Re: readsw/writesw readsl/writesl

Re: readsw/writesw readsl/writesl

[Richard.Zidlicky]

[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

 

Re: readsw/writesw readsl/writesl

[Benjamin Herrenschmidt]

>> ...... 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.

Re: readsw/writesw readsl/writesl

[Richard Zidlicky]

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

Re: readsw/writesw readsl/writesl

[Benjamin Herrenschmidt]

>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.

Re: readsw/writesw readsl/writesl

[Richard Zidlicky]

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

Re: [BKPATCH] Read-Copy Update 2.5

[David S. Miller]

   From: Dipankar Sarma <dipankar@in.ibm.com>
   Date: Tue, 27 Aug 2002 11:41:52 +0530

   On Tue, Aug 27, 2002 at 10:24:30AM +1000, Rusty Russell wrote:
   > > +#ifdef CONFIG_PREEMPT
   > > +/* Fake initialization to work around compiler breakage */
   > > +DEFINE_PER_CPU(atomic_t[2], rcu_preempt_cntr) = 
   > > +			{ATOMIC_INIT(0), ATOMIC_INIT(0)};
   > > +DEFINE_PER_CPU(atomic_t, *curr_preempt_cntr) = NULL;
   > > +DEFINE_PER_CPU(atomic_t, *next_preempt_cntr) = NULL;
   > 
   > Also static I assume?
   
   So, only statics are broken by gcc 2.95, right ?

I think it gets both static and non-static wrong.

Why don't we just specify that DEFINE_PER_CPU()'s must
have explicit initializers then we never need to think
about this ever again.

readsw/writesw readsl/writesl

[Andre Hedrick]

Dave,

Would you consider these for each arch as there are coresponding one for
IOMIO, and life would be better if we had a standard set for MMIO.

Please consider the request.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: readsw/writesw readsl/writesl

[David S. Miller]

   From: Andre Hedrick <andre@linux-ide.org>
   Date: Mon, 26 Aug 2002 23:23:22 -0700 (PDT)
   
   Would you consider these for each arch as there are coresponding one for
   IOMIO, and life would be better if we had a standard set for MMIO.
   
   Please consider the request.

I responded to the private email I got on this subject.
I forget who asked me this, but they said they were working
on this IDE stuff.

My response was that io_barrier() shall be defined on all
platforms in asm/io.h and that you can then define your
ide_read{l,w,b} as:

	__raw_raw{l,w,b}(...);
	io_barrier();

So instead of having a million read* variations, we have one that is
standard usage (little endian + I/O barrier) and then a raw variant
where the cpu does nothing special and you have to byte-twiddle and
barrier explicitly.

Re: readsw/writesw readsl/writesl

[Andre Hedrick]

Thanks, it was Ben H.

Cheers,

On Mon, 26 Aug 2002, David S. Miller wrote:

>    From: Andre Hedrick <andre@linux-ide.org>
>    Date: Mon, 26 Aug 2002 23:23:22 -0700 (PDT)
>    
>    Would you consider these for each arch as there are coresponding one for
>    IOMIO, and life would be better if we had a standard set for MMIO.
>    
>    Please consider the request.
> 
> I responded to the private email I got on this subject.
> I forget who asked me this, but they said they were working
> on this IDE stuff.
> 
> My response was that io_barrier() shall be defined on all
> platforms in asm/io.h and that you can then define your
> ide_read{l,w,b} as:
> 
> 	__raw_raw{l,w,b}(...);
> 	io_barrier();
> 
> So instead of having a million read* variations, we have one that is
> standard usage (little endian + I/O barrier) and then a raw variant
> where the cpu does nothing special and you have to byte-twiddle and
> barrier explicitly.
> -
> 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/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: readsw/writesw readsl/writesl

[David S. Miller]

   From: Andre Hedrick <andre@linux-ide.org>
   Date: Mon, 26 Aug 2002 23:23:22 -0700 (PDT)
   
   Would you consider these for each arch as there are coresponding one for
   IOMIO, and life would be better if we had a standard set for MMIO.
   
   Please consider the request.

The only reason insl() exists is because the x86 has special
instructions to perform that operation.

It used to be an optimization when cpus were really slow.

No cpu to my knowledge has special instructions to readsl et al.  and
on no cpu would be faster than a hand coded loop.

In fact I would instead vote to delete {in,out}s{b,w,l}() and friends.
:-)

Re: readsw/writesw readsl/writesl

[Benjamin Herrenschmidt]

>The only reason insl() exists is because the x86 has special
>instructions to perform that operation.
>
>It used to be an optimization when cpus were really slow.
>
>No cpu to my knowledge has special instructions to readsl et al.  and
>on no cpu would be faster than a hand coded loop.
>
>In fact I would instead vote to delete {in,out}s{b,w,l}() and friends.
>:-)

The problem with that approach is that the "s" versions must also take
care of byte swapping (or rather _not_ byteswapping while the non-"s"
do the byteswapping).

So we would need to have raw_{in,out}{b,w,l}. Currently, it's not
possible to implement {in,out}s{b,w,l} in an efficient way because of
that.

Then we would also need to expose the io_barrier for CPUs like PPC

etc...

I tend to think that makes us expose too much CPU-specific things, which
is why I'd rather have the {read,write}s{b,w,l} versions provided by the
arch so those can be done "the right way" in the arch code, and drivers
not care about some of the gory details.

Ben.

Re: readsw/writesw readsl/writesl

[Benjamin Herrenschmidt]

>The problem with that approach is that the "s" versions must also take
>care of byte swapping (or rather _not_ byteswapping while the non-"s"
>do the byteswapping).
>
>So we would need to have raw_{in,out}{b,w,l}. Currently, it's not
>possible to implement {in,out}s{b,w,l} in an efficient way because of
>that.
>
>Then we would also need to expose the io_barrier for CPUs like PPC
>
>etc...
>
>I tend to think that makes us expose too much CPU-specific things, which
>is why I'd rather have the {read,write}s{b,w,l} versions provided by the
>arch so those can be done "the right way" in the arch code, and drivers
>not care about some of the gory details.

Ok, thinking more about it, I think finally that you are right. Since
we also have the "_p" crap entering the dance, that would really make
to much functions to abstract. However, if we decide to go the way
you describe, the we should probably also provide the raw_{in,out}*
ones.

Ben.

Re: readsw/writesw readsl/writesl

[Alan Cox]

On Tue, 2002-08-27 at 08:30, David S. Miller wrote:
> The only reason insl() exists is because the x86 has special
> instructions to perform that operation.
> 
> It used to be an optimization when cpus were really slow.

readsl becomes relevant once people start shipping bridges that can do
asynchronous pci mmio read or burst mode to order however

I wonder if thats something we should plan for now ?

Re: readsw/writesw readsl/writesl

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: 27 Aug 2002 18:25:24 +0100

   On Tue, 2002-08-27 at 08:30, David S. Miller wrote:
   > It used to be an optimization when cpus were really slow.
   
   readsl becomes relevant once people start shipping bridges that can do
   asynchronous pci mmio read or burst mode to order however
   
This would be relevant if the MMIO address were to increment,
but bursting from the same MMIO word?  That's what readsl
is meant to do, just as insl does for port I/O addresses.

UltraSPARC can do what you mention using 64-byte block loads and
stores, the same ones we use for fast memcpy/memset.  It just looks
like a huge 64-byte MMIO on the pci bus.