[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<MN0PR12MB59534165D2775B7DD478C0B2B7D72@MN0PR12MB5953.namprd12.prod.outlook.com>
Date: Sun, 9 Mar 2025 14:55:56 +0000
From: "Pandey, Radhey Shyam" <radhey.shyam.pandey@....com>
To: Junzhong Pan <panjunzhong@...look.com>, "piyush.mehta@....com"
<piyush.mehta@....com>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "Simek, Michal"
<michal.simek@....com>, "peter.chen@...nel.org" <peter.chen@...nel.org>,
"Paladugu, Siva Durga Prasad" <siva.durga.prasad.paladugu@....com>
Subject: RE: [PATCH V2] usb: chipidea: udc: Add revision check of
2.20[CI_REVISION_22]
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Junzhong Pan <panjunzhong@...look.com>
> Sent: Thursday, March 6, 2025 7:43 PM
> To: piyush.mehta@....com
> Cc: gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org; linux-
> usb@...r.kernel.org; Simek, Michal <michal.simek@....com>;
> peter.chen@...nel.org; Pandey, Radhey Shyam
> <radhey.shyam.pandey@....com>; Paladugu, Siva Durga Prasad
> <siva.durga.prasad.paladugu@....com>
> Subject: Re: [PATCH V2] usb: chipidea: udc: Add revision check of
> 2.20[CI_REVISION_22]
>
> Hi Piyush,
>
> > Issue: Adding a dTD to a Primed Endpoint May Not Get Recognized with
> > revision 2.20a.
> >
> > There is an issue with the add dTD tripwire semaphore (ATDTW bit in
> > USBCMD register) that can cause the controller to ignore a dTD that is
> > added to a primed endpoint. When this happens, the software can read
> > the tripwire bit and the status bit at '1' even though the endpoint is
> > unprimed.
> > This issue observed with the Windows host machine.
>
> Sorry to dig through this old patch email.
>
> May I ask what does **the scene look like (bus condition/dtd status)** when this
> issue observed with the Windows host machine occurs?
>
> I want to know if it's relevant to an issue I encountered recently.
>
> I met this a tricky issue with an soc have a marvel udc (driven by mv_udc_core.c, it's
> a same chipidea IP accordingly) when running rndis gadget with the Windows host
> machine.
What is IP version ? If not 2.20, can you try with extending current check?
>
> When the rndis gadget running for a long time (randomly), the udc would suddenly
> stopped and no longger response to IN token sent from the host.
>
> The bus trace looks like this:
>
> BULK IN:
> IN
> DATA0 120 Bytes
> ACK
> BULK OUT:
> OUT
> DATA1 98 Bytes
> NYET
> BULK IN ??
> IN NAK
> IN NAK
> IN NAK
> .....
> IN !!Propagated Error!!(Turnaround/Timeout Error)
>
>
>
> The driver doesn't receive any further interrupts when it stopped, though the IN 102
> Bytes transaction is finished on the bus, but the TD_TOTAL_BYTES of that dTd is
> never updated.
>
> ep num: 1 dir: 1(in)
> qh of current ep: 1 dir: 1(in)
> qh maxpacklen: 0x22000000, token: 0x668080
> qh td_dma curr_dtd_ptr: 0x658403c0, next_dtd_ptr: 0x1
> qh buf p0: 0x672dcde, p1: 0x672e378, p2: 0x672f000, p3: 0x6730000, p4:
> 0x6731000
> req 0xd81e245540 len: **102**, first_dtd: 0x658403c0, last_dtd: 0x658403c0,
> dtd_count: 1, actual: 102
> [qh->curr_dtd_ptr]dtd dma 0x658403c0, token: 0x668080, err: 0x0, dtd_nxt:
> 0x65840540
> buf p0:0x672dcde p1:0x672e000 p2:0x672f000 p3:0x6730000 p4:0x6731000
> scr: 0x0
> req 0xd81e245b40 len: 1558, first_dtd: 0x65840540, last_dtd: 0x65840540,
> dtd_count: 1, actual: 1558
> [---]dtd dma 0x65840540, token: 0x6168080, err: 0x0, dtd_nxt: 0x65840080
> buf p0:0x20ce50de p1:0x20ce6000 p2:0x20ce7000 p3:0x20ce8000
> p4:0x20ce9000 scr: 0x0 ......
>
> epnak: 0x00070003
> epsetupstat: 0x00000000
> epprime: 0x00000000
> epflush: 0x00000000
> epstatus: 0x00020002
>
>
> Thanks!
Powered by blists - more mailing lists