On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote:

Em 22-03-2011 14:32, Mythri P K escreveu:

quoted

Adding support for common EDID parsing in kernel.

EDID - Extended display identification data is a data structure provided 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 kernel, some
of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
parsing of EDID should be done in a library, which is agnostic of the
framework (V4l2, DRM, FB)  which is using the functionality, just 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 implementation
of EDID.
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401

This patch tries to add functions to parse some portion EDID (detailed timing,
monitor limits, AV delay information, deep color mode support, Audio and VSDB)
If we can align on this library approach i can enhance this library to parse
other blocks and probably we could also add quirks from other implementation
as well.

Signed-off-by: Mythri P K <redacted>
---
 arch/arm/include/asm/edid.h |  243 ++++++++++++++++++++++++++++++
 drivers/video/edid.c        |  340 +++++++++++++++++++++++++++++++++++++++++++

Hmm... if you want this to be agnostic, the header file should not be 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 of
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.