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

[Enric Balletbo Serra]

Hello Thierry,

2015-11-19 12:51 GMT+01:00 Thierry Reding <treding@xxxxxxxxxx>:
> 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[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?
>

Mmm, just checked and yes, get_maintainer list you, so probably I did
something getting the maintainers.
Sorry.

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/