30.09.2019 23:05, Peter Geis пишет: > Good Afternoon, > > I have prepped the patch for the tegra-udc driver to fail out in host > mode and load as a peripheral in otg mode. > 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] >>
