[coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead
c-d.hailfinger.devel.2006 at gmx.net
Thu May 8 18:06:01 CEST 2008
On 08.05.2008 17:14, Stefan Reinauer wrote:
> ron minnich wrote:
>> On Thu, May 8, 2008 at 7:51 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
>>>> in some cases we actually have to allocate the BARs and so on and
>>>> leave it disabled -- we don't know if the OS wants it, but if the OS
>>>> wants it, it has to work. This is one of the less intuitive bits of
>>>> the device bringup process.
>>> Which device is that?
>> Almost all of them. Consider a bridge.
> I still think a bridge that gets disabled in Config.lb or the dts should
> not be set up. Otherwise it might be bridging, which would really not be
> what we want if we disable the device.
Are devices behind a disabled bridge completely invisible or do their
PCI headers show up?
> I can't find any bridge in v2 from a quick scan that would stay un-enabled.
> If we don't know whether the OS wants the device, we enable it, not
> leave it or disable it.
> We disable or hide the device, if that functionality is not there on the
> _board_, ie. because it is not wired.
Commerical BIOS sometimes have the ability to disable/hide otherwise
functional onboard devices, which is useful if the machine is severely
resource constrained in the IRQ area and/or the user doesn't want the OS
to drive the device.
> If we start thinking about what the OS wants in this context, we have to
> call this ACPI and make distinctions between OSes in the DTS. ;-)
Mind bleach! Now!
>>> What does pci xx.x off end do then?
>> in v2, it means that in the init function, the CMD register is
>> un-enabled (I think; I have not looked at this code for a bit and it
>> always confuses me).
>> Look in pci_probe_dev for example: device is unconditionally enabled,
>> so we can scan it.
>> IIRC one case that drove this was multiple VGA cards -- you want to
>> set up the BARs etc. for all but you really don't know what the OS
>> will do -- maybe nothing -- but you want them there if it will do
> Unless the bios disables one of the devices, in which case the OS should
> find nothing.
What about devices which cause periodic interrupts once they are
enabled? Enabling them has the undesirable effect of causing unhandled
interrupts which irritate Linux a lot.
>> There really is a difference between un-enabled (or disabled) and
>> hidden; as you pointed out, hidden means no config space, or "will not
>> show up in lspci".
> So disabled devices do show up in lspci?
I could try to dig up a lspci from a mail someone sent last year, but if
Uwe has seen this on one of his machines, I'd be glad if he could track
More information about the coreboot