Eugene Surovegin wrote: > On Wed, Feb 01, 2006 at 10:04:15AM -0800, David Hawkins wrote: > >>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, and in mmap making sure to set the _PAGE_ENDIAN flag. Of course, making mmap endian-neutral depends on the 440EP page flags, which say an ARM might not have. Thanks for the valuable feedback guys. Dave
