usb.org CV MSC test for CDNS3

usb.org CV MSC test for CDNS3

[Peter Chen]

Hi Pawel,

Does the upstream version Cadence driver pass CV MSC test at your
side? I met an issue for “Error Recovery Test”, It needs to clear halt
for ep1-out, but ep1-out’s request is pending. After ep is reset,
and set doorbell again, the transfer begins at once, and receive TRBERR
interrupt, but the host still not sends CBW, so when the host sends CBW,
the device side can’t receive any interrupts due to there is no TRB is
pending.

Call __cdns3_gadget_ep_clear_halt for OUT will trigger TRBERR interrupt,
and advance the TRADDR value if there is a pending TRB, does it be
expected?

To fix this issue, it needs to change several places, and I make it
partial work to use the next TRB for the same pending request.
I don't know if it is correct way, since you may more familiar with
your IP, you could give me some suggestions if possible,
thanks in advance.

-- 

Thanks,
Peter Chen

RE: usb.org CV MSC test for CDNS3

[Pawel Laszczak]

Hi Peter, 

Which version kernel exactly do you means ? 
In v5.6-rc*  there has been added stream support. I didn't check it with CV MSC.

On 5.5 the CV MSC passed some months ago.

#define DEV_VER_NXP_V1		0x00024502
Did you still use controller version 0x00024502 ?

>Hi Pawel,
>
>Does the upstream version Cadence driver pass CV MSC test at your
>side? I met an issue for “Error Recovery Test”, It needs to clear halt
>for ep1-out, but ep1-out’s request is pending. After ep is reset,
>and set doorbell again, the transfer begins at once, and receive TRBERR
>interrupt, but the host still not sends CBW, so when the host sends CBW,
>the device side can’t receive any interrupts due to there is no TRB is
>pending.
>
>Call __cdns3_gadget_ep_clear_halt for OUT will trigger TRBERR interrupt,
>and advance the TRADDR value if there is a pending TRB, does it be
>expected?

I don't remember such issue on my side but the spec say: 
"After endpoint reset the software is responsible
for it to re-set the Endpoint TRADDR."
 
Re-arming transfer on the same TRB should not generate TRBERR, it's 
means that probably the TRADDR  advance to next TRB. 

What about saving TRADDR before making reset and restoring it after reset.

If it works we will have simple change only in one place. 

Regards,
Pawel

>
>To fix this issue, it needs to change several places, and I make it
>partial work to use the next TRB for the same pending request.
>I don't know if it is correct way, since you may more familiar with
>your IP, you could give me some suggestions if possible,
>thanks in advance.
>
>--
>
>Thanks,
>Peter Chen

RE: usb.org CV MSC test for CDNS3

[Felipe Balbi]

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


Hi,

(no top-posting)

Pawel Laszczak <pawell@cadence.com> writes:

> Hi Peter, 
>
> Which version kernel exactly do you means ? 
> In v5.6-rc*  there has been added stream support. I didn't check it with CV MSC.
>
> On 5.5 the CV MSC passed some months ago.

How did you load MSC gadget? Did you have the stall flag set or cleared?

I see that cdns3 doesn't implement set_halt for ep0, that should be
implemented.

> #define DEV_VER_NXP_V1		0x00024502
> Did you still use controller version 0x00024502 ?
>
>>Hi Pawel,
>>
>>Does the upstream version Cadence driver pass CV MSC test at your
>>side? I met an issue for “Error Recovery Test”, It needs to clear halt
>>for ep1-out, but ep1-out’s request is pending. After ep is reset,
>>and set doorbell again, the transfer begins at once, and receive TRBERR
>>interrupt, but the host still not sends CBW, so when the host sends CBW,
>>the device side can’t receive any interrupts due to there is no TRB is
>>pending.
>>
>>Call __cdns3_gadget_ep_clear_halt for OUT will trigger TRBERR interrupt,
>>and advance the TRADDR value if there is a pending TRB, does it be
>>expected?
>
> I don't remember such issue on my side but the spec say: 
> "After endpoint reset the software is responsible
> for it to re-set the Endpoint TRADDR."
>  
> Re-arming transfer on the same TRB should not generate TRBERR, it's 
> means that probably the TRADDR  advance to next TRB. 
>
> What about saving TRADDR before making reset and restoring it after reset.
>
> If it works we will have simple change only in one place. 

tracepoints may help here

-- 
balbi

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