RE: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM
From: Benjamin Herrenschmidt
Date: Sun Oct 17 2010 - 19:19:22 EST
On Sun, 2010-10-17 at 08:05 -0500, Woodruff, Richard wrote:
> ARM has always been a rawer (and cheaper) environment than many other
> CPU architectures. Until maybe this year coherency was never even an
> option provided in the hardware. The vast majority of the systems
> currently in mass production in 2010 and before don't have coherency.
> The software has to handle all the details.
>
> Starting today and onwards coherency options will start to be seen in
> high end. It seems likely some of the old external IP won't be
> compliant and likely have bugs undercutting it.
>
> People from high ends like x86 and PPC have different expectations and
> problems. Your chip set nightmares are our standard in some areas. In
> my narrow experience PPC pioneered many techniques 15 years back which
> are now just coming into ARM. They are coming in at a much reduced
> power and cost footprint.
This is all quite possible the the fact remains that at the end of the
day, if you're going to have a speculative memory model with prefetch
and your architecture (rightfully so) disallows aliasing of mappings
with different cache attributes, then you are screwed the minute your
devices do non-coherent DMA :-)
As Russell says, the only proper way to do that would be to set aside
memory at boot. That or provide a way to take chunks out of the linear
mapping, which may or may not be possible, I don't know how ARM does it
well enough. On some 32-bit powerpc's unfortunately, that would meant
taking whole 256M chunks out due to the way we implement it.
The main problem is usually related to the linear mapping using some
form of huge pages, I suppose this is the same for you here.
Now of course, you always have the un-satisfactory options of disabling
speculation/prefetch and/or disabling the use of such huge pages in the
linear mapping, which makes unmapping chunks of it a lot easier.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/