[Arm-netbook] [fedora-arm] 1ghz ARM Laptop (12in 1280x800 LCD)

[Luke Kenneth Casson Leighton]

On Wed, Feb 2, 2011 at 1:41 PM, Gordan Bobic <gordan at bobich.net> 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 :)