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: Gadiyar, Anand on 17 Feb 2010 15:40 Alan Stern wrote: > 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? > I think that's oversight. For this controller, we need to skip mapping all buffers used to do transfers on EP0, which is all control transfers. Will fix in the next version of the patch. - 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: Oliver Neukum on 18 Feb 2010 02:00 Am Mittwoch, 17. Februar 2010 21:30:24 schrieb Gadiyar, Anand: > > Why do you skip mapping the setup packet but not the data packet? > > > > I think that's oversight. For this controller, we need to skip mapping > all buffers used to do transfers on EP0, which is all control transfers. One thing more. Do you have an issue with EP 0 only or all control endpoints? EP 0 must be control, but devices are within spec if they have multiple control endpoints provided EP 0 is control. 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: Gadiyar, Anand on 18 Feb 2010 02:20 Oliver Neukum wrote: > Am Mittwoch, 17. Februar 2010 21:30:24 schrieb Gadiyar, Anand: > > > Why do you skip mapping the setup packet but not the data packet? > > > > > > > I think that's oversight. For this controller, we need to skip mapping > > all buffers used to do transfers on EP0, which is all control transfers. > > One thing more. Do you have an issue with EP 0 only or all control > endpoints? EP 0 must be control, but devices are within spec if they > have multiple control endpoints provided EP 0 is control. Sorry for the confusion. The issue is not with EP 0 of devices connected to the controller; the problem is with EP 0 on the host controller itself. The controller in question is the MUSB OTG controller present in OMAPs, Davinci chips, and some Blackfins. The MUSB HCD driver is written such that it carries out all control transfers on EP 0 of the controller. All bulk transfers are carried out on other hardware endpoints. (This is the same "hardware endpoint" that is used in when the MUSB is used in gadget mode.) I'm not really sure why EP0 was chosen for control transfers, or if there is a restriction that we *need* to use it. Let me study the docs some more. The problem is that with the driver code as written today, we use EP 0 for all control transfers, and the DMA engine cannot do DMA to this endpoint's FIFO. - 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: Oliver Neukum on 19 Feb 2010 16:00 Am Freitag, 19. Februar 2010 18:36:51 schrieb Catalin Marinas: > If a page is already mapped in user space, flush_dcache_page() on ARM > does the flushing rather than deferring it to update_mmu_cache(). The > PIO HCD drivers, however, don't call flush_dcache_page(). Is it possible > that the HCD could transfer data into a page cache page already mapped > in user space? My understanding is that the scenario above is possible. Yes, video drivers do that. 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: Pete Zaitcev on 20 Feb 2010 02:30
On Tue, 16 Feb 2010 14:21:48 +0530 "Gadiyar, Anand" <gadiyar(a)ti.com> wrote: > > 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. The HC driver does not have to be 100% truthful here. If the system is not HIGHMEM, HCD can easily set uses_dma to false yet use DMA by mapping buffers itself, without relying on the quoted code. On a HIGHMEM system, block layer will bounce-buffer data in such case. Hopefuly not a problem for ARM? All network stack drivers work that way, BTW. -- Pete -- 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/ |