From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>,
linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
Date: Wed, 7 Sep 2005 21:51:35 -0300 [thread overview]
Message-ID: <20050908005135.GA8882@dmt.cnet> (raw)
In-Reply-To: <1126139332.29803.0.camel@gaston>
On Thu, Sep 08, 2005 at 10:28:52AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2005-09-07 at 20:03 -0300, Marcelo Tosatti wrote:
> > Hi,
> >
> > The following patch adds big endian version of ld_/st_ macros
> > and converts core 8xx code to use them.
> >
> > Other than making IO accesses explicit (which is a plus for
> > readability), a common set of macros provides a unified place for the
> > volatile flag to constraint compiler code reordering.
> >
> > There are several unlucky places at the moment which lack the
> > volatile flag.
>
> I'm not fan of the approach. You should use in_/out_ macros for IOs. If
> you don't need eieio on 8xx , then just #ifdef it out of the
> implementation of these.
The reason for that is that in_/out_ are supposed to be the standard
IO macros (conformance)? In practice most drivers using the std macros
can benefit from the change.
A common routine is shared by all architectures. Doing something like
/*
* 8, 16 and 32 bit, big and little endian I/O operations, with barrier.
*/
extern inline int in_8(volatile unsigned char __iomem *addr)
{
int ret;
__asm__ __volatile__(
"lbz%U1%X1 %0,%1;\n"
#ifndef CONFIG_8xx
"twi 0,%0,0;\n"
"isync" : "=r" (ret) : "m" (*addr));
#else
: "=r" (ret) : "m" (*addr));
#endif
return ret;
}
Seems somewhat ugly?
next prev parent reply other threads:[~2005-09-08 0:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-07 23:03 [PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it Marcelo Tosatti
2005-09-08 0:28 ` Benjamin Herrenschmidt
2005-09-08 0:42 ` Dan Malek
2005-09-08 0:55 ` Benjamin Herrenschmidt
2005-09-08 0:58 ` Marcelo Tosatti
2005-09-08 4:27 ` Paul Mackerras
2005-09-08 13:56 ` Dan Malek
2005-09-08 19:34 ` Marcelo Tosatti
2005-09-08 0:51 ` Marcelo Tosatti [this message]
2005-09-08 1:14 ` 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=20050908005135.GA8882@dmt.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=paulus@samba.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.