On Tue, 22 Feb 2005 08:04:14 +1100, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > Hardware support, radeonfb multihead, etc... is all trivial to do once > we have proper infrastructure. fbdev need a bit of overhaul in it's > current state (at least proper mecanism for picking where to allocate > the second head and ways for userland to know which framebuffers are > "tied" together).
Ben, since I'm not getting any help on LKML maybe you can answer this. Secondary cards needs reset. After looking at a bunch of fbdev drivers their code assumes the card has been reset when their probe() function runs. So this means that we have to run the VBIOS reset before probe is called. So where can I hook up the call to run the VBIOS up in the kernel? You can't trigger it on module load since the module may support multiple identical adapters. One adapter may already have the module loaded and then a second shows up via hotplug. In this case the module won't get loaded again and the second card doesn't get reset. If using a user space reset program what do you do if the user space program is missing or does not complete running? Somehow you have to stop the probe function from being called. Another case, you have a card and load the module for it, this causes reset. Now unload the module and load it again. This probably should not reset the card a second time. You also have to make sure you don't reset the primary card. One solution is to track in pci_dev if the card has been reset. This preserves the state across module load/unload. I'm then tempted to put an in-kernel emu86 (I have a 40K one) into the pci driver. PCI would use this to reset the card before calling probe(). If the VBIOS/emu86 has an error it simply wouldn't call the probe function. Doing this in-kernel makes everything synchronous but GregKH would probably have some choice words about the emulator in the PCI driver. I am leaning toward putting this into the PCI driver. At boot the PCI driver would reset any cards it finds. The PCI driver also implements hotplug so now I have a place to do reset before calling probe in this case. Doing it in-kernel fixes the synchronization problem. Right now there is no way to suspend calling the probe function while we wait for a hotplug event to finish. I have all of the pieces needed to build this. I just can't figure out where to hook it into the kernel. Worst case is that I have to go modify 75 framebuffer drivers to explicitly support reset. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
