[PATCH 0/3] can: Add D_CAN raminit support to am335x-evm

[PATCH 0/3] can: Add D_CAN raminit support to am335x-evm

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

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

-- 
1.7.9.5

[PATCH 1/3] can: c_can: Add d_can raminit support

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

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 <anilkumar@ti.com>
---
 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(-)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index e5180df..c15830c 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -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);
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index e5ed41d..419de5c 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -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);
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index ee141613..2e61d69 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -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]);
 }
 
+static void c_can_hw_raminit(const struct c_can_priv *priv, bool enable)
+{
+	u32 val;
+
+	if (!priv->raminit_ctrlreg || (priv->instance < 0))
+		return;
+
+	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;
 
@@ -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);
+		if (!priv->raminit_ctrlreg)
+			dev_warn(&pdev->dev, "failed to obtain control memory\n");
+
+		if (pdev->dev.of_node)
+			pdev->id = of_alias_get_id(pdev->dev.of_node, "d_can");
+
+		priv->instance = pdev->id;
+		priv->ram_init = c_can_hw_raminit;
 		break;
 	default:
 		ret = -EINVAL;
-- 
1.7.9.5

Re: [PATCH 1/3] can: c_can: Add d_can raminit support

[Marc Kleine-Budde]

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

On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> 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 <anilkumar-l0cyMroinI0@public.gmane.org>

Some nitpicks inline.

Marc

> ---
>  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(-)
> 
> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> index e5180df..c15830c 100644
> --- a/drivers/net/can/c_can/c_can.c
> +++ b/drivers/net/can/c_can/c_can.c
> @@ -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);
> diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
> index e5ed41d..419de5c 100644
> --- a/drivers/net/can/c_can/c_can.h
> +++ b/drivers/net/can/c_can/c_can.h
> @@ -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);
> diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
> index ee141613..2e61d69 100644
> --- a/drivers/net/can/c_can/c_can_platform.c
> +++ b/drivers/net/can/c_can/c_can_platform.c
> @@ -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]);
>  }
>  
> +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?

> +
> +	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;
>  
> @@ -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

> +		if (!priv->raminit_ctrlreg)
> +			dev_warn(&pdev->dev, "failed to obtain control memory\n");
> +
> +		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;

> +		priv->ram_init = c_can_hw_raminit;
>  		break;
>  	default:
>  		ret = -EINVAL;
> 

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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH 1/3] can: c_can: Add d_can raminit support

[AnilKumar, Chimata]

On Tue, Nov 20, 2012 at 16:20:41, Marc Kleine-Budde wrote:
> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> > 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 <anilkumar@ti.com>
> 
> Some nitpicks inline.

Thanks for the review.
 
> 
> > ---
> >  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(-)
> > 
> > diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> > index e5180df..c15830c 100644
> > --- a/drivers/net/can/c_can/c_can.c
> > +++ b/drivers/net/can/c_can/c_can.c
> > @@ -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);
> > diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
> > index e5ed41d..419de5c 100644
> > --- a/drivers/net/can/c_can/c_can.h
> > +++ b/drivers/net/can/c_can/c_can.h
> > @@ -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);
> > diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
> > index ee141613..2e61d69 100644
> > --- a/drivers/net/can/c_can/c_can_platform.c
> > +++ b/drivers/net/can/c_can/c_can_platform.c
> > @@ -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]);
> >  }
> >  
> > +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?

Sure, I will change

> 
> > +
> > +	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;
> >  
> > @@ -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

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.

> 
> > +		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");

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

I will change accordingly.

Thanks
AnilKumar

Re: [PATCH 1/3] can: c_can: Add d_can raminit support

[Marc Kleine-Budde]

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

On 11/20/2012 02:05 PM, AnilKumar, Chimata wrote:
[...]

>>>  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;
>>>  
>>> @@ -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
> 
> 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.
> 
>>
>>> +		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");

That's more descriptive, good.

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: 261 bytes --]

[PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases

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

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 <anilkumar-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/am33xx.dtsi |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..c92c35f 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -21,6 +21,8 @@
 		serial3 = &uart4;
 		serial4 = &uart5;
 		serial5 = &uart6;
+		d_can0 = &dcan0;
+		d_can1 = &dcan1;
 	};
 
 	cpus {
-- 
1.7.9.5

Re: [PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases

[Marc Kleine-Budde]

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

On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> 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 <anilkumar-l0cyMroinI0@public.gmane.org>

Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

-- 
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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases

[AnilKumar, Chimata]

On Tue, Nov 20, 2012 at 16:21:42, Marc Kleine-Budde wrote:
> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> > 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 <anilkumar@ti.com>
> 
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>

Hi Tony/Benoit,

Could you please pull this in?

Thanks
AnilKumar

RE: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm

[AnilKumar, Chimata]

On Wed, Nov 14, 2012 at 23:38:22, AnilKumar, Chimata wrote:
> 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.

Hi Mark,

Gentle remainder to this series

Thanks
AnilKumar
 
> 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(-)
> 
> -- 
> 1.7.9.5
> 
> 

[PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node

[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 <anilkumar@ti.com>
---
 arch/arm/boot/dts/am33xx.dtsi |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c92c35f..ea011d6 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -227,7 +227,8 @@
 		dcan0: d_can@481cc000 {
 			compatible = "bosch,d_can";
 			ti,hwmods = "d_can0";
-			reg = <0x481cc000 0x2000>;
+			reg = <0x481cc000 0x2000
+				0x44e10644 0x4>;
 			interrupts = <52>;
 			status = "disabled";
 		};
@@ -235,7 +236,8 @@
 		dcan1: d_can@481d0000 {
 			compatible = "bosch,d_can";
 			ti,hwmods = "d_can1";
-			reg = <0x481d0000 0x2000>;
+			reg = <0x481d0000 0x2000
+				0x44e10644 0x4>;
 			interrupts = <55>;
 			status = "disabled";
 		};
-- 
1.7.9.5

Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node

[Marc Kleine-Budde]

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

On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> 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 <anilkumar@ti.com>

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

-- 
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: 261 bytes --]

RE: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node

[AnilKumar, Chimata]

On Tue, Nov 20, 2012 at 15:43:04, Marc Kleine-Budde wrote:
> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> > 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 <anilkumar@ti.com>
> 
> 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.

Tony/Benoit,

Could you please take dt patches in this series to linux-omap?

Thanks
AnilKumar

Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node

[Marc Kleine-Budde]

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

On 11/20/2012 11:23 AM, AnilKumar, Chimata wrote:
> On Tue, Nov 20, 2012 at 15:43:04, Marc Kleine-Budde wrote:
>> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
>>> 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 <anilkumar-l0cyMroinI0@public.gmane.org>
>>
>> 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.

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

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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

RE: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node

[AnilKumar, Chimata]

On Tue, Nov 20, 2012 at 15:56:32, Marc Kleine-Budde wrote:
> On 11/20/2012 11:23 AM, AnilKumar, Chimata wrote:
> > On Tue, Nov 20, 2012 at 15:43:04, Marc Kleine-Budde wrote:
> >> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> >>> 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 <anilkumar@ti.com>
> >>
> >> 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.
> 
> Will do - I'm currently looking at the driver.
> 

Hi Marc,

Please ACK this patch as well.

Thanks
AnilKumar

Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node

[Marc Kleine-Budde]

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

On 11/21/2012 06:45 AM, AnilKumar, Chimata wrote:
> On Tue, Nov 20, 2012 at 15:56:32, Marc Kleine-Budde wrote:
>> On 11/20/2012 11:23 AM, AnilKumar, Chimata wrote:
>>> On Tue, Nov 20, 2012 at 15:43:04, Marc Kleine-Budde wrote:
>>>> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
>>>>> 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 <anilkumar-l0cyMroinI0@public.gmane.org>
>>>>
>>>> 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.
>>
>> Will do - I'm currently looking at the driver.
>>
> 
> Hi Marc,
> 
> Please ACK this patch as well.

done :)

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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node

[Marc Kleine-Budde]

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

On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> 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 <anilkumar@ti.com>

Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>

-- 
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: 261 bytes --]

RE: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node

[AnilKumar, Chimata]

On Wed, Nov 21, 2012 at 13:50:26, Marc Kleine-Budde wrote:
> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> > 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 <anilkumar@ti.com>
> 
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
> 

Hi Tony/Benoit,

Could you please pull this in?

Thanks
AnilKumar

Re: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm

[Benoit Cousson]

Hi Anil,

On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> 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

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

Regards,
Benoit

RE: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm

[AnilKumar, Chimata]

On Wed, Jan 09, 2013 at 17:46:37, Cousson, Benoit wrote:
> Hi Anil,
> 
> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
> > 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
> 
> I've just applied both DTS patches with Acked-by from Marc in my
> for_3.9/dts branch.
> 
Hi Benoit,

Thanks much

Thanks
AnilKumar