summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-10-29drm/i915/display: convert I915_STATE_WARN() to struct intel_displayJani Nikula
Convert I915_STATE_WARN() to struct intel_display *, and rename to INTEL_DISPLAY_STATE_WARN(). Do some minor opportunistic struct drm_i915_private to struct intel_display conversions while at it. v2: crtc_state may be NULL in intel_connector_verify_state() Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241024162510.2410128-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-29drm/i914/xe3lpd: Increase bigjoiner limitationsSuraj Kandpal
With 6k resolution support for a single crtc being added bigjoiner will only come into picture when hdisplay > 6144 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028074333.182041-4-suraj.kandpal@intel.com
2024-10-29drm/i915/psr: Change psr size limits checkSuraj Kandpal
Change the check to only check for psr size limits till Pre-Xe2 since after that the psr size is equal to maximum pipe size anyways. --v2 -Check only size limit until pre-Xe2 [Matt] --v3 -Make sure psr_max_{h,v} and max_bpp are equal to crtc_{h,v}_display and pipe_bpp [Ankit] Bspec: 69885, 68858 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028130012.199090-1-suraj.kandpal@intel.com
2024-10-29drm/i915/xe3lpd: Increase resolution for plane to support 6kSuraj Kandpal
DISPLAY_VER >= 30 onwards CRTC can now support 6k resolution. Increase pipe and plane max width and height to reflect this increase in resolution. --v2 -Take care of the subsampling scenario sooner rather than later [Matt] --v3 -Take care of the joined pipe limits too [Ankit/Matt] --v4 -Leave the joiner limits check here as is and handle them later [Ville] Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028074333.182041-2-suraj.kandpal@intel.com
2024-10-28drm/i915: Use string enable/disable choice helpersSai Teja Pottumuttu
Replace the last few remaining instances of string enable(d)/disable(d) choices with the linux string choice helpers to avoid further cocci warnings. Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023054655.4017489-1-sai.teja.pottumuttu@intel.com
2024-10-28drm/i915/xe2lpd: Update C20 algorithm to include tx_miscGustavo Sousa
There has been an update to the BSpec in which we need to set tx_misc=0x5 field for C20 TX Context programming for HDMI TMDS for Xe2_LPD and newer. That field is mapped to the bits 7:0 of SRAM_GENERIC_<A/B>_TX_CNTX_CFG_1, which in turn translates to tx[1] of our state struct. Update the algorithm to reflect this change. v2: - Fix Bspec reference (Sai Teja) - Use struct intel_display instead of drm_i915_private. (Jani) - Use the correct bit width for C20_PHY_TX_MISC_MASK. (Jani) Bspec: 74491 Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> #v1 Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023153352.144146-3-gustavo.sousa@intel.com
2024-10-28drm/i915/cx0: Pass crtc_state to intel_c20_compute_hdmi_tmds_pll()Gustavo Sousa
The variable crtc_state already contains everything that intel_c20_compute_hdmi_tmds_pll() needs. Simplify the function's signature by passing that struct instead of separate variables. Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023153352.144146-2-gustavo.sousa@intel.com
2024-10-28drm/xe/hdcp: Fix gsc structure check in fw check statusSuraj Kandpal
Fix the condition for gsc structure validity in gsc_cs_status_check(). It needs to be an OR and not an AND condition Fixes: b4224f6bae38 ("drm/xe/hdcp: Check GSC structure validity") 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/20241025160834.8785-1-suraj.kandpal@intel.com
2024-10-28drm/i915/display: Add Wa_16023981245Nemesa Garg
Disable the support for odd panning in x direction. v2: Replace HSD with WA in commit message [Suraj] Modified the condition for handling odd panning v3: Simplified the condition for checking hsub Using older framework for wa as rev1[Jani] v4: Modify the condition for hsub [Sai Teja] Initialize hsub in else path [Dan] v5: Replace IS_LUNARLAKE with display version. Resolve nitpicks[Jani] v6: Replace -EINVAL with hsub [Suraj] Remove src_w check as not required v7: Remove check for NV12. Add check for PTL as well [Matt] v8: Alignment fix Continuing discussions from: https://patchwork.freedesktop.org/series/136416/ Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028044153.1605209-1-nemesa.garg@intel.com
2024-10-25drm/i915/xe3lpd: Load DMCGustavo Sousa
Load the DMC for Xe3LPD. Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241022155115.50989-1-gustavo.sousa@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2024-10-25drm/i915/display: Cover all possible pipes in TP_printk()Gustavo Sousa
Tracepoints that display frame and scanline counters for all pipes were added with commit 1489bba82433 ("drm/i915: Add cxsr toggle tracepoint") and commit 0b2599a43ca9 ("drm/i915: Add pipe enable/disable tracepoints"). At that time, we only had pipes A, B and C. Now that we can also have pipe D, the TP_printk() calls are missing it. As a quick and dirty fix for that, let's define two common macros to be used for the format and values respectively, and also ensure we raise a build bug if more pipes are added to enum pipe. In the future, we should probably have a way of printing information for available pipes only. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-6-gustavo.sousa@intel.com
2024-10-25drm/i915/display: Do not use ids from enum pipe in TP_printk()Gustavo Sousa
Because much of kernel tracepoints is implemented at the C preprocessor level, C identifiers used in TP_printk() are saved verbatim in the event format, even when they represent compile-time constant values. As an example, we can look at the format for the intel_pipe_enable event: # cat /sys/kernel/debug/tracing/events/i915/intel_pipe_enable/format | grep '^print fmt' print fmt: "dev %s, pipe %c enable, pipe A: frame=%u, scanline=%u, pipe B: frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u", __get_str(dev), REC->pipe_name, REC->frame[PIPE_A], REC->scanline[PIPE_A], REC->frame[PIPE_B], REC->scanline[PIPE_B], REC->frame[PIPE_C], REC->scanline[PIPE_C] We see that PIPE_A, PIPE_B and PIPE_C are pasted directly in the format. Because tools that interact with kernel tracepoints don't know about those ids, they'll endup failing to parse the format or produce corrupted output. For example, we can see below that trace-cmd repeats PIPE_A's frame/scanline counts for all pipes (probably because it evaluates unknown ids as zero): $ trace-cmd report -F intel_pipe_enable | tail -n5 testdisplay-8616 [000] 22048.276758: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=861, scanline=480, pipe B: frame=861, scanline=480, pipe C: frame=861, scanline=480 testdisplay-8616 [001] 22048.490287: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=867, scanline=480, pipe B: frame=867, scanline=480, pipe C: frame=867, scanline=480 testdisplay-8616 [003] 22048.700181: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=872, scanline=400, pipe B: frame=872, scanline=400, pipe C: frame=872, scanline=400 testdisplay-8616 [002] 22049.054220: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=881, scanline=2170, pipe B: frame=881, scanline=2170, pipe C: frame=881, scanline=2170 testdisplay-8616 [002] 22049.166851: intel_pipe_enable: dev 0000:00:02.0, pipe B enable, pipe A: frame=887, scanline=1632, pipe B: frame=887, scanline=1632, pipe C: frame=887, scanline=1632 , while in fact we have different values for each pipe, which can be confirmed with the raw view of the events: $ trace-cmd report -R -F intel_pipe_enable | tail -n5 testdisplay-8616 [000] 22048.276758: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[5d, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A testdisplay-8616 [001] 22048.490287: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[63, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A testdisplay-8616 [003] 22048.700181: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[68, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[90, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A testdisplay-8616 [002] 22049.054220: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[71, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[7a, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A testdisplay-8616 [002] 22049.166851: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[77, 03, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[60, 06, 00, 00, 39, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=B To fix that, we need a fix that looks more like a hack: use macros that result to integer constants instead of enum pipe values. This fixes the issue, but could break if, for whatever unlikely reason, the underlying values in the enum are changed. In the future, we should find a better way to handle this, but for now, the hack took care of the job: $ trace-cmd report -F intel_pipe_enable | tail -n5 testdisplay-9224 [003] 24324.455375: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1103, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0 testdisplay-9224 [002] 24324.669845: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1109, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0 testdisplay-9224 [003] 24324.900105: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1115, scanline=31, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0 testdisplay-9224 [002] 24325.256408: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1124, scanline=2171, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0 testdisplay-9224 [003] 24325.380789: intel_pipe_enable: dev 0000:00:02.0, pipe B enable, pipe A: frame=1131, scanline=979, pipe B: frame=1, scanline=1082, pipe C: frame=0, scanline=0 v2: - Statically assert that PIPE_A == _TRACE_PIPE_A. (MattR) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-5-gustavo.sousa@intel.com
2024-10-25drm/i915/display: Store pipe name in trace eventsGustavo Sousa
The first part[1] of the LWN series on using TRACE_EVENT() mentions about TP_printk(): "Do not create new tracepoint-specific helpers, because that will confuse user-space tools that know about the TRACE_EVENT() helper macros but will not know how to handle ones created for individual tracepoints." It seems this is what we ended up doing when using pipe_name() in TP_printk(). For example, the format for the intel_pipe_update_start event is as follows: # cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format name: intel_pipe_update_start ID: 1136 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:__data_loc char[] dev; offset:8; size:4; signed:0; field:enum pipe pipe; offset:12; size:4; signed:1; field:u32 frame; offset:16; size:4; signed:0; field:u32 scanline; offset:20; size:4; signed:0; field:u32 min; offset:24; size:4; signed:0; field:u32 max; offset:28; size:4; signed:0; print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A') and that's how the format is saved. Even though the output from /sys/kernel/debug/tracing/trace will look correct (because it is generated in the kernel), we will see corrupted lines when using a tool like trace-cmd to view the data. While the output looks correct when looking at /sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the trace data with "trace-cmd report": $ trace-cmd report \ > | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \ > | cat -v | uniq -c 34 pipe ^A , where ^A is a non-printable character. As a fix, let's store the pipe name directly in the event. The fix was done by applying the following sed script: s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/ s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/ s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/ After these changes, using the same example, we have the following: $ trace-cmd report \ > | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \ > | cat -v | sort | uniq -c 396 pipe A 34 pipe B [1] https://lwn.net/Articles/379903/ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-25drm/i915/display: Zero-initialize frame/scanline counts in tracepointsGustavo Sousa
In an upcoming change, we will also add support for logging frame/scanline counts for pipe D in relevant tracepoints. In [1], Matt mentioned the possibility of having garbage in those counts for pipe D on a platform containing only 3 pipes. Indeed, it has been verified that the counts for the extra pipe would not be zero-initialized by the tracing system. Since it is also possible that the same would happen for a fused-off pipe, let's go ahead and add the logic to zero-initialize the arrays now. [1] https://lore.kernel.org/all/20240918224927.GU5091@mdroper-desk1.amr.corp.intel.com/ Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-3-gustavo.sousa@intel.com
2024-10-25drm/i915/display: Fix out-of-bounds access in pipe-related tracepointsGustavo Sousa
Some display trace events use array members to store frame and scanline counts for each pipe. However, those arrays are declared with 3 as the hardcoded size, which cause out-of-bounds access when the trace event is enabled on a platform that contains pipe D. For example, when looking at the last 10 intel_pipe_enable events after running IGT's testdisplay, we see the following on a MTL machine that has pipe D available: $ trace-cmd report -R -F intel_pipe_enable \ > | tail \ > | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,' testdisplay-6715 [002] 17591.063491: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[83, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [003] 17591.264742: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[89, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [003] 17591.464541: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[8f, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [001] 17591.695827: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[95, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [000] 17591.915841: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[9a, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [000] 17592.127114: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[a0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [002] 17592.358351: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [002] 17592.580467: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [000] 17592.950946: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[b8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [004] 17593.079597: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[bf, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00] pipe=1 Which shows zeros for pipe A's scanline counts. That happens because pipe D's frame counts are overwriting them. Let's fix that by making the arrays bring able to store info for all possible pipes. With the fix, we get the following: $ trace-cmd report -R -F intel_pipe_enable \ > | tail \ > | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,' testdisplay-7040 [003] 18067.489565: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[8c, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[8e, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18067.699312: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[92, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18067.908868: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[98, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18068.122802: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[9d, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [003] 18068.331019: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[a2, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18068.529067: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [003] 18068.742033: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18068.956229: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[b3, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[1f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18069.295322: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[bb, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[7b, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [010] 18069.423527: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[c2, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[d0, 05, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=1 Which makes more sense now. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-2-gustavo.sousa@intel.com
2024-10-24drm/i915: remove all IS_<PLATFORM>_GT<N>() macrosJani Nikula
There aren't many users for the IS_<PLATFORM>_GT<N>() macros, and many of them are in fact unused. Even among the users, the platform check is often redundant. Just remove the macros. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930124948.3551980-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/xe3lpd: Add condition for EDP to powerdown P2.PGSuraj Kandpal
Add condition for P2.PG power down value. v2: change subject line to better match patch condition Bspec: 74494 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@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/20241018200311.67324-8-matthew.s.atwood@intel.com
2024-10-23drm/i915/xe3lpd: Add new bit range of MAX swing setupSuraj Kandpal
Add new bit range for Max PHY Swing Setup in PORT_ALPM_CTL register for DISPLAY_VER >= 30. v2: implement as two separate macros instead of a single macro v3: extend previous definition by 2 bits that were previously reserved Bspec: 70277 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@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/20241018200311.67324-6-matthew.s.atwood@intel.com
2024-10-23drm/i915/xe3lpd: Add C20 Phy consolidated programming tableSuraj Kandpal
From DISPLAY_VER() >= 30 C20 PHY consolidated programming table of DP and eDP been merged and now use the same rates and values. eDP over TypeC has also been introduced. Moreover it allows more granular and higher rates. Add new table to represent this change. Bspec: 68961 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241018200311.67324-5-matthew.s.atwood@intel.com
2024-10-23drm/i915/xe3lpd: Add cdclk changesRadhakrishna Sripada
Xe3_LPD has new max cdclk of 691200 which requires reusing the lnl table and modify/add higher frequencies. Updating the max cdclk supported by the platform and voltage_level determination is also updated. There are minor changes in cdclk programming sequence compared to lnl, where programming cd2x divider needs to be skipped. This is already handled by the calculations in existing code. v2: update tables v3: xe3lpd doesn't supply the power control unit the voltage index Bspec: 68861, 68863, 68864 Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241018200311.67324-3-matthew.s.atwood@intel.com
2024-10-23drm/i915: Remove ckey/format checks from skl_update_scaler_plane()Ville Syrjälä
skl_plane_check() already takes care to reject scaling when an unsupported pixel format or color keying is used. No need to replicate that in the scaler code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Extract intel_pfit.cVille Syrjälä
The panel fitter code doesn't really have much to do with the rest of intel_panel.c, so extract it all into its own file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/panel: Convert panel code to intel_displayVille Syrjälä
struct intel_display will replace struct drm_i915_private as the main thing for display code. Convert the panel code to use it (as much as possible at this stage). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Check pfit destination window on ILK-BDWVille Syrjälä
The ILK-BDW panel fitter has several restrictions on the destination window size. Check for those and reject the configuration if things aren't entirely proper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-7-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Reject cloning when using pfit on ILK-BDWVille Syrjälä
The panel fitter lives inside the pipe and so would affect all cloned outputs. However the relevant properties (scaling mode, TV margins) are per-connector so we could end up with a situation where each cloned output wants a different pfit configuration. Let's just reject pfit usage with cloning entirely. Currently not an issue as we don't yet expose the TV margin properties, but if/when we add those to HDMI we could end up in this situation. For eDP/DP we don't support cloning anyyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-6-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Check pfit minimum timings in pre-SKLVille Syrjälä
Transcoder hdisplay/vdisplay have documented minimum limits when using the panel fitter. Enforce those limits for all pre-SKL platforms. SKL+ handles everything in the unified scaler code instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-5-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Reject pfit downscaling for GMCH platformsVille Syrjälä
Gen2/3 pfit doesn't support downscaling at all, so reject it. On i965+ downscaling is supported by the hardware (max scale factor < 2.0), but as downscaling increases the effective pixel rate we can't safely allow it unless intel_crtc_compute_pixel_rate() gets fixed. Probably the best solution would be to calculate (at least an apporiximate) pfit destination window and use ilk_pipe_pixel_rate() for all platforms. For now reject downscaling on all gmch platforms. The intel ddx has a similar check for this in userspace, modesetting ddx does not. And presumably wayland compositors also do not make such assumptions in userspace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-4-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Check pfit scaling factors on ILK-BDWVille Syrjälä
Make sure we're not exceeding the max scaling factors for the panel fitter on ILK-BDW. SKL+ is skipped here since this is all supposed to be handled by the unified scaler code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-3-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/pfit: Check pipe source size against pfit limits on ILK-BDWVille Syrjälä
The ILK-BDW panel fitter imposes extra limits on the maximum pipe source size we can use. Check for that. Only HSW/BDW are really affected by this since on older platforms the max hdisplay/vdisplay matches the max PIPESRC. But we'll put in the limits for all the platforms just to keep things clear. Note that pch_panel_fitting() is also used on SKL+, but we'll skip the checks for those as it's all supposed to be handled in the unified scaler code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016143134.26903-2-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/active: Use try_cmpxchg() in active_fence_cb()Uros Bizjak
Replace this pattern in active_fence_cb(): cmpxchg(*ptr, old, new) == old ... with the simpler and faster: try_cmpxchg(*ptr, &old, new) The x86 CMPXCHG instruction returns success in the ZF flag, so this change saves a compare after the CMPXCHG. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20241003084533.871524-1-ubizjak@gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-23drm/i915/psr: vbt.psr.enable is only for eDP panelsJouni Högander
We don't want to check vbt.psr.enable on DP Panel Replay as it is targeted for eDP panel usage only. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241021073349.1222331-1-jouni.hogander@intel.com
2024-10-22drm/i915/display: Remove kstrdup_const() and kfree_const() usageChristophe JAILLET
kstrdup_const() and kfree_const() can be confusing in code built as a module. In such a case, it does not do what one could expect from the name of the functions. The code is not wrong by itself, but in such a case, it is equivalent to kstrdup() and kfree(). So, keep thinks simple and straightforward. This reverts commit 379b63e7e682 ("drm/i915/display: Save a few bytes of memory in intel_backlight_device_register()") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patchwork.freedesktop.org/patch/msgid/f82be2ee3ac7d18dd9982b5368a88a5bf2aeb777.1727977199.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-22drm/i915/gvt: use macros from drm_dp.h instead of duplicationJani Nikula
Use the existing macros in drm_dp.h for DPCD and DP AUX instead of duplicating. Remove unused macros, as well as the duplicate definition of DPCD_SIZE. AUX_NATIVE_REPLY_NAK is left unchanged, as it does not match DP_AUX_NATIVE_REPLY_NACK, and I'm not sure what the right thing to do is here. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Zhi Wang <zhiwang@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240930135342.3562755-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-22drm/i915/ddi: use string choice helpersR Sundar
Use str_enabled_disabled string helpers for better readability and to fix cocci warning. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202410071601.TFpXoqgW-lkp@intel.com/ Signed-off-by: R Sundar <prosunofficial@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241007173300.83902-1-prosunofficial@gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-22drm/i915/dp: use string choice helpersR Sundar
Use str_on_off string helpers for better readability and to fix cocci warning. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202410071252.cWILJzrH-lkp@intel.com/ Signed-off-by: R Sundar <prosunofficial@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241007174857.85061-1-prosunofficial@gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-22drm/xe: fix build failure originating from backmergeJani Nikula
../drivers/gpu/drm/xe/display/xe_display.c: In function ‘xe_display_pm_shutdown’: ../drivers/gpu/drm/xe/display/xe_display.c:382:27: error: passing argument 1 of ‘intel_dmc_suspend’ from incompatible pointer type [-Werror=incompatible-pointer-types] 382 | intel_dmc_suspend(xe); | ^~ | | | struct xe_device * In file included from ../drivers/gpu/drm/xe/display/xe_display.c:24: ../drivers/gpu/drm/i915/display/intel_dmc.h:22:46: note: expected ‘struct intel_display *’ but argument is of type ‘struct xe_device *’ 22 | void intel_dmc_suspend(struct intel_display *display); | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ Fixes: c141cf76918e ("Merge drm/drm-next into drm-intel-next") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241022080943.763580-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-18drm/i915/pxp: Add missing tag for Wa_14019159160Alan Previn
Add missing tag for "Wa_14019159160 - Case 2" (for existing PXP code that ensures run alone mode bit is set to allow PxP-decryption. v5: - remove the max IP_VER check since new platforms that i915 supports needs this fix and tag the caller too (John Harrison). v4: - Include IP_VER 12.71. (Matt Roper) v3: - Check targeted platforms using IP_VAL. (John Harrison) v2: - Fix WA id number (John Harrison). - Improve comments and code to be specific for the targeted platforms (John Harrison) Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016001658.2671225-1-alan.previn.teres.alexis@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/i915: Fix irq related documentationRodrigo Vivi
Also update the function names in the documentation. Closes: https://lore.kernel.org/intel-gfx/20241001134331.7b4d4ca5@canb.auug.org.au/ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 3de5774cb8c0 ("drm/i915/irq: Rename suspend/resume functions") Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241011214111.98128-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/i915: Remove unused underrun irq/reporting bitsSai Teja Pottumuttu
Underrun recovery was defeatured and was never brought into usage. Thus we can remove the underrun recovery interrupt/reporting register bits and related logic introduced to detect/report soft, hard, port underruns. Essentially this is a revert of the commit 8bcc0840cf7c ("drm/i915/xelpd: Enhanced pipe underrun reporting") which originally added this functionality. Also note that PIPE_STATUS_UNDERRUN bit in PIPESTATUS still stays relevant but we would move back to not clearing this sticky bit as we are not using any information from this register. v2: Extend commit message to add more details (Matt Roper) v3: Fix the old commit mention in commit message Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241015080503.3521063-1-sai.teja.pottumuttu@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17i915: fix DRM_I915_GVT_KVMGT dependenciesArnd Bergmann
Depending on x86 and KVM is not enough, as the kvm helper functions that get called here are controlled by CONFIG_KVM_X86, which is disabled if both KVM_INTEL and KVM_AMD are turned off. ERROR: modpost: "kvm_write_track_remove_gfn" [drivers/gpu/drm/i915/kvmgt.ko] undefined! ERROR: modpost: "kvm_page_track_register_notifier" [drivers/gpu/drm/i915/kvmgt.ko] undefined! ERROR: modpost: "kvm_page_track_unregister_notifier" [drivers/gpu/drm/i915/kvmgt.ko] undefined! ERROR: modpost: "kvm_write_track_add_gfn" [drivers/gpu/drm/i915/kvmgt.ko] undefined! Change the dependency to CONFIG_KVM_X86 instead. Fixes: ea4290d77bda ("KVM: x86: leave kvm.ko out of the build if no vendor module is requested") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241015152157.2955229-1-arnd@kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17Merge drm/drm-next into drm-intel-nextRodrigo Vivi
Needed to bring some KVM changes to be able to include a fix in our Kconfig. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-17drm/i915/dp: Fix memory leak in parse_lfp_panel_dtd()Shuicheng Lin
The function parse_lfp_panel_dtd() is called when the driver attempts to initialize the eDP connector, and it allocates memory, which is recorded in panel->vbt.lfp_vbt_mode. However, since no eDP panel is connected, the driver fails at intel_edp_init_dpcd() and follows the failure path. Unfortunately, the allocated memory is not freed in this case. To fix this issue, free the memory in the failure path. leak info from kmemleak: " unreferenced object 0xffff8881252f8800 (size 128): comm "systemd-udevd", pid 192, jiffies 4294896880 hex dump (first 32 bytes): e8 fd 00 00 00 04 18 04 a0 04 40 05 00 00 00 03 ..........@..... 03 03 09 03 26 03 00 00 0a 00 00 00 00 00 00 00 ....&........... backtrace (crc 7448f6b4): [<ffffffff82475c9b>] kmemleak_alloc+0x4b/0x80 [<ffffffff814bb50e>] __kmalloc_cache_noprof+0x2be/0x390 [<ffffffffa069862c>] intel_bios_init_panel+0x1c4c/0x2720 [xe] [<ffffffffa0699123>] intel_bios_init_panel_early+0x13/0x20 [xe] [<ffffffffa06fceb9>] intel_dp_init_connector+0x2f9/0x1080 [xe] [<ffffffffa06c370a>] intel_ddi_init+0xbba/0xf50 [xe] [<ffffffffa069b906>] intel_bios_for_each_encoder+0x36/0x60 [xe] [<ffffffffa06d7bd6>] intel_setup_outputs+0x206/0x450 [xe] [<ffffffffa06dad33>] intel_display_driver_probe_nogem+0x163/0x1f0 [xe] [<ffffffffa0680fc7>] xe_display_init_noaccel+0x27/0x70 [xe] [<ffffffffa05b30d6>] xe_device_probe+0x806/0x9a0 [xe] [<ffffffffa0612f0f>] xe_pci_probe+0x31f/0x590 [xe] [<ffffffff81b41718>] local_pci_probe+0x48/0xb0 [<ffffffff81b432c8>] pci_device_probe+0xc8/0x280 [<ffffffff81d5dde8>] really_probe+0xf8/0x390 [<ffffffff81d5e11a>] __driver_probe_device+0x8a/0x170 " v2 (Jani): -use intel_bios_fini_panel() to pair with intel_bios_init_panel_early() Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016150154.1466131-1-shuicheng.lin@intel.com
2024-10-16drm/i915/panelreplay: Panel replay workaround with VRRAnimesh Manna
Panel Replay VSC SDP not getting sent when VRR is enabled and W1 and W2 are 0. So Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY register to at least a value of 1. The same is applicable for PSR1/PSR2 as well. HSD: 14015406119 v1: Initial version. v2: Update timings stored in adjusted_mode struct. [Ville] v3: Add WA in compute_config(). [Ville] v4: - Add DISPLAY_VER() check and improve code comment. [Rodrigo] - Introduce centralized intel_crtc_vblank_delay(). [Ville] v5: Move to crtc_compute_config(). [Ville] v6: Restrict DISPLAY_VER till 14. [Mitul] v7: - Corrected code-comment. [Mitul] - dev_priv local variable removed. [Jani] v8: Introduce late_compute_config() which will take care late vblank-delay adjustment. [Ville] v9: Implementation simplified and split into multiple patches. v10: - Split vrr changes and use struct intel_display in DISPLAY_VER(). [Ankit] - Use for_each_new_intel_connector_in_state(). [Jani] v11: Remove loop and use flipline instead of vrr.enable flag. [Ville] v12: - Use intel_Vrr_possible helper. - Correct flag check for flipline. v13: - Refactor workaround [Jonathan] - Drop the comment around woraround number. [Ville] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> [vsyrjala: Make adjusted_modeg const, and drop redundant parens] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010040503.1795399-4-mitulkumar.ajitkumar.golani@intel.com
2024-10-16drm/i915/vrr: Split vrr-compute-config in two phasesAnimesh Manna
As vrr guardband calculation is dependent on modified vblank start so better to compute late after all vblank adjustement. v1: Initial version. v2: Split in a separate patch from panel-replay workaround. [Ankit] v3: Add a function for late vrr related computation. [Ville] v4: Use flipline instead of vrr.enable and some cosmetic changes. [Ville] v5: Use intel_vrr_possible helper. Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> [vsyrjala: Make adjusted_mode const] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010040503.1795399-3-mitulkumar.ajitkumar.golani@intel.com
2024-10-16drm/i915/vrr: Add helper to check if vrr possibleMitul Golani
Add helper to check if vrr is possible based on flipline is computed. --v1: return just flipline instead using ternary operator [Jonathan, Ville]. Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010040503.1795399-2-mitulkumar.ajitkumar.golani@intel.com
2024-10-15drm/i915/irq: s/gen3/gen2/Ville Syrjälä
Now that we use the gen3 codepaths also for gen2 rename everything to gen2_ to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241008214349.23331-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-15drm/i915/display: Fix Panel Replay vblank enable workaroundJouni Högander
Currently workaround is not applied when vblank is enabled on crtc that needs the workaround if vblank is already enabled for another crtc that doesn't need the workaround. Fix this by increasing counter only if crtc needs the workaround. Fixes: aa451abcffb5 ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009134225.1322820-2-jouni.hogander@intel.com
2024-10-15drm/i915/display: Add own counter for Panel Replay vblank workaroundJouni Högander
We are about to change meaning of vblank_enabled to fix Panel Replay vblank workaround. For sake of clarity we need to rename it. Vblank_enabled is used for i915gm/i945gm vblank irq workaround as well -> instead of rename add new counter named as vblank_wa_pipes. v2: - s/vblank_wa_pipes/vblank_wa_num_pipes/ - use int as a type for the counter Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009134225.1322820-1-jouni.hogander@intel.com
2024-10-14drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible modeImre Deak
If an MST branch device doesn't support DSC for a given mode, but the MST link has enough BW for the mode, assume that the branch device does support the mode using an uncompressed stream. Fixes: 55eaef164174 ("drm/i915/dp_mst: Handle the Synaptics HBlank expansion quirk") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009110135.1216498-2-imre.deak@intel.com
2024-10-14drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculationImre Deak
The MST branch device may not support the number of DSC slices a mode requires, handle the error in this case. Fixes: 4e0837a8d00a ("drm/i915/dp_mst: Account for FEC and DSC overhead during BW allocation") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009110135.1216498-1-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 09:02:26 +0000