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>
