* Re: [RFC PATCH v12 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core
From: Rafael J. Wysocki @ 2017-12-27 0:44 UTC (permalink / raw)
To: Jeffy Chen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
tony-4v6yS6AI5VpBDgjK7y7TUQ, shawn.lin-TNX95d0MmH7DzftRWevZcw,
briannorris-F7+t8E8rja9g9hUCZPvPmw,
dianders-F7+t8E8rja9g9hUCZPvPmw, Xinming Hu,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Catalin Marinas,
Kalle Valo, Heiko Stuebner,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Nishant Sarmukadam, Will Deacon, Matthias Kaehlcke,
devicetree-u79uwXL29TY76Z2rM5mHXA, Ganapathi Bhat, Frank Rowand,
Amitkumar Karwar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171226023646.17722-1-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Tuesday, December 26, 2017 3:36:41 AM CET Jeffy Chen wrote:
>
> Currently we are handling wake irq in mrvl wifi driver. Move it into
> pci core.
>
> Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
>
>
> Changes in v13:
> Fix compiler error reported by kbuild test robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> Changes in v12:
> Only add irq definitions for PCI devices and rewrite the commit message.
> Enable the wake irq in noirq stage to avoid possible irq storm.
>
> Changes in v11:
> Address Brian's comments.
> Only support 1-per-device PCIe WAKE# pin as suggested.
> Move to pcie port as Brian suggested.
>
> Changes in v10:
> Use device_set_wakeup_capable() instead of device_set_wakeup_enable(),
> since dedicated wakeirq will be lost in device_set_wakeup_enable(false).
>
> Changes in v9:
> Add section for PCI devices and rewrite the commit message.
> Fix check error in .cleanup().
> Move dedicated wakeirq setup to setup() callback and use
> device_set_wakeup_enable() to enable/disable.
> Rewrite the commit message.
>
> Changes in v8:
> Add optional "pci", and rewrite commit message.
> Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.
> Rewrite the commit message.
>
> Changes in v7:
> Move PCIE_WAKE handling into pci core.
>
> Changes in v6:
> Fix device_init_wake error handling, and add some comments.
>
> Changes in v5:
> Move to pci.txt
> Rebase.
> Use "wakeup" instead of "wake"
>
> Changes in v3:
> Fix error handling.
>
> Changes in v2:
> Use dev_pm_set_dedicated_wake_irq.
>
> Jeffy Chen (5):
> dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
> of/irq: Adjust of_pci_irq parsing for multiple interrupts
> mwifiex: Disable wakeup irq handling for pcie
> PCI / PM: Add support for the PCIe WAKE# signal for OF
> arm64: dts: rockchip: Move PCIe WAKE# irq to pcie port for Gru
>
> Documentation/devicetree/bindings/pci/pci.txt | 10 ++++
> arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 11 ++--
> drivers/net/wireless/marvell/mwifiex/main.c | 4 ++
> drivers/of/of_pci_irq.c | 71 +++++++++++++++++++++++--
> drivers/pci/Makefile | 1 +
> drivers/pci/pci-driver.c | 10 ++++
> drivers/pci/pci-of.c | 75 +++++++++++++++++++++++++++
> include/linux/of_pci.h | 9 ++++
> 8 files changed, 183 insertions(+), 8 deletions(-)
> create mode 100644 drivers/pci/pci-of.c
I'm going to ignore this version till the discussion on the previous one is
over.
Thanks,
Rafael
--
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: [RFC PATCH v12 1/5] dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
From: Rafael J. Wysocki @ 2017-12-27 0:43 UTC (permalink / raw)
To: Rob Herring
Cc: Jeffy Chen, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
tony-4v6yS6AI5VpBDgjK7y7TUQ, shawn.lin-TNX95d0MmH7DzftRWevZcw,
briannorris-F7+t8E8rja9g9hUCZPvPmw,
dianders-F7+t8E8rja9g9hUCZPvPmw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <20171226233552.nacwqbpkozmy7n6c@rob-hp-laptop>
On Wednesday, December 27, 2017 12:35:52 AM CET Rob Herring wrote:
> On Tue, Dec 26, 2017 at 10:36:42AM +0800, Jeffy Chen wrote:
> > We are going to handle PCIe WAKE# pin for PCI devices in the pci core,
> > so add definitions of the optional PCIe WAKE# pin for PCI devices.
> >
> > Also add an definition of the optional PCI interrupt pin for PCI
> > devices to distinguish it from the PCIe WAKE# pin.
>
> By v13 you should drop "RFC". RFC implies not ready for merging.
Which very much still is the case AFAICS.
Thanks,
Rafael
--
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 4/4] [media] dt/bindings: Add bindings for OV2685
From: Shunqian Zheng @ 2017-12-27 0:40 UTC (permalink / raw)
To: Rob Herring; +Cc: mchehab, mark.rutland, linux-media, devicetree, ddl, tfiga
In-Reply-To: <20171226232855.egppgy22ywketxi6@rob-hp-laptop>
Rob,
On 2017年12月27日 07:28, Rob Herring wrote:
> On Mon, Dec 25, 2017 at 10:11:26PM +0800, Shunqian Zheng wrote:
>> Add device tree binding documentation for the OV2685 sensor.
>>
>> Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
>> ---
>> .../devicetree/bindings/media/i2c/ov2685.txt | 35 ++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2685.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov2685.txt b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
>> new file mode 100644
>> index 0000000..c62db9c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
>> @@ -0,0 +1,35 @@
>> +* Omnivision OV2685 MIPI CSI-2 sensor
>> +
>> +Required Properties:
>> +- compatible: should be "ovti,ov2685"
>> +- clocks: reference to the 24M xvclk input clock.
>> +- clock-names: should be "xvclk".
>> +- avdd-supply: Analog voltage supply, 2.8 volts
>> +- dvdd-supply: Digital core voltage supply, 1.2 volts
>> +- reset-gpios: Low active reset gpio
>> +
>> +The device node must contain one 'port' child node for its digital output
>> +video port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +Example:
>> + ucam: ov2680@3c {
> camera-sensor@3c
>
>> + compatible = "ovti,ov2685";
>> + reg = <0x3c>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&clk_24m_cam &ucam_rst>;
> Not documented.
The &clk_24m_cam is pin mux on my rk3399. While the &ucam_rst is board
special pin, I should remove it in Document.
Thanks,
Shunqian
>
>> +
>> + clocks = <&cru SCLK_TESTCLKOUT1>;
>> + clock-names = "xvclk";
>> +
>> + avdd-supply = <&pp2800_cam>;
>> + dovdd-supply = <&pp1800>;
>> + reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
>> +
>> + port {
>> + ucam_out: endpoint {
>> + remote-endpoint = <&mipi_in_ucam>;
>> + data-lanes = <1>;
>> + };
>> + };
>> + };
>> --
>> 1.9.1
>>
>
>
^ permalink raw reply
* Re: [PATCH] Input: mms114 - drop platform data and use generic APIs
From: Rob Herring @ 2017-12-26 23:57 UTC (permalink / raw)
To: Simon Shields; +Cc: Dmitry Torokhov, Andi Shyti, linux-input, devicetree
In-Reply-To: <20171226032511.17726-1-simon@lineageos.org>
On Tue, Dec 26, 2017 at 02:25:11PM +1100, Simon Shields wrote:
> The MMS114 platform data has no in-tree users, so drop it,
> and make the driver depend on CONFIG_OF.
>
> Switch to using the standard touchscreen properties via
> touchscreen_parse_properties(), and move the old DT parsing code
> to use device_property_*() APIs.
>
> Finally, use touchscreen_report_pos to report x/y coordinates
> and drop the custom x/y inversion code.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> .../bindings/input/touchscreen/mms114.txt | 29 ++--
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/input/touchscreen/Kconfig | 1 +
> drivers/input/touchscreen/mms114.c | 146 +++++++++------------
> include/linux/platform_data/mms114.h | 24 ----
> 4 files changed, 77 insertions(+), 123 deletions(-)
> delete mode 100644 include/linux/platform_data/mms114.h
^ permalink raw reply
* Re: [RFC PATCH v12 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF
From: Rob Herring @ 2017-12-26 23:56 UTC (permalink / raw)
To: Jeffy Chen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
tony-4v6yS6AI5VpBDgjK7y7TUQ, shawn.lin-TNX95d0MmH7DzftRWevZcw,
briannorris-F7+t8E8rja9g9hUCZPvPmw, rjw-LthD3rsA81gm4RdzfppkhA,
dianders-F7+t8E8rja9g9hUCZPvPmw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Frank Rowand
In-Reply-To: <20171226023646.17722-5-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Tue, Dec 26, 2017 at 10:36:45AM +0800, Jeffy Chen wrote:
> Add of_pci_setup_wake_irq() and of_pci_teardown_wake_irq() to handle
> the PCIe WAKE# interrupt.
>
> Also use the dedicated wakeirq infrastructure to simplify it.
>
> And add pci-of.c to enable/disable the wakeup irq in noirq stage to
> avoid possible irq storm.
>
> Signed-off-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Changes in v13:
> Fix compiler error reported by kbuild test robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> Changes in v12:
> Enable the wake irq in noirq stage to avoid possible irq storm.
>
> Changes in v11:
> Only support 1-per-device PCIe WAKE# pin as suggested.
>
> Changes in v10:
> Use device_set_wakeup_capable() instead of device_set_wakeup_enable(),
> since dedicated wakeirq will be lost in device_set_wakeup_enable(false).
>
> Changes in v9:
> Fix check error in .cleanup().
> Move dedicated wakeirq setup to setup() callback and use
> device_set_wakeup_enable() to enable/disable.
>
> Changes in v8:
> Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.
>
> Changes in v7:
> Move PCIE_WAKE handling into pci core.
>
> Changes in v6:
> Fix device_init_wake error handling, and add some comments.
>
> Changes in v5:
> Rebase.
>
> Changes in v3:
> Fix error handling.
>
> Changes in v2:
> Use dev_pm_set_dedicated_wake_irq.
>
> drivers/of/of_pci_irq.c | 49 +++++++++++++++++++++++++++++++
Please move this to drivers/pci/of.c (or perhaps create pci/of_irq.c).
> drivers/pci/Makefile | 1 +
> drivers/pci/pci-driver.c | 10 +++++++
> drivers/pci/pci-of.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++
We already have drivers/pci/of.c. It's not clear what the difference is
from the filenames. Either merge with of.c or perhaps of-pm.c.
> include/linux/of_pci.h | 9 ++++++
> 5 files changed, 144 insertions(+)
> create mode 100644 drivers/pci/pci-of.c
>
> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
> index d39565d5477b..abec3a44853b 100644
> --- a/drivers/of/of_pci_irq.c
> +++ b/drivers/of/of_pci_irq.c
> @@ -1,8 +1,57 @@
> #include <linux/kernel.h>
> #include <linux/of_pci.h>
> #include <linux/of_irq.h>
> +#include <linux/pm_wakeirq.h>
> #include <linux/export.h>
>
> +int of_pci_setup_wake_irq(struct pci_dev *pdev)
> +{
> + struct pci_dev *ppdev;
> + struct device_node *dn;
> + int ret, irq;
> +
> + /* Get the pci_dev of our parent. Hopefully it's a port. */
> + ppdev = pdev->bus->self;
> + /* Nope, it's a host bridge. */
> + if (!ppdev)
> + return 0;
> +
> + dn = pci_device_to_OF_node(ppdev);
> + if (!dn)
> + return 0;
> +
> + irq = of_irq_get_byname(dn, "wakeup");
> + if (irq == -EPROBE_DEFER) {
> + return irq;
> + } else if (irq < 0) {
> + /* Ignore other errors, since a missing wakeup is non-fatal. */
> + dev_info(&pdev->dev, "cannot get wakeup interrupt: %d\n", irq);
> + return 0;
> + }
> +
> + device_init_wakeup(&pdev->dev, true);
> +
> + ret = dev_pm_set_dedicated_wake_irq(&pdev->dev, irq);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to set wake IRQ: %d\n", ret);
> + device_init_wakeup(&pdev->dev, false);
> + return ret;
> + }
> +
> + /* Start out disabled to avoid irq storm */
> + dev_pm_disable_wake_irq(&pdev->dev);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_setup_wake_irq);
> +
> +void of_pci_teardown_wake_irq(struct pci_dev *pdev)
> +{
> + dev_pm_clear_wake_irq(&pdev->dev);
> + device_init_wakeup(&pdev->dev, false);
> +}
> +EXPORT_SYMBOL_GPL(of_pci_teardown_wake_irq);
> +
> /**
> * of_irq_parse_pci - Resolve the interrupt for a PCI device
> * @pdev: the device whose interrupt is to be resolved
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index c7819b973df7..d0182c82162a 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_PCI_IOV) += iov.o
> # ACPI _DSM provided firmware instance and string name
> #
> obj-$(CONFIG_ACPI) += pci-acpi.o
> +obj-$(CONFIG_OF) += pci-of.o
>
> # SMBIOS provided firmware instance and labels
> obj-$(CONFIG_PCI_LABEL) += pci-label.o
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index d79dbc377b9c..b4475ff35d97 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -17,6 +17,7 @@
> #include <linux/slab.h>
> #include <linux/sched.h>
> #include <linux/cpu.h>
> +#include <linux/of_pci.h>
> #include <linux/pm_runtime.h>
> #include <linux/suspend.h>
> #include <linux/kexec.h>
> @@ -421,10 +422,17 @@ static int pci_device_probe(struct device *dev)
> if (error < 0)
> return error;
>
> + error = of_pci_setup_wake_irq(pci_dev);
> + if (error < 0) {
> + pcibios_free_irq(pci_dev);
> + return error;
> + }
> +
> pci_dev_get(pci_dev);
> if (pci_device_can_probe(pci_dev)) {
> error = __pci_device_probe(drv, pci_dev);
> if (error) {
> + of_pci_teardown_wake_irq(pci_dev);
> pcibios_free_irq(pci_dev);
> pci_dev_put(pci_dev);
> }
> @@ -438,6 +446,8 @@ static int pci_device_remove(struct device *dev)
> struct pci_dev *pci_dev = to_pci_dev(dev);
> struct pci_driver *drv = pci_dev->driver;
>
> + of_pci_teardown_wake_irq(pci_dev);
> +
> if (drv) {
> if (drv->remove) {
> pm_runtime_get_sync(dev);
> diff --git a/drivers/pci/pci-of.c b/drivers/pci/pci-of.c
> new file mode 100644
> index 000000000000..ad413b2de508
> --- /dev/null
> +++ b/drivers/pci/pci-of.c
> @@ -0,0 +1,75 @@
> +/*
> + * File: pci-of.c
> + * Purpose: Provide PCI PM/wakeup support in OF systems
> + *
> + * Copyright (C) 2017 Google, Inc.
> + * Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> + *
> + * Copyright (C) 2017 Rockchip Electronics Co., Ltd.
> + * Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/pm_wakeirq.h>
> +#include "pci.h"
> +
> +static bool of_pci_power_manageable(struct pci_dev *dev)
> +{
> + return false;
> +}
> +
> +static int of_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
> +{
> + return -ENOSYS;
> +}
> +
> +static pci_power_t of_pci_get_power_state(struct pci_dev *dev)
> +{
> + return PCI_UNKNOWN;
> +}
> +
> +static pci_power_t of_pci_choose_state(struct pci_dev *pdev)
> +{
> + return PCI_POWER_ERROR;
> +}
> +
> +static int of_pci_wakeup(struct pci_dev *dev, bool enable)
> +{
> + if (enable)
> + dev_pm_enable_wake_irq(&dev->dev);
> + else
> + dev_pm_disable_wake_irq(&dev->dev);
> + return 0;
> +}
> +
> +static bool of_pci_need_resume(struct pci_dev *dev)
> +{
> + return false;
> +}
> +
> +static const struct pci_platform_pm_ops of_pci_platform_pm = {
> + .is_manageable = of_pci_power_manageable,
> + .set_state = of_pci_set_power_state,
> + .get_state = of_pci_get_power_state,
> + .choose_state = of_pci_choose_state,
> + .set_wakeup = of_pci_wakeup,
> + .need_resume = of_pci_need_resume,
> +};
> +
> +static int __init of_pci_init(void)
> +{
> + if (!acpi_disabled)
> + return 0;
> +
> + pci_set_platform_pm(&of_pci_platform_pm);
I guess no DT based system will override this?
> +
> + return 0;
> +}
> +arch_initcall(of_pci_init);
--
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: [RFC PATCH v12 1/5] dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
From: Rob Herring @ 2017-12-26 23:35 UTC (permalink / raw)
To: Jeffy Chen
Cc: linux-kernel, bhelgaas, linux-pm, tony, shawn.lin, briannorris,
rjw, dianders, devicetree, linux-pci, Mark Rutland
In-Reply-To: <20171226023646.17722-2-jeffy.chen@rock-chips.com>
On Tue, Dec 26, 2017 at 10:36:42AM +0800, Jeffy Chen wrote:
> We are going to handle PCIe WAKE# pin for PCI devices in the pci core,
> so add definitions of the optional PCIe WAKE# pin for PCI devices.
>
> Also add an definition of the optional PCI interrupt pin for PCI
> devices to distinguish it from the PCIe WAKE# pin.
By v13 you should drop "RFC". RFC implies not ready for merging.
>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> ---
>
> Changes in v13: None
> Changes in v12:
> Only add irq definitions for PCI devices and rewrite the commit message.
>
> Changes in v11: None
> Changes in v10: None
> Changes in v9:
> Add section for PCI devices and rewrite the commit message.
>
> Changes in v8:
> Add optional "pci", and rewrite commit message.
>
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> Move to pci.txt
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/pci/pci.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [v2] ASoC: max98373: Added Amplifier Driver
From: Rob Herring @ 2017-12-26 23:33 UTC (permalink / raw)
To: Ryan Lee
Cc: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
arnd-r2nGTMty4D4, afd-l0cyMroinI0, robert.jarzmik-GANU6spQydw,
supercraig0719-Re5JQEeQqe8AvxtiuMwx3w,
jbrunet-rdvid1DuHRBWk0Htik3J/w, dannenberg-l0cyMroinI0,
romain.perier-ZGY8ohtN/8qB+jHODAdFcQ,
bryce.ferguson-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR,
kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ,
m-stecklein-l0cyMroinI0, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ryan.lee.maxim-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1514214610-17630-1-git-send-email-ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
On Mon, Dec 25, 2017 at 07:10:10AM -0800, Ryan Lee wrote:
Needs a commit message.
> Signed-off-by: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
> ---
>
> Changes since v1:
> * Removed 'codec' from 'max98373_priv' structure
> : Now 'max98373_set_clock' function use 'dai->codec.dev' instead of using 'max98373->codec.dev'.
> * Removed 'max98373_dai_set_sysclk' function
> : This function is not necessary. Removed 'sysclk' from 'max98373_priv' as well.
> * Removed 'iface' from 'max98373_priv' structure
> : There is no function who refer max98373->iface variable.
> * Added SPDX-License-Identifier
>
> .../devicetree/bindings/sound/max98373.txt | 43 +
Please split bindings to separate patch.
> sound/soc/codecs/Kconfig | 5 +
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/max98373.c | 974 +++++++++++++++++++++
> sound/soc/codecs/max98373.h | 212 +++++
> 5 files changed, 1236 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/max98373.txt
> create mode 100644 sound/soc/codecs/max98373.c
> create mode 100644 sound/soc/codecs/max98373.h
>
> diff --git a/Documentation/devicetree/bindings/sound/max98373.txt b/Documentation/devicetree/bindings/sound/max98373.txt
> new file mode 100644
> index 0000000..22cd259
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/max98373.txt
> @@ -0,0 +1,43 @@
> +Maxim Integrated MAX98373 Speaker Amplifier
> +
> +This device supports I2C.
> +
> +Required properties:
> +
> + - compatible : should be one of the following
> + - "maxim,max98373"
> +
> + - reg : the I2C address of the device.
> +
> +Optional properties:
> +
> + - maxim,vmon-slot-no : slot number used to send voltage information
> + or in inteleave mode this will be used as
> + interleave slot.
> + slot range : 0 ~ 15, Default : 0
> +
> + - maxim,imon-slot-no : slot number used to send current information
> + slot range : 0 ~ 15, Default : 0
> +
> + - maxim,spkfb-slot-no : slot number used to send speaker feedback information
> + slot range : 0 ~ 15, Default : 0
> +
> + - maxim,interleave-mode : When using two MAX98373 in a system it is
> + possible to create ADC data that that will
> + overflow the frame size. Digital Audio Interleave
> + mode provides a means to output VMON and IMON data
> + from two devices on a single DOUT line when running
> + smaller frames sizes such as 32 BCLKS per LRCLK or
> + 48 BCLKS per LRCLK.
> + Range : 0 (off), 1 (on), Default : 0
This can be boolean instead.
> +
> +Example:
> +
> +codec: max98373@31 {
> + compatible = "maxim,max98373";
> + reg = <0x31>;
> + maxim,vmon-slot-no = <0>;
> + maxim,imon-slot-no = <1>;
> + maxim,spkfb-slot-no = <2>;
> + maxim,interleave-mode = <0>;
> +};
--
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 4/4] [media] dt/bindings: Add bindings for OV2685
From: Rob Herring @ 2017-12-26 23:28 UTC (permalink / raw)
To: Shunqian Zheng
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, ddl-TNX95d0MmH7DzftRWevZcw,
tfiga-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <1514211086-13440-4-git-send-email-zhengsq-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Mon, Dec 25, 2017 at 10:11:26PM +0800, Shunqian Zheng wrote:
> Add device tree binding documentation for the OV2685 sensor.
>
> Signed-off-by: Shunqian Zheng <zhengsq-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> .../devicetree/bindings/media/i2c/ov2685.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2685.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov2685.txt b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
> new file mode 100644
> index 0000000..c62db9c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
> @@ -0,0 +1,35 @@
> +* Omnivision OV2685 MIPI CSI-2 sensor
> +
> +Required Properties:
> +- compatible: should be "ovti,ov2685"
> +- clocks: reference to the 24M xvclk input clock.
> +- clock-names: should be "xvclk".
> +- avdd-supply: Analog voltage supply, 2.8 volts
> +- dvdd-supply: Digital core voltage supply, 1.2 volts
> +- reset-gpios: Low active reset gpio
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> + ucam: ov2680@3c {
camera-sensor@3c
> + compatible = "ovti,ov2685";
> + reg = <0x3c>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam &ucam_rst>;
Not documented.
> +
> + clocks = <&cru SCLK_TESTCLKOUT1>;
> + clock-names = "xvclk";
> +
> + avdd-supply = <&pp2800_cam>;
> + dovdd-supply = <&pp1800>;
> + reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
> +
> + port {
> + ucam_out: endpoint {
> + remote-endpoint = <&mipi_in_ucam>;
> + data-lanes = <1>;
> + };
> + };
> + };
> --
> 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 2/4] [media] dt/bindings: Add bindings for OV5695
From: Rob Herring @ 2017-12-26 23:27 UTC (permalink / raw)
To: Shunqian Zheng; +Cc: mchehab, mark.rutland, linux-media, devicetree, ddl, tfiga
In-Reply-To: <1514211086-13440-2-git-send-email-zhengsq@rock-chips.com>
On Mon, Dec 25, 2017 at 10:11:24PM +0800, Shunqian Zheng wrote:
> Add device tree binding documentation for the OV5695 sensor.
>
> Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
> ---
> .../devicetree/bindings/media/i2c/ov5695.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5695.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5695.txt b/Documentation/devicetree/bindings/media/i2c/ov5695.txt
> new file mode 100644
> index 0000000..ed27eb1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5695.txt
> @@ -0,0 +1,38 @@
> +* Omnivision OV5695 MIPI CSI-2 sensor
> +
> +Required Properties:
> +- compatible: should be "ovti,ov5695"
> +- clocks: reference to the 24M xvclk input clock.
> +- clock-names: should be "xvclk".
> +- dovdd-supply: Digital I/O voltage supply, 1.8 volts
> +- avdd-supply: Analog voltage supply, 2.8 volts
> +- dvdd-supply: Digital core voltage supply, 1.2 volts
> +- reset-gpios: Low active reset gpio
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +&i2c1 {
Presumably, i2c1 is your I2C controller, so you are missing a child node
here: camera-sensor@36
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> + compatible = "ovti,ov5695";
> + reg = <0x36>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam &wcam_rst>;
> +
> + clocks = <&cru SCLK_TESTCLKOUT1>;
> + clock-names = "xvclk";
> +
> + avdd-supply = <&pp2800_cam>;
> + dvdd-supply = <&pp1250_cam>;
> + dovdd-supply = <&pp1800>;
> +
> + reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> +
> + port {
> + wcam_out: endpoint {
> + remote-endpoint = <&mipi_in_wcam>;
> + data-lanes = <1 2>;
> + };
> + };
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap,memcpy'
From: Rob Herring @ 2017-12-26 23:23 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ, richard-/L3Ra7n9ekc,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
broonie-DgEjT+Ai2ygdnm+yROfE0A, vigneshr-l0cyMroinI0,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
radu.pirea-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <143542c61ca674d53da4985bbabc142e8e6ebefc.1514087323.git.cyrille.pitchen-yU5RGvR974pGWvitb5QawA@public.gmane.org>
On Sun, Dec 24, 2017 at 05:36:05AM +0100, Cyrille Pitchen wrote:
> The optional 'dmacap,memcpy' DT property tells the Atmel QSPI controller
> driver to reserve some DMA channel then to use it to perform DMA
> memcpy() during data transfers. This feature relies on the generic
> bounce buffer helper from spi-nor.c.
>
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen-yU5RGvR974pGWvitb5QawA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mtd/atmel-quadspi.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> index b93c1e2f25dd..002d3f0a445b 100644
> --- a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> +++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> @@ -12,6 +12,10 @@ Required properties:
> - #address-cells: Should be <1>.
> - #size-cells: Should be <0>.
>
> +Optional properties:
> +- dmacap,memcpy: Reserve a DMA channel to perform DMA memcpy() between the
> + system memory and the QSPI mapped memory.
How is this a h/w property? Why would I not want to always enable DMA if
possible?
Furthermore, you are reusing a property, but giving it a different
meaning. The current definition is an indication whether a DMA
controller supports memcpy operations or not. It is not a flag for
clients to use memcpy channels.
Why don't you use "dmas" property to point to the DMA controller.
> +
> Example:
>
> spi@f0020000 {
> @@ -24,6 +28,7 @@ spi@f0020000 {
> #size-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_spi0_default>;
> + dmacap,memcpy;
>
> m25p80@0 {
> ...
> --
> 2.11.0
>
> --
> 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
--
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: [PATCHv4 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec
From: Rob Herring @ 2017-12-26 23:05 UTC (permalink / raw)
To: Jassi Brar
Cc: netdev,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
David Miller, Arnd Bergmann, Andrew Lunn, Ard Biesheuvel,
Mark Rutland, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1514007911-16674-1-git-send-email-jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Dec 22, 2017 at 11:45 PM, <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Jassi Brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> This patch adds documentation for Device-Tree bindings for the
> Socionext NetSec Controller driver.
>
> Signed-off-by: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/net/socionext-netsec.txt | 55 ++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/socionext-netsec.txt
One other comment besides issues discussed on v2...
> diff --git a/Documentation/devicetree/bindings/net/socionext-netsec.txt b/Documentation/devicetree/bindings/net/socionext-netsec.txt
> new file mode 100644
> index 0000000..adc7bfa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt
> @@ -0,0 +1,55 @@
> +* Socionext NetSec Ethernet Controller IP
> +
> +Required properties:
> +- compatible: Should be "socionext,synquacer-netsec"
> +- reg: Address and length of the control register area, followed by the
> + address and length of the EEPROM holding the MAC address and
> + microengine firmware
> +- interrupts: Should contain ethernet controller interrupt
> +- clocks: phandle to the PHY reference clock, and any other clocks to be
> + switched by runtime_pm
> +- clock-names: Required only if more than a single clock is listed in 'clocks'.
> + The PHY reference clock must be named 'phy_refclk'
> +- phy-mode: See ethernet.txt file in the same directory
> +- phy-handle: See ethernet.txt in the same directory.
> +
> +- mdio device tree subnode: When the Netsec has a phy connected to its local
> + mdio, there must be device tree subnode with the following
> + required properties:
> +
> + - #address-cells: Must be <1>.
> + - #size-cells: Must be <0>.
> +
> + For each phy on the mdio bus, there must be a node with the following
> + fields:
> + - compatible: Refer to phy.txt
> + - reg: phy id used to communicate to phy.
> +
> +Optional properties: (See ethernet.txt file in the same directory)
> +- dma-coherent: Boolean property, must only be present if memory
> + accesses performed by the device are cache coherent.
> +- local-mac-address: See ethernet.txt in the same directory.
> +- mac-address: See ethernet.txt in the same directory.
> +- max-speed: See ethernet.txt in the same directory.
> +- max-frame-size: See ethernet.txt in the same directory.
> +
> +Example:
> + eth0: netsec@522d0000 {
ethernet@...
--
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: [PATCHv2 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec
From: Rob Herring @ 2017-12-26 23:01 UTC (permalink / raw)
To: Jassi Brar
Cc: Mark Rutland, <netdev@vger.kernel.org>, Devicetree List,
David S . Miller, Arnd Bergmann, Ard Biesheuvel, Jassi Brar,
Masami Hiramatsu
In-Reply-To: <CABb+yY20nLJw5m4tq6Zrrqh7SGCWsFKsjzuK6oDFgvD6qS4nrg@mail.gmail.com>
On Wed, Dec 20, 2017 at 2:02 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> Hi Mark,
>
> On Tue, Dec 12, 2017 at 10:59 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> Hi,
>>
>> On Tue, Dec 12, 2017 at 10:45:21PM +0530, jassisinghbrar@gmail.com wrote:
>>> From: Jassi Brar <jassisinghbrar@gmail.com>
>>>
>>> This patch adds documentation for Device-Tree bindings for the
>>> Socionext NetSec Controller driver.
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
>>> ---
>>> .../devicetree/bindings/net/socionext-netsec.txt | 43 ++++++++++++++++++++++
>>> 1 file changed, 43 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/net/socionext-netsec.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/socionext-netsec.txt b/Documentation/devicetree/bindings/net/socionext-netsec.txt
>>> new file mode 100644
>>> index 0000000..4695969
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt
>>> @@ -0,0 +1,45 @@
>>> +* Socionext NetSec Ethernet Controller IP
>>> +
>>> +Required properties:
>>> +- compatible: Should be "socionext,synquacer-netsec"
>>> +- reg: Address and length of the control register area, followed by the
>>> + address and length of the EEPROM holding the MAC address and
>>> + microengine firmware
>>> +- interrupts: Should contain ethernet controller interrupt
>>> +- clocks: phandle to the PHY reference clock, and any other clocks to be
>>> + switched by runtime_pm
runtime_pm is a Linux thing and driver detail.
>>> +- clock-names: Required only if more than a single clock is listed in 'clocks'.
>>> + The PHY reference clock must be named 'phy_refclk'
>>
>> Please define the full set of clocks (and their names) explicitly. This
>> should be well-known.
>>
> The issue is some implementations have just the 'rate-reference' clock
> going in, while others may also have 1or2 optional 'enable' clocks
> (which may go to other devices as well).
> The driver only needs to know which clock to read the freq from, so it
> expects that clock to be named 'phy_refclk', while the 'enable' clocks
> can be named anything.
It still needs to be documented.
If there's differing number of clocks, then I expect a compatible
string for each possible clock setup. Of course, differing number of
clocks for the same block is often an error when multiple clock inputs
are driven by the same source clock.
Rob
^ permalink raw reply
* Re: [PATCH] mmc: Don't reference Linux-specific OF_GPIO_ACTIVE_LOW flag in DT binding
From: Rob Herring @ 2017-12-26 22:53 UTC (permalink / raw)
To: Tuomas Tynkkynen
Cc: Ulf Hansson, Mark Rutland, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171223003412.13688-1-tuomas-yrGDUoBaLx3QT0dZR+AlfA@public.gmane.org>
On Sat, Dec 23, 2017 at 02:34:12AM +0200, Tuomas Tynkkynen wrote:
> OF_GPIO_ACTIVE_LOW is a Linux implementation detail. The binding
> document should be referring to GPIO_ACTIVE_LOW found in
> include/dt-bindings/gpio/gpio.h.
>
> Signed-off-by: Tuomas Tynkkynen <tuomas-yrGDUoBaLx3QT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/mmc.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
Rob
--
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: [PATCHv3 RESEND 1/3] Documentation: dt: memory: ti-emif: add edac support under emif
From: Rob Herring @ 2017-12-26 22:50 UTC (permalink / raw)
To: Tero Kristo
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-omap,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Tony Lindgren
In-Reply-To: <20171226224819.6uekbnbd5tllaxb5@rob-hp-laptop>
On Tue, Dec 26, 2017 at 4:48 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 22, 2017 at 06:23:54PM +0200, Tero Kristo wrote:
>> Certain revisions of the TI EMIF IP contain ECC support in them. Reflect
>> this in the DT binding.
>
> "dt-bindings: edac: ..." is the preferred subject prefix.
Err, I mean "dt-bindings: memory-controllers: ..."
Rob
--
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: [PATCHv3 RESEND 1/3] Documentation: dt: memory: ti-emif: add edac support under emif
From: Rob Herring @ 2017-12-26 22:48 UTC (permalink / raw)
To: Tero Kristo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tony Lindgren
In-Reply-To: <1513959834-27901-1-git-send-email-t-kristo-l0cyMroinI0@public.gmane.org>
On Fri, Dec 22, 2017 at 06:23:54PM +0200, Tero Kristo wrote:
> Certain revisions of the TI EMIF IP contain ECC support in them. Reflect
> this in the DT binding.
"dt-bindings: edac: ..." is the preferred subject prefix.
>
> Signed-off-by: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Just resending this patch, missed adding devicetree list on this previously
> and it got lost.
>
> .../devicetree/bindings/memory-controllers/ti/emif.txt | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> index 0db6047..f56a347 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> @@ -3,12 +3,16 @@
> EMIF - External Memory Interface - is an SDRAM controller used in
> TI SoCs. EMIF supports, based on the IP revision, one or more of
> DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
> -of the EMIF IP and memory parts attached to it.
> +of the EMIF IP and memory parts attached to it. Certain revisions
> +of the EMIF IP controller also contain optional ECC support, which
> +corrects one bit errors and detects two bit errors.
>
> Required properties:
> - compatible : Should be of the form "ti,emif-<ip-rev>" where <ip-rev>
> is the IP revision of the specific EMIF instance.
> For am437x should be ti,emif-am4372.
> + For dra7xx should be ti,emif-dra7xx.
> + For k2x family, should be ti,emif-keystone.
>
> - phy-type : <u32> indicating the DDR phy type. Following are the
> allowed values
> @@ -42,6 +46,10 @@ Optional properties:
> - hw-caps-temp-alert : Have this property if the controller
> has capability for generating SDRAM temperature alerts
>
> +- interrupts : A list of interrupt specifiers for memory
> + controller interrupts, if available. Required for EMIF instances
> + that support ECC.
Be explicit as to which compatibles have an interrupt. Is it really
optional for for those controllers? The interrupt is in the h/w whether
you use ECC or not.
> +
> Example:
>
> emif1: emif@0x4c000000 {
> @@ -54,3 +62,9 @@ emif1: emif@0x4c000000 {
> hw-caps-ll-interface;
> hw-caps-temp-alert;
> };
> +
> +emif1: emif@4c000000 {
> + compatible = "ti,emif-dra7";
> + reg = <0x4c000000 0x200>;
> + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
> +};
> --
> 1.9.1
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
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 13/14] input: touchscreen: sama5d2_rts: SAMA5D2 Resistive touchscreen driver
From: Rob Herring @ 2017-12-26 22:41 UTC (permalink / raw)
To: Eugen Hristev
Cc: nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
linux-input-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1513955241-10985-14-git-send-email-eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
On Fri, Dec 22, 2017 at 05:07:20PM +0200, Eugen Hristev wrote:
> This is the implementation of the Microchip SAMA5D2 SOC resistive
> touchscreen driver.
> The driver registers an input device and connects to the give IIO device
> from devicetree. It requires an IIO trigger (acting as a consumer) and
> three IIO channels : one for X position, one for Y position and one
> for pressure.
> It the reports the values to the input subsystem.
>
> Some parts of this driver are based on the initial original work by
> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
This doesn't appear to have anything specific to SAMA5D2 SoC, but is
rather just a generic ADC (IIO based) resistive touchscreen driver.
Perhaps the binding can also be just an "adc-resistive-touchscreen".
Rob
--
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 03/14] dt-bindings: iio: add binding support for iio trigger provider/consumer
From: Rob Herring @ 2017-12-26 22:35 UTC (permalink / raw)
To: Eugen Hristev
Cc: nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
linux-input-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1513955241-10985-4-git-send-email-eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
On Fri, Dec 22, 2017 at 05:07:10PM +0200, Eugen Hristev wrote:
> Add bindings for producer/consumer for iio triggers.
>
> Similar with iio channels, the iio triggers can be connected between drivers:
> one driver will be a producer by registering iio triggers, and another driver
> will connect as a consumer.
>
> Signed-off-by: Eugen Hristev <eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
> .../devicetree/bindings/iio/iio-bindings.txt | 52 +++++++++++++++++++++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> index 68d6f8c..d861f0df 100644
> --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> @@ -11,6 +11,10 @@ value of a #io-channel-cells property in the IIO provider node.
>
> [1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
>
> +Moreover, the provider can have a set of triggers that can be attached to
> +from the consumer drivers.
> +
> +
> ==IIO providers==
>
> Required properties:
> @@ -18,6 +22,11 @@ Required properties:
> with a single IIO output and 1 for nodes with multiple
> IIO outputs.
>
> +Optional properties:
> +#io-trigger-cells: Number of cells for the IIO trigger specifier. Typically 0
> + for nodes with a single IIO trigger and 1 for nodes with
> + multiple IIO triggers.
> +
> Example for a simple configuration with no trigger:
>
> adc: voltage-sensor@35 {
> @@ -26,7 +35,7 @@ Example for a simple configuration with no trigger:
> #io-channel-cells = <1>;
> };
>
> -Example for a configuration with trigger:
> +Example for a configuration with channels provided by trigger:
>
> adc@35 {
> compatible = "some-vendor,some-adc";
> @@ -42,6 +51,17 @@ Example for a configuration with trigger:
> };
> };
>
> +Example for a configuration for a trigger provider:
> +
> + adc: sensor-with-trigger@35 {
> + compatible = "some-vendor,some-adc";
> + reg = <0x35>;
> + #io-channel-cells = <1>;
> + #io-trigger-cells = <1>;
> + /* other properties */
> + };
> +
> +
> ==IIO consumers==
>
> Required properties:
> @@ -61,16 +81,38 @@ io-channel-ranges:
> IIO channels from this node. Useful for bus nodes to provide
> and IIO channel to their children.
>
> +io-triggers: List of phandle and IIO specifier pairs, one pair
> + for each trigger input to the device. Note: if the
> + IIO trigger provider specifies '0' for #io-trigger-cells,
> + then only the phandle portion of the pair will appear.
> +
> +io-trigger-names:
> + List of IIO trigger input name strings sorted in the same
> + order as the io-triggers property. Consumers drivers
> + will use io-trigger-names to match IIO trigger input names
> + with IIO specifiers.
> +
> +io-trigger-ranges:
> + Empty property indicating that child nodes can inherit named
> + IIO triggers from this node. Useful for bus nodes to provide
> + IIO triggers to their children.
I think it would be better to be explicit in the child nodes. What's the
use you had in mind?
Rob
--
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 1/5] dt-bindings: at24: consistently document the compatible property
From: Bartosz Golaszewski @ 2017-12-26 22:21 UTC (permalink / raw)
To: Rob Herring
Cc: Peter Rosin, Javier Martinez Canillas, Andy Shevchenko,
Mark Rutland, David Lechner, Divagar Mohandass, Linux I2C,
devicetree, Linux Kernel
In-Reply-To: <20171226213226.iyw6tbdnhlrhxwdc@rob-hp-laptop>
2017-12-26 22:32 GMT+01:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> On Fri, Dec 22, 2017 at 05:58:29PM +0100, Peter Rosin wrote:
>> On 2017-12-22 00:38, Javier Martinez Canillas wrote:
>> > Hello Peter,
>> >
>> > On Fri, Dec 22, 2017 at 12:07 AM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>> >> On 2017-12-21 21:27, Javier Martinez Canillas wrote:
>> >>> Hello Peter,
>> >>>
>> >>> On Thu, Dec 21, 2017 at 5:20 PM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>> >>>> On 2017-12-21 14:48, Bartosz Golaszewski wrote:
>> >>>>> Current description of the compatible property for at24 is quite vague.
>> >>>>>
>> >>>>> Specify an exact list of accepted compatibles and document the - now
>> >>>>> deprecated - strings which were previously used in device tree files.
>> >>>>
>> >>>> Why is it suddenly deprecated to correctly specify what hardware you
>> >>>> have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.
>> >>>
>> >>> Sorry but I disagree.
>> >>>
>> >>> When you specify a compatible string, you are not specifying a
>> >>> particular hardware but a device programming model.
>> >>
>> >> That's not what it says in https://elinux.org/Device_Tree_Usage
>> >
>> > I think the most up-to-date DT reference is at:
>> >
>> > https://www.devicetree.org/
>> >
>> >> in the "Understanding the compatible Property" section. I quote:
>> >>
>> >> compatible is a list of strings. The first string in the
>> >> list specifies the exact device that the node represents
>> >> in the form "<manufacturer>,<model>". The following strings
>> >> represent other devices that the device is compatible with.
>> >>
>> >> Pretty clearly talks about devices and not programming models. But
>> >> maybe I shouldn't trust that reference? What should I be reading
>> >> instead?
>> >>
>> >
>> > For example the latest spec draft
>> > (https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2-rc1/devicetree-specification-v0.2-rc1.pdf)
>> > says:
>> >
>> > "The compatible property value consists of one or more strings that
>> > define the specific programming model for the device. This list of
>> > strings should be used by a client program for device driver
>> > selection. The property value consists of a concatenated list of null
>> > terminated strings, from most specific to most general. They allow a
>> > device to express its compatibility with a family of similar devices,
>> > potentially allowing a single device driver to match against several
>> > devices."
>> >
>> > The recommended format is "manufacturer,model", where manufacturer is
>> > a string describing the name of the manufacturer (such as a stock
>> > ticker symbol), and model specifies the model number."
>> >
>> > Example:
>> >
>> > compatible = "fsl,mpc8641", "ns16550";
>> >
>> > In this example, an operating system would first try to locate a
>> > device driver that supported fsl,mpc8641. If a driver was not found,
>> > it would then try to locate a driver that supported the more general
>> > ns16550 device type."
>>
>> Yes, that's a bit different from the wording on the elinux site. Thanks
>> for the pointer! Google was not my friend on this occasion, since I
>> managed to miss that site in my searches. Maybe it has gotten a higher
>> rank now that 0.2 is out, because now I find it easily?
>
> The wording may be different, but both (and Peter) are correct.
>
> And ns16550 is a perfect example of why that string alone is not
> sufficient. Just go count the number of variants and quirks in the
> kernel 8250 driver.
>
>> >>> It's very common to use a compatible string that doesn't match exactly
>> >>> the specific hardware used. That's why it's called _compatible_ BTW.
>> >>
>> >> That's not how I read the above.
>> >>
>> >
>> > That's not how I read it nor my experience with DT, but of course I
>> > may be wrong on this.
>>
>> Either way, it should not be wrong to specify the more specific binding
>> before the generic fallback, as is done in the at91-tse850-3.dts
>> example I gave below.
>
> Indeed. I don't think I've ever said anyone is being too specific.
>
>> >>> For example when a DTS define a UART node with an ns16550 compatible,
>> >>> they don't really mean that have a UART IC manufactured by National
>> >>> Semiconductor.
>> >>
>> >> That just tells me that most people are a little bit lazy and ready
>> >> to cut a corner or two when they can get away with it. Or that there
>> >> is some form of misunderstanding at work...
>> >>
>> >
>> > For example, I usually see that different SoC families from the same
>> > vendor use the same compatible string for integrated peripherals just
>> > because are the same from a programming model point of view.
>> >
>> > TI am33xx SoCs use a lot of omap3 compatible strings on their nodes
>> > and its similar on Exynos SoCs which are the two ARM SoCs I'm most
>> > familiar with. Following your logic that's wrong and instead a new
>> > compatible string should be added for the GPIO or pinctrl drivers even
>> > when are the same because refer to different devices.
>>
>> Considering the above quote from the actual DT spec, I wouldn't say wrong.
>> But I'd still say that it should be preferred to list the actual device
>> before the fallback to some generic programming model compatible or some
>> previous version of the hardware/IP-block. Just in case an unintended
>> difference is discovered late in the game...
>
> Let me clear, "generic" compatibles alone are wrong.
>
>>
>> >>>> Sure, it happens to be compatible with "atmel,24c32", but that is
>> >>>> supposed to be written with a fallback as
>> >>>>
>> >>>> "nxp,24c32", "atmel,24c32"
>> >>>
>> >>> This isn't a requirement really, systems integrators are free to use
>> >>> more than one <manufacturer,model> tuple in the compatible string if
>> >>> they want the DTB to be future proof, just in case there's a need for
>> >>> a more specific driver or if the programming model happened to not be
>> >>> the same at the end. This is usually done for the boards compatible
>> >>> string as an example, even when there isn't a struct machine_desc for
>> >>> the specific board compatible and only for the SoC family.
>> >>>
>> >>> So it's OK if you want to define the compatible as "nxp,24c32",
>> >>> "atmel,24c32", but that's a general OF concept and not something
>> >>> related to the at24 eeprom driver so I'm not sure if it should be
>> >>> mentioned in the at24 DT binding doc.
>> >>
>> >> One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example
>> >> below) is not a valid compatible, the tooling will be correct to
>> >> complain about it. Currently, it is just a checkpatch deficiency that
>> >> it complains like this:
>> >>
>> >> $ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
>> >> WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
>> >> #249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
>> >> + compatible = "nxp,24c02", "atmel,24c02";
>> >>
>> >
>> > But isn't that a bug in checkpatch? as long as there's a valid
>> > <manufacturer,model> tuple in the compatible string, it shouldn't
>> > complain.
>>
>> Then there is a significant risk that speeling mistakes are not
>> caught. So, I don't think it will be considered a bug unless a DT
>> guru says so of course. I think the checkpatch intention is to catch
>> all undocumented compatibles. But I don't know of course...
>
> checkpatch.pl is just plain stupid. Who wrote that check anyway? Because
> bindings are not machine parseable, compatible string checks are pretty
> much just a grep for the string in all binding docs. So "The" or
> "compatible" would be valid compatible strings for checkpatch.pl.
>
> If you want to quiet checkpatch.pl, I'd suggest documenting compatible
> strings as "<vendor>,foo" and having checkpatch match any string for
> <vendor>. We already handle vendor,<soc>-block type compatible
> descriptions.
>
> Rob
Hi Rob,
more than shutting up checkpatch, I care about cleaning up the device
tree support in at24 and extending it with other variants that are
currently supported as i2c devices.
While just listing the supported models with any vendor allowed would
be fine in most cases, there are also examples like
"renesas,r1ex24002" which is really just "atmel,24c02" but with a
different model name. So should we say in the document that 'any
"<manufacturer>,<model>" pair is allowed as long as the fallback is
one of "atmel,<model>" strings'?
Best regards,
Bartosz Golaszewski
--
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] dt: psci: Update DT bindings to support hierarchical PSCI states
From: Rob Herring @ 2017-12-26 22:13 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Sudeep Holla,
Lorenzo Pieralisi, Brendan Jackman, Lina Iyer, Kevin Hilman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513953127-3321-1-git-send-email-ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Fri, Dec 22, 2017 at 03:32:07PM +0100, Ulf Hansson wrote:
> From: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Update DT bindings to represent hierarchical CPU and CPU domain idle states
> for PSCI. Also update the PSCI examples to clearly show how flattened and
> hierarchical idle states can be represented in DT.
>
> Signed-off-by: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> For your information, I have picked up the work from Lina Iyer around the so
> called CPU cluster idling series [1,2] and I working on new versions. However,
> I decided to post the updates to the PSCI DT bindings first, as they will be
> needed to be agreed upon before further changes can be done to the PSCI firmware
> driver.
>
> Note, these bindings have been discussed over and over again, at LKML, but
> especially also at various Linux conferences, like LPC and Linaro Connect. We
> finally came to a conclusion and the changes we agreed upon, should be reflected
> in this update.
>
> Of course, it's a while ago since the latest discussions, but hopefully people
> don't have too hard time to remember.
Vaguely...
>
> Kind regards
> Uffe
>
> [1]
> https://www.spinics.net/lists/arm-kernel/msg566200.html
>
> [2]
> https://lwn.net/Articles/716300/
>
> ---
> Documentation/devicetree/bindings/arm/psci.txt | 152 +++++++++++++++++++++++++
> 1 file changed, 152 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> index a2c4f1d..5a8f11b 100644
> --- a/Documentation/devicetree/bindings/arm/psci.txt
> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> @@ -105,7 +105,159 @@ Case 3: PSCI v0.2 and PSCI v0.1.
> ...
> };
>
> +PSCI v1.0 onwards, supports OS-Initiated mode for powering off CPUs and CPU
> +clusters from the firmware. For such topologies the PSCI firmware driver acts
> +as pseudo-controller, which may be specified in the psci DT node. The
> +definitions of the CPU and the CPU cluster topology, must conform to the domain
> +idle state specification [3]. The domain idle states themselves, must be
> +compatible with the defined 'domain-idle-state' binding [1], and also need to
> +specify the arm,psci-suspend-param property for each idle state.
> +
> +DT allows representing CPU and CPU cluster idle states in two different ways -
> +
> +The flattened model as given in Example 1, lists CPU's idle states followed by
> +the domain idle state that the CPUs may choose. This is the general practice
> +followed in PSCI firmwares that support Platform Coordinated mode. Note that
> +the idle states are all compatible with "arm,idle-state".
> +
> +Example 2 represents the hierarchical model of CPU and domain idle states.
> +CPUs define their domain provider in their DT node. The domain controls the
> +power to the CPU and possibly other h/w blocks that would be powered off when
> +the CPU is powered off. The CPU's idle states may therefore be considered as
> +the domain's idle states and have the compatible "arm,idle-state". Such domains
> +may be embedded within another domain that represents common h/w blocks between
> +these CPUs viz. the cluster. The idle states of the cluster would be
> +represented as the domain's idle states. In order to use OS-Initiated mode of
> +PSCI in the firmware, the hierarchical representation must be used.
> +
> +Example 1: Flattened representation of CPU and domain idle states
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + CPU0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
> + <&CLUSTER_PWR_DWN>;
> + };
> +
> + CPU1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + reg = <0x100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
> + <&CLUSTER_PWR_DWN>;
> + };
> +
> + idle-states {
> + CPU_PWRDN: cpu_power_down{
Use '-' rather than '_'. dtc has more warnings since last time...
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x000001>;
> + entry-latency-us = <10>;
> + exit-latency-us = <10>;
> + min-residency-us = <100>;
> + };
> +
> + CLUSTER_RET: domain_ret {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x1000010>;
> + entry-latency-us = <500>;
> + exit-latency-us = <500>;
> + min-residency-us = <2000>;
> + };
> +
> + CLUSTER_PWR_DWN: domain_off {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x1000030>;
> + entry-latency-us = <2000>;
> + exit-latency-us = <2000>;
> + min-residency-us = <6000>;
> + };
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> +Example 2: Hierarchical representation of CPU and domain idle states
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + CPU0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0>;
> + enable-method = "psci";
> + power-domains = <&CPU_PD0>;
> + };
> +
> + CPU1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + reg = <0x100>;
> + enable-method = "psci";
> + power-domains = <&CPU_PD1>;
> + };
> +
> + idle-states {
> + CPU_PWRDN: cpu_power_down{
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x000001>;
> + entry-latency-us = <10>;
> + exit-latency-us = <10>;
> + min-residency-us = <100>;
> + };
> +
> + CLUSTER_RET: domain_ret {
> + compatible = "domain-idle-state";
> + arm,psci-suspend-param = <0x1000010>;
> + entry-latency-us = <500>;
> + exit-latency-us = <500>;
> + min-residency-us = <2000>;
> + };
> +
> + CLUSTER_PWR_DWN: domain_off {
> + compatible = "domain-idle-state";
> + arm,psci-suspend-param = <0x1000030>;
> + entry-latency-us = <2000>;
> + exit-latency-us = <2000>;
> + min-residency-us = <6000>;
> + };
> + };
> + };
> +
> + psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> +
> + CPU_PD0: cpu-pd@0 {
A unit address without reg property is now a warning.
> + #power-domain-cells = <0>;
> + domain-idle-states = <&CPU_PWRDN>;
> + power-domains = <&CLUSTER_PD>;
> + };
> +
> + CPU_PD1: cpu-pd@1 {
> + #power-domain-cells = <0>;
> + domain-idle-states = <&CPU_PWRDN>;
> + power-domains = <&CLUSTER_PD>;
Could this node be a child of CLUSTER_PD rather than having a phandle?
Doesn't matter so much here, but when you have 3 levels?
> + };
These 2 nodes are identical, so why do you need both?
> +
> + CLUSTER_PD: cluster-pd@0 {
> + #power-domain-cells = <0>;
> + domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
> + };
> + };
> +
> [1] Kernel documentation - ARM idle states bindings
> Documentation/devicetree/bindings/arm/idle-states.txt
> [2] Power State Coordination Interface (PSCI) specification
> http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
> +[3]. PM Domains description
> + Documentation/devicetree/bindings/power/power_domain.txt
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] power: reset: remove unused imx-snvs-poweroff driver
From: Rob Herring @ 2017-12-26 21:57 UTC (permalink / raw)
To: Dong Aisheng
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, sre-DgEjT+Ai2ygdnm+yROfE0A,
dongas86-Re5JQEeQqe8AvxtiuMwx3w, yibin.gong-3arQi8VN3Tc,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513938539-20873-1-git-send-email-aisheng.dong-3arQi8VN3Tc@public.gmane.org>
On Fri, Dec 22, 2017 at 06:28:59PM +0800, Dong Aisheng wrote:
> There's no user of it in kernel now and it basically functions the same
> as the generic syscon-poweroff.c to which we have already switched.
> So let's remove it.
>
> Cc: Robin Gong <yibin.gong-3arQi8VN3Tc@public.gmane.org>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Dong Aisheng <aisheng.dong-3arQi8VN3Tc@public.gmane.org>
> ---
> .../bindings/power/reset/imx-snvs-poweroff.txt | 23 --------
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/power/reset/Kconfig | 9 ---
> drivers/power/reset/Makefile | 1 -
> drivers/power/reset/imx-snvs-poweroff.c | 66 ----------------------
> 4 files changed, 99 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt
> delete mode 100644 drivers/power/reset/imx-snvs-poweroff.c
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Rob Herring @ 2017-12-26 21:55 UTC (permalink / raw)
To: Yong Deng
Cc: Maxime Ripard, Mauro Carvalho Chehab, Mark Rutland, Chen-Yu Tsai,
David S. Miller, Greg Kroah-Hartman, Randy Dunlap, Hans Verkuil,
Stanimir Varbanov, Hugues Fruchet, Yannick Fertre, Philipp Zabel,
Arnd Bergmann, Benjamin Gaignard, Ramesh Shanmugasundaram,
Sakari Ailus, Rick Chang, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sunxi
In-Reply-To: <1513935689-35415-1-git-send-email-yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
On Fri, Dec 22, 2017 at 05:41:29PM +0800, Yong Deng wrote:
> Add binding documentation for Allwinner V3s CSI.
>
> Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/media/sun6i-csi.txt | 51 ++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> new file mode 100644
> index 0000000..b5bfe3f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> @@ -0,0 +1,51 @@
> +Allwinner V3s Camera Sensor Interface
> +------------------------------
> +
> +Required properties:
> + - compatible: value must be "allwinner,sun8i-v3s-csi"
> + - reg: base address and size of the memory-mapped region.
> + - interrupts: interrupt associated to this IP
> + - clocks: phandles to the clocks feeding the CSI
> + * bus: the CSI interface clock
> + * mod: the CSI module clock
> + * ram: the CSI DRAM clock
> + - clock-names: the clock names mentioned above
> + - resets: phandles to the reset line driving the CSI
> +
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + Currently, the driver only support the parallel interface. So, a single port
> + node with one endpoint and parallel bus is supported.
What the driver supports is not relevant. Please document what the h/w
has.
> +
> +Example:
> +
> + csi1: csi@1cb4000 {
> + compatible = "allwinner,sun8i-v3s-csi";
> + reg = <0x01cb4000 0x1000>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_CSI>,
> + <&ccu CLK_CSI1_SCLK>,
> + <&ccu CLK_DRAM_CSI>;
> + clock-names = "bus", "mod", "ram";
> + resets = <&ccu RST_BUS_CSI>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
These are not needed with a single endpoint.
> +
> + /* Parallel bus endpoint */
> + csi1_ep: endpoint {
> + remote-endpoint = <&adv7611_ep>;
> + bus-width = <16>;
> + data-shift = <0>;
> +
> + /* If hsync-active/vsync-active are missing,
> + embedded BT.656 sync is used */
> + hsync-active = <0>; /* Active low */
> + vsync-active = <0>; /* Active low */
> + data-active = <1>; /* Active high */
> + pclk-sample = <1>; /* Rising */
> + };
> + };
> + };
> +
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Rob Herring @ 2017-12-26 21:53 UTC (permalink / raw)
To: Priit Laes
Cc: Yong Deng, Maxime Ripard, Mauro Carvalho Chehab, Mark Rutland,
Chen-Yu Tsai, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
Hans Verkuil, Stanimir Varbanov, Hugues Fruchet, Yannick Fertre,
Philipp Zabel, Arnd Bergmann, Benjamin Gaignard,
Ramesh Shanmugasundaram, Sakari Ailus, Rick Chang,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel
In-Reply-To: <20171222100008.nmmzwhtmputizn7d-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
On Fri, Dec 22, 2017 at 10:00:08AM +0000, Priit Laes wrote:
> On Fri, Dec 22, 2017 at 05:41:29PM +0800, Yong Deng wrote:
> > Add binding documentation for Allwinner V3s CSI.
> >
> > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> > ---
> > .../devicetree/bindings/media/sun6i-csi.txt | 51 ++++++++++++++++++++++
> > 1 file changed, 51 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > new file mode 100644
> > index 0000000..b5bfe3f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > @@ -0,0 +1,51 @@
> > +Allwinner V3s Camera Sensor Interface
> > +------------------------------
>
> Not sure whether syntax for these files is proper reStructuredText/Markdown,
> but the underline-ish style expects the title and underline having same length.
The binding files are not rst/md format, but still the comment is just
good style.
Rob
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: add jianda vendor prefix
From: Rob Herring @ 2017-12-26 21:52 UTC (permalink / raw)
To: David Lechner
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, Noralf Trønnes,
limor-6aDhHjTmHzzR7s880joybQ, Linus Walleij, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513884233-31540-2-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Thu, Dec 21, 2017 at 01:23:51PM -0600, David Lechner wrote:
> This adds a vendor prefix "jianda" for Jiandangjing Technology Co., Ltd.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
>
> v3 changes:
> * new patch in v3
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 41cb1ff0..fea7903 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -172,6 +172,7 @@ issi Integrated Silicon Solutions Inc.
> itead ITEAD Intelligent Systems Co.Ltd
> iwave iWave Systems Technologies Pvt. Ltd.
> jdi Japan Display Inc.
> +jianda Jiandangjing Technology Co., Ltd.
> jedec JEDEC Solid State Technology Association
Err, not alphabetical order.
With that fixed,
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> karo Ka-Ro electronics GmbH
> keithkoep Keith & Koep GmbH
> --
> 2.7.4
>
--
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 2/3] dt-bindings: update compatible string for ILI9225
From: Rob Herring @ 2017-12-26 21:50 UTC (permalink / raw)
To: David Lechner; +Cc: Mark Rutland, devicetree, limor, linux-kernel, dri-devel
In-Reply-To: <1513881187-3197-3-git-send-email-david@lechnology.com>
On Thu, Dec 21, 2017 at 12:33:06PM -0600, David Lechner wrote:
> This updates the compatible string for a no-name LCD panel to
> "vot,v220hf01a-t", "ilitek,ili9225".
>
> The original bindings [1] were the generic "ilitek,ili9225-2.2in-176x220"
> because I could not find a datasheet. However, after some more research,
> I finally found one, so the actual vendor and model name are now known.
>
> This previous bindings have not made it to the mainline kernel yet, so
> this is not breaking backwards compatibility.
>
> This is also following the precedence of the ILI9322 bindings [2] by using
> the pattern "vendor,specific-system-config", "vendor,ip-part";
>
> [1]: https://patchwork.ozlabs.org/patch/839352/
> [2]: https://patchwork.ozlabs.org/patch/843576/
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> Documentation/devicetree/bindings/display/ilitek,ili9225.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-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 1/3] dt-bindings: Add "vot" vendor prefix
From: Rob Herring @ 2017-12-26 21:49 UTC (permalink / raw)
To: David Lechner
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, Noralf Trønnes,
limor-6aDhHjTmHzzR7s880joybQ, Linus Walleij, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513881187-3197-2-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Thu, Dec 21, 2017 at 12:33:05PM -0600, David Lechner wrote:
> This adds a vendor prefix "vot" for Vision Optical Technology Co., Ltd.
> They make LCD displays.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox