Re: [PATCH v2 1/2] iio: stm32 trigger: Add quadrature encoder device

[Michael Welling]

On Sat, Mar 25, 2017 at 06:26:05PM +, Jonathan Cameron wrote:
> On 24/03/17 14:00, Benjamin Gaignard wrote:
> > One of the features of STM32 trigger hardware block is a quadrature
> > encoder that can counts up/down depending of the levels and edges
> > of the selected external pins.
> > 
> > This patch allow to read/write the counter, get it direction,
> > set/get quadrature modes and get scale factor.
> > 
> > When counting up preset value is the limit of the counter.
> > When counting down the counter start from preset value down to 0.
> > This preset value could be set/get by using
> > /sys/bus/iio/devices/iio:deviceX/in_count0_preset attribute.
> > 
> > Signed-off-by: Benjamin Gaignard <benjamin.gaign...@st.com>
> A few little nitpicks.
> 
> Otherwise I like this.  Would love William to give another review
> though if he has time.
> 
> I've tacked Michael Welling on the cc list as well as he has offered
> to help the beaglebone lot upstream some drivers, including the
> eqep quadrature encoder drivers - so he can poke the right people
> to get some review of the ABI from their point of view as well.
>

BTW here is the out of tree module that will be converted to IIO eventually.
https://github.com/Teknoman117/beaglebot/tree/master/encoders

There are probably more requirements to encapsulate all of the features of the 
eQEP.
 
> Thanks
> 
> Jonathan 
> > ---
> >  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  32 +++
> >  drivers/iio/trigger/stm32-timer-trigger.c  | 244 
> > -
> >  include/linux/mfd/stm32-timers.h   |   2 +
> >  3 files changed, 272 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 
> > b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > index 6534a60..fbdee4f 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > @@ -27,3 +27,35 @@ Description:
> > Reading returns the current sampling frequency.
> > Writing an value different of 0 set and start sampling.
> > Writing 0 stop sampling.
> > +
> > +What:  /sys/bus/iio/devices/iio:deviceX/in_count0_preset
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Reading returns the current preset value.
> > +   Writing set the preset value.
> > +   When counting up the counter start from 0 and fire an event 
> > when reach preset value.
> > +   When counting down the counter start from preset value and fire 
> > event when reach 0.
> We'll want to generalize that description at some point as it's most often 
> used as a place to reset
> too on an event (homing switch or similar)
> > +
> > +What:  
> > /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Reading returns the list possible quadrature modes.
> > +
> > +What:  
> > /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Configure the device counter quadrature modes:
> > +   channel_A:
> > +   Encoder A input severs as the count input and B as
> > +   the UP/DOWN direction control input.
> > +
> > +   channel_B:
> > +   Encoder B input severs as the count input and A as
> > +   the UP/DOWN direction control input.
> > +
> > +   quadrature:
> > +   Encoder A and B inputs are mixed to get direction
> > +   and count with a scale of 0.25.
> Whilst the quadrature mode is always with that scale on this device, we should
> as discussed be explicitly providing access to the scale so that we can
> cope with different scales on different devices.  As such the docs here
> shouldn't mention it.
> 
> I'm keen to get these docs straight into sysfs-bus-iio or perhaps
> sysfs-bus-iio-encoder-counter asap so good to write them with that at the
> front of your mind.
> 
> > diff --git a/drivers/iio/trigger/stm32-timer-trigger.c 
> > b/drivers/iio/trigger/stm32-timer-trigger.c
> > index 994b96d..48d2bf9 100644
> > --- a/drivers/iio/trigger/stm32-timer-trigger.c
> > +++ b/drivers/iio/trigger/stm32-timer-trigger.c
> >

Re: [PATCH v2 1/2] iio: stm32 trigger: Add quadrature encoder device

[Michael Welling]

On Sat, Mar 25, 2017 at 06:26:05PM +, Jonathan Cameron wrote:
> On 24/03/17 14:00, Benjamin Gaignard wrote:
> > One of the features of STM32 trigger hardware block is a quadrature
> > encoder that can counts up/down depending of the levels and edges
> > of the selected external pins.
> > 
> > This patch allow to read/write the counter, get it direction,
> > set/get quadrature modes and get scale factor.
> > 
> > When counting up preset value is the limit of the counter.
> > When counting down the counter start from preset value down to 0.
> > This preset value could be set/get by using
> > /sys/bus/iio/devices/iio:deviceX/in_count0_preset attribute.
> > 
> > Signed-off-by: Benjamin Gaignard 
> A few little nitpicks.
> 
> Otherwise I like this.  Would love William to give another review
> though if he has time.
> 
> I've tacked Michael Welling on the cc list as well as he has offered
> to help the beaglebone lot upstream some drivers, including the
> eqep quadrature encoder drivers - so he can poke the right people
> to get some review of the ABI from their point of view as well.
>

BTW here is the out of tree module that will be converted to IIO eventually.
https://github.com/Teknoman117/beaglebot/tree/master/encoders

There are probably more requirements to encapsulate all of the features of the 
eQEP.
 
> Thanks
> 
> Jonathan 
> > ---
> >  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  32 +++
> >  drivers/iio/trigger/stm32-timer-trigger.c  | 244 
> > -
> >  include/linux/mfd/stm32-timers.h   |   2 +
> >  3 files changed, 272 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 
> > b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > index 6534a60..fbdee4f 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > @@ -27,3 +27,35 @@ Description:
> > Reading returns the current sampling frequency.
> > Writing an value different of 0 set and start sampling.
> > Writing 0 stop sampling.
> > +
> > +What:  /sys/bus/iio/devices/iio:deviceX/in_count0_preset
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Reading returns the current preset value.
> > +   Writing set the preset value.
> > +   When counting up the counter start from 0 and fire an event 
> > when reach preset value.
> > +   When counting down the counter start from preset value and fire 
> > event when reach 0.
> We'll want to generalize that description at some point as it's most often 
> used as a place to reset
> too on an event (homing switch or similar)
> > +
> > +What:  
> > /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Reading returns the list possible quadrature modes.
> > +
> > +What:  
> > /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Configure the device counter quadrature modes:
> > +   channel_A:
> > +   Encoder A input severs as the count input and B as
> > +   the UP/DOWN direction control input.
> > +
> > +   channel_B:
> > +   Encoder B input severs as the count input and A as
> > +   the UP/DOWN direction control input.
> > +
> > +   quadrature:
> > +   Encoder A and B inputs are mixed to get direction
> > +   and count with a scale of 0.25.
> Whilst the quadrature mode is always with that scale on this device, we should
> as discussed be explicitly providing access to the scale so that we can
> cope with different scales on different devices.  As such the docs here
> shouldn't mention it.
> 
> I'm keen to get these docs straight into sysfs-bus-iio or perhaps
> sysfs-bus-iio-encoder-counter asap so good to write them with that at the
> front of your mind.
> 
> > diff --git a/drivers/iio/trigger/stm32-timer-trigger.c 
> > b/drivers/iio/trigger/stm32-timer-trigger.c
> > index 994b96d..48d2bf9 100644
> > --- a/drivers/iio/trigger/stm32-timer-trigger.c
> > +++ b/drivers/iio/trigger/stm32-timer-trigger.c
> > @@ -15,6 +15,7 @@
> >  #include 

Re: [PATCH v2 1/2] iio: stm32 trigger: Add quadrature encoder device

[Michael Welling]

On Sat, Mar 25, 2017 at 06:26:05PM +, Jonathan Cameron wrote:
> On 24/03/17 14:00, Benjamin Gaignard wrote:
> > One of the features of STM32 trigger hardware block is a quadrature
> > encoder that can counts up/down depending of the levels and edges
> > of the selected external pins.
> > 
> > This patch allow to read/write the counter, get it direction,
> > set/get quadrature modes and get scale factor.
> > 
> > When counting up preset value is the limit of the counter.
> > When counting down the counter start from preset value down to 0.
> > This preset value could be set/get by using
> > /sys/bus/iio/devices/iio:deviceX/in_count0_preset attribute.
> > 
> > Signed-off-by: Benjamin Gaignard <benjamin.gaign...@st.com>
> A few little nitpicks.
> 
> Otherwise I like this.  Would love William to give another review
> though if he has time.
> 
> I've tacked Michael Welling on the cc list as well as he has offered
> to help the beaglebone lot upstream some drivers, including the
> eqep quadrature encoder drivers - so he can poke the right people
> to get some review of the ABI from their point of view as well.
> 
> Thanks
> 
> Jonathan 
> > ---
> >  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  32 +++
> >  drivers/iio/trigger/stm32-timer-trigger.c  | 244 
> > -
> >  include/linux/mfd/stm32-timers.h   |   2 +
> >  3 files changed, 272 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 
> > b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > index 6534a60..fbdee4f 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > @@ -27,3 +27,35 @@ Description:
> > Reading returns the current sampling frequency.
> > Writing an value different of 0 set and start sampling.
> > Writing 0 stop sampling.
> > +
> > +What:  /sys/bus/iio/devices/iio:deviceX/in_count0_preset
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Reading returns the current preset value.
> > +   Writing set the preset value.

Writing sets the preset value.

> > +   When counting up the counter start from 0 and fire an event 
> > when reach preset value.

... the counter starts from 0 and fires an event ...

> > +   When counting down the counter start from preset value and fire 
> > event when reach 0.
> We'll want to generalize that description at some point as it's most often 
> used as a place to reset
> too on an event (homing switch or similar)
> > +
> > +What:  
> > /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Reading returns the list possible quadrature modes.
> > +
> > +What:  
> > /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Configure the device counter quadrature modes:
> > +   channel_A:
> > +   Encoder A input severs as the count input and B as

Encoder A input serves ...

> > +   the UP/DOWN direction control input.
> > +
> > +   channel_B:
> > +   Encoder B input severs as the count input and A as

Encoder B input serves ...

> > +   the UP/DOWN direction control input.
> > +
> > +   quadrature:
> > +   Encoder A and B inputs are mixed to get direction
> > +   and count with a scale of 0.25.
> Whilst the quadrature mode is always with that scale on this device, we should
> as discussed be explicitly providing access to the scale so that we can
> cope with different scales on different devices.  As such the docs here
> shouldn't mention it.
> 
> I'm keen to get these docs straight into sysfs-bus-iio or perhaps
> sysfs-bus-iio-encoder-counter asap so good to write them with that at the
> front of your mind.
> 
> > diff --git a/drivers/iio/trigger/stm32-timer-trigger.c 
> > b/drivers/iio/trigger/stm32-timer-trigger.c
> > index 994b96d..48d2bf9 100644
> > --- a/drivers/iio/trigger/stm32-timer-trigger.c
> > +++ b/drivers/iio/trigger/stm32-timer-trigger.c
> > @@ -15,6 +15,7 @@
> >  #include 
> >  
> >  #define MAX_TRIGGERS 6
>

Re: [PATCH v2 1/2] iio: stm32 trigger: Add quadrature encoder device

[Michael Welling]

On Sat, Mar 25, 2017 at 06:26:05PM +, Jonathan Cameron wrote:
> On 24/03/17 14:00, Benjamin Gaignard wrote:
> > One of the features of STM32 trigger hardware block is a quadrature
> > encoder that can counts up/down depending of the levels and edges
> > of the selected external pins.
> > 
> > This patch allow to read/write the counter, get it direction,
> > set/get quadrature modes and get scale factor.
> > 
> > When counting up preset value is the limit of the counter.
> > When counting down the counter start from preset value down to 0.
> > This preset value could be set/get by using
> > /sys/bus/iio/devices/iio:deviceX/in_count0_preset attribute.
> > 
> > Signed-off-by: Benjamin Gaignard 
> A few little nitpicks.
> 
> Otherwise I like this.  Would love William to give another review
> though if he has time.
> 
> I've tacked Michael Welling on the cc list as well as he has offered
> to help the beaglebone lot upstream some drivers, including the
> eqep quadrature encoder drivers - so he can poke the right people
> to get some review of the ABI from their point of view as well.
> 
> Thanks
> 
> Jonathan 
> > ---
> >  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  32 +++
> >  drivers/iio/trigger/stm32-timer-trigger.c  | 244 
> > -
> >  include/linux/mfd/stm32-timers.h   |   2 +
> >  3 files changed, 272 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 
> > b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > index 6534a60..fbdee4f 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> > @@ -27,3 +27,35 @@ Description:
> > Reading returns the current sampling frequency.
> > Writing an value different of 0 set and start sampling.
> > Writing 0 stop sampling.
> > +
> > +What:  /sys/bus/iio/devices/iio:deviceX/in_count0_preset
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Reading returns the current preset value.
> > +   Writing set the preset value.

Writing sets the preset value.

> > +   When counting up the counter start from 0 and fire an event 
> > when reach preset value.

... the counter starts from 0 and fires an event ...

> > +   When counting down the counter start from preset value and fire 
> > event when reach 0.
> We'll want to generalize that description at some point as it's most often 
> used as a place to reset
> too on an event (homing switch or similar)
> > +
> > +What:  
> > /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Reading returns the list possible quadrature modes.
> > +
> > +What:  
> > /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
> > +KernelVersion: 4.12
> > +Contact:   benjamin.gaign...@st.com
> > +Description:
> > +   Configure the device counter quadrature modes:
> > +   channel_A:
> > +   Encoder A input severs as the count input and B as

Encoder A input serves ...

> > +   the UP/DOWN direction control input.
> > +
> > +   channel_B:
> > +   Encoder B input severs as the count input and A as

Encoder B input serves ...

> > +   the UP/DOWN direction control input.
> > +
> > +   quadrature:
> > +   Encoder A and B inputs are mixed to get direction
> > +   and count with a scale of 0.25.
> Whilst the quadrature mode is always with that scale on this device, we should
> as discussed be explicitly providing access to the scale so that we can
> cope with different scales on different devices.  As such the docs here
> shouldn't mention it.
> 
> I'm keen to get these docs straight into sysfs-bus-iio or perhaps
> sysfs-bus-iio-encoder-counter asap so good to write them with that at the
> front of your mind.
> 
> > diff --git a/drivers/iio/trigger/stm32-timer-trigger.c 
> > b/drivers/iio/trigger/stm32-timer-trigger.c
> > index 994b96d..48d2bf9 100644
> > --- a/drivers/iio/trigger/stm32-timer-trigger.c
> > +++ b/drivers/iio/trigger/stm32-timer-trigger.c
> > @@ -15,6 +15,7 @@
> >  #include 
> >  
> >  #define MAX_TRIGGERS 6
> > +#define MAX_VALIDS 5

Re: [PATCH] Input: tsc200x - Report proper input_dev name

[Michael Welling]

On Wed, Jul 20, 2016 at 08:54:05AM +0200, Pavel Machek wrote:
> > By same logic we shouldn't change from TSC200X back to TSC2005 because of
> > people's possibly new setup in the last 9 months.
> 
> That's your, broken logic.
> 
> TSC200X->TSC2005 needs to be fixed, because people seen the TSC2005
> for past few years.
> 
> TSC200X->TSC2004 is just introducing regression, because noone ever
> seen TSC2004, AFAICT.

I am pretty sure no one cares. Escpecially me.

> 
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Input: tsc200x - Report proper input_dev name

[Michael Welling]

On Wed, Jul 20, 2016 at 08:54:05AM +0200, Pavel Machek wrote:
> > By same logic we shouldn't change from TSC200X back to TSC2005 because of
> > people's possibly new setup in the last 9 months.
> 
> That's your, broken logic.
> 
> TSC200X->TSC2005 needs to be fixed, because people seen the TSC2005
> for past few years.
> 
> TSC200X->TSC2004 is just introducing regression, because noone ever
> seen TSC2004, AFAICT.

I am pretty sure no one cares. Escpecially me.

> 
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Input: tsc200x - Report proper input_dev name

[Michael Welling]

On Wed, Jul 20, 2016 at 08:31:06AM +0200, Pavel Machek wrote:
> Hi!
> 
> > Passes input_id struct to the the common probe function for the tsc200x 
> > drivers
> > instead of just the bustype.
> > 
> > This allows for the use of the product variable to set the input_dev->name
> > variable according to the type of touchscreen used.
> > 
> > Signed-off-by: Michael Welling <mwell...@ieee.org>
> > ---
> >  drivers/input/touchscreen/tsc2004.c  | 7 ++-
> >  drivers/input/touchscreen/tsc2005.c  | 7 ++-
> >  drivers/input/touchscreen/tsc200x-core.c | 7 ---
> >  drivers/input/touchscreen/tsc200x-core.h | 2 +-
> >  4 files changed, 17 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/input/touchscreen/tsc2004.c 
> > b/drivers/input/touchscreen/tsc2004.c
> > index 7295c19..6fe55d5 100644
> > --- a/drivers/input/touchscreen/tsc2004.c
> > +++ b/drivers/input/touchscreen/tsc2004.c
> > @@ -22,6 +22,11 @@
> >  #include 
> >  #include "tsc200x-core.h"
> >  
> > +static const struct input_id tsc2004_input_id = {
> > +   .bustype = BUS_I2C,
> > +   .product = 2004,
> > +};
> > +
> >  static int tsc2004_cmd(struct device *dev, u8 cmd)
> >  {
> > u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
> > @@ -42,7 +47,7 @@ static int tsc2004_probe(struct i2c_client *i2c,
> >  const struct i2c_device_id *id)
> >  
> >  {
> > -   return tsc200x_probe(>dev, i2c->irq, BUS_I2C,
> > +   return tsc200x_probe(>dev, i2c->irq, _input_id,
> >  devm_regmap_init_i2c(i2c, _regmap_config),
> >  tsc2004_cmd);
> >  }
> > diff --git a/drivers/input/touchscreen/tsc2005.c 
> > b/drivers/input/touchscreen/tsc2005.c
> > index b9f593d..f2c5f0e 100644
> > --- a/drivers/input/touchscreen/tsc2005.c
> > +++ b/drivers/input/touchscreen/tsc2005.c
> > @@ -24,6 +24,11 @@
> >  #include 
> >  #include "tsc200x-core.h"
> >  
> > +static const struct input_id tsc2005_input_id = {
> > +   .bustype = BUS_SPI,
> > +   .product = 2005,
> > +};
> > +
> >  static int tsc2005_cmd(struct device *dev, u8 cmd)
> >  {
> > u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
> > @@ -62,7 +67,7 @@ static int tsc2005_probe(struct spi_device *spi)
> > if (error)
> > return error;
> >  
> > -   return tsc200x_probe(>dev, spi->irq, BUS_SPI,
> > +   return tsc200x_probe(>dev, spi->irq, _input_id,
> >  devm_regmap_init_spi(spi, _regmap_config),
> >  tsc2005_cmd);
> >  }
> > diff --git a/drivers/input/touchscreen/tsc200x-core.c 
> > b/drivers/input/touchscreen/tsc200x-core.c
> > index 26e81d1b..5e625c4 100644
> > --- a/drivers/input/touchscreen/tsc200x-core.c
> > +++ b/drivers/input/touchscreen/tsc200x-core.c
> > @@ -450,7 +450,7 @@ static void tsc200x_close(struct input_dev *input)
> > mutex_unlock(>mutex);
> >  }
> >  
> > -int tsc200x_probe(struct device *dev, int irq, __u16 bustype,
> > +int tsc200x_probe(struct device *dev, int irq, const struct input_id 
> > *tsc_id,
> >   struct regmap *regmap,
> >   int (*tsc200x_cmd)(struct device *dev, u8 cmd))
> >  {
> > @@ -547,9 +547,10 @@ int tsc200x_probe(struct device *dev, int irq, __u16 
> > bustype,
> > snprintf(ts->phys, sizeof(ts->phys),
> >  "%s/input-ts", dev_name(dev));
> >  
> > -   input_dev->name = "TSC200X touchscreen";
> > +   input_dev->name = devm_kasprintf(dev, GFP_KERNEL, "TSC%04d touchscreen",
> > +   tsc_id->product);
> 
> What about:
> 
>  if (tsc_id->product == 2005)
>   input_dev->name = "TSC2005 touchscreen";
>  else
>   input_dev->name = "TSC200X touchscreen";
> 
> We do want to use 'TSC2005' name for TSC2005, because compatibility,
> but you should keep TSC200X because compatibility. You don't want
> to break people's setups by going from TSC200X to TSC2004.

By same logic we shouldn't change from TSC200X back to TSC2005 because of
people's possibly new setup in the last 9 months.

> 
> Best regards,
>   Pavel
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Input: tsc200x - Report proper input_dev name

[Michael Welling]

On Wed, Jul 20, 2016 at 08:31:06AM +0200, Pavel Machek wrote:
> Hi!
> 
> > Passes input_id struct to the the common probe function for the tsc200x 
> > drivers
> > instead of just the bustype.
> > 
> > This allows for the use of the product variable to set the input_dev->name
> > variable according to the type of touchscreen used.
> > 
> > Signed-off-by: Michael Welling 
> > ---
> >  drivers/input/touchscreen/tsc2004.c  | 7 ++-
> >  drivers/input/touchscreen/tsc2005.c  | 7 ++-
> >  drivers/input/touchscreen/tsc200x-core.c | 7 ---
> >  drivers/input/touchscreen/tsc200x-core.h | 2 +-
> >  4 files changed, 17 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/input/touchscreen/tsc2004.c 
> > b/drivers/input/touchscreen/tsc2004.c
> > index 7295c19..6fe55d5 100644
> > --- a/drivers/input/touchscreen/tsc2004.c
> > +++ b/drivers/input/touchscreen/tsc2004.c
> > @@ -22,6 +22,11 @@
> >  #include 
> >  #include "tsc200x-core.h"
> >  
> > +static const struct input_id tsc2004_input_id = {
> > +   .bustype = BUS_I2C,
> > +   .product = 2004,
> > +};
> > +
> >  static int tsc2004_cmd(struct device *dev, u8 cmd)
> >  {
> > u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
> > @@ -42,7 +47,7 @@ static int tsc2004_probe(struct i2c_client *i2c,
> >  const struct i2c_device_id *id)
> >  
> >  {
> > -   return tsc200x_probe(>dev, i2c->irq, BUS_I2C,
> > +   return tsc200x_probe(>dev, i2c->irq, _input_id,
> >  devm_regmap_init_i2c(i2c, _regmap_config),
> >  tsc2004_cmd);
> >  }
> > diff --git a/drivers/input/touchscreen/tsc2005.c 
> > b/drivers/input/touchscreen/tsc2005.c
> > index b9f593d..f2c5f0e 100644
> > --- a/drivers/input/touchscreen/tsc2005.c
> > +++ b/drivers/input/touchscreen/tsc2005.c
> > @@ -24,6 +24,11 @@
> >  #include 
> >  #include "tsc200x-core.h"
> >  
> > +static const struct input_id tsc2005_input_id = {
> > +   .bustype = BUS_SPI,
> > +   .product = 2005,
> > +};
> > +
> >  static int tsc2005_cmd(struct device *dev, u8 cmd)
> >  {
> > u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
> > @@ -62,7 +67,7 @@ static int tsc2005_probe(struct spi_device *spi)
> > if (error)
> > return error;
> >  
> > -   return tsc200x_probe(>dev, spi->irq, BUS_SPI,
> > +   return tsc200x_probe(>dev, spi->irq, _input_id,
> >  devm_regmap_init_spi(spi, _regmap_config),
> >  tsc2005_cmd);
> >  }
> > diff --git a/drivers/input/touchscreen/tsc200x-core.c 
> > b/drivers/input/touchscreen/tsc200x-core.c
> > index 26e81d1b..5e625c4 100644
> > --- a/drivers/input/touchscreen/tsc200x-core.c
> > +++ b/drivers/input/touchscreen/tsc200x-core.c
> > @@ -450,7 +450,7 @@ static void tsc200x_close(struct input_dev *input)
> > mutex_unlock(>mutex);
> >  }
> >  
> > -int tsc200x_probe(struct device *dev, int irq, __u16 bustype,
> > +int tsc200x_probe(struct device *dev, int irq, const struct input_id 
> > *tsc_id,
> >   struct regmap *regmap,
> >   int (*tsc200x_cmd)(struct device *dev, u8 cmd))
> >  {
> > @@ -547,9 +547,10 @@ int tsc200x_probe(struct device *dev, int irq, __u16 
> > bustype,
> > snprintf(ts->phys, sizeof(ts->phys),
> >  "%s/input-ts", dev_name(dev));
> >  
> > -   input_dev->name = "TSC200X touchscreen";
> > +   input_dev->name = devm_kasprintf(dev, GFP_KERNEL, "TSC%04d touchscreen",
> > +   tsc_id->product);
> 
> What about:
> 
>  if (tsc_id->product == 2005)
>   input_dev->name = "TSC2005 touchscreen";
>  else
>   input_dev->name = "TSC200X touchscreen";
> 
> We do want to use 'TSC2005' name for TSC2005, because compatibility,
> but you should keep TSC200X because compatibility. You don't want
> to break people's setups by going from TSC200X to TSC2004.

By same logic we shouldn't change from TSC200X back to TSC2005 because of
people's possibly new setup in the last 9 months.

> 
> Best regards,
>   Pavel
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH] Input: tsc200x - Report proper input_dev name

[Michael Welling]

Passes input_id struct to the the common probe function for the tsc200x drivers
instead of just the bustype.

This allows for the use of the product variable to set the input_dev->name
variable according to the type of touchscreen used.

Signed-off-by: Michael Welling <mwell...@ieee.org>
---
 drivers/input/touchscreen/tsc2004.c  | 7 ++-
 drivers/input/touchscreen/tsc2005.c  | 7 ++-
 drivers/input/touchscreen/tsc200x-core.c | 7 ---
 drivers/input/touchscreen/tsc200x-core.h | 2 +-
 4 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2004.c 
b/drivers/input/touchscreen/tsc2004.c
index 7295c19..6fe55d5 100644
--- a/drivers/input/touchscreen/tsc2004.c
+++ b/drivers/input/touchscreen/tsc2004.c
@@ -22,6 +22,11 @@
 #include 
 #include "tsc200x-core.h"
 
+static const struct input_id tsc2004_input_id = {
+   .bustype = BUS_I2C,
+   .product = 2004,
+};
+
 static int tsc2004_cmd(struct device *dev, u8 cmd)
 {
u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
@@ -42,7 +47,7 @@ static int tsc2004_probe(struct i2c_client *i2c,
 const struct i2c_device_id *id)
 
 {
-   return tsc200x_probe(>dev, i2c->irq, BUS_I2C,
+   return tsc200x_probe(>dev, i2c->irq, _input_id,
 devm_regmap_init_i2c(i2c, _regmap_config),
 tsc2004_cmd);
 }
diff --git a/drivers/input/touchscreen/tsc2005.c 
b/drivers/input/touchscreen/tsc2005.c
index b9f593d..f2c5f0e 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -24,6 +24,11 @@
 #include 
 #include "tsc200x-core.h"
 
+static const struct input_id tsc2005_input_id = {
+   .bustype = BUS_SPI,
+   .product = 2005,
+};
+
 static int tsc2005_cmd(struct device *dev, u8 cmd)
 {
u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
@@ -62,7 +67,7 @@ static int tsc2005_probe(struct spi_device *spi)
if (error)
return error;
 
-   return tsc200x_probe(>dev, spi->irq, BUS_SPI,
+   return tsc200x_probe(>dev, spi->irq, _input_id,
 devm_regmap_init_spi(spi, _regmap_config),
 tsc2005_cmd);
 }
diff --git a/drivers/input/touchscreen/tsc200x-core.c 
b/drivers/input/touchscreen/tsc200x-core.c
index 26e81d1b..5e625c4 100644
--- a/drivers/input/touchscreen/tsc200x-core.c
+++ b/drivers/input/touchscreen/tsc200x-core.c
@@ -450,7 +450,7 @@ static void tsc200x_close(struct input_dev *input)
mutex_unlock(>mutex);
 }
 
-int tsc200x_probe(struct device *dev, int irq, __u16 bustype,
+int tsc200x_probe(struct device *dev, int irq, const struct input_id *tsc_id,
  struct regmap *regmap,
  int (*tsc200x_cmd)(struct device *dev, u8 cmd))
 {
@@ -547,9 +547,10 @@ int tsc200x_probe(struct device *dev, int irq, __u16 
bustype,
snprintf(ts->phys, sizeof(ts->phys),
 "%s/input-ts", dev_name(dev));
 
-   input_dev->name = "TSC200X touchscreen";
+   input_dev->name = devm_kasprintf(dev, GFP_KERNEL, "TSC%04d touchscreen",
+   tsc_id->product);
input_dev->phys = ts->phys;
-   input_dev->id.bustype = bustype;
+   input_dev->id = *tsc_id;
input_dev->dev.parent = dev;
input_dev->evbit[0] = BIT(EV_ABS) | BIT(EV_KEY);
input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
diff --git a/drivers/input/touchscreen/tsc200x-core.h 
b/drivers/input/touchscreen/tsc200x-core.h
index 7a482d1..49a63a3 100644
--- a/drivers/input/touchscreen/tsc200x-core.h
+++ b/drivers/input/touchscreen/tsc200x-core.h
@@ -70,7 +70,7 @@
 extern const struct regmap_config tsc200x_regmap_config;
 extern const struct dev_pm_ops tsc200x_pm_ops;
 
-int tsc200x_probe(struct device *dev, int irq, __u16 bustype,
+int tsc200x_probe(struct device *dev, int irq, const struct input_id *tsc_id,
  struct regmap *regmap,
  int (*tsc200x_cmd)(struct device *dev, u8 cmd));
 int tsc200x_remove(struct device *dev);
-- 
2.1.4

[PATCH] Input: tsc200x - Report proper input_dev name

[Michael Welling]

Passes input_id struct to the the common probe function for the tsc200x drivers
instead of just the bustype.

This allows for the use of the product variable to set the input_dev->name
variable according to the type of touchscreen used.

Signed-off-by: Michael Welling 
---
 drivers/input/touchscreen/tsc2004.c  | 7 ++-
 drivers/input/touchscreen/tsc2005.c  | 7 ++-
 drivers/input/touchscreen/tsc200x-core.c | 7 ---
 drivers/input/touchscreen/tsc200x-core.h | 2 +-
 4 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2004.c 
b/drivers/input/touchscreen/tsc2004.c
index 7295c19..6fe55d5 100644
--- a/drivers/input/touchscreen/tsc2004.c
+++ b/drivers/input/touchscreen/tsc2004.c
@@ -22,6 +22,11 @@
 #include 
 #include "tsc200x-core.h"
 
+static const struct input_id tsc2004_input_id = {
+   .bustype = BUS_I2C,
+   .product = 2004,
+};
+
 static int tsc2004_cmd(struct device *dev, u8 cmd)
 {
u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
@@ -42,7 +47,7 @@ static int tsc2004_probe(struct i2c_client *i2c,
 const struct i2c_device_id *id)
 
 {
-   return tsc200x_probe(>dev, i2c->irq, BUS_I2C,
+   return tsc200x_probe(>dev, i2c->irq, _input_id,
 devm_regmap_init_i2c(i2c, _regmap_config),
 tsc2004_cmd);
 }
diff --git a/drivers/input/touchscreen/tsc2005.c 
b/drivers/input/touchscreen/tsc2005.c
index b9f593d..f2c5f0e 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -24,6 +24,11 @@
 #include 
 #include "tsc200x-core.h"
 
+static const struct input_id tsc2005_input_id = {
+   .bustype = BUS_SPI,
+   .product = 2005,
+};
+
 static int tsc2005_cmd(struct device *dev, u8 cmd)
 {
u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
@@ -62,7 +67,7 @@ static int tsc2005_probe(struct spi_device *spi)
if (error)
return error;
 
-   return tsc200x_probe(>dev, spi->irq, BUS_SPI,
+   return tsc200x_probe(>dev, spi->irq, _input_id,
 devm_regmap_init_spi(spi, _regmap_config),
 tsc2005_cmd);
 }
diff --git a/drivers/input/touchscreen/tsc200x-core.c 
b/drivers/input/touchscreen/tsc200x-core.c
index 26e81d1b..5e625c4 100644
--- a/drivers/input/touchscreen/tsc200x-core.c
+++ b/drivers/input/touchscreen/tsc200x-core.c
@@ -450,7 +450,7 @@ static void tsc200x_close(struct input_dev *input)
mutex_unlock(>mutex);
 }
 
-int tsc200x_probe(struct device *dev, int irq, __u16 bustype,
+int tsc200x_probe(struct device *dev, int irq, const struct input_id *tsc_id,
  struct regmap *regmap,
  int (*tsc200x_cmd)(struct device *dev, u8 cmd))
 {
@@ -547,9 +547,10 @@ int tsc200x_probe(struct device *dev, int irq, __u16 
bustype,
snprintf(ts->phys, sizeof(ts->phys),
 "%s/input-ts", dev_name(dev));
 
-   input_dev->name = "TSC200X touchscreen";
+   input_dev->name = devm_kasprintf(dev, GFP_KERNEL, "TSC%04d touchscreen",
+   tsc_id->product);
input_dev->phys = ts->phys;
-   input_dev->id.bustype = bustype;
+   input_dev->id = *tsc_id;
input_dev->dev.parent = dev;
input_dev->evbit[0] = BIT(EV_ABS) | BIT(EV_KEY);
input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
diff --git a/drivers/input/touchscreen/tsc200x-core.h 
b/drivers/input/touchscreen/tsc200x-core.h
index 7a482d1..49a63a3 100644
--- a/drivers/input/touchscreen/tsc200x-core.h
+++ b/drivers/input/touchscreen/tsc200x-core.h
@@ -70,7 +70,7 @@
 extern const struct regmap_config tsc200x_regmap_config;
 extern const struct dev_pm_ops tsc200x_pm_ops;
 
-int tsc200x_probe(struct device *dev, int irq, __u16 bustype,
+int tsc200x_probe(struct device *dev, int irq, const struct input_id *tsc_id,
  struct regmap *regmap,
  int (*tsc200x_cmd)(struct device *dev, u8 cmd));
 int tsc200x_remove(struct device *dev);
-- 
2.1.4

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Wed, Jul 20, 2016 at 04:26:44AM +0300, Aaro Koskinen wrote:
> On Tue, Jul 19, 2016 at 07:39:08PM -0500, Michael Welling wrote:
> > On Tue, Jul 19, 2016 at 04:51:20PM -0700, Dmitry Torokhov wrote:
> > > On Sun, Jul 17, 2016 at 05:56:36PM -0500, Michael Welling wrote:
> > > > On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> > > > > Ok, thanks for the information. I believe changing it back to
> > > > > "TSC2005" version makes sense (and then fixing it in stable).
> > > 
> > > Do we know how many users are affected?
> > 
> > Anyone with an old N900 and the smarts to update the kernel.
> 
> I think tsc2005 could be also used on N810.

The N810 uses the tsc2301 which appears to be the combination of the tsc2005
and a audio codec. It appears that the N810's touchscreen may not be properly 
supported in mainline anymore.

Actually, I still have a N810 so I will take a look for historical reasons.

> 
> A.

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Wed, Jul 20, 2016 at 04:26:44AM +0300, Aaro Koskinen wrote:
> On Tue, Jul 19, 2016 at 07:39:08PM -0500, Michael Welling wrote:
> > On Tue, Jul 19, 2016 at 04:51:20PM -0700, Dmitry Torokhov wrote:
> > > On Sun, Jul 17, 2016 at 05:56:36PM -0500, Michael Welling wrote:
> > > > On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> > > > > Ok, thanks for the information. I believe changing it back to
> > > > > "TSC2005" version makes sense (and then fixing it in stable).
> > > 
> > > Do we know how many users are affected?
> > 
> > Anyone with an old N900 and the smarts to update the kernel.
> 
> I think tsc2005 could be also used on N810.

The N810 uses the tsc2301 which appears to be the combination of the tsc2005
and a audio codec. It appears that the N810's touchscreen may not be properly 
supported in mainline anymore.

Actually, I still have a N810 so I will take a look for historical reasons.

> 
> A.

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Tue, Jul 19, 2016 at 06:44:24PM -0700, Dmitry Torokhov wrote:
> On Tue, Jul 19, 2016 at 08:34:57PM -0500, Michael Welling wrote:
> > On Tue, Jul 19, 2016 at 05:53:07PM -0700, Dmitry Torokhov wrote:
> > > On Tue, Jul 19, 2016 at 07:39:08PM -0500, Michael Welling wrote:
> > > > On Tue, Jul 19, 2016 at 04:51:20PM -0700, Dmitry Torokhov wrote:
> > > > > On Sun, Jul 17, 2016 at 05:56:36PM -0500, Michael Welling wrote:
> > > > > > On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> > > > > > > On Sun 2016-07-17 13:51:34, Michael Welling wrote:
> > > > > > > > On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> > > > > > > > > On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > > > > > > > > > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek 
> > > > > > > > > > wrote:
> > > > > > > > > > > Hi!
> > > > > > > > > > > 
> > > > > > > > > > > tsc2005 driver changed input device name, from
> > > > > > > > > > > 
> > > > > > > > > > > drivers/input/touchscreen/tsc2005.c:
> > > > > > > > > > > input_dev->name = "TSC2005
> > > > > > > > > > > touchscreen";
> > > > > > > > > > > 
> > > > > > > > > > > to "TSC200X touchscreen". Unfortunately, X seems to 
> > > > > > > > > > > propagate that
> > > > > > > > > > > name to userspace, where it is needed to be able to do
> > > > > 
> > > > > Technically X _is_ userspace.
> > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > xinput --set-prop --type=int ...
> > > > > > > > > > > 
> > > > > > > > > > > with the right arguments to calibrate touchscreen. 
> > > > > > > > > > > (Touchscreen is
> > > > > > > > > > > unusable without calibration).
> > > > > > > > > > > 
> > > > > > > > > > > What to do with that?
> > > > > 
> > > > > Hmm, I do not think we ever committed for the device names to be 
> > > > > stable.
> > > > > You are supposed to locate touchscreen device based on its properties
> > > > > and you might need some heuristic if you encounter a system with more
> > > > > than one such touchscreen.
> > > > > 
> > > > > > > > > > 
> > > > > > > > > > The input_dev name could be passed to the common probe 
> > > > > > > > > > function.
> > > > > > > > > > 
> > > > > > > > > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> > > > > > > > > 
> > > > > > > > > That would be preffered, I guess.
> > > > > > > > > 
> > > > > > > > > How many stable releases are affected?
> > > > > > > > 
> > > > > > > > Well this patch is 9 months old now. Lets see.
> > > > > > > > 
> > > > > > > > It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.
> > > > > > > 
> > > > > > > Ok, thanks for the information. I believe changing it back to
> > > > > > > "TSC2005" version makes sense (and then fixing it in stable).
> > > > > 
> > > > > Do we know how many users are affected?
> > > > 
> > > > Anyone with an old N900 and the smarts to update the kernel.
> > > 
> > > Soo... only Pavel? ;)
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > Lets see if the maintainer has any input before I submit a patch.
> > > > > 
> > > > > I guess we could also pass the input_id structure to tsc200x_probe, 
> > > > > fill
> > > > > the proper product ID (2004 or 2005) and derive the name form it.
> > > > >
> > 
> > If we passed the input_dev with the filled product idea it would have to be
> > allocated in the calling probe functions instead of the common probe.
> > 
> > This will lead to more duplicated code which we jumped through so many hoops
> > to avoid.
> 
> Not input_dev, input_id, like :
> 
> static const struct input_id tsc2005_input_id = {
>   .bustype= BUS_SPI,
>   .product= 2005,
> };
> 
> 
> 
> static int tsc2005_probe(struct spi_device *spi)
> {
> ...
>   return tsc200x_probe(>dev, spi->irq,
>_input_id,
>devm_regmap_init_spi(spi, _regmap_config),
>tsc2005_cmd);
> };
> 
> and in tsc200x_probe() you'd do:
> 
>   input_dev->name = dev_kasprintf(dev, GFP_KERNEL, "TSC%04d touchscreen",
>   tsc_id->product);
>   if (!input_dev->name)
>   return -ENOMEM;
>   ...
>   input_dev->id = *tsc_id;
>

Okay. Easy enough.
 
> Thanks.
> 
> -- 
> Dmitry

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Tue, Jul 19, 2016 at 06:44:24PM -0700, Dmitry Torokhov wrote:
> On Tue, Jul 19, 2016 at 08:34:57PM -0500, Michael Welling wrote:
> > On Tue, Jul 19, 2016 at 05:53:07PM -0700, Dmitry Torokhov wrote:
> > > On Tue, Jul 19, 2016 at 07:39:08PM -0500, Michael Welling wrote:
> > > > On Tue, Jul 19, 2016 at 04:51:20PM -0700, Dmitry Torokhov wrote:
> > > > > On Sun, Jul 17, 2016 at 05:56:36PM -0500, Michael Welling wrote:
> > > > > > On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> > > > > > > On Sun 2016-07-17 13:51:34, Michael Welling wrote:
> > > > > > > > On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> > > > > > > > > On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > > > > > > > > > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek 
> > > > > > > > > > wrote:
> > > > > > > > > > > Hi!
> > > > > > > > > > > 
> > > > > > > > > > > tsc2005 driver changed input device name, from
> > > > > > > > > > > 
> > > > > > > > > > > drivers/input/touchscreen/tsc2005.c:
> > > > > > > > > > > input_dev->name = "TSC2005
> > > > > > > > > > > touchscreen";
> > > > > > > > > > > 
> > > > > > > > > > > to "TSC200X touchscreen". Unfortunately, X seems to 
> > > > > > > > > > > propagate that
> > > > > > > > > > > name to userspace, where it is needed to be able to do
> > > > > 
> > > > > Technically X _is_ userspace.
> > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > xinput --set-prop --type=int ...
> > > > > > > > > > > 
> > > > > > > > > > > with the right arguments to calibrate touchscreen. 
> > > > > > > > > > > (Touchscreen is
> > > > > > > > > > > unusable without calibration).
> > > > > > > > > > > 
> > > > > > > > > > > What to do with that?
> > > > > 
> > > > > Hmm, I do not think we ever committed for the device names to be 
> > > > > stable.
> > > > > You are supposed to locate touchscreen device based on its properties
> > > > > and you might need some heuristic if you encounter a system with more
> > > > > than one such touchscreen.
> > > > > 
> > > > > > > > > > 
> > > > > > > > > > The input_dev name could be passed to the common probe 
> > > > > > > > > > function.
> > > > > > > > > > 
> > > > > > > > > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> > > > > > > > > 
> > > > > > > > > That would be preffered, I guess.
> > > > > > > > > 
> > > > > > > > > How many stable releases are affected?
> > > > > > > > 
> > > > > > > > Well this patch is 9 months old now. Lets see.
> > > > > > > > 
> > > > > > > > It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.
> > > > > > > 
> > > > > > > Ok, thanks for the information. I believe changing it back to
> > > > > > > "TSC2005" version makes sense (and then fixing it in stable).
> > > > > 
> > > > > Do we know how many users are affected?
> > > > 
> > > > Anyone with an old N900 and the smarts to update the kernel.
> > > 
> > > Soo... only Pavel? ;)
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > Lets see if the maintainer has any input before I submit a patch.
> > > > > 
> > > > > I guess we could also pass the input_id structure to tsc200x_probe, 
> > > > > fill
> > > > > the proper product ID (2004 or 2005) and derive the name form it.
> > > > >
> > 
> > If we passed the input_dev with the filled product idea it would have to be
> > allocated in the calling probe functions instead of the common probe.
> > 
> > This will lead to more duplicated code which we jumped through so many hoops
> > to avoid.
> 
> Not input_dev, input_id, like :
> 
> static const struct input_id tsc2005_input_id = {
>   .bustype= BUS_SPI,
>   .product= 2005,
> };
> 
> 
> 
> static int tsc2005_probe(struct spi_device *spi)
> {
> ...
>   return tsc200x_probe(>dev, spi->irq,
>_input_id,
>devm_regmap_init_spi(spi, _regmap_config),
>tsc2005_cmd);
> };
> 
> and in tsc200x_probe() you'd do:
> 
>   input_dev->name = dev_kasprintf(dev, GFP_KERNEL, "TSC%04d touchscreen",
>   tsc_id->product);
>   if (!input_dev->name)
>   return -ENOMEM;
>   ...
>   input_dev->id = *tsc_id;
>

Okay. Easy enough.
 
> Thanks.
> 
> -- 
> Dmitry

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Tue, Jul 19, 2016 at 05:53:07PM -0700, Dmitry Torokhov wrote:
> On Tue, Jul 19, 2016 at 07:39:08PM -0500, Michael Welling wrote:
> > On Tue, Jul 19, 2016 at 04:51:20PM -0700, Dmitry Torokhov wrote:
> > > On Sun, Jul 17, 2016 at 05:56:36PM -0500, Michael Welling wrote:
> > > > On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> > > > > On Sun 2016-07-17 13:51:34, Michael Welling wrote:
> > > > > > On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> > > > > > > On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > > > > > > > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> > > > > > > > > Hi!
> > > > > > > > > 
> > > > > > > > > tsc2005 driver changed input device name, from
> > > > > > > > > 
> > > > > > > > > drivers/input/touchscreen/tsc2005.c:input_dev->name = 
> > > > > > > > > "TSC2005
> > > > > > > > > touchscreen";
> > > > > > > > > 
> > > > > > > > > to "TSC200X touchscreen". Unfortunately, X seems to propagate 
> > > > > > > > > that
> > > > > > > > > name to userspace, where it is needed to be able to do
> > > 
> > > Technically X _is_ userspace.
> > > 
> > > > > > > > > 
> > > > > > > > > xinput --set-prop --type=int ...
> > > > > > > > > 
> > > > > > > > > with the right arguments to calibrate touchscreen. 
> > > > > > > > > (Touchscreen is
> > > > > > > > > unusable without calibration).
> > > > > > > > > 
> > > > > > > > > What to do with that?
> > > 
> > > Hmm, I do not think we ever committed for the device names to be stable.
> > > You are supposed to locate touchscreen device based on its properties
> > > and you might need some heuristic if you encounter a system with more
> > > than one such touchscreen.
> > > 
> > > > > > > > 
> > > > > > > > The input_dev name could be passed to the common probe function.
> > > > > > > > 
> > > > > > > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> > > > > > > 
> > > > > > > That would be preffered, I guess.
> > > > > > > 
> > > > > > > How many stable releases are affected?
> > > > > > 
> > > > > > Well this patch is 9 months old now. Lets see.
> > > > > > 
> > > > > > It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.
> > > > > 
> > > > > Ok, thanks for the information. I believe changing it back to
> > > > > "TSC2005" version makes sense (and then fixing it in stable).
> > > 
> > > Do we know how many users are affected?
> > 
> > Anyone with an old N900 and the smarts to update the kernel.
> 
> Soo... only Pavel? ;)
> 
> > 
> > > 
> > > > 
> > > > Lets see if the maintainer has any input before I submit a patch.
> > > 
> > > I guess we could also pass the input_id structure to tsc200x_probe, fill
> > > the proper product ID (2004 or 2005) and derive the name form it.
> > >

If we passed the input_dev with the filled product idea it would have to be
allocated in the calling probe functions instead of the common probe.

This will lead to more duplicated code which we jumped through so many hoops
to avoid.

> > 
> > Okay do you really think this should be considered a regression?
> > 
> > Should I go ahead with the patch?
> 
> To "fix" it is a small change so we might as well do that, but I
> probably leave it off stable for now.
> 
> Thanks.
> 
> -- 
> Dmitry

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Tue, Jul 19, 2016 at 05:53:07PM -0700, Dmitry Torokhov wrote:
> On Tue, Jul 19, 2016 at 07:39:08PM -0500, Michael Welling wrote:
> > On Tue, Jul 19, 2016 at 04:51:20PM -0700, Dmitry Torokhov wrote:
> > > On Sun, Jul 17, 2016 at 05:56:36PM -0500, Michael Welling wrote:
> > > > On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> > > > > On Sun 2016-07-17 13:51:34, Michael Welling wrote:
> > > > > > On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> > > > > > > On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > > > > > > > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> > > > > > > > > Hi!
> > > > > > > > > 
> > > > > > > > > tsc2005 driver changed input device name, from
> > > > > > > > > 
> > > > > > > > > drivers/input/touchscreen/tsc2005.c:input_dev->name = 
> > > > > > > > > "TSC2005
> > > > > > > > > touchscreen";
> > > > > > > > > 
> > > > > > > > > to "TSC200X touchscreen". Unfortunately, X seems to propagate 
> > > > > > > > > that
> > > > > > > > > name to userspace, where it is needed to be able to do
> > > 
> > > Technically X _is_ userspace.
> > > 
> > > > > > > > > 
> > > > > > > > > xinput --set-prop --type=int ...
> > > > > > > > > 
> > > > > > > > > with the right arguments to calibrate touchscreen. 
> > > > > > > > > (Touchscreen is
> > > > > > > > > unusable without calibration).
> > > > > > > > > 
> > > > > > > > > What to do with that?
> > > 
> > > Hmm, I do not think we ever committed for the device names to be stable.
> > > You are supposed to locate touchscreen device based on its properties
> > > and you might need some heuristic if you encounter a system with more
> > > than one such touchscreen.
> > > 
> > > > > > > > 
> > > > > > > > The input_dev name could be passed to the common probe function.
> > > > > > > > 
> > > > > > > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> > > > > > > 
> > > > > > > That would be preffered, I guess.
> > > > > > > 
> > > > > > > How many stable releases are affected?
> > > > > > 
> > > > > > Well this patch is 9 months old now. Lets see.
> > > > > > 
> > > > > > It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.
> > > > > 
> > > > > Ok, thanks for the information. I believe changing it back to
> > > > > "TSC2005" version makes sense (and then fixing it in stable).
> > > 
> > > Do we know how many users are affected?
> > 
> > Anyone with an old N900 and the smarts to update the kernel.
> 
> Soo... only Pavel? ;)
> 
> > 
> > > 
> > > > 
> > > > Lets see if the maintainer has any input before I submit a patch.
> > > 
> > > I guess we could also pass the input_id structure to tsc200x_probe, fill
> > > the proper product ID (2004 or 2005) and derive the name form it.
> > >

If we passed the input_dev with the filled product idea it would have to be
allocated in the calling probe functions instead of the common probe.

This will lead to more duplicated code which we jumped through so many hoops
to avoid.

> > 
> > Okay do you really think this should be considered a regression?
> > 
> > Should I go ahead with the patch?
> 
> To "fix" it is a small change so we might as well do that, but I
> probably leave it off stable for now.
> 
> Thanks.
> 
> -- 
> Dmitry

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Tue, Jul 19, 2016 at 04:51:20PM -0700, Dmitry Torokhov wrote:
> On Sun, Jul 17, 2016 at 05:56:36PM -0500, Michael Welling wrote:
> > On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> > > On Sun 2016-07-17 13:51:34, Michael Welling wrote:
> > > > On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> > > > > On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > > > > > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> > > > > > > Hi!
> > > > > > > 
> > > > > > > tsc2005 driver changed input device name, from
> > > > > > > 
> > > > > > > drivers/input/touchscreen/tsc2005.c:input_dev->name = 
> > > > > > > "TSC2005
> > > > > > > touchscreen";
> > > > > > > 
> > > > > > > to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> > > > > > > name to userspace, where it is needed to be able to do
> 
> Technically X _is_ userspace.
> 
> > > > > > > 
> > > > > > > xinput --set-prop --type=int ...
> > > > > > > 
> > > > > > > with the right arguments to calibrate touchscreen. (Touchscreen is
> > > > > > > unusable without calibration).
> > > > > > > 
> > > > > > > What to do with that?
> 
> Hmm, I do not think we ever committed for the device names to be stable.
> You are supposed to locate touchscreen device based on its properties
> and you might need some heuristic if you encounter a system with more
> than one such touchscreen.
> 
> > > > > > 
> > > > > > The input_dev name could be passed to the common probe function.
> > > > > > 
> > > > > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> > > > > 
> > > > > That would be preffered, I guess.
> > > > > 
> > > > > How many stable releases are affected?
> > > > 
> > > > Well this patch is 9 months old now. Lets see.
> > > > 
> > > > It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.
> > > 
> > > Ok, thanks for the information. I believe changing it back to
> > > "TSC2005" version makes sense (and then fixing it in stable).
> 
> Do we know how many users are affected?

Anyone with an old N900 and the smarts to update the kernel.

> 
> > 
> > Lets see if the maintainer has any input before I submit a patch.
> 
> I guess we could also pass the input_id structure to tsc200x_probe, fill
> the proper product ID (2004 or 2005) and derive the name form it.
>

Okay do you really think this should be considered a regression?

Should I go ahead with the patch?
 
> Thanks.
> 
> -- 
> Dmitry

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Tue, Jul 19, 2016 at 04:51:20PM -0700, Dmitry Torokhov wrote:
> On Sun, Jul 17, 2016 at 05:56:36PM -0500, Michael Welling wrote:
> > On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> > > On Sun 2016-07-17 13:51:34, Michael Welling wrote:
> > > > On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> > > > > On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > > > > > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> > > > > > > Hi!
> > > > > > > 
> > > > > > > tsc2005 driver changed input device name, from
> > > > > > > 
> > > > > > > drivers/input/touchscreen/tsc2005.c:input_dev->name = 
> > > > > > > "TSC2005
> > > > > > > touchscreen";
> > > > > > > 
> > > > > > > to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> > > > > > > name to userspace, where it is needed to be able to do
> 
> Technically X _is_ userspace.
> 
> > > > > > > 
> > > > > > > xinput --set-prop --type=int ...
> > > > > > > 
> > > > > > > with the right arguments to calibrate touchscreen. (Touchscreen is
> > > > > > > unusable without calibration).
> > > > > > > 
> > > > > > > What to do with that?
> 
> Hmm, I do not think we ever committed for the device names to be stable.
> You are supposed to locate touchscreen device based on its properties
> and you might need some heuristic if you encounter a system with more
> than one such touchscreen.
> 
> > > > > > 
> > > > > > The input_dev name could be passed to the common probe function.
> > > > > > 
> > > > > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> > > > > 
> > > > > That would be preffered, I guess.
> > > > > 
> > > > > How many stable releases are affected?
> > > > 
> > > > Well this patch is 9 months old now. Lets see.
> > > > 
> > > > It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.
> > > 
> > > Ok, thanks for the information. I believe changing it back to
> > > "TSC2005" version makes sense (and then fixing it in stable).
> 
> Do we know how many users are affected?

Anyone with an old N900 and the smarts to update the kernel.

> 
> > 
> > Lets see if the maintainer has any input before I submit a patch.
> 
> I guess we could also pass the input_id structure to tsc200x_probe, fill
> the proper product ID (2004 or 2005) and derive the name form it.
>

Okay do you really think this should be considered a regression?

Should I go ahead with the patch?
 
> Thanks.
> 
> -- 
> Dmitry

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> On Sun 2016-07-17 13:51:34, Michael Welling wrote:
> > On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> > > On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > > > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> > > > > Hi!
> > > > > 
> > > > > tsc2005 driver changed input device name, from
> > > > > 
> > > > > drivers/input/touchscreen/tsc2005.c:input_dev->name = "TSC2005
> > > > > touchscreen";
> > > > > 
> > > > > to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> > > > > name to userspace, where it is needed to be able to do
> > > > > 
> > > > > xinput --set-prop --type=int ...
> > > > > 
> > > > > with the right arguments to calibrate touchscreen. (Touchscreen is
> > > > > unusable without calibration).
> > > > > 
> > > > > What to do with that?
> > > > 
> > > > The input_dev name could be passed to the common probe function.
> > > > 
> > > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> > > 
> > > That would be preffered, I guess.
> > > 
> > > How many stable releases are affected?
> > 
> > Well this patch is 9 months old now. Lets see.
> > 
> > It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.
> 
> Ok, thanks for the information. I believe changing it back to
> "TSC2005" version makes sense (and then fixing it in stable).

Lets see if the maintainer has any input before I submit a patch.

> 
> Best regards,
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Sun, Jul 17, 2016 at 10:03:39PM +0200, Pavel Machek wrote:
> On Sun 2016-07-17 13:51:34, Michael Welling wrote:
> > On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> > > On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > > > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> > > > > Hi!
> > > > > 
> > > > > tsc2005 driver changed input device name, from
> > > > > 
> > > > > drivers/input/touchscreen/tsc2005.c:input_dev->name = "TSC2005
> > > > > touchscreen";
> > > > > 
> > > > > to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> > > > > name to userspace, where it is needed to be able to do
> > > > > 
> > > > > xinput --set-prop --type=int ...
> > > > > 
> > > > > with the right arguments to calibrate touchscreen. (Touchscreen is
> > > > > unusable without calibration).
> > > > > 
> > > > > What to do with that?
> > > > 
> > > > The input_dev name could be passed to the common probe function.
> > > > 
> > > > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> > > 
> > > That would be preffered, I guess.
> > > 
> > > How many stable releases are affected?
> > 
> > Well this patch is 9 months old now. Lets see.
> > 
> > It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.
> 
> Ok, thanks for the information. I believe changing it back to
> "TSC2005" version makes sense (and then fixing it in stable).

Lets see if the maintainer has any input before I submit a patch.

> 
> Best regards,
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> > > Hi!
> > > 
> > > tsc2005 driver changed input device name, from
> > > 
> > > drivers/input/touchscreen/tsc2005.c:input_dev->name = "TSC2005
> > > touchscreen";
> > > 
> > > to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> > > name to userspace, where it is needed to be able to do
> > > 
> > > xinput --set-prop --type=int ...
> > > 
> > > with the right arguments to calibrate touchscreen. (Touchscreen is
> > > unusable without calibration).
> > > 
> > > What to do with that?
> > 
> > The input_dev name could be passed to the common probe function.
> > 
> > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> 
> That would be preffered, I guess.
> 
> How many stable releases are affected?

Well this patch is 9 months old now. Lets see.

It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.

> 
> Thanks,
>   Pavel
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Sun, Jul 17, 2016 at 08:42:09PM +0200, Pavel Machek wrote:
> On Sun 2016-07-17 13:24:45, Michael Welling wrote:
> > On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> > > Hi!
> > > 
> > > tsc2005 driver changed input device name, from
> > > 
> > > drivers/input/touchscreen/tsc2005.c:input_dev->name = "TSC2005
> > > touchscreen";
> > > 
> > > to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> > > name to userspace, where it is needed to be able to do
> > > 
> > > xinput --set-prop --type=int ...
> > > 
> > > with the right arguments to calibrate touchscreen. (Touchscreen is
> > > unusable without calibration).
> > > 
> > > What to do with that?
> > 
> > The input_dev name could be passed to the common probe function.
> > 
> > http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65
> 
> That would be preffered, I guess.
> 
> How many stable releases are affected?

Well this patch is 9 months old now. Lets see.

It was introduced in v4.4-rc1. So v4.4, v4.5 and v4.6.

> 
> Thanks,
>   Pavel
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> Hi!
> 
> tsc2005 driver changed input device name, from
> 
> drivers/input/touchscreen/tsc2005.c:input_dev->name = "TSC2005
> touchscreen";
> 
> to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> name to userspace, where it is needed to be able to do
> 
> xinput --set-prop --type=int ...
> 
> with the right arguments to calibrate touchscreen. (Touchscreen is
> unusable without calibration).
> 
> What to do with that?

The input_dev name could be passed to the common probe function.

http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65

It could also be inferred from the bus_type or dev_name.

http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc200x-core.c#L547

Pick a method and I will provide a patch.

> 
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: v4.1 to v4.7: regression in tsc2005 driver

[Michael Welling]

On Sun, Jul 17, 2016 at 07:52:57PM +0200, Pavel Machek wrote:
> Hi!
> 
> tsc2005 driver changed input device name, from
> 
> drivers/input/touchscreen/tsc2005.c:input_dev->name = "TSC2005
> touchscreen";
> 
> to "TSC200X touchscreen". Unfortunately, X seems to propagate that
> name to userspace, where it is needed to be able to do
> 
> xinput --set-prop --type=int ...
> 
> with the right arguments to calibrate touchscreen. (Touchscreen is
> unusable without calibration).
> 
> What to do with that?

The input_dev name could be passed to the common probe function.

http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2005.c#L65

It could also be inferred from the bus_type or dev_name.

http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc200x-core.c#L547

Pick a method and I will provide a patch.

> 
>   Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Regression in inv_mpu6050: 4.6.0-rc5

[Michael Welling]

On Tue, Apr 26, 2016 at 11:26:51PM +0100, One Thousand Gnomes wrote:
> 
> This now causes us to crash and burn on the ASUS T100TA Baytrail/T
> platforms
>

I believe this regression has already been patched.

Check the latest commits in linux-next.

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c

See if the latest patches fix your issue.

> [9.308605] BUG: unable to handle kernel NULL pointer dereference at 
> 0018
> [9.310735] IP: [] inv_mpu_probe+0x5e/0x110 
> [inv_mpu6050_i2c]
> [9.312876] PGD 0 
> [9.314956] Oops:  [#1] SMP 
> [9.317018] Modules linked in: inv_mpu6050_i2c(+) aes_x86_64 lrw gf128mul 
> inv_mpu6050 glue_helper ablk_helper cryptd industrialio_triggered_buffer 
> kfifo_buf industrialio snd_intel_sst_acpi snd_intel_sst_core i2c_mux 
> snd_soc_rt5640 snd_soc_sst_mfld_platform snd_soc_rl6231 snd_soc_sst_match 
> input_leds snd_soc_core hci_uart snd_compress snd_pcm_dmaengine lpc_ich 
> snd_pcm btbcm snd_seq_midi btintel snd_seq_midi_event bluetooth snd_rawmidi 
> wmi snd_seq snd_seq_device dw_dmac snd_timer dw_dmac_core soc_button_array 
> snd soundcore processor_thermal_device int3402_thermal ac97_bus 
> int3403_thermal int3400_thermal i2c_designware_platform intel_soc_dts_iosf 
> int340x_thermal_zone acpi_thermal_rel acpi_pad i2c_designware_core 
> pwm_lpss_platform pwm_lpss ipv6 autofs4 i915 i2c_algo_bit drm_kms_helper 
> syscopyarea sysfillrect
> [9.326919]  sysimgblt fb_sys_fops drm mmc_block hid_generic usbhid 
> i2c_hid video hid sdhci_acpi sdhci
> [9.332174] CPU: 3 PID: 326 Comm: systemd-udevd Not tainted 4.6.0-rc5+ #3
> [9.334899] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS 
> T100TA.307 05/09/2014
> [9.337655] task: 8800706dde80 ti: 880035928000 task.ti: 
> 880035928000
> [9.340428] RIP: 0010:[]  [] 
> inv_mpu_probe+0x5e/0x110 [inv_mpu6050_i2c]
> [9.343286] RSP: 0018:88003592bad8  EFLAGS: 00010287
> [9.346132] RAX: 88003523e000 RBX: 880070d57000 RCX: 
> 880070e51a40
> [9.349006] RDX: 880070e51a20 RSI: 00cf RDI: 
> 88003523e000
> [9.351863] RBP: 88003592bb08 R08: 88007558c9f8 R09: 
> 880070e51a40
> [9.354713] R10: 880070e51a38 R11:  R12: 
> 
> [9.357569] R13: 880070d57000 R14: c04661d0 R15: 
> 880070d57004
> [9.360431] FS:  7f56017618c0() GS:88007898() 
> knlGS:
> [9.363330] CS:  0010 DS:  ES:  CR0: 80050033
> [9.366226] CR2: 0018 CR3: 359f6000 CR4: 
> 001006e0
> [9.369140] Stack:
> [9.371988]  81303a32 00cf 880070d57020 
> c04670c0
> [9.374883]  880070d57020 880070d57000 88003592bb40 
> 8141ea6b
> [9.377769]  880070d57020  c0468038 
> 0029
> [9.380650] Call Trace:
> [9.383493]  [] ? acpi_dev_pm_attach+0x85/0xa2
> [9.386382]  [] i2c_device_probe+0xfb/0x1b0
> [9.389260]  [] driver_probe_device+0x227/0x440
> [9.392130]  [] __driver_attach+0xcc/0xf0
> [9.395000]  [] ? driver_probe_device+0x440/0x440
> [9.397875]  [] bus_for_each_dev+0x67/0xb0
> [9.400759]  [] driver_attach+0x19/0x20
> [9.403636]  [] bus_add_driver+0x1e1/0x280
> [9.406539]  [] ? 0xc0076000
> [9.409424]  [] driver_register+0x5b/0xd0
> [9.412278]  [] i2c_register_driver+0x26/0x90
> [9.415171]  [] inv_mpu_driver_init+0x17/0x19 
> [inv_mpu6050_i2c]
> [9.418058]  [] do_one_initcall+0xae/0x1f0
> [9.420972]  [] ? kmem_cache_alloc+0x2b/0xc0
> [9.423856]  [] do_init_module+0x55/0x1c5
> [9.426770]  [] load_module+0x2123/0x2730
> [9.429664]  [] ? __symbol_put+0x50/0x50
> [9.432537]  [] SYSC_finit_module+0xe6/0x120
> [9.435382]  [] SyS_finit_module+0x9/0x10
> [9.438212]  [] entry_SYSCALL_64_fastpath+0x17/0x93
> [9.441015] Code: 00 00 00 31 c9 31 d2 48 89 df 48 c7 c6 e0 70 46 c0 e8 37 
> e7 f3 c0 48 3d 00 f0 ff ff 48 89 c7 0f 87 94 00 00 00 8b b3 d0 02 00 00 <45> 
> 8b 44 24 18 31 c9 4c 89 e2 e8 b3 b9 06 00 85 c0 78 4f 48 8b 
> [9.446976] RIP  [] inv_mpu_probe+0x5e/0x110 
> [inv_mpu6050_i2c]
> [9.449967]  RSP 
> [9.452844] CR2: 0018
> [9.455673] ---[ end trace d9e48d40f1079c34 ]---
> 
> Alan
> --
> 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

Re: Regression in inv_mpu6050: 4.6.0-rc5

[Michael Welling]

On Tue, Apr 26, 2016 at 11:26:51PM +0100, One Thousand Gnomes wrote:
> 
> This now causes us to crash and burn on the ASUS T100TA Baytrail/T
> platforms
>

I believe this regression has already been patched.

Check the latest commits in linux-next.

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c

See if the latest patches fix your issue.

> [9.308605] BUG: unable to handle kernel NULL pointer dereference at 
> 0018
> [9.310735] IP: [] inv_mpu_probe+0x5e/0x110 
> [inv_mpu6050_i2c]
> [9.312876] PGD 0 
> [9.314956] Oops:  [#1] SMP 
> [9.317018] Modules linked in: inv_mpu6050_i2c(+) aes_x86_64 lrw gf128mul 
> inv_mpu6050 glue_helper ablk_helper cryptd industrialio_triggered_buffer 
> kfifo_buf industrialio snd_intel_sst_acpi snd_intel_sst_core i2c_mux 
> snd_soc_rt5640 snd_soc_sst_mfld_platform snd_soc_rl6231 snd_soc_sst_match 
> input_leds snd_soc_core hci_uart snd_compress snd_pcm_dmaengine lpc_ich 
> snd_pcm btbcm snd_seq_midi btintel snd_seq_midi_event bluetooth snd_rawmidi 
> wmi snd_seq snd_seq_device dw_dmac snd_timer dw_dmac_core soc_button_array 
> snd soundcore processor_thermal_device int3402_thermal ac97_bus 
> int3403_thermal int3400_thermal i2c_designware_platform intel_soc_dts_iosf 
> int340x_thermal_zone acpi_thermal_rel acpi_pad i2c_designware_core 
> pwm_lpss_platform pwm_lpss ipv6 autofs4 i915 i2c_algo_bit drm_kms_helper 
> syscopyarea sysfillrect
> [9.326919]  sysimgblt fb_sys_fops drm mmc_block hid_generic usbhid 
> i2c_hid video hid sdhci_acpi sdhci
> [9.332174] CPU: 3 PID: 326 Comm: systemd-udevd Not tainted 4.6.0-rc5+ #3
> [9.334899] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS 
> T100TA.307 05/09/2014
> [9.337655] task: 8800706dde80 ti: 880035928000 task.ti: 
> 880035928000
> [9.340428] RIP: 0010:[]  [] 
> inv_mpu_probe+0x5e/0x110 [inv_mpu6050_i2c]
> [9.343286] RSP: 0018:88003592bad8  EFLAGS: 00010287
> [9.346132] RAX: 88003523e000 RBX: 880070d57000 RCX: 
> 880070e51a40
> [9.349006] RDX: 880070e51a20 RSI: 00cf RDI: 
> 88003523e000
> [9.351863] RBP: 88003592bb08 R08: 88007558c9f8 R09: 
> 880070e51a40
> [9.354713] R10: 880070e51a38 R11:  R12: 
> 
> [9.357569] R13: 880070d57000 R14: c04661d0 R15: 
> 880070d57004
> [9.360431] FS:  7f56017618c0() GS:88007898() 
> knlGS:
> [9.363330] CS:  0010 DS:  ES:  CR0: 80050033
> [9.366226] CR2: 0018 CR3: 359f6000 CR4: 
> 001006e0
> [9.369140] Stack:
> [9.371988]  81303a32 00cf 880070d57020 
> c04670c0
> [9.374883]  880070d57020 880070d57000 88003592bb40 
> 8141ea6b
> [9.377769]  880070d57020  c0468038 
> 0029
> [9.380650] Call Trace:
> [9.383493]  [] ? acpi_dev_pm_attach+0x85/0xa2
> [9.386382]  [] i2c_device_probe+0xfb/0x1b0
> [9.389260]  [] driver_probe_device+0x227/0x440
> [9.392130]  [] __driver_attach+0xcc/0xf0
> [9.395000]  [] ? driver_probe_device+0x440/0x440
> [9.397875]  [] bus_for_each_dev+0x67/0xb0
> [9.400759]  [] driver_attach+0x19/0x20
> [9.403636]  [] bus_add_driver+0x1e1/0x280
> [9.406539]  [] ? 0xc0076000
> [9.409424]  [] driver_register+0x5b/0xd0
> [9.412278]  [] i2c_register_driver+0x26/0x90
> [9.415171]  [] inv_mpu_driver_init+0x17/0x19 
> [inv_mpu6050_i2c]
> [9.418058]  [] do_one_initcall+0xae/0x1f0
> [9.420972]  [] ? kmem_cache_alloc+0x2b/0xc0
> [9.423856]  [] do_init_module+0x55/0x1c5
> [9.426770]  [] load_module+0x2123/0x2730
> [9.429664]  [] ? __symbol_put+0x50/0x50
> [9.432537]  [] SYSC_finit_module+0xe6/0x120
> [9.435382]  [] SyS_finit_module+0x9/0x10
> [9.438212]  [] entry_SYSCALL_64_fastpath+0x17/0x93
> [9.441015] Code: 00 00 00 31 c9 31 d2 48 89 df 48 c7 c6 e0 70 46 c0 e8 37 
> e7 f3 c0 48 3d 00 f0 ff ff 48 89 c7 0f 87 94 00 00 00 8b b3 d0 02 00 00 <45> 
> 8b 44 24 18 31 c9 4c 89 e2 e8 b3 b9 06 00 85 c0 78 4f 48 8b 
> [9.446976] RIP  [] inv_mpu_probe+0x5e/0x110 
> [inv_mpu6050_i2c]
> [9.449967]  RSP 
> [9.452844] CR2: 0018
> [9.455673] ---[ end trace d9e48d40f1079c34 ]---
> 
> Alan
> --
> 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

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Tue, Mar 01, 2016 at 08:35:01AM +, ji...@jic23.retrosnub.co.uk wrote:
> On 01.03.2016 02:42, Michael Welling wrote:
> >On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> >>On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwell...@ieee.org>
> >>wrote:
> >>> On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >>>> The driver has sysfs readings with runtime PM support for power saving.
> >>>> It also offers buffer support that can be used together with IIO software
> >>>> triggers.
> >>>>
> >>>
> >>> Daniel,
> >>>
> >>> So I noticed something yesterday while testing new boards.
> >>> The channels are occassionally swapping when accessing data from multiple 
> >>> channels.
> >>>
> >>> I wrote a simple bash script to demonstrate.
> >>
> >>This happened to me in a previous version of the patch. I remember it
> >>being fixed in the last version (or at least I could not reproduce).
> >>I'll test again tomorrow with your script.
> >>
> >
> >Here is what I believe is happening.
> >
> >The request for a conversion on a new channel comes in while the
> >conversion
> >for the previous channel is still converting. The driver waits
> >approximately
> >one conversion cycle. The previous channel completes within this timeframe
> >and the MUX is changed and the new sample is started. The new sample is
> >still
> >converting and the driver returns the value from the previous conversion.
> >
> >For a test I multiplied the conv_time value by 2 in the
> >ads1015_get_adc_result
> >function. This allows time for the current sample flush out and always
> >returns
> >the appropriate channel's value.
> >
> >Looking at the buffered mode it appears that only one channel is being
> >accessed
> >at any time. This being the first one in the active_scan_mask found by
> >find_first_bit. So the MUX would never change is buffered mode as far I
> >can
> >tell.
> >
> >Don't we typically want to read all of enabled channels in buffered mode?
> In some devices that is effectively impossible (fifo's that fill only from
> the currently
> selected channel). That is what the onehot validation callback is about.
> In this particular case it looks like doing a multichannel read is fair bit
> more time
> consuming than a single channel read and so will result in a considerable
> reduction in
> throughput.  This is of course why many parts include a simple sequencer!

Yes the sampling rate would effectively be divided by the number of channels
enabled.

> 
> Anyhow, supporting multi channel buffered reads could be done (probably) but
> you
> would want to fall back to the single channel case as it is now.

Understood.

> 
> Jonathan
> >>Lucas De Marchi
> >--
> >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

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Tue, Mar 01, 2016 at 08:35:01AM +, ji...@jic23.retrosnub.co.uk wrote:
> On 01.03.2016 02:42, Michael Welling wrote:
> >On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> >>On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling 
> >>wrote:
> >>> On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >>>> The driver has sysfs readings with runtime PM support for power saving.
> >>>> It also offers buffer support that can be used together with IIO software
> >>>> triggers.
> >>>>
> >>>
> >>> Daniel,
> >>>
> >>> So I noticed something yesterday while testing new boards.
> >>> The channels are occassionally swapping when accessing data from multiple 
> >>> channels.
> >>>
> >>> I wrote a simple bash script to demonstrate.
> >>
> >>This happened to me in a previous version of the patch. I remember it
> >>being fixed in the last version (or at least I could not reproduce).
> >>I'll test again tomorrow with your script.
> >>
> >
> >Here is what I believe is happening.
> >
> >The request for a conversion on a new channel comes in while the
> >conversion
> >for the previous channel is still converting. The driver waits
> >approximately
> >one conversion cycle. The previous channel completes within this timeframe
> >and the MUX is changed and the new sample is started. The new sample is
> >still
> >converting and the driver returns the value from the previous conversion.
> >
> >For a test I multiplied the conv_time value by 2 in the
> >ads1015_get_adc_result
> >function. This allows time for the current sample flush out and always
> >returns
> >the appropriate channel's value.
> >
> >Looking at the buffered mode it appears that only one channel is being
> >accessed
> >at any time. This being the first one in the active_scan_mask found by
> >find_first_bit. So the MUX would never change is buffered mode as far I
> >can
> >tell.
> >
> >Don't we typically want to read all of enabled channels in buffered mode?
> In some devices that is effectively impossible (fifo's that fill only from
> the currently
> selected channel). That is what the onehot validation callback is about.
> In this particular case it looks like doing a multichannel read is fair bit
> more time
> consuming than a single channel read and so will result in a considerable
> reduction in
> throughput.  This is of course why many parts include a simple sequencer!

Yes the sampling rate would effectively be divided by the number of channels
enabled.

> 
> Anyhow, supporting multi channel buffered reads could be done (probably) but
> you
> would want to fall back to the single channel case as it is now.

Understood.

> 
> Jonathan
> >>Lucas De Marchi
> >--
> >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

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Tue, Mar 01, 2016 at 01:28:26PM +0200, Daniel Baluta wrote:
> On Tue, Mar 1, 2016 at 4:42 AM, Michael Welling <mwell...@ieee.org> wrote:
> > On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> >> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwell...@ieee.org> wrote:
> >> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> >> The driver has sysfs readings with runtime PM support for power saving.
> >> >> It also offers buffer support that can be used together with IIO 
> >> >> software
> >> >> triggers.
> >> >>
> >> >
> >> > Daniel,
> >> >
> >> > So I noticed something yesterday while testing new boards.
> >> > The channels are occassionally swapping when accessing data from 
> >> > multiple channels.
> >> >
> >> > I wrote a simple bash script to demonstrate.
> >>
> >> This happened to me in a previous version of the patch. I remember it
> >> being fixed in the last version (or at least I could not reproduce).
> >> I'll test again tomorrow with your script.
> >>
> >
> > Here is what I believe is happening.
> >
> > The request for a conversion on a new channel comes in while the conversion
> > for the previous channel is still converting. The driver waits approximately
> > one conversion cycle. The previous channel completes within this timeframe
> > and the MUX is changed and the new sample is started. The new sample is 
> > still
> > converting and the driver returns the value from the previous conversion.
> >
> 
> Yes, this was the problem in the initial driver. The fix was to wait
> for the conversion to complete
> but it seems that it doesn't always work on your setup :(.
> 
>  if (change) {
> +   conv_time = DIV_ROUND_UP(USEC_PER_SEC, ads1015_data_rate[dr]);
> +   usleep_range(conv_time, conv_time + 1);
> +   }
> +
>

The result can theoretically take up to nearly 2 conversion cycles if the
request for a new channel comes in just as the previous conversion starts.

> 
> > For a test I multiplied the conv_time value by 2 in the 
> > ads1015_get_adc_result
> > function. This allows time for the current sample flush out and always 
> > returns
> > the appropriate channel's value.
> >
> > Looking at the buffered mode it appears that only one channel is being 
> > accessed
> > at any time. This being the first one in the active_scan_mask found by
> > find_first_bit. So the MUX would never change is buffered mode as far I can
> > tell.
> >
> > Don't we typically want to read all of enabled channels in buffered mode?
> 
> For the moment we allow only a single channel to be enabled in buffer mode.

Okay just making sure. Adding more channels would effectively divide the 
sampling
rate and increase the complexity of the driver.

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Tue, Mar 01, 2016 at 01:28:26PM +0200, Daniel Baluta wrote:
> On Tue, Mar 1, 2016 at 4:42 AM, Michael Welling  wrote:
> > On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> >> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling  wrote:
> >> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> >> The driver has sysfs readings with runtime PM support for power saving.
> >> >> It also offers buffer support that can be used together with IIO 
> >> >> software
> >> >> triggers.
> >> >>
> >> >
> >> > Daniel,
> >> >
> >> > So I noticed something yesterday while testing new boards.
> >> > The channels are occassionally swapping when accessing data from 
> >> > multiple channels.
> >> >
> >> > I wrote a simple bash script to demonstrate.
> >>
> >> This happened to me in a previous version of the patch. I remember it
> >> being fixed in the last version (or at least I could not reproduce).
> >> I'll test again tomorrow with your script.
> >>
> >
> > Here is what I believe is happening.
> >
> > The request for a conversion on a new channel comes in while the conversion
> > for the previous channel is still converting. The driver waits approximately
> > one conversion cycle. The previous channel completes within this timeframe
> > and the MUX is changed and the new sample is started. The new sample is 
> > still
> > converting and the driver returns the value from the previous conversion.
> >
> 
> Yes, this was the problem in the initial driver. The fix was to wait
> for the conversion to complete
> but it seems that it doesn't always work on your setup :(.
> 
>  if (change) {
> +   conv_time = DIV_ROUND_UP(USEC_PER_SEC, ads1015_data_rate[dr]);
> +   usleep_range(conv_time, conv_time + 1);
> +   }
> +
>

The result can theoretically take up to nearly 2 conversion cycles if the
request for a new channel comes in just as the previous conversion starts.

> 
> > For a test I multiplied the conv_time value by 2 in the 
> > ads1015_get_adc_result
> > function. This allows time for the current sample flush out and always 
> > returns
> > the appropriate channel's value.
> >
> > Looking at the buffered mode it appears that only one channel is being 
> > accessed
> > at any time. This being the first one in the active_scan_mask found by
> > find_first_bit. So the MUX would never change is buffered mode as far I can
> > tell.
> >
> > Don't we typically want to read all of enabled channels in buffered mode?
> 
> For the moment we allow only a single channel to be enabled in buffer mode.

Okay just making sure. Adding more channels would effectively divide the 
sampling
rate and increase the complexity of the driver.

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwell...@ieee.org> wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple 
> > channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Here is what I believe is happening.

The request for a conversion on a new channel comes in while the conversion
for the previous channel is still converting. The driver waits approximately
one conversion cycle. The previous channel completes within this timeframe
and the MUX is changed and the new sample is started. The new sample is still
converting and the driver returns the value from the previous conversion.

For a test I multiplied the conv_time value by 2 in the ads1015_get_adc_result
function. This allows time for the current sample flush out and always returns
the appropriate channel's value.

Looking at the buffered mode it appears that only one channel is being accessed
at any time. This being the first one in the active_scan_mask found by
find_first_bit. So the MUX would never change is buffered mode as far I can
tell.

Don't we typically want to read all of enabled channels in buffered mode?
 
> Lucas De Marchi

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling  wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple 
> > channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Here is what I believe is happening.

The request for a conversion on a new channel comes in while the conversion
for the previous channel is still converting. The driver waits approximately
one conversion cycle. The previous channel completes within this timeframe
and the MUX is changed and the new sample is started. The new sample is still
converting and the driver returns the value from the previous conversion.

For a test I multiplied the conv_time value by 2 in the ads1015_get_adc_result
function. This allows time for the current sample flush out and always returns
the appropriate channel's value.

Looking at the buffered mode it appears that only one channel is being accessed
at any time. This being the first one in the active_scan_mask found by
find_first_bit. So the MUX would never change is buffered mode as far I can
tell.

Don't we typically want to read all of enabled channels in buffered mode?
 
> Lucas De Marchi

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwell...@ieee.org> wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple 
> > channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Just verified that it is happening to me will the latest in linux-next.

root@dragonboard-410c:~# cat /proc/version 
Linux version 4.5.0-rc6-next-20160229+ (michael@deathstar) (gcc version 5.2.0 
(GCC) ) #1 SMP PREEMPT Mon Feb 29 19:27:11 CST 2016
root@dragonboard-410c:~# ./test-analog.sh 
ain0 = 267 ain1 = 286 ain2 = 268 ain3 = 288
ain0 = 283 ain1 = 284 ain2 = 284 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 285 ain2 = 287 ain3 = 0
ain0 = 282 ain1 = 284 ain2 = 287 ain3 = 0
ain0 = 283 ain1 = 284 ain2 = 286 ain3 = 0
ain0 = 283 ain1 = 290 ain2 = 285 ain3 = 288
ain0 = 284 ain1 = 286 ain2 = 285 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 285 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 289 ain3 = 0
.
.
 
> Lucas De Marchi

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling  wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple 
> > channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Just verified that it is happening to me will the latest in linux-next.

root@dragonboard-410c:~# cat /proc/version 
Linux version 4.5.0-rc6-next-20160229+ (michael@deathstar) (gcc version 5.2.0 
(GCC) ) #1 SMP PREEMPT Mon Feb 29 19:27:11 CST 2016
root@dragonboard-410c:~# ./test-analog.sh 
ain0 = 267 ain1 = 286 ain2 = 268 ain3 = 288
ain0 = 283 ain1 = 284 ain2 = 284 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 285 ain2 = 287 ain3 = 0
ain0 = 282 ain1 = 284 ain2 = 287 ain3 = 0
ain0 = 283 ain1 = 284 ain2 = 286 ain3 = 0
ain0 = 283 ain1 = 290 ain2 = 285 ain3 = 288
ain0 = 284 ain1 = 286 ain2 = 285 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 285 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 289 ain3 = 0
.
.
 
> Lucas De Marchi

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwell...@ieee.org> wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple 
> > channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Okay thanks. I will see if I am using a dated version of the driver for some 
reason.
 
> Lucas De Marchi

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling  wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple 
> > channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Okay thanks. I will see if I am using a dated version of the driver for some 
reason.
 
> Lucas De Marchi

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> The driver has sysfs readings with runtime PM support for power saving.
> It also offers buffer support that can be used together with IIO software
> triggers.
>

Daniel,

So I noticed something yesterday while testing new boards.
The channels are occassionally swapping when accessing data from multiple 
channels.

I wrote a simple bash script to demonstrate.

root@dragonboard-410c:~# cat test-analog.sh 
while [ 1 ]; do
voltage0=`cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw`
voltage1=`cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw`
voltage2=`cat /sys/bus/iio/devices/iio\:device0/in_voltage2_raw`
voltage3=`cat /sys/bus/iio/devices/iio\:device0/in_voltage3_raw`
echo ain0 = $voltage0 ain1 = $voltage1 ain2 = $voltage2 ain3 = $voltage3
done
root@dragonboard-410c:~# ./test-analog.sh 
ain0 = 266 ain1 = 291 ain2 = 268 ain3 = 291
ain0 = 287 ain1 = 294 ain2 = 289 ain3 = 292
ain0 = 284 ain1 = 294 ain2 = 286 ain3 = 0
ain0 = 285 ain1 = 288 ain2 = 287 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 285 ain1 = 287 ain2 = 293 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 293 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 290 ain3 = 291
ain0 = 287 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 0 ain1 = 285 ain2 = 288 ain3 = 0
ain0 = 285 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 288 ain2 = 285 ain3 = 0
ain0 = 287 ain1 = 293 ain2 = 289 ain3 = 292
ain0 = 288 ain1 = 292 ain2 = 287 ain3 = 293
ain0 = 286 ain1 = 287 ain2 = 289 ain3 = 0
ain0 = 283 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 288 ain2 = 289 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 290 ain3 = 0
ain0 = 289 ain1 = 291 ain2 = 287 ain3 = 0
ain0 = 284 ain1 = 286 ain2 = 292 ain3 = 0
ain0 = 286 ain1 = 291 ain2 = 289 ain3 = 292
ain0 = 284 ain1 = 292 ain2 = 291 ain3 = 291
ain0 = 285 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 288 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 287 ain2 = 290 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 285 ain1 = 289 ain2 = 288 ain3 = 288
ain0 = 289 ain1 = 292 ain2 = 289 ain3 = 293
ain0 = 287 ain1 = 292 ain2 = 290 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 290 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 289 ain3 = 0
ain0 = 284 ain1 = 285 ain2 = 292 ain3 = 0
ain0 = 285 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 287 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 287 ain1 = 291 ain2 = 287 ain3 = 291
ain0 = 288 ain1 = 291 ain2 = 290 ain3 = 293
ain0 = 285 ain1 = 290 ain2 = 287 ain3 = 292
ain0 = 285 ain1 = 289 ain2 = 289 ain3 = 292
ain0 = 286 ain1 = 289 ain2 = 288 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 291 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 288 ain1 = 286 ain2 = 289 ain3 = 0
ain0 = 284 ain1 = 289 ain2 = 288 ain3 = 0
ain0 = 287 ain1 = 290 ain2 = 287 ain3 = 292
ain0 = 285 ain1 = 292 ain2 = 289 ain3 = 292
ain0 = 289 ain1 = 292 ain2 = 290 ain3 = 0
.
.

The in_voltage3_raw channel is connected to GND the rest are left floating.
This does not happen if only one channels is accessed at a time.

I have not yet found the solution. Please left me know if this can be
duplicated on your end.

Regards,

Michael

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> The driver has sysfs readings with runtime PM support for power saving.
> It also offers buffer support that can be used together with IIO software
> triggers.
>

Daniel,

So I noticed something yesterday while testing new boards.
The channels are occassionally swapping when accessing data from multiple 
channels.

I wrote a simple bash script to demonstrate.

root@dragonboard-410c:~# cat test-analog.sh 
while [ 1 ]; do
voltage0=`cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw`
voltage1=`cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw`
voltage2=`cat /sys/bus/iio/devices/iio\:device0/in_voltage2_raw`
voltage3=`cat /sys/bus/iio/devices/iio\:device0/in_voltage3_raw`
echo ain0 = $voltage0 ain1 = $voltage1 ain2 = $voltage2 ain3 = $voltage3
done
root@dragonboard-410c:~# ./test-analog.sh 
ain0 = 266 ain1 = 291 ain2 = 268 ain3 = 291
ain0 = 287 ain1 = 294 ain2 = 289 ain3 = 292
ain0 = 284 ain1 = 294 ain2 = 286 ain3 = 0
ain0 = 285 ain1 = 288 ain2 = 287 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 285 ain1 = 287 ain2 = 293 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 293 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 290 ain3 = 291
ain0 = 287 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 0 ain1 = 285 ain2 = 288 ain3 = 0
ain0 = 285 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 288 ain2 = 285 ain3 = 0
ain0 = 287 ain1 = 293 ain2 = 289 ain3 = 292
ain0 = 288 ain1 = 292 ain2 = 287 ain3 = 293
ain0 = 286 ain1 = 287 ain2 = 289 ain3 = 0
ain0 = 283 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 288 ain2 = 289 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 290 ain3 = 0
ain0 = 289 ain1 = 291 ain2 = 287 ain3 = 0
ain0 = 284 ain1 = 286 ain2 = 292 ain3 = 0
ain0 = 286 ain1 = 291 ain2 = 289 ain3 = 292
ain0 = 284 ain1 = 292 ain2 = 291 ain3 = 291
ain0 = 285 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 288 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 287 ain2 = 290 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 285 ain1 = 289 ain2 = 288 ain3 = 288
ain0 = 289 ain1 = 292 ain2 = 289 ain3 = 293
ain0 = 287 ain1 = 292 ain2 = 290 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 290 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 289 ain3 = 0
ain0 = 284 ain1 = 285 ain2 = 292 ain3 = 0
ain0 = 285 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 287 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 287 ain1 = 291 ain2 = 287 ain3 = 291
ain0 = 288 ain1 = 291 ain2 = 290 ain3 = 293
ain0 = 285 ain1 = 290 ain2 = 287 ain3 = 292
ain0 = 285 ain1 = 289 ain2 = 289 ain3 = 292
ain0 = 286 ain1 = 289 ain2 = 288 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 291 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 288 ain1 = 286 ain2 = 289 ain3 = 0
ain0 = 284 ain1 = 289 ain2 = 288 ain3 = 0
ain0 = 287 ain1 = 290 ain2 = 287 ain3 = 292
ain0 = 285 ain1 = 292 ain2 = 289 ain3 = 292
ain0 = 289 ain1 = 292 ain2 = 290 ain3 = 0
.
.

The in_voltage3_raw channel is connected to GND the rest are left floating.
This does not happen if only one channels is accessed at a time.

I have not yet found the solution. Please left me know if this can be
duplicated on your end.

Regards,

Michael

Re: [LKP] [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Michael Welling]

On Tue, Feb 23, 2016 at 02:35:14PM +0800, Huang, Ying wrote:
> Linus Walleij <linus.wall...@linaro.org> writes:
> 
> > On Mon, Feb 15, 2016 at 3:39 AM, Huang, Ying <ying.hu...@intel.com> wrote:
> >> Michael Welling <mwell...@ieee.org> writes:
> >
> >>> Could you run cat /proc/devices?
> >>
> >> Sorry, the test mechanism is not flexible enough to run some shell
> >> command in test system.  Could you provide a specialized debug kernel to
> >> dump the necessary information in kernel log?  We can collect dmesg
> >> easily.
> >
> > Can you try this:
> >
> > diff --git a/fs/char_dev.c b/fs/char_dev.c
> > index 24b142569ca9..74a2d433273e 100644
> > --- a/fs/char_dev.c
> > +++ b/fs/char_dev.c
> > @@ -96,6 +96,8 @@ __register_chrdev_region(unsigned int major,
> > unsigned int baseminor,
> >  goto out;
> >  }
> >  major = i;
> > +pr_info("CHARDEV: allocate major %d for \"%s\"\n",
> > +i, name);
> >  }
> >
> >  cd->major = major;
> >
> > Then dmesg |grep CHARDEV should tell what we need to know.
> 
> Sorry for late, the dmesg with the patch is attached.  And the output of
> dmesg | grep CHARDEV is as follow:
> 
> [0.750037] CHARDEV: allocate major 254 for "gpiochip"
> [0.897928] CHARDEV: allocate major 253 for "tpm"
> [0.904196] CHARDEV: allocate major 252 for "ndctl"
> [0.905295] CHARDEV: allocate major 251 for "dimmctl"
> [0.909573] CHARDEV: allocate major 250 for "pps"
> [0.913740] CHARDEV: allocate major 249 for "ptp"
> [0.916711] CHARDEV: allocate major 248 for "iio"
> [1.227597] CHARDEV: allocate major 247 for "bsg"
> [1.577194] CHARDEV: allocate major 246 for "gsmtty"
> [1.614921] CHARDEV: allocate major 245 for "ttyn"
> [1.616044] CHARDEV: allocate major 244 for "ttyARC"
> [1.617177] CHARDEV: allocate major 243 for "ttyRP"
> [1.618310] CHARDEV: allocate major 242 for "ttyLP"
> [1.620618] CHARDEV: allocate major 241 for "noz"
> [1.621707] CHARDEV: allocate major 240 for "ttyIPWp"
> [1.630024] CHARDEV: allocate major 239 for "telco_clock"
> [1.632315] CHARDEV: allocate major 239 for "cmm"
> [1.681375] CHARDEV: allocate major 238 for "hpilo"
> [1.696757] CHARDEV: allocate major 237 for "aac"
> [1.699338] CHARDEV: allocate major 236 for "megadev_legacy"
> [1.704680] CHARDEV: allocate major 235 for "megaraid_sas_ioctl"
> [1.731179] CHARDEV: allocate major 234 for "pmcsas"

Not sure how this is the first time this problem has come up.
There is an obvious overlap here into the statically allocated region.

> [1.737520] CHARDEV: allocate major 233 for "nvme"
> [2.388531] CHARDEV: allocate major 232 for "firewire"
> [2.389743] CHARDEV: allocate major 231 for "uio"
> [2.904429] CHARDEV: allocate major 230 for "ttySDIO"
> [2.922374] CHARDEV: allocate major 229 for "ib_qib"
> [2.927559] CHARDEV: allocate major 228 for "hidraw"
> [2.952328] CHARDEV: allocate major 227 for "fwtty"
> [2.953435] CHARDEV: allocate major 225 for "fwloop"
> 
> Best Regards,
> Huang, Ying

Re: [LKP] [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Michael Welling]

On Tue, Feb 23, 2016 at 02:35:14PM +0800, Huang, Ying wrote:
> Linus Walleij  writes:
> 
> > On Mon, Feb 15, 2016 at 3:39 AM, Huang, Ying  wrote:
> >> Michael Welling  writes:
> >
> >>> Could you run cat /proc/devices?
> >>
> >> Sorry, the test mechanism is not flexible enough to run some shell
> >> command in test system.  Could you provide a specialized debug kernel to
> >> dump the necessary information in kernel log?  We can collect dmesg
> >> easily.
> >
> > Can you try this:
> >
> > diff --git a/fs/char_dev.c b/fs/char_dev.c
> > index 24b142569ca9..74a2d433273e 100644
> > --- a/fs/char_dev.c
> > +++ b/fs/char_dev.c
> > @@ -96,6 +96,8 @@ __register_chrdev_region(unsigned int major,
> > unsigned int baseminor,
> >  goto out;
> >  }
> >  major = i;
> > +pr_info("CHARDEV: allocate major %d for \"%s\"\n",
> > +i, name);
> >  }
> >
> >  cd->major = major;
> >
> > Then dmesg |grep CHARDEV should tell what we need to know.
> 
> Sorry for late, the dmesg with the patch is attached.  And the output of
> dmesg | grep CHARDEV is as follow:
> 
> [0.750037] CHARDEV: allocate major 254 for "gpiochip"
> [0.897928] CHARDEV: allocate major 253 for "tpm"
> [0.904196] CHARDEV: allocate major 252 for "ndctl"
> [0.905295] CHARDEV: allocate major 251 for "dimmctl"
> [0.909573] CHARDEV: allocate major 250 for "pps"
> [0.913740] CHARDEV: allocate major 249 for "ptp"
> [0.916711] CHARDEV: allocate major 248 for "iio"
> [1.227597] CHARDEV: allocate major 247 for "bsg"
> [1.577194] CHARDEV: allocate major 246 for "gsmtty"
> [1.614921] CHARDEV: allocate major 245 for "ttyn"
> [1.616044] CHARDEV: allocate major 244 for "ttyARC"
> [1.617177] CHARDEV: allocate major 243 for "ttyRP"
> [1.618310] CHARDEV: allocate major 242 for "ttyLP"
> [1.620618] CHARDEV: allocate major 241 for "noz"
> [1.621707] CHARDEV: allocate major 240 for "ttyIPWp"
> [1.630024] CHARDEV: allocate major 239 for "telco_clock"
> [1.632315] CHARDEV: allocate major 239 for "cmm"
> [1.681375] CHARDEV: allocate major 238 for "hpilo"
> [1.696757] CHARDEV: allocate major 237 for "aac"
> [1.699338] CHARDEV: allocate major 236 for "megadev_legacy"
> [1.704680] CHARDEV: allocate major 235 for "megaraid_sas_ioctl"
> [1.731179] CHARDEV: allocate major 234 for "pmcsas"

Not sure how this is the first time this problem has come up.
There is an obvious overlap here into the statically allocated region.

> [1.737520] CHARDEV: allocate major 233 for "nvme"
> [2.388531] CHARDEV: allocate major 232 for "firewire"
> [2.389743] CHARDEV: allocate major 231 for "uio"
> [2.904429] CHARDEV: allocate major 230 for "ttySDIO"
> [2.922374] CHARDEV: allocate major 229 for "ib_qib"
> [2.927559] CHARDEV: allocate major 228 for "hidraw"
> [2.952328] CHARDEV: allocate major 227 for "fwtty"
> [2.953435] CHARDEV: allocate major 225 for "fwloop"
> 
> Best Regards,
> Huang, Ying

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Wed, Feb 10, 2016 at 10:36:22AM -0600, Michael Welling wrote:
> On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > > Hi Sricharan,
> > > 
> > > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > > right?
> > >
> >  Yes.
> >  
> > > I'm asking this because this driver doesn't seem to support runtime pm and
> > > there is no check for regmap_write/regmap_write return code in the probe
> > > function.
> >Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> > right ?
> >I was tracking that when there are i2c_xfers from pwm. I did not see any 
> > failures there.
> >So wanted to know the correct sequence to reproduce.
> >
> 
> The problem was discovered using the patch that this thread is on. The PWM 
> driver does
> not have the problem.
> 
> When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

I noticed some patches for the QUP I2C driver in linux-next so I built against 
it.

The ADC driver now appears to work as desired.

root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw 
287
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw 
269
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage2_raw 
270
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage3_raw 
271

> 
> > Regards,
> >   Sricharan
> >   
> > 
> > 

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Wed, Feb 10, 2016 at 10:36:22AM -0600, Michael Welling wrote:
> On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > > Hi Sricharan,
> > > 
> > > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > > right?
> > >
> >  Yes.
> >  
> > > I'm asking this because this driver doesn't seem to support runtime pm and
> > > there is no check for regmap_write/regmap_write return code in the probe
> > > function.
> >Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> > right ?
> >I was tracking that when there are i2c_xfers from pwm. I did not see any 
> > failures there.
> >So wanted to know the correct sequence to reproduce.
> >
> 
> The problem was discovered using the patch that this thread is on. The PWM 
> driver does
> not have the problem.
> 
> When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

I noticed some patches for the QUP I2C driver in linux-next so I built against 
it.

The ADC driver now appears to work as desired.

root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw 
287
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw 
269
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage2_raw 
270
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage3_raw 
271

> 
> > Regards,
> >   Sricharan
> >   
> > 
> > 

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Mon, Feb 15, 2016 at 11:36:13AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Feb 15, 2016 at 12:50:41PM -0600, Michael Welling wrote:
> > On Mon, Feb 15, 2016 at 10:15:08AM -0800, Greg Kroah-Hartman wrote:
> > > On Sun, Feb 14, 2016 at 09:08:50PM -0600, Michael Welling wrote:
> > > > On Sun, Feb 14, 2016 at 03:17:36PM -0800, Greg Kroah-Hartman wrote:
> > > > > On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote:
> > > > > > On Sun, Feb 14, 2016 at 02:20:48PM -0800, Greg Kroah-Hartman wrote:
> > > > > > > 4.3-stable review patch.  If anyone has any objections, please 
> > > > > > > let me know.
> > > > > > >
> > > > > > 
> > > > > > If not planned it should be considered that we include the latest 
> > > > > > two
> > > > > > commits to spi-omap2-mcpsi into stable as well.
> > > > > > 
> > > > > > spi: omap2-mcspi: Prevent duplicate gpio_request
> > > > > > spi: omap2-mcspi: Add calls for pinctrl state select 
> > > > > > 
> > > > > > Let me know if I need to do anything to make this happen.
> > > > > 
> > > > > What are the git commit ids of them?
> > > > 
> > > > commit 2f538c017e1a8620d19553931199c6d6a6d31bb2
> > > > Author: Michael Welling <mwell...@ieee.org>
> > > > Date:   Mon Nov 30 09:02:39 2015 -0600
> > > > 
> > > > spi: omap2-mcspi: Prevent duplicate gpio_request
> > > > 
> > > > Occasionally the setup function will be called multiple times. Only 
> > > > request
> > > > the gpio the first time otherwise -EBUSY will occur on subsequent 
> > > > calls to
> > > > setup.
> > > > 
> > > > Reported-by: Joseph Bell <j...@iachieved.it>
> > > > 
> > > > Signed-off-by: Michael Welling <mwell...@ieee.org>
> > > > Signed-off-by: Mark Brown <broo...@kernel.org>
> > > 
> > > That seems reasonable but:
> > > 
> > > > commit beca365565d8f8912dce67567f54ad4c71734843
> > > > Author: Pascal Huerst <pascal.hue...@gmail.com>
> > > > Date:   Thu Nov 19 16:18:28 2015 +0100
> > > > 
> > > > spi: omap2-mcspi: Add calls for pinctrl state select
> > > > 
> > > > This adds calls to pinctrl subsystem in order to switch pin states
> > > > on suspend/resume if you provide a "sleep" state in DT.
> > > > 
> > > > If no "sleep" state is provided in DT, these calls turn
> > > > to NOPs.
> > > > 
> > > > Signed-off-by: Pascal Huerst <pascal.hue...@gmail.com>
> > > > Signed-off-by: Mark Brown <broo...@kernel.org>
> > > 
> > > That looks like a new feature being added.
> > > 
> > > > > What stable tree(s) do you want
> > > > > them applied to?
> > > > 
> > > > v4.3, v4.4
> > > 
> > > 4.3 is now end-of-life with this release, can you live with these just
> > > in 4.4-stable instead?
> > 
> > v4.4 stable is good enough.
> > 
> > Let me know what needs to be done if anything.
> 
> That last patch does not seem like it follows the rules documented at
> Documentation/stable_kernel_rules.txt, so I can't take it.
>

Okay sorry for the noise.

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Mon, Feb 15, 2016 at 11:36:13AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Feb 15, 2016 at 12:50:41PM -0600, Michael Welling wrote:
> > On Mon, Feb 15, 2016 at 10:15:08AM -0800, Greg Kroah-Hartman wrote:
> > > On Sun, Feb 14, 2016 at 09:08:50PM -0600, Michael Welling wrote:
> > > > On Sun, Feb 14, 2016 at 03:17:36PM -0800, Greg Kroah-Hartman wrote:
> > > > > On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote:
> > > > > > On Sun, Feb 14, 2016 at 02:20:48PM -0800, Greg Kroah-Hartman wrote:
> > > > > > > 4.3-stable review patch.  If anyone has any objections, please 
> > > > > > > let me know.
> > > > > > >
> > > > > > 
> > > > > > If not planned it should be considered that we include the latest 
> > > > > > two
> > > > > > commits to spi-omap2-mcpsi into stable as well.
> > > > > > 
> > > > > > spi: omap2-mcspi: Prevent duplicate gpio_request
> > > > > > spi: omap2-mcspi: Add calls for pinctrl state select 
> > > > > > 
> > > > > > Let me know if I need to do anything to make this happen.
> > > > > 
> > > > > What are the git commit ids of them?
> > > > 
> > > > commit 2f538c017e1a8620d19553931199c6d6a6d31bb2
> > > > Author: Michael Welling 
> > > > Date:   Mon Nov 30 09:02:39 2015 -0600
> > > > 
> > > > spi: omap2-mcspi: Prevent duplicate gpio_request
> > > > 
> > > > Occasionally the setup function will be called multiple times. Only 
> > > > request
> > > > the gpio the first time otherwise -EBUSY will occur on subsequent 
> > > > calls to
> > > > setup.
> > > > 
> > > > Reported-by: Joseph Bell 
> > > > 
> > > > Signed-off-by: Michael Welling 
> > > > Signed-off-by: Mark Brown 
> > > 
> > > That seems reasonable but:
> > > 
> > > > commit beca365565d8f8912dce67567f54ad4c71734843
> > > > Author: Pascal Huerst 
> > > > Date:   Thu Nov 19 16:18:28 2015 +0100
> > > > 
> > > > spi: omap2-mcspi: Add calls for pinctrl state select
> > > > 
> > > > This adds calls to pinctrl subsystem in order to switch pin states
> > > > on suspend/resume if you provide a "sleep" state in DT.
> > > > 
> > > > If no "sleep" state is provided in DT, these calls turn
> > > > to NOPs.
> > > > 
> > > > Signed-off-by: Pascal Huerst 
> > > > Signed-off-by: Mark Brown 
> > > 
> > > That looks like a new feature being added.
> > > 
> > > > > What stable tree(s) do you want
> > > > > them applied to?
> > > > 
> > > > v4.3, v4.4
> > > 
> > > 4.3 is now end-of-life with this release, can you live with these just
> > > in 4.4-stable instead?
> > 
> > v4.4 stable is good enough.
> > 
> > Let me know what needs to be done if anything.
> 
> That last patch does not seem like it follows the rules documented at
> Documentation/stable_kernel_rules.txt, so I can't take it.
>

Okay sorry for the noise.

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Mon, Feb 15, 2016 at 10:15:08AM -0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 14, 2016 at 09:08:50PM -0600, Michael Welling wrote:
> > On Sun, Feb 14, 2016 at 03:17:36PM -0800, Greg Kroah-Hartman wrote:
> > > On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote:
> > > > On Sun, Feb 14, 2016 at 02:20:48PM -0800, Greg Kroah-Hartman wrote:
> > > > > 4.3-stable review patch.  If anyone has any objections, please let me 
> > > > > know.
> > > > >
> > > > 
> > > > If not planned it should be considered that we include the latest two
> > > > commits to spi-omap2-mcpsi into stable as well.
> > > > 
> > > > spi: omap2-mcspi: Prevent duplicate gpio_request
> > > > spi: omap2-mcspi: Add calls for pinctrl state select 
> > > > 
> > > > Let me know if I need to do anything to make this happen.
> > > 
> > > What are the git commit ids of them?
> > 
> > commit 2f538c017e1a8620d19553931199c6d6a6d31bb2
> > Author: Michael Welling <mwell...@ieee.org>
> > Date:   Mon Nov 30 09:02:39 2015 -0600
> > 
> > spi: omap2-mcspi: Prevent duplicate gpio_request
> > 
> > Occasionally the setup function will be called multiple times. Only 
> > request
> > the gpio the first time otherwise -EBUSY will occur on subsequent calls 
> > to
> > setup.
> > 
> > Reported-by: Joseph Bell <j...@iachieved.it>
> > 
> > Signed-off-by: Michael Welling <mwell...@ieee.org>
> > Signed-off-by: Mark Brown <broo...@kernel.org>
> 
> That seems reasonable but:
> 
> > commit beca365565d8f8912dce67567f54ad4c71734843
> > Author: Pascal Huerst <pascal.hue...@gmail.com>
> > Date:   Thu Nov 19 16:18:28 2015 +0100
> > 
> > spi: omap2-mcspi: Add calls for pinctrl state select
> > 
> > This adds calls to pinctrl subsystem in order to switch pin states
> > on suspend/resume if you provide a "sleep" state in DT.
> > 
> > If no "sleep" state is provided in DT, these calls turn
> > to NOPs.
> > 
> > Signed-off-by: Pascal Huerst <pascal.hue...@gmail.com>
> > Signed-off-by: Mark Brown <broo...@kernel.org>
> 
> That looks like a new feature being added.
> 
> > > What stable tree(s) do you want
> > > them applied to?
> > 
> > v4.3, v4.4
> 
> 4.3 is now end-of-life with this release, can you live with these just
> in 4.4-stable instead?

v4.4 stable is good enough.

Let me know what needs to be done if anything.

> 
> thanks,
> 
> greg k-h

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Mon, Feb 15, 2016 at 10:15:08AM -0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 14, 2016 at 09:08:50PM -0600, Michael Welling wrote:
> > On Sun, Feb 14, 2016 at 03:17:36PM -0800, Greg Kroah-Hartman wrote:
> > > On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote:
> > > > On Sun, Feb 14, 2016 at 02:20:48PM -0800, Greg Kroah-Hartman wrote:
> > > > > 4.3-stable review patch.  If anyone has any objections, please let me 
> > > > > know.
> > > > >
> > > > 
> > > > If not planned it should be considered that we include the latest two
> > > > commits to spi-omap2-mcpsi into stable as well.
> > > > 
> > > > spi: omap2-mcspi: Prevent duplicate gpio_request
> > > > spi: omap2-mcspi: Add calls for pinctrl state select 
> > > > 
> > > > Let me know if I need to do anything to make this happen.
> > > 
> > > What are the git commit ids of them?
> > 
> > commit 2f538c017e1a8620d19553931199c6d6a6d31bb2
> > Author: Michael Welling 
> > Date:   Mon Nov 30 09:02:39 2015 -0600
> > 
> > spi: omap2-mcspi: Prevent duplicate gpio_request
> > 
> > Occasionally the setup function will be called multiple times. Only 
> > request
> > the gpio the first time otherwise -EBUSY will occur on subsequent calls 
> > to
> > setup.
> > 
> > Reported-by: Joseph Bell 
> > 
> > Signed-off-by: Michael Welling 
> > Signed-off-by: Mark Brown 
> 
> That seems reasonable but:
> 
> > commit beca365565d8f8912dce67567f54ad4c71734843
> > Author: Pascal Huerst 
> > Date:   Thu Nov 19 16:18:28 2015 +0100
> > 
> > spi: omap2-mcspi: Add calls for pinctrl state select
> > 
> > This adds calls to pinctrl subsystem in order to switch pin states
> > on suspend/resume if you provide a "sleep" state in DT.
> > 
> > If no "sleep" state is provided in DT, these calls turn
> > to NOPs.
> > 
> > Signed-off-by: Pascal Huerst 
> > Signed-off-by: Mark Brown 
> 
> That looks like a new feature being added.
> 
> > > What stable tree(s) do you want
> > > them applied to?
> > 
> > v4.3, v4.4
> 
> 4.3 is now end-of-life with this release, can you live with these just
> in 4.4-stable instead?

v4.4 stable is good enough.

Let me know what needs to be done if anything.

> 
> thanks,
> 
> greg k-h

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Mon, Feb 15, 2016 at 11:03:51AM +, Mark Brown wrote:
> On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote:
> 
> > spi: omap2-mcspi: Add calls for pinctrl state select 
> 
> That doesn't sound like stable material, it's adding a new feature which
> might break existing systems if they have buggy configuration defined in
> DT which we suddenly start using.

Okay.

I was looking to get the GPIO registration fix in and figured that
it would be easier to merge with both.

Greg, How do you want to handle this?

Try to patch and see if it applies with fuzz or have me provide a
patch that applies to the stable?

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Mon, Feb 15, 2016 at 11:03:51AM +, Mark Brown wrote:
> On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote:
> 
> > spi: omap2-mcspi: Add calls for pinctrl state select 
> 
> That doesn't sound like stable material, it's adding a new feature which
> might break existing systems if they have buggy configuration defined in
> DT which we suddenly start using.

Okay.

I was looking to get the GPIO registration fix in and figured that
it would be easier to merge with both.

Greg, How do you want to handle this?

Try to patch and see if it applies with fuzz or have me provide a
patch that applies to the stable?

Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Michael Welling]

On Sun, Feb 14, 2016 at 03:49:54PM -0800, Greg KH wrote:
> On Sun, Feb 14, 2016 at 01:51:20PM -0600, Michael Welling wrote:
> > On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> > > On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > > > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH <gre...@linuxfoundation.org> 
> > > > wrote:
> > > > > On Sun, Feb 14, 2016 at 06:42:11PM +0100, Linus Walleij wrote:
> > > > >> Greg, heads-up on this... you'd know if this happened
> > > > >> before.
> > > > >>
> > > > >> On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling <mwell...@ieee.org> 
> > > > >> wrote:
> > > > >> > On Sun, Feb 14, 2016 at 02:59:06PM +0800, kernel test robot wrote:
> > > > >> >> FYI, we noticed the below changes on
> > > > >> >>
> > > > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
> > > > >> >>  chardev
> > > > >> >> commit 3c702e9987e261042a07e43460a8148be254412e ("gpio: add a 
> > > > >> >> userspace chardev ABI for GPIOs")
> > > > >> >>
> > > > >> >>
> > > > >> >> [1.951191] user_verbs: couldn't register device number
> > > > >> >
> > > > >> > Looks like user_verbs is using a static device node setup.
> > > > >> >
> > > > >> > enum {
> > > > >> > IB_UVERBS_MAJOR   = 231,
> > > > >> > IB_UVERBS_BASE_MINOR  = 192,
> > > > >> > IB_UVERBS_MAX_DEVICES = 32
> > > > >> > };
> > > > >> >
> > > > >> > #define IB_UVERBS_BASE_DEV  MKDEV(IB_UVERBS_MAJOR, 
> > > > >> > IB_UVERBS_BASE_MINOR)
> > > > >>
> > > > >> That's annoying...
> > > > >> I notice that infiniband is using register_chrdev_region() at
> > > > >> module_init() time, counting on device major 231 to be free.
> > > > >
> > > > > That device major is assigned to Infiniband, why shouldn't it be doing
> > > > > this?
> > > > 
> > > > I mean it's annoying that they collide. (Because of the details I
> > > > write below, it's fine it's using the assigned number.
> > > > 
> > > > > Why not just ask for a new reserved one?  We could give you 261 and
> > > > > everything should be fine, right?
> > > > 
> > > > Sure I can post a patch for that, but it just mitigates the problem.
> > > > 
> > > > The report point to the serious problem that on this system
> > > > some dynamic allocations have already stolen major device
> > > > numbers 232 thru 255, and 232 and 233 are also assigned.
> > > > 
> > > > What do you think about a patch that makes fs/char_dev.c
> > > > emit a warning when it starts assigning dynamic numbers
> > > > 233 and below?
> > > 
> > > That's fine with me.  I also think maybe we should look into just
> > > switching all char major/minor allocation to be dynamic, starting at the
> > > bottom and moving up.  I think the only tools that might have an issue
> > > with that is the raw device controller, but maybe that has been fixed up
> > > in userspace, I haven't looked at that in many years.
> > >
> > 
> > Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
> > If we increase the size to say 511 will it break userspace?
> 
> No, that's an internal thing, but I don't see what that has to do with
> this...
> 
> > In the future I see a robot building a kernel with more that 255 devices and
> > having to deal with this kind of collision again.
> 
> We handle major numbers larger than 255 already...
> 
> > The handling of large major assignment baffles me.
> 
> It's tricky, messy, and something you don't want to touch, seriously...
>

Doh... I see now that each entry in the table is a list.

But then the dynamic allocation only looks for a NULL entry in the table.
So the limitation appears to be 255 dynamically allocated devices so still
has something to do with this.

Another simpler alternate to going completely dynamic is allocate dynamically
starting at an offset outside of the fixed range and just increment the major
on a first come first serve basis.

I guess that the current number would have to be stored somewhere.

Does this make sense or am I still not understanding how this works?

> good luck,
> 
> greg k-h

Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Michael Welling]

On Sun, Feb 14, 2016 at 03:49:54PM -0800, Greg KH wrote:
> On Sun, Feb 14, 2016 at 01:51:20PM -0600, Michael Welling wrote:
> > On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> > > On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > > > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  
> > > > wrote:
> > > > > On Sun, Feb 14, 2016 at 06:42:11PM +0100, Linus Walleij wrote:
> > > > >> Greg, heads-up on this... you'd know if this happened
> > > > >> before.
> > > > >>
> > > > >> On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling  
> > > > >> wrote:
> > > > >> > On Sun, Feb 14, 2016 at 02:59:06PM +0800, kernel test robot wrote:
> > > > >> >> FYI, we noticed the below changes on
> > > > >> >>
> > > > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
> > > > >> >>  chardev
> > > > >> >> commit 3c702e9987e261042a07e43460a8148be254412e ("gpio: add a 
> > > > >> >> userspace chardev ABI for GPIOs")
> > > > >> >>
> > > > >> >>
> > > > >> >> [1.951191] user_verbs: couldn't register device number
> > > > >> >
> > > > >> > Looks like user_verbs is using a static device node setup.
> > > > >> >
> > > > >> > enum {
> > > > >> > IB_UVERBS_MAJOR   = 231,
> > > > >> > IB_UVERBS_BASE_MINOR  = 192,
> > > > >> > IB_UVERBS_MAX_DEVICES = 32
> > > > >> > };
> > > > >> >
> > > > >> > #define IB_UVERBS_BASE_DEV  MKDEV(IB_UVERBS_MAJOR, 
> > > > >> > IB_UVERBS_BASE_MINOR)
> > > > >>
> > > > >> That's annoying...
> > > > >> I notice that infiniband is using register_chrdev_region() at
> > > > >> module_init() time, counting on device major 231 to be free.
> > > > >
> > > > > That device major is assigned to Infiniband, why shouldn't it be doing
> > > > > this?
> > > > 
> > > > I mean it's annoying that they collide. (Because of the details I
> > > > write below, it's fine it's using the assigned number.
> > > > 
> > > > > Why not just ask for a new reserved one?  We could give you 261 and
> > > > > everything should be fine, right?
> > > > 
> > > > Sure I can post a patch for that, but it just mitigates the problem.
> > > > 
> > > > The report point to the serious problem that on this system
> > > > some dynamic allocations have already stolen major device
> > > > numbers 232 thru 255, and 232 and 233 are also assigned.
> > > > 
> > > > What do you think about a patch that makes fs/char_dev.c
> > > > emit a warning when it starts assigning dynamic numbers
> > > > 233 and below?
> > > 
> > > That's fine with me.  I also think maybe we should look into just
> > > switching all char major/minor allocation to be dynamic, starting at the
> > > bottom and moving up.  I think the only tools that might have an issue
> > > with that is the raw device controller, but maybe that has been fixed up
> > > in userspace, I haven't looked at that in many years.
> > >
> > 
> > Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
> > If we increase the size to say 511 will it break userspace?
> 
> No, that's an internal thing, but I don't see what that has to do with
> this...
> 
> > In the future I see a robot building a kernel with more that 255 devices and
> > having to deal with this kind of collision again.
> 
> We handle major numbers larger than 255 already...
> 
> > The handling of large major assignment baffles me.
> 
> It's tricky, messy, and something you don't want to touch, seriously...
>

Doh... I see now that each entry in the table is a list.

But then the dynamic allocation only looks for a NULL entry in the table.
So the limitation appears to be 255 dynamically allocated devices so still
has something to do with this.

Another simpler alternate to going completely dynamic is allocate dynamically
starting at an offset outside of the fixed range and just increment the major
on a first come first serve basis.

I guess that the current number would have to be stored somewhere.

Does this make sense or am I still not understanding how this works?

> good luck,
> 
> greg k-h

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Sun, Feb 14, 2016 at 03:17:36PM -0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote:
> > On Sun, Feb 14, 2016 at 02:20:48PM -0800, Greg Kroah-Hartman wrote:
> > > 4.3-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > >
> > 
> > If not planned it should be considered that we include the latest two
> > commits to spi-omap2-mcpsi into stable as well.
> > 
> > spi: omap2-mcspi: Prevent duplicate gpio_request
> > spi: omap2-mcspi: Add calls for pinctrl state select 
> > 
> > Let me know if I need to do anything to make this happen.
> 
> What are the git commit ids of them?

commit 2f538c017e1a8620d19553931199c6d6a6d31bb2
Author: Michael Welling <mwell...@ieee.org>
Date:   Mon Nov 30 09:02:39 2015 -0600

spi: omap2-mcspi: Prevent duplicate gpio_request

Occasionally the setup function will be called multiple times. Only request
the gpio the first time otherwise -EBUSY will occur on subsequent calls to
    setup.

Reported-by: Joseph Bell <j...@iachieved.it>

Signed-off-by: Michael Welling <mwell...@ieee.org>
Signed-off-by: Mark Brown <broo...@kernel.org>

commit beca365565d8f8912dce67567f54ad4c71734843
Author: Pascal Huerst <pascal.hue...@gmail.com>
Date:   Thu Nov 19 16:18:28 2015 +0100

spi: omap2-mcspi: Add calls for pinctrl state select

This adds calls to pinctrl subsystem in order to switch pin states
on suspend/resume if you provide a "sleep" state in DT.

If no "sleep" state is provided in DT, these calls turn
to NOPs.

Signed-off-by: Pascal Huerst <pascal.hue...@gmail.com>
Signed-off-by: Mark Brown <broo...@kernel.org>


> What stable tree(s) do you want
> them applied to?

v4.3, v4.4

> 
> thanks,
> 
> greg k-h

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Sun, Feb 14, 2016 at 03:17:36PM -0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 14, 2016 at 04:50:47PM -0600, Michael Welling wrote:
> > On Sun, Feb 14, 2016 at 02:20:48PM -0800, Greg Kroah-Hartman wrote:
> > > 4.3-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > >
> > 
> > If not planned it should be considered that we include the latest two
> > commits to spi-omap2-mcpsi into stable as well.
> > 
> > spi: omap2-mcspi: Prevent duplicate gpio_request
> > spi: omap2-mcspi: Add calls for pinctrl state select 
> > 
> > Let me know if I need to do anything to make this happen.
> 
> What are the git commit ids of them?

commit 2f538c017e1a8620d19553931199c6d6a6d31bb2
Author: Michael Welling 
Date:   Mon Nov 30 09:02:39 2015 -0600

spi: omap2-mcspi: Prevent duplicate gpio_request

Occasionally the setup function will be called multiple times. Only request
the gpio the first time otherwise -EBUSY will occur on subsequent calls to
setup.

Reported-by: Joseph Bell 

Signed-off-by: Michael Welling 
Signed-off-by: Mark Brown 

commit beca365565d8f8912dce67567f54ad4c71734843
Author: Pascal Huerst 
Date:   Thu Nov 19 16:18:28 2015 +0100

spi: omap2-mcspi: Add calls for pinctrl state select

This adds calls to pinctrl subsystem in order to switch pin states
on suspend/resume if you provide a "sleep" state in DT.

If no "sleep" state is provided in DT, these calls turn
to NOPs.

Signed-off-by: Pascal Huerst 
Signed-off-by: Mark Brown 


> What stable tree(s) do you want
> them applied to?

v4.3, v4.4

> 
> thanks,
> 
> greg k-h

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Sun, Feb 14, 2016 at 02:20:48PM -0800, Greg Kroah-Hartman wrote:
> 4.3-stable review patch.  If anyone has any objections, please let me know.
>

If not planned it should be considered that we include the latest two
commits to spi-omap2-mcpsi into stable as well.

spi: omap2-mcspi: Prevent duplicate gpio_request
spi: omap2-mcspi: Add calls for pinctrl state select 

Let me know if I need to do anything to make this happen.

> --
> 
> From: Neil Armstrong 
> 
> commit 468a32082b04c7febccfcd55b06ecbc438fcddcc upstream.
> 
> Since the "Switch driver to use transfer_one" change, the cs_change
> behavior has changed and a channel chip select can still be
> asserted when changing channel from a previous last transfer in a
> message having the cs_change attribute.
> 
> Since there is no sense having multiple chip select being asserted at the
> same time, disable all the remaining forced chip selects in a the
> prepare_message called right before a spi_transfer_one_message call.
> It ignores the current channel configuration in order to keep the
> possibility to leave the chip select asserted between messages.
> 
> It fixes this bug on a DM8168 SoC ES2.1 Soc and an OMAP4 ES2.1 SoC.
> It was hanging all the other channels transfers when a CHCONF_FORCE
> is present on the wrong channel.
> 
> Fixes: b28cb9414db9 ("spi: omap2-mcspi: Switch driver to use transfer_one")
> Signed-off-by: Neil Armstrong 
> Reviewed-by: Michael Welling 
> Signed-off-by: Mark Brown 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  drivers/spi/spi-omap2-mcspi.c |   28 
>  1 file changed, 28 insertions(+)
> 
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -1217,6 +1217,33 @@ out:
>   return status;
>  }
>  
> +static int omap2_mcspi_prepare_message(struct spi_master *master,
> +struct spi_message *msg)
> +{
> + struct omap2_mcspi  *mcspi = spi_master_get_devdata(master);
> + struct omap2_mcspi_regs *ctx = >ctx;
> + struct omap2_mcspi_cs   *cs;
> +
> + /* Only a single channel can have the FORCE bit enabled
> +  * in its chconf0 register.
> +  * Scan all channels and disable them except the current one.
> +  * A FORCE can remain from a last transfer having cs_change enabled
> +  */
> + list_for_each_entry(cs, >cs, node) {
> + if (msg->spi->controller_state == cs)
> + continue;
> +
> + if ((cs->chconf0 & OMAP2_MCSPI_CHCONF_FORCE)) {
> + cs->chconf0 &= ~OMAP2_MCSPI_CHCONF_FORCE;
> + writel_relaxed(cs->chconf0,
> + cs->base + OMAP2_MCSPI_CHCONF0);
> + readl_relaxed(cs->base + OMAP2_MCSPI_CHCONF0);
> + }
> + }
> +
> + return 0;
> +}
> +
>  static int omap2_mcspi_transfer_one(struct spi_master *master,
>   struct spi_device *spi, struct spi_transfer *t)
>  {
> @@ -1344,6 +1371,7 @@ static int omap2_mcspi_probe(struct plat
>   master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
>   master->setup = omap2_mcspi_setup;
>   master->auto_runtime_pm = true;
> + master->prepare_message = omap2_mcspi_prepare_message;
>   master->transfer_one = omap2_mcspi_transfer_one;
>   master->set_cs = omap2_mcspi_set_cs;
>   master->cleanup = omap2_mcspi_cleanup;
> 
> 

Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Michael Welling]

On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  wrote:
> > > On Sun, Feb 14, 2016 at 06:42:11PM +0100, Linus Walleij wrote:
> > >> Greg, heads-up on this... you'd know if this happened
> > >> before.
> > >>
> > >> On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling  
> > >> wrote:
> > >> > On Sun, Feb 14, 2016 at 02:59:06PM +0800, kernel test robot wrote:
> > >> >> FYI, we noticed the below changes on
> > >> >>
> > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
> > >> >> chardev
> > >> >> commit 3c702e9987e261042a07e43460a8148be254412e ("gpio: add a 
> > >> >> userspace chardev ABI for GPIOs")
> > >> >>
> > >> >>
> > >> >> [1.951191] user_verbs: couldn't register device number
> > >> >
> > >> > Looks like user_verbs is using a static device node setup.
> > >> >
> > >> > enum {
> > >> > IB_UVERBS_MAJOR   = 231,
> > >> > IB_UVERBS_BASE_MINOR  = 192,
> > >> > IB_UVERBS_MAX_DEVICES = 32
> > >> > };
> > >> >
> > >> > #define IB_UVERBS_BASE_DEV  MKDEV(IB_UVERBS_MAJOR, 
> > >> > IB_UVERBS_BASE_MINOR)
> > >>
> > >> That's annoying...
> > >> I notice that infiniband is using register_chrdev_region() at
> > >> module_init() time, counting on device major 231 to be free.
> > >
> > > That device major is assigned to Infiniband, why shouldn't it be doing
> > > this?
> > 
> > I mean it's annoying that they collide. (Because of the details I
> > write below, it's fine it's using the assigned number.
> > 
> > > Why not just ask for a new reserved one?  We could give you 261 and
> > > everything should be fine, right?
> > 
> > Sure I can post a patch for that, but it just mitigates the problem.
> > 
> > The report point to the serious problem that on this system
> > some dynamic allocations have already stolen major device
> > numbers 232 thru 255, and 232 and 233 are also assigned.
> > 
> > What do you think about a patch that makes fs/char_dev.c
> > emit a warning when it starts assigning dynamic numbers
> > 233 and below?
> 
> That's fine with me.  I also think maybe we should look into just
> switching all char major/minor allocation to be dynamic, starting at the
> bottom and moving up.  I think the only tools that might have an issue
> with that is the raw device controller, but maybe that has been fixed up
> in userspace, I haven't looked at that in many years.
>

Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
If we increase the size to say 511 will it break userspace?

In the future I see a robot building a kernel with more that 255 devices and
having to deal with this kind of collision again.

The handling of large major assignment baffles me.
The major numbers outside of the size of the table are just wrapping around to
the beginning again. This is inherently going to cause collisions.

static inline int major_to_index(unsigned major)
{
return major % CHRDEV_MAJOR_HASH_SIZE;
}

> I thought I had an old patch around somewhere that did that, will go
> look for it this week and see what breaks with it enabled...
> 
> thanks,
> 
> greg k-h

Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Michael Welling]

On Sun, Feb 14, 2016 at 02:59:06PM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git chardev
> commit 3c702e9987e261042a07e43460a8148be254412e ("gpio: add a userspace 
> chardev ABI for GPIOs")
> 
> 
> [1.951191] user_verbs: couldn't register device number

Looks like user_verbs is using a static device node setup.

enum {
IB_UVERBS_MAJOR   = 231,
IB_UVERBS_BASE_MINOR  = 192,
IB_UVERBS_MAX_DEVICES = 32
};

#define IB_UVERBS_BASE_DEV  MKDEV(IB_UVERBS_MAJOR, IB_UVERBS_BASE_MINOR)

Something tells me that a new GPIO chardev is taking this spot.

It looks like the device is documented to be using the range:
https://www.kernel.org/doc/Documentation/devices.txt

Could you run cat /proc/devices?

> [1.952527] ucm: couldn't register device number
> 
> 
> Thanks,
> Ying Huang

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.5.0-rc1 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_PERF_EVENTS_INTEL_UNCORE=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi 
> -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 
> -fcall-saved-r10 -fcall-saved-r11"
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_PGTABLE_LEVELS=4
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> # CONFIG_USELIB is not set
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_DEBUG=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_HZ_PERIODIC=y
> # CONFIG_NO_HZ_IDLE is not set
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> # CONFIG_HIGH_RES_TIMERS is not set
> 
> #
> # CPU/Task time and stats accounting
> #
> # CONFIG_TICK_CPU_ACCOUNTING is not set
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> CONFIG_IRQ_TIME_ACCOUNTING=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> # CONFIG_TASKSTATS is not set
> 
> #
> # RCU Subsystem
> #
> CONFIG_TREE_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> # CONFIG_IKCONFIG_PROC is not set
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
> CONFIG_ARCH_SUPPORTS_INT128=y
> # 

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

[Michael Welling]

On Sun, Feb 14, 2016 at 02:20:48PM -0800, Greg Kroah-Hartman wrote:
> 4.3-stable review patch.  If anyone has any objections, please let me know.
>

If not planned it should be considered that we include the latest two
commits to spi-omap2-mcpsi into stable as well.

spi: omap2-mcspi: Prevent duplicate gpio_request
spi: omap2-mcspi: Add calls for pinctrl state select 

Let me know if I need to do anything to make this happen.

> --
> 
> From: Neil Armstrong <narmstr...@baylibre.com>
> 
> commit 468a32082b04c7febccfcd55b06ecbc438fcddcc upstream.
> 
> Since the "Switch driver to use transfer_one" change, the cs_change
> behavior has changed and a channel chip select can still be
> asserted when changing channel from a previous last transfer in a
> message having the cs_change attribute.
> 
> Since there is no sense having multiple chip select being asserted at the
> same time, disable all the remaining forced chip selects in a the
> prepare_message called right before a spi_transfer_one_message call.
> It ignores the current channel configuration in order to keep the
> possibility to leave the chip select asserted between messages.
> 
> It fixes this bug on a DM8168 SoC ES2.1 Soc and an OMAP4 ES2.1 SoC.
> It was hanging all the other channels transfers when a CHCONF_FORCE
> is present on the wrong channel.
> 
> Fixes: b28cb9414db9 ("spi: omap2-mcspi: Switch driver to use transfer_one")
> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
> Reviewed-by: Michael Welling <mwell...@ieee.org>
> Signed-off-by: Mark Brown <broo...@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> 
> ---
>  drivers/spi/spi-omap2-mcspi.c |   28 
>  1 file changed, 28 insertions(+)
> 
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -1217,6 +1217,33 @@ out:
>   return status;
>  }
>  
> +static int omap2_mcspi_prepare_message(struct spi_master *master,
> +struct spi_message *msg)
> +{
> + struct omap2_mcspi  *mcspi = spi_master_get_devdata(master);
> + struct omap2_mcspi_regs *ctx = >ctx;
> + struct omap2_mcspi_cs   *cs;
> +
> + /* Only a single channel can have the FORCE bit enabled
> +  * in its chconf0 register.
> +  * Scan all channels and disable them except the current one.
> +  * A FORCE can remain from a last transfer having cs_change enabled
> +  */
> + list_for_each_entry(cs, >cs, node) {
> + if (msg->spi->controller_state == cs)
> + continue;
> +
> + if ((cs->chconf0 & OMAP2_MCSPI_CHCONF_FORCE)) {
> + cs->chconf0 &= ~OMAP2_MCSPI_CHCONF_FORCE;
> + writel_relaxed(cs->chconf0,
> + cs->base + OMAP2_MCSPI_CHCONF0);
> + readl_relaxed(cs->base + OMAP2_MCSPI_CHCONF0);
> + }
> + }
> +
> + return 0;
> +}
> +
>  static int omap2_mcspi_transfer_one(struct spi_master *master,
>   struct spi_device *spi, struct spi_transfer *t)
>  {
> @@ -1344,6 +1371,7 @@ static int omap2_mcspi_probe(struct plat
>   master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
>   master->setup = omap2_mcspi_setup;
>   master->auto_runtime_pm = true;
> + master->prepare_message = omap2_mcspi_prepare_message;
>   master->transfer_one = omap2_mcspi_transfer_one;
>   master->set_cs = omap2_mcspi_set_cs;
>   master->cleanup = omap2_mcspi_cleanup;
> 
> 

Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Michael Welling]

On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH <gre...@linuxfoundation.org> wrote:
> > > On Sun, Feb 14, 2016 at 06:42:11PM +0100, Linus Walleij wrote:
> > >> Greg, heads-up on this... you'd know if this happened
> > >> before.
> > >>
> > >> On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling <mwell...@ieee.org> 
> > >> wrote:
> > >> > On Sun, Feb 14, 2016 at 02:59:06PM +0800, kernel test robot wrote:
> > >> >> FYI, we noticed the below changes on
> > >> >>
> > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
> > >> >> chardev
> > >> >> commit 3c702e9987e261042a07e43460a8148be254412e ("gpio: add a 
> > >> >> userspace chardev ABI for GPIOs")
> > >> >>
> > >> >>
> > >> >> [1.951191] user_verbs: couldn't register device number
> > >> >
> > >> > Looks like user_verbs is using a static device node setup.
> > >> >
> > >> > enum {
> > >> > IB_UVERBS_MAJOR   = 231,
> > >> > IB_UVERBS_BASE_MINOR  = 192,
> > >> > IB_UVERBS_MAX_DEVICES = 32
> > >> > };
> > >> >
> > >> > #define IB_UVERBS_BASE_DEV  MKDEV(IB_UVERBS_MAJOR, 
> > >> > IB_UVERBS_BASE_MINOR)
> > >>
> > >> That's annoying...
> > >> I notice that infiniband is using register_chrdev_region() at
> > >> module_init() time, counting on device major 231 to be free.
> > >
> > > That device major is assigned to Infiniband, why shouldn't it be doing
> > > this?
> > 
> > I mean it's annoying that they collide. (Because of the details I
> > write below, it's fine it's using the assigned number.
> > 
> > > Why not just ask for a new reserved one?  We could give you 261 and
> > > everything should be fine, right?
> > 
> > Sure I can post a patch for that, but it just mitigates the problem.
> > 
> > The report point to the serious problem that on this system
> > some dynamic allocations have already stolen major device
> > numbers 232 thru 255, and 232 and 233 are also assigned.
> > 
> > What do you think about a patch that makes fs/char_dev.c
> > emit a warning when it starts assigning dynamic numbers
> > 233 and below?
> 
> That's fine with me.  I also think maybe we should look into just
> switching all char major/minor allocation to be dynamic, starting at the
> bottom and moving up.  I think the only tools that might have an issue
> with that is the raw device controller, but maybe that has been fixed up
> in userspace, I haven't looked at that in many years.
>

Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
If we increase the size to say 511 will it break userspace?

In the future I see a robot building a kernel with more that 255 devices and
having to deal with this kind of collision again.

The handling of large major assignment baffles me.
The major numbers outside of the size of the table are just wrapping around to
the beginning again. This is inherently going to cause collisions.

static inline int major_to_index(unsigned major)
{
return major % CHRDEV_MAJOR_HASH_SIZE;
}

> I thought I had an old patch around somewhere that did that, will go
> look for it this week and see what breaks with it enabled...
> 
> thanks,
> 
> greg k-h

Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Michael Welling]

On Sun, Feb 14, 2016 at 02:59:06PM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git chardev
> commit 3c702e9987e261042a07e43460a8148be254412e ("gpio: add a userspace 
> chardev ABI for GPIOs")
> 
> 
> [1.951191] user_verbs: couldn't register device number

Looks like user_verbs is using a static device node setup.

enum {
IB_UVERBS_MAJOR   = 231,
IB_UVERBS_BASE_MINOR  = 192,
IB_UVERBS_MAX_DEVICES = 32
};

#define IB_UVERBS_BASE_DEV  MKDEV(IB_UVERBS_MAJOR, IB_UVERBS_BASE_MINOR)

Something tells me that a new GPIO chardev is taking this spot.

It looks like the device is documented to be using the range:
https://www.kernel.org/doc/Documentation/devices.txt

Could you run cat /proc/devices?

> [1.952527] ucm: couldn't register device number
> 
> 
> Thanks,
> Ying Huang

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.5.0-rc1 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_PERF_EVENTS_INTEL_UNCORE=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi 
> -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 
> -fcall-saved-r10 -fcall-saved-r11"
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_PGTABLE_LEVELS=4
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> # CONFIG_USELIB is not set
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_DEBUG=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_HZ_PERIODIC=y
> # CONFIG_NO_HZ_IDLE is not set
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> # CONFIG_HIGH_RES_TIMERS is not set
> 
> #
> # CPU/Task time and stats accounting
> #
> # CONFIG_TICK_CPU_ACCOUNTING is not set
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> CONFIG_IRQ_TIME_ACCOUNTING=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> # CONFIG_TASKSTATS is not set
> 
> #
> # RCU Subsystem
> #
> CONFIG_TREE_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> # CONFIG_IKCONFIG_PROC is not set
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
> CONFIG_ARCH_SUPPORTS_INT128=y
> # 

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > Hi Sricharan,
> > 
> > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > right?
> >
>  Yes.
>  
> > I'm asking this because this driver doesn't seem to support runtime pm and
> > there is no check for regmap_write/regmap_write return code in the probe
> > function.
>Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> right ?
>I was tracking that when there are i2c_xfers from pwm. I did not see any 
> failures there.
>So wanted to know the correct sequence to reproduce.
>

The problem was discovered using the patch that this thread is on. The PWM 
driver does
not have the problem.

When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

> Regards,
>   Sricharan
>   
> 
> 

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > Hi Sricharan,
> > 
> > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > right?
> >
>  Yes.
>  
> > I'm asking this because this driver doesn't seem to support runtime pm and
> > there is no check for regmap_write/regmap_write return code in the probe
> > function.
>Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> right ?
>I was tracking that when there are i2c_xfers from pwm. I did not see any 
> failures there.
>So wanted to know the correct sequence to reproduce.
>

The problem was discovered using the patch that this thread is on. The PWM 
driver does
not have the problem.

When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

> Regards,
>   Sricharan
>   
> 
> 

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 08, 2016 at 09:00:27PM +0100, Wolfram Sang wrote:
> > > > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > > > >> + struct iio_chan_spec const *chan, int
> 
> Guys, please quote only relevant sections.
>

Sorry. 

> >  pca: pca@40 {
> >  compatible = "nxp,pca9685-pwm";
> >  #pwm-cells = <2>;
> >  reg = <0x40>;
> >  };
> 
> Does accessing the pca work?
> 

Yes.

https://plus.google.com/+MichaelWelling79/posts/PdmGysBfZp4

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Tue, Feb 09, 2016 at 12:41:35AM +0530, Sricharan wrote:
> Hi,
> 
> > -Original Message-
> > From: Michael Welling [mailto:mwellin...@gmail.com] On Behalf Of Michael
> > Welling
> > Sent: Monday, February 08, 2016 10:07 PM
> > To: Wolfram Sang
> > Cc: Daniel Baluta; Jonathan Cameron; Hartmut Knaack; Lars-Peter Clausen;
> > Peter Meerwald-Stadler; Linux Kernel Mailing List;
> linux-...@vger.kernel.org;
> > Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> > Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> > Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> > 
> > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > >> + struct iio_chan_spec const *chan, int
> *val,
> > > > > >> + int *val2, long mask) {
> > > > > >> + int ret, idx;
> > > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > > > >> +
> > > > > >> + mutex_lock(>lock);
> > > > > >> + switch (mask) {
> > > > > >> + case IIO_CHAN_INFO_RAW:
> > > > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > > > >> + ret = -EBUSY;
> > > > > >> + break;
> > > > > >> + }
> > > > > >> +
> > > > > >> + ret = ads1015_set_power_state(data, true);
> > > > > >> + if (ret < 0)
> > > > > >> + break;
> > > > > >
> > > > > > Just tested the driver on a Dragonboard 410C with a robotics
> > > > > > mezzanine that I designed.
> > > > > >
> > > > > > The above ads1015_set_power_state(data, true) is always returning
> -
> > EINVAL.
> > > > > >
> > > > > > Any ideas why that would be happening?
> > > > > > I think it may be the return from pm_runtime_get_sync?
> > > > >
> > > > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > > >
> > > > > Also adding printks in suspend/resume function would be helpful.
> > > > > Do you have CONFIG_PM enabled?
> > > > >
> > > >
> > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > > >
> > > > > >
> > > > > > When I comment out the break the readings come back but are not
> > updated continually.
> > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value
> is
> > updated.
> > > > >
> > > > > I guess this is normal if set_power_state fails.
> > > >
> > > > The hwmod driver works fine BTW.
> > > >
> > > > My guess is there is an issue with the qup i2c driver seeing as it
> > > > has worked on other system without issue.
> > > >
> > > > CC'd some the latest developer on the qup i2c driver.
> > > >
> > > > I2C guys have any ideas on this?
> > > >
> > >
> > > Adding some more people who recently worked on this. Might be nice to
> > > know which kernel version you are using.
> > >
>  Which i2c bus is this connected to ? I can give a try with 410c to see why
> pm_runtime_get_sync from qup
>  fails.

It is on the lowspeed header. Here is my devicetree entry:

 i2c@78b6000 {
 /* On Low speed expansion */
 label = "LS-I2C0";
 status = "okay";
 
 pca: pca@40 {
 compatible = "nxp,pca9685-pwm";
 #pwm-cells = <2>;
 reg = <0x40>;
 };
 
 adc: adc@48 {
 compatible = "ti,ads1015";
 reg = <0x48>;
 };
 };

> 
> Regards,
>   Sricharan
> 
> 
> 

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 08, 2016 at 04:44:02PM +0200, Daniel Baluta wrote:
> On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang  wrote:
> > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> >> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> >> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> >> > >> + struct iio_chan_spec const *chan, int *val,
> >> > >> + int *val2, long mask)
> >> > >> +{
> >> > >> + int ret, idx;
> >> > >> + struct ads1015_data *data = iio_priv(indio_dev);
> >> > >> +
> >> > >> + mutex_lock(>lock);
> >> > >> + switch (mask) {
> >> > >> + case IIO_CHAN_INFO_RAW:
> >> > >> + if (iio_buffer_enabled(indio_dev)) {
> >> > >> + ret = -EBUSY;
> >> > >> + break;
> >> > >> + }
> >> > >> +
> >> > >> + ret = ads1015_set_power_state(data, true);
> >> > >> + if (ret < 0)
> >> > >> + break;
> >> > >
> >> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> >> > > that I
> >> > > designed.
> >> > >
> >> > > The above ads1015_set_power_state(data, true) is always returning 
> >> > > -EINVAL.
> >> > >
> >> > > Any ideas why that would be happening?
> >> > > I think it may be the return from pm_runtime_get_sync?
> >> >
> >> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> >> >
> >> > Also adding printks in suspend/resume function would be helpful. Do
> >> > you have CONFIG_PM enabled?
> >> >
> >>
> >> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> 
> Can you check the output of:
> $ cat /sys/bus/iio/devices/iio:device0/power/runtime_status
> 
> * after insmod

root@dragonboard-410c:~# cat 
/sys/bus/iio/devices/iio:device0/power/runtime_status
unsupported

> * after a reading from sysfs

root@dragonboard-410c:~# cat 
/sys/bus/iio/devices/iio:device0/power/runtime_status
unsupported

> 
> >>
> >> > >
> >> > > When I comment out the break the readings come back but are not 
> >> > > updated continually.
> >> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> >> > > updated.
> >> >
> >> > I guess this is normal if set_power_state fails.
> >>
> >> The hwmod driver works fine BTW.
> >>
> >> My guess is there is an issue with the qup i2c driver seeing as it has 
> >> worked on
> >> other system without issue.
> >>
> >> CC'd some the latest developer on the qup i2c driver.
> >>
> >> I2C guys have any ideas on this?
> >>
> >
> > Adding some more people who recently worked on this. Might be nice to
> > know which kernel version you are using.

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > >> + struct iio_chan_spec const *chan, int *val,
> > > >> + int *val2, long mask)
> > > >> +{
> > > >> + int ret, idx;
> > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > >> +
> > > >> + mutex_lock(>lock);
> > > >> + switch (mask) {
> > > >> + case IIO_CHAN_INFO_RAW:
> > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > >> + ret = -EBUSY;
> > > >> + break;
> > > >> + }
> > > >> +
> > > >> + ret = ads1015_set_power_state(data, true);
> > > >> + if (ret < 0)
> > > >> + break;
> > > >
> > > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> > > > that I
> > > > designed.
> > > >
> > > > The above ads1015_set_power_state(data, true) is always returning 
> > > > -EINVAL.
> > > >
> > > > Any ideas why that would be happening?
> > > > I think it may be the return from pm_runtime_get_sync?
> > > 
> > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > 
> > > Also adding printks in suspend/resume function would be helpful. Do
> > > you have CONFIG_PM enabled?
> > >
> > 
> > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > 
> > > >
> > > > When I comment out the break the readings come back but are not updated 
> > > > continually.
> > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > > > updated.
> > > 
> > > I guess this is normal if set_power_state fails.
> > 
> > The hwmod driver works fine BTW.
> > 
> > My guess is there is an issue with the qup i2c driver seeing as it has 
> > worked on
> > other system without issue.
> > 
> > CC'd some the latest developer on the qup i2c driver.
> > 
> > I2C guys have any ideas on this?
> > 
> 
> Adding some more people who recently worked on this. Might be nice to
> know which kernel version you are using.
>

4.5.0-rc2
 
> > > 
> > > thanks,
> > > Daniel.

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > >> + struct iio_chan_spec const *chan, int *val,
> > > >> + int *val2, long mask)
> > > >> +{
> > > >> + int ret, idx;
> > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > >> +
> > > >> + mutex_lock(>lock);
> > > >> + switch (mask) {
> > > >> + case IIO_CHAN_INFO_RAW:
> > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > >> + ret = -EBUSY;
> > > >> + break;
> > > >> + }
> > > >> +
> > > >> + ret = ads1015_set_power_state(data, true);
> > > >> + if (ret < 0)
> > > >> + break;
> > > >
> > > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> > > > that I
> > > > designed.
> > > >
> > > > The above ads1015_set_power_state(data, true) is always returning 
> > > > -EINVAL.
> > > >
> > > > Any ideas why that would be happening?
> > > > I think it may be the return from pm_runtime_get_sync?
> > > 
> > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > 
> > > Also adding printks in suspend/resume function would be helpful. Do
> > > you have CONFIG_PM enabled?
> > >
> > 
> > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > 
> > > >
> > > > When I comment out the break the readings come back but are not updated 
> > > > continually.
> > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > > > updated.
> > > 
> > > I guess this is normal if set_power_state fails.
> > 
> > The hwmod driver works fine BTW.
> > 
> > My guess is there is an issue with the qup i2c driver seeing as it has 
> > worked on
> > other system without issue.
> > 
> > CC'd some the latest developer on the qup i2c driver.
> > 
> > I2C guys have any ideas on this?
> > 
> 
> Adding some more people who recently worked on this. Might be nice to
> know which kernel version you are using.
>

4.5.0-rc2
 
> > > 
> > > thanks,
> > > Daniel.

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 08, 2016 at 04:44:02PM +0200, Daniel Baluta wrote:
> On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang <w...@the-dreams.de> wrote:
> > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> >> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> >> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> >> > >> + struct iio_chan_spec const *chan, int *val,
> >> > >> + int *val2, long mask)
> >> > >> +{
> >> > >> + int ret, idx;
> >> > >> + struct ads1015_data *data = iio_priv(indio_dev);
> >> > >> +
> >> > >> + mutex_lock(>lock);
> >> > >> + switch (mask) {
> >> > >> + case IIO_CHAN_INFO_RAW:
> >> > >> + if (iio_buffer_enabled(indio_dev)) {
> >> > >> + ret = -EBUSY;
> >> > >> + break;
> >> > >> + }
> >> > >> +
> >> > >> + ret = ads1015_set_power_state(data, true);
> >> > >> + if (ret < 0)
> >> > >> + break;
> >> > >
> >> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> >> > > that I
> >> > > designed.
> >> > >
> >> > > The above ads1015_set_power_state(data, true) is always returning 
> >> > > -EINVAL.
> >> > >
> >> > > Any ideas why that would be happening?
> >> > > I think it may be the return from pm_runtime_get_sync?
> >> >
> >> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> >> >
> >> > Also adding printks in suspend/resume function would be helpful. Do
> >> > you have CONFIG_PM enabled?
> >> >
> >>
> >> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> 
> Can you check the output of:
> $ cat /sys/bus/iio/devices/iio:device0/power/runtime_status
> 
> * after insmod

root@dragonboard-410c:~# cat 
/sys/bus/iio/devices/iio:device0/power/runtime_status
unsupported

> * after a reading from sysfs

root@dragonboard-410c:~# cat 
/sys/bus/iio/devices/iio:device0/power/runtime_status
unsupported

> 
> >>
> >> > >
> >> > > When I comment out the break the readings come back but are not 
> >> > > updated continually.
> >> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> >> > > updated.
> >> >
> >> > I guess this is normal if set_power_state fails.
> >>
> >> The hwmod driver works fine BTW.
> >>
> >> My guess is there is an issue with the qup i2c driver seeing as it has 
> >> worked on
> >> other system without issue.
> >>
> >> CC'd some the latest developer on the qup i2c driver.
> >>
> >> I2C guys have any ideas on this?
> >>
> >
> > Adding some more people who recently worked on this. Might be nice to
> > know which kernel version you are using.

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Tue, Feb 09, 2016 at 12:41:35AM +0530, Sricharan wrote:
> Hi,
> 
> > -Original Message-
> > From: Michael Welling [mailto:mwellin...@gmail.com] On Behalf Of Michael
> > Welling
> > Sent: Monday, February 08, 2016 10:07 PM
> > To: Wolfram Sang
> > Cc: Daniel Baluta; Jonathan Cameron; Hartmut Knaack; Lars-Peter Clausen;
> > Peter Meerwald-Stadler; Linux Kernel Mailing List;
> linux-...@vger.kernel.org;
> > Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> > Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> > Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> > 
> > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > >> + struct iio_chan_spec const *chan, int
> *val,
> > > > > >> + int *val2, long mask) {
> > > > > >> + int ret, idx;
> > > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > > > >> +
> > > > > >> + mutex_lock(>lock);
> > > > > >> + switch (mask) {
> > > > > >> + case IIO_CHAN_INFO_RAW:
> > > > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > > > >> + ret = -EBUSY;
> > > > > >> + break;
> > > > > >> + }
> > > > > >> +
> > > > > >> + ret = ads1015_set_power_state(data, true);
> > > > > >> + if (ret < 0)
> > > > > >> + break;
> > > > > >
> > > > > > Just tested the driver on a Dragonboard 410C with a robotics
> > > > > > mezzanine that I designed.
> > > > > >
> > > > > > The above ads1015_set_power_state(data, true) is always returning
> -
> > EINVAL.
> > > > > >
> > > > > > Any ideas why that would be happening?
> > > > > > I think it may be the return from pm_runtime_get_sync?
> > > > >
> > > > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > > >
> > > > > Also adding printks in suspend/resume function would be helpful.
> > > > > Do you have CONFIG_PM enabled?
> > > > >
> > > >
> > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > > >
> > > > > >
> > > > > > When I comment out the break the readings come back but are not
> > updated continually.
> > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value
> is
> > updated.
> > > > >
> > > > > I guess this is normal if set_power_state fails.
> > > >
> > > > The hwmod driver works fine BTW.
> > > >
> > > > My guess is there is an issue with the qup i2c driver seeing as it
> > > > has worked on other system without issue.
> > > >
> > > > CC'd some the latest developer on the qup i2c driver.
> > > >
> > > > I2C guys have any ideas on this?
> > > >
> > >
> > > Adding some more people who recently worked on this. Might be nice to
> > > know which kernel version you are using.
> > >
>  Which i2c bus is this connected to ? I can give a try with 410c to see why
> pm_runtime_get_sync from qup
>  fails.

It is on the lowspeed header. Here is my devicetree entry:

 i2c@78b6000 {
 /* On Low speed expansion */
 label = "LS-I2C0";
 status = "okay";
 
 pca: pca@40 {
 compatible = "nxp,pca9685-pwm";
 #pwm-cells = <2>;
 reg = <0x40>;
 };
 
 adc: adc@48 {
 compatible = "ti,ads1015";
 reg = <0x48>;
 };
 };

> 
> Regards,
>   Sricharan
> 
> 
> 

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Mon, Feb 08, 2016 at 09:00:27PM +0100, Wolfram Sang wrote:
> > > > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > > > >> + struct iio_chan_spec const *chan, int
> 
> Guys, please quote only relevant sections.
>

Sorry. 

> >  pca: pca@40 {
> >  compatible = "nxp,pca9685-pwm";
> >  #pwm-cells = <2>;
> >  reg = <0x40>;
> >  };
> 
> Does accessing the pca work?
> 

Yes.

https://plus.google.com/+MichaelWelling79/posts/PdmGysBfZp4

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> >> + struct iio_chan_spec const *chan, int *val,
> >> + int *val2, long mask)
> >> +{
> >> + int ret, idx;
> >> + struct ads1015_data *data = iio_priv(indio_dev);
> >> +
> >> + mutex_lock(>lock);
> >> + switch (mask) {
> >> + case IIO_CHAN_INFO_RAW:
> >> + if (iio_buffer_enabled(indio_dev)) {
> >> + ret = -EBUSY;
> >> + break;
> >> + }
> >> +
> >> + ret = ads1015_set_power_state(data, true);
> >> + if (ret < 0)
> >> + break;
> >
> > Just tested the driver on a Dragonboard 410C with a robotics mezzanine that 
> > I
> > designed.
> >
> > The above ads1015_set_power_state(data, true) is always returning -EINVAL.
> >
> > Any ideas why that would be happening?
> > I think it may be the return from pm_runtime_get_sync?
> 
> Can you confirm that pm_runtime_get_sync fails? Using some printk?
> 
> Also adding printks in suspend/resume function would be helpful. Do
> you have CONFIG_PM enabled?
>

Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.

> >
> > When I comment out the break the readings come back but are not updated 
> > continually.
> > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > updated.
> 
> I guess this is normal if set_power_state fails.

The hwmod driver works fine BTW.

My guess is there is an issue with the qup i2c driver seeing as it has worked on
other system without issue.

CC'd some the latest developer on the qup i2c driver.

I2C guys have any ideas on this?

> 
> thanks,
> Daniel.

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> On Fri, Feb 5, 2016 at 7:25 PM, Michael Welling  wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >> Datasheet can be found here:
> >>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> >>
> >> Signed-off-by: Daniel Baluta 
> >> ---
> >> Changes since v3:
> >>   * fixed type connectd -> connected
> >>   * move mutex outside of switch in read_raw to be consistent
> >>   with write_raw
> >>
> >> Changes since v2:
> >>   * push locking out of the switch in write_raw
> >>   * fix  buf allocation in triggered buffer's handler
> >>
> >> Changes since v1:
> >>   * addressed concerns about replacing the ads1015 hwmon driver
> >>   * For the moment the IIO driver is compatible with hwmon
> >> driver (dt bindings) the only thing left is to also add
> >> support for ads1115.
> >>   * DT bindings are described in Documentation/devicetree/
> >> bindings/hwmon/ads1015.txt. If needed will copy this file
> >> in a later patch to the IIO corresponding location.
> >>   * addressed comments from Jonathan
> >>   * added proper locking
> >>   * added timestamp channel
> >>   * removed magic constants
> >>   * added some new lines to increase readability
> >>   * used regmap_get_device instead of keeping a copy of
> >>   i2c_client pointer.
> >>   * used non-devm function to correct the cleanup order
> >>
> >>  drivers/iio/adc/Kconfig  |  13 +
> >>  drivers/iio/adc/Makefile |   1 +
> >>  drivers/iio/adc/ti-ads1015.c | 610 
> >> +++
> >>  3 files changed, 624 insertions(+)
> >>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> >>
> >> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> >> index 60673b4..fad7e6a 100644
> >> --- a/drivers/iio/adc/Kconfig
> >> +++ b/drivers/iio/adc/Kconfig
> >> @@ -370,6 +370,19 @@ config TI_ADC128S052
> >> This driver can also be built as a module. If so, the module will 
> >> be
> >> called ti-adc128s052.
> >>
> >> +config TI_ADS1015
> >> + tristate "Texas Instruments ADS1015 ADC"
> >> + depends on I2C && !SENSORS_ADS1015
> >> + select REGMAP_I2C
> >> + select IIO_BUFFER
> >> + select IIO_TRIGGERED_BUFFER
> >> + help
> >> +   If you say yes here you get support for Texas Instruments ADS1015
> >> +   ADC chip.
> >> +
> >> +   This driver can also be built as a module. If so, the module will 
> >> be
> >> +   called ti-ads1015.
> >> +
> >>  config TI_ADS8688
> >>   tristate "Texas Instruments ADS8688"
> >>   depends on SPI && OF
> >> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> >> index fb57e12..2ff70a3 100644
> >> --- a/drivers/iio/adc/Makefile
> >> +++ b/drivers/iio/adc/Makefile
> >> @@ -36,6 +36,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_ADS1015) += ti-ads1015.o
> >>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
> >>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> >>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> >> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> >> new file mode 100644
> >> index 000..596335f
> >> --- /dev/null
> >> +++ b/drivers/iio/adc/ti-ads1015.c
> >> @@ -0,0 +1,610 @@
> >> +/*
> >> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> >> + *
> >> + * Copyright (c) 2016, Intel Corporation.
> >> + *
> >> + * This file is subject to the terms and conditions of version 2 of
> >> + * the GNU General Public License.  See the file COPYING in the main
> &g

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> The driver has sysfs readings with runtime PM support for power saving.
> It also offers buffer support that can be used together with IIO software
> triggers.
> 
> Datasheet can be found here:
>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> 
> Signed-off-by: Daniel Baluta 
> ---
> Changes since v3:
>   * fixed type connectd -> connected
>   * move mutex outside of switch in read_raw to be consistent
>   with write_raw
> 
> Changes since v2:
>   * push locking out of the switch in write_raw
>   * fix  buf allocation in triggered buffer's handler
> 
> Changes since v1:
>   * addressed concerns about replacing the ads1015 hwmon driver
>   * For the moment the IIO driver is compatible with hwmon
> driver (dt bindings) the only thing left is to also add
> support for ads1115.
>   * DT bindings are described in Documentation/devicetree/
> bindings/hwmon/ads1015.txt. If needed will copy this file
> in a later patch to the IIO corresponding location.
>   * addressed comments from Jonathan
>   * added proper locking
>   * added timestamp channel
>   * removed magic constants
>   * added some new lines to increase readability
>   * used regmap_get_device instead of keeping a copy of
>   i2c_client pointer.
>   * used non-devm function to correct the cleanup order
> 
>  drivers/iio/adc/Kconfig  |  13 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads1015.c | 610 
> +++
>  3 files changed, 624 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60673b4..fad7e6a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -370,6 +370,19 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS1015
> + tristate "Texas Instruments ADS1015 ADC"
> + depends on I2C && !SENSORS_ADS1015
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   If you say yes here you get support for Texas Instruments ADS1015
> +   ADC chip.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads1015.
> +
>  config TI_ADS8688
>   tristate "Texas Instruments ADS8688"
>   depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fb57e12..2ff70a3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -36,6 +36,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_ADS1015) += ti-ads1015.o
>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> new file mode 100644
> index 000..596335f
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -0,0 +1,610 @@
> +/*
> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> + *   * 0x48 - ADDR connected to Ground
> + *   * 0x49 - ADDR connected to Vdd
> + *   * 0x4A - ADDR connected to SDA
> + *   * 0x4B - ADDR connected to SCL
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADS1015_DRV_NAME "ads1015"
> +
> +#define ADS1015_CONV_REG 0x00
> +#define ADS1015_CFG_REG  0x01
> +
> +#define ADS1015_CFG_DR_SHIFT 5
> +#define ADS1015_CFG_MOD_SHIFT8
> +#define ADS1015_CFG_PGA_SHIFT9
> +#define ADS1015_CFG_MUX_SHIFT12
> +
> +#define ADS1015_CFG_DR_MASK  GENMASK(7, 5)
> +#define ADS1015_CFG_MOD_MASK BIT(8)
> +#define ADS1015_CFG_PGA_MASK GENMASK(11, 9)
> +#define ADS1015_CFG_MUX_MASK GENMASK(14, 12)
> +
> +/* device operating modes */
> +#define ADS1015_CONTINUOUS   0
> +#define ADS1015_SINGLESHOT   1
> +
> +#define ADS1015_SLEEP_DELAY_MS   2000
> +#define ADS1015_DEFAULT_PGA  2
> +#define ADS1015_DEFAULT_DATA_RATE4
> +#define ADS1015_DEFAULT_CHAN 0
> +
> +enum ads1015_channels {
> + ADS1015_AIN0_AIN1 = 0,
> + 

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> The driver has sysfs readings with runtime PM support for power saving.
> It also offers buffer support that can be used together with IIO software
> triggers.
> 
> Datasheet can be found here:
>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> 
> Signed-off-by: Daniel Baluta 
> ---
> Changes since v3:
>   * fixed type connectd -> connected
>   * move mutex outside of switch in read_raw to be consistent
>   with write_raw
> 
> Changes since v2:
>   * push locking out of the switch in write_raw
>   * fix  buf allocation in triggered buffer's handler
> 
> Changes since v1:
>   * addressed concerns about replacing the ads1015 hwmon driver
>   * For the moment the IIO driver is compatible with hwmon
> driver (dt bindings) the only thing left is to also add
> support for ads1115.
>   * DT bindings are described in Documentation/devicetree/
> bindings/hwmon/ads1015.txt. If needed will copy this file
> in a later patch to the IIO corresponding location.
>   * addressed comments from Jonathan
>   * added proper locking
>   * added timestamp channel
>   * removed magic constants
>   * added some new lines to increase readability
>   * used regmap_get_device instead of keeping a copy of
>   i2c_client pointer.
>   * used non-devm function to correct the cleanup order
> 
>  drivers/iio/adc/Kconfig  |  13 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads1015.c | 610 
> +++
>  3 files changed, 624 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60673b4..fad7e6a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -370,6 +370,19 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS1015
> + tristate "Texas Instruments ADS1015 ADC"
> + depends on I2C && !SENSORS_ADS1015
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   If you say yes here you get support for Texas Instruments ADS1015
> +   ADC chip.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads1015.
> +
>  config TI_ADS8688
>   tristate "Texas Instruments ADS8688"
>   depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fb57e12..2ff70a3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -36,6 +36,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_ADS1015) += ti-ads1015.o
>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> new file mode 100644
> index 000..596335f
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -0,0 +1,610 @@
> +/*
> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> + *   * 0x48 - ADDR connected to Ground
> + *   * 0x49 - ADDR connected to Vdd
> + *   * 0x4A - ADDR connected to SDA
> + *   * 0x4B - ADDR connected to SCL
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADS1015_DRV_NAME "ads1015"
> +
> +#define ADS1015_CONV_REG 0x00
> +#define ADS1015_CFG_REG  0x01
> +
> +#define ADS1015_CFG_DR_SHIFT 5
> +#define ADS1015_CFG_MOD_SHIFT8
> +#define ADS1015_CFG_PGA_SHIFT9
> +#define ADS1015_CFG_MUX_SHIFT12
> +
> +#define ADS1015_CFG_DR_MASK  GENMASK(7, 5)
> +#define ADS1015_CFG_MOD_MASK BIT(8)
> +#define ADS1015_CFG_PGA_MASK GENMASK(11, 9)
> +#define ADS1015_CFG_MUX_MASK GENMASK(14, 12)
> +
> +/* device operating modes */
> +#define ADS1015_CONTINUOUS   0
> +#define ADS1015_SINGLESHOT   1
> +
> +#define ADS1015_SLEEP_DELAY_MS   2000
> +#define ADS1015_DEFAULT_PGA  2
> +#define ADS1015_DEFAULT_DATA_RATE4
> +#define ADS1015_DEFAULT_CHAN 0
> +
> +enum ads1015_channels {
> + 

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> On Fri, Feb 5, 2016 at 7:25 PM, Michael Welling <mwell...@ieee.org> wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >> Datasheet can be found here:
> >>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> >>
> >> Signed-off-by: Daniel Baluta <daniel.bal...@intel.com>
> >> ---
> >> Changes since v3:
> >>   * fixed type connectd -> connected
> >>   * move mutex outside of switch in read_raw to be consistent
> >>   with write_raw
> >>
> >> Changes since v2:
> >>   * push locking out of the switch in write_raw
> >>   * fix  buf allocation in triggered buffer's handler
> >>
> >> Changes since v1:
> >>   * addressed concerns about replacing the ads1015 hwmon driver
> >>   * For the moment the IIO driver is compatible with hwmon
> >> driver (dt bindings) the only thing left is to also add
> >> support for ads1115.
> >>   * DT bindings are described in Documentation/devicetree/
> >> bindings/hwmon/ads1015.txt. If needed will copy this file
> >> in a later patch to the IIO corresponding location.
> >>   * addressed comments from Jonathan
> >>   * added proper locking
> >>   * added timestamp channel
> >>   * removed magic constants
> >>   * added some new lines to increase readability
> >>   * used regmap_get_device instead of keeping a copy of
> >>   i2c_client pointer.
> >>   * used non-devm function to correct the cleanup order
> >>
> >>  drivers/iio/adc/Kconfig  |  13 +
> >>  drivers/iio/adc/Makefile |   1 +
> >>  drivers/iio/adc/ti-ads1015.c | 610 
> >> +++
> >>  3 files changed, 624 insertions(+)
> >>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> >>
> >> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> >> index 60673b4..fad7e6a 100644
> >> --- a/drivers/iio/adc/Kconfig
> >> +++ b/drivers/iio/adc/Kconfig
> >> @@ -370,6 +370,19 @@ config TI_ADC128S052
> >> This driver can also be built as a module. If so, the module will 
> >> be
> >> called ti-adc128s052.
> >>
> >> +config TI_ADS1015
> >> + tristate "Texas Instruments ADS1015 ADC"
> >> + depends on I2C && !SENSORS_ADS1015
> >> + select REGMAP_I2C
> >> + select IIO_BUFFER
> >> + select IIO_TRIGGERED_BUFFER
> >> + help
> >> +   If you say yes here you get support for Texas Instruments ADS1015
> >> +   ADC chip.
> >> +
> >> +   This driver can also be built as a module. If so, the module will 
> >> be
> >> +   called ti-ads1015.
> >> +
> >>  config TI_ADS8688
> >>   tristate "Texas Instruments ADS8688"
> >>   depends on SPI && OF
> >> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> >> index fb57e12..2ff70a3 100644
> >> --- a/drivers/iio/adc/Makefile
> >> +++ b/drivers/iio/adc/Makefile
> >> @@ -36,6 +36,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_ADS1015) += ti-ads1015.o
> >>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
> >>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> >>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> >> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> >> new file mode 100644
> >> index 000..596335f
> >> --- /dev/null
> >> +++ b/drivers/iio/adc/ti-ads1015.c
> >> @@ -0,0 +1,610 @@
> >> +/*
> >> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> >> + *
> >> + * Copyright (c) 2016, Intel Corporation.
> >> + *
> >> + * This file is subject to the terms and conditions of version 2 of
> >> + * the GNU General Public License

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> >> + struct iio_chan_spec const *chan, int *val,
> >> + int *val2, long mask)
> >> +{
> >> + int ret, idx;
> >> + struct ads1015_data *data = iio_priv(indio_dev);
> >> +
> >> + mutex_lock(>lock);
> >> + switch (mask) {
> >> + case IIO_CHAN_INFO_RAW:
> >> + if (iio_buffer_enabled(indio_dev)) {
> >> + ret = -EBUSY;
> >> + break;
> >> + }
> >> +
> >> + ret = ads1015_set_power_state(data, true);
> >> + if (ret < 0)
> >> + break;
> >
> > Just tested the driver on a Dragonboard 410C with a robotics mezzanine that 
> > I
> > designed.
> >
> > The above ads1015_set_power_state(data, true) is always returning -EINVAL.
> >
> > Any ideas why that would be happening?
> > I think it may be the return from pm_runtime_get_sync?
> 
> Can you confirm that pm_runtime_get_sync fails? Using some printk?
> 
> Also adding printks in suspend/resume function would be helpful. Do
> you have CONFIG_PM enabled?
>

Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.

> >
> > When I comment out the break the readings come back but are not updated 
> > continually.
> > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > updated.
> 
> I guess this is normal if set_power_state fails.

The hwmod driver works fine BTW.

My guess is there is an issue with the qup i2c driver seeing as it has worked on
other system without issue.

CC'd some the latest developer on the qup i2c driver.

I2C guys have any ideas on this?

> 
> thanks,
> Daniel.

Re: [PATCH v3] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Wed, Feb 03, 2016 at 06:59:56PM +0200, Daniel Baluta wrote:
> The driver has sysfs readings with runtime PM support for power saving.
> It also offers buffer support that can be used together with IIO software
> triggers.
> 
> Datasheet can be found here:
>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> 
> Signed-off-by: Daniel Baluta 
> ---
> Changes since v2:
>   * push locking out of the switch in write_raw
>   * fix  buf allocation in triggered buffer's handler
> 
> Changes since v1:
>   * addressed concerns about replacing the ads1015 hwmon driver
>   * For the moment the IIO driver is compatible with hwmon
> driver (dt bindings) the only thing left is to also add
> support for ads1115.
>   * DT bindings are described in Documentation/devicetree/
> bindings/hwmon/ads1015.txt. If needed will copy this file
> in a later patch to the IIO corresponding location.
>   * addressed comments from Jonathan
>   * added proper locking
>   * added timestamp channel
>   * removed magic constants
>   * added some new lines to increase readability
>   * used regmap_get_device instead of keeping a copy of
>   i2c_client pointer.
>   * used non-devm function to correct the cleanup order
> 
>  drivers/iio/adc/Kconfig  |  13 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads1015.c | 616 
> +++
>  3 files changed, 630 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60673b4..fad7e6a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -370,6 +370,19 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS1015
> + tristate "Texas Instruments ADS1015 ADC"
> + depends on I2C && !SENSORS_ADS1015
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   If you say yes here you get support for Texas Instruments ADS1015
> +   ADC chip.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads1015.
> +
>  config TI_ADS8688
>   tristate "Texas Instruments ADS8688"
>   depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fb57e12..2ff70a3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -36,6 +36,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_ADS1015) += ti-ads1015.o
>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> new file mode 100644
> index 000..abe78d3
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -0,0 +1,616 @@
> +/*
> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> + *   * 0x48 - ADDR connectd to Ground
> + *   * 0x49 - ADDR connected to Vdd
> + *   * 0x4A - ADDR connected to SDA
> + *   * 0x4B - ADDR connected to SCL
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADS1015_DRV_NAME "ads1015"
> +
> +#define ADS1015_CONV_REG 0x00
> +#define ADS1015_CFG_REG  0x01
> +
> +#define ADS1015_CFG_DR_SHIFT 5
> +#define ADS1015_CFG_MOD_SHIFT8
> +#define ADS1015_CFG_PGA_SHIFT9
> +#define ADS1015_CFG_MUX_SHIFT12
> +
> +#define ADS1015_CFG_DR_MASK  GENMASK(7, 5)
> +#define ADS1015_CFG_MOD_MASK BIT(8)
> +#define ADS1015_CFG_PGA_MASK GENMASK(11, 9)
> +#define ADS1015_CFG_MUX_MASK GENMASK(14, 12)
> +
> +/* device operating modes */
> +#define ADS1015_CONTINUOUS   0
> +#define ADS1015_SINGLESHOT   1
> +
> +#define ADS1015_SLEEP_DELAY_MS   2000
> +#define ADS1015_DEFAULT_PGA  2
> +#define ADS1015_DEFAULT_DATA_RATE4
> +#define ADS1015_DEFAULT_CHAN 0
> +
> +enum ads1015_channels {
> + ADS1015_AIN0_AIN1 = 0,
> + ADS1015_AIN0_AIN3,
> + ADS1015_AIN1_AIN3,
> + ADS1015_AIN2_AIN3,
> + ADS1015_AIN0,
> + ADS1015_AIN1,
> + ADS1015_AIN2,
> + ADS1015_AIN3,
> 

Re: [PATCH v3] iio: adc: Add TI ADS1015 ADC driver support

[Michael Welling]

On Wed, Feb 03, 2016 at 06:59:56PM +0200, Daniel Baluta wrote:
> The driver has sysfs readings with runtime PM support for power saving.
> It also offers buffer support that can be used together with IIO software
> triggers.
> 
> Datasheet can be found here:
>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> 
> Signed-off-by: Daniel Baluta 
> ---
> Changes since v2:
>   * push locking out of the switch in write_raw
>   * fix  buf allocation in triggered buffer's handler
> 
> Changes since v1:
>   * addressed concerns about replacing the ads1015 hwmon driver
>   * For the moment the IIO driver is compatible with hwmon
> driver (dt bindings) the only thing left is to also add
> support for ads1115.
>   * DT bindings are described in Documentation/devicetree/
> bindings/hwmon/ads1015.txt. If needed will copy this file
> in a later patch to the IIO corresponding location.
>   * addressed comments from Jonathan
>   * added proper locking
>   * added timestamp channel
>   * removed magic constants
>   * added some new lines to increase readability
>   * used regmap_get_device instead of keeping a copy of
>   i2c_client pointer.
>   * used non-devm function to correct the cleanup order
> 
>  drivers/iio/adc/Kconfig  |  13 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads1015.c | 616 
> +++
>  3 files changed, 630 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60673b4..fad7e6a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -370,6 +370,19 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS1015
> + tristate "Texas Instruments ADS1015 ADC"
> + depends on I2C && !SENSORS_ADS1015
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   If you say yes here you get support for Texas Instruments ADS1015
> +   ADC chip.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads1015.
> +
>  config TI_ADS8688
>   tristate "Texas Instruments ADS8688"
>   depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fb57e12..2ff70a3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -36,6 +36,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_ADS1015) += ti-ads1015.o
>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> new file mode 100644
> index 000..abe78d3
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -0,0 +1,616 @@
> +/*
> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> + *   * 0x48 - ADDR connectd to Ground
> + *   * 0x49 - ADDR connected to Vdd
> + *   * 0x4A - ADDR connected to SDA
> + *   * 0x4B - ADDR connected to SCL
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADS1015_DRV_NAME "ads1015"
> +
> +#define ADS1015_CONV_REG 0x00
> +#define ADS1015_CFG_REG  0x01
> +
> +#define ADS1015_CFG_DR_SHIFT 5
> +#define ADS1015_CFG_MOD_SHIFT8
> +#define ADS1015_CFG_PGA_SHIFT9
> +#define ADS1015_CFG_MUX_SHIFT12
> +
> +#define ADS1015_CFG_DR_MASK  GENMASK(7, 5)
> +#define ADS1015_CFG_MOD_MASK BIT(8)
> +#define ADS1015_CFG_PGA_MASK GENMASK(11, 9)
> +#define ADS1015_CFG_MUX_MASK GENMASK(14, 12)
> +
> +/* device operating modes */
> +#define ADS1015_CONTINUOUS   0
> +#define ADS1015_SINGLESHOT   1
> +
> +#define ADS1015_SLEEP_DELAY_MS   2000
> +#define ADS1015_DEFAULT_PGA  2
> +#define ADS1015_DEFAULT_DATA_RATE4
> +#define ADS1015_DEFAULT_CHAN 0
> +
> +enum ads1015_channels {
> + ADS1015_AIN0_AIN1 = 0,
> + ADS1015_AIN0_AIN3,
> + ADS1015_AIN1_AIN3,
> + ADS1015_AIN2_AIN3,
> + ADS1015_AIN0,
> + ADS1015_AIN1,
> + 

[PATCH] spi: omap2-mcspi: Prevent duplicate gpio_request

[Michael Welling]

Occasionally the setup function will be called multiple times. Only request
the gpio the first time otherwise -EBUSY will occur on subsequent calls to
setup.

Reported-by: Joseph Bell 

Signed-off-by: Michael Welling 
---
 drivers/spi/spi-omap2-mcspi.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 02aa1d0..7273820 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1025,6 +1025,16 @@ static int omap2_mcspi_setup(struct spi_device *spi)
spi->controller_state = cs;
/* Link this to context save list */
list_add_tail(>node, >cs);
+
+   if (gpio_is_valid(spi->cs_gpio)) {
+   ret = gpio_request(spi->cs_gpio, dev_name(>dev));
+   if (ret) {
+   dev_err(>dev, "failed to request gpio\n");
+   return ret;
+   }
+   gpio_direction_output(spi->cs_gpio,
+!(spi->mode & SPI_CS_HIGH));
+   }
}
 
if (!mcspi_dma->dma_rx || !mcspi_dma->dma_tx) {
@@ -1033,15 +1043,6 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return ret;
}
 
-   if (gpio_is_valid(spi->cs_gpio)) {
-   ret = gpio_request(spi->cs_gpio, dev_name(>dev));
-   if (ret) {
-   dev_err(>dev, "failed to request gpio\n");
-   return ret;
-   }
-   gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
-   }
-
ret = pm_runtime_get_sync(mcspi->dev);
if (ret < 0)
return ret;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] spi: omap2-mcspi: Prevent duplicate gpio_request

[Michael Welling]

Occasionally the setup function will be called multiple times. Only request
the gpio the first time otherwise -EBUSY will occur on subsequent calls to
setup.

Reported-by: Joseph Bell <j...@iachieved.it>

Signed-off-by: Michael Welling <mwell...@ieee.org>
---
 drivers/spi/spi-omap2-mcspi.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 02aa1d0..7273820 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1025,6 +1025,16 @@ static int omap2_mcspi_setup(struct spi_device *spi)
spi->controller_state = cs;
/* Link this to context save list */
list_add_tail(>node, >cs);
+
+   if (gpio_is_valid(spi->cs_gpio)) {
+   ret = gpio_request(spi->cs_gpio, dev_name(>dev));
+   if (ret) {
+   dev_err(>dev, "failed to request gpio\n");
+   return ret;
+   }
+   gpio_direction_output(spi->cs_gpio,
+!(spi->mode & SPI_CS_HIGH));
+   }
}
 
if (!mcspi_dma->dma_rx || !mcspi_dma->dma_tx) {
@@ -1033,15 +1043,6 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return ret;
}
 
-   if (gpio_is_valid(spi->cs_gpio)) {
-   ret = gpio_request(spi->cs_gpio, dev_name(>dev));
-   if (ret) {
-   dev_err(>dev, "failed to request gpio\n");
-   return ret;
-   }
-   gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
-   }
-
ret = pm_runtime_get_sync(mcspi->dev);
if (ret < 0)
return ret;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Tue, Nov 03, 2015 at 02:59:13PM -0800, Dmitry Torokhov wrote:
> On Tue, Nov 03, 2015 at 09:41:17AM -0600, Michael Welling wrote:
> > On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> > > On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
> > >  wrote:
> > > > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> > > >> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > > >> > > +Required properties:
> > > >> > > + - compatible: "ti,tsc2004"
> > > >> > > + - interrupts: IRQ specifier
> > > >> > > + - vio-supply : Regulator specifier
> > > >> >
> > > >> > reg property?
> > > >>
> > > >> Rob,
> > > >>
> > > >> It appears that I missed this in the description.
> > > >>
> > > >> Probably because I was following the lead of the ts2005 description.
> > > >>
> > > >> How does this look:
> > > >> - reg : I2C address. 0x48 - 0x4b based on the voltage 
> > > >> applied to
> > > >> the AD1 and AD0 inputs on the IC.
> > > >>
> > > >
> > > > How about the version below?
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > Dmitry
> > > >
> > > >
> > > > Input: tsc2004 - document ts2004 dt bindings
> > 
> > Just noticed that it says ts2004 instead of tsc2004 in the subject.
> > Otherwise, I am fine with it.
> > 
> > Thanks for the assistance.
> > 
> > Still no acks or reviews for the other patches in the series.
> > I would like for someone to test the tsc2005 support to see if it still 
> > works.
> > 
> > The tsc2004 works very well on the target that I have here.
> 
> I folded this patch into the patch #3 and applied everything.
>

Great.

Will this patch series conflict with the patch series to take out the 
.owner=THIS_MODULE
from spi_drivers?

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1004626.html
 
> Thanks!
> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] Input: tsc2005 - Separate SPI and core functions

[Michael Welling]

On Mon, Nov 02, 2015 at 05:49:46PM -0800, Dmitry Torokhov wrote:
> On Fri, Oct 30, 2015 at 07:41:23PM -0500, Michael Welling wrote:
> > This patch separates the SPI functionality from core functionality
> > that overlaps with the tsc2004.
> > 
> > Prepares kernel for new tsc2004 driver without much redundant code.
> > 
> > Signed-off-by: Michael Welling 
> > ---
> >  drivers/input/touchscreen/Kconfig  |   4 +
> >  drivers/input/touchscreen/Makefile |   1 +
> >  drivers/input/touchscreen/tsc2005.c| 709 
> > +
> >  .../touchscreen/{tsc2005.c => tsc200x-core.c}  | 226 ++-
> >  drivers/input/touchscreen/tsc200x-core.h   |  78 +++
> >  5 files changed, 162 insertions(+), 856 deletions(-)
> >  copy drivers/input/touchscreen/{tsc2005.c => tsc200x-core.c} (72%)
> >  create mode 100644 drivers/input/touchscreen/tsc200x-core.h
> 
> This was giving me:
> 
> Kernel: arch/x86/boot/bzImage is ready  (#1451)
>   MODPOST 1447 modules
> ERROR: "tsc200x_regmap_config" [drivers/input/touchscreen/tsc2005.ko] 
> undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> 
> I'll fix it up locally by exporting the symbol.
> 
> Thanks.

Ooops. I guess that I need to check more thoroughly the different configs.

Thanks for your help.

> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
>  wrote:
> > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> >> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> >> > > +Required properties:
> >> > > + - compatible: "ti,tsc2004"
> >> > > + - interrupts: IRQ specifier
> >> > > + - vio-supply : Regulator specifier
> >> >
> >> > reg property?
> >>
> >> Rob,
> >>
> >> It appears that I missed this in the description.
> >>
> >> Probably because I was following the lead of the ts2005 description.
> >>
> >> How does this look:
> >> - reg : I2C address. 0x48 - 0x4b based on the voltage 
> >> applied to
> >> the AD1 and AD0 inputs on the IC.
> >>
> >
> > How about the version below?
> >
> > Thanks.
> >
> > --
> > Dmitry
> >
> >
> > Input: tsc2004 - document ts2004 dt bindings

Just noticed that it says ts2004 instead of tsc2004 in the subject.
Otherwise, I am fine with it.

Thanks for the assistance.

Still no acks or reviews for the other patches in the series.
I would like for someone to test the tsc2005 support to see if it still works.

The tsc2004 works very well on the target that I have here.

> >
> > From: Michael Welling 
> >
> > Adds documentation for the devicetree bindings of the new tsc2004 driver.
> >
> > Signed-off-by: Michael Welling 
> > Signed-off-by: Dmitry Torokhov 
> 
> Acked-by: Rob Herring 
> 
> > ---
> >  .../bindings/input/touchscreen/tsc2005.txt |   34 
> > 
> >  1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
> > b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > index 09089a6..b80c04b 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > @@ -1,14 +1,15 @@
> > -* Texas Instruments tsc2005 touchscreen controller
> > +* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
> >
> >  Required properties:
> > - - compatible: "ti,tsc2005"
> > - - reg   : SPI device address
> > - - spi-max-frequency : Maximal SPI speed
> > + - compatible: "ti,tsc2004" or "ti,tsc2005"
> > + - reg   : Device address
> >   - interrupts: IRQ specifier
> > - - reset-gpios   : GPIO specifier
> > - - vio-supply : Regulator specifier
> > + - spi-max-frequency : Maximum SPI clocking speed of the device
> > +   (for tsc2005)
> >
> >  Optional properties:
> > + - vio-supply: Regulator specifier
> > + - reset-gpios   : GPIO specifier for the controller reset line
> >   - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
> > plates
> > in ohm (defaults to 280)
> >   - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not 
> > respond after
> > @@ -18,6 +19,27 @@ Optional properties:
> >
> >  Example:
> >
> > + {
> > +   tsc2004@48 {
> > +   compatible = "ti,tsc2004";
> > +   reg = <0x48>;
> > +   vio-supply = <>;
> > +
> > +   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
> > +   interrupts-extended = < 27 IRQ_TYPE_EDGE_RISING>;
> > +
> > +   touchscreen-fuzz-x = <4>;
> > +   touchscreen-fuzz-y = <7>;
> > +   touchscreen-fuzz-pressure = <2>;
> > +   touchscreen-size-x = <4096>;
> > +   touchscreen-size-y = <4096>;
> > +   touchscreen-max-pressure = <2048>;
> > +
> > +   ti,x-plate-ohms = <280>;
> > +   ti,esd-recovery-timeout-ms = <8000>;
> > +   };
> > +}
> > +
> >   {
> > tsc2005@0 {
> > compatible = "ti,tsc2005";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
> <dmitry.torok...@gmail.com> wrote:
> > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> >> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> >> > > +Required properties:
> >> > > + - compatible: "ti,tsc2004"
> >> > > + - interrupts: IRQ specifier
> >> > > + - vio-supply : Regulator specifier
> >> >
> >> > reg property?
> >>
> >> Rob,
> >>
> >> It appears that I missed this in the description.
> >>
> >> Probably because I was following the lead of the ts2005 description.
> >>
> >> How does this look:
> >> - reg : I2C address. 0x48 - 0x4b based on the voltage 
> >> applied to
> >> the AD1 and AD0 inputs on the IC.
> >>
> >
> > How about the version below?
> >
> > Thanks.
> >
> > --
> > Dmitry
> >
> >
> > Input: tsc2004 - document ts2004 dt bindings

Just noticed that it says ts2004 instead of tsc2004 in the subject.
Otherwise, I am fine with it.

Thanks for the assistance.

Still no acks or reviews for the other patches in the series.
I would like for someone to test the tsc2005 support to see if it still works.

The tsc2004 works very well on the target that I have here.

> >
> > From: Michael Welling <mwell...@ieee.org>
> >
> > Adds documentation for the devicetree bindings of the new tsc2004 driver.
> >
> > Signed-off-by: Michael Welling <mwell...@ieee.org>
> > Signed-off-by: Dmitry Torokhov <dmitry.torok...@gmail.com>
> 
> Acked-by: Rob Herring <r...@kernel.org>
> 
> > ---
> >  .../bindings/input/touchscreen/tsc2005.txt |   34 
> > 
> >  1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
> > b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > index 09089a6..b80c04b 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > @@ -1,14 +1,15 @@
> > -* Texas Instruments tsc2005 touchscreen controller
> > +* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
> >
> >  Required properties:
> > - - compatible: "ti,tsc2005"
> > - - reg   : SPI device address
> > - - spi-max-frequency : Maximal SPI speed
> > + - compatible: "ti,tsc2004" or "ti,tsc2005"
> > + - reg   : Device address
> >   - interrupts: IRQ specifier
> > - - reset-gpios   : GPIO specifier
> > - - vio-supply : Regulator specifier
> > + - spi-max-frequency : Maximum SPI clocking speed of the device
> > +   (for tsc2005)
> >
> >  Optional properties:
> > + - vio-supply: Regulator specifier
> > + - reset-gpios   : GPIO specifier for the controller reset line
> >   - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
> > plates
> > in ohm (defaults to 280)
> >   - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not 
> > respond after
> > @@ -18,6 +19,27 @@ Optional properties:
> >
> >  Example:
> >
> > + {
> > +   tsc2004@48 {
> > +   compatible = "ti,tsc2004";
> > +   reg = <0x48>;
> > +   vio-supply = <>;
> > +
> > +   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
> > +   interrupts-extended = < 27 IRQ_TYPE_EDGE_RISING>;
> > +
> > +   touchscreen-fuzz-x = <4>;
> > +   touchscreen-fuzz-y = <7>;
> > +   touchscreen-fuzz-pressure = <2>;
> > +   touchscreen-size-x = <4096>;
> > +   touchscreen-size-y = <4096>;
> > +   touchscreen-max-pressure = <2048>;
> > +
> > +   ti,x-plate-ohms = <280>;
> > +   ti,esd-recovery-timeout-ms = <8000>;
> > +   };
> > +}
> > +
> >   {
> > tsc2005@0 {
> > compatible = "ti,tsc2005";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] Input: tsc2005 - Separate SPI and core functions

[Michael Welling]

On Mon, Nov 02, 2015 at 05:49:46PM -0800, Dmitry Torokhov wrote:
> On Fri, Oct 30, 2015 at 07:41:23PM -0500, Michael Welling wrote:
> > This patch separates the SPI functionality from core functionality
> > that overlaps with the tsc2004.
> > 
> > Prepares kernel for new tsc2004 driver without much redundant code.
> > 
> > Signed-off-by: Michael Welling <mwell...@ieee.org>
> > ---
> >  drivers/input/touchscreen/Kconfig  |   4 +
> >  drivers/input/touchscreen/Makefile |   1 +
> >  drivers/input/touchscreen/tsc2005.c| 709 
> > +
> >  .../touchscreen/{tsc2005.c => tsc200x-core.c}  | 226 ++-
> >  drivers/input/touchscreen/tsc200x-core.h   |  78 +++
> >  5 files changed, 162 insertions(+), 856 deletions(-)
> >  copy drivers/input/touchscreen/{tsc2005.c => tsc200x-core.c} (72%)
> >  create mode 100644 drivers/input/touchscreen/tsc200x-core.h
> 
> This was giving me:
> 
> Kernel: arch/x86/boot/bzImage is ready  (#1451)
>   MODPOST 1447 modules
> ERROR: "tsc200x_regmap_config" [drivers/input/touchscreen/tsc2005.ko] 
> undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> 
> I'll fix it up locally by exporting the symbol.
> 
> Thanks.

Ooops. I guess that I need to check more thoroughly the different configs.

Thanks for your help.

> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Tue, Nov 03, 2015 at 02:59:13PM -0800, Dmitry Torokhov wrote:
> On Tue, Nov 03, 2015 at 09:41:17AM -0600, Michael Welling wrote:
> > On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> > > On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
> > > <dmitry.torok...@gmail.com> wrote:
> > > > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> > > >> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > > >> > > +Required properties:
> > > >> > > + - compatible: "ti,tsc2004"
> > > >> > > + - interrupts: IRQ specifier
> > > >> > > + - vio-supply : Regulator specifier
> > > >> >
> > > >> > reg property?
> > > >>
> > > >> Rob,
> > > >>
> > > >> It appears that I missed this in the description.
> > > >>
> > > >> Probably because I was following the lead of the ts2005 description.
> > > >>
> > > >> How does this look:
> > > >> - reg : I2C address. 0x48 - 0x4b based on the voltage 
> > > >> applied to
> > > >> the AD1 and AD0 inputs on the IC.
> > > >>
> > > >
> > > > How about the version below?
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > Dmitry
> > > >
> > > >
> > > > Input: tsc2004 - document ts2004 dt bindings
> > 
> > Just noticed that it says ts2004 instead of tsc2004 in the subject.
> > Otherwise, I am fine with it.
> > 
> > Thanks for the assistance.
> > 
> > Still no acks or reviews for the other patches in the series.
> > I would like for someone to test the tsc2005 support to see if it still 
> > works.
> > 
> > The tsc2004 works very well on the target that I have here.
> 
> I folded this patch into the patch #3 and applied everything.
>

Great.

Will this patch series conflict with the patch series to take out the 
.owner=THIS_MODULE
from spi_drivers?

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1004626.html
 
> Thanks!
> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > +Required properties:
> > + - compatible: "ti,tsc2004"
> > + - interrupts: IRQ specifier
> > + - vio-supply : Regulator specifier
> 
> reg property?

Rob,

It appears that I missed this in the description.

Probably because I was following the lead of the ts2005 description.

How does this look:
- reg   : I2C address. 0x48 - 0x4b based on the voltage applied 
to
  the AD1 and AD0 inputs on the IC.

Do I have to spin the whole series to update this patch?

Everyone,

Are there any other concerns with this patch series?

Regards,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > +Required properties:
> > + - compatible: "ti,tsc2004"
> > + - interrupts: IRQ specifier
> > + - vio-supply : Regulator specifier
> 
> reg property?

Rob,

It appears that I missed this in the description.

Probably because I was following the lead of the ts2005 description.

How does this look:
- reg   : I2C address. 0x48 - 0x4b based on the voltage applied 
to
  the AD1 and AD0 inputs on the IC.

Do I have to spin the whole series to update this patch?

Everyone,

Are there any other concerns with this patch series?

Regards,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] Input: tsc2004 - Add support for tsc2004

[Michael Welling]

Adds support for the i2c based tsc2004.

Signed-off-by: Michael Welling 
---
 drivers/input/touchscreen/Kconfig   | 13 ++
 drivers/input/touchscreen/Makefile  |  1 +
 drivers/input/touchscreen/tsc2004.c | 86 +
 3 files changed, 100 insertions(+)
 create mode 100644 drivers/input/touchscreen/tsc2004.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 6a5878b..ae33da7 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -942,6 +942,19 @@ config TOUCHSCREEN_TSC_SERIO
 config TOUCHSCREEN_TSC200X_CORE
tristate
 
+config TOUCHSCREEN_TSC2004
+   tristate "TSC2004 based touchscreens"
+   depends on I2C
+   select REGMAP_I2C
+   select TOUCHSCREEN_TSC200X_CORE
+   help
+ Say Y here if you have a TSC2004 based touchscreen.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tsc2004.
+
 config TOUCHSCREEN_TSC2005
tristate "TSC2005 based touchscreens"
depends on SPI_MASTER
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 03179f2..cbaa6ab 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT)  += touchright.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
 obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)+= tsc40.o
 obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
+obj-$(CONFIG_TOUCHSCREEN_TSC2004)  += tsc2004.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)  += tsc2005.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)  += tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)  += ucb1400_ts.o
diff --git a/drivers/input/touchscreen/tsc2004.c 
b/drivers/input/touchscreen/tsc2004.c
new file mode 100644
index 000..d2f7a6b
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2004.c
@@ -0,0 +1,86 @@
+/*
+ * TSC2004 touchscreen driver
+ *
+ * Copyright (C) 2015 QWERTY Embedded Design
+ * Copyright (C) 2015 EMAC 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.
+ *
+ * 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 "tsc200x-core.h"
+
+static int tsc2004_cmd(struct device *dev, u8 cmd)
+{
+   u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
+   s32 data;
+   struct i2c_client *i2c = to_i2c_client(dev);
+
+   data = i2c_smbus_write_byte(i2c, tx);
+   if (data < 0) {
+   dev_err(dev, "%s: failed, command: %x i2c error: %d\n",
+   __func__, cmd, data);
+   return data;
+   }
+
+   return 0;
+}
+
+static int tsc2004_probe(struct i2c_client *i2c,
+const struct i2c_device_id *id)
+
+{
+   return tsc200x_probe(>dev, i2c->irq, BUS_I2C,
+devm_regmap_init_i2c(i2c, _regmap_config),
+_cmd);
+}
+
+static int tsc2004_remove(struct i2c_client *i2c)
+{
+   return tsc200x_remove(>dev);
+}
+
+static const struct i2c_device_id tsc2004_idtable[] = {
+   { "tsc2004", 0 },
+   { }
+};
+
+MODULE_DEVICE_TABLE(i2c, tsc2004_idtable);
+
+#ifdef CONFIG_OF
+static const struct of_device_id tsc2004_of_match[] = {
+   { .compatible = "ti,tsc2004" },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tsc2004_of_match);
+#endif
+
+static struct i2c_driver tsc2004_driver = {
+   .driver = {
+   .name   = "tsc2004",
+   .of_match_table = of_match_ptr(tsc2004_of_match),
+   .pm = _pm_ops,
+   },
+   .id_table   = tsc2004_idtable,
+   .probe  = tsc2004_probe,
+   .remove = tsc2004_remove,
+};
+
+module_i2c_driver(tsc2004_driver);
+
+MODULE_AUTHOR("Michael Welling ");
+MODULE_DESCRIPTION("TSC2004 Touchscreen Driver");
+MODULE_LICENSE("GPL");
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] Input: tsc2005 - Separate SPI and core functions

[Michael Welling]

This patch separates the SPI functionality from core functionality
that overlaps with the tsc2004.

Prepares kernel for new tsc2004 driver without much redundant code.

Signed-off-by: Michael Welling 
---
 drivers/input/touchscreen/Kconfig  |   4 +
 drivers/input/touchscreen/Makefile |   1 +
 drivers/input/touchscreen/tsc2005.c| 709 +
 .../touchscreen/{tsc2005.c => tsc200x-core.c}  | 226 ++-
 drivers/input/touchscreen/tsc200x-core.h   |  78 +++
 5 files changed, 162 insertions(+), 856 deletions(-)
 copy drivers/input/touchscreen/{tsc2005.c => tsc200x-core.c} (72%)
 create mode 100644 drivers/input/touchscreen/tsc200x-core.h

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 80cc698..6a5878b 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -939,10 +939,14 @@ config TOUCHSCREEN_TSC_SERIO
  To compile this driver as a module, choose M here: the
  module will be called tsc40.
 
+config TOUCHSCREEN_TSC200X_CORE
+   tristate
+
 config TOUCHSCREEN_TSC2005
tristate "TSC2005 based touchscreens"
depends on SPI_MASTER
select REGMAP_SPI
+   select TOUCHSCREEN_TSC200X_CORE
help
  Say Y here if you have a TSC2005 based touchscreen.
 
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 17435c7..03179f2 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213)  += touchit213.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT)   += touchright.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
 obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)+= tsc40.o
+obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)  += tsc2005.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)  += tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)  += ucb1400_ts.o
diff --git a/drivers/input/touchscreen/tsc2005.c 
b/drivers/input/touchscreen/tsc2005.c
index 0f65d02..fc879cf 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -2,9 +2,10 @@
  * TSC2005 touchscreen driver
  *
  * Copyright (C) 2006-2010 Nokia Corporation
+ * Copyright (C) 2015 QWERTY Embedded Design
+ * Copyright (C) 2015 EMAC Inc.
  *
- * Author: Lauri Leukkunen 
- * based on TSC2301 driver by Klaus K. Pedersen 
+ * Based on original tsc2005.c by Lauri Leukkunen 
  *
  * 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
@@ -15,192 +16,34 @@
  * 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, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
  */
 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-
-/*
- * The touchscreen interface operates as follows:
- *
- * 1) Pen is pressed against the touchscreen.
- * 2) TSC2005 performs AD conversion.
- * 3) After the conversion is done TSC2005 drives DAV line down.
- * 4) GPIO IRQ is received and tsc2005_irq_thread() is scheduled.
- * 5) tsc2005_irq_thread() queues up an spi transfer to fetch the x, y, z1, z2
- *values.
- * 6) tsc2005_irq_thread() reports coordinates to input layer and sets up
- *tsc2005_penup_timer() to be called after TSC2005_PENUP_TIME_MS (40ms).
- * 7) When the penup timer expires, there have not been touch or DAV interrupts
- *during the last 40ms which means the pen has been lifted.
- *
- * ESD recovery via a hardware reset is done if the TSC2005 doesn't respond
- * after a configurable period (in ms) of activity. If esd_timeout is 0, the
- * watchdog is disabled.
- */
-
-/* control byte 1 */
-#define TSC2005_CMD0x80
-#define TSC2005_CMD_NORMAL 0x00
-#define TSC2005_CMD_STOP   0x01
-#define TSC2005_CMD_12BIT  0x04
-
-/* control byte 0 */
-#define TSC2005_REG_READ   0x01 /* R/W access */
-#define TSC2005_REG_PND0   0x02 /* Power Not Down Control */
-#define TSC2005_REG_X  (0x0 << 3)
-#define TSC2005_REG_Y  (0x1 << 3)
-#define TSC2005_REG_Z1 (0x2 << 3)
-#define TSC2005_REG_Z2 (0x3 << 3)
-#define TSC2005_REG_AUX(0x4 << 3)
-#define TSC2005_REG_TEMP1  (0x5 << 3)
-#define TSC2005_REG_TEMP2  (0x6 << 3)
-#define TSC2005_REG_STATUS (0x7 << 3)
-#define TSC2005_REG_AUX_HIGH   

[PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

Adds documentation for the devicetree bindings of the new tsc2004 driver.

Signed-off-by: Michael Welling 
---
 .../bindings/input/touchscreen/tsc2005.txt | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
index 09089a6..27c6082 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -1,3 +1,42 @@
+* Texas Instruments tsc2004 touchscreen controller
+
+Required properties:
+ - compatible: "ti,tsc2004"
+ - interrupts: IRQ specifier
+ - vio-supply : Regulator specifier
+
+Optional properties:
+ - reset-gpios   : GPIO specifier
+ - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
plates
+   in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond 
after
+   the configured time (in milli seconds), the 
driver
+   will reset it. This is disabled by default.
+ - properties defined in touchscreen.txt
+
+Example:
+
+ {
+   tsc2004@48 {
+   compatible = "ti,tsc2004";
+   reg = <0x48>;
+   vio-supply = <>;
+
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   interrupts-extended = < 27 IRQ_TYPE_EDGE_RISING>;
+
+   touchscreen-fuzz-x = <4>;
+   touchscreen-fuzz-y = <7>;
+   touchscreen-fuzz-pressure = <2>;
+   touchscreen-size-x = <4096>;
+   touchscreen-size-y = <4096>;
+   touchscreen-max-pressure = <2048>;
+
+   ti,x-plate-ohms = <280>;
+   ti,esd-recovery-timeout-ms = <8000>;
+   };
+}
+
 * Texas Instruments tsc2005 touchscreen controller
 
 Required properties:
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] Input: tsc200x-core - Rename functions and variables

[Michael Welling]

The functions, variables, and defines of the new tsc200x-core.c are
renamed to tsc200x instead of tsc2005 avoid possible confusion.

Signed-off-by: Michael Welling 
---
 drivers/input/touchscreen/tsc2005.c  |   2 +-
 drivers/input/touchscreen/tsc200x-core.c | 200 +++
 drivers/input/touchscreen/tsc200x-core.h | 102 
 3 files changed, 152 insertions(+), 152 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2005.c 
b/drivers/input/touchscreen/tsc2005.c
index fc879cf..cbff18a 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -28,7 +28,7 @@
 
 static int tsc2005_cmd(struct device *dev, u8 cmd)
 {
-   u8 tx = TSC2005_CMD | TSC2005_CMD_12BIT | cmd;
+   u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
struct spi_transfer xfer = {
.tx_buf = ,
.len= 1,
diff --git a/drivers/input/touchscreen/tsc200x-core.c 
b/drivers/input/touchscreen/tsc200x-core.c
index 528ad39..6dfcbea 100644
--- a/drivers/input/touchscreen/tsc200x-core.c
+++ b/drivers/input/touchscreen/tsc200x-core.c
@@ -37,28 +37,28 @@
  * The touchscreen interface operates as follows:
  *
  * 1) Pen is pressed against the touchscreen.
- * 2) TSC2005 performs AD conversion.
- * 3) After the conversion is done TSC2005 drives DAV line down.
- * 4) GPIO IRQ is received and tsc2005_irq_thread() is scheduled.
- * 5) tsc2005_irq_thread() queues up a transfer to fetch the x, y, z1, z2
+ * 2) TSC200X performs AD conversion.
+ * 3) After the conversion is done TSC200X drives DAV line down.
+ * 4) GPIO IRQ is received and tsc200x_irq_thread() is scheduled.
+ * 5) tsc200x_irq_thread() queues up a transfer to fetch the x, y, z1, z2
  *values.
- * 6) tsc2005_irq_thread() reports coordinates to input layer and sets up
- *tsc2005_penup_timer() to be called after TSC2005_PENUP_TIME_MS (40ms).
+ * 6) tsc200x_irq_thread() reports coordinates to input layer and sets up
+ *tsc200x_penup_timer() to be called after TSC200X_PENUP_TIME_MS (40ms).
  * 7) When the penup timer expires, there have not been touch or DAV interrupts
  *during the last 40ms which means the pen has been lifted.
  *
- * ESD recovery via a hardware reset is done if the TSC2005 doesn't respond
+ * ESD recovery via a hardware reset is done if the TSC200X doesn't respond
  * after a configurable period (in ms) of activity. If esd_timeout is 0, the
  * watchdog is disabled.
  */
 
-static const struct regmap_range tsc2005_writable_ranges[] = {
-   regmap_reg_range(TSC2005_REG_AUX_HIGH, TSC2005_REG_CFR2),
+static const struct regmap_range tsc200x_writable_ranges[] = {
+   regmap_reg_range(TSC200X_REG_AUX_HIGH, TSC200X_REG_CFR2),
 };
 
-static const struct regmap_access_table tsc2005_writable_table = {
-   .yes_ranges = tsc2005_writable_ranges,
-   .n_yes_ranges = ARRAY_SIZE(tsc2005_writable_ranges),
+static const struct regmap_access_table tsc200x_writable_table = {
+   .yes_ranges = tsc200x_writable_ranges,
+   .n_yes_ranges = ARRAY_SIZE(tsc200x_writable_ranges),
 };
 
 const struct regmap_config tsc200x_regmap_config = {
@@ -66,21 +66,21 @@ const struct regmap_config tsc200x_regmap_config = {
.val_bits = 16,
.reg_stride = 0x08,
.max_register = 0x78,
-   .read_flag_mask = TSC2005_REG_READ,
-   .write_flag_mask = TSC2005_REG_PND0,
-   .wr_table = _writable_table,
+   .read_flag_mask = TSC200X_REG_READ,
+   .write_flag_mask = TSC200X_REG_PND0,
+   .wr_table = _writable_table,
.use_single_rw = true,
 };
 
-struct tsc2005_data {
+struct tsc200x_data {
u16 x;
u16 y;
u16 z1;
u16 z2;
 } __packed;
-#define TSC2005_DATA_REGS 4
+#define TSC200X_DATA_REGS 4
 
-struct tsc2005 {
+struct tsc200x {
struct device   *dev;
struct regmap   *regmap;
__u16   bustype;
@@ -118,7 +118,7 @@ struct tsc2005 {
int irq;
 };
 
-static void tsc2005_update_pen_state(struct tsc2005 *ts,
+static void tsc200x_update_pen_state(struct tsc200x *ts,
 int x, int y, int pressure)
 {
if (pressure) {
@@ -141,17 +141,17 @@ static void tsc2005_update_pen_state(struct tsc2005 *ts,
pressure);
 }
 
-static irqreturn_t tsc2005_irq_thread(int irq, void *_ts)
+static irqreturn_t tsc200x_irq_thread(int irq, void *_ts)
 {
-   struct tsc2005 *ts = _ts;
+   struct tsc200x *ts = _ts;
unsigned long flags;
unsigned int pressure;
-   struct tsc2005_data tsdata;
+   struct tsc200x_data tsdata;
int error;
 
/* read the coordinates */
-   error = regmap_bulk_read(ts->regmap, TSC2005_REG_X, ,
-TSC2005_DATA_REGS);
+   error = regmap_bulk_read(ts->regmap, TSC200X_REG_X, ,
+TSC200X_DATA_REGS);
if (unlikely

[PATCH v4 0/4] tsc2005 - Add support for tsc2004

[Michael Welling]

Adds support for the i2c based tsc2004.

Due to the overlapping functionality of the tsc2004 and tsc2005
the common code was moved to a core driver (tsc200x-core).

v4: Break patch into series. Isolates the I2C and SPI commands to
respective drivers.
v3: Splits the tsc2004 and tsc2005 into separate drivers with
with common routines in tsc200x-core.
v2: Fixes Kconfig based on report for 0-day build bot.

Michael Welling (4):
  Input: tsc2005 - Seperate SPI and core functions
  Input: tsc200x-core - Rename functions and variables
  Input: tsc2004 - Add support for tsc2004
  Input: tsc2004 - Document ts2004 dt bindings

 .../bindings/input/touchscreen/tsc2005.txt |  39 ++
 drivers/input/touchscreen/Kconfig  |  17 +
 drivers/input/touchscreen/Makefile |   2 +
 drivers/input/touchscreen/tsc2004.c|  86 +++
 drivers/input/touchscreen/tsc2005.c| 711 +
 .../touchscreen/{tsc2005.c => tsc200x-core.c}  | 408 +---
 drivers/input/touchscreen/tsc200x-core.h   |  78 +++
 7 files changed, 393 insertions(+), 948 deletions(-)
 create mode 100644 drivers/input/touchscreen/tsc2004.c
 copy drivers/input/touchscreen/{tsc2005.c => tsc200x-core.c} (51%)
 create mode 100644 drivers/input/touchscreen/tsc200x-core.h

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

Adds documentation for the devicetree bindings of the new tsc2004 driver.

Signed-off-by: Michael Welling <mwell...@ieee.org>
---
 .../bindings/input/touchscreen/tsc2005.txt | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
index 09089a6..27c6082 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -1,3 +1,42 @@
+* Texas Instruments tsc2004 touchscreen controller
+
+Required properties:
+ - compatible: "ti,tsc2004"
+ - interrupts: IRQ specifier
+ - vio-supply : Regulator specifier
+
+Optional properties:
+ - reset-gpios   : GPIO specifier
+ - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
plates
+   in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond 
after
+   the configured time (in milli seconds), the 
driver
+   will reset it. This is disabled by default.
+ - properties defined in touchscreen.txt
+
+Example:
+
+ {
+   tsc2004@48 {
+   compatible = "ti,tsc2004";
+   reg = <0x48>;
+   vio-supply = <>;
+
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   interrupts-extended = < 27 IRQ_TYPE_EDGE_RISING>;
+
+   touchscreen-fuzz-x = <4>;
+   touchscreen-fuzz-y = <7>;
+   touchscreen-fuzz-pressure = <2>;
+   touchscreen-size-x = <4096>;
+   touchscreen-size-y = <4096>;
+   touchscreen-max-pressure = <2048>;
+
+   ti,x-plate-ohms = <280>;
+   ti,esd-recovery-timeout-ms = <8000>;
+   };
+}
+
 * Texas Instruments tsc2005 touchscreen controller
 
 Required properties:
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] Input: tsc200x-core - Rename functions and variables

[Michael Welling]

The functions, variables, and defines of the new tsc200x-core.c are
renamed to tsc200x instead of tsc2005 avoid possible confusion.

Signed-off-by: Michael Welling <mwell...@ieee.org>
---
 drivers/input/touchscreen/tsc2005.c  |   2 +-
 drivers/input/touchscreen/tsc200x-core.c | 200 +++
 drivers/input/touchscreen/tsc200x-core.h | 102 
 3 files changed, 152 insertions(+), 152 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2005.c 
b/drivers/input/touchscreen/tsc2005.c
index fc879cf..cbff18a 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -28,7 +28,7 @@
 
 static int tsc2005_cmd(struct device *dev, u8 cmd)
 {
-   u8 tx = TSC2005_CMD | TSC2005_CMD_12BIT | cmd;
+   u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
struct spi_transfer xfer = {
.tx_buf = ,
.len= 1,
diff --git a/drivers/input/touchscreen/tsc200x-core.c 
b/drivers/input/touchscreen/tsc200x-core.c
index 528ad39..6dfcbea 100644
--- a/drivers/input/touchscreen/tsc200x-core.c
+++ b/drivers/input/touchscreen/tsc200x-core.c
@@ -37,28 +37,28 @@
  * The touchscreen interface operates as follows:
  *
  * 1) Pen is pressed against the touchscreen.
- * 2) TSC2005 performs AD conversion.
- * 3) After the conversion is done TSC2005 drives DAV line down.
- * 4) GPIO IRQ is received and tsc2005_irq_thread() is scheduled.
- * 5) tsc2005_irq_thread() queues up a transfer to fetch the x, y, z1, z2
+ * 2) TSC200X performs AD conversion.
+ * 3) After the conversion is done TSC200X drives DAV line down.
+ * 4) GPIO IRQ is received and tsc200x_irq_thread() is scheduled.
+ * 5) tsc200x_irq_thread() queues up a transfer to fetch the x, y, z1, z2
  *values.
- * 6) tsc2005_irq_thread() reports coordinates to input layer and sets up
- *tsc2005_penup_timer() to be called after TSC2005_PENUP_TIME_MS (40ms).
+ * 6) tsc200x_irq_thread() reports coordinates to input layer and sets up
+ *tsc200x_penup_timer() to be called after TSC200X_PENUP_TIME_MS (40ms).
  * 7) When the penup timer expires, there have not been touch or DAV interrupts
  *during the last 40ms which means the pen has been lifted.
  *
- * ESD recovery via a hardware reset is done if the TSC2005 doesn't respond
+ * ESD recovery via a hardware reset is done if the TSC200X doesn't respond
  * after a configurable period (in ms) of activity. If esd_timeout is 0, the
  * watchdog is disabled.
  */
 
-static const struct regmap_range tsc2005_writable_ranges[] = {
-   regmap_reg_range(TSC2005_REG_AUX_HIGH, TSC2005_REG_CFR2),
+static const struct regmap_range tsc200x_writable_ranges[] = {
+   regmap_reg_range(TSC200X_REG_AUX_HIGH, TSC200X_REG_CFR2),
 };
 
-static const struct regmap_access_table tsc2005_writable_table = {
-   .yes_ranges = tsc2005_writable_ranges,
-   .n_yes_ranges = ARRAY_SIZE(tsc2005_writable_ranges),
+static const struct regmap_access_table tsc200x_writable_table = {
+   .yes_ranges = tsc200x_writable_ranges,
+   .n_yes_ranges = ARRAY_SIZE(tsc200x_writable_ranges),
 };
 
 const struct regmap_config tsc200x_regmap_config = {
@@ -66,21 +66,21 @@ const struct regmap_config tsc200x_regmap_config = {
.val_bits = 16,
.reg_stride = 0x08,
.max_register = 0x78,
-   .read_flag_mask = TSC2005_REG_READ,
-   .write_flag_mask = TSC2005_REG_PND0,
-   .wr_table = _writable_table,
+   .read_flag_mask = TSC200X_REG_READ,
+   .write_flag_mask = TSC200X_REG_PND0,
+   .wr_table = _writable_table,
.use_single_rw = true,
 };
 
-struct tsc2005_data {
+struct tsc200x_data {
u16 x;
u16 y;
u16 z1;
u16 z2;
 } __packed;
-#define TSC2005_DATA_REGS 4
+#define TSC200X_DATA_REGS 4
 
-struct tsc2005 {
+struct tsc200x {
struct device   *dev;
struct regmap   *regmap;
__u16   bustype;
@@ -118,7 +118,7 @@ struct tsc2005 {
int irq;
 };
 
-static void tsc2005_update_pen_state(struct tsc2005 *ts,
+static void tsc200x_update_pen_state(struct tsc200x *ts,
 int x, int y, int pressure)
 {
if (pressure) {
@@ -141,17 +141,17 @@ static void tsc2005_update_pen_state(struct tsc2005 *ts,
pressure);
 }
 
-static irqreturn_t tsc2005_irq_thread(int irq, void *_ts)
+static irqreturn_t tsc200x_irq_thread(int irq, void *_ts)
 {
-   struct tsc2005 *ts = _ts;
+   struct tsc200x *ts = _ts;
unsigned long flags;
unsigned int pressure;
-   struct tsc2005_data tsdata;
+   struct tsc200x_data tsdata;
int error;
 
/* read the coordinates */
-   error = regmap_bulk_read(ts->regmap, TSC2005_REG_X, ,
-TSC2005_DATA_REGS);
+   error = regmap_bulk_read(ts->regmap, TSC200X_REG_X, ,
+TSC200X_DATA_REGS);

[PATCH 1/4] Input: tsc2005 - Separate SPI and core functions

[Michael Welling]

This patch separates the SPI functionality from core functionality
that overlaps with the tsc2004.

Prepares kernel for new tsc2004 driver without much redundant code.

Signed-off-by: Michael Welling <mwell...@ieee.org>
---
 drivers/input/touchscreen/Kconfig  |   4 +
 drivers/input/touchscreen/Makefile |   1 +
 drivers/input/touchscreen/tsc2005.c| 709 +
 .../touchscreen/{tsc2005.c => tsc200x-core.c}  | 226 ++-
 drivers/input/touchscreen/tsc200x-core.h   |  78 +++
 5 files changed, 162 insertions(+), 856 deletions(-)
 copy drivers/input/touchscreen/{tsc2005.c => tsc200x-core.c} (72%)
 create mode 100644 drivers/input/touchscreen/tsc200x-core.h

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 80cc698..6a5878b 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -939,10 +939,14 @@ config TOUCHSCREEN_TSC_SERIO
  To compile this driver as a module, choose M here: the
  module will be called tsc40.
 
+config TOUCHSCREEN_TSC200X_CORE
+   tristate
+
 config TOUCHSCREEN_TSC2005
tristate "TSC2005 based touchscreens"
depends on SPI_MASTER
select REGMAP_SPI
+   select TOUCHSCREEN_TSC200X_CORE
help
  Say Y here if you have a TSC2005 based touchscreen.
 
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 17435c7..03179f2 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213)  += touchit213.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT)   += touchright.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
 obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)+= tsc40.o
+obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)  += tsc2005.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)  += tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)  += ucb1400_ts.o
diff --git a/drivers/input/touchscreen/tsc2005.c 
b/drivers/input/touchscreen/tsc2005.c
index 0f65d02..fc879cf 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -2,9 +2,10 @@
  * TSC2005 touchscreen driver
  *
  * Copyright (C) 2006-2010 Nokia Corporation
+ * Copyright (C) 2015 QWERTY Embedded Design
+ * Copyright (C) 2015 EMAC Inc.
  *
- * Author: Lauri Leukkunen <lauri.leukku...@nokia.com>
- * based on TSC2301 driver by Klaus K. Pedersen <klaus.k.peder...@nokia.com>
+ * Based on original tsc2005.c by Lauri Leukkunen <lauri.leukku...@nokia.com>
  *
  * 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
@@ -15,192 +16,34 @@
  * 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, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
  */
 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-
-/*
- * The touchscreen interface operates as follows:
- *
- * 1) Pen is pressed against the touchscreen.
- * 2) TSC2005 performs AD conversion.
- * 3) After the conversion is done TSC2005 drives DAV line down.
- * 4) GPIO IRQ is received and tsc2005_irq_thread() is scheduled.
- * 5) tsc2005_irq_thread() queues up an spi transfer to fetch the x, y, z1, z2
- *values.
- * 6) tsc2005_irq_thread() reports coordinates to input layer and sets up
- *tsc2005_penup_timer() to be called after TSC2005_PENUP_TIME_MS (40ms).
- * 7) When the penup timer expires, there have not been touch or DAV interrupts
- *during the last 40ms which means the pen has been lifted.
- *
- * ESD recovery via a hardware reset is done if the TSC2005 doesn't respond
- * after a configurable period (in ms) of activity. If esd_timeout is 0, the
- * watchdog is disabled.
- */
-
-/* control byte 1 */
-#define TSC2005_CMD0x80
-#define TSC2005_CMD_NORMAL 0x00
-#define TSC2005_CMD_STOP   0x01
-#define TSC2005_CMD_12BIT  0x04
-
-/* control byte 0 */
-#define TSC2005_REG_READ   0x01 /* R/W access */
-#define TSC2005_REG_PND0   0x02 /* Power Not Down Control */
-#define TSC2005_REG_X  (0x0 << 3)
-#define TSC2005_REG_Y  (0x1 << 3)
-#define TSC2005_REG_Z1 (0x2 << 3)
-#define TSC2005_REG_Z2 (0x3 << 3)
-#define TSC2005_REG_AUX(0x4 << 3)
-#define TSC2005_REG_TEMP1  (0x5 << 3)
-#define TSC2005_REG_TEM

[PATCH v4 0/4] tsc2005 - Add support for tsc2004

[Michael Welling]

Adds support for the i2c based tsc2004.

Due to the overlapping functionality of the tsc2004 and tsc2005
the common code was moved to a core driver (tsc200x-core).

v4: Break patch into series. Isolates the I2C and SPI commands to
respective drivers.
v3: Splits the tsc2004 and tsc2005 into separate drivers with
with common routines in tsc200x-core.
v2: Fixes Kconfig based on report for 0-day build bot.

Michael Welling (4):
  Input: tsc2005 - Seperate SPI and core functions
  Input: tsc200x-core - Rename functions and variables
  Input: tsc2004 - Add support for tsc2004
  Input: tsc2004 - Document ts2004 dt bindings

 .../bindings/input/touchscreen/tsc2005.txt |  39 ++
 drivers/input/touchscreen/Kconfig  |  17 +
 drivers/input/touchscreen/Makefile |   2 +
 drivers/input/touchscreen/tsc2004.c|  86 +++
 drivers/input/touchscreen/tsc2005.c| 711 +
 .../touchscreen/{tsc2005.c => tsc200x-core.c}  | 408 +---
 drivers/input/touchscreen/tsc200x-core.h   |  78 +++
 7 files changed, 393 insertions(+), 948 deletions(-)
 create mode 100644 drivers/input/touchscreen/tsc2004.c
 copy drivers/input/touchscreen/{tsc2005.c => tsc200x-core.c} (51%)
 create mode 100644 drivers/input/touchscreen/tsc200x-core.h

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] Input: tsc2004 - Add support for tsc2004

[Michael Welling]

Adds support for the i2c based tsc2004.

Signed-off-by: Michael Welling <mwell...@ieee.org>
---
 drivers/input/touchscreen/Kconfig   | 13 ++
 drivers/input/touchscreen/Makefile  |  1 +
 drivers/input/touchscreen/tsc2004.c | 86 +
 3 files changed, 100 insertions(+)
 create mode 100644 drivers/input/touchscreen/tsc2004.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 6a5878b..ae33da7 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -942,6 +942,19 @@ config TOUCHSCREEN_TSC_SERIO
 config TOUCHSCREEN_TSC200X_CORE
tristate
 
+config TOUCHSCREEN_TSC2004
+   tristate "TSC2004 based touchscreens"
+   depends on I2C
+   select REGMAP_I2C
+   select TOUCHSCREEN_TSC200X_CORE
+   help
+ Say Y here if you have a TSC2004 based touchscreen.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tsc2004.
+
 config TOUCHSCREEN_TSC2005
tristate "TSC2005 based touchscreens"
depends on SPI_MASTER
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 03179f2..cbaa6ab 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT)  += touchright.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
 obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)+= tsc40.o
 obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
+obj-$(CONFIG_TOUCHSCREEN_TSC2004)  += tsc2004.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)  += tsc2005.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)  += tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)  += ucb1400_ts.o
diff --git a/drivers/input/touchscreen/tsc2004.c 
b/drivers/input/touchscreen/tsc2004.c
new file mode 100644
index 000..d2f7a6b
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2004.c
@@ -0,0 +1,86 @@
+/*
+ * TSC2004 touchscreen driver
+ *
+ * Copyright (C) 2015 QWERTY Embedded Design
+ * Copyright (C) 2015 EMAC 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.
+ *
+ * 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 "tsc200x-core.h"
+
+static int tsc2004_cmd(struct device *dev, u8 cmd)
+{
+   u8 tx = TSC200X_CMD | TSC200X_CMD_12BIT | cmd;
+   s32 data;
+   struct i2c_client *i2c = to_i2c_client(dev);
+
+   data = i2c_smbus_write_byte(i2c, tx);
+   if (data < 0) {
+   dev_err(dev, "%s: failed, command: %x i2c error: %d\n",
+   __func__, cmd, data);
+   return data;
+   }
+
+   return 0;
+}
+
+static int tsc2004_probe(struct i2c_client *i2c,
+const struct i2c_device_id *id)
+
+{
+   return tsc200x_probe(>dev, i2c->irq, BUS_I2C,
+devm_regmap_init_i2c(i2c, _regmap_config),
+_cmd);
+}
+
+static int tsc2004_remove(struct i2c_client *i2c)
+{
+   return tsc200x_remove(>dev);
+}
+
+static const struct i2c_device_id tsc2004_idtable[] = {
+   { "tsc2004", 0 },
+   { }
+};
+
+MODULE_DEVICE_TABLE(i2c, tsc2004_idtable);
+
+#ifdef CONFIG_OF
+static const struct of_device_id tsc2004_of_match[] = {
+   { .compatible = "ti,tsc2004" },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tsc2004_of_match);
+#endif
+
+static struct i2c_driver tsc2004_driver = {
+   .driver = {
+   .name   = "tsc2004",
+   .of_match_table = of_match_ptr(tsc2004_of_match),
+   .pm = _pm_ops,
+   },
+   .id_table   = tsc2004_idtable,
+   .probe  = tsc2004_probe,
+   .remove     = tsc2004_remove,
+};
+
+module_i2c_driver(tsc2004_driver);
+
+MODULE_AUTHOR("Michael Welling <mwell...@ieee.org>");
+MODULE_DESCRIPTION("TSC2004 Touchscreen Driver");
+MODULE_LICENSE("GPL");
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004

[Michael Welling]

Dmitry,

On Thu, Oct 29, 2015 at 06:45:22PM -0700, Dmitry Torokhov wrote:
> Hi Michael,
> 
> On Wed, Oct 28, 2015 at 07:12:34PM -0500, Michael Welling wrote:
> > Adds support for the i2c based tsc2004.
> > 
> > Due to the overlapping functionality of the tsc2004 and tsc2005
> > the common code was moved to a core driver (tsc200x-core).
> > 
> > Signed-off-by: Michael Welling 
> 
> In addition to what has been discussed in the other email:
> 
> > ---
> > v3: Splits the tsc2004 and tsc2005 into separate drivers with
> > with common routines in tsc200x-core.
> > v2: Fixes Kconfig based on report for 0-day build bot.
> >  .../bindings/input/touchscreen/tsc2004.txt |  38 +
> 
> Can we please combine tsc2004.txt and tsc2005.txt?

Sure.

> 
> >  
> > +config TOUCHSCREEN_TSC200X
> > +   tristate
> 
> Let's call it TOUCHSCREEN_TSC200X_CORE.

Okay.

> 
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/tsc2004.c
> > @@ -0,0 +1,73 @@
> > +/*
> > + * TSC2004 touchscreen driver
> > + *
> > + * Copyright (C) 2015 EMAC Inc.
> > + * Copyright (C) 2015 QWERTY Embedded Design
> > + *
> > + * 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.
> > + *
> > + * 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.
> > + *
> 
> Please drop this empty line in the comment.
>

No problem.
 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "tsc200x-core.h"
> > +
> > +static int tsc2004_probe(struct i2c_client *i2c,
> > +const struct i2c_device_id *id)
> > +
> > +{
> > +   return tsc200x_probe(>dev, i2c->irq, BUS_I2C,
> > +devm_regmap_init_i2c(i2c,
> > + _regmap_config));
> > +}
> > +
> > +static int tsc2004_remove(struct i2c_client *i2c)
> > +{
> > +   return tsc200x_remove(>dev);
> > +}
> > +
> > +static const struct i2c_device_id tsc2004_idtable[] = {
> > +   { "tsc2004", 0 },
> > +   { }
> > +};
> > +
> > +MODULE_DEVICE_TABLE(i2c, tsc2004_idtable);
> > +
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id tsc2004_of_match[] = {
> > +   { .compatible = "ti,tsc2004" },
> > +   { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, tsc2004_of_match);
> > +#endif
> > +
> > +static SIMPLE_DEV_PM_OPS(tsc2004_pm_ops, tsc200x_suspend, tsc200x_resume);
> 
> Hmm, maybe you should export tsc200x_pm_ops instead of individual
> functions.
> 
> > +
> > +int __maybe_unused tsc200x_suspend(struct device *dev)
> > +{
> > +   struct tsc2005 *ts = dev_get_drvdata(dev);
> > +
> > +   mutex_lock(>mutex);
> > +
> > +   if (!ts->suspended && ts->opened)
> > +   __tsc2005_disable(ts);
> > +
> > +   ts->suspended = true;
> > +
> > +   mutex_unlock(>mutex);
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(tsc200x_suspend);
> 
> __maybe_unused does not make sense here - the symbol is exported and
> therefore is always used. If you export the pm_ops stucture then you can
> keep functions as __maybe_unused.
> 
> BTW, can you generate the patch with -M to let git do the rename
> detection - it will be easier to see what changed in the core.

Okay.

Here is somthing that I just saw. The tsc2005_cmd function uses a pointer to
struct tsc2005 as a paramter. So the struct needs to moved into the 
tsc200x-core.h. Should all of the defines be moved there too?

Also the old platform data is in a SPI specific include directory.
Do we want to move this?

Also should I change all of the names of the core functions, variables, structs,
and defines to tsc200x for consistency including the driver struct/defines/etc?

Regards,

Michael
> 
> Thanks!
> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004

[Michael Welling]

On Fri, Oct 30, 2015 at 09:39:05AM +0900, Mark Brown wrote:
> On Thu, Oct 29, 2015 at 03:23:31PM -0700, Dmitry Torokhov wrote:
> 
> > However, you have regmap in the driver core already. Mark, is it
> > possible to have regmap API also allow doing raw underlying protocol
> > transfer so that consumers could issue command requests without needing
> > to know if they need to do it over i2c or spi or whatever. Or we need a
> > notion of command registers in regmap...
> 
> I don't think it's a good idea to break the encapsulation of the regmap
> and export the raw I/O functionality directly, there seem to be more bad
> ways of using that than good.  The driver must at some point know what
> bus it is dealing with and be able to manage this itself.
> 
> I don't know what "command registers" are.

With this device, if the MSB of the first byte of the transaction is 1 then
a convertor command is encoded in that byte instead of a register address.

So here is my plan:
- Add a function pointer for tsc2005_cmd in the struct tsc2005
- Put the spi and i2c tsc2005_cmd versions in their respective drivers
- Pass the cmd functions to the core via tsc200x_probe

Any objections?
Other review suggestions before I code the revision?
Am I doing too much with a single patch?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004

[Michael Welling]

On Thu, Oct 29, 2015 at 10:46:20PM +0100, Arnd Bergmann wrote:
> On Thursday 29 October 2015 09:22:37 Michael Welling wrote:
> > > 
> > > All errors (new ones prefixed by >>):
> > > 
> > >drivers/built-in.o: In function `tsc2005_cmd':
> > > >> tsc200x-core.c:(.text+0x2ae07f): undefined reference to 
> > > >> `i2c_smbus_write_byte'
> > 
> > Argh!
> > 
> > How do I fix this one?
> > 
> 
> Move all the I2C specific code into the tsc2004.c file and remove the
> #ifdef. The problem is that tsc200x-core.c is used as built-in when
> TOUCHSCREEN_TSC2005=y and I2C=m, so it can't call functions that are
> defined in i2c-core.c.

How would I call the function from the core then?

-Michael
> 
>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004

[Michael Welling]

On Thu, Oct 29, 2015 at 03:25:34PM +0800, kbuild test robot wrote:
> Hi Michael,
> 
> [auto build test ERROR on input/next -- if it's inappropriate base, please 
> suggest rules for selecting the more suitable base]
> 
> url:
> https://github.com/0day-ci/linux/commits/Michael-Welling/Input-tsc2005-Add-support-for-tsc2004/20151029-081504
> config: x86_64-randconfig-s1-10291412 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/built-in.o: In function `tsc2005_cmd':
> >> tsc200x-core.c:(.text+0x2ae07f): undefined reference to 
> >> `i2c_smbus_write_byte'

Argh!

How do I fix this one?

> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/