Re: Need reports about PCI I/O conflicts

Hi all,

[snip]

quoted

It does this by writing 0 in the io space register, but
doesn't disable IO accesses to the card in the PCI config header (or
maybe they get re-enabled by the kernel fixup code).

I think the fixup code is re-enabling it if it can:

   PCI: setting IRQ 24 on device 01:18.
   PCI: Correcting IOaddress 0 on device 01:18, now fe000001.
   PCI: Enabling I/O for device 01:18
   PCI: setting IRQ 25 on device 01:20.
   PCI: Correcting IOaddress 0 on device 01:20, now fe000001.
   PCI: Correcting IOaddress 0 on device 01:21, now fe000001.

Clearly, this is not the right way to proceed, I guess that all IO
regions above were set at 0 (which means disabled, right?), so they
get set all on the same translation.

I remember looking at the code which enables I/O for a device, but it
wasn't clear to me at that time how it decided whether to enable I/O.

At this time, simply by looking whether a BAR is marked as IO space (bit
0 set, IIRC). Obviously, there should be other sanity checks, the first
of which being to see whether the configured address falls within the
expected range (0 < BAR < [io-space size]).

If anyone wants to add that, please go ahead; but keep in mind that the
io-space size depends on the parent bridge.

By the way, Doug, can you comment on whether the 39160 should get one
or two IRQs?  I/O and memory base registers are clearly not shared
between the channels, but according to these boot messages, only one
channel gets assigned an IRQ.  (I've confirmed this with lspci.)

On Macs (at least all those I could read doc of), all PCI IRQs are or'ed
together per physical slot. Therefore, multiple devices or functions on
a single card will all get the same IRQ. Whether the PCI code really gets
this right is a different matter.

Michel
__________________________________-
.sig at home

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/