From: Ville Syrjälä
The biggest thing here is changing the state checker to use
a dedicated crtc state (instead of clobbering the old state),
the rest is all polish.
Ville Syrjälä (12):
drm/i915/psr: Unify PSR pre/post plane update hooks
drm/i915: Stop clobbering old crtc state during state
From: Ville Syrjälä
The current check just asserts that we need FEC to use DSC
with (non-eDP) DP-SST. But MST also needs FEC for DSC. Just
check for !eDP instead to cover all the cases correctly.
v2: DP2/UHBR always uses FEC even though we don't flag it (Jani)
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Do a s/dev_priv/i915/ pass over the shared_dpll code to
get the variable names into sync with modern standards.
v2: Rebase
Reviewed-by: Jani Nikula #v1
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 872 +-
From: Ville Syrjälä
No one really cares how we store the shared_dplls. Currently
it happens to be an array, but we could change that to a more
flexible scheme at some point. Hide the implementation details
behind an iterator macro.
The slight downside is the pll variable moving out of the
loop
From: Ville Syrjälä
Start to clean up the mess around DPLL IDs a bit by removing
the nasty assumption that the index of the DPLL in the
arrays matches its ID. Fortunately we did have a WARN
i nthere to cathc mistakes, but better to not has such
silly assumptions i nthe first place.
There's
From: Ville Syrjälä
Stop assuming the size of PLL ID based bitmask is restricted
to I915_NUM_PLLS bits. This is the last thing coupling the
two things together and thus artificially limiting PLL IDs.
We could just pass any arbitrary (large enough) size to
for_each_set_bit() and be done with it,
From: Ville Syrjälä
There's no good reason to keep around this PLL index == PLL ID
footgun. Get rid of it.
Both i915->shared_dplls[] and state->shared_dpll[] are indexed
by the same thing now, which is just the index we get at
initialization from dpll_mgr->dpll_info[]. The rest is all about
PLL
From: Ville Syrjälä
Plane stride is always a multiple of 64 bytes. Remove the
pointless check that really doesn't have anything to do
with FBC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
From: Ville Syrjälä
Carve up stride_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Carve up tiling_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Carve up pixel_format_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
Note that the XRGB1555 can be dropped from the g4x+ variant
since the plane no longer supports that format anyway.
TODO: maybe go for vfuncs later
From: Ville Syrjälä
Carve up rotation_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The 16k max plane stride limit seems to be originally from
i965gm, and no explicit limit has been specified since (g4x+).
So let's assume the max plane stride itself is a suitable limit
also for the more recent FBC hardware.
In fact even for i965gm the max X-tiled stride is
From: Ville Syrjälä
In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.
Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening.
From: Ville Syrjälä
With all the known issues sorted out we can start to use
DSB to load the LUTs.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
From: Ville Syrjälä
Since flip_done_handler() is always called from the irq handler
we can skip the irqsave/restore dance.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_irq.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
From: Ville Syrjälä
Assuming crtc->state is pointing at the correct thing for the
async flip commit is nonsense. If we had already queued up multiple
commits this would point at the very lates crtc state even if the
older commits hadn't even happened yet.
Instead properly stage/arm the event
From: Ville Syrjälä
We have the same h/vsync_end vs. h/vtotal quirk in the VBT parser
that was also present in EDID parser. Adjust the VBT parser the
same way as was done for hte EDID parser to fixup h/vsync_end
instead of h/vtotal. While I'm not currently aware of any machines
that need this
From: Ville Syrjälä
There are some weird EDIDs floating around that have the sync
pulse extending beyond the end of the blanking period.
On the currently problemtic machine (HP Omni 120) EDID reports
the following mode:
"1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
which
From: Ville Syrjälä
This reverts commit 959fb1a686528df1b8fb0cc7bec8ff851b1594a5.
Looks like the core MST code might not call i2c_adapter() for us
in time, and thus creating the ddc symlink will fail. This will
in fact fail the entire connector registration, but the MST code
doesn't really seem
From: Ville Syrjälä
Implement low refresh rate (LRR) where we change the vblank
length by hand as requested, but otherwise keep the timing
generator running in non-VRR mode (ie. fixed refresh rate).
The panel itself must support VRR for this to work, and
only TGL+ has the double buffred
From: Ville Syrjälä
The 16k max plane stride limit seems to be originally from
i965gm, and no limit explicit limit has been specified since (g4x+).
So let's assume the max plane stride itself is a suitable limit
also for the more recent FBC hardware.
In fact even for i965gm the max X-tiled
From: Ville Syrjälä
Carve up rotation_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 30 +++-
1 file
From: Ville Syrjälä
Carve up stride_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 68 ++--
1 file changed,
From: Ville Syrjälä
Carve up pixel_format_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
Note that the XRGB1555 can be dropped from the g4x+ variant
since the plane no longer supports that format anyway.
TODO: maybe go for vfuncs later
From: Ville Syrjälä
Carve up tiling_is_valid() into per-platform variants to
make it easier to see what limits are actually being imposed.
TODO: maybe go for vfuncs later
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 21 ++---
1 file changed, 18
From: Ville Syrjälä
There are some weird EDIDs floating around that have the sync
pulse extending beyond the end of the blanking period.
On the currently problemtic machine (HP Omni 120) EDID reports
the following mode:
"1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
which
From: Ville Syrjälä
ICL doesn't support FEC with a x1 DP link. Make sure
we don't try to enable FEC in such cases.
Requires a bit of reordering to make sure we've computed lane_count
before checking it.
Cc: Luca Coelho
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c
From: Ville Syrjälä
The current check just asserts that we need FEC to use DSC
with (non-eDP) DP-SST. But MST also needs FEC for DSC. Just
check for !eDP instead to cover all the cases correctly.
Cc: Luca Coelho
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
From: Ville Syrjälä
Apparently Acer Chromebook C740 (BDW-ULT) doesn't have the
eDP HPD line properly connected, and thus fails the new
HPD check during eDP probe. The result is that we lose the
eDP output.
I suspect all such machines would all be Chromebooks or other
Linux exclusive systems as
From: Ville Syrjälä
Split intel_update_crtc() into two parts such that the first
part performs all the non-vblank evasion preparatory stuff,
and the second part just does the vblank evasion stuff.
For now we just call these back to back so that there is
no funcitonal change.
Signed-off-by:
From: Ville Syrjälä
Perform all the intel_pre_update_crtc() stuff for all pipes first,
and only then do the intel_update_crtc() vblank evasion stuff for
every pipe back to back. This should make it more likely that
the plane updates from multiple pipes happen on the same frame
(assuming the
From: Ville Syrjälä
Attempt at making synced multi-pipe commits a bit more atomic.
Ville Syrjälä (3):
drm/i915: Drop redundant !modeset check
drm/i915: Split intel_update_crtc() into two parts
drm/i915: Do plane/etc. updates more atomically across pipes
From: Ville Syrjälä
Since commit 7de5b6b54630 ("drm/i915: Don't flag both full
modeset and fastset at the same time")
intel_crtc_needs_fastset() and intel_crtc_needs_modeset() have
been mutually exclusive. Drop the redundant check.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Apparently Acer Chromebook C740 (BDW-ULT) doesn't have the
eDP HPD line properly connected, and thus fails the new
HPD check during eDP probe. The result is that we lose the
eDP output.
I suspect all such machines would all be Chromebooks or other
Linux exclusive systems as
From: Ville Syrjälä
Silently cancelling vblank works is a bit rude, especially
if said works do any resource management (eg. free memory).
WARN if we ever hit this.
TODO: Maybe drm_crtc_vblank_off() should wait for any
pending work to reach its target vblank before actually
doing anything
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased
From: Ville Syrjälä
Implement low refresh rate (LRR) where we change the vblank
length by hand as requested, but otherwise keep the timing
generator running in non-VRR mode (ie. fixed refresh rate).
The panel itself must support VRR for this to work, and
only TGL+ has the double buffred
From: Ville Syrjälä
Whenever we change the actual transcoder timings (clock via
seamless M/N, full modeset, (or soon) vtotal via LRR) we
want the timing generator to be in non-VRR during the commit.
Warn if we forgot to turn VRR off prior to vblank evasion.
Cc: Manasi Navare
Signed-off-by:
From: Ville Syrjälä
We should be able to change any of the VRR parameters
during fastsets as long as we toggle VRR off at the start
and then back on at the end. The transcoder will be running
in non-VRR mode during the transition.
Co-developed-by: Manasi Navare
Signed-off-by: Manasi Navare
From: Ville Syrjälä
Let's assume there are some crazy displays where the high
end of the VRR range ends up being lower than the refresh
rate as determined by the actual timings. In that case
when we toggle VRR on/off we would step outside the VRR
range when toggling VRR on/off. Let's just make
From: Ville Syrjälä
Make life less confusing by making sure VRR is disabled whenever
we do any drastic changes to the display timings, such as seamless
M/N changes.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 --
1 file changed, 4
From: Ville Syrjälä
Move is_in_vrr_range() into intel_vrr.c in anticipation of
more users, and rename it accordingly.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c | 17 -
drivers/gpu/drm/i915/display/intel_vrr.c | 9
From: Ville Syrjälä
In order to reconcile seamless M/N updates with VRR we'll
need to defer the fastset VRR enable to happen after the
seamless M/N update (which happens during the vblank evade
critical section). So just push the VRR enable to be the last
thing during the update.
This will also
From: Ville Syrjälä
Make the seamless_m_n flag more like the update_pipe fastset
flag, ie. the flag will only be set if we need to do the seamless
M/N update, and in all other cases the flag is cleared. Also
rename the flag to update_m_n to make it more clear it's similar
to update_pipe.
I
From: Ville Syrjälä
Don't perform a seamless M/N update if the values aren't actually
changing. This avoids doing extra shenanigans during vblank evasion
needlessly.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3
From: Ville Syrjälä
Pull the vblank evasion scanline calculations into their own helper
to declutter intel_pipe_update_start() a bit.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 53 +--
1 file changed, 31
From: Ville Syrjälä
We'll need to also look at the old crtc state in
intel_pipe_update_start() so change the calling convention to
just plumb in the full atomic state instead.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c| 18
From: Ville Syrjälä
Do the PSR unlock after the vblank evade critcal section is
fully over, not before.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
From: Ville Syrjälä
Attempt to make VRR, LRR, and M/N updates coexist nicely,
allowing fastsets whenever feasible.
Lightly smoke tested on my adl.
Cc: Manasi Navare
Ville Syrjälä (12):
drm/i915: Move psr unlock out
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased
From: Ville Syrjälä
Rename the various names we've used for the DDC bus
i2c adapter ("i2c", "adapter", etc.) to just "ddc".
This differentiates it from the various other i2c
busses we might have (DSI panel stuff, DVO control bus, etc.).
v2: Don't add a bogus drm_get_edid() call (Jani)
From: Ville Syrjälä
Remove the i915 specific i2c-N symlink from HDMI connectors.
This was added to sort of mirror the DP connectors that alreayd
had their aux ch based i2c adapter sitting beneath them in the
sysfs hierarchy. But now that we have the standard "ddc" symlink
approach provided by
From: Ville Syrjälä
We aren't intending to mutate the SDVO device mapping structs,
so make them const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
From: Ville Syrjälä
Remove the mostly redundant hdmi->ddc_bus. The only thing that needs
it anymore is get_encoder_by_ddc_bus(), but that can be replaced with
a slight detour through attached_connector+intel_gmbus_get_adapter().
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
We already populate connector->ddc for HDMI ports, but
so far we've not taken full advantage of it. Do that by
eliminating a bunch of intel_gmbus_get_adapter() lookups.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
From: Ville Syrjälä
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for analog DP SST connectors.
Let's also reorder intel_dp_aux_init() vs. drm_connector_init_with_ddc()
a bit to make sure the i2c aux ch is at least somewhat populated
before we pass it on, though
From: Ville Syrjälä
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for DVO connectors.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dvo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git
From: Ville Syrjälä
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for DP MST connectors.
TODO: test that this actually works
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3605
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_mst.c |
From: Ville Syrjälä
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for analog VGA connectors.
As a bonus we can replace a bunch of intel_gmbus_get_adapter()
lookups with just the connector->ddc pointer. Sadly one extra
lookup still remains due to the g4x DVI-I shenanigans.
From: Ville Syrjälä
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for the LVDS port.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_lvds.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git
From: Ville Syrjälä
Rename the various names we've used for the DDC bus
i2c adapter ("i2c", "adapter", etc.) to just "ddc".
This differentiates it from the various other i2c
busses we might have (DSI panel stuff, DVO control bus, etc.).
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Use the standard onion peeling approach and call
drm_debugfs_connector_remove() and
drm_sysfs_connector_remove() in the reverse order in
drm_connector_unregister() than what we called their
add counterpartse in drm_connector_register().
The error unwiding in
From: Ville Syrjälä
Currently drm_sysfs_connector_add() attempts to register
the "ddc" symlink (based one connector->ddc) before the
driver's .early_register() hook has been called. That is
too early for i915 which only fully registers the aux ch
and associated i2c bus from said hook (to prevent
From: Ville Syrjälä
Populate connector->ddc for all output types that don't already
do so, and clean up a bunch of code as a result of having the
ddc i2c adapter in easy reach. And this also provides the sysfs
"ddc" symlink.
There are potentially a few oddball (mostly DVI-I) cases where
the
From: Ville Syrjälä
Make the seamless_m_n flag more like the update_pipe fastset
flag, ie. the flag will only be set if we need to do the seamless
M/N update, and in all other cases the flag is cleared. Also
rename the flag to update_m_n to make it more clear it's similar
to update_pipe.
I
From: Ville Syrjälä
Don't perform a seamless M/N update if the values aren't actually
changing. This avoids doing extra shenanigans during vblank evasion
needlessly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1
From: Ville Syrjälä
Some prep work towards reconciling VRR and M/N. I think after these
we coukd try VRR fastsets that alter the state of the VRR registers,
assuming we toggle VRR off and on around the update.
Cc: Manasi Navare
Ville Syrjälä (6):
drm/i915: Move psr unlock out from the pipe
From: Ville Syrjälä
In order to reconcile seamless M/N updates with VRR we'll
need to defer the fastset VRR enable to happen after the
seamless M/N update (which happens during the vblank evade
critical section). So just push the VRR enable to be the last
thing during the update.
This will also
From: Ville Syrjälä
Pull the vblank evasion scanline calculations into their own helper
to declutter intel_pipe_update_start() a bit.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 53 +--
1 file changed, 31 insertions(+),
From: Ville Syrjälä
We'll need to also look at the old crtc state in
intel_pipe_update_start() so change the calling convention to
just plumb in the full atomic state instead.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c| 18
From: Ville Syrjälä
Do the PSR unlock after the vblank evade critcal section is
fully over, not before.
Cc: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
From: Ville Syrjälä
We already have encoder->port so get rid of the duplicate
sdvo->port.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git
From: Ville Syrjälä
Call drm_encoder_init() earlier so that we don't have to keep passing
the i915/dev_priv around separately.
v2: Reorder drm_encoder_cleanup() in the error path (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 37
From: Ville Syrjälä
To reduce the guesswork a bit let's print out the SDVO
device i2c bus and slave address during init.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 4
1 file changed, 4 insertions(+)
diff --git
From: Ville Syrjälä
Each SDVO device can have up to three sets of DDC pins.
Currently we just register a single i2c_adapter for the
entire SDVO device and semi-randomly pick the "correct"
set of DDC pins during intel_sdvo_tmds_sink_detect().
This doesn't make any real sense especially if we have
From: Ville Syrjälä
We should switch over to the standard "ddc" per-connector
symlink instead of rolling our own thing. The i2c specific
symlink is also in the way of reworking the SDVO DDC handling
(which is a mess atm) so get rid of it.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Instead of operating on the output the user specified (via the
connector) the current code tends to operate on whichever outputs
it has detected as attached. That is not how the kms uapi is supposed
to work. So simply get rid of attached_outputs and instead directly
operate
From: Ville Syrjälä
I have plans to switch the whole driver over to using
drm_connector_init_with_ddc(), and thus populate the
sysfs "ddc" consistently. The biggest hurdle is the
SDVO DDC handling, so start by cleaning that up.
I also found some other issues with the SDVO code so
some
From: Ville Syrjälä
Currently dma_resv_get_fences() will leak the previously
allocated array if the fence iteration got restarted and
the krealloc_array() fails.
Free the old array by hand, and make sure we still clear
the returned *fences so the caller won't end up accessing
freed memory. Some
From: Ville Syrjälä
To reduce the guesswork a bit let's print out the SDVO
device i2c bus and slave address during init.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
From: Ville Syrjälä
Each SDVO device can have up to three sets of DDC pins.
Currently we just register a single i2c_adapter for the
entire SDVO device and semi-randomly pick the "correct"
set of DDC pins during intel_sdvo_tmds_sink_detect().
This doesn't make any real sense especially if we have
From: Ville Syrjälä
We should switch over to the standard "ddc" per-connector
symlink instead of rolling our own thing. The i2c specific
symlink is also in the way of reworking the SDVO DDC handling
(which is a mess atm) so get rid of it.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
We already have encoder->port so get rid of the duplicate
sdvo->port.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git
From: Ville Syrjälä
Call drm_encoder_init() earlier so that we don't have to keep passing
the i915/dev_priv around separately.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 35 +++
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git
From: Ville Syrjälä
Instead of operating on the output the user specified (via the
connector) the current code tends to operate on whichever outputs
it has detected as attached. That is not how the kms uapi is supposed
to work. So simply get rid of attached_outputs and instead directly
operate
From: Ville Syrjälä
Instead of warning and continuing with bogus state when the
requested dotclock isn't acceptable just print some debug
spew and fail gracefully.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 18 +-
1 file changed, 13
From: Ville Syrjälä
port_clock is what the encoder/dpll code is supposed to calculate,
it is not the input clock. Use the dotclock as the target we're
trying to achieve instead.
TODO: the SDVO TV clocking is a mess atm and needs further work
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Call *_calc_dpll_params() even in cases where the encoder has
computed the DPLL params for us.
The SDVO TV output code doesn't populate crtc_state->dpll.dot
leading to the dotclock getting calculated as zero, and that
leads to all kinds of real problems. The g4x DP code also
From: Ville Syrjälä
Allow *_calc_dpll_params() to be called even if the N/P dividers
are zero without warning. We'll want to call these to make sure the
derived values are fully computed, but not all users (VLV DSI in
particular) don't even enable the DPLL and thus the dividers will
be left at
From: Ville Syrjälä
The SDVO inputs are reportes a simple number, not a bitmask.
Adjust the code to match reality.
Note that we don't actually support dual input SDVO devices,
and we just always use the first input.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c
From: Ville Syrjälä
Put parens around macro argument evaluation for safety.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
From: Ville Syrjälä
I have at least one SDVO device (some Lenovo DVI-I ADD2 card,
based on Conexant CX25904) where GetAttachedDisplays returns
success but fails to report any attached displays unless wet
precede the command with a SetTargetOutput. Make it so.
I wasn't able to spot anything in
From: Ville Syrjälä
I have plans to switch the whole driver over to using
drm_connector_init_with_ddc(), and thus populate the
sysfs "ddc" consistently. The biggest hurdle is the
SDVO DDC handling, so start by cleaning that up.
I also found some other issues with the SDVO code so
some
From: Ville Syrjälä
We'll have a few places where we need to do the full (incl. ICL+ DSI)
DVO port->port conversion, so extract the code for that into a helper.
Suggested-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 18 ++
1
From: Ville Syrjälä
Stop with the VBT AUX CH sanitation, and instead just check
that the appropriate AUX CH is still available when initializing
a DP/TC port.
The reason being that we want to start initializing ports in
VBT order to deal with VBTs that declare child devices with
seemingly
From: Ville Syrjälä
Stop with the VBT DDC pin sanitation, and instead just check
that the appropriate DDC pin is still available when initializing
a HDMI connector.
The reason being that we want to start initializing ports in
VBT order to deal with VBTs that declare child devices with
seemingly
From: Ville Syrjälä
Mixing VBT based AUX CH with platform defaults seems like
a recipe for conflicts. Let's only populate AUX CH if we
absolutely need it, that is only if we are dealing with
a DP output or a TC port (which need it due to some power
well shenanigans).
TODO: double check that
From: Ville Syrjälä
Try to deal with duplicate child devices for the same DDI port
by attempting to initialize them in VBT defined order The first
on to succeed for a specific DDI port will be the one we use.
We'll also get rid of i915->display.vbt.ports[] here as any conflicts
will now be
From: Ville Syrjälä
The remaining parts of the big VBT based DDI port initialization
series.
The main goal being to get the HDMI port working on many
ADL-P machines where the VBT declares both eDP and HDMI
for the same DDI port (B).
v3: Pimped commit messages
Add intel_bios_encoder_port()
601 - 700 of 8901 matches
Mail list logo
