Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Peter Meerwald-Stadler @ 2016-12-13 20:22 UTC (permalink / raw)
  To: Andreas Klinger
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
	galak-sgV2jX0FEOL9JmXXK+q4OQ, jic23-DgEjT+Ai2ygdnm+yROfE0A,
	knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw
In-Reply-To: <20161213180254.GA3185@andreas>


> This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> cells.

comments below
 
> The protocol is quite simple and using GPIO's:

GPIOs

> One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
> 
> Signed-off-by: Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> ---
>  drivers/iio/adc/Kconfig  |  13 +++
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/hx711.c  | 269 +++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 283 insertions(+)
>  create mode 100644 drivers/iio/adc/hx711.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 932de1f9d1e7..7902b50fcf32 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -205,6 +205,19 @@ config HI8435
>  	  This driver can also be built as a module. If so, the module will be
>  	  called hi8435.
>  
> +config HX711
> +	tristate "AVIA HX711 ADC for weight cells"
> +	depends on GPIOLIB
> +	help
> +	  If you say yes here you get support for AVIA HX711 ADC which is used
> +	  for weight cells
> +
> +	  This driver uses two GPIO's, one for setting the clock and the other

GPIOs

> +	  one for getting the data
> +
> +	  This driver can also be built as a module. If so, the module will be
> +	  called hx711.
> +
>  config INA2XX_ADC
>  	tristate "Texas Instruments INA2xx Power Monitors IIO driver"
>  	depends on I2C && !SENSORS_INA2XX
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index b1aa456e6af3..d46e289900ef 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_HX711) += hx711.o
>  obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> new file mode 100644
> index 000000000000..cbc89e467985
> --- /dev/null
> +++ b/drivers/iio/adc/hx711.c
> @@ -0,0 +1,269 @@
> +/*
> + * HX711: analog to digital converter for weight sensor module
> + *
> + * Copyright (c) Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/err.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/slab.h>
> +#include <linux/sched.h>
> +#include <linux/delay.h>
> +#include <linux/iio/iio.h>
> +
> +#define HX711_GAIN_32		2	/* gain = 32 for channel B  */
> +#define HX711_GAIN_64		3	/* gain = 64 for channel A  */
> +#define HX711_GAIN_128		1	/* gain = 128 for channel A */
> +

only one newline here please

> +
> +struct hx711_data {
> +	struct device		*dev;
> +	dev_t			devt;

devt is not used, delete

> +	struct gpio_desc	*gpiod_sck;
> +	struct gpio_desc	*gpiod_dout;
> +	int			gain_pulse;
> +	struct mutex		lock;
> +};
> +
> +static void hx711_reset(struct hx711_data *hx711_data)
> +{
> +	int val;
> +	int i;
> +
> +	val = gpiod_get_value(hx711_data->gpiod_dout);
> +	if (val) {
> +		dev_warn(hx711_data->dev, "RESET-HX711\n");

message needed?

> +
> +		gpiod_set_value(hx711_data->gpiod_sck, 1);
> +		udelay(80);
> +		gpiod_set_value(hx711_data->gpiod_sck, 0);
> +
> +		for (i = 0; i < 1000; i++) {
> +			val = gpiod_get_value(hx711_data->gpiod_dout);
> +			if (!val)
> +				break;
> +			/* sleep at least 1 ms*/

add space before */

> +			msleep(1);
> +		}

can this fail? what is it takes longer than 1000 * 1ms?

> +	}
> +}
> +
> +static int hx711_cycle(struct hx711_data *hx711_data)
> +{
> +	int val;
> +
> +	/* if preempted for more then 60us while SCK is high:
> +	 * hx711 is going in reset
> +	 * ==> measuring is false
> +	 */
> +	preempt_disable();
> +	gpiod_set_value(hx711_data->gpiod_sck, 1);
> +	val = gpiod_get_value(hx711_data->gpiod_dout);
> +	gpiod_set_value(hx711_data->gpiod_sck, 0);
> +	preempt_enable();
> +
> +	return val;
> +}
> +
> +static unsigned int hx711_read(struct hx711_data *hx711_data)
> +{
> +	int i;
> +	int ret;
> +	int wert = 0;

val or value maybe?
should be unsigned int to match the return type of the function

> +
> +	hx711_reset(hx711_data);
> +
> +	for (i = 0; i < 24; i++) {
> +		wert <<= 1;
> +		ret = hx711_cycle(hx711_data);
> +		if (ret)
> +			wert++;
> +	}
> +
> +	wert ^= 0x800000;
> +
> +	for (i = 0; i < hx711_data->gain_pulse; i++)
> +		ret = hx711_cycle(hx711_data);
> +
> +	return wert;
> +}
> +

delete newline

> +
> +static int hx711_read_raw(struct iio_dev *iio_dev,
> +				const struct iio_chan_spec *chan,
> +				int *val, int *val2, long mask)
> +{
> +	struct hx711_data *hx711_data = iio_priv(iio_dev);
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		switch (chan->type) {
> +		case IIO_VOLTAGE:
> +			mutex_lock(&hx711_data->lock);
> +			*val = (int)hx711_read(hx711_data);
> +			mutex_unlock(&hx711_data->lock);
> +			ret = IIO_VAL_INT;

return IIO_VAL_INT;

> +			break;
> +		default:
> +			return -EINVAL;
> +		}
> +		return ret;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return ret;

delete, dead code

> +}
> +
> +static const struct iio_info hx711_iio_info = {
> +	.driver_module		= THIS_MODULE,
> +	.read_raw		= hx711_read_raw,
> +};
> +
> +static const struct iio_chan_spec hx711_chan_spec[] = {
> +	{ .type = IIO_VOLTAGE,
> +		.channel = 0,

.channel = 0 not needed, there is only one channel

> +		.info_mask_separate =
> +			BIT(IIO_CHAN_INFO_RAW),
> +		.scan_type = {

scan_type not needed, driver does not support buffered reads

> +			.sign = 'u',
> +			.realbits = 24,
> +			.storagebits = 32,
> +			.shift = 0,
> +		}
> +	},
> +};
> +
> +static int hx711_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *node = dev->of_node;
> +	struct hx711_data *hx711_data = NULL;
> +	struct iio_dev *iio;
> +	int ret = 0, ival;
> +
> +	iio = devm_iio_device_alloc(dev, sizeof(struct hx711_data));
> +	if (!iio) {
> +		dev_err(dev, "failed to allocate IIO device\n");
> +		return -ENOMEM;
> +	}
> +
> +	hx711_data = iio_priv(iio);
> +	hx711_data->dev = dev;
> +
> +	mutex_init(&hx711_data->lock);
> +
> +	hx711_data->gpiod_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_HIGH);
> +	if (IS_ERR(hx711_data->gpiod_sck)) {
> +		ret = PTR_ERR(hx711_data->gpiod_sck);
> +		goto err;
> +	}
> +
> +	hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
> +	if (IS_ERR(hx711_data->gpiod_dout)) {
> +		ret = PTR_ERR(hx711_data->gpiod_dout);
> +		goto err;
> +	}
> +
> +	ret = of_property_read_u32 (node, "gain", &ival);
> +	if (!ret) {
> +		switch (ival) {
> +		case 32:
> +			hx711_data->gain_pulse = HX711_GAIN_32;
> +			break;
> +		case 64:
> +			hx711_data->gain_pulse = HX711_GAIN_64;
> +			break;
> +		case 128:

merge default and case 128?

> +			hx711_data->gain_pulse = HX711_GAIN_128;
> +			break;
> +		default:
> +			hx711_data->gain_pulse = HX711_GAIN_128;
> +		}
> +	} else
> +		hx711_data->gain_pulse = HX711_GAIN_128;
> +	dev_dbg(hx711_data->dev, "gain: %d\n", hx711_data->gain_pulse);
> +
> +	ret = gpiod_direction_input(hx711_data->gpiod_dout);
> +	if (ret < 0) {
> +		dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
> +		goto err;
> +	}
> +
> +	ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
> +	if (ret < 0) {
> +		dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
> +		goto err;
> +	}
> +
> +	platform_set_drvdata(pdev, iio);
> +
> +	iio->name = pdev->name;
> +	iio->dev.parent = &pdev->dev;
> +	iio->info = &hx711_iio_info;
> +	iio->modes = INDIO_DIRECT_MODE;
> +	iio->channels = hx711_chan_spec;
> +	iio->num_channels = ARRAY_SIZE(hx711_chan_spec);
> +
> +	dev_err(hx711_data->dev, "initialized\n");

excessive logging, please remove

> +
> +	return devm_iio_device_register(dev, iio);
> +
> +err:
> +	return ret;

just return directly without goto?

> +}
> +
> +
> +static int hx711_suspend(struct device *dev)
> +{

pointless, just don't do PM support

> +	return 0;
> +}
> +
> +static int hx711_resume(struct device *dev)
> +{
> +	return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(hx711_pm_ops, hx711_suspend, hx711_resume);
> +
> +
> +static const struct of_device_id of_hx711_match[] = {
> +	{ .compatible = "avia,hx711", },
> +	{},
> +};
> +
> +MODULE_DEVICE_TABLE(of, of_hx711_match);
> +
> +static struct platform_driver hx711_driver = {
> +	.probe		= hx711_probe,
> +	.driver		= {
> +		.name		= "hx711-gpio",
> +		.pm		= &hx711_pm_ops,
> +		.of_match_table	= of_hx711_match,
> +	},
> +};
> +
> +module_platform_driver(hx711_driver);
> +
> +MODULE_AUTHOR("Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>");
> +MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hx711-gpio");
> +
> 

-- 

Peter Meerwald-Stadler
+43-664-2444418 (mobile)

^ permalink raw reply

* Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level
From: Subhash Jadavani @ 2016-12-13 20:16 UTC (permalink / raw)
  To: Rob Herring
  Cc: vinholikatti-Re5JQEeQqe8AvxtiuMwx3w,
	jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
	martin.petersen-QHcLZuEGTsvQT0dZR+AlfA,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Hannes Reinecke,
	Yaniv Gardi, Joao Pinto,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list
In-Reply-To: <20161213200427.vzdwyzajcftvvcgu@rob-hp-laptop>

On 2016-12-13 12:04, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 04:54:20PM -0800, Subhash Jadavani wrote:
>> UFS device and link can be put in multiple different low power modes 
>> hence
>> UFS driver supports multiple different low power modes. By default UFS
>> driver selects the default (optimal) low power mode (which gives 
>> moderate
>> power savings and have relatively less enter and exit latencies) but
>> we might have to tune this default power mode for different chipset
>> platforms to meet the low power requirements/goals. Hence this patch
>> adds option to change default UFS low power mode (level).
>> 
>> Reviewed-by: Yaniv Gardi <ygardi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Signed-off-by: Subhash Jadavani <subhashj-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      | 10 ++++++
>>  drivers/scsi/ufs/ufshcd-pltfrm.c                   | 14 ++++++++
>>  drivers/scsi/ufs/ufshcd.c                          | 39 
>> ++++++++++++++++++++++
>>  drivers/scsi/ufs/ufshcd.h                          |  4 +--
>>  4 files changed, 65 insertions(+), 2 deletions(-)
>> 
>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
>> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> index a99ed55..c3836c5 100644
>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> @@ -41,6 +41,14 @@ Optional properties:
>>  -lanes-per-direction	: number of lanes available per direction - 
>> either 1 or 2.
>>  			  Note that it is assume same number of lanes is used both
>>  			  directions at once. If not specified, default is 2 lanes per 
>> direction.
>> +- rpm-level		: UFS Runtime power management level. Following PM 
>> levels are supported:
>> +			  0 - Both UFS device and Link in active state (Highest power 
>> consumption)
>> +			  1 - UFS device in active state but Link in Hibern8 state
>> +			  2 - UFS device in Sleep state but Link in active state
>> +			  3 - UFS device in Sleep state and Link in hibern8 state (default 
>> PM level)
>> +			  4 - UFS device in Power-down state and Link in Hibern8 state
>> +			  5 - UFS device in Power-down state and Link in OFF state (Lowest 
>> power consumption)
>> +- spm-level		: UFS System power management level. Allowed PM levels 
>> are same as rpm-level.
> 
> This looks like you are putting policy for Linux into DT.
> 
> What I would expect to see here is disabling of states that don't work
> due to some h/w limitation. Otherwise, it is a user decision for what
> modes to go into. Also, I think link and device states should be
> separate.

Yes, generally default level (3) is good enough (and recommended) for 
all platforms and most likely user is only expected to change this if 
they see issues (most H/W) on their platform or they want even more 
aggressive power state (level-4 or level-5) and ready to take the 
performance hit associated with resume latencies.

Also, I think it is better to keep Link and device states tied, one 
reason is that we can't keep device in sleep/active state when Link is 
in OFF state.

> 
> Rob

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 1/2] iio: adc: hx711: Add DT binding for avia,hx711
From: Peter Meerwald-Stadler @ 2016-12-13 20:11 UTC (permalink / raw)
  To: Andreas Klinger; +Cc: devicetree, linux-iio, linux-kernel, robh+dt, jic23
In-Reply-To: <20161213180142.GA3162@andreas>


> Add DT bindings for avia,hx711
> Add vendor avia to vendor list
> 
> Signed-off-by: Andreas Klinger <ak@it-klinger.de>
> ---
>  .../devicetree/bindings/iio/adc/avia-hx711.txt     | 23 ++++++++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>  2 files changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> new file mode 100644
> index 000000000000..d56f95705fd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> @@ -0,0 +1,23 @@
> +* AVIA HX711 ADC chip for weight cells
> +  Bit-banging driver
> +
> +Required properties:
> + - compatible: Should be "avia,hx711"
> + - sck-gpios:	Definition of the GPIO for the clock
> + - dout-gpios:	Definition of the GPIO for Data-Out

data-out (lowercase)


> +		See Documentation/devicetree/bindings/gpio/gpio.txt
> +
> +Recommended properties:
> + - gain:	Gain select, can be 32, 64 or 128
> +		default is 128
> +
> +Optional properties:

maybe delete this empty section?

> +
> +Example:
> +weight@0 {
> +	compatible = "avia,hx711";
> +	sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
> +	dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
> +	gain = <32>
> +};
> +
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 44ddc980b085..4696bb5c2198 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -32,6 +32,7 @@ atlas	Atlas Scientific LLC
>  atmel	Atmel Corporation
>  auo	AU Optronics Corporation
>  avago	Avago Technologies
> +avia	avia semiconductor
>  avic	Shanghai AVIC Optoelectronics Co., Ltd.
>  axis	Axis Communications AB
>  boe	BOE Technology Group Co., Ltd.
> 

-- 

Peter Meerwald-Stadler
+43-664-2444418 (mobile)

^ permalink raw reply

* Re: [PATCH 3/9] dt-bindings: stm32-dma: Fix typo regarding DMA client binding
From: Rob Herring @ 2016-12-13 20:09 UTC (permalink / raw)
  To: M'boumba Cedric Madianga
  Cc: mark.rutland, devicetree, alexandre.torgue, vinod.koul,
	linux-kernel, mcoquelin.stm32, dmaengine, dan.j.williams,
	linux-arm-kernel
In-Reply-To: <1481636451-27863-4-git-send-email-cedric.madianga@gmail.com>

On Tue, Dec 13, 2016 at 02:40:45PM +0100, M'boumba Cedric Madianga wrote:
> Only four cells are required for dma client binding not five.
> 
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
> ---
>  Documentation/devicetree/bindings/dma/stm32-dma.txt | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 1/3] dt-bindings: arm: update Armada CP110 system controller binding
From: Rob Herring @ 2016-12-13 20:07 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Mark Rutland, devicetree, Yehuda Yitschak, Jason Cooper,
	Pawel Moll, Ian Campbell, Michael Turquette, Hanna Hawa,
	Stephen Boyd, Nadav Haklai, Andrew Lunn, Kumar Gala,
	Gregory Clement, Marcin Wojtas, linux-clk, linux-arm-kernel,
	Sebastian Hesselbarth
In-Reply-To: <1481632880-9198-2-git-send-email-thomas.petazzoni@free-electrons.com>

On Tue, Dec 13, 2016 at 01:41:18PM +0100, Thomas Petazzoni wrote:
> It turns out that in the CP110 HW block present in Marvell Armada
> 7K/8K SoCs, gatable clock n°18 not only controls SD/MMC, but also the
> GOP block. This commit updates the Device Tree binding for this piece
> of hardware accordingly.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  .../devicetree/bindings/arm/marvell/cp110-system-controller0.txt    | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v2 2/2] crypto: mediatek - add DT bindings documentation
From: Rob Herring @ 2016-12-13 20:06 UTC (permalink / raw)
  To: Ryder Lee
  Cc: Herbert Xu, David S. Miller, Matthias Brugger, devicetree,
	linux-mediatek, linux-kernel, linux-crypto, linux-arm-kernel,
	Sean Wang, Roy Luo
In-Reply-To: <1481592676-2248-3-git-send-email-ryder.lee@mediatek.com>

On Tue, Dec 13, 2016 at 09:31:16AM +0800, Ryder Lee wrote:
> Add DT bindings documentation for the crypto driver
> 
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
>  .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> 
> diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> new file mode 100644
> index 0000000..47a786e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> @@ -0,0 +1,32 @@
> +MediaTek cryptographic accelerators
> +
> +Required properties:
> +- compatible: Should be "mediatek,eip97-crypto"
> +- reg: Address and length of the register set for the device
> +- interrupts: Should contain the five crypto engines interrupts in numeric
> +	order. These are global system and four descriptor rings.
> +- clocks: the clock used by the core
> +- clock-names: the names of the clock listed in the clocks property. These are
> +	"ethif", "cryp"
> +- power-domains: Must contain a reference to the PM domain.
> +
> +
> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> +  that services interrupts for this device

This is not optional. It's perhaps inherited from the parent. You can 
drop it as it's implied by interrupts property.

Rob

^ permalink raw reply

* Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level
From: Rob Herring @ 2016-12-13 20:04 UTC (permalink / raw)
  To: Subhash Jadavani
  Cc: vinholikatti, jejb, martin.petersen, linux-scsi, Mark Rutland,
	Hannes Reinecke, Yaniv Gardi, Joao Pinto,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list
In-Reply-To: <1481590462-9981-1-git-send-email-subhashj@codeaurora.org>

On Mon, Dec 12, 2016 at 04:54:20PM -0800, Subhash Jadavani wrote:
> UFS device and link can be put in multiple different low power modes hence
> UFS driver supports multiple different low power modes. By default UFS
> driver selects the default (optimal) low power mode (which gives moderate
> power savings and have relatively less enter and exit latencies) but
> we might have to tune this default power mode for different chipset
> platforms to meet the low power requirements/goals. Hence this patch
> adds option to change default UFS low power mode (level).
> 
> Reviewed-by: Yaniv Gardi <ygardi@codeaurora.org>
> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
> ---
>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      | 10 ++++++
>  drivers/scsi/ufs/ufshcd-pltfrm.c                   | 14 ++++++++
>  drivers/scsi/ufs/ufshcd.c                          | 39 ++++++++++++++++++++++
>  drivers/scsi/ufs/ufshcd.h                          |  4 +--
>  4 files changed, 65 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> index a99ed55..c3836c5 100644
> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> @@ -41,6 +41,14 @@ Optional properties:
>  -lanes-per-direction	: number of lanes available per direction - either 1 or 2.
>  			  Note that it is assume same number of lanes is used both
>  			  directions at once. If not specified, default is 2 lanes per direction.
> +- rpm-level		: UFS Runtime power management level. Following PM levels are supported:
> +			  0 - Both UFS device and Link in active state (Highest power consumption)
> +			  1 - UFS device in active state but Link in Hibern8 state
> +			  2 - UFS device in Sleep state but Link in active state
> +			  3 - UFS device in Sleep state and Link in hibern8 state (default PM level)
> +			  4 - UFS device in Power-down state and Link in Hibern8 state
> +			  5 - UFS device in Power-down state and Link in OFF state (Lowest power consumption)
> +- spm-level		: UFS System power management level. Allowed PM levels are same as rpm-level.

This looks like you are putting policy for Linux into DT.

What I would expect to see here is disabling of states that don't work 
due to some h/w limitation. Otherwise, it is a user decision for what 
modes to go into. Also, I think link and device states should be 
separate.

Rob

^ permalink raw reply

* Re: [PATCH v4 4/4] regulator: Prevent falling too fast
From: Doug Anderson @ 2016-12-13 20:00 UTC (permalink / raw)
  To: Mark Brown
  Cc: Matthias Kaehlcke, Liam Girdwood, Brian Norris,
	Javier Martinez Canillas, Rob Herring, Mark Rutland,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20161213171904.ohsxc3xhscdinctt@sirena.org.uk>

Hi,

On Tue, Dec 13, 2016 at 9:19 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Dec 12, 2016 at 01:15:02PM -0800, Matthias Kaehlcke wrote:
>> El Fri, Oct 28, 2016 at 07:15:21PM +0100 Mark Brown ha dit:
>> > On Mon, Sep 26, 2016 at 10:41:59AM -0700, Doug Anderson wrote:
>
>> > What you're describing to me is a discrete DCDC that has an input
>> > voltage that sets the output voltage which happens to be set with a PWM.
>
>> I experimented a bit with this. Besides the question of how to model
>> the passives I wonder how the two regulators would interact. The
>> correct thing seems to be to specify the input regulator as a supply
>> of the DCDC. dcdc->set_voltage breaks down a voltage transition into
>
> No, not unless the prior descriptions of the hardware have been wildly
> inaccurate - my understanding had been that the DCDC was a normal DCDC
> with an analogue input intended to be biased to set the output voltage
> (presumably in terms of a full rail supply) and that the PWM had been
> connected to this analogue input.  If the PWM is supplying the DCDC then
> the hardware design just seems bizzare, I can't see how this would even
> work.

Looking at one schematic, the discrete BUCK for at least one of the
rails is TPS65261RHBR, which appears to be described at
<https://store.ti.com/TPS65261RHBR.aspx>.  Data sheet appears to be at
<http://www.ti.com/product/tps65261/technicaldocuments?HQS=TI-null-null-octopart-df-pf-null-wwe>.

As you can see from the datasheet ("Adjusting the Output Voltage"
section), it is intended that you stuff a resistor to make a voltage
divider and that's how you select the output voltage.  In our case the
PWM interacts here and allows you to make a more dynamic output
voltage.  I've always thought about the input to the "FB" pin as
making an input voltage, but I guess it's not terribly simple since
the voltage divider ends up dividing between ground and the output
voltage.

Also as you can see, the datasheet never talks about using a PWM to
control the feedback and as I understand it the BUCK wasn't designed
for this, but it (mostly) works just fine.

...you can also see details about the Over Voltage Protection (at last
for this BUCK) in the TPS65261RHBR datasheet.


-Doug

^ permalink raw reply

* Re: [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Rob Herring @ 2016-12-13 19:54 UTC (permalink / raw)
  To: Guy Shapiro
  Cc: Fabio Estevam, Mark Rutland, devicetree@vger.kernel.org,
	Haibo Chen, Dmitry Torokhov, linux-input@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <1481440003-27168-1-git-send-email-guy.shapiro@mobi-wize.com>

On Sun, Dec 11, 2016 at 1:06 AM, Guy Shapiro <guy.shapiro@mobi-wize.com> wrote:
> Make the avarage-samples property a general touchscreen property
> rather than imx6ul device specific.
>
> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
> ---
>  .../bindings/input/touchscreen/imx6ul_tsc.txt      | 11 ++----
>  .../bindings/input/touchscreen/touchscreen.txt     |  3 ++
>  drivers/input/touchscreen/imx6ul_tsc.c             | 46 ++++++++++++++++------
>  3 files changed, 41 insertions(+), 19 deletions(-)

[...]

> +       switch (average_samples) {
> +       case 1:
> +               tsc->average_enable = false;
> +               tsc->average_select = 0; /* value unused; initialize anyway */
> +               break;
> +       case 4:
> +               tsc->average_enable = true;
> +               tsc->average_select = 0;
> +               break;
> +       case 8:
> +               tsc->average_enable = true;
> +               tsc->average_select = 1;
> +               break;
> +       case 16:
> +               tsc->average_enable = true;
> +               tsc->average_select = 2;
> +               break;
> +       case 32:
> +               tsc->average_enable = true;
> +               tsc->average_select = 3;
> +               break;

This could be more efficiently written as

tsc->average_select = log2(average_samples) - 2;

Then enable if >=0.

Rob

^ permalink raw reply

* [PATCH v2 07/12] scsi: ufs: add option to change default UFS power management level
From: Subhash Jadavani @ 2016-12-13 19:51 UTC (permalink / raw)
  To: vinholikatti, jejb, martin.petersen
  Cc: linux-scsi, Subhash Jadavani, Rob Herring, Mark Rutland,
	Hannes Reinecke, Yaniv Gardi, Gilad Broner, Joao Pinto,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list

UFS device and link can be put in multiple different low power modes hence
UFS driver supports multiple different low power modes. By default UFS
driver selects the default (optimal) low power mode (which gives moderate
power savings and have relatively less enter and exit latencies) but
we might have to tune this default power mode for different chipset
platforms to meet the low power requirements/goals. Hence this patch
adds option to change default UFS low power mode (level).

Reviewed-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
---
 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      | 10 ++++++
 drivers/scsi/ufs/ufshcd-pltfrm.c                   | 14 ++++++++
 drivers/scsi/ufs/ufshcd.c                          | 39 ++++++++++++++++++++++
 drivers/scsi/ufs/ufshcd.h                          |  4 +--
 4 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index a99ed55..c3836c5 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -41,6 +41,14 @@ Optional properties:
 -lanes-per-direction	: number of lanes available per direction - either 1 or 2.
 			  Note that it is assume same number of lanes is used both
 			  directions at once. If not specified, default is 2 lanes per direction.
+- rpm-level		: UFS Runtime power management level. Following PM levels are supported:
+			  0 - Both UFS device and Link in active state (Highest power consumption)
+			  1 - UFS device in active state but Link in Hibern8 state
+			  2 - UFS device in Sleep state but Link in active state
+			  3 - UFS device in Sleep state and Link in hibern8 state (default PM level)
+			  4 - UFS device in Power-down state and Link in Hibern8 state
+			  5 - UFS device in Power-down state and Link in OFF state (Lowest power consumption)
+- spm-level		: UFS System power management level. Allowed PM levels are same as rpm-level.
 
 Note: If above properties are not defined it can be assumed that the supply
 regulators or clocks are always on.
@@ -66,4 +74,6 @@ Example:
 		freq-table-hz = <100000000 200000000>, <0 0>, <0 0>;
 		phys = <&ufsphy1>;
 		phy-names = "ufsphy";
+		rpm-level = <3>;
+		spm-level = <5>;
 	};
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index a72a4ba..896943d 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -223,6 +223,19 @@ static int ufshcd_parse_regulator_info(struct ufs_hba *hba)
 	return err;
 }
 
+static void ufshcd_parse_pm_levels(struct ufs_hba *hba)
+{
+	struct device *dev = hba->dev;
+	struct device_node *np = dev->of_node;
+
+	if (np) {
+		if (of_property_read_u32(np, "rpm-level", &hba->rpm_lvl))
+			hba->rpm_lvl = -1;
+		if (of_property_read_u32(np, "spm-level", &hba->spm_lvl))
+			hba->spm_lvl = -1;
+	}
+}
+
 #ifdef CONFIG_PM
 /**
  * ufshcd_pltfrm_suspend - suspend power management function
@@ -342,6 +355,7 @@ int ufshcd_pltfrm_init(struct platform_device *pdev,
 		goto dealloc_host;
 	}
 
+	ufshcd_parse_pm_levels(hba);
 	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
 
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 982802c..c5e4b86 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -191,6 +191,22 @@ enum {
 	return ufs_pm_lvl_states[lvl].link_state;
 }
 
+static inline enum ufs_pm_level
+ufs_get_desired_pm_lvl_for_dev_link_state(enum ufs_dev_pwr_mode dev_state,
+					enum uic_link_state link_state)
+{
+	enum ufs_pm_level lvl;
+
+	for (lvl = UFS_PM_LVL_0; lvl < UFS_PM_LVL_MAX; lvl++) {
+		if ((ufs_pm_lvl_states[lvl].dev_state == dev_state) &&
+			(ufs_pm_lvl_states[lvl].link_state == link_state))
+			return lvl;
+	}
+
+	/* if no match found, return the level 0 */
+	return UFS_PM_LVL_0;
+}
+
 static struct ufs_dev_fix ufs_fixups[] = {
 	/* UFS cards deviations table */
 	UFS_FIX(UFS_VENDOR_SAMSUNG, UFS_ANY_MODEL,
@@ -215,6 +231,14 @@ enum {
 	END_FIX
 };
 
+static inline bool ufshcd_is_valid_pm_lvl(int lvl)
+{
+	if (lvl >= 0 && lvl < ARRAY_SIZE(ufs_pm_lvl_states))
+		return true;
+	else
+		return false;
+}
+
 static void ufshcd_tmc_handler(struct ufs_hba *hba);
 static void ufshcd_async_scan(void *data, async_cookie_t cookie);
 static int ufshcd_reset_and_restore(struct ufs_hba *hba);
@@ -7290,6 +7314,21 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 		ufshcd_clkscaling_init_sysfs(hba);
 	}
 
+	/*
+	 * If rpm_lvl and and spm_lvl are not already set to valid levels,
+	 * set the default power management level for UFS runtime and system
+	 * suspend. Default power saving mode selected is keeping UFS link in
+	 * Hibern8 state and UFS device in sleep.
+	 */
+	if (!ufshcd_is_valid_pm_lvl(hba->rpm_lvl))
+		hba->rpm_lvl = ufs_get_desired_pm_lvl_for_dev_link_state(
+							UFS_SLEEP_PWR_MODE,
+							UIC_LINK_HIBERN8_STATE);
+	if (!ufshcd_is_valid_pm_lvl(hba->spm_lvl))
+		hba->spm_lvl = ufs_get_desired_pm_lvl_for_dev_link_state(
+							UFS_SLEEP_PWR_MODE,
+							UIC_LINK_HIBERN8_STATE);
+
 	/* Hold auto suspend until async scan completes */
 	pm_runtime_get_sync(dev);
 
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 787323b..97fbe4a 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -432,9 +432,9 @@ struct ufs_hba {
 	enum ufs_dev_pwr_mode curr_dev_pwr_mode;
 	enum uic_link_state uic_link_state;
 	/* Desired UFS power management level during runtime PM */
-	enum ufs_pm_level rpm_lvl;
+	int rpm_lvl;
 	/* Desired UFS power management level during system PM */
-	enum ufs_pm_level spm_lvl;
+	int spm_lvl;
 	struct device_attribute rpm_lvl_attr;
 	struct device_attribute spm_lvl_attr;
 	int pm_op_in_progress;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related

* Re: [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Rob Herring @ 2016-12-13 19:48 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Fabio Estevam, Mark Rutland, Guy Shapiro,
	devicetree@vger.kernel.org, Haibo Chen,
	linux-input@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1CDAF0C6-25E1-4CE9-8F98-F07333827B98@gmail.com>

On Tue, Dec 13, 2016 at 1:14 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On December 13, 2016 11:10:50 AM PST, Rob Herring <robh@kernel.org> wrote:
>>On Sun, Dec 11, 2016 at 09:06:43AM +0200, Guy Shapiro wrote:
>>> Make the avarage-samples property a general touchscreen property
>>> rather than imx6ul device specific.
>>>
>>> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
>>> ---
>>>  .../bindings/input/touchscreen/imx6ul_tsc.txt      | 11 ++----
>>>  .../bindings/input/touchscreen/touchscreen.txt     |  3 ++
>>>  drivers/input/touchscreen/imx6ul_tsc.c             | 46
>>++++++++++++++++------
>>>  3 files changed, 41 insertions(+), 19 deletions(-)
>>
>>You can't just switch existing bindings as that breaks compatibility
>>with old dtbs. The kernel driver would need to support both. Just
>>introduce the new common property and use it for your device.
>>
>
> The old binding is only in my tree at the moment, so I do not think there is compatibility concerns.
>
> Are you OK with the new binding itself?

Ah, then yes. For the binding:

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v2 2/2] ASoC: cs43130: Add devicetree bindings for CS43130
From: Rob Herring @ 2016-12-13 19:46 UTC (permalink / raw)
  To: Li Xu
  Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
	mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
	brian.austin-jGc1dHjMKG3QT0dZR+AlfA,
	Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA
In-Reply-To: <63e40838-0226-4f9d-ab41-5815c724e9ef-XU/xxMRwCJnfk+Ne4bZl5AC/G2K4zDHf@public.gmane.org>

On Mon, Dec 12, 2016 at 02:17:31PM -0600, Li Xu wrote:
> Add devicetree bindings documentation file for Cirrus
> Logic CS43130 codec.
> 
> Signed-off-by: Li Xu <li.xu-jGc1dHjMKG3QT0dZR+AlfA@public.gmane.org>
> ---
>  .../devicetree/bindings/sound/cs43130.txt          | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/cs43130.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v4 4/4] mtd: spi-nor: add a label property to jedec,spi-nor
From: Rob Herring @ 2016-12-13 19:46 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
	Joel Stanley
In-Reply-To: <1481557252-13656-5-git-send-email-clg-Bxea+6Xhats@public.gmane.org>

On Mon, Dec 12, 2016 at 04:40:52PM +0100, Cédric Le Goater wrote:
> This can be used to easily identify a chip on a system with multiple
> chips.
> 
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v4 3/4] mtd: spi-nor: bindings for the Aspeed memory controllers
From: Rob Herring @ 2016-12-13 19:45 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
	Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
	Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
	Joel Stanley
In-Reply-To: <1481557252-13656-4-git-send-email-clg-Bxea+6Xhats@public.gmane.org>

On Mon, Dec 12, 2016 at 04:40:51PM +0100, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> ---
>  .../devicetree/bindings/mtd/aspeed-smc.txt         | 51 ++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v2] PCI: rockchip: Add quirk to disable RC's ASPM L0s
From: Rob Herring @ 2016-12-13 19:41 UTC (permalink / raw)
  To: Shawn Lin
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Wenrui Li,
	linux-pci-u79uwXL29TY76Z2rM5mHXA, Jeffy Chen, Brian Norris,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Bjorn Helgaas
In-Reply-To: <1481543487-33152-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

On Mon, Dec 12, 2016 at 07:51:27PM +0800, Shawn Lin wrote:
> Rockchip's RC outputs 100MHz reference clock but there are
> two methods for PHY to generate it.
> 
> (1)One of them is to use system PLL to generate 100MHz clock and
> the PHY will relock it and filter signal noise then outputs the
> reference clock.
> 
> (2)Another way is to share Soc's 24MHZ crystal oscillator with
> PHY and force PHY's DLL to generate 100MHz internally.
> 
> When using case(2), the exit from L0s doesn't work fine occasionally
> due to the broken design of RC receiver's logical circuit. So even if
> we use extended-synch, it still fails for PHY to relock the bits from
> FTS sometimes. This will hang the system.
> 
> Maybe we could argue that why not use case(1) to avoid it? The reason
> is that as we could see the reference clock is derived from system PLL
> and the path from it to PHY isn't so clean which means there are some
> noise introduced by power-domain and other buses can't be filterd out
> by PHY and we could see noise from the frequency spectrum by
> oscilloscope. This makes the TX compatibility test a little difficult
> to pass the spec. So case(1) and case(2) are both used indeed now. If
> using case(2), we should disable RC's L0s support, and that is why we
> need this property to indicate this quirk.
> 
> Also after checking quirk.c, I noticed there is already a quirk for
> disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
> shouldn't do that as mentioned above that case(1) could still works fine
> with L0s.
> 
> Reported-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Cc: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> 
> ---
> 
> Changes in v2:
> - drop the quirk prefix
> 
>  Documentation/devicetree/bindings/pci/rockchip-pcie.txt | 2 ++
>  drivers/pci/host/pcie-rockchip.c                        | 9 +++++++++
>  2 files changed, 11 insertions(+)

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

^ permalink raw reply

* Re: [PATCH 2/3] power: supply: bq24735-charger: optionally poll the ac-detect gpio
From: Rob Herring @ 2016-12-13 19:30 UTC (permalink / raw)
  To: Peter Rosin
  Cc: linux-kernel, Sebastian Reichel, Mark Rutland, linux-pm,
	devicetree
In-Reply-To: <1481540424-19293-3-git-send-email-peda@axentia.se>

On Mon, Dec 12, 2016 at 12:00:23PM +0100, Peter Rosin wrote:
> If the ac-detect gpio does not support interrupts, provide a fallback
> to poll the gpio at a configurable interval.
> 
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>  .../bindings/power/supply/ti,bq24735.txt           |  2 +
>  drivers/power/supply/bq24735-charger.c             | 50 +++++++++++++++++++---
>  2 files changed, 47 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> index 3bf55757ceec..59c4dde589cf 100644
> --- a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> +++ b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> @@ -25,6 +25,8 @@ Optional properties :
>   - ti,external-control : Indicates that the charger is configured externally
>     and that the host should not attempt to enable/disable charging or set the
>     charge voltage/current.
> + - ti,poll-interval-ms : In case there is no interrupts specified, poll AC
> +   presense on the ti,ac-detect-gpios GPIO with this interval.

We already have poll-interval and cm-poll-interval properties. Just use 
poll-interval here.

Rob

^ permalink raw reply

* Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches
From: Rob Herring @ 2016-12-13 19:27 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Mark Rutland, linux-iio, devicetree,
	linux-kernel, Kevin Hilman, Patrick Titiano, Neil Armstrong,
	Linus Walleij, Alexandre Courbot, linux-gpio, Sebastian Reichel,
	linux-pm, Mark Brown, Liam Girdwood
In-Reply-To: <1481494905-18037-2-git-send-email-bgolaszewski@baylibre.com>

On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
> Some boards are equipped with simple, GPIO-driven power load switches.
> An example of such ICs is the TI tps229* series.

How is this different than a GPIO regulator? The input and output 
voltages just happen to be the same. I could be convinced this is 
different enough to have a different compatible, but it somewhat seems 
you want to use this for IIO, so you are creating a different binding 
for that usecase.

Rob

^ permalink raw reply

* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-13 19:18 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski
  Cc: Mark Rutland, devicetree, linux-samsung-soc, linux-pm, Ben Gamari,
	linux-kernel, Russell King, Rob Herring, Doug Anderson,
	Kukjin Kim, Thomas Abraham, Andreas Faerber, linux-arm-kernel
In-Reply-To: <5220084.l31t5oJbsy@amdc3058>

Hello Bartlomiej,

On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> (for A7 cores).  Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> cooling maps to account for new OPPs.
> 
> Since new OPPs are not available on all Exynos5422/5800 boards modify
> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> 
> Tested on Odroid-XU3 and XU3 Lite.
> 
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Thomas Abraham <thomas.ab@samsung.com>
> Cc: Ben Gamari <ben@smart-cactus.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |   14 +++++++-------
>  arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts    |   17 +++++++++++++++++
>  arch/arm/boot/dts/exynos5800-peach-pi.dts          |    4 ++++
>  arch/arm/boot/dts/exynos5800.dtsi                  |   15 +++++++++++++++
>  4 files changed, 43 insertions(+), 7 deletions(-)
> 
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi	2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi	2016-12-13 15:59:33.775763261 +0100
> @@ -118,7 +118,7 @@
>  				/*
>  				 * When reaching cpu_alert3, reduce CPU
>  				 * by 2 steps. On Exynos5422/5800 that would
> -				 * be: 1600 MHz and 1100 MHz.
> +				 * (usually) be: 1800 MHz and 1200 MHz.
>  				 */
>  				map3 {
>  					trip = <&cpu_alert3>;
> @@ -131,16 +131,16 @@
>  
>  				/*
>  				 * When reaching cpu_alert4, reduce CPU
> -				 * further, down to 600 MHz (11 steps for big,
> -				 * 7 steps for LITTLE).
> +				 * further, down to 600 MHz (13 steps for big,
> +				 * 8 steps for LITTLE).
>  				 */
> -				map5 {
> +				cooling_map5: map5 {
>  					trip = <&cpu_alert4>;
> -					cooling-device = <&cpu0 3 7>;
> +					cooling-device = <&cpu0 3 8>;
>  				};
> -				map6 {
> +				cooling_map6: map6 {
>  					trip = <&cpu_alert4>;
> -					cooling-device = <&cpu4 3 11>;
> +					cooling-device = <&cpu4 3 13>;
>  				};
>  			};
>  		};
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts	2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts	2016-12-13 15:59:33.775763261 +0100
> @@ -21,6 +21,23 @@
>  	compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>  };
>  
> +&cluster_a15_opp_table {
> +	/delete-node/opp@2000000000;
> +	/delete-node/opp@1900000000;
> +};
> +
> +&cluster_a7_opp_table {
> +	/delete-node/opp@1400000000;
> +};
> +

I think that a comment in the DTS why these operating points aren't available
in this board will make more clear why the nodes are being deleted.

> +&cooling_map5 {
> +	cooling-device = <&cpu0 3 7>;
> +};
> +
> +&cooling_map6 {
> +	cooling-device = <&cpu4 3 11>;
> +};
> +
>  &pwm {
>  	/*
>  	 * PWM 0 -- fan
> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts	2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts	2016-12-13 15:59:33.779763261 +0100
> @@ -146,6 +146,10 @@
>  	vdd-supply = <&ldo9_reg>;
>  };
>  
> +&cluster_a7_opp_table {
> +	/delete-property/opp@1400000000;
> +};
> +
>  &cpu0 {
>  	cpu-supply = <&buck2_reg>;
>  };
> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800.dtsi	2016-12-13 15:59:33.779763261 +0100
> +++ b/arch/arm/boot/dts/exynos5800.dtsi	2016-12-13 15:59:33.779763261 +0100
> @@ -24,6 +24,16 @@
>  };
>  
>  &cluster_a15_opp_table {
> +	opp@2000000000 {
> +		opp-hz = /bits/ 64 <2000000000>;
> +		opp-microvolt = <1250000>;
> +		clock-latency-ns = <140000>;
> +	};
> +	opp@1900000000 {
> +		opp-hz = /bits/ 64 <1900000000>;
> +		opp-microvolt = <1250000>;
> +		clock-latency-ns = <140000>;
> +	};
>  	opp@1700000000 {
>  		opp-microvolt = <1250000>;
>  	};
> @@ -85,6 +95,11 @@
>  };
>

AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
INT rail would need to be scaled up as well since there's a maximum voltage
difference between the ARM and INT rails before the system becomes unstable:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
https://lkml.org/lkml/2014/5/2/419

The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
the maximum voltage skew is between a limit. But that never made to mainline:

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
https://lkml.org/lkml/2014/4/29/28

Did that change and there's infrastructure in mainline now to cope with that?
If that's the case, I think it would be good to mention in the commit message.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

^ permalink raw reply

* Re: [PATCH 6/6] ARM: dts: sun8i: raise the max voltage of DCDC2 in sun8i reference tablets
From: Maxime Ripard @ 2016-12-13 19:14 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: devicetree, Quentin Schulz, Michael Turquette, Stephen Boyd,
	Russell King, linux-kernel, Hans de Goede, Chen-Yu Tsai,
	linux-clk, linux-arm-kernel, Jorik Jonker
In-Reply-To: <20161213152252.53749-7-icenowy@aosc.xyz>


[-- Attachment #1.1: Type: text/plain, Size: 1168 bytes --]

On Tue, Dec 13, 2016 at 11:22:52PM +0800, Icenowy Zheng wrote:
> The "extremity_freq" frequency described in the original FEX files uses
> a voltage of 1.46v, which is beyond the current maximum voltage value of
> DCDC2 (Cortex-A7 supply) in the sun8i reference tablet DTSI file.
> 
> Raise the maximum value to 1.46v.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>  arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
> index 7ac8bb4bc95a..325ca5bd67a5 100644
> --- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
> @@ -180,7 +180,7 @@
>  &reg_dcdc2 {
>  	regulator-always-on;
>  	regulator-min-microvolt = <900000>;
> -	regulator-max-microvolt = <1400000>;
> +	regulator-max-microvolt = <1460000>;

This is outside of the voltage range tolerated by the CPU. NAK.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Dmitry Torokhov @ 2016-12-13 19:14 UTC (permalink / raw)
  To: Rob Herring, Guy Shapiro
  Cc: fabio.estevam, mark.rutland, devicetree, haibo.chen, linux-input,
	linux-arm-kernel
In-Reply-To: <20161213191050.3yrmxaubpgjh65bz@rob-hp-laptop>

On December 13, 2016 11:10:50 AM PST, Rob Herring <robh@kernel.org> wrote:
>On Sun, Dec 11, 2016 at 09:06:43AM +0200, Guy Shapiro wrote:
>> Make the avarage-samples property a general touchscreen property
>> rather than imx6ul device specific.
>> 
>> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
>> ---
>>  .../bindings/input/touchscreen/imx6ul_tsc.txt      | 11 ++----
>>  .../bindings/input/touchscreen/touchscreen.txt     |  3 ++
>>  drivers/input/touchscreen/imx6ul_tsc.c             | 46
>++++++++++++++++------
>>  3 files changed, 41 insertions(+), 19 deletions(-)
>
>You can't just switch existing bindings as that breaks compatibility 
>with old dtbs. The kernel driver would need to support both. Just 
>introduce the new common property and use it for your device.
>

The old binding is only in my tree at the moment, so I do not think there is compatibility concerns.

Are you OK with the new binding itself?


Thanks.

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH 5/6] ARM: dts: sun8i: set cpu-supply in reference tablet DTSI
From: Maxime Ripard @ 2016-12-13 19:13 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: devicetree, Quentin Schulz, Michael Turquette, Stephen Boyd,
	Russell King, linux-kernel, Hans de Goede, Chen-Yu Tsai,
	linux-clk, linux-arm-kernel, Jorik Jonker
In-Reply-To: <20161213152252.53749-6-icenowy@aosc.xyz>


[-- Attachment #1.1: Type: text/plain, Size: 422 bytes --]

On Tue, Dec 13, 2016 at 11:22:51PM +0800, Icenowy Zheng wrote:
> All reference design A33 tablets uses DCDC2 of AXP223 as the power
> supply of the Cortex-A7 cores.
> 
> Set the cpu-supply in the DTSI of sun8i reference tablets.
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>

Applied, thanks

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 4/6] ARM: dts: sun8i: add opp-v2 table for A33
From: Maxime Ripard @ 2016-12-13 19:12 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: devicetree, Quentin Schulz, Michael Turquette, Stephen Boyd,
	Russell King, linux-kernel, Hans de Goede, Chen-Yu Tsai,
	linux-clk, linux-arm-kernel, Jorik Jonker
In-Reply-To: <20161213152252.53749-5-icenowy@aosc.xyz>


[-- Attachment #1.1: Type: text/plain, Size: 2286 bytes --]

On Tue, Dec 13, 2016 at 11:22:50PM +0800, Icenowy Zheng wrote:
> An operating point table is needed for the cpu frequency adjusting to
> work.
> 
> The operating point table is converted from the common value in
> extracted script.fex from many A33 board/tablets.
> 
> 1.344GHz is set as a turbo-mode operating point, as it's described as
> "extremity_freq" in the FEX file. (the "max_freq" is 1.2GHz)
> 
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>  arch/arm/boot/dts/sun8i-a33.dtsi | 38 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 504996cbee29..035c058324b8 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -46,7 +46,45 @@
>  #include <dt-bindings/dma/sun4i-a10.h>
>  
>  / {
> +	cpu0_opp_table: opp_table0 {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp@648000000 {
> +			opp-hz = /bits/ 64 <648000000>;
> +			opp-microvolt = <1040000>;
> +			clock-latency-ns = <244144>; /* 8 32k periods */
> +		};

Please add new lines between the nodes.

> +		opp@816000000 {
> +			opp-hz = /bits/ 64 <816000000>;
> +			opp-microvolt = <1100000>;
> +			clock-latency-ns = <244144>; /* 8 32k periods */
> +		};
> +		opp@1008000000 {
> +			opp-hz = /bits/ 64 <1008000000>;
> +			opp-microvolt = <1200000>;
> +			clock-latency-ns = <244144>; /* 8 32k periods */
> +		};
> +		opp@1200000000 {
> +			opp-hz = /bits/ 64 <1200000000>;
> +			opp-microvolt = <1320000>;
> +			clock-latency-ns = <244144>; /* 8 32k periods */
> +		};
> +		opp@1344000000 {
> +			opp-hz = /bits/ 64 <1344000000>;
> +			opp-microvolt = <1460000>;
> +			clock-latency-ns = <244144>; /* 8 32k periods */
> +			turbo-mode;
> +		};

As far as I know, this OPP is not used by Allwinner, is not usable in
any A33 board so far (both the A33-olinuxino and the SinA33 do not
allow such a voltage on their CPU regulator), and overvolting and
overclocking is something that is very risky, and might lead to
stability issues.

Please remove this OPP.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] Input: imx6ul_tsc - generalize the averaging property
From: Rob Herring @ 2016-12-13 19:10 UTC (permalink / raw)
  To: Guy Shapiro
  Cc: dmitry.torokhov, fabio.estevam, mark.rutland, devicetree,
	haibo.chen, linux-input, linux-arm-kernel
In-Reply-To: <1481440003-27168-1-git-send-email-guy.shapiro@mobi-wize.com>

On Sun, Dec 11, 2016 at 09:06:43AM +0200, Guy Shapiro wrote:
> Make the avarage-samples property a general touchscreen property
> rather than imx6ul device specific.
> 
> Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
> ---
>  .../bindings/input/touchscreen/imx6ul_tsc.txt      | 11 ++----
>  .../bindings/input/touchscreen/touchscreen.txt     |  3 ++
>  drivers/input/touchscreen/imx6ul_tsc.c             | 46 ++++++++++++++++------
>  3 files changed, 41 insertions(+), 19 deletions(-)

You can't just switch existing bindings as that breaks compatibility 
with old dtbs. The kernel driver would need to support both. Just 
introduce the new common property and use it for your device.

Rob

^ permalink raw reply

* Re: [PATCH v6 2/2] Add support for OV5647 sensor.
From: Pavel Machek @ 2016-12-13 19:09 UTC (permalink / raw)
  To: Ramiro Oliveira
  Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-media-u79uwXL29TY76Z2rM5mHXA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
	dheitmueller-eb9eJ82Ua7k9XoPSrs7Ehg,
	slongerbeam-Re5JQEeQqe8AvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
	robert.jarzmik-GANU6spQydw, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
	sakari.ailus-VuQAYsv1563Yd54FQh9/CA, mark.rutland-5wv7dgnIgG8,
	CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <d8ac513cd1d84063f73452e0b3ab12ab5f5728a0.1481639091.git.roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

On Tue 2016-12-13 14:32:37, Ramiro Oliveira wrote:
> Modes supported:
>  - 640x480 RAW 8
> 
> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>

Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply

* Re: [PATCH v6 1/2] Add OV5647 device tree documentation
From: Pavel Machek @ 2016-12-13 19:05 UTC (permalink / raw)
  To: Ramiro Oliveira
  Cc: mchehab, linux-kernel, linux-media, robh+dt, devicetree, davem,
	gregkh, geert+renesas, akpm, linux, hverkuil, dheitmueller,
	slongerbeam, lars, robert.jarzmik, pali.rohar, sakari.ailus,
	mark.rutland, CARLOS.PALMINHA
In-Reply-To: <c47834c1c9c2a8e23f41a12c8717601f4a901506.1481639091.git.roliveir@synopsys.com>

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

On Tue 2016-12-13 14:32:36, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
> 
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index 0000000..46e5e30
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +---------------------------------
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible	: "ovti,ov5647";
> +- reg		: I2C slave address of the sensor;
> +- clocks	: Reference to the xclk clock.
> +- clock-names	: Should be "xclk".
> +- clock-frequency: Frequency of the xclk clock

Nit pick: you end the lines here with ';', '.' and nothing. Pick one
:-).

Otherwise it looks good.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ 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