Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752660AbbKNAdx (ORCPT ); Fri, 13 Nov 2015 19:33:53 -0500 Received: from mail-yk0-f176.google.com ([209.85.160.176]:36359 "EHLO mail-yk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752519AbbKNAdv (ORCPT ); Fri, 13 Nov 2015 19:33:51 -0500 MIME-Version: 1.0 In-Reply-To: <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> <2B3535C5ECE8B5419E3ECBE30077290901DC3CBCA4@US01WEMBX2.internal.synopsys.com> Date: Fri, 13 Nov 2015 16:33:50 -0800 X-Google-Sender-Auth: EMwjBol0yNw_p6QZbFR-ctb5ZWk Message-ID: Subject: Re: [RFC] usb: dwc2: hcd: fix split schedule issue From: Doug Anderson To: 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2631 Lines: 73 John, On Thu, Nov 12, 2015 at 9:05 PM, John Youn wrote: > It seems to be an issue with single TT hubs. I've tried several > multi-TT hubs with no issues. Agreed. > 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. Seems like different single TT hubs react differently. I got one where the mouse kept working but the audio was just static... > 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(). I've started working on this and just before I needed to leave my desk I got something that seemed to work. I'll keep at it on Monday. At the moment I'm making the assumption that we never got a multi_tt hub attached to us. My code will always just schedule one split per microframe. Would that be OK for now until we make the scheduler better? To handle things smarter, I think I need to research how to deal with hubs attached to hubs attached to hubs. For instance: dwc2 -> multi_tt hub -> single_tt hub -> device 1 -> device 2 -> single_tt hub -> device 3 -> device 4 vs. dwc2 -> single_tt hub -> multi_tt hub -> device 1 -> device 2 -> multi_tt hub -> device 3 -> device 4 In the first case I presume I could schedule device 1 and device 3 at the same time, but not device 2 and device 4. In the 2nd case I presume I could schedule all 4 devices independently. ...but I haven't dug through the spec to confirm that, yet. -- 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/