Re: [parisc-linux] memcpy_fromio() seems partially broken [with patch]

[Grant Grundler <grundler@puffin.external.hp.com>]

Matthew Wilcox wrote:
> This is very bizarre.  Following the codepaths, the current code does:
...
>  bytecopy:
...
> and i don't see how that can possibly do byteswapping.  unless byteswapping
> is necessary and this code is failing to do that?

That's what it sounds like.

> Your code is doing:
> 
>          if (((unsigned long)dest & 3) != (src & 3))
>                  goto wordcopy;
> 
>   wordcopy:
>          if (src & 3)
>                  goto bytecopy;
>   wordcopy_loop:
...
> which is doing a byteswap on the  value returned from readl!

Exactly.

> This seems
> pretty grotesque to me.

It looks grotesque but the compiler should be able to
do pretty well with that.

>   I want to hear from someone (eg grant) who can
> say what's actually going on here..

The problem seems that the data needs to be swapped and I don't know why.
Perhaps the card is swapping the data?
acenic (and tulip?) has such a mode.

PARISC pci host bus adapters has a "byte is byte" approach to data.
I've heard the term "address invariance" used but not sure if
that's exactly the same thing. The idea here is data DMA'd into memory
is a byte stream and the CPU reading the data from memory byte at a time
from low address to higher address would see the same data.

Normally we expect the consumer of data (eg device driver) from IO space
to perform the swap and not the accessor functions (eg readl).

I need to do more homework to be certain about the following:
  I *think* CPU reading IO space directly needs to be swapped to
  provide the same illusion that DMA provides. The problem (I think)
  is the data is *little* endian across the PCI bus and presented as
  such to the CPU which then stores it *big* endian in memory.

Dino ERS has a nice chapter on this mess. Elroy follows the same rules.
I'll have to read that again.

grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253