From mboxrd@z Thu Jan 1 00:00:00 1970 From: "K, Mythri P" Subject: Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel. Date: Wed, 23 Mar 2011 19:17:20 +0530 Message-ID: References: <1300815176-21206-1-git-send-email-mythripk@ti.com> <4D88E1FB.5070503@redhat.com> <20110322175810.GA32416@linux-sh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20110322175810.GA32416@linux-sh.org> Sender: linux-media-owner@vger.kernel.org To: Paul Mundt Cc: Mauro Carvalho Chehab , linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org, linux-media@vger.kernel.org List-Id: linux-omap@vger.kernel.org Hi Paul, On Tue, Mar 22, 2011 at 11:28 PM, Paul Mundt wrot= e: > On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote= : >> Em 22-03-2011 14:32, Mythri P K escreveu: >> > Adding support for common EDID parsing in kernel. >> > >> > EDID - Extended display identification data is a data structure pr= ovided by >> > a digital display to describe its capabilities to a video source, = This a >> > standard supported by CEA and VESA. >> > >> > There are several custom implementations for parsing EDID in kerne= l, some >> > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Idea= lly >> > parsing of EDID should be done in a library, which is agnostic of = the >> > framework (V4l2, DRM, FB) =A0which is using the functionality, jus= t based on >> > the raw EDID pointer with size/segment information. >> > >> > With other RFC's such as the one below, which tries to standardize= HDMI API's >> > It would be better to have a common EDID code in one place.It also= helps to >> > provide better interoperability with variety of TV/Monitor may be = even by >> > listing out quirks which might get missed with several custom impl= ementation >> > of EDID. >> > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrast= ructure/30401 >> > >> > This patch tries to add functions to parse some portion EDID (deta= iled timing, >> > monitor limits, AV delay information, deep color mode support, Aud= io and VSDB) >> > If we can align on this library approach i can enhance this librar= y to parse >> > other blocks and probably we could also add quirks from other impl= ementation >> > as well. >> > >> > Signed-off-by: Mythri P K >> > --- >> > =A0arch/arm/include/asm/edid.h | =A0243 ++++++++++++++++++++++++++= ++++ >> > =A0drivers/video/edid.c =A0 =A0 =A0 =A0| =A0340 ++++++++++++++++++= +++++++++++++++++++++++++ >> >> Hmm... if you want this to be agnostic, the header file should not b= e inside >> arch/arm, but on some other place, like include/video/. >> > Ironically this adds a drivers/video/edid.c but completely ignores > drivers/video/edid.h which already exists and already contains many o= f > these definitions. > > I like the idea of a generalized library, but it would be nice to see= the > existing edid.h evolved and its users updated incrementally. > well yes , That could be enhanced and that would take care of Mauro's comment too. Thanks and regards, Mythri.