On 08/28, Jorijn van der Graaf wrote: > 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).
Ah, so both STK3310 and STK36C61 have register 0x02 for integration time and gain configurations that applies for all light/color channels. I think changing to compare with IIO_PROXIMITY makes sense then. Having a closer look at the data sheet I found for STK36C61, I noticed registers 0x13 and 0x14 are not listed. Does the newer part has ambient light sensing besides the clear channel? With best regards, Marcelo
