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. > > > 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]
