Re: [RFC] iio: health: max30102: proximity power saving TODO and datasheet history

On Thursday, 13 August 2026 at 02:27, Marco Chen <[email protected]> wrote:

> 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.

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

> 
> 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]/
> 
> 
>