Nvi_mpu configuration

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
#1

What’s the recommended way of configuring the Nvidia nvi_mpu driver? The number of config parameters read out of the device tree by this driver is pretty small.

Specifically, I’d like to configure the sample rate (represented in the driver as “period_us_req”). This value defaults to 0. As a last resort, I’ll modify the nvi_mpu driver and add a custom device tree parameter for specifying this sample period, but there must be a way to do it without such kernel changes.

We’re not using the nvs-service, if it matters.

thanks
Jim

#4

We need time to investigate this requirement, please stay tuned.

#7

The short answer is to write the period in microseconds to the driver’s sysfs node, “batch_period”, before enabling the device.

Longer answer, history, and documentation:

Reading “batch_period” when the device is disabled will return the fastest period (in microseconds) the device supports. When reading “batch_period” when the device is enabled will return the actual period of the device.

The expected procedure to enable the device, as done by NVS using IIO, is to write the period first and then enable the device via the IIO steps (enable scan_elements and enable buffer/enable). An NVS feature is to be able to disable a device to change parameters without the device actually powering off. This is done by disabling the device the same way IIO would, except an NVS driver won’t power down the device until 0 is written to the driver’s NVS specific sysfs node, “enable”.

NVS has a few layers much like ogres are like onions. At the lowest level is this NVI (NVS driver for Invensense, which has its own API for externally attached devices (pressure and/or compass) hence its own acronym) HW driver that interacts with the HW on one end, and the NVS interface to the kernel on the other. The NVS component at the kernel layer supports multiple kernel subsystems, e.g. IIO, input, relay, etc. Since NVS is based on the Android sensor specification, in the user space, NVS provides the sensor list and all the sensor details from the sensor_cfg structure as defined in the kernel/nvidia/include/linux/nvs.h file that is provided by the NVS HW driver (NVI driver we’re talking about). Although the HW driver may have few configurable parameters, all of the members of the sensor_cfg structure can be overridden by the device tree using the NVS framework at the kernel level.

You may have noticed that the NVS framework breaks up all of the sensors into “virtual drivers”. For example, the accelerometer and gyroscope each have their own driver space as if they are separate devices. This is what allows NVS to automagically populate the sensor list in user space since all NVS “virtual drivers” have the same structure. That information is more of an FYI, but it might help explain why things were done the way they were done.

#8

Thanks for the detailed response. I’ll try it out. Do you have a link to documentation for any of this?

#9

Any official documentation would be geared toward the front end of NVS, which is really just a superset of the Android sensor API. In fact, the documentation heavily relies on the Android sensor specification for the details. However, since you’re using the driver as a standard IIO driver and not with nvs-service, the documentation doesn’t apply. And the only superset feature added to the IIO standard operating procedure (if there is a SOP for IIO) is the use of the “enable” file system attribute to completely power down the device as mentioned in the previous comment. At the kernel level, the only documentation would be at the beginning of the nvs_iio.c file and the comments in the nvs.h file.

#10

OK, thanks.