From: Peter Chen <peter.chen@nxp.com>
To: Roger Quadros <rogerq@ti.com>
Cc: "balbi@kernel.org" <balbi@kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
"pawell@cadence.com" <pawell@cadence.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Jun Li <jun.li@nxp.com>
Subject: Re: [PATCH 2/2] usb: cdns3: gadget: toggle cycle bit before reset endpoint
Date: Sun, 16 Feb 2020 13:56:22 +0000 [thread overview]
Message-ID: <20200216135624.GB12539@b29397-desktop> (raw)
In-Reply-To: <97bbbf7d-2718-b6a0-2fda-6cac21643dfe@ti.com>
On 20-02-14 10:48:47, Roger Quadros wrote:
>
>
> On 14/02/2020 09:14, Peter Chen wrote:
> > If there are TRBs pending during clear stall and reset endpoint, the
>
> s/and/or?
I think it is reset operation, just I observe it at these two operations
together.
>
> > DMA will advance after reset operation, but it doesn't be expected,
>
> s/doesn't/isn't?
>
> > since the data has still not be ready (For OUT, the data has still
>
> s/"has still not be"/"is not yet"
>
> (e.g. for OUT, the data is not yet available).
>
> > not received). After the data is ready, there isn't any interrupt
>
> s/"there isn't any"/"there won't be any"
>
> > since the EP_TRADDR has already points to next TRB entry.
>
> remove "has"
>
> >
> > To fix it, it toggles cyclt bit before reset operation, and restore
>
> s/cyclt/cycle
>
> s/restore/restores
>
Will change above typo.
> > it after reset, it could keep DMA stopping.
>
> It prevents DMA from getting stuck up?
It could avoid unexpected DMA advance later due to TRB content has
changed during the reset.
>
> >
> > Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > ---
> > drivers/usb/cdns3/gadget.c | 17 ++++++++++++++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
> > index 1d8a2af35bb0..7b6bb96b91d1 100644
> > --- a/drivers/usb/cdns3/gadget.c
> > +++ b/drivers/usb/cdns3/gadget.c
> > @@ -2595,11 +2595,21 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint *priv_ep)
> > {
> > struct cdns3_device *priv_dev = priv_ep->cdns3_dev;
> > struct usb_request *request;
> > + struct cdns3_request *priv_req;
> > + struct cdns3_trb *trb = NULL;
> > int ret;
> > int val;
> > trace_cdns3_halt(priv_ep, 0, 0);
> > + request = cdns3_next_request(&priv_ep->pending_req_list);
> > + if (request) {
> > + priv_req = to_cdns3_request(request);
> > + trb = priv_req->trb;
> > + if (trb)
> > + trb->control = trb->control ^ 1;
>
> use TRB_CYCLE macro instead of 1.
>
> Is it better to toggle this bit or explicitly set/clear it?
Since we don't know the value for cycle bit, it is better just
toggle it.
>
> > + }
> > +
> > writel(EP_CMD_CSTALL | EP_CMD_EPRST, &priv_dev->regs->ep_cmd);
> > /* wait for EPRST cleared */
> > @@ -2610,10 +2620,11 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint *priv_ep)
> > priv_ep->flags &= ~(EP_STALLED | EP_STALL_PENDING);
> > - request = cdns3_next_request(&priv_ep->pending_req_list);
> > -
> > - if (request)
> > + if (request) {
> > + if (trb)
> > + trb->control = trb->control ^ 1;
>
> same here.
Ok.
--
Thanks,
Peter Chen
prev parent reply other threads:[~2020-02-16 13:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 7:14 [PATCH 0/2] usb: cdns3: two fixes for gadget Peter Chen
2020-02-14 7:14 ` [PATCH 1/2] usb: cdns3: gadget: link trb should point to next request Peter Chen
2020-02-14 7:14 ` [PATCH 2/2] usb: cdns3: gadget: toggle cycle bit before reset endpoint Peter Chen
2020-02-14 7:41 ` Pawel Laszczak
2020-02-16 13:42 ` Peter Chen
2020-02-14 8:48 ` Roger Quadros
2020-02-16 13:56 ` Peter Chen [this message]
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=20200216135624.GB12539@b29397-desktop \
--to=peter.chen@nxp.com \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jun.li@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-usb@vger.kernel.org \
--cc=pawell@cadence.com \
--cc=rogerq@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).