Re: [PATCH v2 5/5] iio: light: stk3310: support the Sensortek STK36C61

[Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>]

On Fri, Aug 28, 2026 at 01:18:18AM -0300, Marcelo Schmitt wrote:
> > @@ -417,10 +459,10 @@ static int stk3310_read_raw(struct iio_dev *indio_dev,
> >  		mutex_unlock(&data->lock);
> >  		return IIO_VAL_INT;
> >  	case IIO_CHAN_INFO_INT_TIME:
> > -		if (chan->type == IIO_LIGHT)
> > -			ret = regmap_field_read(data->reg_als_it, &index);
> > -		else
> > +		if (chan->type == IIO_PROXIMITY)
> >  			ret = regmap_field_read(data->reg_ps_it, &index);
> > +		else
> > +			ret = regmap_field_read(data->reg_als_it, &index);
> The above seems unnecessary. Why changing the comparison from IIO_LIGHT to IIO_PROXIMITY?
> After the proposed update we would have the integration time for both light and
> intensity channels being read from the same register field?

These arms now see three channel types instead of two, so the two-way
branch has to put the intensity channels on one side or the other:
keyed on IIO_LIGHT they would fall into the else and read or write the
proximity fields. Proximity is the odd one out - its engine has its
own integration-time and gain fields - so the comparison keys on it
(the write_raw arms route identically, hence the same change there).

And yes, light and intensity read the same field: the chip measures
the colour channels in the same engine run as the ALS data, over the
ALS integration time. Stepping that field through the driver doubles
the ALS count and all four colour counts together (measured on the
device: ALS 30/59/120 across three settings, C 83/167/334, R/G/B
likewise).

> > @@ -428,10 +470,12 @@ static int stk3310_read_raw(struct iio_dev *indio_dev,
> >  		*val2 = stk3310_it_table[index][1];
> >  		return IIO_VAL_INT_PLUS_MICRO;
> >  	case IIO_CHAN_INFO_SCALE:
> > -		if (chan->type == IIO_LIGHT)
> > -			ret = regmap_field_read(data->reg_als_gain, &index);
> > -		else
> > +		if (chan->type == IIO_PROXIMITY)
> >  			ret = regmap_field_read(data->reg_ps_gain, &index);
> > +		else if (chan->channel2 == IIO_MOD_LIGHT_CLEAR)
> > +			ret = regmap_field_read(data->reg_clear_gain, &index);
> > +		else
> > +			ret = regmap_field_read(data->reg_als_gain, &index);
> Similar question here. What do we accomplish by comparing to proximity instead
> of light? Is the gain info the same for light and intensity red/green/blue channels?

The same keying, plus an extra arm because the gains split
differently: one field serves illuminance, R, G and B - switching it
x16 moved all four together (ALS 25->404, R 42->677, G 25->404,
B 15->248) - while clear did not respond to it and is gained by its
own register, which is what the IIO_MOD_LIGHT_CLEAR arm selects.

Thanks,
Jorijn