- 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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-5-ville.syrjala@linux.intel.comReviewed-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 <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:
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:
Taylor, Clinton A <clinton.a.taylor@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 11 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:
-
Ville Syrjälä authored
Get rid of the dvo_reg/dvo_srcdim_reg stuff by parametrizing the DVO port registers. Signed-off-by:
-
Ville Syrjälä authored
Poke a few more bits into the SiI164 to make it recover after S3. HEN/VEN are the important bits, the rest PLL filter/HPD detection I just did for good measure to match the BIOS programming. Note that the spec recommended SCNT bit in REGC isn't set by the BIOS at least for me, so I left it out. Signed-off-by:
-
Ville Syrjälä authored
Drop the pointless return statements at the end of void functions. Signed-off-by:
-
Ville Syrjälä authored
Poke a few more bits into the ch7xxx to make it output a picture after being reset during S3. In particular we need to set the input buffer select (IBS), and enable VGA vsync output on the BCO pin. Selecting VGA hsync on the c/h sync pin doesn't actually seem necessary on my ADD card at least, but the BIOS selects it so why not. Signed-off-by:
-
Jani Nikula authored
If phy is PHY_NONE, the shift to register bits becomes negative. Check and warn about this. Reported-by:
coverity-bot <keescook@chromium.org> References: https://lore.kernel.org/r/202211180848.D39006C@keescookSigned-off-by:
-
- 22 Nov, 2022 1 commit
-
-
Ville Syrjälä authored
Some gen2/gen3 parts have a 10bit gamma mode, on some pipes. Expose it. The format is different to the later i965+ style in that we store a 10bit value and a 6 bit floating point slope for each entry. Ie. the hardware extrapolates the intermediate steps from the current LUT entry, instead of interpolating between the current and next LUT entries. This also means we don't store the last LUT entry in any register as it is defined by the previous LUT entry's value+slope. The slope has limited precision though (2 bit exponent + 4 bit mantissa), so we'd have to allow for more error in the state checker for the last entry and we have to make sure userspace doesn't pass in something where the slope is simply to steep. In theory we should perhaps check the slope for every interval, but we don't do that for any other interpolated gamma mode and I suspect they may also have some internal limit on the slope. I haven't confirmed that theory though. Anyways, for ease of implementation we shall just ignore the last entry in the state checker. If all the other entries match anyway then that seems like a good indication that the hardware was programmed as expected. v2: Redo the state checker logic a bit Rebase due to other changes v3: Fix C8 readout v4: Use REG_FIELD_PREP() Acked-by:
-
