aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2024-04-08drm/i915/cdclk: Fix voltage_level programming edge caseVille Syrjälä1-10/+27
Currently we only consider the relationship of the old and new CDCLK frequencies when determining whether to do the repgramming from intel_set_cdclk_pre_plane_update() or intel_set_cdclk_post_plane_update(). It is technically possible to have a situation where the CDCLK frequency is decreasing, but the voltage_level is increasing due a DDI port. In this case we should bump the voltage level already in intel_set_cdclk_pre_plane_update() (so that the voltage_level will have been increased by the time the port gets enabled), while leaving the CDCLK frequency unchanged (as active planes/etc. may still depend on it). We can then reduce the CDCLK frequency to its final value from intel_set_cdclk_post_plane_update(). In order to handle that correctly we shall construct a suitable amalgam of the old and new cdclk states in intel_set_cdclk_pre_plane_update(). And we can simply call intel_set_cdclk() unconditionally in both places as it will not do anything if nothing actually changes vs. the current hw state. v2: Handle cdclk_state->disable_pipes v3: Only synchronize the cd2x update against the pipe's vblank when the cdclk frequency is changing during the current commit phase (Gustavo) Cc: [email protected] Cc: Gustavo Sousa <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 34d127e2bdef73a923aa0dcd95cbc3257ad5af52) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/i915/cdclk: Fix CDCLK programming order when pipes are activeVille Syrjälä2-2/+8
Currently we always reprogram CDCLK from the intel_set_cdclk_pre_plane_update() when using squash/crawl. The code only works correctly for the cd2x update or full modeset cases, and it was simply never updated to deal with squash/crawl. If the CDCLK frequency is increasing we must reprogram it before we do anything else that might depend on the new higher frequency, and conversely we must not decrease the frequency until everything that might still depend on the old higher frequency has been dealt with. Since cdclk_state->pipe is only relevant when doing a cd2x update we can't use it to determine the correct sequence during squash/crawl. To that end introduce cdclk_state->disable_pipes which simply indicates that we must perform the update while the pipes are disable (ie. during intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new CDCLK frequency comparsiong as for cd2x updates. The only remaining problem case is when the voltage_level needs to increase due to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are being disabled). The current approach will not bump the voltage level up until after the port has already been enabled, which is too late. But we'll take care of that case separately. v2: Don't break the "must disable pipes case" v3: Keep the on stack 'pipe' for future use Cc: [email protected] Fixes: d62686ba3b54 ("drm/i915/adl_p: CDCLK crawl support for ADL") Reviewed-by: Uma Shankar <[email protected]> Reviewed-by: Gustavo Sousa <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3aecee90ac12a351905f12dda7643d5b0676d6ca) Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-08drm/msm/dp: Account for the timeout in wait_hpd_asserted() callbackDouglas Anderson3-6/+9
The DP wait_hpd_asserted() callback is passed a timeout which indicates how long we should wait for HPD. This timeout was being ignored in the MSM DP implementation and instead a hardcoded 500 ms timeout was used. Fix it to use the proper timeout. As part of this we move the hardcoded 500 ms number into the AUX transfer function, which isn't given a timeout. The wait in the AUX transfer function will be removed in a future commit. Fixes: e2969ee30252 ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/583128/ Link: https://lore.kernel.org/r/20240315143621.v2.2.I7758d18a1773821fa39c034b16a12ef3f18a51ee@changeid Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connectedDouglas Anderson3-0/+25
As documented in the description of the transfer() function of "struct drm_dp_aux", the transfer() function can be called at any time regardless of the state of the DP port. Specifically if the kernel has the DP AUX character device enabled and userspace accesses "/dev/drm_dp_auxN" directly then the AUX transfer function will be called regardless of whether a DP device is connected. For eDP panels we have a special rule where we wait (with a 5 second timeout) for HPD to go high. This rule was important before all panels drivers were converted to call wait_hpd_asserted() and actually can be removed in a future commit. For external DP devices we never checked for HPD. That means that trying to access the DP AUX character device (AKA `hexdump -C /dev/drm_dp_auxN`) would very, very slowly timeout. Specifically on my system: $ time hexdump -C /dev/drm_dp_aux0 hexdump: /dev/drm_dp_aux0: Connection timed out real 0m8.200s We want access to the drm_dp_auxN character device to fail faster than 8 seconds when no DP cable is plugged in. Let's add a test to make transfers fail right away if a device isn't plugged in. Rather than testing the HPD line directly, we have the dp_display module tell us when AUX transfers should be enabled so we can handle cases where HPD is signaled out of band like with Type C. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/583127/ Link: https://lore.kernel.org/r/20240315143621.v2.1.I16aff881c9fe82b5e0fc06ca312da017aa7b5b3e@changeid Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dpu: add current resource allocation to dumped stateDmitry Baryshkov4-0/+78
Provide atomic_print_state callback to the DPU's private object. This way the debugfs/dri/0/state will also include RM's internal state. Example output (RB5 board, HDMI and writeback encoder enabled) resource mapping: pingpong=31 36 # # # # - - - - - mixer=31 36 # # # # - ctl=# # 31 36 # # dspp=# # # # dsc=# # # # - - cdm=# Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/579648/ Link: https://lore.kernel.org/r/[email protected]
2024-04-08drm/msm/dp: allow voltage swing / pre emphasis of 3Dmitry Baryshkov3-27/+15
Both dp_link_adjust_levels() and dp_ctrl_update_vx_px() limit swing and pre-emphasis to 2, while the real maximum value for the sum of the voltage swing and pre-emphasis is 3. Fix the DP code to remove this limitation. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Kuogee Hsieh <[email protected]> Tested-by: Kuogee Hsieh <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/577006/ Link: https://lore.kernel.org/r/[email protected]
2024-04-08drm/msm/dp: Remove now unused connector_type from descBjorn Andersson1-31/+17
Now that the connector_type is dynamically determined, the connector_type of the struct msm_dp_desc is unused. Clean it up. Remaining duplicate entries are squashed. Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/588020/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dp: Add support for the X1E80100Abel Vesa1-0/+9
Add the X1E80100 DP descs and compatible. This platform will be using a single compatible for both eDP and DP mode. The actual mode will be set based on the presence of the panel node in DT. Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Abel Vesa <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/584536/ Link: https://lore.kernel.org/r/20240324-x1e80100-display-refactor-connector-v4-2-e0ebaea66a78@linaro.org Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm/msm/dp: Add support for determining the eDP/DP mode from DTAbel Vesa1-1/+28
Instead of relying on different compatibles for eDP and DP, lookup the panel node in devicetree to figure out the connector type and then pass on that information to the PHY. External DP doesn't have a panel described in DT, therefore, assume it's eDP if panel node is present. Signed-off-by: Abel Vesa <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/584534/ Link: https://lore.kernel.org/r/20240324-x1e80100-display-refactor-connector-v4-1-e0ebaea66a78@linaro.org Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08Merge tag 'phy_dp_modes_6.10' into msm-next-lumagDmitry Baryshkov336-2903/+129388
Merge DisplayPort subnode API in order to allow DisplayPort driver to configure the PHYs either to the DP or eDP mode, depending on hardware configuration. Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-08drm: bridge: cdns-mhdp8546: Fix possible null pointer dereferenceAleksandr Mishin1-0/+3
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/client: Fully protect modes[] with dev->mode_config.mutexVille Syrjälä1-1/+2
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]>
2024-04-08drm/xe: Label RING_CONTEXT_CONTROL as maskedAshutosh Dixit2-4/+3
RING_CONTEXT_CONTROL is a masked register. v2: Also clean up setting register value (Lucas) Reviewed-by: Matt Roper <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe: Remove debug message from migrate_clear()José Roberto de Souza1-3/+0
This messages is printed a lot and from my understanding it do not bring any value, so here dropping it. Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/display: Fix double mutex initializationLucas De Marchi1-5/+0
All of these mutexes are already initialized by the display side since commit 3fef3e6ff86a ("drm/i915: move display mutex inits to display code"), so the xe shouldn´t initialize them. Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: Jani Nikula <[email protected]> Cc: Arun R Murthy <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-08drm/xe/vf: Mark supported firmwares as preloadedMichal Wajdeczko3-3/+19
On current platforms supported firmwares, like GuC and HuC, must be loaded by the PF driver. Mark those firmwares as 'preloaded' so we will skip fetching and loading them on the VF drivers but still correctly report them as 'running'. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/vf: Don't try to read legacy GuC MMIO notification if VFMichal Wajdeczko1-0/+3
Legacy SOFT_SCRATCH registers are not accessible from the VF. Any G2H notification posted there will be handled by the PF driver. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/vf: Don't try to program MOCS if VFMichal Wajdeczko1-0/+3
VFs drivers don't have access to MOCS registers. It is a PF driver responsibility to program MOCS according to the HW team guidelines. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/vf: Don't emit access to Global HWSP if VFMichal Wajdeczko1-4/+7
VFs can't access Global HWSP, don't emit questionable MI_FLUSH_DW while processing a migration job. Bspec: 52398 Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915: Update pipes in reverse order for bigjoinerVille Syrjälä2-3/+19
With bigjoiner the master crtc is the one that will send out the uapi event/etc. We want that to happen after all the slaves are done, so let's try to do the commits in reverse order so that the master comes last. Even worse, the modeset helper will simply complete the commit on the slave pipe immediately as it consider the crtc to be inactive (it can't see our crtc_state->hw.active/etc.). With regular sync updates this generally doesn't matter all that much as the slave pipe should typically finish its work during the same frame as the master pipe. However in case the slave pipe's commit slips into the next frame we end up in a bit of trouble. This is most visible with either async flips (currently disabled with bigjoiner exactly for this reason), and DSB gamma updates. With DSB the problem happens because the DSB itself will wait until the next start vblank before starting to execute. So if the master pipe already finished its commit and the DSB on the slave pipe is still waiting for the next vblank we will assume the DSB as gotten stuck and terminate it. Reversing the commit order should ameliarate this for the most part as the master pipe is guaranteed to start its commit after the slave pipe started. The one thing that can still screw us over is the fact that we aren't necessarily going to commit the pipes in the reverse order as the actual order is dictated by the DDB overlap avoidance. But that can only happen while other pipes are being enabled/disabled, and so in the normal steady state we should be safe. The full fix will involve making the commit machinery aware of the slave pipes and not finish their commits prematurely. But that will involve a bit more work than this. And this commit order reversal will still be beneficial to avoid userspace getting an -EBUSY from the following page flip if the second pipe's commit does stretch into the next frame. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Arun R Murthy <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]>
2024-04-08drm/i915: Fix intel_modeset_pipe_config_late() for bigjoinerVille Syrjälä1-14/+32
Currently intel_modeset_pipe_config_late() is called after the bigjoiner state copy, and it will actually not do anything for bigjoiner slaves. This can lead to a mismatched state between the master and slave. The two things that we do in the encoder .compute_config_late() hook are mst master transcoder and port sync master transcoder elections. So if either of either MST or port sync is combined with bigjoiner then we can see the mismatch. Currently this problem is more or less theoretical; MST+bigjoiner has not been implemented yet, and port sync+bigjoiner would require a tiled display with >5k tiles (or a very high dotclock per tile). Although we do have kms_tiled_display in igt which can fake a tiled display, and we can now force bigjoiner via debugfs, so it is possible to trigger this if you try hard enough. Reorder the code such that intel_modeset_pipe_config_late() will be called before the bigjoiner state copy happens so that both pipes will end up with the same state. Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/vrr: Disable VRR when using bigjoinerVille Syrjälä1-0/+7
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change switch between non-VRR and VRR timings generators on the fly, or even when sending the push to the transcoder. For now just disable VRR when bigjoiner is needed. Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2024-04-08drm/i915: Disable live M/N updates when using bigjoinerVille Syrjälä1-1/+5
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change the timings at the same time. For now just disable live M/N updates when bigjoiner is needed. Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2024-04-08drm/i915: Disable port sync when bigjoiner is usedVille Syrjälä1-0/+5
The current modeset sequence can't handle port sync and bigjoiner at the same time. Refuse port sync when bigjoiner is needed, at least until we fix the modeset sequence. v2: Add a FIXME (Vandite) Cc: [email protected] Tested-by: Vidya Srinivas <[email protected]> Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]>
2024-04-08drm/i915/psr: Disable PSR when bigjoiner is usedVille Syrjälä1-0/+11
Bigjoiner seem to be causing all kinds of grief to the PSR code currently. I don't believe there is any hardware issue but the code simply not handling this correctly. For now just disable PSR when bigjoiner is needed. Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Arun R Murthy <[email protected]> Acked-by: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
2024-04-08drm/xe/guc: Initialize GuC ID manager soonerMichal Wajdeczko1-9/+5
The GuC submission cleanup code may depend on the GuC ID manager, thus we can't initialize it after registering a submission cleanup action, as reverse cleanup sequence will destroy GuC ID manager prior to a call to guc_submit_fini(). Move GuC ID manager initialization up, right after managed mutex initialization, to have it available during guc_submit_fini(). Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/guc: Use drm_device-managed version of mutex_init()Michal Wajdeczko1-2/+4
This is safer approach and will help resolve a cleanup ordering conflict related to the GuC ID manager. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/xe/display: clean up compat i915_vgpu.hJani Nikula1-26/+0
There's a bunch of unnecessary stuff not needed by display code. Remove. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e583679c00aae8fec78f988fa857cfc724a9fa2d.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/xe/display: remove compat i915_gem.hJani Nikula2-10/+0
It's only there for GEM_BUG_ON(), but the display code no longer uses it. Good riddance. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/8de7815d9c80125b86e0b85a1af80d4f8686eef6.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/xe/display: clean up a lot of cruft from compat i915_drv.hJani Nikula1-32/+0
There's a bunch of unused cruft. Just throw away. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d773f26cced0b376a30a6cb1e38c9581b469d8cf.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/i915: move i915_fixed.h to display/intel_fixed.hJani Nikula3-7/+1
All the users are in display, move the fixed point header under display. We could also consider making these more general purpose things, but that takes a bunch more effort. This allows the immediate cleanup of xe compat i915_fixed.h. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/320c451e116c7807e544a50c67ba79b087a4f218.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/i915/dmc: define firmware URL locallyJani Nikula3-13/+3
Avoid the dependency on intel_uc_fw.h, and allow removal of xe compat intel_uc_fw.h. If there needs to be duplication of the URL, at least have the duplication in a sensible way. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/15935837a0c15f861bb2a688cc53514f47153ef3.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/i915: use IS_JASPERLAKE()/IS_ELKHARTLAKE() instead of IS_PLATFORM()Jani Nikula1-2/+2
Avoid direct IS_PLATFORM() usage when we have the platform helpers. Cc: Lucas De Marchi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7ca5fabac6a6f5ac8e102b84d1e28502e79296f0.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-08drm/i915/psr: Panel replay has to be enabled before link trainingJouni Högander4-3/+23
Panel replay has to be enabled on sink side before link training. Take this into account in fastset check and in initial fastset check. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Unify panel replay enable/disable sinkJouni Högander3-23/+50
Unify enabling and disabling of psr/panel replay for a sink. Modify intel_psr_enable_sink accordingly and use it for both cases. v3: - move psr2_su_region_et_valid to be check for PSR2 only v2: - enable panel replay for sink before link training - write ALPM_CONFIG only for PSR - add DP_PSR_CRC_VERIFICATION only for PSR - take care of disable sink as well Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Do not write registers/bits not applicable for panel replayJouni Högander1-25/+45
Bspec is saying this mask register: Only PSR_MASK[Mask FBC modify] and PSR_MASK[Mask Hotplug] are used in panel replay mode. Status register: Only SRD_STATUS[SRD state] field is used in panel replay mode. Due to this stop writing and reading registers and bits not used by panel replay if panel replay is used. Bspec: 53370, 68920 v2: - use intel_dp_is_edp with PSR_MASK register - handle LunarLake as well - hanle ALPM configuration as well Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Check possible errors for panel replay as wellJouni Högander1-5/+16
On HPD interrupt we want to check if the reason for HPD was some panel replay error detected by monitor/panel. This is already done for PSR. We want to do this for panel replay as well. Modify intel_psr_short_pulse to support panel replay as well. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Do not update phy power state in case of non-eDP panel replayJouni Högander1-4/+8
Currently panel replay is supporting only main link on mode -> Do not update phy power state for non-eDP panel replay. Bspec: 53370 v2: use intel_dp_is_edp to differentiate Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Intel_psr_pause/resume needs to support panel replayJouni Högander1-2/+2
Currently intel_psr_pause and intel_psr_resume do nothing in case of panel replay. Change them to perform pause and return also in case of panel replay. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Set intel_crtc_state->has_psr on panel replay as wellJouni Högander1-5/+6
Current code is setting only intel_crtc_state->has_panel_replay in panel replay case. There are lots of stuff behind intel_crtc_state->has_psr that is needed for panel replay as well. Instead of converting each check to has_psr || has_panel_replay set has_psr in case of panel replay as well. Code can then differentiate between psr and panel replay by using intel_crtc_state->has_panel_replay. Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-08drm/i915/psr: Add some documentation of variables used in psr codeJouni Högander1-0/+16
We are adding more boolean variable into intel_psr and intel_crtc_state structs. Add some documentation about these for sake of clarity. v2: Modify has_psr + has_panel_replay to mean panel replay Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Animesh Manna <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-07drm-panel: If drm_panel_dp_aux_backlight() fails, don't fail panel probeDouglas Anderson2-3/+14
If we're using the AUX channel for eDP backlight and it fails to probe for some reason, let's _not_ fail the panel probe. At least one case where we could fail to init the backlight is because of a dead or physically missing panel. As talked about in detail in the earlier patch in this series, ("drm/panel-edp: If we fail to powerup/get EDID, use conservative timings"), this can cause the entire system's display pipeline to fail to come up and that's non-ideal. If we fail to init the backlight for some transitory reason, we should dig in and see if there's a way to fix this (perhaps retries?). Even in that case, though, having a panel whose backlight is stuck at 100% (the default, at least in the panel Samsung ATNA33XC20 I tested) is better than having no panel at all. Reviewed-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.3.I552e8af0ddb1691cc0fe5d27ea3d8020e36f7006@changeid
2024-04-07drm/panel-edp: If we fail to powerup/get EDID, use conservative timingsDouglas Anderson1-5/+7
If at boot we fail to power up the eDP panel (most often happens if the eDP panel never asserts HPD to us) or if we are unable to read the EDID at bootup to figure out the panel's ID then let's use the conservative eDP panel powerup/powerdown timings but _not_ fail the probe. It might seem strange to _not_ fail the probe in this case since we were unable to powerup the panel and confirm it's there. However, there is a reason to do this. Specifically, if we fail to probe the panel then it really throws the whole display pipeline for loop. Most DRM subsystems are written so that they wait until all components (including the panel) have probed before they set everything up. When the panel doesn't come up then this never happens. As a side effect of not setting everything up then other display adapters don't get initialized. As a practical example, I can see that if I open up a sc7180-trogdor based Chromebook that's using the generic "edp-panel" and unplug the eDP panel that it causes the _external_ DP monitor not to function. This is obviously bad because it means that a device with a dead eDP panel becomes e-waste when it could instead still be given useful life with an external display. NOTES: - When we fail to probe like this, boot is a bit slow because we try several times to power the panel up. This doesn't feel horrible because it'll eventually work and the retries are known to help bring some panels up. - In the case where we hit the condition of failing to power up, the display will likely _never_ have a chance to work again until reboot. Once the panel-edp pm_runtime resume function fails it doesn't ever seem to retry. This is probably for the best given that we don't have any real timing/modes. eDP isn't expected to be "hotplugged" so this makes some sense. - It turns out that this makes panel-edp behave more similarly for users of the generic "edp-panel" compatible string and the old fixed panel compatible string. With the old fixed panel compatible string we don't talk to the panel during probe so we'd actually behave much the same way that we'll now behave for the generic "edp-panel". Reviewed-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.2.Ia7a55a9657b0b6aa4644fd497a0bc595a771258c@changeid
2024-04-07drm/panel-edp: Abstract out function to set conservative timingsDouglas Anderson1-20/+20
If we're using the generic "edp-panel" compatible string and we fail to detect an eDP panel then we fall back to conservative timings for powering up and powering down the panel. Abstract out the function for setting these timings so it can be used in future patches. No functional change expected--just code movement. Reviewed-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.1.I659b2517d9f619d09e804e071591ecab76335dfb@changeid
2024-04-06drm/i915: Fix i915_display_info output when connectors are not activeVille Syrjälä1-11/+3
Currently intel_connector_info(), which prints the per-connector output for i915_display_info, just bails out early if the connector doesn't have a current encoder. That leads to very confusing output where some of your connected (and properly detected) outputs appear to have no enumerated modes. Get rid of the encoder stuff and just rely on the connector itself so that the output is always consistent. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Suraj Kandpal <[email protected]>
2024-04-05drm/msm/adreno: Set highest_bank_bit for A619Luca Weiss1-0/+4
The default highest_bank_bit of 15 didn't seem to cause issues so far but downstream defines it to be 14. But similar to [0] leaving it on 14 (or 15 for that matter) causes some corruption issues with some resolutions with DisplayPort, like 1920x1200. So set it to 13 for now so that there's no screen corruption. [0] commit 6a0dbcd20ef2 ("drm/msm/a6xx: set highest_bank_bit to 13 for a610") Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support") Signed-off-by: Luca Weiss <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/585215/ Signed-off-by: Rob Clark <[email protected]>
2024-04-05drm/msm: fix the `CRASHDUMP_READ` target of `a6xx_get_shader_block()`Miguel Ojeda1-1/+1
Clang 14 in an (essentially) defconfig arm64 build for next-20240326 reports [1]: drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error: variable 'out' set but not used [-Werror,-Wunused-but-set-variable] The variable `out` in these functions is meant to compute the `target` of `CRASHDUMP_READ()`, but in this case only the initial value (`dumper->iova + A6XX_CD_DATA_OFFSET`) was being passed. Thus use `out` as it was intended by Connor [2]. There was an alternative patch at [3] that removed the variable altogether, but that would only use the initial value. Fixes: 64d6255650d4 ("drm/msm: More fully implement devcoredump for a7xx") Closes: https://lore.kernel.org/lkml/CANiq72mjc5t4n25SQvYSrOEhxxpXYPZ4pPzneSJHEnc3qApu2Q@mail.gmail.com/ [1] Link: https://lore.kernel.org/lkml/CACu1E7HhCKMJd6fixZSPiNAz6ekoZnkMTHTcLFVmbZ-9VoLxKg@mail.gmail.com/ [2] Link: https://lore.kernel.org/lkml/[email protected]/ [3] Signed-off-by: Miguel Ojeda <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/584955/ Signed-off-by: Rob Clark <[email protected]>
2024-04-05drm/xe: Drop xe_vm_assert_held() macro definition from xe_bo.hMichal Wajdeczko1-8/+0
It is already defined in xe_vm.h and shouldn't be duplicated. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/xe: Move PTE/PDE bit definitions to proper headerMichal Wajdeczko6-21/+25
We already have dedicated header for GGTT/PPGTT definitions. It's also cleaner to separate them from implementation macros. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Matt Roper <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-05drm/i915/guc: Fix the fix for reset lock confusionJohn Harrison2-14/+13
The previous fix for the circlular lock splat about the busyness worker wasn't quite complete. Even though the reset-in-progress flag is cleared at the start of intel_uc_reset_finish, the entire function is still inside the reset mutex lock. Not sure why the patch appeared to fix the issue both locally and in CI. However, it is now back again. There is a further complication that the wedge code path within intel_gt_reset() jumps around so much that it results in nested reset_prepare/_finish calls. That is, the call sequence is: intel_gt_reset | reset_prepare | __intel_gt_set_wedged | | reset_prepare | | reset_finish | reset_finish The nested finish means that even if the clear of the in-progress flag was moved to the end of _finish, it would still be clear for the entire second call. Surprisingly, this does not seem to be causing any other problems at present. As an aside, a wedge on fini does not call the finish functions at all. The reset_in_progress flag is left set (twice). So instead of trying to cancel the worker anywhere at all in the reset path, just add a cancel to intel_guc_submission_fini instead. Note that it is not a problem if the worker is still active during a reset. Either it will run before the reset path starts locking things and will simply block the reset code for a tiny amount of time. Or it will run after the locks have been acquired and will early exit due to the try-lock. Also, do not use the reset-in-progress flag to decide whether a synchronous cancel is safe (from a lockdep perspective) or not. Instead, use the actual reset mutex state (both the genuine one and the custom rolled BACKOFF one). Fixes: 0e00a8814eec ("drm/i915/guc: Avoid circular locking issue on busyness flush") Signed-off-by: John Harrison <[email protected]> Cc: Zhanjun Dong <[email protected]> Cc: John Harrison <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Nirmoy Das <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Umesh Nerlige Ramappa <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Matt Roper <[email protected]> Cc: Jonathan Cavitt <[email protected]> Cc: Prathap Kumar Valsan <[email protected]> Cc: Alan Previn <[email protected]> Cc: Madhumitha Tolakanahalli Pradeep <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Ashutosh Dixit <[email protected]> Cc: Dnyaneshwar Bhadane <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.