On Mon, 13 Sep 2004 12:26:33 +0100, Alan Cox wrote: > Well this is what I came up with so far. It creates a vga class so you > can bind the drivers to functions of the card (and we can add/remove > functions later as appropriate), tells functions about each other and > now implements Linux lock proposal as I understood it. It needs something to sort out both drivers attaching to the IRQ. 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. 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. 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. 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. 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. It should support more than two drivers, I forgot to check, does it already? 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. 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. -- Jon Smirl jonsmirl@gmail.com