Re: [PATCH 12/14] ARM: dts: qs600: add pwrseq support to WLAN

[Igor Grinberg]

On 09/18/15 15:32, Srinivas Kandagatla wrote:
> Add pwrseq support to sdcc4 which would enable a proper reset of WLAN
> without ugly hacks in the board support file.
> 
> Signed-off-by: Srinivas Kandagatla 

Thanks Srini!

Acked-by: Igor Grinberg 

> ---
>  arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 32 
> +
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts 
> b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> index 8aac3be..cc9d942 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> @@ -1,4 +1,6 @@
>  #include "qcom-apq8064-v2.0.dtsi"
> +#include 
> +#include 
>  
>  / {
>   model = "CompuLab CM-QS600";
> @@ -12,6 +14,20 @@
>   stdout-path = "serial0:115200n8";
>   };
>  
> + pwrseq {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "simple-bus";
> +
> + sdcc4_pwrseq: sdcc4_pwrseq {
> + pinctrl-names = "default";
> + pinctrl-0 = <_default_gpios>;
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <_gpio 43 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
>   soc {
>   rpm@108000 {
>   regulators {
> @@ -154,6 +170,21 @@
>   regulator-always-on;
>   };
>  
> + qcom,ssbi@50 {
> + pmic@0 {
> + gpio@150 {
> + wlan_default_gpios: wlan-gpios {
> + pios {
> + pins = "gpio43";
> + function = "normal";
> + bias-disable;
> + power-source = 
> ;
> + };
> + };
> + };
> + };
> + };
> +
>   amba {
>   /* eMMC */
>   sdcc1: sdcc@1240 {
> @@ -172,6 +203,7 @@
>   status = "okay";
>   vmmc-supply = <_fixed>;
>   vqmmc-supply = <_fixed>;
> + mmc-pwrseq = <_pwrseq>;
>   };
>   };
>   };
> 

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

RE: [PATCH] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

Ping!

-Original Message-
From: Bharat Kumar Gogada [mailto:bharat.kumar.gog...@xilinx.com]
Sent: Thursday, August 27, 2015 5:14 PM
To: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; 
ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek; Soren 
Brinkmann; bhelg...@google.com; a...@arndb.de; tinam...@apm.com; 
tred...@nvidia.com; r...@broadcom.com; minghuan.l...@freescale.com; 
m-kariche...@ti.com; ha...@hauke-m.de
Cc: devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Kumar Gogada; 
Ravikiran Gummaluri
Subject: [PATCH] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host 
Controller

Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.

Signed-off-by: Bharat Kumar Gogada 
Signed-off-by: Ravi Kiran Gummaluri 
---
 .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   39 +
 drivers/pci/host/Kconfig   |9 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pci-xilinx-nwl.c  | 1038 
 4 files changed, 1087 insertions(+), 0 deletions(-)  create mode 100644 
Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
 create mode 100644 drivers/pci/host/pci-xilinx-nwl.c

diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..c554d6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,39 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location and
+length
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- ranges: ranges for the PCI memory regions (I/O space region is not
+   supported by hardware)
+   Please refer to the standard PCI bus binding document for a more
+   detailed explanation
+
+Optional properties:
+- xlnx,msi-fifo: To enable MSI FIFO mode
+
+Example:
+
+nwl_pcie: pcie@fd0e {
+   compatible = "xlnx,nwl-pcie-2.11";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   device_type = "pci";
+   interrupt-parent = <>;
+   interrupts = < 0 118 4
+  0 116 4
+  0 115 4  // MSI_1 [63...32]
+  0 114 4 >;   // MSI_0 [31...0]
+   interrupt-names = "misc", "intx", "msi_1", "msi_0";
+   reg = <0x0 0xfd0e 0x1000
+  0x0 0xfd48 0x1000
+  0x0 0xE000 0x100>;
+   reg-names = "breg", "pcireg", "cfg";
+   ranges = <0x0200 0x 0xE100 0x 0xE100 0
+0x0F00>; };
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 
c132bdd..5ff4e7e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,15 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF

+config PCI_XILINX_NWL
+   bool "NWL PCIe Core"
+   depends on ARCH_ZYNQMP && PCI_MSI
+   help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller.The controller can act as Root Port
+or End Point.The current option selection will only
+support root port enabling.
+
 config PCIE_DW
bool

diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile index 
140d66f..0f3a789 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
 obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
+obj-$(CONFIG_PCI_XILINX_NWL) += pci-xilinx-nwl.o
 obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
 obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
 obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o diff --git 
a/drivers/pci/host/pci-xilinx-nwl.c b/drivers/pci/host/pci-xilinx-nwl.c
new file mode 100644
index 000..6c2fa80
--- /dev/null
+++ b/drivers/pci/host/pci-xilinx-nwl.c
@@ -0,0 +1,1038 @@
+/*
+ * PCIe host controller driver for NWL PCIe Bridge
+ * Based on pci-xilinx.c, pci-tegra.c
+ *
+ * (C) Copyright 2014 - 2015, Xilinx, Inc.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 

[PATCH 1/1] ARM: DTS: dra72-evm: remove cpsw gpio hogging and add select-slave-gpio

[Mugunthan V N]

Since GPIO hogging fails to through error when booting with
gpio-pcf857x as module and NFS root filesystem. So by having
mode-gpio, it throw error to user so that the used can make
gpio-pcf857x as inbuilt for NFS. When using mmc/ramdisk as root
fs, cpsw will probe defer and re-probes again when gpio-pcf857x
module is inserted and ethernet becomes operational.

Signed-off-by: Mugunthan V N 
---

The driver patch is applied to net-next branch (also present in
linux-next) with commit '1d147ccbfc35 ("drivers: net: cpsw: Add
support to drive gpios for ethernet to be functional") and logs
[1] also pushed a branch [2] for testing.

[1]: http://pastebin.ubuntu.com/12306224/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-gpio-optional-v3

---
 arch/arm/boot/dts/dra72-evm.dts | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index c11ccb1..b7eca13 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -353,12 +353,6 @@
interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <2>;
-
-   cpsw_sel_s0 {
-   gpio-hog;
-   gpios = <4 GPIO_ACTIVE_HIGH>;
-   output-low;
-   };
};
 };
 
@@ -590,6 +584,7 @@
pinctrl-0 = <_default>;
pinctrl-1 = <_sleep>;
slaves = <1>;
+   mode-gpios = <_gpio_21 4 GPIO_ACTIVE_HIGH>;
 };
 
 _emac0 {
-- 
2.6.0.rc2.10.gf4d9753

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

Re: [PATCH v10 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 15-09-07 13:51:34, Sanchayan Maity wrote:
> Hello,
> 
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-9-g1cec223 #5 SMP Mon Sep 7 12:34:37 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2006      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1300      
> 8d0 320a 0800      
> 8e0  e200      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> Changes since v9:
> 1. Drop clock-names property from DT
> 2. Rebase on top of latest char-misc-next
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Version 9 patches can be found here
> https://lkml.org/lkml/2015/8/12/530
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  19 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   8 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 344 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
>  create mode 100644 drivers/nvmem/vf610-ocotp.c
> 
> -- 
> 2.5.1
> 
--
To unsubscribe from this list: 

Re: [PATCH 10/14] ARM: dts: qs600: Add missing pinctrl property for gsbi7 uart

[Igor Grinberg]

On 09/18/15 15:31, Srinivas Kandagatla wrote:
> This patch adds missing 2pin uart pinctrl property to gsbi7 uart on
> CM-QS600.
> 
> Signed-off-by: Srinivas Kandagatla 

Acked-by: Igor Grinberg 

> ---
>  arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts 
> b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> index bdea747..8aac3be 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> @@ -101,6 +101,8 @@
>   qcom,mode = ;
>   serial@1664 {
>   status = "ok";
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart_2pins>;
>   };
>   };
>  
> 

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

Re: [PATCH 14/14] ARM: dts: qs600: Add SD card detect support.

[Igor Grinberg]

On 09/18/15 15:32, Srinivas Kandagatla wrote:
> This patch adds SD card detect support.
> 
> Signed-off-by: Srinivas Kandagatla 

Acked-by: Igor Grinberg 

> ---
>  arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts 
> b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> index cc9d942..03784f1 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
> @@ -29,6 +29,16 @@
>   };
>  
>   soc {
> + pinctrl@80 {
> + card_detect: card_detect {
> + mux {
> + pins = "gpio26";
> + function = "gpio";
> + bias-disable;
> + };
> + };
> + };
> +
>   rpm@108000 {
>   regulators {
>   vin_lvs1_3_6-supply = <_s4>;
> @@ -197,6 +207,9 @@
>   sdcc3: sdcc@1218 {
>   status = "okay";
>   vmmc-supply = <_fixed>;
> + pinctrl-names   = "default";
> + pinctrl-0   = <_detect>;
> + cd-gpios= <_pinmux 26 
> GPIO_ACTIVE_LOW>;
>   };
>   /* WLAN */
>   sdcc4: sdcc@121c {
> 

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

Re: [RFC PATCH 2/3] dtc: make check test for dtc --annotate

[David Gibson]

On Tue, Sep 15, 2015 at 09:24:59PM -0700, Frank Rowand wrote:
> From: Frank Rowand 
> 
> Add dtc tests.
> 
>   - dtc --annotate to create a .dts with annotations
>   - compile the annotated .dts
> 
> Not-signed-off-by: Frank Rowand 

It'd be nice to make this test a bit less trivial by actually
comparing the output against a sample.  Maybe for tests/include0.dts
to give it a real workout.

> ---
>  tests/run_tests.sh |3 +++
>  1 file changed, 3 insertions(+)
> 
> Index: b/tests/run_tests.sh
> ===
> --- a/tests/run_tests.sh
> +++ b/tests/run_tests.sh
> @@ -276,6 +276,9 @@ libfdt_tests () {
>  run_dtc_test -I dts -O dtb -o sourceoutput.test.dts.test.dtb 
> sourceoutput.test.dts
>  run_test dtbs_equal_ordered sourceoutput.test.dtb 
> sourceoutput.test.dts.test.dtb
>  
> +run_dtc_test --annotate -o sourceoutput.test.annotate.dts 
> sourceoutput.dts
> +run_dtc_test -o sourceoutput.test.annotate.dts.test.dts 
> sourceoutput.test.annotate.dts
> +
>  run_dtc_test -I dts -O dtb -o embedded_nul.test.dtb embedded_nul.dts
>  run_dtc_test -I dts -O dtb -o embedded_nul_equiv.test.dtb 
> embedded_nul_equiv.dts
>  run_test dtbs_equal_ordered embedded_nul.test.dtb 
> embedded_nul_equiv.test.dtb

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgpnukAULKOxB.pgp
Description: PGP signature

Re: [RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding

[Philipp Zabel]

Hi Rob,

thank you for the comments.

Am Freitag, den 18.09.2015, 15:33 -0500 schrieb Rob Herring:
[...]
> > +The display-subsystem node binds together all individual device nodes that
> > +comprise the DISP subsystem.
> > +
> > +Required properties:
> > +
> > +- compatible: "mediatek,-disp"
> 
> > +- components: Should contain a list of phandles pointing to the DISP 
> > function
> > +  block device nodes.
> > +- component-names: Should contain the name of the function block pointed to
> > +  by the components phandle of the same index.
> 
> NAK. Group these nodes under a parent node, use of-graph or just don't
> put this into DT. Don't invent a new way.

Ok. The reason I haven't grouped all the display nodes together in the
first place is that they aren't contiguous in the register space. So
instead of:

ovl@1400c000 {
compatible = "mediatek,mt8173-disp-ovl";
};
...
ufoe@1401a000 {
compatible = "mediatek,mt8173-disp-ufoe";
};

pwm@1401e000 {
compatible = "mediatek,mt8173-disp-pwm";
};

larb@14021000 {
compatible = "mediatek,mt8173-smi-larb";
};

od@14023000 {
compatible = "mediatek,mt8173-disp-od";
};

We'd have:

display-subsystem@1400c00 {
compatible = "mediatek,mt8173-disp", "simple-bus";

ovl@1400c000 {
compatible = "mediatek,mt8173-disp-ovl";
};
...
ufoe@1401a000 {
compatible = "mediatek,mt8173-disp-ufoe";
};

od@14023000 {
compatible = "mediatek,mt8173-disp-od";
};
};

pwm@1401e000 {
compatible = "mediatek,mt8173-disp-pwm";
};

larb@14021000 {
compatible = "mediatek,mt8173-smi-larb";
};

Note how the display-subsystem node overlaps the larb node. Is that
acceptable?

[...]
> > diff --git 
> > a/Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt 
> > b/Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
> > new file mode 100644
> > index 000..e892ef1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
> > @@ -0,0 +1,29 @@
> > +Mediatek DSI Device
> > +===
> > +
> > +The Mediatek DSI function block is a sink of the display subsystem and can
> > +drive up to 4-lane MIPI DSI output. Two DSIs can be synchronized for dual-
> > +channel output.
> > +
> > +Required properties:
> > +- compatible: "mediatek,-dsi"
> > +- reg: Physical base address and length of the controller's registers
> > +- clocks: device clocks
> > +  See Documentation/devicetree/bindings/clock/clock-bindings.txt for 
> > details.
> > +- clock-names: must contain "engine" and "digital".
> 
> This leaves wondering which one is used for DSI bit clock.

The MIPI_TX0 module controls the MIPI D-PHY. It contains a PLL that
provides the bit clock to the DSI module.

>From the documentation, it looks to me like the AP_PLL_CON0[6] bit in
the mediatek,mt8173-apmixedsys region gates the 26 MHz reference clock
to MIPI_TX. It is enabled by default. Currently there is no gate clock
registered for that bit.
Can somebody confirm that this gate clock should be added to the
mediatek,mt8173-apmixedsys bindings?

> > +
> > +Example:
> > +
> > +dsi0: dsi@1401b000 {
> > +   compatible = "mediatek,mt8173-dsi";
> > +   reg = <0 0x1401b000 0 0x1000>,  /* DSI0 */
> > + <0 0x10215000 0 0x1000>;  /* MIPI_TX0 */

Thinking about it, MIPI_TX0 is for PHY control. Should this be moved
into its own node and the phy bindings used to let the DSI driver find
it?

> > +   clocks = < MM_DSI0_ENGINE>, < MM_DSI0_DIGITAL>;
> > +   clock-names = "engine", "digital";
> > +
> > +   port {
> 
> Missing from the binding description.

Thanks, I'll fix that next round.

> > +   dsi0_out: endpoint {
> > +   remote-endpoint = <_in>;
> > +   };
> > +   };
> > +};

best regards
Philipp

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

Re: [RFC PATCH 1/3] dtc: dts source location annotation

[David Gibson]

On Tue, Sep 15, 2015 at 09:22:18PM -0700, Frank Rowand wrote:
> 
> From: Frank Rowand 
> 
> Proof of concept patch.
> 
> Annotates input source file and line number of nodes and properties
> as comments in output .dts file when --annotate flag is supplied.
> 
> Not-signed-off-by: Frank Rowand 

A like the concept, but I have some queries about the implementation.

> ---
>  dtc-lexer.l  |2 +
>  dtc.c|9 
>  dtc.h|   14 +
>  livetree.c   |   62 
> +++
>  srcpos.h |6 +
>  treesource.c |   27 -
>  6 files changed, 115 insertions(+), 5 deletions(-)
> 
> Index: b/dtc.h
> ===
> --- a/dtc.h
> +++ b/dtc.h
> @@ -54,6 +54,7 @@ extern int reservenum;  /* Number of mem
>  extern int minsize;  /* Minimum blob size */
>  extern int padsize;  /* Additional padding to blob */
>  extern int phandle_format;   /* Use linux,phandle or phandle properties */
> +extern bool annotate;/* annotate .dts with input source 
> location */
>  
>  #define PHANDLE_LEGACY   0x1
>  #define PHANDLE_EPAPR0x2
> @@ -126,6 +127,16 @@ bool data_is_one_string(struct data d);
>  #define MAX_NODENAME_LEN 31
>  
>  /* Live trees */
> +struct src {
> + char *name;
> + int lineno;
> +};

I'd prefer to see the existing struct srcpos used, rather than
creating a new structure.

> +struct prop_src {
> + struct prop_src *prev;
> + struct src src;
> +};
> +
>  struct label {
>   bool deleted;
>   char *label;
> @@ -140,6 +151,7 @@ struct property {
>   struct property *next;
>  
>   struct label *labels;
> + struct src src;
>  };
>  
>  struct node {
> @@ -158,6 +170,8 @@ struct node {
>   int addr_cells, size_cells;
>  
>   struct label *labels;
> + struct src begin_src;
> + struct src end_src;
>  };
>  
>  #define for_each_label_withdel(l0, l) \
> Index: b/livetree.c
> ===
> --- a/livetree.c
> +++ b/livetree.c
> @@ -19,6 +19,9 @@
>   */
>  
>  #include "dtc.h"
> +#include "srcpos.h"
> +
> +struct prop_src *prev_prop_src = NULL;

So you've built a new global stack here, and I don't really understand
what it's for.  The parser already tracks source positions for each
construct, so you should be able to just use that.  You'd need to pass
the srcpos from dtc-parser.y into the tree building calls in more
places, but that should be it.

Or have I missed something?

>  /*
>   * Tree building functions
> @@ -58,6 +61,13 @@ struct property *build_property(char *na
>  
>   new->name = name;
>   new->val = val;
> + if (current_srcfile) {
> + new->src.name = current_srcfile->name;
> + new->src.lineno = current_srcfile->lineno;
> + } else {
> + new->src.name = "__builtin__";
> + new->src.lineno = 0;

A comment explaining when this will happen in practice would be nice.

Incidentally.. what happens if you use dtb input and try to annotate?

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgpYjJwutNePN.pgp
Description: PGP signature

Re: [PATCH 2/5] pinctrl: berlin: add the berlin4ct pinctrl driver

[Jisheng Zhang]

Dear Sebastian,

On Sun, 20 Sep 2015 21:32:37 +0200
Sebastian Hesselbarth  wrote:

> On 19.09.2015 12:02, Jisheng Zhang wrote:
> > Add the pin-controller driver for Marvell Berlin BG4CT SoC, with definition
> > of its groups and functions. This uses the core Berlin pinctrl driver.
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> [...]
> > diff --git a/drivers/pinctrl/berlin/berlin4ct.c 
> > b/drivers/pinctrl/berlin/berlin4ct.c
> > new file mode 100644
> > index 000..2960e16
> > --- /dev/null
> > +++ b/drivers/pinctrl/berlin/berlin4ct.c
> > @@ -0,0 +1,503 @@
> > +/*
> > + * Marvell berlin4ct pinctrl driver
> [...]
> > +static const struct berlin_desc_group berlin4ct_soc_pinctrl_groups[] = {
> > +   BERLIN_PINCTRL_GROUP("EMMC_RSTn", 0x0, 0x3, 0x00,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "emmc_rstn"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "gpio47")),
> 
> Jisheng,
> 
> I am fine with naming the groups after the 0x0 function but
> the functions themselves should be named after a generic
> name, e.g. "emmc" instead of "emmc_rstn".

This seems better. Will change in newer version.

> 
> That will allow to add pinmux nodes like
> 
> uart_pmx {
>   groups = "SM_UART0_TXD", "SM_UART0_RXD";
>   function = "uart0";
> };
> 
> instead of two separate nodes like in patch 5/5.
> 
> You should however keep the actual pin function e.g. in a comment
> after the function define above:
> 
> BERLIN_PINCTRL_GROUP("EMMC_RSTn", 0x0, 0x3, 0x00,
>   BERLIN_PINCTRL_FUNCTION(0x0, "emmc"),   /* RESETn */
>   BERLIN_PINCTRL_FUNCTION(0x1, "gpio")),  /* GPIO47 */
> 
> > +   BERLIN_PINCTRL_GROUP("NAND_IO0", 0x0, 0x3, 0x03,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "nand_io0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii_rxd0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "sd1_clk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "gpio0")),
> [...]
> > +   BERLIN_PINCTRL_GROUP("SD0_CLK", 0x4, 0x3, 0x12,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "gpio29"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "sd0_clk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "sts4_clk"),
> 
> Please find a better name for "sts" whatever it is for.

sts is one kind of HW component, and that's what we called it.

> 
> > +   BERLIN_PINCTRL_FUNCTION(0x5, "v4g_dbg8"),
> 
> ditto for "v4g"

v4g is another kind of HW component which is called as "v4g"

> 
> > +   BERLIN_PINCTRL_FUNCTION(0x7, "phy_dbg8")),
> [...]
> > +   BERLIN_PINCTRL_GROUP("SCRD0_RST", 0xc, 0x3, 0x06,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "gpio15"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "scrd0_rst"),
> 
> ditto for "scrd0"

scrd stands for smartcard. But it's what HW/ASIC call them

> 
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "sd1a_clk")),
> > +   BERLIN_PINCTRL_GROUP("SCRD0_DCLK", 0xc, 0x3, 0x09,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "gpio16"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "scrd0_dclk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "sd1a_cmd")),
> 
> What is the "a" for in "sd1a" ? There is a "sd1b" below so I
> guess that there is two pinmux groups that mux sd1?

Yes, correct.

> 
> > +   BERLIN_PINCTRL_GROUP("SCRD0_GPIO0", 0xc, 0x3, 0x0c,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "gpio17"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "scrd0_gpio0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "sif_dio"),
> 
> What kind of interface is "sif" ?

serial interface, ASIC called it as SIF

> 
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "sd1a_dat0")),
> [...]
> > +static const struct berlin_desc_group berlin4ct_soc_aviopinctrl_groups[] = 
> > {
> > +   BERLIN_PINCTRL_GROUP("TX_EDDC_SCL", 0x0, 0x3, 0x00,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "avio_gpio0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "tx_eddc_scl"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "tw1_scl")),
> > +   BERLIN_PINCTRL_GROUP("TX_EDDC_SDA", 0x0, 0x3, 0x03,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "avio_gpio1"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "tx_eddc_sda"),
> > +   BERLIN_PINCTRL_FUNCTION(0x2, "tw1_sda")),
> > +   BERLIN_PINCTRL_GROUP("I2S1_LRCKO", 0x0, 0x3, 0x06,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "avio_gpio2"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "i2s1_lrcko"),
> > +   BERLIN_PINCTRL_FUNCTION(0x3, "sts6_clk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x4, "adac_dbg0"),
> > +   BERLIN_PINCTRL_FUNCTION(0x6, "sd1b_clk"),
> > +   BERLIN_PINCTRL_FUNCTION(0x7, "avio_dbg0")),
> [...]
> > +static const struct berlin_desc_group berlin4ct_sysmgr_pinctrl_groups[] = {
> > +   BERLIN_PINCTRL_GROUP("SM_TW2_SCL", 0x0, 0x3, 0x00,
> > +  

Re: [PATCH] ARM: dts: fix usb pin control for imx-rex dts

[Felipe Tonello]

On Wed, Sep 16, 2015 at 6:40 PM,   wrote:
> From: "Felipe F. Tonello" 
>
> This fixes a duplicated pin control causing this error:
>
> imx6q-pinctrl 20e.iomuxc: pin MX6Q_PAD_GPIO_1 already
> requested by regulators:regulator@2; cannot claim for 2184000.usb
> imx6q-pinctrl 20e.iomuxc: pin-137 (2184000.usb) status -22
> imx6q-pinctrl 20e.iomuxc: could not request pin 137
> (MX6Q_PAD_GPIO_1) from group usbotggrp  on device 20e.iomuxc
> imx_usb 2184000.usb: Error applying setting, reverse things
> back
> imx6q-pinctrl 20e.iomuxc: pin MX6Q_PAD_EIM_D31 already
> requested by regulators:regulator@1; cannot claim for 2184200.usb
> imx6q-pinctrl 20e.iomuxc: pin-52 (2184200.usb) status -22
> imx6q-pinctrl 20e.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
> from group usbh1grp  on device 20e.iomuxc
> imx_usb 2184200.usb: Error applying setting, reverse things
> back
>
> Signed-off-by: Felipe F. Tonello 

Any comments?

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

Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC

[Harini Katakam]

Hi Richard,

On Tue, Sep 22, 2015 at 12:09 AM, Richard Cochran
 wrote:
> On Mon, Sep 21, 2015 at 11:19:32PM +0530, Harini Katakam wrote:
>> Ping
>
> 1) trim your replies
>
> 2) put the PTP maintainer on PTP patches for review
>

I'm sorry I missed that. Will do so in the future.

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

Re: [PATCH v3 1/3] ARM: uniphier: add outer cache support

[Masahiro Yamada]

Hi Russell,


2015-09-22 4:38 GMT+09:00 Russell King - ARM Linux :
> On Fri, Sep 18, 2015 at 01:37:32PM +0900, Masahiro Yamada wrote:
>> +/**
>> + * __uniphier_cache_maint_common - run a queue operation for a particular 
>> level
>> + *
>> + * @data: cache controller specific data
>> + * @start: start address of range operation (don't care for "all" operation)
>> + * @size: data size of range operation (don't care for "all" operation)
>> + * @operation: flags to specify the desired cache operation
>> + */
>> +static void __uniphier_cache_maint_common(struct uniphier_cache_data *data,
>> +   unsigned long start,
>> +   unsigned long size,
>> +   u32 operation)
>> +{
>> + unsigned long flags;
>> +
>> + /*
>> +  * The IRQ must be disable during this sequence because the accessor
>> +  * holds the access right of the operation queue registers.  The IRQ
>> +  * should be restored after releasing the register access right.
>> +  */
>> + local_irq_save(flags);
>> +
>> + /* clear the complete notification flag */
>> + writel_relaxed(UNIPHIER_SSCOLPQS_EF, data->op_base + 
>> UNIPHIER_SSCOLPQS);
>> +
>> + /*
>> +  * We do not need a spin lock here because the hardware guarantees
>> +  * this sequence is atomic, i.e. the write access is arbitrated
>> +  * and only the winner's write accesses take effect.
>> +  * After register settings, we need to check the UNIPHIER_SSCOPPQSEF to
>> +  * see if we won the arbitration or not.
>> +  * If the command was not successfully set, just try again.
>> +  */
>> + do {
>> + /* set cache operation */
>> + writel_relaxed(UNIPHIER_SSCOQM_CE | operation,
>> +data->op_base + UNIPHIER_SSCOQM);
>> +
>> + /* set address range if needed */
>> + if (likely(UNIPHIER_SSCOQM_S_IS_RANGE(operation))) {
>> + writel_relaxed(start, data->op_base + 
>> UNIPHIER_SSCOQAD);
>> + writel_relaxed(size, data->op_base + UNIPHIER_SSCOQSZ);
>> + }
>> +
>> + /* set target ways if needed */
>> + if (unlikely(UNIPHIER_SSCOQM_TID_IS_WAY(operation)))
>> + writel_relaxed(data->way_locked_mask,
>> +data->op_base + UNIPHIER_SSCOQWN);
>> + } while (unlikely(readl_relaxed(data->op_base + UNIPHIER_SSCOPPQSEF) &
>> +   (UNIPHIER_SSCOPPQSEF_FE | UNIPHIER_SSCOPPQSEF_OE)));
>> +
>> + /* wait until the operation is completed */
>> + while (likely(readl_relaxed(data->op_base + UNIPHIER_SSCOLPQS) !=
>> +   UNIPHIER_SSCOLPQS_EF))
>> + cpu_relax();
>> +
>> + local_irq_restore(flags);
>
> I'm concerned about this.  We've had caches like this (ARM L220) which
> require only one operation to be performed at a time.  In a SMP system,
> that requires a spinlock to prevent one CPU triggering a L2 maintanence
> operation while another CPU tries to operate on the L2 cache.
>
> From the overall series diffstat, I see that you are adding SMP support
> too.  So I have to ask the obvious question: if you need to disable
> local IRQs around the L2 cache operations, what happens if two CPUs
> both try to perform a L2 cache operation concurrently?


This cache controller is able to accept operations from multiple CPUs
at the same time.

Let's assume the following scenario:

CPU0 issues some operation.
Before the cache controller finishes the operation,
CPU1 issues another operation;  this is OK.
The operation is stored in the queue of the cache controller
until the operation under way is completed.
When the operation from CPU0 is finished, the controller starts
the operation from CPU1.

If the queue is full (this unlikely happens though),
the CPU can know by checking UNIPHIER_SSCOPPQSEF register.
This is checked by the code:

unlikely(readl_relaxed(data->op_base + UNIPHIER_SSCOPPQSEF) &
   (UNIPHIER_SSCOPPQSEF_FE | UNIPHIER_SSCOPPQSEF_OE))


The status register (UNIPHIER_SSCOLPQS) has each instance for each CPU.
That means, CPU0 can know if the operation issued by itself is finished or not.
Likewise for CPU1, CPU2, ...

To sum up, the cache controller can nicely handles cache operations in SMP.



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/5] usb: change clock information for chipidea

[Fabio Estevam]

On Sun, Sep 20, 2015 at 9:43 PM, Peter Chen  wrote:
> This patch set changes usb clock information for legacy i.mx platforms.
> At these platforms, they needs three clocks to let controller work.
>
> Hi Fabio,
>
> Would you please have a test at imx27 and imx25 boards, thanks.

Works fine on both boards, thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: bcm2835: Add the auxiliary clocks to the device tree.

[Stephen Warren]

On 09/10/2015 03:22 PM, Eric Anholt wrote:
> These will be used for enabling UART1, SPI1, and SPI2.

Patches 1, 3,
Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.

[Stephen Warren]

On 09/10/2015 03:22 PM, Eric Anholt wrote:
> There are a pair of SPI masters and a mini UART that were last minute
> additions.  As a result, they didn't get integrated in the same way as
> the other gates off of the VPU clock in CPRMAN.

> diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c 
> b/drivers/clk/bcm/clk-bcm2835-aux.c

> +static int bcm2835_aux_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct clk_onecell_data *onecell;
> + const char *parent;
> + struct clk *parent_clk;
> + void __iomem *reg;
> +
> + parent_clk = of_clk_get(dev->of_node, 0);
> + if (IS_ERR(parent_clk))
> + return PTR_ERR(parent_clk);
> + parent = __clk_get_name(parent_clk);

I think all the comments I made on probe() for the main bcm2835 clock
driver likely apply here too.

Also, is it "legal" for clock drivers to use __clk_get_name()? I thought
that was a clock core internal function, but may be wrong. I would have
expected to be able to pass a clock object when registering clocks
rather than a clock name, but oh well.

BTW, I like how this series shows how useful it is for someone with full
knowledge of the HW to come up with the DT bindings for a HW module;
once you know how the HW is actually designed, the correct binding ends
up being a lot easier to come up with, rather than guessing:-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document

[Matt Porter]

On Thu, Sep 10, 2015 at 05:08:50PM +1000, David Gibson wrote:
> On Fri, Aug 28, 2015 at 09:53:06AM -0500, Rob Herring wrote:
> > On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter  wrote:
> > > Add a skeleton DT binding document that serves as the canonical
> > > example for implementing YAML-based DT bindings documentation.
> > > The skeleton binding illustrates use of all fields and variations
> > > described in the dt-binding-format.txt documentation.
> > >
> > > Signed-off-by: Matt Porter 
> > > ---
> > >  Documentation/devicetree/bindings/skeleton.yaml | 98 
> > > +
> > >  1 file changed, 98 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/skeleton.yaml 
> > > b/Documentation/devicetree/bindings/skeleton.yaml
> > > new file mode 100644
> > > index 000..175965f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/skeleton.yaml
> > > @@ -0,0 +1,98 @@
> > > +%YAML 1.2
> > > +---
> > > +id: skel-device
> > > +
> > > +title: Skeleton Device
> > > +
> > > +maintainer:
> > > +  - name: Skeleton Person 
> > 
> > We'd want to tie this into get_maintainers.pl obviously.
> > 
> > > +
> > > +description: >
> > > +  The Skeleton Device binding represents the SK11 device produced by
> > > +  the Skeleton Corporation. The binding can also support compatible
> > > +  clones made by second source vendors.
> > > +
> > > +compatible:
> > > +  - name: "skel,sk11"
> > > +  - name: "faux,fx11"
> > 
> > Is this an OR or AND? We need both.
> 
> Hrm.  So, from the example below it's an OR.  But.. I think the
> considerations here change when you separate out "tag" information as
> I've suggested elsewhere.
> 
> The command AND case, I can think of is where you want both
> "foo,new-model-device" and "foo,old-model-device".  I think the first
> belongs in the "tag", but the second in the body of the requirements.
> 
> The OR case demonstrated here strikes me as very poor binding design -
> but that doesn't mean we can totally avoid it, since we do have poor
> bindings we want to convert.
> 
> Fwiw, I think the right way to encode "OR" at least in the "tag" is to
> pick just the preferred form, then have additional bindings tagged on
> the alternative forms and inheriting the main binding.  I don't know
> if that's practical in the short term though.

I reworked this as a constraint key with C-like syntax to express
allowable compatible strings. It's got some warts but let's take
a look at v2 and see if good constraint syntax can handle all these
cases. I use some macro like constructs to denote a generic compatible
string that must be included in addition to the part-specific string.

> 
> > The complicated case is "one of {specific names} followed by {generic 
> > name}."
> > 
> > > +description: A clone of the original sk11 device
> > > +
> > > +required:
> > > +  - name: "reg"
> > 
> > We definitely need type info from the start.
> 
> It's interesting you should mention that here, because 'reg' is
> actually a hard case for describint the type: because it's format is
> determined as much by the parent bus binding as this node's binding.
> 
> I suspect it will be worth special-casing "reg" in order to make
> common bindings more compact, but again, probably not in the first
> pass.

I've added type in v2 and in comments note the "reg" is indeed a
special case and derived not so much from the inherited binding but
from the actual parent node as used in an implementation.

> 
> > > +description: chip select address of skeleton device
> > > +reference: spi-slave
> > 
> > I would like to not have to list properties if the inherited binding
> > lists it. The problem is we need to say how many cells and the order
> > (not a problem here, but for mmio devices).
> > 
> > Perhaps we can list the reference at the top level for the node
> > instead of for every property.
> 
> Yeah, I think it would be worth having a top-level "inherits" field.
 
Added in v2

> > > +  - name: "spi-max-frequency"
> > > +description: >
> > > +  Maximum SPI clocking speed of skeleton device in Hz, must be
> > > +  100
> > > +reference: spi-slave
> > 
> > Rather than listing the property and having constraint in description,
> > perhaps we could add constraints like this:
> > 
> > - spi-max-frequency-range: 100 100
> > 
> > Or groups of constraints:
> > 
> > - spi-max-frequency-constraints:
> >   range: 100 100
> >   some-other-constraint: 
> 
> Not for the first pass I think.  What I would suggest is having
> "description" for pure informational stuff, and "constraint" or maybe
> just "extra" for normative constraints expressed in English.
> 
> The idea here is that over time we can add new ways of expressing
> constraints.  In the meantime tools can use the "extra" field to
> preseve any difficult text in the current 

Re: [RFC PATCH 1/5] Documentation: dt-bindings: add documentation on new DT binding format

[Matt Porter]

On Tue, Sep 01, 2015 at 09:59:14AM -0700, Tim Bird wrote:
> On Thu, Aug 27, 2015 at 10:23 PM, Matt Porter  wrote:
> > Documentation explaining the syntax and format of the YAML-based DT binding
> > documentation.
> >
> > Signed-off-by: Matt Porter 
> > ---
> >  .../devicetree/bindings/dt-binding-format.txt  | 106 
> > +
> >  1 file changed, 106 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt
> >
> > diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt 
> > b/Documentation/devicetree/bindings/dt-binding-format.txt
> > new file mode 100644
> > index 000..f9acc22
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dt-binding-format.txt
> > @@ -0,0 +1,106 @@
> > +--
> > +Device Tree Binding Format
> > +--
> > +
> > +Background
> > +--
> > +
> > +DT bindings historically were written as text in prose format which
> > +led to issues in usability of that source documentation. Some of
> > +these issues include the need to programmatically process binding
> > +source documentation to do DTS validation, perform mass updates to
> > +format/style, and to generate publishable documentation in HTML or
> > +PDF form.
> > +
> > +Overview
> > +
> > +
> > +The DT binding format is based on the YAML text markup language.
> > +Although there are many text markup options available, YAML
> > +fulfills all requirements considered for a DT binding source format
> > +which include:
> > +
> > +1) Must be human readable
> > +2) Must be easily translated to other data formats (XML, JSON, etc).
> > +3) Must have sufficient tools and libraries to enable developers to
> > +   build new tools for DT binding processing
> > +4) Must have a complete spec to refer to syntax
> > +
> > +YAML is documentated in the specification found at
> > +http://www.yaml.org/spec/1.2/spec.html
> > +
> > +The required YAML DT binding tag format and syntax are defined in
> > +the following sections.
> > +
> > +YAML DT Binding Syntax
> > +--
> > +
> > +* Lines starting with "#" are comments and not part of the binding itself
> > +* "%YAML 1.2" starts a file, indicating the version of YAML in use
> 
> I think it would be good to specify a DT Binding Format version as well.
> I would expect we may expand the syntax, or we may alter it, so it
> would be good to have a number for our specific syntax.  This would
> help in some circumstances, if we make multiple passes over the
> documents to achieve our conversion.  Maybe this should be added
> below.

Added this in v2, thanks.

> 
> > +* "---" starts a binding document
> > +* "..." ends a binding document
> > +* Multiple binding documents may exist in a single file
> > +* Tabs are not permitted
> > +* Scope is denoted by indentation of two spaces
> > +* Key value pairs are denoted by "key: value"
> > +* Sequences are denoted by "- "
> > +* Scalar values may convert newlines to spaces and preserve blank
> > +  lines for long description formatting using ">"
> > +* Scalar values may escape all reserved characters and preserve
> > +  newlines by using "|" to denote literal style
> > +
> > +For additional information on YAML syntax, refer to the specification
> > +at http://www.yaml.org/spec/1.2/spec.html
> > +
> > +YAML DT Binding Format
> > +--
> > +
> > +The following YAML types are supported in the DT binding format:
> > +
> 
> Based on my comment above, I recommend:
> [R] binding-format: 1
> 
> > +* [R] id: unique identifier in property form (e.g. skel-device)
> > +
> > +* [R] title: title of the binding
> > +
> > +* [O] maintainer: sequence of maintainers
> > +  [R] name: name and email of maintainer or mailing list in RFC822
> > +form.
> > +
> > +* [O] description: full description of the binding
> > +
> > +* [O] compatible: sequence of valid compatible descriptors
> > +  [R] name: the compatible string surrounded in double quotes
> > +  [O] deprecated: a deprecated compatible string surrounded in
> > +  double quotes
> > +  [O] description: description of the compatible string
> 
> compatible is a property like all the others, and I think it's confusing
> to have it in a separate section.  For example, when listing other
> properties, the "name:" field specifies the property name, but for
> the compatible section the "name:" field specifies the possible values
> for the compatible property.  This is (at least to me) quite confusing.
> 
> Can we make this a regular property, with an option 'deprecated' attribute.
> I guess we may need to distinguish between deprecated properties and
> deprecated vales of properties.
> The above 'deprecated' specifies deprecated values for the compatible
> property, while
> the section below specifies deprecated properties.  I don't see a way
> to indicate a deprecated
> value for a 

[net-next PATCH 0/4] Add support for reading macid when DT macid not found

[Mugunthan V N]

Did a boot test on dra7-evm [1] and am437x-gp-evm [2].
Pushed a branch [3] for others to test the patch.

[1]: http://pastebin.ubuntu.com/12513420/
[2]: http://pastebin.ubuntu.com/12513428/
[3]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-macid-read-support

Mugunthan V N (4):
  drivers: net: cpsw: davinci_emac: move reading mac id to common file
  drivers: net: cpsw-common: add support for reading mac address for
dra7 and am437x platforms
  arm: dts: dra7: add syscon phandle to cpsw node
  arm: dts: am4372: add syscon phandle to cpsw node

 arch/arm/boot/dts/am4372.dtsi  |  1 +
 arch/arm/boot/dts/dra7.dtsi|  1 +
 drivers/net/ethernet/ti/cpsw-common.c  | 64 +-
 drivers/net/ethernet/ti/cpsw.c | 11 +++---
 drivers/net/ethernet/ti/cpsw.h |  3 +-
 drivers/net/ethernet/ti/davinci_emac.c | 44 ++-
 6 files changed, 65 insertions(+), 59 deletions(-)

-- 
2.6.0.rc2.10.gf4d9753

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

Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods

[Geert Uytterhoeven]

Hi Pantelis,

On Mon, Sep 21, 2015 at 2:49 PM, Pantelis Antoniou
 wrote:
>> On Sep 21, 2015, at 15:47 , Geert Uytterhoeven  wrote:
>> On Mon, Sep 21, 2015 at 2:36 PM, Pantelis Antoniou
>>  wrote:
 On Sep 21, 2015, at 15:35 , Geert Uytterhoeven  
 wrote:
 On Wed, Sep 16, 2015 at 6:11 PM, Pantelis Antoniou
  wrote:
> Changesets are very powerful, but the lack of a helper API
> makes using them cumbersome. Introduce a simple copy based
> API that makes things considerably easier.
>
> To wit, adding a property using the raw API.
>
>   struct property *prop;
>   prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>   prop->name = kstrdup("compatible");
>   prop->value = kstrdup("foo,bar");
>   prop->length = strlen(prop->value) + 1;
>   of_changeset_add_property(ocs, np, prop);
>
> while using the helper API
>
>   of_changeset_add_property_string(ocs, np, "compatible",
>   "foo,bar");

 What about removing properties?
>>>
>>> Once upon a time there was that capability. It was removed after we didn’t 
>>> have
>>> a good use for them yet. Do you have any? I’d be happy to re-add it :)
>>
>> Aliases?
>>
>> If an overlay removes e.g. a serial port, it should remove its alias, too.
>
> Well, that case is handled. Addition of a property results in removal of a 
> property when
> the overlay is reverted.

Actually what I meant is the other way around: _adding_ the overlay would
_remove_ the alias.

I have a board with an SDHI connector, and an expansion connector.
SDHI and serial on the expansion connector share the same pins.
By default, SDHI is enabled in the DTS.

To add a serial port to the expansion connector, I disable the SDHI device,
add the alias, and add the serial device.
(dtsi in http://www.spinics.net/lists/devicetree/msg79438.html)

Now imagine doing the opposite: having the serial device enabled by default.
Then the overlay should disable the serial device, remove the alias, and add
the SDHI device.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/4] Documentation: bindings: mfd: cros ec: document vbc EC property

[Emilio López]

Some EC implementations include a small nvram space used to store
verified boot context data. This boolean property lets us indicate
whether this space is available or not on a specific EC implementation.

Signed-off-by: Emilio López 
---

Patch is new in v3, split from 3/4

 Documentation/devicetree/bindings/mfd/cros-ec.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt 
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
index 1777916..136e0c2 100644
--- a/Documentation/devicetree/bindings/mfd/cros-ec.txt
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -34,6 +34,10 @@ Required properties (LPC):
 - compatible: "google,cros-ec-lpc"
 - reg: List of (IO address, size) pairs defining the interface uses
 
+Optional properties (all):
+- google,has-vbc-nvram: Some implementations of the EC include a small
+  nvram space used to store verified boot context data. This boolean flag
+  is used to specify whether this nvram is present or not.
 
 Example for I2C:
 
-- 
2.1.4

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

[PATCH v3 3/4] platform/chrome: Support reading/writing the vboot context

[Emilio López]

Some EC implementations include a small nvram space used to store
verified boot context data. This patch offers a way to expose this
data to userspace.

Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Emilio López 
---

Changes from v1:
 - Use is_bin_visible instead of is_visible

Changes from v2:
 - Changes suggested by Javier (makefile, size checks, etc)
 - Add his reviewed-by

 drivers/platform/chrome/Makefile  |   3 +-
 drivers/platform/chrome/cros_ec_dev.c |   1 +
 drivers/platform/chrome/cros_ec_vbc.c | 137 ++
 include/linux/mfd/cros_ec.h   |   1 +
 4 files changed, 141 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/chrome/cros_ec_vbc.c

diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 4a11b01..bc498bd 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,7 +1,8 @@
 
 obj-$(CONFIG_CHROMEOS_LAPTOP)  += chromeos_laptop.o
 obj-$(CONFIG_CHROMEOS_PSTORE)  += chromeos_pstore.o
-cros_ec_devs-objs   := cros_ec_dev.o cros_ec_sysfs.o 
cros_ec_lightbar.o
+cros_ec_devs-objs  := cros_ec_dev.o cros_ec_sysfs.o \
+  cros_ec_lightbar.o cros_ec_vbc.o
 obj-$(CONFIG_CROS_EC_CHARDEV)   += cros_ec_devs.o
 obj-$(CONFIG_CROS_EC_LPC)   += cros_ec_lpc.o
 obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
diff --git a/drivers/platform/chrome/cros_ec_dev.c 
b/drivers/platform/chrome/cros_ec_dev.c
index e8fcdc2..d19263f 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -32,6 +32,7 @@ static int ec_major;
 static const struct attribute_group *cros_ec_groups[] = {
_ec_attr_group,
_ec_lightbar_attr_group,
+   _ec_vbc_attr_group,
NULL,
 };
 
diff --git a/drivers/platform/chrome/cros_ec_vbc.c 
b/drivers/platform/chrome/cros_ec_vbc.c
new file mode 100644
index 000..564a0d0
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_vbc.c
@@ -0,0 +1,137 @@
+/*
+ * cros_ec_vbc - Expose the vboot context nvram to userspace
+ *
+ * Copyright (C) 2015 Collabora Ltd.
+ *
+ * based on vendor driver,
+ *
+ * Copyright (C) 2012 The Chromium OS Authors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static ssize_t vboot_context_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *att, char *buf,
+ loff_t pos, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct cros_ec_dev *ec = container_of(dev, struct cros_ec_dev,
+ class_dev);
+   struct cros_ec_device *ecdev = ec->ec_dev;
+   struct ec_params_vbnvcontext *params;
+   struct cros_ec_command *msg;
+   int err;
+   const size_t para_sz = sizeof(params->op);
+   const size_t resp_sz = sizeof(struct ec_response_vbnvcontext);
+   const size_t payload = max(para_sz, resp_sz);
+
+   msg = kmalloc(sizeof(*msg) + payload, GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+
+   /* NB: we only kmalloc()ated enough space for the op field */
+   params = (struct ec_params_vbnvcontext *)msg->data;
+   params->op = EC_VBNV_CONTEXT_OP_READ;
+
+   msg->version = EC_VER_VBNV_CONTEXT;
+   msg->command = EC_CMD_VBNV_CONTEXT;
+   msg->outsize = para_sz;
+   msg->insize = resp_sz;
+
+   err = cros_ec_cmd_xfer(ecdev, msg);
+   if (err < 0) {
+   dev_err(dev, "Error sending read request: %d\n", err);
+   kfree(msg);
+   return err;
+   }
+
+   memcpy(buf, msg->data, resp_sz);
+
+   kfree(msg);
+   return resp_sz;
+}
+
+static ssize_t vboot_context_write(struct file *filp, struct kobject *kobj,
+  struct bin_attribute *attr, char *buf,
+  loff_t pos, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct cros_ec_dev *ec = container_of(dev, struct cros_ec_dev,
+ class_dev);
+   struct cros_ec_device *ecdev = ec->ec_dev;
+   struct ec_params_vbnvcontext *params;
+   struct cros_ec_command *msg;
+   int err;
+   const size_t para_sz = sizeof(*params);
+   const size_t data_sz = 

[PATCH v3 4/4] ARM: dts: Enable EC vboot context support on Peach boards

[Emilio López]

The Peach boards use the EC to store the vboot context information,
so add the corresponding properties on the EC node to indicate so.

Reviewed-by: Krzysztof Kozlowski 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Emilio López 
---

Changes from v1:
 - none

Changes from v2:
 - collect tags from Krzysztof & Javier

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..ac02fb4 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -935,6 +935,7 @@
pinctrl-0 = <_spi_cs _irq>;
reg = <0>;
spi-max-frequency = <3125000>;
+   google,has-vbc-nvram;
 
controller-data {
samsung,spi-feedback-delay = <1>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386..b60dec0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -898,6 +898,7 @@
pinctrl-0 = <_spi_cs _irq>;
reg = <0>;
spi-max-frequency = <3125000>;
+   google,has-vbc-nvram;
 
controller-data {
samsung,spi-feedback-delay = <1>;
-- 
2.1.4

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

Re: [PATCH v2 3/3] gpiolib: Add GPIO initialization

[Markus Pargmann]

On Sun, Aug 30, 2015 at 09:44:46AM +0200, Markus Pargmann wrote:
> This functions adds a way to initialize a GPIO without hogging it.
> 
> Signed-off-by: Markus Pargmann 
> ---
>  Documentation/devicetree/bindings/gpio/gpio.txt | 29 +++--
>  drivers/gpio/gpiolib-of.c   |  9 
>  drivers/gpio/gpiolib.c  | 55 
> -
>  drivers/gpio/gpiolib.h  |  2 +
>  4 files changed, 73 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt 
> b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 5788d5cf1252..55d58983ba43 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -116,29 +116,34 @@ Every GPIO controller node must contain both an empty 
> "gpio-controller"
>  property, and a #gpio-cells integer property, which indicates the number of
>  cells in a gpio-specifier.
>  
> -The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
> -providing automatic GPIO request and configuration as part of the
> -gpio-controller's driver probe function.
> +The GPIO chip may contain GPIO definitions. These define properties for 
> single
> +GPIOs of this controller.
>  
> -Each GPIO hog definition is represented as a child node of the GPIO 
> controller.
> +GPIO hogging is a mechanism providing automatic GPIO request and 
> configuration
> +as part of the gpio-controller's driver probe function.
> +
> +GPIO initialization provides an automatic initialization to known save 
> values.
> +Instead of GPIO hogging the GPIO's value and direction can be modified by 
> other
> +users after it was initialized.
> +
> +Each GPIO definition is represented as a child node of the GPIO controller.
>  Required properties:
> -- gpio-hog:   A property specifying that this child node represent a GPIO 
> hog.
>  - gpios:  Store the GPIO information (id, flags, ...). Shall contain the
> number of cells specified in its parent node (GPIO controller
> node).
> -Only one of the following properties scanned in the order shown below.
> -This means that when multiple properties are present they will be searched
> -in the order presented below and the first match is taken as the intended
> -configuration.
> +
> +Optional properties:
> +- line-name:  The GPIO label name. If not present the node name is used.
> + Only one of gpio-hog and gpio-initval may be specified.
> +- gpio-hog:   A property specifying that this child node represent a GPIO 
> hog.
> +- gpio-initval: This GPIO should be initialized to the specified 
> configuration.

Any feedback on this new DT binding?

Best Regards,

Markus

> + Only one of input, output-low and output-high may be specified:
>  - input:  A property specifying to set the GPIO direction as input.
>  - output-low  A property specifying to set the GPIO direction as output with
> the value low.
>  - output-high A property specifying to set the GPIO direction as output with
> the value high.
>  
> -Optional properties:
> -- line-name:  The GPIO label name. If not present the node name is used.
> -
>  Example of two SOC GPIO banks defined as gpio-controller nodes:
>  
>   qe_pio_a: gpio-controller@1400 {
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index f1fe5123da28..ee00c2c63f57 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -234,6 +234,15 @@ static void of_gpiochip_scan_gpios(struct gpio_chip 
> *chip)
>  
>   if (gpiod_hog(desc, lflags, dflags))
>   continue;
> + } else if (of_property_read_bool(np, "gpio-initval")) {
> + if (!dflags) {
> + dev_warn(chip->dev, "GPIO line %d (%s): no 
> initialization state specified, bailing out\n",
> +  desc_to_gpio(desc), np->name);
> + continue;
> + }
> +
> + if (gpiod_initialize(desc, lflags, dflags))
> + continue;
>   }
>   }
>  }
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index f1559fa72c36..d7aa27a92e82 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -2178,15 +2178,8 @@ struct gpio_desc *__must_check 
> __gpiod_get_index_optional(struct device *dev,
>  }
>  EXPORT_SYMBOL_GPL(__gpiod_get_index_optional);
>  
> -/**
> - * gpiod_hog - Hog the specified GPIO desc given the provided flags
> - * @desc:gpio whose value will be assigned
> - * @lflags:  gpio_lookup_flags - returned from of_find_gpio() or
> - *   of_get_gpio_hog()
> - * @dflags:  gpiod_flags - optional GPIO initialization flags
> - */
> -int gpiod_hog(struct gpio_desc *desc, unsigned long lflags,
> -   enum gpiod_flags dflags)
> +static 

Re: [PATCH 2/5] pinctrl: berlin: add the berlin4ct pinctrl driver

[Jisheng Zhang]

Dear Sebastian,

On Sun, 20 Sep 2015 21:32:37 +0200
Sebastian Hesselbarth  wrote:

> > +   BERLIN_PINCTRL_GROUP("SM_TDO", 0x0, 0x3, 0x12,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "sm_tdo"),
> > +   BERLIN_PINCTRL_FUNCTION(0x1, "sm_gpio2")),
> > +   BERLIN_PINCTRL_GROUP("SM_URT0_TXD", 0x0, 0x3, 0x15,
> > +   BERLIN_PINCTRL_FUNCTION(0x0, "sm_urt0_txd"),  
> 
> Please avoid abbreviating acronyms even more, we can afford the
> few extra bytes.

In the 2nd version, I kept using HW names, for example:

1. "urt0" as the function name,

2. "SM_URT0_TXD" as the pin name (group name)

to keep sync with HW, especially the pin names are the same as HW's, because
that's what HW doc, sch, etc. call them. IMHO, using a different name with HW
is not a good idea, what do you think?

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

Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods

[Geert Uytterhoeven]

Hi Pantelis,

On Wed, Sep 16, 2015 at 6:11 PM, Pantelis Antoniou
 wrote:
> Changesets are very powerful, but the lack of a helper API
> makes using them cumbersome. Introduce a simple copy based
> API that makes things considerably easier.
>
> To wit, adding a property using the raw API.
>
> struct property *prop;
> prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
> prop->name = kstrdup("compatible");
> prop->value = kstrdup("foo,bar");
> prop->length = strlen(prop->value) + 1;
> of_changeset_add_property(ocs, np, prop);
>
> while using the helper API
>
> of_changeset_add_property_string(ocs, np, "compatible",
> "foo,bar");

What about removing properties?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 4/4] arm: dts: am4372: add syscon phandle to cpsw node

[Mugunthan V N]

There are 2 MACIDs stored in the control module of the am4372.
These are read by the cpsw driver if no valid MACID was found
in the devicetree.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 0447c04a..d83ff9c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -591,6 +591,7 @@
cpts_clock_mult = <0x8000>;
cpts_clock_shift = <29>;
ranges;
+   syscon = <_conf>;
 
davinci_mdio: mdio@4a101000 {
compatible = "ti,am4372-mdio","ti,davinci_mdio";
-- 
2.6.0.rc2.10.gf4d9753

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

[net-next PATCH 2/4] drivers: net: cpsw-common: add support for reading mac address for dra7 and am437x platforms

[Mugunthan V N]

Adding support for reading mac address using syscon driver for
dra7 and am437x platforms

Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpsw-common.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw-common.c 
b/drivers/net/ethernet/ti/cpsw-common.c
index c70417c..c08be62 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -87,6 +87,12 @@ int ti_cm_get_macid(struct device *dev, int slave, u8 
*mac_addr)
if (of_device_is_compatible(dev->of_node, "ti,dm816-emac"))
return cpsw_am33xx_cm_get_macid(dev, 0x30, slave, mac_addr);
 
+   if (of_machine_is_compatible("ti,am4372"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
+   if (of_machine_is_compatible("ti,dra7"))
+   return davinci_emac_3517_get_macid(dev, 0x514, slave, mac_addr);
+
dev_err(dev, "incompatible machine/device type for reading mac 
address\n");
return -ENOENT;
 }
-- 
2.6.0.rc2.10.gf4d9753

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

[net-next PATCH 3/4] arm: dts: dra7: add syscon phandle to cpsw node

[Mugunthan V N]

There are 2 MACIDs stored in the control module of the dra7.
These are read by the cpsw driver if no valid MACID was found
in the devicetree.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5d65db9..76c739d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1447,6 +1447,7 @@
 ,
 ;
ranges;
+   syscon = <_conf>;
status = "disabled";
 
davinci_mdio: mdio@48485000 {
-- 
2.6.0.rc2.10.gf4d9753

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

[net-next PATCH 1/4] drivers: net: cpsw: davinci_emac: move reading mac id to common file

[Mugunthan V N]

Moving mac address reading from ethernet driver to common
file for better maintenance and for code reusable.

Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpsw-common.c  | 58 --
 drivers/net/ethernet/ti/cpsw.c | 11 +++
 drivers/net/ethernet/ti/cpsw.h |  3 +-
 drivers/net/ethernet/ti/davinci_emac.c | 44 ++
 4 files changed, 57 insertions(+), 59 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw-common.c 
b/drivers/net/ethernet/ti/cpsw-common.c
index f595094..c70417c 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -19,11 +19,38 @@
 
 #include "cpsw.h"
 
-#define AM33XX_CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
-#define AM33XX_CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
+#define CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
+#define CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
 
-int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, int slave,
-u8 *mac_addr)
+static int davinci_emac_3517_get_macid(struct device *dev, u16 offset,
+  int slave, u8 *mac_addr)
+{
+   u32 macid_lsb;
+   u32 macid_msb;
+   struct regmap *syscon;
+
+   syscon = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
+   if (IS_ERR(syscon)) {
+   if (PTR_ERR(syscon) == -ENODEV)
+   return 0;
+   return PTR_ERR(syscon);
+   }
+
+   regmap_read(syscon, CTRL_MAC_LO_REG(offset, slave), _lsb);
+   regmap_read(syscon, CTRL_MAC_HI_REG(offset, slave), _msb);
+
+   mac_addr[0] = (macid_msb >> 16) & 0xff;
+   mac_addr[1] = (macid_msb >> 8)  & 0xff;
+   mac_addr[2] = macid_msb & 0xff;
+   mac_addr[3] = (macid_lsb >> 16) & 0xff;
+   mac_addr[4] = (macid_lsb >> 8)  & 0xff;
+   mac_addr[5] = macid_lsb & 0xff;
+
+   return 0;
+}
+
+static int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, int slave,
+   u8 *mac_addr)
 {
u32 macid_lo;
u32 macid_hi;
@@ -36,10 +63,8 @@ int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, 
int slave,
return PTR_ERR(syscon);
}
 
-   regmap_read(syscon, AM33XX_CTRL_MAC_LO_REG(offset, slave),
-   _lo);
-   regmap_read(syscon, AM33XX_CTRL_MAC_HI_REG(offset, slave),
-   _hi);
+   regmap_read(syscon, CTRL_MAC_LO_REG(offset, slave), _lo);
+   regmap_read(syscon, CTRL_MAC_HI_REG(offset, slave), _hi);
 
mac_addr[5] = (macid_lo >> 8) & 0xff;
mac_addr[4] = macid_lo & 0xff;
@@ -50,6 +75,21 @@ int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, 
int slave,
 
return 0;
 }
-EXPORT_SYMBOL_GPL(cpsw_am33xx_cm_get_macid);
+
+int ti_cm_get_macid(struct device *dev, int slave, u8 *mac_addr)
+{
+   if (of_machine_is_compatible("ti,am33xx"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
+   if (of_device_is_compatible(dev->of_node, "ti,am3517-emac"))
+   return davinci_emac_3517_get_macid(dev, 0x110, slave, mac_addr);
+
+   if (of_device_is_compatible(dev->of_node, "ti,dm816-emac"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x30, slave, mac_addr);
+
+   dev_err(dev, "incompatible machine/device type for reading mac 
address\n");
+   return -ENOENT;
+}
+EXPORT_SYMBOL_GPL(ti_cm_get_macid);
 
 MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c670317..75584cc 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2058,13 +2058,10 @@ no_phy_slave:
if (mac_addr) {
memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
} else {
-   if (of_machine_is_compatible("ti,am33xx")) {
-   ret = cpsw_am33xx_cm_get_macid(>dev,
-   0x630, i,
-   slave_data->mac_addr);
-   if (ret)
-   return ret;
-   }
+   ret = ti_cm_get_macid(>dev, i,
+ slave_data->mac_addr);
+   if (ret)
+   return ret;
}
if (data->dual_emac) {
if (of_property_read_u32(slave_node, 
"dual_emac_res_vlan",
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index ca90efa..442a703 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -41,7 +41,6 @@ struct cpsw_platform_data {
 };
 
 void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave);
-int 

[PATCH v3 0/4] platform/chrome: vboot context support

[Emilio López]

Hi everyone,

This series adds support for reading and writing the verified boot context
nvram space on the EC using the cros_ec sysfs interface.

The first patch improves is_visible() functionality, making it work
for binary attributes as well as normal ones. This is needed so the
sysfs group can be hidden when the EC doesn't offer any space for
the context.

The second patch documents the property used in the binding documents.
This used to live in the next patch on the previous versions of this series.

The third patch is the actual code implementing the interface to read
and write the context data.

The fourth patch adds the DT properties on peach boards which, judging by
the vendor tree, use the EC to store the verified boot context.

The series was tested on a peach pi and was found to work OK there. As
always, all comments and further tests are welcome :)

Cheers!
Emilio

Emilio López (4):
  sysfs: Support is_visible() on binary attributes
  Documentation: bindings: mfd: cros ec: document vbc EC property
  platform/chrome: Support reading/writing the vboot context
  ARM: dts: Enable EC vboot context support on Peach boards

 Documentation/devicetree/bindings/mfd/cros-ec.txt |   4 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts|   1 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   1 +
 drivers/platform/chrome/Makefile  |   3 +-
 drivers/platform/chrome/cros_ec_dev.c |   1 +
 drivers/platform/chrome/cros_ec_vbc.c | 137 ++
 fs/sysfs/group.c  |  17 ++-
 include/linux/mfd/cros_ec.h   |   1 +
 include/linux/sysfs.h |  18 ++-
 9 files changed, 176 insertions(+), 7 deletions(-)
 create mode 100644 drivers/platform/chrome/cros_ec_vbc.c

-- 
2.1.4

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

[PATCH 1/4] sysfs: Support is_visible() on binary attributes

[Emilio López]

According to the sysfs header file:

"The returned value will replace static permissions defined in
 struct attribute or struct bin_attribute."

but this isn't the case, as is_visible is only called on struct attribute
only. This patch introduces a new is_bin_visible() function to implement
the same functionality for binary attributes, and updates documentation
accordingly.

Note that to keep functionality and code similar to that of normal
attributes, the mode is now checked as well to ensure it contains only
read/write permissions or SYSFS_PREALLOC.

Reviewed-by: Guenter Roeck 
Signed-off-by: Emilio López 
---

Changes from v1:
 - Don't overload is_visible, introduce is_bin_visible instead as
   discussed on the list.

Changes from v2:
 - Note change in mode checking on the commit log
 - Add Guenter's reviewed-by

 fs/sysfs/group.c  | 17 +++--
 include/linux/sysfs.h | 18 ++
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 39a0199..51b56e6 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -73,13 +73,26 @@ static int create_files(struct kernfs_node *parent, struct 
kobject *kobj,
}
 
if (grp->bin_attrs) {
-   for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
+   for (i = 0, bin_attr = grp->bin_attrs; *bin_attr; i++, 
bin_attr++) {
+   umode_t mode = (*bin_attr)->attr.mode;
+
if (update)
kernfs_remove_by_name(parent,
(*bin_attr)->attr.name);
+   if (grp->is_bin_visible) {
+   mode = grp->is_bin_visible(kobj, *bin_attr, i);
+   if (!mode)
+   continue;
+   }
+
+   WARN(mode & ~(SYSFS_PREALLOC | 0664),
+"Attribute %s: Invalid permissions 0%o\n",
+(*bin_attr)->attr.name, mode);
+
+   mode &= SYSFS_PREALLOC | 0664;
error = sysfs_add_file_mode_ns(parent,
&(*bin_attr)->attr, true,
-   (*bin_attr)->attr.mode, NULL);
+   mode, NULL);
if (error)
break;
}
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9f65758..2f66050 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -64,10 +64,18 @@ do {
\
  * a new subdirectory with this name.
  * @is_visible:Optional: Function to return permissions associated 
with an
  * attribute of the group. Will be called repeatedly for each
- * attribute in the group. Only read/write permissions as well as
- * SYSFS_PREALLOC are accepted. Must return 0 if an attribute is
- * not visible. The returned value will replace static permissions
- * defined in struct attribute or struct bin_attribute.
+ * non-binary attribute in the group. Only read/write
+ * permissions as well as SYSFS_PREALLOC are accepted. Must
+ * return 0 if an attribute is not visible. The returned value
+ * will replace static permissions defined in struct attribute.
+ * @is_bin_visible:
+ * Optional: Function to return permissions associated with a
+ * binary attribute of the group. Will be called repeatedly
+ * for each binary attribute in the group. Only read/write
+ * permissions as well as SYSFS_PREALLOC are accepted. Must
+ * return 0 if a binary attribute is not visible. The returned
+ * value will replace static permissions defined in
+ * struct bin_attribute.
  * @attrs: Pointer to NULL terminated list of attributes.
  * @bin_attrs: Pointer to NULL terminated list of binary attributes.
  * Either attrs or bin_attrs or both must be provided.
@@ -76,6 +84,8 @@ struct attribute_group {
const char  *name;
umode_t (*is_visible)(struct kobject *,
  struct attribute *, int);
+   umode_t (*is_bin_visible)(struct kobject *,
+ struct bin_attribute *, int);
struct attribute**attrs;
struct bin_attribute**bin_attrs;
 };
-- 
2.1.4

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

Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods

[Geert Uytterhoeven]

Hi Pantelis,

On Mon, Sep 21, 2015 at 2:36 PM, Pantelis Antoniou
 wrote:
>> On Sep 21, 2015, at 15:35 , Geert Uytterhoeven  wrote:
>> On Wed, Sep 16, 2015 at 6:11 PM, Pantelis Antoniou
>>  wrote:
>>> Changesets are very powerful, but the lack of a helper API
>>> makes using them cumbersome. Introduce a simple copy based
>>> API that makes things considerably easier.
>>>
>>> To wit, adding a property using the raw API.
>>>
>>>struct property *prop;
>>>prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>>>prop->name = kstrdup("compatible");
>>>prop->value = kstrdup("foo,bar");
>>>prop->length = strlen(prop->value) + 1;
>>>of_changeset_add_property(ocs, np, prop);
>>>
>>> while using the helper API
>>>
>>>of_changeset_add_property_string(ocs, np, "compatible",
>>>"foo,bar");
>>
>> What about removing properties?
>
> Once upon a time there was that capability. It was removed after we didn’t 
> have
> a good use for them yet. Do you have any? I’d be happy to re-add it :)

Aliases?

If an overlay removes e.g. a serial port, it should remove its alias, too.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Jyri Sarha]

On 09/21/15 12:31, Russell King - ARM Linux wrote:

On Sat, Sep 19, 2015 at 10:54:51AM -0700, Mark Brown wrote:

On Fri, Sep 18, 2015 at 02:06:40PM +0300, Jyri Sarha wrote:

+#define SPDIF_FORMATS  (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\
+SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
+SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
+SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE)
+
+#define I2S_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\
+SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE |\
+SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
+SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
+SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\
+SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)


I'm not sure how abstracted this I2S and S/PDIF DAI business is - it
doesn't feel like something that's going to be a property of all HDMI
devices, and the specific sets of formats above cause me to raise a bit
of an eyebrow.  Should this be an interface where the HDMI chip
registers multiple interfaces if it has them instead of automatically
getting this split as is?


The inclusion of the 32-bit formats does raise an eyebrow here too.
Audio transmission across the HDMI link is S/PDIF, supporting up to
24-bit uncompressed audio (aka L-PCM).

The device may accept 32 bit I2S, but it would have to be truncated to
24 bit before transmitting it to the sink.  This should be mentioned
somewhere.



There is ".sig_bits = 24" in hdmi_i2s_dai, but I can add an explicit 
comment about it.


We needed 32bit format in practice until Peter got 24_LE properly 
working with McASP. I just thought the may still be some platforms out 
there that can not produce 24bit i2s samples for some reason, but work 
just fine with 32bit samples. Those platforms would be limited to less 
than 24bit precision without 32bit formats. But as said, it is not 
critical to us any more and I can drop the 32bit formats as well.


BR,
Jyri



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

[PATCH v2 3/6] arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs

[Jisheng Zhang]

This is to add the pinctrl dependency for Marvell Berlin SoCs.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index c6e2c75..3d17ee2 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -9,6 +9,7 @@ config ARCH_BERLIN
bool "Marvell Berlin SoC Family"
select ARCH_REQUIRE_GPIOLIB
select DW_APB_ICTL
+   select PINCTRL
help
  This enables support for Marvell Berlin SoC Family
 
-- 
2.5.3

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

Re: [PATCH linux-next v9 2/3] mfd: devicetree: add bindings for Atmel Flexcom

[Cyrille Pitchen]

Hi Rob,

Le 10/09/2015 02:06, Rob Herring a écrit :
> On 09/09/2015 10:45 AM, Cyrille Pitchen wrote:
>> Hi Rob,
>>
>> Le 09/09/2015 01:40, Rob Herring a écrit :
>>> On 09/01/2015 09:46 AM, Cyrille Pitchen wrote:
 This patch documents the DT bindings for the Atmel Flexcom which will be
 introduced by sama5d2x SoCs. These bindings will be used by the actual
 Flexcom driver to be sent in another patch.

 Signed-off-by: Cyrille Pitchen 
 Acked-by: Boris Brezillon 
 Acked-by: Alexandre Belloni 
>>>
>>> A few comments, but in general looks fine.
>>>
 ---
  .../devicetree/bindings/mfd/atmel-flexcom.txt  | 67 
 ++
  1 file changed, 67 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt

 diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
 b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
 new file mode 100644
 index ..fc3511e41542
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
 @@ -0,0 +1,67 @@
 +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication 
 Unit)
 +
 +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
 +controller and an USART. Only one function can be used at a time and is 
 chosen
 +at boot time according to the device tree.
>>>
>>> Doesn't the board design choose (unless pins go to a header)?
>>>
>>
>> The function may be chosen once for all by the board design but if we take 
>> the
>> sama5d2 xplained board as an example, most Flexcoms output their pins to
>> headers.
>>
 +
 +Required properties:
 +- compatible: Should be "atmel,sama5d2-flexcom"
 +- reg:Should be the offset/length value for Flexcom 
 dedicated
 +  I/O registers (without USART, TWI or SPI registers).
 +- clocks: Should be the Flexcom peripheral clock from PMC.
 +- #address-cells: Should be <1>
 +- #size-cells:Should be <1>
 +- ranges: Should be one range for the full I/O register region
 +  (including USART, TWI and SPI registers).
 +- atmel,flexcom-mode: Should be one of the 3 following macros as 
 defined in
 +  include/dt-bindings/mfd/atmel-flexcom.h:
 +  - ATMEL_FLEXCOM_MODE_USART for USART
 +  - ATMEL_FLEXCOM_MODE_SPI for SPI
 +  - ATMEL_FLEXCOM_MODE_TWI for I2C
 +
 +Required child:
 +a single child device of type matching the "atmel,flexcom-mode" property.
>>>
>>> Okay, but why not allow all children and use "status"?
>>>
>>
>> That is exactly what was proposed in v6 of this series: allow more than one
>> child so possibly all children but only one "available" child (status = 
>> "okay").
>>
>> The Flexocm driver still needs to find out the type of device of this
>> available child to know which function is to be enabled (USART, I2C or SPI).
>> So the "compatible" attribute was parsed using strstr() to search on of the
>> patterns "usart", "spi" or "i2c".
>>
>> However the use of strstr() was discussed to know whether the driver should
>> looks for a partial or an exact match of the "compatible" string.
>> An exact match would require to keep the Flexcom driver synchonized with the
>> 3 other drivers every time one of them introduces a new compatibility string,
>> which whould have made every driver more difficult to maintain by creating a
>> useless dependency.
>> So this implementation relying on the "compatible" attribute was abandoned.
>>
>> To sum up, no other reliable (and simple) means to guess/extact the device
>> type from its DT node was found so we got back to the "atmel,flexcom-mode"
>> property.
> 
> I wasn't thinking removing this property. If the mode is configured by
> the bootloader, then you want to make updates to the configuration as
> simple as possible. Updating atmel,flexcom-mode and status for the
> children would be much more simple than creating the whole child node.
> If that's not a valid usecase, then never mind.
> 
> Rob
> 

The Flexcom driver calls of_platform_populate(), so yes it's allowed and
supported to put the 3 children in the DT as long as only one is available.

Should I update the documentation to deal with optional children or leave it
as it is?

Best Regards,

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

Re: [PATCH v4 0/16] Add Analogix Core Display Port Driver

[Thierry Reding]

On Mon, Sep 21, 2015 at 06:27:40PM +0800, Yakir Yang wrote:
> Hi Thierry,
> 
> Thanks for your suggest :)
> 
> On 09/21/2015 05:15 PM, Thierry Reding wrote:
> >On Mon, Sep 21, 2015 at 04:45:44PM +0800, Yakir Yang wrote:
> >>Hi Heiko,
> >>
> >>On 09/02/2015 10:15 AM, Yakir Yang wrote:
> >>>Hi Heiko,
> >>>
> >>>在 09/02/2015 05:47 AM, Heiko Stuebner 写道:
> Hi Yakir,
> 
> Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang:
> >The Samsung Exynos eDP controller and Rockchip RK3288 eDP
> >controller
> >share the same IP, so a lot of parts can be re-used. I split the common
> >code into bridge directory, then rk3288 and exynos only need to keep
> >some platform code. Cause I can't find the exact IP name of exynos dp
> >controller, so I decide to name dp core driver with "analogix" which I
> >find in rk3288 eDP TRM ;)
> >
> >Beyond that, there are three light registers setting differents bewteen
> >exynos and rk3288.
> >1. RK3288 have five special pll resigters which not indicata in exynos
> >dp controller.
> >2. The address of DP_PHY_PD(dp phy power manager register) are
> >different
> >between rk3288 and exynos.
> >3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
> >debug
> >register).
> >
> >I have verified this series on two kinds of rockchip platform board,
> >one
> >is rk3288 sdk board which connect with a 2K display port monitor, the
> >other
> >is google jerry chromebook which connect with a eDP screen
> >"cnm,n116bgeea2",
> >both of them works rightlly.
> it looks like during the rebase something did go wrong and I found some
> issues
> I mentioned in the replies to individual patches.
> 
> I did prepare a branch based on mainline [0] with both the old and the
> new edp
> driver - rk3288_veyron_defconfig build both drivers into the image.
> 
> While the old driver still works, I wasn't able to make the new one work
> yet
> ... the drm core does find the connector, but not that anything is
> connected
> to it. I'll try to dig deeper tomorrow, but maybe you'll see anything
> interesting before then.
> >>>Many thanks for your comment and debug, I would rebase on your
> >>>"edp-with-veyron" branch and fix the broken, make sure v6 would
> >>>work rightly at least in your side and my side.
> >>Just like we talk off line, I guess there are two tricky questions which
> >>make analogix_dp just crash/failed on rockchip platform:
> >>
> >>-  One is how to reach a agreement with the common way to register
> >>connector. There would be a conflict with Exynos & IMX & Rockchip.
> >>  On analogix_dp thread, Exynos want to register connector when that
> >>connector is ready.
> >>  On dw_hdmi thread, IMX want to register connector when all component 
> >> is
> >>already.
> >>  So Exynos & IMX & Rockchip should reach a common way to register
> >>connector to fix this issue.
> >>
> >>-  The other is atomic API.
> >>   The rockchip drm haven't implemented the atomic API, but the original
> >>exynos_dp have used the atomic API on connector helper function. That's why
> >>analogix_dp just keep crash on your side.
> >There's really no reason not to convert Rockchip to atomic. It will have
> >to happen eventually anyway.
> 
> Do agree on this point, and I see Tomasz Figa have done some WIP
> works on implementing the atomic_commit, maybe would upstream
> in further.(https://chromium-review.googlesource.com/#/c/284560/1)
> 
> 
> >That said, there's another option that would allow you to side-step both
> >of the above problems at the same time. If you turn the common code into
> >a helper library that should give you enough flexibility to integrate it
> >into all existing users. For example you could leave out the connector
> >registration and let the drivers do that. Similarly since the helpers
> >are only hooked up at registration time you could probably find a way to
> >share the low-level code but again leave it up to the drivers to glue it
> >all together at registration time (drivers could wrap the low-level code
> >with atomic or non-atomic callbacks).
> 
> Wow, sounds good, but I'm not sure I understand this rightly. Do you
> mean that I could support two kinds of callbacks in analogix_dp_core
> driver, and export them out. And move the connector registration code
> into the helper driver (like exynos_dp.c), so helper driver could chose to
> use the atomic or non-atomic callbacks. like:
> 
> -- analogix_dp_core.c
> 
> ...
> struct drm_connector_funcs analogix_dp_connector_atomic_funcs = {
> .dpms = drm_atomic_helper_connector_dpms,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .detect = analogix_dp_detect,
> .destroy = analogix_dp_connector_destroy,
> .reset = 

Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods

[Pantelis Antoniou]

Hi Geert,

> On Sep 21, 2015, at 15:35 , Geert Uytterhoeven  wrote:
> 
> Hi Pantelis,
> 
> On Wed, Sep 16, 2015 at 6:11 PM, Pantelis Antoniou
>  wrote:
>> Changesets are very powerful, but the lack of a helper API
>> makes using them cumbersome. Introduce a simple copy based
>> API that makes things considerably easier.
>> 
>> To wit, adding a property using the raw API.
>> 
>>struct property *prop;
>>prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>>prop->name = kstrdup("compatible");
>>prop->value = kstrdup("foo,bar");
>>prop->length = strlen(prop->value) + 1;
>>of_changeset_add_property(ocs, np, prop);
>> 
>> while using the helper API
>> 
>>of_changeset_add_property_string(ocs, np, "compatible",
>>"foo,bar");
> 
> What about removing properties?
> 

Once upon a time there was that capability. It was removed after we didn’t have
a good use for them yet. Do you have any? I’d be happy to re-add it :)


> Gr{oetje,eeting}s,
> 
>Geert
> 

Regards

— Pantelis

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

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

[PATCH v2 0/6] arm64: berlin: add pinctrl support

[Jisheng Zhang]

This series adds support for Marvell berlin4ct pin-controller, allowing
to configure the pin muxing from the device tree.

Since v1:
 - use generic name for pin functions
 - a new commit to add pinmux for uart0
 - correct pinctrl usage in dts

Jisheng Zhang (6):
  pinctrl: berlin: regmap as an extra argument of berlin_pinctrl_probe()
  pinctrl: berlin: add the berlin4ct pinctrl driver
  arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs
  pinctrl: dt-binding: document berlin4ct SoC pinctrl
  arm64: dts: berlin4ct: add the pinctrl node
  arm64: dts: berlin4ct: add default pinmux for uart0

 .../devicetree/bindings/pinctrl/berlin,pinctrl.txt |   5 +-
 arch/arm64/Kconfig.platforms   |   1 +
 arch/arm64/boot/dts/marvell/berlin4ct.dtsi |  22 +
 drivers/pinctrl/berlin/Kconfig |   5 +
 drivers/pinctrl/berlin/Makefile|   1 +
 drivers/pinctrl/berlin/berlin-bg2.c|  10 +-
 drivers/pinctrl/berlin/berlin-bg2cd.c  |  10 +-
 drivers/pinctrl/berlin/berlin-bg2q.c   |  10 +-
 drivers/pinctrl/berlin/berlin.c|   9 +-
 drivers/pinctrl/berlin/berlin.h|   1 +
 drivers/pinctrl/berlin/berlin4ct.c | 503 +
 11 files changed, 565 insertions(+), 12 deletions(-)
 create mode 100644 drivers/pinctrl/berlin/berlin4ct.c

-- 
2.5.3

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

[PATCH v2 4/6] pinctrl: dt-binding: document berlin4ct SoC pinctrl

[Jisheng Zhang]

Add berlin4ct to existing berlin pinctrl device tree binding.

Signed-off-by: Jisheng Zhang 
---
 Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
index a8bb5e2..0580860 100644
--- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
@@ -20,7 +20,10 @@ Required properties:
"marvell,berlin2cd-soc-pinctrl",
"marvell,berlin2cd-system-pinctrl",
"marvell,berlin2q-soc-pinctrl",
-   "marvell,berlin2q-system-pinctrl"
+   "marvell,berlin2q-system-pinctrl",
+   "marvell,berlin4ct-avio-pinctrl",
+   "marvell,berlin4ct-sm-pinctrl",
+   "marvell,berlin4ct-soc-pinctrl"
 
 Required subnode-properties:
 - groups: a list of strings describing the group names.
-- 
2.5.3

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

RE: [PATCH 2/3] ASoC: da7219: Add bindings documentation for DA7219 audio codec

[Opensource [Adam Thomson]]

On September 19, 2015 18:10, Mark Brown wrote:

> > +- dlg,io-lvl : Expected voltage level range for digital IO
> > +   ["2.5V_3.6V", "1.2V_2.8V"]
> 
> If the driver needs to read or set the voltage a supply is at it should
> do that via the regulator API.

This would just be a read for the driver. However it's a fair point, so I'll
look to add passing of the regulator information for VDDIO, so i can set this
based on read voltage.

> 
> > +- dlg,cp-mchange : Charge pump voltage tracking mode
> > +   ["largest_vol", "dac_vol", "sig_mag"]
> > +- dlg,cp-vol-thresh : Charge pump volume threshold value (6-bit value)
> > +   [ 0 - 0x3F ]
> 
> Why are these in the device tree rather than runtime parameters?
> 

From previous internal discussions, these seemed to be fire and forget
parameters, hence their inclusion in the DT binding, rather than as controls.
Personally didn't see either needing runtime updates.

> > +Child node - 'da7219_aad':
> > +
> > +Required properties:
> > +- interrupt-parent : Specifies the phandle of the interrupt controller to 
> > which
> > +  the IRQs from DA7219 AAD block are delivered to.
> > +- interrupts : IRQ line info for DA7219 AAD block.
> > +  (See 
> > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
> > +   further information relating to interrupt properties)
> 
> Why is this not specified at the device level (the device does not
> appear to support other interrupts)?

Given the way that the driver code was structured, and that the IRQ is only used
for accessory detection, I added it to the child node. The other option would
be to flatten out bindings, and remove the child node. Felt like keeping the
accessory detect items separate though was a sensible approach. What is your
feeling on this?
N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH 1/4] sysfs: Support is_visible() on binary attributes

[Emilio López]

This is v3, even if the subject doesn't say so. This is what happens 
when you forget to use --reroll-count and try to fix it manually :)


Emilio

On 21/09/15 10:38, Emilio López wrote:

According to the sysfs header file:

 "The returned value will replace static permissions defined in
  struct attribute or struct bin_attribute."

but this isn't the case, as is_visible is only called on struct attribute
only. This patch introduces a new is_bin_visible() function to implement
the same functionality for binary attributes, and updates documentation
accordingly.

Note that to keep functionality and code similar to that of normal
attributes, the mode is now checked as well to ensure it contains only
read/write permissions or SYSFS_PREALLOC.

Reviewed-by: Guenter Roeck 
Signed-off-by: Emilio López 
---

Changes from v1:
  - Don't overload is_visible, introduce is_bin_visible instead as
discussed on the list.

Changes from v2:
  - Note change in mode checking on the commit log
  - Add Guenter's reviewed-by

  fs/sysfs/group.c  | 17 +++--
  include/linux/sysfs.h | 18 ++
  2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 39a0199..51b56e6 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -73,13 +73,26 @@ static int create_files(struct kernfs_node *parent, struct 
kobject *kobj,
}

if (grp->bin_attrs) {
-   for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
+   for (i = 0, bin_attr = grp->bin_attrs; *bin_attr; i++, 
bin_attr++) {
+   umode_t mode = (*bin_attr)->attr.mode;
+
if (update)
kernfs_remove_by_name(parent,
(*bin_attr)->attr.name);
+   if (grp->is_bin_visible) {
+   mode = grp->is_bin_visible(kobj, *bin_attr, i);
+   if (!mode)
+   continue;
+   }
+
+   WARN(mode & ~(SYSFS_PREALLOC | 0664),
+"Attribute %s: Invalid permissions 0%o\n",
+(*bin_attr)->attr.name, mode);
+
+   mode &= SYSFS_PREALLOC | 0664;
error = sysfs_add_file_mode_ns(parent,
&(*bin_attr)->attr, true,
-   (*bin_attr)->attr.mode, NULL);
+   mode, NULL);
if (error)
break;
}
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9f65758..2f66050 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -64,10 +64,18 @@ do {
\
   *a new subdirectory with this name.
   * @is_visible:   Optional: Function to return permissions associated 
with an
   *attribute of the group. Will be called repeatedly for each
- * attribute in the group. Only read/write permissions as well as
- * SYSFS_PREALLOC are accepted. Must return 0 if an attribute is
- * not visible. The returned value will replace static permissions
- * defined in struct attribute or struct bin_attribute.
+ * non-binary attribute in the group. Only read/write
+ * permissions as well as SYSFS_PREALLOC are accepted. Must
+ * return 0 if an attribute is not visible. The returned value
+ * will replace static permissions defined in struct attribute.
+ * @is_bin_visible:
+ * Optional: Function to return permissions associated with a
+ * binary attribute of the group. Will be called repeatedly
+ * for each binary attribute in the group. Only read/write
+ * permissions as well as SYSFS_PREALLOC are accepted. Must
+ * return 0 if a binary attribute is not visible. The returned
+ * value will replace static permissions defined in
+ * struct bin_attribute.
   * @attrs:Pointer to NULL terminated list of attributes.
   * @bin_attrs:Pointer to NULL terminated list of binary attributes.
   *Either attrs or bin_attrs or both must be provided.
@@ -76,6 +84,8 @@ struct attribute_group {
const char  *name;
umode_t (*is_visible)(struct kobject *,
  struct attribute *, int);
+   umode_t (*is_bin_visible)(struct kobject *,
+ struct bin_attribute *, int);
struct attribute**attrs;
struct bin_attribute**bin_attrs;
  };


--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH v2 2/3] gpiolib: gpiod_hog remove separate name argument

[Linus Walleij]

On Sun, Aug 30, 2015 at 12:44 AM, Markus Pargmann  wrote:

> The gpio name is now stored in the gpio descriptor, so we can simply use
> that instead of an argument to the function.
>
> Signed-off-by: Markus Pargmann 

Several problems with this patch:

- Does not apply to v4.3-rc1
- Fixed that but noted that it just alters the call to gpiod_hog()
  in of_gpiochip_scan_hogs(), there is a local const char *name that
  should be removed too.
- Looking at of_get_gpio_hog() it is unclear to me that .name
  is set in the gpio_desc as desired. Please check this.

  Crucial code looks like this:

if (name && of_property_read_string(np, "line-name", name))
*name = np->name;

  i.e. is the line-name really propagated to gpiod->name?
  Are you sure you have tested this with a DTS using line-name
  and verified that it propagates properly?

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

Re: [PATCH v2 3/3] gpiolib: Add GPIO initialization

[Linus Walleij]

On Sun, Aug 30, 2015 at 12:44 AM, Markus Pargmann  wrote:

> This functions adds a way to initialize a GPIO without hogging it.
>
> Signed-off-by: Markus Pargmann 

(...)

> -The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
> -providing automatic GPIO request and configuration as part of the
> -gpio-controller's driver probe function.
> +The GPIO chip may contain GPIO definitions. These define properties for 
> single
> +GPIOs of this controller.

Insert text like this:

There are two types of GPIO definitions:

- GPIO hogs are ...

- GPIO initializers are ...

This list form is easier to understand.

> -Each GPIO hog definition is represented as a child node of the GPIO 
> controller.
> +GPIO hogging is a mechanism providing automatic GPIO request and 
> configuration
> +as part of the gpio-controller's driver probe function.
> +
> +GPIO initialization provides an automatic initialization to known save 
> values.
> +Instead of GPIO hogging the GPIO's value and direction can be modified by 
> other
> +users after it was initialized.
> +
> +Each GPIO definition is represented as a child node of the GPIO controller.
>  Required properties:
> -- gpio-hog:   A property specifying that this child node represent a GPIO 
> hog.
>  - gpios:  Store the GPIO information (id, flags, ...). Shall contain the
>   number of cells specified in its parent node (GPIO controller
>   node).
> -Only one of the following properties scanned in the order shown below.
> -This means that when multiple properties are present they will be searched
> -in the order presented below and the first match is taken as the intended
> -configuration.
> +
> +Optional properties:
> +- line-name:  The GPIO label name. If not present the node name is used.
> + Only one of gpio-hog and gpio-initval may be specified.

This is confusing. Instead write: "The two following options are
mutually exclusive. One of them must be specified, but not both."

> +- gpio-hog:   A property specifying that this child node represent a GPIO 
> hog.
> +- gpio-initval: This GPIO should be initialized to the specified 
> configuration.

> + Only one of input, output-low and output-high may be specified:

Insert "Of the following arguments, only one..." (etc)

>  - input:  A property specifying to set the GPIO direction as input.
>  - output-low  A property specifying to set the GPIO direction as output with
>   the value low.
>  - output-high A property specifying to set the GPIO direction as output with
>   the value high.
>
> -Optional properties:
> -- line-name:  The GPIO label name. If not present the node name is used.
> -
>  Example of two SOC GPIO banks defined as gpio-controller nodes:

(...)
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -234,6 +234,15 @@ static void of_gpiochip_scan_gpios(struct gpio_chip 
> *chip)
>
> if (gpiod_hog(desc, lflags, dflags))
> continue;
> +   } else if (of_property_read_bool(np, "gpio-initval")) {
> +   if (!dflags) {
> +   dev_warn(chip->dev, "GPIO line %d (%s): no 
> initialization state specified, bailing out\n",
> +desc_to_gpio(desc), np->name);
> +   continue;
> +   }
> +
> +   if (gpiod_initialize(desc, lflags, dflags))
> +   continue;

We usually do not mix implementations and bindings but it's OK with me.

> }

You need a terminating  else {} - clause to warn if neither of gpio-hog
or gpio-initval is specified.

> -int gpiod_hog(struct gpio_desc *desc, unsigned long lflags,
> - enum gpiod_flags dflags)
> +static int _gpiod_initialize(struct gpio_desc *desc, unsigned long lflags,
> + enum gpiod_flags dflags)

I don't like _underscore functions. Try to find a name that is descriptive
and does not begin with underscore.

What about just gpiod_init()?

> if (status < 0) {
> pr_err("setup of hog GPIO %s (chip %s, offset %d) failed\n",
> -  name, gpiod_to_chip(desc)->label, 
> gpio_chip_hwgpio(desc));
> +  name, gpiod_to_chip(desc)->label,
> +  gpio_chip_hwgpio(desc));

Looks like a random, unrelated code reshuffling. Don't do this.

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

Re: [PATCH v2 4/4] ARM: bcm2835: Switch to using the new clock driver support.

[Stephen Warren]

On 09/10/2015 02:58 PM, Eric Anholt wrote:
> This will give us the ability to set the pixel and HDMI state machine
> clocks for the VC4 KMS driver, change the CPU frequency, and
> potentially gate clocks in the future (once we also write a power
> domain driver).  It also gives the uart an explicit clock reference,
> so that we don't need to change the physical addresses of the old
> fixed clk_bcm2835.c clocks for Raspberry Pi 2 port.
> 
> Two clocks get their frequencies updated as a result of this.  One is
> uart's apb_pclk, which was previously accidentally grabbing the fixed
> uart0_pclk due to the apb_pclk not having clk_register_clkdev()
> called.  The uart doesn't seem to do anything with apb_pclk other than
> make sure it's on, so that appears safe (also, as far as I can see,
> the apb clock is actually the same as the VPU clock).  The other is
> EMMC, which according to the docs was supposed to be in the 50-100Mhz
> range, but it turns out the firmware needed to change to running it at
> the 250Mhz core clock speed to avoid a bug in clock domain crossing.
> 
> Additionally, anything using BCM2835_CLOCK_VPU will now have a correct
> clock rate if the user configures the boot-time core clock speed using
> config.txt.

Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] bcm2835: enable auxiliary uart1

[Stephen Warren]

On 09/14/2015 07:53 AM, Eric Anholt wrote:
> ker...@martin.sperl.org writes:
> 
>> From: Martin Sperl 
>> 
>> The bcm2835 SOC contains an auxiliary uart, which is very close 
>> to the ns16550 with some differences.
>> 
>> The big difference is that the uart HW is not using an internal
>> divider of 16 but 8, which results in an effictive baud-rate
>> being twice the requested baud-rate.
>> 
>> The bcm2835-aux-uart is also special in such that it is
>> enabled/disabled by a gate in the clock, which is managed by the
>> clk-bcm2835-aux clock driver.
>> 
>> there are 2 options: * defining the clock-frequency property in
>> the device tree to 500k instead of 250k, but this keeps the HW
>> block disabled making the uart not work.

Why does this keep the HW block disabled?

>> * defining a clock in the device tree, but this results in a baud
>> rate that is twice the requested baud-rate.
>> 
>> To address this this patch-set introduce a new property in the
>> device tree to define a clock divider other than 16.
>> 
>> This currently just scales the clock by a factor of 16/divider.
>> 
>> Note that the use of fixed-factor-clock has also been proposed as
>> a workarround, but this does not really describe the hw in the
>> device tree so another solution was needed that allows a correct
>> representation of the HW in the device tree.
> 
> I personally lean toward the fixed-factor-clock solution, but could
> go either way.  Serial maintainers, what do you think?

The external fixed-factor-clock solution sounds more like a workaround
than a real fix. It means that the UART driver isn't aware of what's
going on and only "accidentally" works due to some manipulation of the
clock values that it requests. That kind of thing almost always come
back to bite you later.

Rather than adding a DT property to configure the internal clock
divider, it seems best to add a new compatible value to the list it
supports, and have that compatible value set up internal data that
indicates divide-by-16 vs. divide-by-8. After all, the HW isn't 100%
compatible with ns16550, so the DT should not say that it is. While
the clock-divider property this series adds to the DT does solve the
issue, it does not prevent an older piece of SW that predates this
series, and hence which does not implement clock-divider, attempting
to bind to this DT but fail to operate correctly since it doesn't know
about the different divider.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Userspace and Device-Tree

[Linus Walleij]

On Tue, Sep 1, 2015 at 3:19 PM, Chris Read  wrote:

> That sounds quite workable to me.  It might get more complicated
> than I'd prefer, especially if there are more things than GPIOs (such
> as ADCs, DACs, etc.)

What do you mean by this? We have in-kernel support for ADC and
DAC, see drivers/iio/[adc|dac] and these have excellent userspace
interfaces.

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

Re: [PATCH linux-next 1/4] mtd: spi-nor: remove unused read_xfer/write_xfer hooks

[Brian Norris]

On Sat, Sep 19, 2015 at 05:08:55AM +0200, Marek Vasut wrote:
> On Friday, September 18, 2015 at 05:49:25 PM, Cyrille Pitchen wrote:
> > struct spi_nor_xfer_cfg and read_xfer/write_xfer hooks were never used by
> > any driver. Do some cleanup by removing them.
> > 
> > Signed-off-by: Cyrille Pitchen 
> 
> Right, if this will ever be needed, it can be re-added.
> 
> Reviewed-by: Marek Vasut 

Applied this patch to l2-mtd.git. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/4] dt/bindings: bcm2835: spi: add bindings for the bcm2835 auxiliary spi devices

[Stephen Warren]

On 09/11/2015 04:22 AM, ker...@martin.sperl.org wrote:
> From: Martin Sperl 
> 
> This defines the spi1 and spi2 devices in the device-tree.

Patches 1, 3, 4,
Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 3/6] PCI: designware: Add ARM64 support

[Zhou Wang]

Hi Jingoo and Pratyush,

Could you help to review this patch if you have time?

Many Thanks,
Zhou

On 2015/9/15 20:49, Zhou Wang wrote:
> This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
> move related operations to dw_pcie_host_init.
> 
> This patch also try to use of_pci_get_host_bridge_resources for ARM32 and 
> ARM64
> according to the suggestion for Gabriele[1]
> 
> This patch reverts commit f4c55c5a3f7f ("PCI: designware: Program ATU with
> untranslated address") based on 1/6 in this series. we delete *_mod_base in
> pcie-designware. This was discussed in [2]
> 
> I have compiled the driver with multi_v7_defconfig. However, I don't have
> ARM32 PCIe related board to do test. It will be appreciated if someone could
> help to test it.
> 
> Signed-off-by: Zhou Wang 
> Signed-off-by: Gabriele Paoloni 
> Signed-off-by: Arnd Bergmann 
> Tested-by: James Morse 
> Tested-by: Gabriel Fernandez 
> Tested-by: Minghuan Lian 
> 
> [1] http://www.spinics.net/lists/linux-pci/msg42194.html
> [2] http://www.spinics.net/lists/arm-kernel/msg436779.html
> ---
>  drivers/pci/host/pci-dra7xx.c  |  14 +--
>  drivers/pci/host/pci-keystone-dw.c |   2 +-
>  drivers/pci/host/pcie-designware.c | 238 
> -
>  drivers/pci/host/pcie-designware.h |  14 +--
>  4 files changed, 90 insertions(+), 178 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index ebdffa0..b88c248 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -153,15 +153,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
>  {
>   dw_pcie_setup_rc(pp);
>  
> - if (pp->io_mod_base)
> - pp->io_mod_base &= CPU_TO_BUS_ADDR;
> + if (pp->io_base)
> + pp->io_base &= CPU_TO_BUS_ADDR;
>  
> - if (pp->mem_mod_base)
> - pp->mem_mod_base &= CPU_TO_BUS_ADDR;
> + if (pp->mem_base)
> + pp->mem_base &= CPU_TO_BUS_ADDR;
>  
> - if (pp->cfg0_mod_base) {
> - pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
> - pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
> + if (pp->cfg0_base) {
> + pp->cfg0_base &= CPU_TO_BUS_ADDR;
> + pp->cfg1_base &= CPU_TO_BUS_ADDR;
>   }
>  
>   dra7xx_pcie_establish_link(pp);
> diff --git a/drivers/pci/host/pci-keystone-dw.c 
> b/drivers/pci/host/pci-keystone-dw.c
> index e71da99..8062ddb 100644
> --- a/drivers/pci/host/pci-keystone-dw.c
> +++ b/drivers/pci/host/pci-keystone-dw.c
> @@ -322,7 +322,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem 
> *reg_virt)
>  void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
>  {
>   struct pcie_port *pp = _pcie->pp;
> - u32 start = pp->mem.start, end = pp->mem.end;
> + u32 start = pp->mem->start, end = pp->mem->end;
>   int i, tr_size;
>  
>   /* Disable BARs for inbound access */
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index 75338a6..8ef74da 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -11,6 +11,7 @@
>   * published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -69,16 +70,7 @@
>  #define PCIE_ATU_FUNC(x) (((x) & 0x7) << 16)
>  #define PCIE_ATU_UPPER_TARGET0x91C
>  
> -static struct hw_pci dw_pci;
> -
> -static unsigned long global_io_offset;
> -
> -static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
> -{
> - BUG_ON(!sys->private_data);
> -
> - return sys->private_data;
> -}
> +static struct pci_ops dw_pcie_ops;
>  
>  int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
>  {
> @@ -255,7 +247,7 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int 
> irq)
>  static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
>  {
>   int irq, pos0, i;
> - struct pcie_port *pp = sys_to_pcie(msi_desc_to_pci_sysdata(desc));
> + struct pcie_port *pp = (struct pcie_port *) 
> msi_desc_to_pci_sysdata(desc);
>  
>   pos0 = bitmap_find_free_region(pp->msi_irq_in_use, MAX_MSI_IRQS,
>  order_base_2(no_irqs));
> @@ -298,7 +290,7 @@ static int dw_msi_setup_irq(struct msi_controller *chip, 
> struct pci_dev *pdev,
>  {
>   int irq, pos;
>   struct msi_msg msg;
> - struct pcie_port *pp = sys_to_pcie(pdev->bus->sysdata);
> + struct pcie_port *pp = pdev->bus->sysdata;
>  
>   if (desc->msi_attrib.is_msix)
>   return -EINVAL;
> @@ -327,7 +319,7 @@ static void dw_msi_teardown_irq(struct msi_controller 
> *chip, unsigned int irq)
>  {
>   struct irq_data *data = irq_get_irq_data(irq);
>   struct 

Re: [PATCH 1/3] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

[Lee Jones]

On Mon, 21 Sep 2015, Andrew F. Davis wrote:
> On 09/19/2015 11:16 PM, Lee Jones wrote:
> >On Tue, 15 Sep 2015, Andrew F. Davis wrote:
> >
> >>The TPS65912 PMIC contains several regulators and a GPIO controller.
> >>Add bindings for the TPS65912 PMIC.
> >>
> >>Signed-off-by: Andrew F. Davis 
> >>---
> >>  .../devicetree/bindings/gpio/gpio-tps65912.txt | 17 +
> >>  Documentation/devicetree/bindings/mfd/tps65912.txt | 43 
> >> ++
> >>  .../bindings/regulator/tps65912-regulator.txt  | 32 
> >>  3 files changed, 92 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
> >>  create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/regulator/tps65912-regulator.txt

[...]

> >>+Optional nodes:
> >>+ - Regulators: 
> >>Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> >>+ - GPIO: Documentation/devicetree/bindings/gpio/gpio-tps65912.txt.
> >
> >Better to use ../gpio, ../regulator, etc.
> >
> >"Regulators" and "GPIO" aren't valid node names.
> >
> >Please be more specific.
> >
> 
> OK, I'll see if I can clear this up.

[...]

> >>+Optional properties:
> >>+ - Any optional property defined in bindings/regulator/regulator.txt
> >
> >../regulator/...
> >
> 
> Not really sure what you mean here?

Same as above.  Use "../regulator/regulator.txt" instead.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: bcm2835: Add the auxiliary clocks to the device tree.

[Stephen Warren]

On 09/10/2015 03:22 PM, Eric Anholt wrote:
> These will be used for enabling UART1, SPI1, and SPI2.

> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

> + aux_clocks: aux-clocks@0x7e215004 {
> + compatible = "brcm,bcm2835-aux-clock";
> + #clock-cells = <1>;
> + reg = <0x7e215004 0x4>;

Actually, I take back the ack on this patch. This HW module has two
registers. The reg property should include both of those registers so
that if SW needs to start using the other register at some time in the
future, the entire set of registers is already represented in DT.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Userspace and Device-Tree

[Linus Walleij]

On Wed, Sep 2, 2015 at 6:35 AM, Chris Read  wrote:
> On Wed, Sep 2, 2015 at 5:29 AM, Alexandre Courbot  wrote:
>> Since the GPIO sysfs allows you to request any GPIO that is not
>> claimed by a kernel driver from userspace, is there a reason why you
>> cannot simply run board-specific init scripts that request and
>> configure the GPIOs you need? Once GPIO naming is merged, this should
>> be as elegant as it gets for what you want to do.
>
> For many things this is true.  There are some hardware aspects/parameters
> of exporting that aren't controllable from userspace, such as whether or not
> reversing the direction of a GPIO is safe.

The original argument as to why kernel should handle hardware
is to keep things safe and under control.

I don't understand this argument really, should the kernel give you
a gun but stop you from shooting yourself in the foot with it or
what do you mean? Then the stance of kernel not to give out guns
is better.

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

Re: [PATCH v2 3/4] clk: bcm2835: Add support for programming the audio domain clocks.

[Stephen Warren]

On 09/10/2015 02:58 PM, Eric Anholt wrote:
> This adds support for enabling, disabling, and setting the rate of the
> audio domain clocks.  It will be necessary for setting the pixel clock
> for HDMI in the VC4 driver and let us write a cpufreq driver.  It will
> also improve compatibility with user changes to the firmware's
> config.txt, since our previous fixed clocks are unaware of it.
> 
> The firmware also has support for configuring the clocks through the
> mailbox channel, but the pixel clock setup by the firmware doesn't
> work, and it's Raspberry Pi specific anyway.  The only conflicts we
> should have with the firmware would be if we made firmware calls that
> result in clock management (like opening firmware V3D or ISP access,
> which we don't support in upstream), or on hardware over-thermal or
> under-voltage (when the firmware would rewrite PLLB to take the ARM
> out of overclock).  If that happens, our cached .recalc_rate() results
> would be incorrect, but that's no worse than our current state where
> we used fixed clocks.
> 
> The existing fixed clocks in the code are left in place to provide
> backwards compatibility with old device tree files.

> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c

> +/**
> + * DOC: BCM2835 CPRMAN (clock manager for the "audio" domain)
> + *
> + * The clock tree on the 2835 has several levels.  There's a root
> + * oscillator running at 19.2Mhz.  After the oscillator there are 4

Nit: s/4/5.

> +struct bcm2835_pll_data {
...
> + /* Highest rate for the VCO before we have to use the
> +  * pre-divide-by-2.
> +  */

Nit: /* should be on a line on its own I think. Similar elsewhere.

> +static const struct bcm2835_pll_ana_bits bcm2835_ana_default = {
> + 0,
> + 0,
> + ~((7 << 19) | (15 << 15)),
> + (2 << 19) | (8 << 15),
> + ~(7 << 7),
> + (6 << 1),
> +
> + 14

Nit: Elide the blank line? In some other structs too.

Are there #defines or names you can use for those initializers?

> +static int bcm2835_clk_probe(struct platform_device *pdev)

> + cprman = kzalloc(sizeof(*cprman), GFP_KERNEL);
> + if (!cprman)
> + return -ENOMEM;

This function allocates/initializes a lot of resources without using
devm_ versions of APIs.
> +
> + spin_lock_init(>regs_lock);
> + cprman->dev = >dev;
> + cprman->regs = of_iomap(dev->of_node, 0);
> + if (!cprman->regs)
> + return -ENODEV;

.. consequently if probe() fails later on (such as here) then resources
allocated earlier are not released. probe() should either switch to APIs
such as devm_kzalloc() or add some cleanup handling.

> + cprman->osc_name = of_clk_get_parent_name(dev->of_node, 0);
> + if (!cprman->osc_name)
> + return -ENODEV;
> +
> + platform_set_drvdata(pdev, cprman);

I'd expect that to happen right after allocating cprman, since it feels
related to having allocated the cprman object.

> + onecell = kmalloc(sizeof(*onecell), GFP_KERNEL);
> + if (!onecell)
> + return -ENOMEM;
> + onecell->clk_num = BCM2835_CLOCK_COUNT;
> + onecell->clks = kzalloc(sizeof(*onecell->clks) *
> + BCM2835_CLOCK_COUNT, GFP_KERNEL);

Does this need to be dynamically allocated? I think you can just make
these fields in struct bcm2835_cprman; even the array of clks could be:

struct clks clks[BCM2835_CLOCK_COUNT];

> + clks[BCM2835_PLLA] = bcm2835_register_pll(cprman, _plla_data);
> + clks[BCM2835_PLLB] = bcm2835_register_pll(cprman, _pllb_data);

These can fail; shouldn't there be error-checking? Or, does
of_clk_add_provider() check for this?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] clk: bcm2835: Add binding docs for the new platform clock driver.

[Stephen Warren]

On 09/10/2015 02:58 PM, Eric Anholt wrote:
> Previously we've only supported a few fixed clocks based on
> assumptions about how the firmware sets up the clocks, but this
> binding will let us control the actual (audio power domain) clock
> manager.

Patches 1 and 2,
Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 03/22] of/platform: Point to struct device from device node

[Rob Herring]

On Mon, Sep 21, 2015 at 9:02 AM, Tomeu Vizoso
 wrote:
> When adding platform and AMBA devices, set the device node's device
> member to point to it.
>
> This speeds lookups considerably and is safe because we only create one
> of these devices for any given device node.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
> Changes in v5:
> - Set the pointer to struct device also for AMBA devices
> - Unset the pointer to struct device when the platform device is about
>   to be unregistered
> - Increase the reference count of the device before returning from
>   of_find_device_by_node()
>
>  drivers/of/platform.c | 19 ++-
>  include/linux/of.h|  1 +
>  2 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 1001efaedcb8..408d89f1d124 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -32,11 +32,6 @@ const struct of_device_id of_default_bus_match_table[] = {
> {} /* Empty terminated list */
>  };
>
> -static int of_dev_node_match(struct device *dev, void *data)
> -{
> -   return dev->of_node == data;
> -}
> -
>  /**
>   * of_find_device_by_node - Find the platform_device associated with a node
>   * @np: Pointer to device tree node
> @@ -45,10 +40,10 @@ static int of_dev_node_match(struct device *dev, void 
> *data)
>   */
>  struct platform_device *of_find_device_by_node(struct device_node *np)
>  {
> -   struct device *dev;
> -
> -   dev = bus_find_device(_bus_type, NULL, np, 
> of_dev_node_match);
> -   return dev ? to_platform_device(dev) : NULL;
> +   if (np->device && np->device->bus == _bus_type &&
> +   get_device(np->device))

Where do we drop the reference incremented by get_device?

However, bus_find_device also took a reference I think, so you aren't
really changing behavior.

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

Re: [PATCH 3/4] serial: bcm2835: add auxiliary uart1 to device tree of bcm2835

[Stephen Warren]

On 09/11/2015 05:20 AM, ker...@martin.sperl.org wrote:
> From: Martin Sperl 
> 
> Add the auxiliary uart1 device to the device tree of the bcm2835 SOC.

> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

> + uart1: uart@7e215040 {
> + compatible = "ns16550";

compatible should always include a precise HW-specific value; something
like brcm,bcm2835-aux-uart. That way, if we find some other issue that
needs working around on this HW in the future, all DTs will already
contain the compatible value that SW needs in order to trigger that
workaround. That's a generally true statement; i.e. irrespective of
anything else in this series.

I don't believe "ns16550" should be in the compatible value for this
device, since the device cannot be successfully driven by SW that only
knows about a standard 16650 UART. SW must know about the different
divider, and there is no possibility of SW knowing about that before
this series.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mfd: tps65912: Rewrite driver adding DT support and using regmap

[Lee Jones]

On Mon, 21 Sep 2015, Andrew F. Davis wrote:
> On 09/19/2015 11:16 PM, Lee Jones wrote:
> >On Tue, 15 Sep 2015, Andrew F. Davis wrote:
> >
> >>The old driver does not support DT. Rewrite the driver adding DT support
> >>and use modern kernel features such as regmap and related helpers.
> >>
> >>Signed-off-by: Andrew F. Davis 
> >>---
> >>  drivers/gpio/gpio-tps65912.c   | 291 ++--
> >>  drivers/mfd/Kconfig|  20 +-
> >>  drivers/mfd/Makefile   |   3 +-
> >>  drivers/mfd/tps65912-core.c| 288 +---
> >>  drivers/mfd/tps65912-i2c.c | 233 --
> >>  drivers/mfd/tps65912-irq.c | 217 -
> >>  drivers/mfd/tps65912-spi.c | 236 --
> >>  drivers/regulator/tps65912-regulator.c | 783 
> >> ++---
> >>  include/linux/mfd/tps65912.h   | 256 +++
> >>  9 files changed, 854 insertions(+), 1473 deletions(-)
> >>  rewrite drivers/gpio/gpio-tps65912.c (68%)
> >>  rewrite drivers/mfd/tps65912-core.c (96%)
> >>  rewrite drivers/mfd/tps65912-i2c.c (92%)
> >>  delete mode 100644 drivers/mfd/tps65912-irq.c
> >>  rewrite drivers/mfd/tps65912-spi.c (91%)
> >>  rewrite drivers/regulator/tps65912-regulator.c (94%)
> >
> >Is there really no other way to split this up?
> 
> I don't think so, not without breaking stuff, all the files are strongly
> connected.

I believe you've already had this conversation with Mark, so I'll not
labour it.

[...]

> >>+#include 
> >>+#include 
> >>+#include 
> >>+
> >
> >No need for the '\n'.
> >
> 
> Is it prohibited? It seems a lot over files do it this way, I personally
> think it makes it cleaner to see what headers are driver local. If you
> really don't like it have have no problem removing it though.

It's not a blocker.

> >>+#include 
> >>+
> >>+#define TPS65912_IRQ(_name, _reg, _offset) \
> >>+   [TPS65912_IRQ_ ## _name] = {\
> >>+   .mask = TPS65912_ ## _reg ## _ ## _name,\
> >>+   .reg_offset = _offset,  \
> >>+   }
> >
> >If you find this useful, then others will too.
> >
> >Please submit this to Mark Brown.
> 
> This is a really horrible macro hack I made so I didn't have to type
> out the whole register name each time, I'm not sure anyone else
> could use this, a better solution for most would be to use less
> verbose #defines for register names.

http://www.gossamer-threads.com/lists/linux/kernel/2261088

[...]

> >>+   .name = "tps65912",
> >>+   .irqs = tps65912_irqs,
> >>+   .num_irqs = ARRAY_SIZE(tps65912_irqs),
> >>+
> >>+   .num_regs = 4,
> >
> >Why do you have 2 num_regs entries?
> 
> Not sure what you mean, the other is num_irqs?

That's what no sleep on a plane gets you.

Please ignore.

[...]

> >>+#include 
> >>+
> >>+static const struct of_device_id tps65912_i2c_of_match_table[] = {
> >>+   { .compatible = "ti,tps65912", },
> >>+   { /*sentinel*/ }
> >
> >No need for this comment.  We know what { } does.
> 
> We do, but I didn't when I first saw this kind of thing, everything is
> obvious to someone, I'm not sure trying to keep the kernel as comment
> bare as it is is a good idea. Plus, how many chances do you get to
> use the word "sentinel" :). But I'll remove it if you have a strong
> opposition to it.

Again, it's not a blocker, but I believe there are enough of these now
and they have been around long enough that any non-noob will know what
they mean.  But granted, "sentinel" is a cool word.  Either remove it
completely, or at least conform to the Kernel's single line
commentating standards (HINT: Whitespace).

> >>+};
> >>+
> >>+static int tps65912_i2c_probe(struct i2c_client *client,
> >>+ const struct i2c_device_id *ids)
> >>+{
> >>+   struct tps65912 *tps;
> >>+   const struct of_device_id *match;
> >>+
> >>+   match = of_match_device(tps65912_i2c_of_match_table, >dev);
> >>+   if (!match) {
> >>+   dev_err(>dev, "Failed to find matching DT id\n");
> >>+   return -EINVAL;
> >>+   }
> >
> >Why are you matching?
> >
> 
> It looks like other drivers do this so they will fail early if they were
> not instantiated with DT. Here we don't need the match, so I'll just
> drop this check.

They should not be doing that either.

> >>+   tps = devm_kzalloc(>dev, sizeof(*tps), GFP_KERNEL);
> >>+   if (!tps)
> >>+   return -ENOMEM;
> >>+
> >>+   i2c_set_clientdata(client, tps);
> >>+   tps->dev = >dev;
> >>+   tps->irq = client->irq;
> >>+
> >>+   tps->regmap = devm_regmap_init_i2c(client, _regmap_config);
> >>+   if (IS_ERR(tps->regmap)) {
> >>+   int ret = PTR_ERR(tps->regmap);
> >
> >Neater just to declare 'int ret' up the top like we always do.
> 
> Linus has decreed we should not mix code and declerations outside of C89,
> and so I will not, but ret is at the top of its scope and so is conforment
> to C89. Moving it further up might be overly overly pedantic.
> 
> But if you think it would be really neater I can 

Re: [net-next PATCH 0/4] Add support for reading macid when DT macid not found

[David Miller]

From: Mugunthan V N 
Date: Mon, 21 Sep 2015 15:56:49 +0530

> Did a boot test on dra7-evm [1] and am437x-gp-evm [2].
> Pushed a branch [3] for others to test the patch.
> 
> [1]: http://pastebin.ubuntu.com/12513420/
> [2]: http://pastebin.ubuntu.com/12513428/
> [3]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
> cpsw-macid-read-support

Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Please suggest proper format for DT properties.

[Rob Herring]

On Mon, Sep 21, 2015 at 2:24 PM, Constantine Shulyupin
 wrote:
> On Mon, Sep 21, 2015 at 4:51 AM, Rob Herring  wrote:
>> On Fri, Sep 18, 2015 at 5:36 PM, Constantine Shulyupin
>>  wrote:
>>> Hi,
>>>
>>> I am designing DT support for a hwmon chip.
>>> It has some sensors, each of them can be:
>>>  - "disabled"
>>>  - "thermal diode"
>>>  - "thermistor"
>>>  - "voltage"
>>>
>>> Four possible options for DT properties format.
>>>
>>> Option 1: Separated property for each sensor.
>>>
>>> Example nct7802 node:
>>>
>>> nct7802 {
>>> compatible = "nuvoton,nct7802";
>>> reg = <0x2a>;
>>> nuvoton,sensor1-type = "thermistor";
>>> nuvoton,sensor2-type = "disabled";
>>> nuvoton,sensor3-type = "voltage";
>>> };
>>>
>>> Option 2: Array of strings for all sensors.
>>>
>>> nct7802 {
>>> compatible = "nuvoton,nct7802";
>>> reg = <0x2a>;
>>> nuvoton,sensors-types = "thermistor", "disabled", "voltage";
>>> };
>>
>> It seems you are just listing out all possible modes. Why do you need
>> this in the DT at all? This can be inferred by the compatible string.
>
> There are tree sensor, each of one can be one of three type ("thermal
> diode", "thermistor", "voltage") or be disabled.
> Also there are at least five platform depended registers, most of them
> are enable/disable.
> You can find full datasheet here
> https://www.nuvoton.com/hq/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/
>
> The question is how to describe configuration of this registers in dts.
> The second option is array of types for tree registers.

Okay, got it. I would go with option 2 in that case. Perhaps "mode"
instead of "type" though.

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

Re: [PATCH 1/7] phy: fix of_mdio_find_bus() device refcount leak

[David Miller]

From: Russell King - ARM Linux 
Date: Mon, 21 Sep 2015 20:32:07 +0100

> In the case of the mdio mux code, I'm dropping the reference when
> either (a) we've encountered an error during initialisation and
> we're cleaning up, or (b) when the mdio mux code is being torn down
> after the mdiomux bus has been unregistered and freed.  In both
> cases, we're done with the mdio bus that was returned from
> of_mdio_find_bus().
> 
> In case (a), the devres code will release the kmalloc'd memory when
> mdio_mux_gpio_probe() or mdio_mux_mmioreg_probe() propagates the error
> out of their probe() function.
> 
> I'm not sure why you think anything is wrong here - maybe it's the odd
> code structure to the success path at the bottom of mdio_mux_init()?

Ok I may have misread your change.  I'll restudy it when you respin
the series with the commit message fixed and the DSA change added.

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

[PATCH v3 8/9] ARM: dts: enable touchscreen support on Cygnus

[Ray Jui]

This patch enables touchscreen support on bcm958300k and bcm958305k.
Touchscreen is connected to these boards through the bcm9hmidc daughter
card, and therefore also adding bcm9hmidc.dtsi that describes the
daughter card

Signed-off-by: Ray Jui 
Reviewed-by: Vikram Prakash 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 10 ++
 arch/arm/boot/dts/bcm958300k.dts  |  1 +
 arch/arm/boot/dts/bcm958305k.dts  |  1 +
 arch/arm/boot/dts/bcm9hmidc.dtsi  | 42 +++
 4 files changed, 54 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm9hmidc.dtsi

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 33ec6a5..24e058c 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 
 #include "skeleton.dtsi"
 
@@ -257,5 +258,14 @@
interrupt-controller;
interrupts = ;
};
+
+   touchscreen: tsc@180a6000 {
+   compatible = "brcm,iproc-touchscreen";
+   reg = <0x180a6000 0x40>;
+   clocks = <_clks BCM_CYGNUS_ASIU_ADC_CLK>;
+   clock-names = "tsc_clk";
+   interrupts = ;
+   status = "disabled";
+   };
};
 };
diff --git a/arch/arm/boot/dts/bcm958300k.dts b/arch/arm/boot/dts/bcm958300k.dts
index d8dc9f0..2e31581 100644
--- a/arch/arm/boot/dts/bcm958300k.dts
+++ b/arch/arm/boot/dts/bcm958300k.dts
@@ -33,6 +33,7 @@
 /dts-v1/;
 
 #include "bcm-cygnus.dtsi"
+#include "bcm9hmidc.dtsi"
 
 / {
model = "Cygnus SVK (BCM958300K)";
diff --git a/arch/arm/boot/dts/bcm958305k.dts b/arch/arm/boot/dts/bcm958305k.dts
index 9863a19..288a637 100644
--- a/arch/arm/boot/dts/bcm958305k.dts
+++ b/arch/arm/boot/dts/bcm958305k.dts
@@ -33,6 +33,7 @@
 /dts-v1/;
 
 #include "bcm-cygnus.dtsi"
+#include "bcm9hmidc.dtsi"
 
 / {
model = "Cygnus Wireless Audio (BCM958305K)";
diff --git a/arch/arm/boot/dts/bcm9hmidc.dtsi b/arch/arm/boot/dts/bcm9hmidc.dtsi
new file mode 100644
index 000..65397c0
--- /dev/null
+++ b/arch/arm/boot/dts/bcm9hmidc.dtsi
@@ -0,0 +1,42 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  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.
+ */
+
+/*
+ * Broadcom human machine interface daughter card (bcm9hmidc) installed on
+ * bcm958300k/bcm958305k boards
+ */
+
+ {
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+   status = "okay";
+};
-- 
1.9.1

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

[PATCH v3 1/9] ARM: dts: consolidate aliases for Cygnus dt files

[Ray Jui]

Move aliases into bcm-cygnus.dtsi to avoid duplications in Cygnus dts
files

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi  | 4 
 arch/arm/boot/dts/bcm911360_entphn.dts | 4 
 arch/arm/boot/dts/bcm911360k.dts   | 4 
 arch/arm/boot/dts/bcm958300k.dts   | 4 
 arch/arm/boot/dts/bcm958305k.dts   | 4 
 5 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index e1ac07a..30903ba 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -40,6 +40,10 @@
model = "Broadcom Cygnus SoC";
interrupt-parent = <>;
 
+   aliases {
+   serial0 = 
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts 
b/arch/arm/boot/dts/bcm911360_entphn.dts
index 7db4843..0e1320e 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -39,10 +39,6 @@
model = "Cygnus Enterprise Phone (BCM911360_ENTPHN)";
compatible = "brcm,bcm11360", "brcm,cygnus";
 
-   aliases {
-   serial0 = 
-   };
-
chosen {
stdout-path = 
bootargs = "console=ttyS0,115200";
diff --git a/arch/arm/boot/dts/bcm911360k.dts b/arch/arm/boot/dts/bcm911360k.dts
index 9658d4f..2af40c6 100644
--- a/arch/arm/boot/dts/bcm911360k.dts
+++ b/arch/arm/boot/dts/bcm911360k.dts
@@ -38,10 +38,6 @@
model = "Cygnus SVK (BCM911360K)";
compatible = "brcm,bcm11360", "brcm,cygnus";
 
-   aliases {
-   serial0 = 
-   };
-
chosen {
stdout-path = 
bootargs = "console=ttyS0,115200";
diff --git a/arch/arm/boot/dts/bcm958300k.dts b/arch/arm/boot/dts/bcm958300k.dts
index 2f63052..75e50f0 100644
--- a/arch/arm/boot/dts/bcm958300k.dts
+++ b/arch/arm/boot/dts/bcm958300k.dts
@@ -38,10 +38,6 @@
model = "Cygnus SVK (BCM958300K)";
compatible = "brcm,bcm58300", "brcm,cygnus";
 
-   aliases {
-   serial0 = 
-   };
-
chosen {
stdout-path = 
bootargs = "console=ttyS0,115200";
diff --git a/arch/arm/boot/dts/bcm958305k.dts b/arch/arm/boot/dts/bcm958305k.dts
index 56b429a..bf62e1b 100644
--- a/arch/arm/boot/dts/bcm958305k.dts
+++ b/arch/arm/boot/dts/bcm958305k.dts
@@ -38,10 +38,6 @@
model = "Cygnus Wireless Audio (BCM958305K)";
compatible = "brcm,bcm58305", "brcm,cygnus";
 
-   aliases {
-   serial0 = 
-   };
-
chosen {
stdout-path = 
bootargs = "console=ttyS0,115200";
-- 
1.9.1

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

[PATCH v3 2/9] ARM: dts: Use label for device nodes in Cygnus dts

[Ray Jui]

Use label instead of full path to reference device nodes in Cygnus dts
files

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm911360_entphn.dts |  8 +++
 arch/arm/boot/dts/bcm911360k.dts   |  6 ++---
 arch/arm/boot/dts/bcm958300k.dts   | 40 +-
 arch/arm/boot/dts/bcm958305k.dts   |  6 ++---
 4 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts 
b/arch/arm/boot/dts/bcm911360_entphn.dts
index 0e1320e..f791a3b 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -44,10 +44,6 @@
bootargs = "console=ttyS0,115200";
};
 
-   uart3: serial@18023000 {
-   status = "okay";
-   };
-
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -60,3 +56,7 @@
};
};
 };
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm911360k.dts b/arch/arm/boot/dts/bcm911360k.dts
index 2af40c6..814011c 100644
--- a/arch/arm/boot/dts/bcm911360k.dts
+++ b/arch/arm/boot/dts/bcm911360k.dts
@@ -42,8 +42,8 @@
stdout-path = 
bootargs = "console=ttyS0,115200";
};
+};
 
-   uart3: serial@18023000 {
-   status = "okay";
-   };
+ {
+   status = "okay";
 };
diff --git a/arch/arm/boot/dts/bcm958300k.dts b/arch/arm/boot/dts/bcm958300k.dts
index 75e50f0..d8dc9f0 100644
--- a/arch/arm/boot/dts/bcm958300k.dts
+++ b/arch/arm/boot/dts/bcm958300k.dts
@@ -42,32 +42,32 @@
stdout-path = 
bootargs = "console=ttyS0,115200";
};
+};
 
-   pcie0: pcie@18012000 {
-   status = "okay";
-   };
+ {
+   status = "okay";
+};
 
-   pcie1: pcie@18013000 {
-   status = "okay";
-   };
+ {
+   status = "okay";
+};
 
-   uart3: serial@18023000 {
-   status = "okay";
-   };
+ {
+   status = "okay";
+};
 
-   nand: nand@18046000 {
-   nandcs@1 {
-   compatible = "brcm,nandcs";
-   reg = <0>;
-   nand-on-flash-bbt;
+ {
+   nandcs@1 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-on-flash-bbt;
 
-   #address-cells = <1>;
-   #size-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
 
-   nand-ecc-strength = <24>;
-   nand-ecc-step-size = <1024>;
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <1024>;
 
-   brcm,nand-oob-sector-size = <27>;
-   };
+   brcm,nand-oob-sector-size = <27>;
};
 };
diff --git a/arch/arm/boot/dts/bcm958305k.dts b/arch/arm/boot/dts/bcm958305k.dts
index bf62e1b..af11a8e 100644
--- a/arch/arm/boot/dts/bcm958305k.dts
+++ b/arch/arm/boot/dts/bcm958305k.dts
@@ -42,8 +42,8 @@
stdout-path = 
bootargs = "console=ttyS0,115200";
};
+};
 
-   uart3: serial@18023000 {
-   status = "okay";
-   };
+ {
+   status = "okay";
 };
-- 
1.9.1

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

[PATCH v3 7/9] ARM: dts: Enable NAND support on bcm911360_entphn

[Ray Jui]

This patch enables NAND support on Broadcom Cygnus form factor board
(bcm911360_entphn)

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm911360_entphn.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts 
b/arch/arm/boot/dts/bcm911360_entphn.dts
index f791a3b..8b3800f 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -60,3 +60,19 @@
  {
status = "okay";
 };
+
+ {
+   nandcs@1 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-on-flash-bbt;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <1024>;
+
+   brcm,nand-oob-sector-size = <27>;
+   };
+};
-- 
1.9.1

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

[PATCH v3 9/9] ARM: dts: fix Cygnus nand device node

[Ray Jui]

The third compatible string "brcm,brcmnand" in bcm-cygnus.dtsi nand node
is incorrect, redundant and should be removed. "brcm,brcmnand" is meant to
be used by STB based Broadcom SoCs. All iProc based SoCs should use
"brcm,nand-iproc".

Signed-off-by: Ray Jui 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 24e058c..b5f9f34 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -234,8 +234,7 @@
};
 
nand: nand@18046000 {
-   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
-"brcm,brcmnand";
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x18046000 0x600>, <0xf8105408 0x600>,
  <0x18046f00 0x20>;
reg-names = "nand", "iproc-idm", "iproc-ext";
-- 
1.9.1

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

[PATCH v3 4/9] ARM: dts: Move all Cygnus peripherals into axi bus

[Ray Jui]

Move all Cygnus peripherals to be under the "axi" bus node of type
"simple-bus"

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 279 +++---
 1 file changed, 140 insertions(+), 139 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 97fd305..5ee7543 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -88,173 +88,174 @@
};
};
 
-   pinctrl: pinctrl@0x0301d0c8 {
-   compatible = "brcm,cygnus-pinmux";
-   reg = <0x0301d0c8 0x30>,
- <0x0301d24c 0x2c>;
-   };
+   axi {
+   compatible = "simple-bus";
+   ranges;
+   #address-cells = <1>;
+   #size-cells = <1>;
 
-   gpio_crmu: gpio@03024800 {
-   compatible = "brcm,cygnus-crmu-gpio";
-   reg = <0x03024800 0x50>,
- <0x03024008 0x18>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   };
+   pinctrl: pinctrl@0x0301d0c8 {
+   compatible = "brcm,cygnus-pinmux";
+   reg = <0x0301d0c8 0x30>,
+ <0x0301d24c 0x2c>;
+   };
 
-   gpio_ccm: gpio@1800a000 {
-   compatible = "brcm,cygnus-ccm-gpio";
-   reg = <0x1800a000 0x50>,
- <0x0301d164 0x20>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   interrupts = ;
-   interrupt-controller;
-   };
+   gpio_crmu: gpio@03024800 {
+   compatible = "brcm,cygnus-crmu-gpio";
+   reg = <0x03024800 0x50>,
+ <0x03024008 0x18>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   };
 
-   gpio_asiu: gpio@180a5000 {
-   compatible = "brcm,cygnus-asiu-gpio";
-   reg = <0x180a5000 0x668>;
-   #gpio-cells = <2>;
-   gpio-controller;
+   gpio_ccm: gpio@1800a000 {
+   compatible = "brcm,cygnus-ccm-gpio";
+   reg = <0x1800a000 0x50>,
+ <0x0301d164 0x20>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupts = ;
+   interrupt-controller;
+   };
 
-   pinmux = <>;
+   gpio_asiu: gpio@180a5000 {
+   compatible = "brcm,cygnus-asiu-gpio";
+   reg = <0x180a5000 0x668>;
+   #gpio-cells = <2>;
+   gpio-controller;
 
-   interrupt-controller;
-   interrupts = ;
-   };
+   pinmux = <>;
 
-   amba {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "arm,amba-bus", "simple-bus";
-   interrupt-parent = <>;
-   ranges;
+   interrupt-controller;
+   interrupts = ;
+   };
 
-   wdt@18009000 {
-compatible = "arm,sp805" , "arm,primecell";
-reg = <0x18009000 0x1000>;
-interrupts = ;
-clocks = <_clk>;
-clock-names = "apb_pclk";
+   wdt0: wdt@18009000 {
+   compatible = "arm,sp805" , "arm,primecell";
+   reg = <0x18009000 0x1000>;
+   interrupts = ;
+   clocks = <_clk>;
+   clock-names = "apb_pclk";
};
-   };
 
-   i2c0: i2c@18008000 {
-   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
-   reg = <0x18008000 0x100>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   interrupts = ;
-   clock-frequency = <10>;
-   status = "disabled";
-   };
+   i2c0: i2c@18008000 {
+   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
+   };
 
-   i2c1: i2c@1800b000 {
-   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
-   reg = <0x1800b000 0x100>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   interrupts = ;
-   clock-frequency = <10>;
-   status = "disabled";
-   };
+   

[PATCH v3 5/9] ARM: dts: Reorder Cygnus peripherals

[Ray Jui]

Reorder all Cygnus peripherals based on base register addresses in
bcm-cygnus.dtsi

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 56 +++
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5ee7543..33ec6a5 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -108,26 +108,14 @@
gpio-controller;
};
 
-   gpio_ccm: gpio@1800a000 {
-   compatible = "brcm,cygnus-ccm-gpio";
-   reg = <0x1800a000 0x50>,
- <0x0301d164 0x20>;
-   #gpio-cells = <2>;
-   gpio-controller;
-   interrupts = ;
-   interrupt-controller;
-   };
-
-   gpio_asiu: gpio@180a5000 {
-   compatible = "brcm,cygnus-asiu-gpio";
-   reg = <0x180a5000 0x668>;
-   #gpio-cells = <2>;
-   gpio-controller;
-
-   pinmux = <>;
-
-   interrupt-controller;
-   interrupts = ;
+   i2c0: i2c@18008000 {
+   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
+   reg = <0x18008000 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   clock-frequency = <10>;
+   status = "disabled";
};
 
wdt0: wdt@18009000 {
@@ -138,14 +126,14 @@
clock-names = "apb_pclk";
};
 
-   i2c0: i2c@18008000 {
-   compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
-   reg = <0x18008000 0x100>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   interrupts = ;
-   clock-frequency = <10>;
-   status = "disabled";
+   gpio_ccm: gpio@1800a000 {
+   compatible = "brcm,cygnus-ccm-gpio";
+   reg = <0x1800a000 0x50>,
+ <0x0301d164 0x20>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   interrupts = ;
+   interrupt-controller;
};
 
i2c1: i2c@1800b000 {
@@ -257,5 +245,17 @@
 
brcm,nand-has-wp;
};
+
+   gpio_asiu: gpio@180a5000 {
+   compatible = "brcm,cygnus-asiu-gpio";
+   reg = <0x180a5000 0x668>;
+   #gpio-cells = <2>;
+   gpio-controller;
+
+   pinmux = <>;
+
+   interrupt-controller;
+   interrupts = ;
+   };
};
 };
-- 
1.9.1

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

[PATCH v3 0/9] Broadcom Cygnus device tree changes

[Ray Jui]

This patch series cleans up the Broadcom Cygnus device tree files and makes it
more consistent with the rest of Broadcom iProc device tree files. This patch
series also enables various peripherals on Cygnus boards. They include:

bcm11360_entphn:
NAND

bcm958300k:
touchscreen

bcm958305k:
I2C, PCIe, NAND, touchscreen

Code is based on v4.3-rc1 and is available on GITHUB:
https://github.com/Broadcom/cygnus-linux/tree/cygnus-dt-v3

Changes from V2:
 - Drop PCIe device node change that removes the I/O resource
 - Set up appropriate address range for the 'core' bus
 - Rename the 'soc' bus node to 'axi'
 - Remove incorrect 3rd compatible string 'brcm,brcmnand' in the NAND node

Chages from V1:
 - Break the major clean up change into separate patches

Ray Jui (9):
  ARM: dts: consolidate aliases for Cygnus dt files
  ARM: dts: Use label for device nodes in Cygnus dts
  ARM: dts: Put Cygnus core components under core bus
  ARM: dts: Move all Cygnus peripherals into axi bus
  ARM: dts: Reorder Cygnus peripherals
  ARM: dts: Enable various peripherals on bcm958305k
  ARM: dts: Enable NAND support on bcm911360_entphn
  ARM: dts: enable touchscreen support on Cygnus
  ARM: dts: fix Cygnus nand device node

 arch/arm/boot/dts/bcm-cygnus.dtsi  | 338 +
 arch/arm/boot/dts/bcm911360_entphn.dts |  28 ++-
 arch/arm/boot/dts/bcm911360k.dts   |  10 +-
 arch/arm/boot/dts/bcm958300k.dts   |  45 ++---
 arch/arm/boot/dts/bcm958305k.dts   |  41 +++-
 arch/arm/boot/dts/bcm9hmidc.dtsi   |  42 
 6 files changed, 300 insertions(+), 204 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm9hmidc.dtsi

-- 
1.9.1

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

[PATCH v3 3/9] ARM: dts: Put Cygnus core components under core bus

[Ray Jui]

Put all Cygnus core components into "core" node of type "simple-bus" in
bcm-cygnus.dtsi

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 54 ++-
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 30903ba..97fd305 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -58,6 +58,36 @@
 
/include/ "bcm-cygnus-clock.dtsi"
 
+   core {
+   compatible = "simple-bus";
+   ranges = <0x 0x1900 0x100>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   timer@20200 {
+   compatible = "arm,cortex-a9-global-timer";
+   reg = <0x20200 0x100>;
+   interrupts = ;
+   clocks = <_clk>;
+   };
+
+   gic: interrupt-controller@21000 {
+   compatible = "arm,cortex-a9-gic";
+   #interrupt-cells = <3>;
+   #address-cells = <0>;
+   interrupt-controller;
+   reg = <0x21000 0x1000>,
+ <0x20100 0x100>;
+   };
+
+   L2: l2-cache {
+   compatible = "arm,pl310-cache";
+   reg = <0x22000 0x1000>;
+   cache-unified;
+   cache-level = <2>;
+   };
+   };
+
pinctrl: pinctrl@0x0301d0c8 {
compatible = "brcm,cygnus-pinmux";
reg = <0x0301d0c8 0x30>,
@@ -227,28 +257,4 @@
 
brcm,nand-has-wp;
};
-
-   gic: interrupt-controller@19021000 {
-   compatible = "arm,cortex-a9-gic";
-   #interrupt-cells = <3>;
-   #address-cells = <0>;
-   interrupt-controller;
-   reg = <0x19021000 0x1000>,
- <0x19020100 0x100>;
-   };
-
-   L2: l2-cache {
-   compatible = "arm,pl310-cache";
-   reg = <0x19022000 0x1000>;
-   cache-unified;
-   cache-level = <2>;
-   };
-
-   timer@19020200 {
-   compatible = "arm,cortex-a9-global-timer";
-   reg = <0x19020200 0x100>;
-   interrupts = ;
-   clocks = <_clk>;
-   };
-
 };
-- 
1.9.1

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

[PATCH v3 6/9] ARM: dts: Enable various peripherals on bcm958305k

[Ray Jui]

This patch enables various peripherals on Broadcom Cygnus wireless audio
board (bcm958305k). These peripherals include I2C, PCIe, and NAND

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm958305k.dts | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/bcm958305k.dts b/arch/arm/boot/dts/bcm958305k.dts
index af11a8e..9863a19 100644
--- a/arch/arm/boot/dts/bcm958305k.dts
+++ b/arch/arm/boot/dts/bcm958305k.dts
@@ -44,6 +44,38 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
+
+ {
+   nandcs@1 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-on-flash-bbt;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <1024>;
+
+   brcm,nand-oob-sector-size = <27>;
+   };
+};
-- 
1.9.1

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

[RFC PATCH v2 1/3] Documentation: dt-bindings: add documentation on new DT binding format

[Matt Porter]

Documentation explaining the syntax and format of the YAML-based DT binding
documentation.

Signed-off-by: Matt Porter 
---
 .../devicetree/bindings/dt-binding-format.txt  | 105 +
 1 file changed, 105 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt

diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt 
b/Documentation/devicetree/bindings/dt-binding-format.txt
new file mode 100644
index 000..3763487
--- /dev/null
+++ b/Documentation/devicetree/bindings/dt-binding-format.txt
@@ -0,0 +1,105 @@
+--
+Device Tree Binding Format
+--
+
+Background
+--
+
+DT bindings historically were written as text in prose format which
+led to issues in usability of that source documentation. Some of
+these issues include the need to programmatically process binding
+source documentation to do DTS validation, perform mass updates to
+format/style, and to generate publishable documentation in HTML or
+PDF form.
+
+Overview
+
+
+The DT binding format is based on the YAML text markup language.
+Although there are many text markup options available, YAML
+fulfills all requirements considered for a DT binding source format
+which include:
+
+1) Must be human readable
+2) Must be easily translated to other data formats (XML, JSON, etc).
+3) Must have sufficient tools and libraries to enable developers to
+   build new tools for DT binding processing
+4) Must have a complete spec to refer to syntax
+
+YAML is documentated in the specification found at
+http://www.yaml.org/spec/1.2/spec.html
+
+The required YAML DT binding tag format and syntax are defined in
+the following sections.
+
+YAML DT Binding Syntax
+--
+
+* Lines starting with "#" are comments and not part of the binding itself
+* "%YAML 1.2" starts a file, indicating the version of YAML in use
+* "---" starts a binding document
+* "..." ends a binding document
+* Multiple binding documents may exist in a single file
+* Tabs are not permitted
+* Scope is denoted by indentation of four spaces
+* Key value pairs are denoted by "key: value"
+* Sequences are denoted by "-"
+* Scalar values may convert newlines to spaces and preserve blank
+  lines for long description formatting using ">"
+* Scalar values may escape all reserved characters and preserve
+  newlines by using "|" to denote literal style
+
+For additional information on YAML syntax, refer to the specification
+at http://www.yaml.org/spec/1.2/spec.html
+
+YAML DT Binding Format
+--
+
+The DT binding format is based on the YAML Core schema defined in the
+specification. The following YAML sequences and keys are supported in
+the DT binding format:
+
+[Note: [R] and [O] denote required and optional sequences/keys,respectively]
+
+* [R] version: DT binding format version. Currently 1.
+
+* [R] id: unique identifier in property form (e.g. skel-device)
+
+* [R] title: title of the binding
+
+* [R] maintainer: sequence of maintainers
+  [R] name: name and email of maintainer or mailing list in RFC822
+form.
+
+* [O] description: full description of the binding
+
+* [O] inherits: sequence of inherited bindings
+  [R] id: unique identifier of inherited binding
+
+* [R] properties: sequence of properties
+  [R] name: name of property surrounded in double quotes
+  [R} category: category of property. One of "required",
+"optional", or "deprecated".
+  [R] type: type of property. One of "string", "int", "empty",
+"phandle", or "array".
+  [O] constraint: constraint expression using C syntax
+  [O] deprecated: C syntax expression of deprecated compatible
+  strings.
+  [O] description: description of the property
+
+* [O] notes: Any additional notes about properties in this binding.
+
+* [O] example: sequence of examples:
+  [R] dts: DT source of example usage. The example text must use
+   literal style ("|") so that it retains indentation and
+   newlines.
+  [O] description: description of the example
+
+Skeleton Binding
+
+
+The skeleton.yaml binding found in the top of the DT binding tree
+is the canonical example of syntax and format to use when writing
+a DT binding document. It is maintained with the latest formatting
+conventions, making it the best starting point when writing a new DT
+binding.
-- 
2.5.1

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

[RFC PATCH v2 0/3] DT binding documents using text markup

[Matt Porter]

Changes since v1:
* Add dt binding format version
* Treat compatible strings as another property
* Required, optional, deprecated now a property field
* Add property type field
* Add property constraint field using C syntax for constraints
* Move binding references to a top level inherits sequence
* Dropped eeprom and phy examples. Example bindings are now only
  the spi-slave binding and the skeleton device binding which
  inherits the spi-slave binding.
* Added notes field to capture any notes on properties
* Update DT format docs to match new format.
* Add language about use of YAML core binding
* Refer to defined YAML sequences/keys consistently as such, remove
  all vague reference to types and tags.

TODO:
* reach agreement on format of sequences/keys
* need a flexible constraint syntax. this is only described
  in examples but needs a specific description in the format
  document.
* determine if compatibles can be handled generically in the
  property sequence or are better handled in their own specific
  compatible sequence
* compatibles as properties have the ugliness of how to
  handle deprecated strings, for now this is a "deprecated"
  key that contains a C-syntax expression of all deprecated
  strings.
* simple binding doc validator
* simple checkpatch.pl dts compatible string validator against yaml
  binding doc compatible property constraints
* update dtdocgen.py to process inherited bindings and current
  sequence/key format.

---

During the Device Tree microconference at Linux Plumbers 2015, we had
a short discussion about how to improve DT Binding Documentation. A
number of issues were raised (again, as these things have been
discussed in the past) including:

* Inconsistency between binding documents due to prose text
  format.
* Inability to reliably machine read bindings for mass update
  or search.
* Bit rot of bindings as new conventions are agreed upon but
  only new bindings are changed.

When the topic of needing the bindings in a rigid format was raised,
there was general head nodding that this was needed. It was noted that
this has been discussed many times before and nothing has been done.

My proposed solution to the problem is to convert all DT bindings
a rigid text markup format. In choosing a text markup language my
requirements were:

1) Human readable
2) Well documented
3) Easy to translate to other data formats
4) Well supported by tools and libraries

After looking at a number of markup options, YAML stood out as the
one that meets all of these requirements. The YAML syntax is adopted
in many projects specifically because of the high level of readability.
A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html.
There's a number of tools to convert between YAML and other popular
data formats such as JSON and XML. XML was cited by Behan Webster
during the microconference as an important data format as the type
of developers that may produce comprehensive DTS Binding validation
tools will want to use XML. Every major scripting language has a
high level binding to the low level libyaml C library to facilitate
handling of YAML data files.

This series is broken up into three parts:

1) The documentation defining the YAML DT binding format
2) A conversion of the generic SPI slave binding
2) A skeleton device binding example illustrating use of this format
   and inheriting the generic SPI slave binding properties.

As a proof of concept of what can be done with a proper machine
readable DT binding source file, there's a simple markdown document
generator at https://github.com/konsulko/dtgendoc. Also, to see
actual output from the generator, the generated markdown from those
bindings is viewable at https://github.com/konsulko/dtgendoc/wiki
(Note: this is not updated yet for v2, see TODO list)

There's a lot of other possibilities for validation tools using
only the data we have today in the bindings. In addition, Frank
Rowand covered some DT debug techniques that would benefit from
the binding documentation being 100% reliably searchable.

-Matt

Matt Porter (3):
  Documentation: dt-bindings: add documentation on new DT binding format
  Documentation: dt-bindings: spi: add generic YAML SPI slave binding
  Documentation: dt-bindings: add example DT binding document

 .../devicetree/bindings/dt-binding-format.txt  | 105 
 Documentation/devicetree/bindings/skeleton.yaml| 138 +
 .../devicetree/bindings/spi/spi-slave.yaml | 108 
 3 files changed, 351 insertions(+)
 create mode 100644 

[RFC PATCH v2 2/3] Documentation: dt-bindings: spi: add generic YAML SPI slave binding

[Matt Porter]

Convert the SPI slave portion of the spi-bus.txt binding to the
standard YAML DT binding format.

Signed-off-by: Matt Porter 
---
 .../devicetree/bindings/spi/spi-slave.yaml | 108 +
 1 file changed, 108 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-slave.yaml

diff --git a/Documentation/devicetree/bindings/spi/spi-slave.yaml 
b/Documentation/devicetree/bindings/spi/spi-slave.yaml
new file mode 100644
index 000..8447bb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-slave.yaml
@@ -0,0 +1,108 @@
+%YAML 1.2
+---
+version: 1
+
+id: spi-slave
+
+title: SPI Slave Devices
+
+maintainer:
+-   name: Mark Brown 
+
+description: >
+SPI (Serial Peripheral Interface) slave bus devices are children of
+of a SPI master bus device.
+properties:
+-   name: "reg"
+category: required
+type: int
+description: chip select address of device
+
+-   name: "compatible"
+category: required
+type: string
+description: compatible strings
+
+-   name: "spi-max-frequency"
+category: required
+type: int
+description: Maximum SPI clocking speed of device in Hz
+
+-   name: "spi-cpol"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+inverse clock polarity (CPOL) mode
+
+-   name: "spi-cpha"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+shifted clock phase (CPHA) mode
+
+-   name: "spi-cs-high"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+chip select active high
+
+-   name: "spi-3wire"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+3-wire mode.
+
+-   name: "spi-lsb-first"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+LSB first mode.
+
+-   name: "spi-tx-bus-width"
+category: optional
+type: int
+constraint: 1 || 2 || 4
+description: >
+The bus width(number of data wires) that
+used for MOSI. Defaults to 1 if not present.
+
+-   name: "spi-rx-bus-width"
+category: optional
+type: int
+constraint: 1 || 2 || 4
+description: >
+The bus width(number of data wires) that
+used for MISO. Defaults to 1 if not present.
+
+notes: >
+Some SPI controllers and devices support Dual and Quad SPI transfer mode.
+It allows data in the SPI system to be transferred in 2 wires(DUAL) or
+4 wires(QUAD).
+Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is
+only 1(SINGLE), 2(DUAL) and 4(QUAD). Dual/Quad mode is not allowed when
+3-wire mode is used.
+If a gpio chipselect is used for the SPI slave the gpio number will be
+passed via the SPI master node cs-gpios property.
+
+examples:
+-   dts: |
+spi@f00 {
+...
+ethernet-switch@0 {
+compatible = "micrel,ks8995m";
+spi-max-frequency = <100>;
+reg = <0>;
+};
+
+codec@1 {
+compatible = "ti,tlv320aic26";
+spi-max-frequency = <10>;
+reg = <1>;
+};
+};
+...
-- 
2.5.1

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

[RFC PATCH v2 3/3] Documentation: dt-bindings: add example DT binding document

[Matt Porter]

Add a skeleton DT binding document that serves as the canonical
example for implementing YAML-based DT bindings documentation.
The skeleton binding illustrates use of all fields and variations
described in the dt-binding-format.txt documentation.

Signed-off-by: Matt Porter 
---
 Documentation/devicetree/bindings/skeleton.yaml | 138 
 1 file changed, 138 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/skeleton.yaml

diff --git a/Documentation/devicetree/bindings/skeleton.yaml 
b/Documentation/devicetree/bindings/skeleton.yaml
new file mode 100644
index 000..d7a27cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/skeleton.yaml
@@ -0,0 +1,138 @@
+%YAML 1.2
+---
+version: 1
+
+id: skel-device
+
+title: Skeleton Device
+
+maintainer:
+-   name: Skeleton Person 
+
+description: >
+The Skeleton Device binding represents the SK11 device produced by
+the Skeleton Corporation. The binding can also support compatible
+clones made by second source vendors.
+
+# This binding inherits property characteristics from the generic
+# spi-slave binding
+
+inherits:
+-   id: spi-slave
+
+properties:
+
+# The compatible property is a reserved name. The type is always "string"
+# and should not be repeated device binding.
+
+-   name: "compatible"
+constraint: |
+"skel,sk11" || "faux,fx11" , BASE("skel,sk11")
+description: FX11 is a clone of the original SK11 device
+
+# The reg property is a reserved name. The type is always "int" and
+# should not be repeated in a device binding. Constraints are defined
+# only in the context of the parent node's address, size, and ranges
+# cells. The description is inherited from the spi-slave binding.
+
+-   name: "reg"
+
+# spi-max-frequency needs the device-specific constraint to be supplied
+
+-   name: "spi-max-frequency"
+constraint: |
+if (compatible == "skel,sk11") c <= 1000 else c <= 100
+
+# This property overrides the generic binding description with
+# a device specific description in order to mention the chip's
+# h/w cfg strapping pins.
+
+-   name: "spi-cs-high"
+description: >
+Set if skeleton device configuration pins are set for chip
+select polarity high
+
+# Device specific properties don't inherit characteristic from a generic
+# binding so category, type, constraint, and description must be specified
+# if needed.
+
+-   name: "skel,deprecated1"
+category: deprecated
+type: int
+constraint: |
+(c >= 10) && (c <= 20)
+description: >
+First of two deprecated properties.
+
+# There are no constraints for properties of empty type
+
+-   name: "skel,deprecated2"
+category: deprecated
+type: empty
+description: >
+Second of two deprecated properties.
+
+# This example could be auto-generated rather than explicitly included
+# in the yaml source.
+
+example:
+-   dts: |
+sk11@0 {
+compatible = "skel,sk11";
+reg = <0>;
+spi-max-frequency = <100>;
+spi-cs-high;
+};
+...
+
+---
+version: 1
+
+id: skel-mini
+
+title: Skeleton Mini Device
+
+maintainer:
+-   name: Rogue Developer 
+
+description: >
+The Skeleton Mini Device binding represents the SK47x series devices
+produced by the Skeleton Corporation.
+
+properties:
+-   name: "compatible"
+category: required
+constraint: |
+"skel,sk472" || skel,sk473" || "skel,sk474" , BASE("skel,sk472")
+deprecated: "skel,sk47x"
+description: >
+SK472 is the original part in the family. SK473/4 are later 
releases
+with minor register changes.
+
+-   name: "reg"
+category: required
+description: Address and size of Skeleton Mini register range.
+
+-   name: "skel,sync-mode"
+category: optional
+type: empty
+description: Enable synchronous transfer mode
+
+example:
+-   dts: |
+sk472@beef {
+compatible = "skel,sk472";
+reg = <0xbeef 0x100>;
+};
+description: >
+Demonstrates an SK472 in normal mode.
+
+-   dts: |
+sk474@dead {
+compatible = "skel,sk474", "skel,sk472";
+reg = <0xdead 0x100>;
+skel,sync-mode;
+};
+description: >
+Demonstrates an SK474 in synchronous mode.
+...
-- 
2.5.1

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

[PATCH v6 0/22] On-demand device probing

[Tomeu Vizoso]

Hello,

I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playing with initcall levels and linking order.

While reading the thread [1] that Alexander Holler started with his
series to make probing order deterministic, it occurred to me that it
should be possible to achieve the same by probing devices as they are
referenced by other devices.

This basically reuses the information that is already implicit in the
probe() implementations, saving us from refactoring existing drivers or
adding information to DTBs.

During review of v1 of this series Linus Walleij suggested that it
should be the device driver core to make sure that dependencies are
ready before probing a device. I gave this idea a try [2] but Mark Brown
pointed out to the logic duplication between the resource acquisition
and dependency discovery code paths (though I think it's fairly minor).

To address that code duplication I experimented with Arnd's devm_probe
[3] concept of having drivers declare their dependencies instead of
acquiring them during probe, and while it worked [4], I don't think we
end up winning anything when compared to just probing devices on-demand
from resource getters.

One remaining objection is to the "sprinkling" of calls to
of_device_probe() in the resource getters of each subsystem, but I think
it's the right thing to do given that the storage of resources is
currently subsystem-specific.

We could avoid the above by moving resource storage into the core, but I
don't think there's a compelling case for that.

I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
OMAP SoCs, and these patches were enough to eliminate all the deferred
probes (except one in PandaBoard because omap_dma_system doesn't have a
firmware node as of yet).

Have submitted a branch [5][6][7] with these patches on top of today's
linux-next (20150921) to kernelci.org and I don't see any issues that
could be caused by them.

With this series I get the kernel to output to the panel in 0.5s,
instead of 2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

[2] https://lkml.org/lkml/2015/6/17/305

[3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689

[4] https://lkml.org/lkml/2015/7/21/441a

[5] 
https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v8

[6] 
http://kernelci.org/boot/all/job/collabora/kernel/v4.3-rc2-2587-gf92b0ab33d14/

[7] http://kernelci.org/boot/all/job/next/kernel/next-20150921

Changes in v6:
- Drop bus_type.pre_probe and read the periphid in match() instead as
  suggested by Alan Stern.
- Merge changes to the regulator subsystem's locking so no references
  are leaked between commits.

Changes in v5:
- Set the pointer to struct device also for AMBA devices
- Unset the pointer to struct device when the platform device is about
  to be unregistered
- Increase the reference count of the device before returning from
  of_find_device_by_node()
- Move the assignment to device_node->device for AMBA devices to another
  commit.
- Hold a reference to the struct device while it's in use in
  of_device_probe().
- Use regulator_class' klist of devices instead of regulator_list to
  store and lookup regulator devices.

Changes in v4:
- Added bus.pre_probe callback so the probes of Primecell devices can be
  deferred if their device IDs cannot be yet read because of the clock
  driver not having probed when they are registered. Maybe this goes
  overboard and the matching information should be in the DT if there is
  one.
- Rename of_platform_probe to of_device_probe
- Use device_node.device instead of device_node.platform_dev
- Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in
  machines with initcalls that depend on devices probing at a given time.
- Start processing deferred probes in device_initcall_sync
- Also defer probes of AMBA devices registered from the DT as they can
  also request resources.

Changes in v3:
- Set and use device_node.platform_dev instead of reversing the logic to
  find the platform device that encloses a device node.
- Drop the fwnode API to probe firmware nodes and add OF-only API for
  now. I think this same scheme could be used for machines with ACPI,
  but I haven't been able to find one that had to defer its probes because
  of the device probe order.

Tomeu Vizoso (22):
  driver core: handle -EPROBE_DEFER from bus_type.match()
  ARM: amba: Move reading of periphid to amba_match()
  of/platform: Point to struct device from device node
  of: add function to allow probing a device from a OF node
  gpio: Probe GPIO drivers on demand
  gpio: Probe pinctrl devices on demand
  regulator: core: Remove regulator_lis

[PATCH v6 02/22] ARM: amba: Move reading of periphid to amba_match()

[Tomeu Vizoso]

Reading the periphid when the Primecell device is registered means that
the apb pclk must be available by then or the device won't be registered
at all.

By reading the periphid in amba_match() we can return -EPROBE_DEFER if
the apb pclk isn't there yet and the device will be retried later.

Signed-off-by: Tomeu Vizoso 
---

Changes in v6:
- Drop bus_type.pre_probe and read the periphid in match() instead as
  suggested by Alan Stern.

Changes in v4:
- Added bus.pre_probe callback so the probes of Primecell devices can be
  deferred if their device IDs cannot be yet read because of the clock
  driver not having probed when they are registered. Maybe this goes
  overboard and the matching information should be in the DT if there is
  one.

 drivers/amba/bus.c | 88 --
 1 file changed, 46 insertions(+), 42 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index f0099360039e..72ebf9b1c715 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -24,6 +24,8 @@
 
 #define to_amba_driver(d)  container_of(d, struct amba_driver, drv)
 
+static int read_periphid(struct amba_device *d, unsigned int *periphid);
+
 static const struct amba_id *
 amba_lookup(const struct amba_id *table, struct amba_device *dev)
 {
@@ -43,11 +45,22 @@ static int amba_match(struct device *dev, struct 
device_driver *drv)
 {
struct amba_device *pcdev = to_amba_device(dev);
struct amba_driver *pcdrv = to_amba_driver(drv);
+   int ret;
 
/* When driver_override is set, only bind to the matching driver */
if (pcdev->driver_override)
return !strcmp(pcdev->driver_override, drv->name);
 
+   if (!pcdev->periphid) {
+   ret = read_periphid(pcdev, >periphid);
+   if (ret) {
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev, "Failed to read periphid: %d",
+   ret);
+   return ret;
+   }
+   }
+
return amba_lookup(pcdrv->id_table, pcdev) != NULL;
 }
 
@@ -336,44 +349,22 @@ static void amba_device_release(struct device *dev)
kfree(d);
 }
 
-/**
- * amba_device_add - add a previously allocated AMBA device structure
- * @dev: AMBA device allocated by amba_device_alloc
- * @parent: resource parent for this devices resources
- *
- * Claim the resource, and read the device cell ID if not already
- * initialized.  Register the AMBA device with the Linux device
- * manager.
- */
-int amba_device_add(struct amba_device *dev, struct resource *parent)
+static int read_periphid(struct amba_device *d, unsigned int *periphid)
 {
u32 size;
void __iomem *tmp;
-   int i, ret;
-
-   WARN_ON(dev->irq[0] == (unsigned int)-1);
-   WARN_ON(dev->irq[1] == (unsigned int)-1);
-
-   ret = request_resource(parent, >res);
-   if (ret)
-   goto err_out;
-
-   /* Hard-coded primecell ID instead of plug-n-play */
-   if (dev->periphid != 0)
-   goto skip_probe;
+   int i, ret = 0;
 
/*
 * Dynamically calculate the size of the resource
 * and use this for iomap
 */
-   size = resource_size(>res);
-   tmp = ioremap(dev->res.start, size);
-   if (!tmp) {
-   ret = -ENOMEM;
-   goto err_release;
-   }
+   size = resource_size(>res);
+   tmp = ioremap(d->res.start, size);
+   if (!tmp)
+   return -ENOMEM;
 
-   ret = amba_get_enable_pclk(dev);
+   ret = amba_get_enable_pclk(d);
if (ret == 0) {
u32 pid, cid;
 
@@ -388,37 +379,50 @@ int amba_device_add(struct amba_device *dev, struct 
resource *parent)
cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) <<
(i * 8);
 
-   amba_put_disable_pclk(dev);
+   amba_put_disable_pclk(d);
 
if (cid == AMBA_CID || cid == CORESIGHT_CID)
-   dev->periphid = pid;
+   *periphid = pid;
 
-   if (!dev->periphid)
+   if (!*periphid)
ret = -ENODEV;
}
 
iounmap(tmp);
 
+   return ret;
+}
+
+/**
+ * amba_device_add - add a previously allocated AMBA device structure
+ * @dev: AMBA device allocated by amba_device_alloc
+ * @parent: resource parent for this devices resources
+ *
+ * Claim the resource, and register the AMBA device with the Linux device
+ * manager.
+ */
+int amba_device_add(struct amba_device *dev, struct resource *parent)
+{
+   int ret;
+
+   WARN_ON(dev->irq[0] == (unsigned int)-1);
+   WARN_ON(dev->irq[1] == (unsigned int)-1);
+
+   ret = request_resource(parent, >res);
if (ret)
-   goto err_release;
+   return ret;
 
- skip_probe:
ret = 

[PATCH v6 01/22] driver core: handle -EPROBE_DEFER from bus_type.match()

[Tomeu Vizoso]

Lets implementations of the match() callback in struct bus_type to
return errors and if it's -EPROBE_DEFER then queue the device for
deferred probing.

This is useful to buses such as AMBA in which devices are registered
before their matching information can be retrieved from the HW
(typically because a clock driver hasn't probed yet).

Signed-off-by: Tomeu Vizoso 
---


 drivers/base/dd.c  | 24 ++--
 include/linux/device.h |  2 +-
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..7dc04ee81c8b 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -488,6 +488,7 @@ static int __device_attach_driver(struct device_driver 
*drv, void *_data)
struct device_attach_data *data = _data;
struct device *dev = data->dev;
bool async_allowed;
+   int ret;
 
/*
 * Check if device has already been claimed. This may
@@ -498,8 +499,17 @@ static int __device_attach_driver(struct device_driver 
*drv, void *_data)
if (dev->driver)
return -EBUSY;
 
-   if (!driver_match_device(drv, dev))
+   ret = driver_match_device(drv, dev);
+   if (!ret)
return 0;
+   else if (ret < 0) {
+   if (ret == -EPROBE_DEFER) {
+   dev_dbg(dev, "Device match requests probe deferral\n");
+   driver_deferred_probe_add(dev);
+   } else
+   dev_warn(dev, "Bus failed to match device: %d", ret);
+   return ret;
+   }
 
async_allowed = driver_allows_async_probing(drv);
 
@@ -619,6 +629,7 @@ void device_initial_probe(struct device *dev)
 static int __driver_attach(struct device *dev, void *data)
 {
struct device_driver *drv = data;
+   int ret;
 
/*
 * Lock device and try to bind to it. We drop the error
@@ -630,8 +641,17 @@ static int __driver_attach(struct device *dev, void *data)
 * is an error.
 */
 
-   if (!driver_match_device(drv, dev))
+   ret = driver_match_device(drv, dev);
+   if (!ret)
+   return 0;
+   else if (ret < 0) {
+   if (ret == -EPROBE_DEFER) {
+   dev_dbg(dev, "Device match requests probe deferral\n");
+   driver_deferred_probe_add(dev);
+   } else
+   dev_warn(dev, "Bus failed to match device: %d", ret);
return 0;
+   }
 
if (dev->parent)/* Needed for USB */
device_lock(dev->parent);
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc6349930..8e7b806f0744 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -70,7 +70,7 @@ extern void bus_remove_file(struct bus_type *, struct 
bus_attribute *);
  * @dev_groups:Default attributes of the devices on the bus.
  * @drv_groups: Default attributes of the device drivers on the bus.
  * @match: Called, perhaps multiple times, whenever a new device or driver
- * is added for this bus. It should return a nonzero value if the
+ * is added for this bus. It should return a positive value if the
  * given device can be handled by the given driver.
  * @uevent:Called when a device is added, removed, or a few other things
  * that generate uevents to add the environment variables.
-- 
2.4.3

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

[PATCH v6 07/22] regulator: core: Remove regulator_list

[Tomeu Vizoso]

As we are already registering a device with regulator_class for each
regulator device, regulator_list is redundant and can be replaced with
calls to class_find_device() and class_for_each_device().

Signed-off-by: Tomeu Vizoso 
---

Changes in v6:
- Merge changes to the regulator subsystem's locking so no references
  are leaked between commits.

Changes in v5:
- Use regulator_class' klist of devices instead of regulator_list to
  store and lookup regulator devices.

 drivers/regulator/core.c | 255 ++-
 1 file changed, 164 insertions(+), 91 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e5dbbe2f5212..af045e5a83ef 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -51,7 +51,6 @@
pr_debug("%s: " fmt, rdev_get_name(rdev), ##__VA_ARGS__)
 
 static DEFINE_MUTEX(regulator_list_mutex);
-static LIST_HEAD(regulator_list);
 static LIST_HEAD(regulator_map_list);
 static LIST_HEAD(regulator_ena_gpio_list);
 static LIST_HEAD(regulator_supply_alias_list);
@@ -59,6 +58,8 @@ static bool has_full_constraints;
 
 static struct dentry *debugfs_root;
 
+static struct class regulator_class;
+
 /*
  * struct regulator_map
  *
@@ -1325,6 +1326,47 @@ static void regulator_supply_alias(struct device **dev, 
const char **supply)
}
 }
 
+static int of_node_match(struct device *dev, const void *data)
+{
+   return dev->of_node == data;
+}
+
+static struct regulator_dev *of_find_regulator_by_node(struct device_node *np)
+{
+   struct device *dev;
+
+   dev = class_find_device(_class, NULL, np, of_node_match);
+
+   return dev ? dev_to_rdev(dev) : NULL;
+}
+
+static int regulator_match(struct device *dev, const void *data)
+{
+   struct regulator_dev *r = dev_to_rdev(dev);
+
+   return strcmp(rdev_get_name(r), data) == 0;
+}
+
+static struct regulator_dev *regulator_lookup_by_name(const char *name)
+{
+   struct device *dev;
+
+   dev = class_find_device(_class, NULL, name, regulator_match);
+
+   return dev ? dev_to_rdev(dev) : NULL;
+}
+
+/**
+ * regulator_dev_lookup - lookup a regulator device.
+ * @dev: device for regulator "consumer".
+ * @supply: Supply name or regulator ID.
+ * @ret: 0 on success, -ENODEV if lookup fails permanently, -EPROBE_DEFER if
+ * lookup could succeed in the future.
+ *
+ * If successful, returns a struct regulator_dev that corresponds to the name
+ * @supply and with the embedded struct device refcount incremented by one,
+ * or NULL on failure. The refcount must be dropped by calling put_device().
+ */
 static struct regulator_dev *regulator_dev_lookup(struct device *dev,
  const char *supply,
  int *ret)
@@ -1340,10 +1382,9 @@ static struct regulator_dev *regulator_dev_lookup(struct 
device *dev,
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
-   list_for_each_entry(r, _list, list)
-   if (r->dev.parent &&
-   node == r->dev.of_node)
-   return r;
+   r = of_find_regulator_by_node(node);
+   if (r)
+   return r;
*ret = -EPROBE_DEFER;
return NULL;
} else {
@@ -1361,20 +1402,24 @@ static struct regulator_dev 
*regulator_dev_lookup(struct device *dev,
if (dev)
devname = dev_name(dev);
 
-   list_for_each_entry(r, _list, list)
-   if (strcmp(rdev_get_name(r), supply) == 0)
-   return r;
+   r = regulator_lookup_by_name(supply);
+   if (r)
+   return r;
 
+   mutex_lock(_list_mutex);
list_for_each_entry(map, _map_list, list) {
/* If the mapping has a device set up it must match */
if (map->dev_name &&
(!devname || strcmp(map->dev_name, devname)))
continue;
 
-   if (strcmp(map->supply, supply) == 0)
+   if (strcmp(map->supply, supply) == 0 &&
+   get_device(>regulator->dev)) {
+   mutex_unlock(_list_mutex);
return map->regulator;
+   }
}
-
+   mutex_unlock(_list_mutex);
 
return NULL;
 }
@@ -1405,6 +1450,7 @@ static int regulator_resolve_supply(struct regulator_dev 
*rdev)
 
if (have_full_constraints()) {
r = dummy_regulator_rdev;
+   get_device(>dev);
} else {
dev_err(dev, "Failed to resolve %s-supply for %s\n",
rdev->supply_name, rdev->desc->name);
@@ -1414,12 +1460,16 @@ static int 

[PATCH v6 13/22] backlight: Probe backlight devices on demand

[Tomeu Vizoso]

When looking up a backlight device through its OF node, probe it if it
hasn't already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso 
---


 drivers/video/backlight/backlight.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index bddc8b17a4d8..9bcdc16eacdf 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_PMAC_BACKLIGHT
 #include 
@@ -559,6 +560,8 @@ struct backlight_device *of_find_backlight_by_node(struct 
device_node *node)
 {
struct device *dev;
 
+   of_device_probe(node);
+
dev = class_find_device(backlight_class, NULL, node, of_parent_match);
 
return dev ? to_backlight_device(dev) : NULL;
-- 
2.4.3

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

[PATCH v6 09/22] drm: Probe panels on demand

[Tomeu Vizoso]

When looking up a panel through its OF node, probe it if it hasn't
already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso 
---


 drivers/gpu/drm/drm_panel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e037b7..ad79a7b9c74d 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -80,6 +81,8 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
 {
struct drm_panel *panel;
 
+   of_device_probe(np);
+
mutex_lock(_lock);
 
list_for_each_entry(panel, _list, list) {
-- 
2.4.3

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

[PATCH v6 08/22] regulator: core: Probe regulators on demand

[Tomeu Vizoso]

When looking up a regulator through its OF node, probe it if it hasn't
already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso 
---


 drivers/regulator/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index af045e5a83ef..a6ed657c691b 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1382,6 +1383,7 @@ static struct regulator_dev *regulator_dev_lookup(struct 
device *dev,
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
+   of_device_probe(node);
r = of_find_regulator_by_node(node);
if (r)
return r;
-- 
2.4.3

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

RE: [PATCH 1/3] ASoC: codecs: Add da7219 codec driver

[Opensource [Adam Thomson]]

On September 19, 2015 18:44, Mark Brown wrote:

> > +   do {
> > +   statusa = snd_soc_read(codec, DA7219_ACCDET_STATUS_A);
> > +   if (statusa & DA7219_MICBIAS_UP_STS_MASK)
> > +   micbias_up = true;
> > +   } while (!micbias_up);
> 
> This could go into an inifinite loop.
> 

Only if the HW is unresponsive. However, it's probably better to add a timeout
and some debug in the unlikely event that does happen.

> > +static void da7219_aad_hptest_work(struct work_struct *work)
> > +{
> > +   struct da7219_aad_priv *da7219_aad =
> > +   container_of(work, struct da7219_aad_priv, hptest_work);
> > +   struct snd_soc_codec *codec = da7219_aad->codec;
> > +   struct da7219_priv *da7219 = snd_soc_codec_get_drvdata(codec);
> > +
> > +   u8 tonegen_cfg1, tonegen_cfg2, tonegen_onper;
> > +   u16 tonegen_freq1, tonegen_freq_hptest;
> > +   u8 hpl_gain, hpr_gain, dacl_gain, dacr_gain, dac_filters1, dac_filters4;
> > +   u8 dac_filters5, cp_ctrl, routing_dac, dacl_ctrl, dacr_ctrl;
> > +   u8 mixoutl_sel, mixoutr_sel, st_outfilt_1l, st_outfilt_1r;
> > +   u8 mixoutl_ctrl, mixoutr_ctrl, hpl_ctrl, hpr_ctrl, accdet_cfg8;
> > +   int report = 0;
> > +
> > +   /* Save current settings */
> 
> This is obviously a massive reconfiguration of the device.  I'm not
> seeing anything here which prevents userspace coming in and change the
> configuration while we're in this function, that would obviously have
> serious issues.
> 
> I'm also wondering if this might be more elegantly implemented by going
> into cache bypass mode, doing the test and then using a cache resync to
> restore the initial configuration.  That will at least avoid issues with
> updates adding a new register but not modifying it.

In a system scenario the likelihood of that happening is small as you
cannot use the mic or headphones until they've been inserted. The system is
only likely to act after the jack insertion events have occurred. However, it
would be better to prevent any chance of concurrent access. The problem is how
best to lock the Kcontrols whilst the test procedure in progress. At the moment
the only way I can see is to add explicit control set() functions which would
use a lock that can also be controlled by the HP test code. Does this make sense
to you or do you know of a simpler method? Obviously dapm has function to lock
as required.

For the cache resync idea, in terms of code, it will look cleaner, but you are
talking about 4 to 5 times the number of I2C accesses to the device, to restore
configuration. Does that not seem like a bit too much overhead?
 
> > +   if (statusa & DA7219_JACK_TYPE_STS_MASK) {
> > +   report |= SND_JACK_HEADSET;
> > +   mask |= SND_JACK_HEADSET |
> SND_JACK_LINEOUT;
> > +   schedule_work(_aad->btn_det_work);
> > +   } else {
> > +   schedule_work(_aad->hptest_work);
> > +   }
> 
> Why are we scheduling work - we're already in thread context?

hptest will take some time to complete (over 100ms), and in that time it's
plausible that a user could remove the jack. If we deal with this in the IRQ
thread, we won't be aware of jack removal during the process, and will send a
report regardless, which will almost definitely be incorrect, and unnecessary.
By spawning off work, it allows the removal to be dealt with if the hptest work
procedure is currently in process, and then we can avoid sending incorrect jack
reports at the end.

For button detection, for certain mics it's required to pulse the micbias to a
higher voltage, for a defined period of time, to enable the mic. Again this
period is likely to take maybe 100ms, depending on the mic, so it made far more
sense to me to do this outside of the IRQ thread. However, if you have a better
proposal for this then am happy to take it on board.
 
> > +   /* Un-drive headphones/lineout */
> > +   snd_soc_update_bits(codec, DA7219_HP_R_CTRL,
> > +   DA7219_HP_R_AMP_OE_MASK, 0);
> > +   snd_soc_update_bits(codec, DA7219_HP_L_CTRL,
> > +   DA7219_HP_L_AMP_OE_MASK, 0);
> 
> This looks like DAPM?

The control of driving the headphones or making them high impedance is handled
in the AAD code because we cannot have the headphones driven before a jack is
inserted as it will affect the pole detection. Adding it to DAPM seemed like it
would cause more problems in terms of controlling when it would and wouldn't be
enabled.
 
> > +static enum da7219_aad_jack_ins_deb da7219_aad_of_jack_ins_deb(u32 val)
> > +{
> > +   switch (val) {
> > +   case 5:
> > +   return DA7219_AAD_JACK_INS_DEB_5MS;
> > +   case 10:
> > +   return DA7219_AAD_JACK_INS_DEB_10MS;
> > +   case 20:
> > +   return DA7219_AAD_JACK_INS_DEB_20MS;
> > +   case 50:
> > +   return 

Re: [PATCH 2/2] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Fri, 18 Sep 2015 10:54:02 -0700
David Daney  wrote:

> On 09/18/2015 01:51 AM, Marc Zyngier wrote:
> > On Thu, 17 Sep 2015 11:00:59 -0700
> > David Daney  wrote:
> >
> > Hi David,
> >
> >> From: David Daney 
> >>
> >> Search up the device hierarchy to find devices with a "msi-map"
> >> property, if found apply the mapping to the GIC device id.
> >>
> >> Signed-off-by: David Daney 
> >> ---
> >>   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 73 
> >> 
> >>   1 file changed, 73 insertions(+)
> >>
> >> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> >> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> index cf351c6..aa61cef 100644
> >> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> @@ -73,6 +73,8 @@ static int its_pci_msi_prepare(struct irq_domain 
> >> *domain, struct device *dev,
> >>struct pci_dev *pdev;
> >>struct its_pci_alias dev_alias;
> >>struct msi_domain_info *msi_info;
> >> +  struct device *parent_dev;
> >> +  struct device_node *msi_controller_node = NULL;
> >>
> >>if (!dev_is_pci(dev))
> >>return -EINVAL;
> >> @@ -84,6 +86,77 @@ static int its_pci_msi_prepare(struct irq_domain 
> >> *domain, struct device *dev,
> >>dev_alias.count = nvec;
> >>
> >>pci_for_each_dma_alias(pdev, its_get_pci_alias, _alias);
> >> +  /*
> >> +   * Walk up the device parent links looking for one with a
> >> +   * "msi-map" property.
> >> +   */
> >
> > My first objection is the location of this parsing. It shouldn't be
> > driver specific, but instead be part of the generic OF handling
> > (nothing in these properties is GICv3 specific, even if the ITS is the
> > only user so far).
> 
> OK, I agree that this should eventually end up in generic OF handling 
> code.  I just wanted to get something out to initiate discussion.
> 
> The next patch revision will move this to a more generic home.
> 
> >
> >> +  for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
> >
> > Is there a limit how far we should go up the parent chain to find a
> > msi-map? My hunch is that you should stop at the first device that does
> > have an of_node, as it is the one that should contain the msi-map
> > property.
> 
> I think there is the possibility of finding something like a bridge that 
> has an of_node, but does not have the "msi-map" property.  I currently 
> have exactly this configuration, as some of the on-SoC devices sit 
> behind a bridge, but need an of_node to obtain unprobable properties and 
> children (the MDIO bus devices are like this).
> 
> So if we want to abort the walk early, we should at least go up until we 
> find "msi-map" in the of_node.

I don't really see a case where we would traverse a series of nodes
where the msi-map property wouldn't be in the first node. Could you
please give me an example?

[...]

> >> +  msi_controller_node = of_find_node_by_phandle(phandle);
> >> +  if (domain->of_node != msi_controller_node) {
> >> +  dev_err(dev,
> >> +  "ERROR: msi-map mismatch \"%s\" vs. \"%s\"\n",
> >> +  domain->of_node->full_name,
> >> +  msi_controller_node ? NULL : 
> >> msi_controller_node->full_name);
> >
> > Why is that an error? a RC can be configured to master multiple
> > MSI-controllers,
> 
> Something has already associated the PCI device with this 
> MSI-controller.  Therefore I think the reference in the map must refer 
> to this ITS MSI-controller instance.
> 
> 
> > and the kernel picks one of them for a given device.
> > This is illustrated by "Example (5)" in the binding, where a device can
> > master two MSI controllers.
> 
> The PCI host may have many MSI controllers, but I think a given PCI 
> device will have only one (based on bus:devfn) that is looked up in the map.

A PCI device will only be configured to talk to a single MSI
controller, but here you stop parsing the msi-map on the first match,
and assume that you must have found the right MSI controller:

I think this should read:

+   if (masked_devid < rid_base ||
+   masked_devid >= rid_base + rid_len ||
domain->of_node != 
of_find_node_by_phandle(phandle)) {
+   msi_map_len -= 4 * sizeof(__be32);
+   msi_map += 4;
+   continue;
+   }
+   matched = true;
+   break;

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

[Andrew F. Davis]

On 09/19/2015 11:16 PM, Lee Jones wrote:

On Tue, 15 Sep 2015, Andrew F. Davis wrote:


The TPS65912 PMIC contains several regulators and a GPIO controller.
Add bindings for the TPS65912 PMIC.

Signed-off-by: Andrew F. Davis 
---
  .../devicetree/bindings/gpio/gpio-tps65912.txt | 17 +
  Documentation/devicetree/bindings/mfd/tps65912.txt | 43 ++
  .../bindings/regulator/tps65912-regulator.txt  | 32 
  3 files changed, 92 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
  create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
  create mode 100644 
Documentation/devicetree/bindings/regulator/tps65912-regulator.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt 
b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
new file mode 100644
index 000..f65370b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
@@ -0,0 +1,17 @@
+* TPS65912 GPIO controller bindings


Suggest s/controller/Controller/



ACK


+Required properties:
+ - compatible : Should be "ti,tps65912-gpio".
+ - gpio-controller : Marks the device node as a gpio controller.


s/gpio/GPIO/

As above for controller.



ACK


+ - #gpio-cells : Should be two.  The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+   0 = active high
+   1 = active low


Best to use the #defines in include/dt-bindings/gpio.



ACK


+Example:
+
+   gpio4: tps65912_gpio {
+   compatible = "ti,tps65912-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt 
b/Documentation/devicetree/bindings/mfd/tps65912.txt
new file mode 100644
index 000..081af66
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
@@ -0,0 +1,43 @@
+* TPS65912 Power Management Integrated Circuit bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65912".
+ - reg : Slave address or chip select number (I2C / SPI).
+ - 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, this should be 2.


s/the/The/



ACK


+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ Documentation/devicetree/bindings/interrupts.txt


No such file.



Yeah, this is an unchecked copy/paste on my part, other bindings did it this 
also, so
I just submitted a patch to fix them too.


+Optional nodes:
+ - Regulators: 
Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
+ - GPIO: Documentation/devicetree/bindings/gpio/gpio-tps65912.txt.


Better to use ../gpio, ../regulator, etc.

"Regulators" and "GPIO" aren't valid node names.

Please be more specific.



OK, I'll see if I can clear this up.


+Example:
+
+   pmic: tps65912@2d {
+   compatible = "ti,tps65912";
+   reg = <0x2d>;
+   interrupt-parent = <>;
+   interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   dcdc1: regulator-dcdc1 {
+   compatible = "ti,tps65912-dcdc1";
+   regulator-name = "vdd_core";
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <1144000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   ...


No need for this.



ACK


+   gpio4: tps65912_gpio {
+   compatible = "ti,tps65912-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
diff --git a/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt 
b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
new file mode 100644
index 000..a417ff7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
@@ -0,0 +1,32 @@
+* TPS65912 regulator bindings
+
+Required properties:
+ - compatible: Should be:
+   - "ti,tps65912-dcdc1" for DCDC1
+   - "ti,tps65912-dcdc2" for DCDC2
+   - "ti,tps65912-dcdc3" for DCDC3
+   - "ti,tps65912-dcdc4" for DCDC4
+   - "ti,tps65912-ldo1" for LDO1
+   - "ti,tps65912-ldo2" for LDO2
+   - "ti,tps65912-ldo3" for LDO3
+   - "ti,tps65912-ldo4" for LDO4
+   - "ti,tps65912-ldo5" for LDO5
+   - "ti,tps65912-ldo6" for LDO6
+   - "ti,tps65912-ldo7" for LDO7
+   - "ti,tps65912-ldo8" for LDO8
+   - "ti,tps65912-ldo9" for LDO9
+   - "ti,tps65912-ldo10" for LDO10
+
+Optional properties:
+ - Any optional property defined in bindings/regulator/regulator.txt


../regulator/...



Not really sure what 

Re: [PATCH 2/5] thermal: rockchip: Support the RK3368 SoCs in thermal driver

[Dmitry Torokhov]

Hi Caesar,

On Mon, Sep 21, 2015 at 12:16:08PM +0800, Caesar Wang wrote:
> The RK3368 SoCs support to 2 channel TS-ADC, the temperature criteria
> of each channel can be configurable.
> 
> The system has two Temperature Sensors, channel 0 is for CPU,
> and channel 1 is for GPU.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
>  drivers/thermal/rockchip_thermal.c | 201 
> -
>  1 file changed, 176 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/thermal/rockchip_thermal.c 
> b/drivers/thermal/rockchip_thermal.c
> index 4d5b7d4..16d2476 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -1,6 +1,9 @@
>  /*
>   * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
>   *
> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
> + * Caesar Wang 
> + *
>   * 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.
> @@ -43,16 +46,11 @@ enum tshut_polarity {
>   TSHUT_HIGH_ACTIVE,
>  };
>  
> -/**
> - * The system has three Temperature Sensors.  channel 0 is reserved,
> - * channel 1 is for CPU, and channel 2 is for GPU.
> - */
> -enum sensor_id {
> - SENSOR_CPU = 1,
> - SENSOR_GPU,
> -};
> -
>  struct rockchip_tsadc_chip {
> + /* The sensor id of chip correspond to the ADC channel */
> + int cpu_id;
> + int gpu_id;
> +
>   /* The hardware-controlled tshut property */
>   long tshut_temp;
>   enum tshut_mode tshut_mode;
> @@ -72,10 +70,11 @@ struct rockchip_tsadc_chip {
>  struct rockchip_thermal_sensor {
>   struct rockchip_thermal_data *thermal;
>   struct thermal_zone_device *tzd;
> - enum sensor_id id;
> + int id;
>  };
>  
> -#define NUM_SENSORS  2 /* Ignore unused sensor 0 */
> +/* Two sensors: CPU and GPU */
> +#define NUM_SENSORS  2
>  
>  struct rockchip_thermal_data {
>   const struct rockchip_tsadc_chip *chip;
> @@ -94,7 +93,7 @@ struct rockchip_thermal_data {
>   enum tshut_polarity tshut_polarity;
>  };
>  
> -/* TSADC V2 Sensor info define: */
> +/* TSADC Sensor info define: */
>  #define TSADCV2_AUTO_CON 0x04
>  #define TSADCV2_INT_EN   0x08
>  #define TSADCV2_INT_PD   0x0c
> @@ -116,6 +115,8 @@ struct rockchip_thermal_data {
>  #define TSADCV2_INT_PD_CLEAR_MASK~BIT(8)
>  
>  #define TSADCV2_DATA_MASK0xfff
> +#define TSADCV3_DATA_MASK0x3ff
> +
>  #define TSADCV2_HIGHT_INT_DEBOUNCE_COUNT 4
>  #define TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT   4
>  #define TSADCV2_AUTO_PERIOD_TIME 250 /* msec */
> @@ -164,6 +165,45 @@ static const struct tsadc_table v2_code_table[] = {
>   {3421, 125000},
>  };
>  
> +static const struct tsadc_table v3_code_table[] = {
> + {0, -4},
> + {106, -4},
> + {108, -35000},
> + {110, -3},
> + {112, -25000},
> + {114, -2},
> + {116, -15000},
> + {118, -1},
> + {120, -5000},
> + {122, 0},
> + {124, 5000},
> + {126, 1},
> + {128, 15000},
> + {130, 2},
> + {132, 25000},
> + {134, 3},
> + {136, 35000},
> + {138, 4},
> + {140, 45000},
> + {142, 5},
> + {144, 55000},
> + {146, 6},
> + {148, 65000},
> + {150, 7},
> + {152, 75000},
> + {154, 8},
> + {156, 85000},
> + {158, 9},
> + {160, 95000},
> + {162, 10},
> + {163, 105000},
> + {165, 11},
> + {167, 115000},
> + {169, 12},
> + {171, 125000},
> + {TSADCV3_DATA_MASK, 125000},
> +};
> +
>  static u32 rk_tsadcv2_temp_to_code(long temp)
>  {
>   int high, low, mid;
> @@ -227,16 +267,83 @@ static int rk_tsadcv2_code_to_temp(u32 code, int *temp)
>   return 0;
>  }
>  
> +static u32 rk_tsadcv3_temp_to_code(long temp)
> +{
> + int high, low, mid;
> +
> + low = 0;
> + high = ARRAY_SIZE(v3_code_table) - 1;
> + mid = (high + low) / 2;
> +
> + if (temp < v3_code_table[low].temp || temp > v3_code_table[high].temp)
> + return 0;

How is this different from v2 conversion except for the table being
used? I think you should be able to reuse the conversion routines if you
pass the conversion table in as a parameter.

Thanks.

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

Re: [PATCH 2/2] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Mon, 21 Sep 2015 09:35:51 -0700
David Daney  wrote:

> On 09/21/2015 08:58 AM, Marc Zyngier wrote:
> > On Fri, 18 Sep 2015 10:54:02 -0700
> > David Daney  wrote:
> >
> >> On 09/18/2015 01:51 AM, Marc Zyngier wrote:
> >>> On Thu, 17 Sep 2015 11:00:59 -0700
> >>> David Daney  wrote:
> >>>
> >>> Hi David,
> >>>
>  From: David Daney 
> 
>  Search up the device hierarchy to find devices with a "msi-map"
>  property, if found apply the mapping to the GIC device id.
> 
>  Signed-off-by: David Daney 
>  ---
> drivers/irqchip/irq-gic-v3-its-pci-msi.c | 73 
>  
> 1 file changed, 73 insertions(+)
> 
>  diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
>  b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>  index cf351c6..aa61cef 100644
>  --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>  +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>  @@ -73,6 +73,8 @@ static int its_pci_msi_prepare(struct irq_domain 
>  *domain, struct device *dev,
>   struct pci_dev *pdev;
>   struct its_pci_alias dev_alias;
>   struct msi_domain_info *msi_info;
>  +struct device *parent_dev;
>  +struct device_node *msi_controller_node = NULL;
> 
>   if (!dev_is_pci(dev))
>   return -EINVAL;
>  @@ -84,6 +86,77 @@ static int its_pci_msi_prepare(struct irq_domain 
>  *domain, struct device *dev,
>   dev_alias.count = nvec;
> 
>   pci_for_each_dma_alias(pdev, its_get_pci_alias, _alias);
>  +/*
>  + * Walk up the device parent links looking for one with a
>  + * "msi-map" property.
>  + */
> >>>
> >>> My first objection is the location of this parsing. It shouldn't be
> >>> driver specific, but instead be part of the generic OF handling
> >>> (nothing in these properties is GICv3 specific, even if the ITS is the
> >>> only user so far).
> >>
> >> OK, I agree that this should eventually end up in generic OF handling
> >> code.  I just wanted to get something out to initiate discussion.
> >>
> >> The next patch revision will move this to a more generic home.
> >>
> >>>
>  +for (parent_dev = dev; parent_dev; parent_dev = 
>  parent_dev->parent) {
> >>>
> >>> Is there a limit how far we should go up the parent chain to find a
> >>> msi-map? My hunch is that you should stop at the first device that does
> >>> have an of_node, as it is the one that should contain the msi-map
> >>> property.
> >>
> >> I think there is the possibility of finding something like a bridge that
> >> has an of_node, but does not have the "msi-map" property.  I currently
> >> have exactly this configuration, as some of the on-SoC devices sit
> >> behind a bridge, but need an of_node to obtain unprobable properties and
> >> children (the MDIO bus devices are like this).
> >>
> >> So if we want to abort the walk early, we should at least go up until we
> >> find "msi-map" in the of_node.
> >
> > I don't really see a case where we would traverse a series of nodes
> > where the msi-map property wouldn't be in the first node. Could you
> > please give me an example?
> >
> 
> OK, how about this:

[...]

> The "msi-map" is specified in the PICe host controller node, but there
> is a bridge between the device generating interrupts "bgx0" and the
> host controller.

OK, I can now see why you're doing that, thanks.


> >> The PCI host may have many MSI controllers, but I think a given PCI
> >> device will have only one (based on bus:devfn) that is looked up in the 
> >> map.
> >
> > A PCI device will only be configured to talk to a single MSI
> > controller, but here you stop parsing the msi-map on the first match,
> > and assume that you must have found the right MSI controller:
> >
> > I think this should read:
> >
> > +   if (masked_devid < rid_base ||
> > +   masked_devid >= rid_base + rid_len ||
> > domain->of_node != 
> > of_find_node_by_phandle(phandle)) {
> > +   msi_map_len -= 4 * sizeof(__be32);
> > +   msi_map += 4;
> > +   continue;
> > +   }
> > +   matched = true;
> > +   break;
> >
> 
> Good, I will incorporate that too.
> 
> In practice, I don't know if we would ever find a system with multiple 
> "msi-map" on a path from the device to the root, but we should probably 
> attempt to handle it "just in case".

There are systems in the wild with exactly that kind of topology, and
I'd like to support them out of the box.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a 

Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC

[Harini Katakam]

On Fri, Sep 11, 2015 at 1:27 PM, Harini Katakam
 wrote:
> Cadence GEM in Zynq Ultrascale+ MPSoC supports 1588 and provides a
> 102 bit time counter with 48 bits for seconds, 30 bits for nsecs and
> 24 bits for sub-nsecs. The timestamp is made available to the SW through
> registers as well as (more precisely) through upper two words in
> an extended BD.
>
> This patch does the following:
> - Adds MACB_CAPS_TSU in zynqmp_config.
> - Registers to ptp clock framework (after checking for timestamp support in
>   IP and capability in config).
> - TX BD and RX BD control registers are written to populate timestamp in
>   extended BD words.
> - Timer initialization is done by writing time of day to the timer counter.
> - ns increment register is programmed as NS_PER_SEC/TSU_CLK.
>   For a 24 bit subns precision, the subns increment equals
>   remainder of (NS_PER_SEC/TSU_CLK) * (2^24).
>   TSU (Time stamp unit) clock is obtained by the  driver from devicetree.
> - HW time stamp capabilities are advertised via ethtool and macb ioctl is
>   updated accordingly.
> - For all PTP event frames, nanoseconds and the lower 5 bits of seconds are
>   obtained from the BD. This offers a precise timestamp. The upper bits
>   (which dont vary between consecutive packets) are obtained from the
>   TX/RX PTP event/PEER registers. The timestamp obtained thus is updated
>   in skb for upper layers to access.
> - The drivers register functions with ptp to perform time and frequency
>   adjustment.
> - Time adjustment is done by writing to the 1558_ADJUST register.
>   The controller will read the delta in this register and update the timer
>   counter register. Alternatively, for large time offset adjustments,
>   the driver reads the secs and nsecs counter values, adds/subtracts the
>   delta and updates the timer counter. In order to be as precise as possible,
>   nsecs counter is read again if secs has incremented during the counter read.
> - Frequency adjustment is not directly supported by this IP.
>   addend is the initial value ns increment and similarly addendesub.
>   The ppb (parts per billion) provided is used as
>   ns_incr = addend +/- (ppb/rate).
>   Similarly the remainder of the above is used to populate subns increment.
>   In case the ppb requested is negative AND subns adjustment greater than
>   the addendsub, ns_incr is reduced by 1 and subns_incr is adjusted in
>   positive accordingly.
>
> Signed-off-by: Harini Katakam :
> ---
>  drivers/net/ethernet/cadence/macb.c |  372 
> ++-
>  drivers/net/ethernet/cadence/macb.h |   64 ++
>  2 files changed, 428 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c 
> b/drivers/net/ethernet/cadence/macb.c
> index bb2932c..b531008 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -30,6 +30,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #include "macb.h"
>
> @@ -56,6 +58,9 @@
>
>  #define GEM_MTU_MIN_SIZE   68
>
> +#define GEM_TX_PTPHDR_OFFSET   42
> +#define GEM_RX_PTPHDR_OFFSET   28
> +
>  /*
>   * Graceful stop timeouts in us. We should allow up to
>   * 1 frame time (10 Mbits/s, full-duplex, ignoring collisions)
> @@ -165,6 +170,9 @@ static void macb_set_hwaddr(struct macb *bp)
> top = cpu_to_le16(*((u16 *)(bp->dev->dev_addr + 4)));
> macb_or_gem_writel(bp, SA1T, top);
>
> +   gem_writel(bp, RXPTPUNI, bottom);
> +   gem_writel(bp, TXPTPUNI, bottom);
> +
> /* Clear unused address register sets */
> macb_or_gem_writel(bp, SA2B, 0);
> macb_or_gem_writel(bp, SA2T, 0);
> @@ -653,6 +661,40 @@ static void macb_tx_error_task(struct work_struct *work)
> spin_unlock_irqrestore(>lock, flags);
>  }
>
> +static inline void macb_handle_txtstamp(struct macb *bp, struct sk_buff *skb,
> +   struct macb_dma_desc *desc)
> +{
> +   u32 ts_s, ts_ns;
> +   u8 msg_type;
> +
> +   skb_copy_from_linear_data_offset(skb, GEM_TX_PTPHDR_OFFSET,
> +_type, 1);
> +
> +   /* Bit[32:6] of TS secs from register
> +* Bit[5:0] of TS secs from BD
> +* TS nano secs is available in BD
> +*/
> +   if (msg_type & 0x2) {
> +   /* PTP Peer Event Frame packets */
> +   ts_s = (gem_readl(bp, 1588PEERTXSEC) & GEM_SEC_MASK) |
> +  ((desc->tsl >> GEM_TSL_SEC_RS) |
> +  (desc->tsh << GEM_TSH_SEC_LS));
> +   ts_ns = desc->tsl & GEM_TSL_NSEC_MASK;
> +   } else {
> +   /* PTP Event Frame packets */
> +   ts_s = (gem_readl(bp, 1588TXSEC) & GEM_SEC_MASK) |
> +  ((desc->tsl >> GEM_TSL_SEC_RS) |
> +  (desc->tsh << GEM_TSH_SEC_LS));
> +   ts_ns = desc->tsl & GEM_TSL_NSEC_MASK;
> +   }
> +
> +   struct 

Re: [RFC PATCH 2/3] dtc: make check test for dtc --annotate

[Frank Rowand]

On 9/20/2015 11:33 PM, David Gibson wrote:
> On Tue, Sep 15, 2015 at 09:24:59PM -0700, Frank Rowand wrote:
>> From: Frank Rowand 
>>
>> Add dtc tests.
>>
>>   - dtc --annotate to create a .dts with annotations
>>   - compile the annotated .dts
>>
>> Not-signed-off-by: Frank Rowand 
> 
> It'd be nice to make this test a bit less trivial by actually
> comparing the output against a sample.  Maybe for tests/include0.dts
> to give it a real workout.

I'll add a comparison test.


> 
>> ---
>>  tests/run_tests.sh |3 +++
>>  1 file changed, 3 insertions(+)
>>
>> Index: b/tests/run_tests.sh
>> ===
>> --- a/tests/run_tests.sh
>> +++ b/tests/run_tests.sh
>> @@ -276,6 +276,9 @@ libfdt_tests () {
>>  run_dtc_test -I dts -O dtb -o sourceoutput.test.dts.test.dtb 
>> sourceoutput.test.dts
>>  run_test dtbs_equal_ordered sourceoutput.test.dtb 
>> sourceoutput.test.dts.test.dtb
>>  
>> +run_dtc_test --annotate -o sourceoutput.test.annotate.dts 
>> sourceoutput.dts
>> +run_dtc_test -o sourceoutput.test.annotate.dts.test.dts 
>> sourceoutput.test.annotate.dts
>> +
>>  run_dtc_test -I dts -O dtb -o embedded_nul.test.dtb embedded_nul.dts
>>  run_dtc_test -I dts -O dtb -o embedded_nul_equiv.test.dtb 
>> embedded_nul_equiv.dts
>>  run_test dtbs_equal_ordered embedded_nul.test.dtb 
>> embedded_nul_equiv.test.dtb
> 

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

[PATCH] ARM: dts: exynos4412-odroid: remove redundant pinctrl settings

[Tobias Jakobi]

The pinctrl settings in i2c_0 and i2c_1 are already provided
through the exynos4 dtsi.

Signed-off-by: Tobias Jakobi 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3f8bc7b..3c34e74 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -217,8 +217,6 @@
 };
 
 _0 {
-   pinctrl-0 = <_bus>;
-   pinctrl-names = "default";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <40>;
status = "okay";
@@ -444,8 +442,6 @@
 };
 
 _1 {
-   pinctrl-names = "default";
-   pinctrl-0 = <_bus>;
status = "okay";
max98090: max98090@10 {
compatible = "maxim,max98090";
@@ -460,8 +456,6 @@
 
 _2 {
status = "okay";
-   pinctrl-names = "default";
-   pinctrl-0 = <_bus>;
 };
 
 _8 {
-- 
2.0.5

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

[PATCH] ARM: dts: exynos4412-odroid: unify voltage regulator style

[Tobias Jakobi]

Use 'ldoN_reg: LDON' syntax and drop the deprecated
'regulator-compatible' property.

Signed-off-by: Tobias Jakobi 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 518230f..9f381bd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -294,15 +294,13 @@
regulator-always-on;
};
 
-   ldo8_reg: ldo@8 {
-   regulator-compatible = "LDO8";
+   ldo8_reg: LDO8 {
regulator-name = "VDD10_HDMI_1.0V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
};
 
-   ldo10_reg: ldo@10 {
-   regulator-compatible = "LDO10";
+   ldo10_reg: LDO10 {
regulator-name = "VDDQ_MIPIHSI_1.8V";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-- 
2.0.5

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

Re: [alsa-devel] [PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

[Jyri Sarha]

On 09/21/15 18:08, Clemens Ladisch wrote:

>But there is no downside in using prepare callback.

The prepare callback also can be called multiple times.  This certainly
happens when the stream is stopped/restarted multiple times.

If something does not need to be done again when a stream is restarted,
then it should be done in the hw_params callback.


Oh, forgot about that. This would suggest to keep the stream header 
configuration in the hw_params().


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

Re: [RFC PATCH 1/3] net: macb: Add support for extended BD with a config option

[Harini Katakam]

On Fri, Sep 11, 2015 at 1:27 PM, Harini Katakam
 wrote:
> Cadence GEM supports extended buffer descriptors.
> This patch adds a config option to enable use of extended BD.
> This adds two extra words to the TX BD and RX BD by configuring the
> necessary registers. Corresponding variables are added to the
> macb_dma_desc structure.
>
> Signed-off-by: Harini Katakam 
> ---
>  drivers/net/ethernet/cadence/Kconfig |8 
>  drivers/net/ethernet/cadence/macb.c  |4 
>  drivers/net/ethernet/cadence/macb.h  |8 
>  3 files changed, 20 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig 
> b/drivers/net/ethernet/cadence/Kconfig
> index f0bcb15..33e4198 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -31,4 +31,12 @@ config MACB
>   To compile this driver as a module, choose M here: the module
>   will be called macb.
>
> +config MACB_EXT_BD
> +   tristate "Cadence MACB/GEM extended buffer descriptor"
> +   depends on HAS_DMA && MACB
> +   ---help---
> + The Cadence MACB host supports use of extended buffer descriptor.
> + This option enables additon of two extra words to TX BD and RX BD.
> + These two extra words are currently used to obtain PTP timestamp.
> +
>  endif # NET_CADENCE
> diff --git a/drivers/net/ethernet/cadence/macb.c 
> b/drivers/net/ethernet/cadence/macb.c
> index 88c1e1a..bb2932c 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -1665,6 +1665,10 @@ static void macb_configure_dma(struct macb *bp)
> dmacfg |= GEM_BIT(TXCOEN);
> else
> dmacfg &= ~GEM_BIT(TXCOEN);
> +#ifdef CONFIG_MACB_EXT_BD
> +   dmacfg |= GEM_BIT(RXBDEXT);
> +   dmacfg |= GEM_BIT(TXBDEXT);
> +#endif
> netdev_dbg(bp->dev, "Cadence configure DMA with 0x%08x\n",
>dmacfg);
> gem_writel(bp, DMACFG, dmacfg);
> diff --git a/drivers/net/ethernet/cadence/macb.h 
> b/drivers/net/ethernet/cadence/macb.h
> index 6e1faea..58c9870 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -244,6 +244,10 @@
>  #define GEM_RXBS_SIZE  8
>  #define GEM_DDRP_OFFSET24 /* disc_when_no_ahb */
>  #define GEM_DDRP_SIZE  1
> +#define GEM_RXBDEXT_OFFSET 28 /* Extended RX BD */
> +#define GEM_RXBDEXT_SIZE   1
> +#define GEM_TXBDEXT_OFFSET 29 /* Extended TX BD */
> +#define GEM_TXBDEXT_SIZE   1
>
>
>  /* Bitfields in NSR */
> @@ -466,6 +470,10 @@
>  struct macb_dma_desc {
> u32 addr;
> u32 ctrl;
> +#ifdef CONFIG_MACB_EXT_BD
> +   u32 tsl;
> +   u32 tsh;
> +#endif
>  };
>
>  /* DMA descriptor bitfields */
> --
> 1.7.9.5
>

Any comment on this?

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

Re: [PATCH v2] dmaengine: vdma: Add 64 bit addressing support to the driver

[Vinod Koul]

On Thu, Aug 27, 2015 at 09:19:18PM +0530, Anurag Kumar Vulisha wrote:
> This VDMA  is a soft ip, which can be programmed to support
> 32 bit addressing or greater than 32 bit addressing.
> 
> When the VDMA ip is configured for 32 bit address space the
> transfer start address is specified by a single register.

would be good to specfiy which one

> When the  VDMA core is configured for an address space greater
> than 32 then each start address is specified by a combination
> of two registers. The first register specifies the LSB 32 bits
> of address, while the next register specifies the MSB 32 bits
> of address.For example,5Ch will specify the LSB 32 bits while
> 60h will specify the MSB 32 bits of the first start address.So
> we need to program two registers at a time.

can we have spaces after full stops and commas!

> +/* Since vdma driver is trying to write to a register offset which is not a
> + * multiple of 64 bits(ex : 0x5c), we are writing as two separate 32 bits
> + * instead of a single 64 bit register write.
> + */

This is not kernel style for multi-lines, pls refer to
Documentation/CodingStyle

> +
> +static inline void vdma_desc_write_64(struct xilinx_vdma_chan *chan, u32 reg,
> +  u32 value_lsb, u32 value_msb)
> +{
> + /* Write the lsb 32 bits*/
> + writel(value_lsb, chan->xdev->regs + chan->desc_offset + reg);
> +
> + /* Write the msb 32 bits */
> + writel(value_msb, chan->xdev->regs + chan->desc_offset + reg + 4);

why not writeq

> + err = of_property_read_u32(node, "xlnx,addrwidth", _width);
> +
> + if (err < 0) {
> + /* Setting addr_width property to default 32 bits */
> + addr_width = 32;
> + }

braces for a single line statement! Also space is redandant before if
condition

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

[PATCH] Documentation: dt-bindings: Fix interrupt documentation file path

[Andrew F. Davis]

Fix the incorrect interrupt documentation file path in binding docs.

Signed-off-by: Andrew F. Davis 
---
 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt | 2 +-
 Documentation/devicetree/bindings/mfd/arizona.txt  | 2 +-
 Documentation/devicetree/bindings/mfd/palmas.txt   | 2 +-
 Documentation/devicetree/bindings/sound/wm8994.txt | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
index dd5d2c0..4d6c8cd 100644
--- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -24,7 +24,7 @@ controller.
 - #interrupt-cells : Specifies the number of cells needed to encode an
   interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
   the second encodes the triger flags encoded as described in
-  Documentation/devicetree/bindings/interrupts.txt
+  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 - interrupt-parent : The parent interrupt controller.
 - interrupts : The interrupt to the parent controller raised when GPIOs
   generate the interrupts.
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
b/Documentation/devicetree/bindings/mfd/arizona.txt
index a8fee60..3d361ec 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -24,7 +24,7 @@ Required properties:
   - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
 The first cell is the IRQ number.
 The second cell is the flags, encoded as the trigger masks from
-Documentation/devicetree/bindings/interrupts.txt
+Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 
   - gpio-controller : Indicates this device is a GPIO controller.
   - #gpio-cells : Must be 2. The first cell is the pin number and the
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt 
b/Documentation/devicetree/bindings/mfd/palmas.txt
index eda8989..8ae1a32 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -24,7 +24,7 @@ and also the generic series names
 - #interrupt-cells : should be set to 2 for IRQ number and flags
   The first cell is the IRQ number.
   The second cell is the flags, encoded as the trigger masks from
-  Documentation/devicetree/bindings/interrupts.txt
+  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 - interrupt-parent : The parent interrupt controller.
 
 Optional properties:
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt 
b/Documentation/devicetree/bindings/sound/wm8994.txt
index e045e90..68c4e8d 100644
--- a/Documentation/devicetree/bindings/sound/wm8994.txt
+++ b/Documentation/devicetree/bindings/sound/wm8994.txt
@@ -30,7 +30,7 @@ Optional properties:
   - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
 The first cell is the IRQ number.
 The second cell is the flags, encoded as the trigger masks from
-Documentation/devicetree/bindings/interrupts.txt
+Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 
   - clocks : A list of up to two phandle and clock specifier pairs
   - clock-names : A list of clock names sorted in the same order as clocks.
-- 
1.9.1

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

Re: [PATCH 2/2] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[David Daney]

On 09/21/2015 08:58 AM, Marc Zyngier wrote:

On Fri, 18 Sep 2015 10:54:02 -0700
David Daney  wrote:


On 09/18/2015 01:51 AM, Marc Zyngier wrote:

On Thu, 17 Sep 2015 11:00:59 -0700
David Daney  wrote:

Hi David,


From: David Daney 

Search up the device hierarchy to find devices with a "msi-map"
property, if found apply the mapping to the GIC device id.

Signed-off-by: David Daney 
---
   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 73 

   1 file changed, 73 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index cf351c6..aa61cef 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -73,6 +73,8 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
struct device *dev,
struct pci_dev *pdev;
struct its_pci_alias dev_alias;
struct msi_domain_info *msi_info;
+   struct device *parent_dev;
+   struct device_node *msi_controller_node = NULL;

if (!dev_is_pci(dev))
return -EINVAL;
@@ -84,6 +86,77 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
struct device *dev,
dev_alias.count = nvec;

pci_for_each_dma_alias(pdev, its_get_pci_alias, _alias);
+   /*
+* Walk up the device parent links looking for one with a
+* "msi-map" property.
+*/


My first objection is the location of this parsing. It shouldn't be
driver specific, but instead be part of the generic OF handling
(nothing in these properties is GICv3 specific, even if the ITS is the
only user so far).


OK, I agree that this should eventually end up in generic OF handling
code.  I just wanted to get something out to initiate discussion.

The next patch revision will move this to a more generic home.




+   for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {


Is there a limit how far we should go up the parent chain to find a
msi-map? My hunch is that you should stop at the first device that does
have an of_node, as it is the one that should contain the msi-map
property.


I think there is the possibility of finding something like a bridge that
has an of_node, but does not have the "msi-map" property.  I currently
have exactly this configuration, as some of the on-SoC devices sit
behind a bridge, but need an of_node to obtain unprobable properties and
children (the MDIO bus devices are like this).

So if we want to abort the walk early, we should at least go up until we
find "msi-map" in the of_node.


I don't really see a case where we would traverse a series of nodes
where the msi-map property wouldn't be in the first node. Could you
please give me an example?



OK, how about this:

pcie0: pcie0@8480, {
compatible = "pci-host-ecam-generic";
device_type = "pci";
msi-parent = <>;
msi-map = <0  0x8 0x1>;
bus-range = <0 255>;
#size-cells = <2>;
#address-cells = <3>;
#stream-id-cells = <1>;
reg = <0x8480 0x 0 0x1000>;/* Configuration 
space */
		ranges = <0x0300 0x8010 0x 0x8010 0x 0x070 
0x>, /* mem ranges */

 <0x0300 0x87e0 0x 0x87e0 0x 0x020 
0x>;

/* Other devices that use MSI, like USB xHCI, are here
on the same bus as the bridge.  They have no firmware
node as sufficient information can be probed as part
of normal PCI probing. */

mrml-bridge0@1,0 {
compatible = "cavium,thunder-8890-mrml-bridge";
#size-cells = <2>;
#address-cells = <3>;
			ranges = <0x0300 0x87e0 0x 0x0300 0x87e0 0x 
0x10 0x>;

reg = <0x0800 0 0 0 0>; /* DEVFN = 0x08 (1:0) */

mdio-nexus@1,3 {
compatible = "cavium,thunder-8890-mdio-nexus";
#address-cells = <2>;
#size-cells = <2>;
reg = <0x0b00 0 0 0 0>; /* DEVFN = 0x0b (1:3) */
assigned-addresses = <0x0300 0x87e0 0x0500 
0x0 0x80>;
ranges = <0x87e0 0x0500 0x0300 0x87e0 
0x0500 0x0 0x80>;

mdio0@87e0,05003800 {
compatible = "cavium,thunder-8890-mdio";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x87e0 0x05003800 0x0 0x30>;

[PATCH v2 6/6] arm64: dts: berlin4ct: add default pinmux for uart0

[Jisheng Zhang]

Add urt0 txd and rxd muxing setup in the dtsi because uart0 always uses
them to work, no other possibilities.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
index c374f1d..e9409ec 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
@@ -288,12 +288,19 @@
clocks = <>;
reg-shift = <2>;
status = "disabled";
+   pinctrl-0 = <_pmux>;
+   pinctrl-names = "default";
};
};
 
sm_pinctrl: pinctrl@fe2200 {
compatible = "marvell,berlin4ct-sm-pinctrl";
reg = <0xfe2200 0xc>;
+
+   urt0_pmux: urt0-pmux {
+   groups = "SM_URT0_TXD", "SM_URT0_RXD";
+   function = "urt0";
+   };
};
};
 };
-- 
2.5.3

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

[GIT PULL]Hisilicon arm64 dt changes for 4.3

[Wei Xu]

Hi Arnd, Hi Olof, Hi Kevin,

Please help to pull the following changes.
Thanks!

Best Regards,
Wei

---

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://github.com/hisilicon/linux-hisi.git tags/hip05-dt-for-4.3

for you to fetch changes up to fcab303c015397c307ae4873e02598f89a4a3ef6:

  arm64: dts: add dts files for Hisilicon Hip05-D02 Development Board 
(2015-09-21 15:50:50 +0100)


ARM64: DT: Hisilicon hip05 soc and D02 board updates for 4.3

- Updated the hisilicon devicetree bindings document to support hip05-D02 board
- Added dts files for hip05 SoC and D02 board


Ding Tianhong (2):
  arm64: hip05-d02: Document devicetree bindings for Hisilicon Hip05-D02 
Board
  arm64: dts: add dts files for Hisilicon Hip05-D02 Development Board

 Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt |   4 ++
 arch/arm64/boot/dts/hisilicon/Makefile|   2 +-
 arch/arm64/boot/dts/hisilicon/hip05-d02.dts   |  36 
++
 arch/arm64/boot/dts/hisilicon/hip05.dtsi  | 271 
+++
 4 files changed, 312 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/hisilicon/hip05-d02.dts
 create mode 100644 arch/arm64/boot/dts/hisilicon/hip05.dtsi




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

Re: [PATCH 2/3] ASoC: da7219: Add bindings documentation for DA7219 audio codec

[Mark Brown]

On Mon, Sep 21, 2015 at 10:36:04AM +, Opensource [Adam Thomson] wrote:
> On September 19, 2015 18:10, Mark Brown wrote:

> > > +- dlg,cp-mchange : Charge pump voltage tracking mode
> > > + ["largest_vol", "dac_vol", "sig_mag"]
> > > +- dlg,cp-vol-thresh : Charge pump volume threshold value (6-bit value)
> > > + [ 0 - 0x3F ]

> > Why are these in the device tree rather than runtime parameters?

> From previous internal discussions, these seemed to be fire and forget
> parameters, hence their inclusion in the DT binding, rather than as controls.
> Personally didn't see either needing runtime updates.

Make them runtime configurable.  People can do an at boot runtime
configuration if they like.

> 
> > > +Required properties:
> > > +- interrupt-parent : Specifies the phandle of the interrupt controller 
> > > to which
> > > +  the IRQs from DA7219 AAD block are delivered to.
> > > +- interrupts : IRQ line info for DA7219 AAD block.
> > > +  (See 
> > > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
> > > +   further information relating to interrupt properties)

> > Why is this not specified at the device level (the device does not
> > appear to support other interrupts)?

> Given the way that the driver code was structured, and that the IRQ is only 
> used
> for accessory detection, I added it to the child node. The other option would
> be to flatten out bindings, and remove the child node. Felt like keeping the
> accessory detect items separate though was a sensible approach. What is your
> feeling on this?

The child node is fine for collecting the parameters but the chip
interrupt line should be at the chip level.


signature.asc
Description: Digital signature

Re: [PATCH 2/3] mfd: tps65912: Rewrite driver adding DT support and using regmap

[Andrew F. Davis]

On 09/19/2015 01:40 PM, Mark Brown wrote:

On Tue, Sep 15, 2015 at 12:57:40PM -0500, Andrew F. Davis wrote:

The old driver does not support DT. Rewrite the driver adding DT support
and use modern kernel features such as regmap and related helpers.

Signed-off-by: Andrew F. Davis 
---
  drivers/gpio/gpio-tps65912.c   | 291 ++--
  drivers/mfd/Kconfig|  20 +-
  drivers/mfd/Makefile   |   3 +-
  drivers/mfd/tps65912-core.c| 288 +---
  drivers/mfd/tps65912-i2c.c | 233 --
  drivers/mfd/tps65912-irq.c | 217 -
  drivers/mfd/tps65912-spi.c | 236 --
  drivers/regulator/tps65912-regulator.c | 783 ++---
  include/linux/mfd/tps65912.h   | 256 +++
  9 files changed, 854 insertions(+), 1473 deletions(-)


It's not OK to have a single commit that rewrites multiple drivers over
many subsystems, that's really not something that can be sensibly
reviewed.  You should split this into a patch series which makes one
specific change at a time as covered in SubmittingPatches.  That will
allow the changes to be reviewed much more sensibly.



I know this is hard to review, and so I would like to apologize in advance, but
the regulator and GPIO changes depend on the new driver core, as do the i2c/spi
components. I really don't know how to split this up without leaving some part
in a non-working state in-between patches (which I've heard is also not OK).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html