lkml.org 
[lkml]   [2004]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Backlight and LCD module patches [2]
On 07/30/04 15:02:05, Andrew Zabolotny wrote:
> On Thu, 29 Jul 2004 19:49:50 -0500
> John Lenz <jelenz@students.wisc.edu> wrote:
>
> > The only problem is that what happens if the fb device is registered before
> > the lcd device? So that means you still need to keep around a list of fb
> > devices that have been registered so that when a new lcd device is
> > registered it can check if it matches an old fb device.
> Right now it happens in a different way. The patch I've published earlier uses
> notifier objects (linux/notifier.h) so that if framebuffer can't find the
> matched lcd device, it registers to be notified when new lcd devices appear in
> the system; when it does it proceeds like usual (e.g. calls lcd_device_find).
> Until it finds the LCD device framebuffer device cannot even initialize
> (without powering on the LCD controller in some circumstances it's impossible
> to do anything useful).

I could see it going either way I guess. The other thing the class_match could
do is create those symlinks from the two classes of devices. What other way is
there from userspace to see which lcd device is associated with fb device?

>
> > The only advantage is we let the core class code take care of managing the 2
> > lists of devices for us (which it is doing anyway).
> These lists are anyway maintained by the class.c core. You just need a pointer
> to the 'struct class' variable for classes you are interested in, and locking
> also comes for free - everything is already implemented. Look in class.c for
> list_for_each_entry macros - they all are traveling along these lists.

Yea I see that, but I was trying to keep all the class related code contained in
class.c I feel kinda uncomfortable manipulating lists and locking locks in
struct class from outside code.

>
> I personally don't like to make this device matching too generalized - if we
> need it for b/l, that's fine, we'll have to implement it for b/l.
> But it doesn't look too sane, so I'd rather leave it l/b specific.
>

Why not? I see it as a simple extension of the class_interface stuff... it
could even use the class_interface to implement class_match (or use
class_interface directly in the lcdbase.c code and forget the class_match stuff).

Now I could see both solutions as workable and either one or even a bunch more
could work for the lcd/fb matching. Now the question is, which one to implement?
Or actually, the question is, which one is more likely to be accepted into the
kernel?

The way I see it, we really need a policy decision here, and neither you nor I
are "authorized" to make that decision :) We have two completly seperate devices,
both have a struct device and both have a struct device_driver. They can sit on
completly seperate buses and be mixed together in lots of different combinations.
One of the devices "knows" if it matches with the other device.

What is the linux preferred way to dynamicly match the two devices together? Should
each driver pair make its own decisions and its own constructs, or should we try and
extend the device/driver/class/bus/etc model to support matching two devices together?
Use waitqueues and probe functions? notify.h? match by a char *name? class_match?
class_interface? create a virtual bus and use the bus matching code (not a very good
solution, but one nonetheless)? Secondly, what is the best way to represent this
matching to userspace (sysfs)?

We already tried matching together devices by their name, and that was shot down.
And yet the mtd code matches chips and maps together by their name... We haven't
really gotten much feedback in which ways of matching devices together is acceptable
and which isn't.

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

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.100 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site