Attached is a patch against the most recent BK tree which implements a
driver for the on-chip LCD controller of the Xscale PXA255 processor. It
is based on the SA1100 FB driver and has been hacked on by various
people on the ARM mailing list.
I would appreciate a review of the code, any comments etc, with the aim
of getting the driver into good shape to be merged.
Not much comments, except: why don't you use the standard modedb mode parameter
style?
I posted it to the fbdev list @ sf.net (from MAINTAINERS) but that list
seems to be pretty quiet and www.linux-fbdev.org (also from MAINTAINERS)
It's not quiet, though.
seems to be down -- is there a more appropriate place these days for
framebuffer stuff?
linux-fbdev-devel was correct.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Not much comments, except: why don't you use the standard modedb mode parameter
style?
I was trying too (I mostly copied the i810 driver). How wrong did I get
it? I'm willing to rework it to make it the same as the standard.
quoted
I posted it to the fbdev list @ sf.net (from MAINTAINERS) but that list
seems to be pretty quiet and www.linux-fbdev.org (also from MAINTAINERS)
It's not quiet, though.
OK, I just hadn't seen many messages since I subscribed...
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
Not much comments, except: why don't you use the standard modedb mode parameter
style?
I was trying too (I mostly copied the i810 driver). How wrong did I get
it? I'm willing to rework it to make it the same as the standard.
Take a look at drivers/video/modedb.c and fb_find_mode().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
From: Ian Campbell <hidden> Date: 2004-03-17 12:05:02
quoted
I was trying too (I mostly copied the i810 driver). How wrong did I get
it? I'm willing to rework it to make it the same as the standard.
Take a look at drivers/video/modedb.c and fb_find_mode().
Ah, I had seen that, but it doesn't seem to be very appropriate for an
LCD controller in an embedded environment. TFT and STN (STN in
particular) displays don't often fit into any of the standard mode
definitions. There's also several settings which aren't in the DB, such
as pixel clock polarity, dual vs. single panel STN etc.
I quite often get asked to make some arbitrary panel which a customer
picked up somewhere dirt cheap to work, it is very useful to be able to
give each of the parameters explicitly, even if they do not correspond
to a mode listed in the DB.
I could make the code use the same XRESxYRES-DEPTH syntax though since
the 2.4 version did (by copying the parsing code from fb_find_mode()), I
just changed it to match i810fb for the 2.6 port.
I had considered extending the modedb stuff to support the requirements
of embedded LCD controller drivers and to encompass a db of LCD panels
by part number (Kconfig selectable, something like the NLS support
perhaps) containing the extra options that you can have -- but I wasn't
sure if it was something that would be useful only to me or to all
embedded LCD driver authors.
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been checked for all viruses by MessageLabs Virus Control Centre.
From: James Simmons <hidden> Date: 2004-03-17 19:03:19
quoted
quoted
I was trying too (I mostly copied the i810 driver). How wrong did I get
it? I'm willing to rework it to make it the same as the standard.
Take a look at drivers/video/modedb.c and fb_find_mode().
Ah, I had seen that, but it doesn't seem to be very appropriate for an
LCD controller in an embedded environment. TFT and STN (STN in
particular) displays don't often fit into any of the standard mode
definitions. There's also several settings which aren't in the DB, such
as pixel clock polarity, dual vs. single panel STN etc.
The way to handle different types of displays, LCD, CRT etc has
improved greatly in the latest 2.6.X kernels. You don't need to lock yourself
into the standard modedb database. Also modedb is used only for selecting a
particular resolution. The structure used to define the display panels
behavior is struct fb_monspecs. Take a look at it in fb.h. I'm interested
if I got all the needed data from the EDID about a display panel.
Here is basically what you have to do to handle mode setting:
1) Does the displaying hardware tell you data about itself? You have to
ask yourself can I get display hardware information. If it does
what format is it in. In most hardware today you can get data about the
display hardware in a EDID block format. Usually that data is retrieved
via i2c. Fbdev driver writers must write the code handling getting the
display hardware's data. Once you have the EDID data block you can use
already written functions to parse the EDID block.
If you display hardware does not use EDID format then the driver
writer must parse the data himself. What data needs to get generated?
This is covered next.
2) Attempt to generate the struct fb_monspecs data. Now it is not a
absolute requirement but it sure does help. There is one per physical
display. This means for cases like laptops you can have one framebuffer's
data being displayed on two physical displays (attached CRT and the LCD
panel). In this case you would have two struct fb_monspecs per struct
fb_info. When you are going to change the video mode you would have to
valid the new mode against BOTH physical displays. In fact you can get
a bunch of crazy combo's. The important part is that use generate a
fb_monospec if possible.
Note that fb_monospec has a mode database in its data structure.
Sometimes the display hardware will tell use what the "best" video
modes are for it. Also some display hardware is limited in what it can
be allow to display. SO those modes are the only ones that actually
work.
Now back to the EDID case. There is a global function that will get
the monitor limits for you. This function will also build you your
modedb for you!!!
fb_get_monitor_limits(unsigned char *edid, struct fb_monspecs *specs)
Again what if we don't use EDID. Well if you can get the display
hardware information in some way it is in your best interest to create
a struct fb_monspec and also the modedb attached to it. What if you
can't get supported modes to build a database but you can get the monitor
limits? Here are your options.
I. Build your own modedb from stratch.
II. Use the standard vesa database if hooking up to a standard vesa
display.
III. Don't use a database. We have a function, fb_get_mode in fbmon.c,
that generates modes on the fly based on GTF formulas. Note this
function can generate modes without fb_monspecs but it will be
severally handicapped modes.
Now if you can't get neither fb_monspecs or modedb data you still can
use the above options.
3) Okay now we "might" have our monitor data and our modedb. If we have to
ask ourselves does the hardware allow the change of the resolution? If
it doesn't then why do we generate a fb_monospec or a modedb. Because
that data can be very useful to userland :-) If this is the case you
can call fb_find_mode on your modedb if you have one and return the
default struct fb_var_screeninfo that we need. If you don't have a
modedb you still need to supply a default struct fb_var_screeninfo that
represents the display resolution. Also you could have the case where
you swap about the display. In this case you might want to create a new
fb_monospec and update your var data even if you don't change your
resolution. Now we are done. If you hardware can change modes then
continue on.
3) Now what to do for when we want to set the graphics display. Before we
consider the monitor we have to see if the new resolution request is
complete. Not every fb_var_screeninfo request is complete. Often the user
only is concern with xres, yres and bpp. That is it. Alot of data is
missing. This is bug in many drivers that they don't fill in that data
thus often when the user tried to change the resolution they ended up
with a blank screen. So how do we deal with it?
4) First we can use a modedb we have to find the best fit. If not use the
function fb_get_mode in fbmon.c.
5) Now that we have the purposed mode we call the function
fb_validate_mode(const struct fb_var_screeninfo *var, struct fb_info *info)
This tells us if the requested video mode is to much for our display
hardware to handle.
6) If the monitor can handle it we call the drivers xxxfb_check_var
function to see if the graphics chip can handle the mode.
I hope that answers your question. Now that I wrote this I'm going to make
it apart of the documenation in the kernel for a driver how to.
From: Ian Campbell <hidden> Date: 2004-03-18 11:05:42
Hi James (and everyone),
The way to handle different types of displays, LCD, CRT etc has
improved greatly in the latest 2.6.X kernels. You don't need to lock yourself
into the standard modedb database. Also modedb is used only for selecting a
particular resolution. The structure used to define the display panels
behavior is struct fb_monspecs. Take a look at it in fb.h. I'm interested
if I got all the needed data from the EDID about a display panel.
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.
If I explain what the situation is with the PXA LCD controller perhaps
you can give me some advice onto how I can massage this into the current
system, or extend the system to my needs.
Essentially the LCD controller<->panel interface has 16 data pins, an
output enable, a pixel clock and (HV)sync. There is nothing
'intelligent' in the controller, it needs to be told explicitly how it
should manage these pins. The settings depend on the panel you have
attached and there is no way to automatically derive them, the panel is
not like a monitor really, it just shifts in pixel data on each clock
pulse and puts it on the display.
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...
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).
Because the driver is often used in an embedded environment the settings
are often hardcoded at compile time.
My problem is that I need to support Arcom's development kits, which a
customer might plug just about any TFT or STN panel into, so I need to
be able to control all of the above settings from the command line or
module parameters, or to pass in something like the LCD part # and have
the settings looked up from a DB. However I would like to keep the
overhead for others who just want a single static panel to be as small
as possible.
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).
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been checked for all viruses by MessageLabs Virus Control Centre.
From: James Simmons <hidden> Date: 2004-03-20 00:01:12
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
From: Ian Campbell <hidden> Date: 2004-03-20 11:24:53
Is this the case for your setup or is this something true in general.
I'm not entirely sure -- I know it's true in my case, I have a feeling
it's true in general (apart from things like the CPLDs that Russell
mentioned).
I like to add data fields that could be used by everyone.
I totally agree -- as I said in my reply to Russell I don't want to come
up with a solution which is only useful to me!
Are these the fields you need in general?
I believe so -- although as I said I'm not 100% about it. I really need
input from people who have experience with lcd controllers on other
architectures than StrongArm and XScale.
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?
It sounds great, if we can work out which extra settings are needed
Ian.
--
Ian Campbell
-------------------------------------------------------
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