Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 07/21] pinctrl: mvebu: move generic group name generation
From: Sebastian Hesselbarth @ 2014-01-28  0:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390869573-27624-1-git-send-email-sebastian.hesselbarth@gmail.com>

MVEBU SoC pinctrl allows SoC specific drivers to pass a range of mpp
pins without a corresponding name. Each pin in this range is then
translated into a single-pin group with an auto-generated name. To allow
some redesign of the driver, move name generation for those pin ranges
down to where the groups are created.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 90c35b20a7af..375666b0abc3 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -631,7 +631,6 @@ int mvebu_pinctrl_probe(struct platform_device *pdev, void __iomem *base)
 	pctl->desc.npins = 0;
 	for (n = 0; n < soc->ncontrols; n++) {
 		struct mvebu_mpp_ctrl *ctrl = &soc->controls[n];
-		char *names;
 
 		pctl->desc.npins += ctrl->npins;
 		/* initial control pins */
@@ -649,14 +648,6 @@ int mvebu_pinctrl_probe(struct platform_device *pdev, void __iomem *base)
 		}
 
 		/* generic mvebu register control */
-		names = devm_kzalloc(&pdev->dev, ctrl->npins * 8, GFP_KERNEL);
-		if (!names) {
-			dev_err(&pdev->dev, "failed to alloc mpp names\n");
-			return -ENOMEM;
-		}
-		for (k = 0; k < ctrl->npins; k++)
-			sprintf(names + 8*k, "mpp%d", ctrl->pid+k);
-		ctrl->name = names;
 		pctl->num_groups += ctrl->npins;
 	}
 
@@ -689,7 +680,18 @@ int mvebu_pinctrl_probe(struct platform_device *pdev, void __iomem *base)
 		pctl->groups[gid].npins = ctrl->npins;
 
 		/* generic mvebu register control maps to a number of groups */
-		if (!ctrl->mpp_get && !ctrl->mpp_set) {
+		if (!ctrl->name) {
+			char *names = devm_kzalloc(&pdev->dev,
+						   ctrl->npins * 8, GFP_KERNEL);
+			if (!names) {
+				dev_err(&pdev->dev, "failed to alloc mpp names\n");
+				return -ENOMEM;
+			}
+			for (k = 0; k < ctrl->npins; k++)
+				sprintf(names + 8*k, "mpp%d", ctrl->pid+k);
+			ctrl->name = names;
+
+			pctl->groups[gid].name = &ctrl->name[0];
 			pctl->groups[gid].npins = 1;
 
 			for (k = 1; k < ctrl->npins; k++) {
-- 
1.8.5.2

^ permalink raw reply related

* [PATCH v2 06/21] pinctrl: mvebu: add common mpp reg defines to mvebu pinctrl include
From: Sebastian Hesselbarth @ 2014-01-28  0:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390869573-27624-1-git-send-email-sebastian.hesselbarth@gmail.com>

This adds some defines for the common mpp reg layout to mvebu pinctrl
include.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.h b/drivers/pinctrl/mvebu/pinctrl-mvebu.h
index b66949040e0a..e81caa964d83 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.h
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.h
@@ -186,6 +186,10 @@ struct mvebu_pinctrl_soc_info {
 		.npins = _npins,				\
 	}
 
+#define MVEBU_MPPS_PER_REG	8
+#define MVEBU_MPP_BITS		4
+#define MVEBU_MPP_MASK		0xf
+
 int mvebu_pinctrl_probe(struct platform_device *pdev, void __iomem *base);
 int mvebu_pinctrl_remove(struct platform_device *pdev);
 
-- 
1.8.5.2

^ permalink raw reply related

* [PATCH v2 05/21] pinctrl: mvebu: prepare to fix misdesigned resource allocation
From: Sebastian Hesselbarth @ 2014-01-28  0:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390869573-27624-1-git-send-email-sebastian.hesselbarth@gmail.com>

Allocating the pinctrl resource in common pinctrl-mvebu was a misdesign,
as it does not allow SoC specific parts to access the allocated resource.
This moves resource allocation from mvebu_pinctrl_probe to SoC specific
_probe functions and temporarily passes the base address to common pinctrl
driver instead.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-armada-370.c | 10 +++++++++-
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c  | 10 +++++++++-
 drivers/pinctrl/mvebu/pinctrl-dove.c       | 11 ++++++++++-
 drivers/pinctrl/mvebu/pinctrl-kirkwood.c   | 11 ++++++++++-
 drivers/pinctrl/mvebu/pinctrl-mvebu.c      | 14 ++++++--------
 drivers/pinctrl/mvebu/pinctrl-mvebu.h      |  2 +-
 6 files changed, 45 insertions(+), 13 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-370.c b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
index ae1f760cbdd2..7586072e66c6 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-370.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
@@ -23,6 +23,8 @@
 
 #include "pinctrl-mvebu.h"
 
+static void __iomem *mpp_base;
+
 static struct mvebu_mpp_mode mv88f6710_mpp_modes[] = {
 	MPP_MODE(0,
 	   MPP_FUNCTION(0x0, "gpio", NULL),
@@ -385,6 +387,12 @@ static struct pinctrl_gpio_range mv88f6710_mpp_gpio_ranges[] = {
 static int armada_370_pinctrl_probe(struct platform_device *pdev)
 {
 	struct mvebu_pinctrl_soc_info *soc = &armada_370_pinctrl_info;
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mpp_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mpp_base))
+		return PTR_ERR(mpp_base);
 
 	soc->variant = 0; /* no variants for Armada 370 */
 	soc->controls = mv88f6710_mpp_controls;
@@ -396,7 +404,7 @@ static int armada_370_pinctrl_probe(struct platform_device *pdev)
 
 	pdev->dev.platform_data = soc;
 
-	return mvebu_pinctrl_probe(pdev);
+	return mvebu_pinctrl_probe(pdev, mpp_base);
 }
 
 static int armada_370_pinctrl_remove(struct platform_device *pdev)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 843a51f9d129..786c629af8a8 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -33,6 +33,8 @@
 
 #include "pinctrl-mvebu.h"
 
+static void __iomem *mpp_base;
+
 enum armada_xp_variant {
 	V_MV78230	= BIT(0),
 	V_MV78260	= BIT(1),
@@ -399,10 +401,16 @@ static int armada_xp_pinctrl_probe(struct platform_device *pdev)
 	struct mvebu_pinctrl_soc_info *soc = &armada_xp_pinctrl_info;
 	const struct of_device_id *match =
 		of_match_device(armada_xp_pinctrl_of_match, &pdev->dev);
+	struct resource *res;
 
 	if (!match)
 		return -ENODEV;
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mpp_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mpp_base))
+		return PTR_ERR(mpp_base);
+
 	soc->variant = (unsigned) match->data & 0xff;
 
 	switch (soc->variant) {
@@ -443,7 +451,7 @@ static int armada_xp_pinctrl_probe(struct platform_device *pdev)
 
 	pdev->dev.platform_data = soc;
 
-	return mvebu_pinctrl_probe(pdev);
+	return mvebu_pinctrl_probe(pdev, mpp_base);
 }
 
 static int armada_xp_pinctrl_remove(struct platform_device *pdev)
diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 47268393af34..4d051ba17fee 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -55,6 +55,8 @@
 
 #define CONFIG_PMU	BIT(4)
 
+static void __iomem *mpp_base;
+
 static int dove_pmu_mpp_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 				 unsigned long *config)
 {
@@ -776,6 +778,13 @@ static int dove_pinctrl_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *match =
 		of_match_device(dove_pinctrl_of_match, &pdev->dev);
+	struct resource *mpp_res;
+
+	mpp_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mpp_base = devm_ioremap_resource(&pdev->dev, mpp_res);
+	if (IS_ERR(mpp_base))
+		return PTR_ERR(mpp_base);
+
 	pdev->dev.platform_data = (void *)match->data;
 
 	/*
@@ -789,7 +798,7 @@ static int dove_pinctrl_probe(struct platform_device *pdev)
 	}
 	clk_prepare_enable(clk);
 
-	return mvebu_pinctrl_probe(pdev);
+	return mvebu_pinctrl_probe(pdev, mpp_base);
 }
 
 static int dove_pinctrl_remove(struct platform_device *pdev)
diff --git a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
index 6b504b5935a5..842ceb196726 100644
--- a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
+++ b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
@@ -21,6 +21,8 @@
 
 #include "pinctrl-mvebu.h"
 
+static void __iomem *mpp_base;
+
 #define V(f6180, f6190, f6192, f6281, f6282, dx4122)	\
 	((f6180 << 0) | (f6190 << 1) | (f6192 << 2) |	\
 	 (f6281 << 3) | (f6282 << 4) | (dx4122 << 5))
@@ -458,8 +460,15 @@ static int kirkwood_pinctrl_probe(struct platform_device *pdev)
 {
 	const struct of_device_id *match =
 		of_match_device(kirkwood_pinctrl_of_match, &pdev->dev);
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mpp_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mpp_base))
+		return PTR_ERR(mpp_base);
+
 	pdev->dev.platform_data = (void *)match->data;
-	return mvebu_pinctrl_probe(pdev);
+	return mvebu_pinctrl_probe(pdev, mpp_base);
 }
 
 static int kirkwood_pinctrl_remove(struct platform_device *pdev)
diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 0fd1ad31fbf9..90c35b20a7af 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -590,26 +590,24 @@ static int mvebu_pinctrl_build_functions(struct platform_device *pdev,
 	return 0;
 }
 
-int mvebu_pinctrl_probe(struct platform_device *pdev)
+int mvebu_pinctrl_probe(struct platform_device *pdev, void __iomem *base)
 {
 	struct mvebu_pinctrl_soc_info *soc = dev_get_platdata(&pdev->dev);
-	struct resource *res;
 	struct mvebu_pinctrl *pctl;
-	void __iomem *base;
 	struct pinctrl_pin_desc *pdesc;
 	unsigned gid, n, k;
 	int ret;
 
+	if (!base) {
+		dev_err(&pdev->dev, "missing base address\n");
+		return -EINVAL;
+	}
+
 	if (!soc || !soc->controls || !soc->modes) {
 		dev_err(&pdev->dev, "wrong pinctrl soc info\n");
 		return -EINVAL;
 	}
 
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	base = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(base))
-		return PTR_ERR(base);
-
 	pctl = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_pinctrl),
 			GFP_KERNEL);
 	if (!pctl) {
diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.h b/drivers/pinctrl/mvebu/pinctrl-mvebu.h
index 90bd3beee860..b66949040e0a 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.h
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.h
@@ -186,7 +186,7 @@ struct mvebu_pinctrl_soc_info {
 		.npins = _npins,				\
 	}
 
-int mvebu_pinctrl_probe(struct platform_device *pdev);
+int mvebu_pinctrl_probe(struct platform_device *pdev, void __iomem *base);
 int mvebu_pinctrl_remove(struct platform_device *pdev);
 
 #endif
-- 
1.8.5.2

^ permalink raw reply related

* [PATCH v2 04/21] ARM: dove: add global-config register node
From: Sebastian Hesselbarth @ 2014-01-28  0:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390869573-27624-1-git-send-email-sebastian.hesselbarth@gmail.com>

We share global config registers by syscon node, add it to dove.dtsi.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 69405e00f2c8..fb289d83b76d 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -618,6 +618,12 @@
 				interrupts = <5>;
 			};
 
+			gconf: global-config at e802c {
+				compatible = "marvell,dove-global-config",
+				             "syscon";
+				reg = <0xe802c 0x14>;
+			};
+
 			gpio2: gpio-ctrl at e8400 {
 				compatible = "marvell,orion-gpio";
 				#gpio-cells = <2>;
-- 
1.8.5.2

^ permalink raw reply related

* [PATCH v2 03/21] ARM: dove: add additional pinctrl registers
From: Sebastian Hesselbarth @ 2014-01-28  0:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390869573-27624-1-git-send-email-sebastian.hesselbarth@gmail.com>

Dove pinctrl used additional registers to control MPPs. This patch first
increases existing pinctrl reg property by one register, and then adds
two new ranges for MPP4 and PMU MPP registers.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 8de1031233ae..69405e00f2c8 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -392,7 +392,9 @@
 
 			pinctrl: pin-ctrl at d0200 {
 				compatible = "marvell,dove-pinctrl";
-				reg = <0xd0200 0x10>;
+				reg = <0xd0200 0x14>,
+				      <0xd0440 0x04>,
+				      <0xd802c 0x08>;
 				clocks = <&gate_clk 22>;
 
 				pmx_gpio_0: pmx-gpio-0 {
-- 
1.8.5.2

^ permalink raw reply related

* [PATCH v2 02/21] devicetree: bindings: update MVEBU pinctrl binding documentation
From: Sebastian Hesselbarth @ 2014-01-28  0:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390869573-27624-1-git-send-email-sebastian.hesselbarth@gmail.com>

Dove pinctrl binding now requires three different reg properties. This
updates corresponding binding and example accordingly. While at it, also
document reg property as required for the other MVEBU SoC pinctrl nodes.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 .../devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt          | 1 +
 Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt | 1 +
 Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt      | 1 +
 Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt  | 1 +
 Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt     | 2 +-
 5 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
index 01ef408e205f..adda2a8d1d52 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
@@ -5,6 +5,7 @@ part and usage.
 
 Required properties:
 - compatible: "marvell,88f6710-pinctrl"
+- reg: register specifier of MPP registers
 
 Available mpp pins/groups and functions:
 Note: brackets (x) are not part of the mpp name for marvell,function and given
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
index bfa0a2e5e0cb..373dbccd7ab0 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -6,6 +6,7 @@ part and usage.
 Required properties:
 - compatible: "marvell,mv78230-pinctrl", "marvell,mv78260-pinctrl",
               "marvell,mv78460-pinctrl"
+- reg: register specifier of MPP registers
 
 This driver supports all Armada XP variants, i.e. mv78230, mv78260, and mv78460.
 
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
index 50ec3512a292..cf52477cc7ee 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
@@ -6,6 +6,7 @@ part and usage.
 Required properties:
 - compatible: "marvell,dove-pinctrl"
 - clocks: (optional) phandle of pdma clock
+- reg: register specifiers of MPP, MPP4, and PMU MPP registers
 
 Available mpp pins/groups and functions:
 Note: brackets (x) are not part of the mpp name for marvell,function and given
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
index 95daf6335c37..730444a9a4de 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
@@ -8,6 +8,7 @@ Required properties:
               "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl",
               "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl"
               "marvell,98dx4122-pinctrl"
+- reg: register specifier of MPP registers
 
 This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x.
 It also support the 88f6281-based variant in the 98dx412x Bobcat SoCs.
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
index 0a26c3aa4e6d..0c09f4eb2af0 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
@@ -37,7 +37,7 @@ uart1: serial at 12100 {
 
 pinctrl: pinctrl at d0200 {
 	compatible = "marvell,dove-pinctrl";
-	reg = <0xd0200 0x20>;
+	reg = <0xd0200 0x14>, <0xd0440 0x04>, <0xd802c 0x08>;
 
 	pmx_uart1_sw: pmx-uart1-sw {
 		marvell,pins = "mpp_uart1";
-- 
1.8.5.2

^ permalink raw reply related

* [PATCH v2 01/21] devicetree: bindings: add missing Marvell Dove SoC documentation
From: Sebastian Hesselbarth @ 2014-01-28  0:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390869573-27624-1-git-send-email-sebastian.hesselbarth@gmail.com>

Marvell Dove SoC binding was not documented, yet. Add the documentation
and also describe Global Configuration register node in it.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 .../devicetree/bindings/arm/marvell,dove.txt       | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell,dove.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell,dove.txt b/Documentation/devicetree/bindings/arm/marvell,dove.txt
new file mode 100644
index 000000000000..aaaf64c56e44
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell,dove.txt
@@ -0,0 +1,22 @@
+Marvell Dove Platforms Device Tree Bindings
+-----------------------------------------------
+
+Boards with a Marvell Dove SoC shall have the following properties:
+
+Required root node property:
+- compatible: must contain "marvell,dove";
+
+* Global Configuration registers
+
+Global Configuration registers of Dove SoC are shared by a syscon node.
+
+Required properties:
+- compatible: must contain "marvell,dove-global-config" and "syscon".
+- reg: base address and size of the Global Configuration registers.
+
+Example:
+
+gconf: global-config at e802c {
+	compatible = "marvell,dove-global-config", "syscon";
+	reg = <0xe802c 0x14>;
+};
-- 
1.8.5.2

^ permalink raw reply related

* [PATCH v2 00/21] pinctrl: mvebu: restructure and remove hardcoded addresses from Dove pinctrl
From: Sebastian Hesselbarth @ 2014-01-28  0:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390674856-4993-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch set is one required step for Dove to hop into mach-mvebu.
Until now, pinctrl-dove was hardcoding some registers that do not
directly belong to MPP core registers. This is not compatible with
what we want for mach-mvebu.

Unfortunately, the common pinctrl driver part has a design flaw,
that requires some restructuring. As Thomas pointed out, the redesign
taken in v1 [1] is not sufficient for possible future Orion5x SoC pinctrl.

The "common" part of the patch set therefore, overhawls MVEBU pinctrl
to remove any register mangling from the common pinctrl driver and
moves it into SoC specific drivers instead.

The "Dove" part of the patch set removes all hardcoded addresses
from pinctrl-dove by either requesting additional resources or a
syscon provided regmap for global config registers. As this changes
existing driver to DT binding relationship, all additional resources
are probed in a backward compatible way. If the corresponding resource
cannot be found, we derive it from the existing pinctrl resource and
warn about the old DTB firmware.

Patches 1 to 4 remain unchanged:

Patch 1 and 2 add or update binding documentation for dove, global
config syscon, and pinctrl-dove. The latter also documents missing reg
property requirement for other mvebu pinctrl nodes.

Patch 3 and 4 add the new pinctrl reg property values and global config
register syscon to exisiting dove.dtsi.

Patches 5-8 now prepare to fix the misdesign of common mvebu pinctrl
driver, that requested the resource instead of getting it from the SoC
specific driver stub:

Patch 5 temporarily adds passing the base address the common driver
and moves resource requests to the SoC specific drivers. Patch 6 adds
some useful mask/shift defines. Patches 7 and 8 allow to identify
mpp pin ranges by NULL mpp name instead of special get/set callbacks.

Patches 9-12 provide SoC specific callbacks for mpp ctrl registers
even if they match the standard layout. This then allows patches 13
and 14 to get rid of base addresses and the temporary address passing.

Patches 15-20 comprise the rebased hardcoded address removal for
Dove from v1. Patch 21 finally consolidates Dove pmu mpp definition
by exploiting auto-numbering of mpp names.

The patch set is still based on pre-v3.14-rc1 mainline.  It has been
boot tested on Dove and compile tested only for Kirkwood, Armada 370
and XP.

[1] https://lkml.org/lkml/2014/1/25/131

Sebastian Hesselbarth (21):
  devicetree: bindings: add missing Marvell Dove SoC documentation
  devicetree: bindings: update MVEBU pinctrl binding documentation
  ARM: dove: add additional pinctrl registers
  ARM: dove: add global-config register node
  pinctrl: mvebu: prepare to fix misdesigned resource allocation
  pinctrl: mvebu: add common mpp reg defines to mvebu pinctrl include
  pinctrl: mvebu: move generic group name generation
  pinctrl: mvebu: remove checks for mpp_get/set
  pinctrl: mvebu: dove: provide generic mpp callbacks
  pinctrl: mvebu: kirkwood: provide generic mpp callbacks
  pinctrl: mvebu: armada-370: provide generic mpp callbacks
  pinctrl: mvebu: armada-xp: provide generic mpp callbacks
  pinctrl: mvebu: remove unused macros and functions
  pinctrl: mvebu: remove base address from common driver
  pinctrl: mvebu: dove: request additional resources
  pinctrl: mvebu: dove: request syscon regmap for global registers
  pinctrl: mvebu: dove: use remapped mpp base registers
  pinctrl: mvebu: dove: use remapped mpp4 register
  pinctrl: mvebu: dove: use remapped pmu_mpp registers
  pinctrl: mvebu: dove: use global register regmap
  pinctrl: mvebu: dove: consolidate auto-numbered pmu mpp ranges

 .../devicetree/bindings/arm/marvell,dove.txt       |  22 ++
 .../pinctrl/marvell,armada-370-pinctrl.txt         |   1 +
 .../bindings/pinctrl/marvell,armada-xp-pinctrl.txt |   1 +
 .../bindings/pinctrl/marvell,dove-pinctrl.txt      |   1 +
 .../bindings/pinctrl/marvell,kirkwood-pinctrl.txt  |   1 +
 .../bindings/pinctrl/marvell,mvebu-pinctrl.txt     |   2 +-
 arch/arm/boot/dts/dove.dtsi                        |  10 +-
 drivers/pinctrl/mvebu/Kconfig                      |   1 +
 drivers/pinctrl/mvebu/pinctrl-armada-370.c         |  34 +-
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c          |  38 ++-
 drivers/pinctrl/mvebu/pinctrl-dove.c               | 374 +++++++++++++--------
 drivers/pinctrl/mvebu/pinctrl-kirkwood.c           |  39 ++-
 drivers/pinctrl/mvebu/pinctrl-mvebu.c              |  94 +-----
 drivers/pinctrl/mvebu/pinctrl-mvebu.h              |  16 +-
 14 files changed, 388 insertions(+), 246 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell,dove.txt

---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
-- 
1.8.5.2

^ permalink raw reply

* Samsung-clk patches for 3.15
From: Tomasz Figa @ 2014-01-28  0:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <251c01cf1bbd$36802390$a3806ab0$@samsung.com>



On 28.01.2014 01:09, Kukjin Kim wrote:
> Tomasz Figa wrote:
>>
>> [Forgot to Cc Mike...]
>>
>> On 24.01.2014 15:38, Tomasz Figa wrote:
>>> Hi,
>>>
>
> Hi,
>
>>> Linux 3.14 is going to include Andrzej Hajda's patches converting
>>> Samsung clock drivers to use clock ID defines in include/dt-bindings,
>>> instead of local enums, but to avoid unnecessary merge conflicts we
>>> have converted only the clock driver, leaving DTS files unchanged yet.
>>>
>>> We intend to complete the conversion in 3.15, by replacing magic
>>> numbers in DTS files with respective preprocessor macros, but to
>>> reduce potential conflicts we need help of you, Samsung clock patches
>> authors :).
>>>
>>> I'd like to ask anybody who already has patches for DTS files adding
>>> any clock-related contents still using numeric IDs, e.g. clock
>>> properties in nodes or full nodes containing clock properties, to make
>>> sure that the patches are merged before Andrzej sends the conversion
>>> patches. Then Andrzej's script will generate patches updating all
>>> clock properties, leaving no numeric IDs in DTS files.
>>>
>
> There are several DTS patches in v3.14-drop/soc-exynos-2 branch of my tree
> for 3.15 and it will be merged after done of multiplatform, I need to rebase
> them based on v3.14-rc1 though...So I think, would be better if we could
> update DTS with using Andrzej's script after merging it into arm-soc...

Basically my intention is to:

1) Have any existing patches using clock numbers merged in reasonable 
period of time (to not miss the merge window with DTS conversion patches).

2) Stop accepting such patches anymore.

3) Rerun Andrzej's script and convert all device tree sources to use 
clock macros.

Andrzej's patches for DTSes should go through your tree anyway (as any 
Samsung DTS patches by default), so it shouldn't be a problem, 
regardless of merging anything into arm-soc.

Best regards,
Tomasz

^ permalink raw reply

* Samsung-clk patches for 3.15
From: Kukjin Kim @ 2014-01-28  0:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E6EDC1.9080003@gmail.com>

Tomasz Figa wrote:
> 
> [Forgot to Cc Mike...]
> 
> On 24.01.2014 15:38, Tomasz Figa wrote:
> > Hi,
> >

Hi,

> > Linux 3.14 is going to include Andrzej Hajda's patches converting
> > Samsung clock drivers to use clock ID defines in include/dt-bindings,
> > instead of local enums, but to avoid unnecessary merge conflicts we
> > have converted only the clock driver, leaving DTS files unchanged yet.
> >
> > We intend to complete the conversion in 3.15, by replacing magic
> > numbers in DTS files with respective preprocessor macros, but to
> > reduce potential conflicts we need help of you, Samsung clock patches
> authors :).
> >
> > I'd like to ask anybody who already has patches for DTS files adding
> > any clock-related contents still using numeric IDs, e.g. clock
> > properties in nodes or full nodes containing clock properties, to make
> > sure that the patches are merged before Andrzej sends the conversion
> > patches. Then Andrzej's script will generate patches updating all
> > clock properties, leaving no numeric IDs in DTS files.
> >

There are several DTS patches in v3.14-drop/soc-exynos-2 branch of my tree
for 3.15 and it will be merged after done of multiplatform, I need to rebase
them based on v3.14-rc1 though...So I think, would be better if we could
update DTS with using Andrzej's script after merging it into arm-soc...

> > If you are just starting your work on a patch that introduces changes
> > as mentioned above, please make sure to already use clock macros, not
> > numeric IDs. Otherwise you risk having needless rebases with a lot of
> > conflicts. You have been warned ;).
> >

Thanks,
Kukjin

^ permalink raw reply

* Samsung-clk patches for 3.15
From: Tomasz Figa @ 2014-01-27 23:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E27AE9.7040501@samsung.com>

[Forgot to Cc Mike...]

On 24.01.2014 15:38, Tomasz Figa wrote:
> Hi,
>
> Linux 3.14 is going to include Andrzej Hajda's patches converting
> Samsung clock drivers to use clock ID defines in include/dt-bindings,
> instead of local enums, but to avoid unnecessary merge conflicts we have
> converted only the clock driver, leaving DTS files unchanged yet.
>
> We intend to complete the conversion in 3.15, by replacing magic numbers
> in DTS files with respective preprocessor macros, but to reduce
> potential conflicts we need help of you, Samsung clock patches authors :).
>
> I'd like to ask anybody who already has patches for DTS files adding any
> clock-related contents still using numeric IDs, e.g. clock properties in
> nodes or full nodes containing clock properties, to make sure that the
> patches are merged before Andrzej sends the conversion patches. Then
> Andrzej's script will generate patches updating all clock properties,
> leaving no numeric IDs in DTS files.
>
> If you are just starting your work on a patch that introduces changes as
> mentioned above, please make sure to already use clock macros, not
> numeric IDs. Otherwise you risk having needless rebases with a lot of
> conflicts. You have been warned ;).
>
> Best regards,
> Tomasz
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [RFC PATCH V3 0/4] APM X-Gene PCIe controller
From: Tanmay Inamdar @ 2014-01-27 22:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CALdTtnsEo74UeYgoQ0DF7=LN074b_0bL0vg6Bxs02B9nDkRTNA@mail.gmail.com>

On Sat, Jan 25, 2014 at 8:09 AM, Dann Frazier
<dann.frazier@canonical.com> wrote:
> On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> This patch adds support for AppliedMicro X-Gene PCIe host controller. The
>> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
>> cards.
>>
>> X-Gene PCIe controller driver has depedency on the pcie arch support for
>> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
>> and approach for arch support is under discussion with arm64 maintainers.
>> The reference patch can be found here --> https://lkml.org/lkml/2013/10/23/244
>
> The reference patch looks corrupted (pcibios.c has no includes, etc),
> would you mind reposting?

Yes. You are right. I will re-post the patch.

>
>   -dann
>
>> If someone wishes to test PCIe on X-Gene, arch support patch must be applied
>> before the patches in this patch set.
>>
>> changes since V2:
>> 1. redefined each PCI port in different PCI domain correctly.
>> 2. removed setup_lane and setup_link functions from driver.
>> 3. removed scan_bus wrapper and set_primary_bus hack.
>> 4. added pci_ioremap_io for io resources.
>>
>> changes since V1:
>> 1. added PCI domain support
>> 2. reading cpu and pci addresses from device tree to configure regions.
>> 3. got rid of unnecessary wrappers for readl and writel.
>> 4. got rid of endpoint configuration code.
>> 5. added 'dma-ranges' property support to read inbound region configuration.
>> 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
>> 7. dropped 'clock-names' property from bindings
>> 8. added comments whereever requested.
>>
>> Tanmay Inamdar (4):
>>   pci: APM X-Gene PCIe controller driver
>>   arm64: dts: APM X-Gene PCIe device tree nodes
>>   dt-bindings: pci: xgene pcie device tree bindings
>>   MAINTAINERS: entry for APM X-Gene PCIe host driver
>>
>>  .../devicetree/bindings/pci/xgene-pci.txt          |   52 ++
>>  MAINTAINERS                                        |    7 +
>>  arch/arm64/boot/dts/apm-mustang.dts                |    8 +
>>  arch/arm64/boot/dts/apm-storm.dtsi                 |  155 ++++
>>  drivers/pci/host/Kconfig                           |   10 +
>>  drivers/pci/host/Makefile                          |    1 +
>>  drivers/pci/host/pci-xgene.c                       |  784 ++++++++++++++++++++
>>  7 files changed, 1017 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
>>  create mode 100644 drivers/pci/host/pci-xgene.c
>>
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
From: Tanmay Inamdar @ 2014-01-27 22:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5086198.ZOWZ5xuyna@wuerfel>

On Sat, Jan 25, 2014 at 12:11 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
>> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> > On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> On Wednesday 15 January 2014, Tanmay Inamdar wrote:
>
>> >>
>> >>> +static void xgene_pcie_poll_linkup(struct xgene_pcie_port *port, u32 *lanes)
>> >>> +{
>> >>> +     void *csr_base = port->csr_base;
>> >>> +     u32 val32;
>> >>> +     u64 start_time, time;
>> >>> +
>> >>> +     /*
>> >>> +      * A component enters the LTSSM Detect state within
>> >>> +      * 20ms of the end of fundamental core reset.
>> >>> +      */
>> >>> +     msleep(XGENE_LTSSM_DETECT_WAIT);
>> >>> +     port->link_up = 0;
>> >>> +     start_time = jiffies;
>> >>> +     do {
>> >>> +             val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
>> >>> +             if (val32 & LINK_UP_MASK) {
>> >>> +                     port->link_up = 1;
>> >>> +                     port->link_speed = PIPE_PHY_RATE_RD(val32);
>> >>> +                     val32 = readl(csr_base + BRIDGE_STATUS_0);
>> >>> +                     *lanes = val32 >> 26;
>> >>> +             }
>> >>> +             time = jiffies_to_msecs(jiffies - start_time);
>> >>> +     } while ((!port->link_up) || (time <= XGENE_LTSSM_L0_WAIT));
>> >>> +}
>> >>
>> >> Maybe another msleep() in the loop? It seems weird to first do an
>> >> unconditional sleep but then busy-wait for the result.
>> >
>> > ok.
>>
>> This loop can execute for maximum 4 msec. So putting msleep(1) won't
>> get us much.
>
> 4 msec is still quite a long time for a busy loop that can be spent doing
> useful work in another thread.
>

Right. If 'msleep(1)' is used, then 'checkpatch' throws a warning
saying that it can actually sleep for 20ms in some cases. I will check
if 'usleep_range' is useful here.

>> >>
>> >> Another general note: Your "compatible" strings are rather unspecific.
>> >> Do you have a version number for this IP block? I suppose that it's related
>> >> to one that has been used in other chips before, or will be used in future
>> >> chips, if it's not actually licensed from some other company.
>> >
>> > I will have to check this.
>> >
>>
>> We have decided to stick with current compatible string for now.
>
> Can you elaborate on your reasoning? Does this mean X-Gene is a one-off
> product and you won't be doing any new chips based on the same hardware
> components?

The current convention is to key upon the family name - X-Gene. Future
chips will also be a part of X-Gene family. Right now it is unclear if
there are any obvious feature additions to be done in Linux PCIe
driver. Until then same driver is expected to work as is in future
chips.

>
>         Arnd

^ permalink raw reply

* [Q] block / zynq: DMA bouncing
From: Guennadi Liakhovetski @ 2014-01-27 22:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E69E1E.3020202@monstr.eu>

Hi Michal, Russell,

On Mon, 27 Jan 2014, Michal Simek wrote:

> On 01/27/2014 06:52 PM, Russell King - ARM Linux wrote:
> > On Mon, Jan 27, 2014 at 06:45:50PM +0100, Michal Simek wrote:
> >> Why 0x4000? IRC Linux for ARM is using space for any purpose.
> >> Russell knows this much better than I.
> > 
> > Probably because as the kernel is loaded at 0x8000, it will place the
> > swapper page table at 0x4000, thus covering from 0x4000 upwards.
> 
> Ah yeah swapper.
> 
> > 
> > Thus, the majority of your un-DMA-able memory will be kernel text or
> > swapper page tables.
> 
> Yes, exactly.
> 0x0 - 0x4000 - reserving not to be used by DMA
> 0x4000 - 0x8000 swapper page table
> 0x8000 - 0x80000 kernel text + up

Good, thanks for the explanations and examples, we'll do the same then!

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

^ permalink raw reply

* [PATCH-next] drivers/clk: make max77686 driver bool for now
From: Paul Gortmaker @ 2014-01-27 22:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140127215257.4167.26286@quantum>

On 14-01-27 04:52 PM, Mike Turquette wrote:
> Quoting Paul Gortmaker (2014-01-23 11:32:15)
>> Commit 3966c947f45911e093114371462687134d5e8d40 ("clk: max77686:
>> Refactor driver data handling") added a call to __clk_get_hw()
>> but this function is not exported (as __<name> is typically a
>> private/internal thing).
>>
>> Hence this driver fails to build modular, and has been causing
>> allmodconfig build breakage in arch outside of just ARM.  Since
>> the only defconfig that uses it sets it as =y, lets just make
>> it non-modular for now.
>>
>> Mike says that changes are pending to export similar functionality
>> in the future[1], so at that point in time, it can be returned to
>> tristate if desired.
> 
> Hi Paul,
> 
> I've just sent off my 2nd pull request for 3.14 and it includes the
> export for __clk_get_hw.

Sounds good ; I wasn't too partial to how it got fixed, but just
wanting to see the ARCH != ARM build fallout go away.

Thanks,
Paul.
--

> 
> Regards,
> Mike
> 
>>
>> [1] https://lkml.org/lkml/2014/1/20/21
>>
>> Reported-by: SeongJae Park <sj38.park@gmail.com>
>> Cc: SeongJae Park <sj38.park@gmail.com>
>> Cc: Tomasz Figa <t.figa@samsung.com>
>> Cc: Kyungmin Park <kyungmin.park@samsung.com>
>> Cc: Mike Turquette <mturquette@linaro.org>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index efb508a..009fb9b 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -40,7 +40,7 @@ config COMMON_CLK_VERSATILE
>>           - Versatile Express
>>  
>>  config COMMON_CLK_MAX77686
>> -       tristate "Clock driver for Maxim 77686 MFD"
>> +       bool "Clock driver for Maxim 77686 MFD"
>>         depends on MFD_MAX77686
>>         ---help---
>>           This driver supports Maxim 77686 crystal oscillator clock. 
>> -- 
>> 1.8.5.2
>>

^ permalink raw reply

* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Arnaud Ebalard @ 2014-01-27 22:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140123110914.GA22913@1wt.eu>

Hi Willy,

Willy Tarreau <w@1wt.eu> writes:

>> > I don't know if it should have included FL1009, it was just a guess,
>> > based on the fact that the 0x1000 and 0x1400 devices did need MSI
>> > disabled.  I can attempt to ask the Fresco Logic folks I know, but I'm
>> > not sure if/when I'll get a response back.
>> >
>> > That still doesn't necessarily rule out MSI issues in the Marvell PCI
>> > host controller code.  Can you attach another PCI device with MSI
>> > support under the host and see if it works?
>> 
>> The various Armada-based devices I have are NAS which do not have PCIe
>> slots to plug additional devices (everything is soldered). I don't know
>> which device Thomas used for its tests. Just in case, I also added Willy
>> in CC: who have various boards and may also have done more test with
>> additional PCIe devices and CONFIG_PCI_MSI enabled on 3.13 kernel.
>
> I've been running an intel i350 dual-port NIC (igb driver) supporting
> MSI on the mirabox, and it used to work in 3.10+many of the patches
> coming from the Free-electrons team. Some recent changes to the PCI
> code introduced a regression preventing this driver from correctly
> registering an MSI interrupt, and I did not have enough time to
> investigate it deep enough to fix it. That said, I know how to hack
> it to work again, so if it can be of any use, I can run a test on
> the mirabox (armada370) and on the XPGP board (armadaXP).

Thanks for the proposal, Willy. I guess Thomas can tell better than me
what kind of tests would help ruling out a problem in MSI support and
put the blame on FL chip ;-) Thomas, if you need me to test something on
some of my platforms, do not hesitate.

Cheers,

a+

^ permalink raw reply

* [PATCH-next] drivers/clk: make max77686 driver bool for now
From: Mike Turquette @ 2014-01-27 21:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390505535-30229-1-git-send-email-paul.gortmaker@windriver.com>

Quoting Paul Gortmaker (2014-01-23 11:32:15)
> Commit 3966c947f45911e093114371462687134d5e8d40 ("clk: max77686:
> Refactor driver data handling") added a call to __clk_get_hw()
> but this function is not exported (as __<name> is typically a
> private/internal thing).
> 
> Hence this driver fails to build modular, and has been causing
> allmodconfig build breakage in arch outside of just ARM.  Since
> the only defconfig that uses it sets it as =y, lets just make
> it non-modular for now.
> 
> Mike says that changes are pending to export similar functionality
> in the future[1], so at that point in time, it can be returned to
> tristate if desired.

Hi Paul,

I've just sent off my 2nd pull request for 3.14 and it includes the
export for __clk_get_hw.

Regards,
Mike

> 
> [1] https://lkml.org/lkml/2014/1/20/21
> 
> Reported-by: SeongJae Park <sj38.park@gmail.com>
> Cc: SeongJae Park <sj38.park@gmail.com>
> Cc: Tomasz Figa <t.figa@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index efb508a..009fb9b 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -40,7 +40,7 @@ config COMMON_CLK_VERSATILE
>           - Versatile Express
>  
>  config COMMON_CLK_MAX77686
> -       tristate "Clock driver for Maxim 77686 MFD"
> +       bool "Clock driver for Maxim 77686 MFD"
>         depends on MFD_MAX77686
>         ---help---
>           This driver supports Maxim 77686 crystal oscillator clock. 
> -- 
> 1.8.5.2
> 

^ permalink raw reply

* [PATCH 0/2] Enable clock controllers on MSM
From: Mike Turquette @ 2014-01-27 21:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <69BE1300-36E8-400B-BD77-DB89740C10D2@codeaurora.org>

Quoting Kumar Gala (2014-01-23 13:57:58)
> 
> On Jan 23, 2014, at 2:43 PM, Olof Johansson <olof@lixom.net> wrote:
> 
> > On Thu, Jan 23, 2014 at 11:59 AM, Kumar Gala <galak@codeaurora.org> wrote:
> >> 
> >> On Jan 23, 2014, at 11:25 AM, Kevin Hilman <khilman@linaro.org> wrote:
> >> 
> >>> Stephen Boyd <sboyd@codeaurora.org> writes:
> >>> 
> >>>> These patches add the clock controller nodes, enable the clock drivers
> >>>> on MSM based platforms, and hook it up enough to get the serial console
> >>>> working. This is based on the merge of Mike's clk-next branch with
> >>>> linux-next-20140116. The changes need the clk-next branch because that's
> >>>> where the DTS include files landed.
> >>> 
> >>> I forgot to repond to this earlier, but I tested this on top of -next
> >>> and it gets the dragonboard booting w/mainline.  Yay!
> >>> 
> >>>> Perhaps this can be applied after 3.14-rc1 is out?
> >>> 
> >>> Yeah, sounds good.
> >>> 
> >>> Kevin
> >> 
> >> We?ll need arm-soc to pull in the clk changes from Mike?s tree for that.
> > 
> > They're queued for this merge window, right? If so, they'll be in -rc1
> > and the dependency will be solved before we apply the patches.
> > 
> 
> Yeah, they look like they are in Mike?s pull request for Linus.  So hopefully they?ll show up in -rc1 (wasn?t sure if Mike intended them for 3.14 or not).

They are in the second pull request which I just sent today.

Regards,
Mike

> 
> What?s the feeling about pushing DT and defconfig changes into 3.14 (or do we just queue them up for 3.15)?
> 
> - k
> 
> -- 
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 

^ permalink raw reply

* [PATCH RESEND v2 00/12] clk/exynos convert clock IDs to macros
From: Mike Turquette @ 2014-01-27 21:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1514827.Cd6xxeNpq2@amdc1227>

Quoting Tomasz Figa (2014-01-07 07:17:22)
> Hi Mike,
> 
> On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote:
> > Hi,
> > 
> > This patch set adds header files with macros defining exynos clocks.
> > Then it converts dts files and drivers to use macros instead
> > of magic numbers or enums to describe clock bindings.
> > 
> > The patch set is rebased on the latest samsung-clk/samsung-next branch.
> > 
> > The patches are generated by script.
> > Many clocks I have verified by hand.
> > I have also tested it successfully on exynos4 based board.
> > 
> > This is the 2nd version of the patchset.
> > Changes:
> > - corrected devicetree mailing list,
> > - added comments to include/dt-bindings/clock/exynos4.h for
> >   clocks present only in particular chip,
> > - added tab alignement in headers,
> > - added comment to CLK_NR_CLKS,
> > - added copyright headers,
> > - split long lines in dts,
> > - corrected example in bindings/clock/exynos5250-clock.txt, to point
> >   appropriate clocks.
> 
> I believe this has been already acked before, so could you still take
> it for 3.14? For now I'd merge only the patches adding headers and
> updating clock drivers to avoid merge conflicts and then after
> release of 3.14-rc1 we could early merge dts patches for 3.15.

Hi Tomasz,

Let's go ahead and merge this after 3.14-rc1. I'll take it in when that
drops and the DTS data will go in during the same merge window.

Regards,
Mike

> 
> What do you think?
> 
> Best regards,
> Tomasz
> 

^ permalink raw reply

* [PATCH] arm64: Add pdev_archdata for dmamask
From: Yann Droneaud @ 2014-01-27 21:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140127203635.GA15937@n2100.arm.linux.org.uk>

Hi Russel,

Le lundi 27 janvier 2014 ? 20:36 +0000, Russell King - ARM Linux a
?crit :
> On Mon, Jan 27, 2014 at 09:25:31PM +0100, Yann Droneaud wrote:
> > ARM, even AAAAARGH64 [1], doesn't need a special treatement regarding
> > the infamous dma_mask pointer. So perhaps my solution is better.
> > 
> > This solution (adding dma_mask in pdev_archdata) is already in use in
> > powerpc architecture. See arch/powerpc/kernel/setup-common.c
> > 
> > The advantage of this solution is that it makes a dma_mask placeholder
> > available to statically allocated platform_device struct, while mine
> > only address the problem for platform_device struct allocated with
> > platform_device_alloc().
> 
> As I've already said in this thread, the basic problem comes from DT's
> platform device creation.  It's the responsibility of the device creator
> to set the dma_mask pointer appropriately, and DT doesn't do that.  So,
> DT needs to be fixed rather than everyone introducing their own
> workarounds for this.
>

Sure proliferation of fixes is not what we want.

Note that Uwe added me to the thread not because I tried to address
the same issue, but I tried to improve platform_device_register_full() to
not allocate and leak an u64 used to hold the dma mask provided as part of
platform_device_info. I believe he thought the two issues could be solved
at the same time.

> > I'm also considering using dma_set_mask_and_coherent() in
> > platform_device_register_full() and drivers using
> > platform_device_alloc().
> 
> As the one who introduced dma_set_mask_and_coherent, consider this a
> strong NAK on that.  The reason is dma_set_mask_and_coherent() is
> for drivers to set their requirements, not for the bus requirements
> to be set in the first place.
> 
> It also means that drivers which need no DMA support are subjected to
> DMA restrictions (in that dma_set_mask_and_coherent can error out if
> the platform can't support the DMA mask.)
> 

I'm not sure to understand your point here. If the driver explicitly set
a DMA mask in its call to platform_device_register_full(), can't we suppose
it should be subject to restriction from the platform ?

As I'm not sure to be clear on this particular point, here's the patch I
was considering, (sorry of being quite out of topic):

                           ---8<---

Subject: [PATCH] driver core/platform: use dma_set_mask_and_coherent() in
 platform_device_register_full()

dma_set_mask_and_coherent() is a nice function for setting the
various DMA masks in struct device. Additionnaly, it checks the
mask value against arch limits.

It may be used to control the validity of the dma_mask given to
platform_device_register_full() and setting the masks in struct
platform_device.

Note: as dma_set_mask() does nothing on m68k, or returns -EINVAL
      on sparc (if PCI support not built), etc. this could break
      in unpleasant ways I'm not yet able to detail ...

Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k at lists.linux-m68k.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux at vger.kernel.org
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
---
 drivers/base/platform.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index bc78848dd59a..ada1d366e1b6 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -446,8 +446,10 @@ struct platform_device *platform_device_register_full(
 		if (!pdev->dev.dma_mask)
 			goto err;
 
-		*pdev->dev.dma_mask = pdevinfo->dma_mask;
-		pdev->dev.coherent_dma_mask = pdevinfo->dma_mask;
+		ret = dma_set_mask_and_coherent(&pdev->dev,
+						pdevinfo->dma_mask);
+		if (ret)
+			goto err;
 	}
 
 	ret = platform_device_add_resources(pdev,
-- 
1.8.5.3

^ permalink raw reply related

* [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases
From: Bill Pringlemeir @ 2014-01-27 21:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EDAD85E@DBDE04.ent.ti.com>


> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]

>> So it seems that your intention is to use the existing infrastructure
>> for this by directing SGIs through the normal IRQ processing.
>> To that idea, I say no way.

On  6 Jan 2014, hvaibhav at ti.com wrote:

> You have any other alternative?

I think you need to put Bhupesh Sharma's comment with this.  The typical
sane mode for GIC with TZ is to have the monitor mode toggle the IRQ/FIQ
routing bits in the SCR (cp15) bits 1,2.  That is, the IRQ goes direct
to core and FIQ goes to monitor from the 'Normal' world.  In the
'Secure' world, the FIQ goes direct to core and IRQ traps to monitor.
The monitor mode vector table has a gateway from secure to normal for
IRQ and gateway from normal to secure for FIQ.

Now, consider the 'SMC' instruction and what is present in stuff like
this,

 http://lwn.net/Articles/513756/
 mach-omap2/{omap-smc.S,omap-secure.c,omap-secure.h}

Instead of messing around with the GIC, why not use something even more
generic like the 'SMC' instruction.  It has the same sort of 'end game'
which is a trap to monitor mode.  The monitor has to be a little smarter
to determine which world called but this should always be the case;
really you want to check this.

Btw, the situation is the same no matter which world Linux is in.  I
don't think Linux can be the recipient of an 'SMC' call.  But I think
most use cases would put it in the 'normal world' and the SMC is fine.

Fwiw,
Bill Pringlemeir.

^ permalink raw reply

* [PATCH 2/3] ASoC: atmel_wm8904: make it available to choose clock
From: Mark Brown @ 2014-01-27 20:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52D7366B.1030909@atmel.com>

On Thu, Jan 16, 2014 at 09:31:23AM +0800, Bo Shen wrote:

> >Shouldn't this code be in the DAI driver?  Otherwise this series looks
> >fine to me, though the DT folks might have something to say I guess.

>   For audio on Atmel SoC, it depends on three device nodes, one is
> SSC node, one is the codec node and the sound node.
>   The sound node will parse by machine driver, and machine driver is
> mainly for hardware connection. As the "clk_from_rk_pin" is decided
> by hardware, so, I put it here.
>   If I move the code to dai driver, it will parse the sound node in
> dai driver, I think it will make the code a little bit not explicit.
> What do you think?

I think it should just be a property of the DAI device.  It's true that
the card defines the connections but if something is going to be an
option that's there for most if not all systems then putting it in the
device driver means less effort on each integration.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/2940e34c/attachment.sig>

^ permalink raw reply

* [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Mark Brown @ 2014-01-27 20:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140127204534.GB15937@n2100.arm.linux.org.uk>

On Mon, Jan 27, 2014 at 08:45:34PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 08:43:02PM +0000, Mark Brown wrote:
> > On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:

> > > +	- audio-ports: one or two values.
> > > +		The first value defines the I2S input port.
> > > +		The second one, if present, defines the S/PDIF input port.

> > I take it these are port numbers on the device and it's not possible to
> > do something like having multiple I2S ports?

> You can feed it with multiple synchronised I2S streams for the additional
> channels.

Ah, I feared as much.  The bindings ought to take account of that
posibility even if the code can't use additional ports yet.  Perhaps
separate properties for I2S and S/PDIF?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/5b441d2e/attachment.sig>

^ permalink raw reply

* [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Mark Brown @ 2014-01-27 20:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140127204915.GC15937@n2100.arm.linux.org.uk>

On Mon, Jan 27, 2014 at 08:49:15PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 08:44:41PM +0000, Mark Brown wrote:

> > Can this parsing code be factored out - it (or large parts of it) should
> > be usable by other HDMI devices shouldn't it?

> Yes, preferably as a generic ALSA helper rather than an ASoC helper -
> I don't see any need for this to be ASoC specific (I have a pure ALSA
> driver which has very similar code in it.)

Indeed, definitely ALSA generic - ideally we could factor a lot of the
integration with the video side out.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/2d20285d/attachment.sig>

^ permalink raw reply

* [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Russell King - ARM Linux @ 2014-01-27 20:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140127204441.GZ11841@sirena.org.uk>

On Mon, Jan 27, 2014 at 08:44:41PM +0000, Mark Brown wrote:
> On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
> 
> > +		eld_ver = eld[0] >> 3;
> > +		if (eld_ver != 2 && eld_ver != 31)
> > +			return 0;
> > +
> > +		mnl = eld[4] & 0x1f;
> > +		if (mnl > 16)
> > +			return 0;
> > +
> > +		sad_count = eld[5] >> 4;
> > +		sad = eld + 20 + mnl;
> 
> Can this parsing code be factored out - it (or large parts of it) should
> be usable by other HDMI devices shouldn't it?

Yes, preferably as a generic ALSA helper rather than an ASoC helper -
I don't see any need for this to be ASoC specific (I have a pure ALSA
driver which has very similar code in it.)

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox