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 17 Feb 2010 11:20 SORRY - one more message to apologise for the multiple reposts (and automatically appended legal disclaimer). I've been moved to Exchange 2007 and trying to use Evolution + Exchange-MAPI. It looks like it went terribly wrong. Catalin On Wed, 2010-02-17 at 15:40 +0000, Catalin Marinas wrote: > On Wed, 2010-02-17 at 20:05 +1100, Benjamin Herrenschmidt wrote: > > On Tue, 2010-02-16 at 09:22 +0100, Oliver Neukum wrote: > > > 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. > > >=20 > > > Would you care to elaborate on the exact nature of the bug you are > > > fixing? > >=20 > > I missed part of this thread, so forgive me if I'm a bit off here, but > > if the problem is indeed I$/D$ cache coherency vs. PIO transfers, then > > this is a long solved issue on other archs such as ppc (and I _think_ > > sparc). > > The thread I started was indeed regarding I/D cache coherency and PIO. > But it diverged into DMA issues a few days ago (should have been a new > thread). > > > The way we do it, at least on powerpc which is PIPT, is to keep track on > > a per-page basis, whether a given page is clean for execution using > > PG_arch1 bit. This bit is cleared when a new page is popped into the > > page cache, and we clear it from flush_dcache_page() iirc (you may want > > to dbl check I don't have the code at hand right now, or rather, I do > > but I'm to lazy to look right now :-) > > We do the same on ARM. The problem with most (all) HCD drivers that do > PIO is that they copy the data to the transfer buffer but there is no > call in this driver to flush_dcache_page(). The upper mass storage or > filesystem layers don't call this function either, so there isn't > anything that would set the PG_arch1 bit. > > --=20 > Catalin > -- > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 17 Feb 2010 11:30 SORRY - one more message to apologise for the multiple reposts (and automatically appended legal disclaimer). I've been moved to Exchange 2007 and trying to use Evolution + Exchange-MAPI. It looks like it went terribly wrong. Catalin On Wed, 2010-02-17 at 15:40 +0000, Catalin Marinas wrote: > On Wed, 2010-02-17 at 20:05 +1100, Benjamin Herrenschmidt wrote: > > On Tue, 2010-02-16 at 09:22 +0100, Oliver Neukum wrote: > > > 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. > > >=3D20 > > > Would you care to elaborate on the exact nature of the bug you are > > > fixing? > >=3D20 > > I missed part of this thread, so forgive me if I'm a bit off here, but > > if the problem is indeed I$/D$ cache coherency vs. PIO transfers, then > > this is a long solved issue on other archs such as ppc (and I _think_ > > sparc). >=20 > The thread I started was indeed regarding I/D cache coherency and PIO. > But it diverged into DMA issues a few days ago (should have been a new > thread). >=20 > > The way we do it, at least on powerpc which is PIPT, is to keep track o= n > > a per-page basis, whether a given page is clean for execution using > > PG_arch1 bit. This bit is cleared when a new page is popped into the > > page cache, and we clear it from flush_dcache_page() iirc (you may want > > to dbl check I don't have the code at hand right now, or rather, I do > > but I'm to lazy to look right now :-) >=20 > We do the same on ARM. The problem with most (all) HCD drivers that do > PIO is that they copy the data to the transfer buffer but there is no > call in this driver to flush_dcache_page(). The upper mass storage or > filesystem layers don't call this function either, so there isn't > anything that would set the PG_arch1 bit. >=20 > --=3D20 > Catalin > --=20 > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. >=20 > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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 17 Feb 2010 12:10 On Wed, 17 Feb 2010, Shilimkar, Santosh wrote: > How about below approach? Controller driver can set > "uses_pio_for_control" if it can't do dma for control transfer. > > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > index 80995ef..e3eae02 100644 > --- a/drivers/usb/core/hcd.c > +++ b/drivers/usb/core/hcd.c > @@ -1276,7 +1276,7 @@ static int map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb, > > if (usb_endpoint_xfer_control(&urb->ep->desc) > && !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP)) { > - if (hcd->self.uses_dma) { > + if (hcd->self.uses_dma && !hcd->self.uses_pio_for_control) { > urb->setup_dma = dma_map_single( > hcd->self.controller, > urb->setup_packet, > @@ -1335,7 +1335,7 @@ static void unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb) > > if (usb_endpoint_xfer_control(&urb->ep->desc) > && !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP)) { > - if (hcd->self.uses_dma) > + if (hcd->self.uses_dma && !hcd->self.uses_pio_for_control) > dma_unmap_single(hcd->self.controller, urb->setup_dma, > sizeof(struct usb_ctrlrequest), > DMA_TO_DEVICE); > diff --git a/include/linux/usb.h b/include/linux/usb.h > index d7ace1b..ba5b0a2 100644 > --- a/include/linux/usb.h > +++ b/include/linux/usb.h > @@ -329,6 +329,9 @@ struct usb_bus { > int busnum; /* Bus number (in order of reg) */ > const char *bus_name; /* stable id (PCI slot_name etc) */ > u8 uses_dma; /* Does the host controller use DMA? */ > + u8 uses_pio_for_control; /* Does the host controller use PIO > + * for control tansfers? > + */ > u8 otg_port; /* 0, or number of OTG/HNP port */ > unsigned is_b_host:1; /* true during some HNP roleswitches */ > unsigned b_hnp_enable:1; /* OTG: did A-Host enable HNP? */ Why do you skip mapping the setup packet but not the data packet? 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: Russell King - ARM Linux on 17 Feb 2010 15:30 On Wed, Feb 17, 2010 at 12:02:21PM -0500, Alan Stern wrote: > Why do you skip mapping the setup packet but not the data packet? This is something of a FAQ in this thread. Here are the responses to similar questions yesterday: "Gadiyar, Anand" <gadiyar(a)ti.com> said: > 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. "Shilimkar, Santosh" <santosh.shilimkar(a)ti.com> said: > 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. -- 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: Benjamin Herrenschmidt on 17 Feb 2010 15:40
On Wed, 2010-02-17 at 15:27 +0000, Catalin Marinas wrote: > We do the same on ARM. The problem with most (all) HCD drivers that do > PIO is that they copy the data to the transfer buffer but there is no > call in this driver to flush_dcache_page(). The upper mass storage or > filesystem layers don't call this function either, so there isn't > anything that would set the PG_arch1 bit. Actually, clear it :-) I suppose that's one thing that needs to be fixed in the drivers. Cheers, Ben. -- 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/ |