Telit LE910-NVG

[Randy Yates]

Dan Williams <dcbw at redhat.com> writes:

> <snip...>
>
> You probably want to dump 'dmesg' output when you power on the Telit
> device.  If you don't see /dev/cdc-wdm0 or wwan0, that means the kernel
> hasn't enumerated the device or hasn't bound it to a driver.  So what
> I'd do here is:
>
> 1) do whatever you do to power on the telit device
> 2) grab 'dmesg' output after 10 seconds
> 3) grab 'lsusb -v' output, or better 'usb-devices' output
>
> You should see stuff in dmesg like:
>
> [    0.884476] usb 1-4: New USB device found, idVendor=1199, idProduct=a001
> [    0.884480] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [    0.884482] usb 1-4: Product: Sierra Wireless EM7345 4G LTE
> [    0.884484] usb 1-4: Manufacturer: Sierra Wireless Inc.
> [    0.884486] usb 1-4: SerialNumber: xxxxxxxxxxxxxxxxxx
> [    1.047084] usb 1-6: new full-speed USB device number 3 using xhci_hcd
>
> if you don't see that kind of stuff, then the kernel was never notified
> about the Telit device and there's no hope of it ever showing up; you
> have to figure out that first.  That's probably related to the USB host
> controller driver for your platform.
>
> If the device does show up in 'dmesg', but the kernel isn't binding
> qmi_wwan to the device, that could be a problem with module auto-
> loading.  Try 'modprobe qmi_wwan' and see if that probes the device and
> creates /dev/cdc-wdm0 and wwan0.

Dan,

Thank you for these suggestions. They are indeed helpful. 

I have found new information since my post a couple of days ago. The
problem appears to be a result of receiving a USB babble event/message:

  [13314.062686] musb-hdrc musb-hdrc.1.auto: Babble

Once that happens, the kernel disconnects all devices on the USB bus
shuts it down. Thus no subsequent enumerations can take place, and any
connected devices (i.e., the LE910) are dropped. Wonderful.

The babble event occurs with 100 percent regularity a) early on at boot
time when the eth0 is not plugged in, and b) subsequent to boot (i.e.,
normal linux operation) whenever the eth0 is unplugged. If eth0 is 
plugged in, the babble event can also occur, but it is irregular, e.g.,
I have observed it occurring after operating for about 16 minutes.

So I believe we can conclude that this is not a libqmi issue. However, I
will continue to describe the problem since it is something others here
may have encountered.

Recall that we are running linux on a TI AM3352 SoC. On this chip the
USB is built-in as a peripheral, and the relevent driver is
KERNEL/drivers/usb/musb/musb_core.c.

I posted this problem to the TI E2E web site:

  https://e2e.ti.com/support/embedded/linux/f/354/t/489649

There is also a post from someone with a very similar problem
which I've been commenting on:

  https://e2e.ti.com/support/embedded/linux/f/354/t/484475

Any posts there to either one of these would be most welcomed.

I have received a few comments and/or read a few posts there that
mention patches to fix this. I looked into (very roughly) the
drivers/musb\_core.c driver last night and it appears that the babble
message comes from receiving a babble interrupt from the AM335x on-board
USB peripheral.

If that is the case, how can any patch or kernel version fix this
problem? It appears what we need to do to fix our problem is understand
what causes the AM335x USB peripheral to generate this interrupt, e.g.,
does it monitor power variations, DM/DP voltages, etc., or what?

So thanks Dan and the list again for your help. 
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com