Re: [PATCH] PXA255 LCD Driver

3 messages, 3 authors, 2004-03-25 · open the first message on its own page

Re: [PATCH] PXA255 LCD Driver

From: Russell King <hidden>
Date: 2004-03-18 20:36:56

On Wed, Mar 17, 2004 at 07:03:06PM +0000, James Simmons wrote:
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.
You're thinking too PC-centric.  You don't get EDID data with embedded
LCD panels.  Instead, you get timing information, number of pixels per
line, and other parameters either from a PDF or paper datasheet on the
device.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


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

Re: [PATCH] PXA255 LCD Driver

From: James Simmons <hidden>
Date: 2004-03-19 23:52:49

On Wed, Mar 17, 2004 at 07:03:06PM +0000, James Simmons wrote:
quoted
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.
You're thinking too PC-centric.  You don't get EDID data with embedded
LCD panels.  Instead, you get timing information, number of pixels per
line, and other parameters either from a PDF or paper datasheet on the
device.
Your right. Want I would like to know is what do you guys need!!!





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

Re: [PATCH] PXA255 LCD Driver

From: Ian Campbell <hidden>
Date: 2004-03-25 17:22:56

Hi James and others,

I've been playing with trying to get something which uses fb_monspecs
put together. The patch is littered with FIXME, TODO and debugging cruft
but it seems to work for the two panels I have bothered to put in the
LCD DB. If the general approach is satisfactory for you I will look at
tidying it up and making everything work properly. I'm not sure about
the aesthetics physical_interface stuff in fb_monspecs but that can be
changed as you wish. Perhaps a ->type field + a union to cover
MONITOR/TFT/STN in a space efficient manner?? I'm not sure what sort of
API/ABI guarentees are being made for fb_monspecs and fb_videomode at
this time.

I couldn't find suitable places for a few settings. They are commented
in fb.h (and hardcoded for now in pxafb). The settings are the bit depth
and some color map stuff.

I'm not happy with the way the fb_videomode and the fb_monspecs are
separated in lcddb.c. I'm not sure if there is syntax in C to allow me
to put the pointer to fb_videomode inline in the fb_monspecs
declaration. Perhaps I will define a datatype fb_lcd_info which is
roughly the same as the commented out stuff in
include/asm-arm/arch-pxa/pxafb.h and have fb_lcd_lookup construct the
fb_monspec with dynamically allocated fb_videomode from that (which
might be best anyway, since other code looks like it might expect the
modedb to be dynamically allocated).

My only thought is that having done that, perhaps it makes sense to
dispense with the fb_monspecs stuff and have drivers use fb_lcd_info
directly. What does using fb_monspecs gain us over this scenario? 

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help