- Jan 23, 2025
-
-
Ankit Nautiyal authored
Try SNPS_PHY HDMI alogorithm, if there are no pre-computed tables. Also get rid of the helper to get rate for HDMI snps phy, as we no longer depend only on pre-computed tables. v2: -Prefer pre-computed tables over computed values from algorithm. (Jani) Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Suraj Kandpal <suraj.kandpal@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250120042122.1029481-3-ankit.k.nautiyal@intel.com
-
Ankit Nautiyal authored
Add helpers to calculate the necessary parameters for configuring the HDMI PLL for SNPS MPLLB and C10 PHY. The pll parameters are computed for desired pixel clock, curve data and other inputs used for interpolation and finally stored in the pll_state. Currently the helper is used to compute PLLs for DG2 SNPS PHY. Support for computing Plls for C10 PHY is added in subsequent patches. v2: -Used kernel types instead of C99 types. (Jani) -Fixed styling issues and renamed few variables to more meaningful names. (Jani) -Added Xe make file changes. (Jani) -Fixed build errors reported by kernel test robot v3: -Renamed helper to align with file name. (Jani) v4: -Removed erroraneous comment, and added Bspec# as part of trailer. (Suraj) -Fixed warning flagged by kernel test robot. Bspec: 54032 Signed-off-by:
-
- Jan 22, 2025
-
-
Imre Deak authored
Use the driver's standard intel_display::platform.alderlake_p instead of IS_ALDERLAKE_P(). Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250108151916.491113-6-imre.deak@intel.com
-
Imre Deak authored
Simplify getting a drm_device pointer when using to_i915() in intel_dp_mst.c from the already available intel_display object, instead of getting it from a DRM KMS object. While at it rename dev_priv to i915, following the driver's standard terminology. Suggested-by:
-
Imre Deak authored
Simplify the use of to_intel_display() in intel_dp_mst.c passing it the already available intel_connector pointer, instead of looking up a drm_device pointer for the same purpose. Suggested-by:
-
Imre Deak authored
Follow the canonical way in intel_dp_mst.c, referencing a connector only via a struct intel_connector pointer and naming this pointer 'connector' instead of 'intel_connector', the only exception being the casting of a drm_connector function parameter pointer to intel_connector, calling the drm_connector pointer _connector. Suggested-by:
-
Imre Deak authored
After an error during adding an MST connector the MST port and the intel_connector object could be leaked, fix this up. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ankit Nautiyal authored
While setting the bounds for compressed bpp, we ensure that the compressed bpp is less than the pipe bpp. This causes an issue with the 420 output format, where the effective link bpp (or output bpp) is half that of the pipe bpp. Therefore instead of using pipe bpp, use the output bpp to set the bounds for the compressed bpp. v2: Use identifier output_bpp instead of link_bpp (Imre) Signed-off-by:
-
- Jan 21, 2025
-
-
Guenter Roeck authored
The scale() functions detects invalid parameters, but continues its calculations anyway. This causes bad results if negative values are used for unsigned operations. Worst case, a division by 0 error will be seen if source_min == source_max. On top of that, after v6.13, the sequence of WARN_ON() followed by clamp() may result in a build error with gcc 13.x. drivers/gpu/drm/i915/display/intel_backlight.c: In function 'scale': include/linux/compiler_types.h:542:45: error: call to '__compiletime_assert_415' declared with attribute error: clamp() low limit source_min greater than high limit source_max This happens if the compiler decides to rearrange the code as follows. if (source_min > source_max) { WARN(..); /* Do the clamp() knowing that source_min > source_max */ source_val = clamp(source_val, source_min, source_max); } else { /* Do the clamp knowing that source_min <= source_max */ source_val = clamp(source_val, source_min, source_max); } Fix the problem by evaluating the return values from WARN_ON and returning immediately after a warning. While at it, fix divide by zero error seen if source_min == source_max. Analyzed-by:Linus Torvalds <torvalds@linux-foundation.org> Suggested-by:
David Laight <david.laight.linux@gmail.com> Cc: David Laight <david.laight.linux@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
-
Ville Syrjälä authored
Now that we know how to issue the push with the DSB we can allow the DSB to drive the commits even when VRR is active. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
We have at least two options for how to do the TRANS_PUSH_SEND + commit completion signalling with the DSB: Option A) 1. trigger TRANS_PUSH_SEND 2. wait for "safe window" 3. signal the interrupt In this cases step 2 should not do anything if we were already between vmin and vmax decision boundaries. Otherwise we'll wait until the next start of the vblank period. Option B) 1. wait for "safe window" 2. trigger TRANS_PUSH_SEND 3. signal the interrupt This option is perhaps a bit less racy, but if we do somehow screw up and the wait is a nop but the push gets deferred until the next frame then we'll end up completing the commit a frame too early. So for now I'm leaning towards option A since losing the race won't have any drastic consequences. To deal with the race we can give the DSB a bit more time to start step 2 before the hardware has started the vblank termination properly. Often times it seems to be fast enough to make it in time even without any extra vblank delay (the push is issued somewhere within a scanline and it latches on the next scanline). v2: Use intel_vrr_possible() to determine if we need some vblank delay (also avoids adding it for DSI which doens't actually program the transcoder registers correctly for it) Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: -
Ville Syrjälä authored
GOP might not agree with our idea of what the vblank delay should be. Reuse the LRR codepaths to fix that up via a fastset. The relevant registers aren't actually double buffered so this is a little bit dodgy. While I've not seen any real issues from frobbing these live, let's limit this to just the fastboot case (by only allowing it when old_crtc_state->inherited==true). Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Pull the "do we actually need a LRR update?" checks into a small helper for clarity. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
intel_set_transcoder_timings*() aren't currently suitable for DSI. Warn if someone accidentally calls them in such cases. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Update TRANS_SET_CONTEXT_LATENCY in intel_set_transcoder_timings_lrr() as well. While for actual LRR updates this should not change, I want to reuse this code to also sanitize the vblank delay during boot, and in that case we do need to update this. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
I want to start using intel_set_transcoder_timings_lrr() also for fixing up the vblank delay during boot. To that end make sure it can cope with interlaced modes as well. Note that we have soft-defeatured interlaced modes on tgl+ so technically this is dead code, but if we ever have the need to bring interlaced support back it seems better to handle this. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
intel_set_transcoder_timings() will set TRANS_VBLANK.vblank_start to 0 for clarity on ADL+ (non-DSI) because the hardware no longer uses that value. Do the same in intel_set_transcoder_timings_lrr() to make sure the registers stay consistent even when doing LRR timing updates. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by:
-
Imre Deak authored
Code for the DP tunnelling functionality in the xe driver can be built only if the display code is also built, adjust the kconfig dependency accordingly. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Fixes: 73900dce ("drm/xe/dp: Enable DP tunneling") Reported-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Maarten Lankhorst authored
This is already handled below in the code by fixup_initial_plane_config. Fixes: a8153627 ("drm/i915: Try to relocate the BIOS fb to the start of ggtt") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
Maarten Lankhorst <dev@lankhorst.se>
-
Jouni Högander authored
Currently we are forcing full modeset if Panel Replay mode is changed. This is not necessary as long as we are not changing sink PANEL REPLAY ENABLE bit in PANEL REPLAY ENABLE AND CONFIGURATION 1 register. This can be achieved by entering Panel Replay inactive mode (Live Frame mode) when Panel Replay is disabled and keep PANEL REPLAY ENABLE bit in PANEL REPLAY ENABLE AND CONFIGURATION 1 enabled always if panel is just supporting Panel Replay. Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-5-jouni.hogander@intel.com
-
Jouni Högander authored
Intel_psr_enable_sink is not used outside intel_psr.c. Convert it as local static function. Signed-off-by:
-
Jouni Högander authored
Currently we are configuring Panel Replay on sink when it get's enabled. This means we need to do full modeset when enabling Panel Replay. This is required as DP specification is saying sink Panel Replay needs to be configured before link training. Avoid full modeset by enabling Panel Replay on sink always when it's supported by the sink and the source. Signed-off-by:
-
Jouni Högander authored
According to DP/eDP specification only DP_PANEL_REPLAY_ENABLE has to be set prior link training. For this purpose add a new function which sets this bit on sink side if Panel Replay is supported by the sink and the source. Signed-off-by:
-
Maarten Lankhorst authored
i915 has this really nice, infrastructure where everything becomes complicated, GGTT needs eviction, etc.. Lets not do that, and make the dumbest possible interface instead. Try to retrieve the VMA from old_plane_state, or intel_fbdev if kernel fb. Link: https://patchwork.freedesktop.org/patch/msgid/20241206182032.196307-1-dev@lankhorst.se Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Tested-by:
Jani Saarinen <jani.saarinen@intel.com>
-
surajk8 authored
Use intel_encoder_is_hdmi function which was recently introduced to see if encoder is HDMI or not. --v2 -Add Fixes tag [Jani] Fixes: 6a3691ca ("drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI") Signed-off-by:
-
- Jan 20, 2025
-
-
Ville Syrjälä authored
Split skl_get_plane_caps() into four variants: skl_plane_caps(), glk_plane_caps(), icl_plane_caps(), tgl_plane_caps(). Makes it easier to figure out what is actually going on there. v2: skl_plane_caps() should return u8 not bool Signed-off-by:
-
Ville Syrjälä authored
Move the xe AUX neutering out from skl_get_plane_caps() into the caller so that it'll be easier to refactor skl_get_plane_caps() into a more readable shape. This isn't really hardware specific anyway, and just some kind of bug/misfeature of xe. Signed-off-by:
-
Ville Syrjälä authored
Wa_22011186057 (some CCS problem) only affected ADL A-stepping, which I presume is pre-production hw. Drop the dead code. Bspec: 54369 Signed-off-by:
-
Ville Syrjälä authored
TGL+ should no longer need any VT-d scanout workarounds. Don't apply any. Not 100% sure whether pre-SNB might also suffer from this. The workaround did originate on SNB but who knows if it was just never caught before that. Not that I ever managed to enable VT-d any older hardware. Last time I tried on my ILK it ate the disk! Signed-off-by:
-
Ville Syrjälä authored
Rename vlv_primary_min_alignment() to vlv_plane_min_alignment() and use it to replace vlv_sprite_min_alignment() since the behaviour is now identical when the plane init doesn't set up any async flips stuff. Technically VLV/CHV sprites do support async flips, so this also makes us a bit more future proof if/when we extend async flip support to more than one plane. Signed-off-by:
-
Ville Syrjälä authored
Async flips often require bigger alignment that sync flips. Currently we have HAS_ASYNC_FLIPS() checks strewn about to inidcate that async flips are generally supported and thus we want more alignment. Switch that over to using intel_plane_can_async_flip() so that we can handle these in a slightly less messy way. Currently we don't have cases where async flips would require different alignment for different modifiers on the same plane. We'll also move the HAS_ASYNC_FLIPS() check to the plane init code so that we can still use that as a quick way to disable the async flips workarounds for testing purposes. Signed-off-by:
-
Ville Syrjälä authored
Move the "does this modifier support async flips?" check to be handled by the platform specific plane code instead of having a big mess in common code. Signed-off-by:
-
Ville Syrjälä authored
Apparently ICL can do async flips with CCS. In fact it already seems to work on GLK, but apparently can lead to underruns there so we'll only enable it for ICL. Signed-off-by:
-
Ville Syrjälä authored
Looks like CCS + async flips has been a thing for a while now. Enable this for TGL+ render compression modifiers. Note that we can't update AUX_DIST during async flips we must check to make sure it remains unchanged. We also can't do clear color. Supposedly there was some attempt to make it work, but apparently the issues only got ironed out in MTL. For now we'll not worry about it and refuse async flips with clear color modifiers. Bspec claims that media compression doesn't support async flips. Based on a quick test it does seem to work to some degree, but perhaps it has issues as well. Let's trust the spec here and continue to refuse async flips + media compression. Bspec: 49250,49251,49252,49253 Signed-off-by:
-
- Jan 17, 2025
-
-
Gustavo Sousa authored
Pipe interrupt registers live in their respective pipes' power wells, which are below PG0. That means that they must also be tracked as registers that are powered-off during dynamic DC states. There are probably more ranges that we need to track down and add to the powered_off_ranges. However, let's make this change only about pipe interrupt registers to fix some vblank timeouts observed due to the DMC wakelock not being taken for those registers. In the future, we might want to replace powered_off_ranges with a new table to represent registers in PG0, which should be probably easier to maintain. Any register not belonging to that table should be considered powered off during dynamic DC states and, as such, requiring the DMC wakelock for access. Bspec: 72519, 71583 Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250113204306.112266-4-gustavo.sousa@intel.com
-
Gustavo Sousa authored
The current display IRQ code calls some IRQ-specific helpers that use intel_uncore_*() MMIO functions instead of the display-specific ones. Wrap those helpers to ensure that the proper display-specific hooks (currently only DMC wakelock handling) are called. v2: - Move functions to intel_display_irq.c instead of having them in intel_de.h. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Most of MMIO accesses from intel_display_irq.c are currently done via uncore_*() functions instead of the display-specific ones, namely intel_de_*(). Because of that, DMC wakelock ends up being ignored and some invalid MMIO accesses are performed while display is in dynamic DC states. Thus, update the display IRQ code to use the intel_de_*() MMIO functions. After this change, we are left with some IRQ-specific functions that still use the unwrapped uncore_*() functions (i.e. gen2_irq_init, gen3_irq_reset and gen2_assert_iir_is_zero). We will deal with them in an upcoming change. Reviewed-by:
-
Ankit Nautiyal authored
DSC with YCbCr420 is now supported, so remove the comment mentioning support for only 444 format. Signed-off-by:
-
Ankit Nautiyal authored
We get range_bpg_offset for different bpps based on linear-interpolation from values given for nearby bpps. Use a helper to get these values. Signed-off-by:
Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250110044131.3162682-2-ankit.k.nautiyal@intel.com
-
surajk8 authored
When topology changes, before beginning a new HDCP authentication by sending AKE_init message we need to first authenticate only the repeater. Only after repeater authentication failure, it makes sense to start a new HDCP authentication. Even though it made sense to not enable HDCP directly from check_link and schedule it for later, repeater authentication needs to be done immediately. --v2 -Fix comment grammatical errors [Ankit] Fixes: 47ef55a8 ("drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link") Signed-off-by:
-
