[PATCH 3/5] ARM: dts: add dts files for hi3519-demb board

[Jiancheng Xue]

add dts files for hi3519-demb board

Signed-off-by: Jiancheng Xue 
---
 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/hi3519-demb.dts |  55 
 arch/arm/boot/dts/hi3519.dtsi | 129 ++
 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..39ad947 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -133,6 +133,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
+dtb-$(CONFIG_ARCH_HI3519) += \
+   hi3519-demb.dtb
 dtb-$(CONFIG_ARCH_HI3xxx) += \
hi3620-hi4511.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts 
b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 000..c7a1720
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,55 @@
+/*
+ * 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";
+
+   chosen {
+   bootargs = "mem=64M console=ttyAMA0,115200 early_printk \
+root=/dev/mtdblock2 rootfstype=jffs2 \
+mtdparts=hi_sfc:1M(boot),4M(kernel),11M(rootfs)";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   };
+   };
+
+   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..7422ddc
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,129 @@
+/*
+ * 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"
+#include 
+/ {
+   aliases {
+   serial0 = &uart0;
+   };
+
+   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;
+
+   amba {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "arm,amba-bus";
+   ranges;
+
+   uart0: uart@1210 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x1210 0x1000>;
+   interrupts = <0 4 4>;
+   clocks = <&clock HI3519_UART0_CLK>;
+   clock-names = "apb_pclk";
+   status = "disable";
+   };
+
+   uart1: uart@12101000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x12101000 0x1000>;
+   interrupts = <0 5 4>;
+   clock

[PATCH 1/5] clk: hi3519: add CRG driver for hisilicon hi3519 soc

[Jiancheng Xue]

The CRG(Clock and Reset Generator) module provides
clock and reset signals for other modules in hi3519 soc.

Signed-off-by: Jiancheng Xue 
---
 .../devicetree/bindings/clock/hi3519-clock.txt |  46 +++
 drivers/clk/hisilicon/Makefile |   1 +
 drivers/clk/hisilicon/clk-hi3519.c | 130 ++
 drivers/clk/hisilicon/reset.c  | 149 +
 drivers/clk/hisilicon/reset.h  |  25 
 include/dt-bindings/clock/hi3519-clock.h   |  78 +++
 6 files changed, 429 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-clock.txt
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

diff --git a/Documentation/devicetree/bindings/clock/hi3519-clock.txt 
b/Documentation/devicetree/bindings/clock/hi3519-clock.txt
new file mode 100644
index 000..9fea878
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-clock.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-clock" - 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 .
+
+- #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 {
+   compatible = "hisilicon,hi3519-clock";
+reg = <0x1201 0x1>;
+#clock-cells = <1>;
+#reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c@0x1211 {
+   compatible = "hisilicon,hi3519-i2c";
+reg = <0x1211 0x1000>;
+clocks = <&CRG HI3519_I2C0_RST>;*/
+resets = <&CRG 0xE4 0>;
+};
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..9a601c0 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_ARCH_HIP04)+= clk-hip04.o
 obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
 obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o
 obj-$(CONFIG_STUB_CLK_HI6220)  += clk-hi6220-stub.o
+obj-$(CONFIG_ARCH_HI3519)  += clk-hi3519.o reset.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c 
b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 000..00e4f76
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,130 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include "clk.h"
+#include "reset.h"
+
+static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
+   { HI3519_FIXED_2376M, "2376m", NULL, CLK_IS_ROOT, 237600UL, },
+   { HI3519_FIXED_1188M, "1188m", NULL, CLK_IS_ROOT, 118800, },
+   { HI3519_FIXED_594M, "594m", NULL, CLK_IS_ROOT, 59400, },
+   { HI3519_FIXED_297M, "297m", NULL, CLK_IS_ROOT, 29700, },
+   { HI3519_FIXED_148P5M, "148p5m", NULL, CLK_IS_ROOT, 14850, },
+   { HI3519_FIXED_74P25M, "74p25m", NULL, CLK_IS_ROOT, 7425, },
+   { HI3519_FIXED_792M, "792m", NULL, CLK_IS_ROOT, 79200, },
+   { HI3519_FIXED_475M, "475m", NULL, CLK_IS_ROOT, 47500, },
+   { HI3519_FIXED_340M, "340m", NULL, CLK_IS_ROOT, 34000, },
+   { HI3519_FIXED_72M, "72m", NULL, CLK_IS_ROOT, 7200, },
+   { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 4, },
+   { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 2000

[PATCH 0/5] arm, hisi: enable Hi3519 soc

[Jiancheng Xue]

Hello,

Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset 
adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, device tree and 
debug uart configuration.
It has been tested on hi3519 reference board.

Spi-nor flash driver and other peripheral drivers will be submitted later.

Any comments will be appreciated!

Thanks!

Jiancheng Xue (5):
  clk: hi3519: add CRG driver for hisilicon hi3519 soc
  ARM: hisi: enable Hi3519 soc
  ARM: dts: add dts files for hi3519-demb board
  ARM: config: enable ARCH_HI3519
  ARM: debug: add Hi3519 debug uart

 .../devicetree/bindings/clock/hi3519-clock.txt |  46 +++
 arch/arm/Kconfig.debug |  10 ++
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/hi3519-demb.dts  |  55 
 arch/arm/boot/dts/hi3519.dtsi  | 129 ++
 arch/arm/configs/hisi_defconfig|   1 +
 arch/arm/mach-hisi/Kconfig |   9 ++
 arch/arm/mach-hisi/hisilicon.c |   9 ++
 drivers/clk/hisilicon/Makefile |   1 +
 drivers/clk/hisilicon/clk-hi3519.c | 130 ++
 drivers/clk/hisilicon/reset.c  | 149 +
 drivers/clk/hisilicon/reset.h  |  25 
 include/dt-bindings/clock/hi3519-clock.h   |  78 +++
 13 files changed, 644 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-clock.txt
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

-- 
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 net-next 1/3] dts: hisi: enables the ethX for D02 board

[yankejian]

this patch enables the ethX for D02 board on hip05-d02.dts. otherwise it
cannot find hns ethX by ifconfig -a.

Signed-off-by: yankejian 
---
 arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts 
b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
index ae34e25..6aa5cb2 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
@@ -34,3 +34,19 @@
 &uart0 {
status = "ok";
 };
+
+ð2 {
+   status = "okay";
+};
+
+ð3 {
+   status = "okay";
+};
+
+ð6 {
+   status = "okay";
+};
+
+ð7 {
+   status = "okay";
+};
-- 
1.9.1

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

[PATCH net-next 2/3] dts: hisi: fixes no syscon error when init mdio

[yankejian]

when linux start up, we get the log below:
"Hi-HNS_MDIO 803c.mdio: no syscon hisilicon,peri-c-subctrl
 mdio_bus mdio@803c: mdio sys ctl reg has not maped   "

the source code about the subctrl is dealled with syscon, but dts doesn't.
it cause such fault. so this patch adds the syscon info on dts files to
fixes it.

Signed-off-by: yankejian 
---
 arch/arm64/boot/dts/hisilicon/hip05.dtsi | 4 
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index 4ff16d0..daaca63 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -246,6 +246,10 @@
clock-frequency = <2>;
};
 
+   peri_c_subctrl: sub_ctrl_c@8000 {
+   compatible = "hisilicon,peri-c-subctrl", "syscon";
+   reg = < 0x0 0x8000 0x0 0x1>;
+   };
uart0: uart@8030 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x8030 0x0 0x1>;
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 606dd5a..4d4815e 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -10,8 +10,8 @@ soc0: soc@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "hisilicon,hns-mdio";
-   reg = <0x0 0x803c 0x0 0x1
-  0x0 0x8000 0x0 0x1>;
+   reg = <0x0 0x803c 0x0 0x1>;
+   subctrl_vbase = <&peri_c_subctrl>;
 
soc0_phy0: ethernet-phy@0 {
reg = <0x0>;
-- 
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 net-next 0/3] dts: hisi: fixes can't find eth for hip05-D02

[yankejian]

this patchset fixes the bug that eth can't initial successful. because the
the dts files doesn't match the source code.

yankejian (3):
  dts: hisi: enables the ethX for D02 board
  dts: hisi: fixes no syscon error when init mdio
  arm64: hip05-d02: Document devicetree bindings for Hisilicon D02 Board

 .../devicetree/bindings/arm/hisilicon/hisilicon.txt  | 16 
 arch/arm64/boot/dts/hisilicon/hip05-d02.dts  | 16 
 arch/arm64/boot/dts/hisilicon/hip05.dtsi |  4 
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi |  4 ++--
 4 files changed, 38 insertions(+), 2 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 V5 RESEND 2/3] iommu/hisilicon: Add hi6220-SoC smmu driver

[chenfeng]

On 2015/11/27 20:02, Joerg Roedel wrote:
> On Fri, Nov 20, 2015 at 10:25:08AM +0800, Chen Feng wrote:
>> +config HI6220_IOMMU
>> +bool "Hi6220 IOMMU Support"
>> +depends on ARM64
>> +select IOMMU_API
>> +select IOMMU_IOVA
>> +help
>> +  Enable IOMMU Driver for hi6220 SoC. The IOMMU API and IOMMU IOVA
>> +  is also selected.
> 
> The last sentence is of little help for the user. Better put the reasons
> in here when a user should select this option.
> 
>> +/*set axi id*/
> 
> Coding style nit: Please write these oneline comments with spaces, like
> this:
> 
>   /* set axi id */
> 

learned,Thanks.
>> +static int hi6220_smmu_attach_dev(struct iommu_domain *domain,
>> +  struct device *dev)
>> +{
>> +dev->archdata.iommu = &iova_allocator;
>> +
>> +return 0;
>> +}
>> +
>> +static void hi6220_smmu_detach_dev(struct iommu_domain *domain,
>> +   struct device *dev)
>> +{
>> +dev->archdata.iommu = NULL;
>> +}
> 
> This basically means that this driver only supports one domain, right?
yes.
> That is not compatible with the iommu-api requirements.
> 
> You need to create an iommu-group per smmu in your system and put all
> devices translated by this smmu in that group. And then you must change
> your code to allow attaching/detaching this iommu-group to different
> domains.
> 
I read the code,I am confused about these concepts.
In my opinion,
IOMMU-Domain: The masters in one domain share the same iova space. Is that 
right?
IOMMU-GROUP: As you mentioned up,all devices translated by this smmu should be 
into one group.
I can do this. But if there is only on domain in the system, how can I 
attaching/detaching the group
to different domains.

I think I have something wrong with these concepts.

Could you help to give me some suggestions.

> 
>   Joerg
> 
> 
> .
> 

--
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 02/15] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Chanwoo Choi]

Hi Rob,

On Sat, Nov 28, 2015 at 5:30 AM, Rob Herring  wrote:
> On Thu, Nov 26, 2015 at 10:47:26PM +0900, Chanwoo Choi wrote:
>> This patch adds the documentation for generic exynos bus frequency
>> driver.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  .../devicetree/bindings/devfreq/exynos-bus.txt | 92 
>> ++
>>  1 file changed, 92 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
>> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> new file mode 100644
>> index ..5d90623bd173
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -0,0 +1,92 @@
>> +* Generic Exynos Bus frequency device
>> +
>> +The Samsung Exynos SoC have many buses for data transfer between DRAM
>> +and sub-blocks in SoC. Almost Exynos SoC have the common architecture
>> +for buses. Generally, the each bus of Exynos SoC includes the source clock
>> +and power line and then is able to change the clock according to the usage
>> +of each buses on runtime. When gathering the usage of each buses on runtime,
>> +thie driver uses the exynos-ppmu.c driver with DEVFREQ-EVENT framework.
>
> Please don't refer to Linux subsystem specifics in bindings. It looks
> like you are creating devices to match what you have for drivers, not
> what the h/w looks like.

OK. I'll modify it on next patchiest.

>
>
>> +There are a little different composition among Exynos SoC because each 
>> Exynos
>> +SoC has the different sub-blocks. So, this difference should be specified
>> +in devicetree file instead of each device driver. In result, this driver
>> +is able to support the bus frequency for all Exynos SoCs.
>> +
>> +Required properties for bus device:
>> +- compatible: Should be "samsung,exynos-bus".
>> +- clock-names : the name of clock used by the bus, "bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- #clock-cells: should be 1.
>> +- operating-points-v2: the OPP table including frequency/voltage information
>> +  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
>> +- vdd-supply: the regulator to provide the buses with the voltage.
>> +- devfreq-events: the devfreq-event device to monitor the curret utilization
>> +  of buses.
>> +
>> +Optional properties for bus device:
>> +- exynos,saturation-ratio: the percentage value which is used to calibrate
>> +   the performance count againt total cycle count.
>> +
>> +Example1:
>> + Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
>> + power line (regulator). The MIF (Memory Interface) AXI bus is used to
>> + transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
>> +
>> + - power line(VDD_MIF) --> bus for DMC block (dmc clock)
>> +
>> + - MIF bus's frequency/voltage table
>> + ---
>> + |Lv| Freq   | Voltage |
>> + ---
>> + |L1| 5  |80   |
>> + |L2| 10 |80   |
>> + |L3| 133000 |80   |
>> + |L4| 20 |80   |
>> + |L5| 40 |875000   |
>> + ---
>> +
>> +Example2 :
>> + The bus of DMC block in exynos3250.dtsi are listed below:
>
> What is DMC?

DMC (DRAM Memory Controller)

>
>> +
>> + bus_dmc: bus_dmc {
>> + compatible = "samsung,exynos-bus";
>
> I would expect the children of this bus to be under this node.

I add the detailed description on patch9 which is included in this
patch-set as follwoing.
- [RFC PATCH 09/15] PM / devfreq: exynos: Update documentation for bus
devices usingpassive governor

This patch-set don' include the the list of children node in parent dt node.
Instead, I add the separate node and then each children node has the
the phandle of parent node

>
>> + clocks = <&cmu_dmc CLK_DIV_DMC>;
>> + clock-names = "bus";
>> + operating-points-v2 = <&bus_dmc_opp_table>;
>> + status = "disabled";
>> + };
>> +
>> + bus_dmc_opp_table: opp_table0 {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + opp00 {
>> + opp-hz = /bits/ 64 <5000>;
>> + opp-microvolt = <80>;
>> + };
>> + opp01 {
>> + opp-hz = /bits/ 64 <1>;
>> + opp-microvolt = <80>;
>> + };
>> + opp02 {
>> + opp-hz = /bits/ 64 <13300>;
>> + opp-microvolt = <80>;
>> + };
>> + opp03 {
>> + opp-hz = /bits/ 64 <2>;
>> + opp-microvolt = <80>;
>> + };
>> + opp04 {
>> + opp-hz = /bits/ 64 <4>;
>> + opp-microvolt = <875000>;
>> + };
>> + };
>> +

Re: [PATCH V5 RESEND 0/3] Add iommu support for hi6220 HiKey board

[chenfeng]

On 2015/11/27 19:49, Joerg Roedel wrote:
> On Fri, Nov 20, 2015 at 10:25:06AM +0800, Chen Feng wrote:
>> eg:
>> struct iommu_domain *domain = iommu_domain_alloc(bus);
>> iommu_attach_device(domain, dev);
>> struct iova_domain *iovad = (struct iova_domain *)m_dev->archdata.iommu;
>> struct iova * t_iova = alloc_iova(iovad, size, limit_pfn, align);
>> iommu_map(domain, t_iova->pfn_lo << 12, phy_addr, size, port);
> 
> Any reason the media subsystem should use the iommu-api directly, and
> not the dma-api? You can make your iommu available by adapting the
> common dma-iommu implementation from Robin Murphy to your iommu to make
> it usable through the dma-api.
> 

ok, I will change this to dma-api. Since v1 version, the dma-api was not ok for 
arm64.
I will do this with dma-api function.
> 
>   Joerg
> 
> 
> .
> 

--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Nicolas Pitre]

On Fri, 27 Nov 2015, Arnd Bergmann wrote:

> I don't mind creating the /proc/atags compatibility hack from the kernel
> for a DT based N700 kernel, as long as we limit it as much as we can
> to the machines that need it. Leaving a board file for the N700 in place
> that contains the procfs code (and not much more) seems reasonable
> here, as we are talking about a board specific hack and the whole point
> appears to be running unmodified user space.
> 
> Regarding how to get the data into the kernel in the first place, my
> preferred choice would still be to have an intermediate bootloader
> such as pxa-impedance-matcher, but I won't complain if others are
> happy enough about putting it into the ATAGS compat code we already
> have, as long as it's limited to the boards we know need it.

Assuming you have a N700 board file for special procfs code, then why 
not getting at the atags in memory where the bootloader has put them 
directly from that same board file? This way it'll really be limited to 
the board we know needs it and the special exception will be contained 
to that one file.  Amongst the machine specific hooks, there is one that 
gets invoked early during boot before those atags are overwritten.


Nicolas
--
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/9] Documentation: dt-bindings: regulator: add LM363x regulator binding information

[Mark Brown]

On Fri, Nov 27, 2015 at 02:44:50PM -0600, Rob Herring wrote:
> On Fri, Nov 27, 2015 at 12:37:50PM +, Mark Brown wrote:
> > On Thu, Nov 26, 2015 at 03:57:00PM +0900, Milo Kim wrote:

> > > This binding describes LM3631 and LM3632 regulator properties.

> > Please use subject lines matching the style for the subsystem.

> Which for bindings, my preference is "dt-bindings: ..." I assume you 
> meant to follow regulator style though. 

Given that maintainers are generally expected to review and apply
bindings themselves it seems sensible (and it's what we mostly seem to
do).


signature.asc
Description: PGP signature

[PATCH] ravb: add R8A7791 support

[Sergei Shtylyov]

Add support  for yet another ARM member of the R-Car family, R-Car M2, also
known as R8A7791.

Signed-off-by: Sergei Shtylyov 

---
The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if it's
applied to 'net.git' instead. :-)

 Documentation/devicetree/bindings/net/renesas,ravb.txt |1 +
 drivers/net/ethernet/renesas/ravb_main.c   |1 +
 2 files changed, 2 insertions(+)

Index: net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
===
--- net-next.orig/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -5,6 +5,7 @@ interface contains.
 
 Required properties:
 - compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 
SoC.
+ "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC.
  "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC.
  "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC.
 - reg: offset and length of (1) the register block and (2) the stream buffer.
Index: net-next/drivers/net/ethernet/renesas/ravb_main.c
===
--- net-next.orig/drivers/net/ethernet/renesas/ravb_main.c
+++ net-next/drivers/net/ethernet/renesas/ravb_main.c
@@ -1655,6 +1655,7 @@ static int ravb_mdio_release(struct ravb
 
 static const struct of_device_id ravb_match_table[] = {
{ .compatible = "renesas,etheravb-r8a7790", .data = (void *)RCAR_GEN2 },
+   { .compatible = "renesas,etheravb-r8a7791", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,etheravb-r8a7794", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,etheravb-r8a7795", .data = (void *)RCAR_GEN3 },
{ }

--
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 03/10] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices

[Rob Herring]

On Wed, Nov 25, 2015 at 04:07:21PM -0800, Andrew Duggan wrote:
> Add devicetree binding for I2C devices and add bindings for optional
> parameters in the function drivers. Parameters for function drivers are
> defined in child nodes for each of the functions.
> 
> Signed-off-by: Andrew Duggan 
> ---
>  .../devicetree/bindings/input/rmi4/rmi_f01.txt | 39 
>  .../devicetree/bindings/input/rmi4/rmi_i2c.txt | 53 
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  drivers/input/rmi4/rmi_bus.c   | 71 
> ++
>  drivers/input/rmi4/rmi_driver.c| 28 +
>  drivers/input/rmi4/rmi_i2c.c   | 12 +++-
>  6 files changed, 203 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
>  create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt 
> b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
> new file mode 100644
> index 000..df34dd5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
> @@ -0,0 +1,39 @@
> +Synaptics RMI4 F01 Device Binding
> +
> +The Synaptics RMI4 core is able to support RMI4 devices using differnet
> +transports and differnet functions. This file describes the device tree

s/differnet/different/

> +bindings for devices which contain Function 1. Complete documentation
> +for transports and other functions can be found in:
> +Documentation/devicetree/bindings/input/rmi4.
> +
> +Additional documentation for F01 can be found at:
> +http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
> +
> +Optional Properties:
> +- syna,nosleep-mode: If set the device will run at full power without 
> sleeping.
> + nosleep has 3 modes, 0 will not change the default
> + setting, 1 will disable nosleep (allow sleeping),
> + and 2 will enable nosleep (disabling sleep).
> +- syna,wakeup-threshold: Defines the amplitude of the disturbance to the
> + background capacitance that will cause the
> + device to wake from dozing.

> +- syna,doze-holdoff: The delay to wait after the last finger lift and the
> + first doze cycle (in 0.1 second units).
> +- syna,doze-interval: The time period that the device sleeps between finger
> + activity (in 10 ms units).

Use millisec units and -msec suffix.


> +
> +
> +Example of a RMI4 I2C device with F01:
> + Example:
> + &i2c1 {
> + rmi-i2c-dev@2c {
> + compatible = "syna,rmi-i2c";
> +
> + ...
> +
> + rmi-f01@1 {
> + reg = <0x1>;
> + syna,nosleep-mode = <1>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt 
> b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
> new file mode 100644
> index 000..0f4a8e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
> @@ -0,0 +1,53 @@
> +Synaptics RMI4 I2C Device Binding
> +
> +The Synaptics RMI4 core is able to support RMI4 devices using differnet
> +transports and differnet functions. This file describes the device tree

s/differnet/different/

> +bindings for devices using the I2C tranport driver. Complete documentation
> +for other transports and functions cen be found ini
> +Documentation/devicetree/bindings/input/rmi4.
> +
> +Required Properties:
> +- compatible: syna,rmi-i2c

This is not very specific. Perhaps at least "rmi4" instead of just rmi.

> +- reg: I2C address
> +- #address-cells: Set to 1 to indicate that the function child nodes
> + consist of only on uint32 value.
> +- #size-cells: Set to 0 to indicate that the function child nodes do not
> + have a size property.
> +
> +Optional Properties:
> +- interrupts: interrupt which the rmi device is connected to.
> +- interrupt-parent: The interrupt controller.
> +See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +- syna,reset-delay-ms: The number of milliseconds to wait after resetting the

"-msec" is the more commonly used abreviation in bindings.

> + device.
> +
> +Function Parameters:
> +Parameters specific to RMI functions are contained in child nodes of the rmi 
> device
> + node. Documentation for the parameters of each function can be found in:
> +Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
> +
> +
> +
> +Example:
> + &i2c1 {
> + rmi-i2c-dev@2c {
> + compatible = "syna,rmi-i2c";
> + reg = <0x2c>;
> + #address-cells = <1>;
> + 

Re: [PATCH 05/10] Input: synaptics-rmi4: Add device tree support for 2d sensors and F11

[Rob Herring]

On Wed, Nov 25, 2015 at 04:09:13PM -0800, Andrew Duggan wrote:
> 2D sensors have several parameter which can be set in the platform data.
> This patch adds support for getting those values from devicetree.
> 
> Signed-off-by: Andrew Duggan 
> ---
>  .../bindings/input/rmi4/rmi_2d_sensor.txt  |  54 +++
>  drivers/input/rmi4/rmi_2d_sensor.c | 103 
> +
>  drivers/input/rmi4/rmi_2d_sensor.h |   3 +
>  drivers/input/rmi4/rmi_f11.c   |   7 +-
>  4 files changed, 166 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt 
> b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> new file mode 100644
> index 000..bbff31b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> @@ -0,0 +1,54 @@
> +Synaptics RMI4 2D Sensor Device Binding
> +
> +The Synaptics RMI4 core is able to support RMI4 devices using differnet

s/differnet/different/

> +transports and differnet functions. This file describes the device tree

ditto.

> +bindings for devices which contain 2D sensors using Function 11 or
> +Function 12. Complete documentation for transports and other functions
> +can be found in:
> +Documentation/devicetree/bindings/input/rmi4.
> +
> +RMI4 Function 11 and Function 12 are for 2D touch position sensing.
> +Additional documentation for F11 can be found at:
> +http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
> +
> +Optional Properties:
> +- syna,swap-axes: Swap X and Y positions when reporting (boolean).
> +- syna,flip-x: Reverse the direction of X (boolean).
> +- syna,flip-y: Reverse the direction of Y (boolean).

We already have similar, generic properties for these.

> +- syna,clip-x-low: Sets a minimum value for X.
> +- syna,clip-y-low: Sets a minimum value for Y.
> +- syna,clip-x-high: Sets a maximum value for X.
> +- syna,clip-y-high: Sets a maximum value for Y.
> +- syna,offset-x: Add an offset to X.
> +- syna,offset_y: Add an offset to Y.

Don't use "_".

> +- syna,delta-x-threshold: Set the minimum distance on the X axis required
> + to generate an interrupt in reduced reporting
> + mode.
> +- syna,delta-y-threshold: Set the minimum distance on the Y axis required
> + to generate an interrupt in reduced reporting
> + mode.
> +- syna,type-a: Report type A multitouch events.
> +- syna,sensor-type: Set the sensor type. 1 for touchscreen 2 for touchpad.
> +- syna,x-mm: The length in millimeters of the X axis.
> +- syna,y-mm: The length in millimeters of the Y axis.

I think some of these have common properties defined too. If not, we 
should add them.

> +- syna,disable-report-mask: Mask for disabling posiiton reporting. Used to
> + disable reporing absolute position data.
> +- syna,rezero-wait: Time in miliseconds to wait after issuing a rezero
> + command.

Add -msec suffix.
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Friday 27 November 2015 19:51:48 Russell King - ARM Linux wrote:
> On Fri, Nov 27, 2015 at 01:27:23PM +, Russell King - ARM Linux wrote:
> > It is possible to redirect any program to open any other file.  You can
> > do it via a LD preload, and intercepting the open(), and possibly the
> > read() calls if you want to do something more fancy.  The down-side is
> > that you have to arrange for the preloaded object to be used by the
> > linker, and the additional overhead it places on the intercepted
> > functions.
> 
> Another idea if people don't like the preload idea.
> 
> We could create a zero-sized /proc/atags, and then use a bind mount in
> userspace to bind some other file containing the required information
> on top.  That could even be the atag blob from /sys/firmware/whatever.
> The N700 (or whatever platform needs it) could be responsible for
> creating the zero-sized /proc/atags so that we don't have it everywhere.

I don't mind creating the /proc/atags compatibility hack from the kernel
for a DT based N700 kernel, as long as we limit it as much as we can
to the machines that need it. Leaving a board file for the N700 in place
that contains the procfs code (and not much more) seems reasonable
here, as we are talking about a board specific hack and the whole point
appears to be running unmodified user space.

Regarding how to get the data into the kernel in the first place, my
preferred choice would still be to have an intermediate bootloader
such as pxa-impedance-matcher, but I won't complain if others are
happy enough about putting it into the ATAGS compat code we already
have, as long as it's limited to the boards we know need it.

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 4/9] Documentation: dt-bindings: regulator: add LM363x regulator binding information

[Rob Herring]

On Thu, Nov 26, 2015 at 03:57:00PM +0900, Milo Kim wrote:
> This binding describes LM3631 and LM3632 regulator properties.
> 
> Cc: Rob Herring 
> Cc: devicetree@vger.kernel.org
> Cc: Lee Jones  
> Cc: Jacek Anaszewski 
> Cc: Mark Brown 
> Cc: linux-l...@vger.kernel.org 
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Milo Kim 
> ---
>  .../bindings/regulator/lm363x-regulator.txt| 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> 
> diff --git a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt 
> b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> new file mode 100644
> index 000..8f14df9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> @@ -0,0 +1,34 @@
> +TI LMU LM363x regulator device tree bindings
> +
> +LM363x regulator driver supports LM3631 and LM3632.
> +LM3631 has five regulators and LM3632 supports three regulators.
> +
> +Required property:
> +  - compatible: "ti,lm363x-regulator"
> +
> +Optional properties:
> +  LM3632 has external enable pins for two LDOs.
> +  - ti,lcm-en1-gpio: A GPIO specifier for Vpos control pin.
> +  - ti,lcm-en2-gpio: A GPIO specifier for Vneg control pin.

Use "-gpios" please.

> +
> +Child nodes:
> +  LM3631
> +  - vboost
> +  - vcont
> +  - voref
> +  - vpos
> +  - vneg
> +
> +  LM3632
> +  - vboost
> +  - vpos
> +  - vneg
> +
> +  Optional properties of a child node:
> +  Each sub-node should contain the constraints and initialization.
> +  Please refer to [1].

What about the regulator names?

> +
> +Examples: Please refer to ti-lmu dt-bindings [2].
> +
> +[1] ../regulator/regulator.txt
> +[2] ../mfd/ti-lmu.txt
> -- 
> 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 1/9] Documentation: dt-bindings: mfd: add TI LMU device binding information

[Rob Herring]

On Thu, Nov 26, 2015 at 03:56:57PM +0900, Milo Kim wrote:
> This patch describes overall binding for TI LMU MFD devices.
> 
> Cc: Rob Herring 
> Cc: devicetree@vger.kernel.org
> Cc: Lee Jones  
> Cc: Jacek Anaszewski 
> Cc: Mark Brown 
> Cc: linux-l...@vger.kernel.org 
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Milo Kim 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/mfd/ti-lmu.txt | 243 
> +++
>  1 file changed, 243 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt 
> b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> new file mode 100644
> index 000..c885cf8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> @@ -0,0 +1,243 @@
> +TI LMU (Lighting Management Unit) device tree bindings
> +
> +TI LMU driver supports lighting devices below.
> +
> +   Name  Child nodes
> +  --  -
> +  LM3532   Backlight
> +  LM3631   Backlight and regulator
> +  LM3632   Backlight and regulator
> +  LM3633   Backlight, LED and fault monitor
> +  LM3695   Backlight
> +  LM3697   Backlight and fault monitor
> +
> +Required properties:
> +  - compatible: Should be one of:
> +"ti,lm3532"
> +"ti,lm3631"
> +"ti,lm3632"
> +"ti,lm3633"
> +"ti,lm3695"
> +"ti,lm3697"
> +  - reg: I2C slave address.
> + 0x11 for LM3632
> + 0x29 for LM3631
> + 0x36 for LM3633, LM3697
> + 0x38 for LM3532
> + 0x63 for LM3695
> +
> +Optional property:
> +  - enable-gpios: A GPIO specifier for hardware enable pin.
> +
> +Required node:
> +  - backlight: All LMU devices have backlight child nodes.
> +   For the properties, please refer to [1].
> +
> +Optional nodes:
> +  - fault-monitor: Hardware fault monitoring driver for LM3633 and LM3697.
> +Required properties:
> +  - compatible: Should be one of:
> +"ti,lm3633-fault-monitor"
> +"ti,lm3697-fault-monitor"
> +  - leds: LED properties for LM3633. Please refer to [2].
> +  - regulators: Regulator properties for LM3631 and LM3632.
> +Please refer to [3].
> +
> +[1] ../leds/backlight/ti-lmu-backlight.txt
> +[2] ../leds/leds-lm3633.txt
> +[3] ../regulator/lm363x-regulator.txt
> +
> +lm3532@38 {
> + compatible = "ti,lm3532";
> + reg = <0x38>;
> +
> + enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>;
> +
> + backlight {
> + compatible = "ti,lm3532-backlight";
> +
> + lcd {
> + led-sources = <0 1 2>;
> + ramp-up-msec = <30>;
> + ramp-down-msec = <0>;
> + };
> + };
> +};
> +
> +lm3631@29 {
> + compatible = "ti,lm3631";
> + reg = <0x29>;
> +
> + regulators {
> + compatible = "ti,lm363x-regulator";
> +
> + vboost {
> + regulator-name = "lcd_boost";
> + regulator-min-microvolt = <450>;
> + regulator-max-microvolt = <635>;
> + regulator-always-on;
> + };
> +
> + vcont {
> + regulator-name = "lcd_vcont";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + voref {
> + regulator-name = "lcd_voref";
> + regulator-min-microvolt = <400>;
> + regulator-max-microvolt = <600>;
> + };
> +
> + vpos {
> + regulator-name = "lcd_vpos";
> + regulator-min-microvolt = <400>;
> + regulator-max-microvolt = <600>;
> + regulator-boot-on;
> + };
> +
> + vneg {
> + regulator-name = "lcd_vneg";
> + regulator-min-microvolt = <400>;
> + regulator-max-microvolt = <600>;
> + regulator-boot-on;
> + };
> + };
> +
> + backlight {
> + compatible = "ti,lm3631-backlight";
> +
> + lcd_bl {
> + led-sources = <0 1>;
> + ramp-up-msec = <300>;
> + };
> + };
> +};
> +
> +lm3632@11 {
> + compatible = "ti,lm3632";
> + reg = <0x11>;
> +
> + enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>; /* PC2 */
> +
> + regulators {
> + compatible = "ti,lm363x-regulator";
> +
> + ti,lcm-en1-gpio = <&pioC 0 GPIO_ACTIVE_HIGH>; /* PC0 */
> + ti,lcm-en2-gpio = <&pioC 1 GPIO_ACTIVE_HIGH>; /* PC1 */
> +
> + vboost {
> + regulator-name = "lcd_boost";
> + regul

Re: [PATCH v2 4/9] Documentation: dt-bindings: regulator: add LM363x regulator binding information

[Rob Herring]

On Fri, Nov 27, 2015 at 12:37:50PM +, Mark Brown wrote:
> On Thu, Nov 26, 2015 at 03:57:00PM +0900, Milo Kim wrote:
> > This binding describes LM3631 and LM3632 regulator properties.
> 
> Please use subject lines matching the style for the subsystem.

Which for bindings, my preference is "dt-bindings: ..." I assume you 
meant to follow regulator style though. 

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

Re: [PATCH 1/3] dt-bindings: add Marvell core PLL and clock divider PMU documentation

[Russell King - ARM Linux]

On Fri, Nov 27, 2015 at 02:21:14PM -0600, Rob Herring wrote:
> On Thu, Nov 26, 2015 at 10:23:21PM +, Russell King wrote:
> > Add documentation for the Marvell clock divider driver, which is used
> > to source clocks for the AXI bus, video decoder, GPU and LCD blocks.
> > 
> > Signed-off-by: Russell King 
> > ---
> >  .../bindings/clock/dove-divider-clock.txt  | 28 
> > ++
> >  1 file changed, 28 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/dove-divider-clock.txt 
> > b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> > new file mode 100644
> > index ..0c602de279e5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> > @@ -0,0 +1,28 @@
> > +PLl divider based Dove clocks
> > +
> > +Marvell Dove has a 2GHz PLL, which feeds into a set of dividers to provide
> > +high speed clocks for a number of peripherals.  These dividers are part of
> > +the PMU, and thus this node should be a child of the PMU node.
> 
> It seems a bit strange to just be documenting these clocks. What about 
> the rest of the SOC clocks?

This is all that this pair of registers provide.

The SoC has other clocks handled by other DT nodes - for Dove, we now
have:

gate_clk: clock-gating-ctrl@0038 {
compatible = "marvell,dove-gating-clock";
reg = <0x0038 0x4>;
clocks = <&core_clk 0>;
#clock-cells = <1>;
};
divider_clk: core-clock@0064 {
compatible = "marvell,dove-divider-clock";
reg = <0x0064 0x8>;
#clock-cells = <1>;
};
core_clk: core-clocks@0214 {
compatible = "marvell,dove-core-clock";
reg = <0x0214 0x4>;
#clock-cells = <1>;
};

and all three of these are part of the PMU register block.  I'm not sure
why the mvebu maintainers decided to minutely describe the PMU like this,
but unfortunately that's the structure we have.

What's more silly is that the "dove-core-clock" appears to disagree in
terminology with the manual - there's a "Core PLL" which supplies the
dividers in the "divider_clk" block, and is entirely separate from the
CPU PLL which "core_clk" is describing.

IMHO, it would've been cleaner to have these components registered
separately from a central PMU driver (as I'm doing with the power
domains, resets and IRQs that are part of the PMU), but my view is
limited to Dove and not the other mvebu clocks, so there may be a good
reason for it.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/5] dt-bindings: mediatek: Modify pinctrl bindings for mt2701

[Rob Herring]

On Thu, Nov 26, 2015 at 04:44:29PM +0800, Biao Huang wrote:
> Signed-off-by: Biao Huang 
> ---
>  .../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..ca6a27a 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.
> +(a) "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl.
> +(b) "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
> +(c) "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl.
> +(d) "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl.
> +(e) "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.

If you were trying to sort these, they still aren't quite sorted. There 
is no point in sorting if you number (or letter) them because you will 
have to update many lines on any change. So drop the (a), (b), (c), etc.

Rob

>  - 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: [RFC PATCH 02/15] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Rob Herring]

On Thu, Nov 26, 2015 at 10:47:26PM +0900, Chanwoo Choi wrote:
> This patch adds the documentation for generic exynos bus frequency
> driver.
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 92 
> ++
>  1 file changed, 92 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> new file mode 100644
> index ..5d90623bd173
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -0,0 +1,92 @@
> +* Generic Exynos Bus frequency device
> +
> +The Samsung Exynos SoC have many buses for data transfer between DRAM
> +and sub-blocks in SoC. Almost Exynos SoC have the common architecture
> +for buses. Generally, the each bus of Exynos SoC includes the source clock
> +and power line and then is able to change the clock according to the usage
> +of each buses on runtime. When gathering the usage of each buses on runtime,
> +thie driver uses the exynos-ppmu.c driver with DEVFREQ-EVENT framework.

Please don't refer to Linux subsystem specifics in bindings. It looks 
like you are creating devices to match what you have for drivers, not 
what the h/w looks like.


> +There are a little different composition among Exynos SoC because each Exynos
> +SoC has the different sub-blocks. So, this difference should be specified
> +in devicetree file instead of each device driver. In result, this driver
> +is able to support the bus frequency for all Exynos SoCs.
> +
> +Required properties for bus device:
> +- compatible: Should be "samsung,exynos-bus".
> +- clock-names : the name of clock used by the bus, "bus".
> +- clocks : phandles for clock specified in "clock-names" property.
> +- #clock-cells: should be 1.
> +- operating-points-v2: the OPP table including frequency/voltage information
> +  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
> +- vdd-supply: the regulator to provide the buses with the voltage.
> +- devfreq-events: the devfreq-event device to monitor the curret utilization
> +  of buses.
> +
> +Optional properties for bus device:
> +- exynos,saturation-ratio: the percentage value which is used to calibrate
> +   the performance count againt total cycle count.
> +
> +Example1:
> + Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
> + power line (regulator). The MIF (Memory Interface) AXI bus is used to
> + transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
> +
> + - power line(VDD_MIF) --> bus for DMC block (dmc clock)
> +
> + - MIF bus's frequency/voltage table
> + ---
> + |Lv| Freq   | Voltage |
> + ---
> + |L1| 5  |80   |
> + |L2| 10 |80   |
> + |L3| 133000 |80   |
> + |L4| 20 |80   |
> + |L5| 40 |875000   |
> + ---
> +
> +Example2 :
> + The bus of DMC block in exynos3250.dtsi are listed below:

What is DMC?

> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";

I would expect the children of this bus to be under this node.

> + clocks = <&cmu_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <13300>;
> + opp-microvolt = <80>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <80>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <875000>;
> + };
> + };
> +
> + Usage case to handle the frequency and voltage of bus on runtime
> + in exynos3250-rinato.dts are listed below:
> +
> + &bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;

What do these phandles point to exactly?

> + vdd-supply = <&buck1_reg>;  /* VDD_MIF */
> + status = "okay";
> + };
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] dt-bindings: add Marvell core PLL and clock divider PMU documentation

[Andrew Lunn]

> > +Marvell Dove has a 2GHz PLL, which feeds into a set of dividers to provide
> > +high speed clocks for a number of peripherals.  These dividers are part of
> > +the PMU, and thus this node should be a child of the PMU node.
> 
> It seems a bit strange to just be documenting these clocks. What about 
> the rest of the SOC clocks?

$ ls Documentation/devicetree/bindings/clock/mvebu*
Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt

Dove is a member of mvebu, and gets most of its clocks from these
drivers. But it has additional clocks which are not shared with other
members of mvebu.

  Andrew
--
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] dt-bindings: add Marvell core PLL and clock divider PMU documentation

[Rob Herring]

On Thu, Nov 26, 2015 at 10:23:21PM +, Russell King wrote:
> Add documentation for the Marvell clock divider driver, which is used
> to source clocks for the AXI bus, video decoder, GPU and LCD blocks.
> 
> Signed-off-by: Russell King 
> ---
>  .../bindings/clock/dove-divider-clock.txt  | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/dove-divider-clock.txt 
> b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> new file mode 100644
> index ..0c602de279e5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> @@ -0,0 +1,28 @@
> +PLl divider based Dove clocks
> +
> +Marvell Dove has a 2GHz PLL, which feeds into a set of dividers to provide
> +high speed clocks for a number of peripherals.  These dividers are part of
> +the PMU, and thus this node should be a child of the PMU node.

It seems a bit strange to just be documenting these clocks. What about 
the rest of the SOC clocks?

> +
> +The following clocks are provided:
> +
> +ID   Clock
> +-
> +0AXI bus clock
> +1GPU clock
> +2VMeta clock
> +3LCD clock
> +
> +Required properties:
> +- compatible : shall be "marvell,dove-divider-clock"
> +- reg : shall be the register address of the Core PLL and Clock Divider
> +   Control 0 register.  This will cover that register, as well as the
> +   Core PLL and Clock Divider Control 1 register.  Thus, it will have
> +   a size of 8.
> +- #clock-cells : from common clock binding; shall be set to 1
> +
> +divider_clk: core-clock@0064 {
> + compatible = "marvell,dove-divider-clock";
> + reg = <0x0064 0x8>;
> + #clock-cells = <1>;
> +};
> -- 
> 2.1.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 1/2] ARM: mvebu: add kirkwood compatibles for cloudengine boards

[Rob Herring]

On Fri, Nov 27, 2015 at 12:00:54AM +0100, 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 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/arm/marvell,kirkwood.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt 
> b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
> index 5171ad8f48ff..ab0c9cdf388e 100644
> --- a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
> @@ -24,6 +24,8 @@ board. Currently known boards are:
>  "buffalo,lswxl"
>  "buffalo,lsxhl"
>  "buffalo,lsxl"
> +"cloudengines,pogo02"
> +"cloudengines,pogoplugv4"
>  "dlink,dns-320"
>  "dlink,dns-320-a1"
>  "dlink,dns-325"
> -- 
> 2.4.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] dt-bindings: iio: adc: Update mcp342x binding for the mcp3421

[Rob Herring]

On Fri, Nov 27, 2015 at 02:52:52PM +0100, Sascha Hauer wrote:
> The mcp3421 is the single channel variant of the mcp342x family and
> can be supported by the mcp342x driver.
> 
> Signed-off-by: Sascha Hauer 
> Cc: devicetree@vger.kernel.org

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/iio/adc/mcp3422.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt 
> b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
> index 333139c..dcae4cc 100644
> --- a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
> @@ -1,7 +1,8 @@
> -* Microchip mcp3422/3/4/6/7/8 chip family (ADC)
> +* Microchip mcp3421/2/3/4/6/7/8 chip family (ADC)
>  
>  Required properties:
>   - compatible: Should be
> + "microchip,mcp3421" or
>   "microchip,mcp3422" or
>   "microchip,mcp3423" or
>   "microchip,mcp3424" or
> -- 
> 2.6.2
> 
> --
> 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 v2 1/1] platform: goldfish: pipe: add devicetree bindings

[Rob Herring]

On Fri, Nov 27, 2015 at 12:17 PM, Greg Hackmann  wrote:
> On 11/26/15 12:34 AM, Christoffer Dall wrote:
>>
>> On Wed, Nov 25, 2015 at 02:24:16PM -0600, Rob Herring wrote:
>>>
>>>
>>> The binding may be trivial, but there's a bigger question of whether
>>> this is the right long term direction. For example is upstream QEMU
>>> going to take all the Android pipe stuff? Couldn't virtio be used here
>>> as the transport?
>>>
>>
>> But I wonder if that should really block this from being merged?  The
>> support may not be in QEMU but it's in the Android emulator and it would
>> be a less broken implementation with these patches in the kernel than
>> without, I think.
>>
>> -Christoffer
>>
>
> To add to Christoffer's point, we added these bindings so we don't need to
> rely on the goldfish virtual bus for probing anymore.
>
> Switching from the goldfish virtual bus to Device-Tree already eliminates
> one big piece where the Android emulator has diverged from upstream qemu.
> And on the kernel side, it means we don't need ARM and MIPS goldfish board
> code to instantiate the bus.

Okay, fair enough. That's not evident from the patch.

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

Re: [PATCH 3/3] ARM: dts: dove: add Dove divider clocks

[Andrew Lunn]

On Thu, Nov 26, 2015 at 10:23:32PM +, Russell King wrote:
> Add the Dove divider clocks to the Dove dtsi file.
> 
> Signed-off-by: Russell King 

Acked-by: Andrew Lunn 

  Andrew

> ---
>  arch/arm/boot/dts/dove.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> index 179121630ad7..ea36a262d056 100644
> --- a/arch/arm/boot/dts/dove.dtsi
> +++ b/arch/arm/boot/dts/dove.dtsi
> @@ -459,6 +459,12 @@
>   #clock-cells = <1>;
>   };
>  
> + divider_clk: core-clock@0064 {
> + compatible = 
> "marvell,dove-divider-clock";
> + reg = <0x0064 0x8>;
> + #clock-cells = <1>;
> + };
> +
>   pinctrl: pin-ctrl@0200 {
>   compatible = "marvell,dove-pinctrl";
>   reg = <0x0200 0x14>,
> -- 
> 2.1.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 2/3] clk: add Dove PLL divider support for GPU, VMeta and AXI clocks

[Andrew Lunn]

Hi Russell

> +static int dove_calc_divider(const struct dove_clk *dc, unsigned long rate,
> +  unsigned long parent_rate, bool set)
> +{
> + unsigned int divider, max;
> +
> + divider = DIV_ROUND_CLOSEST(parent_rate, rate);
> +
> + if (dc->divider_table) {
> + unsigned int i;
> +
> + for (i = 0; dc->divider_table[i]; i++)
> + if (divider == dc->divider_table[i]) {
> + divider = i;
> + break;
> + }
> +
> + if (dc->divider_table[i])
> + return -EINVAL;

Is this condition correct? If we have reached the 0 at the end of the
table, -EINVAL makes sense. But that would need a !

   Andrew
--
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] dt-bindings: add Marvell core PLL and clock divider PMU documentation

[Andrew Lunn]

On Thu, Nov 26, 2015 at 10:23:21PM +, Russell King wrote:
> Add documentation for the Marvell clock divider driver, which is used
> to source clocks for the AXI bus, video decoder, GPU and LCD blocks.
> 
> Signed-off-by: Russell King 
> ---
>  .../bindings/clock/dove-divider-clock.txt  | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/dove-divider-clock.txt 
> b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> new file mode 100644
> index ..0c602de279e5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> @@ -0,0 +1,28 @@
> +PLl divider based Dove clocks

Nit pick. It would be nice if the second L of PLL was also a capital.

Acked-by: Andrew Lunn 

  Andrew
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Russell King - ARM Linux]

On Fri, Nov 27, 2015 at 01:27:23PM +, Russell King - ARM Linux wrote:
> It is possible to redirect any program to open any other file.  You can
> do it via a LD preload, and intercepting the open(), and possibly the
> read() calls if you want to do something more fancy.  The down-side is
> that you have to arrange for the preloaded object to be used by the
> linker, and the additional overhead it places on the intercepted
> functions.

Another idea if people don't like the preload idea.

We could create a zero-sized /proc/atags, and then use a bind mount in
userspace to bind some other file containing the required information
on top.  That could even be the atag blob from /sys/firmware/whatever.
The N700 (or whatever platform needs it) could be responsible for
creating the zero-sized /proc/atags so that we don't have it everywhere.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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

[4.4-rc][PATCH] ARM: dts: am4372: fix clock source for arm twd and global timers

[Grygorii Strashko]

ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
Timekeeping core misbehaves. For example, execution of command
"sleep 5" will take 10 sec instead of 5.

Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
it for clocking ARM TWD and Global timer (same way as on OMAP4).

Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: Tero Kristo 
Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
nodes")
Signed-off-by: Grygorii Strashko 
---
 arch/arm/boot/dts/am4372.dtsi| 4 ++--
 arch/arm/boot/dts/am43xx-clocks.dtsi | 8 
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..de8791a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -74,7 +74,7 @@
reg = <0x48240200 0x100>;
interrupts = ;
interrupt-parent = <&gic>;
-   clocks = <&dpll_mpu_m2_ck>;
+   clocks = <&mpu_periphclk>;
};
 
local_timer: timer@48240600 {
@@ -82,7 +82,7 @@
reg = <0x48240600 0x100>;
interrupts = ;
interrupt-parent = <&gic>;
-   clocks = <&dpll_mpu_m2_ck>;
+   clocks = <&mpu_periphclk>;
};
 
l2-cache-controller@48242000 {
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index cc88728..2ff58b1 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -259,6 +259,14 @@
ti,invert-autoidle-bit;
};
 
+   mpu_periphclk: mpu_periphclk {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&dpll_mpu_ck>;
+   clock-mult = <1>;
+   clock-div = <2>;
+   };
+
dpll_ddr_ck: dpll_ddr_ck {
#clock-cells = <0>;
compatible = "ti,am3-dpll-clock";
-- 
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

Re: [PATCH v2 1/1] platform: goldfish: pipe: add devicetree bindings

[Greg Hackmann]

On 11/26/15 12:34 AM, Christoffer Dall wrote:

On Wed, Nov 25, 2015 at 02:24:16PM -0600, Rob Herring wrote:


The binding may be trivial, but there's a bigger question of whether
this is the right long term direction. For example is upstream QEMU
going to take all the Android pipe stuff? Couldn't virtio be used here
as the transport?



But I wonder if that should really block this from being merged?  The
support may not be in QEMU but it's in the Android emulator and it would
be a less broken implementation with these patches in the kernel than
without, I think.

-Christoffer



To add to Christoffer's point, we added these bindings so we don't need 
to rely on the goldfish virtual bus for probing anymore.


Switching from the goldfish virtual bus to Device-Tree already 
eliminates one big piece where the Android emulator has diverged from 
upstream qemu.  And on the kernel side, it means we don't need ARM and 
MIPS goldfish board code to instantiate the bus.


In the long term I'm happy to push the SDK team towards replacing the 
Android pipe with a virtio alternative.  (We've already been switching 
over to virtio for things like storage.)  But in the short term, we 
still need it.  And I don't think it benefits the mainline kernel if we 
have to maintain cleanup patches like this out-of-tree.


--
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 v11 6/8] Input: goodix - add support for ESD

[Dmitry Torokhov]

On Fri, Nov 27, 2015 at 05:24:21PM +, Tirdea, Irina wrote:
> 
> 
> > -Original Message-
> > From: Rob Herring [mailto:r...@kernel.org]
> > Sent: 20 November, 2015 17:45
> > To: Tirdea, Irina
> > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; Karsten Merker; 
> > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian;
> > linux-ker...@vger.kernel.org; devicetree@vger.kernel.org
> > Subject: Re: [PATCH v11 6/8] Input: goodix - add support for ESD
> > 
> > On Thu, Nov 19, 2015 at 02:26:39PM +0200, Irina Tirdea wrote:
> > > Add ESD (Electrostatic Discharge) protection mechanism.
> > 
> > [...]
> > 
> > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > > driver gt9xx.c for Android (publicly available in Android kernel
> > > trees for various devices).
> > >
> > > Signed-off-by: Irina Tirdea 
> > > For the binding: Acked-by: Rob Herring 
> > 
> > You should not have the "For the binding:" part here. It was just a note
> > so it was clear what part I looked at.
> > 
> 
> I saw it done like that in another patch already merged, so I thought it's
> the right way [1]. Dmitry, could you fix this at merge or you need me to
> send another patchset?

No, I can fix it up locally. Let me sort through the latest submission
and I'll let you know if I need any changes.

Thanks!

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

Re: [PATCH v5 4/4] ARM: dts: rockchip: Add Crypto node for rk3288

[Heiko Stübner]

Am Mittwoch, 25. November 2015, 13:43:33 schrieb Zain Wang:
> Add Crypto node for rk3288 including crypto controller and dma clk.
> 
> Signed-off-by: Zain Wang 
> Tested-by: Heiko Stuebner 

applied to my dts32 branch for 4.5 .

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 v11 6/8] Input: goodix - add support for ESD

[Tirdea, Irina]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 20 November, 2015 17:45
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; Karsten Merker; 
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian;
> linux-ker...@vger.kernel.org; devicetree@vger.kernel.org
> Subject: Re: [PATCH v11 6/8] Input: goodix - add support for ESD
> 
> On Thu, Nov 19, 2015 at 02:26:39PM +0200, Irina Tirdea wrote:
> > Add ESD (Electrostatic Discharge) protection mechanism.
> 
> [...]
> 
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > Signed-off-by: Irina Tirdea 
> > For the binding: Acked-by: Rob Herring 
> 
> You should not have the "For the binding:" part here. It was just a note
> so it was clear what part I looked at.
> 

I saw it done like that in another patch already merged, so I thought it's
the right way [1]. Dmitry, could you fix this at merge or you need me to
send another patchset?

Thanks,
Irina

[1] 
https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/commit/?id=d2a3e0931a8f3b95b910096d022ffd98adbd075c

> It is preferred to split DT bindings to separate patches for this
> reason.
> 
> > Signed-off-by: Irina Tirdea 
> > ---
> >  .../bindings/input/touchscreen/goodix.txt  |   4 +
> >  drivers/input/touchscreen/goodix.c | 160 
> > -
> >  2 files changed, 159 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] arm64: dts: uniphier: add PH1-LD10 SoC/board support

[Masahiro Yamada]

This is the first ARMv8 SoC from Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Fix phandle to cpu nodes in cluster1

Changes in v2:
  - Split into a single patch

 MAINTAINERS|   1 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/socionext/Makefile |   4 +
 .../boot/dts/socionext/uniphier-ph1-ld10-ref.dts   |  95 +++
 .../boot/dts/socionext/uniphier-ph1-ld10.dtsi  | 280 +
 .../arm64/boot/dts/socionext/uniphier-pinctrl.dtsi |   1 +
 .../boot/dts/socionext/uniphier-support-card.dtsi  |   1 +
 7 files changed, 383 insertions(+)
 create mode 100644 arch/arm64/boot/dts/socionext/Makefile
 create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
 create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
 create mode 12 arch/arm64/boot/dts/socionext/uniphier-pinctrl.dtsi
 create mode 12 arch/arm64/boot/dts/socionext/uniphier-support-card.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index 3f92804..99a1424 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier*
 F: arch/arm/include/asm/hardware/cache-uniphier.h
 F: arch/arm/mach-uniphier/
 F: arch/arm/mm/cache-uniphier.c
+F: arch/arm64/boot/dts/socionext/
 F: drivers/i2c/busses/i2c-uniphier*
 F: drivers/pinctrl/uniphier/
 F: drivers/tty/serial/8250/8250_uniphier.c
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index eb3c42d..6672a96 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -11,6 +11,7 @@ dts-dirs += marvell
 dts-dirs += mediatek
 dts-dirs += qcom
 dts-dirs += rockchip
+dts-dirs += socionext
 dts-dirs += sprd
 dts-dirs += xilinx
 
diff --git a/arch/arm64/boot/dts/socionext/Makefile 
b/arch/arm64/boot/dts/socionext/Makefile
new file mode 100644
index 000..8d72771
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -0,0 +1,4 @@
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+
+always := $(dtb-y)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
new file mode 100644
index 000..3e53317
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
@@ -0,0 +1,95 @@
+/*
+ * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-support-card.dtsi"
+
+/ {
+   model = "UniPhier PH1-LD10 Reference Board";
+   compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+
+   memory {
+   device_type = "memory";
+   reg = <0 0x8000 0 0xc000>;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   serial0 = &serial0;
+   serial1 = &serial1;

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Bjorn Andersson]

On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones  wrote:
> This functionality is especially useful during the testing phase.  When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).
>

I want this too!

> Signed-off-by: Ludovic Barre 
> Signed-off-by: Lee Jones 
> ---
>  drivers/remoteproc/remoteproc_debugfs.c | 34 
> +
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c 
> b/drivers/remoteproc/remoteproc_debugfs.c
> index 9d30809..8113c18 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -88,8 +88,42 @@ static ssize_t rproc_state_read(struct file *filp, char 
> __user *userbuf,
> return simple_read_from_buffer(userbuf, count, ppos, buf, i);
>  }
>
> +static ssize_t rproc_state_write(struct file *filp, const char __user 
> *userbuf,
> +size_t count, loff_t *ppos)
> +{
> +   struct rproc *rproc = filp->private_data;
> +   char buf[10];
> +   int ret;
> +
> +   if (count > sizeof(buf))
> +   return count;
> +
> +   ret = copy_from_user(buf, userbuf, count);
> +   if (ret)
> +   return -EFAULT;
> +
> +   if (buf[count - 1] == '\n')
> +   buf[count - 1] = '\0';

I believe you can get here with count = 0.

> +
> +   if (!strncmp(buf, "start", count)) {
> +   ret = rproc_boot(rproc);
> +   if (ret) {
> +   dev_err(&rproc->dev, "Boot failed: %d\n", ret);
> +   return ret;
> +   }
> +   } else if (!strncmp(buf, "stop", count)) {
> +   rproc_shutdown(rproc);
> +   } else {
> +   dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);

Unrecognized

> +   return -EINVAL;
> +   }
> +
> +   return count;
> +}
> +
>  static const struct file_operations rproc_state_ops = {
> .read = rproc_state_read,
> +   .write = rproc_state_write,
> .open = simple_open,
> .llseek = generic_file_llseek,
>  };

Part of these nits

Acked-by: Bjorn Andersson 

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: [RESEND RFC/PATCH 6/8] media: platform: mtk-vcodec: Add Mediatek V4L2 Video Encoder Driver

[Daniel Thompson]

Hi Tiffany/Andrew

This review is a rather more superficial than my previous one. Mostly 
I'm just commenting on some of the bits I spotted whilst trying to find 
my way around the patchset.


I hope to another more detailed review for v2 (and feel free to add me 
to Cc:).



On 17/11/15 12:54, Tiffany Lin wrote:
> Signed-off-by: Tiffany Lin 

Signed-off-by: Andrew-CT Chen 


There is no description of what this patch does. Its not enough to have 
it on the cover letter (because that won't end up in version control). 
You need something here.




diff --git a/drivers/media/platform/mtk-vcodec/Kconfig 
b/drivers/media/platform/mtk-vcodec/Kconfig
new file mode 100644
index 000..1c0b935
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/Kconfig
@@ -0,0 +1,5 @@
+config MEDIATEK_VPU
+   bool
+   ---help---
+ This driver provides downloading firmware vpu (video processor unit)
+ and communicating with vpu.


Haven't I seen this before (in patch 3)? Why is it being added to 
another Kconfig file?




diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
new file mode 100644
index 000..c7f7174
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -0,0 +1,12 @@
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
+  mtk_vcodec_util.o \
+  mtk_vcodec_enc_drv.o \
+  mtk_vcodec_enc.o \
+  mtk_vcodec_enc_pm.o
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += common/
+
+ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vcodec/include \
+-I$(srctree)/drivers/media/platform/mtk-vcodec \
+-I$(srctree)/drivers/media/platform/mtk-vpu


Seems like there's a lot of directories here. Are these files 
(framework, common, vcodec, etc) so unrelated they really need to live 
in separate directories?


Why not just drivers/media/platform/mediatek?



diff --git a/drivers/media/platform/mtk-vcodec/common/Makefile 
b/drivers/media/platform/mtk-vcodec/common/Makefile
new file mode 100644
index 000..477ab80
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/common/Makefile
@@ -0,0 +1,8 @@
+obj-y += \
+venc_drv_if.o
+
+ccflags-y += \
+-I$(srctree)/include/ \
+-I$(srctree)/drivers/media/platform/mtk-vcodec \
+-I$(srctree)/drivers/media/platform/mtk-vcodec/include \
+-I$(srctree)/drivers/media/platform/mtk-vpu


As above, this appears to be a directory to hold just one file.


> diff --git a/drivers/media/platform/mtk-vcodec/common/venc_drv_if.c 
b/drivers/media/platform/mtk-vcodec/common/venc_drv_if.c

> new file mode 100644
> index 000..9b3f025
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/common/venc_drv_if.c
> @@ -0,0 +1,152 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Daniel Hsiao 
> + * Jungchang Tsao 
> + *
> + * 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 "mtk_vcodec_drv.h"
> +#include "mtk_vcodec_enc.h"
> +#include "mtk_vcodec_pm.h"
> +#include "mtk_vcodec_util.h"
> +#include "mtk_vpu_core.h"
> +
> +#include "venc_drv_if.h"
> +#include "venc_drv_base.h"
> +
> +
> +int venc_if_create(void *ctx, unsigned int fourcc, unsigned long 
*handle)

> +{
> +  struct venc_handle *h;
> +  char str[10];
> +
> +  mtk_vcodec_fmt2str(fourcc, str);
> +
> +  h = kzalloc(sizeof(*h), GFP_KERNEL);
> +  if (!h)
> +  return -ENOMEM;
> +
> +  h->fourcc = fourcc;
> +  h->ctx = ctx;
> +  mtk_vcodec_debug(h, "fmt = %s handle = %p", str, h);
> +
> +  switch (fourcc) {
> +  default:
> +  mtk_vcodec_err(h, "invalid format %s", str);
> +  goto err_out;
> +  }
> +
> +  *handle = (unsigned long)h;
> +  return 0;
> +
> +err_out:
> +  kfree(h);
> +  return -EINVAL;
> +}
> +
> +int venc_if_init(unsigned long handle)
> +{
> +  int ret = 0;
> +  struct venc_handle *h = (struct venc_handle *)handle;
> +
> +  mtk_vcodec_debug_enter(h);
> +
> +  mtk_venc_lock(h->ctx);
> +  mtk_vcodec_enc_clock_on();
> +  vpu_enable_clock(vpu_get_plat_device(h->ctx->dev->plat_dev));
> +  ret = h->enc_if->init(h->ctx, (unsigned long *)&h->drv_handle);
> +  vpu_disable_clock(vpu_get_plat_device(h->ctx->dev->plat_dev));
> +  mtk_vcodec_enc_clock_off();
> +  mtk_venc_unlock(h->ctx);
> +
> +  return ret;
> +}

To me this looks more like an obfuscation layer rather than a 
abstraction layer. I don't understand why we need to hide things from 
the V4L2 implementation that 

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

[Arnd Bergmann]

On Friday 27 November 2015 20:32:03 Bharat Kumar Gogada wrote:
> +   do {
> +   err = nwl_pcie_link_up(pcie, PHY_RDY_LINKUP);
> +   if (err != 1) {
> +   check_link_up++;
> +   if (check_link_up > LINKUP_ITER_CHECK)
> +   return -ENODEV;
> +   mdelay(1000);
> +   }
> +   } while (!err);

mdelay(1000) is not something anyone should do. Why can't you call
a sleeping function here?

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 v10] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 27/11/15 15:02, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> Acked-by: Rob Herring 
> ---
> Changes for v10:
> -> Changed MSI address to PCIe controller base.
> -> Removed nwl_check_hwirq function, instead using bitmap_find_next_zero_area
>API to do the same.
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>  drivers/pci/host/Kconfig   |   10 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1068 
> 
>  4 files changed, 1147 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 
> diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
> b/drivers/pci/host/pcie-xilinx-nwl.c
> new file mode 100644
> index 000..d070344
> --- /dev/null
> +++ b/drivers/pci/host/pcie-xilinx-nwl.c

[...]

> +#define MSI_ADDRESS  0xFD48
> +

Really? Why do you bother having DT support then? You might as well
hardcode everything, while you're at it.

/me felling depressed now.

> +struct nwl_msi { /* MSI information */
> + struct irq_domain *msi_domain;
> + unsigned long *bitmap;
> + struct irq_domain *dev_domain;
> + struct mutex lock;  /* protect bitmap variable */
> + int irq_msi0;
> + int irq_msi1;
> +};
> +
> +struct nwl_pcie {
> + struct device *dev;
> + void __iomem *breg_base;
> + void __iomem *pcireg_base;
> + void __iomem *ecam_base;
> + u32 phys_breg_base; /* Physical Bridge Register Base */
> + u32 phys_pcie_reg_base; /* Physical PCIe Controller Base */
> + u32 phys_ecam_base; /* Physical Configuration Base */

All these u32 should be phys_addr_t. Not all the world is 32bit,
fortunately.

> + u32 breg_size;
> + u32 pcie_reg_size;
> + u32 ecam_size;
> + int irq_intx;
> + int irq_misc;
> + u32 ecam_value;
> + u8 last_busno;
> + u8 root_busno;
> + u8 link_up;
> + struct nwl_msi msi;
> + struct irq_domain *legacy_irq_domain;
> +};

[...]

> +static void nwl_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + phys_addr_t msi_addr = MSI_ADDRESS;

Fix this.

> +
> + msg->address_lo = lower_32_bits(msi_addr);
> + msg->address_hi = upper_32_bits(msi_addr);
> + msg->data = data->hwirq;
> +}

[...]

> +static int nwl_pcie_bridge_init(struct nwl_pcie *pcie)
> +{
> + struct platform_device *pdev = to_platform_device(pcie->dev);
> + u32 breg_val, ecam_val, first_busno = 0;
> + int err;
> + int check_link_up = 0;
> +
> + /* Check for BREG present bit */
> + breg_val = nwl_bridge_readl(pcie, E_BREG_CAPABILITIES) & BREG_PRESENT;
> + if (!breg_val) {
> + dev_err(pcie->dev, "BREG is not present\n");
> + return breg_val;
> + }
> + /* Write bridge_off to breg base */
> + nwl_bridge_writel(pcie, (u32)(pcie->phys_breg_base),
> +   E_BREG_BASE_LO);
> +

I love the casting of a u32 to a u32. You have to program E_BREG_BASE_HI
as well, once you've fixed the data type.

> + /* Enable BREG */
> + nwl_bridge_writel(pcie, ~BREG_ENABLE_FORCE & BREG_ENABLE,
> +   E_BREG_CONTROL);
> +
> + /* Disable DMA channel registers */
> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, BRCFG_PCIE_RX0) |
> +   CFG_DMA_REG_BAR, BRCFG_PCIE_RX0);
> +
> + /* Enable the bridge config interrupt */
> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, BRCFG_INTERRUPT) |
> +   BRCFG_INTERRUPT_MASK, BRCFG_INTERRUPT);
> + /* Enable Ingress subtractive decode translation */
> + nwl_bridge_writel(pcie, SET_ISUB_CONTROL, I_ISUB_CONTROL);
> +
> + /* Enable msg filtering details */
> + nwl_bridge_writel(pcie, CFG_ENABLE_MSG_FILTER_MASK,
> +   BRCFG_PCIE_RX_MSG_FILTER);
> + do {
> + err = nwl_pcie_link_up(pcie, PHY_RDY_LINKUP);
> + if (err != 1) {
> + check_link_up++;
> + if (check_link_up > LINKUP_ITER_CHECK)
> + return -ENODEV;
> + mdelay(1000);
> + }
> + } while (!err);
> +
> + /* Check for ECAM present bit */
> + ecam_val = nwl_bridge_readl(pcie, E_ECAM_CAPABILITIES) & E_ECAM_PRESENT;
> + if (!ecam_val) {
> + dev_err(pcie->dev, "ECAM is not present\n");
> + return ecam_val;
> + }
> +
> + /* Enable ECAM */
> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, E_ECAM_CONTROL) |
> +   E_ECAM_CR_ENABLE, E_ECAM_CONTROL);
> + /* Write ecam_value on ecam_control */
> + nwl_bridge_writel(pcie, nwl_bridge_readl

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

[Bharat Kumar Gogada]

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

Signed-off-by: Bharat Kumar Gogada 
Signed-off-by: Ravi Kiran Gummaluri 
Acked-by: Rob Herring 
---
Changes for v10:
-> Changed MSI address to PCIe controller base.
-> Removed nwl_check_hwirq function, instead using bitmap_find_next_zero_area
   API to do the same.
---
 .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-xilinx-nwl.c | 1068 
 4 files changed, 1147 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
 create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c

diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..3b2a9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,68 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+   configuration sapce, and length
+- reg-names: Must include the following entries:
+   "breg": bridge registers
+   "pcireg": PCIe controller registers
+   "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+   "msi1, msi0": interrupt asserted when msi is received
+   "intx": interrupt that is asserted when an legacy interrupt is received
+   "misc": interrupt asserted when miscellaneous is received
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+   supported by hardware)
+   Please refer to the standard PCI bus binding document for a more
+   detailed explanation
+- msi-controller: indicates that this is MSI controller node
+- msi-parent:  MSI parent of the root complex itself
+- legacy-interrupt-controller: Interrupt controller device node for Legacy 
interrupts
+   - interrupt-controller: identifies the node as an interrupt controller
+   - #interrupt-cells: should be set to 1
+   - #address-cells: specifies the number of cells needed to encode an
+   address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+   #address-cells = <3>;
+   #size-cells = <2>;
+   compatible = "xlnx,nwl-pcie-2.11";
+   #interrupt-cells = <1>;
+   msi-controller;
+   device_type = "pci";
+   interrupt-parent = <&gic>;
+   interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
+   interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
+   interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+   interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
+   <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
+   <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
+   <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+
+   msi-parent = <&nwl_pcie>;
+   reg = <0x0 0xfd0e 0x1000>,
+ <0x0 0xfd48 0x1000>,
+ <0x0 0xe000 0x100>;
+   reg-names = "breg", "pcireg", "cfg";
+   ranges = <0x0200 0x 0xe100 0x 0xe100 0 
0x0f00>;
+
+   pcie_intc: legacy-interrupt-controller {
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..24cbcba 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,16 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
 
+config PCIE_XILINX_NWL
+   bool "NWL PCIe Core"
+   depends on ARCH_ZYNQMP
+   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+   help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
 config PCIE_DW
bool
 
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keysto

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Tony Lindgren]

* Pali Rohár  [151127 00:39]:
> On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
> > Just to explore options.. How about make a minimal device driver that
> > just loads the atags blob from /lib/firmware and then shows it in
> > /proc/atags? Of course some checking on the atags should be done by
> > the driver..
> 
> And who can dynamically create that blob file in /lib/firmware? If
> kernel does not export those atags (somehow) from bootloader, then
> userspace is not able to create that blob... cyclic problem.
> 
> So no, problem is that bootloader provides via custom atags dynamic
> information like: boot reason (how was device started, by rtc alarm? by
> reboot? by usb charger? by power button?), boot mode (should be enter
> into firmware update mode?, is this normal boot mode?), ... and those
> information are needed for some proprietary software (e.g. firmware
> upgrade/flash) but also by any other open source applications (based on
> usb charger we enter different runlevel -- for just only charging
> device).

OK if the ATAGs are not static then naturally we can't create the blobs
then.

Regards,

Tony
--
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] dt-bindings: iio: adc: Update mcp342x binding for the mcp3421

[Sascha Hauer]

The mcp3421 is the single channel variant of the mcp342x family and
can be supported by the mcp342x driver.

Signed-off-by: Sascha Hauer 
Cc: devicetree@vger.kernel.org
---
 Documentation/devicetree/bindings/iio/adc/mcp3422.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt 
b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
index 333139c..dcae4cc 100644
--- a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
@@ -1,7 +1,8 @@
-* Microchip mcp3422/3/4/6/7/8 chip family (ADC)
+* Microchip mcp3421/2/3/4/6/7/8 chip family (ADC)
 
 Required properties:
  - compatible: Should be
+   "microchip,mcp3421" or
"microchip,mcp3422" or
"microchip,mcp3423" or
"microchip,mcp3424" or
-- 
2.6.2

--
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 v8 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

[Heiko Stübner]

Am Mittwoch, 28. Oktober 2015, 16:56:01 schrieb Yakir Yang:
> There are some IP limit on rk3288 that only support 4 physical lanes
> of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---

[...]

> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> 6307060..563ffb1d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
> *dp) return;
>   }
> 
> - ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> -  dp->video_info.link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
> +  dp->video_info.max_link_rate);
>   if (ret) {
>   dev_err(dp->dev, "unable to do link train\n");
>   return;
> @@ -1156,16 +1156,25 @@ static int analogix_dp_dt_parse_pdata(struct
> analogix_dp_device *dp) struct device_node *dp_node = dp->dev->of_node;
>   struct video_info *video_info = &dp->video_info;
> 
> - if (of_property_read_u32(dp_node, "samsung,link-rate",
> -  &video_info->link_rate)) {
> - dev_err(dp->dev, "failed to get link-rate\n");
> - return -EINVAL;
> - }
> -
> - if (of_property_read_u32(dp_node, "samsung,lane-count",
> -  &video_info->lane_count)) {
> - dev_err(dp->dev, "failed to get lane-count\n");
> - return -EINVAL;
> + switch (dp->plat_data && dp->plat_data->dev_type) {

drivers/gpu/drm/bridge/analogix/analogix_dp_core.c: In function 
‘analogix_dp_dt_parse_pdata’:
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1191:10: warning: switch 
condition has boolean value [-Wswitch-bool]
  switch (dp->plat_data && dp->plat_data->dev_type) {
  ^

As I think we always will need to distinguish between implementations,
I guess it should be safe to exit with an error, it that implementation-data
is not available, like just doing before the switch a:

if (!dp->plat_data)
return -EINVAL;


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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Russell King - ARM Linux]

On Thu, Nov 26, 2015 at 10:07:39AM +0100, Pali Rohár wrote:
> On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote:
> > > Or populate /proc/atags only for the ones that need it from machine
> > > specific init_early?
> > 
> > This is circling back to the first comment from Russell King where
> > he suggested a legacy file for the N900 which calls save_atags():
> > 
> > Are the ATAGs at a fixed address on the N900?  Can that be handled in
> > some kind of legacy file for the N900 which calls save_atags() on it, so
> > we don't end up introducing yet more stuff that we have to maintain into
> > the distant future?  If not, what about copying a known working atag
> > structure into a legacy file for the N900?
> > 
> > It seems to me that patches 1, 2, 4, and 5 could be replaced by this
> > approach.
> 
> Hi Frank, in this case I will ask my question again: It is possible to
> read atags from that legacy file. And if yes how? I was not thinking
> about this approach because somebody in past wrote that this is not
> possible...

It is possible to redirect any program to open any other file.  You can
do it via a LD preload, and intercepting the open(), and possibly the
read() calls if you want to do something more fancy.  The down-side is
that you have to arrange for the preloaded object to be used by the
linker, and the additional overhead it places on the intercepted
functions.

Eg,

openatags.c:

#define open libc_open
#include 
#undef open
#include 

int open(const char *pathname, int flags, mode_t mode)
{
static int (*old_open)(const char *pathname, int flags, mode_t mode);

if (strcmp(pathname, "/proc/atags") == 0)
pathname = "/tmp/my-atags";

if (!old_open)
old_open = dlsym(RTLD_NEXT, "open");

return old_open(pathname, flags, mode);
}

Build the above (untested) with:
gcc -O2 -o openatags.o -c openatags.c
gcc -shared -o openatags.so openatags.o -ldl

Now, when running one of these programs, you can test it with:
LD_PRELOAD=openatags.so /name/of/program

You could also list the full pathname to openatags.so in /etc/ld.so.preload,
but test it first, because it will always be used by the linker in that
case, and you wouldn't want normal commands to misbehave.

Note that putting it in /etc/ld.so.preload will also have the effect that
cat /proc/atags will also get redirected to /tmp/my-atags too.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 3/4] Crypto: rockchip/crypto - add crypto driver for rk3288

[Herbert Xu]

On Wed, Nov 25, 2015 at 01:43:32PM +0800, Zain Wang wrote:
> Crypto driver support:
>  ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You can alloc tags above in your case.
> 
> And other algorithms and platforms will be added later on.
> 
> Signed-off-by: Zain Wang 
> Tested-by: Heiko Stuebner 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/4] crypto: rockchip/crypto - add DT bindings documentation

[Herbert Xu]

On Wed, Nov 25, 2015 at 01:43:30PM +0800, Zain Wang wrote:
> Add DT bindings documentation for the rk3288 crypto drivers.
> 
> Signed-off-by: Zain Wang 
> Acked-by: Rob Herring 
> Tested-by: Heiko Stuebner 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: Dynamically adding SPI buses (was: Re: [PATCH v8 0/8] Device Tree Overlays - 8th time's the charm)

[Mark Brown]

On Fri, Nov 27, 2015 at 02:06:41PM +0100, Geert Uytterhoeven wrote:

> (replaying to an old mail, as I'm seeing the exact same behavior with current
>  overlay code)

I don't seem to have this mail...  I'm not even sure that mailing list
archive does (at least

   http://thread.gmane.org/gmane.linux.kernel.spi.devel/18597

anyway).

> When adding an SPI master device node to DT, or changing its status to "okay",
> of_register_spi_devices() will scan for SPI slaves, and will add all of them.
> Later, the notifier kicks:

> static int of_spi_notify(struct notifier_block *nb, unsigned long action,
>  void *arg)
> {
> ...
> 
> case OF_RECONFIG_CHANGE_ADD:
> master = of_find_spi_master_by_node(rd->dn->parent);
> if (master == NULL)
> return NOTIFY_OK;   /* not for us */
> 
> spi = of_register_spi_device(master, rd->dn);

> Woops, this fails, as the device has been added before!
> Should the code just check for the existence of the SPI slave first, or would
> that cause problems when just modifying an existing SPI slave node in DT?

Looking at the I2C code it seems like it's using
of_node_test_and_set_flag() to check for OF_POPULATED before
instantiating, doing that manually in every place where it might
instantiate a device and manually clearing when deinstantiating.

I have to say I don't entirely understand the logic behind how this
stuff is supposed to work, it's confusing to me why we have separate
dynamic and static instantiation paths in the first place or why this is
open coded in the buses.  It seems like a more robust thing here is to
always use the dynamic path even on static instantiation, or to move it
more into the driver core.

Ideally I'd like to see the I2C code factored out into the DT core but
otherwise probably we have to cut'n'paste it.


signature.asc
Description: PGP signature

Dynamically adding SPI buses (was: Re: [PATCH v8 0/8] Device Tree Overlays - 8th time's the charm)

[Geert Uytterhoeven]

Hi Mike,

(replaying to an old mail, as I'm seeing the exact same behavior with current
 overlay code)

On Thu, Nov 13, 2014 at 9:10 PM, Michael Fiore  wrote:
> I have been doing some testing with the overlay patches and, while it
> is working in general, I have noticed a couple of issues.
>
> I am using the following patchsets in conjunction with an updated DTC 
> compiler:
>
> * Device Tree Overlays (v8)
>
> * of: Resolver and dynamic updates
>
> * configfs: Implement binary attributes (v3)
>
> I have applied all 3 of the patchsets against rev
> f7e87a44ef60ad379e39b45437604141453bf0ec of the linux source tree.
> This is the rev that was specified in the submission of the v8 Device
> Tree Overlay patchset.
>
> My base dtb has a SPI bus set up, including chip selects, but
> disabled.  My overlay dtb enables that bus and adds 3 spi devices. My
> overlay is installed in /lib/firmware/port1_gpio.dtbo. The relevant
> portion of my base dtb follows:
>
>  91 /* runs to Accessory Port 1 */
>  92 spi0: spi@f000 {
>  93 status = "disabled";
>  94 cs-gpios = <&pioA 4 0>, <&pioA 2 0>, <&pioA 5 0>, <0>;
>  95 };
>
> Overlay contents are as follows:
>
> /dts-v1/;
> /plugin/;
>
> /* enable spi0 for mts-io */
>
> / {
> fragment@0 {
> target-path = "/ahb/apb/spi@f000";
> __overlay__ {
> status = "okay";
>
> ap1-cs0@0 {
> compatible = "mts-io-ap1-adc";
> spi-max-frequency = <2000>;
> reg = <0>;
> };
> ap1-cs1@1 {
> compatible = "mts-io-ap1-dout";
> spi-max-frequency = <100>;
> reg = <1>;
> };
> ap1-cs2@2 {
> compatible = "mts-io-ap1-din";
> spi-max-frequency = <100>;
> reg = <2>;
> };
> };
> };
> };
>
> I have added the following patch in order to more easily demonstrate
> what I've observed. This change affects the function spi_add_device()
>
> Index: git/drivers/spi/spi.c
> ===
> --- git.orig/drivers/spi/spi.c 2014-11-13 07:41:14.424270598 -0600
> +++ git/drivers/spi/spi.c 2014-11-13 08:34:24.700331795 -0600
> @@ -424,6 +424,8 @@
>   /* Set the bus ID string */
>   spi_dev_set_name(spi);
>
> + dev_info(dev, "adding spi device - chip select [%d]", spi->chip_select);
> +
>   /* We need to make sure there's no other device with this
>   * chipselect **BEFORE** we call setup(), else we'll trash
>   * its configuration.  Lock against concurrent add() calls.
>
> Applying the overlay from above gives the following output:
>
> root@mtr2d2:~# mount -t configfs none /config/
> root@mtr2d2:~# cd /config/device-tree/overlays/
> root@mtr2d2:/config/device-tree/overlays# mkdir port1
> root@mtr2d2:/config/device-tree/overlays# echo port1_gpio.dtbo > port1/path
> atmel_spi f000.spi: version: 0x212
> atmel_spi f000.spi: Using dma0chan2 (tx) and dma0chan3 (rx) for
> DMA transfers
> atmel_spi f000.spi: Atmel SPI Controller at 0xf000 (irq 142)
> atmel_spi f000.spi: adding spi device - chip select [2]
> atmel_spi f000.spi: adding spi device - chip select [1]
> atmel_spi f000.spi: adding spi device - chip select [0]
> atmel_spi f000.spi: adding spi device - chip select [0]
> atmel_spi f000.spi: chipselect 0 already in use
> spi_master spi32766: spi_device register error /ahb/apb/spi@f000/ap1-cs0@0
> of_spi_notify: failed to create for '/ahb/apb/spi@f000/ap1-cs0@0'
> __of_changeset_entry_notify: notifier error @/ahb/apb/spi@f000/ap1-cs0@0
> atmel_spi f000.spi: adding spi device - chip select [1]
> atmel_spi f000.spi: chipselect 1 already in use
> spi_master spi32766: spi_device register error /ahb/apb/spi@f000/ap1-cs1@1
> of_spi_notify: failed to create for '/ahb/apb/spi@f000/ap1-cs1@1'
> __of_changeset_entry_notify: notifier error @/ahb/apb/spi@f000/ap1-cs1@1
> atmel_spi f000.spi: adding spi device - chip select [2]
> atmel_spi f000.spi: chipselect 2 already in use
> spi_master spi32766: spi_device register error /ahb/apb/spi@f000/ap1-cs2@2
> of_spi_notify: failed to create for '/ahb/apb/spi@f000/ap1-cs2@2'
> __of_changeset_entry_notify: notifier error @/ahb/apb/spi@f000/ap1-cs2@2
>
> It appears that the spi devices are getting added twice.  Despite the
> warnings and errors from the overlay driver and the spi subsystem, my
> spi devices are working properly.
>
> Attempts to apply additional overlays succeed, but generate an additional 
> error:
>
> root@mtr2d2:/config/device-tree/overlays# mkdir port2
> root@mtr2d2:/config/device-tree/overlays# echo port2_gpio.dtbo > port2/path
> atmel_spi f0004000.spi: version: 0x212
> atmel_spi f0004000.spi: Using dma1chan0 (tx) and dma1chan1 (rx) for
> DMA transfers
> atmel_spi f0004000.spi: Atmel SPI Controller a

Re: [alsa-devel] [PATCH 2/2] ASoC: pcm3168a: Add driver for pcm3168a codec

[Mark Brown]

On Tue, Nov 24, 2015 at 02:43:44PM +, Damien Horsley wrote:
> From: "Damien.Horsley" 
> 
> Add driver for Texas Instruments pcm3168a codec

Please try to keep your CC lists reasonable - only CC people who have an
interest in the patch you're posting.  The CC list you have here is far
too broad, I can't figure out why a lot of the people there ended up
there.  If you've got 10 people that's generally a warning sign.

Overall this looks good but there are a few smallish issues below:

> + if ((!slave_mode || (fmt & PCM3168A_FMT_DSP_MASK)) &&
> + (format == SNDRV_PCM_FORMAT_S24_3LE)) {
> + dev_err(codec->dev, "48-bit frames not supported in master mode 
> or slave mode using DSP(A/B)\n");

You've got a lot of weird indentation with the second line of multi-line
if conditionals massively further indented than I'd expect.  These
conditionals all also seem more complex than they should be - the fact
that you're using so many !slave_modes makes me think that you should
have a flag for master mode and...

> + if ((!slave_mode || ((fmt != PCM3168A_FMT_RIGHT_J) &&
> + (fmt != PCM3168A_FMT_LEFT_J))) &&
> + (format == SNDRV_PCM_FORMAT_S16)) {

...especially with things like this the indentation makes it hard to
tell what bits go together.

> + val = slave_mode ? 0 : ((i + 1) << shift);

Please write normal if statements unless there's a strong reason to use
the ternery operator.

> + /*
> +  * Justification has no effect for S32 and S16 as the whole frame
> +  * is filled with the samples, but the register field
> +  * must be set to a specific value for correct operation
> +  */
> + if ((fmt == PCM3168A_FMT_RIGHT_J) &&
> + (format == SNDRV_PCM_FORMAT_S32)) {
> + fmt = PCM3168A_FMT_LEFT_J;
> + } else if (format == SNDRV_PCM_FORMAT_S16) {
> + fmt = PCM3168A_FMT_RIGHT_J_16;
> + }

Being in right justified mode *does* have an effect - it changes where
the audio data starts relative to LRCLK.  It is true that if the frame
has exactly the right number of clocks left and right justified are
identical but extra clocks are in general permitted so it looks like
your right justified case above just isn't something the device really
supports.

> + pcm3168a->scki = devm_clk_get(dev, "scki");
> + if (IS_ERR(pcm3168a->scki)) {
> + if (PTR_ERR(pcm3168a->scki) != -EPROBE_DEFER)
> + dev_err(dev, "failed to acquire clock 'scki'\n");

Please print the error code as well, it may help people understand the
problem.

> + ret = snd_soc_register_codec(dev, &pcm3168a_driver, pcm3168a_dais,
> + ARRAY_SIZE(pcm3168a_dais));
> + if (ret) {
> + dev_err(dev, "failed to register codec: %d\n", ret);
> + goto err_regulator;
> + }
> +
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> + pm_runtime_idle(dev);

You should enable runtime PM before registering the CODEC since the core
can do runtime PM operations and if it tries before runtime PM is
enabled things will get unbalanced.

> +#define PCM3168A_DOUBLE_STS(xname, reg, shift_left, shift_right, max, 
> invert) \
> +{\
> + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = (xname),   \
> + .info = snd_soc_info_volsw, .get = snd_soc_get_volsw,   \
> + .put = snd_soc_put_volsw,   \
> + .access = SNDRV_CTL_ELEM_ACCESS_READ |  \
> + SNDRV_CTL_ELEM_ACCESS_VOLATILE, \
> + .private_value = SOC_DOUBLE_VALUE(reg, shift_left, shift_right, \
> + max, invert, 0) \
> +}

This doesn't look like it should be driver specific - what's driver
specific about it?


signature.asc
Description: PGP signature

Re: [PATCH v2 4/9] Documentation: dt-bindings: regulator: add LM363x regulator binding information

[Mark Brown]

On Thu, Nov 26, 2015 at 03:57:00PM +0900, Milo Kim wrote:
> This binding describes LM3631 and LM3632 regulator properties.

Please use subject lines matching the style for the subsystem.


signature.asc
Description: PGP signature

Re: [RESEND RFC/PATCH 3/8] media: platform: mtk-vpu: Support Mediatek VPU

[Daniel Thompson]

On 27/11/15 12:10, andrew-ct chen wrote:

+
> >+  memcpy((void *)send_obj->share_buf, buf, len);
> >+  send_obj->len = len;
> >+  send_obj->id = id;
> >+  vpu_cfg_writel(vpu, 0x1, HOST_TO_VPU);
> >+
> >+  /* Wait until VPU receives the command */
> >+  timeout = jiffies + msecs_to_jiffies(IPI_TIMEOUT_MS);
> >+  do {
> >+  if (time_after(jiffies, timeout)) {
> >+  dev_err(vpu->dev, "vpu_ipi_send: IPI timeout!\n");
> >+  return -EIO;
> >+  }
> >+  } while (vpu_cfg_readl(vpu, HOST_TO_VPU));

>
>Do we need to busy wait every time we communicate with the co-processor?
>Couldn't we put this wait*before*  we write to HOST_TO_VPU above.
>
>That way we only spin when there is a need to.
>

Since the hardware VPU only allows that one client sends the command to
it each time.
We need the wait to make sure VPU accepted the command and cleared the
interrupt and then the next command would be served.


I understand that the VPU  can only have on message outstanding at once.

I just wonder why we busy wait *after* sending the first command rather 
than *before* sending the second one.


Streamed decode/encode typically ends up being rate controlled by 
capture or display meaning that in these cases we don't need to busy 
wait at all (because by the time we send the next frame the VPU has 
already accepted the previous message).



Daniel.

--
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: [RESEND RFC/PATCH 3/8] media: platform: mtk-vpu: Support Mediatek VPU

[andrew-ct chen]

Thanks a lot for your review comments.

On Wed, 2015-11-25 at 16:11 +, Daniel Thompson wrote:
> On 17/11/15 12:54, Tiffany Lin wrote:
> > From: Andrew-CT Chen 
> >
> > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> > It is able to handle video decoding/encoding of in a range of formats.
> > The driver provides with VPU firmware download, memory management and
> > the communication interface between CPU and VPU.
> > For VPU initialization, it will create virtual memory for CPU access and
> > IOMMU address for vcodec hw device access. When a decode/encode instance
> > opens a device node, vpu driver will download vpu firmware to the device.
> > A decode/encode instant will decode/encode a frame using VPU
> > interface to interrupt vpu to handle decoding/encoding jobs.
> >
> > Signed-off-by: Andrew-CT Chen 
> > ---
> >   drivers/media/platform/Kconfig |6 +
> >   drivers/media/platform/Makefile|2 +
> >   drivers/media/platform/mtk-vpu/Makefile|1 +
> >   .../platform/mtk-vpu/h264_enc/venc_h264_vpu.h  |  127 +++
> >   .../media/platform/mtk-vpu/include/venc_ipi_msg.h  |  212 +
> >   drivers/media/platform/mtk-vpu/mtk_vpu_core.c  |  823 
> > 
> >   drivers/media/platform/mtk-vpu/mtk_vpu_core.h  |  161 
> >   .../media/platform/mtk-vpu/vp8_enc/venc_vp8_vpu.h  |  119 +++
> >   8 files changed, 1451 insertions(+)
> >   create mode 100644 drivers/media/platform/mtk-vpu/Makefile
> >   create mode 100644 drivers/media/platform/mtk-vpu/h264_enc/venc_h264_vpu.h
> >   create mode 100644 drivers/media/platform/mtk-vpu/include/venc_ipi_msg.h
> >   create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu_core.c
> >   create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu_core.h
> >   create mode 100644 drivers/media/platform/mtk-vpu/vp8_enc/venc_vp8_vpu.h
> >
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index ccbc974..f98eb47 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -148,6 +148,12 @@ config VIDEO_CODA
> >Coda is a range of video codec IPs that supports
> >H.264, MPEG-4, and other video formats.
> >
> > +config MEDIATEK_VPU
> > +   bool "Mediatek Video Processor Unit"
> > +   ---help---
> > +   This driver provides downloading firmware vpu and
> > +   communicating with vpu.
> > +
> 
> This looks pretty broken.
> 
> Shouldn't this option be tristate? Why are there no depends-on or selects?
> 

Yes, this should be tristate and depends on VIDEO_DEV && VIDEO_V4L2 &&
ARCH_MEDIATEK

> Also I think the help text could be more descriptive here (and so does 
> checkpatch ;-) ).
> 

I'll put more descriptive. Thanks.

> 
> > diff --git a/drivers/media/platform/mtk-vpu/h264_enc/venc_h264_vpu.h 
> > b/drivers/media/platform/mtk-vpu/h264_enc/venc_h264_vpu.h
> > new file mode 100644
> > index 000..9c8ebdd
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vpu/h264_enc/venc_h264_vpu.h
> 
> Why is this file included in *this* patch? It is not included by 
> anything in the patch and defines functions that do not exist yet.

I'll move this to the h264 patch.Thanks

> 
> 
> > diff --git a/drivers/media/platform/mtk-vpu/include/venc_ipi_msg.h 
> > b/drivers/media/platform/mtk-vpu/include/venc_ipi_msg.h
> > new file mode 100644
> > index 000..a345b98
> 
> This file also is not included by anything and should, perhaps be 
> included in a different patch.
> 

I'll move this to the v4l2 encoder patch.

> 
> > diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu_core.c 
> > b/drivers/media/platform/mtk-vpu/mtk_vpu_core.c
> > new file mode 100644
> > index 000..b524dbc
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vpu/mtk_vpu_core.c
> > @@ -0,0 +1,823 @@
> > +/*
> > +* Copyright (c) 2015 MediaTek Inc.
> > +* Author: Andrew-CT Chen 
> > +*
> > +* 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 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "mtk_vpu_core.h"
> > +
> > +/**
> > + * VPU (video processor unit) is a tiny processor controlling video 
> > hardware
> > + * related to video codec, scaling and color format converting.
> > + * VPU interfaces with other blocks by share memory and interrupt.
> > + **/
> > +#define MTK_VPU_DRV_NAME   "mtk_vpu"
> 
> This is only used once, why not just put this string directly into the 
> .nam

Re: [PATCH V5 RESEND 2/3] iommu/hisilicon: Add hi6220-SoC smmu driver

[Joerg Roedel]

On Fri, Nov 20, 2015 at 10:25:08AM +0800, Chen Feng wrote:
> +config HI6220_IOMMU
> + bool "Hi6220 IOMMU Support"
> + depends on ARM64
> + select IOMMU_API
> + select IOMMU_IOVA
> + help
> +   Enable IOMMU Driver for hi6220 SoC. The IOMMU API and IOMMU IOVA
> +   is also selected.

The last sentence is of little help for the user. Better put the reasons
in here when a user should select this option.

> + /*set axi id*/

Coding style nit: Please write these oneline comments with spaces, like
this:

/* set axi id */

> +static int hi6220_smmu_attach_dev(struct iommu_domain *domain,
> +   struct device *dev)
> +{
> + dev->archdata.iommu = &iova_allocator;
> +
> + return 0;
> +}
> +
> +static void hi6220_smmu_detach_dev(struct iommu_domain *domain,
> +struct device *dev)
> +{
> + dev->archdata.iommu = NULL;
> +}

This basically means that this driver only supports one domain, right?
That is not compatible with the iommu-api requirements.

You need to create an iommu-group per smmu in your system and put all
devices translated by this smmu in that group. And then you must change
your code to allow attaching/detaching this iommu-group to different
domains.


Joerg

--
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 RESEND 0/3] Add iommu support for hi6220 HiKey board

[Joerg Roedel]

On Fri, Nov 20, 2015 at 10:25:06AM +0800, Chen Feng wrote:
> eg:
> struct iommu_domain *domain = iommu_domain_alloc(bus);
> iommu_attach_device(domain, dev);
> struct iova_domain *iovad = (struct iova_domain *)m_dev->archdata.iommu;
> struct iova * t_iova = alloc_iova(iovad, size, limit_pfn, align);
> iommu_map(domain, t_iova->pfn_lo << 12, phy_addr, size, port);

Any reason the media subsystem should use the iommu-api directly, and
not the dma-api? You can make your iommu available by adapting the
common dma-iommu implementation from Robin Murphy to your iommu to make
it usable through the dma-api.


Joerg

--
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 8/9] leds: add LM3633 driver

[Jacek Anaszewski]

Hi Milo,

Thanks for the update. I have few comments below.

On 11/26/2015 07:57 AM, Milo Kim wrote:

LM3633 LED driver supports generic LED functions and pattern generation.
Pattern is generated through the sysfs. ABI documentation is also added.

Device creation from device tree

   LED channel name, LED string usage and max current settings are
   configured inside the DT.

LED dimming pattern generation
--
   LM3633 supports programmable dimming pattern generator.
   To enable it, eight attributes are used. Sysfs ABI describes it.
   - Time domain
 : 'pattern_time_delay', 'pattern_time_rise', 'pattern_time_high',
   'pattern_time_fall' and 'pattern_time_low'.
   - Level domain
 : 'pattern_brightness_low' and 'pattern_brightness_high'.
   - Start or stop
 : 'run_pattern'

LMU fault monitor event handling

   As soon as LMU fault monitoring is done, LMU device is reset. So LED
   device should be reinitialized. lm3633_led_fault_monitor_notifier() is
   used for this purpose.

Data structure
--
   ti_lmu_led: LED output channel data.
   ti_lmu_led_chip:LED device data. One LED device can have multiple
   LED channel data.

Cc: Jacek Anaszewski 
Cc: linux-l...@vger.kernel.org
Cc: Lee Jones 
Cc: Mark Brown 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
  Documentation/ABI/testing/sysfs-class-led-lm3633 |  97 +++
  drivers/leds/Kconfig |  10 +
  drivers/leds/Makefile|   1 +
  drivers/leds/leds-lm3633.c   | 840 +++
  4 files changed, 948 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-class-led-lm3633
  create mode 100644 drivers/leds/leds-lm3633.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-lm3633 
b/Documentation/ABI/testing/sysfs-class-led-lm3633
new file mode 100644
index 000..46217d4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-lm3633
@@ -0,0 +1,97 @@
+LM3633 LED driver generates programmable pattern via the sysfs.
+
+LED Pattern Generator Structure
+
+(3)
+  (a) --->  ___
+   /   \
+  (2) / \ (4)
+  (b) > _/   \_  ...
+   (1)   (5)
+
+ |<-   period   -> |
+
+What:  /sys/class/leds//pattern_time_delay
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern startup delay. Please refer to (1).
+Range is from 0 to 9700. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_time_rise
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern rising dimming time. Please refer to (2).
+Range is from 0 to 16000. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_time_high
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern high level time. Please refer to (3).
+It means how much time stays at high level.
+Range is from 0 to 9700. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_time_fall
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern falling dimming time. Please refer to (4).
+Range is from 0 to 16000. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_time_low
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern low level time. Please refer to (5).
+It means how much time stays at low level.
+Range is from 0 to 9700. Unit is millisecond.
+
+What:  /sys/class/leds//pattern_brightness_high
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern brightness value at high level.
+Please refer to (a). Range is from 0 to max brightness value.
+
+What:  /sys/class/leds//pattern_brightness_low
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+Set pattern brightness value at low level.
+Please refer to (b). Range is from 0 to max brightness value.
+
+What:  /sys/class/leds//run_pattern
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Milo Kim 
+Description:   write only
+It is used for activating or deactivating programmed LED
+dimming pattern. Please make sure pattern parameters
+should be wri

Re: [PATCH v2 3/9] Documentation: dt-bindings: leds: add LM3633 LED binding information

[Jacek Anaszewski]

Hi Milo,

On 11/26/2015 07:56 AM, Milo Kim wrote:

LM3633 LED device is one of TI LMU device list.

Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Cc: Lee Jones 
Cc: Jacek Anaszewski 
Cc: Mark Brown 
Cc: linux-l...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
  .../devicetree/bindings/leds/leds-lm3633.txt   | 24 ++
  1 file changed, 24 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
new file mode 100644
index 000..a553894
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
@@ -0,0 +1,24 @@
+TI LMU LM3633 LED device tree bindings
+
+Required properties:
+  - compatible: "ti,lm3633-leds"
+
+Child nodes:
+  Each node matches with LED control bank.
+  Please refer to the datasheet [1].


leds/common.txt documentation says that child nodes represent discrete
LED elements.


+  Required properties of a child node:
+  - led-sources: List of enabled channels from 0 to 5.
+ Please refer to LED binding [2].


led-sources property should contain always one element -
a control bank identifier that the iout is to be associated with.
For example, if there are three LEDs and they should be controlled
with control bank A, then the bindings should look as follows
(assuming that control bank identifiers start from 0 [A:0, B:1,
C:2, etc. - it has to be also explicitly stated in the documentation]:

lvled1 {
led-sources = <2>;
led-max-microamp = <1000>;
}

lvled2 {
led-sources = <2>;
led-max-microamp = <29000>;
}

lvled3 {
led-sources = <2>;
led-max-microamp = <7000>;
}

The driver should expose singled LED class device for this arrangement.

Since all of these LEDs will be controlled by the common bank, the
lowest led-max-micromp constraint value from the three should be taken
as a base for calculating max_brightness property of the LED class
device. Of course in the sane case all these properties should have
the same values.

If the LEDs are to be connected to separate banks, then DT child nodes
should look e.g. as follows (led-max-microamp values are set
arbitrarily here):

lvled4 {
led-sources = <6>;
led-max-microamp = <2>;
}

lvled5 {
led-sources = <7>;
led-max-microamp = <17000>;
}

lvled6 {
led-sources = <8>;
led-max-microamp = <11000>;
}

You can of course add label properties to the child nodes.
LED class device name could be composed out of LED names
separated with colon, so here it would be:

lvled4:levled5:lvled6


+  Optional properties of a child node:
+  - label: LED channel identification. Please refer to LED binding [2].
+  - led-max-microamp: Max current setting. Type is .
+  Unit is microampere. Range is from 5000 to 3.
+  Step is 1000. Please refer to LED binding [2].
+
+Example: Please refer to ti-lmu dt-bindings [3].
+
+[1] http://www.ti.com/product/LM3633/datasheet
+[2] ../leds/common.txt
+[2] ../mfd/ti-lmu.txt


Last index should be [3] and all references above should be corrected
accordingly.

--
Best Regards,
Jacek Anaszewski
--
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: [linux-sunxi] Re: [PATCH v3 1/2] phy-sun4i-usb: Use of_match_node to get model specific config data

[Hans de Goede]

Hi,

On 27-11-15 11:37, Hans de Goede wrote:

Hi,

On 27-11-15 09:53, Maxime Ripard wrote:

On Thu, Nov 26, 2015 at 01:11:32PM +0100, Hans de Goede wrote:

+enum sun4i_usb_phy_type {
+   sun4i_a10_phy,
+   sun8i_a33_phy,
+};
+
+struct sun4i_usb_phy_cfg {
+   int num_phys;
+   u32 disc_thresh;
+   enum sun4i_usb_phy_type type;
+   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;
@@ -164,12 +174,15 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
*phy, u32 addr, u32 data,

 mutex_lock(&phy_data->mutex);

-   if (phy_data->has_a33_phyctl) {
+   switch (phy_data->cfg->type) {
+   case sun4i_a10_phy:
+   phyctl = phy_data->base + REG_PHYCTL_A10;


Any reason why this offset isn't incorporated into phy_data?


You mean in phy_data->cfg I assume, the difference needed for
the "sun4i_usb_phy_write" functionality are not just the phyctl
register offset...




+   break;
+   case sun8i_a33_phy:
 phyctl = phy_data->base + REG_PHYCTL_A33;
 /* A33 needs us to set phyctl to 0 explicitly */
 writel(0, phyctl);


e.g. the A33 needs this extra write, and on the H3 we need to do
similar bitbanging, but slightly different, see:

https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/usb/host/sunxi_hci.c#L899

Notice how it uses different addr and write register addresses
their through the usb_phy_csr_add and usb_phy_csr_write helper
functions as well as directly poking offset 0x20.


Then it easy to support: one u8 for each register that changes, one
bool to tell if you need to clear the phyctl register or not, And you
don't have to duplicate the switch everywhere, and basically just
reimplement of_device_is_compatible without an actual compatible to
workaround the review ;)


You clearly have not looked at the actual code I've linked to, the
entire "algorithm" for sun4i_usb_phy_write is different on the H3.

Moreover, this has nothing to do with this patch, the code coding the
difference behavior for the a10 style phy and the a33 style phy is already
there before this patch-set, and this is not something Kishon asked
me to change.


And on top of that phy_data->cfg->type is also used in different places,
where the behavior for h3 is again completely different then for the other
phy-s. There are just some differences which cannot be encoded in the form
of register offsets or bools between the old a10 usb phys and the newer ones.

And yes I've considered to just do a whole new phy driver, but there is enough
overlap to make doing this in one driver more sensible. This may change when
we add otg support for the H3. But we can always do a new driver then, and
remove the limited (see the 2nd patch in this series) amount of changes needed
for the H3 from phy-sun4i-usb.c again.

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: [linux-sunxi] Re: [PATCH v3 1/2] phy-sun4i-usb: Use of_match_node to get model specific config data

[Hans de Goede]

Hi,

On 27-11-15 09:53, Maxime Ripard wrote:

On Thu, Nov 26, 2015 at 01:11:32PM +0100, Hans de Goede wrote:

+enum sun4i_usb_phy_type {
+   sun4i_a10_phy,
+   sun8i_a33_phy,
+};
+
+struct sun4i_usb_phy_cfg {
+   int num_phys;
+   u32 disc_thresh;
+   enum sun4i_usb_phy_type type;
+   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;
@@ -164,12 +174,15 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
*phy, u32 addr, u32 data,

 mutex_lock(&phy_data->mutex);

-   if (phy_data->has_a33_phyctl) {
+   switch (phy_data->cfg->type) {
+   case sun4i_a10_phy:
+   phyctl = phy_data->base + REG_PHYCTL_A10;


Any reason why this offset isn't incorporated into phy_data?


You mean in phy_data->cfg I assume, the difference needed for
the "sun4i_usb_phy_write" functionality are not just the phyctl
register offset...




+   break;
+   case sun8i_a33_phy:
 phyctl = phy_data->base + REG_PHYCTL_A33;
 /* A33 needs us to set phyctl to 0 explicitly */
 writel(0, phyctl);


e.g. the A33 needs this extra write, and on the H3 we need to do
similar bitbanging, but slightly different, see:

https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/usb/host/sunxi_hci.c#L899

Notice how it uses different addr and write register addresses
their through the usb_phy_csr_add and usb_phy_csr_write helper
functions as well as directly poking offset 0x20.


Then it easy to support: one u8 for each register that changes, one
bool to tell if you need to clear the phyctl register or not, And you
don't have to duplicate the switch everywhere, and basically just
reimplement of_device_is_compatible without an actual compatible to
workaround the review ;)


You clearly have not looked at the actual code I've linked to, the
entire "algorithm" for sun4i_usb_phy_write is different on the H3.

Moreover, this has nothing to do with this patch, the code coding the
difference behavior for the a10 style phy and the a33 style phy is already
there before this patch-set, and this is not something Kishon asked
me to change.

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

[PATCH v4 1/3] arm64: dts: mt8173: Add thermal zone node.

[Dawei Chien]

This adds thermal zone node to Mediatek MT8173 dtsi file.

Signed-off-by: Dawei Chien 
---
This patch is based on patchset:
https://lkml.org/lkml/2015/11/18/84
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   43 ++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index fda805d..4114cee 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -188,6 +188,49 @@
clock-output-names = "cpum_ck";
};
 
+   thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <1000>; /* milliseconds */
+
+   thermal-sensors = <&thermal 0>;
+   sustainable-power = <1500>; /* milliwatts */
+
+   trips {
+   threshold: trip-point@0 {
+   temperature = <68000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   target: trip-point@1 {
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   cpu_crit: cpu_crit@0 {
+   temperature = <115000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map@0 {
+   trip = <&target>;
+   cooling-device = <&cpu0 0 0>;
+   contribution = <1024>;
+   };
+   map@1 {
+   trip = <&target>;
+   cooling-device = <&cpu2 0 0>;
+   contribution = <2048>;
+   };
+   };
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
-- 
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

[PATCH v4 3/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Dawei Chien]

MT8173 cpufreq driver use of_cpufreq_power_cooling_register registering
cooling devices with dynamic power coefficient.

Signed-off-by: Dawei Chien 
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/17/251
---
 drivers/cpufreq/mt8173-cpufreq.c |   28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c
index 83001dc..4d39468 100644
--- a/drivers/cpufreq/mt8173-cpufreq.c
+++ b/drivers/cpufreq/mt8173-cpufreq.c
@@ -263,24 +263,34 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy 
*policy,
return 0;
 }
 
+#define DYNAMIC_POWER "dynamic-power-coefficient"
+
 static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
 {
struct mtk_cpu_dvfs_info *info = policy->driver_data;
struct device_node *np = of_node_get(info->cpu_dev->of_node);
+   u32 capacitance;
 
if (WARN_ON(!np))
return;
 
if (of_find_property(np, "#cooling-cells", NULL)) {
-   info->cdev = of_cpufreq_cooling_register(np,
-policy->related_cpus);
+   if (!info->cdev) {
+   of_property_read_u32(np, DYNAMIC_POWER, &capacitance);
+
+   info->cdev = of_cpufreq_power_cooling_register(np,
+   policy->related_cpus,
+   capacitance,
+   NULL);
 
-   if (IS_ERR(info->cdev)) {
-   dev_err(info->cpu_dev,
-   "running cpufreq without cooling device: %ld\n",
-   PTR_ERR(info->cdev));
+   if (IS_ERR(info->cdev)) {
+   dev_err(info->cpu_dev,
+   "running cpufreq without cooling 
device: %ld\n",
+   PTR_ERR(info->cdev));
 
-   info->cdev = NULL;
+   info->cdev = NULL;
+   }
}
}
 
@@ -460,7 +470,9 @@ static int mtk_cpufreq_exit(struct cpufreq_policy *policy)
 {
struct mtk_cpu_dvfs_info *info = policy->driver_data;
 
-   cpufreq_cooling_unregister(info->cdev);
+   if (info->cdev)
+   cpufreq_cooling_unregister(info->cdev);
+
dev_pm_opp_free_cpufreq_table(info->cpu_dev, &policy->freq_table);
mtk_cpu_dvfs_info_release(info);
kfree(info);
-- 
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

[PATCH v4 2/3] arm64: dts: mt8173: Add dynamic power node.

[Dawei Chien]

This device node is for calculating dynamic power in mW.
Since mt8173 has two clusters, there are two dynamic power
coefficient as well.

Signed-off-by: Dawei Chien 
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/17/251
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 4114cee..33fabe4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -71,6 +71,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+   dynamic-power-coefficient = <263>;
};
 
cpu1: cpu@1 {
@@ -95,6 +96,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+   dynamic-power-coefficient = <263>;
};
 
cpu2: cpu@100 {
@@ -119,6 +121,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+   dynamic-power-coefficient = <530>;
};
 
cpu3: cpu@101 {
@@ -143,6 +146,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+   dynamic-power-coefficient = <530>;
};
 
idle-states {
-- 
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

[PATCH v4 0/3] thermal: mediatek: Add cpu power cooling model

[Dawei Chien]

Use Intelligent Power Allocation (IPA) technical to add dynamic power model
for binding CPU thermal zone. The power allocator governor allocates power
budget to control CPU temperature.

Power Allocator governor is able to keep SOC temperature within a defined
temperature range to avoid SOC overheat and keep it's performance.
mt8173-cpufreq.c need to register its' own power model with power allocator
thermal governor, so that power allocator governor can allocates suitable
power budget to control CPU temperature.

Binging document is refer to this patchset
https://lkml.org/lkml/2015/11/17/251

Change since V1:
1. Include mt8171.h and sort header file for mt8173.dtsi

Change since V2:
1. Move dynamic/static power model in device tree

Change since V3:
1. Remove static power model.
2. Split V3's device tree in two for thermal zones and dynamic power models 
respectively.

Dawei Chien (3):
  arm64: dts: mt8173: Add thermal zone node for mt8173 platform.
  arm64: dts: mt8173: Add dynamic power node for mt8173 platform.
  thermal: mediatek: Add cpu dynamic power cooling model.

 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   47 ++
 drivers/cpufreq/mt8173-cpufreq.c |   28 +-
 2 files changed, 67 insertions(+), 8 deletions(-)

--
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: [linux-sunxi] Re: [PATCH v3 1/2] phy-sun4i-usb: Use of_match_node to get model specific config data

[Maxime Ripard]

On Thu, Nov 26, 2015 at 01:11:32PM +0100, Hans de Goede wrote:
> >>+enum sun4i_usb_phy_type {
> >>+   sun4i_a10_phy,
> >>+   sun8i_a33_phy,
> >>+};
> >>+
> >>+struct sun4i_usb_phy_cfg {
> >>+   int num_phys;
> >>+   u32 disc_thresh;
> >>+   enum sun4i_usb_phy_type type;
> >>+   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;
> >>@@ -164,12 +174,15 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> >>*phy, u32 addr, u32 data,
> >>
> >> mutex_lock(&phy_data->mutex);
> >>
> >>-   if (phy_data->has_a33_phyctl) {
> >>+   switch (phy_data->cfg->type) {
> >>+   case sun4i_a10_phy:
> >>+   phyctl = phy_data->base + REG_PHYCTL_A10;
> >
> >Any reason why this offset isn't incorporated into phy_data?
> 
> You mean in phy_data->cfg I assume, the difference needed for
> the "sun4i_usb_phy_write" functionality are not just the phyctl
> register offset...
> 
> >
> >>+   break;
> >>+   case sun8i_a33_phy:
> >> phyctl = phy_data->base + REG_PHYCTL_A33;
> >> /* A33 needs us to set phyctl to 0 explicitly */
> >> writel(0, phyctl);
> 
> e.g. the A33 needs this extra write, and on the H3 we need to do
> similar bitbanging, but slightly different, see:
> 
> https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/usb/host/sunxi_hci.c#L899
> 
> Notice how it uses different addr and write register addresses
> their through the usb_phy_csr_add and usb_phy_csr_write helper
> functions as well as directly poking offset 0x20.

Then it easy to support: one u8 for each register that changes, one
bool to tell if you need to clear the phyctl register or not, And you
don't have to duplicate the switch everywhere, and basically just
reimplement of_device_is_compatible without an actual compatible to
workaround the review ;)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Michael Trimarchi]

Hi

On Fri, Nov 27, 2015 at 9:44 AM, Michael Trimarchi
 wrote:
> Hi
>
> On Fri, Nov 27, 2015 at 9:38 AM, Pali Rohár  wrote:
>> On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
>>> Just to explore options.. How about make a minimal device driver that
>>> just loads the atags blob from /lib/firmware and then shows it in
>>> /proc/atags? Of course some checking on the atags should be done by
>>> the driver..
>>
>> And who can dynamically create that blob file in /lib/firmware? If
>> kernel does not export those atags (somehow) from bootloader, then
>> userspace is not able to create that blob... cyclic problem.
>>
>
> Are those atags from bootloader fix or they change device by device. If they
> are fixed they can be included in some firmware and get from the disk.
>

Sorry, miss the second part of email ;)

Michael

> Michael
>
>> So no, problem is that bootloader provides via custom atags dynamic
>> information like: boot reason (how was device started, by rtc alarm? by
>> reboot? by usb charger? by power button?), boot mode (should be enter
>> into firmware update mode?, is this normal boot mode?), ... and those
>> information are needed for some proprietary software (e.g. firmware
>> upgrade/flash) but also by any other open source applications (based on
>> usb charger we enter different runlevel -- for just only charging
>> device).
>>
>> --
>> Pali Rohár
>> pali.ro...@gmail.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
--
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 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Jisheng Zhang]

On Fri, 27 Nov 2015 16:39:37 +0800
Jisheng Zhang wrote:

> On Fri, 27 Nov 2015 08:51:27 +0100
> Sebastian Hesselbarth wrote:
> 
> > On 24.11.2015 03:35, Jisheng Zhang wrote:  
> > > On Mon, 23 Nov 2015 16:54:44 +0800
> > > Jisheng Zhang wrote:
> > >> On Mon, 23 Nov 2015 09:30:42 +0100
> > >> Sebastian Hesselbarth wrote:
> > >>> On 23.11.2015 08:21, Jisheng Zhang wrote:
> >  On Fri, 20 Nov 2015 22:06:59 +0100
> >  Sebastian Hesselbarth wrote:
> > > On 20.11.2015 09:42, Jisheng Zhang wrote:
> > >> Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.
> > >>
> > >> Signed-off-by: Jisheng Zhang 
> > >> ---
> > >>> [...]
> > >> +syspll: syspll {
> > >> +compatible = "marvell,berlin-pll";
> > >> +reg = <0xea0200 0x14>, <0xea0710 4>;
> > >> +#clock-cells = <0>;
> > >> +clocks = <&osc>;
> > >> +bypass-shift = /bits/ 8 <0>;
> > >> +};
> > >> +
> > >> +gateclk: gateclk {
> > >> +compatible = "marvell,berlin4ct-gateclk";
> > >> +reg = <0xea0700 4>;
> > >> +#clock-cells = <1>;
> > >> +};
> > >> +
> > >> +clk: clk {
> > >> +compatible = "marvell,berlin4ct-clk";
> > >> +reg = <0xea0720 0x144>;
> > >
> > > Looking at the reg ranges, I'd say that they are all clock related
> > > and pretty close to each other:
> > >
> > > gateclk: reg = <0xea0700 4>;
> > > bypass:  reg = <0xea0710 4>;
> > > clk: reg = <0xea0720 0x144>;
> > 
> >  Although these ranges sit close, but we should represent HW structure 
> >  as you
> >  said.
> > >>>
> > >>> Then how do you argue that you have to share the gate clock register
> > >>> with every PLL? The answer is quite simple: You are not separating by
> > >>> HW either but existing SW API.
> > >>
> > >> No, PLLs don't share register any more. You can find what all clock 
> > >> nodes will
> > >> look like in:
> > 
> > Jisheng,
> > 
> > referring to the sunxi clock related thread, I am glad you finally
> > picked up the idea of merging clock nodes. Before you start reworking
> > bg4 clocks, I think I should be a little bit more clear about what I
> > expect to be the outcome.
> > 
> > When I said "one single clock complex node", I was referring to the
> > clocks located within the system-controller reg region, i.e. those at
> > 0xea. With bg2x we came to the conclusion that those registers
> > cannot be not cleanly separated by functions, so we decided to have
> > a single system-controller simple-mfd node with sub-nodes for
> > pinctrl, clock, reset, and whatever we will find there in the future.
> > 
> > Please also follow this scheme for bg4 because when you start looking
> > at reset, you'll likely see the same issues we were facing: Either you
> > have a reset controller node with a plethora of reg property entries
> > or you constantly undermine the concept of requested resources by using
> > of_iomap().
> > 
> > Using simple-mfd is a compromise between detailed HW description and
> > usability. It will also automatically deal with concurrent accesses to
> > the same register for e.g. clock and reset because simple-mfd and syscon
> > install an access lock for the reg region. Even though there may be no
> > real concurrent accesses to the same register, it does no real harm
> > because we are locking resisters that aren't supposed to be used in
> > high-speed applications. Some of them are touched once at boot, most
> > of them are never touched by Linux at all.  
> 
> Thank you so much for the detailed information. It do help me to have
> a better understanding why.
> 
> > 
> > For the other PLLs at <0x922000 0x14> and <0x940034 0x14>, I do accept
> > that they are not part of the system-controller sub-node. For the short
> > run, I would accept separate nodes for the PLLs alone, but on the long
> > run they should be hidden within the functional node they belong to,
> > i.e. mempll should be a clock provided by some memory-controller node.
> > As soon as you look at power saving modes for the memory-controller,
> > you would need access to memory-controller register _and_ mempll anyway.
> > 
> > We do have our DT tagged unstable, so we still can easily revert our
> > limited view of some nodes later.
> > 
> > BTW, if the clock provided by mempll is used to generate peripheral
> > clocks that are dealt with in the sysctrl clock complex, you should,  
> 
> mempll is only for ddrphy clk. So we are lucky ;)

oops, no, we are not lucky. mempll and memfastrefclk are clk-muxed to ddrphy clk
which is dealt within the complex big clock block. So is for cpupll, 
cpufastrefclk
But it's not that hard to add this support in the code.

Thanks for t

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Michael Trimarchi]

Hi

On Fri, Nov 27, 2015 at 9:38 AM, Pali Rohár  wrote:
> On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
>> Just to explore options.. How about make a minimal device driver that
>> just loads the atags blob from /lib/firmware and then shows it in
>> /proc/atags? Of course some checking on the atags should be done by
>> the driver..
>
> And who can dynamically create that blob file in /lib/firmware? If
> kernel does not export those atags (somehow) from bootloader, then
> userspace is not able to create that blob... cyclic problem.
>

Are those atags from bootloader fix or they change device by device. If they
are fixed they can be included in some firmware and get from the disk.

Michael

> So no, problem is that bootloader provides via custom atags dynamic
> information like: boot reason (how was device started, by rtc alarm? by
> reboot? by usb charger? by power button?), boot mode (should be enter
> into firmware update mode?, is this normal boot mode?), ... and those
> information are needed for some proprietary software (e.g. firmware
> upgrade/flash) but also by any other open source applications (based on
> usb charger we enter different runlevel -- for just only charging
> device).
>
> --
> Pali Rohár
> pali.ro...@gmail.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Jisheng Zhang]

On Fri, 27 Nov 2015 08:51:27 +0100
Sebastian Hesselbarth wrote:

> On 24.11.2015 03:35, Jisheng Zhang wrote:
> > On Mon, 23 Nov 2015 16:54:44 +0800
> > Jisheng Zhang wrote:  
> >> On Mon, 23 Nov 2015 09:30:42 +0100
> >> Sebastian Hesselbarth wrote:  
> >>> On 23.11.2015 08:21, Jisheng Zhang wrote:  
>  On Fri, 20 Nov 2015 22:06:59 +0100
>  Sebastian Hesselbarth wrote:  
> > On 20.11.2015 09:42, Jisheng Zhang wrote:  
> >> Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.
> >>
> >> Signed-off-by: Jisheng Zhang 
> >> ---  
> >>> [...]  
> >> +  syspll: syspll {
> >> +  compatible = "marvell,berlin-pll";
> >> +  reg = <0xea0200 0x14>, <0xea0710 4>;
> >> +  #clock-cells = <0>;
> >> +  clocks = <&osc>;
> >> +  bypass-shift = /bits/ 8 <0>;
> >> +  };
> >> +
> >> +  gateclk: gateclk {
> >> +  compatible = "marvell,berlin4ct-gateclk";
> >> +  reg = <0xea0700 4>;
> >> +  #clock-cells = <1>;
> >> +  };
> >> +
> >> +  clk: clk {
> >> +  compatible = "marvell,berlin4ct-clk";
> >> +  reg = <0xea0720 0x144>;  
> >
> > Looking at the reg ranges, I'd say that they are all clock related
> > and pretty close to each other:
> >
> > gateclk: reg = <0xea0700 4>;
> > bypass:  reg = <0xea0710 4>;
> > clk: reg = <0xea0720 0x144>;  
> 
>  Although these ranges sit close, but we should represent HW structure as 
>  you
>  said.  
> >>>
> >>> Then how do you argue that you have to share the gate clock register
> >>> with every PLL? The answer is quite simple: You are not separating by
> >>> HW either but existing SW API.  
> >>
> >> No, PLLs don't share register any more. You can find what all clock nodes 
> >> will
> >> look like in:  
> 
> Jisheng,
> 
> referring to the sunxi clock related thread, I am glad you finally
> picked up the idea of merging clock nodes. Before you start reworking
> bg4 clocks, I think I should be a little bit more clear about what I
> expect to be the outcome.
> 
> When I said "one single clock complex node", I was referring to the
> clocks located within the system-controller reg region, i.e. those at
> 0xea. With bg2x we came to the conclusion that those registers
> cannot be not cleanly separated by functions, so we decided to have
> a single system-controller simple-mfd node with sub-nodes for
> pinctrl, clock, reset, and whatever we will find there in the future.
> 
> Please also follow this scheme for bg4 because when you start looking
> at reset, you'll likely see the same issues we were facing: Either you
> have a reset controller node with a plethora of reg property entries
> or you constantly undermine the concept of requested resources by using
> of_iomap().
> 
> Using simple-mfd is a compromise between detailed HW description and
> usability. It will also automatically deal with concurrent accesses to
> the same register for e.g. clock and reset because simple-mfd and syscon
> install an access lock for the reg region. Even though there may be no
> real concurrent accesses to the same register, it does no real harm
> because we are locking resisters that aren't supposed to be used in
> high-speed applications. Some of them are touched once at boot, most
> of them are never touched by Linux at all.

Thank you so much for the detailed information. It do help me to have
a better understanding why.

> 
> For the other PLLs at <0x922000 0x14> and <0x940034 0x14>, I do accept
> that they are not part of the system-controller sub-node. For the short
> run, I would accept separate nodes for the PLLs alone, but on the long
> run they should be hidden within the functional node they belong to,
> i.e. mempll should be a clock provided by some memory-controller node.
> As soon as you look at power saving modes for the memory-controller,
> you would need access to memory-controller register _and_ mempll anyway.
> 
> We do have our DT tagged unstable, so we still can easily revert our
> limited view of some nodes later.
> 
> BTW, if the clock provided by mempll is used to generate peripheral
> clocks that are dealt with in the sysctrl clock complex, you should,

mempll is only for ddrphy clk. So we are lucky ;)

Thanks,
Jisheng

> of course, expose that relation in DT, e.g.:
> 
> sysctrl: system-controller {
>   reg = <0xea0700 0xfoo>;
> 
>   sysclk: clock {
>   #clock-cells = <1>;
>   clocks = <&osc>, <&memctrl 0>;
>   clock-names = "osc", "mempll";
>   };
> };
> 
> memctrl: memory-controller {
>   reg = <0x92 0xbar>;
>   /*
>* clock-cells can also be 0
>* if there is no other clock provided
>*/
>   #clock-cell

Re: [PATCH v8 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Heiko Stübner]

Hi Yakir,

Am Freitag, 27. November 2015, 09:20:44 schrieb Yakir Yang:
> Hi Heiko,
> 
> Thanks you for feedback, I do see some conflicts in Exynos Make/Kconfig
> file [02/17] and dtsi file [07/17] when I try to apply this series on
> 4.4-rc1
> branch.
> 
> Hmm... Due to I have update some patches to version 10 already, this
> series may be become harder to reviewed, should I just send the whole
> series out that update the version to v10.

yes, that might make sense, also because people are generally reluctant to 
fixup patches when simply reviewing/testing.


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 v8 08/17] drm: rockchip: dp: add rockchip platform dp driver

[Heiko Stübner]

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:27:45 schrieb Yakir Yang:
> Rockchip have three clocks for dp controller, we leave pclk_edp
> to analogix_dp driver control, and keep the sclk_edp_24m and
> sclk_edp in platform driver.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---

> diff --git a/drivers/gpu/drm/rockchip/Kconfig
> b/drivers/gpu/drm/rockchip/Kconfig index 35215f6..c2ba945 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
> for the Synopsys DesignWare HDMI driver. If you want to
> enable HDMI on RK3288 based SoC, you should selet this
> option.
> +
> +config ROCKCHIP_ANALOGIX_DP
> +tristate "Rockchip specific extensions for Analogix DP driver"
> +depends on DRM_ROCKCHIP
> +select DRM_ANALOGIX_DP
> +help

the indentation should probably be tabs here, ROCKCHIP_DW_HDMI also does it 
wrong it seems, but DRM_ROCKCHIP looks correct :-)


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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
> Just to explore options.. How about make a minimal device driver that
> just loads the atags blob from /lib/firmware and then shows it in
> /proc/atags? Of course some checking on the atags should be done by
> the driver..

And who can dynamically create that blob file in /lib/firmware? If
kernel does not export those atags (somehow) from bootloader, then
userspace is not able to create that blob... cyclic problem.

So no, problem is that bootloader provides via custom atags dynamic
information like: boot reason (how was device started, by rtc alarm? by
reboot? by usb charger? by power button?), boot mode (should be enter
into firmware update mode?, is this normal boot mode?), ... and those
information are needed for some proprietary software (e.g. firmware
upgrade/flash) but also by any other open source applications (based on
usb charger we enter different runlevel -- for just only charging
device).

-- 
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH (v4) 2/11] MIPS: bmips: Add bcm6345-l2-timer interrupt controller

[Thomas Gleixner]

Simon,

On Thu, 26 Nov 2015, Simon Arlott wrote:
> +static inline u32 bcm6345_timer_read_int_status(struct bcm6345_timer *timer)
> +{
> + if (timer->interrupt_bits == 32)
> + return __raw_readl(timer->base + timer->regs[TIMER_INT_STATUS]);
> + else
> + return __raw_readb(timer->base + timer->regs[TIMER_INT_STATUS]);
> +}

Instead of having that pile of conditionals you could just define two
functions and have a function pointer in struct bcm6345_timer which
you initialize at init time.

> +static inline void bcm6345_timer_write_control(struct bcm6345_timer *timer,
> + unsigned int id, u32 val)
> +{
> + if (id >= timer->nr_timers) {
> + WARN(1, "%s: %d >= %d", __func__, id, timer->nr_timers);

This is more than silly. You call that form the init function via:

for (i = 0; i < timer->nr_timers; i++)

Hmm?

> +static void bcm6345_timer_unmask(struct irq_data *d)
> +{
> + struct bcm6345_timer *timer = irq_data_get_irq_chip_data(d);
> + unsigned long flags;
> + u8 val;
> +
> + if (d->hwirq < timer->nr_timers) {

Again. You can have two different interrupt chips without that
completely undocumented and non obvious conditional.

BTW, how are those simple interrupts masked at all?

> + raw_spin_lock_irqsave(&timer->lock, flags);
> + val = bcm6345_timer_read_int_enable(timer);
> + val |= BIT(d->hwirq);
> + bcm6345_timer_write_int_enable(timer, val);
> + raw_spin_unlock_irqrestore(&timer->lock, flags);
> + }
> +}

> + raw_spin_lock_init(&timer->lock);
> + timer->regs = regs;
> + timer->interrupt_bits = interrupt_bits;
> + timer->nr_timers = nr_timers;
> + timer->nr_interrupts = nr_timers + 1;

What is that extra interrupt about? For the casual reader this looks
like a bug ... Comments exist for a reason.

Thanks,

tglx
--
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 1/4] arm64, numa: adding numa support for arm64 platforms.

[Shannon Zhao]

On 2015/11/18 1:20, Ganapatrao Kulkarni wrote:
> Adding numa support for arm64 based platforms.
> This patch adds by default the dummy numa node and
> maps all memory and cpus to node 0.
> using this patch, numa can be simulated on single node arm64 platforms.
> 
> Reviewed-by: Robert Richter 
> Signed-off-by: Ganapatrao Kulkarni 

I've tested this patch on QEMU VM.

Tested-by: Shannon Zhao 
> ---
>  arch/arm64/Kconfig  |  25 +++
>  arch/arm64/include/asm/mmzone.h |  17 ++
>  arch/arm64/include/asm/numa.h   |  47 +
>  arch/arm64/kernel/setup.c   |   4 +
>  arch/arm64/kernel/smp.c |   2 +
>  arch/arm64/mm/Makefile  |   1 +
>  arch/arm64/mm/init.c|  30 +++-
>  arch/arm64/mm/numa.c| 384 
> 
>  8 files changed, 506 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm64/include/asm/mmzone.h
>  create mode 100644 arch/arm64/include/asm/numa.h
>  create mode 100644 arch/arm64/mm/numa.c
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9ac16a4..7d8fb42 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -71,6 +71,7 @@ config ARM64
>   select HAVE_GENERIC_DMA_COHERENT
>   select HAVE_HW_BREAKPOINT if PERF_EVENTS
>   select HAVE_MEMBLOCK
> + select HAVE_MEMBLOCK_NODE_MAP if NUMA
>   select HAVE_PATA_PLATFORM
>   select HAVE_PERF_EVENTS
>   select HAVE_PERF_REGS
> @@ -482,6 +483,30 @@ config HOTPLUG_CPU
> Say Y here to experiment with turning CPUs off and on.  CPUs
> can be controlled through /sys/devices/system/cpu.
>  
> +# Common NUMA Features
> +config NUMA
> + bool "Numa Memory Allocation and Scheduler Support"
> + depends on SMP
> + help
> +   Enable NUMA (Non Uniform Memory Access) support.
> +
> +   The kernel will try to allocate memory used by a CPU on the
> +   local memory controller of the CPU and add some more
> +   NUMA awareness to the kernel.
> +
> +config NODES_SHIFT
> + int "Maximum NUMA Nodes (as a power of 2)"
> + range 1 10
> + default "2"
> + depends on NEED_MULTIPLE_NODES
> + help
> +   Specify the maximum number of NUMA Nodes available on the target
> +   system.  Increases memory reserved to accommodate various tables.
> +
> +config USE_PERCPU_NUMA_NODE_ID
> + def_bool y
> + depends on NUMA
> +
>  source kernel/Kconfig.preempt
>  source kernel/Kconfig.hz
>  
> diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
> new file mode 100644
> index 000..6ddd468
> --- /dev/null
> +++ b/arch/arm64/include/asm/mmzone.h
> @@ -0,0 +1,17 @@
> +#ifndef __ASM_ARM64_MMZONE_H_
> +#define __ASM_ARM64_MMZONE_H_
> +
> +#ifdef CONFIG_NUMA
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +extern struct pglist_data *node_data[];
> +
> +#define NODE_DATA(nid)   (node_data[(nid)])
> +
> +#endif /* CONFIG_NUMA */
> +#endif /* __ASM_ARM64_MMZONE_H_ */
> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> new file mode 100644
> index 000..c00f3a4
> --- /dev/null
> +++ b/arch/arm64/include/asm/numa.h
> @@ -0,0 +1,47 @@
> +#ifndef _ASM_NUMA_H
> +#define _ASM_NUMA_H
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_NUMA
> +
> +#define NR_NODE_MEMBLKS  (MAX_NUMNODES * 2)
> +#define ZONE_ALIGN (1UL << (MAX_ORDER + PAGE_SHIFT))
> +
> +/* currently, arm64 implements flat NUMA topology */
> +#define parent_node(node)(node)
> +
> +extern int __node_distance(int from, int to);
> +#define node_distance(a, b) __node_distance(a, b)
> +
> +/* dummy definitions for pci functions */
> +#define pcibus_to_node(node) 0
> +#define cpumask_of_pcibus(bus)   0
> +
> +extern int cpu_to_node_map[NR_CPUS];
> +extern nodemask_t numa_nodes_parsed __initdata;
> +
> +/* Mappings between node number and cpus on that node. */
> +extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
> +extern void numa_clear_node(unsigned int cpu);
> +#ifdef CONFIG_DEBUG_PER_CPU_MAPS
> +extern const struct cpumask *cpumask_of_node(int node);
> +#else
> +/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
> +static inline const struct cpumask *cpumask_of_node(int node)
> +{
> + return node_to_cpumask_map[node];
> +}
> +#endif
> +
> +void __init arm64_numa_init(void);
> +int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +void __init numa_set_distance(int from, int to, int distance);
> +void __init numa_reset_distance(void);
> +void numa_store_cpu_info(unsigned int cpu);
> +#else/* CONFIG_NUMA */
> +static inline void numa_store_cpu_info(unsigned int cpu) { }
> +static inline void arm64_numa_init(void) { }
> +#endif   /* CONFIG_NUMA */
> +#endif   /* _ASM_NUMA_H */
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 8119479..d9b9761 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -53,6 +53,7 @@
>