summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_psr.c
AgeCommit message (Collapse)Author
2022-08-29drm/i915: move dmc to display.dmcJani Nikula
Move display dmc related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7cb91222e099b96b82c74b5f086d50c43459d61b.1661346845.git.jani.nikula@intel.com
2022-07-18drm/i915/psr: Disable PSR before disable pipeJosé Roberto de Souza
The issue here was on for_each_intel_encoder_mask_with_psr() over the new_crtc_state encoder mask, so if the CRTC was being disabled mask would be zero and it would not have any chance to disable PSR. So here doing for_each_intel_encoder_mask_with_psr() over the old_crtc_state encoder mask and then using the new_crtc_state to check if PSR needs to be disabled. Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220714150755.154985-2-jose.souza@intel.com
2022-07-18Revert "drm/i915/display: Ensure PSR gets disabled if no encoders in new state"José Roberto de Souza
This patches fixes a issue but not in the right way as for_each_oldnew_intel_crtc_in_state() will interate over all CRTCs not only the crtc passed as parameter, also this two for_each loops are not necessary and only make code harder to understand. Proper fix will be discussed in the next patch. This reverts commit 75f664903d8672897333b86bb450335ec6486ad5. Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220714150755.154985-1-jose.souza@intel.com
2022-07-12drm/i915/display: Ensure PSR gets disabled if no encoders in new stateJouni Högander
Currently PSR is left enabled when all planes are disabled if there is no attached encoder in new state. This seems to be causing FIFO underruns. Fix this by checking if encoder exists in new crtc state and disable PSR if it doesn't. v2: Unify disable logic with existing Cc: Mika Kahola <mika.kahola@intel.com> Reported-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220711111750.881552-1-jouni.hogander@intel.com
2022-07-01drm/i915/display: clean up commentsTom Rix
spelling changes resoluition -> resolution dont -> don't commmit -> commit Invalidade -> Invalidate Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220701203236.1871668-1-trix@redhat.com
2022-06-09drm/i915/display: Fix handling of enable_psr parameterJosé Roberto de Souza
Commit 3cf050762534 ("drm/i915/bios: Split VBT data into per-panel vs. global parts") cause PSR to be disabled when enable_psr has the default value and there is at least one DP port that do not supports PSR. That was happening because intel_psr_init() is called for every DP port and then enable_psr is globaly set to 0 based on the PSR support of the DP port. Here dropping the enable_psr overwritten and using the VBT PSR value when enable_psr is set as default. Fixes: 3cf050762534 ("drm/i915/bios: Split VBT data into per-panel vs. global parts") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220608203344.513082-1-jose.souza@intel.com
2022-05-27drm/i915/bios: Split VBT data into per-panel vs. global partsVille Syrjälä
Move the panel specific VBT parsing to happen during the output probing stage. Needs to be done because the VBT parsing will need to look at the EDID to determine the correct panel_type on some machines. We split the parsed VBT data (i915->vbt) along the same boundary. For the moment we just hoist all the panel specific stuff into connector->panel.vbt since that seems like the most convenient place for eg. the backlight code. Note that we simply drop the drrs type check from intel_drrs_frontbuffer_update() since that operates on the whole device rather than a specific connector/encoder. But the check was just a micro optimization so removing it doesn't actually mattter for correctness. TODO: Lot's of cleanup to be done in the future. Eg. most of the DSI stuff could probably be eliminated entirely and just parsed on demand during DSI init. v2: Note the intel_drrs_frontbuffer_update() change Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-05-16drm/i915: Ensure damage clip area is within pipe areaJouni Högander
Current update area calculation is not handling situation where e.g. cursor plane is fully or partially outside pipe area. Fix this by checking damage area against pipe_src area using drm_rect_intersect. v2: Set x1 and x2 in damaged_area initialization v3: Move drm_rect_intersect into clip_area_update v4: draw_area -> pipe_src Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5440 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220513142811.779331-3-jouni.hogander@intel.com
2022-05-16drm/i915/psr: Use full update In case of area calculation failsJouni Högander
Currently we have some corner cases where area calculation fails. For these sel fetch area calculation ends up having update area as y1 = 0, y2 = 4. Instead of these values safer option is full update. One of such for example is big fb with offset. We don't have usable offset in psr2_sel_fetch_update. Currently it's open what is the proper way to fix this corner case. Use full update for now. v2: Commit message modified v3: Print out debug info once when area calculation fails v4: Use drm_info_once v5: pipeA -> "pipe %c", pipe_name(crtc-pipe) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220513142811.779331-2-jouni.hogander@intel.com
2022-04-19drm/i915/display/psr: Clear more PSR state during disableJosé Roberto de Souza
After commit 805f04d42a6b ("drm/i915/display/psr: Use continuos full frame to handle frontbuffer invalidations") was merged we started to get some drm_WARN_ON(&dev_priv->drm, !(tmp & PSR2_MAN_TRK_CTL_ENABLE)) in tests that are executed in pipe B. This is probably due psr2_sel_fetch_cff_enabled being left set during PSR disable in the pipe A, so the PSR2_MAN_TRK_CTL write in intel_psr2_program_trans_man_trk_ctl() is skipped in pipe B and then we get the warning when actually enabling PSR after planes programing. We don't get such warnings when running tests in pipe A because PSR2_MAN_TRK_CTL is only cleared when enabling PSR2 with hardware tracking. Was not able to reproduce this issue but cleaning the PSR state disable will not harm anything at all. Fixes: 805f04d42a6b ("drm/i915/display/psr: Use continuos full frame to handle frontbuffer invalidations") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5634 Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414151118.21980-2-jose.souza@intel.com
2022-04-19drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in ↵José Roberto de Souza
intel_psr2_config_valid() fails If any of the PSR2 checks after intel_psr2_sel_fetch_config_valid() fails, enable_psr2_sel_fetch will be kept enabled causing problems in the functions that only checks for it and not for has_psr2. So here moving the check that do not depend on enable_psr2_sel_fetch and for the remaning ones jumping to a section that unset enable_psr2_sel_fetch in case of failure to support PSR2. Fixes: 6e43e276b8c9 ("drm/i915: Initial implementation of PSR2 selective fetch") Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414151118.21980-1-jose.souza@intel.com
2022-04-06drm/i915/display/psr: Use continuos full frame to handle frontbuffer ↵José Roberto de Souza
invalidations Instead of exit PSR when a frontbuffer invalidation happens, we can enable the PSR2 selective fetch continuous full frame, that will keep the panel updated like PSR was disabled but without keeping PSR active. So as soon as the frontbuffer flush happens we can disable the continuous full frame and start to do selective fetches much quicker than the path that would enable PSR, that will wait a few frames to actually activate PSR. Also this approach has proven to fix some glitches found in Alderlake-P when there are a lot of invalidations happening together with page flips. Some may ask why it is writing to CURSURFLIVE(), it is because that is the way that hardware team provided us to poke display to handle PSR updates, and it is being used since display 9. v2: - handling possible race conditions between frontbuffer rendering and page flips Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Cc: Shawn C Lee <shawn.c.lee@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-3-jose.souza@intel.com
2022-04-06drm/i915/display/psr: Lock and unlock PSR around pipe updatesJosé Roberto de Souza
Frontbuffer rendering and page flips can race with each other and this can potentialy cause issues with PSR2 selective fetch. And because pipe/crtc updates are time sentive we can't grab the PSR lock after intel_pipe_update_start() and before intel_pipe_update_end(). So here adding the lock and unlock functions and calls, the proper PSR2 selective fetch handling will come in a separated patch. v2: - fixed new functions documentation Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-2-jose.souza@intel.com
2022-04-06drm/i915/display/psr: Set partial frame enable when forcing full frame fetchJosé Roberto de Souza
Following up what was done in commit 804f46885317 ("drm/i915/psr: Set "SF Partial Frame Enable" also on full update") and also setting partial frame enable when psr_force_hw_tracking_exit() is called. Also as PSR2_MAN_TRK_CTL is a double buffered registers do a RMW is not a good idea so here also setting the man_trk_ctl_enable_bit() that is required in TGL and only doing a register write. v2: - not doing a rmw v3: - removing the inline from functions that return PSR2_MAN_TRK_CTL bits Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-1-jose.souza@intel.com
2022-03-15drm/i915/display: Do not re-enable PSR after it was marked as not reliableJosé Roberto de Souza
If a error happens and sink_not_reliable is set, PSR should be disabled for good but that is not happening. It would be disabled by the function handling the PSR error but then on the next fastset it would be enabled again in _intel_psr_post_plane_update(). It would only be disabled for good in the next modeset where has_psr will be set false. v2: - release psr lock before continue Fixes: 9ce5884e5139 ("drm/i915/display: Only keep PSR enabled if there is active planes") Reported-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reported-by: Charlton Lin <charlton.lin@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311185149.110527-2-jose.souza@intel.com
2022-03-03drm/i915/display: Allow users to disable PSR2José Roberto de Souza
Some users are suffering with PSR2 issues that are under debug or issues that were root caused to panel firmware bugs, to make life of those users easier here adding a option to disable PSR2 with kernel parameters so they can still benefit from PSR1 power savings. Using the same enable_psr that is current used to turn the whole feature on or off and allowing user to select up to what PSR version it should enable. Right now users only set this parameter to 0 when they want to disable PSR1 and PSR2 or don't add it at all leaving it to per-chip behavior so it should not cause a bad impact on users. v2: - changing enable_psr values (Ville and Rodrigo) Link: https://gitlab.freedesktop.org/drm/intel/-/issues/4951 Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220224202523.993560-1-jose.souza@intel.com
2022-03-03drm/i915/psr: Set "SF Partial Frame Enable" also on full updateJouni Högander
Currently we are observing occasional screen flickering when PSR2 selective fetch is enabled. More specifically glitch seems to happen on full frame update when cursor moves to coords x = -1 or y = -1. According to Bspec SF Single full frame should not be set if SF Partial Frame Enable is not set. This happened to be true for ADLP as PSR2_MAN_TRK_CTL_ENABLE is always set and for ADL_P it's actually "SF Partial Frame Enable" (Bit 31). Setting "SF Partial Frame Enable" bit also on full update seems to fix screen flickering. Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE only if not on ADL_P. Bit 31 has different meaning in ADL_P. Bspec: 49274 v2: Fix Mihai Harpau email address v3: Modify commit message and remove unnecessary comment Tested-by: Lyude Paul <lyude@redhat.com> Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by default") Reported-by: Lyude Paul <lyude@redhat.com> Cc: Mihai Harpau <mharpau@gmail.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/5077 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220225070228.855138-1-jouni.hogander@intel.com
2022-02-18drm/i915/display: Implement Wa_16013835468José Roberto de Souza
PSR2 workaround required when mode has delayed vblank. BSpec: 52890 BSpec: 49421 Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210185223.95399-2-jose.souza@intel.com
2022-02-18drm/i915/display: Group PSR2 prog sequences and workaroundsJosé Roberto de Souza
Grouping inside of the same if all the programing sequences and workarounds of PSR2. The order of programing changed in intel_psr_enable_source() but it will not affect PSR2 as at this point PSR2_ENABLE is still disabled. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210185223.95399-1-jose.souza@intel.com
2021-11-11drm/i915/psr: Fix PSR2 handling of multiplanar formatJosé Roberto de Souza
When a plane with a multiplanar format is added to the state by drm_atomic_add_affected_planes(), only the UV plane is added, so a intel_atomic_get_new_plane_state() call to get the Y plane state can return a null pointer. To fix this, intel_atomic_get_plane_state() should be called and the return needs to be checked for errors, as it could return a EAGAIN as other atomic state could be holding the lock for the Y plane. Other issue with the patch being fixed is that the Y plane is not being committed to hardware because the corresponded plane bit is not set in update_planes when UV and Y planes are added to the state by drm_atomic_add_affected_planes(). Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Fixes: 3809991ff5f4 ("drm/i915/display: Add initial selective fetch support for biplanar formats") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211108213807.39865-1-jose.souza@intel.com
2021-10-29Revert "drm/i915/display/psr: Do full fetch when handling multi-planar formats"Jouni Högander
This reverts commit 1f61f0655b95d5b89589390e6f83c4a61d9b1e8d. Now we are supporting selective fetch for biplanar formats. We can revert WA patch which forced using full fetch for biplanar formats. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211021101024.13112-3-jouni.hogander@intel.com
2021-10-29drm/i915/display: Add initial selective fetch support for biplanar formatsJouni Högander
Biplanar formats are using two planes (Y and UV). This patch adds handling of Y selective fetch area by utilizing existing linked plane mechanism. Also UV plane Y offset configuration is modified according to Bspec. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211021101024.13112-2-jouni.hogander@intel.com
2021-10-28drm/i915/adlp: Extend PSR2 support in transcoder BJosé Roberto de Souza
PSR2 is supported in transcoder A and B on Alderlake-P. v2: - explicity checking for transcoder A and B to avoid invalid transcoder BSpec: 49185 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jouni Hogander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> # v2 Link: https://patchwork.freedesktop.org/patch/msgid/20211027180545.55660-1-jose.souza@intel.com
2021-10-27drm/i915/psr: Disable PSR before modesets turn off all planesVille Syrjälä
PSR2 apparently requires some planes to be enabled for some silly reason, and so we are now trying to turn PSR off before planes go off. Except during a full modeset that is handled less clearly through reorganization of the modeset sequence. That is not great as it makes the code mode complex, and prevents us from doing nice things such as just turning off all the planes at the very start of the modeset. So let's move the PSR pre_plane_update() thing to a spot where it will handle both full modesets and everything else. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-2-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2021-10-26drm/i915/display: Wait PSR2 get out of deep sleep to update pipeJosé Roberto de Souza
Alderlake-P was getting 'max time under evasion' messages when PSR2 is enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a period of time longer than VBLANK_EVASION_TIME_US. For PSR1 we had the same issue so intel_psr_wait_for_idle() was implemented to wait for PSR1 to get into idle state but nothing was done for PSR2. For PSR2 we can't only wait for idle state as PSR2 tends to keep into sleep state(ready to send selective updates). Waiting for any state below deep sleep proved to be effective in avoiding the evasion messages and also not wasted a lot of time. v2: - dropping the additional wait_for loops, only the _wait_for_atomic() is necessary - waiting for states below EDP_PSR2_STATUS_STATE_DEEP_SLEEP v3: - dropping intel_wait_for_condition_atomic() function Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005231851.67698-1-jose.souza@intel.com
2021-10-21drm/i915: Move function prototypes to the correct headerVille Syrjälä
A bunch of function prototypes were left behind when the plane/crtc code got reshuffled to new files. Move the prototypes as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-20drm/i915/display: Add warn_on in intel_psr_pause()José Roberto de Souza
Right now the only user of psr_pause/resume is intel_cdclk but additional users will be added in the future and we may need do reference counting for PSR pause and resume, for now only adding a warn_on so this cases do not go unnoticed. Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jouni Hogander <jouni.hogander@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020003558.222198-2-jose.souza@intel.com
2021-09-30drm/i915/display/adlp: Allow PSR2 to be enabledJosé Roberto de Souza
With all the recent fixes PSR2 is properly working in Alderlake-P but due to some issues that don't have software workarounds it will not be supported in display steppings older than B0. Even with this patch PSR2 will no be enabled by default in ADL-P, it still requires enable_psr2_sel_fetch to be set to true, what some of our tests does. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930001409.254817-7-jose.souza@intel.com
2021-09-30drm/i915/display/adlp: Optimize PSR2 power-savings in corner casesJosé Roberto de Souza
The Wa_14014971508 is required to fix scanout when a feature that i915 do not support is enabled and this feature is not planned to be enabled for adlp. Keeping this workaround enabled can badly hurt power-savings when a full frame fetch is required(see psr2_sel_fetch_plane_state_supported() and psr2_sel_fetch_pipe_state_supported()). Here a example that could badly hurt power-savings, userspace does a page flip to a rotated plane, so CONTINUOS_FULL_FRAME set. But then for a whole 30 seconds nothing in the screen requires updates but because CONTINUOS_FULL_FRAME is set, it will not go into DC5/DC6. Reverting Wa_14014971508 fixes that, as only a single frame will be sent and then display can go to DC5/DC6 for those 30 seconds of idleness. BSpec: 54369 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930001409.254817-6-jose.souza@intel.com
2021-09-30drm/i915/display: Fix glitches when moving cursor with PSR2 selective fetch ↵José Roberto de Souza
enabled Legacy cursor APIs are handled by intel_legacy_cursor_update(), that calls drm_atomic_helper_update_plane() when going through the slow/atomic path to update cursor, what was the case for PSR2 selective fetch. drm_atomic_helper_update_plane() sets drm_atomic_state->legacy_cursor_update to true when updating the cursor plane, to allow several cursor updates to happen within the same frame, as userspace does that. If drivers waited for a vblank increment at the end of every cursor movement that would cause a visible lag in the cursor. But this optimization do not properly work with PSR2 selective fetch dirt area calculation, for example if within a single frame the cursor had 3 moves the final dirt area programmed to PSR2_MAN_TRK_CTL would be based in the second movement as old state and third movement as new state, not updating the area where cursor was in the first state. So here switching back to the fast path approach in intel_legacy_cursor_update() and handling cursor movements as frontbuffer rendering(psr_force_hw_tracking_exit()), that is not the most optimal for power-savings but is the solution that we have until mailbox style updates is implemented. Also removing the cursor workaround as not it is properly undestand the issue and is know that it will never cover all the cases. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930001409.254817-5-jose.souza@intel.com
2021-09-30drm/i915/display: Handle frontbuffer rendering when PSR2 selective fetch is ↵José Roberto de Souza
enabled When PSR2 selective fetch is enabled writes to CURSURFLIVE alone do not causes the panel to be updated when doing frontbuffer rendering. From what I was able to figure from experiments the writes to CURSURFLIVE takes PSR2 from deep sleep but panel is not updated because PSR2_MAN_TRK_CTL has no start and end region set. As we don't have the dirt area from current flush and invalidate API and even if we did userspace could do several draws to frontbuffer and we would need a way to append all the damaged areas of all the draws that need to be part of next frame. So here only programing PSR2_MAN_TRK_CTL to do a single full frame fetch. It is a safe approach as if scanout is in the visible area the single full frame will only be visible for hardware in the next frame because of the double buffering, and if scanout is in vblank area it will be draw in the current frame. No need to disable PSR and wait a few miliseconds to enable it again. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930001409.254817-4-jose.souza@intel.com
2021-09-30drm/i915/display/psr: Do full fetch when handling multi-planar formatsGwan-gyeong Mun
We are still missing the PSR2 selective fetch handling of multi-planar formats but until proper handle is added we can workaround it by doing full frames fetch when state has such formats. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930001409.254817-2-jose.souza@intel.com Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
2021-09-30drm/i915/display/psr: Handle plane and pipe restrictions at every page flipJosé Roberto de Souza
PSR2 selective is not supported over rotated and scaled planes. We had the rotation check in intel_psr2_sel_fetch_config_valid() but that code path is only execute when a modeset is needed and those plane parameters can change without a modeset. Pipe selective fetch restrictions are also needed, it could be added in intel_psr_compute_config() but pippe scaling is computed after it is executed, so leaving as is for now. There is no much loss in this approach as it would cause selective fetch to not enabled as for alderlake-P and newer will cause it to switch to PSR1 that will have the same power-savings as do full pipe fetch. Also need to check those restricions in the second for_each_oldnew_intel_plane_in_state() loop because the state could only have a plane that is not affected by those restricitons but the damaged area intersect with planes that has those restrictions, so a full pipe fetch is required. v2: - also handling pipe restrictions BSpec: 55229 Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> # v1 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930001409.254817-1-jose.souza@intel.com
2021-09-30drm/i915: Enable TPS3/4 on all platforms that support themVille Syrjälä
Stop using HBR2/3 support as a proxy for TPS3/4 support. The two are no longer 1:1 in the hardware, arguably they never were due to HSW ULX which does support TPS3 while being limited to HBR1. In more recent times GLK gained support for TPS4 while being limited to HBR2. And on CNL+ some ports support HBR3 while others are limited to HBR2, but all ports support TPS4. v2: s/INTEL_GEN/DISPLAY_VER/ Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929162404.6717-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2021-09-23drm/i915/display: Only keep PSR enabled if there is active planesJosé Roberto de Souza
PSR always had a requirement to only be enabled if there is active planes but not following that never caused any issues. But that changes in Alderlake-P, leaving PSR enabled without active planes causes transcoder/port underruns. Similar behavior was fixed during the pipe disable sequence by commit 84030adb9e27 ("drm/i915/display: Disable audio, DRRS and PSR before planes"). intel_dp_compute_psr_vsc_sdp() had to move from intel_psr_enable_locked() to intel_psr_compute_config() because we need to be able to disable/enable PSR from atomic states without connector and encoder state. Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210922215242.66683-3-jose.souza@intel.com
2021-09-23drm/i915/display: Match PSR2 selective fetch sequences with specificationJosé Roberto de Souza
We were not completely following the selective fetch programming sequence, here some things we were doing wrong: - not programming plane selective fetch a PSR2_MAN_TRK_CTL registers when doing a modeset - programming PSR2_MAN_TRK_CTL out of vblank With this changes the last remainig underrun found in Alderlake-P is fixed. Bspec: 55229 Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210922215242.66683-2-jose.souza@intel.com
2021-09-17drm/i915/display/adlp: Add new PSR2 workaroundsJosé Roberto de Souza
Wa_16014451276 fixes the starting coordinate for PSR2 selective updates. CHICKEN_TRANS definition of the workaround bit has a wrong name based on workaround definition and HSD. Wa_14014971508 allows the screen to continue to be updated when coming back from DC5/DC6 and SF_SINGLE_FULL_FRAME bit is not kept set in PSR2_MAN_TRK_CTL. Wa_16012604467 fixes underruns when exiting PSR2 when it is in one of its internal states. Wa_14014971508 is still in pending status in BSpec but by the time this is reviewed and ready to be merged it will be finalized. v2: - renamed register to ADLP_1_BASED_X_GRANULARITY - added comment about all ADL-P supported panels being 1 based X granularity BSpec: 54369 BSpec: 50054 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210914212507.177511-5-jose.souza@intel.com
2021-09-17drm/i915/display/psr: Use drm damage helpers to calculate plane damaged areaJosé Roberto de Souza
drm_atomic_helper_damage_iter_init() + drm_atomic_for_each_plane_damage() returns the full plane area in case no damaged area was set by userspace or it was discarted by driver. This is important to fix the rendering of userspace applications that does frontbuffer rendering and notify driver about dirty areas but do not set any dirty clips. With this we don't need to worry about to check and mark the whole area as damaged in page flips. Another important change here is the move of drm_atomic_add_affected_planes() call, it needs to called late otherwise the area of all the planes would be added to pipe_clip and not saving power. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210914212507.177511-4-jose.souza@intel.com
2021-09-17drm/i915/display: Workaround cursor left overs with PSR2 selective fetch enabledJosé Roberto de Souza
Not sure why but when moving the cursor fast it causes some artifacts of the cursor to be left in the cursor path, adding some pixels above the cursor to the damaged area fixes the issue, so leaving this as a workaround until proper fix is found. This is reproducile on TGL and ADL-P. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210914212507.177511-3-jose.souza@intel.com
2021-09-17drm/i915/display: Wait at least 2 frames before selective updateJosé Roberto de Souza
BSpec states that the minimum number of frames before selective update is 2, so making sure this minimum limit is fulfilled. BSpec: 50422 Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210914212507.177511-2-jose.souza@intel.com
2021-09-17drm/i915/display/adlp: Fix PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR calculationJosé Roberto de Souza
As the SU_REGION_START begins at 0, the SU_REGION_END should be number of lines - 1. BSpec: 50424 Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210914212507.177511-1-jose.souza@intel.com
2021-08-30drm/i915/display: Drop PSR support from HSW and BDWJosé Roberto de Souza
At this point is sure that HSW and BDW will never have PSR enabled by default, so here dropping it from device info and cleaning up code. v2: - enable psr support for display 9 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210827174253.51122-1-jose.souza@intel.com
2021-08-16drm/i915/display: Fix sel fetch plane offset calculationJosé Roberto de Souza
skl_calc_main_surface_offset() is used to calculate an aligned plane surface address considering the inner framebuffer x and y offset. It can not be used by selective fetch functions becase there is no PLANE_SEL_FETCH_SURF. So the PLANE_SEL_FETCH_OFFSET.y should only be PLANE_OFFSET.y + damaged_area_within_plane.y1. This fixes glitches seen in fbcon caused by typing something in the terminal. BSpec: 55229 Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210815014346.373945-1-jose.souza@intel.com
2021-07-29drm/i915/dg2: Update lane disable power state during PSRGwan-gyeong Mun
The PSR enable/disable sequences now require that we program an extra register in the PHY to adjust the lane disable power setting. Bspec: 49274 Bspec: 53885 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723174239.1551352-29-matthew.d.roper@intel.com
2021-07-26drm/i915/display/psr2: Mark as updated all planes that intersect with pipe_clipJosé Roberto de Souza
Without this planes that were added by intel_psr2_sel_fetch_update() that intersect with pipe damaged area will not have skl_program_plane() and intel_psr2_program_plane_sel_fetch() called, causing panel to not be properly updated. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717011227.204494-2-jose.souza@intel.com
2021-07-23drm/i915/dg2: Add DG2 to the PSR2 defeature listJosé Roberto de Souza
PSR2 is not supported on DG2. Cc: Caz Yokoyama <Caz.Yokoyama@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210714031540.3539704-49-matthew.d.roper@intel.com
2021-07-21drm/i915: Make display workaround upper bounds exclusiveMatt Roper
Workarounds are documented in the bspec with an exclusive upper bound (i.e., a "fixed" stepping that no longer needs the workaround). This makes our driver's use of an inclusive upper bound for stepping ranges confusing; the differing notation between code and bspec makes it very easy for mistakes to creep in. Let's switch the upper bound of our IS_{GT,DISP}_STEP macros over to use an exclusive upper bound like the bspec does. This also has the benefit of helping make sure workarounds are properly handled for new minor steppings that show up (e.g., an A1 between the A0 and B0 we already knew about) --- if the new intermediate stepping pulls in hardware fixes early, there will be an update to the workaround definition which lets us know we need to change our code. If the new stepping does not pull a hardware fix earlier, then the new stepping will already be captured properly by the "[begin, fix)" range in the code. We'll probably need to be extra vigilant in code review of new workarounds for the near future to make sure developers notice the new semantics of workaround bounds. But we just migrated a bunch of our platforms from the IS_REVID bounds over to IS_{GT,DISP}_STEP, so people are already adjusting to the new macros and now is a good time to make this change too. [mattrope: Split out display changes to apply through intel-next tree] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717051426.4120328-8-matthew.d.roper@intel.com
2021-07-21drm/i915/rkl: Wa_1408330847 no longer applies to RKLMatt Roper
RKL doesn't have PSR2 support, so PSR2-related workarounds no longer apply. Bspec: 53273 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717051426.4120328-7-matthew.d.roper@intel.com
2021-07-20drm/i915/display/adl_p: Implement PSR changesJosé Roberto de Souza
Implements changes around PSR for alderlake-P: - EDP_SU_TRACK_ENABLE was removed and bit 30 now has other function - Some bits of PSR2_MAN_TRK_CTL moved and SF_PARTIAL_FRAME_UPDATE was removed setting SU_REGION_START/END_ADDR will do this job - SU_REGION_START/END_ADDR have now line granularity but will need to be aligned with DSC when the PSRS + DSC support lands BSpec: 50422 BSpec: 50424 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210625235600.765677-1-jose.souza@intel.com
2021-07-14Merge branch 'topic/revid_steppings' into drm-intel-nextMatt Roper
The switch from old old IS_FOO_REVID() macros to the new table-based IS_FOO_{GT,DISP}_STEP() macros is needed on both drm-intel-next (for display-based DMC matching) and drm-intel-gt-next (for workaround guards). To avoid conflicts, we'll apply the patches to a topic branch and merge it to both intel branches to ensure the transition to the new macros is clean. Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-06 07:21:53 +0000