Re: radeon-pre-2

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

On Llu, 2004-09-13 at 16:06, Jon Smirl wrote:
> It also needs something to sort out both drivers using pci_drvdata()
> to get to their private data. For example in the hotplug routines you
> only get passed a pdev and you want to use that to locate your private
> data.

The hotplug routines for vga objects in the code I posted get passed
vga_dev objects. You can put what you like in those. I guessed at 
"memory manager" "dri" and "framebuffer0" being the ones to create for
now but we can invent anything thats more appropriate.

> It also needs to track pci_enable_device() so that if one driver
> unloads it won't turn the device off for the other driver.

The ->remove function is passed the number of remaining clients for
exactly this reason. We could move the resource grabbing up the tree.
IRQ handling is rather harder. Quiescing and handing back the IRQ on
lock loss is ugggggggggly so I want to think about it - it works but its
not nice.

Should pci_enable and friends be done by the vga class driver- it can do
this and it would have to do it if it did the hotplug ?

> VGA routing needs to be supported. I attached the code I was writing
> for that. I was in the middle of writing it so it doesn't compile.
> This code should be integrated into the VGA driver.

Agreed. 

> It needs to integrate into VGAcon. VGAcon should require the vga
> device before loading. The resource reservation code in VGAcon needs
> to be moved to the VGA driver. If you use a command to switch the
> active VGA device, VGAcon needs to reset itself for the new device.

I saw vgacon as being a client of the vga class driver like the various
fb drivers would be.

> VGA driver needs to generate hotplug events for the VGA device that
> indicate if they are primary or secondary. If they are secondary there
> needs to be a user space reset program that uses the new ROM hooks to
> reset the card.

The VGA driver at the moment doesn't really know about legacy vga space.
That was something I wanted to touch last of all because it is foul. It
can do this and as you say its the perfect person to issue the hotplug
notifications. It also needs to do it for vesafb so if it is handed an
ISA hole it can work out the right PCI device.

> It should support more than two drivers, I forgot to check, does it already?

As many as you want. Just change the array size or the number
registered. One neat trick we can support is adding extra devices when
necessary - thus if the boot code in user space boots a card and decides
its multihead we'd want to add extra heads.

> fbdev takes a snapshot of the video registers when it loads. When you
> unload it it writes those registers back. That doesn't work if you
> load from an xterm and rmmod it from the command line. It snapshots
> the card in graphics mode and then restores it in an environment
> expecting text mode.

Big lock issue. You get told if someone else ate your environment. Being
more polite about that would help performance a ton. You know who had
the lock before and who has it now - so we can be intelligent about
->release cleanup I hope. (eg FB0 finds FB1 had it last it might do a
minimal restore)

> Something needs to be done for DMA processing. What if I get an
> interrupt that the DMA queue has been completed but we've switched to
> a driver that doesn't understand DMA? I guess the only safe thing to
> do is make sure all DMA queue are finished before releasing control.

The ->remove path takes the lock (so calls ->release) and then drops it
with no callback needed so providing the hand over code is robust this
will come for free.

Alan