Grabbing an Interrupt for a Brain-dead PCI Device

[Gabriel Paubert]

> I doubt it will work on a PowerMac; see what the resource 'checking'
> code finds as parent resources (r is a mem resource, pr is its parent
> resource):
>
> Mar  9 07:24:29 piglet kernel:    Resources: r.start=f2000400, r.end=f200043f,
> pr.start=00000000, pr.end=ffffffff.
>
> As far as I can tell, parent resource would be the memory region held
> by the parent bridge, out of which this region was allocated. A bit
> huge, this region, isn't it?

Indeed...

> Then again, Apple's host bridges might not conform entirely to the PCI
> spec in the way they advertise their resources available for
> assignment...

They probably do, at least OF should get it right in the range properties
of every bus (that's what I have on a very buggy OF for PreP Motorola
boards):

ranges                   01000000 00000000 00000000 80000000 00010000
                         01000000 00000000 01000000 81000000 3e800000
                         02000000 00000000 00000000 c0000000 3c000000
			 c172616e 67657386 0005c32c

the first 2 lines indicate how the I/O space is mapped from the processor
and the 3rd the PCI memory  space. The last line is junk...

> Those with the PCI spec at hand out there, is there such a thing as
> resource registers in bridges (be it P2P or host) that inform about
> what is available to devices behind this particular bridge?

P2P do have them, host bridges do not have them although they often have
chip specific registers which allow t ochoose between several options or
to program where the I/O space.

> Maybe there's another job for the fixup code...

Indeed, actually /proc/iomem on Intel includes even the RAM ! What is
needed is to include one hierarchy level to define the physical addresses
which the bridge forward to PCI (I started a patch but never finished it).

	Gabriel.


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