Re: [RFC] iio: light: tcs3472: implementing wait time TODO
From: Aldo Conte
Date: Sat Apr 25 2026 - 15:01:04 EST
On 4/25/26 18:49, David Lechner wrote:
On 4/25/26 11:28 AM, Aldo Conte wrote: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.
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?
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.
yes
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?
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?
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.
I also plan a following patch converting the driver to devm.
Would be better to do this first before adding new features.
Thanks,
Aldo