> > > Why do we want this?
> > >
> > > Currently the kernel cannot provide both the fb and drm drivers with
> > > access to the device model and this means the drm cannot get any
> > > suspend/resume callbacks. This layer attempts to fix this problem by
> > > adding a bus for the gpu drivers to attach to. Currently a lowlevel
> > > binding driver is needed along with optional fb and drm components.
> >
> > If we were to allow this kind of "sharing" for all PCI devices would
> > that work out instead? Or would this layer still be needed?
>
> Initially this layer wouldn't be needed, but I'd like to add some
> awareness to the drivers, so the drm can tell the fb to stop doing
> stuff and vice-versa if necessary.... but perhaps that could be done
> with a generic layer also.. or via the lowlevel driver I have...
I have a idea. Greg asked me to move my display class away from the
class_device method. One of the nice things about using
class_device_register is that it handles all the attributes for you :-)
So while going throught the core code for device handling I discovered
that struct device has a struct class. I found it alot easier to have
class field in the device point to the class you want to use. With
device registeration the class is setup up for you.
The idea was to have the a linked list of classes inside of
struct device. Then have a way to register/unregister that class with
the device. This way struct device and struct device_driver are per
hardware but struct class could be used to handle different interfaces
to that same hardware. What do you think? I could do a example with
hardware that registers a fbdev drivers as well as a backlight. Plus
nobody is using the class field in struct device at this time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
