Re: [PATCH 14/16] usb: musb: dsps: add MUSB_DEVCTL_SESSION back afterremoval

[Sebastian Andrzej Siewior]

On 07/29/2013 07:26 PM, Bin Liu wrote:
> Sebastian,

Hi Bin,

> I did not say AM335xEVM is not able to run OTG mode. The problem is in
> OTG mode the SESSION bit will be cleared once the device is unplugged,
> then there is no way the SESSION bit will come back in the current
> mainline kernel.

Yes, you did.

> 
> The TI 3.2 kernel works around this OTG issue by toggling the SESSION
> bit in b_idle handling in otg_timer(). The workaround makes most users
> happy but it causes VBUS voltage pulsing. That is why I said I don't
> know an ideal solution without a ID pin interrupt support.

Now I understand more pieces of the puzzle. And the missing ID pin
support is Am335x-evm specific since other am335x board may wire up
that pin.
But you say there is no way that the phy or anything else could help to
avoid that pulsing.

> I think you looked at a wrong file, maybe a wrong branch. Please check
> [1], which defines
> 
> 2644          * mode[0:3] = USB0PORT's mode
> 2645          * mode[4:7] = USB1PORT's mode
> 2646          * AM335X beta EVM has USB0 in OTG mode and USB1 in host mode.
> 2647          */
> 2648         .mode           = (MUSB_HOST << 4) | MUSB_OTG,

Oh it is a long way. So looked into the wrong branch.

>> I agree that without that try_idle part things keep working but it
>> seems, that it is also called in the other tree.
>>
> 
> Then because AM335xEVM USB1 port does not call *try_idle() in this 3.2
> kernel, its SESSION bit is always set.
> 
> But I don't have a clear idea how to solve this in the mainline kernel
> since is_otg_enabled() has been cleaned.

So now I think this is a board problem. What about switching port 1
from OTG to HOST only and avoiding kicking the timer in
dsps_musb_try_idle() in such a case? It seems we only need to do this
in OTG mode.

> Regards,
> -Bin.

Sebastian
--
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/