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

[Bharat Kumar Gogada]

> On 09/10/15 06:11, Bharat Kumar Gogada wrote:
>  +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.
> 
> Thanks for doing so, much appreciated.
> 
> > 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.
> 
> No, your PCI controller can perfectly be part of the PCIe node.
You meant 'msi-controller' property to be part of PCIe node?

> 
> > 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'.
> 
> If you want to keep them in the same file, please at least have two separate
> patches. These are two different functions, and they should be reviewed
> separately.
> 
What I meant is if we don't have separate msi node do we need separate file? 
If you meant msi controller to be part of same node then we will use single 
file and will
try to have two separate patches.

Thanks,
Bharat

> It will help everyone to understand your code, and speed up the reviewing
> process.
> 
> Thanks,
> 
>   M.
> --
> Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:06PM +0800, Jisheng Zhang wrote:
> This is to add the pinctrl dependency for Marvell Berlin SoCs.
> 
> Signed-off-by: Jisheng Zhang 

Acked-by: Antoine Tenart 

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

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:04PM +0800, Jisheng Zhang wrote:
> This is to prepare for the next berlin4ct support, where we won't use
> simple-mfd any more.
> 
> Signed-off-by: Jisheng Zhang 

Acked-by: Antoine Tenart 

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

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 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 = >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 = >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 v4 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 v3:
 - fix stupid build error: I missed local changes to berlin-bg4ct.c

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 v4 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 = <>;
reg-shift = <2>;
status = "disabled";
+   pinctrl-0 = <_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 v4 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

Re: [PATCH 2/4] arm64: dts: qcom: Add msm8916 I2C nodes.

[Srinivas Kandagatla]

On 08/10/15 19:17, Stephen Boyd wrote:

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.


Absolutely.. :-)
will fix it in next version.

--srini



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




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

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

[Antoine Tenart]

Hi Jisheng,

On Fri, Oct 09, 2015 at 04:17:05PM +0800, Jisheng Zhang wrote:
> 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

This endif ends the following condition:

if ARCH_BERLIN
[...]

So the "depends on ARCH_BERLIN" here can be dropped. Also the
COMPILE_TEST can be moved as it isn't BG4CT specific and all other
Berlin pinctrl drivers would benefit from this.

So we would have something like:

if (ARCH_BERLIN || COMPILE_TEST)
[...]
endif

Finally you can move the OF dependency to the PINCTRL_BERLIN config as
all Berlin pinctrl drivers depends on it.

Thanks!

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:09PM +0800, Jisheng Zhang wrote:
> 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 

Acked-by: Antoine Tenart 

> ---
>  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 = <>;
>   reg-shift = <2>;
>   status = "disabled";
> + pinctrl-0 = <_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
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:08PM +0800, Jisheng Zhang wrote:
> Add the avio, soc, sm pinctrl nodes for Marvell berlin4ct SoC.
> 
> Signed-off-by: Jisheng Zhang 

Acked-by: Antoine Tenart 

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

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/2] clk: imx6: Add SPDIF_GCLK clock in clock tree

[Shengjiu Wang]

On Thu, Sep 24, 2015 at 04:57:37AM -0700, Shawn Guo wrote:
> On Thu, Sep 24, 2015 at 01:43:24PM +0800, Shengjiu Wang wrote:
> > On Wed, Sep 23, 2015 at 08:33:41AM -0700, Shawn Guo wrote:
> > > On Tue, Sep 15, 2015 at 06:01:01PM +0800, Shengjiu Wang wrote:
> > > > As spdif driver will register SPDIF clock to regmap, regmap will do
> > > > clk_prepare in init function, so SPDIF clock is prepared in probe, then 
> > > > its
> > > > root clock (pll clock) is prepared also, which cause the arm can't enter
> > > > low power mode.
> > > 
> > > Can you help me understand why ARM cannot enter low power mode when pll
> > > clock is prepared?
> > > 
> > > Shawn
> > Hi Shawn
> > 
> >In i.mx clock framework, when pll clk is prepared, it will be powerup. 
> > when
> > enterring low power idle mode, the powerdown bit is checked, when pll is not
> > powerdown state, chip will not enter low power idle mode.
> 
> So this is not a SPDIF specific problem, and any device driver preparing
> its clock that is a child of pll clock will run into this problem,
> right?  If so, we should purchase a more generic solution than such
> device specific one.
> 
> Shawn
Hi shawn

SPDIF_GCLK is also spdif's clock, it use a same enable bit with SPDIF_ROOT_CLK,
We didn't separate them in clock tree before.

I can't find a generic solution. But anyway if there is a solution or not, I
think we'd better to separate them.

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

[PATCH v4 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 v4 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 v2 4/4] arm64: dts: apq8016-sbc: enable spi buses on LS and HS

[Srinivas Kandagatla]

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 cd1d0b5..64b06d8 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -49,6 +49,16 @@
status = "okay";
};
 
+   spi@78b7000 {
+   /* On High speed expansion */
+   status = "okay";
+   };
+
+   spi@78b9000 {
+   /* On Low speed expansion */
+   status = "okay";
+   };
+
leds {
pinctrl-names = "default";
pinctrl-0 = <_leds>,
-- 
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 v2 3/4] arm64: dts: apq8016-sbc: enable i2c buses on LS and HS

[Srinivas Kandagatla]

This patch enables i2c buses on low speed and high speed expansion
connectors on DB410C.

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

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 3fc3be4..cd1d0b5 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -34,6 +34,21 @@
pinctrl-1 = <_uart2_sleep>;
};
 
+   i2c@78b6000 {
+   /* On Low speed expansion */
+   status = "okay";
+   };
+
+   i2c@78b8000 {
+   /* On High speed expansion */
+   status = "okay";
+   };
+
+   i2c@78ba000 {
+   /* On Low speed expansion */
+   status = "okay";
+   };
+
leds {
pinctrl-names = "default";
pinctrl-0 = <_leds>,
-- 
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 v2 0/4] arm64: dts: qcom: add support to LS and HS connectors

[Srinivas Kandagatla]

Hi Andy, 

This patchset adds support for i2c and spi on High-Speed and Low speed
connectors on DB410c.
One of the patch fixes the sleep state of existing i2c node.

thanks,
srini

Changes since v1:
- removed useless comment spotted by Stephen Boyd.
- Use absolute names instead of lables for consistency suggested by 
Stephen Boyd.

Srinivas Kandagatla (4):
  arm64: dts: fix i2c pinconf sleep state function
  arm64: dts: qcom: Add msm8916 I2C nodes.
  arm64: dts: apq8016-sbc: enable i2c buses on LS and HS
  arm64: dts: apq8016-sbc: enable spi buses on LS and HS

 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 25 +++
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 50 +-
 arch/arm64/boot/dts/qcom/msm8916.dtsi  | 30 ++
 3 files changed, 104 insertions(+), 1 deletion(-)

-- 
1.9.1

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

[PATCH v2 2/4] arm64: dts: qcom: Add msm8916 I2C nodes.

[Srinivas Kandagatla]

This patch adds missing support for i2c0 and i2c6, this support is
required to connect the i2c slaves on LS expansion on DB410c.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 48 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  | 30 +++
 2 files changed, 78 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index a6105d7..49ec55a 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -265,6 +265,30 @@
};
};
 
+   i2c2_default: i2c2_default {
+   pinmux {
+   function = "blsp_i2c2";
+   pins = "gpio6", "gpio7";
+   };
+   pinconf {
+   pins = "gpio6", "gpio7";
+   drive-strength = <2>;
+   bias-disable = <0>;
+   };
+   };
+
+   i2c2_sleep: i2c2_sleep {
+   pinmux {
+   function = "gpio";
+   pins = "gpio6", "gpio7";
+   };
+   pinconf {
+   pins = "gpio6", "gpio7";
+   drive-strength = <2>;
+   bias-disable = <0>;
+   };
+   };
+
i2c4_default: i2c4_default {
pinmux {
function = "blsp_i2c4";
@@ -289,6 +313,30 @@
};
};
 
+   i2c6_default: i2c6_default {
+   pinmux {
+   function = "blsp_i2c6";
+   pins = "gpio22", "gpio23";
+   };
+   pinconf {
+   pins = "gpio22", "gpio23";
+   drive-strength = <2>;
+   bias-disable = <0>;
+   };
+   };
+
+   i2c6_sleep: i2c6_sleep {
+   pinmux {
+   function = "gpio";
+   pins = "gpio22", "gpio23";
+   };
+   pinconf {
+   pins = "gpio22", "gpio23";
+   drive-strength = <2>;
+   bias-disable = <0>;
+   };
+   };
+
sdhc2_cd_pin {
sdc2_cd_on: cd_on {
pinmux {
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 85f7bee..2c86234 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -233,6 +233,21 @@
status = "disabled";
};
 
+   blsp_i2c2: i2c@78b6000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78b6000 0x1000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_default>;
+   pinctrl-1 = <_sleep>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
blsp_i2c4: i2c@78b8000 {
compatible = "qcom,i2c-qup-v2.2.1";
reg = <0x78b8000 0x1000>;
@@ -248,6 +263,21 @@
status = "disabled";
};
 
+   blsp_i2c6: i2c@78ba000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78ba000 0x1000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP6_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_default>;
+   pinctrl-1 = <_sleep>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
sdhc_1: sdhci@07824000 {
compatible = "qcom,sdhci-msm-v4";
reg = <0x07824900 0x11c>, <0x07824000 0x800>;
-- 
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 v2 1/4] arm64: dts: fix i2c pinconf sleep state function

[Srinivas Kandagatla]

This patch fixes the i2c pinctrl sleep state by changing the pinconf
function to be in gpio mode rather than i2c.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 42941b9..a6105d7 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -279,7 +279,7 @@
 
i2c4_sleep: i2c4_sleep {
pinmux {
-   function = "blsp_i2c4";
+   function = "gpio";
pins = "gpio14", "gpio15";
};
pinconf {
-- 
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 v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 09/10/15 09:51, Bharat Kumar Gogada wrote:
>> On 09/10/15 06:11, Bharat Kumar Gogada wrote:
>> +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.
>>
>> Thanks for doing so, much appreciated.
>>
>>> 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.
>>
>> No, your PCI controller can perfectly be part of the PCIe node.
> You meant 'msi-controller' property to be part of PCIe node?

Yeah, sorry. Too early, not enough coffee.

>>
>>> 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'.
>>
>> If you want to keep them in the same file, please at least have two separate
>> patches. These are two different functions, and they should be reviewed
>> separately.
>>
> What I meant is if we don't have separate msi node do we need separate file? 

That's up to you. Nodes and source code files don't have to match at all.

> If you meant msi controller to be part of same node then we will use single 
> file and will
> try to have two separate patches.

That's fine by me.

Thanks,

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

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

[Jisheng Zhang]

Hi Antoine,

On Fri, 9 Oct 2015 11:03:53 +0200
Antoine Tenart  wrote:

> Hi Jisheng,
> 
> On Fri, Oct 09, 2015 at 04:17:05PM +0800, Jisheng Zhang wrote:
> > 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
> 
> This endif ends the following condition:
> 
>   if ARCH_BERLIN
>   [...]
> 
> So the "depends on ARCH_BERLIN" here can be dropped. Also the
> COMPILE_TEST can be moved as it isn't BG4CT specific and all other
> Berlin pinctrl drivers would benefit from this.
> 
> So we would have something like:
> 
>   if (ARCH_BERLIN || COMPILE_TEST)

Oh yeah! This is better.

>   [...]
>   endif
> 
> Finally you can move the OF dependency to the PINCTRL_BERLIN config as
> all Berlin pinctrl drivers depends on it.

PINCTRL_BERLIN isn't user visible and it's selected by PINCTRL_BERLIN_BG4CT. So
we may have the following random config case:

CONFIG_OF=n
CONFIG_PINCTRL_BERLIN_BG4CT=y

In this case, there will be build errors for we missed OF. So we have to
make PINCTRL_BERLIN_BG4CT depends on OF. What do you think? Or is there
better solution?

Thanks for kind review,
Jisheng

> 
> Thanks!
> 
> Antoine
> 

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

Re: [PATCH v6 0/5] Add DT support for netxbig LEDs

[Jacek Anaszewski]

On 09/26/2015 11:02 PM, Simon Guinot wrote:

Hello,

This patch series adds DT support for the LEDs found on the
Kirkwood-based LaCie boards 2Big and 5Big Network v2.

Changes for v2:
- Check timer mode value retrieved from DT.
- In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
   timer delay values from DT with function of_property_read_u32_index.
   Instead, use a temporary u32 variable. This allows to silence a static
   checker warning.
- Make timer property optional in the binding documentation. It is now
   aligned with the driver code.

Changes for v3:
- Fix pointer usage with the temporary u32 variable while calling
   of_property_read_u32_index.

Changes for v4:
- In DT binding document netxbig-gpio-ext.txt, detail byte order for
   registers and latch mechanism for "enable-gpio".
- In leds-netxbig.c, add some error messages.
- In leds-netxbig.c, fix some "sizeof" style issues.
- In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
   of_property_read_string() calls after the error-prone checks.
- Add some Acked-by.

Changes for v5:
- Rename DT property "bright-max" into the more common "max-brightness".
- Make use of the "max-brightness" DT property. Instead of counting the
   data pins of the GPIO extension bus, use "max-brightness" to get the
   maximum brightness level.
- Add a patch to convert the leds-netxbig driver to the devm_ functions.

Changes for v6:
- Add a patch to set led_classdev max_brightness in the leds-netxbig
   driver.
- Decrement the current child node refcount with of_node_put() when an
   error happens while iterating with for_each_child_of_node().

Thanks,

Simon

Simon Guinot (5):
   leds: netxbig: add device tree binding
   ARM: Kirkwood: add LED DT entries for netxbig boards
   ARM: mvebu: remove static LED setup for netxbig boards
   leds: netxbig: convert to use the devm_ functions
   leds: netxbig: set led_classdev max_brightness

  .../devicetree/bindings/gpio/netxbig-gpio-ext.txt  |  22 ++
  .../devicetree/bindings/leds/leds-netxbig.txt  |  92 ++
  arch/arm/boot/dts/kirkwood-net5big.dts |  60 
  arch/arm/boot/dts/kirkwood-netxbig.dtsi|  80 +
  arch/arm/mach-mvebu/Kconfig|   7 -
  arch/arm/mach-mvebu/Makefile   |   1 -
  arch/arm/mach-mvebu/board.h|  21 --
  arch/arm/mach-mvebu/kirkwood.c |   4 -
  arch/arm/mach-mvebu/netxbig.c  | 191 
  drivers/leds/leds-netxbig.c| 336 -
  include/dt-bindings/leds/leds-netxbig.h|  18 ++
  .../linux/platform_data/leds-kirkwood-netxbig.h|   1 +
  12 files changed, 531 insertions(+), 302 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
  create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
  delete mode 100644 arch/arm/mach-mvebu/board.h
  delete mode 100644 arch/arm/mach-mvebu/netxbig.c
  create mode 100644 include/dt-bindings/leds/leds-netxbig.h



Since no comment regarding DT bindings has appeared for a long time,
I decided to merge the patch set without DT maintainer's ack, thanks.

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

[PATCH v4 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..0917204
--- /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 */
+   

Re: [PATCH 4/4] arm64: dts: apq8016-sbc: enable spi buses on LS and HS

[Srinivas Kandagatla]

On 08/10/15 19:16, Stephen Boyd wrote:

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";
  };

+_spi3 {
+   /* On High speed expansion */
+   status = "okay";
+};
+
  _i2c4 {
/* On High speed expansion */
status = "okay";
  };

+_spi5 {
+   /* On Low speed expansion */
+   status = "okay";
+};
+
  _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?


Sure, I will re-spin a new version.

--srini



--
To unsubscribe from this list: send the line "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/6] pinctrl: dt-binding: document berlin4ct SoC pinctrl

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:07PM +0800, Jisheng Zhang wrote:
> Add berlin4ct to existing berlin pinctrl device tree binding.
> 
> Signed-off-by: Jisheng Zhang 

Acked-by: Antoine Tenart 

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

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] leds-bcm6328: several fixes and improvements

[Jacek Anaszewski]

Hi Alvaro,

Thanks for the patches, merged.

Best Regards,
Jacek Anaszewski

On 10/08/2015 12:35 PM, Álvaro Fernández Rojas wrote:

These patches improve leds-bcm6328 by adding invalid LED printing (like it's 
done in leds-bcm6358), simplifying default-state handling (once again like it's 
done in leds-bcm6358), and adding more init configuration options.

Álvaro Fernández Rojas (4):
   leds-bcm6328: print invalid LED
   leds-bcm6328: simplify and improve default-state handling
   leds-bcm6328: add more init configuration options
   Documentation: leds: update DT bindings for leds-bcm6328

  .../devicetree/bindings/leds/leds-bcm6328.txt  | 10 ++
  drivers/leds/leds-bcm6328.c| 41 --
  2 files changed, 40 insertions(+), 11 deletions(-)


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

Re: [RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

[Kishon Vijay Abraham I]

Hi Bjorn,

On Saturday 10 October 2015 04:20 AM, Bjorn Helgaas wrote:
> [+cc Arnd, Rob]
> 
> On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
>> Add driver modifications in pci-dra7xx to get x2 mode working in
>> DRA72 and DRA74. Certain modifications is needed in PHY driver also
>> which I'll send as a separate series.
>>
>> Kishon Vijay Abraham I (2):
>>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
>>   pci: host: pci-dra7xx: Enable x2 mode support
> 
> Applied to pci/host-dra7xx for v4.4, thanks!
> 
> I adjusted the subject line capitalization & format to match the history.
> 
> Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
> strings in "phy-names" changes?

I sent it as RFC since I didn't have the board to test 2 lane mode with
$patch. And just now I got a board to test x2 and I found a problem with
the 2nd patch.

.b1co_mode_sel_mask = GENMASK(2, 3), in the patch should be replaced with
.b1co_mode_sel_mask = GENMASK(3, 2).

I'll resend the patch fixing the above.

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

Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource

[Stephen Boyd]

On 10/09, Måns Rullgård wrote:
> Stephen Boyd  writes:
> 
> > On 10/09, Rob Herring wrote:
> >> 
> >> Adding a ptr to the callback seems fine to me.
> >> 
> >
> > Does that mean a flag day? Urgh. Pain. I'm not opposed to adding
> > a pointer, in fact it might be better for performance so that we
> > don't take a cache miss in read() functions that need to load
> > some pointer. We were talking about that problem a few months
> > ago, but nothing came of it.
> 
> Flag day in what sense?  There aren't all that many users of the
> interface (56, to be precise), and sched_clock_register() isn't
> exported. 

That's exactly what a flag day is. Lots of coordination, lots of
acks, etc. Last time when I changed the registration API I made a
new registration API, moved every caller over one by one, and
then deleted the old registration API. That's how you manage a
flag day.

We could probably do the same thing again with two different
types of registration APIs so that we move over users one by one.
The old registration API would be wrapped with a sched_clock
local function that doesn't pass the pointer it gets called with,
while the new registration API would fill in the function pointer
that we call directly from the core code. The double function
call is probably bad for performance, so I guess we should get
rid of it and always pass the pointer to the callback. But this
is at least a method to convert everything gradually without
breaking users that may be going through different trees.

> Verifying the change will be a minor pain, but I don't see
> why it should have any major consequences.  Obviously I'd just set the
> pointer to null for existing users and leave it for the respective
> maintainers to make proper use of it where sensible.
> 

Sure.

-- 
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 04/10] ARM: dts: enable clock support for BCM5301X

[Stephen Boyd]

On 10/09, Jon Mason wrote:
> On Fri, Oct 09, 2015 at 12:35:40AM -0700, Stephen Boyd wrote:
> > On 10/02, Jon Mason wrote:
> > 
> > >  arch/arm/boot/dts/bcm5301x.dtsi | 67 
> > > -
> > >  1 file changed, 60 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/bcm5301x.dtsi 
> > > b/arch/arm/boot/dts/bcm5301x.dtsi
> > > index 6f50f67..f717859 100644
> > > --- a/arch/arm/boot/dts/bcm5301x.dtsi
> > > +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> > > @@ -55,14 +56,14 @@
> > >   compatible = "arm,cortex-a9-global-timer";
> > >   reg = <0x0200 0x100>;
> > >   interrupts = ;
> > > - clocks = <_periph>;
> > > + clocks = <_clk>;
> > >   };
> > >  
> > >   local-timer@0600 {
> > >   compatible = "arm,cortex-a9-twd-timer";
> > >   reg = <0x0600 0x100>;
> > >   interrupts = ;
> > > - clocks = <_periph>;
> > > + clocks = <_clk>;
> > >   };
> > >  
> > >   gic: interrupt-controller@1000 {
> > > @@ -94,14 +95,66 @@
> > >  
> > >   clocks {
> > 
> > I'd expect this to only contain nodes that don't have a reg
> > property. Clock providers that have a reg property would go into
> > some soc node or bus. Perhaps that's the chipcommonA node, or
> > axi?
> 
> This might get a little ugly, as some of the clocks are in the
> 0x1800 and others are in 0x1900.  I would think it better to
> have them all in one place (as that is more readable).  Do you preferr
> I split the pieces up into their respective DT nodes?

Are there two clock controllers? Sorry I don't understand the
architecture here very well. Nodes with reg properties in the
same range should be near each other. We don't group all i2c
controllers into the same node because they're logically i2c
controllers. We express the hierarchy of devices with container
nodes. The clocks node is only useful for board-level clocks, not
things that are inside the SoC.

-- 
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] PCI: generic: Fix address window calculation for non-zero starting bus.

[Bjorn Helgaas]

On Thu, Oct 08, 2015 at 12:54:16PM -0700, 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 

Applied to pci/host-generic for v4.4 with Reviewed-by and Acked-by from
Arnd and Rob, thanks David!

Bjorn

> ---
> 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, >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 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: [RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

[Bjorn Helgaas]

On Sat, Oct 10, 2015 at 04:46:55AM +0530, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> On Saturday 10 October 2015 04:20 AM, Bjorn Helgaas wrote:
> > [+cc Arnd, Rob]
> > 
> > On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
> >> Add driver modifications in pci-dra7xx to get x2 mode working in
> >> DRA72 and DRA74. Certain modifications is needed in PHY driver also
> >> which I'll send as a separate series.
> >>
> >> Kishon Vijay Abraham I (2):
> >>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
> >>   pci: host: pci-dra7xx: Enable x2 mode support
> > 
> > Applied to pci/host-dra7xx for v4.4, thanks!
> > 
> > I adjusted the subject line capitalization & format to match the history.
> > 
> > Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
> > strings in "phy-names" changes?
> 
> I sent it as RFC since I didn't have the board to test 2 lane mode with
> $patch. And just now I got a board to test x2 and I found a problem with
> the 2nd patch.
> 
> .b1co_mode_sel_mask = GENMASK(2, 3), in the patch should be replaced with
> .b1co_mode_sel_mask = GENMASK(3, 2).
> 
> I'll resend the patch fixing the above.

OK, I dropped these two patches.  Thanks for letting me know.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource

[Stephen Boyd]

On 10/09, Måns Rullgård wrote:
> Stephen Boyd  writes:
> >
> > Does that mean a flag day? Urgh. Pain. I'm not opposed to adding
> > a pointer, in fact it might be better for performance so that we
> > don't take a cache miss in read() functions that need to load
> > some pointer. We were talking about that problem a few months
> > ago, but nothing came of it.
> 
> I've sent a patch.  Let the flames begin.
> 

I never got it. Was I Cced?

-- 
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 05/10] clk: iproc: Add PLL base write function

[Stephen Boyd]

On 10/02, Jon Mason wrote:
> diff --git a/drivers/clk/bcm/clk-iproc-pll.c b/drivers/clk/bcm/clk-iproc-pll.c
> index e029ab3..a4602aa 100644
> --- a/drivers/clk/bcm/clk-iproc-pll.c
> +++ b/drivers/clk/bcm/clk-iproc-pll.c
> @@ -137,6 +137,18 @@ static int pll_wait_for_lock(struct iproc_pll *pll)
>   return -EIO;
>  }
>  
> +static void iproc_pll_write(struct iproc_pll *pll, void __iomem *base,
> + u32 offset, u32 val)
> +{
> + const struct iproc_pll_ctrl *ctrl = pll->ctrl;
> +
> + writel(val, base + offset);
> +
> + if (unlikely(ctrl->flags & IPROC_CLK_NEEDS_READ_BACK &&
> +  base == pll->pll_base))
> + val = readl(base + offset);

Is there any point to assign val here?

-- 
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 09/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Stephen Boyd]

On 10/02, Jon Mason wrote:
> diff --git a/drivers/clk/bcm/clk-ns2.c b/drivers/clk/bcm/clk-ns2.c
> new file mode 100644
> index 000..1d08281
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-ns2.c
> @@ -0,0 +1,290 @@
> +/*
> + * Copyright (C) 2015 Broadcom Corporation
> + *
> + * 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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; 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 

clkdev looks unused here too?

> +#include 
> +#include 

And this one?

> +
> +#include 
> +#include "clk-iproc.h"
> +
> +#define reg_val(o, s, w) { .offset = o, .shift = s, .width = w, }

I guess we missed this one already, but this isn't a macro
resembling a function. Kernel style is to capitalize this sort of
macro.

-- 
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 1/2] clk: imx6: Add SPDIF_GCLK clock in clock tree

[Shengjiu Wang]

On Sat, Oct 10, 2015 at 09:11:55AM +0800, Shawn Guo wrote:
> On Fri, Oct 09, 2015 at 05:15:30PM +0800, Shengjiu Wang wrote:
> > SPDIF_GCLK is also spdif's clock, it use a same enable bit with 
> > SPDIF_ROOT_CLK,
> > We didn't separate them in clock tree before.
> 
> Is it the clock described as "Global clock" in Reference Manual, SPDIF
Yes.
> chapter?  If that's the case, you are just adding a missing SPDIF clock
> rather than fixing a low power mode issue, and I will be fine.  But
> still you should reword the commit log to make it clear, that the patch
> is to correct a SPDIF clock setting issue, which is just discovered by
> low power mode support.
> 
Ok, I will refine the patch comments, and send it 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

[RFC V2] arm: add relocate initrd support

[yalin wang]

Add support for initrd on ARM arch, in case
mem= boot option change the memory size or the initrd are
not placed in low memory region, we need copy the initrd
to low memory region.

Signed-off-by: yalin wang 
---
 arch/arm/include/asm/fixmap.h |  1 +
 arch/arm/kernel/setup.c   | 70 +++
 drivers/of/fdt.c  |  2 ++
 include/linux/initrd.h|  1 +
 init/do_mounts_initrd.c   |  2 ++
 5 files changed, 76 insertions(+)

diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 58cfe9f..18ad90f 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -10,6 +10,7 @@
 
 enum fixed_addresses {
FIX_EARLYCON_MEM_BASE,
+   FIX_RELOCATE_INITRD,
__end_of_permanent_fixed_addresses,
 
FIX_KMAP_BEGIN = __end_of_permanent_fixed_addresses,
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..036473b 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -811,6 +811,75 @@ static void __init request_standard_resources(const struct 
machine_desc *mdesc)
request_resource(_resource, );
 }
 
+#if defined(CONFIG_BLK_DEV_INITRD) && defined(CONFIG_MMU)
+/*
+ * Relocate initrd if it is not completely within the linear mapping.
+ * This would be the case if mem= cuts out all or part of it
+ * or the initrd are not in low mem region place.
+ */
+static void __init relocate_initrd(void)
+{
+   phys_addr_t ram_end = memblock_end_of_DRAM();
+   phys_addr_t new_start;
+   phys_addr_t src;
+   unsigned long size, to_free = 0;
+   unsigned long slop, clen, p;
+   void *dest;
+
+   if (initrd_end_phys <= __virt_to_phys(memblock_get_current_limit()))
+   return;
+
+   /*
+* Any of the original initrd which overlaps the linear map should
+* be freed after relocating.
+*/
+   if (initrd_start_phys < ram_end)
+   to_free = min(ram_end, initrd_end_phys) - initrd_start_phys;
+
+   size = initrd_end_phys - initrd_start_phys;
+
+   /* initrd needs to be relocated completely inside linear mapping */
+   new_start = memblock_find_in_range(0, 0, size, PAGE_SIZE);
+   if (!new_start)
+   panic("Cannot relocate initrd of size %ld\n", size);
+   memblock_reserve(new_start, size);
+
+   initrd_start = __phys_to_virt(new_start);
+   initrd_end   = initrd_start + size;
+
+   pr_info("Moving initrd from [%llx-%llx] to [%llx-%llx]\n",
+   (unsigned long long)initrd_start_phys,
+   (unsigned long long)(initrd_start_phys + size - 1),
+   (unsigned long long)new_start,
+   (unsigned long long)(new_start + size - 1));
+
+   dest = (void *)initrd_start;
+
+   src = initrd_start_phys;
+   while (size) {
+   slop = src & ~PAGE_MASK;
+   clen = min(PAGE_SIZE - slop, size);
+   p = set_fixmap_offset(FIX_RELOCATE_INITRD, src);
+   memcpy(dest, (void *)p, clen);
+   clear_fixmap(FIX_RELOCATE_INITRD);
+   dest += clen;
+   src += clen;
+   size -= clen;
+   }
+
+   if (to_free) {
+   pr_info("Freeing original RAMDISK from [%llx-%llx]\n",
+   (unsigned long long)initrd_start_phys,
+   (unsigned long long)(initrd_start_phys + to_free - 1));
+   memblock_free(initrd_start_phys, to_free);
+   }
+}
+#else
+static inline void __init relocate_initrd(void)
+{
+}
+#endif
+
 #if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
 struct screen_info screen_info = {
  .orig_video_lines = 30,
@@ -969,6 +1038,7 @@ void __init setup_arch(char **cmdline_p)
arm_memblock_init(mdesc);
 
paging_init(mdesc);
+   relocate_initrd();
request_standard_resources(mdesc);
 
if (mdesc->restart)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 0749656..3287ecb 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -777,6 +777,8 @@ static void __init early_init_dt_check_for_initrd(unsigned 
long node)
return;
end = of_read_number(prop, len/4);
 
+   initrd_start_phys = start;
+   initrd_end_phys = end;
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
initrd_below_start_ok = 1;
diff --git a/include/linux/initrd.h b/include/linux/initrd.h
index 55289d2..0698f37 100644
--- a/include/linux/initrd.h
+++ b/include/linux/initrd.h
@@ -15,6 +15,7 @@ extern int initrd_below_start_ok;
 
 /* free_initrd_mem always gets called with the next two as arguments.. */
 extern unsigned long initrd_start, initrd_end;
+extern phys_addr_t initrd_start_phys, initrd_end_phys;
 extern void free_initrd_mem(unsigned long, unsigned long);
 
 extern unsigned int real_root_dev;
diff --git a/init/do_mounts_initrd.c 

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

[Zhou Wang]

This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
move related operations to dw_pcie_host_init.

This patch also try to use of_pci_get_host_bridge_resources for ARM32 and ARM64
according to the suggestion for Gabriele[1]

This patch reverts commit f4c55c5a3f7f ("PCI: designware: Program ATU with
untranslated address") based on 1/6 in this series. we delete *_mod_base in
pcie-designware. This was discussed in [2]

I have compiled the driver with multi_v7_defconfig. However, I don't have
ARM32 PCIe related board to do test. It will be appreciated if someone could
help to test it.

Signed-off-by: Zhou Wang 
Signed-off-by: Gabriele Paoloni 
Signed-off-by: Arnd Bergmann 
Tested-by: James Morse 
Tested-by: Gabriel Fernandez 
Tested-by: Minghuan Lian 
Acked-by: Pratyush Anand 

[1] http://www.spinics.net/lists/linux-pci/msg42194.html
[2] http://www.spinics.net/lists/arm-kernel/msg436779.html
---
 drivers/pci/host/pci-dra7xx.c  |  14 +--
 drivers/pci/host/pci-keystone-dw.c |   2 +-
 drivers/pci/host/pcie-designware.c | 238 -
 drivers/pci/host/pcie-designware.h |  14 +--
 4 files changed, 90 insertions(+), 178 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index ebdffa0..b88c248 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -153,15 +153,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
 {
dw_pcie_setup_rc(pp);
 
-   if (pp->io_mod_base)
-   pp->io_mod_base &= CPU_TO_BUS_ADDR;
+   if (pp->io_base)
+   pp->io_base &= CPU_TO_BUS_ADDR;
 
-   if (pp->mem_mod_base)
-   pp->mem_mod_base &= CPU_TO_BUS_ADDR;
+   if (pp->mem_base)
+   pp->mem_base &= CPU_TO_BUS_ADDR;
 
-   if (pp->cfg0_mod_base) {
-   pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
-   pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
+   if (pp->cfg0_base) {
+   pp->cfg0_base &= CPU_TO_BUS_ADDR;
+   pp->cfg1_base &= CPU_TO_BUS_ADDR;
}
 
dra7xx_pcie_establish_link(pp);
diff --git a/drivers/pci/host/pci-keystone-dw.c 
b/drivers/pci/host/pci-keystone-dw.c
index e71da99..8062ddb 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -322,7 +322,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem 
*reg_virt)
 void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
 {
struct pcie_port *pp = _pcie->pp;
-   u32 start = pp->mem.start, end = pp->mem.end;
+   u32 start = pp->mem->start, end = pp->mem->end;
int i, tr_size;
 
/* Disable BARs for inbound access */
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 75338a6..8ef74da 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -11,6 +11,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -69,16 +70,7 @@
 #define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET  0x91C
 
-static struct hw_pci dw_pci;
-
-static unsigned long global_io_offset;
-
-static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
-   BUG_ON(!sys->private_data);
-
-   return sys->private_data;
-}
+static struct pci_ops dw_pcie_ops;
 
 int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
 {
@@ -255,7 +247,7 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int 
irq)
 static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
 {
int irq, pos0, i;
-   struct pcie_port *pp = sys_to_pcie(msi_desc_to_pci_sysdata(desc));
+   struct pcie_port *pp = (struct pcie_port *) 
msi_desc_to_pci_sysdata(desc);
 
pos0 = bitmap_find_free_region(pp->msi_irq_in_use, MAX_MSI_IRQS,
   order_base_2(no_irqs));
@@ -298,7 +290,7 @@ static int dw_msi_setup_irq(struct msi_controller *chip, 
struct pci_dev *pdev,
 {
int irq, pos;
struct msi_msg msg;
-   struct pcie_port *pp = sys_to_pcie(pdev->bus->sysdata);
+   struct pcie_port *pp = pdev->bus->sysdata;
 
if (desc->msi_attrib.is_msix)
return -EINVAL;
@@ -327,7 +319,7 @@ static void dw_msi_teardown_irq(struct msi_controller 
*chip, unsigned int irq)
 {
struct irq_data *data = irq_get_irq_data(irq);
struct msi_desc *msi = irq_data_get_msi_desc(data);
-   struct pcie_port *pp = sys_to_pcie(msi_desc_to_pci_sysdata(msi));
+   struct pcie_port *pp = (struct pcie_port *) 
msi_desc_to_pci_sysdata(msi);
 
clear_irq_range(pp, irq, 1, data->hwirq);
 }
@@ -362,14 +354,12 @@ 

[PATCH v10 5/6] Documentation: DT: Add HiSilicon PCIe host binding

[Zhou Wang]

This patch adds related DTS binding document for HiSilicon PCIe host driver.

Signed-off-by: Zhou Wang 
---
 .../bindings/arm/hisilicon/hisilicon.txt   | 17 +
 .../devicetree/bindings/pci/hisilicon-pcie.txt | 44 ++
 2 files changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 3504dca..6ac7c00 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -171,6 +171,23 @@ Example:
};
 
 ---
+Hisilicon HiP05 PCIe-SAS system controller
+
+Required properties:
+- compatible : "hisilicon,pcie-sas-subctrl", "syscon";
+- reg : Register address and size
+
+The HiP05 PCIe-SAS system controller is shared by PCIe and SAS controllers in
+HiP05 Soc to implement some basic configurations.
+
+Example:
+   /* for HiP05 PCIe-SAS system */
+   pcie_sas: system_controller@0xb000 {
+   compatible = "hisilicon,pcie-sas-subctrl", "syscon";
+   reg = <0xb000 0x1>;
+   };
+
+---
 Hisilicon CPU controller
 
 Required properties:
diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt 
b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
new file mode 100644
index 000..17c6ed9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -0,0 +1,44 @@
+HiSilicon PCIe host bridge DT description
+
+HiSilicon PCIe host controller is based on Designware PCI core.
+It shares common functions with PCIe Designware core driver and inherits
+common properties defined in
+Documentation/devicetree/bindings/pci/designware-pci.txt.
+
+Additional properties are described here:
+
+Required properties:
+- compatible: Should contain "hisilicon,hip05-pcie".
+- reg: Should contain rc_dbi, config registers location and length.
+- reg-names: Must include the following entries:
+  "rc_dbi": controller configuration registers;
+  "config": PCIe configuration space registers.
+- msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
+- port-id: Should be 0, 1, 2 or 3.
+
+Optional properties:
+- status: Either "ok" or "disabled".
+- dma-coherent: Present if DMA operations are coherent.
+
+Example:
+   pcie@0xb008 {
+   compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
+   reg = <0 0xb008 0 0x1>, <0x220 0x 0 0x2000>;
+   reg-names = "rc_dbi", "config";
+   bus-range = <0  15>;
+   msi-parent = <_pcie>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   dma-coherent;
+   ranges = <0x8200 0 0x 0x220 0x 0 
0x1000>;
+   num-lanes = <8>;
+   port-id = <1>;
+   #interrupts-cells = <1>;
+   interrupts-map-mask = <0xf800 0 0 7>;
+   interrupts-map = <0x0 0 0 1 _pcie 1 10
+ 0x0 0 0 2 _pcie 2 11
+ 0x0 0 0 3 _pcie 3 12
+ 0x0 0 0 4 _pcie 4 13>;
+   status = "ok";
+   };
-- 
1.9.1

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

[PATCH v10 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Zhou Wang]

This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe hosts
use PCIe IP core from Synopsys, So this driver is based on designware PCIe 
driver.

Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64 PCIe API in
designware PCIe driver. So this patch also adds ARM64 support for designware
pcie.

This patchset is based on v4.3-rc1.

Change from v9:
- Use syscon to get subctrl base address.
- 5/6 is based on [PATCH v3 0/2] arm64: Support Hisilicon Hip05-D02 board
  from Ding Tianhong
- Add hisi_pcie_cfg_read in pcie-hisi.c to match
  [PATCH v6 0/3] PCI: designware: change dw_pcie_cfg_write() and 
dw_pcie_cfg_read()
  from Gabriele.

Change from v8:
- Rebase on v4.3-rc1.
- Add Tested-by from Gabriel and Minghuan.
- Remove ITS domain parsing in msi_host_init in pcie-hisi.c, no need this as PCI
  core does related job. Add ITS base address parsing in msi_host_init.
- Change vmid/asid table configuration, previous configuration was wrong.
- Add wr_own_conf callback in pcie-hisi.c.
- Use subsys_initcall to init hisi PCIe.

Change from v7:
- Remove pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
  spear13xx. Pass pp->busn->start to pci_create_root_bus as root bus number.
- Remove bus-range parsing in pcie-hisi.c.

Change from v6:
- Add Pratyush's Acked-by for 1/6 and 2/6.
- Add James' Tested-by for 3/6.

Change from v5:
- Merge 1/6 in this series, discussion about this can be found in [1]

Change from v4:
- Change the author of 1/5 to Gabriele.
- Modify problems in 3/5 pointed by Bjorn.
- Modify spelling problems in 4/5.

Change from v3:
- Change 1/5 to what Gabriele suggested.
- Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series.

Change from v2:
- Move struct pci_dev *dev and struct pci_sys_data *sys in
  pcibios_align_resource in 1/5.
- Add Gabriele's codes in 2/5 which delete unnecessary information parse and
  use of_pci_get_host_bridge_resources for both ARM32 and ARM64.
- Add maintainer patch 5/5.

Change from RFC v1:
- Add 1/4 patch by Arnd which removes align_resource callback in ARM
  pcibios_align_resource.
- Change head file in pcie-designware from asm/hardirq.h to linux/hardirq.h.
- Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
  spear13xx.
- Remove unnecessary parentheses of some macros in pcie-hisi.
- Use macro to replace some magic values.
- Merge two loops together and add some comments about it in context_config
  function in pcie-hisi.
- Modify some value of items in pcie node example in binding document. 

Change from RFC:
- delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
  merge related operations into dw_pcie_host_init.

Link of v9:
- http://www.spinics.net/lists/linux-pci/msg44545.html
Link of v8:
- http://www.spinics.net/lists/linux-pci/msg44192.html
Link of v7:
- http://www.spinics.net/lists/devicetree/msg90690.html
Link of v6:
- http://www.spinics.net/lists/linux-pci/msg43669.html
Link of v5:
- http://www.spinics.net/lists/devicetree/msg87959.html
Link of v4:
- http://www.spinics.net/lists/arm-kernel/msg433050.html
Link of v3:
- http://www.spinics.net/lists/linux-pci/msg42539.html
Link of v2:
- http://www.spinics.net/lists/linux-pci/msg41844.html
Link of RFC v1:
- http://www.spinics.net/lists/linux-pci/msg41305.html
Link of RFC:
- http://www.spinics.net/lists/linux-pci/msg40434.html

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/359741.html

Zhou Wang (4):
  PCI: designware: Add ARM64 support
  PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
  Documentation: DT: Add HiSilicon PCIe host binding
  MAINTAINERS: Add pcie-hisi maintainer

gabriele paoloni (2):
  PCI: designware: move calculation of bus addresses to DRA7xx
  ARM/PCI: remove align_resource in pci_sys_data

 .../bindings/arm/hisilicon/hisilicon.txt   |  17 ++
 .../devicetree/bindings/pci/hisilicon-pcie.txt |  44 +++
 MAINTAINERS|   7 +
 arch/arm/include/asm/mach/pci.h|   6 -
 arch/arm/kernel/bios32.c   |  12 +-
 drivers/pci/host/Kconfig   |   8 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pci-dra7xx.c  |  13 +
 drivers/pci/host/pci-keystone-dw.c |   2 +-
 drivers/pci/host/pcie-designware.c | 245 +---
 drivers/pci/host/pcie-designware.h |  14 +-
 drivers/pci/host/pcie-hisi.c   | 320 +
 12 files changed, 501 insertions(+), 188 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 create mode 100644 drivers/pci/host/pcie-hisi.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 v10 6/6] MAINTAINERS: Add pcie-hisi maintainer

[Zhou Wang]

Signed-off-by: Zhou Wang 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..944a229 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8047,6 +8047,13 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
 F: drivers/pci/host/pci-xgene-msi.c
 
+PCIE DRIVER FOR HISILICON
+M: Zhou Wang 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+F: drivers/pci/host/pcie-hisi.c
+
 PCMCIA SUBSYSTEM
 P: Linux PCMCIA Team
 L: linux-pcm...@lists.infradead.org
-- 
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 v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Zhou Wang]

This patch adds PCIe host support for HiSilicon SoC Hip05.

Signed-off-by: Zhou Wang 
Signed-off-by: Gabriele Paoloni 
Signed-off-by: liudongdong 
Signed-off-by: Kefeng Wang 
Signed-off-by: qiuzhenfa 
---
 drivers/pci/host/Kconfig |   8 ++
 drivers/pci/host/Makefile|   1 +
 drivers/pci/host/pcie-hisi.c | 320 +++
 3 files changed, 329 insertions(+)
 create mode 100644 drivers/pci/host/pcie-hisi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..ae873be 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
  Say Y here if you want to use the Broadcom iProc PCIe controller
  through the BCMA bus interface
 
+config PCI_HISI
+   depends on OF && ARM64
+   bool "HiSilicon SoC HIP05 PCIe controller"
+   select PCIEPORTBUS
+   select PCIE_DW
+   help
+ Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..ea1dbf2 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
 obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
new file mode 100644
index 000..26aa0d9
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi.c
@@ -0,0 +1,320 @@
+/*
+ * PCIe host controller driver for HiSilicon Hip05 SoC
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang 
+ * Dacai Zhu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pcie-designware.h"
+
+#define PCIE_SUBCTRL_MODE_REG   0x2800
+#define PCIE_SUBCTRL_SYS_STATE4_REG 0x6818
+#define PCIE_SLV_DBI_MODE   0x0
+#define PCIE_SLV_SYSCTRL_MODE   0x1
+#define PCIE_SLV_CONTENT_MODE   0x2
+#define PCIE_SLV_MSI_ASID   0x10
+#define PCIE_LTSSM_LINKUP_STATE 0x11
+#define PCIE_LTSSM_STATE_MASK   0x3F
+#define PCIE_MSI_ASID_ENABLE(0x1 << 12)
+#define PCIE_MSI_ASID_VALUE (0x1 << 16)
+#define PCIE_MSI_TRANS_ENABLE   (0x1 << 12)
+#define PCIE_MSI_TRANS_REG  0x1c8
+#define PCIE_MSI_LOW_ADDRESS0x1b4
+#define PCIE_MSI_HIGH_ADDRESS   0x1c4
+#define PCIE_GITS_TRANSLATER0x10040
+
+#define PCIE_SYS_CTRL20_REG 0x20
+#define PCIE_RD_TAB_SEL BIT(31)
+#define PCIE_RD_TAB_EN  BIT(30)
+
+#define to_hisi_pcie(x)container_of(x, struct hisi_pcie, pp)
+
+struct hisi_pcie {
+   struct regmap *subctrl;
+   void __iomem *reg_base;
+   u32 port_id;
+   struct pcie_port pp;
+};
+
+static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
+   u32 val, u32 reg)
+{
+   writel(val, pcie->reg_base + reg);
+}
+
+static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
+{
+   return readl(pcie->reg_base + reg);
+}
+
+/*
+ * Change mode to indicate the same reg_base to base of PCIe host configure
+ * registers, base of RC configure space or base of vmid/asid context table
+ */
+static void hisi_pcie_change_apb_mode(struct hisi_pcie *pcie, u32 mode)
+{
+   u32 val;
+   u32 bit_mask;
+   u32 bit_shift;
+   u32 port_id = pcie->port_id;
+   u32 reg = PCIE_SUBCTRL_MODE_REG + 0x100 * port_id;
+
+   if ((port_id == 1) || (port_id == 2)) {
+   bit_mask = 0xc;
+   bit_shift = 0x2;
+   } else {
+   bit_mask = 0x6;
+   bit_shift = 0x1;
+   }
+
+   regmap_update_bits(pcie->subctrl, reg, bit_mask, mode << bit_shift);
+}
+
+/* Configure vmid/asid table in PCIe host */
+static void hisi_pcie_config_context(struct hisi_pcie *pcie)
+{
+   int i;
+   u32 val;
+
+   /* enable to clean vmid and asid tables though apb bus */
+   hisi_pcie_change_apb_mode(pcie, PCIE_SLV_SYSCTRL_MODE);
+
+   val = hisi_pcie_apb_readl(pcie, 

[PATCH v10 1/6] PCI: designware: move calculation of bus addresses to DRA7xx

[Zhou Wang]

From: gabriele paoloni 

Commit f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated
address") added the calculation of PCI BUS addresses in designware,
storing them in new fields added in "struct pcie_port". This
calculation is done for every designware user even if is only
applicable to DRA7xx.
This patch moves the calculation of the bus addresses to the DRA7xx
driver and is needed to allow the rework of designware to use
the new DT parsing API.

Signed-off-by: Gabriele Paoloni 
Signed-off-by: Zhou Wang 
Acked-by: Pratyush Anand 
---
 drivers/pci/host/pci-dra7xx.c  | 13 +
 drivers/pci/host/pcie-designware.c | 15 ---
 2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 199e29a..ebdffa0 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -62,6 +62,7 @@
 
 #definePCIECTRL_DRA7XX_CONF_PHY_CS 0x010C
 #defineLINK_UP BIT(16)
+#defineCPU_TO_BUS_ADDR 0x0FFF
 
 struct dra7xx_pcie {
void __iomem*base;
@@ -151,6 +152,18 @@ static void dra7xx_pcie_enable_interrupts(struct pcie_port 
*pp)
 static void dra7xx_pcie_host_init(struct pcie_port *pp)
 {
dw_pcie_setup_rc(pp);
+
+   if (pp->io_mod_base)
+   pp->io_mod_base &= CPU_TO_BUS_ADDR;
+
+   if (pp->mem_mod_base)
+   pp->mem_mod_base &= CPU_TO_BUS_ADDR;
+
+   if (pp->cfg0_mod_base) {
+   pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
+   pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
+   }
+
dra7xx_pcie_establish_link(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
dw_pcie_msi_init(pp);
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 52aa6e3..75338a6 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -365,14 +365,10 @@ int dw_pcie_host_init(struct pcie_port *pp)
struct of_pci_range range;
struct of_pci_range_parser parser;
struct resource *cfg_res;
-   u32 val, na, ns;
+   u32 val, ns;
const __be32 *addrp;
int i, index, ret;
 
-   /* Find the address cell size and the number of cells in order to get
-* the untranslated address.
-*/
-   of_property_read_u32(np, "#address-cells", );
ns = of_n_size_cells(np);
 
cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
@@ -415,8 +411,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->io_base = range.cpu_addr;
 
/* Find the untranslated IO space address */
-   pp->io_mod_base = of_read_number(parser.range -
-parser.np + na, ns);
+   pp->io_mod_base = range.cpu_addr;
}
if (restype == IORESOURCE_MEM) {
of_pci_range_to_resource(, np, >mem);
@@ -425,8 +420,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->mem_bus_addr = range.pci_addr;
 
/* Find the untranslated MEM space address */
-   pp->mem_mod_base = of_read_number(parser.range -
- parser.np + na, ns);
+   pp->mem_mod_base = range.cpu_addr;
}
if (restype == 0) {
of_pci_range_to_resource(, np, >cfg);
@@ -436,8 +430,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->cfg1_base = pp->cfg.start + pp->cfg0_size;
 
/* Find the untranslated configuration space address */
-   pp->cfg0_mod_base = of_read_number(parser.range -
-  parser.np + na, ns);
+   pp->cfg0_mod_base = range.cpu_addr;
pp->cfg1_mod_base = pp->cfg0_mod_base +
pp->cfg0_size;
}
-- 
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 v10 2/6] ARM/PCI: remove align_resource in pci_sys_data

[Zhou Wang]

From: gabriele paoloni 

This patch is needed in order to unify the PCIe designware framework for ARM and
ARM64 architectures. In the PCIe designware unification process we are calling
pci_create_root_bus() passing a "sysdata" parameter that is the same for both
ARM and ARM64 and is of type "struct pcie_port*". In the ARM case this will
cause a problem with the function pcibios_align_resource(); in fact this will
cast "dev->sysdata" to "struct pci_sys_data*", whereas designware had passed a
"struct pcie_port*" pointer.

This patch solves the issue by removing "align_resource" from "pci_sys_data"
struct and defining a static global function pointer in "bios32.c"

Signed-off-by: Gabriele Paoloni 
Signed-off-by: Zhou Wang 
Acked-by: Pratyush Anand 
---
 arch/arm/include/asm/mach/pci.h |  6 --
 arch/arm/kernel/bios32.c| 12 
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 8857d28..0070e85 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -52,12 +52,6 @@ struct pci_sys_data {
u8  (*swizzle)(struct pci_dev *, u8 *);
/* IRQ mapping  
*/
int (*map_irq)(const struct pci_dev *, u8, u8);
-   /* Resource alignement requirements 
*/
-   resource_size_t (*align_resource)(struct pci_dev *dev,
- const struct resource *res,
- resource_size_t start,
- resource_size_t size,
- resource_size_t align);
void*private_data;  /* platform controller private data 
*/
 };
 
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 874e182..6551d28 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -17,6 +17,11 @@
 #include 
 
 static int debug_pci;
+static resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align) = NULL;
 
 /*
  * We can't use pci_get_device() here since we are
@@ -456,7 +461,7 @@ static void pcibios_init_hw(struct device *parent, struct 
hw_pci *hw,
sys->busnr   = busnr;
sys->swizzle = hw->swizzle;
sys->map_irq = hw->map_irq;
-   sys->align_resource = hw->align_resource;
+   align_resource = hw->align_resource;
INIT_LIST_HEAD(>resources);
 
if (hw->private_data)
@@ -572,7 +577,6 @@ resource_size_t pcibios_align_resource(void *data, const 
struct resource *res,
resource_size_t size, resource_size_t align)
 {
struct pci_dev *dev = data;
-   struct pci_sys_data *sys = dev->sysdata;
resource_size_t start = res->start;
 
if (res->flags & IORESOURCE_IO && start & 0x300)
@@ -580,8 +584,8 @@ resource_size_t pcibios_align_resource(void *data, const 
struct resource *res,
 
start = (start + align - 1) & ~(align - 1);
 
-   if (sys->align_resource)
-   return sys->align_resource(dev, res, start, size, align);
+   if (align_resource)
+   return align_resource(dev, res, start, size, align);
 
return start;
 }
-- 
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: [RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)

[Krzysztof Kozlowski]

W dniu 10.10.2015 o 04:18, Kevin Hilman pisze:
> Hi Krzystof,
> 
> Krzysztof Kozlowski <k.kozlow...@samsung.com> writes:
> 
>> Introduction
>> 
>> This patchset tries to fix probing of usb3503 on Arndale board
>> if the Samsung PHY driver is probed later (or built as a module).
>>
>> *The patchset was not tested on Arndale board.*
>> I don't have that board. Please test it and say if the usb3503 deferred probe
>> works fine and the issue is solved.
> 
> FYI... I built this series on top of  next-20151009 and using
> exynos_defconfig.  I booted it on my arndale, and I still don't see the
> networking come up.  Full boot log attached.

+cc Tyler

Kevin,
Thanks for testing but I am not sure if this boot failure is related to
the patch. I mean if the patch should fix this particular boot failure.
The board stopped to boot after enabling DWC2 and network USB gadget:
http://www.spinics.net/lists/linux-samsung-soc/msg47009.html

The boot log shows that usb3503 was probed but asix network adapter was
not. I wonder how these things are related to each other...

Nevertheless it would be difficult to debug the issue without the
Arndale board. :)

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

Re: [RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

[Kishon Vijay Abraham I]

Hi,

On Saturday 10 October 2015 04:46 AM, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> On Saturday 10 October 2015 04:20 AM, Bjorn Helgaas wrote:
>> [+cc Arnd, Rob]
>>
>> On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
>>> Add driver modifications in pci-dra7xx to get x2 mode working in
>>> DRA72 and DRA74. Certain modifications is needed in PHY driver also
>>> which I'll send as a separate series.
>>>
>>> Kishon Vijay Abraham I (2):
>>>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
>>>   pci: host: pci-dra7xx: Enable x2 mode support
>>
>> Applied to pci/host-dra7xx for v4.4, thanks!
>>
>> I adjusted the subject line capitalization & format to match the history.
>>
>> Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
>> strings in "phy-names" changes?
> 
> I sent it as RFC since I didn't have the board to test 2 lane mode with
> $patch. And just now I got a board to test x2 and I found a problem with
> the 2nd patch.
> 
> .b1co_mode_sel_mask = GENMASK(2, 3), in the patch should be replaced with
> .b1co_mode_sel_mask = GENMASK(3, 2).
> 
> I'll resend the patch fixing the above.

I'll resend after a couple of days to fix any comments from Arnd or Rob.

Thanks
Kishon

> 
> Thanks
> Kishon
> --
> 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 v3 1/7] drm/vc4: Add devicetree bindings for VC4.

[Sebastian Reichel]

Hi,

On Fri, Oct 09, 2015 at 02:27:42PM -0700, Eric Anholt wrote:
> VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
> other Broadcom SoCs.
> 
> This binding follows the model of msm, imx, sti, and others, where
> there is a subsystem node for the whole GPU, with nodes for the
> individual HW components within it.

I think it would be useful to have the acronyms written out one time
in the document (VC4, HVS).

-- Sebastian


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/8] clk: qoriq: Move chip-specific knowledge into driver

[Scott Wood]

On Thu, 2015-10-01 at 19:26 -0500, Scott Wood wrote:
> [Resending to updated e-mail address]
> 
> On Tue, 2015-08-11 at 11:25 -0700, Michael Turquette wrote:
> > Hi Scott,
> > 
> > Quoting Scott Wood (2015-06-18 19:49:10)
> > > The existing device tree bindings are error-prone and inflexible. 
> > > Correct the mistake by moving the knowledge into the driver, which
> > > has more flexibility in describing the quirks of each chip.  This leaves
> > > the device tree to its proper role of identifying a programming 
> > > interface
> > > rather than describing its individual registers.
> > 
> > Sorry for not responding to this one sooner. Fell through the cracks.
> > 
> > All of the changes to drives/clk/clk-qoriq.c look great to me. I assume
> > you need to keep all of these patches together and want to the take
> > through the freescale tree? If so feel free to add,
> > 
> > Acked-by: Michael Turquette 
> 
> Is the ack still valid for the v3 patchset?

ping

-Scott

--
To unsubscribe from this list: send the line "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 3/6] pci:host: Add Altera PCIe host controller driver

[Bjorn Helgaas]

On Thu, Oct 08, 2015 at 06:03:24PM +0800, Ley Foon Tan wrote:
> On Thu, Oct 8, 2015 at 5:47 PM, Russell King - ARM Linux
>  wrote:
> >
> > On Thu, Oct 08, 2015 at 05:43:11PM +0800, Ley Foon Tan wrote:
> > > +static int altera_pcie_cfg_write(struct pci_bus *bus, unsigned int devfn,
> > > +  int where, int size, u32 value)
> > > +{
> > > + struct altera_pcie *pcie = bus->sysdata;
> > > + u32 data32;
> > > + u32 shift = 8 * (where & 3);
> > > + int ret;
> > > +
> > > + if (!altera_pcie_valid_config(pcie, bus, PCI_SLOT(devfn)))
> > > + return PCIBIOS_DEVICE_NOT_FOUND;
> > > +
> > > + /* write partial */
> > > + if (size != sizeof(u32)) {
> > > + ret = tlp_cfg_dword_read(pcie, bus->number, devfn,
> > > +  where & ~DWORD_MASK, );
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > + switch (size) {
> > > + case 1:
> > > + data32 = (data32 & ~(0xff << shift)) |
> > > + ((value & 0xff) << shift);
> > > + break;
> > > + case 2:
> > > + data32 = (data32 & ~(0x << shift)) |
> > > + ((value & 0x) << shift);
> > > + break;
> > > + default:
> > > + data32 = value;
> >
> > Can you generate proper 1, 2 and 4 byte configuration accesses?  That
> > is much preferred over the above read-modify-write, as there are
> > registers in PCI and PCIe that are read/write-1-to-clear.  The above
> > has the effect of inadvertently clearing those RW1C bits.
> No, hardware can only access 4-byte aligned address.

This is non-spec compliant, and we really should have some way of
flagging that because it may break things in ways that would be very
difficult to debug, e.g., we can lose RW1C status bits when writing an
adjacent register, so they would just silently disappear.

I don't know if this should be a kernel taint, a simple warning in
dmesg, or what.  I guess the tainting mechanism is probably too
general-purpose for this, and add_taint() doesn't give any dmesg
indication.  We wouldn't see the taint unless the problem actually
caused an oops or panic.  In this case, I think I want a clue in dmesg
so we have a chance of seeing it even if there is no oops.  So
probably something like a dev_warn("non-compliant config accesses")
would work.

You really should double-check with the hardware guys, because it's
pretty obvious that the PCI spec requires 1- and 2-byte config
accesses to work correctly.  For example, if you read/modify/write to
update PCI_COMMAND, you will inadvertently clear the RW1C bits in
PCI_STATUS.

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

Re: [PATCH 09/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Stephen Boyd]

On 10/02, Jon Mason wrote:
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 23800a1..2790f21 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -2,6 +2,7 @@ menu "Platform selection"
>  
>  config ARCH_BCM_IPROC
>   bool "Broadcom iProc SoC Family"
> + select COMMON_CLK_IPROC

Given that this is a visible option, I'd expect the defconfig to
enable this.

>   help
> This enables support for Broadcom iProc based SoCs
>  
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index d08b3e5..ea81eaa 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -47,7 +47,8 @@ obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_XGENE)   += clk-xgene.o
>  obj-$(CONFIG_COMMON_CLK_PWM) += clk-pwm.o
>  obj-$(CONFIG_COMMON_CLK_AT91)+= at91/
> -obj-$(CONFIG_ARCH_BCM)   += bcm/
> +obj-$(CONFIG_CLK_BCM_KONA)   += bcm/
> +obj-$(CONFIG_COMMON_CLK_IPROC)   += bcm/

Also, perhaps we need some sort of Kconfig thing for overall bcm
clock drivers, so that we don't have duplicate Makefile rules.

config COMMON_CLK_BCM
bool "Support for Broadcom clocks"

-- 
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 1/2] clk: imx6: Add SPDIF_GCLK clock in clock tree

[Shawn Guo]

On Fri, Oct 09, 2015 at 05:15:30PM +0800, Shengjiu Wang wrote:
> SPDIF_GCLK is also spdif's clock, it use a same enable bit with 
> SPDIF_ROOT_CLK,
> We didn't separate them in clock tree before.

Is it the clock described as "Global clock" in Reference Manual, SPDIF
chapter?  If that's the case, you are just adding a missing SPDIF clock
rather than fixing a low power mode issue, and I will be fine.  But
still you should reword the commit log to make it clear, that the patch
is to correct a SPDIF clock setting issue, which is just discovered by
low power mode support.

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

[PATCH] ARM: dts: sun7i: Correct USB regulators on pcDuino v3 Nano

[Adam Sampson]

The LinkSprite pcDuino v3 Nano's two USB host ports are powered by a
single RT9701GB regulator, which has its enable input tied to the A20's
PD2 pin, pulled up to 3v3 via a 10k resistor.

However, the script.bin that shipped with the device listed PH11 and PH3
as Vbus control pins for the two USB ports. Neither of these are
actually connected to anything.

Siarhei Siamashka spotted this problem while reviewing the other
LinkSprite boards. This patch fixes it by only defining a single
regulator, controlled by PD2. Testing shows that the USB ports are now
(correctly) only powered up once the USB PHY driver is loaded.

Signed-off-by: Adam Sampson 
---
 arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts 
b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
index 5361fce..f75e3bd 100644
--- a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
+++ b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
@@ -158,7 +158,7 @@
};
 
usb1_vbus_pin_pcduino3_nano: usb1_vbus_pin@0 {
-   allwinner,pins = "PH11";
+   allwinner,pins = "PD2";
allwinner,function = "gpio_out";
allwinner,drive = ;
allwinner,pull = ;
@@ -166,18 +166,17 @@
 };
 
 _ahci_5v {
+   pinctrl-names = "default";
pinctrl-0 = <_pwr_pin_pcduino3_nano>;
gpio = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
status = "okay";
 };
 
+/* A single regulator (U24) powers both USB host ports. */
 _usb1_vbus {
+   pinctrl-names = "default";
pinctrl-0 = <_vbus_pin_pcduino3_nano>;
-   gpio = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
-   status = "okay";
-};
-
-_usb2_vbus {
+   gpio = < 3 2 GPIO_ACTIVE_HIGH>; /* PD2 */
status = "okay";
 };
 
@@ -189,6 +188,6 @@
 
  {
usb1_vbus-supply = <_usb1_vbus>;
-   usb2_vbus-supply = <_usb2_vbus>;
+   usb2_vbus-supply = <_usb1_vbus>;
status = "okay";
 };
-- 
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: [linux-sunxi] [PATCH] ARM: dts: sun7i: Correct USB regulators on pcDuino v3 Nano

[Chen-Yu Tsai]

Hi,

On Sat, Oct 10, 2015 at 9:47 AM, Adam Sampson  wrote:
> The LinkSprite pcDuino v3 Nano's two USB host ports are powered by a
> single RT9701GB regulator, which has its enable input tied to the A20's
> PD2 pin, pulled up to 3v3 via a 10k resistor.
>
> However, the script.bin that shipped with the device listed PH11 and PH3
> as Vbus control pins for the two USB ports. Neither of these are
> actually connected to anything.
>
> Siarhei Siamashka spotted this problem while reviewing the other
> LinkSprite boards. This patch fixes it by only defining a single
> regulator, controlled by PD2. Testing shows that the USB ports are now
> (correctly) only powered up once the USB PHY driver is loaded.
>
> Signed-off-by: Adam Sampson 

Since Siarhei spotted the issue, maybe add a Reported-by tag where credit
is due?

> ---
>  arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts 
> b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
> index 5361fce..f75e3bd 100644
> --- a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
> @@ -158,7 +158,7 @@
> };
>
> usb1_vbus_pin_pcduino3_nano: usb1_vbus_pin@0 {
> -   allwinner,pins = "PH11";
> +   allwinner,pins = "PD2";
> allwinner,function = "gpio_out";
> allwinner,drive = ;
> allwinner,pull = ;
> @@ -166,18 +166,17 @@
>  };
>
>  _ahci_5v {
> +   pinctrl-names = "default";

This is already in sunxi-common-regulators.dtsi.
No need to add it again.

> pinctrl-0 = <_pwr_pin_pcduino3_nano>;
> gpio = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> status = "okay";
>  };
>
> +/* A single regulator (U24) powers both USB host ports. */
>  _usb1_vbus {
> +   pinctrl-names = "default";

And this.

The rest looks good.

Thanks!
ChenYu

> pinctrl-0 = <_vbus_pin_pcduino3_nano>;
> -   gpio = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
> -   status = "okay";
> -};
> -
> -_usb2_vbus {
> +   gpio = < 3 2 GPIO_ACTIVE_HIGH>; /* PD2 */
> status = "okay";
>  };
>
> @@ -189,6 +188,6 @@
>
>   {
> usb1_vbus-supply = <_usb1_vbus>;
> -   usb2_vbus-supply = <_usb2_vbus>;
> +   usb2_vbus-supply = <_usb1_vbus>;
> status = "okay";
>  };
> --
> 2.1.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "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/7] drm/vc4: Use the fbdev_cma helpers

[Eric Anholt]

From: Derek Foreman 

Keep the fbdev_cma pointer around so we can use it on hotplog and close
to ensure the frame buffer console is in a useful state.

Signed-off-by: Derek Foreman 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 14 ++
 drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
 drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 3c3ccff..6e73060 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "drm_fb_cma_helper.h"
 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
@@ -49,6 +50,14 @@ static void vc4_drm_preclose(struct drm_device *dev, struct 
drm_file *file)
vc4_cancel_page_flip(crtc, file);
 }
 
+static void vc4_lastclose(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4->fbdev)
+   drm_fbdev_cma_restore_mode(vc4->fbdev);
+}
+
 static const struct file_operations vc4_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -71,6 +80,7 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_ATOMIC |
DRIVER_GEM |
DRIVER_PRIME),
+   .lastclose = vc4_lastclose,
.preclose = vc4_drm_preclose,
 
.enable_vblank = vc4_enable_vblank,
@@ -199,6 +209,10 @@ static void vc4_drm_unbind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = platform_get_drvdata(pdev);
+   struct vc4_dev *vc4 = to_vc4_dev(drm);
+
+   if (vc4->fbdev)
+   drm_fbdev_cma_fini(vc4->fbdev);
 
drm_mode_config_cleanup(drm);
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c710e03..23e7bac2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -15,6 +15,8 @@ struct vc4_dev {
struct vc4_hdmi *hdmi;
struct vc4_hvs *hvs;
struct vc4_crtc *crtc[3];
+
+   struct drm_fbdev_cma *fbdev;
 };
 
 static inline struct vc4_dev *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index c241c8f..ee3e004 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -21,7 +21,16 @@
 #include "drm_fb_cma_helper.h"
 #include "vc4_drv.h"
 
+static void vc4_output_poll_changed(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4->fbdev)
+   drm_fbdev_cma_hotplug_event(vc4->fbdev);
+}
+
 static const struct drm_mode_config_funcs vc4_mode_funcs = {
+   .output_poll_changed = vc4_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.fb_create = drm_fb_cma_create,
@@ -29,6 +38,7 @@ static const struct drm_mode_config_funcs vc4_mode_funcs = {
 
 int vc4_kms_load(struct drm_device *dev)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
 
ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
@@ -44,9 +54,11 @@ int vc4_kms_load(struct drm_device *dev)
 
drm_mode_config_reset(dev);
 
-   drm_fbdev_cma_init(dev, 32,
-  dev->mode_config.num_crtc,
-  dev->mode_config.num_connector);
+   vc4->fbdev = drm_fbdev_cma_init(dev, 32,
+   dev->mode_config.num_crtc,
+   dev->mode_config.num_connector);
+   if (IS_ERR(vc4->fbdev))
+   vc4->fbdev = NULL;
 
drm_kms_helper_poll_init(dev);
 
-- 
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/7] drm/vc4: Add devicetree bindings for VC4.

[Eric Anholt]

VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
other Broadcom SoCs.

This binding follows the model of msm, imx, sti, and others, where
there is a subsystem node for the whole GPU, with nodes for the
individual HW components within it.

Signed-off-by: Eric Anholt 
---

v2: Extend the commit message, fix several nits from Stephen Warren.
v3: Rename the compatibility strings, clean up node names, drop the
unnecessary lists of components.  Use compatibility strings for
choosing CRTC HVS channel numbers.  Document the HDMI clock usage.

 .../devicetree/bindings/gpu/brcm,bcm-vc4.txt   | 64 ++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
new file mode 100644
index 000..175bcde
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
@@ -0,0 +1,64 @@
+Broadcom VC4 GPU
+
+The VC4 device present on the Raspberry Pi includes a display system
+with HDMI output and the HVS scaler for compositing display planes.
+
+Required properties for VC4:
+- compatible:  Should be "brcm,bcm2835-vc4"
+
+Required properties for Pixel Valve:
+- compatible:  Should be one of "brcm,bcm2835-pixelvalve0",
+   "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
+- reg: Physical base address and length of the PV's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HVS:
+- compatible:  Should be "brcm,bcm2835-hvs"
+- reg: Physical base address and length of the HVS's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HDMI
+- compatible:  Should be "brcm,bcm2835-hdmi"
+- reg: Physical base address and length of the two register ranges
+ ("HDMI" and "HD", in that order)
+- interrupts:  The interrupt numbers
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+- ddc: phandle of the I2C controller used for DDC EDID probing
+- clocks:  a) hdmi: The HDMI state machine clock
+   b) pixel: The pixel clock.
+
+Optional properties for HDMI:
+- hpd-gpio:The GPIO pin for HDMI hotplug detect (if it doesn't appear
+ as an interrupt/status bit in the HDMI controller
+ itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt
+
+Example:
+pixelvalve@7e807000 {
+   compatible = "brcm,bcm2835-pixelvalve2";
+   reg = <0x7e807000 0x100>;
+   interrupts = <2 10>; /* pixelvalve */
+};
+
+hvs@7e40 {
+   compatible = "brcm,bcm2835-hvs";
+   reg = <0x7e40 0x6000>;
+   interrupts = <2 1>;
+};
+
+hdmi: hdmi@7e902000 {
+   compatible = "brcm,bcm2835-hdmi";
+   reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+   interrupts = <2 8>, <2 9>;
+   ddc = <>;
+   hpd-gpio = < 46 GPIO_ACTIVE_HIGH>;
+   clocks = < BCM2835_PLLH_PIX>,
+< BCM2835_CLOCK_HSM>;
+   clock-names = "pixel", "hdmi";
+};
+
+vc4: gpu@7e4c {
+   compatible = "brcm,bcm2835-vc4";
+};
-- 
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] ARM: shmobile: porter: add QSPI DT support

[Sergei Shtylyov]

Define the Porter board dependent part of the QSPI device node.
Add device nodes  for Spansion  S25FL512S SPI flash and the MTD partitions
on it.

This patch is  mostly analogous  to the commit f59838d44835 ("ARM:
shmobile: henninger: add QSPI 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 and VIN0/ADV7180 patches posted earlier.

Changes in version 2:
- fixed the commit citing style and reformatted that whole paragraph.

 arch/arm/boot/dts/r8a7791-porter.dts |   38 +++
 1 file changed, 38 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
@@ -110,6 +110,11 @@
renesas,function = "sdhi2";
};
 
+   qspi_pins: spi0 {
+   renesas,groups = "qspi_ctrl", "qspi_data4";
+   renesas,function = "qspi";
+   };
+
i2c2_pins: i2c2 {
renesas,groups = "i2c2";
renesas,function = "i2c2";
@@ -165,6 +170,39 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+
+   flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spansion,s25fl512s", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <3000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   m25p,fast-read;
+
+   partition@0 {
+   label = "loader_prg";
+   reg = <0x 0x0004>;
+   read-only;
+   };
+   partition@4 {
+   label = "user_prg";
+   reg = <0x0004 0x0040>;
+   read-only;
+   };
+   partition@44 {
+   label = "flash_fs";
+   reg = <0x0044 0x03bc>;
+   };
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";

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

Re: [PATCH v3 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Emil Velikov]

Hi Eric,

On 9 October 2015 at 22:27, Eric Anholt  wrote:
> Signed-off-by: Eric Anholt 
> ---
>
> v2: Mark it Supported, not Maintained.
>
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7ba7ab7..e331e46 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3653,6 +3653,12 @@ S:   Maintained
>  F: drivers/gpu/drm/sti
>  F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt
>
> +DRM DRIVERS FOR VC4
> +M: Eric Anholt 
> +T: git git://github.com/anholt/linux
You might want to add dri-devel as mailing list, at least initially.

> +S: Supported
> +F: drivers/gpu/drm/vc4/*
Imho, the binding documentation should also be listed here.

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

Re: [RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

[Bjorn Helgaas]

[+cc Arnd, Rob]

On Mon, Sep 28, 2015 at 06:27:36PM +0530, Kishon Vijay Abraham I wrote:
> Add driver modifications in pci-dra7xx to get x2 mode working in
> DRA72 and DRA74. Certain modifications is needed in PHY driver also
> which I'll send as a separate series.
> 
> Kishon Vijay Abraham I (2):
>   pci: host: pci-dra7xx: use "num-lanes" property to find phy count
>   pci: host: pci-dra7xx: Enable x2 mode support

Applied to pci/host-dra7xx for v4.4, thanks!

I adjusted the subject line capitalization & format to match the history.

Arnd, Rob, any comments on the DT updates or the "num-lanes" vs number of
strings in "phy-names" changes?

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

Re: [PATCH 02/10] clk: nsp: add clock support for Broadcom Northstar Plus SoC

[Stephen Boyd]

On 10/02, Jon Mason wrote:
> diff --git a/drivers/clk/bcm/clk-nsp.c b/drivers/clk/bcm/clk-nsp.c
> new file mode 100644
> index 000..708961a
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-nsp.c
> @@ -0,0 +1,139 @@
> +/*
> + * Copyright (C) 2015 Broadcom Corporation
> + *
> + * 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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; 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 

Is this used?

> +#include 
> +#include 

Is this used?

> +
> +#include 
> +#include "clk-iproc.h"

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

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

Re: [PATCH 05/10] clk: iproc: Add PLL base write function

[Stephen Boyd]

On 10/02, Jon Mason wrote:
> diff --git a/drivers/clk/bcm/clk-iproc-pll.c b/drivers/clk/bcm/clk-iproc-pll.c
> index e029ab3..a4602aa 100644
> --- a/drivers/clk/bcm/clk-iproc-pll.c
> +++ b/drivers/clk/bcm/clk-iproc-pll.c
> @@ -137,6 +137,18 @@ static int pll_wait_for_lock(struct iproc_pll *pll)
>   return -EIO;
>  }
>  
> +static void iproc_pll_write(struct iproc_pll *pll, void __iomem *base,

Seems that pll could be const too?

> + u32 offset, u32 val)
> +{
> + const struct iproc_pll_ctrl *ctrl = pll->ctrl;
> +

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

[Marc Zyngier]

On 09/10/15 06:11, Bharat Kumar Gogada wrote:
 +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.

Thanks for doing so, much appreciated.

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

No, your PCI controller can perfectly be part of the PCIe node.

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

If you want to keep them in the same file, please at least have two
separate patches. These are two different functions, and they should be
reviewed separately.

It will help everyone to understand your code, and speed up the
reviewing process.

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 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 */
+   

[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 = <>;
reg-shift = <2>;
status = "disabled";
+   pinctrl-0 = <_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

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

[Jisheng Zhang]

Hi Antoine,

On Thu, 8 Oct 2015 18:46:53 +0800
Jisheng Zhang  wrote:

> Hi Antoine,
> 
> On Fri, 2 Oct 2015 15:21:39 +0200
> Antoine Tenart  wrote:
> 
> > Hi Jisheng,
> > 
> > Sorry for the delay, I was quite busy these days...
> > 
> > Thanks for the nice comments!
> > 
> > I saw your using pin names in the BERLIN_PINCTRL_GROUP macro, like
> > "EMMC_RSTn". In other berlin pinctrl drivers we use the group name (such
> > as "G11" or GSM1"). If there is such a thing in the BG4CT, please
> > update.
> 
> From newer SoCs than BG2Q, ASIC began to use more meaningful names such
> as "EMMC_RSTn" as group name, there's no Gy or GSMy any more ;)
> 
> > 
> > On Mon, Sep 21, 2015 at 06:04:16PM +0800, Jisheng Zhang wrote:
> > [...]
> > > --- a/drivers/pinctrl/berlin/Kconfig
> > > +++ b/drivers/pinctrl/berlin/Kconfig
> > > @@ -17,4 +17,9 @@ config PINCTRL_BERLIN_BG2Q
> > >   bool
> > >   select PINCTRL_BERLIN
> > >  
> > > +config PINCTRL_BERLIN4CT
> > > + depends on OF && (ARCH_BERLIN || COMPILE_TEST)
> > > + bool "Marvell berlin4ct pin controller driver"
> > > + select PINCTRL_BERLIN
> > > +
> > >  endif
> > 
> > These dependencies also apply to the other Berlin pinctrl drivers, so
> > this should be on PINCTRL_BERLIN.
> 
> Will provide a separate patch to add this dependency

Hmm, other berlin pinctrl driver options are not user visible and are selected
by MACH_BERLIN_BGxx, but here option for BG4CT is user visible, so it's better
to keep the dependency as this patch does. I also found similar pattern in
other pinctrl drivers, what do you think?

Thanks,
Jisheng

> 
> > 
> > Is there a reason not to name the configuration option
> > PINCTRL_BERLIN_BG4CT, to be consistent with the existing?
> 
> There's no special reason. I just like the name be consistent with BERLINxYY
> used in dts, where, x= 2, 3, 4... YY may be CT, CD, etc. for example 
> berlin4ct.
> I could update in V3 if BERLIN_BGxYY is preferred
> 
> 
> > 
> > > diff --git a/drivers/pinctrl/berlin/berlin4ct.c 
> > > b/drivers/pinctrl/berlin/berlin4ct.c
> > > new file mode 100644
> > > index 000..88e1670
> > > --- /dev/null
> > > +++ b/drivers/pinctrl/berlin/berlin4ct.c
> > > +
> > > +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 */
> > > + BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* CMD */
> > > + BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO6 */
> > > + BERLIN_PINCTRL_GROUP("NAND_IO7", 

Re: [PATCH v4 8/8] ARM: multi_v7_defconfig: Add rockchip audio support

[Lee Jones]

Thanks an awful lot of people you've spammed there.

Are you sure they all care about your Rockchip changes?

Hint: I'm sure that they don't.

Please be careful and only send patches to relevant people.

> Enable support for audio device found on rockchip boards.
> 
> Signed-off-by: Sjoerd Simons 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/configs/multi_v7_defconfig | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 03deb7f..febce7e 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -478,6 +478,10 @@ CONFIG_SND_USB_AUDIO=y
>  CONFIG_SND_SOC=m
>  CONFIG_SND_ATMEL_SOC=m
>  CONFIG_SND_ATMEL_SOC_WM8904=m
> +CONFIG_SND_SOC_ROCKCHIP=m
> +CONFIG_SND_SOC_ROCKCHIP_SPDIF=m
> +CONFIG_SND_SOC_ROCKCHIP_MAX98090=m
> +CONFIG_SND_SOC_ROCKCHIP_RT5645=m
>  CONFIG_SND_SOC_SH4_FSI=m
>  CONFIG_SND_SOC_RCAR=m
>  CONFIG_SND_SOC_RSRC_CARD=m
> @@ -489,6 +493,7 @@ CONFIG_SND_SOC_TEGRA_TRIMSLICE=m
>  CONFIG_SND_SOC_TEGRA_ALC5632=m
>  CONFIG_SND_SOC_TEGRA_MAX98090=m
>  CONFIG_SND_SOC_AK4642=m
> +CONFIG_SND_SOC_SPDIF=m
>  CONFIG_SND_SOC_WM8978=m
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y

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

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

[Arnd Bergmann]

On Friday 09 October 2015 09:10:17 Marc Zyngier wrote:
> > 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'.
> 
> If you want to keep them in the same file, please at least have two
> separate patches. These are two different functions, and they should be
> reviewed separately.
> 
> It will help everyone to understand your code, and speed up the
> reviewing process.

Agreed. Also, the part we really want is to have the PCI controller
code decoupled enough from the MSI code that it will not require
further changes once Xilinx comes out with a chip that has a modern
GIC in it and the same PCIe host.

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 04/10] ARM: dts: enable clock support for BCM5301X

[Stephen Boyd]

On 10/02, Jon Mason wrote:
> Replace current device tree dummy clocks with real clock support for
> Broadcom Northstar SoCs.
> 
> Signed-off-by: Jon Mason 
> ---

I'd rather not take any dts changes through clk tree.

>  arch/arm/boot/dts/bcm5301x.dtsi | 67 
> -
>  1 file changed, 60 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index 6f50f67..f717859 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -55,14 +56,14 @@
>   compatible = "arm,cortex-a9-global-timer";
>   reg = <0x0200 0x100>;
>   interrupts = ;
> - clocks = <_periph>;
> + clocks = <_clk>;
>   };
>  
>   local-timer@0600 {
>   compatible = "arm,cortex-a9-twd-timer";
>   reg = <0x0600 0x100>;
>   interrupts = ;
> - clocks = <_periph>;
> + clocks = <_clk>;
>   };
>  
>   gic: interrupt-controller@1000 {
> @@ -94,14 +95,66 @@
>  
>   clocks {

I'd expect this to only contain nodes that don't have a reg
property. Clock providers that have a reg property would go into
some soc node or bus. Perhaps that's the chipcommonA node, or
axi?

>   #address-cells = <1>;
> - #size-cells = <0>;
> + #size-cells = <1>;
> + ranges;
>  
> - /* As long as we do not have a real clock driver us this
> -  * fixed clock */
> - clk_periph: periph {
> + osc: oscillator {
> + #clock-cells = <0>;
>   compatible = "fixed-clock";
> + clock-frequency = <2500>;
> + };
> +
> + lcpll0: lcpll0@1800c100 {
> + #clock-cells = <1>;
> + compatible = "brcm,nsp-lcpll0";
> + reg = <0x1800c100 0x14>;
> + clocks = <>;
> + clock-output-names = "lcpll0", "pcie_phy", "sdio",
> +  "ddr_phy";
> + };
> +
> + genpll: genpll@1800c140 {
> + #clock-cells = <1>;
> + compatible = "brcm,nsp-genpll";
> + reg = <0x1800c140 0x24>;
> + clocks = <>;
> + clock-output-names = "genpll", "phy", "ethernetclk",
> +  "usbclk", "iprocfast", "sata1",
> +  "sata2";
> + };
> +
> + iprocmed: iprocmed {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clocks = < BCM_NSP_GENPLL_IPROCFAST_CLK>;
> + clock-div = <2>;
> + clock-mult = <1>;
> + clock-output-names = "iprocmed";
> + };
> +
> + iprocslow: iprocslow {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clocks = < BCM_NSP_GENPLL_IPROCFAST_CLK>;
> + clock-div = <4>;
> + clock-mult = <1>;
> + clock-output-names = "iprocslow";
> + };
> +
> +
> + a9pll: arm_clk@1900 {
> + #clock-cells = <0>;
> + compatible = "brcm,nsp-armpll";
> + clocks = <>;
> + reg = <0x1900 0x1000>;
> + };
> +
> + periph_clk: periph_clk {
>   #clock-cells = <0>;
> - clock-frequency = <4>;
> + compatible = "fixed-factor-clock";
> + clocks = <>;
> + clock-div = <2>;
> + clock-mult = <1>;
>   };
>   };
>  

We're trying to move away from putting individual clocks into DT
like this. Is there some sort of clock controller that's at
0x1800c000, but we're just not exposing all the clocks in there?
See this thread for more information on why we'd like to avoid
this sort of design:

http://lkml.kernel.org/r/<20150416192014.19585.9663@quantum>

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

[PATCH v3 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.

[Eric Anholt]

We need to use it for getting video modes over HDMI.

Signed-off-by: Eric Anholt 
Acked-by: Stephen Warren 
---

v2: Mark it as disabled by default, and enable it in bcm2835-rpi.

 arch/arm/boot/dts/bcm2835-rpi.dtsi |  4 
 arch/arm/boot/dts/bcm2835.dtsi | 10 ++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index ab5474e..3572f03 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -52,6 +52,10 @@
clock-frequency = <10>;
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
bus-width = <4>;
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index a6a55b7..1e61eb7 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -167,6 +167,16 @@
status = "disabled";
};
 
+   i2c2: i2c@7e805000 {
+   compatible = "brcm,bcm2835-i2c";
+   reg = <0x7e805000 0x1000>;
+   interrupts = <2 21>;
+   clocks = < BCM2835_CLOCK_VPU>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
-- 
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 0/2] arm: mvebu: disable unused rtc + cosmetic patch for ReadyNAS devices

[Arnaud Ebalard]

Hi,

Here are two simple patches for Armada-based ReadyNAS devices.

The first one disables Armada 370/XP rtc in the .dts files of ReadyNAS
102, 104 and 2120 devices. Those use an Intersil ISL12057 I2C RTC chip
and do not use the internal Armada RTC. Because it is enabled in
included armada-370-xp.dtsi, it just pollutes logs during boot.

While writing the patches, I noticed RN2120 .dts file has nodes that
are badly ordered under internal-regs. This second patch fixes
that. Note that it depends on first patch. 

Arnaud Ebalard (2):
  arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120
  arm: mvebu: reorder internal-regs nodes by address in RN2120 .dts file

 arch/arm/boot/dts/armada-370-netgear-rn102.dts |  6 ++
 arch/arm/boot/dts/armada-370-netgear-rn104.dts |  6 ++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 86 ++
 3 files changed, 58 insertions(+), 40 deletions(-)

-- 
2.5.3

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

[PATCH v3 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Signed-off-by: Eric Anholt 
---

v2: Mark it Supported, not Maintained.

 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..e331e46 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3653,6 +3653,12 @@ S:   Maintained
 F: drivers/gpu/drm/sti
 F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt
 
+DRM DRIVERS FOR VC4
+M: Eric Anholt 
+T: git git://github.com/anholt/linux
+S: Supported
+F: drivers/gpu/drm/vc4/*
+
 DSBR100 USB FM RADIO DRIVER
 M: Alexey Klimov 
 L: linux-me...@vger.kernel.org
-- 
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 5/7] drm/vc4: Allow vblank to be disabled

[Eric Anholt]

From: Derek Foreman 

Signed-off-by: Derek Foreman 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ee3e004..2e5597d 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -51,6 +51,7 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.max_height = 2048;
dev->mode_config.funcs = _mode_funcs;
dev->mode_config.preferred_depth = 24;
+   dev->vblank_disable_allowed = true;
 
drm_mode_config_reset(dev);
 
-- 
2.1.4

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

[PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

This is enough for fbcon and bringing up X using
xf86-video-modesetting.  It doesn't support the 3D accelerator or
power management yet.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter 
---

v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
ordering instead of using the .load hook.  Structure registration
more like tegra's, but still using the typical "component" code.
Drop no-op hooks for atomic_begin and mode_fixup() now that
they're optional.  Drop sentinel in Makefile.  Fix minor style
nits I noticed on another reread.

v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead
of having a fixed video mode.  Use exynos-style component driver
matching instead of devicetree nodes to list the component driver
instances.  Rename compatibility strings to say bcm2835, and
distinguish pv0/1/2.  Clean up some h/vsync code, and add in
interlaced mode setup.  Fix up probe/bind error paths.  Use
bitops.h macros for vc4_regs.h

 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/vc4/Kconfig   |  13 +
 drivers/gpu/drm/vc4/Makefile  |  17 +
 drivers/gpu/drm/vc4/vc4_bo.c  |  52 +++
 drivers/gpu/drm/vc4/vc4_crtc.c| 675 ++
 drivers/gpu/drm/vc4/vc4_debugfs.c |  39 +++
 drivers/gpu/drm/vc4/vc4_drv.c | 284 
 drivers/gpu/drm/vc4/vc4_drv.h | 115 +++
 drivers/gpu/drm/vc4/vc4_hdmi.c| 588 +
 drivers/gpu/drm/vc4/vc4_hvs.c | 163 +
 drivers/gpu/drm/vc4/vc4_kms.c |  54 +++
 drivers/gpu/drm/vc4/vc4_plane.c   | 320 ++
 drivers/gpu/drm/vc4/vc4_regs.h| 570 
 14 files changed, 2893 insertions(+)
 create mode 100644 drivers/gpu/drm/vc4/Kconfig
 create mode 100644 drivers/gpu/drm/vc4/Makefile
 create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1a0a8df..c4bf9a1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig"
 source "drivers/gpu/drm/amd/amdkfd/Kconfig"
 
 source "drivers/gpu/drm/imx/Kconfig"
+
+source "drivers/gpu/drm/vc4/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 45e7719..0edc9e2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA) += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915)  += i915/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
+obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
 obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
new file mode 100644
index 000..e810ef7
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -0,0 +1,13 @@
+config DRM_VC4
+   tristate "Broadcom VC4 Graphics"
+   depends on ARCH_BCM2835
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have a system that has a Broadcom
+ VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
+
+ This driver requires that "avoid_warnings=2" be present in
+ the config.txt for the firmware, to keep it from smashing
+ our display setup.
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
new file mode 100644
index 000..32b4f9c
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -0,0 +1,17 @@
+ccflags-y := -Iinclude/drm
+
+# Please keep these build lists sorted!
+
+# core driver code
+vc4-y := \
+   vc4_bo.o \
+   vc4_crtc.o \
+   vc4_drv.o \
+   vc4_kms.o \
+   vc4_hdmi.o \
+   vc4_hvs.o \
+   vc4_plane.o
+
+vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
+
+obj-$(CONFIG_DRM_VC4)  += vc4.o
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
new file mode 100644
index 000..ab9f510
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -0,0 +1,52 @@
+/*
+ *  Copyright © 2015 Broadcom
+ *
+ * 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.
+ */
+
+/* DOC: VC4 GEM BO management support.
+ *
+ * The VC4 GPU architecture (both scanout and rendering) has direct
+ * access to system memory with no MMU 

[PATCH v3 7/7] ARM: bcm2835: Add VC4 to the device tree.

[Eric Anholt]

VC4 is the GPU (display and 3D) present on the 2835.

Signed-off-by: Eric Anholt 
---

v2: Sort by register address, mark HDMI as disabled by default in the
SoC file and enable it from -rpi.

v3: Add references to the pixel/HSM clocks for HDMI.  Rename
compatibility strings and clean up node names.

 arch/arm/boot/dts/bcm2835-rpi.dtsi |  4 
 arch/arm/boot/dts/bcm2835.dtsi | 42 ++
 2 files changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..dcaaee2 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -56,6 +56,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
bus-width = <4>;
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 1e61eb7..21e354a9 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include "skeleton.dtsi"
 
@@ -149,6 +150,18 @@
status = "disabled";
};
 
+   pixelvalve@7e206000 {
+   compatible = "brcm,bcm2835-pixelvalve0";
+   reg = <0x7e206000 0x100>;
+   interrupts = <2 13>; /* pwa2 */
+   };
+
+   pixelvalve@7e207000 {
+   compatible = "brcm,bcm2835-pixelvalve1";
+   reg = <0x7e207000 0x100>;
+   interrupts = <2 14>; /* pwa1 */
+   };
+
sdhci: sdhci@7e30 {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e30 0x100>;
@@ -157,6 +170,12 @@
status = "disabled";
};
 
+   hvs@7e40 {
+   compatible = "brcm,bcm2835-hvs";
+   reg = <0x7e40 0x6000>;
+   interrupts = <2 1>;
+   };
+
i2c1: i2c@7e804000 {
compatible = "brcm,bcm2835-i2c";
reg = <0x7e804000 0x1000>;
@@ -177,6 +196,25 @@
status = "disabled";
};
 
+   pixelvalve@7e807000 {
+   compatible = "brcm,bcm2835-pixelvalve2";
+   reg = <0x7e807000 0x100>;
+   interrupts = <2 10>; /* pixelvalve */
+   };
+
+   hdmi: hdmi@7e902000 {
+   compatible = "brcm,bcm2835-hdmi";
+   reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+   interrupts = <2 8>, <2 9>;
+   ddc = <>;
+   hpd-gpio = < 46 GPIO_ACTIVE_HIGH>;
+   clocks = < BCM2835_PLLH_PIX>,
+< BCM2835_CLOCK_HSM>;
+   clock-names = "pixel", "hdmi";
+   status = "disabled";
+   };
+
usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
@@ -186,6 +224,10 @@
arm-pmu {
compatible = "arm,arm1176-pmu";
};
+
+   vc4: gpu@7e4c {
+   compatible = "brcm,bcm2835-vc4";
+   };
};
 
clocks {
-- 
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] ARM: shmobile: henninger: add MSIOF0 DT support

[Sergei Shtylyov]

On 05/07/2014 12:47 AM, Sergei Shtylyov wrote:


Define the Henninger board dependent part of the MSIOF0 device node.
Add device node for Renesas R2A11302FT PMIC for which no bindings exist yet.


   I've just realized that there's no such PMIC on the Henninger/Porter 
boards and MSIOF0 is only connected to CN6, hence this patch was wrong.

The .dts is going to be deleted anyway though...


Based on the Koelsch MSIOF device tree patch by Geert Uytterhoeven.

Signed-off-by: Sergei Shtylyov 


MBR, Sergei

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

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

[Sergei Shtylyov]

Define the Porter board dependent part of the QSPI device node.
Add device nodes  for Spansion  S25FL512S SPI flash and the MTD partitions
on it.

This patch is  mostly analogous to the commit f59838d44835 (ARM: shmobile:
henninger: add QSPI 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 and VIN0/ADV7180 patches posted earlier.

 arch/arm/boot/dts/r8a7791-porter.dts |   38 +++
 1 file changed, 38 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
@@ -110,6 +110,11 @@
renesas,function = "sdhi2";
};
 
+   qspi_pins: spi0 {
+   renesas,groups = "qspi_ctrl", "qspi_data4";
+   renesas,function = "qspi";
+   };
+
i2c2_pins: i2c2 {
renesas,groups = "i2c2";
renesas,function = "i2c2";
@@ -165,6 +170,39 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+
+   flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spansion,s25fl512s", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <3000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   m25p,fast-read;
+
+   partition@0 {
+   label = "loader_prg";
+   reg = <0x 0x0004>;
+   read-only;
+   };
+   partition@4 {
+   label = "user_prg";
+   reg = <0x0004 0x0040>;
+   read-only;
+   };
+   partition@44 {
+   label = "flash_fs";
+   reg = <0x0044 0x03bc>;
+   };
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";

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

[PATCH 1/2] arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120

[Arnaud Ebalard]

By default, armada-370-xp.dtsi file has internal RTC enabled.
NETGEAR ReadyNAS 102, 104 and 2120 all use an Intersil ISL12057
I2C RTC chip. The internal RTC not being disabled in the .dts
files of those devices result in the following useless first
line during boot:

[4.500056] rtc-mv d0010300.rtc: internal RTC not ticking
[4.505684] i2c /dev entries driver
[4.513246] rtc-isl12057 0-0068: rtc core: registered rtc-isl12057 as rtc0

This patch marks Armada internal RTC as disabled in individual .dts
files of those devices.

Reported-by: TuxOholic 
Signed-off-by: Arnaud Ebalard 
---
 arch/arm/boot/dts/armada-370-netgear-rn102.dts | 6 ++
 arch/arm/boot/dts/armada-370-netgear-rn104.dts | 6 ++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
index a31207860f34..5851964196bd 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -82,6 +82,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
serial@12000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/armada-370-netgear-rn104.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
index 00540f292979..b0b07ba677b9 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn104.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
@@ -82,6 +82,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
serial@12000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts 
b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 1516fc2627f9..85b2f87c0b8a 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -88,6 +88,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
/* Two rear eSATA ports */
sata@a {
nr-ports = <2>;
-- 
2.5.3


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

[PATCH 2/2] arm: mvebu: reorder nodes under internal-regs by address in RN2120 .dts file

[Arnaud Ebalard]

This cosmetic patch reorder nodes under internal-regs by increasing
address order, as epxected.

Signed-off-by: Arnaud Ebalard 
---
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 86 +-
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts 
b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 85b2f87c0b8a..d72a69d97ba2 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -94,54 +94,11 @@
status = "disabled";
};
 
-   /* Two rear eSATA ports */
-   sata@a {
-   nr-ports = <2>;
-   status = "okay";
-   };
-
-   serial@12000 {
-   status = "okay";
-   };
-
-   mdio {
-   phy0: ethernet-phy@0 { /* Marvell 88E1318 */
-   reg = <0>;
-   };
-
-   phy1: ethernet-phy@1 { /* Marvell 88E1318 */
-   reg = <1>;
-   };
-   };
-
-   ethernet@7 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "rgmii-id";
-   };
-
-   ethernet@74000 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "rgmii-id";
-   };
-
-   /* Front USB 2.0 port */
-   usb@5 {
-   status = "okay";
-   };
-
i2c@11000 {
compatible = "marvell,mv64xxx-i2c";
clock-frequency = <40>;
status = "okay";
 
-   isl12057: isl12057@68 {
-   compatible = "isil,isl12057";
-   reg = <0x68>;
-   isil,irq2-can-wakeup-machine;
-   };
-
/* Controller for rear fan #1 of 3 (Protechnic
 * MGT4012XB-O20, 8000RPM) near eSATA port */
g762_fan1: g762@3e {
@@ -178,6 +135,49 @@
compatible = "gmt,g751";
reg = <0x4c>;
};
+
+   isl12057: isl12057@68 {
+   compatible = "isil,isl12057";
+   reg = <0x68>;
+   isil,irq2-can-wakeup-machine;
+   };
+   };
+
+   serial@12000 {
+   status = "okay";
+   };
+
+   /* Front USB 2.0 port */
+   usb@5 {
+   status = "okay";
+   };
+
+   mdio {
+   phy0: ethernet-phy@0 { /* Marvell 88E1318 */
+   reg = <0>;
+   };
+
+   phy1: ethernet-phy@1 { /* Marvell 88E1318 */
+   reg = <1>;
+   };
+   };
+
+   ethernet@7 {
+   status = "okay";
+   phy = <>;
+   phy-mode = "rgmii-id";
+   };
+
+   ethernet@74000 {
+   status = "okay";
+   phy = <>;
+   phy-mode = "rgmii-id";
+   };
+
+   /* Two rear eSATA ports */
+   sata@a {
+   nr-ports = <2>;
+   status = "okay";
};
 
nand@d {
-- 
2.5.3

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

bcm2835 (Raspberry Pi) KMS driver

[Eric Anholt]

This is a respin of the Raspberry Pi KMS series.  Now that we've got a
real clock driver, I can actually set new video modes.  Also in this
version, most of the custom DT stuff from before is gone, thanks to
finding exynos's platform_driver component matching code (I have sent
separate patches to drivers/base to make helpers for doing it).

https://github.com/anholt/linux/tree/vc4-kms-squash-2

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

[PATCH] ARM: shmobile: porter: enable PCIe

[Sergei Shtylyov]

Enable the PCIe controller and clock for the Porter board.

This patch is analogous to the commit 485f3ce67c11 ("ARM: shmobile:
henninger: Enable PCIe Controller & PCIe bus clock") 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, VIN0/ADV7180, and QSPI patches posted
earlier.

 arch/arm/boot/dts/r8a7791-porter.dts |8 
 1 file changed, 8 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
@@ -244,3 +244,11 @@
};
};
 };
+
+_bus_clk {
+   status = "okay";
+};
+
+ {
+   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 v2 1/2] devicetree: add binding for generic mmio clocksource

[Måns Rullgård]

Stephen Boyd  writes:

> On 10/09, Rob Herring wrote:
>> +Stephen who has worked on this code.
>> 
>> On Fri, Oct 9, 2015 at 11:19 AM, Måns Rullgård  wrote:
>> > Måns Rullgård  writes:
>> >
>> >> Rob Herring  writes:
>> >>
>> >>> On Wed, Oct 7, 2015 at 11:47 AM, Måns Rullgård  wrote:
>>  What would be a proper way to select a sched_clock source?  I realise
>>  it's a Linux-specific thing and DT is supposed to be generic, but the
>>  information must be provided somehow.
>> >>>
>> >>> The kernel already has some logic to do this. Most number of bits
>> >>> followed by highest frequency will be the winning sched_clock. You
>> >>> might also want to look at things like always on or not.
>> >>
>> >> The problem is that sched_clock_register() doesn't take a pointer to be
>> >> passed back to the read_sched_clock callback like most interfaces of
>> >> this type do.  This means the callback must use global variables set up
>> >> before the register call, but at that time there's no way of knowing
>> >> which one will be used.  If there were a way of getting a pointer to the
>> >> callback, it would be a simple matter of registering all instances and
>> >> letting the kernel choose which to use.
>> >
>> > Anyone got a comment on this?  Do I have to send a patch adding this
>> > before anyone will tell me why it's a bad idea?  (That method almost
>> > always works.)
>> 
>> Adding a ptr to the callback seems fine to me.
>> 
>
> Does that mean a flag day? Urgh. Pain. I'm not opposed to adding
> a pointer, in fact it might be better for performance so that we
> don't take a cache miss in read() functions that need to load
> some pointer. We were talking about that problem a few months
> ago, but nothing came of it.

I've sent a patch.  Let the flames begin.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Emil Velikov  writes:

> Hi Eric,
>
> On 9 October 2015 at 22:27, Eric Anholt  wrote:
>> Signed-off-by: Eric Anholt 
>> ---
>>
>> v2: Mark it Supported, not Maintained.
>>
>>  MAINTAINERS | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7ba7ab7..e331e46 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3653,6 +3653,12 @@ S:   Maintained
>>  F: drivers/gpu/drm/sti
>>  F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt
>>
>> +DRM DRIVERS FOR VC4
>> +M: Eric Anholt 
>> +T: git git://github.com/anholt/linux
> You might want to add dri-devel as mailing list, at least initially.

I believe that's already implied by the general entry for dri-devel:

./scripts/get_maintainer.pl -f drivers/gpu/drm/vc4/vc4_drv.c
Eric Anholt  (supporter:DRM DRIVERS FOR VC4)
David Airlie  (maintainer:DRM DRIVERS)
dri-de...@lists.freedesktop.org (open list:DRM DRIVERS)


signature.asc
Description: PGP signature

[PATCH] ARM: hisilicon: DT: Drop console= and earlyprintk bootargs parameter

[Wei Xu]

Replace console with stdout-path so that we don't have to put the
console on the kernel command line.

Remove earlyprintk to allow the kernel to boot on a system even
if DEBUG_LL is configured for another system.

Signed-off-by: Wei Xu 
Tested-by: Zhangfei Gao 
---
 arch/arm/boot/dts/hi3620-hi4511.dts  | 3 ++-
 arch/arm/boot/dts/hisi-x5hd2-dkb.dts | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/hi3620-hi4511.dts 
b/arch/arm/boot/dts/hi3620-hi4511.dts
index fe62392..a579fbf 100644
--- a/arch/arm/boot/dts/hi3620-hi4511.dts
+++ b/arch/arm/boot/dts/hi3620-hi4511.dts
@@ -16,7 +16,8 @@
 compatible = "hisilicon,hi3620-hi4511";

 chosen {
-bootargs = "console=ttyAMA0,115200 root=/dev/ram0 earlyprintk";
+bootargs = "root=/dev/ram0";
+stdout-path = "serial0:115200n8";
 };

 memory {
diff --git a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts 
b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
index 721b092..d13af84 100644
--- a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
+++ b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
@@ -15,7 +15,7 @@
 compatible = "hisilicon,hix5hd2";

 chosen {
-bootargs = "console=ttyAMA0,115200 earlyprintk";
+stdout-path = "serial0:115200n8";
 };

 cpus {
-- 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 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Mark Rutland]

On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau  wrote:
> > > Juno R1 board sports a functional PCIe host bridge that is
> > > compliant with the SBSA standard found here[1]. With the right
> > > firmware that initialises the XpressRICH3 controller one can
> > > use the generic Host Bridge driver to use the PCIe hardware.
> > >
> > > Signed-off-by: Liviu Dudau 
> > >
> > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > > ---
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts 
> > > b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > index c627511..a702a6b 100644
> > > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -109,6 +109,26 @@
> > >
> > > #include "juno-base.dtsi"
> > >
> > > +   pcie-controller@4000 {
> > > +   compatible = "pci-host-ecam-generic";
> > 
> > I think this is the first case of real h/w using this. We should have
> > a specific compatible here additionally.
> 
> Or maybe I can claim the use of the string on account on being the first on 
> arm64 ;)
> 
> I can add a vendor prefix if you want, but pci-host-generic is going to 
> ignore it 
> *because* it is trying to be a generic driver.

The point here is to have the string ready if we need it later, so it's
fine that it's not used currently.

Rob's suggestion is that the compatible list should look something like:

compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";

We can match on "pci-host-ecam-generic" for now (and hopefully forever),
but if for some reason we need to special-case this host controller (or
Juno's integration thereof), we can do that based on the compatible
string.

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

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > Or maybe I can claim the use of the string on account on being the first 
> > > on arm64 
> > > 
> > > I can add a vendor prefix if you want, but pci-host-generic is going to 
> > > ignore it 
> > > *because* it is trying to be a generic driver.
> > 
> > The point here is to have the string ready if we need it later, so it's
> > fine that it's not used currently.
> > 
> > Rob's suggestion is that the compatible list should look something like:
> > 
> > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", 
> > "pci-host-ecam-generic";
> > 
> > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > but if for some reason we need to special-case this host controller (or
> > Juno's integration thereof), we can do that based on the compatible
> > string.
> 
> Sounds good to me, it certainly can't hurt.
> 
>   Arnd

Hmm, I'm sorry, but this time I'm going to disagree.

I understand the principle that the DTS is a description of the hardware and it 
should
not have any built in knowledge of how a driver works but describe the physical 
properties
of the device (where such description makes sense, in this case it does).

However, when ARM has created the Juno platform it has also created a standard 
called
SBSA and has claimed that Juno is compliant with that standard. My current 
position (and
it used to be MarkR's as well when we have argued internally the pros and cons 
of having
a bespoke driver for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* 
the expected
behaviour and if the device doesn't conform it needs to be fixed in firmware.

Otherwise, I could've posted months ago the other public driver[1] that I've 
wrote that
doesn't depend on firmware and could have been done with this long time ago.

Best regards,
Liviu

1. 
https://github.com/ARM-software/linux/commit/ca9d82679916c3b6bdb846319e343a43a6bbb31c


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

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource

[Måns Rullgård]

Måns Rullgård  writes:

> Rob Herring  writes:
>
>> On Wed, Oct 7, 2015 at 11:47 AM, Måns Rullgård  wrote:
>>> What would be a proper way to select a sched_clock source?  I realise
>>> it's a Linux-specific thing and DT is supposed to be generic, but the
>>> information must be provided somehow.
>>
>> The kernel already has some logic to do this. Most number of bits
>> followed by highest frequency will be the winning sched_clock. You
>> might also want to look at things like always on or not.
>
> The problem is that sched_clock_register() doesn't take a pointer to be
> passed back to the read_sched_clock callback like most interfaces of
> this type do.  This means the callback must use global variables set up
> before the register call, but at that time there's no way of knowing
> which one will be used.  If there were a way of getting a pointer to the
> callback, it would be a simple matter of registering all instances and
> letting the kernel choose which to use.

Anyone got a comment on this?  Do I have to send a patch adding this
before anyone will tell me why it's a bad idea?  (That method almost
always works.)

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 10/60] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

[Khalid Aziz]

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote:
> 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

Tested on sparc platforms

Tested-by: Khalid Aziz  




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

[Will Deacon]

On Tue, Sep 22, 2015 at 03:12:47PM +0100, Yong Wu wrote:
>  I would like to show you a problem I met, The recursion here may
> lead to stack overflow while we test FHD video decode.
> 
> From the log, I get the internal variable in the error case: the
> "size" is 0x10, the "iova" is 0xfea0, but at that time the
> "blk_size" is 0x1000 as it was the map of small-page. so it enter the
> recursion here.
> 
> After check the unmap flow, there is only a iommu_unmap in
> __iommu_dma_unmap, and it won't check the physical address align in
> iommu_unmap.

That sounds like a bug in __iommu_dma_unmap. Robin?

Will
--
To unsubscribe from this list: send the line "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

[Aleksei Mamlin]

On Thu,  8 Oct 2015 17:23:42 +0300
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.
> 

I tested this patchset on ARM tablet Wexler TAB7200 with GT911 touchscreen 
controller. All works fine, so you can add

Tested-by: Aleksei Mamlin 

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


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

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

[Josh Cartwright]

On Fri, Oct 09, 2015 at 12:45:05AM +0200, Moritz Fischer wrote:
> 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

I think you mean 'interrupt-parent', with the hyphen.

Actually, this isn't really a 'required' property of this node, as it
could be specified in a parent node.

  Josh


signature.asc
Description: PGP signature

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:32:52PM +0100, Mark Rutland wrote:
> On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote:
> > On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> > > On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > > > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > > > Or maybe I can claim the use of the string on account on being the 
> > > > > first on arm64 
> > > > > 
> > > > > I can add a vendor prefix if you want, but pci-host-generic is going 
> > > > > to ignore it 
> > > > > *because* it is trying to be a generic driver.
> > > > 
> > > > The point here is to have the string ready if we need it later, so it's
> > > > fine that it's not used currently.
> > > > 
> > > > Rob's suggestion is that the compatible list should look something like:
> > > > 
> > > > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", 
> > > > "pci-host-ecam-generic";
> > > > 
> > > > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > > > but if for some reason we need to special-case this host controller (or
> > > > Juno's integration thereof), we can do that based on the compatible
> > > > string.
> > > 
> > > Sounds good to me, it certainly can't hurt.
> > > 
> > >   Arnd
> > 
> > Hmm, I'm sorry, but this time I'm going to disagree.
> > 
> > I understand the principle that the DTS is a description of the
> > hardware and it should not have any built in knowledge of how a driver
> > works but describe the physical properties of the device (where such
> > description makes sense, in this case it does).
> > 
> > However, when ARM has created the Juno platform it has also created a
> > standard called SBSA and has claimed that Juno is compliant with that
> > standard. My current position (and it used to be MarkR's as well when
> > we have argued internally the pros and cons of having a bespoke driver
> > for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the
> > expected behaviour and if the device doesn't conform it needs to be
> > fixed in firmware.
> 
> We are not arguing for a bespoke driver, and in fact we hope to never
> have to use the addition strings.
> 
> However, experience shows that we might not be lucky, and if we
> encounter some bizarre quirk in future we might need to handle that by
> knowing what the hardware is.
> 
> > Otherwise, I could've posted months ago the other public driver[1]
> > that I've wrote that doesn't depend on firmware and could have been
> > done with this long time ago.
> 
> We're not arguing for kernel support code. What we're arguing for is
> data in the DTB that ideally turns out to be irrelevant.
> 
> I can't see why you object to that.

It is not a strong objection but I don't want to ever have to add bespoke
code to the pci-host-generic.c driver so adding a compatible property that
is going to be ignored is kind of pointless. Yes, one will have a better
idea on what the hardware actually is, but so what?

I will send a v2 with the added values.

Best regards,
Liviu

> 
> Mark.
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Arnd Bergmann]

On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > Or maybe I can claim the use of the string on account on being the first on 
> > arm64 
> > 
> > I can add a vendor prefix if you want, but pci-host-generic is going to 
> > ignore it 
> > *because* it is trying to be a generic driver.
> 
> The point here is to have the string ready if we need it later, so it's
> fine that it's not used currently.
> 
> Rob's suggestion is that the compatible list should look something like:
> 
> compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> 
> We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> but if for some reason we need to special-case this host controller (or
> Juno's integration thereof), we can do that based on the compatible
> string.

Sounds good to me, it certainly can't hurt.

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] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

[Vinod Koul]

On Thu, Oct 08, 2015 at 02:36:57PM +0530, Rameshwar Prasad Sahu wrote:
> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
> computations. But the bandwidth of the entire DMA engine is shared
> among all channels. This patch re-configures operations availability
> such that one can achieve maximum performance for XOR and PQ
> computation by removing the memory offload operations.
> 
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/dma/xgene-dma.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index 8d57b1b..cd38022 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -1707,7 +1707,6 @@ static void xgene_dma_set_caps(struct xgene_dma_chan 
> *chan,
>   dma_cap_zero(dma_dev->cap_mask);
> 
>   /* Set DMA device capability */
> - dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>   dma_cap_set(DMA_SG, dma_dev->cap_mask);

This will not work. Still clients can invoke memcpy operation. You need to
remove the callback

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

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

[David Daney]

On 10/09/2015 06:20 AM, Rob Herring wrote:

On Thu, Oct 8, 2015 at 5:10 PM, David Daney  wrote:

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 


I acked v3. Please add it so I can stop paying attention.



My apologies for missing that.

The Acked-by is now in my local tree.  Can the MSI maintainer take it as 
is and add your Acked-by?  If not, I can resend with this added.


Thanks for taking the time to review it,
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: [PATCH 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000

[Josh Cartwright]

Hey Moritz-

On Fri, Oct 09, 2015 at 12:45:07AM +0200, Moritz Fischer wrote:
> 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 
[..]
> +++ b/drivers/fpga/zynq-fpga.c
[..]
> +static irqreturn_t zynq_fpga_isr(int irq, void *data)
> +{
> + u32 intr_status;
> + struct zynq_fpga_priv *priv = data;
> +
> + spin_lock(>lock);

I'm confused about the locking here.  You have this lock, but it's only
used in the isr.  It's claimed purpose is to protect 'error', but that
clearly isn't happening.

> + intr_status = zynq_fpga_read(priv, INT_STS_OFFSET);
> +
> + if (!intr_status) {
> + spin_unlock(>lock);
> + return IRQ_NONE;
> + }
> +
> + zynq_fpga_write(priv, INT_STS_OFFSET, intr_status);
> +
> + if ((intr_status & IXR_D_P_DONE_MASK) == IXR_D_P_DONE_MASK)
> + complete(>dma_done);

Just so I understand, wouldn't you also want to complete() in the error
case, too?

> + if ((intr_status & IXR_ERROR_FLAGS_MASK) ==
> + IXR_ERROR_FLAGS_MASK) {
> + priv->error = true;
> + dev_err(priv->dev, "%s dma error\n", __func__);
> + }
> + spin_unlock(>lock);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct zynq_fpga_priv *priv;
> + u32 ctrl, status;
> + int err;
> +
> + priv = mgr->priv;
> +
> + err = clk_enable(priv->clk);
> + if (err)
> + return err;
> +
> + /* only reset if we're not doing partial reconfig */
> + if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + /* assert AXI interface resets */
> + regmap_write(priv->slcr, SLCR_FPGA_RST_CTRL_OFFSET,
> +  FPGA_RST_ALL_MASK);
> +
> + /* disable level shifters */
> + regmap_write(priv->slcr, SLCR_LVL_SHFTR_EN_OFFSET,
> +  LVL_SHFTR_DISABLE_ALL_MASK);
> + /* enable output level shifters */
> + regmap_write(priv->slcr, SLCR_LVL_SHFTR_EN_OFFSET,
> +  LVL_SHFTR_ENABLE_PS_TO_PL);
> +
> + /* create a rising edge on PCFG_INIT. PCFG_INIT follows
> +  * PCFG_PROG_B, so we need to poll it after setting PCFG_PROG_B
> +  * to make sure the rising edge actually happens
> +  */
> + ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
> + ctrl |= CTRL_PCFG_PROG_B_MASK;
> +
> + zynq_fpga_write(priv, CTRL_OFFSET, ctrl);
> +
> + zynq_fpga_poll_timeout(priv, STATUS_OFFSET, status, status &
> +STATUS_PCFG_INIT_MASK, 20, 0);

And if we timeout?

> +
> + ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
> + ctrl &= ~CTRL_PCFG_PROG_B_MASK;
> +
> + zynq_fpga_write(priv, CTRL_OFFSET, ctrl);
> +
> + zynq_fpga_poll_timeout(priv, STATUS_OFFSET, status, !(status &
> +STATUS_PCFG_INIT_MASK), 20, 0);

And if we timeout?

> +
> + ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
> + ctrl |= CTRL_PCFG_PROG_B_MASK;
> +
> + zynq_fpga_write(priv, CTRL_OFFSET, ctrl);
> +
> + zynq_fpga_poll_timeout(priv, STATUS_OFFSET, status, status &
> +STATUS_PCFG_INIT_MASK, 20, 0);

And if we timeout?

> + }
> +
> + clk_disable(priv->clk);
> +
> + return 0;
> +}
> +
> +static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> +const char *buf, size_t count)
> +{
> + struct zynq_fpga_priv *priv;
> + int err;
> + char *kbuf;
> + size_t i, in_count;
> + dma_addr_t dma_addr;
> + u32 transfer_length = 0;
> + bool endian_swap = false;
> +
> + in_count = count;
> + priv = mgr->priv;
> +
> + kbuf = dma_alloc_coherent(priv->dev, count, _addr, GFP_KERNEL);
> + if (!kbuf)
> + return -ENOMEM;
> +
> + memcpy(kbuf, buf, count);
> +
> + /* look for the sync word */
> + for (i = 0; i < count - 4; i++) {
> + if (memcmp(kbuf + i, "\x66\x55\x99\xAA", 4) == 0) {
> + dev_dbg(priv->dev, "Found normal sync word\n");
> + endian_swap = false;
> + break;
> + }
> + if (memcmp(kbuf + i, "\xAA\x99\x55\x66", 4) == 0) {
> + dev_dbg(priv->dev, "Found swapped sync word\n");
> + endian_swap = true;
> + break;
> + }
> + }

How much control do we have over mandating the format of firmware at
this point?  It'd be swell if we could just mandate a specific
endianness, and leave this munging to usermode.

> + /* remove the 

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Mark Rutland]

On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> > On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > > Or maybe I can claim the use of the string on account on being the 
> > > > first on arm64 
> > > > 
> > > > I can add a vendor prefix if you want, but pci-host-generic is going to 
> > > > ignore it 
> > > > *because* it is trying to be a generic driver.
> > > 
> > > The point here is to have the string ready if we need it later, so it's
> > > fine that it's not used currently.
> > > 
> > > Rob's suggestion is that the compatible list should look something like:
> > > 
> > > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", 
> > > "pci-host-ecam-generic";
> > > 
> > > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > > but if for some reason we need to special-case this host controller (or
> > > Juno's integration thereof), we can do that based on the compatible
> > > string.
> > 
> > Sounds good to me, it certainly can't hurt.
> > 
> > Arnd
> 
> Hmm, I'm sorry, but this time I'm going to disagree.
> 
> I understand the principle that the DTS is a description of the
> hardware and it should not have any built in knowledge of how a driver
> works but describe the physical properties of the device (where such
> description makes sense, in this case it does).
> 
> However, when ARM has created the Juno platform it has also created a
> standard called SBSA and has claimed that Juno is compliant with that
> standard. My current position (and it used to be MarkR's as well when
> we have argued internally the pros and cons of having a bespoke driver
> for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the
> expected behaviour and if the device doesn't conform it needs to be
> fixed in firmware.

We are not arguing for a bespoke driver, and in fact we hope to never
have to use the addition strings.

However, experience shows that we might not be lucky, and if we
encounter some bizarre quirk in future we might need to handle that by
knowing what the hardware is.

> Otherwise, I could've posted months ago the other public driver[1]
> that I've wrote that doesn't depend on firmware and could have been
> done with this long time ago.

We're not arguing for kernel support code. What we're arguing for is
data in the DTB that ideally turns out to be irrelevant.

I can't see why you object to that.

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

Re: [PATCH v2] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

[Rameshwar Sahu]

Hi Vinod,

On Fri, Oct 9, 2015 at 9:42 PM, Vinod Koul  wrote:
> On Thu, Oct 08, 2015 at 02:36:57PM +0530, Rameshwar Prasad Sahu wrote:
>> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
>> computations. But the bandwidth of the entire DMA engine is shared
>> among all channels. This patch re-configures operations availability
>> such that one can achieve maximum performance for XOR and PQ
>> computation by removing the memory offload operations.
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index 8d57b1b..cd38022 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -1707,7 +1707,6 @@ static void xgene_dma_set_caps(struct xgene_dma_chan 
>> *chan,
>>   dma_cap_zero(dma_dev->cap_mask);
>>
>>   /* Set DMA device capability */
>> - dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>>   dma_cap_set(DMA_SG, dma_dev->cap_mask);
>
> This will not work. Still clients can invoke memcpy operation. You need to
> remove the callback

Got it, instead of removing the callback registration can we keep it
inside the condition like..

if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
dma_dev->device_prep_dma_memcpy = xgene_dma_prep_memcpy;


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