From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 49D9038AC7D for ; Wed, 15 Apr 2026 08:20:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776241213; cv=none; b=UOE6JtmQb2D4qEG8TbqSIRwi9GzdLfs0oT8FIyeo+4eJvfVy42ZIKAQw9B7JMnRyuWuoalasqDndex172/dbXpZzYYhgtDhQqDHLUHWA1l8rhhoKtDTtxWPIO29GyI4DeF/ULlWuHA3VChASSxrrbdMe7gVO7xJLcLI8bDL9aC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776241213; c=relaxed/simple; bh=AS429itr7wbpGuNOk5jL7MlDnLt1qmHnn3vRkHB1nVk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W2RG+Gmjy98ZclUNjW98CGCra9WepxOCO1i5XA/grklvlioGHJpbfljfFYbXAOyydfb3IVZe4ugr/kGi+OImdlfclLg4j/zMB/DHLoXy7q/ngwsrgZign0PTh8yPDkyiiBWp0AS3zv1GLIIpxxhSHjvAMdSqOJCiKvY5KjxvjTw= 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=O0k3KIXT; arc=none smtp.client-ip=209.85.128.52 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="O0k3KIXT" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4852b81c73aso60816505e9.3 for ; Wed, 15 Apr 2026 01:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776241211; x=1776846011; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=0otFmE3OfgX1ocRffAsBD3VgKhSHJKmOocoLMY68w2Q=; b=O0k3KIXTrRRTXq7ITdfsgz4CqfxhnnsMH1eB/RPf8ZrOiN+jGV7dxT1ik7p8SNFD4O jI4fSaTYA40PH2meeWkBVio+RGdNX7bS+9NrufjDQektPsXipRcOjrxVkTI/J14sF9ht d77eO62p8G4jsUCwh4bijIM1BiLwlzJL1GQg4D0UumwndDvsJ/ToV/MMIzQu3U94vpzW d+h8ES2B1K9GtcErvIv2vEtf4/CKmgUtbstgEbZNpyD6/mIEhXR3MbOkWvMXBVrzr645 6PG1yiI5JiN3JouibmvfbLp9TGVvQyIoh/jCNDHZu4Z1q6tTGGVK4XR2rFetxvd9dSce hm+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776241211; x=1776846011; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0otFmE3OfgX1ocRffAsBD3VgKhSHJKmOocoLMY68w2Q=; b=s7rfHi1ZhNF9V654lNtVxi2gX1b71f34N4zBN8XBgRaivxN+Wv0T9lWx+uT8U28rKH i96vC70j3ft+AbFBKU0rQL5wh70Z2q2SwRRizN7ioQhoOxyF7OEPWkfI3oxU8RlgPNK0 HMd1Yg0jzAHWBb5lY4hEUnucqZKUV4tNQvN3USFnbkkKyNNXSawpTsUG5TUYAG8PqtcY Xw+A7ennMMxOEFSs6G9tYsP6WofFmKFCz6d3or4TLlYDAMCMH0iYWdPDg0hzDDeTWG6v mUxowfhQ2AxEzjld3fMUqsTAuVrT0+tFe7pJbjA4n4n9hz4yWPkE4SymWervWPm/uMrN 3IlQ== X-Forwarded-Encrypted: i=1; AFNElJ9oe+Yl15j58ADmt49UUfpxdELDuPpkY4S1B9069b6rOBeuuYsuC+fMGJK7LQChvmB+yheHZW2/gfg=@vger.kernel.org X-Gm-Message-State: AOJu0YxbneMTe84oj3Ha84g5sOWTkYJZ1sg22WLZ6RDIXo8ubE12E3Vk EmFLpjvOhaDzQTlZSUGdNW2k6j+kfT49ATk9jqivSLSWcZogQoBnAuFk X-Gm-Gg: AeBDiesr97Dyfwpwbz1Vn86Ot1djEbmaCT2B0eFHImiS7yw7RysyDg4/IELgLY+v1jC kXfbovREarpeIo4FD+WR+tfpyyULq7oQwG9s3+GUDYpwdRArY7/UNsXdI0qcEUwJ0QazPeGrCVM nWFC8cz/JTsphCen7LUlIFxIrR6mpNrHnZJzT0dbakcXTkqL8SCaPsSYcODycRCRxs2NinuCJiD j4HJD0BcbtzqIad6yJalECXvEXW/YEPbc5yb8brcGNx83zERkrL1o5bW1xYUIkFi5xBDA+XV1Bh Prc4UVMsjyjNZ7qsXAv9C6/uWb5hsVnyR9ytvMIYX2LOBV4D9XC862yeozOHeRECHEmVW3dtML5 R6HPJlZQ0P8cnI8gVUatsrAHteAjLqsMRAQO0wA74uLrJM7tMYpkMeeUH6U5GjCPnvuG919s5j+ fjtJ5L5aMO2zfz/NSTHZScLcg= X-Received: by 2002:a05:600c:c0dc:b0:488:aa3d:fab1 with SMTP id 5b1f17b1804b1-488d68364f2mr188027275e9.17.1776241210420; Wed, 15 Apr 2026 01:20:10 -0700 (PDT) Received: from nsa ([45.94.208.74]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43ead3ebaf1sm2980604f8f.33.2026.04.15.01.20.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 01:20:09 -0700 (PDT) Date: Wed, 15 Apr 2026 09:20:59 +0100 From: Nuno =?utf-8?B?U8Oh?= To: David Lechner Cc: "Sabau, Radu bogdan" , Jonathan Cameron , Lars-Peter Clausen , "Hennerich, Michael" , "Sa, Nuno" , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Liam Girdwood , Mark Brown , Linus Walleij , Bartosz Golaszewski , Philipp Zabel , Jonathan Corbet , Shuah Khan , "linux-iio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "linux-doc@vger.kernel.org" Subject: Re: [PATCH v7 5/6] iio: adc: ad4691: add oversampling support Message-ID: References: <20260409-ad4692-multichannel-sar-adc-driver-v7-0-be375d4df2c5@analog.com> <20260409-ad4692-multichannel-sar-adc-driver-v7-5-be375d4df2c5@analog.com> <742b1821-9103-414e-a860-c2e8d5406e35@baylibre.com> <20260412185821.739e477f@jic23-huawei> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Apr 14, 2026 at 10:02:31AM -0500, David Lechner wrote: > On 4/14/26 9:25 AM, Sabau, Radu bogdan wrote: > > > > > >> -----Original Message----- > >> From: Jonathan Cameron > >> Sent: Sunday, April 12, 2026 8:58 PM > >> To: David Lechner > >> Cc: Sabau, Radu bogdan ; Lars-Peter Clausen > >> ; Hennerich, Michael ; > >> Sa, Nuno ; Andy Shevchenko ; > >> Rob Herring ; Krzysztof Kozlowski ; > >> Conor Dooley ; Uwe Kleine-König > >> ; Liam Girdwood ; Mark Brown > >> ; Linus Walleij ; Bartosz > >> Golaszewski ; Philipp Zabel ; > >> Jonathan Corbet ; Shuah Khan > >> ; linux-iio@vger.kernel.org; > >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > >> pwm@vger.kernel.org; linux-gpio@vger.kernel.org; linux-doc@vger.kernel.org > >> Subject: Re: [PATCH v7 5/6] iio: adc: ad4691: add oversampling support > >> > >> [External] > >> > >> On Fri, 10 Apr 2026 16:15:20 -0500 > >> David Lechner wrote: > >> > >>> On 4/9/26 10:28 AM, Radu Sabau via B4 Relay wrote: > >>>> From: Radu Sabau > >>>> > >>>> Add per-channel oversampling ratio (OSR) support for CNV burst mode. > >>>> The accumulator depth register (ACC_DEPTH_IN) is programmed with the > >>>> selected OSR at buffer enable time and before each single-shot read. > >>>> > >>>> Supported OSR values: 1, 2, 4, 8, 16, 32. > >>>> > >>>> Introduce AD4691_MANUAL_CHANNEL() for manual mode channels, > >> which do > >>>> not expose the oversampling ratio attribute since OSR is not applicable > >>>> in that mode. A separate manual_channels array is added to > >>>> struct ad4691_channel_info and selected at probe time; offload paths > >>>> reuse the same arrays with num_channels capping access before the soft > >>>> timestamp entry. > >>>> > >>>> The reported sampling frequency accounts for the active OSR: > >>>> effective_freq = oscillator_freq / osr > >>> > >>> Technically, the way this is implemented is fine according to IIO ABI > >>> rules. Writing any attribute can cause others to change. It does > >>> introduce a potential pitfall though. Currently, changing the OSR will > >>> change the sampling frequency, so you have to always write > >> oversampling_ratio > >>> first, then write sampling_frequency to get what you asked for. If you want > >>> to change the OSR and keep the same sample rate, you still have to write > >> both > >>> attributes again. > >>> > >>> In other drivers, I've implemented it so that the requested sampling > >> frequency > >>> is stored any you always get the closest sampling frequency available based > >> on > >>> the oversampling ratio. This way, it doesn't matter which order you write > >>> the attributes. In that case, the actual periodic trigger source isn't set up > >>> until we actually start sampling. > >>> > >> Agreed. This is more intuitive. Now generally the userspace should > >> be sanity checking the value anyway as limitations may mean the new > >> sampling frequency is not particularly close to the original one but > >> at least it increases the chances of getting the expected value somewhat! > >> > >> So to me this is a nice useability improvement given the code to implement > >> it tends not to be too complex. > >> > > > > Hi David, Jonathan, > > > > What I understand from this is that the osr should be taken into account when writing > > the sampling frequency as well, right? Here's what I understand: > > > > If the user wants a 125kHz freq with 4 OSR, then when internal osc will be written > > to 500kHz before single-shot read, buffer preenable/postenable. > > However, if the user wants a 500kHz frequency with 4 OSR, that would mean a 2MHz > > Internal osc freq, which is impossible. > > It is up to the user to request something that is legal. They should know this > from reading the datasheet. > > > > > More than this, if the OSR is 32 the maximum effective rate would be 31250, so 25kHz > > would make it the closes available one. If the user would select 1MHz from the available > > list it would be weird I would say. So perhaps a solution for this is to display the avail list > > depending on the set OSR value. > > Yes, the available list should reflect the current state of any other attributes > that affect it. IMO, the above makes total sense to me. - Nuno Sá > > > > > Linking the two together is perhaps wrong to begin with from my end, since in this > > driver's case, the per-channel sampling frequency is controlled by the internal oscillator > > which has static available values. So perhaps sampling frequency should be separate, and > > OSR separate as well, which would make everything cleaner. > > > > Indeed, the effective rate is changed by OSR, but perhaps that is something the user > > should be aware of, since the sampling frequency is the rate at which the channel samples > > (1 sample per period) and OSR is how many times the channel samples upon a final sample > > is to be read. The user already has to take this into account when setting the buffer > > sampling frequency, so it would make sense to take this into account here too. > > We can't change the definition of the IIO ABI just to make one driver simpler > to implement. The OSR and sample rate can't be completely independent. > > If you want to leave it the way it is currently implemented though, that is fine. > > > > > Please let me know you thoughts on this, > > Radu >