* [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm
@ 2012-11-14 18:08 AnilKumar Ch
2012-11-14 18:08 ` [PATCH 1/3] can: c_can: Add d_can raminit support AnilKumar Ch
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: AnilKumar Ch @ 2012-11-14 18:08 UTC (permalink / raw)
To: wg, mkl
Cc: swarren, linux-can, tony, b-cousson, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss, 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/3] can: c_can: Add d_can raminit support
2012-11-14 18:08 [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm AnilKumar Ch
@ 2012-11-14 18:08 ` AnilKumar Ch
[not found] ` <1352916505-12343-2-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
2012-11-14 18:08 ` [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node AnilKumar Ch
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: AnilKumar Ch @ 2012-11-14 18:08 UTC (permalink / raw)
To: wg, mkl
Cc: swarren, linux-can, tony, b-cousson, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss, 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
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases
[not found] ` <1352916505-12343-1-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
@ 2012-11-14 18:08 ` AnilKumar Ch
[not found] ` <1352916505-12343-3-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
2012-11-20 5:00 ` [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm AnilKumar, Chimata
1 sibling, 1 reply; 19+ messages in thread
From: AnilKumar Ch @ 2012-11-14 18:08 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
2012-11-14 18:08 [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm AnilKumar Ch
2012-11-14 18:08 ` [PATCH 1/3] can: c_can: Add d_can raminit support AnilKumar Ch
@ 2012-11-14 18:08 ` AnilKumar Ch
2012-11-20 10:13 ` Marc Kleine-Budde
2012-11-21 8:20 ` Marc Kleine-Budde
[not found] ` <1352916505-12343-1-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
2013-01-09 12:16 ` Benoit Cousson
3 siblings, 2 replies; 19+ messages in thread
From: AnilKumar Ch @ 2012-11-14 18:08 UTC (permalink / raw)
To: wg, mkl
Cc: swarren, linux-can, tony, b-cousson, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss, 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
^ permalink raw reply related [flat|nested] 19+ messages in thread
* RE: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm
[not found] ` <1352916505-12343-1-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
2012-11-14 18:08 ` [PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases AnilKumar Ch
@ 2012-11-20 5:00 ` AnilKumar, Chimata
1 sibling, 0 replies; 19+ messages in thread
From: AnilKumar, Chimata @ 2012-11-20 5:00 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
2012-11-14 18:08 ` [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node AnilKumar Ch
@ 2012-11-20 10:13 ` Marc Kleine-Budde
2012-11-20 10:23 ` AnilKumar, Chimata
2012-11-21 8:20 ` Marc Kleine-Budde
1 sibling, 1 reply; 19+ messages in thread
From: Marc Kleine-Budde @ 2012-11-20 10:13 UTC (permalink / raw)
To: AnilKumar Ch
Cc: wg, swarren, linux-can, tony, b-cousson, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss
[-- 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 --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
2012-11-20 10:13 ` Marc Kleine-Budde
@ 2012-11-20 10:23 ` AnilKumar, Chimata
[not found] ` <331ABD5ECB02734CA317220B2BBEABC13EA7701D-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
0 siblings, 1 reply; 19+ messages in thread
From: AnilKumar, Chimata @ 2012-11-20 10:23 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: wg, swarren, linux-can, tony, Cousson, Benoit, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
[not found] ` <331ABD5ECB02734CA317220B2BBEABC13EA7701D-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
@ 2012-11-20 10:26 ` Marc Kleine-Budde
2012-11-21 5:45 ` AnilKumar, Chimata
0 siblings, 1 reply; 19+ messages in thread
From: Marc Kleine-Budde @ 2012-11-20 10:26 UTC (permalink / raw)
To: AnilKumar, Chimata
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 1/3] can: c_can: Add d_can raminit support
[not found] ` <1352916505-12343-2-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
@ 2012-11-20 10:50 ` Marc Kleine-Budde
2012-11-20 13:05 ` AnilKumar, Chimata
0 siblings, 1 reply; 19+ messages in thread
From: Marc Kleine-Budde @ 2012-11-20 10:50 UTC (permalink / raw)
To: AnilKumar Ch
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases
[not found] ` <1352916505-12343-3-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
@ 2012-11-20 10:51 ` Marc Kleine-Budde
2013-01-02 10:13 ` AnilKumar, Chimata
0 siblings, 1 reply; 19+ messages in thread
From: Marc Kleine-Budde @ 2012-11-20 10:51 UTC (permalink / raw)
To: AnilKumar Ch
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 1/3] can: c_can: Add d_can raminit support
2012-11-20 10:50 ` Marc Kleine-Budde
@ 2012-11-20 13:05 ` AnilKumar, Chimata
2012-11-20 13:46 ` Marc Kleine-Budde
0 siblings, 1 reply; 19+ messages in thread
From: AnilKumar, Chimata @ 2012-11-20 13:05 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: wg, swarren, linux-can, tony, Cousson, Benoit, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 1/3] can: c_can: Add d_can raminit support
2012-11-20 13:05 ` AnilKumar, Chimata
@ 2012-11-20 13:46 ` Marc Kleine-Budde
0 siblings, 0 replies; 19+ messages in thread
From: Marc Kleine-Budde @ 2012-11-20 13:46 UTC (permalink / raw)
To: AnilKumar, Chimata
Cc: wg, swarren, linux-can, tony, Cousson, Benoit, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss
[-- 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 --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
2012-11-20 10:26 ` Marc Kleine-Budde
@ 2012-11-21 5:45 ` AnilKumar, Chimata
[not found] ` <331ABD5ECB02734CA317220B2BBEABC13EA778F3-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
0 siblings, 1 reply; 19+ messages in thread
From: AnilKumar, Chimata @ 2012-11-21 5:45 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: wg, swarren, linux-can, tony, Cousson, Benoit, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
2012-11-14 18:08 ` [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node AnilKumar Ch
2012-11-20 10:13 ` Marc Kleine-Budde
@ 2012-11-21 8:20 ` Marc Kleine-Budde
2013-01-02 10:14 ` AnilKumar, Chimata
1 sibling, 1 reply; 19+ messages in thread
From: Marc Kleine-Budde @ 2012-11-21 8:20 UTC (permalink / raw)
To: AnilKumar Ch
Cc: wg, swarren, linux-can, tony, b-cousson, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss
[-- 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 --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
[not found] ` <331ABD5ECB02734CA317220B2BBEABC13EA778F3-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
@ 2012-11-21 8:20 ` Marc Kleine-Budde
0 siblings, 0 replies; 19+ messages in thread
From: Marc Kleine-Budde @ 2012-11-21 8:20 UTC (permalink / raw)
To: AnilKumar, Chimata
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases
2012-11-20 10:51 ` Marc Kleine-Budde
@ 2013-01-02 10:13 ` AnilKumar, Chimata
0 siblings, 0 replies; 19+ messages in thread
From: AnilKumar, Chimata @ 2013-01-02 10:13 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: wg, swarren, linux-can, tony, Cousson, Benoit, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node
2012-11-21 8:20 ` Marc Kleine-Budde
@ 2013-01-02 10:14 ` AnilKumar, Chimata
0 siblings, 0 replies; 19+ messages in thread
From: AnilKumar, Chimata @ 2013-01-02 10:14 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: wg, swarren, linux-can, tony, Cousson, Benoit, linux-arm-kernel,
linux-omap, grant.likely, devicetree-discuss
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm
2012-11-14 18:08 [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm AnilKumar Ch
` (2 preceding siblings ...)
[not found] ` <1352916505-12343-1-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
@ 2013-01-09 12:16 ` Benoit Cousson
2013-01-09 12:20 ` AnilKumar, Chimata
3 siblings, 1 reply; 19+ messages in thread
From: Benoit Cousson @ 2013-01-09 12:16 UTC (permalink / raw)
To: AnilKumar Ch
Cc: wg, mkl, swarren, linux-can, tony, linux-arm-kernel, linux-omap,
grant.likely, devicetree-discuss
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm
2013-01-09 12:16 ` Benoit Cousson
@ 2013-01-09 12:20 ` AnilKumar, Chimata
0 siblings, 0 replies; 19+ messages in thread
From: AnilKumar, Chimata @ 2013-01-09 12:20 UTC (permalink / raw)
To: Cousson, Benoit
Cc: wg, mkl, swarren, linux-can, tony, linux-arm-kernel, linux-omap,
grant.likely, devicetree-discuss
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
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-01-09 12:20 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-14 18:08 [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm AnilKumar Ch
2012-11-14 18:08 ` [PATCH 1/3] can: c_can: Add d_can raminit support AnilKumar Ch
[not found] ` <1352916505-12343-2-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
2012-11-20 10:50 ` Marc Kleine-Budde
2012-11-20 13:05 ` AnilKumar, Chimata
2012-11-20 13:46 ` Marc Kleine-Budde
2012-11-14 18:08 ` [PATCH 3/3] ARM: dts: AM33XX: Add memory resource to d_can node AnilKumar Ch
2012-11-20 10:13 ` Marc Kleine-Budde
2012-11-20 10:23 ` AnilKumar, Chimata
[not found] ` <331ABD5ECB02734CA317220B2BBEABC13EA7701D-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2012-11-20 10:26 ` Marc Kleine-Budde
2012-11-21 5:45 ` AnilKumar, Chimata
[not found] ` <331ABD5ECB02734CA317220B2BBEABC13EA778F3-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2012-11-21 8:20 ` Marc Kleine-Budde
2012-11-21 8:20 ` Marc Kleine-Budde
2013-01-02 10:14 ` AnilKumar, Chimata
[not found] ` <1352916505-12343-1-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
2012-11-14 18:08 ` [PATCH 2/3] ARM: dts: AM33XX: Add d_can instances to aliases AnilKumar Ch
[not found] ` <1352916505-12343-3-git-send-email-anilkumar-l0cyMroinI0@public.gmane.org>
2012-11-20 10:51 ` Marc Kleine-Budde
2013-01-02 10:13 ` AnilKumar, Chimata
2012-11-20 5:00 ` [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm AnilKumar, Chimata
2013-01-09 12:16 ` Benoit Cousson
2013-01-09 12:20 ` AnilKumar, Chimata
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).