Re: [PATCHv2] dmaengine: cppi41: Fix oops in cppi41_runtime_resume

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170117 11:47]:
> On Tue, Jan 17, 2017 at 09:39:23AM -0800, Tony Lindgren wrote:
> > * Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170117 08:49]:
> > > On Tue, Jan 17, 2017 at 08:31:03AM -0800, Tony Lindgren wrote:
> > > > * Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170117 08:22]:
> > > > > On Tue, Jan 17, 2017 at 08:11:39AM -0800, Tony Lindgren wrote:
> > > > > > * Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [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 linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html