On Sun, Mar 3, 2019 at 9:38 AM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > Hmm. Just been thinking a bit about the events on here and wondered > if it is possible to mask them through careful use of the threshold > values - i.e. can we stop the hardware generating the interrupts for > the ones we don't want. It would be unusual for hardware to be > designed where this wasn't possible. Excellent point! People with power / battery constraints take a dim view of receiving interrupts when no-one wants them. So disabling them in h/w is definitely the way to go, if possible. And yes, this also makes a non-issue of thresh_en visibility concerns, if any. > > Alternatively if you have a scope or equivalent to verify if it is doing > these as a multi byte read and working that would be even better. > It is not uncommon for hardware to implement fairly standard i2c features > like this and not document them because they weren't what the test code > the docs writer got given does! (may not be true here of course) Or alternatively, the current chip rev supports undocumented multi-reads, and the next revision silently drops support, thereby breaking the driver... Been there, done that, got the T-shirt :(
