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..
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
