All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Jeff Garzik <jgarzik@pobox.com>, Andrew Morton <akpm@osdl.org>,
	"David S. Miller" <davem@davemloft.net>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: lib/iomap.c mmio_{in,out}s* vs. __raw_* accessors
Date: Sun, 05 Nov 2006 15:38:57 +1100	[thread overview]
Message-ID: <1162701537.28571.156.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0611042013400.25218@g5.osdl.org>


> The _only_ reason to use "ioread32be()" would be because the machine is 
> actually natively BE, and you want to avoid swab. That's kind of the point 
> of using "be32_to_cpu(__raw_readl(addr)))" like we do now - it will do the 
> byte swap only if it's necessary.
> 
> In contrast, your "swab(readl())" does _two_ byteswaps - once to turn it 
> into LE, then to turn it back into BE.

I'm not doing a swab(readl()), I'm doing a swab(insl()) and have the
arch provide a native BE accessor for readl_be(). The idea is that I
don't want to add _be accessors for PIO and PIO is slow anyway. But I'm
providing one for MMIO, along with the repeat versions. Have a second
look. 

> So if we can't just rip it out, then we sure as hell shouldn't replace it 
> with something that is obviously worse either.
> 
> In other words - I don't see the reasoning here again. You seem to want to 
> make the code just worse. 

Wait, let's make thing clear, there are 2 things here:

 - MMIO : For that, I'm providing readw_be etc... which my patch defines
based on __raw_* just as your suggest, I'm just adding a way for the
arch to provide its own.

 - PIO : This is broken -now-. The current code doesn't swap at all in
the PIO case, thus you get LE result when using ioread32be() on PIO. I
propose to fix that with swab() because PIO sucks already, there is no
"__raw" for PIO and it doesn't deserve new accessors nor speed.

Cheers,
Ben.



  reply	other threads:[~2006-11-05  4:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-04  7:52 lib/iomap.c mmio_{in,out}s* vs. __raw_* accessors Benjamin Herrenschmidt
2006-11-04 14:06 ` Russell King
2006-11-04 22:17   ` Benjamin Herrenschmidt
2006-11-04 23:52     ` Linus Torvalds
2006-11-05  1:10       ` Benjamin Herrenschmidt
2006-11-05  3:32         ` Benjamin Herrenschmidt
2006-11-05  3:46           ` Linus Torvalds
2006-11-05  3:55             ` Benjamin Herrenschmidt
2006-11-05  4:00             ` Benjamin Herrenschmidt
2006-11-05  4:16               ` Linus Torvalds
2006-11-05  4:38                 ` Benjamin Herrenschmidt [this message]
2006-11-05  5:00                   ` Linus Torvalds
2006-11-05  5:08                     ` Benjamin Herrenschmidt
2006-11-05  5:28                       ` Benjamin Herrenschmidt
2006-11-06  2:56                         ` Benjamin Herrenschmidt
2006-11-06  3:13                           ` Linus Torvalds
2006-11-06  4:50                             ` Benjamin Herrenschmidt
2006-11-05  3:34         ` Linus Torvalds
2006-11-05  3:49           ` Benjamin Herrenschmidt

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=1162701537.28571.156.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=torvalds@osdl.org \
    /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.