- 13 Dec, 2022 1 commit
-
-
Ville Syrjälä authored
s/GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED/GAMMA_MODE_MODE_12BIT_MULTI_SEG/ to make this thing slightly shorter. Also fix up the platform comment while at it. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-2-ville.syrjala@linux.intel.comReviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
- 12 Dec, 2022 1 commit
-
-
Jouni Högander authored
This patch introduces initial workarounds for mtl platform v2: switch IS_MTL_DISPLAY_STEP to use IS_METEORLAKE from testing display ver. (Tvrtko) v3: clerical issues, extend 16015201720 to mtl. (MattR) v4: make sure 16015201720 includes display 13. (MattR) Bspec: 66624 Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 09 Dec, 2022 11 commits
-
-
Ville Syrjälä authored
Always include both the encoder and PPS instance information in the debug prints so that we know what piece of hardware we're actually dealing with. v2: Make sure pps is selected before debug prints/etc. in intel_pps_vdd_on_unlocked() on vlv/chv There is no pps on pipe C on chv v3: Allow PPS=INVALID_PIPE for vlv/chv Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by:Animesh Manna <animesh.manna@intel.com>
-
Ville Syrjälä authored
Stray spaces have snuck in where everything else uses tabs. Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Use the consistent format when dumping out the PPS control/status registers. Helps with pattern matching. Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by:
-
Ville Syrjälä authored
On ICP-ADP the pins used by the second PPS can be alternatively muxed to some other function. In that case the second power sequencer is unusable. Unfortunately (on my ADL Thinkpad T14 gen3 at least) the BIOS still likes to enable the VDD on the second PPS (due to the VBT declaring the second bogus eDP panel) even when not correctly muxed, so we need to deal with it somehow. For now let's just initialize the PPS as normal, and then use the normal eDP probe failure VDD off path to turn it off (and release the wakeref the PPS init grabbed). The alternative of just declaring that the platform has a single PPS doesn't really work since it would cause the second eDP probe to also try to use the first PPS and thus clobber the state for the first (real) eDP panel. Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by:
-
Ville Syrjälä authored
On the PCH side the second PPS was introduced in ICP. Let's make sure we examine both power sequencer on ICP+ as well. Note that DG1/2 south block only has the single PPS, so need to exclude the fake DG1/2 PCHs. Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by:
-
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ä 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:
-
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:
-
- 29 Nov, 2022 1 commit
-
-
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:
-
