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 2 Feb 2010 08:10 Am Dienstag, 2. Februar 2010 13:39:35 schrieb Catalin Marinas: > > For storage that is correct. But what about other sources of pages, > > for example iSCSI? > > In the iSCSI case, does the HCD driver write directly to a page cache > page? Or it just fills in network packets that are copied to page cache > pages by the iSCSI code (sorry, I'm not familiar with this part of the > kernel). If the latter, the cache flushing in the HCD driver would not > help and it needs to be done in the iSCSI code. As far as I can tell iSCSI does a private copy. But I don't know how many methods to transfer code pages over USB exist. I'd say the conservative solution is to flush for everything but control transfers. 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 2 Feb 2010 08:50 2010/2/2 Catalin Marinas <catalin.marinas(a)arm.com>: > In the iSCSI case, does the HCD driver write directly to a page cache > page? Or it just fills in network packets that are copied to page cache > pages by the iSCSI code (sorry, I'm not familiar with this part of the > kernel). If the latter, the cache flushing in the HCD driver would not > help and it needs to be done in the iSCSI code. So we should flush dcache page in the place where the user mapped page is copied to, instead of low level driver which does not do such thing always. -- 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 2 Feb 2010 09:40 On Tue, 2010-02-02 at 13:36 +0000, Ming Lei wrote: > 2010/2/2 Catalin Marinas <catalin.marinas(a)arm.com>: > > > In the iSCSI case, does the HCD driver write directly to a page cache > > page? Or it just fills in network packets that are copied to page cache > > pages by the iSCSI code (sorry, I'm not familiar with this part of the > > kernel). If the latter, the cache flushing in the HCD driver would not > > help and it needs to be done in the iSCSI code. > > So we should flush dcache page in the place where the user mapped > page is copied to, instead of low level driver which does not do such > thing always. Or both if you can't be sure whether the driver copies directly to a page cache page. -- 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: Clemens Ladisch on 2 Feb 2010 09:50 Andreas Mohr wrote: > On Tue, Feb 02, 2010 at 01:07:56PM +0100, Oliver Neukum wrote: > > Am Dienstag, 2. Februar 2010 13:01:12 schrieb Catalin Marinas: > > > On Tue, 2010-02-02 at 11:48 +0000, Oliver Neukum wrote: > > > > Am Montag, 1. Februar 2010 18:29:14 schrieb Catalin Marinas: > > > > Is it correct to limit this to BULK pipes? > > > > > > I'm not entirely sure. The flush_dcache_page() should only be called for > > > pages that may be mapped into user space (page cache pages). We don't > > > need this for control buffers. It was my impression that what's coming > > > from the mass storage layer intended for page cache pages has the > > > PIPE_BULK type (I may be wrong though). > > > > For storage that is correct. But what about other sources of pages, > > for example iSCSI? > > Or... usb-audio? I should have verified that it is using bulk endpoints > (and thus the patch applies to my case). > usb-audio probably uses isochronous transfers, thus that would be > an obvious reason why the patch didn't work for me. snd-usb-audio indeed uses isochronous transfers, but those buffers are never mapped into user space. The intermediate vmalloc()ed buffer is, however, and there was a bugfix for this recently. Do you have these patches in your tree? http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=3e879d7bac705be4813a0ec9560cbe31db4b269f http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=c32d977b8157bf67cdf47729ce7dd054a26eb534 Best regards, Clemens -- 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 2 Feb 2010 10:00
Am Dienstag, 2. Februar 2010 15:42:49 schrieb Clemens Ladisch: > > Or... usb-audio? I should have verified that it is using bulk endpoints > > (and thus the patch applies to my case). > > usb-audio probably uses isochronous transfers, thus that would be > > an obvious reason why the patch didn't work for me. > > snd-usb-audio indeed uses isochronous transfers, but those buffers are > never mapped into user space. The intermediate vmalloc()ed buffer is, > however, and there was a bugfix for this recently. Do you have these > patches in your tree? Now that I think about it, several video drivers do map it to user space. 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/ |