[coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead

[Carl-Daniel Hailfinger]

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