- 18 Mar, 2022 2 commits
-
-
Ville Syrjälä authored
I'd like to see the SAGV block time we got from the mailbox in the logs regardless of whether other factors prevent the use of SAGV. So let's adjust the code to always query the SAGV block time, log it, and then reset it if SAGV is not actually supported. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-3-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
For modern platforms the spec explicitly states that a SAGV block time of zero means that SAGV is not supported. Let's extend that to all platforms. Supposedly there should be no systems where this isn't true, and it'll allow us to: - use the same code regardless of older vs. newer platform - wm latencies already treat 0 as disabled, so this fits well with other related code - make it a bit more clear when SAGV is used vs. not - avoid overflows from adding U32_MAX with a u16 wm0 latency value which could cause us to miscalculate the SAGV watermarks on tgl+ Cc: stable@vger.kernel.org Signed-off-by:
-
- 17 Mar, 2022 2 commits
-
-
Jani Nikula authored
Remove the uapi/drm/i915_drm.h include from drm/i915_drm.h, and stop being a proxy for uapi/drm/i915_drm.h. Include uapi/drm/i915_drm.h and drm/i915_drm.h only where needed. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Jani Nikula authored
Move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch] as a i915_gem_object function related to tiling. Also un-inline while at it; does not seem like this is a function needed in hot paths. v2: i915_gem_tiling.[ch] instead of intel_ggtt_fencing.[ch] (Chris) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220316095018.137998-1-jani.nikula@intel.com
-
- 16 Mar, 2022 10 commits
-
-
Ville Syrjälä authored
ICL+ PLLs can't genenerate certain frequencies. Running the PLL algorithms through for all frequencies 25-594MHz we see a gap just above 500 MHz. Specifically 500-522.8MHZ for TC PLLs, and 500-533.2 MHz for combo PHY PLLs. Reject those frequencies hdmi_port_clock_valid() so that we properly filter out unsupported modes and/or color depths for HDMI. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5247Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
DRRS operates on transcoder level, so we should only poke at it from the master crtc rather than letting every joined pipe give it potentially conflicting input. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
Let's just do a full DRRS disable/enable across all pipe updates. This guarantees that the DRRS work doesn't interfere with anything while the atomic commit is busy reprogramming the pipe. Needed so that we can start reprogramming M/N seamlessly during fastsets whenever possible. Also avoids the pre-bdw DRRS PIPECONF rmw racing with the potential PIPECONF write from the atomic commit (eg. due to GAMMA_MODE changes). v2: Include has_drrs in state dump (José) Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Schedule the DRRS downclock work already from intel_drrs_enable() instead of waiting around for a frontbuffer flush that may or may not ever come. Signed-off-by:
-
Ville Syrjälä authored
Skip all the DRRS work cancel/schedule stuff if the pipe's frontbuffer bits were not among those affected by the frontbuffer rendering. Signed-off-by:
-
Ville Syrjälä authored
Pre-determine the frontbuffer_bits for the each pipe during intel_drrs_enable(). Will become useful for bigjoiner use cases soon. Signed-off-by:
-
Ville Syrjälä authored
Now that DRRS can operate on multiple pipes we need to make sure one pipe doesn't throw away the other pipe's frontbuffer_bits before said pipe can handle them. Signed-off-by:
-
Ville Syrjälä authored
The DRRS refresh rate should be indented by one tab like the other per-crtc DRRS stuff. Signed-off-by:
-
Ville Syrjälä authored
With static DRRS the user might ask for the lowest possible refresh rate of the panel, in which case we're not going to find a suitable downclock mode for it and we should not try to enable seamless DRRS. This will in fact oops. We used to check for the presence of the downclock mode here, but that got removed in commit f0a57798 ("drm/i915: Introduce intel_panel_drrs_type()") as redundant (which it was at the time). But we do need the check again now that static DRRS is a thing. I must have not re-tested static DRRS fully after introducing intel_panel_drrs_type() :/ Fixes: c5ee2343 ("drm/i915: Implement static DRRS") Signed-off-by:
-
Ville Syrjälä authored
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Signed-off-by:
-
- 15 Mar, 2022 2 commits
-
-
José Roberto de Souza authored
If a error happens and sink_not_reliable is set, PSR should be disabled for good but that is not happening. It would be disabled by the function handling the PSR error but then on the next fastset it would be enabled again in _intel_psr_post_plane_update(). It would only be disabled for good in the next modeset where has_psr will be set false. v2: - release psr lock before continue Fixes: 9ce5884e ("drm/i915/display: Only keep PSR enabled if there is active planes") Reported-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Reported-by:
Charlton Lin <charlton.lin@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311185149.110527-2-jose.souza@intel.com
-
José Roberto de Souza authored
Commit 13ea6db2 ("drm/i915/edp: Ignore short pulse when panel powered off") completely broke short pulse handling for eDP as it is usually generated by sink when it is displaying image and there is some error or status that source needs to handle. When power panel is enabled, this state is enough to power aux transactions and VDD override is disabled, so intel_pps_have_power() is always returning false causing short pulses to be ignored. So here better naming this function that intends to check if aux lines are powered to avoid the endless cycle mentioned in the commit being fixed and fixing the check for what it is intended. v2: - renamed to intel_pps_have_panel_power_or_vdd() - fixed indentation Fixes: 13ea6db2 ("drm/i915/edp: Ignore short pulse when panel powered off") Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 14 Mar, 2022 18 commits
-
-
Ville Syrjälä authored
Store the fixed_mode and downclock_mode as a real list, in preparation for exposing other supported modes as well. v2: Init the list in intel_sdvo_connector_alloc() too v3: Use list_first_entry_or_null() (Jani) Reviewed-by:
-
Ville Syrjälä authored
Let's start supporting static DRRS by trying to match the refresh rate the user has requested, assuming the panel supports suitable timings. For now we stick to just our current two timings: - fixed_mode: the panel's preferred mode - downclock_mode: the lowest refresh rate mode we found Some panels may support more timings than that, but we'll have to convert our fixed_mode/downclock_mode pointers into a full list before we can handle that. v2: Rebase due to intel_panel_get_modes() Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
Nothing special about ivb+ here, if DRRS works on ivb+ port A it should work just as well on ilk/snb. So let's enable that. Reviewed-by:
-
Ville Syrjälä authored
No reason to keep the DRRS enable/disable hidden insider the encoder hooks. Let's just move them all the way up into platform independent code so that all platforms get to use them. These are nops when the state computation doesn't think DRRS is possible. Reviewed-by:
-
Ville Syrjälä authored
Ger rid of one more ugly crtc->config usage by storing the DRRS state under intel_crtc. intel_drrs_enable() copies what it needs from the crtc state, after which DRRS can be blissfully ignorant of anything going on around it. This also lets multiple pipes do DRRS simultanously and entirely independently. v2: Split out some stuff (Jani) Signed-off-by:
-
Ville Syrjälä authored
The DRRS code has no use for the intel_dp, replace it with just a crtc pointer. This is just an intermediate step towards making DRRS truly per-crtc. Signed-off-by:
-
Ville Syrjälä authored
Add helper to get the drrs type as a string, and use it in a couple of places. Also pimp the debugfs output a bit while at it. Signed-off-by:
-
Ville Syrjälä authored
Add a helper to determine which type of DRRS the panel supports. Signed-off-by:
-
Ville Syrjälä authored
There are a couple of cases where we essentially just want to get/check the preferred fixed mode of the panel. Add a small helper for that to abstract away the direct pointer lookup. Signed-off-by:
-
Ville Syrjälä authored
Several connectors want to return the fixed_mode from .get_modes(), add a helper to do that (and hide the details inside intel_panel.c). Signed-off-by:
-
Ville Syrjälä authored
Abstract away the details on where we store the fixed/downclock modes, and also how we select them. Will be useful for static DRRS (aka. allowing the user to select the refresh rate for the panel). We pass in the user requested mode to intel_panel_fixed_mode() so that in the future it may try to match the refresh rate. And intel_panel_downclock_mode() gets passed the adjusted_mode we actually chose to use so that it may find a suitable lower resresh rate variant. v2: Hook it up for all encoders s/fixed_mode/adjusted_mode/ in intel_panel_downclock_mode() (Jani) Elaborate on the choice or arguments for the functions (Jani) Signed-off-by: -
Ville Syrjälä authored
When we found a downclock mode dev_priv->drrs.type is just a straight copy of dev_priv->vbt.drrs_type. And in case we couldn't find a downclock mode can_enable_drrs() won't let us enable DRRS anyway so the minor distinction between the two is irrelevant. So let's just nuke dev_priv->drrs.type and consult the VBT version directly. Signed-off-by:
-
Ville Syrjälä authored
No need for all this connector type special casing. If the connector has a fixed mode just print it, otherwise don't. Signed-off-by:
-
Ville Syrjälä authored
We want to eventually get rid of the connector->panel.fixed_mode pointer so avoid using it during LVDS setup. Since this all happens during the encoder init we already have the fixed_mode around, just pass that in. Signed-off-by:
-
Ville Syrjälä authored
We want to stop using connector->panel.fixed_mode directtly. In order to look it up in the future we'll need to have the requested mode around, so pass that in fully (instead of just passing bits of it). Signed-off-by:
-
Ville Syrjälä authored
We want to eventually get rid of the connector->panel.fixed_mode pointer so avoid using it during DSI property setup. Since this all happens during the encoder init we already have the fixed_mode around, just pass that in. Signed-off-by:
-
José Roberto de Souza authored
Up to now alderlake-p was using the same eDP voltage swing table for frequencies up to HBR2 as icelake but now it has its own table. BSpec: 49291 Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220314152753.85081-1-jose.souza@intel.com
-
Jani Nikula authored
early-quirks.c is the only user of drm/i915_drm.h that also needs drm/i915_pciids.h. Include the masses of PCI ID macros only where needed. Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org Cc: x86@kernel.org Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311100639.114685-1-jani.nikula@intel.com
-
- 10 Mar, 2022 6 commits
-
-
Ville Syrjälä authored
Rename the PIPECONF refresh rate select bits to be less cryptic. Also nothing eDP specific about these as they also select between FP0 vs. FP1 for the DPLL and thus can be used to change the refresh rate on other output types as well. Signed-off-by:
-
Ville Syrjälä authored
Make the DRRS refresh rate enum less magical. Signed-off-by:
-
Ville Syrjälä authored
Make the drrs type enum less convoluted. Signed-off-by:
-
Ville Syrjälä authored
Grab the DRRS MSA timing delay value from the VBT and program things accordingly. Only ilk/snb/ivb have this so presumably on hsw+ we don't need it. Signed-off-by:
-
Ville Syrjälä authored
VBT hsa a field for the MSA timing delay, which supposedly should be used with DRRS. Extract the data from the VBT. Signed-off-by:
-
Ville Syrjälä authored
Use the standard [CONNECTOR:%d:%s] format in the DRRS debugs. Signed-off-by:
-
