summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd/display/amdgpu_dm
AgeCommit message (Collapse)Author
2019-10-07drm/amd/display: Use proper enum conversion functionsNathan Chancellor
[ Upstream commit d196bbbc28fab82624f7686f8b0da8e8644b6e6a ] clang warns: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:336:8: warning: implicit conversion from enumeration type 'enum smu_clk_type' to different enumeration type 'enum amd_pp_clock_type' [-Wenum-conversion] dc_to_smu_clock_type(clk_type), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:421:14: warning: implicit conversion from enumeration type 'enum amd_pp_clock_type' to different enumeration type 'enum smu_clk_type' [-Wenum-conversion] dc_to_pp_clock_type(clk_type), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are functions to properly convert between all of these types, use them so there are no longer any warnings. Fixes: a43913ea50a5 ("drm/amd/powerplay: add function get_clock_by_type_with_latency for navi10") Fixes: e5e4e22391c2 ("drm/amd/powerplay: add interface to get clock by type with latency for display (v2)") Link: https://github.com/ClangBuiltLinux/linux/issues/586 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05drm/amd/display: Restore backlight brightness after system resumeKai-Heng Feng
commit bb264220d9316f6bd7c1fd84b8da398c93912931 upstream. Laptops with AMD APU doesn't restore display backlight brightness after system resume. This issue started when DC was introduced. Let's use BL_CORE_SUSPENDRESUME so the backlight core calls update_status callback after system resume to restore the backlight level. Tested on Dell Inspiron 3180 (Stoney Ridge) and Dell Latitude 5495 (Raven Ridge). Cc: <stable@vger.kernel.org> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-01drm/amd/display: Don't replace the dc_state for fast updatesNicholas Kazlauskas
commit bd200d190f45b62c006d1ad0a63eeffd87db7a47 upstream. [Why] DRM private objects have no hw_done/flip_done fencing mechanism on their own and cannot be used to sequence commits accordingly. When issuing commits that don't touch the same set of hardware resources like page-flips on different CRTCs we can run into the issue below because of this: 1. Client requests non-blocking Commit #1, has a new dc_state #1, state is swapped, commit tail is deferred to work queue 2. Client requests non-blocking Commit #2, has a new dc_state #2, state is swapped, commit tail is deferred to work queue 3. Commit #2 work starts, commit tail finishes, atomic state is cleared, dc_state #1 is freed 4. Commit #1 work starts, commit tail encounters null pointer deref on dc_state #1 In order to change the DC state as in the private object we need to ensure that we wait for all outstanding commits to finish and that any other pending commits must wait for the current one to finish as well. We do this for MEDIUM and FULL updates. But not for FAST updates, nor would we want to since it would cause stuttering from the delays. FAST updates that go through dm_determine_update_type_for_commit always create a new dc_state and lock the DRM private object if there are any changed planes. We need the old state to validate, but we don't actually need the new state here. [How] If the commit isn't a full update then the use after free can be resolved by simply discarding the new state entirely and retaining the existing one instead. With this change the sequence above can be reexamined. Commit #2 will still free Commit #1's reference, but before this happens we actually added an additional reference as part of Commit #2. If an update comes in during this that needs to change the dc_state it will need to wait on Commit #1 and Commit #2 to finish. Then it'll swap the state, finish the work in commit tail and drop the last reference on Commit #2's dc_state. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204181 Fixes: 004b3938e637 ("drm/amd/display: Check scaling info when determing update type") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-01drm/amd/display: Skip determining update type for async updatesNicholas Kazlauskas
commit 43d10d30df156f7834fa91aecb69614fefc8bb0a upstream. [Why] By passing through the dm_determine_update_type_for_commit for atomic commits that can be done asynchronously we are incurring a performance penalty by locking access to the global private object and holding that access until the end of the programming sequence. This is also allocating a new large dc_state on every access in addition to retaining all the references on each stream and plane until the end of the programming sequence. [How] Shift the determination for async update before validation. Return early if it's going to be an async update. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-01drm/amd/display: Allow cursor async updates for framebuffer swapsNicholas Kazlauskas
commit e16e37efb4c9eb7bcb9dab756c975040c5257e98 upstream. [Why] We previously allowed framebuffer swaps as async updates for cursor planes but had to disable them due to a bug in DRM with async update handling and incorrect ref counting. The check to block framebuffer swaps has been added to DRM for a while now, so this check is redundant. The real fix that allows this to properly in DRM has also finally been merged and is getting backported into stable branches, so dropping this now seems to be the right time to do so. [How] Drop the redundant check for old_fb != new_fb. With the proper fix in DRM, this should also fix some cursor stuttering issues with xf86-video-amdgpu since it double buffers the cursor. IGT tests that swap framebuffers (-varying-size for example) should also pass again. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-21drm/amd/display: Calculate bpc based on max_requested_bpcNicholas Kazlauskas
[Why] The only place where state->max_bpc is updated on the connector is at the start of atomic check during drm_atomic_connector_check. It isn't updated when adding the connectors to the atomic state after the fact. It also doesn't necessarily reflect the right value when called in amdgpu during mode validation outside of atomic check. This can cause the wrong bpc to be used even if the max_requested_bpc is the correct value. [How] Don't rely on state->max_bpc reflecting the real bpc value and just do the min(...) based on display info bpc and max_requested_bpc. Fixes: 01933ba42d3d ("drm/amd/display: Use current connector state if NULL when checking bpc") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-18drm/amd/display: Force uclk to max for every stateNicholas Kazlauskas
Workaround for now to avoid underflow. The uclk switch time should really be bumped up to 404, but doing so would expose p-state hang issues for higher bandwidth display configurations. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-11drm/amdgpu: Print out voltage in DM_PPLIBPaul Menzel
As the clock is already logged, also log the voltage. Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-11drm/amd/display: Add drm_audio_component support to amdgpu_dmNicholas Kazlauskas
[Why] The drm_audio_component can be used to give pin ELD notifications directly to the sound driver. This fixes audio endpoints disappearing due to missing unsolicited notifications. [How] Send the notification via the audio component whenever we enable or disable audio state on a stream. This matches what i915 does with their drm_audio_component and what Takashi Iwai's proposed hack for radeon/amdpgu did. This is a bit delayed in when the notification actually occurs, however. We wait until after all the programming is complete rather than sending the notification mid sequence. Particular care is needed for the get ELD callback since it can happen outside the locking and fencing DRM does for atomic commits. Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-02drm/amdgpu/display: fix interrupt client id for naviAlex Deucher
All asics newer than vega10 use client ids, so simplify the check. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-25drm/amd/amdgpu: Check stream in amdgpu_dm_commit_planesErnst Sjöstrand
Reported by smatch: amdgpu_dm.c:5637 amdgpu_dm_commit_planes() error: we previously assumed 'acrtc_state->stream' could be null This seems to be checked for null pretty consistently elsewhere. Signed-off-by: Ernst Sjöstrand <ernstp@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-25Merge branch 'drm-next' into drm-next-5.3Alex Deucher
Backmerge drm-next and fix up conflicts due to drmP.h removal. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-22drm/amd/display: Rework CRTC color managementNicholas Kazlauskas
[Why] To prepare for the upcoming DRM plane color management properties we need to correct a lot of wrong behavior and assumptions made for CRTC color management. The documentation added by this commit in amdgpu_dm_color explains how the HW color pipeline works and its limitations with the DRM interface. The current implementation does the following wrong: - Implicit sRGB DGM when no CRTC DGM is set - Implicit sRGB RGM when no CRTC RGM is set - No way to specify a non-linear DGM matrix that produces correct output - No way to specify a correct RGM when a linear DGM is used We had workarounds for passing kms_color tests but not all of the behavior we had wrong was covered by these tests (especially when it comes to non-linear DGM). Testing both DGM and RGM at the same time isn't something kms_color tests well either. [How] The specifics for how color management works in AMDGPU and the new behavior can be found by reading the documentation added to amdgpu_dm_color.c from this patch. All of the incorrect cases from the old implementation have been addressed for the atomic interface, but there still a few TODOs for the legacy one. Note: this does cause regressions for kms_color@pipe-a-ctm-* over HDMI. The result looks correct from visual inspection but the CRC no longer matches. For reference, the test was previously doing the following: linear degamma -> CTM -> sRGB regamma -> RGB to YUV (709) -> ... Now the test is doing: linear degamma -> CTM -> linear regamma -> RGB to YUV (709) -> ... Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-22drm/amd/display: update DSC MST DP virtual DPCD peer device enumeration policyWenjing Liu
[why] Current policy assumes virtual DPCD peer device as an individual MST branch device with 1 input and 1 output. However this is only true for virtual DP-to-DP peer device. In general there are three types of virtual DP peer devices. 1. Sink peer device with virtual DPCD. 2. Virtual DP-to-DP Peer device with virtual DPCD. 3. Virtual DP-to-HDMI Protocol Converter Peer Device with Virtual DPCD. So we should break the assumption and handle all three types. [how] DP-to-DP peer device will have virtual DPCD cap upstream. Sink peer device will have virtual DPCD on the logical port. Dp to HDMI protocol converter peer device will have virtual DPCD on its converter port. For DSC capable Synaptics non VGA port we workaround by enumerating a virutal DPCD peer device on its upstream even if it doesn't have one. Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-22drm/amd/display: Add power down display on boot flagThomas Lim
[Why] Due to the generic introduction of seamless boot, the display is no longer blanked upon boot. However, this causes corruption on some systems that does not lock the memory in the non-secure boot case, resulting in brief corruption on boot due to garbage being written into the frame buffer. [How] Add a flag, read during DC init, to determine whether display should be blanked on boot. Default to true. Signed-off-by: Thomas Lim <Thomas.Lim@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Acked-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-22drm/amd/display: disable dcn20 abm feature for bring uphersen wu
[WHY] dcn20 enable usb-c dp ALT mode in dmcu. There is bug when enable abm feature which cause system crash. dal team will debug this bug later. [HOW] disable dcn abm feature for dcn20. Signed-off-by: hersen wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-22drm/amd/display: Add DSC support for Navi (v2)Harry Wentland
Add support for DCN2 DSC (Display Stream Compression) HW Blocks: +--------++------+ +----------+ | HUBBUB || HUBP | <-- | MMHUBBUB | +--------++------+ +----------+ | ^ v | +--------+ +--------+ | DPP | | DWB | +--------+ +--------+ | v ^ +--------+ | | MPC | | +--------+ | | | v | +-------+ +-------+ | | OPP | <--> | DSC | | +-------+ +-------+ | | | v | +--------+ / | OPTC | -------------- +--------+ | v +--------+ +--------+ | DIO | | DCCG | +--------+ +--------+ v2: rebase (Alex) Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-22drm/amd/display: Hook DCN2 into amdgpu_dm and expose as config (v2)Harry Wentland
Enable DCN2 support in DM (Display Manager). v2: fix spurious raven change (Alex) Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-22drm/amd/display: hook navi10 pplib functionshersen wu
during bring up time, before window dc-ppplib interface design, linux dc use raven dc-pplib interface. now nvai10 dc-pplib-smu interface is changed and verified under window, navi10 need its specific dc-pplib-smu interface. todo: hook set_hard_min_uclk_by_freq, get_maximum_sustainable_clocks Signed-off-by: hersen wu <hersenxs.wu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-21drm/amd/display: Read soc_bounding_box from gpu_info (v2)Harry Wentland
[WHY] We don't want to expose sensitive ASIC information before ASIC release. [HOW] Encode the soc_bounding_box in the gpu_info FW (for Linux) and read it at driver load. v2: fix warning when CONFIG_DRM_AMD_DC_DCN2_0 is not set (Alex) Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-21drm/amd/powerplay: add function get_clock_by_type_with_latency for navi10Kevin Wang
add callback function get_clock_by_type_with_latency for navi10 asic Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-20drm/amd/display: move dcn v1_0 irq source header to ivsrcid/dcn/Hawking Zhang
interrupt source packet definitions for the display block (DCN). Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Jack Xiao <Jack.Xiao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-20Revert "drm/amd/display: Rework CRTC color management"Alex Deucher
This reverts commit 7cd4b70091a5cfa1f58d3a529535304a116acc95. Revert this to apply the version that includes DCN2 support. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-20Revert "drm/amd/display: Enable fast plane updates when state->allow_modeset ↵Nicholas Kazlauskas
= true" This reverts commit ebc8c6f18322ad54275997a888ca1731d74b711f. There are still missing corner cases with cursor interaction and these fast plane updates on Picasso and Raven2 leading to endless PSTATE warnings for typical desktop usage depending on the userspace. This change should be reverted until these issues have been resolved. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110949 Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-19Merge v5.2-rc5 into drm-nextDaniel Vetter
Maarten needs -rc4 backmerged so he can pull in the fbcon notifier removal topic branch into drm-misc-next. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-06-17drm/amd/display: Delete a redundant memory setting in ↵Markus Elfring
amdgpu_dm_irq_register_interrupt() The memory was set to zero already by a call of the function “kzalloc”. Thus remove an extra call of the function “memset” for this purpose. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-14Merge tag 'drm-misc-next-2019-06-14' of ↵Daniel Vetter
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.3: UAPI Changes: Cross-subsystem Changes: - Add code to signal all dma-fences when freed with pending signals. - Annotate reservation object access in CONFIG_DEBUG_MUTEXES Core Changes: - Assorted documentation fixes. - Use irqsave/restore spinlock to add crc entry. - Move code around to drm_client, for internal modeset clients. - Make drm_crtc.h and drm_debugfs.h self-contained. - Remove drm_fb_helper_connector. - Add bootsplash to todo. - Fix lock ordering in pan_display_legacy. - Support pinning buffers to current location in gem-vram. - Remove the now unused locking functions from gem-vram. - Remove the now unused kmap-object argument from vram helpers. - Stop checking return value of debugfs_create. - Add atomic encoder enable/disable helpers. - pass drm_atomic_state to atomic connector check. - Add atomic support for bridge enable/disable. - Add self refresh helpers to core. Driver Changes: - Add extra delay to make MTP SDM845 work. - Small fixes to virtio, vkms, sii902x, sii9234, ast, mcde, analogix, rockchip. - Add zpos and ?BGR8888 support to meson. - More removals of drm_os_linux and drmP headers for amd, radeon, sti, r128, r128, savage, sis. - Allow synopsis to unwedge the i2c hdmi bus. - Add orientation quirks for GPD panels. - Edid cleanups and fixing handling for edid < 1.2. - Add runtime pm to stm. - Handle s/r in dw-hdmi. - Add hooks for power on/off to dsi for stm. - Remove virtio dirty tracking code, done in drm core. - Rework BO handling in ast and mgag200. Tiny conflict in drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c, needed #include <linux/slab.h> to make it compile. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0e01de30-9797-853c-732f-4a5bd6e61445@linux.intel.com
2019-06-14drm/amdgpu: Fix connector atomic_check compilation failSean Paul
I missed amdgpu in my connnector_helper_funcs->atomic_check conversion, which is understandably causing compilation failures. Fixes: 6f3b62781bbd ("drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state") Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [for rcar lvds] Cc: Sean Paul <seanpaul@chromium.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614002713.141340-1-sean@poorly.run
2019-06-13amdgpu_dm: no need to check return value of debugfs_create functionsGreg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: David Francis <David.Francis@amd.com> Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Anthony Koo <Anthony.Koo@amd.com> Cc: hersen wu <hersenxs.wu@amd.com> Cc: "Leo (Hanghong) Ma" <hanghong.ma@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-11drm/amd/display: Rework CRTC color managementNicholas Kazlauskas
[Why] To prepare for the upcoming DRM plane color management properties we need to correct a lot of wrong behavior and assumptions made for CRTC color management. The documentation added by this commit in amdgpu_dm_color explains how the HW color pipeline works and its limitations with the DRM interface. The current implementation does the following wrong: - Implicit sRGB DGM when no CRTC DGM is set - Implicit sRGB RGM when no CRTC RGM is set - No way to specify a non-linear DGM matrix that produces correct output - No way to specify a correct RGM when a linear DGM is used We had workarounds for passing kms_color tests but not all of the behavior we had wrong was covered by these tests (especially when it comes to non-linear DGM). Testing both DGM and RGM at the same time isn't something kms_color tests well either. [How] The specifics for how color management works in AMDGPU and the new behavior can be found by reading the documentation added to amdgpu_dm_color.c from this patch. All of the incorrect cases from the old implementation have been addressed for the atomic interface, but there still a few TODOs for the legacy one. Note: this does cause regressions for kms_color@pipe-a-ctm-* over HDMI. The result looks correct from visual inspection but the CRC no longer matches. For reference, the test was previously doing the following: linear degamma -> CTM -> sRGB regamma -> RGB to YUV (709) -> ... Now the test is doing: linear degamma -> CTM -> linear regamma -> RGB to YUV (709) -> ... Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-11drm/amd/display: Set default ABM level to module parameterNicholas Kazlauskas
[Why] The module parameter to specify the default ABM level is now defined, so hook it up in DM. [How] On connector reset specify the default level. DC will program this as part of the modeset since it gets passed onto the stream in dm_update_crtc_state. It's only set for eDP connectors, but it doesn't matter if this is specified for connectors or hardware that doesn't support ABM. It's DC's responsibility to check that ABM can be set or adjusted, and DC does check that the DMCU firmware is running and if there's backlight control available. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-11drm/amd/display: Enable fast plane updates when state->allow_modeset = trueNicholas Kazlauskas
[Why] Whenever the a modeset is allowed (but not neccessarily required) we currently recreate all the planes in the state. Most IGT tests and legacy IOCTLs create atomic commits with this flag set, so the pipes are often unnecessarily reprogrammed. Poor performance and stuttering can occur when many of these commits are frequently issued. This flag was needed when the appropriate conditions for checking whether the planes needed a reset were not in place, but should_reset_plane should cover everything needed now. [How] Drop the check for state->allow_modeset in should_reset_plane. All planes on a CRTC should reset in the following conditions: - The CRTC needs a modeset - The CRTC degamma changes - Planes are added or removed to the CRTC These conditions are all covered in should_reset_plane. We still can't drop the format change check in should_reset_plane since fill_dc_plane_info_and_addr isn't called when validating the state, so we can't tell if a FULL update is needed or not. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-11drm/amd/display: Use current connector state if NULL when checking bpcNicholas Kazlauskas
[Why] The old logic for checking which output depth to use relied on using the current connector state rather than the new proposed state. This was a problem when performing atomic commits since we weren't verifying it against the incoming max_requested_bpc. But switching this to only use the new state and not the current state breaks filtering modes - it'll always assume that the maximum bpc supported by the display is in use, which will cause certain modes like 1440p@144Hz to be filtered even when using 8bpc. [How] Still use the connector->state if we aren't passed an explicit state. This will respect the max_bpc the user currently has when filtering modes. Also remember to reset the default max_requested_bpc to 8 whenever connector reset is called to retain old behavior when using the new property. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110845 Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-11drm/amd/display: Always allocate initial connector state stateNicholas Kazlauskas
[Why] Unlike our regular connectors, MST connectors don't start off with an initial connector state. This causes a NULL pointer dereference to occur when attaching the bpc property since it tries to modify the connector state. We need an initial connector state on the connector to avoid the crash. [How] Use our reset helper to allocate an initial state and reset the values to their defaults. We were already doing this before, just not for MST connectors. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-11drm/amd/display: Add connector debugfs for "output_bpc"Nicholas Kazlauskas
[Why] This will be useful for verifying whether we enter the correct output color depth from IGT. [How] Locks the connector and associated CRTC if available and outputs the current and maximum output bpc values. Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc Current: 8 Maximum: 10 v2: Drop unneeded connector status check Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-11drm/amd/display: Don't set mode_changed=false if the stream was removedNicholas Kazlauskas
[Why] When switching from vt to desktop with EDID emulation we can receive an atomic commit such that we have a crtc where mode_changed = true. During the dm_update_crtc_state disable pass we remove the stream from the context and free it on the dm_new_crtc_state. During the enable pass we compare the new provisional stream to the dm_old_crtc_state->stream and determine that the stream is unchanged and no scaling has been changed. Following this, new_crtc_state->mode_changed is then set to false. The connectors haven't changed and the CRTC active state hasn't changed so drm_atomic_crtc_needs_modeset returns false, so we jump to skip_modeset and we hit: BUG_ON(dm_new_crtc_state->stream == NULL); ...since the old stream is gone from the context and the new stream is also still NULL. [How] Ensure that we still a stream to reuse before checking if we can reuse the old stream without a full modeset. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-10drm/amd: drop use of drmP.h in display/Sam Ravnborg
Drop all uses of drmP.h in drm/amd/display/. Fix fallout. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190609220757.10862-9-sam@ravnborg.org
2019-06-10drm/amd: drop use of drmP.h from all header filesSam Ravnborg
Drop use of the deprecated drmP.h header file from all amd header files. This makes it a more smooth process to get rid of drmP.h in the .c files. Added include files and forwards as appropriate. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190609220757.10862-7-sam@ravnborg.org
2019-06-10drm/amd: drop use of drmP.h in amdgpu.hSam Ravnborg
Delete the unused drmP.h from amdgpu.h. Fix fallout in various files. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190609220757.10862-5-sam@ravnborg.org
2019-06-06Merge branch 'drm-next-5.3' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next amdgpu: - Revert timeline support until KHR is ready - Various driver reload fixes - Refactor clock handling in DC - Aux fixes for DC - Bandwidth calculation updates for DC - Fix documentation due to file rename - RAS fix - Fix race in late_init ttm: - Allow for better forward progress when there is heavy memory contention Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606032537.6939-1-alexander.deucher@amd.com
2019-06-05drm/amdgpu/display: Drop some new CONFIG_DRM_AMD_DC_DCN1_01 guardsAlex Deucher
These got added back by subsequent merges accidently. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-06Merge tag 'drm-misc-next-2019-06-05' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.3: UAPI Changes: Cross-subsystem Changes: - Add devicetree bindings for new panels. - Convert allwinner's DT bindings to a schema. - Drop video/hdmi static functions from kernel docs. - Discard old fence when reserving space in reservation_object_get_fences_rcu. Core Changes: - Add missing -ENOMEM handling in edid loading. - Fix null pointer deref in scheduler. - Header cleanups, making them self-contained. - Remove drmP.h inclusion from core. - Fix make htmldocs warning in scheduler and HDR metadata. - Fix a few warnings in the uapi header and add a doc section for it. - Small MST sideband error handling fix. - Clarify userspace review requirements. - Clarify implicit/explicit fencing in docs. - Flush output polling on shutdown. Driver Changes: - Small cleanups to stm. - Add new driver for ST-Ericsson MCDE - Kconfig fix for meson HDMI. - Add support for Armadeus ST0700 Adapt panel. - Add KOE tx14d24vm1bpa panel. - Update timings for st7701. - Fix compile error in mcde. - Big series of tc358767 fixes, and enabling support for IRQ and HPD handling. - Assorted fixes to sii902x, and implementing HDMI audio support. - Enable HDR metadata support on amdgpu. - Assorted fixes to atmel-hlcdc, and add sam9x60 LCD controller support. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6c43ffa9-11ff-5354-d772-c20fd4d1e3d9@linux.intel.com
2019-06-04drm/amd: fix fb references in async updateHelen Koike
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <stable@vger.kernel.org> # v4.20+ Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane updates") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-3-helen.koike@collabora.com
2019-06-03drm/amd/display: Only force modesets when toggling HDRNicholas Kazlauskas
[Why] We can issue HDR static metadata as part of stream updates for non-modesets as long as we force a modeset when entering or exiting HDR. This avoids unnecessary blanking for simple metadata updates. [How] When changing scaling and abm for the stream also check if HDR has changed and send the stream update. This will only happen in non-modeset cases. Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528190836.10738-3-nicholas.kazlauskas@amd.com
2019-06-03drm/amd/display: Expose HDR output metadata for supported connectorsNicholas Kazlauskas
[Why] For userspace to send static HDR metadata to the display we need to attach the property on the connector and send it to DC. [How] The property is attached to HDMI and DP connectors. Since the metadata isn't actually available when creating the connector this isn't a property we can dynamically support based on the extension block being available or not. When the HDR metadata is changed a modeset will be forced for now. We need to switch from 8bpc to 10bpc in most cases anyway, and we want to fully exit HDR mode when userspace gives us a NULL metadata, so this isn't completely unnecessary. The requirement can later be reduced to just entering and exiting HDR or switching max bpc. Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528190836.10738-2-nicholas.kazlauskas@amd.com
2019-05-31drm/amd/display: use ttm_eu_reserve_buffers instead of amdgpu_bo_reserve v2Chunming Zhou
add ticket for display bo, so that it can preempt busy bo. v2: fix stupid rebase error Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-31drm/amdgpu/display: Fix reload driver errorEmily Deng
Issue: Will have follow error when reload driver: [ 3986.567739] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:07.0/drm_dp_aux_dev' [ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G OE 5.0.0-rc1-custom #1 [ 3986.567745] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 3986.567746] Call Trace: ...... [ 3986.567808] drm_dp_aux_register_devnode+0xdc/0x140 [drm_kms_helper] ...... [ 3986.569081] kobject_add_internal failed for drm_dp_aux_dev with -EEXIST, don't try to register things with the same name in the same directory. Reproduce sequences: 1.modprobe amdgpu 2.modprobe -r amdgpu 3.modprobe amdgpu Root cause: When unload driver, it doesn't unregister aux. v2: Don't use has_aux Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-31drm/amd/display: Reset planes for color management changesNicholas Kazlauskas
[Why] For commits with allow_modeset=false and CRTC degamma changes the planes aren't reset. This results in incorrect rendering. [How] Reset the planes when color management has changed on the CRTC. Technically this will include regamma changes as well, but it doesn't really after legacy userspace since those commit with allow_modeset=true. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-31drm/amd/display: Ensure DRR triggers in BPEryk Brol
[Why] In the previous implementation DRR event sometimes came in during FP2 region which is a keep-out zone. This would cause the frame not to latch until the next frame which resulted in heavy flicker. To fix this we need to make sure that it triggers in the BP. [How] 1. Remove DRR programming during flip 2. Setup manual trigger for DRR event and trigger it after surface programming is complete Signed-off-by: Eryk Brol <eryk.brol@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-28drm/amdgpu: fix unload driver failEmily Deng
dc_destroy should be called amdgpu_cgs_destroy_device, as it will use cgs context to read or write registers. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>