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
next prev parent 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: linkBe 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.