From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smirl Date: Sat, 02 Jul 2005 13:34:33 +0000 Subject: Re: sysdev_class use from DRM Message-Id: <9e4733910507020634c3559d9@mail.gmail.com> List-Id: References: <9e473391050624071263dfbea7@mail.gmail.com> In-Reply-To: <9e473391050624071263dfbea7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On 7/2/05, Greg KH wrote: > On Fri, Jul 01, 2005 at 07:18:08PM -0400, Jon Smirl wrote: > > On 7/1/05, Greg KH 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. >=20 > {sigh} there always is... >=20 > >=20 > 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: >=20 > register_my_driver(struct pci_driver *drv) > { > /* add drv to list of drivers that want to use this hardware */ > } >=20 >=20 > struct pci_driver foo =3D { > .owner =3D THIS_MODULE, > .name =3D "foo_video_multiplexor", > .id_table =3D all_foo_ids_combined, > .probe =3D foo_probe, > .suspend =3D foo_suspend, > ... > }; >=20 > 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. --=20 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=16492&op=CCk _______________________________________________ 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