* [PATCH 0/3] iio: add unit converter @ 2018-03-19 17:02 Peter Rosin 2018-03-19 17:02 ` [PATCH 1/3] iio: rename the multiplexer category to wrapper Peter Rosin ` (3 more replies) 0 siblings, 4 replies; 22+ messages in thread From: Peter Rosin @ 2018-03-19 17:02 UTC (permalink / raw) To: linux-kernel Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/3] iio: rename the multiplexer category to wrapper 2018-03-19 17:02 [PATCH 0/3] iio: add unit converter Peter Rosin @ 2018-03-19 17:02 ` Peter Rosin 2018-03-19 18:36 ` Randy Dunlap 2018-03-19 17:02 ` [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter Peter Rosin ` (2 subsequent siblings) 3 siblings, 1 reply; 22+ messages in thread From: Peter Rosin @ 2018-03-19 17:02 UTC (permalink / raw) To: linux-kernel Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree Paves the way for other wrappers. Signed-off-by: Peter Rosin <peda@axentia.se> --- .../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 <peda@axentia.se> L: linux-iio@vger.kernel.org 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 <jic23@kernel.org> 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/3] iio: rename the multiplexer category to wrapper 2018-03-19 17:02 ` [PATCH 1/3] iio: rename the multiplexer category to wrapper Peter Rosin @ 2018-03-19 18:36 ` Randy Dunlap 0 siblings, 0 replies; 22+ messages in thread From: Randy Dunlap @ 2018-03-19 18:36 UTC (permalink / raw) To: Peter Rosin, linux-kernel Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, linux-iio, devicetree On 03/19/2018 10:02 AM, Peter Rosin wrote: > Paves the way for other wrappers. > > Signed-off-by: Peter Rosin <peda@axentia.se> > --- > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter 2018-03-19 17:02 [PATCH 0/3] iio: add unit converter Peter Rosin 2018-03-19 17:02 ` [PATCH 1/3] iio: rename the multiplexer category to wrapper Peter Rosin @ 2018-03-19 17:02 ` Peter Rosin 2018-03-24 13:53 ` Jonathan Cameron 2018-03-26 22:23 ` Rob Herring 2018-03-19 17:02 ` [PATCH 3/3] iio: wrapper: unit-converter: new driver Peter Rosin 2018-03-23 13:14 ` [PATCH 0/3] iio: add unit converter Jonathan Cameron 3 siblings, 2 replies; 22+ messages in thread From: Peter Rosin @ 2018-03-19 17:02 UTC (permalink / raw) To: linux-kernel Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree 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 <peda@axentia.se> --- .../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 <peda@axentia.se> +L: linux-iio@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt + IKANOS/ADI EAGLE ADSL USB DRIVER M: Matthieu Castet <castet.matthieu@free.fr> M: Stanislaw Gruszka <stf_xl@wp.pl> -- 2.11.0 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter 2018-03-19 17:02 ` [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter Peter Rosin @ 2018-03-24 13:53 ` Jonathan Cameron 2018-03-24 14:06 ` Jonathan Cameron 2018-03-26 22:23 ` Rob Herring 1 sibling, 1 reply; 22+ messages in thread From: Jonathan Cameron @ 2018-03-24 13:53 UTC (permalink / raw) To: Peter Rosin Cc: linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On Mon, 19 Mar 2018 18:02:45 +0100 Peter Rosin <peda@axentia.se> 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 <peda@axentia.se> > --- > .../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 <peda@axentia.se> > +L: linux-iio@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt > + > IKANOS/ADI EAGLE ADSL USB DRIVER > M: Matthieu Castet <castet.matthieu@free.fr> > M: Stanislaw Gruszka <stf_xl@wp.pl> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter 2018-03-24 13:53 ` Jonathan Cameron @ 2018-03-24 14:06 ` Jonathan Cameron 0 siblings, 0 replies; 22+ messages in thread From: Jonathan Cameron @ 2018-03-24 14:06 UTC (permalink / raw) To: Peter Rosin Cc: linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On Sat, 24 Mar 2018 13:53:19 +0000 Jonathan Cameron <jic23@kernel.org> wrote: > On Mon, 19 Mar 2018 18:02:45 +0100 > Peter Rosin <peda@axentia.se> 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 <peda@axentia.se> > > --- > > .../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 <peda@axentia.se> > > +L: linux-iio@vger.kernel.org > > +S: Maintained > > +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt > > + > > IKANOS/ADI EAGLE ADSL USB DRIVER > > M: Matthieu Castet <castet.matthieu@free.fr> > > M: Stanislaw Gruszka <stf_xl@wp.pl> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter 2018-03-19 17:02 ` [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter Peter Rosin 2018-03-24 13:53 ` Jonathan Cameron @ 2018-03-26 22:23 ` Rob Herring 2018-03-27 8:01 ` Peter Rosin 1 sibling, 1 reply; 22+ messages in thread From: Rob Herring @ 2018-03-26 22:23 UTC (permalink / raw) To: Peter Rosin Cc: linux-kernel, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree 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 <peda@axentia.se> > --- > .../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 <peda@axentia.se> > +L: linux-iio@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt > + > IKANOS/ADI EAGLE ADSL USB DRIVER > M: Matthieu Castet <castet.matthieu@free.fr> > M: Stanislaw Gruszka <stf_xl@wp.pl> > -- > 2.11.0 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter 2018-03-26 22:23 ` Rob Herring @ 2018-03-27 8:01 ` Peter Rosin 2018-03-28 2:29 ` Phil Reid 2018-03-29 13:55 ` Rob Herring 0 siblings, 2 replies; 22+ messages in thread From: Peter Rosin @ 2018-03-27 8:01 UTC (permalink / raw) To: Rob Herring Cc: linux-kernel, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree 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 <peda@axentia.se> >> --- >> .../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 <peda@axentia.se> >> +L: linux-iio@vger.kernel.org >> +S: Maintained >> +F: Documentation/devicetree/bindings/iio/wrapper/io-channel-unit-converter.txt >> + >> IKANOS/ADI EAGLE ADSL USB DRIVER >> M: Matthieu Castet <castet.matthieu@free.fr> >> M: Stanislaw Gruszka <stf_xl@wp.pl> >> -- >> 2.11.0 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter 2018-03-27 8:01 ` Peter Rosin @ 2018-03-28 2:29 ` Phil Reid 2018-03-29 13:55 ` Rob Herring 1 sibling, 0 replies; 22+ messages in thread From: Phil Reid @ 2018-03-28 2:29 UTC (permalink / raw) To: Peter Rosin, Rob Herring Cc: linux-kernel, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter 2018-03-27 8:01 ` Peter Rosin 2018-03-28 2:29 ` Phil Reid @ 2018-03-29 13:55 ` Rob Herring 2018-03-30 22:38 ` Peter Rosin 1 sibling, 1 reply; 22+ messages in thread From: Rob Herring @ 2018-03-29 13:55 UTC (permalink / raw) To: Peter Rosin Cc: linux-kernel, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On Tue, Mar 27, 2018 at 3:01 AM, Peter Rosin <peda@axentia.se> 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 <peda@axentia.se> >>> --- >>> .../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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter 2018-03-29 13:55 ` Rob Herring @ 2018-03-30 22:38 ` Peter Rosin 0 siblings, 0 replies; 22+ messages in thread From: Peter Rosin @ 2018-03-30 22:38 UTC (permalink / raw) To: Rob Herring Cc: linux-kernel, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On 2018-03-29 15:55, Rob Herring wrote: > On Tue, Mar 27, 2018 at 3:01 AM, Peter Rosin <peda@axentia.se> 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 <peda@axentia.se> >>>> --- >>>> .../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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 3/3] iio: wrapper: unit-converter: new driver 2018-03-19 17:02 [PATCH 0/3] iio: add unit converter Peter Rosin 2018-03-19 17:02 ` [PATCH 1/3] iio: rename the multiplexer category to wrapper Peter Rosin 2018-03-19 17:02 ` [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter Peter Rosin @ 2018-03-19 17:02 ` Peter Rosin 2018-03-24 14:03 ` Jonathan Cameron 2018-03-23 13:14 ` [PATCH 0/3] iio: add unit converter Jonathan Cameron 3 siblings, 1 reply; 22+ messages in thread From: Peter Rosin @ 2018-03-19 17:02 UTC (permalink / raw) To: linux-kernel Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree 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 <peda@axentia.se> --- 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 <peda@axentia.se> L: linux-iio@vger.kernel.org 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 <castet.matthieu@free.fr> 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 <peda@axentia.se> + */ + +#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 <peda@axentia.se>"); +MODULE_LICENSE("GPL v2"); -- 2.11.0 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] iio: wrapper: unit-converter: new driver 2018-03-19 17:02 ` [PATCH 3/3] iio: wrapper: unit-converter: new driver Peter Rosin @ 2018-03-24 14:03 ` Jonathan Cameron 2018-03-27 7:42 ` Peter Rosin 0 siblings, 1 reply; 22+ messages in thread From: Jonathan Cameron @ 2018-03-24 14:03 UTC (permalink / raw) To: Peter Rosin Cc: linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On Mon, 19 Mar 2018 18:02:46 +0100 Peter Rosin <peda@axentia.se> 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 <peda@axentia.se> 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 <peda@axentia.se> > L: linux-iio@vger.kernel.org > 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 <castet.matthieu@free.fr> > 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 <peda@axentia.se> > + */ > + > +#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 <peda@axentia.se>"); > +MODULE_LICENSE("GPL v2"); ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] iio: wrapper: unit-converter: new driver 2018-03-24 14:03 ` Jonathan Cameron @ 2018-03-27 7:42 ` Peter Rosin 2018-03-27 13:22 ` Jonathan Cameron 0 siblings, 1 reply; 22+ messages in thread From: Peter Rosin @ 2018-03-27 7:42 UTC (permalink / raw) To: Jonathan Cameron Cc: linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On 2018-03-24 15:03, Jonathan Cameron wrote: > On Mon, 19 Mar 2018 18:02:46 +0100 > Peter Rosin <peda@axentia.se> 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 <peda@axentia.se> > 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; >> +} ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] iio: wrapper: unit-converter: new driver 2018-03-27 7:42 ` Peter Rosin @ 2018-03-27 13:22 ` Jonathan Cameron 2018-03-27 13:32 ` Peter Rosin 0 siblings, 1 reply; 22+ messages in thread From: Jonathan Cameron @ 2018-03-27 13:22 UTC (permalink / raw) To: Peter Rosin Cc: Jonathan Cameron, linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On Tue, 27 Mar 2018 09:42:40 +0200 Peter Rosin <peda@axentia.se> wrote: > On 2018-03-24 15:03, Jonathan Cameron wrote: > > On Mon, 19 Mar 2018 18:02:46 +0100 > > Peter Rosin <peda@axentia.se> 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 <peda@axentia.se> > > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] iio: wrapper: unit-converter: new driver 2018-03-27 13:22 ` Jonathan Cameron @ 2018-03-27 13:32 ` Peter Rosin 2018-03-30 9:24 ` Jonathan Cameron 0 siblings, 1 reply; 22+ messages in thread From: Peter Rosin @ 2018-03-27 13:32 UTC (permalink / raw) To: Jonathan Cameron Cc: Jonathan Cameron, linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On 2018-03-27 15:22, Jonathan Cameron wrote: > On Tue, 27 Mar 2018 09:42:40 +0200 > Peter Rosin <peda@axentia.se> wrote: >> On 2018-03-24 15:03, Jonathan Cameron wrote: >>> On Mon, 19 Mar 2018 18:02:46 +0100 >>> Peter Rosin <peda@axentia.se> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/3] iio: wrapper: unit-converter: new driver 2018-03-27 13:32 ` Peter Rosin @ 2018-03-30 9:24 ` Jonathan Cameron 0 siblings, 0 replies; 22+ messages in thread From: Jonathan Cameron @ 2018-03-30 9:24 UTC (permalink / raw) To: Peter Rosin Cc: Jonathan Cameron, linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On Tue, 27 Mar 2018 15:32:13 +0200 Peter Rosin <peda@axentia.se> wrote: > On 2018-03-27 15:22, Jonathan Cameron wrote: > > On Tue, 27 Mar 2018 09:42:40 +0200 > > Peter Rosin <peda@axentia.se> wrote: > >> On 2018-03-24 15:03, Jonathan Cameron wrote: > >>> On Mon, 19 Mar 2018 18:02:46 +0100 > >>> Peter Rosin <peda@axentia.se> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] iio: add unit converter 2018-03-19 17:02 [PATCH 0/3] iio: add unit converter Peter Rosin ` (2 preceding siblings ...) 2018-03-19 17:02 ` [PATCH 3/3] iio: wrapper: unit-converter: new driver Peter Rosin @ 2018-03-23 13:14 ` Jonathan Cameron 2018-03-23 13:59 ` Peter Rosin 3 siblings, 1 reply; 22+ messages in thread From: Jonathan Cameron @ 2018-03-23 13:14 UTC (permalink / raw) To: Peter Rosin Cc: linux-kernel, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On Mon, 19 Mar 2018 18:02:43 +0100 Peter Rosin <peda@axentia.se> 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 > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] iio: add unit converter 2018-03-23 13:14 ` [PATCH 0/3] iio: add unit converter Jonathan Cameron @ 2018-03-23 13:59 ` Peter Rosin 2018-03-24 13:48 ` Jonathan Cameron 0 siblings, 1 reply; 22+ messages in thread From: Peter Rosin @ 2018-03-23 13:59 UTC (permalink / raw) To: Jonathan Cameron Cc: linux-kernel, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On 2018-03-23 14:14, Jonathan Cameron wrote: > On Mon, 19 Mar 2018 18:02:43 +0100 > Peter Rosin <peda@axentia.se> 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 >> > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] iio: add unit converter 2018-03-23 13:59 ` Peter Rosin @ 2018-03-24 13:48 ` Jonathan Cameron 2018-03-24 16:34 ` Linus Walleij 0 siblings, 1 reply; 22+ messages in thread From: Jonathan Cameron @ 2018-03-24 13:48 UTC (permalink / raw) To: Peter Rosin Cc: Jonathan Cameron, linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Randy Dunlap, linux-iio, devicetree On Fri, 23 Mar 2018 14:59:41 +0100 Peter Rosin <peda@axentia.se> wrote: > On 2018-03-23 14:14, Jonathan Cameron wrote: > > On Mon, 19 Mar 2018 18:02:43 +0100 > > Peter Rosin <peda@axentia.se> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] iio: add unit converter 2018-03-24 13:48 ` Jonathan Cameron @ 2018-03-24 16:34 ` Linus Walleij 2018-03-24 17:47 ` Jonathan Cameron 0 siblings, 1 reply; 22+ messages in thread From: Linus Walleij @ 2018-03-24 16:34 UTC (permalink / raw) To: Jonathan Cameron Cc: Peter Rosin, Jonathan Cameron, linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Randy Dunlap, linux-iio, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS On Sat, Mar 24, 2018 at 2:48 PM, Jonathan Cameron <jic23@kernel.org> wrote: > On Fri, 23 Mar 2018 14:59:41 +0100 > Peter Rosin <peda@axentia.se> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 0/3] iio: add unit converter 2018-03-24 16:34 ` Linus Walleij @ 2018-03-24 17:47 ` Jonathan Cameron 0 siblings, 0 replies; 22+ messages in thread From: Jonathan Cameron @ 2018-03-24 17:47 UTC (permalink / raw) To: Linus Walleij Cc: Peter Rosin, Jonathan Cameron, linux-kernel, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring, Mark Rutland, David S. Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman, Randy Dunlap, linux-iio, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Michael Hennerich On Sat, 24 Mar 2018 17:34:17 +0100 Linus Walleij <linus.walleij@linaro.org> wrote: > On Sat, Mar 24, 2018 at 2:48 PM, Jonathan Cameron <jic23@kernel.org> wrote: > > On Fri, 23 Mar 2018 14:59:41 +0100 > > Peter Rosin <peda@axentia.se> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-03-30 22:38 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-19 17:02 [PATCH 0/3] iio: add unit converter Peter Rosin 2018-03-19 17:02 ` [PATCH 1/3] iio: rename the multiplexer category to wrapper Peter Rosin 2018-03-19 18:36 ` Randy Dunlap 2018-03-19 17:02 ` [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter Peter Rosin 2018-03-24 13:53 ` Jonathan Cameron 2018-03-24 14:06 ` Jonathan Cameron 2018-03-26 22:23 ` Rob Herring 2018-03-27 8:01 ` Peter Rosin 2018-03-28 2:29 ` Phil Reid 2018-03-29 13:55 ` Rob Herring 2018-03-30 22:38 ` Peter Rosin 2018-03-19 17:02 ` [PATCH 3/3] iio: wrapper: unit-converter: new driver Peter Rosin 2018-03-24 14:03 ` Jonathan Cameron 2018-03-27 7:42 ` Peter Rosin 2018-03-27 13:22 ` Jonathan Cameron 2018-03-27 13:32 ` Peter Rosin 2018-03-30 9:24 ` Jonathan Cameron 2018-03-23 13:14 ` [PATCH 0/3] iio: add unit converter Jonathan Cameron 2018-03-23 13:59 ` Peter Rosin 2018-03-24 13:48 ` Jonathan Cameron 2018-03-24 16:34 ` Linus Walleij 2018-03-24 17:47 ` Jonathan Cameron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).