From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (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 CCA5230E0D9 for ; Wed, 10 Dec 2025 04:08:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765339718; cv=none; b=ArtidTq36vBIOeJTHG5KN7SrQY82veDwXSOA3yKj1R599ZoDr+9g20ufLzkK5UukLa6qlT+mwMSNAO3hVAAPRe0t6LCoNcOl5odCKcZkG5F5DfaURwTopeoTbmSMmwns5yZzW31KmERDvgKPGoLB8fStTVs25YvjmXcNtuO4sKw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765339718; c=relaxed/simple; bh=Gr53fuTbHZKpl46q1LFj7gcfKtH2HbjrpK1Otwbijug=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=eAO1HRqw9Xy5tlWzCcX4FUqIDlvyBA1OK3j5mcWeVKX7DQ/CpWeQlCOedK8A57geFqD7vCh/upJYR+qFn7iBNo0BYTLG5Nq/6UO6jkuxxUC7FWWvOd24sf0QzRDx+DGOYr56SoCE4HbeylVS457x2qq9BzjZjRLohoHimIKifJc= 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=ZX3fWj0C; arc=none smtp.client-ip=209.85.222.44 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="ZX3fWj0C" Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-9371aca0a4dso3947097241.1 for ; Tue, 09 Dec 2025 20:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765339716; x=1765944516; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8j58EbJRehVD66NIXI6Vngeh4NEZg0BT3sgTrmPRCJg=; b=ZX3fWj0C7UAwfkoTgwzOWxF41qAJaP8U/Y9XUwZb/k19ylwNMaGjcGv4cFGuLiGRrk op6oAJWRbHjLGSIbkbcxgWs8wvDbSnal06XXuvaEQMjG3BAY/NvwEE5Vk6poG0AKnzdv 0MeZTDt8Einri/pVFJaGYB8e+nTbB0XqgE+ukTblDLgXNd2kp06u/5Za/FeLzGTjGKb3 vFpAALA2Unrevc3xA4Fr+/bJdBAgEBaBhzdiB7w4MduqlmAz7RzzLKFQ5ycdhJIHwT7M bMKhYlSK1JtkyCFwweFSmGk1xatuguTCjfDbrjMXJYVgxBvZhYg9JyWo67jJBDPA3Bmn Wn5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765339716; x=1765944516; h=in-reply-to:references:subject:cc:to:from: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=8j58EbJRehVD66NIXI6Vngeh4NEZg0BT3sgTrmPRCJg=; b=Pqvz9FRxWKdf6aAs9S+HMOFrjTSfvdpiNujcRvOp3aij68/CujjAG7sf5oXEnSlp+D NSRJqA4mrZ73pIGo0DHptCcEZ7FeHqOyzQ4SZ+k8tN3wTVHNbek+c1S7MI6hDx38sM19 E19I/sBdnqkt9+iJ8Cwyb/PvGrP8NumBiuNHFshHdcE5bI1eZUr3/nO1+zODrgnf9R9/ bUQg7H1LX9PIHrMlYLghtKLRMATZkgR5us+L3r/YENsCA2vb0OPCIoHZ9mal0xL9i0cs kjaFJaSXVOLQXLy34JQLhdQXX6HEUNwKN15acGH82L6vVK3oR4EfdOjHxRXjQ7/ZfcPU SNzQ== X-Forwarded-Encrypted: i=1; AJvYcCUQm8EPd6apMyPP2qrpjq7NfVfaeIE/8+q4IiaH0So7M0Esdvl4ERjjstqmMJENcwN7ocEHbUAY4PJhZiw=@vger.kernel.org X-Gm-Message-State: AOJu0YwLF31KvOGjM7zDN2pRRgKzKaC7okQJ9pUG6Z2EBuTZ2SKFX36m QVl1SH2o3WYMuEqebiHw9bxFwo4Jg1nuq7WPLyYk5cQ0ohAkpwqnY8sG X-Gm-Gg: AY/fxX4ArMn8owdCou/X+5AN3ycu9LuBxJFqxegZ9lyVqAHgHtp4pLIKh7ONpRaCUye kANHhF3ITinYTdiodCo9IIbOlh0rdv0m9CyUKGNU/YkubvXpmsQAmePpv6vejeJVDyJLTjjOK8x oRRnidIkjRfO4PiZIARdAyx898j0PpIkWWpnEf/fpqOvzYxbo64lNklsWQ9waqDgy0M01mAncNK wTJCVw1Pdjd5oUKv3txcqSvlDP115seLFirrIsLvKVYie3vWrNHpXsVOS7wKgag2EFroMF5LdbK gK2LPD0f5eJUhIJVKljJinvFLRnY2d6zDMamaBkEltuLaZsdxFoC4CNLPsX6CFrdLslVTG4r9R9 KxVw2/W/ePFaRzWj97Mh1ftLrZI4jAHBpFO5bNBA/0fKhiWzR9J2G8DeGzDq/THCbf7ApqHkLKT 1lzbPFll1Fvdwvsg== X-Google-Smtp-Source: AGHT+IHeJyww8xPuUv2NJf/IVFsizp5qbt8Bdk/UY3APTv8xhYUgPWJ1SWgJYbINgzgxJuiNKs4R1w== X-Received: by 2002:a05:6102:6b0a:b0:5e5:7055:66f5 with SMTP id ada2fe7eead31-5e571f2f71emr373127137.27.1765339715682; Tue, 09 Dec 2025 20:08:35 -0800 (PST) Received: from localhost ([2800:bf0:82:3d2:875c:6c76:e06b:3095]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-5e51068471asm7888292137.0.2025.12.09.20.08.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Dec 2025 20:08:35 -0800 (PST) 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: Tue, 09 Dec 2025 23:08:33 -0500 Message-Id: From: "Kurt Borja" To: "David Lechner" , "Kurt Borja" , "Jonathan Cameron" Cc: "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Tobias Sperling" , =?utf-8?q?Nuno_S=C3=A1?= , "Andy Shevchenko" , , , , "Jonathan Cameron" Subject: Re: [PATCH v6 2/2] iio: adc: Add ti-ads1018 driver X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20251204-ads1x18-v6-0-2ae4a2f8e90c@gmail.com> <20251204-ads1x18-v6-2-2ae4a2f8e90c@gmail.com> <20251206200721.5e683a83@jic23-huawei> <5b843df0-138e-4e2e-a70d-beb8a39ed85f@baylibre.com> <20251207195613.0e222b3a@jic23-huawei> <04aee30f-908b-4390-934a-e49990217d15@baylibre.com> In-Reply-To: <04aee30f-908b-4390-934a-e49990217d15@baylibre.com> On Mon Dec 8, 2025 at 11:00 AM -05, David Lechner wrote: > On 12/7/25 10:06 PM, Kurt Borja wrote: >> On Sun Dec 7, 2025 at 2:56 PM -05, Jonathan Cameron wrote: >>> On Sun, 7 Dec 2025 11:12:51 -0600 >>> David Lechner wrote: >>> >>>> On 12/7/25 10:02 AM, Kurt Borja wrote: >>>>> On Sat Dec 6, 2025 at 3:07 PM -05, Jonathan Cameron wrote: =20 >>>>>> On Thu, 04 Dec 2025 13:01:28 -0500 >>>>>> Kurt Borja wrote: >>>>>> =20 >>>>>>> Add ti-ads1018 driver for Texas Instruments ADS1018 and ADS1118 SPI >>>>>>> analog-to-digital converters. >>>>>>> >>>>>>> These chips' MOSI pin is shared with a data-ready interrupt. Defini= ng >>>>>>> this interrupt in devicetree is optional, therefore we only create = an >>>>>>> IIO trigger if one is found. >>>>>>> >>>>>>> Handling this interrupt requires some considerations. When enabling= the >>>>>>> trigger the CS line is tied low (active), thus we need to hold >>>>>>> spi_bus_lock() too, to avoid state corruption. This is done inside = the >>>>>>> set_trigger_state() callback, to let users use other triggers witho= ut >>>>>>> wasting a bus lock. >>>>>>> >>>>>>> Signed-off-by: Kurt Borja =20 >>>>> >>>>> ... >>>>> =20 >>>>>>> +#define ADS1018_VOLT_CHAN(_index, _chan, _realbits) { \ >>>>>>> + .type =3D IIO_VOLTAGE, \ >>>>>>> + .channel =3D _chan, \ >>>>>>> + .scan_index =3D _index, \ >>>>>>> + .scan_type =3D { \ >>>>>>> + .sign =3D 's', \ >>>>>>> + .realbits =3D _realbits, \ >>>>>>> + .storagebits =3D 16, \ >>>>>>> + .shift =3D 16 - _realbits, \ >>>>>>> + .endianness =3D IIO_BE, \ >>>>>>> + }, \ >>>>>>> + .info_mask_separate =3D BIT(IIO_CHAN_INFO_RAW) | \ >>>>>>> + BIT(IIO_CHAN_INFO_SCALE) | \ >>>>>>> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \ =20 >>>>>> >>>>>> What motivates per channel sampling frequency? >>>>>> >>>>>> Given you have to write it each time you configure I guess it doesn'= t matter much >>>>>> either way. =20 >>>>> >>>>> I guess making it shared by all is simpler too, so I'll go with that. >>>>> =20 >>>> Just keep in mind that if there is ever some use case we don't know >>>> about that would require a different rate per channel, we can't change >>>> it without breaking usespace. Once the decision is made, we are >>>> locked in. Keeping it per-channel seems more future-proof to me. >>> >>> Only way I can think of that might cause that to matter would be >>> if the complex dance to avoid the onehot buffer restriction is added. >>> Given you gave this response I went looking and that might make >>> sense as an enhancement as the SPI protocol would allow a crafted messa= ge >>> sequence to do this efficiently. Extension of figure 15 where first me= ssage >>> sets config and after that they read out channel and set config for nex= t one. >>=20 >> This is possible, yes. But would the timestamp even make sense in this >> case? Even in the fastest sampling rate, we would have to wait at least >> 1 ms for each channel and the timestamp would become stale. >>=20 >> That was my reasoning for using the onehot restriction. >>=20 >> Is that acceptable? Or maybe we would need to disallow the timestamp >> channel if more than one channel is selected? > > Yes. We have pretty much the same situation with timestamps on every > other ADC. The timestamp is usually when one full set of samples is > triggered. Not when the actual individual conversions are performed. This is good to know for future patches or drivers. Thanks! --=20 ~ Kurt