On Fri, 2007-12-21 at 10:39 +0100, Harald Welte wrote: > On Fri, Dec 21, 2007 at 12:01:11AM +0000, Richard Purdie wrote: > > Backlights and lcd controllers mainly reside in drivers/video/backlight > > although there are a number of backlight drivers spread about the tree. > > well, there alsi is drivers/video/display now, which is where I have put > my driver now. However, I'm not using the DISPLAY_CLASS, since it seems > to deal mainly with contrast settings. > > > I'm not sure the LCD class would be very helpful to this driver. As you > > say, this really suggests shortcomings of the LCD class but with only > > one LCD driver in mainline changing that class to work better for LCDs > > is possible. > > > > The main question is whether the functionality here is suitably generic > > to turn into a class? Personally I'm not sure it is but I'm open to > > opinions (and patches). > > I think the power states and configuration parameters of different TFT > panels (in embedded devices) are fairly device-specific. Even the power > states of different panels can differ a lot. So I don't know how much > common abstrction is possible to implement.
Agreed, I'm not sure how much common ground there is either. > One thing that we still need for the Neo1973 is some kind of interaction > betwee the display driver and the framebuffer driver. The issue is that > if we change the framebuffer resolution from VGA to QVGA, the display > driver needs to alter the timing configuration of the display ASIC. I had this problem with the Zaurus and ended up with arch/arm/mach-pxa/corgi_lcd.c. It has two different mechanisms for connecting into w100fb and pxafb. I would like to see a common method for doing this and would be happy to change the corgi code to some kind of common framework. A problem, at least with w100fb was that the ordering of the calls to the LCD and w100 were quite critical, one wrong move and it doesn't work... > I was thinking of something abstact like a notifier_chain for resolution > changes. This way the display driver (and other potential users) can > get informed about resolution changes. In the w100 case we ended up with change(), suspend() and resume() function pointers. A call notifier could do the same job though. For pxafb its just a case of LCD on/off... > And then, after all, we have the issue of backlight, display and > framebuffer all together. If you want to blank the screen, you would > want to switch off the backlight, but also put the display into a > lower-power mode. Right now we're not doing any of this in the kenrel, > but I believe we definitely should. Any suggestions on that? The backlight class does have a hook into the framebuffer blank call notifier chain (see drivers/video/backlight.c:fb_notifier_callback()) and this works very effectively. The LCD class does also power down when the display is blanked through a similar mechanism. One tricky problem here is working out which blank call belongs to which display. In the end I left this problem to the driver though the "check_fb" function pointer. On a device with a single display there is no problem... Adding a resolution change notifier chain does sound good, the LCD class could then at least become useful for turning the LCD on/off and blanking + resolution change notification. Cheers, Richard ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
