Nikolaus,
On 09/09/18 11:39, H. Nikolaus Schaller wrote:
Hi Roger,
Am 31.08.2018 um 09:32 schrieb Roger Quadros rogerq@ti.com:
Nikolaus,
On 30/08/18 20:17, H. Nikolaus Schaller wrote:
Hi Roger,
Am 30.08.2018 um 16:15 schrieb Roger Quadros rogerq@ti.com:
Hi Nikolaus,
Sorry for the delay. My reply below.
no problem - we have enough other issues to work on (e.g. TILER, AESS) :)
On 05/07/18 11:22, Tony Lindgren wrote:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [180704 18:06]:
Hi Tony, I have seen two small issues:
a) USB client mode works fine, except that on first plug in of the cable I see NOHZ warnings (which seem to be harmless):
> dhcpcd[2317]: version 6.0.5 starting > dhcpcd[2317]: wlan0: waiting for carrier > dhcpcd[2317]: usb0: waiting for carrier > dhcpcd[2317]: wlan0: carrier acquired > dhcpcd[2317]: wlan0: carrier lost > dhcpcd[2317]: wlan0: waiting for carrier > [ 23.626353] wlcore: down > [ 46.919138] g_ether gadget: high-speed config #1: CDC Ethernet (ECM) > [ 47.285640] bq24296: VBUS became available > [ 47.290052] bq24296_update_input_current_limit(6) > [ 48.531529] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready > [ 48.593338] NOHZ: local_softirq_pending 08 > [ 48.826821] NOHZ: local_softirq_pending 08 > [ 48.987261] NOHZ: local_softirq_pending 08 > [ 49.288690] NOHZ: local_softirq_pending 08 > [ 49.381113] NOHZ: local_softirq_pending 08 > [ 49.610246] NOHZ: local_softirq_pending 08 > [ 49.774833] NOHZ: local_softirq_pending 08 > [ 49.888948] NOHZ: local_softirq_pending 08 > [ 50.143018] NOHZ: local_softirq_pending 08 > [ 50.168652] NOHZ: local_softirq_pending 08 > dhcpcd[2317]: timed out > dhcpcd[2317]: allowing 8 seconds for IPv4LL timeout > dhcpcd[2317]: usb0: carrier acquired > dhcpcd[2317]: usb0: soliciting an IPv6 router > dhcpcd[2317]: usb0: using IPv4LL address 169.254.83.144 > dhcpcd[2317]: usb0: adding host route to 169.254.83.144 via 127.0.0.1 > dhcpcd[2317]: usb0: adding route to 169.254.0.0/16 > dhcpcd[2317]: forked to background, child pid 2812 > [FAIL] startpar: service(s) returned failure: isc-dhcp-server ... failed! > > Debian GNU/Linux 8 letux console > > letux login: root > Password:
It is the same on omap5uevm:
> root@letux:~# [ 2858.377258] g_ether gadget: high-speed config #1: CDC Ethernet (ECM) > [ 2859.205770] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready > [ 2859.279922] NOHZ: local_softirq_pending 08 > [ 2859.481076] NOHZ: local_softirq_pending 08 > [ 2859.800392] NOHZ: local_softirq_pending 08 > [ 2859.913331] NOHZ: local_softirq_pending 08 > [ 2860.052946] NOHZ: local_softirq_pending 08 > [ 2860.232251] NOHZ: local_softirq_pending 08 > [ 2860.280545] NOHZ: local_softirq_pending 08 > [ 2860.445238] NOHZ: local_softirq_pending 08 > [ 2860.541821] NOHZ: local_softirq_pending 08 > [ 2860.808122] NOHZ: local_softirq_pending 08 > > root@letux:~# [ 2872.169307] g_ether gadget: high-speed config #1: CDC Ethernet (ECM) >
b) OTG mode detects cable plugin (extcon) and turns on power but dwc3 does not try to find the connected device
> root@letux:~# [ 692.970418] bq24296: VBUS became unavailable > [ 850.289966] bq24296_otg_is_enabled(1) > [ 850.294997] bq24296_otg_enable(1) > [ 858.377691] bq24296_otg_disable(1) > [ 864.544944] bq24296_otg_is_enabled(1) > [ 864.549017] bq24296_otg_enable(1) > [ 866.834895] bq24296_otg_disable(1) >
Same on omap5uevm (just power can be measured, not the bq24296 printk of course).
otg mode was never tested on omap5uevm.
omap5.dtsi sets dwc3 controller's dr_mode to "peripheral". And it remains like that. So we need to set it to "otg" in the boards that need dual-role support.
Ah, ok. That explains a lot!
I had only verified that we have enabled OTG support in the CONFIG.
The other missing piece for omap5uevm is how to enable the VBUS regulator that is on the PMIC (palmas). Unlike later SoCs (AM43/DRA7) omap5 doesn't have a DRVVBUS pin that can turn on an external VBUS regulator. So this must be done by SW.
Powering the external device seems to work, when I plug in an USB-Host cable, I get 5V output. If I remember correctly (I have no access to the EVM in the next days), there is an extcon dedicated to detecting the ID pin and turning on SMPS10.
Which driver is it using? Is it upstream? But if it is taking care of turning on/off vbus independently then it should be fine. We don't have to plug it to the dwc3 driver.
The USB2 PHY that we use model in omap5.dtsi is a generic-phy and does not implement otg_set_vbus(). VBUS regulator is managed by PMIC. So we need to model the PMIC VBUS regulator as a 2nd USB2 PHY and implement otg->set_host() and otg->set_peripheral() for it.
Any ideas how to fix / debug?
Can I see your board's device tree file?
For tests on the EVM, I use the upstream omap5-uevm.dts which is based on omap5-board-common.dtsi.
Can you see dwc3 otg interrupts in /proc/interrupts when you plug/unplug a host adapter?
Yes, I'll test that asap.
You could also apply the below patch so we know what role the controller is in.
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c index 218371f..56c94cd 100644 --- a/drivers/usb/dwc3/drd.c +++ b/drivers/usb/dwc3/drd.c @@ -327,6 +327,20 @@ static void dwc3_otg_device_exit(struct dwc3 *dwc) dwc3_writel(dwc->regs, DWC3_OCTL, reg); }
+static char * otg_role_string(int role) +{
- switch (role) {
- case DWC3_OTG_ROLE_IDLE:
return "idle";- case DWC3_OTG_ROLE_DEVICE:
return "device";- case DWC3_OTG_ROLE_HOST:
return "host";- default:
return "invalid";- }
+}
void dwc3_otg_update(struct dwc3 *dwc, bool ignore_idstatus) { int ret; @@ -372,6 +386,8 @@ void dwc3_otg_update(struct dwc3 *dwc, bool ignore_idstatus)
spin_lock_irqsave(&dwc->lock, flags);
dev_info(dwc->dev, "otg: %s->%s\n", otg_role_string(dwc->current_otg_role),
otg_role_string(dwc->desired_otg_role));dwc->current_otg_role = dwc->desired_otg_role;
spin_unlock_irqrestore(&dwc->lock, flags);
-- cheers, -roger
I have added your patch and added
+&dwc3 {
dr_mode = "otg";+};
to omap5-board-common.dtsi (because it already handles extcon/smps10 enable).
And it looks as if OTG just works!
Awesome!
a) after boot
<snip>
BTW: is there a /sys node to read the OTG state?
The sys node should be something like /sys/kernel/debug/<addr>.usb
However it doesn't have anything to show the current role. It has a "mode" file which shows the otg mode and allows you to force "host" or "device" modes if initial mode was "otg".
If you need something to show the current role, it needs to be added to debugfs.c by exporting dwc->current_otg_role if (dwc->dr_mode == USB_DR_MODE_OTG)
cheers, -roger
So I'll test a little more an send a patch for review to LKML in the next days.
BR and thanks, Nikolaus