All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Chen <peter.chen@nxp.com>
To: Pawel Laszczak <pawell@cadence.com>
Cc: Felipe Balbi <balbi@kernel.org>,
	Peter Chen <hzpeterchen@gmail.com>,
	USB list <linux-usb@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>, "rogerq@ti.com" <rogerq@ti.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jun Li <jun.li@nxp.com>
Subject: RE: [PATCH 1/1] usb: cdns3: ep0: delete the redundant status stage
Date: Mon, 18 May 2020 11:21:33 +0000	[thread overview]
Message-ID: <AM7PR04MB7157D5C811E0772B84842B798BB80@AM7PR04MB7157.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <DM6PR07MB55294A6614050A8B424FD1CBDDB80@DM6PR07MB5529.namprd07.prod.outlook.com>

 
> >Pawel, would you please confirm it with your design team? I tried to
> >comment out cdns3_ep0_complete_setup at cdns3_ep0_setup_phase for test
> >mode case, the test mode can't work. It means it still needs software
> >setting to notify controller to prepare status stage.
> 
> Sorry. I got something wrong. You have right.  Driver must prepare Status Stage
> itself.
> It's means that origin code is really incorrect and driver sends the second Status
> Stage twice.
> 
> Hardware team confirm also that setting Test Mode in usb_cmd can be done before
> sending Status Stage. Test Mode should start automatically after sending Status
> Stage by controller.
> 
> 

Thanks, Pawel.

If this patch is ok, could you please add your reviewed-by?

Peter

> >
> >> mdelay(1) was added to give controller some time for sending Status
> >> Stage. Status Stage should be send before driver send appropriate
> >> Test Mode in usb_cmd register. If you remove mdelay it can works accidentally
> on your board.
> >
> >If without cdns3_ep0_complete_setup(priv_dev, 0, 1) before mdelay, how
> >the controller knows it needs to prepare status stage, the test mode
> >setting code is behind than it.
> >
> >The focus is: my board can't enter test mode if status stage is
> >prepared before set test mode, it is strange. At other controller, eg,
> >chipidea, we set test mode after receiving the status stage completion
> >interrupt, but at cdns3, there is no status stage completion interrupt.
> >
> >>
> >> Currently I don't have access for testing board so I can't recreate this test again.
> >>
> >> >
> >> >On 20-05-15 12:35:32, Felipe Balbi wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Peter Chen <hzpeterchen@gmail.com> writes:
> >> >> > It seems the yesterday's reply from nxp email account is blocked by ML.
> >> >> > Send it again.
> >> >> >
> >> >> >>
> >> >> >> Peter Chen <peter.chen@nxp.com> writes:
> >> >> >> > Each setup stage will prepare status stage at
> >> >> >> > cdns3_ep0_setup_phase,
> >> >> >>
> >> >> >> care to explain this a little better? The controller itself
> >> >> >> will produce the status stage?
> >> >> >>
> >> >> >
> >> >> > Unlike the other controllers, the CDNS3 does not need to prepare
> >> >> > TD for status stage, it only needs to write register bits
> >> >> > EP_CMD.REQ_CMPL to tell the controller the request service is
> >> >> > completed, and the controller itself will send ACK answer for
> >> >> > the Status Stage after that.
> >> >> > The code sequence like below:
> >> >> >
> >> >> > cdns3_ep0_setup_phase -> cdns3_ep0_complete_setup ->
> >> >> >             writel((send_erdy ? EP_CMD_ERDY : 0) | EP_CMD_REQ_CMPL,
> >> >> >                    &priv_dev->regs->ep_cmd);
> >> >>
> >> >> got it.
> >> >>
> >> >> >> Usually, the way this works is that SETUP stage must be
> >> >> >> *always* prepared by the SW while STATUS stage is prepared
> >> >> >> on-demand, after we get an interrupt from the controller.
> >> >> >>
> >> >> >> Also, I see a possible bug in cdns3_ep0_setup_phase():
> >> >> >>
> >> >> >>         if (result < 0)
> >> >> >>                 cdns3_ep0_complete_setup(priv_dev, 1, 1);
> >> >> >>         else if (priv_dev->ep0_stage == CDNS3_STATUS_STAGE)
> >> >> >>                 cdns3_ep0_complete_setup(priv_dev, 0, 1);
> >> >> >>
> >> >> >> What happens here if result is 0 but ep0_state !=
> CNDS3_STATUS_STAGE?
> >> >> >> Seems like you should have a "stall and restart" somewhere here
> >> >> >> as a default fallback.
> >>
> >> When this case when happen ?
> >>
> >> BTW.  I see one issue in cdns3_ep0_complete_setup.
> >>
> >> The last one in this function is incorrect:
> >> 		cdns3_allow_enable_l1(priv_dev, 1); should be:
> >> 		/* Resume controller before arming transfer. */
> >> 		__cdns3_gadget_wakeup(priv_dev);
> >>
> >
> >Would you please send a patch to fix it?
> >
> >Peter
> >
> >--
> >
> >Thanks,
> >Peter Chen
> 
> Pawel

  reply	other threads:[~2020-05-18 11:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-26 13:07 [PATCH 1/1] usb: cdns3: ep0: delete the redundant status stage Peter Chen
2020-05-05  7:49 ` Felipe Balbi
     [not found]   ` <CAL411-q4euWFrJ5Sp+tocBEsXXYkviQXt_pz_SyHHC=ELNf_sQ@mail.gmail.com>
2020-05-15  9:35     ` Felipe Balbi
2020-05-18  3:49       ` Peter Chen
2020-05-18  4:36         ` Pawel Laszczak
2020-05-18  6:14           ` Peter Chen
2020-05-18  8:30             ` Pawel Laszczak
2020-05-18 11:21               ` Peter Chen [this message]
2020-05-18  8:21         ` Felipe Balbi
2020-05-19  4:20 ` Pawel Laszczak

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=AM7PR04MB7157D5C811E0772B84842B798BB80@AM7PR04MB7157.eurprd04.prod.outlook.com \
    --to=peter.chen@nxp.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hzpeterchen@gmail.com \
    --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 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.