[PATCH v3 0/3] Adding DT support for TI HECC module

[PATCH v3 0/3] Adding DT support for TI HECC module

[yegorslists]

From: Yegor Yefremov <yegorslists@googlemail.com>

This is an attempt to revive DT support for TI HECC that was started in 2015 [1].

Changes v2 -> v3:
  - rename compatible property to "ti,am3517-hecc" (though there is a stipped
    device named 3505, EMAC driver already uses am3517-emac name, so keep this
    property consistent)
  - use reg-names to specify different HECC I/O mapping (suggested by Tony Lindgren)
  - provide fallback offsets and sizes for board files
  - convert optional property ti,int_line to ti,use-hecc1int and add proper
    description

Changes v1 -> v2:
  - change compatible to "ti,am3505
  - remove CONFIG_OF
  - don't set int_line to 0 explicitly

[1] http://comments.gmane.org/gmane.linux.can/8616

Yegor Yefremov (3):
  ARM: dts: AM35x: Add hecc node
  can: ti_hecc: Add TI HECC DT binding documentation
  can: ti_hecc: Add DT support for TI HECC module

 .../devicetree/bindings/net/can/ti_hecc.txt        |  32 +++++
 arch/arm/boot/dts/am3517.dtsi                      |  12 ++
 drivers/net/can/ti_hecc.c                          | 157 +++++++++++++++------
 3 files changed, 156 insertions(+), 45 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc.txt

-- 
2.1.4

[PATCH v3 1/3] ARM: dts: AM35x: Add hecc node

[yegorslists]

From: Yegor Yefremov <yegorslists@googlemail.com>

HECC node description for am35x SOCs

Signed-off-by: Anton Glukhov <anton.a.glukhov@gmail.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
 arch/arm/boot/dts/am3517.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index 9fe545d..00da3f2 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -13,6 +13,7 @@
 / {
 	aliases {
 		serial3 = &uart4;
+		can = &hecc;
 	};
 
 	ocp@68000000 {
@@ -72,6 +73,17 @@
 			pinctrl-single,register-width = <16>;
 			pinctrl-single,function-mask = <0xff1f>;
 		};
+
+		hecc: can@5c050000 {
+			compatible = "ti,am3517-hecc";
+			status = "disabled";
+			reg = <0x5c050000 0x80>,
+			      <0x5c053000 0x180>,
+			      <0x5c052000 0x200>;
+			reg-names = "hecc", "hecc-ram", "mbx";
+			interrupts = <24>;
+			clocks = <&hecc_ck>;
+		};
 	};
 };
 
-- 
2.1.4

[PATCH v3 2/3] can: ti_hecc: Add TI HECC DT binding documentation

[yegorslists]

From: Yegor Yefremov <yegorslists@googlemail.com>

DT binding documentation for TI High End CAN Controller

Signed-off-by: Anton Glukhov <anton.a.glukhov@gmail.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
 .../devicetree/bindings/net/can/ti_hecc.txt        | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc.txt

diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc.txt b/Documentation/devicetree/bindings/net/can/ti_hecc.txt
new file mode 100644
index 0000000..8257428
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ti_hecc.txt
@@ -0,0 +1,32 @@
+Texas Instruments High End CAN Controller (HECC)
+================================================
+
+This file provides information, what the device node
+for the hecc interface contains.
+
+Required properties:
+- compatible: "ti,am3517-hecc"
+- reg: addresses and lengths of the register spaces for 'hecc', 'hecc-ram'
+       and 'mbx'
+- reg-names :"hecc", "hecc-ram", "mbx"
+- interrupts: interrupt mapping for the hecc interrupts sources
+- clocks: clock phandles (see clock bindings for details)
+
+Optional properties:
+- ti,use-hecc1int: if provided configures HECC to produce all interrupts
+		   on HECC1INT interrupt line. By default HECC0INT interrupt
+		   line will be used.
+
+Example:
+
+For am3517evm board:
+	hecc: can@0x5c050000 {
+		compatible = "ti,am3517-hecc";
+		status = "disabled";
+		reg = <0x5c050000 0x80>,
+		      <0x5c053000 0x180>,
+		      <0x5c052000 0x200>;
+		reg-names = "hecc", "hecc-ram", "mbx";
+		interrupts = <24>;
+		clocks = <&hecc_ck>;
+	};
-- 
2.1.4

[PATCH v3 3/3] can: ti_hecc: Add DT support for TI HECC module

[yegorslists]

From: Yegor Yefremov <yegorslists@googlemail.com>

These patch set adds device tree support for TI HECC module.

Signed-off-by: Anton Glukhov <anton.a.glukhov@gmail.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
 drivers/net/can/ti_hecc.c | 157 +++++++++++++++++++++++++++++++++-------------
 1 file changed, 112 insertions(+), 45 deletions(-)

diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index 6749b18..63056f3 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -46,6 +46,8 @@
 #include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
 
 #include <linux/can/dev.h>
 #include <linux/can/error.h>
@@ -57,6 +59,12 @@
 MODULE_VERSION(HECC_MODULE_VERSION);
 #define DRV_DESC "TI High End CAN Controller Driver " HECC_MODULE_VERSION
 
+#define HECC_BASE_SIZE		0x80
+#define HECC_RAM_OFFSET		0x3000
+#define HECC_RAM_SIZE		0x180
+#define MBX_OFFSET		0x2000
+#define MBX_SIZE		0x200
+
 /* TX / RX Mailbox Configuration */
 #define HECC_MAX_MAILBOXES	32	/* hardware mailboxes - do not change */
 #define MAX_TX_PRIO		0x3F	/* hardware value - do not change */
@@ -214,10 +222,9 @@ struct ti_hecc_priv {
 	struct net_device *ndev;
 	struct clk *clk;
 	void __iomem *base;
-	u32 scc_ram_offset;
-	u32 hecc_ram_offset;
-	u32 mbx_offset;
-	u32 int_line;
+	void __iomem *hecc_ram;
+	void __iomem *mbx;
+	bool int_line;
 	spinlock_t mbx_lock; /* CANME register needs protection */
 	u32 tx_head;
 	u32 tx_tail;
@@ -242,20 +249,18 @@ static inline int get_tx_head_prio(struct ti_hecc_priv *priv)
 
 static inline void hecc_write_lam(struct ti_hecc_priv *priv, u32 mbxno, u32 val)
 {
-	__raw_writel(val, priv->base + priv->hecc_ram_offset + mbxno * 4);
+	__raw_writel(val, priv->hecc_ram + mbxno * 4);
 }
 
 static inline void hecc_write_mbx(struct ti_hecc_priv *priv, u32 mbxno,
 	u32 reg, u32 val)
 {
-	__raw_writel(val, priv->base + priv->mbx_offset + mbxno * 0x10 +
-			reg);
+	__raw_writel(val, priv->mbx + mbxno * 0x10 + reg);
 }
 
 static inline u32 hecc_read_mbx(struct ti_hecc_priv *priv, u32 mbxno, u32 reg)
 {
-	return __raw_readl(priv->base + priv->mbx_offset + mbxno * 0x10 +
-			reg);
+	return __raw_readl(priv->mbx + mbxno * 0x10 + reg);
 }
 
 static inline void hecc_write(struct ti_hecc_priv *priv, u32 reg, u32 val)
@@ -872,56 +877,121 @@ static const struct net_device_ops ti_hecc_netdev_ops = {
 	.ndo_change_mtu		= can_change_mtu,
 };
 
+static const struct of_device_id ti_hecc_dt_ids[] = {
+	{
+		.compatible = "ti,am3517-hecc",
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, ti_hecc_dt_ids);
+
+static struct ti_hecc_platform_data *
+hecc_of_get_pdata(struct platform_device *pdev)
+{
+	struct ti_hecc_platform_data *pdata;
+	struct device_node *np = pdev->dev.of_node;
+
+	if (!IS_ENABLED(CONFIG_OF) || !np)
+		return dev_get_platdata(&pdev->dev);
+
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return ERR_PTR(-ENOMEM);
+
+	pdata->int_line = of_property_read_bool(np, "ti,use-hecc1int");
+
+	return pdata;
+}
+
 static int ti_hecc_probe(struct platform_device *pdev)
 {
 	struct net_device *ndev = (struct net_device *)0;
 	struct ti_hecc_priv *priv;
-	struct ti_hecc_platform_data *pdata;
-	struct resource *mem, *irq;
-	void __iomem *addr;
+	struct ti_hecc_platform_data *pdata = dev_get_platdata(&pdev->dev);
+	struct resource temp_res, *res, *irq;
 	int err = -ENODEV;
 
-	pdata = dev_get_platdata(&pdev->dev);
+	pdata = hecc_of_get_pdata(pdev);
 	if (!pdata) {
-		dev_err(&pdev->dev, "No platform data\n");
-		goto probe_exit;
+		dev_err(&pdev->dev, "Platform data missing\n");
+		return -EINVAL;
 	}
 
-	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!mem) {
-		dev_err(&pdev->dev, "No mem resources\n");
-		goto probe_exit;
+	ndev = alloc_candev(sizeof(struct ti_hecc_priv), HECC_MAX_TX_MBOX);
+	if (!ndev) {
+		dev_err(&pdev->dev, "alloc_candev failed\n");
+		return -ENOMEM;
+	}
+	priv = netdev_priv(ndev);
+
+	/* handle hecc memory */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hecc");
+	if (!res) {
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+		if (!res) {
+			dev_err(&pdev->dev, "can't get IORESOURCE_MEM hecc\n");
+			return -EINVAL;
+		}
+
+		temp_res.start = res->start;
+		temp_res.end = temp_res.start + HECC_BASE_SIZE - 1;
+		res = &temp_res;
+	}
+
+	priv->base = devm_ioremap_resource(&pdev->dev, res);
+	if (!priv->base) {
+		dev_err(&pdev->dev, "hecc ioremap failed\n");
+		return -ENOMEM;
+	}
+
+	/* handle hecc-ram memory */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hecc-ram");
+	if (!res) {
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+		if (!res) {
+			dev_err(&pdev->dev, "can't get IORESOURCE_MEM hecc-ram\n");
+			return -EINVAL;
+		}
+
+		temp_res.start = res->start + HECC_RAM_OFFSET;
+		temp_res.end = temp_res.start + HECC_RAM_SIZE - 1;
+		res = &temp_res;
+	}
+
+	priv->hecc_ram = devm_ioremap_resource(&pdev->dev, res);
+	if (!priv->hecc_ram) {
+		dev_err(&pdev->dev, "hecc-ram ioremap failed\n");
+		return -ENOMEM;
+	}
+
+	/* handle mbx memory */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mbx");
+	if (!res) {
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+		if (!res) {
+			dev_err(&pdev->dev, "can't get IORESOURCE_MEM mbx\n");
+			return -EINVAL;
+		}
+
+		temp_res.start = res->start + MBX_OFFSET;
+		temp_res.end = temp_res.start + MBX_SIZE - 1;
+		res = &temp_res;
 	}
+
+	priv->mbx = devm_ioremap_resource(&pdev->dev, res);
+	if (!priv->mbx) {
+		dev_err(&pdev->dev, "mbx ioremap failed\n");
+		return -ENOMEM;
+	}
+
 	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 	if (!irq) {
 		dev_err(&pdev->dev, "No irq resource\n");
 		goto probe_exit;
 	}
-	if (!request_mem_region(mem->start, resource_size(mem), pdev->name)) {
-		dev_err(&pdev->dev, "HECC region already claimed\n");
-		err = -EBUSY;
-		goto probe_exit;
-	}
-	addr = ioremap(mem->start, resource_size(mem));
-	if (!addr) {
-		dev_err(&pdev->dev, "ioremap failed\n");
-		err = -ENOMEM;
-		goto probe_exit_free_region;
-	}
 
-	ndev = alloc_candev(sizeof(struct ti_hecc_priv), HECC_MAX_TX_MBOX);
-	if (!ndev) {
-		dev_err(&pdev->dev, "alloc_candev failed\n");
-		err = -ENOMEM;
-		goto probe_exit_iounmap;
-	}
 
-	priv = netdev_priv(ndev);
 	priv->ndev = ndev;
-	priv->base = addr;
-	priv->scc_ram_offset = pdata->scc_ram_offset;
-	priv->hecc_ram_offset = pdata->hecc_ram_offset;
-	priv->mbx_offset = pdata->mbx_offset;
 	priv->int_line = pdata->int_line;
 	priv->transceiver_switch = pdata->transceiver_switch;
 
@@ -971,10 +1041,6 @@ static int ti_hecc_probe(struct platform_device *pdev)
 	clk_put(priv->clk);
 probe_exit_candev:
 	free_candev(ndev);
-probe_exit_iounmap:
-	iounmap(addr);
-probe_exit_free_region:
-	release_mem_region(mem->start, resource_size(mem));
 probe_exit:
 	return err;
 }
@@ -1045,6 +1111,7 @@ static int ti_hecc_resume(struct platform_device *pdev)
 static struct platform_driver ti_hecc_driver = {
 	.driver = {
 		.name    = DRV_NAME,
+		.of_match_table = ti_hecc_dt_ids,
 	},
 	.probe = ti_hecc_probe,
 	.remove = ti_hecc_remove,
-- 
2.1.4

Re: [PATCH v3 0/3] Adding DT support for TI HECC module

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 1135 bytes --]

On 02/15/2017 03:48 PM, yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org wrote:
> From: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> 
> This is an attempt to revive DT support for TI HECC that was started in 2015 [1].
> 
> Changes v2 -> v3:
>   - rename compatible property to "ti,am3517-hecc" (though there is a stipped
>     device named 3505, EMAC driver already uses am3517-emac name, so keep this
>     property consistent)
>   - use reg-names to specify different HECC I/O mapping (suggested by Tony Lindgren)
>   - provide fallback offsets and sizes for board files

Are there any board files using te_hecc intree? I don't see any on the
first glance. What about making the driver DT only?

>   - convert optional property ti,int_line to ti,use-hecc1int and add proper
>     description

regards,
Marc

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 0/3] Adding DT support for TI HECC module

[Yegor Yefremov]

On Fri, Feb 17, 2017 at 9:46 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 02/15/2017 03:48 PM, yegorslists@googlemail.com wrote:
>> From: Yegor Yefremov <yegorslists@googlemail.com>
>>
>> This is an attempt to revive DT support for TI HECC that was started in 2015 [1].
>>
>> Changes v2 -> v3:
>>   - rename compatible property to "ti,am3517-hecc" (though there is a stipped
>>     device named 3505, EMAC driver already uses am3517-emac name, so keep this
>>     property consistent)
>>   - use reg-names to specify different HECC I/O mapping (suggested by Tony Lindgren)
>>   - provide fallback offsets and sizes for board files
>
> Are there any board files using te_hecc intree? I don't see any on the
> first glance. What about making the driver DT only?

Good idea. I aslo wanted to ask this. So this means we could
completely get rid of include/linux/can/platform/ti_hecc.h?

Yegor

>>   - convert optional property ti,int_line to ti,use-hecc1int and add proper
>>     description
>
> regards,
> Marc
>
> --
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
>

Re: [PATCH v3 0/3] Adding DT support for TI HECC module

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 1385 bytes --]

On 02/17/2017 09:50 AM, Yegor Yefremov wrote:
> On Fri, Feb 17, 2017 at 9:46 AM, Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>> On 02/15/2017 03:48 PM, yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org wrote:
>>> From: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>>
>>> This is an attempt to revive DT support for TI HECC that was started in 2015 [1].
>>>
>>> Changes v2 -> v3:
>>>   - rename compatible property to "ti,am3517-hecc" (though there is a stipped
>>>     device named 3505, EMAC driver already uses am3517-emac name, so keep this
>>>     property consistent)
>>>   - use reg-names to specify different HECC I/O mapping (suggested by Tony Lindgren)
>>>   - provide fallback offsets and sizes for board files
>>
>> Are there any board files using te_hecc intree? I don't see any on the
>> first glance. What about making the driver DT only?
> 
> Good idea. I aslo wanted to ask this. So this means we could
> completely get rid of include/linux/can/platform/ti_hecc.h?

If there isn't any in-tree user, thes yes.

Marc

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 0/3] Adding DT support for TI HECC module

[Yegor Yefremov]

On Fri, Feb 17, 2017 at 9:51 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 02/17/2017 09:50 AM, Yegor Yefremov wrote:
>> On Fri, Feb 17, 2017 at 9:46 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>>> On 02/15/2017 03:48 PM, yegorslists@googlemail.com wrote:
>>>> From: Yegor Yefremov <yegorslists@googlemail.com>
>>>>
>>>> This is an attempt to revive DT support for TI HECC that was started in 2015 [1].
>>>>
>>>> Changes v2 -> v3:
>>>>   - rename compatible property to "ti,am3517-hecc" (though there is a stipped
>>>>     device named 3505, EMAC driver already uses am3517-emac name, so keep this
>>>>     property consistent)
>>>>   - use reg-names to specify different HECC I/O mapping (suggested by Tony Lindgren)
>>>>   - provide fallback offsets and sizes for board files
>>>
>>> Are there any board files using te_hecc intree? I don't see any on the
>>> first glance. What about making the driver DT only?
>>
>> Good idea. I aslo wanted to ask this. So this means we could
>> completely get rid of include/linux/can/platform/ti_hecc.h?
>
> If there isn't any in-tree user, thes yes.

Btw. what should we do about "@transceiver_switch: platform specific
callback fn for transceiver control"? Model it via something like
this:

enable-gpios = <&gpio6 15 GPIO_ACTIVE_HIGH>; /* gpio 175 */

Yegor

Re: [PATCH v3 0/3] Adding DT support for TI HECC module

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 1808 bytes --]

On 02/17/2017 10:23 AM, Yegor Yefremov wrote:
> On Fri, Feb 17, 2017 at 9:51 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>> On 02/17/2017 09:50 AM, Yegor Yefremov wrote:
>>> On Fri, Feb 17, 2017 at 9:46 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>>>> On 02/15/2017 03:48 PM, yegorslists@googlemail.com wrote:
>>>>> From: Yegor Yefremov <yegorslists@googlemail.com>
>>>>>
>>>>> This is an attempt to revive DT support for TI HECC that was started in 2015 [1].
>>>>>
>>>>> Changes v2 -> v3:
>>>>>   - rename compatible property to "ti,am3517-hecc" (though there is a stipped
>>>>>     device named 3505, EMAC driver already uses am3517-emac name, so keep this
>>>>>     property consistent)
>>>>>   - use reg-names to specify different HECC I/O mapping (suggested by Tony Lindgren)
>>>>>   - provide fallback offsets and sizes for board files
>>>>
>>>> Are there any board files using te_hecc intree? I don't see any on the
>>>> first glance. What about making the driver DT only?
>>>
>>> Good idea. I aslo wanted to ask this. So this means we could
>>> completely get rid of include/linux/can/platform/ti_hecc.h?
>>
>> If there isn't any in-tree user, thes yes.
> 
> Btw. what should we do about "@transceiver_switch: platform specific
> callback fn for transceiver control"? Model it via something like
> this:
> 
> enable-gpios = <&gpio6 15 GPIO_ACTIVE_HIGH>; /* gpio 175 */

Make it a regulator as in the flexcan:

> 	reg_xceiver = devm_regulator_get(&pdev->dev, "xceiver");

Marc

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]