linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Peter Chen <hzpeterchen@gmail.com>
Cc: Peter Chen <peter.chen@nxp.com>,
	USB list <linux-usb@vger.kernel.org>,
	linux-imx@nxp.com, pawell@cadence.com, rogerq@ti.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	jun.li@nxp.com
Subject: Re: [PATCH 1/1] usb: cdns3: ep0: delete the redundant status stage
Date: Fri, 15 May 2020 12:35:32 +0300	[thread overview]
Message-ID: <87ftc135i3.fsf@kernel.org> (raw)
In-Reply-To: <CAL411-q4euWFrJ5Sp+tocBEsXXYkviQXt_pz_SyHHC=ELNf_sQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]


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.
>>
>
> At cdns3_ep0_setup_phase, the status will be CDNS3_DATA_STAGE
> or CDNS3_STATUS_STAGE according to if there is a data stage.
> If there is a data stage, it will inform of controller ACKing the status
> stage after data stage has finished, it is at: ep0.c,
> cdns3_transfer_completed->cdns3_ep0_complete_setup
>
> But I don't know why it needs to send ERDY for ep0 transfer without
> data stage, but do need for ep0 transfer with data stage. Maybe Pawel
> could explain it. At spec, it only says below for ERDY:

Would be good, indeed. Pawel?

>> Is this backed by documentation or is this something that just happens
>> to work? Pawell, can you confirm that this is the correct programming
>> model?
>>
>
> No documentation, maybe Pawel could confirm with designer.

yeah, Pawel?

>> Is this working against USBCV? What about LeCroy's compliance suite?
>>
>
> For NXP USB certification flow:
>
> The test mode is only used for USB2 electrical test (eg, Eye diagram),
> The HSETT tool is used for device mode which will send command
> from Windows PC to let device enter test mode.
>
> USBCV is used to test protocol level, like USB CH9, Mass Storage protocol
> etc.

Entering test modes is part of chapter9 tests, IIRC.

> For Lecroy's compliance suite, we usually use it for Link test for
> USB3.

You need to run the HS compliance suite ;-) USB3 devices must still
comply with HS/FS/LS.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2020-05-15  9:35 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 [this message]
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
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=87ftc135i3.fsf@kernel.org \
    --to=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=peter.chen@nxp.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).