Re: [PATCH v2] iio: health: max30100: add config for LED current

[Jonathan Cameron]

On 31/12/15 22:17, Rob Herring wrote:
> On Tue, Dec 29, 2015 at 09:44:48PM -0800, Matt Ranostay wrote:
>> Allow the current for both RED and IR LEDs to be set via an device tree
>> property setting.
>>
>> This is an optional setting that is useful for applications that have a
>> known glass attenuation factor.
>>
>> Signed-off-by: Matt Ranostay 
>> ---
>> Changes from v2:
>> * change to use microamp property name from LED class
>> * updated documentation for new format
>> * added allowed current index map
>>
>> .../devicetree/bindings/iio/health/max30100.txt|  8 +++
>>  drivers/iio/health/max30100.c  | 81 
>> --
>>  2 files changed, 83 insertions(+), 6 deletions(-)
> 
> Acked-by: Rob Herring 
Looks good to me as well. Applied to the togreg branch of iio.git - initially
pushed out as testing for the autobuilders to play with it.

Thanks,

Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] iio:adc:at91_adc8xx: introduce new atmel adc driver

[Jonathan Cameron]

On 23/12/15 10:27, Ludovic Desroches wrote:
> On Tue, Dec 22, 2015 at 06:34:00PM +0000, Jonathan Cameron wrote:
>> On 21/12/15 09:24, Ludovic Desroches wrote:
>>> This driver supports the new version of the Atmel ADC device introduced
>>> with the SAMA5D2 SoC family.
>>>
>>> Signed-off-by: Ludovic Desroches 
>> A few more bits and bobs from me. Mostly looking good.
>>
>> Jonathan
>>> ---
>>>  .../devicetree/bindings/iio/adc/at91_adc8xx.txt|  27 ++
>>>  drivers/iio/adc/Kconfig|  11 +
>>>  drivers/iio/adc/Makefile   |   1 +
>>>  drivers/iio/adc/at91_adc8xx.c  | 417 
>>> +
>>>  4 files changed, 456 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt
>>>  create mode 100644 drivers/iio/adc/at91_adc8xx.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt 
>>> b/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt
>>> new file mode 100644
>>> index 000..64ad6a5
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt
>>> @@ -0,0 +1,27 @@
>>> +* AT91 SAMA5D2 Analog to Digital Converter (ADC)
>>> +
>>> +Required properties:
>>> +  - compatible: Should be "atmel,sama5d2-adc".
>>> +  - reg: Should contain ADC registers location and length.
>>> +  - interrupts: Should contain the IRQ line for the ADC.
>>> +  - clocks: phandles to clocks.
>>> +  - clock-names: tuple listing clock names.
>>> +  Required elements: "adc_clk", "adc_op_clk". "adc_clk" is the 
>>> peripheral
>>> +  clock, "adc_clk" is the sampling clock.
>>> +  - vref-supply: Supply used as reference for conversions.
>>> +
>>> +Optional properties:
>>> +  - vddana-supply: Supply for the adc device.
>>> +
>>> +
>>> +Example:
>>> +
>>> +adc: adc@fc03 {
>>> +   compatible = "atmel,sama5d2-adc";
>>> +   reg = <0xfc03 0x100>;
>>> +   interrupts = <40 IRQ_TYPE_LEVEL_HIGH 7>;
>>> +   clocks = <&adc_clk>, <&adc_op_clk>;
>>> +   clock-names = "adc_clk", "adc_op_clk";
>>> +   vddana-supply = <&vdd_3v3_lp_reg>;
>>> +   vref-supply = <&vdd_3v3_lp_reg>;
>>> +}
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 9162dfe..5819e41 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -131,6 +131,17 @@ config AT91_ADC
>>>   To compile this driver as a module, choose M here: the module will be
>>>   called at91_adc.
>>>  
>>> +config AT91_ADC8xx
>>> +   tristate "Atmel AT91 ADC 8xx"
>>> +   depends on ARCH_AT91
>>> +   depends on INPUT
>>> +   help
>>> + Say yes here to build support for Atmel ADC 8xx which is available
>>> + from SAMA5D2 SoC family.
>>> +
>>> + To compile this driver as a module, choose M here: the module will be
>>> + called at91_adc8xx.
>>> +
>>>  config AXP288_ADC
>>> tristate "X-Powers AXP288 ADC driver"
>>> depends on MFD_AXP20X
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 91a65bf..d684a52 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -14,6 +14,7 @@ obj-$(CONFIG_AD7793) += ad7793.o
>>>  obj-$(CONFIG_AD7887) += ad7887.o
>>>  obj-$(CONFIG_AD799X) += ad799x.o
>>>  obj-$(CONFIG_AT91_ADC) += at91_adc.o
>>> +obj-$(CONFIG_AT91_ADC8xx) += at91_adc8xx.o
>>>  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
>>>  obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
>>>  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>>> diff --git a/drivers/iio/adc/at91_adc8xx.c b/drivers/iio/adc/at91_adc8xx.c
>>> new file mode 100644
>>> index 000..8b4a6e7
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/at91_adc8xx.c
>>> @@ -0,0 +1,417 @@
>>> +/*
>>> + * Atmel ADC driver for SAMA5D2 devices and later.
>>> + *
>>> + * Copyright (C) 2015 Atmel,
>>> + *   2015 Ludovic Desroches 
>>> + *
>>> + * This software is licensed under the terms of the GNU General Public
>>> + * L

Re: [PATCH 1/5] iio:adc:at91_adc8xx: introduce new atmel adc driver

[Jonathan Cameron]

On 23 December 2015 10:48:33 GMT+00:00, Ludovic Desroches 
 wrote:
>On Wed, Dec 23, 2015 at 11:27:00AM +0100, Ludovic Desroches wrote:
>> On Tue, Dec 22, 2015 at 06:34:00PM +, Jonathan Cameron wrote:
>> > On 21/12/15 09:24, Ludovic Desroches wrote:
>> > > This driver supports the new version of the Atmel ADC device
>introduced
>> > > with the SAMA5D2 SoC family.
>> > > 
>
>[...]
>
>> > > +static irqreturn_t at91_adc_interrupt(int irq, void *private)
>> > > +{
>> > > +struct iio_dev *indio = private;
>> > > +struct at91_adc_state *st = iio_priv(indio);
>> > > +u32 status = at91_adc_readl(st, ADC_ISR);
>> > > +
>> > > +status &= at91_adc_readl(st, ADC_IMR);
>> > > +if (status & 0xFFF) {
>> > > +st->last_value = at91_adc_readl(st, st->chan->address);
>> > If this is a polled read - is there any reason to read this value
>here
>> > rather than outside the interrupt?
>> 
>> No it can be done outside the interrupt. I have taken some parts from
>the
>> previous driver but it was reading a register used by all the
>channels
>> when it has been designed. So yes there is probably no more reason to
>> read it into the interrupt.
>> 
>
>Thinking about it. Is it really useful to move reading outside the
>interrupt?
It avoids needing to know the channel in here, hence simplifying the code a bit.
>
>By the way this is not a polled read.
I meant that it is an individually requested conversion rather than a free 
running
 sampling system where the value read might change before it is read out.
>
>> > > +st->done = true;
>> > > +wake_up_interruptible(&st->wq_data_available);
>> > > +}
>> > > +
>> > > +return IRQ_HANDLED;
>> > > +}
>
>Ludovic
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] iio:adc:at91_adc8xx: introduce new atmel adc driver

[Jonathan Cameron]

On 21/12/15 09:24, Ludovic Desroches wrote:
> This driver supports the new version of the Atmel ADC device introduced
> with the SAMA5D2 SoC family.
> 
> Signed-off-by: Ludovic Desroches 
A few more bits and bobs from me. Mostly looking good.

Jonathan
> ---
>  .../devicetree/bindings/iio/adc/at91_adc8xx.txt|  27 ++
>  drivers/iio/adc/Kconfig|  11 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/at91_adc8xx.c  | 417 
> +
>  4 files changed, 456 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt
>  create mode 100644 drivers/iio/adc/at91_adc8xx.c
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt 
> b/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt
> new file mode 100644
> index 000..64ad6a5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt
> @@ -0,0 +1,27 @@
> +* AT91 SAMA5D2 Analog to Digital Converter (ADC)
> +
> +Required properties:
> +  - compatible: Should be "atmel,sama5d2-adc".
> +  - reg: Should contain ADC registers location and length.
> +  - interrupts: Should contain the IRQ line for the ADC.
> +  - clocks: phandles to clocks.
> +  - clock-names: tuple listing clock names.
> +  Required elements: "adc_clk", "adc_op_clk". "adc_clk" is the peripheral
> +  clock, "adc_clk" is the sampling clock.
> +  - vref-supply: Supply used as reference for conversions.
> +
> +Optional properties:
> +  - vddana-supply: Supply for the adc device.
> +
> +
> +Example:
> +
> +adc: adc@fc03 {
> + compatible = "atmel,sama5d2-adc";
> + reg = <0xfc03 0x100>;
> + interrupts = <40 IRQ_TYPE_LEVEL_HIGH 7>;
> + clocks = <&adc_clk>, <&adc_op_clk>;
> + clock-names = "adc_clk", "adc_op_clk";
> + vddana-supply = <&vdd_3v3_lp_reg>;
> + vref-supply = <&vdd_3v3_lp_reg>;
> +}
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 9162dfe..5819e41 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -131,6 +131,17 @@ config AT91_ADC
> To compile this driver as a module, choose M here: the module will be
> called at91_adc.
>  
> +config AT91_ADC8xx
> + tristate "Atmel AT91 ADC 8xx"
> + depends on ARCH_AT91
> + depends on INPUT
> + help
> +   Say yes here to build support for Atmel ADC 8xx which is available
> +   from SAMA5D2 SoC family.
> +
> +   To compile this driver as a module, choose M here: the module will be
> +   called at91_adc8xx.
> +
>  config AXP288_ADC
>   tristate "X-Powers AXP288 ADC driver"
>   depends on MFD_AXP20X
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 91a65bf..d684a52 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_AD7793) += ad7793.o
>  obj-$(CONFIG_AD7887) += ad7887.o
>  obj-$(CONFIG_AD799X) += ad799x.o
>  obj-$(CONFIG_AT91_ADC) += at91_adc.o
> +obj-$(CONFIG_AT91_ADC8xx) += at91_adc8xx.o
>  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
>  obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
>  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> diff --git a/drivers/iio/adc/at91_adc8xx.c b/drivers/iio/adc/at91_adc8xx.c
> new file mode 100644
> index 000..8b4a6e7
> --- /dev/null
> +++ b/drivers/iio/adc/at91_adc8xx.c
> @@ -0,0 +1,417 @@
> +/*
> + * Atmel ADC driver for SAMA5D2 devices and later.
> + *
> + * Copyright (C) 2015 Atmel,
> + *   2015 Ludovic Desroches 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADC_CR   0x00/* Control Register */
> +#define  ADC_CR_SWRSTBIT(0)  /* Software 
> Reset */
> +#define  ADC_CR_STARTBIT(1)  /* Start 
> Conversion */
> +#define  ADC_CR_TSCALIB  BIT(2)  /* Touchscreen 
> Calibration */
> +#define  ADC_CR_CMPRST   BIT(4)  /* Comparison 
> Restart */
> +#define ADC_MR   0x04/* Mode Register */
> +#define  ADC_MR_TRGSEL(v)(v << 1)/* Trigger 
> Selection */
> +#define  ADC_MR_TRGSEL_TRIG0 0   /* 
> ADTRG */
> +#define  ADC_MR_TRGSEL_TRIG1 1   /* 
> TIOA0 */
> +#defi

Re: [PATCH v3 5/5] iio: health: Add driver for the TI AFE4403 heart monitor

[Jonathan Cameron]

On 14/12/15 22:36, Andrew F. Davis wrote:
> Add driver for the TI AFE4403 heart rate monitor and pulse oximeter.
> This device detects reflected LED light fluctuations and presents an ADC
> value to the user space for further signal processing.
> 
> Data sheet located here:
> http://www.ti.com/product/AFE4403/datasheet
> 
> Signed-off-by: Andrew F. Davis 
I assume the plan is to break some of this out into a common shared
'helper' module for the two drivers?   You will probably want
to do that before we merge either of them.  Again, doesn't look like
it will be a big job as you just have cut and paste functions in
here (I think!)

I also picked up on a lack of locking around read update pairs
that I'd missed in reviewing the 4404 driver. Please fix it there
as well.

Otherwise a few spi specific bits inline and as you expect
the comments from one driver mostly apply to the other as well
(in both directions!)
> ---
>  .../ABI/testing/sysfs-bus-iio-health-afe4403   |  52 ++
>  drivers/iio/health/Kconfig |  12 +
>  drivers/iio/health/Makefile|   1 +
>  drivers/iio/health/afe4403.c   | 696 
> +
>  4 files changed, 761 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4403
>  create mode 100644 drivers/iio/health/afe4403.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe4403 
> b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4403
> new file mode 100644
> index 000..325efcb
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4403
> @@ -0,0 +1,52 @@
> +What:/sys/bus/iio/devices/iio:deviceX/tia_resistanceY
> + /sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get and set the resistance and the capacitance settings for the
> + Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
> + Rf2 and Cf2 values.
> + Valid Resistance settings are 50, 25, 10, 5,
> + 25000, 1, 100, and 0 Ohms.
> + Valid capacitance settings are 5, 10, 20, 25, 30, 35, 45, 50, 
> 55,
> + 60, 70, 75, 80, 85, 95, 100, 155, 160, 170, 175, 180, 185, 195,
> + 200, 205, 210, 220, 225, 230, 235, 245, and 250 picoFarads.
Given we have two devices with very similar ABI up to the values, I'd
suggest providing *_available attributes so these can be queried from
userspace and you can create a single ABI document covering the two drivers.
> +
> +What:/sys/bus/iio/devices/iio:deviceX/tia_separate_en
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Enable or disable separate settings for the TransImpedance
> + Amplifier above, when disabled both values are set by the
> + first channel.
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_raw
> + /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_ambient_raw
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get measured values from the ADC for these stages. Y is the
> + specific LED number. The values are expressed in 24-bit twos
> + complement.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY-ledY_ambient_raw
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get differential values from the ADC for these stages. Y is the
> + specific LED number. The values are expressed in 24-bit twos
> + complement for the specified LEDs.
> +
> +What:/sys/bus/iio/devices/iio:deviceX/out_current_ledY_raw
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get and set the LED current for the specified LED. Y is the
> + specific LED number.
> + Values range from 0 -> 255. Current is calculated by
> + current = (value / 256) * 50mA
This level of detail is exposed anyway in the userspace interface, so I
would not expect it to be explicitly mentioned here.  Without this I 'think'
we can combine this with the docs for the afe4404.

> diff --git a/drivers/iio/health/Kconfig b/drivers/iio/health/Kconfig
> index 526e7af..e338df4 100644
> --- a/drivers/iio/health/Kconfig
> +++ b/drivers/iio/health/Kconfig
> @@ -7,6 +7,18 @@ menu "Health"
>  
>  menu "Heart Rate Monitors"
>  
> +config AFE4403
> + tristate "TI AFE4403 Heart Rate Monitor"
> + depends on SPI_MASTER
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   Say yes to choose the Texas Instruments AFE4403
> +   heart ra

Re: [PATCH v3 4/5] Documentation: afe4403: Add DT bindings for the AFE4403 heart monitor

[Jonathan Cameron]

On 14/12/15 22:36, Andrew F. Davis wrote:
> Add the TI AFE4403 heart monitor DT bindings documentation.
> 
> Signed-off-by: Andrew F. Davis 
Nothing terribly controversial in here that I can spot
so looks good to me.

Jonathan
> ---
>  .../devicetree/bindings/iio/health/afe4403.txt | 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/health/afe4403.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/health/afe4403.txt 
> b/Documentation/devicetree/bindings/iio/health/afe4403.txt
> new file mode 100644
> index 000..2fffd70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/health/afe4403.txt
> @@ -0,0 +1,34 @@
> +Texas Instruments AFE4403 Heart rate and Pulse Oximeter
> +
> +Required properties:
> + - compatible: Should be "ti,afe4403".
> + - reg   : SPI chip select address of device.
> + - tx-supply : Regulator supply to transmitting LEDs.
> + - interrupt-parent  : Phandle to he parent interrupt controller.
> + - interrupts: The interrupt line the device ADC_RDY pin is
> +   connected to. For details refer to,
> +   ../../interrupt-controller/interrupts.txt.
> +
> +Optional properties:
> + - reset-gpios   : GPIO used to reset the device.
> +   For details refer to, ../../gpio/gpio.txt.
> +
> +For other required and optional properties of SPI slave nodes
> +please refer to ../../spi/spi-bus.txt.
> +
> +Example:
> +
> +&spi0 {
> + heart_mon@0 {
> + compatible = "ti,afe4403";
> + reg = <0>;
> + spi-max-frequency = <1000>;
> +
> + tx-supply = <&vbat>;
> +
> + interrupt-parent = <&gpio1>;
> + interrupts = <28 IRQ_TYPE_EDGE_RISING>;
> +
> + reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
> + };
> +};
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] iio: health: Add driver for the TI AFE4404 heart monitor

[Jonathan Cameron]

On 14/12/15 22:35, Andrew F. Davis wrote:
> Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
> This device detects reflected LED light fluctuations and presents an ADC
> value to the user space for further signal processing.
> 
> Datasheet: http://www.ti.com/product/AFE4404/datasheet
> 
> Signed-off-by: Andrew F. Davis 
Hi Andrew,

Sorry I didn't get to this a the weekend. We are now likely to just
miss the merge window so lets get this cleaned up and ready to go
for the start of the next cycle (probably 3rd week of January)

Looking good mostly.  A few minor bits and bobs I either missed before
or that got introduced as side effects of your changes.
I thought about fixing them up and applying, but I think it's just
a shade to many changes and I need your feedback on a couple of them
anyway.

Jonathan

> ---
>  .../ABI/testing/sysfs-bus-iio-health-afe4404   |  60 ++
>  drivers/iio/Kconfig|   1 +
>  drivers/iio/Makefile   |   1 +
>  drivers/iio/health/Kconfig |  25 +
>  drivers/iio/health/Makefile|   6 +
>  drivers/iio/health/afe4404.c   | 700 
> +
>  drivers/iio/health/afe440x.h   | 202 ++
>  7 files changed, 995 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
>  create mode 100644 drivers/iio/health/Kconfig
>  create mode 100644 drivers/iio/health/Makefile
>  create mode 100644 drivers/iio/health/afe4404.c
>  create mode 100644 drivers/iio/health/afe440x.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404 
> b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
> new file mode 100644
> index 000..b01ca47
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
> @@ -0,0 +1,60 @@
> +What:/sys/bus/iio/devices/iio:deviceX/tia_resistanceY
> + /sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get and set the resistance and the capacitance settings for the
> + Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
> + Rf2 and Cf2 values.
> + Valid Resistance settings are 50, 25, 10, 5,
> + 25000, 1, 100, and 200 Ohms.
> + Valid capacitance settings are 5, 2.5, 10, 7.5, 20, 17.5, 25,
> + and 22.5 picoFarads.
Defined units for IIO are nanofarads - see sysfs-bus-iio.
Would really like to keep this consistent and doesn't look like that should
be terribly hard to do here.

> +
> +What:/sys/bus/iio/devices/iio:deviceX/tia_separate_en
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Enable or disable separate settings for the TransImpedance
> + Amplifier above, when disabled both values are set by the
> + first channel.
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_raw
> + /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_ambient_raw
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get measured values from the ADC for these stages. Y is the
> + specific LED number. The values are expressed in 24-bit twos
> + complement.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY-ledY_ambient_raw
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get differential values from the ADC for these stages. Y is the
> + specific LED number. The values are expressed in 24-bit twos
> + complement for the specified LEDs.
> +
> +What:/sys/bus/iio/devices/iio:deviceX/out_current_ledY_offset
> + /sys/bus/iio/devices/iio:deviceX/out_current_ledY_ambient_offset
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get and set the offset cancellation DAC setting for these
> + stages. The values are expressed in 5-bit sign–magnitude.
> +
> +What:/sys/bus/iio/devices/iio:deviceX/out_current_ledY_raw
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get and set the LED current for the specified LED. Y is the
> + specific LED number.
> + Values range from 0 -> 63. Current is calculated by
> + current = value * 0.8mA
Otherwise, we both know that the ABI is less than ideal, but it's probably
the best solution we can easily manage so lets go with this.
While it's not easy to revise this in future it can be done should

Re: [PATCH v3 1/5] iio: Make IIO value formating function globally available.

[Jonathan Cameron]

On 14/12/15 22:35, Andrew F. Davis wrote:
> Make IIO value formating function globally available to allow IIO drivers
> to output values as the core does.
> 
> Signed-off-by: Andrew F. Davis 
Applied to the togreg branch of iio.git - initially pushed out as testing for 
the
autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/iio/industrialio-core.c | 1 +
>  include/linux/iio/iio.h | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 208358f..eb5909d 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -470,6 +470,7 @@ ssize_t iio_format_value(char *buf, unsigned int type, 
> int size, int *vals)
>   return 0;
>   }
>  }
> +EXPORT_SYMBOL_GPL(iio_format_value);
>  
>  static ssize_t iio_read_channel_info(struct device *dev,
>struct device_attribute *attr,
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index 19c94c9..b589411 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -636,6 +636,8 @@ static inline struct dentry 
> *iio_get_debugfs_dentry(struct iio_dev *indio_dev)
>  }
>  #endif
>  
> +ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals);
> +
>  int iio_str_to_fixpoint(const char *str, int fract_mult, int *integer,
>   int *fract);
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 5/8] iio: adc: fsl,imx25-gcq driver

[Jonathan Cameron]

On 06/12/15 19:52, Markus Pargmann wrote:
> This is a conversion queue driver for the mx25 SoC. It uses the central
> ADC which is used by two seperate independent queues. This driver
> prepares different conversion configurations for each possible input.
> For a conversion it creates a conversionqueue of one item with the
conversion queue
> correct configuration for the chosen channel. It then executes the queue
> once and disables the conversion queue afterwards.
> 
> The reference voltages are configurable through devicetree subnodes,
> depending on the connections of the ADC inputs.
> 
> Signed-off-by: Markus Pargmann 
> Signed-off-by: Denis Carikli 
A couple of little bits inline.  Fix the return of 0 on fail in probe
and you can add

Acked-by: Jonathan Cameron 
> ---
> 
> Notes:
> Changes in v7:
>  - Remove separate functions mx25_gcq_disable/enable_eoq() as they were 
> used at
>only one position
>  - Enforce an external reference regulator if one of the conversions uses 
> it as
>reference. The devm_regulator_get() call was moved into
>mx25_gcq_setup_cfgs() to be able to acquire the reference regulator 
> when
>necessary.
>  - Store indio_dev as platform driver data instead of the private data. 
> This
>was changed in probe() and remove().
> 
> Changes in v6:
>  - Added defines for a complete list of references in the dt binding 
> macros
> 
>  drivers/iio/adc/Kconfig |   7 +
>  drivers/iio/adc/Makefile|   1 +
>  drivers/iio/adc/fsl-imx25-gcq.c | 415 
> 
>  3 files changed, 423 insertions(+)
>  create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7868c744fd4b..73145c53ec2c 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -183,6 +183,13 @@ config EXYNOS_ADC
> To compile this driver as a module, choose M here: the module will be
> called exynos_adc.
>  
> +config FSL_MX25_ADC
> + tristate "Freescale MX25 ADC driver"
> + depends on MFD_MX25_TSADC
> + help
> +   Generic Conversion Queue driver used for general purpose ADC in the
> +   MX25. This driver supports single measurements using the MX25 ADC.
> +
>  config HI8435
>   tristate "Holt Integrated Circuits HI-8435 threshold detector"
>   select IIO_TRIGGERED_EVENT
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 99b37a963a1e..2fe9b78e4b02 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
>  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> +obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
>  obj-$(CONFIG_HI8435) += hi8435.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1027) += max1027.o
> diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
> new file mode 100644
> index ..eb9570876291
> --- /dev/null
> +++ b/drivers/iio/adc/fsl-imx25-gcq.c
> @@ -0,0 +1,415 @@
> +/*
> + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann 
> + *
> + * This program is free software; you can redistribute it and/or modify it 
> under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + *
> + * This is the driver for the imx25 GCQ (Generic Conversion Queue)
> + * connected to the imx25 ADC.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MX25_GCQ_TIMEOUT (msecs_to_jiffies(2000))
> +
> +static const char * const driver_name = "mx25-gcq";
> +
> +enum mx25_gcq_cfgs {
> + MX25_CFG_XP = 0,
> + MX25_CFG_YP,
> + MX25_CFG_XN,
> + MX25_CFG_YN,
> + MX25_CFG_WIPER,
> + MX25_CFG_INAUX0,
> + MX25_CFG_INAUX1,
> + MX25_CFG_INAUX2,
> + MX25_NUM_CFGS,
> +};
> +
> +struct mx25_gcq_priv {
> + struct regmap *regs;
> + struct completion completed;
> + struct clk *clk;
> + int irq;
> + struct regulator *vref[4];
> + u32 channel_vref_mv[MX25_NUM_CFGS];
> +};
> +
> +#define MX25_CQG_CHAN(chan, id) {\
> + .type = IIO_VOLTAGE,\
> + .indexed = 1,\
> + .channel = chan,\
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> +   BIT(IIO_CHAN_INFO_SCALE),\
> + .datasheet_name = id,\
> +}
> 

Re: [PATCH v5 1/4] iio: adc: add IMX7D ADC driver support

[Jonathan Cameron]

On 08/12/15 10:26, Haibo Chen wrote:
> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
> driver support, and the driver only support ADC software trigger.
> 
> Signed-off-by: Haibo Chen 
One significant issue, but as the fix is simple I've made it.
A few formatting bits and bobs that I've also cleaned up (overly long lines).
If I don't clean them up on merge I have to deal with the little 'fix'
patches in the coming weeks :) Easier to do it now.
I left one case where I felt it would hurt readability alone, but fixed the
others.

Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/Kconfig |   9 +
>  drivers/iio/adc/Makefile|   1 +
>  drivers/iio/adc/imx7d_adc.c | 589 
> 
>  3 files changed, 599 insertions(+)
>  create mode 100644 drivers/iio/adc/imx7d_adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7868c74..3493a46 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -194,6 +194,15 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>  
> +config IMX7D_ADC
> + tristate "IMX7D ADC driver"
> + depends on ARCH_MXC || COMPILE_TEST
> + help
> +   Say yes here to build support for IMX7D ADC.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called imx7d_adc.
> +
>  config LP8788_ADC
>   tristate "LP8788 ADC driver"
>   depends on MFD_LP8788
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 99b37a9..282ffc01 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1027) += max1027.o
>  obj-$(CONFIG_MAX1363) += max1363.o
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> new file mode 100644
> index 000..d3511b9
> --- /dev/null
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -0,0 +1,589 @@
> +/*
> + * Freescale i.MX7D ADC driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/* ADC register */
> +#define IMX7D_REG_ADC_CH_A_CFG1  0x00
> +#define IMX7D_REG_ADC_CH_A_CFG2  0x10
> +#define IMX7D_REG_ADC_CH_B_CFG1  0x20
> +#define IMX7D_REG_ADC_CH_B_CFG2  0x30
> +#define IMX7D_REG_ADC_CH_C_CFG1  0x40
> +#define IMX7D_REG_ADC_CH_C_CFG2  0x50
> +#define IMX7D_REG_ADC_CH_D_CFG1  0x60
> +#define IMX7D_REG_ADC_CH_D_CFG2  0x70
> +#define IMX7D_REG_ADC_CH_SW_CFG  0x80
> +#define IMX7D_REG_ADC_TIMER_UNIT 0x90
> +#define IMX7D_REG_ADC_DMA_FIFO   0xa0
> +#define IMX7D_REG_ADC_FIFO_STATUS0xb0
> +#define IMX7D_REG_ADC_INT_SIG_EN 0xc0
> +#define IMX7D_REG_ADC_INT_EN 0xd0
> +#define IMX7D_REG_ADC_INT_STATUS 0xe0
> +#define IMX7D_REG_ADC_CHA_B_CNV_RSLT 0xf0
> +#define IMX7D_REG_ADC_CHC_D_CNV_RSLT 0x100
> +#define IMX7D_REG_ADC_CH_SW_CNV_RSLT 0x110
> +#define IMX7D_REG_ADC_DMA_FIFO_DAT   0x120
> +#define IMX7D_REG_ADC_ADC_CFG0x130
> +
> +#define IMX7D_REG_ADC_CHANNEL_CFG2_BASE  0x10
> +#define IMX7D_EACH_CHANNEL_REG_OFFSET0x20
> +
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_EN (0x1 << 31)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SINGLE BIT(30)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_AVG_EN BIT(29)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SEL(x) ((x) << 24)
> +
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_4  (0x0 << 
> 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_8  (0x1 << 
> 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_16 (0x2 << 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_32 (0x3 << 12)
> +
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_4   (0x0 << 29)
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_8   (0x1 << 29)
> +#define IMX7D_REG_ADC_TIMER_U

Re: [PATCH v9 2/8] ARM: dt: Binding documentation for imx25 GCQ

[Jonathan Cameron]

On 07/12/15 17:39, Rob Herring wrote:
> On Sun, Dec 06, 2015 at 08:52:15PM +0100, Markus Pargmann wrote:
>> The documentation describes the bindings for the imx25 GCQ unit which is
>> essentially a generic conversion queue using the imx25 ADC.
>>
>> Signed-off-by: Markus Pargmann 
> 
> Acked-by: Rob Herring 
Acked-by: Jonathan Cameron 
> 
>> ---
>>
>> Notes:
>> Changes in v9:
>>  - Added the dt-bindings header to this patch instead of the driver
>> 
>> Changes in v6:
>>  - Changed bindings to use adc-refp and adc-refn. Also a bit of cleanup 
>> in the
>>setup routine.
>> 
>> Changes in v5:
>>  - Fixed locking
>>  - Removed module owner
>>
>>  .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt  | 58 
>> ++
>>  include/dt-bindings/iio/adc/fsl-imx25-gcq.h| 18 +++
>>  2 files changed, 76 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
>>  create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt 
>> b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
>> new file mode 100644
>> index ..b0866d36a307
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
>> @@ -0,0 +1,58 @@
>> +Freescale i.MX25 ADC GCQ device
>> +
>> +This is a generic conversion queue device that can convert any of the
>> +analog inputs using the ADC unit of the i.MX25.
>> +
>> +Required properties:
>> + - compatible: Should be "fsl,imx25-gcq".
>> + - reg: Should be the register range of the module.
>> + - interrupts: Should be the interrupt number of the module.
>> +   Typically this is <1>.
>> + - interrupt-parent: phandle to the tsadc module of the i.MX25.
>> + - #address-cells: Should be <1> (setting for the subnodes)
>> + - #size-cells: Should be <0> (setting for the subnodes)
>> +
>> +Optional properties:
>> + - vref-ext-supply: The regulator supplying the ADC reference voltage.
>> +   Required when at least one subnode uses the this reference.
>> + - vref-xp-supply: The regulator supplying the ADC reference voltage on pin 
>> XP.
>> +   Required when at least one subnode uses this reference.
>> + - vref-yp-supply: The regulator supplying the ADC reference voltage on pin 
>> YP.
>> +   Required when at least one subnode uses this reference.
>> +
>> +Sub-nodes:
>> +Optionally you can define subnodes which define the reference voltage
>> +for the analog inputs.
>> +
>> +Required properties for subnodes:
>> + - reg: Should be the number of the analog input.
>> + 0: xp
>> + 1: yp
>> + 2: xn
>> + 3: yn
>> + 4: wiper
>> + 5: inaux0
>> + 6: inaux1
>> + 7: inaux2
>> +Optional properties for subnodes:
>> + - fsl,adc-refp: specifies the positive reference input as defined in
>> + 
>> + - fsl,adc-refn: specifies the negative reference input as defined in
>> + 
>> +
>> +Example:
>> +
>> +adc: adc@50030800 {
>> +compatible = "fsl,imx25-gcq";
>> +reg = <0x50030800 0x60>;
>> +interrupt-parent = <&tscadc>;
>> +interrupts = <1>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +inaux@5 {
>> +reg = <5>;
>> +fsl,adc-refp = ;
>> +fsl,adc-refn = ;
>> +};
>> +};
>> diff --git a/include/dt-bindings/iio/adc/fsl-imx25-gcq.h 
>> b/include/dt-bindings/iio/adc/fsl-imx25-gcq.h
>> new file mode 100644
>> index ..87abdd4a7674
>> --- /dev/null
>> +++ b/include/dt-bindings/iio/adc/fsl-imx25-gcq.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * This header provides constants for configuring the I.MX25 ADC
>> + */
>> +
>> +#ifndef _DT_BINDINGS_IIO_ADC_FS_IMX25_GCQ_H
>> +#define _DT_BINDINGS_IIO_ADC_FS_IMX25_GCQ_H
>> +
>> +#define MX25_ADC_REFP_YP0 /* YP voltage reference */
>> +#define MX25_ADC_REFP_XP1 /* XP voltage reference */
>> +#define MX25_ADC_REFP_EXT   2 /* External voltage reference */
>> +#define MX25_ADC_REFP_INT   3 /* Internal voltage reference */
>> +
>> +#define MX25_ADC_REFN_XN0 /* XN ground reference */
>> +#de

Re: [PATCH v5 3/4] ARM: dts: imx7d.dtsi: add ADC support

[Jonathan Cameron]

On 08/12/15 10:26, Haibo Chen wrote:
> Add imx7d ADC support.
> 
> Signed-off-by: Haibo Chen 
The driver is now working its way in the direction of linux-next via
Greg KHs tree. I'm happy to take these changes as well, but would imagine
they are better routed through the relevant imx trees.

Jonathan
> ---
>  arch/arm/boot/dts/imx7d.dtsi | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index ebc053a..aa0624d 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -583,6 +583,24 @@
>   reg = <0x3040 0x40>;
>   ranges;
>  
> + adc1: adc@3061 {
> + compatible = "fsl,imx7d-adc";
> + reg = <0x3061 0x1>;
> + interrupts = ;
> + clocks = <&clks IMX7D_ADC_ROOT_CLK>;
> + clock-names = "adc";
> + status = "disabled";
> + };
> +
> + adc2: adc@3062 {
> + compatible = "fsl,imx7d-adc";
> + reg = <0x3062 0x1>;
> + interrupts = ;
> + clocks = <&clks IMX7D_ADC_ROOT_CLK>;
> + clock-names = "adc";
> + status = "disabled";
> + };
> +
>   pwm1: pwm@3066 {
>   compatible = "fsl,imx7d-pwm", "fsl,imx27-pwm";
>   reg = <0x3066 0x1>;
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/4] Documentation: add the binding file for Freescale imx7d ADC driver

[Jonathan Cameron]

On 08/12/15 10:26, Haibo Chen wrote:
> The patch adds the binding file for Freescale imx7d ADC driver.
> 
> Signed-off-by: Haibo Chen 
> Acked-by: Rob Herring 
Applied 
> ---
>  .../devicetree/bindings/iio/adc/imx7d-adc.txt  | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt 
> b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
> new file mode 100644
> index 000..5c184b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
> @@ -0,0 +1,22 @@
> +Freescale imx7d ADC bindings
> +
> +The devicetree bindings are for the ADC driver written for
> +imx7d SoC.
> +
> +Required properties:
> +- compatible: Should be "fsl,imx7d-adc"
> +- reg: Offset and length of the register set for the ADC device
> +- interrupts: The interrupt number for the ADC device
> +- clocks: The root clock of the ADC controller
> +- clock-names: Must contain "adc", matching entry in the clocks property
> +- vref-supply: The regulator supply ADC reference voltage
> +
> +Example:
> +adc1: adc@3061 {
> + compatible = "fsl,imx7d-adc";
> + reg = <0x3061 0x1>;
> + interrupts = ;
> + clocks = <&clks IMX7D_ADC_ROOT_CLK>;
> + clock-names = "adc";
> + vref-supply = <®_vcc_3v3_mcu>;
> +};
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] iio: health: Add driver for the TI AFE4404 heart monitor

[Jonathan Cameron]

On 07/12/15 17:26, Andrew F. Davis wrote:
> On 12/05/2015 12:21 PM, Jonathan Cameron wrote:
>> On 02/12/15 19:57, Andrew F. Davis wrote:
>>> Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
>>> This device detects reflected LED light fluctuations and presents an ADC
>>> value to the user space for further signal processing.
>>>
>>> Datasheet: http://www.ti.com/product/AFE4404/datasheet
>>>
>>> Signed-off-by: Andrew F. Davis 
>> I like this a lot.  Seems much simpler to me.
>>
>> Various bits and bobs inline though.  You quite rightly stated there
>> was too much to describe in the change log so I've kind of started
>> from scratch on the review as well.
>>
>> Thanks for your hard work on this.
>>
>> Jonathan
Reponses inline.
>>> ---
>>>   .../ABI/testing/sysfs-bus-iio-health-afe4404   |  20 +
>>>   drivers/iio/Kconfig|   1 +
>>>   drivers/iio/Makefile   |   1 +
>>>   drivers/iio/health/Kconfig |  25 +
>>>   drivers/iio/health/Makefile|   6 +
>>>   drivers/iio/health/afe4404.c   | 619 
>>> +
>>>   drivers/iio/health/afe440x.h   | 168 ++
>>>   7 files changed, 840 insertions(+)
>>>   create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
>>>   create mode 100644 drivers/iio/health/Kconfig
>>>   create mode 100644 drivers/iio/health/Makefile
>>>   create mode 100644 drivers/iio/health/afe4404.c
>>>   create mode 100644 drivers/iio/health/afe440x.h
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404 
>>> b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
>>> new file mode 100644
>>> index 000..c104d66
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
>>> @@ -0,0 +1,20 @@
>>> +What:/sys/bus/iio/devices/iio:deviceX/tia_resistanceY
>>> +/sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
>>> +Date:December 2015
>>> +KernelVersion:
>>> +Contact:Andrew F. Davis 
>>> +Description:
>>> +Get and set the resistance and the capacitance settings for the
>>> +Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
>>> +Rf2 and Cf2 values.
>>> +Resistance setting is from 0 -> 7
>>> +Capcitance setting is from 0 -> 15
>> No magic numbers if at all possible.  These correspond to real resistances
>> and capacitances.
>>
>> You also want an _available attribute for each of them for the different
>> possible values.
>>
>> I'm not overly keep on the naming still but it's part specific enough that
>> if you fix the units I'll let it go ;)
> 
> I'm not sure if there is a clean way to do this, these are not channels
> so parsing input will need checks based on what kind of register and value
> we send in, these are raw input to the registers for other registers, I
> changed the name to attempt to make it clear to users these are not
> channels but raw registers (out_resistance1_raw -> tia_resistance1).
> 
> I could still make this more clear in the ABI doc:
> 
> Valid capacitance settings are 0 -> 7 which correspond to
> 5pF, 2.5pF, 10pF, 7.5pF, 20pF, 17.5pF, 25pF, and 22.5pF
> respectively.
Just do a simple mapping in the driver from magic number to real value
and the other way around + provide the available attribute.  Rule 2 of sysfs
interfaces: no magic values where a real meaningful one can be provided for
the cost of a few more lines of code.

You can use the existing floating point to value pair functions from IIO
to get you to a couple of values that can be trivially matched against
a const table.

It's not free, but probably only 20 lines including the static const table
of values.
> 
> or something similar.
> 
>>> +
>>> +What:/sys/bus/iio/devices/iio:deviceX/tia_separate_en
>>> +Date:December 2015
>>> +KernelVersion:
>>> +Contact:Andrew F. Davis 
>>> +Description:
>>> +Enable or disable separate settings for the TransImpedance
>>> +Amplifier above, when disabled both values are set by the
>>> +first channel.
>> Weird and wonderful but fine for a part specific attibute!
>>
>> As noted below, I think we need to document all the new ABI even though
>> much of

Re: [PATCH v4 1/4] iio: adc: add IMX7D ADC driver support

[Jonathan Cameron]

On 01/12/15 08:22, Haibo Chen wrote:
> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
> driver support, and the driver only support ADC software trigger.
> 
> Signed-off-by: Haibo Chen 
Looks good to me.

Only bit I don't like is the papering over an interrupt occuring that
should not.  If that happens we want to rely on the core support shutting
down the interrupt and providing the correct report on what happened rather
than hiding it in the driver.

Jonathan
> ---
>  drivers/iio/adc/Kconfig |   9 +
>  drivers/iio/adc/Makefile|   1 +
>  drivers/iio/adc/imx7d_adc.c | 588 
> 
>  3 files changed, 598 insertions(+)
>  create mode 100644 drivers/iio/adc/imx7d_adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7868c74..3493a46 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -194,6 +194,15 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>  
> +config IMX7D_ADC
> + tristate "IMX7D ADC driver"
> + depends on ARCH_MXC || COMPILE_TEST
> + help
> +   Say yes here to build support for IMX7D ADC.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called imx7d_adc.
> +
>  config LP8788_ADC
>   tristate "LP8788 ADC driver"
>   depends on MFD_LP8788
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 99b37a9..282ffc01 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1027) += max1027.o
>  obj-$(CONFIG_MAX1363) += max1363.o
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> new file mode 100644
> index 000..4780595
> --- /dev/null
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -0,0 +1,588 @@
> +/*
> + * Freescale i.MX7D ADC driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/* ADC register */
> +#define IMX7D_REG_ADC_CH_A_CFG1  0x00
> +#define IMX7D_REG_ADC_CH_A_CFG2  0x10
> +#define IMX7D_REG_ADC_CH_B_CFG1  0x20
> +#define IMX7D_REG_ADC_CH_B_CFG2  0x30
> +#define IMX7D_REG_ADC_CH_C_CFG1  0x40
> +#define IMX7D_REG_ADC_CH_C_CFG2  0x50
> +#define IMX7D_REG_ADC_CH_D_CFG1  0x60
> +#define IMX7D_REG_ADC_CH_D_CFG2  0x70
> +#define IMX7D_REG_ADC_CH_SW_CFG  0x80
> +#define IMX7D_REG_ADC_TIMER_UNIT 0x90
> +#define IMX7D_REG_ADC_DMA_FIFO   0xa0
> +#define IMX7D_REG_ADC_FIFO_STATUS0xb0
> +#define IMX7D_REG_ADC_INT_SIG_EN 0xc0
> +#define IMX7D_REG_ADC_INT_EN 0xd0
> +#define IMX7D_REG_ADC_INT_STATUS 0xe0
> +#define IMX7D_REG_ADC_CHA_B_CNV_RSLT 0xf0
> +#define IMX7D_REG_ADC_CHC_D_CNV_RSLT 0x100
> +#define IMX7D_REG_ADC_CH_SW_CNV_RSLT 0x110
> +#define IMX7D_REG_ADC_DMA_FIFO_DAT   0x120
> +#define IMX7D_REG_ADC_ADC_CFG0x130
> +
> +#define IMX7D_REG_ADC_CHANNEL_CFG2_BASE  0x10
> +#define IMX7D_EACH_CHANNEL_REG_OFFSET0x20
> +
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_EN (0x1 << 31)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SINGLE BIT(30)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_AVG_EN BIT(29)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SEL(x) ((x) << 24)
> +
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_4  (0x0 << 
> 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_8  (0x1 << 
> 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_16 (0x2 << 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_32 (0x3 << 12)
> +
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_4   (0x0 << 29)
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_8   (0x1 << 29)
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_16  (0x2 << 29)
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_32  (0x3 << 29)
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_64  (0x4 << 29)
> +#

Re: [PATCH v2 2/2] iio: health: Add driver for the TI AFE4404 heart monitor

[Jonathan Cameron]

On 02/12/15 19:57, Andrew F. Davis wrote:
> Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
> This device detects reflected LED light fluctuations and presents an ADC
> value to the user space for further signal processing.
> 
> Datasheet: http://www.ti.com/product/AFE4404/datasheet
> 
> Signed-off-by: Andrew F. Davis 
I like this a lot.  Seems much simpler to me.

Various bits and bobs inline though.  You quite rightly stated there
was too much to describe in the change log so I've kind of started
from scratch on the review as well.

Thanks for your hard work on this.

Jonathan
> ---
>  .../ABI/testing/sysfs-bus-iio-health-afe4404   |  20 +
>  drivers/iio/Kconfig|   1 +
>  drivers/iio/Makefile   |   1 +
>  drivers/iio/health/Kconfig |  25 +
>  drivers/iio/health/Makefile|   6 +
>  drivers/iio/health/afe4404.c   | 619 
> +
>  drivers/iio/health/afe440x.h   | 168 ++
>  7 files changed, 840 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
>  create mode 100644 drivers/iio/health/Kconfig
>  create mode 100644 drivers/iio/health/Makefile
>  create mode 100644 drivers/iio/health/afe4404.c
>  create mode 100644 drivers/iio/health/afe440x.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404 
> b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
> new file mode 100644
> index 000..c104d66
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
> @@ -0,0 +1,20 @@
> +What:/sys/bus/iio/devices/iio:deviceX/tia_resistanceY
> + /sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get and set the resistance and the capacitance settings for the
> + Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
> + Rf2 and Cf2 values.
> + Resistance setting is from 0 -> 7
> + Capcitance setting is from 0 -> 15
No magic numbers if at all possible.  These correspond to real resistances
and capacitances.

You also want an _available attribute for each of them for the different
possible values.

I'm not overly keep on the naming still but it's part specific enough that
if you fix the units I'll let it go ;)
> +
> +What:/sys/bus/iio/devices/iio:deviceX/tia_separate_en
> +Date:December 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Enable or disable separate settings for the TransImpedance
> + Amplifier above, when disabled both values are set by the
> + first channel.
Weird and wonderful but fine for a part specific attibute!

As noted below, I think we need to document all the new ABI even though
much of it is just extended names on standard channels.

> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 66792e7..ac085ab 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -52,6 +52,7 @@ source "drivers/iio/common/Kconfig"
>  source "drivers/iio/dac/Kconfig"
>  source "drivers/iio/frequency/Kconfig"
>  source "drivers/iio/gyro/Kconfig"
> +source "drivers/iio/health/Kconfig"
>  source "drivers/iio/humidity/Kconfig"
>  source "drivers/iio/imu/Kconfig"
>  source "drivers/iio/light/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index aeca726..6c5eb2a 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -18,6 +18,7 @@ obj-y += common/
>  obj-y += dac/
>  obj-y += gyro/
>  obj-y += frequency/
> +obj-y += health/
>  obj-y += humidity/
>  obj-y += imu/
>  obj-y += light/
> diff --git a/drivers/iio/health/Kconfig b/drivers/iio/health/Kconfig
> new file mode 100644
> index 000..526e7af
> --- /dev/null
> +++ b/drivers/iio/health/Kconfig
> @@ -0,0 +1,25 @@
> +#
> +# Health drivers
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Health"
> +
> +menu "Heart Rate Monitors"
> +
> +config AFE4404
> + tristate "TI AFE4404 Heart Rate Monitor"
> + depends on I2C
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   Say yes to choose the Texas Instruments AFE4404
> +   heart rate monitor and low-cost pulse oximeter.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called afe4404.
> +
> +endmenu
> +
> +endmenu
> diff --git a/drivers/iio/health/Makefile b/drivers/iio/health/Makefile
> new file mode 100644
> index 000..c108c8d
> --- /dev/null
> +++ b/drivers/iio/health/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for IIO Health drivers
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +obj-$(CONFIG_AFE4404) += afe4404.o
> diff --git a

Re: [PATCH v2 1/2] Documentation: afe4404: Add DT bindings for the AFE4404 heart monitor

[Jonathan Cameron]

On 05/12/15 17:53, Andrew F. Davis wrote:
> On 12/05/2015 11:38 AM, Jonathan Cameron wrote:
>> On 02/12/15 19:57, Andrew F. Davis wrote:
>>> Add the TI afe4404 heart monitor DT bindings documentation.
>>> Create health directory created under iio.
>>>
>>> Signed-off-by: Andrew F. Davis 
>> One little point inline - otherwise this is straightforward and
>> looks good to me.
>>
>> Could add cross references to the interrupt and gpio docs.
>>
> 
> Will add.
> 
>> Jonathan
>>> ---
>>>   .../devicetree/bindings/iio/health/afe4404.txt | 27 
>>> ++
>>>   1 file changed, 27 insertions(+)
>>>   create mode 100644 
>>> Documentation/devicetree/bindings/iio/health/afe4404.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/health/afe4404.txt 
>>> b/Documentation/devicetree/bindings/iio/health/afe4404.txt
>>> new file mode 100644
>>> index 000..25b77a4
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/health/afe4404.txt
>>> @@ -0,0 +1,27 @@
>>> +* Texas Instruments AFE4404 Heart rate and Pulse Oximeter
>>> +
>>> +Required properties:
>>> + - compatible: Should be "ti,afe4404".
>>> + - reg: I2C address of the device.
>>> + - tx_sup-supply: Regulator supply to LEDs.
>> If the sup bit is for supply I'd drop it and just have
>> tx-supply.
> 
> It is, the name of the pin in the datasheet is "tx_sup", so
> I went with that.
Drop it - I suspect the device tree guys would prefer it without
and it's not hard to make the connection with the datasheet name!
> 
>>> + - interrupt-parent: Phandle to he parent interrupt controller.
>>> + - interrupts: The interrupt line the device ADC_RDY pin is 
>>> connected to.
>>> +
>>> +Optional properties:
>>> + - reset-gpios: GPIO used to reset the device.
>>> +
>>> +Example:
>>> +
>>> +&i2c2 {
>>> +heart_mon@58 {
>>> +compatible = "ti,afe4404";
>>> +reg = <0x58>;
>>> +
>>> +tx_sup-supply = <&vbat>;
>>> +
>>> +interrupt-parent = <&gpio1>;
>>> +interrupts = <28 IRQ_TYPE_EDGE_RISING>;
>>> +
>>> +reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
>>> +};
>>> +};
>>>
>>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] Documentation: afe4404: Add DT bindings for the AFE4404 heart monitor

[Jonathan Cameron]

On 02/12/15 19:57, Andrew F. Davis wrote:
> Add the TI afe4404 heart monitor DT bindings documentation.
> Create health directory created under iio.
> 
> Signed-off-by: Andrew F. Davis 
One little point inline - otherwise this is straightforward and
looks good to me.

Could add cross references to the interrupt and gpio docs.

Jonathan
> ---
>  .../devicetree/bindings/iio/health/afe4404.txt | 27 
> ++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/health/afe4404.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/health/afe4404.txt 
> b/Documentation/devicetree/bindings/iio/health/afe4404.txt
> new file mode 100644
> index 000..25b77a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/health/afe4404.txt
> @@ -0,0 +1,27 @@
> +* Texas Instruments AFE4404 Heart rate and Pulse Oximeter
> +
> +Required properties:
> + - compatible: Should be "ti,afe4404".
> + - reg   : I2C address of the device.
> + - tx_sup-supply : Regulator supply to LEDs.
If the sup bit is for supply I'd drop it and just have
tx-supply.
> + - interrupt-parent  : Phandle to he parent interrupt controller.
> + - interrupts: The interrupt line the device ADC_RDY pin is 
> connected to.
> +
> +Optional properties:
> + - reset-gpios   : GPIO used to reset the device.
> +
> +Example:
> +
> +&i2c2 {
> + heart_mon@58 {
> + compatible = "ti,afe4404";
> + reg = <0x58>;
> +
> + tx_sup-supply = <&vbat>;
> +
> + interrupt-parent = <&gpio1>;
> + interrupts = <28 IRQ_TYPE_EDGE_RISING>;
> +
> + reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
> + };
> +};
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] iio: light: us5182d: Add functions for selectively enabling als and proximity

[Jonathan Cameron]

On 24/11/15 10:59, Adriana Reus wrote:
> Keep track of the als and px enabled/disabled status in
> order to enable them selectively.
> 
> Signed-off-by: Adriana Reus 
Couple more nitpicks, but again fixed up during apply.
> ---
>  drivers/iio/light/us5182d.c | 64 
> ++---
>  1 file changed, 60 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 7993014..3d959f3 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -119,6 +119,9 @@ struct us5182d_data {
>   u8 opmode;
>   u8 power_mode;
>  
> + bool als_enabled;
> + bool px_enabled;
> +
>   bool default_continuous;
>  };
>  
> @@ -227,6 +230,48 @@ static int us5182d_set_opmode(struct us5182d_data *data, 
> u8 mode)
>   return 0;
>  }
>  
> +static int us5182d_als_enable(struct us5182d_data *data)
> +{
> + int ret;
> + u8 mode;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return us5182d_set_opmode(data, US5182D_ALS_ONLY);
> +
> + if (data->als_enabled)
> + return 0;
> +
> + mode = data->px_enabled ? US5182D_ALS_PX : US5182D_ALS_ONLY;
> +
> + ret = us5182d_set_opmode(data, mode);
> + if (ret < 0)
> + return ret;
> +
> + data->als_enabled = true;
Blank line here ideally.
> + return 0;
> +}
> +
> +static int us5182d_px_enable(struct us5182d_data *data)
> +{
> + int ret;
> + u8 mode;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return us5182d_set_opmode(data, US5182D_PX_ONLY);
> +
> + if (data->px_enabled)
> + return 0;
> +
> + mode = data->als_enabled ? US5182D_ALS_PX : US5182D_PX_ONLY;
> +
> + ret = us5182d_set_opmode(data, mode);
> + if (ret < 0)
> + return ret;
> +
> + data->px_enabled = true;
And here...
> + return 0;
> +}
> +
>  static int us5182d_shutdown_en (struct us5182d_data *data, u8 state)
>  {
>   int ret;
> @@ -241,7 +286,16 @@ static int us5182d_shutdown_en (struct us5182d_data 
> *data, u8 state)
>   ret = ret & ~US5182D_CFG0_SHUTDOWN_EN;
>   ret = ret | state;
>  
> - return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> + ret = i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> + if (ret < 0)
> + return ret;
> +
> + if (state & US5182D_CFG0_SHUTDOWN_EN) {
> + data->als_enabled = false;
> + data->px_enabled = false;
> + }
> +
> + return ret;
>  }
>  
>  static int us5182d_read_raw(struct iio_dev *indio_dev,
> @@ -261,7 +315,7 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out_err;
>   }
> - ret = us5182d_set_opmode(data, US5182D_OPMODE_ALS);
> + ret = us5182d_als_enable(data);
>   if (ret < 0)
>   goto out_err;
>  
> @@ -278,7 +332,7 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out_err;
>   }
> - ret = us5182d_set_opmode(data, US5182D_OPMODE_PX);
> + ret = us5182d_px_enable(data);
>   if (ret < 0)
>   goto out_err;
>  
> @@ -421,6 +475,9 @@ static int us5182d_init(struct iio_dev *indio_dev)
>   return ret;
>   }
>  
> + data->als_enabled = true;
> + data->px_enabled = true;
> +
>   if (!data->default_continuous) {
>   ret = us5182d_shutdown_en(data, US5182D_CFG0_SHUTDOWN_EN);
>   if (ret < 0)
> @@ -428,7 +485,6 @@ static int us5182d_init(struct iio_dev *indio_dev)
>   data->power_mode = US5182D_ONESHOT;
>   }
>  
> -
>   return ret;
>  }
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] iio: adc: add IMX7D ADC driver support

[Jonathan Cameron]

On 25/11/15 03:52, Stefan Agner wrote:
> Hi Haibo,
> 
> Some comments below:
> 
> On 2015-11-20 07:48, Haibo Chen wrote:
>> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
>> driver support, and the driver only support ADC software trigger.
>>
>> Signed-off-by: Haibo Chen 
>> ---
>>  drivers/iio/adc/Kconfig |   9 +
>>  drivers/iio/adc/Makefile|   1 +
>>  drivers/iio/adc/imx7d_adc.c | 570 
>> 
>>  3 files changed, 580 insertions(+)
>>  create mode 100644 drivers/iio/adc/imx7d_adc.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 7868c74..bf0611c 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -194,6 +194,15 @@ config HI8435
>>This driver can also be built as a module. If so, the module will be
>>called hi8435.
>>  
>> +config IMX7D_ADC
>> +tristate "IMX7D ADC driver"
>> +depends on OF
> 
> Hm, not sure, but shouldn't we use a proper depends here? Otherwise this
> will show up as modules in all kinds of distributions.
usual trick is a depends on the platform or COMPILE_TEST
(so that autobuilders will hit it)
> 
>> +help
>> +  Say yes here to build support for IMX7D ADC.
>> +
>> +  This driver can also be built as a module. If so, the module will be
>> +  called imx7d_adc.
>> +
>>  config LP8788_ADC
>>  tristate "LP8788 ADC driver"
>>  depends on MFD_LP8788
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 99b37a9..282ffc01 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>>  obj-$(CONFIG_HI8435) += hi8435.o
>> +obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>>  obj-$(CONFIG_MAX1027) += max1027.o
>>  obj-$(CONFIG_MAX1363) += max1363.o
>> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
>> new file mode 100644
>> index 000..d9547bf
>> --- /dev/null
>> +++ b/drivers/iio/adc/imx7d_adc.c
>> @@ -0,0 +1,570 @@
>> +/*
>> + * Freescale i.MX7D ADC driver
>> + *
>> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> Can you sort these alphabetically
> 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* ADC register */
>> +#define IMX7D_REG_ADC_CH_A_CFG1 0x00
>> +#define IMX7D_REG_ADC_CH_A_CFG2 0x10
>> +#define IMX7D_REG_ADC_CH_B_CFG1 0x20
>> +#define IMX7D_REG_ADC_CH_B_CFG2 0x30
>> +#define IMX7D_REG_ADC_CH_C_CFG1 0x40
>> +#define IMX7D_REG_ADC_CH_C_CFG2 0x50
>> +#define IMX7D_REG_ADC_CH_D_CFG1 0x60
>> +#define IMX7D_REG_ADC_CH_D_CFG2 0x70
>> +#define IMX7D_REG_ADC_CH_SW_CFG 0x80
>> +#define IMX7D_REG_ADC_TIMER_UNIT0x90
>> +#define IMX7D_REG_ADC_DMA_FIFO  0xa0
>> +#define IMX7D_REG_ADC_FIFO_STATUS   0xb0
>> +#define IMX7D_REG_ADC_INT_SIG_EN0xc0
>> +#define IMX7D_REG_ADC_INT_EN0xd0
>> +#define IMX7D_REG_ADC_INT_STATUS0xe0
>> +#define IMX7D_REG_ADC_CHA_B_CNV_RSLT0xf0
>> +#define IMX7D_REG_ADC_CHC_D_CNV_RSLT0x100
>> +#define IMX7D_REG_ADC_CH_SW_CNV_RSLT0x110
>> +#define IMX7D_REG_ADC_DMA_FIFO_DAT  0x120
>> +#define IMX7D_REG_ADC_ADC_CFG   0x130
>> +
>> +#define IMX7D_EACH_CHANNEL_REG_SHIF 0x20
> 
> I would call that OFFSET, SHIFT is typically used for a bit offset
> within a register.
> 
>> +
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_EN(0x1 << 31)
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_DISABLE   (0x0 << 
>> 31)
> 
> I would just define the _EN definition (along with using BIT).
> Bitshifting a 0 is not really useful.
> 
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SINGLEBIT(30)
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_AVG_ENBIT(29)
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SEL_SHIF  24
>> +
>> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_4 (0x0 << 
>> 12)
>> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_8 (0x1 << 
>> 12)
>> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_16(0x2 << 12)
>> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_32 

Re: [PATCH 5/5] iio: light: us5182d: Add interrupt support and events

[Jonathan Cameron]

On 24/11/15 10:59, Adriana Reus wrote:
> Add interrupt support and events for proximity.
> Add two threshold events to signal rising and falling directions.
> 
> Signed-off-by: Adriana Reus 
A few bits and bobs inline...
> ---
>  drivers/iio/light/us5182d.c | 272 
> +++-
>  1 file changed, 271 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 60cab4a..4d1f80d 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -20,7 +20,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -30,6 +33,8 @@
>  #define US5182D_CFG0_ONESHOT_EN  BIT(6)
>  #define US5182D_CFG0_SHUTDOWN_EN BIT(7)
>  #define US5182D_CFG0_WORD_ENABLE BIT(0)
> +#define US5182D_CFG0_PROXBIT(3)
> +#define US5182D_CFG0_PX_IRQ  BIT(2)
>  
>  #define US5182D_REG_CFG1 0x01
>  #define US5182D_CFG1_ALS_RES16   BIT(4)
> @@ -41,6 +46,7 @@
>  
>  #define US5182D_REG_CFG3 0x03
>  #define US5182D_CFG3_LED_CURRENT100  (BIT(4) | BIT(5))
> +#define US5182D_CFG3_INT_SOURCE_PX   BIT(3)
>  
>  #define US5182D_REG_CFG4 0x10
>  
> @@ -55,6 +61,13 @@
>  #define US5182D_REG_AUTO_LDARK_GAIN  0x29
>  #define US5182D_REG_AUTO_HDARK_GAIN  0x2a
>  
> +/* Thresholds for events: px low (0x08-l, 0x09-h), px high (0x0a-l 0x0b-h) */
> +#define US5182D_REG_PXL_TH   0x08
> +#define US5182D_REG_PXH_TH   0x0a
> +
> +#define US5182D_REG_PXL_TH_DEFAULT   1000
> +#define US5182D_REG_PXH_TH_DEFAULT   3
> +
>  #define US5182D_OPMODE_ALS   0x01
>  #define US5182D_OPMODE_PX0x02
>  #define US5182D_OPMODE_SHIFT 4
> @@ -84,6 +97,8 @@
>  #define US5182D_READ_WORD2
>  #define US5182D_OPSTORE_SLEEP_TIME   20 /* ms */
>  #define US5182D_SLEEP_MS 3000 /* ms */
> +#define US5182D_PXH_TH_DISABLE   0x
> +#define US5182D_PXL_TH_DISABLE   0x
>  
>  /* Available ranges: [12354, 7065, 3998, 2202, 1285, 498, 256, 138] lux */
>  static const int us5182d_scales[] = {188500, 107800, 61000, 33600, 19600, 
> 7600,
> @@ -119,6 +134,12 @@ struct us5182d_data {
>   u8 upper_dark_gain;
>   u16 *us5182d_dark_ths;
>  
> + u16 px_low_th;
> + u16 px_high_th;
> +
> + int rising_en;
> + int falling_en;
> +
>   u8 opmode;
>   u8 power_mode;
>  
> @@ -148,10 +169,26 @@ static const struct {
>   {US5182D_REG_CFG1, US5182D_CFG1_ALS_RES16},
>   {US5182D_REG_CFG2, (US5182D_CFG2_PX_RES16 |
>   US5182D_CFG2_PXGAIN_DEFAULT)},
> - {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100},
> + {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100 |
> +US5182D_CFG3_INT_SOURCE_PX},
>   {US5182D_REG_CFG4, 0x00},
>  };
>  
> +static const struct iio_event_spec us5182d_events[] = {
> + {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_RISING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_ENABLE),
> + },
> + {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_FALLING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_ENABLE),
> + },
> +};
> +
>  static const struct iio_chan_spec us5182d_channels[] = {
>   {
>   .type = IIO_LIGHT,
> @@ -161,6 +198,8 @@ static const struct iio_chan_spec us5182d_channels[] = {
>   {
>   .type = IIO_PROXIMITY,
>   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .event_spec = us5182d_events,
> + .num_event_specs = ARRAY_SIZE(us5182d_events),
>   }
>  };
>  
> @@ -477,11 +516,199 @@ static int us5182d_write_raw(struct iio_dev *indio_dev,
>   return -EINVAL;
>  }
>  
> +static int us5182d_setup_prox(struct iio_dev *indio_dev,
> +   enum iio_event_direction dir, u16 val)
> +{
> + struct us5182d_data *data = iio_priv(indio_dev);
> + int ret = 0;
> +
> + if (dir == IIO_EV_DIR_FALLING)
> + ret = i2c_smbus_write_word_data(data->client,
> + US5182D_REG_PXL_TH, val);
> +
> + if (dir == IIO_EV_DIR_RISING)
> + ret = i2c_smbus_write_word_data(data->client,
> + US5182D_REG_PXH_TH, val);
> +
> + return ret;
return directly above, no need for the local ret variable and return
0 here.
> +}
> +
> +static int us5182d_read_thresh(struct iio_dev 

Re: [PATCH 4/5] iio: light: us8152d: Add power management support

[Jonathan Cameron]

On 24/11/15 10:59, Adriana Reus wrote:
> Add power management for sleep as well as runtime pm.
> 
> Signed-off-by: Adriana Reus 
Mostly fine, but a comment on a possible future tidy up inline.

Applied to the togreg branch of iio.git - initially pushed out as
testing for the autobuilders to play with it.

> ---
>  drivers/iio/light/us5182d.c | 95 
> +
>  1 file changed, 88 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 3d959f3..60cab4a 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #define US5182D_REG_CFG0 0x00
>  #define US5182D_CFG0_ONESHOT_EN  BIT(6)
> @@ -81,6 +83,7 @@
>  #define US5182D_READ_BYTE1
>  #define US5182D_READ_WORD2
>  #define US5182D_OPSTORE_SLEEP_TIME   20 /* ms */
> +#define US5182D_SLEEP_MS 3000 /* ms */
>  
>  /* Available ranges: [12354, 7065, 3998, 2202, 1285, 498, 256, 138] lux */
>  static const int us5182d_scales[] = {188500, 107800, 61000, 33600, 19600, 
> 7600,
> @@ -298,6 +301,26 @@ static int us5182d_shutdown_en (struct us5182d_data 
> *data, u8 state)
>   return ret;
>  }
>  
> +
> +static int us5182d_set_power_state(struct us5182d_data *data, bool on)
> +{
> + int ret;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return 0;
> +
> + if (on) {
> + ret = pm_runtime_get_sync(&data->client->dev);
> + if (ret < 0)
> + pm_runtime_put_noidle(&data->client->dev);
> + } else {
> + pm_runtime_mark_last_busy(&data->client->dev);
> + ret = pm_runtime_put_autosuspend(&data->client->dev);
> + }
> +
> + return ret;
> +}
> +
>  static int us5182d_read_raw(struct iio_dev *indio_dev,
>   struct iio_chan_spec const *chan, int *val,
>   int *val2, long mask)
> @@ -315,15 +338,20 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out_err;
>   }
> - ret = us5182d_als_enable(data);
> + ret = us5182d_set_power_state(data, true);
>   if (ret < 0)
>   goto out_err;
> -
> + ret = us5182d_als_enable(data);
> + if (ret < 0)
> + goto out_poweroff;
>   ret = us5182d_get_als(data);
>   if (ret < 0)
> + goto out_poweroff;
> + *val = ret;
> + ret = us5182d_set_power_state(data, false);
> + if (ret < 0)
>   goto out_err;
>   mutex_unlock(&data->lock);
> - *val = ret;
>   return IIO_VAL_INT;
>   case IIO_PROXIMITY:
I'd argue the complexity of this has reached the point where ideally you'd
break it out to a function.  The jumps out of the switch statement are 
particularly nasty from a readability point of view.

Perhaps a job for a followup patch?
>   mutex_lock(&data->lock);
> @@ -332,17 +360,22 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out_err;
>   }
> - ret = us5182d_px_enable(data);
> + ret = us5182d_set_power_state(data, true);
>   if (ret < 0)
>   goto out_err;
> -
> + ret = us5182d_px_enable(data);
> + if (ret < 0)
> + goto out_poweroff;
>   ret = i2c_smbus_read_word_data(data->client,
>  US5182D_REG_PDL);
>   if (ret < 0)
> + goto out_poweroff;
> + *val = ret;
> + ret = us5182d_set_power_state(data, false);
> + if (ret < 0)
>   goto out_err;
>   mutex_unlock(&data->lock);
> - *val = ret;
> - return  IIO_VAL_INT;
> + return IIO_VAL_INT;
This is a little bit of noise that should have been dealt with separately...

>   default:
>   return -EINVAL;
>   }
> @@ -361,6 +394,9 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   }
>  
>   return -EINVAL;
> +
> +out_poweroff:
> + us5182d_set_power_state(data, false);
>  out_err:
>   mutex_unlock(&data->lock);
>  

Re: [PATCH 1/5] iio: light: us5182d: Add property for choosing default power mode

[Jonathan Cameron]

On 24/11/15 10:59, Adriana Reus wrote:
> This chip supports two power modes.
> 1. "one-shot" mode - the chip activates and executes one complete
> conversion loop and then shuts itself down. This is the default mode
> chosen for raw reads.
> 2. "continuous" mode - the chip takes continuous measurements.
> 
> Continuous mode is more expensive power-wise but may be more reliable.
> Add a property so that if preferred, the default power mode for raw
> reads can be set to continuous.
> Separate one-shot enabling in a separate function that will be used
> depending on the chosen power mode. Also create a function for
> powering the chip on and off.
> 
> Signed-off-by: Adriana Reus 
A couple of nitpicks inline...  I've fixed them up when applying to the
togreg branch of iio.git - initially pushed out as testing for the autobuilders
to play with them.

Thanks,

Jonathan
> ---
>  drivers/iio/light/us5182d.c | 90 
> +++--
>  1 file changed, 78 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 49dab3c..7993014 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -99,6 +99,11 @@ enum mode {
>   US5182D_PX_ONLY
>  };
>  
> +enum pmode {
> + US5182D_CONTINUOUS,
> + US5182D_ONESHOT
> +};
> +
>  struct us5182d_data {
>   struct i2c_client *client;
>   struct mutex lock;
> @@ -112,6 +117,9 @@ struct us5182d_data {
>   u16 *us5182d_dark_ths;
>  
>   u8 opmode;
> + u8 power_mode;
> +
> + bool default_continuous;
>  };
>  
>  static IIO_CONST_ATTR(in_illuminance_scale_available,
> @@ -130,13 +138,11 @@ static const struct {
>   u8 reg;
>   u8 val;
>  } us5182d_regvals[] = {
> - {US5182D_REG_CFG0, (US5182D_CFG0_SHUTDOWN_EN |
> - US5182D_CFG0_WORD_ENABLE)},
> + {US5182D_REG_CFG0, US5182D_CFG0_WORD_ENABLE},
>   {US5182D_REG_CFG1, US5182D_CFG1_ALS_RES16},
>   {US5182D_REG_CFG2, (US5182D_CFG2_PX_RES16 |
>   US5182D_CFG2_PXGAIN_DEFAULT)},
>   {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100},
> - {US5182D_REG_MODE_STORE, US5182D_STORE_MODE},
>   {US5182D_REG_CFG4, 0x00},
>  };
>  
> @@ -169,7 +175,7 @@ static int us5182d_get_als(struct us5182d_data *data)
>   return result;
>  }
>  
> -static int us5182d_set_opmode(struct us5182d_data *data, u8 mode)
> +static int us5182d_oneshot_en(struct us5182d_data *data)
>  {
>   int ret;
>  
> @@ -182,6 +188,20 @@ static int us5182d_set_opmode(struct us5182d_data *data, 
> u8 mode)
>* required measurement.
>*/
>   ret = ret | US5182D_CFG0_ONESHOT_EN;
> + return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
Unwanted extra blank line here...
> +
> +}
> +
> +static int us5182d_set_opmode(struct us5182d_data *data, u8 mode)
> +{
> + int ret;
> +
> + if (mode == data->opmode)
> + return 0;
> +
> + ret = i2c_smbus_read_byte_data(data->client, US5182D_REG_CFG0);
> + if (ret < 0)
> + return ret;
>  
>   /* update mode */
>   ret = ret & ~US5182D_OPMODE_MASK;
> @@ -196,9 +216,6 @@ static int us5182d_set_opmode(struct us5182d_data *data, 
> u8 mode)
>   if (ret < 0)
>   return ret;
>  
> - if (mode == data->opmode)
> - return 0;
> -
>   ret = i2c_smbus_write_byte_data(data->client, US5182D_REG_MODE_STORE,
>   US5182D_STORE_MODE);
>   if (ret < 0)
> @@ -210,6 +227,23 @@ static int us5182d_set_opmode(struct us5182d_data *data, 
> u8 mode)
>   return 0;
>  }
>  
> +static int us5182d_shutdown_en (struct us5182d_data *data, u8 state)
Stray space above.. Checkpatch would have highlighted this for you, please
do run it as a sanity check before you send a series out.

> +{
> + int ret;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return 0;
> +
> + ret = i2c_smbus_read_byte_data(data->client, US5182D_REG_CFG0);
> + if (ret < 0)
> + return ret;
> +
> + ret = ret & ~US5182D_CFG0_SHUTDOWN_EN;
> + ret = ret | state;
> +
> + return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> +}
> +
>  static int us5182d_read_raw(struct iio_dev *indio_dev,
>   struct iio_chan_spec const *chan, int *val,
>   int *val2, long mask)
> @@ -222,6 +256,11 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   switch (chan->type) {
>   case IIO_LIGHT:
>   mutex_lock(&data->lock);
> + if (data->power_mode == US5182D_ONESHOT) {
> + ret = us5182d_oneshot_en(data);
> + if (ret < 0)
> + goto out_err;
> + }
>   ret = us5182d_set_opmode(data, US5182D_OPMODE_ALS);
>   if (ret <

Re: [PATCH 2/5] Documentation: devicetree: Add property for controlling power saving mode for the us5182 als sensor

[Jonathan Cameron]

On 25/11/15 23:55, Rob Herring wrote:
> On Wed, Nov 25, 2015 at 11:50:30AM +0200, Adriana Reus wrote:
>>
>>
>> On 25.11.2015 02:01, Rob Herring wrote:
>>> On Tue, Nov 24, 2015 at 12:59:49PM +0200, Adriana Reus wrote:
 Add a property to allow changing the default power-saving mode.
 By default, at read raw the chip will activate and provide
 one measurent, then it will shut itself down. However, the
 chip can also work in "continuous" mode which may be more reliable
 but is also more power consuming.

 Signed-off-by: Adriana Reus 
 ---
  Documentation/devicetree/bindings/iio/light/us5182d.txt | 11 +++
  1 file changed, 11 insertions(+)

 diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt 
 b/Documentation/devicetree/bindings/iio/light/us5182d.txt
 index 6f0a530..a619799 100644
 --- a/Documentation/devicetree/bindings/iio/light/us5182d.txt
 +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
 @@ -7,13 +7,24 @@ Required properties:
  Optional properties:
  - upisemi,glass-coef: glass attenuation factor - compensation factor of
resolution 1000 for material transmittance.
 +
  - upisemi,dark-ths: array of 8 elements containing 16-bit thresholds (adc
  counts) corresponding to every scale.
 +
  - upisemi,upper-dark-gain: 8-bit dark gain compensation factor(4 int and 4
 fractional bits - Q4.4) applied when light > 
 threshold
 +
  - upisemi,lower-dark-gain: 8-bit dark gain compensation factor(4 int and 4
 fractional bits - Q4.4) applied when light < 
 threshold

 +- upisemi,continuous: This chip has two power modes: one-shot (chip takes 
 one
 +  measurement and then shuts itself down) and 
 continuous (
 +  chip takes continuous measurements). The one-shot 
 mode is
 +  more power-friendly but the continuous mode may be 
 more
 +  reliable. If this property is specified the 
 continuous
 +  mode will be used instead of the default one-shot 
 one for
 +  raw reads.
>>>
>>> I could imagine an OS may want to decide this on its own or use a
>>> mixture of the modes.
>>>
>>> Rob
>>>
>>
>> There is no possibility of mixing them up (at the same time), so for example
>> proximity cannot work in one mode and als the other.
>>
>> The one-shot mode can only be used for raw reads (for example when
>> user-space polls in_[proximity|light]_raw). If user-space wants to enable
>> events (activate interrupts when certain thresholds are met - patch 5 of the
>> series), then the chip has to switch to continuous nonetheless because it
>> needs to be active all the time. So one work-flow scenario would be:
>>
>> Consumer1 starts polling the raw interface - default_mode
>> Consumer2 activates events - continuous mode
>> Consumer2 deactivates events - back to default_mode
>>
>> The only choice here is the default mode for raw reads, it currently is
>> one-shot, this patch allows for continuous to be used if preferred.
> 
> Okay, then:
> 
> Acked-by: Rob Herring 
Applied to the togreg branch of iio.git - initially pushed out as testing.

Thanks,

Jonathan
> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dt-bindings: iio: adc: Update mcp342x binding for the mcp3421

[Jonathan Cameron]

On 27/11/15 20:15, Rob Herring wrote:
> On Fri, Nov 27, 2015 at 02:52:52PM +0100, Sascha Hauer wrote:
>> The mcp3421 is the single channel variant of the mcp342x family and
>> can be supported by the mcp342x driver.
>>
>> Signed-off-by: Sascha Hauer 
>> Cc: devicetree@vger.kernel.org
> 
> Acked-by: Rob Herring 
Applied.

Thanks,

Jonathan
> 
>> ---
>>  Documentation/devicetree/bindings/iio/adc/mcp3422.txt | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt 
>> b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
>> index 333139c..dcae4cc 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
>> +++ b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
>> @@ -1,7 +1,8 @@
>> -* Microchip mcp3422/3/4/6/7/8 chip family (ADC)
>> +* Microchip mcp3421/2/3/4/6/7/8 chip family (ADC)
>>  
>>  Required properties:
>>   - compatible: Should be
>> +"microchip,mcp3421" or
>>  "microchip,mcp3422" or
>>  "microchip,mcp3423" or
>>  "microchip,mcp3424" or
>> -- 
>> 2.6.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 6/8] input: touchscreen: imx25 tcq driver

[Jonathan Cameron]

On 21/11/15 17:48, Jonathan Cameron wrote:
> On 16/11/15 12:01, Markus Pargmann wrote:
>> This is a driver for the imx25 ADC/TSC module. It controls the
>> touchscreen conversion queue and creates a touchscreen input device.
>> The driver currently only supports 4 wire touchscreens. The driver uses
>> a simple conversion queue of precharge, touch detection, X measurement,
>> Y measurement, precharge and another touch detection.
>>
>> This driver uses the regmap from the parent to setup some touch specific
>> settings in the core driver and setup a idle configuration with touch
>> detection.
>>
>> Signed-off-by: Markus Pargmann 
>> Signed-off-by: Denis Carikli 
>>
>> [fix clock's period calculation]
>> [fix calculation of the 'settling' value]
>> Signed-off-by: Juergen Borleis 
> I read this out of curiousity to see how you had handled the touchscreen
> usecase of this hardware differently from the generic version.
> 
> Anyhow, a few little bits and pieces inline from me as a result
Ah, I'd missed Dmitry's review.  Looks like he raised the same issue
on ordering in the probe so it doesn't work how I thought ;)
> 
> Jonathan
>> ---
>>
>> Notes:
>> Changes in v7:
>>  - Moved clk_prepare_enable() and mx25_tcq_init() into mx25_tcq_open(). 
>> This
>>was done to be able to use devm_request_threaded_irq().
>>  - Cleanup of the probe function through above change
>>  - Removed mx25_tcq_remove(), not necessary now
>>
>>  drivers/input/touchscreen/Kconfig |   6 +
>>  drivers/input/touchscreen/Makefile|   1 +
>>  drivers/input/touchscreen/fsl-imx25-tcq.c | 600 
>> ++
>>  3 files changed, 607 insertions(+)
>>  create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
>>
>> diff --git a/drivers/input/touchscreen/Kconfig 
>> b/drivers/input/touchscreen/Kconfig
>> index ae33da7ab51f..b44651d33080 100644
>> --- a/drivers/input/touchscreen/Kconfig
>> +++ b/drivers/input/touchscreen/Kconfig
>> @@ -811,6 +811,12 @@ config TOUCHSCREEN_USB_COMPOSITE
>>To compile this driver as a module, choose M here: the
>>module will be called usbtouchscreen.
>>  
>> +config TOUCHSCREEN_MX25
>> +tristate "Freescale i.MX25 touchscreen input driver"
>> +depends on MFD_MX25_TSADC
>> +help
>> +  Enable support for touchscreen connected to your i.MX25.
>> +
>>  config TOUCHSCREEN_MC13783
>>  tristate "Freescale MC13783 touchscreen input driver"
>>  depends on MFD_MC13XXX
>> diff --git a/drivers/input/touchscreen/Makefile 
>> b/drivers/input/touchscreen/Makefile
>> index cbaa6abb08da..77a2ac54101a 100644
>> --- a/drivers/input/touchscreen/Makefile
>> +++ b/drivers/input/touchscreen/Makefile
>> @@ -45,6 +45,7 @@ obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)+= 
>> intel-mid-touch.o
>>  obj-$(CONFIG_TOUCHSCREEN_IPROC) += bcm_iproc_tsc.o
>>  obj-$(CONFIG_TOUCHSCREEN_LPC32XX)   += lpc32xx_ts.o
>>  obj-$(CONFIG_TOUCHSCREEN_MAX11801)  += max11801_ts.o
>> +obj-$(CONFIG_TOUCHSCREEN_MX25)  += fsl-imx25-tcq.o
>>  obj-$(CONFIG_TOUCHSCREEN_MC13783)   += mc13783_ts.o
>>  obj-$(CONFIG_TOUCHSCREEN_MCS5000)   += mcs5000_ts.o
>>  obj-$(CONFIG_TOUCHSCREEN_MIGOR) += migor_ts.o
>> diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c 
>> b/drivers/input/touchscreen/fsl-imx25-tcq.c
>> new file mode 100644
>> index ..c833cd814972
>> --- /dev/null
>> +++ b/drivers/input/touchscreen/fsl-imx25-tcq.c
>> @@ -0,0 +1,600 @@
>> +/*
>> + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann 
>> 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it 
>> under
>> + * the terms of the GNU General Public License version 2 as published by the
>> + * Free Software Foundation.
>> + *
>> + * Based on driver from 2011:
>> + *   Juergen Beisert, Pengutronix 
>> + *
>> + * This is the driver for the imx25 TCQ (Touchscreen Conversion Queue)
>> + * connected to the imx25 ADC.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static const char mx25_tcq_name[] = "mx25-tcq";
>> +
>> +enum mx25_tcq_mode {
>> +MX25_TS_4WIRE,
>> +};
>> +
>> +struct mx25_tcq_priv {
>> +struct regmap *re

Re: [PATCH v8 6/8] input: touchscreen: imx25 tcq driver

[Jonathan Cameron]

On 16/11/15 12:01, Markus Pargmann wrote:
> This is a driver for the imx25 ADC/TSC module. It controls the
> touchscreen conversion queue and creates a touchscreen input device.
> The driver currently only supports 4 wire touchscreens. The driver uses
> a simple conversion queue of precharge, touch detection, X measurement,
> Y measurement, precharge and another touch detection.
> 
> This driver uses the regmap from the parent to setup some touch specific
> settings in the core driver and setup a idle configuration with touch
> detection.
> 
> Signed-off-by: Markus Pargmann 
> Signed-off-by: Denis Carikli 
> 
> [fix clock's period calculation]
> [fix calculation of the 'settling' value]
> Signed-off-by: Juergen Borleis 
I read this out of curiousity to see how you had handled the touchscreen
usecase of this hardware differently from the generic version.

Anyhow, a few little bits and pieces inline from me as a result

Jonathan
> ---
> 
> Notes:
> Changes in v7:
>  - Moved clk_prepare_enable() and mx25_tcq_init() into mx25_tcq_open(). 
> This
>was done to be able to use devm_request_threaded_irq().
>  - Cleanup of the probe function through above change
>  - Removed mx25_tcq_remove(), not necessary now
> 
>  drivers/input/touchscreen/Kconfig |   6 +
>  drivers/input/touchscreen/Makefile|   1 +
>  drivers/input/touchscreen/fsl-imx25-tcq.c | 600 
> ++
>  3 files changed, 607 insertions(+)
>  create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index ae33da7ab51f..b44651d33080 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -811,6 +811,12 @@ config TOUCHSCREEN_USB_COMPOSITE
> To compile this driver as a module, choose M here: the
> module will be called usbtouchscreen.
>  
> +config TOUCHSCREEN_MX25
> + tristate "Freescale i.MX25 touchscreen input driver"
> + depends on MFD_MX25_TSADC
> + help
> +   Enable support for touchscreen connected to your i.MX25.
> +
>  config TOUCHSCREEN_MC13783
>   tristate "Freescale MC13783 touchscreen input driver"
>   depends on MFD_MC13XXX
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index cbaa6abb08da..77a2ac54101a 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_TOUCHSCREEN_INTEL_MID) += intel-mid-touch.o
>  obj-$(CONFIG_TOUCHSCREEN_IPROC)  += bcm_iproc_tsc.o
>  obj-$(CONFIG_TOUCHSCREEN_LPC32XX)+= lpc32xx_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_MAX11801)   += max11801_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_MX25)   += fsl-imx25-tcq.o
>  obj-$(CONFIG_TOUCHSCREEN_MC13783)+= mc13783_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_MCS5000)+= mcs5000_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_MIGOR)  += migor_ts.o
> diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c 
> b/drivers/input/touchscreen/fsl-imx25-tcq.c
> new file mode 100644
> index ..c833cd814972
> --- /dev/null
> +++ b/drivers/input/touchscreen/fsl-imx25-tcq.c
> @@ -0,0 +1,600 @@
> +/*
> + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann 
> + *
> + * This program is free software; you can redistribute it and/or modify it 
> under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + *
> + * Based on driver from 2011:
> + *   Juergen Beisert, Pengutronix 
> + *
> + * This is the driver for the imx25 TCQ (Touchscreen Conversion Queue)
> + * connected to the imx25 ADC.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const char mx25_tcq_name[] = "mx25-tcq";
> +
> +enum mx25_tcq_mode {
> + MX25_TS_4WIRE,
> +};
> +
> +struct mx25_tcq_priv {
> + struct regmap *regs;
> + struct regmap *core_regs;
> + struct input_dev *idev;
> + enum mx25_tcq_mode mode;
> + unsigned int pen_threshold;
> + unsigned int sample_count;
> + unsigned int expected_samples;
> + unsigned int pen_debounce;
> + unsigned int settling_time;
> + struct clk *clk;
> + int irq;
> +};
> +
> +static struct regmap_config mx25_tcq_regconfig = {
> + .fast_io = true,
> + .max_register = 0x5c,
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static const struct of_device_id mx25_tcq_ids[] = {
> + { .compatible = "fsl,imx25-tcq", },
> + { /* Sentinel */ }
> +};
> +
> +#define TSC_4WIRE_PRE_INDEX 0
> +#define TSC_4WIRE_X_INDEX 1
> +#define TSC_4WIRE_Y_INDEX 2
> +#define TSC_4WIRE_POST_INDEX 3
> +#define TSC_4WIRE_LEAVE 4
> +
> +#define MX25_TSC_DEF_THRESHOLD 80
> +#define TSC_MAX_SAMPLES 16
> +
> +#define MX25_TSC_REPEAT_WAIT 14
> +
> +enum mx25_adc_configurations {
> + MX25_CFG_PRECHARGE = 0,
> + MX25_CFG

Re: [PATCH v8 4/8] mfd: fsl imx25 Touchscreen ADC driver

[Jonathan Cameron]

On 21/11/15 17:02, Jonathan Cameron wrote:
> On 16/11/15 12:01, Markus Pargmann wrote:
>> This is the core driver for imx25 touchscreen/adc driver. The module
>> has one shared ADC and two different conversion queues which use the
>> ADC. The two queues are identical. Both can be used for general purpose
>> ADC but one is meant to be used for touchscreens.
>>
>> This driver is the core which manages the central components and
>> registers of the TSC/ADC unit. It manages the IRQs and forwards them to
>> the correct components.
>>
>> Signed-off-by: Markus Pargmann 
>> Signed-off-by: Denis Carikli 
>>
>> [ensure correct ADC clock depending on the IPG clock]
>> Signed-off-by: Juergen Borleis 
> Looks good to me - one query on meaning of a comment inline.
> 
> Acked-by: Jonathan Cameron 
> 
> I'm taking the view this series wants to go through the MFD tree
> but don't mind if it goes through IIO or input instead
> if there is a good reason to do so.
> 
> Jonathan
>> ---
>>
>> Notes:
>> Changes in v7:
>>  - Cleanup bit defines in header files to be more readable
>>  - Fix irq check to return with an error for irq <= 0
>>  - Add COMPILE_TEST in Kconfig file
>> 
>> Changes in v5:
>>  - Remove ifdef CONFIG_OF as this driver is only for DT usage
>>  - Remove module owner
>>  - Add Kconfig dependencies ARCH_MX25 and OF
>> 
>> @Jonathan Cameron:
>> I left your acked-by on the patch as these were small changes. If it 
>> should be
>> removed, please say so. Thanks
>>
>>  drivers/mfd/Kconfig |   9 ++
>>  drivers/mfd/Makefile|   2 +
>>  drivers/mfd/fsl-imx25-tsadc.c   | 204 
>> 
>>  include/linux/mfd/imx25-tsadc.h | 140 +++
>>  4 files changed, 355 insertions(+)
>>  create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
>>  create mode 100644 include/linux/mfd/imx25-tsadc.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 4d92df6ef9fe..4222e202ad2b 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -271,6 +271,15 @@ config MFD_MC13XXX_I2C
>>  help
>>Select this if your MC13xxx is connected via an I2C bus.
>>  
>> +config MFD_MX25_TSADC
>> +tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
>> +select REGMAP_MMIO
>> +depends on (SOC_IMX25 && OF) || COMPILE_TEST
>> +help
>> +  Enable support for the integrated Touchscreen and ADC unit of the
>> +  i.MX25 processors. They consist of a conversion queue for general
>> +  purpose ADC and a queue for Touchscreens.
>> +
>>  config MFD_HI6421_PMIC
>>  tristate "HiSilicon Hi6421 PMU/Codec IC"
>>  depends on OF
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index a8b76b81b467..5741be88c173 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -81,6 +81,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
>>  obj-$(CONFIG_MFD_TWL4030_AUDIO) += twl4030-audio.o
>>  obj-$(CONFIG_TWL6040_CORE)  += twl6040.o
>>  
>> +obj-$(CONFIG_MFD_MX25_TSADC)+= fsl-imx25-tsadc.o
>> +
>>  obj-$(CONFIG_MFD_MC13XXX)   += mc13xxx-core.o
>>  obj-$(CONFIG_MFD_MC13XXX_SPI)   += mc13xxx-spi.o
>>  obj-$(CONFIG_MFD_MC13XXX_I2C)   += mc13xxx-i2c.o
>> diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
>> new file mode 100644
>> index ..e67d5ca81e10
>> --- /dev/null
>> +++ b/drivers/mfd/fsl-imx25-tsadc.c
>> @@ -0,0 +1,204 @@
>> +/*
>> + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann 
>> 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it 
>> under
>> + * the terms of the GNU General Public License version 2 as published by the
>> + * Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static struct regmap_config mx25_tsadc_regmap_config = {
>> +.fast_io = true,
>> +.max_register = 8,
>> +.reg_bits = 32,
>> +.val_bits = 32,
>> +.reg_stride = 4,
>> +};
>> +
>> +static void mx25_tsadc_irq_handler(struct irq_desc *desc)
>> +{
>> 

Re: [PATCH v8 4/8] mfd: fsl imx25 Touchscreen ADC driver

[Jonathan Cameron]

On 16/11/15 12:01, Markus Pargmann wrote:
> This is the core driver for imx25 touchscreen/adc driver. The module
> has one shared ADC and two different conversion queues which use the
> ADC. The two queues are identical. Both can be used for general purpose
> ADC but one is meant to be used for touchscreens.
> 
> This driver is the core which manages the central components and
> registers of the TSC/ADC unit. It manages the IRQs and forwards them to
> the correct components.
> 
> Signed-off-by: Markus Pargmann 
> Signed-off-by: Denis Carikli 
> 
> [ensure correct ADC clock depending on the IPG clock]
> Signed-off-by: Juergen Borleis 
Looks good to me - one query on meaning of a comment inline.

Acked-by: Jonathan Cameron 

I'm taking the view this series wants to go through the MFD tree
but don't mind if it goes through IIO or input instead
if there is a good reason to do so.

Jonathan
> ---
> 
> Notes:
> Changes in v7:
>  - Cleanup bit defines in header files to be more readable
>  - Fix irq check to return with an error for irq <= 0
>  - Add COMPILE_TEST in Kconfig file
> 
> Changes in v5:
>  - Remove ifdef CONFIG_OF as this driver is only for DT usage
>  - Remove module owner
>  - Add Kconfig dependencies ARCH_MX25 and OF
> 
> @Jonathan Cameron:
> I left your acked-by on the patch as these were small changes. If it 
> should be
> removed, please say so. Thanks
> 
>  drivers/mfd/Kconfig |   9 ++
>  drivers/mfd/Makefile|   2 +
>  drivers/mfd/fsl-imx25-tsadc.c   | 204 
> 
>  include/linux/mfd/imx25-tsadc.h | 140 +++
>  4 files changed, 355 insertions(+)
>  create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
>  create mode 100644 include/linux/mfd/imx25-tsadc.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 4d92df6ef9fe..4222e202ad2b 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -271,6 +271,15 @@ config MFD_MC13XXX_I2C
>   help
> Select this if your MC13xxx is connected via an I2C bus.
>  
> +config MFD_MX25_TSADC
> + tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
> + select REGMAP_MMIO
> + depends on (SOC_IMX25 && OF) || COMPILE_TEST
> + help
> +   Enable support for the integrated Touchscreen and ADC unit of the
> +   i.MX25 processors. They consist of a conversion queue for general
> +   purpose ADC and a queue for Touchscreens.
> +
>  config MFD_HI6421_PMIC
>   tristate "HiSilicon Hi6421 PMU/Codec IC"
>   depends on OF
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index a8b76b81b467..5741be88c173 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -81,6 +81,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
>  obj-$(CONFIG_MFD_TWL4030_AUDIO)  += twl4030-audio.o
>  obj-$(CONFIG_TWL6040_CORE)   += twl6040.o
>  
> +obj-$(CONFIG_MFD_MX25_TSADC) += fsl-imx25-tsadc.o
> +
>  obj-$(CONFIG_MFD_MC13XXX)+= mc13xxx-core.o
>  obj-$(CONFIG_MFD_MC13XXX_SPI)+= mc13xxx-spi.o
>  obj-$(CONFIG_MFD_MC13XXX_I2C)+= mc13xxx-i2c.o
> diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
> new file mode 100644
> index ..e67d5ca81e10
> --- /dev/null
> +++ b/drivers/mfd/fsl-imx25-tsadc.c
> @@ -0,0 +1,204 @@
> +/*
> + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann 
> + *
> + * This program is free software; you can redistribute it and/or modify it 
> under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static struct regmap_config mx25_tsadc_regmap_config = {
> + .fast_io = true,
> + .max_register = 8,
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static void mx25_tsadc_irq_handler(struct irq_desc *desc)
> +{
> + struct mx25_tsadc *tsadc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + u32 status;
> +
> + chained_irq_enter(chip, desc);
> +
> + regmap_read(tsadc->regs, MX25_TSC_TGSR, &status);
> +
> + if (status & MX25_TGSR_GCQ_INT)
> + generic_handle_irq(irq_find_mapping(tsadc->domain, 1));
> +
> + if (status & MX25_TGSR_TCQ_INT)
> + generic_handle_irq(irq_find_mapping(tsadc->domain,

Re: [PATCH 2/2] iio: health: Add driver for the TI AFE4404 heart monitor

[Jonathan Cameron]

On 10/11/15 19:19, Andrew F. Davis wrote:
> On 11/05/2015 01:09 PM, Jonathan Cameron wrote:
>> Lars, Hartmut, Peter,
>>
>> This is becoming a really involved ABI discussion so I'd like some
>> input on this if any of you have the time.
>>
>> I'm going to be busy now until at least the weekend...
>>
>> On 04/11/15 21:17, Andrew F. Davis wrote:
>>> On 11/04/2015 01:40 PM, Jonathan Cameron wrote:
>>>> On 02/11/15 20:37, Andrew F. Davis wrote:
>>>>> On 11/01/2015 02:52 PM, Jonathan Cameron wrote:
>>>>>> On 31/10/15 16:31, Andrew F. Davis wrote:
>>>>>>> Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
>>>>>>> This device detects reflected LED light fluctuations and presents an ADC
>>>>>>> value to the user space for further signal processing.
>>>>>>>
>>>>>>> Data sheet located here:
>>>>>>> http://www.ti.com/product/AFE4404/datasheet
>>>>>>>
>>>>>>> Signed-off-by: Andrew F. Davis 
>>>>>> Hi Andrew,
>>>>>>
>>>>>> Good to see this resurface.  It's a fascinating little device.
>>>>>>
>>>>>> Anyhow, most of the interesting bit in here is unsuprisingly concerned
>>>>>> with the interface.  I know we went round a few loops of this before but
>>>>>> it still feels like we haven't worked out to handle it well.  I would 
>>>>>> like
>>>>>> as much input as we can get on this as inevitablly it will have
>>>>>> repercussions outside this driver.
>>>>>>
>>>>>> Your approach of hammering out descriptive sysfs attributes is a good
>>>>>> starting point but we need to work towards a formal description that
>>>>>> can be generalised.  Whilst there are not many similar devices out there
>>>>>> to this one, I suspect there are a few and more may well show up in
>>>>>> future.
>>>>>>
>>>>>
>>>>> Yeah, I'm working on brining up drivers for them now :)
>>>> cool
>>>>>
>>>>>> The escence of my rather roundabout response inline is that I'm 
>>>>>> suggesting
>>>>>> adding a new channel type to represent light transmission, taking the 
>>>>>> analogous
>>>>>> case of proximity devices in which we are looking at light reflection.
>>>>>> I've also taken the justification we use for illuminance vs intensity 
>>>>>> readings
>>>>>> for two sensor ALS sensors as a precident for having compound channels 
>>>>>> of a different
>>>>>> type to the 'raw' data that feeds them.  Hence I propose something along
>>>>>> the lines of:
>>>>>>
>>>>>> in_intensityX_raw (raw channel value with the led on)
>>>>>> in_intensityX_ambient_raw (raw channel value with the led off)
>>>>>>
>>>>>
>>>>> I'm not sure, I know it may be too late for a lot of drivers but putting 
>>>>> the 'X'
>>>>> against the 'intensity' works for devices like ADCs/DACs with a simple 
>>>>> list
>>>>> of numeric channels, but for any other device with named channels this 
>>>>> will
>>>>> become very inconsistent, especially when adding modified channels and
>>>>> differential channels.
>>>> Sadly its ABI now so we can't realistically change it.  We can extend, we 
>>>> can't
>>>> replace (we we can over the course of a lot of years but that's a 
>>>> nightmare).
>>>>
>>>>>
>>>>> For example:
>>>>>
>>>>> in_intensity5_name_ambient-2_mean_raw
>>>> The oddity here is that in your case the device in interacting with a 
>>>> stimulus
>>>> output.  Normally the index reflects an actual sensor.  We are kind of 
>>>> bludgeoning
>>>> it in. The only equivalently nasty case I know of is touch screens where 
>>>> different
>>>> resistances are being connected - from a generic point of view those are a 
>>>> nightmare
>>>> as well (as every implementation does it differently).
>>>
>>> Yeah, this part really doesn't fit t

Re: [PATCH v6 2/2] iio: ti-ads8688: Add DT binding documentation

[Jonathan Cameron]

On 09/11/15 15:57, Rob Herring wrote:
> On Mon, Nov 09, 2015 at 01:53:00PM +0100, Sean Nyekjaer wrote:
>> Adding binding documentation for Texas Instruments ADS8688 ADC.
>>
>> Signed-off-by: Sean Nyekjaer 
>> Reviewed-by: Martin Hundebøll 
> 
> Acked-by: Rob Herring 
Applied to the togreg branch of iio.git - initially pushed out
as testing to let the autobuilders work their magic.

Thanks and thanks Rob for reviewing these bindings!

Jonathan
> 
>> ---
>> Changes since v2:
>> - Moved vref-supply to Optional properties
>>
>>  .../devicetree/bindings/iio/adc/ti-ads8688.txt   | 20 
>> 
>>  1 file changed, 20 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt 
>> b/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt
>> new file mode 100644
>> index 000..a02337d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt
>> @@ -0,0 +1,20 @@
>> +* Texas Instruments' ADS8684 and ADS8688 ADC chip
>> +
>> +Required properties:
>> + - compatible: Should be "ti,ads8684" or "ti,ads8688"
>> + - reg: spi chip select number for the device
>> +
>> +Recommended properties:
>> + - spi-max-frequency: Definition as per
>> +Documentation/devicetree/bindings/spi/spi-bus.txt
>> +
>> +Optional properties:
>> + - vref-supply: The regulator supply for ADC reference voltage
>> +
>> +Example:
>> +adc@0 {
>> +compatible = "ti,ads8688";
>> +reg = <0>;
>> +vref-supply = <&vdd_supply>;
>> +spi-max-frequency = <100>;
>> +};
>> -- 
>> 2.6.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] iio: st_sensors: support open drain mode

[Jonathan Cameron]

On 13/11/15 20:18, Linus Walleij wrote:
> Some types of ST Sensors can be connected to the same IRQ line
> as other peripherals using open drain. Add a device tree binding
> and a sensor data property to flip the right bit in the interrupt
> control register to enable open drain mode on the INT line.
> 
> If the line is set to be open drain, also tag on IRQF_SHARED
> to the IRQ flags when requesting the interrupt, as the whole
> point of using open drain interrupt lines is to share them with
> more than one peripheral (wire-or).
> 
> Cc: devicetree@vger.kernel.org
> Cc: Giuseppe Barba 
> Cc: Denis Ciocca 
> Signed-off-by: Linus Walleij 
As with the previous patch, looking for an ack / reviewed-by from
Denis and comments from Giuseppe on the parts added recently.

Otherwise, looks good to me!

Jonathan
> ---
>  Documentation/devicetree/bindings/iio/st-sensors.txt |  3 +++
>  drivers/iio/accel/st_accel_core.c|  8 
>  drivers/iio/common/st_sensors/st_sensors_core.c  | 20 
> 
>  drivers/iio/common/st_sensors/st_sensors_trigger.c   |  9 +
>  drivers/iio/gyro/st_gyro_core.c  | 12 
>  drivers/iio/pressure/st_pressure_core.c  |  8 
>  include/linux/iio/common/st_sensors.h|  6 ++
>  include/linux/platform_data/st_sensors_pdata.h   |  2 ++
>  8 files changed, 68 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt 
> b/Documentation/devicetree/bindings/iio/st-sensors.txt
> index d3ccdb190c53..4ac20cb2ae8d 100644
> --- a/Documentation/devicetree/bindings/iio/st-sensors.txt
> +++ b/Documentation/devicetree/bindings/iio/st-sensors.txt
> @@ -16,6 +16,9 @@ Optional properties:
>  - st,drdy-int-pin: the pin on the package that will be used to signal
>"data ready" (valid values: 1 or 2). This property is not configurable
>on all sensors.
> +- st,int-pin-open-drain: the interrupt/data ready line will be configured
> +  as open drain, which is useful if several sensors share the same
> +  interrupt line.
>  
>  Sensors may also have applicable pin control settings, those use the
>  standard bindings from pinctrl/pinctrl-bindings.txt.
> diff --git a/drivers/iio/accel/st_accel_core.c 
> b/drivers/iio/accel/st_accel_core.c
> index 1132224cbc10..888682b95693 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -96,6 +96,8 @@
>  #define ST_ACCEL_2_DRDY_IRQ_INT2_MASK0x10
>  #define ST_ACCEL_2_IHL_IRQ_ADDR  0x22
>  #define ST_ACCEL_2_IHL_IRQ_MASK  0x80
> +#define ST_ACCEL_2_OD_IRQ_ADDR   0x22
> +#define ST_ACCEL_2_OD_IRQ_MASK   0x40
>  #define ST_ACCEL_2_MULTIREAD_BIT true
>  
>  /* CUSTOM VALUES FOR SENSOR 3 */
> @@ -177,6 +179,8 @@
>  #define ST_ACCEL_5_DRDY_IRQ_INT2_MASK0x20
>  #define ST_ACCEL_5_IHL_IRQ_ADDR  0x22
>  #define ST_ACCEL_5_IHL_IRQ_MASK  0x80
> +#define ST_ACCEL_5_OD_IRQ_ADDR   0x22
> +#define ST_ACCEL_5_OD_IRQ_MASK   0x40
>  #define ST_ACCEL_5_IG1_EN_ADDR   0x21
>  #define ST_ACCEL_5_IG1_EN_MASK   0x08
>  #define ST_ACCEL_5_MULTIREAD_BIT false
> @@ -366,6 +370,8 @@ static const struct st_sensor_settings 
> st_accel_sensors_settings[] = {
>   .mask_int2 = ST_ACCEL_2_DRDY_IRQ_INT2_MASK,
>   .addr_ihl = ST_ACCEL_2_IHL_IRQ_ADDR,
>   .mask_ihl = ST_ACCEL_2_IHL_IRQ_MASK,
> + .addr_od = ST_ACCEL_2_OD_IRQ_ADDR,
> + .mask_od = ST_ACCEL_2_OD_IRQ_MASK,
>   },
>   .multi_read_bit = ST_ACCEL_2_MULTIREAD_BIT,
>   .bootime = 2,
> @@ -552,6 +558,8 @@ static const struct st_sensor_settings 
> st_accel_sensors_settings[] = {
>   .mask_int2 = ST_ACCEL_5_DRDY_IRQ_INT2_MASK,
>   .addr_ihl = ST_ACCEL_5_IHL_IRQ_ADDR,
>   .mask_ihl = ST_ACCEL_5_IHL_IRQ_MASK,
> + .addr_od = ST_ACCEL_5_OD_IRQ_ADDR,
> + .mask_od = ST_ACCEL_5_OD_IRQ_MASK,
>   },
>   .multi_read_bit = ST_ACCEL_5_MULTIREAD_BIT,
>   .bootime = 2, /* guess */
> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c 
> b/drivers/iio/common/st_sensors/st_sensors_core.c
> index ed6f54d5c932..bff469dd9583 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
> @@ -302,6 +302,14 @@ static int st_sensors_set_drdy_int_pin(struct iio_dev 
> *indio_dev,
>   return -EINVAL;
>   }
>  
> + if (pdata->open_drain) {
> + if (!sdata->sensor_settings->drdy_irq.addr_od)
> + dev_err(&indio_dev->dev,
> + "open drain re

Re: [PATCH v2 1/4] iio: adc: add IMX7D ADC driver support

[Jonathan Cameron]

On 13/11/15 09:52, Lars-Peter Clausen wrote:
> On 11/13/2015 10:39 AM, Haibo Chen wrote:
> [...]
 +static void imx7d_adc_feature_config(struct imx7d_adc *info)
 +{
 +  info->adc_feature.clk_pre_div = IMX7D_ADC_ANALOG_CLK_PRE_DIV_4;
 +  info->adc_feature.avg_num = IMX7D_ADC_AVERAGE_NUM_32;
 +  info->adc_feature.core_time_unit = 1;
 +  info->adc_feature.average_en = true;
>>>
>>> What's the plan for these? Right now they are always initialized to the same
>>> static value.
>>>
>>
>> In future, we can get these values from dts file, currently we just use the 
>> static value.
> 
> Those seem to be software configuration values though, not part of hardware
> description.
> 
>>
>>>
 +}
>>> [...]
 +static int imx7d_adc_read_raw(struct iio_dev *indio_dev,
 +  struct iio_chan_spec const *chan,
 +  int *val,
 +  int *val2,
 +  long mask)
 +{
 +  struct imx7d_adc *info = iio_priv(indio_dev);
 +
 +  u32 channel;
 +  long ret;
 +
 +  switch (mask) {
 +  case IIO_CHAN_INFO_RAW:
 +  mutex_lock(&indio_dev->mlock);
 +  reinit_completion(&info->completion);
 +
 +  channel = (chan->channel) & 0x0f;
 +  info->channel = channel;
 +  imx7d_adc_channel_set(info);
>>>
>>> How about just passing channel directy adc_channel_set() instead of doing it
>>> implicitly through the info struct?
>>>
>>
>> I think there is no difference, besides, using this parameter info struct 
>> can keep align with other functions.
>> eg.  imx7d_adc_sample_set(), imx7d_adc_hw_init(), 
>> imx7d_adc_get_sample_rate(), all these functions have the same parameter.
>>
>>> [...]
 +static irqreturn_t imx7d_adc_isr(int irq, void *dev_id)
 +{
 +  struct imx7d_adc *info = (struct imx7d_adc *)dev_id;
 +  int status;
 +
 +  status = readl(info->regs + IMX7D_REG_ADC_INT_STATUS);
 +  if (status & IMX7D_REG_ADC_INT_STATUS_CHANNEL_INT_STATUS) {
 +  info->value = imx7d_adc_read_data(info);
 +  complete(&info->completion);
 +  }
 +  writel(0, info->regs + IMX7D_REG_ADC_INT_STATUS);
>>>
>>> Is the hardware really this broken? If the interrupt happens between reading
>>> the status register and clearing it here it will be missed.
>>>
>>
>> I think interrupt can't happen between reading the status register and 
>> clearing it.
>> Because in function imx7d_adc_read_raw(), we call the function 
>> imx7d_adc_channel_set(info), in this function, we config the register
>> REG_ADC_CH_A\B\C\D_CFG1 and REG_ADC_CH_A\B\C\D_CFG2, only when these 
>> registers
>> is configed, ADC start a conversion. Once the conversion complete, ADC 
>> trigger an 
>> interrupt, and call the imx7d_adc_isr().
> 
> Well an interrupt can always happen, its running fully asynchronous to the
> CPU. If you have multiple interrupt sources enabled and the first one fires
> and you run then start the irq handler, read the status register, now the
> second irq sources fires, and then you clear the status interrupt register.
> This means the driver will not see the irq from the second source.
I'd agree with this, would normally expect to see only the relevant parts of the
register 'cleared'.  Usually this is done by explicitly picking those bits
out (normally writing 1 to the bit to clear the interrupt source).

If there is anything else of interest in that register this is nasty!

Hmm. looking at the bits you have defined and the way it is used you only
ever have one interrupt at a time possibly occurring at the moment?

If this is actually the case, then why read the register at all?

If there is anything in the other bits of that register it would be interesting 
to
know what is there!
> 
>>
 +
 +  return IRQ_HANDLED;
>>>
>>> You should only return IRQ_HANDLED if you actually handled are interrupt.
>>>
>>
>> Here in the interrupt, we just handle the channel conversion finished flag, 
>> for
>> other flag, ignore them this time, Will add other flag in future.
> 
> Yeah, but if you don't handle any interrupt you should return IRQ_NONE. This
> will make sure that the system can recover in case the hardware (or the
> driver) is broken and generates unexpected interrupts. If there are a 1000
> or so IRQ_NONEs in a row in a short time frame the kernel will disable the 
> IRQ.
> 
>>> [...]
 +  ret  = of_property_read_u32(pdev->dev.of_node,
>>>
>>> Extra space.
>>>
 +  "num-channels", &channels);
>>>
>>> What decides how many channels are in use?
>>>
>>
>> The board decides the channel number.
>> In dts file, there is a line: num-channels = <4>;
> 
> Yes, but what decides how this property should be configured?
> 
>>
>>
 +  if (ret)
 +  channels = ARRAY_SIZE(imx7d_adc_iio_channels);
 +
 +  indio_dev->name = dev_name(&pdev->dev);
 +  indio_dev->dev.parent = &pdev->dev;
 +

Re: [PATCH v2 1/4] iio: adc: add IMX7D ADC driver support

[Jonathan Cameron]

On 09/11/15 13:28, Haibo Chen wrote:
> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
> driver support, and the driver only support ADC software trigger.
> 
> Signed-off-by: Haibo Chen 
Hi Haibo,

A few comments inline in addition to Lars' ones.

One small point is that whilst the 80 char limit
should be ignored when obeying it significantly hurts readability, there
are cases in here where it wouldn't hurt to keep the lines shorter, so that
would be preferred.

Mostly looking good.

Jonathan
> ---
>  drivers/iio/adc/Kconfig |   9 +
>  drivers/iio/adc/Makefile|   1 +
>  drivers/iio/adc/imx7d_adc.c | 571 
> 
>  3 files changed, 581 insertions(+)
>  create mode 100644 drivers/iio/adc/imx7d_adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7868c74..bf0611c 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -194,6 +194,15 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>  
> +config IMX7D_ADC
> + tristate "IMX7D ADC driver"
> + depends on OF
> + help
> +   Say yes here to build support for IMX7D ADC.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called imx7d_adc.
> +
>  config LP8788_ADC
>   tristate "LP8788 ADC driver"
>   depends on MFD_LP8788
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 99b37a9..282ffc01 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1027) += max1027.o
>  obj-$(CONFIG_MAX1363) += max1363.o
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> new file mode 100644
> index 000..7e25e4e
> --- /dev/null
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -0,0 +1,571 @@
> +/*
> + * Freescale i.MX7D ADC driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/* This will be the driver name the kernel reports */
> +#define DRIVER_NAME "imx7d_adc"
It's only used in one place so don't bother with the define.
Use the string inline and it's immediately obvious what it
is for without the comment.

> +
> +/* ADC register */
> +#define IMX7D_REG_ADC_CH_A_CFG1  0x00
> +#define IMX7D_REG_ADC_CH_A_CFG2  0x10
> +#define IMX7D_REG_ADC_CH_B_CFG1  0x20
> +#define IMX7D_REG_ADC_CH_B_CFG2  0x30
> +#define IMX7D_REG_ADC_CH_C_CFG1  0x40
> +#define IMX7D_REG_ADC_CH_C_CFG2  0x50
> +#define IMX7D_REG_ADC_CH_D_CFG1  0x60
> +#define IMX7D_REG_ADC_CH_D_CFG2  0x70
> +#define IMX7D_REG_ADC_CH_SW_CFG  0x80
> +#define IMX7D_REG_ADC_TIMER_UNIT 0x90
> +#define IMX7D_REG_ADC_DMA_FIFO   0xa0
> +#define IMX7D_REG_ADC_FIFO_STATUS0xb0
> +#define IMX7D_REG_ADC_INT_SIG_EN 0xc0
> +#define IMX7D_REG_ADC_INT_EN 0xd0
> +#define IMX7D_REG_ADC_INT_STATUS 0xe0
> +#define IMX7D_REG_ADC_CHA_B_CNV_RSLT 0xf0
> +#define IMX7D_REG_ADC_CHC_D_CNV_RSLT 0x100
> +#define IMX7D_REG_ADC_CH_SW_CNV_RSLT 0x110
> +#define IMX7D_REG_ADC_DMA_FIFO_DAT   0x120
> +#define IMX7D_REG_ADC_ADC_CFG0x130
> +
> +#define IMX7D_EACH_CHANNEL_REG_SHIF  0x20
> +
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_EN (0x1 << 31)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_DISABLE(0x0 << 
> 31)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SINGLE BIT(30)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_AVG_EN BIT(29)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SEL_SHIF   24
> +
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_4  (0x0 << 
> 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_8  (0x1 << 
> 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_16 (0x2 << 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_32 (0x3 << 12)
> +
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_4  

Re: IIO device indexing issue

[Jonathan Cameron]

On 04/11/15 18:53, Vesa Jääskeläinen wrote:
> On 04/11/15 11:38, Lars-Peter Clausen wrote:
>> On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
>>> Hi,
>>>
>>> When we were using kernel 3.2 and with that board files we just got IIO
>>> devices with static order so that we knew exactly what iio:device0 is.
>>>
>>> Now with device tree that order is not so static anymore especially when
>>> using device overlays (have not yet tried that thou). If there would be
>>> deferred probe for the device then if we have multiple iio:device's then
>>> those could in theory be in any order.
>>>
>>> In example libiio uses iio device index to open the IIO device. So the
>>> problem is to know what iio:device is what.
>>>
>>> If we look files under /sys/bus/iio/iio:deviceX. They do not reveal what
>>> device this is (especially if there are multiple device of same type). There
>>> does not seem to be a way to give custom name for the iio device from device
>>> tree that could have been used as a cue.
>>>
>>> Device tree aliases kinda sounded a good idea to try. Eg. define adc0 alias
>>> and then link it to actual device node in tree.
>>>
>>> Aliases could be found under /proc/device-tree/aliases. Looking at it shows
>>> what device tree node it is. However there does not seem to be actual link
>>> from any /proc/device-tree entries to kernel drivers exposed under sysfs.
>>> And even the path components in device tree are not in same format as in
>>> sysfs. So there is no 1:1 mapping possible here.
>>>
>>> IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
>>> devices under /sys/devices and from there is physical path to the device and
>>> under that the IIO device with the same name as is under /sys/bus/iio.
>>>
>>> So in theory we could make a mapping configuration file that specifies
>>> logical name for iio device and then physical parent path for the device and
>>> then find under it iio:device* files to determine what is the iio device
>>> index for this physical device. Then open IIO device with that index in
>>> example with libiio. Sounds a bit complex?
>>>
>>> So did we miss something on how this should be defined/accessed or is there
>>> a slight issue here on how to identify iio devices?
>>>
>>> Don't know how device tree overlays affect this if we first load device tree
>>> overlay with some configuration and then unload it and load another one with
>>> different configuration.
>> Hi,
>>
>> Yes, excellent analysis. This is a real issue. As you said there is no
>> guarantee that the IIO device numbers are stable, they are assigned in the
>> order the devices are registered. If the device are registered in a
>> different order for whatever reason the numbers will change. You can use
>> readlink on the IIO device in /sys/bus/iio/devices to get its position in
>> the global device topology and be able to tell what the parent device is,
>> but this path might not be completely stable either though. E.g. if your
>> device is on a I2C bus and the number of the I2C bus is dynamically assigned
>> it might change when the probe order changes.
>>
>> Alias seem to be one way to solve this issue. The big question remains is
>> how to communicate the alias to userspace. For other device classes the
>> alias index is used as the device index e.g. a device with alias i2c0 ends
>> up being the i2c adapter with index 0. But with IIO where we support a wide
>> range of different devices that does not really work. E.g. what to do if you
>> have adc0 and dac0 as aliases for different devices. So you'd need a
>> different way to expose the alias.
>>
>> Some bindings also use the "label" property to assign a unique name to node.
>> But again the same issue how to expose that information to applications.
>>
> To continue from this "label" property idea I was wondering if we
> would add it as new optional(?) file node for IIO devices.> 
> One could then specify it like:
> 
> tscadc: tscadc@44e0d000 {
> compatible = "ti,am3359-tscadc";
> ...
> am335x_adc: adc {
> compatible = "ti,am3359-adc";
> ...
> label = "Port A";
> };
> };
> 
> And this would generate file /sys/bus/iio/iio:deviceX/label with
> contents of "Port A".
> 
> Then during the application startup it would just need to scan all
> devices under /sys/bus/iio and determine what labelled device it
> wants to use.
> 
> It would be up to device's developer to determine what labels to use
> in their designs. This would not break ABI and would be just an
> extension for it.
> 
> One could also auto-assign label "am335x_adc" in this case too. But
> if you include existing arch device tree then changing label in top
> level is kinda a bit annoying as you would then need to duplicate all
> properties with another label and disable arch device tree's
> settings. Could cause also conflict if there are references elsewhere
> to existing arch nodes.
> 
> Having following in device's device tree file would allow one to
> override label or just 

Re: [PATCH 2/2] iio: health: Add driver for the TI AFE4404 heart monitor

[Jonathan Cameron]

Lars, Hartmut, Peter,

This is becoming a really involved ABI discussion so I'd like some
input on this if any of you have the time.

I'm going to be busy now until at least the weekend...

On 04/11/15 21:17, Andrew F. Davis wrote:
> On 11/04/2015 01:40 PM, Jonathan Cameron wrote:
>> On 02/11/15 20:37, Andrew F. Davis wrote:
>>> On 11/01/2015 02:52 PM, Jonathan Cameron wrote:
>>>> On 31/10/15 16:31, Andrew F. Davis wrote:
>>>>> Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
>>>>> This device detects reflected LED light fluctuations and presents an ADC
>>>>> value to the user space for further signal processing.
>>>>>
>>>>> Data sheet located here:
>>>>> http://www.ti.com/product/AFE4404/datasheet
>>>>>
>>>>> Signed-off-by: Andrew F. Davis 
>>>> Hi Andrew,
>>>>
>>>> Good to see this resurface.  It's a fascinating little device.
>>>>
>>>> Anyhow, most of the interesting bit in here is unsuprisingly concerned
>>>> with the interface.  I know we went round a few loops of this before but
>>>> it still feels like we haven't worked out to handle it well.  I would like
>>>> as much input as we can get on this as inevitablly it will have
>>>> repercussions outside this driver.
>>>>
>>>> Your approach of hammering out descriptive sysfs attributes is a good
>>>> starting point but we need to work towards a formal description that
>>>> can be generalised.  Whilst there are not many similar devices out there
>>>> to this one, I suspect there are a few and more may well show up in
>>>> future.
>>>>
>>>
>>> Yeah, I'm working on brining up drivers for them now :)
>> cool
>>>
>>>> The escence of my rather roundabout response inline is that I'm suggesting
>>>> adding a new channel type to represent light transmission, taking the 
>>>> analogous
>>>> case of proximity devices in which we are looking at light reflection.
>>>> I've also taken the justification we use for illuminance vs intensity 
>>>> readings
>>>> for two sensor ALS sensors as a precident for having compound channels of 
>>>> a different
>>>> type to the 'raw' data that feeds them.  Hence I propose something along
>>>> the lines of:
>>>>
>>>> in_intensityX_raw (raw channel value with the led on)
>>>> in_intensityX_ambient_raw (raw channel value with the led off)
>>>>
>>>
>>> I'm not sure, I know it may be too late for a lot of drivers but putting 
>>> the 'X'
>>> against the 'intensity' works for devices like ADCs/DACs with a simple list
>>> of numeric channels, but for any other device with named channels this will
>>> become very inconsistent, especially when adding modified channels and
>>> differential channels.
>> Sadly its ABI now so we can't realistically change it.  We can extend, we 
>> can't
>> replace (we we can over the course of a lot of years but that's a nightmare).
>>
>>>
>>> For example:
>>>
>>> in_intensity5_name_ambient-2_mean_raw
>> The oddity here is that in your case the device in interacting with a 
>> stimulus
>> output.  Normally the index reflects an actual sensor.  We are kind of 
>> bludgeoning
>> it in. The only equivalently nasty case I know of is touch screens where 
>> different
>> resistances are being connected - from a generic point of view those are a 
>> nightmare
>> as well (as every implementation does it differently).
> 
> Yeah, this part really doesn't fit the mold for this subsystem, or
> any really, hwmon, input, were also considered, but the plan is still
> to attempt to shoehorn it in to this one, so hopefully you can bear with me
> on all these oddities :)
Much as it irritates my sense of neat and tidy I guess that if we do end up with
an ABI for this that we don't like later it isn't the end of the world as I 
doubt
we'll be inundated with hundreds of these sensors.

However, lets keep the naming within reason to how we would naturally extend
the ABI.  

Having thought more on these differential channels, do we really need to have
them explicitly as differential channels at all?  Perhaps we are better off with

in_intensity0_led1_raw
in_intensity1_ambient_raw
in_intensity2_transmitted_led1_raw

in_intensity3_led2_raw
in_intensity4_ambient_raw
in_intensity5_transm

Re: [PATCH 2/2] iio: health: Add driver for the TI AFE4404 heart monitor

[Jonathan Cameron]

On 02/11/15 20:37, Andrew F. Davis wrote:
> On 11/01/2015 02:52 PM, Jonathan Cameron wrote:
>> On 31/10/15 16:31, Andrew F. Davis wrote:
>>> Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
>>> This device detects reflected LED light fluctuations and presents an ADC
>>> value to the user space for further signal processing.
>>>
>>> Data sheet located here:
>>> http://www.ti.com/product/AFE4404/datasheet
>>>
>>> Signed-off-by: Andrew F. Davis 
>> Hi Andrew,
>>
>> Good to see this resurface.  It's a fascinating little device.
>>
>> Anyhow, most of the interesting bit in here is unsuprisingly concerned
>> with the interface.  I know we went round a few loops of this before but
>> it still feels like we haven't worked out to handle it well.  I would like
>> as much input as we can get on this as inevitablly it will have
>> repercussions outside this driver.
>>
>> Your approach of hammering out descriptive sysfs attributes is a good
>> starting point but we need to work towards a formal description that
>> can be generalised.  Whilst there are not many similar devices out there
>> to this one, I suspect there are a few and more may well show up in
>> future.
>>
> 
> Yeah, I'm working on brining up drivers for them now :)
cool
> 
>> The escence of my rather roundabout response inline is that I'm suggesting
>> adding a new channel type to represent light transmission, taking the 
>> analogous
>> case of proximity devices in which we are looking at light reflection.
>> I've also taken the justification we use for illuminance vs intensity 
>> readings
>> for two sensor ALS sensors as a precident for having compound channels of a 
>> different
>> type to the 'raw' data that feeds them.  Hence I propose something along
>> the lines of:
>>
>> in_intensityX_raw (raw channel value with the led on)
>> in_intensityX_ambient_raw (raw channel value with the led off)
>>
> 
> I'm not sure, I know it may be too late for a lot of drivers but putting the 
> 'X'
> against the 'intensity' works for devices like ADCs/DACs with a simple list
> of numeric channels, but for any other device with named channels this will
> become very inconsistent, especially when adding modified channels and
> differential channels.
Sadly its ABI now so we can't realistically change it.  We can extend, we can't
replace (we we can over the course of a lot of years but that's a nightmare).

> 
> For example:
> 
> in_intensity5_name_ambient-2_mean_raw
The oddity here is that in your case the device in interacting with a stimulus
output.  Normally the index reflects an actual sensor.  We are kind of 
bludgeoning
it in. The only equivalently nasty case I know of is touch screens where 
different
resistances are being connected - from a generic point of view those are a 
nightmare
as well (as every implementation does it differently).
> 
> This is the differential of name and an unnamed channel '2', also something
> is an average, is it channel '2', is it the whole differential channel? Is
> 5 this channels id or part of the first differential channel name? Who knows!
> 
> The way I would do it is with this more universal format:
> 
> [direction]_[type]_[name|number]_[info]
Hind sight is a great thing in that the extra _ would have made parsing 
marginally
easier.
> 
> 
> And then we just drop trying to deal with modifiers and differential stuff
> internally, just let the driver give the channel a name with those. We then
> wouldn't need to deal with channels numbers ether, just names.
See my reply to the cover letter thread.  You can't pass a name in an event
to userspace and we'd end up string matching all over the place or you end
up not encoding the information currently in the modifier at all.  

Perhaps you are right in that it would still have been neater but such is hind 
sight!

The one I wonder about occasionally is similar to what you suggest, but don't
ever having anything other than number (and I'd keep the differential channels.
Then have an extra sysfs attribute that provides the modifier string.

Then I'm not sure it gains us much.
Also note that in the classic ADC case (and there are a whole load more
of those than weird light sensors ;) there are only indexes and differential 
channels
so it all becomes rather cleaner.

in_voltage0-1_raw 

It's also worth noting that whilst we do allow freeform extend_name elements
they are very rarely accepted in drivers as the moment you do that you have
something that standard userspace code won't know what to do 

Re: [PATCH 0/2] iio: Heart Rate Monitors

[Jonathan Cameron]

On 02/11/15 16:31, Andrew F. Davis wrote:
> On 11/01/2015 12:35 PM, Jonathan Cameron wrote:
>> On 31/10/15 16:31, Andrew F. Davis wrote:
>>> Hello all,
>>>
>>> This series adds the TI AFE4404 "Ultra-small, Integrated AFE for
>>> Wearable, Optical Heart Rate Monitoring and Bio-Sensing".
>>>
>>> This work is based on previous work by Dan Murphy [0] who is working
>>> on other tasks at the moment, so I will be helping to continue
>>> upstreaming this driver. This is more of a re-write than a continuation
>>> and there are many changes so I am submitting this as a v1.
>>>
>>> This device is very similar to the AFE4403 and I was originally planning
>>> on pushing the two drivers together with common core functions in a
>>> third file. The AFE4403 driver is still being tested so I merged common
>>> code back into this driver, this is why this driver may seem a bit
>>> unnecessarily modular. I will probably split this stuff back out when
>>> I push the AFE4403.
>>>
>>> I also had some issues with sysfs naming for the channels; this device
>>> has three input channels from three LED stages and two ambient
>>> channels based on the LED stages. This might have been be a good place
>>> for using IIO modifiers[1], but we also have two differential channels
>>> based on the ambient channels, and channels cannot have both modifiers
>>> and be differential (the modifier is stored in the differential channel's
>>> ID field?).
>> True enough. Didn't expect to run into this particular problem, but I guess
>> someone will always make hardware breaking any assumptions we make from the
>> software side of things.
> 
> Seems that way, it probably would work to have modified be more that a single
> bit flag, maybe call it modifier and just store the modifier in there. Doesn't
> look like it would be that hard right now to fix.
As I stated below the issue is then to figure out how to get it into the event
codes without breaking backwards compatibility.  It could probably be done but 
would
involve something hideous like a bit for this event is on a channel that is both
differential and modified.  Then we need to potentially sneak into the code
2 modifiers, 2 indexes and a bit saying to use them all.  

This is rapidly getting to some very long naming to avoid simply saying what
the channel is in reality which is a measure of light transmission.  I'm kind
of thinking that information is more useful to userspace than ending up with
something along the lines of

in_intensity0_lit-intensity0_ambient_raw

it's worth noting for the discussion below that if you didn't have modifiers
you'd need to index those two channels separately as the event codes that
might be generated can't have strings burried in them.  So you'd have
the even more cyptic.

in_intensity0_lit-in_intensity1_ambient_raw
(or if you dropped the extra string from these attributes simply
in_intensity0-intensity1_raw
vs
in_intensitytransmitted0_raw
>  
> I'm not really sure I understand the need for modifiers at all really, seems
> most are used by a single driver to get around just naming the channel.
In a sense they do serve that purpose, but their primary purpose is to provide
a short hand lookup for common elements that 'identify' a channel.
These get used in a couple of places in particular:
1) Event codes - now we could have insisted that any process using events holds
sufficient state to allow it to identify the channel purely based on type and 
index
but instead decided that the vast majority of cases where there is a reason to
map to a unique identifier are straight forward (e.g. an axis for multi axis
sensors).  If anyone needs to still do a more detailed lookup to identify the 
source
of an event they still can (effectively nothing is lost)

2) In kernel mappings - consumers of IIO channels could in theory do a name look
up if it was all string based, but then all we've done is pushed the problem on
one step and have to maintain copies of the magic string mapping that says 
'This is an x axis'.

Hwmon basically only ever uses string based naming (as it just has sysfs 
attributes
instantiated by every driver from scratch).  It works for that case, but has 
caused
a lot of grief when people try for example to base a thermal driver on top
of hwmon. Obviously this doesn't precisely map given the nature of hwmon 
channels
is typically simpler and they are almost always accompanied by a userspace 
mapping
in lm-sensors that identifies what they are wired to on a particular board.

Input goes right the otherway and more or less provides no naming based stuff 
at all
instead mapping to a set of big enums to identify t

Re: [PATCH 2/2] iio: health: Add driver for the TI AFE4404 heart monitor

[Jonathan Cameron]

On 31/10/15 16:31, Andrew F. Davis wrote:
> Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
> This device detects reflected LED light fluctuations and presents an ADC
> value to the user space for further signal processing.
> 
> Data sheet located here:
> http://www.ti.com/product/AFE4404/datasheet
> 
> Signed-off-by: Andrew F. Davis 
Hi Andrew,

Good to see this resurface.  It's a fascinating little device.

Anyhow, most of the interesting bit in here is unsuprisingly concerned
with the interface.  I know we went round a few loops of this before but
it still feels like we haven't worked out to handle it well.  I would like
as much input as we can get on this as inevitablly it will have
repercussions outside this driver.

Your approach of hammering out descriptive sysfs attributes is a good
starting point but we need to work towards a formal description that
can be generalised.  Whilst there are not many similar devices out there
to this one, I suspect there are a few and more may well show up in
future.

The escence of my rather roundabout response inline is that I'm suggesting
adding a new channel type to represent light transmission, taking the analogous
case of proximity devices in which we are looking at light reflection.
I've also taken the justification we use for illuminance vs intensity readings
for two sensor ALS sensors as a precident for having compound channels of a 
different
type to the 'raw' data that feeds them.  Hence I propose something along
the lines of:

in_intensityX_raw (raw channel value with the led on)
in_intensityX_ambient_raw (raw channel value with the led off)

in_intensitytransmittedX_raw the differential signal which is actually just
measuring the proportion of light that got through the finger or similar.
(other naming suggestions welcome!)

Lots more detail inline, but I wanted anyone at a quick glance to know
what we are discussing.  Perhaps my suggestion is bonkers so feel free
to pick it to shreds.

The average channels are also unusual to handle.  When would a user
want to get both the average and non average channel via the triggered
buffer?   I propose that we might handle these generically by treating
the averaging process as a filter and extending the filter interface to
describe it.

I also do feel that the modularity you have driven for to support your
other part has perhaps come at the expense of some false complexity
(I think there are easier to follow ways of keeping thing modular without
 as many duplicate copies of pointers as you pass around here).
 
Jonathan

p.s. Seemed like a good idea to look at this on a Sunday evening
to avoid some truely terrible TV...  Now for the TV I think!
> ---
>  .../ABI/testing/sysfs-bus-iio-health-afe4404   |  70 +++
>  drivers/iio/Kconfig|   1 +
>  drivers/iio/Makefile   |   1 +
>  drivers/iio/health/Kconfig |  24 +
>  drivers/iio/health/Makefile|   6 +
>  drivers/iio/health/afe4404.c   | 526 
> +
>  drivers/iio/health/afe440x.h   | 159 +++
>  7 files changed, 787 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
>  create mode 100644 drivers/iio/health/Kconfig
>  create mode 100644 drivers/iio/health/Makefile
>  create mode 100644 drivers/iio/health/afe4404.c
>  create mode 100644 drivers/iio/health/afe440x.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404 
> b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
> new file mode 100644
> index 000..c67748b
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
> @@ -0,0 +1,70 @@
> +What:/sys/bus/iio/devices/iio:deviceX/out_resistanceY_tia_raw
> + /sys/bus/iio/devices/iio:deviceX/out_capacitanceY_tia_raw
> +Date:October 2015
> +KernelVersion:
> +Contact: Andrew F. Davis 
> +Description:
> + Get and set the resistance and the capacitance settings for the
> + Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
> + Rf2 and Cf2 values.
> + Resistance setting is from 0 -> 7
> + Capcitance setting is from 0 -> 15
These are defined types, so need to be in the relevant defined base units.
I know it is a pain to map real world values directly to the driver units
but if it actually makes sense to expose these to userspace they need to
defined in the same units as every other element of that type is - so
if you don't provide a scale for the 'channels' then it should be
nanofarads and ohms.

Could be handled as an output channel internaly with and extended_name -
this sort of internally handled value is exactly what
the extended_name stuff is meant to be used to identify.

These are really controlling a front end analog filter, so another option would
be to use the filter description

Re: [PATCH 0/2] iio: Heart Rate Monitors

[Jonathan Cameron]

On 31/10/15 16:31, Andrew F. Davis wrote:
> Hello all,
> 
> This series adds the TI AFE4404 "Ultra-small, Integrated AFE for
> Wearable, Optical Heart Rate Monitoring and Bio-Sensing".
> 
> This work is based on previous work by Dan Murphy [0] who is working
> on other tasks at the moment, so I will be helping to continue
> upstreaming this driver. This is more of a re-write than a continuation
> and there are many changes so I am submitting this as a v1.
> 
> This device is very similar to the AFE4403 and I was originally planning
> on pushing the two drivers together with common core functions in a
> third file. The AFE4403 driver is still being tested so I merged common
> code back into this driver, this is why this driver may seem a bit
> unnecessarily modular. I will probably split this stuff back out when
> I push the AFE4403.
> 
> I also had some issues with sysfs naming for the channels; this device
> has three input channels from three LED stages and two ambient
> channels based on the LED stages. This might have been be a good place
> for using IIO modifiers[1], but we also have two differential channels
> based on the ambient channels, and channels cannot have both modifiers
> and be differential (the modifier is stored in the differential channel's
> ID field?).
True enough. Didn't expect to run into this particular problem, but I guess
someone will always make hardware breaking any assumptions we make from the
software side of things.
 So I used sysfs names that would be close to what they
> would be if IIO supported these things.
Fair enough as a starting point though we probably want to figure out how
to do this 'right'.   Adding an extra field to the channel descriptor will
be easy enough - it'll be event codes that are nasty to handle.

Jonathan
> 
> [0] http://www.spinics.net/lists/linux-iio/msg18413.html
> [1] IIO_MOD_TEMP_AMBIENT could be renamed IIO_MOD_AMBIENT as it can
> also apply to LIGHT, PRESSURE, HUMIDITY, etc..
No problem with this change so please send a patch.
> 
> Thanks,
> Andrew
> 
> Andrew F. Davis (2):
>   Documentation: afe4404: Add DT bindings for the AFE4404 heart monitor
>   iio: health: Add driver for the TI AFE4404 heart monitor
> 
>  .../ABI/testing/sysfs-bus-iio-health-afe4404   |  70 +++
>  .../devicetree/bindings/iio/health/afe4404.txt |  27 ++
>  drivers/iio/Kconfig|   1 +
>  drivers/iio/Makefile   |   1 +
>  drivers/iio/health/Kconfig |  24 +
>  drivers/iio/health/Makefile|   6 +
>  drivers/iio/health/afe4404.c   | 526 
> +
>  drivers/iio/health/afe440x.h   | 159 +++
>  8 files changed, 814 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
>  create mode 100644 Documentation/devicetree/bindings/iio/health/afe4404.txt
>  create mode 100644 drivers/iio/health/Kconfig
>  create mode 100644 drivers/iio/health/Makefile
>  create mode 100644 drivers/iio/health/afe4404.c
>  create mode 100644 drivers/iio/health/afe440x.h
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation

[Jonathan Cameron]

On 27/10/15 16:13, Linus Walleij wrote:
> On Sun, Oct 25, 2015 at 2:31 PM, Jonathan Cameron  wrote:
>> On 13/10/15 10:37, Paul Cercueil wrote:
>>> Signed-off-by: Paul Cercueil 
>> Looks good to me, but as it is a little bit 'different' and we are
>> defining entirely new generic bindings (the channel modes stuff)
>> I would like some more input.  It might be overkill but we do
>> of course have the pinctl framework which covers this sort of
>> thing... Might be worth considering if using that to get the unified
>> bindings might make sense here...
>>
>> cc'd Linus in case he wants to comment on this.
>>
>> It would obviously be a very heavy weight solution to the problem
>> so I'm far from convinced it makes sense - or even fits the usecase
>> terrible well.  Just thought I'd mention the possibility.
> 
> There is something of a grey area between "definately pin control"
> and "some extra pin hardware duct-taped to something else".
> 
> I guess that is natural, life is full of grey areas...
> 
> Basically if there are plenty of pins and functions, local solutions
> to the problem will not scale. Then it is necessary to go ahead
> and implement full pin control. Especially for say a big BGA
> package or so with lots and lots of pins.
> 
> It is is a few pins or they just alter between similar functionality
> (like different graphic modes) I think local solutions are OK.
Thanks Linus.  Makes sense

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] devicetree: mfd: Add binding for the TI LM3533

[Jonathan Cameron]

On 30/10/15 23:50, Bjorn Andersson wrote:
> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
> 
> Signed-off-by: Bjorn Andersson 
For the ALS bits.  It does feel like the als resistance might become
a generic parameter in the long term, but it's not common enough to
conclude that now.

Acked-by: Jonathan Cameron 
> ---
> 
> Changes since v2:
> - Drop vendor prefix of vendor properties
> - Specify unit of various properties
> - Fix reference paths
> 
> Changes since v1:
> - Added unit to boost-freq and als-resistance (as the frequency now comes with
>   a unit specifier I changed it to be expressed in kHz)
> 
>  Documentation/devicetree/bindings/mfd/lm3533.txt | 184 
> +++
>  1 file changed, 184 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt 
> b/Documentation/devicetree/bindings/mfd/lm3533.txt
> new file mode 100644
> index ..963cee153a4d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
> @@ -0,0 +1,184 @@
> +Texas Instruments LM3533 binding
> +
> +This binding describes the Texas Instruments LM3533, a lighting power 
> solution
> +for smartphone handsets. The common properties are described directly in the
> +node, while each individual component are described in an optional subnode.
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be:
> + "ti,lm3533"
> +
> +- reg:
> + Usage: required
> + Value type: 
> + Definition: i2c address of the LM3533 chip
> +
> +- als-supply:
> + Usage: optional
> + Value type: 
> + Definition: reference to regulator powering the V_als input; as
> + specified in "../regulator/regulator.txt"
> +
> +- hwen-gpios:
> + Usage: required
> + Value type: 
> + Definition: reference to gpio pin connected to the HWEN input; as
> + specified in "../gpio/gpio.txt"
> +
> +- ti,boost-freq-hz:
> + Usage: required
> + Value type: 
> + Definition: switch-frequency of the boost converter, must be either:
> + 50 or 100
> +
> +- ti,boost-ovp-mv:
> + Usage: required
> + Value type: 
> + Definition: over-voltage protection limit, in mV. Must be one of:
> + 16000, 24000, 32000 or 4
> +
> +- #address-cells:
> + Usage: required
> + Value type: 
> + Definition: must be 1
> +
> +- #size-cells:
> + Usage: required
> + Value type: 
> + Definition: must be 0
> +
> += ALS SUBNODE
> +The ambient light sensor subnode must be named "als", it carries the light
> +sensor related properties.
> +
> +- ti,als-resistance-ohm:
> + Usage: required (unless ti,pwm-mode is specified)
> + Value type: 
> + Definition: specifies the resistor value (R_als), in Ohm. Valid values
> + ranges from 20 to 1574 Ohm.
> +
> +- ti,pwm-mode:
> + Usage: optional
> + Value type: 
> + Definition: specifies, if present, that the als should operate in PWM
> + mode - rather than analog mode
> +
> += BACKLIGHT NODES
> +Backlight subnodes must be named "backlight", they carry the backlight 
> related
> +properties.
> +
> +- reg:
> + Usage: required
> + Value type: 
> + Definition: specifies which of the two backlights this node corresponds
> + to
> +
> +- default-brightness:
> + Usage: optional
> + Value type: <32>
> + Definition: specifies the default brightness for the backlight, in
> + units of brightness [0-255]
> +
> +- label:
> + Usage: required
> + Value type: 
> + Definition: specifies a name of this backlight
> +
> +- led-max-microamp:
> + Usage: required
> + Value type: 
> + Definition: specifies the max current for this backlight, in uA, as
> + described in "../leds/common.txt"
> +
> +- ti,pwm-zones:
> + Usage: optional
> + Value type: 
> + Definition: lists the ALS zones to be PWM controlled for this backlight,
> + the values in the list are in the range [0 - 4]
> +
> += LED NODES
> +LED subnodes must be named "led", they carry the LED related properties.
> +
> +- reg:
> + Usage: required
> + Value type: 
> + Definition: specifies which of the four LEDs this node corresponds to
> +
> +- linux,default-trigger:
> + Usage: optional
> + Value type:

Re: [PATCH v4 1/2] iio: adc: Add TI ADS8688

[Jonathan Cameron]

On 13/10/15 10:46, Sean Nyekjær wrote:
> Hi
> 
> I'm having a problems with the ads8688_write_raw_get_fmt function.
> 
> Firstly the OFFSET and the SCALE its switched around. Ill fix that :-)
> Secondly the i'm not allowed to return IIO_VAL_INT, this results in the
> iio_write_channel_info() is returning -EINVAL. The iio_write_channel_info() 
> only checks if the write_raw_get_fmt is existing...
> Do I need to convert the OFFSET to a IIO_VAL_INT_PLUS_NANO aswell or ?
Nope. The core needs extending to actually support IIO_VAL_INT.  Though 
cynically
setting it to IIO_VAL_INT_PLUS_MICRO and checking the val2 is 0 would work
as well if you want a quick solution.

Adding IIO_VAL_INT support should be fairly straightforward, though I'd
bypass the string to fixedpoint convertor in this case and do it with an
scanf.  


> 
> /Sean
> 
> On 2015-10-11 16:53, Jonathan Cameron wrote:
>> On 06/10/15 09:12, Sean Nyekjaer wrote:
>>> This patch adds support for the Texas Intruments ADS8688 ADC.
>>>
>>> Signed-off-by: Sean Nyekjaer 
>>> Reviewed-by: Martin Hundebøll 
>> only one issue that I can see.  You do need locking to protect
>> your local buffers.  A local lock in the same structure would be
>> appropriate for this.
>>
>> Neither sysfs nor IIO provide any serialization guarantees
>> so multiple concurrent reads are more than possible and may
>> cause you data corruption as it stands.
>>
>> Other than that, it's looking very nice.
>>
>> Thanks,
>>
>> Jonathan
>>> ---
>>> Changes since v3:
>>> - fixed multiline comments
>>> - write_raw_get_fmt _SCALE is nano, _OFFSET is int
>>>
>>> Changes since v2:
>>> - Removed unused variables
>>> - Removed unnecessary mutex lock
>>> - Range array is a enum
>>> - Made the read and write functions less complex and easier to read
>>> - Added inline comments
>>> - Added callback to write_raw_get_fmt
>>>
>>> Changes since v1:
>>> - Now possible to read and write the actual offset and scale values
>>> - Removed unused includes
>>> - Removed unused buffer references
>>>   drivers/iio/adc/Kconfig  |  10 +
>>>   drivers/iio/adc/Makefile |   1 +
>>>   drivers/iio/adc/ti-ads8688.c | 472 
>>> +++
>>>   3 files changed, 483 insertions(+)
>>>   create mode 100644 drivers/iio/adc/ti-ads8688.c
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 7868c74..4135d17 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -333,6 +333,16 @@ config TI_ADC128S052
>>> This driver can also be built as a module. If so, the module will be
>>> called ti-adc128s052.
>>>   +config TI_ADS8688
>>> +tristate "Texas Instruments ADS8688"
>>> +depends on SPI && OF
>>> +help
>>> +  If you say yes here you get support for Texas Instruments ADS8684 and
>>> +  and ADS8688 ADC chips
>>> +
>>> +  This driver can also be built as a module. If so, the module will be
>>> +  called ti-ads8688.
>>> +
>>>   config TI_AM335X_ADC
>>>   tristate "TI's AM335X ADC driver"
>>>   depends on MFD_TI_AM335X_TSCADC
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 99b37a9..04ab2c8 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -32,6 +32,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>>   obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>>   obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>>> +obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>>>   obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>>   obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>>>   obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>>> diff --git a/drivers/iio/adc/ti-ads8688.c b/drivers/iio/adc/ti-ads8688.c
>>> new file mode 100644
>>> index 000..537bb0a
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/ti-ads8688.c
>>> @@ -0,0 +1,472 @@
>>> +/*
>>> + * Copyright (C) 2015 Prevas A/S
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>&g

Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation

[Jonathan Cameron]

On 13/10/15 10:37, Paul Cercueil wrote:
> Signed-off-by: Paul Cercueil 
Looks good to me, but as it is a little bit 'different' and we are
defining entirely new generic bindings (the channel modes stuff)
I would like some more input.  It might be overkill but we do
of course have the pinctl framework which covers this sort of
thing... Might be worth considering if using that to get the unified
bindings might make sense here...

cc'd Linus in case he wants to comment on this.

It would obviously be a very heavy weight solution to the problem
so I'm far from convinced it makes sense - or even fits the usecase
terrible well.  Just thought I'd mention the possibility.
> ---
>  .../devicetree/bindings/iio/dac/ad5592r.txt| 43 
> ++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> 
>  v2: Fix indentation issue
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5592r.txt 
> b/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> new file mode 100644
> index 000..12b8d0e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> @@ -0,0 +1,43 @@
> +Analog Devices AD5592R/AD5593R DAC/ADC device driver
> +
> +Required properties for the AD5592R:
> + - compatible: Must be "adi,ad5592r"
> + - reg: SPI chip select number for the device
> + - spi-max-frequency: Max SPI frequency to use (< 3000)
> + - spi-cpol: The AD5592R requires inverse clock polarity (CPOL) mode
> +
> +Required properties for the AD5593R:
> + - compatible: Must be "adi,ad5593r"
> + - reg: I2C address of the device
> +
> +Required properties for all supported chips:
> + - channel-modes: An array of eight 8-bit values (one per channel)
> +   describing the mode of each channel. Macros specifying the valid 
> values
> +   can be found in .
> +   The following values are currently supported:
> + * CH_MODE_UNUSED (the pin is pulled down)
> + * CH_MODE_DAC
> + * CH_MODE_ADC
> + * CH_MODE_GPIO_TRISTATE
> +
> +Example:
> +
> + #include 
> +
> + ad5592r@0 {
> + compatible = "adi,ad5592r";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + spi-cpol;
> +
> + channel-modes = /bits/ 8 <
> + CH_MODE_DAC
> + CH_MODE_ADC
> + CH_MODE_ADC
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + CH_MODE_UNUSED
> + >;
> + };
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 2/2] iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs

[Jonathan Cameron]

On 13/10/15 10:38, Paul Cercueil wrote:
> This patch adds support for the AD5592R (spi) and AD5593R (i2c)
> ADC/DAC devices.
> 
> Signed-off-by: Paul Cercueil 
A few minor questions inline...
> ---
>  drivers/iio/dac/Kconfig   |  27 
>  drivers/iio/dac/Makefile  |   3 +
>  drivers/iio/dac/ad5592r-base.c| 289 
> ++
>  drivers/iio/dac/ad5592r-base.h|  56 +++
>  drivers/iio/dac/ad5592r.c | 126 +++
>  drivers/iio/dac/ad5593r.c | 121 ++
>  include/dt-bindings/iio/adi,ad5592r.h |  13 ++
>  7 files changed, 635 insertions(+)
>  create mode 100644 drivers/iio/dac/ad5592r-base.c
>  create mode 100644 drivers/iio/dac/ad5592r-base.h
>  create mode 100644 drivers/iio/dac/ad5592r.c
>  create mode 100644 drivers/iio/dac/ad5593r.c
>  create mode 100644 include/dt-bindings/iio/adi,ad5592r.h
> 
>  v2: Introduced changes suggested by upstream feedback
> 
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index e701e28..be7bb04 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -72,6 +72,33 @@ config AD5449
> To compile this driver as a module, choose M here: the
> module will be called ad5449.
>  
> +config AD5592R_BASE
> + tristate
> +
> +config AD5592R
> + tristate "Analog Devices AD5592R ADC/DAC driver"
> + depends on SPI_MASTER
> + depends on OF
> + select AD5592R_BASE
> + help
> +   Say yes here to build support for Analog Devices AD5592R
> +   Digital to Analog / Analog to Digital Converter.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ad5592r.
> +
> +config AD5593R
> + tristate "Analog Devices AD5593R ADC/DAC driver"
> + depends on I2C
> + depends on OF
> + select AD5592R_BASE
> + help
> +   Say yes here to build support for Analog Devices AD5593R
> +   Digital to Analog / Analog to Digital Converter.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ad5593r.
> +
>  config AD5504
>   tristate "Analog Devices AD5504/AD5501 DAC SPI driver"
>   depends on SPI
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 63ae056..ae00b67 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -11,6 +11,9 @@ obj-$(CONFIG_AD5064) += ad5064.o
>  obj-$(CONFIG_AD5504) += ad5504.o
>  obj-$(CONFIG_AD5446) += ad5446.o
>  obj-$(CONFIG_AD5449) += ad5449.o
> +obj-$(CONFIG_AD5592R_BASE) += ad5592r-base.o
> +obj-$(CONFIG_AD5592R) += ad5592r.o
> +obj-$(CONFIG_AD5593R) += ad5593r.o
>  obj-$(CONFIG_AD5755) += ad5755.o
>  obj-$(CONFIG_AD5764) += ad5764.o
>  obj-$(CONFIG_AD5791) += ad5791.o
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
> new file mode 100644
> index 000..c1132fd
> --- /dev/null
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -0,0 +1,289 @@
> +/*
> + * AD5592R Digital <-> Analog converters driver
> + *
> + * Copyright 2014 Analog Devices Inc.
> + * Author: Paul Cercueil 
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +/*
> + * TODO:
> + * - Add support for using channels as GPIOs
> + */
> +
> +#include "ad5592r-base.h"
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int ad5592r_set_channel_modes(struct ad5592r_state *st)
> +{
> + const struct ad5592r_rw_ops *ops = st->ops;
> + int ret;
> + unsigned i;
> + struct iio_dev *iio_dev = iio_priv_to_dev(st);
> + u8 pulldown = 0, open_drain = 0, tristate = 0,
> +dac = 0, adc = 0, gpio_in = 0, gpio_out = 0;
> + u16 read_back;
> +
> + for (i = 0; i < st->num_channels; i++) {
> + switch (st->channel_modes[i]) {
> + case CH_MODE_DAC:
> + dac |= BIT(i);
> +
> + /* fall-through */
> + case CH_MODE_ADC:
> + adc |= BIT(i);
> + break;
> +
> + case CH_MODE_GPIO_OUT:
> + gpio_out |= BIT(i);
> +
> + /* fall-through */
> + case CH_MODE_GPIO_IN:
> + gpio_in |= BIT(i);
> + break;
> +
> + case CH_MODE_GPIO_OPEN_DRAIN:
> + open_drain |= BIT(i);
> + break;
> +
> + case CH_MODE_GPIO_TRISTATE:
> + tristate |= BIT(i);
> + break;
> +
> + default:
> + pulldown |= BIT(i);
> + break;
> + }
> + }
> +
> + mutex_lock(&iio_dev->mlock);
> +
> + /* Configure pins that we use */
> + ret = ops->reg_write(st, AD5592R_REG_DAC_EN, dac);
> + if (ret)
> + goto err_unlock;
> +
> + ret = ops->reg_write(st, AD5592R_REG_ADC_EN, adc);
> + if (ret)
> + goto err_unlock;
> +
> + 

Re: [PATCH 1/2] iio: adc: mcp320x: Deprecated compatible strings with no vendor prefix

[Jonathan Cameron]

On 14/10/15 16:27, Michael Welling wrote:
> On Wed, Oct 14, 2015 at 02:54:38PM +0200, Javier Martinez Canillas wrote:
>> The Microchip Analog to Digital Converter (ADC) Device Tree binding
>> documents compatible strings with no vendor prefix. Since it should
>> compatible strings with also a vendor, add these to the binding doc
>> and mark the old ones as deprecated.
>>
>> The driver says that the device is from Microchip Technology which
>> is listed in Documentation/devicetree/bindings/vendor-prefixes.txt
>> so use the documented prefix.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>
>>  .../devicetree/bindings/iio/adc/mcp320x.txt| 30 
>> +++---
>>  1 file changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt 
>> b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
>> index 2a1f3af30155..bcd3ac8e6e0c 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
>> +++ b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
>> @@ -10,16 +10,28 @@ must be specified.
>>  Required properties:
>>  - compatible:   Must be one of the following, depending on the
>>  model:
>> -"mcp3001"
>> -"mcp3002"
>> -"mcp3004"
>> -"mcp3008"
>> -"mcp3201"
>> -"mcp3202"
>> -"mcp3204"
>> -"mcp3208"
>> -"mcp3301"
>> +"mcp3001" (DEPRECATED)
>> +"mcp3002" (DEPRECATED)
>> +"mcp3004" (DEPRECATED)
>> +"mcp3008" (DEPRECATED)
>> +"mcp3201" (DEPRECATED)
>> +"mcp3202" (DEPRECATED)
>> +"mcp3204" (DEPRECATED)
>> +"mcp3208" (DEPRECATED)
>> +"mcp3301" (DEPRECATED)
>>  
>> +"microchip,mcp3001"
>> +"microchip,mcp3002"
>> +"microchip,mcp3004"
>> +"microchip,mcp3008"
>> +"microchip,mcp3201"
>> +"microchip,mcp3202"
>> +"microchip,mcp3204"
>> +"microchip,mcp3208"
>> +"microchip,mcp3301"
>> +
>> +NOTE: The use of the compatibles with no vendor prefix
>> +is deprecated and only listed because old DT use them.
>>
> 
> Acked-by: Michael Welling 
Small point, Michael. Please add such acks below the the Author sign off.
Otherwise sometimes I miss them!  Added it now for this one.
>   
>>  Examples:
>>  spi_controller {
>> -- 
>> 2.4.3
>>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] iio: adc: mcp320x: Deprecated compatible strings with no vendor prefix

[Jonathan Cameron]

On 14/10/15 13:54, Javier Martinez Canillas wrote:
> The Microchip Analog to Digital Converter (ADC) Device Tree binding
> documents compatible strings with no vendor prefix. Since it should
> compatible strings with also a vendor, add these to the binding doc
> and mark the old ones as deprecated.
> 
> The driver says that the device is from Microchip Technology which
> is listed in Documentation/devicetree/bindings/vendor-prefixes.txt
> so use the documented prefix.
> 
> Signed-off-by: Javier Martinez Canillas 
Applied to the togreg branch of iio.git - initially pushed out as testing.
Thanks,
> ---
> 
>  .../devicetree/bindings/iio/adc/mcp320x.txt| 30 
> +++---
>  1 file changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt 
> b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
> index 2a1f3af30155..bcd3ac8e6e0c 100644
> --- a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
> @@ -10,16 +10,28 @@ must be specified.
>  Required properties:
>   - compatible:   Must be one of the following, depending on the
>   model:
> - "mcp3001"
> - "mcp3002"
> - "mcp3004"
> - "mcp3008"
> - "mcp3201"
> - "mcp3202"
> - "mcp3204"
> - "mcp3208"
> - "mcp3301"
> + "mcp3001" (DEPRECATED)
> + "mcp3002" (DEPRECATED)
> + "mcp3004" (DEPRECATED)
> + "mcp3008" (DEPRECATED)
> + "mcp3201" (DEPRECATED)
> + "mcp3202" (DEPRECATED)
> + "mcp3204" (DEPRECATED)
> + "mcp3208" (DEPRECATED)
> + "mcp3301" (DEPRECATED)
>  
> + "microchip,mcp3001"
> + "microchip,mcp3002"
> + "microchip,mcp3004"
> + "microchip,mcp3008"
> + "microchip,mcp3201"
> + "microchip,mcp3202"
> + "microchip,mcp3204"
> + "microchip,mcp3208"
> + "microchip,mcp3301"
> +
> + NOTE: The use of the compatibles with no vendor prefix
> + is deprecated and only listed because old DT use them.
>  
>  Examples:
>  spi_controller {
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] iio:adc:palmas: add DT support

[Jonathan Cameron]

On 16/10/15 13:53, H. Nikolaus Schaller wrote:
> From: Marek Belisko 
> 
> Code was found at:
> https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1
> 
> Signed-off-by: Laxman Dewangan 
> Signed-off-by: Marek Belisko  [Fixed minor typos + add 
> channels list to documentation]
I am happy with your responses to Lars and that kind of covers what Mark raised 
as well.

One typo correction applied.

Applied to the togreg branch of iio.git

Thanks,

Jonathan
> ---
>  .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 48 
>  drivers/iio/adc/palmas_gpadc.c | 52 
> +++---
>  2 files changed, 95 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> new file mode 100644
> index 000..a6de996
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> @@ -0,0 +1,48 @@
> +* Palmas general purpose ADC IP block devicetree bindings
> +
> +Channels list:
> + 0 battery type
> + 1 battery temp NTC (optional current source)
> + 2 GP
> + 3 temp (with ext. diode, optional current source)
> + 4 GP
> + 5 GP
> + 6 VBAT_SENSE
> + 7 VCC_SENSE
> + 8 Backup Battery voltage
> + 9 external charger (VCHG)
> + 10 VBUS
> + 11 DC-DC current probe (how does this work?)
> + 12 internal die temp
> + 13 internal die temp
> + 14 USB ID pin voltage
> + 15 test network
> +
> +Required properties:
> +- compatible : Must be "ti,palmas-gpadc".
> +- #io-channel-cells: Should be set to <1>.
> +
> +Optional sub-nodes:
> +ti,channel0-current-microamp: Channel 0 current in uA.
> + Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
> +ti,channel3-current-microamp: Channel 3 current in uA.
> + Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
Values

> +ti,enable-extended-delay: Enable extended delay.
> +
> +Example:
> +
> +pmic {
> + compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
> + ...
> + gpadc {
> + compatible = "ti,palmas-gpadc";
> + interrupts = <18 0
> +   16 0
> +   17 0>;
> + #io-channel-cells = <1>;
> + ti,channel0-current-microamp = <5>;
> + ti,channel3-current-microamp = <10>;
> + };
> + };
> + ...
> +};
> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> index 71763c5..f42eb8a 100644
> --- a/drivers/iio/adc/palmas_gpadc.c
> +++ b/drivers/iio/adc/palmas_gpadc.c
> @@ -21,6 +21,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -460,6 +462,34 @@ static const struct iio_chan_spec 
> palmas_gpadc_iio_channel[] = {
>   PALMAS_ADC_CHAN_IIO(IN15, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
>  };
>  
> +static int palmas_gpadc_get_adc_dt_data(struct platform_device *pdev,
> + struct palmas_gpadc_platform_data **gpadc_pdata)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct palmas_gpadc_platform_data *gp_data;
> + int ret;
> + u32 pval;
> +
> + gp_data = devm_kzalloc(&pdev->dev, sizeof(*gp_data), GFP_KERNEL);
> + if (!gp_data)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32(np, "ti,channel0-current-microamp", &pval);
> + if (!ret)
> + gp_data->ch0_current = pval;
> +
> + ret = of_property_read_u32(np, "ti,channel3-current-microamp", &pval);
> + if (!ret)
> + gp_data->ch3_current = pval;
> +
> + gp_data->extended_delay = of_property_read_bool(np,
> + "ti,enable-extended-delay");
> +
> + *gpadc_pdata = gp_data;
> +
> + return 0;
> +}
> +
>  static int palmas_gpadc_probe(struct platform_device *pdev)
>  {
>   struct palmas_gpadc *adc;
> @@ -469,12 +499,17 @@ static int palmas_gpadc_probe(struct platform_device 
> *pdev)
>   int ret, i;
>  
>   pdata = dev_get_platdata(pdev->dev.parent);
> - if (!pdata || !pdata->gpadc_pdata) {
> - dev_err(&pdev->dev, "No platform data\n");
> - return -ENODEV;
> - }
>  
> - gpadc_pdata = pdata->gpadc_pdata;
> + if (pdata && pdata->gpadc_pdata)
> + gpadc_pdata = pdata->gpadc_pdata;
> +
> + if (!gpadc_pdata && pdev->dev.of_node) {
> + ret = palmas_gpadc_get_adc_dt_data(pdev, &gpadc_pdata);
> + if (ret < 0)
> + return ret;
> + }
> + if (!gpadc_pdata)
> + return -EINVAL;
>  
>   indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*adc));
>   if (!indio_dev) {
> @@ -790,12 +825,19 @@ static const struct dev_pm_ops palmas_pm_ops = {
>   palmas_gpadc_resume)
>  };
>  
> +static const struc

Re: [PATCH v3 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[Jonathan Cameron]

On 16/10/15 13:53, H. Nikolaus Schaller wrote:
> This driver code was found as:
> 
> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
> 
> Fixed various compilation issues and test this driver on omap5 evm.
> 
> Signed-off-by: Pradeep Goudagunta 
> Signed-off-by: H. Nikolaus Schaller 
> Signed-off-by: Marek Belisko 
> Acked-by: Laxman Dewangan 
> Reviewed-by: Jonathan Cameron 
> Acked-by: Lee Jones 
Applied to the togreg branch of iio.git - initially pushed out as testing.
Unfortunately the timing is such that it's not going to make the upcoming
merge window so will be an early entry to linux-next after the merge window
closes.

Jonathan
> ---
>  drivers/iio/adc/Kconfig|   8 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/palmas_gpadc.c | 817 
> +
>  include/linux/mfd/palmas.h |  75 ++--
>  4 files changed, 877 insertions(+), 24 deletions(-)
>  create mode 100644 drivers/iio/adc/palmas_gpadc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 50c103d..5100e56 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -264,6 +264,14 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
>  
> +config PALMAS_GPADC
> + tristate "TI Palmas General Purpose ADC"
> + depends on MFD_PALMAS
> + help
> +   Palmas series pmic chip by Texas Instruments (twl6035/6037)
> +   is used in smartphones and tablets and supports a 16 channel
> +   general purpose ADC.
> +
>  config QCOM_SPMI_IADC
>   tristate "Qualcomm SPMI PMIC current ADC"
>   depends on SPMI
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index a096210..716f112 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>  obj-$(CONFIG_MCP3422) += mcp3422.o
>  obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>  obj-$(CONFIG_NAU7802) += nau7802.o
> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>  obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>  obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> new file mode 100644
> index 000..71763c5
> --- /dev/null
> +++ b/drivers/iio/adc/palmas_gpadc.c
> @@ -0,0 +1,817 @@
> +/*
> + * palmas-adc.c -- TI PALMAS GPADC.
> + *
> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
> + *
> + * Author: Pradeep Goudagunta 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MOD_NAME "palmas-gpadc"
> +#define PALMAS_ADC_CONVERSION_TIMEOUT(msecs_to_jiffies(5000))
> +#define PALMAS_TO_BE_CALCULATED 0
> +#define PALMAS_GPADC_TRIMINVALID -1
> +
> +struct palmas_gpadc_info {
> +/* calibration codes and regs */
> + int x1; /* lower ideal code */
> + int x2; /* higher ideal code */
> + int v1; /* expected lower volt reading */
> + int v2; /* expected higher volt reading */
> + u8 trim1_reg;   /* register number for lower trim */
> + u8 trim2_reg;   /* register number for upper trim */
> + int gain;   /* calculated from above (after reading trim regs) */
> + int offset; /* calculated from above (after reading trim regs) */
> + int gain_error; /* calculated from above (after reading trim regs) */
> + bool is_uncalibrated;   /* if channel has calibration data */
> +};
> +
> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
> _is_uncalibrated) \
> + [PALMAS_ADC_CH_##_chan] = { \
> + .x1 = _x1, \
> + .x2 = _x2, \
> + .v1 = _v1, \
> + .v2 = _v2, \
> + .gain = PALMAS_TO_BE_CALCULATED, \
> + .offset = PALMAS_TO_BE_CALCULATED, \
> + .gain_error = PALMAS_TO_BE_CALCULATED, \
> + .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
> + .trim2_reg = PALMAS_GPADC_TRIM##_t2,  \
> + .is_uncalibrated = _is_uncalibrated \
> + }
> +
> +static struct palmas_gpadc_info palmas_gpadc_info[] = {
> + PALMAS_ADC_INFO(IN0, 2064

Re: [PATCH v4] iio: mma8452: support either of the available interrupt pins

[Jonathan Cameron]

On 22/10/15 19:22, Rob Herring wrote:
> On Thu, Oct 15, 2015 at 8:10 AM, Martin Kepplinger  wrote:
>> This change is important in order for everyone to be easily able to use the
>> driver for one of the supported accelerometer chips!
>>
>> Until now, the driver blindly assumed that the INT1 interrupt line is wired
>> on a user's board. But these devices have 2 interrupt lines and can route
>> their interrupt sources to one of them. Now, if "INT2" is found and matches
>> i2c_client->irq, INT2 will be used.
>>
>> The chip's default actually is INT2, which is why probably many boards will
>> have it wired and can make use of this.
>>
>> Of course, this also falls back to assuming INT1, so for existing users
>> nothing will break. The new functionality is described in the bindings doc.
>>
>> Signed-off-by: Martin Kepplinger 
>> ---
>> changelog:
>> v4: use irq that matches client->irq, backwards compatible
>> v3: correctly assign irq if both pins are described in DT
>> v2: don't warn but normally handle if both pins are described in dts
>> thanks Mark Rutland
>> v1: initial post
>>
>>  .../devicetree/bindings/iio/accel/mma8452.txt   |  6 ++
> 
> For the binding:
> 
> Rob Herring 
I've guessed that was an Acked-by :)

Anyhow, applied to the togreg branch of iio.git.

I'm afraid after my hiatus for a couple of weeks (day job work crisis now
over) this has missed going in for the current cycle.

IIO merge closes more than a week before the merge window opens and Linus
just announced probably release a week today.

Sorry about that, will be queued up for an early entry into linux next
after the merge window closes.

Jonathan
> 
>>  drivers/iio/accel/mma8452.c | 21 
>> +++--
>>  2 files changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
>> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> index e3c3746..3c10e85 100644
>> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
>> @@ -7,13 +7,18 @@ Required properties:
>>  * "fsl,mma8453"
>>  * "fsl,mma8652"
>>  * "fsl,mma8653"
>> +
>>- reg: the I2C address of the chip
>>
>>  Optional properties:
>>
>>- interrupt-parent: should be the phandle for the interrupt controller
>> +
>>- interrupts: interrupt mapping for GPIO IRQ
>>
>> +  - interrupt-names: should contain "INT1" and/or "INT2", the 
>> accelerometer's
>> +interrupt line in use.
>> +
>>  Example:
>>
>> mma8453fc@1d {
>> @@ -21,4 +26,5 @@ Example:
>> reg = <0x1d>;
>> interrupt-parent = <&gpio1>;
>> interrupts = <5 0>;
>> +   interrupt-names = "INT2";
>> };
>> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
>> index 1eccc2d..116a6e4 100644
>> --- a/drivers/iio/accel/mma8452.c
>> +++ b/drivers/iio/accel/mma8452.c
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #define MMA8452_STATUS 0x00
>>  #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
>> @@ -1130,13 +1131,21 @@ static int mma8452_probe(struct i2c_client *client,
>>MMA8452_INT_FF_MT;
>> int enabled_interrupts = MMA8452_INT_TRANS |
>>  MMA8452_INT_FF_MT;
>> +   int irq2;
>>
>> -   /* Assume wired to INT1 pin */
>> -   ret = i2c_smbus_write_byte_data(client,
>> -   MMA8452_CTRL_REG5,
>> -   supported_interrupts);
>> -   if (ret < 0)
>> -   return ret;
>> +   irq2 = of_irq_get_byname(client->dev.of_node, "INT2");
>> +
>> +   if (irq2 == client->irq) {
>> +   dev_dbg(&client->dev, "using interrupt line INT2\n");
>> +   } else {
>> +   ret = i2c_smbus_write_byte_data(client,
>> +   MMA8452_CTRL_REG5,
>> +   
>> supported_interrupts);
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   dev_dbg(&client->dev, "using interrupt line INT1\n");
>> +   }
>>
>> ret = i2c_smbus_write_byte_data(client,
>> MMA8452_CTRL_REG4,
>> --
>> 2.1.4
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info

Re: [PATCH v4 1/2] iio: adc: Add TI ADS8688

[Jonathan Cameron]

On 06/10/15 09:12, Sean Nyekjaer wrote:
> This patch adds support for the Texas Intruments ADS8688 ADC.
> 
> Signed-off-by: Sean Nyekjaer 
> Reviewed-by: Martin Hundebøll 
only one issue that I can see.  You do need locking to protect
your local buffers.  A local lock in the same structure would be
appropriate for this.

Neither sysfs nor IIO provide any serialization guarantees
so multiple concurrent reads are more than possible and may
cause you data corruption as it stands.

Other than that, it's looking very nice.

Thanks,

Jonathan
> ---
> Changes since v3:
> - fixed multiline comments
> - write_raw_get_fmt _SCALE is nano, _OFFSET is int
> 
> Changes since v2:
> - Removed unused variables
> - Removed unnecessary mutex lock
> - Range array is a enum
> - Made the read and write functions less complex and easier to read
> - Added inline comments
> - Added callback to write_raw_get_fmt
> 
> Changes since v1:
> - Now possible to read and write the actual offset and scale values
> - Removed unused includes
> - Removed unused buffer references
>  drivers/iio/adc/Kconfig  |  10 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads8688.c | 472 
> +++
>  3 files changed, 483 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads8688.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7868c74..4135d17 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -333,6 +333,16 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS8688
> + tristate "Texas Instruments ADS8688"
> + depends on SPI && OF
> + help
> +   If you say yes here you get support for Texas Instruments ADS8684 and
> +   and ADS8688 ADC chips
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads8688.
> +
>  config TI_AM335X_ADC
>   tristate "TI's AM335X ADC driver"
>   depends on MFD_TI_AM335X_TSCADC
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 99b37a9..04ab2c8 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> +obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>  obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> diff --git a/drivers/iio/adc/ti-ads8688.c b/drivers/iio/adc/ti-ads8688.c
> new file mode 100644
> index 000..537bb0a
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads8688.c
> @@ -0,0 +1,472 @@
> +/*
> + * Copyright (C) 2015 Prevas A/S
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define ADS8688_CMD_REG(x)   (x << 8)
> +#define ADS8688_CMD_REG_NOOP 0x00
> +#define ADS8688_CMD_REG_RST  0x85
> +#define ADS8688_CMD_REG_MAN_CH(chan) (0xC0 | (4 * chan))
> +#define ADS8688_CMD_DONT_CARE_BITS   16
> +
> +#define ADS8688_PROG_REG(x)  (x << 9)
> +#define ADS8688_PROG_REG_RANGE_CH(chan)  (0x05 + chan)
> +#define ADS8688_PROG_WR_BIT  BIT(8)
> +#define ADS8688_PROG_DONT_CARE_BITS  8
> +
> +#define ADS8688_REG_PLUSMINUS25VREF  0
> +#define ADS8688_REG_PLUSMINUS125VREF 1
> +#define ADS8688_REG_PLUSMINUS0625VREF2
> +#define ADS8688_REG_PLUS25VREF   5
> +#define ADS8688_REG_PLUS125VREF  6
> +
> +#define ADS8688_VREF_MV  4096
> +#define ADS8688_REALBITS 16
> +
> +/*
> + * enum ads8688_range - ADS8688 reference voltage range
> + * @ADS8688_PLUSMINUS25VREF: Device is configured for input range ±2.5 * VREF
> + * @ADS8688_PLUSMINUS125VREF: Device is configured for input range ±1.25 * 
> VREF
> + * @ADS8688_PLUSMINUS0625VREF: Device is configured for input range ±0.625 * 
> VREF
> + * @ADS8688_PLUS25VREF: Device is configured for input range 0 - 2.5 * VREF
> + * @ADS8688_PLUS125VREF: Device is configured for input range 0 - 1.25 * VREF
> + */
> +enum ads8688_range {
> + ADS8688_PLUSMINUS25VREF,
> + ADS8688_PLUSMINUS125VREF,
> + ADS8688_PLUSMINUS0625VREF,
> + ADS8688_PLUS25VREF,
> + ADS8688_PLUS125VREF,
> +};
> +
> +struct ads8688_chip_info {
> + const struct iio_chan_spec *channels;
> + unsigned int num_channels;
> +};
> +
> +struct ads8688_state {
> + const struct ads8688_chip_info  *chip_info;
> + struct spi_device   *spi;
> + struct regulator 

Re: [PATCH 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[Jonathan Cameron]

On 04/10/15 17:04, H. Nikolaus Schaller wrote:
> 
> Am 27.09.2015 um 17:21 schrieb Jonathan Cameron :
> 
>> On 23/09/15 13:48, H. Nikolaus Schaller wrote:
>>> This driver code was found as:
>>>
>>> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
>>>
>>> Fixed various compilation issues and test this driver on omap5 evm.
>>>
>>> Signed-off-by: Pradeep Goudagunta 
>>> Signed-off-by: H. Nikolaus Schaller 
>>> Signed-off-by: Marek Belisko 
>> Various bits inline.
> 
> Thanks again!
> 
> Worked into V2 (coming right after this mail).
> Comments below, where/why we have not exactly followed your feedback.
Responses inline, but we haven't disagreed on anything important
so none of it really matters!

Jonathan
> 
> BR,
> Nikolaus
> 
>>
>> Jonathan
>>> ---
>>> drivers/iio/adc/Kconfig|   9 +
>>> drivers/iio/adc/Makefile   |   1 +
>>> drivers/iio/adc/palmas_gpadc.c | 797 
>>> +
>>> include/linux/mfd/palmas.h |  59 ++-
>>> 4 files changed, 862 insertions(+), 4 deletions(-)
>>> create mode 100644 drivers/iio/adc/palmas_gpadc.c
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index eb0cd89..f6df9db 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -242,6 +242,15 @@ config NAU7802
>>>   To compile this driver as a module, choose M here: the
>>>   module will be called nau7802.
>>>
>>> +config PALMAS_GPADC
>>> +   tristate "TI Palmas General Purpose ADC"
>>> +   depends on MFD_PALMAS
>>> +   help
>>> + Palmas series pmic chip by texas Instruments (twl6035/6037)
>>> + is used in smartphones and tablets and supports a 16 channel
>>> + general purpose ADC. Add iio driver to read different channel
>>> + of the GPADCs.
>>> +
>>> config QCOM_SPMI_IADC
>>> tristate "Qualcomm SPMI PMIC current ADC"
>>> depends on SPMI
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index a096210..716f112 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>>> obj-$(CONFIG_MCP3422) += mcp3422.o
>>> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>>> obj-$(CONFIG_NAU7802) += nau7802.o
>>> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>>> obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
>>> new file mode 100644
>>> index 000..17abb28
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/palmas_gpadc.c
>>> @@ -0,0 +1,797 @@
>>> +/*
>>> + * palmas-adc.c -- TI PALMAS GPADC.
>>> + *
>>> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
>>> + *
>>> + * Author: Pradeep Goudagunta 
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation version 2.
>>> + */
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define MOD_NAME "palmas-gpadc"
>>> +#define ADC_CONVERSION_TIMEOUT (msecs_to_jiffies(5000))
>>> +#define TO_BE_CALCULATED 0
>>> +
>>> +struct palmas_gpadc_info {
>>> +/* calibration codes and regs */
>> Full docs on this would be appreciated.
> Is mostly defined in the Palmas data sheet but I have added some comments.
>>> +   int x1;
>>> +   int x2;
>>> +   int v1;
>>> +   int v2;
>>> +   u8 trim1_reg;
>>> +   u8 trim2_reg;
>>> +   int gain;
>>> +   int offset;
>>> +   int gain_error;
>>> +   bool is_correct_code;
>>> +};
>>> +
>>> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
>>> _is_correct_code)\
>>&

Re: [PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[Jonathan Cameron]

On 05/10/15 07:14, H. Nikolaus Schaller wrote:
> This driver code was found as:
> 
> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
> 
> Fixed various compilation issues and test this driver on omap5 evm.
> 
> Signed-off-by: Pradeep Goudagunta 
> Signed-off-by: H. Nikolaus Schaller 
> Signed-off-by: Marek Belisko 

I'm pretty much fine with this.  However, there are some edits within the
existing mfd support so I will want acks for that or for the driver to go
through the MFD tree (note that as it touched that, even if only a header,
Lee and Samuel should have been cc'd).

One thing that slightly confuses me is there seems to be hints of support in the
mfd driver already... I can't find any sign of the child device however so
I guess this is fine from that point of view.

Reviewed-by: Jonathan Cameron 
> ---
>  drivers/iio/adc/Kconfig|   9 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/palmas_gpadc.c | 818 
> +
>  include/linux/mfd/palmas.h |  75 ++--
>  4 files changed, 879 insertions(+), 24 deletions(-)
>  create mode 100644 drivers/iio/adc/palmas_gpadc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index eb0cd89..05a0368 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -242,6 +242,15 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
>  
> +config PALMAS_GPADC
> + tristate "TI Palmas General Purpose ADC"
> + depends on MFD_PALMAS
> + help
> +   Say yes here to build support for Texas Instruments Palmas.
> +
> +   Palmas series pmic chip (twl6035/6037) is used in smartphones and
> +   tablets and supports a 16 channel general purpose ADC.
> +
>  config QCOM_SPMI_IADC
>   tristate "Qualcomm SPMI PMIC current ADC"
>   depends on SPMI
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index a096210..716f112 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>  obj-$(CONFIG_MCP3422) += mcp3422.o
>  obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>  obj-$(CONFIG_NAU7802) += nau7802.o
> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>  obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>  obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> new file mode 100644
> index 000..6805d81
> --- /dev/null
> +++ b/drivers/iio/adc/palmas_gpadc.c
> @@ -0,0 +1,818 @@
> +/*
> + * palmas-adc.c -- TI PALMAS GPADC.
> + *
> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
> + *
> + * Author: Pradeep Goudagunta 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MOD_NAME "palmas-gpadc"
> +#define PALMAS_ADC_CONVERSION_TIMEOUT(msecs_to_jiffies(5000))
> +#define PALMAS_TO_BE_CALCULATED 0
> +#define PALMAS_GPADC_TRIMINVALID -1
> +
> +struct palmas_gpadc_info {
> +/* calibration codes and regs */
> + int x1; /* lower ideal code */
> + int x2; /* higher ideal code */
> + int v1; /* expected lower volt reading */
> + int v2; /* expected higher volt reading */
> + u8 trim1_reg;   /* register number for lower trim */
> + u8 trim2_reg;   /* register number for upper trim */
> + int gain;   /* calculated from above (after reading trim regs) */
> + int offset; /* calculated from above (after reading trim regs) */
> + int gain_error; /* calculated from above (after reading trim regs) */
> + bool is_uncalibrated;   /* if channel has calibration data */
> +};
> +
> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
> _is_uncalibrated) \
> + [PALMAS_ADC_CH_##_chan] = { \
> + .x1 = _x1, \
> + .x2 = _x2, \
> + .v1 = _v1, \
> + .v2 = _v2, \
> + .gain = PALMAS_TO_BE_CALCULATED, \
> + .offset = PALMAS_TO_BE_CALCULATED, \
> + .gain_error = PALMAS_TO_BE_CALCULATED, \
> + .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
> + 

Re: [PATCH 1/5] iio: adc: add IMX7D ADC driver support

[Jonathan Cameron]

On 08/10/15 11:59, Haibo Chen wrote:
> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
> driver support, and the driver only support ADC software trigger.
> 
> Signed-off-by: Haibo Chen 
Hi Haibo,

A very nice clean driver. I've noted a few minor stylistic things inline that
I would like you to clean up.

In particular we are fairly strict in IIO about prefixing register defines
etc.  It is much easier to just do this be default than to constantly
be wary of where a naming clash might occur with a core header in the
future.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/Kconfig |   9 +
>  drivers/iio/adc/Makefile|   1 +
>  drivers/iio/adc/imx7d_adc.c | 586 
> 
>  3 files changed, 596 insertions(+)
>  create mode 100644 drivers/iio/adc/imx7d_adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7868c74..bf0611c 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -194,6 +194,15 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>  
> +config IMX7D_ADC
> + tristate "IMX7D ADC driver"
> + depends on OF
> + help
> +   Say yes here to build support for IMX7D ADC.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called imx7d_adc.
> +
>  config LP8788_ADC
>   tristate "LP8788 ADC driver"
>   depends on MFD_LP8788
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 99b37a9..282ffc01 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1027) += max1027.o
>  obj-$(CONFIG_MAX1363) += max1363.o
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> new file mode 100644
> index 000..8be8bf8
> --- /dev/null
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -0,0 +1,586 @@
> +/*
> + * Freescale ADC driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/* This will be the driver name the kernel reports */
> +#define DRIVER_NAME "imx7d_adc"
> +
> +/* ADC register */
Please prefix defines with IMX7D_ or similar.
Avoids possible naming clashes in the future

> +#define REG_ADC_CH_A_CFG10x00
> +#define REG_ADC_CH_A_CFG20x10
> +#define REG_ADC_CH_B_CFG10x20
> +#define REG_ADC_CH_B_CFG20x30
> +#define REG_ADC_CH_C_CFG10x40
> +#define REG_ADC_CH_C_CFG20x50
> +#define REG_ADC_CH_D_CFG10x60
> +#define REG_ADC_CH_D_CFG20x70
> +#define REG_ADC_CH_SW_CFG0x80
> +#define REG_ADC_TIMER_UNIT   0x90
> +#define REG_ADC_DMA_FIFO 0xa0
> +#define REG_ADC_FIFO_STATUS  0xb0
> +#define REG_ADC_INT_SIG_EN   0xc0
> +#define REG_ADC_INT_EN   0xd0
> +#define REG_ADC_INT_STATUS   0xe0
> +#define REG_ADC_CHA_B_CNV_RSLT   0xf0
> +#define REG_ADC_CHC_D_CNV_RSLT   0x100
> +#define REG_ADC_CH_SW_CNV_RSLT   0x110
> +#define REG_ADC_DMA_FIFO_DAT 0x120
> +#define REG_ADC_ADC_CFG  0x130
> +
> +#define CHANNEL_REG_SHIF 0x20
> +
> +#define CHANNEL_EN   (0x1 << 31)
> +#define CHANNEL_DISABLE  (0x0 << 31)
> +#define CHANNEL_SINGLE   (0x1 << 30)
> +#define CHANNEL_AVG_EN   (0x1 << 29)
> +#define CHANNEL_SEL_SHIF 24
> +
> +#define PRE_DIV_4(0x0 << 29)
> +#define PRE_DIV_8(0x1 << 29)
> +#define PRE_DIV_16   (0x2 << 29)
> +#define PRE_DIV_32   (0x3 << 29)
> +#define PRE_DIV_64   (0x4 << 29)
> +#define PRE_DIV_128  (0x5 << 29)

Please name these in a fashion that makes it clear which
register they are fields within.
IMX7D_REG_ADC_TIMER_UNIT_ADC_CLK_DOWN for example.
> +
> +#define ADC_CLK_DOWN (0x1 << 31)
> +#define ADC_POWER_DOWN   (0x1 << 1)
> +#define ADC_EN   0x1
> +
> +#define AVG_NUM_4(0x0 << 12)
> +#define AVG_NUM_8

Re: [PATCH 2/5] Documentation: add the binding file for Freescale imx7d ADC driver

[Jonathan Cameron]

On 11/10/15 14:31, Jonathan Cameron wrote:
> On 08/10/15 11:59, Haibo Chen wrote:
>> The patch adds the binding file for Freescale imx7d ADC driver.
>>
>> Signed-off-by: Haibo Chen 
> Couple of trivial typos..  otherwise fine.
>> ---
>>  .../devicetree/bindings/iio/adc/imx7d-adc.txt  | 26 
>> ++
>>  1 file changed, 26 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt 
>> b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
>> new file mode 100644
>> index 000..6b21fd27
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
>> @@ -0,0 +1,26 @@
>> +Freescale imx7d ADC bindings
>> +
>> +The devicetree bingdings are for the nwe ADC driver written for
>> +imx7d SoC.
> bindings and new
Actually I'd drop the new.  Makes sense in a patch comment, but
in the docs it'll rapidly stop being new.

>> +
>> +Required properties:
>> +- compatible: Should be "fsl,imx7d-adc"
>> +- reg: Offset and length of the register set for the ADC device
>> +- interrupts: The interrupt number for the ADC device
>> +- clocks: The root clock of the ADC controller
>> +- clock-names: Must contain "adc", matching entry in the clocks property
>> +- vref-supply: The regulator supply ADC reference voltage
>> +
>> +Optional properties:
>> +- num-channels: the number of channels used
>> +
>> +Example:
>> +adc1: adc@3061 {
>> +compatible = "fsl,imx7d-adc";
>> +reg = <0x3061 0x1>;
>> +interrupts = ;
>> +clocks = <&clks IMX7D_ADC_ROOT_CLK>;
>> +clock-names = "adc";
>> +num-channels = <4>;
>> +vref-supply = <®_vcc_3v3_mcu>;
>> +};
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] Documentation: add the binding file for Freescale imx7d ADC driver

[Jonathan Cameron]

On 08/10/15 11:59, Haibo Chen wrote:
> The patch adds the binding file for Freescale imx7d ADC driver.
> 
> Signed-off-by: Haibo Chen 
Couple of trivial typos..  otherwise fine.
> ---
>  .../devicetree/bindings/iio/adc/imx7d-adc.txt  | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt 
> b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
> new file mode 100644
> index 000..6b21fd27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
> @@ -0,0 +1,26 @@
> +Freescale imx7d ADC bindings
> +
> +The devicetree bingdings are for the nwe ADC driver written for
> +imx7d SoC.
bindings and new
> +
> +Required properties:
> +- compatible: Should be "fsl,imx7d-adc"
> +- reg: Offset and length of the register set for the ADC device
> +- interrupts: The interrupt number for the ADC device
> +- clocks: The root clock of the ADC controller
> +- clock-names: Must contain "adc", matching entry in the clocks property
> +- vref-supply: The regulator supply ADC reference voltage
> +
> +Optional properties:
> +- num-channels: the number of channels used
> +
> +Example:
> +adc1: adc@3061 {
> + compatible = "fsl,imx7d-adc";
> + reg = <0x3061 0x1>;
> + interrupts = ;
> + clocks = <&clks IMX7D_ADC_ROOT_CLK>;
> + clock-names = "adc";
> + num-channels = <4>;
> + vref-supply = <®_vcc_3v3_mcu>;
> +};
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] iio: ad5064: Always use external vref if there is no internal vref

[Jonathan Cameron]

On 02/10/15 13:41, Paul Cercueil wrote:
> If the device does not have an internal reference, there is no
> other choice but to use the external reference. In that case,
> it does not make much sense to have to specify it.
> 
> This patch ensures that the external reference is used if the
> device does not feature an internal reference.
> 
> Signed-off-by: Paul Cercueil 
Other than the issue the autobuilder found I'm happy enough
with the series.

Given it is Lars' driver I'd like him to take a look as well
before I apply it.

Thanks,

Jonathan
> ---
>  drivers/iio/dac/ad5064.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iio/dac/ad5064.c b/drivers/iio/dac/ad5064.c
> index 7146f42..daee39e 100644
> --- a/drivers/iio/dac/ad5064.c
> +++ b/drivers/iio/dac/ad5064.c
> @@ -464,7 +464,9 @@ static int ad5064_probe(struct device *dev, enum 
> ad5064_type type,
>   for (i = 0; i < ad5064_num_vref(st); ++i)
>   st->vref_reg[i].supply = ad5064_vref_name(st, i);
>  
> - if (dev->of_node) {
> + if (!st->chip_info->internal_vref) {
> + ext_vref = true;
> + } else if (dev->of_node) {
>   for (i = 0; ext_vref && i < ad5064_num_vref(st); ++i)
>   ext_vref = of_property_read_bool(dev->of_node,
>   ad5064_vref_name(st, i));
> @@ -483,11 +485,6 @@ static int ad5064_probe(struct device *dev, enum 
> ad5064_type type,
>   if (ret)
>   return ret;
>   } else {
> - if (!st->chip_info->internal_vref) {
> - dev_err(dev, "No vref available\n");
> - return -ENXIO;
> - }
> -
>   st->use_internal_vref = true;
>   ret = ad5064_write(st, AD5064_CMD_CONFIG, 0,
>   AD5064_CONFIG_INT_VREF_ENABLE, 0);
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs

[Jonathan Cameron]

On 02/10/15 13:45, Paul Cercueil wrote:
> This patch adds support for the AD5592R (spi) and AD5593R (i2c)
> ADC/DAC devices.
> 
> Signed-off-by: Paul Cercueil 
SMBUS makes the assumption that the wire order is little endian. As such
all the i2c drivers should be doing an necessary endian conversions
for word write / read internally.  Hence if the wire order is be16 you'll
want unconditional swaps.  Note we have i2c_smbus_read_word_swapped
and i2c_smbus_write_word_swapped for this.

I've mentioned this in a few places inline but there are probably others.
See Documentation/i2c/smbus-protocol.txt for more details.

Various other bits inline.

I would in particular like you to use a common module to handle the base
part rather than linking this object file into two separate modules..

Jonathan
> ---
>  drivers/iio/dac/Kconfig   |  22 +++
>  drivers/iio/dac/Makefile  |   2 +
>  drivers/iio/dac/ad5592r-base.c| 290 
> ++
>  drivers/iio/dac/ad5592r-base.h|  59 +++
>  drivers/iio/dac/ad5592r.c | 121 ++
>  drivers/iio/dac/ad5593r.c | 121 ++
>  include/dt-bindings/iio/adi,ad5592r.h |  13 ++
>  7 files changed, 628 insertions(+)
>  create mode 100644 drivers/iio/dac/ad5592r-base.c
>  create mode 100644 drivers/iio/dac/ad5592r-base.h
>  create mode 100644 drivers/iio/dac/ad5592r.c
>  create mode 100644 drivers/iio/dac/ad5593r.c
>  create mode 100644 include/dt-bindings/iio/adi,ad5592r.h
> 
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index e701e28..e520059 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -72,6 +72,28 @@ config AD5449
> To compile this driver as a module, choose M here: the
> module will be called ad5449.
>  
> +config AD5592R
> + tristate "Analog Devices AD5592R ADC/DAC driver"
> + depends on SPI_MASTER
> + depends on OF
> + help
> +   Say yes here to build support for Analog Devices AD5592R
> +   Digital to Analog / Analog to Digital Converter.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ad5592r.
> +
> +config AD5593R
> + tristate "Analog Devices AD5593R ADC/DAC driver"
> + depends on I2C
> + depends on OF
> + help
> +   Say yes here to build support for Analog Devices AD5593R
> +   Digital to Analog / Analog to Digital Converter.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ad5593r.
> +
>  config AD5504
>   tristate "Analog Devices AD5504/AD5501 DAC SPI driver"
>   depends on SPI
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 63ae056..181fc28 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -11,6 +11,8 @@ obj-$(CONFIG_AD5064) += ad5064.o
>  obj-$(CONFIG_AD5504) += ad5504.o
>  obj-$(CONFIG_AD5446) += ad5446.o
>  obj-$(CONFIG_AD5449) += ad5449.o
> +obj-$(CONFIG_AD5592R) += ad5592r.o ad5592r-base.o
> +obj-$(CONFIG_AD5593R) += ad5593r.o ad5592r-base.o
Note the majority of distros will just enable anything and everything.  Hence
most of the time they'll both be built.  As such I'd prefer you to make
the minor mods needed to have a common base module rather than dublicating
the *-base.o object in both modules.

>  obj-$(CONFIG_AD5755) += ad5755.o
>  obj-$(CONFIG_AD5764) += ad5764.o
>  obj-$(CONFIG_AD5791) += ad5791.o
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
> new file mode 100644
> index 000..347f209
> --- /dev/null
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -0,0 +1,290 @@
> +/*
> + * AD5592R Digital <-> Analog converters driver
> + *
> + * Copyright 2014 Analog Devices Inc.
> + * Author: Paul Cercueil 
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +/*
> + * TODO:
> + * - Add support for using channels as GPIOs
> + */
> +
> +#include "ad5592r-base.h"
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int ad5592r_set_channel_modes(struct ad5592r_state *st)
> +{
> + const struct ad5592r_rw_ops *ops = st->ops;
> + int ret;
> + unsigned i;
> + struct iio_dev *iio_dev = iio_priv_to_dev(st);
> + u8 pulldown = 0, open_drain = 0, tristate = 0,
> +dac = 0, adc = 0, gpio_in = 0, gpio_out = 0;
> + u16 read_back;
> +
> + for (i = 0; i < st->chip_info->num_channels; i++) {
> + switch (st->channel_modes[i]) {
> + case CH_MODE_DAC:
> + dac |= BIT(i);
> +
> + /* fall-through */
> + case CH_MODE_ADC:
> + adc |= BIT(i);
> + break;
> +
> + case CH_MODE_GPIO_OUT:
> + gpio_out |= BIT(i);
> +
> + /* fall-through */
> + case CH_MODE_GPIO_IN:
> + gpio_in |= BIT(i);
> + break

Re: [PATCH v3 1/2] iio:light: Add Dyna-Image AP3223 ambient light and proximity driver

[Jonathan Cameron]

On 30/09/15 02:36, Suresh Rajashekara wrote:
> Minimal implementation with support for raw light and proximity reading.
> 
> This is based on the driver provided by the vendor
> (which was an input driver). Authors of the
> driver from the vendor included
> * John Huang 
> * Templeton Tsai 
> * Vic Lee 
> 
> v3
> * Resubmitting due to typo in accompanying patch
> 
> v2
> * Using regmap framework
> * Error handling
> * Code cleanups following comments
> 
> Signed-off-by: Suresh Rajashekara 
Fundamentally fine and heading in the right direction.
A lot of cases of eating error codes that should be returned and
a few other easy cleanups that will make it more readable and
easier to review.

Thanks,

Jonathan
> ---
>  drivers/iio/light/Kconfig  |  11 +
>  drivers/iio/light/Makefile |   1 +
>  drivers/iio/light/ap3223.c | 706 
> +
>  3 files changed, 718 insertions(+)
>  create mode 100644 drivers/iio/light/ap3223.c
> 
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index ae68c64..5c93ef0 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -27,6 +27,17 @@ config AL3320A
>To compile this driver as a module, choose M here: the
>module will be called al3320a.
>  
> +config AP3223
> + tristate "AP3223 ambient light and proximity sensor"
> + depends on I2C
> + select REGMAP_I2C
> + help
> +  Say Y here if you want to build a driver for the Dyna Image AP3223
> +  ambient light and proximity sensor.
> +
> +  To compile this driver as a module, choose M here: the
> +  module will be called ap3223.
> +
>  config APDS9300
>   tristate "APDS9300 ambient light sensor"
>   depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index b12a516..13a74f9 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -5,6 +5,7 @@
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_ADJD_S311)  += adjd_s311.o
>  obj-$(CONFIG_AL3320A)+= al3320a.o
> +obj-$(CONFIG_AP3223) += ap3223.o
>  obj-$(CONFIG_APDS9300)   += apds9300.o
>  obj-$(CONFIG_CM32181)+= cm32181.o
>  obj-$(CONFIG_CM3232) += cm3232.o
> diff --git a/drivers/iio/light/ap3223.c b/drivers/iio/light/ap3223.c
> new file mode 100644
> index 000..6b457c1
> --- /dev/null
> +++ b/drivers/iio/light/ap3223.c
> @@ -0,0 +1,706 @@
> +/*
> + * Copyright (C) 2015 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Note about the original authors:
> + *
> + * The driver for AP3223 was originally distributed by dyna image in a
> + * different framework (as an input driver). This driver uses code from
> + * that driver and converts it to iio framework. The non-iio driver from
> + * dyna image is not available online anywhere, so there is no reference
> + * for it here. However, that driver is also GPLv2.
> + * The following is part of the header found in that file
> + * (The GPL notice from the original header is removed)
> + *
> + * >> This file is part of the AP3223, AP3212C and AP3216C sensor driver.
> + * >> AP3426 is combined proximity and ambient light sensor.
> + * >> AP3216C is combined proximity, ambient light sensor and IRLED.
> + * >>
> + * >> Contact: John Huang 
> + * >>   Templeton Tsai 
> + *
> + * Another author initials mentioned in that file was just YC (and no name).
> + *
> + * Not sure for what kernel version the driver from dyna image was written 
> for.
> + * Vic Lee  made modifications to it to run on 3.14.
> + *
> + * Datasheet:
> + * 
> http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8#doc
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AP3223_DRV_NAME "ap3223"
> +
> +/* ap3223 control registers */
> +
> +#define  AP3223_REG_SYS_CTRL 0x00
> +#define AP3223_REG_SYS_CTRL_SHIFT(0)
> +#define AP3223_REG_SYS_CTRL_MASK 0x07
> +
> +/* System Mode (AP3223_REG_SYS_CTRL) */
> +
> +#define AP3223_SYS_DEV_DOWN  0x00
> +#define AP3223_SYS_ALS_ENABLE0x01
> +#define AP3223_SYS_PS_ENABLE 0x02
> +#define AP3223_SYS_ALS_PS_ENABLE 0x03
> +#define AP3223_SYS_DEV_RESET 0x04
> +
> +#define AP3223_REG_SYS_INTSTATUS 0x01
> +#define AP3223_REG_SYS_INT_SHIFT (0)
> +#define AP3223_REG_SYS_INT_

Re: [PATCHv2 1/2] iio: adc: Add TI ADS868X

[Jonathan Cameron]

On 28/09/15 17:26, Sean Nyekjær wrote:
> Hi
> 
> Just to clear thing up :-)
> 
> All the mess in the write_raw functions are from the allowed scales.
> if you are in ±0.625×Vref mode you are not allowed set an offset value of 0.
Ah.  Thanks for clarifying that.
> 
> INPUT RANGE POSITIVE FULL SCALE NEGATIVE FULL SCALE FULL-SCALE RANGE
> ±2.5 × V REF 10.24 V –10.24 V 20.48 V
> ±1.25 × V REF 5.12 V –5.12 V 10.24 V
> ±0.625 × V REF 2.56 V –2.56 V 5.12 V
> 0 to 2.5 × V REF 10.24 V 0V 10.24 V
> 0 to 1.25 × V REF 5.12 V 0V 5.12 V
> 
> I will update the driver with your comments :-)
> 
> /Sean
> 
> On 2015-09-27 16:38, Jonathan Cameron wrote:
>> On 25/09/15 07:29, Sean Nyekjaer wrote:
>>> This patch adds support for the Texas Intruments ADS868x ADC.
>>>
>>> Signed-off-by: Sean Nyekjaer 
>>> Reviewed-by: Martin Hundebøll 
>> Hi
>>
>> The driver is fundamentally good, but I think a few small changes would make
>> it less complex to read which is always a good thing!
>>
>> Comments inline.
>>
>> Jonathan
>>> ---
>>> Changes since v1:
>>> - Now possible to read and write the actual offset and scale values
>>> - Removed unused includes
>>> - Removed unused buffer references
>>>
>>>   drivers/iio/adc/Kconfig  |  10 +
>>>   drivers/iio/adc/Makefile |   1 +
>>>   drivers/iio/adc/ti-ads868x.c | 456 
>>> +++
>>>   3 files changed, 467 insertions(+)
>>>   create mode 100644 drivers/iio/adc/ti-ads868x.c
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index deea62c..39924d5 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -322,6 +322,16 @@ config TI_ADC128S052
>>> This driver can also be built as a module. If so, the module will be
>>> called ti-adc128s052.
>>>   +config TI_ADS868X
>>> +tristate "Texas Instruments ADS8684/8"
>>> +depends on SPI && OF
>>> +help
>>> +  If you say yes here you get support for Texas Instruments ADS8684 and
>>> +  and ADS8688 ADC chips
>>> +
>>> +  This driver can also be built as a module. If so, the module will be
>>> +  called ti-ads868x.
>>> +
>>>   config TI_AM335X_ADC
>>>   tristate "TI's AM335X ADC driver"
>>>   depends on MFD_TI_AM335X_TSCADC
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index fa5723a..75170d2 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>>   obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>>   obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>>> +obj-$(CONFIG_TI_ADS868X) += ti-ads868x.o
>>>   obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>>   obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>>>   obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>>> diff --git a/drivers/iio/adc/ti-ads868x.c b/drivers/iio/adc/ti-ads868x.c
>>> new file mode 100644
>>> index 000..66d9b64
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/ti-ads868x.c
>>> @@ -0,0 +1,456 @@
>>> +/*
>>> + * Copyright (C) 2015 Prevas A/S
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#define ADS868X_CMD_REG(x)(x << 8)
>>> +#define ADS868X_CMD_REG_NOOP0x00
>>> +#define ADS868X_CMD_REG_RST0x85
>>> +#define ADS868X_CMD_REG_MAN_CH(chan)(0xC0 | (4 * chan))
>>> +#define ADS868X_CMD_DONT_CARE_BITS16
>>> +
>>> +#define ADS868X_PROG_REG(x)(x << 9)
>>> +#define ADS868X_PROG_REG_RANGE_CH(chan)(0x05 + chan)
>>> +#define ADS868X_PROG_WR_BITBIT(8)
>>> +#define ADS868X_PROG_DONT_CARE_BITS8
>>> +
>>> +#define ADS868X_VREF_MV4096
>>> +#d

Re: [PATCH 2/3] iio:adc:palmas: add DT support

[Jonathan Cameron]

On 23/09/15 13:49, H. Nikolaus Schaller wrote:
> From: Marek Belisko 
> 
> Code was found at:
> https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1
> 
> Signed-off-by: Laxman Dewangan 
> [Fixed minor typos + add channels list to documentation]
> Signed-off-by: Marek Belisko 
Various commments inline.  You've run into the region of previous arguments
over driver bindings...  Mark Rutland, one for you to comment on as I know
you love our bindings ;) and yes we haven't done anything about them in two
years or so since you last moaned about them to me :(

> ---
> .../devicetree/bindings/iio/adc/palmas-gpadc.txt   |  67 +++
> drivers/iio/adc/palmas_gpadc.c | 130 +
> 2 files changed, 175 insertions(+), 22 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> new file mode 100644
> index 000..a5a33ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> @@ -0,0 +1,67 @@
> +* Palmas general purpose ADC IP block devicetree bindings
> +
> +Channels list:
> + 0 battery type
> +1 battery temp NTC
tab vs space fun.
> + 2 GP
> + 3 temp (with ext. diode)
> + 4 GP
> + 5 GP
> + 6 VBAT_SENSE
> + 7 VCC_SENSE
> + 8 Backup Battery voltage
> + 9 external charger (VCHG)
> + 10 VBUS
> + 11 DC-DC current probe (how does this work?)
> + 12 internal die temp
> + 13 internal die temp
> + 14 USB ID pin voltage
> + 15 test network
> +
> +Required properties:
> +- compatible : Must be "ti,palmas-gpadc".
> +
> +Optional sub-nodes:
> +ti,channel0-current-microamp: Channel 0 current in uA.
> + Valid values 0uA, 5uA, 15uA, 20uA.
> +ti,channel3-current-microamp: Channel 3 current in uA.
> + Valid value 0uA, 10uA, 400uA, 800uA.
> +ti,enable-channel3-dual-current: Enable dual current on channel 3.
> +ti,enable-extended-delay: Enable extended delay.
> +
> +Optional sub-node:
> +The Palmas ADC node has optional subnode to define the iio mapping.
> +It is the name with "iio_map". This node has again subnode to define
> +the property of the channel. The sub subnode has following properties:
> +- ti,adc-channel-number: ADC channel number.
> +- ti,adc-consumer-device: Consumer device name.
> +- ti,adc-consumer-channel: ADC consumer channel name.
> +
> +Example:
> +
> +pmic {
> + compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
> + ...
> + gpadc {
> + compatible = "ti,palmas-gpadc";
> + interrupts = <18 0
> +   16 0
> +   17 0>;
> + ti,channel0-current-microamp = <5>;
> + ti,channel3-current-microamp = <10>;
> + iio_map {
> + ch1 {
> + ti,adc-channel-number = <1>;
> + ti,adc-consumer-device = 
> "generic-adc-thermal.0";
> + ti,adc-consumer-channel ="battery-temp-channel";
> + };
> +
> + ch6 {
> + ti,adc-channel-number = <6>;
> + ti,adc-consumer-device = "palmas-battery";
> + ti,adc-consumer-channel ="vbat_channel";
> + };
See comments below.  There is an existing iio-consumer binding.
Various uses of it have caused complaints from the device tree guys in the
past.  I'd be interested to get their feedback on this use case.
> + };
> + };
> + ...
> +};
> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> index 17abb28..bc4db43 100644
> --- a/drivers/iio/adc/palmas_gpadc.c
> +++ b/drivers/iio/adc/palmas_gpadc.c
> @@ -20,6 +20,8 @@
> #include 
> #include 
> #include 
> +#include 
> +#include 
> #include 
> #include 
> #include 
> @@ -434,20 +436,97 @@ static const struct iio_chan_spec 
> palmas_gpadc_iio_channel[] = {
>   PALMAS_ADC_CHAN_IIO(IN15, IIO_VOLTAGE),
> };
> 
> +static int palmas_gpadc_get_adc_dt_data(struct platform_device *pdev,
> + struct palmas_gpadc_platform_data **gpadc_pdata)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct palmas_gpadc_platform_data *gp_data;
> + struct device_node *map_node;
> + struct device_node *child;
> + struct iio_map *palmas_iio_map;
> + int ret;
> + u32 pval;
> + int nmap, nvalid_map;
> +
> + gp_data = devm_kzalloc(&pdev->dev, sizeof(*gp_data), GFP_KERNEL);
> + if (!gp_data)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32(np, "ti,channel0-current-microamp", &pval);
> + if (!ret)
> + gp_data->ch0_current = pval;
> +
> + ret = of_property_read_u32(np, "ti,channel3-current-microamp", &pval);
> + if (!ret)
> + 

Re: [PATCH 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[Jonathan Cameron]

On 23/09/15 13:48, H. Nikolaus Schaller wrote:
> This driver code was found as:
> 
> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
> 
> Fixed various compilation issues and test this driver on omap5 evm.
> 
> Signed-off-by: Pradeep Goudagunta 
> Signed-off-by: H. Nikolaus Schaller 
> Signed-off-by: Marek Belisko 
Various bits inline.

Jonathan
> ---
> drivers/iio/adc/Kconfig|   9 +
> drivers/iio/adc/Makefile   |   1 +
> drivers/iio/adc/palmas_gpadc.c | 797 +
> include/linux/mfd/palmas.h |  59 ++-
> 4 files changed, 862 insertions(+), 4 deletions(-)
> create mode 100644 drivers/iio/adc/palmas_gpadc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index eb0cd89..f6df9db 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -242,6 +242,15 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
> 
> +config PALMAS_GPADC
> + tristate "TI Palmas General Purpose ADC"
> + depends on MFD_PALMAS
> + help
> +   Palmas series pmic chip by texas Instruments (twl6035/6037)
> +   is used in smartphones and tablets and supports a 16 channel
> +   general purpose ADC. Add iio driver to read different channel
> +   of the GPADCs.
> +
> config QCOM_SPMI_IADC
>   tristate "Qualcomm SPMI PMIC current ADC"
>   depends on SPMI
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index a096210..716f112 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> obj-$(CONFIG_NAU7802) += nau7802.o
> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
> obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> new file mode 100644
> index 000..17abb28
> --- /dev/null
> +++ b/drivers/iio/adc/palmas_gpadc.c
> @@ -0,0 +1,797 @@
> +/*
> + * palmas-adc.c -- TI PALMAS GPADC.
> + *
> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
> + *
> + * Author: Pradeep Goudagunta 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MOD_NAME "palmas-gpadc"
> +#define ADC_CONVERSION_TIMEOUT   (msecs_to_jiffies(5000))
> +#define TO_BE_CALCULATED 0
> +
> +struct palmas_gpadc_info {
> +/* calibration codes and regs */
Full docs on this would be appreciated.
> + int x1;
> + int x2;
> + int v1;
> + int v2;
> + u8 trim1_reg;
> + u8 trim2_reg;
> + int gain;
> + int offset;
> + int gain_error;
> + bool is_correct_code;
> +};
> +
> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
> _is_correct_code)\
> +[PALMAS_ADC_CH_##_chan] = {  \
> + .x1 = _x1,  \
> + .x2 = _x2,  \
> + .v1 = _v1,  \
> + .v2 = _v2,  \
> + .gain = TO_BE_CALCULATED,   \
> + .offset = TO_BE_CALCULATED, \
> + .gain_error = TO_BE_CALCULATED, \
> + .trim1_reg = PALMAS_GPADC_TRIM##_t1,\
> + .trim2_reg = PALMAS_GPADC_TRIM##_t2,\
> + .is_correct_code = _is_correct_code \
> + }
> +
> +static struct palmas_gpadc_info palmas_gpadc_info[] = {
> + PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
> + PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
> + PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
> + PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
> + PALMAS_ADC_INFO(IN4, 2064, 3112, 630, 950, 1, 2, false),
> + PALMAS_ADC_INFO(IN5, 2064, 3112, 630, 950, 1, 2, false),
> + PALMAS_ADC_INFO(IN6, 2064, 3112, 2520, 3800, 5, 6, false),
> + PALMAS_ADC_INFO(IN7, 2064, 3112, 2520, 3800, 7, 8, false),
> + PALMAS_ADC_INFO(IN8, 2064, 3112, 3150, 4750, 9, 10, false),
> + PALMAS_ADC_INFO(IN9, 2064, 3112, 5670, 8550, 11, 12, false),
> + PALMAS_ADC_INFO(IN10, 2064, 3112, 3465, 5225, 13, 14, false),
> + PALMAS_ADC_INFO(IN11, 0, 0, 0, 0, INVALI

Re: [PATCHv2 1/2] iio: adc: Add TI ADS868X

[Jonathan Cameron]

On 27/09/15 15:38, Jonathan Cameron wrote:
> On 25/09/15 07:29, Sean Nyekjaer wrote:
>> This patch adds support for the Texas Intruments ADS868x ADC.
>>
>> Signed-off-by: Sean Nyekjaer 
>> Reviewed-by: Martin Hundebøll 
> Hi
> 
> The driver is fundamentally good, but I think a few small changes would make
> it less complex to read which is always a good thing!
> 
> Comments inline.
> 
> Jonathan
I forgot to mention the general preference (we aren't as strict
as we should be on this) to not have wild cards in the name. TI might
be good and never release a new part that matches your string but not
the interface, but I think that is overly optimistic!

Hence, pick a part from your initially supported list and name it after
that (including all prefixes etc).

If you want an example of the sort of silliness that can occur with part
numbering take a look at the max1363 driver and imagine we'd slowly
generalized the naming of that using wildcards as new parts were added!

I suspect we'd now have maxx :)

Jonathan
>> ---
>> Changes since v1:
>> - Now possible to read and write the actual offset and scale values
>> - Removed unused includes
>> - Removed unused buffer references
>>
>>  drivers/iio/adc/Kconfig  |  10 +
>>  drivers/iio/adc/Makefile |   1 +
>>  drivers/iio/adc/ti-ads868x.c | 456 
>> +++
>>  3 files changed, 467 insertions(+)
>>  create mode 100644 drivers/iio/adc/ti-ads868x.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index deea62c..39924d5 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -322,6 +322,16 @@ config TI_ADC128S052
>>This driver can also be built as a module. If so, the module will be
>>called ti-adc128s052.
>>  
>> +config TI_ADS868X
>> +tristate "Texas Instruments ADS8684/8"
>> +depends on SPI && OF
>> +help
>> +  If you say yes here you get support for Texas Instruments ADS8684 and
>> +  and ADS8688 ADC chips
>> +
>> +  This driver can also be built as a module. If so, the module will be
>> +  called ti-ads868x.
>> +
>>  config TI_AM335X_ADC
>>  tristate "TI's AM335X ADC driver"
>>  depends on MFD_TI_AM335X_TSCADC
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index fa5723a..75170d2 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>> +obj-$(CONFIG_TI_ADS868X) += ti-ads868x.o
>>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>>  obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>> diff --git a/drivers/iio/adc/ti-ads868x.c b/drivers/iio/adc/ti-ads868x.c
>> new file mode 100644
>> index 000..66d9b64
>> --- /dev/null
>> +++ b/drivers/iio/adc/ti-ads868x.c
>> @@ -0,0 +1,456 @@
>> +/*
>> + * Copyright (C) 2015 Prevas A/S
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +#define ADS868X_CMD_REG(x)  (x << 8)
>> +#define ADS868X_CMD_REG_NOOP0x00
>> +#define ADS868X_CMD_REG_RST 0x85
>> +#define ADS868X_CMD_REG_MAN_CH(chan)(0xC0 | (4 * chan))
>> +#define ADS868X_CMD_DONT_CARE_BITS  16
>> +
>> +#define ADS868X_PROG_REG(x) (x << 9)
>> +#define ADS868X_PROG_REG_RANGE_CH(chan) (0x05 + chan)
>> +#define ADS868X_PROG_WR_BIT BIT(8)
>> +#define ADS868X_PROG_DONT_CARE_BITS 8
>> +
>> +#define ADS868X_VREF_MV 4096
>> +#define ADS868X_REALBITS16
>> +
>> +struct ads868x_chip_info {
>> +unsigned int id;
>> +const struct iio_chan_spec *channels;
>> +unsigned int num_channels;
>> +unsigned int flags;
> flags isn't used that I can see.
>> +const struct iio_info *iio_info;
> Why bother? Right now you only have one iio_info structure

Re: [PATCHv2 2/2] iio: ti-ads868x: Add DT binding documentation

[Jonathan Cameron]

On 25/09/15 07:29, Sean Nyekjaer wrote:
> Adding binding documentation for Texas Instruments ADS868X ADC.
> 
> Signed-off-by: Sean Nyekjaer 
> Reviewed-by: Martin Hundebøll 
> ---
>  .../devicetree/bindings/iio/adc/ti-ads868x.txt | 18 
> ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-ads868x.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/ti-ads868x.txt 
> b/Documentation/devicetree/bindings/iio/adc/ti-ads868x.txt
> new file mode 100644
> index 000..bc3c305
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ti-ads868x.txt
> @@ -0,0 +1,18 @@
> +* Texas Instruments' ADS8684 and ADS8688 ADC chip
> +
> +Required properties:
> + - compatible: Should be "ti,ads8684" or "ti,ads8688"
> + - reg: spi chip select number for the device
> + - vref-supply: The regulator supply for ADC reference voltage
In the driver it appears that this is optional rather than required.
Whether it is provided or not controls whether the external or internal
reference is used.
> +
> +Recommended properties:
> + - spi-max-frequency: Definition as per
> + Documentation/devicetree/bindings/spi/spi-bus.txt
> +
> +Example:
> +adc@0 {
> + compatible = "ti,ads8688";
> + reg = <0>;
> + vref-supply = <&vdd_supply>;
> + spi-max-frequency = <100>;
> +};
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] iio: adc: Add TI ADS868X

[Jonathan Cameron]

On 25/09/15 07:29, Sean Nyekjaer wrote:
> This patch adds support for the Texas Intruments ADS868x ADC.
> 
> Signed-off-by: Sean Nyekjaer 
> Reviewed-by: Martin Hundebøll 
Hi

The driver is fundamentally good, but I think a few small changes would make
it less complex to read which is always a good thing!

Comments inline.

Jonathan
> ---
> Changes since v1:
> - Now possible to read and write the actual offset and scale values
> - Removed unused includes
> - Removed unused buffer references
> 
>  drivers/iio/adc/Kconfig  |  10 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads868x.c | 456 
> +++
>  3 files changed, 467 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads868x.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index deea62c..39924d5 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -322,6 +322,16 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS868X
> + tristate "Texas Instruments ADS8684/8"
> + depends on SPI && OF
> + help
> +   If you say yes here you get support for Texas Instruments ADS8684 and
> +   and ADS8688 ADC chips
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads868x.
> +
>  config TI_AM335X_ADC
>   tristate "TI's AM335X ADC driver"
>   depends on MFD_TI_AM335X_TSCADC
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fa5723a..75170d2 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> +obj-$(CONFIG_TI_ADS868X) += ti-ads868x.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>  obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> diff --git a/drivers/iio/adc/ti-ads868x.c b/drivers/iio/adc/ti-ads868x.c
> new file mode 100644
> index 000..66d9b64
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads868x.c
> @@ -0,0 +1,456 @@
> +/*
> + * Copyright (C) 2015 Prevas A/S
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define ADS868X_CMD_REG(x)   (x << 8)
> +#define ADS868X_CMD_REG_NOOP 0x00
> +#define ADS868X_CMD_REG_RST  0x85
> +#define ADS868X_CMD_REG_MAN_CH(chan) (0xC0 | (4 * chan))
> +#define ADS868X_CMD_DONT_CARE_BITS   16
> +
> +#define ADS868X_PROG_REG(x)  (x << 9)
> +#define ADS868X_PROG_REG_RANGE_CH(chan)  (0x05 + chan)
> +#define ADS868X_PROG_WR_BIT  BIT(8)
> +#define ADS868X_PROG_DONT_CARE_BITS  8
> +
> +#define ADS868X_VREF_MV  4096
> +#define ADS868X_REALBITS 16
> +
> +struct ads868x_chip_info {
> + unsigned int id;
> + const struct iio_chan_spec *channels;
> + unsigned int num_channels;
> + unsigned int flags;
flags isn't used that I can see.
> + const struct iio_info *iio_info;
Why bother? Right now you only have one iio_info structure for both
supported parts.  Just use it directly and drop it form this structure.
> +};
> +
> +struct ads868x_state {
> + const struct ads868x_chip_info  *chip_info;
> + struct spi_device   *spi;
> + struct regulator*reg;
> + unsigned intvref_mv;
prefer u8 type to a char as it clearly isn't actually a character.

See below for more detail, but I'd suggest having a contiguous enum to
reference into the below ranges structure then store that in your
device instance specific structure rather than these values.
It avoids a fair bit of searching!  That would also change the type
of this to be an array of enums rather than u8/chars.

> + charrange[8];
> + union {
> + __be32 d32;
> + u8 d8[4];
> + } data[2] cacheline_aligned;
> +};
> +
> +enum ads868x_id {
> + ID_ADS8684,
> + ID_ADS8688,
> +};
> +
> +enum ads868x_range {
> + ADS868X_PLUSMINUS25VREF = 0x00,
> + ADS868X_PLUSMINUS125VREF= 0x01,
> + ADS868X_PLUSMINUS0625VREF   = 0x02,
> + ADS868X_PLUS25VREF  = 0x05,
> + ADS868X_PLUS125VREF = 0x06,
> +};
> +
> +struct ads868x_ranges {
> + enum ads868x_range range;
> + unsigned int scale;
> + int offset;
> +};
> +
const
> +static struct ads868x_ranges ads868x_range_def[5] = {
> + {
> + .range = ADS868X_PLUSMINUS25VREF,

Re: [v7 PATCH 1/2] iio: light: Add support for UPISEMI uS5182d als and proximity sensor

[Jonathan Cameron]

On 16/09/15 09:14, Adriana Reus wrote:
> Add support for UPISEMI us5182d als and proximity sensor.
> Supports raw readings.
> Data sheet for this device can be found here:
> http://www.upi-semi.com/temp/uS5182D-DS-P0103-temp.pdf
> 
> Signed-off-by: Adriana Reus 
Applied to the togreg branch of iio.git - initially pushed out
as testing for the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  No changes since v6
>  drivers/iio/light/Kconfig   |  10 +
>  drivers/iio/light/Makefile  |   1 +
>  drivers/iio/light/us5182d.c | 507 
> 
>  3 files changed, 518 insertions(+)
>  create mode 100644 drivers/iio/light/us5182d.c
> 
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 19b9a17..cfd3df8 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -300,6 +300,16 @@ config TSL4531
>To compile this driver as a module, choose M here: the
>module will be called tsl4531.
>  
> +config US5182D
> + tristate "UPISEMI light and proximity sensor"
> + depends on I2C
> + help
> +  If you say yes here you get support for the UPISEMI US5182D
> +  ambient light and proximity sensor.
> +
> +  This driver can also be built as a module.  If so, the module
> +  will be called us5182d.
> +
>  config VCNL4000
>   tristate "VCNL4000 combined ALS and proximity sensor"
>   depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index 7b22445..b2c3105 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -28,4 +28,5 @@ obj-$(CONFIG_STK3310)  += stk3310.o
>  obj-$(CONFIG_TCS3414)+= tcs3414.o
>  obj-$(CONFIG_TCS3472)+= tcs3472.o
>  obj-$(CONFIG_TSL4531)+= tsl4531.o
> +obj-$(CONFIG_US5182D)+= us5182d.o
>  obj-$(CONFIG_VCNL4000)   += vcnl4000.o
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> new file mode 100644
> index 000..49dab3c
> --- /dev/null
> +++ b/drivers/iio/light/us5182d.c
> @@ -0,0 +1,507 @@
> +/*
> + * Copyright (c) 2015 Intel Corporation
> + *
> + * Driver for UPISEMI us5182d Proximity and Ambient Light Sensor.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * To do: Interrupt support.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define US5182D_REG_CFG0 0x00
> +#define US5182D_CFG0_ONESHOT_EN  BIT(6)
> +#define US5182D_CFG0_SHUTDOWN_EN BIT(7)
> +#define US5182D_CFG0_WORD_ENABLE BIT(0)
> +
> +#define US5182D_REG_CFG1 0x01
> +#define US5182D_CFG1_ALS_RES16   BIT(4)
> +#define US5182D_CFG1_AGAIN_DEFAULT   0x00
> +
> +#define US5182D_REG_CFG2 0x02
> +#define US5182D_CFG2_PX_RES16BIT(4)
> +#define US5182D_CFG2_PXGAIN_DEFAULT  BIT(2)
> +
> +#define US5182D_REG_CFG3 0x03
> +#define US5182D_CFG3_LED_CURRENT100  (BIT(4) | BIT(5))
> +
> +#define US5182D_REG_CFG4 0x10
> +
> +/*
> + * Registers for tuning the auto dark current cancelling feature.
> + * DARK_TH(reg 0x27,0x28) - threshold (counts) for auto dark cancelling.
> + * when ALS  > DARK_TH --> ALS_Code = ALS - Upper(0x2A) * Dark
> + * when ALS < DARK_TH --> ALS_Code = ALS - Lower(0x29) * Dark
> + */
> +#define US5182D_REG_UDARK_TH 0x27
> +#define US5182D_REG_DARK_AUTO_EN 0x2b
> +#define US5182D_REG_AUTO_LDARK_GAIN  0x29
> +#define US5182D_REG_AUTO_HDARK_GAIN  0x2a
> +
> +#define US5182D_OPMODE_ALS   0x01
> +#define US5182D_OPMODE_PX0x02
> +#define US5182D_OPMODE_SHIFT 4
> +
> +#define US5182D_REG_DARK_AUTO_EN_DEFAULT 0x80
> +#define US5182D_REG_AUTO_LDARK_GAIN_DEFAULT  0x16
> +#define US5182D_REG_AUTO_HDARK_GAIN_DEFAULT  0x00
> +
> +#define US5182D_REG_ADL  0x0c
> +#define US5182D_REG_PDL  0x0e
> +
> +#define US5182D_REG_MODE_STORE   0x21
> +#define US5182D_STORE_MODE   0x01
> +
> +#define US5182D_REG_CHIPID   0xb2
> +
> +#define US5182D_OPMODE_MASK  GENMASK(5, 4)
> +#define US5182D_AGAIN_MASK   0x07
> +#define US5182D_RES

Re: [v7 PATCH 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor

[Jonathan Cameron]

On 21/09/15 16:02, Rob Herring wrote:
> On 09/16/2015 03:14 AM, Adriana Reus wrote:
>> Added entries in i2c/vendor-prefixes for the us5182d als and proximity 
>> sensor.
>> Also added a documentation file for this sensor's properties.
>>
>> Signed-off-by: Adriana Reus 
>> ---
>>  Changes since v6:
>>  * Added some aditional clarifications on the optional
>>properties, as suggested by Rob.
> 
> Acked-by: Rob Herring 
Thanks. Applied to the togreg branch of iio.git - initially pushed out
as testing for the autobuilders to play with it.

Jonathan
> 
>>
>>  .../devicetree/bindings/iio/light/us5182d.txt  | 34 
>> ++
>>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>>  2 files changed, 35 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt 
>> b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>> new file mode 100644
>> index 000..6f0a530
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>> @@ -0,0 +1,34 @@
>> +* UPISEMI us5182d I2C ALS and Proximity sensor
>> +
>> +Required properties:
>> +- compatible: must be "upisemi,usd5182"
>> +- reg: the I2C address of the device
>> +
>> +Optional properties:
>> +- upisemi,glass-coef: glass attenuation factor - compensation factor of
>> +  resolution 1000 for material transmittance.
>> +- upisemi,dark-ths: array of 8 elements containing 16-bit thresholds (adc
>> +counts) corresponding to every scale.
>> +- upisemi,upper-dark-gain: 8-bit dark gain compensation factor(4 int and 4
>> +   fractional bits - Q4.4) applied when light > 
>> threshold
>> +- upisemi,lower-dark-gain: 8-bit dark gain compensation factor(4 int and 4
>> +   fractional bits - Q4.4) applied when light < 
>> threshold
>> +
>> +If the optional properties are not specified these factors will default to 
>> the
>> +values in the below example.
>> +The glass-coef defaults to no compensation for the covering material.
>> +The threshold array defaults to experimental values that work with US5182D
>> +sensor on evaluation board - roughly between 12-32 lux.
>> +There will be no dark-gain compensation by default when ALS > thresh
>> +(0 * dark-gain), and a 1.35 compensation factor when ALS < thresh.
>> +
>> +Example:
>> +
>> +usd5182@39 {
>> +compatible = "upisemi,usd5182";
>> +reg = <0x39>;
>> +upisemi,glass-coef = < 1000 >;
>> +upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 
>> 8000>;
>> +upisemi,upper-dark-gain = /bits/ 8 <0x00>;
>> +upisemi,lower-dark-gain = /bits/ 8 <0x16>;
>> +};
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 341695b..85ba915 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -213,6 +213,7 @@ toshiba  Toshiba Corporation
>>  toumaz  Toumaz
>>  tplink  TP-LINK Technologies Co., Ltd.
>>  truly   Truly Semiconductors Limited
>> +upisemi uPI Semiconductor Corp.
>>  usi Universal Scientific Industrial Co., Ltd.
>>  v3  V3 Semiconductor
>>  variscite   Variscite Ltd.
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/4] devicetree: add SGX Sensortech vendor id

[Jonathan Cameron]

On 14/09/15 04:26, Matt Ranostay wrote:
> Signed-off-by: Matt Ranostay 
Applied. Note there was fuzz in my tree as I am lagging mainline
somewhat.  However it is pretty obvious how to fix up merge
issues in this file so lets not worry about that ;)

Jonathan
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index ac5f0c3..281e8f0 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -191,6 +191,7 @@ sbs   Smart Battery System
>  schindlerSchindler
>  seagate  Seagate Technology PLC
>  semtech  Semtech Corporation
> +sgx  SGX Sensortech
>  sharpSharp Corporation
>  sil  Silicon Image
>  silabs   Silicon Laboratories
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] iio: chemical: Add IIO_CONCENTRATION channel type

[Jonathan Cameron]

On 14/09/15 04:26, Matt Ranostay wrote:
> There are air quality sensors that report data back in parts per million
> of VOC (Volatile Organic Compounds) which are usually indexed from CO2
> or another common pollutant.
> 
> This patchset adds an IIO_CONCENTRATION type that returns a percentage
> of substance because no other channels types fit this use case.
> Modifiers for IIO_MOD_CO2 and IIO_MOD_VOC gas types are defined.
> 
> Signed-off-by: Matt Ranostay 
Applied to the togreg branch of iio.git - initially pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 11 +++
>  drivers/iio/industrialio-core.c |  3 +++
>  include/uapi/linux/iio/types.h  |  3 +++
>  3 files changed, 17 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 42d360f..682c070 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1459,3 +1459,14 @@ Description:
>   measurements and return the average value as output data. Each
>   value resulted from [_name]_oversampling_ratio 
> measurements
>   is considered as one sample for 
> [_name]_sampling_frequency.
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_concentration_raw
> +What:/sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
> +KernelVersion:   4.3
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Raw (unscaled no offset etc.) percentage reading of a substance.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index b3fcc2c..8eb6064 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -75,6 +75,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   [IIO_ENERGY] = "energy",
>   [IIO_DISTANCE] = "distance",
>   [IIO_VELOCITY] = "velocity",
> + [IIO_CONCENTRATION] = "concentration",
>  };
>  
>  static const char * const iio_modifier_names[] = {
> @@ -111,6 +112,8 @@ static const char * const iio_modifier_names[] = {
>   [IIO_MOD_ROOT_SUM_SQUARED_X_Y_Z] = "sqrt(x^2+y^2+z^2)",
>   [IIO_MOD_I] = "i",
>   [IIO_MOD_Q] = "q",
> + [IIO_MOD_CO2] = "co2",
> + [IIO_MOD_VOC] = "voc",
>  };
>  
>  /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 2f8b117..1e4c4e3 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -35,6 +35,7 @@ enum iio_chan_type {
>   IIO_ENERGY,
>   IIO_DISTANCE,
>   IIO_VELOCITY,
> + IIO_CONCENTRATION,
>  };
>  
>  enum iio_modifier {
> @@ -72,6 +73,8 @@ enum iio_modifier {
>   IIO_MOD_ROOT_SUM_SQUARED_X_Y_Z,
>   IIO_MOD_I,
>   IIO_MOD_Q,
> + IIO_MOD_CO2,
> + IIO_MOD_VOC,
>  };
>  
>  enum iio_event_type {
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/4] iio: resistance: add IIO_RESISTANCE channel type

[Jonathan Cameron]

On 14/09/15 04:26, Matt Ranostay wrote:
> Signed-off-by: Matt Ranostay 
Applied to the togreg branch of iio.git - initially pushed out as testing for 
the
autobuilders to play with it.

Thanks,

Jonathan
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 8 
>  drivers/iio/industrialio-core.c | 1 +
>  include/uapi/linux/iio/types.h  | 1 +
>  3 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 682c070..a91af51 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1470,3 +1470,11 @@ KernelVersion: 4.3
>  Contact: linux-...@vger.kernel.org
>  Description:
>   Raw (unscaled no offset etc.) percentage reading of a substance.
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_resistance_raw
> +What:/sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
> +KernelVersion:   4.3
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Raw (unscaled no offset etc.) resistance reading that can be 
> processed
> + into an ohm value.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 8eb6064..80439a6 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -76,6 +76,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   [IIO_DISTANCE] = "distance",
>   [IIO_VELOCITY] = "velocity",
>   [IIO_CONCENTRATION] = "concentration",
> + [IIO_RESISTANCE] = "resistance",
>  };
>  
>  static const char * const iio_modifier_names[] = {
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 1e4c4e3..7c63bd6 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -36,6 +36,7 @@ enum iio_chan_type {
>   IIO_DISTANCE,
>   IIO_VELOCITY,
>   IIO_CONCENTRATION,
> + IIO_RESISTANCE,
>  };
>  
>  enum iio_modifier {
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] iio: mma8452: leave sysfs namings to the iio core

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> This doesn't actually change anything since the core names the sysfs folder
> for the iio event attributes "events" anyways. It only leaves the job to the
> core.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Applied to the togreg branch of iio.git - initially pushed out as testing for 
the
autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/iio/accel/mma8452.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 15d50c9..1eccc2d 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -772,7 +772,6 @@ static struct attribute *mma8452_event_attributes[] = {
>  
>  static struct attribute_group mma8452_event_attribute_group = {
>   .attrs = mma8452_event_attributes,
> - .name = "events",
>  };
>  
>  #define MMA8452_CHANNEL(axis, idx, bits) { \
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6] iio: mma8452: add copyright notice comment

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Applied.
> ---
>  drivers/iio/accel/mma8452.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 59b4455..15d50c9 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -6,6 +6,7 @@
>   * MMA8652FC (12 bit)
>   * MMA8653FC (10 bit)
>   *
> + * Copyright 2015 Martin Kepplinger 
>   * Copyright 2014 Peter Meerwald 
>   *
>   * This file is subject to the terms and conditions of version 2 of
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] iio: mma8452: add support for MMA8652FC and MMA8653FC

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> MMA8652FC and MMA8653FC don't provide the transient interrupt source, so
> the motion interrupt source is used by providing a new iio_chan_spec
> definition, so that other supported devices are not affected by this.
> 
> Datasheets for the newly supported devices are available at Freescale's
> website:
> 
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8652FC.pdf
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8653FC.pdf
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Applied.
> ---
>  .../devicetree/bindings/iio/accel/mma8452.txt  |  4 +-
>  drivers/iio/accel/Kconfig  |  2 +-
>  drivers/iio/accel/mma8452.c| 98 
> --
>  3 files changed, 95 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> index c3bc272..e3c3746 100644
> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -1,10 +1,12 @@
> -Freescale MMA8452Q or MMA8453Q triaxial accelerometer
> +Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
>  
>  Required properties:
>  
>- compatible: should contain one of
>  * "fsl,mma8452"
>  * "fsl,mma8453"
> +* "fsl,mma8652"
> +* "fsl,mma8653"
>- reg: the I2C address of the chip
>  
>  Optional properties:
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index e4075a0..a37155d 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -106,7 +106,7 @@ config MMA8452
>   select IIO_TRIGGERED_BUFFER
>   help
> Say yes here to build support for the following Freescale 3-axis
> -   accelerometers: MMA8452Q, MMA8453Q.
> +   accelerometers: MMA8452Q, MMA8453Q, MMA8652FC, MMA8653FC.
>  
> To compile this driver as a module, choose M here: the module
> will be called mma8452.
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 6b1a862..59b4455 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -3,6 +3,8 @@
>   *
>   * MMA8452Q (12 bit)
>   * MMA8453Q (10 bit)
> + * MMA8652FC (12 bit)
> + * MMA8653FC (10 bit)
>   *
>   * Copyright 2014 Peter Meerwald 
>   *
> @@ -84,6 +86,8 @@
>  
>  #define  MMA8452_DEVICE_ID   0x2a
>  #define  MMA8453_DEVICE_ID   0x3a
> +#define MMA8652_DEVICE_ID0x4a
> +#define MMA8653_DEVICE_ID0x5a
>  
>  struct mma8452_data {
>   struct i2c_client *client;
> @@ -791,6 +795,26 @@ static struct attribute_group 
> mma8452_event_attribute_group = {
>   .num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
>  }
>  
> +#define MMA8652_CHANNEL(axis, idx, bits) { \
> + .type = IIO_ACCEL, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_CALIBBIAS), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .scan_index = idx, \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = (bits), \
> + .storagebits = 16, \
> + .shift = 16 - (bits), \
> + .endianness = IIO_BE, \
> + }, \
> + .event_spec = mma8452_motion_event, \
> + .num_event_specs = ARRAY_SIZE(mma8452_motion_event), \
> +}
> +
>  static const struct iio_chan_spec mma8452_channels[] = {
>   MMA8452_CHANNEL(X, 0, 12),
>   MMA8452_CHANNEL(Y, 1, 12),
> @@ -805,9 +829,25 @@ static const struct iio_chan_spec mma8453_channels[] = {
>   IIO_CHAN_SOFT_TIMESTAMP(3),
>  };
>  
> +static const struct iio_chan_spec mma8652_channels[] = {
> + MMA8652_CHANNEL(X, 0, 12),
> + MMA8652_CHANNEL(Y, 1, 12),
> + MMA8652_CHANNEL(Z, 2, 12),
> + IIO_CHAN_SOFT_TIMESTAMP(3),
> +};
> +
> +static const struct iio_chan_spec mma8653_channels[] = {
> + MMA8652_CHANNEL(X, 0, 10),
> + MMA8652_CHANNEL(Y, 1, 10),
> + MMA8652_CHANNEL(Z, 2, 10),
> + IIO_CHAN_SOFT_TIMESTAMP(3),
> +};
> +
>  enum {
>   mma8452,
>   mma8453,
> + mma8652,
> + mma8653,
>  };
>  
>  static const struct mma_chip_info mma_chip_info_table[] = {
> @@ -850,6 +890,38 @@ static const struct mma_chip_info mma_chip_info_table[] 
> = {
>   .ev_ths_mask = MMA8452_TRANSIENT_THS_MASK,
>   .ev_count = MMA8452_TRANSIENT_COUNT,
>   },
> + [mma8652] = {
> + .chip_id = MMA8652_DEVICE_ID,
> + .channels = mma8652_channels,
> + .num_channels = ARRAY_SIZE(mma8652_channels),
> + .mma_scales = { {0, 9577}, {0, 19154}, {0, 38307} },
> + .ev_cfg = MMA8452_FF_MT_CFG,
> + .ev_cfg_ele = MMA8452_FF_

Re: [PATCH 3/6] iio: mma8452: add freefall / motion interrupt source

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds the freefall / motion interrupt source definitions to the driver.
> It is used in this series' next patch, for chips that don't support the
> transient interrupt source.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Applied.
> ---
>  drivers/iio/accel/mma8452.c | 44 
>  1 file changed, 36 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 7b2ab17..6b1a862 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -42,6 +42,16 @@
>  #define  MMA8452_DATA_CFG_HPF_MASK   BIT(4)
>  #define MMA8452_HP_FILTER_CUTOFF 0x0f
>  #define  MMA8452_HP_FILTER_CUTOFF_SEL_MASK   GENMASK(1, 0)
> +#define MMA8452_FF_MT_CFG0x15
> +#define  MMA8452_FF_MT_CFG_OAE   BIT(6)
> +#define  MMA8452_FF_MT_CFG_ELE   BIT(7)
> +#define MMA8452_FF_MT_SRC0x16
> +#define  MMA8452_FF_MT_SRC_XHE   BIT(1)
> +#define  MMA8452_FF_MT_SRC_YHE   BIT(3)
> +#define  MMA8452_FF_MT_SRC_ZHE   BIT(5)
> +#define MMA8452_FF_MT_THS0x17
> +#define  MMA8452_FF_MT_THS_MASK  0x7f
> +#define MMA8452_FF_MT_COUNT  0x18
>  #define MMA8452_TRANSIENT_CFG0x1d
>  #define  MMA8452_TRANSIENT_CFG_HPF_BYP   BIT(0)
>  #define  MMA8452_TRANSIENT_CFG_CHAN(chan)BIT(chan + 1)
> @@ -69,6 +79,7 @@
>  #define MMA8452_MAX_REG  0x31
>  
>  #define  MMA8452_INT_DRDYBIT(0)
> +#define  MMA8452_INT_FF_MT   BIT(2)
>  #define  MMA8452_INT_TRANS   BIT(5)
>  
>  #define  MMA8452_DEVICE_ID   0x2a
> @@ -613,7 +624,8 @@ static int mma8452_write_event_config(struct iio_dev 
> *indio_dev,
>   else
>   val &= ~BIT(chan->scan_index + chip->ev_cfg_chan_shift);
>  
> - val |= MMA8452_TRANSIENT_CFG_ELE;
> + val |= chip->ev_cfg_ele;
> + val |= MMA8452_FF_MT_CFG_OAE;
>  
>   return mma8452_change_config(data, chip->ev_cfg, val);
>  }
> @@ -654,6 +666,7 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
>  {
>   struct iio_dev *indio_dev = p;
>   struct mma8452_data *data = iio_priv(indio_dev);
> + const struct mma_chip_info *chip = data->chip_info;
>   int ret = IRQ_NONE;
>   int src;
>  
> @@ -666,7 +679,10 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
>   ret = IRQ_HANDLED;
>   }
>  
> - if (src & MMA8452_INT_TRANS) {
> + if ((src & MMA8452_INT_TRANS &&
> +  chip->ev_src == MMA8452_TRANSIENT_SRC) ||
> + (src & MMA8452_INT_FF_MT &&
> +  chip->ev_src == MMA8452_FF_MT_SRC)) {
>   mma8452_transient_interrupt(indio_dev);
>   ret = IRQ_HANDLED;
>   }
> @@ -728,6 +744,16 @@ static const struct iio_event_spec 
> mma8452_transient_event[] = {
>   },
>  };
>  
> +static const struct iio_event_spec mma8452_motion_event[] = {
> + {
> + .type = IIO_EV_TYPE_MAG,
> + .dir = IIO_EV_DIR_RISING,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> + .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_PERIOD)
> + },
> +};
> +
>  /*
>   * Threshold is configured in fixed 8G/127 steps regardless of
>   * currently selected scale for measurement.
> @@ -1013,13 +1039,15 @@ static int mma8452_probe(struct i2c_client *client,
>  
>   if (client->irq) {
>   /*
> -  * Although we enable the transient interrupt source once and
> -  * for all here the transient event detection itself is not
> -  * enabled until userspace asks for it by
> -  * mma8452_write_event_config()
> +  * Although we enable the interrupt sources once and for
> +  * all here the event detection itself is not enabled until
> +  * userspace asks for it by mma8452_write_event_config()
>*/
> - int supported_interrupts = MMA8452_INT_DRDY | MMA8452_INT_TRANS;
> - int enabled_interrupts = MMA8452_INT_TRANS;
> + int supported_interrupts = MMA8452_INT_DRDY |
> +MMA8452_INT_TRANS |
> +MMA8452_INT_FF_MT;
> + int enabled_interrupts = MMA8452_INT_TRANS |
> +  MMA8452_INT_FF_MT;
>  
>   /* Assume wired to INT1 pin */
>   ret = i2c_smbus_write_byte_data(client,
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] iio: mma8452: add support for MMA8453Q accelerometer chip

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds support for the 10 bit version if Freescale's accelerometers
> of this series. The datasheet is available at Freescale's website:
> 
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8453Q.pdf
> 
> It creates a devicetree bindings file to document the new functionality
> and removes the driver from the trivial-devices list.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Applied.
> ---
>  .../devicetree/bindings/i2c/trivial-devices.txt|  1 -
>  .../devicetree/bindings/iio/accel/mma8452.txt  | 22 +
>  drivers/iio/accel/Kconfig  |  6 ++--
>  drivers/iio/accel/mma8452.c| 37 
> --
>  4 files changed, 59 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/iio/accel/mma8452.txt
> 
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index d77d412..a50e56d 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -54,7 +54,6 @@ epson,rx8581I2C-BUS INTERFACE REAL TIME 
> CLOCK MODULE
>  fsl,mag3110  MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
>  fsl,mc13892  MC13892: Power Management Integrated Circuit (PMIC) for 
> i.MX35/51
>  fsl,mma8450  MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic 
> Accelerometer
> -fsl,mma8452  MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer
>  fsl,mpr121   MPR121: Proximity Capacitive Touch Sensor Controller
>  fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
>  gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog 
> with Two-Wire Interface
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> new file mode 100644
> index 000..c3bc272
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -0,0 +1,22 @@
> +Freescale MMA8452Q or MMA8453Q triaxial accelerometer
> +
> +Required properties:
> +
> +  - compatible: should contain one of
> +* "fsl,mma8452"
> +* "fsl,mma8453"
> +  - reg: the I2C address of the chip
> +
> +Optional properties:
> +
> +  - interrupt-parent: should be the phandle for the interrupt controller
> +  - interrupts: interrupt mapping for GPIO IRQ
> +
> +Example:
> +
> + mma8453fc@1d {
> + compatible = "fsl,mma8453";
> + reg = <0x1d>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <5 0>;
> + };
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index a59047d..e4075a0 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -100,13 +100,13 @@ config KXCJK1013
> be called kxcjk-1013.
>  
>  config MMA8452
> - tristate "Freescale MMA8452Q Accelerometer Driver"
> + tristate "Freescale MMA8452Q and similar Accelerometers Driver"
>   depends on I2C
>   select IIO_BUFFER
>   select IIO_TRIGGERED_BUFFER
>   help
> -   Say yes here to build support for the Freescale MMA8452Q 3-axis
> -   accelerometer.
> +   Say yes here to build support for the following Freescale 3-axis
> +   accelerometers: MMA8452Q, MMA8453Q.
>  
> To compile this driver as a module, choose M here: the module
> will be called mma8452.
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index f28428fa..7b2ab17 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1,5 +1,8 @@
>  /*
> - * mma8452.c - Support for Freescale MMA8452Q 3-axis 12-bit accelerometer
> + * mma8452.c - Support for following Freescale 3-axis accelerometers:
> + *
> + * MMA8452Q (12 bit)
> + * MMA8453Q (10 bit)
>   *
>   * Copyright 2014 Peter Meerwald 
>   *
> @@ -26,7 +29,7 @@
>  
>  #define MMA8452_STATUS   0x00
>  #define  MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> -#define MMA8452_OUT_X0x01 /* MSB first, 
> 12-bit  */
> +#define MMA8452_OUT_X0x01 /* MSB first */
>  #define MMA8452_OUT_Y0x03
>  #define MMA8452_OUT_Z0x05
>  #define MMA8452_INT_SRC  0x0c
> @@ -69,6 +72,7 @@
>  #define  MMA8452_INT_TRANS   BIT(5)
>  
>  #define  MMA8452_DEVICE_ID   0x2a
> +#define  MMA8453_DEVICE_ID   0x3a
>  
>  struct mma8452_data {
>   struct i2c_client *client;
> @@ -768,8 +772,16 @@ static const struct iio_chan_spec mma8452_channels[] = {
>   IIO_CHAN_SOFT_TIMESTAMP(3),
>  };
>  
> +static const struct iio_chan_spec mma8453_channels[] = {
> + MMA8452_CHANNEL(X, 0, 10),
> + MMA8

Re: [PATCH 1/6] iio: mma8452: refactor for seperating chip specific data

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds a struct mma_chip_info to hold data that will remain specific to
> the chip in use. It is provided during probe() and linked in
> struct of_device_id.
> 
> Also this suggests that the driver is called "mma8452" and now handles the
> MMA8452Q device, but is not limited to it.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Applied to the togreg branch of iio.git.  Initially pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/iio/accel/mma8452.c | 183 
> 
>  1 file changed, 134 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index b921d84..f28428fa 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define MMA8452_STATUS   0x00
>  #define  MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> @@ -74,6 +75,52 @@ struct mma8452_data {
>   struct mutex lock;
>   u8 ctrl_reg1;
>   u8 data_cfg;
> + const struct mma_chip_info *chip_info;
> +};
> +
> +/**
> + * struct mma_chip_info - chip specific data for Freescale's accelerometers
> + * @chip_id: WHO_AM_I register's value
> + * @channels:struct iio_chan_spec matching the 
> device's
> + *   capabilities
> + * @num_channels:number of channels
> + * @mma_scales:  scale factors for converting register 
> values
> + *   to m/s^2; 3 modes: 2g, 4g, 8g; 2 integers
> + *   per mode: m/s^2 and micro m/s^2
> + * @ev_cfg:  event config register address
> + * @ev_cfg_ele:  latch bit in event config register
> + * @ev_cfg_chan_shift:   number of the bit to enable events in X
> + *   direction; in event config register
> + * @ev_src:  event source register address
> + * @ev_src_xe:   bit in event source register that 
> indicates
> + *   an event in X direction
> + * @ev_src_ye:   bit in event source register that 
> indicates
> + *   an event in Y direction
> + * @ev_src_ze:   bit in event source register that 
> indicates
> + *   an event in Z direction
> + * @ev_ths:  event threshold register address
> + * @ev_ths_mask: mask for the threshold value
> + * @ev_count:event count (period) register address
> + *
> + * Since not all chips supported by the driver support comparing high pass
> + * filtered data for events (interrupts), different interrupt sources are
> + * used for different chips and the relevant registers are included here.
> + */
> +struct mma_chip_info {
> + u8 chip_id;
> + const struct iio_chan_spec *channels;
> + int num_channels;
> + const int mma_scales[3][2];
> + u8 ev_cfg;
> + u8 ev_cfg_ele;
> + u8 ev_cfg_chan_shift;
> + u8 ev_src;
> + u8 ev_src_xe;
> + u8 ev_src_ye;
> + u8 ev_src_ze;
> + u8 ev_ths;
> + u8 ev_ths_mask;
> + u8 ev_count;
>  };
>  
>  static int mma8452_drdy(struct mma8452_data *data)
> @@ -143,16 +190,6 @@ static const int mma8452_samp_freq[8][2] = {
>   {6, 25}, {1, 56}
>  };
>  
> -/*
> - * Hardware has fullscale of -2G, -4G, -8G corresponding to raw value -2048
> - * The userspace interface uses m/s^2 and we declare micro units
> - * So scale factor is given by:
> - *   g * N * 100 / 2048 for N = 2, 4, 8 and g = 9.80665
> - */
> -static const int mma8452_scales[3][2] = {
> - {0, 9577}, {0, 19154}, {0, 38307}
> -};
> -
>  /* Datasheet table 35  (step time vs sample frequency) */
>  static const int mma8452_transient_time_step_us[8] = {
>   1250,
> @@ -189,8 +226,11 @@ static ssize_t mma8452_show_scale_avail(struct device 
> *dev,
>   struct device_attribute *attr,
>   char *buf)
>  {
> - return mma8452_show_int_plus_micros(buf, mma8452_scales,
> - ARRAY_SIZE(mma8452_scales));
> + struct mma8452_data *data = iio_priv(i2c_get_clientdata(
> +  to_i2c_client(dev)));
> +
> + return mma8452_show_int_plus_micros(buf, data->chip_info->mma_scales,
> + ARRAY_SIZE(data->chip_info->mma_scales));
>  }
>  
>  static ssize_t mma8452_show_hp_cutoff_avail(struct device *dev,
> @@ -221,9 +261,8 @@ static int mma8452_get_samp_freq_index(struct 
> mma8452_data *data,
>  
>  static int mma8452_get_scale_index(struct mma8452_data *data, int val, int 
> val2)
>  {
> - return mma8452_get_int_plus_micros_index(mm

Re: [PATCH 6/6] iio: mma8452: leave sysfs namings to the iio core

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> This doesn't actually change anything since the core names the sysfs folder
> for the iio event attributes "events" anyways. It only leaves the job to the
> core.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Good point.  I wonder if we have others of these in the tree.

Anyhow, an excellent patch set.  As I've said, I'll pick them up in
perhaps a week if Peter or someone else hasn't intervened in the meantime.

Give me a poke if I don't seem to be doing so!

Jonathan
> ---
>  drivers/iio/accel/mma8452.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 15d50c9..1eccc2d 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -772,7 +772,6 @@ static struct attribute *mma8452_event_attributes[] = {
>  
>  static struct attribute_group mma8452_event_attribute_group = {
>   .attrs = mma8452_event_attributes,
> - .name = "events",
>  };
>  
>  #define MMA8452_CHANNEL(axis, idx, bits) { \
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] iio: mma8452: add support for MMA8652FC and MMA8653FC

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> MMA8652FC and MMA8653FC don't provide the transient interrupt source, so
> the motion interrupt source is used by providing a new iio_chan_spec
> definition, so that other supported devices are not affected by this.
> 
> Datasheets for the newly supported devices are available at Freescale's
> website:
> 
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8652FC.pdf
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8653FC.pdf
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
One comment inline, but I'm arguing in favour of the approach you have
taken so don't worry about that!

Another nice clean focused patch.

(note I'm marking all of them as to be applied in my email archive so
if no one else chips in they'll probably get picked up next weekend.)

Jonathan
> ---
>  .../devicetree/bindings/iio/accel/mma8452.txt  |  4 +-
>  drivers/iio/accel/Kconfig  |  2 +-
>  drivers/iio/accel/mma8452.c| 98 
> --
>  3 files changed, 95 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> index c3bc272..e3c3746 100644
> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -1,10 +1,12 @@
> -Freescale MMA8452Q or MMA8453Q triaxial accelerometer
> +Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
>  
>  Required properties:
>  
>- compatible: should contain one of
>  * "fsl,mma8452"
>  * "fsl,mma8453"
> +* "fsl,mma8652"
> +* "fsl,mma8653"
>- reg: the I2C address of the chip
>  
>  Optional properties:
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index e4075a0..a37155d 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -106,7 +106,7 @@ config MMA8452
>   select IIO_TRIGGERED_BUFFER
>   help
> Say yes here to build support for the following Freescale 3-axis
> -   accelerometers: MMA8452Q, MMA8453Q.
> +   accelerometers: MMA8452Q, MMA8453Q, MMA8652FC, MMA8653FC.
>  
> To compile this driver as a module, choose M here: the module
> will be called mma8452.
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 6b1a862..59b4455 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -3,6 +3,8 @@
>   *
>   * MMA8452Q (12 bit)
>   * MMA8453Q (10 bit)
> + * MMA8652FC (12 bit)
> + * MMA8653FC (10 bit)
>   *
>   * Copyright 2014 Peter Meerwald 
>   *
> @@ -84,6 +86,8 @@
>  
>  #define  MMA8452_DEVICE_ID   0x2a
>  #define  MMA8453_DEVICE_ID   0x3a
> +#define MMA8652_DEVICE_ID0x4a
> +#define MMA8653_DEVICE_ID0x5a
>  
>  struct mma8452_data {
>   struct i2c_client *client;
> @@ -791,6 +795,26 @@ static struct attribute_group 
> mma8452_event_attribute_group = {
>   .num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
>  }
>  
> +#define MMA8652_CHANNEL(axis, idx, bits) { \
> + .type = IIO_ACCEL, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_CALIBBIAS), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .scan_index = idx, \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = (bits), \
> + .storagebits = 16, \
> + .shift = 16 - (bits), \
> + .endianness = IIO_BE, \
> + }, \
> + .event_spec = mma8452_motion_event, \
I suppose you could add another macro def that does everything other than
the event_spec. However I'd argue that it is better to keep it clear like
you have done here.
> + .num_event_specs = ARRAY_SIZE(mma8452_motion_event), \
> +}
> +
>  static const struct iio_chan_spec mma8452_channels[] = {
>   MMA8452_CHANNEL(X, 0, 12),
>   MMA8452_CHANNEL(Y, 1, 12),
> @@ -805,9 +829,25 @@ static const struct iio_chan_spec mma8453_channels[] = {
>   IIO_CHAN_SOFT_TIMESTAMP(3),
>  };
>  
> +static const struct iio_chan_spec mma8652_channels[] = {
> + MMA8652_CHANNEL(X, 0, 12),
> + MMA8652_CHANNEL(Y, 1, 12),
> + MMA8652_CHANNEL(Z, 2, 12),
> + IIO_CHAN_SOFT_TIMESTAMP(3),
> +};
> +
> +static const struct iio_chan_spec mma8653_channels[] = {
> + MMA8652_CHANNEL(X, 0, 10),
> + MMA8652_CHANNEL(Y, 1, 10),
> + MMA8652_CHANNEL(Z, 2, 10),
> + IIO_CHAN_SOFT_TIMESTAMP(3),
> +};
> +
>  enum {
>   mma8452,
>   mma8453,
> + mma8652,
> + mma8653,
>  };
>  
>  static const struct mma_chip_info mma_chip_info_table[] = {
> @@ -850,6 +890,38 @@ static const struct mma_chip_info mma_chip_info_table[] 
> = {
>

Re: [PATCH 3/6] iio: mma8452: add freefall / motion interrupt source

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds the freefall / motion interrupt source definitions to the driver.
> It is used in this series' next patch, for chips that don't support the
> transient interrupt source.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Looks fine to me.  Will let sit for Peter and others to take a look if they 
like.

Jonathan
> ---
>  drivers/iio/accel/mma8452.c | 44 
>  1 file changed, 36 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 7b2ab17..6b1a862 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -42,6 +42,16 @@
>  #define  MMA8452_DATA_CFG_HPF_MASK   BIT(4)
>  #define MMA8452_HP_FILTER_CUTOFF 0x0f
>  #define  MMA8452_HP_FILTER_CUTOFF_SEL_MASK   GENMASK(1, 0)
> +#define MMA8452_FF_MT_CFG0x15
> +#define  MMA8452_FF_MT_CFG_OAE   BIT(6)
> +#define  MMA8452_FF_MT_CFG_ELE   BIT(7)
> +#define MMA8452_FF_MT_SRC0x16
> +#define  MMA8452_FF_MT_SRC_XHE   BIT(1)
> +#define  MMA8452_FF_MT_SRC_YHE   BIT(3)
> +#define  MMA8452_FF_MT_SRC_ZHE   BIT(5)
> +#define MMA8452_FF_MT_THS0x17
> +#define  MMA8452_FF_MT_THS_MASK  0x7f
> +#define MMA8452_FF_MT_COUNT  0x18
>  #define MMA8452_TRANSIENT_CFG0x1d
>  #define  MMA8452_TRANSIENT_CFG_HPF_BYP   BIT(0)
>  #define  MMA8452_TRANSIENT_CFG_CHAN(chan)BIT(chan + 1)
> @@ -69,6 +79,7 @@
>  #define MMA8452_MAX_REG  0x31
>  
>  #define  MMA8452_INT_DRDYBIT(0)
> +#define  MMA8452_INT_FF_MT   BIT(2)
>  #define  MMA8452_INT_TRANS   BIT(5)
>  
>  #define  MMA8452_DEVICE_ID   0x2a
> @@ -613,7 +624,8 @@ static int mma8452_write_event_config(struct iio_dev 
> *indio_dev,
>   else
>   val &= ~BIT(chan->scan_index + chip->ev_cfg_chan_shift);
>  
> - val |= MMA8452_TRANSIENT_CFG_ELE;
> + val |= chip->ev_cfg_ele;
> + val |= MMA8452_FF_MT_CFG_OAE;
>  
>   return mma8452_change_config(data, chip->ev_cfg, val);
>  }
> @@ -654,6 +666,7 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
>  {
>   struct iio_dev *indio_dev = p;
>   struct mma8452_data *data = iio_priv(indio_dev);
> + const struct mma_chip_info *chip = data->chip_info;
>   int ret = IRQ_NONE;
>   int src;
>  
> @@ -666,7 +679,10 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
>   ret = IRQ_HANDLED;
>   }
>  
> - if (src & MMA8452_INT_TRANS) {
> + if ((src & MMA8452_INT_TRANS &&
> +  chip->ev_src == MMA8452_TRANSIENT_SRC) ||
> + (src & MMA8452_INT_FF_MT &&
> +  chip->ev_src == MMA8452_FF_MT_SRC)) {
>   mma8452_transient_interrupt(indio_dev);
>   ret = IRQ_HANDLED;
>   }
> @@ -728,6 +744,16 @@ static const struct iio_event_spec 
> mma8452_transient_event[] = {
>   },
>  };
>  
> +static const struct iio_event_spec mma8452_motion_event[] = {
> + {
> + .type = IIO_EV_TYPE_MAG,
> + .dir = IIO_EV_DIR_RISING,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> + .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_PERIOD)
> + },
> +};
> +
>  /*
>   * Threshold is configured in fixed 8G/127 steps regardless of
>   * currently selected scale for measurement.
> @@ -1013,13 +1039,15 @@ static int mma8452_probe(struct i2c_client *client,
>  
>   if (client->irq) {
>   /*
> -  * Although we enable the transient interrupt source once and
> -  * for all here the transient event detection itself is not
> -  * enabled until userspace asks for it by
> -  * mma8452_write_event_config()
> +  * Although we enable the interrupt sources once and for
> +  * all here the event detection itself is not enabled until
> +  * userspace asks for it by mma8452_write_event_config()
>*/
> - int supported_interrupts = MMA8452_INT_DRDY | MMA8452_INT_TRANS;
> - int enabled_interrupts = MMA8452_INT_TRANS;
> + int supported_interrupts = MMA8452_INT_DRDY |
> +MMA8452_INT_TRANS |
> +MMA8452_INT_FF_MT;
> + int enabled_interrupts = MMA8452_INT_TRANS |
> +  MMA8452_INT_FF_MT;
>  
>   /* Assume wired to INT1 pin */
>   ret = i2c_smbus_write_byte_data(client,
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kerne

Re: [PATCH 2/6] iio: mma8452: add support for MMA8453Q accelerometer chip

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds support for the 10 bit version if Freescale's accelerometers
> of this series. The datasheet is available at Freescale's website:
> 
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8453Q.pdf
> 
> It creates a devicetree bindings file to document the new functionality
> and removes the driver from the trivial-devices list.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Another nice patch.  My only comment is that it might be worth adding
a cross reference in the bindings docs to the interrupt docs.

I'll probably take it as is after letting it sit for a little longer, but
if you are rerolling for another reason that would be a nice addition.

Jonathan
> ---
>  .../devicetree/bindings/i2c/trivial-devices.txt|  1 -
>  .../devicetree/bindings/iio/accel/mma8452.txt  | 22 +
>  drivers/iio/accel/Kconfig  |  6 ++--
>  drivers/iio/accel/mma8452.c| 37 
> --
>  4 files changed, 59 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/iio/accel/mma8452.txt
> 
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index d77d412..a50e56d 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -54,7 +54,6 @@ epson,rx8581I2C-BUS INTERFACE REAL TIME 
> CLOCK MODULE
>  fsl,mag3110  MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
>  fsl,mc13892  MC13892: Power Management Integrated Circuit (PMIC) for 
> i.MX35/51
>  fsl,mma8450  MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic 
> Accelerometer
> -fsl,mma8452  MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer
>  fsl,mpr121   MPR121: Proximity Capacitive Touch Sensor Controller
>  fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
>  gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog 
> with Two-Wire Interface
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> new file mode 100644
> index 000..c3bc272
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -0,0 +1,22 @@
> +Freescale MMA8452Q or MMA8453Q triaxial accelerometer
> +
> +Required properties:
> +
> +  - compatible: should contain one of
> +* "fsl,mma8452"
> +* "fsl,mma8453"
> +  - reg: the I2C address of the chip
> +
> +Optional properties:
> +
> +  - interrupt-parent: should be the phandle for the interrupt controller
> +  - interrupts: interrupt mapping for GPIO IRQ
Only comment here is that usual convention is to cross reference the
interrupt docs as their are lots of weird corner cases that we don't
have to care about documenting for every device.
> +
> +Example:
> +
> + mma8453fc@1d {
> + compatible = "fsl,mma8453";
> + reg = <0x1d>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <5 0>;
> + };
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index a59047d..e4075a0 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -100,13 +100,13 @@ config KXCJK1013
> be called kxcjk-1013.
>  
>  config MMA8452
> - tristate "Freescale MMA8452Q Accelerometer Driver"
> + tristate "Freescale MMA8452Q and similar Accelerometers Driver"
>   depends on I2C
>   select IIO_BUFFER
>   select IIO_TRIGGERED_BUFFER
>   help
> -   Say yes here to build support for the Freescale MMA8452Q 3-axis
> -   accelerometer.
> +   Say yes here to build support for the following Freescale 3-axis
> +   accelerometers: MMA8452Q, MMA8453Q.
>  
> To compile this driver as a module, choose M here: the module
> will be called mma8452.
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index f28428fa..7b2ab17 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1,5 +1,8 @@
>  /*
> - * mma8452.c - Support for Freescale MMA8452Q 3-axis 12-bit accelerometer
> + * mma8452.c - Support for following Freescale 3-axis accelerometers:
> + *
> + * MMA8452Q (12 bit)
> + * MMA8453Q (10 bit)
>   *
>   * Copyright 2014 Peter Meerwald 
>   *
> @@ -26,7 +29,7 @@
>  
>  #define MMA8452_STATUS   0x00
>  #define  MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> -#define MMA8452_OUT_X0x01 /* MSB first, 
> 12-bit  */
> +#define MMA8452_OUT_X0x01 /* MSB first */
>  #define MMA8452_OUT_Y0x03
>  #define MMA8452_OUT_Z0x05
>  #define MMA8452_INT_SRC  0x0c
> @@ -69,6 +72,7

Re: [PATCH 1/6] iio: mma8452: refactor for seperating chip specific data

[Jonathan Cameron]

On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds a struct mma_chip_info to hold data that will remain specific to
> the chip in use. It is provided during probe() and linked in
> struct of_device_id.
> 
> Also this suggests that the driver is called "mma8452" and now handles the
> MMA8452Q device, but is not limited to it.
> 
> Signed-off-by: Martin Kepplinger 
> Signed-off-by: Christoph Muellner 
Looks very nice to me. Very clear resulting code.

Peter.  This is your driver so will give you time to take a look at this (or
tell me you don't want to / haven't got time if you like and I'll take
it as is!)

If we'd been towards the end of the cycle I might have gone with it without
waiting, but we have plenty of time now so lets not rush!

Jonathan
> ---
>  drivers/iio/accel/mma8452.c | 183 
> 
>  1 file changed, 134 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index b921d84..f28428fa 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define MMA8452_STATUS   0x00
>  #define  MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> @@ -74,6 +75,52 @@ struct mma8452_data {
>   struct mutex lock;
>   u8 ctrl_reg1;
>   u8 data_cfg;
> + const struct mma_chip_info *chip_info;
> +};
> +
> +/**
> + * struct mma_chip_info - chip specific data for Freescale's accelerometers
> + * @chip_id: WHO_AM_I register's value
> + * @channels:struct iio_chan_spec matching the 
> device's
> + *   capabilities
> + * @num_channels:number of channels
> + * @mma_scales:  scale factors for converting register 
> values
> + *   to m/s^2; 3 modes: 2g, 4g, 8g; 2 integers
> + *   per mode: m/s^2 and micro m/s^2
> + * @ev_cfg:  event config register address
> + * @ev_cfg_ele:  latch bit in event config register
> + * @ev_cfg_chan_shift:   number of the bit to enable events in X
> + *   direction; in event config register
> + * @ev_src:  event source register address
> + * @ev_src_xe:   bit in event source register that 
> indicates
> + *   an event in X direction
> + * @ev_src_ye:   bit in event source register that 
> indicates
> + *   an event in Y direction
> + * @ev_src_ze:   bit in event source register that 
> indicates
> + *   an event in Z direction
> + * @ev_ths:  event threshold register address
> + * @ev_ths_mask: mask for the threshold value
> + * @ev_count:event count (period) register address
> + *
> + * Since not all chips supported by the driver support comparing high pass
> + * filtered data for events (interrupts), different interrupt sources are
> + * used for different chips and the relevant registers are included here.
> + */
> +struct mma_chip_info {
> + u8 chip_id;
> + const struct iio_chan_spec *channels;
> + int num_channels;
> + const int mma_scales[3][2];
> + u8 ev_cfg;
> + u8 ev_cfg_ele;
> + u8 ev_cfg_chan_shift;
> + u8 ev_src;
> + u8 ev_src_xe;
> + u8 ev_src_ye;
> + u8 ev_src_ze;
> + u8 ev_ths;
> + u8 ev_ths_mask;
> + u8 ev_count;
>  };
>  
>  static int mma8452_drdy(struct mma8452_data *data)
> @@ -143,16 +190,6 @@ static const int mma8452_samp_freq[8][2] = {
>   {6, 25}, {1, 56}
>  };
>  
> -/*
> - * Hardware has fullscale of -2G, -4G, -8G corresponding to raw value -2048
> - * The userspace interface uses m/s^2 and we declare micro units
> - * So scale factor is given by:
> - *   g * N * 100 / 2048 for N = 2, 4, 8 and g = 9.80665
> - */
> -static const int mma8452_scales[3][2] = {
> - {0, 9577}, {0, 19154}, {0, 38307}
> -};
> -
>  /* Datasheet table 35  (step time vs sample frequency) */
>  static const int mma8452_transient_time_step_us[8] = {
>   1250,
> @@ -189,8 +226,11 @@ static ssize_t mma8452_show_scale_avail(struct device 
> *dev,
>   struct device_attribute *attr,
>   char *buf)
>  {
> - return mma8452_show_int_plus_micros(buf, mma8452_scales,
> - ARRAY_SIZE(mma8452_scales));
> + struct mma8452_data *data = iio_priv(i2c_get_clientdata(
> +  to_i2c_client(dev)));
> +
> + return mma8452_show_int_plus_micros(buf, data->chip_info->mma_scales,
> + ARRAY_SIZE(data->chip_info->mma_scales));
>  }
>  
>  static ssize_t mma8452_show_hp_cutoff_avail(struct device *dev,
> @@ -221,9 +2

Re: [[PATCH v2] 2/2] Altera Modular ADC driver support

[Jonathan Cameron]

On 01/09/15 22:49, Chee Nouk Phoo wrote:
> From: Chee Nouk Phoon 
> 
> Altera Modular ADC is soft IP that wraps the hardened ADC block in a Max10
> device. It can be configured to dual ADC mode that supports two channel
> synchronous sampling or independent single ADCs. ADC sampled values will be
> written into memory slots in sequence determined by a user configurable
> sequencer block.
> 
> This patch adds Altera Modular ADC driver support
> 
> Signed-off-by: Chee Nouk Phoon 
Sorry, I wrote a review of version 1 but for some reason seem not have
sent it.  Anyhow, will comment on this version now.

I'm feeling rather guilty about this as there are a number of elements
in this driver that are major issues and I meant to get back to you on
them over a week ago!  Oops.

Anyhow, big ones in here are unusual uses of the ABI.  One point to note
is that if you ever add any ABI not documented in Documentation/ABI/testing/*
then you MUST document it as part of your patch.  It saves a lot
of time whilst the reviewer figures out what the ABI being presented
actually is.

Dual ADCs should not have their two elements passed out through a single
sysfs attribute.  If you need to maintain their relationship it must
be done by using the buffered interface not the sysfs one.  Doing it
any other way leads to inconsistent and confusing userspace ABI which
would be a disaster.

Extended naming (tied up with the above) has very limited use cases and
must be documented.  It confuses userspace applications by encoding
information in a freeform way within the attribute name. As such the
form must be clearly documented and justified.  The use case here is
not justified.

Anyhow, whilst these sound major, the driver is actually in pretty good
shape and the other stuff is minor tidy ups / formatting suggestions.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/Kconfig   |   11 ++
>  drivers/iio/adc/Makefile  |1 +
>  drivers/iio/adc/alt_modular_adc.c |  322 
> +
>  3 files changed, 334 insertions(+), 0 deletions(-)
>  mode change 100644 => 100755 drivers/iio/adc/Kconfig
>  create mode 100755 drivers/iio/adc/alt_modular_adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> old mode 100644
> new mode 100755
> index 50c103d..e1a67cb
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -118,6 +118,17 @@ config AD799X
> To compile this driver as a module, choose M here: the module will be
> called ad799x.
>  
> +config ALT_MODULAR_ADC
> + tristate "Altera Modular ADC driver"
> + select ANON_INODES
> +
> + help
> +   Say yes here to have support for Altera Modular ADC. The driver
> +   supports both Altera Modular ADC and Altera Modular Dual ADC.
> +
> +   The driver can also be build as a module. If so the module will be
> +   called alt_modular_adc.
> +
>  config AT91_ADC
>   tristate "Atmel AT91 ADC"
>   depends on ARCH_AT91
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index a096210..d7f10e0 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -38,3 +38,4 @@ obj-$(CONFIG_VF610_ADC) += vf610_adc.o
>  obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
>  xilinx-xadc-y := xilinx-xadc-core.o xilinx-xadc-events.o
>  obj-$(CONFIG_XILINX_XADC) += xilinx-xadc.o
> +obj-$(CONFIG_ALT_MODULAR_ADC) += alt_modular_adc.o
> diff --git a/drivers/iio/adc/alt_modular_adc.c 
> b/drivers/iio/adc/alt_modular_adc.c
> new file mode 100755
> index 000..3d2d870
> --- /dev/null
> +++ b/drivers/iio/adc/alt_modular_adc.c
> @@ -0,0 +1,322 @@
> +/*
> + * Copyright (C) 2015 Altera Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +/* Constant Definitions */
Please prefix all constants iwth ALT_MODULAR_ADC_ or similar
to avoid potential name clashes in the future.

> +#define MAX_SLOT 64
> +#define MAX_ADC  2
> +#define MAX_CHANNEL  18
> +#define MODE_SINGLE_ADC  1
> +#define MODE_DUAL_ADC2
> +#define ADC_BITS 12
> +#define ADC_STORE_BITS   16
> +#define ADC_MAX_STR_SIZE20
> +
> +/* Register Definitions */
> +#define ADC_CMD_REG  0x

Re: [[PATCH v2] 1/2] Altera Modular ADC driver device binding

[Jonathan Cameron]

On 01/09/15 22:49, Chee Nouk Phoo wrote:
> From: Chee Nouk Phoon 
> 
> Altera Modular ADC is soft IP that wraps the hardened ADC block in a Max10
> device. It can be configured to dual ADC mode that supports two channel
> synchronous sampling or independent single ADCs. ADC sampled values will be
> written into memory slots in sequence determined by a user configurable
> sequencer block.
> 
> This patch adds Altera Modular ADC driver device tree binding
I think the convention is still to explicitly cc all device tree maintainers on 
bindings
patches (added).

A few bits and pieces in line.  Basically I'd like more explanation + examples 
to
make it clear what is going on.  This hardware has some unusual corners
(inherent in being a highly configurable bit of IP) so perhaps needs more than
we would normally expect in the way of description

Thanks,

Jonathan
> 
> Signed-off-by: Chee Nouk Phoon 
> ---
>  .../bindings/iio/adc/altr,modular-adc.txt  |   63 
> 
>  1 files changed, 63 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt 
> b/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
> new file mode 100644
> index 000..faafcac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
> @@ -0,0 +1,63 @@
> +Altera Modular (Dual) ADC
> +
> +This binding document describes both Altera Modular ADC and Altera Modular 
> Dual
> +ADC. Both options can be configured during generation time in Qsys. This 
> driver
> +only supports standard sequencer with Avalon-MM sample storage with up to 64
> +memory slots.
> +
> +Required properties:
> +- compatible: must be one of the following strings
> +  "altr,modular-adc-1.0": single ADC configuration
> +  "altr,modular-dual-adc-1.0": dual ADC configuration
> +
> +- reg: Address and length of the register set for the device. It contains the
> +  information of registers in the same order as described by reg-names
> +
> +- reg-names: Should contain the reg names
> +  "sequencer_csr": register region for adc sequencer block
> +  "sample_store_csr": register region for sample store block
> +
> +- interrupts: interrupt line for ADC
Normal to add a cross reference here to the standard interrupt binding
docs (as there are loads of ways of specifying an interrupt!)
> +
> +- altr,adc-mode : ADC configuration
> +  1: single ADC mode
> +  2: dual ADC mode
I'd guess this is only relevant if the compatible is the dual-adc version?
Please document that if so.
> +
> +- altr,adc-slot-count : specify number of conversion slot in use
slots  Could you add an example below of multiple slots in use?
Would make it clearer what is going on here and what the expected
syntax is for the bindings.

> +
> +- altr,adc-slot-sequence-: specify ADC channel
> +  conversion sequence
> +  : instantiated ADC number
> +  : slot index for ADC memory slot
What for does the value take?

> +
> +- altr,adc-number : specify ADC number when single ADC mode is selected
> +  1: 1st ADC
> +  2: 2nd ACD
ADC

> +
> +Example: single ADC
> +modular_adc_0: adc@0x2200 {
> +  compatible = "altr,modular-adc";
> +  reg = <0x2000 0x0008>,
> +<0x2200 0x0200>;
> +  reg-names = "sequencer_csr", "sample_store_csr";
> +  interrupt-parent = <&cpu>;
> +  interrupts = <8>;
> +  altr,adc-mode = <1>;
> +  altr,adc-slot-count = <2>;
> +  altr,adc1-slot-sequence-1 = <1>;
> +  altr,adc-number = <1>;
> +};
> +
> +Example: dual ADC
> +modular_adc_1: adc@0x18002200 {
> +  compatible = "altr,modular-dual-adc";
> +  reg = <0x18002000 0x0008>,
> +<0x18002200 0x0200>;
> +  reg-names = "sequencer_csr", "sample_store_csr";
> +  interrupt-parent = <&cpu>;
> +  interrupts = <8>;
> +  altr,adc-mode = <2>;
> +  altr,adc-slot-count = <1>;
These needs some comments to explain the settings.
There is more here than simply dual vs single ADCs.  Perhaps
even a more complex example with multipel slots in use would
clarify things?  As I understand it the slot sequencing is baked
into the fpga logic and not configurable at runtime?
Perhaps add some detail of that in this document as well to make it
easier to review.

> +  altr,adc1-slot-sequence-1 = <6>;
> +  altr,adc2-slot-sequence-1 = <6>;
> +};
There's a hint here.  There should be a new line at the end of the file ;)

> \ No newline at end of file
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Altera Modular ADC driver device tree binding

[Jonathan Cameron]

On 20/08/15 08:46, Chee Nouk Phoo wrote:
> From: Chee Nouk Phoon 
> 
> Altera Modular ADC is soft IP that wraps the hardened ADC block in a Max1
> device. It can be configured to dual ADC mode that supports two channel
> synchronous sampling or independent single ADCs. ADC sampled values will be
> written into memory slots in sequence determined by a user configurable
> sequencer block.
> 
> This patch adds device tree binding for Altera Modular ADC driver
> 
> Signed-off-by: Chee Nouk Phoon 
> ---
>  .../bindings/iio/adc/altr,modular-adc.txt  |   63 
> 
>  1 files changed, 63 insertions(+), 0 deletions(-)
>  create mode 100755 
> Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt 
> b/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
> new file mode 100755
> index 000..4106cb4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/altr,modular-adc.txt
> @@ -0,0 +1,63 @@
> +Altera Modular (Dual) ADC
> +
> +This binding document describes both Altera Modular ADC and Altera Modular 
> Dual
> +ADC. Both options can be configured during generation time in Qsys. This 
> driver
> +only support standard sequencer with Avalon-MM sample storage with up to 64
> +memory slots.
> +
> +Required properties:
> +- compatible: must be one of the following strings
> +  "altr,modular-adc": single ADC configuration
> +  "altr,modular-dual-adc": dual ADC configuration
> +
> +- reg: Address and length of the register set for the device. It contains the
> +  information of registers in the same order as described by reg-names
> +
> +- reg-names: Should contain the reg names
> +  "sequencer_csr": register region for adc sequencer block
> +  "sample_store_csr": register region for sample store block
> +
> +- interrupts: interrupt line for ADC
> +
> +- altr,adc-mode : ADC configuration
> +  1: single ADC mode
> +  2: dual ADC mode
> +
> +- altr,adc-slot-count : specify number of conversion slot in use
> +
> +- altr,adc-slot-sequence-: specify ADC channel 
> +  conversion sequence
> +  : instantiated ADC number
> +  : slot index for ADC memory slot
> +
> +- altr,adc-number : specify ADC number when single ADC mode is selected
> +  1: 1st ADC
> +  2: 2nd ACD
> +
> +Example: single ADC
> +modular_adc_0: adc@0x2200 {
> +  compatible = "altr,modular-adc";
> +  reg = <0x2000 0x0008>,
> +<0x2200 0x0200>;
> +  reg-names = "sequencer_csr", "sample_store_csr";
> +  interrupt-parent = <&cpu>;
> +  interrupts = <8>;
> +  altr,adc-mode = <1>;
> +  altr,adc-slot-count = <2>;
> +  altr,adc1-slot-sequence-1 = <1>;
> +  altr,adc-number = <1>;
> +};
> +
> +Example: dual ADC
> +modular_adc_1: adc@0x18002200 {
> +  compatible = "altr,modular-dual-adc";
> +  reg = <0x18002000 0x0008>,
> +<0x18002200 0x0200>;
> +  reg-names = "sequencer_csr", "sample_store_csr";
> +  interrupt-parent = <&cpu>;
> +  interrupts = <8>;
> +  altr,adc-mode = <2>;
> +  altr,adc-slot-count = <1>;
> +  altr,adc1-slot-sequence-1 = <6>;
> +  altr,adc2-slot-sequence-1 = <6>;
> +};
> \ No newline at end of file
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/2] dt: Document Holt HI-8435 bindings

[Jonathan Cameron]

On 28/08/15 15:28, Vladimir Barinov wrote:
> These bindings can be used to register Holt HI-8435 threshold detector
> 
> Signed-off-by: Vladimir Barinov 
This is now trivial so I'm taking it.

Applied to the togreg branch of iio.git

Thanks,

Jonathan
> ---
> Changes in version 2:
> - renamed file name hi-843x.txt to hi8435.txt
> - removed hi-8436,hi-8436,hi-8437
> - removed holt,debounce-soft field
> - renamed holt,debounc-soft-delay to holt,debounce-interval
> - renamed mr-gpio to reset-gpios
> Changes in version 3:
> - none
> Changes in version 4:
> - removed debounce_interval property
> - removed reset-gpios to use GPIO descriptor API
> Changes in version 5:
> - none
> 
>  .../devicetree/bindings/iio/adc/hi8435.txt  | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
> b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
> new file mode 100644
> index 000..3b0348c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
> @@ -0,0 +1,21 @@
> +Holt Integrated Circuits HI-8435 threshold detector bindings
> +
> +Required properties:
> + - compatible: should be "holt,hi8435"
> + - reg: spi chip select number for the device
> +
> +Recommended properties:
> + - spi-max-frequency: definition as per
> + Documentation/devicetree/bindings/spi/spi-bus.txt
> +
> +Optional properties:
> + - gpios: GPIO used for controlling the reset pin
> +
> +Example:
> +sensor@0 {
> + compatible = "holt,hi8435";
> + reg = <0>;
> + gpios = <&gpio6 1 0>;
> +
> + spi-max-frequency = <100>;
> +};
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] iio: adc: hi8435: Holt HI-8435 threshold detector

[Jonathan Cameron]

On 28/08/15 15:27, Vladimir Barinov wrote:
> Add Holt threshold detector driver for HI-8435 chip
> 
> Signed-off-by: Vladimir Barinov 
Applied to the togreg branch of iio.git - initially pushed out as
testing for the auto builders to try and break it.

Thanks for you persistence with this one!  I'm not entirely sure
where we will ultimately end up with chips like this, but this
is certainly a good start!

Jonathan
> ---
> Changes in version 2:
> - Added file sysfs-bus-iio-adc-hi8435
> - Changed naming from "discrete ADC" to "threshold detector"
> - Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
> - Made *_show and *_store functions static
> - moved out from iio buffers to iio events
> - removed hi8436/hi8437 chips from the driver
> - moved from debounce_soft_delay/enable to debounce_interval via
>   IIO_CHAN_INFO_DEBOUNCE_TIME
> - added name extention "comparator"
> - moved threshold/hysteresis setup via generic iio event sysfs
> - added software mask/unmask channel events
> - added programming sensor outputs while in test mode via
>   IIO_CHAN_INFO_RAW
> - added channels .ext_info for programming sensing mode
> Changes in version 3:
> - fixed typos
> - moved  to match alphabetic order
> - fixed missed */event/* prefix in the ABI description
> - added missed colon in sysfs-bus-iio-adc-hi8435 file after "What"
> - moved in_voltageY_comparator_thresh_either_en and debounce_time
>   to sysfs-bus-iio file
> - added error checking for hi8435_write[b|w]
> Changes in version 4:
> - removed software debounce logic
> - fixed typo in comment s/threshold/thresholds
> - removed test_enable sysfs entry
> - removed *_raw entries
> - removed extended_name
> - switched to GPIO descriptor API
> - added comment describing the need of thresholds initialization
> - added debugfs_reg_access
> Changes in version 5:
> - added ABI description about falling/rising thresholds automatic
>  adjustment that avoids odd hysteresis
> - changed reg_buffer[] size to 3 instead of 4
> - modified if/else logic in hi8435_read_event_value function
> - modified if/else logic in hi8435_write_event_value function
> - modified if/else logic in hi8435_iio_push_event function
> 
>  Documentation/ABI/testing/sysfs-bus-iio|   1 +
>  Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  43 ++
>  drivers/iio/adc/Kconfig|  11 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/hi8435.c   | 531 
> +
>  5 files changed, 587 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
>  create mode 100644 drivers/iio/adc/hi8435.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 42d360f..20312a0 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -581,6 +581,7 @@ What: 
> /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
>  What:
> /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
>  What:/sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
>  What:
> /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
> +What:/sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
>  What:/sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
>  What:/sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
>  KernelVersion:   2.6.37
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
> b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
> new file mode 100644
> index 000..f30b4c4
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
> @@ -0,0 +1,43 @@
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
> +Date:August 2015
> +KernelVersion:   4.2.0
> +Contact: sou...@cogentembedded.com
> +Description:
> + Program sensor type for threshold detector inputs.
> + Could be either "GND-Open" or "Supply-Open" mode. Y is a
> + threshold detector input channel. Channels 0..7, 8..15, 16..23
> + and 24..31 has common sensor types.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
> +Date:August 2015
> +KernelVersion:   4.2.0
> +Contact: sou...@cogentembedded.com
> +Description:
> + Channel Y low voltage threshold. If sensor input voltage goes 
> lower then
> + this value then the threshold falling event is pushed.
> + Depending on in_voltageY_sensing_mode the low voltage threshold
> + is separately set for "GND-Open" and "Supply-Open" modes.
> + Channels 0..31 have common low threshold values, but could have 
> different
> + sensing_modes.
> + The low voltage threshold range

Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor

[Jonathan Cameron]

On 20/08/15 11:12, Adriana Reus wrote:
> Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor.
> Also added a documentation file for this sensor's properties.
> 
> Signed-off-by: Adriana Reus 
This isn't that trivial so I'd like some device tree maintainer
input if possible.

For now I've backed out the driver from my tree (given timing we have
loads of time to sort this out!)

Anyhow, anyone device tree related able to take a look at this.

Adriana, btw these should be cc'd to the device tree maintainers in
the first place (now added).

Jonathan
> ---
>  .../devicetree/bindings/iio/light/us5182d.txt  | 23 
> ++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  2 files changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt 
> b/Documentation/devicetree/bindings/iio/light/us5182d.txt
> new file mode 100644
> index 000..7785c56
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
> @@ -0,0 +1,23 @@
> +* UPISEMI us5182d I2C ALS and Proximity sensor
> +
> +Required properties:
> +- compatible: must be "upisemi,usd5182"
> +- reg: the I2C address of the device
> +
> +Optional properties:
> +- upisemi,glass-coef: glass attenuation factor
> +- upisemi,dark-ths: array of thresholds (adc counts) corresponding to every 
> scale
> +- upisemi,upper-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) 
> applied when light > threshold
> +- upisemi,lower-dark-gain: tuning factor(4 int and 4 fractional bits - Q4.4) 
> applied when light < threshold
> +
> +Example:
> +
> +usd5182@39 {
> +compatible = "upisemi,usd5182";
> +reg = <0x39>;
> +upisemi,glass-coef = < 1000 >;
> +upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 
> 8000>;
> +upisemi,upper-dark-gain = /bits/ 8 <0x00>;
> +upisemi,lower-dark-gain = /bits/ 8 <0x16>;
> +};
> +
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index d444757..5b40bab 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -211,6 +211,7 @@ toshiba   Toshiba Corporation
>  toumaz   Toumaz
>  tplink   TP-LINK Technologies Co., Ltd.
>  trulyTruly Semiconductors Limited
> +upisemi  uPI Semiconductor Corp.
>  usi  Universal Scientific Industrial Co., Ltd.
>  v3   V3 Semiconductor
>  varisciteVariscite Ltd.
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/2] iio: light: Add support for UPISEMI uS5182d als and proximity sensor

[Jonathan Cameron]

On 20/08/15 11:12, Adriana Reus wrote:
> Add support for UPISEMI us5182d als and proximity sensor.
> Supports raw readings.
> Data sheet for this device can be found here:
> http://www.upi-semi.com/temp/uS5182D-DS-P0103-temp.pdf
> 
> Signed-off-by: Adriana Reus 
Applied to the togreg branch of iio.git - initially pushed out
as testing for the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  Changes since v5:
>  * fixed typos (thank you, Peter)
> 
>  drivers/iio/light/Kconfig   |  10 +
>  drivers/iio/light/Makefile  |   1 +
>  drivers/iio/light/us5182d.c | 507 
> 
>  3 files changed, 518 insertions(+)
>  create mode 100644 drivers/iio/light/us5182d.c
> 
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 7ed859a..0442f01 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -287,6 +287,16 @@ config TSL4531
>To compile this driver as a module, choose M here: the
>module will be called tsl4531.
>  
> +config US5182D
> + tristate "UPISEMI light and proximity sensor"
> + depends on I2C
> + help
> +  If you say yes here you get support for the UPISEMI US5182D
> +  ambient light and proximity sensor.
> +
> +  This driver can also be built as a module.  If so, the module
> +  will be called us5182d.
> +
>  config VCNL4000
>   tristate "VCNL4000 combined ALS and proximity sensor"
>   depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index 91c74c0..528cc8f 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -27,4 +27,5 @@ obj-$(CONFIG_STK3310)  += stk3310.o
>  obj-$(CONFIG_TCS3414)+= tcs3414.o
>  obj-$(CONFIG_TCS3472)+= tcs3472.o
>  obj-$(CONFIG_TSL4531)+= tsl4531.o
> +obj-$(CONFIG_US5182D)+= us5182d.o
>  obj-$(CONFIG_VCNL4000)   += vcnl4000.o
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> new file mode 100644
> index 000..49dab3c
> --- /dev/null
> +++ b/drivers/iio/light/us5182d.c
> @@ -0,0 +1,507 @@
> +/*
> + * Copyright (c) 2015 Intel Corporation
> + *
> + * Driver for UPISEMI us5182d Proximity and Ambient Light Sensor.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * To do: Interrupt support.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define US5182D_REG_CFG0 0x00
> +#define US5182D_CFG0_ONESHOT_EN  BIT(6)
> +#define US5182D_CFG0_SHUTDOWN_EN BIT(7)
> +#define US5182D_CFG0_WORD_ENABLE BIT(0)
> +
> +#define US5182D_REG_CFG1 0x01
> +#define US5182D_CFG1_ALS_RES16   BIT(4)
> +#define US5182D_CFG1_AGAIN_DEFAULT   0x00
> +
> +#define US5182D_REG_CFG2 0x02
> +#define US5182D_CFG2_PX_RES16BIT(4)
> +#define US5182D_CFG2_PXGAIN_DEFAULT  BIT(2)
> +
> +#define US5182D_REG_CFG3 0x03
> +#define US5182D_CFG3_LED_CURRENT100  (BIT(4) | BIT(5))
> +
> +#define US5182D_REG_CFG4 0x10
> +
> +/*
> + * Registers for tuning the auto dark current cancelling feature.
> + * DARK_TH(reg 0x27,0x28) - threshold (counts) for auto dark cancelling.
> + * when ALS  > DARK_TH --> ALS_Code = ALS - Upper(0x2A) * Dark
> + * when ALS < DARK_TH --> ALS_Code = ALS - Lower(0x29) * Dark
> + */
> +#define US5182D_REG_UDARK_TH 0x27
> +#define US5182D_REG_DARK_AUTO_EN 0x2b
> +#define US5182D_REG_AUTO_LDARK_GAIN  0x29
> +#define US5182D_REG_AUTO_HDARK_GAIN  0x2a
> +
> +#define US5182D_OPMODE_ALS   0x01
> +#define US5182D_OPMODE_PX0x02
> +#define US5182D_OPMODE_SHIFT 4
> +
> +#define US5182D_REG_DARK_AUTO_EN_DEFAULT 0x80
> +#define US5182D_REG_AUTO_LDARK_GAIN_DEFAULT  0x16
> +#define US5182D_REG_AUTO_HDARK_GAIN_DEFAULT  0x00
> +
> +#define US5182D_REG_ADL  0x0c
> +#define US5182D_REG_PDL  0x0e
> +
> +#define US5182D_REG_MODE_STORE   0x21
> +#define US5182D_STORE_MODE   0x01
> +
> +#define US5182D_REG_CHIPID   0xb2
> +
> +#define US5182D_OPMODE_MASK  GENMASK(5, 4)
> +#define US5182D_AGAIN_MASK 

Re: [PATCH v4 4/4] dt: Document Holt HI-8435 bindings

[Jonathan Cameron]

On 20/08/15 20:38, Vladimir Barinov wrote:
> These bindings can be used to register Holt HI-8435 threshold detector
> 
> Signed-off-by: Vladimir Barinov 
This is fine and trivial enough that I am not going to need a device tree
ack (not that I'd complain if one showed up :)


Will pick it up with the driver..
> ---
> Changes in version 2:
> - renamed file name hi-843x.txt to hi8435.txt
> - removed hi-8436,hi-8436,hi-8437
> - removed holt,debounce-soft field
> - renamed holt,debounc-soft-delay to holt,debounce-interval
> - renamed mr-gpio to reset-gpios
> Changes in version 3:
> - none
> Changes in version 4:
> - removed debounce_interval property
> - removed reset-gpios to use GPIO descriptor API
> 
>  .../devicetree/bindings/iio/adc/hi8435.txt  | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt 
> b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
> new file mode 100644
> index 000..3b0348c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
> @@ -0,0 +1,21 @@
> +Holt Integrated Circuits HI-8435 threshold detector bindings
> +
> +Required properties:
> + - compatible: should be "holt,hi8435"
> + - reg: spi chip select number for the device
> +
> +Recommended properties:
> + - spi-max-frequency: definition as per
> + Documentation/devicetree/bindings/spi/spi-bus.txt
> +
> +Optional properties:
> + - gpios: GPIO used for controlling the reset pin
> +
> +Example:
> +sensor@0 {
> + compatible = "holt,hi8435";
> + reg = <0>;
> + gpios = <&gpio6 1 0>;
> +
> + spi-max-frequency = <100>;
> +};
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/4] iio: adc: hi8435: Holt HI-8435 threshold detector

[Jonathan Cameron]

On 20/08/15 20:38, Vladimir Barinov wrote:
> Add Holt threshold detector driver for HI-8435 chip
> 
> Signed-off-by: Vladimir Barinov 
A few little bits and bobs below but basically there.

Jonathan
> ---
> Changes in version 2:
> - Added file sysfs-bus-iio-adc-hi8435
> - Changed naming from "discrete ADC" to "threshold detector"
> - Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup
> - Made *_show and *_store functions static
> - moved out from iio buffers to iio events
> - removed hi8436/hi8437 chips from the driver
> - moved from debounce_soft_delay/enable to debounce_interval via
>   IIO_CHAN_INFO_DEBOUNCE_TIME
> - added name extention "comparator"
> - moved threshold/hysteresis setup via generic iio event sysfs
> - added software mask/unmask channel events
> - added programming sensor outputs while in test mode via
>   IIO_CHAN_INFO_RAW
> - added channels .ext_info for programming sensing mode
> Changes in version 3:
> - fixed typos
> - moved  to match alphabetic order
> - fixed missed */event/* prefix in the ABI description
> - added missed colon in sysfs-bus-iio-adc-hi8435 file after "What"
> - moved in_voltageY_comparator_thresh_either_en and debounce_time
>   to sysfs-bus-iio file
> - added error checking for hi8435_write[b|w]
> Changes in version 4:
> - removed software debounce logic
> - fixed typo in comment s/threshold/thresholds
> - removed test_enable sysfs entry
> - removed *_raw entries
> - removed extended_name
> - switched to GPIO descriptor API
> - added comment describing the need of thresholds initialization
> - added debugfs_reg_access
> 
>  Documentation/ABI/testing/sysfs-bus-iio|   1 +
>  Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 |  39 ++
>  drivers/iio/adc/Kconfig|  11 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/hi8435.c   | 535 
> +
>  5 files changed, 587 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
>  create mode 100644 drivers/iio/adc/hi8435.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 42d360f..20312a0 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -581,6 +581,7 @@ What: 
> /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
>  What:
> /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
>  What:/sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
>  What:
> /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
> +What:/sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
>  What:/sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
>  What:/sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
>  KernelVersion:   2.6.37
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 
> b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
> new file mode 100644
> index 000..e3f1943
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
> @@ -0,0 +1,39 @@
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
> +Date:August 2015
> +KernelVersion:   4.2.0
> +Contact: sou...@cogentembedded.com
> +Description:
> + Program sensor type for threshold detector inputs.
> + Could be either "GND-Open" or "Supply-Open" mode. Y is a
> + threshold detector input channel. Channels 0..7, 8..15, 16..23
> + and 24..31 has common sensor types.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
> +Date:August 2015
> +KernelVersion:   4.2.0
> +Contact: sou...@cogentembedded.com
> +Description:
> + Channel Y low voltage threshold. If sensor input voltage goes 
> lower then
> + this value then the threshold falling event is pushed.
> + Depending on in_voltageY_sensing_mode the low voltage threshold
> + is separately set for "GND-Open" and "Supply-Open" modes.
> + Channels 0..31 have common low threshold values, but could have 
> different
> + sensing_modes.
> + The low voltage threshold range is between 2..21V.
> + Hysteresis between low and high thresholds can not be lower 
> then 2 and
> + can not be odd.
Should note that what happens if it is set to odd.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
> +Date:August 2015
> +KernelVersion:   4.2.0
> +Contact: sou...@cogentembedded.com
> +Description:
> + Channel Y high voltage threshold. If sensor input voltage goes 
> higher then
> + this value then the threshold rising event is pushed.
> + 

Re: [PATCH v4 2/4] dt: Add vendor prefix 'holt'

[Jonathan Cameron]

On 23/08/15 23:32, Rob Herring wrote:
> On Thu, Aug 20, 2015 at 2:38 PM, Vladimir Barinov
>  wrote:
>> Add Holt Integrated Circuits, Inc. to the list of device tree vendor
>> prefixes
>>
>> Signed-off-by: Vladimir Barinov 
> 
> Acked-by: Rob Herring 
Applied to the togreg branch of iio.git.

Thanks,

Jonathan
> 
>> ---
>> Changes in version 2:
>> - none
>> Changes in version 3:
>> - none
>> Changes in version 4:
>> - none
>>
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index d444757..bc64cc9 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -99,6 +99,7 @@ himax Himax Technologies, Inc.
>>  hisilicon  Hisilicon Limited.
>>  hitHitachi Ltd.
>>  hitex  Hitex Development Tools
>> +holt   Holt Integrated Circuits, Inc.
>>  honeywell  Honeywell
>>  hp Hewlett Packard
>>  i2se   I2SE GmbH
>> --
>> 1.9.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/4] iio: Support triggered events

[Jonathan Cameron]

On 20/08/15 20:43, Vladimir Barinov wrote:
> Verified event and buffer polling works concurrently on the same trigger with 
> hi-8435.
> The buffer interface part for hi-8435 was not sent.
> 
> On 20.08.2015 22:37, Vladimir Barinov wrote:
>> Support triggered events.
>>
>> This is useful for chips that don't have their own interrupt sources.
>> It allows to use generic/standalone iio triggers for those drivers.
>>
>> Signed-off-by: Vladimir Barinov 
Applied with a certain amount of fuzz (the buffers have moved out into
their own directory).

Jonathan
>> ---
>> Changes in version 2:
>> - initially added
>> Changes in version 3:
>> - fixed grammar in patch description
>> - changed license header to match "GNU Public License v2 or later"
>> Changes in version 4:
>> - added pollfunc_event to separate triggering buffer and event
>> interfaces. This allows runnig both from the same trigger
>> - removed 'currentmode' for triggered buffer since useless
>> - renamed parameters of iio_triggered_event_setup
>>
>>   drivers/iio/Kconfig|  6 +++
>>   drivers/iio/Makefile   |  1 +
>>   drivers/iio/industrialio-core.c|  4 +-
>>   drivers/iio/industrialio-trigger.c | 12 +-
>>   drivers/iio/industrialio-triggered-event.c | 68 
>> ++
>>   include/linux/iio/iio.h|  3 ++
>>   include/linux/iio/triggered_event.h| 11 +
>>   7 files changed, 101 insertions(+), 4 deletions(-)
>>   create mode 100644 drivers/iio/industrialio-triggered-event.c
>>   create mode 100644 include/linux/iio/triggered_event.h
>>
>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>> index 4011eff..8fcc92f 100644
>> --- a/drivers/iio/Kconfig
>> +++ b/drivers/iio/Kconfig
>> @@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
>>   This value controls the maximum number of consumers that a
>>   given trigger may handle. Default is 2.
>>   +config IIO_TRIGGERED_EVENT
>> +tristate
>> +select IIO_TRIGGER
>> +help
>> +  Provides helper functions for setting up triggered events.
>> +
>>   source "drivers/iio/accel/Kconfig"
>>   source "drivers/iio/adc/Kconfig"
>>   source "drivers/iio/amplifiers/Kconfig"
>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>> index 698afc2..40dc13e 100644
>> --- a/drivers/iio/Makefile
>> +++ b/drivers/iio/Makefile
>> @@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
>>   industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
>> obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
>> +obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
>>   obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
>> obj-y += accel/
>> diff --git a/drivers/iio/industrialio-core.c 
>> b/drivers/iio/industrialio-core.c
>> index b3fcc2c..2c3b6a1 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -962,7 +962,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
>> *indio_dev)
>>   static void iio_dev_release(struct device *device)
>>   {
>>   struct iio_dev *indio_dev = dev_to_iio_dev(device);
>> -if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
>> +if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
>>   iio_device_unregister_trigger_consumer(indio_dev);
>>   iio_device_unregister_eventset(indio_dev);
>>   iio_device_unregister_sysfs(indio_dev);
>> @@ -1241,7 +1241,7 @@ int iio_device_register(struct iio_dev *indio_dev)
>>   "Failed to register event set\n");
>>   goto error_free_sysfs;
>>   }
>> -if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
>> +if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
>>   iio_device_register_trigger_consumer(indio_dev);
>> if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
>> diff --git a/drivers/iio/industrialio-trigger.c 
>> b/drivers/iio/industrialio-trigger.c
>> index 570606c..ae2806a 100644
>> --- a/drivers/iio/industrialio-trigger.c
>> +++ b/drivers/iio/industrialio-trigger.c
>> @@ -366,10 +366,18 @@ static ssize_t iio_trigger_write_current(struct device 
>> *dev,
>> indio_dev->trig = trig;
>>   -if (oldtrig)
>> +if (oldtrig) {
>> +if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
>> +iio_trigger_detach_poll_func(oldtrig,
>> + indio_dev->pollfunc_event);
>>   iio_trigger_put(oldtrig);
>> -if (indio_dev->trig)
>> +}
>> +if (indio_dev->trig) {
>>   iio_trigger_get(indio_dev->trig);
>> +if (indio_dev->modes & INDIO_EVENT_TRIGGERED)
>> +iio_trigger_attach_poll_func(indio_dev->trig,
>> + indio_dev->pollfunc_event);
>> +}
>> return len;
>>   }
>> diff --git a/drivers/iio/industrialio-triggered-event.c 
>> b/drivers/iio/industrialio-triggered-event.c
>> new file mode 100644
>> index 000..8cc254f
>>

Re: [PATCH 13/18] iio: adc: mcp320x: Set struct spi_driver .of_match_table

[Jonathan Cameron]

On 20/08/15 23:48, Javier Martinez Canillas wrote:
> Hello Michael,
> 
> On 08/21/2015 12:29 AM, Michael Welling wrote:
>> On Fri, Aug 21, 2015 at 12:02:40AM +0200, Javier Martinez Canillas wrote:
>>> Hello Michael,
>>>
>>> On 08/20/2015 10:09 PM, Michael Welling wrote:
 On Thu, Aug 20, 2015 at 09:07:26AM +0200, Javier Martinez Canillas wrote:
> The driver has an OF id table but the .of_match_table is not set so
> the SPI core can't do an OF style match and the table was unused.
>

 Is an OF style match necessary?

>>>
>>> Did you read the cover letter [0] on which I explain why is needed to
>>> avoid breaking module autoloading in the future? Once the SPI core is
>>> changed by RFC patch 18/18? (you were cc'ed in the cover letter BTW).
>>
>> Well I have read it now. :)
>>
> 
> Great :)
>  
>>>
 I have been using devicetree and it matches based on the .id_table.

>>>
>>> Yes it fallbacks to the .id_table or the driver name but the correct
>>> thing to do for devices registered by OF, is to match using the
>>> compatible string.
>>>
 Couldn't we just remove the mcp320x_dt_ids table instead?

>>>
>>> No, that is the wrong thing to do IMHO since the compatible string
>>> contains both vendor and device name whle the .id_table only contains
>>> a device name.
>>>
>>> So it makes sense to match using the compatible string and also report
>>> the OF modalias information to user-space.
>>>
>>> Otherwise what's the point of the vendor in the compatible string for
>>> SPI devices? You can just use "bar" instead of "foo,bar" as a string.
>>>
>>
>> Well then shouldn't the patch include adding the vendor to the compatible
>> string?
>>
> 
> Well, I was talking in general. You are right that this specific driver does
> not have a vendor prefix for the compatible strings. This is incorrect
> according to the ePAPR document [0].
> 
> However, these compatible strings are already documented as a DT binding doc
> in Documentation/devicetree/bindings/iio/adc/mcp320x.txt so I don't know
> what is the correct thing to do in this situation.
Take the view the old version is wrong but needs to be supported and add also
the corrected strings + document them.

cc'd The device tree list for any more comments on this.
> 
> Changing the compatible string will break old DTB with newer kernels and that
> is a no go. But that doesn't invalidate what I said since once the SPI core
> is changed and report OF modalias, you will need a MODULE_DEVICE_TABLE(of,...)
> regardless if the compatible string has a vendor prefix or not.
> 
> [0]: https://www.power.org/documentation/epapr-version-1-1/
> 
> Best regards,
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/7] iio: Support triggered events

[Jonathan Cameron]

On 16/08/15 21:15, Vladimir Barinov wrote:
> Hi Jonathan,
> 
> Thank you for review.
> Find some comments below.
> 
> Regards,
> Vladimir
> 
> On 16.08.2015 12:20, Jonathan Cameron wrote:
>> On 29/07/15 13:57, Vladimir Barinov wrote:
>>> Support triggered events.
>>>
>>> This is useful for chips that don't have their own interrupt sources.
>>> It allows to use generic/standalone iio triggers for those drivers.
>> As we have concluded this is a good thing to have, I've take a closer
>> look at it.
>>
>> I think we need to slightly separate the buffer and event uses of
>> triggers as it's entirely plausible both might be enabled at the same
>> time.  Don't think this should be hard however.
>>
>> I can concieve of weird restrictions from certain hardware (particularly
>> where hardware buffers are concerned) in which events are not monitored
>> when we are reading through the buffer but we can tackle that when we
>> actually need to.
>>
>> Anyhow, few bits inline.  Thanks for your persistence with this!
>>
>> Jonathan
>>
>>> Signed-off-by: Vladimir Barinov 
>>> ---
>>> Changes in version 2:
>>> - initially added
>>> Changes in version 3:
>>> - fixed grammar in patch description
>>> - changed license header to match "GNU Public License v2 or later"
>>>
>>>   drivers/iio/Kconfig|  6 +++
>>>   drivers/iio/Makefile   |  1 +
>>>   drivers/iio/industrialio-core.c|  4 +-
>>>   drivers/iio/industrialio-trigger.c | 12 +-
>>>   drivers/iio/industrialio-triggered-event.c | 68 
>>> ++
>>>   include/linux/iio/iio.h|  1 +
>>>   include/linux/iio/triggered_event.h| 11 +
>>>   7 files changed, 99 insertions(+), 4 deletions(-)
>>>   create mode 100644 drivers/iio/industrialio-triggered-event.c
>>>   create mode 100644 include/linux/iio/triggered_event.h
>>>
>>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>>> index 4011eff..8fcc92f 100644
>>> --- a/drivers/iio/Kconfig
>>> +++ b/drivers/iio/Kconfig
>>> @@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
>>>   This value controls the maximum number of consumers that a
>>>   given trigger may handle. Default is 2.
>>>   +config IIO_TRIGGERED_EVENT
>>> +tristate
>>> +select IIO_TRIGGER
>>> +help
>>> +  Provides helper functions for setting up triggered events.
>>> +
>>>   source "drivers/iio/accel/Kconfig"
>>>   source "drivers/iio/adc/Kconfig"
>>>   source "drivers/iio/amplifiers/Kconfig"
>>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>>> index 698afc2..40dc13e 100644
>>> --- a/drivers/iio/Makefile
>>> +++ b/drivers/iio/Makefile
>>> @@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
>>>   industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
>>> obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
>>> +obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
>>>   obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
>>> obj-y += accel/
>>> diff --git a/drivers/iio/industrialio-core.c 
>>> b/drivers/iio/industrialio-core.c
>>> index 3524b0d..54d71ea 100644
>>> --- a/drivers/iio/industrialio-core.c
>>> +++ b/drivers/iio/industrialio-core.c
>>> @@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
>>> *indio_dev)
>>>   static void iio_dev_release(struct device *device)
>>>   {
>>>   struct iio_dev *indio_dev = dev_to_iio_dev(device);
>>> -if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
>>> +if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | 
>>> INDIO_EVENT_TRIGGERED))
>>>   iio_device_unregister_trigger_consumer(indio_dev);
>>>   iio_device_unregister_eventset(indio_dev);
>>>   iio_device_unregister_sysfs(indio_dev);
>>> @@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
>>>   "Failed to register event set\n");
>>>   goto error_free_sysfs;
>>>   }
>>> -if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
>>> +if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | 
>>> INDIO_EVENT_TRIGGERED))

Re: [PATCH v3 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector

[Jonathan Cameron]

On 16/08/15 19:54, Vladimir Barinov wrote:
> Hi Jonathan,
> 
> On 16.08.2015 12:00, Jonathan Cameron wrote:
>> On 11/08/15 15:37, Vladimir Barinov wrote:
>>> Hi Jonathan,
>>>
>>> Thank you for the review.
>> Sorry I was being so indecisive.  Always take a while when something
>> 'new' turns up to gather opinions and select the best option.  You
>> are just the unlucky guy who happened to hit the question first!
>>
>> Anyhow, I'm basically happy (now) with the events approach though
>> I would suggest some modifications to how exactly it is done
>> (see inline).
> Nice to hear!
> I've got some light in the tunnel :)
Yeah, sorry it took so long to pin down the approach!
> 
> Thank you for dealing with this stuff.
> Please find one minor questions below.
> 
> Regards,
> Vladimir
> 
>>
>> Jonathan
>>> On 08.08.2015 20:56, Jonathan Cameron wrote:
>>>> On 29/07/15 13:56, Vladimir Barinov wrote:
>>>>> Add Holt threshold detector driver for HI-8435 chip
>>>>>
>>>>> Signed-off-by: Vladimir Barinov 
>>>> Because it usually reads better that way, I review from the bottom.
>>>> Might make more sense if you read the comments that way around ;)
>>> I did try to match this way.
>>> At some places the comments below the code, but in other places the 
>>> comments are above the code :)
>> Yeah, I've never been consistent ;)
>>>> I'm going to guess that the typical usecase for this device is in realtime
>>>> systems where polling gives a nice predictable timing (hence the lack of 
>>>> any
>>>> interrupt support).  These typically operate as 'scanning' devices
>>>> (e.g. you update all state at approximately the same time, by reading
>>>> one input after another in some predefined order).
>>> Probably you are right about 8435 h/w design or there were other
>>> reason why this functionality was dropped in comparison to 8429
>>> chip. The Holt chip hi-8429 has both hardware interrupt and hardware
>>> debounce enable lines, but it has less amount of sensors (just 8
>>> outputs).
>>>> Does the use of events actually map well to this use case?  You are taking
>>>> something that (other than the results being a bit different) is basically
>>>> a digital I/O interface and mapping it (sort of) to an interrupt chip
>>>> when it isn't nothing of the sort.
>>> a) Using hardware point of view.
>>>
>>> I was thinking that it matches the events a little bit more then
>>> buffer, because the chip senses for threshold changes (passing
>>> threshold high or threshold low margins) and then notifies the upper
>>> layer. The bad point here is that the chip does not have interrupt
>>> line for sensor state change (i.e. threshold passing).
>>>
>>> If it would have the interrupt line for sensor state changes then the
>>> event interface map this case best way.
>> Agreed.  I'm coming round to the argument Lars made that we should end
>> up with the interface being the same whether or not there is an interrupt
>> there.  Actually I suspect in the long run we will end up with both
>> a buffered interface and an event interface as they simply have different
>> usecases for the same hardware (which is why we are having these lengthy
>> discussions in the first place!)
>>
>>> b) Using s/w point of view
>>>
>>> I answer relying on current iio stack implementation. I do understand
>>> that the 8435 chip is not the common/usual iio client like
>>> adc/dac/light/others, so I'm trying to match the existent iio stack.
>> Yes.  It's certainly throwing up lots of questions!
>>>  From s/w point of view it does not matter much difference between
>>> event or buffer interface for this chip because in provides 1-bit
>>> change and does not have it's own interrupt source line.
>> Yes, just requires the userspace side to track the state if it wants
>> to know.  Actually the one nasty is initialization. When the events
>> are first enabled I guess we fire them all once (if any limits are currently
>> breached).  That way the state can always be known.
>>> The event interface has generic interface to fill in falling/rising
>>> thresholds but buffer interface does not.
>> We can always add more ABI.
>>
>>> The buffer interface has already has the trigger poll func support
>>> but event interface does not. So I'

Re: [PATCH v3 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor

[Jonathan Cameron]

On 18 August 2015 16:13:02 BST, Adriana Reus  wrote:
>
>Thank you Jonathan, I'll add a new patch set soon, added some comments 
>inline also.
>
>Adriana
>On 15.08.2015 17:31, Jonathan Cameron wrote:
>> On 14/08/15 10:29, Adriana Reus wrote:
>>> Added entries in trivial-devices and i2c/vendor-prefixes for
>>> the us5182d als and proximity sensor. Also added a documentation
>file for
>>> this sensor's properties.
>>>
>>> Signed-off-by: Adriana Reus 
>> It's not a trivial device if it has it's own docs.  So don't add it
>to that list
>> (the point is to not have separate docs for devices that don't really
>have
>> any device tree data other than where they are.
>right, I'll add a new path set soon.
>>
>> Few more bits inline.
>>> ---
>>>No changes - resending because I forgot to cc devicetree.
>>>   .../devicetree/bindings/i2c/trivial-devices.txt|  1 +
>>>   .../devicetree/bindings/iio/light/us5182d.txt  | 24
>++
>>>   .../devicetree/bindings/vendor-prefixes.txt|  1 +
>>>   3 files changed, 26 insertions(+)
>>>   create mode 100644
>Documentation/devicetree/bindings/iio/light/us5182d.txt
>>>
>>> diff --git
>a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>>> index 00f8652..96d3b9c 100644
>>> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>>> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
>>> @@ -99,4 +99,5 @@ ti,tsc2003I2C Touch-Screen Controller
>>>   ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two
>Wire Serial Interface
>>>   ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two
>Wire Serial Interface
>>>   ti,tmp275 Digital Temperature Sensor
>>> +upisemi,usd5182Als and Proximity Sensor
>>>   winbond,wpct301   i2c trusted platform module (TPM)
>>> diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt
>b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>> new file mode 100644
>>> index 000..9ac3336
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
>>> @@ -0,0 +1,24 @@
>>> +* UPISEMI us5182d I2C ALS and Proximity sensor
>>> +
>>> +Required properties:
>>> +- compatible: must be "upisemi,usd5182"
>>> +- reg: the I2C address of the device
>>> +
>>> +Optional properties:
>>> +- upisemi,glass-coef: glass attenuation factor
>>> +- upisemi,dark-ths: array of thresholds corresponding to every
>scale
>> That needs more detail. I've read the driver and I am not sure what
>exactly
>> you mean!  Why should a scale have a threshold?
>I'll try to be more specific. These are values representing adc counts,
>
>that's why there are different values corresponding to every scale.
>>> +- upisemi,upper-dark-gain: tuning factor applied when light > th
>>> +- upisemi,lower-dark-gain: tuning factor applied when light < th
>>> +
>>> +Example:
>>> +
>>> +usd5182@39 {
>>> +compatible = "upisemi,usd5182";
>>> +reg = <0x39>;
>>> +upisemi,glass-coef = < 1000 >;
>>> +upisemi,dark-ths = /bits/ 16 <170 200 512 512 800
>2000 4000 8000>;
>>> +upisemi,upper-dark-gain = /bits/ 8 <0x00>;
>>> +upisemi,lower-dark-gain = /bits/ 8 <0x16>;
>> Not sure why these are in hex.. Or why we care if they are 8 bits. 
>If there is a limit
>> on the possible values, perhaps mention it in the docs above.
>I should have been (much) more specific here: that represents a float 
>number with 4 integer bits and 4 fractional bits (Q4.4), so I find hex 
>more intuitive since it's split in half, let me know if you think 
>otherwise. 
One for the device tree guys to answer rather than me.  My gut feeling would be
a representation that made this obvious but I have no idea what normal choice 
would be.
>I'll add a more complete description. As for the "/bits/ x" 
>it's because currently in the driver I use the read_property_u8 or
>*_u16 
>functions, these require that the dts entry be as I wrote it in the 
>example, and since it's an example it should be functional, so I feel 
>that is ok as it is.
>>
>>
>>> +};
>>>

Re: [PATCH v3 1/2] iio: light: Add support for UPISEMI uS5182d als and proximity sensor

[Jonathan Cameron]

On 18 August 2015 16:28:20 BST, Adriana Reus  wrote:
>Thanks for the review, added some comments inline, next patch set
>coming 
>soon.
>
>Adriana
>
>On 15.08.2015 17:27, Jonathan Cameron wrote:
>> On 14/08/15 10:29, Adriana Reus wrote:
>>> Add support for UPISEMI us5182d als and proximity sensor.
>>> Supports raw readings.
>>> Data sheet for this device can be found here:
>>> http://www.upi-semi.com/temp/uS5182D-DS-P0103-temp.pdf
>>>
>>> Signed-off-by: Adriana Reus 
>> Mostly looking pretty good.  I've partly been (slightly) pickier than
>normal
>> here because we are stalled for a few weeks anyway by the fact the
>merge
>> window for IIO is now probably done (about a week before Linus opens
>his)
>> and also we have device tree docs that will need comments or to sit
>for
>> quite a while on the mailing list.
>>
>> Thanks,
>>
>> Jonathan
>>> ---
>>> Changes since v2:
>>>   - Adressed Peter's comments (with the exception of setting
>>> the ths_vals array as const - if I do that the compiler will
>>> eventually whine because it gets passed as an argument to
>device_property_read).
>> That should be a giveaway that you want to have a copy rather than
>one
>> instance of this.  Stick a copy in your data structure with defaults
>> if no others are supplied.
>>
>> Note we might have two different instances of this part on one device
>> with different thresholds...
>>
>>
>>>   - Tried to break down the compound register values into more
>intuitive definitions.
>> Much improved .
>>>   - Eliminated the read helper functions.
>>>
>>>   drivers/iio/light/Kconfig   |  10 +
>>>   drivers/iio/light/Makefile  |   1 +
>>>   drivers/iio/light/us5182d.c | 484
>
>>>   3 files changed, 495 insertions(+)
>>>   create mode 100644 drivers/iio/light/us5182d.c
>>>
>>> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
>>> index 7ed859a..0442f01 100644
>>> --- a/drivers/iio/light/Kconfig
>>> +++ b/drivers/iio/light/Kconfig
>>> @@ -287,6 +287,16 @@ config TSL4531
>>>  To compile this driver as a module, choose M here: the
>>>  module will be called tsl4531.
>>>
>>> +config US5182D
>>> +   tristate "UPISEMI light and proximity sensor"
>>> +   depends on I2C
>>> +   help
>>> +If you say yes here you get support for the UPISEMI US5182D
>>> +ambient light and proximity sensor.
>>> +
>>> +This driver can also be built as a module.  If so, the module
>>> +will be called us5182d.
>>> +
>>>   config VCNL4000
>>> tristate "VCNL4000 combined ALS and proximity sensor"
>>> depends on I2C
>>> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
>>> index 91c74c0..528cc8f 100644
>>> --- a/drivers/iio/light/Makefile
>>> +++ b/drivers/iio/light/Makefile
>>> @@ -27,4 +27,5 @@ obj-$(CONFIG_STK3310)  += stk3310.o
>>>   obj-$(CONFIG_TCS3414) += tcs3414.o
>>>   obj-$(CONFIG_TCS3472) += tcs3472.o
>>>   obj-$(CONFIG_TSL4531) += tsl4531.o
>>> +obj-$(CONFIG_US5182D)  += us5182d.o
>>>   obj-$(CONFIG_VCNL4000)+= vcnl4000.o
>>> diff --git a/drivers/iio/light/us5182d.c
>b/drivers/iio/light/us5182d.c
>>> new file mode 100644
>>> index 000..9ba99f5
>>> --- /dev/null
>>> +++ b/drivers/iio/light/us5182d.c
>>> @@ -0,0 +1,484 @@
>>> +/*
>>> + * Copyright (c) 2015 Intel Corporation
>>> + *
>>> + * Driver for UPISEMI us5182d Proximity and Ambient Light Sensor.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>modify it
>>> + * under the terms of the GNU General Public License version 2 as
>published by
>>> + * the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope it will be useful, but
>WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of
>MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>License for
>>> + * more details.
>>> + *
>>> + * To do: Interrupt support.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> 

Re: [PATCH v3 5/7] iio: Support triggered events

[Jonathan Cameron]

On 29/07/15 13:57, Vladimir Barinov wrote:
> Support triggered events.
> 
> This is useful for chips that don't have their own interrupt sources.
> It allows to use generic/standalone iio triggers for those drivers.
As we have concluded this is a good thing to have, I've take a closer
look at it.

I think we need to slightly separate the buffer and event uses of
triggers as it's entirely plausible both might be enabled at the same
time.  Don't think this should be hard however.

I can concieve of weird restrictions from certain hardware (particularly
where hardware buffers are concerned) in which events are not monitored
when we are reading through the buffer but we can tackle that when we
actually need to.

Anyhow, few bits inline.  Thanks for your persistence with this!

Jonathan

> 
> Signed-off-by: Vladimir Barinov 
> ---
> Changes in version 2:
> - initially added
> Changes in version 3:
> - fixed grammar in patch description
> - changed license header to match "GNU Public License v2 or later"
> 
>  drivers/iio/Kconfig|  6 +++
>  drivers/iio/Makefile   |  1 +
>  drivers/iio/industrialio-core.c|  4 +-
>  drivers/iio/industrialio-trigger.c | 12 +-
>  drivers/iio/industrialio-triggered-event.c | 68 
> ++
>  include/linux/iio/iio.h|  1 +
>  include/linux/iio/triggered_event.h| 11 +
>  7 files changed, 99 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/iio/industrialio-triggered-event.c
>  create mode 100644 include/linux/iio/triggered_event.h
> 
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 4011eff..8fcc92f 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
>   This value controls the maximum number of consumers that a
>   given trigger may handle. Default is 2.
>  
> +config IIO_TRIGGERED_EVENT
> + tristate
> + select IIO_TRIGGER
> + help
> +   Provides helper functions for setting up triggered events.
> +
>  source "drivers/iio/accel/Kconfig"
>  source "drivers/iio/adc/Kconfig"
>  source "drivers/iio/amplifiers/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index 698afc2..40dc13e 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
>  industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
>  
>  obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
> +obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
>  obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
>  
>  obj-y += accel/
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 3524b0d..54d71ea 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev 
> *indio_dev)
>  static void iio_dev_release(struct device *device)
>  {
>   struct iio_dev *indio_dev = dev_to_iio_dev(device);
> - if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
> + if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
>   iio_device_unregister_trigger_consumer(indio_dev);
>   iio_device_unregister_eventset(indio_dev);
>   iio_device_unregister_sysfs(indio_dev);
> @@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
>   "Failed to register event set\n");
>   goto error_free_sysfs;
>   }
> - if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
> + if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
>   iio_device_register_trigger_consumer(indio_dev);
>  
>   if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
> diff --git a/drivers/iio/industrialio-trigger.c 
> b/drivers/iio/industrialio-trigger.c
> index d31098e..72b63e7 100644
> --- a/drivers/iio/industrialio-trigger.c
> +++ b/drivers/iio/industrialio-trigger.c
> @@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device 
> *dev,
>  
>   indio_dev->trig = trig;
>  
> - if (oldtrig)
> + if (oldtrig) {
> + if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
> + iio_trigger_detach_poll_func(oldtrig,
> +  indio_dev->pollfunc);
>   iio_trigger_put(oldtrig);
> - if (indio_dev->trig)
> + }
> + if (indio_dev->trig) {
>   iio_trigger_get(indio_dev->trig);
> + if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
> + iio_trigger_attach_poll_func(indio_dev->trig,
> +  indio_dev->pollfunc);
> + }
>  
>   return len;
>  }
> diff --git a/drivers/iio/industrialio-triggered-event.c 
> b/drivers/iio/industrialio-triggered-event.c
> new file mode 100644
> index 00

Re: [PATCH v3 5/7] iio: Support triggered events

[Jonathan Cameron]

Vladimir - before I forget, could you try to wrap emails to around 
80 characters per line.  Otherwise we end up with really tricky
to read thread when some are doing so and others aren't!

On 07/08/15 17:10, Vladimir Barinov wrote:
> Hi Lars,
> 
> On 07.08.2015 16:45, Lars-Peter Clausen wrote:
>> Hi,
>>
>> On 07/29/2015 02:57 PM, Vladimir Barinov wrote:
>>> Support triggered events.
>>>
>>> This is useful for chips that don't have their own interrupt sources.
>>> It allows to use generic/standalone iio triggers for those drivers.
>>>
>> Thanks for the patch. Can you describe in more detail how
>> INDIO_EVENT_TRIGGERED differs from the INDIO_BUFFER_TRIGGERED. By just
>> looking at the source code I don't understand quite why it is necessary.
> This is needed for the case when iio buffer is not used and used only
> iio event.
> 
> The difference to INDIO_BUFFER_TRIGGERED is that for triggered buffer
> the trigger poll function is attached (using
> iio_trigger_attach_poll_func) only in industrialio-buffer.c using
> number of steps/conditions starting by issuing 1 to buffer/enable
> sysfs path.
> 
> For chips that do not use iio buffer but use only iio events the
> iio_trigger_attach_poll_func never called.
> 
> In case of using INDIO_BUFFER_TRIGGERED the poll func is
> attached/detached via industrialio-buffer.c In case of using
> INDIO_EVENT_TRIGGERED the poll func is attached/detached via
> industrialio-trigger.c during set/change the current trigger.
> 
> Regards, Vladimir
You've convinced Lars and I agree with his argument that this
is a sensible addition to IIO.
> 

>> Thanks,
>> - Lars
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector

[Jonathan Cameron]

On 11/08/15 15:37, Vladimir Barinov wrote:
> Hi Jonathan,
> 
> Thank you for the review.
Sorry I was being so indecisive.  Always take a while when something
'new' turns up to gather opinions and select the best option.  You
are just the unlucky guy who happened to hit the question first!

Anyhow, I'm basically happy (now) with the events approach though
I would suggest some modifications to how exactly it is done
(see inline).

Jonathan
> 
> On 08.08.2015 20:56, Jonathan Cameron wrote:
>> On 29/07/15 13:56, Vladimir Barinov wrote:
>>> Add Holt threshold detector driver for HI-8435 chip
>>>
>>> Signed-off-by: Vladimir Barinov 
>> Because it usually reads better that way, I review from the bottom.
>> Might make more sense if you read the comments that way around ;)
> I did try to match this way.
> At some places the comments below the code, but in other places the comments 
> are above the code :)
Yeah, I've never been consistent ;)
>>
>> I'm going to guess that the typical usecase for this device is in realtime
>> systems where polling gives a nice predictable timing (hence the lack of any
>> interrupt support).  These typically operate as 'scanning' devices
>> (e.g. you update all state at approximately the same time, by reading
>> one input after another in some predefined order).
> Probably you are right about 8435 h/w design or there were other
> reason why this functionality was dropped in comparison to 8429
> chip. The Holt chip hi-8429 has both hardware interrupt and hardware
> debounce enable lines, but it has less amount of sensors (just 8
> outputs).
>>
>> Does the use of events actually map well to this use case?  You are taking
>> something that (other than the results being a bit different) is basically
>> a digital I/O interface and mapping it (sort of) to an interrupt chip
>> when it isn't nothing of the sort.
> a) Using hardware point of view.
> 
> I was thinking that it matches the events a little bit more then
> buffer, because the chip senses for threshold changes (passing
> threshold high or threshold low margins) and then notifies the upper
> layer. The bad point here is that the chip does not have interrupt
> line for sensor state change (i.e. threshold passing).
>
> If it would have the interrupt line for sensor state changes then the
> event interface map this case best way.
Agreed.  I'm coming round to the argument Lars made that we should end
up with the interface being the same whether or not there is an interrupt
there.  Actually I suspect in the long run we will end up with both
a buffered interface and an event interface as they simply have different
usecases for the same hardware (which is why we are having these lengthy
discussions in the first place!)

> b) Using s/w point of view
> 
> I answer relying on current iio stack implementation. I do understand
> that the 8435 chip is not the common/usual iio client like
> adc/dac/light/others, so I'm trying to match the existent iio stack.
Yes.  It's certainly throwing up lots of questions!
> 
> From s/w point of view it does not matter much difference between
> event or buffer interface for this chip because in provides 1-bit
> change and does not have it's own interrupt source line.
Yes, just requires the userspace side to track the state if it wants
to know.  Actually the one nasty is initialization. When the events
are first enabled I guess we fire them all once (if any limits are currently
breached).  That way the state can always be known.
>
> The event interface has generic interface to fill in falling/rising
> thresholds but buffer interface does not.
We can always add more ABI.

> The buffer interface has already has the trigger poll func support
> but event interface does not. So I've tried to implement the
> triggered event in iio stack. BTW: Doesn't the triggered event
> support match the usecase with iio_interrupt_trigger? Or it does not
> make sense to have triggered events (even with irqtrig) at all?
Initially I was unsure about this, but Lars and you have convinced me.
I'm happy having that in the subsystem.  Can also be used for devices
which have an interrupt but which didn't get wired for some reason rather
than having them have some internal poll loop (as we have done up to now).

 
>>
>> I'd like more opinions on this, but my gut reaction is that we would
>> be better making the normal buffered infrastructure handle this data
>> properly rather than pushing it through the events intrastructure.
>>
>> Your solution is neat and tidy in someways but feels like it is mashing
>> data into a particular format.
> Probably that's all because the chip lac