Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?

On Wed, Feb 01, 2006 at 10:20:42AM -0800, David Hawkins wrote:

Eugene Surovegin wrote:

quoted

On Wed, Feb 01, 2006 at 10:04:15AM -0800, David Hawkins wrote:

quoted

Matt,

In the same vein as the readl()/writel() question, what
are the assumptions regarding memcpy_toio and memcpy_fromio?

If the memcpy_to/fromio operations are intended only
for access to PCI devices, then they should also inherently
perform little-endianness conversion. For the test driver
I was working on, I did *not* find this the case, eg.
I implemented the test driver read() and write() using the
memcpy_to/fromio calls, and the data transfers occur
in big-endian (well, 'native' mode, since I also test the
same test driver with the PCI adapter in an x86 system).

If memcpy_to/fromio can be used in a more general context,
then I can see why they operate in native mode.

Just looking for enlightenment.

This commands IIRC are intended for copying chunk of _bytes_. There 
are no issues with endianess for bytes, e.g. they work just like 
ordinary memcpy.

True, good point.

I quite often implement a 'control' device to read/write/mmap PCI
device registers. In that case, the registers are usually 32-bit, so
if I wanted endian neutrality, I could either let the user-space
app determine the endianness and act accordingly, or force the
user-space app to always see little-endian registers by replacing
memcpy_to/fromio calls with a loop over read;/writel,

You seem to assume that memcpy should do 32-bit reads/writes. Why not 
16-bit ones? That's why memcpy cannot do any byte swapping, because it 
can "theoretically" do 2 different types of it (16-bit and 32-bit), 
which is obviously not specified in memcpy interface.

-- 
Eugene