| Message ID | 20170117173922.GR7403@atomide.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Tue, Jan 17, 2017 at 09:39:23AM -0800, Tony Lindgren wrote: > * Bin Liu <b-liu@ti.com> [170117 08:49]: > > On Tue, Jan 17, 2017 at 08:31:03AM -0800, Tony Lindgren wrote: > > > * Bin Liu <b-liu@ti.com> [170117 08:22]: > > > > On Tue, Jan 17, 2017 at 08:11:39AM -0800, Tony Lindgren wrote: > > > > > * Bin Liu <b-liu@ti.com> [170117 05:00]: > > > > > > On Mon, Jan 16, 2017 at 03:54:29PM -0800, Tony Lindgren wrote: > > > > > > > Anyways, for the -rc series oops, we can just leave out the WARN_ON > > > > > > > parts for now until drivers/usb/musb/musb_cppi41.c is fixed too. > > > > > > > > > > > > Giving that cppi is a submodule inside the usb subsysytem and it does't > > > > > > have separate power rail or clock, what is the benefit to adding runtime > > > > > > PM in the cppi driver? > > > > > > > > > > Good question. We need at least minimal support to enable things for > > > > > probe and then idle cppi41 properly if only cppi41.ko is loaded with no > > > > > USB modules. > > > > > > > > > > But yeah now that musb does runtime PM based on the cable detection, we > > > > > pretty much guarantee that cppi41 is always enabled when USB is in use. > > > > > > > > > > And if there are no other devices using cppi41 dma on davinci, we can > > > > > simplify the PM runtime a bit for cppi41. > > > > > > > > This might be a good idea. I didn't have much time to play with this > > > > cppi41 runtime PM, but it seems I am having more issues than you and > > > > others seeing. > > > > > > What kind of additional issues are you seeing not described in the $subject > > > patch? > > > > I didn't take a note and don't remember if those are in the $subject > > patch. But > > > > - enumeration begining with a reset that the device doesn't accept > > address X, error code -71; or > > Some of this could be fixed by $subject patch if caused by a race. > Some of it I'm suspecting might be a different issue where cppi41 dma > will just hang until the device is disconnected on 1 sized in dma transfer. > See the experimental patch below. > > > - console fooding with cppi error code -115 after thumb drive enumeration. > > This should get fixed with the $subject patch if we additionally set > the autosuspend_delay to something sufficient, like 1000. > > > Again, I only tried for a few minutes and didn't take a note, since I > > don't have time to look at this ATM. > > Well I'll post what I think we should fix for the -rc series for cppi41. > If you can then please test that a bit and see if it works. Assuming > things work, then all the other changes can be done later on with no > rush. Sure, I will spend some time on this tomorrow morning, and let you know. > > Regards, > > Tony > > 8< ---------------------------------------- > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > --- a/drivers/usb/musb/musb_host.c > +++ b/drivers/usb/musb/musb_host.c > @@ -751,6 +751,15 @@ static void musb_ep_program(struct musb *musb, u8 epnum, > hw_ep->tx_channel = NULL; > } > > + /* > + * At least cppi41 in dma will just hang with size of 1 until the > + * device is connected. For sizes less than 8 it seems to take a > + * long time to complete. Let's use minimum size of 16 to avoid > + * tiny in DMA transfers. > + */ > + if (!is_out && (len < 16)) > + use_dma = 0; I think you also need to add more cleanup in here when not use dma, as in musb_ep_program(): 746 if (is_out && !len) { 747 use_dma = 0; 748 csr = musb_readw(epio, MUSB_TXCSR); 749 csr &= ~MUSB_TXCSR_DMAENAB; 750 musb_writew(epio, MUSB_TXCSR, csr); 751 hw_ep->tx_channel = NULL; 752 } Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Bin Liu <b-liu@ti.com> [170117 11:47]: > On Tue, Jan 17, 2017 at 09:39:23AM -0800, Tony Lindgren wrote: > > * Bin Liu <b-liu@ti.com> [170117 08:49]: > > > On Tue, Jan 17, 2017 at 08:31:03AM -0800, Tony Lindgren wrote: > > > > * Bin Liu <b-liu@ti.com> [170117 08:22]: > > > > > On Tue, Jan 17, 2017 at 08:11:39AM -0800, Tony Lindgren wrote: > > > > > > * Bin Liu <b-liu@ti.com> [170117 05:00]: > > > > > > > On Mon, Jan 16, 2017 at 03:54:29PM -0800, Tony Lindgren wrote: > > > > > > > > Anyways, for the -rc series oops, we can just leave out the WARN_ON > > > > > > > > parts for now until drivers/usb/musb/musb_cppi41.c is fixed too. > > > > > > > > > > > > > > Giving that cppi is a submodule inside the usb subsysytem and it does't > > > > > > > have separate power rail or clock, what is the benefit to adding runtime > > > > > > > PM in the cppi driver? > > > > > > > > > > > > Good question. We need at least minimal support to enable things for > > > > > > probe and then idle cppi41 properly if only cppi41.ko is loaded with no > > > > > > USB modules. > > > > > > > > > > > > But yeah now that musb does runtime PM based on the cable detection, we > > > > > > pretty much guarantee that cppi41 is always enabled when USB is in use. > > > > > > > > > > > > And if there are no other devices using cppi41 dma on davinci, we can > > > > > > simplify the PM runtime a bit for cppi41. > > > > > > > > > > This might be a good idea. I didn't have much time to play with this > > > > > cppi41 runtime PM, but it seems I am having more issues than you and > > > > > others seeing. > > > > > > > > What kind of additional issues are you seeing not described in the $subject > > > > patch? > > > > > > I didn't take a note and don't remember if those are in the $subject > > > patch. But > > > > > > - enumeration begining with a reset that the device doesn't accept > > > address X, error code -71; or > > > > Some of this could be fixed by $subject patch if caused by a race. > > Some of it I'm suspecting might be a different issue where cppi41 dma > > will just hang until the device is disconnected on 1 sized in dma transfer. > > See the experimental patch below. > > > > > - console fooding with cppi error code -115 after thumb drive enumeration. > > > > This should get fixed with the $subject patch if we additionally set > > the autosuspend_delay to something sufficient, like 1000. > > > > > Again, I only tried for a few minutes and didn't take a note, since I > > > don't have time to look at this ATM. > > > > Well I'll post what I think we should fix for the -rc series for cppi41. > > If you can then please test that a bit and see if it works. Assuming > > things work, then all the other changes can be done later on with no > > rush. > > Sure, I will spend some time on this tomorrow morning, and let you know. > > > > > Regards, > > > > Tony > > > > 8< ---------------------------------------- > > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > > --- a/drivers/usb/musb/musb_host.c > > +++ b/drivers/usb/musb/musb_host.c > > @@ -751,6 +751,15 @@ static void musb_ep_program(struct musb *musb, u8 epnum, > > hw_ep->tx_channel = NULL; > > } > > > > + /* > > + * At least cppi41 in dma will just hang with size of 1 until the > > + * device is connected. For sizes less than 8 it seems to take a > > + * long time to complete. Let's use minimum size of 16 to avoid > > + * tiny in DMA transfers. > > + */ > > + if (!is_out && (len < 16)) > > + use_dma = 0; > > I think you also need to add more cleanup in here when not use dma, > as in musb_ep_program(): > > 746 if (is_out && !len) { > 747 use_dma = 0; > 748 csr = musb_readw(epio, MUSB_TXCSR); > 749 csr &= ~MUSB_TXCSR_DMAENAB; > 750 musb_writew(epio, MUSB_TXCSR, csr); > 751 hw_ep->tx_channel = NULL; > 752 } Oh OK. Yeah this one is in the mysteries to unravel category. And I noticed the -71 resets with another USB mass storage device I tried with this patch so clearly not the right fix for that one. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -751,6 +751,15 @@ static void musb_ep_program(struct musb *musb, u8 epnum, hw_ep->tx_channel = NULL; } + /* + * At least cppi41 in dma will just hang with size of 1 until the + * device is connected. For sizes less than 8 it seems to take a + * long time to complete. Let's use minimum size of 16 to avoid + * tiny in DMA transfers. + */ + if (!is_out && (len < 16)) + use_dma = 0; + /* candidate for DMA? */ dma_controller = musb->dma_controller; if (use_dma && is_dma_capable() && epnum && dma_controller) {