aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2022-06-07drm/amd/display: 3.2.188Aric Cyr1-1/+1
This version brings along the following: - Optimized blank calculations - More robust DP MST hotplug support - eDP bug fix relating to ODM - Revert a patch that caused a regression with DP - min comp buffer size fix - Make DP easier to debug - Calculate the maximum OLED brightness correctly - 3 plane MPO. Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: [FW Promotion] Release 0.0.119.0Anthony Koo1-0/+1
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Enable 3 plane MPOHansen Dsouza2-6/+6
[why and how] 3 plane MPO is a new feature missing in a few resource files Enable 3 plane MPO by setting slave planes to 2 Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Hansen Dsouza <Hansen.Dsouza@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Cap OLED brightness per max frame-average luminanceRoman Li1-4/+4
[Why] For OLED eDP the Display Manager uses max_cll value as a limit for brightness control. max_cll defines the content light luminance for individual pixel. Whereas max_fall defines frame-average level luminance. The user may not observe the difference in brightness in between max_fall and max_cll. That negatively impacts the user experience. [How] Use max_fall value instead of max_cll as a limit for brightness control. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: add DP sanity checks during enable streamWenjing Liu4-6/+15
[why] 1. When HPD deassertion is pulled in the middle of enabe stream link training, we will abort current training and turn off PHY. This causes current link settings to be zeroed this causes later stream enablement sequence to fail as we prefer to carry on enablement process despite of link training failure for SST. 2. When HPD is toggled after detection before before the enable stream sequence as a result. There could be a race condition where we could end up enable stream based on the previous link even though the link is updated after the HPD toggle. This causes an issue where our link bandwidth is no longer enough to accommodate the timing therefore causes us to oversubscribe MST payload time slots. As discussed we decided to add basic sanity check to make sure that our code can handle the oversubscription failure silently without system hang. [how] 1. Keep PHY powered on when HPD is deasserted during enable stream and wait for the detection sequence to power it off later. 2. Do not allocate payload if the required timeslot for current timing is greater than 64 timeslots. Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Reviewed-by: George Shen <George.Shen@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Correct min comp buffer sizeDuncan Ma1-1/+2
[Why] In 3-way mpo pipes, there is a case that we overbook the CRB buffer size. At rare instances, overbooking the crb will cause underflow. This only happens when det_size changes dynamically based on pipe_cnt. [How] Set min compbuff size to 1 segment when preparing BW. Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Duncan Ma <duncan.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Blank eDP on enable drv if odm enabledDuncan Ma4-0/+44
[Why] For panels with pixel clock > 1200MHz that require ODM in pre-OS, when driver is disabled in OS, odm is enabled. Upon driver enablement, corruption is seen if odm was originally enabled. DP_PIXEL_COMBINE and pixelclk must be programmed prior to programming the optc-odm registers. However, eDP displays aren't blanked prior to initializing odm in this case. [How] Upon driver enablement, check whether odm is enabled, if so, blank eDP prior to programming optc-odm registers. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Duncan Ma <duncan.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Avoid reading LTTPR caps in non-LTTPR mode.Jimmy Kizito1-13/+31
[Why] LTTPR capable devices on the DisplayPort path may assume that extended LTTPR AUX timeouts will be used after LTTPR capabilities are read. When DPTX operates in non-LTTPR mode, AUX timeouts are not extended and this can result in AUX transactions timing out. [How] Use shared helper function to determine LTTPR mode and do not read LTTPR capabilities in non-LTTPR mode. Reviewed-by: Mustapha Ghaddar <Mustapha.Ghaddar@amd.com> Reviewed-by: Meenakshikumar Somasundaram <Meenakshikumar.Somasundaram@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07Revert "drm/amd/display: Pass the new context into disable OTG WA"Nicholas Kazlauskas3-12/+12
This reverts commit 8440f57532496d398a461887e56ca6f45089fbcf. Causes a hang when hotplugging DP, shutting down system, or enabling dual eDP. Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07Revert "drm/amdgpu: Ensure the DMA engine is deactivated during set ups"Guchun Chen1-64/+45
This reverts commit b992a19085885c096b19625a85c674cb89829ca1. This causes regression in GPU reset related test. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: ricetons@gmail.com Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/i915: remove noisy logs in intel_dp_dsc_get_output_bpp()Luca Coelho1-5/+0
The intel_dp_dsc_get_output_bpp() function outputs two lines of unconditional logs, which was okay when it was called only once. But now, we also call this function from intel_dp_mode_valid(), which is in turn called for every mode we need to validate. This causes a lot of useless noise. Remove the unconditional prints to avoid spamming the logs. Also remove one more print that is not unconditional, but is related. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607074433.1202917-1-luca@coelho.fi
2022-06-07drm/i915/utils: throw out unused stuffJani Nikula1-40/+0
Remove some of the unused helpers from i915_utils.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607094207.536699-3-jani.nikula@intel.com
2022-06-07drm/i915/drv: drop intel_bios.h includeJani Nikula1-1/+0
No longer needed after panel data was moved. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607094207.536699-2-jani.nikula@intel.com
2022-06-07drm/i915/tasklet: separate local hacks around struct tasklet_structJani Nikula4-34/+45
Add a dedicated file for the local functions around struct tasklet_struct. Far from ideal, but better placed in a dedicated file than i915_gem.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607094207.536699-1-jani.nikula@intel.com
2022-06-07drm/i915/client: only include what's neededJani Nikula1-1/+1
Only the uapi header is required. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607092207.476653-1-jani.nikula@intel.com
2022-06-07drm/bridge: lt9611uxc: Cancel only driver's workBjorn Andersson1-1/+1
During device remove care needs to be taken that no work is pending before it removes the underlying DRM bridge etc, but this can be done on the specific work rather than waiting for the flush of the system-wide workqueue. Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220601233818.1877963-1-bjorn.andersson@linaro.org
2022-06-07drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_initMiaoqian Lin1-4/+11
of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: e67f6037ae1b ("drm/meson: split out encoder from meson_dw_hdmi") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601033927.47814-3-linmq006@gmail.com
2022-06-07drm/meson: encoder_cvbs: Fix refcount leak in meson_encoder_cvbs_initMiaoqian Lin1-0/+1
of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 318ba02cd8a8 ("drm/meson: encoder_cvbs: switch to bridge with ATTACH_NO_CONNECTOR") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601033927.47814-2-linmq006@gmail.com
2022-06-07drm/mgag200: Store positions of I2C data and clock bits in device infoThomas Zimmermann10-38/+27
The bits for accessing I2C data and clock channels varies among models. Store them in the device-info structure for consumption by the DDC code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-11-tzimmermann@suse.de
2022-06-07drm/mgag200: Store vidrst flag in device infoThomas Zimmermann11-17/+24
Set new vidrst flag in device info for models that synchronize with external sources (i.e., BMCs). In modesetting, set the corresponding bits from the device-info flag. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-10-tzimmermann@suse.de
2022-06-07drm/mgag200: Store maximum resolution and memory bandwidth in device infoThomas Zimmermann10-63/+75
The maximum resolution and memory bandwidth are model-specific limits. Both are used during display-mode validation. Store the values in struct mgag200_device_info and simplify the validation code. v2: * 'bandwith' -> 'bandwidth' in commit message Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-9-tzimmermann@suse.de
2022-06-07drm/mgag200: Store HW_BUG_NO_STARTADD flag in device infoThomas Zimmermann11-69/+69
Flag devices with broken handling of the startadd field in struct mgag200_device_info, instead of PCI driver data. This reduces the driver data to a simple type constant. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-8-tzimmermann@suse.de
2022-06-07drm/mgag200: Add struct mgag200_device_infoThomas Zimmermann10-10/+46
While currently empty, struct mgag200_device_info, will provide static, constant information on each device model. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-7-tzimmermann@suse.de
2022-06-07drm/mgag200: Implement new init logicThomas Zimmermann13-148/+88
Rework mgag200_regs_init() and mgag200_mm_init() into device preinit and init functions. The preinit function, mgag200_device_preinit(), requests and maps a device's I/O and video memory. The init function, mgag200_device_init() initializes the state of struct mga_device. Splitting the initialization between the two functions is necessary to perform per-model operations between the two calls, such as reading the unique revision ID on G200SEs. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-6-tzimmermann@suse.de
2022-06-07drm/mgag200: Call mgag200_device_probe_vram() from per-model initThomas Zimmermann12-58/+94
Call mgag200_device_probe_vram() from each model's initializer. The G200EW3 uses a special helper with additional instructions. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-5-tzimmermann@suse.de
2022-06-07drm/mgag200: Move PCI-option setup into model-specific codeThomas Zimmermann9-55/+100
Split the PCI code into a single call for each model. G200 and G200SE each contain a dedicated helper with additional instructions. Noteably, the G200ER has no code for PCI setup. In a later patch, the magic numbers should be replaced by descriptive constants. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-4-tzimmermann@suse.de
2022-06-07drm/mgag200: Initialize each model in separate functionThomas Zimmermann13-202/+603
Add a separate initializer function for each model. Add separate devic structures for G200 and G200SE, which require additional information. Also move G200's and G200SE's helpers for reading the BIOS and version id into model-specific code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-3-tzimmermann@suse.de
2022-06-07drm/mgag200: Remove special case for G200SE with <2 MiBThomas Zimmermann1-12/+1
Remove old test for 32-bit vs 16-bit colors. Prefer 24-bit color depth on all devices. 32-bit color depth doesn't exist, it should have always been 24-bit. G200SE with less than 2 MiB of video memory have defaulted to 16-bit color depth, as the original revision of the G200SE had only 1.75 MiB of video memory. Using 16-bit colors enabled XGA resolution. But we now already limit these devices to VGA resolutions as the memory-bandwith test assumes 32-bit pixel size. So drop the special case from color-depth selection. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-2-tzimmermann@suse.de
2022-06-07drm/mediatek: Add pull-down MIPI operation in mtk_dsi_poweroff functionXinlei Lee1-0/+2
In the dsi_enable function, mtk_dsi_rxtx_control is to pull up the MIPI signal operation. Before dsi_disable, MIPI should also be pulled down by writing a register instead of disabling dsi. If disable dsi without pulling the mipi signal low, the value of the register will still maintain the setting of the mipi signal being pulled high. After resume, even if the mipi signal is not pulled high, it will still be in the high state. Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1653012007-11854-5-git-send-email-xinlei.lee@mediatek.com/ Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2022-06-07drm/mediatek: Keep dsi as LP00 before dcs cmds transferJitao Shi1-7/+21
To comply with the panel sequence, hold the mipi signal to LP00 before the dcs cmds transmission, and pull the mipi signal high from LP00 to LP11 until the start of the dcs cmds transmission. The normal panel timing is : (1) pp1800 DC pull up (2) avdd & avee AC pull high (3) lcm_reset pull high -> pull low -> pull high (4) Pull MIPI signal high (LP11) -> initial code -> send video data (HS mode) The power-off sequence is reversed. If dsi is not in cmd mode, then dsi will pull the mipi signal high in the mtk_output_dsi_enable function. The delay in lane_ready func is the reaction time of dsi_rx after pulling up the mipi signal. Fixes: 2dd8075d2185 ("drm/mediatek: mtk_dsi: Use the drm_panel_bridge API") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1653012007-11854-4-git-send-email-xinlei.lee@mediatek.com/ Cc: <stable@vger.kernel.org> # 5.10.x: 7f6335c6a258: drm/mediatek: Modify dsi funcs to atomic operations Cc: <stable@vger.kernel.org> # 5.10.x: cde7e2e35c28: drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs Cc: <stable@vger.kernel.org> # 5.10.x Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2022-06-07drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcsJitao Shi1-19/+34
In order to match the changes of "Use the drm_panel_bridge API", the poweron/poweroff of dsi is extracted from enable/disable and defined as new funcs (atomic_pre_enable/atomic_post_disable). Since dsi_poweron is moved from dsi_enable to pre_enable function, in order to avoid poweron failure, the operation of dsi register fails to cause bus hang. Therefore, the protection mechanism is added to the dsi_enable function. Fixes: 2dd8075d2185 ("drm/mediatek: mtk_dsi: Use the drm_panel_bridge API") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1653012007-11854-3-git-send-email-xinlei.lee@mediatek.com/ Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2022-06-07drm/mediatek: Modify dsi funcs to atomic operationsXinlei Lee1-4/+6
Because .enable & .disable are deprecated. Use .atomic_enable & .atomic_disable instead. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/1653012007-11854-2-git-send-email-xinlei.lee@mediatek.com/ Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2022-06-06drm/atomic: Force bridge self-refresh-exit on CRTC switchBrian Norris1-3/+13
It's possible to change which CRTC is in use for a given connector/encoder/bridge while we're in self-refresh without fully disabling the connector/encoder/bridge along the way. This can confuse the bridge encoder/bridge, because (a) it needs to track the SR state (trying to perform "active" operations while the panel is still in SR can be Bad(TM)); and (b) it tracks the SR state via the CRTC state (and after the switch, the previous SR state is lost). Thus, we need to either somehow carry the self-refresh state over to the new CRTC, or else force an encoder/bridge self-refresh transition during such a switch. I choose the latter, so we disable the encoder (and exit PSR) before attaching it to the new CRTC (where we can continue to assume a clean (non-self-refresh) state). This fixes PSR issues seen on Rockchip RK3399 systems with drivers/gpu/drm/bridge/analogix/analogix_dp_core.c. Change in v2: - Drop "->enable" condition; this could possibly be "->active" to reflect the intended hardware state, but it also is a little over-specific. We want to make a transition through "disabled" any time we're exiting PSR at the same time as a CRTC switch. (Thanks Liu Ying) Cc: Liu Ying <victor.liu@oss.nxp.com> Cc: <stable@vger.kernel.org> Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in drivers") Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.2.Ic15a2ef69c540aee8732703103e2cff51fb9c399@changeid
2022-06-06drm/bridge: analogix_dp: Support PSR-exit to disable transitionBrian Norris1-4/+38
Most eDP panel functions only work correctly when the panel is not in self-refresh. In particular, analogix_dp_bridge_disable() tends to hit AUX channel errors if the panel is in self-refresh. Given the above, it appears that so far, this driver assumes that we are never in self-refresh when it comes time to fully disable the bridge. Prior to commit 846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2."), this tended to be true, because we would automatically disable the pipe when framebuffers were removed, and so we'd typically disable the bridge shortly after the last display activity. However, that is not guaranteed: an idle (self-refresh) display pipe may be disabled, e.g., when switching CRTCs. We need to exit PSR first. Stable notes: this is definitely a bugfix, and the bug has likely existed in some form for quite a while. It may predate the "PSR helpers" refactor, but the code looked very different before that, and it's probably not worth rewriting the fix. Cc: <stable@vger.kernel.org> Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR") Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.1.I161904be17ba14526f78536ccd78b85818449b51@changeid
2022-06-06drm/probe-helper: Default to 640x480 if no EDID on DPDouglas Anderson1-1/+10
If we're unable to read the EDID for a display because it's corrupt / bogus / invalid then we'll add a set of standard modes for the display. Since we have no true information about the connected display, these modes are essentially guesses but better than nothing. At the moment, none of the modes returned is marked as preferred, but the modes are sorted such that the higher resolution modes are listed first. When userspace sees these modes presented by the kernel it needs to figure out which one to pick. At least one userspace, ChromeOS [1] seems to use the rules (which seem pretty reasonable): 1. Try to pick the first mode marked as preferred. 2. Try to pick the mode which matches the first detailed timing descriptor in the EDID. 3. If no modes were marked as preferred then pick the first mode. Unfortunately, userspace's rules combined with what the kernel is doing causes us to fail section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a Link CTS. That test case says that, while it's OK to allow some implementation-specific fall-back modes if the EDID is bad that userspace should _default_ to 640x480. Let's fix this by marking 640x480 as default for DP in the no-EDID case. NOTES: - In the discussion around v3 of this patch [2] there was talk about solving this in userspace and I even implemented a patch that would have solved this for ChromeOS, but then the discussion turned back to solving this in the kernel. - Also in the discussion of v3 [2] it was requested to limit this change to just DP since folks were worried that it would break some subtle corner case on VGA or HDMI. [1] https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488 [2] https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112302.v4.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
2022-06-06drm/amdgpu/soc21: add mode2 asic reset for SMU IP v13.0.4Alex Deucher1-0/+7
Set the default reset method to mode2 for SMU IP v13.0.4 Acked-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Tim Huang <Tim.Huang@amd.com> Signed-off-by: Tim Huang <tim.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()Alexey Kodanev1-4/+2
The last case label can write two buffers 'mc_reg_address[j]' and 'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE since there are no checks for this value in both case labels after the last 'j++'. Instead of changing '>' to '>=' there, add the bounds check at the start of the second 'case' (the first one already has it). Also, remove redundant last checks for 'j' index bigger than array size. The expression is always false. Moreover, before or after the patch 'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it seems it can be a valid value. Detected using the static analysis tool - Svace. Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)") Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amdgpu/display: fix DCN3.2 Makefiles for non-x86Alex Deucher2-2/+16
Add proper handling for PPC64. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amdgpu/display: make some functions staticAlex Deucher3-6/+6
Fixes "no previous prototype" warnings. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amdgpu/discovery: add comments about VCN instance handlingAlex Deucher1-0/+8
Add comments to clarify code that is safe, but triggers and smatch warning. Link: https://lists.freedesktop.org/archives/amd-gfx/2022-June/079905.html Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Dan Carpenter <dan.carpenter@oracle.com>
2022-06-06drm/amd/display: Detect dpcd_rev when hotplug mst monitorWayne Lin1-1/+37
[Why] Once mst topology is constructed, later on new connected monitors are reported to source by CSN message. Within CSN, there is no carried info of DPCD_REV comparing to LINK_ADDRESS reply. As the result, we might leave some ports connected to DP but without DPCD revision number which will affect us determining the capability of the DP Rx. [How] Send out remote DPCD read when the port's dpcd_rev is 0x0 in detect_ctx(). Firstly, read out the value from DPCD 0x2200. If the return value is 0x0, it's likely the DP1.2 DP Rx then we reques revision from DPCD 0x0 again. Reviewed-by: Hersen Wu <hersenwu@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: Update optimized blank calc and programmingGabe Teeger5-16/+5
[Why] The existing calculations in DCN3.1 were placeholder and need to be replaced with HW team approved calculations. [How] The new calculations add new parameters to the bounding box and pipe params - VblankNom and the bounding box default. The placeholder calculations are dropped from DCN3.1 in the meantime while we work out hardware approved replacements. Also fix a bug where we wipe out other register contents with a REG_SET instead of a REG_UPDATE for the register we were programming the min_dst_y_next_start_optimized. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Gabe Teeger <gabe.teeger@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: Implement MPO PSR SULeo Li2-4/+144
[WHY] For additional power savings, PSR SU (also referred to as PSR2) can be enabled on eDP panels with PSR SU support. PSR2 saves more power compared to PSR1 by allowing more opportunities for the display hardware to be shut down. In comparison to PSR1, Shut down can now occur in-between frames, as well as in display regions where there is no visible update. In otherwords, it allows for some display hw components to be enabled only for a **selectively updated** region of the visible display. Hence PSR SU. [HOW] To define the SU region, support from the OS is required. OS needs to inform driver of damaged regions that need to be flushed to the eDP panel. Today, such support is lacking in most compositors. Therefore, an in-between solution is to implement PSR SU for MPO and cursor scenarios. The plane bounds can be used to define the damaged region to be flushed to panel. This is achieved by: * Leveraging dm_crtc_state->mpo_requested flag to identify when MPO is enabled. * If MPO is enabled, only add updated plane bounds to dirty region. Determine plane update by either: * Existence of drm damaged clips attached to the plane (added by a damage-aware compositor) * Change in fb id (flip) * Change in plane bounds (position and dimensions) * If cursor is enabled, the old_pos and new_pos of cursor plus cursor size is used as damaged regions(*). (*) Cursor updates follow a different code path through DC. PSR SU for cursor is already implemented in DC, and the only thing required to enable is to set DC_PSR_VERSION_SU_1 on the eDP link. See dcn10_dmub_update_cursor_data(). Signed-off-by: Leo Li <sunpeng.li@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: update cursor position to DMUB FWDavid Zhang4-0/+136
[why] To involve the cursor position into dirty rectangle calculation. [how] - separate plane and cursor update by different DMUB command - send the cursor information while cursor updating, when updating cursor position/attribute, store cursor pos/attr to hubp, and notify dmub FW to exit psr before program cursor registers Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: calculate psr config settings in runtime in DMDavid Zhang1-5/+10
[why] Currently the psr configuration parameters are hardcoded before feeding into the DC helper before passing to DMUB FW. We'd rework to call a shared helper to calculate/update generic psr config fields which are relying on the stream timing and eDP sink PSR caps to avoid hard-coding. [how] - drop part of hard-coded psr config fields by replacing w/ the call of helper from DM before feeding into DC link setup psr helper - For those DM specific psr config fields, e.g. allow smu opt, is not to be set/updated from the shared helper but to rely on the DC feature mask - for the psr version field in psr_config structure, since only the field psr_version of DC link psr_settings matters for that fed to DMUB FW, thus no need to set/update the psr_version field of psr_config structure. Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: add shared helpers to update psr config fields to power moduleDavid Zhang2-0/+90
[why] Currently the amdgpu DM psr configuration parameters are hardcoded before feeding into the DC helper to setup PSR. We would define a helper which is to calculate parts of the psr config fields to avoid hard-coding. [how] To make helper shareable, declare and define the helper in the module_helper, to set/update below fields: - psr remote buffer setup time - sdp tx line number deadline - line time in us - su_y_granularity - su_granularity_required - psr_frame_capture_indication_req - psr_exit_link_training_required add another helper to check given the stream context, if there is only one stream and the output is eDP panel connected. changes in v2: ------------------ - add detailed comment for how psr setup time is calculated as per eDP 1.5 spec Cc: Chandan Vurdigerenataraj <chandan.vurdigerenataraj@amd.com> Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: PSRSU+DSC WA for specific TCONDavid Zhang2-0/+15
[why] Some specific TCON chip has HW limitation to support PSRSU+DSC. [how] Force ffu mode when DSC enabled if we detect it is the specific model from sink OUI DPCD. And disable ABM update for this case. Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: use HW lock mgr for PSR-SUDavid Zhang1-0/+2
[why] Feature requires synchronization of dig, pipe, and cursor locking between driver and DMUB fw for PSR-SU [how] return True if PSR-SU in the checker should_use_dmub_lock() Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: Set PSR level to enable ALPM by defaultDavid Zhang2-1/+7
[Why & How] While support ALPM, do ALPM state transition while PSR entry/exit. ALPM is needed for PSR-SU feature, and since the function is ready, we'd enable it by default. - Add psr level definition to enable/disable ALPM and set ALPM powerdone mode. - Enable ALPM by default Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-06drm/amd/display: fix system hang when PSR exitsDavid Zhang2-0/+23
[why] When DC driver send PSR exit dmub command to DMUB FW, it might not wait until PSR exit. Then it may hit the following deadlock situation. 1. DC driver send HW LOCK command to DMUB FW due to frame update 2. DMUB FW Set the HW lock 3. DMUB execute PSR exit sequence and stuck at polling DPG Pending register due to the HW Lock is set 4. DC driver ask DMUB FW to unlock HW lock, but DMUB FW is polling DPG pending register [how] The reason why DC driver doesn't wait until PSR exit is because some of the PSR state machine state is not update the dc driver. So when DC driver read back the PSR state, it take the state for PSR inactive. Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.