Re: insw/outsw/insl/outsl (was: Re: your mail)

Re: insw/outsw/insl/outsl (was: Re: your mail)

[Benjamin Herrenschmidt]

On Fri, Feb 18, 2000, Patrick Lerda <Lerda@microprocess.com> wrote:

>In my opinion we need new functions for quick byte copy, with new names.
>The names insw/outsw/insl/outsl are to close to inw, outw, insw...;
>these functions work with the PCI bus, and data need a conversion to
>little-endian,
>before read and write operation.
>
>We need new functions and fix the kernel.

I'm not sure we need new functions at all.

Do you know a single case where swapping would actually be required with
insw/outsw/insl/outsl ?

All cases I encountered so far (IDE, sound, ethernet), those are used to
transfer stream of bytes between device and memory. In this case, the
access width is irrelevant and no swapping must be done.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

insw/outsw/insl/outsl (was: Re: your mail)

[Geert Uytterhoeven]

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/

Re: insw/outsw/insl/outsl (was: Re: your mail)

[Gabriel Paubert]

On Fri, 18 Feb 2000, Geert Uytterhoeven wrote:

>
> 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.

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.

> > 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/

Re: insw/outsw/insl/outsl (was: Re: your mail)

[Momchil Velikov]

Geert Uytterhoeven wrote:
>
> 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.

How about {ins|outs}_{be|le}{16|32} ?

Regards,
-velco

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/