[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090727050031.GA14931@linux-sh.org>
Date: Mon, 27 Jul 2009 14:00:31 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Jiri Slaby <jirislaby@...il.com>, Pekka Paalanen <pq@....fi>,
linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>, linux-sh@...r.kernel.org
Subject: Re: Do cpu-endian MMIO accessors exist?
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists