| Message ID | 23f5ee3e3bf7179930d66c720d5c4c33cdbe8366.1740421248.git.mazziesaccount@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | Support ROHM BD79124 ADC | expand |
On 2/24/25 12:33 PM, Matti Vaittinen wrote: > There are ADC ICs which may have some of the AIN pins usable for other > functions. These ICs may have some of the AIN pins wired so that they > should not be used for ADC. > > (Preferred?) way for marking pins which can be used as ADC inputs is to > add corresponding channels@N nodes in the device tree as described in > the ADC binding yaml. I think "preferred?" is the key question here. Currently, it is assumed that basically all IIO bindings have channels implicitly even if the binding doesn't call them out. It just means that there is nothing special about the channel that needs to be documented, but the channel is still there. Similarly, on several drivers we added recently that make use of adc.yaml (adi,ad7380, adi,ad4695) we wrote the bindings with the intention that if a channel was wired in the default configuration, then you would just omit the channel node for that input pin. Therefore, this helper couldn't be used by these drivers since we always have a fixed number of channels used in the driver regardless of if there are explicit channel nodes in the devicetree or not. In my experience, the only time we don't populate all available channels on an ADC, even if not used, is in cases like differential chips where any two inputs can be mixed and matched to form a channel. Some of these, like adi,ad7173-8 would have 100s or 1000s of channels if we tried to include all possible channels. In those cases, we make an exception and use a dynamic number of channels based on the devicetree. But for chips that have less than 20 total possible channels or so we've always provided all possible channels to userspace. It makes writing userspace software for a specific chip easier if we can always assume that chip has the same number of channels. > > Add couple of helper functions which can be used to retrieve the channel > information from the device node. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> >
Hi David, Thanks for taking a look at this :) On 26/02/2025 02:26, David Lechner wrote: > On 2/24/25 12:33 PM, Matti Vaittinen wrote: >> There are ADC ICs which may have some of the AIN pins usable for other >> functions. These ICs may have some of the AIN pins wired so that they >> should not be used for ADC. >> >> (Preferred?) way for marking pins which can be used as ADC inputs is to >> add corresponding channels@N nodes in the device tree as described in >> the ADC binding yaml. > > I think "preferred?" is the key question here. Currently, it is assumed > that basically all IIO bindings have channels implicitly even if the > binding doesn't call them out. It just means that there is nothing > special about the channel that needs to be documented, but the channel > is still there. I think this works well with the ADCs which have no other purpose for the pins but the ADC. The BD79124 (and some others) do allow muxing the ADC input pins for other purposes. There the DT bindings with nothing but the "reg" are relevant, and channels can't be trusted to just be there without those.. > Similarly, on several drivers we added recently that make use of adc.yaml > (adi,ad7380, adi,ad4695) we wrote the bindings with the intention that > if a channel was wired in the default configuration, then you would just > omit the channel node for that input pin. Therefore, this helper couldn't > be used by these drivers since we always have a fixed number of channels > used in the driver regardless of if there are explicit channel nodes in > the devicetree or not. I think this works with the ICs where channels, indeed, always are there. But this is not the case with _all_ ICs. And in order to keep the consistency I'd actually required that if channels are listed in the DT, then _all_ the channels must be listed. Else it becomes less straightforward for people to understand how many channels there are based on the device tree. I believe this was also proposed by Jonathan during the v1 review: > > Hmm. That'd mean the ADC channels _must_ be defined in DT in order to be > > usable(?) Well, if this is the usual way, then it should be well known > > by users. Thanks. > > Yes. We basically have two types of binding wrt to channels. > 1) Always there - no explicit binding, but also no way to describe > anything specific about the channels. > 2) Subnode per channel with stuff from adc.yaml and anything device > specific. Only channels that that have a node are enabled. > > There are a few drivers that for historical reasons support both > options with 'no channels' meaning 'all channels'. https://lore.kernel.org/all/20250201162631.2eab9a9a@jic23-huawei/ > In my experience, the only time we don't populate all available channels > on an ADC, even if not used, is in cases like differential chips where > any two inputs can be mixed and matched to form a channel. Some of these, > like adi,ad7173-8 would have 100s or 1000s of channels if we tried to > include all possible channels. In those cases, we make an exception and > use a dynamic number of channels based on the devicetree. But for chips > that have less than 20 total possible channels or so we've always > provided all possible channels to userspace. It makes writing userspace > software for a specific chip easier if we can always assume that chip > has the same number of channels. In any exception to this rule of describing all channels in DT should just avoid using these helpers and do things as they're done now. No one is forced to use them. But I am not really sure why would you not describe all the channels in the device-tree for ICs with less than 20 channels? I'd assume that if the channels are unconditionally usable in the hardware, then they should be in DT as well(?) >> Add couple of helper functions which can be used to retrieve the channel >> information from the device node. >> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> >> Yours, -- Matti
On 2/26/25 12:28 AM, Matti Vaittinen wrote: > Hi David, > > Thanks for taking a look at this :) > > On 26/02/2025 02:26, David Lechner wrote: >> On 2/24/25 12:33 PM, Matti Vaittinen wrote: >>> There are ADC ICs which may have some of the AIN pins usable for other >>> functions. These ICs may have some of the AIN pins wired so that they >>> should not be used for ADC. >>> >>> (Preferred?) way for marking pins which can be used as ADC inputs is to >>> add corresponding channels@N nodes in the device tree as described in >>> the ADC binding yaml. >> >> I think "preferred?" is the key question here. Currently, it is assumed >> that basically all IIO bindings have channels implicitly even if the >> binding doesn't call them out. It just means that there is nothing >> special about the channel that needs to be documented, but the channel >> is still there. > > I think this works well with the ADCs which have no other purpose for the pins but the ADC. The BD79124 (and some others) do allow muxing the ADC input pins for other purposes. There the DT bindings with nothing but the "reg" are relevant, and channels can't be trusted to just be there without those.. Makes sense. > >> Similarly, on several drivers we added recently that make use of adc.yaml >> (adi,ad7380, adi,ad4695) we wrote the bindings with the intention that >> if a channel was wired in the default configuration, then you would just >> omit the channel node for that input pin. Therefore, this helper couldn't >> be used by these drivers since we always have a fixed number of channels >> used in the driver regardless of if there are explicit channel nodes in >> the devicetree or not. > > I think this works with the ICs where channels, indeed, always are there. But this is not the case with _all_ ICs. And in order to keep the consistency I'd actually required that if channels are listed in the DT, then _all_ the channels must be listed. Else it becomes less straightforward for people to understand how many channels there are based on the device tree. I believe this was also proposed by Jonathan during the v1 review: > >> > Hmm. That'd mean the ADC channels _must_ be defined in DT in order to be >> > usable(?) Well, if this is the usual way, then it should be well known >> > by users. Thanks. >> >> Yes. We basically have two types of binding wrt to channels. >> 1) Always there - no explicit binding, but also no way to describe >> anything specific about the channels. >> 2) Subnode per channel with stuff from adc.yaml and anything device >> specific. Only channels that that have a node are enabled. >> Hmm... does that mean we implemented it wrong on ad7380 and ad4695? >> There are a few drivers that for historical reasons support both >> options with 'no channels' meaning 'all channels'. > > https://lore.kernel.org/all/20250201162631.2eab9a9a@jic23-huawei/ > >> In my experience, the only time we don't populate all available channels >> on an ADC, even if not used, is in cases like differential chips where >> any two inputs can be mixed and matched to form a channel. Some of these, >> like adi,ad7173-8 would have 100s or 1000s of channels if we tried to >> include all possible channels. In those cases, we make an exception and >> use a dynamic number of channels based on the devicetree. But for chips >> that have less than 20 total possible channels or so we've always >> provided all possible channels to userspace. It makes writing userspace >> software for a specific chip easier if we can always assume that chip >> has the same number of channels. > > In any exception to this rule of describing all channels in DT should just avoid using these helpers and do things as they're done now. No one is forced to use them. But I am not really sure why would you not describe all the channels in the device-tree for ICs with less than 20 channels? I'd assume that if the channels are unconditionally usable in the hardware, then they should be in DT as well(?) I devicetree, I think the tendency is to be less verbose and only add properties/nodes when there is something that is not the usual case. Default values are chosen to be the most usual case so we don't have to write so much in the .dts. > >>> Add couple of helper functions which can be used to retrieve the channel >>> information from the device node. >>> >>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> >>> > > Yours, > -- Matti
On 26/02/2025 18:10, David Lechner wrote: > On 2/26/25 12:28 AM, Matti Vaittinen wrote: >> Hi David, >> >> Thanks for taking a look at this :) >> >> On 26/02/2025 02:26, David Lechner wrote: >>> On 2/24/25 12:33 PM, Matti Vaittinen wrote: ... >> >>> Similarly, on several drivers we added recently that make use of adc.yaml >>> (adi,ad7380, adi,ad4695) we wrote the bindings with the intention that >>> if a channel was wired in the default configuration, then you would just >>> omit the channel node for that input pin. Therefore, this helper couldn't >>> be used by these drivers since we always have a fixed number of channels >>> used in the driver regardless of if there are explicit channel nodes in >>> the devicetree or not. >> >> I think this works with the ICs where channels, indeed, always are there. But this is not the case with _all_ ICs. And in order to keep the consistency I'd actually required that if channels are listed in the DT, then _all_ the channels must be listed. Else it becomes less straightforward for people to understand how many channels there are based on the device tree. I believe this was also proposed by Jonathan during the v1 review: >> >>>> Hmm. That'd mean the ADC channels _must_ be defined in DT in order to be >>>> usable(?) Well, if this is the usual way, then it should be well known >>>> by users. Thanks. >>> >>> Yes. We basically have two types of binding wrt to channels. >>> 1) Always there - no explicit binding, but also no way to describe >>> anything specific about the channels. >>> 2) Subnode per channel with stuff from adc.yaml and anything device >>> specific. Only channels that that have a node are enabled. >>> > > Hmm... does that mean we implemented it wrong on ad7380 and ad4695? I believe this is a question to Jonathan. With my ADC-driver experience I am not the person to answer this :) _If_ I commented something to this, I would say that: "I believe, this question is a good example of why providing helpers is so powerful. In my experience, when we provide helpers, then there will be a 'de facto' way of doing things, which improves consistency". But as I feel I'm on the verge of stepping on someones toes (and I am really the novice on this area), I won't say that comment out loud. >>> There are a few drivers that for historical reasons support both >>> options with 'no channels' meaning 'all channels'. >> >> https://lore.kernel.org/all/20250201162631.2eab9a9a@jic23-huawei/ >> >>> In my experience, the only time we don't populate all available channels >>> on an ADC, even if not used, is in cases like differential chips where >>> any two inputs can be mixed and matched to form a channel. Some of these, >>> like adi,ad7173-8 would have 100s or 1000s of channels if we tried to >>> include all possible channels. In those cases, we make an exception and >>> use a dynamic number of channels based on the devicetree. But for chips >>> that have less than 20 total possible channels or so we've always >>> provided all possible channels to userspace. It makes writing userspace >>> software for a specific chip easier if we can always assume that chip >>> has the same number of channels. >> >> In any exception to this rule of describing all channels in DT should just avoid using these helpers and do things as they're done now. No one is forced to use them. But I am not really sure why would you not describe all the channels in the device-tree for ICs with less than 20 channels? I'd assume that if the channels are unconditionally usable in the hardware, then they should be in DT as well(?) > > I devicetree, I think the tendency is to be less verbose and only add > properties/nodes when there is something that is not the usual case. > Default values are chosen to be the most usual case so we don't have > to write so much in the .dts. On the other hand, I've received comments from the DTS people to expose all HW blocks in the bindings. AFAIR, for example, marking power-supplies as 'optional' in bindings is frowned upon, because they are in the HW whether the SW needs to control them or not. Hence I think marking either all or no channels in dt should be the way to go - but my thinking is not done based on the years of experience on ADCs! >>>> Add couple of helper functions which can be used to retrieve the channel >>>> information from the device node. >>>> >>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> >>>> >> >> Yours, >> -- Matti >
On Thu, 27 Feb 2025 09:46:06 +0200 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On 26/02/2025 18:10, David Lechner wrote: > > On 2/26/25 12:28 AM, Matti Vaittinen wrote: > >> Hi David, > >> > >> Thanks for taking a look at this :) > >> > >> On 26/02/2025 02:26, David Lechner wrote: > >>> On 2/24/25 12:33 PM, Matti Vaittinen wrote: > > ... > > >> > >>> Similarly, on several drivers we added recently that make use of adc.yaml > >>> (adi,ad7380, adi,ad4695) we wrote the bindings with the intention that > >>> if a channel was wired in the default configuration, then you would just > >>> omit the channel node for that input pin. Therefore, this helper couldn't > >>> be used by these drivers since we always have a fixed number of channels > >>> used in the driver regardless of if there are explicit channel nodes in > >>> the devicetree or not. > >> > >> I think this works with the ICs where channels, indeed, always are there. But this is not the case with _all_ ICs. And in order to keep the consistency I'd actually required that if channels are listed in the DT, then _all_ the channels must be listed. Else it becomes less straightforward for people to understand how many channels there are based on the device tree. I believe this was also proposed by Jonathan during the v1 review: > >> > >>>> Hmm. That'd mean the ADC channels _must_ be defined in DT in order to be > >>>> usable(?) Well, if this is the usual way, then it should be well known > >>>> by users. Thanks. So there is some history here that complicates things. 1) Originally we always provided all channels. Easy case :) 2) Along came SoC ADC users who were unhappy with this not so much because of the case Matti hit where the channel can be something else but more because it's not unusual to either not wire up some pins on an SoC or there are multiple packages that we don't otherwise distinguish (as no software differences really) in which some internal pins never reach the ones on the package. Various solutions initially existed for this (you can find things like xxx,channels properties in some bindings.) 3) Then along came devices where we wanted per channel config. There were some 'interesting' bindings for that as well for a while but eventually we decided on channel nodes when needed. Those always allowed drivers to supply extra channels that didn't have nodes though (that's a driver /binding choice and motivated somewhat by whether the unwired pin thing matters - there are ADC package variants where this happens but it is rare unlike for SoCs where it seems to be common). From this discussion it occurs to me that we maybe want to make sure that binding docs state what is expected here clearly. If there is a concept of a 'default' for missing channel nodes then we need to say what it is. Property defaults will give us most of that but don't cover everything. 4) Now we had channel nodes we can also use them for (2). In those cases on a device specific case we allow for channels that don't have nodes to be hidden. There is often a fallback for this which is more about how bindings evolved (sure they shouldn't evolve but they do unfortunately). In those cases, no channel nodes == all channel nodes with default settings. > >>> > >>> Yes. We basically have two types of binding wrt to channels. > >>> 1) Always there - no explicit binding, but also no way to describe > >>> anything specific about the channels. > >>> 2) Subnode per channel with stuff from adc.yaml and anything device > >>> specific. Only channels that that have a node are enabled. > >>> > > > > Hmm... does that mean we implemented it wrong on ad7380 and ad4695? > > I believe this is a question to Jonathan. With my ADC-driver experience > I am not the person to answer this :) > > _If_ I commented something to this, I would say that: "I believe, this > question is a good example of why providing helpers is so powerful. In > my experience, when we provide helpers, then there will be a 'de facto' > way of doing things, which improves consistency". But as I feel I'm on > the verge of stepping on someones toes (and I am really the novice on > this area), I won't say that comment out loud. Problem is always 'history'. We already have a bunch of drivers doing what the parts David called out do. The bindings are clear and ultimately it is a bit device specific to whether missing nodes logically should default to default parameters or be hidden. In some cases there are natural defaults, in others not even close as we have fully flexible MUXes in front of differential ADCs and can in theory configure far more combinations than we even have pins for. So today the situation is we have all the options in tree and we aren't really in a position to drop any of them: a) custom bindings to configure channels - lots of these :( b) everything on if no channel nodes. Maybe everything on always. c) channel nodes necessary for a channel to exist. If I were starting all this again we'd probably reduce the options but too late now :( Only thing I'd request is if a binding uses channel nodes at all. It should be possible to provide all nodes - whether or not some are just the defaults. That way we can advise writers of bindings to provide all the channels they want to use. The other cases then become a case of whether they get more channels than expected, but never that some they want aren't there! A binding that didn't do this wouldn't be wrong, it would just mean the writer read the binding doc more carefully and knows what is expected for this device rather than more generally. There are some 'interesting' is it broken ABI backwards compatibility questions when we retrofit channel nodes into a binding. In those cases we can't hide non specified nodes as it would mean channels disappear that in an earlier kernel were present. In theory that should never be a problem but not all userspace code is going to be sufficient careful to not be disrupted by channel number changes. Even this I think we broke once or twice because of cases like the one Matti has where they are multipurpose pins on some chip variant we didn't know about when the driver was written. Jonathan > > >>> There are a few drivers that for historical reasons support both > >>> options with 'no channels' meaning 'all channels'. > >> > >> https://lore.kernel.org/all/20250201162631.2eab9a9a@jic23-huawei/ > >> > >>> In my experience, the only time we don't populate all available channels > >>> on an ADC, even if not used, is in cases like differential chips where > >>> any two inputs can be mixed and matched to form a channel. Some of these, > >>> like adi,ad7173-8 would have 100s or 1000s of channels if we tried to > >>> include all possible channels. In those cases, we make an exception and > >>> use a dynamic number of channels based on the devicetree. But for chips > >>> that have less than 20 total possible channels or so we've always > >>> provided all possible channels to userspace. It makes writing userspace > >>> software for a specific chip easier if we can always assume that chip > >>> has the same number of channels. > >> > >> In any exception to this rule of describing all channels in DT should just avoid using these helpers and do things as they're done now. No one is forced to use them. But I am not really sure why would you not describe all the channels in the device-tree for ICs with less than 20 channels? I'd assume that if the channels are unconditionally usable in the hardware, then they should be in DT as well(?) > > > > I devicetree, I think the tendency is to be less verbose and only add > > properties/nodes when there is something that is not the usual case. > > Default values are chosen to be the most usual case so we don't have > > to write so much in the .dts. > > On the other hand, I've received comments from the DTS people to expose > all HW blocks in the bindings. AFAIR, for example, marking > power-supplies as 'optional' in bindings is frowned upon, because they > are in the HW whether the SW needs to control them or not. Hence I think > marking either all or no channels in dt should be the way to go - but my > thinking is not done based on the years of experience on ADCs! Even for power supplies there is a difference between the binding doc saying they are there and what we do if they aren't (which is assume a stub regulator representing an non controllable / unknowable power supply is sufficient). Also for power supplies there isn't really a 'default' to use so it doesn't really work as a comparison. Hindsight is a wonderful thing. I'm not sure on what policy we should have gone for, but now we are kind of stuck with this slightly messy situation. Helper wise if it expands usefulness we may want a bool parameter to say if we skip the missing or not + make sure a max expected channel is provided (might already be - I didn't check!) Jonathan > > >>>> Add couple of helper functions which can be used to retrieve the channel > >>>> information from the device node. > >>>> > >>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > >>>> > >> > >> Yours, > >> -- Matti > > >
On Mon, 24 Feb 2025 20:33:16 +0200 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > There are ADC ICs which may have some of the AIN pins usable for other > functions. These ICs may have some of the AIN pins wired so that they > should not be used for ADC. > > (Preferred?) way for marking pins which can be used as ADC inputs is to > add corresponding channels@N nodes in the device tree as described in > the ADC binding yaml. I think it's worth exploring if we can tweak this slightly to make that something a driver specifies. Either skip the unspecified or fill them with default values depending on a parameter. Would make this code cover the existing cases better. Might be a little fiddly as we'd want to maintain ordering so the code would need to index slightly differently. I've not tried it so maybe not worth it for now. > > Add couple of helper functions which can be used to retrieve the channel > information from the device node. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > > --- > Revision history: > v3 => v4: > - Drop diff-channel support > - Drop iio_adc_device_channels_by_property() > - Add IIO_DEVICE namespace > - Move industrialio-adc.o to top of the Makefile > - Some styling as suggested by Andy > - Re-consider included headers > v2 => v3: Mostly based on review comments by Jonathan > - Support differential and single-ended channels > - Rename iio_adc_device_get_channels() as > iio_adc_device_channels_by_property() > - Improve spelling > - Drop support for cases where DT comes from parent device's node > - Decrease loop indent by reverting node name check conditions > - Don't set 'chan->indexed' by number of channels to keep the > interface consistent no matter how many channels are connected. > - Fix ID range check and related comment > RFC v1 => v2: > - New patch > > iio: adc: helper: drop headers > --- > drivers/iio/adc/Kconfig | 3 + > drivers/iio/adc/Makefile | 2 + > drivers/iio/adc/industrialio-adc.c | 89 ++++++++++++++++++++++++++++++ > include/linux/iio/adc-helpers.h | 22 ++++++++ > 4 files changed, 116 insertions(+) > create mode 100644 drivers/iio/adc/industrialio-adc.c > create mode 100644 include/linux/iio/adc-helpers.h > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index 849c90203071..37b70a65da6f 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -6,6 +6,9 @@ > > menu "Analog to digital converters" > > +config IIO_ADC_HELPER > + tristate > + > config AB8500_GPADC > bool "ST-Ericsson AB8500 GPADC driver" > depends on AB8500_CORE && REGULATOR_AB8500 > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > index ee19afba62b7..1c410f483029 100644 > --- a/drivers/iio/adc/Makefile > +++ b/drivers/iio/adc/Makefile > @@ -3,6 +3,8 @@ > # Makefile for IIO ADC drivers > # > > +obj-$(CONFIG_IIO_ADC_HELPER) += industrialio-adc.o > + > # When adding new entries keep the list in alphabetical order > obj-$(CONFIG_AB8500_GPADC) += ab8500-gpadc.o > obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o > diff --git a/drivers/iio/adc/industrialio-adc.c b/drivers/iio/adc/industrialio-adc.c > new file mode 100644 > index 000000000000..d8e9e6825d2b > --- /dev/null > +++ b/drivers/iio/adc/industrialio-adc.c > @@ -0,0 +1,89 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Helpers for parsing common ADC information from a firmware node. > + * > + * Copyright (c) 2025 Matti Vaittinen <mazziesaccount@gmail.com> > + */ > + > +#include <linux/device.h> > +#include <linux/errno.h> > +#include <linux/export.h> > +#include <linux/module.h> > +#include <linux/property.h> > +#include <linux/types.h> > + > +#include <linux/iio/adc-helpers.h> > +#include <linux/iio/iio.h> > + > +int iio_adc_device_num_channels(struct device *dev) > +{ > + return device_get_child_node_count_named(dev, "channel"); > +} > +EXPORT_SYMBOL_GPL(iio_adc_device_num_channels); Maybe one to promote to a static inline in the header and avoid need for the export given it is very simple. > + > +/** > + * devm_iio_adc_device_alloc_chaninfo_se - allocate and fill iio_chan_spec for ADC > + * > + * Scan the device node for single-ended ADC channel information. Channel ID is > + * expected to be found from the "reg" property. Allocate and populate the > + * iio_chan_spec structure corresponding to channels that are found. The memory > + * for iio_chan_spec structure will be freed upon device detach. > + * > + * @dev: Pointer to the ADC device. > + * @template: Template iio_chan_spec from which the fields of all > + * found and allocated channels are initialized. > + * @max_chan_id: Maximum value of a channel ID. Use -1 if no checking > + * is required. > + * @cs: Location where pointer to allocated iio_chan_spec > + * should be stored. > + * > + * Return: Number of found channels on succes. Negative value to indicate > + * failure. > + */ > +int devm_iio_adc_device_alloc_chaninfo_se(struct device *dev, > + const struct iio_chan_spec *template, > + int max_chan_id, > + struct iio_chan_spec **cs) > +{ > + struct iio_chan_spec *chan_array, *chan; > + int num_chan = 0, ret; > + > + num_chan = iio_adc_device_num_channels(dev); > + if (num_chan < 1) > + return num_chan; > + > + chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array), > + GFP_KERNEL); > + if (!chan_array) > + return -ENOMEM; > + > + chan = &chan_array[0]; > + > + device_for_each_child_node_scoped(dev, child) { > + u32 ch; > + > + if (!fwnode_name_eq(child, "channel")) > + continue; > + > + ret = fwnode_property_read_u32(child, "reg", &ch); > + if (ret) > + return ret; > + > + if (max_chan_id != -1) > + if (ch > max_chan_id) > + return -ERANGE; Might as well combine. if (max_chan_id != -1 && ch > max_chan_id) return -ERANGE; > + > + *chan = *template; > + chan->channel = ch; > + chan++; > + } > + > + *cs = chan_array; > + > + return num_chan; > +} > +EXPORT_SYMBOL_NS_GPL(devm_iio_adc_device_alloc_chaninfo_se, "IIO_DRIVER"); > + > +MODULE_LICENSE("GPL"); > +MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>"); > +MODULE_DESCRIPTION("IIO ADC fwnode parsing helpers");
On Mon, 24 Feb 2025 20:33:16 +0200 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > There are ADC ICs which may have some of the AIN pins usable for other > functions. These ICs may have some of the AIN pins wired so that they > should not be used for ADC. > > (Preferred?) way for marking pins which can be used as ADC inputs is to > add corresponding channels@N nodes in the device tree as described in > the ADC binding yaml. > > Add couple of helper functions which can be used to retrieve the channel > information from the device node. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > > --- > Revision history: > v3 => v4: > - Drop diff-channel support > - Drop iio_adc_device_channels_by_property() > - Add IIO_DEVICE namespace > - Move industrialio-adc.o to top of the Makefile > - Some styling as suggested by Andy > - Re-consider included headers > v2 => v3: Mostly based on review comments by Jonathan > - Support differential and single-ended channels > - Rename iio_adc_device_get_channels() as > iio_adc_device_channels_by_property() > - Improve spelling > - Drop support for cases where DT comes from parent device's node > - Decrease loop indent by reverting node name check conditions > - Don't set 'chan->indexed' by number of channels to keep the > interface consistent no matter how many channels are connected. > - Fix ID range check and related comment > RFC v1 => v2: > - New patch > > iio: adc: helper: drop headers > --- > drivers/iio/adc/Kconfig | 3 + > drivers/iio/adc/Makefile | 2 + > drivers/iio/adc/industrialio-adc.c | 89 ++++++++++++++++++++++++++++++ > include/linux/iio/adc-helpers.h | 22 ++++++++ > 4 files changed, 116 insertions(+) > create mode 100644 drivers/iio/adc/industrialio-adc.c > create mode 100644 include/linux/iio/adc-helpers.h > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index 849c90203071..37b70a65da6f 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -6,6 +6,9 @@ > > menu "Analog to digital converters" > > +config IIO_ADC_HELPER > + tristate > + > config AB8500_GPADC > bool "ST-Ericsson AB8500 GPADC driver" > depends on AB8500_CORE && REGULATOR_AB8500 > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > index ee19afba62b7..1c410f483029 100644 > --- a/drivers/iio/adc/Makefile > +++ b/drivers/iio/adc/Makefile > @@ -3,6 +3,8 @@ > # Makefile for IIO ADC drivers > # > > +obj-$(CONFIG_IIO_ADC_HELPER) += industrialio-adc.o > + > # When adding new entries keep the list in alphabetical order > obj-$(CONFIG_AB8500_GPADC) += ab8500-gpadc.o > obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o > diff --git a/drivers/iio/adc/industrialio-adc.c b/drivers/iio/adc/industrialio-adc.c > new file mode 100644 > index 000000000000..d8e9e6825d2b > --- /dev/null > +++ b/drivers/iio/adc/industrialio-adc.c > @@ -0,0 +1,89 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Helpers for parsing common ADC information from a firmware node. > + * > + * Copyright (c) 2025 Matti Vaittinen <mazziesaccount@gmail.com> > + */ > + > +#include <linux/device.h> > +#include <linux/errno.h> > +#include <linux/export.h> > +#include <linux/module.h> > +#include <linux/property.h> > +#include <linux/types.h> > + > +#include <linux/iio/adc-helpers.h> > +#include <linux/iio/iio.h> > + > +int iio_adc_device_num_channels(struct device *dev) > +{ > + return device_get_child_node_count_named(dev, "channel"); > +} > +EXPORT_SYMBOL_GPL(iio_adc_device_num_channels); Just noticed, this isn't namespaces which is a bit odd. I'd drop the export anyway in favour of static inline but if you don't match the namespace of the next one.
On 02/03/2025 05:20, Jonathan Cameron wrote: > On Thu, 27 Feb 2025 09:46:06 +0200 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> On 26/02/2025 18:10, David Lechner wrote: >>> On 2/26/25 12:28 AM, Matti Vaittinen wrote: ... > So today the situation is we have all the options in tree and we aren't > really in a position to drop any of them: Sure. I am only really interested whether we want to prefer some approach for (majority of) new drivers. Furthermore, I believe there will always be corner cases and oddities which won't fit to the 'de facto' model. That doesn't mean we shouldn't help those which don't have such 'oddities' to work with some generic code. > Hindsight is a wonderful thing. I'm not sure on what policy we should have > gone for, but now we are kind of stuck with this slightly messy situation. Sorry if my comments came out as criticism. It was not intention, I just try to justify the helpers by trying to think what new drivers should prefer. > Helper wise if it expands usefulness we may want a bool parameter to say > if we skip the missing or not + make sure a max expected channel is provided > (might already be - I didn't check!) This far it only had (optional) maximum channel ID for sanity checking (useful for callers which use the ID to index an array). The bool parameter would also require a parameter specifying the number of expected channels. That'd make 3 parameters which may be used or unused. I don't think I saw existing code which would have used these parameters. It might be cleaner to add new APIs when we get such use-cases. That should simplify the use for current cases. Thank You for the long explanation of current system + the history :) I appreciate your guidance! Yours, -- Matti
On 02/03/2025 05:35, Jonathan Cameron wrote: > On Mon, 24 Feb 2025 20:33:16 +0200 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> There are ADC ICs which may have some of the AIN pins usable for other >> functions. These ICs may have some of the AIN pins wired so that they >> should not be used for ADC. >> >> (Preferred?) way for marking pins which can be used as ADC inputs is to >> add corresponding channels@N nodes in the device tree as described in >> the ADC binding yaml. > I think it's worth exploring if we can tweak this slightly to make > that something a driver specifies. Either skip the unspecified or > fill them with default values depending on a parameter. > > Would make this code cover the existing cases better. > Might be a little fiddly as we'd want to maintain ordering so > the code would need to index slightly differently. I've not tried it > so maybe not worth it for now. Thanks for the review! I don't remember seeing users which would have benefited from this (but maybe I just quickly discarded them as unsuitable for this API and forgot them). Anyways, I think it might be cleaner (from the caller's perspective) to have own function for supporting such cases. >> + >> +int iio_adc_device_num_channels(struct device *dev) >> +{ >> + return device_get_child_node_count_named(dev, "channel"); >> +} >> +EXPORT_SYMBOL_GPL(iio_adc_device_num_channels); > > Maybe one to promote to a static inline in the header and avoid need for > the export given it is very simple. Makes sense, thanks. ... >> + >> + if (max_chan_id != -1) >> + if (ch > max_chan_id) >> + return -ERANGE; > > Might as well combine. > if (max_chan_id != -1 && ch > max_chan_id) > return -ERANGE; Ack. Yours, -- Matti
On 02/03/2025 05:48, Jonathan Cameron wrote: > On Mon, 24 Feb 2025 20:33:16 +0200 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > ... >> +int iio_adc_device_num_channels(struct device *dev) >> +{ >> + return device_get_child_node_count_named(dev, "channel"); >> +} >> +EXPORT_SYMBOL_GPL(iio_adc_device_num_channels); > Just noticed, this isn't namespaces which is a bit odd. I'd drop > the export anyway in favour of static inline but if you don't match > the namespace of the next one. Indeed, thanks. I'll inline this in v5. Yours, -- Matti
On Sun, 2 Mar 2025 14:54:16 +0200 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On 02/03/2025 05:20, Jonathan Cameron wrote: > > On Thu, 27 Feb 2025 09:46:06 +0200 > > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > > > >> On 26/02/2025 18:10, David Lechner wrote: > >>> On 2/26/25 12:28 AM, Matti Vaittinen wrote: > > ... > > > So today the situation is we have all the options in tree and we aren't > > really in a position to drop any of them: > > Sure. I am only really interested whether we want to prefer some > approach for (majority of) new drivers. Furthermore, I believe there > will always be corner cases and oddities which won't fit to the 'de > facto' model. That doesn't mean we shouldn't help those which don't have > such 'oddities' to work with some generic code. Absolutely but we also can't apply this to existing drivers that don't work quite that way. So if we want to make more use of it we end up providing variants long term. > > > Hindsight is a wonderful thing. I'm not sure on what policy we should have > > gone for, but now we are kind of stuck with this slightly messy situation. > > Sorry if my comments came out as criticism. No problem - that was just me being wistful about wanting a crystal ball :) > It was not intention, I just > try to justify the helpers by trying to think what new drivers should > prefer. > > > Helper wise if it expands usefulness we may want a bool parameter to say > > if we skip the missing or not + make sure a max expected channel is provided > > (might already be - I didn't check!) > > This far it only had (optional) maximum channel ID for sanity checking > (useful for callers which use the ID to index an array). The bool > parameter would also require a parameter specifying the number of > expected channels. That'd make 3 parameters which may be used or unused. > > I don't think I saw existing code which would have used these > parameters. It might be cleaner to add new APIs when we get such > use-cases. That should simplify the use for current cases. That's fair enough. Ultimately my guess is we'll end up with a complex internal function and a bunch of wrappers that elide the majority of the parameters. We can get there once it's needed though! Jonathan > > Thank You for the long explanation of current system + the history :) I > appreciate your guidance! > > Yours, > -- Matti >
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 849c90203071..37b70a65da6f 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -6,6 +6,9 @@ menu "Analog to digital converters" +config IIO_ADC_HELPER + tristate + config AB8500_GPADC bool "ST-Ericsson AB8500 GPADC driver" depends on AB8500_CORE && REGULATOR_AB8500 diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index ee19afba62b7..1c410f483029 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -3,6 +3,8 @@ # Makefile for IIO ADC drivers # +obj-$(CONFIG_IIO_ADC_HELPER) += industrialio-adc.o + # When adding new entries keep the list in alphabetical order obj-$(CONFIG_AB8500_GPADC) += ab8500-gpadc.o obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o diff --git a/drivers/iio/adc/industrialio-adc.c b/drivers/iio/adc/industrialio-adc.c new file mode 100644 index 000000000000..d8e9e6825d2b --- /dev/null +++ b/drivers/iio/adc/industrialio-adc.c @@ -0,0 +1,89 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Helpers for parsing common ADC information from a firmware node. + * + * Copyright (c) 2025 Matti Vaittinen <mazziesaccount@gmail.com> + */ + +#include <linux/device.h> +#include <linux/errno.h> +#include <linux/export.h> +#include <linux/module.h> +#include <linux/property.h> +#include <linux/types.h> + +#include <linux/iio/adc-helpers.h> +#include <linux/iio/iio.h> + +int iio_adc_device_num_channels(struct device *dev) +{ + return device_get_child_node_count_named(dev, "channel"); +} +EXPORT_SYMBOL_GPL(iio_adc_device_num_channels); + +/** + * devm_iio_adc_device_alloc_chaninfo_se - allocate and fill iio_chan_spec for ADC + * + * Scan the device node for single-ended ADC channel information. Channel ID is + * expected to be found from the "reg" property. Allocate and populate the + * iio_chan_spec structure corresponding to channels that are found. The memory + * for iio_chan_spec structure will be freed upon device detach. + * + * @dev: Pointer to the ADC device. + * @template: Template iio_chan_spec from which the fields of all + * found and allocated channels are initialized. + * @max_chan_id: Maximum value of a channel ID. Use -1 if no checking + * is required. + * @cs: Location where pointer to allocated iio_chan_spec + * should be stored. + * + * Return: Number of found channels on succes. Negative value to indicate + * failure. + */ +int devm_iio_adc_device_alloc_chaninfo_se(struct device *dev, + const struct iio_chan_spec *template, + int max_chan_id, + struct iio_chan_spec **cs) +{ + struct iio_chan_spec *chan_array, *chan; + int num_chan = 0, ret; + + num_chan = iio_adc_device_num_channels(dev); + if (num_chan < 1) + return num_chan; + + chan_array = devm_kcalloc(dev, num_chan, sizeof(*chan_array), + GFP_KERNEL); + if (!chan_array) + return -ENOMEM; + + chan = &chan_array[0]; + + device_for_each_child_node_scoped(dev, child) { + u32 ch; + + if (!fwnode_name_eq(child, "channel")) + continue; + + ret = fwnode_property_read_u32(child, "reg", &ch); + if (ret) + return ret; + + if (max_chan_id != -1) + if (ch > max_chan_id) + return -ERANGE; + + *chan = *template; + chan->channel = ch; + chan++; + } + + *cs = chan_array; + + return num_chan; +} +EXPORT_SYMBOL_NS_GPL(devm_iio_adc_device_alloc_chaninfo_se, "IIO_DRIVER"); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>"); +MODULE_DESCRIPTION("IIO ADC fwnode parsing helpers"); diff --git a/include/linux/iio/adc-helpers.h b/include/linux/iio/adc-helpers.h new file mode 100644 index 000000000000..5d64244f1552 --- /dev/null +++ b/include/linux/iio/adc-helpers.h @@ -0,0 +1,22 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +/* + * The industrial I/O ADC firmware property parsing helpers + * + * Copyright (c) 2025 Matti Vaittinen <mazziesaccount@gmail.com> + */ + +#ifndef _INDUSTRIAL_IO_ADC_HELPERS_H_ +#define _INDUSTRIAL_IO_ADC_HELPERS_H_ + +struct device; +struct fwnode_handle; +struct iio_chan_spec; + +int iio_adc_device_num_channels(struct device *dev); +int devm_iio_adc_device_alloc_chaninfo_se(struct device *dev, + const struct iio_chan_spec *template, + int max_chan_id, + struct iio_chan_spec **cs); + +#endif /* _INDUSTRIAL_IO_ADC_HELPERS_H_ */
There are ADC ICs which may have some of the AIN pins usable for other functions. These ICs may have some of the AIN pins wired so that they should not be used for ADC. (Preferred?) way for marking pins which can be used as ADC inputs is to add corresponding channels@N nodes in the device tree as described in the ADC binding yaml. Add couple of helper functions which can be used to retrieve the channel information from the device node. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> --- Revision history: v3 => v4: - Drop diff-channel support - Drop iio_adc_device_channels_by_property() - Add IIO_DEVICE namespace - Move industrialio-adc.o to top of the Makefile - Some styling as suggested by Andy - Re-consider included headers v2 => v3: Mostly based on review comments by Jonathan - Support differential and single-ended channels - Rename iio_adc_device_get_channels() as iio_adc_device_channels_by_property() - Improve spelling - Drop support for cases where DT comes from parent device's node - Decrease loop indent by reverting node name check conditions - Don't set 'chan->indexed' by number of channels to keep the interface consistent no matter how many channels are connected. - Fix ID range check and related comment RFC v1 => v2: - New patch iio: adc: helper: drop headers --- drivers/iio/adc/Kconfig | 3 + drivers/iio/adc/Makefile | 2 + drivers/iio/adc/industrialio-adc.c | 89 ++++++++++++++++++++++++++++++ include/linux/iio/adc-helpers.h | 22 ++++++++ 4 files changed, 116 insertions(+) create mode 100644 drivers/iio/adc/industrialio-adc.c create mode 100644 include/linux/iio/adc-helpers.h