summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-10-06drm/amd/display: Implement end of training for hop in DPIA display pathJimmy Kizito
[Why & How] Clear training pattern sequence for hop in display path once clock recovery and equalization phases of DP tunnel link training completed. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Implement DPIA equalisation phaseJimmy Kizito
[Why] Equalisation is the mandatory second phase of DisplayPort link training over a USB4 DP tunnel. [How] Implement equalisation phase for DP tunneled over USB4 in DPIA training module. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Implement DPIA clock recovery phaseJimmy Kizito
[Why] Clock recovery is the mandatory first phase of DP link training. [How] - Implement clock recovery phase in DPIA training module. - Add helper functions for building SET_CONFIG messages. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Implement DPIA link configurationJimmy Kizito
[Why] Training settings need to be applied to DPIA link at start of each training loop. Note: FEC readiness should be configured before link training while FEC enablement should be configured once training is complete. [How] - Implement DPIA link configuration function. - Account for dynamically assigned link encoders during link configuration. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Implement DPIA training loopJimmy Kizito
[Why] Training of DPIA link differs enough from that of conventional DP link to warrant a separate implementation. [How] - Implement top-level of DPIA training loop. - Make functions shared between DP and DPIA link training "public". Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Train DPIA links with fallbackJimmy Kizito
[Why & How] Conventional links are trained with fallback during sink detection. Have DPIA links trained with fallback too. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Skip DPCD read for DPTX-to-DPIA hopJimmy Kizito
[why & how] Driver does not need to train the first hop. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Add stub to get DPIA tunneling device dataJimmy Kizito
[why & how] 1. Add stub for getting tunneling device data 2. Add check for phy_repeater_cnt < 0xff to LTTPR check 3. Add two more bits of information to DPIA links Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Stub out DPIA link training callJimmy Kizito
[why & how] Add stub for DPIA link training and define new DPIA DMUB commands to support it. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Set DPIA link endpoint typeJimmy Kizito
[why & how] We will need a way to distinguish physically connected links and DPIA endpoints. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Support for DMUB HPD and HPD RX interrupt handlingMeenakshikumar Somasundaram
[WHY] To add support for HPD & HPD RX interrupt handling for USB4 DPIA in YELLOW_CARP_B0. USB4 DPIA HPD & HPD RX interrupts are issued from DMUB to driver as a outbox1 message. [HOW] 1) Created get_link_index_from_dpia_port_index() to retrieve link index from dpia port index for HPD & HPD RX dmub notifications. 2) Added DMUB HPD & HPD RX handling in dmub_srv_stat_get_notification(). Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: USB4 DPIA enumeration and AUX TunnelingMeenakshikumar Somasundaram
[WHY] To enable dc links for USB4 DPIA ports and AUX command tunneling for YELLOW_CARP_B0. [HOW] 1) Created dc links for all USB4 DPIA ports in create_links(). dc_link_construct() implementation is split for legacy DDC and DPIAs. As usb4 has no ddc, ddc->ddc_pin will be set to NULL for its dc link and this parameter will be used to identify the dc links as DPIA. The dc link for DPIA is further to be enhanced with implementation for link encoder and link initialization. 2) usb4_dpia_count in struct resource_pool will be initialized to 4 in dcn31_resource_construct() if the DCN is YELLOW_CARP_B0. 3) Enabled DMUB AUX via outbox for YELLOW_CARP_B0. Reviewed-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Update link encoder object creation.Jimmy Kizito
[Why & How] USB4 endpoints are dynamically mapped. We create additional link encoders for USB4 use when DC is created and destroy them when DC is destructed Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: fix DCC settings for DCN3Marek Olšák
ind_block_64b_no_128bcl means INDEP_64B && INDEP_128B && MAX_COMPRESSED_BLOCK_SIZE == 64B. Only used by gfx10.3. ind_block_64b means INDEP_64B && !INDEP_128B && MAX_COMPRESSED_BLOCK_SIZE == 64B. Only used by gfx9 and gfx10. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Fix error in dmesg at bootLeo (Hanghong) Ma
[Why] During DQE's promotion test, error appears in dmesg at boot on dcn3.1; [How] Add NULL pointor check for the pointor to the amdgpu_dm_connector; Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Fix concurrent dynamic encoder assignment.Jimmy Kizito
[Why] Trying to enable multiple displays simultaneously exposed shortcomings with the algorithm for dynamic link encoder assignment. The main problems were: - Assuming stream order remained constant across states would sometimes lead to invalid DIG encoder assignment. - Incorrect logic for deciding whether or not a DIG could support a stream would also sometimes lead to invalid DIG encoder assignment. - Changes in encoder assignment were wholesale while updating of the pipe backend is incremental. This would lead to the hardware state not matching the software state even with valid encoder assignments. [How] The following changes fix the identified problems. - Use stream pointer rather than stream index to track streams across states. - Fix DIG compatibility check by examining the link signal type rather than the stream signal type. - Modify assignment algorithm to make incremental updates so software and hardware states remain coherent. Additionally: - Add assertions and an encoder assignment validation function link_enc_cfg_validate() to detect potential problems with encoder assignment closer to their root cause. - Reduce the frequency with which the assignment algorithm is executed. It should not be necessary for fast state validation. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Add helper for blanking all dp displaysLeo (Hanghong) Ma
[Why & How] The codes to blank all dp display have been called many times, so add a helper in dc_link to make it more concise. Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: 3.2.156Aric Cyr
This version brings along following fixes: - New firmware version - Fix DMUB problems on stress test. - Improve link training by skip overrride for preferred link - Refinement of FPU code structure for DCN2 - Fix 3DLUT skipped programming - Fix detection of 4 lane for DPALT - Fix dcn3 failure due to dmcbu_abm not created - Limit display scaling to up to 4k for DCN 3.1 - Add helper for blanking all dp displays Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: [FW Promotion] Release 0.0.87Anthony Koo
Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Fix detection of 4 lane for DPALTHansen
[Why] DPALT detection for B0 PHY has its own set of RDPCSPIPE registers [How] Use RDPCSPIPE registers to detect if DPALT lane is 4 lane Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Hansen <Hansen.Dsouza@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Limit display scaling to up to 4k for DCN 3.1Nikola Cornij
[why] The existing limit was mistakenly bigger than 4k for DCN 3.1 Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Nikola Cornij <nikola.cornij@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Added root clock optimization flagsJake Wang
[Why & How] Added root clock optimization debug flags for future debugging. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Jake Wang <haonan.wang2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Re-arrange FPU code structure for dcn2xQingqing Zhuo
[Why] Current FPU code for DCN2x is located under dml/dcn2x. This is not aligned with DC's general source tree structure. [How] Move FPU code for DCN2x to dml/dcn20. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Skip override for preferred link settings during link trainingGeorge Shen
[Why] Overriding link setting inside override_training_settings result in fallback link settings being ignored. This can potentially cause link training to always fail and consequently result in an infinite loop of link training to occur in dp_verify_link_cap during detection. [How] Since preferred link settings are already considered inside decide_link_settings, skip the check in override_training_settings to avoid infinite link training loops. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: George Shen <george.shen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/i915: Call intel_dp_dump_link_status() for CR failuresVille Syrjälä
I suppose intel_dp_dump_link_status() might be useful for diagnosing link training failures. Hoever we only call from the channel EQ phase currently. Let's call it from the CR phase as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-6-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-10-06drm/i915: Pimp link training debug printsVille Syrjälä
Unify all debug prints during link training to include information on both the encoder and the LTTPR. We unify the format to something like "[ENCODER:1:FOO][LTTPR 1] Something something". Though not sure if those brackets around the dp_phy just make it look like line noise? I'll accept suggestions on better formatting. I'm slightly on the fence about also including the connector, but technically only the DPRX is the SST connector (ie. intel_dp->attached_connector). I suppose you could think of it as the branch device/whatever in the topology, and we're training the link leading to it. So that could argue for its inclusion. But it's all getting a bit long alrady, so not going to do it I think. v2: Keep the connector name in the final passed/failed debug print Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-5-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-10-06drm/i915: Print the DP vswing adjustment requestVille Syrjälä
Print out each DP vswing adjustment request we got from the RX. Could help in diagnosing what's going on during link training. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-4-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-10-06drm/i915: Show LTTPR in the TPS debug printVille Syrjälä
Indicate which LTTPR we're currently attempting to train when we print which training pattern we're using. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-10-06drm/i915: Tweak the DP "max vswing reached?" conditionVille Syrjälä
Currently we consider the max vswing reached when we transmit a the max voltage level, but we don't consider pre-emphasis at all. This kinda matches older DP specs that only had some vague text about transmitting the maximum voltage swing. Latest versions now say something vague about consider the sum of the vswing and pre-emphasis fields in the ADJUST_REQUEST_LANE registers. Very vague, and super confusing especially the fact that it talks about transmitted voltgage swing in the same sentence as it say to look at the requested values. Also glanced at the link CTS spec, and that one seems to have tests that assume contradicting behaviour. Some say to consider just the vswing level we transmit, others say to check for sum of transmitted vswing+preemph being 3. So let's try to take some kind of sane middle ground here. I think what could make sense is only consider max vswing reached if MAX_SWING_REACHED==1 _and_ vswing+preemph==3. That will allow things to go all the way up to vswing 3 + pre-emph 0 or vswing 2 + pre-emph 1, depending on what the maximum supported vswing is. Only considering the sum of vswing+pre-emph doesn't make much sense to me since we could terminate too early if the sink requests eg. vswing 0 + pre-emph 3. And if we'd stick to the current code we could terminate too early of the sink asks for vswing 2 + pre-emph 0 when vswing level 3 is not supported. Side note: I don't really understand why any of this stuff is "specified" at all. There is already a limit of 5 attempts at the same vswing+pre-emph level, and a total limit of 10 attempts. So might as well stick to the same max 5 attempts across the board IMO. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-10-06drm/bridge: dw-hdmi-cec: Make use of the helper function ↵Cai Huoqing
devm_add_action_or_reset() The helper function devm_add_action_or_reset() will internally call devm_add_action(), and if devm_add_action() fails then it will execute the action mentioned and return the error code. So use devm_add_action_or_reset() instead of devm_add_action() to simplify the error handling, reduce the code. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210922125909.215-1-caihuoqing@baidu.com
2021-10-06dma-buf: use new iterator in dma_resv_test_signaledChristian König
This makes the function much simpler since the complex retry logic is now handled elsewhere. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-8-christian.koenig@amd.com
2021-10-06dma-buf: use new iterator in dma_resv_wait_timeoutChristian König
This makes the function much simpler since the complex retry logic is now handled elsewhere. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-7-christian.koenig@amd.com
2021-10-06dma-buf: use new iterator in dma_resv_get_fences v3Christian König
This makes the function much simpler since the complex retry logic is now handled elsewhere. v2: use sizeof(void*) instead v3: fix rebase bug Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-6-christian.koenig@amd.com
2021-10-06dma-buf: use new iterator in dma_resv_copy_fencesChristian König
This makes the function much simpler since the complex retry logic is now handled else where. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-5-christian.koenig@amd.com
2021-10-06dma-buf: add dma_resv_for_each_fence_unlocked v8Christian König
Abstract the complexity of iterating over all the fences in a dma_resv object. The new loop handles the whole RCU and retry dance and returns only fences where we can be sure we grabbed the right one. v2: fix accessing the shared fences while they might be freed, improve kerneldoc, rename _cursor to _iter, add dma_resv_iter_is_exclusive, add dma_resv_iter_begin/end v3: restructor the code, move rcu_read_lock()/unlock() into the iterator, add dma_resv_iter_is_restarted() v4: fix NULL deref when no explicit fence exists, drop superflous rcu_read_lock()/unlock() calls. v5: fix typos in the documentation v6: fix coding error when excl fence is NULL v7: one more logic fix v8: fix index check in dma_resv_iter_is_exclusive() Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v7) Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-2-christian.koenig@amd.com
2021-10-06drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setupTvrtko Ursulin
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa) when rendering is done on Intel dgfx and scanout/composition on Intel igfx. Before this patch the driver was not quite ready for that setup, mainly because it was able to emit a semaphore wait between the two GPUs, which results in deadlocks because semaphore target location in HWSP is neither shared between the two, nor mapped in both GGTT spaces. To fix it the patch adds an additional check to a couple of relevant code paths in order to prevent using semaphores for inter-engine synchronisation when relevant objects are not in the same GGTT space. v2: * Avoid adding rq->i915. (Chris) v3: * Use GGTT which describes the limit more precisely. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113135.768295-1-tvrtko.ursulin@linux.intel.com
2021-10-05drm/edid: Fix crash with zero/invalid EDIDDouglas Anderson
In the commit bac9c2948224 ("drm/edid: Break out reading block 0 of the EDID") I broke out reading the base block of the EDID to its own function. Unfortunately, when I did that I messed up the handling when drm_edid_is_zero() indicated that we had an EDID that was all 0x00 or when we went through 4 loops and didn't get a valid EDID. Specifically I needed to pass the broken EDID to connector_bad_edid() but now I was passing an error-pointer. Let's re-jigger things so we can pass the bad EDID in properly. Fixes: bac9c2948224 ("drm/edid: Break out reading block 0 of the EDID") Reported-by: kernel test robot <oliver.sang@intel.com> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20211004092100.1.Ic90a5ebd44c75db963112be167a03cc96f9fb249@changeid
2021-10-05drm/i915/tc: Delete bogus NULL check in intel_ddi_encoder_destroy()Dan Carpenter
The "digi_port" pointer can't be NULL and we have already dereferenced it so checking for NULL is not necessary. Delete the check. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004103737.GC25015@kili
2021-10-05drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resumeGuchun Chen
In current code, when a PCI error state pci_channel_io_normal is detectd, it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI driver will continue the execution of PCI resume callback report_resume by pci_walk_bridge, and the callback will go into amdgpu_pci_resume finally, where write lock is releasd unconditionally without acquiring such lock first. In this case, a deadlock will happen when other threads start to acquire the read lock. To fix this, add a member in amdgpu_device strucutre to cache pci_channel_state, and only continue the execution in amdgpu_pci_resume when it's pci_channel_io_frozen. Fixes: c9a6b82f45e2 ("drm/amdgpu: Implement DPC recovery") Suggested-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-05drm/amdgpu: print warning and taint kernel if lockup timeout is disabledChristian König
Make sure that we notice this in error reports. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-05drm/amdgpu: revert "Add autodump debugfs node for gpu reset v8"Christian König
This reverts commit 728e7e0cd61899208e924472b9e641dbeb0775c4. Further discussion reveals that this feature is severely broken and needs to be reverted ASAP. GPU reset can never be delayed by userspace even for debugging or otherwise we can run into in kernel deadlocks. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Nirmoy Das <nirmoy.das@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-05drm/amdgpu: init iommu after amdkfd device initYifan Zhang
This patch is to fix clinfo failure in Raven/Picasso: Number of platforms: 1 Platform Profile: FULL_PROFILE Platform Version: OpenCL 2.2 AMD-APP (3364.0) Platform Name: AMD Accelerated Parallel Processing Platform Vendor: Advanced Micro Devices, Inc. Platform Extensions: cl_khr_icd cl_amd_event_callback Platform Name: AMD Accelerated Parallel Processing Number of devices: 0 Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: James Zhu <James.Zhu@amd.com> Tested-by: James Zhu <James.Zhu@amd.com> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-05drm/amdkfd: remove redundant iommu cleanup codeYifan Zhang
kfd_resume doesn't involve iommu operation, remove redundant iommu cleanup code. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: James Zhu <James.Zhu@amd.com> Tested-by: James Zhu <James.Zhu@amd.com> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-05drm/i915: Fix bug in user proto-context creation that leaked contextsMatthew Brost
Set number of engines before attempting to create contexts so the function free_engines can clean up properly. Also check return of alloc_engines for NULL. v2: (Tvrtko) - Send as stand alone patch (John Harrison) - Check for alloc_engines returning NULL v3: (Checkpatch / Tvrtko) - Remove braces around single line if statement Cc: Jason Ekstrand <jason@jlekstrand.net> Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001155825.6762-1-matthew.brost@intel.com
2021-10-04drm/amdgpu/display: fix dependencies for DRM_AMD_DC_SIAlex Deucher
Depends on DRM_AMDGPU_SI and DRM_AMD_DC Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-04drm/amdgpu/gmc9: convert to IP version checkingAlex Deucher
Use IP versions rather than asic_type to differentiate IP version specific features. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-04drm/amd/display: Prevent using DMUB rptr that is out-of-boundsWyatt Wood
[Why] Running into bugchecks during stress test where rptr is 0xFFFFFFFF. Typically this is caused by a hard hang, and can come from HW outside of DCN. [How] To prevent bugchecks when writing the DMUB rptr, fist check that the rptr is valid. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Wyatt Wood <wyatt.wood@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-04drm/amdgpu/display: fold DRM_AMD_DC_DCN201 into DRM_AMD_DC_DCNAlex Deucher
No need for a separate kconfig option at this point. Reviewed-by: Zhan Liu <zhan.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-04drm/amdgpu: remove some repeated includingsGuo Zhengkui
Remove two repeated includings in line 46 and 47. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-04drm/amdgpu: During s0ix don't wait to signal GFXOFFLijo Lazar
In the rare event when GFX IP suspend coincides with a s0ix entry, don't schedule a delayed work, instead signal PMFW immediately to allow GFXOFF entry. GFXOFF is a prerequisite for s0ix entry. PMFW needs to be signaled about GFXOFF status before amd-pmc module passes OS HINT to PMFW telling that everything is ready for a safe s0ix entry. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1712 Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Mario Limonciello <mario.limonciell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 06:07:44 +0000