Messages in this thread | | | Date | Wed, 1 Jul 2015 09:47:31 -0700 | Subject | Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases | From | Dan Williams <> |
| |
On Wed, Jul 1, 2015 at 1:09 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote: >> On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig <hch@lst.de> wrote: >> >> One useful feature of the ifdef mess as implemented in the patch is >> >> that you could test for whether ioremap_cache() is actually >> >> implemented or falls back to default ioremap(). I think for >> >> completeness archs should publish an ioremap type capabilities mask >> >> for drivers that care... (I can imagine pmem caring), or default to >> >> being permissive if something like IOREMAP_STRICT is not set. There's >> >> also the wrinkle of archs that can only support certain types of >> >> mappings at a given alignment. >> > >> > I think doing this at runtime might be a better idea. E.g. a >> > ioremap_flags with the CACHED argument will return -EOPNOTSUP unless >> > actually implemented. On various architectures different CPUs or >> > boards will have different capabilities in this area. >> >> So it would be the responsibility of the caller to fall back from >> ioremap(..., CACHED) to ioremap(..., UNCACHED)? >> I.e. all drivers using it should be changed... > > Another important point here is to define what the properties of the > mappings are. It's no good just saying "uncached". > > We've recently been around this over the PMEM driver and the broken > addition of ioremap_wt() on ARM... > > By "properties" I mean stuff like whether unaligned accesses permitted, > any kind of atomic access (eg, xchg, cmpxchg, etc). > > This matters: on ARM, a mapping suitable for a device does not support > unaligned accesses or atomic accesses - only "memory-like" mappings > support those. However, memory-like mappings are not required to > preserve access size, number of accesses, etc which makes them unsuitable > for device registers.
I'm proposing that we explicitly switch "memory-like" use cases over to a separate set of "memremap()" apis, as these are no longer "__iomem" [1].
> The problem with ioremap_uncached() in particular is that we have LDD > and other documentation telling people to use it to map device registers, > so we can't define ioremap_uncached() on ARM to have memory-like > properties, and it doesn't support unaligned accesses. > > I have a series of patches which fix up 32-bit ARM for the broken > ioremap_wt() stuff that was merged during this merge window, which I > intend to push out into linux-next at some point (possibly during the > merge window, if not after -rc1) which also move ioremap*() out of line > on ARM but more importantly, adds a load of documentation about the > properties of the resulting mapping on ARM.
Sounds good, I'll look for that before proceeding on this clean up.
[1]: https://lists.01.org/pipermail/linux-nvdimm/2015-June/001331.html
| |