Message-ID: <CAPweEDzQXUTtAwiU4qEB_eQqNgJeazpeTxixyAnbgscvC5yujQ@mail.gmail.com>
Date:	Mon, 25 Jul 2011 13:40:38 +0100
From:	Luke Kenneth Casson Leighton <lkcl@...l.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	debian-arm@...ts.debian.org, linux-kernel@...r.kernel.org,
	Wookey <wookey@...kware.org>
Subject: Re: dynamic LCD support for "embedded" systems

On Mon, Jul 25, 2011 at 1:17 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>>  ok, so.  does anyone on LKML happen to know if there exists in the
>> linux kernel a method for dynamic detection and booting off of
>> absolutely any type of LCD panel?  even if it's a predefined list of
>> say 10 quotes supported quotes static LCD panels?
>
> It depends entirely on the platform, the interconnect, the panel and the
> controller. You may have a way of probing it, but even on a PC in a lot
> of cases the knowledge is actually in the firmware not in the panel
> itself. In some cases the relationship is even more incestuous (eg look
> at some of the MIPI drivers).

 euurgh, inspire me with confidence, why not? :)  yes, virtually every
datasheet for an RGB/TTL LCD panel i've looked at has EDID data which
is typically accessible over an I2C bus.  hilariously (ok maybe not)
i've heard of manufacturers getting this data wrong.  then, you
_still_ need some offsets (the Horizontal and Vertical tuning which
you simply don't have on an embedded LCD panel - there's no buttons
and no adjustment menu on an embedded system!)

 ... but, think about it: that LCD panel goes into a VGA monitor (or
DVI monitor), and that EDID data just gets passed-through via the VGA
IC. so it's all the same stuff... so what's the damn difference
between a system with a VGA monitor and a system with the exact same
LCD panel *from* that VGA monitor, ehn? :)  ok, rhetorical question.

 so, basically, unless you absorb the capabilities of a VGA monitor
*into* the linux kernel and/or the OS running on top of it (think of
that menu system on a VGA monitor), as well as the capabilities
normally offered by a PC "BIOS", true "dynamic" LCD capabilities on an
embedded system - to adapt to literally any LCD panel - are a
pipe-dream.

 so *sigh* that means having a list of static pre-arranged data
structures associated with pre-vetted pre-tested LCD panels (and
identifying them correctly).

> Well really the panel belongs in devicetree. That would I think sort much
> of the mess out.

 *lol* yehhs... drag hundreds of chinese tablet manufacturers kicking
and screaming into the C21st^H^H^H^H^H device tree era - oh god i hope
it's not 2.4 kernel all over again [note for people who may not be
aware: in the embedded world, the 2.4 linux kernel, especially the
2.4.18 and 2.4.20 ones, had a massively extended lifetime because of a
significant performance drop, and increases in compiled size and also
resident memory usage over the 2.6 kernel.  2.4 kernels could be 600k
compiled whilst 2.6 with the exact same options came out at 900k]

 but seriously: i talked with david (from linaro) a few months back,
and he mentioned what the aims of devicetree are, and yes i believe
it's an excellent technical solution, into which something like
dynamic LCD panel startup would fit very well.

 oh.

 wait.

 i have an idea.

 devicetree LCD modules.  these could still be dynamically loaded,
right?  i mean, it's a bit crazy, but you could have associated with a
particular LCD panel a devicetree-compliant dynamic loaded module
which had the correct LCD settings (including the required pre-tested
hsync and vsync data), right?

 thanks alain.

 l.
--
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/

Powered by blists - more mailing lists