On Wed, Feb 2, 2011 at 9:30 AM, Luke Kenneth Casson Leighton <luke.leighton@xxxxxxxxx> wrote: > On Wed, Feb 2, 2011 at 1:41 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote: >>> ÂARM CPUs don't have the concept of a BIOS, so the screen timings are >>> hard-coded into the kernel driver. Âyou *can't* just whop a new screen >>> in and expect it to work, you *have* to recompile the kernel, >>> hard-coding the hsync, vsync, offsets, hclock, vclock, pixel rate, >>> pixel density *everything*. >> >> So, I should blame the kernel for not reading the EDID on the panel? > > Âthe EDID data is generally completely ignored by the linux kernel for > LCD panels, in embedded systems. Âit's only typically when that panel > ends up in an LCD monitor and shoved over DVI, HDMI or VGA by virtue > of the IC controller chip having the necessary I2C logic that EDID > data ends up being read. Âbut in embedded systems, changing the LCD > panel _just_ doesn't happen, and the linux kernel source code for such > devices typically reflects this by having the panel's settings > hard-coded in. > > Âso... yes :) No, Luke. This is a complete misconception. Most panels have EDID data that is perfectly valid. Not reading the EDID is laziness. 99% of embedded panels expose the DDC lines to the host - you just wire up an i2c controller. It is not common for the panel controller (either LVDS or TMDS or whatever) to arbitrate access to the i2c bus used for DDC except when HDCP is required (and accessing DDC data is a violation of the security framework). Embedded systems that have anything approaching a VGA sized panel should be reading the EDID, but most devices *never* accept more than one panel. In this case reading the EDID is redundant. Some developers consider it a waste of time to plug in the one mode supported from the EDID when they can copy the data from the spec sheet. In the event a different panel is used, the EDID is the sole, only way of differentiating between panels without additional hardware support or having a kernel for each panel. >> If you're right, then a >> 720p panel may not be implausible. But my understanding is that the screen >> gets setup by the boot loader, and the Tegra FB driver just works based on >> that, it doesn't configure anything itself. > > Âhmmm, that sounds about right. Âand if you don't mind a bit of > "bzzzt" and not being able to see anything during the boot process, > you should be able to overwrite whatever crud settings the bootloader > decided to set, once you've started the linux kernel. The screen on the Smartbook is set up by the MTL017 driver. It's been coded in Taiwan so it hardcodes the MTL017 configuration as an unhealthy block of 256 byte values and just hammers the chip with it. Genesi accepts that it is godawful way to do it and we are not happy with the code we were provided with. But it does read the EDID so it knows what panel data to send depending on the panel attached via the EDID. We're rewriting it to use the EDID properly here. -- Matt _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
