On Wed, Sep 30, 2009 at 6:49 AM, Rakesh Jagota <[email protected]> wrote:
> Hi Christian,
>

Hi,

> with SPI interface. The Can driver works but I observed data loss:
>
> mcp2515 spi2.0: EFLG = 0x40

Yes this means input overrun. Keep in mind that the CAN controller
runs over SPI, it's not suited for high performance applications. If
the system is under load it's even worse because the workqueues
compete with other kernel process for the CPU time (and by default
with a lower non-RT priority). It depends on the implementation of the
SPI driver too. If the system is under load a dirty hack could be the
following patch:

------------------------------ kernel/workqueue.c ------------------------------
index 4048e92..bfeeee2 100644
@@ -974,3 +974,36 @@ void __init init_workqueues(void)
        keventd_wq = create_workqueue("events");
        BUG_ON(!keventd_wq);
 }
+
+void set_workqueue_max_prio(struct workqueue_struct *wq, int rt)
+{
+ struct task_struct *p;
+ int cpu;
+ int r = 0;
+ struct sched_param param = {
+   .sched_priority = MAX_RT_PRIO - 1,
+ };
+
+ if (is_single_threaded(wq)) {
+   p = wq->cpu_wq->thread;
+   if (rt)
+     r = sched_setscheduler(wq->cpu_wq->thread, SCHED_FIFO, &param);
+   else
+     set_user_nice(p, -20);
+   if (r)
+     printk("maxprio setting failed: %d\n", r);
+ } else {
+   for_each_online_cpu(cpu) {
+     struct cpu_workqueue_struct *cwq = wq->cpu_wq + cpu;
+
+     p = cwq->thread;
+     if (rt)
+       r = sched_setscheduler(wq->cpu_wq->thread, SCHED_FIFO, &param);
+     else
+       set_user_nice(p, -20);
+     if (r)
+       printk("maxprio setting failed: %d\n", r);
+   }
+ }
+}
+EXPORT_SYMBOL_GPL(set_workqueue_max_prio);

and then increasing the priority of the worqueues with something like:

set_workqueue_max_prio(&priv->tx_work, 1);
set_workqueue_max_prio(&priv->irq_work, 1);

after INIT_WORK-ing them. Please keep in mind that this exposes the
system to DOS attacks via CAN interface. Anyway this is a more general
problem, perhaps the drivers should be written without using
workqueues as they are implemented nowadays in Linux. But they will
became much more messy!

> I would like to know about your inputs on data corruption and packet loss.

packet loss is ok but corruption *isn't*. Can you send me some
examples of data corruption?

>
> Even I used to see one more error message "write: No buffer space available"

that's ok too, you are sending data from user program too fast for the
driver to finish transmission.

>
> Looking forward for your suggestion so that I can fix this issue.
>

I think the only possible problem here is the data corruption you
mentioned. Can you send some examples of it? Anyway I think you
shouldn't use devices wired via SPI for high-performance and high
throughput data streams. Have a look at how SPI is implemented on your
platform too, perhaps you are suffering low performance (low clock,
high delays between transfers, use of worqueues) at that layer too (I
never worked with the imx arch).

Bye!

-- 
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to