summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-08drm/i915/psr: Disable Panel Replay as well if VRR is enabledJouni Högander
Having Panel Replay enabled together with VRR is causing following errors: xe 0000:00:02.0: [drm] *ERROR* Timed out waiting PSR idle state xe 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 xe 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun xe 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00040080 xe 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00040080 Let's disable Panel Replay as well if VRR is enabled. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031081025.3215966-1-jouni.hogander@intel.com
2024-11-07drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4Suraj Kandpal
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in hdcp 2.2 and we are not using an hdmi transcoder and it need to be enabled when we are using an HDMI transcoder to enable HDCP 1.4. We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so we cannot depend on the value being 0 by default everytime which calls for seprate handling of HDCP 1.4 case. --v2 -Use the exising function and modify it based on a bool rather than have a different function [Matt] --v3 -No need for kzalloc [Jani] --v4 -i915_reg_t should not be pointer [Jani] -use rekey_bit to ensure when writing to reg everything is initialized Bspec: 69964, 50493, 50054 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107022807.869744-1-suraj.kandpal@intel.com
2024-11-07drm/i915/cdclk: Unify cdclk max() parameter orderVille Syrjälä
In some places we do min_cdclk = max(min_cdclk, other_min_cdclk) and in other places we have the arguments swapped as min_cdclk = max(other_min_cdclk, min_cdclk) Unify everyone to use the first order of arguments, because it looks cleaner, especially within intel_crtc_compute_min_cdclk() which is doing a lot of these back-to-back. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Relocate intel_vdsc_min_cdclk()Ville Syrjälä
Move intel_vdsc_min_cdclk() into intel_vdsc.c from intel_cdclk.c so that details about DSC are better contained. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Drop pointles max_t() usage in intel_vdsc_min_cdclk()Ville Syrjälä
min_cdclk==0 when intel_vdsc_min_cdclk() calls max_t() on it. Drop the redundant max_t(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Suck the compression_enable check into intel_vdsc_min_cdclk()Ville Syrjälä
Declutter intel_crtc_compute_min_cdclk() by moving the crtc_state->dsc.compression_enable check into intel_vdsc_min_cdclk(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Factor out INTEL_OUTPUT_DSI check in vlv_dsi_min_cdclk()Ville Syrjälä
All the if statements in vlv_dsi_min_cdclk() check for INTEL_OUTPUT_DSI. Make life simpler by checking that just once at the start. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Extract vlv_dsi_min_cdclk()Ville Syrjälä
Pull the DSI min cdclk calculation into a helper and hide it inside vlv_dsi.c in order to keep most DSI related details in one place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Factor out has_audio check in intel_audio_min_cdclk()Ville Syrjälä
All the if statements in intel_audio_min_cdclk() check for has_audio==true. Check that once ahead of time to make things a bit simpler. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Extract intel_audio_min_cdclk()Ville Syrjälä
Pull the audio min cdclk calculation into a helper and hide it inside intel_audio.c in order to keep most audio related details in one place. The one audio related thing that remains in intel_cdclk.c is commit 451eaa1a614c ("drm/i915: Bump GLK CDCLK frequency when driving multiple pipes") but given that's implemented in terms of the cdclk_state I think it should stay put. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Extract hsw_ips_min_cdclk()Ville Syrjälä
Pull the whole BDW IPS min CDCLK stuff into the IPS code so that all the details around IPS are contained in once place. Note that while - min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 95); vs. + min_cdclk = max(DIV_ROUND_UP(crtc_state->pixel_rate * 100, 95), min_cdclk) may look different, they are in fact the same because min_cdclk==crtc_state->pixel_rate at this point in intel_crtc_compute_min_cdclk() on BDW. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Extract intel_cdclk_guardband() and intel_cdclk_ppc()Ville Syrjälä
We are duplicating the CDCLK guardband and "pixels per clock" figures in two places. Pull those out into small helpers that can be used by both places. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915: Introduce HAS_DOUBLE_WIDE()Ville Syrjälä
Make the code a bit more self documenting by adding HAS_DOUBLE_WIDE(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBTVille Syrjälä
Introduce a proper VBT->enum mipi_dsi_pixel_format converter instead of abusing pixel_format_from_register_bits() (whose job is to parse the pixel format from some pre-ICL DSI hardware register). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106220904.29523-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-06drm/i915/adlp+/dp_mst: Align master transcoder disabling with spec wrt. DP2 ↵Imre Deak
config On ADLP+ during modeset disabling, disable the DP2 configuration for MST master transcoders as required by the specification. Bspec: 55424, 54128, 65448, 68849 Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030192313.4030617-6-imre.deak@intel.com
2024-11-06drm/i915/adlp+/dp_mst: Align slave transcoder sequences with spec wrt. DP2 ↵Imre Deak
config On ADLP+ during modeset enabling and disabling, enable and disable the DP2 configuration for MST slave transcoders as required by the specification. Update the documentation of intel_ddi_config_transcoder_func() / intel_ddi_disable_transcoder_func() based on the above. While at it also clarify the programming steps of these functions specific to transcoder types. v2: - Enable/disable the DP2 config from intel_ddi_config_transcoder_func()/intel_ddi_disable_transcoder_func(). (Jani) - Handle all ADLP+ platforms in one patch, instead of doing that separately wrt. PTL. Bspec: 55424, 54128, 65448, 68849 Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030192313.4030617-5-imre.deak@intel.com
2024-11-06drm/i915/dp_mst: Add a way to disable the DP2 configImre Deak
Add a way to disable the DP2 configuration, required by the next patch during transcoder disabling. While at it drop the redundant encoder parameter. v2: - Keep intel_ddi_config_transcoder_dp2() static. (Jani) - Remove the encoder parameter. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030192313.4030617-4-imre.deak@intel.com
2024-11-06drm/i915/adlp+/dp_mst: Align slave transcoder enabling with spec wrt. DDI ↵Imre Deak
function On ADLP+ during modeset enabling configure the DDI function without enabling it for MST slave transcoders before programming the data and link M/N values. The DDI function gets enabled separately later in the transcoder enabling sequence. Align the code with the spec based on the above. v2: Move this patch earlier in the series, addressing the DP2 config fixes for all ADLP+ platforms later. Bspec: 55424, 54128, 65448, 68849 Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030192313.4030617-3-imre.deak@intel.com
2024-11-06drm/i915/ptl/dp_mst: Fix slave transcoder enabling wrt. DDI functionImre Deak
On PTL during modeset enabling configure the DDI function without enabling it for MST slave transcoders before programming the data and link M/N values. The DDI function gets enabled separately later in the transcoder enabling sequence. This fixes a slave transcoder getting stuck during enabling, leading to page flip timeout errors on the corresponding pipe. The spec requires the same programming step for ADLP+ platforms, that will be addressed separately (on those platforms the above transcoder getting stuck issue was not observed). Bspec: 68849 Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030192313.4030617-2-imre.deak@intel.com
2024-11-06drm/i915: Simplify xelpdp_is_only_pipe_per_dbuf_bank()Ville Syrjälä
Implement xelpdp_is_only_pipe_per_dbuf_bank() in a slightly more straightforward way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-06drm/i915: Sanitize MBUS joiningVille Syrjälä
If the system boots with MBUS joining enabled but we disable the relevant pipe during sanitation we later get into trouble as the rest of the code doesn't expect MBUS joining to be enabled unless the set of active pipes is in agreement. We could relax some of the MBUS joining related checks during normal atomic commits to let this slide, but that might also let some real bugs through. So let's sanitize the MBUS joining instead. And in order to keep things more or less in sync we'll do the related credit, cdclk/mdclk ratio, etc. updates as well. We'll stick to sturct drm_i915_private for now (instead of struct intel_display) since the rest of the skl wm code does the same, and we might need to bakport this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-06drm/i915: Extract mbus_ctl_join_update()Ville Syrjälä
We'll be wanting to reprogram the MBUS_CTL register during an upcoming MBUS sanitation stage. Extract the reprogramming into a helper that doesn't depend on the full atomic state so that it can be reused. We'll stick to sturct drm_i915_private for now (instead of struct intel_display) since the rest of the skl wm code does the same, and we might need to bakport this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-06drm/i915: Extract pipe_mbus_dbox_ctl_update()Ville Syrjälä
We'll be wanting to reprogram the PIPE_MBUS_DBOX_CTL registers during an upcoming MBUS sanitation stage. Extract the reprogramming loop into a helper that doesn't depend on the full atomic state so that it can be reused. We'll stick to sturct drm_i915_private for now (instead of struct intel_display) since the rest of the skl wm code does the same, and we might need to bakport this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-06drm/i915: Extract pipe_mbus_dbox_ctl()Ville Syrjälä
We'll be wanting to reprogram the PIPE_MBUS_DBOX_CTL registers during an upcoming MBUS sanitation stage. To make that easier extract a helper that computes the full register value for us. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-06drm/i915: Relocate the SKL wm sanitation codeVille Syrjälä
In order to add more MBUS sanitation into the code we'll want to reuse a bunch of the code that performs the MBUS/related hardware programming. Currently that code comes after the main skl_wm_get_hw_state_and_sanitize() entrypoint. In order to avoid annoying forward declarations relocate the skl_wm_get_hw_state_and_sanitize() and related stuff nearer to the end of the file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-06drm/i915/dp: Enable 3 DSC engines for 12 slicesAnkit Nautiyal
Certain resolutions require 12 DSC slices support along with ultrajoiner. For such cases, the third DSC Engine per Pipe is enabled. Each DSC Engine processes 1 Slice, resulting in a total of 12 VDSC slices (4 Pipes * 3 DSC Instances per Pipe). Add support for 12 DSC slices and 3 DSC engines for such modes. v2: Add missing check for 3 slices support only with 4 joined pipes. (Suraj) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-8-ankit.k.nautiyal@intel.com
2024-11-06drm/i915/dp: Ensure hactive is divisible by slice countAnkit Nautiyal
According to the DSC spec, the slice width should be chosen such that the picture width (hactive) is evenly divisible by the slice width. If not, extra pixels (padding) must be added to the last slice to ensure all slices have the same width. Currently, we do not support handling these extra pixels. Therefore, select a slice count that evenly divides the hactive (slice_width = hactive / slice_count). This check is already implemented for DSI, where the slice count is selected from the BIOS. For DP, currently with 1, 2, 4 slices per pipe it is unlikely to have slice count not being able to divide hactive, but with 3 DSC engines and 3 slices, we can have such cases. Adding this check prepares for future scenarios where such configurations might be used. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-7-ankit.k.nautiyal@intel.com
2024-11-06drm/i915/vdsc: Add support for read/write PPS for 3rd DSC engineAnkit Nautiyal
With BMG each pipe has 3 DSC engines, so add bits to read/write the PPS registers for the 3rd DSC engine Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-6-ankit.k.nautiyal@intel.com
2024-11-06drm/i915/vdsc: Introduce 3rd VDSC engine VDSC2Ankit Nautiyal
Introduce the register bits to enable the 3rd DSC engine VDSC2. Add support to read/write these bits. v2: Only introduce bits that are used and update the subject and commit message. (Suraj) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-5-ankit.k.nautiyal@intel.com
2024-11-06drm/i915/vdsc: Use VDSC0/VDSC1 for LEFT/RIGHT VDSC engineAnkit Nautiyal
Drop use of LEFT/RIGHT VDSC engine and use VDSC0/VDSC1 instead. While at it, use REG_BIT macro for the bits. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-4-ankit.k.nautiyal@intel.com
2024-11-06drm/i915/display: Prepare for dsc 3 stream splitterAnkit Nautiyal
At the moment dsc_split represents whether the dsc splitter is used or not. With 3 DSC engines, the splitter can split into two streams or three streams. Instead of representing the splitter's state, it is more effective to represent the number of DSC streams per pipe. Replace the `dsc.dsc_split` member with `dsc.num_streams` to indicate the number of DSC streams used per pipe. This change will implicitly convey the splitter's operation mode. v2: Avoid new enum for dsc split. (Suraj) v3: -Replace dsc_split with num_stream. (Suraj) -Avoid extra parentheses. (Jani) v4: Set num_streams to 1, if VDSC_JOINER not set while readout. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-3-ankit.k.nautiyal@intel.com
2024-11-06drm/i915/dp: Update Comment for Valid DSC Slices per LineAnkit Nautiyal
For some platforms, the maximum slices per DSC engine is 4, while for others it is 2. Update the comment to reflect this and clarify that the 'valid_dsc_slicecount' list represents the valid number of slices per pipe. Currently, we are working with 1, and 2 slices per DSC engine, which works for all platforms. With this the number of slices per pipe can be 1,2 or 4 with different slice & DSC engine configuration. Add a #TODO for adding support for 4 slices per DSC engine where supported. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-2-ankit.k.nautiyal@intel.com
2024-11-05drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.Daniele Ceraolo Spurio
All MTL and ARL SKUs share the same GSC FW, but the newer platforms are only supported in newer blobs. In particular, ARL-S is supported starting from 102.0.10.1878 (which is already the minimum required version for ARL in the code), while ARL-H and ARL-U are supported from 102.1.15.1926. Therefore, the driver needs to check which specific ARL subplatform its running on when verifying that the GSC FW is new enough for it. Fixes: 2955ae8186c8 ("drm/i915: ARL requires a newer GSC firmware") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028233132.149745-1-daniele.ceraolospurio@intel.com
2024-11-05drm/i915: hide VLV PUNIT IOSF sideband qos handling betterJani Nikula
The sideband latency qos request is only used for VLV PUNIT access. Abstract it better, and also add the request for VLV only. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/92632f64c1256bfafe7ebf49c1ad0618157d9484.1730193891.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-05drm/i915: add a dedicated mutex for VLV/CHV IOSF sidebandJani Nikula
The VLV/CHV IOSF sideband is unrelated to pcode. It's just confusing to piggyback on the same mutex. Add a dedicated lock with init and cleanup functions. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/31ccbf33c6b6114d0bcb40a2e174f19162d4e177.1730193891.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-05drm/i915/sbi: add a dedicated mutex for LPT/WPT IOSF sidebandJani Nikula
The LPT/WPT IOSF sideband is unrelated to pcode or VLV/CHV IOSF sideband. It's just confusing to piggyback on the same mutex. Add a dedicated lock with init and cleanup functions. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/139933094fe51fccdbe14d4e20df69782e801905.1730193891.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-05drm/i915/sbi: add intel_sbi_{lock,unlock}()Jani Nikula
Abstract the LPT/WPT IOSF sideband locking by adding dedicated sbi lock/unlock functions. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/61929c2fad4d4ff64e57ea2a28007f2efeb5113c.1730193891.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-05drm/i915/xe3lpd: Update HDCP rekeying bitSuraj Kandpal
The TRANS_DDI_FUNC_CTL bit used to enable/disable HDCP rekeying has moved from bit 12 (Xe2) to bit 15 (Xe3); update the RMW toggle accordingly. Also drop the misleading workaround comment tag on this function since disabling of HDCP rekeying is something that happens on all platforms, not just those impacted by that workaround. While we're here, also re-order the if/else ladder to use standard "newest platform first" order. v2: add additional definition instead of function, commit message typo fix and update. v3: restore lost conditional from v2. v4: subject line and subject message updated, fix the if ladder order, fix the bit definition order. v5: Add the bspec link and remove the Wa comment tag v6: Rebase over new changes v7: Fix commit subject and message, reladder the if/else blocks Bspec: 69964 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241104185055.739605-1-suraj.kandpal@intel.com
2024-11-04drm/i915/display: Allow fastset for change in HDR infoframeChaitanya Kumar Borah
Changes in Dynamic Range and Mastering infoframe should not trigger a full modeset. Therefore, allow fastset. DP SDP programming is already hooked up in the fastset flow but HDMI AVI infoframe update is not, add it. Any other infoframe that can be fastset should be added to the helper intel_hdmi_fastset_infoframes(). v3: - Create a wrapper intel_ddi_update_pipe_hdmi to stick to uniform naming (Jani) - Do not disable HDMI AVI infoframe if already disabled (Uma) v2: - Update HDMI AVI infoframe during fastset. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023044122.3889137-1-chaitanya.kumar.borah@intel.com
2024-11-04drm/i915/psr: WA for panels stating bad link status after PSR is enabledJouni Högander
We are currently seeing unexpected link trainings with several different eDP panels. These are caused by these panels stating bad link status in their dpcd registers. This can be observed by doing following test: 1. Boot up without Xe module loaded 2. Load Xe module with PSR disabled: $ modprobe xe enable_psr=0 3. Read panel link status register $ dpcd_reg read --offset 0x200e --count=1 0x200e: 00 4. Enable PSR, sleep for 2 seconds and disable PSR again: $ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug $ echo "-1" > /sys/kernel/debug/dri/0000:00:02.0/xe_params/enable_psr $ echo 0x0 > /sys/kernel/debug/dri/0/i915_edp_psr_debug $ sleep 2 $ cat /sys/kernel/debug/dri/0/i915_edp_psr_status | grep status $ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug Source PSR/PanelReplay status: DEEP_SLEEP [0x80310030] 5. Now read panel link status registers again: $ dpcd_reg read --offset 0x200e --count=1 0x200e: 80 Workaround this by not trusting link status registers after PSR is enabled until first short pulse interrupt is received. v2: - clear link_ok flag on pipe disable - remove useless comment - modify intel_dp_needs_link_retrain return statement Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029122415.1789528-1-jouni.hogander@intel.com
2024-11-04drm/i915/dp: Add FEC Enable Retry mechanismChaitanya Kumar Borah
Currently, even though there is a bit to control FEC enable/disable individually, the FEC Decode Enable sequence is sent by the SOC only once TRANS_CONF enable is set. This ties the FEC enabling too tightly to modeset and therefore cannot be re-issued (in case of failure) without a modeset. From PTL, FEC_DECODE_EN sequence can be sent to a DPRX independent of TRANS_CONF enable. This allows us to re-issue an FEC_DECODE_EN sequence without a modeset. Hence allowing us to have a retry mechanism in case the DPRX does not respond with an FEC_ENABLE within certain amount of time. While at it, replace struct drm_i915_private with struct intel_display v4: - More code refactor [Jani] - use struct intel_display [Jani] - Optimize logging [Jani] v3: - Make the commit message more legible [Jani] - Refactor code to re-use existing code [Jani] - Do away with platform dependent FEC enable checks [Jani] v2: - Refactor code to avoid duplication and improve readability [Jani] - In case of PTL, wait for FEC status directly after FEC enable [Srikanth] - Wait for FEC_ENABLE_LIVE_STATUS to be cleared before re-enabling FEC [Srikanth] Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241024061002.4085137-1-chaitanya.kumar.borah@intel.com
2024-11-01drm/i915/display: Fuse bit for power management disable removedClint Taylor
Starting with display version 13 the fuse bit to disable Display PM has been removed. v2: Bit removed starting with display version 13 (MattR) v3: DG2 still uses this fuse bit (MattR) Bspec: 50075, 69464 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030195507.2753404-1-clinton.a.taylor@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-31drm/i915: Implement Dbuf overlap detection feature starting from LNLStanislav Lisovskiy
From LNL onwards there is a new hardware feature, which allows to detect if the driver wrongly allocated DBuf entries and they happen to overlap. If enabled this will cause a specific interrupt to occur. We now handle it in the driver, by writing correspondent error message to kernel log. v2: Initialize dbuf overlap flag in runtime_defaults (Jani Nikula) v3: Unmask the overlap detection interrupt (Uma) v4: use display over i915 (Jani Nikula) v5: Use display instead of dev_priv (Jani Nikula) v6: rebased to resolve merge conflicts Bspec: 69450, 69464 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241030103319.207235-1-vinod.govindapillai@intel.com
2024-10-31drm/i915/dp: Write the source OUI for non-eDP sinks as wellImre Deak
At least the i-tec USB-C Nano 2x Display Docking Station (containing a Synaptics MST branch device) requires the driver to update the source OUI DPCD registers to expose its DSC capability. Accordingly update the OUI for all sink types (besides eDP where this has been done already). v2: Rebased on latest patch version. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11776 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-9-imre.deak@intel.com
2024-10-31drm/i915/dp: Write the source OUI during connector detectionImre Deak
The DP sink's capabilities, like DSC, may depend on the source OUI written to the sink. On eDP this OUI value could have been reset before the detection started if the panel power on it got disabled. Make sure the OUI is re-written at the beginning of detection in this case, before the sink capabilities are read out. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-8-imre.deak@intel.com
2024-10-31drm/i915/dp: Write the source OUI for eDP before detecting sink capabilitiesImre Deak
The eDP sink's capabilities, like DSC, may depend on the source OUI written to the sink, so ensure the OUI is written before reading out the capabilities. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-7-imre.deak@intel.com
2024-10-31drm/i915/dp: Reuse intel_dp_detect_dsc_caps() for eDPImre Deak
Reuse intel_dp_detect_dsc_caps() which already checks for the source's DSC cap and retrieves the DPCD version from the DPRX caps. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-6-imre.deak@intel.com
2024-10-31drm/i915/dp: Track source OUI validity explicitlyImre Deak
While updating the source OUI on the sink the driver should avoid writing the OUI if it's already up-to-date to prevent the sink from resetting itself in response to the update. On eDP - the only output type where the OUI was updated so far - the driver ensured this by comparing the current source OUI DPCD register values with the expected Intel OUI value, skipping the update in case of a match. On some non-eDP sinks - at least on Synaptics branch devices - this method doesn't work, since the source OUI DPCD registers read back as all 0, even after updating the registers. Handle the above kind of sinks by tracking when the OUI was updated and so should be valid, regardless of what the DPCD registers contain. eDP sinks reset the written source OUI value when the panel power is disabled, invalidate the OUI state accordingly. This is required by a follow-up patch updating the source OUI for non-eDP sink types as well. v2: Fix setting intel_dp::oui_valid=true, if the DPCD register contains already the expected value. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-5-imre.deak@intel.com
2024-10-31drm/i915/dp: Initialize the source OUI write timestamp alwaysImre Deak
If the source OUI DPCD register value matches the expected Intel OUI value, the write timestamp doesn't get updated leaving it at the 0 initial value if the OUI wasn't written before. This can lead to an incorrect wait duration in intel_dp_wait_source_oui(), since jiffies is not inited to 0 in general (on a 32 bit system INITIAL_JIFFIES is set to 5 minutes ahead of wrap-around). Fix this by intializing the write timestamp in the above case as well. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-4-imre.deak@intel.com
2024-10-31drm/i915/dp: Ensure panel power remains enabled during connector detectionImre Deak
The sink's capabilities, like the DSC caps, depend on the source OUI written to the sink's DPCD registers and so this OUI value should be valid for the whole duration of the detection. An eDP sink will reset this OUI value when the panel power is disabled, so prevent the disabling - happening by default after a 1 sec idle period - for the whole duration of detection. v2: Update the documentation for intel_pps_on(). (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-3-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 22:44:54 +0000