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.