[AMD Official Use Only - AMD Internal Distribution Only] > -----Original Message----- > From: Junzhong Pan <panjunzhong@xxxxxxxxxxx> > Sent: Thursday, March 6, 2025 7:43 PM > To: piyush.mehta@xxxxxxx > Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- > usb@xxxxxxxxxxxxxxx; Simek, Michal <michal.simek@xxxxxxx>; > peter.chen@xxxxxxxxxx; Pandey, Radhey Shyam > <radhey.shyam.pandey@xxxxxxx>; Paladugu, Siva Durga Prasad > <siva.durga.prasad.paladugu@xxxxxxx> > 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!
