On Wed, Feb 01, 2006 at 10:20:42AM -0800, David Hawkins wrote: > 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,
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
