From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 3380043553E for ; Tue, 21 Jul 2026 08:03:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784621011; cv=none; b=tKKyCofMMNFo1lL2rC83ZfL+iPGUE1AdOC3GBqbZNrZeVsXSJPLBA2TfOLSN8OwPG/prIqiJb3TutkagUyITdxCFzgx2xSyTutcSzWgAsI0L3d34PbTMr+xZs8pjhZldpdZJAXRmtwDuL7601dSSeS8ohmqbdQk9W8IycFNfWyY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784621011; c=relaxed/simple; bh=0Cbw2gXFjpOIEPOY/4kVuvN9KhzVSRPu/bEgNQbmbnU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ui+uT77PNF3avq8zfPkKNB9hltsm2fuif6BiuAGEz80dLGwItDVuJNGUszrkhNbHWKPa8oXyNW59kl0OLd7aEehn7AHAT1kRAyqF4a8w0TgTNUaGOulc3PQgIc+wgVVt3e2TmbWErEsaEJs+SUmGmDTjuPNzTBsB/J/Et8maTbM= 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=JgLCOL/n; arc=none smtp.client-ip=209.85.221.53 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="JgLCOL/n" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-47f81a3ccf9so156115f8f.0 for ; Tue, 21 Jul 2026 01:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784621008; x=1785225808; darn=vger.kernel.org; h=content-transfer-encoding:content-type: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 :content-type; bh=FQW9nOmQRNCmAQpN47AcJCe9kdEEIZC5I+8m11r1HjA=; b=JgLCOL/nXI26OSR7/+twJ6V9h3yG7vvwqbLYx3My9qGzF51G+2RJAmJ8pVT3vDgB8T jqiiLMPPiWcC/CyMpV7I3ES9+7OaG7b7KdHYBeoz9KI7/mHQyXthek5bHzjRFbAzzujV dg9WXtd7D5pSh1rRFHycGozTs24CC2C/CxqcDMxVdzzBD530SNXZqsMF4axEf6XRaTp4 nNHwJEz+TeaclqflbaDM0YWyS0QGydkH/CH3uCwN2oeqQ9K/uf/A+VShlJJ0zouwQtHQ SutVVUA/4wWzlnbvXl9PcI1Lo5IUXVgxGb13yyIUAIx5Iys6fEyBeFyW9zhAAEGS1aA2 zdyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784621008; x=1785225808; h=content-transfer-encoding:content-type: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:content-type; bh=FQW9nOmQRNCmAQpN47AcJCe9kdEEIZC5I+8m11r1HjA=; b=HhzFcubU3Qg6AizWxW8IFStL72iGr+HI855BeQSW6+Xs25be3zkNNoXRlugeULDecK WlkwwgdWx3i9nDmHI+FfMSRnofv/odNroNP9Dz+mHKTNOozbmKGj6KFDAQ9cgm7zi6tS rEpG7xamUQM1i5WeYwO/ZoQp7Cs/gYm9S8V0KHHWYnH1ahyaqkPh0LKdetNIwFRqXfgh HEsgtuKIpCrgUA3WCtcmNKGUfVKBivdcYzavxYbIBvR5ROM5yF6fTCypOjiicXFv3MPA 1w7z5jAJFnL9BFRRNPRvybTYq4DZMZEOUEVaFk53ZWmS53t+0VSa1whFdTM/rPIPm65/ BCBg== X-Forwarded-Encrypted: i=1; AHgh+RqQoFoJQ0NwPTe2g3DLqrFdc9p0nuU8KOGDbRGt3OspzVXbnVQpAf6px3TGdPTEEpWsPWjWHEaF0CmYc7g=@vger.kernel.org X-Gm-Message-State: AOJu0YxbGovajkIsF9BqIFtOQ3mvtf86UAESCjf5/fxmPH1fUEgbnV/S U/pAbSs5B1ymolbHgm7fsH03qu/M1zSacl6vYy4aNvyZw1hod3/XnRFP X-Gm-Gg: AR+sD11CwI2Ko1yROOffS/H0LJGPwleK8gUaO7LHHlvPM/2G8d0ICz8E+tmnuHBisXo wPOwOlfwtCdIay6I+eMzdibHxW/nf1aEKhqQQgLoL54J9lH2144CjicFg3WpS89Xfka7gidh+SH JY7ipaDKC8TcLC7+9vBYjfX5EKE6QvN8R96ytJuuxNVDpJuK5zuDZovEhtR92//L3KzPogYQRvY QZzYcUef5zx0nj/rQgOOHESYa7LTyEUpnQwhYhYKG9FB70f0UgpM6K+OlnCvJYbaZ/7qIZuIMLB 26pRs7MpT0yjIHbehlAw18E6X3dm8AikxO3LCRSpOBQRWxLw3R8GN+KodAUyzVv5HweW8ouxiNq HzwYqY3/XWmIcYDRLvikDsrCSGb+jgw+rRN7MESd0rRPIHySygUy3mGi+/vjIce6sZReoj/wg9R ZAk8RsTBWNWoxX96nSBI26qnpHvXxXO6E19EaBJ6rNCGS9xHTsjoM+6hRa783yCpDZUoMGwsTes lTwl3kRm7Zer2+pbTw= X-Received: by 2002:adf:e195:0:b0:475:a4ae:e630 with SMTP id ffacd0b85a97d-47f623364bfmr20547113f8f.37.1784621008290; Tue, 21 Jul 2026 01:03:28 -0700 (PDT) Received: from [172.24.138.145] (ipservice-092-208-246-161.092.208.pools.vodafone-ip.de. [92.208.246.161]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f63eeece9sm35822439f8f.37.2026.07.21.01.03.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jul 2026 01:03:27 -0700 (PDT) Message-ID: Date: Tue, 21 Jul 2026 10:03:26 +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: [PATCH 1/6] dt-bindings: iio: adc: Add AD7768 To: David Lechner , Janani Sunil , =?UTF-8?Q?Nuno_S=C3=A1?= , Michael Hennerich , Jonathan Cameron , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Olivier Moysan , Philipp Zabel , Linus Walleij , Bartosz Golaszewski , Jonathan Corbet , Shuah Khan Cc: linux@analog.com, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org References: <20260709-ad7768-driver-v1-0-44e1194fd96a@analog.com> <20260709-ad7768-driver-v1-1-44e1194fd96a@analog.com> <36df7c4f-82ea-4ed5-a4f9-3a29c75dc99a@baylibre.com> <9dd16bb5-7a30-4024-88a7-4a4bf47c35e8@gmail.com> Content-Language: en-US From: Janani Sunil In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/21/26 03:39, David Lechner wrote: > On 7/20/26 9:00 AM, Janani Sunil wrote: >> On 7/9/26 17:43, David Lechner wrote: >>> On 7/9/26 3:50 AM, Janani Sunil wrote: >>>> Devicetree Bindings for AD7768-4 (4 channel) and AD7768 (8 channel) >>>> simultaneous sampling ADC >>>> >>>> Signed-off-by: Janani Sunil >>>> --- >>>> >>>> + >>>> +  adi,power-mode: >>>> +    $ref: /schemas/types.yaml#/definitions/string >>>> +    enum: >>>> +      - low >>>> +      - median >>>> +      - fast >>>> +    description: >>>> +      Power mode selection. >>> Unless there are pins that control this, it seems like it should be >>> left up to the driver to decide how to set this. >>> >>> In this case, it looks like the power mode also influences sample rate >>> which is normally something controlled at runtime. > Looking at this again, there is also an MCLK divider that influences > sample rate, so sampling_frequency to power mode is not straight-forward > anyway. > >> Hi David, >> >> The reason we'd like to retain power mode control is that certain ODRs are supported across all three power modes (low/median/fast), and the RMS noise and power consumption differ significantly between them at the same ODR. >> >> The higher the power mode, the better the noise performance, but power consumption nearly doubles for every ~3 dB improvement in dynamic range. Silently selecting one power mode in the driver would remove a meaningful hardware tradeoff from the user. >> >> We'd like to propose the following instead: >> - Remove adi,power-mode from the DT as suggested. >> - Expose power mode as a per-device sysfs attribute. >> - in_voltage_sampling_frequency_available dynamically reflects only the ODRs valid for the currently selected power mode. >> >> This keeps the DT clean while still giving the user explicit control over the noise versus power trade off. Would this approach be acceptable? >> >> Thanks, >> Jan >> >> > Jonathan usually pushes back against userspace power controls. We do have > this for accelerometers, but not ADCs currently. > > If we can't think of anything better, maybe we could use this. It only > has low_noise and low_power options though, so the driver would still > need to chose the best power mode of the 3 based on the other requested > parameters. E.g. always make all sampling_frequency available and just > pick the highest power or lowest power mode that can provide that rate > based on the power_mode attribute. > > I wanted to suggest maybe adding some kind of noise attribute instead, > but I'm not sure how we could do that in a way using SI units since the > value would depend on so many things (at least V_REF voltage, filter type, > temperature and even the physical input). We considered the low_power/balanced/low_noise approach, but the customers typically use the datasheet alongside the driver and the datasheet explicitly uses the terms "low power", "median" and "fast" for the three modes. Abstracting them with different names in the sysfs attribute would create a confusion- the users would have to mentally translate between the two naming conventions. The noise attribute would not actually configure anything on a register level- it would purely be informational. Furthermore, noise performance is not solely determined by the power mode. There are other parameters (eg. filter mode) that has a significant impact. A power_mode attribute directly configures the hardware register and has a deterministic effect on the device. Jonathan, could we keep the power_mode as an attribute in this case?