- 09 Dec, 2022 6 commits
-
-
Ville Syrjälä authored
Currently on bxt/glk we just grab the power sequencer index from the VBT data even though it may not have been parsed yet. That could lead us to using the incorrect power sequencer during the initial panel probe. To avoid that let's try to read out the current state of the power sequencer from the hardware. Unfortunately the power sequencer no longer has anything in its registers to associate it with the port, so the best we can do is just iterate through the power sequencers and pick the first one. This should be sufficient for single panel cases. For the dual panel cases we probably need to go back to parsing the VBT before the panel probe (and hope that panel_type=0xff is never a thing in those cases). To that end the code always prefers the VBT panel sequencer, if available. v2: Restructure a bit for upcoming icp+ dual PPS support Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-5-ville.syrjala@linux.intel.comReviewed-by:
Animesh Manna <animesh.manna@intel.com>
-
Ville Syrjälä authored
Restate the vlv_pipe_check() stuff in terms of PPS index (rather than pipe, which it is on VLV/CHV) so that we can reuse this same mechanim on other platforms as well. Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Lots of ADL machines out there with bogus VBTs that declare two eDP child devices. In order for those to work we need to figure out which power sequencer to use before we try the EDID read. So let's do the panel VBT init early if we can, falling back to the post-EDID init otherwise. The post-EDID init panel_type=0xff approach of assuming the power sequencer should already be enabled doesn't really work with multiple eDP panels, and currently we just end up using the same power sequencer for both eDP ports, which at least confuses the wakeref tracking, and potentially also causes us to toggle the VDD for the panel when we should not. Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Introduce a place where we can initialize connector->panel after it's been allocated. We already have a intel_panel_init() so had to get creative with the name and came up with intel_panel_init_alloc(). Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by:
-
Jani Nikula authored
Remove an unnecessary include. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221208133638.478024-1-jani.nikula@intel.com
-
Khaled Almahallawy authored
Bspecs has updated recently to remove the restriction to disable DDI/Transcoder before setting PHY test pattern. This update is to address PHY compliance test failures observed on a port with LTTPR. The issue is that when Transc. is disabled, the main link signals fed to LTTPR will be dropped invalidating link training, which will affect the quality of the phy test pattern when the transcoder is enabled again. v2: Update commit message (Clint) v3: Add missing Signed-off in v2 v4: Update Bspec and commit message for pre-gen12 (Jani) Bspec: 50482, 7555 Fixes: 8cdf7271 ("drm/i915/dp: Program vswing, pre-emphasis, test-pattern") Cc: Imre Deak <imre.deak@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> CC: Jani Nikula <jani.nikula@intel.com> Tested-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
- 08 Dec, 2022 16 commits
-
-
Ville Syrjälä authored
On mtl (at least) clearing the guardband bits in the same write as the enable bit gets cleared seems to cause an immediate FIFO underrun. Thus is seems that we need to first clear just the enable bit, then wait for the VRR live status to indicate the transcoder has exited VRR mode (this step is documented in Bspec as well), and finally we can clear out the rest of the TRANS_VRR_CTL for good measure. I did this without any RMWs in case we want to toggle VRR on/off via DSB in the future, and as we know DSB can't read registers. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
On mtl it looks like disabling VRR after the transcoder has been disabled can cause the pipe/transcoder to get stuck when re-enabled in non-vrr mode. Reversing the order seems to help. Bspec is extremely confused about the VRR enable/disable sequence anyway, and this now more closely matches the non-modeset VRR sequence, whereas the full modeset sequence still claims that the original order is fine. But since we eventually want to toggle VRR without a full modeset anyway this seems like the better order to follow. Signed-off-by:
-
Ville Syrjälä authored
We are miscalculating both the guardband value, and the resulting vblank exit length on adl+. This means that our start of vblank (double buffered register latch point) is incorrect, and we also think that it's not where it actually is (hence vblank evasion/etc. may not work properly). Fix up the calculations to match the real hardware behaviour (as reverse engineered by intel_display_poller). Signed-off-by:
-
Ville Syrjälä authored
Account for the framestart delay when calculating the "pipeline full" value for icl/tgl vrr. This puts the start of vblank (ie. where the double bufferd registers get latched) to a consistent place regardless of what framestart delay value is used. framestart delay does not change where start of vblank occurs in non-vrr mode and I can't see any reason why we'd want different behaviour in vrr mode. Currently framestart delay is always set to 1, and the hardcoded 4 scanlines in the code means we're currently delaying the start of vblank by three extra lines. And with framestart delay set to 4 we'd have no extra delay. Signed-off-by:
-
Ville Syrjälä authored
Despite what I claimed in commit c3c5dc1d ("drm/i915/audio: Do the vblank waits") the vblank interrupts are in fact not enabled yet when we do the audio enable sequence on VLV/CHV (all other platforms are fine). Reorder the enable sequence on VLV/CHV to match that of the other platforms so that the audio enable happens after the pipe has been enabled. Fixes: c3c5dc1d ("drm/i915/audio: Do the vblank waits") Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8c29f4f76c2163da309ead0bf48652024f134f11.1670433372.git.jani.nikula@intel.com
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
There's no need to save the register offsets. Drop the variables. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
A similar thing was added in intel_uncore_rmw(). Make it available for display too. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Add more de helpers to be able to avoid direct calls to uncore. v3 by Jani: - drop intel_de_write_samevalue/intel_de_rewrite_fw altogether v2 by Jani: - drop pcode stuff for now - rename intel_de_write_samevalue -> intel_de_rewrite_fw Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
- 07 Dec, 2022 7 commits
-
-
Jani Nikula authored
Fix the final straggler. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4769f8377be11536bd19840a2e59ef9f8c0a558c.1670405587.git.jani.nikula@intel.com
-
Jani Nikula authored
Prefer only having struct drm_i915_private *i915 around. Drop the drm_device *dev locals. Signed-off-by:
-
Jani Nikula authored
With the implicit dev_priv usage gone, we can rename dev_priv to i915 throughout. Do some drive-by whitespace cleanups while at it. Signed-off-by:
-
Jani Nikula authored
None of the remaining backlight registers that use DISPLAY_MMIO_BASE() are used on VLV/CHV, which are the only platforms that have non-zero base. Just drop the DISPLAY_MMIO_BASE() use, reducing the implicit dev_priv references. Signed-off-by:
-
Jani Nikula authored
Since the VLV/CHV backlight registers are only used on VLV/CHV, there's no need to dynamically look up DISPLAY_MMIO_BASE(). We know it's VLV_DISPLAY_BASE. Use it statically, reducing the implicit dev_priv references. Signed-off-by:
-
Miaoqian Lin authored
intel_uncore_forcewake_put__locked() is used to release a reference. Fixes: a6111f7b ("drm/i915: Reduce locking in execlist command submission") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
-
Jani Nikula authored
The locking should not be needed after commits de5bd083 ("drm/i915/fbc: Skip nuke when flip is pending") and 7cfd1a18 ("drm/i915: Remove remaining locks from i9xx plane udpates"). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 30 Nov, 2022 3 commits
-
-
Taylor, Clinton A authored
Replace integrated with discrete for dgfx platforms. v2: commit title reword (Jani) v3: use variable name i915 (Jani) v4: commit message reword (MattR) Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Release notes: 1. Fixes for Register noclaims and few restore. Fixes: c4cf059d ("drm/i915/dmc: Update DG2 DMC firmware to v2.07") Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Swati Sharma authored
Use HAS_DSC(__i915) wrapper containing runtime info of has_dsc member. Platforms supporting dsc has this flag enabled; no need of DISPLAY_VER() check. Also, simplified intel_dsc_source_support() based on above changes. Suggested-by:
Swati Sharma <swati2.sharma@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221110093312.13932-1-swati2.sharma@intel.com
-
- 29 Nov, 2022 2 commits
-
-
Mikko Kovanen authored
intel_dsi->ports contains bitmask of enabled ports and correspondingly logic for selecting port for VBT packet sending must use port specific bitmask when deciding appropriate port. Fixes: 08c59dde ("drm/i915/dsi: fix VBT send packet port selection for ICL+") Cc: stable@vger.kernel.org Signed-off-by:
Mikko Kovanen <mikko.kovanen@aavamobile.com> Reviewed-by:
-
Xia Fukun authored
When (size != 0 || ptrs->lvds_ entries != 3), the program tries to free() the ptrs. However, the ptrs is not created by calling kzmalloc(), but is obtained by pointer offset operation. This may lead to memory leaks or undefined behavior. Fix this by replacing the arguments of kfree() with ptrs_block. Fixes: a87d0a84 ("drm/i915/bios: Generate LFP data table pointers if the VBT lacks them") Signed-off-by:
Xia Fukun <xiafukun@huawei.com> Signed-off-by:
-
- 23 Nov, 2022 6 commits
-
-
Ville Syrjälä authored
Currently it's not 100% obvious which DVO encoder chip was found on which port. Leave a slightly better trace in log. Signed-off-by:
-
Ville Syrjälä authored
Pull the DVO port register definitons into their own header to declutter i915_reg.h a bit. Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled RMW with intel_de_rmw() in the DVO port enable/disable functions. Also switch to intel_de_posting_read() for the posting read (though maybe it should be just be nuked...). Signed-off-by:
-
Ville Syrjälä authored
Polish the DVO port registers with REG_BIT()/etc. Signed-off-by:
-
Ville Syrjälä authored
We have two sets of bits for DVO "data order" stuff. Rename one set to ACT_DATA_ORDER to make it clear they are separate bitfields. Signed-off-by:
-
Ville Syrjälä authored
Define a few extra interrupt related bits on the DVO register. One of these we included in the DVO_PRESERVE_MASK already. Signed-off-by:
-
