From: Ville Syrjälä
Extract the skl+ wm latency determination into a small helper
so that everyone has the same idea what the latency should be.
This introduces a slight functional change in that
skl_cursor_allocation() will now start to account for the
extra 4 usec that the kbk/cfl/cml IPC w/a
From: Ville Syrjälä
Remainder of the vblank length/start stuff, rebased to deal
with the watermark max_level vs. num_level changes.
Ville Syrjälä (2):
drm/i915: Extract skl_wm_latency()
drm/i915: Reject wm levels that exceed vblank time
drivers/gpu/drm/i915/display/skl_watermark.c | 155
From: Ville Syrjälä
Remove the bogus csync check and replace it with something that:
- triggers for all forms of csync, not just the basic analog variant
- actually populates the mode csync flags so that drivers can
decide what to do with the mode
Originally the code tried to outright reject
From: Ville Syrjälä
Remove the bogus csync check and replace it with something that:
- triggers for all forms of csync, not just the basic analog variant
- actually populates the mode csync flags so that drivers can
decide what to do with the mode
Originally the code tried to outright reject
From: Ville Syrjälä
intel_crtc_prepare_cleared_state() is unintentionally losing
the "inherited" flag. This will happen if intel_initial_commit()
is forced to go through the full modeset calculations for
whatever reason.
Afterwards the first real commit from userspace will not get
forced to the
From: Ville Syrjälä
The audio logic lives in the transcoder rather than the pipe,
so start tracking it like that.
This is only really important for bigjoiner cases where tracking
by pipe doesn't work at all since intel_audio_codec_{enable,disable}()
won't even be called for the slave pipe. This
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.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 3 ++
drivers/gpu/drm/i915/display/intel_bios.c | 56
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 ot 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.
TODO: DSI dual link handling is sketchy at best
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Make HSW/BDW use the new VBT child device driven output
probing as well. To achieve that the strap checks are
moved into intel_ddi_init() itself.
I have one HSW ULT laptop here which declares all the ports
A-D in the VBT, so in order to avoid assert_port_valid() tripping
on
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.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 72 ---
From: Ville Syrjälä
Make sure dig_port->aux_ch is trustworthy by initializing it
to NONE at the start. The encoder init will later fill in
the actual value, if appropriate.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c| 2 ++
From: Ville Syrjälä
The SDVO code already warns when the port in question doesn't
actually support SDVO. Let's make that also bail the encoder
registration like the generic assert_port_valid() we added.
And add a similar thing for g4x HDMI, mainly because on g4x
itsefl port D only supports DP
From: Ville Syrjälä
Sprinkle some asserts to catch any mishaps in the port_mask
vs. output init.
For DDI/DP/HDMI/SDVO I decided that we want to bail out for
an invalid port since those are the encoder types where
we might want consider driving the whole thing from the VBT
child device list, and
From: Ville Syrjälä
Instead of listing every platform's possible DDI outputs
in intel_setup_outputs() just loop over the new port_mask
to achieve the same thing.
HSW/BDW were left as is since they still look at the straps
as well.
DSI is still a mess. For now just check for the relevant
From: Ville Syrjälä
Now that we have encoder->devdata everwhere we don't need
the intel_bios_is_port_dp_dual_mode() wrapper any more.
And while at it let's include it in the child device log
dump as well since the logic in there is a bit more complex
than just DP&
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
We need to untangle the mess where some SKL machines (at least)
declare both DDI A and DDI E to be present in their VBT, and
both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
real DP->VGA converter.
Currently that is handled by checking the VBT child devices
for
From: Ville Syrjälä
HSW/BDW don't have DDI-F so don't go looking for one.
Seems to have been accidentally left behind when the
skl+ stuff got split out in commit 097d9e902068
("drm/i915/display: remove strap checks from gen 9").
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Currently we sanitize the child device aux_ch/ddc_pin while parsing
the ports from VBT. But that won't work when we have duplicate child
devices for the same port.
Instead let's sanitize just before initializing the encoder,
based on which resources were consumed by encoders
From: Ville Syrjälä
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the
device info. The other outputs (LVDS/TV/DSI/VGA) are left
out since for most of them we don't consider them as "ports".
DSI we should probably perhaps include somehow in the device
info. Just not sure how. Or we just
From: Ville Syrjälä
Sprinkle in some BUILD_BUG_ON()s to make sure some of
the bitmasks used in the device info have enough bits.
Do we have a better place for this sort of stuff?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 4
1 file changed, 4
From: Ville Syrjälä
The big switch+if statement mess in map_aux_ch() is
illegible. Split up into cleaner per-platform arrays
like we already have for the gmbus pins.
We use enum aux_ch as the index and the VBT thing as
the value. Slightly non-intuitive perhaps but if we
did it the other way
From: Ville Syrjälä
Swap the roles of the index vs. value for the VBT DDC pin
mapping tables. This is not strictly necessary for DDC pins
but it will make this work exactly like the AUX CH mapping
tables where the role reversal is necessary (or at least makes
things easier). Consistency is good.
From: Ville Syrjälä
Pair each _hotplug_enables() function with
a corresponding _hotplug_mask() function so that
we can determine right bits to clear on a per hpd_pin basis.
We'll need this for turning on HPD sense for a specific
encoder rather than just all of them.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Add a mechanism by which we can toggle the HPD sense for
individual encoders.
This will be used during eDP probing to figure out if
anything is actually connected. The normal intel_hpd_irq_setup()
thing doesn't work since we only do that after probing the
outputs, and we
From: Ville Syrjälä
The idea that ctg uses different HPD live state bits is
total nonsense, at least on my machine (Dell Latitude
E5400).
The only reason DP-B even works on my ctg is that DP-D
live state is stuck high, even though there is no physical
DP-D port. So when the detect checks DP-B
From: Ville Syrjälä
SKL doesn't have any north DE hotplug stuff. Currently we're
trying to read DDI A live state from the BDW north DE bit,
instead of the approproate south DE bit. Fix it.
And for good measure clear the pointer to the north hpd
pin array, so that we'll actually notice if some
From: Ville Syrjälä
We'll need dig_port->connected() to be there for a HPD live
state check during eDP connector probing. Reorder intel_ddi_init()
accordingly. g4x_dp_init() is already fine.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 40
From: Ville Syrjälä
I just wanted to init DDI ports in VBT child device order
without any up front assumptions about which conflicting
child device defition is valid. That is pretty much what
we need to do for the ADL laptops with the phantom eDP vs.
native HDMI on DDI B.
However that approach
From: Ville Syrjälä
Make HSW/BDW use the new VBT child device driven output
probing as well. To achieve that the strap checks are
moved into intel_ddi_init() itself.
I have one HSW ULT laptop here which declares all the ports
A-D in the VBT, so in order to avoid assert_port_valid() tripping
on
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.
TODO: DSI dual link handling is sketchy at best
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Instead of listing every platform's possible DDI outputs
in intel_setup_outputs() just loop over the new port_mask
to achieve the same thing.
HSW/BDW were left as is since they still look at the straps
as well.
DSI is still a mess. For now just check for the relevant
From: Ville Syrjälä
The SDVO code already warns when the port in question doesn't
actually support SDVO. Let's make that also bail the encoder
registration like the generic assert_port_valid() we added.
And add a similar thing for g4x HDMI, mainly because on g4x
itsefl port D only supports DP
From: Ville Syrjälä
Sprinkle in some BUILD_BUG_ON()s to make sure some of
the bitmasks used in the device info have enough bits.
Do we have a better place for this sort of stuff?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 4
1 file changed, 4
From: Ville Syrjälä
Sprinkle some asserts to catch any mishaps in the port_mask
vs. output init.
For DDI/DP/HDMI/SDVO I decided that we want to bail out for
an invalid port since those are the encoder types where
we might want consider driving the whole thing from the VBT
child device list, and
From: Ville Syrjälä
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the
device info. The other outputs (LVDS/TV/DSI/VGA) are left
out since for most of them we don't consider them as "ports".
DSI we should probably perhaps include somehow in the device
info. Just not sure how. Or we just
From: Ville Syrjälä
HSW/BDW don't have DDI-F so don't go looking for one.
Seems to have been accidentally left behind when the
skl+ stuff got split out in commit 097d9e902068
("drm/i915/display: remove strap checks from gen 9").
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Now that we have encoder->devdata everwhere we don't need
the intel_bios_is_port_dp_dual_mode() wrapper any more.
And while at it let's include it in the child device log
dump as well since the logic in there is a bit more complex
than just DP&
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Swap the roles of the index vs. value for the VBT DDC pin
mapping tables. This is not strictly necessary for DDC pins
but it will make this work exactly like the AUX CH mapping
tables where the role reversal is necessary (or at least makes
things easier). Consistency is good.
From: Ville Syrjälä
The big switch+if statement mess in map_aux_ch() is
illegible. Split up into cleaner per-platform arrays
like we already have for the gmbus pins.
We use enum aux_ch as the index and the VBT thing as
the value. Slightly non-intuitive perhaps but if we
did it the other way
From: Ville Syrjälä
Currently we sanitize the child device aux_ch/ddc_pin while parsing
the ports from VBT. But that won't work when we have duplicate child
devices for the same port.
Instead let's sanitize just before initializing the encoder,
based on which resources were consumed by encoders
From: Ville Syrjälä
Add a mechanism by which we can toggle the HPD sense for
individual encoders.
This will be used during eDP probing to figure out if
anything is actually connected. The normal intel_hpd_irq_setup()
thing doesn't work since we only do that after probing the
outputs, and we
From: Ville Syrjälä
We need to untangle the mess where some SKL machines (at least)
declare both DDI A and DDI E to be present in their VBT, and
both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
real DP->VGA converter.
Currently that is handled by checking the VBT child devices
for
From: Ville Syrjälä
Pair each _hotplug_enables() function with
a corresponding _hotplug_mask() function so that
we can determine right bits to clear on a per hpd_pin basis.
We'll need this for turning on HPD sense for a specific
encoder rather than just all of them.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
The idea that ctg uses different HPD live state bits is
total nonsense, at least on my machine (Dell Latitude
E5400).
The only reason DP-B even works on my ctg is that DP-D
live state is stuck high, even though there is no physical
DP-D port. So when the detect checks DP-B
From: Ville Syrjälä
SKL doesn't have any north DE hotplug stuff. Currently we're
trying to read DDI A live state from the BDW north DE bit,
instead of the approproate south DE bit. Fix it.
And for good measure clear the pointer to the north hpd
pin array, so that we'll actually notice if some
From: Ville Syrjälä
We'll need dig_port->connected() to be there for a HPD live
state check during eDP connector probing. Reorder intel_ddi_init()
accordingly. g4x_dp_init() is already fine.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 40
From: Ville Syrjälä
I just wanted to init DDI ports in VBT child device order
without any up front assumptions about which conflicting
child device defition is valid. That is pretty much what
we need to do for the ADL laptops with the phantom eDP vs.
native HDMI on DDI B.
However that approach
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.
TODO: DSI dual link handling is sketchy at best
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Make HSW/BDW use the new VBT child device driven output
probing as well. To achieve that the strap checks are
moved into intel_ddi_init() itself.
I have one HSW ULT laptop here which declares all the ports
A-D in the VBT, so in order to avoid assert_port_valid() tripping
on
From: Ville Syrjälä
Instead of listing every platform's possible DDI outputs
in intel_setup_outputs() just loop over the new port_mask
to achieve the same thing.
HSW/BDW were left as is since they still look at the straps
as well.
DSI is still a mess. For now just check for the relevant
From: Ville Syrjälä
The SDVO code already warns when the port in question doesn't
actually support SDVO. Let's make that also bail the encoder
registration like the generic assert_port_valid() we added.
And add a similar thing for g4x HDMI, mainly because on g4x
itsefl port D only supports DP
From: Ville Syrjälä
Sprinkle some asserts to catch any mishaps in the port_mask
vs. output init.
For DDI/DP/HDMI/SDVO I decided that we want to bail out for
an invalid port since those are the encoder types where
we might want consider driving the whole thing from the VBT
child device list, and
From: Ville Syrjälä
Sprinkle in some BUILD_BUG_ON()s to make sure some of
the bitmasks used in the device info have enough bits.
Do we have a better place for this sort of stuff?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 4
1 file changed, 4
From: Ville Syrjälä
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the
device info. The other outputs (LVDS/TV/DSI/VGA) are left
out since for most of them we don't consider them as "ports".
DSI we should probably perhaps include somehow in the device
info. Just not sure how. Or we just
From: Ville Syrjälä
HSW/BDW don't have DDI-F so don't go looking for one.
Seems to have been accidentally left behind when the
skl+ stuff got split out in commit 097d9e902068
("drm/i915/display: remove strap checks from gen 9").
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Swap the roles of the index vs. value for the VBT DDC pin
mapping tables. This is not strictly necessary for DDC pins
but it will make this work exactly like the AUX CH mapping
tables where the role reversal is necessary (or at least makes
things easier). Consistency is good.
From: Ville Syrjälä
Now that we have encoder->devdata everwhere we don't need
the intel_bios_is_port_dp_dual_mode() wrapper any more.
And while at it let's include it in the child device log
dump as well since the logic in there is a bit more complex
than just DP&
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
The big switch+if statement mess in map_aux_ch() is
illegible. Split up into cleaner per-platform arrays
like we already have for the gmbus pins.
We use enum aux_ch as the index and the VBT thing as
the value. Slightly non-intuitive perhaps but if we
did it the other way
From: Ville Syrjälä
Currently we sanitize the child device aux_ch/ddc_pin while parsing
the ports from VBT. But that won't work when we have duplicate child
devices for the same port.
Instead let's sanitize just before initializing the encoder,
based on which resources were consumed by encoders
From: Ville Syrjälä
We need to untangle the mess where some SKL machines (at least)
declare both DDI A and DDI E to be present in their VBT, and
both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
real DP->VGA converter.
Currently that is handled by checking the VBT child devices
for
From: Ville Syrjälä
Add a mechanism by which we can toggle the HPD sense for
individual encoders.
This will be used during eDP probing to figure out if
anything is actually connected. The normal intel_hpd_irq_setup()
thing doesn't work since we only do that after probing the
outputs, and we
From: Ville Syrjälä
Pair each _hotplug_enables() function with
a corresponding _hotplug_mask() function so that
we can determine right bits to clear on a per hpd_pin basis.
We'll need this for turning on HPD sense for a specific
encoder rather than just all of them.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
The idea that ctg uses different HPD live state bits is
total nonsense, at least on my machine (Dell Latitude
E5400).
The only reason DP-B even works on my ctg is that DP-D
live state is stuck high, even though there is no physical
DP-D port. So when the detect checks DP-B
From: Ville Syrjälä
We'll need dig_port->connected() to be there for a HPD live
state check during eDP connector probing. Reorder intel_ddi_init()
accordingly. g4x_dp_init() is already fine.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 40
From: Ville Syrjälä
I just wanted to init DDI ports in VBT child device order
without any up front assumptions about which conflicting
child device defition is valid. That is pretty much what
we need to do for the ADL laptops with the phantom eDP vs.
native HDMI on DDI B.
However that approach
From: Ville Syrjälä
Grab the HDR DPCD refresh timeout (time we need to wait after
writing the sourc OUI before the HDR DPCD registers are ready)
from the VBT.
Windows doesn't even seem to have any default value for this,
which is perhaps a bit weird since the VBT value is documented
as TGL+ and
From: Ville Syrjälä
intel_dp_has_audio() has no need for the crtc_state, so don't
pass it in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
From: Ville Syrjälä
I forgot to call intel_audio_compute_config() on DP MST, which
means ELD doesn't get populated and passed to the audio driver.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8097
Fixes: 5d986635e296 ("drm/i915/audio: Precompute the ELD")
Signed-off-by: Ville
From: Ville Syrjälä
The big switch+if statement mess in map_aux_ch() is
illegible. Split up into cleaner per-platform arrays
like we already have for the gmbus pins.
To save space in the arrays we shift away the lower nibble
of the VBT AUX CH byte since it's always zero anyway.
Extra care must
From: Ville Syrjälä
SKL/derivatives have DDI E but no AUX E, so we need to pick
another aux ch as the platform default. DDI E is more or less
the other half of DDI A, so we pick AUX A.
In all other cases we should have a corresponding aux ch for
each DDI.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Use encoer->name rather than port_name() in the debug messages
so that they actually make more sense.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 10 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 ++
2 files changed,
From: Ville Syrjälä
Restructure intel_bios_port_aux_ch() to resemble the ddc_pin
counterpart, where the intel_bios.c stuff only deals with the
child device definition, and the platform default will come from
elsewhere.
This requires the introduction if AUX_CH_NONE as the value 0
is already
From: Ville Syrjälä
Switch a lot of the intel_bios_foo() stuff to just accept the
devdata (VBT child device info) directly, instead of taking
detours via vbt.ports[].
Also unify the function naming scheme.
v2: Drop the redundant "encoder" from the dp/hdmi specific functions
Signed-off-by:
From: Ville Syrjälä
Most of the .fb_create() failure paths are annotated but there
are a few that seem capable of failing silently (well, higher
level code should print something, just not anything actually
useful). Drop a few more hints into the log to aid in debugging.
Signed-off-by: Ville
From: Ville Syrjälä
We are failing to free the already allocated DPT if the final
drm_framebuffer_init() fails. That would require idr_alloc() to
fail, so not very likely, but let's add the cleanup code anyway.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 5 -
From: Ville Syrjälä
Do the ELD hexdumps only up to the last differing byte.
The rest is typically all zeroes anyway so not much point
in dumping it.
Couldn't find anything for memcmp_diff_len() so
rolled my own.
v2: Use semantics and function name suggested by Jani
Cc: Jani Nikula
From: Ville Syrjälä
With multi panel machines becoming more prominent it's also
important to know which connector's backlight we're talking
about. Include that information in all the backlight debug/error
messages.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_backlight.c
From: Ville Syrjälä
It's confusing to debug backlight issues when one can't
easily even tell what kind of backlight control was
selected. Sprinkle uniform debug messages to all the
backlight setup functions.
Also the one that was already there (ext_pwm) was
using drm_info() for some reason. I
From: Ville Syrjälä
Do the ELD hexdumps only up to the last differing byte.
The rest is typically all zeroes anyway so not much point
in dumping it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 23
1 file changed, 23 insertions(+)
diff
From: Ville Syrjälä
Currently we sanitize the child device aux_ch/ddc_pin while parsing
the ports from VBT. But that won't work when we have duplicate child
devices for the same port.
Instead let's sanitize just before initializing the encoder,
based on which resources were consumed by encoders
From: Ville Syrjälä
Try to deal with duplicate child devices for the same DDI port
by attempting to initialize each in turn. The first on to succeed
will be the one we use.
TODO: Still very rough. Should probably just initialize DDIs
strictly in child device order, and just filter out the
From: Ville Syrjälä
Switch a lot of the intel_bios_foo() stuff to just accept the
devdata (VBT child device info) directly, instead of taking
detours via vbt.ports[].
Also unify the function naming scheme.
TODO: is intel_bios_encoder_{dp,hdmi}_ too much? Or should we
shorten to just
From: Ville Syrjälä
We defined the bitmasks for DVSTILEOFF but never used them.
Remedy that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sprite.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
From: Ville Syrjälä
Hiding a function call with side effects inside the
variable declaration block is a bit rude. Make it
stand out more.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_backlight.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
It's confusing to debug backlight issues when one can't
easily even tell what kind of backlight control was
selected. Sprinkle uniform debug messages to all the
backlight setup functions.
Also the one that was already there (ext_pwm) was
using drm_info() for some reason. I
From: Ville Syrjälä
Currently we are always switching to the idle pattern after the
link training, but we don't always wait for the minimum number
of idle patterns sent. That doesn't look to be what Bspec
asks of us.
According to bspec what we should do is switch to idle pattern
and wait for it
From: Ville Syrjälä
Bspec calls us to select pattern 2 after link training for
DP 2.0. Let's do that... by doing nothing because we will
be transmitting pattern 2 at the end of the link training
already.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c |
From: Ville Syrjälä
AFAICS Bspec has never asked us to switch to TPS1 when *disabling*
DP_TP_CTL. Let's stop doing that in case it confuses something.
We do have to switch before we *enable* DP_TP_CTL, but that
is already being handled correctly.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Instead of consulting vbt.ports[] lets just go through the
whole child device list to check whether a specific port
was declared by the VBT or not.
Note that this doesn't change anything wrt. detecting duplicate
child devices with the same port as vbt.ports[] would also
From: Ville Syrjälä
We just wrote the EDP transcoder's VTOTAL register a few lines
earlier, so instead of reading it back out again let's just
generate the same value for the transocder B/C register.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
1
From: Ville Syrjälä
The DSI code has some local hacks to program TRANS_H/VBLANK on
TGL+ (ICL DSI transcoders didn't have these registers). That
will not work when we need to start using the delayed vblank
(for DSB purposes). Too lazy to figure out what the is going
on there, so just sprinkle
From: Ville Syrjälä
On TGL VBLANK.VBLANK_START was the mechanism by which we can
delay the pipe's internal vblank in relation to the transcoder's
vblank. On ADL+ that no longer does anything. Instead we must
now use the new TRANS_SET_CONTEXT_LATENCY register. Program it
accordingly.
And since
From: Ville Syrjälä
Define the contents of the transcoder timing registers using
REG_GENMASK() & co. For ease of maintenance let's just define
the bitmasks with the full 16bit width (also used by the
current hand rolled stuff) even though not all bits are actually
used. None of the unsued bits
From: Ville Syrjälä
Clean up the eyesore in intel_get_transcoder_timings() a
bit by adding a local 'adjusted_mode' variable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 35 +---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git
From: Ville Syrjälä
The PSR code has no business mucking around with the
vblank delay. Currently nothing that depends on knowing
the exact vblank start scanline (eg. vblank evasion)
is aware of this and so will not work correctly.
The w/a seems to be for pre-production hw only, so let's
just
From: Ville Syrjälä
On TGL+ the normal "start of vblank" interrupt is the pipe's
(potentially delayed) version. Add the new bit for the
transcoder's "unmodified" vblank so I don't have to dig it
out from bspec every time.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
From: Ville Syrjälä
With the delayed vblank we need to start knowing where
the blanking periods start. So let's start dumping
out also the blanking start/end timings.
And while at it let's try to make that huge list of
numbers somewhat legible by indicating what each value
means. Also drop the
From: Ville Syrjälä
Rename PIPECONF to TRANSCONF to make it clear what it actually
applies to.
While the usual convention is to pick the earliers name I think
in this case it's more clear to use the later name. Especially
as even the register offset is in the wrong range (0x7 vs.
0x6)
From: Ville Syrjälä
Name the CPU transcoder timing registers TRANS_FOO rather than
just FOO. This is the modern name, after the pipe/transcoder split
happened. Makes it a bit more obvious whether you pass in a pipe or
a transcoder.
PIPESRC is a bit special as it's a pipe register, even though
1101 - 1200 of 9009 matches
Mail list logo
