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: Oliver Neukum on 16 Feb 2010 08:40 Am Dienstag, 16. Februar 2010 10:39:46 schrieb Russell King - ARM Linux: > 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. I am afraid for these controllers the controller driver must be responsible for all DMA and cache issues. Indicating the exact requirements to the upper layer would be a battle already lost. so the safe choice is not to set has_dma and the generic layer will leave the issue to the lower level. 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: Oliver Neukum on 16 Feb 2010 08:50 Am Dienstag, 16. Februar 2010 14:40:45 schrieb Shilimkar, Santosh: > > > 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. > > > > I am afraid for these controllers the controller driver must be responsible > > for all DMA and cache issues. Indicating the exact requirements to the > > upper layer would be a battle already lost. > > so the safe choice is not to set has_dma and the generic layer will leave > > the issue to the lower level. > This means don't use dma at all which will almost kill the performance. Why would you be unable to map a buffer in the hcd driver when you know that you'll use DMA? 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: Shilimkar, Santosh on 16 Feb 2010 08:50 > -----Original Message----- > From: Oliver Neukum [mailto:oliver(a)neukum.org] > Sent: Tuesday, February 16, 2010 7:03 PM > To: Russell King - ARM Linux > Cc: Shilimkar, Santosh; Catalin Marinas; Pavel Machek; Greg KH; 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 10:39:46 schrieb Russell King - ARM Linux: > > 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. > > I am afraid for these controllers the controller driver must be responsible > for all DMA and cache issues. Indicating the exact requirements to the > upper layer would be a battle already lost. > so the safe choice is not to set has_dma and the generic layer will leave > the issue to the lower level. This means don't use dma at all which will almost kill the performance. 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: Shilimkar, Santosh on 16 Feb 2010 09:20 > -----Original Message----- > From: Oliver Neukum [mailto:oliver(a)neukum.org] > Sent: Tuesday, February 16, 2010 7:17 PM > To: Shilimkar, Santosh > Cc: Russell King - ARM Linux; Catalin Marinas; Pavel Machek; Greg KH; 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 14:40:45 schrieb Shilimkar, Santosh: > > > > 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. > > > > > > I am afraid for these controllers the controller driver must be responsible > > > for all DMA and cache issues. Indicating the exact requirements to the > > > upper layer would be a battle already lost. > > > so the safe choice is not to set has_dma and the generic layer will leave > > > the issue to the lower level. > > This means don't use dma at all which will almost kill the performance. > > Why would you be unable to map a buffer in the hcd driver when you know > that you'll use DMA? Probably it can be. The USB stack has the dma maintenance code at common place for all controllers and hence we were just trying to see if there is way to handle that way. We shall check this possibility 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 09:30
Am Dienstag, 16. Februar 2010 15:12:45 schrieb Shilimkar, Santosh: > > > > I am afraid for these controllers the controller driver must be responsible > > > > for all DMA and cache issues. Indicating the exact requirements to the > > > > upper layer would be a battle already lost. > > > > so the safe choice is not to set has_dma and the generic layer will leave > > > > the issue to the lower level. > > > This means don't use dma at all which will almost kill the performance. > > > > Why would you be unable to map a buffer in the hcd driver when you know > > that you'll use DMA? > Probably it can be. The USB stack has the dma maintenance code at common > place for all controllers and hence we were just trying to see if there is > way to handle that way. This is true. If you can find a clean way to describe your requirements to the generic layer, that would be better. The problem is that we must not end up with a dozen flags. Your original patch however kills ehci, ohci and uhci on some architectures. 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/ |