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 29 Jan 2010 09:40 Hi Matthew, I've been trying for some time to use a rootfs (ext2) on a USB memory stick on ARM platforms but without any success. The USB HCD driver is ISP1760 which doesn't use DMA. ARM has a Harvard cache architecture and what I get is incoherency between the I and D caches. The CPU I'm using (ARM11MPCore) has PIPT caches with D-cache lines allocation on write. Basically, when user space tries to execute from a new page, it faults and the data is requested via the VFS layer, SCSI block device and USB mass storage from the ISP1760 driver. The page is then mapped into user space and update_mmu_cache() called. However, since the driver is PIO, the data copied from the USB device into RAM gets stuck in the D-cache. On the above page requesting path there is no call to flush_dcache_page() to handle D-cache maintenance (for DMA drivers, that's handled by the DMA API). Since the USB mass storage code has the information about the USB driver capabilities (DMA or PIO), it looks like the best place to call flush_dcache_page(). But I got lost in the SCSI emulation and all my attempts failed to get a working rootfs. Adding flush_dcache_page() higher up in mpage_end_io_read() solves the problem but that's not the correct fix as it has wider implications and it's not needed for DMA-capable devices. Thanks. -- 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: Oliver Neukum on 29 Jan 2010 11:20 Am Freitag, 29. Januar 2010 15:34:15 schrieb Catalin Marinas: > Basically, when user space tries to execute from a new page, it faults > and the data is requested via the VFS layer, SCSI block device and USB > mass storage from the ISP1760 driver. The page is then mapped into user > space and update_mmu_cache() called. > > However, since the driver is PIO, the data copied from the USB device > into RAM gets stuck in the D-cache. On the above page requesting path > there is no call to flush_dcache_page() to handle D-cache maintenance > (for DMA drivers, that's handled by the DMA API). > > Since the USB mass storage code has the information about the USB driver > capabilities (DMA or PIO), it looks like the best place to call > flush_dcache_page(). But I got lost in the SCSI emulation and all my > attempts failed to get a working rootfs. No, that would be a very bad place in the layering to do this. The problem would happen with ub and storage. It might also happen with any other driver. Please add this to the HCD driver. 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: Ming Lei on 29 Jan 2010 11:30 2010/1/29 Catalin Marinas <catalin.marinas(a)arm.com>: > Hi Matthew, > > I've been trying for some time to use a rootfs (ext2) on a USB memory > stick on ARM platforms but without any success. The USB HCD driver is > ISP1760 which doesn't use DMA. > > ARM has a Harvard cache architecture and what I get is incoherency > between the I and D caches. The CPU I'm using (ARM11MPCore) has PIPT > caches with D-cache lines allocation on write. > > Basically, when user space tries to execute from a new page, it faults > and the data is requested via the VFS layer, SCSI block device and USB > mass storage from the ISP1760 driver. The page is then mapped into user > space and update_mmu_cache() called. > > However, since the driver is PIO, the data copied from the USB device > into RAM gets stuck in the D-cache. On the above page requesting path > there is no call to flush_dcache_page() to handle D-cache maintenance > (for DMA drivers, that's handled by the DMA API). > > Since the USB mass storage code has the information about the USB driver Sorry, I am a little confused that usb mass storage has what information about DMA or PIO of low level usb transfer? Thanks, -- 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: Catalin Marinas on 29 Jan 2010 11:40 On Fri, 2010-01-29 at 16:23 +0000, Ming Lei wrote: > 2010/1/29 Catalin Marinas <catalin.marinas(a)arm.com>: > > I've been trying for some time to use a rootfs (ext2) on a USB memory > > stick on ARM platforms but without any success. The USB HCD driver is > > ISP1760 which doesn't use DMA. > > > > ARM has a Harvard cache architecture and what I get is incoherency > > between the I and D caches. The CPU I'm using (ARM11MPCore) has PIPT > > caches with D-cache lines allocation on write. > > > > Basically, when user space tries to execute from a new page, it faults > > and the data is requested via the VFS layer, SCSI block device and USB > > mass storage from the ISP1760 driver. The page is then mapped into user > > space and update_mmu_cache() called. > > > > However, since the driver is PIO, the data copied from the USB device > > into RAM gets stuck in the D-cache. On the above page requesting path > > there is no call to flush_dcache_page() to handle D-cache maintenance > > (for DMA drivers, that's handled by the DMA API). > > > > Since the USB mass storage code has the information about the USB driver > > Sorry, I am a little confused that usb mass storage has what information > about DMA or PIO of low level usb transfer? I was thinking about checking dev->bus->controller->dma_mask which the code (though not the storage one) seems to imply that if the dma_mask is 0, the HCD driver is only capable of PIO. That would be a more general solution rather than going through each HCD driver since my understanding is that flush_dcache_page() is only needed together with the mass storage support. -- 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: Oliver Neukum on 29 Jan 2010 11:50
Am Freitag, 29. Januar 2010 17:34:03 schrieb Catalin Marinas: > I was thinking about checking dev->bus->controller->dma_mask which the > code (though not the storage one) seems to imply that if the dma_mask is > 0, the HCD driver is only capable of PIO. That a HCD is capable of DMA need not imply that DMA is used for every transfer. > That would be a more general solution rather than going through each HCD > driver since my understanding is that flush_dcache_page() is only needed > together with the mass storage support. What about ub, nfs or nbd over a USB<->ethernet converter? This, I am afraid is best solved at the HCD or glue layer. 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/ |