On 05/31/2013 01:43:49 AM, Kevin Hao wrote:

On Thu, May 30, 2013 at 01:54:59PM -0500, Scott Wood wrote:

quoted

On 05/30/2013 05:20:34 AM, Kevin Hao wrote:

quoted

On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote:

quoted

On 05/21/2013 07:04:58 AM, Kevin Hao wrote:

quoted

It also seems that we don't support ISA on all the current

corenet ds

quoted

quoted

boards. So picking a primary bus seems useless, remove that

function

quoted

quoted

too.

IIRC that was due to some bugs in the PPC PCI code in the =20

absence of

quoted

quoted

quoted

any primary bus.

Do you know more about these bugs?

Not off the top of my head -- either search the archives or ask Ben.

quoted

quoted

 fsl_pci_assign_primary() will arbitrarily pick one
to be primary if there's no ISA.  Have the bugs been fixed?

I know there should be some reason that we put the
fsl_pci_assign_primary()
here. But frankly I am not sure what bugs this workaround try to
fix. For these
corenet boards picking one to be primary has no effect to the
64bit kernel.
And for 32bit kernel, the only effect of this is that isa_io_base
is set to the
io virtual base of the primary bus. But the isa_io_base only make
sense when
we do have a isa bus, so that we can access some well-known io
ports directly
by using outx/inx. But if we don't have isa bus on the board, the
value of
isa_io_base should make no sense at all. So we really don't need
to pick a
fake primary bus. Of course I may miss something, correct me if I
am wrong. :-)

outx/inx can also be used for PCI I/O BARs.

=20
Yes, I know there is also PIO. But the value of isa_io_base doesn't
have any effect for this.

See this e-mail for some of the issues I was referring to with =20
isa_io_base being zero:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-June/098586.html

Reading it again I'm not so sure that the problem is so much that we =20
need a primary, as that somewhat bad things happen on non-primary =20
buses, such as the possibility of assigning a zero BAR.  Some hardware =20
(including QEMU's PCI emulation) cares about this, though most =20
doesn't.  We only have one PCI bus under QEMU, so when we started =20
picking an arbitrary bus to be primary, the problem went away because =20
there was only one bus and therefore there was no non-primary bus.

-Scott=