Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754702AbbKMFFS (ORCPT ); Fri, 13 Nov 2015 00:05:18 -0500 Received: from us01smtprelay-2.synopsys.com ([198.182.47.9]:44969 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751404AbbKMFFO convert rfc822-to-8bit (ORCPT ); Fri, 13 Nov 2015 00:05:14 -0500 From: John Youn To: Doug Anderson , John Youn CC: Yunzhi Li , Julius Werner , "Dinh Nguyen" , "Kaukab, Yousaf" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , wulf , Kever Yang , caesar , Tao Huang , rockchip-discuss Subject: Re: [RFC] usb: dwc2: hcd: fix split schedule issue Thread-Topic: [RFC] usb: dwc2: hcd: fix split schedule issue Thread-Index: AQHRGHbnZi8mHX/q8ECLIM60EIOt9w== Date: Fri, 13 Nov 2015 05:05:12 +0000 Message-ID: <2B3535C5ECE8B5419E3ECBE30077290901DC3CBCA4@US01WEMBX2.internal.synopsys.com> References: <1446802612-5828-1-git-send-email-lyz@rock-chips.com> <563C7B48.2020308@rock-chips.com> <2B3535C5ECE8B5419E3ECBE30077290901DC3C8CA4@US01WEMBX2.internal.synopsys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.140.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3044 Lines: 76 On 11/11/2015 8:46 PM, Doug Anderson wrote: > John, > > On Wed, Nov 11, 2015 at 8:29 PM, John Youn wrote: >> I also feel it is not quite right as the SSPLIT should be able to >> happen during the SSPLIT of another device. I tried to reproduce >> and see the same scheduling but don't see any hang due to it. >> >> Yunzhi, any details on what kind of hub and keyboard you are >> using? I have the same Jabra 410 speaker. > > I saw it with a standard Logitech mouse. It wasn't a hang, but the > mouse effectively became non-functional (behaved like it hung) when > you started playing audio. Once the audio stream stopped, the mouse > would work again. I was using the same Jabra 410 as well. > > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M > |__ Port 2: Dev 6, If 0, Class=Human Interface Device, > Driver=usbhid, 1.5M > |__ Port 3: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 3: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 3: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 12M > |__ Port 3: Dev 5, If 3, Class=Human Interface Device, Driver=, 12M > > Bus 002 Device 005: ID 0b0e:0412 GN Netcom > Bus 002 Device 006: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse > Bus 002 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > We've also had some discussion of this patch in our bug tracker at > . > > I'll keep digging tomorrow, too. > > -Doug > It seems to be an issue with single TT hubs. I've tried several multi-TT hubs with no issues. With a single TT hub I do see a problem though not the exact one described. I see corrupted and dropped packets on the FS side of the hub. In a microframe with SSPLIT.begin, taking up the max bandwidth for the microframe, when another SSPLIT for a different device is issued, the data gets corrupted on the other side of the TT. Probably due to exceeding the bandwidth in the microframe since a single TT hub's ports all share the bandwidth. With this fix, the next SSPLIT goes out in the same microframe as the SSPLIT.end and the data goes through fine. However I don't think this will work as a general fix. Since it is just skipping things without rescheduling. For example SSPLIT now happens a microframe later but the CSPLIT is not adjusted so it comes a microframe too early. I think the correct fix is to create a proper schedule based on all the active endpoints to make sure we don't go over the bandwidth for a single TT hub. Or to make the adjustments earlier like in dwc2_sched_periodic_split(). Regards, John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/