All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Liu <b-liu-l0cyMroinI0@public.gmane.org>
To: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Cc: Alexandre Bailon
	<abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	nsekhar-l0cyMroinI0@public.gmane.org,
	khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
	ptitiano-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org,
	grygorii.strashko-l0cyMroinI0@public.gmane.org,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v3 4/5] usb: musb: musb_cppi41: Workaround DMA stall issue during teardown
Date: Fri, 20 Jan 2017 11:23:00 -0600	[thread overview]
Message-ID: <20170120172300.GA14571@uda0271908> (raw)
In-Reply-To: <20170119165646.GV7403-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

On Thu, Jan 19, 2017 at 08:56:46AM -0800, Tony Lindgren wrote:
> * Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> [170119 06:09]:
> > The DMA may hung up if a teardown is initiated while an endpoint is still
> > active (Advisory 2.3.27 of DA8xx errata).
> > To workaround this issue, add a delay before to initiate the teardown.
> > 
> > Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > ---
> >  drivers/usb/musb/da8xx.c       | 2 +-
> >  drivers/usb/musb/musb_core.h   | 1 +
> >  drivers/usb/musb/musb_cppi41.c | 4 ++++
> >  3 files changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
> > index 5f50a78..8c9850c 100644
> > --- a/drivers/usb/musb/da8xx.c
> > +++ b/drivers/usb/musb/da8xx.c
> > @@ -483,7 +483,7 @@ da8xx_dma_controller_create(struct musb *musb, void __iomem *base)
> >  #endif
> >  
> >  static const struct musb_platform_ops da8xx_ops = {
> > -	.quirks		= MUSB_INDEXED_EP | MUSB_DMA_CPPI41,
> > +	.quirks		= MUSB_INDEXED_EP | MUSB_DMA_CPPI41 | MUSB_DA8XX,
> >  	.init		= da8xx_musb_init,
> >  	.exit		= da8xx_musb_exit,
> >  
> > diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> > index ade902e..d129278 100644
> > --- a/drivers/usb/musb/musb_core.h
> > +++ b/drivers/usb/musb/musb_core.h
> > @@ -172,6 +172,7 @@ struct musb_io;
> >   */
> >  struct musb_platform_ops {
> >  
> > +#define MUSB_DA8XX		BIT(7)
> >  #define MUSB_DMA_UX500		BIT(6)
> >  #define MUSB_DMA_CPPI41		BIT(5)
> >  #define MUSB_DMA_CPPI		BIT(4)
> > diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> > index 1fe7eae..d371d05 100644
> > --- a/drivers/usb/musb/musb_cppi41.c
> > +++ b/drivers/usb/musb/musb_cppi41.c
> > @@ -554,6 +554,10 @@ static int cppi41_dma_channel_abort(struct dma_channel *channel)
> >  		}
> >  	}
> >  
> > +	/* DA8xx Advisory 2.3.27: wait 250 ms before to start the teardown */
> > +	if (musb->io.quirks & MUSB_DA8XX)
> > +		mdelay(250);
> > +
> >  	tdbit = 1 << cppi41_channel->port_num;
> >  	if (is_tx)
> >  		tdbit <<= 16;
> 
> How about replace the do while loop calling  dmaengine_terminate_all() with
> deferred work doing that?

It would be great, but it seems a little hard to implement. If the
_abort is initiated by application due to transfer timeout, the
application might immediately retry the transfer, then the driver would
have to ensure the deferred work is done and the channel is free by that
time.

I guess we have to evaluate the impact of the do-while loop and the
performance impact of the deferred work to know if it is worth it.

> 
> That way it's more generic as it seems there's no hurry doing that
> after the musb registers are cleared. That would also allow getting rid of
> the two current udelay() calls there that also seems nasty.

I don't think replacing the do-while loop will allow to get rid of the
two udelay() calls, which are there as barriers for the register changes
- clearing MUSB_RXCSR_DMAENAB and flushing FIFO.

Regards,
-Bin.
--
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

  parent reply	other threads:[~2017-01-20 17:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-19 14:08 [PATCH v3 0/5] usb: musb: da8xx: Add DMA support Alexandre Bailon
     [not found] ` <20170119140835.18981-1-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-01-19 14:08   ` [PATCH v3 1/5] usb: musb: da8xx: Remove CPPI 3.0 quirk and methods Alexandre Bailon
2017-01-19 14:08   ` [PATCH v3 2/5] usb: musb: Use shared irq Alexandre Bailon
2017-01-19 14:08   ` [PATCH v3 3/5] usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx Alexandre Bailon
     [not found]     ` <20170119140835.18981-4-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-01-19 15:56       ` Alexandre Bailon
2017-01-19 16:38       ` Sergei Shtylyov
2017-01-19 14:08   ` [PATCH v3 4/5] usb: musb: musb_cppi41: Workaround DMA stall issue during teardown Alexandre Bailon
     [not found]     ` <20170119140835.18981-5-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-01-19 16:56       ` Tony Lindgren
     [not found]         ` <20170119165646.GV7403-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2017-01-20 15:03           ` Alexandre Bailon
2017-01-20 17:23           ` Bin Liu [this message]
2017-01-20 18:45             ` Tony Lindgren
2017-01-19 14:08   ` [PATCH v3 5/5] usb: musb: da8xx: Add a primary support of PM runtime Alexandre Bailon
     [not found]     ` <20170119140835.18981-6-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-01-19 16:42       ` Sergei Shtylyov
     [not found]         ` <6287b54d-c5ed-dc2d-2077-3eaa4a4e7d4a-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2017-01-20  5:40           ` Sekhar Nori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170120172300.GA14571@uda0271908 \
    --to=b-liu-l0cymroini0@public.gmane.org \
    --cc=abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
    --cc=grygorii.strashko-l0cyMroinI0@public.gmane.org \
    --cc=khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nsekhar-l0cyMroinI0@public.gmane.org \
    --cc=ptitiano-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
    --cc=sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org \
    --cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.