There are some minor changes to pmdemand handling on Xe3:
- Active scalers are no longer tracked. We can simply skip the readout
and programming of this field.
- Active dbuf slices are no longer tracked. We should skip the readout
and programming of this field and also make sure that it stays 0 in
our software bookkeeping so that we won't erroneously return true
from intel_pmdemand_needs_update() due to mismatches.
- Even though there aren't enough pipes to utilize them, the size of
the 'active pipes' field has expanded to four bits, taking over the
register bits previously used for dbuf slices. Since the lower bits
of the mask have moved, we need to update our reads/writes to handle
this properly.
v2: active pipes is no longer always max 3, add in the ability to go to
4 for PTL.
v3: use intel_display for display_ver check, use INTEL_NUM_PIPES
v4: add a conditional for number of pipes macro vs using 3.
v5: reverse conditional order of v4.
v6: undo v5 and fix num_pipes assignment
v7: pass display struct instead of i915, checkpatch fix
v8: Alignment issue
Bspec: 68883, 69125
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028193015.3241858-2-clinton.a.taylor@intel.com
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
Tracepoints that display frame and scanline counters for all pipes were
added with commit 1489bba824 ("drm/i915: Add cxsr toggle tracepoint")
and commit 0b2599a43c ("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
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
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>
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>
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>
../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: c141cf7691 ("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>
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>
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 8bcc0840cf
("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>
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: ea4290d77b ("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>
