Re: Fwd: composite device fails to reset "suspended" flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 12/21/2018 11:17 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes:
>>>> You're using a really old kernel. Please try with v4.19.11 or v4.20-rc7
>>>>
>>>
>>> I have to use an altera patched kernel linux-socfpga to boot my board,
>>> and it always lags behind mainline kernel.  If I really had to, I can
>>> probably backport an individual driver (I already backported dwc2 from
>>> 4.17).  Anyways, in principal is this a bug in dwc2 or libcomposite?
>>> That is, is libcomposite correct in assuming the dwc2 should call the
>>> gadget "resume" callback when the plug is reinserted?  Or should
>>> libcomposite getting just the gadget "reset" be enough for it to know
>>> it may need to update the suspended flag?
>>>
>>> I played around with my hardware a bit more, and when I suspend/resume
>>> the gadget from the host over the usb bus (rather than pulling out
>>> then reinserting the physical cable) it works fine.  That is, the dwc2
>>> hardware generates a suspend interrupt then later a resume/wakeup
>>> interrupt which results in the gadget "resume" callback getting
>>> called.
>>>
>>> However, when pulling/reinserting the cable only the suspend interrupt
>>> is generated.  When the cable is reinserted, there is no resume/wakeup
>>> interrupt (only some usb reset interrupts) and thus the gadget
>>> "resume" is never called.
>>
>> Maybe the problem is not lack of a resume callback but lack of a
>> disconnect callback.
>>
>> When an unplugged cable is plugged in again, it is not a resume event
>> but rather a connect event -- and the gadget API does not have
>> callbacks for connect events.
>>
>> When a cable is unplugged it initially appears to be a suspend, but
>> within a few milliseconds the UDC driver should realize what has
>> actually happened.  The disconnect callback should follow close on the
>> heels of the suspend callback.
> 
> after a quick glance at dwc2 driver, it seems like Disconnect Interrupt
> isn't enabled. There's no handling for it. Minas, any comments?
> 

According data book Disconnect Interrupt asserted only in Host mode.
Programming guide says for device initialization unmask follow device 
specific interrupts: USB reset, Enum Done, Early suspend, Suspend and SOF.
And on device disconnect asserted interrupts:
- In OTG_MODE=0,1,3: GOTGINT.SesEndDet;
- In OTG_MODE=2,4: GINTSTS.USBRst
Looks like on Frank's platform/PHY SesEndDet not asserted, otherwise 
will be called dwc2_hsotg_disconnect()->call_gadget(hsotg, disconnect).
But above function call chain performing on USB reset interrupt also.
Any case on cable pull should be called gadget with "disconnect" state 
not "resume".

Frank, can you please review dmesg log to see which exactly interrupts 
sequence asserted on cable disconnect.

Thanks,
Minas




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux