From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Sharma, Shashank" <shashank.sharma@intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
Andrzej Hajda <a.hajda@samsung.com>,
Thierry Reding <thierry.reding@gmail.com>,
Hans Verkuil <hans.verkuil@cisco.com>,
linux-media@vger.kernel.org
Subject: Re: [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes
Date: Thu, 16 Nov 2017 18:16:31 +0200 [thread overview]
Message-ID: <20171116161631.GV10981@intel.com> (raw)
In-Reply-To: <6e738687-62f2-c803-a64c-7364bae3eacf@intel.com>
On Thu, Nov 16, 2017 at 08:06:18PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
> > when switching from 3D to 2D mode, even if the infoframe isn't strictly
> > necessary (ie. not needed to transmit the VIC or stereo information).
> > This is a workaround against some sinks that fail to realize that they
> > should switch from 3D to 2D mode when the source stop transmitting
> > the infoframe.
> >
> > v2: Handle unpack() as well
> > Pull the length calculation into a helper
> >
> > Cc: Shashank Sharma <shashank.sharma@intel.com>
> > Cc: Andrzej Hajda <a.hajda@samsung.com>
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: Hans Verkuil <hans.verkuil@cisco.com>
> > Cc: linux-media@vger.kernel.org
> > Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> #v1
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/video/hdmi.c | 51 +++++++++++++++++++++++++++++++--------------------
> > 1 file changed, 31 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 1cf907ecded4..111a0ab6280a 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct hdmi_vendor_infoframe *frame)
> > }
> > EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
> >
> > +static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame)
> > +{
> > + /* for side by side (half) we also need to provide 3D_Ext_Data */
> > + if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > + return 6;
> > + else if (frame->vic != 0 || frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
> > + return 5;
> > + else
> > + return 4;
> > +}
> > +
> > /**
> > * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary buffer
> > * @frame: HDMI infoframe
> > @@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
> > u8 *ptr = buffer;
> > size_t length;
> >
> > - /* empty info frame */
> > - if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
> > - return -EINVAL;
> > -
> > /* only one of those can be supplied */
> > if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
> > return -EINVAL;
> >
> > - /* for side by side (half) we also need to provide 3D_Ext_Data */
> > - if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > - frame->length = 6;
> > - else
> > - frame->length = 5;
> > + frame->length = hdmi_vendor_infoframe_length(frame);
> >
> > length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> >
> > @@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
> > ptr[5] = 0x0c;
> > ptr[6] = 0x00;
> >
> > - if (frame->vic) {
> > - ptr[7] = 0x1 << 5; /* video format */
> > - ptr[8] = frame->vic;
> > - } else {
> > + if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
> > ptr[7] = 0x2 << 5; /* video format */
> > ptr[8] = (frame->s3d_struct & 0xf) << 4;
> > if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
> > + } else if (frame->vic) {
> Please correct me if I dint understand this properly, but for a HDMI 2.0
> sink + 3D transmission, wouldn't I be sending
> HDMI 2.0 VIC = 94 as well as some valid s3d flag (like side by side) ?
That vic will be in the AVI infoframe. Here we're concerned about the
VIC in the HDMI vendor infoframe.
>
> - Shashank
> > + ptr[7] = 0x1 << 5; /* video format */
> > + ptr[8] = frame->vic;
> > + } else {
> > + ptr[7] = 0x0 << 5; /* video format */
> > }
> >
> > hdmi_infoframe_set_checksum(buffer, length);
> > @@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame,
> >
> > if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
> > ptr[1] != 1 ||
> > - (ptr[2] != 5 && ptr[2] != 6))
> > + (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
> > return -EINVAL;
> >
> > length = ptr[2];
> > @@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame,
> >
> > hvf->length = length;
> >
> > - if (hdmi_video_format == 0x1) {
> > - hvf->vic = ptr[4];
> > - } else if (hdmi_video_format == 0x2) {
> > + if (hdmi_video_format == 0x2) {
> > + if (length != 5 && length != 6)
> > + return -EINVAL;
> > hvf->s3d_struct = ptr[4] >> 4;
> > if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
> > - if (length == 6)
> > - hvf->s3d_ext_data = ptr[5] >> 4;
> > - else
> > + if (length != 6)
> > return -EINVAL;
> > + hvf->s3d_ext_data = ptr[5] >> 4;
> > }
> > + } else if (hdmi_video_format == 0x1) {
> > + if (length != 5)
> > + return -EINVAL;
> > + hvf->vic = ptr[4];
> > + } else {
> > + if (length != 4)
> > + return -EINVAL;
> > }
> >
> > return 0;
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2017-11-16 16:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 17:04 [PATCH 00/10] drm/edid: Infoframe cleanups and fixes Ville Syrjala
2017-11-13 17:04 ` [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes Ville Syrjala
2017-11-16 14:36 ` Sharma, Shashank
2017-11-16 16:16 ` Ville Syrjälä [this message]
2017-11-17 3:05 ` Sharma, Shashank
2017-11-13 17:04 ` [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D Ville Syrjala
2017-11-16 14:40 ` Sharma, Shashank
2017-11-16 16:21 ` Ville Syrjälä
2017-11-17 3:10 ` Sharma, Shashank
2017-11-22 18:28 ` Ville Syrjälä
2017-11-13 17:04 ` [PATCH 03/10] drm/modes: Introduce drm_mode_match() Ville Syrjala
2017-11-13 17:04 ` [PATCH 04/10] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy Ville Syrjala
2017-11-13 17:04 ` [PATCH 05/10] drm/edid: Fix up edid_cea_modes[] formatting Ville Syrjala
2017-11-13 17:04 ` [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling Ville Syrjala
2017-11-13 18:13 ` Jose Abreu
2017-11-13 18:53 ` Ville Syrjälä
2017-11-16 14:51 ` Sharma, Shashank
2017-11-16 16:23 ` Ville Syrjälä
2017-11-17 3:19 ` Sharma, Shashank
2017-11-17 11:35 ` Ville Syrjälä
2017-11-17 12:20 ` Sharma, Shashank
2017-11-17 12:49 ` Ville Syrjälä
2017-11-24 8:56 ` Sharma, Shashank
2017-11-24 13:22 ` Ville Syrjälä
2017-11-13 17:04 ` [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes Ville Syrjala
2017-11-13 18:30 ` Jose Abreu
2017-11-13 19:00 ` Ville Syrjälä
2017-11-16 15:01 ` Sharma, Shashank
2017-11-16 16:26 ` Ville Syrjälä
2017-11-17 3:23 ` Sharma, Shashank
2017-11-17 11:38 ` Ville Syrjälä
2017-11-24 8:55 ` Sharma, Shashank
2017-11-13 17:04 ` [PATCH 08/10] video/hdmi: Reject illegal picture aspect ratios Ville Syrjala
2017-11-13 18:33 ` Jose Abreu
2017-11-13 17:04 ` [PATCH 09/10] video/hdmi: Constify 'buffer' to the unpack functions Ville Syrjala
2017-11-13 17:04 ` [PATCH 10/10] video/hdmi: Pass buffer size to infoframe " Ville Syrjala
2017-11-20 13:36 ` Hans Verkuil
2017-11-20 14:55 ` Ville Syrjälä
2017-11-13 17:52 ` ✓ Fi.CI.BAT: success for drm/edid: Infoframe cleanups and fixes Patchwork
2017-11-13 19:07 ` ✓ Fi.CI.IGT: " Patchwork
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=20171116161631.GV10981@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=a.hajda@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hans.verkuil@cisco.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-media@vger.kernel.org \
--cc=shashank.sharma@intel.com \
--cc=thierry.reding@gmail.com \
/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).