From: Peter Tyser [mailto:ptyser@xes-inc.com]
When agent/end-point, I thought the CPU must enable inbound PCI configuration cycles by poking the PBFR Register (offset 0x44) for PCI, or the Configuration Ready Register (offset 0x4b0 for PCIe) after configuring its own inbound BARs.
That is true if any of the CPUs are allowed to boot immediately after hreset. If all the CPUs have boot-holdoff set, hardware will enable inbound config.
I believe without these PCI config writes, the agent/end-point device will not be able to be enumerated by the PCI/PCIe host/root-comples as any config cycle to the device will be retried.
True.
Would it make sense to add the unlocking of inbound PCI configuration cycles with this patch, or as a separate one?
Separate.
Are there use cases where this should not be done in u-boot, but postponed until Linux is booted?
I have some basic code to do this, but wasn't sure of a clean way to determine if an interface is PCI or PCIe to determine how the interface should be unlocked (ie, the patch is a bit "dirty":).
I'm not sure of the best way for this determination. It looks like a non-zero value for the "PCI Express Capability ID Register" at 4c can be use to detect PCIe.
-Ed