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
