Messages in this thread | | | From | Patrick Lerda <> | Subject | RE: insw/outsw/insl/outsl (was: Re: your mail) | Date | Fri, 18 Feb 2000 13:54:46 +0100 |
| |
I have the same problem with my PowerPC board, these functions at this time are used only for quick byte copy, and the little endian to big endian conversion break data.
The problem is still here in 2.2.14 PPC, hdparm -c 1 turn on IDE 32 bit mode that use these functions, and this mode of operation is unusable without hacks ...
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.
Patrick LERDA
> >> 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. > >My original reply to Paul's post didn't make it to the list, so here it is:
>My understanding is that those routines are used to "pump" or write >to/from a fifo containing a bytestream. For example, IDE is a bytestream >fifo that is usually 16 bits wide (but can be 32). A sound card is a byte >stream too (the endian ordering of samples is a different issue). So we >always fall in cases where datas must not be swapped. >Anyway, if you want to have in memory the same data pattern you have on a >LE platform, then you must not byteswap (if you don't see why, just >imagine that the i386 will endian swap when reading the port and endian >swap again when writing to memory, which is equivalent of a read&write >without swap). The width of the fifo is in fact irrelevant.
>So yes, I beleive Paul is right and this should be done on all BE archs.
> ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |