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

[Conor Dooley]

On Fri, Jun 05, 2026 at 09:28:03PM +0200, me@xxxxxxxxxx wrote:
> On 2026-06-05 15:18, me@xxxxxxxxxx wrote:
> > On 2026-06-05 15:04, Jonathan Cameron wrote:
> > > On Thu, 4 Jun 2026 18:01:08 +0100
> > > Conor Dooley <conor@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > > > ---
> > > > >  .../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

Attachment: signature.asc
Description: PGP signature