15:07 <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?

15:11 <zmatt> vvn: it can't act as host since it can't output 5v

15:13 <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

15:15 <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

15:32 <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

15:32 <vvn> daughter board*

15:32 <vvn> the* power

15:33 <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

15:33 <zmatt> *will want to observe

15:35 <zmatt> but anyway, try &usb0 { dr_mode = "host"; };

15:41 <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

15:41 <zmatt> ok

15:41 <zmatt> I mean, if it works it works

15:42 <vvn> that's what I wanted to say ^^

15:42 <vvn> I'll try dr_mode right away

16:24 <vvn> zmatt: how do I know the usb mode from userspace?

16:26 <zmatt> if usb0 is in host mode it will show up in /sys/bus/usb/devices/

16:26 <zmatt> if it's in device mode it'll show up in /sys/class/udc as "musb-hdrc.0"

16:31 <zmatt> you can also check its state using: cat /sys/bus/platform/devices/musb-hdrc.0/mode

16:32 <vvn> currently b_idle

16:32 <zmatt> that's device mode

16:32 <zmatt> not host

16:32 <vvn> is the usbgadget thing a feature of the SoC itself or a feature of the board?

16:32 <zmatt> the SoC

16:33 <vvn> ok

16:33 <vvn> that's a capability of the usb IP in the SoC I imagine

16:33 <zmatt> it has two dual-role usb controllers

16:35 <zmatt> specifically Mentor Graphics USB 2.0 Multi-Point Dual-Role Controller, commonly abbreviated musbmhdrc or musb

16:36 <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

16:37 <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

16:37 <vvn> ok I see

16:38 <vvn> does this SoC have ALSA audio drivers?

16:39 <zmatt> yes

16:40 <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)

16:43 <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)

16:49 <vvn> funny

16:49 <vvn> ok recompile the whole thing with the host usb mode and the soc / ext RTCs switched!

16:58 <vvn> zmatt: I used to get the same headache while working on the davinci da850 omap socl

16:58 <vvn> soc*

17:00 <zmatt> da850 ... that's the "freon" SoC I think? (omap-L138 / AM18xx)

17:02 <zmatt> or maybe primus (omap-L137 / AM17xx)

17:06 <zmatt> nah, definitely freon

17:07 <vvn> those codenames ring a bell yeah

17:08 <zmatt> omap-L138, omap-L132, AM18xx, (tms320)c6748, (tms320)da850 ... all the same die afaik

17:10 <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

17:12 <vvn> indeed

17:12 <vvn> I'm wondering if that is just clumsiness or if there's a strategy behind such naming mess

17:12 <zmatt> Marketing™