Re: [PATCH] PXA255 LCD Driver
From: James Simmons (jsimmons_at_infradead.org)
Date: 03/20/04
- Previous message: Bartlomiej Zolnierkiewicz: "Re: [PATCH] barrier patch set"
- In reply to: Ian Campbell: "Re: [PATCH] PXA255 LCD Driver"
- Next in thread: Russell King: "Re: [PATCH] PXA255 LCD Driver"
- Reply: Russell King: "Re: [PATCH] PXA255 LCD Driver"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 20 Mar 2004 00:01:03 +0000 (GMT) To: Ian Campbell <icampbell@arcom.com>
> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Bartlomiej Zolnierkiewicz: "Re: [PATCH] barrier patch set"
- In reply to: Ian Campbell: "Re: [PATCH] PXA255 LCD Driver"
- Next in thread: Russell King: "Re: [PATCH] PXA255 LCD Driver"
- Reply: Russell King: "Re: [PATCH] PXA255 LCD Driver"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
