[PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case
balbi at ti.com
Tue Dec 8 06:20:45 PST 2015
Gregory CLEMENT <gregory.clement at free-electrons.com> writes:
>>>> if it is the case then it didn't fix the issue I had.
>>>> I activated the following debug line:
>>>> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012"
>>>> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012"
>>>> But I didn't get any interrupt while disconnecting the cable without any
>>>> device connected on it (whereas I got an interrupt when I connected it).
>>>> Note that I applied this patch instead of the "usb: musb: dsps: handle
>>>> the otg_state_a_wait_vrise_timeout case", is what you had in mind ?
>> yeah, that's what I had in mind. But your patch seems wrong :-)
>> I tried writing a more correct version here and found 2 issues:
>> a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's
>> b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note
>> that according to TRM, RESET_ISOLATION _must_ be set prior to a soft
>> reset and cleared afterwards. But right after setting RESET_ISOLATION,
>> if I try a read of CTRL, it'll hang forever.
> The datasheet seems not very coherent about it,
> on one side we have:
> "This bit should be set high prior to setting bit 0 and cleared after bit 0
> is cleared."
> and on the other side:
> "Both the soft_reset and soft_reset_isolation bits should be asserted
> The hang you saw could be explained by the following:
> "Setting only the soft_reset_isolation bit will cause all USB0 output
> signals to go to a known constant value via multiplexers.
> This will
> prevent future access to USB0." page 2567
good catch. Setting them together makes the hang go away.
I still have the other problem, which is legacy IRQ reporting mode not
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 818 bytes
Desc: not available
More information about the linux-arm-kernel