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: Russell King - ARM Linux on 16 Feb 2010 03:50 On Tue, Feb 16, 2010 at 01:27:53PM +0530, Shilimkar, Santosh wrote: > 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) if (usb_endpoint_xfer_control(&urb->ep->desc) && !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP)) { if (hcd->self.uses_dma) { <================= urb->setup_dma = dma_map_single( hcd->self.controller, urb->setup_packet, sizeof(struct usb_ctrlrequest), DMA_TO_DEVICE); struct usb_hcd *usb_create_hcd (const struct hc_driver *driver, struct device *dev, const char *bus_name) { .... hcd->self.uses_dma = (dev->dma_mask != NULL); Is it easier to make sure that PIO devices don't have dev->dma_mask set? -- 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: Gadiyar, Anand on 16 Feb 2010 04:00 Russell King - ARM Linux wrote: > On Tue, Feb 16, 2010 at 01:27:53PM +0530, Shilimkar, Santosh wrote: > > 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) > > if (usb_endpoint_xfer_control(&urb->ep->desc) > && !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP)) { > if (hcd->self.uses_dma) { <================= > urb->setup_dma = dma_map_single( > hcd->self.controller, > urb->setup_packet, > sizeof(struct usb_ctrlrequest), > DMA_TO_DEVICE); > > struct usb_hcd *usb_create_hcd (const struct hc_driver *driver, > struct device *dev, const char *bus_name) > { > ... > hcd->self.uses_dma = (dev->dma_mask != NULL); > > Is it easier to make sure that PIO devices don't have dev->dma_mask set? Not really. For instance, in the case of the DMA engine in the MUSB controller in OMAP3, we can only use DMA with endpoints other than EP0, and EP0 is what is used for control transfers. It's not PIO for all the endpoints or DMA for all of them. - Anand -- 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 04:00 > -----Original Message----- > From: Oliver Neukum [mailto:oliver(a)neukum.org] > Sent: Tuesday, February 16, 2010 1:53 PM > To: Shilimkar, Santosh > Cc: Catalin Marinas; Pavel Machek; Greg KH; Russell King - ARM Linux; Matthew Dharm; Sergei Shtylyov; > Ming Lei; Sebastian Siewior; linux-usb(a)vger.kernel.org; linux-kernel; linux-arm-kernel; Mankad, > Maulik Ojas > Subject: Re: USB mass storage and ARM cache coherency > > 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. 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. 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. Regards, Santosh -- 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 04:10 Am Dienstag, 16. Februar 2010 09:55:55 schrieb Shilimkar, Santosh: > > 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. Given that the generic layer can't know which buffers will be used for DMA that would require a callback into the hcd driver. > > 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. > > 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. How does the mapping corrupt buffers? It might impact performance, but why do you see corruption? 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/
From: Russell King - ARM Linux on 16 Feb 2010 04:50
On Tue, Feb 16, 2010 at 10:07:20AM +0100, Oliver Neukum wrote: > Am Dienstag, 16. Februar 2010 09:55:55 schrieb Shilimkar, Santosh: > > > 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. > > > > 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. > > How does the mapping corrupt buffers? It might impact performance, but why > do you see corruption? On map, buffers are cleaned if they're being used for DMA_TO_DEVICE and DMA_BIDIRECTIONAL, or invalidated in the case of DMA_FROM_DEVICE. However, because ARM CPUs can now speculatively prefetch, just leaving it at that results in corruption of buffers used for DMA. So we have to invalidate DMA_FROM_DEVICE and DMA_BIDIRECTIONAL buffers on unmap to ensure coherency with DMA operations. If the CPU writes to a DMA_FROM_DEVICE buffer between map and unmap, the writes can sit in the cache, and on unmap, they will be discarded. Cleaning the cache on unmap is not an option; that too can lead to DMA buffer corruption in the DMA case. USB and associated host driver must abide by the DMA API buffer ownership rules otherwise the result will be data corruption; either that or USB/host driver people need to have a discussion with the DMA API authors to remove this sensible "restriction". -- 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/ |