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 :) > Can you > point me at the relevant bit of the kernel code? aw gawd come on, gordan :) > 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 tegra fb kernel driver _should_ be setting them anyway. > If that is the case, then the > boot loader itself would likely need to be reconfigured, or the TegraFB > driver taught to configure the display geometry. yyep. > The latter may be difficult > given that nvidia aren't exactly renowned for publishing their specs. it's nothing to do with nvidia, and everything to do with the timings of the LCD. ahh, i see what you mean, you'd need to know where the registers are for blopping in the hsync, vsync etc. etc. timings. yep, you're right. *sigh* that'll need investigating. ok - start here. https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi >> /dev/mmcblk0p6. Âget the external boot working first otherwise you'll >> be left without a means to recover after blowing away mmcblk0p6 ;) > > Yes, I know how it works. :) ah goood :) _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
