Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758532AbbKSLv6 (ORCPT ); Thu, 19 Nov 2015 06:51:58 -0500 Received: from hqemgate16.nvidia.com ([216.228.121.65]:8517 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758516AbbKSLv4 (ORCPT ); Thu, 19 Nov 2015 06:51:56 -0500 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Thu, 19 Nov 2015 03:40:04 -0800 Date: Thu, 19 Nov 2015 12:51:46 +0100 From: Thierry Reding To: Enric Balletbo Serra CC: , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , Hans Verkuil , Mauro Carvalho Chehab , Martin Bugge , , dri-devel Subject: Re: [PATCH] [media] hdmi: added functions for MPEG InfoFrames Message-ID: <20151119115144.GA21862@ulmo.nvidia.com> References: <1447526299-4222-1-git-send-email-enric.balletbo@collabora.com> <20151116115037.GF31033@ulmo.nvidia.com> <20151117125507.GD25715@ulmo.nvidia.com> MIME-Version: 1.0 In-Reply-To: X-NVConfidentiality: public User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) X-Originating-IP: [10.2.70.143] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4480 Lines: 104 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 17, 2015 at 11:55:53PM +0100, Enric Balletbo Serra wrote: > Hello Thierry, >=20 > 2015-11-17 13:55 GMT+01:00 Thierry Reding : > > 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 : > >> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wro= te: > >> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes asp= ects of > >> >> the compressed video stream that were used to produce the uncompres= sed > >> >> video. > >> >> > >> >> The patch adds functions to work with MPEG InfoFrames. > >> >> > >> >> Signed-off-by: Enric Balletbo i Serra > >> >> --- > >> >> 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? > > >=20 > 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. >=20 > [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 --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWTbfMAAoJEN0jrNd/PrOhKywP/jUGBNbFkKXQQ59RqjEew2rS eNX5LZbN9i721uiJt4MWVllZQuiiK2dUNt6pUkxz7IH+yGHYLnHctkZctaVzAqwG ew30P+SBgJsP6Q52U/eRi69m7dZFB0qw0uc2pma7knFV0ro3k1XNXLAQ8XBJ+0U4 mA6RxbtrkmP1oT7MxJkU072ipJRlhr6Oi+r6RkqBTsx8m1SfG1uG5MyEwtllYkDq E2ufacYKAQ8Nfo6dAy0Q2v3D/gxch1HM8CdIT3n6QOjXTJzJPwI0uEAavFE18czz q2gdlRoupni326Ag5IX/djmMtPi7hMCrUNonjz3BnvBEJgfQaaZIdk8DPp95/ulo nKSST2Zde9rXrhC+gH4mKqTC+vmOhNbOl5lxaG5YbbLUGXAxcFbNoGKZVR5I5pSI 20rQZIiqzHi3JLVa0bFw0sKpkF+MZYkpTFTWZEdref8TAJJJ2S9wyeSD3lqaTBfj e3nGkWPWA0flqWiForEYzgDLJqIQ/q/k6cjFND6x+uk42mlPsMRSy7JHR+0VP1MX P5eZoFRP4do1mKROFS4yAjCth6/D6o8y8MUHanB0IAeapEchP56l5cDyjCRaPrzB ksPqpChVOQe9VMruHFy8Iog9pP/kv0NG0cNlZhWsfTq18Bpm3C3AQoMXy1yPcoQ6 +ZpA4l7LHN7VE4tlbq5S =pMp/ -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/