Good Evening, While testing Dmitry's cpuidle driver I found that tegra-udc is broken completely on linux-next. Even in peripheral mode, disconnected from the host, it locks at the same place. [ 2.864983] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.871723] tegra-ehci: Tegra EHCI driver [ 2.880593] tegra-ehci 7d004000.usb: EHCI Host Controller [ 2.886484] tegra-ehci 7d004000.usb: new USB bus registered, assigned bus number 1 [ 2.895250] tegra-ehci 7d004000.usb: irq 88, io mem 0x7d004000 [ 2.916528] tegra-ehci 7d004000.usb: USB 2.0 started, EHCI 1.00 [ 2.927441] hub 1-0:1.0: USB hub found [ 2.931479] hub 1-0:1.0: 1 port detected [ 2.939124] usbcore: registered new interface driver cdc_acm [ 2.944889] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters [ 2.953185] usbcore: registered new interface driver cdc_wdm [ 2.959107] usbcore: registered new interface driver uas [ 2.964824] usbcore: registered new interface driver usb-storage [ 2.974726] tegra-udc 7d000000.usb: 7d000000.usb supply vbus not found, using dummy regulator [ 2.990506] ci_hdrc ci_hdrc.0: EHCI Host Controller [ 2.992320] udc ci_hdrc.0: registering UDC driver [g_ncm] [ 2.995708] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 2 [ 3.001232] using random self ethernet address [ 3.012631] using random host ethernet address [ 3.017190] g_ncm gadget: adding config #1 'CDC Ethernet (NCM)'/(ptrval) [ 3.020523] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 [ 3.024058] g_ncm gadget: adding 'cdc_network'/(ptrval) to config 'CDC Ethernet (NCM)'/(ptrval) [ 3.033578] hub 2-0:1.0: USB hub found [ 3.041721] usb0: HOST MAC 9e:a2:94:94:76:53 [ 3.042085] hub 2-0:1.0: 1 port detected [ 3.046706] usb0: MAC b2:13:8e:20:a9:fa [ 3.054215] g_ncm gadget: CDC Network: dual speed IN/ep1in OUT/ep1out NOTIFY/ep2in [ 3.061861] g_ncm gadget: cfg 1/(ptrval) speeds: high full [ 3.067402] g_ncm gadget: interface 0 = cdc_network/(ptrval) [ 3.073292] g_ncm gadget: interface 1 = cdc_network/(ptrval) [ 3.079206] g_ncm gadget: NCM Gadget [ 3.082843] g_ncm gadget: g_ncm ready [ 3.091020] rtc rtc1: alarm rollover: day [ 3.096710] tegra_rtc 7000e000.rtc: char device (253:1) [ 3.102059] tegra_rtc 7000e000.rtc: registered as rtc1 [ 3.107257] tegra_rtc 7000e000.rtc: Tegra internal Real Time Clock [ 3.114270] i2c /dev entries driver [ 3.118781] tegra-apbdma 6000a000.dma: private_candidate: dma0chan0 busy [ 3.128234] tegra-apbdma 6000a000.dma: private_candidate: dma0chan0 busy [ 3.135069] tegra-apbdma 6000a000.dma: private_candidate: dma0chan1 busy [ 3.141875] tegra-apbdma 6000a000.dma: private_candidate: dma0chan0 busy [ 3.148644] tegra-apbdma 6000a000.dma: private_candidate: dma0chan1 busy [ 3.155402] tegra-apbdma 6000a000.dma: private_candidate: dma0c Thank you for your time, Peter On Sun, Sep 29, 2019 at 6:15 PM Peter Geis <pgwipeout@xxxxxxxxx> wrote: > > Good Afternoon, > > So I have dug a bit further into it. > The tegra-udc driver defaults to host mode when set to otg. > If the tegra-udc driver is in host mode while plugged into another > host, the kernel will hard lock. > If the tegra-udc driver is in host mode with a device attached the > device enumerates correctly. > In this state, if you change the state to gadget, the driver goes into > a broken state. > The gadget side is in gadget mode, but the host does not enumerate the device. > > As it stands the code path for the tegra-udc driver is broken in OTG mode. > Without proper extcon support we can't support dynamic switching > correctly anyways. > My hack around method of retaining the phy in peripheral mode and > switching drivers to change modes only works because both code paths > are incomplete as well, and should not be relied upon. > > I think for the time being, the tegra-udc driver should check for > host, peripheral, or otg mode. > If it detects the device is set to otg mode, it should print an error > message describing the current situation and fail out. > > If I had a device to test against with an extcon capable port, I'd try > some more experimenting with the chipidea drivers to see if I can get > it to work. > > What do you think? > > Dmitry, > Do you have any devices to experiment with this? > > Thank you for your time, > Peter > > On Sat, Sep 28, 2019 at 11:36 PM Peter Chen <peter.chen@xxxxxxx> wrote: > > > > > > > > > > I've encountered an odd situation where the CI Dual Role driver hard locks the > > > kernel on the Ouya (Tegra 3). > > > I was attempting to set up manual mode switching in the kernel, as the Ouya lacks > > > hardware support for the ID pin and no voltage output on that port. > > > I found that the kernel was hard locking whenever I had the dr_mode = "otg" set in > > > the devicetree. > > > > It seems Tegra doesn't support host mode using chipidea driver. The ci_hdrc_tegra.c > > only supports device mode. Thierry, could you confirm that? > > > > Peter > > > > > No further output was seen on the console, and sysreq does not respond. > > > It occurs both in module and builtin mode. > > > > > > I have however found a workaround. > > > By setting the dual role usb device to: > > > compatible = "nvidia,tegra30-ehci", "nvidia,tegra30-udc"; and setting the assigned > > > phy to: > > > dr_mode = "peripheral"; > > > I can achieve rudimentary live switching of roles. > > > The device defaults to host mode, as the ehci driver enumerates first. > > > By unbinding the tegra-ehci driver and binding the tegra-udc driver, I can switch to > > > gadget mode. > > > The reverse also works. > > > The PHY driver does not appear to care if it is always in peripheral mode. > > > > > > Thank you for your time, > > > Peter Geis
