From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 10 Apr 2020 08:40:07 -0400 Subject: [PATCH] usb: Keep async schedule running only across mass storage xfers In-Reply-To: <20200410082120.7b79955a@jawa> References: <20200406122944.105432-1-marek.vasut+renesas@gmail.com> <20200409232326.GJ8031@bill-the-cat> <20200410082120.7b79955a@jawa> Message-ID: <20200410124007.GK8031@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Apr 10, 2020 at 08:21:20AM +0200, Lukasz Majewski wrote: > On Thu, 9 Apr 2020 19:23:26 -0400 > Tom Rini wrote: > > > On Mon, Apr 06, 2020 at 02:29:44PM +0200, Marek Vasut wrote: > > > > > Rather than keeping the asynchronous schedule running always, keep > > > it running only across USB mass storage transfers for now, as it > > > seems that keeping it running all the time interferes with certain > > > control transfers during device enumeration. > > > > > > Note that running the async schedule all the time should not be an > > > issue, especially on EHCI HCD, as that one implements most of the > > > transfers using async schedule. > > > > > > Note that we have usb_disable_asynch(), which however is utterly > > > broken. The usb_disable_asynch() blocks the USB core from doing > > > async transfers by setting a global flag. The async schedule should > > > however be disabled per USB controller. Moreover, setting a global > > > flag does not prevent the controller from using the async schedule, > > > which e.g. the EHCI HCD does. > > > > > > This patch implements additional callback to the controller, which > > > permits it to lock the async schedule and keep it running across > > > multiple transfers. Once the schedule is unlocked, it must also be > > > disabled. This thus prevents the async schedule from running outside > > > of the USB mass storage transfers. > > > > > > Signed-off-by: Marek Vasut > > > Cc: Lukasz Majewski > > > Cc: Tom Rini > > > Tested-by: Tom Rini [omap3_beagle, previously > > > failing] > > > > Applied to u-boot/master, thanks! > > > > It is a really short time between posting the patch (Monday) and being > applied (midnight on Friday). > > It is the Pre-Easter period with some other world-wide issues... and not > all of us have enough time now to review and test patches. So, I took this patch at this point in the cycle as it fixes a regression that we've had reported for a while and because the custodian asked me to grab it directly. All things considered, it is unlikely to make the situation worse and may fix some of the other regressions we've had in the area. Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: