From: Ville Syrjälä
The fact that the DispID starts at byte offset 1 is due to
the DispID coming from and EDID extension block (the first byte
being the extesion block tag). Instead of hadrdocoding that idx==1
assumptions all over let's just have drm_find_displayid_extension()
return it since it
From: Ville Syrjälä
I was playing around with the tile stuff a bit and noticed a bunch of
issues in the DisplayID parser. This series aims to fix what I found.
Ville Syrjälä (9):
drm: Constify topology id
drm/edid: Swap some operands in for_each_displayid_db()
drm/edid: Remove idx==1
From: Ville Syrjälä
As with the byte offset (idx) drm_find_displayid_extension() is
the only one who actually knows how much data the resulting DispID
block can contain. So return the length from therein instead of
assuming it's the EDID block length all over.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Throw out the magic '5' from validate_displayid() and replace with
the actual thing we mean sizeof(header)+checksum. Also rewrite the
checksum loop to be less hard to parse for mere mortals.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 13 -
1
From: Ville Syrjälä
Currently the code assumes that the entire EDID extesion block
can be taken up by the DispID blocks. That is not true. There
is at least always the DispID checksum, and potentially fill
bytes if the extension block uses the interior fill scheme
to pad out to fill EDID block
From: Ville Syrjälä
The listed dotclocks are two orders of mangnitude out.
Fix them.
v2: Just divide everything by 100 (Linus)
Cc: Linus Walleij
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 +++---
1 file changed, 7
From: Ville Syrjälä
The dotclock is three orders of magnitude out. Fix it.
v2: Just set it to 20MHz (Linus)
Cc: Linus Walleij
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Gustaf Lindström
Cc: Peter Rosin
Cc: Thierry Reding
Signed-off-by:
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Bhuvanchandra DV
Cc: Rob Herring
Cc: Thierry Reding
Signed-off-by:
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Fabio Estevam
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Ville
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Adam Ford
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: H. Nikolaus Schaller
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Eugen Hristev
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Riccardo Bortolato
Cc: Boris Brezillon
Cc: Thierry Reding
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Alexandre Courbot
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Maxime Ripard
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Eric Anholt
Cc: Rob Herring
Cc: Thierry Reding
Signed-off-by: Ville
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Vladimir Zapolskiy
Cc: Rob Herring
Cc: Thierry Reding
Signed-off-by:
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Josh Wu
Cc: Alexandre Belloni
Cc: Thierry Reding
Signed-off-by: Ville
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Jonathan Marek
Cc: Brian Masney
Cc: Linus Walleij
Signed-off-by: Ville
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Thierry Reding
Signed-off-by:
From: Ville Syrjälä
The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Linus Walleij
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Christoph Fritz
Cc: Stefan Riedmueller
Cc: Rob Herring
Cc: Thierry
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Philipp Zabel
Cc: Lucas Stach
Cc: Thierry Reding
Signed-off-by: Ville
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Paul Kocialkowski
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Heiko Stuebner
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Andreas Pretzsch
Cc: Marco Felsch
Cc: Thierry Reding
Signed-off-by:
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Giulio Benetti
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Linus Walleij
Cc: Eric Anholt
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Icenowy Zheng
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Linus Walleij
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Giulio Benetti
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Boris Brezillon
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Maxime Ripard
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Alex Gonzalez
Cc: Rob Herring
Cc: Thierry Reding
Signed-off-by: Ville
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Randy Li
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Heiko Schocher
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
A lot of the panel drivers put bogus looking values into
mode.clock. This series replaces the bogus values with
mode.vrefresh*mode.htotal*mode.vtotal.
Now, that may not be the right choice in all cases. There
are quite a few cases where the error looks very minor and
it may
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Marian-Cristian Rotariu
Cc: Lad Prabhakar
Cc: Sam Ravnborg
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Linus Walleij
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
gma500 needs 4 bits (to store a pixel multiplier) in the
mode->private_flags, i915 currently has three bits defined.
No one else uses this. Reduce the size to u8.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ville Syrjälä
Remove the pointless whole-function indentation. Also don't
need to worry about negative values anymore since we switched
everything to u16.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 26 --
1 file changed, 12 insertions(+), 14
From: Ville Syrjälä
Instead of supporting ~2000km wide displayes let's limit ourselves
to ~65m. That seems plenty big enough to me.
Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
10*0xfff which fits into the 16 bits.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h |
From: Ville Syrjälä
The mode flags are direclty exposed in the uapi as u32. Use the
same size type to store them internally.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h
From: Ville Syrjälä
Reorganize drm_display_mode to eliminate all the holes.
We'll put all the actual timings to the start of the
struct and all the extra junk to the end.
Gets the size down to 136 bytes on 64bit and 120 bytes on
32bit. With a bit more work we should be able to get this
below
From: Ville Syrjälä
We only have 7 bits defined for mode->type. Shrink the storage to u8.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index
From: Ville Syrjälä
The driver never sets mode->private_flags so copying
it back and forth is entirely pointless. Stop doing it.
Also drop private_flags from the tracepoint.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville
From: Ville Syrjälä
Store the timings (apart from the clock) as u16. The uapi mode
struct already uses u16 for everything so using something bigger
internally doesn't really help us.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 7 --
include/drm/drm_modes.h | 46
From: Ville Syrjälä
htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Ville Syrjälä
Let's just calculate the hsync rate on demand. No point in wasting
space storing it and risking the cached value getting out of sync
with reality.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 14 ++
From: Ville Syrjälä
The drrs code dereferences mode->vrefresh via some really long chain
of structures/pointers. Couldn't get coccinelle to see through all
that so let's add some local variables to help it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 18
From: Ville Syrjälä
struct drm_display_mode is extremely fat. Put it on diet.
Some stats for the whole series:
64bit sizeof(struct drm_display_mode):
200 -> 136 bytes (-32%)
64bit bloat-o-meter -c drm.ko:
add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
Function
From: Ville Syrjälä
Let's simplify life of driver by allowing them to leave
encoder->possible_crtcs unset if they have no restrictions
in crtc<->encoder linkage. We'll just populate possible_crtcs
with the full crtc mask when registering the encoder so that
userspace doesn't have to deal with
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
v2: Move to drm_mode_config_validate() (Daniel)
Make the docs say we WARN when this is wrong (Daniel)
Extract full_crtc_mask()
Cc: Thomas Zimmermann
Cc: Daniel Vetter
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about
From: Ville Syrjälä
Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Acked-by: Thomas Zimmermann
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
1 file changed, 2
From: Ville Syrjälä
Another respin of the possible_clones/crtcs fixing.
Changes based on v2 review:
- introduce drm_mode_config_validate()
- WARN for possible_clones!=0 when the encoder
itself isn't in the mask
- update the documentation to match the code
Other changes:
- sligth refactoring
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
From: Ville Syrjälä
It's not at all clear what cloning options this driver supports.
So let's just clear possible_clones instead of setting it to some
bogus value.
v2: Adjust the FIXME (Daniel)
Cc: Philipp Zabel
Acked-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about
From: Ville Syrjälä
Remainder of my possible_clones/crtcs cleanup. All the i915 bits and a
few other driver bits got merged already.
Ville Syrjälä (6):
drm: Include the encoder itself in possible_clones
drm/gma500: Sanitize possible_clones
drm/exynos: Use drm_encoder_mask()
drm/imx:
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
TODO: Or should we perhapst just filter out any bit for a
non-exisiting crtc?
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
It's not at all clear what cloning options this driver supports.
So let's just clear possible_clones instead of setting it to some
bogus value.
Cc: Philipp Zabel
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Ville Syrjälä
Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
From: Ville Syrjälä
Account for the TMDS clock limits declared by the DFP/DP++ dongle
when determining what color depth we're going to use.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 67 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 50
From: Ville Syrjälä
Stash the downstream facing port max bpc away during
intel_dp_set_edid(). We'll soon need the EDID in there so
we can't figure this out so easily during .compute_config() anymore.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 5 +
From: Ville Syrjälä
w/a #1139 is only needed for pre-production GLK. Nuke it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
From: Ville Syrjälä
DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
based on the capabilities of the sink.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
From: Ville Syrjälä
Add helpers to determine whether the DFP supports
YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 44 +
include/drm/drm_dp_helper.h | 8 ++
2 files
From: Ville Syrjälä
The downstream facing port caps in the DPCD can give us a hint
as to what kind of display mode the sink can use if it doesn't
have an EDID. Use that information to pick a suitable mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 54
From: Ville Syrjälä
Decouple the DP dual mode adaptor stuff from the HDMI code so that
we can try to use it for DP branch downstream facing HDMI ports as
well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 +-
.../drm/i915/display/intel_display_types.h
From: Ville Syrjälä
Use drm_dp_downstream_mode() to get a suitable mode for downstream
facing ports which don't have an EDID.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
To save a bit of power let's try to power down the TMDS buffers on
DP++ dongles hooked to downstream facing DP++ ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
drivers/gpu/drm/i915/display/intel_dp.c | 25
From: Ville Syrjälä
For platforms that can't do native 4:2:0 outout we may still be
able to do it by getting the DP->HDMI protocol converter to
perform the 4:4:4->4:2:0 downsamling for us. In this case we
have to configure our hardware to output YCbCr 4:4:4, which we've
already hooked up so all
From: Ville Syrjälä
Pull the "do we want to enable audio?" computation into a small helper
to make intel_hdmi_compute_config() less messy. Will make it easier to
add more checks for this later (eg. we should actually be checking
at the hblank is long enough for audio transmission).
From: Ville Syrjälä
In order to get accurate TMDS clocks limits for the DP++ ports we
can try to probe the DP dual mode adapter registers. Unfortunately
I've not yet seen a DP->DP++ branch device that would actually
forward these i2c accesses to the dual mode dongle downstream.
But we don't lose
From: Ville Syrjälä
Add helpers to get the TMDS clock limits for HDMI/DVI downstream
facing ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 116
include/drm/drm_dp_helper.h | 6 ++
2 files changed, 122 insertions(+)
diff --git
From: Ville Syrjälä
Move the downstream facing port dotclock check into a new function
(intel_dp_mode_valid_downstream()) so that we have a nice future
place where we can collect other related checks.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 1 +
From: Ville Syrjälä
Use the new helpers to extract the TMDS clock limits from
the downstream facing port and check them in .mode_valid().
TODO: we should check these in .compute_config() too to eg.
determine if we can do deep color on the HDMI side or not
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Deal with more cases in drm_dp_downstream_max_bpc():
- DPCD 1.0 -> assume 8bpc for non-DP
- DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
- DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap
- anything else -> assume 8bpc
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Add a few helpers to let us better identify which kind of DFP
we're dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 60 +
include/drm/drm_dp_helper.h | 5 +++
2 files changed, 65 insertions(+)
diff
From: Ville Syrjälä
It helps when the logs have a dump of the DFP capabilities.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
From: Ville Syrjälä
Non-HDMI sinks shouldn't be sent infoframes. Check for that when
using LSPCON.
FIXME: How do we turn off infoframes once enabled? Do we even
have to?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 --
From: Ville Syrjälä
DP 1.3 and 1.4 introduced some new registers for DP->HDMI protocol
converters. Define those.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_dp_helper.h
From: Ville Syrjälä
Our definitions for the DPCD DFP capabilities are lacking.
Add the missing bits.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h
From: Ville Syrjälä
We want to differentiate between the DFP dotclock and TMDS clock
limits. Let's convert the current thing to just give us the
dotclock limit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 42 ++---
From: Ville Syrjälä
To make it easier to figure out what caused a particular debug
message let's print out aux->name.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 44 +++--
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git
From: Ville Syrjälä
Attempt to deal with DP downstream facing ports (DFP) more
thoroughly. This involves reading more of the port caps
and dealing with various clock/bpc limitations.
Also we try to hook up the DP dual mode dongles into the
mix (unfortunately I've not yet seen a DP++ DFP that
From: Ville Syrjälä
WaDDIIOTimeout is only for A1 (pre-prod) glk steppings. Nuke it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index
From: Ville Syrjälä
TGL+ supposedly do not need Wa_1405510057 so limit it to
gen11 only.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
From: Ville Syrjälä
Detect GLK pre-production steppings. Not 100% of A2 being pre-prod
since the spec is a bit of a mess but feels more or less correct.
Suggested-by: Chris Wilson
Acked-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
From: Ville Syrjälä
I don't understand what the DispID CEA data block revision
means. The spec doesn't say. I guess some DispID must have
a value of >= 3 in there or else we generally wouldn't
even parse the CEA data blocks. Or does all this code
actually not do anything?
Cc: Andres Rodriguez
From: Ville Syrjälä
Let's introduce is_detailed_timing_descritor() as the opposite
counterpart of is_display_descriptor().
Cc: Allen Chen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 42 ++
1 file changed, 24 insertions(+), 18 deletions(-)
From: Ville Syrjälä
Nuke some whitespace that shouldn't be there.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d6bce58b27ac..3df5744026b0
From: Ville Syrjälä
CEA-861 says :
"d = offset for the byte following the reserved data block.
If no data is provided in the reserved data block, then d=4.
If no DTDs are provided, then d=0."
So let's not look for DTDs when d==0. In fact let's just make that
<4 since those values would just
From: Ville Syrjälä
After much head scratching I managed to convince myself that
for_each_displayid_db() has already done the bounds checks for
the DispID CEA data block. Which is why we don't need to repeat
them in cea_db_offsets(). To avoid having to go through that
pain again in the future
301 - 400 of 1423 matches
Mail list logo
