Re: sysdev_class use from DRM

[Jon Smirl <jonsmirl@gmail.com>]

On 7/2/05, Greg KH <greg@kroah.com> wrote:
> On Fri, Jul 01, 2005 at 07:18:08PM -0400, Jon Smirl wrote:
> > On 7/1/05, Greg KH <greg@kroah.com> wrote:
> > > Last kernel summit I thought this was all hashed out.  I guess the
> > > people not there didn't agree...
> >
> > There are more layers to the problem.
> 
> {sigh}  there always is...
> 
> <good reasons snipped>
> 
> What about starting small, with just the pci driver functions, and going
> on from there.  That way you all can still fight it out over the
> different details, and I'll be happy that you play nice with the driver
> core.  Something as simple as:
> 
> register_my_driver(struct pci_driver *drv)
> {
>         /* add drv to list of drivers that want to use this hardware */
> }
> 
> 
> struct pci_driver foo = {
>         .owner = THIS_MODULE,
>         .name = "foo_video_multiplexor",
>         .id_table = all_foo_ids_combined,
>         .probe = foo_probe,
>         .suspend = foo_suspend,
>         ...
> };
> 
> static int foo_probe(struct pci_dev *dev, id)
> {
>         for (all drivers registered with me)
>                 drv->probe(dev, id);
> }

That is the pure architecture scheme of a small base driver. It
doesn't do anything for the fact that some of the drivers are
programming the chips in incompatible ways. Also each driver will
initialize the chip and format things the way they want to since they
will all assume no other driver is going to be loaded. Another example
is interrupts, with the thin base all of the drivers will each ACK the
interrupts and we have several drivers trying to service the same
interrupts.

GPUs have two basic modes - 2D programmed IO, and DMA based drawing.
fbdev will put it into 2D mode, DRM into DMA mode.

My approach is to make fbdev the base layer. fbdev will initialize the
chip and attach/ACK the interrupts. I then have to disable/remove
fbdev acceleration since it uses the chip in a conflicting way with
DRM. DRM then hooks into fbdev in a coordinated way.

Nothing can protect from the current X server coming in and
programming everything from user space. On VT swap the friendly X
server walks the PCI bus and disables the IO/MEM space of all VGA
adapters that it does not own. Guess what happens if my driver has an
interrupt while X has disabled it's ability to write to the interrupt
ACK register. Remember, the rules on VT swap are that you can do
anything you want to the hardware including resetting or disabling it.

There definitely should be a huge kernel rule that no future driver
that does not attach to a device will be accepted. That would have
blocked the current DRM from getting in and forced a merger long ago.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel