Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v6 06/13] IIO: ADC: add sigma delta modulator support
From: Jonathan Cameron @ 2017-12-02 14:54 UTC (permalink / raw)
  To: Arnaud Pouliquen
  Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Jaroslav Kysela, Takashi Iwai,
	Liam Girdwood, Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Maxime Coquelin,
	Alexandre Torgue
In-Reply-To: <1512150020-20335-7-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

On Fri, 1 Dec 2017 18:40:13 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:

> Add generic driver to support sigma delta modulators.
> Typically, this device is hardware connected to
> an IIO device in charge of the conversion. Devices are
> bonded through the hardware consumer API.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
I love this little one ;) Smallest IIO driver yet!
Doesn't technically 'do' anything but that's not the point.

Acked-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

> ---
>  drivers/iio/adc/Kconfig            | 12 ++++++
>  drivers/iio/adc/Makefile           |  1 +
>  drivers/iio/adc/sd_adc_modulator.c | 81 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 94 insertions(+)
>  create mode 100644 drivers/iio/adc/sd_adc_modulator.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 5762565..c5db62f 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -626,6 +626,18 @@ config SPEAR_ADC
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called spear_adc.
>  
> +config SD_ADC_MODULATOR
> +	tristate "Generic sigma delta modulator"
> +	depends on OF
> +	select IIO_BUFFER
> +	select IIO_TRIGGERED_BUFFER
> +	help
> +	  Select this option to enables sigma delta modulator. This driver can
> +	  support generic sigma delta modulators.
> +
> +	  This driver can also be built as a module.  If so, the module
> +	  will be called sd_adc_modulator.
> +
>  config STM32_ADC_CORE
>  	tristate "STMicroelectronics STM32 adc core"
>  	depends on ARCH_STM32 || COMPILE_TEST
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 9874e05..d800325 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -81,3 +81,4 @@ obj-$(CONFIG_VF610_ADC) += vf610_adc.o
>  obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
>  xilinx-xadc-y := xilinx-xadc-core.o xilinx-xadc-events.o
>  obj-$(CONFIG_XILINX_XADC) += xilinx-xadc.o
> +obj-$(CONFIG_SD_ADC_MODULATOR) += sd_adc_modulator.o
> diff --git a/drivers/iio/adc/sd_adc_modulator.c b/drivers/iio/adc/sd_adc_modulator.c
> new file mode 100644
> index 0000000..08bd7b6
> --- /dev/null
> +++ b/drivers/iio/adc/sd_adc_modulator.c
> @@ -0,0 +1,81 @@
> +/*
> + * Generic sigma delta modulator driver
> + *
> + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
> + * Author: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>.
> + *
> + * License type: GPLv2
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/triggered_buffer.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +
> +static const struct iio_info iio_sd_mod_iio_info;
> +
> +static const struct iio_chan_spec iio_sd_mod_ch = {
> +	.type = IIO_VOLTAGE,
> +	.indexed = 1,
> +	.scan_type = {
> +		.sign = 'u',
> +		.realbits = 1,
> +		.shift = 0,
> +	},
> +};
> +
> +static int iio_sd_mod_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct iio_dev *iio;
> +
> +	iio = devm_iio_device_alloc(dev, 0);
> +	if (!iio)
> +		return -ENOMEM;
> +
> +	iio->dev.parent = dev;
> +	iio->dev.of_node = dev->of_node;
> +	iio->name = dev_name(dev);
> +	iio->info = &iio_sd_mod_iio_info;
> +	iio->modes = INDIO_BUFFER_HARDWARE;
> +
> +	iio->num_channels = 1;
> +	iio->channels = &iio_sd_mod_ch;
> +
> +	platform_set_drvdata(pdev, iio);
> +
> +	return devm_iio_device_register(&pdev->dev, iio);
> +}
> +
> +static const struct of_device_id sd_adc_of_match[] = {
> +	{ .compatible = "sd-modulator" },
> +	{ .compatible = "ads1201" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, sd_adc_of_match);
> +
> +static struct platform_driver iio_sd_mod_adc = {
> +	.driver = {
> +		.name = "iio_sd_adc_mod",
> +		.of_match_table = of_match_ptr(sd_adc_of_match),
> +	},
> +	.probe = iio_sd_mod_probe,
> +};
> +
> +module_platform_driver(iio_sd_mod_adc);
> +
> +MODULE_DESCRIPTION("Basic sigma delta modulator");
> +MODULE_AUTHOR("Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>");
> +MODULE_LICENSE("GPL v2");

^ permalink raw reply

* Re: [PATCH v6 05/13] IIO: Add DT bindings for sigma delta adc modulator
From: Jonathan Cameron @ 2017-12-02 14:52 UTC (permalink / raw)
  To: Arnaud Pouliquen
  Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Jaroslav Kysela, Takashi Iwai,
	Liam Girdwood, Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Maxime Coquelin,
	Alexandre Torgue
In-Reply-To: <1512150020-20335-6-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

On Fri, 1 Dec 2017 18:40:12 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:

> Add documentation of device tree bindings to support
> sigma delta modulator in IIO framework.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Acked-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

> ---
>  .../devicetree/bindings/iio/adc/sigma-delta-modulator.txt   | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
> new file mode 100644
> index 0000000..e9ebb8a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
> @@ -0,0 +1,13 @@
> +Device-Tree bindings for sigma delta modulator
> +
> +Required properties:
> +- compatible: should be "ads1201", "sd-modulator". "sd-modulator" can be use
> +	as a generic SD modulator if modulator not specified in compatible list.
> +- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers".
> +
> +Example node:
> +
> +	ads1202: adc@0 {
> +		compatible = "sd-modulator";
> +		#io-channel-cells = <1>;
> +	};

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

^ permalink raw reply

* Re: [PATCH v6 03/13] IIO: hw_consumer: add devm_iio_hw_consumer_alloc
From: Jonathan Cameron @ 2017-12-02 14:52 UTC (permalink / raw)
  To: Arnaud Pouliquen
  Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Jaroslav Kysela, Takashi Iwai,
	Liam Girdwood, Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Maxime Coquelin,
	Alexandre Torgue
In-Reply-To: <1512150020-20335-4-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

On Fri, 1 Dec 2017 18:40:10 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:

> Add devm_iio_hw_consumer_alloc function that calls iio_hw_consumer_free
> when the device is unbound from the bus.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

Reviewed-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

> ---
>  drivers/iio/buffer/industrialio-hw-consumer.c | 66 +++++++++++++++++++++++++++
>  include/linux/iio/hw-consumer.h               |  2 +
>  2 files changed, 68 insertions(+)
> 
> diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
> index 0253be1..e980a79 100644
> --- a/drivers/iio/buffer/industrialio-hw-consumer.c
> +++ b/drivers/iio/buffer/industrialio-hw-consumer.c
> @@ -138,6 +138,72 @@ void iio_hw_consumer_free(struct iio_hw_consumer *hwc)
>  }
>  EXPORT_SYMBOL_GPL(iio_hw_consumer_free);
>  
> +static void devm_iio_hw_consumer_release(struct device *dev, void *res)
> +{
> +	iio_hw_consumer_free(*(struct iio_hw_consumer **)res);
> +}
> +
> +static int devm_iio_hw_consumer_match(struct device *dev, void *res, void *data)
> +{
> +	struct iio_hw_consumer **r = res;
> +
> +	if (!r || !*r) {
> +		WARN_ON(!r || !*r);
> +		return 0;
> +	}
> +	return *r == data;
> +}
> +
> +/**
> + * devm_iio_hw_consumer_alloc - Resource-managed iio_hw_consumer_alloc()
> + * @dev: Pointer to consumer device.
> + *
> + * Managed iio_hw_consumer_alloc. iio_hw_consumer allocated with this function
> + * is automatically freed on driver detach.
> + *
> + * If an iio_hw_consumer allocated with this function needs to be freed
> + * separately, devm_iio_hw_consumer_free() must be used.
> + *
> + * returns pointer to allocated iio_hw_consumer on success, NULL on failure.
> + */
> +struct iio_hw_consumer *devm_iio_hw_consumer_alloc(struct device *dev)
> +{
> +	struct iio_hw_consumer **ptr, *iio_hwc;
> +
> +	ptr = devres_alloc(devm_iio_hw_consumer_release, sizeof(*ptr),
> +			   GFP_KERNEL);
> +	if (!ptr)
> +		return NULL;
> +
> +	iio_hwc = iio_hw_consumer_alloc(dev);
> +	if (IS_ERR(iio_hwc)) {
> +		devres_free(ptr);
> +	} else {
> +		*ptr = iio_hwc;
> +		devres_add(dev, ptr);
> +	}
> +
> +	return iio_hwc;
> +}
> +EXPORT_SYMBOL_GPL(devm_iio_hw_consumer_alloc);
> +
> +/**
> + * devm_iio_hw_consumer_free - Resource-managed iio_hw_consumer_free()
> + * @dev: Pointer to consumer device.
> + * @hwc: iio_hw_consumer to free.
> + *
> + * Free iio_hw_consumer allocated with devm_iio_hw_consumer_alloc().
> + */
> +void devm_iio_hw_consumer_free(struct device *dev, struct iio_hw_consumer *hwc)
> +{
> +	int rc;
> +
> +	rc = devres_release(dev, devm_iio_hw_consumer_release,
> +			    devm_iio_hw_consumer_match, hwc);
> +	WARN_ON(rc);
> +}
> +EXPORT_SYMBOL_GPL(devm_iio_hw_consumer_free);
> +
>  /**
>   * iio_hw_consumer_enable() - Enable IIO hardware consumer
>   * @hwc: iio_hw_consumer to enable.
> diff --git a/include/linux/iio/hw-consumer.h b/include/linux/iio/hw-consumer.h
> index f16791b..90ecfce 100644
> --- a/include/linux/iio/hw-consumer.h
> +++ b/include/linux/iio/hw-consumer.h
> @@ -14,6 +14,8 @@ struct iio_hw_consumer;
>  
>  struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev);
>  void iio_hw_consumer_free(struct iio_hw_consumer *hwc);
> +struct iio_hw_consumer *devm_iio_hw_consumer_alloc(struct device *dev);
> +void devm_iio_hw_consumer_free(struct device *dev, struct iio_hw_consumer *hwc);
>  int iio_hw_consumer_enable(struct iio_hw_consumer *hwc);
>  void iio_hw_consumer_disable(struct iio_hw_consumer *hwc);
>  

^ permalink raw reply

* Re: [PATCH v6 02/13] docs: driver-api: add iio hw consumer section
From: Jonathan Cameron @ 2017-12-02 14:51 UTC (permalink / raw)
  To: Arnaud Pouliquen
  Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Jaroslav Kysela, Takashi Iwai,
	Liam Girdwood, Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Maxime Coquelin,
	Alexandre Torgue
In-Reply-To: <1512150020-20335-3-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

On Fri, 1 Dec 2017 18:40:09 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:

> This adds a section about the Hardware consumer
> API of the IIO subsystem to the driver API
> documentation.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

Reviewed-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

> ---
>  Documentation/driver-api/iio/hw-consumer.rst | 51 ++++++++++++++++++++++++++++
>  Documentation/driver-api/iio/index.rst       |  1 +
>  2 files changed, 52 insertions(+)
>  create mode 100644 Documentation/driver-api/iio/hw-consumer.rst
> 
> diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
> new file mode 100644
> index 0000000..8facce6
> --- /dev/null
> +++ b/Documentation/driver-api/iio/hw-consumer.rst
> @@ -0,0 +1,51 @@
> +===========
> +HW consumer
> +===========
> +An IIO device can be directly connected to another device in hardware. in this
> +case the buffers between IIO provider and IIO consumer are handled by hardware.
> +The Industrial I/O HW consumer offers a way to bond these IIO devices without
> +software buffer for data. The implementation can be found under
> +:file:`drivers/iio/buffer/hw-consumer.c`
> +
> +
> +* struct :c:type:`iio_hw_consumer` — Hardware consumer structure
> +* :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer
> +* :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer
> +* :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer
> +* :c:func:`iio_hw_consumer_disable` — Disable IIO hardware consumer
> +
> +
> +HW consumer setup
> +=================
> +
> +As standard IIO device the implementation is based on IIO provider/consumer.
> +A typical IIO HW consumer setup looks like this::
> +
> +	static struct iio_hw_consumer *hwc;
> +
> +	static const struct iio_info adc_info = {
> +		.read_raw = adc_read_raw,
> +	};
> +
> +	static int adc_read_raw(struct iio_dev *indio_dev,
> +				struct iio_chan_spec const *chan, int *val,
> +				int *val2, long mask)
> +	{
> +		ret = iio_hw_consumer_enable(hwc);
> +
> +		/* Acquire data */
> +
> +		ret = iio_hw_consumer_disable(hwc);
> +	}
> +
> +	static int adc_probe(struct platform_device *pdev)
> +	{
> +		hwc = devm_iio_hw_consumer_alloc(&iio->dev);
> +	}
> +
> +More details
> +============
> +.. kernel-doc:: include/linux/iio/hw-consumer.h
> +.. kernel-doc:: drivers/iio/buffer/industrialio-hw-consumer.c
> +   :export:
> +
> diff --git a/Documentation/driver-api/iio/index.rst b/Documentation/driver-api/iio/index.rst
> index e5c3922..7fba341 100644
> --- a/Documentation/driver-api/iio/index.rst
> +++ b/Documentation/driver-api/iio/index.rst
> @@ -15,3 +15,4 @@ Contents:
>     buffers
>     triggers
>     triggered-buffers
> +   hw-consumer

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

^ permalink raw reply

* Re: [PATCH v6 01/13] iio: Add hardware consumer buffer support
From: Jonathan Cameron @ 2017-12-02 14:50 UTC (permalink / raw)
  To: Arnaud Pouliquen
  Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Jaroslav Kysela, Takashi Iwai,
	Liam Girdwood, Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Maxime Coquelin,
	Alexandre Torgue
In-Reply-To: <1512150020-20335-2-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

On Fri, 1 Dec 2017 18:40:08 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:

> From: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
> 
> Hardware consumer interface can be used when one IIO device has
> a direct connection to another device in hardware.

Given I'm not totally sure who will do the immutable branch I'm going
to starting adding tags to make it clear what I'm happy with.
(might rip them off again if I end up handling the final merge)
> 
> Signed-off-by: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

Reviewed-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

> ---
>  drivers/iio/buffer/Kconfig                    |  10 ++
>  drivers/iio/buffer/Makefile                   |   1 +
>  drivers/iio/buffer/industrialio-hw-consumer.c | 182 ++++++++++++++++++++++++++
>  include/linux/iio/hw-consumer.h               |  20 +++
>  4 files changed, 213 insertions(+)
>  create mode 100644 drivers/iio/buffer/industrialio-hw-consumer.c
>  create mode 100644 include/linux/iio/hw-consumer.h
> 
> diff --git a/drivers/iio/buffer/Kconfig b/drivers/iio/buffer/Kconfig
> index 4ffd3db..338774c 100644
> --- a/drivers/iio/buffer/Kconfig
> +++ b/drivers/iio/buffer/Kconfig
> @@ -29,6 +29,16 @@ config IIO_BUFFER_DMAENGINE
>  
>  	  Should be selected by drivers that want to use this functionality.
>  
> +config IIO_BUFFER_HW_CONSUMER
> +	tristate "Industrial I/O HW buffering"
> +	help
> +	  Provides a way to bonding when an IIO device has a direct connection
> +	  to another device in hardware. In this case buffers for data transfers
> +	  are handled by hardware.
> +
> +	  Should be selected by drivers that want to use the generic Hw consumer
> +	  interface.
> +
>  config IIO_KFIFO_BUF
>  	tristate "Industrial I/O buffering based on kfifo"
>  	help
> diff --git a/drivers/iio/buffer/Makefile b/drivers/iio/buffer/Makefile
> index 85beaae..324a36b 100644
> --- a/drivers/iio/buffer/Makefile
> +++ b/drivers/iio/buffer/Makefile
> @@ -6,5 +6,6 @@
>  obj-$(CONFIG_IIO_BUFFER_CB) += industrialio-buffer-cb.o
>  obj-$(CONFIG_IIO_BUFFER_DMA) += industrialio-buffer-dma.o
>  obj-$(CONFIG_IIO_BUFFER_DMAENGINE) += industrialio-buffer-dmaengine.o
> +obj-$(CONFIG_IIO_BUFFER_HW_CONSUMER) += industrialio-hw-consumer.o
>  obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
>  obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
> diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
> new file mode 100644
> index 0000000..0253be1
> --- /dev/null
> +++ b/drivers/iio/buffer/industrialio-hw-consumer.c
> @@ -0,0 +1,182 @@
> +/*
> + * Copyright 2017 Analog Devices Inc.
> + *  Author: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
> + *
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/consumer.h>
> +#include <linux/iio/hw-consumer.h>
> +#include <linux/iio/buffer_impl.h>
> +
> +/**
> + * struct iio_hw_consumer - IIO hw consumer block
> + * @buffers: hardware buffers list head.
> + * @channels: IIO provider channels.
> + */
> +struct iio_hw_consumer {
> +	struct list_head buffers;
> +	struct iio_channel *channels;
> +};
> +
> +struct hw_consumer_buffer {
> +	struct list_head head;
> +	struct iio_dev *indio_dev;
> +	struct iio_buffer buffer;
> +	long scan_mask[];
> +};
> +
> +static struct hw_consumer_buffer *iio_buffer_to_hw_consumer_buffer(
> +	struct iio_buffer *buffer)
> +{
> +	return container_of(buffer, struct hw_consumer_buffer, buffer);
> +}
> +
> +static void iio_hw_buf_release(struct iio_buffer *buffer)
> +{
> +	struct hw_consumer_buffer *hw_buf =
> +		iio_buffer_to_hw_consumer_buffer(buffer);
> +	kfree(hw_buf);
> +}
> +
> +static const struct iio_buffer_access_funcs iio_hw_buf_access = {
> +	.release = &iio_hw_buf_release,
> +	.modes = INDIO_BUFFER_HARDWARE,
> +};
> +
> +static struct hw_consumer_buffer *iio_hw_consumer_get_buffer(
> +	struct iio_hw_consumer *hwc, struct iio_dev *indio_dev)
> +{
> +	size_t mask_size = BITS_TO_LONGS(indio_dev->masklength) * sizeof(long);
> +	struct hw_consumer_buffer *buf;
> +
> +	list_for_each_entry(buf, &hwc->buffers, head) {
> +		if (buf->indio_dev == indio_dev)
> +			return buf;
> +	}
> +
> +	buf = kzalloc(sizeof(*buf) + mask_size, GFP_KERNEL);
> +	if (!buf)
> +		return NULL;
> +
> +	buf->buffer.access = &iio_hw_buf_access;
> +	buf->indio_dev = indio_dev;
> +	buf->buffer.scan_mask = buf->scan_mask;
> +
> +	iio_buffer_init(&buf->buffer);
> +	list_add_tail(&buf->head, &hwc->buffers);
> +
> +	return buf;
> +}
> +
> +/**
> + * iio_hw_consumer_alloc() - Allocate IIO hardware consumer
> + * @dev: Pointer to consumer device.
> + *
> + * Returns a valid iio_hw_consumer on success or a ERR_PTR() on failure.
> + */
> +struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev)
> +{
> +	struct hw_consumer_buffer *buf;
> +	struct iio_hw_consumer *hwc;
> +	struct iio_channel *chan;
> +	int ret;
> +
> +	hwc = kzalloc(sizeof(*hwc), GFP_KERNEL);
> +	if (!hwc)
> +		return ERR_PTR(-ENOMEM);
> +
> +	INIT_LIST_HEAD(&hwc->buffers);
> +
> +	hwc->channels = iio_channel_get_all(dev);
> +	if (IS_ERR(hwc->channels)) {
> +		ret = PTR_ERR(hwc->channels);
> +		goto err_free_hwc;
> +	}
> +
> +	chan = &hwc->channels[0];
> +	while (chan->indio_dev) {
> +		buf = iio_hw_consumer_get_buffer(hwc, chan->indio_dev);
> +		if (!buf) {
> +			ret = -ENOMEM;
> +			goto err_put_buffers;
> +		}
> +		set_bit(chan->channel->scan_index, buf->buffer.scan_mask);
> +		chan++;
> +	}
> +
> +	return hwc;
> +
> +err_put_buffers:
> +	list_for_each_entry(buf, &hwc->buffers, head)
> +		iio_buffer_put(&buf->buffer);
> +	iio_channel_release_all(hwc->channels);
> +err_free_hwc:
> +	kfree(hwc);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(iio_hw_consumer_alloc);
> +
> +/**
> + * iio_hw_consumer_free() - Free IIO hardware consumer
> + * @hwc: hw consumer to free.
> + */
> +void iio_hw_consumer_free(struct iio_hw_consumer *hwc)
> +{
> +	struct hw_consumer_buffer *buf, *n;
> +
> +	iio_channel_release_all(hwc->channels);
> +	list_for_each_entry_safe(buf, n, &hwc->buffers, head)
> +		iio_buffer_put(&buf->buffer);
> +	kfree(hwc);
> +}
> +EXPORT_SYMBOL_GPL(iio_hw_consumer_free);
> +
> +/**
> + * iio_hw_consumer_enable() - Enable IIO hardware consumer
> + * @hwc: iio_hw_consumer to enable.
> + *
> + * Returns 0 on success.
> + */
> +int iio_hw_consumer_enable(struct iio_hw_consumer *hwc)
> +{
> +	struct hw_consumer_buffer *buf;
> +	int ret;
> +
> +	list_for_each_entry(buf, &hwc->buffers, head) {
> +		ret = iio_update_buffers(buf->indio_dev, &buf->buffer, NULL);
> +		if (ret)
> +			goto err_disable_buffers;
> +	}
> +
> +	return 0;
> +
> +err_disable_buffers:
> +	list_for_each_entry_continue_reverse(buf, &hwc->buffers, head)
> +		iio_update_buffers(buf->indio_dev, NULL, &buf->buffer);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(iio_hw_consumer_enable);
> +
> +/**
> + * iio_hw_consumer_disable() - Disable IIO hardware consumer
> + * @hwc: iio_hw_consumer to disable.
> + */
> +void iio_hw_consumer_disable(struct iio_hw_consumer *hwc)
> +{
> +	struct hw_consumer_buffer *buf;
> +
> +	list_for_each_entry(buf, &hwc->buffers, head)
> +		iio_update_buffers(buf->indio_dev, NULL, &buf->buffer);
> +}
> +EXPORT_SYMBOL_GPL(iio_hw_consumer_disable);
> +
> +MODULE_AUTHOR("Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>");
> +MODULE_DESCRIPTION("Hardware consumer buffer the IIO framework");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/iio/hw-consumer.h b/include/linux/iio/hw-consumer.h
> new file mode 100644
> index 0000000..f16791b
> --- /dev/null
> +++ b/include/linux/iio/hw-consumer.h
> @@ -0,0 +1,20 @@
> +/*
> + * Industrial I/O in kernel hardware consumer interface
> + *
> + * Copyright 2017 Analog Devices Inc.
> + *  Author: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
> + *
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#ifndef LINUX_IIO_HW_CONSUMER_H
> +#define LINUX_IIO_HW_CONSUMER_H
> +
> +struct iio_hw_consumer;
> +
> +struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev);
> +void iio_hw_consumer_free(struct iio_hw_consumer *hwc);
> +int iio_hw_consumer_enable(struct iio_hw_consumer *hwc);
> +void iio_hw_consumer_disable(struct iio_hw_consumer *hwc);
> +
> +#endif

^ permalink raw reply

* Re: [PATCH v6 04/13] IIO: inkern: API for manipulating channel attributes
From: Jonathan Cameron @ 2017-12-02 14:46 UTC (permalink / raw)
  To: Arnaud Pouliquen
  Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Jaroslav Kysela, Takashi Iwai,
	Liam Girdwood, Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Maxime Coquelin,
	Alexandre Torgue
In-Reply-To: <1512150020-20335-5-git-send-email-arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>

On Fri, 1 Dec 2017 18:40:11 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:

> Extend the inkern API with functions for reading and writing
> attribute of iio channels.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
> ---
> V5 to V6 update:
>  Replace include type.h with iio.h to fix build warning

Except don't do that.   Consumers should not be able to see the internals
of iio devices..  Hence instead, move the required enum to types.h please.

One other passing comment inline (not one I'm expecting you to do anything
about!).  Otherwise this is fine with me.

Thanks,

Jonathan

> 
>  drivers/iio/inkern.c         | 18 +++++++++++++-----
>  include/linux/iio/consumer.h | 28 +++++++++++++++++++++++++++-
>  2 files changed, 40 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> index 069defc..f2e7824 100644
> --- a/drivers/iio/inkern.c
> +++ b/drivers/iio/inkern.c
> @@ -664,9 +664,8 @@ int iio_convert_raw_to_processed(struct iio_channel *chan, int raw,
>  }
>  EXPORT_SYMBOL_GPL(iio_convert_raw_to_processed);
>  
> -static int iio_read_channel_attribute(struct iio_channel *chan,
> -				      int *val, int *val2,
> -				      enum iio_chan_info_enum attribute)
> +int iio_read_channel_attribute(struct iio_channel *chan, int *val, int *val2,
> +			       enum iio_chan_info_enum attribute)
>  {
>  	int ret;
>  
> @@ -682,6 +681,8 @@ static int iio_read_channel_attribute(struct iio_channel *chan,
>  
>  	return ret;
>  }
> +EXPORT_SYMBOL_GPL(iio_read_channel_attribute);
> +
>  
>  int iio_read_channel_offset(struct iio_channel *chan, int *val, int *val2)
>  {
> @@ -850,7 +851,8 @@ static int iio_channel_write(struct iio_channel *chan, int val, int val2,
>  						chan->channel, val, val2, info);
>  }
>  
> -int iio_write_channel_raw(struct iio_channel *chan, int val)
> +int iio_write_channel_attribute(struct iio_channel *chan, int val, int val2,
> +				enum iio_chan_info_enum attribute)
>  {
>  	int ret;
>  
> @@ -860,12 +862,18 @@ int iio_write_channel_raw(struct iio_channel *chan, int val)
>  		goto err_unlock;
>  	}
>  
> -	ret = iio_channel_write(chan, val, 0, IIO_CHAN_INFO_RAW);
> +	ret = iio_channel_write(chan, val, val2, attribute);
>  err_unlock:
>  	mutex_unlock(&chan->indio_dev->info_exist_lock);
>  
>  	return ret;
>  }
> +EXPORT_SYMBOL_GPL(iio_write_channel_attribute);
> +
> +int iio_write_channel_raw(struct iio_channel *chan, int val)
> +{
> +	return iio_write_channel_attribute(chan, val, 0, IIO_CHAN_INFO_RAW);
> +}
>  EXPORT_SYMBOL_GPL(iio_write_channel_raw);
>  
>  unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
> diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
> index 5e347a9..70658b1 100644
> --- a/include/linux/iio/consumer.h
> +++ b/include/linux/iio/consumer.h
> @@ -11,7 +11,7 @@
>  #define _IIO_INKERN_CONSUMER_H_
>  
>  #include <linux/types.h>
> -#include <linux/iio/types.h>
> +#include <linux/iio/iio.h>

Hmm. Not keen on this include as it just exposed the internals
to IIO consumers which we really don't want to do.

This is to allow access to the enum iio_chan_info_enum?
Move it to types.h please.

>  
>  struct iio_dev;
>  struct iio_chan_spec;
> @@ -216,6 +216,32 @@ int iio_read_channel_average_raw(struct iio_channel *chan, int *val);
>  int iio_read_channel_processed(struct iio_channel *chan, int *val);
>  
>  /**
> + * iio_write_channel_attribute() - Write values to the device attribute.
> + * @chan:	The channel being queried.
> + * @val:	Value being written.
> + * @val2:	Value being written.val2 use depends on attribute type.
> + * @attribute:	info attribute to be read.
> + *
> + * Returns an error code or 0.
> + */
> +int iio_write_channel_attribute(struct iio_channel *chan, int val,
> +				int val2, enum iio_chan_info_enum attribute);
> +
> +/**
> + * iio_read_channel_attribute() - Read values from the device attribute.
> + * @chan:	The channel being queried.
> + * @val:	Value being written.
> + * @val2:	Value being written.Val2 use depends on attribute type.

This pretty much highlights that we are still missing a function to allow us
to query what form write data should be presented in...

Here we have tightly coupled hardware so we know the answer, but in general
we don't.

Still can be a follow up patch when someone needs it.

> + * @attribute:	info attribute to be written.
> + *
> + * Returns an error code if failed. Else returns a description of what is in val
> + * and val2, such as IIO_VAL_INT_PLUS_MICRO telling us we have a value of val
> + * + val2/1e6
> + */
> +int iio_read_channel_attribute(struct iio_channel *chan, int *val,
> +			       int *val2, enum iio_chan_info_enum attribute);
> +
> +/**
>   * iio_write_channel_raw() - write to a given channel
>   * @chan:		The channel being queried.
>   * @val:		Value being written.

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

^ permalink raw reply

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
From: Linus Walleij @ 2017-12-02 12:56 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Andrew Lunn, Vivien Didelot, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <f9bfa1e1-7f05-1e2b-6663-09d4d3bf6a12@gmail.com>

On Thu, Nov 30, 2017 at 12:26 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 11/29/2017 03:19 PM, Linus Walleij wrote:

>> Or are there in pracice things such that reg is different
>> on the port and the PHY connected to it? Then it makes
>> much sense to put an MDIO bus inside the switch DT
>> node and populate the PHY interrupts from there as you
>> say.
>
> Yes, I have such systems here, Port 0 has its PHY at MDIO address 5 for
> instance.

That explains it.

> switch@0 {
>         compatible = "acme,switch";
>         #address-cells = <1>;
>         #size-cells = <0>;
>
>         ports {
>
>                 port@0 {
>                         reg = <0>;
>                         phy-handle = <&phy0>;
>                 };
>
>                 port@1 {
>                         reg = <1>;
>                         phy-handle = <&phy1>;
>                 };
>
>                 port@8 {
>                         reg = <8>;
>                         ethernet = = <&eth0>;
>                 };
>         };
>
>         mdio {
>                 compatible = "acme,switch-mdio";
>
>                 phy@0 {
>                         reg = <0>;
>                 };
>
>                 phy@1 {
>                         reg = <1>;
>                 };
>         };
> };
>
> That way it's clear which port maps to which PHY, and that the MDIO
> controller is internal within the switch (and so are the PHYs).

So why not:

switch@0 {
        compatible = "acme,switch";
        #address-cells = <1>;
        #size-cells = <0>;

        ports {

                port@0 {
                        reg = <0>;
                        phy@0 {
                             reg = <0>;
                        };
                };

                port@1 {
                        reg = <1>;
                        phy@1 {
                             reg = <1>;
                        };
                };

                port@8 {
                        reg = <8>;
                        ethernet = = <&eth0>;
                };
        };

This avoids the cross-referencing of phandles.

Yours,
Linus Walleii

^ permalink raw reply

* Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power
From: Linus Walleij @ 2017-12-02 12:48 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Tony Lindgren, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
	Mark Rutland,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, Charles Keepax, Charles Keepax, Stephen Warren,
	Andy Shevchenko, Al Cooper, bcm-kernel-feedback-list
In-Reply-To: <96cf5d74-3acf-07b9-9ad8-1011cd99a860-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Wed, Nov 29, 2017 at 6:37 PM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 11/29/2017 09:02 AM, Tony Lindgren wrote:

>> Hmm well typically a device driver that loses it's context just does
>> save and restore of the registers in runtime PM suspend/resume
>> as needed. In this case it would mean duplicating the state for
>> potentially for hundreds of registers.. So using the existing
>> state in the pinctrl subsystem totally makes sense for the pins.
>>
>> Florian do you have other reasons why this should be done in the
>> pinctrl framework instead of the driver? Might be worth describing
>> the reasoning in the patch descriptions :)
>
> The pinctrl provider driver that I am using is pinctrl-single, which has
> proper suspend/resume callbacks but those are not causing any HW
> programming to happen because of the (p->state == state) check, hence
> this patch series.

So we are talking about these callbacks, correct?

#ifdef CONFIG_PM
static int pinctrl_single_suspend(struct platform_device *pdev,
                                        pm_message_t state)
{
        struct pcs_device *pcs;

        pcs = platform_get_drvdata(pdev);
        if (!pcs)
                return -EINVAL;

        return pinctrl_force_sleep(pcs->pctl);
}

static int pinctrl_single_resume(struct platform_device *pdev)
{
        struct pcs_device *pcs;

        pcs = platform_get_drvdata(pdev);
        if (!pcs)
                return -EINVAL;

        return pinctrl_force_default(pcs->pctl);
}
#endif

Which falls through to this:

/**
 * pinctrl_force_sleep() - turn a given controller device into sleep state
 * @pctldev: pin controller device
 */
int pinctrl_force_sleep(struct pinctrl_dev *pctldev)
{
        if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_sleep))
                return pinctrl_select_state(pctldev->p, pctldev->hog_sleep);
        return 0;
}
EXPORT_SYMBOL_GPL(pinctrl_force_sleep);

/**
 * pinctrl_force_default() - turn a given controller device into default state
 * @pctldev: pin controller device
 */
int pinctrl_force_default(struct pinctrl_dev *pctldev)
{
        if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_default))
                return pinctrl_select_state(pctldev->p, pctldev->hog_default);
        return 0;
}
EXPORT_SYMBOL_GPL(pinctrl_force_default);

So am I right in assuming it is actually the hogs that is your biggest
problem, and those are the states that get lost over suspend/resume
that are especially problematic?

I.e. you don't have any problem with any non-hogged pinctrl
handles, those are handled just fine in the suspend/resume
paths of the client drivers?

If this is the case, it changes the problem scope slightly.

It is fair that functions named *force* should actually enforce
programming a state.

So then I would suggest somethin else: break pinctrl_select_state()
into two:

pinctrl_select_state() that works just like before, checking if
(p->state == state) but which calls a static function
pinctrl_select_state_commit() that commits the change unconditonally.
Then alter pinctrl_force_sleep() and pinctrl_force_sleep() to call
that function.

This should solve your problem without having to alter the semantics
of pinctrl_select_state() for everyone.

If you want I can cook a patch to illustrate what I mean so you can
try it.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v6 03/17] mfd: madera: Add common support for Cirrus Logic Madera codecs
From: Linus Walleij @ 2017-12-02 12:10 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: Lee Jones, Mark Brown, Alexandre Courbot, Rob Herring,
	Thomas Gleixner, Jason Cooper, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	open list:WOLFSON MICROELECTRONICS DRIVERS,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Charles Keepax, Nikesh Oswal
In-Reply-To: <1eff5a38-cff3-449b-bda4-047f50a9f1d4-MRjWshV2NDGMZzV0eMwobdBPR1lH4CV8@public.gmane.org>

On Wed, Nov 29, 2017 at 12:36 PM, Richard Fitzgerald
<rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> On 29/11/17 10:18, Linus Walleij wrote:
>>
>> On Thu, Nov 23, 2017 at 6:13 PM, Richard Fitzgerald
>> <rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
>>
>>> +config MFD_MADERA_I2C
>>> +       bool "Cirrus Logic Madera codecs with I2C"
>>> +       select MFD_MADERA
>>> +       select REGMAP_I2C
>>> +       depends on I2C
>>> +       depends on PINCTRL
>>> +       help
>>> +         Support for the Cirrus Logic Madera platform audio SoC
>>> +         core functionality controlled via I2C.
>>> +
>>> +config MFD_MADERA_SPI
>>> +       bool "Cirrus Logic Madera codecs with SPI"
>>> +       select MFD_MADERA
>>> +       select REGMAP_SPI
>>> +       depends on SPI_MASTER
>>> +       depends on PINCTRL
>>> +       help
>>> +         Support for the Cirrus Logic Madera platform audio SoC
>>> +         core functionality controlled via SPI.
>>
>>
>> Why do the I2C and SPI subdrivers depend on PINCTRL?
>>
>> They sure don't seem to be using any pinctrl-specific APIs.
>>
>
> They require PINCTRL even if they don't call any functions on it because the
> chip won't work correctly if there isn't a PINCTRL driver to apply the
> correct pinmux configuration.

Apply the configuration to what? Sorry I don't get it.

You can't be referring to the internal pin controller of the Madera, since
that has to come up before its pin controller can even be communicated
with.

If you mean it is to apply the configuration to the system SoC where
this coded is connected, this is wrong. There may very well be systems
which have dedicated pins for the codec, atleast in theory. The fact
that your reference board needs this is not a universal requirement,
it should be set up in the machine-specific Kconfig for the reference
board in that case.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v4 0/4] fix the clock setting for SAR ADC
From: Jonathan Cameron @ 2017-12-02 11:38 UTC (permalink / raw)
  To: Yixun Lan
  Cc: Jonathan Cameron, Martin Blumenstingl, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Neil Armstrong,
	linux-iio-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, Michael Turquette,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Xingyu Chen,
	Kevin Hilman, Carlo Caione,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-clk-u79uwXL29TY76Z2rM5mHXA, Jerome Brunet
In-Reply-To: <15745fd0-1af9-c7c0-8769-063f218a3d28-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>

On Tue, 28 Nov 2017 21:11:29 +0800
Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org> wrote:

> On 11/11/17 08:37, Jonathan Cameron wrote:
> > On Tue, 7 Nov 2017 22:36:00 +0100
> > Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> >   
> >> Hi Yixun,
> >>
> >> On Tue, Nov 7, 2017 at 3:09 PM, Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org> wrote:  
> >>> patch [1/4]:
> >>>   Fix wrong SARADC/SANA clock gate bit in Meson-GXBB/GXL,
> >>> the published datasheets[4] also has wrong description about this.
> >>>   This patch should be explicitly merged *before* other patches.
> >>>
> >>> patch [2-4/4]:
> >>>   Drop the "sana" clock from SAR ADC module,    
> >> I agree with Jerome that patch 2/4 should be applied last.  
> > 
> > Let me know when I should take this.
> > 
> > Thanks,
> > 
> > Jonathan
> >   
> >> when I wrote the driver I couldn't get it to work on my GXBB board
> >> (which unfortunately has died since then) because the clocks were
> >> disabled (they weren't enabled by the bootloader). people who are
> >> using an old .dtb would get the same problem again until the clock
> >> driver is merged
> >>  
> >>>   From the hardware perspective, the SAR ADC module doesn't
> >>> require "sana" clock to wrok. This should apply to all SoC,
> >>> including meson6,8, GXBB, GXL..    
> >> thank you for clarifying this!
> >>  
> >>> Note: the whole patchset series has been tested at GXL-P212 board,
> >>> we haven't got any meson6,8 board to test, so I would appreciate
> >>> if someone (Martin?) could help to confirm it works there.    
> >> I can test this on a Meson8b and a Meson8m2 board on the weekend -
> >> I'll let you know about the results
> >>
> >>
> >> Regards
> >> Martin
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> >> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> > 
> > 
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
> > 
> > .
> >   
> 
> Hi Jonathan Cameron & Kevin Hilman:
> 
>  since the clk part patch has been applied[1], can we proceed with others?
> 
> to Jonathan:
> I think the iio part(patch [2/4]) should be merged via your iio tree?
> see [2]
I've applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.  It also makes sense for me to
take the dts binding update as it goes with the driver change. 

Hence I've just left patch 4 for Kevin.  Doesn't matter if this crosses
with Kevin also taking patch 3 though as it'll get sorted out automatically
by git later anyway.

Thanks

Jonathan
> 
> to Kevin:
> could you take the DTS part? see [3], and the patch [4/4] has a rework
> version, see [4], to separate dt64 vs dt32 device tree.
> 
> 
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005472.html
> 
> [2]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005264.html
> 
> [3]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005265.html
> 
> [4]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005304.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005305.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005306.html
> 
> Yixun
> 

^ permalink raw reply

* [PATCH] pinctrl: gemini: Support drive strength setting
From: Linus Walleij @ 2017-12-02 11:23 UTC (permalink / raw)
  To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
  Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
	devicetree-u79uwXL29TY76Z2rM5mHXA

The Gemini pin controller can set drive strength for a few
select groups of pins (not individually). Implement this
for GMAC0 and 1 (ethernet ports), IDE and PCI.

Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
The DT binding part is just using generic bindings, so should be
pretty uncontroversial.
---
 .../bindings/pinctrl/cortina,gemini-pinctrl.txt    |  3 +
 drivers/pinctrl/pinctrl-gemini.c                   | 81 ++++++++++++++++++++++
 2 files changed, 84 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt
index d857b67fab72..4346ff2dd8e6 100644
--- a/Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt
@@ -17,6 +17,9 @@ and generic pin config nodes.
 
 Supported configurations:
 - skew-delay is supported on the Ethernet pins
+- drive-strength with 4, 8, 12 or 16 mA as argument is supported for
+  entire groups on the groups "idegrp", "gmii_gmac0_grp", "gmii_gmac1_grp"
+  and "pcigrp".
 
 Example:
 
diff --git a/drivers/pinctrl/pinctrl-gemini.c b/drivers/pinctrl/pinctrl-gemini.c
index c11b8f14d841..56db4e77b220 100644
--- a/drivers/pinctrl/pinctrl-gemini.c
+++ b/drivers/pinctrl/pinctrl-gemini.c
@@ -67,6 +67,9 @@ struct gemini_pmx {
  *	elements in .pins so we can iterate over that array
  * @mask: bits to clear to enable this when doing pin muxing
  * @value: bits to set to enable this when doing pin muxing
+ * @driving_mask: bitmask for the IO Pad driving register for this
+ *	group, if it supports altering the driving strength of
+ *	its lines.
  */
 struct gemini_pin_group {
 	const char *name;
@@ -74,12 +77,14 @@ struct gemini_pin_group {
 	const unsigned int num_pins;
 	u32 mask;
 	u32 value;
+	u32 driving_mask;
 };
 
 /* Some straight-forward control registers */
 #define GLOBAL_WORD_ID		0x00
 #define GLOBAL_STATUS		0x04
 #define GLOBAL_STATUS_FLPIN	BIT(20)
+#define GLOBAL_IODRIVE		0x10
 #define GLOBAL_GMAC_CTRL_SKEW	0x1c
 #define GLOBAL_GMAC0_DATA_SKEW	0x20
 #define GLOBAL_GMAC1_DATA_SKEW	0x24
@@ -738,6 +743,7 @@ static const struct gemini_pin_group gemini_3512_pin_groups[] = {
 		/* Conflict with all flash usage */
 		.value = IDE_PADS_ENABLE | NAND_PADS_DISABLE |
 			PFLASH_PADS_DISABLE | SFLASH_PADS_DISABLE,
+		.driving_mask = GENMASK(21, 20),
 	},
 	{
 		.name = "satagrp",
@@ -753,6 +759,7 @@ static const struct gemini_pin_group gemini_3512_pin_groups[] = {
 		.name = "gmii_gmac0_grp",
 		.pins = gmii_gmac0_3512_pins,
 		.num_pins = ARRAY_SIZE(gmii_gmac0_3512_pins),
+		.driving_mask = GENMASK(17, 16),
 	},
 	{
 		.name = "gmii_gmac1_grp",
@@ -760,6 +767,7 @@ static const struct gemini_pin_group gemini_3512_pin_groups[] = {
 		.num_pins = ARRAY_SIZE(gmii_gmac1_3512_pins),
 		/* Bring out RGMII on the GMAC1 pins */
 		.value = GEMINI_GMAC_IOSEL_GMAC0_GMAC1_RGMII,
+		.driving_mask = GENMASK(19, 18),
 	},
 	{
 		.name = "pcigrp",
@@ -767,6 +775,7 @@ static const struct gemini_pin_group gemini_3512_pin_groups[] = {
 		.num_pins = ARRAY_SIZE(pci_3512_pins),
 		/* Conflict only with GPIO2 */
 		.value = PCI_PADS_ENABLE | PCI_CLK_PAD_ENABLE,
+		.driving_mask = GENMASK(23, 22),
 	},
 	{
 		.name = "lpcgrp",
@@ -1671,6 +1680,7 @@ static const struct gemini_pin_group gemini_3516_pin_groups[] = {
 		/* Conflict with all flash usage */
 		.value = IDE_PADS_ENABLE | NAND_PADS_DISABLE |
 			PFLASH_PADS_DISABLE | SFLASH_PADS_DISABLE,
+		.driving_mask = GENMASK(21, 20),
 	},
 	{
 		.name = "satagrp",
@@ -1686,6 +1696,7 @@ static const struct gemini_pin_group gemini_3516_pin_groups[] = {
 		.name = "gmii_gmac0_grp",
 		.pins = gmii_gmac0_3516_pins,
 		.num_pins = ARRAY_SIZE(gmii_gmac0_3516_pins),
+		.driving_mask = GENMASK(17, 16),
 	},
 	{
 		.name = "gmii_gmac1_grp",
@@ -1693,6 +1704,7 @@ static const struct gemini_pin_group gemini_3516_pin_groups[] = {
 		.num_pins = ARRAY_SIZE(gmii_gmac1_3516_pins),
 		/* Bring out RGMII on the GMAC1 pins */
 		.value = GEMINI_GMAC_IOSEL_GMAC0_GMAC1_RGMII,
+		.driving_mask = GENMASK(19, 18),
 	},
 	{
 		.name = "pcigrp",
@@ -1700,6 +1712,7 @@ static const struct gemini_pin_group gemini_3516_pin_groups[] = {
 		.num_pins = ARRAY_SIZE(pci_3516_pins),
 		/* Conflict only with GPIO2 */
 		.value = PCI_PADS_ENABLE | PCI_CLK_PAD_ENABLE,
+		.driving_mask = GENMASK(23, 22),
 	},
 	{
 		.name = "lpcgrp",
@@ -2393,9 +2406,77 @@ static int gemini_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
 	return ret;
 }
 
+static int gemini_pinconf_group_set(struct pinctrl_dev *pctldev,
+				    unsigned selector,
+				    unsigned long *configs,
+				    unsigned num_configs)
+{
+	struct gemini_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
+	const struct gemini_pin_group *grp = NULL;
+	enum pin_config_param param;
+	u32 arg;
+	u32 val;
+	int i;
+
+	if (pmx->is_3512)
+		grp = &gemini_3512_pin_groups[selector];
+	if (pmx->is_3516)
+		grp = &gemini_3516_pin_groups[selector];
+
+	/* First figure out if this group supports configs */
+	if (!grp->driving_mask) {
+		dev_err(pmx->dev, "pin config group \"%s\" does "
+			"not support drive strength setting\n",
+			grp->name);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < num_configs; i++) {
+		param = pinconf_to_config_param(configs[i]);
+		arg = pinconf_to_config_argument(configs[i]);
+
+		switch (param) {
+		case PIN_CONFIG_DRIVE_STRENGTH:
+			switch (arg) {
+			case 4:
+				val = 0;
+				break;
+			case 8:
+				val = 1;
+				break;
+			case 12:
+				val = 2;
+				break;
+			case 16:
+				val = 3;
+				break;
+			default:
+				dev_err(pmx->dev,
+					"invalid drive strength %d mA\n",
+					arg);
+				return -ENOTSUPP;
+			}
+			val <<= (ffs(grp->driving_mask) - 1);
+			regmap_update_bits(pmx->map, GLOBAL_IODRIVE,
+					   grp->driving_mask,
+					   val);
+			dev_info(pmx->dev,
+				 "set group %s to %d mA drive strength mask %08x val %08x\n",
+				 grp->name, arg, grp->driving_mask, val);
+			break;
+		default:
+			dev_err(pmx->dev, "invalid config param %04x\n", param);
+			return -ENOTSUPP;
+		}
+	}
+
+	return 0;
+}
+
 static const struct pinconf_ops gemini_pinconf_ops = {
 	.pin_config_get = gemini_pinconf_get,
 	.pin_config_set = gemini_pinconf_set,
+	.pin_config_group_set = gemini_pinconf_group_set,
 	.is_generic = true,
 };
 
-- 
2.14.3

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

^ permalink raw reply related

* [PATCH net-next 1/2 v6] net: ethernet: Add DT bindings for the Gemini ethernet
From: Linus Walleij @ 2017-12-02 11:06 UTC (permalink / raw)
  To: netdev-u79uwXL29TY76Z2rM5mHXA, David S . Miller,
	Michał Mirosław
  Cc: Janos Laube, Paulius Zaleckas,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Hans Ulli Kroll, Florian Fainelli, Linus Walleij,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Tobias Waldvogel

This adds the device tree bindings for the Gemini ethernet
controller. It is pretty straight-forward, using standard
bindings and modelling the two child ports as child devices
under the parent ethernet controller device.

Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Tobias Waldvogel <tobias.waldvogel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Michał Mirosław <mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org>
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 .../bindings/net/cortina,gemini-ethernet.txt       | 92 ++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt

diff --git a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
new file mode 100644
index 000000000000..35fa3abd1c73
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
@@ -0,0 +1,92 @@
+Cortina Systems Gemini Ethernet Controller
+==========================================
+
+This ethernet controller is found in the Gemini SoC family:
+StorLink SL3512 and SL3516, also known as Cortina Systems
+CS3512 and CS3516.
+
+Required properties:
+- compatible: must be "cortina,gemini-ethernet"
+- reg: must contain the global registers and the V-bit and A-bit
+  memory areas, in total three register sets.
+- syscon: a phandle to the system controller
+- #address-cells: must be specified, must be <1>
+- #size-cells: must be specified, must be <1>
+- ranges: should be state like this giving a 1:1 address translation
+  for the subnodes
+
+The subnodes represents the two ethernet ports in this device.
+They are not independent of each other since they share resources
+in the parent node, and are thus children.
+
+Required subnodes:
+- port0: contains the resources for ethernet port 0
+- port1: contains the resources for ethernet port 1
+
+Required subnode properties:
+- compatible: must be "cortina,gemini-ethernet-port"
+- reg: must contain two register areas: the DMA/TOE memory and
+  the GMAC memory area of the port
+- interrupts: should contain the interrupt line of the port.
+  this is nominally a level interrupt active high.
+- resets: this must provide an SoC-integrated reset line for
+  the port.
+- clocks: this should contain a handle to the PCLK clock for
+  clocking the silicon in this port
+- clock-names: must be "PCLK"
+
+Optional subnode properties:
+- phy-mode: see ethernet.txt
+- phy-handle: see ethernet.txt
+
+Example:
+
+mdio-bus {
+	(...)
+	phy0: ethernet-phy@1 {
+		reg = <1>;
+		device_type = "ethernet-phy";
+	};
+	phy1: ethernet-phy@3 {
+		reg = <3>;
+		device_type = "ethernet-phy";
+	};
+};
+
+
+ethernet@60000000 {
+	compatible = "cortina,gemini-ethernet";
+	reg = <0x60000000 0x4000>, /* Global registers, queue */
+	      <0x60004000 0x2000>, /* V-bit */
+	      <0x60006000 0x2000>; /* A-bit */
+	syscon = <&syscon>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges;
+
+	gmac0: port0 {
+		compatible = "cortina,gemini-ethernet-port";
+		reg = <0x60008000 0x2000>, /* Port 0 DMA/TOE */
+		      <0x6000a000 0x2000>; /* Port 0 GMAC */
+		interrupt-parent = <&intcon>;
+		interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
+		resets = <&syscon GEMINI_RESET_GMAC0>;
+		clocks = <&syscon GEMINI_CLK_GATE_GMAC0>;
+		clock-names = "PCLK";
+		phy-mode = "rgmii";
+		phy-handle = <&phy0>;
+	};
+
+	gmac1: port1 {
+		compatible = "cortina,gemini-ethernet-port";
+		reg = <0x6000c000 0x2000>, /* Port 1 DMA/TOE */
+		      <0x6000e000 0x2000>; /* Port 1 GMAC */
+		interrupt-parent = <&intcon>;
+		interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+		resets = <&syscon GEMINI_RESET_GMAC1>;
+		clocks = <&syscon GEMINI_CLK_GATE_GMAC1>;
+		clock-names = "PCLK";
+		phy-mode = "rgmii";
+		phy-handle = <&phy1>;
+	};
+};
-- 
2.14.3

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

^ permalink raw reply related

* Re: [PATCH 0/2] Add devicetree for Axentia Nattis
From: Peter Rosin @ 2017-12-02  7:58 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: Mark Rutland, devicetree@vger.kernel.org,
	alsa-devel@alsa-project.org, Liam Girdwood, Mark Brown,
	Takashi Iwai, Nicolas Ferre, Linux Kernel, Rob Herring,
	Alexandre Belloni, Russell King,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABxcv=k6K8gRDSRu1r6=mELcOQLcNr6EOQGj0Q0wDXrGa58sqw@mail.gmail.com>

On 2017-12-02 02:05, Javier Martinez Canillas wrote:
> Hello Peter,
> 
> On Fri, Dec 1, 2017 at 11:44 PM, Peter Rosin <peda@axentia.se> wrote:
>> Hi!
>>
>> I'd like to add a devicetree for our Nattis to the kernel. The
>> Nattis is a device for showing departures for public transportation
>> (optionally including a text-to-speech module for the visually
>> impaired).
>>
>> I'm a bit unsure if the tfa9879 sound codec binding is needed,
>> but I suppose it belongs in trivial-devices?
>>
> 
> There's a DT binding for this device now:
> 
> https://patchwork.ozlabs.org/patch/816157/

What do you know, thanks for the hint. I even reviewed a followup
patch for that one, so I guess I should have known...

Anyway, I should probably add a #sound-dai-cells entry. v2 coming up.

Cheers,
peda

^ permalink raw reply

* [PATCH V5 7/7] dmaengine: qcom_hidma: Add identity register support
From: Sinan Kaya @ 2017-12-02  4:27 UTC (permalink / raw)
  To: dmaengine-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sinan Kaya,
	Andy Gross, David Brown, Dan Williams, Vinod Koul,
	open list:ARM/QUALCOMM SUPPORT, open list
In-Reply-To: <1512188864-773-1-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

The location for destination event channel register has been relocated from
offset 0x28 to 0x40. Update the code accordingly.

Signed-off-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
 drivers/dma/qcom/hidma.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index c146c6d..963cc52 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -107,6 +107,7 @@ static void hidma_free(struct hidma_dev *dmadev)
 
 enum hidma_cap {
 	HIDMA_MSI_CAP = 1,
+	HIDMA_IDENTITY_CAP,
 };
 
 /* process completed descriptors */
@@ -838,7 +839,10 @@ static int hidma_probe(struct platform_device *pdev)
 	if (!dmadev->nr_descriptors)
 		dmadev->nr_descriptors = HIDMA_NR_DEFAULT_DESC;
 
-	dmadev->chidx = readl(dmadev->dev_trca + 0x28);
+	if (hidma_test_capability(&pdev->dev, HIDMA_IDENTITY_CAP))
+		dmadev->chidx = readl(dmadev->dev_trca + 0x40);
+	else
+		dmadev->chidx = readl(dmadev->dev_trca + 0x28);
 
 	/* Set DMA mask to 64 bits. */
 	rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
@@ -944,7 +948,7 @@ static int hidma_remove(struct platform_device *pdev)
 static const struct acpi_device_id hidma_acpi_ids[] = {
 	{"QCOM8061"},
 	{"QCOM8062", HIDMA_MSI_CAP},
-	{"QCOM8063", HIDMA_MSI_CAP},
+	{"QCOM8063", (HIDMA_MSI_CAP | HIDMA_IDENTITY_CAP)},
 	{},
 };
 MODULE_DEVICE_TABLE(acpi, hidma_acpi_ids);
@@ -953,7 +957,8 @@ static int hidma_remove(struct platform_device *pdev)
 static const struct of_device_id hidma_match[] = {
 	{.compatible = "qcom,hidma-1.0",},
 	{.compatible = "qcom,hidma-1.1", .data = (void *)(HIDMA_MSI_CAP),},
-	{.compatible = "qcom,hidma-1.2", .data = (void *)(HIDMA_MSI_CAP),},
+	{.compatible = "qcom,hidma-1.2",
+	 .data = (void *)(HIDMA_MSI_CAP | HIDMA_IDENTITY_CAP),},
 	{},
 };
 MODULE_DEVICE_TABLE(of, hidma_match);
-- 
1.9.1

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

^ permalink raw reply related

* [PATCH V5 6/7] dmaengine: qcom_hidma: Add support for the new revision
From: Sinan Kaya @ 2017-12-02  4:27 UTC (permalink / raw)
  To: dmaengine-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sinan Kaya,
	Andy Gross, David Brown, Vinod Koul, Dan Williams,
	open list:ARM/QUALCOMM SUPPORT, open list
In-Reply-To: <1512188864-773-1-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

Add support for probing the newer HW and also organize MSI capable hardware
into an array for maintenance reasons.

Signed-off-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
 drivers/dma/qcom/hidma.c | 34 +++++++++++++---------------------
 1 file changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index e366985..c146c6d 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -50,6 +50,7 @@
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/of_dma.h>
+#include <linux/of_device.h>
 #include <linux/property.h>
 #include <linux/delay.h>
 #include <linux/acpi.h>
@@ -104,6 +105,9 @@ static void hidma_free(struct hidma_dev *dmadev)
 module_param(nr_desc_prm, uint, 0644);
 MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
 
+enum hidma_cap {
+	HIDMA_MSI_CAP = 1,
+};
 
 /* process completed descriptors */
 static void hidma_process_completed(struct hidma_chan *mchan)
@@ -736,25 +740,12 @@ static int hidma_request_msi(struct hidma_dev *dmadev,
 #endif
 }
 
-static bool hidma_msi_capable(struct device *dev)
+static bool hidma_test_capability(struct device *dev, enum hidma_cap test_cap)
 {
-	struct acpi_device *adev = ACPI_COMPANION(dev);
-	const char *of_compat;
-	int ret = -EINVAL;
-
-	if (!adev || acpi_disabled) {
-		ret = device_property_read_string(dev, "compatible",
-						  &of_compat);
-		if (ret)
-			return false;
+	enum hidma_cap cap;
 
-		ret = strcmp(of_compat, "qcom,hidma-1.1");
-	} else {
-#ifdef CONFIG_ACPI
-		ret = strcmp(acpi_device_hid(adev), "QCOM8062");
-#endif
-	}
-	return ret == 0;
+	cap = (enum hidma_cap) device_get_match_data(dev);
+	return cap ? ((cap & test_cap) > 0) : 0;
 }
 
 static int hidma_probe(struct platform_device *pdev)
@@ -834,8 +825,7 @@ static int hidma_probe(struct platform_device *pdev)
 	 * Determine the MSI capability of the platform. Old HW doesn't
 	 * support MSI.
 	 */
-	msi = hidma_msi_capable(&pdev->dev);
-
+	msi = hidma_test_capability(&pdev->dev, HIDMA_MSI_CAP);
 	device_property_read_u32(&pdev->dev, "desc-count",
 				 &dmadev->nr_descriptors);
 
@@ -953,7 +943,8 @@ static int hidma_remove(struct platform_device *pdev)
 #if IS_ENABLED(CONFIG_ACPI)
 static const struct acpi_device_id hidma_acpi_ids[] = {
 	{"QCOM8061"},
-	{"QCOM8062"},
+	{"QCOM8062", HIDMA_MSI_CAP},
+	{"QCOM8063", HIDMA_MSI_CAP},
 	{},
 };
 MODULE_DEVICE_TABLE(acpi, hidma_acpi_ids);
@@ -961,7 +952,8 @@ static int hidma_remove(struct platform_device *pdev)
 
 static const struct of_device_id hidma_match[] = {
 	{.compatible = "qcom,hidma-1.0",},
-	{.compatible = "qcom,hidma-1.1",},
+	{.compatible = "qcom,hidma-1.1", .data = (void *)(HIDMA_MSI_CAP),},
+	{.compatible = "qcom,hidma-1.2", .data = (void *)(HIDMA_MSI_CAP),},
 	{},
 };
 MODULE_DEVICE_TABLE(of, hidma_match);
-- 
1.9.1

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

^ permalink raw reply related

* [PATCH V5 5/7] ACPI: properties: Implement get_match_data() callback
From: Sinan Kaya @ 2017-12-02  4:27 UTC (permalink / raw)
  To: dmaengine, timur, devicetree
  Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Rafael J. Wysocki,
	Len Brown, open list:ACPI, open list
In-Reply-To: <1512188864-773-1-git-send-email-okaya@codeaurora.org>

Now that we have a get_match_data() callback as part of the firmware node,
implement the ACPI specific piece for it.

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/acpi/property.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index e26ea20..49dd50b 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1271,6 +1271,17 @@ static int acpi_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
 	return 0;
 }
 
+static void *acpi_fwnode_get_match_data(const struct fwnode_handle *fwnode,
+					const struct device_driver *drv)
+{
+	struct acpi_device *adev = to_acpi_device_node(fwnode);
+
+	if (!adev)
+		return NULL;
+
+	return acpi_get_match_data(adev, drv->acpi_match_table);
+}
+
 #define DECLARE_ACPI_FWNODE_OPS(ops) \
 	const struct fwnode_operations ops = {				\
 		.device_is_available = acpi_fwnode_device_is_available, \
@@ -1289,6 +1300,7 @@ static int acpi_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
 			acpi_fwnode_graph_get_remote_endpoint,		\
 		.graph_get_port_parent = acpi_fwnode_get_parent,	\
 		.graph_parse_endpoint = acpi_fwnode_graph_parse_endpoint, \
+		.get_match_data = acpi_fwnode_get_match_data,		\
 	};								\
 	EXPORT_SYMBOL_GPL(ops)
 
-- 
1.9.1

^ permalink raw reply related

* [PATCH V5 4/7] OF: properties: Implement get_match_data() callback
From: Sinan Kaya @ 2017-12-02  4:27 UTC (permalink / raw)
  To: dmaengine, timur, devicetree
  Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Rob Herring,
	Frank Rowand, open list
In-Reply-To: <1512188864-773-1-git-send-email-okaya@codeaurora.org>

Now that we have a get_match_data() callback as part of the firmware node,
implement the OF specific piece for it.

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/of/property.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 264c355..adcde1a 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -981,6 +981,22 @@ static int of_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
 	return 0;
 }
 
+void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode,
+			       const struct device_driver *drv)
+{
+	const struct device_node *node = to_of_node(fwnode);
+	const struct of_device_id *match;
+
+	if (!node)
+		return NULL;
+
+	match = of_match_node(drv->of_match_table, node);
+	if (!match)
+		return NULL;
+
+	return (void *)match->data;
+}
+
 const struct fwnode_operations of_fwnode_ops = {
 	.get = of_fwnode_get,
 	.put = of_fwnode_put,
@@ -996,5 +1012,6 @@ static int of_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
 	.graph_get_remote_endpoint = of_fwnode_graph_get_remote_endpoint,
 	.graph_get_port_parent = of_fwnode_graph_get_port_parent,
 	.graph_parse_endpoint = of_fwnode_graph_parse_endpoint,
+	.get_match_data = of_fwnode_get_match_data,
 };
 EXPORT_SYMBOL_GPL(of_fwnode_ops);
-- 
1.9.1

^ permalink raw reply related

* [PATCH V5 3/7] device property: Introduce a common API to fetch device match data
From: Sinan Kaya @ 2017-12-02  4:27 UTC (permalink / raw)
  To: dmaengine, timur, devicetree
  Cc: Rob Herring, linux-arm-msm, Dmitry Torokhov, Rafael J. Wysocki,
	open list, Sinan Kaya, open list:ACPI, Kieran Bingham,
	Sakari Ailus, Greg Kroah-Hartman, Mika Westerberg,
	linux-arm-kernel, Len Brown
In-Reply-To: <1512188864-773-1-git-send-email-okaya@codeaurora.org>

There is an OF/ACPI function to obtain the driver data. We want to hide
OF/ACPI details from the device drivers and abstract following the device
family of functions.

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
 drivers/base/property.c  | 7 +++++++
 include/linux/fwnode.h   | 4 ++++
 include/linux/property.h | 2 ++
 3 files changed, 13 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 7ed99c1..dfc53af 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1335,3 +1335,10 @@ int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
 	return fwnode_call_int_op(fwnode, graph_parse_endpoint, endpoint);
 }
 EXPORT_SYMBOL(fwnode_graph_parse_endpoint);
+
+void *device_get_match_data(struct device *dev)
+{
+	return fwnode_call_ptr_op(dev_fwnode(dev), get_match_data,
+				  dev->driver);
+}
+EXPORT_SYMBOL_GPL(device_get_match_data);
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 0c35b6c..6e5e1dd 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -15,6 +15,7 @@
 #include <linux/types.h>
 
 struct fwnode_operations;
+struct device_driver;
 
 struct fwnode_handle {
 	struct fwnode_handle *secondary;
@@ -66,6 +67,7 @@ struct fwnode_reference_args {
  *			       endpoint node.
  * @graph_get_port_parent: Return the parent node of a port node.
  * @graph_parse_endpoint: Parse endpoint for port and endpoint id.
+ * @get_match_data: Return the driver match data.
  */
 struct fwnode_operations {
 	void (*get)(struct fwnode_handle *fwnode);
@@ -101,6 +103,8 @@ struct fwnode_operations {
 	(*graph_get_port_parent)(struct fwnode_handle *fwnode);
 	int (*graph_parse_endpoint)(const struct fwnode_handle *fwnode,
 				    struct fwnode_endpoint *endpoint);
+	void *(*get_match_data)(const struct fwnode_handle *fwnode,
+				const struct device_driver *drv);
 };
 
 #define fwnode_has_op(fwnode, op)				\
diff --git a/include/linux/property.h b/include/linux/property.h
index 6bebee1..01fa55b 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -275,6 +275,8 @@ int device_add_properties(struct device *dev,
 
 enum dev_dma_attr device_get_dma_attr(struct device *dev);
 
+void *device_get_match_data(struct device *dev);
+
 int device_get_phy_mode(struct device *dev);
 
 void *device_get_mac_address(struct device *dev, char *addr, int alen);
-- 
1.9.1

^ permalink raw reply related

* [PATCH V5 2/7] ACPI / bus: Introduce acpi_get_match_data() function
From: Sinan Kaya @ 2017-12-02  4:27 UTC (permalink / raw)
  To: dmaengine-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sinan Kaya,
	Rafael J. Wysocki, Len Brown, open list:ACPI, open list
In-Reply-To: <1512188864-773-1-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

OF has of_device_get_match_data() function to extract driver specific data
structure. Add a similar function for ACPI.

Signed-off-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
 drivers/acpi/bus.c   | 13 +++++++++++++
 include/linux/acpi.h |  8 ++++++++
 2 files changed, 21 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 4d0979e..05d8d9a 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -785,6 +785,19 @@ const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
 }
 EXPORT_SYMBOL_GPL(acpi_match_device);
 
+void *acpi_get_match_data(struct acpi_device *device,
+			  const struct acpi_device_id *ids)
+{
+	const struct acpi_device_id *match;
+
+	match =  __acpi_match_device(device, ids, NULL);
+	if (!match)
+		return NULL;
+
+	return (void *)match->driver_data;
+}
+EXPORT_SYMBOL_GPL(acpi_get_match_data);
+
 int acpi_match_device_ids(struct acpi_device *device,
 			  const struct acpi_device_id *ids)
 {
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 502af53..196bc7a 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -584,6 +584,8 @@ extern int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
 const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
 					       const struct device *dev);
 
+void *acpi_get_match_data(struct acpi_device *device,
+			  const struct acpi_device_id *ids);
 extern bool acpi_driver_match_device(struct device *dev,
 				     const struct device_driver *drv);
 int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
@@ -755,6 +757,12 @@ static inline const struct acpi_device_id *acpi_match_device(
 	return NULL;
 }
 
+static inline void *acpi_get_match_data(struct acpi_device *device,
+					const struct acpi_device_id *ids)
+{
+	return NULL;
+}
+
 static inline bool acpi_driver_match_device(struct device *dev,
 					    const struct device_driver *drv)
 {
-- 
1.9.1

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

^ permalink raw reply related

* [PATCH V5 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
From: Sinan Kaya @ 2017-12-02  4:27 UTC (permalink / raw)
  To: dmaengine-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sinan Kaya,
	Vinod Koul, Rob Herring, Mark Rutland, open list
In-Reply-To: <1512188864-773-1-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

A new version of the HIDMA IP has been released with bug fixes. Bumping the
hardware version to differentiate from others.

Signed-off-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index 55492c2..5d93d6d 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -47,8 +47,8 @@ When the OS is not in control of the management interface (i.e. it's a guest),
 the channel nodes appear on their own, not under a management node.
 
 Required properties:
-- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
-for MSI capable HW.
+- compatible: must contain "qcom,hidma-1.0" for initial HW or
+  "qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
 - reg: Addresses for the transfer and event channel
 - interrupts: Should contain the event interrupt
 - desc-count: Number of asynchronous requests this channel can handle
-- 
1.9.1

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

^ permalink raw reply related

* [PATCH V5 0/7] dmaengine: qcom_hidma: add support for bugfixed HW
From: Sinan Kaya @ 2017-12-02  4:27 UTC (permalink / raw)
  To: dmaengine, timur, devicetree; +Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya

Introduce new ACPI and OF device ids for thw HW along with the helper
functions.

Changes from v4:
* rework the device_get_match_data() to use fwnode callbacks
* change calling parameter of acpi_get_match_data() to struct acpi_device()

Sinan Kaya (7):
  Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
  ACPI / bus: Introduce acpi_get_match_data() function
  device property: Introduce a common API to fetch device match data
  OF: properties: Implement get_match_data() callback
  ACPI: properties: Implement get_match_data() callback
  dmaengine: qcom_hidma: Add support for the new revision
  dmaengine: qcom_hidma: Add identity register support

 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  4 +--
 drivers/acpi/bus.c                                 | 13 +++++++
 drivers/acpi/property.c                            | 12 +++++++
 drivers/base/property.c                            |  7 ++++
 drivers/dma/qcom/hidma.c                           | 41 ++++++++++------------
 drivers/of/property.c                              | 17 +++++++++
 include/linux/acpi.h                               |  8 +++++
 include/linux/fwnode.h                             |  4 +++
 include/linux/property.h                           |  2 ++
 9 files changed, 84 insertions(+), 24 deletions(-)

-- 
1.9.1

^ permalink raw reply

* Re: [PATCH 07/12] ARM: dts: imx6qdl-aristainetos: Move display node out of 'soc'
From: Heiko Schocher @ 2017-12-02  3:48 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Fabio Estevam, Heiko Schocher
In-Reply-To: <1512156285-18451-7-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hello Fabio,

Am 01.12.2017 um 20:24 schrieb Fabio Estevam:
> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> 
> Move disp0 node from soc node to root node.
> 
> disp0 node does not have any register properties and thus
> shouldn't be placed on the bus.
> 
> This fixes the following build warnings with W=1:
> 
> arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (simple_bus_reg): Node /soc/disp0 missing or empty reg/ranges property
> 
> Cc: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> ---
>   arch/arm/boot/dts/imx6dl-aristainetos_4.dts | 50 ++++++++++++++---------------
>   arch/arm/boot/dts/imx6dl-aristainetos_7.dts | 48 +++++++++++++--------------
>   2 files changed, 47 insertions(+), 51 deletions(-)

Thanks for fixing!

Reviewed-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
Tested-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs-ynQEQJNshbs@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 06/12] ARM: dts: imx6qdl-aristainetos: Move regulators out of simple-bus
From: Heiko Schocher @ 2017-12-02  3:47 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Fabio Estevam, Heiko Schocher
In-Reply-To: <1512156285-18451-6-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hello fabio,

Am 01.12.2017 um 20:24 schrieb Fabio Estevam:
> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> 
> It is not recommended to place regulator nodes inside simple-bus, so
> move them out in order to fix the following build warnings with W=1:
> 
> arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name

This is not fixed through this patch.

> arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /regulators/regulator@0 has a unit name, but no reg property
> arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /regulators/regulator@1 has a unit name, but no reg property
> arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /regulators/regulator@2 has a unit name, but no reg property
> arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /regulators/regulator@3 has a unit name, but no reg property
> 
> Cc: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> ---
>   arch/arm/boot/dts/imx6qdl-aristainetos.dtsi  | 73 +++++++++++++-------------
>   arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi | 76 +++++++++++++---------------
>   2 files changed, 70 insertions(+), 79 deletions(-)

Beside of the nitpick, Thanks for fixing!

Reviewed-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
Tested-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs-ynQEQJNshbs@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 0/2] Add devicetree for Axentia Nattis
From: Javier Martinez Canillas @ 2017-12-02  1:05 UTC (permalink / raw)
  To: Peter Rosin
  Cc: Mark Rutland, devicetree@vger.kernel.org,
	alsa-devel@alsa-project.org, Liam Girdwood, Mark Brown,
	Takashi Iwai, Nicolas Ferre, Linux Kernel, Rob Herring,
	Alexandre Belloni, Russell King,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20171201224425.5477-1-peda@axentia.se>

Hello Peter,

On Fri, Dec 1, 2017 at 11:44 PM, Peter Rosin <peda@axentia.se> wrote:
> Hi!
>
> I'd like to add a devicetree for our Nattis to the kernel. The
> Nattis is a device for showing departures for public transportation
> (optionally including a text-to-speech module for the visually
> impaired).
>
> I'm a bit unsure if the tfa9879 sound codec binding is needed,
> but I suppose it belongs in trivial-devices?
>

There's a DT binding for this device now:

https://patchwork.ozlabs.org/patch/816157/

> Cheers,
> Peter
>

Best regards,
Javier

^ permalink raw reply

* Re: [PATCH 14/17] ARM: dts: Add missing gpu node and binding for omap4
From: Adam Ford @ 2017-12-02  0:18 UTC (permalink / raw)
  To: Rob Herring
  Cc: Tony Lindgren, linux-omap-u79uwXL29TY76Z2rM5mHXA,
	Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Mark Rutland, Tomi Valkeinen
In-Reply-To: <20170911215016.far2rpihdd423ybt@rob-hp-laptop>

On Mon, Sep 11, 2017 at 4:50 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Aug 30, 2017 at 08:19:50AM -0700, Tony Lindgren wrote:
>> On omap4 we're missing the PowerVR SGX GPU node with it's related
>> "ti,hwmods" property that the SoC interconnect code needs.
>>
>> Note that this will only show up as a bug with "doesn't have
>> mpu register target base" boot errors when the legacy platform
>> data is removed.
>>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
>> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>> ---

Out of curiosity, is anything being done with this?  I'm really
interested to see the PVR working in a modern kernel.  I'd like to
help more, but I am afraid I don't fully understand the interconnects
and how the driver componenets interact with the omap processor.

Please let me know if there are sub-tasks that I can assist.

adam

>>  .../devicetree/bindings/gpu/ti-powervr-sgx.txt     | 39 ++++++++++++++++++++++
>
> While the compatible strings should be TI specific, the doc shouldn't
> be.
>
>>  arch/arm/boot/dts/omap4.dtsi                       |  7 ++++
>>  2 files changed, 46 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/gpu/ti-powervr-sgx.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox