Re: ROHM ALS, integration time

[Jonathan Cameron <jic23@kernel.org>]

On Sat, 18 Feb 2023 20:08:10 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> Thanks a lot Jonathan,
> 
> You have been super helpful :) Thanks!
> 
> On 2/18/23 19:20, Jonathan Cameron wrote:
> >>>> such it can't compensate the scale change.  
> >>
> >> Regarding the scale:
> >>
> >> When scale is changed by user, the driver attempts to maintain
> >> integration time and perform only the gain change. If requested scale
> >> can not be supported by any available gain using the current integration
> >> time, then the driver attempts to change both the gain and integration
> >> time to achieve requested scale. (If this also fails, then an error is
> >> returned).
> >>
> >> I guess this is what is expected to happen in "normal mode".  
> > 
> > Interesting. I was actually thinking prefer to change integration time
> > but your way may make more sense.
> >   
> >>
> >> As I mentioned earlier, this does not allow a great control over the
> >> integration time for users who (may?) wish to have shorter time with
> >> gain bigger than 1x.
> >>
> >> Hence the writeable integration time.
> >> Now, an user may request different integration time by writing the
> >> integration time. I assumed this is also normal operation assuming this
> >> does not cause a scale change?  
> > 
> > If magic mode write hasn't happened, then integration time should reject
> > writes. Interface is too complex otherwise because if a user writes the
> > integration time then the scale, they'll expect that their integration
> > time has not changed.  
> 
> I agree that changing the integration time set by the user could be 
> unexpected. OTOH, if we take the approach I explained above (Eg. try 
> keeping integration time intact when scale is changed and only change 
> int-time if gain alone can't provide requested scale), then the 
> integration time would not change is user asks for scale we can support 
> with the set integration time.
> 
> There is few bumps on the road though... I am not exactly sure how to 
> decide available scales to advertise. Nor am I sure how to deal with the 
> scale settings when requested scale can't be met with gain change alone 
> but where scale is also not at the one of the extreme ends (which could 
> clearly warrant the integration time change) - but is somewhere in the 
> mid-range. This can happen because the supported gains have "jumps". 1x 
> to 4x (skipping 2x), to 16x (skipping 8x) to 32, 64, and then to 256 
> (skip 128), 512, 1024, 2048 and 4096.
> 
> Integration times are 50, 100, 200, 400 - which means that some of the 
> 'mid range' scales can be only supported by some integration times.
> 
> I will try to cook an RFC next week to show what I have drafted if there 
> is no big surprizes on the road..

Hmm. There is another approach that I'd not thought of in this case because
in my head integration time is more continuous than it is for this part and
that is to fiddle the _raw values (we do this for oversampling or SAR ADCs
where things tend to be powers of 2).  The trick is to shift the raw value
always so that the 'scale' due to (in this case) integration time remains
constant.  That separates the two controls completely.

However, I'm not sure that makes sense here where the thing we typically
want to change when scaling due to saturation is integration time.

Jonathan
> 
> Yours,
> 	-- Matti
>