pci <-> device node mapping

[Todd Inglett]

On Wed, 2003-06-18 at 16:04, Benjamin Herrenschmidt wrote:
> On Wed, 2003-06-18 at 21:36, Todd Inglett wrote:
>
> > The device_node contains a ptr to the tce table.  I suppose sysdata
> > could point directly to it, or you could invent some other external
> > means to find it.
>
> Do you rely on this direct pointer in performance critical locations ?
>
> One thing I want to do sooner or later on ppc32 and possibly ppc64 as
> well is to get rid of all fields in the device_node except the actual
> link pointers and the property list. Additional infos would then be
> added to device nodes by adding properties. For example, I plan to
> replace the n_interrupts & interrupts array with a "linux,irq"
> property.

Yeah, I like this idea.  At the time I coded this it was a choice
between adding an intermediate node off sysdata pointing to the
tce_table and device_node, or just putting the pci stuff into the device
node.  The latter wasn't as clean but it was easy :).  Yeah, poor excuse
and it should be cleaned up.

The reasons for the direct link to the device node itself may well be
all gone -- at least on performance paths.

BTW, is there a reason that interrupts array is computed and stored in
early boot?  Seems to me that the interrupt can be computed on the fly
as the pci probe occurs.  Not as efficient, but simple and the pci probe
itself certainly isn't performance critical.  I must be overlooking
something.

My intuition says the pci_map* paths are performance critical, but I
have not personally measured them nor have I seen anyone comment on them
and I make it a habit never to count on my intuition for stuff like this
:).

One other comment is that it was pure hell to map sysdata with a unique
value per device.  The pci probe code (at least in 2.4) really wanted
sysdata to be inherited from the bus being probed.  The busno, devfn,
etc, that I added to the device node can go away if this is fixed.
--
Todd Inglett <tinglett at vnet.ibm.com>


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