Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Wed, Jan 27, 2016 at 2:03 PM, Alan Stern  wrote:
> On Wed, 27 Jan 2016, Doug Anderson wrote:
>
>> Alan,
>>
>> On Wed, Jan 27, 2016 at 1:34 PM, Alan Stern  
>> wrote:
>> > On Wed, 27 Jan 2016, Doug Anderson wrote:
>> >
>> >> This patch should fix ya.
>> >>
>> >> FIXUP: FROMLIST: usb: dwc2: host: Manage frame nums better in scheduler
>> >> https://chromium-review.googlesource.com/324185
>> >
>> > Hmmm.  That fixed the problem of the polls occuring too frequently, but
>> > now I see again intervals that are larger than 256 ms.  In the most
>> > recent test there are two intervals of 512 ms and one of 2048 ms.
>>
>> OK, good to know.  Ugh.  I'll have to see if I can reproduce that.  If
>> I had to guess, though, I'd say that you're probably running into high
>> interrupt latency problems.
>
> Quite possibly.  Would that delay the transfers by a full period or
> only by one frame?

Yeah, that's the part that doesn't make sense.  I would not have
expected it to be a multiple.  If we missed something then we should
have picked something sooner to reschedule.  Even if the frame we
picked to reschedule wasn't ideal you still should have seen it on the
bus.

In other words, I'd expect lots of 256 ms with the occasional 257,
258, 259.  I wouldn't expect 512.

Presumably the 512 means that there was an error somewhere and the
packet was dropped.  I'm actually tracking down a weird full speed hub
bug right now and it's possible that it's a more serious / general
problem.

It's also possible that we're somehow overflowing a FIFO or a queue.
I've seen some overflow errors pop by while debugging recently, and
those shouldn't happen unless calculations are off somewhere.


>>  Those problems would be worse on the
>> Raspberry Pi than on my system due to the significantly slower
>> processor.
>>
>> Can you confirm that these problems also were introduced by my series?
>>  AKA: you never saw > 256 ms polls before my series and now you see
>> them?
>
> No, these problems were also present in the kernel without your
> patches.

Whew!  Still good to root cause, but also nice to know that I didn't
introduce this one.  ;)  Of course, had I introduced it it would
probably be easier to fix...


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Tue, 26 Jan 2016, Doug Anderson wrote:

> > This probably indicates that the list of patches was incomplete (i.e.,
> > some other patches were applied before these).  Also, the patches
> > aren't listed in order of the patchwork IDs -- which order is correct?
> 
> The order like 01, 02, 03, etc is correct.  Patchwork numbers things
> in a random order (depending on the vagaries of SMTP and which one
> arrives to their server first).
> 
> Ah, I had tried linux/master recently, but that has a patch that's not in 
> v4.4:
> 
> fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
> 
> 
> I'd bet that you don't have descriptor DMA turned on anyway, so the
> descriptor DMA patches won't really matter (they'll just be noops).
> ...but you could pick all the patches up to that one to avoid
> conflicts.
> 
> fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
> 762d3a1a9cd7 usb: dwc2: host: process all completed urbs
> 3f808bdae75e usb: dwc2: host: always increment available host channel
> during release
> c17b337c1ea4 usb: dwc2: host: program descriptor for next frame
> b9392d9920fd usb: dwc2: host: add function to compare frame index
> 2b046bc5aaef usb: dwc2: host: spinlock release channel
> 26a19ea69906 usb: dwc2: host: fix use of qtd after free in desc dma mode
> c503b3815385 usb: dwc2: host: rework isochronous halt path
> dde4c1bf5df0 usb: dwc2: host: set active bit in isochronous descriptors
> 3ac38d260fa5 usb: dwc2: host: ensure filling of isoc desc is correctly done

In the end I just used the contents of the dwc2 directory from Linus's 
current tree -- I don't think it has changed since 4.5-rc1.  Your 
patches applied on top of that with no issues.

They seem to work.  Is there anything in particular you would like me 
to test?

One problem I noticed: The controller does hub status polling to an
external high-speed hub much too frequently.  The interrupt endpoint's
bInterval value is 12, meaning the polling interval should be 256 ms.  
But when data was available, the polls were issued every 2 microframes
instead of every 2048.

Could the driver be rescheduling the interrupt endpoint every time an
URB completes and a new one is submitted?  That's what it looks like.  
This might be related to the giving-URBs-back-in-a-tasklet change.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Alan,

On Wed, Jan 27, 2016 at 11:03 AM, Alan Stern  wrote:
> On Tue, 26 Jan 2016, Doug Anderson wrote:
>
>> > This probably indicates that the list of patches was incomplete (i.e.,
>> > some other patches were applied before these).  Also, the patches
>> > aren't listed in order of the patchwork IDs -- which order is correct?
>>
>> The order like 01, 02, 03, etc is correct.  Patchwork numbers things
>> in a random order (depending on the vagaries of SMTP and which one
>> arrives to their server first).
>>
>> Ah, I had tried linux/master recently, but that has a patch that's not in 
>> v4.4:
>>
>> fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
>>
>>
>> I'd bet that you don't have descriptor DMA turned on anyway, so the
>> descriptor DMA patches won't really matter (they'll just be noops).
>> ...but you could pick all the patches up to that one to avoid
>> conflicts.
>>
>> fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
>> 762d3a1a9cd7 usb: dwc2: host: process all completed urbs
>> 3f808bdae75e usb: dwc2: host: always increment available host channel
>> during release
>> c17b337c1ea4 usb: dwc2: host: program descriptor for next frame
>> b9392d9920fd usb: dwc2: host: add function to compare frame index
>> 2b046bc5aaef usb: dwc2: host: spinlock release channel
>> 26a19ea69906 usb: dwc2: host: fix use of qtd after free in desc dma mode
>> c503b3815385 usb: dwc2: host: rework isochronous halt path
>> dde4c1bf5df0 usb: dwc2: host: set active bit in isochronous descriptors
>> 3ac38d260fa5 usb: dwc2: host: ensure filling of isoc desc is correctly done
>
> In the end I just used the contents of the dwc2 directory from Linus's
> current tree -- I don't think it has changed since 4.5-rc1.  Your
> patches applied on top of that with no issues.
>
> They seem to work.  Is there anything in particular you would like me
> to test?

I was sorta wondering if it fixed the original problem you were
seeing?  Unless I missed it it sounded like it was still broken on ToT
and I was wondering if my series happened to help in any way...

Other than that the series mostly improves compatibility with splits,
especially when many periodic devices are plugged in (like a Full
Speed USB audio device plugged in at the same time as several
keyboards).


> One problem I noticed: The controller does hub status polling to an
> external high-speed hub much too frequently.  The interrupt endpoint's
> bInterval value is 12, meaning the polling interval should be 256 ms.
> But when data was available, the polls were issued every 2 microframes
> instead of every 2048.
>
> Could the driver be rescheduling the interrupt endpoint every time an
> URB completes and a new one is submitted?  That's what it looks like.
> This might be related to the giving-URBs-back-in-a-tasklet change.

Hrm.  That started with this series?  OK, I'll take a look and see if
it can reproduce.

Oh, wait, I think I know what this is.  This is probably ("usb: dwc2:
host: Manage frame nums better in scheduler").  I'd bet that if you go
before that change then the behavior will be the way it was.

In said patch you can see that dwc2_schedule_periodic() will now
always pick a new first frame.  As I understand it that will happen if
there was ever a short period of time when we weren't scheduled and I
was worried about the next slice being in the past.  It wouldn't hurt
to change the test to only pick a new first frame if the existing
first frame is in the past.  That would probably fix your problem.

Question: is the behavior you're seeing illegal / undesirable?  It
only happens when there's data available, right?  My current
(rewritten) reservation algorithm in dwc2 is pretty crude  From a high
speed device perspective it reserves a timeslot for the EP in every
microframe even if the EP has a long interval.  It won't typically
schedule the EP more often than every "interval" microframes, but the
reservation is there.  That means we can't support quite as many
devices at the same time, but it has the advantage that if we screw up
(like if we miss an SOF) we know we can actually try to make up for it
quickly and we won't collide with anyone else.  The whole thing also
simplifies the scheduler.  In your particular case, we used our
existing reservation to schedule the device a little sooner than
requested.


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Wed, Jan 27, 2016 at 12:59 PM, Alan Stern  wrote:
> On Wed, 27 Jan 2016, Doug Anderson wrote:
>
>> > In the end I just used the contents of the dwc2 directory from Linus's
>> > current tree -- I don't think it has changed since 4.5-rc1.  Your
>> > patches applied on top of that with no issues.
>> >
>> > They seem to work.  Is there anything in particular you would like me
>> > to test?
>>
>> I was sorta wondering if it fixed the original problem you were
>> seeing?  Unless I missed it it sounded like it was still broken on ToT
>> and I was wondering if my series happened to help in any way...
>
> They did not fix the original problem.  I still have no idea what could
> be causing the device's selective behavior.  If you want, I can send
> you the .tdc analyzer files for kernels with and without your patch
> series.  Maybe you'll see something I missed.

Argh.  Sure, go ahead and send the .tdc files.  Caveat emptor that I
know very little about USB (as I indicated in the cover letter of my
series), but I'll do my best.  ;)


> It did.  Without your patches the opposite problem occurred; the status
> polls sometimes didn't get sent when they should have.
>
>> Oh, wait, I think I know what this is.  This is probably ("usb: dwc2:
>> host: Manage frame nums better in scheduler").  I'd bet that if you go
>> before that change then the behavior will be the way it was.
>>
>> In said patch you can see that dwc2_schedule_periodic() will now
>> always pick a new first frame.  As I understand it that will happen if
>> there was ever a short period of time when we weren't scheduled and I
>> was worried about the next slice being in the past.  It wouldn't hurt
>> to change the test to only pick a new first frame if the existing
>> first frame is in the past.  That would probably fix your problem.
>
> Are you perhaps thinking of isochronous transfers?  This is an
> interrupt endpoint, not isochronous.  Individual interrupt transfers
> don't have assigned slices.  The "Add a delay before releasing periodic
> bandwidth" patch seems more relevant.  Or maybe "Schedule periodic
> right away if it's time", although that comes before the tasklet patch.

Please try the past I posted that crossed your reply in the ether.  ;)
 AKA: .  I
reproduced what I think is your problem and this patch fixed it for
me.

In my scheduler all periodic transfers have reservations.  Perhaps
it's not critical to reserve for INT transfers, but that's how things
are setup right now.


>> Question: is the behavior you're seeing illegal / undesirable?  It
>> only happens when there's data available, right?  My current
>> (rewritten) reservation algorithm in dwc2 is pretty crude  From a high
>> speed device perspective it reserves a timeslot for the EP in every
>> microframe even if the EP has a long interval.  It won't typically
>> schedule the EP more often than every "interval" microframes, but the
>> reservation is there.  That means we can't support quite as many
>> devices at the same time, but it has the advantage that if we screw up
>> (like if we miss an SOF) we know we can actually try to make up for it
>> quickly and we won't collide with anyone else.  The whole thing also
>> simplifies the scheduler.  In your particular case, we used our
>> existing reservation to schedule the device a little sooner than
>> requested.
>
> It's not illegal.  Interrupt transfers are guaranteed to be scheduled
> at least as often as bInterval; there's nothing wrong with issuing them
> more frequently.  But it is a waste of bandwidth and CPU time to issue
> transfers more often than necessary, so it is undesirable in that
> sense.

OK.  Well, hopefully fixed with my FIXUP patch.  ;)


> You know, from what you've said it seems that writing a proper periodic
> scheduler would be _easier_ for DWC2 than for EHCI.  The EHCI hardware
> requires special data structures to handle cases where a SPLIT packet
> occurs in microframe 7 or microframe 0 of the following frame; those
> structures are a nuisance to manage and ehci-hcd doesn't bother to
> implement them.  It sounds like DWC2 wouldn't need any of that.
> Furthermore, because coordination between the CPU and the EHCI core is
> rather asynchronous, it's difficult to change the microframe allotment
> for an interrupt endpoint should the schedule need to be rebalanced --
> that hasn't been implemented either.  Again, this should be much
> simpler for DWC2.
>
> I've got the overall design for a proper scheduler worked out in my
> head, but I have never sat down and written any of it because of the
> inertia involved in these two difficult requirements.  :-(

I'm certainly more than happy for any comments you might have or for
any followup or alternate patches for my dwc2 scheduler patches.  I'm
not attached to my scheduler and if someone wants to write a better
one I'm more than happy to have mine ripped out...  The only reason

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Alan,

On Wed, Jan 27, 2016 at 11:21 AM, Doug Anderson  wrote:
> Alan,
>
> On Wed, Jan 27, 2016 at 11:03 AM, Alan Stern  
> wrote:
>> On Tue, 26 Jan 2016, Doug Anderson wrote:
>>
>>> > This probably indicates that the list of patches was incomplete (i.e.,
>>> > some other patches were applied before these).  Also, the patches
>>> > aren't listed in order of the patchwork IDs -- which order is correct?
>>>
>>> The order like 01, 02, 03, etc is correct.  Patchwork numbers things
>>> in a random order (depending on the vagaries of SMTP and which one
>>> arrives to their server first).
>>>
>>> Ah, I had tried linux/master recently, but that has a patch that's not in 
>>> v4.4:
>>>
>>> fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
>>>
>>>
>>> I'd bet that you don't have descriptor DMA turned on anyway, so the
>>> descriptor DMA patches won't really matter (they'll just be noops).
>>> ...but you could pick all the patches up to that one to avoid
>>> conflicts.
>>>
>>> fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
>>> 762d3a1a9cd7 usb: dwc2: host: process all completed urbs
>>> 3f808bdae75e usb: dwc2: host: always increment available host channel
>>> during release
>>> c17b337c1ea4 usb: dwc2: host: program descriptor for next frame
>>> b9392d9920fd usb: dwc2: host: add function to compare frame index
>>> 2b046bc5aaef usb: dwc2: host: spinlock release channel
>>> 26a19ea69906 usb: dwc2: host: fix use of qtd after free in desc dma mode
>>> c503b3815385 usb: dwc2: host: rework isochronous halt path
>>> dde4c1bf5df0 usb: dwc2: host: set active bit in isochronous descriptors
>>> 3ac38d260fa5 usb: dwc2: host: ensure filling of isoc desc is correctly done
>>
>> In the end I just used the contents of the dwc2 directory from Linus's
>> current tree -- I don't think it has changed since 4.5-rc1.  Your
>> patches applied on top of that with no issues.
>>
>> They seem to work.  Is there anything in particular you would like me
>> to test?
>
> I was sorta wondering if it fixed the original problem you were
> seeing?  Unless I missed it it sounded like it was still broken on ToT
> and I was wondering if my series happened to help in any way...
>
> Other than that the series mostly improves compatibility with splits,
> especially when many periodic devices are plugged in (like a Full
> Speed USB audio device plugged in at the same time as several
> keyboards).
>
>
>> One problem I noticed: The controller does hub status polling to an
>> external high-speed hub much too frequently.  The interrupt endpoint's
>> bInterval value is 12, meaning the polling interval should be 256 ms.
>> But when data was available, the polls were issued every 2 microframes
>> instead of every 2048.
>>
>> Could the driver be rescheduling the interrupt endpoint every time an
>> URB completes and a new one is submitted?  That's what it looks like.
>> This might be related to the giving-URBs-back-in-a-tasklet change.
>
> Hrm.  That started with this series?  OK, I'll take a look and see if
> it can reproduce.
>
> Oh, wait, I think I know what this is.  This is probably ("usb: dwc2:
> host: Manage frame nums better in scheduler").  I'd bet that if you go
> before that change then the behavior will be the way it was.
>
> In said patch you can see that dwc2_schedule_periodic() will now
> always pick a new first frame.  As I understand it that will happen if
> there was ever a short period of time when we weren't scheduled and I
> was worried about the next slice being in the past.  It wouldn't hurt
> to change the test to only pick a new first frame if the existing
> first frame is in the past.  That would probably fix your problem.
>
> Question: is the behavior you're seeing illegal / undesirable?  It
> only happens when there's data available, right?  My current
> (rewritten) reservation algorithm in dwc2 is pretty crude  From a high
> speed device perspective it reserves a timeslot for the EP in every
> microframe even if the EP has a long interval.  It won't typically
> schedule the EP more often than every "interval" microframes, but the
> reservation is there.  That means we can't support quite as many
> devices at the same time, but it has the advantage that if we screw up
> (like if we miss an SOF) we know we can actually try to make up for it
> quickly and we won't collide with anyone else.  The whole thing also
> simplifies the scheduler.  In your particular case, we used our
> existing reservation to schedule the device a little sooner than
> requested.

This patch should fix ya.

FIXUP: FROMLIST: usb: dwc2: host: Manage frame nums better in scheduler
https://chromium-review.googlesource.com/324185


The series is starting to get enough comments that I'm tempted to send
up a new version, but I'm always a little reluctant to post 21 patches
again if more feedback is coming.

Unless I hear otherwise, I'll plan to post up a new version with
accumulated fixes 

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Wed, 27 Jan 2016, Doug Anderson wrote:

> > In the end I just used the contents of the dwc2 directory from Linus's
> > current tree -- I don't think it has changed since 4.5-rc1.  Your
> > patches applied on top of that with no issues.
> >
> > They seem to work.  Is there anything in particular you would like me
> > to test?
> 
> I was sorta wondering if it fixed the original problem you were
> seeing?  Unless I missed it it sounded like it was still broken on ToT
> and I was wondering if my series happened to help in any way...

They did not fix the original problem.  I still have no idea what could 
be causing the device's selective behavior.  If you want, I can send 
you the .tdc analyzer files for kernels with and without your patch 
series.  Maybe you'll see something I missed.

> Other than that the series mostly improves compatibility with splits,
> especially when many periodic devices are plugged in (like a Full
> Speed USB audio device plugged in at the same time as several
> keyboards).

Alright, I can try something like that.

> > One problem I noticed: The controller does hub status polling to an
> > external high-speed hub much too frequently.  The interrupt endpoint's
> > bInterval value is 12, meaning the polling interval should be 256 ms.
> > But when data was available, the polls were issued every 2 microframes
> > instead of every 2048.
> >
> > Could the driver be rescheduling the interrupt endpoint every time an
> > URB completes and a new one is submitted?  That's what it looks like.
> > This might be related to the giving-URBs-back-in-a-tasklet change.
> 
> Hrm.  That started with this series?  OK, I'll take a look and see if
> it can reproduce.

It did.  Without your patches the opposite problem occurred; the status 
polls sometimes didn't get sent when they should have.

> Oh, wait, I think I know what this is.  This is probably ("usb: dwc2:
> host: Manage frame nums better in scheduler").  I'd bet that if you go
> before that change then the behavior will be the way it was.
> 
> In said patch you can see that dwc2_schedule_periodic() will now
> always pick a new first frame.  As I understand it that will happen if
> there was ever a short period of time when we weren't scheduled and I
> was worried about the next slice being in the past.  It wouldn't hurt
> to change the test to only pick a new first frame if the existing
> first frame is in the past.  That would probably fix your problem.

Are you perhaps thinking of isochronous transfers?  This is an
interrupt endpoint, not isochronous.  Individual interrupt transfers
don't have assigned slices.  The "Add a delay before releasing periodic
bandwidth" patch seems more relevant.  Or maybe "Schedule periodic
right away if it's time", although that comes before the tasklet patch.

> Question: is the behavior you're seeing illegal / undesirable?  It
> only happens when there's data available, right?  My current
> (rewritten) reservation algorithm in dwc2 is pretty crude  From a high
> speed device perspective it reserves a timeslot for the EP in every
> microframe even if the EP has a long interval.  It won't typically
> schedule the EP more often than every "interval" microframes, but the
> reservation is there.  That means we can't support quite as many
> devices at the same time, but it has the advantage that if we screw up
> (like if we miss an SOF) we know we can actually try to make up for it
> quickly and we won't collide with anyone else.  The whole thing also
> simplifies the scheduler.  In your particular case, we used our
> existing reservation to schedule the device a little sooner than
> requested.

It's not illegal.  Interrupt transfers are guaranteed to be scheduled
at least as often as bInterval; there's nothing wrong with issuing them
more frequently.  But it is a waste of bandwidth and CPU time to issue
transfers more often than necessary, so it is undesirable in that
sense.

You know, from what you've said it seems that writing a proper periodic
scheduler would be _easier_ for DWC2 than for EHCI.  The EHCI hardware
requires special data structures to handle cases where a SPLIT packet
occurs in microframe 7 or microframe 0 of the following frame; those
structures are a nuisance to manage and ehci-hcd doesn't bother to
implement them.  It sounds like DWC2 wouldn't need any of that.  
Furthermore, because coordination between the CPU and the EHCI core is
rather asynchronous, it's difficult to change the microframe allotment
for an interrupt endpoint should the schedule need to be rebalanced --
that hasn't been implemented either.  Again, this should be much
simpler for DWC2.

I've got the overall design for a proper scheduler worked out in my
head, but I have never sat down and written any of it because of the
inertia involved in these two difficult requirements.  :-(

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More 

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Wed, 27 Jan 2016, Doug Anderson wrote:

> This patch should fix ya.
> 
> FIXUP: FROMLIST: usb: dwc2: host: Manage frame nums better in scheduler
> https://chromium-review.googlesource.com/324185

Hmmm.  That fixed the problem of the polls occuring too frequently, but
now I see again intervals that are larger than 256 ms.  In the most
recent test there are two intervals of 512 ms and one of 2048 ms.

Alan Stern

PS: Is the databook for the DWC2 controller available for download?  
I'm going on vacation starting next week, and I might want to have a 
little light reading to take along.  :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Alan,

On Wed, Jan 27, 2016 at 1:34 PM, Alan Stern  wrote:
> On Wed, 27 Jan 2016, Doug Anderson wrote:
>
>> This patch should fix ya.
>>
>> FIXUP: FROMLIST: usb: dwc2: host: Manage frame nums better in scheduler
>> https://chromium-review.googlesource.com/324185
>
> Hmmm.  That fixed the problem of the polls occuring too frequently, but
> now I see again intervals that are larger than 256 ms.  In the most
> recent test there are two intervals of 512 ms and one of 2048 ms.

OK, good to know.  Ugh.  I'll have to see if I can reproduce that.  If
I had to guess, though, I'd say that you're probably running into high
interrupt latency problems.  Those problems would be worse on the
Raspberry Pi than on my system due to the significantly slower
processor.

Can you confirm that these problems also were introduced by my series?
 AKA: you never saw > 256 ms polls before my series and now you see
them?


Turning on scheduler tracing would probably be quite helpful at this
point.  You can see
.  If printing
even non-verbose traces to the console is too much, you could make
everything "trace_printk".  You might also want
.

Things printed with trace_printk will end up in
/sys/kernel/debug/tracing/.  See "trace" for a single trace buffer or
trace_pipe.  Using the trace buffer can be a bit of a pain but the
cost of the prints is much lower which is why it works well for
verbose scheduler spew.


I typically like the non-verbose stuff in the console and the verbose
stuff in the trace buffer.  Then I can look in the console for info on
what's scheduled and grep through the trace buffer for it.


> PS: Is the databook for the DWC2 controller available for download?
> I'm going on vacation starting next week, and I might want to have a
> little light reading to take along.  :-)

I don't have a databook that I can give you, unfortunately.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Wed, 27 Jan 2016, Doug Anderson wrote:

> Alan,
> 
> On Wed, Jan 27, 2016 at 1:34 PM, Alan Stern  wrote:
> > On Wed, 27 Jan 2016, Doug Anderson wrote:
> >
> >> This patch should fix ya.
> >>
> >> FIXUP: FROMLIST: usb: dwc2: host: Manage frame nums better in scheduler
> >> https://chromium-review.googlesource.com/324185
> >
> > Hmmm.  That fixed the problem of the polls occuring too frequently, but
> > now I see again intervals that are larger than 256 ms.  In the most
> > recent test there are two intervals of 512 ms and one of 2048 ms.
> 
> OK, good to know.  Ugh.  I'll have to see if I can reproduce that.  If
> I had to guess, though, I'd say that you're probably running into high
> interrupt latency problems.

Quite possibly.  Would that delay the transfers by a full period or 
only by one frame?

>  Those problems would be worse on the
> Raspberry Pi than on my system due to the significantly slower
> processor.
> 
> Can you confirm that these problems also were introduced by my series?
>  AKA: you never saw > 256 ms polls before my series and now you see
> them?

No, these problems were also present in the kernel without your 
patches.

> Turning on scheduler tracing would probably be quite helpful at this
> point.  You can see
> .  If printing
> even non-verbose traces to the console is too much, you could make
> everything "trace_printk".  You might also want
> .

Later...

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Mon, 25 Jan 2016, Doug Anderson wrote:

> Hi,
> 
> On Mon, Jan 25, 2016 at 1:51 PM, Alan Stern  wrote:
> > On Mon, 25 Jan 2016, Peter Stuge wrote:
> >
> >> Alan Stern wrote:
> >> > the device's embedded hub ACKs the packets from the PC and not the
> >> > packets from the RPi.
> >> >
> >> > What other differences could there be?  Timing?  Power levels?
> >>
> >> Yes, both good candidates. Can you measure VUSB?
> >
> > Distinctly higher than 5V.
> >
> >> As for timing, the
> >> host controller will send SOF more or less regularly, if too
> >> irregular then that could cause problems for the device. Does your
> >> analyzer provide precise timestamps?
> >
> > Yes, but the software doesn't want to display individual SOF packets.
> > However I can see, for example, that 84 SOF packets were sent during a
> > 10.3-ms period.  Or 2048 were sent during a 256-ms period.  It seems
> > pretty regular.
> 
> What analyzer are you using?

The Total Phase Beagle 480, with their Data Center analysis software.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Noralf Trønnes]

Den 26.01.2016 17:55, skrev Alan Stern:

On Mon, 25 Jan 2016, Doug Anderson wrote:


...another interesting idea would be to try to see if you could just
change the configuration of the Raspberry Pi kernel to switch which
dwc2 driver it used.  Presumably their driver was an addition on top
of the driver in "drivers/usb/dwc2".  In fact, doing a 'git log' on
drivers/usb/dwc2 in the "rpi-4.4.y" kernel on github it looks pure
(and Stefan is even the last commit author!)

I'll try it.  In case it works: There have been lots of patches from
you and John posted to linux-usb in the last couple of months; which
ones should I apply for testing on top of d51c7d840b002?  (That was the
top commit on the master branch at the time I shallow-cloned the
Raspberry Pi kernel from github -- looks like it's based on 4.1.15.)

It's possible it makes more sense to switch to the 4.4 RPI kernel
first to make thing simpler?  Presumably that would have fewer patches
to try applying atop.

I installed the rpi-4.4.y branch from the
https://github.com/raspberrypi/linux repository.  As is, it generated a
working kernel.  Then I tried editing the config; I removed
CONFIG_USB_DWCOTG and added CONFIG_USB_DWC2 and CONFIG_USB_DWC2_HOST.
However, when I booted the resulting kernel it didn't seem to detect
the host controller at all.  No USB devices were probed, which meant no
working ethernet or keyboard.

Then I tried enabling both drivers in the config.  That worked, but the
controller was bound to dwc_otg, not to dwc2.

I get the feeling that some magic DT incantation is missing, although I
have no idea what.  The base bcm2709-rpi-2-b.dtb wasn't affected by the
config change, nor was the overlays/dwc2-overlay.dtb file.

Any suggestions?


Have you enabled the dwc2 overlay?
Add to /boot/config.txt:
dtoverlay=dwc2


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Mon, 25 Jan 2016, Doug Anderson wrote:

> >> ...another interesting idea would be to try to see if you could just
> >> change the configuration of the Raspberry Pi kernel to switch which
> >> dwc2 driver it used.  Presumably their driver was an addition on top
> >> of the driver in "drivers/usb/dwc2".  In fact, doing a 'git log' on
> >> drivers/usb/dwc2 in the "rpi-4.4.y" kernel on github it looks pure
> >> (and Stefan is even the last commit author!)
> >
> > I'll try it.  In case it works: There have been lots of patches from
> > you and John posted to linux-usb in the last couple of months; which
> > ones should I apply for testing on top of d51c7d840b002?  (That was the
> > top commit on the master branch at the time I shallow-cloned the
> > Raspberry Pi kernel from github -- looks like it's based on 4.1.15.)
> 
> It's possible it makes more sense to switch to the 4.4 RPI kernel
> first to make thing simpler?  Presumably that would have fewer patches
> to try applying atop.

I installed the rpi-4.4.y branch from the 
https://github.com/raspberrypi/linux repository.  As is, it generated a 
working kernel.  Then I tried editing the config; I removed 
CONFIG_USB_DWCOTG and added CONFIG_USB_DWC2 and CONFIG_USB_DWC2_HOST.  
However, when I booted the resulting kernel it didn't seem to detect 
the host controller at all.  No USB devices were probed, which meant no 
working ethernet or keyboard.

Then I tried enabling both drivers in the config.  That worked, but the 
controller was bound to dwc_otg, not to dwc2.

I get the feeling that some magic DT incantation is missing, although I 
have no idea what.  The base bcm2709-rpi-2-b.dtb wasn't affected by the 
config change, nor was the overlays/dwc2-overlay.dtb file.

Any suggestions?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Tue, Jan 26, 2016 at 7:08 AM, Alan Stern  wrote:
> On Mon, 25 Jan 2016, Doug Anderson wrote:
>
>> Hi,
>>
>> On Mon, Jan 25, 2016 at 1:51 PM, Alan Stern  
>> wrote:
>> > On Mon, 25 Jan 2016, Peter Stuge wrote:
>> >
>> >> Alan Stern wrote:
>> >> > the device's embedded hub ACKs the packets from the PC and not the
>> >> > packets from the RPi.
>> >> >
>> >> > What other differences could there be?  Timing?  Power levels?
>> >>
>> >> Yes, both good candidates. Can you measure VUSB?
>> >
>> > Distinctly higher than 5V.
>> >
>> >> As for timing, the
>> >> host controller will send SOF more or less regularly, if too
>> >> irregular then that could cause problems for the device. Does your
>> >> analyzer provide precise timestamps?
>> >
>> > Yes, but the software doesn't want to display individual SOF packets.
>> > However I can see, for example, that 84 SOF packets were sent during a
>> > 10.3-ms period.  Or 2048 were sent during a 256-ms period.  It seems
>> > pretty regular.
>>
>> What analyzer are you using?
>
> The Total Phase Beagle 480, with their Data Center analysis software.

Hrm.  I've got the Beagle 5000 Superspeed on my desk.  I can get it to
show me individual SOFs, but maybe that's a feature of the new
hardware?  I'm using Data Center v6.63.000

I had to turn on lots of stuff to see all this and it eats up lots of
memory quickly, but it works.  I've got:

Capture Settings, USB
-> Sequential
-> Keep USB 2.0 Data-less Sequences

In device settings I make sure it's not Filtering anything...

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Tue, 26 Jan 2016, Doug Anderson wrote:

> >> > Yes, but the software doesn't want to display individual SOF packets.
> >> > However I can see, for example, that 84 SOF packets were sent during a
> >> > 10.3-ms period.  Or 2048 were sent during a 256-ms period.  It seems
> >> > pretty regular.
> >>
> >> What analyzer are you using?
> >
> > The Total Phase Beagle 480, with their Data Center analysis software.
> 
> Hrm.  I've got the Beagle 5000 Superspeed on my desk.  I can get it to
> show me individual SOFs, but maybe that's a feature of the new
> hardware?  I'm using Data Center v6.63.000
> 
> I had to turn on lots of stuff to see all this and it eats up lots of
> memory quickly, but it works.  I've got:
> 
> Capture Settings, USB
> -> Sequential
> -> Keep USB 2.0 Data-less Sequences
> 
> In device settings I make sure it's not Filtering anything...

I had the wrong capture settings.  After changing them to match yours, 
I am now able to display the individual SOF packets.

The interval between SOFs is 125 us with a slight excess.  The excess
varies, sometimes 16 and sometimes 33 ns.  This probably represents the
resolution of the analyzer's hardware clock.  Either there's a slight
frequency mismatch between the analyzer and the controller clocks or
else the controller is letting each microframe run about 31 ns too
long.  Still, it seems to be quite regular.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Tue, 26 Jan 2016, Noralf Trønnes wrote:

> > I installed the rpi-4.4.y branch from the
> > https://github.com/raspberrypi/linux repository.  As is, it generated a
> > working kernel.  Then I tried editing the config; I removed
> > CONFIG_USB_DWCOTG and added CONFIG_USB_DWC2 and CONFIG_USB_DWC2_HOST.
> > However, when I booted the resulting kernel it didn't seem to detect
> > the host controller at all.  No USB devices were probed, which meant no
> > working ethernet or keyboard.
> >
> > Then I tried enabling both drivers in the config.  That worked, but the
> > controller was bound to dwc_otg, not to dwc2.
> >
> > I get the feeling that some magic DT incantation is missing, although I
> > have no idea what.  The base bcm2709-rpi-2-b.dtb wasn't affected by the
> > config change, nor was the overlays/dwc2-overlay.dtb file.
> >
> > Any suggestions?
> 
> Have you enabled the dwc2 overlay?
> Add to /boot/config.txt:
> dtoverlay=dwc2

That did it!  Thank you.

The dwc2 driver seems to do a better job than dwc_otg -- at least, it 
sends Clear-TT-Buffer requests after each failure.

Doug, do you have a list of patches you'd like me to try on top of the 
rpi-4.4.y branch?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Tue, Jan 26, 2016 at 10:22 AM, Alan Stern  wrote:
> On Tue, 26 Jan 2016, Noralf Trønnes wrote:
>
>> > I installed the rpi-4.4.y branch from the
>> > https://github.com/raspberrypi/linux repository.  As is, it generated a
>> > working kernel.  Then I tried editing the config; I removed
>> > CONFIG_USB_DWCOTG and added CONFIG_USB_DWC2 and CONFIG_USB_DWC2_HOST.
>> > However, when I booted the resulting kernel it didn't seem to detect
>> > the host controller at all.  No USB devices were probed, which meant no
>> > working ethernet or keyboard.
>> >
>> > Then I tried enabling both drivers in the config.  That worked, but the
>> > controller was bound to dwc_otg, not to dwc2.
>> >
>> > I get the feeling that some magic DT incantation is missing, although I
>> > have no idea what.  The base bcm2709-rpi-2-b.dtb wasn't affected by the
>> > config change, nor was the overlays/dwc2-overlay.dtb file.
>> >
>> > Any suggestions?
>>
>> Have you enabled the dwc2 overlay?
>> Add to /boot/config.txt:
>> dtoverlay=dwc2
>
> That did it!  Thank you.
>
> The dwc2 driver seems to do a better job than dwc_otg -- at least, it
> sends Clear-TT-Buffer requests after each failure.
>
> Doug, do you have a list of patches you'd like me to try on top of the
> rpi-4.4.y branch?

Nice!  You can give this series a try.  It aims to improve SPLIT
scheduling quite a bit:

8091691 New  [v5,01/21] usb: dwc2: rockchip: Make the
max_transfer_size automatic
8091701 New  [v5,02/21] usb: dwc2: host: Get aligned DMA in a
more supported way
8092101 New  [v5,03/21] usb: dwc2: host: Set host_rx_fifo_size
to 528 for rk3066
8092091 New  [v5,04/21] usb: dwc2: host: Set
host_perio_tx_fifo_size to 304 for rk3066
8092081 New  [v5,05/21] usb: dwc2: host: Avoid use of chan->qh
after qh freed
8092071 New  [v5,06/21] usb: dwc2: host: Always add to the
tail of queues
8092061 New  [v5,07/21] usb: dwc2: hcd: fix split transfer
schedule sequence
8091761 New  [v5,08/21] usb: dwc2: host: Add scheduler tracing
8092051 New  [v5,09/21] usb: dwc2: host: Add a delay before
releasing periodic bandwidth
8092041 New  [v5,10/21] usb: dwc2: host: Giveback URB in tasklet context
8092031 New  [v5,11/21] usb: dwc2: host: Use periodic
interrupt even with DMA
8092021 New  [v5,12/21] usb: dwc2: host: Rename some fields in
struct dwc2_qh
8092011 New  [v5,13/21] usb: dwc2: host: Reorder things in hcd_queue.c
8092001 New  [v5,14/21] usb: dwc2: host: Split code out to
make dwc2_do_reserve()
8091991 New  [v5,15/21] usb: dwc2: host: Add scheduler logging
for missed SOFs
8091821 New  [v5,16/21] usb: dwc2: host: Manage frame nums
better in scheduler
8091831 New  [v5,17/21] usb: dwc2: host: Schedule periodic
right away if it's time
8091971 New  [v5,18/21] usb: dwc2: host: Add
dwc2_hcd_get_future_frame_number() call
8091961 New  [v5,19/21] usb: dwc2: host: Properly set even/odd frame
8091981 New  [v5,20/21] usb: dwc2: host: Totally redo the
microframe scheduler
8091951 New  [v5,21/21] usb: dwc2: host: If using uframe
scheduler, end splits better

Plus grab:

8094921 New  usb: dwc2: host: Properly set the HFIR

You could ignore the two rk3066 patches, though they won't hurt you.
Hopefully you also saw the note that you should pick the two patches:

http://marc.info/?l=linux-usb=145255851516121=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Tue, Jan 26, 2016 at 10:26 AM, Doug Anderson  wrote:
> Hi,
>
> On Tue, Jan 26, 2016 at 10:22 AM, Alan Stern  
> wrote:
>> On Tue, 26 Jan 2016, Noralf Trønnes wrote:
>>
>>> > I installed the rpi-4.4.y branch from the
>>> > https://github.com/raspberrypi/linux repository.  As is, it generated a
>>> > working kernel.  Then I tried editing the config; I removed
>>> > CONFIG_USB_DWCOTG and added CONFIG_USB_DWC2 and CONFIG_USB_DWC2_HOST.
>>> > However, when I booted the resulting kernel it didn't seem to detect
>>> > the host controller at all.  No USB devices were probed, which meant no
>>> > working ethernet or keyboard.
>>> >
>>> > Then I tried enabling both drivers in the config.  That worked, but the
>>> > controller was bound to dwc_otg, not to dwc2.
>>> >
>>> > I get the feeling that some magic DT incantation is missing, although I
>>> > have no idea what.  The base bcm2709-rpi-2-b.dtb wasn't affected by the
>>> > config change, nor was the overlays/dwc2-overlay.dtb file.
>>> >
>>> > Any suggestions?
>>>
>>> Have you enabled the dwc2 overlay?
>>> Add to /boot/config.txt:
>>> dtoverlay=dwc2
>>
>> That did it!  Thank you.
>>
>> The dwc2 driver seems to do a better job than dwc_otg -- at least, it
>> sends Clear-TT-Buffer requests after each failure.
>>
>> Doug, do you have a list of patches you'd like me to try on top of the
>> rpi-4.4.y branch?
>
> Nice!  You can give this series a try.  It aims to improve SPLIT
> scheduling quite a bit:
>
> 8091691 New  [v5,01/21] usb: dwc2: rockchip: Make the
> max_transfer_size automatic
> 8091701 New  [v5,02/21] usb: dwc2: host: Get aligned DMA in a
> more supported way
> 8092101 New  [v5,03/21] usb: dwc2: host: Set host_rx_fifo_size
> to 528 for rk3066
> 8092091 New  [v5,04/21] usb: dwc2: host: Set
> host_perio_tx_fifo_size to 304 for rk3066
> 8092081 New  [v5,05/21] usb: dwc2: host: Avoid use of chan->qh
> after qh freed
> 8092071 New  [v5,06/21] usb: dwc2: host: Always add to the
> tail of queues
> 8092061 New  [v5,07/21] usb: dwc2: hcd: fix split transfer
> schedule sequence
> 8091761 New  [v5,08/21] usb: dwc2: host: Add scheduler tracing
> 8092051 New  [v5,09/21] usb: dwc2: host: Add a delay before
> releasing periodic bandwidth
> 8092041 New  [v5,10/21] usb: dwc2: host: Giveback URB in tasklet 
> context
> 8092031 New  [v5,11/21] usb: dwc2: host: Use periodic
> interrupt even with DMA
> 8092021 New  [v5,12/21] usb: dwc2: host: Rename some fields in
> struct dwc2_qh
> 8092011 New  [v5,13/21] usb: dwc2: host: Reorder things in hcd_queue.c
> 8092001 New  [v5,14/21] usb: dwc2: host: Split code out to
> make dwc2_do_reserve()
> 8091991 New  [v5,15/21] usb: dwc2: host: Add scheduler logging
> for missed SOFs
> 8091821 New  [v5,16/21] usb: dwc2: host: Manage frame nums
> better in scheduler
> 8091831 New  [v5,17/21] usb: dwc2: host: Schedule periodic
> right away if it's time
> 8091971 New  [v5,18/21] usb: dwc2: host: Add
> dwc2_hcd_get_future_frame_number() call
> 8091961 New  [v5,19/21] usb: dwc2: host: Properly set even/odd frame
> 8091981 New  [v5,20/21] usb: dwc2: host: Totally redo the
> microframe scheduler
> 8091951 New  [v5,21/21] usb: dwc2: host: If using uframe
> scheduler, end splits better
>
> Plus grab:
>
> 8094921 New  usb: dwc2: host: Properly set the HFIR
>
> You could ignore the two rk3066 patches, though they won't hurt you.
> Hopefully you also saw the note that you should pick the two patches:
>
> http://marc.info/?l=linux-usb=145255851516121=2

Oh, and above IDs are patchwork.kernel.org IDs.  So the HFIR patch can
be found at  (or applied
via the pwclient command line tool).

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Tue, 26 Jan 2016, Doug Anderson wrote:

> >> Doug, do you have a list of patches you'd like me to try on top of the
> >> rpi-4.4.y branch?
> >
> > Nice!  You can give this series a try.  It aims to improve SPLIT
> > scheduling quite a bit:
> >
> > 8091691 New  [v5,01/21] usb: dwc2: rockchip: Make the
> > max_transfer_size automatic
> > 8091701 New  [v5,02/21] usb: dwc2: host: Get aligned DMA in a
> > more supported way

This one failed to apply; there was a merge conflict in hcd_queue.c.  
The original code says:

void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
{
if (hsotg->core_params->dma_desc_enable > 0) {
dwc2_hcd_qh_free_ddma(hsotg, qh);
} else {

whereas the patch says:

 void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
 {
-   if (qh->desc_list) {
+   if (qh->desc_list)
dwc2_hcd_qh_free_ddma(hsotg, qh);
-   } else {

This probably indicates that the list of patches was incomplete (i.e.,
some other patches were applied before these).  Also, the patches
aren't listed in order of the patchwork IDs -- which order is correct?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Alan,

On Tue, Jan 26, 2016 at 12:29 PM, Alan Stern  wrote:
> On Tue, 26 Jan 2016, Doug Anderson wrote:
>
>> >> Doug, do you have a list of patches you'd like me to try on top of the
>> >> rpi-4.4.y branch?
>> >
>> > Nice!  You can give this series a try.  It aims to improve SPLIT
>> > scheduling quite a bit:
>> >
>> > 8091691 New  [v5,01/21] usb: dwc2: rockchip: Make the
>> > max_transfer_size automatic
>> > 8091701 New  [v5,02/21] usb: dwc2: host: Get aligned DMA in a
>> > more supported way
>
> This one failed to apply; there was a merge conflict in hcd_queue.c.
> The original code says:
>
> void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
> {
> if (hsotg->core_params->dma_desc_enable > 0) {
> dwc2_hcd_qh_free_ddma(hsotg, qh);
> } else {
>
> whereas the patch says:
>
>  void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
>  {
> -   if (qh->desc_list) {
> +   if (qh->desc_list)
> dwc2_hcd_qh_free_ddma(hsotg, qh);
> -   } else {
>
> This probably indicates that the list of patches was incomplete (i.e.,
> some other patches were applied before these).  Also, the patches
> aren't listed in order of the patchwork IDs -- which order is correct?

The order like 01, 02, 03, etc is correct.  Patchwork numbers things
in a random order (depending on the vagaries of SMTP and which one
arrives to their server first).

Ah, I had tried linux/master recently, but that has a patch that's not in v4.4:

fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices


I'd bet that you don't have descriptor DMA turned on anyway, so the
descriptor DMA patches won't really matter (they'll just be noops).
...but you could pick all the patches up to that one to avoid
conflicts.

fbb9e22b15ad usb: dwc2: host: enable descriptor dma for fs devices
762d3a1a9cd7 usb: dwc2: host: process all completed urbs
3f808bdae75e usb: dwc2: host: always increment available host channel
during release
c17b337c1ea4 usb: dwc2: host: program descriptor for next frame
b9392d9920fd usb: dwc2: host: add function to compare frame index
2b046bc5aaef usb: dwc2: host: spinlock release channel
26a19ea69906 usb: dwc2: host: fix use of qtd after free in desc dma mode
c503b3815385 usb: dwc2: host: rework isochronous halt path
dde4c1bf5df0 usb: dwc2: host: set active bit in isochronous descriptors
3ac38d260fa5 usb: dwc2: host: ensure filling of isoc desc is correctly done


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Noralf Trønnes]

Den 25.01.2016 23:07, skrev Stefan Wahren:

Doug Anderson  hat am 25. Januar 2016 um 21:44
geschrieben:


Hi,

On Mon, Jan 25, 2016 at 12:05 PM, Alan Stern 
wrote:

On Fri, 22 Jan 2016, Doug Anderson wrote:


Can you tell me how to configure a mainline kernel to work on the
Raspberry Pi? There is no arch/arm/configs/bcmrpi_defconfig.

Not offhand. Again, perhaps someone else on this thread will have
more. I did do a quick Google search and came up with:

http://elinux.org/RPi_Upstream_Kernel_Compilation

...but the Raspberry Pi I have at home is running some home automation
stuff so I don't want to give that a try. :-P

I followed those instructions, and the result doesn't boot. No easy
way to figure out why -- nothing shows up on the HDMI screen but the
color splash.

Interestingly enough Stefan Wahren reached out to me after my recent
patch series indicating that my series didn't fix some other problem
he was having on his Raspberry Pi. Presumably that means he might
have some pointers?

Stefan: do you have any pointer to instructions that Alan can use to
get a booting Raspberry Pi kernel based on mainline Linux?

It sounds like that bootloader doesn't came up.

You will need to add / replace the following files in the FAT partition of an
raspbian:
kernel.img (U-Boot)
boot.scr.uimg
bcm2835-rpi*.dtb (from kernel)
zImage


...another interesting idea would be to try to see if you could just
change the configuration of the Raspberry Pi kernel to switch which
dwc2 driver it used. Presumably their driver was an addition on top
of the driver in "drivers/usb/dwc2". In fact, doing a 'git log' on
drivers/usb/dwc2 in the "rpi-4.4.y" kernel on github it looks pure
(and Stefan is even the last commit author!)

-Doug

dwc2 is broken in Linux 4.4 and newer


We are using dwc2 downstream[1] on 4.4 to get gadget support on
Pi Zero. I didn't add any extra patches to get that working.
The only difference I can think of is that we boot directly from the
firmware bootloader and turn on USB power in the firmware driver.

I have seen strange dwc2 probing errors when USB power is off.

Noralf.

[1] https://github.com/raspberrypi/linux/tree/rpi-4.4.y


Please apply the following patch series:

http://marc.info/?l=linux-usb=145255851516121=2

___
linux-rpi-kernel mailing list
linux-rpi-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Fri, 22 Jan 2016, Doug Anderson wrote:

> > The corresponding line in the dwc2_host_hub_info() routine simply does:
> >
> > *hub_port = urb->dev->ttport;
> >
> > Unfortunately, even after I changed the dwc_otg routine the device
> > still didn't work.  My bus analyzer isn't on hand today, so I'll have
> > to work on it more next week.

Okay, I checked it.  Oddly enough, even though the SPLIT packet's
contents are now correct, the device still doesn't respond.

Bizarrely, when I interpose a USB-1.1 hub between the RPi and the
compound device, it _does_ work.  I guess this indicates the device's
embedded hub isn't quite up to snuff.  But why it should work okay with 
a PC and not with a Raspberry Pi is beyond me.

> > Can you tell me how to configure a mainline kernel to work on the
> > Raspberry Pi?  There is no arch/arm/configs/bcmrpi_defconfig.
> 
> Not offhand.  Again, perhaps someone else on this thread will have
> more.  I did do a quick Google search and came up with:
> 
> http://elinux.org/RPi_Upstream_Kernel_Compilation
> 
> ...but the Raspberry Pi I have at home is running some home automation
> stuff so I don't want to give that a try.  :-P

I followed those instructions, and the result doesn't boot.  No easy 
way to figure out why -- nothing shows up on the HDMI screen but the 
color splash.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Mon, 25 Jan 2016, Doug Anderson wrote:

> > Okay, I checked it.  Oddly enough, even though the SPLIT packet's
> > contents are now correct, the device still doesn't respond.
> >
> > Bizarrely, when I interpose a USB-1.1 hub between the RPi and the
> > compound device, it _does_ work.  I guess this indicates the device's
> > embedded hub isn't quite up to snuff.  But why it should work okay with
> > a PC and not with a Raspberry Pi is beyond me.
> 
> I just spent a lot of time tracking down lots of problems with SPLITs
> in the mainline driver.  No idea if there are similar problems in the
> RPI driver.

The strange thing is that the packets sent to the device are now 
identical (except for address numbers and checksums) between the RPi 
and the PC.  And yet the device's embedded hub ACKs the packets from 
the PC and not the packets from the RPi.

What other differences could there be?  Timing?  Power levels?  
Something else I'm not seeing?

> Note that I have one hub that I've been debugging that still has
> problems after all my patches.  My current (unsubstantiated) guess is
> that the hub is somehow missing a reset or a configuration packet.
> When I plug this hub in it either works or it doesn't work and seems
> to stay in that state until I unplug / replug the hub.  I wonder if
> there could be something similar?

I doubt it, because the behavior I'm seeing is completely consistent 
from one run to another.

> ...another interesting idea would be to try to see if you could just
> change the configuration of the Raspberry Pi kernel to switch which
> dwc2 driver it used.  Presumably their driver was an addition on top
> of the driver in "drivers/usb/dwc2".  In fact, doing a 'git log' on
> drivers/usb/dwc2 in the "rpi-4.4.y" kernel on github it looks pure
> (and Stefan is even the last commit author!)

I'll try it.  In case it works: There have been lots of patches from
you and John posted to linux-usb in the last couple of months; which
ones should I apply for testing on top of d51c7d840b002?  (That was the
top commit on the master branch at the time I shallow-cloned the
Raspberry Pi kernel from github -- looks like it's based on 4.1.15.)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Mon, Jan 25, 2016 at 1:51 PM, Alan Stern  wrote:
> On Mon, 25 Jan 2016, Peter Stuge wrote:
>
>> Alan Stern wrote:
>> > the device's embedded hub ACKs the packets from the PC and not the
>> > packets from the RPi.
>> >
>> > What other differences could there be?  Timing?  Power levels?
>>
>> Yes, both good candidates. Can you measure VUSB?
>
> Distinctly higher than 5V.
>
>> As for timing, the
>> host controller will send SOF more or less regularly, if too
>> irregular then that could cause problems for the device. Does your
>> analyzer provide precise timestamps?
>
> Yes, but the software doesn't want to display individual SOF packets.
> However I can see, for example, that 84 SOF packets were sent during a
> 10.3-ms period.  Or 2048 were sent during a 256-ms period.  It seems
> pretty regular.

What analyzer are you using?

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Peter Stuge]

Alan Stern wrote:
> the device's embedded hub ACKs the packets from the PC and not the
> packets from the RPi.
> 
> What other differences could there be?  Timing?  Power levels?

Yes, both good candidates. Can you measure VUSB? As for timing, the
host controller will send SOF more or less regularly, if too
irregular then that could cause problems for the device. Does your
analyzer provide precise timestamps?


//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Alan,

On Mon, Jan 25, 2016 at 1:04 PM, Alan Stern  wrote:
> On Mon, 25 Jan 2016, Doug Anderson wrote:
>
>> > Okay, I checked it.  Oddly enough, even though the SPLIT packet's
>> > contents are now correct, the device still doesn't respond.
>> >
>> > Bizarrely, when I interpose a USB-1.1 hub between the RPi and the
>> > compound device, it _does_ work.  I guess this indicates the device's
>> > embedded hub isn't quite up to snuff.  But why it should work okay with
>> > a PC and not with a Raspberry Pi is beyond me.
>>
>> I just spent a lot of time tracking down lots of problems with SPLITs
>> in the mainline driver.  No idea if there are similar problems in the
>> RPI driver.
>
> The strange thing is that the packets sent to the device are now
> identical (except for address numbers and checksums) between the RPi
> and the PC.  And yet the device's embedded hub ACKs the packets from
> the PC and not the packets from the RPi.
>
> What other differences could there be?  Timing?  Power levels?
> Something else I'm not seeing?

I suppose there's a tiny chance it could be:

https://patchwork.kernel.org/patch/8094921/

I haven't seen that fix anything, but it is conceivable that it could.
It wouldn't be hard to apply that change to the RPI driver.  It's
possible that without that fix dwc2 may be sending some extra bits in
each microframe or it's possible that there may be a period of time
with no bits sent at all (I haven't looked at the wire to see what
actually happens and my analyzer doesn't tell me).

--

It's certainly also possible that things are just scheduled in the
wrong microframes.  As I said, I can't comment on the RPI driver but I
do know that dwc2 makes you do _everything_ in software.  Software
needs to get involved every 125us which means you need to have very
good interrupt latency and need to be able to service the dwc2
interrupts quickly.

In dwc2 you can tell the hardware about 2 uFrams MAX.  When you give a
packet to hardware you give it the "even / odd" flag.  If the
"evenness" of the packet you gave to the hardware matches the current
microframe number then it's transmitted in the current uFrame.  If the
evenness doesn't match it's transmitted in the next uFrame.

As you could maybe imagine, it can be challenging to make packets show
up at the right time, especially if you've got a slow system or bad
interrupt latency.  Before my patches the driver also never looked at
how far we were through the current microframe, so things could get
pretty mixed up if the microframe "ticked" at an unexpected time.


On my analyzer I have it capture every piece of data it can so I can
see all the SOFs and see exactly when packets were queued.


>> Note that I have one hub that I've been debugging that still has
>> problems after all my patches.  My current (unsubstantiated) guess is
>> that the hub is somehow missing a reset or a configuration packet.
>> When I plug this hub in it either works or it doesn't work and seems
>> to stay in that state until I unplug / replug the hub.  I wonder if
>> there could be something similar?
>
> I doubt it, because the behavior I'm seeing is completely consistent
> from one run to another.
>
>> ...another interesting idea would be to try to see if you could just
>> change the configuration of the Raspberry Pi kernel to switch which
>> dwc2 driver it used.  Presumably their driver was an addition on top
>> of the driver in "drivers/usb/dwc2".  In fact, doing a 'git log' on
>> drivers/usb/dwc2 in the "rpi-4.4.y" kernel on github it looks pure
>> (and Stefan is even the last commit author!)
>
> I'll try it.  In case it works: There have been lots of patches from
> you and John posted to linux-usb in the last couple of months; which
> ones should I apply for testing on top of d51c7d840b002?  (That was the
> top commit on the master branch at the time I shallow-cloned the
> Raspberry Pi kernel from github -- looks like it's based on 4.1.15.)

It's possible it makes more sense to switch to the 4.4 RPI kernel
first to make thing simpler?  Presumably that would have fewer patches
to try applying atop.

Personally I just take all the dwc2 patches because otherwise merging
becomes a nightmare.  I run regularly on a 3.14 kernel with dwc2
backports and there wasn't anything too hard to apply and there
weren't many out-of-dwc2 dependencies.  The recent 21-patch series
from me was what made splits (and general microframe scheduling) more
reliable, but still not perfect.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Mon, Jan 25, 2016 at 12:05 PM, Alan Stern  wrote:
> On Fri, 22 Jan 2016, Doug Anderson wrote:
>
>> > The corresponding line in the dwc2_host_hub_info() routine simply does:
>> >
>> > *hub_port = urb->dev->ttport;
>> >
>> > Unfortunately, even after I changed the dwc_otg routine the device
>> > still didn't work.  My bus analyzer isn't on hand today, so I'll have
>> > to work on it more next week.
>
> Okay, I checked it.  Oddly enough, even though the SPLIT packet's
> contents are now correct, the device still doesn't respond.
>
> Bizarrely, when I interpose a USB-1.1 hub between the RPi and the
> compound device, it _does_ work.  I guess this indicates the device's
> embedded hub isn't quite up to snuff.  But why it should work okay with
> a PC and not with a Raspberry Pi is beyond me.

I just spent a lot of time tracking down lots of problems with SPLITs
in the mainline driver.  No idea if there are similar problems in the
RPI driver.

Note that I have one hub that I've been debugging that still has
problems after all my patches.  My current (unsubstantiated) guess is
that the hub is somehow missing a reset or a configuration packet.
When I plug this hub in it either works or it doesn't work and seems
to stay in that state until I unplug / replug the hub.  I wonder if
there could be something similar?


>> > Can you tell me how to configure a mainline kernel to work on the
>> > Raspberry Pi?  There is no arch/arm/configs/bcmrpi_defconfig.
>>
>> Not offhand.  Again, perhaps someone else on this thread will have
>> more.  I did do a quick Google search and came up with:
>>
>> http://elinux.org/RPi_Upstream_Kernel_Compilation
>>
>> ...but the Raspberry Pi I have at home is running some home automation
>> stuff so I don't want to give that a try.  :-P
>
> I followed those instructions, and the result doesn't boot.  No easy
> way to figure out why -- nothing shows up on the HDMI screen but the
> color splash.

Interestingly enough Stefan Wahren reached out to me after my recent
patch series indicating that my series didn't fix some other problem
he was having on his Raspberry Pi.  Presumably that means he might
have some pointers?

Stefan: do you have any pointer to instructions that Alan can use to
get a booting Raspberry Pi kernel based on mainline Linux?

...another interesting idea would be to try to see if you could just
change the configuration of the Raspberry Pi kernel to switch which
dwc2 driver it used.  Presumably their driver was an addition on top
of the driver in "drivers/usb/dwc2".  In fact, doing a 'git log' on
drivers/usb/dwc2 in the "rpi-4.4.y" kernel on github it looks pure
(and Stefan is even the last commit author!)

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Stefan Wahren]

> Doug Anderson  hat am 25. Januar 2016 um 21:44
> geschrieben:
>
>
> Hi,
>
> On Mon, Jan 25, 2016 at 12:05 PM, Alan Stern 
> wrote:
> > On Fri, 22 Jan 2016, Doug Anderson wrote:
> >
> >> > Can you tell me how to configure a mainline kernel to work on the
> >> > Raspberry Pi? There is no arch/arm/configs/bcmrpi_defconfig.
> >>
> >> Not offhand. Again, perhaps someone else on this thread will have
> >> more. I did do a quick Google search and came up with:
> >>
> >> http://elinux.org/RPi_Upstream_Kernel_Compilation
> >>
> >> ...but the Raspberry Pi I have at home is running some home automation
> >> stuff so I don't want to give that a try. :-P
> >
> > I followed those instructions, and the result doesn't boot. No easy
> > way to figure out why -- nothing shows up on the HDMI screen but the
> > color splash.
>
> Interestingly enough Stefan Wahren reached out to me after my recent
> patch series indicating that my series didn't fix some other problem
> he was having on his Raspberry Pi. Presumably that means he might
> have some pointers?
>
> Stefan: do you have any pointer to instructions that Alan can use to
> get a booting Raspberry Pi kernel based on mainline Linux?

It sounds like that bootloader doesn't came up.

You will need to add / replace the following files in the FAT partition of an
raspbian:
kernel.img (U-Boot)
boot.scr.uimg
bcm2835-rpi*.dtb (from kernel)
zImage

>
> ...another interesting idea would be to try to see if you could just
> change the configuration of the Raspberry Pi kernel to switch which
> dwc2 driver it used. Presumably their driver was an addition on top
> of the driver in "drivers/usb/dwc2". In fact, doing a 'git log' on
> drivers/usb/dwc2 in the "rpi-4.4.y" kernel on github it looks pure
> (and Stefan is even the last commit author!)
>
> -Doug

dwc2 is broken in Linux 4.4 and newer

Please apply the following patch series:

http://marc.info/?l=linux-usb=145255851516121=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Alan Stern]

On Thu, 21 Jan 2016, Doug Anderson wrote:

> This doesn't sound familiar to me, but as far as I know all the
> official Raspberry Pi kernels use a pretty different dwc2 driver.  See
> the (non-mainline) code in drivers/usb/host/dwc_otg/ in the Raspberry
> Pi tree at .

Ah, thanks for that pointer.  I also found the page at raspberrypi.org 
which describes how to build and install a custom kernel.

> The Raspberry Pi driver and the mainline driver are pretty different
> (though they have the same heritage).  As far as I remember the
> Raspberry Pi driver has feature to enable FIQ for helping deal with
> some of the dwc2 issues.  That gives it a chunk of code that's totally
> rewritten...

Indeed, dwc_otg is quite different from dwc2.  I found what appears to
be a bug in the dwc_otg's _hub_info() routine.  (This is the subroutine
that gets the upstream hub address and port number for devices behind a
TT.)  It does:

*port_addr = urb->dev->tt->multi ? urb->dev->ttport : 1;

However, the USB spec says that the SPLIT packet's third byte is
supposed to contain the port for both single-TT and multi-TT hubs.  
And sure enough, the upstream hub for this non-working device is
single-TT.  Presumably that explains why the third byte in the SPLIT
packet was 0x01 rather than 0x04.

The corresponding line in the dwc2_host_hub_info() routine simply does:

*hub_port = urb->dev->ttport;

Unfortunately, even after I changed the dwc_otg routine the device 
still didn't work.  My bus analyzer isn't on hand today, so I'll have
to work on it more next week.

> It would be really interesting to see if the patch series I just
> posted helps you (it fixes lots of problems in the mainline driver
> with splits), though it might still not be enough on the Raspberry Pi
> since the CPU clock there is much slower than on my 1.8GHz A12-based
> system and thus maybe FIQ is a must have there...

Can you tell me how to configure a mainline kernel to work on the
Raspberry Pi?  There is no arch/arm/configs/bcmrpi_defconfig.

> Anyway, sorry if that's not terribly helpful.  :(  John may have more
> familiarity with the non-mainline driver (or know people who are more
> familiar with it).

Thanks,

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Alan,

On Fri, Jan 22, 2016 at 11:48 AM, Alan Stern  wrote:
> On Thu, 21 Jan 2016, Doug Anderson wrote:
>
>> This doesn't sound familiar to me, but as far as I know all the
>> official Raspberry Pi kernels use a pretty different dwc2 driver.  See
>> the (non-mainline) code in drivers/usb/host/dwc_otg/ in the Raspberry
>> Pi tree at .
>
> Ah, thanks for that pointer.  I also found the page at raspberrypi.org
> which describes how to build and install a custom kernel.
>
>> The Raspberry Pi driver and the mainline driver are pretty different
>> (though they have the same heritage).  As far as I remember the
>> Raspberry Pi driver has feature to enable FIQ for helping deal with
>> some of the dwc2 issues.  That gives it a chunk of code that's totally
>> rewritten...
>
> Indeed, dwc_otg is quite different from dwc2.  I found what appears to
> be a bug in the dwc_otg's _hub_info() routine.  (This is the subroutine
> that gets the upstream hub address and port number for devices behind a
> TT.)  It does:
>
> *port_addr = urb->dev->tt->multi ? urb->dev->ttport : 1;

Hrm.  Yeah, in the mainline driver it looks like we just have:

void dwc2_host_hub_info(struct dwc2_hsotg *hsotg, void *context, int *hub_addr,
int *hub_port)
{
struct urb *urb = context;

if (urb->dev->tt)
*hub_addr = urb->dev->tt->hub->devnum;
else
*hub_addr = 0;
*hub_port = urb->dev->ttport;
}


> However, the USB spec says that the SPLIT packet's third byte is
> supposed to contain the port for both single-TT and multi-TT hubs.
> And sure enough, the upstream hub for this non-working device is
> single-TT.  Presumably that explains why the third byte in the SPLIT
> packet was 0x01 rather than 0x04.
>
> The corresponding line in the dwc2_host_hub_info() routine simply does:
>
> *hub_port = urb->dev->ttport;
>
> Unfortunately, even after I changed the dwc_otg routine the device
> still didn't work.  My bus analyzer isn't on hand today, so I'll have
> to work on it more next week.
>
>> It would be really interesting to see if the patch series I just
>> posted helps you (it fixes lots of problems in the mainline driver
>> with splits), though it might still not be enough on the Raspberry Pi
>> since the CPU clock there is much slower than on my 1.8GHz A12-based
>> system and thus maybe FIQ is a must have there...
>
> Can you tell me how to configure a mainline kernel to work on the
> Raspberry Pi?  There is no arch/arm/configs/bcmrpi_defconfig.

Not offhand.  Again, perhaps someone else on this thread will have
more.  I did do a quick Google search and came up with:

http://elinux.org/RPi_Upstream_Kernel_Compilation

...but the Raspberry Pi I have at home is running some home automation
stuff so I don't want to give that a try.  :-P

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Thu, Jan 21, 2016 at 1:28 PM, Alan Stern  wrote:
> John, Doug, or anyone else:
>
> I've got a Raspberry Pi 2B and I'm trying to use it with a compound
> device.  The device has a High-Speed hub with a Full-Speed function
> permanently attached to port 4.
>
> The RPi detects the function but fails to initialize it.  My bus
> analyzer shows the reason why: A Start Split packet sent to the
> device's internal hub for delivery to the FS function contained these
> bytes:
>
> 78 44 01 c0
>
> 0x78 is the SPLIT packet ID.  0x44 is the hub's bus address, with a 0
> in the high-order bit to indicate a Start Split.  0x01 is supposed to
> be the port number in the hub (with a 0 in the high-order bit to
> indicate the target device is Full Speed).  The final 0xc0 is the CRC
> with a few extra uninteresting bits.
>
> The problem here is the third byte.  It is set to 0x01 even though the
> port number is 4.  As a result, the packet never gets delivered and the
> host controller is unable to communicate with the target function.
>
> (By contrast, when the same device was attached to a laptop PC instead
> of the RPi, the bus analyzer showed the SPLIT packet contained 78 06
> 04 60, as one would expect.)
>
> Now oddly enough, when I ran a similar test on the RPi using a
> Low-Speed target device, it worked perfectly.  In this case the device
> was attached to port 5 of the HS hub, and the third byte of the SPLIT
> packet was 0x85 (high-order bit is on to indicate Low Speed).
>
> Is this a bug in the Pi's host controller hardware?  Or a bug in the
> dwc_otg driver?  The kernel I tested was current Raspbian, 4.1.15-v7+.
>
> Is this a known problem?  Is there any reasonable way to fix it?

This doesn't sound familiar to me, but as far as I know all the
official Raspberry Pi kernels use a pretty different dwc2 driver.  See
the (non-mainline) code in drivers/usb/host/dwc_otg/ in the Raspberry
Pi tree at .

The Raspberry Pi driver and the mainline driver are pretty different
(though they have the same heritage).  As far as I remember the
Raspberry Pi driver has feature to enable FIQ for helping deal with
some of the dwc2 issues.  That gives it a chunk of code that's totally
rewritten...

It would be really interesting to see if the patch series I just
posted helps you (it fixes lots of problems in the mainline driver
with splits), though it might still not be enough on the Raspberry Pi
since the CPU clock there is much slower than on my 1.8GHz A12-based
system and thus maybe FIQ is a must have there...


Anyway, sorry if that's not terribly helpful.  :(  John may have more
familiarity with the non-mainline driver (or know people who are more
familiar with it).


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html