Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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 > are. 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. Best regards, Kou Ishizaki _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev