> >> > >> I have prepped the patch for the tegra-udc driver to fail out in host > >> mode and load as a peripheral in otg mode. > > Just to be clear, this part is good to me. Although, doesn't CI driver operates by > default in a peripheral mode when drm_mode=otg? > Sorry to reply late due to National Holiday. The CI driver will not configure any modes if dr_mode = otg, and the VBus and Id interrupt will be enabled to wait external events. Peter > >> My reasoning for this is as follows: > >> host mode allows devices to enumerate, but data cannot transmit > >> correctly otg mode allows mode switching which is broken and was > >> never supported peripheral mode is the only function that behaves > >> correctly > >> > >> My presumption is this is caused by the chipidea driver not handling > >> the tegra specific quirks. > >> Reading through how nice and clean the tegra-ehci driver is, I'm > >> wondering if it would be better to simply pull the requisite gadget > >> stuff into the ehci driver, vice trying to wedge into the chipidea > >> driver. > >> > >> What do y'all think? > > > > Not possible. The ChipIdea driver supports multiple vendors, it is > > universal and should have all functionality needed by the host mode. > > There is no point in duplicating the effort. > > > > Looking at host.c of CI driver I even see that it has references to > > the tegra-ehci driver. I may take a look at what it would take to > > replace tegra-ehci driver with the CI, then there will one less USB > > driver for the same hardware (IIRC, the fsl-usb2-udc also potentially > > could be squashed into the CI driver). > > > >> On Mon, Sep 30, 2019 at 1:55 PM Dmitry Osipenko <digetx@xxxxxxxxx> wrote: > >>> > >>> 30.09.2019 20:46, Peter Geis пишет: > >>>> On Mon, Sep 30, 2019 at 1:42 PM Dmitry Osipenko <digetx@xxxxxxxxx> > wrote: > >>>>> > >>>>> 30.09.2019 18:54, Peter Geis пишет: > >>>>>> Dmitry, > >>>>>> > >>>>>> As far as I can tell the cpuidle drivers work perfectly, but I > >>>>>> don't have full power management yet on either my T20 device nor > >>>>>> my T30 device. > >>>>>> They aren't the cause of this though. > >>>>>> > >>>>>> I've been sticking to the mainline release code since 5.3 landed, > >>>>>> as something was merged into linux-next that breaks > >>>>>> brcm4329/brcm4330 firmware loading. > >>>>>> > >>>>>> Jumping to linux-next to test your driver just revealed the behavior. > >>>>>> > >>>>>> On my T20 device I haven't encountered issues, but that operates > >>>>>> almost exclusively in gadget mode. > >>>>>> On my T30 device tegra-udc is misbehaving, especially on linux-next. > >>>>>> > >>>>>> By removing the hardcoded LL_DEBUG config and moving to a command > >>>>>> line earlycon statement, I seem to be making progress in > >>>>>> capturing what's going on. > >>>>>> With the following actions, I got a panic crash dump: > >>>>>> phy set to peripheral, boot with tegra-ehci in host mode, usb hub plugged > in. > >>>>>> Booted successfully, hub enumerated, passed data through attached > >>>>>> ethernet device. > >>>>>> Unbind the tegra-ehci driver, bind the tegra-udc driver. > >>>>>> Hub enumerates, as well as attached ethernet device, but writes > >>>>>> to the device throw constant errors. > >>>>> > >>>>> Is the host mode working properly when booting with the tegra-udc > >>>>> as a primary driver? > >>>> > >>>> I actually got it working <once>. > >>>> It threw constant reset errors though. > >>>> Afterwards a soft reboot caused the kernel to crash with an irq-init error. > >>>> tegra-ehci is the only stable host driver. > >>> > >>> Okay, I guess the host mode requires some extra configuration (or > >>> some > >>> quirk) that is currently missing in the tegra-udc. You may try to > >>> compare what tegra-ehci and tegra-udc do differently and then figure > >>> out how make it to work, for now I don't have any better advises. > >>> > >>>>>> Unbind the tegra-udc driver, produces the following panic: > >>>>> > >>>>> Looks like it is a CI driver bug, perhaps timer's tear down isn't > >>>>> performed correctly. Maybe it is related to the errors you're > >>>>> seeing and something getting stuck with the offending timer being > >>>>> active during of the driver's unbinding.. > >>>>> > >>>>> Probably Peter Chen could help with that. > >>>>> > >>>>> [snip] > >>> > >
