Disable LPM for USB 3.0 in TK1

Autonomous Machines Jetson & Embedded Systems Jetson TK1
21

@linuxdev
Without camera:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M

With camera:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
    |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M

there is descriptors: https://textuploader.com/15r9d

22

From the USB side, excluding any power management issue, USB is working according to the tree listing. The verbose detailed listing might offer more clues. What is the output of this (adjusting the ID for your camera):

sudo lsusb -d 0955:7140 -vvv

The earlier listed messages indicate some sort of protocol error. Since this is a custom driver for the camera I wonder if the driver itself might have some sort of options for LPM being disabled. The verbose listing might offer more information about the driver (looking at driver options is basically the next step).

The current status seems to be that part of the system uses LPM, and that another part of the system does not support LPM (the camera and/or driver). Things probably work well until LPM is hit, and then things would go bad. On the assumption that the camera cannot use LPM (and knowing what the custom driver is might answer if there is an option to make LPM possible) you could recompile the kernel without power management support (this is something I’m not sure is a good idea since it would remove power management for everything USB…even so this would be an excellent debug step to know if feature removal solves the problem). You can see your current kernel config related to this via:

gunzip < /proc/config.gz | grep CONFIG_PM_RUNTIME

…rebuilding without that feature would be a way to get around going into LPM when something doesn’t work with LPM.

There is a good chance this wouldn’t work anyway because you already have the “autosuspend=-1” going (I am assuming the USB errors were with autosuspend being disabled already with -1). Beyond the verbose lsusb listing can you give any information on what driver this camera uses?

23

There is no driver for this camera for linux. I just use libusb for transmitting command at low-level. There is link, where you can see descriptors: https://textuploader.com/15r9d
There is out from command:

ubuntu@tegra-ubuntu:~$ gunzip < /proc/config.gz | grep CONFIG_PM_RUNTIME
CONFIG_PM_RUNTIME=y
24

You could rebuild the kernel without LPM support, but this would remove low power modes for all USB (no device would sleep). This might solve the problem, but you won’t know if you don’t test (be sure to keep the old config handy to put it back in place). If you do, then this would give valuable information. The TK1 still allows use of extra Image files and module directories to be picked from serial console for alternate boot. Do you have a serial console? If so, then this is easy to test.

Libusb interface is at user space level, but it is still the kernel which does the direct communications with the device. I couldn’t say for sure, but it sounds like there is still some missing configuration within the kernel itself. Complaints about USB protocol might be passed to libusb or intended to be handled by libusb, but it is worth looking to see if something in the kernel is missing which was intended to handle the parts of USB which the error complains of. Normally there would be a driver which talks to a custom device before talking to user space. Standard class devices might not have an issue where custom devices do (and your device is custom). Would it be possible to find out the exact camera requirements? Model, any kind of specification, so on? It feels like there is some missing kernel space software in this and I’d like to see what the camera docs say on requirements in Linux.