From: Ville Syrjälä
The address we read from the PTE is a dma address, not a physical
address. Rename the variable to say so.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_plane_initial.c| 15 ---
1 file changed, 8 insertions(+), 7
From: Ville Syrjälä
MTL stolen memory looks more like local memory, so use the
(now fixed) lmem path when doing the initial plane readout.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_plane_initial.c| 25 +--
1 file changed, 18
From: Ville Syrjälä
On MTL the stolen region starts at offset 8MiB from the start of
LMEMBAR. The dma addresses are thus also offset by 8MiB. However the
mm_node/etc. is zero based, and i915_pages_create_for_stolen() will
add the appropriate region.start into the sg dma address. So when
we do
From: Ville Syrjälä
When multiple pipes are enabled by the BIOS we try to read out each
in turn. But we do the readout for the second only after the inherited
vma for the first has been rebound into its original place (and thus
the PTEs have been rewritten). Unlike the BIOS we set some high
From: Ville Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
From: Ville Syrjälä
Now that the GGTT PTE updates go straight to GSMBASE (bypassing
GTTMMADR) there should be no more risk of system hangs? So the
"binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer
necessary, disable it.
TODO: MI_UPDATE_GTT might be interesting as an optimization
From: Ville Syrjälä
On MTL accessing stolen memory via the BARs is somehow borked,
and it can hang the machine. As a workaround let's bypass the
BARs and just go straight to DSMBASE/GSMBASE instead.
Note that on every other platform this itself would hang the
machine, but on MTL the system
From: Ville Syrjälä
Now that intel_memory_regions_hw_probe() prints out each and every
memory region there's no reason to have ad-hoc debugs to do similar
things elsewhere.
Cc: Paz Zcharya
Reviewed-by: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c
From: Ville Syrjälä
Dump the details about every memory region into dmesg at probe time.
Avoids having to dig those out from random places when debugging stuff.
Cc: Paz Zcharya
Reviewed-by: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_memory_region.c | 18
From: Ville Syrjälä
mem->region is a struct resource, but mem->io_start and
mem->io_size are not for whatever reason. Let's unify this
and convert the io stuff into a struct resource as well.
Should make life a little less annoying when you don't have
juggle between two different approaches all
From: Ville Syrjälä
Attempt to fix the mess around stolen memory, especially on MTL
with it's special (and apparenly broken) not-actually-lmem stolen.
The series is made up of roughtly three parts:
1. General refactoring/debug improvement for mem regions
2. Deal with the broken BAR stuff on MTL
From: Ville Syrjälä
Replace pointless memcpy()s of structures. A normal assignment
will do just fine, thank you.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 3 +--
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
2 files changed, 3
From: Ville Syrjälä
intel_crtc_check_fastset() is done per-pipe, so it would be nice
to know which pipe it was that failed its checkup.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Ville Syrjälä
With Xorg+modesetting on skl+ we see the following behaviour:
1. root pixmap is X-tiled
2. client submitted buffers can be Y-tiled (w/ 'Option "dmabuf_capable"')
3. we try to switch from the X-tiled buffer to the Y-tiled buffer
using an async flip (when vsync is disabled).
From: Ville Syrjälä
Unlike later platforms TGL/ADLS has the half refresh rate (HRR) event
on the main DMC (as opposed to the pipe DMC). Since we're disabling
that event on all later platforms already let's do the same on
TGL/ADLS as well.
There is supposedly a bit somewhere (DMC_CHICKEN on TGL)
From: Ville Syrjälä
This reverts commit cfeff354f70bb1d0deb0279506e3f7989bc16e28.
A core design consideration with legacy cursor updates is that the
cursor must not touch any other plane, even if we were to force it
to take the slow path. That is the real reason why the cursor uses
a fixed ddb
From: Ville Syrjälä
Our legacy cursor updates are actually mailbox updates.
Ie. the hardware latches things once per frame on start of
vblank, but we issue an number of updates per frame,
withough any attempt to synchronize against the vblank
in software. So in theory only the last update issued
From: Ville Syrjälä
intel_vblank.c seems like the appropriate place for the core
vblank evasion code. Move it there.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 135
drivers/gpu/drm/i915/display/intel_vblank.c | 130 +++
From: Ville Syrjälä
There isn't really any reason to make the caller suffer through
checking the vblank evasion min/max scanlines. If we somehow
ended up with bogus values (which really shouldn't happen)
then just skip the actual vblank evasion loop but otherwise
plow ahead as normal.
The only
From: Ville Syrjälä
Pull the core vblank evasion loop into its own function,
so that we can reuse it elsewhere later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 135 --
1 file changed, 75 insertions(+), 60 deletions(-)
diff --git
From: Ville Syrjälä
Pull the need_vlv_dsi_wa details into intel_vblank_evade_init()
so that caller doesn't have to care about it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Collect the information needed for vblank evasions into
a structure that we can pass around more easily.
And let's rename intel_crtc_vblank_evade_scanlines() to just
intel_vblank_evade_init() so that better describes the intended
usage of initializing the context.
From: Ville Syrjälä
Drop the vblank reference only after we've done the hideous
need_vlv_dsi_wa stuff. This will make it easier to reuse the
the vblank evasion machinery elsewhere.
Keeping the vblank reference for a bit longer is not a
problem. In fact we might want to not drop it at all until
From: Ville Syrjälä
We'll be needing to do vblank evasion around legacy cursor updates,
which don't have the intel_atomic_state around. So let's remove
this dependency on a full commit and pass the crtc state in by hand.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
MTL seems very good at racing the cursor mailbox updates against
the vblank, causing things to not latch for long enough to cause
GTT faults. Attempt to hook up vblank evasions into the legacy
cursor path to avoid this.
Also revert a dangerous wm/ddb change related to
From: Ville Syrjälä
There's no reason the caller of intel_initial_plane_config() should
have to loop over the CRTCs. Pull the loop into the function to
make life simpler for the caller.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_driver.c | 7 +---
From: Ville Syrjälä
Declutter initial_plane_vma() a bit by pulling the lmem and smem
readout paths into their own functions.
TODO: the smem path should still be fixed to get and validate
the dma address from the pte as well
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The address we read from the PTE is a dma address, not a physical
address. Rename the variable to say so.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_plane_initial.c| 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git
From: Ville Syrjälä
MTL stolen memory looks more like local memory, so use the
(now fixed) lmem path when doing the initial plane readout.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_plane_initial.c| 25 +--
1 file changed, 18 insertions(+), 7 deletions(-)
From: Ville Syrjälä
On MTL the stolen region starts at offset 8MiB from the start of
LMEMBAR. The dma addresses are thus also offset by 8MiB. However the
mm_node/etc. is zero based, and i915_pages_create_for_stolen() will
add the appropriate region.start into the sg dma address. So when
we do
From: Ville Syrjälä
When multiple pipes are enabled by the BIOS we try to read out each
in turn. But we do the readout for the second only after the inherited
vma for the first has been rebound into its original place (and thus
the PTEs have been rewritten). Unlike the BIOS we set some high
From: Ville Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
From: Ville Syrjälä
Now that the GGTT PTE updates go straight to GSMBASE (bypassing
GTTMMADR) there should be no more risk of system hangs? So the
"binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer
necessary, disable it.
TODO: MI_UPDATE_GTT might be interesting as an optimization
From: Ville Syrjälä
On MTL accessing stolen memory via the BARs is somehow borked,
and it can hang the machine. As a workaround let's bypass the
BARs and just go straight to DSMBASE/GSMBASE instead.
Note that on every other platform this itself would hang the
machine, but on MTL the system
From: Ville Syrjälä
Now that intel_memory_regions_hw_probe() prints out each and every
memory region there's no reason to have ad-hoc debugs to do similar
things elsewhere.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4
From: Ville Syrjälä
Dump the details about every memory region into dmesg at probe time.
Avoids having to dig those out from random places when debugging stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_memory_region.c | 18 ++
1 file changed, 18
From: Ville Syrjälä
mem->region is a struct resource, but mem->io_start and
mem->io_size are not for whatever reason. Let's unify this
and convert the io stuff into a struct resource as well.
Should make life a little less annoying when you don't have
juggle between two different approaches all
From: Ville Syrjälä
Attempt to fix the mess around stolen memory, especially on MTL
with it's special (and apparenly broken) not-actually-lmem stolen.
The series is made up of roughtly three parts:
1. General refactoring/debug improvement for mem regions
2. Deal with the broken BAR stuff on MTL
From: Ville Syrjälä
The cdclk->voltage_level if ladders are hard to read, especially as
they're written the other way around compared to how bspec lists
the limits. Let's rewrite them to use simple arrays that gives us
the max cdclk for each voltage level.
v2: Bump the jsl/ehl max cdclk in the
From: Ville Syrjälä
Currently we have a hardcoded assumption that the cdclk divider
(2*cd2x divider) is always 2 when squashing is used. While that
is true for all current platforms it might not hold in the future.
So eliminate the assumption and calculate the correct divider
from the other
From: Ville Syrjälä
To help with debugging print out the mmio list contained in the DMC
firmware. Also highlight the event registers, and whether we're going
to disable them or not.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dmc.c | 18 ++
1 file
From: Ville Syrjälä
Unlike later platforms TGL has the half refresh rate (HRR) event
on the main DMC (as opposed to the pipe DMC). Since we're disabling
that event on all later platforms already let's do the same on
TGL as well.
There is supposedly a bit somewhere (DMC_CHICKEN on TGL) to make
From: Ville Syrjälä
Unlike later platforms TGL has its flip queue event (CLK_MSEC) on
the main DMC (as opposed to the pipe DMC). Currently we're doing
a second pass to disable that, but let's just follow the same
approach as the later platforms and never even enable the event
in the first place.
From: Ville Syrjälä
The pipe DMC seems to be making a mess of things in ADL. Various weird
symptoms have been observed such as missing vblank irqs, typicalle
happening when using multiple displays.
Keep all pipe DMC event handlers disabled until needed (which is never
atm). This is also what
From: Ville Syrjälä
Fix the weird flip_done/etc. issues plaguing ADL+ by disabling all dodgy
DMC events that we definitely don't need. Also improve the debugs to
make it easier to see what we're doing.
Ville Syrjälä (4):
drm/i915/dmc: Don't enable any pipe DMC events
drm/i915/dmc: Also
From: Ville Syrjälä
Sprinkle some extra WARNs around so that we might catch
premature framebuffer destruction more readily.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_framebuffer.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we
From: Ville Syrjälä
Currently async flips are busted when bigjoiner is in use.
As a short term fix simply reject async flips in that case.
Cc: sta...@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9769
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Neither 'tv_mode' or 'color_conversion' can be NULL,
so drop the pointless checks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_tv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
From: Ville Syrjälä
Use standard variable name 'crtc_state' instead of 'cstate'.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_psr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
From: Ville Syrjälä
intel_get_frame_time_us() is never called with a NULL crtc_state so
drop the redundant check.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
intel_bios_get_dsc_params() is only called from
gen11_dsi_dsc_compute_config() and it always passes a non-NULL
crtc_state in. Drop the redundant check.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 3 +--
1 file changed, 1 insertion(+), 2
From: Ville Syrjälä
intel_fb_uses_dpt() should not be called with a NULL fb, so
drop the check.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
From: Ville Syrjälä
intel_crtc_active() is never called with a NULL crtc. Drop
the redundant NULL check.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_wm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
From: Ville Syrjälä
intel_dsc_pps_read() is rather convoluted. Make it legible.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
From: Ville Syrjälä
Since the plane_state variable is declared outside the scaler_users
loop in intel_atomic_setup_scalers(), and it's never reset back to
NULL inside the loop we may end up calling intel_atomic_setup_scaler()
with a non-NULL plane state for the pipe scaling case. That is bad
From: Ville Syrjälä
Mostly just dropping a bunch of redundant null checks that I ran
into while playing around with __attribute__((nonnull)).
And I also ended up discovering an actual bug in the scaler code.
Ville Syrjälä (8):
drm/i915: Fix intel_atomic_setup_scalers() plane_state handling
From: Ville Syrjälä
On ADL+ the hardware automagically calculates the CCS AUX surface
stride from the main surface stride, so when remapping we can't
really play a lot of tricks with the main surface stride, or else
the AUX surface stride would get miscalculated and no longer
match the actual
From: Ville Syrjälä
plane_view_scanout_stride() currently assumes that we had to pad the
mapping stride with dummy pages in order to align it. But that is not
the case if the original fb stride exceeds the aligned stride used
to populate the remapped view, which is calculated from the user
From: Ville Syrjälä
Drop the redundant dev_priv parameters from
intel_ddi_compute_min_voltage_level() to make life easier.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c| 9 +
drivers/gpu/drm/i915/display/intel_ddi.h| 3 +--
From: Ville Syrjälä
On MTL we need to bump the voltage level to only 1 (not 2)
when port clock exceeds 594MHz. Make it so.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
The mess inside intel_ddi_compute_min_voltage_level() is illegible.
Clean it up a bit by splitting the internals into per-platform
functions.
TODO: make it a vfunc?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 37 +++-
1
From: Ville Syrjälä
Allow MTL to use voltage level 1 for 480MHz cdclk,
instead of the voltage level 2 that it's currently using.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
The cdclk->voltage_level if ladders are hard to read, especially as
they're written the other way around compared to how bspec lists
the limits. Let's rewrite them to use simple arrays that gives us
the max cdclk for each voltage level.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Currently we have a hardcoded assumption that the cd2x divider
is always 2 when squahsing is used. While that is true for all
current platforms it might not hold in the future. So eliminate
the assumption and calculate the correct divider from the other
parameters.
From: Ville Syrjälä
Replace the slightly magic 'size = 16' with a bit more descriptive
name. We'll have another user for this value later on.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Ville Syrjälä
cdclk_pll_is_unknown() used ~0 when checking for the "VCO is
unknown" value, but the assignment uses -1. They are the same
in the end, but let's use the same ~0 form on both sides for
consistency.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c
From: Ville Syrjälä
A bit of refactoring around the cdclk/voltage_level stuff.
I also spotted that we were miscalculating the voltage level
on MTL in two different places, so included fixes (or rather
power optimizations) for those.
Ville Syrjälä (8):
drm/i915/cdclk: s/-1/~0/ when dealing
From: Ville Syrjälä
Use the >= and < operators for the DISPLAY_VER checks everywhere.
This is what most of the code does, but especially recently random
pieces of code have started doing this differently for no good reason.
Conversion done with the following cocci:
@find@
expression i915;
From: Ville Syrjälä
We have no bigjoiner support in the MST code, so .mode_valid()
pretending otherwise is just going to result black screens for
users. Reject any mode that needs the joiner.
Cc: Stanislav Lisovskiy
Fixes: d51f25eb479a ("drm/i915: Add DSC support to MST path")
Signed-off-by:
From: Ville Syrjälä
.mode_valid_ctx() returns an errno, not the mode status. Fix
the code to do the right thing.
Cc: Stanislav Lisovskiy
Fixes: d51f25eb479a ("drm/i915: Add DSC support to MST path")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 12
From: Ville Syrjälä
Apparently some BXT/GLK systems have DSI panels whose timings
don't agree with the normal cpu transcoder hblank>=32 limitation.
This is perhaps fine as there are no specific hblank/etc. limits
listed for the BXT/GLK DSI transcoders.
Move those checks out from the global
From: Ville Syrjälä
No real reason why the PLL flags need to be a bitmask. Switch
to booleans to make the code simpler.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 46 +--
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 22 +
2
From: Ville Syrjälä
Make the log easier to parse by including the name of the PLL
in the debug prints regarding said PLL.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 39 ++-
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git
From: Ville Syrjälä
TC ports have both the MG/TC and TBT PLLs selected simultanously (so
that we can switch from MG/TC to TBT as a fallback). This doesn't play
well with the state checker that assumes that the old PLL shouldn't
have the pipe in its pipe_mask anymore. Suppress that check for
From: Ville Syrjälä
Declaring a struct and immediately zeroing it with memset()
seems a bit silly to me. Just zero initialize the struct
when declaring it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
From: Ville Syrjälä
Currently no one can figure out what the PSR code is doing since
we're including any of it in the basic state dump. Add at least the
bare minimum there.
v2: Also dump has_panel_replay (Jouni)
Cc: Jouni Högander
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Adding ad-hoc debug prints all over the place is not good.
Move the SDP split debug spew into the proper place (state
dumper).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc_state_dump.c | 3 +++
drivers/gpu/drm/i915/display/intel_dp.c
From: Ville Syrjälä
Print the pipe name in ascii rather than hex.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
From: Ville Syrjälä
Currently no one can figure out what the PSR code is doing since
we're including any of it in the basic state dump. Add at least the
bare minimum there.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc_state_dump.c | 5 +
1 file changed, 5
From: Ville Syrjälä
The PSR code is unconditionally enabling the VSC SDP whether or not PSR
itself is enabled. This means if the DP code decided not to use a VSC
SDP we're always transmitting a zeroed SDP. Not sure what the hardware
will even do in that case. We also see a "Failed to unpack DP
From: Ville Syrjälä
There's no real reason why we'd need a full modeset for audio
changes. So let's allow audio to be toggled during fastset.
In case the ELD changes while has_audio isn't changing state
we force both audio disable and enable so the new ELD gets
propagated to the audio driver.
From: Ville Syrjälä
Relocate the audio enable/disable from the full modeset hooks into
the common pre/post plane update stage of the commit. Audio fastset
is within easy reach now.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 31
From: Ville Syrjälä
Push the encoder->audio_{enable,disable}() calls out from the
encoder->{enable,disable}() hooks. Moving towards audio fastset.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c| 2 -
From: Ville Syrjälä
Add encoder vfuncs for audio enable/disable. This will allow
audio to be enabled/disabled during fastsets. An encoder hook
is necessary as on pre-hsw platforms different encoder types
implement audio in different ways.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Follow the hsw+ approach toggle the audio presence detect
when we set up the ELD, instead of doing it when turning the
port on/off.
This will facilitate audio enable/disable to happen during
fastsets instead of requiring a full modeset.
Reviewed-by: Jani Nikula
From: Ville Syrjälä
Follow the hsw+ approach toggle the audio presence detect
when we set up the ELD, instead of doing it when turning the
port on/off.
This will facilitate audio enable/disable to happen during
fastsets instead of requiring a full modeset.
Reviewed-by: Jani Nikula
From: Ville Syrjälä
Put a wrapper around the intel_audio_codec_{enable,disable}()
calls in the g4x+ DP/HDMI code. We shall move the presence
detect enable/disable into the wrappers later.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 26
From: Ville Syrjälä
Push the audio enable/disable to be the last/first thing
respectively that is done in the encoder enable/disable hooks.
The goal is to move it further out of these encoder hooks entirely.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Doing the if-else around RMWs is kinda silly. Just set/clear the
apporiate bits with a single RMW.
Also unify the coding style a bit icl_wa_cursorclkgating() while at it.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
We used to call intel_pre_plane_updates() for any pipe going through
a modeset whether the pipe was previously enabled or not. This in
fact needed to apply all the necessary clock gating workarounds/etc.
Restore the correct behaviour.
Fixes: 39919997322f ("drm/i915: Disable
From: Ville Syrjälä
{planes,vrr}_{enabling,disabling}() are supposed to indicate
whether the specific hardware feature is supposed to be enabling
or disabling. That can only makes sense if the pipe is active
overall. So check for that before we go poking at the hardware.
I think we're semi-safe
From: Ville Syrjälä
Implement audio fastset. Probably mosy useful in avoiding
some fastboot blinks, runtime audio fastset is less likely
to be a typical use case.
Also try to fix up a mess with pre_plane_update() vs.
already disabled pipe.
v2: Rebase
Ville Syrjälä (11):
drm/i915: Check pipe
From: Ville Syrjälä
IVB Bspec says:
"Frame Buffer Compression is only supported with memory surfaces of 4096 lines
or less and pipe source sizes of 4096 pixels by 2048 lines or less. "
so seems like we should be able to bump the offset+size limit to
at least 4kx4k. Make it so.
Signed-off-by:
From: Ville Syrjälä
FBC on icl+ should supposedly be fine with surface sizes up to
8kx4k. Bump up the limit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
Do separate checks for the visible plane size vs. the surface
size (which I take to mean offset+size). For now both use the
same max w/h, but we can relax the surface size limits as
a followup.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 32
From: Ville Syrjälä
Unfortunately even the HPD based detection added in
commit cfe5bdfb27fa ("drm/i915: Check HPD live state during eDP probe")
fails to detect that the VBT's eDP/DDI-A is a ghost on
Asus B360M-A (CFL+CNP). On that board eDP/DDI-A has its HPD
asserted despite nothing being
From: Ville Syrjälä
There's no real why we'd need a full modeset for audio changes.
So let's allow audio to be toggled during fastset. In case the
ELD changes while has_audio isn't changing state we force both
audio disable and enable so the new ELD gets propagated to the
audio driver.
From: Ville Syrjälä
Relocate the audio enable/disable from the full modeset hooks into
the common pre/post plane update stage of the commit. Audio fastset
is within easy reach now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 31 +++-
1 file
From: Ville Syrjälä
Push he encoder->audio_{enable,disable}() calls out from the
encoder->{enable,disable}() hooks. Moving towards audio fastset.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c| 2 -
drivers/gpu/drm/i915/display/g4x_hdmi.c | 10
501 - 600 of 8965 matches
Mail list logo
