From: Ville Syrjälä
We don't really want legacy cursor updates to trigger
VRR pushes because these can happen willy nilly and we
generally want more precise control over the pushes.
The fastpath in intel_legacy_cursor_update() doesn't
send pushes, but if we punt to the full commit path
(with the
From: Ville Syrjälä
Currently we trigger the push send first, then follow it with
a "wait for safe window". That approach no longer works on
PTL+ because triggering the push send immediately ends the safe
window. On prior hardware the safe window extended past the
push being sent (presumably all
From: Ville Syrjälä
When we send a push during vblank the TRANS_PUSH write happens
at some point during a scanline, and the hardware picks it up
on the next scanline. Thus there is up to one extra scanline
of delay between the TRANS_PUSH write and the delayed vblank
triggering. Account for that d
From: Ville Syrjälä
Apparently PTL (or I suppose it could have already happened
in either MTL or LNL, didn't have either one to check) changes
the way the VRR hardwre works by ending the safe window as
soon as the push send is triggered. Reorder our DSB programming
sequence to account for that, a
From: Ville Syrjälä
Since we don't do mailbox updates the push send bit
should alwyas clear by the time the delay vblank fires
and the flip completes. Check for that to make sure we
haven't screwed up the sequencing/vblank evasion/etc.
On the DSB path we should be able to guarantee this
since we
From: Ville Syrjälä
The "wait usec" DSB command doesn't quite seem to able to
guarantee that it always waits at least the specified
amount of usecs. Some of that could be just because it
supposedly just does some kind of dumb timestamp comparison
internally. But I also see cases where two hardwar
From: Ville Syrjälä
Decode the DSB error interrupts into human readable
form for easier debugging.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_d
From: Ville Syrjälä
Skip all the commit completion interrupt stuff on the
chained DSB when we don't take the full DSB path (ie. when
the plane/pipe programming is done via MMIO). The commit
completion will be done via the CPU side vblank interrupt.
Currently this is just a redundant interrupt, s
From: Ville Syrjälä
Add a function for emitting a DSB poll instruction. We'll allow
the caller to specify the poll parameters.
v2: s/wait/wait_us/ (Ankit)
Reviewed-by: Ankit Nautiyal
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 19 +++
drivers/g
From: Ville Syrjälä
Make intel_crtc_scanline_offset() a bit less confusing by
fully reordering the if ladder to use the new->old platform
order.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vblank.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Something has changed in the hardware on LNL/BMG because
HDMI outputs no longer have the extra scanline offset.
I confirmed that MTL still has the old behaviour, which
is a bit weird since both MTL and BMG have display ver 14
vs. LNL is version 20. But can't argue with actual
From: Ville Syrjälä
The HDMI vs. not scanline offset stuff no longer applies to the
latest platforms, so using HAS_DDI() is a bit confusing. Replace
with a more specific set of conditions.
Also let's just deal with the platform types in the if ladder
itself, and handle the HDMI vs. not within th
From: Ville Syrjälä
Turns out LNL+ and BMG+ no longer have the weird extra scanline
offset for HDMI outputs. Fix intel_crtc_scanline_offset()
accordingly so that scanline evasion/etc. works correctly on
HDMI outputs on these new platforms.
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Convert a bunch of stuff over to struct intel_display, and
finish off with a few debug print improvements.
v2: One new patch to deal with the VT-d fallout, and the rest
has been rebased/slightly updated due to various othert changes
Ville Syrjälä (12):
drm/i915: Pass i
From: Ville Syrjälä
Now that intel_scanout_needs_vtd_wa() is no longer used from
the gem code we can convert it to take struct intel_display.
which will help with converting the low level plane code over
as well.
Cc: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the skl+ universal plane
code to use it.
Note that we still have two straggles in the form on
HAS_FLAT_CCS() and the pxp stuff.
Reviewed-by: Jani Nikula
Signed-off-by: Vill
From: Ville Syrjälä
intel_sprite.c was partially converted to struct intel_display.
Finish the job now that we can deal with the platform checks
as well.
And while at it we also move the 'display' variable declaration
to be the first thing in most functions, consistency. We can
actually do that
From: Ville Syrjälä
Switch the plane debugs to use DRM_RECT_FMT & co. instead
of drm_rect_debug_print() so that the debugs go on the same line.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 11 +--
1 file changed, 5 inser
From: Ville Syrjälä
Include the standard "[PLANE:%d:s]" stuff in all plane debugs
(or rather all I was able to find), to provide better information
on which plane we're actually talking about.
There are a few spots where we care about the CRTC as well, so
include that where appropriate.
Reviewe
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the fb code to
use it.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 2 +-
drivers/gpu/drm/i915/display/intel
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the pre-skl primary plane
code to use it.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 240 +++---
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the cursor code to
use it.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
drivers/gpu/drm/i915/display/int
From: Ville Syrjälä
Pass intel_display to the display power stuff. These are spread
all over the place so tend to hinder clean conversions of whole
files.
TODO: The gt part/unpark power domain shenanigans need some
kind of more abstract interface...
v2: Deal with cmtg
Reviewed-by: Jani Nikula
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert intel_crtc.c code to
use it.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 4 +-
drivers/gpu/drm/i915/display/
From: Ville Syrjälä
Pass the device argument as drm_device to intel_plane_fb_max_stride()
to decouple i915_gem_dumb_create() vs. the display code a bit.
xe currently doesn't even call this, but it probably should...
v2: s/dev/drm/ (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Make the intel_fb_bo.h interfaces operated purely in base
drm_ types so that each driver (i915 and xe) doesn't have to
know about each other, or the display stuff.
v2: s/dev/drm/ (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display
From: Ville Syrjälä
Currently we trigger the push send first, then follow it with
a "wait for safe window". That approach no longer works on
PTL+ because triggering the push send immediately ends the safe
window. On prior hardware the safe window extended past the
push being sent (presumably all
From: Ville Syrjälä
Since we now do the "wait for safe window" before triggering
the push send, there is a theoretical possibity that we may
have screwed up the vblank evasion and the push has slipped
past the vmax decision boundary. In that case the push would
only happen after the next frame's
From: Ville Syrjälä
Add a functiuon for emitting a DSB poll instruction. We'll allow
the caller to specify the poll parameters.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 19 +++
drivers/gpu/drm/i915/display/intel_dsb.h | 3 +++
2 files changed
From: Ville Syrjälä
Apparently PTL (or I suppose it could have already happened
in either MTL or LNL, didn't have either one to check) changes
the way the VRR hardwre works by ending the safe window as
soon as the push send is triggered. Reorder our DSB programming
sequence to account for that, a
From: Ville Syrjälä
Currently we just define the display tracpoints with
TRACE_SYSTEM i915. However the code gets included separately
in i915 and xe, and now both modules are competing for the
same tracpoints. Apparently whichever module is loaded first
gets the tracepoints and the other guy is l
From: Ville Syrjälä
Move all the intel_atomic_check_planes() machinery into
intel_atomic_plane.c in order to declutter intel_display.c.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 293 ++
.../gpu/drm/i915/display/intel_atomic_plane.h | 3 +
From: Ville Syrjälä
Pull the code linking the UV and Y planes together into a
sensible function instead of having the code plastered inside
the higher level loop.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 83 +++-
1 file changed, 47 inserti
From: Ville Syrjälä
Use the standard [PLANE:%d:%s] stuff for the Y plane debugs,
and more clearly spell out which plane is UV plane and which
is Y plane when linking them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
1 file changed, 5 inserti
From: Ville Syrjälä
Any active plane needs to have its crtc included in the atomic
state. For planes enabled via uapi that is all handler in the core.
But when we use a plane for joiner the uapi code things the plane
is disabled and therefore doesn't have a crtc. So we need to pull
those in by ha
From: Ville Syrjälä
Try to keep all the low level skl+ universal plane register
details inside skl_universal_plane.c instead of having them
sprinkled all over the place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 30 -
.../drm/i915/display/
From: Ville Syrjälä
All the this generic 'plane' vs 'linked' stuff is hard to
follow. Rename the variables to use the y_plane vs. uv_plane
terminology to make it clear which is which.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 107 ++-
1 fil
From: Ville Syrjälä
visible can't be true when is_y_plane is true. Replace the
bogus check with an WARN_ON(). Flatten the function while
at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-
From: Ville Syrjälä
Pull the details of the nv12 plane unlinking to a small
funciton to make the higher level code less messy.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git
From: Ville Syrjälä
Bspec talks about Y planes, not planar slaves. Switch to using the
same erminology to make life a bit less confusing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 4 ++--
drivers/gpu/drm/i915/display/intel_display.c| 8 +++
From: Ville Syrjälä
The current code tries to handle joiner vs. Y planes completely
independently. That does not really work since each pipe selects
its Y planes completely independently, and any plane pulled into
the state by one of the secondary pipes needs to have the plane
on the primary pipe
From: Ville Syrjälä
This reverts commit 1d5b09f8daf859247a1ea65b0d732a24d88980d8.
Now that the root cause the missing crtc state has been fixed
we can get rid of the duct tape.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 2 +-
1 file changed, 1 inserti
From: Ville Syrjälä
I wanted to reorganize the Y plane code, but then I
realized it still has real issued, espectially when it comes
to joiner usage. So fix the bugs first, then do the code
reorganization.
Ville Syrjälä (11):
drm/i915: Make sure all planes in use by the joiner have their crtc
From: Ville Syrjälä
Switch the plane debugs to use DRM_RECT_FMT & co. instead
of drm_rect_debug_print() so that the debugs go on the same line.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
From: Ville Syrjälä
Include the standard "[PLANE:%d:s]" stuff in all plane debugs
(or rather all I was able to find), to provide better information
on which plane we're actually talking about.
There are a few spots where we care about the CRTC as well, so
include that where appropriate.
Signed-
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the pre-skl primary plane
code to use it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 240 +++---
drivers/gpu/drm/i915/disp
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the fb code to
use it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 3 +-
drivers/gpu/drm/i915/display/intel_cursor.c | 3 +-
driv
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the skl+ universal plane
code to use it.
Note that we still have two straggles in the form on
HAS_FLAT_CCS() and the pxp stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the cursor code to
use it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
drivers/gpu/drm/i915/display/intel_cursor.c | 136
From: Ville Syrjälä
intel_sprite.c was partially converted to struct intel_display.
Finish the job now that we can deal with the platform checks
as well.
And while at it we also move the 'display' variable declaration
to be the first thing in most functions, consistency. We can
actually do that
From: Ville Syrjälä
Pass intel_display to the display power stuff. These are spread
all over the place so tend to hinder clean conversions of whole
files.
TODO: The gt part/unpark power domain shenanigans need some
kind of more abstract interface...
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert intel_crtc.c code to
use it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 4 +-
drivers/gpu/drm/i915/display/g4x_hdmi.c | 3 +-
From: Ville Syrjälä
Make the intel_fb_bo.h interfaces operated purely in base
drm_ types so that each driver (i915 and xe) doesn't have to
know about each other, or the display stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c| 5 ++---
drivers/gpu/drm/i915/di
From: Ville Syrjälä
Pass the device argument as drm_device to intel_plane_fb_max_stride()
to decouple i915_gem_dumb_create() vs. the display code a bit.
xe currently doesn't even call this, but it probably should...
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c
From: Ville Syrjälä
Convert a bunch of stuff over to struct intel_display, and
finish off with a few debug print improvements.
Ville Syrjälä (11):
drm/i915: Decouple i915_gem_dumb_create() from the display a bit
drm/i915: Decouple intel_fb_bo.h interfaces from driver specific types
drm/i91
From: Ville Syrjälä
Grab the GTT view for the fbdev fb pinning from
fb->normal_view.gtt instead of having and extra one on
the stack. Seems safer in case we ever put any new
information into normal GTT views.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 5 +
From: Ville Syrjälä
Depending on the platform and/or plane type we can get away
with a bit less alignment in the VT-d w/a. Reduce the numbers
accordingly.
Note that it's not actually clear in VLV/CHV need this w/a,
and if they do we don't actually know what kind of alignment
is sufficient. Leave
From: Ville Syrjälä
Bspec lists different VT-d guard numbers (the number of dummy
padding PTEs) for different platforms and plane types. Use those
instead of just assuming the max glk+ number for everything.
This could avoid a bit of overhead on older platforms due to
reduced padding, and it make
From: Ville Syrjälä
Currently i915_gem_object_pin_to_display_plane() uses
i915_gem_object_get_tile_row_size() to calculate the tile row
size for the VT-d guard w/a. That's not really proper since
i915_gem_object_get_tile_row_size() only works for fenced BOs,
nor does it take rotation into account
From: Ville Syrjälä
Currently we don't account for the VT-d alignment w/a in
plane->min_alignment() which means that panning inside a larger
framebuffer can still cause the plane SURF to be misaligned.
Fix the issue by moving the VT-d alignment w/a into
plane->min_alignment() itself (for the affe
From: Ville Syrjälä
Try to make the display VT-d workarounds more robust.
Ville Syrjälä (5):
drm/i915: Move VT-d alignment into plane->min_alignment()
drm/i915: Use more optimal VTd alignment for planes
drm/i915: Calculate the VT-d guard size in the display code
drm/i915: Use per-plane V
From: Ville Syrjälä
Pull the "do we actually need a LRR update?" checks into a small
helper for clarity.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/dr
From: Ville Syrjälä
We have at least two options for how to do the
TRANS_PUSH_SEND + commit completion signalling
with the DSB:
Option A)
1. trigger TRANS_PUSH_SEND
2. wait for "safe window"
3. signal the interrupt
In this cases step 2 should not do anything if we were already
between vmin a
From: Ville Syrjälä
Now that we know how to issue the push with the DSB we can
allow the DSB to drive the commits even when VRR is active.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 1 -
1 file changed, 1 deleti
From: Ville Syrjälä
GOP might not agree with our idea of what the vblank delay should be.
Reuse the LRR codepaths to fix that up via a fastset.
The relevant registers aren't actually double buffered so this is a
little bit dodgy. While I've not seen any real issues from frobbing
these live, let'
From: Ville Syrjälä
Update TRANS_SET_CONTEXT_LATENCY in intel_set_transcoder_timings_lrr()
as well. While for actual LRR updates this should not change, I want
to reuse this code to also sanitize the vblank delay during boot,
and in that case we do need to update this.
Cc: Paz Zcharya
Signed-of
From: Ville Syrjälä
Try to deal with the fact that the GOP may configure the vblank delay
differently than what we do, without resorting to a full modeset
to fix it up. It's a bit questinable as the relevant register are
single buffered, but so far I've not seen any real issue from frobbing
them
From: Ville Syrjälä
intel_set_transcoder_timings*() aren't currently suitable for DSI.
Warn if someone accidentally calls them in such cases.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/d
From: Ville Syrjälä
intel_set_transcoder_timings() will set TRANS_VBLANK.vblank_start to 0
for clarity on ADL+ (non-DSI) because the hardware no longer uses that
value. So the same in intel_set_transcoder_timings_lrr() to make sure
the registers stay constitent even when doing LRR timing updates.
From: Ville Syrjälä
I want to start using intel_set_transcoder_timings_lrr() also for
fixing up the vblank delay during boot. To that end make sure it
can cope with interlaced modes as well.
Note that we have soft-defeatured interlaced modes on tgl+ so
technically this is dead code, but if we ev
From: Ville Syrjälä
Hook up the display fault irq handlers for VLV/CHV.
Unfortunately the actual hardware doesn't agree with the
spec on how DPINVGTT should behave. The docs claim that
the status bits can be cleared by writing '1' to them,
but in reality there doesn't seem to be any way to clear
From: Ville Syrjälä
I want to capture a little bit more information about the state
of the plane upon faults. To that end introduce a small plane error
state struct and provide per-plane vfuncs to read it out.
For now we just stick the CTL, SURF, and SURFLIVE (if available)
registers contents in
From: Ville Syrjälä
Dump out the display fault information from the IVB/HSW
error interrupt handler.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_display_irq.c | 47 +++
drivers/gpu/drm/i915/i915_reg.h | 11 +
2 files changed, 58 insertions
From: Ville Syrjälä
Make life a bit more straightforward by removing the bitwise
not from {i9xx,i965}_error_mask() and instead do it when feeding
the value to gen2_error_init(). Make life a bit easier I think.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 22 +++---
From: Ville Syrjälä
Decode the display faults a bit more extensively so that one
doesn't have translate the bitmask to planes/etc. manually.
Also for plane faults we can read out a bit of state from the
relevant plane(s) and dump that out.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/disp
From: Ville Syrjälä
Introduce i915_error_regs as the EIR/EMR counterpart
to the IIR/IMR/IER i915_irq_regs, and update the irq
reset/postingstall to utilize them accordingly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 29 ++--
drivers/gpu/drm
From: Ville Syrjälä
Hook up display GTT fault interrupts for ILK/SNB.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_display_irq.c | 56 ++-
drivers/gpu/drm/i915/i915_reg.h | 10
2 files changed, 65 insertions(+), 1 deletion(-)
diff --git a
From: Ville Syrjälä
The if ladder in gen8_de_pipe_fault_mask() was missing one
else, add it. Doesn't actually matter since each if branch
just returns directly. But the code is less confusing when
you always do things the same way.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/
From: Ville Syrjälä
Currently we just print a hardware specific bitmask when
encountering any kind of display fault error. To make these
errors a bit easier to decode (and perhps even analyze)
I now decode the actual bits, and for plane faults provide
a dump of a few (hopefully) relevant plane re
From: Ville Syrjälä
Add some tracpoints around skl+ scaler programming to help with
debugging.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_trace.h| 99 +++
drivers/gpu/drm/i915/display/skl_scaler.c | 8 ++
2 files changed, 107 insertions(+)
dif
From: Ville Syrjälä
Fix typo s/excdeed/exceed/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index f6d76ef1a85
From: Ville Syrjälä
Include the standard "[CRTC:...]" information in the scaler debugs
to make life easier.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 25 +++
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i9
From: Ville Syrjälä
The tgl+ and mtl+ numbers in skl_scaler_max_dst_size() are
identical. Combine them to a single piece of code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i
From: Ville Syrjälä
The SKL_MAX_DST_* defines just make things hard to read.
Get rid of them and introduce an easy to read function
in their place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 44 +++
1 file changed, 21 insertions(+), 23 dele
From: Ville Syrjälä
The SKL_MAX_SRC_* defines just make things hard to read.
Get rid of them and introduce an easy to read function
in their place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 37 +--
1 file changed, 21 insertions(+), 16 dele
From: Ville Syrjälä
The SKL_MIN_DST_* defines just make things hard to read.
Get rid of them and introduce an easy to read function
in their place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff
From: Ville Syrjälä
The SKL_MIN_*SRC_* defines just make things hard to read.
Get rid of them and introduce an easy to read function
in their place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 25 ---
1 file changed, 13 insertions(+), 12 del
From: Ville Syrjälä
Do a bunch of cleanup in the scaler code, and add rudimentary
scaler tracpoints to aid debugging.
Ville Syrjälä (8):
drm/i915/scaler: Extract skl_scaler_min_src_size()
drm/i915/scaler: Extract skl_scaler_max_src_size()
drm/i915/scaler: Extract skl_scaler_min_dst_size()
From: Ville Syrjälä
Make debugging a bit easier by including the pixel format in
the plane tracpoints.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_trace.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/displ
From: Ville Syrjälä
Using the plane->state pointer in the tracepoints is incorrect
as technically a different state could already have been swapped
in (though in reality that is currently prevented by the stall
hacks in the commit machinery). But let's not leave such footguns
lying around when we
From: Ville Syrjälä
Get rid of the 64bpp YUV formats on ICL+ SDR planes due to
some weird underruns they're causing on TGL, and also bspec
seems to be telling us to not use them either.
Also included some improvements to the tracepoints
that I used to hunt this down.
Ville Syrjälä (4):
drm/i9
From: Ville Syrjälä
I'm seeing underruns with these 64bpp YUV formats on TGL.
The weird details:
- only happens on pipe B/C/D SDR planes, pipe A SDR planes
seem fine, as do all HDR planes
- somehow CDCLK related, higher CDCLK allows for bigger plane
with these formats without underruns. With
From: Ville Syrjälä
Out plane names already include the "plane" part (or
"primary","sprite","cursor" in some cases). Don't duplicate
that in the tracpoints as that leadst to weird stuff like
"plane plane 1A".
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_trace.h |
From: Ville Syrjälä
Turns out that TGL needs its vmin/vmax/flipling adjusted based
on the vblank delay, otherwise the hardware pushes the vtotals
fiurther out. Make it so.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vrr.c | 32 +++-
1 file changed, 2
From: Ville Syrjälä
When looking at raw hardware scanline numbers it's helpful to
remember what the offset between the hardware values and our
more human readable numbers should be. Include that in the state dump.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc_state_d
From: Ville Syrjälä
On ICL/TGL the VRR hardware injects an extra scanline just after
vactive. This essentically behaves the same as an extra line of
vblank delay, except it only appears in this one specific spot.
Considee our DSB interrupt signalling scheme:
1. arm the update
2. wait for undelay
From: Ville Syrjälä
Plumb the DSB down into intel_vrr_send_push() so that we can
perform the opration on the DSB.
TRANS_PUSH, being a transcoder register, needs non-posted writes
to make it through.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
drivers/gp
From: Ville Syrjälä
Apparently on ICL/TGL need the annoying vmin adjustemnt. On
ADL+ we can program flipling==vmin and the hardware actually
respects that properly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vrr.c | 39
1 file changed, 27 inser
From: Ville Syrjälä
We have at least two options for how to do the
TRANS_PUSH_SEND + commit completion signalling
with the DSB:
Option A)
1. trigger TRANS_PUSH_SEND
2. wait for "safe window"
3. signal the interrupt
In this cases step 2 should not do anything if we were already
between vmin a
From: Ville Syrjälä
Introduce a VRR specific function for determining the current
vblank delay. Currently thus will give the same answer as
intel_mode_vblank_delay() but that will change later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c| 18 ++
1 - 100 of 2548 matches
Mail list logo
