Re: [PATCH v3 2/3] dt-bindings: iio: light: isl29018: add isil,cover-comp-gain

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 8 Jun 2026 18:49:13 +0100
Conor Dooley <conor@kernel.org> wrote:

> On Fri, Jun 05, 2026 at 09:28:03PM +0200, me@herrie.org wrote:
> > On 2026-06-05 15:18, me@herrie.org wrote:  
> > > On 2026-06-05 15:04, Jonathan Cameron wrote:  
> > > > On Thu, 4 Jun 2026 18:01:08 +0100
> > > > Conor Dooley <conor@kernel.org> wrote:
> > > >   
> > > > > On Thu, Jun 04, 2026 at 12:06:16PM +0200, Herman van Hazendonk wrote:  
> > > > > > Document the new optional property that seeds the ISL29018 calibration
> > > > > > scale factor at boot from firmware, allowing boards with tinted cover
> > > > > > glass to ship with correct luminance readings without a userspace helper.
> > > > > >
> > > > > > The value is a positive integer (minimum 1, maximum 65535) that is
> > > > > > multiplied with the raw lux reading.  Userspace can still override it
> > > > > > at runtime through in_illuminance0_calibscale.
> > > > > >
> > > > > > Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
> > > > > > ---
> > > > > >  .../devicetree/bindings/iio/light/isl29018.yaml     | 13 +++++++++++++
> > > > > >  1 file changed, 13 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/iio/light/isl29018.yaml b/Documentation/devicetree/bindings/iio/light/isl29018.yaml
> > > > > > index 0ea278b07d1c..92ea2742bbd3 100644
> > > > > > --- a/Documentation/devicetree/bindings/iio/light/isl29018.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/iio/light/isl29018.yaml
> > > > > > @@ -34,6 +34,19 @@ properties:
> > > > > >    vcc-supply:
> > > > > >      description: Regulator that provides power to the sensor
> > > > > >
> > > > > > +  isil,cover-comp-gain:
> > > > > > +    description: |
> > > > > > +      Multiplier applied to the ambient-light reading at startup to
> > > > > > +      compensate for optical loss in the board's cover glass. Boards
> > > > > > +      that mount the sensor under a tinted or coated window typically
> > > > > > +      need a value between a few and a few hundred.  
> > > > 
> > > > Is it useful to support decimal points on these values?  The
> > > > userspace interface
> > > > does and you mention the 'right' answer might be only a few which
> > > > means precision
> > > > at that range will be terrible - less of an issue if 100s!
> > > > 
> > > > Thanks
> > > > 
> > > > Jonathan
> > > >   
> > > Hard to say, my old HP TouchPad needs 100 as a value here (taken from
> > > legacy 2.6.35
> > > kernel and binaries). So we probably don't need precision, but I have no
> > > other
> > > references to substantiate.
> > > 
> > > Thanks
> > > Herman  
> > Scratch that. Did some more research. Proof is in the legacy webOS binaries:
> > 
> > What legacy webOS actually does here:
> > 
> > 1. Per-device calibration via factory token reads an ALSCal token from
> > system storage
> > containing JSON with calibration points at lux_0, lux_50, lux_100, lux_400
> > (measured
> > ADC counts at known reference illuminance levels).
> > 
> > 2. Computes a floating-point ratio AlsToLux_Ratio_WhiteLED = average of
> > expected_lux /
> > measured_count across the JSON calibration points. This is a real number,
> > not an integer.
> > 
> > 3. Adjusts for light source spectrum at runtime detects illuminant type from
> > ALS:IR
> > ratio, then applies a fractional spectrum correction:
> > Fluorescent above 100 counts: ratio x 0.4652
> > Incandescent above 700 counts: ratio x 0.4
> > Incandescent 50-100 counts:    ratio x 0.9
> > Fluorescent < 50 counts:       ratio x (-0.000724·N + 0.7463)
> > 
> > 4. Final lux = ALSCount / spectrum_corrected_ratio - a true floating-point
> > division.
> > 
> > Implications
> > 
> > - The "right" cover-comp value is per-device factory-measured, not
> > per-board. Different
> > units off the same production line have different optical transmission due
> > to coating
> > tolerance.
> > - The values are fractional by nature. Examples from the legacy code:
> > 0.4652, 0.7463,
> > 0.8333. None are integers.
> > 
> > The ISL29023 datasheet itself says nothing about cover compensation - it's
> > strictly
> > board-level optical correction. So there's no "right" answer from the chip
> > side;
> > it's whatever the board's cover glass + coating attenuates.
> > 
> > ALSCal values found on the particular device:
> > 
> > {"lux_50":{"c":31}, "lux_100":{"c":58}, "lux_400":{"c":164}}
> > 
> > This is device specific TouchPad's factory calibration:
> >   - At 50 lux, ADC reads 31 counts  lux/count = 1.613
> >   - At 100 lux, ADC reads 58 counts lux/count = 1.724
> >   - At 400 lux, ADC reads 164 counts  lux/count = 2.439
> > 
> > Note the ratio isn't constant - the response is mildly non-linear, but per
> > the legacy
> > code the driver computes the average ratio as the calibration:
> > 
> >   ratio = (1.6129 + 1.7241 + 2.4390) / 3 = 1.9253 lux/count
> > 
> > Independent verification:
> >   - At calibscale=34: lux = 1295
> >   - Implied raw count: 1295 / (34 x 0.015258) = 2496 counts
> >   - Applying legacy formula: 2496 / 1.9253 = 1296.4 = 1295
> > 
> > The factory-calibrated value for this specific TouchPad is 34.04 (not 100).
> > Per-point
> > calibscale values from the ALSCal JSON:
> > 
> > Cal point‚ lux/count ratio‚ Equivalent calibscale
> > lux_50    ‚ 1.6129          ‚ 40.64
> > lux_100   ‚ 1.7241          ‚ 38.01
> > lux_400   ‚ 2.4390          ‚ 26.87
> > average   ‚ 1.9253          ‚ 34.04
> > 
> > What this means concretely
> > 
> > 1. Decimal precision is necessary, not nice-to-have. Real per-device factory
> > values
> > span 26.9 - 40.6 across the chip's response curve. A single scalar
> > approximation costs
> > precision; restricting to integer compounds it.
> > 
> > 2. Updated v5 plan: switch to two-cell <int micro> for fractional values,
> > and change
> > the tenderloin DTS default from <100> to <34 040000> (or close to that).
> > 
> > Thoughts on this?  
> 
> Instead of going 2-cell, it might be worth moving the property to be
> based in some fractional unit to begin with. I just don't know what to
> call that, milligain? I dunno.
> 
> 
> Jonathan's call here I think

If this is varying that a lot per device, then, unless you plan to
have a bootloader inject it into DT, are we better off making this
a userspace problem?  There is a hybrid we've done before, which is
to make it a firmware loading problem but that requires some way to
generate a suitable file to load and typically a calibration sequence
that goes with it.

If it is 'fairly constant' for a given device then fine to be in DT
- it will just be a case of picking the average of a bunch of measured
devices and assuming it is good enough.

If it does end up in dt, then a fractional type like Conor suggests
is fine.

Jonathan