From: Richard Zidlicky <rz@linux-m68k.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: davem@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: readsw/writesw readsl/writesl
Date: Wed, 28 Aug 2002 14:23:56 +0200 [thread overview]
Message-ID: <20020828142356.B4464@linux-m68k.org> (raw)
In-Reply-To: <20020827092908.31569@192.168.4.1>; from benh@kernel.crashing.org on Tue, Aug 27, 2002 at 11:29:07AM +0200
On Tue, Aug 27, 2002 at 11:29:07AM +0200, Benjamin Herrenschmidt wrote:
> >> ...... However, if we decide to go the way
> >> you describe, the we should probably also provide the raw_{in,out}*
> >> ones.
> >
> >carefull, m68k already has them for other purposes. Original intention
> >was that raw_{in,out} should never be used outside architecture specific
> >stuff anyway.
>
> Then we have a problem... Either we chose to keep 2 different interfaces
> for MMIO and "PIO" with the "s" versions on PIO and not on MMIO, the
> raw versions on MMIO but not PIO, etc...
>
> Or we decide to unify this properly.
>
> In all cases, the current abstraction doesn't allow to re-implement
> {in,out}s{b,w,l}. This is already a problem as if a driver need to
> pump a fifo with some udelay's (like doing a _p version of one of
> the above), it can't or has to do some arch specific crap to deal
> with byteswap, barriers, etc...
it is a bit ugly right now, in asm-m68/ide.h we have to include io.h
and redefine some of the defs. Even more fun with some net drivers (eg 8390)
which on m68k can accessed over ISA bus, Zorro bus, or Zorro bus +
ISA bridge and maybe a few other methods. Byteswaps are the smallest
problem here, we have also to translate adresses and deal with sparsely
mapped io regions.
A decent solution should use a per device "busops" struct that would
define in/out and other access methods for the underlying bus.
Richard
next prev parent reply other threads:[~2002-08-28 12:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-27 16:00 readsw/writesw readsl/writesl Richard.Zidlicky
2002-08-27 9:29 ` Benjamin Herrenschmidt
2002-08-28 12:23 ` Richard Zidlicky [this message]
2002-08-28 16:17 ` Benjamin Herrenschmidt
2002-08-29 9:17 ` Richard Zidlicky
-- strict thread matches above, loose matches on Subject: below --
2002-08-27 6:11 [BKPATCH] Read-Copy Update 2.5 David S. Miller
2002-08-27 6:23 ` readsw/writesw readsl/writesl Andre Hedrick
2002-08-27 6:43 ` David S. Miller
2002-08-27 6:55 ` Andre Hedrick
2002-08-27 7:30 ` David S. Miller
2002-08-27 6:46 ` Benjamin Herrenschmidt
2002-08-27 6:49 ` Benjamin Herrenschmidt
2002-08-27 17:25 ` Alan Cox
2002-08-27 21:31 ` David S. Miller
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=20020828142356.B4464@linux-m68k.org \
--to=rz@linux-m68k.org \
--cc=benh@kernel.crashing.org \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.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