* [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
@ 2017-11-08 15:25 Ville Syrjala
2017-11-08 15:49 ` ✗ Fi.CI.BAT: failure for " Patchwork
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Ville Syrjala @ 2017-11-08 15:25 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx, stable, Jani Nikula, Eric Anholt, Neil Kownacki
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Apparently some sinks look at the YQ bits even when receiving RGB,
and they get somehow confused when they see a non-zero YQ value.
So we can't just blindly follow CEA-861-F and set YQ to match the
RGB range.
Unfortunately there is no good way to tell whether the sink
designer claims to have read CEA-861-F. The CEA extension block
revision number has generally been stuck at 3 since forever,
and even a very recently manufactured sink might be based on
an old design so the manufacturing date doesn't seem like
something we can use. In lieu of better information let's
follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
The alternative would of course be to always set YQ=0. And if
we ever encounter a HDMI 2.0+ sink with this bug that's what
we'll probably have to do.
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Neil Kownacki <njkkow@gmail.com>
Reported-by: Neil Kownacki <njkkow@gmail.com>
Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/drm_edid.c | 12 ++++++++++--
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
include/drm/drm_edid.h | 3 ++-
4 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 749d07a01772..8567890f47a7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4838,7 +4838,8 @@ void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode,
enum hdmi_quantization_range rgb_quant_range,
- bool rgb_quant_range_selectable)
+ bool rgb_quant_range_selectable,
+ bool is_hdmi2_sink)
{
/*
* CEA-861:
@@ -4862,8 +4863,15 @@ drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
* YQ-field to match the RGB Quantization Range being transmitted
* (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
* set YQ=1) and the Sink shall ignore the YQ-field."
+ *
+ * Unfortunate certain sinks (eg. VIZ Model 67/E261VA) get confused
+ * by non-zero YQ when receiving RGB. There doesn't seem to be any
+ * good way to tell which version of CEA-861 the sink supports, so
+ * we limit non-zero YQ to HDMI 2.0 sinks only as HDMI 2.0 is based
+ * on on CEA-861-F.
*/
- if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
+ if (!is_hdmi2_sink ||
+ rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
frame->ycc_quantization_range =
HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
else
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index fa1c793a21ef..2b23d3662eec 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -487,7 +487,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
crtc_state->limited_color_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL,
- intel_hdmi->rgb_quant_range_selectable);
+ intel_hdmi->rgb_quant_range_selectable,
+ is_hdmi2_sink);
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, &frame);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9a9a6b4acccf..d645df0c6d15 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -423,7 +423,8 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
vc4_encoder->limited_rgb_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL,
- vc4_encoder->rgb_range_selectable);
+ vc4_encoder->rgb_range_selectable,
+ false);
vc4_hdmi_write_infoframe(encoder, &frame);
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 9e4e23524840..58ffb68efdc5 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -361,7 +361,8 @@ void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode,
enum hdmi_quantization_range rgb_quant_range,
- bool rgb_quant_range_selectable);
+ bool rgb_quant_range_selectable,
+ bool is_hdmi2_sink);
/**
* drm_eld_mnl - Get ELD monitor name length in bytes.
--
2.13.6
^ permalink raw reply related [flat|nested] 11+ messages in thread
* ✗ Fi.CI.BAT: failure for drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-08 15:25 [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks Ville Syrjala
@ 2017-11-08 15:49 ` Patchwork
2017-11-08 19:42 ` ✓ Fi.CI.BAT: success " Patchwork
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2017-11-08 15:49 UTC (permalink / raw)
To: Ville Syrjala; +Cc: intel-gfx
== Series Details ==
Series: drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
URL : https://patchwork.freedesktop.org/series/33432/
State : failure
== Summary ==
Series 33432v1 drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
https://patchwork.freedesktop.org/api/1.0/series/33432/revisions/1/mbox/
Test chamelium:
Subgroup dp-crc-fast:
fail -> PASS (fi-kbl-7500u) fdo#102514
Test gem_exec_basic:
Subgroup basic-bsd2:
skip -> INCOMPLETE (fi-byt-j1900)
fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:445s
fi-bdw-gvtdvm total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:451s
fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:381s
fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:539s
fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:273s
fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:508s
fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:507s
fi-byt-j1900 total:36 pass:25 dwarn:0 dfail:0 fail:0 skip:10
fi-byt-n2820 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:491s
fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:429s
fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:262s
fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:536s
fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:427s
fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:440s
fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:471s
fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:458s
fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:485s
fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:472s
fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:537s
fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:578s
fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:452s
fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:546s
fi-skl-6700hq total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:569s
fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:518s
fi-skl-6770hq total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:495s
fi-skl-gvtdvm total:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:460s
fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:554s
fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:424s
Blacklisted hosts:
fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:570s
fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:489s
748f2c6b4046b23a623b4af3799563ef3110bb0d drm-tip: 2017y-11m-08d-07h-50m-13s UTC integration manifest
1202d8863878 drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7014/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* ✓ Fi.CI.BAT: success for drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-08 15:25 [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks Ville Syrjala
2017-11-08 15:49 ` ✗ Fi.CI.BAT: failure for " Patchwork
@ 2017-11-08 19:42 ` Patchwork
2017-11-08 20:17 ` [PATCH] " Eric Anholt
2017-11-08 21:19 ` ✓ Fi.CI.IGT: success for " Patchwork
3 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2017-11-08 19:42 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
== Series Details ==
Series: drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
URL : https://patchwork.freedesktop.org/series/33432/
State : success
== Summary ==
Series 33432v1 drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
https://patchwork.freedesktop.org/api/1.0/series/33432/revisions/1/mbox/
Test chamelium:
Subgroup dp-crc-fast:
pass -> FAIL (fi-kbl-7500u) fdo#102514
fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:447s
fi-bdw-gvtdvm total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:451s
fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:377s
fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:544s
fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:273s
fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:502s
fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:503s
fi-byt-j1900 total:289 pass:254 dwarn:0 dfail:0 fail:0 skip:35 time:499s
fi-byt-n2820 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:488s
fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:430s
fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:549s
fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:430s
fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:445s
fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:428s
fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:472s
fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:461s
fi-kbl-7500u total:289 pass:263 dwarn:1 dfail:0 fail:1 skip:24 time:480s
fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:531s
fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:476s
fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:535s
fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:573s
fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:448s
fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:542s
fi-skl-6700hq total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:561s
fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:518s
fi-skl-6770hq total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:499s
fi-skl-gvtdvm total:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:456s
fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:556s
fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:421s
Blacklisted hosts:
fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:563s
fi-gdg-551 failed to connect after reboot
087c404bd6d56a52e0656ac7c79faa376c25b796 drm-tip: 2017y-11m-08d-15h-44m-06s UTC integration manifest
72043e77385e drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7018/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-08 15:25 [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks Ville Syrjala
2017-11-08 15:49 ` ✗ Fi.CI.BAT: failure for " Patchwork
2017-11-08 19:42 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2017-11-08 20:17 ` Eric Anholt
2017-11-08 20:45 ` Ville Syrjälä
2017-11-08 21:19 ` ✓ Fi.CI.IGT: success for " Patchwork
3 siblings, 1 reply; 11+ messages in thread
From: Eric Anholt @ 2017-11-08 20:17 UTC (permalink / raw)
To: Ville Syrjala, dri-devel; +Cc: intel-gfx, stable, Jani Nikula, Neil Kownacki
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Apparently some sinks look at the YQ bits even when receiving RGB,
> and they get somehow confused when they see a non-zero YQ value.
> So we can't just blindly follow CEA-861-F and set YQ to match the
> RGB range.
>
> Unfortunately there is no good way to tell whether the sink
> designer claims to have read CEA-861-F. The CEA extension block
> revision number has generally been stuck at 3 since forever,
> and even a very recently manufactured sink might be based on
> an old design so the manufacturing date doesn't seem like
> something we can use. In lieu of better information let's
> follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
>
> The alternative would of course be to always set YQ=0. And if
> we ever encounter a HDMI 2.0+ sink with this bug that's what
> we'll probably have to do.
Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
source?
That said, as far as vc4, this patch is
Acked-by: Eric Anholt <eric@anholt.net>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-08 20:17 ` [PATCH] " Eric Anholt
@ 2017-11-08 20:45 ` Ville Syrjälä
2017-11-08 22:21 ` Eric Anholt
0 siblings, 1 reply; 11+ messages in thread
From: Ville Syrjälä @ 2017-11-08 20:45 UTC (permalink / raw)
To: Eric Anholt; +Cc: Jani Nikula, intel-gfx, Neil Kownacki, stable, dri-devel
On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
>
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Apparently some sinks look at the YQ bits even when receiving RGB,
> > and they get somehow confused when they see a non-zero YQ value.
> > So we can't just blindly follow CEA-861-F and set YQ to match the
> > RGB range.
> >
> > Unfortunately there is no good way to tell whether the sink
> > designer claims to have read CEA-861-F. The CEA extension block
> > revision number has generally been stuck at 3 since forever,
> > and even a very recently manufactured sink might be based on
> > an old design so the manufacturing date doesn't seem like
> > something we can use. In lieu of better information let's
> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> >
> > The alternative would of course be to always set YQ=0. And if
> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> > we'll probably have to do.
>
> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
> source?
As long as you stick to < 340 MHz modes you shouldn't have to do
anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
to bridges/encoders to filter out most things that aren't supported?
>
> That said, as far as vc4, this patch is
>
> Acked-by: Eric Anholt <eric@anholt.net>
Ta.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* ✓ Fi.CI.IGT: success for drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-08 15:25 [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks Ville Syrjala
` (2 preceding siblings ...)
2017-11-08 20:17 ` [PATCH] " Eric Anholt
@ 2017-11-08 21:19 ` Patchwork
3 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2017-11-08 21:19 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
== Series Details ==
Series: drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
URL : https://patchwork.freedesktop.org/series/33432/
State : success
== Summary ==
Test perf:
Subgroup blocking:
fail -> PASS (shard-hsw) fdo#102252 +1
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
pass -> DMESG-WARN (shard-hsw) fdo#103038
Subgroup extended-modeset-hang-newfb-with-reset-render-a:
dmesg-warn -> PASS (shard-hsw) fdo#102249
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
shard-hsw total:2540 pass:1432 dwarn:1 dfail:0 fail:10 skip:1097 time:9265s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7018/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-08 20:45 ` Ville Syrjälä
@ 2017-11-08 22:21 ` Eric Anholt
2017-11-09 8:26 ` Daniel Vetter
0 siblings, 1 reply; 11+ messages in thread
From: Eric Anholt @ 2017-11-08 22:21 UTC (permalink / raw)
To: Ville Syrjälä
Cc: dri-devel, intel-gfx, stable, Jani Nikula, Neil Kownacki
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]
Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
>> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
>>
>> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> >
>> > Apparently some sinks look at the YQ bits even when receiving RGB,
>> > and they get somehow confused when they see a non-zero YQ value.
>> > So we can't just blindly follow CEA-861-F and set YQ to match the
>> > RGB range.
>> >
>> > Unfortunately there is no good way to tell whether the sink
>> > designer claims to have read CEA-861-F. The CEA extension block
>> > revision number has generally been stuck at 3 since forever,
>> > and even a very recently manufactured sink might be based on
>> > an old design so the manufacturing date doesn't seem like
>> > something we can use. In lieu of better information let's
>> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
>> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
>> >
>> > The alternative would of course be to always set YQ=0. And if
>> > we ever encounter a HDMI 2.0+ sink with this bug that's what
>> > we'll probably have to do.
>>
>> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
>> source?
>
> As long as you stick to < 340 MHz modes you shouldn't have to do
> anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
>
> Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
> to bridges/encoders to filter out most things that aren't supported?
I had a patch for that at
https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
into trouble with 4k monitors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-08 22:21 ` Eric Anholt
@ 2017-11-09 8:26 ` Daniel Vetter
2017-11-09 18:16 ` Eric Anholt
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Vetter @ 2017-11-09 8:26 UTC (permalink / raw)
To: Eric Anholt
Cc: Ville Syrjälä, Jani Nikula, intel-gfx, Neil Kownacki,
stable, dri-devel
On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
>
> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> >> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> >>
> >> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >
> >> > Apparently some sinks look at the YQ bits even when receiving RGB,
> >> > and they get somehow confused when they see a non-zero YQ value.
> >> > So we can't just blindly follow CEA-861-F and set YQ to match the
> >> > RGB range.
> >> >
> >> > Unfortunately there is no good way to tell whether the sink
> >> > designer claims to have read CEA-861-F. The CEA extension block
> >> > revision number has generally been stuck at 3 since forever,
> >> > and even a very recently manufactured sink might be based on
> >> > an old design so the manufacturing date doesn't seem like
> >> > something we can use. In lieu of better information let's
> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> >> >
> >> > The alternative would of course be to always set YQ=0. And if
> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> >> > we'll probably have to do.
> >>
> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
> >> source?
> >
> > As long as you stick to < 340 MHz modes you shouldn't have to do
> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
> >
> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
> > to bridges/encoders to filter out most things that aren't supported?
>
> I had a patch for that at
> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
> into trouble with 4k monitors.
Ack on the clock limiting patch, silly that it's stuck. No idea about CEC,
better for Hans/Boris I guess.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-09 8:26 ` Daniel Vetter
@ 2017-11-09 18:16 ` Eric Anholt
2017-11-14 23:38 ` neil k
0 siblings, 1 reply; 11+ messages in thread
From: Eric Anholt @ 2017-11-09 18:16 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Neil Kownacki, Jani Nikula, intel-gfx, dri-devel, stable
[-- Attachment #1.1: Type: text/plain, Size: 2060 bytes --]
Daniel Vetter <daniel@ffwll.ch> writes:
> On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
>> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
>>
>> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
>> >> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
>> >>
>> >> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> >> >
>> >> > Apparently some sinks look at the YQ bits even when receiving RGB,
>> >> > and they get somehow confused when they see a non-zero YQ value.
>> >> > So we can't just blindly follow CEA-861-F and set YQ to match the
>> >> > RGB range.
>> >> >
>> >> > Unfortunately there is no good way to tell whether the sink
>> >> > designer claims to have read CEA-861-F. The CEA extension block
>> >> > revision number has generally been stuck at 3 since forever,
>> >> > and even a very recently manufactured sink might be based on
>> >> > an old design so the manufacturing date doesn't seem like
>> >> > something we can use. In lieu of better information let's
>> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
>> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
>> >> >
>> >> > The alternative would of course be to always set YQ=0. And if
>> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what
>> >> > we'll probably have to do.
>> >>
>> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
>> >> source?
>> >
>> > As long as you stick to < 340 MHz modes you shouldn't have to do
>> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
>> >
>> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
>> > to bridges/encoders to filter out most things that aren't supported?
>>
>> I had a patch for that at
>> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
>> into trouble with 4k monitors.
>
> Ack on the clock limiting patch, silly that it's stuck. No idea about CEC,
> better for Hans/Boris I guess.
Thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-09 18:16 ` Eric Anholt
@ 2017-11-14 23:38 ` neil k
2017-11-15 15:30 ` Ville Syrjälä
0 siblings, 1 reply; 11+ messages in thread
From: neil k @ 2017-11-14 23:38 UTC (permalink / raw)
To: Eric Anholt; +Cc: Jani Nikula, intel-gfx, stable, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 2335 bytes --]
I tested the patch from Ville Syrjälä's email and it works fine on top of
4.14 for me.
Thanks,
Neil
On Thu, Nov 9, 2017 at 1:16 PM, Eric Anholt <eric@anholt.net> wrote:
> Daniel Vetter <daniel@ffwll.ch> writes:
>
> > On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
> >> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> >>
> >> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> >> >> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> >> >>
> >> >> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >> >
> >> >> > Apparently some sinks look at the YQ bits even when receiving RGB,
> >> >> > and they get somehow confused when they see a non-zero YQ value.
> >> >> > So we can't just blindly follow CEA-861-F and set YQ to match the
> >> >> > RGB range.
> >> >> >
> >> >> > Unfortunately there is no good way to tell whether the sink
> >> >> > designer claims to have read CEA-861-F. The CEA extension block
> >> >> > revision number has generally been stuck at 3 since forever,
> >> >> > and even a very recently manufactured sink might be based on
> >> >> > an old design so the manufacturing date doesn't seem like
> >> >> > something we can use. In lieu of better information let's
> >> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> >> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> >> >> >
> >> >> > The alternative would of course be to always set YQ=0. And if
> >> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> >> >> > we'll probably have to do.
> >> >>
> >> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an
> HDMI1.4
> >> >> source?
> >> >
> >> > As long as you stick to < 340 MHz modes you shouldn't have to do
> >> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
> >> >
> >> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
> >> > to bridges/encoders to filter out most things that aren't supported?
> >>
> >> I had a patch for that at
> >> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
> >> into trouble with 4k monitors.
> >
> > Ack on the clock limiting patch, silly that it's stuck. No idea about
> CEC,
> > better for Hans/Boris I guess.
>
> Thanks!
>
[-- Attachment #1.2: Type: text/html, Size: 3630 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
2017-11-14 23:38 ` neil k
@ 2017-11-15 15:30 ` Ville Syrjälä
0 siblings, 0 replies; 11+ messages in thread
From: Ville Syrjälä @ 2017-11-15 15:30 UTC (permalink / raw)
To: neil k
Cc: Eric Anholt, Daniel Vetter, Jani Nikula, intel-gfx, stable,
dri-devel
On Tue, Nov 14, 2017 at 06:38:11PM -0500, neil k wrote:
> I tested the patch from Ville Syrjälä's email and it works fine on top of
> 4.14 for me.
Thanks for confirming.
Patch pushed to drm-misc-fixes.
>
> Thanks,
> Neil
>
> On Thu, Nov 9, 2017 at 1:16 PM, Eric Anholt <eric@anholt.net> wrote:
>
> > Daniel Vetter <daniel@ffwll.ch> writes:
> >
> > > On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
> > >> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> > >>
> > >> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> > >> >> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> > >> >>
> > >> >> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >> >> >
> > >> >> > Apparently some sinks look at the YQ bits even when receiving RGB,
> > >> >> > and they get somehow confused when they see a non-zero YQ value.
> > >> >> > So we can't just blindly follow CEA-861-F and set YQ to match the
> > >> >> > RGB range.
> > >> >> >
> > >> >> > Unfortunately there is no good way to tell whether the sink
> > >> >> > designer claims to have read CEA-861-F. The CEA extension block
> > >> >> > revision number has generally been stuck at 3 since forever,
> > >> >> > and even a very recently manufactured sink might be based on
> > >> >> > an old design so the manufacturing date doesn't seem like
> > >> >> > something we can use. In lieu of better information let's
> > >> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> > >> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> > >> >> >
> > >> >> > The alternative would of course be to always set YQ=0. And if
> > >> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> > >> >> > we'll probably have to do.
> > >> >>
> > >> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an
> > HDMI1.4
> > >> >> source?
> > >> >
> > >> > As long as you stick to < 340 MHz modes you shouldn't have to do
> > >> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
> > >> >
> > >> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
> > >> > to bridges/encoders to filter out most things that aren't supported?
> > >>
> > >> I had a patch for that at
> > >> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
> > >> into trouble with 4k monitors.
> > >
> > > Ack on the clock limiting patch, silly that it's stuck. No idea about
> > CEC,
> > > better for Hans/Boris I guess.
> >
> > Thanks!
> >
--
Ville Syrjälä
Intel OTC
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-11-15 15:30 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-08 15:25 [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks Ville Syrjala
2017-11-08 15:49 ` ✗ Fi.CI.BAT: failure for " Patchwork
2017-11-08 19:42 ` ✓ Fi.CI.BAT: success " Patchwork
2017-11-08 20:17 ` [PATCH] " Eric Anholt
2017-11-08 20:45 ` Ville Syrjälä
2017-11-08 22:21 ` Eric Anholt
2017-11-09 8:26 ` Daniel Vetter
2017-11-09 18:16 ` Eric Anholt
2017-11-14 23:38 ` neil k
2017-11-15 15:30 ` Ville Syrjälä
2017-11-08 21:19 ` ✓ Fi.CI.IGT: success for " Patchwork
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox