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: Fri, 25 Mar 2011 19:04:05 +0530 Message-ID: References: <1300815176-21206-1-git-send-email-mythripk@ti.com> <20110323081820.5b37d169@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from na3sys009aog104.obsmtp.com ([74.125.149.73]:53818 "EHLO na3sys009aog104.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751985Ab1CYNe1 (ORCPT ); Fri, 25 Mar 2011 09:34:27 -0400 In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Guennadi Liakhovetski Cc: Jesse Barnes , Dave Airlie , linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org, dri-devel , linux-media@vger.kernel.org Hi Gunnedi, >> > 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. > > Does the DRM EDID-parser also process blocks beyond the first one and > also parses SVD entries similar to what I've recently added to fbdev? Yes, > we definitely need a common EDID parses, and maybe we'll have to collect > various pieces from different implementations. > As far as I know , it does not parse SVD ,But it should not be that difficult to add. We could take the SVD parsing from your code . In the RFC i have posted I parse for detailed timing and other VSDB blocks. Also the parsing should be based on the extension type for multiple 128 byte blocks. Thanks and regards, Mythri. > Thanks > Guennadi >