lkml.org 
[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: readsw/writesw readsl/writesl
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.032 / U:18.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site