Re: [PATCH 1/2] dt-bindings: iio: light: Add ROHM BH1730FVC binding

[Matti Vaittinen]

On 11/05/2026 11:22, Matti Vaittinen wrote:
> Thanks for patches Alexandre!
>
> It's nice to see these upstreamed :)
>
> On 10/05/2026 21:09, Alexandre Hamamdjian wrote:
> > From: CTCaer <ctcaer@xxxxxxxxx>
> >
> > Add a YAML binding for the ROHM BH1730FVC ambient light sensor.
> > Documents the required compatible string, the als-vdd/als-vid
> > regulators, and the rohm,integration-cycle, rohm,lux-multiplier,
> > rohm,opt-win-coeff and rohm,gain-coeff calibration properties
> > consumed by the driver.

// snip

> > +  rohm,opt-win-coeff:
> > +    description:
> > +      Optical-window calibration coefficients. Specified as a flat 
> > list of
> > +      triplets <rc cv ci>, one triplet per window region, where rc is 
> > the
> > +      visible/IR ratio cutoff and cv/ci are the visible and IR weighting
> > +      factors used in that region.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +    items:
> > +      minItems: 3
> > +      maxItems: 3
>
> I am not sure if I read the driver patch (2/2) correctly, but if I did, 
> then these coefficients are used to compute Luxes out of the raw sensor 
> data. I believe it would help anyone integrating (or investigating) this 
> sensor, if you added the actual formula here as a comment. If I read 
> this right, the formula is _somehting_ like:
>
>
> Lx = (cv[win] * ch0_data - ci[win] * ch1_data) / gain / int_time
>
> Here the cv[win] and ci[win] are selected from the opt-win-coeff -table, 
> depending on the measured ch1_data/ch0_data ratio, right?

One thing came to my mind. This 'window' -approach for lux calculation 
is not too unique. For example the rohm-bu27034.c uses similar approach.

The thing is that some of the sensors have more than 2 channels. (For 
example, the first version of BU27034 did. [That was BU27034NUC, which 
got cancelled when BU27034_A_NUC emerged]). These ICs may still may use 
similar approach of having light regions, determined by ratio of (2) 
channels. BUT, they may then have more than 2 coefficients / window.

So, maybe this could be made generic enough so it could be re-used for 
such devices if needed? I am not sure if other manufacturers but ROHM 
does this in Lux computations - if yes, then it might be worth making 
this more generic and not just a ROHM property? Maybe Jonathan has some 
insight on other Lux computations.

Yours,
	-- Matti

--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~