On Mon, Mar 22, 2021 at 9:17 PM Dipen Patel <dipenp@xxxxxxxxxx> wrote: > My follow-up concerns on both Linus's and Kent's feedback: > > 1. Please correct me if I am wrong, lineevent in the gpiolib* is only > serves the userspace clients. > 1.a What about kernel drivers wanting to use this feature for monitoring its > GPIO lines, see gyroscope example somewhere below. In that regards, > lineevent implementation is not sufficient. > 1.b Are you also implying to extend lineevent implementation to kernel > drivers? I was talking about lineevent because you mentioned things like motors and robotics, and those things are traditionally not run in kernelspace because they are not generic hardware that fit in the kernel subsystems. Normally industrial automatic control tasks are run in a userspace thread with some realtime priority. As Kent says, in-kernel events are exclusively using IRQ as mechanism, and should be modeled as IRQs. Then the question is how you join the timestamp with the IRQ. GPIO chips are just some kind of irqchip in this regard, we reuse the irqchip infrastructure in the kernel for all GPIO drivers that generate "events" in response to state transitions on digital lines. > >> And certainly you will also want to use this timestamp for > >> IIO devices? If it is just GPIOs and IRQs today, it will be > >> gyroscopes and accelerometers tomorrow, am I right? > >> > > Gyroscope, accelerometers or any IIO are built on top of i2c/spi and/or GPIOs. > So they are covered as long as they serve as client to GTE framework, For > example, if gyroscope uses GPIO as an interrupt to indicate frame > ready, GTE could timestamp that GPIO as well any IRQs like i2c transaction > complete IRQ. To this to happen, gycroscope then register itself with > GTE framework and enable required signals that it interfaces/interested with. I think there are IIO devices that provide their own hardware timestamp and as such they might want to use that, so the mechanism need to be generic enough that a certain hardware timestamp can be selected sooner or later. But let's not overcomplicate things for now. Yours, Linus Walleij
