From: Peter Korsgaard <jacmet@sunsite.dk>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, Peter Korsgaard <jacmet@sunsite.dk>,
sfr@canb.auug.org.au
Subject: Re: Recently removed io accessors
Date: Fri, 13 Oct 2006 11:55:11 +0200 [thread overview]
Message-ID: <87ejtctu9s.fsf@sleipner.barco.com> (raw)
In-Reply-To: <1160731859.4792.249.camel@localhost.localdomain> (Benjamin Herrenschmidt's message of "Fri, 13 Oct 2006 19:30:59 +1000")
>>>>> "BH" == Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
Hi,
BH> That's what bothers me... usually, if the registers are little
BH> endian and you need a byteswap to read them, then you don't need a
BH> byteswap to pump the fifo. For example, things like IDE, sound
BH> cards, wireless chips etc... have LE registers (we use byteswap to
BH> access them) and we are fine not swapping on the fifo read/writes.
Exactly. As I wrote in my previous mail: If the hw people had swapped
the 2 byte lanes I would need to byteswap on the normal register
accesses, but not on the FIFO. That would have been the preferable
setup.
Unfortunately they didn't so I need to enable big endian mode and NOT
swap on normal register access and swap on access to the FIFO.
The question is what to do about it. Adding another special case to
smc911x.h for my board is not a big deal, but I would like to get the
_insl / _outsl implementations back in misc.S instead of adding them
to my platform file.
BH> I'll read the chip spec and try to figure out what can be
BH> done. Maybe an option is to use the per-page little endian flag
BH> available on 4xx parts, I think you may have that in your xilinx,
BH> and thus have automatic byteswapping. We don't support that bit
BH> but it shouldn't be too hard to add it so that you can pass it to
BH> __ioremap. But again, I'm surprised that's necessary.
Sorry, but that sounds overkill to me. Everything works fine as long
as I don't byteswap on normal registers and use something like _insl /
_outsl for the FIFOs.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2006-10-13 9:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-12 15:44 Recently removed io accessors Peter Korsgaard
2006-10-13 0:04 ` Benjamin Herrenschmidt
2006-10-13 6:56 ` Peter Korsgaard
2006-10-13 7:31 ` Benjamin Herrenschmidt
2006-10-13 8:43 ` Peter Korsgaard
2006-10-13 9:30 ` Benjamin Herrenschmidt
2006-10-13 9:55 ` Peter Korsgaard [this message]
2006-10-13 12:18 ` Benjamin Herrenschmidt
2006-10-13 12:38 ` Peter Korsgaard
2006-10-13 23:20 ` Paul Mackerras
2006-10-14 11:57 ` Peter Korsgaard
2006-10-16 16:51 ` Linas Vepstas
2006-10-16 18:54 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ejtctu9s.fsf@sleipner.barco.com \
--to=jacmet@sunsite.dk \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.