Jonathan Cameron <jic23@xxxxxxxxxx> writes: > On Sat, 12 Oct 2024 19:45:18 -0700 > Justin Weiss <justin@xxxxxxxxxxxxxxx> wrote: > >> Jonathan Cameron <jic23@xxxxxxxxxx> writes: >> >> > On Fri, 11 Oct 2024 08:37:49 -0700 >> > Justin Weiss <justin@xxxxxxxxxxxxxxx> wrote: >> > >> >> Add read and write functions and create _available entries. Use >> >> IIO_CHAN_INFO_SAMP_FREQ instead of IIO_CHAN_INFO_FREQUENCY to match >> >> the BMI160 / BMI323 drivers. >> > >> > Ah. Please break dropping _FREQUENCY change out as a separate fix >> > with fixes tag etc and drag it to start of the patch. It was never >> > wired to anything anyway >> > >> > That's a straight forward ABI bug so we want that to land ahead >> > of the rest of the series. >> >> Thanks, I'll pull that into its own change and make it the first patch. >> >> > Does this device have a data ready interrupt and if so what affect >> > do the different ODRs for each type of sensor have on that? >> > If there are separate data ready signals, you probably want to >> > go with a dual buffer setup from the start as it is hard to unwind >> > that later. >> >> It has data ready interrupts for both accelerometer and gyroscope and a >> FIFO interrupt. I had held off on interrupts to keep this change >> simpler, but if it's a better idea to get it in earlier, I can add it >> alongside the triggered buffer change. > > Ok. So the challenge is that IIO buffers are only described by external > metadata. We don't carry tags within them. Hence if you are using > either effectively separate datastreams (the two data ready interrupts) > or a fifo that is tagged data (how this difference of speed is normally handled > if it's one buffer) then when we push them into IIO buffers, they have > to go into separate buffers. > > In older drivers this was done via the heavy weight option of registering > two separate IIO devices. Today we have the ability to support multiple buffers > in one driver. I'm not sure we've yet used it for this case, so I think > there may still be some gaps around triggering that will matter for the > separate dataready interrupt case (fifo is fine as no trigger involved). > Looking again at that code, it looks like there may need to be quite > a bit more work to cover this case proeprly. > > We may be able to have a migration path from the simple case you have > (where timing is an external trigger) to multiple buffers. > It would involve: > 1) Initial solution where the frequencies must match if the fifo is in use. > Non fifo trigger from data ready might work but we'd need to figure out > if they run in close enough timing. > 2) Solution where we add a second buffer and if the channels are enabled > in that we can allow separate timing for the two sensor types. > > This is one of those hardware features that seems like a good idea > from the hardware design point of view but assumes a very specific > sort of software model :( > > Jonathan Hm, that does sound tricky. If there's an example I can follow, I can make an attempt at it. Otherwise, if there's a change I can make now that would help with migrating in the future, I can do that instead. Of the devices I've looked at, only one has had the interrupts usable and that one only had a single pin available. So if this change doesn't make it harder to add later if it's necessary, I would still be OK going without full support for now. Justin
