usb: dwc2: problems with IN requests completion in linux-next

usb: dwc2: problems with IN requests completion in linux-next

[Robert Baldyga]

Hi,

I have recently noticed problem with DWC2 driver in latest linux-next. I
use it in gadget only mode at Samsung platform (Odroid U3) but I believe
the bug can be reproduced at another platforms.

While running FFS example (tools/usb/ffs-aio-example/simple/) the
communication breaks after few seconds. It's because one of IN requests
enqueued in DWC2 driver do not complete. At USB analyzer I see that USB
device started to transmit data from this request, but it ended incomplete.

I bisected kernel tree, and I got following patches are reason of break.

941fcce usb: dwc2: Update the gadget driver to use common dwc2_hsotg
structure
117777b usb: dwc2: Move gadget probe function into platform code
bcc0607 usb: dwc2: convert to use dev_pm_ops API
510ffaa usb: dwc2: Initialize the USB core for peripheral mode
db8178c usb: dwc2: Update common interrupt handler to call gadget
interrupt handler
8d736d8 usb: dwc2: gadget: Do not fail probe if there isn't a clock node

Patch 941fcce breaks DWC2 driver at my platform and it starts to work
from 8d736d8 but it has described bug.

I will try to localize reason of this issue.

Best regards,
Robert Baldyga

RE: dwc2: problems with IN requests completion in linux-next

[Paul Zimmerman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1639 bytes --]

> From: Robert Baldyga [mailto:r.baldyga@samsung.com]
> Sent: Monday, December 22, 2014 6:13 AM
> 
> I have recently noticed problem with DWC2 driver in latest linux-next. I
> use it in gadget only mode at Samsung platform (Odroid U3) but I believe
> the bug can be reproduced at another platforms.
> 
> While running FFS example (tools/usb/ffs-aio-example/simple/) the
> communication breaks after few seconds. It's because one of IN requests
> enqueued in DWC2 driver do not complete. At USB analyzer I see that USB
> device started to transmit data from this request, but it ended incomplete.
> 
> I bisected kernel tree, and I got following patches are reason of break.
> 
> 941fcce usb: dwc2: Update the gadget driver to use common dwc2_hsotg
> structure
> 117777b usb: dwc2: Move gadget probe function into platform code
> bcc0607 usb: dwc2: convert to use dev_pm_ops API
> 510ffaa usb: dwc2: Initialize the USB core for peripheral mode
> db8178c usb: dwc2: Update common interrupt handler to call gadget
> interrupt handler
> 8d736d8 usb: dwc2: gadget: Do not fail probe if there isn't a clock node
> 
> Patch 941fcce breaks DWC2 driver at my platform and it starts to work
> from 8d736d8 but it has described bug.
> 
> I will try to localize reason of this issue.

Hi Robert,

I think the most likely suspect would be db8178c, since the rest appear
to be init-time things. It seems to revert cleanly, can you try
reverting just that patch and see if it helps?

-- 
Paul

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: dwc2: problems with IN requests completion in linux-next

[Robert Baldyga]

On 01/12/2015 10:35 PM, Paul Zimmerman wrote:
>> From: Robert Baldyga [mailto:r.baldyga@samsung.com]
>> Sent: Monday, December 22, 2014 6:13 AM
>>
>> I have recently noticed problem with DWC2 driver in latest linux-next. I
>> use it in gadget only mode at Samsung platform (Odroid U3) but I believe
>> the bug can be reproduced at another platforms.
>>
>> While running FFS example (tools/usb/ffs-aio-example/simple/) the
>> communication breaks after few seconds. It's because one of IN requests
>> enqueued in DWC2 driver do not complete. At USB analyzer I see that USB
>> device started to transmit data from this request, but it ended incomplete.
>>
>> I bisected kernel tree, and I got following patches are reason of break.
>>
>> 941fcce usb: dwc2: Update the gadget driver to use common dwc2_hsotg
>> structure
>> 117777b usb: dwc2: Move gadget probe function into platform code
>> bcc0607 usb: dwc2: convert to use dev_pm_ops API
>> 510ffaa usb: dwc2: Initialize the USB core for peripheral mode
>> db8178c usb: dwc2: Update common interrupt handler to call gadget
>> interrupt handler
>> 8d736d8 usb: dwc2: gadget: Do not fail probe if there isn't a clock node
>>
>> Patch 941fcce breaks DWC2 driver at my platform and it starts to work
>> from 8d736d8 but it has described bug.
>>
>> I will try to localize reason of this issue.
> 
> Hi Robert,
> 
> I think the most likely suspect would be db8178c, since the rest appear
> to be init-time things. It seems to revert cleanly, can you try
> reverting just that patch and see if it helps?
> 

Hi Paul,

Thanks. It looks like you're right, commit db8178c causes the break.

I have found out that if we don't call dwc2_is_controller_alive() in
interrupt handler everything works well. Conclusion is that reading from
GSNPSID causes the problem.

BTW it's strange that this register is used for testing if controller is
alive. Documentation says nothing about that as well as it does not say
that reading this register can affect hardware behaviour.

Avoiding to read this register in device mode seems to be the simplest
solution. But the question is why does it behave this way?

Best regards,
Robert Baldyga

Re: dwc2: problems with IN requests completion in linux-next

[Robert Baldyga]

On 01/13/2015 11:18 AM, Robert Baldyga wrote:
> On 01/12/2015 10:35 PM, Paul Zimmerman wrote:
>>> From: Robert Baldyga [mailto:r.baldyga@samsung.com]
>>> Sent: Monday, December 22, 2014 6:13 AM
>>>
>>> I have recently noticed problem with DWC2 driver in latest linux-next. I
>>> use it in gadget only mode at Samsung platform (Odroid U3) but I believe
>>> the bug can be reproduced at another platforms.
>>>
>>> While running FFS example (tools/usb/ffs-aio-example/simple/) the
>>> communication breaks after few seconds. It's because one of IN requests
>>> enqueued in DWC2 driver do not complete. At USB analyzer I see that USB
>>> device started to transmit data from this request, but it ended incomplete.
>>>
>>> I bisected kernel tree, and I got following patches are reason of break.
>>>
>>> 941fcce usb: dwc2: Update the gadget driver to use common dwc2_hsotg
>>> structure
>>> 117777b usb: dwc2: Move gadget probe function into platform code
>>> bcc0607 usb: dwc2: convert to use dev_pm_ops API
>>> 510ffaa usb: dwc2: Initialize the USB core for peripheral mode
>>> db8178c usb: dwc2: Update common interrupt handler to call gadget
>>> interrupt handler
>>> 8d736d8 usb: dwc2: gadget: Do not fail probe if there isn't a clock node
>>>
>>> Patch 941fcce breaks DWC2 driver at my platform and it starts to work
>>> from 8d736d8 but it has described bug.
>>>
>>> I will try to localize reason of this issue.
>>
>> Hi Robert,
>>
>> I think the most likely suspect would be db8178c, since the rest appear
>> to be init-time things. It seems to revert cleanly, can you try
>> reverting just that patch and see if it helps?
>>
> 
> Hi Paul,
> 
> Thanks. It looks like you're right, commit db8178c causes the break.
> 
> I have found out that if we don't call dwc2_is_controller_alive() in
> interrupt handler everything works well. Conclusion is that reading from
> GSNPSID causes the problem.
> 
> BTW it's strange that this register is used for testing if controller is
> alive. Documentation says nothing about that as well as it does not say
> that reading this register can affect hardware behaviour.
> 
> Avoiding to read this register in device mode seems to be the simplest
> solution. But the question is why does it behave this way?
> 

It looks like calling dwc2_is_controller_alive() under spinlock solves
the problem. I will prepare patch.

Best regards,
Robert Baldyga