[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2B3535C5ECE8B5419E3ECBE30077290901DC3CBCA4@US01WEMBX2.internal.synopsys.com>
Date: Fri, 13 Nov 2015 05:05:12 +0000
From: John Youn <John.Youn@...opsys.com>
To: Doug Anderson <dianders@...omium.org>,
John Youn <John.Youn@...opsys.com>
CC: Yunzhi Li <lyz@...k-chips.com>, Julius Werner <jwerner@...gle.com>,
"Dinh Nguyen" <dinguyen@...nsource.altera.com>,
"Kaukab, Yousaf" <yousaf.kaukab@...el.com>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
wulf <wulf@...k-chips.com>,
Kever Yang <kever.yang@...k-chips.com>,
caesar <caesar.wang@...k-chips.com>,
Tao Huang <huangtao@...k-chips.com>,
rockchip-discuss <rockchip-discuss@...omium.org>
Subject: Re: [RFC] usb: dwc2: hcd: fix split schedule issue
On 11/11/2015 8:46 PM, Doug Anderson wrote:
> John,
>
> On Wed, Nov 11, 2015 at 8:29 PM, John Youn <John.Youn@...opsys.com> 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
> <https://chromium-review.googlesource.com/#/c/312160/>.
>
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists