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@xxxxxxxxxxx]
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/