[Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Fabrice Gasnier]

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

Dear all,

I'm trying to build xenomai-2.6.0 with kernel 3.0.4 for powerpc (MPC5121).
some config options:
CONFIG_PPC_MPC512x=y
CONFIG_XENO_DRIVERS_CAN=m
CONFIG_XENO_DRIVERS_CAN_MSCAN=m

Using CAN support leads to compile errors:
   CC [M]  drivers/xenomai/can/mscan/rtcan_mscan.o
   CC [M]  drivers/xenomai/can/mscan/rtcan_mscan_mpc5xxx.o
drivers/xenomai/can/mscan/rtcan_mscan_mpc5xxx.c: In function 
'mpc512x_can_get_clock':
drivers/xenomai/can/mscan/rtcan_mscan_mpc5xxx.c:158:30: error: 'struct 
platform_device' has no member named 'node'
drivers/xenomai/can/mscan/rtcan_mscan_mpc5xxx.c:174:41: error: 'struct 
platform_device' has no member named 'node'
drivers/xenomai/can/mscan/rtcan_mscan_mpc5xxx.c:178:31: error: 'struct 
platform_device' has no member named 'node'
make[5]: *** [drivers/xenomai/can/mscan/rtcan_mscan_mpc5xxx.o] Error 1


I'm a bit surprised as I found a xenomai git commit that seem to handle 
this issue when building with CONFIG_PPC_MPC52xx:
- can: adapt to platform driver infrastructure changes for 2 .6.35
http://git.xenomai.org/?p=xenomai-head.git;a=commit;h=50b289784ef2b0734bef1e99b008ff4b79ad5409


I believe this issue can be fixed for MPC512x as well, by using same 
principle. Is it correct to do so?

Index: xenomai-2.6.0/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c
===================================================================
--- xenomai-2.6.0.orig/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c    
2011-10-18 20:17:18.000000000 +0200
+++ xenomai-2.6.0/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c    
2011-12-21 11:52:43.000000000 +0100
@@ -155,7 +155,7 @@
      }

      /* Determine the MSCAN device index from the physical address */
-    pval = of_get_property(ofdev->node, "reg", &plen);
+    pval = of_get_property(mpc5xxx_get_of_node(ofdev), "reg", &plen);
      BUG_ON(!pval || plen < sizeof(*pval));
      clockidx = (*pval & 0x80) ? 1 : 0;
      if (*pval & 0x2000)
@@ -171,11 +171,11 @@
       */
      if (clock_name && !strcmp(clock_name, "ip")) {
          *mscan_clksrc = MSCAN_CLKSRC_IPS;
-        freq = mpc5xxx_get_bus_frequency(ofdev->node);
+        freq = mpc5xxx_get_bus_frequency(mpc5xxx_get_of_node(ofdev));
      } else {
          *mscan_clksrc = MSCAN_CLKSRC_BUS;

-        pval = of_get_property(ofdev->node,
+        pval = of_get_property(mpc5xxx_get_of_node(ofdev),
                         "fsl,mscan-clock-divider", &plen);
          if (pval && plen == sizeof(*pval))
              clockdiv = *pval;




If it's ok, can it be integrated into xenomai-head?

Thanks in advance,

Fabrice Gasnier

-- 

Fabrice GASNIER, Ingénieur Systèmes Embarqués
Email: fabrice.gasnier@domain.hid <mailto:fabrice.gasnier@domain.hid>

Découvrez notre catalogue de formations 2011 
<http://www.cenosys.com/contenu/pdf/catalogue.pdf>

<http://www.cenosys.com>

10 rue Xavier Bichat - 72000 Le Mans - France - Tel: +33(0)2 43 51 17 97 
- Fax: +33(0)2 43 51 17 98 - www.cenosys.com <http://www.cenosys.com>

CONFIDENTIALITÉ : Ce message électronique et tous les fichiers attachés 
qu'il contient sont confidentiels et destinés exclusivement à l'usage de 
la personne à laquelle ils sont adressés. Si vous avez reçu ce message 
par erreur, merci de le retourner immédiatement à son émetteur sans en 
conserver de copie.

CONFIDENTIALITY : This e-mail and any attachments are confidential and 
may also be privileged. If you are not the named recipient, please 
notify the sender immediately and do not disclose the contents to an 
other person, use it for any purpose, or store or copy the information 
in any medium.


[-- Attachment #2.1: Type: text/html, Size: 6078 bytes --]

[-- Attachment #2.2: pied-mail.png --]
[-- Type: image/png, Size: 7760 bytes --]

Re: [Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Gilles Chanteperdrix]

On 12/21/2011 12:22 PM, Fabrice Gasnier wrote:
> If it's ok, can it be integrated into xenomai-head?

It is not OK, your patch fails to apply. But if you send a properly
formatted patch, it will be applied. If you do not know how to properly
format a patch, use "git format-patch".

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Fabrice Gasnier]

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

Dear Gilles,

please find attached a properly formatted patch using git (hope so).

Fabrice

> It is not OK, your patch fails to apply. But if you send a properly
> formatted patch, it will be applied. If you do not know how to properly
> format a patch, use "git format-patch".
>

[-- Attachment #2: 0001-mpc5121-can-adapt-to-platform-driver-infrastructure-.patch --]
[-- Type: text/x-patch, Size: 1544 bytes --]

>From 735c80009228d66a77126dd989008a6ca9b1d6b4 Mon Sep 17 00:00:00 2001
From: Fabrice Gasnier <fabrice.gasnier@domain.hid>
Date: Tue, 3 Jan 2012 09:28:40 +0100
Subject: [PATCH] mpc5121 can: adapt to platform driver infrastructure changes for 2.6.35

---
 ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c b/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c
index 82aea37..e65e0c2 100644
--- a/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c
+++ b/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c
@@ -155,7 +155,7 @@ static u32 __devinit mpc512x_can_get_clock(struct of_device *ofdev,
 	}
 
 	/* Determine the MSCAN device index from the physical address */
-	pval = of_get_property(ofdev->node, "reg", &plen);
+	pval = of_get_property(mpc5xxx_get_of_node(ofdev), "reg", &plen);
 	BUG_ON(!pval || plen < sizeof(*pval));
 	clockidx = (*pval & 0x80) ? 1 : 0;
 	if (*pval & 0x2000)
@@ -171,11 +171,11 @@ static u32 __devinit mpc512x_can_get_clock(struct of_device *ofdev,
 	 */
 	if (clock_name && !strcmp(clock_name, "ip")) {
 		*mscan_clksrc = MSCAN_CLKSRC_IPS;
-		freq = mpc5xxx_get_bus_frequency(ofdev->node);
+		freq = mpc5xxx_get_bus_frequency(mpc5xxx_get_of_node(ofdev));
 	} else {
 		*mscan_clksrc = MSCAN_CLKSRC_BUS;
 
-		pval = of_get_property(ofdev->node,
+		pval = of_get_property(mpc5xxx_get_of_node(ofdev),
 				       "fsl,mscan-clock-divider", &plen);
 		if (pval && plen == sizeof(*pval))
 			clockdiv = *pval;
-- 
1.7.0.4

Re: [Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Gilles Chanteperdrix]

On 01/03/2012 09:47 AM, Fabrice Gasnier wrote:
> Dear Gilles,
> 
> please find attached a properly formatted patch using git (hope so).

Applied, thanks.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Fabrice Gasnier]

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

Thanks Gilles.

I posted some time ago another question that is somehow related to rtcan 
and mpc5121:
insmod xeno_rtcan_mscan gets stuck on MPC5121
https://mail.gna.org/public/xenomai-core/2011-09/msg00032.html

I still have this issue and prepared a re-worked patch that you can find 
attached to this email.
Can this also be applied?

Regards,
Fabrice

On 03/01/2012 22:03, Gilles Chanteperdrix wrote:
> On 01/03/2012 09:47 AM, Fabrice Gasnier wrote:
>> Dear Gilles,
>>
>> please find attached a properly formatted patch using git (hope so).
> Applied, thanks.
>

[-- Attachment #2: 0001-fix-mscan-init-on-mpc5121.patch --]
[-- Type: text/x-patch, Size: 2564 bytes --]

>From 8e8a5e35d4c85a6a0e239c61009a309f6cb0437d Mon Sep 17 00:00:00 2001
From: Fabrice Gasnier <fabrice.gasnier@domain.hid>
Date: Wed, 4 Jan 2012 10:54:56 +0100
Subject: [PATCH] fix mscan init on mpc5121

---
 ksrc/drivers/can/mscan/rtcan_mscan.c |   38 ++++++++++++++++++++++++++++++++-
 1 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/ksrc/drivers/can/mscan/rtcan_mscan.c b/ksrc/drivers/can/mscan/rtcan_mscan.c
index d25fc5a..7d69348 100644
--- a/ksrc/drivers/can/mscan/rtcan_mscan.c
+++ b/ksrc/drivers/can/mscan/rtcan_mscan.c
@@ -40,6 +40,8 @@
 #include "rtcan_mscan_regs.h"
 #include "rtcan_mscan.h"
 
+#define MSCAN_SET_MODE_RETRIES	255
+
 /**
  *  Reception Interrupt handler
  *
@@ -306,11 +308,41 @@ static int rtcan_mscan_mode_stop(struct rtcan_device *dev,
 
 	/* Switch to sleep mode */
 	setbits8(&regs->canctl0, MSCAN_SLPRQ);
+	reg = in_8(&regs->canctl1);
+	while (!(reg & MSCAN_SLPAK) &&
+	        (rinit < MSCAN_SET_MODE_RETRIES)) {
+		if (likely(lock_ctx != NULL))
+			rtdm_lock_put_irqrestore(&dev->device_lock, *lock_ctx);
+		/* Busy sleep 1 microsecond */
+		rtdm_task_busy_sleep(1000);
+		if (likely(lock_ctx != NULL))
+			rtdm_lock_get_irqsave(&dev->device_lock, *lock_ctx);
+		rinit++;
+		reg = in_8(&regs->canctl1);
+	}
+	/*
+	 * The mscan controller will fail to enter sleep mode,
+	 * while there are irregular activities on bus, like
+	 * somebody keeps retransmitting. This behavior is
+	 * undocumented and seems to differ between mscan built
+	 * in mpc5200b and mpc5200. We proceed in that case,
+	 * since otherwise the slprq will be kept set and the
+	 * controller will get stuck. NOTE: INITRQ or CSWAI
+	 * will abort all active transmit actions, if still
+	 * any, at once.
+	 */
+	if (rinit >= MSCAN_SET_MODE_RETRIES)
+		rtdm_printk("rtcan_mscan: device failed to enter sleep mode. "
+				"We proceed anyhow.\n");
+	else
+		dev->state = CAN_STATE_SLEEPING;
+
+	rinit=0;
 	setbits8(&regs->canctl0, MSCAN_INITRQ);
 
 	reg = in_8(&regs->canctl1);
-	while (!(reg & MSCAN_SLPAK) ||
-	       !(reg & MSCAN_INITAK)) {
+	while (!(reg & MSCAN_INITAK) &&
+	        (rinit < MSCAN_SET_MODE_RETRIES)) {
 		if (likely(lock_ctx != NULL))
 			rtdm_lock_put_irqrestore(&dev->device_lock, *lock_ctx);
 		/* Busy sleep 1 microsecond */
@@ -320,6 +352,8 @@ static int rtcan_mscan_mode_stop(struct rtcan_device *dev,
 		rinit++;
 		reg = in_8(&regs->canctl1);
 	}
+	if (rinit >= MSCAN_SET_MODE_RETRIES)
+		ret = -ENODEV;
 
 	/* Volatile state could have changed while we slept busy. */
 	dev->state = CAN_STATE_STOPPED;
-- 
1.7.0.4

Re: [Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Wolfgang Grandegger]

Hi Fabrice,

On 01/04/2012 11:06 AM, Fabrice Gasnier wrote:
> Thanks Gilles.
> 
> I posted some time ago another question that is somehow related to rtcan
> and mpc5121:
> insmod xeno_rtcan_mscan gets stuck on MPC5121
> https://mail.gna.org/public/xenomai-core/2011-09/msg00032.html
> 
> I still have this issue and prepared a re-worked patch that you can find
> attached to this email.
> Can this also be applied?

Looks good. This patch is obviously derived from the MSCAN driver of the
Linux kernel where we know that it works:

  http://lxr.linux.no/#linux+v3.1.7/drivers/net/can/mscan/mscan.c#L62

Just a minor issue:

s/rinit=0/rinit = 0/

Could please send a separate patch inline. I will do some testing on my
MPC5200 and MPC5121 boards later this week.

Thanks,

Wolfgang.

Re: [Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Fabrice Gasnier]

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

---
  ksrc/drivers/can/mscan/rtcan_mscan.c |   38 
++++++++++++++++++++++++++++++++-
  1 files changed, 36 insertions(+), 2 deletions(-)



[-- Attachment #2: 0001-fix-mscan-init-on-mpc5121.patch --]
[-- Type: text/x-patch, Size: 2215 bytes --]

diff --git a/ksrc/drivers/can/mscan/rtcan_mscan.c b/ksrc/drivers/can/mscan/rtcan_mscan.c
index d25fc5a..edd590e 100644
--- a/ksrc/drivers/can/mscan/rtcan_mscan.c
+++ b/ksrc/drivers/can/mscan/rtcan_mscan.c
@@ -40,6 +40,8 @@
 #include "rtcan_mscan_regs.h"
 #include "rtcan_mscan.h"
 
+#define MSCAN_SET_MODE_RETRIES	255
+
 /**
  *  Reception Interrupt handler
  *
@@ -306,11 +308,41 @@ static int rtcan_mscan_mode_stop(struct rtcan_device *dev,
 
 	/* Switch to sleep mode */
 	setbits8(&regs->canctl0, MSCAN_SLPRQ);
+	reg = in_8(&regs->canctl1);
+	while (!(reg & MSCAN_SLPAK) &&
+	        (rinit < MSCAN_SET_MODE_RETRIES)) {
+		if (likely(lock_ctx != NULL))
+			rtdm_lock_put_irqrestore(&dev->device_lock, *lock_ctx);
+		/* Busy sleep 1 microsecond */
+		rtdm_task_busy_sleep(1000);
+		if (likely(lock_ctx != NULL))
+			rtdm_lock_get_irqsave(&dev->device_lock, *lock_ctx);
+		rinit++;
+		reg = in_8(&regs->canctl1);
+	}
+	/*
+	 * The mscan controller will fail to enter sleep mode,
+	 * while there are irregular activities on bus, like
+	 * somebody keeps retransmitting. This behavior is
+	 * undocumented and seems to differ between mscan built
+	 * in mpc5200b and mpc5200. We proceed in that case,
+	 * since otherwise the slprq will be kept set and the
+	 * controller will get stuck. NOTE: INITRQ or CSWAI
+	 * will abort all active transmit actions, if still
+	 * any, at once.
+	 */
+	if (rinit >= MSCAN_SET_MODE_RETRIES)
+		rtdm_printk("rtcan_mscan: device failed to enter sleep mode. "
+				"We proceed anyhow.\n");
+	else
+		dev->state = CAN_STATE_SLEEPING;
+
+	rinit = 0;
 	setbits8(&regs->canctl0, MSCAN_INITRQ);
 
 	reg = in_8(&regs->canctl1);
-	while (!(reg & MSCAN_SLPAK) ||
-	       !(reg & MSCAN_INITAK)) {
+	while (!(reg & MSCAN_INITAK) &&
+	        (rinit < MSCAN_SET_MODE_RETRIES)) {
 		if (likely(lock_ctx != NULL))
 			rtdm_lock_put_irqrestore(&dev->device_lock, *lock_ctx);
 		/* Busy sleep 1 microsecond */
@@ -320,6 +352,8 @@ static int rtcan_mscan_mode_stop(struct rtcan_device *dev,
 		rinit++;
 		reg = in_8(&regs->canctl1);
 	}
+	if (rinit >= MSCAN_SET_MODE_RETRIES)
+		ret = -ENODEV;
 
 	/* Volatile state could have changed while we slept busy. */
 	dev->state = CAN_STATE_STOPPED;

Re: [Xenomai-help] Xenomai rtcan build issue on MPC5121 (kernel >= 2.6.35)

[Wolfgang Grandegger]

On 01/04/2012 02:48 PM, Fabrice Gasnier wrote:
> ---
>  ksrc/drivers/can/mscan/rtcan_mscan.c |   38
> ++++++++++++++++++++++++++++++++-
>  1 files changed, 36 insertions(+), 2 deletions(-)
> 

Unfortunately, this is not a proper patch. It should have:

- a descriptive subject line, e.g.:

  [PATCH] fix mscan init on mpc5121

- a short description of the patch. Why? What does it fix?

- your signed-off-by line.

Furthermore, the patch should be send *inline* (and not as attachment).
The best is to setup and use "git send-email" for that purpose.
Otherwise you need to tweak you mail clients somehow to avoid
white-space mangling.

Thanks,

Wolfgang.