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

[Matti Vaittinen <mazziesaccount@gmail.com>]

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@gmail.com>
>>
>> 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! ~~