linux-kernel - Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5108D9BA.9040305@nvidia.com>
Date:	Wed, 30 Jan 2013 17:28:42 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	Thierry Reding <thierry.reding@...onic-design.de>
CC:	Mark Zhang <nvmarkzhang@...il.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Mark Zhang <markz@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"gnurou@...il.com" <gnurou@...il.com>
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support

On 01/30/2013 04:48 PM, Thierry Reding wrote:
> I already said this in another thread. I think we should only be using
> the CDF .get_modes() for static modes that cannot be obtained from EDID.
> Thinking about it, I'm not quite sure why EDID would be needed for this
> kind of panel anyway. Ventana probably has it because it keeps us from
> having to hardcode things, but if we provide drivers for the panel
> anyway, we can just as well hard-code the supported mode(s) in those
> drivers.
>
> What I'm trying to say is that the existence of EDID is board-specific,
> so boards other than Ventana may not have an EDID EEPROM. Or perhaps
> this particular display has the EEPROM integrated? Even in that case,
> some boards may use this panel and simply not connect the EEPROM to an
> I2C controller.

Actually this display has its own EEPROM and pins for the I2C bus. 
That's why it would seems out-of-place to have EDID taking place outside 
its driver.

But you are right that we should also handle the case where the I2C bus 
is not connected and provide a static list of videomodes (that could be 
an "offline" dump of the EDID data). However, the driver could take the 
decision to use it if the EDID bus is not specified in the DT or if 
transfer failed for some reason.

But then as you mention we might as well save time and directly serve 
that offline version, since we know the content of the EEPROM anyway.

Alex.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/