- 20 Apr, 2022 10 commits
-
-
Imre Deak authored
Save some space by grouping the HSW power well descriptor flags along with other flags in one bitfield. This change also lets simplifying the definition of power well descriptors sharing the same flags in an upcoming patch. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-5-imre.deak@intel.com
-
Imre Deak authored
The DG2 fixed delay duration is always 600usec, so save some space in the power well descriptors by converting the parameter to a flag. While at it also use a bitfield for both the always_on and fixed_enable_delay flag. This change also lets simplifying the definiton of power wells sharing the same flags in an upcoming patch. Signed-off-by:
-
Imre Deak authored
Move the list of platform specific power domain -> power well definitions to intel_display_power_map.c. While at it group the platforms' power domain macros with the corresponding power well lists and keep all the power domain lists in the same order (matching the enum order). No functional changes. v2: - s/intel_display_power_internal.h/intel_display_power_map.h/ (Jani) - Simplify intel_cleanup_power_wells(). - Don't move intel_display_power_domain_str(). v3: - Rename intel_init/cleanup_power_wells() to intel_display_power_map_init/cleanup(). - Add documentation to intel_display_power_map_init/cleanup(). Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Imre Deak authored
The for_each_power_well() macros are only used in intel_display_power.c and intel_display_power_well.c, so unexport them. Signed-off-by:
-
Imre Deak authored
Move the implementation of platform specific power well hooks to intel_display_power_well.c, to reduce the clutter in intel_display_power.c. The locking of all the power domain/power well state is handled in the power domain functions in intel_display_power.c using i915_power_domains::lock. This patch also moves the chy_phy_powergate_ch/lanes() functions to intel_display_power_well.c which borrow the same lock to protect the DISPLAY_PHY_CONTROL register state, which the HW uses both for toggling power wells and power gating PHY lanes. No functional change. v2: - Clarify in the commit log why CHV functions using the i915_power_domains::lock were moved, while others locking the power domain/well state were kept in intel_display_power.c . (Jouni) - Move forward declaration of chv_phy_powergate_ch/lanes() to intel_display_power_well.h . Signed-off-by:
-
José Roberto de Souza authored
This workaround fixes screen flickers with FBC. BSpec: 33450 BSpec: 52890 BSpec: 54369 BSpec: 66624 Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419182753.364237-1-jose.souza@intel.com
-
Ville Syrjälä authored
Follow the new i9xx DPLL FP register programming sequence introduced in commit 62d66b21 ("drm/i915: Fold i9xx_set_pll_dividers() into i9xx_enable_pll()") in the i830 "power well" code as well. Just for consistency. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-2-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Vinod Govindapillai authored
In configurations with single DRAM channel, for usecases like 4K 60 Hz, FIFO underruns are observed quite frequently. Looks like the wm0 watermark values need to bumped up because the wm0 memory latency calculations are probably not taking the DRAM channel's impact into account. As per the Bspec 49325, if the ddb allocation can hold at least one plane_blocks_per_line we should have selected method2. Assuming that modern HW versions have enough dbuf to hold at least one line, set the wm blocks to equivalent to blocks per line. v2: styling and comments changes (Ville) v3: Updated the reviewed-by tag v4: max_t to max and patch styling (Ville) References: https://gitlab.freedesktop.org/drm/intel/-/issues/4321 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Hans de Goede authored
Commit 428cb15d ("drm/i915: Clean up pre-skl primary plane registers") introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16). This breaks the primary display pane on at least pineview machines, fix the mask to fix the primary display pane only showing black. Tested on an Acer One AO532h with an Intel N450 SoC. Fixes: 428cb15d ("drm/i915: Clean up pre-skl primary plane registers") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Matt Atwood authored
Adding initial PCI ids for RPL-P. RPL-P behaves identically to ADL-P from i915's point of view. Changes since V1 : - SUBPLATFORM ADL_N and RPL_P clash as both are ADLP based - Matthew R Bspec: 55376 Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> [mattrope: Corrected comment formatting to match coding style] Signed-off-by:
-
- 19 Apr, 2022 2 commits
-
-
José Roberto de Souza authored
After commit 805f04d4 ("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: 805f04d4 ("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 authored
drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in 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: 6e43e276 ("drm/i915: Initial implementation of PSR2 selective fetch") Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
- 13 Apr, 2022 7 commits
-
-
Ville Syrjälä authored
Remove the pointless detour via __intel_fbc_post_update() during frontbuffer flush. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
Let's make sure FBC is always disabled when we start to take over the hardware state. I suspect this should never really happen, since the only time when we really should be taking over with the display already active is when the previous state was progammed by the BIOS, which likely shouldn't use FBC. This could be driver init, or S4 resume when the boot kernel doesn't load i915. But I suppose no harm in keeping this code around for exra safety since it's quite trivial. Signed-off-by:
-
Ville Syrjälä authored
By the time intel_fbc_global_disable() gets called during driver teardown we should have already disabled all the crtcs, so no way FBC should be enabled at this point. And I have no idea what the other user (i915_restore_display()) is even trying to achieve. So let's just throw intel_fbc_global_disable() into the bin. Signed-off-by:
-
Ville Syrjälä authored
Now that fbc no longer nukes while a flip is pending we can remove the last uncore.lock from the i9xx plane code. Signed-off-by:
-
Ville Syrjälä authored
Don't issue a nuke from frontbuffer flush while a flip is pending. This avoids the DSPADDR/DSPSURF rmw abuse from the pre-snb nuke from racing with the DSPADDR/DSPSURF write being performed by the flip/plane update. The flip itself will already cause the nuke so a double nuke is redundant. Signed-off-by:
-
Ville Syrjälä authored
If the frontbuffer bits say this fbc instance isn't affected just skip the whole thing. Signed-off-by:
-
Ville Syrjälä authored
Not sure what the point of this fbc->possible_frontbuffer_bits is. And especially don't see why it's returning all the bits when fbc is not even enabled. So let's just get rid of this and only say we are interested in the plane's frontbuffer bits when fbc is actually enabled. Signed-off-by:
-
- 12 Apr, 2022 11 commits
-
-
Manasi Navare authored
With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings. When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit in the DPCD. Currently the driver parses that onevery HPD but fails to reset the corresponding VRR Capable Connector property. Hence the userspace still sees this as VRR Capable panel which is incorrect. Fix this by explicitly resetting the connector property. v2: Reset vrr capable if status == connector_disconnected v3: Use i915 and use bool vrr_capable (Jani Nikula) v4: Move vrr_capable to after update modes call (Jani N) Remove the redundant comment (Jan N) v5: Fixes the regression on older platforms by resetting the VRR only if HAS_VRR v6: Remove the checks from driver, add in drm core before setting VRR prop (Ville) v7: Move VRR set/reset to set/unset_edid (Ville) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 9bc34b4d ("drm/i915/display/vrr: Reset VRR capable property on a long hpd") Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Juha-Pekka Heikkilä authored
Add support for the DG2 specific render compression with clear color framebuffer format. DG2 onwards discrete gfx has support for new flat CCS mapping, which brings in display feature in to avoid Aux walk for compressed surface. This support build on top of Flat CCS support added in XEHPSDV. FLAT CCS surface base address should be 64k aligned, Compressed displayable surfaces must use tile4 format. HAS: 1407880786 B.Spec : 7655 B.Spec : 53902 v2: Merge all bits required for the support of functionality into this patch from the patch adding the corresponding modifier. Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
-
Mika Kahola authored
DG2 clear color render compression uses Tile4 layout. Therefore, we need to define a new format modifier for uAPI to support clear color rendering. v2: Display version is fixed. [Imre] KDoc is enhanced for cc modifier. [Nanley & Lionel] v3: Split out the modifier addition to a separate patch. Clarify the modifier layout description. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-4-imre.deak@intel.com
-
Matt Roper authored
Add support for DG2 render and media compression, for the description of buffer layouts see the previous patch adding the corresponding frame buffer modifiers. v2: Display version fix [Imre] v3: Split out modifier addition to separate patch. Signed-off-by:
-
Matt Roper authored
The render/media engines on DG2 unify render compression and media compression into a single format for the first time, using the Tile 4 layout for main surfaces. The compression algorithm is different from any previous platform and the display engine must still be configured to decompress either a render or media compressed surface; as such, we need new RC and MC framebuffer modifiers to represent buffers in this format. v2: Clarify modifier layout description. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Ville Syrjälä authored
In addition to the fp_timing,dvo_timing,panel_pnp_id tables there also exists a panel_name table. Unlike the others this is just one offset+table_size even though there are still 16 actual panel_names in the data block. The panel_name table made its first appearance somewhere around VBT version 156-163. The exact version is not known. But we don't need to know that since we can just check whether the pointers block has enough room for it or not. Signed-off-by:
-
Ville Syrjälä authored
Now that we've sufficiently validated the LFP data pointers we can trust them. Signed-off-by:
-
Ville Syrjälä authored
Make sure the LFP data table pointers sane. Sensible looking table entries, everything points correctly into the data block, etc. Signed-off-by:
-
Ville Syrjälä authored
Currently get_lvds_fp_timing() still returns a pointer to the original data block rather than our copy. Let's convert the data pointer offsets to be relative to the data block rather than the whole BDB. With that we can make get_lvds_fp_timing() return a pointer to the copy. Signed-off-by:
-
Ville Syrjälä authored
Make a copy of each VBT data block with a guaranteed minimum size. The extra (if any) will just be left zeroed. This means we don't have to worry about going out of bounds when accessing any of the structure members. Otherwise that could easliy happen if we simply get the version check wrong, or if the VBT is broken/malicious. v2: Don't do arithmetic between bdb header and copy of the LFP data block (Jani) v3: Make all the copies up front v4: Only WARN about min_size==0 if we found the block Signed-off-by: -
Ville Syrjälä authored
We have the BDB version cached, use it. We're going to have to start doing some of the BDB block parsing later, at which point we may no longer have the VBT around anymore (we free it at the end of intel_bios_init() when it didn't come via OpRegion). Signed-off-by:
-
- 11 Apr, 2022 4 commits
-
-
Lucas De Marchi authored
When the PHY fails on calibration we were previously skipping the ddi initialization. However the driver is not really prepared for that, ultimately leading to a NULL pointer dereference: [ 75.748348] i915 0000:03:00.0: [drm:intel_modeset_init_nogem [i915]] SNPS PHY A failed to calibrate; output will not be used. ... [ 75.750336] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:80:pipe A] hw state readout: enabled ... ( no DDI A/PHY A ) [ 75.753080] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:235:DDI B/PHY B] hw state readout: disabled, pipe A [ 75.753164] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:245:DDI C/PHY C] hw state readout: disabled, pipe A ... [ 75.754425] i915 0000:03:00.0: [drm] *ERROR* crtc 80: Can't calculate constants, dotclock = 0! [ 75.765558] i915 0000:03:00.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) [ 75.765569] WARNING: CPU: 5 PID: 1759 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x347/0x360 ... [ 75.781230] BUG: kernel NULL pointer dereference, address: 000000000000007c [ 75.788198] #PF: supervisor read access in kernel mode [ 75.793347] #PF: error_code(0x0000) - not-present page [ 75.798480] PGD 0 P4D 0 [ 75.801019] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 75.805377] CPU: 5 PID: 1759 Comm: modprobe Tainted: G W 5.18.0-rc1-demarchi+ #199 [ 75.827613] RIP: 0010:icl_aux_power_well_disable+0x3b/0x200 [i915] [ 75.833890] Code: 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 48 8b 06 0f b6 70 1c f6 40 20 04 8d 56 fa 0f 45 f2 e8 88 bd ff ff 48 89 ef <8b> 70 7c e8 ed 67 ff ff 48 89 ef 89 c6 e8 73 67 ff ff 84 c0 75 0a [ 75.852629] RSP: 0018:ffffc90003a7fb30 EFLAGS: 00010246 [ 75.857852] RAX: 0000000000000000 RBX: ffff8881145e8f10 RCX: 0000000000000000 [ 75.864978] RDX: ffff888115220840 RSI: 0000000000000000 RDI: ffff888115220000 [ 75.872106] RBP: ffff888115220000 R08: ffff88888effffe8 R09: 00000000fffdffff [ 75.879234] R10: ffff88888e200000 R11: ffff88888ed00000 R12: ffff8881145e8f10 [ 75.886363] R13: 0000000000000001 R14: ffff888115223240 R15: 0000000000000000 [ 75.893490] FS: 00007ff6e753a740(0000) GS:ffff88888f680000(0000) knlGS:0000000000000000 [ 75.901573] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.907313] CR2: 000000000000007c CR3: 00000001216a6001 CR4: 0000000000770ee0 [ 75.914446] PKRU: 55555554 [ 75.917153] Call Trace: [ 75.919603] <TASK> [ 75.921709] intel_power_domains_sanitize_state+0x88/0xb0 [i915] [ 75.927814] intel_modeset_init_nogem+0x317/0xef0 [i915] [ 75.933205] i915_driver_probe+0x5f6/0xdf0 [i915] [ 75.937976] i915_pci_probe+0x51/0x1d0 [i915] We skip the initialization of PHY A, but later we try to find out what is the phy for that power well and dereference dig_port, which is NULL. Failing the PHY calibration could be left as a warning or error, like it was before commit b4eb76d8 ("drm/i915/dg2: Skip output init on PHY calibration failure"). However that often fails for outputs not being used, which would make the warning/error appear on systems that have no visible issues. Anyway, there is still a need to fix those failures, but that is left for later. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Stanislav Lisovskiy authored
If ret isn't zero, it is almost for sure ETIMEDOUT, because we use it in wait_for macro which does continuous retries until timeout is reached. If we still ran out of time and retries, we most likely would be interested in getting status, to understand what was the actual error propagated from PCode, rather than to find out that we had a time out, which is anyway quite obvious, if the function fails. v2: Make it status ? status : ret(thanks Vinod for the hint) Signed-off-by:
-
Stanislav Lisovskiy authored
Currently skl_pcode_try_request function doesn't properly handle return value it gets from snb_pcode_rw, but treats status != 0 as success, returning true, which basically doesn't allow to use retry/timeout mechanisms if PCode happens to be busy and returns EGAIN or some other status code not equal to 0. We saw this on real hw and also tried simulating this by always returning -EAGAIN from snb_pcode_rw for 6 times, which currently will just result in false success, while it should have tried until timeout is reached: [ 22.357729] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0 [ 22.357831] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1 [ 22.357892] i915 0000:00:02.0: [drm:skl_pcode_request [i915]] Success, exiting [ 22.357936] i915 0000:00:02.0: [drm] ERROR Failed to inform PCU about cdclk change (err -11, freq 307200) We see en error because higher level api, still notices that status was wrong, however we still did try only once. We fix it by requiring _both_ the status to be 0 and request/reply match for success(true) and function should return failure(false) if either status turns out to be EAGAIN, EBUSY or whatever or reply/request masks do not match. So now we see this in the logs: [ 22.318667] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0 [ 22.318782] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1 [ 22.318849] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 2 [ 22.319006] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 3 [ 22.319091] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 4 [ 22.319158] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 5 [ 22.319224] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 6 Reviewed-by:
-
Jani Nikula authored
Sync up with v5.18-rc1, in particular to get 5e3094cf ("drm/i915/xehpsdv: Add has_flat_ccs to device info"). Signed-off-by:
-
- 09 Apr, 2022 1 commit
-
-
Lucas De Marchi authored
Commit 4b276ed3 ("drm/i915/uncore: Warn on previous unclaimed accesses") tried to improve our report of unclaimed register access, however it unveiled cases that were not previously causing any harm. Downgrade the first message to debug so we can still see them and eventually fix, but don't warn. Fixes: 4b276ed3 ("drm/i915/uncore: Warn on previous unclaimed accesses") Signed-off-by:
-
- 08 Apr, 2022 1 commit
-
-
José Roberto de Souza authored
Commit 3b6f4095 ("drm/i915/display/psr: Lock and unlock PSR around pipe updates") did not took into account async flips with PSR1 and PSR2 HW tracking, causing PSR lock not be held and causing warnings when intel_psr2_program_trans_man_trk_ctl() is executed. So here taking the PSR lock before the earlier return in intel_pipe_update_start/end(). Cc: Jouni Högander <jouni.hogander@intel.com> Reported-by:
-
- 06 Apr, 2022 4 commits
-
-
Lucas De Marchi authored
Since gen6 we use FPGA_DBG register to detect unclaimed MMIO registers. This register is in the display engine IP and can only ever detect unclaimed accesses to registers in this area. However sometimes there are reports of this triggering for registers in other areas, which should not be possible. Right now we always warn after the read/write of registers going through unclaimed_reg_debug(). However places using __raw_uncore_* may be triggering the unclaimed access and those being later accounted to a different register. Let's warn both before and after the read/write with a slightly different message, so it's clear if the register reported in the warning is actually the culprit. Commit dda96033 ("drm/i915: Just clear the mmiodebug before a register access") attempted to solve the same issue by removing the warning when if FPGA_DBG flags before the mmio read/write. However, it doesn't solve it completely as FPGA_DBG may remain set when reading registers outside display. So in the end the check after the mmio read/write triggers the warning pointing to the wrong register. Signed-off-by:
-
Imre Deak authored
Accessing the DDI_BUF_CTL register without the port's DDI clock being enabled (to set/clear the TypeC PHY ownership for the port) can lead to a corrupted value read during any i915 register access right after the DDI clock is enabled. The root cause is the way clock synchronization works for this register, controlled by the CHICKEN_DCPR_1 DDI_CLOCK_REG_ACCESS flag. Correctly this flag should be cleared on ADLP (see the Bspec link below), however after bootup the flag is set. One easily reproducible issue is an unclaimed register access of the PWR_WELL_CTL_DDI2 register, programmed right after DDI clock enabling to enable the port's DDI_IO power well (see the HSDES, VLK links below). With the correct setting above this problem can't be reproduced. Bspec: 49189 HSDES: 18019028154 VLK: 28328, 28655 Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by:
Arthur J Runyan <arthur.j.runyan@intel.com> Reviewed-by:
-
Casey Bowman authored
Split i915_run_as_guest() into a more arch-friendly function as non-x86 builds do not support this functionality. Signed-off-by:
Casey Bowman <casey.g.bowman@intel.com> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
José Roberto de Souza authored
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:
-
