Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752285AbbKPUqh (ORCPT ); Mon, 16 Nov 2015 15:46:37 -0500 Received: from mail-yk0-f179.google.com ([209.85.160.179]:35964 "EHLO mail-yk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751251AbbKPUqe (ORCPT ); Mon, 16 Nov 2015 15:46:34 -0500 MIME-Version: 1.0 In-Reply-To: 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: Mon, 16 Nov 2015 12:46:32 -0800 Message-ID: Subject: Re: [RFC] usb: dwc2: hcd: fix split schedule issue From: Julius Werner To: Doug Anderson Cc: John Youn , Yunzhi Li , 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: 1571 Lines: 41 > 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 Keep in mind that there's always at most one (active) TT between host and device. The TT is the point where high-speed traffic is translated to low-/full-speed traffic, so after that you cannot translate again. With multiple hubs you either have -> high-speed 2.0 hub (TT inactive / irrelevant for this path) -> multi or single TT 2.0 hub -> device or -> multi or single TT 2.0 hub -> full-speed 1.1 hub -> device All the information you need should already be in struct usb_device. If udev->tt->multi == 0, then it must be scheduled in the same group as all other devices it shares udev->tt (the same pointer address) with. If udev->tt->multi == 1, then it belongs in the same group as all that have the same udev->tt and the same udev->ttport. There's even a udev->tt->hcpriv where you could link a data structure (array) in to keep track of these matching devices. I agree that this is a nice-to-have optimization, though... it's more important to get the thing stable, and I think it's fine to assume that all low-/full-speed transfers go on the same bus for the first iteration. -- 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/