Solo Xgl..

[Jon Smirl]

On Tue, 22 Feb 2005 08:04:14 +1100, Benjamin Herrenschmidt
<benh at kernel.crashing.org> 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
jonsmirl at gmail.com