- 19 Nov, 2021 6 commits
-
-
Jani Nikula authored
The debugfs should have no special privileges to look into the implementation guts. Move the actual debug printing of power domains to intel_display_power.c. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-3-jani.nikula@intel.com
-
Jani Nikula authored
Use forward declarations instead. Signed-off-by:
-
Jani Nikula authored
Use forward declarations instead. Signed-off-by:
-
Ville Syrjälä authored
Use REG_BIT() & co. for the CRC registers. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-8-ville.syrjala@linux.intel.comReviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
Use REG_BIT() & co. for DPINVTT/VLV_DPFLIPSTAT bits. Signed-off-by:
-
Ville Syrjälä authored
Use REG_BIT() & co. for FPGA_DBG/CLAIM_ER bits. Signed-off-by:
-
- 18 Nov, 2021 7 commits
-
-
Manasi Navare authored
VRR is supported on Gen 11 HW , hence extend the support in the driver to enable this for Gen 11. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Turns out the DSB has trouble correctly loading the gamma LUT. From a cursory look maybe like some entries do not load properly, or they get loaded with some gibberish. Unfortunately our current kms_color/etc. tests do not seem to catch this. I had a brief look at the generated DSB batch and it looked correct. Tried a few quick tricks like writing the index register twice/etc. but didn't see any improvement. Also tried switching to the 10bit gamma mode in case there is yet another issue with the multi-segment mode, but even the 10bit mode was showing issues. Switching to mmio fixes all of it. I suppose one theory is that maybe the DSB bangs on the LUT too quickly and it can't keep up and instead some data either gets dropped or corrupted. To confirm that someone should try to slow down the DSB's progress a bit. Another thought was that maybe the LUT has crappy dual porting and you get contention if you try to load it during active scanout. But why then would the mmio path work, unless it's just sufficiently slow? Whatever the case, this is currently busted so let's disable it until we get to the root of the problem. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3916Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
All interpolated gamma modes including the icl+ multi segment mode require non-decreasing entries for the interpolation to work correctly. For some reason we're forgetting to declare that for icl+. Let us do so. References: https://gitlab.freedesktop.org/drm/intel/-/issues/3916Signed-off-by:
-
Ville Syrjälä authored
Since I originally wrote these comments we decided to change our definition of framestart_delay from 0-3 to 1-4. Adjust the comments to match that new convention. The actual code was adjusted already. Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Let's adjust the vblank evasion to account for the case where a push has already been sent. In that case the vblank exit will start at vmin vblank start (as opposed to vmax vblank start when no push has been sent). This should minimize the effects of the tiny race between sampling the frame counter vs. intel_vrr_send_push() during the previous frame. This will also be required if we want to do mailbox style updates with vrr since then we'd definitely do multiple commits per frame. Currently mailbox updates are only used by the legacy cursor, but we don't do vrr push for those. Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Moving the vrr push to happen before sampling the frame counter was wrong. If we are already in vblank when the push is sent the vblank exit will start immediately which causes the sampled frame counter to correspond to the next frame instead of the current frame. So put things back into the original order (except we should keep the vrr push within the irq disable section to avoid pointless irq related delays here). We'll just have to accept the tiny race that exists between sampling the frame counter vs. vrr push. And let's at least document said race properly in a comment. I suppose we could try to minimize the race by sampling the frame counter just before sending the push, but that would require changing drm_crtc_arm_vblank_event() to accept a caller provided vblank counter value, so leave it be for now. Another thing we could do is change the vblank evasion to account for the case where a push was already sent. That would anyway be required for mailbox style updates. Currently mailbox updates are only used by the legacy cursor, but we don't do a vrr push for those. Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 6f9976bd ("drm/i915: Do vrr push before sampling the frame counter") Signed-off-by:
-
Hans de Goede authored
In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk() for dual-link panels. This fixes the following WARN triggering: i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in pixel_rate (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.pipe_mode.crtc_clock (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.adjusted_mode.crtc_clock (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in port_clock (expected 235710, found 118056) ------------[ cut here ]------------ pipe state doesn't match! WARNING: CPU: 3 PID: 136 at drivers/gpu/drm/i915/display/intel_display.c:9125 intel_display_finish_reset+0x1bd3/0x2050 [i915] ... This has been tested on a Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC) tablet, with a 1536x2048 dual-link DSI panel. Note this fix was taken from icl_dsi.c which does the same in its get_config(). Cc: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
- 17 Nov, 2021 5 commits
-
-
Imre Deak authored
After a non-blocking modeset on a TypeC port's CRTC - possibly blocked later in drm_atomic_helper_wait_for_dependencies() - a fastset on the same CRTC may copy the state of CRTC before this gets updated to reflect the up-to-date DP-alt vs. TBT-alt TypeC mode DPLL used for the CRTC. In this case after the first (non-blocking) commit completes enabling the DPLL required for the up-to-date TypeC mode the following fastset will update the CRTC state pointing to the wrong DPLL. A subsequent disabling modeset will try to disable the wrong PLL, triggering a state checker WARN (and leaving the DPLL which is actually used active for good). Fix the above race by copying the DPLL state for fastset CRTCs from the old CRTC state at the point where it's guaranteed to be up-to-date already. This could be handled in the encoder's update_prepare() hook as well, but that's a bigger change, which is better done as a follow-up. v2: Copy dpll_hw_state as well. (Ville) Testcase: igt/kms_busy/extended-modeset-hang-newfb-with-reset Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4308 Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211115181121.156197-1-imre.deak@intel.com
-
Dan Carpenter authored
The intel_engine_create_virtual() function does not return NULL. It returns error pointers. Fixes: e5e32171 ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Jani Nikula authored
Add the i915_driver_ prefix to the switcheroo functions in i915_driver.[ch]. Signed-off-by:
-
Jani Nikula authored
As a name, "driver" is too generic and short to be easily located in a file this size. Rename it to i915_drm_driver. Signed-off-by:
-
Jani Nikula authored
This is more about trimming i915_drv.h than the renamed i915_driver.[ch]. Split out i915_driver.[ch] out of i915_drv.h as a feasible thing to do. Signed-off-by:
-
- 16 Nov, 2021 1 commit
-
-
Tilak Tangudu authored
s2idle and runtime pm puts the pci gfx device in D3Hot, ACPI runtime monitors the pci tree,if it sees complete tree as D3Hot,it transitions the device to D3Cold.But i915 do not have D3Cold support in S2idle or in runtime pm. so disabling D3cold in above flows and its FIXME. Added pci D3Cold enable/disable in s2idle and runtime suspend/resume flows. Signed-off-by:
Tilak Tangudu <tilak.tangudu@intel.com> Reviewed-by:
-
- 15 Nov, 2021 7 commits
-
-
Jani Nikula authored
Fix the recently introduced 'make htmldocs' warnings: $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_fbc.c:635: warning: Excess function parameter 'i915' description in 'intel_fbc_is_active' ./drivers/gpu/drm/i915/display/intel_fbc.c:1638: warning: Excess function parameter 'i915' description in 'intel_fbc_handle_fifo_underrun_irq' ./drivers/gpu/drm/i915/display/intel_fbc.c:635: warning: Function parameter or member 'fbc' not described in 'intel_fbc_is_active' ./drivers/gpu/drm/i915/display/intel_fbc.c:635: warning: Excess function parameter 'i915' description in 'intel_fbc_is_active' ./drivers/gpu/drm/i915/display/intel_fbc.c:1638: warning: Function parameter or member 'fbc' not described in 'intel_fbc_handle_fifo_underrun_irq' ./drivers/gpu/drm/i915/display/intel_fbc.c:1638: warning: Excess function parameter 'i915' description in 'intel_fbc_handle_fifo_underrun_irq' Fixes: e49a656b ("drm/i915/fbc: Start passing around intel_fbc") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Don't include stuff on behalf of users if they're not strictly necessary for the header. Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7bcaa1684587b9b008d3c41468fb40e63c54fbc7.1636977089.git.jani.nikula@intel.com
-
Andy Shevchenko authored
When kernel.h is used in the headers it adds a lot into dependency hell, especially when there are circular dependencies are involved. Replace kernel.h inclusion with the list of what is really being used. Signed-off-by:
-
Jani Nikula authored
Only intel_gt.c and intel_ggtt.c need the interface. Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Vandita Kulkarni authored
MIPI DSI transcoder cannot be in video mode to support any of the display C states. Bspec: 49195 (For DC*co DSI transcoders cannot be in video mode) Bspec: 49193 (Hardware does not support DC5 or DC6 with MIPI DSI enabled) Bspec: 49188 (desc of DSI_DCSTATE_CTL talks about cmd mode PM control v2: Align to the power domain ordering (Jani) Add bspec references (Imre) Signed-off-by:Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Vandita Kulkarni authored
Update ADL_P device info to support DSI0, DSI1 v2: Re-define cpu_transcoder_mask only (Jani) Signed-off-by:
-
Vandita Kulkarni authored
v2: Fix the typo, move out the hardcoding from macro(Jani, Ville) Fixes: f87c46c4 ("drm/i915/dsi/xelpd: Add WA to program LP to HS wakeup guardband") Signed-off-by:
-
- 12 Nov, 2021 1 commit
-
-
Colin Ian King authored
Don't populate the read-only array states on the stack but instead it static. Also makes the object code smaller. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
- 11 Nov, 2021 13 commits
-
-
José Roberto de Souza authored
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: 3809991f ("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
-
Ville Syrjälä authored
With multiple fbc instances we need to find the right one for each plane. Rather than going looking for the right instance every time let's just replace the has_fbc boolean with a pointer that gets us there straight away. Signed-off-by:
-
Ville Syrjälä authored
In preparation for multiple FBC instances start passing around intel_fbc pointers rather than i915 pointers. And once there are multiple of these we can't rely on container_of() to get back to the i915, so we toss in a fbc->i915 pointer already. Signed-off-by:
-
Ville Syrjälä authored
Rename 'dev_priv' to 'i915' to match modern style. Signed-off-by:
-
Ville Syrjälä authored
In the case of FBC_LLC_READ_CTRL the "FBC" stands for frame buffer _caching_, not frame buffer compression. Move the register definition out from the middle of the frame buffer compression register definitions. Let's just stick it somewhere with similar looking register offsets. And while at it switch it over to REG_BIT(). Signed-off-by:
-
Ville Syrjälä authored
Switch all the FBC1 registers over to REG_BTT()/etc. And while at it add a few more registers/bits that escaped the net previously. Signed-off-by:
-
Ville Syrjälä authored
The FBC register defines are a mess: - namespace changes between DPFC_, FBC_, and some platform specific prefix at a whim - ilk+ reuses most g4x bits but still has some separate bit defines elsewhere - it's not clear from the defines that the bit defines are shared So let's clean it up: - both g4x and ilk register share the same defines now - only defines which conflict have a _PLATFORM suffix, everyone else just gets comments to indicate which platforms do what - namespace is consistent DPFC_ now - SNB system agent fence registers also get a consistent namespace - REG_BIT() & co. for everything Signed-off-by:
-
Ville Syrjälä authored
Just use a same mask for ivb/hsw as for bdw+. The extra bit in the bdw mask is mbz on ivb/hsw anyway so this is just pointless complexity. Signed-off-by:
-
Ville Syrjälä authored
Pull the direct FBC register frobbing out from the debugfs code into the fbc code. Also add a vfunc for this so we don't need extra platforms checks. Signed-off-by:
-
Ville Syrjälä authored
Eliminate the last if-ladder by pulling the CFB/LLB programming into a vfunc as well. Signed-off-by:
-
Ville Syrjälä authored
"gen7" in display code is not really sensible. We shall call these things "ivb". Signed-off-by:
-
Ville Syrjälä authored
Eliminate yet another if-ladder by adding .nuke() vfunc. We also rename all *_recompress() stuff to *_nuke() since that's the terminology the spec uses. Also "recompress" is a bit confusing by perhaps implying that this triggers an immediate recompression. Depending on the hardware that may definitely not be the case, and in general we don't specifically know when the hardware decides to compress. So all we do is "nuke" the current compressed framebuffer and leave it up to the hardware to recompress later if it so chooses. Signed-off-by:
-
Ville Syrjälä authored
Replace the "if-ladders everywhere" approach with vfuncs. Signed-off-by:
-
