From: Stanislav Lisovskiy
Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
slave crtcs should be handled by master hooks. Same for encoders.
That way we can also remove a bunch of checks like
intel_crtc_is_bigjoiner_slave.
v2: - Moved skl_pfit_enable, intel_dsc_enable, inte
From: Ville Syrjälä
Unify the master vs. slave handling in
intel_ddi_post_disable_hdmi_or_sst() by looping over all the
pipes in one go.
This also lets us move the intel_crtc_vblank_off() calls to
happen in a consistent place vs. the transcoder disable.
Previously we did the master vs. slaves on
From: Ville Syrjälä
Extract the "not-MST" stuff from intel_ddi_post_disable() so that
the whole thing isn't so cluttered.
The bigjoiner slave handling was outside of the !MST check,
but it really should have been inside it as its the counterpart
to the master handling inside the check. So we pul
From: Ville Syrjälä
Add a small helper to compute the set of pipes that the current
crtc is using.
And we have at least one trivial place in
intel_ddi_update_active_dpll() where we can use it
immediately, so let's do that.
v2: Use the name 'pipe_crtc' for the per-pipe crtc pointer
Signed-off-b
From: Ville Syrjälä
ICL supposedly doesn't support FEC on MST. Reject it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel
From: Ville Syrjälä
The MST code currently assumes that glk+ alerady supports MST+DSC,
which is incorrect. We need to check for TGL+ actually. ICL does
support SST+DSC, but supposedly it can't do MST+FEC which will
also rule MST+DSC.
Note that a straight TGL+ check doesn't work here because DSC
From: Ville Syrjälä
Pass the connector explicitly to intel_dp_need_bigjoiner()
so that it'll actually check the correct place for the
bigjoiner force flag.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
drivers/gpu/drm/i915/display/intel_dp.h
From: Ville Syrjälä
Pull the "does joiner need DSC?" check into a helper. MST will
want to use this too at some point.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 26 ++---
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
drivers/gpu/drm/i9
From: Ville Syrjälä
intel_dp_mst_compute_config() is missing the "does the
joiner need DSC?" check despite claiming to have a lot
of other joiner/dsc stuff in there (albeit disabled).
Replicate the logic from the SST side.
TODO: refactor all this duplicated code!
Signed-off-by: Ville Syrjälä
-
From: Ville Syrjälä
Rename intel_dp_can_bigjoiner() to intel_dp_has_bigjoiner()
to better reflect its function.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
d
From: Ville Syrjälä
Simplify our life by extracting the "do we need the glk scaler
clock gating w/a?" check into a small helper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/d
From: Ville Syrjälä
glk_pipe_scaler_clock_gating_wa() is messy. Clean it up via
intel_de_rmw(), and also just pass in the whole crtc so the
caller doesn't dance around so much.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 19 +++
1 file change
From: Ville Syrjälä
Move some of the more trivial checks in the DP .mode_valid()
hooks upwards to lessen the noise amongst the more complex
checks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 21 +++
From: Ville Syrjälä
We never set connector->doublescan_allowed, so the probe helper
already filters out all doublescan modes for us.
Sadly we still need to keep the explicit doublescan checks
in .compute_config as outlined in commit e4dd27aadd20
("drm/i915: Allow DBLSCAN user modes with eDP/LVDS
From: Ville Syrjälä
All joined pipes share the same transcoder/timing generator.
Currently we just do the commits per-pipe, which doesn't really
work if we need to change switch between non-VRR and VRR timings
generators on the fly, or even when sending the push to the
transcoder. For now just di
From: Ville Syrjälä
All joined pipes share the same transcoder/timing generator.
Currently we just do the commits per-pipe, which doesn't really
work if we need to change the timings at the same time. For
now just disable live M/N updates when bigjoiner is needed.
Signed-off-by: Ville Syrjälä
-
From: Ville Syrjälä
Currently intel_modeset_pipe_config_late() is called after the
bigjoiner state copy, and it will actually not do anything for
bigjoiner slaves. This can lead to a mismatched state between
the master and slave.
The two things that we do in the encoder .compute_config_late()
ho
From: Ville Syrjälä
I started to look at the MST+bignoier stuff floating around
and then decided that there's just too much noise in the way,
and so did a quick pass over the whole thing to clean and
fix things up ahead of time.
I then applied the stuff from Stan and Vidya on top of what
I had a
From: Ville Syrjälä
The current modeset sequence can't handle port sync and bigjoiner
at the same time. Refuse port sync when bigjoiner is needed,
at least until we fix the modeset sequence.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 inse
From: Ville Syrjälä
Currently intel_modeset_pipe_config_late() is called after the
bigjoiner state copy, and it will actually not do anything for
bigjoiner slaves. This can lead to a mismatched state between
the master and slave.
The two things that we do in the encoder .compute_config_late()
ho
From: Ville Syrjälä
The current modeset sequence can't handle port sync and bigjoiner
at the same time. Refuse port sync when bigjoiner is needed,
at least until we fix the modeset sequence.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 inse
From: Ville Syrjälä
Refuse bigjoiner+port sync as it's completely broken,
and also fix a potential state mismatch once we do
get MST/port sync + bigjoiner support.
Ville Syrjälä (2):
drm/i915: Disable port sync when bigjoiner is used
drm/i915: Fix intel_modeset_pipe_config_late() for bigjoin
From: Ville Syrjälä
if the new dbuf slices are a superset of the old
dbuf slices then we don't have to do anything in
intel_dbuf_post_plane_update(). Restructure the code
to skip such redundant dbuf slice updates. The main
benefit is slightly less confusing logs.
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
No point in throwing around u8 when we're dealing with
just an integer. Use a plain old boring 'int'.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 6 +++---
drivers/gpu/drm/i915/display/intel_cdclk.h | 4 ++--
drivers/gpu/drm/i915/displa
From: Stanislav Lisovskiy
Currently we can't change MBUS join status without doing a modeset,
because we are lacking mechanism to synchronize those with vblank.
However then this means that we can't do a fastset, if there is a need
to change MBUS join state. Fix that by implementing such change.
From: Stanislav Lisovskiy
In order to make sure we are not breaking the proper sequence
lets to updates step by step and don't change MBUS join value
during MDCLK/CDCLK programming stage.
MBUS join programming would be taken care by pre/post ddb hooks.
v2: - Reworded comment about using old mbus
From: Ville Syrjälä
Extact the stuff that writes the dbuf/mbus ration stuff
into its own function. Will help with correctly sequencing
the operations done during mbus programming.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_watermark.c | 43
1 file ch
From: Ville Syrjälä
Add some debugs so that we can actually observe what is
actually happening during the mbus/dbuf programming steps.
We can just shove them into fairly low level functions as
none of them are called during any critical sections/etc.
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
Extact the stuff that writes the joining bits in MBUS_CTL
into its own function. Will help with correctly sequencing
the operations done during mbus programming.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_watermark.c | 37 +---
1 file
From: Ville Syrjälä
intel_mbus_dbox_update() will become static soon. Relocate it
into a place that avoids having to add a forward declaration
for it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_watermark.c | 166 +--
1 file changed, 83 insertions(+), 83 d
From: Stanislav Lisovskiy
We need to loop through all active pipes, not just the ones, that
are in current state, because disabling and enabling even a particular
pipe affects credits in another one.
Signed-off-by: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/disp
From: Ville Syrjälä
Currently we just get a plain "Changing CDCLK to ..." in the
logs. It would actually be interesting to see whether we're
doing the programming during the pre or post plane phase of
the commit. Include that information in the debug message.
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
Currently we only consider the relationship of the
old and new CDCLK frequencies when determining whether
to do the repgramming from intel_set_cdclk_pre_plane_update()
or intel_set_cdclk_post_plane_update().
It is technically possible to have a situation where the
CDCLK frequ
From: Ville Syrjälä
No ever figured out why bumping the cdclk helped
with whatever issue we were having at the time.
Remove the hacks and start from scratch so that we
can actually see if any problems still remain.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 1
From: Ville Syrjälä
Currently we always reprogram CDCLK from the
intel_set_cdclk_pre_plane_update() when using squahs/crawl.
The code only works correctly for the cd2x update or full
modeset cases, and it was simply never updated to deal with
squash/crawl.
If the CDCLK frequency is increasing we
From: Ville Syrjälä
Get rid of the full modeset requirement for changing mbus
joining. Things got quite a bit more complicated than
originally envisioned due to the dynamic cdclk/mdclk ratio.
Sadly we have to do a fairly careful dance between the
dbuf and cdclk code to make sure everything is pro
From: Ville Syrjälä
Currently we only consider the relationship of the
old and new CDCLK frequencies when determining whether
to do the repgramming from intel_set_cdclk_pre_plane_update()
or intel_set_cdclk_post_plane_update().
It is technically possible to have a situation where the
CDCLK frequ
From: Ville Syrjälä
Currently we always reprogram CDCLK from the
intel_set_cdclk_pre_plane_update() when using squahs/crawl.
The code only works correctly for the cd2x update or full
modeset cases, and it was simply never updated to deal with
squash/crawl.
If the CDCLK frequency is increasing we
From: Ville Syrjälä
No ever figured out why bumping the cdclk helped
with whatever issue we were having at the time.
Remove the hacks and start from scratch so that we
can actually see if any problems still remain.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 1
From: Ville Syrjälä
Currently we only consider the relationship of the
old and new CDCLK frequencies when determining whether
to do the repgramming from intel_set_cdclk_pre_plane_update()
or intel_set_cdclk_post_plane_update().
It is technically possible to have a situation where the
CDCLK frequ
From: Ville Syrjälä
Fix the CDCLK programming sequence when using squash or crawl,
and also drop the tgl/dg2 hacks since we have no idea what those
are for.
Ville Syrjälä (3):
drm/i915/cdclk: Fix CDCLK programming order when pipes are active
drm/i915/cdclk: Fix voltage_level programming edge
From: Ville Syrjälä
Currently we always reprogram CDCLK from the
intel_set_cdclk_post_plane_update() when using squahs/crawl.
The code only works correctly for the cd2x update or full
modeset cases, and it was simply never updated to deal with
squash/crawl.
If the CDCLK frequency is increasing w
From: Ville Syrjälä
Calling i915_gem_object_get_dma_address() from the vblank
evade critical section triggers might_sleep().
While we know that we've already pinned the framebuffer
and thus i915_gem_object_get_dma_address() will in fact
not sleep in this case, it seems reasonable to keep the
unc
From: Ville Syrjälä
Add the missing BDB version number information for some of
the backlight fields in VBT.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_
From: Ville Syrjälä
According to some VBIOS sources the LFP power block used to
have a single bit for DPST support. In version 159 that bit
got moved into the driver features block, and then in version
228 back into the LFP power block (but this time as a
per-panel thing). We have definitions for
From: Ville Syrjälä
The VBT backlight entries include various fields for i2c
controlled backlights. These have been obsoleted at some
unknown point in time, but let's define them anyway so that
we have a full picture of what has been in there.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i
From: Ville Syrjälä
While the spec does claim that most of the driver feature flags
start from BDB version 165, reality and some VBIOS code disagrees.
The VBIOS code says it sart from version 159, and my ILK
with version 162 definitely has these things already in its
VBT. Update the version numbe
From: Ville Syrjälä
We've misspelled the VBT DFPS (dynamic frames per second) field
as DPFS. Fix it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
From: Ville Syrjälä
Update a bunch of our VBT defintions based on real world data
and an archaeological dig through some VBIOS ruins.
Ville Syrjälä (5):
drm/i915/bios: s/dpfs/dfps/
drm/i915/bios: Update VBT driver feature block version numbers
drm/i915/bios: Add the old DPST field into VBT
From: Ville Syrjälä
Pull the ilk/snb/ivb LP watermark disable checks into a separate
function similar to the gmch counterpart (i9xx_must_disable_cxsr()).
Reduces the clutter in intel_plane_atomic_calc_changes() significantly.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atom
From: Ville Syrjälä
Rename need_async_flip_disable_wa to need_async_flip_toggle_wa to
better reflect the fact that we need to deal with the bad
PLANE_CTL_ASYNC_FLIP double buffering behaviour going both
ways.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c |
From: Ville Syrjälä
On bdw-glk the sync->async flip change takes an extra frame due to
the double buffering behaviour of the async flip plane control bit.
Since on skl+ we are now explicitly converting the first async flip
to a sync flip (in order to allow changing the modifier and/or
ddb/waterm
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ä
DDB/watermarks are always double buffered on the vblank, so we
can't safely change them during async flips. Currently this never
happens, but we'll be making changing between sync and async
flips a bit more flexible, in which case we can actually end up
here.
Signed-off-by: V
From: Ville Syrjälä
On ADL async flips apparently generate DMAR and GGTT faults
(with accompanying visual glitches) unless PLANE_SURF is
aligned to at least 16k. Bump up the alignment to 16k.
TODO: analyze things better to figure out what is really
going on here
Signed-off-by: Ville Syrjä
From: Ville Syrjälä
Xorg/modesetting expects to be able to change the modifier already
when submitting the first async flip. Let's convert the first async
flip to a sync flip so that we can accommodate it. For now I limit
this behaviour to skl+ since earlier platforms don't support async
flips wi
From: Ville Syrjälä
When we have no VBT we currently assume ports A-F are
all pontially valid for every platform. That is nonsense.
Grab the bitmask of valid ports from the runtime info
instead.
Although the defaults we actually fill here look semi-sensible
only for hsw-skl era hardware. Dunno i
From: Ville Syrjälä
If we have no VBT, or the VBT didn't declare the encoder
in question, we won't have the 'devdata' for the encoder.
Instead of oopsing just bail early.
We won't be able to tell whether the port is DP++ or not,
but so be it.
Cc: sta...@vger.kernel.org
Closes: https://gitlab.fr
From: Ville Syrjälä
Advertize more suitable cursor sizes via the new SIZE_HINTS
plane property.
We can't really enumerate all supported cursor sizes on
the platforms where the cursor height can vary freely, so
for simplicity we'll just expose all square+POT sizes between
each platform's min and
From: Ville Syrjälä
Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all lim
From: Ville Syrjälä
Final final version I hope. Mainly for CI to test against the
new IGTs.
Real userspace implementation:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165
IGT:
https://patchwork.freedesktop.org/series/131199
From: Ville Syrjälä
Our definitions for bit 7 and bit 0 of ICL_PORT_TX_DW6 are
swapped. Functionally it doesn't matter as we always set both
bits, but let's rename the bits to match bspec 100%.
And while at it, add the definition for bits 1-6 as well, just
to have it all fully documented.
Signe
From: Ville Syrjälä
Remove the pointless (void*) cast, the incoming pointer is already
the correct type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
b/d
From: Ville Syrjälä
commit 64f6a5d1922b ("container_of: add container_of_const()
that preserves const-ness of the pointer") is nice. Let's use
it so that we don't accidentally cast away the const from our
state pointers.
The only thing I don't particularly like about container_of_const()
is that
From: Ville Syrjälä
The connector state passed to .atomic_get_property() is const.
We should preserve that when downcasting to our version.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/g
From: Ville Syrjälä
Use enc_to_intel_dsi() instead hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 3 +--
drivers/gpu/drm/i915/display/vlv_dsi.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_d
From: Ville Syrjälä
Start using container_of_const() for some extra const safety.
Ville Syrjälä (4):
drm/i915/dsi: Use enc_to_intel_dsi()
drm/i915: Don't cast away const
drm/i915: Use container_of_const() for states
drm/i915: Drop pointless (void*) cast
drivers/gpu/drm/i915/display/icl
From: Ville Syrjälä
Looks like the undelayed vblank gets signalled exactly when
the active period ends. That is a problem for DSB+VRR when
we are already in vblank and expect DSB to start executing
as soon as we send the push. Instead of starting the DSB
just keeps on waiting for the undelayed vb
From: Ville Syrjälä
Bspec asks us to always set the DSB_SKIP_WAITS_EN bit in
DSB_CHICKEN. This seems to instruct DSB to skip vblank and
scanline waits when PSR is entered.
I don't think we have any cases currently where we would want
to enter PSR while DSB is waiting for something, but let's
set
From: Ville Syrjälä
Looks like TRANS_CHICKEN bit 31 means something totally different
depending on the platform:
TGL: generate VRR "safe window" for DSB
ADL/DG2: make TRANS_SET_CONTEXT_LATENCY effective with VRR
So far we've only set this on ADL/DG2, but when using DSB+VRR
we also need to set it
From: Ville Syrjälä
Make DSB vblank waits work correctly when VRR is enabled.
Ville Syrjälä (3):
drm/i915/vrr: Generate VRR "safe window" for DSB
drm/i915/dsb: Fix DSB vblank waits when using VRR
drm/i915/dsb: Always set DSB_SKIP_WAITS_EN
drivers/gpu/drm/i915/display/intel_dsb.c | 15 +++
From: Ville Syrjälä
Stop passing in so much redundant stuff to
intel_old_crtc_state_disables(). Top level atomic state + crtc
is all we need.
And while at it constify the states to make it clear they should
not be mutated.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_di
From: Ville Syrjälä
Follow in the footsteps of commit c610e841f19d ("drm/i915:
Do plane/etc. updates more atomically across pipes") and
do the plane disables back to back for all pipes also when
we are disabling pipes.
This should provide for a potentially more atomic user
experience, which migh
From: Ville Syrjälä
Copy the pipe bitmask based approach skl_commit_modeset_enables()
into intel_commit_modeset_disables(). This avoids doing so many
duplicated checks in all the loops, and also let's us WARN at the
end if we screwed up somewhere and forgot to disable some pipe.
Signed-off-by: V
From: Ville Syrjälä
Make the crtc disable more atomic (in terms of plane disable).
And also also track which pipes need disabling in the same way
as skl_commit_modeset_enables(), which should make the whole
thing bit less messy as we don't have to keep on checking the
same conditions multiple ti
From: Ville Syrjälä
Reinstate commit 88b065943cb5 ("drm/i915/dsi: Do display on
sequence later on icl+"), for the most part. Turns out some
machines (eg. Chuwi Minibook X) really do need that updated order.
It is also the order the Windows driver uses.
However we can't just undo the revert since
From: Ville Syrjälä
Reorganize the crtc disable path to only deal with the
master pipes/transcoders in intel_old_crtc_state_disables()
and offload the handling of joined pipes to hsw_crtc_disable().
This makes the whole thing much more sensible since we can
actually control the order in which we
From: Ville Syrjälä
Reorganize the crtc disable path to only deal with the
master pipes/transcoders in intel_old_crtc_state_disables()
and offload the handling of joined pipes to hsw_crtc_disable().
This makes the whole thing much more sensible since we can
actually control the order in which we
From: Ville Syrjälä
Stop passing in so much redundant stuff to
intel_old_crtc_state_disables(). Top level atomic state + crtc
is all we need.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
From: Ville Syrjälä
Follow in the footsteps of commit c610e841f19d ("drm/i915:
Do plane/etc. updates more atomically across pipes") and
do the plane disables back to back for all pipes also when
we are disabling pipes.
This should provide for a potentially more atomic user
experience, which migh
From: Ville Syrjälä
Copy the pipe bitmask based approach skl_commit_modeset_enables()
into intel_commit_modeset_disables(). This avoids doing so many
duplicated checks in all the loops, and also let's us WARN at the
end if we screwed up somewhere and forgot to disable some pipe.
Signed-off-by: V
From: Ville Syrjälä
Unify the master vs. slave handling in
intel_ddi_post_disable_hdmi_or_sst() by looping over all the
pipes in one go.
This also lets us move the intel_crtc_vblank_off() calls to
happen in a consistent place vs. the transcoder disable.
Previously we did the master vs. slaves on
From: Ville Syrjälä
Extract the "not-MST" stuff from intel_ddi_post_disable() so that
the whole thing isn't so cluttered.
The bigjoiner slave handling was outside of the !MST check,
but it really should have been inside it as its the counterpart
to the master handling inside the check. So we pul
From: Ville Syrjälä
Add a small helper to compute the set of pipes that the current
crtc is using.
And we have at least one trivial place in
intel_ddi_update_active_dpll() where we can use it
immediately, so let's do that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dd
From: Ville Syrjälä
In preparation for doing a more sensible pipe vs. transcoder
handling for bigjoiner let's rename the crtc/crtc_state in the
top level crtc_enable/disable and the DDI encoder hooks to
include "master" in the name. This way they won't collide with
the per-pipe stuff.
Note that
From: Ville Syrjälä
Here's some prep work I cooked up while thinking how to handle
the bigjoiner stuff. I coverted the .crtc_disable() side of things
to follow the new approach of iterating the joined pipes at a lower
level. Looks pretty reasonable to me in the end. The enable side
is somewhat mo
From: Ville Syrjälä
Drop the pointless phy/port detour from the eDP handling
in icl_combo_phy_aux_power_well_enable(). We can just directly
consult the dig_port and determine whether it's eDP or not.
This also removes the assumption that port==phy, although that is
always trued on ICL, so it was
From: Ville Syrjälä
We don't actually know whether we should be picking the PHY
simply based on the AUX_CH/power well, or based on the VBT
defined AUX_CH->DDI->PHY relationship. At the moment we are
doing the former for the ANAOVRD workaround, and the latter
for the ICL_LANE_ENABLE_AUX override.
From: Ville Syrjälä
Modernize the ICL+ combo PHY register refinitions by using
REG_BIT() & co.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_combo_phy_regs.h | 114 +-
1 file changed, 55 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i
From: Ville Syrjälä
ICL_AUX_ANAOVRD1 is actually ICL_PORT_TX_DW6_AUX. Give it its proper
name, and relocate to the correct file (intel_combo_phy_regs.h).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_combo_phy_regs.h | 6 ++
drivers/gpu/drm/i915/display/intel_disp
From: Ville Syrjälä
Create the drm_printer at the start of intel_pipe_config_compare()
and pass it on to all the mismatch() functions.
v2: Rebase
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 101 +--
1 file changed,
From: Ville Syrjälä
Just call pipe_config_mismatch() from all the more specialized
mismatch() functions instead of hand rolling the same printfs
all over.
v2: Eliminate the dpll drm_debug_enabled() in an earlier patch (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/g
From: Ville Syrjälä
Utilize drm_printer in pipe_config_pll_mismatch() to avoid
a bit of code duplication.
To achieve this we need to plumb the printer all way to the
dpll_mgr .dump_hw_state() functions. Those are also used by
intel_crtc_state_dump() which needs to be adjusted as well.
v2: Conve
From: Ville Syrjälä
inlined from ‘i915_ttm_get_pages’ at
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:847:2:
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:165:18: warning: ‘places[0].flags’
is used uninitialized [-Wuninitialized]
165 | places[0].flags |= TTM_PL_FLAG_DESIRED;
|
From: Ville Syrjälä
Advertize more suitable cursor sizes via the new SIZE_HINTS
plane property.
We can't really enumerate all supported cursor sizes on
the platforms where the cursor height can vary freely, so
for simplicity we'll just expose all square+POT sizes between
each platform's min and
From: Ville Syrjälä
Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all lim
From: Ville Syrjälä
Final version for a new plane SIZE_HINTS property to
essentially replace the cursor size caps, based on recent
discussion in this gitlab bug:
https://gitlab.freedesktop.org/drm/intel/-/issues/7687
As for userspace, so far I only did a quick modetest
blob decoder (mainly to ve
From: Ville Syrjälä
ADL DSI transcoders do not have the new SET_CONTEXT_LATENCY
register. Instead they supposedly use the older TGL VBLANK_START
based method of defining the vblank delay.
Completely untested due to lack of suitable hardware.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i9
From: Ville Syrjälä
Looks like I misplaced a few hunks when I moved the audio
enable/disable out from the encoder enable/disable hooks.
So we are now doing a double audio enable/disable on SDVO
and g4x+ DP. Probably harmless as doing it twice shouldn't
really change anything, but let's do it just
From: Ville Syrjälä
Just return the correct thing from within the loop to make
the code more readable. We have no ref counts/etc. to deal
with here so no point in breaking from the loop just to return
something.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_power_well.c
401 - 500 of 3032 matches
Mail list logo
