From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel. Date: Wed, 23 Mar 2011 08:18:20 -0700 Message-ID: <20110323081820.5b37d169@jbarnes-desktop> References: <1300815176-21206-1-git-send-email-mythripk@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-media-owner@vger.kernel.org To: "K, Mythri P" Cc: Dave Airlie , linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org, dri-devel , linux-media@vger.kernel.org List-Id: linux-omap@vger.kernel.org On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" wrote: > Hi Dave, >=20 > On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie wrot= e: > > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote= : > >> 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. > >> > > > > If you want to take this approach, you need to start from the DRM E= DID parser, > > its the most well tested and I can guarantee its been plugged into = more monitors > > than any of the others. There is just no way we would move the DRM = parser to a > > library one that isn't derived from it + enhancements, as we'd thro= w away the > > years of testing and the regression count would be way too high. > > > I had a look at the DRM EDID code, but for quirks it looks pretty muc= h the same. > yes i could take quirks and other DRM tested code and enhance, but > still the code has to do away with struct drm_display_mode > which is very much custom to DRM. If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need. Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code. Do you really think the differences between your code and the existing DRM code are irreconcilable? --=20 Jesse Barnes, Intel Open Source Technology Center