aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2021-10-06drm/amd/display: Deadlock/HPD Status/Crash Bug FixJude Shih1-26/+44
[why] 1. HPD callback function has deadlock problem 2. HPD status is not assigned 3. There is crash due to null pointer 4. link_enc is NULL in DPIA case [How] 1. Fix deadlock problem by moving it out of the drm_modeset_lock 2. Assign HPD status from the notify of outbox from dmub FW 3. Fix the crash by checking if pin or enc exists 4. Use link_enc_cfg_get_link_enc_used_by_link to dynamically assign Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jude Shih <shenshih@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Fix for access for ddc pin and aux engine.Meenakshikumar Somasundaram4-10/+10
[Why & How] 1. Remove unnecessary dummy interrupt source for USB4 HPD & HPD RX 2. Adjust parameter for DPCD writing of link training process of DPIA link 3. Adjust specific AUX defer delay for DPIA link 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: Add debug flags for USB4 DP link training.Jimmy Kizito4-1/+18
[Why & How] Additional debug flags that can be useful for testing USB4 DP link training. Add flags: - 0x2 : Forces USB4 DP link to non-LTTPR mode - 0x4 : Extends status read intervals to about 60s. Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> 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 DIG_HPD_SELECT for USB4 display endpoints.Jimmy Kizito1-3/+9
[Why] DIB_BE_CNTL<i>.DIG_HPD_SELECT selects the HPD block being used by the display endpoint assigned to DIG<i>. In the case of USB4 display endpoints, no physical HPD block is assigned. [How] Setting DIB_BE_CNTL<i>.DIG_HPD_SELECT to 5 indicates that no HPD is assigned to a display endpoint. Firmware decrements the HPD_SELECT value by 1 before writing it to the register. Reviewed-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@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 SET_CONFIG processing with DMUBJude Shih5-20/+94
[Why] To process SET_CONFIG transactions with DMUB using inbox1 and outbox1 mail boxes. [How] 1) DMUB posts SET_CONFIG reply as an Outbox1 message of type DMUB_OUT_CMD__SET_CONFIG_REPLY. 2) The dmub async to sync mechanism for AUX is modified to accommodate SET_CONFIG commands for both command issue and reply code paths. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Wayne Lin <Wayne.Lin@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jude Shih <shenshih@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-10-06drm/amd/display: Add dpia debug optionsMeenakshikumar Somasundaram5-3/+14
[Why & How] To add support for dpia debug options. 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: Read USB4 DP tunneling data from DPCD.Jimmy Kizito4-2/+67
[Why] We requires information from DPCD in order to identify USB4 DP tunneling targets. [How] Add USB4 DP tunneling fields to DPCD struct and populate these fields during sink detection. 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 SET_CONFIG processing with DMUBMeenakshikumar Somasundaram8-4/+149
[Why] To process SET_CONFIG transactions with DMUB using inbox1 and outbox1 mail boxes. [How] 1) Added inbox1 DPIA command subtype DMUB_CMD__DPIA_SET_CONFIG_ACCESS to issue SET_CONFIG command to DMUB in dc_process_dmub_set_config_async(). DMUB processes the command with DPIA sends reply back immediately or in an outbox1 message triggering an outbox1 interrupt to driver. 2) DMUB posts SET_CONFIG reply as an Outbox1 message of type DMUB_OUT_CMD__SET_CONFIG_REPLY. 3) The dmub async to sync mechanism for AUX is modified to accommodate SET_CONFIG commands for both command issue and reply code paths. 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: Implement end of training for hop in DPIA display pathJimmy Kizito2-5/+83
[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 Kizito1-3/+246
[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 Kizito2-7/+457
[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 Kizito2-4/+43
[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 Kizito4-17/+120
[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 Kizito2-2/+8
[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 Kizito1-0/+7
[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 Kizito5-1/+81
[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 Kizito3-7/+182
[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 Kizito2-0/+3
[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 Somasundaram5-0/+45
[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 Somasundaram8-5/+120
[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 Kizito3-0/+80
[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šák2-3/+4
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) Ma1-2/+2
[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 Kizito1-3/+3
[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) Ma6-129/+58
[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 Cyr1-1/+1
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 Koo1-2/+2
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 DPALTHansen2-1/+35
[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 Cornij1-1/+1
[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 Wang1-0/+18
[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 Zhuo7-10/+10
[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 Shen1-6/+0
[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ä1-2/+4
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ä1-61/+108
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ä1-0/+27
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ä3-5/+9
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ä1-3/+19
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/lontium-lt9611uxc: fix provided connector suportDmitry Baryshkov1-3/+6
- set DRM_CONNECTOR_POLL_HPD as the connector will generate hotplug events on its own - do not call drm_kms_helper_hotplug_event() unless mode_config.funcs pointer is not NULL to remove possible kernel oops. Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210708230329.395976-1-dmitry.baryshkov@linaro.org
2021-10-06drm/bridge: dw-hdmi-cec: Make use of the helper function devm_add_action_or_reset()Cai Huoqing1-4/+2
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-06drm/nouveau/debugfs: fix file release memory leakYang Yingliang1-0/+1
When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 6e9fc177399f ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-2-yangyingliang@huawei.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/nouveau/kms/nv50-: fix file release memory leakYang Yingliang1-0/+1
When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-1-yangyingliang@huawei.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/nouveau: avoid a use-after-free when BO init failsJeremy Cline1-3/+1
nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm_bo_init() invokes the provided destructor which should de-initialize and free the memory. Thus, when nouveau_bo_init() returns an error the gem object has already been released and the memory freed by nouveau_bo_del_ttm(). Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Jeremy Cline <jcline@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201203000220.18238-1-jcline@redhat.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/panel: abt-y030xx067a: yellow tint fixChristophe Branchereau1-2/+2
The previous parameters caused an unbalanced yellow tint. Fixes: 7467389bdafb ("drm/panel: Add ABT Y030XX067A 3.0" 320x480 panel") Signed-off-by: Christophe Branchereau <cbranchereau@gmail.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> [Paul: Add Fixes: tag, and fix case and punctuation in commit message] Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210914092716.2370039-1-cbranchereau@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/nouveau/fifo/ga102: initialise chid on return from channel creationBen Skeggs1-0/+3
Turns out caller isn't zero-initialised after-all. Fixes: 49b2dfc08182 ("drm/nouveau/ga102-: support ttm buffer moves via copy engine") Reported-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921090735.247236-1-skeggsb@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/rockchip: Update crtc fixup to account for fractional clk changeChris Morgan1-14/+12
After commit 928f9e268611 ("clk: fractional-divider: Hide clk_fractional_divider_ops from wide audience") was merged it appears that the DSI panel on my Odroid Go Advance stopped working. Upon closer examination of the problem, it looks like it was the fixup in the rockchip_drm_vop.c file was causing the issue. The changes made to the clk driver appear to change some assumptions made in the fixup. After debugging the working 5.14 kernel and the no-longer working 5.15 kernel, it looks like this was broken all along but still worked, whereas after the fractional clock change it stopped working despite the issue (it went from sort-of broken to very broken). In the 5.14 kernel the dclk_vopb_frac was being requested to be set to 17000999 on my board. The clock driver was taking the value of the parent clock and attempting to divide the requested value from it (17000000/17000999 = 0), then subtracting 1 from it (making it -1), and running it through fls_long to get 64. It would then subtract the value of fd->mwidth from it to get 48, and then bit shift 17000999 to the left by 48, coming up with a very large number of 7649082492112076800. This resulted in a numerator of 65535 and a denominator of 1 from the clk driver. The driver seemingly would try again and get a correct 1:1 value later, and then move on. Output from my 5.14 kernel (with some printfs for good measure): [ 2.830066] rockchip-drm display-subsystem: bound ff460000.vop (ops vop_component_ops) [ 2.839431] rockchip-drm display-subsystem: bound ff450000.dsi (ops dw_mipi_dsi_rockchip_ops) [ 2.855980] Clock is dclk_vopb_frac [ 2.856004] Scale 64, Rate 7649082492112076800, Oldrate 17000999, Parent Rate 17000000, Best Numerator 65535, Best Denominator 1, fd->mwidth 16 [ 2.903529] Clock is dclk_vopb_frac [ 2.903556] Scale 0, Rate 17000000, Oldrate 17000000, Parent Rate 17000000, Best Numerator 1, Best Denominator 1, fd->mwidth 16 [ 2.903579] Clock is dclk_vopb_frac [ 2.903583] Scale 0, Rate 17000000, Oldrate 17000000, Parent Rate 17000000, Best Numerator 1, Best Denominator 1, fd->mwidth 16 Contrast this with 5.15 after the clk change where the rate of 17000999 was getting passed and resulted in numerators/denomiators of 17001/ 17000. Output from my 5.15 kernel (with some printfs added for good measure): [ 2.817571] rockchip-drm display-subsystem: bound ff460000.vop (ops vop_component_ops) [ 2.826975] rockchip-drm display-subsystem: bound ff450000.dsi (ops dw_mipi_dsi_rockchip_ops) [ 2.843430] Rate 17000999, Parent Rate 17000000, Best Numerator 17018, Best Denominator 17017 [ 2.891073] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 [ 2.891269] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 [ 2.891281] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 I have tested the change extensively on my Odroid Go Advance (Rockchip RK3326) and it appears to work well. However, this change will affect all Rockchip SoCs that use this driver so I believe further testing is warranted. Please note that without this change I can confirm at least all PX30s with DSI panels will stop working with the 5.15 kernel. Upon advice from Doug Anderson <dianders@chromium.org> it was decided that we would first check if the clock rate can be set exactly as requested, and only if it could not would we then add 999 to it and attempt the process again. This way we can preserve the behavior for clocks that still need it while resolving the specific issue for the PX30 and DSI panels (since it is using a fractional clock). Changes since v2: - Moved fixes to correct location. Changes since v1: - Made the addition of 999 conditional based on whether the clock subsystem can set the actual clock rate as requested. - Updated the notes in the fixup routine to reflect this new behavior. - Added reference to original commit, as this has technically been broken since then however only now is it an issue due to the clock changes. Fixes: 4e7cf74fa3b2 ("clk: fractional-divider: Export approximation algorithm to the CCF users") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210916202907.18394-1-macroalpha82@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/nouveau/ga102-: support ttm buffer moves via copy engineBen Skeggs10-6/+329
We don't currently have any kind of real acceleration on Ampere GPUs, but the TTM memcpy() fallback paths aren't really designed to handle copies between different devices, such as on Optimus systems, and result in a kernel OOPS. A few options were investigated to try and fix this, but didn't work out, and likely would have resulted in a very unpleasant experience for users anyway. This commit adds just enough support for setting up a single channel connected to a copy engine, which the kernel can use to accelerate the buffer copies between devices. Userspace has no access to this incomplete channel support, but it's suitable for TTM's needs. A more complete implementation of host(fifo) for Ampere GPUs is in the works, but the required changes are far too invasive that they would be unsuitable to backport to fix this issue on current kernels. v2: fix GPFIFO length in RAMFC (reported by Karol) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: <stable@vger.kernel.org> # v5.12+ Reviewed-by: Karol Herbst <kherbst@redhat.com> Tested-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916220406.666454-1-skeggsb@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/nouveau/kms/tu102-: delay enabling cursor until after assign_windowsBen Skeggs1-1/+1
Prevent NVD core channel error code 67 occuring and hanging display, managed to reproduce on GA102 while testing suspend/resume scenarios. Required extension of earlier commit to fix interactions with EFI. Fixes: e78b1b545c6c ("drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: <stable@vger.kernel.org> # v5.12+ Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210906005628.11499-2-skeggsb@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/sun4i: dw-hdmi: Fix HDMI PHY clock setupJernej Skrabec3-47/+61
Recent rework, which made HDMI PHY driver a platform device, inadvertely reversed clock setup order. HW is very touchy about it. Proper way is to handle controllers resets and clocks first and HDMI PHYs second. Currently, without this fix, first mode set completely fails (nothing on HDMI monitor) on H3 era PHYs. On H6, it still somehow work. Move HDMI PHY reset & clocks handling to sun8i_hdmi_phy_init() which will assure that code is executed after controllers reset & clocks are handled. Additionally, add sun8i_hdmi_phy_deinit() which will deinit them at controllers driver unload. Tested on A64, H3, H6 and R40. Fixes: 9bf3797796f5 ("drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210915175836.3158839-1-jernej.skrabec@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/vc4: hdmi: Remove unused structMaxime Ripard1-8/+0
Commitc7d30623540b ("drm/vc4: hdmi: Remove unused struct") removed the references to the vc4_hdmi_audio_widgets and vc4_hdmi_audio_routes structures, but not the structures themselves resulting in two warnings. Remove it. Fixes: c7d30623540b ("drm/vc4: hdmi: Remove unused struct") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210819140753.930751-1-maxime@cerno.tech Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2021-10-06drm/kmb: Enable alpha blended second planeEdmund Dea5-15/+87
Enable one additional plane that is alpha blended on top of the primary plane. This also fixes the below warnings when building with -Warray-bounds: drivers/gpu/drm/kmb/kmb_plane.c:135:20: warning: array subscript 3 is above array bounds of 'struct layer_status[1]' [-Warray-bounds] drivers/gpu/drm/kmb/kmb_plane.c:132:20: warning: array subscript 2 is above array bounds of 'struct layer_status[1]' [-Warray-bounds] drivers/gpu/drm/kmb/kmb_plane.c:129:20: warning: array subscript 1 is above array bounds of 'struct layer_status[1]' [-Warray-bounds] v2: corrected previous patch dependecies so it builds Signed-off-by: Edmund Dea <edmund.j.dea@intel.com> Signed-off-by: Anitha Chrisanthus <anitha.chrisanthus@intel.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.kernel.org/project/dri-devel/patch/20210728003126.1425028-13-anitha.chrisanthus@intel.com/ Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.