Re: [RFC] iio: light: tcs3472: implementing wait time TODO

[Aldo Conte <aldocontelk@gmail.com>]

On 4/25/26 18:49, David Lechner wrote:
> On 4/25/26 11:28 AM, Aldo Conte wrote:
>> Hi all,
>>
>> I'd like to resolve the wait time TODO in tcs3472.c.
> 
> Do you actually have this hardware to test it?
> 
> What is the application that needs to make use of this feature?
> 
I'm currently participating in the 2026 linux kernel mentorship program. 
I don't really have an application that would use this feature, but in 
any case, I have the hardware (Adafruit TCS34725 breakout board to test 
with a Raspberry Pi 3B) to test everything out.

As part of this experience, I'm focusing on “light” and, while looking 
through the TODO, i noticed this and wanted to explore it further.


>>
>> The TCS3472 has a WTIME register and WEN bit that insert a low-power
> 
> What about WLONG?
> 
>> wait state between RGBC cycles. The register is already defined in the driver but never used.
>> I noticed that tsl2772.c enables wait with a fixed default and no
>> userspace control. However, I think exposing the wait time to
>> userspace would be more useful to tune the power/responsiveness tradeoff.
> 
> I assume this would affect the effective sample rate?
yes
> 
>>
>> My plan would be to expose it via an ext_info attribute in
>> microseconds, following the same convention as integration_time.
>> Does that sound acceptable, or would you prefer a simpler approach
>> with just a fixed default like tsl2772?
> 
> So perhaps we could just use the standard sampling_frequency attribute?

Just want to make sure I understand the sampling_frequency approach
correctly before implementing.

The total cycle time of the chip is:

   cycle = wait_time + rgbc_init + integration_time
         = (256 - WTIME) * 2.4ms + 2.4ms + (256 - ATIME) * 2.4ms

So sampling_frequency = 1 / cycle.

On a write, the driver would keep ATIME fixed (since the user
controls it independently via integration_time) and solve for WTIME:

   wait_time = (1 / requested_freq) - 2.4ms - atime_duration
   WTIME = 256 - (wait_time / 2.4ms)

For very low frequencies where the wait exceeds 614 ms, the driver
would automatically enable WLONG in the CONFIG register to extend
the step from 2.4 ms to 28.8 ms.

But i wanto to clear my self this: changing integration_time would 
implicitly change
the effective sampling_frequency since both contribute to the cycle
time. Is that acceptable, or should the driver recalculate WTIME
when ATIME changes to maintain the current sampling_frequency?

>>
>> I also plan a following patch converting the driver to devm.
> 
> Would be better to do this first before adding new features.
> 
ok i could bring it up in the series assuming instead that the WTIME new 
feature is actually wanted, since I don't have a real-world application.
>>
>> Thanks,
>> Aldo
>>
>