From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.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 9A088306756 for ; Tue, 7 Jul 2026 01:38:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783388337; cv=none; b=aNmXtOuHemzoVdMT0T2h0QDfDFWsY+khkSJMOxnJu/FAXhEYbfRQds59NN1gK9x7TUdIt1CwB3lGFxpyniqHj43fjHggbrFByrcFWVuUhZh6yaSGVKjejSOy6sDeUKq1FXseqrrBA+xQKdHy7Bo/qf+WRXpF3O9g7Gk2++ByNxo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783388337; c=relaxed/simple; bh=GWqzWiq+j0RxHQzZhZDV6By8omBIwJBlTOY3h8xOhoo=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=Sl4Lzy4WilgKpRrAQJcJkHYS6iAivjAsDjxyyx8bsYrO+3Dowce1Cer+E9VWQ04YWRj8UN9fR8k6aI8QCkoMJyycGoPQDfaZs8TmORakzkdfvIE0U2lSnEFHNRvQIvJD5rsE8OSEzvRut6YW+Omjki5MUrys+p+0BG1w9OkLgls= 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=Qy87WceC; arc=none smtp.client-ip=209.85.221.176 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="Qy87WceC" Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-5bd742e0c20so2630027e0c.3 for ; Mon, 06 Jul 2026 18:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783388334; x=1783993134; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1LriMcSNJ5pcK00Rw56VbtN5AdDBaoG9VSgFiEqdgUk=; b=Qy87WceCbs+O9UDgYBNHcByygLc88G1jalNXMOOoS9SZIFvtoSbIbK2HagIJ65ikVu LL8QML5aZIDzIgrIFE5rQ2/xuAMKD71N8u7i9fYGT2LIl6MmUGJCYmbsSy3LtPMA7jln 2VsJy0xCaw3JgBkFDQIAenBrINm+GbjwW8GXjyAnU1LJnZLSIudFwgpb0Nr12iMdjum0 ukReE0spUVc/zK9gCVFUaBT//u5EpJvk0zB2UdoWYJCYPPjODpqrhL1ZFbWd0dczsFN4 39natcpHLPPV60dIZTgUHn5O12K6Ox7/wTVAXfZNxweKCNmnoUcoC6Awp2WJjcHn0dkS vmhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783388334; x=1783993134; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1LriMcSNJ5pcK00Rw56VbtN5AdDBaoG9VSgFiEqdgUk=; b=A4o8lIj8tvijY95kx/dFg93IFsHav+jfGZTPk3J8zLEa9bmDJhYKxmR6qO6zRfeHKY 4W1etbnmK3ofsfZWp3JScGzBfWPnowJZq7THRt/n7+IhG5fc8+epscnBR40pb4+4cd5l 3vvYUTIoRHJ/tEpdMyOxC4g2s0+E0pRiItEvEO3C+GOPaDnG3GB7hj/ssJDn/ivCATxB EfuwUpD8e3oActPGR5yKPQkBaWK2ezyNHFUVpw3GV6AtjNac+hVSNuAvNyEeesJbB+BD tuFoztWl1Jlc81VYTp3eWHR3xs9EjQwgt4DKoCAYiLQtwuopjkC0WiR5mo8E2rmqXjIv Bvog== X-Forwarded-Encrypted: i=1; AHgh+Rq4+pzg+RbjavPkuBJ6cmtjRuym4xKURJ+w1LMqvwnT1SQVWrV+3hgyhzxubnIn5ZXb34UNNPLHDVHPeHw=@vger.kernel.org X-Gm-Message-State: AOJu0Yzo7NIbBjoNtVL/LPCvFIn1fDcBe2mYsep5TeALd4BpSqheJfFL YVEiv0TzKnt09k1dsnAZSxcSC9VbqXkxnUoTz6UkDtA7JoRLt+J+4vN+ X-Gm-Gg: AfdE7ckDyz/FSX8ThlGxTHKZtWhcarI94a7Xd7airMwBzV9pHiNRAMMGlPYbSN69IOP yBPMbI6zVwa6jWxpgEQSHgcxcVbzuw9IRiifmdcf0ufpkvSQopsZI6EyrLlrbd4123tFKSvJdHf qhf0+IQEMDdAvArYGvYHalPfd2H7/NGfpAlu1U91FfAVuvx3/BwITt5LSnPRiqhuQDRkVGsOvLO xv77meoxyvFZrV1nsc5MYhrHO/dporGuV6iFsJ6C9AmX4le+XQOoTcre//NNOCgWXDJ6vSI26ZI /xHB2jKaeXuZAuxB377HAkXis7t0BGE78BlW1I4hzaXwYY8EVqu3vCC9U+1kLxHMiDdO21zjpml hcp3ePD8A2jukcT4IZ5we6V1S/MPAU/QAfUo2YMPImWS7DIIlaF8WrSnnqRLlYD+lkeljhCPXk7 hJlg0= X-Received: by 2002:a05:6122:3d4b:b0:5bb:d233:70bd with SMTP id 71dfb90a1353d-5be8974163emr1912443e0c.2.1783388334524; Mon, 06 Jul 2026 18:38:54 -0700 (PDT) Received: from localhost ([2800:bf0:82:11a2:7ac4:1f2:947b:2b6]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5be02934c13sm5894170e0c.3.2026.07.06.18.38.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2026 18:38:54 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 06 Jul 2026 20:38:45 -0500 Message-Id: Cc: "Kurt Borja" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , =?utf-8?q?Nuno_S=C3=A1?= , "Andy Shevchenko" , , , Subject: Re: [PATCH v2 5/7] iio: adc: ti-ads1262: Add conversion delay support From: "Kurt Borja" To: "Jonathan Cameron" , "David Lechner" X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260628-ads126x-v2-0-4b1b231325ba@gmail.com> <20260628-ads126x-v2-5-4b1b231325ba@gmail.com> <20260630015027.3afdfc3a@jic23-huawei> <20260701012026.29f18bf4@jic23-huawei> <8dd4bb6b-a83d-4584-8893-b56b8aaed973@baylibre.com> <20260706182317.64cb0a4c@jic23-huawei> In-Reply-To: <20260706182317.64cb0a4c@jic23-huawei> On Mon Jul 6, 2026 at 12:23 PM -05, Jonathan Cameron wrote: > On Mon, 6 Jul 2026 11:19:40 -0500 > David Lechner wrote: > >> On 6/30/26 7:20 PM, Jonathan Cameron wrote: >> > On Tue, 30 Jun 2026 13:44:49 -0500 >> > David Lechner wrote: >> > =20 >> >> On 6/30/26 12:23 PM, Kurt Borja wrote: =20 >> >>> On Mon Jun 29, 2026 at 7:50 PM -05, Jonathan Cameron wrote: =20 >> >>>> On Sun, 28 Jun 2026 00:36:06 -0500 >> >>>> Kurt Borja wrote: >> >>>> =20 >> >>>>> Expose the programmable conversion start delay as a per-channel >> >>>>> IIO_CHAN_INFO_CONVDELAY attribute. =20 >> >>>> Coversion delay was always a somewhere weird bit of ABI. >> >>>> What are the delays relative to in this case? >> >>>> Is this a device that does simultaneous sampling? Pictures >> >>>> suggest otherwise, and convdelay is currently only defined >> >>>> in that case. We might be able to extend it but it needs >> >>>> some thought. =20 >> >>> >> >>> The chip has a configurable internal conversion delay to allow for >> >>> external settling effects. See datasheet section 9.4.3 if you'd like= a >> >>> bit more details. =20 >> >> >> >> Since this depends on external components, it sounds like it belongs >> >> in the devicetree. I have the same feature in the chip I am working >> >> on and was just looking at this and plan to add it to the ti,ads112c1= 4 >> >> devicetree patch. >> >> >> >> This delay only applies to a "new conversion", i.e. when certain conf= ig >> >> registers change, and not every conversion, so isn't like the convdel= ay >> >> attribute. =20 >> >=20 >> > See settling-time-us in adc.yaml. I'd forgotten we had that ;) =20 >>=20 >> I got some more feedback on this and this may indeed be something we >> want to tune at runtime after all. >>=20 >> I'm not really sure where it fits in though. On AD112C14 that I am worki= ng >> on, the DELAY register value adds a delay (for settling time) in additio= n >> to some other intrinsic delays. I'm pretty sure ADS1262 is similar. It is! there is a fixed 52 usecs delay after starting conversions. >>=20 >> So one question is do we want a usespace control to be the total delay >> or just the additional delay? >>=20 > > Total I think. > >> And when the delay takes effect depends on other things. Normally the >> delay only happens before the first sample after any other parameters >> change. If we read the same channel again with the same config, then >> there won't be any added delay. But if input chopping is enabled, then >> this delay happens on every conversion. > > Hmm. That is awkward. I guess the best we could do is either to document > it as 'may be skipped if channel setup is unchanged either via explicit > channel or parameter change, or via chopping'. I kind of think of choppi= ng > as advanced channel sequencing - inX-inY being switched to inY-inX with a= scale > *=3D -1. Thinking about it this way, shouldn't there be userspace control for the chopping stuff too? Something like in_voltageY_chop_type, similar to the filter type. > >>=20 >> I'm a bit on the fence of if we should extend the definition of convdela= y >> for this or if we should propose a new settling time attribute. I'll hav= e >> to think about it some more. > Smells different enough that we shouldn't smash the two together. >>=20 >> Maybe something like in_voltageY_calibsettlingtime? > > calib might be reasonable if it was a tweak to a fixed settling time > and like other calib stuff would not necessarily have any scaling. > > If it's the whole thing and in seconds then in_voltageY_settlingtime=20 > should be enough I think. +1 for this. in_voltageY_settlingdelay might work too, as both our datasheets call it "delay". > > Jonathan > >>=20 >> > =20 >> >> =20 >> >>> >> >>> But you're right, I should at least also edit the ABI description of >> >>> this attribute. We can postpone this discussion for a future series. >> >>> =20 >> >>>> >> >>>> Jonathan =20 >> >>> =20 >> >> =20 >> > =20 >>=20 --=20 Thanks, ~ Kurt