[PATCH 2/2] arm64: dts: r8a7795: Add L2 cache-controller nodes

[Dirk Behme]

From: Geert Uytterhoeven 

Add device nodes for the L2 caches, and link the CPU node to its L2
cache node.

The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as
128 KiB x 16 ways).

The L2 cache for the Cortex-A53 CPU cores is 512 KiB large (organized as
32 KiB x 16 ways).

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Dirk Behme 
---
Note: Geert: I picked your patch from

http://www.spinics.net/lists/arm-kernel/msg466628.html

incoporated some review comments and rebased it against

https://git.kernel.org/cgit/linux/kernel/git/horms/renesas.git/log/?h=next 
renesas-next-20151211v2-v4.4-rc1 

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 3633a2a..d63a70f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -39,6 +39,7 @@
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x0>;
device_type = "cpu";
+   next-level-cache = <&L2_CA57>;
enable-method = "psci";
};
 
@@ -46,46 +47,61 @@
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x1>;
device_type = "cpu";
+   next-level-cache = <&L2_CA57>;
enable-method = "psci";
};
a57_2: cpu@2 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x2>;
device_type = "cpu";
+   next-level-cache = <&L2_CA57>;
enable-method = "psci";
};
a57_3: cpu@3 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x3>;
device_type = "cpu";
+   next-level-cache = <&L2_CA57>;
enable-method = "psci";
};
a53_0: cpu@100 {
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x100>;
device_type = "cpu";
+   next-level-cache = <&L2_CA53>;
enable-method = "psci";
};
a53_1: cpu@101 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x101>;
device_type = "cpu";
+   next-level-cache = <&L2_CA53>;
enable-method = "psci";
};
a53_2: cpu@102 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x102>;
device_type = "cpu";
+   next-level-cache = <&L2_CA53>;
enable-method = "psci";
};
a53_3: cpu@103 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x103>;
device_type = "cpu";
+   next-level-cache = <&L2_CA53>;
enable-method = "psci";
};
};
 
+   L2_CA57: cache-controller@0 {
+   compatible = "cache";
+   };
+
+   L2_CA53: cache-controller@1 {
+   compatible = "cache";
+   };
+
extal_clk: extal {
compatible = "fixed-clock";
#clock-cells = <0>;
-- 
2.6.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/2] arm64: dts: r8a7795: Add Cortex-A53 CPU cores

[Dirk Behme]

From: Takeshi Kihara 

This patch adds Cortex-A53 CPU cores to r8a7795 SoC for a total of 8
cores (4 x Cortex-A57 + 4 x Cortex-A53).

Signed-off-by: Takeshi Kihara 
Signed-off-by: Dirk Behme 
---
Note: This patch is picked from

https://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git/log/?h=v4.2/rcar-3.0.x

and rebased against

https://git.kernel.org/cgit/linux/kernel/git/horms/renesas.git/log/?h=next 
renesas-next-20151211v2-v4.4-rc1

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 46 +++-
 1 file changed, 39 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b9229a4..3633a2a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -60,6 +60,30 @@
device_type = "cpu";
enable-method = "psci";
};
+   a53_0: cpu@100 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x100>;
+   device_type = "cpu";
+   enable-method = "psci";
+   };
+   a53_1: cpu@101 {
+   compatible = "arm,cortex-a53","arm,armv8";
+   reg = <0x101>;
+   device_type = "cpu";
+   enable-method = "psci";
+   };
+   a53_2: cpu@102 {
+   compatible = "arm,cortex-a53","arm,armv8";
+   reg = <0x102>;
+   device_type = "cpu";
+   enable-method = "psci";
+   };
+   a53_3: cpu@103 {
+   compatible = "arm,cortex-a53","arm,armv8";
+   reg = <0x103>;
+   device_type = "cpu";
+   enable-method = "psci";
+   };
};
 
extal_clk: extal {
@@ -115,7 +139,7 @@
reg = <0x0 0xf101 0 0x1000>,
  <0x0 0xf102 0 0x2000>;
interrupts = ;
+   (GIC_CPU_MASK_SIMPLE(8) | 
IRQ_TYPE_LEVEL_HIGH)>;
};
 
gpio0: gpio@e605 {
@@ -235,23 +259,31 @@
interrupts = ,
 ,
 ,
-;
+,
+,
+,
+,
+;
interrupt-affinity = <&a57_0>,
 <&a57_1>,
 <&a57_2>,
-<&a57_3>;
+<&a57_3>,
+<&a53_0>,
+<&a53_1>,
+<&a53_2>,
+<&a53_3>;
};
 
timer {
compatible = "arm,armv8-timer";
interrupts = ,
+   (GIC_CPU_MASK_SIMPLE(8) | 
IRQ_TYPE_LEVEL_LOW)>,
 ,
+   (GIC_CPU_MASK_SIMPLE(8) | 
IRQ_TYPE_LEVEL_LOW)>,
 ,
+   (GIC_CPU_MASK_SIMPLE(8) | 
IRQ_TYPE_LEVEL_LOW)>,
 ;
+   (GIC_CPU_MASK_SIMPLE(8) | 
IRQ_TYPE_LEVEL_LOW)>;
};
 
cpg: clock-controller@e615 {
-- 
2.6.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 0/4] arm,arm64: uniphier: add a new driver, device tree updates

[Masahiro Yamada]

Hi Arnd,


Sorry for confusing you.

2015-12-12 9:12 GMT+09:00 Arnd Bergmann :
> On Tuesday 24 November 2015 18:39:18 Masahiro Yamada wrote:
>>
>> Here is another series for UniPhier SoC family:
>>
>>  - 1/4: add a new driver.  The UniPhier System Bus is an external bus
>> where on-board devices are connected to the SoC.
>> (please check if the binding specification is OK.)
>>
>>  - 2/4: device tree updates to use the driver added by 1/4
>>
>>  - 3/4: trivial rename of device node names
>>
>>  - 4/4: initial commit for ARMv8 SoC/Board device trees
>>
>> Please apply 2/4, 3/4/, 4/4 into the same branch because 4/4 depends on 2/4 
>> and 3/4.
>> (4/4 creates symbolic links to ARM device trees.)
>
> I'm a bit confused how this relates to the newer version ("[PATCH v5] bus:
> uniphier-system-bus: add UniPhier System Bus driver"). The new version
> only has one patch instead of four, so I'm not sure if the patches 2, 3
> and 4 of this series still apply.
>
> Can you clarify, or send the entire series again?
>
> Arnd


I'd like to retract this series.
Please just disregard it.


Instead, please review this one:
https://patchwork.kernel.org/patch/7714151/


Thanks!

-- 
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 v1 7/8] ARM: dts: rockchip: add core rk3228 dtsi

[Jeffy Chen]

Hi Heiko,

On 2015-12-11 18:12, Heiko Stübner wrote:

Hi Jeffy,

Am Freitag, 11. Dezember 2015, 09:53:59 schrieb Jeffy Chen:

On 2015-12-10 8:32, Heiko Stuebner wrote:

Am Mittwoch, 9. Dezember 2015, 17:04:12 schrieb Jeffy Chen:

Initial release for rk3228 shared dtsi.

Signed-off-by: Jeffy Chen 
---

   arch/arm/boot/dts/rk3228.dtsi | 478
   ++ 1 file changed, 478
   insertions(+)
   create mode 100644 arch/arm/boot/dts/rk3228.dtsi

diff --git a/arch/arm/boot/dts/rk3228.dtsi
b/arch/arm/boot/dts/rk3228.dtsi
new file mode 100644
index 000..d6b3e40
--- /dev/null
+++ b/arch/arm/boot/dts/rk3228.dtsi
@@ -0,0 +1,478 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "rockchip,rk3228";
+
+   interrupt-parent = <&gic>;
+
+   aliases {
+   serial0 = &uart0;
+   serial1 = &uart1;
+   serial2 = &uart2;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x6000 0x4000>;
+   };

The amount of memory is a property of the board

done.


+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;

no enable-method?

As the rk3228 also does not have a pmu, does the newly created
"rockchip,rk3036-smp" work for you?

unlucky, that doesn't work...and our 3.10 kernel is using psci for
rk3228's smp ops, maybe i should check that too, but i know nothing
about psci for now :(

Using PSCI on more rockchip socs will make the ARM people very happy ;-) .

So definitly no argument from me against it. I guess you should only need the
enable-method and psci node you should already have in your 3.10 dts, to
actually enable it.

cpu@xxx {
enable-method = "psci";
};

psci {
compatible = "arm,psci-0.2";
...
};


But we can of course add that in a later patch as well.


Heiko


yes, you're right~
after added psci node and enabled CONFIG_ARM_PSCI, it could bring up all 
cpus :


[0.090371] CPU0: thread -1, cpu 0, socket 15, mpidr 8f00
[0.091018] Setting up static identity map for 0x6010 - 0x60100058
[0.095260] CPU1: thread -1, cpu 1, socket 15, mpidr 8f01
[0.096648] CPU2: thread -1, cpu 2, socket 15, mpidr 8f02
[0.098070] CPU3: thread -1, cpu 3, socket 15, mpidr 8f03
[0.098228] Brought up 4 CPUs
[0.100145] SMP: Total of 4 processors activated (192.00 BogoMIPS).
[0.100732] CPU: All CPU(s) started in SVC mode.

patch coming :)

--
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 0/7] mtd: partitions: add of_match_table support

[Brian Norris]

On Fri, Dec 11, 2015 at 09:44:37AM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
>  wrote:
> > IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
> > and so I don't plan to do that sort of work myself. If you can provide
> > some better argument for it, and some nice maintainable code to go with
> > it, then of course it could be considered :)
> 
> There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
> working on have.

OK. But these flash are often used for the boot firmware, no? And then,
does the boot code have to be provided at one end of the flash (e.g.,
bottom)? If so, then something like MBR or GPT will likely not apply,
since they reserve the first (and sometimes last) blocks of the medium.

Brian
--
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 2/2] devicetree: Add DTS file to support the Nexus7 2013 (flo) device.

[John Stultz]

This patch adds a dts file to support the Nexus7 2013
device. Its based off of the qcom-apq8064-ifc6410.dts
which is similar hardware.

Also includes some comments and context folded in
from Vinay Simha BN 

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Russell King 
Cc: Vinay Simha BN 
Cc: devicetree@vger.kernel.org
Cc: Bjorn Andersson 
Signed-off-by: John Stultz 
---
v2: Included Bjorn's feedback. Patch applies against -next.

 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts | 276 +
 2 files changed, 277 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0fe130e..2148c62 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -510,6 +510,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
qcom-apq8064-sony-xperia-yuga.dtb \
+   qcom-apq8064-asus-nexus7-flo.dts \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts 
b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
new file mode 100644
index 000..c535b3f
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
@@ -0,0 +1,276 @@
+#include "qcom-apq8064-v2.0.dtsi"
+#include 
+#include 
+#include 
+/ {
+   model = "Asus Nexus7(flo)";
+   compatible = "asus,nexus7-flo", "qcom,apq8064";
+
+   aliases {
+   serial0 = &gsbi7_serial;
+   serial1 = &gsbi6_serial;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   ext_3p3v: regulator-fixed@1 {
+   compatible = "regulator-fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "ext_3p3v";
+   regulator-type = "voltage";
+   startup-delay-us = <0>;
+   gpio = <&tlmm_pinmux 77 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-boot-on;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   power {
+   label = "Power";
+   gpios = <&tlmm_pinmux 26 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   gpio-key,wakeup;
+   };
+   volume_up {
+   label = "Volume Up";
+   gpios = <&pm8921_gpio 4 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   };
+   volume_down {
+   label = "Volume Down";
+   gpios = <&pm8921_gpio 38 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   };
+   };
+
+   soc {
+   rpm@108000 {
+   regulators {
+   vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
+   vin_lvs1_3_6-supply = <&pm8921_s4>;
+   vin_lvs4_5_7-supply = <&pm8921_s4>;
+
+
+   vdd_l24-supply = <&pm8921_s1>;
+   vdd_l25-supply = <&pm8921_s1>;
+   vin_lvs2-supply = <&pm8921_s1>;
+
+   vdd_l26-supply = <&pm8921_s7>;
+   vdd_l27-supply = <&pm8921_s7>;
+   vdd_l28-supply = <&pm8921_s7>;
+
+   vdd_ncp-supply = <&pm8921_l6>;
+
+   /* Buck SMPS */
+   s1 {
+   regulator-always-on;
+   regulator-min-microvolt = <1225000>;
+   regulator-max-microvolt = <1225000>;
+   qcom,switch-mode-frequency = <320>;
+   bias-pull-down;
+   };
+
+   /* msm otg HSUSB_VDDCX */
+   s3 {
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <115>;
+   qcom,switch-mode-frequency = <480>;
+   };
+
+   /*
+* msm_sdcc.1-sdc-vdd_io
+* tabla2x-slim-CDC_VDDA_RX
+* tabla2x-slim-CDC_VDDA_TX
+* tabla2x-slim-CDC_VDD_CP
+* tabla2x-slim-VDDIO_CDC
+*/
+   s4 {
+  

[PATCH 1/2] devicetree: qcom-apq8064.dtsi: Add i2c3 address-cells and size-cells values

[John Stultz]

This adds address-cell and size-cell values to the i2c3 bus
in the qcom-apq8064.dtsi, which is needed to describe devices
on that bus.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Russell King 
Cc: Vinay Simha BN 
Cc: devicetree@vger.kernel.org
Cc: Bjorn Andersson 
Acked-by: Bjorn Andersson 
Signed-off-by: John Stultz 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 4e7f5cc..b61b754 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -337,6 +337,8 @@
clocks = <&gcc GSBI3_QUP_CLK>,
 <&gcc GSBI3_H_CLK>;
clock-names = "core", "iface";
+   #address-cells = <1>;
+   #size-cells = <0>;
};
};
 
-- 
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 0/4] arm: dts: qcom-apq8064: add smem and hwspinlock support

[Bjorn Andersson]

On Fri 11 Dec 10:26 PST 2015, Srinivas Kandagatla wrote:

> Hi Andy, 
> 
> Here are 3 patches for smem/hwspinlock which I have tested with QDSP on 
> IFC6410.
> Also a fix from Ivan which I think can be taken aswell.
> 

As far as I can tell my patch for adding smem and hwmutex are already in
linux-next, via Andy's tree. Am I missing something?

Regards,
Bjorn
--
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] arm,arm64: uniphier: add a new driver, device tree updates

[Arnd Bergmann]

On Tuesday 24 November 2015 18:39:18 Masahiro Yamada wrote:
> 
> Here is another series for UniPhier SoC family:
> 
>  - 1/4: add a new driver.  The UniPhier System Bus is an external bus
> where on-board devices are connected to the SoC.
> (please check if the binding specification is OK.)
> 
>  - 2/4: device tree updates to use the driver added by 1/4
> 
>  - 3/4: trivial rename of device node names
> 
>  - 4/4: initial commit for ARMv8 SoC/Board device trees
> 
> Please apply 2/4, 3/4/, 4/4 into the same branch because 4/4 depends on 2/4 
> and 3/4.
> (4/4 creates symbolic links to ARM device trees.)

I'm a bit confused how this relates to the newer version ("[PATCH v5] bus:
uniphier-system-bus: add UniPhier System Bus driver"). The new version
only has one patch instead of four, so I'm not sure if the patches 2, 3
and 4 of this series still apply.

Can you clarify, or send the entire series again?

Arnd
--
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] ARM: dts: rockchip: add core rk3228 dtsi

[Heiko Stübner]

Am Freitag, 11. Dezember 2015, 12:25:32 schrieb Heiko Stübner:
> Hi Jeffy,
> 
> Am Freitag, 11. Dezember 2015, 09:30:51 schrieb Jeffy Chen:
> > Initial release for rk3228 shared dtsi.
> > 
> > Signed-off-by: Jeffy Chen 
> 
> Booth dts look good now, just need to wait on Linus Walleij picking up the
> pinctrl patch first.

as the pinctrl change got picked up, I've now also applied the two dts 
patches. I've added the missing entry for 
Documentation/devicetree/bindings/arm/rockchip.txt myself now, please keep 
that in mind for future boards :-) .


Thanks
Heiko
--
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/2] ARM: dts: uniphier: clean up DTSIs by factoring the common parts out

[Arnd Bergmann]

On Thursday 03 December 2015 15:33:55 Masahiro Yamada wrote:
> Masahiro Yamada (2):
>   ARM: dts: uniphier: change IRQ number of UART3 of PH1-Pro4 SoC
>   ARM: dts: uniphier: factor out common nodes to uniphier-common32.dtsi
> 

Applied both to next/dt, thanks!

Arnd
--
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] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to function
as  an USB  OTG dual-role device.  In addition  to sensing/controlling Vbus,
the chip also passes thru the ID signal  from the USB  OTG connector.
On some Renesas boards,  this signal is  just fed into the SoC thru a GPIO
pin --  there's no real  OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd  like to allow host or gadget drivers
to be loaded depending on the cable type,  hence the need for the MAX3355
extcon driver. The Vbus status signals are also  wired to GPIOs (however, we
aren't currently interested in them),  the OFFVBUS# signal is controlled  by
the host controllers, there's  also the SHDN# signal wired to a GPIO, it
should be driven high for the  normal operation.

Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.

Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
  entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.

 Documentation/devicetree/bindings/extcon/extcon-max3355.txt |   21 +
 drivers/extcon/Kconfig  |8 
 drivers/extcon/Makefile |1 
 drivers/extcon/extcon-max3355.c |  153 
 4 files changed, 183 insertions(+)

Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO 
pin
+  connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+  connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+   usb-otg {
+   compatible = "maxim,max3355";
+   maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+   id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+   };
Index: extcon/drivers/extcon/Kconfig
===
--- extcon.orig/drivers/extcon/Kconfig
+++ extcon/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
  Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
  detector and switch.
 
+config EXTCON_MAX3355
+   tristate "Maxim MAX3355 USB OTG EXTCON Support"
+   help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
 config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: extcon/drivers/extcon/Makefile
===
--- extcon.orig/drivers/extcon/Makefile
+++ extcon/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
 obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
 obj-$(CONFIG_EXTCON_GPIO)  += extcon-gpio.o
 obj-$(CONFIG_EXTCON_MAX14577)  += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355)   += extcon-max3355.o
 obj-$(CONFIG_EXTCON_MAX77693)  += extcon-max77693.o
 obj-$(CONFIG_EXTCON_MAX77843)  += extcon-max77843.o
 obj-$(CONFIG_EXTCON_MAX8997)   += extcon-max8997.o
Index: extcon/drivers/extcon/extcon-max3355.c
===
--- /dev/null
+++ extcon/drivers/extcon/extcon-max3355.c
@@ -0,0 +1,153 @@
+/*
+ * Maxim Integrated MAX3355 USB OTG chip extcon driver
+ *
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ * Author: Sergei Shtylyov 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foun

Re: [PATCH 2/3] arm64: dts: apq8016-sbc: add label properties for UART, I2C, and SPI

[Kevin Hilman]

Rob Herring  writes:

> Add label properties to provide a way to identify UART, I2C and SPI
> ports based on their connector names. This follows naming convention in
> 96boards CE spec. Ports without external connections are not labelled.
>
> Signed-off-by: Rob Herring 
> Cc: Srinivas Kandagatla 
> Cc: Andy Gross 

Acked-by: Kevin Hilman 
Tested-by: Kevin Hilman 

Tested this on my db410c (along with script from cover letter) and it
works great.

Kevin
--
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] arm: dts: rockchip: Fix typo in rk32288 sdmmc card detect pin name

[Heiko Stübner]

Hi Matthias,

Am Freitag, 11. Dezember 2015, 15:45:58 schrieb Matthias Brugger:
> The card detect pin is currently called sdmcc-cd.
> This patch fixes the typo and renames the pin to sdmmc-cd.
> 
> Signed-off-by: Matthias Brugger 

applied to my dts32 branch for 4.5, after fixing the rk32288 in the subject


Thanks
Heiko
--
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] arm64: dts: r8a7795: Add Cortex-A57 CPU cores

[Simon Horman]

On Fri, Dec 04, 2015 at 02:38:52PM +0100, Dirk Behme wrote:
> From: Gaku Inami 
> 
> Add Cortex-A57 CPU cores to r8a7795 SoC for a total of 4 x Cortex-A57.
> 
> Signed-off-by: Gaku Inami 
> Signed-off-by: Takeshi Kihara 
> Sigend-off-by: Dirk Behme 

Thanks, I have queued this up for v4.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: [PATCH 3/3] arm64: dts: r8a7795: Add pmu device nodes

[Simon Horman]

On Fri, Dec 04, 2015 at 02:38:53PM +0100, Dirk Behme wrote:
> From: Yoshifumi Hosoya 
> 
> Enabling the performance monitor unit on r8a7795.
> 
> Signed-off-by: Masaru Nagai 
> Signed-off-by: Yoshifumi Hosoya 
> Sigend-off-by: Dirk Behme 

I took the liberty of correcting the spelling of "Signed" when
queuing up this patch for v4.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: [PATCH 1/3] arm64: dts: r8a7795: Add PSCI node

[Simon Horman]

On Fri, Dec 04, 2015 at 02:38:51PM +0100, Dirk Behme wrote:
> From: Gaku Inami 
> 
> Add PSCI node for r8a7795 SoC, and cpu node enable-method property is
> set to "psci".
> 
> Signed-off-by: Gaku Inami 
> Signed-off-by: Takeshi Kihara 
> Sigend-off-by: Dirk Behme 

I took the liberty of correcting the spelling of "Sigend" when
queueing this patch up for v4.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 v2] spi: dts: sun4i: Add support for inter-word wait cycles using the SPI Wait Clock Register

[Marcus Weseloh]

Adds support and binding documentation for a new slave device property
"sun4i,spi-word-wait-ns" that allows to set a hardware based delay
between the transmission of words using the SPI Wait Clock Register.
The SPI hardware needs 3 clock cycles to set up the delay, which makes
the minimum non-zero wait time 4 clock cycles.

Signed-off-by: Marcus Weseloh 
---
Changes from v1:
 * renamed the property for more clarity
 * wait time is set in nanoseconds instead of number of clock cycles
 * transparently handle the 3 setup clock cycles

There is one review comment that I didn't address: Rob Herring suggested
that this should be in the core-binding rather than in sun4i. I checked
many of the hardware manuals of other SPI drivers and it looks to me like
this hardware based inter-word delay is a feature that not many SPI
controllers offer. And the SPI core currently has no way to control an
inter-word delay, only inter-message. So I would like to propose this again
as a sun4i binding, as it targets a sun4i (or sunxi?) specific hardware
feature.
---
 .../devicetree/bindings/spi/spi-sun4i.txt  | 11 +++
 drivers/spi/spi-sun4i.c| 23 ++
 2 files changed, 34 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt 
b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
index de827f5..d6c55fc 100644
--- a/Documentation/devicetree/bindings/spi/spi-sun4i.txt
+++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
@@ -10,6 +10,10 @@ Required properties:
   - "mod": the parent module clock
 - clock-names: Must contain the clock names described just above
 
+Optional properties for slave devices:
+- sun4i,spi-word-wait-ns: hardware based delay in nanoseconds between
+ transmission of words
+
 Example:
 
 spi1: spi@01c06000 {
@@ -21,4 +25,11 @@ spi1: spi@01c06000 {
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+
+   spi1_0 {
+   compatible = "example,dummy";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   sun4i,spi-word-wait-ns = <12000>;
+   };
 };
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index f60a6d6..8cfd96c 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -173,6 +174,9 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
+   u32 wait_ns = 0;
+   int wait_clk = 0;
+   int clk_ns = 0;
 
/* We don't support transfer larger than the FIFO */
if (tfr->len > SUN4I_FIFO_DEPTH)
@@ -261,6 +265,25 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
 
sun4i_spi_write(sspi, SUN4I_CLK_CTL_REG, reg);
 
+   /* Setup wait time beteen words */
+   of_property_read_u32(spi->dev.of_node, "sun4i,spi-word-wait-ns",
+&wait_ns);
+   if (wait_ns) {
+   /* The wait time is set in SPI_CLK cycles. The SPI hardware
+* needs 3 additional cycles to setup the wait counter, so
+* the minimum delay time is 4 cycles.
+*/
+   clk_ns = DIV_ROUND_UP(10, tfr->speed_hz);
+   wait_clk = DIV_ROUND_UP(wait_ns, clk_ns) - 3;
+   if (wait_clk < 1) {
+   wait_clk = 1;
+   dev_info(&spi->dev,
+"using minimum of 4 word wait cycles (%uns)",
+4 * clk_ns);
+   }
+   }
+   sun4i_spi_write(sspi, SUN4I_WAIT_REG, (u16)wait_clk);
+
/* Setup the transfer now... */
if (sspi->tx_buf)
tx_len = tfr->len;
-- 
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 v5 1/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

[Benoit Parrot]

Mauro Carvalho Chehab  wrote on Thu [2015-Dec-03 
11:19:22 -0200]:
> Em Wed, 18 Nov 2015 14:47:11 -0600
> Benoit Parrot  escreveu:
> 
> > The Camera Adaptation Layer (CAL) is a block which consists of a dual
> > port CSI2/MIPI camera capture engine.
> > Port #0 can handle CSI2 camera connected to up to 4 data lanes.
> > Port #1 can handle CSI2 camera connected to up to 2 data lanes.
> > The driver implements the required API/ioctls to be V4L2 compliant.
> > Driver supports the following:
> > - V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
> > - Asynchronous sensor sub device registration
> 
> Please see the comments I did for the git pull request. Additionally,
> see below.

Yes I'll take care of the comments about the MAINTAINERS mods and patch order.

However I do have a few question on your comments, see below.

> 
> > 
> > Signed-off-by: Benoit Parrot 
> > Signed-off-by: Hans Verkuil 
> > ---
> >  drivers/media/platform/Kconfig   |   12 +
> >  drivers/media/platform/Makefile  |2 +
> >  drivers/media/platform/ti-vpe/Makefile   |4 +
> >  drivers/media/platform/ti-vpe/cal.c  | 2143 
> > ++
> >  drivers/media/platform/ti-vpe/cal_regs.h |  779 +++
> >  5 files changed, 2940 insertions(+)
> >  create mode 100644 drivers/media/platform/ti-vpe/cal.c
> >  create mode 100644 drivers/media/platform/ti-vpe/cal_regs.h
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 0c53805dff0e..db052f5a627a 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -120,6 +120,18 @@ source "drivers/media/platform/s5p-tv/Kconfig"
> >  source "drivers/media/platform/am437x/Kconfig"
> >  source "drivers/media/platform/xilinx/Kconfig"
> >  
> > +config VIDEO_TI_CAL
> > +   tristate "TI CAL (Camera Adaptation Layer) driver"
> > +   depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> > +   depends on SOC_DRA7XX || COMPILE_TEST
> > +   select VIDEOBUF2_DMA_CONTIG
> > +   default n
> > +   ---help---
> > + Support for the TI CAL (Camera Adaptation Layer) block
> > + found on DRA72X SoC.
> > + In TI Technical Reference Manual this module is referred as
> > + Camera Interface Subsystem (CAMSS).
> > +
> >  endif # V4L_PLATFORM_DRIVERS
> >  
> >  menuconfig V4L_MEM2MEM_DRIVERS
> > diff --git a/drivers/media/platform/Makefile 
> > b/drivers/media/platform/Makefile
> > index efa0295af87b..028a7233096b 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -18,6 +18,8 @@ obj-$(CONFIG_VIDEO_VIM2M) += vim2m.o
> >  
> >  obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe/
> >  
> > +obj-$(CONFIG_VIDEO_TI_CAL) += ti-vpe/
> > +
> >  obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
> >  obj-$(CONFIG_VIDEO_CODA)   += coda/
> >  
> > diff --git a/drivers/media/platform/ti-vpe/Makefile 
> > b/drivers/media/platform/ti-vpe/Makefile
> > index be680f839e77..e236059a60ad 100644
> > --- a/drivers/media/platform/ti-vpe/Makefile
> > +++ b/drivers/media/platform/ti-vpe/Makefile
> > @@ -3,3 +3,7 @@ obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
> >  ti-vpe-y := vpe.o sc.o csc.o vpdma.o
> >  
> >  ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
> > +
> > +obj-$(CONFIG_VIDEO_TI_CAL) += ti-cal.o
> > +
> > +ti-cal-y := cal.o
> > diff --git a/drivers/media/platform/ti-vpe/cal.c 
> > b/drivers/media/platform/ti-vpe/cal.c
> > new file mode 100644
> > index ..61cd5b9bd8f6
> > --- /dev/null
> > +++ b/drivers/media/platform/ti-vpe/cal.c
> > @@ -0,0 +1,2143 @@
> > +/*
> > + * TI CAL camera interface driver
> > + *
> > + * Copyright (c) 2015 Texas Instruments Inc.
> > + * Benoit Parrot, 
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License version 2 as 
> > published by
> > + * the Free Software Foundation
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "cal_regs.h"
> > +
> > +#define CAL_MODULE_NAME "cal"
> > +
> > +#define MAX_WIDTH 1920
> > +#define MAX_HEIGHT 1200
> > +
> > +#define CAL_VERSION "0.1.0"
> > +
> > +MODULE_DESCRIPTION("TI CAL driver");
> > +MODULE_AUTHOR("Benoit Parrot, ");
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_VERSION(CAL_VERSION);
> > +
> > +static unsigned video_nr = -1;
> > +module_param(video_nr, uint, 0644);
> > +MODULE_PARM_DESC(video_nr, "videoX start number, -1 is autodetect");
> > +
> > +static unsigned debug;
> > +module_param(debug, uint, 0644);
> > +MODULE_PARM_DESC(debug, "activates debug info");
> > +
> > +/* timeperframe: min/max and

Re: [PATCH 2/2] gpio: Add driver for SPI serializers

[Linus Walleij]

On Fri, Dec 11, 2015 at 8:46 PM, Andrew F. Davis  wrote:

> Add generic parallel-in/serial-out shift register GPIO driver.
>
> This includes SPI compatible devices like SN74165 serial-out shift
> registers and the SN65HVS88x series of industrial serializers that can
> be read over the SPI bus and used for GPI (General Purpose Input).
>
> Signed-off-by: Andrew F. Davis 
(...)
> +#include 
> +#include 

Use #include  instead.

> +#include 
> +#include 
> +#include 
> +
> +#define DEFAULT_NGPIO 8
> +
> +struct pisosr_gpio {
> +   struct gpio_chip chip;
> +   struct spi_device *spi;
> +   u8 *buffer;
> +   size_t buffer_size;
> +   struct gpio_desc *load_gpio;
> +   struct mutex lock;
> +};

Add kerneldoc to this struct.

> +static inline struct pisosr_gpio *to_pisosr_gpio(struct gpio_chip *chip)
> +{
> +   return container_of(chip, struct pisosr_gpio, chip);
> +}

We are doing away with this, but I can fix up the driver by a separate
patch later of we merge it.

> +static int pisosr_gpio_refresh(struct pisosr_gpio *gpio)
> +{
> +   int ret;
> +
> +   mutex_lock(&gpio->lock);
> +
> +   if (gpio->load_gpio) {
> +   gpiod_set_value(gpio->load_gpio, 1);
> +   udelay(1); /* registers load time (~10ns) */
> +   gpiod_set_value(gpio->load_gpio, 0);
> +   udelay(1); /* registers recovery time (~5ns) */


So aren't these load/recovery times dependent on the device?
I think these should come from the compatible string.

> +static int pisosr_gpio_get_direction(struct gpio_chip *chip,
> +unsigned offset)
> +{
> +   return GPIOF_DIR_IN;
> +}

Just return 1, GPIOF_DIR_IN is for the external API.

> +static int pisosr_gpio_get(struct gpio_chip *chip, unsigned offset)
> +{
> +   struct pisosr_gpio *gpio = to_pisosr_gpio(chip);
> +
> +   /* Refresh may not always be needed */
> +   pisosr_gpio_refresh(gpio);
> +
> +   return (gpio->buffer[offset / 8] >> (offset % 8)) & 0x1;
> +}

This looks like a good reason to implement .get_multiple() in the
same way that we have .set_multiple(), so you agree?

But it's not like I'm requiring you to engineer all that. Just an
academic reflection of the fact.

> +static int pisosr_gpio_probe(struct spi_device *spi)
> +{
> +   struct pisosr_gpio *gpio;
> +   struct device_node *np = spi->dev.of_node;
> +   int ret;


To match and get a pointer to a compatible-string-specific data variant,
look at the example in drivers/mfd/tc3589x.c

> +   gpio = devm_kzalloc(&spi->dev, sizeof(*gpio), GFP_KERNEL);
> +   if (!gpio)
> +   return -ENOMEM;
> +
> +   spi_set_drvdata(spi, gpio);
> +
> +   gpio->chip = template_chip;
> +   gpio->chip.parent = &spi->dev;
> +   of_property_read_u16(np, "ngpios", &gpio->chip.ngpio);

As I wrote elsewhere, should come from the variant data, based on the
compatible string. ngpios is in case you're not using all of them and
need to restrict the number of used GPIOs. Usually this only applies to
on-SoC GPIOs that are unrouted.

> +   gpio->spi = spi;
> +
> +   gpio->buffer_size = DIV_ROUND_UP(gpio->chip.ngpio, 8);
> +   gpio->buffer = devm_kzalloc(&spi->dev, gpio->buffer_size, GFP_KERNEL);
> +   if (!gpio->buffer)
> +   return -ENOMEM;
> +
> +   gpio->load_gpio = devm_gpiod_get(&spi->dev, "load", GPIOD_OUT_LOW);
> +   if (IS_ERR(gpio->load_gpio)) {
> +   ret = PTR_ERR(gpio->load_gpio);
> +   if (ret != -ENOENT && ret != -ENOSYS) {
> +   if (ret != -EPROBE_DEFER)
> +   dev_err(&spi->dev, "Unable to allocate reset 
> gpio\n");

Reset gpio? Really? Load GPIO?

Apart from that it looks good.

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 1/2] dt-bindings: GPIO: Add generic serializer binding

[Linus Walleij]

On Fri, Dec 11, 2015 at 8:46 PM, Andrew F. Davis  wrote:

> Add binding for generic parallel-in/serial-out shift register devices
> used as GPIO.
>
> Signed-off-by: Andrew F. Davis 

> +Generic Parallel-in/Serial-out Shift Register GPIO Driver
> +
> +This binding describes generic parallel-in/serial-out shift register
> +devices that can be used for GPI (General Purpose Input). This includes
> +SN74165 serial-out shift registers and the SN65HVS88x series of
> +industrial serializers.
> +
> +Required properties:
> + - compatible  : Should be "pisosr-gpio".

I think it should also define compatible strings on the "vendor,device"
format apart from the generic compatible. Sooner or later we may need
to differentiate them and then that comes in handy.

> + - gpio-controller : Marks the device node as a GPIO controller.
> + - #gpio-cells : Should be two. For consumer use see gpio.txt.
> +
> +Optional properties:
> + - ngpios  : Number of GPIO lines, default is 8.

If you didn't do "pisosr-gpio" but instead "foo,sn74165", maybe you
don't need to have this in the device tree but instead it can be
determined from the compatible string?

In that case do that.

> + - load-gpios  : GPIO pin specifier attached to load enable, this
> + pin is pulsed before reading from the device to
> + load input pin values into the the device.

OK seems necessary.

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 0/2] gpio: Add driver for SPI serializers

[Linus Walleij]

On Fri, Dec 11, 2015 at 8:46 PM, Andrew F. Davis  wrote:

> This series adds a GPI(General Purpose Input) driver for generic
> parallel-in/serial-out shift registers, such as the SN65HVS882
> that this driver was tested on. This should also work for the rest
> of the SN65HVS88x series as well as other 74x165 style devices.

Pretty interesting, I'd like you to CC SPI maintainer Mark Brown
on this patch series, and the SPI mailing list.

Looking closer at the code.

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 v3 0/5] Add reboot notifier driver for rockchip platform

[Heiko Stübner]

Am Mittwoch, 18. November 2015, 17:47:24 schrieb Andy Yan:
> rockchip platform have a protocol to pass the kernel reboot
> mode to bootloader by some special registers when system reboot.
> By this way the bootloader can take different action according
> to the different kernel reboot mode, for example, command
> "reboot loader" will reboot the board to rockusb mode, this is
> a very convenient way to get the board enter download mode.
> And Android system also use this protocol to pass "recovery"、
> “fastboot” reboot mode to bootloader. In upstream land, We found
> tegra platform also use this mechanism.
> 
> Before this version, I have sent two Series, which can be found
> at [0] [1]
> [0] https://patchwork.kernel.org/patch/7140751/
> [1] https://patchwork.kernel.org/patch/7153531/

just so it doesn't get lost, this ties into a slightly more generic approach, 
John Stultz is doing for the android reboot reasons:

http://thread.gmane.org/gmane.linux.kernel/2103447

The only difference is that we'd need to use the pmu syscon for it.



> Changes in v3:
>  - rename a pinctrl node in rk3288-veyron, the original name will be
>used in the incoming reboot notifier driver
>  - add dt binding
>  - move from mach-rockchip to drivers/soc/rockchip, as the tegra does
>  - use dts pass the related register
>  - add DT node
> 
> Changes in v2:
>   - check cpu dt node
>   - remove a unnecessary of_put_node in function rockchip_get_pmu_regmap
>   - fix a align issue
>   - use reboot_notifier instead of restart_handler
> 
> Andy Yan (5):
>   ARM: dts: rockchip: rk3288-veyron: rename pinctrl node reboot to reset
>   dt-bindings: soc: add document for rockchip reboot notifier driver
>   soc: rockchip: add reboot notifier driver
>   ARM: dts: rockchip: add reboot node
>   ARM64: dts: rockchip: add reboot node
> 
>  .../bindings/soc/rockchip/rockchip-reboot.txt  | 18 
>  arch/arm/boot/dts/rk3288-veyron.dtsi   |  2 +-
>  arch/arm/boot/dts/rk3288.dtsi  |  6 ++
>  arch/arm/boot/dts/rk3xxx.dtsi  |  6 ++
>  arch/arm64/boot/dts/rockchip/rk3368.dtsi   |  6 ++
>  drivers/soc/rockchip/Kconfig   |  7 ++
>  drivers/soc/rockchip/Makefile  |  1 +
>  drivers/soc/rockchip/loader.h  | 22 +
>  drivers/soc/rockchip/reboot.c  | 98
> ++ 9 files changed, 165 insertions(+), 1 deletion(-)
>  create mode 100644
> Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt create
> mode 100644 drivers/soc/rockchip/loader.h
>  create mode 100644 drivers/soc/rockchip/reboot.c

--
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/2] power: Add brcm,bcm6358-power-controller device tree binding

[Simon Arlott]

On 11/12/15 02:58, Rob Herring wrote:
> On Wed, Dec 09, 2015 at 10:29:35PM +, Simon Arlott wrote:
>> The BCM6358 contains power domains controlled with a register. Power
>> domains are indexed by bits in the register. Power domain bits can be
>> interleaved with other status bits and clocks in the same register.
>> 
>> Newer SoCs with dedicated power domain registers are active low.
>> 
>> Signed-off-by: Simon Arlott 
>> ---
>>  .../power/brcm,bcm6358-power-controller.txt| 53 
>> ++
>>  1 file changed, 53 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt 
>> b/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt
>> new file mode 100644
>> index 000..556c323
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt
>> @@ -0,0 +1,53 @@
>> +Broadcom BCM6358 Power domain controller
>> +
>> +This binding uses the power domain bindings:
>> +Documentation/devicetree/bindings/power/power_domain.txt
>> +
>> +The BCM6358 contains power domains controlled with a register. Power
>> +domains are indexed by bits in the register. Power domain bits can be
>> +interleaved with other status bits and clocks in the same register.
>> +
>> +Newer SoCs with dedicated power domain registers are active low.
>> +
>> +Required properties:
>> +- compatible:   Should be "brcm,bcm-power-controller", 
>> "brcm,bcm6358-power-controller"
>> +- #power-domain-cells:  Should be <1>.
>> +- regmap:   The register map phandle
>> +- offset:   Offset in the register map for the power domain 
>> register (in bytes)
>> +- power-domain-indices: The bits in the register used for power domains.
> 
> You should drop this and make the cell values be the register offsets.

I need to register every power domain in order to get the kernel to turn
off those that are unused. Even if I could enumerate all device tree
devices that reference the power-controller node, not all of them have
bindings to allow them to be specified in the device tree file.

I can't register all 32 bits because that won't work on the BCM6358 that
only has 1 power domain bit in the register and several clock bits. On
the BCM63268 there are power domain bits that have no device that I
don't want the kernel to disable (like the memory controller).

How should I determine which bits to register a power domain for?

misc_iddq_ctrl: power-controller@1000184c {
compatible = "brcm,bcm6358-power-controller";
regmap = <&misc>;
offset = <0x4c>;

mask = <0x1043fff>;

#power-domain-cells = <1>;
};

or

misc_iddq_ctrl: power-controller@1000184c {
compatible = "brcm,bcm6358-power-controller";
regmap = <&misc>;
offset = <0x4c>;

#address-cells = <1>;
#size-cells = <0>;

sar: power-controller@0 {
reg = <0>;
#power-domain-cells = <0>;
};

ipsec: power-controller@1 {
reg = <1>;
#power-domain-cells = <0>;
};

...
};

or something else?

>> +- power-domain-names:   Should be a list of strings of power domain names
>> +indexed by the power domain indices.
> 
> This isn't really needed anyway.

If I remove this then I'll have to use the same node name for each
struct generic_pm_domain "name" field that I register, although these
names don't appear to be exported anywhere.

>> +
>> +Optional properties:
>> +- active-low:   Specify that the bits are active low.
> 
> This should be implied by the compatible property.

Ok, I'll create "brcm,bcm6358-power-controller" that's active high and
"brcm,bcm6328-power-controller" that's active low. This appear to be
the earliest chips that introduced or changed "iddq" register bits.

-- 
Simon Arlott
--
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 6/6] staging: board: armadillo800eva: Use "arm,pl390"

[Greg Kroah-Hartman]

On Fri, Nov 20, 2015 at 01:36:57PM +0100, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> ---
> Must be applied together with "ARM: shmobile: r8a7740 dtsi: Use
> "arm,pl390" for GIC"!
> 
> Greg: Can you please provide your ack? Thanks!

Acked-by: Greg Kroah-Hartman 
--
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/2] dt-bindings: GPIO: Add generic serializer binding

[Andrew F. Davis]

Add binding for generic parallel-in/serial-out shift register devices
used as GPIO.

Signed-off-by: Andrew F. Davis 
---
 .../devicetree/bindings/gpio/gpio-pisosr.txt   | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pisosr.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt 
b/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt
new file mode 100644
index 000..e69e8ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt
@@ -0,0 +1,34 @@
+Generic Parallel-in/Serial-out Shift Register GPIO Driver
+
+This binding describes generic parallel-in/serial-out shift register
+devices that can be used for GPI (General Purpose Input). This includes
+SN74165 serial-out shift registers and the SN65HVS88x series of
+industrial serializers.
+
+Required properties:
+ - compatible  : Should be "pisosr-gpio".
+ - gpio-controller : Marks the device node as a GPIO controller.
+ - #gpio-cells : Should be two. For consumer use see gpio.txt.
+
+Optional properties:
+ - ngpios  : Number of GPIO lines, default is 8.
+ - load-gpios  : GPIO pin specifier attached to load enable, this
+ pin is pulsed before reading from the device to
+ load input pin values into the the device.
+
+For other required and optional properties of SPI slave
+nodes please refer to ../spi/spi-bus.txt.
+
+Example:
+
+   sn65hvs882@0 {
+   compatible = "pisosr-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   load-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
+
+   reg = <0>;
+   spi-max-frequency = <100>;
+   spi-cpol;
+   };
-- 
2.6.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 2/2] gpio: Add driver for SPI serializers

[Andrew F. Davis]

Add generic parallel-in/serial-out shift register GPIO driver.

This includes SPI compatible devices like SN74165 serial-out shift
registers and the SN65HVS88x series of industrial serializers that can
be read over the SPI bus and used for GPI (General Purpose Input).

Signed-off-by: Andrew F. Davis 
---
 drivers/gpio/Kconfig   |   6 ++
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-pisosr.c | 182 +
 3 files changed, 189 insertions(+)
 create mode 100644 drivers/gpio/gpio-pisosr.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 30d8bd3..95615b1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1021,6 +1021,12 @@ config GPIO_MC33880
  SPI driver for Freescale MC33880 high-side/low-side switch.
  This provides GPIO interface supporting inputs and outputs.
 
+config GPIO_PISOSR
+   tristate "Generic parallel-in/serial-out shift register"
+   help
+ GPIO driver for SPI compatible parallel-in/serial-out shift
+ registers. These are input only devices.
+
 endmenu
 
 menu "SPI or I2C GPIO expanders"
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 548e9b5..ee26102 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_GPIO_OMAP)   += gpio-omap.o
 obj-$(CONFIG_GPIO_PCA953X) += gpio-pca953x.o
 obj-$(CONFIG_GPIO_PCF857X) += gpio-pcf857x.o
 obj-$(CONFIG_GPIO_PCH) += gpio-pch.o
+obj-$(CONFIG_GPIO_PISOSR)  += gpio-pisosr.o
 obj-$(CONFIG_GPIO_PL061)   += gpio-pl061.o
 obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
 obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
diff --git a/drivers/gpio/gpio-pisosr.c b/drivers/gpio/gpio-pisosr.c
new file mode 100644
index 000..e89cd59
--- /dev/null
+++ b/drivers/gpio/gpio-pisosr.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_NGPIO 8
+
+struct pisosr_gpio {
+   struct gpio_chip chip;
+   struct spi_device *spi;
+   u8 *buffer;
+   size_t buffer_size;
+   struct gpio_desc *load_gpio;
+   struct mutex lock;
+};
+
+static inline struct pisosr_gpio *to_pisosr_gpio(struct gpio_chip *chip)
+{
+   return container_of(chip, struct pisosr_gpio, chip);
+}
+
+static int pisosr_gpio_refresh(struct pisosr_gpio *gpio)
+{
+   int ret;
+
+   mutex_lock(&gpio->lock);
+
+   if (gpio->load_gpio) {
+   gpiod_set_value(gpio->load_gpio, 1);
+   udelay(1); /* registers load time (~10ns) */
+   gpiod_set_value(gpio->load_gpio, 0);
+   udelay(1); /* registers recovery time (~5ns) */
+   }
+
+   ret = spi_read(gpio->spi, gpio->buffer, gpio->buffer_size);
+   if (ret)
+   return ret;
+
+   mutex_unlock(&gpio->lock);
+
+   return 0;
+}
+
+static int pisosr_gpio_get_direction(struct gpio_chip *chip,
+unsigned offset)
+{
+   return GPIOF_DIR_IN;
+}
+
+static int pisosr_gpio_direction_input(struct gpio_chip *chip,
+  unsigned offset)
+{
+   /* This device always input */
+   return 0;
+}
+
+static int pisosr_gpio_direction_output(struct gpio_chip *chip,
+   unsigned offset, int value)
+{
+   /* This device is input only */
+   return -EINVAL;
+}
+
+static int pisosr_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+   struct pisosr_gpio *gpio = to_pisosr_gpio(chip);
+
+   /* Refresh may not always be needed */
+   pisosr_gpio_refresh(gpio);
+
+   return (gpio->buffer[offset / 8] >> (offset % 8)) & 0x1;
+}
+
+static struct gpio_chip template_chip = {
+   .label  = "pisosr-gpio",
+   .owner  = THIS_MODULE,
+   .get_direction  = pisosr_gpio_get_direction,
+   .direction_input= pisosr_gpio_direction_input,
+   .direction_output   = pisosr_gpio_direction_output,
+   .get= pisosr_gpio_get,
+   .base   = -1,
+   .ngpio  = DEFAULT_NGPIO,
+   .can_sleep  = true,
+};
+
+static int pisosr_gpio_probe(struct spi_device *spi)
+{
+   struct pisosr_gpio *gpio;
+   struct device_node *np = spi->dev.of_node;
+   int ret;
+
+   gpio = devm_kzalloc(&spi->dev, sizeof(*gpio), GFP_

[PATCH 0/2] gpio: Add driver for SPI serializers

[Andrew F. Davis]

Hello all,

This series adds a GPI(General Purpose Input) driver for generic
parallel-in/serial-out shift registers, such as the SN65HVS882
that this driver was tested on. This should also work for the rest
of the SN65HVS88x series as well as other 74x165 style devices.

Thanks,
Andrew

Andrew F. Davis (2):
  dt-bindings: GPIO: Add generic serializer binding
  gpio: Add driver for SPI serializers

 .../devicetree/bindings/gpio/gpio-pisosr.txt   |  34 
 drivers/gpio/Kconfig   |   6 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-pisosr.c | 182 +
 4 files changed, 223 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pisosr.txt
 create mode 100644 drivers/gpio/gpio-pisosr.c

-- 
2.6.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 1/4] ARM: dts: qcom: apq8064-ifc6410 Use hardware flow control for GSBI6

[Andy Gross]

On Fri, Dec 11, 2015 at 06:29:58PM +, Srinivas Kandagatla wrote:
> From: "Ivan T. Ivanov" 
> 
> GSBI6 UART module is connected to BT chip, which uses
> hardware flow control lines. Enable them on SoC side.
> 
> Signed-off-by: Ivan T. Ivanov 

Looks fine to me. Thanks for the patch.
--
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/4] arm: dts: apq8064: add shared memory into dt reserved-memory

[Andy Gross]

On Fri, Dec 11, 2015 at 06:31:47PM +, Srinivas Kandagatla wrote:
> This patch adds the shared memory in the Device tree reserved memory
> list so that kernel would not map it as normal memory.
> 
> Signed-off-by: Srinivas Kandagatla 

Looks fine to me.
--
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] arm: dts: apq8064: add hwspinlock nodes

[Andy Gross]

On Fri, Dec 11, 2015 at 06:32:11PM +, Srinivas Kandagatla wrote:
> This patch adds support hwspinlock devicetree node.
> 
> Signed-off-by: Srinivas Kandagatla 


Looks fine to me.  Thanks for the patch.
--
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 4/4] arm: dts: apq8064: add shared memory node

[Andy Gross]

On Fri, Dec 11, 2015 at 06:33:09PM +, Srinivas Kandagatla wrote:
> This patch adds support to qcom,smem device.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 829028a..40dd6b4 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -682,5 +682,11 @@
>   #hwlock-cells = <1>;
>   };
>  
> + smem {
> + compatible = "qcom,smem";
> + memory-region = <&smem>;
> + hwlocks = <&sfpb_mutex 3>;
> + };
> +

smem needs to be outside the soc as there is no reg entry.

--
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] devicetree: Add DTS file to support the Nexus7 2013 (flo) device.

[Bjorn Andersson]

On Fri 04 Dec 20:36 PST 2015, John Stultz wrote:

> This patch adds a dts file to support the Nexus7 2013
> device. Its based off of the qcom-apq8064-ifc6410.dts
> which is similar hardware.
> 
> Also includes some comments and context folded in
> from Vinay Simha BN 
> 
> This is my first DTS submission, so thoughts or feedback
> on would be appreciated.

Please remove this from the commit message ;)

[..]

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 30bbc37..c0f9076a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -502,6 +502,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += \
>  dtb-$(CONFIG_ARCH_QCOM) += \
>   qcom-apq8064-cm-qs600.dtb \
>   qcom-apq8064-ifc6410.dtb \
> + qcom-apq8064-nexus7-flo.dtb \

The format for the Sony products are -sony-.dts, I
think we should try to follow this for other devices as well.

>   qcom-apq8074-dragonboard.dtb \
>   qcom-apq8084-ifc6540.dtb \
>   qcom-apq8084-mtp.dtb \
> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts 
> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> new file mode 100644
> index 000..5183d18
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> @@ -0,0 +1,306 @@
> +#include "qcom-apq8064-v2.0.dtsi"
> +#include 
> +#include 
> +#include 
> +/ {
> + model = "Qualcomm APQ8064/Nexus7(flo)";
> + compatible = "qcom,apq8064-nexus7-flo", "qcom,apq8064";

The Nexus7 isn't a Qualcomm product, so you should omit that from the
model and I believe the compatible should be "asus,something-flo",
"qcom,apq8064".

> +
> + aliases {
> + serial0 = &gsbi7_serial;
> + serial1 = &gsbi6_serial;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + soc {
> + rpm@108000 {
> + regulators {
> + vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
> + vin_lvs1_3_6-supply = <&pm8921_s4>;
> + vin_lvs4_5_7-supply = <&pm8921_s4>;
> +
> +
> + vdd_l24-supply = <&pm8921_s1>;
> + vdd_l25-supply = <&pm8921_s1>;
> + vin_lvs2-supply = <&pm8921_s1>;
> +
> + vdd_l26-supply = <&pm8921_s7>;
> + vdd_l27-supply = <&pm8921_s7>;
> + vdd_l28-supply = <&pm8921_s7>;
> +
> + vdd_ncp-supply = <&pm8921_l6>;
> +
> + /* Buck SMPS */
> + pm8921_s1: s1 {

These nodes already have labels, from the dtsi. So please omit the
labels.

> + regulator-always-on;
> + regulator-min-microvolt = <1225000>;
> + regulator-max-microvolt = <1225000>;
> + qcom,switch-mode-frequency = <320>;
> + bias-pull-down;
> + };
> +
[..]
> + };
> +
> + ext_3p3v: regulator-fixed@1 {

This regulator does not sit on the mmio bus should as such be moved
outside of the soc {}.

> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "ext_3p3v";
> + regulator-type = "voltage";
> + startup-delay-us = <0>;
> + gpio = <&tlmm_pinmux 77 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-boot-on;
> + };
> +
> + gsbi3: gsbi@1620 {

Please omit this label.

> + status = "okay";
> + qcom,mode = ;
> + i2c3: i2c@1628 {

Please omit this label.

> + status = "okay";
> + clock-frequency = <20>;
> + pinctrl-0 = <&i2c3_pins>;
> + pinctrl-names = "default";
> +
> + trackpad: trackpad@10 {

Please omit this label.

> + compatible = "elan,ekth3500";
> + reg = <0x10>;
> + interrupt-parent = <&tlmm_pinmux>;
> + interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
> + };
> + };
> + };
[..]
> +
> + /* OTG */
> + usb1_phy: phy@1250 {

Please omit this label.

> + status  = "okay";
> + vddcx-supply= <&pm8921_s3>;
> + v3p3-supply = <&pm8921_l3>;
> + v1p8-supply = <&pm8921_l4>;
> 

[PATCH v2 4/4] ARM: dts: sun4i: Enable onboard codec used on the pov protab2-ips9 tablet

[Hans de Goede]

The pov protab2-ips9 tablet uses the A10's integrated audio codec,
enable it.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Adjust for gpio rename from pa-gpios to allwinner,pa-gpios
---
 arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts 
b/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
index a88d5f4..ea90634 100644
--- a/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
@@ -72,6 +72,13 @@
};
 };
 
+&codec {
+   pinctrl-names = "default";
+   pinctrl-0 = <&codec_pa_pin>;
+   allwinner,pa-gpios = <&pio 7 15 GPIO_ACTIVE_HIGH>; /* PH15 */
+   status = "okay";
+};
+
 &cpu0 {
cpu-supply = <®_dcdc2>;
 };
@@ -170,6 +177,13 @@
allwinner,pull = ;
};
 
+   codec_pa_pin: codec_pa_pin@0 {
+   allwinner,pins = "PH15";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
touchscreen_pins: touchscreen_pins@0 {
allwinner,pins = "PA5", "PB13";
allwinner,function = "gpio_out";
-- 
2.5.0

--
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 1/4] ASoC: sun4i-codec: Rename codec dapm widgets and routes

[Hans de Goede]

Rename the codec dapm widgets and routes with a _codec prefix. This is
a preparation patch for adding card dapm widgets and routes.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-New patch in v2 of this patchset
---
 sound/soc/sunxi/sun4i-codec.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 7a3fe1d..519ccb3 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -532,7 +532,7 @@ static const struct snd_kcontrol_new 
sun4i_codec_pa_mixer_controls[] = {
SUN4I_CODEC_DAC_ACTL_MIXPAS, 1, 0),
 };
 
-static const struct snd_soc_dapm_widget sun4i_codec_dapm_widgets[] = {
+static const struct snd_soc_dapm_widget sun4i_codec_codec_dapm_widgets[] = {
/* Digital parts of the ADCs */
SND_SOC_DAPM_SUPPLY("ADC", SUN4I_CODEC_ADC_FIFOC,
SUN4I_CODEC_ADC_FIFOC_EN_AD, 0,
@@ -589,7 +589,7 @@ static const struct snd_soc_dapm_widget 
sun4i_codec_dapm_widgets[] = {
SND_SOC_DAPM_OUTPUT("HP Left"),
 };
 
-static const struct snd_soc_dapm_route sun4i_codec_dapm_routes[] = {
+static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
/* Left ADC / DAC Routes */
{ "Left ADC", NULL, "ADC" },
{ "Left DAC", NULL, "DAC" },
@@ -628,10 +628,10 @@ static const struct snd_soc_dapm_route 
sun4i_codec_dapm_routes[] = {
 static struct snd_soc_codec_driver sun4i_codec_codec = {
.controls   = sun4i_codec_widgets,
.num_controls   = ARRAY_SIZE(sun4i_codec_widgets),
-   .dapm_widgets   = sun4i_codec_dapm_widgets,
-   .num_dapm_widgets   = ARRAY_SIZE(sun4i_codec_dapm_widgets),
-   .dapm_routes= sun4i_codec_dapm_routes,
-   .num_dapm_routes= ARRAY_SIZE(sun4i_codec_dapm_routes),
+   .dapm_widgets   = sun4i_codec_codec_dapm_widgets,
+   .num_dapm_widgets   = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
+   .dapm_routes= sun4i_codec_codec_dapm_routes,
+   .num_dapm_routes= ARRAY_SIZE(sun4i_codec_codec_dapm_routes),
 };
 
 static const struct snd_soc_component_driver sun4i_codec_component = {
-- 
2.5.0

--
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/4] ARM: dts: sun5i: Enable onboard codec used on the UTOO P66 tablet

[Hans de Goede]

The UTOO P66 tablet uses the A13's integrated audio codec, enable it.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Adjust for gpio rename from pa-gpios to allwinner,pa-gpios
---
 arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts 
b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
index 5236c1e..fa9ddfd 100644
--- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -73,6 +73,13 @@
};
 };
 
+&codec {
+   pinctrl-names = "default";
+   pinctrl-0 = <&codec_pa_pin>;
+   allwinner,pa-gpios = <&pio 6 3 GPIO_ACTIVE_HIGH>; /* PG3 */
+   status = "okay";
+};
+
 &cpu0 {
cpu-supply = <®_dcdc2>;
 };
@@ -168,6 +175,13 @@
 };
 
 &pio {
+   codec_pa_pin: codec_pa_pin@0 {
+   allwinner,pins = "PG3";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
mmc0_cd_pin_p66: mmc0_cd_pin@0 {
allwinner,pins = "PG0";
allwinner,function = "gpio_in";
-- 
2.5.0

--
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 2/4] ASoC: sun4i-codec: Add support for PA gpio pin

[Hans de Goede]

Add support for PA gpio pin for controlling an external amplifier as used
on some Allwinner boards.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use a dapm speaker widget (SND_SOC_DAPM_SPK) to control the gpio
-Rename gpio in devicetree from pa-gpios to allwinner,pa-gpios
---
 .../devicetree/bindings/sound/sun4i-codec.txt  |  3 ++
 sound/soc/sunxi/sun4i-codec.c  | 35 ++
 2 files changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt 
b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index c92966b..0dce690 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -14,6 +14,9 @@ Required properties:
- "apb": the parent APB clock for this controller
- "codec": the parent module clock
 
+Optional properties:
+- allwinner,pa-gpios: gpio to enable external amplifier
+
 Example:
 codec: codec@01c22c00 {
#sound-dai-cells = <0>;
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 519ccb3..e6cc6a1 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -103,6 +104,7 @@ struct sun4i_codec {
struct regmap   *regmap;
struct clk  *clk_apb;
struct clk  *clk_module;
+   struct gpio_desc *gpio_pa;
 
struct snd_dmaengine_dai_dma_data   capture_dma_data;
struct snd_dmaengine_dai_dma_data   playback_dma_data;
@@ -709,6 +711,26 @@ static struct snd_soc_dai_link 
*sun4i_codec_create_link(struct device *dev,
return link;
 };
 
+static int sun4i_codec_spk_event(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol *k, int event)
+{
+   struct sun4i_codec *scodec = snd_soc_card_get_drvdata(w->dapm->card);
+
+   if (scodec->gpio_pa)
+   gpiod_set_value_cansleep(scodec->gpio_pa,
+!!SND_SOC_DAPM_EVENT_ON(event));
+
+   return 0;
+}
+
+static const struct snd_soc_dapm_widget sun4i_codec_card_dapm_widgets[] = {
+   SND_SOC_DAPM_SPK("Speaker", sun4i_codec_spk_event),
+};
+
+static const struct snd_soc_dapm_route sun4i_codec_card_dapm_routes[] = {
+   { "Speaker", NULL, "Power Amplifier" },
+};
+
 static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
 {
struct snd_soc_card *card;
@@ -723,6 +745,10 @@ static struct snd_soc_card *sun4i_codec_create_card(struct 
device *dev)
 
card->dev   = dev;
card->name  = "sun4i-codec";
+   card->dapm_widgets  = sun4i_codec_card_dapm_widgets;
+   card->num_dapm_widgets  = ARRAY_SIZE(sun4i_codec_card_dapm_widgets);
+   card->dapm_routes   = sun4i_codec_card_dapm_routes;
+   card->num_dapm_routes   = ARRAY_SIZE(sun4i_codec_card_dapm_routes);
 
return card;
 };
@@ -774,6 +800,15 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+   scodec->gpio_pa = devm_gpiod_get_optional(&pdev->dev, "allwinner,pa",
+ GPIOD_OUT_LOW);
+   if (IS_ERR(scodec->gpio_pa)) {
+   ret = PTR_ERR(scodec->gpio_pa);
+   if (ret != -EPROBE_DEFER)
+   dev_err(&pdev->dev, "Failed to get pa gpio: %d\n", ret);
+   return ret;
+   }
+
/* DMA configuration for TX FIFO */
scodec->playback_dma_data.addr = res->start + SUN4I_CODEC_DAC_TXDATA;
scodec->playback_dma_data.maxburst = 4;
-- 
2.5.0

--
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 v14 1/7] fpga: add usage documentation for fpga area

[atull]

On Fri, 11 Dec 2015, Rob Herring wrote:

Hi Rob,

> > +Device Tree Example: Partial Reconfiguration with no Bridges
> > +
> > +
> > +Live Device Tree contains:
> > +   fpgamgr@0 {
> 
> Unit address should be ffd03000 here.

I'll clean up the addresses (and add that to my checklist!).

> 
> > +   compatible = "altr,socfpga-a10-fpga-mgr", "simple-bus";
> 
> This should not have simple-bus. This would be broken in the case of 
> applying the overlay before booting the kernel. You don't want the 
> devices probed before the fpgamgr has programmed them.
> 

I debugged this and had to add the simple-bus's to see my child devices
probe.  Otherwise I can apply the overlay, but when I call
of_platform_populate, no child nodes get populated.
In drivers/of/platform.c's of_platform_notify(), the OF_POPULATED_BUS
flag has to be set for the parent (implying it was set for its parents
or it wouldn't be set).  The child nodes do not get populated unless
the insertion point and all the ancestors of the insertion point are
simple-bus's.  

So the issue of applying the overlay before booting the kernel:
if FPGA Area gets probed before its children get populated, then
I'm K since FPGA Area is responsible for programming the FPGA.

I can rework this to have a virtualized fpgabus that has the fpgamgr
and bridges as its children if that is more correct.  I actually
worked this up several different ways so I have the code.  I still
would like to keep the FPGA Area because that gives me a module that
gets probed that can be in charge of programming the FPGA.  If I were
to rid of FPGA Area and just have an overlay of "firmware-name" plus
child nodes, then I have to add a notifier to the fpgabus.  This I
can do (and have done and seen it work) so if that is preferable,
that's what v15 of this can easily be.

In that case, the target path for the overlay could be the fpgabus.
The fpgabus would need to also be a simple-bus but not the manager
or bridges.

So if I have a fpgabus, the live tree would be:
fpgabus@0 {
compatible = "altr,fpga-bus", "simple-bus";
#address-cells = <0x1>;
#size-cells = <0x1>;
ranges;

fpgamgr@ff706000 {
compatible = "altr,socfpga-fpga-mgr";
reg = <0xff706000 0x1000
   0xffb9 0x1000>;
interrupts = <0 175 4>;
};

bridge@0 {
compatible = "altr,socfpga-lwhps2fpga-bridge";
resets = <&rst LWHPS2FPGA_RESET>;
reset-names = "lwhps2fpga";
clocks = <&l4_main_clk>;
#address-cells = <0x1>;
#size-cells = <0x1>;
ranges;
};

bridge@1 {
compatible = "altr,socfpga-hps2fpga-bridge";
resets = <&rst HPS2FPGA_RESET>;
reset-names = "hps2fpga";
clocks = <&l4_main_clk>;
};
};

Alan
--
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] extcon-usb-gpio: add enable pin support

[Sergei Shtylyov]

Hello.

On 12/11/2015 06:53 AM, Rob Herring wrote:


Sometimes  there's a real  OTG chip behind the USB ID signal mapped to a GPIO
pin: in my case it's Maxim Integrated MAX3355E which  integrates Vbus charge
pump and comparators and passes  thru the ID  signal  from an OTG connector.
This chip also has the SHDN# pin which  should be  driven high for the normal
operation  and low to  save power;  it  is connected to a GPIO pin as well on,
hence  we'll have  to  teach the driver to parse the new optional device tree
property, "enable-gpio"...


Some wierd spacing going on here.


   I like my text properly filling up the given columns. What's the problem? :-)


Signed-off-by: Sergei Shtylyov 

---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.

  Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt |3 +++
  drivers/extcon/extcon-usb-gpio.c |5 +
  2 files changed, 8 insertions(+)

Index: extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
===
--- extcon.orig/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -7,6 +7,9 @@ Required properties:
  - compatible: Should be "linux,extcon-usb-gpio"
  - id-gpio: gpio for USB ID pin. See gpio binding.

+Optional properties:
+- enable-gpio: gpio for the enable pin. See gpio binding.


Use -gpios as -gpio is deprecated.


   Didn't know, thanks.

[...]

Index: extcon/drivers/extcon/extcon-usb-gpio.c
===
--- extcon.orig/drivers/extcon/extcon-usb-gpio.c
+++ extcon/drivers/extcon/extcon-usb-gpio.c

[...]

@@ -99,6 +100,8 @@ static int usb_extcon_probe(struct platf
return -ENOMEM;

info->dev = dev;
+   info->enable_gpiod = devm_gpiod_get_optional(&pdev->dev, "enable",
+GPIOD_OUT_HIGH);
info->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
if (IS_ERR(info->id_gpiod)) {
dev_err(dev, "failed to get ID GPIO\n");
@@ -155,6 +158,8 @@ static int usb_extcon_remove(struct plat

cancel_delayed_work_sync(&info->wq_detcable);

+   gpiod_set_value_cansleep(info->enable_gpiod, 0);



Shouldn't you support either polarity?


   The gpiolib does that for me -- devm_gpiod_get_optional() should read the 
polarity from DT.



Rob


MBR, Sergei

--
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 4/4] arm: dts: apq8064: add shared memory node

[Srinivas Kandagatla]

This patch adds support to qcom,smem device.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 829028a..40dd6b4 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -682,5 +682,11 @@
#hwlock-cells = <1>;
};
 
+   smem {
+   compatible = "qcom,smem";
+   memory-region = <&smem>;
+   hwlocks = <&sfpb_mutex 3>;
+   };
+
};
 };
-- 
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 1/2] ARM: mvebu: add kirkwood compatibles for cloudengine boards

[Linus Walleij]

On Wed, Dec 9, 2015 at 4:27 PM, Gregory CLEMENT
 wrote:
> Hi Linus,
>
>  On mer., déc. 09 2015, Linus Walleij  wrote:
>
>> On Fri, Nov 27, 2015 at 12:00 AM, Linus Walleij
>>  wrote:
>>
>>> This adds the compatible strings for Cloudengine PogoPlug E02 and
>>> series 4. The former already has a devicetree in the kernel.
>>>
>>> Cc: devicetree@vger.kernel.org
>>> Signed-off-by: Linus Walleij 
>>
>> Kirkwood maintainers: are you queueing this patch with Rob's
>> ACK?
>
> Actually I was waiting for a new version of the series with Adrew's
> comment addressed in the 2nd patch before applying the whole series.

OK I sent a new one of that earlier today, but I did not resend this one.
I think it stand on its own though? The compatible string for the machine
was never target of review comments.

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

[PATCH 3/4] arm: dts: apq8064: add hwspinlock nodes

[Srinivas Kandagatla]

This patch adds support hwspinlock devicetree node.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 09f0e27..829028a 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -670,5 +670,17 @@
compatible = "qcom,tcsr-apq8064", "syscon";
reg = <0x1a40 0x100>;
};
+
+   sfpb_syscon:syscon@01200600 {
+   compatible = "syscon";
+   reg = <0x01200600 0x100>;
+   };
+
+   sfpb_mutex: hwlock {
+   compatible = "qcom,sfpb-mutex";
+   syscon = <&sfpb_syscon 0x4 0x4>;
+   #hwlock-cells = <1>;
+   };
+
};
 };
-- 
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 2/4] arm: dts: apq8064: add shared memory into dt reserved-memory

[Srinivas Kandagatla]

This patch adds the shared memory in the Device tree reserved memory
list so that kernel would not map it as normal memory.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index a4c1762..09f0e27 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -11,6 +11,17 @@
compatible = "qcom,apq8064";
interrupt-parent = <&intc>;
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   smem:smem@8000 {
+   reg = <0x8000 0x20>;
+   no-map;
+   };
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
-- 
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 1/4] ARM: dts: qcom: apq8064-ifc6410 Use hardware flow control for GSBI6

[Srinivas Kandagatla]

From: "Ivan T. Ivanov" 

GSBI6 UART module is connected to BT chip, which uses
hardware flow control lines. Enable them on SoC side.

Signed-off-by: Ivan T. Ivanov 
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 11ac608..80c6695 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -164,7 +164,7 @@
 
gsbi@1650 {
status = "ok";
-   qcom,mode = ;
+   qcom,mode = ;
 
serial@1654 {
status = "ok";
-- 
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 0/4] arm: dts: qcom-apq8064: add smem and hwspinlock support

[Srinivas Kandagatla]

Hi Andy, 

Here are 3 patches for smem/hwspinlock which I have tested with QDSP on IFC6410.
Also a fix from Ivan which I think can be taken aswell.

Thanks,
srini

Ivan T. Ivanov (1):
  ARM: dts: qcom: apq8064-ifc6410 Use hardware flow control for GSBI6

Srinivas Kandagatla (3):
  arm: dts: apq8064: add shared memory into dt reserved-memory
  arm: dts: apq8064: add hwspinlock nodes
  arm: dts: apq8064: add shared memory node

 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |  2 +-
 arch/arm/boot/dts/qcom-apq8064.dtsi| 29 +
 2 files changed, 30 insertions(+), 1 deletion(-)

-- 
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 v2 2/3] ehci-platform: Add support for controllers with multiple reset lines

[Hans de Goede]

Hi,

On 11-12-15 18:13, Philipp Zabel wrote:

Am Freitag, den 11.12.2015, 16:41 +0100 schrieb Hans de Goede:

From: Reinder de Haan 

At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.

Signed-off-by: Reinder de Haan 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use the new reset_control_[de]assert_shared reset-controller functions
---
  Documentation/devicetree/bindings/usb/usb-ehci.txt |  2 +-
  drivers/usb/host/ehci-platform.c   | 47 +-
  2 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index a12d601..0701812 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -18,7 +18,7 @@ Optional properties:
   - clocks : a list of phandle + clock specifier pairs
   - phys : phandle + phy specifier pair
   - phy-names : "usb"
- - resets : phandle + reset specifier pair
+ - resets : a list of phandle + reset specifier pairs


Are there documented names for these resets?


This binding is a generic ehci controller binding, so even if
the names are documented for the allwinner SoC we should
not use names, just like the binding is deliberately not
using names for the clocks either to keep it generic, so
that we can reuse the binding + driver with many different SoCs.


Is the companion you
mention the Port Control?


Sort of, with USB-2, USB-1 compatibility is handled via a mux on the
datalines (controlled by the EHCI controller Port Control) which muxes
the lines to an USB-1 controller (typically either UHCI or OHCI) when the
device does not connect after USB-2 highspeed handshaking.

This USB-1 controller (or controller_S_ in some case since the
USB-1 companions may have less root-ports per controller then the EHCI
has root-ports) is called the companion controller.

The 2 controllers are supposed to be 100% independent but on the H3
Allwinner has done something (not documented) which requires one to
deassert reset on both before you can talk to either one.

Regards,

Hans
--
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 1/3] reset: Add shared reset_control_[de]assert variants

[Hans de Goede]

Hi,

On 11-12-15 18:10, Philipp Zabel wrote:

Hi Hans,

thanks for moving this forward.


Thanks for the quick review, I've a couple of (simple) questions
about your review remarks once those are cleared up I'll post a new version
(of just this patch).


Am Freitag, den 11.12.2015, 16:41 +0100 schrieb Hans de Goede:

Add reset_control_deassert_shared / reset_control_assert_shared
functions which are intended for use by drivers for hw blocks which
(may) share a reset line with another driver / hw block.

Unlike the regular reset_control_[de]assert functions these functions
keep track of how often deassert_shared / assert_shared have been called
and keep the line deasserted as long as deassert has been called more
times than assert.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-This is a new patch in v2 of this patch-set
---
  drivers/reset/core.c | 121 ---
  include/linux/reset-controller.h |   2 +
  include/linux/reset.h|   2 +
  3 files changed, 116 insertions(+), 9 deletions(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 9ab9290..8c3436c 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -22,16 +22,29 @@ static DEFINE_MUTEX(reset_controller_list_mutex);
  static LIST_HEAD(reset_controller_list);

  /**
+ * struct reset_line - a reset line
+ * @list: list entry for the reset controllers reset line list
+ * @id:   ID of the reset line in the reset controller device
+ * @refcnt:   Number of reset_control structs referencing this device
+ * @deassert_cnt: Number of times this reset line has been deasserted
+ */
+struct reset_line {
+   struct list_head list;
+   unsigned int id;
+   unsigned int refcnt;
+   unsigned int deassert_cnt;
+};


I'd move rcdev into reset_line, too. That way the description is
complete, and we don't duplicate rcdev when there are multiple
reset_controls pointing here.


Ack.


+/**
   * struct reset_control - a reset control
   * @rcdev: a pointer to the reset controller device
   * this reset control belongs to
- * @id: ID of the reset controller in the reset
- *  controller device
+ * @line:  reset line for this reset control
   */
  struct reset_control {
struct reset_controller_dev *rcdev;
+   struct reset_line *line;
struct device *dev;
-   unsigned int id;
  };

  /**

[...]

@@ -119,13 +134,55 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
  int reset_control_deassert(struct reset_control *rstc)
  {


Maybe WARN_ON(rstc->line->refcnt > 1) ?


I assume you mean deasser_cnt ? Seems reasonable with that change.


if (rstc->rcdev->ops->deassert)
-   return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->id);
+   return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->line->id);

return -ENOTSUPP;
  }
  EXPORT_SYMBOL_GPL(reset_control_deassert);

  /**
+ * reset_control_assert_shared - asserts a shared reset line
+ * @rstc: reset controller
+ *
+ * Assert a shared reset line, this functions decreases the deassert count
+ * of the line by one and asserts it if, and only if, the deassert count
+ * reaches 0.


"After calling this function the shared reset line may be asserted, or
  it may still be deasserted, as long as other users keep it so."


I take it this is to replace the text about "deassert count" ?


+ */
+int reset_control_assert_shared(struct reset_control *rstc)
+{
+   if (!rstc->rcdev->ops->assert)
+   return -ENOTSUPP;


WARN_ON(rstc->line->deassert_cnt == 0)

Actually, what to do in this case? Assume ops->assert was called, or do
it again to be sure? Certainly we don't want to wrap deassert_cnt, or
the next deassert_shared will do nothing.


+   rstc->line->deassert_cnt--;
+   if (rstc->line->deassert_cnt)


deassert_cnt isn't protected by any lock.


Right, good catch. I believe the best way to fix this is to change deassert_cnt
into an atomic_t and use atomic_dec_return / atomic_int_return,

Downside of using an atomic_t is that doing the WARN_ON you are asking for above
will not be race free, then, but since it is a should never happen scenario I
guess we do not care about the check not being 100% race free. Or we can even
just leave out the check ?





+   return 0;
+
+   return rstc->rcdev->ops->assert(rstc->rcdev, rstc->line->id);
+}
+EXPORT_SYMBOL_GPL(reset_control_assert_shared);
+
+/**
+ * reset_control_deassert_shared - deasserts a shared reset line
+ * @rstc: reset controller
+ *
+ * Assert a shared reset line, this functions increases the deassert count


Deassert


Ack.


+ * of the line by one and deasserts the reset line (if it was not already
+ * deasserted).


"After calling this function, the shared reset line is guaranteed to be
  deasserted."


Same question as above.


+ */
+int reset_control_deassert_shared(struct reset_control *rstc)
+{
+   if (!rstc->rcdev->ops->deassert)
+   return -ENO

[PATCH 1/2] arm64: dts: fix the i2c aliasing to match to schematics.

[Srinivas Kandagatla]

This patch fixes the i2c bus number aliasing so that it matches with the
schematics bus naming.

Without this patch the user might would get bus numbers depending on
the order the devices are probed.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 6b8abbe..6f19956 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -20,6 +20,9 @@
aliases {
serial0 = &blsp1_uart2;
serial1 = &blsp1_uart1;
+   i2c0= &blsp_i2c2;
+   i2c1= &blsp_i2c6;
+   i2c3= &blsp_i2c4;
};
 
chosen {
-- 
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 2/2] arm64: dts: set the default i2c pin drive strength to 16mA

[Srinivas Kandagatla]

2mA drive strength is not enough when we connect multiple i2c devices
on the bus with different pull up resistors.

This issue was detected when multiple i2c devices connected on the other side
of level shifters on Linaro sensor board. Maxing up to 16mA made i2c much 
stable.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 49ec55a..1991af7 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -272,7 +272,7 @@
};
pinconf {
pins = "gpio6", "gpio7";
-   drive-strength = <2>;
+   drive-strength = <16>;
bias-disable = <0>;
};
};
@@ -296,7 +296,7 @@
};
pinconf {
pins = "gpio14", "gpio15";
-   drive-strength = <2>;
+   drive-strength = <16>;
bias-disable = <0>;
};
};
@@ -320,7 +320,7 @@
};
pinconf {
pins = "gpio22", "gpio23";
-   drive-strength = <2>;
+   drive-strength = <16>;
bias-disable = <0>;
};
};
-- 
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 0/2] arm64: dts: qcom: few i2c fixes

[Srinivas Kandagatla]

Hi Andy, 

Here are two i2c dt fixes which I have been using for long time on Landing team 
tree.

Can you please consider fixes for v4.5.

Thanks,
srini

Srinivas Kandagatla (2):
  arm64: dts: fix the i2c aliasing to match to schematics.
  arm64: dts: set the default i2c pin drive strength to 16mA

 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 3 +++
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 6 +++---
 2 files changed, 6 insertions(+), 3 deletions(-)

-- 
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 v2 3/5] ARM: bcm2835: add rpi power domain driver

[Stefan Wahren]

Hi Eric,

Am 04.12.2015 um 18:45 schrieb Eric Anholt:

From: Alexander Aring 

This patch adds support for several power domains on Raspberry Pi,
including USB (so it can be enabled even if the bootloader didn't do
it), and graphics.

This patch is the combined work of Eric Anholt (who wrote USB support
inside of the Raspberry Pi firmware driver, and wrote the non-USB
domain support) and Alexander Aring (who separated the original USB
work out from the firmware driver).

Signed-off-by: Alexander Aring 
Signed-off-by: Eric Anholt 
---

v2: Add support for power domains other than USB, using the new
 firmware interface, reword commit message (changes by Eric)

  arch/arm/mach-bcm/Kconfig   |  10 ++
  arch/arm/mach-bcm/Makefile  |   1 +
  arch/arm/mach-bcm/raspberrypi-power.c   | 269 
  include/dt-bindings/arm/raspberrypi-power.h |  41 +
  4 files changed, 321 insertions(+)
  create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
  create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8c53c55..0f23bad 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -134,6 +134,16 @@ config ARCH_BCM2835
  This enables support for the Broadcom BCM2835 SoC. This SoC is
  used in the Raspberry Pi and Roku 2 devices.

+config RASPBERRYPI_POWER
+   bool "Raspberry Pi power domain driver"
+   depends on ARCH_BCM2835 || COMPILE_TEST
+   depends on RASPBERRYPI_FIRMWARE
+   select PM_GENERIC_DOMAINS if PM
+   select PM_GENERIC_DOMAINS_OF if PM
+   help
+ This enables support for the RPi power domains which can be enabled
+ or disabled via the RPi firmware.
+
  config ARCH_BCM_63XX
bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
depends on MMU
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..fec2d6b 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -36,6 +36,7 @@ endif

  # BCM2835
  obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o

  # BCM5301X
  obj-$(CONFIG_ARCH_BCM_5301X)  += bcm_5301x.o
diff --git a/arch/arm/mach-bcm/raspberrypi-power.c 
b/arch/arm/mach-bcm/raspberrypi-power.c
new file mode 100644
index 000..3444301
--- /dev/null
+++ b/arch/arm/mach-bcm/raspberrypi-power.c
@@ -0,0 +1,269 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Authors:
+ * (C) 2015 Pengutronix, Alexander Aring 
+ * Eric Anholt 


shouldn't be the copyright before license?


+ */
+ [...]
+
+static int rpi_power_probe(struct platform_device *pdev)
+{
+   struct device_node *fw_np;
+   struct device *dev = &pdev->dev;
+   struct rpi_power_domains *rpi_domains;
+   int ret, i;
+
+   rpi_domains = devm_kzalloc(dev, sizeof(*rpi_domains), GFP_KERNEL);
+   if (!rpi_domains)
+   return -ENOMEM;
+
+   rpi_domains->xlate.domains =
+   devm_kzalloc(dev, sizeof(*rpi_domains->xlate.domains) *
+RPI_POWER_DOMAIN_COUNT, GFP_KERNEL);
+   if (!rpi_domains->xlate.domains)
+   return -ENOMEM;
+
+   rpi_domains->xlate.num_domains = RPI_POWER_DOMAIN_COUNT;
+
+   fw_np = of_parse_phandle(pdev->dev.of_node, "firmware", 0);
+   if (!fw_np) {
+   dev_err(&pdev->dev, "no firmware node\n");
+   return -ENODEV;
+   }
+
+   rpi_domains->fw = rpi_firmware_get(fw_np);
+   of_node_put(fw_np);
+   if (!rpi_domains->fw)
+   return -EPROBE_DEFER;
+
+   rpi_domains->has_new_interface =
+   rpi_has_new_domain_support(rpi_domains);
+
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C0, "I2C0");
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C1, "I2C1");
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_I2C2, "I2C2");
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VIDEO_SCALER,
+ "VIDEO_SCALER");
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VPU1, "VPU1");
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_HDMI, "HDMI");
+
+   /*
+* Use the old firmware interface for USB power, so that we
+* can turn it on even if the firmware hasn't been updated.
+*/
+   rpi_init_old_power_domain(rpi_domains, RPI_POWER_DOMAIN_USB,
+ RPI_OLD_POWER_DOMAIN_USB, "USB");
+
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_VEC, "VEC");
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_JPEG, "JPEG");
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_H264, "H264");
+   rpi_init_power_domain(rpi_domains, RPI_POWER_DOMAIN_

Re: [PATCH v2 1/4] pinctrl: rockchip: add support for the rk3228

[Linus Walleij]

On Fri, Dec 11, 2015 at 2:30 AM, Jeffy Chen  wrote:

> The pinctrl of rk3228 is much the same as rk3288's, but
> without pmu.
>
> Signed-off-by: Jeffy Chen 
> Reviewed-by: Heiko Stuebner 
> Acked-by: Rob Herring 
>
> ---
>
> Changes in v2: None

Same as I applied then, I also added the same Review/ACKs.

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 v1 1/8] pinctrl: rockchip: add support for the rk3228

[Linus Walleij]

On Wed, Dec 9, 2015 at 10:04 AM, Jeffy Chen  wrote:

> The pinctrl of rk3228 is much the same as rk3288's, but
> without pmu.
>
> Signed-off-by: Jeffy Chen 

Patch applied with Heiko's and Rob's Review/ACKs.

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: [RFC PATCH 8/8] arm64: add sysfs cpu_capacity attribute

[Mark Brown]

On Thu, Dec 10, 2015 at 06:01:59PM +, Juri Lelli wrote:
> On 10/12/15 15:59, Mark Brown wrote:
> > On Thu, Dec 10, 2015 at 02:15:04PM +, Dietmar Eggemann wrote:
> > > On 23/11/15 14:28, Juri Lelli wrote:

> > > > The new attribute shows up as:

> > > >  /sys/devices/system/cpu/cpu*/cpu_capacity

> > > This sysfs interface is not really needed for arm or arm64. People can
> > > build the dt blob if they want to change the values. Less code to carry
> > > ... Let's focus on the core functionality, which is parsing cpu capacity
> > > from dt file to task scheduler for heterogeneous systems.

> > That does make the tuning process much more cumbersome - users have to
> > rebuild and reboot to tweak the numbers rather than just tweaking the
> > numbers and rerunning the benchmark (which seems like something people
> > would want to automate).

> IMHO, this is not a tuning interface. It is an alternative interface,
> w.r.t. DTs, that we could use to provide default capacity values to the
> kernel. I'm proposing both here as they make both sense to me. Then we
> might dedice for which one to go (or if we need some other way) or to
> keep both for flexibility.

Kind of repeating what I said in the other mail but I'd say that any
interface which provides a mechanism for setting a magic number that
influences system performance is providing tuning.  It's hard to see how
else to describe it to be honest.


signature.asc
Description: PGP signature

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

[Mark Brown]

On Thu, Dec 10, 2015 at 05:58:20PM +, Juri Lelli wrote:
> On 10/12/15 15:30, Mark Brown wrote:
> > On Mon, Nov 23, 2015 at 08:06:31PM -0600, Rob Herring wrote:

> > > In other words, I want to see these numbers have a defined method 
> > > of determining them and don't want to see random values from every 
> > > vendor. ARM, Ltd. says core X has a value of Y would be good enough for 
> > > me. Vendor X's A57 having a value of 2 and Vendor Y's A57 having a 
> > > value of 1024 is not what I want to see. Of course things like cache 
> > > sizes can vary the performance, but is a baseline value good enough? 

> > > However, no vendor will want to publish their values if these are 
> > > absolute values relative to other vendors.

> > > If you expect these to need frequent tuning, then don't put them in DT.

> > I agree strongly.  Putting what are essentially tuning numbers for the
> > system into the ABI is going to lead us into a mess long term since if
> > we change anything related to the performance of the system the numbers
> > may become invalid and we've no real way of recovering sensible
> > information.

> I'm not entirely getting here why you consider capacity values to be
> tunables. As part of the EAS effort, we are proposing ways in which users

The purpose of the capacity values is to influence the scheduler
behaviour and hence performance.  Without a concrete definition they're
just magic numbers which have meaining only in terms of their effect on
the performance of the system.  That is a sufficiently complex outcome
to ensure that there will be an element of taste in what the desired
outcomes are.  Sounds like tuneables to me.

> should be able to fine tune their system as needed, when required
> (don't know if you had a chance to have a look at the SchedTune posting
> back in August for example [1]). This patch tries to only standardize
> where do we get default values from and how we specify them. I'm not
> seeing them changing much after an initial benchmarking phase has been
> done. Tuning should happen using different methods, not by changing
> these values, IMHO.

If you are saying people should use other, more sensible, ways of
specifying the final values that actually get used in production then
why take the defaults from direct numbers DT in the first place?  If you
are saying that people should tune and then put the values in here then
that's problematic for the reasons I outlined.

> > It would be better to have the DT describe concrete physical properties
> > of the system which we can then map onto numbers we like, that way if we
> > get better information in future or just decide that completely
> > different metrics are appropriate for tuning we can just do that without
> > having to worry about translating the old metrics into new ones.  We can
> > then expose the tuning knobs to userspace for override if that's needed.
> > If doing system specific tuning on vertically integrated systems really
> > is terribly important it's not going to matter too much where the tuning
> > is but we also have to consider more general purpose systems.

> As replied to Rob, I'm not sure it is so easy to find any physical
> property that expresses what we essentially need (without maybe relying
> on a complex mix of hardware details and a model to extract numbers from
> them). Instead, we propose to have reasonable, per SoC, default numbers;
> and then let users fine tune their platform afterwards, without changing
> those default values.

If users are supposed to do fine tuning elsewhere after the fact why
bother with this initial callibration?  Something that's ballpark good
enough like just knowing the core used and perhaps some important
options on it should give an adequate starting point and not have the
issues with having the tuning numbers present as magic numbers.  Perhaps
we might also feed cache information in at some point.  If in future
we're able to improve those default numbers (or just adapt at runtime)
then even better.

It also seems a bit strange to expect people to do some tuning in one
place initially and then additional tuning somewhere else later, from
a user point of view I'd expect to always do my tuning in the same
place.

> > We're not going to get out of having to pick numbers at some point,
> > pushing them into DT doesn't get us out of that but it does make the
> > situation harder to manage long term and makes the performance for the
> > general user less relaible.  It's also just more work all round,
> > everyone doing the DT for a SoC is going to have to do some combination
> > of cargo culting or repeating the callibration.

> I'm most probably a bit naive here, but I see the calibration phase
> happening only once, after the platform is stable. You get default
> capacity values by running a pretty simple benchmark on a fixed
> configuration; and you put them somewhere (DTs still seem to be a
> sensible place to me). Then you'll be able to suit tuning needs 

Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files

[Rob Herring]

On Fri, Dec 11, 2015 at 8:41 AM, Arnd Bergmann  wrote:
> On Thursday 10 December 2015 17:38:23 Rob Herring wrote:
>> Platform dts files need to be reviewed primarily by the platform
>> maintainers as dts files typically go in thru their trees. Add the missing
>> paths where there are existing maintainers listed.
>>
>> Signed-off-by: Rob Herring 
>>
>
> Acked-by: Arnd Bergmann 
>
> Do you want to collect the Acks and take this through your git tree, so should
> we pick it up into arm-soc?

I'll take it.

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 2/2] mfd: arizona: Update binding docs for selecting mono/stereo outputs

[Rob Herring]

On Fri, Dec 11, 2015 at 10:28:23AM +, Charles Keepax wrote:
> Update the device tree binding documentation to include the wlf,out-mono
> property that is used to specify whether each output is a mono or stereo
> output.

You just added this binding and updating it already? While we may like 
kernel changes incremental, we don't like bindings evolving any more 
than necessary.
 
> Signed-off-by: Charles Keepax 
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index 2b6ccdb..489dd07 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -65,6 +65,10 @@ Optional properties:
>  that have not been specified are set to 0 by default. Entries are:
>   (wm5102, wm5110, wm8280, wm8997)
>   (wm8998, wm1814)
> +  - wlf,out-mono : A boolean indicating whether each output is mono or 
> stereo.
> +A non-zero value indicates a mono output. If present, the number of 
> values
> +should be less than or equal to the number of outputs, if less values are
> +supplied the additional outputs will be treated as stereo.

How do you know which outputs are which with a variable number? 

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 v2 4/8] dt-bindings: Add a binding for Mediatek Video Encoder

[Rob Herring]

On Fri, Dec 11, 2015 at 05:55:39PM +0800, Tiffany Lin wrote:
> Add a DT binding documentation of Video Encoder for the
> MT8173 SoC from Mediatek.
> 
> Signed-off-by: Tiffany Lin 

A question and minor issue below, otherwise:

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/media/mediatek-vcodec.txt  |   58 
> 
>  1 file changed, 58 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt 
> b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> new file mode 100644
> index 000..510cd81
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> @@ -0,0 +1,58 @@
> +Mediatek Video Codec
> +
> +Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
> +supports high resolution encoding functionalities.
> +
> +Required properties:
> +- compatible : "mediatek,mt8173-vcodec-enc" for encoder
> +- reg : Physical base address of the video codec registers and length of
> +  memory mapped region.
> +- interrupts : interrupt number to the cpu.
> +- mediatek,larb : must contain the local arbiters in the current Socs.
> +- clocks : list of clock specifiers, corresponding to entries in
> +  the clock-names property;
> +- clock-names: must contain "vencpll", "venc_lt_sel", "vcodecpll_370p5_ck"
> +- iommus : list of iommus specifiers should be enabled for hw encode.
> +  There are 2 cells needed to enable/disable iommu.
> +  The first one is local arbiter index(larbid), and the other is port
> +  index(portid) within local arbiter. Specifies the larbid and portid
> +  as defined in dt-binding/memory/mt8173-larb-port.h.
> +- mediatek,vpu : the node of video processor unit
> +
> +Example:
> +vcodec_enc: vcodec@0x18002000 {
> +compatible = "mediatek,mt8173-vcodec-enc";
> +reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
> +  <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
> +interrupts = ,
> +   ;
> +larb = <&larb3>,
> +   <&larb5>;
> +iommus = <&iommu M4U_LARB3_ID M4U_PORT_VENC_RCPU>,

Is this the same iommu as the VPU? If so, you can't have a mixed number 
of cells.

> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_REC>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_BSDMA>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_SV_COMV>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_RD_COMV>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_CUR_LUMA>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_CUR_CHROMA>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_REF_LUMA>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_REF_CHROMA>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_NBM_RDMA>,
> + <&iommu M4U_LARB3_ID M4U_PORT_VENC_NBM_WDMA>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_RCPU_SET2>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_REC_FRM_SET2>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_BSDMA_SET2>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_SV_COMA_SET2>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_RD_COMA_SET2>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_CUR_LUMA_SET2>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_CUR_CHROMA_SET2>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_REF_LUMA_SET2>,
> + <&iommu M4U_LARB5_ID M4U_PORT_VENC_REC_CHROMA_SET2>;
> +vpu = <&vpu>;

Need to update the example.

> +clocks = <&apmixedsys CLK_APMIXED_VENCPLL>,
> + <&topckgen CLK_TOP_VENC_LT_SEL>,
> + <&topckgen CLK_TOP_VCODECPLL_370P5>;
> +clock-names = "vencpll",
> +  "venc_lt_sel",
> +  "vcodecpll_370p5_ck";
> +  };
> -- 
> 1.7.9.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: [PATCH v2 1/8] dt-bindings: Add a binding for Mediatek Video Processor

[Rob Herring]

On Fri, Dec 11, 2015 at 05:55:36PM +0800, Tiffany Lin wrote:
> From: Andrew-CT Chen 
> 
> Add a DT binding documentation of Video Processor Unit for the
> MT8173 SoC from Mediatek.
> 
> Signed-off-by: Andrew-CT Chen 
> Signed-off-by: Tiffany Lin 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/media/mediatek-vpu.txt |   27 
> 
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt 
> b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
> new file mode 100644
> index 000..3c3a424
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
> @@ -0,0 +1,27 @@
> +* Mediatek Video Processor Unit
> +
> +Video Processor Unit is a HW video controller. It controls HW Codec including
> +H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor 
> (scale/rotate/color convert).
> +
> +Required properties:
> +  - compatible: "mediatek,mt8173-vpu"
> +  - reg: Must contain an entry for each entry in reg-names.
> +  - reg-names: Must include the following entries:
> +"tcm": tcm base
> +"cfg_reg": Main configuration registers base
> +  - interrupts: interrupt number to the cpu.
> +  - clocks : clock name from clock manager
> +  - clock-names: must be main. It is the main clock of VPU
> +  - iommus : phandle and IOMMU spcifier for the IOMMU that serves the VPU.
> +
> +Example:
> + vpu: vpu@1002 {
> + compatible = "mediatek,mt8173-vpu";
> + reg = <0 0x1002 0 0x3>,
> +   <0 0x1005 0 0x100>;
> + reg-names = "tcm", "cfg_reg";
> + interrupts = ;
> + clocks = <&topckgen TOP_SCP_SEL>;
> + clock-names = "main";
> + iommus = <&iommu M4U_PORT_VENC_RCPU>;
> + };
> -- 
> 1.7.9.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: [PATCH v7 02/14] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Philipp Zabel]

Hi Matthias,

thanks for your reply. It would be helpful if you could trim the quoted
text a bit when replying to a small part of a huge patch like this.

Am Freitag, den 11.12.2015, 18:10 +0100 schrieb Matthias Brugger:
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > new file mode 100644
> > index 000..a34c765
> > --- /dev/null
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -0,0 +1,562 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: YT SHEN 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * 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 
> > +#include 
> > +#include 
> 
> Do we need this include here?

No, thank you for noticing. Will be removed in the next version.

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: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Philipp Zabel]

Hi Hans,

thanks for moving this forward.

Am Freitag, den 11.12.2015, 16:41 +0100 schrieb Hans de Goede:
> Add reset_control_deassert_shared / reset_control_assert_shared
> functions which are intended for use by drivers for hw blocks which
> (may) share a reset line with another driver / hw block.
> 
> Unlike the regular reset_control_[de]assert functions these functions
> keep track of how often deassert_shared / assert_shared have been called
> and keep the line deasserted as long as deassert has been called more
> times than assert.
>
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -This is a new patch in v2 of this patch-set
> ---
>  drivers/reset/core.c | 121 
> ---
>  include/linux/reset-controller.h |   2 +
>  include/linux/reset.h|   2 +
>  3 files changed, 116 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index 9ab9290..8c3436c 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -22,16 +22,29 @@ static DEFINE_MUTEX(reset_controller_list_mutex);
>  static LIST_HEAD(reset_controller_list);
>  
>  /**
> + * struct reset_line - a reset line
> + * @list: list entry for the reset controllers reset line list
> + * @id:   ID of the reset line in the reset controller device
> + * @refcnt:   Number of reset_control structs referencing this device
> + * @deassert_cnt: Number of times this reset line has been deasserted
> + */
> +struct reset_line {
> + struct list_head list;
> + unsigned int id;
> + unsigned int refcnt;
> + unsigned int deassert_cnt;
> +};

I'd move rcdev into reset_line, too. That way the description is
complete, and we don't duplicate rcdev when there are multiple
reset_controls pointing here.

> +/**
>   * struct reset_control - a reset control
>   * @rcdev: a pointer to the reset controller device
>   * this reset control belongs to
> - * @id: ID of the reset controller in the reset
> - *  controller device
> + * @line:  reset line for this reset control
>   */
>  struct reset_control {
>   struct reset_controller_dev *rcdev;
> + struct reset_line *line;
>   struct device *dev;
> - unsigned int id;
>  };
>  
>  /**
[...]
> @@ -119,13 +134,55 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
>  int reset_control_deassert(struct reset_control *rstc)
>  {

Maybe WARN_ON(rstc->line->refcnt > 1) ?

>   if (rstc->rcdev->ops->deassert)
> - return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->id);
> + return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->line->id);
>  
>   return -ENOTSUPP;
>  }
>  EXPORT_SYMBOL_GPL(reset_control_deassert);
>  
>  /**
> + * reset_control_assert_shared - asserts a shared reset line
> + * @rstc: reset controller
> + *
> + * Assert a shared reset line, this functions decreases the deassert count
> + * of the line by one and asserts it if, and only if, the deassert count
> + * reaches 0.

"After calling this function the shared reset line may be asserted, or
 it may still be deasserted, as long as other users keep it so."

> + */
> +int reset_control_assert_shared(struct reset_control *rstc)
> +{
> + if (!rstc->rcdev->ops->assert)
> + return -ENOTSUPP;

WARN_ON(rstc->line->deassert_cnt == 0)

Actually, what to do in this case? Assume ops->assert was called, or do
it again to be sure? Certainly we don't want to wrap deassert_cnt, or
the next deassert_shared will do nothing.

> + rstc->line->deassert_cnt--;
> + if (rstc->line->deassert_cnt)

deassert_cnt isn't protected by any lock.

> + return 0;
> +
> + return rstc->rcdev->ops->assert(rstc->rcdev, rstc->line->id);
> +}
> +EXPORT_SYMBOL_GPL(reset_control_assert_shared);
> +
> +/**
> + * reset_control_deassert_shared - deasserts a shared reset line
> + * @rstc: reset controller
> + *
> + * Assert a shared reset line, this functions increases the deassert count

Deassert

> + * of the line by one and deasserts the reset line (if it was not already
> + * deasserted).

"After calling this function, the shared reset line is guaranteed to be
 deasserted."

> + */
> +int reset_control_deassert_shared(struct reset_control *rstc)
> +{
> + if (!rstc->rcdev->ops->deassert)
> + return -ENOTSUPP;
> +
> + rstc->line->deassert_cnt++;
> + if (rstc->line->deassert_cnt != 1)
> + return 0;
> +
> + return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->line->id);
> +}
> +EXPORT_SYMBOL_GPL(reset_control_deassert_shared);
> +
> +/**
>   * reset_control_status - returns a negative errno if not supported, a
>   * positive value if the reset line is asserted, or zero if the reset
>   * line is not asserted.
> @@ -134,12 +191,47 @@ EXPORT_SYMBOL_GPL(reset_control_deassert);
>  int reset_control_status(struct reset_control *rstc)
>  {
>   if (rstc->rcdev->ops->status)
> - return rstc->rcdev->ops->status(rstc->rcdev, rstc->id);
> 

Re: [PATCH v2 2/3] ehci-platform: Add support for controllers with multiple reset lines

[Philipp Zabel]

Am Freitag, den 11.12.2015, 16:41 +0100 schrieb Hans de Goede:
> From: Reinder de Haan 
> 
> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
> reset lines, the controller will not initialize while the reset for
> its companion is still asserted, which means we need to de-assert
> 2 resets for the controller to work.
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Use the new reset_control_[de]assert_shared reset-controller functions
> ---
>  Documentation/devicetree/bindings/usb/usb-ehci.txt |  2 +-
>  drivers/usb/host/ehci-platform.c   | 47 
> +-
>  2 files changed, 30 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
> b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> index a12d601..0701812 100644
> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> @@ -18,7 +18,7 @@ Optional properties:
>   - clocks : a list of phandle + clock specifier pairs
>   - phys : phandle + phy specifier pair
>   - phy-names : "usb"
> - - resets : phandle + reset specifier pair
> + - resets : a list of phandle + reset specifier pairs

Are there documented names for these resets? Is the companion you
mention the Port Control?

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: [PATCH v7 02/14] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Matthias Brugger]

On 30/11/15 22:07, Philipp Zabel wrote:

From: CK Hu 

This patch adds an initial DRM driver for the Mediatek MT8173 DISP
subsystem. It currently supports two fixed output streams from the
OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.

Signed-off-by: CK Hu 
Signed-off-by: YT Shen 
Signed-off-by: Philipp Zabel 
---
Changes since v6:
  - Split disp_ovl driver from mtk_drm_crtc code
  - Added crtc and plane state atomic reset functions
  - Toned down debug messages
  - Improved error handling for hardware initialization
  - Get/put smi_larb in crtc_enable/disable
  - Added memory barrier before marking crtc state as ready
  - Changed crtc_disable to wait for vblank
  - Renamed component power_on/off to start/stop
  - Made component ops optional
  - Moved crtc creation from disp_ovl driver bind callback into mtk_drm_kms_init
  - Various fixes
  - Added support for DRIVER_PRIME feature
  - Moved DISP_OVL, DSI, DPI and component initialization into the respective 
drivers
---
  drivers/gpu/drm/Kconfig |   2 +
  drivers/gpu/drm/Makefile|   1 +
  drivers/gpu/drm/mediatek/Kconfig|  16 +
  drivers/gpu/drm/mediatek/Makefile   |  11 +
  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 301 +++
  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 565 
  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |  31 ++
  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 355 +
  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  41 ++
  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 275 ++
  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 148 
  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 562 +++
  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  53 +++
  drivers/gpu/drm/mediatek/mtk_drm_fb.c   | 135 +++
  drivers/gpu/drm/mediatek/mtk_drm_fb.h   |  28 ++
  drivers/gpu/drm/mediatek/mtk_drm_gem.c  | 227 +++
  drivers/gpu/drm/mediatek/mtk_drm_gem.h  |  55 +++
  drivers/gpu/drm/mediatek/mtk_drm_plane.c| 238 
  drivers/gpu/drm/mediatek/mtk_drm_plane.h|  58 +++
  19 files changed, 3102 insertions(+)
  create mode 100644 drivers/gpu/drm/mediatek/Kconfig
  create mode 100644 drivers/gpu/drm/mediatek/Makefile
  create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4bf9a1..8fdb0c2 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -266,3 +266,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
  source "drivers/gpu/drm/imx/Kconfig"

  source "drivers/gpu/drm/vc4/Kconfig"
+
+source "drivers/gpu/drm/mediatek/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1e9ff4c..607a49f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_MSM) += msm/
  obj-$(CONFIG_DRM_TEGRA) += tegra/
  obj-$(CONFIG_DRM_STI) += sti/
  obj-$(CONFIG_DRM_IMX) += imx/
+obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
  obj-y += i2c/
  obj-y += panel/
  obj-y += bridge/
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
new file mode 100644
index 000..5343cf1
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -0,0 +1,16 @@
+config DRM_MEDIATEK
+   tristate "DRM Support for Mediatek SoCs"
+   depends on DRM
+   depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
+   select MTK_SMI
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   select DRM_PANEL_SIMPLE
+   select DRM_KMS_HELPER
+   select IOMMU_DMA
+   help
+ Choose this option if you have a Mediatek SoCs.
+ The module will be called mediatek-drm
+ This driver provides kernel mode setting and
+ buffer management to userspace.
+
diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
new file mode 100644
index 000..bd6e8df
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -0,0 +1,11 @@
+mediatek-drm-y := mtk_disp_ovl.o \
+ mtk

[PATCH v9 3/3] ARM: dts: TS-4800: add basic device tree

[Damien Riegel]

This device tree adds support for TS-4800 by Technologic Systems. This
board is based on MX51-babbage, but there are some subtle differences in
the pins used, and there is an additional FPGA that is memory-mapped.

More details here:
  http://wiki.embeddedarm.com/wiki/TS-4800

Signed-off-by: Damien Riegel 
---
 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/imx51-ts4800.dts | 180 +
 2 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx51-ts4800.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..41b9985 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -258,7 +258,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
imx51-apf51dev.dtb \
imx51-babbage.dtb \
imx51-digi-connectcore-jsk.dtb \
-   imx51-eukrea-mbimxsd51-baseboard.dtb
+   imx51-eukrea-mbimxsd51-baseboard.dtb \
+   imx51-ts4800.dtb
 dtb-$(CONFIG_SOC_IMX53) += \
imx53-ard.dtb \
imx53-m53evk.dtb \
diff --git a/arch/arm/boot/dts/imx51-ts4800.dts 
b/arch/arm/boot/dts/imx51-ts4800.dts
new file mode 100644
index 000..f1317f7
--- /dev/null
+++ b/arch/arm/boot/dts/imx51-ts4800.dts
@@ -0,0 +1,180 @@
+/*
+ * Copyright 2015 Savoir-faire Linux
+ *
+ * This device tree is based on imx51-babbage.dts
+ *
+ * Licensed under the X11 license or the GPL v2 (or later)
+ */
+
+/dts-v1/;
+#include "imx51.dtsi"
+
+/ {
+   model = "Technologic Systems TS-4800";
+   compatible = "technologic,imx51-ts4800", "fsl,imx51";
+
+   chosen {
+   stdout-path = &uart1;
+   };
+
+   memory {
+   reg = <0x9000 0x1000>;
+   };
+
+   soc {
+   fpga {
+   compatible = "simple-bus";
+   reg = <0xb000 0x1d000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   syscon: syscon@b001 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0xb001 0x3d>;
+   reg-io-width = <2>;
+
+   wdt@e {
+   compatible = "technologic,ts4800-wdt";
+   syscon = <&syscon 0xe>;
+   };
+   };
+   };
+   };
+
+   clocks {
+   ckih1 {
+   clock-frequency = <22579200>;
+   };
+
+   ckih2 {
+   clock-frequency = <24576000>;
+   };
+   };
+};
+
+&esdhc1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_esdhc1>;
+   cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+   wp-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+};
+
+&fec {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_fec>;
+   phy-mode = "mii";
+   phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>;
+   phy-reset-duration = <1>;
+   status = "okay";
+};
+
+&i2c2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c2>;
+   status = "okay";
+
+   rtc: m41t00@68 {
+   compatible = "stm,m41t00";
+   reg = <0x68>;
+   };
+};
+
+&uart1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart1>;
+   status = "okay";
+};
+
+&uart2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart2>;
+   status = "okay";
+};
+
+&uart3 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart3>;
+   status = "okay";
+};
+
+&iomuxc {
+   pinctrl_ecspi1: ecspi1grp {
+   fsl,pins = <
+   MX51_PAD_CSPI1_MISO__ECSPI1_MISO0x185
+   MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI0x185
+   MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK0x185
+   MX51_PAD_CSPI1_SS0__GPIO4_240x85 /* CS0 */
+   >;
+   };
+
+   pinctrl_esdhc1: esdhc1grp {
+   fsl,pins = <
+   MX51_PAD_SD1_CMD__SD1_CMD   0x400020d5
+   MX51_PAD_SD1_CLK__SD1_CLK   0x20d5
+   MX51_PAD_SD1_DATA0__SD1_DATA0   0x20d5
+   MX51_PAD_SD1_DATA1__SD1_DATA1   0x20d5
+   MX51_PAD_SD1_DATA2__SD1_DATA2   0x20d5
+   MX51_PAD_SD1_DATA3__SD1_DATA3   0x20d5
+   MX51_PAD_GPIO1_0__GPIO1_0   0x100
+   MX51_PAD_GPIO1_1__GPIO1_1   0x100
+   >;
+   };
+
+   pinctrl_fec: fecgrp {
+   fsl,pins = <
+   MX51_PAD_EIM_EB2__FEC_MDIO  0x01f5
+   MX51_PAD_EIM_EB3__FEC_RDATA10x0085
+  

[PATCH v9 0/3] Add board support for TS-4800

[Damien Riegel]

This patch serie adds support for TS-4800 board. This board,
  
manufactured by Technologic Systems, is based on an IMX515.

The first stage bootloader, called TS-BOOTROM, enables the watchdog,
so a watchdog driver is required to prevent board from rebooting. It is
handled in a separate patchset.

The current device tree is minimal but it allows to get a shell on the
board.

Changes in v9:
 - Changed dts file license to X11/GPL
 - Reordered i2c2 node to be alphabetically sorted
 - Dropped container node in iomuxc

Changes in v8:
 - Split the serie into two parts, watchdog and dts, because there are
   no build dependencies between the two, and the syscon patch has been
   separately applied in Lee Jones' tree.
 - As a consequence, I dropped the patch which enabled the watchdog in
   imx_v6_v7_defconfig to ease the integration.

Changes in v7:
 - syscon: change bus-width DT property to reg-io-width
 - watchdog: add dependency on HAS_IOMEM (spotted by a 0-day build) 

Changes in v6:
 - vendor prefix: reorder to sort alphabetically (wrong order since v3)
 - split commit adding device tree into two patches: one for the doc, one for
   the bindings

Changes in v5:
 - watchdog: changed iteration stop condition in set_timeout to be less
   error prone

Changes in v4:
 - syscon: rewrite DT property reading to be clearer
 - watchdog: made fixes suggested by Guenter (now uses
   watchdog_init_timeout, u32 instead of u16, fixed error checking in
   probe, cleaned set_timeout)

Changes in v3:
 - Rebased on v4.3
 - Changed vendor prefix from "ts" to "technologic"
 - Added a DT option to generic syscon driver to allow regmap configuration
 - Dropped custom mfd driver, use generic syscon driver instead.

Changes in v2:
 - Added a mfd driver to handle syscon registers
 - The watchdog driver now uses the regmap (created by the mfd driver)
   to access the feed register
 - Remove watchdog's dependency on SOC_IMX51

Damien Riegel (3):
  of: add vendor prefix for Technologic Systems
  of: documentation: add bindings documentation for TS-4800
  ARM: dts: TS-4800: add basic device tree

 .../devicetree/bindings/arm/technologic.txt|   6 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/imx51-ts4800.dts | 180 +
 4 files changed, 189 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/technologic.txt
 create mode 100644 arch/arm/boot/dts/imx51-ts4800.dts

-- 
2.5.0

--
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 v9 2/3] of: documentation: add bindings documentation for TS-4800

[Damien Riegel]

This adds the documentation for the TS-4800 by Technologic Systems.

Signed-off-by: Damien Riegel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/technologic.txt | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/technologic.txt

diff --git a/Documentation/devicetree/bindings/arm/technologic.txt 
b/Documentation/devicetree/bindings/arm/technologic.txt
new file mode 100644
index 000..8422988
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/technologic.txt
@@ -0,0 +1,6 @@
+Technologic Systems Platforms Device Tree Bindings
+--
+
+TS-4800 board
+Required root node properties:
+   - compatible = "technologic,imx51-ts4800", "fsl,imx51";
-- 
2.5.0

--
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 v9 1/3] of: add vendor prefix for Technologic Systems

[Damien Riegel]

Signed-off-by: Damien Riegel 
Acked-by: Lee Jones 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..d3a206d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -215,6 +215,7 @@ stericsson  ST-Ericsson
 synology   Synology, Inc.
 tbsTBS Technologies
 tclToby Churchill Ltd.
+technologicTechnologic Systems
 thine  THine Electronics, Inc.
 ti Texas Instruments
 tlmTrusted Logic Mobility
-- 
2.5.0

--
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/5] dt-bindings: mediatek: Modify pinctrl bindings for mt2701

[Rob Herring]

On Fri, Dec 11, 2015 at 05:07:49PM +0800, Biao Huang wrote:
> Signed-off-by: Biao Huang 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt 
> b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
> index 0480bc3..9ffb0b2 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
> @@ -4,10 +4,11 @@ The Mediatek's Pin controller is used to control SoC pins.
>  
>  Required properties:
>  - compatible: value should be one of the following.
> -(a) "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl.
> -(b) "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl.
> -(c) "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
> -(d) "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.
> + "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl.
> + "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
> + "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.
> + "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl.
> + "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl.
>  - pins-are-numbered: Specify the subnodes are using numbered pinmux to
>specify pins.
>  - gpio-controller : Marks the device node as a gpio controller.
> -- 
> 1.7.9.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: [PATCH v3 2/9] Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings

[Rob Herring]

On Wed, Dec 9, 2015 at 3:37 AM, Maxime Coquelin
 wrote:
> Hi Rob,
>
> 2015-12-09 4:41 GMT+01:00 Rob Herring :
>> On Tue, Dec 08, 2015 at 01:45:04PM +0100, Maxime Coquelin wrote:
>>> Signed-off-by: Maxime Coquelin 
>>> ---
>>>  .../bindings/pinctrl/st,stm32-pinctrl.txt  | 126 
>>> +
>>>  1 file changed, 126 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt 
>>> b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>>> new file mode 100644
>>> index 000..7b4800c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>>> @@ -0,0 +1,126 @@
>>> +* STM32 GPIO and Pin Mux/Config controller
>>> +
>>> +STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config 
>>> hardware
>>> +controller. It controls the input/output settings on the available pins and
>>> +also provides ability to multiplex and configure the output of various 
>>> on-chip
>>> +controllers onto these pads.
>>> +
>>> +Pin controller node:
>>> +Required properies:
>>> + - compatible: value should be one of the following:
>>> +   (a) "st,stm32f429-pinctrl"
>>> + - #address-cells: The value of this property must be 1
>>> + - #size-cells   : The value of this property must be 1
>>> + - ranges: defines mapping between pin controller node (parent) to
>>> +   gpio-bank node (children).
>>> + - pins-are-numbered: Specify the subnodes are using numbered pinmux to
>>> +   specify pins.
>>> +
>>> +GPIO controller/bank node:
>>> +Required properties:
>>> + - gpio-controller : Indicates this device is a GPIO controller
>>> + - #gpio-cells : Should be two.
>>> + The first cell is the pin number
>>> + The second one is the polarity:
>>> + - 0 for active high
>>> + - 1 for active low
>>> + - reg : The gpio address range, relative to the pinctrl 
>>> range
>>> + - clocks  : clock that drives this bank
>>> + - st,bank-name: Should be a name string for this bank as 
>>> specified in
>>> +   the datasheet
>>
>> How do you intend to use this? We should come up with something generic
>> or drop it.
> Good point.
> It is used to have a meaningful name set in gpio_chip's label.

Who cares about the gpio_chip name?

> I see two alternatives:
>  1. replace "st,bank-name" with label
>  2. use aliases, and construct label in driver with something like:
>  kasprintf(GFP_KERNEL, "GPIO%c", 'A' + of_alias_get_id(np, "gpio"));
>
> What do you prefer?

I prefer to not need it. Of these 2 though, probably using label.
However, I'm not convinced to say yes, we should use that because it
will only encourage others to do the same.

> Do you have other ideas?

We do need names on individual lines though. I'd rather not complicate
things by having labels for both unless we can define the need for it.

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 v3 6/7] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl

[Rob Herring]

On Fri, Dec 11, 2015 at 03:45:20PM +0800, Jiancheng Xue wrote:
> Add device tree bindings for Hi3519 system controller.
> 
> Signed-off-by: Jiancheng Xue 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt 
> b/Documentation/devicetree/bindings/mfd/hi3519.txt
> new file mode 100644
> index 000..4b1c294
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> @@ -0,0 +1,14 @@
> +* Hisilicon Hi3519 System Controller Block
> +
> +This bindings use the following binding:
> +Dcumentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible: "hislicon,hi3519-sysctrl".
> +- reg: the register region of this block
> +
> +Examples:
> +sysctrl: system-controller@1201 {
> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> + reg = <0x1201 0x1000>;
> +};
> -- 
> 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
--
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 7/7] ARM: dts: add dts files for Hi3519

[Rob Herring]

On Fri, Dec 11, 2015 at 03:45:21PM +0800, Jiancheng Xue wrote:
> add dts files for Hi3519
> 
> Signed-off-by: Jiancheng Xue 
> ---
>  arch/arm/boot/dts/Makefile|   2 +
>  arch/arm/boot/dts/hi3519-demb.dts |  42 +++
>  arch/arm/boot/dts/hi3519.dtsi | 142 
> ++
>  3 files changed, 186 insertions(+)
>  create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
>  create mode 100644 arch/arm/boot/dts/hi3519.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 30bbc37..1ff3ed9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -135,6 +135,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
>   exynos5800-peach-pi.dtb
>  dtb-$(CONFIG_ARCH_HI3xxx) += \
>   hi3620-hi4511.dtb
> +dtb-$(CONFIG_ARCH_HISI) += \
> + hi3519-demb.dtb
>  dtb-$(CONFIG_ARCH_HIX5HD2) += \
>   hisi-x5hd2-dkb.dtb
>  dtb-$(CONFIG_ARCH_HIGHBANK) += \
> diff --git a/arch/arm/boot/dts/hi3519-demb.dts 
> b/arch/arm/boot/dts/hi3519-demb.dts
> new file mode 100644
> index 000..6991ab6
> --- /dev/null
> +++ b/arch/arm/boot/dts/hi3519-demb.dts
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + */
> +
> +/dts-v1/;
> +#include "hi3519.dtsi"
> +
> +/ {
> + model = "HiSilicon HI3519 DEMO Board";
> + compatible = "hisilicon,hi3519";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x4000>;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&dual_timer0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
> new file mode 100644
> index 000..50b736e
> --- /dev/null
> +++ b/arch/arm/boot/dts/hi3519.dtsi
> @@ -0,0 +1,142 @@
> +/*
> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + */
> +
> +#include "skeleton.dtsi"

Don't include skeleton.dtsi. We've decided it was a bad idea.

> +#include 
> +/ {
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {

Single core system? Add the other cpu nodes if not. Adding them doesn't 
have to be in sync with SMP kernel support.

> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0>;
> + };
> + };
> +
> + gic: interrupt-controller@1030 {
> + compatible = "arm,cortex-a7-gic";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + interrupt-parent = <&gic>;
> + ranges;

Looks like everything is in 0x12xx range, so you should add actual 
translation here if that's the case.

> +
> + amba {

Is this actually a separate bus in the physical design of the chip?

> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "arm,amba-bus";

Just simple-bus. "arm,amba-bus" is not any type of bus, nor is it 
documented.

> + ranges;
> +
> + uart0: serial@1210 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x1210 0x1000>;
> + interrupts = <0 4 4>;
> +

Re: [RFC PATCH 0/7] mtd: partitions: add of_match_table support

[Michal Suchanek]

On 11 December 2015 at 17:00, Geert Uytterhoeven  wrote:
> Hi Michal,
>
> On Fri, Dec 11, 2015 at 4:34 PM, Michal Suchanek  wrote:
>> On 11 December 2015 at 09:44, Geert Uytterhoeven  
>> wrote:
>>> On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
>>>  wrote:
 On Sat, Dec 05, 2015 at 11:15:54AM +0100, Geert Uytterhoeven wrote:
> On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>  wrote:
> > There have been several discussions [1] about adding a device tree 
> > binding for
> > associating flash devices with the partition parser(s) that are used on 
> > the
> > flash. There are a few reasons:
> >
> >  (1) drivers shouldn't have to be encoding platform knowledge by 
> > listing what
> >  parsers might be used on a given system (this is the currently all 
> > that's
> >  supported)
> >  (2) we can't just scan for all supported parsers (like the block 
> > system does), since
> >  there is a wide diversity of "formats" (no standardization), and 
> > it is not
> >  always safe or efficient to attempt to do so, particularly since 
> > many of
> >  them allow their data structures to be placed anywhere on the 
> > flash, and
> >  so require scanning the entire flash device to find them.
>
> I read the second reason, but would it be useful to (partially) merge
> block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos
> partitions
> on an mtd device??

 I kinda agree with Michal: is there a good use case?
>>>
>>> I don't have an immediate use case.
>>> Just looking at it from a high-level viewpoint.
>>>
 Really, MTD partitioning is not a highly-scalable design. Particularly,
 it's not typically that well-suited to large (read: unreliable) NAND
 flash, where fixing partitions at the raw flash level mostly serves to
 restrict UBI's ability to wear-level across the device. For that sort of
 case, it's best if people are using UBI volumes on a (mostly?)
 unpartitioned MTD, instead of using MTD partitions as the main
 separation mechanism. Also, most partition designs (either MTD or block)
 aren't very robust against bitflips, read disturb, etc.

 IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
 and so I don't plan to do that sort of work myself. If you can provide
 some better argument for it, and some nice maintainable code to go with
 it, then of course it could be considered :)
>>>
>>> There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
>>> working on have.
>>>
>>
>> Yes, you can dump the content of a NOR flash to a file, attach a loop
>> device to it, and if block devices had the ability to use flash
>> partitioning access the different partitions.
>>
>> Maybe it would be more useful to use some kind of mtdloop, though.
>> There might even be one already. I never needed it.
>
> That's the inverse, which looks like a solid use case to me ;-)
> E.g. for investigation or virtualization.
>
> You can do this already in userspace with kpartx, though.
>

What kind of partitioning does kpartx support? I do not see that
documented anywhere.

Anyway, it seems there is no mtdblock so in case of non-ecc (or
hidden-ecc) flashes you could use losetup -P and block2mtd on each
partition to look at the dumped flash content or even prepare flash
images. So long as the kernel supports the partitioning scheme used on
the flash.

Thanks

Michal
--
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 09/14] DEVICETREE: Add bindings for PIC32 usart driver

[Joshua Henderson]

Rob,

On 11/22/2015 02:56 PM, Rob Herring wrote:
> On Fri, Nov 20, 2015 at 05:17:21PM -0700, Joshua Henderson wrote:
>> From: Andrei Pistirica 
>>
>> Document the devicetree bindings for the USART peripheral found on
>> Microchip PIC32 class devices.
>>
>> Signed-off-by: Andrei Pistirica 
>> Signed-off-by: Joshua Henderson 
>> ---
>>  .../bindings/serial/microchip,pic32-usart.txt  |   29 
>> 
>>  1 file changed, 29 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/serial/microchip,pic32-usart.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/serial/microchip,pic32-usart.txt 
>> b/Documentation/devicetree/bindings/serial/microchip,pic32-usart.txt
>> new file mode 100644
>> index 000..c87321c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/microchip,pic32-usart.txt
>> @@ -0,0 +1,29 @@
>> +* Microchip Universal Synchronous Asynchronous Receiver/Transmitter (USART)
>> +
>> +Required properties:
>> +- compatible: Should be "microchip,pic32-usart"
> 
> Again, should be more specific.
> 

Ack.  In addition, will replace all instances of USART with UART.

>> +- reg: Should contain registers location and length
>> +- interrupts: Should contain interrupt
>> +- pinctrl: Should contain pinctrl for TX/RX/RTS/CTS
>> +
>> +Optional properties:
>> +- microchip,uart-has-rtscts : Indicate the uart has hardware flow control
>> +- rts-gpios: RTS pin for USP-based UART if microchip,uart-has-rtscts
>> +- cts-gpios: CTS pin for USP-based UART if microchip,uart-has-rtscts
> 
> This appears to just be copied for Sirf UART.
> 
> Doesn't *-gpios being present imply having h/w 
> flow-control (i.e. microchip,uart-has-rtscts)?
> 
> Rob

Agreed.  microchip,uart-has-rtscts will be dropped and it turns out we don't 
really need the rtc-gpios property.

Josh

> 
>> +
>> +Example:
>> +usart0: serial@1f822000 {
>> +compatible = "microchip,pic32-usart";
>> +reg = <0x1f822000 0x50>;
>> +interrupts = ,
>> + ,
>> + > IRQ_TYPE_NONE>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <
>> +&pinctrl_uart1
>> +&pinctrl_uart1_cts
>> +&pinctrl_uart1_rts>;
>> +microchip,uart-has-rtscts;
>> +cts-gpios = <&pioB 15 0>;
>> +rts-gpios = <&pioD 1 0>;
>> +};
>> -- 
>> 1.7.9.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: [RFC PATCH 0/7] mtd: partitions: add of_match_table support

[Geert Uytterhoeven]

Hi Michal,

On Fri, Dec 11, 2015 at 4:34 PM, Michal Suchanek  wrote:
> On 11 December 2015 at 09:44, Geert Uytterhoeven  wrote:
>> On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
>>  wrote:
>>> On Sat, Dec 05, 2015 at 11:15:54AM +0100, Geert Uytterhoeven wrote:
 On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
  wrote:
 > There have been several discussions [1] about adding a device tree 
 > binding for
 > associating flash devices with the partition parser(s) that are used on 
 > the
 > flash. There are a few reasons:
 >
 >  (1) drivers shouldn't have to be encoding platform knowledge by listing 
 > what
 >  parsers might be used on a given system (this is the currently all 
 > that's
 >  supported)
 >  (2) we can't just scan for all supported parsers (like the block system 
 > does), since
 >  there is a wide diversity of "formats" (no standardization), and it 
 > is not
 >  always safe or efficient to attempt to do so, particularly since 
 > many of
 >  them allow their data structures to be placed anywhere on the 
 > flash, and
 >  so require scanning the entire flash device to find them.

 I read the second reason, but would it be useful to (partially) merge
 block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos
 partitions
 on an mtd device??
>>>
>>> I kinda agree with Michal: is there a good use case?
>>
>> I don't have an immediate use case.
>> Just looking at it from a high-level viewpoint.
>>
>>> Really, MTD partitioning is not a highly-scalable design. Particularly,
>>> it's not typically that well-suited to large (read: unreliable) NAND
>>> flash, where fixing partitions at the raw flash level mostly serves to
>>> restrict UBI's ability to wear-level across the device. For that sort of
>>> case, it's best if people are using UBI volumes on a (mostly?)
>>> unpartitioned MTD, instead of using MTD partitions as the main
>>> separation mechanism. Also, most partition designs (either MTD or block)
>>> aren't very robust against bitflips, read disturb, etc.
>>>
>>> IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
>>> and so I don't plan to do that sort of work myself. If you can provide
>>> some better argument for it, and some nice maintainable code to go with
>>> it, then of course it could be considered :)
>>
>> There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
>> working on have.
>>
>
> Yes, you can dump the content of a NOR flash to a file, attach a loop
> device to it, and if block devices had the ability to use flash
> partitioning access the different partitions.
>
> Maybe it would be more useful to use some kind of mtdloop, though.
> There might even be one already. I never needed it.

That's the inverse, which looks like a solid use case to me ;-)
E.g. for investigation or virtualization.

You can do this already in userspace with kpartx, though.

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: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

[Michal Suchanek]

Hello,

On 10 December 2015 at 21:43, Brian Norris  wrote:
> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>> On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>> > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>> > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>> > >  wrote:
>> >
>> > >> +
>> > >> +Examples:
>> > >> +
>> > >> +flash@0 {
>> > >> +   partitions {
>> > >> +   compatible = "google,fmap";
>> > >> +   };
>> > >> +};
>> > >
>> > > I wonder if this wouldn't be better served in a separate binding doc
>> > > with its compatible name as the filename, like we do with
>> > > driver^Whardware blocks, especially if we want to add more parsers.
>> >
>> >
>> > I find that *very* counter productive for bindings that go to the same
>> > node. You have a description of a node, and then suddenly there you
>> > have another file with another description of the same node. Totally
>> > awesome.
>>
>> I can't actually work out from that if you're agreeing with the
>> original post or the first reply.
>
> Perhaps I'm biased, but I think he was agreeing with the first reply.
> (Particularly, "I find that *very* counter productive" uses the word
> "that" to refer to "separate binding doc[s]".)
>
>
> I believe Michal is bringing up the (important, IMO) point that if
> distinct partition types are being described in the same node, then any
> use of additional properties *must* be closely coordinated. We can't
> have two parsers "foo" and "bar" defining conflicting uses of the same
> property in the same node, like this:
>

I have seen some MFD bindings which are described in multiple files
with no crossreference whatsoever.

If on-flash partition table bindings are going to be the same then
people are not going to find there are even some on-flash partition
table bindings (because the document describing the in-DT bindings is
complete and exhaustive, right). Can't even imagine coordination.

When you have to grep the tree for docs anyway what's even the point
of the Documentation directory?

You can just grep the whole tree.

Thanks

Michal
--
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 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Geert Uytterhoeven]

Hi Bjorn,

On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas  wrote:
> On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
>> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
>> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
>> > > this short series adds generic gen2 and SoC-specific r8a7793 
>> > > compatibility
>> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
>> > > provide a complete set of compatibility strings for known Gen2 SoCs.
>> > >
>> > > Key Changes in v2:
>> > > * Include "rcar-" in generic bindings
>> > >
>> > > Simon Horman (4):
>> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> > >   PCI: rcar-gen2: add device tree support for r8a7793
>> > >   PCI: rcar: add gen2 fallback compatibility string
>> > >   PCI: rcar: add device tree support for r8a7793
>> > >
>> > >  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 12 
>> > > ++--
>> > >  Documentation/devicetree/bindings/pci/rcar-pci.txt  | 14 
>> > > +++---
>> > >  drivers/pci/host/pci-rcar-gen2.c|  1 +
>> > >  drivers/pci/host/pcie-rcar.c|  1 +
>> > >  4 files changed, 23 insertions(+), 5 deletions(-)
>> >
>> > I applied these:
>> >
>> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> > >   PCI: rcar: add gen2 fallback compatibility string
>> >
>> > to pci/host-rcar for v4.5, thanks!
>> >
>> > I haven't applied the R8A7793 binding documentation updates yet, but
>> > I'll be happy to do so given a short description of why they're
>> > useful (since they don't update a DT or the driver).  Or they could be
>> > merged via a DT tree.
>>
>> To clarify: you would like a description in the changelog?
>
> Yes, please.  The email discussion so far hasn't contained what I'm
> looking for (if it had, I would have just inserted it and been done
> with it).
>
> Apparently it has to do with the stable DT rules, which I don't know.
> A concrete example would probably help clear it up.

The stable DT rules mean that an old DTS should keep on working with
newer kernels.

Suppose we have two SoCs, that both contain "foo" modules, which look
identical. Hence the DTS for both declares the devices to be compatible
with "vendor,foo".

Later, we discover a difference between the two "foo" modules in the two
SoCs (e.g. a feature present in one of them, or worse, a bug), which we
need to handle in the driver. But how can we distinguish between them?
We can change the compatible value in the DTS, but that means the user
has to update the DTS when updating the kernel. For a new feature that
may be deemed acceptable, for a bug fix that's not acceptable.

Hence we always use an SoC-specific compatible value, which may or may
not be accompanied by a family-specific and/or generic compatible value.
As long as everything can be handled the same, the driver will just match
against the most generic compatible value used. But if needed later, the
driver can be updated to match against a more specific compatible value,
and can have special handling for  a module in a specific SoC.

So that's why we want to have compatible value in the DT bindings that
are not necessarily used by the driver.

In a perfect world, where all hardware is properly documented, or even
Open Source, we wouldn't need this. There we could just declare a device
compatible with what it really is, based on the module's internal version ID
(ideally a git commit ID of its HDL source ;-).

I hope the above explains it. If you have more questions, feel free to ask!

> I've applied the parts that touch PCI.  I won't be offended if the
> binding documentation patches go as-is via another tree.  It's just
> that if *I'm* going to apply them, I'd like to understand better what
> the benefit is.

DT binding updates typically go through the subsystem maintainer,
just like driver updates.

Thanks!

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 v2 3/3] ohci-platform: Add support for controllers with multiple reset lines

[Hans de Goede]

At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-New patch in v2 of this patch-set, to complement the identical patch for
 the ehci-platform code
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt |  2 +-
 drivers/usb/host/ohci-platform.c   | 49 +-
 2 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt 
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 19233b7..9df4569 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -14,7 +14,7 @@ Optional properties:
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
 - phy-names : "usb"
-- resets : phandle + reset specifier pair
+- resets : a list of phandle + reset specifier pairs
 
 Example:
 
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index c2669f18..7d8bbc4 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -33,11 +33,12 @@
 
 #define DRIVER_DESC "OHCI generic platform driver"
 #define OHCI_MAX_CLKS 3
+#define OHCI_MAX_RESETS 2
 #define hcd_to_ohci_priv(h) ((struct ohci_platform_priv *)hcd_to_ohci(h)->priv)
 
 struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
-   struct reset_control *rst;
+   struct reset_control *resets[OHCI_MAX_RESETS];
struct phy **phys;
int num_phys;
 };
@@ -117,7 +118,7 @@ static int ohci_platform_probe(struct platform_device *dev)
struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
-   int err, irq, phy_num, clk = 0;
+   int err, irq, phy_num, clk = 0, rst = 0;
 
if (usb_disabled())
return -ENODEV;
@@ -195,19 +196,23 @@ static int ohci_platform_probe(struct platform_device 
*dev)
break;
}
}
-
-   }
-
-   priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
-   if (IS_ERR(priv->rst)) {
-   err = PTR_ERR(priv->rst);
-   if (err == -EPROBE_DEFER)
-   goto err_put_clks;
-   priv->rst = NULL;
-   } else {
-   err = reset_control_deassert(priv->rst);
-   if (err)
-   goto err_put_clks;
+   for (rst = 0; rst < OHCI_MAX_RESETS; rst++) {
+   priv->resets[rst] =
+   of_reset_control_get_by_index(dev->dev.of_node,
+ rst);
+   if (IS_ERR(priv->resets[rst])) {
+   err = PTR_ERR(priv->resets[rst]);
+   if (err == -EPROBE_DEFER)
+   goto err_reset;
+   priv->resets[rst] = NULL;
+   break;
+   }
+   err = reset_control_deassert_shared(priv->resets[rst]);
+   if (err) {
+   reset_control_put(priv->resets[rst]);
+   goto err_reset;
+   }
+   }
}
 
if (pdata->big_endian_desc)
@@ -265,8 +270,10 @@ err_power:
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
-   if (priv->rst)
-   reset_control_assert(priv->rst);
+   while (--rst >= 0) {
+   reset_control_assert_shared(priv->resets[rst]);
+   reset_control_put(priv->resets[rst]);
+   }
 err_put_clks:
while (--clk >= 0)
clk_put(priv->clks[clk]);
@@ -284,15 +291,17 @@ static int ohci_platform_remove(struct platform_device 
*dev)
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
-   int clk;
+   int clk, rst;
 
usb_remove_hcd(hcd);
 
if (pdata->power_off)
pdata->power_off(dev);
 
-   if (priv->rst)
-   reset_control_assert(priv->rst);
+   for (rst = 0; rst < OHCI_MAX_RESETS && priv->resets[rst]; rst++) {
+   reset_control_assert_shared(priv->resets[rst]);
+   reset_control_put(priv->resets[rst]);
+   }
 
for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++)
clk_put(priv->clks[clk]);
-- 
2.5.0

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

[PATCH v2 2/3] ehci-platform: Add support for controllers with multiple reset lines

[Hans de Goede]

From: Reinder de Haan 

At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.

Signed-off-by: Reinder de Haan 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use the new reset_control_[de]assert_shared reset-controller functions
---
 Documentation/devicetree/bindings/usb/usb-ehci.txt |  2 +-
 drivers/usb/host/ehci-platform.c   | 47 +-
 2 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index a12d601..0701812 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -18,7 +18,7 @@ Optional properties:
  - clocks : a list of phandle + clock specifier pairs
  - phys : phandle + phy specifier pair
  - phy-names : "usb"
- - resets : phandle + reset specifier pair
+ - resets : a list of phandle + reset specifier pairs
 
 Example (Sequoia 440EPx):
 ehci@e300 {
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index bd7082f2..6fbf32a 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -39,11 +39,12 @@
 
 #define DRIVER_DESC "EHCI generic platform driver"
 #define EHCI_MAX_CLKS 3
+#define EHCI_MAX_RESETS 2
 #define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
 
 struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
-   struct reset_control *rst;
+   struct reset_control *resets[EHCI_MAX_RESETS];
struct phy **phys;
int num_phys;
bool reset_on_resume;
@@ -149,7 +150,7 @@ static int ehci_platform_probe(struct platform_device *dev)
struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ehci_platform_priv *priv;
struct ehci_hcd *ehci;
-   int err, irq, phy_num, clk = 0;
+   int err, irq, phy_num, clk = 0, rst = 0;
 
if (usb_disabled())
return -ENODEV;
@@ -232,18 +233,24 @@ static int ehci_platform_probe(struct platform_device 
*dev)
break;
}
}
-   }
 
-   priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
-   if (IS_ERR(priv->rst)) {
-   err = PTR_ERR(priv->rst);
-   if (err == -EPROBE_DEFER)
-   goto err_put_clks;
-   priv->rst = NULL;
-   } else {
-   err = reset_control_deassert(priv->rst);
-   if (err)
-   goto err_put_clks;
+   for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
+   priv->resets[rst] =
+   of_reset_control_get_by_index(dev->dev.of_node,
+ rst);
+   if (IS_ERR(priv->resets[rst])) {
+   err = PTR_ERR(priv->resets[rst]);
+   if (err == -EPROBE_DEFER)
+   goto err_reset;
+   priv->resets[rst] = NULL;
+   break;
+   }
+   err = reset_control_deassert_shared(priv->resets[rst]);
+   if (err) {
+   reset_control_put(priv->resets[rst]);
+   goto err_reset;
+   }
+   }
}
 
if (pdata->big_endian_desc)
@@ -300,8 +307,10 @@ err_power:
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
-   if (priv->rst)
-   reset_control_assert(priv->rst);
+   while (--rst >= 0) {
+   reset_control_assert_shared(priv->resets[rst]);
+   reset_control_put(priv->resets[rst]);
+   }
 err_put_clks:
while (--clk >= 0)
clk_put(priv->clks[clk]);
@@ -319,15 +328,17 @@ static int ehci_platform_remove(struct platform_device 
*dev)
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
-   int clk;
+   int clk, rst;
 
usb_remove_hcd(hcd);
 
if (pdata->power_off)
pdata->power_off(dev);
 
-   if (priv->rst)
-   reset_control_assert(priv->rst);
+   for (rst = 0; rst < EHCI_MAX_RESETS && priv->resets[rst]; rst++) {
+   reset_control_assert_shared(priv->resets[rst]);
+   reset_control_put(priv->resets[rst]);
+   }
 
for (clk = 0; clk < EHCI_MAX_CLKS && priv->clks[clk]; clk++)
clk_put(priv->clks[clk]);
-- 
2.5.0

--
To unsubscribe from this list: send the 

[PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Hans de Goede]

Add reset_control_deassert_shared / reset_control_assert_shared
functions which are intended for use by drivers for hw blocks which
(may) share a reset line with another driver / hw block.

Unlike the regular reset_control_[de]assert functions these functions
keep track of how often deassert_shared / assert_shared have been called
and keep the line deasserted as long as deassert has been called more
times than assert.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-This is a new patch in v2 of this patch-set
---
 drivers/reset/core.c | 121 ---
 include/linux/reset-controller.h |   2 +
 include/linux/reset.h|   2 +
 3 files changed, 116 insertions(+), 9 deletions(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 9ab9290..8c3436c 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -22,16 +22,29 @@ static DEFINE_MUTEX(reset_controller_list_mutex);
 static LIST_HEAD(reset_controller_list);
 
 /**
+ * struct reset_line - a reset line
+ * @list: list entry for the reset controllers reset line list
+ * @id:   ID of the reset line in the reset controller device
+ * @refcnt:   Number of reset_control structs referencing this device
+ * @deassert_cnt: Number of times this reset line has been deasserted
+ */
+struct reset_line {
+   struct list_head list;
+   unsigned int id;
+   unsigned int refcnt;
+   unsigned int deassert_cnt;
+};
+
+/**
  * struct reset_control - a reset control
  * @rcdev: a pointer to the reset controller device
  * this reset control belongs to
- * @id: ID of the reset controller in the reset
- *  controller device
+ * @line:  reset line for this reset control
  */
 struct reset_control {
struct reset_controller_dev *rcdev;
+   struct reset_line *line;
struct device *dev;
-   unsigned int id;
 };
 
 /**
@@ -66,6 +79,8 @@ int reset_controller_register(struct reset_controller_dev 
*rcdev)
rcdev->of_xlate = of_reset_simple_xlate;
}
 
+   INIT_LIST_HEAD(&rcdev->reset_line_head);
+
mutex_lock(&reset_controller_list_mutex);
list_add(&rcdev->list, &reset_controller_list);
mutex_unlock(&reset_controller_list_mutex);
@@ -93,7 +108,7 @@ EXPORT_SYMBOL_GPL(reset_controller_unregister);
 int reset_control_reset(struct reset_control *rstc)
 {
if (rstc->rcdev->ops->reset)
-   return rstc->rcdev->ops->reset(rstc->rcdev, rstc->id);
+   return rstc->rcdev->ops->reset(rstc->rcdev, rstc->line->id);
 
return -ENOTSUPP;
 }
@@ -106,7 +121,7 @@ EXPORT_SYMBOL_GPL(reset_control_reset);
 int reset_control_assert(struct reset_control *rstc)
 {
if (rstc->rcdev->ops->assert)
-   return rstc->rcdev->ops->assert(rstc->rcdev, rstc->id);
+   return rstc->rcdev->ops->assert(rstc->rcdev, rstc->line->id);
 
return -ENOTSUPP;
 }
@@ -119,13 +134,55 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
 int reset_control_deassert(struct reset_control *rstc)
 {
if (rstc->rcdev->ops->deassert)
-   return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->id);
+   return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->line->id);
 
return -ENOTSUPP;
 }
 EXPORT_SYMBOL_GPL(reset_control_deassert);
 
 /**
+ * reset_control_assert_shared - asserts a shared reset line
+ * @rstc: reset controller
+ *
+ * Assert a shared reset line, this functions decreases the deassert count
+ * of the line by one and asserts it if, and only if, the deassert count
+ * reaches 0.
+ */
+int reset_control_assert_shared(struct reset_control *rstc)
+{
+   if (!rstc->rcdev->ops->assert)
+   return -ENOTSUPP;
+
+   rstc->line->deassert_cnt--;
+   if (rstc->line->deassert_cnt)
+   return 0;
+
+   return rstc->rcdev->ops->assert(rstc->rcdev, rstc->line->id);
+}
+EXPORT_SYMBOL_GPL(reset_control_assert_shared);
+
+/**
+ * reset_control_deassert_shared - deasserts a shared reset line
+ * @rstc: reset controller
+ *
+ * Assert a shared reset line, this functions increases the deassert count
+ * of the line by one and deasserts the reset line (if it was not already
+ * deasserted).
+ */
+int reset_control_deassert_shared(struct reset_control *rstc)
+{
+   if (!rstc->rcdev->ops->deassert)
+   return -ENOTSUPP;
+
+   rstc->line->deassert_cnt++;
+   if (rstc->line->deassert_cnt != 1)
+   return 0;
+
+   return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->line->id);
+}
+EXPORT_SYMBOL_GPL(reset_control_deassert_shared);
+
+/**
  * reset_control_status - returns a negative errno if not supported, a
  * positive value if the reset line is asserted, or zero if the reset
  * line is not asserted.
@@ -134,12 +191,47 @@ EXPORT_SYMBOL_GPL(reset_control_deassert);
 int reset_control_status(struct reset_control *rstc)
 {
if (rstc->rcdev->ops->status)
-   return rstc->rcdev-

Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files

[Dinh Nguyen]

On Thu, 10 Dec 2015, Rob Herring wrote:

> Platform dts files need to be reviewed primarily by the platform
> maintainers as dts files typically go in thru their trees. Add the missing
> paths where there are existing maintainers listed.
> 
> Signed-off-by: Rob Herring 
> ---
>  MAINTAINERS | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
[...] 
> @@ -1536,6 +1549,7 @@ S:  Maintained
>  F:   arch/arm/mach-socfpga/
>  F:   arch/arm/boot/dts/socfpga*
>  F:   arch/arm/configs/socfpga_defconfig
> +F:   arch/arm64/boot/dts/altera/
>  W:   http://www.rocketboards.org
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git

Acked-by: Dinh Nguyen 

Thanks,
Dinh
--
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 0/7] mtd: partitions: add of_match_table support

[Michal Suchanek]

On 11 December 2015 at 09:44, Geert Uytterhoeven  wrote:
> Hi Brian,
>
> On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
>  wrote:
>> On Sat, Dec 05, 2015 at 11:15:54AM +0100, Geert Uytterhoeven wrote:
>>> On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>>>  wrote:
>>> > There have been several discussions [1] about adding a device tree 
>>> > binding for
>>> > associating flash devices with the partition parser(s) that are used on 
>>> > the
>>> > flash. There are a few reasons:
>>> >
>>> >  (1) drivers shouldn't have to be encoding platform knowledge by listing 
>>> > what
>>> >  parsers might be used on a given system (this is the currently all 
>>> > that's
>>> >  supported)
>>> >  (2) we can't just scan for all supported parsers (like the block system 
>>> > does), since
>>> >  there is a wide diversity of "formats" (no standardization), and it 
>>> > is not
>>> >  always safe or efficient to attempt to do so, particularly since 
>>> > many of
>>> >  them allow their data structures to be placed anywhere on the flash, 
>>> > and
>>> >  so require scanning the entire flash device to find them.
>>>
>>> I read the second reason, but would it be useful to (partially) merge
>>> block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos
>>> partitions
>>> on an mtd device??
>>
>> I kinda agree with Michal: is there a good use case?
>
> I don't have an immediate use case.
> Just looking at it from a high-level viewpoint.
>
>> Really, MTD partitioning is not a highly-scalable design. Particularly,
>> it's not typically that well-suited to large (read: unreliable) NAND
>> flash, where fixing partitions at the raw flash level mostly serves to
>> restrict UBI's ability to wear-level across the device. For that sort of
>> case, it's best if people are using UBI volumes on a (mostly?)
>> unpartitioned MTD, instead of using MTD partitions as the main
>> separation mechanism. Also, most partition designs (either MTD or block)
>> aren't very robust against bitflips, read disturb, etc.
>>
>> IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
>> and so I don't plan to do that sort of work myself. If you can provide
>> some better argument for it, and some nice maintainable code to go with
>> it, then of course it could be considered :)
>
> There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
> working on have.
>

Yes, you can dump the content of a NOR flash to a file, attach a loop
device to it, and if block devices had the ability to use flash
partitioning access the different partitions.

Maybe it would be more useful to use some kind of mtdloop, though.
There might even be one already. I never needed it.

Thanks

Michal
--
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 v4 2/2] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

[Hans de Goede]

From: Reinder de Haan 

Note this commit only adds support for phys 1-3, phy 0, the otg phy, is
not yet (fully) supported after this commit.

Signed-off-by: Reinder de Haan 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Change break; after dev_err() to return, as intended, fixing a compiler
 warning (the dev_err case should never be reached)
Changes in v3:
-Use of_match_node to get model specific config data
Changes in v4:
-Adjust to v4 of "Use of_match_node to get model specific config data" patch
---
 .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +
 drivers/phy/phy-sun4i-usb.c| 41 +-
 2 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 0cebf74..95736d7 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -9,6 +9,7 @@ Required properties:
   * allwinner,sun7i-a20-usb-phy
   * allwinner,sun8i-a23-usb-phy
   * allwinner,sun8i-a33-usb-phy
+  * allwinner,sun8i-h3-usb-phy
 - reg : a list of offset + length pairs
 - reg-names :
   * "phy_ctrl"
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 35b1fa3..bae54f7 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -47,6 +47,9 @@
 #define REG_PHYBIST0x08
 #define REG_PHYTUNE0x0c
 #define REG_PHYCTL_A33 0x10
+#define REG_PHY_UNK_H3 0x20
+
+#define REG_PMU_UNK_H3 0x10
 
 #define PHYCTL_DATABIT(7)
 
@@ -80,7 +83,7 @@
 #define PHY_DISCON_TH_SEL  0x2a
 #define PHY_SQUELCH_DETECT 0x3c
 
-#define MAX_PHYS   3
+#define MAX_PHYS   4
 
 /*
  * Note do not raise the debounce time, we must report Vusb high within 100ms
@@ -92,6 +95,7 @@
 enum sun4i_usb_phy_type {
sun4i_a10_phy,
sun8i_a33_phy,
+   sun8i_h3_phy,
 };
 
 struct sun4i_usb_phy_cfg {
@@ -239,6 +243,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
int ret;
+   u32 val;
 
ret = clk_prepare_enable(phy->clk);
if (ret)
@@ -250,16 +255,26 @@ static int sun4i_usb_phy_init(struct phy *_phy)
return ret;
}
 
-   /* Enable USB 45 Ohm resistor calibration */
-   if (phy->index == 0)
-   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
+   if (data->cfg->type == sun8i_h3_phy) {
+   if (phy->index == 0) {
+   val = readl(data->base + REG_PHY_UNK_H3);
+   writel(val & ~1, data->base + REG_PHY_UNK_H3);
+   }
+
+   val = readl(phy->pmu + REG_PMU_UNK_H3);
+   writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
+   } else {
+   /* Enable USB 45 Ohm resistor calibration */
+   if (phy->index == 0)
+   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
 
-   /* Adjust PHY's magnitude and rate */
-   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
+   /* Adjust PHY's magnitude and rate */
+   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
 
-   /* Disconnect threshold adjustment */
-   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
-   data->cfg->disc_thresh, 2);
+   /* Disconnect threshold adjustment */
+   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
+   data->cfg->disc_thresh, 2);
+   }
 
sun4i_usb_phy_passby(phy, 1);
 
@@ -726,6 +741,13 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
.dedicated_clocks = true,
 };
 
+static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
+   .num_phys = 4,
+   .type = sun8i_h3_phy,
+   .disc_thresh = 3,
+   .dedicated_clocks = true,
+};
+
 static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-usb-phy", .data = &sun4i_a10_cfg },
{ .compatible = "allwinner,sun5i-a13-usb-phy", .data = &sun5i_a13_cfg },
@@ -733,6 +755,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] = 
{
{ .compatible = "allwinner,sun7i-a20-usb-phy", .data = &sun7i_a20_cfg },
{ .compatible = "allwinner,sun8i-a23-usb-phy", .data = &sun8i_a23_cfg },
{ .compatible = "allwinner,sun8i-a33-usb-phy", .data = &sun8i_a33_cfg },
+   { .compatible = "allwinner,sun8i-h3-usb-phy", .data = &sun8i_h3_cfg },
{ },
 };
 MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
-- 
2.5.0

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

[PATCH v4 1/2] phy-sun4i-usb: Use of_match_node to get model specific config data

[Hans de Goede]

Use of_match_node instead of calling of_device_is_compatible a ton of
times to get model specific config data.

Signed-off-by: Hans de Goede 
---
Changes in v3:
-New patch in v3 of this patch-set
Changes in v4:
-Use of_device_get_match_data()
-Add phyctl_offset to sun4i_usb_phy_cfg, get rid of model specific code
 for phyctl-reg in sun4i_usb_phy_write()
---
 drivers/phy/phy-sun4i-usb.c | 121 +---
 1 file changed, 79 insertions(+), 42 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index b12964b..35b1fa3 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -88,12 +89,23 @@
 #define DEBOUNCE_TIME  msecs_to_jiffies(50)
 #define POLL_TIME  msecs_to_jiffies(250)
 
+enum sun4i_usb_phy_type {
+   sun4i_a10_phy,
+   sun8i_a33_phy,
+};
+
+struct sun4i_usb_phy_cfg {
+   int num_phys;
+   enum sun4i_usb_phy_type type;
+   u32 disc_thresh;
+   u8 phyctl_offset;
+   bool dedicated_clocks;
+};
+
 struct sun4i_usb_phy_data {
void __iomem *base;
+   const struct sun4i_usb_phy_cfg *cfg;
struct mutex mutex;
-   int num_phys;
-   u32 disc_thresh;
-   bool has_a33_phyctl;
struct sun4i_usb_phy {
struct phy *phy;
void __iomem *pmu;
@@ -159,17 +171,14 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
*phy, u32 addr, u32 data,
 {
struct sun4i_usb_phy_data *phy_data = to_sun4i_usb_phy_data(phy);
u32 temp, usbc_bit = BIT(phy->index * 2);
-   void *phyctl;
+   void *phyctl = phy_data->base + phy_data->cfg->phyctl_offset;
int i;
 
mutex_lock(&phy_data->mutex);
 
-   if (phy_data->has_a33_phyctl) {
-   phyctl = phy_data->base + REG_PHYCTL_A33;
+   if (phy_data->cfg->type == sun8i_a33_phy) {
/* A33 needs us to set phyctl to 0 explicitly */
writel(0, phyctl);
-   } else {
-   phyctl = phy_data->base + REG_PHYCTL_A10;
}
 
for (i = 0; i < len; i++) {
@@ -249,7 +258,8 @@ static int sun4i_usb_phy_init(struct phy *_phy)
sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
 
/* Disconnect threshold adjustment */
-   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 2);
+   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
+   data->cfg->disc_thresh, 2);
 
sun4i_usb_phy_passby(phy, 1);
 
@@ -476,7 +486,7 @@ static struct phy *sun4i_usb_phy_xlate(struct device *dev,
 {
struct sun4i_usb_phy_data *data = dev_get_drvdata(dev);
 
-   if (args->args[0] >= data->num_phys)
+   if (args->args[0] >= data->cfg->num_phys)
return ERR_PTR(-ENODEV);
 
return data->phys[args->args[0]].phy;
@@ -511,7 +521,6 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct phy_provider *phy_provider;
-   bool dedicated_clocks;
struct resource *res;
int i, ret;
 
@@ -522,29 +531,9 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
mutex_init(&data->mutex);
INIT_DELAYED_WORK(&data->detect, sun4i_usb_phy0_id_vbus_det_scan);
dev_set_drvdata(dev, data);
-
-   if (of_device_is_compatible(np, "allwinner,sun5i-a13-usb-phy") ||
-   of_device_is_compatible(np, "allwinner,sun8i-a23-usb-phy") ||
-   of_device_is_compatible(np, "allwinner,sun8i-a33-usb-phy"))
-   data->num_phys = 2;
-   else
-   data->num_phys = 3;
-
-   if (of_device_is_compatible(np, "allwinner,sun5i-a13-usb-phy") ||
-   of_device_is_compatible(np, "allwinner,sun7i-a20-usb-phy"))
-   data->disc_thresh = 2;
-   else
-   data->disc_thresh = 3;
-
-   if (of_device_is_compatible(np, "allwinner,sun6i-a31-usb-phy") ||
-   of_device_is_compatible(np, "allwinner,sun8i-a23-usb-phy") ||
-   of_device_is_compatible(np, "allwinner,sun8i-a33-usb-phy"))
-   dedicated_clocks = true;
-   else
-   dedicated_clocks = false;
-
-   if (of_device_is_compatible(np, "allwinner,sun8i-a33-usb-phy"))
-   data->has_a33_phyctl = true;
+   data->cfg = of_device_get_match_data(dev);
+   if (!data->cfg)
+   return -EINVAL;
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy_ctrl");
data->base = devm_ioremap_resource(dev, res);
@@ -590,7 +579,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
}
}
 
-   for (i = 0; i < data->num_phys; i++) {
+   for (i = 0; i < data->cfg->num_phys; i++) {
struct sun4i_usb_phy *phy = data->phys + i;
char name[16];

Re: [PATCH v3 3/7] ARM: hisi: add dt_machine definition for Hi3519

[Rob Herring]

On Fri, Dec 11, 2015 at 03:45:17PM +0800, Jiancheng Xue wrote:
> add dt_machine definition for hi3519.
> 
> Signed-off-by: Jiancheng Xue 
> ---
>  arch/arm/mach-hisi/hisilicon.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
> index 8cc6215..010d8a2 100644
> --- a/arch/arm/mach-hisi/hisilicon.c
> +++ b/arch/arm/mach-hisi/hisilicon.c
> @@ -81,3 +81,12 @@ static const char *const hip01_compat[] __initconst = {
>  DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
>   .dt_compat  = hip01_compat,
>  MACHINE_END
> +
> +static const char *const hi3519_compat[] __initconst = {
> + "hisilicon,hi3519",
> + NULL,
> +};

You should just have 1 mach desc with multiple compatible strings to 
match against, not 1 mach desc per compatible string.

Rob

> +
> +DT_MACHINE_START(HI3519_DT, "Hisilicon Hi3519")
> + .dt_compat  = hi3519_compat,
> +MACHINE_END
> -- 
> 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
--
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 2/7] clk: hisilicon: add dt-binding document for Hi3519 CRG

[Rob Herring]

On Fri, Dec 11, 2015 at 03:45:16PM +0800, Jiancheng Xue wrote:
> add dt-binding document for Hi3519 CRG block
> 
> Signed-off-by: Jiancheng Xue 
> ---
>  .../devicetree/bindings/clock/hi3519-crg.txt   | 46 
> ++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt 
> b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
> new file mode 100644
> index 000..e0d30a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
> @@ -0,0 +1,46 @@
> +* Hisilicon Hi3519 Clock and Reset Generator(CRG)
> +
> +The Hi3519 CRG module provides clock and reset signals to various
> +controllers within the SoC.
> +
> +This binding uses the following bindings:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +Documentation/devicetree/bindings/reset/reset.txt
> +
> +Required Properties:
> +
> +- compatible: should be one of the following.
> +  - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
> +
> +- reg: physical base address of the controller and length of memory mapped
> +  region.
> +
> +- #clock-cells: should be 1.
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +
> +All these identifier could be found in .

This header should be part of this patch.

> +
> +- #reset-cells: should be 2.
> +
> +A reset signal can be controlled by writing a bit register in the CRG module.
> +The reset specifier consists of two cells. The first cell represents the
> +register offset relative to the base address. The second cell represents the
> +bit index in the register.
> +
> +Example: CRG nodes
> +CRG: clock-reset-controller {

clock-reset-controller@1201

> + compatible = "hisilicon,hi3519-crg";
> +reg = <0x1201 0x1>;
> +#clock-cells = <1>;
> +#reset-cells = <2>;
> +};
> +
> +Example: consumer nodes
> +i2c0: i2c@0x1211 {

Drop '0x'

> + compatible = "hisilicon,hi3519-i2c";
> +reg = <0x1211 0x1000>;
> +clocks = <&CRG HI3519_I2C0_RST>;*/
> +resets = <&CRG 0xE4 0>;

lowercase hex please

> +};
> -- 
> 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 v5 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Rob Herring]

On Fri, Dec 11, 2015 at 09:39:59AM +0530, Vignesh R wrote:
> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> update the binding documents for the controller to document this change.
> 
> Signed-off-by: Vignesh R 

Acked-by: Rob Herring 

> ---
> 
> v5: use syscon to access scm register.
> 
>  Documentation/devicetree/bindings/spi/ti_qspi.txt | 17 +
>  arch/arm/boot/dts/dra7.dtsi   |  6 --
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> index 601a360531a5..809c3f334316 100644
> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> @@ -15,6 +15,10 @@ Recommended properties:
>  - spi-max-frequency: Definition as per
>   Documentation/devicetree/bindings/spi/spi-bus.txt
>  
> +Optional properties:
> +- syscon-chipselects: Handle to system control region contains QSPI
> +   chipselect register and offset of that register.
> +
>  Example:
>  
>  qspi: qspi@4b30 {
> @@ -26,3 +30,16 @@ qspi: qspi@4b30 {
>   spi-max-frequency = <2500>;
>   ti,hwmods = "qspi";
>  };
> +
> +For dra7xx:
> +qspi: qspi@4b30 {
> + compatible = "ti,dra7xxx-qspi";
> + reg = <0x4b30 0x100>,
> +   <0x5c00 0x400>,
> + reg-names = "qspi_base", "qspi_mmap";
> + syscon-chipselects = <&scm_conf 0x558>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + spi-max-frequency = <4800>;
> + ti,hwmods = "qspi";
> +};
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index fe99231cbde5..be91c7781c07 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1153,8 +1153,10 @@
>  
>   qspi: qspi@4b30 {
>   compatible = "ti,dra7xxx-qspi";
> - reg = <0x4b30 0x100>;
> - reg-names = "qspi_base";
> + reg = <0x4b30 0x100>,
> +   <0x5c00 0x400>;
> + reg-names = "qspi_base", "qspi_mmap";
> + syscon-chipselects = <&scm_conf 0x558>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>   ti,hwmods = "qspi";
> -- 
> 2.6.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 2/4] drm: Add support for ARM's HDLCD controller.

[Liviu Dudau]

The HDLCD controller is a display controller that supports resolutions
up to 4096x4096 pixels. It is present on various development boards
produced by ARM Ltd and emulated by the latest Fast Models from the
company.

Cc: David Airlie 
Cc: Robin Murphy 

Signed-off-by: Liviu Dudau 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/arm/Kconfig  |  29 ++
 drivers/gpu/drm/arm/Makefile |   2 +
 drivers/gpu/drm/arm/hdlcd_crtc.c | 327 ++
 drivers/gpu/drm/arm/hdlcd_drv.c  | 579 +++
 drivers/gpu/drm/arm/hdlcd_drv.h  |  42 +++
 drivers/gpu/drm/arm/hdlcd_regs.h |  87 ++
 8 files changed, 1069 insertions(+)
 create mode 100644 drivers/gpu/drm/arm/Kconfig
 create mode 100644 drivers/gpu/drm/arm/Makefile
 create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c
 create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c
 create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h
 create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4bf9a1..3fd9124 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -106,6 +106,8 @@ config DRM_TDFX
  Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
  graphics card.  If M is selected, the module will be called tdfx.
 
+source "drivers/gpu/drm/arm/Kconfig"
+
 config DRM_R128
tristate "ATI Rage 128"
depends on DRM && PCI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1e9ff4c..6b42d75 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -35,6 +35,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
 
 obj-$(CONFIG_DRM)  += drm.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
+obj-$(CONFIG_DRM_ARM)  += arm/
 obj-$(CONFIG_DRM_TTM)  += ttm/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
 obj-$(CONFIG_DRM_R128) += r128/
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
new file mode 100644
index 000..5e8c8a8
--- /dev/null
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -0,0 +1,29 @@
+config DRM_ARM
+   bool "ARM Ltd. drivers"
+   depends on DRM && OF && (ARM || ARM64)
+   select DRM_KMS_HELPER
+   help
+ Choose this option to select drivers for ARM's devices
+
+config DRM_HDLCD
+   tristate "ARM HDLCD"
+   depends on DRM_ARM
+   depends on COMMON_CLK
+   select COMMON_CLK_SCPI
+   select DMA_CMA
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   help
+ Choose this option if you have an ARM High Definition Colour LCD
+ controller.
+
+ If M is selected the module will be called hdlcd.
+
+config DRM_HDLCD_SHOW_UNDERRUN
+   bool "Show underrun conditions"
+   depends on DRM_HDLCD
+   default n
+   help
+ Enable this option to show in red colour the pixels that the
+ HDLCD device did not fetch from framebuffer due to underrun
+ conditions.
diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
new file mode 100644
index 000..89dcb7b
--- /dev/null
+++ b/drivers/gpu/drm/arm/Makefile
@@ -0,0 +1,2 @@
+hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
+obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
new file mode 100644
index 000..979b35d
--- /dev/null
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) 2013-2015 ARM Limited
+ * Author: Liviu Dudau 
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ *  Implementation of a CRTC class for the HDLCD driver.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hdlcd_drv.h"
+#include "hdlcd_regs.h"
+
+/*
+ * The HDLCD controller is a dumb RGB streamer that gets connected to
+ * a single HDMI transmitter or in the case of the ARM Models it gets
+ * emulated by the software that does the actual rendering.
+ *
+ */
+
+static const struct drm_crtc_funcs hdlcd_crtc_funcs = {
+   .destroy = drm_crtc_cleanup,
+   .set_config = drm_atomic_helper_set_config,
+   .page_flip = drm_atomic_helper_page_flip,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static struct simplefb_format supported_formats[] = SIMPLEFB_FORMATS;
+
+/*
+ * Setup the HDLCD registers for decoding the pixels out of the framebuffer
+ */
+static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
+{
+   unsigned int btpp;
+   struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
+   uint32_t pixel_format;
+   struct simplefb_format *format = NULL;
+ 

[PATCH v6 3/4] arm64: Juno: Add HDLCD support to the Juno boards.

[Liviu Dudau]

ARM's Juno board has two HDLCD controllers, each linked to an NXP
TDA19988 HDMI transmitter that provides output encoding. Add them
to the device tree.

Signed-off-by: Liviu Dudau 
Acked-by: Sudeep Holla 
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 46 +++---
 1 file changed, 42 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi 
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index dd5158e..8ee094a 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -92,8 +92,8 @@
scpi_clk: scpi_clocks@3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
-   clock-indices = <3>, <4>;
-   clock-output-names = "pxlclk0", "pxlclk1";
+   clock-indices = <3>;
+   clock-output-names = "pxlclk";
};
};
 
@@ -123,6 +123,34 @@
clock-names = "apb_pclk";
};
 
+   hdlcd@7ff5 {
+   compatible = "arm,hdlcd";
+   reg = <0 0x7ff5 0 0x1000>;
+   interrupts = ;
+   clocks = <&scpi_clk 3>;
+   clock-names = "pxlclk";
+
+   port {
+   hdlcd1_output: endpoint@0 {
+   remote-endpoint = <&tda998x_1_input>;
+   };
+   };
+   };
+
+   hdlcd@7ff6 {
+   compatible = "arm,hdlcd";
+   reg = <0 0x7ff6 0 0x1000>;
+   interrupts = ;
+   clocks = <&scpi_clk 3>;
+   clock-names = "pxlclk";
+
+   port {
+   hdlcd0_output: endpoint@0 {
+   remote-endpoint = <&tda998x_0_input>;
+   };
+   };
+   };
+
soc_uart0: uart@7ff8 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x0 0x7ff8 0x0 0x1000>;
@@ -141,14 +169,24 @@
i2c-sda-hold-time-ns = <500>;
clocks = <&soc_smc50mhz>;
 
-   dvi0: dvi-transmitter@70 {
+   hdmi-transmitter@70 {
compatible = "nxp,tda998x";
reg = <0x70>;
+   port {
+   tda998x_0_input: endpoint@0 {
+   remote-endpoint = <&hdlcd0_output>;
+   };
+   };
};
 
-   dvi1: dvi-transmitter@71 {
+   hdmi-transmitter@71 {
compatible = "nxp,tda998x";
reg = <0x71>;
+   port {
+   tda998x_1_input: endpoint@0 {
+   remote-endpoint = <&hdlcd1_output>;
+   };
+   };
};
};
 
-- 
2.6.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 v6 4/4] MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver.

[Liviu Dudau]

Update MAINTAINERS file for HDLCD driver.

Cc: Greg KH 
Cc: Andrew Morton 
Cc: Mauro Carvalho Chehab 
Cc: David S. Miller 

Signed-off-by: Liviu Dudau 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cba790b..4208dae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -820,6 +820,12 @@ S: Maintained
 F: drivers/net/arcnet/
 F: include/uapi/linux/if_arcnet.h
 
+ARM HDLCD DRM DRIVER
+M: Liviu Dudau 
+S: Supported
+F: drivers/gpu/drm/arm/
+F: Documentation/devicetree/bindings/display/arm,hdlcd.txt
+
 ARM MFM AND FLOPPY DRIVERS
 M: Ian Molton 
 S: Maintained
-- 
2.6.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 v6 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.

[Liviu Dudau]

Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 

Signed-off-by: Liviu Dudau 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/arm,hdlcd.txt  | 79 ++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt

diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.txt 
b/Documentation/devicetree/bindings/display/arm,hdlcd.txt
new file mode 100644
index 000..78bc242
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,hdlcd.txt
@@ -0,0 +1,79 @@
+ARM HDLCD
+
+This is a display controller found on several development platforms produced
+by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB
+streamer that reads the data from a framebuffer and sends it to a single
+digital encoder (DVI or HDMI).
+
+Required properties:
+  - compatible: "arm,hdlcd"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: One interrupt used by the display controller to notify the
+interrupt controller when any of the interrupt sources programmed in
+the interrupt mask register have activated.
+  - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+  - clock-names: A list of clock names. For HDLCD it should contain:
+  - "pxlclk" for the clock feeding the output PLL of the controller.
+
+Required sub-nodes:
+  - port: The HDLCD connection to an encoder chip. The connection is modeled
+using the OF graph bindings specified in
+Documentation/devicetree/bindings/graph.txt.
+
+Optional properties:
+  - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to 
be
+used for the framebuffer; if not present, the framebuffer may be located
+anywhere in memory.
+
+
+Example:
+
+/ {
+   ...
+
+   hdlcd@2b00 {
+   compatible = "arm,hdlcd";
+   reg = <0 0x2b00 0 0x1000>;
+   interrupts = ;
+   clocks = <&oscclk5>;
+   clock-names = "pxlclk";
+   port {
+   hdlcd_output: endpoint@0 {
+   remote-endpoint = <&hdmi_enc_input>;
+   };
+   };
+   };
+
+   /* HDMI encoder on I2C bus */
+   i2c@7ffa {
+   
+   hdmi-transmitter@70 {
+   compatible = ".";
+   reg = <0x70>;
+   port@0 {
+   hdmi_enc_input: endpoint {
+   remote-endpoint = <&hdlcd_output>;
+   };
+
+   hdmi_enc_output: endpoint {
+   remote-endpoint = <&hdmi_1_port>;
+   };
+   };
+   };
+
+   };
+
+   hdmi1: connector@1 {
+   compatible = "hdmi-connector";
+   type = "a";
+   port {
+   hdmi_1_port: endpoint {
+   remote-endpoint = <&hdmi_enc_output>;
+   };
+   };
+   };
+
+   ...
+};
-- 
2.6.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 v6 0/4] drm: Add support for the ARM HDLCD display controller

[Liviu Dudau]

This series adds support for ARM's HDLCD display controller found in Juno
and ARM TC2 Coretile. The HDLCD outputs an RGB stream that feeds into a
single digital encoder (DVI or HDMI).

Most of the dependencies for this patch series are now queued for the next
release or are already in the mainline. The one dependency that I'm not sure
about its future is Thierry Reding's cleanup of the connector->encoder being
set in the drivers [1]. It is not blocking the HDLCD functionality but avoids
having an ugly WARNING splat at boot time.

Only the Juno functionality has been tested as the TC2 Coretile require
a working SiI9022 driver for VExpress that is not subject of this patchset.

I think I have addressed most of the comments and I would like to add the series
to some queue for v4.5. David Airlie's tree feels the most appropriate, even
if only 1 patch touches drivers/gpu/drm, but I'm open to suggestions.

Changelog:
v6: Addressed the style nits pointed by Robin Murphy and fixed the use of
default color to highlight underrun errors. Also modified MAINTAINERS file
to change the status to Supported for HDLCD.
v5: Queue the pending vblank events sent by userspace using a list instead of
keeping the last event seen. Suggested by Daniel Stone 
. [2]
v4: Remove some debugging code that could return an error on a critical path
and updated the check for valid format in hdlcd_set_pxl_fmt() to only
WARN() if an invalid format found (unlikely case). Added the ACKs received. 
[3]
v3: Changed the driver to use the memory-region phandle for bespoke 
framebuffers. [4]
v2: Added support for atomic modeset [5]
v1: Original DRM submission [6]

[1] http://lists.freedesktop.org/archives/dri-devel/2015-November/094576.html
[2] http://lists.freedesktop.org/archives/dri-devel/2015-December/096432.html
[3] http://lists.freedesktop.org/archives/dri-devel/2015-December/095990.html
[4] http://lists.freedesktop.org/archives/dri-devel/2015-December/095877.html
[5] http://lists.freedesktop.org/archives/dri-devel/2015-November/094177.html
[6] http://lists.freedesktop.org/archives/dri-devel/2015-August/087685.html

Best regards,
Liviu

Liviu Dudau (4):
  drm: arm: Add DT bindings documentation for HDLCD driver.
  drm: Add support for ARM's HDLCD controller.
  arm64: Juno: Add HDLCD support to the Juno boards.
  MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver.

 .../devicetree/bindings/display/arm,hdlcd.txt  |  79 +++
 MAINTAINERS|   6 +
 arch/arm64/boot/dts/arm/juno-base.dtsi |  46 +-
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/arm/Kconfig|  29 ++
 drivers/gpu/drm/arm/Makefile   |   2 +
 drivers/gpu/drm/arm/hdlcd_crtc.c   | 327 
 drivers/gpu/drm/arm/hdlcd_drv.c| 579 +
 drivers/gpu/drm/arm/hdlcd_drv.h|  42 ++
 drivers/gpu/drm/arm/hdlcd_regs.h   |  87 
 11 files changed, 1196 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt
 create mode 100644 drivers/gpu/drm/arm/Kconfig
 create mode 100644 drivers/gpu/drm/arm/Makefile
 create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c
 create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c
 create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h
 create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h

-- 
2.6.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 v14 1/7] fpga: add usage documentation for fpga area

[Rob Herring]

On Thu, Dec 10, 2015 at 05:37:03PM -0600, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> Add a document spelling out usage of the FPGA Area for
> reprogramming FPGA's under Device Tree control.
 
I'm not too sure about the split between this and the binding doc. This 
one clears up a bit after reading the binding doc first and most of this 
is about DT.

> Signed-off-by: Alan Tull 
> 
> ---
> v9:  Initial version of this patch in patchset
> v10: s/fpga/FPGA/g
>  improve formatting
>  some rewriting
>  move to staging/simple-fpga-bus
> v11: No change in this patch for v11 of the patch set
> v12: Moved out of staging
>  Small changes due to using FPGA bridge framework and not
>  representing the bridges as resets.
> v13: Fix some nits
> v14: fpga-area instead of simple-fpga-bus
> ---
>  Documentation/fpga/fpga-area.txt |  299 
> ++
>  1 file changed, 299 insertions(+)
>  create mode 100644 Documentation/fpga/fpga-area.txt
> 
> diff --git a/Documentation/fpga/fpga-area.txt 
> b/Documentation/fpga/fpga-area.txt
> new file mode 100644
> index 000..f031522
> --- /dev/null
> +++ b/Documentation/fpga/fpga-area.txt
> @@ -0,0 +1,299 @@
> +FPGA Area
> +
> +Alan Tull 2015
> +
> +Overview
> +
> +
> +An FPGA Area details information about a section of an FPGA including the 
> FPGA
> +image needed to program it and the hardware contained once it is programmed.
> +
> +Loading a Device Tree overlay which contains an FPGA Area will cause the
> +FPGA to be programmed and the children of the FPGA Area will get probed.
> +
> +There may be FPGA Bridges involved to prevent spurious data from going out 
> onto
> +the processor bus during FPGA programming.  If so, the FPGA Area will need to
> +disable and enable bridges that will only affect the child devices that are
> +below the FPGA Area.  In the case of partial reconfiguration, bridges will
> +be required within the FPGA design such that the active sections of the
> +FPGA are on the bus while sections that are not programmed or being
> +reprogrammed at the moment are isolated.
> +
> +Removing the overlay will result in the child devices getting removed and the
> +bridges disabled.  Note that in the case of partial reconfiguration the rest 
> of
> +the FPGA continues to function as normal while this is happening.
> +
> +Below are more details on the structuring of the Device Tree for this.
> +
> +Terminology
> +===
> +
> +Full Reconfiguration
> + * The entire FPGA is reprogrammed.
> +
> +Partial Reconfiguration (PR)
> + * Part of the FPGA is reprogrammed while the rest of the FPGA is live and
> +   active.  Not all FPGA's support this.
> +
> +Associated Blocks
> +=
> +
> +FPGA Manager Framework
> + * An FPGA Manager is a hardware block that programs an FPGA under the 
> control
> +   of a host processor.
> + * The FPGA Manager Framework provides drivers and functions to program an
> +   FPGA.
> +
> +FPGA Bridge Framework
> + * Provides drivers and functions to control bridges that enable/disable
> +   data to the FPGA.
> + * FPGA bridges should be disabled while the FPGA is being programmed to
> +   prevent spurious data on the bus.
> + * FPGA bridges are not needed in implementations where the FPGA Manager
> +   handles this.
> +
> +Device Tree
> +===
> +
> +For the purposes of this document, I'm dividing the Device Tree (DT) into 
> two parts,
> +each with its own requirements.  The two parts are:
> + * The live DT prior to the overlay being added
> + * The overlay containing an FPGA Area
> +
> +The live DT will contain:
> + * FPGA Manager
> + * FPGA Bridges as children of the FPGA Manager (optional, architecture 
> specific)
> +
> +The live Device Tree must contain an FPGA Manager to handle programming the 
> FPGA.
> +If FPGA Bridges need to be involved, they show up in the DT as direct 
> children
> +of the FPGA Manager.  During full reconfiguration, the FPGA Area will disable
> +any bridges that are direct children of the manager during full 
> reconfiguration
> +and will re-enable them afterwards.
> +
> +The insertion point in the live tree will also need the "simple-bus"
> +compatibility string to enable populating the child nodes for the overlay.
> +That includes the nodes for the FPGA Manager and controlling FPGA Bridges
> +as explained below.
> +
> +The Device Tree Overlay will contain:
> + * "target-path"
> +   The insertion point where the the contents of the overlay will go into the
> +   live tree.
> + * "ranges"
> + * "firmware-name"
> +   Specifies the name of the FPGA image file on the firmware search
> +   path.  The search path is described in the firmware class documentation.
> + * "partial-reconfig"
> +   This binding is a boolean and should be present if partial reconfiguration
> +   is to be done.
> + * child nodes corresponding to hardware that will be loaded in this
> +   region of the FPGA.
> +
> +Supported use models
> +

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> > > Hi,
> > > 
> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> > > provide a complete set of compatibility strings for known Gen2 SoCs.
> > > 
> > > Key Changes in v2:
> > > * Include "rcar-" in generic bindings
> > > 
> > > Simon Horman (4):
> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
> > >   PCI: rcar-gen2: add device tree support for r8a7793
> > >   PCI: rcar: add gen2 fallback compatibility string
> > >   PCI: rcar: add device tree support for r8a7793
> > > 
> > >  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 12 ++--
> > >  Documentation/devicetree/bindings/pci/rcar-pci.txt  | 14 
> > > +++---
> > >  drivers/pci/host/pci-rcar-gen2.c|  1 +
> > >  drivers/pci/host/pcie-rcar.c|  1 +
> > >  4 files changed, 23 insertions(+), 5 deletions(-)
> > 
> > I applied these:
> > 
> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
> > >   PCI: rcar: add gen2 fallback compatibility string
> > 
> > to pci/host-rcar for v4.5, thanks!
> > 
> > I haven't applied the R8A7793 binding documentation updates yet, but
> > I'll be happy to do so given a short description of why they're
> > useful (since they don't update a DT or the driver).  Or they could be
> > merged via a DT tree.
> 
> To clarify: you would like a description in the changelog?

Yes, please.  The email discussion so far hasn't contained what I'm
looking for (if it had, I would have just inserted it and been done
with it).

Apparently it has to do with the stable DT rules, which I don't know.
A concrete example would probably help clear it up.

I've applied the parts that touch PCI.  I won't be offended if the
binding documentation patches go as-is via another tree.  It's just
that if *I'm* going to apply them, I'd like to understand better what
the benefit is.

Bjorn
--
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 5/5] mtd: atmel-quadspi: add driver for Atmel QSPI controller

[Nicolas Ferre]

Le 07/12/2015 15:09, Cyrille Pitchen a écrit :
> This driver add support to the new Atmel QSPI controller embedded into
> sama5d2x SoCs. It expects a NOR memory to be connected to the QSPI
> controller.
> 
> Signed-off-by: Cyrille Pitchen 

Brian,

This driver has been maturing for months and my only goal is to keep on
supporting it.
As I already gave my Ack this summer, here is it now for sure:

Acked-by: Nicolas Ferre 

I recall that Marek gave his as well and might also agree with the
changes and re-iterate his support.

Together with the current work of Cyrille on the spi-nor Quad SPI
support ("[PATCH linux-next 0/4] mtd: spi-nor: fix Quad SPI memory
support"), I have the feeling that this driver deserves an inclusion in
linux-next.
The infrastructure put in place and then used by this driver will
certainly help other developers to build their driver on top. I had the
impression that at least Marek was considering to use this for his
Cadence driver:

His quote from mid-September:
"
Are there any news on this patch series? I'd like to use that for my own
QSPI driver (the Cadence one), so I'd like to check on the status. Are you
still working on this please ?
"

Can we find a way to give this work even more exposure and consider at
least the spi-nor and m25p80 parts mentioned just above for mainline
inclusion?

Best regards,

> ---
>  drivers/mtd/spi-nor/Kconfig |   8 +
>  drivers/mtd/spi-nor/Makefile|   3 +-
>  drivers/mtd/spi-nor/atmel-quadspi.c | 877 
> 
>  3 files changed, 887 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 0dc927540b3d..15f45dbbfe0d 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -37,6 +37,14 @@ config SPI_FSL_QUADSPI
> This controller does not support generic SPI. It only supports
> SPI NOR.
>  
> +config SPI_ATMEL_QUADSPI
> + tristate "Atmel Quad SPI Controller"
> + depends on OF && HAS_DMA && (ARCH_AT91 || COMPILE_TEST)
> + help
> +   This enables support for the Quad SPI controller in master mode.
> +   This driver does not support generic SPI. The implementation only
> +   supports SPI NOR.
> +
>  config SPI_NXP_SPIFI
>   tristate "NXP SPI Flash Interface (SPIFI)"
>   depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 0bf3a7f81675..0cbed0e4ae8c 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o
>  obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
> -obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
> +obj-$(CONFIG_MTD_MT81xx_NOR) += mtk-quadspi.o
> +obj-$(CONFIG_SPI_ATMEL_QUADSPI)  += atmel-quadspi.o
>  obj-$(CONFIG_SPI_NXP_SPIFI)  += nxp-spifi.o
> diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c 
> b/drivers/mtd/spi-nor/atmel-quadspi.c
> new file mode 100644
> index ..bdebfdc92842
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/atmel-quadspi.c
> @@ -0,0 +1,877 @@
> +/*
> + * Driver for Atmel QSPI Controller
> + *
> + * Copyright (C) 2015 Atmel Corporation
> + *
> + * Author: Cyrille Pitchen 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + *
> + * This driver is based on drivers/mtd/spi-nor/fsl-quadspi.c from Freescale.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/* QSPI register offsets */
> +#define QSPI_CR  0x  /* Control Register */
> +#define QSPI_MR  0x0004  /* Mode Register */
> +#define QSPI_RD  0x0008  /* Receive Data Register */
> +#define QSPI_TD  0x000c  /* Transmit Data Register */
> +#define QSPI_SR  0x0010  /* Status Register */
> +#define QSPI_IER 0x0014  /* Interrupt Enable Register */
> +#define QSPI_IDR 0x0018  /* Interrupt Disable Register */
> +#define QSPI_IMR 0x001c  /* Interrupt Mask Register */
> +#define QSPI_SCR 0x0020  /* Serial Clock Register */
> +
> +#define QSPI_IAR 0x0030  /* Instruction Address Register */
> +#define QSPI_ICR 0x0034  /* Instruction Code Register */
> +#define QSPI

Re: [PATCH v3] ARM: dts: ls1021a: add sata node to dts

[Shawn Guo]

On Wed, Dec 02, 2015 at 03:16:31PM +0800, yuantian.t...@freescale.com wrote:
> From: Tang Yuantian 
> 
> Added sata node to ls1021aqds and ls1021atwr board to support
> sata function.
> 
> Signed-off-by: Tang Yuantian 
> ---
> v3:
>   - refine the title and commit message
>   - added a status property so that sata can be controlled
>   by board specific dts.
> v2:
>   - put reg-names right after reg property
> 
>  arch/arm/boot/dts/ls1021a-qds.dts |  4 
>  arch/arm/boot/dts/ls1021a-twr.dts |  4 
>  arch/arm/boot/dts/ls1021a.dtsi| 11 +++
>  3 files changed, 19 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a-qds.dts 
> b/arch/arm/boot/dts/ls1021a-qds.dts
> index 0521e68..803cc54 100644
> --- a/arch/arm/boot/dts/ls1021a-qds.dts
> +++ b/arch/arm/boot/dts/ls1021a-qds.dts
> @@ -327,3 +327,7 @@
>  &uart1 {
>   status = "okay";
>  };
> +
> +&sata {
> + status = "okay";
> +};

The labelled nodes are sorted alphabetically.  Please keep the new
addition sorted too.

> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
> b/arch/arm/boot/dts/ls1021a-twr.dts
> index fbb89d1..62dec7c 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -219,3 +219,7 @@
>  &uart1 {
>   status = "okay";
>  };
> +
> +&sata {
> + status = "okay";
> +};

Ditto

Shawn

> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 9430a99..da9bd7e 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -143,6 +143,17 @@
>   status = "disabled";
>   };
>  
> + sata: sata@320 {
> + compatible = "fsl,ls1021a-ahci";
> + reg = <0x0 0x320 0x0 0x1>,
> +   <0x0 0x20220520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = <&platform_clk 1>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
>   scfg: scfg@157 {
>   compatible = "fsl,ls1021a-scfg", "syscon";
>   reg = <0x0 0x157 0x0 0x1>;
> -- 
> 2.1.0.27.g96db324
> 
> 
--
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 v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

On Fri, Dec 11, 2015 at 7:23 PM, Mark Rutland  wrote:
> Hi,
>
> On Tue, Nov 17, 2015 at 10:50:41PM +0530, Ganapatrao Kulkarni wrote:
>> DT bindings for numa mapping of memory, cores and IOs.
>>
>> Reviewed-by: Robert Richter 
>> Signed-off-by: Ganapatrao Kulkarni 
>
> Overall this looks good to me. However, I have a couple of concerns.
thanks.
>
>> ---
>>  Documentation/devicetree/bindings/arm/numa.txt | 272 
>> +
>>  1 file changed, 272 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/numa.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/numa.txt 
>> b/Documentation/devicetree/bindings/arm/numa.txt
>> new file mode 100644
>> index 000..b87bf4f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/numa.txt
>> @@ -0,0 +1,272 @@
>> +==
>> +NUMA binding description.
>> +==
>> +
>> +==
>> +1 - Introduction
>> +==
>> +
>> +Systems employing a Non Uniform Memory Access (NUMA) architecture contain
>> +collections of hardware resources including processors, memory, and I/O 
>> buses,
>> +that comprise what is commonly known as a NUMA node.
>> +Processor accesses to memory within the local NUMA node is generally faster
>> +than processor accesses to memory outside of the local NUMA node.
>> +DT defines interfaces that allow the platform to convey NUMA node
>> +topology information to OS.
>> +
>> +==
>> +2 - numa-node-id
>> +==
>> +The device node property numa-node-id describes numa domains within a
>> +machine. This property can be used in device nodes like cpu, memory, bus and
>> +devices to map to respective numa nodes.
>> +
>> +numa-node-id property is a 32-bit integer which defines numa node id to 
>> which
>> +this device node has numa domain association.
>
> I'd prefer if the above two paragraphs were replaced with:
>
> For the purpose of identification, each NUMA node is associated
> with a unique token known as a node id. For the purpose of this
> binding a node id is a 32-bit integer.
>
> A device node is associated with a NUMA node by the presence of
> a numa-node-id property which contains the node id of the
> device.
ok, will do.
>
>> +
>> +Example:
>> + /* numa node 0 */
>> + numa-node-id = <0>;
>> +
>> + /* numa node 1 */
>> + numa-node-id = <1>;
>> +
>> +==
>> +3 - distance-map
>> +==
>> +
>> +The device tree node distance-map describes the relative
>> +distance (memory latency) between all numa nodes.
>
> Is this not a combined approximation for latency and bandwidth?
AFAIK, it is to represent inter-node memory access latency.
>
>> +- compatible : Should at least contain "numa,distance-map-v1".
>
> Please use "numa-distance-map-v1", as "numa" is not a vendor.
ok
>
>> +- distance-matrix
>> +  This property defines a matrix to describe the relative distances
>> +  between all numa nodes.
>> +  It is represented as a list of node pairs and their relative distance.
>> +
>> +  Note:
>> + 1. Each entry represents distance from first node to second node.
>> + 2. If both directions between 2 nodes have the same distance, only
>> +one entry is required.
>
> I still don't understand what direction means in this context. Are there
> systems (of any architecture) which don't have symmetric distances?
> Which accesses does this apply differently to?
>
> Given that, I think that it might be best to explicitly call out
> distances as being equal, and leave any directionality for a later
> revision of the binding when we have some semantics for directionality.
agreed, given that there is no know system to substantiate dual direction,
let us not explicit about direction.
>
>> + 2. distance-matrix shold have entries in lexicographical ascending 
>> order of nodes.
>> + 3. There must be only one Device node distance-map and must reside in 
>> the root node.
>> +
>> +Example:
>> + 4 nodes connected in mesh/ring topology as below,
>> +
>> + 0___20__1
>> + |   |
>> + |   |
>> +   20|   |20
>> + |   |
>> + |   |
>> + |___|
>> + 3   20  2
>> +
>> + if relative distance for each hop is 20,
>> + then inter node distance would be for this topology will be,
>> +   0 ->

Re: [PATCH] extcon-usb-gpio: add enable pin support

[Sergei Shtylyov]

Hello.

On 12/11/2015 07:05 AM, Chanwoo Choi wrote:


Sometimes  there's a real  OTG chip behind the USB ID signal mapped to a GPIO
pin: in my case it's Maxim Integrated MAX3355E which  integrates Vbus charge
pump and comparators and passes  thru the ID  signal  from an OTG connector.


s/thru/through ?


   "Thru" is valid English.


This chip also has the SHDN# pin which  should be  driven high for the normal
operation  and low to  save power;  it  is connected to a GPIO pin as well on,
hence  we'll have  to  teach the driver to parse the new optional device tree
property, "enable-gpio"...



This patch description includes the double space between words. Also, I think


   So what?


you need to write the patch description again for formal style.


   Not sure I understand you.


This patch adds the specific 'enable-gpio' pin to express the SHDN#pin for 
MAX3355E.
I think it is not regular and standard case because maybe USB specification
don't include the SHDN#pin information.


   Certainly, it's not a USB pin.


I think it not appropriate way.
Instead, you better to make the MAX3355 extcon driver to support this case.


   OK, just didn't want to duplicate most of this driver there...


Thanks,
Chanwoo


MBR, Sergei

--
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] MAINTAINERS: Add missing platform maintainers for dts files

[Arnd Bergmann]

On Thursday 10 December 2015 17:38:23 Rob Herring wrote:
> Platform dts files need to be reviewed primarily by the platform
> maintainers as dts files typically go in thru their trees. Add the missing
> paths where there are existing maintainers listed.
> 
> Signed-off-by: Rob Herring 
> 

Acked-by: Arnd Bergmann 

Do you want to collect the Acks and take this through your git tree, so should
we pick it up into arm-soc?

Arnd
--
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] arm64: dts: Fix typo in rk3368 card detect binding

[Heiko Stübner]

Hi Matthias,

Am Freitag, 11. Dezember 2015, 14:22:19 schrieb Matthias Brugger:
> The card detect pin is called sdmcc-cd.
> This patch fixes the typo and renames the pin to sdmmc-cd.
> 
> Signed-off-by: Matthias Brugger 

applied to my arm64 dts branch, after fixing up the subject.


Thanks
Heiko
--
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 v14 2/7] fpga: add bindings document for fpga area

[Rob Herring]

On Thu, Dec 10, 2015 at 05:37:04PM -0600, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> New bindings document for FPGA Area for reprogramming
> FPGA's under Device Tree control
> 
> Signed-off-by: Alan Tull 
> ---
> v9:  initial version added to this patchset
> v10: s/fpga/FPGA/g
>  replace DT overlay example with slightly more complicated example
>  move to staging/simple-fpga-bus
> v11: No change in this patch for v11 of the patch set
> v12: Moved out of staging.
>  Changed to use FPGA bridges framework instead of resets
>  for bridges.
> v13: bridge@0xff2 -> bridge@ff20, etc
>  Leave out directly talking about overlays
>  Remove regs and clocks directly under simple-fpga-bus in example
>  Use common "firmware-name" binding instead of "fpga-firmware"
> v14: Use firmware-name in bindings description
>  Call it FPGA Area
>  Remove bindings that specify FPGA Manager and FPGA Bridges
> ---
>  .../devicetree/bindings/fpga/fpga-area.txt |   70 
> 
>  1 file changed, 70 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/fpga-area.txt
> 
> diff --git a/Documentation/devicetree/bindings/fpga/fpga-area.txt 
> b/Documentation/devicetree/bindings/fpga/fpga-area.txt
> new file mode 100644
> index 000..d656e35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/fpga-area.txt
> @@ -0,0 +1,70 @@
> +FPGA Area
> +=
> +
> +A FPGA Area details information about a section of an FPGA including the FPGA
> +image needed to program it and the hardware contained in this section of the
> +FPGA once it is programmed.
> +
> +A FPGA Area corresponds to the whole FPGA in the case of full reconfiguration
> +or a section of a FPGA in the case of partial reconfiguration.
> +
> +Required properties:
> +- compatible : should contain "fpga-area"

I'm not too sure about this. I think this needs to be FPGA specfic.

> +- #address-cells, #size-cells, ranges: must be present to handle address 
> space
> +  mapping for children.
> +
> +Optional properties:
> +- firmware-name : should contain the name of a FPGA image file located on the
> +  firmware search path.
> +- partial-reconfig : boolean property should be defined if partial
> +  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
> +  is done.
> +
> +Example:
> +
> +/dts-v1/;
> +/plugin/;
> +/ {
> + fragment@0 {
> + target-path="/soc/fpgamgr@0/bridge@0";

Does the bus really go thru the fpgamgr and then the bridge as this 
implies? Or fpgamgr is a sideband controller? For example purposes, it 
would be better to show this not as an overlay so I get the complete 
picture.

Unit addresses of 0 look a bit questionable as I'd expect these to be 
addresses.

> + __overlay__ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bridge@ff20 {

2 levels of bridge devices/buses?

There is nothing programmable for this bridge? clocks, resets, etc.?

> + compatible = "fpga-area";
> +
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + ranges = <0 0x 0xc000 0x0001>,
> +  <1 0x0002 0xff22 0x0008>,
> +  <1 0x00010040 0xff210040 0x0020>;
> +
> + firmware-name = "soc_system.rbf";
> +
> + onchip_memory2_0: memory@0 {
> + device_type = "memory";
> + compatible = "altr,onchipmem-15.1";
> + reg = <0 0x 0x0001>;
> + };
> +
> + jtag_uart: serial@10002 {
> + compatible = "altr,juart-1.0";
> + reg = <1 0x0002 0x0008>;
> + interrupt-parent = <&intc>;
> + interrupts = <0 42 4>;
> + };
> +
> + led_pio: gpio@100010040 {
> + compatible = "altr,pio-1.0";
> + reg = <1 0x00010040 0x0020>;
> + altr,gpio-bank-width = <4>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + };
> + };
> + };
> + };
> +};
> +
> -- 
> 1.7.9.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
--
To unsubscribe from this list: send the line "unsub