Hello. FYI. I made a progress on this, but no solution yet. >The smartphone does use HNP, it is not iPhone Carplay, correct? At this point, I am trying to see original HNP behavior between two pocketbeagles. (After seeing it works, I plan to replace B-device with a phone, and so customization on A-device stack.) >1. MUSB uses one register bit to report babble and reset event, so driver bug could report bus reset as babble if it doesn't trace the controller role correctly; As mentioned below, it may be related to how driver on B-device responds to RESET/BABBLE interrupts (or its sideeffets). 1) I could see CONFIG_USB_OTG was not set on "Debian 9.4 2018-06-17" image so I turned it on. This improved the situation a bit, like A-device side b_hnp_enable flag (which is set when B-device b_hnp_enable is set.) 2) Now I can see A-device and B-device turns to expected modes. A-device: a_host -> a_peripheral After suspending port, sees DISCONNECT and RESET events. B-device: b_peripheral -> b_host Sees SUSPEND, CONNECT events. 3) But I do not see B-device enumerate A-device at this point, and instead on B-device (now b_host) RESET(or BUBBLE) events are seen. Then after that, immediately, SUSPEND is seen on A-device, looks like now A-device is resuming as a_host and B-device back to b_peripheral. 4) I expect at 2) B-device should enumerate A-device and both stays in new mode (and I can, say do lsusb on B-device and see A-device listed), but it does not happen. Ignoring RESET(BUBBLE) events on B-device (b_host) at 3) did not improve the situgation. (Now I see SUSPEND on B-device instead of DISCONNECT.) It may be that driver behavior after 2) (to be initiated as a_peripheral and b_host and restarting) having some problem. ________________________________________ From: linux-usb-owner@xxxxxxxxxxxxxxx <linux-usb-owner@xxxxxxxxxxxxxxx> on behalf of Bin Liu <b-liu@xxxxxx> Sent: Monday, August 27, 2018 10:33 PM To: Takashi Matsuzawa Cc: linux-usb@xxxxxxxxxxxxxxx Subject: Re: musb_hdrc HNP? Hi, On Mon, Aug 27, 2018 at 12:57:55AM +0000, Takashi Matsuzawa wrote: > Thank you for your suggestion. > Yes, I am aware that full-OTG support code is being wiped out of the > latest mainline kernels. Okay. Let me know if reverting that patch can magically make HNP works. > I am trying this for smartphone connectivity where OTG based > role-switch is being used, which may not be of interest of everyone. The smartphone does use HNP, it is not iPhone Carplay, correct? > I picked pocketbeagle since it has 2.0 OTG controller (without hub), > which matched what I wanted to prototype. Pocketbeagle should be good, it uses TI AM335x which is the device I have. > (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). I highly doubt the babble error is caused by hardware. There are mainly two types of sw bugs which cause babble. 1. MUSB uses one register bit to report babble and reset event, so driver bug could report bus reset as babble if it doesn't trace the controller role correctly; 2. true babble events due to controller misconfiguration at runtime. > If it is likely to be caused by such, I may try adding ferite beeds, > etc. to my prototype to see if anything change. First you can try to liminate some variables, for example, disable CPPI DMA, disable usb runtime PM. Good luck. Regards, -Bin. > ________________________________________ > 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?)
