[PATCH 2/11] cell: generalize io-workarounds code
kou.ishizaki at toshiba.co.jp
Thu Mar 27 22:02:15 EST 2008
Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> I may have missed something in your patch but if the workarounds are
> specific to a given bridge, they may as well set the top level
> indirections once straight to the right workarounds.
> Also, my understanding is that we are pretty much using the same
> bridge on the cell blades, so is there any way that can be
> consolidated rather than having function pointers ?
Celleb has two different bus bridges such as PCI and PCI-Express, and
they have different bus access methods. Cell blades support only one
PCI, so you may have only one indirect access method. That is why I
introduced second level indirect function.
Considering to embed 'second level' indirect function into first level
macros, it may break iSeries.
> I'll try to have a closer look next week, but I'm a bit worried by
> having all IO go through 2 level of function pointers, the PPE isn't
> very good at it and this will slow things down more than they already
Only on celleb, all IO go through 2 level of function pointers.
On cell blades, you can set global variable "ppc_pci_io" up at function
spider_pci_workaround_init() directly instead of calling function
io_workaround_init(), so all IO on cell blades use only one level of
function pointer which is stored in ppc_pci_io.
> > I may have missed something in your patch but if the workarounds are
> > specific to a given bridge, they may as well set the top level
> > indirections once straight to the right workarounds.
> Looking more closely, I wonder if a good solution would be to move the
> function pointers away from globals, to the dev_archdata structure,
> and thus make them per-device (like the DMA ops)
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.
More information about the Linuxppc-dev