Blocking access to a PCI device for "a long time"?

Blocking access to a PCI device for "a long time"?

[Timothy Miller]

Some of you may have followed the earlier discussions on the open 
graphics card.  One problem is that we are trying to fit a lot of logic 
into a small area, so one thing we're considering is having multiple 
FPGA bitfiles in the PROM.  When changing modes (ie. from VGA to 3D), 
the driver would instruct the FPGA to reload itself from a different 
part of the bitfile PROM.

The issue here is that it's a complete reload of the FPGA which makes it 
completely lose all configuration state, which includes PCI config. 
Thus, the process for switching modes would go something like this:

- Make sure that nothing can get confused by the device "going away" on 
the PCI/AGP bus, using whatever kernel locks are necessary
- Save PCI config state of device
- Instruct the FPGA to reload itself
- Wait many, many, many, many milliseconds
- Reload PCI config state
- Unlock and continue

Other drivers accessing the bus for other devices is PROBABLY not a 
problem, but nothing can touch the GPU while it's reloading.

Are there any problems with this approach that would make it a really 
bad idea?

Re: Blocking access to a PCI device for "a long time"?

[Benjamin Herrenschmidt]

> - Make sure that nothing can get confused by the device "going away" on 
> the PCI/AGP bus, using whatever kernel locks are necessary
> - Save PCI config state of device
> - Instruct the FPGA to reload itself
> - Wait many, many, many, many milliseconds
> - Reload PCI config state
> - Unlock and continue
> 
> Other drivers accessing the bus for other devices is PROBABLY not a 
> problem, but nothing can touch the GPU while it's reloading.
> 
> Are there any problems with this approach that would make it a really 
> bad idea?

You should read the thread called [PATCH 1/2] pci: Block config access
during BIST where a similar issues with proposed solution is discussed.

Ben.