can: Add D_CAN raminit support to am335x-evm

Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM, which holds all the message objects during transmission or receiving of data. This initialization/de-initialization should be done in synchronous with D_CAN clock.

In case of AM335X-EVM (active user of D_CAN driver) message RAM is controlled through control module register for both instances. So control module register details is required to initialization or de-initialization of message RAM according to instance number.

Control module memory resource is obtained from D_CAN dt node and instance number obtained from device tree aliases node.

Signed-off-by AnilKumar Ch <[email protected]>

---
 drivers/net/can/c_can/c_can.c          |   12 +++++++++++
 drivers/net/can/c_can/c_can.h          |    3 +++
 drivers/net/can/c_can/c_can_platform.c |   34 +++++++++++++++++++++++++++++++-
 3 files changed, 48 insertions(+), 1 deletion(-)

drivers/net/can/c_can/c_can.c +12 -0

index e5180df..c15830c 100644
@@ -233,6 +233,12 @@ static inline void c_can_pm_runtime_put_sync(const struct c_can_priv *priv)
 		pm_runtime_put_sync(priv->device);
 }
 
+static inline void c_can_reset_ram(const struct c_can_priv *priv, bool enable)
+{
+	if (priv->ram_init)
+		priv->ram_init(priv, enable);
+}
+
 static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
 {
 	return (priv->tx_next & C_CAN_NEXT_MSG_OBJ_MASK) +

@@ -1090,6 +1096,7 @@ static int c_can_open(struct net_device *dev)
 	struct c_can_priv *priv = netdev_priv(dev);
 
 	c_can_pm_runtime_get_sync(priv);
+	c_can_reset_ram(priv, true);
 
 	/* open the can device */
 	err = open_candev(dev);

@@ -1118,6 +1125,7 @@ static int c_can_open(struct net_device *dev)
 exit_irq_fail:
 	close_candev(dev);
 exit_open_fail:
+	c_can_reset_ram(priv, false);
 	c_can_pm_runtime_put_sync(priv);
 	return err;
 }

@@ -1131,6 +1139,8 @@ static int c_can_close(struct net_device *dev)
 	c_can_stop(dev);
 	free_irq(dev->irq, dev);
 	close_candev(dev);
+
+	c_can_reset_ram(priv, false);
 	c_can_pm_runtime_put_sync(priv);
 
 	return 0;

@@ -1188,6 +1198,7 @@ int c_can_power_down(struct net_device *dev)
 
 	c_can_stop(dev);
 
+	c_can_reset_ram(priv, false);
 	c_can_pm_runtime_put_sync(priv);
 
 	return 0;

@@ -1206,6 +1217,7 @@ int c_can_power_up(struct net_device *dev)
 	WARN_ON(priv->type != BOSCH_D_CAN);
 
 	c_can_pm_runtime_get_sync(priv);
+	c_can_reset_ram(priv, true);
 
 	/* Clear PDR and INIT bits */
 	val = priv->read_reg(priv, C_CAN_CTRL_EX_REG);

drivers/net/can/c_can/c_can.h +3 -0

index e5ed41d..419de5c 100644
@@ -169,6 +169,9 @@ struct c_can_priv {
 	void *priv;		/* for board-specific data */
 	u16 irqstatus;
 	enum c_can_dev_id type;
+	u32 __iomem *raminit_ctrlreg;
+	unsigned int instance;
+	void (*ram_init) (const struct c_can_priv *priv, bool enable);
 };
 
 struct net_device *alloc_c_can_dev(void);

drivers/net/can/c_can/c_can_platform.c +2 -0

index ee141613..2e61d69 100644
@@ -38,6 +38,8 @@
 
 #include "c_can.h"
 
+#define CAN_RAMINIT_START_MASK(i)	(1 << (i))
+
 /*
  * 16-bit c_can registers can be arranged differently in the memory
  * architecture of different implementations. For example: 16-bit

drivers/net/can/c_can/c_can_platform.c +13 -1

+
+	val = readl(priv->raminit_ctrlreg);
+	if (enable) {
+		val &= ~CAN_RAMINIT_START_MASK(priv->instance);
+		val |= CAN_RAMINIT_START_MASK(priv->instance);
+		writel(val, priv->raminit_ctrlreg);
+	} else {
+		val &= ~CAN_RAMINIT_START_MASK(priv->instance);
+		writel(val, priv->raminit_ctrlreg);
+	}
+}
+
 static struct platform_device_id c_can_id_table[] = {
 	[BOSCH_C_CAN_PLATFORM] = {
 		.name = KBUILD_MODNAME,

@@ -99,7 +119,7 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
 	const struct of_device_id *match;
 	const struct platform_device_id *id;
 	struct pinctrl *pinctrl;
-	struct resource *mem;
+	struct resource *mem, *res;
 	int irq;
 	struct clk *clk;
 

Quoted 10 lines · AnilKumar Ch

Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM, which holds all the message objects during transmission or receiving of data. This initialization/de-initialization should be done in synchronous with D_CAN clock.

In case of AM335X-EVM (active user of D_CAN driver) message RAM is controlled through control module register for both instances. So control module register details is required to initialization or de-initialization of message RAM according to instance number.

Quoted 4 lines

Control module memory resource is obtained from D_CAN dt node and instance number obtained from device tree aliases node.

Signed-off-by AnilKumar Ch <[email protected]>

Some nitpicks inline.

Quoted 96 lines

---
 drivers/net/can/c_can/c_can.c          |   12 +++++++++++
 drivers/net/can/c_can/c_can.h          |    3 +++
 drivers/net/can/c_can/c_can_platform.c |   34 +++++++++++++++++++++++++++++++-
 3 files changed, 48 insertions(+), 1 deletion(-)

drivers/net/can/c_can/c_can.c +12 -0

index e5180df..c15830c 100644
@@ -233,6 +233,12 @@ static inline void c_can_pm_runtime_put_sync(const struct c_can_priv *priv)
 		pm_runtime_put_sync(priv->device);
 }
 
+static inline void c_can_reset_ram(const struct c_can_priv *priv, bool enable)
+{
+	if (priv->ram_init)
+		priv->ram_init(priv, enable);
+}
+
 static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
 {
 	return (priv->tx_next & C_CAN_NEXT_MSG_OBJ_MASK) +

@@ -1090,6 +1096,7 @@ static int c_can_open(struct net_device *dev)
 	struct c_can_priv *priv = netdev_priv(dev);
 
 	c_can_pm_runtime_get_sync(priv);
+	c_can_reset_ram(priv, true);
 
 	/* open the can device */
 	err = open_candev(dev);

@@ -1118,6 +1125,7 @@ static int c_can_open(struct net_device *dev)
 exit_irq_fail:
 	close_candev(dev);
 exit_open_fail:
+	c_can_reset_ram(priv, false);
 	c_can_pm_runtime_put_sync(priv);
 	return err;
 }

@@ -1131,6 +1139,8 @@ static int c_can_close(struct net_device *dev)
 	c_can_stop(dev);
 	free_irq(dev->irq, dev);
 	close_candev(dev);
+
+	c_can_reset_ram(priv, false);
 	c_can_pm_runtime_put_sync(priv);
 
 	return 0;

@@ -1188,6 +1198,7 @@ int c_can_power_down(struct net_device *dev)
 
 	c_can_stop(dev);
 
+	c_can_reset_ram(priv, false);
 	c_can_pm_runtime_put_sync(priv);
 
 	return 0;

@@ -1206,6 +1217,7 @@ int c_can_power_up(struct net_device *dev)
 	WARN_ON(priv->type != BOSCH_D_CAN);
 
 	c_can_pm_runtime_get_sync(priv);
+	c_can_reset_ram(priv, true);
 
 	/* Clear PDR and INIT bits */
 	val = priv->read_reg(priv, C_CAN_CTRL_EX_REG);

drivers/net/can/c_can/c_can.h +3 -0

index e5ed41d..419de5c 100644
@@ -169,6 +169,9 @@ struct c_can_priv {
 	void *priv;		/* for board-specific data */
 	u16 irqstatus;
 	enum c_can_dev_id type;
+	u32 __iomem *raminit_ctrlreg;
+	unsigned int instance;
+	void (*ram_init) (const struct c_can_priv *priv, bool enable);
 };
 
 struct net_device *alloc_c_can_dev(void);

drivers/net/can/c_can/c_can_platform.c +2 -0

index ee141613..2e61d69 100644
@@ -38,6 +38,8 @@
 
 #include "c_can.h"
 
+#define CAN_RAMINIT_START_MASK(i)	(1 << (i))
+
 /*
  * 16-bit c_can registers can be arranged differently in the memory
  * architecture of different implementations. For example: 16-bit

@@ -68,6 +70,24 @@ static void c_can_plat_write_reg_aligned_to_32bit(struct c_can_priv *priv,
 	writew(val, priv->base + 2 * priv->regs[index]);
 }
 

drivers/net/can/c_can/c_can_platform.c static void c_can_plat_write_reg_aligned_to_32bit(struct c_can_priv *priv, · line 78

Quoted 6 lines

drivers/net/can/c_can/c_can_platform.c +6 -0

+static void c_can_hw_raminit(const struct c_can_priv *priv, bool enable)
+{
+	u32 val;
+
+	if (!priv->raminit_ctrlreg || (priv->instance < 0))
+		return;

Can you move this sanity check to the probe function and only assign priv->ram_init if the above is true?

Quoted 26 lines

drivers/net/can/c_can/c_can_platform.c +13 -1

+
+	val = readl(priv->raminit_ctrlreg);
+	if (enable) {
+		val &= ~CAN_RAMINIT_START_MASK(priv->instance);
+		val |= CAN_RAMINIT_START_MASK(priv->instance);
+		writel(val, priv->raminit_ctrlreg);
+	} else {
+		val &= ~CAN_RAMINIT_START_MASK(priv->instance);
+		writel(val, priv->raminit_ctrlreg);
+	}
+}
+
 static struct platform_device_id c_can_id_table[] = {
 	[BOSCH_C_CAN_PLATFORM] = {
 		.name = KBUILD_MODNAME,

@@ -99,7 +119,7 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
 	const struct of_device_id *match;
 	const struct platform_device_id *id;
 	struct pinctrl *pinctrl;
-	struct resource *mem;
+	struct resource *mem, *res;
 	int irq;
 	struct clk *clk;
 

drivers/net/can/c_can/c_can_platform.c static int __devinit c_can_plat_probe(struct platform_device *pdev) · line 204

Quoted 7 lines

drivers/net/can/c_can/c_can_platform.c +4 -0

@@ -178,6 +198,18 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
 		priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
 		priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
 		priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
+
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+		priv->raminit_ctrlreg =
+				devm_request_and_ioremap(&pdev->dev, res);

What happens if there isn't a second IORESOURCE_MEM region? devm_request will print an error in this case and any other error, too [1]. Do we need streamlining here?

[1] http://lxr.free-electrons.com/source/drivers/base/platform.c#L59

drivers/net/can/c_can/c_can_platform.c static int __devinit c_can_plat_probe(struct platform_device *pdev) · line 206

Quoted 3 lines

drivers/net/can/c_can/c_can_platform.c +2 -0

+		if (!priv->raminit_ctrlreg)
+			dev_warn(&pdev->dev, "failed to obtain control memory\n");

drivers/net/can/c_can/c_can_platform.c static int __devinit c_can_plat_probe(struct platform_device *pdev) · line 211

Quoted 5 lines

drivers/net/can/c_can/c_can_platform.c +5 -0

+
+		if (pdev->dev.of_node)
+			pdev->id = of_alias_get_id(pdev->dev.of_node, "d_can");
+
+		priv->instance = pdev->id;

Please do not modify the pdev, better you use something like this:

    pdev->id < 0 ? of_alias_get_id(pdev->dev.of_node, "d_can") :
        pdev->id;

Quoted 25 lines

Quoted 13 lines

static struct platform_device_id c_can_id_table[] = {

drivers/net/can/c_can/c_can_platform.c +1 -1

 	[BOSCH_C_CAN_PLATFORM] = {
 		.name = KBUILD_MODNAME,

@@ -99,7 +119,7 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
 	const struct of_device_id *match;
 	const struct platform_device_id *id;
 	struct pinctrl *pinctrl;
-	struct resource *mem;
+	struct resource *mem, *res;
 	int irq;
 	struct clk *clk;
 

drivers/net/can/c_can/c_can_platform.c static int __devinit c_can_plat_probe(struct platform_device *pdev) · line 204

Quoted 7 lines

drivers/net/can/c_can/c_can_platform.c +4 -0

@@ -178,6 +198,18 @@ static int __devinit c_can_plat_probe(struct platform_device *pdev)
 		priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
 		priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
 		priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
+
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+		priv->raminit_ctrlreg =
+				devm_request_and_ioremap(&pdev->dev, res);

What happens if there isn't a second IORESOURCE_MEM region? devm_request will print an error in this case and any other error, too [1]. Do we need streamlining here?

Quoted 1 line

[1] http://lxr.free-electrons.com/source/drivers/base/platform.c#L59

I did not get what the point is.

In most of the cases above two API's returns NULL. Even res is NULL nothing to worry, first condition in devm_request_and_ioremap() is NULL pointer check of res. If "res" is NULL then devm_xx will return NULL which result into printing of below warning.

Quoted 1 line

Quoted 2 lines

drivers/net/can/c_can/c_can_platform.c static int __devinit c_can_plat_probe(struct platform_device *pdev) · line 206

Quoted 2 lines

drivers/net/can/c_can/c_can_platform.c +2 -0

+		if (!priv->raminit_ctrlreg)
+			dev_warn(&pdev->dev, "failed to obtain control memory\n");

I will change this warning to info

if (!priv->raminit_ctrlreg)

	dev_info(&pdev->dev, "control memory is not used for raminit\n");

Add d_can instances to aliases node to get the D_CAN instance number from the driver. To initialize D_CAN message RAM, corresponding instance number is required.

To initialize instance 0 message RAM then 0x1 should be written and for instance 1 message RAM, 0x2 should be written to control module register.

With device-tree framework ip instance number is "-1" by default for all instances. To get device id/instance number then modules should be added to DT "aliases" node. of_alias_get_id() gives the device id number based on number of alias nodes present in "aliases node".

Signed-off-by AnilKumar Ch <[email protected]>

Quoted 7 lines · AnilKumar Ch

Add d_can instances to aliases node to get the D_CAN instance number from the driver. To initialize D_CAN message RAM, corresponding instance number is required.

To initialize instance 0 message RAM then 0x1 should be written and for instance 1 message RAM, 0x2 should be written to control module register.

Quoted 6 lines

With device-tree framework ip instance number is "-1" by default for all instances. To get device id/instance number then modules should be added to DT "aliases" node. of_alias_get_id() gives the device id number based on number of alias nodes present in "aliases node".

Signed-off-by AnilKumar Ch <[email protected]>

Acked-by Marc Kleine-Budde <[email protected]>

Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register.

Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver.

Signed-off-by AnilKumar Ch <[email protected]>

Quoted 10 lines · AnilKumar Ch

Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register.

Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver.

Quoted 1 line

Signed-off-by AnilKumar Ch <[email protected]>

This does not apply to net-next/master:

Applying: ARM: dts: AM33XX: Add memory resource to d_can node
error: patch failed: arch/arm/boot/dts/am33xx.dtsi:227
error: arch/arm/boot/dts/am33xx.dtsi: patch does not apply Patch failed at 0003 ARM: dts: AM33XX: Add memory resource to d_can node

Quoted 11 lines · Marc Kleine-Budde

Quoted 10 lines · AnilKumar Ch

Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register.

Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver.

Quoted 9 lines

Quoted 1 line

Signed-off-by AnilKumar Ch <[email protected]>

This does not apply to net-next/master:

Applying: ARM: dts: AM33XX: Add memory resource to d_can node
error: patch failed: arch/arm/boot/dts/am33xx.dtsi:227
error: arch/arm/boot/dts/am33xx.dtsi: patch does not apply Patch failed at 0003 ARM: dts: AM33XX: Add memory resource to d_can node

Marc,

Sorry about this DT changes are present in linux-omap.

Could you please take the driver changes only and ACK on remaining will help.

Quoted 22 lines · Chimata

Quoted 20 lines · Marc Kleine-Budde

Quoted 11 lines · AnilKumar Ch

Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register.

Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver.

Signed-off-by AnilKumar Ch <[email protected]>

This does not apply to net-next/master:

Applying: ARM: dts: AM33XX: Add memory resource to d_can node
error: patch failed: arch/arm/boot/dts/am33xx.dtsi:227
error: arch/arm/boot/dts/am33xx.dtsi: patch does not apply Patch failed at 0003 ARM: dts: AM33XX: Add memory resource to d_can node

Quoted 6 lines

Marc,

Sorry about this DT changes are present in linux-omap.

Could you please take the driver changes only and ACK on remaining will help.

Will do - I'm currently looking at the driver.

Quoted 30 lines · Marc Kleine-Budde

Quoted 28 lines · Chimata

Quoted 11 lines · Marc Kleine-Budde

Quoted 10 lines · AnilKumar Ch

Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register.

Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver.

Quoted 9 lines

Quoted 1 line

Signed-off-by AnilKumar Ch <[email protected]>

This does not apply to net-next/master:

Applying: ARM: dts: AM33XX: Add memory resource to d_can node
error: patch failed: arch/arm/boot/dts/am33xx.dtsi:227
error: arch/arm/boot/dts/am33xx.dtsi: patch does not apply Patch failed at 0003 ARM: dts: AM33XX: Add memory resource to d_can node

Marc,

Sorry about this DT changes are present in linux-omap.

Could you please take the driver changes only and ACK on remaining will help.

Quoted 2 lines

Will do - I'm currently looking at the driver.

Hi Marc,

Please ACK this patch as well.

Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register.

Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver.

Signed-off-by AnilKumar Ch <[email protected]>

Quoted 5 lines · AnilKumar Ch

Add a new address space/memory resource to d_can device tree node. D_CAN RAM initialization is achieved through RAMINIT register which is part of AM33XX control module address space. D_CAN RAM init or de-init should be done by writing instance corresponding value to control module register.

Quoted 6 lines

Till we have a separate control module driver to write to control module, d_can driver will handle the register writes to control module by itself. So a new address space to represent this control module register is added to d_can driver.

Signed-off-by AnilKumar Ch <[email protected]>

Acked-by Marc Kleine-Budde <[email protected]>

This patch series adds d_can raminit support to c_can/d_can driver, which is required to init/de-init D_CAN message RAM (holds message objects). Added corresponding DT changes to get resource of RAMINIT register and device instance.

These patches were tested on AM335x-EVM along with pinctrl data addition patch, which is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1.

AnilKumar Ch (3):
can: c_can: Add d_can raminit support
ARM: dts: AM33XX: Add d_can instances to aliases
ARM: dts: AM33XX: Add memory resource to d_can node

 arch/arm/boot/dts/am33xx.dtsi          |    8 ++++++--
 drivers/net/can/c_can/c_can.c          |   12 +++++++++++
 drivers/net/can/c_can/c_can.h          |    3 +++
 drivers/net/can/c_can/c_can_platform.c |   34 +++++++++++++++++++++++++++++++-
 4 files changed, 54 insertions(+), 3 deletions(-)

Signature · 1 line

1.7.9.5

This patch series adds d_can raminit support to c_can/d_can driver, which is required to init/de-init D_CAN message RAM (holds message objects). Added corresponding DT changes to get resource of RAMINIT register and device instance.

These patches were tested on AM335x-EVM along with pinctrl data addition patch, which is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1.

AnilKumar Ch (3):
can: c_can: Add d_can raminit support
ARM: dts: AM33XX: Add d_can instances to aliases
ARM: dts: AM33XX: Add memory resource to d_can node

Hi Anil,

Quoted 9 lines · AnilKumar Ch

This patch series adds d_can raminit support to c_can/d_can driver, which is required to init/de-init D_CAN message RAM (holds message objects). Added corresponding DT changes to get resource of RAMINIT register and device instance.

These patches were tested on AM335x-EVM along with pinctrl data addition patch, which is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1.

Quoted 4 lines

AnilKumar Ch (3):
can: c_can: Add d_can raminit support
ARM: dts: AM33XX: Add d_can instances to aliases
ARM: dts: AM33XX: Add memory resource to d_can node

I've just applied both DTS patches with Acked-by from Marc in my for_3.9/dts branch.