From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82F9B3AC00 for ; Sat, 25 Apr 2026 19:00:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777143654; cv=none; b=JhOSBfucyk/lBwQqftjSItOSia5fdeJTeJ0y5er+gzCToyHacNa2FKwHzOCWw7mJj4/6PaT1+DzE0jL9u9gtQylTev0Rbj+dnmNGg5kzhi3XCo0BcW2GpvgAIV2+P7Cn6nuhmE+mqxax0H3xufOnPcVjKjyXXvf/BCqtFww3YjQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777143654; c=relaxed/simple; bh=jKRAC0dvOAxQMd8XXDWnCxRhT/FTsUIqku+Xl3HcVFU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gEuZ34utFckBBEPehJ1xrRrqtST1uu3OGSyBDBZQtI87PdY2W62yJy8oqankheBIJYCW/0PKmIrPNtCcZODXIhKFNhJLmzhUAKr/w5twYUdRsQx7g4UNde5s5kuxsIhZyWVhDTFMDeINltURJWmAdZBuS7Noq5Kd2dALeTPE5m4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ltgUU9C+; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ltgUU9C+" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4891b0786beso60366805e9.1 for ; Sat, 25 Apr 2026 12:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777143651; x=1777748451; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ufRuLrbKWmmAO4hqjvZ+xgyWvj73/w5Ztmfg4lvBqNU=; b=ltgUU9C+8bAvZ54FSFo1kanQBMxsoIlkQN83N9b5J1DmLvK0CgvkzE6hWYKA40MP5J YOdJ6INQ2rSP1B7vB10gDMqsc7UqYSsIamhb7VndB+LxeIv7K57/jUtGmAa70j3zD6SR qayochfAAIDX+YRV8Qw7ibQ3NXs2zcVeTq1t/6kM081kKoeuV8EzC92hD25k0TLfN0B2 uTp2gDVXNtzZeoVqRyw+Qej/HGyR4AcmWfzb274OTWqtBKGD1F6Z8wlODjiEhOKJKGpf 5GOti5JSO6ozrHIv57ay08lZi6lZ62PuxnDUIqIewvIOSxvEDrRUGjP5oPBhPLe/XPxP 9DNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777143651; x=1777748451; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ufRuLrbKWmmAO4hqjvZ+xgyWvj73/w5Ztmfg4lvBqNU=; b=hwFdD7OrHbKHynz1LZHZ3x+ENDBnlf/jaYUefJI5OdhZcb44Ux7xtpe0GyJYWTrjEd V9/6+uUxsImldsKJH6l+0EIefsRh26OC6mFW1GGRYng5qx9a5r1pm3spI3CD81Bj+IA9 hyYc36f+Lao8nFSHqHXWsc3URm3OjvtJ8kwro4I8VQvDDLvEbrx/wmRo349UsrkmvsuA bddt+pl5/jGhUKWFc7/ykNo/sONoayLaj+OXCEm+5Eq1FEDWSOsb38z959ECAGJ0gf6D GeIZpO1TlrIZSI6/KGnphFvUWSNryKF6qP/lTPQQaolC64FZiv9G0YMFePn3gbAF5+Rw vL0Q== X-Forwarded-Encrypted: i=1; AFNElJ+UjZymO3FRHPi4nyrIPL10IkPcekmbr/yZorQEec9EK3qw5sL6+jcRsV4HVmXotqYc5TMmg+CCLj+yfjE=@vger.kernel.org X-Gm-Message-State: AOJu0YyoqEx356DQTSlGHy//QFaByTo9BJPqOJBUrKzMpGaqyLb2F0Y/ YwqmrWsXjImReyIOlby/+yhZLsjrFfUjXvFJlUK1/bO8SBtPF6XZdj6p X-Gm-Gg: AeBDiev4Xo8LJYs45bd3HszWmk48Djmz4IHUB62i83Gmgcxr4y77j+MfUGp+MweZhQL RRT1HuxR23o8aQcV67Yghi6oARJDhg0/g7FY1LC5FCl2wWqNylEhMEwIkfndLfSLsh9k2808qsO 5p6r9MOh4g5DMDsDXZqxYQgIPm4cnm/tnMRYmTLOmR2QOfJssumSowH++jdmBbvBiCYJ2PBoWBd bk+ii/LLeP6P8/WlOBVV0bjqAf/k/nsahJrCHEQaKl+KazL+y1Nfk/YBqAnn7nR5BFOYLmJjnE/ IXPJ4YMLP7HkjGUqu/SlCiuuTI29h1rOXkkxu21f88iVhzyyaq+jJ7zOy4cKYUlP7lc7/tZcXn6 mYBZ3gl3bXFCnsP0mZrEmXKY3KAHs4gcgEkz+h1v6YhY39FgePCoo9wwzs4SJJSy0E4d647uDwb aaeiYUGKhmZhjt8NV28gQ+UGOb+dtx0/MQqK/8VDE47ZvQU0PIfPxhpXKIgM/tSgedV/7kqLgjz vSQIjNEtw== X-Received: by 2002:a05:600c:3053:b0:48a:53ea:140b with SMTP id 5b1f17b1804b1-48a53ea1526mr197230245e9.28.1777143650714; Sat, 25 Apr 2026 12:00:50 -0700 (PDT) Received: from ?IPV6:2a01:e11:5402:d840:f1ee:c5d:74e4:6e19? ([2a01:e11:5402:d840:f1ee:c5d:74e4:6e19]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4891cc84a1bsm176239435e9.0.2026.04.25.12.00.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2026 12:00:50 -0700 (PDT) Message-ID: <3d4a4dbd-6618-4b63-ade1-d68155bac3ac@gmail.com> Date: Sat, 25 Apr 2026 21:00:49 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] iio: light: tcs3472: implementing wait time TODO To: David Lechner , linux-iio@vger.kernel.org Cc: Jonathan Cameron , =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , linux-kernel@vger.kernel.org References: <73d2183e-dffe-4ae4-9312-c544e0079f3a@gmail.com> <46fd475f-8d54-4419-a195-d66c947fcc1b@baylibre.com> Content-Language: en-US From: Aldo Conte In-Reply-To: <46fd475f-8d54-4419-a195-d66c947fcc1b@baylibre.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 >> >