iio: health: max30102: proximity power saving TODO and datasheet history

The proximity power saving TODO in max30102.c was added in the original driver commit b3c590ce14b1 ("iio: health: add MAX30102 oximeter driver support") in Feb 2017. At that time, the MAX30102 datasheet documented a Proximity Function and Proximity Mode Interrupt Threshold register. Both were removed in revision 1 of that datasheet on October 2018. The MAX30101 datasheet did the same in its revision 1 on June 2018.

That also explains the PROX_INT defines in max30102.c, as they were correct in revision 0 of the datasheet when the commit was made.

Since there is no current documentation for the proximity function on the MAX30102 or MAX30101, I don't think this TODO should be implemented for those parts. Does this seem like the right decision?

However, the feature is still well-documented on the MAX30105. Is proximity power saving worth implementing there? I don't have a MAX30105 but I am more than willing to purchase one and develop and test on it, and I have access to a logic analyzer to verify the I2C transactions.

For the implementation, I would add MAX30105-gated defines for the PILOT_PA (0x10) and PROX_INT_THRESH (0x30) registers and handle PROX_INT in the interrupt handler. The MAX30105 transitions out of proximity mode automatically once the ADC count exceeds the threshold, so PROX_INT is a notification to start getting data, rather than a mode switch.

For the ABI, I was thinking of using an IIO_PROXIMITY channel with an iio_event_spec for the threshold and enable, similar to what was done in cm36651.c. Is this the right approach?

This feature would then be enabled through the event enable, so with the event disabled, the driver would behave the same as it does today. This is important because with proximity active, enabling the buffer would not produce data until an object is detected.

One interaction with a patch that was applied recently [1]: enabling PROX_INT falsifies the assumption that FIFO_RDY is the only enabled interrupt source. So the handler would need to distinguish between causes, likely meaning that max30102_fifo_count() will need to be refactored a little.

Thank you.

[1] https://lore.kernel.org/linux-iio/[email protected]/

If I had to guess the power-saving was such a minor amount that I didn't bother with implementing it, and it being dropped from the datasheet probably backs that up.

Thanks,

Matt