Re: Do cpu-endian MMIO accessors exist?

Re: Do cpu-endian MMIO accessors exist?

[Jiri Slaby]

On 07/22/2009 12:05 AM, Arnd Bergmann wrote:
> On Tuesday 21 July 2009, Jiri Slaby wrote:
>> I guess it's a bug that ioread/write* on sh are not with
>> barriers?
> 
> That depends on how that architecture defines its bus interface.
> On many simple architectures, you do not need any synchronization
> operations.

No, I should have written this explicitly. I meant read* have a barrier,
whereas ioread* do not. Similarly for writes. Is this expected?

For example:
#define __raw_readl(a) (__chk_io_ptr(a), *(volatile u32 __force *)(a))
#define readl(a)       ({ u32 r_ = __raw_readl(a); mb(); r_; })
#define ioread32(a)    __raw_readl(a)

Re: Do cpu-endian MMIO accessors exist?

[Arnd Bergmann]

On Wednesday 22 July 2009, Jiri Slaby wrote:
> No, I should have written this explicitly. I meant read* have a barrier,
> whereas ioread* do not. Similarly for writes. Is this expected?
> 
> For example:
> #define __raw_readl(a) (__chk_io_ptr(a), *(volatile u32 __force *)(a))
> #define readl(a)       ({ u32 r_ = __raw_readl(a); mb(); r_; })
> #define ioread32(a)    __raw_readl(a)

No, this looks like a bug. I would have expected

#define ioread32(a)    readl(a)

in this case. Also, ioread32 should actually multiplex between
readl() and inl() based on the address token, as the code in
lib/iomap.c does. It's probably easy enough to enable
CONFIG_GENERIC_IOMAP on sh, and remove the ioread*/iowrite*
macros from arch/sh/include/asm/io.h.

	Arnd <><

Re: Do cpu-endian MMIO accessors exist?

[Alan Cox]

On Wed, 22 Jul 2009 10:35:49 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday 22 July 2009, Jiri Slaby wrote:
> > No, I should have written this explicitly. I meant read* have a barrier,
> > whereas ioread* do not. Similarly for writes. Is this expected?
> > 
> > For example:
> > #define __raw_readl(a) (__chk_io_ptr(a), *(volatile u32 __force *)(a))
> > #define readl(a)       ({ u32 r_ = __raw_readl(a); mb(); r_; })
> > #define ioread32(a)    __raw_readl(a)
> 
> No, this looks like a bug. I would have expected
> 
> #define ioread32(a)    readl(a)
> 
> in this case. Also, ioread32 should actually multiplex between
> readl() and inl() based on the address token, as the code in
> lib/iomap.c does. It's probably easy enough to enable
> CONFIG_GENERIC_IOMAP on sh, and remove the ioread*/iowrite*
> macros from arch/sh/include/asm/io.h.

If your platform is purely MMIO based then ioread32 and readl can become
the same thing, which is much more efficient. Even if you have port based
devices that are mapped as MMIO surely its more efficient to do the
relevant address tweaking in the iomap not in the read ?

Re: Do cpu-endian MMIO accessors exist?

[Arnd Bergmann]

On Wednesday 22 July 2009, Alan Cox wrote:
> 
> > in this case. Also, ioread32 should actually multiplex between
> > readl() and inl() based on the address token, as the code in
> > lib/iomap.c does. It's probably easy enough to enable
> > CONFIG_GENERIC_IOMAP on sh, and remove the ioread*/iowrite*
> > macros from arch/sh/include/asm/io.h.
> 
> If your platform is purely MMIO based then ioread32 and readl can become
> the same thing, which is much more efficient. Even if you have port based
> devices that are mapped as MMIO surely its more efficient to do the
> relevant address tweaking in the iomap not in the read ?

I did check that the architecture in question (sh) cannot do this,
because it actually implements board specific PIO functions in
arch/sh/boards/mach-*/io.c.

For architectures that don't need such hacks, I fully agree.

	Arnd <><

Re: Do cpu-endian MMIO accessors exist?

[Paul Mundt]

On Wed, Jul 22, 2009 at 03:44:40PM +0200, Arnd Bergmann wrote:
> On Wednesday 22 July 2009, Alan Cox wrote:
> > 
> > > in this case. Also, ioread32 should actually multiplex between
> > > readl() and inl() based on the address token, as the code in
> > > lib/iomap.c does. It's probably easy enough to enable
> > > CONFIG_GENERIC_IOMAP on sh, and remove the ioread*/iowrite*
> > > macros from arch/sh/include/asm/io.h.
> > 
> > If your platform is purely MMIO based then ioread32 and readl can become
> > the same thing, which is much more efficient. Even if you have port based
> > devices that are mapped as MMIO surely its more efficient to do the
> > relevant address tweaking in the iomap not in the read ?
> 
> I did check that the architecture in question (sh) cannot do this,
> because it actually implements board specific PIO functions in
> arch/sh/boards/mach-*/io.c.
> 
> For architectures that don't need such hacks, I fully agree.
> 
SH doesn't really need it either, it is mostly legacy crap that was
commonly done for SuperIOs. I've tried to kill off most of it, and most
of the offenders now are in boards that very few people have available or
even use. We're at the point now where the platforms that are the worst
offenders can just be killed off, and the few that matter can be
converted. The generic iomap is a bit tricky given that most peripherals,
PCI I/O and mem space, etc. all fall under non-translatable sections of
the address space, despite being MMIO.