summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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
2024-10-11drm/i915/xe3lpd: Add new display power wellsMatt Roper
Xe3's power well handling is similar to previous platforms, but there are a few changes that need to be handled to ensure optimal power management: - PGB now only depends on PG1, not PG2 - Transcoder B is now in PG1 (was previously in PGB) - Transcoders C & D are now in PG2 (were previously in PGC/PGD) - DC states now require PG2 to be off (whereas on Xe2 it could remain on as a dependency of PGB, although the features inside of it could not be used). Bspec: 72519, 68851 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010224311.50133-4-matthew.s.atwood@intel.com
2024-10-11drm/i915/xe3lpd: Adjust watermark calculationsMatt Roper
Xe3 makes a couple minor tweaks to the watermark algorithm's block count calculations. Bspec: 68985 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010224311.50133-3-matthew.s.atwood@intel.com
2024-10-11drm/i915/xe3lpd: reuse xe2lpd definitionClint Taylor
xe3_lpd display is functionally identical to xe2_lpd for now so reuse the device description. A separate xe3 definition will be added in the future if/when new feature flags are required. Signed-off-by: Clint Taylor <clinton.a.taylor@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/20241010224311.50133-2-matthew.s.atwood@intel.com
2024-10-11drm/i915/dp: Disable unnecessary HPD polling for eDPImre Deak
A registered eDP connector is considered to be always connected, so it's unnecessary to poll it for a connect/disconnect event. Polling it involves AUX accesses toggling the panel power, which in turn can generate a spurious short HPD pulse and possibly a new poll cycle via the short HPD handler runtime resuming the device. Avoid this by disabling the polling for eDP connectors. This avoids IGT tests timing out while waiting for the device to runtime suspend, the timeout caused by the above runtime resume->poll->suspend-> resume cycle keeping the device in the resumed state. Testcase: igt/kms_pm_rpm/unverisal-planes Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009194358.1321200-3-imre.deak@intel.com
2024-10-11drm/i915/dp: Assume panel power is off if runtime suspendedImre Deak
If the device is runtime suspended the eDP panel power is also off. Ignore a short HPD on eDP if the device is suspended accordingly, instead of checking the panel power state via the PPS registers for the same purpose. The latter involves runtime resuming the device unnecessarily, in a frequent scenario where the panel generates a spurious short HPD after disabling the panel power and the device is runtime suspended. Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009194358.1321200-2-imre.deak@intel.com
2024-10-11Merge tag 'drm-xe-next-2024-10-10' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Cross-subsystem Changes: - Add drm_line_printer (Michal) Driver Changes: - Fix an UAF (Matt Auld) - Sanity check compression and coherency mode (Matt Auld) - Some PIC-ID work (Jani) - Use IS_ENABLED() instead of defined() on config options. - gt powergating work (Riana) - Suppress missing out ter rpm protection warning (Rodrigo) - Fix a vm leak (Dafna) - Clean up and update 'has_flat_ccs' handling (Lucas) - Fix arg to pci_iomap (Lucas) - Mark reserved engines in shapshot (Lucas) - Don't keep stale pointer (Michal) - Fix build warning with CONFIG_PM=n (Arnd) - Add a xe_bo subtest for shrinking / swapping (Thomas) - Add a warkaround (Tejas) - Some display PM work (Maarten) - Enable Xe2 + PES disaggregation (Ashutosh) - Large xe_mmio rework / cleanup (Matt Roper) - A couple of fixes / cleanups in the xe client code (Matt Auld) - Fix page-fault handling on closed VMs (Matt Brost) - Fix overflow in OA batch buffer (José) - Style fixes (Lucas, Jiapeng, Nitin) - Fixes and new development around SRIOV (Michal) - Use devm_add_action_or_reset() in gt code (He) - Fix CCS offset calculation (Matt Auld) - Remove i915_drv.h include (Rodrigo) - Restore PCI state on resume (Rodrigo) - Fix DSB buffer coherency / Revert DSB disabling (Maarten / Animesh) - Convert USM lock to rwsem (Matt Brost) - Defer gt-mmio intialization (Matt Roper) - meemirq changes (Ilia) - Move some PVC related code out of xe-for-CI and to the driver (Rodrigo / Jani) - Use a helper for ASID->VM lookup (Matt Brost) - Add new PCI id for ARL (Dnyaneshwar) - Use Xe2_LPM steering tables for Xe2_HPM (Gustavo) - Performance tuning work for media GT and L3 cache flushing (Gustavo) - Clean up VM- and exec queue file lock usage (Matt Brost) - GuC locking fix (Matt Auld) - Fix UAF around queue destruction (Matt Auld) - Move IRQ-related registers to dedicated header (Matt Roper) - Resume TDR after GT reset (Matt Brost) - Move xa_alloc to prevent UAF (Matt Auld) - Fix OA stream close (José) - Remove unused i915_gpu_error.h (Jani) - Prevent null pointer access in xe_migrate_copy (Zhanjun) - Fix memory leak when aborting binds (Matt Brost) - Prevent UAF in send_recv() (Matt Auld) - Fix xa_store() error checking (Matt Auld) - drop irq disabling around xa_erase in guc code (Matt Auld) - Use fault injection infrastructure to find issues as probe time (Francois) - Fix a workaround implementation. (Vinay) - Mark wedged_mode debugfs writable (Matt Roper) - Fix for prviewous memirq work (Michal) - More SRIOV work (Michal) - Devcoredump work (John) - GuC logging + devcoredump support (John) - Don't report L3 bank availability on PTL (Shekhar) - Replicate Xe2 PAT settings on Xe2 (Matt Roper) - Define Xe3 feature flags (Haridhar) - Reuse Xe2 MOCS table on on PTL (Haridhar) - Add PTL platform definition (Haridhar) - Add MCR steering for Xe3 (Matt) - More work around GuC capture for devcoredump (Zhanjun) - Improve cache flushing behaviour on bmg (Matt Auld) - Fix shrinker test compiler warnings on 32-bit (Thomas) - Initial set of workarounds for Xe3 (Gustavo) - Extend workaround for xe2lpg (Aradhya) - Fix unbalanced rpm put x 2 (Matt Auld) Signed-off-by: Dave Airlie <airlied@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iHUEABYKAB0WIQRskUM7w1oG5rx2IZO4FpNVCsYGvwUCZwekBwAKCRC4FpNVCsYG # v32oAQDnIKVwjZecI1V3oUsy2ZE3TKWx8HH4FweT6S5L6tqZwQD/b0vkeA3UaojO # 5FIkPEqyHFbrj+Sw7bLonLb3LHv4WAE= # =FtY6 # -----END PGP SIGNATURE----- # gpg: Signature made Thu 10 Oct 2024 19:53:11 AEST # gpg: using EDDSA key 6C91433BC35A06E6BC762193B81693550AC606BF # gpg: Can't check signature: No public key # Conflicts: # drivers/gpu/drm/xe/xe_gt_mcr.c # drivers/gpu/drm/xe/xe_tuning.c From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Zwekwrak12c5SSgo@fedora
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 02:10:05 +0000