From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (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 E6A5F36A008 for ; Sat, 7 Mar 2026 18:48:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772909327; cv=none; b=hRblTQ/v62bWV5FyeGI3y6LJc8UFZvkTc6ng1ufpPQgfPiHkwnOSBrfSSffTepBIYrr3ABW+QiUW1L532h6UrhvyTzNSYaC6RpUPeQ4R/jk2kU9zM+Ux08hsaKa1u1A4Vn6m4Af13m1MGKxZ5vEdKsmxz6Nfm+AJXx2y1gTD2Nc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772909327; c=relaxed/simple; bh=bvfLL6leUe4v0YQLR29E1NV0KASf+WoG0ivWe/d+DYE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ozaN3cuUoeAYD5CnFQdZia1r2BfWMfSI3P39iqHhuudX6ECV+jAEUJYdCoRmNRZ5Hm2iwPCQXP6sfJwdCkNSd3xFnqqV3ymN8nAwXe/FUePIbjldnNEJ4dMgX+hMrFkdWANJ+UjHsXLEcUttwU0Vn5JJCpplSORNbFS2OJZbuGA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=yUgq4Yl+; arc=none smtp.client-ip=209.85.167.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="yUgq4Yl+" Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-45f126d47b8so7030912b6e.2 for ; Sat, 07 Mar 2026 10:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1772909323; x=1773514123; 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=QlZl3jF6Nh0Vyp4ww6yN7e366IjMVaugVNe/3eEWvKY=; b=yUgq4Yl+l5N9hLx0mBM11VFPHyeNqV7JRkiWhEj6Uycm35A75C2tNpO3R58XL99OgN ZOc/oDSYY7aWwegtq/9S/3K+g+Sr6aYeeuBRhw8oJlZs0RlkoDXgV39W9PUWUX3kN3MX z4XkS/HhYTS2u8DaGYAxRIDKaMig8H4MPcympxkK7IK76k2bz1ySiGYXFe/fIWYOqO/t sd5Oe2ewRa5lUyhuj9loPeXdgavZ4QMnPS4/LXM2Ic1MF28iBc6tCv9jNEEDdCPIiWwT Zpczsz8lb5xjIpeJK8OCwFCuosC57RoDriTwIuZ8ToF/typXPt/WfFbxWOD9RNixh0bJ TmyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772909323; x=1773514123; 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=QlZl3jF6Nh0Vyp4ww6yN7e366IjMVaugVNe/3eEWvKY=; b=SyrfCpoF4AOO8WrFqfvgy7k6svHV7eO7WdDxcTScQB5x5TgWjMW4t+OoWIGChdFd0R /GORB8uqE8JPqaMPiPGW7ohe9tfi8zkcHZHWgzNjXoAA3+ecHEQDY6/3A7q+TygDmnfT z7F+03mWP1VmfmxN2JengjgKfpqlCFvT9RVOeBHF1A5L19st2XsCsSABCZilarZH9DzJ YXFwM4c6TjROCLLPEOJlcs3eJ27A920nr/yeq8z7dt8eZpUpiGzYjffCp7nCvhgvue+l Rr9uXcN6zeNmW5CDvu5D/ofQvv2ixBRIehq+20qqOfXsmW02XqGFkRS1gqDT7MQvBIqP DPDg== X-Forwarded-Encrypted: i=1; AJvYcCWYYbekO9SekxFCUBJxbv29NF3FA5J+Z08ix6AAQgCYubCjknVJWOuV6kwpcWPQFB8gWYXdu0p4VIYokhw=@vger.kernel.org X-Gm-Message-State: AOJu0Yx6Hrf6xZpwuIs8Ee55UEWVDhHmhYFUxBF9KP45Tu17LtKnAvjO AUgHZWAuVfF5E1ewimgs45sRbSuhWLD7Riy3STlnmWmMKRW7R6CFzNALPok0rO/saTs= X-Gm-Gg: ATEYQzzPVDUZ+g7Fl3FruUSSPE8KnWpwzVHE4GWo9rHND7Q0b50mt512rm/jqEOPsde k/BF1Cu2pyUmV7s+M42f5X0d2/mJQ77cNh3csUSQhHUOUYuQDmRyE+PSuHWx3rtJPeGn07mSmV8 DguZGk6eRVrqjqmjypdm3RGt2iYN9LOxEx/z4D8EUxDqPU67YNLBAsRBTAscALxRpy3HvBr3fVr nZg0pwG9/5gkTm7zLuCHOt86cmBa4wxDG9k2FLtr2a/24ECEl44TUeAwNHCjfJMEpmS9BXYFbKz mV9hGEN1/GKDH6X7CjEoQytYcXW5VOjgWRlGB+4NyJdCMTyURQrDc5UrYvGsXO3tgil9kV1yuX5 A8Snp2CwF/KRqJhVRviuTvLJ77uIwpN3dp+C71K8n5ZOeiXpaZMRXa4g2PW4fvaJA85gpUKL9+x fJ2e8CzXSOEkuumrlyYF0Rl252058DLVoaDB0lQeFLJ6vlS0nO8KNDKxq0B0MJBOjuJKXu07voL A== X-Received: by 2002:a05:6808:830d:b0:466:ee4c:6f13 with SMTP id 5614622812f47-466ee4cb6a3mr844147b6e.2.1772909322858; Sat, 07 Mar 2026 10:48:42 -0800 (PST) Received: from ?IPV6:2600:8803:e7e4:500:cccf:5174:fa72:c520? ([2600:8803:e7e4:500:cccf:5174:fa72:c520]) by smtp.gmail.com with ESMTPSA id 5614622812f47-466df96b093sm2925084b6e.5.2026.03.07.10.48.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Mar 2026 10:48:42 -0800 (PST) Message-ID: <08717cd6-a732-4f06-a6f1-8cbdaa755b78@baylibre.com> Date: Sat, 7 Mar 2026 12:48:39 -0600 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: [PATCH 1/4] dt-bindings: iio: adc: add bindings for AD4691 family To: "Sabau, Radu bogdan" , Jonathan Cameron , Radu Sabau via B4 Relay Cc: Lars-Peter Clausen , "Hennerich, Michael" , "Sa, Nuno" , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Liam Girdwood , Mark Brown , Linus Walleij , Bartosz Golaszewski , "linux-iio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , "linux-gpio@vger.kernel.org" References: <20260305-ad4692-multichannel-sar-adc-driver-v1-0-336229a8dcc7@analog.com> <20260305-ad4692-multichannel-sar-adc-driver-v1-1-336229a8dcc7@analog.com> <20260305174559.1ded5173@jic23-huawei> Content-Language: en-US From: David Lechner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/6/26 5:55 AM, Sabau, Radu bogdan wrote: > > >> -----Original Message----- >> From: Jonathan Cameron >> Sent: Thursday, March 5, 2026 7:46 PM >> To: Radu Sabau via B4 Relay >> Cc: Sabau, Radu bogdan ; Lars-Peter Clausen ; Hennerich, Michael >> ; David Lechner ; Sa, Nuno ; Andy Shevchenko >> ; Rob Herring ; Krzysztof Kozlowski ; Conor Dooley ; >> Uwe Kleine-König ; Liam Girdwood ; Mark Brown ; Linus Walleij >> ; Bartosz Golaszewski ; linux-iio@vger.kernel.org; devicetree@vger.kernel.org; linux- >> kernel@vger.kernel.org; linux-pwm@vger.kernel.org; linux-gpio@vger.kernel.org >> Subject: Re: [PATCH 1/4] dt-bindings: iio: adc: add bindings for AD4691 family >> >> [External] >> >> On Thu, 05 Mar 2026 14:23:27 +0200 >> Radu Sabau via B4 Relay wrote: >> >>> From: Radu Sabau >>> >>> Add YAML bindings and dt-bindings header for the Analog Devices AD4691 >>> family of multichannel SAR ADCs (AD4691, AD4692, AD4693, AD4694). >>> >>> The binding describes five operating modes selectable via the >>> adi,spi-mode property, optional PWM/clock for CNV Clock and CNV Burst >>> modes, GPIO pins, voltage supplies and the trigger-source interface for >>> SPI Engine offload operation. >>> >>> Signed-off-by: Radu Sabau >> >> Hi Radu, I'm going to focus on mode... Mostly because things called >> mode are usually a sign of mixing up different aspects of the board >> design... >> > Hi Jonathan, Krysztof, > > Thank you guys so much for your review. > > Regarding 'mode', I agree that it should be something that could be modified > at run-time, especially since all register modes (CNV_CLOCK, CNV_BURST, > AUTONOMOUS and SPI_BURST) rely on the same principles of reading the > ADC result from the registers, the main difference being that PWM on the > CNV pin is required for CNV_CLOCK and CNV_BURST, but the board design > stays the same. Perhaps this PWM can be initialized at start-time and only > be used when CNV modes are being used. This would mean mode can > become an IIO attribute that could be set by the user at run-time. More likely, it would be two different ways of doing a buffered read, so maybe two different buffers? Or just pick the "best" one and only implement that mode. > > However for MANUAL, modifications of jumper resistors on the physical > board is required for proper functionality, since the CNV pin needs to be > tied to CS in this mode. Would it be preferred if bindings would have a > 'register-mode' attribute (the name could be better) which can have values > like 1(register modes are used) and 1(manual mode is used), and for > register modes, have a global IIO attribute that can switch between > them? > The binding should describe how the chip is wired up. So rather than thinking about modes, try thinking in terms of connections. Based on what the devicetree says is connected, the driver can then infer which modes are actually possible. Bringing back some context that was trimmed: + adi,spi-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4] + description: | + Selects the ADC operating mode: + 0 - CNV Clock Mode: External PWM drives CNV pin, samples at PWM rate. + 1 - CNV Burst Mode: PWM triggers burst cycles, internal oscillator + drives conversions within each burst. + 2 - Autonomous Mode: Internal oscillator drives conversions, software + starts/stops via register write. + 3 - SPI Burst Mode: Similar to Autonomous Mode but optimized for + SPI burst reads. + 4 - Manual Mode: CNV is directly tied to SPI CS. Each SPI transfer + triggers a conversion and returns previous result (pipelined). It sounds like there are 3 ways that the CNV pin could be wired up: 1. Wired to PWM 2. Not connected 3. Wired to CS On some other chips we've seen where CNV could be wired up different ways, "not connected" was not an option. In those cases, we could infer that if that no other properties indicated what CNV was connected to, then we would assume CNV was connected to SPI CS. In this case, if "not connected" is an option, we might need a bool/flag property adi,cnv-is-cs to describe that the CNV pin is wired to the CS pin. And we already have the pwms property to know when CNV is connected to a PWM. > Please let me know your thoughts on this before addressing the other > Comments and preparing other patches. > > Best regards, > Radu >