Hi, On Fri, Aug 31, 2018 at 06:35:50AM +0000, Takashi Matsuzawa wrote: > Hello. > I just confirmed what I wanted to see. > I could do lsusb to list A-device (from b_host) and B-device (from a_host). > Suspending from either side kicked role change between A-device and B-device (in both direction). > > I needed to wait 20ms after B-device seeing MUSB_INTR_CONNECT and before calling musb_host_poke_root_hub(). > > I suppose seeing CONNECT inturrupt B-device can expect that A-device is reset, but it may take some time and B-device may need to wait. > On technial nodes, this is mentioned as something like this: > > "Reset Signaling. If the RESET bit in the POWER register (bit 3) is set while the controller is in Host mode, it will generate Reset signaling on the bus. If the HSENAB bit in the POWER register (bit 5) was set, it will also try to negotiate for high-speed operation. The software should keep the RESET bit set for at least 20 ms to ensure correct resetting of the target device." > > Note I still see errors like below after role change (b_host -> b_peripheral), perhaps some necessary cleanup is not there. > But anyway they role-switched in both direction.. Is commit [1] reverted or not in this experiment? [1] 0a9134bd733b usb: musb: disable otg protocol support > ==== > [ 1204.225843] usb 2-1: USB disconnect, device number 7 > [ 1204.274238] hub 2-0:1.0: USB hub found > [ 1204.282564] hub 2-0:1.0: 1 port detected > [ 1204.496301] musb-hdrc musb-hdrc.1: Babble > [ 1204.622799] musb_h_ep0_irq 1192: no URB for end 0 > [ 1208.474661] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? > [ 1210.063965] zero gadget: high-speed config #3: source/sink > [ 1212.566697] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? > [ 1212.573607] usb usb2-port1: attempt power cycle > [ 1216.974544] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? > [ 1221.066539] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? > [ 1221.073328] usb usb2-port1: unable to enumerate USB device > debian@beaglebone:~/wk-b$ Regards, -Bin. > === > > ________________________________________ > From: linux-usb-owner@xxxxxxxxxxxxxxx <linux-usb-owner@xxxxxxxxxxxxxxx> on behalf of Takashi Matsuzawa <tmatsuzawa@xxxxxxxx> > Sent: Friday, August 31, 2018 1:50 PM > To: Bin Liu > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: Re: musb_hdrc HNP? > > 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?)
