Somebody who understands APUS around ?
In include/asm-ppc/io.h, we have a special definition of the PCI IO
accessors readw,writew,readl and writel for APUS that don't do byteswap
and also don't do barriers.
This seems very bogus to me. Can somebody explain me why it's done that
way so I can then explain why it's broken ? :-)
I will remove those definitions soon, so unless I get a very convincing
argument of why it has to be done that way on APUS, things might break
(APUS-specific drivers relying on those not swapping will have to be
fixed).
Ben.
Hi,
Benjamin Herrenschmidt wrote:
Somebody who understands APUS around ?
I have one, but I don't understand all of it. :-)
In include/asm-ppc/io.h, we have a special definition of the PCI IO
accessors readw,writew,readl and writel for APUS that don't do byteswap
and also don't do barriers.
APUS PCI is weird, to say the least. The PCI extension is basically
built to accomodate a single PCI device, which happens to be a Permedia2
graphics chip that allows byte-swapped mappings of both register and
framebuffer space and is never told to do DMA because nobody knows what
kind of interesting effects that would have, so the only synchronisation
that is needed is between accesses to the framebuffer and the GPU.
That, and that the 604e+ probably doesn't reorder accesses that much
anyway that the barriers would do any good here. :-)
Simon
That, and that the 604e+ probably doesn't reorder accesses that much
anyway that the barriers would do any good here. :-)
Is there any reason though to have APUS-specific I/O accessors
instead of using the generic stuff (except for perhaps a minor
performance hit)?
Segher
On Mon, 2006-11-06 at 16:18 +0100, Simon Richter wrote:
Hi,
Benjamin Herrenschmidt wrote:
quoted
Somebody who understands APUS around ?
I have one, but I don't understand all of it. :-)
quoted
In include/asm-ppc/io.h, we have a special definition of the PCI IO
accessors readw,writew,readl and writel for APUS that don't do byteswap
and also don't do barriers.
APUS PCI is weird, to say the least. The PCI extension is basically
built to accomodate a single PCI device, which happens to be a Permedia2
graphics chip that allows byte-swapped mappings of both register and
framebuffer space and is never told to do DMA because nobody knows what
kind of interesting effects that would have, so the only synchronisation
that is needed is between accesses to the framebuffer and the GPU.
That, and that the 604e+ probably doesn't reorder accesses that much
anyway that the barriers would do any good here. :-)
Still, it annoys me to have an APUS-specific definition of accessors
that would otherwise be common to everybody...
Anyway, I decided not to change asm-ppc/io.h, so this will only become
an issue if we ever move APUS over to arch/powerpc
Ben.