I am using a tx2 in a battery powered application. I need USB to run a peripheral - all works good.
Now when I don’t want to use the USB bus, is there a way to turn off vbus power and save the 400ma that the device uses? And for bonus points can I shut off the clocks to the hcd block.
This power control stuff is fairly standard for Android phones where saving battery power is essential.
Thanks for the help, Steve
Wow, that just opens up a lot of new questions. Is there a reason that the standard jetson distribution does not support a /sys file to disable USB power?
The article you pointed to implies that somewhere I can find the device tree .dts file that describes my hardware? It also implies that I can somehow compile it to a .dtb for use in the standard kernel. And I somehow have to reflash the jetson. At that point a sys/class/regulator will exist that allows what I need.
The complications are extreme. For one I have both a tx2 and a tx2i. Will they be the same? All the more the reason usb power control should be built-in and have a logical name so userspace can handle it without intimate knowledge of how a pcb is layed out.
Can you point to more forum response that can help answer my questions?
Thanks, Steve
If interested, here is a description of working with a device tree:
[url]https://devtalk.nvidia.com/default/topic/1037131/jetson-tx1/does-anybody-know-how-to-enable-and-program-an-spi-protocol-on-the-tx1-/post/5269528/#5269528[/url]
There may be some use in knowing basically why device tree evolved this way. The following is just to give you an idea of what brought device trees into the story…
There was a time when the Linux kernel had everything a device tree would describe in the kernel itself. Every single board, using every single variant, had its own variation on doing certain things regarding initialization of hardware (changes required rebuilding and installing a new kernel). The concept and recipe for bringing up the various hardware was the same, but details forced duplication and editing of kernel code. Linus Torvalds was a bit upset with this, and as a result, device trees were added as a kind of abstraction (call it a OOP “design pattern”) to different hardware doing the same thing with slight differences. The kernel could deal with one set of code by using a device tree, and the kernel could cut out all of those details.
The individual drivers then used what might be (inaccurately) described as a tree-like macro substitution of its terms for actual values. If the tree contains a term the driver understands, then the driver uses that term; the values set up, e.g., 3.3V versus 5V for a rail, then the driver uses that setting. An entire set of drivers will use the same term, but the value will differ for most every board out in the wild. It is no longer required to build a kernel to change from 3.3V to 5V for that example.
You might consider that the device tree is actually code within a driver, and part of the kernel…it’s just in a separate file. In the long run it simplifies life for kernel developers and implies being able to download a smaller kernel. Device tree for this purpose was chosen by the kernel developers, not NVIDIA.
USB itself is a standard. The goal of the drivers (e.g., tegra_xusb) is to follow the standard. Unless someone sees a demand for a use-case which is outside of the standard it is unlikely anyone would have even thought to implement it. I would guess that if a number of people find what you are asking for to be useful, then someone might implement this. Any communications between a driver and “/sys” is part of the driver, and so making a larger or more complicated or slower driver probably won’t happen without a good reason. If you want to describe a use-case as a means of asking for a “/sys” feature, then you’ve probably come to the right place.
NOTE: There are some differences in how to install a device tree depending on which release is used. Device tree signing may complicate things in later releases. If you need to ask for information on dealing with the device tree be sure to mention which release you are working with.
NOTE: A TX2 and TX2i will be very similar in device tree. In many places these will be an exact match. However, wiring layout will imply some differences…the same blocks/nodes of the tree will exist, but values may differ in those cases.