On Wed, Jul 1, 2015 at 1:09 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> 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@xxxxxx> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>