Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Jonathan Cameron @ 2016-12-19 20:49 UTC (permalink / raw)
  To: Andreas Klinger, devicetree, linux-iio
  Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
	galak, knaack.h, lars, pmeerw
In-Reply-To: <20161214161740.GA13896@andreas>

On 14/12/16 16:17, Andreas Klinger wrote:
> This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> cells.
> 
> The protocol is quite simple and using GPIOs:
> One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
Youch. Controlling the next conversion via the number of clocks is hideous!
Oh well, guess it's one solution that limits the number of wires needed.

Still not as hideous as some ;) (sht15 I'm looking at you :)

Few comments inline.

Jonathan

> 
> The raw value read from the chip is delivered. 
> To get a weight one needs to subtract the zero offset and scale it.
> 
> Signed-off-by: Andreas Klinger <ak@it-klinger.de>
> ---
>  drivers/iio/adc/Kconfig  |  18 +++
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/hx711.c  | 292 +++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 311 insertions(+)
>  create mode 100644 drivers/iio/adc/hx711.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 932de1f9d1e7..918f582288c9 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -205,6 +205,24 @@ 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
Typically just called weigh cells rather than weight cells.
One of those ugly bits of English.
> +
> +	  This driver uses two GPIOs, one for setting the clock and the other
> +	  one for getting the data
This driver uses two GPIOs, one acts as the clock and controls the channel
selection and gain, the other is used for the measurement data
(or something like that).
> +
> +	  Currently the raw value is read from the chip and delivered.
> +	  For getting an actual weight one needs to subtract the
To get an actual weight...
> +	  zero offset and multiply by a scale factor.
> +	  This should be done in userspace.
> +
> +	  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..700281932ff0
> --- /dev/null
> +++ b/drivers/iio/adc/hx711.c
> @@ -0,0 +1,292 @@
> +/*
> + * HX711: analog to digital converter for weight sensor module
> + *
> + * Copyright (c) 2016 Andreas Klinger <ak@it-klinger.de>
> + *
> + * 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.
> + *
No need for this blank line.
> + */
> +#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>
> +#include <linux/iio/sysfs.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 */
> +
> +struct hx711_data {
> +	struct device		*dev;
> +	struct gpio_desc	*gpiod_sck;
> +	struct gpio_desc	*gpiod_dout;
> +	int			gain_pulse;
> +	struct mutex		lock;
> +};
> +
> +static int hx711_reset(struct hx711_data *hx711_data)
> +{
> +	int i, val;
> +
> +	val = gpiod_get_value(hx711_data->gpiod_dout);
> +	if (val) {
> +		gpiod_set_value(hx711_data->gpiod_sck, 1);
> +		udelay(80);
a comment here on why 80 would be good (it's bigger than 60?)
> +		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 */
> +			msleep(1);
> +		}
> +	}
> +
> +	return val;
> +}
> +
> +static int hx711_cycle(struct hx711_data *hx711_data)
> +{
> +	int val;
> +
/*
 * if pre...
> +	/* 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);
I'm reading the datasheet as suggesting you need to wait at least 0.1 microsecs
here...
> +	val = gpiod_get_value(hx711_data->gpiod_dout);
> +	gpiod_set_value(hx711_data->gpiod_sck, 0);
> +	preempt_enable();
> +
> +	return val;
> +}
> +
> +static int hx711_read(struct hx711_data *hx711_data)
> +{
> +	int i, ret;
> +	int value = 0;
> +
> +	mutex_lock(&hx711_data->lock);
> +
> +	if (hx711_reset(hx711_data)) {
> +		dev_err(hx711_data->dev, "reset failed!");
> +		mutex_unlock(&hx711_data->lock);
> +		return -1;
> +	}
> +
> +	for (i = 0; i < 24; i++) {
> +		value <<= 1;
> +		ret = hx711_cycle(hx711_data);
> +		if (ret)
> +			value++;
> +	}
> +
> +	value ^= 0x800000;
> +
> +	for (i = 0; i < hx711_data->gain_pulse; i++)
> +		ret = hx711_cycle(hx711_data);
> +
> +	mutex_unlock(&hx711_data->lock);
> +
> +	return value;
> +}
> +
> +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);
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		switch (chan->type) {
> +		case IIO_VOLTAGE:
> +			*val = hx711_read(hx711_data);
> +			return IIO_VAL_INT;
> +		default:
> +			return -EINVAL;
> +		}
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static ssize_t hx711_gain_show(struct device *dev,
> +				struct device_attribute *attr,
> +				char *buf)
> +{
> +	struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
> +	int val;
> +
> +	switch (hx711_data->gain_pulse) {
> +	case HX711_GAIN_32:
> +		val = 32;
> +		break;
> +	case HX711_GAIN_64:
> +		val = 64;
> +		break;
> +	default:
> +		val = 128;
> +	}
> +
> +	return sprintf(buf, "%d\n", val);
> +}
> +
> +static ssize_t hx711_gain_store(struct device *dev,
> +				struct device_attribute *attr,
> +				const char *buf, size_t len)
> +{
> +	struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
> +	int ret, val;
> +	int gain_save = hx711_data->gain_pulse;
> +
> +	ret = kstrtoint((const char *) buf, 10, &val);
> +	if (ret)
> +		return -EINVAL;
> +
> +	switch (val) {
> +	case 32:
> +		hx711_data->gain_pulse = HX711_GAIN_32;
> +		break;
> +	case 64:
> +		hx711_data->gain_pulse = HX711_GAIN_64;
> +		break;
> +	case 128:
> +		hx711_data->gain_pulse = HX711_GAIN_128;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	dev_dbg(hx711_data->dev, "gain_pulse: %d\n", hx711_data->gain_pulse);
> +
> +	/* if gain has changed do a fake read for the new gain to be set
> +	 *   for the next read
> +	 */
> +	if (gain_save != hx711_data->gain_pulse)
> +		hx711_read(hx711_data);
> +
> +	return len;
> +}
> +
> +static IIO_DEVICE_ATTR(gain, S_IRUGO | S_IWUSR,
> +	hx711_gain_show, hx711_gain_store, 0);
> +
> +static struct attribute *hx711_attributes[] = {
> +	&iio_dev_attr_gain.dev_attr.attr,
> +	NULL,
> +};
> +
As Lars suggested, please use standard ABI (easier if you use the info_mask
elements and do it through read raw...
> +static struct attribute_group hx711_attribute_group = {
> +	.attrs = hx711_attributes,
> +};
> +
> +static const struct iio_info hx711_iio_info = {
> +	.driver_module		= THIS_MODULE,
> +	.read_raw		= hx711_read_raw,
> +	.attrs			= &hx711_attribute_group,
> +};
> +
> +static const struct iio_chan_spec hx711_chan_spec[] = {
> +	{
new line here is slightly nicer to read.
>.type = IIO_VOLTAGE,
> +		.info_mask_separate =
> +			BIT(IIO_CHAN_INFO_RAW),
> +	},
> +};
> +
> +static int hx711_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct hx711_data *hx711_data = NULL;
> +	struct iio_dev *iio;
> +	int ret = 0;
> +
> +	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)) {
> +		dev_err(dev, "failed to get sck-gpiod: err=%ld\n",
> +					PTR_ERR(hx711_data->gpiod_sck));
> +		return PTR_ERR(hx711_data->gpiod_sck);
> +	}
> +
> +	hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
If there is a reason for getting an input as an output then it wants a comment!
> +	if (IS_ERR(hx711_data->gpiod_dout)) {
> +		dev_err(dev, "failed to get dout-gpiod: err=%ld\n",
> +					PTR_ERR(hx711_data->gpiod_dout));
> +		return PTR_ERR(hx711_data->gpiod_dout);
> +	}
> +
> +	ret = gpiod_direction_input(hx711_data->gpiod_dout);
> +	if (ret < 0) {
> +		dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
Doesn't the flag above already mean we are in output mode for this pin?
> +	if (ret < 0) {
> +		dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
> +		return ret;
> +	}
> +
> +	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);
> +
> +	return devm_iio_device_register(dev, iio);
> +}
> +
> +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",
> +		.of_match_table	= of_hx711_match,
> +	},
> +};
> +
> +module_platform_driver(hx711_driver);
> +
> +MODULE_AUTHOR("Andreas Klinger <ak@it-klinger.de>");
> +MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hx711-gpio");
> +
> 

^ permalink raw reply

* Re: [PATCH 2/2] regulator: rn5t618: add RC5T619 PMIC support
From: Pierre-Hugues Husson @ 2016-12-19 20:06 UTC (permalink / raw)
  To: Liam Girdwood
  Cc: Lee Jones, Rob Herring, Mark Rutland, devicetree, linux-kernel,
	Mark Brown
In-Reply-To: <20161109140258.25miftfbklwo3apz@sirena.org.uk>

Hi all,

I believe this hasn't been merged.
Is there anything preventing the merge of this patch?

Thanks,

2016-11-09 15:02 GMT+01:00 Mark Brown <broonie@kernel.org>:
> On Sat, Nov 05, 2016 at 05:19:25PM +0100, Pierre-Hugues Husson wrote:
>> Extend the driver to support Ricoh RC5T619.
>> Support the additional regulators and slightly different voltage ranges.
>
> Acked-by: Mark Brown <broonie@kernel.org>

^ permalink raw reply

* Re: [PATCH pci/next] PCI: rcar: Add compatible string for r8a7796
From: Yoshihiro Kaneko @ 2016-12-19 19:27 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: linux-pci, Bjorn Helgaas, Simon Horman, Magnus Damm,
	Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdVOUUM3hZ0sfTcs5PFqfvrYR9Sk3egibpuxb-4a80U02A@mail.gmail.com>

Hi Geert-san,

Thanks for your review.

2016-12-19 18:49 GMT+09:00 Geert Uytterhoeven <geert@linux-m68k.org>:
> Hi Kaneko-san,
>
> On Sun, Dec 18, 2016 at 1:27 PM, Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
>> From: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
>>
>> This patch adds support for r8a7796.
>>
>> Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
>> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>> ---
>>
>> This patch is based on the next branch of the pci tree.
>>
>>  Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
>>  drivers/pci/host/pcie-rcar.c                       | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
>> index eee518d..34712d6 100644
>> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
>> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
>> @@ -6,6 +6,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
>>             "renesas,pcie-r8a7791" for the R8A7791 SoC;
>>             "renesas,pcie-r8a7793" for the R8A7793 SoC;
>>             "renesas,pcie-r8a7795" for the R8A7795 SoC;
>> +           "renesas,pcie-r8a7796" for the R8A7796 SoC;
>>             "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
>>             "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
>>
>> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
>> index aca85be..02e5777 100644
>> --- a/drivers/pci/host/pcie-rcar.c
>> +++ b/drivers/pci/host/pcie-rcar.c
>> @@ -1078,6 +1078,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie *pcie,
>>         { .compatible = "renesas,pcie-rcar-gen2",
>>           .data = rcar_pcie_hw_init_gen2 },
>>         { .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
>> +       { .compatible = "renesas,pcie-r8a7796", .data = rcar_pcie_hw_init },
>>         { .compatible = "renesas,pcie-rcar-gen3", .data = rcar_pcie_hw_init },
>>         {},
>
> Given the driver already matches against "renesas,pcie-rcar-gen3",
> and mainline arch/arm64/boot/dts/renesas/r8a7796.dtsi doesn't have pcie
> nodes yet, I think there's no need to update the driver, only the bindings.

I agree with you.

>
> Hence if you drop the last chunk, you can add my
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

I will do it.

Thanks,
kaneko

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH v10 0/8] power: add power sequence library
From: Krzysztof Kozlowski @ 2016-12-19 19:15 UTC (permalink / raw)
  To: Peter Chen
  Cc: gregkh, stern, ulf.hansson, broonie, sre, robh+dt, shawnguo, rjw,
	dbaryshkov, heiko, linux-arm-kernel, p.zabel, devicetree,
	pawel.moll, mark.rutland, linux-usb, arnd, s.hauer, mail,
	troy.kisky, festevam, oscar, stephen.boyd, linux-pm,
	stillcompiling, linux-kernel, mka, vaibhav.hiremath, gary.bisson
In-Reply-To: <1479087359-7547-1-git-send-email-peter.chen@nxp.com>

On Mon, Nov 14, 2016 at 09:35:51AM +0800, Peter Chen wrote:
> Hi all,
> 
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
> 	 
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> 
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
> 
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
> 
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
> 
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> 
> Changes for v10:
> - Improve the kernel-doc for power sequence core, including exported APIs and
>   main structure. [Patch 2/8]
> - Change Kconfig, and let the user choose power sequence. [Patch 2/8]
> - Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not
>   be intended to export currently. [Patch 2/8]
> - Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8]

Hi Peter,

It is great that you continued the work on this.

I saw (in some previous mails) your repo mentioned:
https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/
Does it contain the recent version of this patchset?

I want to build on top of it fixes for usb3503 on Odroid U3 board.

Best regards,
Krzysztof

> 
> Changes for v9:
> - Add Vaibhav Hiremath's reviewed-by [Patch 4/8]
> - Rebase to v4.9-rc1
> 
> Changes for v8:
> - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
>   preallocate instances problem which the number of instance is decided at
>   compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> - Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
>   match method. [Patch 2/8]
> - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
> 
> Changes for v7:
> - Create kinds of power sequence instance at postcore_initcall, and match
>   the instance with node using compatible string, the beneit of this is
>   the host driver doesn't need to consider which pwrseq instance needs
>   to be used, and pwrseq core will match it, however, it eats some memories
>   if less power sequence instances are used. [Patch 2/8]
> - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8]
> - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
>   use device_node for parameters at pwrseq_on. [Patch 2/8]
> - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
> - Tested three pwrseq instances together using both specific compatible string and
>   generic libraries.
> 
> Changes for v6:
> - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> - Change chipidea core of_node assignment for coming user. (patch [5/6])
> - Applies Joshua Clayton's three dts changes for two boards,
>   the USB device's reg has only #address-cells, but without #size-cells.
> 
> Changes for v5:
> - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> - Fix the linker error when the pwrseq user is compiled as module
> 
> Changes for v4:
> - Create the patch on next-20160722 
> - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> - Using more friendly wait method for reset gpio [Patch 2/6]
> - Support multiple input clocks [Patch 2/6]
> - Add Rob Herring's ack for DT changes
> - Add Joshua Clayton's Tested-by
> 
> Changes for v3:
> - Delete "power-sequence" property at binding-doc, and change related code
>   at both library and user code.
> - Change binding-doc example node name with Rob's comments
> - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
>   add additional code request gpio with proper gpio flags
> - Add Philipp Zabel's Ack and MAINTAINER's entry
> 
> Changes for v2:
> - Delete "pwrseq" prefix and clock-names for properties at dt binding
> - Should use structure not but its pointer for kzalloc
> - Since chipidea core has no of_node, let core's of_node equals glue
>   layer's at core's probe
> 
> Joshua Clayton (2):
>   ARM: dts: imx6qdl: Enable usb node children with <reg>
>   ARM: dts: imx6q-evi: Fix onboard hub reset line
> 
> Peter Chen (6):
>   binding-doc: power: pwrseq-generic: add binding doc for generic power
>     sequence library
>   power: add power sequence library
>   binding-doc: usb: usb-device: add optional properties for power
>     sequence
>   usb: core: add power sequence handling for USB devices
>   usb: chipidea: let chipidea core device of_node equal's glue layer
>     device of_node
>   ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
> 
>  .../bindings/power/pwrseq/pwrseq-generic.txt       |  48 +++++
>  .../devicetree/bindings/usb/usb-device.txt         |  10 +-
>  MAINTAINERS                                        |   9 +
>  arch/arm/boot/dts/imx6q-evi.dts                    |  25 +--
>  arch/arm/boot/dts/imx6qdl-udoo.dtsi                |  26 ++-
>  arch/arm/boot/dts/imx6qdl.dtsi                     |   6 +
>  drivers/power/Kconfig                              |   1 +
>  drivers/power/Makefile                             |   1 +
>  drivers/power/pwrseq/Kconfig                       |  21 ++
>  drivers/power/pwrseq/Makefile                      |   2 +
>  drivers/power/pwrseq/core.c                        | 237 +++++++++++++++++++++
>  drivers/power/pwrseq/pwrseq_generic.c              | 183 ++++++++++++++++
>  drivers/usb/Kconfig                                |   1 +
>  drivers/usb/chipidea/core.c                        |  27 ++-
>  drivers/usb/core/hub.c                             |  41 +++-
>  drivers/usb/core/hub.h                             |   1 +
>  include/linux/power/pwrseq.h                       |  60 ++++++
>  17 files changed, 658 insertions(+), 41 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>  create mode 100644 drivers/power/pwrseq/Kconfig
>  create mode 100644 drivers/power/pwrseq/Makefile
>  create mode 100644 drivers/power/pwrseq/core.c
>  create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>  create mode 100644 include/linux/power/pwrseq.h
> 
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Rob Herring @ 2016-12-19 18:55 UTC (permalink / raw)
  To: Hoegeun Kwon
  Cc: thierry.reding, kgene, krzk, devicetree, linux-samsung-soc,
	Donghwa Lee, linux-kernel, dri-devel, Hyungwon Hwang
In-Reply-To: <1481695445-13088-2-git-send-email-hoegeun.kwon@samsung.com>

On Wed, Dec 14, 2016 at 03:04:04PM +0900, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
> 
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> ---
>  .../bindings/display/panel/samsung,s6e3ha2.txt     |  52 ++
>  drivers/gpu/drm/panel/Kconfig                      |   6 +
>  drivers/gpu/drm/panel/Makefile                     |   1 +
>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c      | 756 +++++++++++++++++++++
>  4 files changed, 815 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 0000000..1f41f24
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> @@ -0,0 +1,52 @@
> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3ha2"
> +  - reg: the virtual channel number of a DSI peripheral
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpios: a GPIO spec for the reset pin
> +  - enable-gpios: a GPIO spec for the panel enable pin
> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal gpio pin

Need to specify the GPIOs as active high or low.

> +
> +Optional properties:
> +  - display-timings: timings for the connected panel as described by [1]
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +	panel@0 {
> +		compatible = "samsung,s6e3ha2";
> +		reg = <0>;

reg doesn't really work here unless this node is a child of the DSI 
controller node. But if it is a child node, then you don't need the OF 
graph.

> +		vdd3-supply = <&ldo27_reg>;
> +		vci-supply = <&ldo28_reg>;
> +		reset-gpios = <&gpg0 0 GPIO_ACTIVE_HIGH>;
> +		enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> +		te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> +
> +		display-timings {
> +			timing-0 {
> +				clock-frequency = <0>;
> +				hactive = <1440>;
> +				vactive = <2560>;
> +				hfront-porch = <1>;
> +				hback-porch = <1>;
> +				hsync-len = <1>;
> +				vfront-porch = <1>;
> +				vback-porch = <15>;
> +				vsync-len = <1>;
> +			};
> +		};
> +
> +		port {
> +			dsi_in: endpoint {
> +				remote-endpoint = <&dsi_out>;
> +			};
> +		};
> +	};

^ permalink raw reply

* Re: [PATCH v3 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
From: Rob Herring @ 2016-12-19 18:45 UTC (permalink / raw)
  To: Caesar Wang; +Cc: devicetree, linux-kernel, dri-devel, dianders
In-Reply-To: <1481685596-15608-1-git-send-email-wxt@rock-chips.com>

On Wed, Dec 14, 2016 at 11:19:55AM +0800, Caesar Wang wrote:
> The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.
> 
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt          | 7 +++++++
>  1 file changed, 7 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt

Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH v2] mmc: sdhci-cadence: add Socionext UniPhier specific compatible string
From: Rob Herring @ 2016-12-19 18:44 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: linux-mmc, Adrian Hunter, Ulf Hansson, devicetree, linux-kernel,
	Mark Rutland
In-Reply-To: <1481681446-29832-1-git-send-email-yamada.masahiro@socionext.com>

On Wed, Dec 14, 2016 at 11:10:46AM +0900, Masahiro Yamada wrote:
> Add a Socionext SoC specific compatible (suggested by Rob Herring).
> 
> No SoC specific data are associated with the compatible strings for
> now, but other SoC vendors may use this IP and want to differentiate
> IP variants in the future.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
> 
> Changes in v2:
>   - Add "uniphier" to the compatible to make it more SoC-specific
> 
>  Documentation/devicetree/bindings/mmc/sdhci-cadence.txt | 6 ++++--
>  drivers/mmc/host/sdhci-cadence.c                        | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)

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

^ permalink raw reply

* Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level
From: Rob Herring @ 2016-12-19 18:38 UTC (permalink / raw)
  To: Subhash Jadavani
  Cc: Vinayak Holikatti, jejb, Martin K. 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: <b326fb4217bb894295e83fe252aa7bf1@codeaurora.org>

On Tue, Dec 13, 2016 at 2:16 PM, Subhash Jadavani
<subhashj@codeaurora.org> wrote:
> 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@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.
>
>
> 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.

What latencies can be tolerated is going to depend on the application
and could vary while running, so putting in DT doesn't make sense. I
would break down settings like this:

broken h/w -> DT
user tuning/config -> sysfs
sensible defaults -> driver

> 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.

The driver can tie the states to together if needed. Just document
what's broken in DT and let the driver make decisions.

Rob

^ permalink raw reply

* [PATCH] gpio: of: Add support for multiple GPIOs in a single GPIO hog
From: Geert Uytterhoeven @ 2016-12-19 18:21 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland
  Cc: linux-gpio, devicetree, Geert Uytterhoeven

When listing multiple GPIOs in the "gpios" property of a GPIO hog, only
the first GPIO is affected.  The user is left clueless about the
disfunctioning of the other GPIOs specified.

Fix this by adding and documenting support for specifying multiple
GPIOs in a single GPIO hog.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 Documentation/devicetree/bindings/gpio/gpio.txt |  8 +++----
 drivers/gpio/gpiolib-of.c                       | 31 ++++++++++++++++---------
 2 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 68d28f62a6f48eca..84ede036f73d09f8 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -187,10 +187,10 @@ gpio-controller's driver probe function.
 
 Each GPIO hog definition is represented as a child node of the GPIO controller.
 Required properties:
-- gpio-hog:   A property specifying that this child node represent a GPIO hog.
-- gpios:      Store the GPIO information (id, flags, ...). Shall contain the
-	      number of cells specified in its parent node (GPIO controller
-	      node).
+- gpio-hog:   A property specifying that this child node represents a GPIO hog.
+- gpios:      Store the GPIO information (id, flags, ...) for each GPIO to
+	      affect. Shall contain an integer multiple of the number of cells
+	      specified in its parent node (GPIO controller node).
 Only one of the following properties scanned in the order shown below.
 This means that when multiple properties are present they will be searched
 in the order presented below and the first match is taken as the intended
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 92b185f19232f7fc..975b9f6cf4082dfc 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -160,6 +160,7 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
  * of_parse_own_gpio() - Get a GPIO hog descriptor, names and flags for GPIO API
  * @np:		device node to get GPIO from
  * @chip:	GPIO chip whose hog is parsed
+ * @idx:	Index of the GPIO to parse
  * @name:	GPIO line name
  * @lflags:	gpio_lookup_flags - returned from of_find_gpio() or
  *		of_parse_own_gpio()
@@ -170,7 +171,7 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
  */
 static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
 					   struct gpio_chip *chip,
-					   const char **name,
+					   unsigned int idx, const char **name,
 					   enum gpio_lookup_flags *lflags,
 					   enum gpiod_flags *dflags)
 {
@@ -178,6 +179,7 @@ static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
 	enum of_gpio_flags xlate_flags;
 	struct of_phandle_args gpiospec;
 	struct gpio_desc *desc;
+	unsigned int i;
 	u32 tmp;
 	int ret;
 
@@ -196,9 +198,12 @@ static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
 	gpiospec.np = chip_np;
 	gpiospec.args_count = tmp;
 
-	ret = of_property_read_u32_array(np, "gpios", gpiospec.args, tmp);
-	if (ret)
-		return ERR_PTR(ret);
+	for (i = 0; i < tmp; i++) {
+		ret = of_property_read_u32_index(np, "gpios", idx * tmp + i,
+						 &gpiospec.args[i]);
+		if (ret)
+			return ERR_PTR(ret);
+	}
 
 	desc = of_xlate_and_get_gpiod_flags(chip, &gpiospec, &xlate_flags);
 	if (IS_ERR(desc))
@@ -240,20 +245,24 @@ static int of_gpiochip_scan_gpios(struct gpio_chip *chip)
 	const char *name;
 	enum gpio_lookup_flags lflags;
 	enum gpiod_flags dflags;
+	unsigned int i;
 	int ret;
 
 	for_each_available_child_of_node(chip->of_node, np) {
 		if (!of_property_read_bool(np, "gpio-hog"))
 			continue;
 
-		desc = of_parse_own_gpio(np, chip, &name, &lflags, &dflags);
-		if (IS_ERR(desc))
-			continue;
+		for (i = 0;; i++) {
+			desc = of_parse_own_gpio(np, chip, i, &name, &lflags,
+						 &dflags);
+			if (IS_ERR(desc))
+				break;
 
-		ret = gpiod_hog(desc, name, lflags, dflags);
-		if (ret < 0) {
-			of_node_put(np);
-			return ret;
+			ret = gpiod_hog(desc, name, lflags, dflags);
+			if (ret < 0) {
+				of_node_put(np);
+				return ret;
+			}
 		}
 	}
 
-- 
1.9.1


^ permalink raw reply related

* Re: [PATCH v3 2/2] ASoC: cs43130: Add devicetree bindings for CS43130
From: Rob Herring @ 2016-12-19 18:13 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: <12f0babd-017e-4aef-b04c-07e783a84c64-k7YZYYsDncjfk+Ne4bZl5AC/G2K4zDHf@public.gmane.org>

On Tue, Dec 13, 2016 at 11:47:07AM -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 v2 2/2] ASoC: cs35l35: Add device tree documentation for CS35L35
From: Rob Herring @ 2016-12-19 18:10 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: <7900b605-6715-4c95-ac44-381b0f7bc95d-XU/xxMRwCJnfk+Ne4bZl5AC/G2K4zDHf@public.gmane.org>

On Tue, Dec 13, 2016 at 10:26:44AM -0600, Li Xu wrote:
> Add device tree documentation for Cirrus Logic CS35L35
> speaker amplifier
> 
> Signed-off-by: Li Xu <li.xu-jGc1dHjMKG3QT0dZR+AlfA@public.gmane.org>
> ---
>  .../devicetree/bindings/sound/cs35l35.txt          | 172 +++++++++++++++++++++
>  1 file changed, 172 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/cs35l35.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/cs35l35.txt b/Documentation/devicetree/bindings/sound/cs35l35.txt
> new file mode 100644
> index 0000000..8b13f67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/cs35l35.txt
> @@ -0,0 +1,172 @@
> +CS35L35 Speaker Amplifier
> +
> +Required properties:
> +
> +  - compatible : "cirrus,cs35l35"
> +
> +  - reg : the I2C address of the device for I2C
> +
> +  - VA-supply, VP-supply : power supplies for the device,
> +    as covered in
> +    Documentation/devicetree/bindings/regulator/regulator.txt.
> +
> +  - interrupt-parent : Specifies the phandle of the interrupt controller to
> +    which the IRQs from CS35L35 are delivered to.
> +  - interrupts : IRQ line info CS35L35.
> +    (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +    for further information relating to interrupt properties)
> +
> +Optional properties:
> +  - cirrus,reset-gpios : Active low GPIO used to reset the amplifier

You can drop cirrus here. reset-gpios is pretty standard.

> +
> +  - cirrus,stereo-config : Boolean to determine if there are 2 AMPs for a
> +  Stereo configuration

The example shows this as a node. I prefer a property.

> +  - cirrus,audio-channel : Set Location of Audio Signal on Serial Port
> +  0 = Data Packet received on Left I2S Channel
> +  1 = Data Packet received on Right I2S Channel
> +
> +  - cirrus,advisory-channel : Set Location of Advisory Signal on Serial Port
> +  0 = Data Packet received on Left I2S Channel
> +  1 = Data Packet received on Right I2S Channel
> +
> +  - cirrus,shared-boost : Boolean to enable ClassH tracking of Advisory Signal
> +  if 2 Devices share Boost BST_CTL
> +
> +  - cirrus,sp-drv-strength : Value for setting the Serial Port drive strength
> +  Table 3-10 of the datasheet lists drive-strength specifications
> +  0 = 1x (Default)
> +  1 = .5x
> +
> +  - cirrus,bst-pdn-fet-on : Boolean to determine if the Boost PDN control
> +  powers down with a rectification FET On or Off. If VSPK is supplied
> +  externally then FET is off.
> +
> +  - cirrus,boost-ctl-millivolt : Boost Converter control word. Step Size of 100mV
> +  0x00 = (Default) VP
> +  0x01 = 2600mV
> +  0x41 = 9000mV
> +
> +  - cirrus,boost-ipk-milliamp : Boost-converter peak current limit.
> +  Configures the peak current by monitoring the current through the boost FET.
> +  Step size: 112mA
> +  0x00 = 1680mA
> +  0x19 = 4480mA

Either make the values be actual mV or mA (actually, uV and uA are the 
standard, see property-units.txt) or drop the unit suffix.

> +
> +  - cirrus,amp-gain-zc : Boolean to determine if to use Amplifier gain-change
> +  zero-cross
> +
> +Optional H/G Algorithm sub-node:
> +
> +  The cs35l35 node can have a single "cirrus,classh-internal-algo" sub-node
> +  that will disable automatic control of the internal H/G Algorithm.
> +
> +  It is strongly recommended that the Datasheet be referenced when adjusting
> +  or using these Class H Algorithm controls over the internal Algorithm.
> +  Serious damage can occur to the Device and surrounding components.
> +
> +  - cirrus,classh-internal-algo : Sub-node for the Internal Class H Algorithm
> +  See Section 4.3 Internal Class H Algorithm in the Datasheet.
> +  If not used, the device manages the ClassH Algorithm internally.
> +
> +Optional properties for the "cirrus,classh-internal-algo" Sub-node
> +
> +  Section 7.29 Class H Control
> +  - cirrus,classh-bst-overide : Boolean
> +  - cirrus,classh-bst-max-limit
> +  - cirrus,classh-mem-depth
> +
> +  Section 7.30 Class H Headroom Control
> +  - cirrus,classh-headroom
> +
> +  Section 7.31 Class H Release Rate
> +  - cirrus,classh-release-rate
> +
> +  Section 7.32 Class H Weak FET Drive Control
> +  - cirrus,classh-wk-fet-disable
> +  - cirrus,classh-wk-fet-delay
> +  - cirrus,classh-wk-fet-thld
> +
> +  Section 7.34 Class H VP Control
> +  - cirrus,classh-vpch-auto
> +  - cirrus,classh-vpch-rate
> +  - cirrus,classh-vpch-man
> +
> +Optional Monitor Signal Format sub-node:
> +
> +  The cs35l35 node can have a single "cirrus,monitor-signal-format" sub-node
> +  for adjusting the Depth, Location and Frame of the Monitoring Signals
> +  for Algorithms.
> +
> +  See Sections 4.8.2 through 4.8.4 Serial-Port Control in the Datasheet
> +
> +  -cirrus,monitor-signal-format : Sub-node for the Monitor Signaling Formating
> +  on the I2S Port. Each of the 3 8 bit values in the array contain the settings
> +  for depth, location, and frame.
> +
> +  If not used, the defaults for the 6 monitor signals is used.
> +
> +  Sections 7.44 - 7.53 lists values for the depth, location, and frame
> +  for each monitoring signal.
> +
> +  - cirrus,imon : 3 8 bit values to set the depth, location, and frame
> +  of the IMON monitor signal.
> +
> +  - cirrus,vmon : 3 8 bit values to set the depth, location, and frame
> +  of the VMON monitor signal.
> +
> +  - cirrus,vpmon : 3 8 bit values to set the depth, location, and frame
> +  of the VPMON monitor signal.
> +
> +  - cirrus,vbstmon : 3 8 bit values to set the depth, location, and frame
> +  of the VBSTMON monitor signal
> +
> +  - cirrus,vpbrstat : 3 8 bit values to set the depth, location, and frame
> +  of the VPBRSTAT monitor signal
> +
> +  - cirrus,zerofill : 3 8 bit values to set the depth, location, and frame\

stray \

> +  of the ZEROFILL packet in the monitor signal
> +
> +Example:
> +
> +cs35l35: audio-codec@20 {
> +	compatible = "cirrus,cs35l35";
> +	reg = <0x20>;
> +	VA-supply = <&dummy_vreg>;
> +	VP-supply = <&dummy_vreg>;
> +	reset-gpios = <&axi_gpio 54 1>;
> +	interrupt-parent = <&gpio8>;
> +	interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +	cirrus,boost-ctl = <0x41>;
> +
> +	cirrus,stereo-config {
> +		cirrus,audio-channel = <0x00>;
> +		cirrus,advisory-channel = <0x01>;
> +		cirrus,shared-boost;
> +	};
> +
> +	cirrus,classh-internal-algo {
> +		cirrus,classh-bst-overide;
> +		cirrus,classh-bst-max-limit = <0x01>;
> +		cirrus,classh-mem-depth = <0x01>;
> +		cirrus,classh-release-rate = <0x08>;
> +		cirrus,classh-headroom-millivolt = <0x0B>;
> +		cirrus,classh-wk-fet-disable = <0x01>;
> +		cirrus,classh-wk-fet-delay = <0x04>;
> +		cirrus,classh-wk-fet-thld = <0x01>;
> +		cirrus,classh-vpch-auto = <0x01>;
> +		cirrus,classh-vpch-rate = <0x02>;
> +		cirrus,classh-vpch-man = <0x05>;
> +	};
> +
> +	/* Depth, Location, Frame */
> +	cirrus,monitor-signal-format {
> +		cirrus,imon = /bits/ 8 <0x03 0x00 0x01>;
> +		cirrus,vmon = /bits/ 8 <0x03 0x00 0x00>;
> +		cirrus,vpmon = /bits/ 8 <0x03 0x04 0x00>;
> +		cirrus,vbstmon = /bits/ 8 <0x03 0x04 0x01>;
> +		cirrus,vpbrstat = /bits/ 8 <0x00 0x04 0x00>;
> +		cirrus,zerofill = /bits/ 8 <0x00 0x00 0x00>;
> +	};
> +
> +};
> -- 
> 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

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

On Tue, Dec 13, 2016 at 02:32:36PM +0000, 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
> +
> +The common video interfaces bindings (see video-interfaces.txt) should be
> +used to specify link to the image data receiver. The OV5647 device
> +node should contain one 'port' child node with an 'endpoint' subnode.

Would be good to add optional regulator supply properties, but that can 
come later.

> +
> +Example:
> +
> +	i2c@0x02000 {

No '0x' or leading 0s on unit addresses.

> +		...
> +		ov: camera@0x36 {

ditto.

> +			compatible = "ovti,ov5647";
> +			reg = <0x36>;
> +			clocks = <&camera_clk>;
> +			clock-names = "xclk";
> +			clock-frequency = <30000000>;
> +			port {
> +				camera_1: endpoint {
> +					remote-endpoint = <&csi1_ep1>;
> +				};
> +			};
> +		};
> +	};
> -- 
> 2.10.2
> 
> 

^ permalink raw reply

* Re: [PATCH v2 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host
From: Rob Herring @ 2016-12-19 17:38 UTC (permalink / raw)
  To: Ramiro Oliveira
  Cc: mark.rutland, mchehab, devicetree, linux-kernel, linux-media,
	davem, gregkh, geert+renesas, akpm, linux, hverkuil,
	laurent.pinchart+renesas, arnd, sudipm.mukherjee, tiffany.lin,
	minghsiu.tsai, jean-christophe.trotin, andrew-ct.chen,
	simon.horman, songjun.wu, bparrot, CARLOS.PALMINHA
In-Reply-To: <48a46d2d60fff723e322fdbfb29d533c2d0f5637.1481554324.git.roliveir@synopsys.com>

On Mon, Dec 12, 2016 at 03:00:35PM +0000, Ramiro Oliveira wrote:
> Create device tree bindings documentation for Media and Video Device, as well
> as the DW MIPI CSI-2 Host.
> 
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---
>  .../devicetree/bindings/media/snps,dw-mipi-csi.txt |  37 ++++++++
>  .../devicetree/bindings/media/snps,plat-ipk.txt    | 105 +++++++++++++++++++++
>  2 files changed, 142 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
>  create mode 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> new file mode 100644
> index 0000000..1caa652
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> @@ -0,0 +1,37 @@
> +Synopsys DesignWare CSI-2 Host controller
> +
> +Description
> +-----------
> +
> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> +camera.
> +
> +Required properties:
> +- compatible: shall be "snps,dw-mipi-csi"

You don't have to add them, but this will need SoC specific compatible 
strings. Please add a note to that effect.

> +- reg		: physical base address and size of the device memory mapped
> +  registers;
> +- interrupts	: CSI-2 Host interrupt
> +- data-lanes    : Number of lanes to be used
> +- output-type   : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2) These
> +  values choose which of the Core outputs will be used, it can be Image Data
> +  Interface or Image Pixel Interface.

This is output to a parallel camera interface (e.g. an SoC camera 
subsystem)? 

> +- phys, phy-names: List of one PHY specifier and identifier string (as defined
> +  in Documentation/devicetree/bindings/phy/phy-bindings.txt). This PHY is a MIPI
> +  DPHY working in RX mode.

phy-names is pointless when there is only 1.

> +
> +Optional properties(if in IPI mode):
> +- ipi-mode 	: Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
> +  This property defines if the controller will use the video timings available
> +  in the video stream or if it will use pre-defined ones.

"pre-defined" doesn't sound like the same thing as "automatic"?

> +- ipi-color-mode: Bus depth to be used in IPI (48 bits -> 0 or 16 bits -> 1)
> +  This property defines the width of the IPI bus.
> +- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No). This property defines
> +  if the data is automatically flushed in each vsync or if this process is done
> +  manually
> +- virtual-channel: Virtual channel where data is present when in IPI mode. This
> +  property chooses the virtual channel which IPI will use to retrieve the video
> +  stream.

All these properties seem like they should be common properties or are 
these interfaces something Synopsys specific? Or perhaps the interface 
is Synopsys specific, but determined by the CSI2 mode?

I think you need to define graph ports for the IPI and IDI interfaces 
and the connections. Then perhaps these properties become endpoint 
properties.

> +
> +The per-board settings:
> + - port sub-node describing a single endpoint connected to the dw-mipi-csi

Wouldn't the port connect to the camera?

> +   as described in video-interfaces.txt[1].
> diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> new file mode 100644
> index 0000000..50e9279
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> @@ -0,0 +1,105 @@
> +Synopsys DesignWare CSI-2 Host IPK Media Device
> +
> +The Synopsys DesignWare CSI-2 Host IPK subsystem comprises of multiple
> +sub-devices represented by separate device tree nodes. Currently this includes:
> +plat-ipk, video-device, and dw-mipi-csi.
> +
> +The sub-subdevices are defined as child nodes of the common 'camera' node which
> +also includes common properties of the whole subsystem not really specific to
> +any single sub-device.

But you don't have any properties defined for the camera node.

> +
> +Common 'camera' node
> +--------------------
> +
> +Required properties:
> +
> +- compatible: must be "snps,plat-ipk", "simple-bus"
> +
> +The 'camera' node must include at least one 'video-device' and one 'dw-mipi-csi'
> +child node.
> +
> +'video-device' device nodes
> +-------------------

Is this a separate block? DMA with no registers is strange. I'm having a 
hard time understanding a complete block diagram.

> +
> +Required properties:
> +
> +- compatible: "snps,video-device"

Kind of generic. The IP block is called just "video device"?

> +- dmas, dma-names: List of one DMA specifier and identifier string (as defined
> +  in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
> +  requires a DMA channel with the identifier string set to "port" followed by
> +  the port index.

port is not what you used in the example.

> +
> +Image sensor nodes
> +------------------
> +
> +The sensor device nodes should be added to their control bus controller (e.g.
> +I2C0) nodes and linked to a port node in the dw-mipi-csi,using the common video
> +interfaces bindings, defined in video-interfaces.txt.
> +
> +Example:
> +
> +	i2c@0x02000 {
> +			compatible = "snps,designware-i2c";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x02000 0x100>;
> +			clock-frequency = <400000>;
> +			clocks = <&i2cclk>;
> +			interrupts =<0>;
> +			ov: camera@0x36 {

Drop the '0x' on unit addresses.

> +				compatible = "ovti,ov5647";
> +				reg = <0x36>;
> +				port {
> +					camera_1: endpoint {
> +						remote-endpoint = <&csi1_ep1>;
> +						clock-lanes = <0>;
> +						data-lanes = <1 2 >;
> +					};
> +				};
> +			};
> +		};
> +
> +
> +	camera {
> +		compatible = "snps,plat-ipk", "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +			video_device: video-device@0x10000 {
> +				compatible = "snps,video-device";
> +				dmas = <&axi_vdma_0 0>;
> +				dma-names = "vdma0";
> +			};
> +
> +
> +			csi2_1: csi2@0x03000 {
> +				compatible = "snps,dw-mipi-csi";
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = < 0x03000 0x7FF>;
> +				interrupts = <2>;
> +				data-lanes = <2>;
> +				output-type = <2>;
> +
> +				phys = <&mipi_phy_ctrl1 0>;
> +				phy-names = "csi2-dphy";
> +
> +				/*IPI Related Configurations*/
> +				ipi-mode = <0>;
> +				ipi-color-mode = <0>;
> +				ipi-auto-flush = <1>;
> +				virtual-channel = <0>;
> +
> +				/* Camera MIPI CSI-2 (CSI1) */
> +				port@1 {
> +					reg = <1>;
> +					csi1_ep1: endpoint {
> +						remote-endpoint = <&camera_1>;
> +						data-lanes = <1 2>;
> +						};
> +				};
> +			};
> +		};
> +	};
> +
> +The dw-mipi-csi device binding is defined in snps,dw-mipi-csi.txt.
> -- 
> 2.10.2
> 
> 

^ permalink raw reply

* Re: [PATCH v2] power: reset: add linkstation-reset driver
From: Roger Shimizu @ 2016-12-19 17:37 UTC (permalink / raw)
  To: Sebastian Reichel, Rob Herring
  Cc: linux-pm, Andrew Lunn, Ryan Tandy, Martin Michlmayr,
	Sylver Bruneau, Herbert Valerio Riedel, Mark Rutland, devicetree
In-Reply-To: <20161219153802.vhcish35qyjbpevj@earth>

Dear Sebastian,

Thanks for your review!

On Tue, Dec 20, 2016 at 12:38 AM, Sebastian Reichel <sre@kernel.org> wrote:
>>
>>  .../bindings/power/reset/linkstation-reset.txt     |  26 ++++
>>  drivers/power/reset/Kconfig                        |  10 ++
>>  drivers/power/reset/Makefile                       |   1 +
>>  drivers/power/reset/linkstation-common.c           | 124 +++++++++++++++
>>  drivers/power/reset/linkstation-common.h           |   8 +
>>  drivers/power/reset/linkstation-reset.c            | 172 +++++++++++++++++++++
>>  6 files changed, 341 insertions(+)
>
> With this being its own driver please merge linkstation-common and
> linkstation-reset. The common part is only used by linkstation-reset
> anyways.

I'll add them into To/Cc list.

>> +/* 4-byte magic hello command to UART1-attached microcontroller */
>> +static const unsigned char linkstation_micon_magic[] = {
>> +     0x1b,
>> +     0x00,
>> +     0x07,
>> +     0x00
>> +};
>
> 4-byte magic hello command? Those are used as uart configuration as
> far as I can see. Just move this directly into reset_cfg:
>
> struct reset_cfg {
>     u32 baud;
>     u8 lcr;
>     u8 ier;
>     u8 fcr;
>     u8 mcr;
>     const unsigned char (*cmd)[MICON_CMD_SIZE];
> };
>

>> +static void linkstation_reset(void)
>> +{
>> +     const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
>> +
>> +     pr_err("%s: triggering power-off...\n", __func__);
>> +
>> +     /* hijack UART1 and reset into sane state */
>> +     writel(0x83, UART1_REG(LCR));
>> +     writel(divisor & 0xff, UART1_REG(DLL));
>> +     writel((divisor >> 8) & 0xff, UART1_REG(DLM));
>> +     writel(cfg->magic[0], UART1_REG(LCR));
>> +     writel(cfg->magic[1], UART1_REG(IER));
>> +     writel(cfg->magic[2], UART1_REG(FCR));
>> +     writel(cfg->magic[3], UART1_REG(MCR));
>> +
>> +     /* send the power-off command to PIC */
>> +     if(cfg->cmd[0][0] == 1 && cfg->cmd[1][0] == 0) {
>> +             /* if it's simply one-byte command, send it directly */
>> +             writel(cfg->cmd[0][1], UART1_REG(TX));
>> +     }
>
> I guess this optimization can be dropped and you can directly
> call the for loop with uart1_micon_send().

Same response regarding above two comments.
The code is extensible because I want to extend in the future.

Current implementation is just for Linkstation Pro / KuroBox Pro to be
able to power-off.
But for some other model of Linkstation, restart also need similar
command via UART1.

Just one example, Linkstation Pro is ARM based, but it was PowerPC based before.
And the device support still exists in kernel tree:
  arch/powerpc/platforms/embedded6xx/linkstation.c
  arch/powerpc/platforms/embedded6xx/ls_uart.c
It shows sending "C" to restart and sending "E" to power-off for
PowerPC based Linkstation.

I'm not actually interested in PowerPC based Linkstation, it's just an
example to show the reason to be flexible.

If other part is fine, may I send the v3 patch after merging
linkstation-common.c into linkstation-reset.c?
Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

^ permalink raw reply

* Re: [PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
From: Laurent Pinchart @ 2016-12-19 16:54 UTC (permalink / raw)
  To: Rob Herring
  Cc: dri-devel, open list:MEDIA DRIVERS FOR RENESAS - FCP,
	devicetree@vger.kernel.org, Tomi Valkeinen, Laurent Pinchart
In-Reply-To: <CAL_JsqKBoAJFiOqNhMPzF5VXjdXT2jbWHV0zxfX0gdSz0yGZLQ@mail.gmail.com>

Hi Rob,

On Monday 19 Dec 2016 09:38:49 Rob Herring wrote:
> On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote:
> >> On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote:
> >>> On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote:
> >>>> On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
> >>>>> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
> >>>>>> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
> >>>>>>> Document properties common to several display panels in a central
> >>>>>>> location that can be referenced by the panel device tree bindings.
> >>>>>> 
> >>>>>> Looks good. Just one comment...
> >>>>>> 
> >>>>>> [...]
> >>>>>> 
> >>>>>>> +Connectivity
> >>>>>>> +------------
> >>>>>>> +
> >>>>>>> +- ports: Panels receive video data through one or multiple
> >>>>>>> connections. While
> >>>>>>> +  the nature of those connections is specific to the panel type,
> >>>>>>> the
> >>>>>>> +  connectivity is expressed in a standard fashion using ports as
> >>>>>>> specified in
> >>>>>>> +  the device graph bindings defined in
> >>>>>>> +  Documentation/devicetree/bindings/graph.txt.
> >>>>>> 
> >>>>>> We allow panels to either use graph binding or be a child of the
> >>>>>> display controller.
> >>>>> 
> >>>>> I knew that some display controllers use a phandle to the panel (see
> >>>>> the fsl,panel and nvidia,panel properties), but I didn't know we had
> >>>>> panels as children of display controller nodes. I don't think we
> >>>>> should allow that for anything but DSI panels, as the DT hierarchy is
> >>>>> based on control buses. Are you sure we have other panels instantiated
> >>>>> through that mechanism ?
> >>> 
> >>> Some panels have no control bus, so were do we place them?
> >> 
> >> I'd say under the root node, like all similar control-less devices.
> >> 
> >>> I would say the hierarchy is based on buses with a preference for the
> >>> control bus when there are multiple buses. I'm not a fan of just
> >>> sticking things are the top level.
> >> 
> >> OK, so much for my comment a few lines up :-)
> >> 
> >> The problem with placing non-DSI panels as children of the display
> >> controller and not using OF graph is that the panel bindings become
> >> dependent of the display controller being used. A display controller
> >> using OF graph would require the panel to do the same, while a display
> >> controller expecting a panel child node (with a specific name) would
> >> require DT properties for the panel node.
> 
> Not sure I follow.

Sorry, I meant "would not requite DT properties".

> They become dependent on the controller driver to probe the panel, but the
> contents of the panel node would not be controller dependent.

If a display controller uses OF graph then the panel DT node has to declare 
ports. If the display controller doesn't use OF graph but instead expects the 
panel to be a direct subnode, or points to the panel using a property such as 
fsl,panel, then the panel DT node will not have ports.

> >> I'm also not sure the complexity of OF graph is really that prohibitive
> >> if you compare it to panels as child nodes. To get the panel driver to
> >> bind to the panel DT node the display controller driver would need to
> >> create a platform device for the panel and register it. That's not very
> >> difficult, but parsing a single port and endpoint isn't either (and we
> >> could even provide a helper function for that, a version of
> >> of_drm_find_panel() that would take as an argument the display controller
> >> device node instead of the panel device node).
> > 
> > Ping ?
> > 
> > I'd like to standardize on one model for panel DT bindings, but I'm not
> > sure that can be achieved given that we already have multiple competing
> > models. In any case, is that blocking to merge this patch ? I only
> > describe one connectivity model here as that's what my panel driver
> > needs, but I have no issue adding more models later when needed. I
> > believe this patch is a good step forward already.
> 
> It is an improvement which I appreciate, so yes I guess we can address
> it later when needed.

Thank you. Can I get your ack then ? :-)

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* Re: [PATCH v2 03/10] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Rob Herring @ 2016-12-19 16:37 UTC (permalink / raw)
  To: Anurup M
  Cc: mark.rutland, will.deacon, linux-kernel, devicetree,
	linux-arm-kernel, anurup.m, zhangshaokun, tanxiaojun, xuwei5,
	sanil.kumar, john.garry, gabriele.paoloni, shiju.jose,
	wangkefeng.wang, linuxarm, shyju.pv
In-Reply-To: <1481129759-159533-1-git-send-email-anurup.m@huawei.com>

On Wed, Dec 07, 2016 at 11:55:59AM -0500, Anurup M wrote:
> 1) Device tree bindings for Hisilicon SoC PMU.
> 2) Add example for Hisilicon L3 cache and MN PMU.
> 3) Add child nodes of L3C and MN in djtag bindings example.
> 
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
> ---
>  .../devicetree/bindings/arm/hisilicon/djtag.txt    | 25 ++++++
>  .../devicetree/bindings/arm/hisilicon/pmu.txt      | 98 ++++++++++++++++++++++
>  2 files changed, 123 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> index 733498e..c885507 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -27,6 +27,31 @@ Example 1: Djtag for CPU die
>  		scl-id = <0x02>;
>  
>  		/* All connecting components will appear as child nodes */
> +
> +		pmul3c0 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x02>;
> +		};
> +
> +		pmul3c1 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x04>;
> +		};
> +
> +		pmul3c2 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x01>;
> +		};
> +
> +		pmul3c3 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x08>;
> +		};
> +
> +		pmumn0 {
> +			compatible = "hisilicon,hisi-pmu-mn-v1";
> +			module-id = <0x0b>;
> +		};
>  	};
>  
>  Example 2: Djtag for IO die
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> new file mode 100644
> index 0000000..e2160ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> @@ -0,0 +1,98 @@
> +Hisilicon SoC HiP05/06/07 ARMv8 PMU
> +===================================
> +
> +The Hisilicon SoC chips like HiP05/06/07 etc. consist of various independent
> +system device PMUs such as L3 cache (L3C) and Miscellaneous Nodes(MN). These
> +PMU devices are independent and have hardware logic to gather statistics and
> +performance information.
> +
> +HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which includes
> +4 cpu-cores each.
> +e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
> +The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
> +
> +The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> +the parent node will be the djtag node of the corresponding CPU die (SCCL).
> +
> +L3 cache
> +---------
> +The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips have 4
> +L3 cache banks. Each L3 cache bank have separate DT nodes.
> +
> +Required properties:
> +
> +	- compatible : This value should be as follows
> +		(a) "hisilicon,hisi-pmu-l3c-v1" for v1 hw in HiP05/06 chips
> +		(b) "hisilicon,hisi-pmu-l3c-v2" for v2 hw in HiP07 chip

Use SoC specific compatible strings.

> +
> +	- module-id : This property is a combination of two values in the below order.
> +		      a) Module ID: The module identifier for djtag.
> +		      b) Instance or Bank ID: This will identify the L3 cache bank
> +			 or instance.

Needs a vendor prefix.

> +
> +Optional properties:
> +
> +	- interrupt-parent : A phandle indicating which interrupt controller
> +		this PMU signals interrupts to.
> +
> +	- interrupts : Interrupt lines used by this L3 cache bank.

How many interrupts and what are they?

> +
> +	*The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Miscellaneous Node
> +------------------
> +The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
> +for each SCCL.

Similar comments here.

> +
> +Required properties:
> +
> +	- compatible : This value should be as follows
> +		(a) "hisilicon,hisi-pmu-mn-v1" for v1 hw in HiP05/06 chips
> +		(b) "hisilicon,hisi-pmu-mn-v2" for v2 hw in HiP07 chip
> +
> +	- module-id : Module ID to input for djtag.
> +
> +Optional properties:
> +
> +	- interrupt-parent : A phandle indicating which interrupt controller
> +		this PMU signals interrupts to.
> +
> +	- interrupts : Interrupt lines used by this PMU.
> +
> +	*The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Example:
> +
> +	djtag0: djtag@80010000 {
> +		compatible = "hisilicon,hisi-djtag-v1";
> +		reg = <0x0 0x80010000 0x0 0x10000>;
> +		scl-id = <0x02>;
> +
> +		pmul3c0 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x02>;
> +		};
> +
> +		pmul3c1 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x04>;
> +		};
> +
> +		pmul3c2 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x01>;
> +		};
> +
> +		pmul3c3 {
> +			compatible = "hisilicon,hisi-pmu-l3c-v1";
> +			module-id = <0x04 0x08>;
> +		};
> +
> +		pmumn0 {
> +			compatible = "hisilicon,hisi-pmu-mn-v1";
> +			module-id = <0x0b>;
> +		};
> +	};
> -- 
> 2.1.4
> 

^ permalink raw reply

* Re: [PATCH v2 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Rob Herring @ 2016-12-19 16:31 UTC (permalink / raw)
  To: Anurup M
  Cc: mark.rutland, will.deacon, linux-kernel, devicetree,
	linux-arm-kernel, anurup.m, zhangshaokun, tanxiaojun, xuwei5,
	sanil.kumar, john.garry, gabriele.paoloni, shiju.jose,
	wangkefeng.wang, linuxarm, shyju.pv
In-Reply-To: <1481129719-159487-1-git-send-email-anurup.m@huawei.com>

On Wed, Dec 07, 2016 at 11:55:19AM -0500, Anurup M wrote:
> From: Tan Xiaojun <tanxiaojun@huawei.com>
> 
> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
> 
> Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> ---
>  .../devicetree/bindings/arm/hisilicon/djtag.txt    | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> new file mode 100644
> index 0000000..733498e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -0,0 +1,41 @@
> +The Hisilicon Djtag is an independent component which connects with some other
> +components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
> +in the chip. The djtag controls access to connecting modules of CPU and IO
> +dies.
> +The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
> +are accessed by djtag during real time debugging. In IO die there are connecting
> +components like RSA. These components appear as devices atatched to djtag bus.
> +
> +Hisilicon HiP05/06 djtag for CPU and HiP05 IO die
> +Required properties:
> +  - compatible : "hisilicon,hisi-djtag-v1"

These need SoC specific compatible strings. They probably should 
also include cpu or io in the compatible string. I would expect there 
are things like events, triggers, or component connections for debug 
that are SoC specifc.

> +  - reg : Register address and size
> +  - scl-id : The Super Cluster ID for CPU or IO die
> +
> +Hisilicon HiP06 djtag for IO die and HiP07 djtag for CPU and IO die
> +Required properties:
> +  - compatible : "hisilicon,hisi-djtag-v2"

Same here.

> +  - reg : Register address and size
> +  - scl-id : The Super Cluster ID for CPU or IO die
> +
> +Example 1: Djtag for CPU die
> +
> +	/* for Hisilicon HiP05 djtag for CPU Die */
> +	djtag0: djtag@80010000 {
> +		compatible = "hisilicon,hisi-djtag-v1";
> +		reg = <0x0 0x80010000 0x0 0x10000>;
> +		scl-id = <0x02>;
> +
> +		/* All connecting components will appear as child nodes */
> +	};
> +
> +Example 2: Djtag for IO die
> +
> +	/* for Hisilicon HiP05 djtag for IO Die */
> +	djtag1: djtag@d0000000 {
> +		compatible = "hisilicon,hisi-djtag-v1";
> +		reg = <0x0 0xd0000000 0x0 0x10000>;
> +		scl-id = <0x01>;
> +
> +		/* All connecting components will appear as child nodes */
> +	};
> -- 
> 2.1.4
> 

^ permalink raw reply

* Re: [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Lars-Peter Clausen @ 2016-12-19 16:28 UTC (permalink / raw)
  To: Andreas Klinger, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-iio-u79uwXL29TY76Z2rM5mHXA
  Cc: 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, pmeerw-jW+XmwGofnusTnJN9+BGXg
In-Reply-To: <20161214161740.GA13896@andreas>

On 12/14/2016 05:17 PM, Andreas Klinger wrote:
[...]
> +#include <linux/err.h>
> +#include <linux/gpio.h>

Since you used the consumer API linux/gpio.h is not needed.

> +#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>
> +#include <linux/iio/sysfs.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 */
> +
> +struct hx711_data {
> +	struct device		*dev;
> +	struct gpio_desc	*gpiod_sck;
> +	struct gpio_desc	*gpiod_dout;
> +	int			gain_pulse;
> +	struct mutex		lock;
> +};
> +
> +static int hx711_read(struct hx711_data *hx711_data)
> +{
> +	int i, ret;
> +	int value = 0;
> +
> +	mutex_lock(&hx711_data->lock);
> +
> +	if (hx711_reset(hx711_data)) {

If you reset the device before each conversion wont this clear the channel
and gain selection? Wouldn't the driver always read from channel A at 128
gain regardless of what has been selected?

> +		dev_err(hx711_data->dev, "reset failed!");
> +		mutex_unlock(&hx711_data->lock);
> +		return -1;

If there is an error it should be propagated to the higher layers. At the
moment you only return a bogus conversion value.

> +	}
> +
> +	for (i = 0; i < 24; i++) {
> +		value <<= 1;
> +		ret = hx711_cycle(hx711_data);
> +		if (ret)
> +			value++;
> +	}
> +
> +	value ^= 0x800000;
> +
> +	for (i = 0; i < hx711_data->gain_pulse; i++)
> +		ret = hx711_cycle(hx711_data);
> +
> +	mutex_unlock(&hx711_data->lock);
> +
> +	return value;
> +}
> +
> +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);
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		switch (chan->type) {
> +		case IIO_VOLTAGE:
> +			*val = hx711_read(hx711_data);
> +			return IIO_VAL_INT;
> +		default:
> +			return -EINVAL;
> +		}
> +	default:
> +		return -EINVAL;
> +	}
> +}
[...]
> +static struct attribute *hx711_attributes[] = {
> +	&iio_dev_attr_gain.dev_attr.attr,

For IIO devices the gain is typically expressed through the scale attribute.
Which is kind of the inverse of gain. It would be good if this driver
follows this standard notation. The scale is the value of 1LSB in mV. So
this includes the resolution of the ADC, the reference voltage and any gain
that is applied to the input signal.

The possible values can be listed in the scale_available attribute.

> +	NULL,
> +};
> +
> +static struct attribute_group hx711_attribute_group = {
> +	.attrs = hx711_attributes,
> +};
> +
> +static const struct iio_info hx711_iio_info = {
> +	.driver_module		= THIS_MODULE,
> +	.read_raw		= hx711_read_raw,
> +	.attrs			= &hx711_attribute_group,
> +};
> +
> +static const struct iio_chan_spec hx711_chan_spec[] = {
> +	{ .type = IIO_VOLTAGE,
> +		.info_mask_separate =
> +			BIT(IIO_CHAN_INFO_RAW),

Given that there are two separate physical input channels this should be
expressed here and there should be two IIO channels for the device.

> +	},
> +};
> +
> +static int hx711_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct hx711_data *hx711_data = NULL;

The = NULL is not needed as it is overwritten a few lines below.

> +	struct iio_dev *iio;
> +	int ret = 0;

Again = 0 no needed.

> +
> +	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)) {
> +		dev_err(dev, "failed to get sck-gpiod: err=%ld\n",
> +					PTR_ERR(hx711_data->gpiod_sck));
> +		return PTR_ERR(hx711_data->gpiod_sck);
> +	}
> +
> +	hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
> +	if (IS_ERR(hx711_data->gpiod_dout)) {
> +		dev_err(dev, "failed to get dout-gpiod: err=%ld\n",
> +					PTR_ERR(hx711_data->gpiod_dout));
> +		return PTR_ERR(hx711_data->gpiod_dout);
> +	}
> +
> +	ret = gpiod_direction_input(hx711_data->gpiod_dout);

If dout is used as a input GPIO you should request it with GPIOD_IN. In that
case you can remove the gpiod_direction_input() call.

> +	if (ret < 0) {
> +		dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);

Similar to above. If you want this to be a output GPIO with the default
value of 0 request it with GPIOD_OUT_LOW.

> +	if (ret < 0) {
> +		dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
> +		return ret;
> +	}
> +
> +	platform_set_drvdata(pdev, iio);

There is no matching platform_get_drvdata() so this can probably be removed.

> +
> +	iio->name = pdev->name;

This should be the part name. E.g. "hx711" in this case.

> +	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);
> +
> +	return devm_iio_device_register(dev, iio);
> +}

--
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] power: reset: add linkstation-reset driver
From: Roger Shimizu @ 2016-12-19 16:12 UTC (permalink / raw)
  To: Andrew Lunn, Sebastian Reichel
  Cc: Rob Herring, linux-pm, Ryan Tandy, Martin Michlmayr,
	Sylver Bruneau, Herbert Valerio Riedel, Mark Rutland, devicetree
In-Reply-To: <20161219160345.GB16612@lunn.ch>

Thanks for your review!

On Tue, Dec 20, 2016 at 1:03 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > +   reset {
>> > +           compatible = "linkstation,power-off";
>> > +           reg = <0x12100 0x100>;
>> > +           clocks = <&core_clk 0>;
>> > +   };
>>
>> This might be another user for UART slave device [0].
>> [0] https://lkml.org/lkml/2016/8/24/769
>>
>> Is the UART port used for anything else besides the reset
>> controller?
>
> I don't know much about these specific devices, but the qnap
> equivalent, there is a user space daemon which also talks to the
> microcontroller, for things like a temperature sensor, buzzer, etc.
>
> https://www.hellion.org.uk/qcontrol/
>
> So the UART can be in a messed up state, which is why the QNAP driver,
> which this code is modelled on, reset it back to a good state.

For Linkstation/KuroBox-Pro, it's quite similar, and the user-land program is
called micro-evtd [0], which is co-maintained by Ryan Tandy and me in Debian.

[0] https://tracker.debian.org/pkg/micro-evtd

>> [0] https://lkml.org/lkml/2016/8/24/769

Do I need to modify anything related to the above UART slave device?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

^ permalink raw reply

* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Rob Herring @ 2016-12-19 16:04 UTC (permalink / raw)
  To: Dongpo Li
  Cc: David Miller, Mark Rutland, Michael Turquette, Stephen Boyd,
	Russell King, Zhangfei Gao, Yisen Zhuang, salil.mehta,
	Arnd Bergmann, Andrew Lunn, Jiancheng Xue, benjamin.chenhao,
	caizhiyong, netdev, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <585796D6.1080407@hisilicon.com>

On Mon, Dec 19, 2016 at 2:14 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
> Hi Rob and David,
>
> On 2016/12/12 22:21, Rob Herring wrote:
>> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
>>> Hi Rob,
>>>
>>> On 2016/12/10 6:35, Rob Herring wrote:
>>>> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:

[...]

>>>>> @@ -20,7 +25,7 @@ Required properties:
>>>>>
>>>>>  Example:
>>>>>      gmac0: ethernet@f9840000 {
>>>>> -            compatible = "hisilicon,hix5hd2-gmac";
>>>>> +            compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
>>>>
>>>> You can't just change compatible strings.
>>>>
>>> Okay, maybe I should name all the compatible string with the suffix "-gmac" instead of
>>> "-gemac". This can keep the compatible strings with the same suffix. Is this okay?
>>> Can I just add the generic compatible string without changing the SoCs compatible string?
>>> Like following:
>>>         gmac0: ethernet@f9840000 {
>>>  -              compatible = "hisilicon,hix5hd2-gmac";
>>>  +              compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
>>
>> Yes, this is fine.
>
> As the patch series have been applied to net-next branch,
> in which way should I commit this compatible fix?
> Should I send a new patch fixing this compatible string error with "Fixes: xxx"?
> Looking forward to your reply!

Yes to both.

Rob

^ permalink raw reply

* Re: [PATCH v2] power: reset: add linkstation-reset driver
From: Andrew Lunn @ 2016-12-19 16:03 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Roger Shimizu, Rob Herring, linux-pm, Ryan Tandy,
	Martin Michlmayr, Sylver Bruneau, Herbert Valerio Riedel,
	Mark Rutland, devicetree
In-Reply-To: <20161219153802.vhcish35qyjbpevj@earth>

> > +	reset {
> > +		compatible = "linkstation,power-off";
> > +		reg = <0x12100 0x100>;
> > +		clocks = <&core_clk 0>;
> > +	};
> 
> This might be another user for UART slave device [0].
> [0] https://lkml.org/lkml/2016/8/24/769
> 
> Is the UART port used for anything else besides the reset
> controller?

I don't know much about these specific devices, but the qnap
equivalent, there is a user space daemon which also talks to the
microcontroller, for things like a temperature sensor, buzzer, etc.

https://www.hellion.org.uk/qcontrol/

So the UART can be in a messed up state, which is why the QNAP driver,
which this code is modelled on, reset it back to a good state.

      Andrew

^ permalink raw reply

* Re: [PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
From: Rob Herring @ 2016-12-19 15:38 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: dri-devel, open list:MEDIA DRIVERS FOR RENESAS - FCP,
	devicetree@vger.kernel.org, Tomi Valkeinen, Laurent Pinchart
In-Reply-To: <2900223.pppRAbRhe6@avalon>

On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Rob,
>
> On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote:
>> On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote:
>> > On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote:
>> >> On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
>> >>> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
>> >>>> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
>> >>>>> Document properties common to several display panels in a central
>> >>>>> location that can be referenced by the panel device tree bindings.
>> >>>>
>> >>>> Looks good. Just one comment...
>> >>>>
>> >>>> [...]
>> >>>>
>> >>>>> +Connectivity
>> >>>>> +------------
>> >>>>> +
>> >>>>> +- ports: Panels receive video data through one or multiple
>> >>>>> connections. While
>> >>>>> +  the nature of those connections is specific to the panel type, the
>> >>>>> +  connectivity is expressed in a standard fashion using ports as
>> >>>>> specified in
>> >>>>> +  the device graph bindings defined in
>> >>>>> +  Documentation/devicetree/bindings/graph.txt.
>> >>>>
>> >>>> We allow panels to either use graph binding or be a child of the
>> >>>> display controller.
>> >>>
>> >>> I knew that some display controllers use a phandle to the panel (see
>> >>> the fsl,panel and nvidia,panel properties), but I didn't know we had
>> >>> panels as children of display controller nodes. I don't think we should
>> >>> allow that for anything but DSI panels, as the DT hierarchy is based on
>> >>> control buses. Are you sure we have other panels instantiated through
>> >>> that mechanism ?
>> >
>> > Some panels have no control bus, so were do we place them?
>>
>> I'd say under the root node, like all similar control-less devices.
>>
>> > I would say the hierarchy is based on buses with a preference for the
>> > control bus when there are multiple buses. I'm not a fan of just sticking
>> > things are the top level.
>>
>> OK, so much for my comment a few lines up :-)
>>
>> The problem with placing non-DSI panels as children of the display
>> controller and not using OF graph is that the panel bindings become
>> dependent of the display controller being used. A display controller using
>> OF graph would require the panel to do the same, while a display controller
>> expecting a panel child node (with a specific name) would require DT
>> properties for the panel node.

Not sure I follow. They become dependent on the controller driver to
probe the panel, but the contents of the panel node would not be
controller dependent.

>> I'm also not sure the complexity of OF graph is really that prohibitive if
>> you compare it to panels as child nodes. To get the panel driver to bind to
>> the panel DT node the display controller driver would need to create a
>> platform device for the panel and register it. That's not very difficult,
>> but parsing a single port and endpoint isn't either (and we could even
>> provide a helper function for that, a version of of_drm_find_panel() that
>> would take as an argument the display controller device node instead of the
>> panel device node).
>
> Ping ?
>
> I'd like to standardize on one model for panel DT bindings, but I'm not sure
> that can be achieved given that we already have multiple competing models. In
> any case, is that blocking to merge this patch ? I only describe one
> connectivity model here as that's what my panel driver needs, but I have no
> issue adding more models later when needed. I believe this patch is a good
> step forward already.

It is an improvement which I appreciate, so yes I guess we can address
it later when needed.

Rob

^ permalink raw reply

* Re: [PATCH v2] power: reset: add linkstation-reset driver
From: Sebastian Reichel @ 2016-12-19 15:38 UTC (permalink / raw)
  To: Roger Shimizu, Rob Herring
  Cc: linux-pm, Andrew Lunn, Ryan Tandy, Martin Michlmayr,
	Sylver Bruneau, Herbert Valerio Riedel, Mark Rutland, devicetree
In-Reply-To: <20161216100501.18173-1-rogershimizu@gmail.com>

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

Hi Roger,

On Fri, Dec 16, 2016 at 07:05:01PM +0900, Roger Shimizu wrote:
> Buffalo Linkstation / KuroBox and their variants need magic command
> sending to UART1 to power-off.
> 
> Power driver linkstation-reset implements the magic command and I/O
> routine, which come from files listed below:
>   - arch/arm/mach-orion5x/kurobox_pro-setup.c
>   - arch/arm/mach-orion5x/terastation_pro2-setup.c

Ok.

> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Martin Michlmayr <tbm@cyrius.com>
> Cc: Sylver Bruneau <sylver.bruneau@googlemail.com>
> Cc: Herbert Valerio Riedel <hvr@gnu.org>
> Reported-by: Ryan Tandy <ryan@nardis.ca>
> Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
> ---
> Dear Sebastian,
> 
> Kurobox-Pro (and variants) need more commands sending to UART1 to shutdown.
> So here I make this patch series to let current qnap-poweroff implementation
> be able to handle such case.
> 
> I already tested this change on Kurobox-Pro and Linkstation LS-GL devices,
> with a modified device-tree file. (Previous device-tree of kurobox-pro invokes
> restart-poweroff, so it simply restarts.)
> 
> Thank you and look forward to your feedback!
>
> Dear Andrew,
> 
> Thanks for your 2nd review!
> 
> So I accept your suggestion and make the new driver for linkstation series.
>
> Changes:
>   v0 => v1:
>   - Update 0003 to split kuroboxpro related code into kuroboxpro-common.c
>   v1 => v2:
>   - Slipt off linkstation/kuroboxpro related code to linkstation-reset.c
>     Because linkstation before kuroboxpro also need this driver to power
>     off properly. It's more proper to call it linkstation driver.
> 
> Cheers,
> --
> Roger Shimizu, GMT +9 Tokyo
> PGP/GPG: 4096R/6C6ACD6417B3ACB1
> 
>  .../bindings/power/reset/linkstation-reset.txt     |  26 ++++
>  drivers/power/reset/Kconfig                        |  10 ++
>  drivers/power/reset/Makefile                       |   1 +
>  drivers/power/reset/linkstation-common.c           | 124 +++++++++++++++
>  drivers/power/reset/linkstation-common.h           |   8 +
>  drivers/power/reset/linkstation-reset.c            | 172 +++++++++++++++++++++
>  6 files changed, 341 insertions(+)

With this being its own driver please merge linkstation-common and
linkstation-reset. The common part is only used by linkstation-reset
anyways.

>  create mode 100644 Documentation/devicetree/bindings/power/reset/linkstation-reset.txt

This patch is missing Cc for DT binding people (check "OPEN FIRMWARE
AND FLATTENED DEVICE TREE BINDINGS" in MAINTAINERS file).

>  create mode 100644 drivers/power/reset/linkstation-common.c
>  create mode 100644 drivers/power/reset/linkstation-common.h
>  create mode 100644 drivers/power/reset/linkstation-reset.c
> 
> diff --git a/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt b/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt
> new file mode 100644
> index 0000000..815e340
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/linkstation-reset.txt
> @@ -0,0 +1,26 @@
> +* Buffalo Linkstation Reset Driver
> +
> +Power of some Buffalo Linkstation or KuroBox Pro is managed by
> +micro-controller, which connects to UART1. After being fed from UART1
> +by a few magic numbers, the so-called power-off command,
> +the micro-controller will turn power off the device.
> +
> +This is very similar to QNAP or Synology NAS devices, which is
> +described in qnap-poweroff.txt, however the command is much simpler,
> +only 1-byte long and without checksums.
> +
> +This driver adds a handler to pm_power_off which is called to turn the
> +power off.
> +
> +Required Properties:
> +- compatible: Should be "linkstation,power-off"
> +- reg: Address and length of the register set for UART1
> +- clocks: tclk clock
> +
> +Example:
> +
> +	reset {
> +		compatible = "linkstation,power-off";
> +		reg = <0x12100 0x100>;
> +		clocks = <&core_clk 0>;
> +	};

This might be another user for UART slave device [0].
[0] https://lkml.org/lkml/2016/8/24/769

Is the UART port used for anything else besides the reset
controller?

> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index c74c3f6..77c44ca 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -98,6 +98,16 @@ config POWER_RESET_IMX
>  	  say N here or disable in dts to make sure pm_power_off never be
>  	  overwrote wrongly by this driver.
>  
> +config POWER_RESET_LINKSTATION
> +	bool "Buffalo Linkstation and its variants reset driver"
> +	depends on OF_GPIO && PLAT_ORION
> +	help
> +	  This driver supports power off Buffalo Linkstation / KuroBox Pro
> +	  NAS and their variants by sending commands to the micro-controller
> +	  which controls the main power.
> +
> +	  Say Y if you have a Buffalo Linkstation / KuroBox Pro NAS.
> +
>  config POWER_RESET_MSM
>  	bool "Qualcomm MSM power-off driver"
>  	depends on ARCH_QCOM
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 1be307c..520afbe 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
>  obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
>  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
>  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> +obj-$(CONFIG_POWER_RESET_LINKSTATION) += linkstation-reset.o linkstation-common.o
>  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
>  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
> diff --git a/drivers/power/reset/linkstation-common.c b/drivers/power/reset/linkstation-common.c
> new file mode 100644
> index 0000000..a6d0930
> --- /dev/null
> +++ b/drivers/power/reset/linkstation-common.c
> @@ -0,0 +1,124 @@
> +/*
> + * Common I/O routine for micro-controller of Buffalo Linkstation
> + * and its variants.
> + *
> + * Copyright (C) 2016 Roger Shimizu <rogershimizu@gmail.com>
> + *
> + * Based on the code from:
> + *
> + * Copyright (C) 2008  Sylver Bruneau <sylver.bruneau@googlemail.com>
> + * Copyright (C) 2007  Herbert Valerio Riedel <hvr@gnu.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.
> + */
> +
> +#include <linux/serial_reg.h>
> +#include <linux/io.h>
> +#include <linux/delay.h>
> +#include "linkstation-common.h"
> +
> +static int uart1_micon_read(void *base, unsigned char *buf, int count)
> +{
> +	int i;
> +	int timeout;
> +
> +	for (i = 0; i < count; i++) {
> +		timeout = 10;
> +
> +		while (!(readl(UART1_REG(LSR)) & UART_LSR_DR)) {
> +			if (--timeout == 0)
> +				break;
> +			udelay(1000);
> +		}
> +
> +		if (timeout == 0)
> +			break;
> +		buf[i] = readl(UART1_REG(RX));
> +	}
> +
> +	/* return read bytes */
> +	return i;
> +}
> +
> +static int uart1_micon_write(void *base, const unsigned char *buf, int count)
> +{
> +	int i = 0;
> +
> +	while (count--) {
> +		while (!(readl(UART1_REG(LSR)) & UART_LSR_THRE))
> +			barrier();
> +		writel(buf[i++], UART1_REG(TX));
> +	}
> +
> +	return 0;
> +}
> +
> +int uart1_micon_send(void *base, const unsigned char *data, int count)
> +{
> +	int i;
> +	unsigned char checksum = 0;
> +	unsigned char recv_buf[40];
> +	unsigned char send_buf[40];
> +	unsigned char correct_ack[3];
> +	int retry = 2;
> +
> +	/* Generate checksum */
> +	for (i = 0; i < count; i++)
> +		checksum -=  data[i];
> +
> +	do {
> +		/* Send data */
> +		uart1_micon_write(base, data, count);
> +
> +		/* send checksum */
> +		uart1_micon_write(base, &checksum, 1);
> +
> +		if (uart1_micon_read(base, recv_buf, sizeof(recv_buf)) <= 3) {
> +			printk(KERN_ERR ">%s: receive failed.\n", __func__);
> +
> +			/* send preamble to clear the receive buffer */
> +			memset(&send_buf, 0xff, sizeof(send_buf));
> +			uart1_micon_write(base, send_buf, sizeof(send_buf));
> +
> +			/* make dummy reads */
> +			mdelay(100);
> +			uart1_micon_read(base, recv_buf, sizeof(recv_buf));
> +		} else {
> +			/* Generate expected ack */
> +			correct_ack[0] = 0x01;
> +			correct_ack[1] = data[1];
> +			correct_ack[2] = 0x00;
> +
> +			/* checksum Check */
> +			if ((recv_buf[0] + recv_buf[1] + recv_buf[2] +
> +			     recv_buf[3]) & 0xFF) {
> +				printk(KERN_ERR ">%s: Checksum Error : "
> +					"Received data[%02x, %02x, %02x, %02x]"
> +					"\n", __func__, recv_buf[0],
> +					recv_buf[1], recv_buf[2], recv_buf[3]);
> +			} else {
> +				/* Check Received Data */
> +				if (correct_ack[0] == recv_buf[0] &&
> +				    correct_ack[1] == recv_buf[1] &&
> +				    correct_ack[2] == recv_buf[2]) {
> +					/* Interval for next command */
> +					mdelay(10);
> +
> +					/* Receive ACK */
> +					return 0;
> +				}
> +			}
> +			/* Received NAK or illegal Data */
> +			printk(KERN_ERR ">%s: Error : NAK or Illegal Data "
> +					"Received\n", __func__);
> +		}
> +	} while (retry--);
> +
> +	/* Interval for next command */
> +	mdelay(10);
> +
> +	return -1;
> +}
> diff --git a/drivers/power/reset/linkstation-common.h b/drivers/power/reset/linkstation-common.h
> new file mode 100644
> index 0000000..89c64a9
> --- /dev/null
> +++ b/drivers/power/reset/linkstation-common.h
> @@ -0,0 +1,8 @@
> +#ifndef __LINKSTATION_COMMON_H__
> +#define __LINKSTATION_COMMON_H__
> +
> +#define UART1_REG(x)	(base + ((UART_##x) << 2))
> +
> +int uart1_micon_send(void *base, const unsigned char *data, int count);
> +
> +#endif
> diff --git a/drivers/power/reset/linkstation-reset.c b/drivers/power/reset/linkstation-reset.c
> new file mode 100644
> index 0000000..78a0137
> --- /dev/null
> +++ b/drivers/power/reset/linkstation-reset.c
> @@ -0,0 +1,172 @@
> +/*
> + * Buffalo Linkstation power reset driver.
> + * It may also be used on following devices:
> + *  - Buffalo Linkstation HG
> + *  - KuroBox HG
> + *  - Buffalo KURO-NAS/T4
> + *  - KuroBox Pro
> + *  - Buffalo Linkstation Pro (LS-GL)
> + *  - Buffalo Terastation Pro II/Live
> + *  - Buffalo Linkstation Duo (LS-WTGL)
> + *  - Buffalo Linkstation Mini (LS-WSGL)
> + *
> + * Copyright (C) 2016  Roger Shimizu <rogershimizu@gmail.com>
> + *
> + * Based on the code from:
> + *
> + * Copyright (C) 2012  Andrew Lunn <andrew@lunn.ch>
> + * Copyright (C) 2009  Martin Michlmayr <tbm@cyrius.com>
> + * Copyright (C) 2008  Byron Bradley <byron.bbradley@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/serial_reg.h>
> +#include <linux/kallsyms.h>
> +#include <linux/of.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include "linkstation-common.h"
> +
> +#define MICON_CMD_SIZE	4
> +
> +/* 4-byte magic hello command to UART1-attached microcontroller */
> +static const unsigned char linkstation_micon_magic[] = {
> +	0x1b,
> +	0x00,
> +	0x07,
> +	0x00
> +};

4-byte magic hello command? Those are used as uart configuration as
far as I can see. Just move this directly into reset_cfg:

struct reset_cfg {
    u32 baud;
    u8 lcr;
    u8 ier;
    u8 fcr;
    u8 mcr;
    const unsigned char (*cmd)[MICON_CMD_SIZE];
};

> +// for each row, first byte is the size of command
> +static const unsigned char linkstation_power_off_cmd[][MICON_CMD_SIZE] = {
> +	{ 3,	0x01, 0x35, 0x00},
> +	{ 2,	0x00, 0x0c},
> +	{ 2,	0x00, 0x06},
> +	{}
> +};
> +
> +struct reset_cfg {
> +	u32 baud;
> +	const unsigned char *magic;
> +	const unsigned char (*cmd)[MICON_CMD_SIZE];
> +};
> +
> +static const struct reset_cfg linkstation_power_off_cfg = {
> +	.baud = 38400,
> +	.magic = linkstation_micon_magic,
> +	.cmd = linkstation_power_off_cmd,
> +};
> +
> +static const struct of_device_id linkstation_reset_of_match_table[] = {
> +	{ .compatible = "linkstation,power-off",
> +	  .data = &linkstation_power_off_cfg,
> +	},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, linkstation_reset_of_match_table);
> +
> +static void __iomem *base;
> +static unsigned long tclk;
> +static const struct reset_cfg *cfg;
> +
> +static void linkstation_reset(void)
> +{
> +	const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
> +
> +	pr_err("%s: triggering power-off...\n", __func__);
> +
> +	/* hijack UART1 and reset into sane state */
> +	writel(0x83, UART1_REG(LCR));
> +	writel(divisor & 0xff, UART1_REG(DLL));
> +	writel((divisor >> 8) & 0xff, UART1_REG(DLM));
> +	writel(cfg->magic[0], UART1_REG(LCR));
> +	writel(cfg->magic[1], UART1_REG(IER));
> +	writel(cfg->magic[2], UART1_REG(FCR));
> +	writel(cfg->magic[3], UART1_REG(MCR));
> +
> +	/* send the power-off command to PIC */
> +	if(cfg->cmd[0][0] == 1 && cfg->cmd[1][0] == 0) {
> +		/* if it's simply one-byte command, send it directly */
> +		writel(cfg->cmd[0][1], UART1_REG(TX));
> +	}

I guess this optimization can be dropped and you can directly
call the for loop with uart1_micon_send().

> +	else {
> +		int i;
> +		for(i = 0; cfg->cmd[i][0] > 0; i ++) {
> +			/* [0] is size of the command; command starts from [1] */
> +			uart1_micon_send(base, &(cfg->cmd[i][1]), cfg->cmd[i][0]);
> +		}
> +	}
> +}
> +
> +static int linkstation_reset_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct resource *res;
> +	struct clk *clk;
> +	char symname[KSYM_NAME_LEN];
> +
> +	const struct of_device_id *match =
> +		of_match_node(linkstation_reset_of_match_table, np);
> +	cfg = match->data;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		dev_err(&pdev->dev, "Missing resource");
> +		return -EINVAL;
> +	}
> +
> +	base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> +	if (!base) {
> +		dev_err(&pdev->dev, "Unable to map resource");
> +		return -EINVAL;
> +	}
> +
> +	/* We need to know tclk in order to calculate the UART divisor */
> +	clk = devm_clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(clk)) {
> +		dev_err(&pdev->dev, "Clk missing");
> +		return PTR_ERR(clk);
> +	}
> +
> +	tclk = clk_get_rate(clk);
> +
> +	/* Check that nothing else has already setup a handler */
> +	if (pm_power_off) {
> +		lookup_symbol_name((ulong)pm_power_off, symname);
> +		dev_err(&pdev->dev,
> +			"pm_power_off already claimed %p %s",
> +			pm_power_off, symname);
> +		return -EBUSY;
> +	}
> +	pm_power_off = linkstation_reset;
> +
> +	return 0;
> +}
> +
> +static int linkstation_reset_remove(struct platform_device *pdev)
> +{
> +	pm_power_off = NULL;
> +	return 0;
> +}
> +
> +static struct platform_driver linkstation_reset_driver = {
> +	.probe	= linkstation_reset_probe,
> +	.remove	= linkstation_reset_remove,
> +	.driver	= {
> +		.name	= "linkstation_reset",
> +		.of_match_table = of_match_ptr(linkstation_reset_of_match_table),
> +	},
> +};
> +
> +module_platform_driver(linkstation_reset_driver);
> +
> +MODULE_AUTHOR("Roger Shimizu <rogershimizu@gmail.com>");
> +MODULE_DESCRIPTION("KuroBox Pro Reset driver");
> +MODULE_LICENSE("GPL v2");

-- Sebastian

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

^ permalink raw reply

* Re: [PATCH net-next v4 2/4] dt-bindings: net: add EEE capability constants
From: Jerome Brunet @ 2016-12-19 15:16 UTC (permalink / raw)
  To: Rob Herring
  Cc: devicetree, Florian Fainelli, Alexandre TORGUE, Andrew Lunn,
	Martin Blumenstingl, netdev, Neil Armstrong, linux-kernel,
	Yegor Yefremov, Julia Lawall, Andre Roth, Kevin Hilman,
	Carlo Caione, Giuseppe Cavallaro, linux-amlogic,
	Andreas Färber, linux-arm-kernel
In-Reply-To: <20161205143942.f3w6nmp3jvmrk5es@rob-hp-laptop>

Hi Rob,

First, Thx for this information and sorry for this late reply
As you may have seen yourself, there was little bit of confusion while
discussing this patch series.

The point is the v3 was applied before your reply (patches 2 and 3 not
combined unfortunately).
Because of this confusion, the series needed a few fixes witch removes
the previously added bindings [0].
This time, I made sure to modify (remove) the bindings along with the
documentation.

[0]: http://lkml.kernel.org/r/1482159938-13239-1-git-send-email-jbrunet
@baylibre.com

Cheers
Jerome

On Mon, 2016-12-05 at 08:39 -0600, Rob Herring wrote:
> On Mon, Nov 28, 2016 at 04:50:26PM +0100, Jerome Brunet wrote:
> > 
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> > Tested-by: Andreas Färber <afaerber@suse.de>
> > Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> >  include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >  create mode 100644 include/dt-bindings/net/mdio.h
> 
> Seems changes are wanted on this, but patches 2 and 3 should be 
> combined. The header is part of the binding doc.
> 
> Rob

_______________________________________________
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 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Volodymyr Bendiuga @ 2016-12-19 15:14 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Volodymyr Bendiuga, Romain Perier, Vivien Didelot,
	Florian Fainelli, Jason Cooper, Sebastian Hesselbarth,
	Gregory Clement, netdev, devicetree, Rob Herring, Ian Campbell,
	Pawel Moll, Mark Rutland, Kumar Gala, linux-arm-kernel,
	Thomas Petazzoni, Nadav Haklai
In-Reply-To: <20161219150759.GG10048@lunn.ch>

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

Hi,

Sure, will do that.

Regards,
Volodymyr

On Mon, Dec 19, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:

> On Mon, Dec 19, 2016 at 04:04:32PM +0100, Volodymyr Bendiuga wrote:
> > Hi Andrew,
> >
> > No, it did not get accepted. Or at least I did not see
> > David accepting it. Let me know if I should resubmit it.
>
> Hi Volodymyr
>
> Please do resend it. Probably netdev will reopen sometime after the
> 25th.
>
> Don't forget to include the reviewed-by i gave.
>
> Thanks
>
>         Andrew
>

[-- Attachment #2: Type: text/html, Size: 975 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