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

[me@herrie.org]

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?

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@microchip.com>
>>> 
>>> pw-bot: changes-requested
>>> 
>>> Cheers,
>>> Conor.
>>> 
>>> > +    $ref: /schemas/types.yaml#/definitions/uint32
>>> > +    minimum: 1
>>> > +    maximum: 65535
>>> > +    default: 1
>>> > +
>>> >  required:
>>> >    - compatible
>>> >    - reg
>>> > --
>>> > 2.43.0
>>> >