USB mass storage and ARM cache coherency
in [Kernel]
|
Prev: [PATCH 0/3] HID: make raw output callback more flexible
Next: kprobes: Disable booster when CONFIG_PREEMPT=y
From: Benjamin Herrenschmidt on 17 Feb 2010 04:50 On Wed, 2010-02-17 at 10:15 +0100, Oliver Neukum wrote: > We should have changed the subject line. > > There's a second problem. It turns out that on ARM > mapping for DMA must not be done if PIO will be used. Some HCDs > use PIO for some transfers but DMA for others. The generic layer > must learn about this. Ah, that makes a lot of sense and the same problem would happen on any non-DMA coherent architecture, including some embedded ppc's. I can see why the dma unmap would invalidate the dcache and blow away the PIO. What bugs me here is that the dma_map_* operation should always be done at the lowest level, ie, the actual HCD driver, and thus it should be up to the HCD to decide whether to dma_map or not depending on whether it's going to do DMA or not. I haven't scrutinized USB lately but if that isn't the case and the dma_map_* operations are done behind your back by the USB core then that needs to be changed in a way or another, or hooked at least. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Sascha Hauer on 17 Feb 2010 05:00 On Mon, Feb 08, 2010 at 11:03:14AM +0100, Andy Green wrote: > On 02/08/10 10:51, Somebody in the thread at some point said: > >> We could of course flush the caches every time we get a page fault but >> that's far from optimal, especially since DMA-capable drivers to do not >> pollute the D-cache and don't need this extra flushing. Note that the >> recent ARM processors have PIPT caches but separate for I and D and it's >> the PIO drivers that pollute the D-cache. > > Just noting that AFAIK iMX31 USB and MMC drivers both are PIO at the > moment, for lack of any platform DMA support of its unusual DMA engine. The EHCI module has its own DMA engine and has nothing to do with the SDMA engine. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andy Green on 17 Feb 2010 05:00 On 02/17/10 10:50, Somebody in the thread at some point said: > On Mon, Feb 08, 2010 at 11:03:14AM +0100, Andy Green wrote: >> On 02/08/10 10:51, Somebody in the thread at some point said: >> >>> We could of course flush the caches every time we get a page fault but >>> that's far from optimal, especially since DMA-capable drivers to do not >>> pollute the D-cache and don't need this extra flushing. Note that the >>> recent ARM processors have PIPT caches but separate for I and D and it's >>> the PIO drivers that pollute the D-cache. >> >> Just noting that AFAIK iMX31 USB and MMC drivers both are PIO at the >> moment, for lack of any platform DMA support of its unusual DMA engine. > > The EHCI module has its own DMA engine and has nothing to do with the > SDMA engine. You're right, my mistake. iMX31 MMC is PIO due to no SDMA support though. -Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 17 Feb 2010 05:10 On Wed, Feb 17, 2010 at 08:05:43PM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2010-02-16 at 09:22 +0100, Oliver Neukum wrote: > > This seems wrong to me. Buffers for control transfers may be > > transfered > > by DMA, so the caches must be flushed on architectures whose caches > > are not coherent with respect to DMA. > > > > Would you care to elaborate on the exact nature of the bug you are > > fixing? > > I missed part of this thread, so forgive me if I'm a bit off here, but > if the problem is indeed I$/D$ cache coherency vs. PIO transfers, then > this is a long solved issue on other archs such as ppc (and I _think_ > sparc). Nope. It's to do with mapping a buffer for DMA, and then doing PIO reads/writes to it. With speculative prefetches, you have to deal with cache coherency with hardware DMA on DMA unmap. If you've written to the buffer in violation of the DMA API buffer ownership rules, then your writes get thrown away resulting in immediate data corruption. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 17 Feb 2010 05:10
Am Mittwoch, 17. Februar 2010 10:40:09 schrieb Benjamin Herrenschmidt: > What bugs me here is that the dma_map_* operation should always > be done at the lowest level, ie, the actual HCD driver, and thus > it should be up to the HCD to decide whether to dma_map or not > depending on whether it's going to do DMA or not. I haven't > scrutinized USB lately but if that isn't the case and the dma_map_* > operations are done behind your back by the USB core then that needs to > be changed in a way or another, or hooked at least. No problem here. USB core does the mapping only if the low-level driver so requests. The only exception is in usb_buffer_alloc(), but that boils down to dma_alloc_coherent() Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |