[snip]
> ...... 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.
Richard
>> ...... 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...
Ben.
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
>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.
This have been proposed several times in the past, and always rejected
for what is I think mostly fantasmatic performances reasons.
Though that would fit nicely in the new driver model ;)
The fact is that an indirect function call has a non-negligible cost
on heavily pipelined CPUs like we have nowadays. But on the other
hand, do we do _that_ much perf critical MMIOs ? Most of the really
perf critical IOs are DMA... We could eventually mix that and provide
direct accessors for PCI in addition to generic per-bus "ops"...
Another possibility (that looks saner to me) would be to define that
the IO macros take all a parameter which represents the bus (or rather
the device pointer in the new driver model). Most archs would just
ignore that macro parameter and so have exactly equivalent code as
we have today, but that let archs that feel they need it to actually
use that to go pick the proper access methods for that device.
In all cases, though, I would keep the distinction between {read,write}*
and {in,out}* as there are PCI drivers that will need to mix them.
But I have few hopes for anything like that to ever be accepted
anyway...
Ben.
On Wed, Aug 28, 2002 at 06:17:01PM +0200, Benjamin Herrenschmidt wrote:
> Another possibility (that looks saner to me) would be to define that
> the IO macros take all a parameter which represents the bus (or rather
> the device pointer in the new driver model). Most archs would just
> ignore that macro parameter and so have exactly equivalent code as
> we have today, but that let archs that feel they need it to actually
> use that to go pick the proper access methods for that device.
that would certainly solve all problems.
> In all cases, though, I would keep the distinction between {read,write}*
> and {in,out}* as there are PCI drivers that will need to mix them.
sure, it makes a difference even on m68k ISA buses.
Richard