linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Peter Korsgaard <jacmet@sunsite.dk>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: sfr@canb.auug.org.au, linuxppc-dev@ozlabs.org
Subject: Re: Recently removed io accessors
Date: Fri, 13 Oct 2006 14:38:12 +0200	[thread overview]
Message-ID: <87wt74s85n.fsf@sleipner.barco.com> (raw)
In-Reply-To: <1160741900.4792.255.camel@localhost.localdomain> (Benjamin Herrenschmidt's message of "Fri, 13 Oct 2006 22:18:20 +1000")

>>>>> "BH" == Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

Hi,

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

BH> That's where it bothers me... you need to enable BE register
BH> mode...

Yes, because the hw people didn't swap the byte lanes. To go back to
my previous mail:

Endian register set to little endian (default at powerup):
RedBoot> x -b 0x8e000064 -2 -l 4
8E000064: 4321 8765
RedBoot> x -b 0x8e000064 -4 -l 4
8E000064: 43218765

With the bytelanes swapped the 32bit read would return 21436587 which
is simply the little endian form of what we need.

But because they didn't swap the lanes I need to enable the BE mode
and not do bswap.

BH> On normal HW, you don't do that... you get LE registers and
BH> everybody is happy with that and the fifo just works. Unless what
BH> you really do is enable BE register mode (and it looks like BE) or
BH> something around those lines.

Sorry, I cannot parse that. I AM enabling BE mode.

Again:
- Bytelanes directly connected (as on our boards): You have to enable BE
  mode in the chip, NOT swap normal register accesses and SWAP accesses
  to/from the FIFOs.

- Bytelanes swapped: You should NOT enable BE mode, SWAP normal
  register accesses and NOT swap accesses from/to the FIFOs.

BH> Have you actually verified that it works if you endian swap the
BH> whole buffer ? Maybe it's just some headers added by the chip that
BH> need swapping in which case it's all fine, just add the proper
BH> leXX_to_cpu() to the driver when reading those...

Yes, we've be using it since January (I worked together with Dustin
before smc911x.c got submitted to mainline) - We need to swap all data
to/from the FIFOs.

>> 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> Maybe with a different name but that's possible. I just wnat to be
BH> 150% sure that this is what you need and the problem isn't lurking
BH> somewhere else ;)

Not as far as I can see.

BH> Overkill ? well, not that much.. you get free byteswap from the
BH> hardware with just a bit set in the PTEs :) Just a matter of
BH> making sure the TLB miss handlers does proerly forward that bit
BH> from the linux PTE to the TLB.

It's still a lot more work than simply doing a s/_outsl_ns/_outsl/.
Isn't the stwbrx as fast as a regular stw?

-- 
Bye, Peter Korsgaard

  reply	other threads:[~2006-10-13 12:38 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
2006-10-13 12:18             ` Benjamin Herrenschmidt
2006-10-13 12:38               ` Peter Korsgaard [this message]
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=87wt74s85n.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).