Hello. >Is commit [1] reverted or not in this experiment?
In fact I noticed I am looking into TI kernel which is distributed in official debian image for pocketbeagle. So, the behavior may not be the same as mainline kernel code. I think I continue look into what I have now, and later check mainline status when I need to support (or try) other boards as well. ________________________________________ From: linux-usb-ow...@vger.kernel.org <linux-usb-ow...@vger.kernel.org> on behalf of Bin Liu <b-...@ti.com> Sent: Tuesday, September 4, 2018 11:00 PM To: Takashi Matsuzawa Cc: linux-usb@vger.kernel.org Subject: Re: musb_hdrc HNP? 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-ow...@vger.kernel.org <linux-usb-ow...@vger.kernel.org> on > behalf of Takashi Matsuzawa <tmatsuz...@xevo.com> > Sent: Friday, August 31, 2018 1:50 PM > To: Bin Liu > Cc: linux-usb@vger.kernel.org > 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-ow...@vger.kernel.org <linux-usb-ow...@vger.kernel.org> on > behalf of Bin Liu <b-...@ti.com> > Sent: Monday, August 27, 2018 10:33 PM > To: Takashi Matsuzawa > Cc: linux-usb@vger.kernel.org > 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-ow...@vger.kernel.org <linux-usb-ow...@vger.kernel.org> on > > behalf of Bin Liu <b-...@ti.com> > > Sent: Friday, August 24, 2018 10:43 PM > > To: Takashi Matsuzawa > > Cc: linux-usb@vger.kernel.org > > 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?)
