intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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

  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).