On Tue, Jul 05, 2011 at 03:58:39PM +0200, Arnd Bergmann wrote: > Ah, sorry I missed that patch on the mailing list, found it now in > your for-next branch. I've been searching for this email to reply to for the last day or so... > If I'm reading your "ARM: DMA: steal memory for DMA coherent mappings" > correctly, the idea is to have a per-platform compile-time amount > of memory that is reserved purely for coherent allocations and > taking out of the buddy allocator, right? Yes, because every time I've looked at taking out memory mappings in the first level page tables, it's always been a major issue. We have a method where we can remove first level mappings on uniprocessor systems in the ioremap code just fine - we use that so that systems can setup section and supersection mappings. They can tear them down as well - and we update other tasks L1 page tables when they get switched in. This, however, doesn't work on SMP, because if you have a DMA allocation (which is permitted from IRQ context) you must have some way of removing the L1 page table entries from all CPUs TLBs and the page tables currently in use and any future page tables which those CPUs may switch to. The easy bit is "future page tables" - that can be done in the same way as the ioremap() code does with a generation number, checked when a new page table is switched in. The problem is the current CPUs, and as we know trying to call smp_call_function() with IRQs disabled is not permitted due to deadlock. So, in a SMP system, there is no safe way to remove L1 page table entries from IRQ context. That means if memory is mapped for the buddy allocators using L1 page table entries, then it is fixed for that application on a SMP system. However, that's not really what I wanted to find this email for. That is I'm dropping the "ARM: DMA: steal memory for DMA coherent mappings" patch for this merge window because - as I found out yesterday - it prevents the Assabet platform booting, and so would be a regression. Plus, I have a report of a regression with the streaming DMA API speculative prefetch fixes causing the IOP ADMA raid5 async offload stuff to explode - which may result in the streaming DMA API fixes being reverted (which will leave ARMv6+ vulnerable to data corruption.) As I have no time to work through the RAID5 code, async_tx code, and IOP ADMA code to get to the bottom of it (because of this flood of patches) I think a revert is looking likely - either that or I'll have to tell the bug reporter to go away, which really isn't on. It's on LKML if anyone's interested in trying to diagnose it, the "PROBLEM: ARM-dma-mapping-fix-for-speculative-prefetching cause OOPS" thread. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
