All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <treding@nvidia.com>
To: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: linux-fbdev@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Martin Bugge <marbugge@cisco.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Subject: Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames
Date: Mon, 16 Nov 2015 11:50:39 +0000	[thread overview]
Message-ID: <20151116115037.GF31033@ulmo.nvidia.com> (raw)
In-Reply-To: <1447526299-4222-1-git-send-email-enric.balletbo@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]

On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
> the compressed video stream that were used to produce the uncompressed
> video.
> 
> The patch adds functions to work with MPEG InfoFrames.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>  drivers/video/hdmi.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/hdmi.h |  24 ++++++++
>  2 files changed, 180 insertions(+)

According to the CEA specification a source is expected to send this
type of infoframe once per video frame. I'm curious how you envision
this to be ensured. Would hardware provide a mechanism to store this
data and send the infoframe automatically? How would you ensure that
updates sent to the hardware match the upcoming frame?

> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
[...]
> @@ -435,6 +510,8 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size)
>  		length = hdmi_vendor_any_infoframe_pack(&frame->vendor,
>  							buffer, size);
>  		break;
> +	case HDMI_INFOFRAME_TYPE_MPEG:
> +		length = hdmi_mpeg_infoframe_pack(&frame->mpeg, buffer, size);

Missing "break;"?

> @@ -899,6 +978,41 @@ static void hdmi_audio_infoframe_log(const char *level,
>  			frame->downmix_inhibit ? "Yes" : "No");
>  }
>  
> +static const char *hdmi_mpeg_picture_get_name(enum hdmi_mpeg_picture_type type)
> +{
> +	switch (type) {
> +	case HDMI_MPEG_PICTURE_TYPE_UNKNOWN:
> +		return "Unknown";
> +	case HDMI_MPEG_PICTURE_TYPE_I:
> +		return "Intra-coded picture";
> +	case HDMI_MPEG_PICTURE_TYPE_B:
> +		return "Bi-predictive picture";
> +	case HDMI_MPEG_PICTURE_TYPE_P:
> +		return "Predicted picture";
> +	}

I'd have chosen the slightly more canonical "I-Frame", "P-Frame",
"B-Frame" here, but that's not a strong objection.

> +	return "Reserved";

There really can't be another value here, so I think this should either
return NULL or even go as far as let it crash. There should be no way
for the invalid value to make it this far.

> +static int hdmi_mpeg_infoframe_unpack(struct hdmi_mpeg_infoframe *frame,
> +				     void *buffer)
> +{
> +	u8 *ptr = buffer;
> +
> +	if (ptr[0] != HDMI_INFOFRAME_TYPE_MPEG ||
> +	    ptr[1] != 1 ||
> +	    ptr[2] != HDMI_MPEG_INFOFRAME_SIZE) {
> +		return -EINVAL;
> +	}

There's no need for the braces here.

> @@ -314,6 +336,7 @@ union hdmi_vendor_any_infoframe {
>   * @spd: spd infoframe
>   * @vendor: union of all vendor infoframes
>   * @audio: audio infoframe
> + * @mpeg: mpeg infoframe

s/mpeg/MPEG/

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <treding@nvidia.com>
To: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: linux-fbdev@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Martin Bugge <marbugge@cisco.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Subject: Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames
Date: Mon, 16 Nov 2015 12:50:39 +0100	[thread overview]
Message-ID: <20151116115037.GF31033@ulmo.nvidia.com> (raw)
In-Reply-To: <1447526299-4222-1-git-send-email-enric.balletbo@collabora.com>


[-- Attachment #1.1: Type: text/plain, Size: 2699 bytes --]

On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
> the compressed video stream that were used to produce the uncompressed
> video.
> 
> The patch adds functions to work with MPEG InfoFrames.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>  drivers/video/hdmi.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/hdmi.h |  24 ++++++++
>  2 files changed, 180 insertions(+)

According to the CEA specification a source is expected to send this
type of infoframe once per video frame. I'm curious how you envision
this to be ensured. Would hardware provide a mechanism to store this
data and send the infoframe automatically? How would you ensure that
updates sent to the hardware match the upcoming frame?

> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
[...]
> @@ -435,6 +510,8 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size)
>  		length = hdmi_vendor_any_infoframe_pack(&frame->vendor,
>  							buffer, size);
>  		break;
> +	case HDMI_INFOFRAME_TYPE_MPEG:
> +		length = hdmi_mpeg_infoframe_pack(&frame->mpeg, buffer, size);

Missing "break;"?

> @@ -899,6 +978,41 @@ static void hdmi_audio_infoframe_log(const char *level,
>  			frame->downmix_inhibit ? "Yes" : "No");
>  }
>  
> +static const char *hdmi_mpeg_picture_get_name(enum hdmi_mpeg_picture_type type)
> +{
> +	switch (type) {
> +	case HDMI_MPEG_PICTURE_TYPE_UNKNOWN:
> +		return "Unknown";
> +	case HDMI_MPEG_PICTURE_TYPE_I:
> +		return "Intra-coded picture";
> +	case HDMI_MPEG_PICTURE_TYPE_B:
> +		return "Bi-predictive picture";
> +	case HDMI_MPEG_PICTURE_TYPE_P:
> +		return "Predicted picture";
> +	}

I'd have chosen the slightly more canonical "I-Frame", "P-Frame",
"B-Frame" here, but that's not a strong objection.

> +	return "Reserved";

There really can't be another value here, so I think this should either
return NULL or even go as far as let it crash. There should be no way
for the invalid value to make it this far.

> +static int hdmi_mpeg_infoframe_unpack(struct hdmi_mpeg_infoframe *frame,
> +				     void *buffer)
> +{
> +	u8 *ptr = buffer;
> +
> +	if (ptr[0] != HDMI_INFOFRAME_TYPE_MPEG ||
> +	    ptr[1] != 1 ||
> +	    ptr[2] != HDMI_MPEG_INFOFRAME_SIZE) {
> +		return -EINVAL;
> +	}

There's no need for the braces here.

> @@ -314,6 +336,7 @@ union hdmi_vendor_any_infoframe {
>   * @spd: spd infoframe
>   * @vendor: union of all vendor infoframes
>   * @audio: audio infoframe
> + * @mpeg: mpeg infoframe

s/mpeg/MPEG/

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <treding@nvidia.com>
To: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: <linux-fbdev@vger.kernel.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	Martin Bugge <marbugge@cisco.com>, <linux-kernel@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames
Date: Mon, 16 Nov 2015 12:50:39 +0100	[thread overview]
Message-ID: <20151116115037.GF31033@ulmo.nvidia.com> (raw)
In-Reply-To: <1447526299-4222-1-git-send-email-enric.balletbo@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]

On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
> the compressed video stream that were used to produce the uncompressed
> video.
> 
> The patch adds functions to work with MPEG InfoFrames.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>  drivers/video/hdmi.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/hdmi.h |  24 ++++++++
>  2 files changed, 180 insertions(+)

According to the CEA specification a source is expected to send this
type of infoframe once per video frame. I'm curious how you envision
this to be ensured. Would hardware provide a mechanism to store this
data and send the infoframe automatically? How would you ensure that
updates sent to the hardware match the upcoming frame?

> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
[...]
> @@ -435,6 +510,8 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size)
>  		length = hdmi_vendor_any_infoframe_pack(&frame->vendor,
>  							buffer, size);
>  		break;
> +	case HDMI_INFOFRAME_TYPE_MPEG:
> +		length = hdmi_mpeg_infoframe_pack(&frame->mpeg, buffer, size);

Missing "break;"?

> @@ -899,6 +978,41 @@ static void hdmi_audio_infoframe_log(const char *level,
>  			frame->downmix_inhibit ? "Yes" : "No");
>  }
>  
> +static const char *hdmi_mpeg_picture_get_name(enum hdmi_mpeg_picture_type type)
> +{
> +	switch (type) {
> +	case HDMI_MPEG_PICTURE_TYPE_UNKNOWN:
> +		return "Unknown";
> +	case HDMI_MPEG_PICTURE_TYPE_I:
> +		return "Intra-coded picture";
> +	case HDMI_MPEG_PICTURE_TYPE_B:
> +		return "Bi-predictive picture";
> +	case HDMI_MPEG_PICTURE_TYPE_P:
> +		return "Predicted picture";
> +	}

I'd have chosen the slightly more canonical "I-Frame", "P-Frame",
"B-Frame" here, but that's not a strong objection.

> +	return "Reserved";

There really can't be another value here, so I think this should either
return NULL or even go as far as let it crash. There should be no way
for the invalid value to make it this far.

> +static int hdmi_mpeg_infoframe_unpack(struct hdmi_mpeg_infoframe *frame,
> +				     void *buffer)
> +{
> +	u8 *ptr = buffer;
> +
> +	if (ptr[0] != HDMI_INFOFRAME_TYPE_MPEG ||
> +	    ptr[1] != 1 ||
> +	    ptr[2] != HDMI_MPEG_INFOFRAME_SIZE) {
> +		return -EINVAL;
> +	}

There's no need for the braces here.

> @@ -314,6 +336,7 @@ union hdmi_vendor_any_infoframe {
>   * @spd: spd infoframe
>   * @vendor: union of all vendor infoframes
>   * @audio: audio infoframe
> + * @mpeg: mpeg infoframe

s/mpeg/MPEG/

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-11-16 11:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-14 18:38 [PATCH] [media] hdmi: added functions for MPEG InfoFrames Enric Balletbo i Serra
2015-11-14 18:38 ` Enric Balletbo i Serra
2015-11-14 18:38 ` Enric Balletbo i Serra
2015-11-16 11:50 ` Thierry Reding [this message]
2015-11-16 11:50   ` Thierry Reding
2015-11-16 11:50   ` Thierry Reding
2015-11-16 16:28   ` Enric Balletbo Serra
2015-11-16 16:28     ` Enric Balletbo Serra
2015-11-16 16:28     ` Enric Balletbo Serra
2015-11-17 12:55     ` Thierry Reding
2015-11-17 12:55       ` Thierry Reding
2015-11-17 12:55       ` Thierry Reding
2015-11-17 22:55       ` Enric Balletbo Serra
2015-11-17 22:55         ` Enric Balletbo Serra
2015-11-17 22:55         ` Enric Balletbo Serra
2015-11-19 11:51         ` Thierry Reding
2015-11-19 11:51           ` Thierry Reding
2015-11-19 11:51           ` Thierry Reding
2015-11-19 12:29           ` Enric Balletbo Serra
2015-11-19 12:29             ` Enric Balletbo Serra
2015-11-19 12:29             ` Enric Balletbo Serra
2015-12-09 12:10             ` Enric Balletbo Serra
2015-12-09 12:10               ` Enric Balletbo Serra

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=20151116115037.GF31033@ulmo.nvidia.com \
    --to=treding@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eballetbo@gmail.com \
    --cc=hans.verkuil@cisco.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marbugge@cisco.com \
    --cc=mchehab@osg.samsung.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=tomi.valkeinen@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.