On 08.05.2008 16:29, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Interesting proposal. If I understand you correctly, enabled=0 would mean
- disabled on all chipsets
- hidden on those chipsets where hiding is supported.
There are two problems I have with that approach, though:
- I don't understand PCI well enough to know how a device is disabled.
On a high level:
Thanks for the explanations!
Disabling the device means we disable its memory and io space.
But it can still do DMA and issue IRQs, right?
Also, does disabling memory and IO space set a special "disabled" flag or do we simply set each resource with a size of zero?
Hiding the device means we disable its config space.
So with any of the three resource types disabled, the device is not really usable. They're just decoded differently.
not usable != disabled.
Does disabling the device mean disabling the resources as well? Does it mean the device won't respond to config cycles outside a special "enable cycle" anymore?
absolutely. If you have a special disable function, you will also need a special enable function. But that won't happen, as you don't re-enable a device that you disabled on purpose.
Do we need special per-device functions for en-/disabling or is this doable with a generic PCI function?
- With automatic hiding, we lose the ability to leave a device
untouched. Do we need an enum(disabled, hidden, enabled, untouched) for a full representation of possible states?
hidden implies disabled, since when you disable the config space of the device, the BARs are gone, too.
Well, if you can hide a device, can it issue IRQs or perform DMA on its own initiative?
untouched is not an option we provided at any time before, but basically it implies disabled, too.
I still think untouched could be useful. For one, it would allow us to minimize setup during early porting and we could do the rest of the setup from a network-loaded payload. That's not neccessary if you have a ROM emulator, but a big plus for those developers without one.
Regards, Carl-Daniel