[RFC] usb: dwc2: hcd: fix split schedule issue

[RFC] usb: dwc2: hcd: fix split schedule issue

[Yunzhi Li]

Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
packet between SSPLIT-begin and SSPLIT-end.

Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
---
 drivers/usb/dwc2/hcd.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index e79baf7..a32ed01 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1122,6 +1122,10 @@ static void dwc2_process_periodic_channels(struct dwc2_hsotg *hsotg)
 			break;
 		}
 
+		if (qh->channel->xact_pos == DWC2_HCSPLT_XACTPOS_BEGIN ||
+		    qh->channel->xact_pos == DWC2_HCSPLT_XACTPOS_MID)
+			break;
+
 		/*
 		 * In Slave mode, stay on the current transfer until there is
 		 * nothing more to do or the high-bandwidth request count is
-- 
2.0.0

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Yunzhi Li]

hi John ,

   As we talked yesterday, I tried to fix the split schedule sequence. This patch will
avoid scheduling SSPLIT-IN packet for another device between SSPLIT-OUT-begin and
SSPLIT-OUT-end, now the keyboard and Jebra audio speaker could work together well, but
I'm not sure if this is exactly the right way to schedule split transfers and if there
is any dide effect with this patch. Please help review this patch. Thanks.

> Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
> packet between SSPLIT-begin and SSPLIT-end.
>
> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
> ---
>   drivers/usb/dwc2/hcd.c | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index e79baf7..a32ed01 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1122,6 +1122,10 @@ static void dwc2_process_periodic_channels(struct dwc2_hsotg *hsotg)
>   			break;
>   		}
>   
> +		if (qh->channel->xact_pos == DWC2_HCSPLT_XACTPOS_BEGIN ||
> +		    qh->channel->xact_pos == DWC2_HCSPLT_XACTPOS_MID)
> +			break;
> +
>   		/*
>   		 * In Slave mode, stay on the current transfer until there is
>   		 * nothing more to do or the high-bandwidth request count is

> On 11/5/2015 2:13 AM, lyz@rock-chips.com wrote:
>> Hi John :
>>
>>       We found some problem when we tested usb audio speaker on rk3288 platform
>> which use dwc2 IP v3.10a as usb controller
>>
>> Steps to reproduce the problem:
>> 1. Plug in USB2.0 hub to rk3288 platform board.
>> 2. Plug in USB keyboard to the hub.
>> 3. Plug in USB audio speaker speaker(Jabra 410 or 510) to the hub
>> (These audio speakers support full speed data packet length 192 byte and it will
>> be split into 2 SSPLIT-OUT packets (188B + 4B) in
>> high speed bus other usb audio devices which has FS data packets length smaller
>> then 188B not has this issue )
>> 4. Play music via usb speaker then USB keyboard stop working
>>
>> I do some debug work and try to figure out the root cause of this issue :
>> Use the usb protocol analyzer to catch usb traffic in high speed bus
>> I see something weired that dwc2 send SSPLIT IN for dev 5 between two SSPLIT OUT
>> transaction for dev 6
>> then hub respond a NYET for dev 5 CSPLIT and keyboard not working any more.
>> It seems  some problem with split scheduling sequence and it let the hub
>> confused, but I'm not sure which rule
>> in usb20 spec chapters 11 is broken and how to fix it.
>> DWC2 traffic
>>
>> I alsocatch the usb traffic between an EHCI controller in pc and the hub
>> connected with audio speaker and keyboard
>> both keyboard and audio speaker work well with EHCI. EHCI schedules the SSPLIT
>> IN for keyboard in the next microframe
>> after OUT SSPLIT OUT for audio data packets and the hub can respond NAK .
>>
>>
>> EHCI traffic
>>
>> I will keep on debugging for this issue and try to fix the scheduling sequence ,
>> does anyone have any  ideas could be help with this issue ?
>>
>> --------------------------------------------------------------------------------
>> lyz@rock-chips.com
>>
> Thanks for this report. I'll try to reproduce and forward it
> along to some of our experts.
>
> Regards,
> John
>

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Doug Anderson]

John,

On Fri, Nov 6, 2015 at 2:04 AM, Yunzhi Li <lyz@rock-chips.com> wrote:
> hi John ,
>
>   As we talked yesterday, I tried to fix the split schedule sequence. This
> patch will
> avoid scheduling SSPLIT-IN packet for another device between
> SSPLIT-OUT-begin and
> SSPLIT-OUT-end, now the keyboard and Jebra audio speaker could work together
> well, but
> I'm not sure if this is exactly the right way to schedule split transfers
> and if there
> is any dide effect with this patch. Please help review this patch. Thanks.
>
>> Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
>> packet between SSPLIT-begin and SSPLIT-end.
>>
>> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
>> ---
>>   drivers/usb/dwc2/hcd.c | 4 ++++
>>   1 file changed, 4 insertions(+)

Did you have any thoughts on this patch?  Although this patch didn't
fix the problems I was seeing with the Microsoft Wireless Keyboard
(see the patch I sent out earlier which does seem to fix it), I can
confirm that in a different setup (HUB goes to USB audio + mouse) that
this patch does fix some problems.

That being said, it feels to me like a band-aid rather than an actual
fix (I'm talking out of my rear end, though, since my USB experience
is lacking at best).  It feels like perhaps we're just not keeping
track the xact_pos correctly, but of course I don't know that for
sure...

Anyway, just fishing...  ;)

-Doug

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[John Youn]

On 11/11/2015 4:22 PM, Doug Anderson wrote:
> John,
> 
> On Fri, Nov 6, 2015 at 2:04 AM, Yunzhi Li <lyz@rock-chips.com> wrote:
>> hi John ,
>>
>>   As we talked yesterday, I tried to fix the split schedule sequence. This
>> patch will
>> avoid scheduling SSPLIT-IN packet for another device between
>> SSPLIT-OUT-begin and
>> SSPLIT-OUT-end, now the keyboard and Jebra audio speaker could work together
>> well, but
>> I'm not sure if this is exactly the right way to schedule split transfers
>> and if there
>> is any dide effect with this patch. Please help review this patch. Thanks.
>>
>>> Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
>>> packet between SSPLIT-begin and SSPLIT-end.
>>>
>>> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
>>> ---
>>>   drivers/usb/dwc2/hcd.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
> 
> Did you have any thoughts on this patch?  Although this patch didn't
> fix the problems I was seeing with the Microsoft Wireless Keyboard
> (see the patch I sent out earlier which does seem to fix it), I can
> confirm that in a different setup (HUB goes to USB audio + mouse) that
> this patch does fix some problems.
> 
> That being said, it feels to me like a band-aid rather than an actual
> fix (I'm talking out of my rear end, though, since my USB experience
> is lacking at best).  It feels like perhaps we're just not keeping
> track the xact_pos correctly, but of course I don't know that for
> sure...
> 
> Anyway, just fishing...  ;)
> 
> -Doug
> 

Hi Doug,

I also feel it is not quite right as the SSPLIT should be able to
happen during the SSPLIT of another device. I tried to reproduce
and see the same scheduling but don't see any hang due to it.

Yunzhi, any details on what kind of hub and keyboard you are
using? I have the same Jabra 410 speaker.

Regards,
John

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Doug Anderson]

John,

On Wed, Nov 11, 2015 at 8:29 PM, John Youn <John.Youn@synopsys.com> wrote:
> I also feel it is not quite right as the SSPLIT should be able to
> happen during the SSPLIT of another device. I tried to reproduce
> and see the same scheduling but don't see any hang due to it.
>
> Yunzhi, any details on what kind of hub and keyboard you are
> using? I have the same Jabra 410 speaker.

I saw it with a standard Logitech mouse.  It wasn't a hang, but the
mouse effectively became non-functional (behaved like it hung) when
you started playing audio.  Once the audio stream stopped, the mouse
would work again.  I was using the same Jabra 410 as well.

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 6, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
        |__ Port 3: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 3: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 3: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 3: Dev 5, If 3, Class=Human Interface Device, Driver=, 12M

Bus 002 Device 005: ID 0b0e:0412 GN Netcom
Bus 002 Device 006: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
Bus 002 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

We've also had some discussion of this patch in our bug tracker at
<https://chromium-review.googlesource.com/#/c/312160/>.

I'll keep digging tomorrow, too.

-Doug

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[John Youn]

On 11/11/2015 8:46 PM, Doug Anderson wrote:
> John,
> 
> On Wed, Nov 11, 2015 at 8:29 PM, John Youn <John.Youn@synopsys.com> wrote:
>> I also feel it is not quite right as the SSPLIT should be able to
>> happen during the SSPLIT of another device. I tried to reproduce
>> and see the same scheduling but don't see any hang due to it.
>>
>> Yunzhi, any details on what kind of hub and keyboard you are
>> using? I have the same Jabra 410 speaker.
> 
> I saw it with a standard Logitech mouse.  It wasn't a hang, but the
> mouse effectively became non-functional (behaved like it hung) when
> you started playing audio.  Once the audio stream stopped, the mouse
> would work again.  I was using the same Jabra 410 as well.
> 
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
>     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>         |__ Port 2: Dev 6, If 0, Class=Human Interface Device,
> Driver=usbhid, 1.5M
>         |__ Port 3: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M
>         |__ Port 3: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M
>         |__ Port 3: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 12M
>         |__ Port 3: Dev 5, If 3, Class=Human Interface Device, Driver=, 12M
> 
> Bus 002 Device 005: ID 0b0e:0412 GN Netcom
> Bus 002 Device 006: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
> Bus 002 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> We've also had some discussion of this patch in our bug tracker at
> <https://chromium-review.googlesource.com/#/c/312160/>.
> 
> I'll keep digging tomorrow, too.
> 
> -Doug
> 


It seems to be an issue with single TT hubs. I've tried several
multi-TT hubs with no issues.

With a single TT hub I do see a problem though not the exact one
described. I see corrupted and dropped packets on the FS side of
the hub. In a microframe with SSPLIT.begin, taking up the max
bandwidth for the microframe, when another SSPLIT for a different
device is issued, the data gets corrupted on the other side of
the TT. Probably due to exceeding the bandwidth in the microframe
since a single TT hub's ports all share the bandwidth.

With this fix, the next SSPLIT goes out in the same microframe as
the SSPLIT.end and the data goes through fine.

However I don't think this will work as a general fix. Since it
is just skipping things without rescheduling. For example SSPLIT
now happens a microframe later but the CSPLIT is not adjusted so
it comes a microframe too early.

I think the correct fix is to create a proper schedule based on
all the active endpoints to make sure we don't go over the
bandwidth for a single TT hub. Or to make the adjustments earlier
like in dwc2_sched_periodic_split().

Regards,
John

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Doug Anderson]

John,

On Thu, Nov 12, 2015 at 9:05 PM, John Youn <John.Youn@synopsys.com> wrote:
> It seems to be an issue with single TT hubs. I've tried several
> multi-TT hubs with no issues.

Agreed.


> With a single TT hub I do see a problem though not the exact one
> described. I see corrupted and dropped packets on the FS side of
> the hub. In a microframe with SSPLIT.begin, taking up the max
> bandwidth for the microframe, when another SSPLIT for a different
> device is issued, the data gets corrupted on the other side of
> the TT. Probably due to exceeding the bandwidth in the microframe
> since a single TT hub's ports all share the bandwidth.

Seems like different single TT hubs react differently.  I got one
where the mouse kept working but the audio was just static...


> With this fix, the next SSPLIT goes out in the same microframe as
> the SSPLIT.end and the data goes through fine.
>
> However I don't think this will work as a general fix. Since it
> is just skipping things without rescheduling. For example SSPLIT
> now happens a microframe later but the CSPLIT is not adjusted so
> it comes a microframe too early.
>
> I think the correct fix is to create a proper schedule based on
> all the active endpoints to make sure we don't go over the
> bandwidth for a single TT hub. Or to make the adjustments earlier
> like in dwc2_sched_periodic_split().

I've started working on this and just before I needed to leave my desk
I got something that seemed to work.  I'll keep at it on Monday.

At the moment I'm making the assumption that we never got a multi_tt
hub attached to us.  My code will always just schedule one split per
microframe.  Would that be OK for now until we make the scheduler
better?

To handle things smarter, I think I need to research how to deal with
hubs attached to hubs attached to hubs.  For instance:

dwc2
-> multi_tt hub
    -> single_tt hub
        -> device 1
        -> device 2
    -> single_tt hub
        -> device 3
        -> device 4
vs.

dwc2
-> single_tt hub
    -> multi_tt hub
        -> device 1
        -> device 2
    -> multi_tt hub
        -> device 3
        -> device 4

In the first case I presume I could schedule device 1 and device 3 at
the same time, but not device 2 and device 4.  In the 2nd case I
presume I could schedule all 4 devices independently.  ...but I
haven't dug through the spec to confirm that, yet.

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Alan Stern]

On Fri, 13 Nov 2015, Doug Anderson wrote:

> To handle things smarter, I think I need to research how to deal with
> hubs attached to hubs attached to hubs.  For instance:
> 
> dwc2
> -> multi_tt hub
>     -> single_tt hub
>         -> device 1
>         -> device 2
>     -> single_tt hub
>         -> device 3
>         -> device 4
> vs.
> 
> dwc2
> -> single_tt hub
>     -> multi_tt hub
>         -> device 1
>         -> device 2
>     -> multi_tt hub
>         -> device 3
>         -> device 4
> 
> In the first case I presume I could schedule device 1 and device 3 at
> the same time, but not device 2 and device 4.

Devices 2 and 4 are related in exactly the same way as 1 and 3.  You 
can schedule them independently.  But you can't schedule 1 
independently of 2 or 3 independently of 4.

>  In the 2nd case I
> presume I could schedule all 4 devices independently.  ...but I
> haven't dug through the spec to confirm that, yet.

That's right.  The basic rule is very simple: Independent scheduling 
requires that the devices in question be attached through different 
TTs, where a multi-TT hub has a separate TT for each port.

On the other hand, it's important to keep in mind that even though you
can consider the devices independently as far as scheduling on the
FS/LS buses is concerned, you also have to consider the bandwidth
requirements of the SSPLIT and CSPLIT packets on the HS bus.  Since
there's only one HS bus, those things can't be independent.

How do you decide which microframes to dedicate to a particular
endpoint?  The scheduler in ehci-hcd isn't especially sophisticated
about this, and it can easily work itself into a corner by allocating
things in such a way that there's no microframe to put a new request
even though the total amount of available bandwidth is more than
sufficient.  I have put a lot of thought into ways of improving this,
but there doesn't seem to be any good approach that doesn't require
rebalancing (i.e., changing the microframes allocated to certain
endpoints) from time to time.  Rebalancing is very awkward because it
means stopping some ongoing transfers temporarily, removing the entries
from their old scheduled positions, putting them into the new
positions, and then restarting the transfers.  It can't be done
transparently or quickly.

Alan Stern

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Julius Werner]

> 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.

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Yunzhi Li]

Hi John

在 2015/11/12 12:29, John Youn 写道:
> On 11/11/2015 4:22 PM, Doug Anderson wrote:
>> John,
>>
>> On Fri, Nov 6, 2015 at 2:04 AM, Yunzhi Li <lyz@rock-chips.com> wrote:
>>> hi John ,
>>>
>>>    As we talked yesterday, I tried to fix the split schedule sequence. This
>>> patch will
>>> avoid scheduling SSPLIT-IN packet for another device between
>>> SSPLIT-OUT-begin and
>>> SSPLIT-OUT-end, now the keyboard and Jebra audio speaker could work together
>>> well, but
>>> I'm not sure if this is exactly the right way to schedule split transfers
>>> and if there
>>> is any dide effect with this patch. Please help review this patch. Thanks.
>>>
>>>> Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
>>>> packet between SSPLIT-begin and SSPLIT-end.
>>>>
>>>> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
>>>> ---
>>>>    drivers/usb/dwc2/hcd.c | 4 ++++
>>>>    1 file changed, 4 insertions(+)
>> Did you have any thoughts on this patch?  Although this patch didn't
>> fix the problems I was seeing with the Microsoft Wireless Keyboard
>> (see the patch I sent out earlier which does seem to fix it), I can
>> confirm that in a different setup (HUB goes to USB audio + mouse) that
>> this patch does fix some problems.
>>
>> That being said, it feels to me like a band-aid rather than an actual
>> fix (I'm talking out of my rear end, though, since my USB experience
>> is lacking at best).  It feels like perhaps we're just not keeping
>> track the xact_pos correctly, but of course I don't know that for
>> sure...
>>
>> Anyway, just fishing...  ;)
>>
>> -Doug
>>
> Hi Doug,
>
> I also feel it is not quite right as the SSPLIT should be able to
> happen during the SSPLIT of another device. I tried to reproduce
> and see the same scheduling but don't see any hang due to it.
>
> Yunzhi, any details on what kind of hub and keyboard you are
> using? I have the same Jabra 410 speaker.
>
>
You could use a single tt hub and any stander keyboard or mouse to 
reproduce this issue
1. connect hub keyboard and audio speaker
2. play any sound
3. then the keyboard stop working

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Doug Anderson]

John,

On Wed, Nov 11, 2015 at 8:29 PM, John Youn <John.Youn@synopsys.com> wrote:
> On 11/11/2015 4:22 PM, Doug Anderson wrote:
>> John,
>>
>> On Fri, Nov 6, 2015 at 2:04 AM, Yunzhi Li <lyz@rock-chips.com> wrote:
>>> hi John ,
>>>
>>>   As we talked yesterday, I tried to fix the split schedule sequence. This
>>> patch will
>>> avoid scheduling SSPLIT-IN packet for another device between
>>> SSPLIT-OUT-begin and
>>> SSPLIT-OUT-end, now the keyboard and Jebra audio speaker could work together
>>> well, but
>>> I'm not sure if this is exactly the right way to schedule split transfers
>>> and if there
>>> is any dide effect with this patch. Please help review this patch. Thanks.
>>>
>>>> Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
>>>> packet between SSPLIT-begin and SSPLIT-end.
>>>>
>>>> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
>>>> ---
>>>>   drivers/usb/dwc2/hcd.c | 4 ++++
>>>>   1 file changed, 4 insertions(+)
>>
>> Did you have any thoughts on this patch?  Although this patch didn't
>> fix the problems I was seeing with the Microsoft Wireless Keyboard
>> (see the patch I sent out earlier which does seem to fix it), I can
>> confirm that in a different setup (HUB goes to USB audio + mouse) that
>> this patch does fix some problems.
>>
>> That being said, it feels to me like a band-aid rather than an actual
>> fix (I'm talking out of my rear end, though, since my USB experience
>> is lacking at best).  It feels like perhaps we're just not keeping
>> track the xact_pos correctly, but of course I don't know that for
>> sure...
>>
>> Anyway, just fishing...  ;)
>>
>> -Doug
>>
>
> Hi Doug,
>
> I also feel it is not quite right as the SSPLIT should be able to
> happen during the SSPLIT of another device. I tried to reproduce
> and see the same scheduling but don't see any hang due to it.
>
> Yunzhi, any details on what kind of hub and keyboard you are
> using? I have the same Jabra 410 speaker.

Just to tie things together for anyone following along, my current
thoughts on how to fix this are something like
<https://patchwork.kernel.org/patch/7631551/>.

-Doug

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Doug Anderson]

lyz@,

On Fri, Nov 6, 2015 at 1:36 AM, Yunzhi Li <lyz@rock-chips.com> wrote:
> Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
> packet between SSPLIT-begin and SSPLIT-end.
>
> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
> ---
>  drivers/usb/dwc2/hcd.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index e79baf7..a32ed01 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1122,6 +1122,10 @@ static void dwc2_process_periodic_channels(struct dwc2_hsotg *hsotg)
>                         break;
>                 }
>
> +               if (qh->channel->xact_pos == DWC2_HCSPLT_XACTPOS_BEGIN ||
> +                   qh->channel->xact_pos == DWC2_HCSPLT_XACTPOS_MID)
> +                       break;
> +
>                 /*
>                  * In Slave mode, stay on the current transfer until there is
>                  * nothing more to do or the high-bandwidth request count is

Just a quite note to say that this doesn't seem to resolve the weird
errors I'm seeing with the "Microsoft Wireless Keyboard 2000" that I
have.  I see split transaction errors in a USB analyzer with just that
hooked up behind a hub (don't even need any other USB devices).

...it is possible that there are two unrelated problems here, but it's
also possible that there's some bigger root cause that will fix both
of our problems.  I've been poking at things a bit too, but so far no
luck...

-Doug

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Yunzhi Li]

hi Doug

在 2015/11/7 7:56, Doug Anderson 写道:
> lyz@,
>
> On Fri, Nov 6, 2015 at 1:36 AM, Yunzhi Li <lyz@rock-chips.com> wrote:
>> Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
>> packet between SSPLIT-begin and SSPLIT-end.
>>
>> Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
>> ---
>>   drivers/usb/dwc2/hcd.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>> index e79baf7..a32ed01 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -1122,6 +1122,10 @@ static void dwc2_process_periodic_channels(struct dwc2_hsotg *hsotg)
>>                          break;
>>                  }
>>
>> +               if (qh->channel->xact_pos == DWC2_HCSPLT_XACTPOS_BEGIN ||
>> +                   qh->channel->xact_pos == DWC2_HCSPLT_XACTPOS_MID)
>> +                       break;
>> +
>>                  /*
>>                   * In Slave mode, stay on the current transfer until there is
>>                   * nothing more to do or the high-bandwidth request count is
> Just a quite note to say that this doesn't seem to resolve the weird
> errors I'm seeing with the "Microsoft Wireless Keyboard 2000" that I
> have.  I see split transaction errors in a USB analyzer with just that
> hooked up behind a hub (don't even need any other USB devices).
>
> ...it is possible that there are two unrelated problems here, but it's
> also possible that there's some bigger root cause that will fix both
> of our problems.  I've been poking at things a bit too, but so far no
> luck...
>
> -Doug
>
It seems that we are debugging two different issues, your new patch which rewrite
the microframe scheduler doesn't resolve my problem. My patch fix chrome-os issue
#46547 not related to the particular Microsoft keyboard any keyboard could be used
to reproduce the issue.

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Doug Anderson]

Hi,

On Mon, Nov 9, 2015 at 1:57 AM, Yunzhi Li <lyz@rock-chips.com> wrote:
> It seems that we are debugging two different issues, your new patch which
> rewrite
> the microframe scheduler doesn't resolve my problem. My patch fix chrome-os
> issue
> #46547 not related to the particular Microsoft keyboard any keyboard could
> be used
> to reproduce the issue.

As far as I can tell my microframe rewrite patch is totally a no-op
(it doesn't do anything useful at all).  I'll try to write some test
code showing why I think the old function is broken and why the new
one works, but my new version doesn't fix any known issues.

Whatever the problem is with the Microsoft keyboard is still unknown.
I'll try to dig into it more today.  I think I'm starting to
understand enough about how USB works that I might be able to make
sense of the analyzer trace now too.  I can also post a screenshot of
that...

-Doug