- 04 Oct, 2021 1 commit
-
-
Dave Airlie authored
This was causing infinite recursion on snb/ivb. Fixes: 5716c8c6 ("drm/i915/uncore: split the fw get function into separate vfunc") Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004003133.2279446-1-airlied@gmail.com
-
- 01 Oct, 2021 19 commits
-
-
Ville Syrjälä authored
While sanitizing the hardware state we're currently forcing the pipe bottom color legacy csc/gamma bits on. That is not a good idea as BIOSen are likely to leave gabage in the LUTs and so doing this causes ugly visual glitches if and when the planes covering the background get disabled. This was exactly the case on this Dell Precision 5560 tgl laptop. On icl+ we don't normally even use these legacy bits anymore and instead use their GAMMA_MODE counterparts. On earlier platforms the bits are used, but we still shouldn't force them on without knowing what's in the LUT. So two options, get rid of the whole thing, or do what intel_color_commit() does to make sure the bottom color state matches whatever out hardware readout produced. I chose the latter since it'll match what happens on older platforms when the primary plane gets turned off. In fact let's just call intel_color_commit(). It'll also do some CSC programming but since we don't have readout for that it'll actually just set to all zeros. So in the unlikely case of CSC actually being enabld by the BIOS we'll end up with all black until the first atomic commit happens. Still not totally sure what we should do about color management features here in general. Probably the safest thing would be to force everything off exactly at the same time when we disable the primary plane as there is no guarantees that whatever the LUTs/CSCs contain make any sense whatsoever without the specific pixel data in the BIOS fb. And if we preserve the primary plane then we should disable the color management features exactly when the primary plane fb contents first changes since the new content assumes more or less no transformations. But of course synchronizing front buffer rendering with anything else is a bit hard... Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3534Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210928185105.3030-1-ville.syrjala@linux.intel.comReviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
Check for the zero length front porch already in intel_mode_valid() so that we get the same validation for both get_modes() and setcrtc()/etc. Signed-off-by:
-
Ville Syrjälä authored
"CRTC fixup failed" is probably leftovers from pre-atomic days when there was an actual fixup() function. Let's unify the debug messages between encoder vs. crtc compute_config() calls. Signed-off-by:
-
Ville Syrjälä authored
Unify how we check for -EDEADLK vs. other errors from crtc vs. encoder compute_config() calls. Signed-off-by:
-
Jani Nikula authored
Prefer the intel_ types. No functional changes. v2: Fix build. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
Failures to register debugfs should be ignored anyway, so stop propagating errors altogether for clarity and simplicity. No functional changes. Reviewed-by:
-
Jani Nikula authored
The debugfs file shows it's not capable, don't duplicate the info. Reviewed-by:
-
Jani Nikula authored
Prefer i915 over drm pointer. Reviewed-by:
-
Jani Nikula authored
Using standard -EAGAIN should be perfectly fine instead of using a special case value. Reviewed-by:
-
Jani Nikula authored
Avoid using the incidental -EPERM. Reviewed-by:
-
Jani Nikula authored
Avoid using the incidental -EPERM. Return the -EIO directly from i915_get_bridge_dev() instead of converting return values later. Reviewed-by:
-
Jani Nikula authored
Avoid using the incidental -EPERM. Reviewed-by:
-
Jani Nikula authored
Avoid using the incidental -EPERM. Also remove useless comment. Reviewed-by:
-
Jani Nikula authored
Having two functions for this seems like excess duplication and parameter juggling. Merge them together. While at it, drop the extra error message, as wait_for_payload_credits() already prints an error, and switch from incidental -EPERM (i.e. -1) to actual error codes. Reviewed-by:
-
Jani Nikula authored
Pass a const pointer instead of passing 32 bytes of struct mipi_dsi_packet by value. Reviewed-by:
-
Jani Nikula authored
Keep the functionality and the assert code together. Reviewed-by:
-
Jani Nikula authored
Keep the functionality and the assert code together. Reviewed-by:
-
Jani Nikula authored
Move assert_panel_unlocked() to intel_pps.c and rename assert_pps_unlocked(). Keep the functionality and the assert code together. There's still a bit of a split between the eDP PPS usage in intel_pps.c and all the other PPS usage, and assert_pps_unlocked() is arguably more related to the latter. However, intel_pps.c is the best fit for anything touching the PPS registers. Reviewed-by:
-
Jani Nikula authored
Keep the functionality and the assert code together. Reviewed-by:
-
- 30 Sep, 2021 20 commits
-
-
José Roberto de Souza authored
With all the past fixes now this feature is functional and can be enabled by default in desktop enviroments that uses compositor. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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-8-jose.souza@intel.com
-
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:
-
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:
-
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:
-
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:
-
Ville Syrjälä authored
We don't support dsi displays without a fixed mode, so drop all the pointless checks. Signed-off-by:
-
