Re: [PATCH v3 6/6] iio: adc: stm32: add support for EXTI trigger

On 02/28/2017 05:51 PM, Fabrice Gasnier wrote: > EXTi (external interrupt) signal can be routed internally as trigger > source for ADC conversions: STM32F4 ADC can use EXTI11. > > Retrieve interrupt trigger from DT, so it can be muxed into ADC IP, > via extsel. Hi, Sorry, I have some trouble

Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one

On 02/28/2017 07:54 PM, Mark Brown wrote: > On Tue, Feb 28, 2017 at 10:24:17AM -0800, Dmitry Torokhov wrote: >> On Tue, Feb 28, 2017 at 09:16:50AM +, Mark Brown wrote: >>> On Mon, Feb 27, 2017 at 08:18:56PM -0800, Dmitry Torokhov wrote: Lists of spi_board_info entries registered with

Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one

On 02/28/2017 07:54 PM, Mark Brown wrote: > On Tue, Feb 28, 2017 at 10:24:17AM -0800, Dmitry Torokhov wrote: >> On Tue, Feb 28, 2017 at 09:16:50AM +, Mark Brown wrote: >>> On Mon, Feb 27, 2017 at 08:18:56PM -0800, Dmitry Torokhov wrote: Lists of spi_board_info entries registered with

Re: [PATCH v2] staging: iio: accel: Move header file content to source file

On 02/28/2017 08:32 PM, SIMRAN SINGHAL wrote: > On Wed, Mar 1, 2017 at 12:53 AM, Jonathan Cameron wrote: >> On 28/02/17 19:17, Jonathan Cameron wrote: >>> On 28/02/17 18:51, simran singhal wrote: The contents of the header file are used only by this single source file.

Re: [PATCH v2] staging: iio: accel: Move header file content to source file

On 02/28/2017 08:32 PM, SIMRAN SINGHAL wrote: > On Wed, Mar 1, 2017 at 12:53 AM, Jonathan Cameron wrote: >> On 28/02/17 19:17, Jonathan Cameron wrote: >>> On 28/02/17 18:51, simran singhal wrote: The contents of the header file are used only by this single source file. Move content into

Re: [PATCH 1/2] dt-bindings: iio: stm32-adc: add option to set resolution

On 02/28/2017 09:21 AM, Fabrice Gasnier wrote: > On 02/25/2017 04:11 PM, Jonathan Cameron wrote: >> On 24/02/17 16:04, Fabrice Gasnier wrote: >>> On 02/19/2017 01:09 PM, Jonathan Cameron wrote: On 15/02/17 16:55, Fabrice Gasnier wrote: > Add documentation for 'st,adc-res' dt optional

Re: [PATCH 1/2] dt-bindings: iio: stm32-adc: add option to set resolution

On 02/28/2017 09:21 AM, Fabrice Gasnier wrote: > On 02/25/2017 04:11 PM, Jonathan Cameron wrote: >> On 24/02/17 16:04, Fabrice Gasnier wrote: >>> On 02/19/2017 01:09 PM, Jonathan Cameron wrote: On 15/02/17 16:55, Fabrice Gasnier wrote: > Add documentation for 'st,adc-res' dt optional

Re: [PATCH v3 4/4] iio: accel: adxl345: Add SPI support

On 02/24/2017 10:12 AM, Eva Rachel Retuya wrote: > On Thu, Feb 23, 2017 at 06:58:12PM +0200, Andy Shevchenko wrote: >> On Thu, Feb 23, 2017 at 6:47 PM, Lars-Peter Clausen <l...@metafoo.de> wrote: >>> On 02/23/2017 05:43 PM, Andy Shevchenko wrote: >>>> On Wed,

Re: [PATCH v3 4/4] iio: accel: adxl345: Add SPI support

On 02/24/2017 10:12 AM, Eva Rachel Retuya wrote: > On Thu, Feb 23, 2017 at 06:58:12PM +0200, Andy Shevchenko wrote: >> On Thu, Feb 23, 2017 at 6:47 PM, Lars-Peter Clausen wrote: >>> On 02/23/2017 05:43 PM, Andy Shevchenko wrote: >>>> On Wed, Feb 22, 2017

Re: [PATCH v3 4/4] iio: accel: adxl345: Add SPI support

On 02/23/2017 05:43 PM, Andy Shevchenko wrote: > On Wed, Feb 22, 2017 at 12:23 PM, Eva Rachel Retuya > wrote: >> Add SPI driver that initializes SPI regmap for the adxl345 core driver. >> The driver supports the same functionality as I2C namely the x, y, z and >> scale

Re: [PATCH v3 4/4] iio: accel: adxl345: Add SPI support

On 02/23/2017 05:43 PM, Andy Shevchenko wrote: > On Wed, Feb 22, 2017 at 12:23 PM, Eva Rachel Retuya > wrote: >> Add SPI driver that initializes SPI regmap for the adxl345 core driver. >> The driver supports the same functionality as I2C namely the x, y, z and >> scale readings. > >> ---

Re: [PATCH v2] iio: adc: xilinx: Fix error handling

On 02/21/2017 07:34 AM, Christophe JAILLET wrote: > Reorder error handling labels in order to match the way resources have > been allocated. > > Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr> Thanks. Acked-by: Lars-Peter Clausen <l...@metafoo.de>

Re: [PATCH v2] iio: adc: xilinx: Fix error handling

On 02/21/2017 07:34 AM, Christophe JAILLET wrote: > Reorder error handling labels in order to match the way resources have > been allocated. > > Signed-off-by: Christophe JAILLET Thanks. Acked-by: Lars-Peter Clausen > --- > v2: update goto label if 'xadc->ops->setup()

Re: [PATCH] iio: adc: xilinx: Fix error handling

On 02/20/2017 09:25 PM, Christophe JAILLET wrote: > Le 20/02/2017 à 09:35, Lars-Peter Clausen a écrit : >> On 02/19/2017 09:29 PM, Christophe JAILLET wrote: >>> Reorder error handling labels in order to match the way resources have >>> been allocated. >>> &

Re: [PATCH] iio: adc: xilinx: Fix error handling

On 02/20/2017 09:25 PM, Christophe JAILLET wrote: > Le 20/02/2017 à 09:35, Lars-Peter Clausen a écrit : >> On 02/19/2017 09:29 PM, Christophe JAILLET wrote: >>> Reorder error handling labels in order to match the way resources have >>> been allocated. >>> &

Re: [PATCH 4/4] iio: accel: adxl345: Add ACPI support

On 02/19/2017 01:15 PM, Eva Rachel Retuya wrote: > On Sun, Feb 19, 2017 at 11:01:23AM +0100, Lars-Peter Clausen wrote: >> On 02/16/2017 11:02 AM, Eva Rachel Retuya wrote: >> [...] >>> @@ -54,9 +55,17 @@ static const struct i2c_device_id adxl345_i2c_id[] = { >>&g

Re: [PATCH 4/4] iio: accel: adxl345: Add ACPI support

On 02/19/2017 01:15 PM, Eva Rachel Retuya wrote: > On Sun, Feb 19, 2017 at 11:01:23AM +0100, Lars-Peter Clausen wrote: >> On 02/16/2017 11:02 AM, Eva Rachel Retuya wrote: >> [...] >>> @@ -54,9 +55,17 @@ static const struct i2c_device_id adxl345_i2c_id[] = { >>&g

Re: [PATCH] iio: adc: xilinx: Fix error handling

On 02/19/2017 09:29 PM, Christophe JAILLET wrote: > Reorder error handling labels in order to match the way resources have > been allocated. > > Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr> Thanks, looks good. Acked-by: Lars-Peter Clausen <l...

Re: [PATCH] iio: adc: xilinx: Fix error handling

On 02/19/2017 09:29 PM, Christophe JAILLET wrote: > Reorder error handling labels in order to match the way resources have > been allocated. > > Signed-off-by: Christophe JAILLET Thanks, looks good. Acked-by: Lars-Peter Clausen I think there is one more issue ret = xadc->

Re: [PATCH 4/4] iio: accel: adxl345: Add ACPI support

On 02/16/2017 11:02 AM, Eva Rachel Retuya wrote: [...] > @@ -54,9 +55,17 @@ static const struct i2c_device_id adxl345_i2c_id[] = { > > MODULE_DEVICE_TABLE(i2c, adxl345_i2c_id); > > +static const struct acpi_device_id adxl345_acpi_id[] = { > + { "ADX0345", 0 }, Who allocated this ID? ADX

Re: [PATCH 4/4] iio: accel: adxl345: Add ACPI support

On 02/16/2017 11:02 AM, Eva Rachel Retuya wrote: [...] > @@ -54,9 +55,17 @@ static const struct i2c_device_id adxl345_i2c_id[] = { > > MODULE_DEVICE_TABLE(i2c, adxl345_i2c_id); > > +static const struct acpi_device_id adxl345_acpi_id[] = { > + { "ADX0345", 0 }, Who allocated this ID? ADX

Re: [RFC 4/4] iio: trigger: add GPIO trigger

On 02/17/2017 05:03 PM, Fabrice Gasnier wrote: > GPIOs can be used to generate triggers for any IIO device. > Introduce generic GPIO trigger driver. It offers some options > to tune polarity (e.g. rising/falling edge), and label so trigger > name may be customized. > By default, gpio triggers will

Re: [RFC 4/4] iio: trigger: add GPIO trigger

On 02/17/2017 05:03 PM, Fabrice Gasnier wrote: > GPIOs can be used to generate triggers for any IIO device. > Introduce generic GPIO trigger driver. It offers some options > to tune polarity (e.g. rising/falling edge), and label so trigger > name may be customized. > By default, gpio triggers will

Re: [PATCH v1 0/2] iio: Add parent_trigger attribute to triggers

On 02/06/2017 03:21 PM, Benjamin Gaignard wrote: > Thoses patches add parent_trigger attribute to IIO triggers. > The goal is to allow triggers to use triggers like is this done for iio > devices. > With this patch it will be possible to chain triggers, for example > stm32 triggers could be used

Re: [PATCH v1 0/2] iio: Add parent_trigger attribute to triggers

On 02/06/2017 03:21 PM, Benjamin Gaignard wrote: > Thoses patches add parent_trigger attribute to IIO triggers. > The goal is to allow triggers to use triggers like is this done for iio > devices. > With this patch it will be possible to chain triggers, for example > stm32 triggers could be used

Re: [PATCH 0/2] iio: pressure: do not rely on structure field ordering

On 02/01/2017 09:09 AM, Peter Rosin wrote: > Hi! > > These two patches are needed to fix some fallout from adding the > available attribute. I put together a quick cocci script to check for other occurrences of this issue and these were the only two drivers affected by the issue.

Re: [PATCH 0/2] iio: pressure: do not rely on structure field ordering

On 02/01/2017 09:09 AM, Peter Rosin wrote: > Hi! > > These two patches are needed to fix some fallout from adding the > available attribute. I put together a quick cocci script to check for other occurrences of this issue and these were the only two drivers affected by the issue.

Re: [PATCH 0/7] gpio: mockup: extensions for testing purposes

On 01/31/2017 03:05 PM, Bartosz Golaszewski wrote: > 2017-01-31 14:28 GMT+01:00 Linus Walleij : >> On Wed, Jan 25, 2017 at 4:34 PM, Bartosz Golaszewski >> wrote: >> >>> This series proposes to extend the gpio framework by allowing to >>> inject

Re: [PATCH 0/7] gpio: mockup: extensions for testing purposes

On 01/31/2017 03:05 PM, Bartosz Golaszewski wrote: > 2017-01-31 14:28 GMT+01:00 Linus Walleij : >> On Wed, Jan 25, 2017 at 4:34 PM, Bartosz Golaszewski >> wrote: >> >>> This series proposes to extend the gpio framework by allowing to >>> inject line events from the kernel code and by providing a

Re: [PATCH 2/2] iio: distance: add devantech us ranger srf04

On 01/29/2017 12:58 AM, Andreas Klinger wrote: > This patch adds support for the ultrasonic ranger srf04 of devantech. Thanks for the patch. Looks mostly good, a few small comments inline. > diff --git a/drivers/iio/proximity/srf04.c b/drivers/iio/proximity/srf04.c > new file mode 100644 > index

Re: [PATCH 2/2] iio: distance: add devantech us ranger srf04

On 01/29/2017 12:58 AM, Andreas Klinger wrote: > This patch adds support for the ultrasonic ranger srf04 of devantech. Thanks for the patch. Looks mostly good, a few small comments inline. > diff --git a/drivers/iio/proximity/srf04.c b/drivers/iio/proximity/srf04.c > new file mode 100644 > index

Re: [PATCH v7 2/4] dmaengine: Forward slave device pointer to of_xlate callback

On 01/25/2017 11:28 AM, Marek Szyprowski wrote: > Add pointer to slave device to of_dma_xlate to let DMA engine driver > to know which slave device is using given DMA channel. This will be > later used to implement non-irq-safe runtime PM for DMA engine driver. of_dma_xlate() is used to translate

Re: [PATCH v7 2/4] dmaengine: Forward slave device pointer to of_xlate callback

On 01/25/2017 11:28 AM, Marek Szyprowski wrote: > Add pointer to slave device to of_dma_xlate to let DMA engine driver > to know which slave device is using given DMA channel. This will be > later used to implement non-irq-safe runtime PM for DMA engine driver. of_dma_xlate() is used to translate

Re: [PATCH v2] iio: trigger: free trigger resource correctly

On 01/22/2017 03:25 PM, Jonathan Cameron wrote: > On 20/01/17 03:47, Alison Schofield wrote: >> These stand-alone trigger drivers were using iio_trigger_put() >> where they should have been using iio_trigger_free(). The >> iio_trigger_put() adds a module_put which is bad since they >> never did a

Re: [PATCH v2] iio: trigger: free trigger resource correctly

On 01/22/2017 03:25 PM, Jonathan Cameron wrote: > On 20/01/17 03:47, Alison Schofield wrote: >> These stand-alone trigger drivers were using iio_trigger_put() >> where they should have been using iio_trigger_free(). The >> iio_trigger_put() adds a module_put which is bad since they >> never did a

Re: [PATCH v2 2/2] iio: distance: srf08: add IIO driver for us ranger

On 01/10/2017 07:48 PM, Andreas Klinger wrote: [...] > + indio_dev->name = dev_name(>dev); The name is supposed to be the type of the device, e.g. part name, not the name of parent device instance. E.g. "srf08" in this case.

Re: [PATCH v2 2/2] iio: distance: srf08: add IIO driver for us ranger

On 01/10/2017 07:48 PM, Andreas Klinger wrote: [...] > + indio_dev->name = dev_name(>dev); The name is supposed to be the type of the device, e.g. part name, not the name of parent device instance. E.g. "srf08" in this case.

Re: [PATCH v9 3/3] iio: adc: add support for Allwinner SoCs ADC

On 12/13/2016 03:33 PM, Quentin Schulz wrote: > + indio_dev->name = dev_name(>dev); The name is supposed to be the type of the device, e.g. part name, not the name of parent device instance. This could e.g. come from a name field in the gpadc_data struct.

Re: [PATCH v9 3/3] iio: adc: add support for Allwinner SoCs ADC

On 12/13/2016 03:33 PM, Quentin Schulz wrote: > + indio_dev->name = dev_name(>dev); The name is supposed to be the type of the device, e.g. part name, not the name of parent device instance. This could e.g. come from a name field in the gpadc_data struct.

Re: [PATCH] spi: spi-axi: Free resources on error path

On 01/09/2017 01:02 AM, Christophe JAILLET wrote: > We should go to 'err_put_master' here instead of returning directly. > Otherwise a call to 'spi_master_put' is missing. > > Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr> Thanks. Acked-by: Lars-Peter Clause

Re: [PATCH] spi: spi-axi: Free resources on error path

On 01/09/2017 01:02 AM, Christophe JAILLET wrote: > We should go to 'err_put_master' here instead of returning directly. > Otherwise a call to 'spi_master_put' is missing. > > Signed-off-by: Christophe JAILLET Thanks. Acked-by: Lars-Peter Clausen > --- > drivers/spi/spi-ax

Re: [PATCH v4] staging: iio: ad7606: replace range/range_available with corresponding scale

uced to hold the available scale values. > > Signed-off-by: Eva Rachel Retuya <eraret...@gmail.com> Looks good, thanks. Acked-by: Lars-Peter Clausen <l...@metafoo.de>

Re: [PATCH v4] staging: iio: ad7606: replace range/range_available with corresponding scale

uced to hold the available scale values. > > Signed-off-by: Eva Rachel Retuya Looks good, thanks. Acked-by: Lars-Peter Clausen

Re: [PATCH v3 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

is OK as is, since it is an improvement over the current situation. But there is still the open issue that we don't know the scale setting if pin is hardwired. I'd like to see that addressed before the driver is moved out of staging. Similar for the oversampling ratio. Consider this Acked-by: Lars-Peter Clausen <l...@metafoo.de>

Re: [PATCH v3 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

nce it is an improvement over the current situation. But there is still the open issue that we don't know the scale setting if pin is hardwired. I'd like to see that addressed before the driver is moved out of staging. Similar for the oversampling ratio. Consider this Acked-by: Lars-Peter Clausen

Re: [PATCH v3 2/2] staging: iio: ad7606: move out of staging

On 12/30/2016 09:16 PM, Jonathan Cameron wrote: > On 11/12/16 02:47, Eva Rachel Retuya wrote: >> Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the >> corresponding Makefile and Kconfig associated with the change. >> >> Signed-off-by: Eva Rachel Retuya >

Re: [PATCH v3 2/2] staging: iio: ad7606: move out of staging

On 12/30/2016 09:16 PM, Jonathan Cameron wrote: > On 11/12/16 02:47, Eva Rachel Retuya wrote: >> Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the >> corresponding Makefile and Kconfig associated with the change. >> >> Signed-off-by: Eva Rachel Retuya > Personally (and this

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

On 12/23/2016 10:07 AM, Geert Uytterhoeven wrote: > BTW, I'm not an IIO expert, but from my limited knowledge, it looks like "O" > support in IIO is limited to DACs? Depends on what you categorize as DACs. There are also potentiometer/rheostat drivers. They are kind of like DACs but the unit you

Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches

On 12/23/2016 10:07 AM, Geert Uytterhoeven wrote: > BTW, I'm not an IIO expert, but from my limited knowledge, it looks like "O" > support in IIO is limited to DACs? Depends on what you categorize as DACs. There are also potentiometer/rheostat drivers. They are kind of like DACs but the unit you

Re: [PATCH] iio: misc: add a generic regulator driver

On 12/23/2016 11:00 AM, Geert Uytterhoeven wrote: > Hi Lars, > > On Mon, Dec 12, 2016 at 6:15 PM, Lars-Peter Clausen <l...@metafoo.de> wrote: >> On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: >>> We're already using libiio to read the measured data from the powe

Re: [PATCH] iio: misc: add a generic regulator driver

On 12/23/2016 11:00 AM, Geert Uytterhoeven wrote: > Hi Lars, > > On Mon, Dec 12, 2016 at 6:15 PM, Lars-Peter Clausen wrote: >> On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: >>> We're already using libiio to read the measured data from the power >>> mon

Re: [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711

On 12/20/2016 11:33 AM, Andreas Klinger wrote: >>> +static struct attribute *hx711_attributes[] = { >>> + _dev_attr_gain.dev_attr.attr, >> >> For IIO devices the gain is typically expressed through the scale attribute. >> Which is kind of the inverse of gain. It would be good if this driver >>

Re: [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711

On 12/20/2016 11:33 AM, Andreas Klinger wrote: >>> +static struct attribute *hx711_attributes[] = { >>> + _dev_attr_gain.dev_attr.attr, >> >> For IIO devices the gain is typically expressed through the scale attribute. >> Which is kind of the inverse of gain. It would be good if this driver >>

Re: [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711

On 12/14/2016 05:17 PM, Andreas Klinger wrote: [...] > +#include > +#include Since you used the consumer API linux/gpio.h is not needed. > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define

Re: [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711

On 12/14/2016 05:17 PM, Andreas Klinger wrote: [...] > +#include > +#include Since you used the consumer API linux/gpio.h is not needed. > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define

Re: [PATCH v2 1/2] iio: adc: hx711: Add DT binding for avia,hx711

On 12/14/2016 11:34 AM, Andreas Klinger wrote: > Hi Lars-Peter, > > Lars-Peter Clausen <l...@metafoo.de> schrieb am Wed, 14. Dec 11:11: >> On 12/14/2016 10:59 AM, Andreas Klinger wrote: >>> Add DT bindings for avia,hx711 >>> Add vendor avia to vendor list

Re: [PATCH v2 1/2] iio: adc: hx711: Add DT binding for avia,hx711

On 12/14/2016 11:34 AM, Andreas Klinger wrote: > Hi Lars-Peter, > > Lars-Peter Clausen schrieb am Wed, 14. Dec 11:11: >> On 12/14/2016 10:59 AM, Andreas Klinger wrote: >>> Add DT bindings for avia,hx711 >>> Add vendor avia to vendor list >&

Re: [PATCH v2 1/2] iio: adc: hx711: Add DT binding for avia,hx711

On 12/14/2016 10:59 AM, Andreas Klinger wrote: > Add DT bindings for avia,hx711 > Add vendor avia to vendor list > > Signed-off-by: Andreas Klinger > --- > .../devicetree/bindings/iio/adc/avia-hx711.txt | 21 > + >

Re: [PATCH v2 1/2] iio: adc: hx711: Add DT binding for avia,hx711

On 12/14/2016 10:59 AM, Andreas Klinger wrote: > Add DT bindings for avia,hx711 > Add vendor avia to vendor list > > Signed-off-by: Andreas Klinger > --- > .../devicetree/bindings/iio/adc/avia-hx711.txt | 21 > + > .../devicetree/bindings/vendor-prefixes.txt |

Re: [PATCH] iio: adc: max1027: allocate DMA-safe buffer

On 12/10/2016 09:53 PM, Marcus Folkesson wrote: > On Sat, Dec 10, 2016 at 05:36:34PM +, Jonathan Cameron wrote: >> On 09/12/16 10:24, Marcus Folkesson wrote: >>> The buffer needs to be DMA-safe when used with spi_read() >>> >>> Signed-off-by: Marcus Folkesson >>

Re: [PATCH] iio: adc: max1027: allocate DMA-safe buffer

On 12/10/2016 09:53 PM, Marcus Folkesson wrote: > On Sat, Dec 10, 2016 at 05:36:34PM +, Jonathan Cameron wrote: >> On 09/12/16 10:24, Marcus Folkesson wrote: >>> The buffer needs to be DMA-safe when used with spi_read() >>> >>> Signed-off-by: Marcus Folkesson >> Please read the documentation

Re: [PATCH] iio: misc: add a generic regulator driver

On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: > 2016-12-03 10:11 GMT+01:00 Jonathan Cameron <ji...@kernel.org>: >> On 30/11/16 10:10, Lars-Peter Clausen wrote: >>> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: >>>> 2016-11-29 16:30 GMT+01:00

Re: [PATCH] iio: misc: add a generic regulator driver

On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: > 2016-12-03 10:11 GMT+01:00 Jonathan Cameron : >> On 30/11/16 10:10, Lars-Peter Clausen wrote: >>> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: >>>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen : >>

Re: [alsa-devel] [PATCH v2 1/1] ALSA: SOC: DMA: access buffer pointer atomically

ned-off-by: Jiada Wang <jiada_w...@mentor.com> Thanks for the patch. Looks good to me. Reviewed-by: Lars-Peter Clausen <l...@metafoo.de> > --- > sound/core/pcm_dmaengine.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/sound/

Re: [alsa-devel] [PATCH v2 1/1] ALSA: SOC: DMA: access buffer pointer atomically

> v2: use READ_ONCE and WRITE_ONCE to ensure read/write of buffer pointer in > only one access > also updates snd_dmaengine_pcm_pointer_no_residue to ensure atomic > access > > Signed-off-by: Andreas Pape > Signed-off-by: Jiada Wang Thanks for the patch. Looks go

Re: [PATCH] IIO: Change msleep to usleep_range for small msecs

On 11/27/2016 11:51 AM, Jonathan Cameron wrote: > On 26/11/16 03:47, Aniroop Mathur wrote: >> msleep(1~20) may not do what the caller intends, and will often sleep longer. >> (~20 ms actual sleep for any value given in the 1~20ms range) >> This is not the desired behaviour for many cases like

Re: [PATCH] IIO: Change msleep to usleep_range for small msecs

On 11/27/2016 11:51 AM, Jonathan Cameron wrote: > On 26/11/16 03:47, Aniroop Mathur wrote: >> msleep(1~20) may not do what the caller intends, and will often sleep longer. >> (~20 ms actual sleep for any value given in the 1~20ms range) >> This is not the desired behaviour for many cases like

Re: [PATCH] iio: misc: add a generic regulator driver

On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: > 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <l...@metafoo.de>: >> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: >> [...] >>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt

Re: [PATCH] iio: misc: add a generic regulator driver

On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: > 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen : >> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: >> [...] >>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt >>> b/Documentation

Re: [PATCH 1/1] ALSA: SOC: DMA: increment buffer pointer atomically

On 11/30/2016 09:36 AM, Lars-Peter Clausen wrote: > On 11/30/2016 09:30 AM, Lars-Peter Clausen wrote: >> On 11/30/2016 09:22 AM, Jiada Wang wrote: >>> From: Andreas Pape <ap...@de.adit-jv.com> >>> >>> Setting pointer and afterwards check for wrap around

Re: [PATCH 1/1] ALSA: SOC: DMA: increment buffer pointer atomically

On 11/30/2016 09:36 AM, Lars-Peter Clausen wrote: > On 11/30/2016 09:30 AM, Lars-Peter Clausen wrote: >> On 11/30/2016 09:22 AM, Jiada Wang wrote: >>> From: Andreas Pape >>> >>> Setting pointer and afterwards check for wrap around leads >>> to the poss

Re: [PATCH 1/1] ALSA: SOC: DMA: increment buffer pointer atomically

On 11/30/2016 09:30 AM, Lars-Peter Clausen wrote: > On 11/30/2016 09:22 AM, Jiada Wang wrote: >> From: Andreas Pape <ap...@de.adit-jv.com> >> >> Setting pointer and afterwards check for wrap around leads >> to the possibility of returning the inconsistent pointer p

Re: [PATCH 1/1] ALSA: SOC: DMA: increment buffer pointer atomically

On 11/30/2016 09:30 AM, Lars-Peter Clausen wrote: > On 11/30/2016 09:22 AM, Jiada Wang wrote: >> From: Andreas Pape >> >> Setting pointer and afterwards check for wrap around leads >> to the possibility of returning the inconsistent pointer position. >> Thi

Re: [PATCH 1/1] ALSA: SOC: DMA: increment buffer pointer atomically

On 11/30/2016 09:22 AM, Jiada Wang wrote: > From: Andreas Pape > > Setting pointer and afterwards check for wrap around leads > to the possibility of returning the inconsistent pointer position. > This patch increments buffer pointer atomically to avoid this issue. Makes

Re: [PATCH 1/1] ALSA: SOC: DMA: increment buffer pointer atomically

On 11/30/2016 09:22 AM, Jiada Wang wrote: > From: Andreas Pape > > Setting pointer and afterwards check for wrap around leads > to the possibility of returning the inconsistent pointer position. > This patch increments buffer pointer atomically to avoid this issue. Makes sense. > >

Re: [PATCH] iio: misc: add a generic regulator driver

On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: [...] > diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt > b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt > new file mode 100644 > index 000..147458f > --- /dev/null > +++

Re: [PATCH] iio: misc: add a generic regulator driver

On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: [...] > diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt > b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt > new file mode 100644 > index 000..147458f > --- /dev/null > +++

Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes

On 11/21/2016 02:17 PM, Peter Rosin wrote: [...] > I have a piece of hardware that is using the same 3 GPIO pins > to control four 8-way muxes. Three of them control ADC lines > to an ADS1015 chip with an iio driver, and the last one > controls the SDA line of an i2c bus. We have some deployed >

Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes

On 11/21/2016 02:17 PM, Peter Rosin wrote: [...] > I have a piece of hardware that is using the same 3 GPIO pins > to control four 8-way muxes. Three of them control ADC lines > to an ADS1015 chip with an iio driver, and the last one > controls the SDA line of an i2c bus. We have some deployed >

Re: [PATCH 5/7] add bindings for stm32 IIO timer drivers

On 11/22/2016 06:01 PM, Benjamin Gaignard wrote: > [snip] >>> + "st,stm32-iio-timer5" >>> + "st,stm32-iio-timer6" >>> + "st,stm32-iio-timer7" >>> + "st,stm32-iio-timer8" >>> + "st,stm32-iio-timer9" >>> + "st,stm32-iio-timer10" >>> + "st,stm32-iio-timer11" >>> +

Re: [PATCH 5/7] add bindings for stm32 IIO timer drivers

On 11/22/2016 06:01 PM, Benjamin Gaignard wrote: > [snip] >>> + "st,stm32-iio-timer5" >>> + "st,stm32-iio-timer6" >>> + "st,stm32-iio-timer7" >>> + "st,stm32-iio-timer8" >>> + "st,stm32-iio-timer9" >>> + "st,stm32-iio-timer10" >>> + "st,stm32-iio-timer11" >>> +

Re: [PATCH 5/7] add bindings for stm32 IIO timer drivers

On 11/22/2016 05:13 PM, Benjamin Gaignard wrote: > Define bindings for stm32 IIO timer > > Signed-off-by: Benjamin Gaignard > --- > .../bindings/iio/timer/stm32-iio-timer.txt | 33 > ++ > 1 file changed, 33 insertions(+) > create mode

Re: [PATCH 5/7] add bindings for stm32 IIO timer drivers

On 11/22/2016 05:13 PM, Benjamin Gaignard wrote: > Define bindings for stm32 IIO timer > > Signed-off-by: Benjamin Gaignard > --- > .../bindings/iio/timer/stm32-iio-timer.txt | 33 > ++ > 1 file changed, 33 insertions(+) > create mode 100644 >

Re: [RFC PATCH v2 3/7] iio: inkern: api for manipulating ext_info of iio channels

On 11/19/2016 04:38 PM, Jonathan Cameron wrote: > On 17/11/16 21:48, Peter Rosin wrote: >> Extend the inkern api with functions for reading and writing ext_info >> of iio channels. > I'd like Lars' feedback on this one. > > Superficially looks fine to me but I am not as familiar with this

Re: [RFC PATCH v2 3/7] iio: inkern: api for manipulating ext_info of iio channels

On 11/19/2016 04:38 PM, Jonathan Cameron wrote: > On 17/11/16 21:48, Peter Rosin wrote: >> Extend the inkern api with functions for reading and writing ext_info >> of iio channels. > I'd like Lars' feedback on this one. > > Superficially looks fine to me but I am not as familiar with this

Re: [RFT v2 2/5] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage

On 11/21/2016 11:30 AM, Sylwester Nawrocki wrote: > On 11/20/2016 08:24 PM, Krzysztof Kozlowski wrote: >> MACH_SMDKC100, MACH_SMDKV210 and MACH_SMDKC110 are no longer supported >> so we can drop the dead code. After this the driver no longer >> differentiates between machines (S3C24xx machines

Re: [RFT v2 2/5] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage

On 11/21/2016 11:30 AM, Sylwester Nawrocki wrote: > On 11/20/2016 08:24 PM, Krzysztof Kozlowski wrote: >> MACH_SMDKC100, MACH_SMDKV210 and MACH_SMDKC110 are no longer supported >> so we can drop the dead code. After this the driver no longer >> differentiates between machines (S3C24xx machines

Re: [PATCH 2/6] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage

On 11/19/2016 04:45 PM, Lars-Peter Clausen wrote: > On 11/19/2016 04:42 PM, Lars-Peter Clausen wrote: >> On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote: >> [...] >>> @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void) >>&g

Re: [PATCH 2/6] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage

On 11/19/2016 04:45 PM, Lars-Peter Clausen wrote: > On 11/19/2016 04:42 PM, Lars-Peter Clausen wrote: >> On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote: >> [...] >>> @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void) >>&g

Re: [PATCH 2/6] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage

On 11/19/2016 04:42 PM, Lars-Peter Clausen wrote: > On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote: > [...] >> @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void) >> int ret; >> char *str; >> >> -if (machine_is_smdkc100() >> -

Re: [PATCH 2/6] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage

On 11/19/2016 04:42 PM, Lars-Peter Clausen wrote: > On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote: > [...] >> @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void) >> int ret; >> char *str; >> >> -if (machine_is_smdkc100() >> -

Re: [PATCH 2/6] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage

On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote: [...] > @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void) > int ret; > char *str; > > - if (machine_is_smdkc100() > - || machine_is_smdkv210() || machine_is_smdkc110()) { > -

Re: [PATCH 2/6] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage

On 11/19/2016 03:48 PM, Krzysztof Kozlowski wrote: [...] > @@ -206,15 +204,10 @@ static int __init smdk_audio_init(void) > int ret; > char *str; > > - if (machine_is_smdkc100() > - || machine_is_smdkv210() || machine_is_smdkc110()) { > -

Re: [RFC PATCH 4/7] dt-bindings: iio: iio-mux: document iio-mux bindings

On 11/17/2016 12:48 AM, Peter Rosin wrote: > --- > .../bindings/iio/multiplexer/iio-mux.txt | 59 > ++ > 1 file changed, 59 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt > > diff --git

Re: [RFC PATCH 4/7] dt-bindings: iio: iio-mux: document iio-mux bindings

On 11/17/2016 12:48 AM, Peter Rosin wrote: > --- > .../bindings/iio/multiplexer/iio-mux.txt | 59 > ++ > 1 file changed, 59 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt > > diff --git

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

On 11/14/2016 05:58 PM, Linus Walleij wrote: > On Sat, Nov 12, 2016 at 3:24 PM, Jonathan Cameron wrote: > >> Is it just me who thought, we need a fixed GPI like a fixed regulator? >> Would allow this sort of fixed wiring to be simply defined. >> >> Linus, worth exploring? > >

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

On 11/14/2016 05:58 PM, Linus Walleij wrote: > On Sat, Nov 12, 2016 at 3:24 PM, Jonathan Cameron wrote: > >> Is it just me who thought, we need a fixed GPI like a fixed regulator? >> Would allow this sort of fixed wiring to be simply defined. >> >> Linus, worth exploring? > > So if fixed

Re: [PATCH v2 3/6] iio: adc: Add support for STM32 ADC

On 11/10/2016 05:18 PM, Fabrice Gasnier wrote: [...] > + static int stm32_adc_single_conv(struct iio_dev *indio_dev, > + const struct iio_chan_spec *chan, > + int *res) > +{ > + struct stm32_adc *adc = iio_priv(indio_dev); > + long

Re: [PATCH v2 3/6] iio: adc: Add support for STM32 ADC

On 11/10/2016 05:18 PM, Fabrice Gasnier wrote: [...] > + static int stm32_adc_single_conv(struct iio_dev *indio_dev, > + const struct iio_chan_spec *chan, > + int *res) > +{ > + struct stm32_adc *adc = iio_priv(indio_dev); > + long

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

On 11/12/2016 03:24 PM, Jonathan Cameron wrote: > On 11/11/16 14:18, Lars-Peter Clausen wrote: >> On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: >>> Eliminate the non-standard attribute in_voltage_range and move its >>> functionality under the scale attribute. rea

<    1   2   3   4   5   6   7   8   9   10   >