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

[Jisheng Zhang]

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

Since v2:
 - introduce new berlin_pinctrl_probe_regmap() to avoid duplicated code
 - renaming such as s/urt/uart etc. but keep the group name as URT* to keep
   consistent with HW/ASIC

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


Jisheng Zhang (6):
  pinctrl: berlin: introduce berlin_pinctrl_probe_regmap()
  pinctrl: berlin: add the berlin4ct pinctrl driver
  arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs
  pinctrl: dt-binding: document berlin4ct SoC pinctrl
  arm64: dts: berlin4ct: add the pinctrl node
  arm64: dts: berlin4ct: add default pinmux for uart0

 .../devicetree/bindings/pinctrl/berlin,pinctrl.txt |   5 +-
 arch/arm64/Kconfig.platforms   |   1 +
 arch/arm64/boot/dts/marvell/berlin4ct.dtsi |  22 +
 drivers/pinctrl/berlin/Kconfig |   5 +
 drivers/pinctrl/berlin/Makefile|   1 +
 drivers/pinctrl/berlin/berlin-bg4ct.c  | 503 +
 drivers/pinctrl/berlin/berlin.c|  26 +-
 drivers/pinctrl/berlin/berlin.h|   4 +
 8 files changed, 557 insertions(+), 10 deletions(-)
 create mode 100644 drivers/pinctrl/berlin/berlin-bg4ct.c

-- 
2.6.1

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

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

[Jisheng Zhang]

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

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

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

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

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

[Jisheng Zhang]

Add berlin4ct to existing berlin pinctrl device tree binding.

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

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

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

[PATCH v3 1/6] pinctrl: berlin: introduce berlin_pinctrl_probe_regmap()

[Jisheng Zhang]

This is to prepare for the next berlin4ct support, where we won't use
simple-mfd any more.

Signed-off-by: Jisheng Zhang 
---
 drivers/pinctrl/berlin/berlin.c | 26 +-
 drivers/pinctrl/berlin/berlin.h |  4 
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
index f495806..898afa4 100644
--- a/drivers/pinctrl/berlin/berlin.c
+++ b/drivers/pinctrl/berlin/berlin.c
@@ -292,20 +292,14 @@ static struct pinctrl_desc berlin_pctrl_desc = {
.owner  = THIS_MODULE,
 };
 
-int berlin_pinctrl_probe(struct platform_device *pdev,
-const struct berlin_pinctrl_desc *desc)
+int berlin_pinctrl_probe_regmap(struct platform_device *pdev,
+   const struct berlin_pinctrl_desc *desc,
+   struct regmap *regmap)
 {
struct device *dev = &pdev->dev;
-   struct device_node *parent_np = of_get_parent(dev->of_node);
struct berlin_pinctrl *pctrl;
-   struct regmap *regmap;
int ret;
 
-   regmap = syscon_node_to_regmap(parent_np);
-   of_node_put(parent_np);
-   if (IS_ERR(regmap))
-   return PTR_ERR(regmap);
-
pctrl = devm_kzalloc(dev, sizeof(*pctrl), GFP_KERNEL);
if (!pctrl)
return -ENOMEM;
@@ -330,3 +324,17 @@ int berlin_pinctrl_probe(struct platform_device *pdev,
 
return 0;
 }
+
+int berlin_pinctrl_probe(struct platform_device *pdev,
+const struct berlin_pinctrl_desc *desc)
+{
+   struct device *dev = &pdev->dev;
+   struct device_node *parent_np = of_get_parent(dev->of_node);
+   struct regmap *regmap = syscon_node_to_regmap(parent_np);
+
+   of_node_put(parent_np);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   return berlin_pinctrl_probe_regmap(pdev, desc, regmap);
+}
diff --git a/drivers/pinctrl/berlin/berlin.h b/drivers/pinctrl/berlin/berlin.h
index e1aa841..dabbd2a 100644
--- a/drivers/pinctrl/berlin/berlin.h
+++ b/drivers/pinctrl/berlin/berlin.h
@@ -58,4 +58,8 @@ struct berlin_pinctrl_function {
 int berlin_pinctrl_probe(struct platform_device *pdev,
 const struct berlin_pinctrl_desc *desc);
 
+int berlin_pinctrl_probe_regmap(struct platform_device *pdev,
+   const struct berlin_pinctrl_desc *desc,
+   struct regmap *regmap);
+
 #endif /* __PINCTRL_BERLIN_H */
-- 
2.6.1

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

[PATCH v3 5/6] arm64: dts: berlin4ct: add the pinctrl node

[Jisheng Zhang]

Add the avio, soc, sm pinctrl nodes for Marvell berlin4ct SoC.

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

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
index a3b5f1d..8e66355 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
@@ -225,6 +225,16 @@
};
};
 
+   soc_pinctrl: pin-controller@ea8000 {
+   compatible = "marvell,berlin4ct-soc-pinctrl";
+   reg = <0xea8000 0x14>;
+   };
+
+   avio_pinctrl: pin-controller@ea8400 {
+   compatible = "marvell,berlin4ct-avio-pinctrl";
+   reg = <0xea8400 0x8>;
+   };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -280,5 +290,10 @@
status = "disabled";
};
};
+
+   system_pinctrl: pin-controller@fe2200 {
+   compatible = "marvell,berlin4ct-system-pinctrl";
+   reg = <0xfe2200 0xc>;
+   };
};
 };
-- 
2.6.1

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

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

[Jisheng Zhang]

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

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

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
index 8e66355..a4a1876 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
@@ -288,12 +288,19 @@
clocks = <&osc>;
reg-shift = <2>;
status = "disabled";
+   pinctrl-0 = <&uart0_pmux>;
+   pinctrl-names = "default";
};
};
 
system_pinctrl: pin-controller@fe2200 {
compatible = "marvell,berlin4ct-system-pinctrl";
reg = <0xfe2200 0xc>;
+
+   uart0_pmux: uart0-pmux {
+   groups = "SM_URT0_TXD", "SM_URT0_RXD";
+   function = "uart0";
+   };
};
};
 };
-- 
2.6.1

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

[PATCH v3 2/6] pinctrl: berlin: add the berlin4ct pinctrl driver

[Jisheng Zhang]

Add the pin-controller driver for Marvell Berlin BG4CT SoC, with definition
of its groups and functions. This uses the core Berlin pinctrl driver.

Signed-off-by: Jisheng Zhang 
---
 drivers/pinctrl/berlin/Kconfig|   5 +
 drivers/pinctrl/berlin/Makefile   |   1 +
 drivers/pinctrl/berlin/berlin-bg4ct.c | 503 ++
 3 files changed, 509 insertions(+)
 create mode 100644 drivers/pinctrl/berlin/berlin-bg4ct.c

diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index b18322b..c13f6d2 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -17,4 +17,9 @@ config PINCTRL_BERLIN_BG2Q
bool
select PINCTRL_BERLIN
 
+config PINCTRL_BERLIN_BG4CT
+   depends on OF && (ARCH_BERLIN || COMPILE_TEST)
+   bool "Marvell berlin4ct pin controller driver"
+   select PINCTRL_BERLIN
+
 endif
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
index deb0c6b..06f9402 100644
--- a/drivers/pinctrl/berlin/Makefile
+++ b/drivers/pinctrl/berlin/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_PINCTRL_BERLIN)+= berlin.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2)   += berlin-bg2.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2CD) += berlin-bg2cd.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2Q)  += berlin-bg2q.o
+obj-$(CONFIG_PINCTRL_BERLIN_BG4CT) += berlin-bg4ct.o
diff --git a/drivers/pinctrl/berlin/berlin-bg4ct.c 
b/drivers/pinctrl/berlin/berlin-bg4ct.c
new file mode 100644
index 000..9687b41
--- /dev/null
+++ b/drivers/pinctrl/berlin/berlin-bg4ct.c
@@ -0,0 +1,503 @@
+/*
+ * Marvell berlin4ct pinctrl driver
+ *
+ * Copyright (C) 2015 Marvell Technology Group Ltd.
+ *
+ * Author: Jisheng Zhang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "berlin.h"
+
+static const struct berlin_desc_group berlin4ct_soc_pinctrl_groups[] = {
+   BERLIN_PINCTRL_GROUP("EMMC_RSTn", 0x0, 0x3, 0x00,
+   BERLIN_PINCTRL_FUNCTION(0x0, "emmc"), /* RSTn */
+   BERLIN_PINCTRL_FUNCTION(0x1, "gpio")), /* GPIO47 */
+   BERLIN_PINCTRL_GROUP("NAND_IO0", 0x0, 0x3, 0x03,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO0 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXD0 */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* CLK */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO0 */
+   BERLIN_PINCTRL_GROUP("NAND_IO1", 0x0, 0x3, 0x06,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO1 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXD1 */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* CDn */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO1 */
+   BERLIN_PINCTRL_GROUP("NAND_IO2", 0x0, 0x3, 0x09,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO2 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXD2 */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* DAT0 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO2 */
+   BERLIN_PINCTRL_GROUP("NAND_IO3", 0x0, 0x3, 0x0c,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO3 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXD3 */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* DAT1 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO3 */
+   BERLIN_PINCTRL_GROUP("NAND_IO4", 0x0, 0x3, 0x0f,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO4 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXC */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* DAT2 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO4 */
+   BERLIN_PINCTRL_GROUP("NAND_IO5", 0x0, 0x3, 0x12,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO5 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXCTL */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* DAT3 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO5 */
+   BERLIN_PINCTRL_GROUP("NAND_IO6", 0x0, 0x3, 0x15,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO6 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* MDC */
+  

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

[Bharat Kumar Gogada]

> >> +struct nwl_msi {  /* struct nwl_msi - MSI information
> */
> >> +  struct msi_controller chip; /* chip: MSI controller */
> >
> >> We're moving away from msi_controller altogether, as the kernel now
> >> has all the necessary infrastructure to do this properly.
> >
> > Our current GIC version does not have separate msi controller (we are
> > not using GICv2m or GICv3), so is it necessary to have separate msi
> > controller node ? Please give me clarity on this.
>
> This has nothing to do with the version of the GIC you are using (XGene
> doesn't have GICv2m or v3 either). This is about reducing code duplication
> and having something that we can maintain. See also
> https://lkml.org/lkml/2015/9/20/193 for yet another example.
>
> I still plan to kill msi_controller, and I'd like to avoid more dependencies 
> with
> it. MSI domains are the way to do it.
>
Sorry previously I haven't configured my email client properly so resending.

Since we don't have separate MSI controller, and our PCIe controller is 
handling MSI, is it necessary to create a separate MSI controller node because 
we don't have any 'reg' space.
Please let me know whether we require a separate msi file as suggested in your 
previous comments to separate MSI controller and PCIE controller in two files, 
if we don't have separate node.
If we do not need a separate node do we need to embed MSI controller child node 
 in PCIe controller node itself, and what properties does this child node will 
require other than 'interrupts'.

Bharat
> Thanks,
>
>   M.
> --
> Jazz is not dead. It just smells funny...


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

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

Re: [PATCH 3/5] clk: imx7d: add ADC root clock

[Shawn Guo]

On Thu, Oct 08, 2015 at 11:35:56AM -0700, Stephen Boyd wrote:
> On 10/08, Haibo Chen wrote:
> > Add ADC root clock support in imx7d clock tree.
> > 
> > Signed-off-by: Haibo Chen 
> > ---
> 
> I see no cover letter indicating how you want this merged, so:
> 
> Acked-by: Stephen Boyd 

To clarify, I applied it on my imx/clk branch, which will be sent to you
and Mike later.

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

Re: [PATCH 3/5] clk: imx7d: add ADC root clock

[Shawn Guo]

On Thu, Oct 08, 2015 at 11:35:56AM -0700, Stephen Boyd wrote:
> On 10/08, Haibo Chen wrote:
> > Add ADC root clock support in imx7d clock tree.
> > 
> > Signed-off-by: Haibo Chen 
> > ---
> 
> I see no cover letter indicating how you want this merged, so:
> 
> Acked-by: Stephen Boyd 

Applied on IMX tree.

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

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

[Bharat Kumar Gogada]

On 06/10/15 17:27, Bharat Kumar Gogada wrote:
> Subject: Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx 
> NWL PCIe Host Controller

[...]

>> +struct nwl_msi {/* struct nwl_msi - MSI information */
>> +struct msi_controller chip; /* chip: MSI controller */
> 
>> We're moving away from msi_controller altogether, as the kernel now 
>> has all the necessary infrastructure to do this properly.
> 
> Our current GIC version does not have separate msi controller (we are 
> not using GICv2m or GICv3), so is it necessary to have separate msi 
> controller node ? Please give me clarity on this.

This has nothing to do with the version of the GIC you are using (XGene doesn't 
have GICv2m or v3 either). This is about reducing code duplication and having 
something that we can maintain. See also
https://lkml.org/lkml/2015/9/20/193 for yet another example.

I still plan to kill msi_controller, and I'd like to avoid more dependencies 
with it. MSI domains are the way to do it.

Since we don't have separate MSI controller, and our PCIe controller is 
handling MSI, is it necessary to create a separate MSI controller node because 
we don't have any 'reg' space. 
Please let me know whether we require a separate msi file as suggested in your 
previous comments to separate MSI controller and PCIE controller in two files, 
if we don't have separate node. 
If we do not need a separate node do we need to embed MSI controller child node 
 in PCIe controller node itself, and what properties does this child node will 
require other than 'interrupts'.

Bharat

Thanks,

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

[PATCH v5 5/6] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

This patch adds support for mediatek m4u (MultiMedia Memory Management
Unit).

Signed-off-by: Yong Wu 
---
 drivers/iommu/Kconfig |  15 +
 drivers/iommu/Makefile|   1 +
 drivers/iommu/mtk_iommu.c | 767 ++
 3 files changed, 783 insertions(+)
 create mode 100644 drivers/iommu/mtk_iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index a7920fb..b964364 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -387,4 +387,19 @@ config ARM_SMMU_V3
  Say Y here if your system includes an IOMMU device implementing
  the ARM SMMUv3 architecture.
 
+config MTK_IOMMU
+   bool "MTK IOMMU Support"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select IOMMU_API
+   select IOMMU_DMA
+   select IOMMU_IO_PGTABLE_SHORT
+   select MEMORY
+   select MTK_SMI
+   help
+ Support for the M4U on certain Mediatek SOCs. M4U is MultiMedia
+ Memory Management Unit. This option enables remapping of DMA memory
+ accesses for the multimedia subsystem.
+
+ If unsure, say N here.
+
 endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 06df3e6..f4f2f2c 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
 obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
 obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
 obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
+obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o
 obj-$(CONFIG_SHMOBILE_IOMMU) += shmobile-iommu.o
 obj-$(CONFIG_SHMOBILE_IPMMU) += shmobile-ipmmu.o
 obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
new file mode 100644
index 000..39839f7
--- /dev/null
+++ b/drivers/iommu/mtk_iommu.c
@@ -0,0 +1,767 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "io-pgtable.h"
+
+#define REG_MMU_PT_BASE_ADDR   0x000
+
+#define REG_MMU_INVALIDATE 0x020
+#define F_ALL_INVLD0x2
+#define F_MMU_INV_RANGE0x1
+
+#define REG_MMU_INVLD_START_A  0x024
+#define REG_MMU_INVLD_END_A0x028
+
+#define REG_MMU_INV_SEL0x038
+#define F_INVLD_EN0BIT(0)
+#define F_INVLD_EN1BIT(1)
+
+#define REG_MMU_STANDARD_AXI_MODE  0x048
+#define REG_MMU_DCM_DIS0x050
+
+#define REG_MMU_CTRL_REG   0x110
+#define F_MMU_PREFETCH_RT_REPLACE_MOD  BIT(4)
+#define F_MMU_TF_PROTECT_SEL(prot) (((prot) & 0x3) << 5)
+#define F_COHERENCE_EN BIT(8)
+
+#define REG_MMU_IVRP_PADDR 0x114
+#define F_MMU_IVRP_PA_SET(pa)  ((pa) >> 1)
+
+#define REG_MMU_INT_CONTROL0   0x120
+#define F_L2_MULIT_HIT_EN  BIT(0)
+#define F_TABLE_WALK_FAULT_INT_EN  BIT(1)
+#define F_PREETCH_FIFO_OVERFLOW_INT_EN BIT(2)
+#define F_MISS_FIFO_OVERFLOW_INT_ENBIT(3)
+#define F_PREFETCH_FIFO_ERR_INT_EN BIT(5)
+#define F_MISS_FIFO_ERR_INT_EN BIT(6)
+#define F_INT_L2_CLR_BIT   BIT(12)
+
+#define REG_MMU_INT_MAIN_CONTROL   0x124
+#define F_INT_TRANSLATION_FAULTBIT(0)
+#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
+#define F_INT_INVALID_PA_FAULT BIT(2)
+#define F_INT_ENTRY_REPLACEMENT_FAULT  BIT(3)
+#define F_INT_TLB_MISS_FAULT   BIT(4)
+#define F_INT_MISS_TRANSATION_FIFO_FAULT   BIT(5)
+#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT   BIT(6)
+
+#define REG_MMU_CPE_DONE   0x12C
+
+#define REG_MMU_FAULT_ST1  0x134
+
+#define REG_MMU_FAULT_VA   0x13c
+#define F_MMU_FAULT_VA_MSK 0xf000
+#define F_MMU_FAULT_VA_WRITE_BIT   BIT(1)
+#define F_MMU_FAULT_VA_LAYER_BIT   BIT(0)
+
+#define REG_MMU_INVLD_PA   0x140
+#define REG_MMU_INT_ID 0x150
+#define F_MMU0_INT_ID_LARB_ID(a)   (((a) >> 7) & 0x7)
+#define F_MMU0_INT_ID_PORT_ID(a)

[PATCH v5 2/6] dt-bindings: mediatek: Add smi dts binding

[Yong Wu]

This patch add smi binding document.

Signed-off-by: Yong Wu 
---
 .../memory-controllers/mediatek,smi-larb.txt   | 25 ++
 .../bindings/memory-controllers/mediatek,smi.txt   | 24 +
 2 files changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/mediatek,smi.txt

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
new file mode 100644
index 000..55ff3b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -0,0 +1,25 @@
+SMI (Smart Multimedia Interface) Local Arbiter
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be "mediatek,mt8173-smi-larb"
+- reg : the register and size of this local arbiter.
+- mediatek,smi : a phandle to the smi_common node.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names: must contain 2 entries, as follows:
+  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
+   the register.
+  - "smi" : It's the clock for transfer data and command.
+
+Example:
+   larb1: larb@1601 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x1601 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+   clocks = <&vdecsys CLK_VDEC_CKEN>,
+<&vdecsys CLK_VDEC_LARB_CKEN>;
+   clock-names = "apb", "smi";
+   };
diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi.txt 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi.txt
new file mode 100644
index 000..f54e91c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi.txt
@@ -0,0 +1,24 @@
+SMI (Smart Multimedia Interface)
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be "mediatek,mt8173-smi"
+- reg : the register and size of the SMI block.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : must contain 2 entries, as follows:
+  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
+   the register.
+  - "smi" : It's the clock for transfer data and command.
+  They may be the same if both source clock are the same.
+
+Example:
+   smi_common: smi@14022000 {
+   compatible = "mediatek,mt8173-smi";
+   reg = <0 0x14022000 0 0x1000>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+   clocks = <&mmsys CLK_MM_SMI_COMMON>,
+<&mmsys CLK_MM_SMI_COMMON>;
+   clock-names = "apb", "smi";
+   };
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "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/6] iommu: add ARM short descriptor page table allocator

[Yong Wu]

This patch is for ARM Short Descriptor Format.

Signed-off-by: Yong Wu 
---
 drivers/iommu/Kconfig|  18 +
 drivers/iommu/Makefile   |   1 +
 drivers/iommu/io-pgtable-arm-short.c | 827 +++
 drivers/iommu/io-pgtable-arm.c   |   3 -
 drivers/iommu/io-pgtable.c   |   3 +
 drivers/iommu/io-pgtable.h   |  18 +-
 6 files changed, 866 insertions(+), 4 deletions(-)
 create mode 100644 drivers/iommu/io-pgtable-arm-short.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 4664c2a..a7920fb 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -40,6 +40,24 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
 
  If unsure, say N here.
 
+config IOMMU_IO_PGTABLE_SHORT
+   bool "ARMv7/v8 Short Descriptor Format"
+   select IOMMU_IO_PGTABLE
+   depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST)
+   help
+ Enable support for the ARM Short-descriptor pagetable format.
+ This allocator supports 2 levels of translation tables, which
+ enables a 32-bit memory map based on memory sections or pages.
+
+config IOMMU_IO_PGTABLE_SHORT_SELFTEST
+   bool "Short Descriptor selftests"
+   depends on IOMMU_IO_PGTABLE_SHORT
+   help
+ Enable self-tests for Short-descriptor page table allocator.
+ This performs a series of page-table consistency checks during boot.
+
+ If unsure, say N here.
+
 endmenu
 
 config IOMMU_IOVA
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index c6dcc51..06df3e6 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
 obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
+obj-$(CONFIG_IOMMU_IO_PGTABLE_SHORT) += io-pgtable-arm-short.o
 obj-$(CONFIG_IOMMU_IOVA) += iova.o
 obj-$(CONFIG_OF_IOMMU) += of_iommu.o
 obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o msm_iommu_dev.o
diff --git a/drivers/iommu/io-pgtable-arm-short.c 
b/drivers/iommu/io-pgtable-arm-short.c
new file mode 100644
index 000..6337c61
--- /dev/null
+++ b/drivers/iommu/io-pgtable-arm-short.c
@@ -0,0 +1,827 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "io-pgtable.h"
+
+typedef u32 arm_short_iopte;
+
+struct arm_short_io_pgtable {
+   struct io_pgtable   iop;
+   struct kmem_cache   *pgtable_cached;
+   size_t  pgd_size;
+   void*pgd;
+};
+
+#define io_pgtable_to_data(x)  \
+   container_of((x), struct arm_short_io_pgtable, iop)
+
+#define io_pgtable_ops_to_data(x)  \
+   io_pgtable_to_data(io_pgtable_ops_to_pgtable(x))
+
+#define io_pgtable_cfg_to_pgtable(x)   \
+   container_of((x), struct io_pgtable, cfg)
+
+#define io_pgtable_cfg_to_data(x)  \
+   io_pgtable_to_data(io_pgtable_cfg_to_pgtable(x))
+
+#define ARM_SHORT_PGDIR_SHIFT  20
+#define ARM_SHORT_PAGE_SHIFT   12
+#define ARM_SHORT_PTRS_PER_PTE \
+   (1 << (ARM_SHORT_PGDIR_SHIFT - ARM_SHORT_PAGE_SHIFT))
+#define ARM_SHORT_BYTES_PER_PTE\
+   (ARM_SHORT_PTRS_PER_PTE * sizeof(arm_short_iopte))
+
+/* level 1 pagetable */
+#define ARM_SHORT_PGD_TYPE_PGTABLE BIT(0)
+#define ARM_SHORT_PGD_TYPE_SECTION BIT(1)
+#define ARM_SHORT_PGD_BBIT(2)
+#define ARM_SHORT_PGD_CBIT(3)
+#define ARM_SHORT_PGD_PGTABLE_NS   BIT(3)
+#define ARM_SHORT_PGD_SECTION_XN   BIT(4)
+#define ARM_SHORT_PGD_IMPLEBIT(9)
+#define ARM_SHORT_PGD_RD_WR(3 << 10)
+#define ARM_SHORT_PGD_RDONLY   BIT(15)
+#define ARM_SHORT_PGD_SBIT(16)
+#define ARM_SHORT_PGD_nG   BIT(17)
+#define ARM_SHORT_PGD_SUPERSECTION BIT(18)
+#define ARM_SHORT_PGD_SECTION_NS   BIT(19)
+
+#define ARM_SHORT_PGD_TYPE_SUPERSECTION\
+   (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_SUPERSECTION)
+#define ARM_SHORT_PGD_SECTION_TYPE_MSK \
+   (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_SUPERSECTION)
+#define ARM_SHORT_PGD_PGTABLE_TYPE_MSK \
+   (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_TYPE_PGTABLE)
+#define ARM_SHORT_PGD_TYPE

[PATCH v5 1/6] dt-bindings: iommu: Add binding for mediatek IOMMU

[Yong Wu]

This patch add mediatek iommu dts binding document.

Signed-off-by: Yong Wu 
---
 .../devicetree/bindings/iommu/mediatek,iommu.txt   |  61 
 include/dt-bindings/memory/mt8173-larb-port.h  | 105 +
 2 files changed, 166 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
 create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h

diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt 
b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
new file mode 100644
index 000..d515e47
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -0,0 +1,61 @@
+* Mediatek IOMMU Architecture Implementation
+
+  Mediatek Socs may contain a implementation of Multimedia Memory
+Management Unit(M4U),which use ARM Short-descriptor translation table
+to achieve address translation.
+
+  The IOMMU Hardware Block Diagram, please check below:
+
+  EMI (External Memory Interface)
+   |
+  m4u (Multimedia Memory Management Unit)
+   |
+  smi (Smart Multimedia Interface)
+   |
++---+---
+|   |
+|   |
+vdec larb   disp larb  ... SoCs have different local arbiter(larb).
+|   |
+|   |
+   ++++-+-+
+   |||| | |...
+   |||| | |...
+   |||| | |...
+  MC   PP   VLD  OVL0 RDMA0 WDMA0  ... There are different ports in each larb.
+
+  As above, The Multimedia HW will go through SMI and M4U while it
+access EMI. SMI is a brige between m4u and the Multimedia HW. It contain
+smi local arbiter and smi common. It will control whether the Multimedia
+HW should go though the m4u for translation or bypass it and talk
+directly with EMI. And also SMI help control the clocks for each
+local arbiter.
+  Normally we specify a local arbiter(larb) for each multimedia HW
+like display, video decode, and camera. And there are different ports
+in each larb. Take a example, There are some ports like MC, PP, VLD in the
+video decode local arbiter, all the ports are according to the video HW.
+
+Required properties:
+- compatible : must be "mediatek,mt8173-m4u".
+- reg : m4u register base and size.
+- interrupts : the interrupt of m4u.
+- clocks : must contain one entry for each clock-names.
+- clock-names : must be "bclk", It is the block clock of m4u.
+- mediatek,larb : List of phandle to the local arbiters in the current Socs.
+   Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
+   according to the local arbiter index, like larb0, larb1, larb2...
+- iommu-cells : must be 2. There are 2 cells needed to enable/disable iommu.
+   The first one is local arbiter index(larbid), and the other is port
+   index(portid) within local arbiter. Specifies the larbid and portid as
+   defined in dt-binding/memory/mt8173-larb-port.h.
+
+Example:
+   iommu: iommu@10205000 {
+   compatible = "mediatek,mt8173-m4u";
+   reg = <0 0x10205000 0 0x1000>;
+   interrupts = ;
+   clocks = <&infracfg CLK_INFRA_M4U>;
+   clock-names = "bclk";
+   mediatek,larb = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
+   #iommu-cells = <2>;
+   };
diff --git a/include/dt-bindings/memory/mt8173-larb-port.h 
b/include/dt-bindings/memory/mt8173-larb-port.h
new file mode 100644
index 000..8e5b716
--- /dev/null
+++ b/include/dt-bindings/memory/mt8173-larb-port.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __DTS_IOMMU_PORT_MT8173_H
+#define __DTS_IOMMU_PORT_MT8173_H
+
+#define M4U_LARB0_ID   0
+#define M4U_LARB1_ID   1
+#define M4U_LARB2_ID   2
+#define M4U_LARB3_ID   3
+#define M4U_LARB4_ID   4
+#define M4U_LARB5_ID   5
+
+/* larb0 */
+#define M4U_PORT_DISP_OVL0 0
+#define M4U_PORT_DISP_RDMA01
+#define M4U_PORT_DISP_WDMA02
+#define M4U_PORT_DISP_OD_R 3
+#define M4U_PORT_DISP_OD_W 4
+#define M4U_PORT_MDP_RDMA0 5
+#define M4U_PORT_MDP_WDMA  6
+#define M4U_PORT_MDP_WROT0 7
+
+/* larb1 */
+#define M4U_PORT_HW_VDEC_MC_EXT0
+#define M4U_PORT_HW_VDEC_PP_EXT  

[PATCH v5 4/6] memory: mediatek: Add SMI driver

[Yong Wu]

This patch add SMI(Smart Multimedia Interface) driver. This driver
is responsible to enable/disable iommu and control the clocks of each
local arbiter

Signed-off-by: Yong Wu 
---
 drivers/memory/Kconfig |   8 ++
 drivers/memory/Makefile|   1 +
 drivers/memory/mtk-smi.c   | 274 +
 include/soc/mediatek/smi.h |  60 ++
 4 files changed, 343 insertions(+)
 create mode 100644 drivers/memory/mtk-smi.c
 create mode 100644 include/soc/mediatek/smi.h

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index c6a644b..6eab27c 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -108,6 +108,14 @@ config JZ4780_NEMC
  the Ingenic JZ4780. This controller is used to handle external
  memory devices such as NAND and SRAM.
 
+config MTK_SMI
+   bool
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   help
+ This driver is for the Memory Controller module in MediaTek SoCs,
+ mainly help enable/disable iommu and control the clock for each
+ local arbiter.
+
 source "drivers/memory/tegra/Kconfig"
 
 endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 1c46af5..890bdf4 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -15,5 +15,6 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
 obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
 obj-$(CONFIG_JZ4780_NEMC)  += jz4780-nemc.o
+obj-$(CONFIG_MTK_SMI)  += mtk-smi.o
 
 obj-$(CONFIG_TEGRA_MC) += tegra/
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
new file mode 100644
index 000..2d9d61b
--- /dev/null
+++ b/drivers/memory/mtk-smi.c
@@ -0,0 +1,274 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SMI_LARB_MMU_EN0xf00
+#define F_SMI_MMU_EN(port) BIT(port)
+
+struct mtk_smi_data {
+   struct clk  *clk_apb;
+   struct clk  *clk_smi;
+};
+
+struct mtk_larb_data { /* larb: local arbiter */
+   void __iomem*base;
+   struct clk  *clk_apb;
+   struct clk  *clk_smi;
+   struct device   *smidev;
+};
+
+struct mtk_larb_mmu {
+   u32 mmu;
+};
+
+static int __mtk_smi_get(struct device *dev, struct clk *apb, struct clk *smi)
+{
+   int ret;
+
+   ret = pm_runtime_get_sync(dev);
+   if (ret < 0)
+   return ret;
+
+   ret = clk_prepare_enable(apb);
+   if (ret) {
+   dev_err(dev, "Failed to enable the apb clock\n");
+   goto err_put_pm;
+   }
+   ret = clk_prepare_enable(smi);
+   if (ret) {
+   dev_err(dev, "Failed to enable the smi clock\n");
+   goto err_disable_apb;
+   }
+   return 0;
+
+err_disable_apb:
+   clk_disable_unprepare(apb);
+err_put_pm:
+   pm_runtime_put(dev);
+   return ret;
+}
+
+static void __mtk_smi_put(struct device *dev, struct clk *apb, struct clk *smi)
+{
+   clk_disable_unprepare(smi);
+   clk_disable_unprepare(apb);
+   pm_runtime_put(dev);
+}
+
+int mtk_smi_larb_get(struct device *larbdev)
+{
+   struct mtk_larb_data *larbdata = dev_get_drvdata(larbdev);
+   struct mtk_smi_data *smidata = dev_get_drvdata(larbdata->smidev);
+   struct mtk_larb_mmu *mmucfg = larbdev->platform_data;
+   int ret;
+
+   /* Enable smidev's power and clockes firstly, then enable the larb's. */
+   ret = __mtk_smi_get(larbdata->smidev, smidata->clk_apb,
+   smidata->clk_smi);
+   if (ret)
+   return ret;
+
+   ret = __mtk_smi_get(larbdev, larbdata->clk_apb, larbdata->clk_smi);
+   if (ret)
+   goto err_put_smi;
+
+   /* config iommu */
+   writel_relaxed(mmucfg->mmu, larbdata->base + SMI_LARB_MMU_EN);
+
+   return ret;
+
+err_put_smi:
+   __mtk_smi_put(larbdata->smidev, smidata->clk_apb, smidata->clk_smi);
+   return ret;
+}
+
+void mtk_smi_larb_put(struct device *larbdev)
+{
+   struct mtk_larb_data *larbdata = dev_get_drvdata(larbdev);
+   struct mtk_smi_data *smidata = dev_get_drvdata(larbdata->smidev);
+
+   __mtk_smi_put(larbdev, larbdata->clk_apb, larbdata->clk_smi);
+   __mtk_smi_put(larbdata->smidev, smidata->clk_apb, smidata->clk_smi);
+}
+
+int mtk_smi_config_port(

[PATCH v5 6/6] dts: mt8173: Add iommu/smi nodes for mt8173

[Yong Wu]

This patch add the iommu/larbs nodes for mt8173

Signed-off-by: Yong Wu 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81 
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 42540b2..524d305 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "mt8173-pinfunc.h"
@@ -265,6 +266,17 @@
reg = <0 0x10200620 0 0x20>;
};
 
+   iommu: iommu@10205000 {
+   compatible = "mediatek,mt8173-m4u";
+   reg = <0 0x10205000 0 0x1000>;
+   interrupts = ;
+   clocks = <&infracfg CLK_INFRA_M4U>;
+   clock-names = "bclk";
+   mediatek,larb = <&larb0 &larb1 &larb2
+&larb3 &larb4 &larb5>;
+   #iommu-cells = <2>;
+   };
+
apmixedsys: clock-controller@10209000 {
compatible = "mediatek,mt8173-apmixedsys";
reg = <0 0x10209000 0 0x1000>;
@@ -514,29 +526,98 @@
#clock-cells = <1>;
};
 
+   larb0: larb@14021000 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x14021000 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+   clocks = <&mmsys CLK_MM_SMI_LARB0>,
+<&mmsys CLK_MM_SMI_LARB0>;
+   clock-names = "apb", "smi";
+   };
+
+   smi_common: smi@14022000 {
+   compatible = "mediatek,mt8173-smi";
+   reg = <0 0x14022000 0 0x1000>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+   clocks = <&mmsys CLK_MM_SMI_COMMON>,
+<&mmsys CLK_MM_SMI_COMMON>;
+   clock-names = "apb", "smi";
+   };
+
+   larb4: larb@14027000 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x14027000 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+   clocks = <&mmsys CLK_MM_SMI_LARB4>,
+<&mmsys CLK_MM_SMI_LARB4>;
+   clock-names = "apb", "smi";
+   };
+
imgsys: clock-controller@1500 {
compatible = "mediatek,mt8173-imgsys", "syscon";
reg = <0 0x1500 0 0x1000>;
#clock-cells = <1>;
};
 
+   larb2: larb@15001000 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x15001000 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_ISP>;
+   clocks = <&imgsys CLK_IMG_LARB2_SMI>,
+<&imgsys CLK_IMG_LARB2_SMI>;
+   clock-names = "apb", "smi";
+   };
+
vdecsys: clock-controller@1600 {
compatible = "mediatek,mt8173-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
#clock-cells = <1>;
};
 
+   larb1: larb@1601 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x1601 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+   clocks = <&vdecsys CLK_VDEC_CKEN>,
+<&vdecsys CLK_VDEC_LARB_CKEN>;
+   clock-names = "apb", "smi";
+   };
+
vencsys: clock-controller@1800 {
compatible = "mediatek,mt8173-vencsys", "syscon";
reg = <0 0x1800 0 0x1000>;
#clock-cells = <1>;
};
 
+   larb3: larb@18001000 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x18001000 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_VENC>;
+   clocks = <&vencsys CLK_VENC_CKE1>,
+<&vencsys CLK_VENC_CKE0>;
+   clock-names = "apb", "smi";
+   };
+
vencltsys: clock-controller@1

[PATCH v5 0/6] MT8173 IOMMU SUPPORT

[Yong Wu]

  This patch set adds support for m4u(Multimedia Memory Management Unit),
Currently it only support the m4u with 2 levels of pagetable on mt8173.

  It's based on Robin Murphy's latest ARM64 DMA-v6[1]. The dsti is based
on MTK clock patch[2].
 
  Please check the hardware block diagram of Mediatek IOMMU.
 
  EMI (External Memory Interface)
   |
  m4u (Multimedia Memory Management Unit)
   |
  smi (Smart Multimedia Interface)
   |
+---+---
|   |
|   |
vdec larb   disp larb  ... SoCs have different local arbiter(larb).
|   |
|   |
   ++++-+-+
   |||| | |...
   |||| | |...
   |||| | |...
  MC   PP   VLD  OVL0 RDMA0 WDMA0  ... There are different ports in each larb.
  
  Normally we specify a local arbiter(larb) for each multimedia hardware like
display, video decode, video encode and camera. And there are different ports in
each larb. Take a example, there are some ports like MC, PP, UFO, VLD, AVC_MV,
PRED_RD in video larb, all the ports are according to the video hardware.
 
  From the diagram, all the multimedia module connect with m4u via smi.
SMI is responsible to enable/disable iommu and control the clocks for each local
arbiter. If we would like to enable the iommu of video decode, the video decode
HW ports have to be configed. And if the video hardware work whether
enable/disable iommu, it need enable the clock of its larb's clock. And smi also
help bandwidth control for each local. So we add a special driver for smi and
locate it drivers/memory.

v5:
-rebase onto v4.3-rc1.
-About MTK iommu: don't return the same domain while domain_alloc, change the
 domain's flow according to the M4U HW.
-About Short-descriptor: Improve many error-handles, NO_PERMS quirk, and 
 add TLBI_MAP quirk following Will's Suggestion; Add io-pgtable don't use 
 dma_to_phys; Add a loop in arm_short_unmap since iommu_unmap don't care the 
 physical address align.
-About SMI driver: Add a help funcion for some similar code. Add PROPRE_DEFER
 for power-domain as MTK SCPSYS is module_init currently.

v4: http://lists.linuxfoundation.org/pipermail/iommu/2015-August/013903.html
-use only one iommu domain here based on the Robin's DMA-v5:
 http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013900.html
-remove flush_pgtable.
-change writel to writel_relaxed.
-about Short-descriptor: move dma_map_single into io-pgtable-arm-short.
 Improve the flow of free pgtable and add NO_XN+NO_PERMS quirk following
 Will's suggestion.
-Change two sytle issues in dtsi according to Daniel's suggestion.

v3: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013632.html
-rebased onto v4.2-rc1
-improve iommu flow based on the Robin's DMA v3:
 http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013597.html
-change mtk iommu-cells from 1 to 2.
-about Short-descriptor: add split function; add self-test; add some other bits 
like nG,
 XN according to the spec; add SUPERSECTION and MTK quirk; move 
io_pgtable_ops_to_pgtable
 out from LPAE to the header file.
-about SMI: move from driver/soc/mediatek to driver/memory; change the clocks 
from
 clk[2] to clk_apb and clk_smi; add pm.
-add iommu suspend/resume to backup/restore register.

v2: http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013028.html
-add arm short descriptor support.
-seperate smi common from smi and change the clock-names according
 to smi HW.
-delete the hardcode of the port-names in mt8173.
 replace this with larb-portes-nr in dtsi.
-fix some coding style issues.

v1: http://lists.infradead.org/pipermail/linux-mediatek/2015-March/58.html
-initial version.

[1]: http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014504.html
[2]: http://lists.infradead.org/pipermail/linux-mediatek/2015-August/001962.html

Yong Wu (6):
  dt-bindings: iommu: Add binding for mediatek IOMMU
  dt-bindings: mediatek: Add smi dts binding
  iommu: add ARM short descriptor page table allocator
  memory: mediatek: Add SMI driver
  iommu/mediatek: Add mt8173 IOMMU driver
  dts: mt8173: Add iommu/smi nodes for mt8173

 .../devicetree/bindings/iommu/mediatek,iommu.txt   |  61 ++
 .../memory-controllers/mediatek,smi-larb.txt   |  25 +
 .../bindings/memory-controllers/mediatek,smi.txt   |  24 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  81 ++
 drivers/iommu/Kconfig  |  33 +
 drivers/iommu/Makefile |   2 +
 drivers/iommu/io-pgtable-arm-short.c   | 827 +
 drivers/iommu/io-pgtable-arm.c |   3 -
 drivers/iommu/io-pgtable.c |   3 +
 drivers/iommu/io-pgtable.h |  18 +-
 drivers/iommu/mtk_iommu.c  | 767 +++

Re: [PATCH] ARM: shmobile: porter: add I2C2 DT support

[Simon Horman]

On Fri, Oct 09, 2015 at 12:44:18AM +0300, Sergei Shtylyov wrote:
> Define the Porter board dependent part of the I2C2 device node.
> 
> This patch is  analogous to the commit 29a647c396a0 ("ARM: shmobile:
> henninger: add I2C2 DT support") as there are no differences between
> the boards in this respect.
> 
> Signed-off-by: Sergei Shtylyov 

Thanks Sergei,

I have queued this up for v4.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] ARM: shmobile: porter: add VIN0/ADV7180 DT support

[Simon Horman]

On Fri, Oct 09, 2015 at 12:45:49AM +0300, Sergei Shtylyov wrote:
> Define the  Porter board dependent part of the VIN0 device node.
> Add the device node for Analog Devices  ADV7180 video decoder to I2C2 bus.
> Add the necessary subnodes to interconnect VIN0 and ADV7180 devices.
> 
> This patch is  analogous to the commit 8d62f4f75320 ("ARM: shmobile:
> henninger: add VIN0/ADV7180 DT support") as there are no differences
> between the boards in this respect.
> 
> Signed-off-by: Sergei Shtylyov 

Thanks Sergei,

I have queued this one up for v4.4 too.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] drm: panel: simple: add QiaoDian qd43003c0-40

[Rob Herring]

On Thu, Oct 8, 2015 at 10:42 AM, Alexandre Belloni
 wrote:
> From: Josh Wu 
>
> The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.
>
> Timings from the OTA5180A document, ver 0.9, section
> 10.1.1:
>   http://www.orientdisplay.com/pdf/OTA5180A.pdf
>
> Signed-off-by: Josh Wu 
> Signed-off-by: Alexandre Belloni 
> ---
>  .../bindings/panel/qiaodian,qd43003c0-40.txt   |  7 ++

Acked-by: Rob Herring 

BTW, I'm moving bindings/panel/ to bindings/display/panel/ for 4.4.
It's fine to leave this, but if you do respin for some reason, can you
move this there.

Rob

>  drivers/gpu/drm/panel/panel-simple.c   | 27 
> ++
>  2 files changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt 
> b/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
> new file mode 100644
> index ..0fbdab89ac3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
> @@ -0,0 +1,7 @@
> +QiaoDian XianShi Corporation 4"3 TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "qiaodian,qd43003c0-40"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index f97b73ec4713..c93ffa615005 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1027,6 +1027,30 @@ static const struct panel_desc ortustech_com43h4m85ulc 
> = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
>  };
>
> +static const struct drm_display_mode qd43003c0_40_mode = {
> +   .clock = 9000,
> +   .hdisplay = 480,
> +   .hsync_start = 480 + 8,
> +   .hsync_end = 480 + 8 + 4,
> +   .htotal = 480 + 8 + 4 + 39,
> +   .vdisplay = 272,
> +   .vsync_start = 272 + 4,
> +   .vsync_end = 272 + 4 + 10,
> +   .vtotal = 272 + 4 + 10 + 2,
> +   .vrefresh = 60,
> +};
> +
> +static const struct panel_desc qd43003c0_40 = {
> +   .modes = &qd43003c0_40_mode,
> +   .num_modes = 1,
> +   .bpc = 8,
> +   .size = {
> +   .width = 95,
> +   .height = 53,
> +   },
> +   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
>  static const struct drm_display_mode samsung_ltn101nt05_mode = {
> .clock = 54030,
> .hdisplay = 1024,
> @@ -1182,6 +1206,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "ortustech,com43h4m85ulc",
> .data = &ortustech_com43h4m85ulc,
> }, {
> +   .compatible = "qiaodian,qd43003c0-40",
> +   .data = &qd43003c0_40,
> +   }, {
> .compatible = "samsung,ltn101nt05",
> .data = &samsung_ltn101nt05,
> }, {
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] video: fbdev: add Marvell PXA framebuffer binding

[Rob Herring]

On Thu, Oct 8, 2015 at 2:15 PM, Robert Jarzmik  wrote:
> Rob Herring  writes:

>>> And then, when a board maintainer will create a devicetree description, he 
>>> will
>>> write something like :
>>>   compatible = "toshiba,ltm0305a776";
>>>   compatible = "marvell,pxa2xx-panel";
>>
>> Drop this compatible.
>>
>>>   lcd-type = "color-tft";
>>>   ...
>>>
>>> If that's the case, I wonder how to "enforce" that a panel used with
>>> marvell,pxa2xx-lcdc (through the of_graph 'port' node) be compatible with
>>> marvell,pxa2xx-panel ?
>>
>> I'm not sure what you mean. Putting the panel into the dts ensures
>> that. The FB driver may check for toshiba,ltm0305a776 or a list of
>> panels. However, a DRM driver would probably not check that.
>>
>> Rob
> What I mean is that the LDLC controller _must_ be programmmed with the correct
> panel type, ie. one register of the LDLC should be set according to this type.
>
> The type is a hardware property of the panel, and yet it is absolutely 
> mandatory
> to have it set in the panel.
>
> What I mean is : what is the good way to enforce that this property is set
> somewhere in the devicetree description ? Philipp adviced for it to be 
> transfered
> to the ldlc description (ie. marvell,pxa2xx-ldlc), while I was thinking of
> having it in a panel description.

Either of those options are fine. Neither should need
marvell,pxa2xx-panel though. I'd lean towards putting it in the panel,
but in that case it should be generic for panels which I think it is.
It should probably be optional with not present meaning color-tft
(since every other type is practically dead), but you could say
required on pxa2xx.

The only way to enforce it ATM, is panicking or something if the LCDC
finds it is not set. That's not any worse that checking for
marvell,pxa2xx-panel.

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] QEMU fw_cfg DMA interface documentation

[Laszlo Ersek]

On 10/08/15 17:03, Marc Marí wrote:
> Add fw_cfg DMA interface specfication in the fw_cfg documentation.
> 
> Signed-off-by: Marc Marí 
> ---
>  Documentation/devicetree/bindings/arm/fw-cfg.txt | 52 
> +++-
>  1 file changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt 
> b/Documentation/devicetree/bindings/arm/fw-cfg.txt
> index 953fb64..0633aad 100644
> --- a/Documentation/devicetree/bindings/arm/fw-cfg.txt
> +++ b/Documentation/devicetree/bindings/arm/fw-cfg.txt
> @@ -38,6 +38,9 @@ The presence of the registers can be verified by selecting 
> the "signature" blob
>  with key 0x, and reading four bytes from the data register. The returned
>  signature is "QEMU".
>  
> +If the DMA interface is available, then reading the DMA Address Register
> +returns 0x51454d5520434647 ("QEMU CFG" in big-endian format).
> +

marking this for a later argument: (*)

>  The outermost protocol (involving the write / read sequences of the control 
> and
>  data registers) is expected to be versioned, and/or described by feature 
> bits.
>  The interface revision / feature bitmap can be retrieved with key 0x0001. The
> @@ -45,6 +48,51 @@ blob to be read from the data register has size 4, and it 
> is to be interpreted
>  as a uint32_t value in little endian byte order. The current value
>  (corresponding to the above outer protocol) is zero.
>  
> +If bit 1 of the feature bitmap is set, the DMA interface is present. This
> +can be used through the 64-bit wide address register.
> +
> +The address register is in big-endian format. The value for the register is 0
> +at startup and after an operation. A write to the lower half triggers an
> +operation. This means, that operations with 32-bit addresses can be triggered
> +with just one write, whereas operations with 64-bit addresses can be 
> triggered
> +with one 64-bit write or two 32-bit writes, starting with the higher part.

Please sync this language with the "least significant half" / "most
significant half" wording that I requested after your QEMU

  [PATCH v4 2/7] fw_cfg DMA interface documentation

and that you implemented in your present QEMU

  [PATCH v5 2/6] fw_cfg DMA interface documentation

> +
> +In this register, the physical address of a FWCfgDmaAccess structure in RAM
> +should be written. This is the format of the FWCfgDmaAccess structure:
> +
> +typedef struct FWCfgDmaAccess {
> +uint32_t control;
> +uint32_t length;
> +uint64_t address;
> +} FWCfgDmaAccess;
> +
> +The fields of the structure are in big endian mode, and the field at the 
> lowest
> +address is the "control" field.
> +
> +The "control" field has the following bits:
> + - Bit 0: Error
> + - Bit 1: Read
> + - Bit 2: Skip
> + - Bit 3: Select. The upper 16 bits are the selected index.
> +
> +When an operation is triggered, if the "control" field has bit 3 set, the
> +upper 16 bits are interpreted as an index of a firmware configuration item.
> +This has the same effect as writing the selector register.
> +
> +If the "control" field has bit 1 set, a read operation will be performed.
> +"length" bytes for the current selector and offset will be copied into the
> +physical RAM address specified by the "address" field.
> +
> +If the "control" field has bit 2 set (and not bit 1), a skip operation will 
> be
> +performed. The offset for the current selector will be advanced "length" 
> bytes.
> +
> +To check the result, read the "control" field:
> +   error bit set->  something went wrong.
> +   all bits cleared ->  transfer finished successfully.
> +   otherwise->  transfer still in progress (doesn't happen
> +today due to implementation not being async,
> +but may in the future).
> +
>  The guest kernel is not expected to use these registers (although it is
>  certainly allowed to); the device tree bindings are documented here because
>  this is where device tree bindings reside in general.

I guess this is all coming verbatim from the QEMU spec. I think that's
okay, it doesn't speak about selector values etc, only about transport.
I think it's okay (and consistent with the current text) to have all the
details here.

> @@ -56,6 +104,8 @@ Required properties:
>  - reg: the MMIO region used by the device.
>* Bytes 0x0 to 0x7 cover the data register.
>* Bytes 0x8 to 0x9 cover the selector register.
> +  * With DMA interface enabled: Bytes 0x10 to 0x17 cover the DMA address
> +register.
>* Further registers may be appended to the region in case of future 
> interface
>  revisions / feature bits.
>  
> @@ -66,7 +116,7 @@ Example:
>   #address-cells = <0x2>;
>  
>   fw-cfg@902 {
> + reg = <0x0 0x902 0x0 0x18>;
>   compatible = "qemu,fw-cfg-mmio";
> - reg = <0x0 0x902 0x0 0xa>;
>   };
>  };
> 

Please make this a bit more precise. As already mentioned by Peter (

[PATCH 1/3] doc: dt: fpga: Added Documentation for Xilinx Zynq FPGA manager.

[Moritz Fischer]

Signed-off-by: Moritz Fischer 
---
 .../bindings/fpga/xilinx-zynq-fpga-mgr.txt | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt

diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt 
b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt
new file mode 100644
index 000..82ffda8
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt
@@ -0,0 +1,26 @@
+Xilinx Zynq FPGA Manager
+
+Required properties:
+- compatible:  should contain "xlnx,zynq-devcfg-1.0"
+- reg: base address and size for memory mapped io
+- interrupt parent:interrupt source phandle
+- interrupts:  interrupt for the FPGA manager device
+- clocks:  phandle for clocks required operation
+- syscon:  phandle for access to SLCR registers
+
+Optional properties:
+- clock-names: names for clocks
+
+
+
+Example:
+   devcfg: devcfg@f8007000 {
+   compatible = "xlnx,zynq-devcfg-1.0";
+   reg = <0xf8007000 0x100>;
+   interrupt-parent = <&intc>;
+   interrupts = <0 8 4>;
+   clocks = <&clkc 12>;
+   clock-names = "ref_clk";
+   syscon = <&slcr>;
+   };
+
-- 
2.6.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 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000

[Moritz Fischer]

This commit adds FPGA Manager support for the Xilinx Zynq chip.
The code heavily borrows from the xdevcfg driver in Xilinx'
vendor tree.

Signed-off-by: Moritz Fischer 
---
 drivers/fpga/Kconfig |   5 +
 drivers/fpga/Makefile|   1 +
 drivers/fpga/zynq-fpga.c | 478 +++
 3 files changed, 484 insertions(+)
 create mode 100644 drivers/fpga/zynq-fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index dfc1f1e..c9b9fdf 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -19,6 +19,11 @@ config FPGA_MGR_SOCFPGA
help
  FPGA manager driver support for Altera SOCFPGA.
 
+config FPGA_MGR_ZYNQ_FPGA
+   tristate "Xilinx Zynq FPGA"
+   help
+ FPGA manager driver support for Xilinx Zynq FPGAs.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index ba6c5c5..8d83fc6 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 
 # FPGA Manager Drivers
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
+obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
new file mode 100644
index 000..7d0d703
--- /dev/null
+++ b/drivers/fpga/zynq-fpga.c
@@ -0,0 +1,478 @@
+/*
+ * Copyright (c) 2011-2015 Xilinx Inc.
+ * Copyright (c) 2015, National Instruments Corp.
+ *
+ * FPGA Manager Driver for Xilinx Zynq, heavily based on xdevcfg driver
+ * in their vendor tree.
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Offsets into SLCR regmap */
+#define SLCR_FPGA_RST_CTRL_OFFSET  0x240 /* FPGA Software Reset Control */
+#define SLCR_LVL_SHFTR_EN_OFFSET   0x900 /* Level Shifters Enable */
+
+/* Constant Definitions */
+#define CTRL_OFFSET0x00 /* Control Register */
+#define LOCK_OFFSET0x04 /* Lock Register */
+#define INT_STS_OFFSET 0x0c /* Interrupt Status Register */
+#define INT_MASK_OFFSET0x10 /* Interrupt Mask Register */
+#define STATUS_OFFSET  0x14 /* Status Register */
+#define DMA_SRC_ADDR_OFFSET0x18 /* DMA Source Address Register */
+#define DMA_DEST_ADDR_OFFSET   0x1c /* DMA Destination Address Reg */
+#define DMA_SRC_LEN_OFFSET 0x20 /* DMA Source Transfer Length */
+#define DMA_DEST_LEN_OFFSET0x24 /* DMA Destination Transfer */
+#define UNLOCK_OFFSET  0x34 /* Unlock Register */
+#define MCTRL_OFFSET   0x80 /* Misc. Control Register */
+
+/* Control Register Bit definitions */
+#define CTRL_PCFG_PROG_B_MASK  BIT(30) /* Program signal to reset FPGA */
+#define CTRL_PCAP_PR_MASK  BIT(27) /* Enable PCAP for PR */
+#define CTRL_PCAP_MODE_MASKBIT(26) /* Enable PCAP */
+
+/* Miscellaneous Control Register bit definitions */
+#define MCTRL_PCAP_LPBK_MASK   BIT(4) /* Internal PCAP loopback */
+
+/* Status register bit definitions */
+#define STATUS_PCFG_INIT_MASK  BIT(4) /* FPGA init status */
+
+/* Interrupt Status/Mask Register Bit definitions */
+#define IXR_DMA_DONE_MASK  BIT(13) /* DMA command done */
+#define IXR_D_P_DONE_MASK  BIT(12) /* DMA and PCAP cmd done */
+#define IXR_PCFG_DONE_MASK BIT(2)  /* FPGA programmed */
+#define IXR_ERROR_FLAGS_MASK   0x00F0F860
+#define IXR_ALL_MASK   0xF8F7F87F
+
+/* Miscellaneous constant values */
+#define DMA_INVALID_ADDRESSGENMASK(31, 0)  /* Invalid DMA address */
+#define UNLOCK_MASK0x757bdf0d /* Used to unlock the device */
+
+/* Masks for controlling stuff in SLCR */
+#define LVL_SHFTR_DISABLE_ALL_MASK 0x0 /* Disable all Level shifters */
+#define LVL_SHFTR_ENABLE_PS_TO_PL  0xa /* Enable all Level shifters */
+#define LVL_SHFTR_ENABLE_PL_TO_PS  0xf /* Enable all Level shifters */
+#define FPGA_RST_ALL_MASK  0xf /* Enable global resets */
+#define FPGA_RST_NONE_MASK 0x0 /* Disable global resets */
+
+struct zynq_fpga_priv {
+   struct device *dev;
+   int irq;
+   struct clk *clk;
+
+   void __iomem *io_base;
+   struct regmap *slcr;
+
+   /* this protects the error flag */
+   spinlock_t lock;
+   bool error;
+
+   struct completion dma_done;
+};
+
+static inline void zynq_fpga_write(struct zynq_fpga_priv *priv, u32 offset,
+  u32 val)
+{
+   writel(val, priv->io_base + offset);
+}
+
+sta

[PATCH 2/3] dts: Updated devicetree bindings for Zynq 7000 platform

[Moritz Fischer]

Added addtional bindings required for FPGA Manager operation
of the Xilinx Zynq Devc configuration interface.

Signed-off-by: Moritz Fischer 
---
 arch/arm/boot/dts/zynq-7000.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index dc0457e..1a5220e 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -294,6 +294,11 @@
devcfg: devcfg@f8007000 {
compatible = "xlnx,zynq-devcfg-1.0";
reg = <0xf8007000 0x100>;
+   interrupt-parent = <&intc>;
+   interrupts = <0 8 4>;
+   clocks = <&clkc 12>;
+   clock-names = "ref_clk";
+   syscon = <&slcr>;
};
 
global_timer: timer@f8f00200 {
-- 
2.6.1

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

[PATCH 0/3] Adding Xilinx Zynq 7000 FPGA Manager driver

[Moritz Fischer]

Hi all,

this patchset adds support for the Xilinx Zynq 7000 FPGA Manager,
based on Alan's FPGA manager framework.

The patchset has lived for a while already in the Xilinx tree,
however, I don't know if anyone besides me tested it so far?

The version in their tree got ACKs by Michal and Soeren already,
but was based against an older version of Alan's patchset.

Michal, Soeren, could I get ACKs from you guys for this version?

Cheers,

Moritz

Moritz Fischer (3):
  doc: dt: fpga: Added Documentation for Xilinx Zynq FPGA manager.
  dts: Updated devicetree bindings for Zynq 7000 platform
  fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000

 .../bindings/fpga/xilinx-zynq-fpga-mgr.txt |  26 ++
 arch/arm/boot/dts/zynq-7000.dtsi   |   5 +
 drivers/fpga/Kconfig   |   5 +
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/zynq-fpga.c   | 478 +
 5 files changed, 515 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt
 create mode 100644 drivers/fpga/zynq-fpga.c

-- 
2.6.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 v5 3/4] PCI/MSI: Add helper function pci_msi_domain_get_msi_rid().

[David Daney]

From: David Daney 

Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
Initially needed by gic-v3 based systems. It will be used by follow on
patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c

Initially supports mapping the RID via OF device tree.  In the future,
this could be extended to use ACPI _IORT tables as well.

Reviewed-by: Marc Zyngier 
Signed-off-by: David Daney 
---
 drivers/pci/msi.c   | 30 ++
 include/linux/msi.h |  1 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d449714..81a2798 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pci.h"
 
@@ -1327,4 +1328,33 @@ struct irq_domain 
*pci_msi_create_default_irq_domain(struct device_node *node,
 
return domain;
 }
+
+static int get_msi_id_cb(struct pci_dev *pdev, u16 alias, void *data)
+{
+   u32 *pa = data;
+
+   *pa = alias;
+   return 0;
+}
+/**
+ * pci_msi_domain_get_msi_rid - Get the MSI requester id (RID)
+ * @domain:The interrupt domain
+ * @pdev:  The PCI device.
+ *
+ * The RID for a device is formed from the alias, with a firmware
+ * supplied mapping applied
+ *
+ * Returns: The RID.
+ */
+u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev *pdev)
+{
+   u32 rid = 0;
+
+   pci_for_each_dma_alias(pdev, get_msi_id_cb, &rid);
+
+   if (domain->of_node)
+   rid = of_msi_map_rid(&pdev->dev, domain->of_node, rid);
+
+   return rid;
+}
 #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ad939d0..56e3b76 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -293,6 +293,7 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct pci_dev 
*dev,
  struct msi_desc *desc);
 int pci_msi_domain_check_cap(struct irq_domain *domain,
 struct msi_domain_info *info, struct device *dev);
+u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev 
*pdev);
 #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
 
 #endif /* LINUX_MSI_H */
-- 
1.9.1

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

[PATCH v5 4/4] irqchip/gic-v3-its: Add handling of PCI requester id.

[David Daney]

From: David Daney 

Replace open coded generation PCI/MSI requester id with call to the
new function pci_msi_domain_get_msi_rid() which applies the "msi-map"
to the id value.

Reviewed-by: Marc Zyngier 
Signed-off-by: David Daney 
---
 drivers/irqchip/irq-gic-v3-its-pci-msi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index a7c8c9f..96f5f5f 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -42,7 +42,6 @@ static struct irq_chip its_msi_irq_chip = {
 
 struct its_pci_alias {
struct pci_dev  *pdev;
-   u32 dev_id;
u32 count;
 };
 
@@ -60,7 +59,6 @@ static int its_get_pci_alias(struct pci_dev *pdev, u16 alias, 
void *data)
 {
struct its_pci_alias *dev_alias = data;
 
-   dev_alias->dev_id = alias;
if (pdev != dev_alias->pdev)
dev_alias->count += its_pci_msi_vec_count(pdev);
 
@@ -86,7 +84,7 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
struct device *dev,
pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
 
/* ITS specific DeviceID, as the core ITS ignores dev. */
-   info->scratchpad[0].ul = dev_alias.dev_id;
+   info->scratchpad[0].ul = pci_msi_domain_get_msi_rid(domain, pdev);
 
return msi_info->ops->msi_prepare(domain->parent,
  dev, dev_alias.count, info);
-- 
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 v5 2/4] of/irq: Add new function of_msi_map_rid()

[David Daney]

From: David Daney 

The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controllers.  Add a new function
of_msi_map_rid() that finds the msi-map property and applies its
translation to a given requester id.

Reviewed-by: Marc Zyngier 
Acked-by: Rob Herring 
Signed-off-by: David Daney 
---
 drivers/of/irq.c   | 84 ++
 include/linux/of_irq.h |  7 +
 2 files changed, 91 insertions(+)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 55317fa..c90bd4e 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -598,3 +598,87 @@ void of_msi_configure(struct device *dev, struct 
device_node *np)
d = irq_find_host(msi_np);
dev_set_msi_domain(dev, d);
 }
+
+/**
+ * of_msi_map_rid - Map a MSI requester ID for a device.
+ * @dev: device for which the mapping is to be done.
+ * @msi_np: device node of the expected msi controller.
+ * @rid_in: unmapped MSI requester ID for the device.
+ *
+ * Walk up the device hierarchy looking for devices with a "msi-map"
+ * property.  If found, apply the mapping to @rid_in.
+ *
+ * Returns the mapped MSI requester ID.
+ */
+u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in)
+{
+   struct device *parent_dev;
+   struct device_node *msi_controller_node;
+   u32 map_mask, masked_rid, rid_base, msi_base, rid_len, phandle;
+   int msi_map_len;
+   bool matched;
+   u32 rid_out = rid_in;
+   const __be32 *msi_map = NULL;
+
+   /*
+* Walk up the device parent links looking for one with a
+* "msi-map" property.
+*/
+   for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
+   if (!parent_dev->of_node)
+   continue;
+
+   msi_map = of_get_property(parent_dev->of_node,
+ "msi-map", &msi_map_len);
+   if (!msi_map)
+   continue;
+
+   if (msi_map_len % (4 * sizeof(__be32))) {
+   dev_err(parent_dev, "Error: Bad msi-map length: %d\n",
+   msi_map_len);
+   return rid_out;
+   }
+   /* We have a good parent_dev and msi_map, let's use them. */
+   break;
+   }
+   if (!msi_map)
+   return rid_out;
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "msi-map-mask" property.  If
+* of_property_read_u32() fails, the default is used.
+*/
+   of_property_read_u32(parent_dev->of_node, "msi-map-mask", &map_mask);
+
+   masked_rid = map_mask & rid_in;
+   matched = false;
+   while (!matched && msi_map_len >= 4 * sizeof(__be32)) {
+   rid_base = be32_to_cpup(msi_map + 0);
+   phandle = be32_to_cpup(msi_map + 1);
+   msi_base = be32_to_cpup(msi_map + 2);
+   rid_len = be32_to_cpup(msi_map + 3);
+
+   msi_controller_node = of_find_node_by_phandle(phandle);
+
+   matched = masked_rid >= rid_base &&
+   masked_rid < rid_base + rid_len &&
+   msi_np == msi_controller_node;
+
+   of_node_put(msi_controller_node);
+   msi_map_len -= 4 * sizeof(__be32);
+   msi_map += 4;
+   }
+   if (!matched)
+   return rid_out;
+
+   rid_out = masked_rid + msi_base;
+   dev_dbg(dev,
+   "msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: 
%08x, length: %08x, rid: %08x -> %08x\n",
+   dev_name(parent_dev), map_mask, rid_base, msi_base,
+   rid_len, rid_in, rid_out);
+
+   return rid_out;
+}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 4bcbd58..8cd9334 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -75,6 +75,7 @@ static inline int of_irq_to_resource_table(struct device_node 
*dev,
 extern unsigned int irq_of_parse_and_map(struct device_node *node, int index);
 extern struct device_node *of_irq_find_parent(struct device_node *child);
 extern void of_msi_configure(struct device *dev, struct device_node *np);
+u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in);
 
 #else /* !CONFIG_OF */
 static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
@@ -87,6 +88,12 @@ static inline void *of_irq_find_parent(struct device_node 
*child)
 {
return NULL;
 }
+
+static inline u32 of_msi_map_rid(struct device *dev,
+struct device_node *msi_np, u32 rid_in)
+{
+   return rid_in;
+}
 #endif /* !CONFIG_OF */
 
 #endif /* __OF_IRQ_H */
-- 
1.9.1

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

[PATCH v5 1/4] Docs: dt: Add PCI MSI map bindings

[David Daney]

From: Mark Rutland 

Currently msi-parent is used by a few bindings to describe the
relationship between a PCI root complex and a single MSI controller, but
this property does not have a generic binding document.

Additionally, msi-parent is insufficient to describe more complex
relationships between MSI controllers and devices under a root complex,
where devices may be able to target multiple MSI controllers, or where
MSI controllers use (non-probeable) sideband information to distinguish
devices.

This patch adds a generic binding for mapping PCI devices to MSI
controllers. This document covers msi-parent, and a new msi-map property
(specific to PCI*) which may be used to map devices (identified by their
Requester ID) to sideband data for each MSI controller that they may
target.

Acked-by: Marc Zyngier 
Signed-off-by: Mark Rutland 
Signed-off-by: David Daney 
---
 Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
 1 file changed, 220 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt

diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt 
b/Documentation/devicetree/bindings/pci/pci-msi.txt
new file mode 100644
index 000..9b3cc81
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
@@ -0,0 +1,220 @@
+This document describes the generic device tree binding for describing the
+relationship between PCI devices and MSI controllers.
+
+Each PCI device under a root complex is uniquely identified by its Requester ID
+(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
+Function number.
+
+For the purpose of this document, when treated as a numeric value, a RID is
+formatted such that:
+
+* Bits [15:8] are the Bus number.
+* Bits [7:3] are the Device number.
+* Bits [2:0] are the Function number.
+* Any other bits required for padding must be zero.
+
+MSIs may be distinguished in part through the use of sideband data accompanying
+writes. In the case of PCI devices, this sideband data may be derived from the
+Requester ID. A mechanism is required to associate a device with both the MSI
+controllers it can address, and the sideband data that will be associated with
+its writes to those controllers.
+
+For generic MSI bindings, see
+Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+
+PCI root complex
+
+
+Optional properties
+---
+
+- msi-map: Maps a Requester ID to an MSI controller and associated
+  msi-specifier data. The property is an arbitrary number of tuples of
+  (rid-base,msi-controller,msi-base,length), where:
+
+  * rid-base is a single cell describing the first RID matched by the entry.
+
+  * msi-controller is a single phandle to an MSI controller
+
+  * msi-base is an msi-specifier describing the msi-specifier produced for the
+first RID matched by the entry.
+
+  * length is a single cell describing how many consecutive RIDs are matched
+following the rid-base.
+
+  Any RID r in the interval [rid-base, rid-base + length) is associated with
+  the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
+
+- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
+  to an msi-specifier per the msi-map property.
+
+- msi-parent: Describes the MSI parent of the root complex itself. Where
+  the root complex and MSI controller do not pass sideband data with MSI
+  writes, this property may be used to describe the MSI controller(s)
+  used by PCI devices under the root complex, if defined as such in the
+  binding for the root complex.
+
+
+Example (1)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   msi: msi-controller@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-controller";
+   msi-controller;
+   #msi-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the MSI controller is
+* the RID, identity-mapped.
+*/
+   msi-map = <0x0 &msi_a 0x0 0x1>,
+   };
+};
+
+
+Example (2)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   msi: msi-controller@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-controller";
+   msi-controller;
+   #msi-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the MSI controller is
+* the RID, masked to only the device and function bits.
+*/
+   msi-map = <0x0 &msi_a 0x0 0x100>,
+   msi-map-mask = <0xff>
+

[PATCH v5 0/4] MSI, of, irqchip/gicv3-its: Handle "msi-map" properties.

[David Daney]

From: David Daney 

The first patch from Mark Rutland adds the OF device tree binding
description, which explains what we are attempting to do here.  For
MSI messages on GICv3 systems there is some side-band data that
accompanies the message, this data is specified in the OF device tree
"msi-map" property of the PCI host driver.

The second patch adds a parser to get the required information out of
the device tree.

The third patch creates the pci_msi_domain_get_msi_rid() function to
make it more convenient to generate the proper PCI/MSI requester id.

The final patch converts gicv3-its to use the new infrastructure.

Changes from v1: Factor out the device tree access code to a separate
function in drivers/of/irq.c

Changes from v2: Added the pci_msi_domain_get_msi_rid() patch to
generalize the support a bit more.

Changes from v3: Added Acked-by to 2/4.  Simplified and improved
pci_msi_domain_get_msi_rid() as suggested by Marc Zyngier in 3/4.  1/4
and 4/4 unchanged.

Changes from v4: Added Reviewed-by to 3/4 and 4/4

David Daney (3):
  of/irq: Add new function of_msi_map_rid()
  PCI/MSI:  Add helper function pci_msi_domain_get_msi_rid().
  irqchip/gic-v3-its:  Add handling of PCI requester id.

Mark Rutland (1):
  Docs: dt: Add PCI MSI map bindings

 Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
 drivers/irqchip/irq-gic-v3-its-pci-msi.c  |   4 +-
 drivers/of/irq.c  |  84 +
 drivers/pci/msi.c |  30 +++
 include/linux/msi.h   |   1 +
 include/linux/of_irq.h|   7 +
 6 files changed, 343 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt

-- 
1.9.1

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

Re: [PATCH] PCI: generic: Fix address window calculation for non-zero starting bus.

[Rob Herring]

On Thu, Oct 8, 2015 at 2:54 PM, David Daney  wrote:
> From: David Daney 
>
> Make the offset from the beginning of the "reg" property be from the
> starting bus number, rather than zero.  Hoist the invariant size
> calculation out of the mapping for loop.
>
> Update host-generic-pci.txt to clarify the semantics of the "reg"
> property with respect to non-zero starting bus numbers.
>
> Signed-off-by: David Daney 

Acked-by: Rob Herring 

> ---
> This is a replacement for:
>
> https://lkml.org/lkml/2015/10/2/653
>
> Since that patch is getting too much push-back, this is the only other
> option for fixing the driver to be internally consistent in its
> treatment of the offset from "reg" to the first bus in the "bus-range"
> property.
>
>  Documentation/devicetree/bindings/pci/host-generic-pci.txt | 5 +++--
>  drivers/pci/host/pci-host-generic.c| 4 ++--
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt 
> b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> index cf3e205..3f1d3fc 100644
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> @@ -34,8 +34,9 @@ Properties of the host controller node:
>  - #size-cells: Must be 2.
>
>  - reg: The Configuration Space base address and size, as accessed
> -   from the parent bus.
> -
> +   from the parent bus.  The base address corresponds to
> +   the first bus in the "bus-range" property.  If no
> +   "bus-range" is specified, this will be bus 0 (the 
> default).
>
>  Properties of the /chosen node:
>
> diff --git a/drivers/pci/host/pci-host-generic.c 
> b/drivers/pci/host/pci-host-generic.c
> index fe9a81b..bb93346 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -169,6 +169,7 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci 
> *pci)
> struct resource *bus_range;
> struct device *dev = pci->host.dev.parent;
> struct device_node *np = dev->of_node;
> +   u32 sz = 1 << pci->cfg.ops->bus_shift;
>
> err = of_address_to_resource(np, 0, &pci->cfg.res);
> if (err) {
> @@ -196,10 +197,9 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci 
> *pci)
> bus_range = pci->cfg.bus_range;
> for (busn = bus_range->start; busn <= bus_range->end; ++busn) {
> u32 idx = busn - bus_range->start;
> -   u32 sz = 1 << pci->cfg.ops->bus_shift;
>
> pci->cfg.win[idx] = devm_ioremap(dev,
> -pci->cfg.res.start + busn * 
> sz,
> +pci->cfg.res.start + idx * 
> sz,
>  sz);
> if (!pci->cfg.win[idx])
> return -ENOMEM;
> --
> 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 v7 10/60] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

[Yinghai Lu]

For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource, so set
IORESOUCE_MEM_64 for 64bit resource during OF device resource flags
parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
---
 drivers/of/address.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 384574c..3399602 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -128,9 +128,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 
*addr)
flags |= IORESOURCE_IO;
break;
case 0x02: /* 32 bits */
-   case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+   case 0x03: /* 64 bits */
+   flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+   break;
}
if (w & 0x4000)
flags |= IORESOURCE_PREFETCH;
-- 
1.8.4.5

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

[PATCH] ARM: shmobile: porter: add VIN0/ADV7180 DT support

[Sergei Shtylyov]

Define the  Porter board dependent part of the VIN0 device node.
Add the device node for Analog Devices  ADV7180 video decoder to I2C2 bus.
Add the necessary subnodes to interconnect VIN0 and ADV7180 devices.

This patch is  analogous to the commit 8d62f4f75320 ("ARM: shmobile:
henninger: add VIN0/ADV7180 DT support") as there are no differences
between the boards in this respect.

Signed-off-by: Sergei Shtylyov 

---
This patch is against 'renesas-devel-20151008-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo plus the Porter I2C2 support patch just posted.

 arch/arm/boot/dts/r8a7791-porter.dts |   35 +++
 1 file changed, 35 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -114,6 +114,11 @@
renesas,groups = "i2c2";
renesas,function = "i2c2";
};
+
+   vin0_pins: vin0 {
+   renesas,groups = "vin0_data8", "vin0_clk";
+   renesas,function = "vin0";
+   };
 };
 
 &scif0 {
@@ -166,8 +171,38 @@
 
status = "okay";
clock-frequency = <40>;
+
+   composite-in@20 {
+   compatible = "adi,adv7180";
+   reg = <0x20>;
+   remote = <&vin0>;
+
+   port {
+   adv7180: endpoint {
+   bus-width = <8>;
+   remote-endpoint = <&vin0ep>;
+   };
+   };
+   };
 };
 
 &sata0 {
status = "okay";
 };
+
+/* composite video input */
+&vin0 {
+   status = "ok";
+   pinctrl-0 = <&vin0_pins>;
+   pinctrl-names = "default";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vin0ep: endpoint {
+   remote-endpoint = <&adv7180>;
+   bus-width = <8>;
+   };
+   };
+};

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

[PATCH] ARM: shmobile: porter: add I2C2 DT support

[Sergei Shtylyov]

Define the Porter board dependent part of the I2C2 device node.

This patch is  analogous to the commit 29a647c396a0 ("ARM: shmobile:
henninger: add I2C2 DT support") as there are no differences between
the boards in this respect.

Signed-off-by: Sergei Shtylyov 

---
This patch is against 'renesas-devel-20151008-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo.

 arch/arm/boot/dts/r8a7791-porter.dts |   13 +
 1 file changed, 13 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -109,6 +109,11 @@
renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
renesas,function = "sdhi2";
};
+
+   i2c2_pins: i2c2 {
+   renesas,groups = "i2c2";
+   renesas,function = "i2c2";
+   };
 };
 
 &scif0 {
@@ -155,6 +160,14 @@
status = "okay";
 };
 
+&i2c2 {
+   pinctrl-0 = <&i2c2_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+   clock-frequency = <40>;
+};
+
 &sata0 {
status = "okay";
 };

--
To unsubscribe from this list: send the line "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/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

[Ezequiel Garcia]

On 6 October 2015 at 13:27, Harvey Hunt  wrote:
> From: Alex Smith 
>
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
>
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
>
> Signed-off-by: Alex Smith 
> Cc: Zubair Lutfullah Kakakhel 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: Paul Burton 
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Alex Smith 
> Signed-off-by: Harvey Hunt 
> ---
> v6 -> v7:
>  - Add nand-ecc-mode to DT.
>  - Add nand-on-flash-bbt to DT.
>
> v4 -> v5:
>  - New patch adding DT nodes for the NAND so that the driver can be
>tested.
>
>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
> ++
>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>  2 files changed, 80 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..453f1d3 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,57 @@
>  &uart4 {
> status = "okay";
>  };
> +
> +&nemc {
> +   status = "okay";
> +
> +   nand: nand@1 {
> +   compatible = "ingenic,jz4780-nand";
> +   reg = <1 0 0x100>;
> +

Why is this in the ci20.dts instead of the SoC dtsi?

Seems at least compatible and reg is not board-specific.

Thanks,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: generic: Fix address window calculation for non-zero starting bus.

[Arnd Bergmann]

On Thursday 08 October 2015 12:54:16 David Daney wrote:
> From: David Daney 
> 
> Make the offset from the beginning of the "reg" property be from the
> starting bus number, rather than zero.  Hoist the invariant size
> calculation out of the mapping for loop.
> 
> Update host-generic-pci.txt to clarify the semantics of the "reg"
> property with respect to non-zero starting bus numbers.
> 
> Signed-off-by: David Daney 
> 

Thanks a lot!

Reviewed-by: Arnd Bergmann 
--
To unsubscribe from this list: send the line "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] dt-bindings: Document the STM32 DMA bindings

[Arnd Bergmann]

On Thursday 08 October 2015 22:25:50 M'boumba Cedric Madianga wrote:
> >
> > How do you know which channels are available for memory-to-memory
> > transfers?
> For memory-to-memory transfer we don't need any channel/request combination.
> We look for any available channel in the channel list to execute our transfer.
> So, as often as possible, we expect that a peripheral release his
> channel after transfering data.
> In that way, we always should have at least one channel available for
> that kind of transfer.
> 

Ah, got it. So the use of virtual channels in this driver makes MEM2MEM
transfers work, but is otherwise not required.

Thanks for the clarification.

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/4] dt-bindings: Document the STM32 DMA bindings

[M'boumba Cedric Madianga]

2015-10-08 21:26 GMT+02:00 Arnd Bergmann :
> On Thursday 08 October 2015 18:01:23 M'boumba Cedric Madianga wrote:
>> Hi Arnd,
>>
>> 2015-10-08 17:43 GMT+02:00 Arnd Bergmann :
>> > On Thursday 08 October 2015 17:20:09 M'boumba Cedric Madianga wrote:
>> >> +Each dmas request consists of 5 cells:
>> >> +1. A phandle pointing to the STM32 DMA controller
>> >> +2. The channel id
>> >> +3. The request line number
>> >> +4. A 32bit mask specifying the DMA channel configuration
>> >>
>> >
>> > It's fairly unusual to encode the channel id here, rather than
>> > letting the driver pick one. Is that actually required here?
>>
>> Yes it is required as in STM32 platform the channel/request DMA
>> mapping is done by hardware lines.
>> So, if one client wants to use DMA, he has to choose the correct
>> channel/request values according to the DMA mapping of his STM32
>> platform.
>
> Interesting. So you have seven channels ans seven request lines,
> with a random but fixed mapping between them?
We have eight channels and eight request lines with fixed mapping between them
Each peripheral has his channel/request combination to access to the
DMA controller.
>
> How do you know which channels are available for memory-to-memory
> transfers?
For memory-to-memory transfer we don't need any channel/request combination.
We look for any available channel in the channel list to execute our transfer.
So, as often as possible, we expect that a peripheral release his
channel after transfering data.
In that way, we always should have at least one channel available for
that kind of transfer.
>
> Arnd

BR,
Cedric
--
To unsubscribe from this list: send the line "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] PCI: generic: Fix address window calculation for non-zero starting bus.

[David Daney]

From: David Daney 

Make the offset from the beginning of the "reg" property be from the
starting bus number, rather than zero.  Hoist the invariant size
calculation out of the mapping for loop.

Update host-generic-pci.txt to clarify the semantics of the "reg"
property with respect to non-zero starting bus numbers.

Signed-off-by: David Daney 
---
This is a replacement for:

https://lkml.org/lkml/2015/10/2/653

Since that patch is getting too much push-back, this is the only other
option for fixing the driver to be internally consistent in its
treatment of the offset from "reg" to the first bus in the "bus-range"
property.

 Documentation/devicetree/bindings/pci/host-generic-pci.txt | 5 +++--
 drivers/pci/host/pci-host-generic.c| 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt 
b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
index cf3e205..3f1d3fc 100644
--- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
+++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
@@ -34,8 +34,9 @@ Properties of the host controller node:
 - #size-cells: Must be 2.
 
 - reg: The Configuration Space base address and size, as accessed
-   from the parent bus.
-
+   from the parent bus.  The base address corresponds to
+   the first bus in the "bus-range" property.  If no
+   "bus-range" is specified, this will be bus 0 (the default).
 
 Properties of the /chosen node:
 
diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index fe9a81b..bb93346 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -169,6 +169,7 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci 
*pci)
struct resource *bus_range;
struct device *dev = pci->host.dev.parent;
struct device_node *np = dev->of_node;
+   u32 sz = 1 << pci->cfg.ops->bus_shift;
 
err = of_address_to_resource(np, 0, &pci->cfg.res);
if (err) {
@@ -196,10 +197,9 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci 
*pci)
bus_range = pci->cfg.bus_range;
for (busn = bus_range->start; busn <= bus_range->end; ++busn) {
u32 idx = busn - bus_range->start;
-   u32 sz = 1 << pci->cfg.ops->bus_shift;
 
pci->cfg.win[idx] = devm_ioremap(dev,
-pci->cfg.res.start + busn * sz,
+pci->cfg.res.start + idx * sz,
 sz);
if (!pci->cfg.win[idx])
return -ENOMEM;
-- 
1.9.1

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

Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings

[Arnd Bergmann]

On Thursday 08 October 2015 18:01:23 M'boumba Cedric Madianga wrote:
> Hi Arnd,
> 
> 2015-10-08 17:43 GMT+02:00 Arnd Bergmann :
> > On Thursday 08 October 2015 17:20:09 M'boumba Cedric Madianga wrote:
> >> +Each dmas request consists of 5 cells:
> >> +1. A phandle pointing to the STM32 DMA controller
> >> +2. The channel id
> >> +3. The request line number
> >> +4. A 32bit mask specifying the DMA channel configuration
> >>
> >
> > It's fairly unusual to encode the channel id here, rather than
> > letting the driver pick one. Is that actually required here?
>
> Yes it is required as in STM32 platform the channel/request DMA
> mapping is done by hardware lines.
> So, if one client wants to use DMA, he has to choose the correct
> channel/request values according to the DMA mapping of his STM32
> platform.
 
Interesting. So you have seven channels ans seven request lines,
with a random but fixed mapping between them?

How do you know which channels are available for memory-to-memory
transfers?

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

Re: [PATCH v2] video: fbdev: add Marvell PXA framebuffer binding

[Robert Jarzmik]

Rob Herring  writes:

>> The pxafb driver acts today on the subset of registers which are the same 
>> across
>> all pxaXXX variants. This is what made me think only one compatible property 
>> was
>> required.
>>
>> If I'm wrong, I could add "marvell,pxa3xx-lcdc", is that what you think I 
>> should
>> do ?
>
> I would prefer specific compatibles (e.g. marvell,pxa270-lcdc) in
> addition to a generic one. You never know when a specific chip will
> have some quirk even though "the IP is the same".
Okay.

>> And then, when a board maintainer will create a devicetree description, he 
>> will
>> write something like :
>>   compatible = "toshiba,ltm0305a776";
>>   compatible = "marvell,pxa2xx-panel";
>
> Drop this compatible.
>
>>   lcd-type = "color-tft";
>>   ...
>>
>> If that's the case, I wonder how to "enforce" that a panel used with
>> marvell,pxa2xx-lcdc (through the of_graph 'port' node) be compatible with
>> marvell,pxa2xx-panel ?
>
> I'm not sure what you mean. Putting the panel into the dts ensures
> that. The FB driver may check for toshiba,ltm0305a776 or a list of
> panels. However, a DRM driver would probably not check that.
>
> Rob
What I mean is that the LDLC controller _must_ be programmmed with the correct
panel type, ie. one register of the LDLC should be set according to this type.

The type is a hardware property of the panel, and yet it is absolutely mandatory
to have it set in the panel.

What I mean is : what is the good way to enforce that this property is set
somewhere in the devicetree description ? Philipp adviced for it to be 
transfered
to the ldlc description (ie. marvell,pxa2xx-ldlc), while I was thinking of
having it in a panel description.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "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 05/13] arm64: enable building of all dtbs

[Rob Herring]

On Thu, Oct 8, 2015 at 1:15 PM, Geert Uytterhoeven  wrote:
> On Thu, Oct 8, 2015 at 7:53 PM, Rob Herring  wrote:
>> Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
>> are not really dependent on a platform being enabled or any other kernel
>> config, so for testing coverage it is convenient to build all of the dtbs.
>> This builds all dts files in the tree, not just targets listed. This
>> is simpler for arm64 which has a bunch of sub-dirs.
>
> This doesn't look simpler than the arm(32) version?

I discussed this with Olof in the last version. In the ARM version, I
could have done just one line "dtb-$(CONFIG_OF_ALL_DTBS) += $(dtb-)"
to add all the disabled dtbs. On arm64, I would have to do that for
each sub-dir Makefile as well as make sure any new sub-dirs have this
line. In the end, I also prefer to build everything in the tree and
not rely on the dtbs to be explicitly listed.

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

Re: [PATCH 3/5] clk: imx7d: add ADC root clock

[Stephen Boyd]

On 10/08, Haibo Chen wrote:
> Add ADC root clock support in imx7d clock tree.
> 
> Signed-off-by: Haibo Chen 
> ---

I see no cover letter indicating how you want this merged, so:

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of 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 2/4] arm64: dts: qcom: Add msm8916 I2C nodes.

[Stephen Boyd]

On 10/08/2015 04:19 AM, Srinivas Kandagatla wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 85f7bee..d49ac37 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -233,6 +233,22 @@
>   status = "disabled";
>   };
>  
> + /* BLSP1 QUP2 */

This comment is useless.

> + blsp_i2c2: i2c@78b6000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x78b6000 0x1000>;
> + interrupts = ;
>

-- 
Qualcomm Innovation Center, Inc. is a member of 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 4/4] arm64: dts: apq8016-sbc: enable spi buses on LS and HS

[Stephen Boyd]

On 10/08/2015 04:19 AM, Srinivas Kandagatla wrote:
> This patch enables spi buses on low speed and high speed expansion
> connectors on DB410C
>
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 3581272..d872654 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -92,11 +92,21 @@
>   status = "okay";
>  };
>  
> +&blsp_spi3 {
> + /* On High speed expansion */
> + status = "okay";
> +};
> +
>  &blsp_i2c4 {
>   /* On High speed expansion */
>   status = "okay";
>  };
>  
> +&blsp_spi5 {
> + /* On Low speed expansion */
> + status = "okay";
> +};
> +
>  &blsp_i2c6 {
>   /* On Low speed expansion */
>   status = "okay";

We've been using absolute nodes to mark device nodes as status = "okay".
Can we keep doing that here please?

-- 
Qualcomm Innovation Center, Inc. is a member of 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 v2 05/13] arm64: enable building of all dtbs

[Geert Uytterhoeven]

On Thu, Oct 8, 2015 at 7:53 PM, Rob Herring  wrote:
> Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
> are not really dependent on a platform being enabled or any other kernel
> config, so for testing coverage it is convenient to build all of the dtbs.
> This builds all dts files in the tree, not just targets listed. This
> is simpler for arm64 which has a bunch of sub-dirs.

This doesn't look simpler than the arm(32) version?

> Signed-off-by: Rob Herring 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: linux-arm-ker...@lists.infradead.org
> ---
>  arch/arm64/boot/dts/Makefile | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index d9f8833..b01ec43 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -14,3 +14,9 @@ dts-dirs += sprd
>  dts-dirs += xilinx
>
>  subdir-y   := $(dts-dirs)
> +
> +dtstree:= $(srctree)/$(src)
> +
> +dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach 
> d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts)))
> +




-- 
Gr{oetje,eeting}s,

Geert

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

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

[PATCH v2 11/13] nios2: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed.

Signed-off-by: Rob Herring 
Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
---
 arch/nios2/boot/dts/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/nios2/boot/dts/Makefile b/arch/nios2/boot/dts/Makefile
index 1c52039..0b6bcf1 100644
--- a/arch/nios2/boot/dts/Makefile
+++ b/arch/nios2/boot/dts/Makefile
@@ -1,3 +1,6 @@
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
+
 always  := $(dtb-y)
 clean-files := *.dtb
 
-- 
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 v2 05/13] arm64: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed. This
is simpler for arm64 which has a bunch of sub-dirs.

Signed-off-by: Rob Herring 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm64/boot/dts/Makefile | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index d9f8833..b01ec43 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -14,3 +14,9 @@ dts-dirs += sprd
 dts-dirs += xilinx
 
 subdir-y   := $(dts-dirs)
+
+dtstree:= $(srctree)/$(src)
+
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach 
d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts)))
+
+always := $(dtb-y)
-- 
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 v2 13/13] xtensa: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed.

Signed-off-by: Rob Herring 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: linux-xte...@linux-xtensa.org
---
 arch/xtensa/Makefile  | 4 
 arch/xtensa/boot/dts/Makefile | 7 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/xtensa/Makefile b/arch/xtensa/Makefile
index f9e6a06..709b574 100644
--- a/arch/xtensa/Makefile
+++ b/arch/xtensa/Makefile
@@ -101,6 +101,10 @@ zImage: vmlinux
 %.dtb:
$(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
 
+dtbs: scripts
+   $(Q)$(MAKE) $(build)=$(boot)/dts
+
 define archhelp
   @echo '* zImage  - Compressed kernel image 
(arch/xtensa/boot/images/zImage.*)'
+  @echo '  dtbs- Build device tree blobs for enabled boards'
 endef
diff --git a/arch/xtensa/boot/dts/Makefile b/arch/xtensa/boot/dts/Makefile
index 5f711bb..a15e241 100644
--- a/arch/xtensa/boot/dts/Makefile
+++ b/arch/xtensa/boot/dts/Makefile
@@ -12,4 +12,9 @@ ifneq ($(CONFIG_BUILTIN_DTB),"")
 obj-$(CONFIG_OF) += $(BUILTIN_DTB)
 endif
 
-clean-files := *.dtb.S
+dtstree := $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
+
+always += $(dtb-y)
+clean-files += *.dtb *.dtb.S
+
-- 
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 v2 04/13] arm: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed. This
is simpler for arm64 which has a bunch of sub-dirs.

Signed-off-by: Rob Herring 
Cc: Russell King 
---
 arch/arm/boot/dts/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..349eb12 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -740,5 +740,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
 dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
 endif
 
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
+
 always := $(dtb-y)
 clean-files:= *.dtb
-- 
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 v2 07/13] metag: use common make variables for dtb builds

[Rob Herring]

Use dtb-y and always make variables to build dtbs instead of explicit
dtbs rule. This is in preparation to support building all dtbs.

Signed-off-by: Rob Herring 
Cc: James Hogan 
Cc: linux-me...@vger.kernel.org
---
 arch/metag/Makefile  | 2 +-
 arch/metag/boot/dts/Makefile | 6 +-
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/metag/Makefile b/arch/metag/Makefile
index 9739857..033a582 100644
--- a/arch/metag/Makefile
+++ b/arch/metag/Makefile
@@ -72,7 +72,7 @@ $(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
 
 dtbs: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts dtbs
+   $(Q)$(MAKE) $(build)=$(boot)/dts
 
 archclean:
$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/metag/boot/dts/Makefile b/arch/metag/boot/dts/Makefile
index 72c1218..2533c38 100644
--- a/arch/metag/boot/dts/Makefile
+++ b/arch/metag/boot/dts/Makefile
@@ -12,11 +12,7 @@ endif
 dtb-$(CONFIG_METAG_BUILTIN_DTB)+= $(builtindtb-y).dtb
 obj-$(CONFIG_METAG_BUILTIN_DTB)+= $(builtindtb-y).dtb.o
 
-targets+= dtbs
-targets+= $(dtb-y)
-
 .SECONDARY: $(obj)/$(builtindtb-y).dtb.S
 
-dtbs: $(addprefix $(obj)/, $(dtb-y))
-
+always += $(dtb-y)
 clean-files += *.dtb *.dtb.S
-- 
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 v2 01/13] of: add config option to enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.

In order to only build dtbs, this option can be used by creating an
allno.config file containing:
CONFIG_COMPILE_TEST=y
CONFIG_OF=y
CONFIG_OF_ALL_DTBS=y

And then running:
make KCONFIG_ALLCONFIG=1 allnoconfig
make dtbs

While building the dtbs themselves don't need a cross compiler, the
scripts dependency does need one. This can be hacked around by
commenting out "subdir-y += mod" in scripts/Makefile.

Signed-off-by: Rob Herring 
Cc: Frank Rowand 
Cc: Grant Likely 
---
 drivers/of/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 59bb855..e2a4841 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -23,6 +23,16 @@ config OF_UNITTEST
 
  If unsure, say N here, but this option is safe to enable.
 
+config OF_ALL_DTBS
+   bool "Build all Device Tree Blobs"
+   depends on COMPILE_TEST
+   select DTC
+   help
+ This option builds all possible Device Tree Blobs (DTBs) for the
+ current architecture.
+
+ If unsure, say N here, but this option is safe to enable.
+
 config OF_FLATTREE
bool
select DTC
-- 
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 v2 08/13] metag: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed.

Signed-off-by: Rob Herring 
Cc: James Hogan 
Cc: linux-me...@vger.kernel.org
---
 arch/metag/boot/dts/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/metag/boot/dts/Makefile b/arch/metag/boot/dts/Makefile
index 2533c38..097c6da 100644
--- a/arch/metag/boot/dts/Makefile
+++ b/arch/metag/boot/dts/Makefile
@@ -12,6 +12,9 @@ endif
 dtb-$(CONFIG_METAG_BUILTIN_DTB)+= $(builtindtb-y).dtb
 obj-$(CONFIG_METAG_BUILTIN_DTB)+= $(builtindtb-y).dtb.o
 
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
+
 .SECONDARY: $(obj)/$(builtindtb-y).dtb.S
 
 always += $(dtb-y)
-- 
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 v2 09/13] mips: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed.

Signed-off-by: Rob Herring 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
---
 arch/mips/boot/dts/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 778a340..bac7b8d 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -9,6 +9,9 @@ dts-dirs+= ralink
 
 obj-y  := $(addsuffix /, $(dts-dirs))
 
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach 
d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts)))
+
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
 clean-files:= *.dtb *.dtb.S
-- 
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 v2 06/13] h8300: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed.

Signed-off-by: Rob Herring 
Cc: Yoshinori Sato 
Cc: uclinux-h8-de...@lists.sourceforge.jp
---
 arch/h8300/boot/dts/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/h8300/boot/dts/Makefile b/arch/h8300/boot/dts/Makefile
index 0abaf1a..6c08467 100644
--- a/arch/h8300/boot/dts/Makefile
+++ b/arch/h8300/boot/dts/Makefile
@@ -8,5 +8,8 @@ dtb-$(CONFIG_H8300H_SIM) := h8300h_sim.dtb
 dtb-$(CONFIG_H8S_SIM) := h8s_sim.dtb
 dtb-$(CONFIG_H8S_EDOSK2674) := edosk2674.dtb
 
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
+
 always := $(dtb-y)
 clean-files := *.dtb.S *.dtb
-- 
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 v2 03/13] arc: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed.

Signed-off-by: Rob Herring 
Cc: Vineet Gupta 
---
 arch/arc/boot/dts/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arc/boot/dts/Makefile b/arch/arc/boot/dts/Makefile
index e8e46f9..a09f11b 100644
--- a/arch/arc/boot/dts/Makefile
+++ b/arch/arc/boot/dts/Makefile
@@ -10,6 +10,8 @@ dtb-y := $(builtindtb-y).dtb
 
 .SECONDARY: $(obj)/$(builtindtb-y).dtb.S
 
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
 
 always := $(dtb-y)
 clean-files := *.dtb  *.dtb.S
-- 
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 v2 12/13] powerpc: enable building of all dtbs

[Rob Herring]

Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
are not really dependent on a platform being enabled or any other kernel
config, so for testing coverage it is convenient to build all of the dtbs.
This builds all dts files in the tree, not just targets listed.

Supporting this requires adding 'dtbs' make target which was not yet
supported on powerpc.

Signed-off-by: Rob Herring 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/Makefile  | 6 ++
 arch/powerpc/boot/Makefile | 5 -
 arch/powerpc/boot/dts/Makefile | 5 +
 3 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/boot/dts/Makefile

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index b9b4af2..0ec35ff 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -273,6 +273,11 @@ bootwrapper_install:
 %.dtb: scripts
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
 
+PHONY += dtbs
+
+dtbs: prepare scripts
+   $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot)/dts
+
 # Used to create 'merged defconfigs'
 # To use it $(call) it with the first argument as the base defconfig
 # and the second argument as a space separated list of .config files to merge,
@@ -317,6 +322,7 @@ define archhelp
   @echo '  dtbImage.   - zImage with an embedded device tree blob'
   @echo '  simpleImage. - Firmware independent image.'
   @echo '  treeImage.  - Support for older IBM 4xx firmware (not U-Boot)'
+  echo  '  dtbs- Build device tree blobs for enabled boards'
   @echo '  install - Install kernel using'
   @echo '(your) ~/bin/$(INSTALLKERNEL) or'
   @echo '(distribution) /sbin/$(INSTALLKERNEL) or'
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4eec430..381df1a 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -402,7 +402,7 @@ zInstall: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
 clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
zImage.miboot zImage.pmac zImage.pseries \
-   zImage.maple simpleImage.* otheros.bld *.dtb
+   zImage.maple simpleImage.* otheros.bld
 
 # clean up files cached by wrapper
 clean-kernel := vmlinux.strip vmlinux.bin
@@ -410,6 +410,9 @@ clean-kernel += $(addsuffix .gz,$(clean-kernel))
 # If not absolute clean-files are relative to $(obj).
 clean-files += $(addprefix $(objtree)/, $(clean-kernel))
 
+# Let clean descend into subdirs
+subdir- := dts
+
 WRAPPER_OBJDIR := /usr/lib/kernel-wrapper
 WRAPPER_DTSDIR := /usr/lib/kernel-wrapper/dts
 WRAPPER_BINDIR := /usr/sbin
diff --git a/arch/powerpc/boot/dts/Makefile b/arch/powerpc/boot/dts/Makefile
new file mode 100644
index 000..f121775
--- /dev/null
+++ b/arch/powerpc/boot/dts/Makefile
@@ -0,0 +1,5 @@
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
+
+always := $(dtb-y)
+clean-files:= *.dtb
-- 
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 v2 10/13] nios2: use common make variables for dtb builds

[Rob Herring]

Use common rules and dtb-y and always make variables to build dtbs
instead of explicit dtbs rule. Add the missing script dependencies as
well.

This is in preparation to support building all dtbs.

Signed-off-by: Rob Herring 
Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
---
 arch/nios2/Makefile  | 10 +-
 arch/nios2/boot/Makefile | 13 +++--
 arch/nios2/boot/dts/Makefile |  3 +++
 3 files changed, 11 insertions(+), 15 deletions(-)
 create mode 100644 arch/nios2/boot/dts/Makefile

diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
index 2328f82..5508587 100644
--- a/arch/nios2/Makefile
+++ b/arch/nios2/Makefile
@@ -41,7 +41,7 @@ core-y+= arch/nios2/platform/
 INSTALL_PATH ?= /tftpboot
 nios2-boot := arch/$(ARCH)/boot
 BOOT_TARGETS = vmImage zImage
-PHONY += $(BOOT_TARGETS) install
+PHONY += $(BOOT_TARGETS) install dtbs
 KBUILD_IMAGE := $(nios2-boot)/vmImage
 
 ifneq ($(CONFIG_NIOS2_DTB_SOURCE),"")
@@ -53,11 +53,11 @@ all: vmImage
 archclean:
$(Q)$(MAKE) $(clean)=$(nios2-boot)
 
-%.dtb:
-   $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
+%.dtb: scripts
+   $(Q)$(MAKE) $(build)=$(nios2-boot)/dts $(nios2-boot)/dts/$@
 
-dtbs:
-   $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
+dtbs: prepare scripts
+   $(Q)$(MAKE) $(build)=$(nios2-boot)/dts
 
 $(BOOT_TARGETS): vmlinux
$(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
diff --git a/arch/nios2/boot/Makefile b/arch/nios2/boot/Makefile
index c899876..187e45d 100644
--- a/arch/nios2/boot/Makefile
+++ b/arch/nios2/boot/Makefile
@@ -31,6 +31,9 @@ $(obj)/zImage: $(obj)/compressed/vmlinux FORCE
 $(obj)/compressed/vmlinux: $(obj)/vmlinux.gz FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed $@
 
+# Let clean descend into subdirs
+subdir- := dts
+
 # Rule to build device tree blobs
 DTB_SRC := $(patsubst "%",%,$(CONFIG_NIOS2_DTB_SOURCE))
 
@@ -45,15 +48,5 @@ $(obj)/linked_dtb.o: $(obj)/system.dtb
 
 obj-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += linked_dtb.o
 
-targets += $(dtb-y)
-
-# Rule to build device tree blobs with make command
-$(obj)/%.dtb: $(src)/dts/%.dts FORCE
-   $(call if_changed_dep,dtc)
-
-$(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
-
-clean-files := *.dtb
-
 install:
sh $(srctree)/$(src)/install.sh $(KERNELRELEASE) $(BOOTIMAGE) 
System.map "$(INSTALL_PATH)"
diff --git a/arch/nios2/boot/dts/Makefile b/arch/nios2/boot/dts/Makefile
new file mode 100644
index 000..1c52039
--- /dev/null
+++ b/arch/nios2/boot/dts/Makefile
@@ -0,0 +1,3 @@
+always  := $(dtb-y)
+clean-files := *.dtb
+
-- 
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 v2 02/13] arc: use common make variables for dtb builds

[Rob Herring]

Use dtb-y and always make variables to build dtbs instead of explicit
dtbs rule. This is in preparation to support building all dtbs.

Signed-off-by: Rob Herring 
Cc: Vineet Gupta 
---
 arch/arc/Makefile  | 2 +-
 arch/arc/boot/dts/Makefile | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 8a27a48..cf0cf34 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -121,7 +121,7 @@ $(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
 
 dtbs: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts dtbs
+   $(Q)$(MAKE) $(build)=$(boot)/dts
 
 archclean:
$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/arc/boot/dts/Makefile b/arch/arc/boot/dts/Makefile
index b0e3f19..e8e46f9 100644
--- a/arch/arc/boot/dts/Makefile
+++ b/arch/arc/boot/dts/Makefile
@@ -6,10 +6,10 @@ ifneq ($(CONFIG_ARC_BUILTIN_DTB_NAME),"")
 endif
 
 obj-y   += $(builtindtb-y).dtb.o
-targets += $(builtindtb-y).dtb
+dtb-y := $(builtindtb-y).dtb
 
 .SECONDARY: $(obj)/$(builtindtb-y).dtb.S
 
-dtbs:  $(addprefix  $(obj)/, $(builtindtb-y).dtb)
 
+always := $(dtb-y)
 clean-files := *.dtb  *.dtb.S
-- 
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 v2 00/13] Enable building all dtb files

[Rob Herring]

This series enables building all the dtb files in the kernel mostly 
independent of the kernel config. The option is only dependent on 
COMPILE_TEST, OF, and the new OF_ALL_DTBS options. This ensures that 
allyesconfig builds can build all dtb files although most arches have to 
build "dtbs" target explicitly. Some arches like ARM include dtbs in the 
default target.

Arch/arm-soc maintainers, Please ack and I will take this series via the DT 
tree.

v2:
- Add OF_ALL_DTBS option hidden behind COMPILE_TEST
- Expand to all architectures (with more than 1 dtb)

Rob


Rob Herring (13):
  of: add config option to enable building of all dtbs
  arc: use common make variables for dtb builds
  arc: enable building of all dtbs
  arm: enable building of all dtbs
  arm64: enable building of all dtbs
  h8300: enable building of all dtbs
  metag: use common make variables for dtb builds
  metag: enable building of all dtbs
  mips: enable building of all dtbs
  nios2: use common make variables for dtb builds
  nios2: enable building of all dtbs
  powerpc: enable building of all dtbs
  xtensa: enable building of all dtbs

 arch/arc/Makefile  |  2 +-
 arch/arc/boot/dts/Makefile |  6 --
 arch/arm/boot/dts/Makefile |  3 +++
 arch/arm64/boot/dts/Makefile   |  6 ++
 arch/h8300/boot/dts/Makefile   |  3 +++
 arch/metag/Makefile|  2 +-
 arch/metag/boot/dts/Makefile   |  7 +++
 arch/mips/boot/dts/Makefile|  3 +++
 arch/nios2/Makefile| 10 +-
 arch/nios2/boot/Makefile   | 13 +++--
 arch/nios2/boot/dts/Makefile   |  6 ++
 arch/powerpc/Makefile  |  6 ++
 arch/powerpc/boot/Makefile |  5 -
 arch/powerpc/boot/dts/Makefile |  5 +
 arch/xtensa/Makefile   |  4 
 arch/xtensa/boot/dts/Makefile  |  7 ++-
 drivers/of/Kconfig | 10 ++
 17 files changed, 73 insertions(+), 25 deletions(-)
 create mode 100644 arch/nios2/boot/dts/Makefile
 create mode 100644 arch/powerpc/boot/dts/Makefile

-- 
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 v4 4/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Lorenzo Pieralisi]

On Thu, Oct 08, 2015 at 08:39:58AM -0700, David Daney wrote:
> On 10/08/2015 08:18 AM, Arnd Bergmann wrote:
> >On Thursday 08 October 2015 17:11:32 Arnd Bergmann wrote:
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> @@ -34,7 +34,11 @@ Properties of the host controller node:
>   - #size-cells: Must be 2.
> 
>   - reg: The Configuration Space base address and size, as 
>  accessed
> -   from the parent bus.
> +   from the parent bus.  The base address corresponds to
> +   bus zero, even though the "bus-range" property may 
> specify
> +   a different starting bus number.  The driver must 
> only map
> +   or access the portion of the Configuration Space that
> +   corresponds to the "bus-range"
> >>
> >>I thought we had reached an agreement that it is a bad idea to have a 'reg'
> >>property that lists registers belonging to a different device.
> >>
> >>
> >
> >To further clarify: the argument was to make it mirror what ACPI does for
> >PCI. However, this is unlike what all other devices do with DT, where you
> >have non-overlapping register ranges (start, length) for each device.
> >ACPI as far as I understand it does not give a range for a PCIe host, but
> >instead provides a way to get the start address of the ECAM register area
> >for the domain that the host is part of, and that needs to be the same
> >address for each host in the domain.
> >
> 
> We are agreed that it is a bad thing to do.  There is disagreement
> about if we should do it.
> 
> I think there are two schools of thought (I will attribute them to
> their proponents and my apologies if I misrepresent someone's
> stance):
> 
> 1) (Arnd) Don't make the the "reg" ranges overlap because it is
> ugly, dangerous and arguably incorrect in general.
> 
> 2) (Me, Will Deacon, Lorenzo Pieralisi) Overlapping "reg" properties
> should be maintained, as that is the current behavior and seems to
> agree with legacy OF device-tree specifications (although there is
> some debate about this).

I have just quoted the PCI FW specification, 4.1.4 section:

"System Software Implication of MCFG and _CBA"

which defines the ACPI behaviour of MCFG and _CBA methods for
hotplug bridges.

I understand Arnd's concerns and I do not think the DT bindings are well
defined in this respect, it is ok for me to define the DT bindings
using the "usual" reg property bindings representation, as long as we
document it and we all agree we are deviating from the PCI FW specs
(that just cover ACPI, BTW).

I think it is worth investigating why the current PCI FW specs were
defined that way for ECAM config space before proceeding any further,
to avoid pitfalls we might be missing.

Thanks,
Lorenzo

> Because the driver is broken in this area (thus the patch), it
> indicates that there are probably no users with non-zero starting
> bus numbers. So, we may have some latitude to change it.
> 
> I will generate another patch that does it Arnd's way, and if Will
> is OK with it, we might be able to do that instead.  One thing is
> certain: The driver is currently broken for non-zero starting bus
> numbers.
> 
> David Daney
> --
> 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

Re: [PATCH v4 1/8] ASoC: dt-bindings: add rockchip tranceiver bindings

[Rob Herring]

On Thu, Oct 8, 2015 at 8:31 AM, Sjoerd Simons
 wrote:
> Add devicetree bindings for the spdif tranceiver found on
> found on rk3066, rk3188 and rk3288 SoCs
>
> Signed-off-by: Sjoerd Simons 
>
> ---
>
> Changes in v4:
> - Require rockchip,grf on RK3288 as the 8 channel solution has to be
>   selected on that SoC
> - Make the compatibility string one of a known list rather then
>   requiring a precise list of options.
> - Change the clock names to hclk and mclk instead of spdif_hclk and
>   spdif_mclk to better match the implementation and data sheets.
>
> Changes in v3: None
> Changes in v2: None
>
>  .../devicetree/bindings/sound/rockchip-spdif.txt   | 44 
> ++
>  1 file changed, 44 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/rockchip-spdif.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.txt 
> b/Documentation/devicetree/bindings/sound/rockchip-spdif.txt
> new file mode 100644
> index 000..33dd82c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.txt
> @@ -0,0 +1,44 @@
> +* Rockchip SPDIF transceiver
> +
> +The S/PDIF audio block is a stereo transceiver that allows the
> +processor to receive and transmit digital audio via an coaxial cable or
> +a fibre cable.
> +
> +Required properties:
> +
> +- compatible: should be one of the following:
> +   - "rockchip,rk3288-spdif", "rockchip,rk3188-spdif" or
> + "rockchip,rk3066-spdif"
> +- reg: physical base address of the controller and length of memory mapped
> +  region.
> +- interrupts: should contain the SPDIF interrupt.

> +- #address-cells: should be 1.
> +- #size-cells: should be 0.

Why do you need these? Are you going to have sub nodes?

> +- dmas: DMA specifiers for tx dma. See the DMA client binding,
> +  Documentation/devicetree/bindings/dma/dma.txt
> +- dma-names: should be "tx"
> +- clocks: a list of phandle + clock-specifier pairs, one for each entry
> +  in clock-names.
> +- clock-names: should contain following:
> +   - "hclk": clock for SPDIF controller
> +   - "mclk" : clock for SPDIF bus
> +
> +Required properties on RK3288:
> +  - rockchip,grf: the phandle of the syscon node for the general register
> +   file (GRF)
> +
> +Example for the rk3188 SPDIF controller:
> +
> +spdif: spdif@0x1011e000 {
> +   compatible = "rockchip,rk3188-spdif", "rockchip,rk3066-spdif";
> +   reg = <0x1011e000 0x2000>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   dmas = <&dmac1_s 8>;
> +   dma-names = "tx";
> +   clock-names = "hclk", "mclk";
> +   clocks = <&cru HCLK_SPDIF>, <&cru SCLK_SPDIF>;
> +   status = "disabled";
> +   #sound-dai-cells = <0>;
> +};
> --
> 2.6.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 v3 1/2] of: Add vendor prefix for QiaoDian Xianshi

[Rob Herring]

On Thu, Oct 8, 2015 at 10:42 AM, Alexandre Belloni
 wrote:
> Use "qiaodian" as the vendor prefix for QiaoDian Xianshi Corporation in
> device tree compatible strings.
>
> Signed-off-by: Alexandre Belloni 

Acked-by: Rob Herring 

> ---
>
> Changes in v3:
>  -use qiaodian as the vendor prefix as preferred by Rob Herring
>
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index ac5f0c34ae00..d6402753fd9f 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -174,6 +174,7 @@ qca Qualcomm Atheros, Inc.
>  qcom   Qualcomm Technologies, Inc
>  qemu   QEMU, a generic and open source machine emulator and virtualizer
>  qi Qi Hardware
> +qiaodian   QiaoDian XianShi Corporation
>  qnap   QNAP Systems, Inc.
>  radxa  Radxa
>  raidsonic  RaidSonic Technology GmbH
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 3/3] ASoC: da7213: Add bindings documentation for codec driver

[Opensource [Adam Thomson]]

On October 08, 2015 14:16, Rob Herring wrote:

> >> > +- dlg,micbias1-lvl : Voltage (mV) for Mic Bias 1
> >> > +   [<1600>, <2200>, <2500>, <3000>]
> >> > +- dlg,micbias2-lvl : Voltage (mV) for Mic Bias 2
> >> > +   [<1600>, <2200>, <2500>, <3000>]
> >>
> >> Please append the units (-microvolt).
> >
> > Given that a user needs to read the bindings document to understand what is
> > available, and what they're for, this seems a little unnecessary.
> 
> You may think so, but it is standard practice.
 
I can find a number of situations in the kernel, where this just isn't followed,
for device specific bindings. What percentage have to follow this for it to be
'standard'? Is this documented somewhere so it's clear for those writing
drivers which need to use DT bindings? I had a quick look and couldn't find
anything on this.

> >>
> >> > +- dlg,dmic-clkrate : DMIC clock frequency (MHz).
> >> > +   [<150>, <300>]
> >>
> >> So 1.5GHz or 3GHz?
> >>
> >> Add units (-hz).
> >
> > Agreed, the description of MHz is misleading so will update to Hz. Thanks.
> > Again though, I don't see what the suffix gives you, and would prefer to 
> > leave
> > the binding as is.
> 
> It tells someone reading the dts what the units are without having to
> find the documentation and helps prevent people using properties with
> differing units.

For a lot of device specific bindings, you will need to read the associated
documentation, and possibly the datasheet, to understand what it's for, and what
values are valid. I don't see this suffix really saving you any time. For
standard frameworks ok, but here it seems overkill.

Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings

[M'boumba Cedric Madianga]

Hi Arnd,

2015-10-08 17:43 GMT+02:00 Arnd Bergmann :
> On Thursday 08 October 2015 17:20:09 M'boumba Cedric Madianga wrote:
>> +Each dmas request consists of 5 cells:
>> +1. A phandle pointing to the STM32 DMA controller
>> +2. The channel id
>> +3. The request line number
>> +4. A 32bit mask specifying the DMA channel configuration
>>
>
> It's fairly unusual to encode the channel id here, rather than
> letting the driver pick one. Is that actually required here?
Yes it is required as in STM32 platform the channel/request DMA
mapping is done by hardware lines.
So, if one client wants to use DMA, he has to choose the correct
channel/request values according to the DMA mapping of his STM32
platform.

>
> Arnd

 BR,
 Cedric
--
To unsubscribe from this list: send the line "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: rpi: Device tree modifications for U-Boot

[Pavel Machek]

Hi!

> This updates the device tree from the kernel version to something suitable
> for U-Boot:
> 
> - Add stdout-path alias for console
> - Mark the /soc node to be available pre-relocation so that the early
> serial console works (we need the 'ranges' property to be available)
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  arch/arm/boot/dts/bcm2835.dtsi | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> @@ -16,6 +17,7 @@
>   #size-cells = <1>;
>   ranges = <0x7e00 0x2000 0x0200>;
>   dma-ranges = <0x4000 0x 0x2000>;
> + u-boot,dm-pre-reloc;
>

Given low ammount of memory available for SPL, such stuff is going to be 
neccessary.

Should it have more generic name... "critical-for-early-boot" ?

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

Re: [PATCH v4 0/5] PCI: generic: Misc. bug fixes/enhancements

[David Daney]

On 10/08/2015 08:28 AM, Bjorn Helgaas wrote:

On Fri, Oct 02, 2015 at 11:43:58AM -0700, David Daney wrote:

From: David Daney 

[...]


David Daney (5):
   PCI: Add pci_bus_fixup_irqs().
   PCI: generic: Only fixup irqs for bus we are creating.


I'm hoping we won't need the above if we can resurrect Matthew's
patches.


I will test some things with this today.





   PCI: generic: Quit clobbering our pci_ops.


Applied to pci/host-generic for v4.4 with Arnd's Reviewed-by and minor
changelog tweaks (as below).


   PCI: generic: Correct, and avoid overflow, in bus_max calculation.


Seems not settled yet.


   PCI: generic: Pass proper starting bus number to pci_scan_root_bus().


Also applied to pci/host-generic, thanks!



Many thanks for getting those two in,


David Daney





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

[PATCH v3 2/2] drm: panel: simple: add QiaoDian qd43003c0-40

[Alexandre Belloni]

From: Josh Wu 

The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.

Timings from the OTA5180A document, ver 0.9, section
10.1.1:
  http://www.orientdisplay.com/pdf/OTA5180A.pdf

Signed-off-by: Josh Wu 
Signed-off-by: Alexandre Belloni 
---
 .../bindings/panel/qiaodian,qd43003c0-40.txt   |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt

diff --git a/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt 
b/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
new file mode 100644
index ..0fbdab89ac3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
@@ -0,0 +1,7 @@
+QiaoDian XianShi Corporation 4"3 TFT LCD panel
+
+Required properties:
+- compatible: should be "qiaodian,qd43003c0-40"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f97b73ec4713..c93ffa615005 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1027,6 +1027,30 @@ static const struct panel_desc ortustech_com43h4m85ulc = 
{
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct drm_display_mode qd43003c0_40_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 8,
+   .hsync_end = 480 + 8 + 4,
+   .htotal = 480 + 8 + 4 + 39,
+   .vdisplay = 272,
+   .vsync_start = 272 + 4,
+   .vsync_end = 272 + 4 + 10,
+   .vtotal = 272 + 4 + 10 + 2,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc qd43003c0_40 = {
+   .modes = &qd43003c0_40_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 95,
+   .height = 53,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct drm_display_mode samsung_ltn101nt05_mode = {
.clock = 54030,
.hdisplay = 1024,
@@ -1182,6 +1206,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ortustech,com43h4m85ulc",
.data = &ortustech_com43h4m85ulc,
}, {
+   .compatible = "qiaodian,qd43003c0-40",
+   .data = &qd43003c0_40,
+   }, {
.compatible = "samsung,ltn101nt05",
.data = &samsung_ltn101nt05,
}, {
-- 
2.1.4

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

[PATCH v3 1/2] of: Add vendor prefix for QiaoDian Xianshi

[Alexandre Belloni]

Use "qiaodian" as the vendor prefix for QiaoDian Xianshi Corporation in
device tree compatible strings.

Signed-off-by: Alexandre Belloni 
---

Changes in v3:
 -use qiaodian as the vendor prefix as preferred by Rob Herring

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac5f0c34ae00..d6402753fd9f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -174,6 +174,7 @@ qca Qualcomm Atheros, Inc.
 qcom   Qualcomm Technologies, Inc
 qemu   QEMU, a generic and open source machine emulator and virtualizer
 qi Qi Hardware
+qiaodian   QiaoDian XianShi Corporation
 qnap   QNAP Systems, Inc.
 radxa  Radxa
 raidsonic  RaidSonic Technology GmbH
-- 
2.1.4

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

Re: [PATCH v2 3/9] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file

[Koul, Vinod]

On Fri, 2015-09-11 at 15:14 +0100, Peter Griffin wrote:

> +#define FDMA_ID_OFST 0x0
> +#define FDMA_VER_OFST0x4
> > +
> +#define FDMA_EN_OFST 0x8

Why cant these be BIT() to maintain consistency?

-- 
~Vinod

Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings

[Arnd Bergmann]

On Thursday 08 October 2015 17:20:09 M'boumba Cedric Madianga wrote:
> +Each dmas request consists of 5 cells:
> +1. A phandle pointing to the STM32 DMA controller
> +2. The channel id
> +3. The request line number
> +4. A 32bit mask specifying the DMA channel configuration
> 

It's fairly unusual to encode the channel id here, rather than
letting the driver pick one. Is that actually required here?

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

Re: [PATCH v4 4/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[David Daney]

On 10/08/2015 08:18 AM, Arnd Bergmann wrote:

On Thursday 08 October 2015 17:11:32 Arnd Bergmann wrote:

--- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
+++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
@@ -34,7 +34,11 @@ Properties of the host controller node:
  - #size-cells: Must be 2.

  - reg: The Configuration Space base address and size, as accessed
-   from the parent bus.
+   from the parent bus.  The base address corresponds to
+   bus zero, even though the "bus-range" property may specify
+   a different starting bus number.  The driver must only map
+   or access the portion of the Configuration Space that
+   corresponds to the "bus-range"


I thought we had reached an agreement that it is a bad idea to have a 'reg'
property that lists registers belonging to a different device.




To further clarify: the argument was to make it mirror what ACPI does for
PCI. However, this is unlike what all other devices do with DT, where you
have non-overlapping register ranges (start, length) for each device.
ACPI as far as I understand it does not give a range for a PCIe host, but
instead provides a way to get the start address of the ECAM register area
for the domain that the host is part of, and that needs to be the same
address for each host in the domain.



We are agreed that it is a bad thing to do.  There is disagreement about 
if we should do it.


I think there are two schools of thought (I will attribute them to their 
proponents and my apologies if I misrepresent someone's stance):


1) (Arnd) Don't make the the "reg" ranges overlap because it is ugly, 
dangerous and arguably incorrect in general.


2) (Me, Will Deacon, Lorenzo Pieralisi) Overlapping "reg" properties 
should be maintained, as that is the current behavior and seems to agree 
with legacy OF device-tree specifications (although there is some debate 
about this).


Because the driver is broken in this area (thus the patch), it indicates 
that there are probably no users with non-zero starting bus numbers. 
So, we may have some latitude to change it.


I will generate another patch that does it Arnd's way, and if Will is OK 
with it, we might be able to do that instead.  One thing is certain: 
The driver is currently broken for non-zero starting bus numbers.


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

Re: [linux-sunxi] [PATCH v2 1/2] mmc: Add support for marking hpi as broken through devicetree

[Hans de Goede]

Hi,

On 10/08/2015 01:32 PM, Olliver Schinagl wrote:

Hey Hans,

On 08-10-15 14:13, Olliver Schinagl wrote:

Hey Hans,


On 08-10-15 10:43, Hans de Goede wrote:

Hi,

On 10/07/2015 09:43 AM, Olliver Schinagl wrote:

Hey Hans,

On 01-04-15 17:26, Hans de Goede wrote:

The eMMC on a tablet I've will stop working / communicating as soon as
the kernel executes:

mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
  EXT_CSD_HPI_MGMT, 1,
  card->ext_csd.generic_cmd6_time);

There seems to be no way to reliable identify eMMC-s which have a broken
hpi implementation, but at least for eMMC's which are soldered onto a board
we can work around this by specifying that hpi is broken in devicetree.

We've been talking about this a little off-list, and I was just triggered again 
by this so I'm following up on it again.

The same issue bit me in the ass on a Micron 'industrial' grade eMMC 
(MTFC4GACAANA) and luckily you found this back then to help me.

As we discussed, this may very well be a limitation of the mmc controller, 
rather then the MMC chip. While we only have a sample size of 2 on 2 different 
socs (with likely the same mmc IP) (A13/A20) I found in the JEDEC spec in the 
appendix on changes from 4.4 to 4.41:
Introduce of High Priority Interrupt mechanism, HPI background and one of 
possible solutions.

Which leaves me to believe, that HPI was added to eMMC in version 4.41 and was 
not available before. Both the A13 and A20 user manuals state that the MMC 
controller in these socs is only version 4.3.

Obviously I know far to little as to what does and what does not work with an 
MMC-host, since it's just a simple data-bus, but I would not be surprised if 
these things are somewhere somewhat related, so hopefully someone on this list 
can give their opinion on this.

I already checked the core/mmc.c where the version is read from the mmc 
controller to see if we can trigger on this based on version, however it seems 
only the major version number is stored here [0]?

So in my opinion, it is quite likely that this setting be moved up to the 
mmc-core level, for the SoC, rather then the card itself?


Yes I was talking to Tsvetan from Olimex and he says they have seen the problem 
with yet
another emmc, so this indeed seems to be a sunxi SoC specific problem, and we 
just need to
disable hpi on all sunxi SoC's.

Do you have time to look into doing a kernel patch for this ?

I'm thinking adding a host-cap called MMC_CAP_BROKEN_HPI and adding
support for that to drivers/mmc/core/host.c: mmc_of_parse() and
extending the current card check for broken-hpi to also check
host->caps

And then we need to decide whether to just hard set that cap
in drivers/mmc/host/sunxi_mmc.c or if we are going to add it
to our dtsi files. I think we should probably just hard-code
it in drivers/mmc/host/sunxi_mmc.c.

Yeah I'll see if I can look into that.

I was also looking if we really cannot detect older MMC versions, and I think 
we can somewhat. I haven't figured out the details yet though.

The EXT_CSD_REV field does yield a version number matching the various 4 
sub-versions, so for now I'm thinking of simply disabeling HPI for anything 
before 4.41 (unless maybe overriden). Since before 4.41 it shouldn't have been 
supported. Maybe add an override that allows use of HPI? but then we have the 
whole backwards compatibility thing.

[0] http://lxr.free-electrons.com/source/drivers/mmc/core/mmc.c#L368


I re-read what you said and looked at the files and think your idea is probably 
best, since there is no version information (in sunxi_mmc.c for example) 
anyway). So there is versioning information on the card level and the mmc core 
level, but not in the host level.

The quick fix, is to use MMC_CAP_BROKEN_HPI
The better fix that would feel better/proper to use MMC_CAP_HPI instead, to 
indicate that a chipset actually can do HPI, since nothing says our chipset 
should do HPI (v4.3 that we have doesn't support it at all).


Maybe, I think for starters doing a MMC_CAP_BROKEN_HPI is best, and then
later maybe do an RFC patch to introduce MMC_CAP_HPI instead, this
becomes difficult quickly though, e.g. on which controllers should
we enable MMC_CAP_HPI ?  Since sunxi currently is the only SoC having
issues with this, I think that MMC_CAP_BROKEN_HPI is the best way to
deal with this.


I'm debating if it would be usefull to have a version field in the mmc host 
struct,


I'm not familiar enough with mmc to say for sure, but I've the feeling that
a lot of card caps introduced in later specs can be used by older hosts
just fine, since they are only a matter of changing the host-driver /
mmc-core. I think it is best to just go for the KISS solution here,
introduce the MMC_CAP_BROKEN_HPI flag and leave it at that.


which would set some capabilities by default based on the version level, but I 
don't think we have that many capabilities right now anyway do we?

P.S. you want to keep the broken-hpi flag (on a car

Re: [PATCH v4 0/5] PCI: generic: Misc. bug fixes/enhancements

[Bjorn Helgaas]

On Fri, Oct 02, 2015 at 11:43:58AM -0700, David Daney wrote:
> From: David Daney 
> 
> While using the pci-host-generic driver to add PCI support for the
> Cavium ThunderX processors, several bugs were discovered.  This patch
> set fixes the bugs, a follow-on set will add the ThunderX support.
> 
> Changes from v3:
> 
>   - Drop "PCI: generic: Claim device resources if PCI_PROBE_ONLY"
> 
>   - Add some Acked-by:
> 
>   - Add to explanation of "reg" property in host-generic-pci.txt.
> 
>   - Add error message if "reg" property is too big.
> 
>   - Use pointer to ops rather than make a copy.
> 
> Changes from v2:
> 
>   - Added " PCI: generic: Claim device resources if PCI_PROBE_ONLY"
> 
> Changes from v1:
> 
>   - "PCI: generic: Allow bus default MSI controller to be specified."
> patch was dropped as it is no longer necessary.
> 
>   - "PCI: Make global and export pdev_fixup_irq()." and "PCI: generic:
> Only fixup irqs for bus we are creating." were rewritten to move
> the support into a somewhat more generic form in setup-irq.c.
> 
>   - Add some clarifying text to host-generic-pci.txt
> 
>   - Add some Acked-by:
> 
> 
> David Daney (5):
>   PCI: Add pci_bus_fixup_irqs().
>   PCI: generic: Only fixup irqs for bus we are creating.

I'm hoping we won't need the above if we can resurrect Matthew's
patches.

>   PCI: generic: Quit clobbering our pci_ops.

Applied to pci/host-generic for v4.4 with Arnd's Reviewed-by and minor
changelog tweaks (as below).

>   PCI: generic: Correct, and avoid overflow, in bus_max calculation.

Seems not settled yet.

>   PCI: generic: Pass proper starting bus number to pci_scan_root_bus().

Also applied to pci/host-generic, thanks!

commit 9a28033753ca
Author: David Daney 
Date:   Thu Oct 8 10:15:10 2015 -0500

PCI: generic: Allow multiple hosts with different map_bus() methods

The generic driver kept a global struct pci_ops ("gen_pci_ops") which it
patched with the .map_bus() method appropriate for the bus device.  This is
a problem when we have two different types of bus devices: the .map_bus()
method for the last device probed clobbers the method for previous devices.
The result is that only the last bus device probed has the correct
.map_bus(), and the others fail.

Move the struct pci_ops into the bus-specific structure and initialize a
pointer to it when the bus device is probed.

Signed-off-by: David Daney 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Arnd Bergmann 
Acked-by: Will Deacon 

commit 47ddb949029f
Author: David Daney 
Date:   Thu Oct 8 10:24:41 2015 -0500

PCI: generic: Pass starting bus number to pci_scan_root_bus()

If the bus is being configured with a bus-range that does not start at
zero, pass that starting bus number to pci_scan_root_bus().  Passing the
incorrect value of zero causes attempted config accesses outside of the
supported range, which cascades to an OOPs spew and eventual kernel panic.

Signed-off-by: David Daney 
Signed-off-by: Bjorn Helgaas 
Acked-by: Will Deacon 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] dt-bindings: Document the STM32 DMA bindings

[M'boumba Cedric Madianga]

This patch adds documentation of device tree bindings for the STM32 dma
controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 .../devicetree/bindings/dma/stm32-dma.txt  | 98 ++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt

diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt 
b/Documentation/devicetree/bindings/dma/stm32-dma.txt
new file mode 100644
index 000..9ce0d49
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
@@ -0,0 +1,98 @@
+* STMicroelectronics STM32 DMA controller
+
+The STM32 DMA is a general-purpose direct memory access controller capable of
+supporting 8 independent DMA channels. Each channel can have up to 8 requests.
+
+Required properties:
+- compatible: Should be "st,stm32-dma"
+- reg: Should contain DMA registers location and length. This should include
+  all of the per-channel registers.
+- interrupts: Should contain all of the per-channel DMA interrupts.
+- clocks: Should contain the input clock of the DMA instance.
+- #dma-cells : Must be <4>. See DMA client paragraph for more details.
+
+Optional properties:
+- resets: Reference to a reset controller asserting the DMA controller
+- st,mem2mem: boolean; if defined, it indicates that the controller supports
+  memory-to-memory transfer
+
+Example:
+
+   dma2: dma-controller@40026400 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026400 0x400>;
+   interrupts = <56>,
+<57>,
+<58>,
+<59>,
+<60>,
+<68>,
+<69>,
+<70>;
+   clocks = <&clk_hclk>;
+   #dma-cells = <4>;
+   st,mem2mem;
+   resets = <&rcc 150>;
+   };
+
+* DMA client
+
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 5 cells:
+1. A phandle pointing to the STM32 DMA controller
+2. The channel id
+3. The request line number
+4. A 32bit mask specifying the DMA channel configuration
+ -bit 1: Direct Mode Error Interrupt
+   0x0: disabled
+   0x1: enabled
+ -bit 2: Transfer Error Interrupt
+   0x0: disabled
+   0x1: enabled
+ -bit 3: Half Transfer Mode Error Interrupt
+   0x0: disabled
+   0x1: enabled
+ -bit 4: Transfer Complete Interrupt
+   0x0: disabled
+   0x1: enabled
+ -bit 9: Peripheral Increment Address
+   0x0: no address increment between transfers
+   0x1: increment address between transfers
+ -bit 10: Memory Increment Address
+   0x0: no address increment between transfers
+   0x1: increment address between transfers
+ -bit 15: Peripheral Increment Offset Size
+   0x0: offset size is linked to the peripheral bus width
+   0x1: offset size is fixed to 4 (32-bit alignment)
+ -bit 16-17: Priority level
+   0x0: low
+   0x1: medium
+   0x2: high
+   0x3: very high
+5. A 32bit mask specifying the DMA FIFO configuration
+ -bit 0-1: Fifo threshold
+   0x0: 1/4 full FIFO
+   0x1: 1/2 full FIFO
+   0x2: 3/4 full FIFO
+   0x3:full FIFO
+ -bit 2: Direct mode
+   0x0: enabled
+   0x1: disabled
+ -bit 7: FIFO Error Interrupt
+   0x0: disabled
+   0x1: enabled
+
+Example:
+
+   usart1: serial@40011000 {
+   compatible = "st,stm32-usart", "st,stm32-uart";
+   reg = <0x40011000 0x400>;
+   interrupts = <37>;
+   clocks = <&clk_pclk2>;
+   dmas = <&dma2 2 4 0x20610 0x3>,
+  <&dma2 7 5 0x20610 0x3>;
+   dma-names = "rx", "tx";
+   };
-- 
1.9.1

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

[PATCH 0/4] Add support for STM32 DMA

[M'boumba Cedric Madianga]

This patchset adds support for the STM32 DMA controller.
This controller provides 8 channels dedicated to managing memory access
request from one or more peripherals.
Each stream can have up to 8 requests in total.

M'boumba Cedric Madianga (4):
  dt-bindings: Document the STM32 DMA bindings
  dmaengine: Add STM32 DMA driver
  ARM: dts: Add STM32 DMA support for STM32F429 MCU
  ARM: configs: Add STM32 DMA support in STM32 defconfig

 .../devicetree/bindings/dma/stm32-dma.txt  |   98 ++
 arch/arm/boot/dts/stm32f429.dtsi   |   31 +
 arch/arm/configs/stm32_defconfig   |2 +
 drivers/dma/Kconfig|   12 +
 drivers/dma/Makefile   |1 +
 drivers/dma/stm32-dma.c| 1193 
 6 files changed, 1337 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt
 create mode 100644 drivers/dma/stm32-dma.c

-- 
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 4/4] ARM: configs: Add STM32 DMA support in STM32 defconfig

[M'boumba Cedric Madianga]

This patch adds STM32 DMA support in stm32_defconfig file

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/configs/stm32_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 4725fab..ec52505 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -54,6 +54,8 @@ CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_DMADEVICES=y
+CONFIG_STM32_DMA=y
 # CONFIG_FILE_LOCKING is not set
 # CONFIG_DNOTIFY is not set
 # CONFIG_INOTIFY_USER is not set
-- 
1.9.1

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

[PATCH 2/4] dmaengine: Add STM32 DMA driver

[M'boumba Cedric Madianga]

This patch adds support for the STM32 DMA controller.

Signed-off-by: M'boumba Cedric Madianga 
---
 drivers/dma/Kconfig |   12 +
 drivers/dma/Makefile|1 +
 drivers/dma/stm32-dma.c | 1193 +++
 3 files changed, 1206 insertions(+)
 create mode 100644 drivers/dma/stm32-dma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 5c931d4..4c6b37b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -431,6 +431,18 @@ config STE_DMA40
help
  Support for ST-Ericsson DMA40 controller
 
+config STM32_DMA
+   tristate "STMicroelectronics STM32 dma support"
+   depends on ARCH_STM32
+   select DMA_ENGINE
+   select DMA_OF
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for the on-chip DMA controller on STMicroelectronics
+ STM32 MCUs.
+ If you have a board based on such a MCU and wish to use DMA say Y or M
+ here.
+
 config S3C24XX_DMAC
tristate "Samsung S3C24XX DMA support"
depends on ARCH_S3C24XX
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index ef9c099..2dd0a067 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
 obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
+obj-$(CONFIG_STM32_DMA) += stm32-dma.o
 obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
 obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
new file mode 100644
index 000..9814ca5
--- /dev/null
+++ b/drivers/dma/stm32-dma.c
@@ -0,0 +1,1193 @@
+/*
+ * Driver for STM32 DMA controller
+ *
+ * Inspired by dma-jz4740.c and tegra20-apb-dma.c
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2015
+ * Author: M'boumba Cedric Madianga 
+ *
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "virt-dma.h"
+
+#define STM32_DMA_LISR 0x /* DMA Low Int Status Reg */
+#define STM32_DMA_HISR 0x0004 /* DMA High Int Status Reg */
+#define STM32_DMA_LIFCR0x0008 /* DMA Low Int Flag 
Clear Reg */
+#define STM32_DMA_HIFCR0x000C /* DMA High Int Flag 
Clear Reg */
+#define STM32_DMA_TCI  BIT(5) /* Transfer Complete Interrupt */
+#define STM32_DMA_HTI  BIT(4) /* Half Transfer Interrupt */
+#define STM32_DMA_TEI  BIT(3) /* Transfer Error Interrupt */
+#define STM32_DMA_DMEI BIT(2) /* Direct Mode Error Interrupt */
+#define STM32_DMA_FEI  BIT(0) /* FIFO Error Interrupt */
+
+/* DMA Stream x Configuration Register */
+#define STM32_DMA_SCR(x)   (0x0010 + 0x18 * (x)) /* x = 0..7 */
+#define STM32_DMA_SCR_REQ(n)   ((n & 0x7) << 25)
+#define STM32_DMA_SCR_MBURST_MASK  GENMASK(24, 23)
+#define STM32_DMA_SCR_MBURST(n)((n & 0x3) << 23)
+#define STM32_DMA_SCR_PBURST_MASK  GENMASK(22, 21)
+#define STM32_DMA_SCR_PBURST(n)((n & 0x3) << 21)
+#define STM32_DMA_SCR_PL_MASK  GENMASK(17, 16)
+#define STM32_DMA_SCR_PL(n)((n & 0x3) << 16)
+#define STM32_DMA_SCR_MSIZE_MASK   GENMASK(14, 13)
+#define STM32_DMA_SCR_MSIZE(n) ((n & 0x3) << 13)
+#define STM32_DMA_SCR_PSIZE_MASK   GENMASK(12, 11)
+#define STM32_DMA_SCR_PSIZE(n) ((n & 0x3) << 11)
+#define STM32_DMA_SCR_PSIZE_GET(n) ((n & STM32_DMA_SCR_PSIZE_MASK) >> 11)
+#define STM32_DMA_SCR_DIR_MASK GENMASK(7, 6)
+#define STM32_DMA_SCR_DIR(n)   ((n & 0x3) << 6)
+#define STM32_DMA_SCR_CT   BIT(19) /* Target in double buffer */
+#define STM32_DMA_SCR_DBM  BIT(18) /* Double Buffer Mode */
+#define STM32_DMA_SCR_PINCOS   BIT(15) /* Peripheral inc offset size */
+#define STM32_DMA_SCR_MINC BIT(10) /* Memory increment mode */
+#define STM32_DMA_SCR_PINC BIT(9) /* Peripheral increment mode */
+#define STM32_DMA_SCR_CIRC BIT(8) /* Circular mode */
+#define STM32_DMA_SCR_PFCTRL   BIT(5) /* Peripheral Flow Controller */
+#define STM32_DMA_SCR_TCIE BIT(4) /* Transfer Cplete Int Enable*/
+#define STM32_DMA_SCR_HTIE BIT(3) /* Halft Transfer Int Enable*/
+#define STM32_DMA_SCR_TEIE BIT(2) /* Transfer Error Int Enable */
+#define STM32_DMA_SCR_DMEIEBIT(1) /* Direct Mode Err Int Enable */
+#define STM32_DMA_SCR_EN   BIT(0) /* Stream Enable */
+#define STM32_DMA_STREAM_CFG_MASK  (STM32_DMA_SCR_DMEIE \
+   | STM32_DMA_SCR_TEIE \
+   | STM32_DMA_SCR_HTIE \
+ 

[PATCH 3/4] ARM: dts: Add STM32 DMA support for STM32F429 MCU

[M'boumba Cedric Madianga]

This patch adds STM32 DMA bindings for STM32F429.

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/boot/dts/stm32f429.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index d78a481..037eb29 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -174,6 +174,37 @@
reg = <0x40023800 0x400>;
clocks = <&clk_hse>;
};
+
+   dma1: dma-controller@40026000 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026000 0x400>;
+   interrupts = <11>,
+<12>,
+<13>,
+<14>,
+<15>,
+<16>,
+<17>,
+<47>;
+   clocks = <&rcc 0 21>;
+   #dma-cells = <4>;
+   };
+
+   dma2: dma-controller@40026400 {
+   compatible = "st,stm32-dma";
+   reg = <0x40026400 0x400>;
+   interrupts = <56>,
+<57>,
+<58>,
+<59>,
+<60>,
+<68>,
+<69>,
+<70>;
+   clocks = <&rcc 0 22>;
+   #dma-cells = <4>;
+   st,mem2mem;
+   };
};
 };
 
-- 
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 v4 4/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Arnd Bergmann]

On Thursday 08 October 2015 17:11:32 Arnd Bergmann wrote:
> > > --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> > > +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> > > @@ -34,7 +34,11 @@ Properties of the host controller node:
> > >  - #size-cells: Must be 2.
> > >  
> > >  - reg: The Configuration Space base address and size, as 
> > > accessed
> > > -   from the parent bus.
> > > +   from the parent bus.  The base address corresponds to
> > > +   bus zero, even though the "bus-range" property may 
> > > specify
> > > +   a different starting bus number.  The driver must 
> > > only map
> > > +   or access the portion of the Configuration Space that
> > > +   corresponds to the "bus-range"
> 
> I thought we had reached an agreement that it is a bad idea to have a 'reg'
> property that lists registers belonging to a different device.
> 
> 

To further clarify: the argument was to make it mirror what ACPI does for
PCI. However, this is unlike what all other devices do with DT, where you
have non-overlapping register ranges (start, length) for each device.
ACPI as far as I understand it does not give a range for a PCIe host, but
instead provides a way to get the start address of the ECAM register area
for the domain that the host is part of, and that needs to be the same
address for each host in the domain.

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 v4 4/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Arnd Bergmann]

On Thursday 08 October 2015 10:02:43 Bjorn Helgaas wrote:
> [+cc Arnd]
> 
> And this one?

Not so good.

> > --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> > @@ -34,7 +34,11 @@ Properties of the host controller node:
> >  - #size-cells: Must be 2.
> >  
> >  - reg: The Configuration Space base address and size, as 
> > accessed
> > -   from the parent bus.
> > +   from the parent bus.  The base address corresponds to
> > +   bus zero, even though the "bus-range" property may 
> > specify
> > +   a different starting bus number.  The driver must only 
> > map
> > +   or access the portion of the Configuration Space that
> > +   corresponds to the "bus-range"

I thought we had reached an agreement that it is a bad idea to have a 'reg'
property that lists registers belonging to a different device.

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 v4 5/8] clk: rockchip: Allow the RK3288 SPDIF clocks to change their parent

[Heiko Stuebner]

Am Donnerstag, 8. Oktober 2015, 15:31:16 schrieb Sjoerd Simons:
> The clock branches leading to sclk_spdif and sclk_spdif_8ch on RK3288
> SoCs only feed those clocks, allow those clocks to change their parents
> all the way up the hierarchy.
> 
> Signed-off-by: Sjoerd Simons 

Just as comment, if I'm seeing that right, this patch needs "clk: rockchip: 
handle mux dependency of fractional dividers" and friends [0] to apply and 
also actually handle the fractional dividers correctly.

For the clock change itself:
Reviewed-by: Heiko Stuebner 


Heiko

[0] http://lists.infradead.org/pipermail/linux-rockchip/2015-August/003930.html


> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/rockchip/clk-rk3288.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c index 90c1c9b..4e90252 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -317,25 +317,25 @@ static struct rockchip_clk_branch
> rk3288_clk_branches[] __initdata = {
> 
>   MUX(0, "spdif_src", mux_pll_src_cpll_gpll_p, 0,
>   RK3288_CLKSEL_CON(5), 15, 1, MFLAGS),
> - COMPOSITE_NOMUX(0, "spdif_pre", "spdif_src", 0,
> + COMPOSITE_NOMUX(0, "spdif_pre", "spdif_src", CLK_SET_RATE_PARENT,
>   RK3288_CLKSEL_CON(5), 0, 7, DFLAGS,
>   RK3288_CLKGATE_CON(4), 4, GFLAGS),
> - COMPOSITE_FRACMUX(0, "spdif_frac", "spdif_src", 0,
> + COMPOSITE_FRACMUX(0, "spdif_frac", "spdif_src", CLK_SET_RATE_PARENT,
>   RK3288_CLKSEL_CON(9), 0,
>   RK3288_CLKGATE_CON(4), 5, GFLAGS,
> - MUX(0, "spdif_mux", mux_spdif_p, 0,
> + MUX(0, "spdif_mux", mux_spdif_p, CLK_SET_RATE_PARENT,
>   RK3288_CLKSEL_CON(5), 8, 2, MFLAGS)),
> - GATE(SCLK_SPDIF, "sclk_spdif", "spdif_mux", 0,
> + GATE(SCLK_SPDIF, "sclk_spdif", "spdif_mux", CLK_SET_RATE_PARENT,
>   RK3288_CLKGATE_CON(4), 6, GFLAGS),
> - COMPOSITE_NOMUX(0, "spdif_8ch_pre", "spdif_src", 0,
> + COMPOSITE_NOMUX(0, "spdif_8ch_pre", "spdif_src", CLK_SET_RATE_PARENT,
>   RK3288_CLKSEL_CON(40), 0, 7, DFLAGS,
>   RK3288_CLKGATE_CON(4), 7, GFLAGS),
> - COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_pre", 0,
> + COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_pre",
> CLK_SET_RATE_PARENT, RK3288_CLKSEL_CON(41), 0,
>   RK3288_CLKGATE_CON(4), 8, GFLAGS,
> - MUX(0, "spdif_8ch_mux", mux_spdif_8ch_p, 0,
> + MUX(0, "spdif_8ch_mux", mux_spdif_8ch_p, CLK_SET_RATE_PARENT,
>   RK3288_CLKSEL_CON(40), 8, 2, MFLAGS)),
> - GATE(SCLK_SPDIF8CH, "sclk_spdif_8ch", "spdif_8ch_mux", 0,
> + GATE(SCLK_SPDIF8CH, "sclk_spdif_8ch", "spdif_8ch_mux",
> CLK_SET_RATE_PARENT, RK3288_CLKGATE_CON(4), 9, GFLAGS),
> 
>   GATE(0, "sclk_acc_efuse", "xin24m", 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 v4 3/5] PCI: generic: Quit clobbering our pci_ops.

[Arnd Bergmann]

On Thursday 08 October 2015 10:02:16 Bjorn Helgaas wrote:
> [+cc Arnd]
> 
> Arnd, you had comments on the previous version.  What do you think of
> this one?

Looks good to me

> On Fri, Oct 02, 2015 at 11:44:01AM -0700, David Daney wrote:
> > From: David Daney 
> > 
> > The pci-host-generic driver keeps a global struct pci_ops which it
> > then patches with the .map_bus method appropriate for the bus device.
> > A problem arises when the driver is used for two different types of
> > bus devices, the .map_bus method for the last device probed clobbers
> > the method for all previous devices.  The result, only the last bus
> > device probed has the proper .map_bus, and the others fail.
> > 
> > Move the struct pci_ops into the bus specific structure, and
> > initialize a pointer to it when the bus device is probed.
> > 
> > Acked-by: Will Deacon 
> > Signed-off-by: David Daney 
> 

Reviewed-by: Arnd Bergmann 
--
To unsubscribe from this list: send the line "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] QEMU fw_cfg DMA interface documentation

[Marc Marí]

Add fw_cfg DMA interface specfication in the fw_cfg documentation.

Signed-off-by: Marc Marí 
---
 Documentation/devicetree/bindings/arm/fw-cfg.txt | 52 +++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt 
b/Documentation/devicetree/bindings/arm/fw-cfg.txt
index 953fb64..0633aad 100644
--- a/Documentation/devicetree/bindings/arm/fw-cfg.txt
+++ b/Documentation/devicetree/bindings/arm/fw-cfg.txt
@@ -38,6 +38,9 @@ The presence of the registers can be verified by selecting 
the "signature" blob
 with key 0x, and reading four bytes from the data register. The returned
 signature is "QEMU".
 
+If the DMA interface is available, then reading the DMA Address Register
+returns 0x51454d5520434647 ("QEMU CFG" in big-endian format).
+
 The outermost protocol (involving the write / read sequences of the control and
 data registers) is expected to be versioned, and/or described by feature bits.
 The interface revision / feature bitmap can be retrieved with key 0x0001. The
@@ -45,6 +48,51 @@ blob to be read from the data register has size 4, and it is 
to be interpreted
 as a uint32_t value in little endian byte order. The current value
 (corresponding to the above outer protocol) is zero.
 
+If bit 1 of the feature bitmap is set, the DMA interface is present. This
+can be used through the 64-bit wide address register.
+
+The address register is in big-endian format. The value for the register is 0
+at startup and after an operation. A write to the lower half triggers an
+operation. This means, that operations with 32-bit addresses can be triggered
+with just one write, whereas operations with 64-bit addresses can be triggered
+with one 64-bit write or two 32-bit writes, starting with the higher part.
+
+In this register, the physical address of a FWCfgDmaAccess structure in RAM
+should be written. This is the format of the FWCfgDmaAccess structure:
+
+typedef struct FWCfgDmaAccess {
+uint32_t control;
+uint32_t length;
+uint64_t address;
+} FWCfgDmaAccess;
+
+The fields of the structure are in big endian mode, and the field at the lowest
+address is the "control" field.
+
+The "control" field has the following bits:
+ - Bit 0: Error
+ - Bit 1: Read
+ - Bit 2: Skip
+ - Bit 3: Select. The upper 16 bits are the selected index.
+
+When an operation is triggered, if the "control" field has bit 3 set, the
+upper 16 bits are interpreted as an index of a firmware configuration item.
+This has the same effect as writing the selector register.
+
+If the "control" field has bit 1 set, a read operation will be performed.
+"length" bytes for the current selector and offset will be copied into the
+physical RAM address specified by the "address" field.
+
+If the "control" field has bit 2 set (and not bit 1), a skip operation will be
+performed. The offset for the current selector will be advanced "length" bytes.
+
+To check the result, read the "control" field:
+   error bit set->  something went wrong.
+   all bits cleared ->  transfer finished successfully.
+   otherwise->  transfer still in progress (doesn't happen
+today due to implementation not being async,
+but may in the future).
+
 The guest kernel is not expected to use these registers (although it is
 certainly allowed to); the device tree bindings are documented here because
 this is where device tree bindings reside in general.
@@ -56,6 +104,8 @@ Required properties:
 - reg: the MMIO region used by the device.
   * Bytes 0x0 to 0x7 cover the data register.
   * Bytes 0x8 to 0x9 cover the selector register.
+  * With DMA interface enabled: Bytes 0x10 to 0x17 cover the DMA address
+register.
   * Further registers may be appended to the region in case of future interface
 revisions / feature bits.
 
@@ -66,7 +116,7 @@ Example:
#address-cells = <0x2>;
 
fw-cfg@902 {
+   reg = <0x0 0x902 0x0 0x18>;
compatible = "qemu,fw-cfg-mmio";
-   reg = <0x0 0x902 0x0 0xa>;
};
 };
-- 
2.4.3

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

[cross-post] QEMU fw_cfg DMA interface

[Marc Marí]

Implementation of the FW CFG DMA interface.

When running a Linux guest on top of QEMU, using the -kernel option and with
fw_cfg DMA Linux boot support, this is the timing improvement for x86:

Original QEMU and SeaBIOS
QEMU startup time: .080
BIOS startup time: .060
Kernel setup time: .586
Total time: .726

QEMU and SeaBIOS with this patch series and fw_cfg DMA Linux boot support
QEMU startup time: .080
BIOS startup time: .039
Kernel setup time: .005
Total time: .126

QEMU startup time is the time between the start and the first kvm_entry.
BIOS startup time is the time between the first kvm_entry and the start of
function do_boot, in SeaBIOS.
Kernel setup time is the time between the start of the function do_boot in
SeaBIOS and the jump to the Linux kernel.

As you can see, both the BIOS (because of ACPI tables and other configurations)
and the Linux kernel boot (because of the copy to memory) are greatly
improved with this new interface.

Also, this new interface is an addon to the old interface. Both interfaces
are compatible and interchangeable.

Changes from v1:
 - Take into account order of fields in the FWCfgDmaAccess structure
 - Check and change endianness of FWCfgDmaAccess fields
 - Change order of fields in the FWCfgDmaAccess structure
 - Add FW_CFG_DMA_CTL_SKIP feature for control field
 - Split FW_CFG_SIZE in QEMU
 - Make FW_CFG_ID a bitmap of features
 - Add 64 bit address support for the transfer. Trigger when writing the low
   address, and address is 0 by default and at the end of each transfer.
 - Align ports and addresses.
 - Preserve old fw_cfg_comb_valid behaviour in QEMU
 - Update documentation to reflect all these changes

Changes from v2:
 - Make IOports fw_cfg DMA region a different IO region.
 - Reuse everything for MMIO and IOport DMA regions
 - Make transfer status only based on control field
 - Use DMA helpers instead of direct map/unmap
 - Change ARM fw_cfg DMA address space
 - Change Linux boot process to match linuxboot.S
 - Add select capabilities in the FWCfgDmaAccess struct
 - Update documentation to reflect all these changes

Changes from v3:
 - Set properly fw_cfg DMA fields in ARM
 - Set fw_cfg DMA boot process properly (by Laszlo Ersek)
 - Add signature to fw_cfg DMA address field (by Kevin O'Connor)
 - Minor nitpicks

Changes from v4:
 - Remove Linux fw_cfg boot from this series (will be sent separately)
 - Minor nitpicks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Bjorn Helgaas]

[+cc Arnd]

And this one?

On Fri, Oct 02, 2015 at 11:44:02AM -0700, David Daney wrote:
> From: David Daney 
> 
> There are two problems with the bus_max calculation:
> 
> 1) The u8 data type can overflow for large config space windows.
> 
> 2) The calculation is incorrect for a bus range that doesn't start at
>zero.
> 
> Since the configuration space is relative to bus zero, make bus_max
> just be the size of the config window scaled by bus_shift.  Then clamp
> it to a maximum of 255, per PCI.  Use a data type of int to avoid
> overflow problems.
> 
> Update host-generic-pci.txt to clarify the semantics of the "reg"
> property with respect to non-zero starting bus numbers.
> 
> Signed-off-by: David Daney 
> ---
> Change from V3: Add to explanation of "reg" property in
> host-generic-pci.txt.  Add error message if "reg" property is too big.
> 
>  Documentation/devicetree/bindings/pci/host-generic-pci.txt |  6 +-
>  drivers/pci/host/pci-host-generic.c| 12 +---
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt 
> b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> index cf3e205..42303bb 100644
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> @@ -34,7 +34,11 @@ Properties of the host controller node:
>  - #size-cells: Must be 2.
>  
>  - reg: The Configuration Space base address and size, as accessed
> -   from the parent bus.
> +   from the parent bus.  The base address corresponds to
> +   bus zero, even though the "bus-range" property may specify
> +   a different starting bus number.  The driver must only map
> +   or access the portion of the Configuration Space that
> +   corresponds to the "bus-range"
>  
>  
>  Properties of the /chosen node:
> diff --git a/drivers/pci/host/pci-host-generic.c 
> b/drivers/pci/host/pci-host-generic.c
> index 216ded5..5cce837 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -164,7 +164,7 @@ out_release_res:
>  static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
>  {
>   int err;
> - u8 bus_max;
> + int bus_max;
>   resource_size_t busn;
>   struct resource *bus_range;
>   struct device *dev = pci->host.dev.parent;
> @@ -177,8 +177,14 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci 
> *pci)
>   }
>  
>   /* Limit the bus-range to fit within reg */
> - bus_max = pci->cfg.bus_range->start +
> -   (resource_size(&pci->cfg.res) >> pci->cfg.ops->bus_shift) - 1;
> + bus_max = (resource_size(&pci->cfg.res) >> pci->cfg.ops->bus_shift) - 1;
> + if (bus_max > 255) {
> + dev_err(dev,
> + "\"reg\" size corresponds to bus %d, truncating to 
> 255\n",
> + bus_max);
> + bus_max = 255;
> + }
> +
>   pci->cfg.bus_range->end = min_t(resource_size_t,
>   pci->cfg.bus_range->end, bus_max);
>  
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] PCI: generic: Quit clobbering our pci_ops.

[Bjorn Helgaas]

[+cc Arnd]

Arnd, you had comments on the previous version.  What do you think of
this one?

On Fri, Oct 02, 2015 at 11:44:01AM -0700, David Daney wrote:
> From: David Daney 
> 
> The pci-host-generic driver keeps a global struct pci_ops which it
> then patches with the .map_bus method appropriate for the bus device.
> A problem arises when the driver is used for two different types of
> bus devices, the .map_bus method for the last device probed clobbers
> the method for all previous devices.  The result, only the last bus
> device probed has the proper .map_bus, and the others fail.
> 
> Move the struct pci_ops into the bus specific structure, and
> initialize a pointer to it when the bus device is probed.
> 
> Acked-by: Will Deacon 
> Signed-off-by: David Daney 
> ---
> Change from v3: Use pointer to ops rather than make a copy.
> 
>  drivers/pci/host/pci-host-generic.c | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-host-generic.c 
> b/drivers/pci/host/pci-host-generic.c
> index 9e9f1c3..216ded5 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -27,7 +27,7 @@
>  
>  struct gen_pci_cfg_bus_ops {
>   u32 bus_shift;
> - void __iomem *(*map_bus)(struct pci_bus *, unsigned int, int);
> + struct pci_ops ops;
>  };
>  
>  struct gen_pci_cfg_windows {
> @@ -35,7 +35,7 @@ struct gen_pci_cfg_windows {
>   struct resource *bus_range;
>   void __iomem**win;
>  
> - const struct gen_pci_cfg_bus_ops*ops;
> + struct gen_pci_cfg_bus_ops  *ops;
>  };
>  
>  /*
> @@ -65,7 +65,11 @@ static void __iomem *gen_pci_map_cfg_bus_cam(struct 
> pci_bus *bus,
>  
>  static struct gen_pci_cfg_bus_ops gen_pci_cfg_cam_bus_ops = {
>   .bus_shift  = 16,
> - .map_bus= gen_pci_map_cfg_bus_cam,
> + .ops= {
> + .map_bus= gen_pci_map_cfg_bus_cam,
> + .read   = pci_generic_config_read,
> + .write  = pci_generic_config_write,
> + }
>  };
>  
>  static void __iomem *gen_pci_map_cfg_bus_ecam(struct pci_bus *bus,
> @@ -80,12 +84,11 @@ static void __iomem *gen_pci_map_cfg_bus_ecam(struct 
> pci_bus *bus,
>  
>  static struct gen_pci_cfg_bus_ops gen_pci_cfg_ecam_bus_ops = {
>   .bus_shift  = 20,
> - .map_bus= gen_pci_map_cfg_bus_ecam,
> -};
> -
> -static struct pci_ops gen_pci_ops = {
> - .read   = pci_generic_config_read,
> - .write  = pci_generic_config_write,
> + .ops= {
> + .map_bus= gen_pci_map_cfg_bus_ecam,
> + .read   = pci_generic_config_read,
> + .write  = pci_generic_config_write,
> + }
>  };
>  
>  static const struct of_device_id gen_pci_of_match[] = {
> @@ -234,8 +237,7 @@ static int gen_pci_probe(struct platform_device *pdev)
>   }
>  
>   of_id = of_match_node(gen_pci_of_match, np);
> - pci->cfg.ops = of_id->data;
> - gen_pci_ops.map_bus = pci->cfg.ops->map_bus;
> + pci->cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
>   pci->host.dev.parent = dev;
>   INIT_LIST_HEAD(&pci->host.windows);
>   INIT_LIST_HEAD(&pci->resources);
> @@ -256,7 +258,8 @@ static int gen_pci_probe(struct platform_device *pdev)
>   if (!pci_has_flag(PCI_PROBE_ONLY))
>   pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
>  
> - bus = pci_scan_root_bus(dev, 0, &gen_pci_ops, pci, &pci->resources);
> + bus = pci_scan_root_bus(dev, 0,
> + &pci->cfg.ops->ops, pci, &pci->resources);
>   if (!bus) {
>   dev_err(dev, "Scanning rootbus failed");
>   return -ENODEV;
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 4/5] xhci: mediatek: support MTK xHCI host controller

[chunfeng yun]

Hi,
On Thu, 2015-10-08 at 16:05 +0300, Mathias Nyman wrote:
> On 08.10.2015 15:28, Daniel Thompson wrote:
> > On 08/10/15 13:05, chunfeng yun wrote:
> >> Hi,
> >> On Thu, 2015-10-01 at 12:44 +0100, Daniel Thompson wrote:
> >>> On 29/09/15 04:01, Chunfeng Yun wrote:
>  There some vendor quirks for MTK xhci host controller:
>  1. It defines some extra SW scheduling parameters for HW
>  to minimize the scheduling effort for synchronous and
>  interrupt endpoints. The parameters are put into reseved
>  DWs of slot context and endpoint context.
>  2. Its IMODI unit for Interrupter Moderation register is
>  8 times as much as that defined in xHCI spec.
>  3. Its TDS in  Normal TRB defines a number of packets that
>  remains to be transferred for a TD after processing all
>  Max packets in all previous TRBs.
> 
>  Signed-off-by: Chunfeng Yun 
> >>>
> >>> I've done some basic soak tests, both with a directly attached USB3 HDD
> >>> and, given the extra code to manage isochronous xfer, also with a hub,
> >>> disc and two audio interfaces.
> >>>
> >>> Tested-by: Daniel Thompson 
> >>>
> >>>
>  diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>  index 57f40a1..243f696 100644
>  --- a/drivers/usb/host/xhci-ring.c
>  +++ b/drivers/usb/host/xhci-ring.c
>  @@ -68,6 +68,7 @@
> #include 
> #include "xhci.h"
> #include "xhci-trace.h"
>  +#include "xhci-mtk.h"
> 
> /*
>  * Returns zero if the TRB isn't in this segment, otherwise it 
>  returns the DMA
>  @@ -3044,18 +3045,27 @@ static u32 xhci_td_remainder(struct xhci_hcd 
>  *xhci, int transferred,
>   struct urb *urb, unsigned int num_trbs_left)
> {
> u32 maxp, total_packet_count;
>  +u32 skip_current_trb = 0;
> >>>
> >>> A bit of a nitpick but why do we need skip_current_trb? Testing
> >>> (xhci->quirks & XHCI_MTK_HOST) twice would make what the code does, and
> >>> why, more obvious.
> >>>
> >> I am not sure which way it is better, so add variable of
> >> skip_current_trb to reduce test times.
> >
> > I can't imagine either approach impacts performance. However introducing 
> > skip_current_trb makes the flow of the branches harder to follow.
> >
> > The first branch was a version check and can remain so; we only need to do 
> > something special with the quirks because the MTK controller is 0.97 but 
> > with a few bits added:
> >
> >  /* MTK xHCI is mostly 0.97 but contains some features from 1.0 */
> >  if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
> >  return ...
> >
> > Setting trb_buff_len to zero is accommodating a quirk and this is clearer 
> > when we have:
> >
> >  /* for MTK xHCI, TD size doesn't include this TRB */
> >  if (xhci->quirks & XHCI_MTK_HOST)
> >  trb_buff_len = 0;
> 
> Both will work, but I'd prefer this solution as well.
> 
Thanks for your suggestion as well

> -Mathias
> 


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

Re: [PATCH v8 4/6] pci: altera: Add Altera PCIe MSI driver

[kbuild test robot]

Hi Ley,

[auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore]

config: sparc-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/of_pci.h:5:0,
from drivers/pci//host/pcie-altera.c:22:
>> include/linux/msi.h:199:10: error: unknown type name 'msi_alloc_info_t'
 msi_alloc_info_t *arg);
 ^
   include/linux/msi.h:203:9: error: unknown type name 'msi_alloc_info_t'
msi_alloc_info_t *arg);
^
   include/linux/msi.h:212:12: error: unknown type name 'msi_alloc_info_t'
   msi_alloc_info_t *arg);
   ^
   include/linux/msi.h:213:22: error: unknown type name 'msi_alloc_info_t'
 void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
 ^
   include/linux/msi.h:214:20: error: unknown type name 'msi_alloc_info_t'
 void  (*set_desc)(msi_alloc_info_t *arg,
   ^
   drivers/pci//host/pcie-altera.c: In function 'tlp_cfg_dword_read':
   drivers/pci//host/pcie-altera.c:243:12: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]
  *value = ~0UL; /* return 0x if error */
   ^
   drivers/pci//host/pcie-altera.c: In function 'altera_pcie_cfg_read':
   drivers/pci//host/pcie-altera.c:291:12: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]
  *value = ~0UL;
   ^
   drivers/pci//host/pcie-altera.c: In function 
'altera_pcie_parse_request_of_pci_ranges':
   drivers/pci//host/pcie-altera.c:410:2: error: implicit declaration of 
function 'of_pci_get_host_bridge_resources' 
[-Werror=implicit-function-declaration]
 err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pcie->resources,
 ^
   cc1: some warnings being treated as errors
--
   In file included from drivers/pci//host/pcie-altera-msi.c:19:0:
>> include/linux/msi.h:199:10: error: unknown type name 'msi_alloc_info_t'
 msi_alloc_info_t *arg);
 ^
   include/linux/msi.h:203:9: error: unknown type name 'msi_alloc_info_t'
msi_alloc_info_t *arg);
^
   include/linux/msi.h:212:12: error: unknown type name 'msi_alloc_info_t'
   msi_alloc_info_t *arg);
   ^
   include/linux/msi.h:213:22: error: unknown type name 'msi_alloc_info_t'
 void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
 ^
   include/linux/msi.h:214:20: error: unknown type name 'msi_alloc_info_t'
 void  (*set_desc)(msi_alloc_info_t *arg,
   ^
--
   In file included from drivers/base/platform-msi.c:24:0:
>> include/linux/msi.h:199:10: error: unknown type name 'msi_alloc_info_t'
 msi_alloc_info_t *arg);
 ^
   include/linux/msi.h:203:9: error: unknown type name 'msi_alloc_info_t'
msi_alloc_info_t *arg);
^
   include/linux/msi.h:212:12: error: unknown type name 'msi_alloc_info_t'
   msi_alloc_info_t *arg);
   ^
   include/linux/msi.h:213:22: error: unknown type name 'msi_alloc_info_t'
 void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
 ^
   include/linux/msi.h:214:20: error: unknown type name 'msi_alloc_info_t'
 void  (*set_desc)(msi_alloc_info_t *arg,
   ^
   drivers/base/platform-msi.c: In function 'platform_msi_update_dom_ops':
>> drivers/base/platform-msi.c:80:9: error: 'struct msi_domain_ops' has no 
>> member named 'msi_init'
 if (ops->msi_init == NULL)
^
   drivers/base/platform-msi.c:81:6: error: 'struct msi_domain_ops' has no 
member named 'msi_init'
  ops->msi_init = platform_msi_init;
 ^
>> drivers/base/platform-msi.c:82:9: error: 'struct msi_domain_ops' has no 
>> member named 'set_desc'
 if (ops->set_desc == NULL)
^
   drivers/base/platform-msi.c:83:6: error: 'struct msi_domain_ops' has no 
member named 'set_desc'
  ops->set_desc = platform_msi_set_desc;
 ^
--
   In file included from drivers/pci/msi.c:17:0:
>> include/linux/msi.h:199:10: error: unknown type name 'msi_alloc_info_t'
 msi_alloc_info_t *arg);
 ^
   include/linux/msi.h:203:9: error: unknown type name 'msi_alloc_info_t'
msi_alloc_info_t *arg);
^
   include/linux/msi.h:212:12: error: unknown type name 'msi_alloc_info_t'
   msi_alloc_info_t *arg);
   ^
   include/linux/msi.h:213:22: error: unknown type name 'msi_alloc_info_t'
 void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
 ^
   include/linux/msi.h:214:20: error: unknown type name 'msi_alloc_info_t'
 void  (*set_desc

Re: [PATCH v9 4/5] xhci: mediatek: support MTK xHCI host controller

[chunfeng yun]

On Thu, 2015-10-08 at 13:28 +0100, Daniel Thompson wrote:
> On 08/10/15 13:05, chunfeng yun wrote:
> > Hi,
> > On Thu, 2015-10-01 at 12:44 +0100, Daniel Thompson wrote:
> >> On 29/09/15 04:01, Chunfeng Yun wrote:
> >>> There some vendor quirks for MTK xhci host controller:
> >>> 1. It defines some extra SW scheduling parameters for HW
> >>> to minimize the scheduling effort for synchronous and
> >>> interrupt endpoints. The parameters are put into reseved
> >>> DWs of slot context and endpoint context.
> >>> 2. Its IMODI unit for Interrupter Moderation register is
> >>> 8 times as much as that defined in xHCI spec.
> >>> 3. Its TDS in  Normal TRB defines a number of packets that
> >>> remains to be transferred for a TD after processing all
> >>> Max packets in all previous TRBs.
> >>>
> >>> Signed-off-by: Chunfeng Yun 
> >>
> >> I've done some basic soak tests, both with a directly attached USB3 HDD
> >> and, given the extra code to manage isochronous xfer, also with a hub,
> >> disc and two audio interfaces.
> >>
> >> Tested-by: Daniel Thompson 
> >>
> >>
> >>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> >>> index 57f40a1..243f696 100644
> >>> --- a/drivers/usb/host/xhci-ring.c
> >>> +++ b/drivers/usb/host/xhci-ring.c
> >>> @@ -68,6 +68,7 @@
> >>>#include 
> >>>#include "xhci.h"
> >>>#include "xhci-trace.h"
> >>> +#include "xhci-mtk.h"
> >>>
> >>>/*
> >>> * Returns zero if the TRB isn't in this segment, otherwise it returns 
> >>> the DMA
> >>> @@ -3044,18 +3045,27 @@ static u32 xhci_td_remainder(struct xhci_hcd 
> >>> *xhci, int transferred,
> >>> struct urb *urb, unsigned int 
> >>> num_trbs_left)
> >>>{
> >>>   u32 maxp, total_packet_count;
> >>> + u32 skip_current_trb = 0;
> >>
> >> A bit of a nitpick but why do we need skip_current_trb? Testing
> >> (xhci->quirks & XHCI_MTK_HOST) twice would make what the code does, and
> >> why, more obvious.
> >>
> > I am not sure which way it is better, so add variable of
> > skip_current_trb to reduce test times.
> 
> I can't imagine either approach impacts performance. However introducing 
> skip_current_trb makes the flow of the branches harder to follow.
> 
> The first branch was a version check and can remain so; we only need to 
> do something special with the quirks because the MTK controller is 0.97 
> but with a few bits added:
> 
>  /* MTK xHCI is mostly 0.97 but contains some features from 1.0 */
>  if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
>   return ...
> 
> Setting trb_buff_len to zero is accommodating a quirk and this is 
> clearer when we have:
> 
>  /* for MTK xHCI, TD size doesn't include this TRB */
>  if (xhci->quirks & XHCI_MTK_HOST)
>   trb_buff_len = 0;
> 
I will revise the code according to your suggestion, thanks

> 
> >> Anyhow with that looked at, and the caveat that I'm not much of USB
> >> expert, you're welcome to add my Reviewed-by: to v10.
> >>
> >
> > Thanks a lot
> 
> No worries.
> 


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

Re: [PATCH v8 0/9] Goodix touchscreen enhancements

[Arnd Bergmann]

On Thursday 08 October 2015 17:23:42 Irina Tirdea wrote:
> Add several enhancements to the Goodix touchscreen driver.
> 
> The new functionality is only available for devices that
> declare named gpio pins for interrupt and reset in their
> ACPI/DT configuration.
> 
> Thanks,
> Irina
> 
> Changes in v8:
>  - only allow new functionality for devices that declare named
> gpios (using _DSD properties in ACPI or named DT properties)
> 
> 

Looks much cleaner this way, thanks!

One remaining question: how would you handle the case where
the hardware doesn't support configuring the int-gpios line
as output but you still want to use the named gpios?

I assume you have that case covered, but I don't see it immediately.

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

[PATCH v8 1/9] Input: goodix - use actual config length for each device type

[Irina Tirdea]

Each of the Goodix devices supported by this driver has a fixed size for
the configuration information registers. The size varies depending on the
device and is specified in the datasheet.

Use the proper configuration length as specified in the datasheet for
each device model, so we do not read more than the actual size of the
configuration registers.

Signed-off-by: Irina Tirdea 
Acked-by: Bastien Nocera 
---
 drivers/input/touchscreen/goodix.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 4d113c9..56d0330 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -36,6 +36,7 @@ struct goodix_ts_data {
unsigned int max_touch_num;
unsigned int int_trigger_type;
bool rotated_screen;
+   int cfg_len;
 };
 
 #define GOODIX_MAX_HEIGHT  4096
@@ -45,6 +46,8 @@ struct goodix_ts_data {
 #define GOODIX_MAX_CONTACTS10
 
 #define GOODIX_CONFIG_MAX_LENGTH   240
+#define GOODIX_CONFIG_911_LENGTH   186
+#define GOODIX_CONFIG_967_LENGTH   228
 
 /* Register defines */
 #define GOODIX_READ_COOR_ADDR  0x814E
@@ -115,6 +118,23 @@ static int goodix_i2c_read(struct i2c_client *client,
return ret < 0 ? ret : (ret != ARRAY_SIZE(msgs) ? -EIO : 0);
 }
 
+static int goodix_get_cfg_len(u16 id)
+{
+   switch (id) {
+   case 911:
+   case 9271:
+   case 9110:
+   case 927:
+   case 928:
+   return GOODIX_CONFIG_911_LENGTH;
+   case 912:
+   case 967:
+   return GOODIX_CONFIG_967_LENGTH;
+   default:
+   return GOODIX_CONFIG_MAX_LENGTH;
+   }
+}
+
 static int goodix_ts_read_input_report(struct goodix_ts_data *ts, u8 *data)
 {
int touch_num;
@@ -230,8 +250,7 @@ static void goodix_read_config(struct goodix_ts_data *ts)
int error;
 
error = goodix_i2c_read(ts->client, GOODIX_REG_CONFIG_DATA,
-   config,
-   GOODIX_CONFIG_MAX_LENGTH);
+   config, ts->cfg_len);
if (error) {
dev_warn(&ts->client->dev,
 "Error reading config (%d), using defaults\n",
@@ -398,6 +417,8 @@ static int goodix_ts_probe(struct i2c_client *client,
return error;
}
 
+   ts->cfg_len = goodix_get_cfg_len(id_info);
+
goodix_read_config(ts);
 
error = goodix_request_input_dev(ts, version_info, id_info);
-- 
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 v8 2/9] Input: goodix - reset device at init

[Irina Tirdea]

After power on, it is recommended that the driver resets the device.
The reset procedure timing is described in the datasheet and is used
at device init (before writing device configuration) and
for power management. It is a sequence of setting the interrupt
and reset pins high/low at specific timing intervals. This procedure
also includes setting the slave address to the one specified in the
ACPI/device tree.

This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
driver gt9xx.c for Android (publicly available in Android kernel
trees for various devices).

For reset the driver needs to control the interrupt and
reset gpio pins (configured through ACPI/device tree). For devices
that do not have the gpio pins properly declared, the functionality
depending on these pins will not be available, but the device can still
be used with basic functionality.

For both device tree and ACPI, the interrupt gpio pin configuration is
read from the "irq-gpio" property and the reset pin configuration is
read from the "reset-gpio" property. For ACPI 5.1, named properties
can be specified using the _DSD section. This functionality will not be
available for devices that use indexed gpio pins declared in the _CRS
section (we need to provide backward compatibility with devices
that do not support using the interrupt gpio pin as output).

For ACPI, the pins can be specified using ACPI 5.1:
Device (STAC)
{
Name (_HID, "GDIX1001")
...

Method (_CRS, 0, Serialized)
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\I2C0",
0x00, ResourceConsumer, ,
)

GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
"\\I2C0", 0x00, ResourceConsumer, ,
 )
 {   // Pin list
 0
 }

GpioIo (Exclusive, PullDown, 0x, 0x,
IoRestrictionOutputOnly, "\\I2C0", 0x00,
ResourceConsumer, ,
)
{
 1
}
})
Return (RBUF)
}

Name (_DSD,  Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
...
}
}

Signed-off-by: Octavian Purdila 
Signed-off-by: Irina Tirdea 
---
 .../bindings/input/touchscreen/goodix.txt  |   5 +
 drivers/input/touchscreen/goodix.c | 101 +
 2 files changed, 106 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt 
b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index 8ba98ee..7137881 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -12,6 +12,8 @@ Required properties:
  - reg : I2C address of the chip. Should be 0x5d or 0x14
  - interrupt-parent: Interrupt controller to which the chip is connected
  - interrupts  : Interrupt to which the chip is connected
+ - irq-gpio: GPIO pin used for IRQ
+ - reset-gpio  : GPIO pin used for reset
 
 Example:
 
@@ -23,6 +25,9 @@ Example:
reg = <0x5d>;
interrupt-parent = <&gpio>;
interrupts = <0 0>;
+
+   irq-gpio = <&gpio1 0 0>;
+   reset-gpio = <&gpio1 1 0>;
};
 
/* ... */
diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 56d0330..87304ac 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,8 +38,13 @@ struct goodix_ts_data {
unsigned int int_trigger_type;
bool rotated_screen;
int cfg_len;
+   struct gpio_desc *gpiod_int;
+   struct gpio_desc *gpiod_rst;
 };
 
+#define GOODIX_GPIO_INT_NAME   "irq"
+#define GOODIX_GPIO_RST_NAME   "reset"
+
 #define GOODIX_MAX_HEIGHT  4096
 #define GOODIX_MAX_WIDTH   4096
 #define GOODIX_INT_TRIGGER 1
@@ -237,6 +243,88 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
+static int goodix_int_sync(struct goodix_ts_data *ts)
+{
+   int error;
+
+   error = gpiod_direction_output(ts->gpiod_int, 0);
+   if (error)
+   return error;
+   msleep(50); /* T5: 50ms */
+
+   return gpiod_direction_input(ts->gpiod_int);
+}
+
+/**
+ * goodix_reset - Reset device during power on
+ *
+ * @ts: goodix_ts_data pointer
+ */
+static int goodix_reset(stru

[PATCH v8 0/9] Goodix touchscreen enhancements

[Irina Tirdea]

Add several enhancements to the Goodix touchscreen driver.

The new functionality is only available for devices that
declare named gpio pins for interrupt and reset in their
ACPI/DT configuration.

Thanks,
Irina

Changes in v8:
 - only allow new functionality for devices that declare named
gpios (using _DSD properties in ACPI or named DT properties)

Changes in v7:
 - add dmi quirk to skip gpio pins setup and functionality that
depends on them for Onda v975w, WinBook TW100 and WinBook TW700.
 - add support for named gpio pins
 - rework the runtime pm patch to fix a couple of issues
 - sort includes using inverse Xmas tree ordering

Changes in v6:
 - skip runtime power manangent calls in open/close if the device
ACPI/DT configuration does not declare interrupt and reset gpio pins.
 - reset the device before starting i2c communication
 - add Bastien's ack to the first 2 patches

Changes in v5:
 - add some more style cleanup (reorder includes, use error instead
of ret for return values)
 - add runtime power management patch

Changes in v4:
 - use dmi quirk to determine the order of irq and reset pins
 - use actual config length depending on device
 - add sysfs interface to dump config
 - initialize esd timeout from ACPI/DT properly

Changes in v3:
 - dropped the first 3 patches that got merged
 - handle -EPROBE_DEFER and -ENOENT for gpio pins
 - skip functionality depending on the gpio pins if the pins are not
properly initialized from ACPI/DT (reset, write config, power management,
ESD)
 - dropped #ifdef CONFIG_PM_SLEEP and annotated with __maybe_unused instead
 - use sysfs property to set ESD timeout instead of ACPI/DT property
 - use request_firmware_nowait to read configuration firmware and use
defaults if firmware is not found
 - use ACPI IDs to determine the order of the GPIO pins in the ACPI tables
(interrupt pin first or reset pin first)

Changes in v2:
 - use request_firmware instead of ACPI/DT property for config
 - dropped "input: goodix: add ACPI IDs for GT911 and GT9271" patch
 - add ACPI DSDT excerpt in commit message where necessary
 - add comments for suspend/resume sleep values
 - dropped the checkpatch fixes that did not make sense
 - added Bastien's ack to the first patch

Irina Tirdea (9):
  Input: goodix - use actual config length for each device type
  Input: goodix - reset device at init
  Input: goodix - write configuration data to device
  Input: goodix - add power management support
  Input: goodix - use goodix_i2c_write_u8 instead of i2c_master_send
  Input: goodix - add support for ESD
  Input: goodix - add sysfs interface to dump config
  Input: goodix - add runtime power management support
  Input: goodix - sort includes using inverse Xmas tree order

 .../bindings/input/touchscreen/goodix.txt  |  11 +
 drivers/input/touchscreen/goodix.c | 766 +++--
 2 files changed, 732 insertions(+), 45 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 v8 7/9] Input: goodix - add sysfs interface to dump config

[Irina Tirdea]

Goodix devices have a configuration information register area that
specify various parameters for the device. The configuration information
has a specific format described in the Goodix datasheet. It includes X/Y
resolution, maximum supported touch points, interrupt flags, various
sesitivity factors and settings for advanced features (like gesture
recognition).

Export a sysfs interface that would allow reading the configuration
information. The default device configuration can be used as a starting
point for creating a valid configuration firmware used by the device at
init time to update its configuration.

This sysfs interface will be exported only if the gpio pins are properly
initialized from ACPI/DT.

Signed-off-by: Irina Tirdea 
---
 drivers/input/touchscreen/goodix.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index a271df9..01a2634 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -508,12 +508,35 @@ static ssize_t goodix_esd_timeout_store(struct device 
*dev,
return count;
 }
 
+static ssize_t goodix_dump_config_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct goodix_ts_data *ts = dev_get_drvdata(dev);
+   u8 config[GOODIX_CONFIG_MAX_LENGTH];
+   int error, count = 0, i;
+
+   error = goodix_i2c_read(ts->client, GOODIX_REG_CONFIG_DATA,
+   config, ts->cfg_len);
+   if (error) {
+   dev_warn(&ts->client->dev,
+"Error reading config (%d)\n",  error);
+   return error;
+   }
+
+   for (i = 0; i < ts->cfg_len; i++)
+   count += scnprintf(buf + count, PAGE_SIZE - count, "%02x ",
+  config[i]);
+   return count;
+}
+
 /* ESD timeout in ms. Default disabled (0). Recommended 2000 ms. */
 static DEVICE_ATTR(esd_timeout, S_IRUGO | S_IWUSR, goodix_esd_timeout_show,
   goodix_esd_timeout_store);
+static DEVICE_ATTR(dump_config, S_IRUGO, goodix_dump_config_show, NULL);
 
 static struct attribute *goodix_attrs[] = {
&dev_attr_esd_timeout.attr,
+   &dev_attr_dump_config.attr,
NULL
 };
 
-- 
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 v8 4/9] Input: goodix - add power management support

[Irina Tirdea]

Implement suspend/resume for goodix driver.

The suspend and resume process uses the gpio pins.
If the device ACPI/DT information does not declare gpio pins,
suspend/resume will not be available for these devices.

This is based on Goodix datasheets for GT911 and GT9271
and on Goodix driver gt9xx.c for Android (publicly available
in Android kernel trees for various devices).

Signed-off-by: Octavian Purdila 
Signed-off-by: Irina Tirdea 
---
 drivers/input/touchscreen/goodix.c | 94 --
 1 file changed, 89 insertions(+), 5 deletions(-)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index b4dfe4b..6314a24 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -44,6 +44,7 @@ struct goodix_ts_data {
u16 id;
u16 version;
char *cfg_name;
+   unsigned long irq_flags;
 };
 
 #define GOODIX_GPIO_INT_NAME   "irq"
@@ -60,6 +61,9 @@ struct goodix_ts_data {
 #define GOODIX_CONFIG_967_LENGTH   228
 
 /* Register defines */
+#define GOODIX_REG_COMMAND 0x8040
+#define GOODIX_CMD_SCREEN_OFF  0x05
+
 #define GOODIX_READ_COOR_ADDR  0x814E
 #define GOODIX_REG_CONFIG_DATA 0x8047
 #define GOODIX_REG_ID  0x8140
@@ -161,6 +165,11 @@ static int goodix_i2c_write(struct i2c_client *client, u16 
reg, const u8 *buf,
return ret < 0 ? ret : (ret != 1 ? -EIO : 0);
 }
 
+static int goodix_i2c_write_u8(struct i2c_client *client, u16 reg, u8 value)
+{
+   return goodix_i2c_write(client, reg, &value, sizeof(value));
+}
+
 static int goodix_get_cfg_len(u16 id)
 {
switch (id) {
@@ -280,6 +289,18 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
+static void goodix_free_irq(struct goodix_ts_data *ts)
+{
+   devm_free_irq(&ts->client->dev, ts->client->irq, ts);
+}
+
+static int goodix_request_irq(struct goodix_ts_data *ts)
+{
+   return devm_request_threaded_irq(&ts->client->dev, ts->client->irq,
+NULL, goodix_ts_irq_handler,
+ts->irq_flags, ts->client->name, ts);
+}
+
 /**
  * goodix_check_cfg - Checks if config fw is valid
  *
@@ -584,7 +605,6 @@ static int goodix_request_input_dev(struct goodix_ts_data 
*ts)
 static int goodix_configure_dev(struct goodix_ts_data *ts)
 {
int error;
-   unsigned long irq_flags;
 
goodix_read_config(ts);
 
@@ -592,10 +612,8 @@ static int goodix_configure_dev(struct goodix_ts_data *ts)
if (error)
return error;
 
-   irq_flags = goodix_irq_flags[ts->int_trigger_type] | IRQF_ONESHOT;
-   error = devm_request_threaded_irq(&ts->client->dev, ts->client->irq,
- NULL, goodix_ts_irq_handler,
- irq_flags, ts->client->name, ts);
+   ts->irq_flags = goodix_irq_flags[ts->int_trigger_type] | IRQF_ONESHOT;
+   error = goodix_request_irq(ts);
if (error) {
dev_err(&ts->client->dev, "request IRQ failed: %d\n", error);
return error;
@@ -701,6 +719,71 @@ static int goodix_ts_probe(struct i2c_client *client,
return goodix_configure_dev(ts);
 }
 
+static int __maybe_unused goodix_suspend(struct device *dev)
+{
+   struct i2c_client *client = to_i2c_client(dev);
+   struct goodix_ts_data *ts = i2c_get_clientdata(client);
+   int error;
+
+   /* We need gpio pins to suspend/resume */
+   if (!ts->gpiod_int || !ts->gpiod_rst)
+   return 0;
+
+   /* Free IRQ as IRQ pin is used as output in the suspend sequence */
+   goodix_free_irq(ts);
+   /* Output LOW on the INT pin for 5 ms */
+   error = gpiod_direction_output(ts->gpiod_int, 0);
+   if (error) {
+   goodix_request_irq(ts);
+   return error;
+   }
+   usleep_range(5000, 6000);
+
+   error = goodix_i2c_write_u8(ts->client, GOODIX_REG_COMMAND,
+   GOODIX_CMD_SCREEN_OFF);
+   if (error) {
+   dev_err(&ts->client->dev, "Screen off command failed\n");
+   gpiod_direction_input(ts->gpiod_int);
+   goodix_request_irq(ts);
+   return -EAGAIN;
+   }
+
+   /*
+* The datasheet specifies that the interval between sending screen-off
+* command and wake-up should be longer than 58 ms. To avoid waking up
+* sooner, delay 58ms here.
+*/
+   msleep(58);
+   return 0;
+}
+
+static int __maybe_unused goodix_resume(struct device *dev)
+{
+   struct i2c_client *client = to_i2c_client(dev);
+   struct goodix_ts_data *ts = i2c_get_clientdata(client);
+   int error;
+
+   if (!ts->gpiod_int || !ts->gpiod_rst)
+   return 0;
+
+   /*
+* Exit sleep mode by outputting HIGH level to INT pin
+* for 2ms~5ms.
+ 

[PATCH v8 5/9] Input: goodix - use goodix_i2c_write_u8 instead of i2c_master_send

[Irina Tirdea]

Use goodix_i2c_write_u8 instead of i2c_master_send to simplify code.

Signed-off-by: Irina Tirdea 
---
 drivers/input/touchscreen/goodix.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 6314a24..c86c265 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -274,16 +274,11 @@ static void goodix_process_events(struct goodix_ts_data 
*ts)
  */
 static irqreturn_t goodix_ts_irq_handler(int irq, void *dev_id)
 {
-   static const u8 end_cmd[] = {
-   GOODIX_READ_COOR_ADDR >> 8,
-   GOODIX_READ_COOR_ADDR & 0xff,
-   0
-   };
struct goodix_ts_data *ts = dev_id;
 
goodix_process_events(ts);
 
-   if (i2c_master_send(ts->client, end_cmd, sizeof(end_cmd)) < 0)
+   if (goodix_i2c_write_u8(ts->client, GOODIX_READ_COOR_ADDR, 0) < 0)
dev_err(&ts->client->dev, "I2C write end_cmd error\n");
 
return IRQ_HANDLED;
-- 
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 v8 6/9] Input: goodix - add support for ESD

[Irina Tirdea]

Add ESD (Electrostatic Discharge) protection mechanism.

The driver enables ESD protection in HW and checks a register
to determine if ESD occurred. If ESD is signalled by the HW,
the driver will reset the device.

The ESD poll time (in ms) can be set through the sysfs property
esd_timeout. If it is set to 0, ESD protection is disabled.
Recommended value is 2000 ms. The initial value for ESD timeout
can be set through esd-recovery-timeout-ms ACPI/DT property.
If there is no such property defined, ESD protection is disabled.
For ACPI 5.1, the property can be specified using _DSD properties:
 Device (STAC)
 {
 Name (_HID, "GDIX1001")
 ...

 Name (_DSD,  Package ()
 {
 ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
 Package ()
 {
 Package (2) { "esd-recovery-timeout-ms", Package(1) { 2000 }},
 ...
 }
 })
 }

The ESD protection mechanism is only available if the gpio pins
are properly initialized from ACPI/DT.

This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
driver gt9xx.c for Android (publicly available in Android kernel
trees for various devices).

Signed-off-by: Irina Tirdea 
---
 .../bindings/input/touchscreen/goodix.txt  |   6 +
 drivers/input/touchscreen/goodix.c | 180 -
 2 files changed, 178 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt 
b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index 7137881..4db3393 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -14,6 +14,12 @@ Required properties:
  - interrupts  : Interrupt to which the chip is connected
  - irq-gpio: GPIO pin used for IRQ
  - reset-gpio  : GPIO pin used for reset
+Optional properties:
+
+ - esd-recovery-timeout-ms : ESD poll time (in milli seconds) for the driver to
+check if ESD occurred and in that case reset the
+device. ESD is disabled if this property is not set
+or is set to 0.
 
 Example:
 
diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index c86c265..a271df9 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -45,10 +45,13 @@ struct goodix_ts_data {
u16 version;
char *cfg_name;
unsigned long irq_flags;
+   atomic_t esd_timeout;
+   struct delayed_work esd_work;
 };
 
 #define GOODIX_GPIO_INT_NAME   "irq"
 #define GOODIX_GPIO_RST_NAME   "reset"
+#define GOODIX_DEVICE_ESD_TIMEOUT_PROPERTY "esd-recovery-timeout-ms"
 
 #define GOODIX_MAX_HEIGHT  4096
 #define GOODIX_MAX_WIDTH   4096
@@ -63,6 +66,8 @@ struct goodix_ts_data {
 /* Register defines */
 #define GOODIX_REG_COMMAND 0x8040
 #define GOODIX_CMD_SCREEN_OFF  0x05
+#define GOODIX_CMD_ESD_ENABLED 0xAA
+#define GOODIX_REG_ESD_CHECK   0x8041
 
 #define GOODIX_READ_COOR_ADDR  0x814E
 #define GOODIX_REG_CONFIG_DATA 0x8047
@@ -405,6 +410,117 @@ static int goodix_reset(struct goodix_ts_data *ts)
return goodix_int_sync(ts);
 }
 
+static void goodix_disable_esd(struct goodix_ts_data *ts)
+{
+   if (!atomic_read(&ts->esd_timeout))
+   return;
+   cancel_delayed_work_sync(&ts->esd_work);
+}
+
+static int goodix_enable_esd(struct goodix_ts_data *ts)
+{
+   int error, esd_timeout;
+
+   esd_timeout = atomic_read(&ts->esd_timeout);
+   if (!esd_timeout)
+   return 0;
+
+   error = goodix_i2c_write_u8(ts->client, GOODIX_REG_ESD_CHECK,
+   GOODIX_CMD_ESD_ENABLED);
+   if (error) {
+   dev_err(&ts->client->dev, "Failed to enable ESD: %d\n", error);
+   return error;
+   }
+
+   schedule_delayed_work(&ts->esd_work, round_jiffies_relative(
+ msecs_to_jiffies(esd_timeout)));
+   return 0;
+}
+
+static void goodix_esd_work(struct work_struct *work)
+{
+   struct goodix_ts_data *ts = container_of(work, struct goodix_ts_data,
+esd_work.work);
+   int retries = 3, error;
+   u8 esd_data[2];
+   const struct firmware *cfg = NULL;
+
+   while (--retries) {
+   error = goodix_i2c_read(ts->client, GOODIX_REG_COMMAND,
+   esd_data, sizeof(esd_data));
+   if (error)
+   continue;
+   if (esd_data[0] != GOODIX_CMD_ESD_ENABLED &&
+   esd_data[1] == GOODIX_CMD_ESD_ENABLED) {
+   /* feed the watchdog */
+   goodix_i2c_write_u8(ts->client,
+   GOODIX_REG_COMMAND,
+