All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Hans Verkuil <hansverk@cisco.com>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
Date: Fri, 21 Sep 2018 18:07:12 +0300	[thread overview]
Message-ID: <20180921150712.GB5565@intel.com> (raw)
In-Reply-To: <55a45f48-f9d8-a28f-c847-d8083d500585@cisco.com>

On Fri, Sep 21, 2018 at 04:12:36PM +0200, Hans Verkuil wrote:
> On 09/21/18 16:01, Ville Syrjälä wrote:
> > On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
> >> On 09/20/18 20:51, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> We'll be wanting to send more than just infoframes over HDMI. So add an
> >>> enum for other packet types.
> >>>
> >>> TODO: Maybe just include the infoframe types in the packet type enum
> >>>       and get rid of the infoframe type enum?
> >>
> >> I think that's better, IMHO. With a comment that the types starting with
> >> 0x81 are defined in CTA-861-G.
> >>
> >> It's really the same byte that is being checked, so having two enums is
> >> a bit misleading. The main difference is really which standard defines
> >> the packet types.
> > 
> > Right. The only slight annoyance is that we'll get a bunch of warnings
> > from the compiler if we don't handle all the enum valus in the switch
> > statements. If we want to avoid that I guess I could limit this
> > to just the null, gcp and gamut metadata packets initially and try to
> > write some actual code for them. Those three are the only ones we
> > care about in i915 at the moment.
> 
> Note that I don't have a terribly strong opinion on this, so if using
> one enum instead of two causes more problems than it is worth, then
> that's fine with me as well.
> 
> But you asked, and given a choice with all other things being equal,
> then one enum has my preference.

I do agree that it would seem nicer.

But I'm a bit busy with other things at the moment so I might want
to leave it like this for now and revisit the topic in the
hopefully-not-too-distant future.

> 
> Regards,
> 
> 	Hans
> 
> > 
> >>
> >> Regards,
> >>
> >> 	Hans
> >>
> >>>
> >>> Cc: Thierry Reding <thierry.reding@gmail.com>
> >>> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> >>> Cc: linux-media@vger.kernel.org
> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> ---
> >>>  include/linux/hdmi.h | 15 +++++++++++++++
> >>>  1 file changed, 15 insertions(+)
> >>>
> >>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> >>> index c76b50a48e48..80521d9591a1 100644
> >>> --- a/include/linux/hdmi.h
> >>> +++ b/include/linux/hdmi.h
> >>> @@ -27,6 +27,21 @@
> >>>  #include <linux/types.h>
> >>>  #include <linux/device.h>
> >>>  
> >>> +enum hdmi_packet_type {
> >>> +	HDMI_PACKET_TYPE_NULL = 0x00,
> >>> +	HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> >>> +	HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> >>> +	HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> >>> +	HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> >>> +	HDMI_PACKET_TYPE_ISRC1 = 0x05,
> >>> +	HDMI_PACKET_TYPE_ISRC2 = 0x06,
> >>> +	HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> >>> +	HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> >>> +	HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> >>> +	HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> >>> +	/* + enum hdmi_infoframe_type */
> >>> +};
> >>> +
> >>>  enum hdmi_infoframe_type {
> >>>  	HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> >>>  	HDMI_INFOFRAME_TYPE_AVI = 0x82,
> >>>
> > 

-- 
Ville Syrjälä
Intel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Hans Verkuil <hansverk@cisco.com>
Cc: intel-gfx@lists.freedesktop.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
Date: Fri, 21 Sep 2018 18:07:12 +0300	[thread overview]
Message-ID: <20180921150712.GB5565@intel.com> (raw)
In-Reply-To: <55a45f48-f9d8-a28f-c847-d8083d500585@cisco.com>

On Fri, Sep 21, 2018 at 04:12:36PM +0200, Hans Verkuil wrote:
> On 09/21/18 16:01, Ville Syrjälä wrote:
> > On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
> >> On 09/20/18 20:51, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> We'll be wanting to send more than just infoframes over HDMI. So add an
> >>> enum for other packet types.
> >>>
> >>> TODO: Maybe just include the infoframe types in the packet type enum
> >>>       and get rid of the infoframe type enum?
> >>
> >> I think that's better, IMHO. With a comment that the types starting with
> >> 0x81 are defined in CTA-861-G.
> >>
> >> It's really the same byte that is being checked, so having two enums is
> >> a bit misleading. The main difference is really which standard defines
> >> the packet types.
> > 
> > Right. The only slight annoyance is that we'll get a bunch of warnings
> > from the compiler if we don't handle all the enum valus in the switch
> > statements. If we want to avoid that I guess I could limit this
> > to just the null, gcp and gamut metadata packets initially and try to
> > write some actual code for them. Those three are the only ones we
> > care about in i915 at the moment.
> 
> Note that I don't have a terribly strong opinion on this, so if using
> one enum instead of two causes more problems than it is worth, then
> that's fine with me as well.
> 
> But you asked, and given a choice with all other things being equal,
> then one enum has my preference.

I do agree that it would seem nicer.

But I'm a bit busy with other things at the moment so I might want
to leave it like this for now and revisit the topic in the
hopefully-not-too-distant future.

> 
> Regards,
> 
> 	Hans
> 
> > 
> >>
> >> Regards,
> >>
> >> 	Hans
> >>
> >>>
> >>> Cc: Thierry Reding <thierry.reding@gmail.com>
> >>> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> >>> Cc: linux-media@vger.kernel.org
> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> ---
> >>>  include/linux/hdmi.h | 15 +++++++++++++++
> >>>  1 file changed, 15 insertions(+)
> >>>
> >>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> >>> index c76b50a48e48..80521d9591a1 100644
> >>> --- a/include/linux/hdmi.h
> >>> +++ b/include/linux/hdmi.h
> >>> @@ -27,6 +27,21 @@
> >>>  #include <linux/types.h>
> >>>  #include <linux/device.h>
> >>>  
> >>> +enum hdmi_packet_type {
> >>> +	HDMI_PACKET_TYPE_NULL = 0x00,
> >>> +	HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> >>> +	HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> >>> +	HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> >>> +	HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> >>> +	HDMI_PACKET_TYPE_ISRC1 = 0x05,
> >>> +	HDMI_PACKET_TYPE_ISRC2 = 0x06,
> >>> +	HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> >>> +	HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> >>> +	HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> >>> +	HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> >>> +	/* + enum hdmi_infoframe_type */
> >>> +};
> >>> +
> >>>  enum hdmi_infoframe_type {
> >>>  	HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> >>>  	HDMI_INFOFRAME_TYPE_AVI = 0x82,
> >>>
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-09-21 20:56 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-20 18:51 [PATCH 00/18] drm/i915: Infoframe precompute/check Ville Syrjala
2018-09-20 18:51 ` Ville Syrjala
2018-09-20 18:51 ` [PATCH 01/18] video/hdmi: Constify 'buffer' to the unpack functions Ville Syrjala
2018-09-20 18:51   ` Ville Syrjala
2018-09-21  8:03   ` Hans Verkuil
2018-09-21  8:03     ` Hans Verkuil
2018-09-20 18:51 ` [PATCH 02/18] video/hdmi: Pass buffer size to infoframe " Ville Syrjala
2018-09-20 18:51   ` Ville Syrjala
2018-09-21  8:06   ` Hans Verkuil
2018-09-21  8:06     ` Hans Verkuil
2018-09-20 18:51 ` [PATCH 03/18] video/hdmi: Constify infoframe passed to the log functions Ville Syrjala
2018-09-20 18:51   ` Ville Syrjala
2018-09-21  8:06   ` Hans Verkuil
2018-09-21  8:06     ` Hans Verkuil
2018-09-20 18:51 ` [PATCH 04/18] video/hdmi: Constify infoframe passed to the pack functions Ville Syrjala
2018-09-20 18:51   ` Ville Syrjala
2018-09-21  8:24   ` Hans Verkuil
2018-09-21  8:24     ` Hans Verkuil
2018-09-21 14:30     ` Ville Syrjälä
2018-09-21 14:30       ` Ville Syrjälä
2018-09-21 14:33   ` [PATCH v3 " Ville Syrjala
2018-09-21 14:33     ` Ville Syrjala
2018-10-01 19:10     ` Ville Syrjälä
2018-10-01 19:10       ` Ville Syrjälä
2018-10-02  6:37       ` Hans Verkuil
2018-10-02  6:37         ` Hans Verkuil
2018-09-20 18:51 ` [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types Ville Syrjala
2018-09-20 18:51   ` Ville Syrjala
2018-09-21  8:41   ` Hans Verkuil
2018-09-21  8:41     ` Hans Verkuil
2018-09-21 14:01     ` Ville Syrjälä
2018-09-21 14:01       ` Ville Syrjälä
2018-09-21 14:12       ` Hans Verkuil
2018-09-21 14:12         ` Hans Verkuil
2018-09-21 15:07         ` Ville Syrjälä [this message]
2018-09-21 15:07           ` Ville Syrjälä
2018-12-20 11:27   ` Sharma, Shashank
2018-09-20 18:51 ` [PATCH 06/18] video/hdmi: Handle the MPEG Source infoframe Ville Syrjala
2018-09-20 18:51   ` Ville Syrjala
2018-09-21  8:28   ` Hans Verkuil
2018-09-21  8:28     ` Hans Verkuil
2018-09-21 13:53     ` Ville Syrjälä
2018-09-21 13:53       ` Ville Syrjälä
2018-09-21 15:09   ` [PATCH v2 " Ville Syrjala
2018-09-21 15:09     ` Ville Syrjala
2018-09-20 18:51 ` [PATCH 07/18] video/hdmi: Handle the NTSC VBI infoframe Ville Syrjala
2018-09-20 18:51   ` Ville Syrjala
2018-09-21  8:30   ` Hans Verkuil
2018-09-21  8:30     ` Hans Verkuil
2018-09-21 13:54     ` Ville Syrjälä
2018-09-21 13:54       ` Ville Syrjälä
2018-09-21 15:10   ` [PATCH v2 " Ville Syrjala
2018-09-21 15:10     ` Ville Syrjala
2018-09-20 18:51 ` [PATCH 08/18] drm/i915: Use memmove() for punching the hole into infoframes Ville Syrjala
2018-09-21 13:52   ` Daniel Vetter
2018-09-20 18:51 ` [PATCH 09/18] drm/i915: Pass intel_encoder to infoframe functions Ville Syrjala
2018-09-21 13:59   ` Daniel Vetter
2018-09-21 15:03     ` Ville Syrjälä
2018-09-20 18:51 ` [PATCH 10/18] drm/i915: Add the missing HDMI gamut metadata packet stuff Ville Syrjala
2018-09-21 14:15   ` [Intel-gfx] " Daniel Vetter
2018-09-20 18:51 ` [PATCH 11/18] drm/i915: Return the mask of enabled infoframes from ->inforame_enabled() Ville Syrjala
2018-09-24 15:51   ` Daniel Vetter
2018-09-24 16:36     ` [Intel-gfx] " Ville Syrjälä
2018-10-01  6:55       ` Daniel Vetter
2018-10-01 19:29         ` Ville Syrjälä
2018-09-20 18:51 ` [PATCH 12/18] drm/i915: Store mask of enabled infoframes in the crtc state Ville Syrjala
2018-09-24 15:51   ` [Intel-gfx] " Daniel Vetter
2018-09-20 18:51 ` [PATCH 13/18] drm/i915: Precompute HDMI infoframes Ville Syrjala
2018-09-24 15:58   ` Daniel Vetter
2018-09-24 16:42     ` Ville Syrjälä
2018-09-20 18:51 ` [PATCH 14/18] drm/i915: Read out " Ville Syrjala
2018-09-24 16:08   ` Daniel Vetter
2018-09-24 16:52     ` Ville Syrjälä
2018-09-20 18:51 ` [PATCH 15/18] drm/i915/sdvo: Precompute " Ville Syrjala
2018-09-20 18:51 ` [PATCH 16/18] drm/i915/sdvo: Read out " Ville Syrjala
2018-09-24 16:10   ` [Intel-gfx] " Daniel Vetter
2018-09-24 17:13     ` Ville Syrjälä
2018-10-01  6:59       ` Daniel Vetter
2018-10-01 13:35         ` Ville Syrjälä
2018-10-01 16:48           ` Daniel Vetter
2018-09-20 18:51 ` [PATCH 17/18] drm/i915: Check infoframe state in intel_pipe_config_compare() Ville Syrjala
2018-09-24 16:12   ` Daniel Vetter
2018-10-01 20:35     ` [Intel-gfx] " Ville Syrjälä
2018-10-02  8:16       ` Daniel Vetter
2018-09-20 18:51 ` [PATCH 18/18] drm/i915: Include infoframes in the crtc state dump Ville Syrjala
2018-09-24 16:14   ` [Intel-gfx] " Daniel Vetter
2018-09-20 19:02 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Infoframe precompute/check Patchwork
2018-09-20 19:12 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-09-20 19:26 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-20 22:30 ` ✓ Fi.CI.IGT: " Patchwork
2018-09-21 14:40 ` ✗ Fi.CI.BAT: failure for drm/i915: Infoframe precompute/check (rev2) Patchwork
2018-09-21 15:25 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Infoframe precompute/check (rev4) Patchwork
2018-09-21 15:35 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-09-21 15:46 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-21 17:04 ` ✓ 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=20180921150712.GB5565@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hans.verkuil@cisco.com \
    --cc=hansverk@cisco.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-media@vger.kernel.org \
    --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 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.