Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Dominic Sweetman <dom@mips.com>
Cc: Hiroshi DOYU <Hiroshi_DOYU@montavista.co.jp>, linux-mips@linux-mips.org
Subject: Re: how to access structured registers correctly
Date: Mon, 1 Aug 2005 08:51:24 +0100	[thread overview]
Message-ID: <20050801075124.GA1972@linux-mips.org> (raw)
In-Reply-To: <17127.14246.112209.239338@mips.com>

On Wed, Jul 27, 2005 at 08:28:38AM +0100, Dominic Sweetman wrote:

> > > In tx4938, every register access is done by using "volatile" like below.
> > 
> > Linus is right, volatile is a dangerous thing.  If you want to write
> > portable code there's a bunch of things that are not being taken care of
> > by plain C - even though in my opinion foo->somereg = 42 is more
> > readable than writel(somereg, 42).  Among the things the pointer to
> > volatile struct method doesn't catch are endianess conversion that might
> > be necessary on some systems, write merging, dealing with write buffers
> > or completly insane methods of attaching the bus such as the infamous
> > ISA / EISA cage that's attached to the host system through a USB
> > interface.
> 
> Yes, this is far outside the compiler's reach.
> 
> All of which suggests that it would make sense to define a standard function
> which:
> 
> o will produce just one fixed-width write cycle to the destination;
> 
> o will deliver the data ordered so that the MSB of the C value is on
>   the "most significant" bit of the device's data bus, usually the
>   highest numbered bit (this doesn't solve all device endianess
>   issues, but it gives you a well-defined place to start solving them);
> 
> o has a variant which returns only after some indication that the
>   data was delivered;
> 
> The implementation of this function can then conceal the details of
> the CPU and interconnect.
> 
> Such a function should probably not be called "writel()" because that
> sounds like "write long", and "long" is not a fixed-size data type,
> which undermines the promises above...  Tediously, you probably need
> "writei32()", "writei16()", "writei8()"...

Linux has a long tradition of grossly missnaming things, so readw reads
16-bit words, readl reads 32-bit words and readq 64-bit words, that is
each of them operates on just half the quantity a MIPS programmer would
expect. Same for writew, writel and writeq.  Blame the Intel guys for it ;-)

Ranting about grossly missnaming things, the DMA API calls coherent what
MIPS calls non-coherent and vice versa.  I'll stop now, birds are
whistling way to nice behind The Fruit Farm for me to write a good rant
today ;-)

There are ioread8, ioread16, ioread32, iowrite8, iowrite16, iowrite32
already except they're primarily used with I/O busses such as PCI but
that's not really an issue.

   Ralf

      reply	other threads:[~2005-08-01  8:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-26  9:25 how to access structured registers correctly Hiroshi DOYU
2005-07-26 19:06 ` Ralf Baechle
2005-07-27  7:28   ` Dominic Sweetman
2005-08-01  7:51     ` Ralf Baechle [this message]

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=20050801075124.GA1972@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=Hiroshi_DOYU@montavista.co.jp \
    --cc=dom@mips.com \
    --cc=linux-mips@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox