**** BEGIN LOGGING AT Wed Apr 27 02:59:56 2022
**** BEGIN LOGGING AT Wed Apr 27 10:38:16 2022
Apr 27 16:07:14 <vvn> The mini usb port on the bbb is configured by default to gadget. Is it possible to configure it as usb host, via the devicetree I imagine?
Apr 27 16:11:48 <zmatt> vvn: it can't act as host since it can't output 5v
Apr 27 16:13:43 <zmatt> but other than that I *think* it's possible to force it into host mode via DT, assuming the driver can force the hardware to ignore the ID pin
Apr 27 16:15:21 <zmatt> I also vaguely remember the usb controller being very fussy about being able to actively control the 5v supply output, but iirc that has been fixed / worked around in the driver
Apr 27 16:32:13 <vvn> zmatt: I just confirmed that our custom daughter (which provides to power to the bbb in fact) also provides power for this port, used as host on our systems
Apr 27 16:32:27 <vvn> daughter board*
Apr 27 16:32:37 <vvn> the* power
Apr 27 16:32:53 * vvn sighs
Apr 27 16:33:22 <zmatt> be sure to also provide power to the bbb via that usb port since the controller will take to observe that 5v is present
Apr 27 16:33:41 <zmatt> *will want to observe
Apr 27 16:35:27 <zmatt> but anyway, try  &usb0 { dr_mode = "host"; };
Apr 27 16:41:43 <vvn> zmatt: this product is a few years old and I'm just writing a fresh device tree and kernel support for it, so I assume this works as expected on the hardware level. I can confirm some aspects of it if there's any risks
Apr 27 16:41:51 <zmatt> ok
Apr 27 16:41:57 <zmatt> I mean, if it works it works
Apr 27 16:42:11 <vvn> that's what I wanted to say ^^
Apr 27 16:42:17 <vvn> I'll try dr_mode right away
Apr 27 17:24:07 <vvn> zmatt: how do I know the usb mode from userspace?
Apr 27 17:26:19 <zmatt> if usb0 is in host mode it will show up in /sys/bus/usb/devices/
Apr 27 17:26:56 <zmatt> if it's in device mode it'll show up in /sys/class/udc as "musb-hdrc.0"
Apr 27 17:31:32 <zmatt> you can also check its state using: cat /sys/bus/platform/devices/musb-hdrc.0/mode
Apr 27 17:32:06 <vvn> currently b_idle
Apr 27 17:32:16 <zmatt> that's device mode
Apr 27 17:32:21 <zmatt> not host
Apr 27 17:32:53 <vvn> is the usbgadget thing a feature of the SoC itself or a feature of the board?
Apr 27 17:32:59 <zmatt> the SoC
Apr 27 17:33:01 <vvn> ok
Apr 27 17:33:18 <vvn> that's a capability of the usb IP in the SoC I imagine
Apr 27 17:33:21 <zmatt> it has two dual-role usb controllers
Apr 27 17:35:11 <zmatt> specifically Mentor Graphics USB 2.0 Multi-Point Dual-Role Controller, commonly abbreviated musbmhdrc or musb
Apr 27 17:36:25 <zmatt> /sys/bus/platform/devices/musb-hdrc.0/mode   shows the current state of the controller, with states for host mode having the a_ prefix and states for peripheral/gadget mode having the b_ prefix
Apr 27 17:37:15 <zmatt> e.g. b_idle for peripheral mode when not connected to a host, and a_wait_bcon for host mode with no peripheral connected to it
Apr 27 17:37:30 <vvn> ok I see
Apr 27 17:38:39 <vvn> does this SoC have ALSA audio drivers?
Apr 27 17:39:21 <zmatt> yes
Apr 27 17:40:59 <zmatt> the SoC has two mcasp controllers supporting i2s and other digital audio serial protocols, and its driver is called davinci-mcasp (CONFIG_SND_SOC_DAVINCI_MCASP)
Apr 27 17:43:28 <zmatt> (davinci is a marketing term used by TI for various, fairly unrelated, SoC families.  mcasp has nothing in particular to do with this, and the AM335x used on the BBB is not part of any davinci family, but I guess the driver was first introduced to support some davinci soc and the name has stuck)
Apr 27 17:49:02 <vvn> funny
Apr 27 17:49:40 <vvn> ok recompile the whole thing with the host usb mode and the soc / ext RTCs switched!
Apr 27 17:58:42 <vvn> zmatt: I used to get the same headache while working on the davinci da850 omap socl
Apr 27 17:58:44 <vvn> soc*
Apr 27 18:00:44 <zmatt> da850 ... that's the "freon" SoC I think?  (omap-L138 / AM18xx)
Apr 27 18:02:25 <zmatt> or maybe primus (omap-L137 / AM17xx)
Apr 27 18:06:32 <zmatt> nah, definitely freon
Apr 27 18:07:32 <vvn> those codenames ring a bell yeah
Apr 27 18:08:16 <zmatt> omap-L138, omap-L132, AM18xx, (tms320)c6748, (tms320)da850 ... all the same die afaik
Apr 27 18:10:43 <zmatt> TI is great at giving the same die (with slightly different efuse programming) several completely different part numbers while giving completely different dies very similar part numbers
Apr 27 18:12:22 <vvn> indeed
Apr 27 18:12:49 <vvn> I'm wondering if that is just clumsiness or if there's a strategy behind such naming mess
Apr 27 18:12:58 <zmatt> Marketing™
**** ENDING LOGGING AT Thu Apr 28 02:59:56 2022