Hi!
This moves the iio-mux driver to a new category, since I think
it will be the single driver in that category forever, and now
I'm adding a new driver that is somewhat similar in nature...
But that rename is not very interesting, it's just reshuffling.
It's the new driver that I need. Specifically, I need to allow
linear scaling and modification of the type of an io-channel.
I don't know exactly how that is accomplished in the best way,
but this is what I came up with.
The use cases are an ADC hooked up to measure a "big" voltage by
looking at the midpoint of a voltage divider, and an ADC used
to measure the current by looking at the voltage over a resistor.
Comments?
Cheers,
Peter
Peter Rosin (3):
iio: rename the multiplexer category to wrapper
dt-bindings: iio: wrapper: add io-channel-unit-converter
iio: wrapper: unit-converter: new driver
.../{multiplexer => wrapper}/io-channel-mux.txt | 0
.../iio/wrapper/io-channel-unit-converter.txt | 84 +++++++
MAINTAINERS | 11 +-
drivers/iio/Kconfig | 2 +-
drivers/iio/Makefile | 2 +-
drivers/iio/multiplexer/Makefile | 6 -
drivers/iio/{multiplexer => wrapper}/Kconfig | 13 +-
drivers/iio/wrapper/Makefile | 7 +
drivers/iio/{multiplexer => wrapper}/iio-mux.c | 0
drivers/iio/wrapper/iio-unit-converter.c | 268 +++++++++++++++++++++
10 files changed, 381 insertions(+), 12 deletions(-)
rename Documentation/devicetree/bindings/iio/{multiplexer => wrapper}/io-channel-mux.txt (100%)
create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
delete mode 100644 drivers/iio/multiplexer/Makefile
rename drivers/iio/{multiplexer => wrapper}/Kconfig (53%)
create mode 100644 drivers/iio/wrapper/Makefile
rename drivers/iio/{multiplexer => wrapper}/iio-mux.c (100%)
create mode 100644 drivers/iio/wrapper/iio-unit-converter.c
--
2.11.0
If an ADC channel measures the midpoint of a voltage divider, the
interesting voltage is often the voltage over the full resistance.
E.g. if the full voltage it too big for the ADC to handle.
Likewise, if an ADC channel measures the voltage across a resistor,
the interesting value is often the current through the resistor.
This driver solves both problems by allowing to linearly scale a channel
and by allowing changes to the type of the channel. Or both.
Signed-off-by: Peter Rosin <[email protected]>
---
MAINTAINERS | 1 +
drivers/iio/wrapper/Kconfig | 9 ++
drivers/iio/wrapper/Makefile | 1 +
drivers/iio/wrapper/iio-unit-converter.c | 268 +++++++++++++++++++++++++++++++
4 files changed, 279 insertions(+)
create mode 100644 drivers/iio/wrapper/iio-unit-converter.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5dd555c7b1b0..b879289f1318 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6889,6 +6889,7 @@ M: Peter Rosin <[email protected]>
L: [email protected]
S: Maintained
F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
+F: drivers/iio/wrapper/iio-unit-converter.c
IKANOS/ADI EAGLE ADSL USB DRIVER
M: Matthieu Castet <[email protected]>
diff --git a/drivers/iio/wrapper/Kconfig b/drivers/iio/wrapper/Kconfig
index f27de347c9b3..16554479264a 100644
--- a/drivers/iio/wrapper/Kconfig
+++ b/drivers/iio/wrapper/Kconfig
@@ -15,4 +15,13 @@ config IIO_MUX
To compile this driver as a module, choose M here: the
module will be called iio-mux.
+config IIO_UNIT_CONVERTER
+ tristate "IIO unit converter"
+ depends on OF || COMPILE_TEST
+ help
+ Say yes here to build support for the IIO unit converter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-unit-converter.
+
endmenu
diff --git a/drivers/iio/wrapper/Makefile b/drivers/iio/wrapper/Makefile
index 53a7b78734e3..1b9db53bd420 100644
--- a/drivers/iio/wrapper/Makefile
+++ b/drivers/iio/wrapper/Makefile
@@ -4,3 +4,4 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_IIO_MUX) += iio-mux.o
+obj-$(CONFIG_IIO_UNIT_CONVERTER) += iio-unit-converter.o
diff --git a/drivers/iio/wrapper/iio-unit-converter.c b/drivers/iio/wrapper/iio-unit-converter.c
new file mode 100644
index 000000000000..53c126f39e4e
--- /dev/null
+++ b/drivers/iio/wrapper/iio-unit-converter.c
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IIO unit converter
+ *
+ * Copyright (C) 2018 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <[email protected]>
+ */
+
+#include <linux/err.h>
+#include <linux/iio/consumer.h>
+#include <linux/iio/iio.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+
+struct unit_converter {
+ struct iio_channel *parent;
+ struct iio_dev *indio_dev;
+ struct iio_chan_spec chan;
+ struct iio_chan_spec_ext_info *ext_info;
+ s32 numerator;
+ s32 denominator;
+};
+
+static int unit_converter_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct unit_converter *uc = iio_priv(indio_dev);
+ unsigned long long tmp;
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ return iio_read_channel_raw(uc->parent, val);
+
+ case IIO_CHAN_INFO_SCALE:
+ ret = iio_read_channel_scale(uc->parent, val, val2);
+ switch (ret) {
+ case IIO_VAL_FRACTIONAL:
+ *val *= uc->numerator;
+ *val2 *= uc->denominator;
+ return ret;
+ case IIO_VAL_INT:
+ *val *= uc->numerator;
+ if (uc->denominator == 1)
+ return ret;
+ *val2 = uc->denominator;
+ return IIO_VAL_FRACTIONAL;
+ case IIO_VAL_FRACTIONAL_LOG2:
+ tmp = *val * 1000000000LL;
+ do_div(tmp, uc->denominator);
+ tmp *= uc->numerator;
+ do_div(tmp, 1000000000LL);
+ *val = tmp;
+ return ret;
+ }
+ return -EOPNOTSUPP;
+ }
+
+ return -EINVAL;
+}
+
+static int unit_converter_read_avail(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ const int **vals, int *type, int *length,
+ long mask)
+{
+ struct unit_converter *uc = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ *type = IIO_VAL_INT;
+ return iio_read_avail_channel_raw(uc->parent, vals, length);
+ }
+
+ return -EINVAL;
+}
+
+static int unit_converter_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long mask)
+{
+ struct unit_converter *uc = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ return iio_write_channel_raw(uc->parent, val);
+ }
+
+ return -EINVAL;
+}
+
+static const struct iio_info unit_converter_info = {
+ .read_raw = unit_converter_read_raw,
+ .read_avail = unit_converter_read_avail,
+ .write_raw = unit_converter_write_raw,
+};
+
+static ssize_t unit_converter_read_ext_info(struct iio_dev *indio_dev,
+ uintptr_t private,
+ struct iio_chan_spec const *chan,
+ char *buf)
+{
+ struct unit_converter *uc = iio_priv(indio_dev);
+
+ return iio_read_channel_ext_info(uc->parent,
+ uc->ext_info[private].name,
+ buf);
+}
+
+static ssize_t unit_converter_write_ext_info(struct iio_dev *indio_dev,
+ uintptr_t private,
+ struct iio_chan_spec const *chan,
+ const char *buf, size_t len)
+{
+ struct unit_converter *uc = iio_priv(indio_dev);
+
+ return iio_write_channel_ext_info(uc->parent,
+ uc->ext_info[private].name,
+ buf, len);
+}
+
+static int unit_converter_configure_channel(struct device *dev,
+ struct unit_converter *uc,
+ enum iio_chan_type type)
+{
+ struct iio_chan_spec *chan = &uc->chan;
+ struct iio_chan_spec const *pchan = uc->parent->channel;
+ int ret;
+
+ chan->indexed = 1;
+ chan->output = pchan->output;
+ chan->ext_info = uc->ext_info;
+
+ if (type == -1) {
+ ret = iio_get_channel_type(uc->parent, &type);
+ if (ret < 0) {
+ dev_err(dev, "failed to get parent channel type\n");
+ return ret;
+ }
+ }
+ chan->type = type;
+
+ if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
+ chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
+ if (iio_channel_has_info(pchan, IIO_CHAN_INFO_SCALE))
+ chan->info_mask_separate |= BIT(IIO_CHAN_INFO_SCALE);
+
+ if (iio_channel_has_available(pchan, IIO_CHAN_INFO_RAW))
+ chan->info_mask_separate_available |= BIT(IIO_CHAN_INFO_RAW);
+
+ chan->channel = 0;
+
+ return 0;
+}
+
+static int unit_converter_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct iio_dev *indio_dev;
+ struct iio_channel *parent;
+ struct unit_converter *uc;
+ const char *type_name;
+ enum iio_chan_type type = -1; /* default to same as parent */
+ int sizeof_ext_info;
+ int sizeof_priv;
+ int i;
+ int ret;
+
+ if (!device_property_read_string(dev, "type", &type_name)) {
+ if (!strcmp(type_name, "voltage"))
+ type = IIO_VOLTAGE;
+ else if (!strcmp(type_name, "current"))
+ type = IIO_CURRENT;
+ else
+ return -EINVAL;
+ }
+
+ parent = devm_iio_channel_get(dev, "parent");
+ if (IS_ERR(parent)) {
+ if (PTR_ERR(parent) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get parent channel\n");
+ return PTR_ERR(parent);
+ }
+
+ sizeof_ext_info = iio_get_channel_ext_info_count(parent);
+ if (sizeof_ext_info) {
+ sizeof_ext_info += 1; /* one extra entry for the sentinel */
+ sizeof_ext_info *= sizeof(*uc->ext_info);
+ }
+
+ sizeof_priv = sizeof(*uc) + sizeof_ext_info;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof_priv);
+ if (!indio_dev)
+ return -ENOMEM;
+
+ uc = iio_priv(indio_dev);
+
+ uc->numerator = 1;
+ uc->denominator = 1;
+ device_property_read_u32(dev, "numerator", &uc->numerator);
+ device_property_read_u32(dev, "denominator", &uc->denominator);
+ if (!uc->numerator || !uc->denominator) {
+ dev_err(dev, "invalid scaling factor.\n");
+ return -EINVAL;
+ }
+
+ platform_set_drvdata(pdev, indio_dev);
+
+ uc->parent = parent;
+
+ indio_dev->name = dev_name(dev);
+ indio_dev->dev.parent = dev;
+ indio_dev->info = &unit_converter_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = &uc->chan;
+ indio_dev->num_channels = 1;
+ if (sizeof_ext_info) {
+ uc->ext_info = devm_kmemdup(dev,
+ parent->channel->ext_info,
+ sizeof_ext_info, GFP_KERNEL);
+ if (!uc->ext_info)
+ return -ENOMEM;
+
+ for (i = 0; uc->ext_info[i].name; ++i) {
+ if (parent->channel->ext_info[i].read)
+ uc->ext_info[i].read = unit_converter_read_ext_info;
+ if (parent->channel->ext_info[i].write)
+ uc->ext_info[i].write = unit_converter_write_ext_info;
+ uc->ext_info[i].private = i;
+ }
+ }
+
+ ret = unit_converter_configure_channel(dev, uc, type);
+ if (ret < 0)
+ return ret;
+
+ ret = devm_iio_device_register(dev, indio_dev);
+ if (ret) {
+ dev_err(dev, "failed to register iio device\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id unit_converter_match[] = {
+ { .compatible = "io-channel-unit-converter" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, unit_converter_match);
+
+static struct platform_driver unit_converter_driver = {
+ .probe = unit_converter_probe,
+ .driver = {
+ .name = "iio-unit-converter",
+ .of_match_table = unit_converter_match,
+ },
+};
+module_platform_driver(unit_converter_driver);
+
+MODULE_DESCRIPTION("IIO unit converter driver");
+MODULE_AUTHOR("Peter Rosin <[email protected]>");
+MODULE_LICENSE("GPL v2");
--
2.11.0
Allow linear scaling and modification of the type of an io-channel.
When an ADC channel measures the midpoint of a voltage divider, the
interesting voltage is often the voltage over the full resistance
of the divider. Likewise, measuring the voltage over a resistor is
often a way to get to the current through it.
This binding allows description of such hardware which is external
to the ADC.
Signed-off-by: Peter Rosin <[email protected]>
---
.../iio/wrapper/io-channel-unit-converter.txt | 84 ++++++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 90 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
diff --git a/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
new file mode 100644
index 000000000000..23af661abe32
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
@@ -0,0 +1,84 @@
+I/O channel unit converter bindings
+
+Allow linear scaling and modification of the type of an io-channel.
+
+When an ADC channel measures the midpoint of a voltage divider, the
+interesting voltage is often the voltage over the full resistance
+of the divider. Likewise, measuring the voltage over a resistor is
+often a way to get to the current through it.
+
+Required properties:
+- compatible : "io-channel-unit-converter"
+- io-channels : Channel node of the parent channel.
+- io-channel-names : Should be "parent".
+
+Optional properties:
+- numerator : The parent channel scale is multiplied by this value (default 1).
+- denominator : The parent channel scale is divided by this value (default 1).
+- type : The type of the wrapped channel is modified to this type. The default
+ is to use the same type as the parent channel. Recognized types are:
+ "voltage"
+ "current"
+
+Example 1:
+The system voltage is circa 12V, but divided down with a 22/200
+voltage divider to adjust it to the ADC range.
+
+SYSV ADC GND
+ + + +
+ | .-----. | .----. |
+ '--| 200 |-+-| 22 |--'
+ '-----' '----'
+
+sysv {
+ compatible = "io-channel-unit-converter";
+ io-channles = <&maxadc 1>;
+ io-channel-names = "parent";
+
+ /* multiply the ADC voltage by 222/22 to get the system voltage */
+ numerator = <222>; /* 200 + 22 */
+ denominator = <22>;
+}
+
+&spi {
+ maxadc: adc@0 {
+ compatible = "maxim,max1027";
+ reg = <0>;
+ #io-channel-cells = <1>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <15 IRQ_TYPE_EDGE_RISING>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
+Example 2:
+The system current is measured by measuring the voltage over a
+3.3 ohm resistor.
+
+sysi {
+ compatible = "io-channel-unit-converter";
+ io-channles = <&tiadc 0>;
+ io-channel-names = "parent";
+
+ /* divide the ADC voltage by 33/10 (i.e. 3.3) to get current */
+ numerator = <10>;
+ denominator = <33>;
+ type = "current";
+}
+
+&i2c {
+ tiadc: adc@48 {
+ compatible = "ti,ads1015";
+ reg = <0x48>;
+ #io-channel-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 { /* IN0,IN1 differential */
+ reg = <0>;
+ ti,gain = <1>;
+ ti,datarate = <4>;
+ };
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 96e5503bfb60..5dd555c7b1b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6884,6 +6884,12 @@ F: drivers/staging/iio/
F: include/linux/iio/
F: tools/iio/
+IIO UNIT CONVERTER
+M: Peter Rosin <[email protected]>
+L: [email protected]
+S: Maintained
+F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
+
IKANOS/ADI EAGLE ADSL USB DRIVER
M: Matthieu Castet <[email protected]>
M: Stanislaw Gruszka <[email protected]>
--
2.11.0
Paves the way for other wrappers.
Signed-off-by: Peter Rosin <[email protected]>
---
.../bindings/iio/{multiplexer => wrapper}/io-channel-mux.txt | 0
MAINTAINERS | 4 ++--
drivers/iio/Kconfig | 2 +-
drivers/iio/Makefile | 2 +-
drivers/iio/{multiplexer => wrapper}/Kconfig | 4 ++--
drivers/iio/{multiplexer => wrapper}/Makefile | 2 +-
drivers/iio/{multiplexer => wrapper}/iio-mux.c | 0
7 files changed, 7 insertions(+), 7 deletions(-)
rename Documentation/devicetree/bindings/iio/{multiplexer => wrapper}/io-channel-mux.txt (100%)
rename drivers/iio/{multiplexer => wrapper}/Kconfig (88%)
rename drivers/iio/{multiplexer => wrapper}/Makefile (67%)
rename drivers/iio/{multiplexer => wrapper}/iio-mux.c (100%)
diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt b/Documentation/devicetree/bindings/iio/wrapper/io-channel-mux.txt
similarity index 100%
rename from Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
rename to Documentation/devicetree/bindings/iio/wrapper/io-channel-mux.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 3bdc260e36b7..96e5503bfb60 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6865,8 +6865,8 @@ IIO MULTIPLEXER
M: Peter Rosin <[email protected]>
L: [email protected]
S: Maintained
-F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
-F: drivers/iio/multiplexer/iio-mux.c
+F: Documentation/devicetree/bindings/iio/wrapper/io-channel-mux.txt
+F: drivers/iio/wrapper/iio-mux.c
IIO SUBSYSTEM AND DRIVERS
M: Jonathan Cameron <[email protected]>
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index b3c8c6ef0dff..c4d25746c585 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -83,7 +83,6 @@ source "drivers/iio/humidity/Kconfig"
source "drivers/iio/imu/Kconfig"
source "drivers/iio/light/Kconfig"
source "drivers/iio/magnetometer/Kconfig"
-source "drivers/iio/multiplexer/Kconfig"
source "drivers/iio/orientation/Kconfig"
if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
@@ -93,5 +92,6 @@ source "drivers/iio/potentiostat/Kconfig"
source "drivers/iio/pressure/Kconfig"
source "drivers/iio/proximity/Kconfig"
source "drivers/iio/temperature/Kconfig"
+source "drivers/iio/wrapper/Kconfig"
endif # IIO
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index b16b2e9ddc40..dc5486f6c148 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -29,7 +29,6 @@ obj-y += humidity/
obj-y += imu/
obj-y += light/
obj-y += magnetometer/
-obj-y += multiplexer/
obj-y += orientation/
obj-y += potentiometer/
obj-y += potentiostat/
@@ -37,3 +36,4 @@ obj-y += pressure/
obj-y += proximity/
obj-y += temperature/
obj-y += trigger/
+obj-y += wrapper/
diff --git a/drivers/iio/multiplexer/Kconfig b/drivers/iio/wrapper/Kconfig
similarity index 88%
rename from drivers/iio/multiplexer/Kconfig
rename to drivers/iio/wrapper/Kconfig
index 735a7b0e6fd8..f27de347c9b3 100644
--- a/drivers/iio/multiplexer/Kconfig
+++ b/drivers/iio/wrapper/Kconfig
@@ -1,9 +1,9 @@
#
-# Multiplexer drivers
+# Wrapper drivers
#
# When adding new entries keep the list in alphabetical order
-menu "Multiplexers"
+menu "Wrapers"
config IIO_MUX
tristate "IIO multiplexer driver"
diff --git a/drivers/iio/multiplexer/Makefile b/drivers/iio/wrapper/Makefile
similarity index 67%
rename from drivers/iio/multiplexer/Makefile
rename to drivers/iio/wrapper/Makefile
index 68be3c4abd07..53a7b78734e3 100644
--- a/drivers/iio/multiplexer/Makefile
+++ b/drivers/iio/wrapper/Makefile
@@ -1,5 +1,5 @@
#
-# Makefile for industrial I/O multiplexer drivers
+# Makefile for industrial I/O wrapper drivers
#
# When adding new entries keep the list in alphabetical order
diff --git a/drivers/iio/multiplexer/iio-mux.c b/drivers/iio/wrapper/iio-mux.c
similarity index 100%
rename from drivers/iio/multiplexer/iio-mux.c
rename to drivers/iio/wrapper/iio-mux.c
--
2.11.0
On 03/19/2018 10:02 AM, Peter Rosin wrote:
> Paves the way for other wrappers.
>
> Signed-off-by: Peter Rosin <[email protected]>
> ---
> diff --git a/drivers/iio/multiplexer/Kconfig b/drivers/iio/wrapper/Kconfig
> similarity index 88%
> rename from drivers/iio/multiplexer/Kconfig
> rename to drivers/iio/wrapper/Kconfig
> index 735a7b0e6fd8..f27de347c9b3 100644
> --- a/drivers/iio/multiplexer/Kconfig
> +++ b/drivers/iio/wrapper/Kconfig
> @@ -1,9 +1,9 @@
> #
> -# Multiplexer drivers
> +# Wrapper drivers
> #
> # When adding new entries keep the list in alphabetical order
>
> -menu "Multiplexers"
> +menu "Wrapers"
Wrappers
>
> config IIO_MUX
> tristate "IIO multiplexer driver"
--
~Randy
On Mon, 19 Mar 2018 18:02:43 +0100
Peter Rosin <[email protected]> wrote:
> Hi!
>
> This moves the iio-mux driver to a new category, since I think
> it will be the single driver in that category forever, and now
> I'm adding a new driver that is somewhat similar in nature...
>
> But that rename is not very interesting, it's just reshuffling.
> It's the new driver that I need. Specifically, I need to allow
> linear scaling and modification of the type of an io-channel.
> I don't know exactly how that is accomplished in the best way,
> but this is what I came up with.
>
> The use cases are an ADC hooked up to measure a "big" voltage by
> looking at the midpoint of a voltage divider, and an ADC used
> to measure the current by looking at the voltage over a resistor.
>
> Comments?
It is pretty much how I would have implemented it as well.
Will probably do a detailed review over the weekend.
Not convinced entirely on the 'wrapper' naming though.
Will think about it...
Jonathan
>
> Cheers,
> Peter
>
> Peter Rosin (3):
> iio: rename the multiplexer category to wrapper
> dt-bindings: iio: wrapper: add io-channel-unit-converter
> iio: wrapper: unit-converter: new driver
>
> .../{multiplexer => wrapper}/io-channel-mux.txt | 0
> .../iio/wrapper/io-channel-unit-converter.txt | 84 +++++++
> MAINTAINERS | 11 +-
> drivers/iio/Kconfig | 2 +-
> drivers/iio/Makefile | 2 +-
> drivers/iio/multiplexer/Makefile | 6 -
> drivers/iio/{multiplexer => wrapper}/Kconfig | 13 +-
> drivers/iio/wrapper/Makefile | 7 +
> drivers/iio/{multiplexer => wrapper}/iio-mux.c | 0
> drivers/iio/wrapper/iio-unit-converter.c | 268 +++++++++++++++++++++
> 10 files changed, 381 insertions(+), 12 deletions(-)
> rename Documentation/devicetree/bindings/iio/{multiplexer => wrapper}/io-channel-mux.txt (100%)
> create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> delete mode 100644 drivers/iio/multiplexer/Makefile
> rename drivers/iio/{multiplexer => wrapper}/Kconfig (53%)
> create mode 100644 drivers/iio/wrapper/Makefile
> rename drivers/iio/{multiplexer => wrapper}/iio-mux.c (100%)
> create mode 100644 drivers/iio/wrapper/iio-unit-converter.c
>
On 2018-03-23 14:14, Jonathan Cameron wrote:
> On Mon, 19 Mar 2018 18:02:43 +0100
> Peter Rosin <[email protected]> wrote:
>
>> Hi!
>>
>> This moves the iio-mux driver to a new category, since I think
>> it will be the single driver in that category forever, and now
>> I'm adding a new driver that is somewhat similar in nature...
>>
>> But that rename is not very interesting, it's just reshuffling.
>> It's the new driver that I need. Specifically, I need to allow
>> linear scaling and modification of the type of an io-channel.
>> I don't know exactly how that is accomplished in the best way,
>> but this is what I came up with.
>>
>> The use cases are an ADC hooked up to measure a "big" voltage by
>> looking at the midpoint of a voltage divider, and an ADC used
>> to measure the current by looking at the voltage over a resistor.
>>
>> Comments?
> It is pretty much how I would have implemented it as well.
>
> Will probably do a detailed review over the weekend.
> Not convinced entirely on the 'wrapper' naming though.
> Will think about it...
Yeah, let's put 'Wrapper' in the crapper. Not married to it.
Miscellaneous?
So, not super-happy about that either. And maybe leave the mux
where it is? It's just that I have the feeling that the iio-mux
is never going to get any friends in its category, and the mux
and the unit-converter are kind of related in that they operate
on other channels. But maybe that's only logical it you know how
they are implemented...
Cheers,
Peter
>
> Jonathan
>
>>
>> Cheers,
>> Peter
>>
>> Peter Rosin (3):
>> iio: rename the multiplexer category to wrapper
>> dt-bindings: iio: wrapper: add io-channel-unit-converter
>> iio: wrapper: unit-converter: new driver
>>
>> .../{multiplexer => wrapper}/io-channel-mux.txt | 0
>> .../iio/wrapper/io-channel-unit-converter.txt | 84 +++++++
>> MAINTAINERS | 11 +-
>> drivers/iio/Kconfig | 2 +-
>> drivers/iio/Makefile | 2 +-
>> drivers/iio/multiplexer/Makefile | 6 -
>> drivers/iio/{multiplexer => wrapper}/Kconfig | 13 +-
>> drivers/iio/wrapper/Makefile | 7 +
>> drivers/iio/{multiplexer => wrapper}/iio-mux.c | 0
>> drivers/iio/wrapper/iio-unit-converter.c | 268 +++++++++++++++++++++
>> 10 files changed, 381 insertions(+), 12 deletions(-)
>> rename Documentation/devicetree/bindings/iio/{multiplexer => wrapper}/io-channel-mux.txt (100%)
>> create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>> delete mode 100644 drivers/iio/multiplexer/Makefile
>> rename drivers/iio/{multiplexer => wrapper}/Kconfig (53%)
>> create mode 100644 drivers/iio/wrapper/Makefile
>> rename drivers/iio/{multiplexer => wrapper}/iio-mux.c (100%)
>> create mode 100644 drivers/iio/wrapper/iio-unit-converter.c
>>
>
On Fri, 23 Mar 2018 14:59:41 +0100
Peter Rosin <[email protected]> wrote:
> On 2018-03-23 14:14, Jonathan Cameron wrote:
> > On Mon, 19 Mar 2018 18:02:43 +0100
> > Peter Rosin <[email protected]> wrote:
> >
> >> Hi!
> >>
> >> This moves the iio-mux driver to a new category, since I think
> >> it will be the single driver in that category forever, and now
> >> I'm adding a new driver that is somewhat similar in nature...
> >>
> >> But that rename is not very interesting, it's just reshuffling.
> >> It's the new driver that I need. Specifically, I need to allow
> >> linear scaling and modification of the type of an io-channel.
> >> I don't know exactly how that is accomplished in the best way,
> >> but this is what I came up with.
> >>
> >> The use cases are an ADC hooked up to measure a "big" voltage by
> >> looking at the midpoint of a voltage divider, and an ADC used
> >> to measure the current by looking at the voltage over a resistor.
> >>
> >> Comments?
> > It is pretty much how I would have implemented it as well.
> >
> > Will probably do a detailed review over the weekend.
> > Not convinced entirely on the 'wrapper' naming though.
> > Will think about it...
>
> Yeah, let's put 'Wrapper' in the crapper. Not married to it.
>
> Miscellaneous?
>
> So, not super-happy about that either. And maybe leave the mux
> where it is? It's just that I have the feeling that the iio-mux
> is never going to get any friends in its category, and the mux
> and the unit-converter are kind of related in that they operate
> on other channels. But maybe that's only logical it you know how
> they are implemented...
Perhaps Analog Front ends?
We could move the amplifier driver into the same directory as well,
though right now that driver is not passing the channels through
(it's often used without there being an IIO ADC behind it I think...)
Jonathan
>
> Cheers,
> Peter
>
> >
> > Jonathan
> >
> >>
> >> Cheers,
> >> Peter
> >>
> >> Peter Rosin (3):
> >> iio: rename the multiplexer category to wrapper
> >> dt-bindings: iio: wrapper: add io-channel-unit-converter
> >> iio: wrapper: unit-converter: new driver
> >>
> >> .../{multiplexer => wrapper}/io-channel-mux.txt | 0
> >> .../iio/wrapper/io-channel-unit-converter.txt | 84 +++++++
> >> MAINTAINERS | 11 +-
> >> drivers/iio/Kconfig | 2 +-
> >> drivers/iio/Makefile | 2 +-
> >> drivers/iio/multiplexer/Makefile | 6 -
> >> drivers/iio/{multiplexer => wrapper}/Kconfig | 13 +-
> >> drivers/iio/wrapper/Makefile | 7 +
> >> drivers/iio/{multiplexer => wrapper}/iio-mux.c | 0
> >> drivers/iio/wrapper/iio-unit-converter.c | 268 +++++++++++++++++++++
> >> 10 files changed, 381 insertions(+), 12 deletions(-)
> >> rename Documentation/devicetree/bindings/iio/{multiplexer => wrapper}/io-channel-mux.txt (100%)
> >> create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> >> delete mode 100644 drivers/iio/multiplexer/Makefile
> >> rename drivers/iio/{multiplexer => wrapper}/Kconfig (53%)
> >> create mode 100644 drivers/iio/wrapper/Makefile
> >> rename drivers/iio/{multiplexer => wrapper}/iio-mux.c (100%)
> >> create mode 100644 drivers/iio/wrapper/iio-unit-converter.c
> >>
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 19 Mar 2018 18:02:45 +0100
Peter Rosin <[email protected]> wrote:
> Allow linear scaling and modification of the type of an io-channel.
>
> When an ADC channel measures the midpoint of a voltage divider, the
> interesting voltage is often the voltage over the full resistance
> of the divider. Likewise, measuring the voltage over a resistor is
> often a way to get to the current through it.
>
> This binding allows description of such hardware which is external
> to the ADC.
>
> Signed-off-by: Peter Rosin <[email protected]>
> ---
> .../iio/wrapper/io-channel-unit-converter.txt | 84 ++++++++++++++++++++++
Hmm. I'm not convinced by the naming really though I can see where you care
coming from as it can effectively use a voltage ADC to measure a current.
Lets see if the devicetree people or anyone else has a suggestion on this.
Could go with AFE as that is how a chip doing this would normally be described.
It's just that here we are doing it in old fashioned resistors...
There are a few unusual elements in here binding wise so definitely looking
for input on the bindings!
Thanks,
Jonathan
> MAINTAINERS | 6 ++
> 2 files changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> new file mode 100644
> index 000000000000..23af661abe32
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> @@ -0,0 +1,84 @@
> +I/O channel unit converter bindings
> +
> +Allow linear scaling and modification of the type of an io-channel.
I can certainly conceive that we will have simple non linear cases in future
though they get awfully hard to describe so we can tackle that when it
happens.
> +
> +When an ADC channel measures the midpoint of a voltage divider, the
> +interesting voltage is often the voltage over the full resistance
> +of the divider. Likewise, measuring the voltage over a resistor is
> +often a way to get to the current through it.
> +
> +Required properties:
> +- compatible : "io-channel-unit-converter"
> +- io-channels : Channel node of the parent channel.
> +- io-channel-names : Should be "parent".
> +
> +Optional properties:
> +- numerator : The parent channel scale is multiplied by this value (default 1).
> +- denominator : The parent channel scale is divided by this value (default 1).
> +- type : The type of the wrapped channel is modified to this type. The default
> + is to use the same type as the parent channel. Recognized types are:
> + "voltage"
> + "current"
> +
> +Example 1:
> +The system voltage is circa 12V, but divided down with a 22/200
> +voltage divider to adjust it to the ADC range.
> +
> +SYSV ADC GND
> + + + +
> + | .-----. | .----. |
> + '--| 200 |-+-| 22 |--'
> + '-----' '----'
> +
> +sysv {
> + compatible = "io-channel-unit-converter";
> + io-channles = <&maxadc 1>;
> + io-channel-names = "parent";
> +
> + /* multiply the ADC voltage by 222/22 to get the system voltage */
> + numerator = <222>; /* 200 + 22 */
> + denominator = <22>;
> +}
> +
> +&spi {
> + maxadc: adc@0 {
> + compatible = "maxim,max1027";
> + reg = <0>;
> + #io-channel-cells = <1>;
> + interrupt-parent = <&gpio5>;
> + interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> + spi-max-frequency = <1000000>;
> + };
> +};
> +
> +Example 2:
> +The system current is measured by measuring the voltage over a
> +3.3 ohm resistor.
> +
> +sysi {
> + compatible = "io-channel-unit-converter";
> + io-channles = <&tiadc 0>;
> + io-channel-names = "parent";
> +
> + /* divide the ADC voltage by 33/10 (i.e. 3.3) to get current */
> + numerator = <10>;
> + denominator = <33>;
> + type = "current";
> +}
> +
> +&i2c {
> + tiadc: adc@48 {
> + compatible = "ti,ads1015";
> + reg = <0x48>;
> + #io-channel-cells = <1>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 { /* IN0,IN1 differential */
> + reg = <0>;
> + ti,gain = <1>;
> + ti,datarate = <4>;
> + };
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 96e5503bfb60..5dd555c7b1b0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6884,6 +6884,12 @@ F: drivers/staging/iio/
> F: include/linux/iio/
> F: tools/iio/
>
> +IIO UNIT CONVERTER
> +M: Peter Rosin <[email protected]>
> +L: [email protected]
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> +
> IKANOS/ADI EAGLE ADSL USB DRIVER
> M: Matthieu Castet <[email protected]>
> M: Stanislaw Gruszka <[email protected]>
On Mon, 19 Mar 2018 18:02:46 +0100
Peter Rosin <[email protected]> wrote:
> If an ADC channel measures the midpoint of a voltage divider, the
> interesting voltage is often the voltage over the full resistance.
> E.g. if the full voltage it too big for the ADC to handle.
> Likewise, if an ADC channel measures the voltage across a resistor,
> the interesting value is often the current through the resistor.
>
> This driver solves both problems by allowing to linearly scale a channel
> and by allowing changes to the type of the channel. Or both.
>
> Signed-off-by: Peter Rosin <[email protected]>
A few comments inline, but basically the code looks fine, just questions
around naming and bindings to answer.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> drivers/iio/wrapper/Kconfig | 9 ++
> drivers/iio/wrapper/Makefile | 1 +
> drivers/iio/wrapper/iio-unit-converter.c | 268 +++++++++++++++++++++++++++++++
> 4 files changed, 279 insertions(+)
> create mode 100644 drivers/iio/wrapper/iio-unit-converter.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5dd555c7b1b0..b879289f1318 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6889,6 +6889,7 @@ M: Peter Rosin <[email protected]>
> L: [email protected]
> S: Maintained
> F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> +F: drivers/iio/wrapper/iio-unit-converter.c
>
> IKANOS/ADI EAGLE ADSL USB DRIVER
> M: Matthieu Castet <[email protected]>
> diff --git a/drivers/iio/wrapper/Kconfig b/drivers/iio/wrapper/Kconfig
> index f27de347c9b3..16554479264a 100644
> --- a/drivers/iio/wrapper/Kconfig
> +++ b/drivers/iio/wrapper/Kconfig
> @@ -15,4 +15,13 @@ config IIO_MUX
> To compile this driver as a module, choose M here: the
> module will be called iio-mux.
>
> +config IIO_UNIT_CONVERTER
> + tristate "IIO unit converter"
> + depends on OF || COMPILE_TEST
> + help
> + Say yes here to build support for the IIO unit converter.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called iio-unit-converter.
> +
> endmenu
> diff --git a/drivers/iio/wrapper/Makefile b/drivers/iio/wrapper/Makefile
> index 53a7b78734e3..1b9db53bd420 100644
> --- a/drivers/iio/wrapper/Makefile
> +++ b/drivers/iio/wrapper/Makefile
> @@ -4,3 +4,4 @@
>
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_IIO_MUX) += iio-mux.o
> +obj-$(CONFIG_IIO_UNIT_CONVERTER) += iio-unit-converter.o
> diff --git a/drivers/iio/wrapper/iio-unit-converter.c b/drivers/iio/wrapper/iio-unit-converter.c
> new file mode 100644
> index 000000000000..53c126f39e4e
> --- /dev/null
> +++ b/drivers/iio/wrapper/iio-unit-converter.c
> @@ -0,0 +1,268 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * IIO unit converter
> + *
> + * Copyright (C) 2018 Axentia Technologies AB
> + *
> + * Author: Peter Rosin <[email protected]>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/iio/consumer.h>
> +#include <linux/iio/iio.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +
> +struct unit_converter {
> + struct iio_channel *parent;
> + struct iio_dev *indio_dev;
> + struct iio_chan_spec chan;
> + struct iio_chan_spec_ext_info *ext_info;
> + s32 numerator;
> + s32 denominator;
> +};
> +
> +static int unit_converter_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct unit_converter *uc = iio_priv(indio_dev);
> + unsigned long long tmp;
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + return iio_read_channel_raw(uc->parent, val);
> +
> + case IIO_CHAN_INFO_SCALE:
> + ret = iio_read_channel_scale(uc->parent, val, val2);
> + switch (ret) {
> + case IIO_VAL_FRACTIONAL:
> + *val *= uc->numerator;
> + *val2 *= uc->denominator;
> + return ret;
> + case IIO_VAL_INT:
> + *val *= uc->numerator;
> + if (uc->denominator == 1)
> + return ret;
> + *val2 = uc->denominator;
> + return IIO_VAL_FRACTIONAL;
> + case IIO_VAL_FRACTIONAL_LOG2:
> + tmp = *val * 1000000000LL;
> + do_div(tmp, uc->denominator);
> + tmp *= uc->numerator;
> + do_div(tmp, 1000000000LL);
> + *val = tmp;
> + return ret;
> + }
> + return -EOPNOTSUPP;
Slightly clearer and less likely to give warningss from static checkers
if you put that return in a default:
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int unit_converter_read_avail(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + const int **vals, int *type, int *length,
> + long mask)
> +{
> + struct unit_converter *uc = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + *type = IIO_VAL_INT;
> + return iio_read_avail_channel_raw(uc->parent, vals, length);
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int unit_converter_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct unit_converter *uc = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + return iio_write_channel_raw(uc->parent, val);
Talk me through the logic of having this... Supporting a DAC?
Bindings don't talk about that possibility...
> + }
> +
> + return -EINVAL;
> +}
> +
> +static const struct iio_info unit_converter_info = {
> + .read_raw = unit_converter_read_raw,
> + .read_avail = unit_converter_read_avail,
> + .write_raw = unit_converter_write_raw,
> +};
> +
> +static ssize_t unit_converter_read_ext_info(struct iio_dev *indio_dev,
> + uintptr_t private,
> + struct iio_chan_spec const *chan,
> + char *buf)
> +{
> + struct unit_converter *uc = iio_priv(indio_dev);
> +
> + return iio_read_channel_ext_info(uc->parent,
> + uc->ext_info[private].name,
> + buf);
> +}
> +
> +static ssize_t unit_converter_write_ext_info(struct iio_dev *indio_dev,
> + uintptr_t private,
> + struct iio_chan_spec const *chan,
> + const char *buf, size_t len)
> +{
> + struct unit_converter *uc = iio_priv(indio_dev);
> +
> + return iio_write_channel_ext_info(uc->parent,
> + uc->ext_info[private].name,
> + buf, len);
> +}
> +
> +static int unit_converter_configure_channel(struct device *dev,
> + struct unit_converter *uc,
> + enum iio_chan_type type)
> +{
> + struct iio_chan_spec *chan = &uc->chan;
> + struct iio_chan_spec const *pchan = uc->parent->channel;
> + int ret;
> +
> + chan->indexed = 1;
> + chan->output = pchan->output;
> + chan->ext_info = uc->ext_info;
> +
> + if (type == -1) {
> + ret = iio_get_channel_type(uc->parent, &type);
> + if (ret < 0) {
> + dev_err(dev, "failed to get parent channel type\n");
> + return ret;
> + }
> + }
> + chan->type = type;
> +
> + if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
> + chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
if the parent doesn't support RAW, is there a lot of point in carrying on?
> + if (iio_channel_has_info(pchan, IIO_CHAN_INFO_SCALE))
> + chan->info_mask_separate |= BIT(IIO_CHAN_INFO_SCALE);
> +
> + if (iio_channel_has_available(pchan, IIO_CHAN_INFO_RAW))
> + chan->info_mask_separate_available |= BIT(IIO_CHAN_INFO_RAW);
> +
> + chan->channel = 0;
> +
> + return 0;
> +}
> +
> +static int unit_converter_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct iio_dev *indio_dev;
> + struct iio_channel *parent;
> + struct unit_converter *uc;
> + const char *type_name;
> + enum iio_chan_type type = -1; /* default to same as parent */
> + int sizeof_ext_info;
> + int sizeof_priv;
> + int i;
> + int ret;
> +
> + if (!device_property_read_string(dev, "type", &type_name)) {
> + if (!strcmp(type_name, "voltage"))
> + type = IIO_VOLTAGE;
> + else if (!strcmp(type_name, "current"))
> + type = IIO_CURRENT;
> + else
> + return -EINVAL;
> + }
> +
> + parent = devm_iio_channel_get(dev, "parent");
> + if (IS_ERR(parent)) {
> + if (PTR_ERR(parent) != -EPROBE_DEFER)
> + dev_err(dev, "failed to get parent channel\n");
> + return PTR_ERR(parent);
> + }
> +
> + sizeof_ext_info = iio_get_channel_ext_info_count(parent);
> + if (sizeof_ext_info) {
> + sizeof_ext_info += 1; /* one extra entry for the sentinel */
> + sizeof_ext_info *= sizeof(*uc->ext_info);
> + }
> +
> + sizeof_priv = sizeof(*uc) + sizeof_ext_info;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof_priv);
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + uc = iio_priv(indio_dev);
> +
> + uc->numerator = 1;
> + uc->denominator = 1;
> + device_property_read_u32(dev, "numerator", &uc->numerator);
> + device_property_read_u32(dev, "denominator", &uc->denominator);
> + if (!uc->numerator || !uc->denominator) {
> + dev_err(dev, "invalid scaling factor.\n");
> + return -EINVAL;
> + }
> +
> + platform_set_drvdata(pdev, indio_dev);
> +
> + uc->parent = parent;
> +
> + indio_dev->name = dev_name(dev);
> + indio_dev->dev.parent = dev;
> + indio_dev->info = &unit_converter_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = &uc->chan;
> + indio_dev->num_channels = 1;
> + if (sizeof_ext_info) {
> + uc->ext_info = devm_kmemdup(dev,
> + parent->channel->ext_info,
> + sizeof_ext_info, GFP_KERNEL);
> + if (!uc->ext_info)
> + return -ENOMEM;
> +
> + for (i = 0; uc->ext_info[i].name; ++i) {
> + if (parent->channel->ext_info[i].read)
> + uc->ext_info[i].read = unit_converter_read_ext_info;
> + if (parent->channel->ext_info[i].write)
> + uc->ext_info[i].write = unit_converter_write_ext_info;
> + uc->ext_info[i].private = i;
> + }
> + }
> +
> + ret = unit_converter_configure_channel(dev, uc, type);
> + if (ret < 0)
> + return ret;
> +
> + ret = devm_iio_device_register(dev, indio_dev);
> + if (ret) {
> + dev_err(dev, "failed to register iio device\n");
> + return ret;
> + }
Drop the return out of the brackets and get rid of return 0 below.
> +
> + return 0;
> +}
> +
> +static const struct of_device_id unit_converter_match[] = {
> + { .compatible = "io-channel-unit-converter" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, unit_converter_match);
> +
> +static struct platform_driver unit_converter_driver = {
> + .probe = unit_converter_probe,
> + .driver = {
> + .name = "iio-unit-converter",
> + .of_match_table = unit_converter_match,
> + },
> +};
> +module_platform_driver(unit_converter_driver);
> +
> +MODULE_DESCRIPTION("IIO unit converter driver");
> +MODULE_AUTHOR("Peter Rosin <[email protected]>");
> +MODULE_LICENSE("GPL v2");
On Sat, 24 Mar 2018 13:53:19 +0000
Jonathan Cameron <[email protected]> wrote:
> On Mon, 19 Mar 2018 18:02:45 +0100
> Peter Rosin <[email protected]> wrote:
>
> > Allow linear scaling and modification of the type of an io-channel.
> >
> > When an ADC channel measures the midpoint of a voltage divider, the
> > interesting voltage is often the voltage over the full resistance
> > of the divider. Likewise, measuring the voltage over a resistor is
> > often a way to get to the current through it.
> >
> > This binding allows description of such hardware which is external
> > to the ADC.
> >
> > Signed-off-by: Peter Rosin <[email protected]>
> > ---
> > .../iio/wrapper/io-channel-unit-converter.txt | 84 ++++++++++++++++++++++
> Hmm. I'm not convinced by the naming really though I can see where you care
> coming from as it can effectively use a voltage ADC to measure a current.
>
> Lets see if the devicetree people or anyone else has a suggestion on this.
>
> Could go with AFE as that is how a chip doing this would normally be described.
> It's just that here we are doing it in old fashioned resistors...
>
> There are a few unusual elements in here binding wise so definitely looking
> for input on the bindings!
>
> Thanks,
>
> Jonathan
>
> > MAINTAINERS | 6 ++
> > 2 files changed, 90 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> > new file mode 100644
> > index 000000000000..23af661abe32
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> > @@ -0,0 +1,84 @@
> > +I/O channel unit converter bindings
> > +
> > +Allow linear scaling and modification of the type of an io-channel.
> I can certainly conceive that we will have simple non linear cases in future
> though they get awfully hard to describe so we can tackle that when it
> happens.
>
> > +
> > +When an ADC channel measures the midpoint of a voltage divider, the
> > +interesting voltage is often the voltage over the full resistance
> > +of the divider. Likewise, measuring the voltage over a resistor is
> > +often a way to get to the current through it.
> > +
> > +Required properties:
> > +- compatible : "io-channel-unit-converter"
> > +- io-channels : Channel node of the parent channel.
> > +- io-channel-names : Should be "parent".
> > +
> > +Optional properties:
> > +- numerator : The parent channel scale is multiplied by this value (default 1).
> > +- denominator : The parent channel scale is divided by this value (default 1).
> > +- type : The type of the wrapped channel is modified to this type. The default
> > + is to use the same type as the parent channel. Recognized types are:
> > + "voltage"
> > + "current"
> > +
> > +Example 1:
> > +The system voltage is circa 12V, but divided down with a 22/200
> > +voltage divider to adjust it to the ADC range.
> > +
> > +SYSV ADC GND
> > + + + +
> > + | .-----. | .----. |
> > + '--| 200 |-+-| 22 |--'
> > + '-----' '----'
> > +
> > +sysv {
> > + compatible = "io-channel-unit-converter";
> > + io-channles = <&maxadc 1>;
> > + io-channel-names = "parent";
> > +
> > + /* multiply the ADC voltage by 222/22 to get the system voltage */
> > + numerator = <222>; /* 200 + 22 */
> > + denominator = <22>;
> > +}
> > +
> > +&spi {
> > + maxadc: adc@0 {
> > + compatible = "maxim,max1027";
> > + reg = <0>;
> > + #io-channel-cells = <1>;
> > + interrupt-parent = <&gpio5>;
> > + interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> > + spi-max-frequency = <1000000>;
> > + };
> > +};
> > +
> > +Example 2:
> > +The system current is measured by measuring the voltage over a
> > +3.3 ohm resistor.
> > +
> > +sysi {
> > + compatible = "io-channel-unit-converter";
> > + io-channles = <&tiadc 0>;
io-channels and same above.
> > + io-channel-names = "parent";
> > +
> > + /* divide the ADC voltage by 33/10 (i.e. 3.3) to get current */
> > + numerator = <10>;
> > + denominator = <33>;
> > + type = "current";
> > +}
> > +
> > +&i2c {
> > + tiadc: adc@48 {
> > + compatible = "ti,ads1015";
> > + reg = <0x48>;
> > + #io-channel-cells = <1>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + channel@0 { /* IN0,IN1 differential */
> > + reg = <0>;
> > + ti,gain = <1>;
> > + ti,datarate = <4>;
> > + };
> > + };
> > +};
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 96e5503bfb60..5dd555c7b1b0 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -6884,6 +6884,12 @@ F: drivers/staging/iio/
> > F: include/linux/iio/
> > F: tools/iio/
> >
> > +IIO UNIT CONVERTER
> > +M: Peter Rosin <[email protected]>
> > +L: [email protected]
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> > +
> > IKANOS/ADI EAGLE ADSL USB DRIVER
> > M: Matthieu Castet <[email protected]>
> > M: Stanislaw Gruszka <[email protected]>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Mar 24, 2018 at 2:48 PM, Jonathan Cameron <[email protected]> wrote:
> On Fri, 23 Mar 2018 14:59:41 +0100
> Peter Rosin <[email protected]> wrote:
>> So, not super-happy about that either. And maybe leave the mux
>> where it is? It's just that I have the feeling that the iio-mux
>> is never going to get any friends in its category, and the mux
>> and the unit-converter are kind of related in that they operate
>> on other channels. But maybe that's only logical it you know how
>> they are implemented...
>
> Perhaps Analog Front ends?
> We could move the amplifier driver into the same directory as well,
> though right now that driver is not passing the channels through
> (it's often used without there being an IIO ADC behind it I think...)
(passive) linear scaler?
analog linear scaler?
But maybe these supersets are not broad enough.
Or just invent another acronym akin to "PHY" such as
"AIF" (analog interface)?
Yours,
Linus Walleij
On Sat, 24 Mar 2018 17:34:17 +0100
Linus Walleij <[email protected]> wrote:
> On Sat, Mar 24, 2018 at 2:48 PM, Jonathan Cameron <[email protected]> wrote:
> > On Fri, 23 Mar 2018 14:59:41 +0100
> > Peter Rosin <[email protected]> wrote:
>
> >> So, not super-happy about that either. And maybe leave the mux
> >> where it is? It's just that I have the feeling that the iio-mux
> >> is never going to get any friends in its category, and the mux
> >> and the unit-converter are kind of related in that they operate
> >> on other channels. But maybe that's only logical it you know how
> >> they are implemented...
> >
> > Perhaps Analog Front ends?
> > We could move the amplifier driver into the same directory as well,
> > though right now that driver is not passing the channels through
> > (it's often used without there being an IIO ADC behind it I think...)
>
> (passive) linear scaler?
> analog linear scaler?
> But maybe these supersets are not broad enough.
>
> Or just invent another acronym akin to "PHY" such as
> "AIF" (analog interface)?
AFE (analog front end) is commonly used, but I'm not sure if implies
more than we want here. Lars, Michael this is more your area than
mine - what do you think?
We could call it an amplifier and be done with it but that wouldn't
really encompass the fact we are also changing it's apparent measurement
from voltage to current because we know enough about the circuit to do
so...
Jonathan
>
> Yours,
> Linus Walleij
On Mon, Mar 19, 2018 at 06:02:45PM +0100, Peter Rosin wrote:
> Allow linear scaling and modification of the type of an io-channel.
>
> When an ADC channel measures the midpoint of a voltage divider, the
> interesting voltage is often the voltage over the full resistance
> of the divider. Likewise, measuring the voltage over a resistor is
> often a way to get to the current through it.
>
> This binding allows description of such hardware which is external
> to the ADC.
>
> Signed-off-by: Peter Rosin <[email protected]>
> ---
> .../iio/wrapper/io-channel-unit-converter.txt | 84 ++++++++++++++++++++++
> MAINTAINERS | 6 ++
> 2 files changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> new file mode 100644
> index 000000000000..23af661abe32
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> @@ -0,0 +1,84 @@
> +I/O channel unit converter bindings
> +
> +Allow linear scaling and modification of the type of an io-channel.
> +
> +When an ADC channel measures the midpoint of a voltage divider, the
> +interesting voltage is often the voltage over the full resistance
> +of the divider. Likewise, measuring the voltage over a resistor is
> +often a way to get to the current through it.
> +
> +Required properties:
> +- compatible : "io-channel-unit-converter"
Would this apply to something besides ADCs?
> +- io-channels : Channel node of the parent channel.
> +- io-channel-names : Should be "parent".
> +
> +Optional properties:
> +- numerator : The parent channel scale is multiplied by this value (default 1).
> +- denominator : The parent channel scale is divided by this value (default 1).
> +- type : The type of the wrapped channel is modified to this type. The default
> + is to use the same type as the parent channel. Recognized types are:
> + "voltage"
> + "current"
This seems overly complicated for just describing a couple of resistors
on an ADC. OTOH, keeping the ADC node and what's attached to the ADC
separate
Perhaps the type should be part of the compatible. For example, if you
have a current measurement resistor/circuit, then the compatible should
be based on that.
> +
> +Example 1:
> +The system voltage is circa 12V, but divided down with a 22/200
> +voltage divider to adjust it to the ADC range.
> +
> +SYSV ADC GND
> + + + +
> + | .-----. | .----. |
> + '--| 200 |-+-| 22 |--'
> + '-----' '----'
> +
> +sysv {
> + compatible = "io-channel-unit-converter";
> + io-channles = <&maxadc 1>;
> + io-channel-names = "parent";
parent doesn't seem to describe something about the h/w.
> +
> + /* multiply the ADC voltage by 222/22 to get the system voltage */
> + numerator = <222>; /* 200 + 22 */
> + denominator = <22>;
> +}
> +
> +&spi {
> + maxadc: adc@0 {
> + compatible = "maxim,max1027";
> + reg = <0>;
> + #io-channel-cells = <1>;
> + interrupt-parent = <&gpio5>;
> + interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> + spi-max-frequency = <1000000>;
> + };
> +};
> +
> +Example 2:
> +The system current is measured by measuring the voltage over a
> +3.3 ohm resistor.
> +
> +sysi {
> + compatible = "io-channel-unit-converter";
> + io-channles = <&tiadc 0>;
> + io-channel-names = "parent";
> +
> + /* divide the ADC voltage by 33/10 (i.e. 3.3) to get current */
> + numerator = <10>;
> + denominator = <33>;
> + type = "current";
> +}
> +
> +&i2c {
> + tiadc: adc@48 {
> + compatible = "ti,ads1015";
> + reg = <0x48>;
> + #io-channel-cells = <1>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 { /* IN0,IN1 differential */
> + reg = <0>;
> + ti,gain = <1>;
> + ti,datarate = <4>;
> + };
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 96e5503bfb60..5dd555c7b1b0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6884,6 +6884,12 @@ F: drivers/staging/iio/
> F: include/linux/iio/
> F: tools/iio/
>
> +IIO UNIT CONVERTER
> +M: Peter Rosin <[email protected]>
> +L: [email protected]
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
> +
> IKANOS/ADI EAGLE ADSL USB DRIVER
> M: Matthieu Castet <[email protected]>
> M: Stanislaw Gruszka <[email protected]>
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2018-03-24 15:03, Jonathan Cameron wrote:
> On Mon, 19 Mar 2018 18:02:46 +0100
> Peter Rosin <[email protected]> wrote:
>
>> If an ADC channel measures the midpoint of a voltage divider, the
>> interesting voltage is often the voltage over the full resistance.
>> E.g. if the full voltage it too big for the ADC to handle.
>> Likewise, if an ADC channel measures the voltage across a resistor,
>> the interesting value is often the current through the resistor.
>>
>> This driver solves both problems by allowing to linearly scale a channel
>> and by allowing changes to the type of the channel. Or both.
>>
>> Signed-off-by: Peter Rosin <[email protected]>
> A few comments inline, but basically the code looks fine, just questions
> around naming and bindings to answer.
>
> Thanks,
>
> Jonathan
>
*snip*
>> +static int unit_converter_write_raw(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan,
>> + int val, int val2, long mask)
>> +{
>> + struct unit_converter *uc = iio_priv(indio_dev);
>> +
>> + switch (mask) {
>> + case IIO_CHAN_INFO_RAW:
>> + return iio_write_channel_raw(uc->parent, val);
> Talk me through the logic of having this... Supporting a DAC?
> Bindings don't talk about that possibility...
There's no logic at all, and I don't need it. It's just leftovers,
should I remove it?
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +
*snip*
>> +static int unit_converter_configure_channel(struct device *dev,
>> + struct unit_converter *uc,
>> + enum iio_chan_type type)
>> +{
>> + struct iio_chan_spec *chan = &uc->chan;
>> + struct iio_chan_spec const *pchan = uc->parent->channel;
>> + int ret;
>> +
>> + chan->indexed = 1;
>> + chan->output = pchan->output;
>> + chan->ext_info = uc->ext_info;
>> +
>> + if (type == -1) {
>> + ret = iio_get_channel_type(uc->parent, &type);
>> + if (ret < 0) {
>> + dev_err(dev, "failed to get parent channel type\n");
>> + return ret;
>> + }
>> + }
>> + chan->type = type;
>> +
>> + if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
>> + chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
> if the parent doesn't support RAW, is there a lot of point in carrying on?
Nope, better to error out I suppose. But I'm not familiar with channels
without RAW, what alternatives are there anyway?
>> + if (iio_channel_has_info(pchan, IIO_CHAN_INFO_SCALE))
>> + chan->info_mask_separate |= BIT(IIO_CHAN_INFO_SCALE);
>> +
>> + if (iio_channel_has_available(pchan, IIO_CHAN_INFO_RAW))
>> + chan->info_mask_separate_available |= BIT(IIO_CHAN_INFO_RAW);
>> +
>> + chan->channel = 0;
>> +
>> + return 0;
>> +}
On 2018-03-27 00:23, Rob Herring wrote:
> On Mon, Mar 19, 2018 at 06:02:45PM +0100, Peter Rosin wrote:
>> Allow linear scaling and modification of the type of an io-channel.
>>
>> When an ADC channel measures the midpoint of a voltage divider, the
>> interesting voltage is often the voltage over the full resistance
>> of the divider. Likewise, measuring the voltage over a resistor is
>> often a way to get to the current through it.
>>
>> This binding allows description of such hardware which is external
>> to the ADC.
>>
>> Signed-off-by: Peter Rosin <[email protected]>
>> ---
>> .../iio/wrapper/io-channel-unit-converter.txt | 84 ++++++++++++++++++++++
>> MAINTAINERS | 6 ++
>> 2 files changed, 90 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>> new file mode 100644
>> index 000000000000..23af661abe32
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>> @@ -0,0 +1,84 @@
>> +I/O channel unit converter bindings
>> +
>> +Allow linear scaling and modification of the type of an io-channel.
>> +
>> +When an ADC channel measures the midpoint of a voltage divider, the
>> +interesting voltage is often the voltage over the full resistance
>> +of the divider. Likewise, measuring the voltage over a resistor is
>> +often a way to get to the current through it.
>> +
>> +Required properties:
>> +- compatible : "io-channel-unit-converter"
>
> Would this apply to something besides ADCs?
Not that I can think of. At the moment.
>> +- io-channels : Channel node of the parent channel.
>> +- io-channel-names : Should be "parent".
>> +
>> +Optional properties:
>> +- numerator : The parent channel scale is multiplied by this value (default 1).
>> +- denominator : The parent channel scale is divided by this value (default 1).
>> +- type : The type of the wrapped channel is modified to this type. The default
>> + is to use the same type as the parent channel. Recognized types are:
>> + "voltage"
>> + "current"
>
> This seems overly complicated for just describing a couple of resistors
> on an ADC. OTOH, keeping the ADC node and what's attached to the ADC
> separate
>
> Perhaps the type should be part of the compatible. For example, if you
> have a current measurement resistor/circuit, then the compatible should
> be based on that.
Is a compatible like "current-sense-circuit" too long(ish)? Is a
vendor prefix absolutely required? Sure, I can use "axentia,"
because we "implemented" the circuit this time, but it seems like
the list can grow very long if we should add every vendor that
may use something like this? Something more generic would be good
for something as simple as this IMHO.
I propose the compatible "voltage-divider" for the other example,
but I have the same issue with the vendor prefix. Even more so
in this case.
Then the above type can be inferred from the compatible. I suppose
I should write the above two bindings as two separate files?
>> +
>> +Example 1:
>> +The system voltage is circa 12V, but divided down with a 22/200
>> +voltage divider to adjust it to the ADC range.
>> +
>> +SYSV ADC GND
>> + + + +
>> + | .-----. | .----. |
>> + '--| 200 |-+-| 22 |--'
>> + '-----' '----'
>> +
>> +sysv {
>> + compatible = "io-channel-unit-converter";
>> + io-channles = <&maxadc 1>;
>> + io-channel-names = "parent";
>
> parent doesn't seem to describe something about the h/w.
Extrapolating from your first question, you are thinking "adc", right?
Cheers,
Peter
>> +
>> + /* multiply the ADC voltage by 222/22 to get the system voltage */
>> + numerator = <222>; /* 200 + 22 */
>> + denominator = <22>;
>> +}
>> +
>> +&spi {
>> + maxadc: adc@0 {
>> + compatible = "maxim,max1027";
>> + reg = <0>;
>> + #io-channel-cells = <1>;
>> + interrupt-parent = <&gpio5>;
>> + interrupts = <15 IRQ_TYPE_EDGE_RISING>;
>> + spi-max-frequency = <1000000>;
>> + };
>> +};
>> +
>> +Example 2:
>> +The system current is measured by measuring the voltage over a
>> +3.3 ohm resistor.
>> +
>> +sysi {
>> + compatible = "io-channel-unit-converter";
>> + io-channles = <&tiadc 0>;
>> + io-channel-names = "parent";
>> +
>> + /* divide the ADC voltage by 33/10 (i.e. 3.3) to get current */
>> + numerator = <10>;
>> + denominator = <33>;
>> + type = "current";
>> +}
>> +
>> +&i2c {
>> + tiadc: adc@48 {
>> + compatible = "ti,ads1015";
>> + reg = <0x48>;
>> + #io-channel-cells = <1>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + channel@0 { /* IN0,IN1 differential */
>> + reg = <0>;
>> + ti,gain = <1>;
>> + ti,datarate = <4>;
>> + };
>> + };
>> +};
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 96e5503bfb60..5dd555c7b1b0 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6884,6 +6884,12 @@ F: drivers/staging/iio/
>> F: include/linux/iio/
>> F: tools/iio/
>>
>> +IIO UNIT CONVERTER
>> +M: Peter Rosin <[email protected]>
>> +L: [email protected]
>> +S: Maintained
>> +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>> +
>> IKANOS/ADI EAGLE ADSL USB DRIVER
>> M: Matthieu Castet <[email protected]>
>> M: Stanislaw Gruszka <[email protected]>
>> --
>> 2.11.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 27 Mar 2018 09:42:40 +0200
Peter Rosin <[email protected]> wrote:
> On 2018-03-24 15:03, Jonathan Cameron wrote:
> > On Mon, 19 Mar 2018 18:02:46 +0100
> > Peter Rosin <[email protected]> wrote:
> >
> >> If an ADC channel measures the midpoint of a voltage divider, the
> >> interesting voltage is often the voltage over the full resistance.
> >> E.g. if the full voltage it too big for the ADC to handle.
> >> Likewise, if an ADC channel measures the voltage across a resistor,
> >> the interesting value is often the current through the resistor.
> >>
> >> This driver solves both problems by allowing to linearly scale a channel
> >> and by allowing changes to the type of the channel. Or both.
> >>
> >> Signed-off-by: Peter Rosin <[email protected]>
> > A few comments inline, but basically the code looks fine, just questions
> > around naming and bindings to answer.
> >
> > Thanks,
> >
> > Jonathan
> >
>
> *snip*
>
> >> +static int unit_converter_write_raw(struct iio_dev *indio_dev,
> >> + struct iio_chan_spec const *chan,
> >> + int val, int val2, long mask)
> >> +{
> >> + struct unit_converter *uc = iio_priv(indio_dev);
> >> +
> >> + switch (mask) {
> >> + case IIO_CHAN_INFO_RAW:
> >> + return iio_write_channel_raw(uc->parent, val);
> > Talk me through the logic of having this... Supporting a DAC?
> > Bindings don't talk about that possibility...
>
> There's no logic at all, and I don't need it. It's just leftovers,
> should I remove it?
>
> >> + }
> >> +
> >> + return -EINVAL;
> >> +}
> >> +
>
> *snip*
>
> >> +static int unit_converter_configure_channel(struct device *dev,
> >> + struct unit_converter *uc,
> >> + enum iio_chan_type type)
> >> +{
> >> + struct iio_chan_spec *chan = &uc->chan;
> >> + struct iio_chan_spec const *pchan = uc->parent->channel;
> >> + int ret;
> >> +
> >> + chan->indexed = 1;
> >> + chan->output = pchan->output;
> >> + chan->ext_info = uc->ext_info;
> >> +
> >> + if (type == -1) {
> >> + ret = iio_get_channel_type(uc->parent, &type);
> >> + if (ret < 0) {
> >> + dev_err(dev, "failed to get parent channel type\n");
> >> + return ret;
> >> + }
> >> + }
> >> + chan->type = type;
> >> +
> >> + if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
> >> + chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
> > if the parent doesn't support RAW, is there a lot of point in carrying on?
>
> Nope, better to error out I suppose. But I'm not familiar with channels
> without RAW, what alternatives are there anyway?
Potentially _PROCESSED though that will need somewhat different handling.
A nasty trick for that might be to map it to RAW and then have the SCALE
reflect the divider circuit scale only.
It's perfectly possible to have channels with neither _RAW or _PROCESSED
but I suspect we don't care about them here.
There might be an application that needs to do buffered data flows in the
long run, but we can figure out how to do that when one exists.
It won't be a huge amount more than you have here, though we might need
a trigger pass through as well to allow you to set the trigger for
the front end and having it automatically applied to the backend.
Jonathan
>
> >> + if (iio_channel_has_info(pchan, IIO_CHAN_INFO_SCALE))
> >> + chan->info_mask_separate |= BIT(IIO_CHAN_INFO_SCALE);
> >> +
> >> + if (iio_channel_has_available(pchan, IIO_CHAN_INFO_RAW))
> >> + chan->info_mask_separate_available |= BIT(IIO_CHAN_INFO_RAW);
> >> +
> >> + chan->channel = 0;
> >> +
> >> + return 0;
> >> +}
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2018-03-27 15:22, Jonathan Cameron wrote:
> On Tue, 27 Mar 2018 09:42:40 +0200
> Peter Rosin <[email protected]> wrote:
>> On 2018-03-24 15:03, Jonathan Cameron wrote:
>>> On Mon, 19 Mar 2018 18:02:46 +0100
>>> Peter Rosin <[email protected]> wrote:
>>>> + if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
>>>> + chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
>>> if the parent doesn't support RAW, is there a lot of point in carrying on?
>>
>> Nope, better to error out I suppose. But I'm not familiar with channels
>> without RAW, what alternatives are there anyway?
>
> Potentially _PROCESSED though that will need somewhat different handling.
> A nasty trick for that might be to map it to RAW and then have the SCALE
> reflect the divider circuit scale only.
Hmm, I think a lot of things might assume RAW to be a pure integer, and
maybe they are even correct to do so? So yes, that seems nasty indeed...
> It's perfectly possible to have channels with neither _RAW or _PROCESSED
> but I suspect we don't care about them here.
>
> There might be an application that needs to do buffered data flows in the
> long run, but we can figure out how to do that when one exists.
>
> It won't be a huge amount more than you have here, though we might need
> a trigger pass through as well to allow you to set the trigger for
> the front end and having it automatically applied to the backend.
Yes, this is the same for the iio-mux. I don't need it, I in fact need
very little bandwidth for these things. Someone with an itch will have
to fill in the buffer/trigger handling...
Cheers,
Peter
On 27/03/2018 16:01, Peter Rosin wrote:
> On 2018-03-27 00:23, Rob Herring wrote:
>> On Mon, Mar 19, 2018 at 06:02:45PM +0100, Peter Rosin wrote:
>>> Allow linear scaling and modification of the type of an io-channel.
>>>
>>> When an ADC channel measures the midpoint of a voltage divider, the
>>> interesting voltage is often the voltage over the full resistance
>>> of the divider. Likewise, measuring the voltage over a resistor is
>>> often a way to get to the current through it.
>>>
>>> This binding allows description of such hardware which is external
>>> to the ADC.
>>>
*snip*
>>> +++ b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>>> @@ -0,0 +1,84 @@
>>> +I/O channel unit converter bindings
>>> +
>>> +Allow linear scaling and modification of the type of an io-channel.
>>> +
>>> +When an ADC channel measures the midpoint of a voltage divider, the
>>> +interesting voltage is often the voltage over the full resistance
>>> +of the divider. Likewise, measuring the voltage over a resistor is
>>> +often a way to get to the current through it.
>>> +
>>> +Required properties:
>>> +- compatible : "io-channel-unit-converter"
>> Would this apply to something besides ADCs?
> Not that I can think of. At the moment.
>
I like the concept. I can think of use case on my end to set a RADC (digital pot)
to set a threshold voltage. Being able to define the hardware scaling in the dt would be nice.
Which would allow all the hardware definition to be in the dt which would nice.
So this would be voltage -> resistance.
Setting a DAC voltage to set output current is also a distinct possibility.
--
Regards
Phil Reid
On Tue, Mar 27, 2018 at 3:01 AM, Peter Rosin <[email protected]> wrote:
> On 2018-03-27 00:23, Rob Herring wrote:
>> On Mon, Mar 19, 2018 at 06:02:45PM +0100, Peter Rosin wrote:
>>> Allow linear scaling and modification of the type of an io-channel.
>>>
>>> When an ADC channel measures the midpoint of a voltage divider, the
>>> interesting voltage is often the voltage over the full resistance
>>> of the divider. Likewise, measuring the voltage over a resistor is
>>> often a way to get to the current through it.
>>>
>>> This binding allows description of such hardware which is external
>>> to the ADC.
>>>
>>> Signed-off-by: Peter Rosin <[email protected]>
>>> ---
>>> .../iio/wrapper/io-channel-unit-converter.txt | 84 ++++++++++++++++++++++
>>> MAINTAINERS | 6 ++
>>> 2 files changed, 90 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>>> new file mode 100644
>>> index 000000000000..23af661abe32
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>>> @@ -0,0 +1,84 @@
>>> +I/O channel unit converter bindings
>>> +
>>> +Allow linear scaling and modification of the type of an io-channel.
>>> +
>>> +When an ADC channel measures the midpoint of a voltage divider, the
>>> +interesting voltage is often the voltage over the full resistance
>>> +of the divider. Likewise, measuring the voltage over a resistor is
>>> +often a way to get to the current through it.
>>> +
>>> +Required properties:
>>> +- compatible : "io-channel-unit-converter"
>>
>> Would this apply to something besides ADCs?
>
> Not that I can think of. At the moment.
>
>>> +- io-channels : Channel node of the parent channel.
>>> +- io-channel-names : Should be "parent".
>>> +
>>> +Optional properties:
>>> +- numerator : The parent channel scale is multiplied by this value (default 1).
>>> +- denominator : The parent channel scale is divided by this value (default 1).
>>> +- type : The type of the wrapped channel is modified to this type. The default
>>> + is to use the same type as the parent channel. Recognized types are:
>>> + "voltage"
>>> + "current"
>>
>> This seems overly complicated for just describing a couple of resistors
>> on an ADC. OTOH, keeping the ADC node and what's attached to the ADC
>> separate
>>
>> Perhaps the type should be part of the compatible. For example, if you
>> have a current measurement resistor/circuit, then the compatible should
>> be based on that.
>
> Is a compatible like "current-sense-circuit" too long(ish)?
No, that's fine.
> Is a vendor prefix absolutely required?
No, it can be common.
> Sure, I can use "axentia,"
> because we "implemented" the circuit this time, but it seems like
> the list can grow very long if we should add every vendor that
> may use something like this? Something more generic would be good
> for something as simple as this IMHO.
>
> I propose the compatible "voltage-divider" for the other example,
> but I have the same issue with the vendor prefix. Even more so
> in this case.
"voltage-divider" doesn't really say what the purpose is.
>
> Then the above type can be inferred from the compatible. I suppose
> I should write the above two bindings as two separate files?
One is fine if the only difference is the compatible.
>>> +
>>> +Example 1:
>>> +The system voltage is circa 12V, but divided down with a 22/200
>>> +voltage divider to adjust it to the ADC range.
>>> +
>>> +SYSV ADC GND
>>> + + + +
>>> + | .-----. | .----. |
>>> + '--| 200 |-+-| 22 |--'
>>> + '-----' '----'
>>> +
>>> +sysv {
>>> + compatible = "io-channel-unit-converter";
>>> + io-channles = <&maxadc 1>;
>>> + io-channel-names = "parent";
>>
>> parent doesn't seem to describe something about the h/w.
>
> Extrapolating from your first question, you are thinking "adc", right?
I don't really have any suggestion. With only 1 channel, there's not
really much point to having a name at all.
Rob
On Tue, 27 Mar 2018 15:32:13 +0200
Peter Rosin <[email protected]> wrote:
> On 2018-03-27 15:22, Jonathan Cameron wrote:
> > On Tue, 27 Mar 2018 09:42:40 +0200
> > Peter Rosin <[email protected]> wrote:
> >> On 2018-03-24 15:03, Jonathan Cameron wrote:
> >>> On Mon, 19 Mar 2018 18:02:46 +0100
> >>> Peter Rosin <[email protected]> wrote:
> >>>> + if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
> >>>> + chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
> >>> if the parent doesn't support RAW, is there a lot of point in carrying on?
> >>
> >> Nope, better to error out I suppose. But I'm not familiar with channels
> >> without RAW, what alternatives are there anyway?
> >
> > Potentially _PROCESSED though that will need somewhat different handling.
> > A nasty trick for that might be to map it to RAW and then have the SCALE
> > reflect the divider circuit scale only.
>
> Hmm, I think a lot of things might assume RAW to be a pure integer, and
> maybe they are even correct to do so? So yes, that seems nasty indeed...
Seems unlikely to occur often as ADCs are mostly linear, but you never
know... We'll figure it out when it happens.
>
> > It's perfectly possible to have channels with neither _RAW or _PROCESSED
> > but I suspect we don't care about them here.
> >
> > There might be an application that needs to do buffered data flows in the
> > long run, but we can figure out how to do that when one exists.
> >
> > It won't be a huge amount more than you have here, though we might need
> > a trigger pass through as well to allow you to set the trigger for
> > the front end and having it automatically applied to the backend.
>
> Yes, this is the same for the iio-mux. I don't need it, I in fact need
> very little bandwidth for these things. Someone with an itch will have
> to fill in the buffer/trigger handling...
Absolutely!
>
> Cheers,
> Peter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2018-03-29 15:55, Rob Herring wrote:
> On Tue, Mar 27, 2018 at 3:01 AM, Peter Rosin <[email protected]> wrote:
>> On 2018-03-27 00:23, Rob Herring wrote:
>>> On Mon, Mar 19, 2018 at 06:02:45PM +0100, Peter Rosin wrote:
>>>> Allow linear scaling and modification of the type of an io-channel.
>>>>
>>>> When an ADC channel measures the midpoint of a voltage divider, the
>>>> interesting voltage is often the voltage over the full resistance
>>>> of the divider. Likewise, measuring the voltage over a resistor is
>>>> often a way to get to the current through it.
>>>>
>>>> This binding allows description of such hardware which is external
>>>> to the ADC.
>>>>
>>>> Signed-off-by: Peter Rosin <[email protected]>
>>>> ---
>>>> .../iio/wrapper/io-channel-unit-converter.txt | 84 ++++++++++++++++++++++
>>>> MAINTAINERS | 6 ++
>>>> 2 files changed, 90 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>>>> new file mode 100644
>>>> index 000000000000..23af661abe32
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt
>>>> @@ -0,0 +1,84 @@
>>>> +I/O channel unit converter bindings
>>>> +
>>>> +Allow linear scaling and modification of the type of an io-channel.
>>>> +
>>>> +When an ADC channel measures the midpoint of a voltage divider, the
>>>> +interesting voltage is often the voltage over the full resistance
>>>> +of the divider. Likewise, measuring the voltage over a resistor is
>>>> +often a way to get to the current through it.
>>>> +
>>>> +Required properties:
>>>> +- compatible : "io-channel-unit-converter"
>>>
>>> Would this apply to something besides ADCs?
>>
>> Not that I can think of. At the moment.
>>
>>>> +- io-channels : Channel node of the parent channel.
>>>> +- io-channel-names : Should be "parent".
>>>> +
>>>> +Optional properties:
>>>> +- numerator : The parent channel scale is multiplied by this value (default 1).
>>>> +- denominator : The parent channel scale is divided by this value (default 1).
>>>> +- type : The type of the wrapped channel is modified to this type. The default
>>>> + is to use the same type as the parent channel. Recognized types are:
>>>> + "voltage"
>>>> + "current"
>>>
>>> This seems overly complicated for just describing a couple of resistors
>>> on an ADC. OTOH, keeping the ADC node and what's attached to the ADC
>>> separate
>>>
>>> Perhaps the type should be part of the compatible. For example, if you
>>> have a current measurement resistor/circuit, then the compatible should
>>> be based on that.
>>
>> Is a compatible like "current-sense-circuit" too long(ish)?
>
> No, that's fine.
>
>> Is a vendor prefix absolutely required?
>
> No, it can be common.
>
>> Sure, I can use "axentia,"
>> because we "implemented" the circuit this time, but it seems like
>> the list can grow very long if we should add every vendor that
>> may use something like this? Something more generic would be good
>> for something as simple as this IMHO.
>>
>> I propose the compatible "voltage-divider" for the other example,
>> but I have the same issue with the vendor prefix. Even more so
>> in this case.
>
> "voltage-divider" doesn't really say what the purpose is.
No, but it says what it *is*, which is pretty much what the compatible
is all about? If you have, I don't know, let's pick some regulator, you
don't expect the compatible to give any details of the purpose. Not
other than regulating of course. But a voltage divider pretty much divides
a voltage, much like a regulator regulates, and that's it. The node name
should be what hints at the purpose, no?
>>
>> Then the above type can be inferred from the compatible. I suppose
>> I should write the above two bindings as two separate files?
>
> One is fine if the only difference is the compatible.
>
>>>> +
>>>> +Example 1:
>>>> +The system voltage is circa 12V, but divided down with a 22/200
>>>> +voltage divider to adjust it to the ADC range.
>>>> +
>>>> +SYSV ADC GND
>>>> + + + +
>>>> + | .-----. | .----. |
>>>> + '--| 200 |-+-| 22 |--'
>>>> + '-----' '----'
>>>> +
>>>> +sysv {
>>>> + compatible = "io-channel-unit-converter";
>>>> + io-channles = <&maxadc 1>;
>>>> + io-channel-names = "parent";
>>>
>>> parent doesn't seem to describe something about the h/w.
>>
>> Extrapolating from your first question, you are thinking "adc", right?
>
> I don't really have any suggestion. With only 1 channel, there's not
> really much point to having a name at all.
Right, I'm ditching the -names line.
Cheers,
Peter