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()
From: Ville Syrjälä
Make sure dig_port->aux_ch is trustworthy by initializing it
to NONE (-1) at the start. The encoder init will later fill in
the actual value, if appropriate.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c| 2 ++
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ä
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.
Note that the old way of sanitizing gave priority to the last
port declared in the VBT, but now we sort of do the opposite by
favoring
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ä
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 | 69 --
From: Ville Syrjälä
Make sure dig_port->aux_ch is trustworthy by initializing it
to NONE (-1) 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 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).
Ville Syrjälä (5):
drm/i915: Initialize dig_port->aux_ch to
From: Ville Syrjälä
Make HSW/BDW use port_mask for output probing as well.
To achieve that the strap checks are moved into
intel_ddi_init() itself. Or should we move them to the
runtime port_mask init instead? Maybe not since the hardware
is still there, just not connected to anything.
v2:
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?
v2: Relocate to the new place
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
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").
Reviewed-by: Lucas De Marchi
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Introduce port_mask into the device info and utilize it
it initalize DDI ports instead of hand rolling each
intel_ddi_init() call per platform+port.
This is an intermediate step towards initializing
DDI/DP/HDMI/DSI ports purely based on VBT information.
v2: rebased due to
From: Ville Syrjälä
All known issues fixed now, so re-enable PSR1 on hsw/bdw.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
From: Ville Syrjälä
Can't see why we'd want the sprite blocking PSR entry.
Mask it out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4
drivers/gpu/drm/i915/display/intel_psr.c | 4
2 files changed, 8 insertions(+)
diff --git
From: Ville Syrjälä
WA 0479 says: "Do not skip both TP1 and TP2/TP3". Let's just
stick the minimum 100us TP2/3 time in there to avoid that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_psr.c | 9 +
1 file changed, 9 insertions(+)
diff --git
From: Ville Syrjälä
hsw/bdw lack the pipe register vs. display register distinction
in their PSR masking capabilities. So to keep our CURSURFLIVE
tricks working we need to just unmask all display register writes
on these platforms. The downside being that any display regitster
(eg. even SWF
From: Ville Syrjälä
Bspec asks us to unmask "vblank to registers" in the DPRS unit.
Note that I was unable to observe any change in hardware
behviour due to this bit on HSW. But let's do this anyway
in case it matters in some cases, and the corresponding bit
on BDW is abolutely critical as
From: Ville Syrjälä
Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware
generate the extra vblank between link training and first frame
being transmitted. This is the same thing that's controlled by
TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering
it's effectively
From: Ville Syrjälä
Add the PSR interrupt handling code back for HSW. Looks like
the removal was never completed anyway since the irq setup
code was lest untouched.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_irq.c | 14 ++
1 file changed, 14
From: Ville Syrjälä
Deal with HSW/BDW in transcoder_has_psr2().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
From: Ville Syrjälä
Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all
of it was even removed (BDW AUX data registers were left behind).
Update the code to use REG_BIT() & co. while at it.
v2: Define the SRD_AUX_CTL bits in terms of DP_AUX_CTL bits (Jouni)
Add a comment
From: Ville Syrjälä
Add back hsw'w special SRD/PSR1 registers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_psr.c | 20 +++
drivers/gpu/drm/i915/display/intel_psr_regs.h | 4
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git
From: Ville Syrjälä
In preparation for re-introducing HSW's different PSR1 register
offeets let's just wrap all the registers into functions.
Avoids having to make the register macros more complex.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_psr.c | 99
From: Ville Syrjälä
The multiplication got replaced by an addition in some cleanup.
This means we never write the correct data to some of the BDW
PSR data registers and thus we fail to actually wake up the
panel from PSR.
Fixes: 4ab4fa103217 ("drm/i915/psr: Make PSR registers relative to
From: Ville Syrjälä
Fix all the obvious issues affecting HSW/BDW PSR1 and
restore it back to life.
The PC8+ vs. init_clock_gating() problem also affects
some non-PSR workarounds as well.
v2: Rebase (due to irq code movement mostly)
Deal with review comments wrt. the AUX setup
Ville
From: Ville Syrjälä
PC8+ clobbers a bunch of displays registers which need to
be restored by hand or else we lost a bunch of workarounds.
The important ones for us are at least CHICKEN_PAR2* and
CHICKEN_PIPESL*.
Curiously at least some CHICKEN_PAR1* registers
are preserved by the
From: Ville Syrjälä
No idea why the DSI code is feeling the need to assert that
has_pch_encoder must not be set. PCH encoders aren't even a
thing on any platform that has DSI.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 2 --
From: Ville Syrjälä
Follow what Windows does and do the DSI panel reset+power off
after everything else.
v2: s/intel_dsi_msleep/msleep/
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 14 --
1 file changed, 8 insertions(+), 6
From: Ville Syrjälä
The encoder hooks already get passed the crtc state so just
grab the crtc from there instead of from the connector state.
This is generally what everyone else does, so no reason for
icl_dsi.c to be different.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
icl+ DSI isn't respecting the panel power_off_delay. Remedy that.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
From: Ville Syrjälä
Do the scaler disable in the spot where bspec has specfied it
for TGL+. And also move the DSC disable to match what
intel_ddi.c does.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 7 +++
1 file changed, 3
From: Ville Syrjälä
encoder->disable() is supposed to happen before the pipe/transcoder
gets disabled. The icl+ DSI code screwed that up and put most things
(including the transcoder disable itself) into encoder->disable().
Follow the common rules and hoist most things into the
From: Ville Syrjälä
Plug in the encoder->shutdown() hook for icl+ DSI so that
we are guaranteed to respect the power cycle delay during
reboots and whatnot.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 1 +
From: Ville Syrjälä
Handle the DSI panel power cycle delay on icl+.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 6 ++
drivers/gpu/drm/i915/display/intel_dsi.c | 13 +
drivers/gpu/drm/i915/display/intel_dsi.h | 1 +
From: Ville Syrjälä
The programming of the DPHY vs. DSI _TIMING registers are
two separate steps in the TGL+ bspec sequence, with some
other stuff in between. Implement the same split.
Windows also seems follow the bspec TGL+ sequence, even
on ICL/JSL.
Reviewed-by: Jani Nikula
Signed-off-by:
From: Ville Syrjälä
The clock gating step is in the wrong spot compared to the
TGL+ bspec sequence. Move it the right place. Windows also
seems to use the TGL+ order here always.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c | 5 ++---
1
From: Ville Syrjälä
Help out debugging things by printing out how long the VBT
delay sequence is supposed to wait.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
Doing the init OTP and display on DSI sequences back to back
doesn't really make any sense (a single sequence would suffice
then). Move the display on sequence to be done just before
backlight on, which is also what Windows does.
Reviewed-by: Jani Nikula
Signed-off-by:
From: Ville Syrjälä
Looks like we're trying to talk to the DSI panel even before turning
it on, on icl+. Bspec doesn't actually specify when these should be
done, but certainly we need to turn the panel on at least before
talking to it. So let's move the power on + reset deassert steps to
be the
From: Ville Syrjälä
Rebase of the ICL+ DSI modeset sequence stuff.
Ville Syrjälä (13):
drm/i915/dsi: Do panel power on + reset deassert earlier on icl+
drm/i915/dsi: Do display on sequence later on icl+
drm/i915/dsi: Print the VBT MIPI sequence delay duration
drm/i915/dsi: Split icl+
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.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
From: Ville Syrjälä
Normally we could be in a deep PkgC state all the way up to the
point when DSB starts its execution at the transcoders undelayed
vblank. The DSB will then have to wait for the hardware to
wake up before it can execute anything. This will waste a huge
chunk of the vblank time
From: Ville Syrjälä
Add a helper to convert our idea of a scanline to the hw's idea
of the same scanline (ie. apply crtc->scanline_offset in reverse).
We'll need this to tell the DSB do stuff on a specific scanline.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vblank.c
From: Ville Syrjälä
Loading LUTs with the DSB outside of vblank doesn't really
work due to the palette anti-collision logic. Apparently the
DSB register writes don't get stalled like CPU mmio writes
do and instead we end up corrupting the LUT entries. Disabling
the anti-collision logic would
From: Ville Syrjälä
The DSB code will want to know the maximum PkgC latency
it has to contend with. Add a helper to expose that
information.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_watermark.c | 14 ++
drivers/gpu/drm/i915/display/skl_watermark.h | 2 ++
From: Ville Syrjälä
We want to start the DSB execution from the transcoder's undelayed
vblank, so in order to guarantee atomicity with the all the other
mmio register writes we need to evade both vblanks.
Note that currently we don't add any vblank delay, so this is
effectively a nop. But in
From: Ville Syrjälä
The DSB has problems writing the legacy LUT. The two workarounds
I've discoverted are:
- write each entry twice back to back
- use non-posted writes
Let's use non-posted writes as that seems a bit more standard.
TODO: measure which is faster
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Using the DSB for LUT loading during full modesets would require
some actual though. Let's just use mmio for the time being.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 4
1 file changed, 4 insertions(+)
diff --git
From: Ville Syrjälä
Writing specific transcoder registers (and as it turns out, the
legacy LUT as well) via DSB needs a magic sequence to emit
non-posted register writes. Add a helper for this.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 20
From: Ville Syrjälä
Add a function for emitting masked register writes.
Note that the mask is implemented through bvyte enables,
so can only mask off aligned 8bit sets of bits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 18 ++
From: Ville Syrjälä
Add a helper for emitting a number of DSB NOOPs commands.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 9 +
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
2 files changed, 10 insertions(+)
diff --git
From: Ville Syrjälä
The indexed write instruction doesn't support byte-enables, so
if the non-indexed write used those we must not convert it to
an indexed write.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 12 +---
1 file changed, 9 insertions(+), 3
From: Ville Syrjälä
i915_gem_object_create_internal() does not hand out zeroed
memory. Thus we may confuse whatever stale garbage is in
there as a previous register write and mistakenly handle the
first actual register write as an indexed write. This can
end up corrupting the instruction
From: Ville Syrjälä
Add some defines to specify what goes inside certain DSB
instructions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
From: Ville Syrjälä
Dump the full DSB command buffers and head/tail pointers if the
the DSB hasn't completed its job in time.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 33 +---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Define all the DSB register bits so I don't have to look through
bspec to find them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb_regs.h | 31 +++
1 file changed, 31 insertions(+)
diff --git
From: Ville Syrjälä
Avoid the locking overhead for DSB registers. We don't need the locks
and intel_dsb_commit() in particular needs to be called from the
vblank evade critical section and thus needs to be fast.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 18
From: Ville Syrjälä
The LUT checker doesn't modify the LUT entries so make them const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
From: Ville Syrjälä
Another attempt at re-enabling DSB based LUT loads.
The main change from the last attempt is that we now
use the DSB's DEwake mechanism to combat PkgC latency
which was causing the LUT to not always load correctly
(due to the anti-collision logic not working correctly
for
From: Ville Syrjälä
Apparently desktop gen3 parts don't support the
10bit gamma mode at all. Stop claiming otherwise.
As is the case with pipe A on gen3 mobile parts, the
PIPECONF gamma mode bit can be set but it has no
effect on the output.
PNV seems to be the only slight exception, but
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ä
Make HSW/BDW use port_mask for output probing as well.
To achieve that the strap checks are moved into
intel_ddi_init() itself. Or should we move them to the
runtime port_mask init instead? Maybe not since the hardware
is still there, just not connected to anything.
v2:
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ä
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ä
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").
Reviewed-by: Lucas De Marchi
Signed-off-by: Ville Syrjälä
---
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ä
Introduce port_mask into the device info and utilize it
it initalize DDI ports instead of hand rolling each
intel_ddi_init() call per platform+port.
This is an intermediate step towards initializing
DDI/DP/HDMI/DSI ports purely based on VBT information.
v2: rebased due to
From: Ville Syrjälä
Make HSW/BDW use port_mask for output probing as well.
To achieve that the strap checks are moved into
intel_ddi_init() itself. Or should we move them to the
runtime port_mask init instead? Maybe not since the hardware
is still there, just not connected to anything.
v2:
From: Ville Syrjälä
Make HSW/BDW use port_mask for output probing as well.
To achieve that the strap checks are moved into
intel_ddi_init() itself. Or should we move them to the
runtime port_mask init instead? Maybe not since the hardware
is still there, just not connected to anything.
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ä
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ä
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ä
Introduce port_mask into the device info and utilize it
it initalize DDI ports instead of hand rolling each
intel_ddi_init() call per platform+port.
This is an intermediate step towards initializing
DDI/DP/HDMI/DSI ports purely based on VBT information.
Ville Syrjälä (7):
From: Ville Syrjälä
Modernize the DP AUX CH register definitions with REG_BIT() & co.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 35 +--
.../gpu/drm/i915/display/intel_dp_aux_regs.h | 62 ++-
drivers/gpu/drm/i915/gvt/edid.c
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ä
Track DP enhanced framing properly in the crtc state instead
of relying just on the cached DPCD everywhere, and hook it
up into the state check and dump.
v2: Actually set enhanced_framing in .compute_config()
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
We always check whether combo PHYs need to be re-initialized
after disabling DC states, which leads to log spam. Switch things
around so that we only log something when we actually have to
re-initialized a PHY.
The log spam was exacerbated by commit 41b4c7fe72b6 ("drm/i915:
From: Ville Syrjälä
There's no need to check for both eDP and fixed_mode when
deciding whether to do the pfit calculations or not.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Ville Syrjälä
encoder->get_config() is not the place where the state
should be dumped. Get rid of the spam.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
From: Ville Syrjälä
Split some overly long lines.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fdi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c
b/drivers/gpu/drm/i915/display/intel_fdi.c
index
From: Ville Syrjälä
Track DP enhanced framing properly in the crtc state instead
of relying just on the cached DPCD everywhere, and hook it
up into the state check and dump.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 10 --
From: Ville Syrjälä
Stop dumping state while reading it out. We have a proper
place for that stuff.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_crtc_state_dump.c| 2 ++
drivers/gpu/drm/i915/display/intel_ddi.c| 13 +++--
2 files changed, 5
801 - 900 of 9009 matches
Mail list logo
