Re: radeon-pre-2

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
> My personal preference for this whole mess has always been the "silly 
> driver" that isn't even hardware-specific, and really does _nothing_ on 
> its own. This one would be the only thing that actually reserves the IO 
> regions and "owns" the card from the respect of the resources. EVERYBODY 
> else would be a "stealth" driver. Not just DRM.

How do you plan to deal with hot plug. At the point the "silly driver"
(in my case this is the vga class driver) claims the PCI device and
propogates things onwards hotplug seems to work.

The second fun bit is that Jon is right that in some cases the fb driver
for a card may want to use the DRI layer if loaded - but only some and
only in a controlled manner. Sometimes the drivers want to co-operate
sometimes they just want to avoid beating each other senseless.

>    Now, the reason why these things are _pointers_ to locks rather than 
>    locks themselves is that maybe some hardware ends up sharing resources 
>    between these things (maybe "modeswitch" needs the accelerator to 

How do you deal with making sure the lock doesn't get freed and knowing
who needs it still ? I ended up with locks in the shared area itself
because I couldn't figure that one out ?

>  - memory allocation. Many of these issues really are generic, and once 
>    you have the locking setup done, maybe you can have a generic memory
>    allocation layer for splitting up AGP memory or whatever. See the 
>    "dma_declare_coherent_memory()" interfaces that James Bottomley did for 
>    some SCSI devices that have on-board memory that they want to let the 
>    kernel allocate as DMA'able.

I think allocation is genuinely a hard problem in the 3D card case. Some
devices have the most wonderful restrictions on layout that range
from "the frame buffer is here" to "I want 2Mb, 1Mb aligned within a 4Mb
range and you can free this stuff if you notify me but its not
textures". Multihead really makes this interesting and DRI itself
doesn't really address this problem either.

Linus let me run what I have now past you for comment (the code isnt
working yet since I've been having a fight with the class code)

The vga_class module registers itself as the owner of every VGA class
device on the PCI bus. The PCI layer duely gives it all the video
hotplug events.

On creation it creates a set of (currently 3) vga bus objects for each
card. So if we find say a Voodoo 3, we will create vga bus objects

		Voodoo 3 memory manager
		Voodoo 3 DRI
		Voodoo 3 Frame buffer 0

(for now. Quite possibly mode management is separate, maybe memory 
 manager eventually will or will not be)

and stick them onto global and per vga router lists.

vga_register_driver works like PCI register driver but also takes a 
"type" field and will attach to the appropriate one of the 3 objects,
detach on hotplug and all the rest as the base/* code provides.

When you attach or detach you get a notifier to the other members that
are loaded.

Finally there is a shared structure between the different vga bus
objects for each video card which allows you to find one function from
another (maybe the notifiers should pass these) and also a semaphore.