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: Catalin Marinas on 8 Feb 2010 06:30 On Mon, 2010-02-08 at 10:52 +0000, Pavel Machek wrote: > > On Mon, 2010-02-08 at 06:55 +0000, Pavel Machek wrote: > > > > > So, let's put this in the HCD drivers and be done with it. > > > > > > > > The patch below is what fixes the I-D cache incoherency issues on ARM. I > > > > don't particularly like the solution but it seems to be the only one > > > > available. > > > > > > Really? It looks like arm should just flush the caches when mapping > > > executable page to the userspace.... you can't expect all the drivers > > > to be modified like that... > > > > 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 > > Maybe far for optimal, but it is something that should be done, > _first_. Correctness is more important than performance, and you can't > expect all drivers to behave like you want them. I wouldn't call heavy cache flushing "correctness". We could as well disable the caches so that it is fully coherent. The arch code follows an API defined in cachetlb.txt but the PIO drivers don't (some do, like mmci.c). It may be inconvenient to call flush_dcache_page() in the driver, hence I started a discussion on linux-arch on a PIO mapping API that x86 or other fully coherent architectures can leave it as no-ops. > Then you can add optimalizations not to do the flushes on drivers you > audited and where you care... Sorry but that's not really feasible (unless I don't fully understand what you mean) - if we do the cache flushing on the fault handling path in the arch code, there is no way for the arch code to know what driver is doing, unless we make this conditionally compiled with something like CONFIG_ARCH_NEEDS_HEAVY_FLUSHING. -- Catalin -- 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: Ming Lei on 16 Feb 2010 22:30 2010/2/16 Shilimkar, Santosh <santosh.shilimkar(a)ti.com>: >> > We have a below temporary patch to get around the issue and probably it >> > needs to be fixed in the right way in the stack because some controllers >> > may not have PIO option even for control transfers. (e.g. Synopsis EHCI >> > controller) Your temporary patch only removes dma map and umap for setup buffer in control transfer. >> >> 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. > Indeed and that's what I mentioned in the comment. But we shouldn't have dma > cache maintenance operations done for the buffers which would use pio based transfer. >> Would you care to elaborate on the exact nature of the bug you are fixing? > On the OMAP4 (ARM cortex-a9) platform, the enumeration fails because control > transfer buffers are corrupted. On our platform, we use PIO mode for control > transfers and DMA for bulk transfers. I don't know you mean you use PIO mode for seup buffer only or whole control transfer(setup sent, data in or data out). If you mean do not use DMA for setup sent, data in or data out in a control transfer, your temporary patch maybe is not enough, right? > > The current stack performs dma cache maintenance even for the PIO transfers > which leads to the corruption issue. The control buffers are handled by CPU > and they already coherent from CPU point of view. -- Lei Ming -- 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: Alan Stern on 16 Feb 2010 10:50 On Tue, 16 Feb 2010, Shilimkar, Santosh wrote: > > Your original patch however kills ehci, ohci and uhci on some architectures. > Well the patch was making _ONLY_ control transfers use PIO and rest of > the transfer would still use dma. So not sure how much performance impact would > be because of that. > Another issue with that patch is there are few controllers which can't do PIO > at all and hence the patch would broke those controllers. More than "a few"! None of the EHCI, OHCI, or UHCI controllers used in Intel-compatible desktop and laptop systems can do PIO. That's what Oliver meant. Alan Stern -- 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: Shilimkar, Santosh on 16 Feb 2010 03:00 > -----Original Message----- > From: linux-arm-kernel-bounces(a)lists.infradead.org [mailto:linux-arm-kernel- > bounces(a)lists.infradead.org] On Behalf Of Catalin Marinas > Sent: Monday, February 08, 2010 4:58 PM > To: Pavel Machek > Cc: Matthew Dharm; Sergei Shtylyov; Ming Lei; Sebastian Siewior; linux-usb(a)vger.kernel.org; linux- > kernel; Greg KH; linux-arm-kernel > Subject: Re: USB mass storage and ARM cache coherency > > On Mon, 2010-02-08 at 10:52 +0000, Pavel Machek wrote: > > > On Mon, 2010-02-08 at 06:55 +0000, Pavel Machek wrote: > > > > > > So, let's put this in the HCD drivers and be done with it. > > > > > > > > > > The patch below is what fixes the I-D cache incoherency issues on ARM. I > > > > > don't particularly like the solution but it seems to be the only one > > > > > available. > > > > > > > > Really? It looks like arm should just flush the caches when mapping > > > > executable page to the userspace.... you can't expect all the drivers > > > > to be modified like that... > > > > > > 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 > > > > Maybe far for optimal, but it is something that should be done, > > _first_. Correctness is more important than performance, and you can't > > expect all drivers to behave like you want them. > > I wouldn't call heavy cache flushing "correctness". We could as well > disable the caches so that it is fully coherent. > > The arch code follows an API defined in cachetlb.txt but the PIO drivers > don't (some do, like mmci.c). It may be inconvenient to call > flush_dcache_page() in the driver, hence I started a discussion on > linux-arch on a PIO mapping API that x86 or other fully coherent > architectures can leave it as no-ops. > > > Then you can add optimalizations not to do the flushes on drivers you > > audited and where you care... > > Sorry but that's not really feasible (unless I don't fully understand > what you mean) - if we do the cache flushing on the fault handling path > in the arch code, there is no way for the arch code to know what driver > is doing, unless we make this conditionally compiled with something like > CONFIG_ARCH_NEEDS_HEAVY_FLUSHING. Continuing on the USB issue w.r.t cache coherency, the usb host code is violating the buffer ownership rules of streaming APIs from dma and non-dma transfers point if view. We have a below temporary patch to get around the issue and probably it needs to be fixed in the right way in the stack because some controllers may not have PIO option even for control transfers. (e.g. Synopsis EHCI controller) From: Maulik Mankad <x0082077(a)ti.com> USB: Avoid DMA map/unmap of control transfer buffers. This patch avoids the DMA mapping of buffers for control transfers. Signed-off-by: Maulik Mankad <x0082077(a)ti.com> --- Index: omap4_integration/drivers/usb/core/hcd.c =================================================================== --- omap4_integration.orig/drivers/usb/core/hcd.c +++ omap4_integration/drivers/usb/core/hcd.c @@ -1274,6 +1274,10 @@ static int map_urb_for_dma(struct usb_hc if (is_root_hub(urb->dev)) return 0; + if (usb_endpoint_xfer_control(&urb->ep->desc)) + urb->transfer_flags = URB_NO_SETUP_DMA_MAP | + URB_NO_TRANSFER_DMA_MAP; + if (usb_endpoint_xfer_control(&urb->ep->desc) && !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP)) { if (hcd->self.uses_dma) { -- 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 16 Feb 2010 03:30
Am Dienstag, 16. Februar 2010 08:57:53 schrieb Shilimkar, Santosh: > Continuing on the USB issue w.r.t cache coherency, the usb host > code is violating the buffer ownership rules of streaming APIs from > dma and non-dma transfers point if view. > > We have a below temporary patch to get around the issue and probably it > needs to be fixed in the right way in the stack because some controllers > may not have PIO option even for control transfers. (e.g. Synopsis EHCI > controller) 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? 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/ |