linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Felipe Balbi <balbi@ti.com>
Cc: "John Youn" <John.Youn@synopsys.com>,
	"Yunzhi Li" <lyz@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Julius Werner" <jwerner@chromium.org>,
	"Herrero, Gregory" <gregory.herrero@intel.com>,
	"Kaukab, Yousaf" <yousaf.kaukab@intel.com>,
	"Dinh Nguyen" <dinguyen@opensource.altera.com>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"Ming Lei" <ming.lei@canonical.com>,
	"John Youn" <johnyoun@synopsys.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@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
Date: Thu, 19 Nov 2015 08:27:03 -0800	[thread overview]
Message-ID: <CAD=FV=UW-AbY9GnYOS_2V=dZTkL6NiZsO4urpf==qjcRDaEMDA@mail.gmail.com> (raw)
In-Reply-To: <87lh9uf1fw.fsf@saruman.tx.rr.com>

Felipe,

On Thu, Nov 19, 2015 at 7:34 AM, Felipe Balbi <balbi@ti.com> wrote:
>
> Hi,
>
> Douglas Anderson <dianders@chromium.org> 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 <dianders@chromium.org>
>> ---
>> 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

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.

-Doug

  reply	other threads:[~2015-11-19 16:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17  0:51 [PATCH v3 0/8] dwc2: Fix uframe scheduler + speed up the interrupt handler quite a bit Douglas Anderson
2015-11-17  0:51 ` [PATCH v3 1/8] usb: dwc2: rockchip: Make the max_transfer_size automatic Douglas Anderson
2015-11-17  0:51 ` [PATCH v3 2/8] usb: dwc2: host: Get aligned DMA in a more supported way Douglas Anderson
2015-11-17  0:51 ` [PATCH v3 3/8] usb: dwc2: host: Add scheduler tracing Douglas Anderson
2015-11-17  0:51 ` [PATCH v3 4/8] usb: dwc2: host: Rewrite the microframe scheduler Douglas Anderson
2015-11-17  0:51 ` [PATCH v3 5/8] usb: dwc2: host: Keep track of and use our scheduled microframe Douglas Anderson
2015-11-17  0:51 ` [PATCH v3 6/8] usb: dwc2: host: Assume all devices are on one single_tt hub Douglas Anderson
2015-11-17 21:22   ` Doug Anderson
2015-11-19 15:34   ` Felipe Balbi
2015-11-19 16:27     ` Doug Anderson [this message]
2015-11-19 19:20       ` Felipe Balbi
2015-11-20  4:33       ` John Youn
2015-11-24  0:28         ` Doug Anderson
2015-11-26  0:44           ` Doug Anderson
2015-11-17  0:51 ` [PATCH v3 7/8] usb: dwc2: host: Add a delay before releasing periodic bandwidth Douglas Anderson
2015-11-17  0:51 ` [PATCH v3 8/8] usb: dwc2: host: Giveback URB in tasklet context Douglas Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD=FV=UW-AbY9GnYOS_2V=dZTkL6NiZsO4urpf==qjcRDaEMDA@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=John.Youn@synopsys.com \
    --cc=balbi@ti.com \
    --cc=dinguyen@opensource.altera.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.herrero@intel.com \
    --cc=heiko@sntech.de \
    --cc=johnyoun@synopsys.com \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lyz@rock-chips.com \
    --cc=ming.lei@canonical.com \
    --cc=stern@rowland.harvard.edu \
    --cc=yousaf.kaukab@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).