Re: [PATCH] PXA255 LCD Driver

[James Simmons]

> 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?










-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/