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

[Robert Baldyga <r.baldyga@samsung.com>]

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