On Jan 27, 2009, at 12:13 PM, Andrew Klossner wrote:
Kumar, you wrote:
Any resolution to all this.. Not exactly sure what change impacts
things and what part of our screwy HW is causing issues.
The change in question is commit
b556151110ff003ce77d84597400c84824690ccf.
The fundamental problem is that the "PCI Bus Command" register, the 16
bits at offset 4 in config space for both the PCI and PCI-Express bus
interfaces, does not populate PCI_COMMAND_IO, the least-significant
bit. The PCI bridge standard says that software must set this bit to
1 before the bridge can respond as a slave to I/O space access,
including access to devices on the subordinate bus. The FSL parts
ignore this requirement and control response to I/O space with the
(vendor-specific) outbound window attributes registers (POWARn.)
2.6.28 differs from 2.6.27 in that it examines this bit and sees that
it's set to 0, then observes that the I/O space window starts at
offset 0 and concludes that no I/O space resource should be allocated
for the bridge.
We are using the patch I emailed. It's ugly in that it hard-codes the
Freescale vendor ID, but it works for us.
I guess I'm confused what the actual breakage is beyond some printk
messages.
We "fixup" the resources in fsl_pcibios_fixup_bus() so Ben's change
shouldn't have an impact. Does something actually stop functioning?
Another option would have been to configure our I/O space window to
start at an offset other than 0. This would take me some time to
achieve, and it feels ugly.
agreed, that's not the right solution.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
