[PATCH] [media] hdmi: added functions for MPEG InfoFrames

[Thierry Reding]

On Tue, Nov 17, 2015 at 11:55:53PM +0100, Enric Balletbo Serra wrote:
> Hello Thierry,
> 
> 2015-11-17 13:55 GMT+01:00 Thierry Reding <treding at nvidia.com>:
> > On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
> >> Hello Thierry,
> >>
> >> Many thanks for your comments.
> >>
> >> 2015-11-16 12:50 GMT+01:00 Thierry Reding <treding at nvidia.com>:
> >> > 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 at 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?
> >> >
> >>
> >> To be honest I'm not sure if I have the full picture. In the use case
> >> I'm trying there is a hardware mechanism to store the data and send
> >> the infoframe through a "Packet Send Control Register".
> >
> > Okay, sounds like the hardware will automatically send out packets at
> > the right time. That still leaves open the issue of how to ensure this
> > is synchronized with userspace. Perhaps this could be done by attaching
> > a property to a framebuffer, so that we'd know what exact frame the meta
> > data is attached to and when to update the FIFOs for the infoframe.
> >
> > Usually it's a good idea to send this type of patch as part of a larger
> > series precisely so that people can see how it is used. That should make
> > it easier to see if this is good enough or needs some more thought on
> > how to synchronize. Do you have any code that you could post that makes
> > use of this new infoframe?
> >
> 
> I was thinking use this and other helpers in the anx7814 bridge
> driver[1], I thought that this patch should go through another tree,
> this is the reason why I send it separately, but If you want or you
> prefer I can send as part of these patch series.
> 
> [1] https://lkml.org/lkml/2015/11/13/284

I haven't seen those patches yet. I should've been Cc'ed on those
patches since I'm technically the maintainer of drm/bridge. Did the
get_maintainer.pl script not list me?

In my opinion, it's usually a good idea to keep all dependencies in a
single series, just so people get a better picture of what you're
submitting. Of course that's just my opinion, somebody else may yell at
you because they get Cc'ed on patches that they're not interested in...

As for merging patches, it's usually best to let maintainers figure that
out once the series is in good shape.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151119/20600a54/attachment.sig>