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

[me]

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?

Thanks,
Herman


> > > > The value seeds
> > > > +      in_illuminance0_calibscale, so it can still be retuned at
> > > > +      runtime through sysfs.
> > >
> > > Delete this, driver implementation stuff isn't relevant to the
> > > devicetree binding.
> > >
> > > With that gone,
> > > Acked-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
> > >
> > > pw-bot: changes-requested
> > >
> > > Cheers,
> > > Conor.
> > >
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > > +    minimum: 1
> > > > +    maximum: 65535
> > > > +    default: 1
> > > > +
> > > >  required:
> > > >    - compatible
> > > >    - reg
> > > > --
> > > > 2.43.0
> > > >