[PATCH 2/11] cell: generalize io-workarounds code

Ishizaki Kou kou.ishizaki at toshiba.co.jp
Fri Apr 4 17:42:32 EST 2008


Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> On Wed, 2008-04-02 at 19:52 +0900, Ishizaki Kou wrote:
> > Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> > > > As you said, if read/write/in/out functions take device parameter,
> > > > taking I/O function pointers into the dev_archdata structure should be
> > > > the best solution. But they don't take device parameter, and they must
> > > > search I/O function pointers with address parameter. I think it's
> > > > better they search pointers from bus bridges, because access mothod
> > > > for a device on its parent bus bridge, not device itself.
> > > 
> > > What I meant is that if the pointers are in dev_archdata, we can
> > > populate with a different set of pointers for PCI vs. PCI-E.
> > 
> > I'm afraid I misunderstood your opinion.
> > 
> > My concern is how to find a device by address when I/O function
> > pointers are in dev_archdata.
> > 
> > You must select the appropriate device with an address, because all
> > I/O functions, read/write/in/out don't have device parameter. If the
> > address is in MMIO space, you can set 'token' to the address to select
> > the device. But in IO space, you can't set 'token' to the I/O port
> > address. Thefore you must scan all devices to select the device.
> > 
> > Do you have any better solution?
> 
> No, you are right. The EEH code has a way to go back to the device but
> it has significant overhead. Let's stick to your current approach.

Thank you very much.

As you pointed, spider I/O functions in Cell blades need 2 step
indirections by our patch. Shall I make another one for Cell blades
whose spider I/O functions need one step indirection?
(But you will need 2 step indirections when you use PCI-ex.)

Best regards,
Kou Ishizaki



More information about the Linuxppc-dev mailing list