Re: [PATCH] PXA255 LCD Driver

I understand what you are saying (I think...), but I'm not sure how it
applies to my situation -- my embedded LCD controller has no analogue
for much of the stuff in fb_monspecs and has some extra stuff which are
not present there.

What is it you need exactly? 

Essentially the LCD controller<->panel interface has 16 data pins, an
output enable, a pixel clock and (HV)sync. 

Is this the case for your setup or is this something true in general.
I like to add data fields that could be used by everyone.
 

The settings which are of interest on a PXA255 are that aren't present
in fb_monspecs, they specify the physical interface between the
processor and the panel:

        active(==TFT) or passive(==STN), 
                These are two fundamentally different types of panel. It
                impacts when the pixclock ticks (all the time or just
                when data is present), and some other timing stuff.

        output enable polarity
                panel is enabled on low or high
        pixel clock polarity
                should the panel shift in data on a rising or a falling
                edge
	dual or single panel
                some STN panels are physically two panels stacked on top
                of each other, this impacts the way pixel data is packed
                onto the data lines
        4pix or 8pix STN mono
                Monochrome STN panels take either 4 or 8 pixels at a
                time.

All of these differ from panel to panel, pretty much at the whim of the
manufacturer...

Are these the fields you need in general?

The other settings I think are already accounted for in the mode db:
        resolution, bit depth, color/mono/grayscale, pixel clock, h and
        vsync length, Left-Right-Upper-Lower margins.
However -- all these are fixed in hardware for any given panel (although
you could emulate different resolutions in s/w I guess).

... snip ...

I also don't know how applicable all this is to other embedded LCD
controllers --- the StrongArm hardware is very close to the PXA
hardware, and I think all controllers which are as low level as them
will share the same settings (since they are down to the hardware
interface). I don't know for sure though.

My thinking prior to this discussion was to go for a database which maps
LCD part # to all the settings above, where each LCD is selectable from
Kconfig and a default can be specified (sort of like NLS now). People
with a static panel would only build in the one database entry, people
like me could build in a selection and choose from the command line etc
(with overrides for all the above). 

I have thought about it. That is why I toke so long to reply. I think the 
best approach is that we create a database of struct fb_monspecs for LCD
panels. In struct fb_monspecs we have the following fields.

manufacturer[4]
monitor[14]
serial_no[14]
ascii[14]	For expansion.

We can have it so that we can pass in a monitor string that can be used to 
select the proper LCD panel in the database. How does that sound?












-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click