Messages in this thread | | | Date | Wed, 14 Jul 2004 23:14:39 +0400 | From | Andrew Zabolotny <> | Subject | Re: Backlight and LCD module patches [1] |
| |
On Tue, 13 Jul 2004 23:11:38 -0700 Greg KH <greg@kroah.com> wrote:
> > It's not a question of b/l driver needing the framebuffer driver; it's the > > other way around: the framebuffer driver needs the b/l drivers (needs so > > much that it can fail initialization in some cases if it doesn't find the > > corresponding b/l device). > Ok, then put a pointer in the fb driver to the backlight. > And a pointer in the backlight to the fb. What's wrong with that? Then arises the same question, but upside down. How the backlight driver will find the corresponding framebuffer device to put a pointer to himself into?
For example, mediaq 11xx chip can be connected to the PCI bus (apart from the fact that it can be connected to embedded CPUs directly), so suppose there are several PCI cards, every card has a LCD connected to it. Now you have a bl/lcd driver that can drive those LCDs; how you can know which LCD is connected to which framebuffer? You will have to do the same: examine the device structure and find the PCI device id, slot number and such - there are simply no other ways.
So I basically propose the same way - but unified from the bl/lcd driver perspective: bl/lcd looks at the framebuffer device structure and decides if it corresponds to the respective device or not. But this operation is initiated by the framebuffer device, not by bl/lcd, since the bl/lcd infrastructure already has a list of all bl/lcd drivers.
-- Greetings, Andrew - 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/
| |