On Sun, Sep 29, 2019 at 06:15:40PM -0400, Peter Geis 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. OTG is not expected to work. I was never able to find hardware that could reliably detect switching between host and peripheral modes, so I ended up adding only peripheral support. > 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. Yeah, that sounds like a good idea. I guess I had assumed that hard- coding the mode in device tree was enough, but I agree that it makes life easier for users if they are warned if whatever changes they do to the DT are not expected to work. > 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? As I mentioned in my earlier reply to Peter, I think it might even be possible to move host support from the current ehci-tegra driver to the ChipIdea driver. I recall from looking at this back at the time, that the ChipIdea driver already has most of the code to deal with switching modes and can even rely on an internal interrupt to detect a change in the mode. Unfortunately I was never able to make that work, but you may want to look at that again if you're interested. In either case, having a patch that works about non-peripheral mode not being supported sounds like a good idea. Could you prepare such a patch? Thierry > 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
Attachment:
signature.asc
Description: PGP signature
