On Wed, Nov 14, 2012 at 01:56:45PM +0800, Mark Zhang wrote: > On 11/14/2012 01:36 PM, Alex Courbot wrote: > > On Wednesday 14 November 2012 00:46:52 Stephen Warren wrote: > >> I do tend to think that we should use EDID where there is one. > >> > >> 1) If there is an EDID in the panel HW, and the panel's I2C is hooked > >> up to Tegra, we should read it out at runtime. > > > > According to Ventana' platform design guide the LCD panel is hooked on I2C2. > > The panel's data sheet lists CLK_EDID and DATA_EDID pins, which I assume are > > for I2C, but there is no mention of an I2C address in both guides. > > > > Normally the address is 0x50. Take a look at function > "drm_do_probe_ddc_edid" as a reference. > > >> 2) Otherwise, if the panel's documentation provides an EDID, we should > >> use that, since it's the most canonical/common/standard representation > >> of the panel's properties. > > > > Panel's documentation indeed provides full EDID specification in appendix. Mark > > sent me an EDID blob which works but I don't know where it comes from - Mark, > > could you tell us? > > > > Actually I use a tool named "i2cget" to get this 128 bytes EDID. For > Ventana, I use a script like this: > > for i in $(seq 0 127) > do > #echo " Reading byte no : $i " > i2cget -y 0 0x50 $i | xxd -r -p >> tegra20-ventana.edid > done There is also i2cdump but I suppose for writing the data into a binary file it isn't as well suited as the above loop. I seem to remember a tool that could be used to dump EDID directly, but I can't get a fix on the name. Anyway, if you can get the EDID data that way it should also be possible to get it directly within tegra-drm. Thierry
Attachment:
pgpGqnfPCetP_.pgp
Description: PGP signature
