From: "Ville Syrjälä" <ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
"Seung-Woo Kim"
<sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
"Russell King" <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
"Vincent Abriou" <vincent.abriou-qxv4g6HH51o@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Kyungmin Park"
<kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
"Tomi Valkeinen" <tomi.valkeinen-l0cyMroinI0@public.gmane.org>,
"Thierry Reding"
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Jani Nikula"
<jani.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Alex Deucher" <alexander.deucher-5C7GfCeVMHo@public.gmane.org>,
"Shawn Guo" <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Ben Skeggs" <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>,
"Laurent Pinchart"
<Laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Subject: Re: [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
Date: Tue, 4 Dec 2018 21:02:34 +0200 [thread overview]
Message-ID: <20181204190234.GL9144@intel.com> (raw)
In-Reply-To: <aee2cad8-ef93-72d5-986f-b33aabd2c3d2-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:48, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> >> Quite late, hopefully not too late.
> >>
> >>
> >> On 21.11.2018 12:51, Ville Syrjälä wrote:
> >>> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> >>>>> return;
> >>>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>> index a6e8f4591e63..0cc293a6ac24 100644
> >>>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> >>>>> @@ -1104,8 +1104,7 @@ static void sii8620_set_infoframes(struct sii8620 *ctx,
> >>>>> int ret;
> >>>>>
> >>>>> ret = drm_hdmi_avi_infoframe_from_display_mode(&frm.avi,
> >>>>> - mode,
> >>>>> - true);
> >>>>> + NULL, mode);
> >>>>> if (ctx->use_packed_pixel)
> >>>>> frm.avi.colorspace = HDMI_COLORSPACE_YUV422;
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>> index 64c3cf027518..88b720b63126 100644
> >>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>>>> @@ -1344,7 +1344,8 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode)
> >>>>> u8 val;
> >>>>>
> >>>>> /* Initialise info frame from DRM mode */
> >>>>> - drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> >>>>> + drm_hdmi_avi_infoframe_from_display_mode(&frame,
> >>>>> + &hdmi->connector, mode);
> >>>>>
> >>>>> if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
> >>>>> frame.colorspace = HDMI_COLORSPACE_YUV444;
> >>>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >>>>> index b506e3622b08..501ac05ba7da 100644
> >>>>> --- a/drivers/gpu/drm/drm_edid.c
> >>>>> +++ b/drivers/gpu/drm/drm_edid.c
> >>>>> @@ -4830,19 +4830,32 @@ void drm_set_preferred_mode(struct drm_connector *connector,
> >>>>> }
> >>>>> EXPORT_SYMBOL(drm_set_preferred_mode);
> >>>>>
> >>>>> +static bool is_hdmi2_sink(struct drm_connector *connector)
> >>>> You're usually known for adding const all around, why not const pointer
> >>>> here and in all the other drm_* functions that call this?
> >>> My current approach is to constify states/fbs/etc. but not so much
> >>> crtcs/connectors/etc. Too much const can sometimes get in the way
> >>> of things requiring that you remove the const later. But I guess
> >>> in this case the const shouldn't really get in the way of anything
> >>> because these are pretty much supposed to be pure functions.
> >>>
> >>>>> +{
> >>>>> + /*
> >>>>> + * FIXME: sil-sii8620 doesn't have a connector around when
> >>>>> + * we need one, so we have to be prepared for a NULL connector.
> >>>>> + */
> >>>>> + if (!connector)
> >>>>> + return false;
> >>>> This actually changes the is_hdmi2_sink value for sil-sii8620.
> >>> Hmm. No idea why they would have set that to true when everyone else is
> >>> passing false.
> >>
> >> Because false does not work :) More precisely MHLv3 (used in Sii8620)
> >> uses CTA-861-F standard for infoframes, which is specific to HDMI2.0.
> >>
> >> Unfortunately I have no access to MHL specs, but my experiments and
> >> vendor drivers strongly suggests it is done this way.
> >>
> >> This is important in case of 4K modes which are handled differently by
> >> HDMI 1.4 and HDMI2.0.
> > HDMI 2.0 handles 4k just like 1.4 handled it when you use one of
> > the 4k modes defined in 1.4. Only if you use features beyond 1.4 do we
> > switch over to the HDMI 2.0 specific signalling.
>
>
> The difference is in infoframes:
>
> HDMI 1.4 sets AVI infoframe VIC to 0, and sends HDMI_VIC in VSI.
>
> HDMI 2.0 sets AVI infoframe to non zero VICs introduced by
> HDMI2.0/CEA-861-F, VSI can be omitted if I remember correctly, unless 3d
> is in use.
Like I said, The HDMI 1.4 method is used even with HDMI 2.0 sinks unless
some feature gets used which can't be signalled via the HDMI 1.4 vendor
specific infoframe.
>
>
> So setting VICs to non-zero in case of HDMI1.4 sinks and 4k modes seems
> risky.
That is not what I was proposing.
>
>
> Regards
>
> Andrzej
>
>
> >
> >> The pipeline looks like (in parenthesis HDMI version on the stream):
> >>
> >> exynos_hdmi --(1.4)--> SII8620 --(2.0)--> MHL_dongle --(1.4)--> TV
> >>
> >>
> >>> I guess I can change this to true to not change it. IIRC
> >>> that was the only driver that didn't have a connector around.
> >>>
> >>> That said, I was actually thinking of removing this hdmi2 vs. not
> >>> stuff from drm_hdmi_avi_infoframe_from_display_mode(). We added it
> >>> "just in case", but we already have a similar issue with earlier
> >>> cea-861 revisions and haven't seen any bugs where an older monitor
> >>> would get confused by a VIC not yet defined when the monitor was
> >>> produced.
> >>>
> >> Are you sure this is a good idea? As I said earlier 4K modes are present
> >> in HDMI 1.4 and 2.0 but they are handled differently, so this is not
> >> only matter of unknown VIC in AVIF.
> >>
> >>
> >> Regards
> >>
> >> Andrzej
>
--
Ville Syrjälä
Intel
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
next prev parent reply other threads:[~2018-12-04 19:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 16:13 [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions Ville Syrjala
[not found] ` <20181120161345.15440-1-ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-11-20 16:27 ` Thierry Reding
2018-11-21 11:40 ` Jani Nikula
[not found] ` <87muq2ek04.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-11-21 11:51 ` Ville Syrjälä
2018-11-29 8:46 ` Andrzej Hajda
[not found] ` <d0e34bab-de8b-1005-b9e8-72afe66576ac-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2018-12-03 21:48 ` Ville Syrjälä
[not found] ` <20181203214844.GK9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-12-04 7:03 ` Andrzej Hajda
[not found] ` <aee2cad8-ef93-72d5-986f-b33aabd2c3d2-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2018-12-04 19:02 ` Ville Syrjälä [this message]
2018-12-05 7:40 ` Andrzej Hajda
[not found] ` <239ce5d3-3959-7926-7c0e-26997ec4e5ee-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2018-12-05 15:06 ` Ville Syrjälä
2018-11-21 18:19 ` Laurent Pinchart
2018-11-29 9:08 ` Andrzej Hajda
[not found] ` <6147ea2d-8044-45d5-7a64-9d632ff41b95-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2018-12-03 21:38 ` Ville Syrjälä
2018-12-04 7:46 ` Andrzej Hajda
[not found] ` <64018e44-9a5e-5b28-63db-f35b97dafb26-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2018-12-04 19:13 ` Ville Syrjälä
[not found] ` <20181204191320.GM9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-12-05 6:32 ` Laurent Pinchart
2018-12-05 8:46 ` Andrzej Hajda
[not found] ` <6da15ecc-d89a-952c-4a70-9d26e02ee58e-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2018-12-05 8:55 ` Laurent Pinchart
2018-12-05 14:43 ` Ville Syrjälä
2018-12-05 10:19 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181204190234.GL9144@intel.com \
--to=ville.syrjala-vuqaysv1563yd54fqh9/ca@public.gmane.org \
--cc=Laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=alexander.deucher-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=jani.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
--cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tomi.valkeinen-l0cyMroinI0@public.gmane.org \
--cc=vincent.abriou-qxv4g6HH51o@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).