* Re: [PATCH v5 13/14] ASoC: add simple-graph-scu-card document
From: Rob Herring @ 2016-12-05 22:40 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Brown, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <871sxwwcas.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Mon, Nov 28, 2016 at 02:48:37AM +0000, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> .../bindings/sound/simple-graph-scu-card.txt | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt b/Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt
> new file mode 100644
> index 0000000..b0e46ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt
> @@ -0,0 +1,69 @@
> +Simple-Graph-SCU-Card:
> +
> +Simple-Graph-SCU-Card specifies audio DAI connections of SoC <-> codec.
> +It is based on common bindings for device graphs.
> +see ${LINUX}/Documentation/devicetree/bindings/graph.txt
> +
> +Basically, Simple-Graph-SCU-Card property is same as Simple-Card / Simple-Graph-Card.
> +see ${LINUX}/Documentation/devicetree/bindings/sound/simple-card.txt
> + ${LINUX}/Documentation/devicetree/bindings/sound/simple-graph-card.txt
> +
> +Main difference between Simple-Graph-Card and Simple-Graph-SCU-Card is that
> +Simple-Graph-SCU-Card can use multi CPU.
So it can have more that 1 port? At least for the bindings, I think you
should combine these 2 bindings. Whether the driver should be combined
is separate question. I imagine you have 2 compatible strings because
you have 2 drivers, but that isn't really a reason to have 2.
I still have no idea what SCU is.
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 v5 11/14] ASoC: add simple-graph-card document
From: Rob Herring @ 2016-12-05 22:58 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Brown, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87lgvvw92p.wl%kuninori.morimoto.gx@renesas.com>
On Sun, Dec 04, 2016 at 11:48:49PM +0000, Kuninori Morimoto wrote:
>
> Hi Rob, Mark
>
> > > +++ b/Documentation/devicetree/bindings/sound/simple-graph-card.txt
> > > @@ -0,0 +1,67 @@
> > > +Simple-Graph-Card:
> >
> > There's nothing simple about this. graph-audio-card or audio-card-graph.
>
> I have no objection about naming, but this is one of simple-xxx-card series.
> And, this is very simple from ALSA SoC point of view...
>
> > > +rcar_sound {
> > > + ...
> > > + port {
> > > + compatible = "asoc-simple-graph-card";
> >
> > Do you have an example where you'd have multiple ports? If not, this
> > should go up a level.
>
> ALSA SoC needs 3 type of driver, CPU/Codec/Card. But HW is SoC <-> Codec.
> Thus, "CPU" side DT needs to call "Card" portion, and ALSA SoC needs to
> select Card type (graph-audio-card, graph-scu-card, etc, etc....).
> Above it for it.
>
> SoC {
> compatible = "cpu_driver_compatible_name";
> ...
> port {
> compatible = "card_driver_compatible_name";
> ...
> };
> };
>
> Here, SoC driver "cpu_driver_compatible_name" will handle CPU and its
> each port settings. And it will probes "card_driver_compatible_name".
> "card_driver_compatible_name" will connect CPU <-> Codec via ALSA SoC.
Don't design bindings around what ASoC wants and don't explain it in
terms of how ALSA works. Design bindings in a way that reflects the h/w.
This explanation seems completely wrong to me. It seems like you are
abusing OF graph to just create 2 instances of a simple-card which would
be working around some ASoC limitation.
I'd expect the top level node to be the card node that knows how to find
all the components. The graph should reflect the data flow. For example,
the data goes to audio DSP to I2S host to codec to amp.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] Add DT bindings documentation for Synopsys UDC driver
From: Rob Herring @ 2016-12-05 23:04 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480485910-7797-2-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Nov 30, 2016 at 11:35:09AM +0530, Raviteja Garimella wrote:
> This patch adds documentation for Synopsis Designware Cores AHB
> Subsystem Device Controller (UDC).
>
> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> new file mode 100644
> index 0000000..64e1fbf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> @@ -0,0 +1,29 @@
> +Synopsys USB Device controller.
> +
> +The device node is used for Synopsys Designware Cores AHB
> +Subsystem Device Controller (UDC).
> +
> +Required properties:
> + - compatible: should be "snps,dw-ahbudc"
Needs an SoC specific compatible string.
> + - reg: Offset and length of UDC register set
> + - interrupts: description of interrupt line
> + - phys: phandle to phy node.
> + - phy-names: name of phy node. Must be usb2drd.
A name is pointless when there's only 1 phy. Is this a device or dual
role device(DRD)?
> + - extcon: phandle to the extcon device
I don't think extcon should be required. If this is UDC only, I'm not
sure why you'd need it.
> +
> +Example:
> +
> + usbdrd_phy: phy@6501c000 {
> + #phy-cells = <0>;
> + compatible = "brcm,ns2-drd-phy";
> + reg = <0x66000000 0x1000>,
> + }
> +
> + udc_dwc: usb@664e0000 {
> + compatible = "snps,dw-ahb-udc";
Doesn't match above.
> + reg = <0x664e0000 0x2000>;
> + interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>;
> + phys = <&usbdrd_phy>;
> + phy-names = "usb2drd";
> + extcon = <&usbdrd_phy>";
You are already describing the phy connection, you shouldn't need both.
> + };
> --
> 2.1.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 1/3] Add DT bindings documentation for NS2 USB DRD phy
From: Rob Herring @ 2016-12-05 23:09 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Mark Rutland, Kishon Vijay Abraham I, Ray Jui, Scott Branden,
Jon Mason, Catalin Marinas, Will Deacon,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480485338-23451-2-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Nov 30, 2016 at 11:25:36AM +0530, Raviteja Garimella wrote:
> This patch adds documentation for NS2 DRD Phy driver DT bindings
>
> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 40 ++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
> new file mode 100644
> index 0000000..5857f99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
> @@ -0,0 +1,40 @@
> +BROADCOM NORTHSTAR2 USB2 (DUAL ROLE DEVICE) PHY
> +
> +Required properties:
> + - compatible: brcm,ns2-drd-phy
> + - reg: offset and length of the NS2 PHY related registers.
> + - reg-names
> + The below registers must be provided.
> + icfg - for DRD ICFG configurations
> + rst-ctrl - for DRD IDM reset
> + crmu-ctrl - for CRMU core vdd, PHY and PHY PLL reset
> + usb2-strap - for port over current polarity reversal
> + - #phy-cells: Must be 0. No args required.
> + - vbus-gpios: vbus gpio binding
> + - id-gpios: id gpio binding
> +
> +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> +
> +Example:
> + gpio_g: gpio@660a0000 {
You don't really need to show gpio node for the example. Otherwise,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
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
* [PATCH 0/2] arm64: dts: NS2: XMC support and Nitro memreserve
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel
Add support for the NS2 XMC formfactor via a new DTS file. Also, set
aside memory for Nitro firmware in the NS2 DTSI file.
Jon Mason (2):
arm64: dts: NS2: reserve memory for Nitro firmware
arm64: dts: NS2: add support for XMC form factor
arch/arm64/boot/dts/broadcom/Makefile | 2 +-
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 191 +++++++++++++++++++++++++++++++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 +
3 files changed, 194 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/broadcom/ns2-xmc.dts
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] arm64: dts: NS2: reserve memory for Nitro firmware
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel
In-Reply-To: <1480979542-26871-1-git-send-email-jon.mason@broadcom.com>
Nitro firmware is loaded into memory by the bootloader at a specific
location. Set this memory range aside to prevent the kernel from using
it.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 96ed47b..9f9e203 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -30,6 +30,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+/memreserve/ 0x81000000 0x00200000;
+
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/bcm-ns2.h>
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: NS2: add support for XMC form factor
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel
In-Reply-To: <1480979542-26871-1-git-send-email-jon.mason@broadcom.com>
The BCM958712DxXMC board is a smaller form factor typically used as
controller boards for switches. This smaller board has less devices
pinned out, so only a few need be populated in the device tree.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/Makefile | 2 +-
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 191 +++++++++++++++++++++++++++++++
2 files changed, 192 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/broadcom/ns2-xmc.dts
diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
index 05faf2a..f1caece 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,5 +1,5 @@
dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
-dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb
+dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
dtb-$(CONFIG_ARCH_VULCAN) += vulcan-eval.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-xmc.dts b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
new file mode 100644
index 0000000..99a2723
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
@@ -0,0 +1,191 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Broadcom. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Broadcom Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "ns2.dtsi"
+
+/ {
+ model = "Broadcom NS2 XMC";
+ compatible = "brcm,ns2-xmc", "brcm,ns2";
+
+ aliases {
+ serial0 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "earlycon=uart8250,mmio32,0x66130000";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x000000000 0x80000000 0x00000001 0x00000000>;
+ };
+};
+
+&enet {
+ status = "ok";
+};
+
+&i2c0 {
+ status = "ok";
+};
+
+&i2c1 {
+ status = "ok";
+};
+
+&mdio_mux_iproc {
+ mdio@10 {
+ gphy0: eth-phy@10 {
+ reg = <0x10>;
+ };
+ };
+};
+
+&nand {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-bus-width = <16>;
+ brcm,nand-oob-sector-size = <16>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "nboot";
+ reg = <0x00000000 0x00280000>; /* 2.5MB */
+ read-only;
+ };
+
+ partition@280000 {
+ label = "nenv";
+ reg = <0x00280000 0x00040000>; /* 0.25MB */
+ read-only;
+ };
+
+ partition@2c0000 {
+ label = "ndtb";
+ reg = <0x002c0000 0x00040000>; /* 0.25MB */
+ read-only;
+ };
+
+ partition@300000 {
+ label = "nsystem";
+ reg = <0x00300000 0x03d00000>; /* 61MB */
+ read-only;
+ };
+
+ partition@4000000 {
+ label = "nrootfs";
+ reg = <0x04000000 0x06400000>; /* 100MB */
+ };
+
+ partition@0a400000{
+ label = "ncustfs";
+ reg = <0x0a400000 0x35c00000>; /* 860MB */
+ };
+ };
+};
+
+&pci_phy0 {
+ status = "ok";
+};
+
+&pcie0 {
+ status = "ok";
+};
+
+&pcie8 {
+ status = "ok";
+};
+
+&sata_phy0 {
+ status = "ok";
+};
+
+&sata_phy1 {
+ status = "ok";
+};
+
+&sata {
+ status = "ok";
+};
+
+&qspi {
+ flash: m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p80";
+ spi-max-frequency = <62500000>;
+ m25p,default-addr-width = <3>;
+ reg = <0x0 0x0>;
+
+ partition@0 {
+ label = "bl0";
+ reg = <0x00000000 0x00080000>; /* 512KB */
+ };
+
+ partition@80000 {
+ label = "fip";
+ reg = <0x00080000 0x00150000>; /* 1344KB */
+ };
+
+ partition@1e0000 {
+ label = "env";
+ reg = <0x001e0000 0x00010000>;/* 64KB */
+ };
+
+ partition@1f0000 {
+ label = "dtb";
+ reg = <0x001f0000 0x00010000>; /* 64KB */
+ };
+
+ partition@200000 {
+ label = "kernel";
+ reg = <0x00200000 0x00e00000>; /* 14MB */
+ };
+
+ partition@1000000 {
+ label = "rootfs";
+ reg = <0x01000000 0x01000000>; /* 16MB */
+ };
+ };
+};
+
+&uart3 {
+ status = "ok";
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings
From: Rob Herring @ 2016-12-05 23:26 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Wolfram Sang, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, Arnd Bergmann, Greg Kroah-Hartman, linux-i2c,
devicetree, linux-iio, linux-doc
In-Reply-To: <1480493823-21462-5-git-send-email-peda@axentia.se>
On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> .../bindings/iio/multiplexer/iio-mux.txt | 40 ++++++++++++++++++++++
> MAINTAINERS | 6 ++++
> 2 files changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
I'm still not convinced about this binding, but don't really have more
comments ATM. Sending 6 versions in 2 weeks or so doesn't really help
either.
> diff --git a/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
> new file mode 100644
> index 000000000000..8080cf790d82
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
> @@ -0,0 +1,40 @@
> +IIO multiplexer bindings
> +
> +If a multiplexer is used to select which hardware signal is fed to
> +e.g. an ADC channel, these bindings describe that situation.
> +
> +Required properties:
> +- compatible : "iio-mux"
This is a Linuxism. perhaps "adc-mux".
> +- io-channels : Channel node of the parent channel that has multiplexed
> + input.
> +- io-channel-names : Should be "parent".
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +- mux-controls : Mux controller node to use for operating the mux
> +- channels : List of strings, labeling the mux controller states.
> +
> +The multiplexer state as described in ../misc/mux-controller.txt
> +
> +For each non-empty string in the channels property, an iio channel will
> +be created. The number of this iio channel is the same as the index into
> +the list of strings in the channels property, and also matches the mux
> +controller state.
> +
> +Example:
> + mux: mux-controller {
> + compatible = "mux-gpio";
> + #mux-control-cells = <0>;
> +
> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
> + <&pioA 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + adc-mux {
> + compatible = "iio-mux";
> + io-channels = <&adc 0>;
> + io-channel-names = "parent";
> +
> + mux-controls = <&mux>;
> +
> + channels = "sync", "in", system-regulator";
> + };
^ permalink raw reply
* Re: [PATCH v2 3/5] dt-bindings: spi: Add documentation for the Armada 3700 SPI Controller
From: Rob Herring @ 2016-12-05 23:27 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20161130094351.2748-4-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, Nov 30, 2016 at 10:43:49AM +0100, Romain Perier wrote:
> This adds the devicetree bindings documentation for the SPI controller
> present in the Marvell Armada 3700 SoCs.
>
> Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/spi/spi-armada-3700.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-armada-3700.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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] Documentation: dt: iio: add st_lsm6dsx sensor device binding
From: Rob Herring @ 2016-12-05 23:30 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, lorenzo.bianconi-qxv4g6HH51o
In-Reply-To: <20161130200559.29910-3-lorenzo.bianconi-qxv4g6HH51o@public.gmane.org>
On Wed, Nov 30, 2016 at 09:05:59PM +0100, Lorenzo Bianconi wrote:
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/iio/imu/st_lsm6dsx.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Rob Herring @ 2016-12-05 23:40 UTC (permalink / raw)
To: Philipp Zabel
Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
zhangfei, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480687813.2460.19.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Dec 02, 2016 at 03:10:13PM +0100, Philipp Zabel wrote:
> Am Freitag, den 02.12.2016, 13:32 +0100 schrieb Arnd Bergmann:
> > On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> > > Hi, Arnd
> > >
> > > On 2016年12月01日 20:05, Arnd Bergmann wrote:
> > > > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> > > >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> > > >> + 0x20 0x10 /* 1: i2c1 */
> > > >> + 0x20 0x20 /* 2: i2c2 */
> > > >> + 0x20 0x8000000>; /* 3: i2c6 */
> > > >> + };
> > > >> +
> > > >> +Specifying reset lines connected to IP modules
> > > >> +==============================================
> > > >> +example:
> > > >> +
> > > >> + i2c0: i2c@..... {
> > > >> + ...
> > > >> + resets = <&iomcu_rst 0>;
> > > >> + ...
> > > >> + };
> > > > I don't really like this approach, since now the information is
> > > > in two places. Why not put the data into the reset specifier
> > > > directly when it is used?
>
> From my point of view, with the binding above, all reset controller
> register/bit layout information is in a single place and can be easily
> compared to a list in the reference manual, whereas with your suggestion
> the description of the reset controller register layout is spread
> throughout one or even several dtsi files.
Which can be solved by tools.
> Also, since no two reset controllers are exactly the same, we get a
> proliferation of different slightly phandle argument meanings.
phandle args are supposed to be specific to the phandle it points to.
Otherwise, we'd never need more than 1 cell and everything could be a
lookup table.
>
> > > Any example, still not understand.
> > > They are consumer and provider.
> >
> > I mean in the i2c node, have
> >
> > i2c0: i2c@..... {
> > ...
> > resets = <&iomcu_rst 0x20 0x8>;
> > ...
> > }
>
> There already are a few drivers that use this, and I fear people having
> to change their bindings because new flags are needed that have not been
> previously thought of.
>
Drivers that use what?
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/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Rob Herring @ 2016-12-05 23:42 UTC (permalink / raw)
To: Brian Norris
Cc: Jiri Kosina, Benjamin Tissoires, Caesar Wang,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov,
Mark Rutland, Doug Anderson
In-Reply-To: <1480555288-142791-1-git-send-email-briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
On Wed, Nov 30, 2016 at 05:21:27PM -0800, Brian Norris wrote:
> From: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Add a compatible string and regulator property for Wacom W9103
> digitizer. Its VDD supply may need to be enabled before using it.
>
> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> v1 was a few months back. I finally got around to rewriting it based on
> DT binding feedback.
>
> v2:
> * add compatible property for wacom
> * name the regulator property specifically (VDD)
>
> Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
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 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Brian Norris @ 2016-12-05 23:54 UTC (permalink / raw)
To: Rob Herring
Cc: Jiri Kosina, Benjamin Tissoires, Caesar Wang,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov,
Mark Rutland, Doug Anderson
In-Reply-To: <20161205234248.tqnpruk442n4lgs5@rob-hp-laptop>
Hi Rob,
On Mon, Dec 05, 2016 at 05:42:48PM -0600, Rob Herring wrote:
> On Wed, Nov 30, 2016 at 05:21:27PM -0800, Brian Norris wrote:
> > From: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >
> > Add a compatible string and regulator property for Wacom W9103
> > digitizer. Its VDD supply may need to be enabled before using it.
> >
> > Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > ---
> > v1 was a few months back. I finally got around to rewriting it based on
> > DT binding feedback.
> >
> > v2:
> > * add compatible property for wacom
> > * name the regulator property specifically (VDD)
> >
> > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks but (unfortunately) there've been 2 new versions since then.
Specifically, Benjamin NACK'ed this patch and requested we NOT include
device/manufacturer-specific compatible properties here. In fact, the
binding is still rather generic and IMO (and in Benjamin's opinion)
doesn't really need to be restricted to a specific device.
Please consider reviewing Benjamin's requests and my recent changes.
Benjamin has one small remaining comment on v4, and I plan to send the
5th (and final?) version once I'm confident you and Benjamin agree :)
Thanks,
Brian
--
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/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Rob Herring @ 2016-12-05 23:59 UTC (permalink / raw)
To: Brian Norris, Benjamin Tissoires
Cc: Jiri Kosina, Caesar Wang, linux-rockchip, linux-input, devicetree,
linux-kernel, Dmitry Torokhov, Mark Rutland, Doug Anderson
In-Reply-To: <20161201172448.GA46688@google.com>
On Thu, Dec 01, 2016 at 09:24:50AM -0800, Brian Norris wrote:
> Hi Benjamin and Rob,
>
> On Thu, Dec 01, 2016 at 03:34:34PM +0100, Benjamin Tissoires wrote:
> > On Nov 30 2016 or thereabouts, Brian Norris wrote:
> > > From: Caesar Wang <wxt@rock-chips.com>
> > >
> > > Add a compatible string and regulator property for Wacom W9103
> > > digitizer. Its VDD supply may need to be enabled before using it.
> > >
> > > Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Cc: Jiri Kosina <jikos@kernel.org>
> > > Cc: linux-input@vger.kernel.org
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > > v1 was a few months back. I finally got around to rewriting it based on
> > > DT binding feedback.
> > >
> > > v2:
> > > * add compatible property for wacom
> > > * name the regulator property specifically (VDD)
> > >
> > > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > index 488edcb264c4..eb98054e60c9 100644
> > > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > @@ -11,12 +11,16 @@ If this binding is used, the kernel module i2c-hid will handle the communication
> > > with the device and the generic hid core layer will handle the protocol.
> > >
> > > Required properties:
> > > -- compatible: must be "hid-over-i2c"
> > > +- compatible: must be "hid-over-i2c", or a device-specific string like:
> > > + * "wacom,w9013"
> >
> > NACK on this one.
> >
> > After re-reading the v1 submission I realized Rob asked for this change,
> > but I strongly disagree.
> >
> > HID over I2C is a generic protocol, in the same way HID over USB is. We
> > can not start adding device specifics here, this is opening the can of
> > worms. If the device is a HID one, nothing else should matter. The rest
> > (description of the device, name, etc...) is all provided by the
> > protocol.
>
> I should have spoken up when Rob made the suggestion, because I more or
> less agree with Benjamin here. I don't really see why this needs to have
> a specialized compatible string, as the property is still fairly
> generic, and the entire device handling is via a generic protocol. The
> fact that we manage its power via a regulator is not very
> device-specific.
It doesn't matter that the protocol is generic. The device attached and
the implementation is not. Implementations have been known to have
bugs/quirks (generally speaking, not HID over I2C in particular). There
are also things outside the scope of what is 'hid-over-i2c' like what's
needed to power-on the device which this patch clearly show.
This is no different than a panel attached via LVDS, eDP, etc., or
USB/PCIe device hard-wired on a board. They all use standard protocols
and all need additional data to describe them. Of course, adding a
single property for a delay would not be a big deal, but it's never
ending. Next you need multiple supplies, GPIO controls, mutiple
delays... This has been discussed to death already. As Thierry Reding
said, you're not special[1].
Now if you want to make 'hid-over-i2c' a fallback to 'wacom,w9013', I'm
fine with that.
Rob
[1] https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Dmitry Torokhov @ 2016-12-06 0:16 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Jiri Kosina, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Doug Anderson,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benjamin Tissoires, linux-input-u79uwXL29TY76Z2rM5mHXA,
Caesar Wang
In-Reply-To: <20161205235908.rmiyd7io4kddple6@rob-hp-laptop>
On Mon, Dec 05, 2016 at 05:59:08PM -0600, Rob Herring wrote:
> On Thu, Dec 01, 2016 at 09:24:50AM -0800, Brian Norris wrote:
> > Hi Benjamin and Rob,
> >
> > On Thu, Dec 01, 2016 at 03:34:34PM +0100, Benjamin Tissoires wrote:
> > > On Nov 30 2016 or thereabouts, Brian Norris wrote:
> > > > From: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > > >
> > > > Add a compatible string and regulator property for Wacom W9103
> > > > digitizer. Its VDD supply may need to be enabled before using it.
> > > >
> > > > Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > > > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > > Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > > > ---
> > > > v1 was a few months back. I finally got around to rewriting it based on
> > > > DT binding feedback.
> > > >
> > > > v2:
> > > > * add compatible property for wacom
> > > > * name the regulator property specifically (VDD)
> > > >
> > > > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > > index 488edcb264c4..eb98054e60c9 100644
> > > > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > > @@ -11,12 +11,16 @@ If this binding is used, the kernel module i2c-hid will handle the communication
> > > > with the device and the generic hid core layer will handle the protocol.
> > > >
> > > > Required properties:
> > > > -- compatible: must be "hid-over-i2c"
> > > > +- compatible: must be "hid-over-i2c", or a device-specific string like:
> > > > + * "wacom,w9013"
> > >
> > > NACK on this one.
> > >
> > > After re-reading the v1 submission I realized Rob asked for this change,
> > > but I strongly disagree.
> > >
> > > HID over I2C is a generic protocol, in the same way HID over USB is. We
> > > can not start adding device specifics here, this is opening the can of
> > > worms. If the device is a HID one, nothing else should matter. The rest
> > > (description of the device, name, etc...) is all provided by the
> > > protocol.
> >
> > I should have spoken up when Rob made the suggestion, because I more or
> > less agree with Benjamin here. I don't really see why this needs to have
> > a specialized compatible string, as the property is still fairly
> > generic, and the entire device handling is via a generic protocol. The
> > fact that we manage its power via a regulator is not very
> > device-specific.
>
> It doesn't matter that the protocol is generic. The device attached and
> the implementation is not. Implementations have been known to have
> bugs/quirks (generally speaking, not HID over I2C in particular). There
> are also things outside the scope of what is 'hid-over-i2c' like what's
> needed to power-on the device which this patch clearly show.
>
> This is no different than a panel attached via LVDS, eDP, etc., or
> USB/PCIe device hard-wired on a board. They all use standard protocols
> and all need additional data to describe them. Of course, adding a
> single property for a delay would not be a big deal, but it's never
> ending. Next you need multiple supplies, GPIO controls, mutiple
> delays... This has been discussed to death already. As Thierry Reding
> said, you're not special[1].
>
> Now if you want to make 'hid-over-i2c' a fallback to 'wacom,w9013', I'm
> fine with that.
So if I understand it correctly the only change is to have DTS specify
compatible = "wacom,w9013", "hid-over-i2c";
and no actual changes to the driver itself with regard to the new
compatible string, correct?
I wonder what, besides breaking module autoload, this really buys us?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] dt: bindings: zx: Add header for PM domains specifiers
From: Baoyou Xie @ 2016-12-06 0:21 UTC (permalink / raw)
To: jun.nie-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
baoyou.xie-QSEj5FYQhm4dnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
include/dt-bindings/arm/zte_pm_domains.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 include/dt-bindings/arm/zte_pm_domains.h
diff --git a/include/dt-bindings/arm/zte_pm_domains.h b/include/dt-bindings/arm/zte_pm_domains.h
new file mode 100644
index 0000000..1485e8d
--- /dev/null
+++ b/include/dt-bindings/arm/zte_pm_domains.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /*g1v6*/
+#define DM_ZX296718_VCE 2 /*h1v6*/
+#define DM_ZX296718_HDE 3 /*g2v2*/
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H */
--
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 related
* Re: [PATCH v4 2/9] doc: DT: venus: binding document for Qualcomm video driver
From: Rob Herring @ 2016-12-06 0:22 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Mauro Carvalho Chehab, Hans Verkuil, Andy Gross, Bjorn Andersson,
Stephen Boyd, Srinivas Kandagatla, linux-media, linux-kernel,
linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <1480583001-32236-3-git-send-email-stanimir.varbanov@linaro.org>
On Thu, Dec 01, 2016 at 11:03:14AM +0200, Stanimir Varbanov wrote:
> Add binding document for Venus video encoder/decoder driver
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
> Rob, I have removed vmem clocks, interrupts and reg properties
> for vmem thing. Probably I will come with a separate platform
> driver fro that and pass the video memory DT node as phandle.
Looks good, a couple of minor things below.
>
> .../devicetree/bindings/media/qcom,venus.txt | 82 ++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
> new file mode 100644
> index 000000000000..a64b4ea1ebba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
> @@ -0,0 +1,82 @@
> +* Qualcomm Venus video encode/decode accelerator
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Value should contain one of:
> + - "qcom,msm8916-venus"
> + - "qcom,msm8996-venus"
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Register ranges as listed in the reg-names property.
> +- reg-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain following entries:
> + - "base" Venus register base
-names is kind of pointless with only one.
> +- interrupts:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Should contain interrupts as listed in the interrupt-names
> + property.
> +- interrupt-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain following entries:
> + - "venus" Venus interrupt line
ditto
> +- clocks:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A List of phandle and clock specifier pairs as listed
> + in clock-names property.
> +- clock-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "core" Core video accelerator clock
> + - "iface" Video accelerator AHB clock
> + - "bus" Video accelerator AXI clock
> +- clock-names:
> + Usage: required for msm8996
It's not clear if this is in addition to the above list. I'd guess not
and you should make it clear the above applies to the 8916 only.
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "subcore0" Subcore0 video accelerator clock
> + - "subcore1" Subcore1 video accelerator clock
> + - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
> + - "mmss_mmagic_iface" Multimedia subsystem MMAGIC AHB clock
> + - "mmss_mmagic_mbus" Multimedia subsystem MMAGIC MAXI clock
> + - "mmagic_video_bus" MMAGIC video AXI clock
> + - "video_mbus" Video MAXI clock
> +- power-domains:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A phandle and power domain specifier pairs to the
> + power domain which is responsible for collapsing
> + and restoring power to the peripheral.
> +- rproc:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A phandle to remote processor responsible for
> + firmware loading and processor booting.
> +
> +- iommus:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> +* An Example
> + video-codec@1d00000 {
> + compatible = "qcom,msm8916-venus";
> + reg = <0x01d00000 0xff000>;
> + reg-names = "base";
> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "venus";
> + clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
> + <&gcc GCC_VENUS0_AHB_CLK>,
> + <&gcc GCC_VENUS0_AXI_CLK>;
> + clock-names = "core", "iface", "bus";
> + power-domains = <&gcc VENUS_GDSC>;
> + rproc = <&venus_rproc>;
> + iommus = <&apps_iommu 5>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v3 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Rob Herring @ 2016-12-06 0:26 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Xing.Xu, victor.wan, khilman, linux-kernel, dri-devel,
laurent.pinchart, jerry.cao, carlo, linux-amlogic,
linux-arm-kernel
In-Reply-To: <1480583160-31806-4-git-send-email-narmstrong@baylibre.com>
On Thu, Dec 01, 2016 at 10:05:59AM +0100, Neil Armstrong wrote:
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/amlogic,meson-vpu.txt | 112 +++++++++++++++++++++
> 1 file changed, 112 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.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 v3 3/5] spi: armada-3700: Add documentation for the Armada 3700 SPI Controller
From: Rob Herring @ 2016-12-06 0:27 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20161201102719.4291-4-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Thu, Dec 01, 2016 at 11:27:17AM +0100, Romain Perier wrote:
> This adds the devicetree bindings documentation for the SPI controller
> present in the Marvell Armada 3700 SoCs.
>
> Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> Changes in v3:
> - Added tag "Tested-by" by Gregory
> - Fixed commit title, as requested by Mark Brown
>
> .../devicetree/bindings/spi/spi-armada-3700.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-armada-3700.txt
Didn't catch the duplicate with the subject change...
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
* [PATCHv3] mfd: cpcap: Add minimal support
From: Tony Lindgren @ 2016-12-06 0:48 UTC (permalink / raw)
To: Lee Jones, Samuel Ortiz
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Mark Rutland,
Michael Scott
Many Motorola phones like droid 4 are using a custom PMIC called CPCAP
or 6556002. We can support it's core features quite easily with regmap_spi
and regmap_irq.
The children of cpcap, such as regulators, ADC and USB, can be just regular
device drivers and defined in the dts file. They get probed as we call
of_platform_populate() at the end of our probe, and then the children
can just call dev_get_regmap(dev.parent, NULL) to get the regmap.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Marcel Partap <mpartap-hi6Y0CQ0nG0@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Michael Scott <michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
Changes from v2:
- Fix typos in binding documentation for #size-cells and spi-cs-high
- Add ack from Rob
---
.../devicetree/bindings/mfd/motorola-cpcap.txt | 31 +++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/motorola-cpcap.c | 244 +++++++++++++++++
include/linux/mfd/motorola-cpcap.h | 289 +++++++++++++++++++++
5 files changed, 576 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
create mode 100644 drivers/mfd/motorola-cpcap.c
create mode 100644 include/linux/mfd/motorola-cpcap.h
diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
@@ -0,0 +1,31 @@
+Motorola CPCAP PMIC device tree binding
+
+Required properties:
+- compatible : One or both of "motorola,cpcap" or "ste,6556002"
+- reg : SPI chip select
+- interrupt-parent : The parent interrupt controller
+- interrupts : The interrupt line the device is connected to
+- interrupt-controller : Marks the device node as an interrupt controller
+- #interrupt-cells : The number of cells to describe an IRQ, should be 2
+- #address-cells : Child device offset number of cells, should be 1
+- #size-cells : Child device size number of cells, should be 0
+- spi-max-frequency : Typically set to 3000000
+- spi-cs-high : SPI chip select direction
+
+Example:
+
+&mcspi1 {
+ cpcap: pmic@0 {
+ compatible = "motorola,cpcap", "ste,6556002";
+ reg = <0>; /* cs0 */
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ spi-max-frequency = <3000000>;
+ spi-cs-high;
+ };
+};
+
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -714,6 +714,17 @@ config EZX_PCAP
This enables the PCAP ASIC present on EZX Phones. This is
needed for MMC, TouchScreen, Sound, USB, etc..
+config MFD_CPCAP
+ tristate "Support for Motorola CPCAP"
+ depends on SPI
+ depends on OF || COMPILE_TEST
+ select REGMAP_SPI
+ select REGMAP_IRQ
+ help
+ Say yes here if you want to include driver for CPCAP.
+ It is used on many Motorola phones and tablets as a PMIC.
+ At least Motorola Droid 4 is known to use CPCAP.
+
config MFD_VIPERBOARD
tristate "Nano River Technologies Viperboard"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
obj-$(CONFIG_MFD_CORE) += mfd-core.o
obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
+obj-$(CONFIG_MFD_CPCAP) += motorola-cpcap.o
obj-$(CONFIG_MCP) += mcp-core.o
obj-$(CONFIG_MCP_SA11X0) += mcp-sa11x0.o
diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
new file mode 100644
--- /dev/null
+++ b/drivers/mfd/motorola-cpcap.c
@@ -0,0 +1,244 @@
+/*
+ * Motorola CPCAP PMIC core driver
+ *
+ * Copyright (C) 2016 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/sysfs.h>
+
+#include <linux/mfd/motorola-cpcap.h>
+#include <linux/spi/spi.h>
+
+#define CPCAP_NR_IRQ_REG_BANKS 6
+#define CPCAP_NR_IRQ_CHIPS 3
+
+struct cpcap_ddata {
+ struct spi_device *spi;
+ struct regmap_irq *irqs;
+ struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_CHIPS];
+ const struct regmap_config *regmap_conf;
+ struct regmap *regmap;
+};
+
+static int cpcap_check_revision(struct cpcap_ddata *cpcap)
+{
+ u16 vendor, rev;
+ int ret;
+
+ ret = cpcap_get_vendor(&cpcap->spi->dev, cpcap->regmap, &vendor);
+ if (ret)
+ return ret;
+
+ ret = cpcap_get_revision(&cpcap->spi->dev, cpcap->regmap, &rev);
+ if (ret)
+ return ret;
+
+ dev_info(&cpcap->spi->dev, "CPCAP vendor: %s rev: %i.%i (%x)\n",
+ vendor == CPCAP_VENDOR_ST ? "ST" : "TI",
+ CPCAP_REVISION_MAJOR(rev), CPCAP_REVISION_MINOR(rev),
+ rev);
+
+ if (rev < CPCAP_REVISION_2_1) {
+ dev_info(&cpcap->spi->dev,
+ "Please add old CPCAP revision support as needed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+/*
+ * First two irq chips are the two private macro interrupt chips, the third
+ * irq chip is for register banks 1 - 4 and is available for drivers to use.
+ */
+static struct regmap_irq_chip cpcap_irq_chip[CPCAP_NR_IRQ_CHIPS] = {
+ {
+ .name = "cpcap-m2",
+ .num_regs = 1,
+ .status_base = CPCAP_REG_MI1,
+ .ack_base = CPCAP_REG_MI1,
+ .mask_base = CPCAP_REG_MIM1,
+ .use_ack = true,
+ },
+ {
+ .name = "cpcap-m2",
+ .num_regs = 1,
+ .status_base = CPCAP_REG_MI2,
+ .ack_base = CPCAP_REG_MI2,
+ .mask_base = CPCAP_REG_MIM2,
+ .use_ack = true,
+ },
+ {
+ .name = "cpcap1-4",
+ .num_regs = 4,
+ .status_base = CPCAP_REG_INT1,
+ .ack_base = CPCAP_REG_INT1,
+ .mask_base = CPCAP_REG_INTM1,
+ .type_base = CPCAP_REG_INTS1,
+ .use_ack = true,
+ },
+};
+
+static int cpcap_init_irq_chip(struct cpcap_ddata *cpcap, int irq_chip,
+ int irq_start, int nr_irqs)
+{
+ struct regmap_irq_chip *chip = &cpcap_irq_chip[irq_chip];
+ int i, ret;
+
+ for (i = irq_start; i < irq_start + nr_irqs; i++) {
+ struct regmap_irq *cpcap_irq = &cpcap->irqs[i];
+
+ cpcap_irq->reg_offset =
+ ((i - irq_start) / cpcap->regmap_conf->val_bits) *
+ cpcap->regmap_conf->reg_stride;
+ cpcap_irq->mask = BIT(i % cpcap->regmap_conf->val_bits);
+ }
+ chip->irqs = &cpcap->irqs[irq_start];
+ chip->num_irqs = nr_irqs;
+ chip->irq_drv_data = cpcap;
+
+ ret = devm_regmap_add_irq_chip(&cpcap->spi->dev, cpcap->regmap,
+ cpcap->spi->irq,
+ IRQF_TRIGGER_RISING |
+ IRQF_SHARED, -1,
+ chip, &cpcap->irqdata[irq_chip]);
+ if (ret) {
+ dev_err(&cpcap->spi->dev, "could not add irq chip %i: %i\n",
+ irq_chip, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int cpcap_init_irq(struct cpcap_ddata *cpcap)
+{
+ int ret;
+
+ cpcap->irqs = devm_kzalloc(&cpcap->spi->dev,
+ sizeof(*cpcap->irqs) *
+ CPCAP_NR_IRQ_REG_BANKS *
+ cpcap->regmap_conf->val_bits,
+ GFP_KERNEL);
+ if (!cpcap->irqs)
+ return -ENOMEM;
+
+ ret = cpcap_init_irq_chip(cpcap, 0, 0, 16);
+ if (ret)
+ return ret;
+
+ ret = cpcap_init_irq_chip(cpcap, 1, 16, 16);
+ if (ret)
+ return ret;
+
+ ret = cpcap_init_irq_chip(cpcap, 2, 32, 64);
+ if (ret)
+ return ret;
+
+ enable_irq_wake(cpcap->spi->irq);
+
+ return 0;
+}
+
+static const struct of_device_id cpcap_of_match[] = {
+ { .compatible = "motorola,cpcap", },
+ { .compatible = "st,6556002", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, cpcap_of_match);
+
+static const struct regmap_config cpcap_regmap_config = {
+ .reg_bits = 16,
+ .reg_stride = 4,
+ .pad_bits = 0,
+ .val_bits = 16,
+ .write_flag_mask = 0x8000,
+ .max_register = CPCAP_REG_ST_TEST2,
+ .cache_type = REGCACHE_NONE,
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
+
+static int cpcap_probe(struct spi_device *spi)
+{
+ const struct of_device_id *match;
+ int ret = -EINVAL;
+ struct cpcap_ddata *cpcap;
+
+ match = of_match_device(of_match_ptr(cpcap_of_match), &spi->dev);
+ if (!match)
+ return -ENODEV;
+
+ cpcap = devm_kzalloc(&spi->dev, sizeof(*cpcap), GFP_KERNEL);
+ if (!cpcap)
+ return -ENOMEM;
+
+ cpcap->spi = spi;
+ spi_set_drvdata(spi, cpcap);
+
+ spi->bits_per_word = 16;
+ spi->mode = SPI_MODE_0 | SPI_CS_HIGH;
+
+ ret = spi_setup(spi);
+ if (ret < 0)
+ return ret;
+
+ cpcap->regmap_conf = &cpcap_regmap_config;
+ cpcap->regmap = devm_regmap_init_spi(spi, &cpcap_regmap_config);
+ if (IS_ERR(cpcap->regmap)) {
+ ret = PTR_ERR(cpcap->regmap);
+ dev_err(&cpcap->spi->dev, "Failed to initialize regmap: %d\n",
+ ret);
+
+ return ret;
+ }
+
+ ret = cpcap_check_revision(cpcap);
+ if (ret) {
+ dev_err(&cpcap->spi->dev, "Failed to detect CPCAP: %i\n", ret);
+ return ret;
+ }
+
+ ret = cpcap_init_irq(cpcap);
+ if (ret)
+ return ret;
+
+ return of_platform_populate(spi->dev.of_node, NULL, NULL,
+ &cpcap->spi->dev);
+}
+
+static int cpcap_remove(struct spi_device *pdev)
+{
+ struct cpcap_ddata *cpcap = spi_get_drvdata(pdev);
+
+ of_platform_depopulate(&cpcap->spi->dev);
+
+ return 0;
+}
+
+static struct spi_driver cpcap_driver = {
+ .driver = {
+ .name = "cpcap-core",
+ .of_match_table = cpcap_of_match,
+ },
+ .probe = cpcap_probe,
+ .remove = cpcap_remove,
+};
+module_spi_driver(cpcap_driver);
+
+MODULE_ALIAS("platform:cpcap");
+MODULE_DESCRIPTION("CPCAP driver");
+MODULE_AUTHOR("Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/motorola-cpcap.h b/include/linux/mfd/motorola-cpcap.h
new file mode 100644
--- /dev/null
+++ b/include/linux/mfd/motorola-cpcap.h
@@ -0,0 +1,289 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Note that the register defines are based on earlier cpcap.h in
+ * Motorola Linux kernel tree Copyright (C) 2007-2009 Motorola, Inc.
+ *
+ * Rewritten for the real register offsets instead of enumeration
+ * to make the defines usable with Linux kernel regmap support
+ * Copyright (C) 2016 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>.
+ */
+
+#define CPCAP_VENDOR_ST 0
+#define CPCAP_VENDOR_TI 1
+
+#define CPCAP_REVISION_MAJOR(r) (((r) >> 4) + 1)
+#define CPCAP_REVISION_MINOR(r) ((r) & 0xf)
+
+#define CPCAP_REVISION_1_0 0x08
+#define CPCAP_REVISION_1_1 0x09
+#define CPCAP_REVISION_2_0 0x10
+#define CPCAP_REVISION_2_1 0x11
+
+/* CPCAP registers */
+#define CPCAP_REG_INT1 0x0000 /* Interrupt 1 */
+#define CPCAP_REG_INT2 0x0004 /* Interrupt 2 */
+#define CPCAP_REG_INT3 0x0008 /* Interrupt 3 */
+#define CPCAP_REG_INT4 0x000c /* Interrupt 4 */
+#define CPCAP_REG_INTM1 0x0010 /* Interrupt Mask 1 */
+#define CPCAP_REG_INTM2 0x0014 /* Interrupt Mask 2 */
+#define CPCAP_REG_INTM3 0x0018 /* Interrupt Mask 3 */
+#define CPCAP_REG_INTM4 0x001c /* Interrupt Mask 4 */
+#define CPCAP_REG_INTS1 0x0020 /* Interrupt Sense 1 */
+#define CPCAP_REG_INTS2 0x0024 /* Interrupt Sense 2 */
+#define CPCAP_REG_INTS3 0x0028 /* Interrupt Sense 3 */
+#define CPCAP_REG_INTS4 0x002c /* Interrupt Sense 4 */
+#define CPCAP_REG_ASSIGN1 0x0030 /* Resource Assignment 1 */
+#define CPCAP_REG_ASSIGN2 0x0034 /* Resource Assignment 2 */
+#define CPCAP_REG_ASSIGN3 0x0038 /* Resource Assignment 3 */
+#define CPCAP_REG_ASSIGN4 0x003c /* Resource Assignment 4 */
+#define CPCAP_REG_ASSIGN5 0x0040 /* Resource Assignment 5 */
+#define CPCAP_REG_ASSIGN6 0x0044 /* Resource Assignment 6 */
+#define CPCAP_REG_VERSC1 0x0048 /* Version Control 1 */
+#define CPCAP_REG_VERSC2 0x004c /* Version Control 2 */
+
+#define CPCAP_REG_MI1 0x0200 /* Macro Interrupt 1 */
+#define CPCAP_REG_MIM1 0x0204 /* Macro Interrupt Mask 1 */
+#define CPCAP_REG_MI2 0x0208 /* Macro Interrupt 2 */
+#define CPCAP_REG_MIM2 0x020c /* Macro Interrupt Mask 2 */
+#define CPCAP_REG_UCC1 0x0210 /* UC Control 1 */
+#define CPCAP_REG_UCC2 0x0214 /* UC Control 2 */
+
+#define CPCAP_REG_PC1 0x021c /* Power Cut 1 */
+#define CPCAP_REG_PC2 0x0220 /* Power Cut 2 */
+#define CPCAP_REG_BPEOL 0x0224 /* BP and EOL */
+#define CPCAP_REG_PGC 0x0228 /* Power Gate and Control */
+#define CPCAP_REG_MT1 0x022c /* Memory Transfer 1 */
+#define CPCAP_REG_MT2 0x0230 /* Memory Transfer 2 */
+#define CPCAP_REG_MT3 0x0234 /* Memory Transfer 3 */
+#define CPCAP_REG_PF 0x0238 /* Print Format */
+
+#define CPCAP_REG_SCC 0x0400 /* System Clock Control */
+#define CPCAP_REG_SW1 0x0404 /* Stop Watch 1 */
+#define CPCAP_REG_SW2 0x0408 /* Stop Watch 2 */
+#define CPCAP_REG_UCTM 0x040c /* UC Turbo Mode */
+#define CPCAP_REG_TOD1 0x0410 /* Time of Day 1 */
+#define CPCAP_REG_TOD2 0x0414 /* Time of Day 2 */
+#define CPCAP_REG_TODA1 0x0418 /* Time of Day Alarm 1 */
+#define CPCAP_REG_TODA2 0x041c /* Time of Day Alarm 2 */
+#define CPCAP_REG_DAY 0x0420 /* Day */
+#define CPCAP_REG_DAYA 0x0424 /* Day Alarm */
+#define CPCAP_REG_VAL1 0x0428 /* Validity 1 */
+#define CPCAP_REG_VAL2 0x042c /* Validity 2 */
+
+#define CPCAP_REG_SDVSPLL 0x0600 /* Switcher DVS and PLL */
+#define CPCAP_REG_SI2CC1 0x0604 /* Switcher I2C Control 1 */
+#define CPCAP_REG_Si2CC2 0x0608 /* Switcher I2C Control 2 */
+#define CPCAP_REG_S1C1 0x060c /* Switcher 1 Control 1 */
+#define CPCAP_REG_S1C2 0x0610 /* Switcher 1 Control 2 */
+#define CPCAP_REG_S2C1 0x0614 /* Switcher 2 Control 1 */
+#define CPCAP_REG_S2C2 0x0618 /* Switcher 2 Control 2 */
+#define CPCAP_REG_S3C 0x061c /* Switcher 3 Control */
+#define CPCAP_REG_S4C1 0x0620 /* Switcher 4 Control 1 */
+#define CPCAP_REG_S4C2 0x0624 /* Switcher 4 Control 2 */
+#define CPCAP_REG_S5C 0x0628 /* Switcher 5 Control */
+#define CPCAP_REG_S6C 0x062c /* Switcher 6 Control */
+#define CPCAP_REG_VCAMC 0x0630 /* VCAM Control */
+#define CPCAP_REG_VCSIC 0x0634 /* VCSI Control */
+#define CPCAP_REG_VDACC 0x0638 /* VDAC Control */
+#define CPCAP_REG_VDIGC 0x063c /* VDIG Control */
+#define CPCAP_REG_VFUSEC 0x0640 /* VFUSE Control */
+#define CPCAP_REG_VHVIOC 0x0644 /* VHVIO Control */
+#define CPCAP_REG_VSDIOC 0x0648 /* VSDIO Control */
+#define CPCAP_REG_VPLLC 0x064c /* VPLL Control */
+#define CPCAP_REG_VRF1C 0x0650 /* VRF1 Control */
+#define CPCAP_REG_VRF2C 0x0654 /* VRF2 Control */
+#define CPCAP_REG_VRFREFC 0x0658 /* VRFREF Control */
+#define CPCAP_REG_VWLAN1C 0x065c /* VWLAN1 Control */
+#define CPCAP_REG_VWLAN2C 0x0660 /* VWLAN2 Control */
+#define CPCAP_REG_VSIMC 0x0664 /* VSIM Control */
+#define CPCAP_REG_VVIBC 0x0668 /* VVIB Control */
+#define CPCAP_REG_VUSBC 0x066c /* VUSB Control */
+#define CPCAP_REG_VUSBINT1C 0x0670 /* VUSBINT1 Control */
+#define CPCAP_REG_VUSBINT2C 0x0674 /* VUSBINT2 Control */
+#define CPCAP_REG_URT 0x0678 /* Useroff Regulator Trigger */
+#define CPCAP_REG_URM1 0x067c /* Useroff Regulator Mask 1 */
+#define CPCAP_REG_URM2 0x0680 /* Useroff Regulator Mask 2 */
+
+#define CPCAP_REG_VAUDIOC 0x0800 /* VAUDIO Control */
+#define CPCAP_REG_CC 0x0804 /* Codec Control */
+#define CPCAP_REG_CDI 0x0808 /* Codec Digital Interface */
+#define CPCAP_REG_SDAC 0x080c /* Stereo DAC */
+#define CPCAP_REG_SDACDI 0x0810 /* Stereo DAC Digital Interface */
+#define CPCAP_REG_TXI 0x0814 /* TX Inputs */
+#define CPCAP_REG_TXMP 0x0818 /* TX MIC PGA's */
+#define CPCAP_REG_RXOA 0x081c /* RX Output Amplifiers */
+#define CPCAP_REG_RXVC 0x0820 /* RX Volume Control */
+#define CPCAP_REG_RXCOA 0x0824 /* RX Codec to Output Amps */
+#define CPCAP_REG_RXSDOA 0x0828 /* RX Stereo DAC to Output Amps */
+#define CPCAP_REG_RXEPOA 0x082c /* RX External PGA to Output Amps */
+#define CPCAP_REG_RXLL 0x0830 /* RX Low Latency */
+#define CPCAP_REG_A2LA 0x0834 /* A2 Loudspeaker Amplifier */
+#define CPCAP_REG_MIPIS1 0x0838 /* MIPI Slimbus 1 */
+#define CPCAP_REG_MIPIS2 0x083c /* MIPI Slimbus 2 */
+#define CPCAP_REG_MIPIS3 0x0840 /* MIPI Slimbus 3. */
+#define CPCAP_REG_LVAB 0x0844 /* LMR Volume and A4 Balanced. */
+
+#define CPCAP_REG_CCC1 0x0a00 /* Coulomb Counter Control 1 */
+#define CPCAP_REG_CRM 0x0a04 /* Charger and Reverse Mode */
+#define CPCAP_REG_CCCC2 0x0a08 /* Coincell and Coulomb Ctr Ctrl 2 */
+#define CPCAP_REG_CCS1 0x0a0c /* Coulomb Counter Sample 1 */
+#define CPCAP_REG_CCS2 0x0a10 /* Coulomb Counter Sample 2 */
+#define CPCAP_REG_CCA1 0x0a14 /* Coulomb Counter Accumulator 1 */
+#define CPCAP_REG_CCA2 0x0a18 /* Coulomb Counter Accumulator 2 */
+#define CPCAP_REG_CCM 0x0a1c /* Coulomb Counter Mode */
+#define CPCAP_REG_CCO 0x0a20 /* Coulomb Counter Offset */
+#define CPCAP_REG_CCI 0x0a24 /* Coulomb Counter Integrator */
+
+#define CPCAP_REG_ADCC1 0x0c00 /* A/D Converter Configuration 1 */
+#define CPCAP_REG_ADCC2 0x0c04 /* A/D Converter Configuration 2 */
+#define CPCAP_REG_ADCD0 0x0c08 /* A/D Converter Data 0 */
+#define CPCAP_REG_ADCD1 0x0c0c /* A/D Converter Data 1 */
+#define CPCAP_REG_ADCD2 0x0c10 /* A/D Converter Data 2 */
+#define CPCAP_REG_ADCD3 0x0c14 /* A/D Converter Data 3 */
+#define CPCAP_REG_ADCD4 0x0c18 /* A/D Converter Data 4 */
+#define CPCAP_REG_ADCD5 0x0c1c /* A/D Converter Data 5 */
+#define CPCAP_REG_ADCD6 0x0c20 /* A/D Converter Data 6 */
+#define CPCAP_REG_ADCD7 0x0c24 /* A/D Converter Data 7 */
+#define CPCAP_REG_ADCAL1 0x0c28 /* A/D Converter Calibration 1 */
+#define CPCAP_REG_ADCAL2 0x0c2c /* A/D Converter Calibration 2 */
+
+#define CPCAP_REG_USBC1 0x0e00 /* USB Control 1 */
+#define CPCAP_REG_USBC2 0x0e04 /* USB Control 2 */
+#define CPCAP_REG_USBC3 0x0e08 /* USB Control 3 */
+#define CPCAP_REG_UVIDL 0x0e0c /* ULPI Vendor ID Low */
+#define CPCAP_REG_UVIDH 0x0e10 /* ULPI Vendor ID High */
+#define CPCAP_REG_UPIDL 0x0e14 /* ULPI Product ID Low */
+#define CPCAP_REG_UPIDH 0x0e18 /* ULPI Product ID High */
+#define CPCAP_REG_UFC1 0x0e1c /* ULPI Function Control 1 */
+#define CPCAP_REG_UFC2 0x0e20 /* ULPI Function Control 2 */
+#define CPCAP_REG_UFC3 0x0e24 /* ULPI Function Control 3 */
+#define CPCAP_REG_UIC1 0x0e28 /* ULPI Interface Control 1 */
+#define CPCAP_REG_UIC2 0x0e2c /* ULPI Interface Control 2 */
+#define CPCAP_REG_UIC3 0x0e30 /* ULPI Interface Control 3 */
+#define CPCAP_REG_USBOTG1 0x0e34 /* USB OTG Control 1 */
+#define CPCAP_REG_USBOTG2 0x0e38 /* USB OTG Control 2 */
+#define CPCAP_REG_USBOTG3 0x0e3c /* USB OTG Control 3 */
+#define CPCAP_REG_UIER1 0x0e40 /* USB Interrupt Enable Rising 1 */
+#define CPCAP_REG_UIER2 0x0e44 /* USB Interrupt Enable Rising 2 */
+#define CPCAP_REG_UIER3 0x0e48 /* USB Interrupt Enable Rising 3 */
+#define CPCAP_REG_UIEF1 0x0e4c /* USB Interrupt Enable Falling 1 */
+#define CPCAP_REG_UIEF2 0x0e50 /* USB Interrupt Enable Falling 1 */
+#define CPCAP_REG_UIEF3 0x0e54 /* USB Interrupt Enable Falling 1 */
+#define CPCAP_REG_UIS 0x0e58 /* USB Interrupt Status */
+#define CPCAP_REG_UIL 0x0e5c /* USB Interrupt Latch */
+#define CPCAP_REG_USBD 0x0e60 /* USB Debug */
+#define CPCAP_REG_SCR1 0x0e64 /* Scratch 1 */
+#define CPCAP_REG_SCR2 0x0e68 /* Scratch 2 */
+#define CPCAP_REG_SCR3 0x0e6c /* Scratch 3 */
+
+#define CPCAP_REG_VMC 0x0eac /* Video Mux Control */
+#define CPCAP_REG_OWDC 0x0eb0 /* One Wire Device Control */
+#define CPCAP_REG_GPIO0 0x0eb4 /* GPIO 0 Control */
+
+#define CPCAP_REG_GPIO1 0x0ebc /* GPIO 1 Control */
+
+#define CPCAP_REG_GPIO2 0x0ec4 /* GPIO 2 Control */
+
+#define CPCAP_REG_GPIO3 0x0ecc /* GPIO 3 Control */
+
+#define CPCAP_REG_GPIO4 0x0ed4 /* GPIO 4 Control */
+
+#define CPCAP_REG_GPIO5 0x0edc /* GPIO 5 Control */
+
+#define CPCAP_REG_GPIO6 0x0ee4 /* GPIO 6 Control */
+
+#define CPCAP_REG_MDLC 0x1000 /* Main Display Lighting Control */
+#define CPCAP_REG_KLC 0x1004 /* Keypad Lighting Control */
+#define CPCAP_REG_ADLC 0x1008 /* Aux Display Lighting Control */
+#define CPCAP_REG_REDC 0x100c /* Red Triode Control */
+#define CPCAP_REG_GREENC 0x1010 /* Green Triode Control */
+#define CPCAP_REG_BLUEC 0x1014 /* Blue Triode Control */
+#define CPCAP_REG_CFC 0x1018 /* Camera Flash Control */
+#define CPCAP_REG_ABC 0x101c /* Adaptive Boost Control */
+#define CPCAP_REG_BLEDC 0x1020 /* Bluetooth LED Control */
+#define CPCAP_REG_CLEDC 0x1024 /* Camera Privacy LED Control */
+
+#define CPCAP_REG_OW1C 0x1200 /* One Wire 1 Command */
+#define CPCAP_REG_OW1D 0x1204 /* One Wire 1 Data */
+#define CPCAP_REG_OW1I 0x1208 /* One Wire 1 Interrupt */
+#define CPCAP_REG_OW1IE 0x120c /* One Wire 1 Interrupt Enable */
+
+#define CPCAP_REG_OW1 0x1214 /* One Wire 1 Control */
+
+#define CPCAP_REG_OW2C 0x1220 /* One Wire 2 Command */
+#define CPCAP_REG_OW2D 0x1224 /* One Wire 2 Data */
+#define CPCAP_REG_OW2I 0x1228 /* One Wire 2 Interrupt */
+#define CPCAP_REG_OW2IE 0x122c /* One Wire 2 Interrupt Enable */
+
+#define CPCAP_REG_OW2 0x1234 /* One Wire 2 Control */
+
+#define CPCAP_REG_OW3C 0x1240 /* One Wire 3 Command */
+#define CPCAP_REG_OW3D 0x1244 /* One Wire 3 Data */
+#define CPCAP_REG_OW3I 0x1248 /* One Wire 3 Interrupt */
+#define CPCAP_REG_OW3IE 0x124c /* One Wire 3 Interrupt Enable */
+
+#define CPCAP_REG_OW3 0x1254 /* One Wire 3 Control */
+#define CPCAP_REG_GCAIC 0x1258 /* GCAI Clock Control */
+#define CPCAP_REG_GCAIM 0x125c /* GCAI GPIO Mode */
+#define CPCAP_REG_LGDIR 0x1260 /* LMR GCAI GPIO Direction */
+#define CPCAP_REG_LGPU 0x1264 /* LMR GCAI GPIO Pull-up */
+#define CPCAP_REG_LGPIN 0x1268 /* LMR GCAI GPIO Pin */
+#define CPCAP_REG_LGMASK 0x126c /* LMR GCAI GPIO Mask */
+#define CPCAP_REG_LDEB 0x1270 /* LMR Debounce Settings */
+#define CPCAP_REG_LGDET 0x1274 /* LMR GCAI Detach Detect */
+#define CPCAP_REG_LMISC 0x1278 /* LMR Misc Bits */
+#define CPCAP_REG_LMACE 0x127c /* LMR Mace IC Support */
+
+#define CPCAP_REG_TEST 0x7c00 /* Test */
+
+#define CPCAP_REG_ST_TEST1 0x7d08 /* ST Test1 */
+
+#define CPCAP_REG_ST_TEST2 0x7d18 /* ST Test2 */
+
+/*
+ * Helpers for child devices to check the revision and vendor.
+ *
+ * REVISIT: No documentation for the bits below, please update
+ * to use proper names for defines when available.
+ */
+
+static inline int cpcap_get_revision(struct device *dev,
+ struct regmap *regmap,
+ u16 *revision)
+{
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(regmap, CPCAP_REG_VERSC1, &val);
+ if (ret) {
+ dev_err(dev, "Could not read revision\n");
+
+ return ret;
+ }
+
+ *revision = ((val >> 3) & 0x7) | ((val << 3) & 0x38);
+
+ return 0;
+}
+
+static inline int cpcap_get_vendor(struct device *dev,
+ struct regmap *regmap,
+ u16 *vendor)
+{
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(regmap, CPCAP_REG_VERSC1, &val);
+ if (ret) {
+ dev_err(dev, "Could not read vendor\n");
+
+ return ret;
+ }
+
+ *vendor = (val >> 6) & 0x7;
+
+ return 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
^ permalink raw reply
* Re: [PATCH v5 11/14] ASoC: add simple-graph-card document
From: Kuninori Morimoto @ 2016-12-06 0:57 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Brown, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <20161205225802.ye4tcjwpjmarbfxh@rob-hp-laptop>
Hi Rob
> I'd expect the top level node to be the card node that knows how to find
> all the components. The graph should reflect the data flow. For example,
> the data goes to audio DSP to I2S host to codec to amp.
Do you mean, is this OK for OF graph ?
in driver point of view, "I2S" is sound card here.
I2S {
port {
i2s-dsp: endpoint {
remote-endpoint = <&dsp>;
}
i2s-codec: endpoint {
remote-endpoint = <&codec>;
}
}
}
DSP {
port {
dsp: endpoint {
remote-endpoint = <&i2s-dsp>;
}
}
}
Codec {
port {
codec: endpoint {
remote-endpoint = <&i2s-codec>;
}
}
}
--
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: [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: zhangfei @ 2016-12-06 1:10 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5982682.vMJxVociDa@wuerfel>
Hi, Arnd
On 2016年12月02日 20:32, Arnd Bergmann wrote:
> On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
>> Hi, Arnd
>>
>> On 2016年12月01日 20:05, Arnd Bergmann wrote:
>>> On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
>>>> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
>>>> + 0x20 0x10 /* 1: i2c1 */
>>>> + 0x20 0x20 /* 2: i2c2 */
>>>> + 0x20 0x8000000>; /* 3: i2c6 */
>>>> + };
>>>> +
>>>> +Specifying reset lines connected to IP modules
>>>> +==============================================
>>>> +example:
>>>> +
>>>> + i2c0: i2c@..... {
>>>> + ...
>>>> + resets = <&iomcu_rst 0>;
>>>> + ...
>>>> + };
>>> I don't really like this approach, since now the information is
>>> in two places. Why not put the data into the reset specifier
>>> directly when it is used?
>> Any example, still not understand.
>> They are consumer and provider.
> I mean in the i2c node, have
>
> i2c0: i2c@..... {
> ...
> resets = <&iomcu_rst 0x20 0x8>;
> ...
> }
Got it.
There is function of_xlate in reset_controller_dev can parse the dts
when devm_reset_control_get
* @of_xlate: translation function to translate from specifier as found
in the
* device tree to id as given to the reset control ops
Will use this instead.
>>> Also the format seems a little too close to the actual register
>>> layout and could be a little more abstract, using bit numbers instead
>>> of a bitmask and register numbers instead of offsets.
>> We use bit numbers first.
>> But in the developing process, we found several bits may be required for
>> one driver.
>> And they may not be continuous as the bits may already be occupied.
>> Directly using offset, we can set several bits together for simple, to
>> give more flexibility.
>> So after discussion, we directly use offset.
> Can you give an example for why this is needed? Is this different
> from a device that has multiple reset lines?
Yes, we can use multiple reset lines, which is also our original method.
But it may have too many reset lines, like pcie driver will have 5 resets.
So just thinking it can be optimized.
However, when using of_xlate, parsing offset & bit to rstc->id (unsigned
int),
It only support u32, so will use bit numbers again.
rstc_id = rcdev->of_xlate(rcdev, &args);
Will update v3 patch, help take a look.
Thanks
--
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 V7 00/10] PM / OPP: Multiple regulator support
From: Rafael J. Wysocki @ 2016-12-06 1:34 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, Lists linaro-kernel,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Stephen Boyd,
Nishanth Menon, Vincent Guittot, Rob Herring, Dave Gerlach,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAKohpokXXhcrhzqs+iW+1kTYjyF47bHF0TupMxP=4cSqXOThtA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Dec 5, 2016 at 3:21 PM, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 1 December 2016 at 16:28, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> Hi,
>>
>> Some platforms (like TI) have complex DVFS configuration for CPU
>> devices, where multiple regulators are required to be configured to
>> change DVFS state of the device. This was explained well by Nishanth
>> earlier [1].
>>
>> One of the major complaints around multiple regulators case was that the
>> DT isn't responsible in any way to represent the order in which multiple
>> supplies need to be programmed, before or after a frequency change. It
>> was considered in this patch and such information is left for the
>> platform specific OPP driver now, which can register its own
>> opp_set_rate() callback with the OPP core and the OPP core will then
>> call it during DVFS.
>>
>> The patches are tested on Exynos5250 (Dual A15). I have hacked around DT
>> and code to pass values for multiple regulators and verified that they
>> are all properly read by the kernel (using debugfs interface).
>>
>> Dave Gerlach has already tested [2] it on the real TI platforms and it
>> works well for him.
>>
>> This is rebased over: linux-next branch in the PM tree.
>>
>> V6->V7:
>> - Added RBY from Stephen for the 8th patch as well.
>> - Rebased over pm/bleeding-edge as the dependency patch is already
>> applied there.
>> - s/dev_pm_opp_set_regulator()/dev_pm_opp_set_regulators() in a comment.
>> - Removed the local 'names' array in cpufreq-dt and used "&name"
>> instead.
>> - Only the 6th patch doesn't have a Reviewed-by Tag now..
>
> Hi Rafael,
>
> V6 of this series received some minor comments [1] and I have
> resolved them all here. Now that the merge window is so close,
> I think we should be merge it now so that it gets a chance to live
> in linux-next for few days.
I've queued them up, but I'd feel more comfortable with an ACK or
Reviewed-by on patch [6/10] too.
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: [RESEND PATCH v2 4/7] drm/vc4: Add support for the VEC (Video Encoder) IP
From: Florian Fainelli @ 2016-12-06 1:50 UTC (permalink / raw)
To: Boris Brezillon, David Airlie, Daniel Vetter,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Stephen Warren,
Lee Jones, Eric Anholt,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480686493-4813-5-git-send-email-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On 12/02/2016 05:48 AM, Boris Brezillon wrote:
> The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
>
> Signed-off-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> new file mode 100644
> index 000000000000..2d4256fcc6f2
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -0,0 +1,657 @@
> +/*
> + * Copyright (C) 2016 Broadcom Limited
The standard copyright template post acquisition is just Broadcom, not
Broadcom Limited, nor Broadcom corporation. Can you audit your entire
submission and fix this up accordingly?
Thanks!
--
Florian
--
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
* [PATCH v3 0/2] add reset-hi3660
From: Zhangfei Gao @ 2016-12-06 1:51 UTC (permalink / raw)
To: Rob Herring, Philipp Zabel, Arnd Bergmann, haojian.zhuang
Cc: devicetree, linux-arm-kernel, Zhangfei Gao
v3:
change dts usage suggested by Arnd
from
resets = <&iomcu_rst 0>;
to
resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
v2:
Considering Arnd and Philipp suggestions,
move reset register to dts as table instead of dts header in case of ABI issue
Zhangfei Gao (2):
dt-bindings: Document the hi3660 reset bindings
reset: hisilicon: add reset-hi3660
.../bindings/reset/hisilicon,hi3660-reset.txt | 36 ++++++
drivers/reset/hisilicon/Kconfig | 7 ++
drivers/reset/hisilicon/Makefile | 1 +
drivers/reset/hisilicon/reset-hi3660.c | 126 +++++++++++++++++++++
4 files changed, 170 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
create mode 100644 drivers/reset/hisilicon/reset-hi3660.c
--
2.7.4
^ 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