Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759129AbbKSTVJ (ORCPT ); Thu, 19 Nov 2015 14:21:09 -0500 Received: from devils.ext.ti.com ([198.47.26.153]:60605 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751465AbbKSTVH (ORCPT ); Thu, 19 Nov 2015 14:21:07 -0500 From: Felipe Balbi To: Doug Anderson CC: John Youn , Yunzhi Li , Heiko =?utf-8?Q?St=C3=BCbner?= , "open list:ARM/Rockchip SoC..." , Julius Werner , "Herrero, Gregory" , "Kaukab, Yousaf" , Dinh Nguyen , Alan Stern , Ming Lei , John Youn , "Greg Kroah-Hartman" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 6/8] usb: dwc2: host: Assume all devices are on one single_tt hub In-Reply-To: References: <1447721484-22548-1-git-send-email-dianders@chromium.org> <1447721484-22548-7-git-send-email-dianders@chromium.org> <87lh9uf1fw.fsf@saruman.tx.rr.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 19 Nov 2015 13:20:23 -0600 Message-ID: <87twoheqyw.fsf@saruman.tx.rr.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5144 Lines: 131 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Doug Anderson writes: >> Douglas Anderson writes: >>> Until we have logic to determine which devices share the same TT let's >>> add logic to assume that all devices on a given dwc2 controller are on >>> one single_tt hub. This is better than the previous code that assumed >>> that all devices were on one multi_tt hub, since single_tt hubs >>> appear (in my experience) to be much more common and any schedule that >>> would work on a single_tt hub will also work on a multi_tt hub. This >>> will prevent more than 8 total low/full speed devices to be on the bus >>> at one time, but that's a reasonable restriction until we've made things >>> smarter. >>> >>> Signed-off-by: Douglas Anderson >>> --- >>> Changes in v3: >>> - Assuming single_tt is new for v3; not terribly well tested (yet). >>> >>> Changes in v2: None >>> >>> drivers/usb/dwc2/core.h | 1 + >>> drivers/usb/dwc2/hcd_queue.c | 40 ++++++++++++++++++++++++++++++++++++= +++- >>> 2 files changed, 40 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h >>> index 567ee2c9e69f..09aa2b5ae29e 100644 >>> --- a/drivers/usb/dwc2/core.h >>> +++ b/drivers/usb/dwc2/core.h >>> @@ -782,6 +782,7 @@ struct dwc2_hsotg { >>> u16 periodic_usecs; >>> unsigned long periodic_bitmap[DIV_ROUND_UP(TOTAL_PERIODIC_USEC, >>> BITS_PER_LONG)]; >>> + bool has_split[8]; >> >> why don't you use a u8 instead then just set each bit for each >> "has_split" you need to take care of. This array is kinda ugly. > > Let's actually drop this patch completely. Julius and I sat down and > he talked me through things, and with my current understanding the > current microframe scheduler in dwc2 is broken enough that small > little band-aids like this will do little more than just push the > problems around. > > I'm a good portion of the way through a better microframe scheduler. > I have no doubt that it won't be perfect, but hopefully it will at > least be based in reality... > > My latest thinking on the patches in this series: > > 1. usb: dwc2: rockchip: Make the max_transfer_size automatic > > I'll probably separate this out into its own patch so I can stop > sending it as part of this series. ...or if someone wanted to land it > then I won't bother. > > > 2. usb: dwc2: host: Get aligned DMA in a more supported way > > Still can land any time and has good benefits. I believe that I can't > separate this because it will cause conflicts with scheduler patches. > > > 3. usb: dwc2: host: Add scheduler tracing > > Would be nice to land. > > > 4. usb: dwc2: host: Rewrite the microframe scheduler > 5. usb: dwc2: host: Keep track of and use our scheduled microframe > 6. usb: dwc2: host: Assume all devices are on one single_tt hub > > Please drop patches 4-6 right now. > > > 7. usb: dwc2: host: Add a delay before releasing periodic bandwidth > 8. usb: dwc2: host: Giveback URB in tasklet context if you can, it's best to send a new series with the changes. This makes mine and John's life a lot easier :-) > I'll probably move these back up in the series (like in v2) and put > microframe rewrite atop them. With my current understanding the > scheduling is so broken today that the concerns Alan brought up can > wait until we have a proper scheduler to be addressed. In the > meantime getting the huge boost in interrupt speed will help with > dwc2's correctness (and performance) because it means we're much less > likely to miss SOF interrupts. > > If anyone has any review time, giving a review to v2 of these patches > would be helpful. Otherwise I'll double check that v2 still looks > good with my current understanding and eventually post them again. That would have to be someone experienced with that IP. I don't even have docs :-) =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWTiD4AAoJEIaOsuA1yqREPA8P/0Dy8aBTIdhTaRu0APXOHqL8 U8qvj5kKyFwNpv4axZhGiKjioW/zjAD/2kE7PgPOfcDd7H22f/XlUtutuSZKizrJ NZ5p2Ca/nC0QuY4bvojEuRi4YLNp1o41f/sfejAUgAA6mtLvoHZsYZq3QuVi/1zR N8N3d87QHkbkeXXbR6/Qc194VVd7eG2a12+ORRcH6lVzwTCWdi2ecMI8Fx3cjkM9 1R8Lcy4NXfSUGuWcRJP/R831xjkcjKmByQkTUoghIH4d5QpOgMV2McdzhiSeLHFe SfObwXmanIM3M1czaJIt7629ngLmYh86H62Jk2YCEHl6vn4LrzZCfuGd6KYcb7Gi EOSd9ur2q3SrXiXIhwa9pn+VHbLycyqrufrP7lrpdPB3diranUozOeTCi8rCqZGG a7fNBU8tQ2cAmCpxN/iibU2xusGFr18Sb/URR4OkkWdJwfwGDowsqbWm1iISG8VY ai9lHsW3BTpIsAWDRHUcUUsBDNkXssZs4tXtjFlso7C30ohARoQqJxIEauwVJxa9 MFRzesBnrSHOsYIZ5XfPZ22EFF09KZHrWoOScAYMuM3Nct65EgzkjM5anQY6iGJw k7gXt9DYkWlgViGsp6C9Z1Zc07XOM/dySUQcvpCRKynk2tsFTZTH9BrqmJkbiHnt HQxTX1cVp0FrNQIjVHht =tN3s -----END PGP SIGNATURE----- --=-=-=-- -- 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/