Received-SPF: pass (google.com: domain of linux-kernel+bounces-155293-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Tue, 23 Apr 2024 15:37:52 +0200
From: Michael Grzeschik <mgr@pengutronix.de>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: gadget: check drained isoc ep
Message-ID: <Zie5sN473m2rgNTK@pengutronix.de>
References: <20240307-dwc3-gadget-complete-irq-v2-1-8c5e9b35f7b9@pengutronix.de>
 <20240402230555.xgt5uilc42diyr4m@synopsys.com>
 <20240402231848.4hzzrxegjrcmdab2@synopsys.com>
 <20240404002906.wk6xbz2wp2tf2xwn@synopsys.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="M6Szu+DUfPV4wPeQ"
Content-Disposition: inline
In-Reply-To: <20240404002906.wk6xbz2wp2tf2xwn@synopsys.com>


--M6Szu+DUfPV4wPeQ
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Thinh,

On Thu, Apr 04, 2024 at 12:29:14AM +0000, Thinh Nguyen wrote:
>On Tue, Apr 02, 2024, Thinh Nguyen wrote:
>> On Tue, Apr 02, 2024, Thinh Nguyen wrote:
>> > My concern here is for the case where transfer_in_flight =3D=3D true a=
nd
>>
>> I mean transfer_in_flight =3D=3D false
>>
>> > list_empty(started_list) =3D=3D false. That means that the requests in=
 the
>> > started_list are completed but are not given back to the gadget driver.
>> >
>> > Since they remained in the started_list, they will be resubmitted again
>> > on the next usb_ep_queue. We may send duplicate transfers right?
>
>Actually, since the requests are completed, the HWO bits are cleared,
>nothing is submitted and no duplicate. But since the requests are not
>given back yet from the started_list, then the next Start_Transfer
>command will begin with the TRB address of the completed request
>(HWO=3D0), the controller may not process the next TRBs. Have you tested
>this scenario?
>
>> >
>> > You can try to cleanup requests in the started_list, but you need to be
>> > careful to make sure you're not out of sync with the transfer completi=
on
>> > events and new requests from gadget driver.
>> >
>
>Was the problem you encounter due to no_interrupt settings where the
>it was set to the last request of the uvc data pump?
>
>if that's the case, can UVC function driver make sure to not set
>no_interrupt to the last request of the data pump from the UVC?

Actually no. What I want to do is to ensure that the dwc3 stream
is stopped when the hardware was drained. Which is a valid point
in my case. Since we are actually potentially enqueueing new request
in the complete handler, be it zero length or real transfers.

Calling kick_transfer on an drained hw will absolutely run into
missed isocs if the irq thread was called late. We saw this on real hardwar=
e,
where another irq_thread was scheduled with the same priority as the
dwc3 irq_thread but was running so long that the HW was running dry in
between the hw irq and the actual dwc3_irq_thread run.

Michael

--=20
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

--M6Szu+DUfPV4wPeQ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElXvEUs6VPX6mDPT8C+njFXoeLGQFAmYnuawACgkQC+njFXoe
LGT/DxAAwz6KulNc5KIUpueaEMu7WCq3l/4Bf+MoO37W9b1F8VVNE2jwZaLn/8iO
rYUEIyJ6yqeiB4PrT3oBUwmqXQ39xMzzPqeFYwNA9WOa9e2vBVNE9ZesNpZVra/Q
uNEoMVN56nWz2kIRLhl5egV5t96GGQMI4zi6UQx8OHXK6zKbhJcNh5zrDZT6gbRi
X2MDOKF2TS9jrJK8TyU+gtbyjPdcrgmKfhv/XYmk3KaMBnVMx9EFoevQ+n2Vl6Nn
51qkbjEooQ4uma+IitEI6tLjaytCOq57JPkMOUqArzXyhDyAhzmo8Lj0RDAhfFus
TFk1TP6ee30tT4+Wvn6x8zD4FdOwqhYhaDfqRhmwdTGuAZ4bjGbsYhn/IT3PSNGF
VyA1XiBqd+aqqBoxqTqMUChZ/uXjxqnJSjryCdwkNjHbxxkjoA9WWPE3QyBZXewn
oEKaNC7G34SiyqubGuLinDBD9Q6gbtNSxCSxCdAEOWKUfI6NVjwr9Dve7dhpTlAu
EqfJJu+Ittz3kB5qddDV43OVc7tpv2Tl6t04gyIuiNyoWxY0InHVJUhYW8hXFle7
EaRn10m7ApNsKmF3Xmixw1uO6qp/Op4F2lvFIgNgkOowrm+zLWUULeR8RFx/HvWR
b5cfRa47S0aUYmloKE93BoH7hN5S/JQ8fNzT+C3ljMr/eL3cEt0=
=kvaR
-----END PGP SIGNATURE-----

--M6Szu+DUfPV4wPeQ--