public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@amd.com>
To: Junzhong Pan <panjunzhong@outlook.com>,
	Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, peter.chen@kernel.org,
	radhey.shyam.pandey@amd.com, siva.durga.prasad.paladugu@amd.com
Subject: Re: [PATCH V2] usb: chipidea: udc: Add revision check of 2.20[CI_REVISION_22]
Date: Thu, 6 Mar 2025 15:22:16 +0100	[thread overview]
Message-ID: <274e6669-adf1-4bb3-9237-2313b0d7fe09@amd.com> (raw)
In-Reply-To: <ME0P300MB05533B11B123B7C9188B699EA6CA2@ME0P300MB0553.AUSP300.PROD.OUTLOOK.COM>

+ Radhey.

On 3/6/25 15:12, Junzhong Pan wrote:
> 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.
> 
> 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
> 

Piyush is no longer with us but Radhey will take care about this.

Thanks,
Michal


  parent reply	other threads:[~2025-03-06 14:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02  7:06 [PATCH V2] usb: chipidea: udc: Add revision check of 2.20[CI_REVISION_22] Piyush Mehta
2025-03-06 14:12 ` Junzhong Pan
2025-03-06 14:17   ` Junzhong Pan
2025-03-06 14:22   ` Michal Simek [this message]
2025-03-09 14:55   ` Pandey, Radhey Shyam

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=274e6669-adf1-4bb3-9237-2313b0d7fe09@amd.com \
    --to=michal.simek@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=panjunzhong@outlook.com \
    --cc=peter.chen@kernel.org \
    --cc=radhey.shyam.pandey@amd.com \
    --cc=siva.durga.prasad.paladugu@amd.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