Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames
From: Thierry Reding
Date: Thu Nov 19 2015 - 06:52:04 EST
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@xxxxxxxxxx>:
> > 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@xxxxxxxxxx>:
> >> > 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@xxxxxxxxxxxxx>
> >> >> ---
> >> >> 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, 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.
>  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.
Description: PGP signature