[PATCH net-next 1/2] net: hns: enet specisies a reference to dsaf

[yankejian]

enet is associating with dasf. before this patch, the association is
the same strings between ae-name and dsa-name. in a general way, enet
specifies a reference to dsaf should be a good idea. so this patch
deletes the ae-name in enet, and adds parsing the ae-handle
from DT to set the associating with dsaf.

Signed-off-by: yankejian 
---
 drivers/net/ethernet/hisilicon/hns/hnae.c  | 17 +++--
 drivers/net/ethernet/hisilicon/hns/hnae.h  |  7 +--
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c  |  4 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 10 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |  1 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.c  | 13 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.h  |  2 +-
 7 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c 
b/drivers/net/ethernet/hisilicon/hns/hnae.c
index b364529..3bfe36f 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -95,21 +95,17 @@ static struct hnae_buf_ops hnae_bops = {
 static int __ae_match(struct device *dev, const void *data)
 {
struct hnae_ae_dev *hdev = cls_to_ae_dev(dev);
-   const char *ae_id = data;
 
-   if (!strncmp(ae_id, hdev->name, AE_NAME_SIZE))
-   return 1;
-
-   return 0;
+   return hdev->dev->of_node == data;
 }
 
-static struct hnae_ae_dev *find_ae(const char *ae_id)
+static struct hnae_ae_dev *find_ae(const struct device_node *ae_node)
 {
struct device *dev;
 
-   WARN_ON(!ae_id);
+   WARN_ON(!ae_node);
 
-   dev = class_find_device(hnae_class, NULL, ae_id, __ae_match);
+   dev = class_find_device(hnae_class, NULL, ae_node, __ae_match);
 
return dev ? cls_to_ae_dev(dev) : NULL;
 }
@@ -316,7 +312,8 @@ EXPORT_SYMBOL(hnae_reinit_handle);
  * return handle ptr or ERR_PTR
  */
 struct hnae_handle *hnae_get_handle(struct device *owner_dev,
-   const char *ae_id, u32 port_id,
+   const struct device_node *ae_node,
+   u32 port_id,
struct hnae_buf_ops *bops)
 {
struct hnae_ae_dev *dev;
@@ -324,7 +321,7 @@ struct hnae_handle *hnae_get_handle(struct device 
*owner_dev,
int i, j;
int ret;
 
-   dev = find_ae(ae_id);
+   dev = find_ae(ae_node);
if (!dev)
return ERR_PTR(-ENODEV);
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index d1f3316..0012664 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -523,8 +523,11 @@ struct hnae_handle {
 
 #define ring_to_dev(ring) ((ring)->q->dev->dev)
 
-struct hnae_handle *hnae_get_handle(struct device *owner_dev, const char 
*ae_id,
-   u32 port_id, struct hnae_buf_ops *bops);
+struct hnae_handle *hnae_get_handle(struct device *owner_dev,
+   const struct device_node *ae_node,
+   u32 port_id,
+   struct hnae_buf_ops *bops);
+
 void hnae_put_handle(struct hnae_handle *handle);
 int hnae_ae_register(struct hnae_ae_dev *dev, struct module *owner);
 void hnae_ae_unregister(struct hnae_ae_dev *dev);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 77c6edb..ed9a72c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -848,6 +848,7 @@ static struct hnae_ae_ops hns_dsaf_ops = {
 int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
 {
struct hnae_ae_dev *ae_dev = &dsaf_dev->ae_dev;
+   static atomic_t id = ATOMIC_INIT(-1);
 
switch (dsaf_dev->dsaf_ver) {
case AE_VERSION_1:
@@ -859,6 +860,9 @@ int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
default:
break;
}
+
+   snprintf(ae_dev->name, AE_NAME_SIZE, "%s%d", DSAF_DEVICE_NAME,
+(int)atomic_inc_return(&id));
ae_dev->ops = &hns_dsaf_ops;
ae_dev->dev = dsaf_dev->dev;
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 636b205..f3de749 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -35,7 +35,7 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
int ret, i;
u32 desc_num;
u32 buf_size;
-   const char *name, *mode_str;
+   const char *mode_str;
struct device_node *np = dsaf_dev->dev->of_node;
 
if (of_device_is_compatible(np, "hisilicon,hns-dsaf-v1"))
@@ -43,14 +43,6 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
else
dsaf_dev->ds

Re: [PATCH RESEND net-next 0/3] dts: hisi: fixes can't find eth for hip05-D02

[Yankejian (Hackim Yim)]

sorry, pls ignore this patchset.

On 2015/12/5 15:54, yankejian wrote:
> this patchset fixes the bug that eth can't initial successful on hip05-D02
> because 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(-)
>


--
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 RESEND net-next 3/3] arm64: hip05-d02: Document devicetree bindings for Hisilicon D02 Board

[yankejian]

This patch adds documentation for the devicetree bindings used by the
DT files of Hisilicon Hip05-D02 development board.

Signed-off-by: yankejian 
---
 .../devicetree/bindings/arm/hisilicon/hisilicon.txt  | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 6ac7c00..5318d78 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -187,6 +187,22 @@ Example:
reg = <0xb000 0x1>;
};
 
+Hisilicon HiP05 PERISUB system controller
+
+Required properties:
+- compatible : "hisilicon,peri-c-subctrl", "syscon";
+- reg : Register address and size
+
+The HiP05 PERISUB system controller is shared by peripheral controllers in
+HiP05 Soc to implement some basic configurations. the peripheral
+ controllers include mdio, ddr, iic, uart, timer and so on.
+
+Example:
+   /* for HiP05 PCIe-SAS system */
+   pcie_sas: system_controller@0xb000 {
+   compatible = "hisilicon,pcie-sas-subctrl", "syscon";
+   reg = <0xb000 0x1>;
+   };
 ---
 Hisilicon CPU controller
 
-- 
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/2] net: hns: enet specisies a reference to dsaf

[yankejian]

in this patchset, enet specifies a reference to dsaf. and delete the 
ae-name in enet, and adds parsing the ae-handle from DT to set the 
associating with dsaf.
the patchset updates the dtsi and bindings documents as well.

yankejian (2):
  net: hns: enet specisies a reference to dsaf
  net: hns: enet specisies a reference to dsaf (config and documents)

 .../devicetree/bindings/net/hisilicon-hns-dsaf.txt|  5 +
 .../devicetree/bindings/net/hisilicon-hns-nic.txt |  7 ---
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi  | 19 +--
 drivers/net/ethernet/hisilicon/hns/hnae.c | 17 +++--
 drivers/net/ethernet/hisilicon/hns/hnae.h |  7 +--
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c |  4 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c| 10 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h|  1 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.c | 13 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.h |  2 +-
 10 files changed, 42 insertions(+), 43 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

[PATCH net-next 2/2] net: hns: enet specisies a reference to dsaf (config and documents)

[yankejian]

when enet specisies a reference to dsaf, the correlative config and
documents needs to update. this patch updates the correlative dtsi file
and bindings documents .

Signed-off-by: yankejian 
---
 .../devicetree/bindings/net/hisilicon-hns-dsaf.txt|  5 +
 .../devicetree/bindings/net/hisilicon-hns-nic.txt |  7 ---
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi  | 19 +--
 3 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
index 80411b2..ecacfa4 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
@@ -4,8 +4,6 @@ Required properties:
 - compatible: should be "hisilicon,hns-dsaf-v1" or "hisilicon,hns-dsaf-v2".
   "hisilicon,hns-dsaf-v1" is for hip05.
   "hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
-- dsa-name: dsa fabric name who provide this interface.
-  should be "dsafX", X is the dsaf id.
 - mode: dsa fabric mode string. only support one of dsaf modes like these:
"2port-64vf",
"6port-16rss",
@@ -26,9 +24,8 @@ Required properties:
 
 Example:
 
-dsa: dsa@c700 {
+dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
-   dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <&mbigen_dsa>;
reg = <0x0 0xC000 0x0 0x42
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
index 41d19be..e6a9d1c 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
@@ -4,8 +4,9 @@ Required properties:
 - compatible: "hisilicon,hns-nic-v1" or "hisilicon,hns-nic-v2".
   "hisilicon,hns-nic-v1" is for hip05.
   "hisilicon,hns-nic-v2" is for Hi1610 and Hi1612.
-- ae-name: accelerator name who provides this interface,
-  is simply a name referring to the name of name in the accelerator node.
+- ae-handle: accelerator engine handle for hns,
+  specifies a reference to the associating hardware driver node.
+  see Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
 - port-id: is the index of port provided by DSAF (the accelerator). DSAF can
   connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose. They
   are called debug ports.
@@ -41,7 +42,7 @@ Example:
 
ethernet@0{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <0>;
local-mac-address = [a2 14 e4 4b 56 76];
};
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 606dd5a..89c883e 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -23,9 +23,8 @@ soc0: soc@0 {
};
};
 
-   dsa: dsa@c700 {
+   dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
-   dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <&mbigen_dsa>;
 
@@ -127,7 +126,7 @@ soc0: soc@0 {
 
eth0: ethernet@0{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <0>;
local-mac-address = [00 00 00 01 00 58];
status = "disabled";
@@ -135,14 +134,14 @@ soc0: soc@0 {
};
eth1: ethernet@1{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <1>;
status = "disabled";
dma-coherent;
};
eth2: ethernet@2{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <2>;
local-mac-address = [00 00 00 01 00 5a];
status = "disabled";
@@ -150,7 +149,7 @@ soc0: soc@0 {
};
eth3: ethernet@3{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <3>;
local-mac-address = [00 00 00 01 00 5b];
status = "disabled";
@@ -158,7 +157,7 @@ soc0: soc@0 {
};
eth4: ethernet@4{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <4>;
local-mac-address = [00 00 00 01 00 5c];
status = "disabled";
@@ -166,7 +165,7 @@ soc0: soc@0 {
};
eth5: ethernet@5{
compatible = "hisilico

[PATCH RESEND 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 RESEND 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 on hip05-D02
because 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

[PATCH RESEND 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 RESEND 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 RESEND 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 on hip05-D02
because 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

[PATCH RESEND net-next 3/3] arm64: hip05-d02: Document devicetree bindings for Hisilicon D02 Board

[yankejian]

This patch adds documentation for the devicetree bindings used by the
DT files of Hisilicon Hip05-D02 development board.

Signed-off-by: yankejian 
---
 .../devicetree/bindings/arm/hisilicon/hisilicon.txt  | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 6ac7c00..5318d78 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -187,6 +187,22 @@ Example:
reg = <0xb000 0x1>;
};
 
+Hisilicon HiP05 PERISUB system controller
+
+Required properties:
+- compatible : "hisilicon,peri-c-subctrl", "syscon";
+- reg : Register address and size
+
+The HiP05 PERISUB system controller is shared by peripheral controllers in
+HiP05 Soc to implement some basic configurations. the peripheral
+ controllers include mdio, ddr, iic, uart, timer and so on.
+
+Example:
+   /* for HiP05 PCIe-SAS system */
+   pcie_sas: system_controller@0xb000 {
+   compatible = "hisilicon,pcie-sas-subctrl", "syscon";
+   reg = <0xb000 0x1>;
+   };
 ---
 Hisilicon CPU controller
 
-- 
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 RESEND 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

RE: [PATCH 4/4] ARM: dts: vf610-twr: relicense vf610-twr.dts under GPLv2/X11

[Yao Yuan]

On 11/24/2015 07:57 AM, Stefan Agner wrote:

> GPLv2-only devicetrees make reuse difficult for software components licensed
> under a different license.
> 
> The consensus is that a GPL/X11 dual-license should allow all necessary uses, 
> so
> relicense the vf610-twr.dts file to this combination.
> 
> CCs were acquired using (updated some email addresses):
> git shortlog -sne --no-merges arch/arm/boot/dts/vf610-twr.dts
> 
> CC: Bill Pringlemeir 
> CC: Chao Fu 
> CC: Cory Tusar 
> CC: Cosmin Stoica 
> CC: Fugang Duan 
> CC: Jingchang Lu 
> CC: Shawn Guo 
> CC: Xiubo Li 

Acked-by: Yuan Yao 

By the way the email address:
CC: Xiubo Li 
Jingchang Lu 
Chao Fu 
is no longer valid.

> Signed-off-by: Stefan Agner 
> ---
>  arch/arm/boot/dts/vf610-twr.dts | 40
> 
>  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-
> twr.dts index 5438ee4..ce937b9 100644
> --- a/arch/arm/boot/dts/vf610-twr.dts
> +++ b/arch/arm/boot/dts/vf610-twr.dts
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/4] ARM: dts: vf610: relicense vf???.dtsi under GPLv2/X11

[Yao Yuan]

On 11/24/2015 07:57 AM, Stefan Agner wrote:
GPLv2-only devicetrees make reuse difficult for software components licensed 
under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary uses, 
so relicense the vfxxx.dtsi, vf500.dtsi and vf610.dtsi files to this 
combination.

CCs were acquired using (updated some email addresses):
git shortlog -sne --no-merges arch/arm/boot/dts/vf???.dtsi

CC: Bhuvanchandra DV 
CC: Chao Fu 
CC: Cory Tusar 
CC: Cosmin Stoica 
CC: Frank Li 
CC: Fugang Duan 
CC: Huang Shijie 
CC: Jingchang Lu 
CC: Lucas Stach 
CC: Sanchayan Maity 
CC: Shawn Guo 
CC: Stephen Warren 
CC: Xiubo Li 
CC: Yuan Yao 

Acked-by: Yuan Yao 

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf500.dtsi | 40 
 arch/arm/boot/dts/vf610.dtsi | 40 
 arch/arm/boot/dts/vfxxx.dtsi | 40 
 3 files changed, 108 insertions(+), 12 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 net-next 2/2] net: hns: enet specisies a reference to dsaf (config and documents)

[yankejian]

when enet specisies a reference to dsaf, the correlative config and
documents needs to update. this patch updates the correlative dtsi file
and bindings documents .

Signed-off-by: yankejian 
---
 .../devicetree/bindings/net/hisilicon-hns-dsaf.txt|  5 +
 .../devicetree/bindings/net/hisilicon-hns-nic.txt |  7 ---
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi  | 19 +--
 3 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
index 80411b2..ecacfa4 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
@@ -4,8 +4,6 @@ Required properties:
 - compatible: should be "hisilicon,hns-dsaf-v1" or "hisilicon,hns-dsaf-v2".
   "hisilicon,hns-dsaf-v1" is for hip05.
   "hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
-- dsa-name: dsa fabric name who provide this interface.
-  should be "dsafX", X is the dsaf id.
 - mode: dsa fabric mode string. only support one of dsaf modes like these:
"2port-64vf",
"6port-16rss",
@@ -26,9 +24,8 @@ Required properties:
 
 Example:
 
-dsa: dsa@c700 {
+dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
-   dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <&mbigen_dsa>;
reg = <0x0 0xC000 0x0 0x42
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
index 41d19be..e6a9d1c 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
@@ -4,8 +4,9 @@ Required properties:
 - compatible: "hisilicon,hns-nic-v1" or "hisilicon,hns-nic-v2".
   "hisilicon,hns-nic-v1" is for hip05.
   "hisilicon,hns-nic-v2" is for Hi1610 and Hi1612.
-- ae-name: accelerator name who provides this interface,
-  is simply a name referring to the name of name in the accelerator node.
+- ae-handle: accelerator engine handle for hns,
+  specifies a reference to the associating hardware driver node.
+  see Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
 - port-id: is the index of port provided by DSAF (the accelerator). DSAF can
   connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose. They
   are called debug ports.
@@ -41,7 +42,7 @@ Example:
 
ethernet@0{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <0>;
local-mac-address = [a2 14 e4 4b 56 76];
};
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 606dd5a..89c883e 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -23,9 +23,8 @@ soc0: soc@0 {
};
};
 
-   dsa: dsa@c700 {
+   dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
-   dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <&mbigen_dsa>;
 
@@ -127,7 +126,7 @@ soc0: soc@0 {
 
eth0: ethernet@0{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <0>;
local-mac-address = [00 00 00 01 00 58];
status = "disabled";
@@ -135,14 +134,14 @@ soc0: soc@0 {
};
eth1: ethernet@1{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <1>;
status = "disabled";
dma-coherent;
};
eth2: ethernet@2{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <2>;
local-mac-address = [00 00 00 01 00 5a];
status = "disabled";
@@ -150,7 +149,7 @@ soc0: soc@0 {
};
eth3: ethernet@3{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <3>;
local-mac-address = [00 00 00 01 00 5b];
status = "disabled";
@@ -158,7 +157,7 @@ soc0: soc@0 {
};
eth4: ethernet@4{
compatible = "hisilicon,hns-nic-v1";
-   ae-name = "dsaf0";
+   ae-handle = <&dsaf0>;
port-id = <4>;
local-mac-address = [00 00 00 01 00 5c];
status = "disabled";
@@ -166,7 +165,7 @@ soc0: soc@0 {
};
eth5: ethernet@5{
compatible = "hisilico

[PATCH net-next 1/2] net: hns: enet specisies a reference to dsaf

[yankejian]

enet is associating with dasf. before this patch, the association is
the same strings between ae-name and dsa-name. in a general way, enet
specifies a reference to dsaf should be a good idea. so this patch
deletes the ae-name in enet, and adds parsing the ae-handle
from DT to set the associating with dsaf.

Signed-off-by: yankejian 
---
 drivers/net/ethernet/hisilicon/hns/hnae.c  | 17 +++--
 drivers/net/ethernet/hisilicon/hns/hnae.h  |  7 +--
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c  |  4 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 10 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |  1 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.c  | 13 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.h  |  2 +-
 7 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c 
b/drivers/net/ethernet/hisilicon/hns/hnae.c
index b364529..3bfe36f 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -95,21 +95,17 @@ static struct hnae_buf_ops hnae_bops = {
 static int __ae_match(struct device *dev, const void *data)
 {
struct hnae_ae_dev *hdev = cls_to_ae_dev(dev);
-   const char *ae_id = data;
 
-   if (!strncmp(ae_id, hdev->name, AE_NAME_SIZE))
-   return 1;
-
-   return 0;
+   return hdev->dev->of_node == data;
 }
 
-static struct hnae_ae_dev *find_ae(const char *ae_id)
+static struct hnae_ae_dev *find_ae(const struct device_node *ae_node)
 {
struct device *dev;
 
-   WARN_ON(!ae_id);
+   WARN_ON(!ae_node);
 
-   dev = class_find_device(hnae_class, NULL, ae_id, __ae_match);
+   dev = class_find_device(hnae_class, NULL, ae_node, __ae_match);
 
return dev ? cls_to_ae_dev(dev) : NULL;
 }
@@ -316,7 +312,8 @@ EXPORT_SYMBOL(hnae_reinit_handle);
  * return handle ptr or ERR_PTR
  */
 struct hnae_handle *hnae_get_handle(struct device *owner_dev,
-   const char *ae_id, u32 port_id,
+   const struct device_node *ae_node,
+   u32 port_id,
struct hnae_buf_ops *bops)
 {
struct hnae_ae_dev *dev;
@@ -324,7 +321,7 @@ struct hnae_handle *hnae_get_handle(struct device 
*owner_dev,
int i, j;
int ret;
 
-   dev = find_ae(ae_id);
+   dev = find_ae(ae_node);
if (!dev)
return ERR_PTR(-ENODEV);
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index d1f3316..0012664 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -523,8 +523,11 @@ struct hnae_handle {
 
 #define ring_to_dev(ring) ((ring)->q->dev->dev)
 
-struct hnae_handle *hnae_get_handle(struct device *owner_dev, const char 
*ae_id,
-   u32 port_id, struct hnae_buf_ops *bops);
+struct hnae_handle *hnae_get_handle(struct device *owner_dev,
+   const struct device_node *ae_node,
+   u32 port_id,
+   struct hnae_buf_ops *bops);
+
 void hnae_put_handle(struct hnae_handle *handle);
 int hnae_ae_register(struct hnae_ae_dev *dev, struct module *owner);
 void hnae_ae_unregister(struct hnae_ae_dev *dev);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 77c6edb..ed9a72c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -848,6 +848,7 @@ static struct hnae_ae_ops hns_dsaf_ops = {
 int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
 {
struct hnae_ae_dev *ae_dev = &dsaf_dev->ae_dev;
+   static atomic_t id = ATOMIC_INIT(-1);
 
switch (dsaf_dev->dsaf_ver) {
case AE_VERSION_1:
@@ -859,6 +860,9 @@ int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
default:
break;
}
+
+   snprintf(ae_dev->name, AE_NAME_SIZE, "%s%d", DSAF_DEVICE_NAME,
+(int)atomic_inc_return(&id));
ae_dev->ops = &hns_dsaf_ops;
ae_dev->dev = dsaf_dev->dev;
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 636b205..f3de749 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -35,7 +35,7 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
int ret, i;
u32 desc_num;
u32 buf_size;
-   const char *name, *mode_str;
+   const char *mode_str;
struct device_node *np = dsaf_dev->dev->of_node;
 
if (of_device_is_compatible(np, "hisilicon,hns-dsaf-v1"))
@@ -43,14 +43,6 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
else
dsaf_dev->ds

[PATCH net-next 0/2] net: hns: enet specisies a reference to dsaf

[yankejian]

in this patchset, enet specifies a reference to dsaf. and delete the 
ae-name in enet, and adds parsing the ae-handle from DT to set the 
associating with dsaf.
the patchset updates the dtsi and bindings documents as well.

yankejian (2):
  net: hns: enet specisies a reference to dsaf
  net: hns: enet specisies a reference to dsaf (config and documents)

 .../devicetree/bindings/net/hisilicon-hns-dsaf.txt|  5 +
 .../devicetree/bindings/net/hisilicon-hns-nic.txt |  7 ---
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi  | 19 +--
 drivers/net/ethernet/hisilicon/hns/hnae.c | 17 +++--
 drivers/net/ethernet/hisilicon/hns/hnae.h |  7 +--
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c |  4 
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c| 10 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h|  1 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.c | 13 +
 drivers/net/ethernet/hisilicon/hns/hns_enet.h |  2 +-
 10 files changed, 42 insertions(+), 43 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

[RFC PATCH 4/7] mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers

[Brian Norris]

Like the corresponding OF-based device/driver matching infrascture,
let's begin to support a mtd/partition-parser matching infrastructure.

Signed-off-by: Brian Norris 
---
 drivers/of/of_mtd.c| 33 +
 include/linux/mtd/partitions.h |  2 ++
 include/linux/of_mtd.h | 13 +
 3 files changed, 48 insertions(+)

diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index b7361ed70537..169d7500af5d 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -117,3 +118,35 @@ bool of_get_nand_on_flash_bbt(struct device_node *np)
return of_property_read_bool(np, "nand-on-flash-bbt");
 }
 EXPORT_SYMBOL_GPL(of_get_nand_on_flash_bbt);
+
+static const struct of_device_id *of_match_mtd_parser(
+   struct mtd_part_parser *parser, struct device_node *np)
+{
+   if (!parser || !np)
+   return NULL;
+
+   return of_match_node(parser->of_match_table, np);
+}
+
+static struct device_node *mtd_get_partitions_of_node(struct mtd_info *master)
+{
+   struct device_node *np = mtd_get_of_node(master);
+
+   if (!np)
+   return NULL;
+
+   return of_get_child_by_name(np, "partitions");
+}
+
+bool of_mtd_match_mtd_parser(struct mtd_info *mtd,
+struct mtd_part_parser *parser)
+{
+   struct device_node *np = mtd_get_partitions_of_node(mtd);
+   bool ret;
+
+   ret = of_match_mtd_parser(parser, np) != NULL;
+   of_node_put(np);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(of_mtd_match_mtd_parser);
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 70736e1e6c8f..2e68ef561a40 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -51,6 +51,7 @@ struct mtd_partition {
 
 struct mtd_info;
 struct device_node;
+struct of_device_id;
 
 /**
  * struct mtd_part_parser_data - used to pass data to MTD partition parsers.
@@ -69,6 +70,7 @@ struct mtd_part_parser {
struct list_head list;
struct module *owner;
const char *name;
+   const struct of_device_id *of_match_table;
int (*parse_fn)(struct mtd_info *, const struct mtd_partition **,
struct mtd_part_parser_data *);
void (*cleanup)(const struct mtd_partition *pparts, int nr_parts);
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
index e266caa36402..781362d0be0c 100644
--- a/include/linux/of_mtd.h
+++ b/include/linux/of_mtd.h
@@ -9,6 +9,10 @@
 #ifndef __LINUX_OF_MTD_H
 #define __LINUX_OF_MTD_H
 
+#include 
+
+struct mtd_part_parser;
+
 #ifdef CONFIG_OF_MTD
 
 #include 
@@ -18,6 +22,9 @@ int of_get_nand_ecc_strength(struct device_node *np);
 int of_get_nand_bus_width(struct device_node *np);
 bool of_get_nand_on_flash_bbt(struct device_node *np);
 
+bool of_mtd_match_mtd_parser(struct mtd_info *mtd,
+struct mtd_part_parser *parser);
+
 #else /* CONFIG_OF_MTD */
 
 static inline int of_get_nand_ecc_mode(struct device_node *np)
@@ -45,6 +52,12 @@ static inline bool of_get_nand_on_flash_bbt(struct 
device_node *np)
return false;
 }
 
+static inline bool of_mtd_match_mtd_parser(struct mtd_info *mtd,
+  struct mtd_part_parser *parser)
+{
+   return false;
+}
+
 #endif /* CONFIG_OF_MTD */
 
 #endif /* __LINUX_OF_MTD_H */
-- 
2.6.0.rc2.230.g3dd15c0

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

[RFC PATCH 2/7] mtd: move partition parsers' Kconfig under a sub-menu

[Brian Norris]

For better organization.

Signed-off-by: Brian Norris 
---
 drivers/mtd/Kconfig| 134 +
 drivers/mtd/partitions/Kconfig | 131 
 2 files changed, 134 insertions(+), 131 deletions(-)
 create mode 100644 drivers/mtd/partitions/Kconfig

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 42cc953309f1..a06e80d24499 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -23,137 +23,9 @@ config MTD_TESTS
  WARNING: some of the tests will ERASE entire MTD device which they
  test. Do not use these tests unless you really know what you do.
 
-config MTD_REDBOOT_PARTS
-   tristate "RedBoot partition table parsing"
-   ---help---
- RedBoot is a ROM monitor and bootloader which deals with multiple
- 'images' in flash devices by putting a table one of the erase
- blocks on the device, similar to a partition table, which gives
- the offsets, lengths and names of all the images stored in the
- flash.
-
- If you need code which can detect and parse this table, and register
- MTD 'partitions' corresponding to each image in the table, enable
- this option.
-
- You will still need the parsing functions to be called by the driver
- for your particular device. It won't happen automatically. The
- SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
- example.
-
-if MTD_REDBOOT_PARTS
-
-config MTD_REDBOOT_DIRECTORY_BLOCK
-   int "Location of RedBoot partition table"
-   default "-1"
-   ---help---
- This option is the Linux counterpart to the
- CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
- option.
-
- The option specifies which Flash sectors holds the RedBoot
- partition table.  A zero or positive value gives an absolute
- erase block number. A negative value specifies a number of
- sectors before the end of the device.
-
- For example "2" means block number 2, "-1" means the last
- block and "-2" means the penultimate block.
-
-config MTD_REDBOOT_PARTS_UNALLOCATED
-   bool "Include unallocated flash regions"
-   help
- If you need to register each unallocated flash region as a MTD
- 'partition', enable this option.
-
-config MTD_REDBOOT_PARTS_READONLY
-   bool "Force read-only for RedBoot system images"
-   help
- If you need to force read-only for 'RedBoot', 'RedBoot Config' and
- 'FIS directory' images, enable this option.
-
-endif # MTD_REDBOOT_PARTS
-
-config MTD_CMDLINE_PARTS
-   tristate "Command line partition table parsing"
-   depends on MTD
-   ---help---
- Allow generic configuration of the MTD partition tables via the kernel
- command line. Multiple flash resources are supported for hardware 
where
- different kinds of flash memory are available.
-
- You will still need the parsing functions to be called by the driver
- for your particular device. It won't happen automatically. The
- SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
- example.
-
- The format for the command line is as follows:
-
- mtdparts=[;  := :[,]
-  := [@offset][][ro]
-   := unique id used in mapping driver/device
- := standard linux memsize OR "-" to denote all
- remaining space
- := (NAME)
-
- Due to the way Linux handles the command line, no spaces are
- allowed in the partition definition, including mtd id's and partition
- names.
-
- Examples:
-
- 1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
- mtdparts=sa1100:-
-
- Same flash, but 2 named partitions, the first one being read-only:
- mtdparts=sa1100:256k(ARMboot)ro,-(root)
-
- If unsure, say 'N'.
-
-config MTD_AFS_PARTS
-   tristate "ARM Firmware Suite partition parsing"
-   depends on (ARM || ARM64)
-   ---help---
- The ARM Firmware Suite allows the user to divide flash devices into
- multiple 'images'. Each such image has a header containing its name
- and offset/size etc.
-
- If you need code which can detect and parse these tables, and
- register MTD 'partitions' corresponding to each image detected,
- enable this option.
-
- You will still need the parsing functions to be called by the driver
- for your particular device. It won't happen automatically. The
- 'physmap' map driver (CONFIG_MTD_PHYSMAP) does this, for example.
-
-config MTD_OF_PARTS
-   tristate "OpenFirmware partitioning information support"
-   default y
-   depends on OF
-   help
- This provides a partition parsing function which derives
- the partition map from the children of the flash 

[RFC PATCH 1/7] mtd: move partition parsers to drivers/mtd/partitions/

[Brian Norris]

For better organization.

Signed-off-by: Brian Norris 
---
 drivers/mtd/Makefile   | 8 +---
 drivers/mtd/partitions/Makefile| 7 +++
 drivers/mtd/{ => partitions}/afs.c | 0
 drivers/mtd/{ => partitions}/ar7part.c | 0
 drivers/mtd/{ => partitions}/bcm47xxpart.c | 0
 drivers/mtd/{ => partitions}/bcm63xxpart.c | 0
 drivers/mtd/{ => partitions}/cmdlinepart.c | 0
 drivers/mtd/{ => partitions}/ofpart.c  | 0
 drivers/mtd/{ => partitions}/redboot.c | 0
 9 files changed, 8 insertions(+), 7 deletions(-)
 create mode 100644 drivers/mtd/partitions/Makefile
 rename drivers/mtd/{ => partitions}/afs.c (100%)
 rename drivers/mtd/{ => partitions}/ar7part.c (100%)
 rename drivers/mtd/{ => partitions}/bcm47xxpart.c (100%)
 rename drivers/mtd/{ => partitions}/bcm63xxpart.c (100%)
 rename drivers/mtd/{ => partitions}/cmdlinepart.c (100%)
 rename drivers/mtd/{ => partitions}/ofpart.c (100%)
 rename drivers/mtd/{ => partitions}/redboot.c (100%)

diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 99bb9a1f6e16..1c0cd3b1c7c3 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -6,13 +6,7 @@
 obj-$(CONFIG_MTD)  += mtd.o
 mtd-y  := mtdcore.o mtdsuper.o mtdconcat.o mtdpart.o 
mtdchar.o
 
-obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
-obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
-obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
-obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
-obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
-obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
-obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
+obj-y  += partitions/
 
 # 'Users' - code which presents functionality to userspace.
 obj-$(CONFIG_MTD_BLKDEVS)  += mtd_blkdevs.o
diff --git a/drivers/mtd/partitions/Makefile b/drivers/mtd/partitions/Makefile
new file mode 100644
index ..89822f2bfa59
--- /dev/null
+++ b/drivers/mtd/partitions/Makefile
@@ -0,0 +1,7 @@
+obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
+obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
+obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
+obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
+obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
+obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
+obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
diff --git a/drivers/mtd/afs.c b/drivers/mtd/partitions/afs.c
similarity index 100%
rename from drivers/mtd/afs.c
rename to drivers/mtd/partitions/afs.c
diff --git a/drivers/mtd/ar7part.c b/drivers/mtd/partitions/ar7part.c
similarity index 100%
rename from drivers/mtd/ar7part.c
rename to drivers/mtd/partitions/ar7part.c
diff --git a/drivers/mtd/bcm47xxpart.c b/drivers/mtd/partitions/bcm47xxpart.c
similarity index 100%
rename from drivers/mtd/bcm47xxpart.c
rename to drivers/mtd/partitions/bcm47xxpart.c
diff --git a/drivers/mtd/bcm63xxpart.c b/drivers/mtd/partitions/bcm63xxpart.c
similarity index 100%
rename from drivers/mtd/bcm63xxpart.c
rename to drivers/mtd/partitions/bcm63xxpart.c
diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/partitions/cmdlinepart.c
similarity index 100%
rename from drivers/mtd/cmdlinepart.c
rename to drivers/mtd/partitions/cmdlinepart.c
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/partitions/ofpart.c
similarity index 100%
rename from drivers/mtd/ofpart.c
rename to drivers/mtd/partitions/ofpart.c
diff --git a/drivers/mtd/redboot.c b/drivers/mtd/partitions/redboot.c
similarity index 100%
rename from drivers/mtd/redboot.c
rename to drivers/mtd/partitions/redboot.c
-- 
2.6.0.rc2.230.g3dd15c0

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

[RFC PATCH 5/7] mtd: partitions: factor out "match by name" handling

[Brian Norris]

This code structure is going to be imitated for a match-by-device-node
implementation, so let's factor out a few functions to make this easier.

Signed-off-by: Brian Norris 
---
 drivers/mtd/mtdpart.c | 67 +++
 1 file changed, 52 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 10bf304027dd..b3100742ddf6 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -687,23 +687,47 @@ int add_mtd_partitions(struct mtd_info *master,
 static DEFINE_SPINLOCK(part_parser_lock);
 static LIST_HEAD(part_parsers);
 
-static struct mtd_part_parser *mtd_part_parser_get(const char *name)
+static bool mtd_part_parser_match_name(struct mtd_part_parser *p,
+  const char *name)
+{
+   return !strcmp(p->name, name);
+}
+
+static struct mtd_part_parser *__mtd_part_parser_get_by_name(const char *name)
 {
struct mtd_part_parser *p, *ret = NULL;
 
spin_lock(&part_parser_lock);
 
-   list_for_each_entry(p, &part_parsers, list)
-   if (!strcmp(p->name, name) && try_module_get(p->owner)) {
+   list_for_each_entry(p, &part_parsers, list) {
+   if (mtd_part_parser_match_name(p, name) &&
+   try_module_get(p->owner)) {
ret = p;
break;
}
+   }
 
spin_unlock(&part_parser_lock);
 
return ret;
 }
 
+static struct mtd_part_parser *mtd_part_parser_get_by_name(const char *name)
+{
+   struct mtd_part_parser *p;
+
+   /* Get parser, if already loaded */
+   p = __mtd_part_parser_get_by_name(name);
+   if (p)
+   return p;
+
+   if (request_module("%s", name))
+   return NULL;
+
+   /* Try again */
+   return __mtd_part_parser_get_by_name(name);
+}
+
 static inline void mtd_part_parser_put(const struct mtd_part_parser *p)
 {
module_put(p->owner);
@@ -752,6 +776,27 @@ static const char * const default_mtd_part_types[] = {
NULL
 };
 
+static int mtd_part_do_parse(struct mtd_part_parser *parser,
+struct mtd_info *master,
+struct mtd_partitions *pparts,
+struct mtd_part_parser_data *data)
+{
+   int ret;
+
+   ret = (*parser->parse_fn)(master, &pparts->parts, data);
+   pr_debug("%s: parser %s: %i\n", master->name, parser->name, ret);
+   if (ret <= 0)
+   return ret;
+
+   pr_notice("%d %s partitions found on MTD device %s\n",
+ ret, parser->name, master->name);
+
+   pparts->nr_parts = ret;
+   pparts->parser = parser;
+
+   return ret;
+}
+
 /**
  * parse_mtd_partitions - parse MTD partitions
  * @master: the master partition (describes whole MTD device)
@@ -785,23 +830,15 @@ int parse_mtd_partitions(struct mtd_info *master, const 
char *const *types,
 
for ( ; *types; types++) {
pr_debug("%s: parsing partitions %s\n", master->name, *types);
-   parser = mtd_part_parser_get(*types);
-   if (!parser && !request_module("%s", *types))
-   parser = mtd_part_parser_get(*types);
+   parser = mtd_part_parser_get_by_name(*types);
pr_debug("%s: got parser %s\n", master->name,
 parser ? parser->name : NULL);
if (!parser)
continue;
-   ret = (*parser->parse_fn)(master, &pparts->parts, data);
-   pr_debug("%s: parser %s: %i\n",
-master->name, parser->name, ret);
-   if (ret > 0) {
-   printk(KERN_NOTICE "%d %s partitions found on MTD 
device %s\n",
-  ret, parser->name, master->name);
-   pparts->nr_parts = ret;
-   pparts->parser = parser;
+   ret = mtd_part_do_parse(parser, master, pparts, data);
+   /* Found partitions! */
+   if (ret > 0)
return 0;
-   }
mtd_part_parser_put(parser);
/*
 * Stash the first error we see; only report it if no parser
-- 
2.6.0.rc2.230.g3dd15c0

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

[RFC PATCH 6/7] RFC: mtd: partitions: enable of_match_table matching

[Brian Norris]

Partition parsers can now provide an of_match_table to enable
flash<-->parser matching via device tree.

TODO: Doesn't yet work when parser is built as module. I can't just use
request_module() and friends, since OF matches don't tell me the name of
the driver/module. Maybe I can report uevents?

Signed-off-by: Brian Norris 
---
 drivers/mtd/mtdpart.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index b3100742ddf6..91eb2df0bf1e 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -728,6 +729,25 @@ static struct mtd_part_parser 
*mtd_part_parser_get_by_name(const char *name)
return __mtd_part_parser_get_by_name(name);
 }
 
+static struct mtd_part_parser *mtd_part_parser_get_by_of(struct mtd_info *mtd)
+{
+   struct mtd_part_parser *p, *ret = NULL;
+
+   spin_lock(&part_parser_lock);
+
+   list_for_each_entry(p, &part_parsers, list) {
+   if (of_mtd_match_mtd_parser(mtd, p) &&
+   try_module_get(p->owner)) {
+   ret = p;
+   break;
+   }
+   }
+
+   spin_unlock(&part_parser_lock);
+
+   return ret;
+}
+
 static inline void mtd_part_parser_put(const struct mtd_part_parser *p)
 {
module_put(p->owner);
@@ -847,6 +867,18 @@ int parse_mtd_partitions(struct mtd_info *master, const 
char *const *types,
if (ret < 0 && !err)
err = ret;
}
+
+   parser = mtd_part_parser_get_by_of(master);
+   if (!parser)
+   return err;
+
+   ret = mtd_part_do_parse(parser, master, pparts, data);
+   if (ret > 0)
+   return 0;
+   mtd_part_parser_put(parser);
+   if (ret < 0 && !err)
+   err = ret;
+
return err;
 }
 
-- 
2.6.0.rc2.230.g3dd15c0

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

[RFC PATCH 7/7] mtd: partitions: add Google's FMAP partition parser

[Brian Norris]

Cc: David Hendricks 
Signed-off-by: Brian Norris 
---
 drivers/mtd/partitions/Kconfig   |   7 ++
 drivers/mtd/partitions/Makefile  |   1 +
 drivers/mtd/partitions/google_fmap.c | 226 +++
 3 files changed, 234 insertions(+)
 create mode 100644 drivers/mtd/partitions/google_fmap.c

diff --git a/drivers/mtd/partitions/Kconfig b/drivers/mtd/partitions/Kconfig
index 0827d7a8be4e..98783f1d3a36 100644
--- a/drivers/mtd/partitions/Kconfig
+++ b/drivers/mtd/partitions/Kconfig
@@ -129,3 +129,10 @@ config MTD_BCM47XX_PARTS
help
  This provides partitions parser for devices based on BCM47xx
  boards.
+
+config MTD_GOOGLE_FMAP_PARTS
+   tristate "Google's Flash Map (FMAP) partition support"
+   help
+ This provides partition parsing for Google's flash map layout, used
+ primarily on the boot flash of Chrome OS hardware (e.g., Chromebooks
+ and Chromeboxes).
diff --git a/drivers/mtd/partitions/Makefile b/drivers/mtd/partitions/Makefile
index 89822f2bfa59..ab398c7f4d01 100644
--- a/drivers/mtd/partitions/Makefile
+++ b/drivers/mtd/partitions/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
 obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
 obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
 obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
+obj-$(CONFIG_MTD_GOOGLE_FMAP_PARTS) += google_fmap.o
diff --git a/drivers/mtd/partitions/google_fmap.c 
b/drivers/mtd/partitions/google_fmap.c
new file mode 100644
index ..abd10eb65c84
--- /dev/null
+++ b/drivers/mtd/partitions/google_fmap.c
@@ -0,0 +1,226 @@
+/*
+ * Parse Google FMAP partitions
+ *
+ * Author: Brian Norris 
+ *
+ * Copyright © 2015 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * See:
+ *   https://github.com/dhendrix/flashmap/blob/wiki/FmapSpec.md
+ *
+ * Notes:
+ *   - scans only at block boundaries; this is not guaranteed for FMAP (the
+ * Chrome OS tools do a kind of stride search, of decreasing size), but
+ * seems like a decent start
+ *   - at worst, scans (beginning of) every block on an unformatted flash
+ *   - only validates the "__FMAP__" signature, just like the Chrome OS tools;
+ * however, this seems (theoretically) easy to produce false matches
+ *   - major/minor version numbers are currently unused
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static const char fmap_signature[] = "__FMAP__";
+
+struct fmap_layout {
+   uint8_t signature[8];   /* "__FMAP__" (0x5F5F50414D465F5F) */
+   uint8_t ver_major;  /* major version number of this 
structure */
+   uint8_t ver_minor;  /* minor version of this structure */
+   __le64 base;/* physical memory-mapped address of 
the flash chip */
+   __le32 size;/* size of the flash chip in bytes */
+   uint8_t name[32];   /* descriptive name of this flash 
device, 0 terminated */
+   __le16 nareas;  /* number of areas described by areas[] 
below */
+   struct fmap_area {
+   __le32 offset;  /* offset of this area in the flash 
device */
+   __le32 size;/* size of this area in bytes */
+   uint8_t name[32];   /* descriptive name of this area, 0 
terminated */
+   __le16 flags;   /* flags for this area */
+   } __packed areas[0];
+} __packed;
+
+/* mtd_read() helper */
+static int fmap_mtd_read(struct mtd_info *mtd, loff_t offset, size_t len,
+void *buf)
+{
+   size_t retlen;
+   int ret;
+
+   ret = mtd_read(mtd, offset, len, &retlen, buf);
+   if (ret)
+   return ret;
+   if (retlen != len)
+   return -EIO;
+   return 0;
+}
+
+/* Return 0 on no match, non-zero on match */
+static inline int fmap_check_signature(struct fmap_layout *fmap)
+{
+   return !strncmp(fmap->signature, fmap_signature,
+   sizeof(fmap->signature));
+}
+
+static int fmap_parse_block(struct mtd_info *master,
+   const struct mtd_partition **pparts,
+   struct fmap_layout *fmap, size_t maxlen)
+{
+   struct mtd_partition *parts;
+   char *names;
+   int nparts;
+   int ret, i, namelen = 0;
+
+   if (!fmap_check_signature(fmap))
+   

[RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

[Brian Norris]

The platform description (such as the type of partition formats used on
a given flash) should be done independently of the flash driver in use.
However, we can't reasonably have *all* partition parsers run on all
flash (until they find a match), so let's overload the 'partitions'
subnode to support specifying which format(s) to try in the device tree.

Start by supporting Google's (Chrome OS) FMAP structure.

There have been others interested in extending devicetree support to
other parsers, like the bcm47xxpart parser:

  http://patchwork.ozlabs.org/patch/475986/

and the AFS (ARM Flash Structure?) parser:

  http://patchwork.ozlabs.org/patch/537827/

Signed-off-by: Brian Norris 
---
 .../devicetree/bindings/mtd/partition.txt  | 75 --
 1 file changed, 69 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
b/Documentation/devicetree/bindings/mtd/partition.txt
index 28ae56f5c972..1bf9a7243993 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -1,29 +1,56 @@
-Representing flash partitions in devicetree
+Flash partitions in device tree
+===
 
-Partitions can be represented by sub-nodes of an mtd device. This can be used
+Flash devices can be partitioned into one or more functional ranges (e.g.,
+"boot code", "nvram", and "kernel") in at least two distinct ways:
+
+ (A) a fixed flash layout at production time or
+ (B) with an on-flash partition table, such as RedBoot, that describes the
+ geometry and naming/purpose of each functional region
+
+The former typically requires an operating system to learn about the
+partitioning from some kind of metadata provided by the bootloader/firmware.
+Such partitions can be described using the method in "Section A: Fixed 
Partitions".
+
+The latter is somewhat analogous to partition tables used on block devices
+(e.g., MBR or GPT), except that there is less standardization for flash
+devices, and it is not always safe or efficient to attempt to search for all of
+them on every flash device in the system, particularly since many of them allow
+their data structures to be placed anywhere on the flash, and so require
+scanning the entire flash device to find them.
+
+To assist system software in locating these partition tables, we provide a
+binding to describe which partition format(s) may be used on a given flash,
+found below in "Section B: On-Flash Partition Tables".
+
+
+Section A: Fixed Partitions
+---
+
+Partitions can be represented by sub-nodes of a flash device. This can be used
 on platforms which have strong conventions about which portions of a flash are
 used for what purposes, but which don't use an on-flash partition table such
 as RedBoot.
 
-The partition table should be a subnode of the mtd node and should be named
+The partition table should be a subnode of the flash node and should be named
 'partitions'. This node should have the following property:
 - compatible : (required) must be "partitions"
 Partitions are then defined in subnodes of the partitions node.
 
-For backwards compatibility partitions as direct subnodes of the mtd device are
+For backwards compatibility partitions as direct subnodes of the flash device 
are
 supported. This use is discouraged.
 NOTE: also for backwards compatibility, direct subnodes that have a compatible
 string are not considered partitions, as they may be used for other bindings.
 
 #address-cells & #size-cells must both be present in the partitions subnode of 
the
-mtd device. There are two valid values for both:
+flash device. There are two valid values for both:
 <1>: for partitions that require a single 32-bit cell to represent their
  size/address (aka the value is below 4 GiB)
 <2>: for partitions that require two 32-bit cells to represent their
  size/address (aka the value is 4 GiB or greater).
 
 Required properties:
-- reg : The partition's offset and size within the mtd bank.
+- reg : The partition's offset and size within the flash
 
 Optional properties:
 - label : The label / name for this partition.  If omitted, the label is taken
@@ -89,3 +116,39 @@ flash@2 {
};
};
 };
+
+
+Section B: On-Flash Partition Tables
+
+
+System designers use a variety of on-flash data structures to describe the
+layout of the flash. Because it's not always optimal for system software to
+scan for every sort of data structure that might be used, one can specify which
+structure(s) might be used on a given flash using the 'partitions' subnode of
+the flash node.
+
+Node name: partitions
+Properties:
+ - compatible: (required) used to define which partition format(s) may be in
+   use on this flash may contain one or more of the strings defined in the
+   following subsections
+
+
+Google's FMAP (Flash MAP)
+#
+
+Often used to describe 

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

[Brian Norris]

Hi,

There have been several discussions [1] about adding a device tree binding for
associating flash devices with the partition parser(s) that are used on the
flash. There are a few reasons:

 (1) drivers shouldn't have to be encoding platform knowledge by listing what
 parsers might be used on a given system (this is the currently all that's
 supported)
 (2) we can't just scan for all supported parsers (like the block system does), 
since
 there is a wide diversity of "formats" (no standardization), and it is not
 always safe or efficient to attempt to do so, particularly since many of
 them allow their data structures to be placed anywhere on the flash, and
 so require scanning the entire flash device to find them.

So instead, let's support a new binding so that a device tree can specify what
partition formats might be used. This seems like a reasonable choice (even
though it's not strictly a hardware description) because the flash layout /
partitioning is often very closely tied with the bootloader/firmware, at
production time.

Also, as an example first-use of this mechanism, I support Google's FMAP flash
structure, used on Chrome OS devices.

Note that this is an RFC, mainly for the reason noted in patch 6 ("RFC: mtd:
partitions: enable of_match_table matching"): the of_match_table support won't
yet autoload a partition parser that is built as a module. I'm not quite sure
if there's a lot of value in supporting MTD parsers as modules (block partition
support can't be), but that is supported for "by-name" parser lookups in MTD
already, so I don't feel like dropping that feature yet. Tips or thoughts are
particularly welcome on this aspect!

Also note that there's an existing undocumented binding for a
"linux,part-probe" property, but it is only usable on the physmap_of.c driver
at the moment, and it is IMO not a good binding. I posted my thoughts on that
previously here [2], and since no one else cared to make a better one...I did
it myself.

I'd love it if we could kill the unreviewed binding off in favor of something
more like this...

Currently based on v2 of "mtd: partitions: support cleanup callback for
parsers":

  
http://lkml.kernel.org/g/1449271518-118900-1-git-send-email-computersforpe...@gmail.com

and this series
("mtd: ofpart: don't complain about missing 'partitions' node too loudly" and
"doc: dt: mtd: partitions: add compatible property to "partitions" node"):

  
http://lkml.kernel.org/g/1449194529-145705-1-git-send-email-computersforpe...@gmail.com

Both of which should hopefully be merged soon.

The current total of this work is stashed here for now:

  git fetch git://git.infradead.org/users/norris/linux-mtd.git 
partition-of-match

I may rewrite this branch if I post future revisions of these patch sets, FYI.

I look forward to your reviews.

Regards,
Brian

[1] Trying to extend "linux,part-probe":
http://patchwork.ozlabs.org/patch/475988/
For bcm47xxpart:
http://patchwork.ozlabs.org/patch/475986/
For AFS:
http://patchwork.ozlabs.org/patch/537827/

[2] "mtd: document linux-specific partition parser DT binding"
http://lists.infradead.org/pipermail/linux-mtd/2015-October/062773.html

Brian Norris (7):
  mtd: move partition parsers to drivers/mtd/partitions/
  mtd: move partition parsers' Kconfig under a sub-menu
  doc: dt: mtd: partition: add on-flash format binding
  mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers
  mtd: partitions: factor out "match by name" handling
  RFC: mtd: partitions: enable of_match_table matching
  mtd: partitions: add Google's FMAP partition parser

 .../devicetree/bindings/mtd/partition.txt  |  75 ++-
 drivers/mtd/Kconfig| 134 +---
 drivers/mtd/Makefile   |   8 +-
 drivers/mtd/mtdpart.c  |  99 +++--
 drivers/mtd/partitions/Kconfig | 138 +
 drivers/mtd/partitions/Makefile|   8 +
 drivers/mtd/{ => partitions}/afs.c |   0
 drivers/mtd/{ => partitions}/ar7part.c |   0
 drivers/mtd/{ => partitions}/bcm47xxpart.c |   0
 drivers/mtd/{ => partitions}/bcm63xxpart.c |   0
 drivers/mtd/{ => partitions}/cmdlinepart.c |   0
 drivers/mtd/partitions/google_fmap.c   | 226 +
 drivers/mtd/{ => partitions}/ofpart.c  |   0
 drivers/mtd/{ => partitions}/redboot.c |   0
 drivers/of/of_mtd.c|  33 +++
 include/linux/mtd/partitions.h |   2 +
 include/linux/of_mtd.h |  13 ++
 17 files changed, 577 insertions(+), 159 deletions(-)
 create mode 100644 drivers/mtd/partitions/Kconfig
 create mode 100644 drivers/mtd/partitions/Makefile
 rename drivers/mtd/{ => partitions}/afs.c (100%)
 rename drivers/mtd/{ => partitions}/ar7part.c (100%)
 rename drivers/mtd/{ => partitions

[RFC][PATCH] devicetree: Add DTS file to support the Nexus7 2013 (flo) device.

[John Stultz]

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

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

This is my first DTS submission, so thoughts or feedback
on would be appreciated.

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

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..c0f9076a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -502,6 +502,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += \
 dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
+   qcom-apq8064-nexus7-flo.dtb \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts 
b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
new file mode 100644
index 000..5183d18
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
@@ -0,0 +1,306 @@
+#include "qcom-apq8064-v2.0.dtsi"
+#include 
+#include 
+#include 
+/ {
+   model = "Qualcomm APQ8064/Nexus7(flo)";
+   compatible = "qcom,apq8064-nexus7-flo", "qcom,apq8064";
+
+   aliases {
+   serial0 = &gsbi7_serial;
+   serial1 = &gsbi6_serial;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   soc {
+   rpm@108000 {
+   regulators {
+   vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
+   vin_lvs1_3_6-supply = <&pm8921_s4>;
+   vin_lvs4_5_7-supply = <&pm8921_s4>;
+
+
+   vdd_l24-supply = <&pm8921_s1>;
+   vdd_l25-supply = <&pm8921_s1>;
+   vin_lvs2-supply = <&pm8921_s1>;
+
+   vdd_l26-supply = <&pm8921_s7>;
+   vdd_l27-supply = <&pm8921_s7>;
+   vdd_l28-supply = <&pm8921_s7>;
+
+   vdd_ncp-supply = <&pm8921_l6>;
+
+   /* Buck SMPS */
+   pm8921_s1: s1 {
+   regulator-always-on;
+   regulator-min-microvolt = <1225000>;
+   regulator-max-microvolt = <1225000>;
+   qcom,switch-mode-frequency = <320>;
+   bias-pull-down;
+   };
+
+   /* msm otg HSUSB_VDDCX */
+   pm8921_s3: s3 {
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <115>;
+   qcom,switch-mode-frequency = <480>;
+   };
+
+   /*
+* msm_sdcc.1-sdc-vdd_io
+* tabla2x-slim-CDC_VDDA_RX
+* tabla2x-slim-CDC_VDDA_TX
+* tabla2x-slim-CDC_VDD_CP
+* tabla2x-slim-VDDIO_CDC
+*/
+   pm8921_s4: s4 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   qcom,switch-mode-frequency = <320>;
+   regulator-always-on;
+   };
+
+   pm8921_s7: s7 {
+   regulator-min-microvolt = <130>;
+   regulator-max-microvolt = <130>;
+   qcom,switch-mode-frequency = <320>;
+   };
+
+   /* mipi_dsi.1-dsi1_pll_vdda */
+   pm8921_l2: l2 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   };
+
+   /* msm_otg-HSUSB_3p3 */
+   pm8921_l3: l3 {
+   regulator-min-microv

Re: [PATCH v2 03/10] drm/hisilicon: Add hisilicon DRM master driver

[Xinliang Liu]

On 4 December 2015 at 00:21, Rob Herring  wrote:
> On Sat, Nov 28, 2015 at 4:38 AM, Xinliang Liu  wrote:
>> Add DRM master driver for hi6220 SoC which used in HiKey board.
>> Add dumb buffer feature.
>> Add prime dmabuf feature.
>>
>> Signed-off-by: Xinliang Liu 
>> Signed-off-by: Xinwei Kong 
>> Signed-off-by: Andy Green 
>> ---
>
>> +static int hisi_gem_cma_dumb_create(struct drm_file *file,
>> +   struct drm_device *dev,
>> +   struct drm_mode_create_dumb *args)
>> +{
>> +   int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>
> BTW, is args->bpp supposed to be bits or bytes? I'm using your dumb bo
> support in drm_gralloc which does bytes as that is what
> gralloc_drm_get_bpp returns. The virtio-gpu driver does bits. I'm
> guessing bits is correct.

yes, it is bits. And pitch is bytes.

>
> 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 v5 2/5] ARM: BCM: Clean up SMP support for Broadcom Kona

[Florian Fainelli]

On 04/12/15 12:23, Kapil Hali wrote:
> These changes cleans up SMP implementaion for Broadcom's
> Kona SoC which are required for handling SMP for iProc
> family of SoCs at a single place for BCM NSP and BCM Kona.
> 
> Signed-off-by: Kapil Hali 
> ---
>  arch/arm/boot/dts/bcm11351.dtsi |  2 +-
>  arch/arm/boot/dts/bcm21664.dtsi |  2 +-
>  arch/arm/mach-bcm/kona_smp.c| 82 
> +++--
>  3 files changed, 56 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 2ddaa51..3dc7a8c 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -31,7 +31,6 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   enable-method = "brcm,bcm11351-cpu-method";
> - secondary-boot-reg = <0x3500417c>;

I would expect the 'enable-method' to be moved as well to be consistent
with what you are adding for NSP later on.

>  
>   cpu0: cpu@0 {
>   device_type = "cpu";
> @@ -42,6 +41,7 @@
>   cpu1: cpu@1 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a9";
> + secondary-boot-reg = <0x3500417c>;
>   reg = <1>;
>   };
-- 
Florian
--
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/5] dt-bindings: add SMP enable-method for Broadcom NSP

[Florian Fainelli]

On 04/12/15 12:23, Kapil Hali wrote:
> Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's
> Northstar Plus CPU to the 32-bit ARM CPU device tree binding
> documentation file and create a new binding documentation for
> Northstar Plus CPU.
> 
> Signed-off-by: Kapil Hali 
> ---
>  .../bindings/arm/bcm/brcm,nsp-cpu-method.txt   | 39 
> ++
>  Documentation/devicetree/bindings/arm/cpus.txt |  1 +
>  2 files changed, 40 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt 
> b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
> new file mode 100644
> index 000..bf08872
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
> @@ -0,0 +1,39 @@
> +Broadcom Northstar Plus SoC CPU Enable Method
> +-
> +This binding defines the enable method used for starting secondary
> +CPUs in the following Broadcom SoCs:
> +  BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
> +
> +The enable method is specified by defining the following required
> +properties in the "cpus" device tree node:
> +  - enable-method = "brcm,bcm-nsp-smp";
> +  - secondary-boot-reg = <...>;

That comment is not quite correct with respect to the paragraph below then?

> +
> +The secondary-boot-reg property is a u32 value that specifies the
> +physical address of the register which should hold the common
> +entry point for a secondary CPU. This entry is cpu node specific
> +and should be added per cpu. E.g., in case of NSP (BCM58625) which
> +is a dual core CPU SoC, this entry should be added to cpu1 node.
> +
> +
> +Example:
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + enable-method = "brcm,bcm-nsp-smp";

Based on the requested feedback, this property should now be placed
under the cpu1 node.

> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + next-level-cache = <&L2>;
> + reg = <0>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + next-level-cache = <&L2>;
> + reg = <1>;
> + secondary-boot-reg = <0x042c>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 3a07a87..d191554 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -190,6 +190,7 @@ nodes to be present and contain the properties described 
> below.
>   "allwinner,sun6i-a31"
>   "allwinner,sun8i-a23"
>   "arm,psci"
> + "brcm,bcm-nsp-smp"
>   "brcm,brahma-b15"
>   "marvell,armada-375-smp"
>   "marvell,armada-380-smp"
> 


-- 
Florian
--
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 02/12] drm/etnaviv: add devicetree bindings

[Ilia Mirkin]

On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux
 wrote:
> On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
>> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
>>  wrote:
>> > Moreover, DRI3 is not yet available for Gallium, so if we're talking
>> > about Xorg, then functional DRI2 is a requirement, and that _needs_
>> > to have a single device for the rendering instances.  Xorg has no way
>> > to pass multiple render nodes to client over DRI2.
>>
>> Just to correct... DRI3 has been available on gallium [at least in the
>> context of st/mesa] basically since DRI3 was introduced. Not sure what
>> issue you're fighting with, but it's definitely not a gallium
>> limitation... could be something related to platform devices.
>
> Well, my statement is based on the fact that there's nothing in
> src/gallium/state-tracker/dri which hints at being DRI3.  Maybe it's
> implemented differently, I don't know.  I never wanted to hack MESA -
> I'm supposed to be the ARM kernel maintainer - and I'm still very new
> to MESA.
>
> I think it's a DRI3 limitation.  The issue with the DRI3 design is that:
>
> * The client has access to the GPU render nodes only, but not the
>   corresponding KMS node.
> * Buffers in DRI3 are allocated from the GPU render nodes.
> * The Xorg Present protocol is then used to manage the vblank
>   synchonisation and page flips.
>
> Now, the KMS scanout hardware typically does not support any kind of
> scatter-gather: the buffers it has must be contiguous.  These can be
> allocated from the KMS DRM device.
>
> However, the DRI3 client has no access to the KMS DRM device to allocate
> linear buffers from, and GPUs typically don't have dumb buffer support.
> Hence, the client can't pass a suitable buffer to the present layer.
>
> Hence, I can see no way for the resource_create() to be able to allocate
> any kind of scanout capable buffer.
>
> That's a separate issue though: you've pointed out that you can select
> which render node to use: what if we want to use multiple render nodes
> simultaneously - eg, because we want to use multiple 3D GPU cores
> together?  How does that work with stuff?

This is a bit like the SLI question -- let's say you have 2 pricey
desktop GPUs, with a fast interconnect between them, which lets them
know about each other, how do you make use of that. Solution: unsolved
:)

In an ideal world, you'd have a single driver that knows how to
interact with multiple devices and make them do cool things. However
this a completely untrodden path. (Not to mention the problem of *how*
to break up a workload across 2 GPUs.)

>
> I think the idea that individual GPU cores should be exposed as
> separate DRM devices is fundamentally flawed, and adds a hell of a
> lot of complexity.
>
> In any case, I've spent _way_ too much time on etnaviv during November -
> quite literally almost every day (I worked out that I was producing 4.5
> patches a day during November for Etnaviv MESA.)  I'm afraid that it's
> now time that I switch my attention elsewhere, so if this means that
> Etnaviv is rejected for merging, I'm afraid it'll be a few months before
> I can get back to it.
>
> It would have been nice if these issues had been brought up much earlier,
> during the RFC posting of the patches.  These are nothing new, and I now
> feel that this whole thing has been a total waste of time.

The whole multi-gpu thing is a bit of an open question right now. It
works in theory, but in practice nobody's done it. Maarten tried to
get nouveau/gk20a + tegra/drm on Jetson TK1 to play nice with, e.g., X
2d accel, and it was an exercise in pain. Not sure that he ever
succeeded.

I think it's unfair to try to make new hardware enablement the time to
attempt to heap extra work onto those authors unfortunate enough to
have slightly unorthodox hardware that maps nicely onto some
desired-but-not-quite-there-yet usage model -- they have enough
problems.

The way everything works is one drm node can do everything. PRIME is a
barely-functional way to offload some things onto a (single) secondary
GPU. Everything beyond that is purely theoretical.

None of what's being done now prevents some future where these things
are broken up. No need to force it now.

  -ilia
--
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 13/12] ARM: dts: dove: add DT GPU support

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 09:49:18PM +0100, Andrew Lunn wrote:
> > This additional patch is in conjunction with my PMU (already merged)
> > and clock driver patch sets.
> 
> Hi Russell
> 
> Please could you respond to my comment about the clock patch.
> 
> http://www.spinics.net/lists/devicetree/msg104464.html

I'm sorry, I haven't had time to look at that your comment yet.  I've
totally forgotten that you made it, or even what the comment was.  I'll
look at it at some point though, if I remember.  That's the best I can
promise.

-- 
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 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
>  wrote:
> > Moreover, DRI3 is not yet available for Gallium, so if we're talking
> > about Xorg, then functional DRI2 is a requirement, and that _needs_
> > to have a single device for the rendering instances.  Xorg has no way
> > to pass multiple render nodes to client over DRI2.
> 
> Just to correct... DRI3 has been available on gallium [at least in the
> context of st/mesa] basically since DRI3 was introduced. Not sure what
> issue you're fighting with, but it's definitely not a gallium
> limitation... could be something related to platform devices.

Well, my statement is based on the fact that there's nothing in
src/gallium/state-tracker/dri which hints at being DRI3.  Maybe it's
implemented differently, I don't know.  I never wanted to hack MESA -
I'm supposed to be the ARM kernel maintainer - and I'm still very new
to MESA.

I think it's a DRI3 limitation.  The issue with the DRI3 design is that:

* The client has access to the GPU render nodes only, but not the
  corresponding KMS node.
* Buffers in DRI3 are allocated from the GPU render nodes.
* The Xorg Present protocol is then used to manage the vblank
  synchonisation and page flips.

Now, the KMS scanout hardware typically does not support any kind of
scatter-gather: the buffers it has must be contiguous.  These can be
allocated from the KMS DRM device.

However, the DRI3 client has no access to the KMS DRM device to allocate
linear buffers from, and GPUs typically don't have dumb buffer support.
Hence, the client can't pass a suitable buffer to the present layer.

Hence, I can see no way for the resource_create() to be able to allocate
any kind of scanout capable buffer.

That's a separate issue though: you've pointed out that you can select
which render node to use: what if we want to use multiple render nodes
simultaneously - eg, because we want to use multiple 3D GPU cores
together?  How does that work with stuff?

I think the idea that individual GPU cores should be exposed as
separate DRM devices is fundamentally flawed, and adds a hell of a
lot of complexity.

In any case, I've spent _way_ too much time on etnaviv during November -
quite literally almost every day (I worked out that I was producing 4.5
patches a day during November for Etnaviv MESA.)  I'm afraid that it's
now time that I switch my attention elsewhere, so if this means that
Etnaviv is rejected for merging, I'm afraid it'll be a few months before
I can get back to it.

It would have been nice if these issues had been brought up much earlier,
during the RFC posting of the patches.  These are nothing new, and I now
feel that this whole thing has been a total waste of time.

-- 
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] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Tony Lindgren]

* Arnd Bergmann  [151204 13:38]:
> On Friday 04 December 2015 10:47:07 Tony Lindgren wrote:
> > > Peter Ujfalusi  writes:
> > > > @@ -174,12 +182,44 @@
> > > > };
> > > >  
> > > > edma: edma@4900 {
> > > > -   compatible = "ti,edma3";
> > > > -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> > > > -   reg =   <0x4900 0x1>,
> > > > -   <0x44e10f90 0x40>;
> > > > +   compatible = "ti,edma3-tpcc";
> > > > +   ti,hwmods = "tpcc";
> > > > +   reg =   <0x4900 0x1>;
> > > > +   reg-names = "edma3_cc";
> > > > interrupts = <12 13 14>;
> > > > -   #dma-cells = <1>;
> > > > +   interrupt-names = "edma3_ccint", "emda3_mperr",
> > > > + "edma3_ccerrint";
> > > > +   dma-requests = <64>;
> > > > +   #dma-cells = <2>;
> > > > +
> > > > +   ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
> > > > +  <&edma_tptc2 0>;
> > > > +
> > > > +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> > > 
> > > can you explain this property here ? Are you setting bits 20 and 21 on a
> > > 16-bit field ?
> > 
> > I think it's an arry of u16 dma channels.. But could it be just /bits/ 8
> > instead of /bits/ 16?
> > 
> 
> Please just drop the /bits/ 16 and use normal cells.

Yeah agreed, makes things less confusing for sure :)

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

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Arnd Bergmann]

On Friday 04 December 2015 10:47:07 Tony Lindgren wrote:
> > Peter Ujfalusi  writes:
> > > @@ -174,12 +182,44 @@
> > > };
> > >  
> > > edma: edma@4900 {
> > > -   compatible = "ti,edma3";
> > > -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> > > -   reg =   <0x4900 0x1>,
> > > -   <0x44e10f90 0x40>;
> > > +   compatible = "ti,edma3-tpcc";
> > > +   ti,hwmods = "tpcc";
> > > +   reg =   <0x4900 0x1>;
> > > +   reg-names = "edma3_cc";
> > > interrupts = <12 13 14>;
> > > -   #dma-cells = <1>;
> > > +   interrupt-names = "edma3_ccint", "emda3_mperr",
> > > + "edma3_ccerrint";
> > > +   dma-requests = <64>;
> > > +   #dma-cells = <2>;
> > > +
> > > +   ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
> > > +  <&edma_tptc2 0>;
> > > +
> > > +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> > 
> > can you explain this property here ? Are you setting bits 20 and 21 on a
> > 16-bit field ?
> 
> I think it's an arry of u16 dma channels.. But could it be just /bits/ 8
> instead of /bits/ 16?
> 

Please just drop the /bits/ 16 and use normal cells.

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 1/3] mtd: brcmnand: Add brcm,bcm6368-nand device tree binding

[Simon Arlott]

On Fri, December 4, 2015 16:04, Jonas Gorski wrote:
> On Thu, Dec 3, 2015 at 12:41 AM, Simon Arlott  wrote:
>> +   * "brcm,nand-bcm6368"
>> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm6368"
>> + - reg: (required) the 'NAND_INTR_BASE' register range, with combined 
>> status
>> +   and enable registers, and boot address registers
>> + - reg-names: (required) "nand-intr-base"
>
> Can't we use the same name as bcm63138, i.e. nand-int-base?

Brian,

Before I change this, is there anything else in the patch series that needs to
be changed?

(I'll keep the comment referring to "NAND_INTR_BASE" the same because that's 
the name
in the original #define for this hardware.)

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

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Bjorn Helgaas]

Hi Simon,

On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> Simply document new compat strings.
> There appears to be no need for a driver updates.
> 
> Signed-off-by: Simon Horman 
> ---
>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt 
> b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> index b19be08a8113..7c231b3e5872 100644
> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
>  Required properties:
>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> "renesas,pci-r8a7791" for the R8A7791 SoC;
> +   "renesas,pci-r8a7793" for the R8A7793 SoC;

What's the benefit of adding a string here if the driver doesn't check
for it?  Since the driver doesn't look for it, there's no way to test
anything.

It doesn't seem like this file is an authoritative source of names, so
if we add it here, there's the possibility the r8a7793 will be
canceled or renamed, and then we'd have to update this if the driver
ever did need an r8a7793-specific quirk.  If we waited until the
driver actually needs a quirk, then we'd know exactly what name to
look for and we could update the driver, DT, and doc all together.

> "renesas,pci-r8a7794" for the R8A7794 SoC;
> "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
>  
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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

[PATCH v5 4/4] ARM: dts: sun8i: Add Orange Pi Plus support

[Jens Kuske]

The Orange Pi Plus is a SBC based on the Allwinner H3 SoC
with 8GB eMMC, multiple USB ports through a USB hub chip, SATA through
a USB-SATA bridge, one uSD slot, a 10/100/1000M ethernet port,
WiFi, HDMI, headphone jack, IR receiver, a microphone, a CSI connector
and a 40-pin GPIO header.

Signed-off-by: Jens Kuske 
---
 arch/arm/boot/dts/Makefile   |  3 +-
 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 77 
 2 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8f44c7..cc7309b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -661,7 +661,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-ga10h-v1.1.dtb \
sun8i-a33-ippo-q8h-v1.2.dtb \
sun8i-a33-q8-tablet.dtb \
-   sun8i-a33-sinlinx-sina33.dtb
+   sun8i-a33-sinlinx-sina33.dtb \
+   sun8i-h3-orangepi-plus.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
sun9i-a80-cubieboard4.dtb
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
new file mode 100644
index 000..e67df59
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2015 Jens Kuske 
+ *
+ * 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 "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "Xunlong Orange Pi Plus";
+   compatible = "xunlong,orangepi-plus", "allwinner,sun8i-h3";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&mmc0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+   vmmc-supply = <®_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+   cd-inverted;
+   status = "okay";
+};
+
+&uart0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart0_pins_a>;
+   status = "okay";
+};
-- 
2.6.3

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

[PATCH v5 3/4] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Jens Kuske]

The Allwinner H3 is a home entertainment system oriented SoC with
four Cortex-A7 cores and a Mali-400MP2 GPU.

Signed-off-by: Jens Kuske 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 497 
 1 file changed, 497 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-h3.dtsi

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
new file mode 100644
index 000..1524130e
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -0,0 +1,497 @@
+/*
+ * Copyright (C) 2015 Jens Kuske 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "skeleton.dtsi"
+
+#include 
+#include 
+
+/ {
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0>;
+   };
+
+   cpu@1 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <1>;
+   };
+
+   cpu@2 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <2>;
+   };
+
+   cpu@3 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <3>;
+   };
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+,
+,
+;
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   osc24M: osc24M_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   osc32k: osc32k_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+   clock-output-names = "osc32k";
+   };
+
+   pll1: clk@01c2 {
+   #clock-cells = <0>;
+   compatible = "allwinner,sun8i-a23-pll1-clk";
+   reg = <0x01c2 0x4>;
+   clocks = <&osc24M>;
+   clock-output-names = "pll1";
+   };
+
+   /* dummy clock until actually implemented */
+   pll5: pll5_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+   clock-output-names = "pll5";
+   };
+
+   pll6: clk@01c20028 {
+   #clock-cells = <1>;
+  

[PATCH v5 1/4] clk: sunxi: Add H3 clocks support

[Jens Kuske]

The H3 clock control unit is similar to the those of other sun8i family
members like the A23.

It adds a new bus gates clock similar to the simple gates, but with a
different parent clock for each single gate.
Some of the gates use the new AHB2 clock as parent, whose clock source
is muxable between AHB1 and PLL6/2. The documentation isn't totally clear
about which devices belong to AHB2 now, especially USB EHIC/OHIC, so it
is mostly based on Allwinner kernel source code.

Signed-off-by: Jens Kuske 
---
 Documentation/devicetree/bindings/clock/sunxi.txt |   2 +
 drivers/clk/sunxi/Makefile|   1 +
 drivers/clk/sunxi/clk-sun8i-bus-gates.c   | 112 ++
 drivers/clk/sunxi/clk-sunxi.c |   6 ++
 4 files changed, 121 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-sun8i-bus-gates.c

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 153ac72..437962d 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -29,6 +29,7 @@ Required properties:
"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
"allwinner,sun9i-a80-cpus-clk" - for the CPUS on A80
"allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
+   "allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
@@ -56,6 +57,7 @@ Required properties:
"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
+   "allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 103efab..abf4916 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-a10-pll2.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
+obj-y += clk-sun8i-bus-gates.o
 obj-y += clk-sun8i-mbus.o
 obj-y += clk-sun9i-core.o
 obj-y += clk-sun9i-mmc.o
diff --git a/drivers/clk/sunxi/clk-sun8i-bus-gates.c 
b/drivers/clk/sunxi/clk-sun8i-bus-gates.c
new file mode 100644
index 000..7ab60c5
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun8i-bus-gates.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2015 Jens Kuske 
+ *
+ * Based on clk-simple-gates.c, which is:
+ * Copyright 2015 Maxime Ripard
+ *
+ * Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_SPINLOCK(gates_lock);
+
+static void __init sun8i_h3_bus_gates_init(struct device_node *node)
+{
+   static const char * const names[] = { "ahb1", "ahb2", "apb1", "apb2" };
+   enum { AHB1, AHB2, APB1, APB2, PARENT_MAX } clk_parent;
+   const char *parents[PARENT_MAX];
+   struct clk_onecell_data *clk_data;
+   const char *clk_name;
+   struct property *prop;
+   struct resource res;
+   void __iomem *clk_reg;
+   void __iomem *reg;
+   const __be32 *p;
+   int number, i;
+   u8 clk_bit;
+   u32 index;
+
+   reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+   if (IS_ERR(reg))
+   return;
+
+   for (i = 0; i < ARRAY_SIZE(names); i++) {
+   index = of_property_match_string(node, "clock-names",
+names[i]);
+   if (index < 0)
+   return;
+
+   parents[i] = of_clk_get_parent_name(node, index);
+   }
+
+   clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
+   if (!clk_data)
+   goto err_unmap;
+
+   number = of_property_count_u32_elems(node, "clock-indices");
+   of_property_read_u32_index(node, "clock-indices", number - 1, &number);
+
+   clk_data->clks = kcalloc(number + 1, sizeof(struct clk *), GFP_KERNEL);
+   if (!clk_data->clks)
+   goto err_free_data;
+
+   i = 0;
+   of_property_for_each_u3

[PATCH v5 2/4] pinctrl: sunxi: Add H3 PIO controller support

[Jens Kuske]

The H3 uses the same pin controller as previous SoC's from Allwinner.
Add support for the pins controlled by the main PIO controller.

Signed-off-by: Jens Kuske 
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 drivers/pinctrl/sunxi/Kconfig  |   4 +
 drivers/pinctrl/sunxi/Makefile |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c   | 515 +
 4 files changed, 521 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index b321b26..e6ba602 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -18,6 +18,7 @@ Required properties:
   "allwinner,sun8i-a23-r-pinctrl"
   "allwinner,sun8i-a33-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
+  "allwinner,sun8i-h3-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index e68fd95..89ab7f5 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -51,6 +51,10 @@ config PINCTRL_SUN8I_A23_R
depends on RESET_CONTROLLER
select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN8I_H3
+   def_bool MACH_SUN8I
+   select PINCTRL_SUNXI_COMMON
+
 config PINCTRL_SUN9I_A80
def_bool MACH_SUN9I
select PINCTRL_SUNXI_COMMON
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index e080290..6bd818e 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -13,4 +13,5 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23)   += 
pinctrl-sun8i-a23.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23_R)  += pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)   += pinctrl-sun8i-a83t.o
+obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c 
b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
new file mode 100644
index 000..77d4cf0
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
@@ -0,0 +1,515 @@
+/*
+ * Allwinner H3 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2015 Jens Kuske 
+ *
+ * Based on pinctrl-sun8i-a23.c, which is:
+ * Copyright (C) 2014 Chen-Yu Tsai 
+ * Copyright (C) 2014 Maxime Ripard 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_h3_pins[] = {
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart2"), /* TX */
+ SUNXI_FUNCTION(0x3, "jtag"),  /* MS */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),  /* PA_EINT0 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart2"), /* RX */
+ SUNXI_FUNCTION(0x3, "jtag"),  /* CK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),  /* PA_EINT1 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart2"), /* RTS */
+ SUNXI_FUNCTION(0x3, "jtag"),  /* DO */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),  /* PA_EINT2 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart2"), /* CTS */
+ SUNXI_FUNCTION(0x3, "jtag"),  /* DI */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),  /* PA_EINT3 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart0"), /* TX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),  /* PA_EINT4 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart0"), /* RX */
+ SUNXI_FUNCTION(0x3, "pwm0"),
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),  /* PA_EINT5 */
+   SUNXI_PIN(SUNXI_PINCTRL

[PATCH v5 0/4] ARM: sunxi: Allwinner H3 support

[Jens Kuske]

Hi everyone,

This is v5 of my patch series introducing basic kernel support for Allwinner's
H3 SoC. It mainly adds basic clocks, resets and pinctrl. It also adds
interrupts, timers, watchdog, RTC, dmaengine, MMC and UARTs, which are mostly
compatible to those in earlier SoCs like A23 and A31, and can simply be reused.

These patches are based on the sunxi-next branch from
git://github.com/linux-sunxi/linux-sunxi.git


Patch 1 adds basic H3 clocks.

Patch 2 adds pin sets for the H3 main PIO.

Patch 3 adds the DTSI for the H3.

Patch 4 adds a DTS for the Orange Pi Plus SBC, which these patches
were developed and tested with.

Changes since v4:
- drop the pll clock cleanup and use dummy clocks instead for now, Maxime
  wants to take care of cleaning up the plls
- split the resets again (as in v1), drop the of_xlate
- fix all reported pinctrl mistakes
- remove memory node and timer frequency from dtsi
- rename the bus gates to bus_*
- clean up the bus gates driver

Changes since v3:
- add a clock driver specific to the bus gates instead of listing parents in
  the DTSI
- skip the holes in the reset controller with of_xlate()

Changes since v2:
- add mbus clock
- add Maxime's suggestion to take the substring up to the first "_" as name
  for the divs base clock
- use A31 pll6 for H3 pll6
- use a clock similar to the new simple gates for H3 bus gates
- drop the pinctrl-as-module patch since pinctrl and gpio don't seem to be
  ready for removable drivers
- documentation and machine support are merged already
  
Changes since v1:
- Update sunxi README in Documentation
- Add the multiple parents gates and use them for bus-gates instead of
  ahb1, ahb2, apb1 and apb2 gates
- Merge the pll8 clock with sun6i pll6
- Merge the ahb12, apb1 and apb2 resets to bus-resets with own compatible
- Add sun6i_timer_init to sun8i machine
- Remove the single SoC names from machine definition, its sun8i family
- Make the pinctrl driver tristate and put its Kconfig entry in the right order
- Rename pinctrl "scr" to "sim" and clock "sim" to "scr" to match user manual
- Remove the address paragraph from GPL in dts and dtsi
- Some style cleanup and line wrapping in dtsi
- Add ARM architected timers
- dmaengine isn't included anymore, it is merged already

Best Regards,
Jens


Jens Kuske (4):
  clk: sunxi: Add H3 clocks support
  pinctrl: sunxi: Add H3 PIO controller support
  ARM: dts: sunxi: Add Allwinner H3 DTSI
  ARM: dts: sun8i: Add Orange Pi Plus support

 Documentation/devicetree/bindings/clock/sunxi.txt  |   2 +
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts   |  77 +++
 arch/arm/boot/dts/sun8i-h3.dtsi| 497 
 drivers/clk/sunxi/Makefile |   1 +
 drivers/clk/sunxi/clk-sun8i-bus-gates.c| 112 +
 drivers/clk/sunxi/clk-sunxi.c  |   6 +
 drivers/pinctrl/sunxi/Kconfig  |   4 +
 drivers/pinctrl/sunxi/Makefile |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c   | 515 +
 11 files changed, 1218 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
 create mode 100644 arch/arm/boot/dts/sun8i-h3.dtsi
 create mode 100644 drivers/clk/sunxi/clk-sun8i-bus-gates.c
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c

-- 
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/2] reset: Add brcm,bcm6345-reset device tree binding

[Simon Arlott]

On Thu, December 3, 2015 08:39, Philipp Zabel wrote:
> Am Mittwoch, den 02.12.2015, 21:03 + schrieb Simon Arlott:
>> +periph_soft_rst: reset-controller {
>> +compatible = "brcm,bcm63168-reset", "brcm,bcm6345-reset";
>> +regmap = <&periph_cntl>;
>> +offset = <0x10>;
>> +
>> +#reset-cells = <1>;
>> +};
>
> I would have written it something like this:
>
> periph_cntl: ... {
>   compatible = "syscon", "simple-mfd";
>   #address-cells = <1>;
>   #size-cells = <1>;
>
>   periph_soft_rst: reset-controller {
>   compatible = "brcm,bcm6345-reset";
>   reg = <0x10 0x4>;
>   #reset-cells = <1>;
>   };
> };
>
> for a device that is only controlled through a syscon.

Rob, do you want me to change this or is my version ok?

> The driver itself looks good to me.
>
> best regards
> Philipp
>
>

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

Re: [PATCH 1/2] clk: Add brcm,bcm63xx-gate-clk device tree binding

[Simon Arlott]

On Fri, December 4, 2015 14:30, Rob Herring wrote:
> On Mon, Nov 30, 2015 at 08:52:55PM +, Simon Arlott wrote:
>> +periph_clk: periph_clk {
>> +compatible = "brcm,bcm63168-gate-clk", "brcm,bcm63xx-gate-clk";
>> +regmap = <&periph_cntl>;
>
> What else is in periph_cntrl? Could this all just be part of that node?

 uint32RevID; /* (00) word 0 */
 uint32blkEnables;/* (04) word 1 */ <-- gated clocks
 uint32pll_control;   /* (08) word 2 */ <-- system reset 
controller bit
 uint32deviceTimeoutEn;   /* (0c) word 3 */ <-- unknown
 uint32softResetB;/* (10) word 4 */ <-- device reset 
controller bits
uint32diagControl;/* (14) word 5 */ <-- unknown
uint32ExtIrqCfg;  /* (18) word 6*/ <-- external interrupt 
controller
uint32unused1;/* (1c) word 7 */ <-- (external interrupt 
controller?)
 IrqControl_t IrqControl[3];/* (20) (40) (60) */ <-- normal 
interrupt controller

So it has these clocks, two types of reset controller, and the interrupt
controllers, but I've left the interrupt controllers registers out of the
syscon device.

For the registers in the "timer" peripheral at the end of the timer/watchdog
registers:
uint32EnSwPLL; <-- unknown
uint32ClkRstCtl;
#define POR_RESET_STATUS(1 << 31) <-- unknown
#define HW_RESET_STATUS (1 << 30) <-- unknown
#define SW_RESET_STATUS (1 << 29) <-- unknown
#define USB_REF_CLKEN   (1 << 18) <-- gated clock
#define UTO_EXTIN_CLKEN (1 << 17) <-- gated clock
#define UTO_CLK50_SEL   (1 << 16) <-- looks like a clock frequency 
selection bit
#define FAP2_PLL_CLKEN  (1 << 15) <-- gated clock
#define FAP2_PLL_FREQ_SHIFT 12<-- bits for controlling the 
frequency
#define FAP1_PLL_CLKEN  (1 << 11) <-- gated clock
#define FAP1_PLL_FREQ_SHIFT 8 <-- bits for controlling the 
frequency
#define WAKEON_DSL  (1 << 7)  <-- wake on network bit
#define WAKEON_EPHY (1 << 6)  <-- wake on network bit
#define DSL_ENERGY_DETECT_ENABLE(1 << 4)  <-- energy saving control for 
network
#define GPHY_1_ENERGY_DETECT_ENABLE (1 << 3)  <-- energy saving control for 
network
#define EPHY_3_ENERGY_DETECT_ENABLE (1 << 2)  <-- energy saving control for 
network
#define EPHY_2_ENERGY_DETECT_ENABLE (1 << 1)  <-- energy saving control for 
network
#define EPHY_1_ENERGY_DETECT_ENABLE (1 << 0)  <-- energy saving control for 
network

I need the usb_ref clock for USB, and I want to be able to disable
uto_extin, fap1 and fap2 as they're unused by anything in the device tree.

The full list of registers is here:
https://github.com/lp0/bcm963xx_4.12L.06B_consumer/blob/master/shared/opensource/include/bcm963xx/63268_map_part.h

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

Re: [PATCH] extcon: arizona: Update naming for micd-timeout DT to include units

[Pavel Machek]

On Mon 2015-11-23 14:51:30, Charles Keepax wrote:
> Add time units of -ms (milliseconds) to wlf,micd-timeout.
> 
> Signed-off-by: Charles Keepax 
> ---
>  .../devicetree/bindings/extcon/extcon-arizona.txt  |2 +-
>  drivers/extcon/extcon-arizona.c|2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> index da9813b..05d85ac 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> @@ -33,7 +33,7 @@ Optional properties:
>  specified as per the ARIZONA_MICD_TIME_XXX defines.
>- wlf,micd-dbtime : Microphone detection hardware debounces specified as 
> the
>  number of measurements to take, valid values being 2 and 4.
> -  - wlf,micd-timeout : Timeout for microphone detection, specified in
> +  - wlf,micd-timeout-ms : Timeout for microphone detection, specified in
>  milliseconds.
>- wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
>  detection.
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index c377030..8647533 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1230,7 +1230,7 @@ static int arizona_extcon_device_get_pdata(struct 
> arizona *arizona)
>   device_property_read_u32(arizona->dev, "wlf,micd-dbtime",
>&pdata->micd_dbtime);
>  
> - device_property_read_u32(arizona->dev, "wlf,micd-timeout",
> + device_property_read_u32(arizona->dev, "wlf,micd-timeout-ms",
>&pdata->micd_timeout);
>  
>   pdata->micd_force_micbias =
device_property_read_bool(arizona->dev,

While the change is nice, new kernel is supposed to work with old
DTS. So you'd need to check for both properties here..
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 13/12] ARM: dts: dove: add DT GPU support

[Andrew Lunn]

> This additional patch is in conjunction with my PMU (already merged)
> and clock driver patch sets.

Hi Russell

Please could you respond to my comment about the clock patch.

http://www.spinics.net/lists/devicetree/msg104464.html

Thanks
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 02/12] drm/etnaviv: add devicetree bindings

[Ilia Mirkin]

On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
 wrote:
> Moreover, DRI3 is not yet available for Gallium, so if we're talking
> about Xorg, then functional DRI2 is a requirement, and that _needs_
> to have a single device for the rendering instances.  Xorg has no way
> to pass multiple render nodes to client over DRI2.

Just to correct... DRI3 has been available on gallium [at least in the
context of st/mesa] basically since DRI3 was introduced. Not sure what
issue you're fighting with, but it's definitely not a gallium
limitation... could be something related to platform devices.

It is also possible to use DRI_PRIME= to select which
device to use. Not sure whether that has been available since the
beginning or not.

That said e.g. st/vdpau still doesn't deal with DRI3 which is a bit
annoying. And your other points all still stand (buffer sharing =
pain, tiling = not figured out, etc).

  -ilia
--
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 02/12] drm/etnaviv: add devicetree bindings

[Daniel Vetter]

On Fri, Dec 04, 2015 at 08:31:01PM +, Russell King - ARM Linux wrote:
> On Fri, Dec 04, 2015 at 02:19:42PM -0600, Rob Herring wrote:
> > On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach  wrote:
> > > Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> > >> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  
> > >> wrote:
> > >> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> > >> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > >> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
> > >> >> > master device node to bind all the individual GPU cores together
> > >> >> > into one DRM device.
> > >> >> >
> > >> >> > Signed-off-by: Lucas Stach 
> > >> >> > ---
> > >> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
> > >> >> > ++
> > >> >> >  1 file changed, 46 insertions(+)
> > >> >> >  create mode 100644 
> > >> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > >> >> >
> > >> >> > diff --git 
> > >> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
> > >> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > >> >> > new file mode 100644
> > >> >> > index ..19fde29dc1d7
> > >> >> > --- /dev/null
> > >> >> > +++ 
> > >> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > >> >> > @@ -0,0 +1,46 @@
> > >> >> > +Etnaviv DRM master device
> > >> >> > +
> > >> >> > +
> > >> >> > +The Etnaviv DRM master device is a virtual device needed to list 
> > >> >> > all
> > >> >> > +Vivante GPU cores that comprise the GPU subsystem.
> > >> >> > +
> > >> >> > +Required properties:
> > >> >> > +- compatible: Should be one of
> > >> >> > +"fsl,imx-gpu-subsystem"
> > >> >> > +"marvell,dove-gpu-subsystem"
> > >> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
> > >> >> > devices
> > >> >> > +
> > >> >> > +example:
> > >> >> > +
> > >> >> > +gpu-subsystem {
> > >> >> > +   compatible = "fsl,imx-gpu-subsystem";
> > >> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
> > >> >> > +};
> > >> >>
> > >> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
> > >> >> driver.
> > >> >>
> > >> > I'm aware of that, but I don't see much value in kicking this 
> > >> > discussion
> > >> > around for every DRM driver submission. This is the binding that has
> > >> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> > >> > allows us to standardize on _something_. Also ALSA does a similar thing
> > >> > to bind codecs and CPU interfaces together.
> > >>
> > >> This case is quite different though I think. The ALSA case and other
> > >> DRM cases are ones that have inter-dependencies between the blocks
> > >> (e.g. some sort of h/w connection). What is the inter-dependency here?
> > >>
> > >> Doing this way has also been found to be completely unnecessary and
> > >> removed in recent DRM driver reviews. Admittedly, those are cases
> > >> where one device can be the master of the others. For 2 parallel
> > >> devices, I don't have an alternative other than question why they need
> > >> to be a single driver.
> > >>
> > > If you insist on doing things differently for this driver, we could add
> > > a pass at driver registration that scans through the DT, looking for
> > > nodes matching the GPU core compatible.
> > 
> > I've not insisted on anything. I'm only asking a question which didn't
> > get answered. I'll ask another way. Why can't you have 2 instances of
> > the same driver given they are only rendering nodes?
> 
> Sorry, but it _did_ get answered - I answered that in my reply to you.
> I'll repeat it again, but more briefly, and then expand on it: it's what
> userspace like Xorg DRI2 and MESA want.
> 
> Yes, there's DRI3, which is more modern and in theory allows multiple
> renderers to be opened by the client, but so far I fail to see how that
> can work with a separate KMS DRM driver.  It _may_ be intended to, but
> the problem I see here is that when you have the KMS hardware only
> capable of scanning out linear buffers, but the GPU hardware is only
> capable of rendering to tiled buffers, there needs to be some way to
> allocate KMS buffers in the client, and right now I don't see any way
> to know what the KMS DRM device being used is in the DRI3/Present Xorg
> extensions.
> 
> Moreover, DRI3 is not yet available for Gallium, so if we're talking
> about Xorg, then functional DRI2 is a requirement, and that _needs_
> to have a single device for the rendering instances.  Xorg has no way
> to pass multiple render nodes to client over DRI2.

The only thing that DRI2 needs is that both client and X use the same
device. But you can just dma-buf share stuff in the client (e.g. we had
some code at intel to decode videos in libva with some code chip, then
dma-buf share to i915.ko for post-proc, then dri2 flink to the X server).
Same on the X server, you

Re: [PATCH 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 02:19:42PM -0600, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach  wrote:
> > Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> >> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  
> >> wrote:
> >> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> >> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> >> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
> >> >> > master device node to bind all the individual GPU cores together
> >> >> > into one DRM device.
> >> >> >
> >> >> > Signed-off-by: Lucas Stach 
> >> >> > ---
> >> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
> >> >> > ++
> >> >> >  1 file changed, 46 insertions(+)
> >> >> >  create mode 100644 
> >> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> >> >
> >> >> > diff --git 
> >> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
> >> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> >> > new file mode 100644
> >> >> > index ..19fde29dc1d7
> >> >> > --- /dev/null
> >> >> > +++ 
> >> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> >> > @@ -0,0 +1,46 @@
> >> >> > +Etnaviv DRM master device
> >> >> > +
> >> >> > +
> >> >> > +The Etnaviv DRM master device is a virtual device needed to list all
> >> >> > +Vivante GPU cores that comprise the GPU subsystem.
> >> >> > +
> >> >> > +Required properties:
> >> >> > +- compatible: Should be one of
> >> >> > +"fsl,imx-gpu-subsystem"
> >> >> > +"marvell,dove-gpu-subsystem"
> >> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
> >> >> > devices
> >> >> > +
> >> >> > +example:
> >> >> > +
> >> >> > +gpu-subsystem {
> >> >> > +   compatible = "fsl,imx-gpu-subsystem";
> >> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
> >> >> > +};
> >> >>
> >> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
> >> >> driver.
> >> >>
> >> > I'm aware of that, but I don't see much value in kicking this discussion
> >> > around for every DRM driver submission. This is the binding that has
> >> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> >> > allows us to standardize on _something_. Also ALSA does a similar thing
> >> > to bind codecs and CPU interfaces together.
> >>
> >> This case is quite different though I think. The ALSA case and other
> >> DRM cases are ones that have inter-dependencies between the blocks
> >> (e.g. some sort of h/w connection). What is the inter-dependency here?
> >>
> >> Doing this way has also been found to be completely unnecessary and
> >> removed in recent DRM driver reviews. Admittedly, those are cases
> >> where one device can be the master of the others. For 2 parallel
> >> devices, I don't have an alternative other than question why they need
> >> to be a single driver.
> >>
> > If you insist on doing things differently for this driver, we could add
> > a pass at driver registration that scans through the DT, looking for
> > nodes matching the GPU core compatible.
> 
> I've not insisted on anything. I'm only asking a question which didn't
> get answered. I'll ask another way. Why can't you have 2 instances of
> the same driver given they are only rendering nodes?

Sorry, but it _did_ get answered - I answered that in my reply to you.
I'll repeat it again, but more briefly, and then expand on it: it's what
userspace like Xorg DRI2 and MESA want.

Yes, there's DRI3, which is more modern and in theory allows multiple
renderers to be opened by the client, but so far I fail to see how that
can work with a separate KMS DRM driver.  It _may_ be intended to, but
the problem I see here is that when you have the KMS hardware only
capable of scanning out linear buffers, but the GPU hardware is only
capable of rendering to tiled buffers, there needs to be some way to
allocate KMS buffers in the client, and right now I don't see any way
to know what the KMS DRM device being used is in the DRI3/Present Xorg
extensions.

Moreover, DRI3 is not yet available for Gallium, so if we're talking
about Xorg, then functional DRI2 is a requirement, and that _needs_
to have a single device for the rendering instances.  Xorg has no way
to pass multiple render nodes to client over DRI2.

-- 
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

[PATCH v5 1/5] dt-bindings: add SMP enable-method for Broadcom NSP

[Kapil Hali]

Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's
Northstar Plus CPU to the 32-bit ARM CPU device tree binding
documentation file and create a new binding documentation for
Northstar Plus CPU.

Signed-off-by: Kapil Hali 
---
 .../bindings/arm/bcm/brcm,nsp-cpu-method.txt   | 39 ++
 Documentation/devicetree/bindings/arm/cpus.txt |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
new file mode 100644
index 000..bf08872
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
@@ -0,0 +1,39 @@
+Broadcom Northstar Plus SoC CPU Enable Method
+-
+This binding defines the enable method used for starting secondary
+CPUs in the following Broadcom SoCs:
+  BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
+
+The enable method is specified by defining the following required
+properties in the "cpus" device tree node:
+  - enable-method = "brcm,bcm-nsp-smp";
+  - secondary-boot-reg = <...>;
+
+The secondary-boot-reg property is a u32 value that specifies the
+physical address of the register which should hold the common
+entry point for a secondary CPU. This entry is cpu node specific
+and should be added per cpu. E.g., in case of NSP (BCM58625) which
+is a dual core CPU SoC, this entry should be added to cpu1 node.
+
+
+Example:
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "brcm,bcm-nsp-smp";
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <&L2>;
+   reg = <0>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <&L2>;
+   reg = <1>;
+   secondary-boot-reg = <0x042c>;
+   };
+   };
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 3a07a87..d191554 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -190,6 +190,7 @@ nodes to be present and contain the properties described 
below.
"allwinner,sun6i-a31"
"allwinner,sun8i-a23"
"arm,psci"
+   "brcm,bcm-nsp-smp"
"brcm,brahma-b15"
"marvell,armada-375-smp"
"marvell,armada-380-smp"
-- 
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

[PATCH v5 2/5] ARM: BCM: Clean up SMP support for Broadcom Kona

[Kapil Hali]

These changes cleans up SMP implementaion for Broadcom's
Kona SoC which are required for handling SMP for iProc
family of SoCs at a single place for BCM NSP and BCM Kona.

Signed-off-by: Kapil Hali 
---
 arch/arm/boot/dts/bcm11351.dtsi |  2 +-
 arch/arm/boot/dts/bcm21664.dtsi |  2 +-
 arch/arm/mach-bcm/kona_smp.c| 82 +++--
 3 files changed, 56 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 2ddaa51..3dc7a8c 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -31,7 +31,6 @@
#address-cells = <1>;
#size-cells = <0>;
enable-method = "brcm,bcm11351-cpu-method";
-   secondary-boot-reg = <0x3500417c>;
 
cpu0: cpu@0 {
device_type = "cpu";
@@ -42,6 +41,7 @@
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
+   secondary-boot-reg = <0x3500417c>;
reg = <1>;
};
};
diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
index 2016b72..3f525be 100644
--- a/arch/arm/boot/dts/bcm21664.dtsi
+++ b/arch/arm/boot/dts/bcm21664.dtsi
@@ -31,7 +31,6 @@
#address-cells = <1>;
#size-cells = <0>;
enable-method = "brcm,bcm11351-cpu-method";
-   secondary-boot-reg = <0x35004178>;
 
cpu0: cpu@0 {
device_type = "cpu";
@@ -42,6 +41,7 @@
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
+   secondary-boot-reg = <0x35004178>;
reg = <1>;
};
};
diff --git a/arch/arm/mach-bcm/kona_smp.c b/arch/arm/mach-bcm/kona_smp.c
index 66a0465..15af781 100644
--- a/arch/arm/mach-bcm/kona_smp.c
+++ b/arch/arm/mach-bcm/kona_smp.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2014 Broadcom Corporation
+ * Copyright (C) 2014-2015 Broadcom Corporation
  * Copyright 2014 Linaro Limited
  *
  * This program is free software; you can redistribute it and/or
@@ -30,9 +30,10 @@
 
 /* Name of device node property defining secondary boot register location */
 #define OF_SECONDARY_BOOT  "secondary-boot-reg"
+#define MPIDR_CPUID_BITMASK0x3
 
 /* I/O address of register used to coordinate secondary core startup */
-static u32 secondary_boot;
+static u32 secondary_boot_addr;
 
 /*
  * Enable the Cortex A9 Snoop Control Unit
@@ -78,44 +79,68 @@ static int __init scu_a9_enable(void)
 static void __init bcm_smp_prepare_cpus(unsigned int max_cpus)
 {
static cpumask_t only_cpu_0 = { CPU_BITS_CPU0 };
-   struct device_node *node;
+   struct device_node *cpus_node = NULL;
+   struct device_node *cpu_node = NULL;
int ret;
 
-   BUG_ON(secondary_boot); /* We're called only once */
-
/*
 * This function is only called via smp_ops->smp_prepare_cpu().
 * That only happens if a "/cpus" device tree node exists
 * and has an "enable-method" property that selects the SMP
 * operations defined herein.
 */
-   node = of_find_node_by_path("/cpus");
-   BUG_ON(!node);
-
-   /*
-* Our secondary enable method requires a "secondary-boot-reg"
-* property to specify a register address used to request the
-* ROM code boot a secondary code.  If we have any trouble
-* getting this we fall back to uniprocessor mode.
-*/
-   if (of_property_read_u32(node, OF_SECONDARY_BOOT, &secondary_boot)) {
-   pr_err("%s: missing/invalid " OF_SECONDARY_BOOT " property\n",
-   node->name);
-   ret = -ENOENT;  /* Arrange to disable SMP */
-   goto out;
+   cpus_node = of_find_node_by_path("/cpus");
+   if (!cpus_node)
+   return;
+
+   for_each_child_of_node(cpus_node, cpu_node) {
+   u32 cpuid;
+
+   if (of_node_cmp(cpu_node->type, "cpu"))
+   continue;
+
+   if (of_property_read_u32(cpu_node, "reg", &cpuid)) {
+   pr_debug("%s: missing reg property\n",
+cpu_node->full_name);
+   ret = -ENOENT;
+   goto out;
+   }
+
+   /*
+* "secondary-boot-reg" property should be defined only
+* for secondary cpu
+*/
+   if ((cpuid & MPIDR_CPUID_BITMASK) == 1) {
+   /*
+* Our secondary enable method requires a
+* "secondary-boot-reg" property to specify a register
+* address used to request the ROM code boot a secondary
+ 

[PATCH v5 3/5] ARM: dts: Add SMP support for Broadcom NSP

[Kapil Hali]

Add device tree changes required for providing SMP support
for Broadcom Northstar Plus SoC.

Signed-off-by: Kapil Hali 
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 58aca27..d9f8b31 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -40,24 +40,33 @@
model = "Broadcom Northstar Plus SoC";
interrupt-parent = <&gic>;
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <&L2>;
+   reg = <0x0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <&L2>;
+   enable-method = "brcm,bcm-nsp-smp";
+   secondary-boot-reg = <0x042c>;
+   reg = <0x1>;
+   };
+   };
+
mpcore {
compatible = "simple-bus";
ranges = <0x 0x1902 0x3000>;
#address-cells = <1>;
#size-cells = <1>;
 
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu@0 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a9";
-   next-level-cache = <&L2>;
-   reg = <0x0>;
-   };
-   };
-
L2: l2-cache {
compatible = "arm,pl310-cache";
reg = <0x2000 0x1000>;
-- 
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

[PATCH v5 5/5] ARM: BCM: Add SMP support for Broadcom 4708

[Kapil Hali]

From: Jon Mason 

Add SMP support for Broadcom's 4708 SoCs.

Signed-off-by: Jon Mason 
Acked-by: Hauke Mehrtens 
Tested-by: Hauke Mehrtens 
Signed-off-by: Kapil Hali 
---
 arch/arm/boot/dts/bcm4708.dtsi | 2 ++
 arch/arm/mach-bcm/Kconfig  | 1 +
 arch/arm/mach-bcm/Makefile | 3 +++
 3 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
index 31141e8..a8b51fa 100644
--- a/arch/arm/boot/dts/bcm4708.dtsi
+++ b/arch/arm/boot/dts/bcm4708.dtsi
@@ -27,6 +27,8 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
next-level-cache = <&L2>;
+   enable-method = "brcm,bcm-nsp-smp";
+   secondary-boot-reg = <0x0400>;
reg = <0x1>;
};
};
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 83765a0..e85246f 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -54,6 +54,7 @@ config ARCH_BCM_NSP
 config ARCH_BCM_5301X
bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
select ARCH_BCM_IPROC
+   select HAVE_SMP
help
  Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
 
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 5193a25..7d66515 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -43,6 +43,9 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
 
 # BCM5301X
 obj-$(CONFIG_ARCH_BCM_5301X)   += bcm_5301x.o
+ifeq ($(CONFIG_ARCH_BCM_5301X),y)
+obj-$(CONFIG_SMP)  += platsmp.o
+endif
 
 # BCM63XXx
 ifeq ($(CONFIG_ARCH_BCM_63XX),y)
-- 
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

[PATCH v5 4/5] ARM: BCM: Add SMP support for Broadcom NSP

[Kapil Hali]

Add SMP support for Broadcom's Northstar Plus SoC
cpu enable method. This changes also consolidates
iProc family's - BCM NSP and BCM Kona, platform
SMP handling in a common file.

Northstar Plus SoC is based on ARM Cortex-A9
revision r3p0 which requires configuration for ARM
Errata 764369 for SMP. This change adds the needed
configuration option.

Signed-off-by: Kapil Hali 
---
 arch/arm/mach-bcm/Kconfig   |  2 +
 arch/arm/mach-bcm/Makefile  |  8 +++-
 arch/arm/mach-bcm/{kona_smp.c => platsmp.c} | 64 -
 3 files changed, 71 insertions(+), 3 deletions(-)
 rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (81%)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8c53c55..83765a0 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -40,6 +40,8 @@ config ARCH_BCM_NSP
select ARCH_BCM_IPROC
select ARM_ERRATA_754322
select ARM_ERRATA_775420
+   select ARM_ERRATA_764369 if SMP
+   select HAVE_SMP
help
  Support for Broadcom Northstar Plus SoC.
  Broadcom Northstar Plus family of SoCs are used for switching control
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..5193a25 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -14,7 +14,11 @@
 obj-$(CONFIG_ARCH_BCM_CYGNUS) +=  bcm_cygnus.o
 
 # Northstar Plus
-obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
+obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
+
+ifeq ($(CONFIG_ARCH_BCM_NSP),y)
+obj-$(CONFIG_SMP)  += platsmp.o
+endif
 
 # BCM281XX
 obj-$(CONFIG_ARCH_BCM_281XX)   += board_bcm281xx.o
@@ -23,7 +27,7 @@ obj-$(CONFIG_ARCH_BCM_281XX)  += board_bcm281xx.o
 obj-$(CONFIG_ARCH_BCM_21664)   += board_bcm21664.o
 
 # BCM281XX and BCM21664 SMP support
-obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += kona_smp.o
+obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += platsmp.o
 
 # BCM281XX and BCM21664 L2 cache control
 obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o
diff --git a/arch/arm/mach-bcm/kona_smp.c b/arch/arm/mach-bcm/platsmp.c
similarity index 81%
rename from arch/arm/mach-bcm/kona_smp.c
rename to arch/arm/mach-bcm/platsmp.c
index 15af781..ea4201e 100644
--- a/arch/arm/mach-bcm/kona_smp.c
+++ b/arch/arm/mach-bcm/platsmp.c
@@ -12,12 +12,17 @@
  * GNU General Public License for more details.
  */
 
-#include 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
+#include 
 #include 
 #include 
 #include 
@@ -76,6 +81,36 @@ static int __init scu_a9_enable(void)
return 0;
 }
 
+static int nsp_write_lut(void)
+{
+   void __iomem *sku_rom_lut;
+   phys_addr_t secondary_startup_phy;
+
+   if (!secondary_boot_addr) {
+   pr_warn("required secondary boot register not specified\n");
+   return -EINVAL;
+   }
+
+   sku_rom_lut = ioremap_nocache((phys_addr_t)secondary_boot_addr,
+   sizeof(secondary_boot_addr));
+   if (!sku_rom_lut) {
+   pr_warn("unable to ioremap SKU-ROM LUT register\n");
+   return -ENOMEM;
+   }
+
+   secondary_startup_phy = virt_to_phys(secondary_startup);
+   BUG_ON(secondary_startup_phy > (phys_addr_t)U32_MAX);
+
+   writel_relaxed(secondary_startup_phy, sku_rom_lut);
+
+   /* Ensure the write is visible to the secondary core */
+   smp_wmb();
+
+   iounmap(sku_rom_lut);
+
+   return 0;
+}
+
 static void __init bcm_smp_prepare_cpus(unsigned int max_cpus)
 {
static cpumask_t only_cpu_0 = { CPU_BITS_CPU0 };
@@ -220,9 +255,36 @@ static int kona_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
return -ENXIO;
 }
 
+static int nsp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+   int ret;
+
+   /*
+* After wake up, secondary core branches to the startup
+* address programmed at SKU ROM LUT location.
+*/
+   ret = nsp_write_lut();
+   if (ret) {
+   pr_err("unable to write startup addr to SKU ROM LUT\n");
+   goto out;
+   }
+
+   /* Send a CPU wakeup interrupt to the secondary core */
+   arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+out:
+   return ret;
+}
+
 static struct smp_operations bcm_smp_ops __initdata = {
.smp_prepare_cpus   = bcm_smp_prepare_cpus,
.smp_boot_secondary = kona_boot_secondary,
 };
 CPU_METHOD_OF_DECLARE(bcm_smp_bcm281xx, "brcm,bcm11351-cpu-method",
&bcm_smp_ops);
+
+struct smp_operations nsp_smp_ops __initdata = {
+   .smp_prepare_cpus   = bcm_smp_prepare_cpus,
+   .smp_boot_secondary = nsp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(bcm_smp_nsp, "brcm,bcm-nsp-smp", &nsp_smp_ops);
-- 
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.k

[PATCH v5 0/5] SMP support for Broadcom NSP

[Kapil Hali]

Changes in v5:
* Made 'enable-method' for SMP per 'cpu' core instead of 'cpus'
node, in the DT files for BCM NSP and BCM4708.

Change in v4:
* Cleaned up kona_smp.c and associated DT file.
* Corrected documentation for DT bindings.
* Corrected secondary-boot-reg entry for bcm4708 DT file.

Change in v3:
* Fixed patch subject from RESEND PATCH to PATCH
* Deleted arch/arm/mach-bcm/bcm_nsp.h file
* Removed inclusion of header file bcm_nsp.h in platsmp.c
* Removed unused variable 'timeout' in nsp_boot_secondary()

Changes in v2:
Removed the pen_holding method of SMP bringup for NSP SoC and
replaced it with simple wakeup of secondary core using ARM IPI.


This series adds SMP support for Broadcom's Northstar Plus SoC.

There are similar SMP enablement methods for many ARMv7 bsed SoCs.
BCM NSP SoC, has a typical such mechanism - after power-on, the
secondary core is held in a standby state, primary core provides a
startup address for the secondary core and wakes it up. Booting of
the secondary core is serialized using pen_release global variable.

The startup address is programmed at a special register location
which is defined in the device tree using a "secondary-boot-reg"
property in a node whose "enable-method" property matches.

The first patch adds cpu-enable-method in the device tree bindings
documentation. It also updates ARM CPU device tree documentation
with Broadcom Northstar Plus CPU details.

The second patch adds SMP support to the BCM NSP device tree file.

The third patch, enables SMP on BCM NSP. It also consolidates
common SMP handling between BCM NSP and BCM Kona.

The final patch, enables SMP on BCM 4708 and this patch is pulled
in from Jon Mason's patch from the mailing list.

This patch series is constructed based on Linux v4.4-rc1.

The source code is available at GITHUB:
https://github.com/Broadcom/cygnus-linux/tree/nsp-smp-v2


Jon Mason (1):
  ARM: BCM: Add SMP support for Broadcom 4708

Kapil Hali (4):
  dt-bindings: add SMP enable-method for Broadcom NSP
  ARM: BCM: Clean up SMP support for Broadcom Kona
  ARM: dts: Add SMP support for Broadcom NSP
  ARM: BCM: Add SMP support for Broadcom NSP

 .../bindings/arm/bcm/brcm,nsp-cpu-method.txt   |  39 ++
 Documentation/devicetree/bindings/arm/cpus.txt |   1 +
 arch/arm/boot/dts/bcm-nsp.dtsi |  33 +++--
 arch/arm/boot/dts/bcm11351.dtsi|   2 +-
 arch/arm/boot/dts/bcm21664.dtsi|   2 +-
 arch/arm/boot/dts/bcm4708.dtsi |   2 +
 arch/arm/mach-bcm/Kconfig  |   3 +
 arch/arm/mach-bcm/Makefile |  11 +-
 arch/arm/mach-bcm/{kona_smp.c => platsmp.c}| 144 +
 9 files changed, 193 insertions(+), 44 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
 rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)

-- 
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 02/12] drm/etnaviv: add devicetree bindings

[Rob Herring]

On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach  wrote:
> Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
>> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  wrote:
>> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
>> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
>> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
>> >> > master device node to bind all the individual GPU cores together
>> >> > into one DRM device.
>> >> >
>> >> > Signed-off-by: Lucas Stach 
>> >> > ---
>> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
>> >> > ++
>> >> >  1 file changed, 46 insertions(+)
>> >> >  create mode 100644 
>> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> >
>> >> > diff --git 
>> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
>> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > new file mode 100644
>> >> > index ..19fde29dc1d7
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > @@ -0,0 +1,46 @@
>> >> > +Etnaviv DRM master device
>> >> > +
>> >> > +
>> >> > +The Etnaviv DRM master device is a virtual device needed to list all
>> >> > +Vivante GPU cores that comprise the GPU subsystem.
>> >> > +
>> >> > +Required properties:
>> >> > +- compatible: Should be one of
>> >> > +"fsl,imx-gpu-subsystem"
>> >> > +"marvell,dove-gpu-subsystem"
>> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
>> >> > devices
>> >> > +
>> >> > +example:
>> >> > +
>> >> > +gpu-subsystem {
>> >> > +   compatible = "fsl,imx-gpu-subsystem";
>> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
>> >> > +};
>> >>
>> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
>> >> driver.
>> >>
>> > I'm aware of that, but I don't see much value in kicking this discussion
>> > around for every DRM driver submission. This is the binding that has
>> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
>> > allows us to standardize on _something_. Also ALSA does a similar thing
>> > to bind codecs and CPU interfaces together.
>>
>> This case is quite different though I think. The ALSA case and other
>> DRM cases are ones that have inter-dependencies between the blocks
>> (e.g. some sort of h/w connection). What is the inter-dependency here?
>>
>> Doing this way has also been found to be completely unnecessary and
>> removed in recent DRM driver reviews. Admittedly, those are cases
>> where one device can be the master of the others. For 2 parallel
>> devices, I don't have an alternative other than question why they need
>> to be a single driver.
>>
> If you insist on doing things differently for this driver, we could add
> a pass at driver registration that scans through the DT, looking for
> nodes matching the GPU core compatible.

I've not insisted on anything. I'm only asking a question which didn't
get answered. I'll ask another way. Why can't you have 2 instances of
the same driver given they are only rendering nodes?

> I'm not sure if that makes things cleaner though and might bite us later
> on. Also I'm not sure if moving away from the binding scheme already
> established for other DRM drivers makes things better from a DT
> perspective. Personally I would prefer DT binding consistency over
> perfection for single drivers, segmenting the DT binding space.

This is the least of our issues in terms of consistency among drivers,
but that is in fact what I'm pushing for. This is probably the first
case of a render only driver (at least for DT). So this isn't a case
of just follow what others are doing.

The h/w in this area can be quite different, so the DT bindings are
going to reflect that to some extent. A virtual node makes sense in
some cases, but for others it may not.

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 V7 net-next 0/5] net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem

[Salil Mehta]

Thanks a ton! David :)

On 12/4/2015 7:37 PM, David Miller wrote:

From: Salil Mehta 
Date: Thu, 3 Dec 2015 12:17:52 +


This PATCH V7 addresses the TAB formatting comments by
Sergei Shtylyov. Missing TABs at some other palces have
also been corrected.

Series applied, thanks.



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

[PATCH v2 13/12] ARM: dts: dove: add DT GPU support

[Russell King]

Add DT support for the Vivante GC600 GPU on Marvell Dove platforms.
These nodes default to being disabled unless a platform decides they
should be enabled.

Signed-off-by: Russell King 
---
This replaces the previous patch I sent out in error; this version
adds all the DT nodes required.  Also included along with this is a
patch which enables the GPU for Cubox platforms.

This additional patch is in conjunction with my PMU (already merged)
and clock driver patch sets.

 arch/arm/boot/dts/dove.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index ea36a262d056..f36e3b9c6730 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -33,6 +33,12 @@
marvell,tauros2-cache-features = <0>;
};
 
+   gpu-subsystem {
+   compatible = "marvell,dove-gpu-subsystem";
+   cores = <&gpu>;
+   status = "disabled";
+   };
+
i2c-mux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
@@ -773,6 +779,16 @@
interrupts = <47>;
status = "disabled";
};
+
+   gpu: gpu@84 {
+   clocks = <÷r_clk 1>;
+   clock-names = "core";
+   compatible = "vivante,gc";
+   interrupts = <48>;
+   power-domains = <&gpu_domain>;
+   reg = <0x84 0x4000>;
+   status = "disabled";
+   };
};
};
 };
-- 
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

[PATCH v2 14/12] ARM: dts: enable GPU for SolidRun's Cubox

[Russell King]

Enable the GPU for SolidRun's Cubox.

Signed-off-by: Russell King 
---
 arch/arm/boot/dts/dove-cubox.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index e6fa251e17b9..af3cb633135f 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -62,6 +62,10 @@
pinctrl-0 = <&pmx_gpio_19>;
pinctrl-names = "default";
};
+
+   gpu-subsystem {
+   status = "okay";
+   };
 };
 
 &uart0 { status = "okay"; };
@@ -74,6 +78,10 @@
reg = <1>;
 };
 
+&gpu {
+   status = "okay";
+};
+
 &i2c0 {
status = "okay";
clock-frequency = <10>;
-- 
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 V7 net-next 0/5] net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem

[David Miller]

From: Salil Mehta 
Date: Thu, 3 Dec 2015 12:17:52 +

> This PATCH V7 addresses the TAB formatting comments by 
> Sergei Shtylyov. Missing TABs at some other palces have
> also been corrected.

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

[PATCH 13/12] ARM: dts: dove: add DT GPU support

[Russell King]

Add DT support for the Vivante GC600 GPU on Marvell Dove platforms.

Signed-off-by: Russell King 
---
This additional patch is in conjunction with my PMU (already merged)
and clock driver patch sets.

 arch/arm/boot/dts/dove.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index ea36a262d056..b1d0eb647ed5 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -773,6 +773,16 @@
interrupts = <47>;
status = "disabled";
};
+
+   gpu: gpu@84 {
+   clocks = <÷r_clk 1>;
+   clock-names = "core";
+   compatible = "vivante,gc";
+   interrupts = <48>;
+   power-domains = <&gpu_domain>;
+   reg = <0x84 0x4000>;
+   status = "disabled";
+   };
};
};
 };
-- 
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] Add support for monitoring gpio switches

[Greg Kroah-Hartman]

On Fri, Dec 04, 2015 at 05:31:14PM +, Martyn Welch wrote:
> Select Chromebooks have gpio attached to switches used to cause the
> firmware to enter alternative modes of operation and/or control other
> device characteristics (such as write protection on flash devices). This
> patch adds a driver that exposes a read-only interface to allow these
> signals to be read from user space.
> 
> This functionality has been generalised to provide support for any device
> with device tree support which needs to identify a gpio as being used for a
> specific task.
> 
> Signed-off-by: Martyn Welch 
> ---
>  drivers/misc/Kconfig   |  11 
>  drivers/misc/Makefile  |   1 +
>  drivers/misc/gpio-switch.c | 160 
> +

Why isn't this in drivers/gpio/ ?

why make it a misc driver?

thanks,

greg k-h
--
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] spi: sh-msiof: Add support for SH-Mobile AG5

[Rob Herring]

On Mon, Nov 30, 2015 at 03:14:00PM +0100, Geert Uytterhoeven wrote:
> MSIOF in SH-Mobile AG5 (sh73a0) is handled fine by the existing driver.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied, thanks.

Rob


Applied, thanks.

Rob

> ---
>  Documentation/devicetree/bindings/spi/sh-msiof.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt 
> b/Documentation/devicetree/bindings/spi/sh-msiof.txt
> index 705075da2f10156e..aa005c1d10d95756 100644
> --- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
> +++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
> @@ -10,6 +10,7 @@ Required properties:
>"renesas,msiof-r8a7792" (R-Car V2H)
>"renesas,msiof-r8a7793" (R-Car M2-N)
>"renesas,msiof-r8a7794" (R-Car E2)
> +  "renesas,msiof-sh73a0" (SH-Mobile AG5)
>  - reg  : A list of offsets and lengths of the register sets 
> for
>the device.
>If only one register set is present, it is to be used
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dt-bindings: tda998x: Document the required 'port' node.

[Rob Herring]

On Wed, Dec 02, 2015 at 11:35:39AM +, Liviu Dudau wrote:
> All the users of the tda998x driver are component based and bind the
> driver via the device graph method described in
> Documentation/devicetree/bindings/graph.txt. Add the fact that the
> 'port' node is required to the bindings.
> 
> Signed-off-by: Liviu Dudau 

Applied, thanks.

Rob

> ---
>  Documentation/devicetree/bindings/display/bridge/tda998x.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt 
> b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
> index e9e4bce..e178e6b 100644
> --- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
> @@ -5,6 +5,10 @@ Required properties;
>  
>- reg: I2C address
>  
> +Required node:
> +  - port: Input port node with endpoint definition, as described
> +in Documentation/devicetree/bindings/graph.txt
> +
>  Optional properties:
>- interrupts: interrupt number and trigger type
>   default: polling
> -- 
> 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] net/macb: bindings doc: Merge cdns-emac to macb

[Rob Herring]

On Mon, Nov 30, 2015 at 02:51:46PM +0100, Michal Simek wrote:
> Merge two bindings for the same driver to together.
> 
> Signed-off-by: Michal Simek 

Applied, thanks.

Rob


Applied, thanks.

Rob

> ---
> 
>  Documentation/devicetree/bindings/net/cdns-emac.txt | 20 
>  Documentation/devicetree/bindings/net/macb.txt  |  3 +++
>  2 files changed, 3 insertions(+), 20 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/net/cdns-emac.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/cdns-emac.txt 
> b/Documentation/devicetree/bindings/net/cdns-emac.txt
> deleted file mode 100644
> index 4451ee973223..
> --- a/Documentation/devicetree/bindings/net/cdns-emac.txt
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -* Cadence EMAC Ethernet controller
> -
> -Required properties:
> -- compatible: Should be "cdns,[-]{emac}"
> -  Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
> -  Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC.
> -  Or the generic form: "cdns,emac".
> -- reg: Address and length of the register set for the device
> -- interrupts: Should contain macb interrupt
> -- phy-mode: see ethernet.txt file in the same directory.
> -
> -Examples:
> -
> - macb0: ethernet@fffc4000 {
> - compatible = "cdns,at91rm9200-emac";
> - reg = <0xfffc4000 0x4000>;
> - interrupts = <21>;
> - phy-mode = "rmii";
> - local-mac-address = [3a 0e 03 04 05 06];
> - };
> diff --git a/Documentation/devicetree/bindings/net/macb.txt 
> b/Documentation/devicetree/bindings/net/macb.txt
> index b5d79761ac97..1361a6daf63f 100644
> --- a/Documentation/devicetree/bindings/net/macb.txt
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -2,6 +2,7 @@
>  
>  Required properties:
>  - compatible: Should be "cdns,[-]{macb|gem}"
> +  Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
>Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
>available on sama5d3 SoCs.
>Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: 
> "cdns,macb".
> @@ -10,7 +11,9 @@ Required properties:
>Use "atmel,sama5d2-gem" for the GEM IP (10/100) available on Atmel sama5d2 
> SoCs.
>Use "atmel,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs.
>Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 
> SoCs.
> +  Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC.
>Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC.
> +  Or the generic form: "cdns,emac".
>  - reg: Address and length of the register set for the device
>  - interrupts: Should contain macb interrupt
>  - phy-mode: See ethernet.txt file in the same directory.
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] dt-bindings: Misc fix for the ATH79 DDR controllers

[Rob Herring]

On Sun, Nov 29, 2015 at 01:40:12PM +0100, Alban Bedel wrote:
> Fix a few typos and reword the description of the
> '#qca,ddr-wb-channel-cells' property.
> 
> Signed-off-by: Alban Bedel 
> CC: triv...@kernel.org

Applied, thanks.

Rob

> ---
> Changlog:
> v2: * Fixed the truncated log message because of a
>   line starting with a #.
> ---
>  .../bindings/memory-controllers/ath79-ddr-controller.txt  | 8 
> 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt
>  
> b/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt
> index efe35a06..c81af75 100644
> --- 
> a/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt
> @@ -1,6 +1,6 @@
>  Binding for Qualcomm  Atheros AR7xxx/AR9xxx DDR controller
>  
> -The DDR controller of the ARxxx and AR9xxx families provides an interface
> +The DDR controller of the AR7xxx and AR9xxx families provides an interface
>  to flush the FIFO between various devices and the DDR. This is mainly used
>  by the IRQ controller to flush the FIFO before running the interrupt handler
>  of such devices.
> @@ -11,9 +11,9 @@ Required properties:
>"qca,[ar7100|ar7240]-ddr-controller" as fallback.
>On SoC with PCI support "qca,ar7100-ddr-controller" should be used as
>fallback, otherwise "qca,ar7240-ddr-controller" should be used.
> -- reg: Base address and size of the controllers memory area
> -- #qca,ddr-wb-channel-cells: has to be 1, the index of the write buffer
> -  channel
> +- reg: Base address and size of the controller's memory area
> +- #qca,ddr-wb-channel-cells: Specifies the number of cells needed to encode
> +  the write buffer channel index, should be 1.
>  
>  Example:
>  
> -- 
> 2.0.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 v7 3/6] watchdog: ts4800: add driver for TS-4800 watchdog

[Damien Riegel]

Hi Wim,

This patch is part of a serie and Lee Jones was willing to handle the
serie (at least the first three patches) but he needs your Ack on the
watchdog as you are the maintainer of this subsystem. This patch has
already been reviewed by Guenter. Could you please review this patch ? 

Thanks,
Damien

On Mon, Nov 30, 2015 at 08:14:48AM -0800, Guenter Roeck wrote:
> On 11/30/2015 07:59 AM, Damien Riegel wrote:
> >This watchdog is instantiated in a FPGA that is memory mapped. It is
> >made of only one register, called the feed register. Writing to this
> >register will re-arm the watchdog for a given time (and enable it if it
> >was disable). It can be disabled by writing a special value into it.
> >
> >It is part of a syscon block, and the watchdog register offset in this
> >block varies from board to board. This offset is passed in the syscon
> >property after the phandle to the syscon node.
> >
> >Signed-off-by: Damien Riegel 
> 
> Reviewed-by: Guenter Roeck 
> 
> >---
> >  .../devicetree/bindings/watchdog/ts4800-wdt.txt|  25 +++
> >  drivers/watchdog/Kconfig   |  10 +
> >  drivers/watchdog/Makefile  |   1 +
> >  drivers/watchdog/ts4800_wdt.c  | 215 
> > +
> >  4 files changed, 251 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> >  create mode 100644 drivers/watchdog/ts4800_wdt.c
> >
> >diff --git a/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt 
> >b/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> >new file mode 100644
> >index 000..8f6caad
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> >@@ -0,0 +1,25 @@
> >+Technologic Systems Watchdog
> >+
> >+Required properties:
> >+- compatible: must be "technologic,ts4800-wdt"
> >+- syscon: phandle / integer array that points to the syscon node which
> >+  describes the FPGA's syscon registers.
> >+  - phandle to FPGA's syscon
> >+  - offset to the watchdog register
> >+
> >+Optional property:
> >+- timeout-sec: contains the watchdog timeout in seconds.
> >+
> >+Example:
> >+
> >+syscon: syscon@b001 {
> >+compatible = "syscon", "simple-mfd";
> >+reg = <0xb001 0x3d>;
> >+reg-io-width = <2>;
> >+
> >+wdt@e {
> >+compatible = "technologic,ts4800-wdt";
> >+syscon = <&syscon 0xe>;
> >+timeout-sec = <10>;
> >+};
> >+}
> >diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> >index 79e1aa1..bb624d2 100644
> >--- a/drivers/watchdog/Kconfig
> >+++ b/drivers/watchdog/Kconfig
> >@@ -426,6 +426,16 @@ config NUC900_WATCHDOG
> >   To compile this driver as a module, choose M here: the
> >   module will be called nuc900_wdt.
> >
> >+config TS4800_WATCHDOG
> >+tristate "TS-4800 Watchdog"
> >+depends on HAS_IOMEM && OF
> >+select WATCHDOG_CORE
> >+select MFD_SYSCON
> >+help
> >+  Technologic Systems TS-4800 has watchdog timer implemented in
> >+  an external FPGA. Say Y here if you want to support for the
> >+  watchdog timer on TS-4800 board.
> >+
> >  config TS72XX_WATCHDOG
> > tristate "TS-72XX SBC Watchdog"
> > depends on MACH_TS72XX
> >diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> >index 0c616e3..3863ce0 100644
> >--- a/drivers/watchdog/Makefile
> >+++ b/drivers/watchdog/Makefile
> >@@ -53,6 +53,7 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
> >  obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
> >  obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
> >  obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> >+obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
> >  obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
> >  obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
> >  obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
> >diff --git a/drivers/watchdog/ts4800_wdt.c b/drivers/watchdog/ts4800_wdt.c
> >new file mode 100644
> >index 000..2b8de86
> >--- /dev/null
> >+++ b/drivers/watchdog/ts4800_wdt.c
> >@@ -0,0 +1,215 @@
> >+/*
> >+ * Watchdog driver for TS-4800 based boards
> >+ *
> >+ * Copyright (c) 2015 - Savoir-faire Linux
> >+ *
> >+ * This file is licensed under the terms of the GNU General Public
> >+ * License version 2. This program is licensed "as is" without any
> >+ * warranty of any kind, whether express or implied.
> >+ */
> >+
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+
> >+static bool nowayout = WATCHDOG_NOWAYOUT;
> >+module_param(nowayout, bool, 0);
> >+MODULE_PARM_DESC(nowayout,
> >+"Watchdog cannot be stopped once started (default="
> >+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> >+
> >+/* possible feed values */
> >+#define TS4800_WDT_FEED_2S   0x1
> >+#define TS4800_WDT_FEED_10S  0x2
> >+#define TS4800_WDT_DISABLE   0x3
> >+
> >+struct ts4800_wdt {
> >+struct watchdog_device  wdd;
> >+struct regmap

Re: [PATCH v2 1/2] dt-bindings: Misc fix for the ATH79 MISC interrupt controllers

[Rob Herring]

On Sun, Nov 29, 2015 at 01:40:11PM +0100, Alban Bedel wrote:
> Add a missing quote in the example
> 
> Signed-off-by: Alban Bedel 
> CC: triv...@kernel.org

Applied, thanks.

Rob

> ---
>  .../devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt| 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
>  
> b/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
> index ec96b1f..475ae9b 100644
> --- 
> a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
> +++ 
> b/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
> @@ -22,7 +22,7 @@ Interrupt Controllers bindings used by client devices.
>  Example:
>  
>   interrupt-controller@18060010 {
> - compatible = "qca,ar9132-misc-intc", qca,ar7100-misc-intc";
> + compatible = "qca,ar9132-misc-intc", "qca,ar7100-misc-intc";
>   reg = <0x18060010 0x4>;
>  
>   interrupt-parent = <&cpuintc>;
> -- 
> 2.0.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] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Tony Lindgren]

* Felipe Balbi  [151204 09:23]:
> 
> Hi,
> 
> Peter Ujfalusi  writes:
> > @@ -174,12 +182,44 @@
> > };
> >  
> > edma: edma@4900 {
> > -   compatible = "ti,edma3";
> > -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> > -   reg =   <0x4900 0x1>,
> > -   <0x44e10f90 0x40>;
> > +   compatible = "ti,edma3-tpcc";
> > +   ti,hwmods = "tpcc";
> > +   reg =   <0x4900 0x1>;
> > +   reg-names = "edma3_cc";
> > interrupts = <12 13 14>;
> > -   #dma-cells = <1>;
> > +   interrupt-names = "edma3_ccint", "emda3_mperr",
> > + "edma3_ccerrint";
> > +   dma-requests = <64>;
> > +   #dma-cells = <2>;
> > +
> > +   ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
> > +  <&edma_tptc2 0>;
> > +
> > +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> 
> can you explain this property here ? Are you setting bits 20 and 21 on a
> 16-bit field ?

I think it's an arry of u16 dma channels.. But could it be just /bits/ 8
instead of /bits/ 16?

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

Re: [PATCH V6 net-next 5/5] net:hns: Add the init code to disable Hip06 "Hardware VLAN assist"

[Salil Mehta]

On 12/2/2015 7:46 PM, Sergei Shtylyov wrote:

Hello.

On 12/02/2015 07:52 PM, Salil Mehta wrote:


This patch adds the initializzation code to disable the hardware
vlan support for VLAN Tag stripping by default for now.

Proper support of "hardware VLAN assitance" feature would
soon come in the next coming patches.

Signed-off-by: Salil Mehta 
---

PATCH V6:
- No change over the earlier patch

PATCH V5:
- Minor merge/reject change resolved to application of previous patch

PATCH V4/V3/V2:
- No change over the initial floated patch

PATCH V1:
- Initial code to disable the hardware VLAN assist for now
---
  drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c |7 +++
  drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |1 +
  2 files changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c

index b5e4c44..f302ef9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -176,6 +176,11 @@ static void hns_ppe_cnt_clr_ce(struct hns_ppe_cb 
*ppe_cb)

   PPE_CNT_CLR_CE_B, 1);
  }

+static void hns_ppe_set_vlan_strip(struct hns_ppe_cb *ppe_cb, int en)
+{
+dsaf_write_dev(ppe_cb, PPEV2_VLAN_STRIP_EN_REG, en);


   Why not call it directly?

Hi Sergei,
The wrapper API abstraction has been put intentionally. The reason is 
the same code
is suppose to run across different SoCs so it is always clean approach 
to hide it so
that even if there are differences in the way we access or configure 
hardware

in other SoCs basic interface of the SET API remains same!!
Therefore, we are in favour of keeping the above wrapper and therefore not
changing now.

Best regards
Salil

+}
+
  /**
   * hns_ppe_checksum_hw - set ppe checksum caculate
   * @ppe_device: ppe device
@@ -336,6 +341,8 @@ static void hns_ppe_init_hw(struct hns_ppe_cb 
*ppe_cb)

  hns_ppe_cnt_clr_ce(ppe_cb);

  if (!AE_IS_VER1(dsaf_dev->dsaf_ver)) {
+hns_ppe_set_vlan_strip(ppe_cb, 0);
+
  /* set default RSS key in h/w */
  hns_ppe_set_rss_key(ppe_cb, ppe_cb->rss_key);

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h

index 98c163e..6c18ca9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -318,6 +318,7 @@
  #define PPE_CFG_PARSE_TAG_REG0x94
  #define PPE_CFG_PRO_CHECK_EN_REG0x98
  #define PPEV2_CFG_TSO_EN_REG0xA0
+#define PPEV2_VLAN_STRIP_EN_REG 0xAC


   Please indent with tabs, like all the surrounding #define's are 
indented (except PPEV2_CFG_TSO_EN_REG).

Thanks for this. I have changed this in PATCH V7 already floated.

Best Regards
Salil

  #define PPE_INTEN_REG 0x100
  #define PPE_RINT_REG0x104
  #define PPE_INTSTS_REG0x108


MBR, Sergei




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

[PATCH] fix noderef.cocci warnings

[kbuild test robot]

drivers/misc/gpio-switch.c:98:34-40: ERROR: application of sizeof to pointer

 sizeof when applied to a pointer typed expression gives the size of
 the pointer

Generated by: scripts/coccinelle/misc/noderef.cocci

CC: Martyn Welch 
Signed-off-by: Fengguang Wu 
---

 gpio-switch.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/misc/gpio-switch.c
+++ b/drivers/misc/gpio-switch.c
@@ -95,7 +95,7 @@ static int gpio_switch_probe(struct plat
if (i < 1)
return i;
 
-   gpios = devm_kmalloc(&pdev->dev, sizeof(gpios) * i, GFP_KERNEL);
+   gpios = devm_kmalloc(&pdev->dev, sizeof(*gpios) * i, GFP_KERNEL);
if (!gpios)
return -ENOMEM;
 
--
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] Add support for monitoring gpio switches

[kbuild test robot]

Hi Martyn,

[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on v4.4-rc3 next-20151203]

url:
https://github.com/0day-ci/linux/commits/Martyn-Welch/Device-tree-binding-documentation-for-gpio-switch/20151205-014105


coccinelle warnings: (new ones prefixed by >>)

>> drivers/misc/gpio-switch.c:98:34-40: ERROR: application of sizeof to pointer

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
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 02/12] drm/etnaviv: add devicetree bindings

[Jon Nettleton]

On Fri, Dec 4, 2015 at 6:56 PM, Lucas Stach  wrote:
> Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
>> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  wrote:
>> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
>> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
>> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
>> >> > master device node to bind all the individual GPU cores together
>> >> > into one DRM device.
>> >> >
>> >> > Signed-off-by: Lucas Stach 
>> >> > ---
>> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
>> >> > ++
>> >> >  1 file changed, 46 insertions(+)
>> >> >  create mode 100644 
>> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> >
>> >> > diff --git 
>> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
>> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > new file mode 100644
>> >> > index ..19fde29dc1d7
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > @@ -0,0 +1,46 @@
>> >> > +Etnaviv DRM master device
>> >> > +
>> >> > +
>> >> > +The Etnaviv DRM master device is a virtual device needed to list all
>> >> > +Vivante GPU cores that comprise the GPU subsystem.
>> >> > +
>> >> > +Required properties:
>> >> > +- compatible: Should be one of
>> >> > +"fsl,imx-gpu-subsystem"
>> >> > +"marvell,dove-gpu-subsystem"
>> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
>> >> > devices
>> >> > +
>> >> > +example:
>> >> > +
>> >> > +gpu-subsystem {
>> >> > +   compatible = "fsl,imx-gpu-subsystem";
>> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
>> >> > +};
>> >>
>> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
>> >> driver.
>> >>
>> > I'm aware of that, but I don't see much value in kicking this discussion
>> > around for every DRM driver submission. This is the binding that has
>> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
>> > allows us to standardize on _something_. Also ALSA does a similar thing
>> > to bind codecs and CPU interfaces together.
>>
>> This case is quite different though I think. The ALSA case and other
>> DRM cases are ones that have inter-dependencies between the blocks
>> (e.g. some sort of h/w connection). What is the inter-dependency here?
>>
>> Doing this way has also been found to be completely unnecessary and
>> removed in recent DRM driver reviews. Admittedly, those are cases
>> where one device can be the master of the others. For 2 parallel
>> devices, I don't have an alternative other than question why they need
>> to be a single driver.
>>
> If you insist on doing things differently for this driver, we could add
> a pass at driver registration that scans through the DT, looking for
> nodes matching the GPU core compatible.
>
> I'm not sure if that makes things cleaner though and might bite us later
> on. Also I'm not sure if moving away from the binding scheme already
> established for other DRM drivers makes things better from a DT
> perspective. Personally I would prefer DT binding consistency over
> perfection for single drivers, segmenting the DT binding space.
>

We should also keep in mind that Vivante is working on newer chipsets
that also include multiple independent 3d cores.  I am not even sure
how userspace would deal with this using the suggested changes.
--
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 02/12] drm/etnaviv: add devicetree bindings

[Lucas Stach]

Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  wrote:
> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
> >> > master device node to bind all the individual GPU cores together
> >> > into one DRM device.
> >> >
> >> > Signed-off-by: Lucas Stach 
> >> > ---
> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
> >> > ++
> >> >  1 file changed, 46 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> > new file mode 100644
> >> > index ..19fde29dc1d7
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> > @@ -0,0 +1,46 @@
> >> > +Etnaviv DRM master device
> >> > +
> >> > +
> >> > +The Etnaviv DRM master device is a virtual device needed to list all
> >> > +Vivante GPU cores that comprise the GPU subsystem.
> >> > +
> >> > +Required properties:
> >> > +- compatible: Should be one of
> >> > +"fsl,imx-gpu-subsystem"
> >> > +"marvell,dove-gpu-subsystem"
> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
> >> > devices
> >> > +
> >> > +example:
> >> > +
> >> > +gpu-subsystem {
> >> > +   compatible = "fsl,imx-gpu-subsystem";
> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
> >> > +};
> >>
> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
> >> driver.
> >>
> > I'm aware of that, but I don't see much value in kicking this discussion
> > around for every DRM driver submission. This is the binding that has
> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> > allows us to standardize on _something_. Also ALSA does a similar thing
> > to bind codecs and CPU interfaces together.
> 
> This case is quite different though I think. The ALSA case and other
> DRM cases are ones that have inter-dependencies between the blocks
> (e.g. some sort of h/w connection). What is the inter-dependency here?
> 
> Doing this way has also been found to be completely unnecessary and
> removed in recent DRM driver reviews. Admittedly, those are cases
> where one device can be the master of the others. For 2 parallel
> devices, I don't have an alternative other than question why they need
> to be a single driver.
> 
If you insist on doing things differently for this driver, we could add
a pass at driver registration that scans through the DT, looking for
nodes matching the GPU core compatible.

I'm not sure if that makes things cleaner though and might bite us later
on. Also I'm not sure if moving away from the binding scheme already
established for other DRM drivers makes things better from a DT
perspective. Personally I would prefer DT binding consistency over
perfection for single drivers, segmenting the DT binding space.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 11:33:22AM -0600, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  wrote:
> > I'm aware of that, but I don't see much value in kicking this discussion
> > around for every DRM driver submission. This is the binding that has
> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> > allows us to standardize on _something_. Also ALSA does a similar thing
> > to bind codecs and CPU interfaces together.
> 
> This case is quite different though I think. The ALSA case and other
> DRM cases are ones that have inter-dependencies between the blocks
> (e.g. some sort of h/w connection). What is the inter-dependency here?

Different GPU cores, where each GPU core is a separate device.  On iMX6,
we have three different GPU cores, two of which need to do cross-GPU
synchronisation for accesses to the buffers.

Sure, we could have decided to publish three entirely different DRM
devices, but that has serious implications: we would be highly non-
standard on the DRI and XF86 cases, to the point where it'd probably
be beyond any hope in getting it to work sanely.  DRI2 requires the
DRM device to be used by MESA to be passed across the X protocol to
authorise the MESA side.

It's already icky enough with the separate DRM device for KMS - which
having poked about with DRI3, I can't see really working at the moment.

> > Same as above really. Parts of the identification registers are
> > different for each SoC integration, even if it's the same IP core, so we
> > can just derive any needed driver behavior differences from that.
> 
> The h/w designers must have had a clue about s/w. First time for
> everything... ;)
> 
> Ok, please just add a note to the binding why a more specific
> compatible is not needed in this case.

If we did want to be safe, we _could_ require something like:

compatible = "vivante,gc320", "vivante,gc";

but I don't see much value to that, because, from what I can see if the
way the GPU numbering/versioning scheme works, the revision number is
the more important bit of information: I believe this started at 1 which
has been incremented ever since.

This can be seen as the GC600 is a much older core than the GC320.

The GC numbering tells you nothing (as far as can be worked out yet)
about what features, what kind of GPU, or anything like that.

Another example: the iMX6 S/DL has a GC880 instead of a GC2000.  While
both are a 3D GPU, they're not really "compatible" with each other -
GC880 has one pixel pipe which requires userspace buffers to be tiled
one way, vs GC2000 which has a different form of tiling to allow two
pixel pipes to operate efficiently.

The number of pixel pipes (and other features) comes from the feature/
specification registers embedded in the device - there's currently 6
32-bit registers, each containing 32 feature flags, describing what
features are present, and including what bugs are present and/or have
been fixed.

There have been one "slip-up" along the way, where the Vivante software
folk have comments in the code along the lines of "Hardware people should
talk to us!!!" which tends to suggest that they've hit the communication
problem, and as it's for very early stuff, and nothing later, it suggests
that they've learnt that lesson themselves already. :)

-- 
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

[PATCH v2 1/5] power: domain: add pm_genpd_exit

[Eric Anholt]

From: Alexander Aring 

This patch adds function pm_genpd_exit for undo a pm_genpd_init. This
is useful for multiple power domains while probing. If the probing fails
after one pm_genpd_init was called we need to undo all previous
registrations of generic pm domains inside the gpd_list list.

There is a check on IS_ERR_OR_NULL(genpd) which is useful to check again
registered power domains and not registered domains, the driver can use
this mechanism to have an array with registered and non-registered power
domains, where non-registered power domains are NULL.

Cc: Rafael J. Wysocki 
Cc: Kevin Hilman 
Cc: Ulf Hansson 
Cc: Pavel Machek 
Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Signed-off-by: Alexander Aring 
Signed-off-by: Eric Anholt 
Acked-by: Ulf Hansson 
---
 drivers/base/power/domain.c | 22 ++
 include/linux/pm_domain.h   |  4 
 2 files changed, 26 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 167418e..e7aca27 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1509,6 +1509,28 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 }
 EXPORT_SYMBOL_GPL(pm_genpd_init);
 
+/**
+ * pm_genpd_exit - Uninitialize a generic I/O PM domain object.
+ * @genpd: PM domain object to uninitialize.
+ */
+void pm_genpd_exit(struct generic_pm_domain *genpd)
+{
+   if (IS_ERR_OR_NULL(genpd))
+   return;
+
+   /* check if domain is still in registered inside the pm subsystem */
+   WARN_ON_ONCE(!list_empty(&genpd->master_links) ||
+!list_empty(&genpd->slave_links) ||
+!list_empty(&genpd->dev_list));
+
+   mutex_lock(&gpd_list_lock);
+   list_del(&genpd->gpd_list_node);
+   mutex_unlock(&gpd_list_lock);
+
+   mutex_destroy(&genpd->lock);
+}
+EXPORT_SYMBOL_GPL(pm_genpd_exit);
+
 #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
 /*
  * Device Tree based PM domain providers.
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index ba4ced3..5020b36 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -123,6 +123,7 @@ extern int pm_genpd_remove_subdomain(struct 
generic_pm_domain *genpd,
 struct generic_pm_domain *target);
 extern void pm_genpd_init(struct generic_pm_domain *genpd,
  struct dev_power_governor *gov, bool is_off);
+extern void pm_genpd_exit(struct generic_pm_domain *genpd);
 
 extern struct dev_power_governor simple_qos_governor;
 extern struct dev_power_governor pm_domain_always_on_gov;
@@ -161,6 +162,9 @@ static inline void pm_genpd_init(struct generic_pm_domain 
*genpd,
 struct dev_power_governor *gov, bool is_off)
 {
 }
+static inline void pm_genpd_exit(struct generic_pm_domain *genpd)
+{
+}
 #endif
 
 static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
-- 
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

[PATCH v2 3/5] ARM: bcm2835: add rpi power domain driver

[Eric Anholt]

From: Alexander Aring 

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

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

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

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

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

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8c53c55..0f23bad 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -134,6 +134,16 @@ config ARCH_BCM2835
  This enables support for the Broadcom BCM2835 SoC. This SoC is
  used in the Raspberry Pi and Roku 2 devices.
 
+config RASPBERRYPI_POWER
+   bool "Raspberry Pi power domain driver"
+   depends on ARCH_BCM2835 || COMPILE_TEST
+   depends on RASPBERRYPI_FIRMWARE
+   select PM_GENERIC_DOMAINS if PM
+   select PM_GENERIC_DOMAINS_OF if PM
+   help
+ This enables support for the RPi power domains which can be enabled
+ or disabled via the RPi firmware.
+
 config ARCH_BCM_63XX
bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
depends on MMU
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..fec2d6b 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -36,6 +36,7 @@ endif
 
 # BCM2835
 obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o
 
 # BCM5301X
 obj-$(CONFIG_ARCH_BCM_5301X)   += bcm_5301x.o
diff --git a/arch/arm/mach-bcm/raspberrypi-power.c 
b/arch/arm/mach-bcm/raspberrypi-power.c
new file mode 100644
index 000..3444301
--- /dev/null
+++ b/arch/arm/mach-bcm/raspberrypi-power.c
@@ -0,0 +1,269 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Authors:
+ * (C) 2015 Pengutronix, Alexander Aring 
+ * Eric Anholt 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Firmware indices for the old power domains interface.  Only a few
+ * of them were actually implemented.
+ */
+#define RPI_OLD_POWER_DOMAIN_USB   3
+#define RPI_OLD_POWER_DOMAIN_V3D   10
+
+struct rpi_power_domain {
+   u32 domain;
+   bool enabled;
+   bool old_interface;
+   struct generic_pm_domain base;
+   struct rpi_firmware *fw;
+};
+
+struct rpi_power_domains {
+   bool has_new_interface;
+   struct genpd_onecell_data xlate;
+   struct rpi_firmware *fw;
+   struct rpi_power_domain domains[RPI_POWER_DOMAIN_COUNT];
+};
+
+/*
+ * Packet definition used by RPI_FIRMWARE_SET_POWER_STATE and
+ * RPI_FIRMWARE_SET_DOMAIN_STATE
+ */
+struct rpi_power_domain_packet {
+   u32 domain;
+   u32 on;
+} __packet;
+
+/*
+ * Asks the firmware to enable or disable power on a specific power
+ * domain.
+ */
+static int rpi_firmware_set_power(struct rpi_power_domain *rpi_domain, bool on)
+{
+   struct rpi_power_domain_packet packet;
+
+   packet.domain = rpi_domain->domain;
+   packet.on = on;
+   return rpi_firmware_property(rpi_domain->fw,
+rpi_domain->old_interface ?
+RPI_FIRMWARE_SET_POWER_STATE :
+RPI_FIRMWARE_SET_DOMAIN_STATE,
+&packet, sizeof(packet));
+}
+
+static int rpi_domain_off(struct generic_pm_domain *domain)
+{
+   struct rpi_power_domain *rpi_domain =
+   container_of(domain, struct rpi_power_domain, base);
+
+   return rpi_firmware_set_power(rpi_domain, false);
+}
+
+static int rpi_domain_on(struct generic_pm_domain *domain)
+{
+   struct rpi_power_domain *rpi_domain =
+   container_of(domain, struct rpi_power_domain, base);
+
+   return rpi_firmware_set_power(rpi_domain, true);
+}
+
+static void rpi_common_init_power_domain(struct rpi_power_domains *rpi_domains,
+int xlate_index, const char *name)
+{
+   struct rpi_power_domain *dom = &rpi_domains->domains[xlate_index];
+
+   dom->fw = rpi_domains->fw;
+
+   dom->base.name = name;
+   dom->base.power_on = rpi_d

[PATCH v2 0/5] Raspberry Pi power domains v2

[Eric Anholt]

This is a series to replace Alexander Aring's power domains
submission.  It uses a new firmware interface to add support for the
other power domains in the system, which I needed for the 3D support,
while still supporting the USB domain on older firmwares.  It also
drops the static declarations, so that the driver instance is entirely
contained inside of the device.

Alexander Aring (4):
  power: domain: add pm_genpd_exit
  ARM: bcm2835: add rpi power domain driver
  dt-bindings: add rpi power domain driver bindings
  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

Eric Anholt (1):
  ARM: bcm2835: Define two new packets from the latest firmware.

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  47 
 arch/arm/boot/dts/bcm2835-rpi.dtsi |  11 +
 arch/arm/boot/dts/bcm2835.dtsi |   2 +-
 arch/arm/mach-bcm/Kconfig  |  10 +
 arch/arm/mach-bcm/Makefile |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c  | 269 +
 drivers/base/power/domain.c|  22 ++
 include/dt-bindings/arm/raspberrypi-power.h|  41 
 include/linux/pm_domain.h  |   4 +
 include/soc/bcm2835/raspberrypi-firmware.h |   2 +
 10 files changed, 408 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

-- 
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

[PATCH v2 2/5] ARM: bcm2835: Define two new packets from the latest firmware.

[Eric Anholt]

These packets give us direct access to the firmware's power management
code, as opposed to GET/SET_POWER_STATE packets that only had a couple
of domains implemented.

Signed-off-by: Eric Anholt 
---
 include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index c07d74a..3fb3571 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -72,10 +72,12 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_ENABLE_QPU = 0x00030012,
RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE =   0x00030014,
RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
+   RPI_FIRMWARE_GET_DOMAIN_STATE =   0x00030030,
RPI_FIRMWARE_SET_CLOCK_STATE =0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
RPI_FIRMWARE_SET_VOLTAGE =0x00038003,
RPI_FIRMWARE_SET_TURBO =  0x00038009,
+   RPI_FIRMWARE_SET_DOMAIN_STATE =   0x00038030,
 
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE =   0x00040001,
-- 
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

[PATCH v2 4/5] dt-bindings: add rpi power domain driver bindings

[Eric Anholt]

From: Alexander Aring 

This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.

Signed-off-by: Alexander Aring 
Acked-by: Rob Herring 
Signed-off-by: Eric Anholt 
---

v2: Add the new domains present in v2 to the list.

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 000..30942cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,47 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible:  Should be "raspberrypi,bcm2835-power".
+- firmware:Reference to the RPi firmware device node.
+- #power-domain-cells: Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_I2C0
+ RPI_POWER_DOMAIN_I2C1
+ RPI_POWER_DOMAIN_I2C2
+ RPI_POWER_DOMAIN_VIDEO_SCALER
+ RPI_POWER_DOMAIN_VPU1
+ RPI_POWER_DOMAIN_HDMI
+ RPI_POWER_DOMAIN_USB
+ RPI_POWER_DOMAIN_VEC
+ RPI_POWER_DOMAIN_JPEG
+ RPI_POWER_DOMAIN_H264
+ RPI_POWER_DOMAIN_V3D
+ RPI_POWER_DOMAIN_ISP
+ RPI_POWER_DOMAIN_UNICAM0
+ RPI_POWER_DOMAIN_UNICAM1
+ RPI_POWER_DOMAIN_CCP2RX
+ RPI_POWER_DOMAIN_CSI2
+ RPI_POWER_DOMAIN_CPI
+ RPI_POWER_DOMAIN_DSI0
+ RPI_POWER_DOMAIN_DSI1
+ RPI_POWER_DOMAIN_TRANSPOSER
+ RPI_POWER_DOMAIN_CCP2TX
+ RPI_POWER_DOMAIN_CDP
+ RPI_POWER_DOMAIN_ARM
+
+Example:
+
+power: power {
+   compatible = "raspberrypi,bcm2835-power";
+   firmware = <&firmware>;
+   #power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+&usb {
+   power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
-- 
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

[PATCH v2 5/5] ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

[Eric Anholt]

From: Alexander Aring 

This connects the USB driver to the USB power domain, so that USB can
actually be turned on at boot if the bootloader didn't do it for us.

Signed-off-by: Alexander Aring 
Signed-off-by: Eric Anholt 
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 +++
 arch/arm/boot/dts/bcm2835.dtsi |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..f828202 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include 
 #include "bcm2835.dtsi"
 
 / {
@@ -20,6 +21,12 @@
compatible = "raspberrypi,bcm2835-firmware";
mboxes = <&mailbox>;
};
+
+   power: power {
+   compatible = "raspberrypi,bcm2835-power";
+   firmware = <&firmware>;
+   #power-domain-cells = <1>;
+   };
};
 };
 
@@ -60,3 +67,7 @@
status = "okay";
bus-width = <4>;
 };
+
+&usb {
+   power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..6d62af0 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -177,7 +177,7 @@
status = "disabled";
};
 
-   usb@7e98 {
+   usb: usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
interrupts = <1 9>;
-- 
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

[PATCH 2/3] Add support for monitoring gpio switches

[Martyn Welch]

Select Chromebooks have gpio attached to switches used to cause the
firmware to enter alternative modes of operation and/or control other
device characteristics (such as write protection on flash devices). This
patch adds a driver that exposes a read-only interface to allow these
signals to be read from user space.

This functionality has been generalised to provide support for any device
with device tree support which needs to identify a gpio as being used for a
specific task.

Signed-off-by: Martyn Welch 
---
 drivers/misc/Kconfig   |  11 
 drivers/misc/Makefile  |   1 +
 drivers/misc/gpio-switch.c | 160 +
 3 files changed, 172 insertions(+)
 create mode 100644 drivers/misc/gpio-switch.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 22892c7..d24367c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -525,6 +525,17 @@ config VEXPRESS_SYSCFG
  bus. System Configuration interface is one of the possible means
  of generating transactions on this bus.
 
+config GPIO_SWITCH
+   tristate "GPIO Switch driver"
+   depends on GPIO_SYSFS
+   ---help---
+Some devices have gpio attached to dedicated switches, an example of
+this are chromebooks (where connection to some switches for predefined
+purposes are provided on the generic development card). This driver
+provides the ability to create consistently named sysfs entries to the
+functionally equivalent signals across a range of devices. This
+functionality currently requires a device which supports device tree.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 537d7f3..7a7e11a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_GENWQE)  += genwqe/
 obj-$(CONFIG_ECHO) += echo/
 obj-$(CONFIG_VEXPRESS_SYSCFG)  += vexpress-syscfg.o
 obj-$(CONFIG_CXL_BASE) += cxl/
+obj-$(CONFIG_GPIO_SWITCH)  += gpio-switch.o
diff --git a/drivers/misc/gpio-switch.c b/drivers/misc/gpio-switch.c
new file mode 100644
index 000..1f381d6
--- /dev/null
+++ b/drivers/misc/gpio-switch.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) 2015 Collabora Ltd.
+ *
+ * based on vendor driver,
+ *
+ * Copyright (C) 2011 The Chromium OS Authors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct gpio_switch_gpio_info {
+   int gpio;
+   const char *link;
+};
+
+static int dt_gpio_init(struct platform_device *pdev, struct device_node 
*child,
+   struct gpio_switch_gpio_info *gpio)
+{
+   int err;
+   enum of_gpio_flags of_flags;
+   unsigned long flags = GPIOF_DIR_IN | GPIOF_EXPORT;
+   const char *name;
+
+   err = of_property_read_string(child, "label", &name);
+   if (err)
+   return err;
+
+   gpio->gpio = of_get_named_gpio_flags(child, "gpios", 0, &of_flags);
+   if (!gpio_is_valid(gpio->gpio)) {
+   err = -EINVAL;
+   goto err_prop;
+   }
+
+   if (of_flags & OF_GPIO_ACTIVE_LOW)
+   flags |= GPIOF_ACTIVE_LOW;
+
+   if (!of_property_read_bool(child, "read-only"))
+   flags |= GPIOF_EXPORT_CHANGEABLE;
+
+   err = gpio_request_one(gpio->gpio, flags, name);
+   if (err)
+   goto err_prop;
+
+   err = gpio_export_link(&pdev->dev, name, gpio->gpio);
+   if (err)
+   goto err_gpio;
+
+   gpio->link = name;
+
+   return 0;
+
+err_gpio:
+   gpio_free(gpio->gpio);
+err_prop:
+   of_node_put(child);
+
+   return err;
+}
+
+static void gpio_switch_rem(struct device *dev,
+   struct gpio_switch_gpio_info *gpio)
+{
+   sysfs_remove_link(&dev->kobj, gpio->link);
+
+   gpio_unexport(gpio->gpio);
+
+   gpio_free(gpio->gpio);
+}
+
+static int gpio_switch_probe(struct platform_device *pdev)
+{
+   struct gpio_switch_gpio_info *gpios;
+   struct device_node *child;
+   struct device_node *np = pdev->dev.of_node;
+   int ret;
+   int i;
+
+   i = of_get_child_count(np);
+   if (i < 1)
+   return i;
+
+   gpios = devm_kmalloc(&pdev->dev, sizeof(gpios) * i, GFP_KERNEL);
+   if (!gpios)
+   return -ENOMEM;
+
+   i = 0;
+
+  

[PATCH 3/3] ARM: dts: Addition of binding for gpio switches on peach-pi

[Martyn Welch]

The peach pi has a GPIO connected to the firmware write protect, developer
mode and recovery mode lines (which are primarily controlled via external
switches on developer test board). This patch adds the required nodes to
the device tree to configure the pinmuxing and allow these to be read from
user space.

Signed-off-by: Martyn Welch 
---
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..2937372 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -53,6 +53,31 @@
};
};
 
+   gpio-switch {
+   compatible = "gpio-switch";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
+
+   write-protect {
+   label = "write-protect";
+   gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+   read-only;
+   };
+
+   developer-switch {
+   label = "developer-switch";
+   gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+   read-only;
+   };
+
+   recovery-switch {
+   label = "recovery-switch";
+   gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+   read-only;
+   };
+   };
+
gpio-keys {
compatible = "gpio-keys";
 
@@ -731,6 +756,13 @@
samsung,pin-val = <0>;
};
 
+   rec_mode: rec-mode {
+   samsung,pins = "gpx0-7";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
tpm_irq: tpm-irq {
samsung,pins = "gpx1-0";
samsung,pin-function = <0>;
@@ -752,6 +784,13 @@
samsung,pin-drv = <0>;
};
 
+   dev_mode: dev-mode {
+   samsung,pins = "gpx1-3";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+
ec_irq: ec-irq {
samsung,pins = "gpx1-5";
samsung,pin-function = <0>;
@@ -773,6 +812,13 @@
samsung,pin-drv = <0>;
};
 
+   wp_gpio: wp_gpio {
+   samsung,pins = "gpx3-0";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
max77802_irq: max77802-irq {
samsung,pins = "gpx3-1";
samsung,pin-function = <0>;
-- 
2.1.4

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

[PATCH 1/3] Device tree binding documentation for gpio-switch

[Martyn Welch]

This patch adds documentation for the gpio-switch binding. This binding
provides a mechanism to bind named links to gpio, with the primary
purpose of enabling standardised access to switches that might be standard
across a group of devices but implemented differently on each device.

Signed-off-by: Martyn Welch 
---
 .../devicetree/bindings/misc/gpio-switch.txt   | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/gpio-switch.txt

diff --git a/Documentation/devicetree/bindings/misc/gpio-switch.txt 
b/Documentation/devicetree/bindings/misc/gpio-switch.txt
new file mode 100644
index 000..13528bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/gpio-switch.txt
@@ -0,0 +1,47 @@
+Device-Tree bindings for gpio attached switches.
+
+This provides a mechanism to provide a named link to specified gpios. This can
+be useful in instances such as when theres a need to monitor a switch, which is
+common across a family of devices, but attached to different gpios and even
+implemented in different ways on differnet devices.
+
+Required properties:
+   - compatible = "gpio-switch";
+
+Each signal is represented as a sub-node of "gpio-switch". The naming of
+sub-nodes is arbitrary.
+
+Required sub-node properties:
+
+   - label: Name to be given to gpio switch.
+   - gpios: OF device-tree gpio specification.
+
+Optional sub-node properties:
+
+   - read-only: Boolean flag to mark the gpio as read-only, i.e. the line
+ should not be driven by the host.
+
+Example nodes:
+
+gpio-switch {
+compatible = "gpio-switch";
+
+write-protect {
+label = "write-protect";
+gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+read-only;
+};
+
+developer-switch {
+label = "developer-switch";
+gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+read-only;
+};
+
+recovery-switch {
+label = "recovery-switch";
+gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+read-only;
+};
+};
+
-- 
2.1.4

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

Re: [PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 06:26:38PM +0100, Marc Kleine-Budde wrote:
> On 12/04/2015 06:07 PM, Russell King - ARM Linux wrote:
> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> >> Signed-off-by: Lucas Stach 
> > 
> > Acked-by: Russell King 
> > 
> > Although, I would like to be copied on patches, I don't think we
> > have a way to encode that information in MAINTAINERS.
> 
> I think you can just add another
> "M: Russell King " next to Lucas. We have this
> for the CAN drivers and it seems to work.

What I'm after avoiding is ending up having to look after this - I've
already enough things on my plate, and I'm not good at context switching
between them.

However, given that I have the ability to test changes on both Dove and
iMX6, that's why I'd like to be Cc'd, so that I can (when I have the
available time) test on Dove, but I don't want to be in the situation
where I'm being required to give acks etc.

-- 
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 02/12] drm/etnaviv: add devicetree bindings

[Rob Herring]

On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  wrote:
> Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
>> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
>> > Etnaviv follows the same priciple as imx-drm to have a virtual
>> > master device node to bind all the individual GPU cores together
>> > into one DRM device.
>> >
>> > Signed-off-by: Lucas Stach 
>> > ---
>> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
>> > ++
>> >  1 file changed, 46 insertions(+)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >
>> > diff --git 
>> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
>> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> > new file mode 100644
>> > index ..19fde29dc1d7
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> > @@ -0,0 +1,46 @@
>> > +Etnaviv DRM master device
>> > +
>> > +
>> > +The Etnaviv DRM master device is a virtual device needed to list all
>> > +Vivante GPU cores that comprise the GPU subsystem.
>> > +
>> > +Required properties:
>> > +- compatible: Should be one of
>> > +"fsl,imx-gpu-subsystem"
>> > +"marvell,dove-gpu-subsystem"
>> > +- cores: Should contain a list of phandles pointing to Vivante GPU devices
>> > +
>> > +example:
>> > +
>> > +gpu-subsystem {
>> > +   compatible = "fsl,imx-gpu-subsystem";
>> > +   cores = <&gpu_2d>, <&gpu_3d>;
>> > +};
>>
>> Yeah, I'm not really a fan of doing this simply because DRM wants 1
>> driver.
>>
> I'm aware of that, but I don't see much value in kicking this discussion
> around for every DRM driver submission. This is the binding that has
> emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> allows us to standardize on _something_. Also ALSA does a similar thing
> to bind codecs and CPU interfaces together.

This case is quite different though I think. The ALSA case and other
DRM cases are ones that have inter-dependencies between the blocks
(e.g. some sort of h/w connection). What is the inter-dependency here?

Doing this way has also been found to be completely unnecessary and
removed in recent DRM driver reviews. Admittedly, those are cases
where one device can be the master of the others. For 2 parallel
devices, I don't have an alternative other than question why they need
to be a single driver.


>> > +Vivante GPU core devices
>> > +
>> > +
>> > +Required properties:
>> > +- compatible: Should be "vivante,gc"
>>
>> This should at least have the specific cores listed like gc-5000 or
>> whatever the numbering is. As is, I can't even tell if this a 2d or 3d
>> core.
>>
> There is really no need for this. The cores have identification
> registers that are much more accurate than what we could describe with a
> compatible value. So using a more specific compatible just provides
> redundant (and possibly wrong) information.
>
>> Also, it probably should have an SOC specific property to deal with SOC
>> specific configuration or integration.
>>
> Same as above really. Parts of the identification registers are
> different for each SoC integration, even if it's the same IP core, so we
> can just derive any needed driver behavior differences from that.

The h/w designers must have had a clue about s/w. First time for
everything... ;)

Ok, please just add a note to the binding why a more specific
compatible is not needed in this case.

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

Add support for monitoring gpio switches

[Martyn Welch]

This driver was written to expose a read only interface to a number of
gpios on Chromebooks. These gpios are attached to signals which cause the
firmware on Chromebooks to enter alternative modes of operation and/or
control other device characteristics (such as write protection on flash
devices). It was originally posted as "Add support for monitoring Chrome
OS firmware signals". A request was made to make it more generic.

In addition this patch series provides the required bindings for this to
the peach-pi Chromebook.

This is a new binding, but the driver is based (now some what loosely) on
functionality in the kernel shipped on Chromebooks.

--
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] of: Check for overlap in reserved memory regions

[Mitchel Humpherys]

On Thu, Nov 12 2015 at 01:19:59 PM, Michael Ellerman  
wrote:
> On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:
>
>> Any overlap in the reserved memory regions (those specified in the
>> reserved-memory DT node) is a bug.
>
> Can you expand a bit on why you think it's a bug? I assume it was discussed at
> some point on the list but I didn't see it sorry.

The reason I think it's a bug is because the overlapping memory could be
handed out to multiple firmwares, which generally ends in "random"
firmware crashes.  We've found by sad experience that root-causing such
a crash can be quite difficult.

Is there a valid use case for overlapping regions?  I can't think of
one...

> There's nothing I can see in the binding document[1] about whether regions can
> overlap, or what it would mean if they did.

You're right, the bindings document doesn't say anything about
overlapping memory regions.  I can submit something unless someone comes
up with a reason why we should allow overlapping memory regions.

> If we want to declare that overlapping regions are always a bug then there
> should be some text in the binding explaining that. There's also the
> possibility that we have existing device trees in the wild that contain
> overlapping regions, and whether we think it's OK to retrospectively declare
> that they're incorrect.

I did a quick survey of in-tree users of reserved-memory and couldn't
find any overlapping regions.


-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Marc Kleine-Budde]

On 12/04/2015 06:07 PM, Russell King - ARM Linux wrote:
> On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
>> Signed-off-by: Lucas Stach 
> 
> Acked-by: Russell King 
> 
> Although, I would like to be copied on patches, I don't think we
> have a way to encode that information in MAINTAINERS.

I think you can just add another
"M: Russell King " next to Lucas. We have this
for the CAN drivers and it seems to work.

> 
>> ---
>>  MAINTAINERS | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e9caa4b28828..1c69563c61ed 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3741,6 +3741,13 @@ S:Maintained
>>  F:  drivers/gpu/drm/sti
>>  F:  Documentation/devicetree/bindings/display/st,stih4xx.txt
>>  
>> +DRM DRIVERS FOR VIVANTE GPU IP
>> +M:  Lucas Stach 
>> +L:  dri-de...@lists.freedesktop.org
>> +S:  Maintained
>> +F:  drivers/gpu/drm/etnaviv
>> +F:  Documentation/devicetree/bindings/display/etnaviv
>> +
>>  DSBR100 USB FM RADIO DRIVER
>>  M:  Alexey Klimov 
>>  L:  linux-me...@vger.kernel.org
>> -- 
>> 2.6.2
>>
> 

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Felipe Balbi]

Hi,

Peter Ujfalusi  writes:
> @@ -174,12 +182,44 @@
>   };
>  
>   edma: edma@4900 {
> - compatible = "ti,edma3";
> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> - reg =   <0x4900 0x1>,
> - <0x44e10f90 0x40>;
> + compatible = "ti,edma3-tpcc";
> + ti,hwmods = "tpcc";
> + reg =   <0x4900 0x1>;
> + reg-names = "edma3_cc";
>   interrupts = <12 13 14>;
> - #dma-cells = <1>;
> + interrupt-names = "edma3_ccint", "emda3_mperr",
> +   "edma3_ccerrint";
> + dma-requests = <64>;
> + #dma-cells = <2>;
> +
> + ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
> +<&edma_tptc2 0>;
> +
> + ti,edma-memcpy-channels = /bits/ 16 <20 21>;

can you explain this property here ? Are you setting bits 20 and 21 on a
16-bit field ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Christian Gmeiner]

2015-12-04 18:13 GMT+01:00 Russell King - ARM Linux :
> On Fri, Dec 04, 2015 at 12:08:47PM -0500, Ilia Mirkin wrote:
>> On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
>>  wrote:
>> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
>> >> Signed-off-by: Lucas Stach 
>> >
>> > Acked-by: Russell King 
>> >
>> > Although, I would like to be copied on patches, I don't think we
>> > have a way to encode that information in MAINTAINERS.
>>
>> >From the top of the MAINTAINERS file:
>>
>> Descriptions of section entries:
>>
>> P: Person (obsolete)
>> M: Mail patches to: FullName 
>> R: Designated reviewer: FullName 
>>These reviewers should be CCed on patches.
>>
>> So I guess that'd mean you want to be a reviewer?
>
> Oh, that got agreed upon?  I thought there was pushback against that
> idea.
>
> You are correct.
>

Put me on the reviewer list too.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
--
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 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Lucas Stach]

Am Freitag, den 04.12.2015, 17:13 + schrieb Russell King - ARM
Linux:
> On Fri, Dec 04, 2015 at 12:08:47PM -0500, Ilia Mirkin wrote:
> > On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
> >  wrote:
> > > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> > >> Signed-off-by: Lucas Stach 
> > >
> > > Acked-by: Russell King 
> > >
> > > Although, I would like to be copied on patches, I don't think we
> > > have a way to encode that information in MAINTAINERS.
> > 
> > >From the top of the MAINTAINERS file:
> > 
> > Descriptions of section entries:
> > 
> > P: Person (obsolete)
> > M: Mail patches to: FullName 
> > R: Designated reviewer: FullName 
> >These reviewers should be CCed on patches.
> > 
> > So I guess that'd mean you want to be a reviewer?
> 
> Oh, that got agreed upon?  I thought there was pushback against that
> idea.
> 
There was pushback to change random people in MAINTAINERS from
maintainer to reviewer just because they don't manage a git tree on
their own. The reviewer tag itself was agreed upon.

If you want to be CC'ed on patches we should definitely add you as a
reviewer.

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 12:08:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
>  wrote:
> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> >> Signed-off-by: Lucas Stach 
> >
> > Acked-by: Russell King 
> >
> > Although, I would like to be copied on patches, I don't think we
> > have a way to encode that information in MAINTAINERS.
> 
> >From the top of the MAINTAINERS file:
> 
> Descriptions of section entries:
> 
> P: Person (obsolete)
> M: Mail patches to: FullName 
> R: Designated reviewer: FullName 
>These reviewers should be CCed on patches.
> 
> So I guess that'd mean you want to be a reviewer?

Oh, that got agreed upon?  I thought there was pushback against that
idea.

You are correct.

-- 
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

[PATCH v2 3/3] ARM: dts: enable GPIO-a for Broadcom NSP

[Yendapally Reddy Dhananjaya Reddy]

This enables the GPIO-a support for Broadcom NSP SoC

Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 58aca27..148d79e 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -116,4 +116,16 @@
status = "disabled";
};
};
+
+   gpioa: gpio@1820 {
+   compatible = "brcm,nsp-gpio-a";
+   reg = <0x1820 0x70>,
+ <0x1803f1c4 0x1c>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   ngpios = <32>;
+   interrupt-controller;
+   interrupts = ;
+   gpio-ranges = <&pinctrl 0 0 32>;
+   };
 };
-- 
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

[PATCH v2 1/3] pinctrl: Broadcom NSP GPIO-a device tree bindings

[Yendapally Reddy Dhananjaya Reddy]

Device tree binding documentation for Broadcom NSP GPIO-a

Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
---
 .../devicetree/bindings/pinctrl/brcm,nsp-gpio.txt  | 80 ++
 1 file changed, 80 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
new file mode 100644
index 000..0844168
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
@@ -0,0 +1,80 @@
+Broadcom Northstar plus (NSP) GPIO/PINCONF Controller
+
+Required properties:
+- compatible:
+Must be "brcm,nsp-gpio-a"
+
+- reg:
+Should contain the register physical address and length for each of
+GPIO base, IO control registers
+
+- #gpio-cells:
+Must be two. The first cell is the GPIO pin number (within the
+controller's pin space) and the second cell is used for the following:
+bit[0]: polarity (0 for active high and 1 for active low)
+
+- gpio-controller:
+Specifies that the node is a GPIO controller
+
+- ngpios:
+Number of gpios supported (58x25 supports 32 and 58x23 supports 24)
+
+Optional properties:
+- interrupts:
+Interrupt ID
+
+- interrupt-controller:
+Specifies that the node is an interrupt controller
+
+- gpio-ranges:
+Specifies the mapping between gpio controller and pin-controllers pins.
+This requires 4 fields in cells defined as -
+1. Phandle of pin-controller.
+2. GPIO base pin offset.
+3  Pin-control base pin offset.
+4. number of gpio pins which are linearly mapped from pin base.
+
+Supported generic PINCONF properties in child nodes:
+- pins:
+The list of pins (within the controller's own pin space) that properties
+in the node apply to. Pin names are "gpio-"
+
+- bias-disable:
+Disable pin bias
+
+- bias-pull-up:
+Enable internal pull up resistor
+
+- bias-pull-down:
+Enable internal pull down resistor
+
+- drive-strength:
+Valid drive strength values include 2, 4, 6, 8, 10, 12, 14, 16 (mA)
+
+Example:
+
+   gpioa: gpio@1820 {
+   compatible = "brcm,nsp-gpio-a";
+   reg = <0x1820 0x100>,
+ <0x1803f1c4 0x1c>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   ngpios = <32>;
+   gpio-ranges = <&pinctrl 0 0 31>;
+   interrupt-controller;
+   interrupts = ;
+
+   /* Hog a few default settings */
+   pinctrl-names = "default";
+   pinctrl-0 = <&led>;
+   led: led {
+   pins = "gpio-1";
+   bias-pull-up;
+   };
+
+   pwr: pwr {
+   gpio-hog;
+   gpios = <3 1>;
+   output-high;
+   };
+   };
-- 
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 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> Signed-off-by: Lucas Stach 

Acked-by: Russell King 

Although, I would like to be copied on patches, I don't think we
have a way to encode that information in MAINTAINERS.

> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9caa4b28828..1c69563c61ed 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3741,6 +3741,13 @@ S: Maintained
>  F:   drivers/gpu/drm/sti
>  F:   Documentation/devicetree/bindings/display/st,stih4xx.txt
>  
> +DRM DRIVERS FOR VIVANTE GPU IP
> +M:   Lucas Stach 
> +L:   dri-de...@lists.freedesktop.org
> +S:   Maintained
> +F:   drivers/gpu/drm/etnaviv
> +F:   Documentation/devicetree/bindings/display/etnaviv
> +
>  DSBR100 USB FM RADIO DRIVER
>  M:   Alexey Klimov 
>  L:   linux-me...@vger.kernel.org
> -- 
> 2.6.2
> 

-- 
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 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Ilia Mirkin]

On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
 wrote:
> On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
>> Signed-off-by: Lucas Stach 
>
> Acked-by: Russell King 
>
> Although, I would like to be copied on patches, I don't think we
> have a way to encode that information in MAINTAINERS.

>From the top of the MAINTAINERS file:

Descriptions of section entries:

P: Person (obsolete)
M: Mail patches to: FullName 
R: Designated reviewer: FullName 
   These reviewers should be CCed on patches.

So I guess that'd mean you want to be a reviewer?

  -ilia
--
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] of: Fix comparison of reserved memory regions

[Mitchel Humpherys]

On Wed, Nov 18 2015 at 09:46:38 PM, Michael Ellerman  
wrote:
> In order to check for overlapping reserved memory regions, we first need
> to sort the array of memory regions. This is implemented using sort(),
> and a custom comparison function __rmem_cmp().
>
> Unfortunatley __rmem_cmp() doesn't work in all cases. Because the two
> base values are phys_addr_t, they may be u64 on some platforms, in which
> case subtracting one from the other and then (implicitly) casting to int
> does not give us the -ve/0/+ve value we need.
>
> This leads to incorrect reports about overlaps, eg:
>
>   ibm,slw-image@1ffe60 (0x001ffe60--0x001ffe70) overlaps 
> with
>   ibm,firmware-allocs-memory@10 
> (0x0010--0x001000dc0200)
>
> Fix it by just doing the standard double if and return 0 logic.
>
> Fixes: ae1add247bf8 ("of: Check for overlap in reserved memory regions")
> Signed-off-by: Michael Ellerman 
> ---
>  drivers/of/of_reserved_mem.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Woops, thanks.

Tested-by: Mitchel Humpherys 

-Mitch

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 05:41:45PM +0100, Lucas Stach wrote:
> Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> > On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > > +gpu-subsystem {
> > > + compatible = "fsl,imx-gpu-subsystem";
> > > + cores = <&gpu_2d>, <&gpu_3d>;
> > > +};
> > 
> > Yeah, I'm not really a fan of doing this simply because DRM wants 1 
> > driver.
> > 
> I'm aware of that, but I don't see much value in kicking this discussion
> around for every DRM driver submission. This is the binding that has
> emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> allows us to standardize on _something_. Also ALSA does a similar thing
> to bind codecs and CPU interfaces together.

Absolutely, this is the interface and method that was discussed and
settled upon, and for DT folk to now start saying that they're not
fans of it is _far_ too late.  If they had concerns, they should have
been discussed during the submission of the first users of it, not
after the 4th or 5th user.

Sure, they may be having reservations about it, but then, I think,
it's up to them to come up with a better solution to this, and discuss
it over with the DRM people, remembering that the DRM people are very
adamant that they're not budging on the "not hotplugging bits" issue,
or if they do, it means _radically_ changing the DRM user API for
everything.

> > Also, it probably should have an SOC specific property to deal with SOC 
> > specific configuration or integration.
>
> Same as above really. Parts of the identification registers are
> different for each SoC integration, even if it's the same IP core,
> so we can just derive any needed driver behavior differences from
> that.

I agree.  There are some bugs in various cores (like the GC320) but
it's not clear whether that's a SoC specific issue or whether it's a
GPU core specific issue: all we know is that GC320 revision X suffers
from a certain bug, which we need to work around in userspace - and as
we pass all the GPU identifying information to userspace, adding such
stuff into DT, and then having to find some way to pass it through to
userspace would just add a whole new level of complexity that isn't
required.

It'd be a case of "okay, we know iMX6 has a GC320 with revision X,
so we better set DT flag Y to indicate that it has this bug" when we
already know in userspace that it's a GC320 revision X and userspace
needs to generate the command stream differently based on that.

So, it seems completely pointless to encode this information in DT.

-- 
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 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 10:29:56AM -0600, Rob Herring wrote:
> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > +Vivante GPU core devices
> > +
> > +
> > +Required properties:
> > +- compatible: Should be "vivante,gc"
> 
> This should at least have the specific cores listed like gc-5000 or 
> whatever the numbering is. As is, I can't even tell if this a 2d or 3d 
> core.

Who cares whether it's a 2D or 3D core?  There are four options here:

2D
2D and 3D
3D
VG

All of these are determined by feature flags in the core - why should
DT have to specify this information when the hardware tells us, just
because we want something humanly visible?

> Also, it probably should have an SOC specific property to deal with SOC 
> specific configuration or integration.

Thus far, we're not aware of any SoC specific configuration of the
core.  Even if there was, I can't see it making much difference to
the DRM driver itself: the DRM driver mostly about command stream
queuing, GEM buffer management (both of which are independent of SoC
issues) and PM management, which is performed via runtime PM.

Where SoC specific integration would come in is the runtime PM, and
that goes as far as what clocks are present, which we already deal
with, power domains, which again we already deal with, and
interrupts - again, which are dealt with.

Given that this driver has been developed on two SoCs (Dove and iMX6)
which are radically different, I can't see any need for other SoC
specifics.

Did you have anything in mind?

Dove:
GC600 combined 2D and 3D GPU core, one clock, one interrupt, one PM
domain.

iMX6 S/DL/D/Q:
GC320 2D GPU core, GC880 or GC2000 3D GPU core, GC335 VG core, multiple
clocks, multiple interrupts, multiple PM domains.

-- 
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 02/12] drm/etnaviv: add devicetree bindings

[Lucas Stach]

Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > Etnaviv follows the same priciple as imx-drm to have a virtual
> > master device node to bind all the individual GPU cores together
> > into one DRM device.
> > 
> > Signed-off-by: Lucas Stach 
> > ---
> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
> > ++
> >  1 file changed, 46 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > new file mode 100644
> > index ..19fde29dc1d7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > @@ -0,0 +1,46 @@
> > +Etnaviv DRM master device
> > +
> > +
> > +The Etnaviv DRM master device is a virtual device needed to list all
> > +Vivante GPU cores that comprise the GPU subsystem.
> > +
> > +Required properties:
> > +- compatible: Should be one of
> > +"fsl,imx-gpu-subsystem"
> > +"marvell,dove-gpu-subsystem"
> > +- cores: Should contain a list of phandles pointing to Vivante GPU devices
> > +
> > +example:
> > +
> > +gpu-subsystem {
> > +   compatible = "fsl,imx-gpu-subsystem";
> > +   cores = <&gpu_2d>, <&gpu_3d>;
> > +};
> 
> Yeah, I'm not really a fan of doing this simply because DRM wants 1 
> driver.
> 
I'm aware of that, but I don't see much value in kicking this discussion
around for every DRM driver submission. This is the binding that has
emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
allows us to standardize on _something_. Also ALSA does a similar thing
to bind codecs and CPU interfaces together.

> > +
> > +
> > +Vivante GPU core devices
> > +
> > +
> > +Required properties:
> > +- compatible: Should be "vivante,gc"
> 
> This should at least have the specific cores listed like gc-5000 or 
> whatever the numbering is. As is, I can't even tell if this a 2d or 3d 
> core.
> 
There is really no need for this. The cores have identification
registers that are much more accurate than what we could describe with a
compatible value. So using a more specific compatible just provides
redundant (and possibly wrong) information.

> Also, it probably should have an SOC specific property to deal with SOC 
> specific configuration or integration.
> 
Same as above really. Parts of the identification registers are
different for each SoC integration, even if it's the same IP core, so we
can just derive any needed driver behavior differences from that.

> > +- reg: should be register base and length as documented in the
> > +  datasheet
> > +- interrupts: Should contain the cores interrupt line
> > +- clocks: should contain one clock for entry in clock-names
> > +  see Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +- clock-names:
> > +   - "bus":AXI/register clock
> > +   - "core":   GPU core clock
> > +   - "shader": Shader clock (only required if GPU has feature PIPE_3D)
> > +
> > +example:
> > +
> > +gpu_3d: gpu@0013 {
> > +   compatible = "vivante,gc";
> > +   reg = <0x0013 0x4000>;
> > +   interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
> > +   clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,
> > +<&clks IMX6QDL_CLK_GPU3D_CORE>,
> > +<&clks IMX6QDL_CLK_GPU3D_SHADER>;
> > +   clock-names = "bus", "core", "shader";
> > +};
> > -- 
> > 2.6.2
> > 

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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