On Thu, 17 Feb 2000, Paul Mackerras wrote:
Does anyone have any objection if I make insw/outsw/insl/outsl *not*
byte-swap the data? The reason is that these functions are mostly used
for transferring blocks of data, i.e. arrays of bytes. I haven't found a
single instance where they are used for transferring arrays of 16 or
32-bit words.
This would mean that we wouldn't need the kludge in the ide stuff where we
redefine insw as ide_insw (which doesn't byte-swap). There is currently a
bug there because insl does still byte-swap, which means that if you set
the -c1 flag with hdparm, you get byte-swapped data. :-(
Hmm... This is indeed ambiguous. Is e.g. insl() used to (a) read n 32-bit words
from (little endian) ISA I/O space, or (b) used to read n*4 bytes from ISA I/O
space, using 32-bit accesses?
What about moving this to linux-kernel? It affects all big endian platforms.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, 18 Feb 2000, Geert Uytterhoeven wrote:
On Thu, 17 Feb 2000, Paul Mackerras wrote:
quoted
Does anyone have any objection if I make insw/outsw/insl/outsl *not*
byte-swap the data? The reason is that these functions are mostly used
for transferring blocks of data, i.e. arrays of bytes. I haven't found a
single instance where they are used for transferring arrays of 16 or
32-bit words.
Go ahead, please. This is the only consistent way. These macros are used
to transfer an unstructured stream (s stands here for stream IMNSHO) of
bytes. The order of the bytes in memory after an insl/before an outsl
should be independant of the endianness of the platform (that's the only
way to be compatible between PIO and DMA modes). If this stream contains
scalars which are multibyte fields then you can access them with the
proper [bl]e{16,32,64}_to_cpu/cpu_to_[bl]e{16,32,64} macros.
quoted
This would mean that we wouldn't need the kludge in the ide stuff where we
redefine insw as ide_insw (which doesn't byte-swap). There is currently a
bug there because insl does still byte-swap, which means that if you set
the -c1 flag with hdparm, you get byte-swapped data. :-(
Hmm... This is indeed ambiguous. Is e.g. insl() used to (a) read n 32-bit words
from (little endian) ISA I/O space, or (b) used to read n*4 bytes from ISA I/O
space, using 32-bit accesses?
Don't forget that it reads repeatedly from the same port, {in,out}[bwl]
transfer scalars so it makes sense to convert by default between device
anc cpu byte orderings. The `s' versions are most often used to tranfer
data from a FIFO and there it does not make sense at all, especially when
you hit a packed structure with unaligned fields.
This is the same problem as some Ethernet chip SROM which are read by
chunks of 16 bits, and have streams of bytes and 16 bit LE fields: each 16
bit value is stored in memory in LE order to avoid crazyness when parsing
the SROM (the pointer increment and 16 bit access macros would be
otherwise very fun to write).
The exceptional case is the other one, when you know that you actually
transfer a series of 16 bit items with insw/outsw or of 32 bit items
with insl/outsl. But in this case, you know the endianness of the device
and if the need arises we might define {in,out}s[wl]_[bl]e
What about moving this to linux-kernel? It affects all big endian platforms.
I think Paul shouuld go ahead, there are pretty convincing arguments (at
least for me) that show that this is the Right Way (TM).
Gabriel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Geert Uytterhoeven wrote:
On Thu, 17 Feb 2000, Paul Mackerras wrote:
quoted
Does anyone have any objection if I make insw/outsw/insl/outsl *not*
byte-swap the data? The reason is that these functions are mostly used
for transferring blocks of data, i.e. arrays of bytes. I haven't found a
single instance where they are used for transferring arrays of 16 or
32-bit words.
This would mean that we wouldn't need the kludge in the ide stuff where we
redefine insw as ide_insw (which doesn't byte-swap). There is currently a
bug there because insl does still byte-swap, which means that if you set
the -c1 flag with hdparm, you get byte-swapped data. :-(
Hmm... This is indeed ambiguous. Is e.g. insl() used to (a) read n 32-bit words
from (little endian) ISA I/O space, or (b) used to read n*4 bytes from ISA I/O
space, using 32-bit accesses?
What about moving this to linux-kernel? It affects all big endian platforms.
How about {ins|outs}_{be|le}{16|32} ?
Regards,
-velco
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/