On Thu, 23 May 2019 10:40:48 -0700 Enrico Granata <egranata@xxxxxxxxxx> wrote: > Hi, > on Chrome OS devices, the architecture for sensors (such as > accelerometer and gyroscope) involves the sensors being connected to > an embedded controller, which receives interrupts from the IMU, > collects samples, and then sends an interrupt to the main CPU running > Linux. > > On the CPU, there currently is an IIO device called sensor_ring, which > handles the interrupt by collecting the samples from the EC, and > pushes them to an IIO buffer. > > As part of the EC --> AP communication mechanism, we collect: > - the time (in EC clock) when the sensor notified the EC; > - the time (in EC clock) when the embedded controller sent the interrupt; > - the time (in Linux clock) when the CPU received the interrupt. > > We use these values (which we call respectively "a" "b" and "c"), as > input to a median filter in order to both convert EC clock to Linux > clock, and to smooth out jitter. I'm a little confused on what useful information b gives you. The first gives you the 'data ready' signal from the sensor, which is as close as we can possibly get to the 'real time' at which a reading was taken. > > We have since come to realize that a median is not the best filter for > this task, and - as part of a larger redesign - would like to move > this filtering in userspace and use a different filter (most likely > either a least squares or a Kalman filter). This is sounds like something very much non standard. It's going to be hard for any general purpose code to know which timestamp is the 'right' one. > > However, doing the filtering in userland requires us to be able to > send the a, b and c points from the IIO device on the kernel to > userspace. > > My initial investigation led me to using indexing as the most viable > option to have multiple IIO_TIMESTAMP channels defined for the same > device. However, I spot a few places in the IIO framework where > channels of kind TIMESTAMP seem to have special meaning. Hmm. This is true for the main timestamp, but mainly because it is convenient to be able to do things like define available_scan_masks without having to care about having to always provide twice as many entries in order to cover the option of having the timestamp turned off and turned on. > > Is defining multiple timestamp channels via indexing a supported > operation? If not, is there any way to define such channels? Or a > better way to support our use case of providing 3 "timestamp" values > to userspace. I don't think we actually prevent it in any way (just took a fairly superficial look) and there certainly isn't any particular intention to prevent it. My only real worry is how to define this interface in a fashion that is generic. We might want to use a modified channel with appropriate IIO_MOD_* to define something like 'sensor time' vs 'host time'. We can't break the existing ABI however, so we may need the slightly ugly option of 'no modifier' is the same as 'host time'. > > Any input is appreciated. Whilst I don't really like the complexity this introduces I can see you might need the more sophisticated timestamps to let you refine the relative clock offsets and multipliers as you get more data. Jonathan
