Devicetree
 help / color / mirror / Atom feed
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel
  Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla

The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
devices. It has 2 ports which it can use for either; both SATA, both
PCIe or one of each in any configuration.

Cc: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 .../devicetree/bindings/phy/phy-miphy365x.txt      | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
new file mode 100644
index 0000000..fdfa7ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,43 @@
+STMicroelectronics STi MIPHY365x PHY binding
+============================================
+
+This binding describes a miphy device that is used to control PHY hardware
+for SATA and PCIe.
+
+Required properties:
+- compatible: Should be "st,miphy365x-phy"
+- #phy-cells: Should be 2 (See example)
+- reg:	      Address and length of the register set for the device
+- reg-names:  The names of the register addresses corresponding to the
+	      registers filled in "reg".
+- st,syscfg : Should be a phandle of the syscfg node.
+
+Example:
+
+	miphy365x_phy: miphy365x@0 {
+		compatible = "st,miphy365x-phy";
+		#phy-cells = <1>;
+		reg =	<0xfe382000 0x100>,
+			<0xfe38a000 0x100>,
+			<0xfe394000 0x100>,
+			<0xfe804000 0x100>;
+		reg-names = "sata0", "sata1", "pcie0", "pcie1";
+		st,syscfg= <&syscfg_rear>;
+	};
+
+Specifying phy control of devices
+=================================
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the miphy device node, a port number
+and a device type.
+
+Example:
+
+#include <dt-bindings/phy/phy-miphy365x.h>
+
+	sata0: sata@fe380000 {
+		...
+		phys	  = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+		...
+	};
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 12/14] net: axienet: Use of_property_* calls
From: Michal Simek @ 2014-02-12 15:55 UTC (permalink / raw)
  To: netdev
  Cc: Srikanth Thokala, Srikanth Thokala, Michal Simek,
	Anirudha Sarangi, John Linn, Grant Likely, Rob Herring,
	linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <cover.1392220536.git.michal.simek@xilinx.com>

[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]

From: Srikanth Thokala <srikanth.thokala@xilinx.com>

Use of_property_* calls

Signed-off-by: Srikanth Thokala <sthokal@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 41 ++++++++++-------------
 1 file changed, 17 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 936a14c..9a9ffbc 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1493,13 +1493,13 @@ static void axienet_dma_err_handler(unsigned long data)
  */
 static int axienet_of_probe(struct platform_device *pdev)
 {
-	__be32 *p;
-	int size, ret = 0;
+	int ret;
 	struct device_node *np;
 	struct axienet_local *lp;
 	struct net_device *ndev;
-	const void *addr;
+	u8 mac_addr[6];
 	struct resource *ethres, dmares;
+	u32 value;

 	ndev = alloc_etherdev(sizeof(*lp));
 	if (!ndev)
@@ -1530,9 +1530,9 @@ static int axienet_of_probe(struct platform_device *pdev)
 	/* Setup checksum offload, but default to off if not specified */
 	lp->features = 0;

-	p = (__be32 *) of_get_property(pdev->dev.of_node, "xlnx,txcsum", NULL);
-	if (p) {
-		switch (be32_to_cpup(p)) {
+	ret = of_property_read_u32(pdev->dev.of_node, "xlnx,txcsum", &value);
+	if (!ret) {
+		switch (value) {
 		case 1:
 			lp->csum_offload_on_tx_path =
 				XAE_FEATURE_PARTIAL_TX_CSUM;
@@ -1551,9 +1551,9 @@ static int axienet_of_probe(struct platform_device *pdev)
 			lp->csum_offload_on_tx_path = XAE_NO_CSUM_OFFLOAD;
 		}
 	}
-	p = (__be32 *) of_get_property(pdev->dev.of_node, "xlnx,rxcsum", NULL);
-	if (p) {
-		switch (be32_to_cpup(p)) {
+	ret = of_property_read_u32(pdev->dev.of_node, "xlnx,rxcsum", &value);
+	if (!ret) {
+		switch (value) {
 		case 1:
 			lp->csum_offload_on_rx_path =
 				XAE_FEATURE_PARTIAL_RX_CSUM;
@@ -1574,17 +1574,10 @@ static int axienet_of_probe(struct platform_device *pdev)
 	 * Here we check for memory allocated for Rx/Tx in the hardware from
 	 * the device-tree and accordingly set flags.
 	 */
-	p = (__be32 *) of_get_property(pdev->dev.of_node, "xlnx,rxmem", NULL);
-	if (p)
-		lp->rxmem = be32_to_cpup(p);
-	p = (__be32 *) of_get_property(pdev->dev.of_node, "xlnx,temac-type",
-				       NULL);
-	if (p)
-		lp->temac_type = be32_to_cpup(p);
-	p = (__be32 *) of_get_property(pdev->dev.of_node,
-						"xlnx,phy-type", NULL);
-	if (p)
-		lp->phy_type = be32_to_cpup(p);
+	of_property_read_u32(pdev->dev.of_node, "xlnx,rxmem", &lp->rxmem);
+	of_property_read_u32(pdev->dev.of_node, "xlnx,temac-type",
+					&lp->temac_type);
+	of_property_read_u32(pdev->dev.of_node, "xlnx,phy-type", &lp->phy_type);

 	/* Find the DMA node, map the DMA registers, and decode the DMA IRQs */
 	np = of_parse_phandle(pdev->dev.of_node, "axistream-connected", 0);
@@ -1614,13 +1607,13 @@ static int axienet_of_probe(struct platform_device *pdev)
 	}

 	/* Retrieve the MAC address */
-	addr = of_get_property(pdev->dev.of_node, "local-mac-address", &size);
-	if ((!addr) || (size != 6)) {
+	ret = of_property_read_u8_array(pdev->dev.of_node,
+			"local-mac-address", mac_addr, 6);
+	if (ret) {
 		dev_err(&pdev->dev, "could not find MAC address\n");
-		ret = -ENODEV;
 		goto free_netdev;
 	}
-	axienet_set_mac_address(ndev, (void *) addr);
+	axienet_set_mac_address(ndev, (void *) mac_addr);

 	lp->coalesce_count_rx = XAXIDMA_DFT_RX_THRESHOLD;
 	lp->coalesce_count_tx = XAXIDMA_DFT_TX_THRESHOLD;
--
1.8.2.3


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply related

* [PATCH 10/14] net: axienet: Use pdev instead of op
From: Michal Simek @ 2014-02-12 15:55 UTC (permalink / raw)
  To: netdev
  Cc: Srikanth Thokala, Srikanth Thokala, Michal Simek,
	Anirudha Sarangi, John Linn, Grant Likely, Rob Herring,
	linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <cover.1392220536.git.michal.simek@xilinx.com>

[-- Attachment #1: Type: text/plain, Size: 5876 bytes --]

From: Srikanth Thokala <srikanth.thokala@xilinx.com>

Synchronize names with other drivers

Signed-off-by: Srikanth Thokala <sthokal@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 49 ++++++++++++-----------
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 4fd8a1d..324033c 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1480,7 +1480,7 @@ static void axienet_dma_err_handler(unsigned long data)

 /**
  * axienet_of_probe - Axi Ethernet probe function.
- * @op:		Pointer to platform device structure.
+ * @pdev:	Pointer to platform device structure.
  * @match:	Pointer to device id structure
  *
  * returns: 0, on success
@@ -1491,7 +1491,7 @@ static void axienet_dma_err_handler(unsigned long data)
  * device. Parses through device tree and populates fields of
  * axienet_local. It registers the Ethernet device.
  */
-static int axienet_of_probe(struct platform_device *op)
+static int axienet_of_probe(struct platform_device *pdev)
 {
 	__be32 *p;
 	int size, ret = 0;
@@ -1505,9 +1505,9 @@ static int axienet_of_probe(struct platform_device *op)
 		return -ENOMEM;

 	ether_setup(ndev);
-	platform_set_drvdata(op, ndev);
+	platform_set_drvdata(pdev, ndev);

-	SET_NETDEV_DEV(ndev, &op->dev);
+	SET_NETDEV_DEV(ndev, &pdev->dev);
 	ndev->flags &= ~IFF_MULTICAST;  /* clear multicast */
 	ndev->features = NETIF_F_SG;
 	ndev->netdev_ops = &axienet_netdev_ops;
@@ -1515,18 +1515,18 @@ static int axienet_of_probe(struct platform_device *op)

 	lp = netdev_priv(ndev);
 	lp->ndev = ndev;
-	lp->dev = &op->dev;
+	lp->dev = &pdev->dev;
 	lp->options = XAE_OPTION_DEFAULTS;
 	/* Map device registers */
-	lp->regs = of_iomap(op->dev.of_node, 0);
+	lp->regs = of_iomap(pdev->dev.of_node, 0);
 	if (!lp->regs) {
-		dev_err(&op->dev, "could not map Axi Ethernet regs.\n");
+		dev_err(&pdev->dev, "could not map Axi Ethernet regs.\n");
 		goto nodev;
 	}
 	/* Setup checksum offload, but default to off if not specified */
 	lp->features = 0;

-	p = (__be32 *) of_get_property(op->dev.of_node, "xlnx,txcsum", NULL);
+	p = (__be32 *) of_get_property(pdev->dev.of_node, "xlnx,txcsum", NULL);
 	if (p) {
 		switch (be32_to_cpup(p)) {
 		case 1:
@@ -1547,7 +1547,7 @@ static int axienet_of_probe(struct platform_device *op)
 			lp->csum_offload_on_tx_path = XAE_NO_CSUM_OFFLOAD;
 		}
 	}
-	p = (__be32 *) of_get_property(op->dev.of_node, "xlnx,rxcsum", NULL);
+	p = (__be32 *) of_get_property(pdev->dev.of_node, "xlnx,rxcsum", NULL);
 	if (p) {
 		switch (be32_to_cpup(p)) {
 		case 1:
@@ -1570,43 +1570,44 @@ static int axienet_of_probe(struct platform_device *op)
 	 * Here we check for memory allocated for Rx/Tx in the hardware from
 	 * the device-tree and accordingly set flags.
 	 */
-	p = (__be32 *) of_get_property(op->dev.of_node, "xlnx,rxmem", NULL);
+	p = (__be32 *) of_get_property(pdev->dev.of_node, "xlnx,rxmem", NULL);
 	if (p)
 		lp->rxmem = be32_to_cpup(p);
-	p = (__be32 *) of_get_property(op->dev.of_node, "xlnx,temac-type",
+	p = (__be32 *) of_get_property(pdev->dev.of_node, "xlnx,temac-type",
 				       NULL);
 	if (p)
 		lp->temac_type = be32_to_cpup(p);
-	p = (__be32 *) of_get_property(op->dev.of_node, "xlnx,phy-type", NULL);
+	p = (__be32 *) of_get_property(pdev->dev.of_node,
+						"xlnx,phy-type", NULL);
 	if (p)
 		lp->phy_type = be32_to_cpup(p);

 	/* Find the DMA node, map the DMA registers, and decode the DMA IRQs */
-	np = of_parse_phandle(op->dev.of_node, "axistream-connected", 0);
+	np = of_parse_phandle(pdev->dev.of_node, "axistream-connected", 0);
 	if (!np) {
-		dev_err(&op->dev, "could not find DMA node\n");
+		dev_err(&pdev->dev, "could not find DMA node\n");
 		goto err_iounmap;
 	}
 	lp->dma_regs = of_iomap(np, 0);
 	if (lp->dma_regs) {
-		dev_dbg(&op->dev, "MEM base: %p\n", lp->dma_regs);
+		dev_dbg(&pdev->dev, "MEM base: %p\n", lp->dma_regs);
 	} else {
-		dev_err(&op->dev, "unable to map DMA registers\n");
+		dev_err(&pdev->dev, "unable to map DMA registers\n");
 		of_node_put(np);
 	}
 	lp->rx_irq = irq_of_parse_and_map(np, 1);
 	lp->tx_irq = irq_of_parse_and_map(np, 0);
 	of_node_put(np);
 	if ((lp->rx_irq <= 0) || (lp->tx_irq <= 0)) {
-		dev_err(&op->dev, "could not determine irqs\n");
+		dev_err(&pdev->dev, "could not determine irqs\n");
 		ret = -ENOMEM;
 		goto err_iounmap_2;
 	}

 	/* Retrieve the MAC address */
-	addr = of_get_property(op->dev.of_node, "local-mac-address", &size);
+	addr = of_get_property(pdev->dev.of_node, "local-mac-address", &size);
 	if ((!addr) || (size != 6)) {
-		dev_err(&op->dev, "could not find MAC address\n");
+		dev_err(&pdev->dev, "could not find MAC address\n");
 		ret = -ENODEV;
 		goto err_iounmap_2;
 	}
@@ -1615,11 +1616,11 @@ static int axienet_of_probe(struct platform_device *op)
 	lp->coalesce_count_rx = XAXIDMA_DFT_RX_THRESHOLD;
 	lp->coalesce_count_tx = XAXIDMA_DFT_TX_THRESHOLD;

-	lp->phy_node = of_parse_phandle(op->dev.of_node, "phy-handle", 0);
+	lp->phy_node = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
 	if (lp->phy_node)
-		ret = axienet_mdio_setup(lp, op->dev.of_node);
+		ret = axienet_mdio_setup(lp, pdev->dev.of_node);
 	if (ret)
-		dev_warn(&op->dev, "error registering MDIO bus\n");
+		dev_warn(&pdev->dev, "error registering MDIO bus\n");

 	ret = register_netdev(lp->ndev);
 	if (ret) {
@@ -1640,9 +1641,9 @@ nodev:
 	return ret;
 }

-static int axienet_of_remove(struct platform_device *op)
+static int axienet_of_remove(struct platform_device *pdev)
 {
-	struct net_device *ndev = platform_get_drvdata(op);
+	struct net_device *ndev = platform_get_drvdata(pdev);
 	struct axienet_local *lp = netdev_priv(ndev);

 	axienet_mdio_teardown(lp);
--
1.8.2.3


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply related

* [PATCH 0/14] Xilinx axi ethernet patches
From: Michal Simek @ 2014-02-12 15:55 UTC (permalink / raw)
  To: netdev
  Cc: Srikanth Thokala, devicetree, monstr, John Linn, Anirudha Sarangi,
	linux-kernel, Grant Likely, Rob Herring, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

Hi,

I have exctracted patches which I have in our
xilinx git tree which are missing in the mainline.

The first two patches fix compilation error and
warnings. Then 5 feature patches
and the rest is OF cleanup and with kernel-doc
and checkpatch problems.

Thanks,
Michal


Michal Simek (4):
  net: axienet: Fix compilation error
  net: axienet: Fix compilation warnings
  net: axienet: Fix comments blocks
  net: axienet: Fix kernel-doc warnings

Peter Crosthwaite (2):
  net: axienet: Handle 0 packet receive gracefully
  net: axienet: Service completion interrupts ASAP

Srikanth Thokala (8):
  net: axienet: Support for RGMII
  net: axienet: Handle jumbo frames for lesser frame sizes
  net: axienet: Support phy-less mode of operation
  net: axienet: Removed checkpatch errors/warnings
  net: axienet: Use pdev instead of op
  net: axienet: Use devm_* calls
  net: axienet: Use of_property_* calls
  net: axienet: Removed _of_ prefix in probe and remove functions

 drivers/net/ethernet/xilinx/xilinx_axienet.h      | 108 ++++----
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 307 ++++++++++++----------
 drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c |  30 ++-
 3 files changed, 241 insertions(+), 204 deletions(-)

--
1.8.2.3


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: [PATCH 2/3] regulator: gpio-regulator: do not open-code counting and access of dt array elements
From: Mark Brown @ 2014-02-12 15:51 UTC (permalink / raw)
  To: Heiko Stübner
  Cc: grant.likely, robh+dt, devicetree, linux-kernel, Liam Girdwood
In-Reply-To: <1553563.pNlhnjkCFL@phil>

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

On Wed, Feb 12, 2014 at 01:01:08AM +0100, Heiko Stübner wrote:
> From: Heiko Stuebner <heiko.stuebner@bqreaders.com>
> 
> Open coding the counting of elements in a dt-property is abstracted by the newly
> introduced of_property_count_uXX_elems functions. Additionally the raw iteration

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH 3/3] regulator: ti-abb-regulator: do not open-code counting and access of dt array elements
From: Mark Brown @ 2014-02-12 15:50 UTC (permalink / raw)
  To: Heiko Stübner
  Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood
In-Reply-To: <2193931.Kqcd3TrslU@phil>

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On Wed, Feb 12, 2014 at 01:01:42AM +0100, Heiko Stübner wrote:
> From: Heiko Stuebner <heiko.stuebner-HCpLIkUQxWGakBO8gow8eQ@public.gmane.org>
> 
> Open coding the counting of elements in a dt-property is abstracted by the newly
> introduced of_property_count_uXX_elems functions. Additionally the raw iteration
> over the states element exposes the endian conversion and dtb-format details,
> which according to Mark Rutland "would be nice to limit [...] to of_ helper
> functions".

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH 1/3] of: add functions to count number of elements in a property
From: Mark Brown @ 2014-02-12 15:48 UTC (permalink / raw)
  To: Heiko Stübner
  Cc: grant.likely, robh+dt, devicetree, linux-kernel, Liam Girdwood
In-Reply-To: <2409422.L9c2tQTy2E@phil>

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Wed, Feb 12, 2014 at 01:00:34AM +0100, Heiko Stübner wrote:
> From: Heiko Stuebner <heiko.stuebner@bqreaders.com>
> 
> The need to know the number of array elements in a property is
> a common pattern. To prevent duplication of open-coded implementations
> add a helper static function that also centralises strict sanity
> checking and DTB format details, as well as a set of wrapper functions
> for u8, u16, u32 and u64.

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Shawn Guo @ 2014-02-12 15:20 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Fabio Estevam,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fabio Estevam
In-Reply-To: <20140212135736.GB25957-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>

On Wed, Feb 12, 2014 at 01:57:36PM +0000, Mark Rutland wrote:
> As it stands, the dts are buggy. I can appreciate that you don't feel
> this is important, but I do. It's not just an IMX issue, there is
> widespread misunderstanding and abuse of simple-bus.
> 
> Said abuse is relying on current Linux implementation details, and that
> can and will create problems if and when probing code is changed.

The reality is the code already gets no chance to change on this regard,
considering the requirement that we need to maintain the interface
between kernel and DT as ABI.  The dts have been there like this for
10 kernel releases or so.

> There's no good reason for abusing the binding when we can get it right
> today.

As I said from the beginning, though I personally take it as a churn, I
will still be happy take the change, as long as my upstream folks are
also fine with it.

Shawn

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

^ permalink raw reply

* Re: [PATCH 01/17] Documentation: i2c: describe devicetree method for instantiating devices
From: Wolfram Sang @ 2014-02-12 15:15 UTC (permalink / raw)
  To: linux-0h96xk9xTtrk1uMJSBkQmQ
  Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Landley,
	linux-doc-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140210122119.115858a7ntu4lr40-S15kz1ZIOvSoVoj5zvVkGw@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]


> There is now also a means to instantiate I2C devices through
> ACPI. This is documented in Documentation/acpi/enumeration.txt.
> 
> Might be worthwhile to reference it from instantiating-devices.
> I guess that would be a separate patch though.

Yes, it would. Thanks for the pointer!


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Brown @ 2014-02-12 15:13 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Pawel Moll,
	Linus Walleij
In-Reply-To: <20140212114740.GE21992-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

On Wed, Feb 12, 2014 at 11:47:40AM +0000, Mark Rutland wrote:

> I assume that for the non-dt case it's possible to name clock inputs to
> a device without the clock being associated with the name globally? If
> so we could get rid of the index usage entirely in this case.

Yes, using clk_add_alias().

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH v4] gpio: davinci: reuse for keystone soc
From: Linus Walleij @ 2014-02-12 15:03 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: Santosh Shilimkar, Sekhar Nori, Rob Herring, Alexandre Courbot,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
In-Reply-To: <1391615244-12014-1-git-send-email-grygorii.strashko-l0cyMroinI0@public.gmane.org>

On Wed, Feb 5, 2014 at 4:47 PM, Grygorii Strashko
<grygorii.strashko-l0cyMroinI0@public.gmane.org> wrote:

> The similar GPIO HW block is used by keystone SoCs as
> in Davinci SoCs.
> Hence, reuse Davinci GPIO driver for Keystone taking into
> account that Keystone contains ARM GIC IRQ controller which
> is implemented using IRQ Chip.
>
> Documentation:
>         http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>
> Acked-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
> Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
> ---
> Changes in v4:
> - rebased on top of v3.14 +
>   [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()

I tried applying this and it does not apply on the "devel" branch
in the GPIO tree. Since I haven't touched one line of code in the
DaVinci driver since v3.14-rc1 I seriously doubt that this is
rebased on v3.14[-rc].

Can you please rebase the patch onto v3.14-rc1 for real and
resend it?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 2/2] ehci-platform: Change compatible string from usb-ehci to ehci-platform
From: Maxime Ripard @ 2014-02-12 14:56 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Roger Quadros, Greg Kroah-Hartman, Alan Stern, Tony Prisk,
	Florian Fainelli, linux-usb, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
	Grant Likely, jwboyer-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <52FA4118.2030100-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Tue, Feb 11, 2014 at 04:26:16PM +0100, Hans de Goede wrote:
> > I'm even OK with removing "usb-ehci" and "usb-ohci" compatibles
> > from all OMAP dts files since they aren't really compatible with
> > the original PPC driver.
> 
> I don't think that is necessary, as your grep has shown there are a
> lot of dts files using compatible = "foo", "usb-?hci"; and some may
> even have the dts in firmware, so we should simply make sure not to
> break such dts.

For these devices, we can't do much, but at least for the DT that are
in Linux, relying on the fact that there is no driver having a
compatible of "usb-ehci" to work looks very fragile. I'd be in favour
of removing it from the OMAP DTs, and every affected DTs.

Maxime

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH net-next 01/10] net: phy: add "internal" PHY mode
From: Sergei Shtylyov @ 2014-02-12 14:35 UTC (permalink / raw)
  To: Florian Fainelli, netdev; +Cc: davem, cernekee, devicetree
In-Reply-To: <1392178053-3143-2-git-send-email-f.fainelli@gmail.com>

Hello.

On 12-02-2014 8:07, Florian Fainelli wrote:

> On some systems, the PHY can be internal, in the same package as the
> Ethernet MAC, and still be responding to a specific address on the MDIO
> bus, in that case, the Ethernet MAC might need to know about it to
> properly configure a port multiplexer to switch to an internal or
> external PHY. Add a new PHY interface mode for this and update the
> Device Tree of_get_phy_mode() function to look for it.

> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[...]

> @@ -553,7 +554,8 @@ static inline bool phy_interrupt_is_valid(struct phy_device *phydev)
>    */
>   static inline bool phy_is_internal(struct phy_device *phydev)
>   {
> -	return phydev->is_internal;
> +	return phydev->is_internal ||
> +		phydev->interface == PHY_INTERFACE_MODE_INTERNAL;

    Shouldn't the continuation line be aligned under 'phydev' on the borken up 
line)?

WBR, Sergei

^ permalink raw reply

* Re: [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Lorenzo Pieralisi @ 2014-02-12 14:34 UTC (permalink / raw)
  To: Amit Kachhap
  Cc: Mark Rutland, Mike Turquette, Tomasz Figa, Mark Hambleton,
	Russell King, Nicolas Pitre, Daniel Lezcano,
	linux-arm-kernel@lists.infradead.org, grant.likely@linaro.org,
	Dave P Martin, Charles Garcia-Tobin, devicetree@vger.kernel.org,
	Kevin Hilman, linux-pm@vger.kernel.org, Kumar Gala, Rob Herring,
	Vincent Guittot, Antti Miettinen, Peter De Schrijver,
	Stephen Boyd, Amit
In-Reply-To: <CADGdYn6O6Vpye8knxXdpGzVQNy9p6mM1Sf-bBs7aQtQv6ReoHQ@mail.gmail.com>

Hi Amit,

On Wed, Feb 12, 2014 at 11:39:28AM +0000, Amit Kachhap wrote:
> Hi Lorenzo,
> 
> This patch series looks nice and explains the ARM C state DT bindings clearly.
Thank you.

[...]

> > +     - entry-latency
> > +             Usage: Required
> > +             Value type: <prop-encoded-array>
> > +             Definition: u32 value representing worst case latency
> > +                         in microseconds required to enter the idle state.
> I liked your V2 version of OPP based latency more. However in this way
> also latency supplied can correspond to max OPP and based on the
> current OPP, the cpuidle driver can compute the new latency
> proportionately. In case of frequency this can be linear but may not
> be linear for residency.

I understand that, but the bindings do not preclude having a list instead of
just worst case value. Let's go for the worst case and build on it
(when we have a decent method to express OPP dependencies in the DT bindings,
that is not the case at present). Your point is taken, I just want a first
version that provides the groundwork on top of which more complex
bindings can be defined.

> > +
> > +     - exit-latency
> > +             Usage: Required
> > +             Value type: <prop-encoded-array>
> > +             Definition: u32 value representing worst case latency
> > +                         in microseconds required to exit the idle state.
> > +
> > +     - min-residency
> > +             Usage: Required
> > +             Value type: <prop-encoded-array>
> > +             Definition: u32 value representing time in microseconds
> > +                         required for the CPU to be in the idle state to
> > +                         make up for the dynamic power consumed to
> > +                         enter/exit the idle state in order to break even
> > +                         in terms of power consumption compared to idle
> > +                         state index 1 (idle_standby).
> > +
> > +     - power-domains
> > +             Usage: Optional
> > +             Value type: <prop-encoded-array>
> > +             Definition: List of power domain specifiers ([1]) describing
> > +                         the power domains that are affected by the idle
> > +                         state entry.
> I can see power-domains used in 2 places. First in C state definitions
> and second in cpu node cache descriptions. I am not sure but if
> possible than this can be put in one place.

Power domain specifiers are there to link devices (ie caches) to the
idle states. We have to know which devices are affected by an idle state
entry, and that's done through the power-domain (ie all devices that
belong to a power domain affected by the idle state entry must be acted
upon).

All devices have to be linked to the power domain they belong to,
possibly by using a hierarchical representation (to group devices under
a power domain and avoid duplicating the power domain specifier).

> > +
> > +     - cache-state-retained
> > +             Usage: See definition
> > +             Value type: <none>
> > +             Definition: if present cache memory is retained on power down,
> > +                         otherwise it is lost.
> Can the DT bindings support both retained and non-retained with
> different C states? The example shown does not use the retained flag.
> I guess than many combinations are possible.
> Processor retained, cache non-retained = C state 2
> Processor non retained , cache retained = C state 3
> Processor non retained, cache non retained = C state 4

Yes. Those are per idle state properties so the can be used as you defined,
I cannot think of any issue regarding those boolean properties at the
moment, but if you do please flag it up.

Thanks !
Lorenzo

^ permalink raw reply

* Re: [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
From: Paul Cercueil @ 2014-02-12 14:07 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Jonathan Cameron, Lars-Peter Clausen,
	linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org, Pawel Moll,
	Ian Campbell, Kumar Gala,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20140212121832.GF21992-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>

On 02/12/14 13:18, Mark Rutland wrote:
> On Wed, Feb 12, 2014 at 12:01:58PM +0000, Paul Cercueil wrote:
>> Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>> Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>>   .../devicetree/bindings/iio/dac/ad5064.txt         |   49 ++++++++++++++++++++
>>   1 file changed, 49 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
>> new file mode 100644
>> index 0000000..e5997b0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
>> @@ -0,0 +1,49 @@
>> +Analog Devices AD5064 DAC device driver
>
> It would be nice to have a short description here, with useful facts
> (e.g. this is an SPI device).
>
> Is there any public documentation? It might not need to go in the
> document, but having a link really helps with review.

Allright, I will add a short description. I didn't add a link to the 
documentation as it moves every once in a while...

>> +
>> +Required properties:
>> +	- compatible: Must be one of:
>> +		* "adi,ad5024"
>> +		* "adi,ad5025"
>> +		* "adi,ad5044"
>> +		* "adi,ad5045"
>> +		* "adi,ad5064"
>> +		* "adi,ad5064-1"
>> +		* "adi,ad5065"
>> +		* "adi,ad5628-1"
>> +		* "adi,ad5628-2"
>> +		* "adi,ad5648-1"
>> +		* "adi,ad5648-2"
>> +		* "adi,ad5666-1"
>> +		* "adi,ad5666-2"
>> +		* "adi,ad5668-1"
>> +		* "adi,ad5668-2"
>> +		* "adi,ad5668-3"
>
> How do these differ? Are these just different revisions of the same
> chip?
>
> Are particular strings expected to be used as fallbacks in the
> compatible list?

All of those chips are different, but are handled by the ad5064 driver. 
They differ in the number of channels available, in the presence of an 
internal vref and/or its voltage. Some of those use a shared vref, some 
others have a vref per channel. The only similar chips are the ad5668-2 
and ad5668-3.

>> +	- reg: SPI chip select number for the device
>> +	- spi-max-frequency: Max SPI frequency to use (< 30000000)
>> +	- vrefA-supply, vrefB-supply: phandles to external reference voltage
>> +	  supplies for channels 0 and 1 respectively.
>> +	  This property must be present for ad5024, ad5025, ad5044, ad5045,
>> +	  ad5064, ad5065.
>
> Does ad5064 also imply ad5604-1 here?
>
>> +	- vrefC-supply, vrefD-supply: phandles to external reference voltage
>> +	  supplies for channels 2 and 3 respectively.
>> +	  This property must be present for ad5024, ad5044, ad5064.
>
> Likewise.

The ad5064 and ad5064-1 chips are actually different; the first one has 
one vref per channel, the second one use a shared vref.

> These seem oddly named given the description. Are these named A B C D in
> the documentation? If not, vref-channel-X-supply would seem to be
> clearer.

They are named after the pin names on the datasheets: vrefA, vrefB, 
vrefC, vrefD.

> Why are these grouped in pairs rather than listed individually?

All the chips featuring separate vref per channel, have either 2 or 4 
channels, which means that some chips have only the vrefA/vrefB pins, 
while others have them all. These properties were grouped in pairs 
because the description and the list of supported chips are the same, 
but I can list them individually if it's preferred.

>> +
>> +Optional properties:
>> +	- adi,use-external-reference: If set, the external reference voltage
>> +	  supply is used. This should only be set if there is an external
>> +	  reference voltage connected to the vref or vref[A-D] pins.
>> +	  If the property is not set, the internal reference voltage supply
>> +	  is used if present, or an error is issued by the driver.
>
> When would you want to do this, and when would you want to use the
> internal reference? Could the driver not choose to do this based on
> whether a supply is listed in the dt?

Using or not the internal reference is up to the platform. But you make 
a valid point, it would be better for the driver to use the external 
reference if specified in the dt and revert to the internal one 
otherwise. I will fix that in the driver.

> Strip the part about the error, that's not a description of the device
> and not a matter for the binding.

Allright.

>> +	- vref-supply: phandle to the external reference voltage supply.
>> +	  This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
>> +	  ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.
>
> Just to check, on some versions (e.g. ad5668-3), this can work without
> any supply listed at all, yes?

All of those chips except for ad5064-1 have an internal vref, which will 
be used if no external regulator is specified, so yes.

> Cheers,
> Mark.
>

Thanks for your comments!

Regards,
Paul

^ permalink raw reply

* Re: [PATCH] ARM: mm: cache-l2x0: Check for status property of DT node
From: Mark Rutland @ 2014-02-12 14:02 UTC (permalink / raw)
  To: Tomasz Figa
  Cc: devicetree@vger.kernel.org, linux@arm.linux.org.uk, Will Deacon,
	Grant Likely, linux-arm-kernel@lists.infradead.org, Tushar Behera
In-Reply-To: <52FB6C49.6010401@samsung.com>

On Wed, Feb 12, 2014 at 12:42:49PM +0000, Tomasz Figa wrote:
> [making Cc list a bit more comprehensive]
> 
> On 12.02.2014 13:01, Tushar Behera wrote:
> > Currently only the DT node is checked during l2x0 cache initialization,
> > but it doesn't check the status of the DT node. Thus it gets called
> > even if the status of DT node for L2 controller is disabled.
> >
> > Add explicit check to ensure that L2 cache is initialized only for
> > desired boards.
> >
> > Reported-by: Tomasz Figa <t.figa@samsung.com>
> > Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> > ---
> >   arch/arm/mm/cache-l2x0.c |    3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> > index 7abde2c..f075cb1 100644
> > --- a/arch/arm/mm/cache-l2x0.c
> > +++ b/arch/arm/mm/cache-l2x0.c
> > @@ -978,6 +978,9 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
> >   	if (!np)
> >   		return -ENODEV;
> >
> > +	if (!of_device_is_available(np))
> > +		return -ENODEV;
> > +
> >   	if (of_address_to_resource(np, 0, &res))
> >   		return -ENODEV;
> >
> >
> 
> Reviewed-by: Tomasz Figa <t.figa@samsung.com>

Looks sensible to me.

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks,
Mark.

^ permalink raw reply

* Re: [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Mark Rutland @ 2014-02-12 13:57 UTC (permalink / raw)
  To: Shawn Guo
  Cc: Fabio Estevam, devicetree@vger.kernel.org, Fabio Estevam,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140212122837.GD24834@S2101-09.ap.freescale.net>

On Wed, Feb 12, 2014 at 12:28:39PM +0000, Shawn Guo wrote:
> On Wed, Feb 12, 2014 at 09:54:50AM +0000, Mark Rutland wrote:
> > > I take it as an unnecessary churn, unless I see the consensus from most
> > > of DT maintainers and arm-soc folks that we should make this change.
> > > And see comment below ...
> > 
> > My concern is that the simple-bus is being used in a nonsensical way,
> > with a meaningless address space and reg values on children. While this
> > currently works it is not correct, and it's not even necessary. I would
> > like to limit the misuse of these constructs so as to prevent others
> > from making the same mistakes.
> 
> Unfortunately, it's already been used quite widely.  This is not IMX
> specific, and you can grep arch/arm/boot/dts to get the idea.  I'm not
> sure if it's worth the churn to 'fix' it.  In these days, arm-soc folks
> are quite sensitive to the number of IMX patches and change sets.  50
> LOC change for one board dts, and we now have ~70 files for IMX.  That's
> why I would like to get the agreement from arm-soc folks that we should
> really make such change. 

As it stands, the dts are buggy. I can appreciate that you don't feel
this is important, but I do. It's not just an IMX issue, there is
widespread misunderstanding and abuse of simple-bus.

Said abuse is relying on current Linux implementation details, and that
can and will create problems if and when probing code is changed.
There's no good reason for abusing the binding when we can get it right
today.

We don't necessarily have to get rid of every simple bus in use as a
regulator container. While I don't like that use, I am happy to accept
them as long as they are used correctly, with a valid ranges property
and with children having sensible reg values (or no reg values if the
children don't need them as part of their binding).

> 
> > 
> > > 
> > > > 
> > > >  arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 51 ++++++++++++++--------------------
> > > >  1 file changed, 21 insertions(+), 30 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > > index 0d816d3..d7df5b2 100644
> > > > --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > > +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > > @@ -18,38 +18,29 @@
> > > >  		reg = <0x10000000 0x40000000>;
> > > >  	};
> > > >  
> > > > -	regulators {
> > > > -		compatible = "simple-bus";
> > > > -		#address-cells = <1>;
> > > > -		#size-cells = <0>;
> > > > -
> > > > -		reg_usb_otg_vbus: regulator@0 {
> > > > -			compatible = "regulator-fixed";
> > > > -			reg = <0>;
> > > > -			regulator-name = "usb_otg_vbus";
> > > > -			regulator-min-microvolt = <5000000>;
> > > > -			regulator-max-microvolt = <5000000>;
> > > > -			gpio = <&gpio3 22 0>;
> > > > -			enable-active-high;
> > > > -		};
> > > > +	reg_usb_otg_vbus: regulator@0 {
> > > 
> > > nodename@num should only be used for nodes that have 'reg' property.
> > > Why are you dropping 'reg' property here?  Right, it does not compile if
> > > you do not drop it.  You can take it as a reason of why I endorse
> > > simple-bus regulators container.
> > 
> > I don't think the logical jump from "it does not compile" to "I endorse
> > simple-bus regulators container" makes any sense. They're two separate
> > issues.
> 
> You're right :)
> 
> > 
> > The unit-addresses and reg values can be dropped. They are not in the
> > regulator-fixed binding, and were never necessary. All that's necessary
> > is a unique name, and unit-addresses (which required a reg) were misused
> > to provide uniqueness. With that fixed, this will compile.
> 
> IIRC, ePAPR recommends to use generic node name and have
> unit-addresses for uniqueness.  That's why I sent patch [1] to follow
> the way that tegra and other platforms names them.  Now you're
> suggesting to go back?

As far as I can see, that's not what ePAPR says:

  If the node has no reg property, the @ and unit-address must be
  omitted and the node-name alone differentiates the node from other
  nodes at the same level in the tree.

If a binding doesn't require a reg property, then the node shouldn't
have a reg property. If that's true then the node should not have a
unit-address.

Using generic names can certainly help to make dts more legible, and we
don't have to go against that. It's just as easy to understand
regulator_1 and regulator@1.

I can appreciate that this area may be unclear, and that fixing this up
creates churn for what you feel is a minor issue. However, I don't see
that as a reason to perpetuate wrongness.

Thanks,
Mark.

> 
> Shawn
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg284474.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* Re: [PATCH v2] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/media
From: Mauro Carvalho Chehab @ 2014-02-12 13:35 UTC (permalink / raw)
  To: Philipp Zabel
  Cc: Russell King - ARM Linux, Grant Likely, Rob Herring,
	Sylwester Nawrocki, Laurent Pinchart, Tomi Valkeinen,
	Kyungmin Park, linux-kernel, linux-media, devicetree,
	Guennadi Liakhovetski, Philipp Zabel
In-Reply-To: <1392196314.5536.15.camel@pizza.hi.pengutronix.de>

Em Wed, 12 Feb 2014 10:11:54 +0100
Philipp Zabel <p.zabel@pengutronix.de> escreveu:

> Hi Mauro,
> 
> Am Mittwoch, den 12.02.2014, 06:53 +0900 schrieb Mauro Carvalho Chehab:
> [...]
> > > diff --git a/include/media/of_graph.h b/include/media/of_graph.h
> > > new file mode 100644
> > > index 0000000..3bbeb60
> > > --- /dev/null
> > > +++ b/include/media/of_graph.h
> > > @@ -0,0 +1,46 @@
> > > +/*
> > > + * OF graph binding parsing helpers
> > > + *
> > > + * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
> > > + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > > + *
> > > + * Copyright (C) 2012 Renesas Electronics Corp.
> > > + * Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of version 2 of the GNU General Public License as
> > > + * published by the Free Software Foundation.
> > > + */
> > > +#ifndef __LINUX_OF_GRAPH_H
> > > +#define __LINUX_OF_GRAPH_H
> > > +
> > > +#ifdef CONFIG_OF
> > 
> > As a matter of consistency, it would be better to test here for
> > CONFIG_OF_GRAPH instead, to reflect the same symbol that enables such
> > functions as used on Kconfig/Makefile.
> 
> Maybe I'm trying to be too clever for my own good, but my reasoning was
> as follows:
> 
> Suppose I newly use the of_graph_ helpers in a subsystem that does not
> yet select OF_GRAPH. In that case I'd rather get linking errors earlier
> rather than stubbed out functions that silently fail to parse the DT
> later.

I see your point, but, imagining that someone pushed a patch using those
symbols upstream, that would break compilation and git bisection, with 
will hurt everyone, and not only the very few of us that would actually
need the OF_GRAPH symbol for an specific driver.

Also, such push would mean that someone forgot to do his homework and
to test if the committed functionality is actually working.

So, it seems more fair that the one that did the mistake will be the one
that will suffer the consequences for his errors instead of applying a
penalty to everybody's else ;)

> Since there is
> config VIDEO_DEV
> 	select OF_GRAPH if OF
> already and the same should be added for other users of device tree
> graphs, I think stubbing out the functions only if OF is disabled should
> be enough.

Well, if you want to be sure that the graph will always be there if OF, then
you could do, instead:

config OF_GRAPH
	bool
	default OF

(that would actually make OF_GRAPH just an alias to OF - so we could just
use OF instead).

In any case, I think that we should use the same config name at Makefile, 
Kconfig and of_graph.h (either OF_GRAPH or just OF).

Regards,
Mauro

^ permalink raw reply

* [PATCH v3 0/11] Xilinx watchdog changes
From: Michal Simek @ 2014-02-12 13:34 UTC (permalink / raw)
  To: linux-kernel, monstr
  Cc: Guenter Roeck, devicetree, linux-watchdog, linux-doc, Kumar Gala,
	Rob Landley, Wim Van Sebroeck, Ian Campbell, Rob Herring,
	Pawel Moll, Mark Rutland, Grant Likely, linux-arm-kernel,
	Arnd Bergmann

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

Hi,

This series contains changes for Xilinx watchdog.
The whole code series have been reviewed by Guenter
and device-tree binding was acked by Arnd.

I have also pushed this v3 to git repo
for easier pulling here:
git://git.monstr.eu/linux-2.6-microblaze.git watchdog

Thanks,
Michal

Changes in v3:
- Remove one if checking and use variable directly

Changes in v2:
- Fix enable_once logic
- Change patch subject
- New patch in this series

Michal Simek (11):
  watchdog: xilinx: Convert driver to the watchdog framework
  watchdog: xilinx: Move control_status_reg to functions
  watchdog: xilinx: Simplify probe and remove functions
  watchdog: xilinx: Move no_timeout to probe function
  watchdog: xilinx: Allocate private structure per device
  watchdog: xilinx: Fix all printk messages
  watchdog: xilinx: Use of_property_read_u32
  watchdog: xilinx: Use correct comment indentation
  watchdog: xilinx: Add missing binding
  watchdog: xilinx: Enable this driver for Zynq
  watchdog: xilinx: Remove no_timeout variable

 .../devicetree/bindings/watchdog/of-xilinx-wdt.txt |  23 ++
 drivers/watchdog/Kconfig                           |  21 +-
 drivers/watchdog/of_xilinx_wdt.c                   | 389 ++++++---------------
 3 files changed, 148 insertions(+), 285 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt

--
1.8.2.3


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* [PATCH RFC v7 6/6] HACK mmc: mxcmmc: enable clocks for the MPC512x
From: Alexander Popov @ 2014-02-12 13:25 UTC (permalink / raw)
  To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
	Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392211508-23615-1-git-send-email-a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

From: Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>

Q&D HACK to enable SD card support without correct COMMON_CLK support,
best viewed with 'git diff -w -b', NOT acceptable for mainline (NAKed)

Signed-off-by: Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>
[ a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org: resolve little patch conflict ]
---
 drivers/mmc/host/mxcmmc.c | 42 ++++++++++++++++++++++++++++--------------
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index f7199c8..ddefa60 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -1123,20 +1123,29 @@ static int mxcmci_probe(struct platform_device *pdev)
 	host->res = r;
 	host->irq = irq;
 
-	host->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
-	if (IS_ERR(host->clk_ipg)) {
-		ret = PTR_ERR(host->clk_ipg);
-		goto out_iounmap;
-	}
+	if (!is_mpc512x_mmc(host)) {
+		host->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
+		if (IS_ERR(host->clk_ipg)) {
+			ret = PTR_ERR(host->clk_ipg);
+			goto out_iounmap;
+		}
 
-	host->clk_per = devm_clk_get(&pdev->dev, "per");
-	if (IS_ERR(host->clk_per)) {
-		ret = PTR_ERR(host->clk_per);
-		goto out_iounmap;
+		host->clk_per = devm_clk_get(&pdev->dev, "per");
+		if (IS_ERR(host->clk_per)) {
+			ret = PTR_ERR(host->clk_per);
+			goto out_iounmap;
+		}
+	} else {
+		host->clk_per = devm_clk_get(&pdev->dev, "sdhc_clk");
+		if (IS_ERR(host->clk_per)) {
+			ret = PTR_ERR(host->clk_per);
+			goto out_iounmap;
+		}
 	}
 
 	clk_prepare_enable(host->clk_per);
-	clk_prepare_enable(host->clk_ipg);
+	if (host->clk_ipg)
+		clk_prepare_enable(host->clk_ipg);
 
 	mxcmci_softreset(host);
 
@@ -1206,7 +1215,8 @@ out_free_dma:
 		dma_release_channel(host->dma);
 out_clk_put:
 	clk_disable_unprepare(host->clk_per);
-	clk_disable_unprepare(host->clk_ipg);
+	if (host->clk_ipg)
+		clk_disable_unprepare(host->clk_ipg);
 out_iounmap:
 	iounmap(host->base);
 out_free:
@@ -1236,7 +1246,8 @@ static int mxcmci_remove(struct platform_device *pdev)
 		dma_release_channel(host->dma);
 
 	clk_disable_unprepare(host->clk_per);
-	clk_disable_unprepare(host->clk_ipg);
+	if (host->clk_ipg)
+		clk_disable_unprepare(host->clk_ipg);
 
 	release_mem_region(host->res->start, resource_size(host->res));
 
@@ -1252,7 +1263,9 @@ static int mxcmci_suspend(struct device *dev)
 	struct mxcmci_host *host = mmc_priv(mmc);
 
 	clk_disable_unprepare(host->clk_per);
-	clk_disable_unprepare(host->clk_ipg);
+	if (host->clk_ipg)
+		clk_disable_unprepare(host->clk_ipg);
+
 	return 0;
 }
 
@@ -1262,7 +1275,8 @@ static int mxcmci_resume(struct device *dev)
 	struct mxcmci_host *host = mmc_priv(mmc);
 
 	clk_prepare_enable(host->clk_per);
-	clk_prepare_enable(host->clk_ipg);
+	if (host->clk_ipg)
+		clk_prepare_enable(host->clk_ipg);
 	return 0;
 }
 
-- 
1.8.4.2

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

^ permalink raw reply related

* [PATCH RFC v7 5/6] dma: mpc512x: register for device tree channel lookup
From: Alexander Popov @ 2014-02-12 13:25 UTC (permalink / raw)
  To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
	Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392211508-23615-1-git-send-email-a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

From: Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>

register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees) and
provide the '#dma-cells' property in the shared mpc5121.dtsi file

Signed-off-by: Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>
[ a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org: resolve little patch conflict and put
  MPC512x DMA controller bindings document to a separate patch ]
---
 arch/powerpc/boot/dts/mpc5121.dtsi |  1 +
 drivers/dma/mpc512x_dma.c          | 21 ++++++++++++++++++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index 2c0e155..7f9d14f 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -498,6 +498,7 @@
 			compatible = "fsl,mpc5121-dma";
 			reg = <0x14000 0x1800>;
 			interrupts = <65 0x8>;
+			#dma-cells = <1>;
 		};
 	};
 
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index b978ef1..1e0b8cf 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -50,6 +50,7 @@
 #include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
+#include <linux/of_dma.h>
 #include <linux/of_platform.h>
 
 #include <linux/random.h>
@@ -1013,11 +1014,23 @@ static int mpc_dma_probe(struct platform_device *op)
 	/* Register DMA engine */
 	dev_set_drvdata(dev, mdma);
 	retval = dma_async_device_register(dma);
-	if (retval) {
-		devm_free_irq(dev, mdma->irq, mdma);
-		irq_dispose_mapping(mdma->irq);
+	if (retval)
+		goto out_irq;
+
+	/* register with OF helpers for DMA lookups (nonfatal) */
+	if (dev->of_node) {
+		retval = of_dma_controller_register(dev->of_node,
+						    of_dma_xlate_by_chan_id,
+						    mdma);
+		if (retval)
+			dev_warn(dev, "could not register for OF lookup\n");
 	}
 
+	return 0;
+
+out_irq:
+	devm_free_irq(dev, mdma->irq, mdma);
+	irq_dispose_mapping(mdma->irq);
 	return retval;
 }
 
@@ -1026,6 +1039,8 @@ static int mpc_dma_remove(struct platform_device *op)
 	struct device *dev = &op->dev;
 	struct mpc_dma *mdma = dev_get_drvdata(dev);
 
+	if (dev->of_node)
+		of_dma_controller_free(dev->of_node);
 	dma_async_device_unregister(&mdma->dma);
 	devm_free_irq(dev, mdma->irq, mdma);
 	irq_dispose_mapping(mdma->irq);
-- 
1.8.4.2

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

^ permalink raw reply related

* [PATCH RFC v7 4/6] dma: mpc512x: add device tree binding document
From: Alexander Popov @ 2014-02-12 13:25 UTC (permalink / raw)
  To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
	Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392211508-23615-1-git-send-email-a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

From: Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>

introduce a device tree binding document for the MPC512x DMA controller

Signed-off-by: Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>
[ a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org: turn this into a separate patch ]
---
 .../devicetree/bindings/dma/mpc512x-dma.txt        | 55 ++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt

diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
new file mode 100644
index 0000000..a4867d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
@@ -0,0 +1,55 @@
+* Freescale MPC512x DMA Controller
+
+The DMA controller in the Freescale MPC512x SoC can move blocks of
+memory contents between memory and peripherals or memory to memory.
+
+Refer to the "Generic DMA Controller and DMA request bindings" description
+in the dma.txt file for a more detailled discussion of the binding.  The
+MPC512x DMA engine binding follows the common scheme, but doesn't provide
+support for the optional channels and requests counters (those values are
+derived from the detected hardware features) and has a fixed client
+specifier length of 1 integer cell (the value is the DMA channel, since
+the DMA controller uses a fixed assignment of request lines per channel).
+
+
+DMA controller node properties:
+
+Required properties:
+- compatible:		should be "fsl,mpc5121-dma"
+- reg:			address and size of the DMA controller's register set
+- interrupts:		interrupt spec for the DMA controller
+
+Optional properties:
+- #dma-cells:		must be <1>, describes the number of integer cells
+			needed to specify the 'dmas' property in client nodes,
+			strongly recommended since common client helper code
+			uses this property
+
+Example:
+
+	dma0: dma@14000 {
+		compatible = "fsl,mpc5121-dma";
+		reg = <0x14000 0x1800>;
+		interrupts = <65 0x8>;
+		#dma-cells = <1>;
+	};
+
+
+Client node properties:
+
+Required properties:
+- dmas:			list of DMA specifiers, consisting each of a handle
+			for the DMA controller and integer cells to specify
+			the channel used within the DMA controller
+- dma-names:		list of identifier strings for the DMA specifiers,
+			client device driver code uses these strings to
+			have DMA channels looked up at the controller
+
+Example:
+
+	sdhc@1500 {
+		compatible = "fsl,mpc5121-sdhc";
+		/* ... */
+		dmas = <&dma0 30>;
+		dma-names = "rx-tx";
+	};
-- 
1.8.4.2

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

^ permalink raw reply related

* [PATCH RFC v7 3/6] dma: of: Add common xlate function for matching by channel id
From: Alexander Popov @ 2014-02-12 13:25 UTC (permalink / raw)
  To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
	Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392211508-23615-1-git-send-email-a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use to
lookup the channel by the id.

Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When registering the of dma provider with
of_dma_controller_register a pointer to the dma_device struct which is
associated with the dt node needs to passed as the data parameter.
New function will use this pointer to match only channels which belong to the
specified DMA controller.

Signed-off-by: Alexander Popov <a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/dma/of-dma.c   | 35 +++++++++++++++++++++++++++++++++++
 include/linux/of_dma.h |  4 ++++
 2 files changed, 39 insertions(+)

diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index e8fe9dc..d5fbeaa 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -218,3 +218,38 @@ struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
 			&dma_spec->args[0]);
 }
 EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+/**
+ * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel id
+ * @dma_spec:	pointer to DMA specifier as found in the device tree
+ * @of_dma:	pointer to DMA controller data
+ *
+ * This function can be used as the of xlate callback for DMA driver which wants
+ * to match the channel based on the channel id. When using this xlate function
+ * the #dma-cells propety of the DMA controller dt node needs to be set to 1.
+ * The data parameter of of_dma_controller_register must be a pointer to the
+ * dma_device struct the function should match upon.
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+					 struct of_dma *ofdma)
+{
+	struct dma_device *dev = ofdma->of_dma_data;
+	struct dma_chan *chan, *candidate = NULL;
+
+	if (!dev || dma_spec->args_count != 1)
+		return NULL;
+
+	list_for_each_entry(chan, &dev->channels, device_node)
+		if (chan->chan_id == dma_spec->args[0]) {
+			candidate = chan;
+			break;
+		}
+
+	if (!candidate)
+		return NULL;
+
+	return dma_get_slave_channel(candidate);
+}
+EXPORT_SYMBOL_GPL(of_dma_xlate_by_chan_id);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..56bc026 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -41,6 +41,8 @@ extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
 						     const char *name);
 extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
 		struct of_dma *ofdma);
+extern struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+		struct of_dma *ofdma);
 #else
 static inline int of_dma_controller_register(struct device_node *np,
 		struct dma_chan *(*of_dma_xlate)
@@ -66,6 +68,8 @@ static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_s
 	return NULL;
 }
 
+#define of_dma_xlate_by_chan_id NULL
+
 #endif
 
 #endif /* __LINUX_OF_DMA_H */
-- 
1.8.4.2

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

^ permalink raw reply related

* [PATCH RFC v7 2/6] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2014-02-12 13:25 UTC (permalink / raw)
  To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
	Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392211508-23615-1-git-send-email-a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers.

Signed-off-by: Alexander Popov <a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/dma/mpc512x_dma.c | 230 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 225 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 2ce248b..b978ef1 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -2,6 +2,7 @@
  * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
  * Copyright (C) Semihalf 2009
  * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2013
  *
  * Written by Piotr Ziecik <kosmo-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>. Hardware description
  * (defines, structures and comments) was taken from MPC5121 DMA driver
@@ -29,8 +30,15 @@
  */
 
 /*
- * This is initial version of MPC5121 DMA driver. Only memory to memory
- * transfers are supported (tested using dmatest module).
+ * MPC512x and MPC8308 DMA driver. It supports
+ * memory to memory data transfers (tested using dmatest module) and
+ * data transfers between memory and peripheral I/O memory
+ * by means of slave s/g with these limitations:
+ * - chunked transfers (transfers with more than one part) are refused
+ * as long as proper support for scatter/gather is missing;
+ * - transfers on MPC8308 always start from software as this SoC appears
+ * not to have external request lines for peripheral flow control;
+ * - minimal memory <-> I/O memory transfer size is 4 bytes.
  */
 
 #include <linux/module.h>
@@ -189,6 +197,7 @@ struct mpc_dma_desc {
 	dma_addr_t			tcd_paddr;
 	int				error;
 	struct list_head		node;
+	int				will_access_peripheral;
 };
 
 struct mpc_dma_chan {
@@ -201,6 +210,10 @@ struct mpc_dma_chan {
 	struct mpc_dma_tcd		*tcd;
 	dma_addr_t			tcd_paddr;
 
+	/* Settings for access to peripheral FIFO */
+	dma_addr_t			per_paddr;	/* FIFO address */
+	u32				tcd_nunits;
+
 	/* Lock for this structure */
 	spinlock_t			lock;
 };
@@ -251,8 +264,21 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
 	struct mpc_dma_desc *mdesc;
 	int cid = mchan->chan.chan_id;
 
-	/* Move all queued descriptors to active list */
-	list_splice_tail_init(&mchan->queued, &mchan->active);
+	while (!list_empty(&mchan->queued)) {
+		mdesc = list_first_entry(&mchan->queued,
+						struct mpc_dma_desc, node);
+
+		/* Grab either several mem-to-mem transfer descriptors
+		 * or one peripheral transfer descriptor,
+		 * don't mix mem-to-mem and peripheral transfer descriptors
+		 * within the same 'active' list. */
+		if (mdesc->will_access_peripheral) {
+			if (list_empty(&mchan->active))
+				list_move_tail(&mdesc->node, &mchan->active);
+			break;
+		} else
+			list_move_tail(&mdesc->node, &mchan->active);
+	}
 
 	/* Chain descriptors into one transaction */
 	list_for_each_entry(mdesc, &mchan->active, node) {
@@ -278,7 +304,17 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
 
 	if (first != prev)
 		mdma->tcd[cid].e_sg = 1;
-	out_8(&mdma->regs->dmassrt, cid);
+
+	if (mdma->is_mpc8308) {
+		/* MPC8308, no request lines, software initiated start */
+		out_8(&mdma->regs->dmassrt, cid);
+	} else if (first->will_access_peripheral) {
+		/* peripherals involved, start by external request signal */
+		out_8(&mdma->regs->dmaserq, cid);
+	} else {
+		/* memory to memory transfer, software initiated start */
+		out_8(&mdma->regs->dmassrt, cid);
+	}
 }
 
 /* Handle interrupt on one half of DMA controller (32 channels) */
@@ -596,6 +632,7 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
 	}
 
 	mdesc->error = 0;
+	mdesc->will_access_peripheral = 0;
 	tcd = mdesc->tcd;
 
 	/* Prepare Transfer Control Descriptor for this transaction */
@@ -643,6 +680,186 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
 	return &mdesc->desc;
 }
 
+static struct dma_async_tx_descriptor *
+mpc_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+		unsigned int sg_len, enum dma_transfer_direction direction,
+		unsigned long flags, void *context)
+{
+	struct mpc_dma *mdma = dma_chan_to_mpc_dma(chan);
+	struct mpc_dma_chan *mchan = dma_chan_to_mpc_dma_chan(chan);
+	struct mpc_dma_desc *mdesc = NULL;
+	dma_addr_t per_paddr;
+	u32 tcd_nunits;
+	struct mpc_dma_tcd *tcd;
+	unsigned long iflags;
+	struct scatterlist *sg;
+	size_t len;
+	int iter, i;
+
+	/* currently there is no proper support for scatter/gather */
+	if (sg_len != 1)
+		return NULL;
+
+	for_each_sg(sgl, sg, sg_len, i) {
+		spin_lock_irqsave(&mchan->lock, iflags);
+
+		mdesc = list_first_entry(&mchan->free, struct mpc_dma_desc,
+									node);
+		if (!mdesc) {
+			spin_unlock_irqrestore(&mchan->lock, iflags);
+			/* try to free completed descriptors */
+			mpc_dma_process_completed(mdma);
+			return NULL;
+		}
+
+		list_del(&mdesc->node);
+
+		per_paddr = mchan->per_paddr;
+		tcd_nunits = mchan->tcd_nunits;
+
+		spin_unlock_irqrestore(&mchan->lock, iflags);
+
+		if (per_paddr == 0 || tcd_nunits == 0)
+			goto err_prep;
+
+		mdesc->error = 0;
+		mdesc->will_access_peripheral = 1;
+		tcd = mdesc->tcd;
+
+		/* Prepare Transfer Control Descriptor for this transaction */
+
+		memset(tcd, 0, sizeof(struct mpc_dma_tcd));
+
+		if (!IS_ALIGNED(sg_dma_address(sg), 4))
+			goto err_prep;
+
+		if (direction == DMA_DEV_TO_MEM) {
+			tcd->saddr = per_paddr;
+			tcd->daddr = sg_dma_address(sg);
+			tcd->soff = 0;
+			tcd->doff = 4;
+		} else if (direction == DMA_MEM_TO_DEV) {
+			tcd->saddr = sg_dma_address(sg);
+			tcd->daddr = per_paddr;
+			tcd->soff = 4;
+			tcd->doff = 0;
+		} else
+			goto err_prep;
+
+		tcd->ssize = MPC_DMA_TSIZE_4;
+		tcd->dsize = MPC_DMA_TSIZE_4;
+
+		len = sg_dma_len(sg);
+		tcd->nbytes = tcd_nunits * 4;
+		if (!IS_ALIGNED(len, tcd->nbytes))
+			goto err_prep;
+
+		iter = len / tcd->nbytes;
+		if (iter >= 1 << 15) {
+			/* len is too big */
+			goto err_prep;
+		} else {
+			/* citer_linkch contains the high bits of iter */
+			tcd->biter = iter & 0x1ff;
+			tcd->biter_linkch = iter >> 9;
+			tcd->citer = tcd->biter;
+			tcd->citer_linkch = tcd->biter_linkch;
+		}
+
+		tcd->e_sg = 0;
+		tcd->d_req = 1;
+
+		/* Place descriptor in prepared list */
+		spin_lock_irqsave(&mchan->lock, iflags);
+		list_add_tail(&mdesc->node, &mchan->prepared);
+		spin_unlock_irqrestore(&mchan->lock, iflags);
+	}
+
+	return &mdesc->desc;
+
+err_prep:
+	/* Put the descriptor back */
+	spin_lock_irqsave(&mchan->lock, iflags);
+	list_add_tail(&mdesc->node, &mchan->free);
+	spin_unlock_irqrestore(&mchan->lock, iflags);
+
+	return NULL;
+}
+
+static int mpc_dma_device_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
+							unsigned long arg)
+{
+	struct mpc_dma_chan *mchan;
+	struct mpc_dma *mdma;
+	struct dma_slave_config *cfg;
+	unsigned long flags;
+
+	mchan = dma_chan_to_mpc_dma_chan(chan);
+	switch (cmd) {
+	case DMA_TERMINATE_ALL:
+		/* disable channel requests */
+		mdma = dma_chan_to_mpc_dma(chan);
+
+		spin_lock_irqsave(&mchan->lock, flags);
+
+		out_8(&mdma->regs->dmacerq, chan->chan_id);
+		list_splice_tail_init(&mchan->prepared, &mchan->free);
+		list_splice_tail_init(&mchan->queued, &mchan->free);
+		list_splice_tail_init(&mchan->active, &mchan->free);
+
+		spin_unlock_irqrestore(&mchan->lock, flags);
+
+		return 0;
+	case DMA_SLAVE_CONFIG:
+		/* Constraints:
+		 * - only transfers between a peripheral device and
+		 * memory are supported;
+		 * - minimal transfer size is 4 bytes and consequently
+		 * source and destination addresses must be 4-byte aligned and
+		 * transfer size must be aligned on (4 * maxburst) boundary;
+		 * - RAM address is being incremented by minimal transfer size
+		 * during the transfer;
+		 * - peripheral port's address is constant during the transfer.
+		 */
+
+		cfg = (void *)arg;
+
+		if (cfg->direction != DMA_DEV_TO_MEM &&
+			cfg->direction != DMA_MEM_TO_DEV)
+			return -EINVAL;
+
+		if (cfg->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES &&
+			cfg->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
+			return -EINVAL;
+
+		spin_lock_irqsave(&mchan->lock, flags);
+
+		if (cfg->direction == DMA_DEV_TO_MEM) {
+			mchan->per_paddr = cfg->src_addr;
+			mchan->tcd_nunits = cfg->src_maxburst;
+		} else {
+			mchan->per_paddr = cfg->dst_addr;
+			mchan->tcd_nunits = cfg->dst_maxburst;
+		}
+
+		if (!IS_ALIGNED(mchan->per_paddr, 4)) {
+			spin_unlock_irqrestore(&mchan->lock, flags);
+			return -EINVAL;
+		}
+
+		if (mchan->tcd_nunits == 0)
+			mchan->tcd_nunits = 1;	/* apply default */
+
+		spin_unlock_irqrestore(&mchan->lock, flags);
+
+		return 0;
+	default:
+		return -ENOSYS;
+	}
+
+	return -EINVAL;
+}
+
 static int mpc_dma_probe(struct platform_device *op)
 {
 	struct device_node *dn = op->dev.of_node;
@@ -727,9 +944,12 @@ static int mpc_dma_probe(struct platform_device *op)
 	dma->device_issue_pending = mpc_dma_issue_pending;
 	dma->device_tx_status = mpc_dma_tx_status;
 	dma->device_prep_dma_memcpy = mpc_dma_prep_memcpy;
+	dma->device_prep_slave_sg = mpc_dma_prep_slave_sg;
+	dma->device_control = mpc_dma_device_control;
 
 	INIT_LIST_HEAD(&dma->channels);
 	dma_cap_set(DMA_MEMCPY, dma->cap_mask);
+	dma_cap_set(DMA_SLAVE, dma->cap_mask);
 
 	for (i = 0; i < dma->chancnt; i++) {
 		mchan = &mdma->channels[i];
-- 
1.8.4.2

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

^ permalink raw reply related

* [PATCH RFC v7 1/6] dma: mpc512x: reorder mpc8308 specific instructions
From: Alexander Popov @ 2014-02-12 13:25 UTC (permalink / raw)
  To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
	Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
	linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392211508-23615-1-git-send-email-a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Concentrate the specific code for MPC8308 in the 'if' branch
and handle MPC512x in the 'else' branch.
This modification only reorders instructions but doesn't change behaviour.

Signed-off-by: Alexander Popov <a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Anatolij Gustschin <agust-ynQEQJNshbs@public.gmane.org>
Acked-by: Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>
---
 drivers/dma/mpc512x_dma.c | 42 +++++++++++++++++++++++++-----------------
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 448750d..2ce248b 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -52,9 +52,17 @@
 #define MPC_DMA_DESCRIPTORS	64
 
 /* Macro definitions */
-#define MPC_DMA_CHANNELS	64
 #define MPC_DMA_TCD_OFFSET	0x1000
 
+/*
+ * Maximum channel counts for individual hardware variants
+ * and the maximum channel count over all supported controllers,
+ * used for data structure size
+ */
+#define MPC8308_DMACHAN_MAX	16
+#define MPC512x_DMACHAN_MAX	64
+#define MPC_DMA_CHANNELS	64
+
 /* Arbitration mode of group and channel */
 #define MPC_DMA_DMACR_EDCG	(1 << 31)
 #define MPC_DMA_DMACR_ERGA	(1 << 3)
@@ -710,10 +718,10 @@ static int mpc_dma_probe(struct platform_device *op)
 
 	dma = &mdma->dma;
 	dma->dev = dev;
-	if (!mdma->is_mpc8308)
-		dma->chancnt = MPC_DMA_CHANNELS;
+	if (mdma->is_mpc8308)
+		dma->chancnt = MPC8308_DMACHAN_MAX;
 	else
-		dma->chancnt = 16; /* MPC8308 DMA has only 16 channels */
+		dma->chancnt = MPC512x_DMACHAN_MAX;
 	dma->device_alloc_chan_resources = mpc_dma_alloc_chan_resources;
 	dma->device_free_chan_resources = mpc_dma_free_chan_resources;
 	dma->device_issue_pending = mpc_dma_issue_pending;
@@ -747,7 +755,19 @@ static int mpc_dma_probe(struct platform_device *op)
 	 * - Round-robin group arbitration,
 	 * - Round-robin channel arbitration.
 	 */
-	if (!mdma->is_mpc8308) {
+	if (mdma->is_mpc8308) {
+		/* MPC8308 has 16 channels and lacks some registers */
+		out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
+
+		/* enable snooping */
+		out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
+		/* Disable error interrupts */
+		out_be32(&mdma->regs->dmaeeil, 0);
+
+		/* Clear interrupts status */
+		out_be32(&mdma->regs->dmaintl, 0xFFFF);
+		out_be32(&mdma->regs->dmaerrl, 0xFFFF);
+	} else {
 		out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_EDCG |
 					MPC_DMA_DMACR_ERGA | MPC_DMA_DMACR_ERCA);
 
@@ -768,18 +788,6 @@ static int mpc_dma_probe(struct platform_device *op)
 		/* Route interrupts to IPIC */
 		out_be32(&mdma->regs->dmaihsa, 0);
 		out_be32(&mdma->regs->dmailsa, 0);
-	} else {
-		/* MPC8308 has 16 channels and lacks some registers */
-		out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
-
-		/* enable snooping */
-		out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
-		/* Disable error interrupts */
-		out_be32(&mdma->regs->dmaeeil, 0);
-
-		/* Clear interrupts status */
-		out_be32(&mdma->regs->dmaintl, 0xFFFF);
-		out_be32(&mdma->regs->dmaerrl, 0xFFFF);
 	}
 
 	/* Register DMA engine */
-- 
1.8.4.2

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

^ permalink raw reply related


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