30.09.2019 23:55, Dmitry Osipenko пишет: > 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. 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? >> 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] >>> >
