Thank you for your suggestion. Yes, I am aware that full-OTG support code is being wiped out of the latest mainline kernels. I am trying this for smartphone connectivity where OTG based role-switch is being used, which may not be of interest of everyone. I picked pocketbeagle since it has 2.0 OTG controller (without hub), which matched what I wanted to prototype. (If anyone is aware similar low-cost board with proven kernel version, I would interested in hearing about it.) I think I try debugging a bit further through ftrace, etc. and bus monitoring. One thing I am curious is the "Babble" errors. If they are caused by hardware (e.g. noise on power line), they may not be solved by software (what it can do is recovering/reset from failure). If it is likely to be caused by such, I may try adding ferite beeds, etc. to my prototype to see if anything change. ________________________________________ From: linux-usb-owner@xxxxxxxxxxxxxxx <linux-usb-owner@xxxxxxxxxxxxxxx> on behalf of Bin Liu <b-liu@xxxxxx> Sent: Friday, August 24, 2018 10:43 PM To: Takashi Matsuzawa Cc: linux-usb@xxxxxxxxxxxxxxx Subject: Re: musb_hdrc HNP? Hi, On Thu, Aug 23, 2018 at 10:06:50PM +0000, Takashi Matsuzawa wrote: > Hello. > > I am trying HNP (host -> peripheral role change) using two > PocketBeagles, but without success. Well, you are the very first one that I have ever heard who tries to use HNP on musb, at least on musb_dsps. > If there any idea on where I, where should I ask this, or how can I > debug / fix, I really appreciate. Being said, the controller itself does support HNP and other OTG protocols, but the musb driver might not, or have been broken for a very long time, since HNP probably never been tested on musb_dsps. If you use kernel v4.18+, you can try to revert commit 0a9134bd733b usb: musb: disable otg protocol support to see if HNP works. Regards, -Bin. > > 1) What I did > > Two PocketBeagles (running the default Debian image). > Both added 2nd USB ports (musb_hdrc.1). > DTBs were modified so that the 2nd musb_hdrcs have dr_mode = "otg". > musb_dsps glue port seems to be used. > Tech reference manual says the SoC's musb core supports HNP. > > One is A (by GNDing ID pin) and another B, connected with USB cable. > modprobe g_zero on both so that VBUS power is on, and A becomes a_host > and b becomes b_peripheral (as read through debugfs mode value). > > Then I did the following, expecting HNP happens and A bevcomes > a_peripheral and B bcomes b_host: > > i) Send b_hnp_enable request on A. > (This does set DEVCTL.HOSTREQ bits on B's musb_hdrc.1 and maybe doing > some additinoal things in musb driver on B.) > > ii) Set POWER.SUSPENDM bit on A's musb_hdrc.1 > (According to TRM, this should tell B's musb core to initiate HNP.) > > 2) Observation > > A: a_host -> a_wait_bcon -> a_idle -> a_wait_vrise -> a_host > B: b_peripheral -> b_idle -> b_peripheral > > And I see "musb_hdrc.1 Babble" messages on both A and B console. > > Looks like B disconnects once, but A = host/B = peripheral does not change. > > Looking into musb driver source, there are code for HNP maybe to help > musb core behavior. > (But I have not enabled driver debug message yet, which I may try next?)
