- 30 Sep, 2021 24 commits
-
-
José Roberto de Souza authored
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
-
José Roberto de Souza authored
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 authored
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
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 authored
This unnecessary flushes are hurting power-savings are it causes features like PSR, FBC and DRRS to disable it self to handle frontbuffer rendering, below some explanation of why each removed call is not necessary. The flush in intel_prepare_plane_fb() is not required as framebuffer will be flipped and power-saving features do the proper flip handling in hardware. intel_find_initial_plane_obj() flush is not required because it is only executed during driver load and at this point the power-saving features are not even enabled. And the last one intelfb_create(), is also not required as at this point the fbdev was just allocated, userspace will draw on it what will trigger frontbuffer invalidates and flushes later on. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Gwan-gyeong Mun authored
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:
-
José Roberto de Souza authored
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:
-
Ville Syrjälä authored
"ddi_translations" is a bit too long, let's shorten it to just "trans". Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Get rid of the local copies and pointers of intel_dp->DP and instead just poke at it directly. Makes it much easier to see where it actually gets used/modified. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Setting DP_PORT_EN in intel_dp->DP is already handled by intel_dp_enable_port() so there is no point in setting it also from the link training code. For DDI platforms a bit with that name doesn't even exist. The counterpart is DDI_BUF_CTL_ENABLE, which is already set up by intel_ddi_prepare_link_retrain(). Fortunately it is the same bit so there was no harm in doing this from the platform independent code as well. But it's just confusing when platform independent code sets platform specific bits in intel_dp->DP. Just get rid of it. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
I want intel_dp->DP to be fully populated by the time the initial vswing programming happens. To that end move the intel_ddi_init_dp_buf_reg() call to an earlier spot. Additionally we don't want intel_ddi_init_dp_buf_reg() to set DDI_BUF_CTL_ENABLE since the port should only get enabled at the start of link training (see intel_ddi_prepare_link_retrain()). So any earlier write to the register should not set the enable bit. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently we clear the leftover vswing/preemphasis values only at the start of link training. That means the initial vswing programming performed during modeset is going to use stale values left over from the previous link training sequence, and then at the start of link training we're going to reset the levels back to 0. Seems much better to make sure we start with level 0 from the get go. Additionally if LTTPRs are present the leftover vswing/preemphasis values are those of the last link in the chain, so not the values that our PHY is even using after a successful link training sequence. So let's make sure everything is cleared up before we start programming anything. Suggested-by:
-
Lukasz Majczak authored
With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+" the size of bdb_lfp_backlight_data structure has been increased, causing if-statement in the parse_lfp_backlight function that comapres this structure size to the one retrieved from BDB, always to fail for older revisions. This patch calculates expected size of the structure for a given BDB version and compares it with the value gathered from BDB. Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221) Fixes: d381baad ("drm/i915/vbt: Fix backlight parsing for VBT 234+") Tested-by:
Lukasz Majczak <lma@semihalf.com> Signed-off-by:
-
Maarten Lankhorst authored
Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held. I don't think there's much of a point in merging intel_dpt_pin() with intel_pin_fb_obj_dpt(), they touch different objects. Changes since v1: - Fix using the wrong pointer to retrieve error code (Julia) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Julia Lawall <julia.lawall@lip6.fr> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929085950.3063191-1-maarten.lankhorst@linux.intel.com
-
Ville Syrjälä authored
Let's not configure the single transcoder's TRANSCONF multiple times with bigjoiner. No real harm I suppose but since we already have the bigjoiner if statement directly above might as well suck this in there and skip the redundant programming. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
Adjust the HSW+ transcoder state readout to just read through all the possible transcoders for the pipe, and stuff the results in a bitmask. We can conveniently cross check the bitmask for invalid combinations of enabled transcoders, and later we can easily extend the bitmask readout to handle the bigjoiner case. One slight change in behaviour is that we no longer read out the AONOFF->force_pfit.pfit bit for all the enabled "panel transcoders". But having more than one enabled would anyway be illegal so no big loss. Also the AONOFF selection should only ever be used on HSW, which only has the EDP transcoder an no DSI transcoders. Signed-off-by:
-
Ville Syrjälä authored
FBC+Yf tiling seems to work just fine, and unlike with linear the hardware does appear to correctly calculate the CFB stride with using the override stride on both cfl and glk. So no need for any additional tweaks. Cc: Uma Shankar <uma.shankar@intel.com> #v2 Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
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:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
We don't support dsi displays without a fixed mode, so drop all the pointless checks. Signed-off-by:
-
Ville Syrjälä authored
When using a panel with a fixed mode we don't change the refresh rate of the display. Reject any user requested mode which doesn't match that fixed refresh rate. Unfortunately when Xorg sees the scaling_mode property on the connecor it likes to automagically cook up modes whose refresh rate is a fair bit off from the fixed refresh rate we use. So we have to give it some extra latitude so that we don't start to reject all of it. v2: sDVO now uses intel_panel_compute_config() too v3: Add a debug message to inform the user what happened References: https://gitlab.freedesktop.org/drm/intel/-/issues/2939 References: https://gitlab.freedesktop.org/drm/intel/-/issues/3969Signed-off-by:
-
Ville Syrjälä authored
Let's introduce a compute_config() helper for fixed mode panels. For now all it does is the fixed_mode->adjusted_mode copy. Note that with sDVO we have to ask the external encoder chip to spit out our actual display timings for us, so the fixed_mode to adjusted_mode copy done by intel_panel_compute_config() is redundant, but we still want to use it to do other checks for us later. We'll be fine so long as we only call it before intel_sdvo_get_preferred_input_mode() overwrites adjusted_mode with the timings from the encoder. v2: Use intel_panel_compute_config() with sDVO Signed-off-by:
-
Ville Syrjälä authored
When using a fixed mode we won't change the refresh rate ever. So filter out all modes that don't match the fixed_mode's refresh rate. I'm going to declare the "rounded to nearest Hz refresh rates must match" approach good enough for now. Note that we could start supporting multiple refresh rates with panels that can do it, but that would mean replacing the single fixed mode concept with a list of fixed modes. Then we could look for the closest match to the user's requested refresh rate and use that. But all of that would be a fair bit of work so we'll leave it for later. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2939 References: https://gitlab.freedesktop.org/drm/intel/-/issues/3969Signed-off-by:
-
Ville Syrjälä authored
All fixed mode panels should behave the same way when it comes to mode filtering. Reuse the intel_panel_mode_valid() for all of them. This changes the behaviour to match what we do for eDP, ie. reject anything that doesn't exactly match the fixed mode dimensions. Users can still manually provide different sized modes which will be handled by the panel fitter just as before. The difference is that we can no longer report funny modes in the connector's mode list. Signed-off-by:
-
Ville Syrjälä authored
Extract intel_panel_mode_valid() from the eDP code to a generic helper. Signed-off-by:
-
- 29 Sep, 2021 16 commits
-
-
Imre Deak authored
The PHY ownership release->AUX PW disable steps during a modeset disable->PHY disconnect sequence can hang the system if the PHY disconnect happens after disabling the PHY's PLL. The spec doesn't require a specific order for these two steps, so this issue is still being root caused by HW/FW teams. Until that is found, let's make sure the disconnect happens before the PLL is disabled, and do this on all platforms for consistency. v2: Add a TODO comment to remove the w/a once the issue is root caused/fixed. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: -
Imre Deak authored
After the previous patch the driver holds a power domain blocking TC-cold whenever the port is locked, so we can remove the extra blocking around the lock/unlock sequence. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
So far TC-cold was blocked only for the duration of TypeC mode resets. The DP-alt and legacy modes require TC-cold to be blocked also whenever the port is in use (AUX transfers, enable modeset), and this was ensured by the held PHY ownership flag. On ADL-P this doesn't work, since the PHY ownership flag is in a register backed by the PW#2 power well. Whenever this power well is disabled the ownership flag is cleared by the HW under the driver. The only way to cleanly release and re-acquire the PHY ownership flag and also allow for power saving (by disabling the display power wells and reaching DC5/6 states) is to hold the TC-cold blocking power domains while the PHY is connected and disconnect/reconnect the PHY on-demand around AUX transfers and modeset enable/disables. Let's do that, disconnecting a PHY with a 1 sec delay after it becomes idle. For consistency do this on all platforms and TypeC modes. v2: Add tc_mode!=disconnected and phy_is_owned asserts to __intel_tc_port_lock(). Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: -
Imre Deak authored
While a TypeC port mode is locked a DISPLAY_CORE power domain reference is held, which implies a runtime PM ref. By removing the ICL !legacy port special casing, a TC_COLD_OFF power domain reference will be taken for such ports, which also translates to a runtime PM ref on that platform. A follow-up change will stop holding the DISPLAY_CORE power domain while the port is locked. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
For the ADL-P TBT mode the spec doesn't require blocking TC-cold by using the legacy AUX power domain. To avoid the timeouts that this would cause during PHY disconnect/reconnect sequences (which will be more frequent after a follow-up change) use the TC_COLD_OFF power domain in TBT mode on all platforms. On TGL this power domain blocks TC-cold via a PUNIT command, while on other platforms the domain just takes a runtime PM reference. If the HPD live status indicates that the port mode needs to be reset - for instance after switching from TBT to a DP-alt sink - still take the AUX domain, since the IOM firmware handshake requires this. v2: Rebased on v2 of the previous patch. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
A follow-up change will select the TC-cold blocking power domain based on the TypeC mode, prepare for that here. Also bring intel_tc_cold_requires_aux_pw() earlier to its logical place for readability. No functional change. v2: Add code comment about IOM reg accesses in TCCOLD. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
A follow-up change will start to disconnect/re-connect PHYs around AUX transfers and modeset enable/disables. To prepare for that add a new TypeC PHY disconnected mode, to help tracking the TC-cold blocking power domain status (no power domain in disconnected state, mode dependent power domain in connected state). v2: Move the !disconnected mode and phy-owned asserts in __intel_tc_port_lock() later in the patchset, when the asserts will hold. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: -
Imre Deak authored
A follow-up patch will disconnect/reconnect PHYs around AUX transfers and modeset enable/disables. To prepare for that and make things consistent for all TypeC modes stop connecting the PHY in legacy mode without a sink being connected. This was done before since in legacy mode the PHY is dedicated to display usage, so there was no point in disconnecting it. However after the follow-up changes the TC-cold blocking power domains will be held as long as the PHY is in the connected state, so we'll need to disconnect/re-connect the PHY in all TypeC modes to allow for power saving. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
Instead of directly accessing the TypeC port internal struct members, add/use helpers to retrieve the corresponding properties. No functional change. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
On ADL-P the PHY ready/complete flag is always set even in TBT-alt mode. To avoid taking the PHY ownership and the following spurious "PHY sudden disconnect" messages on this platform when connecting the PHY in TBT mode, check if there is any DP-alt or legacy sink connected before taking the ownership. v2: (Jose) - Fix debug message clarifying that a TBT sink can be connected. - Add comments describing the PHY complete HW flag semantic differences between adl-p and other platforms. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
Waiting for the PHY complete flag to clear when releasing the PHY ownership was add in commit ddec3627 ("drm/i915: Wait for TypeC PHY complete flag to clear in safe mode") This isn't required by the spec, the vague idea was to make the handshake with the firmware more robust, without actual evidence for when it would be needed. Checking this again, the flag doesn't clear on ICL until after the PHY's PLL is disabled and the flag is permanently set on ADL-P. To avoid the spurious timeout messages in dmesg, just remove this wait. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
On ADL-P the PHY ready (aka status complete on other platforms) flag is always set, besides when a DP-alt, legacy sink is connected also when a TBT sink is connected or nothing is connected. So assume the PHY to be connected when both the TBT live status and PHY ready flags are set. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
Atm during driver loading and system resume TypeC ports are accessed before their HW/SW state is synced. Move the TypeC port sanitization to the encoder's sync_state hook to fix this. v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well (Jose, Jani) Fixes: f9e76a6e ("drm/i915: Add an encoder hook to sanitize its state during init/resume") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Tejas Upadhyay authored
Display underrun in HDR mode when cursor is enabled. RTL fix will be implemented CLKGATE_DIS_PSL_A bit 28-46520h. As per W/A 1604331009, Disable cursor clock gating in HDR mode. Bspec : 33451 Changes since V6: - Address checkpatch warnings - Bit ordering Changes since V5: - replace intel_de_read with intel_de_rmw - Jani Changes since V4: - Added WA needed check - Ville - Replace BIT with REG_BIT - Ville - Add WA enable/disable support back which was added in V1 - Ville Changes since V3: - Disable WA when not in HDR mode or cursor plane not active - Ville - Extract required args from crtc_state - Ville - Create HDR mode API using bdw_set_pipemisc ref - Ville - Tested with HDR video as well full setmode, WA applies and disables Changes since V2: - Made it general gen11 WA - Removed WA needed check - Added cursor plane active check - Once WA enable, software will not disable Changes since V1: - Modified way CLKGATE_DIS_PSL bit 28 was modified Reviewed-by:Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by:
-
Dave Airlie authored
Use a nop table for the cases where CxSR doesn't init properly. v2: use a nop table (Jani) Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
I used a macro to avoid making any really silly mistakes here. Reviewed-by:
-
