christian pellegrin wrote: > On Thu, Jan 21, 2010 at 9:19 PM, Wolfgang Grandegger <[email protected]> > wrote: > >> Threaded irqs entered the kernel with 2.6.30. How do you want to >> maintain backward compatibility with older kernels. > > Yes, I apologize I didn't write this clearly. Threaded interrupts run > with FIFO RT priority which is fairly better that workqueues which are > normal tasks as far as scheduling latency is concerned (BTW I did the > tests with a 1Khz tick-full preemption enabled kernel). I did some > testing and the more critical point is to respond in time. > Unfortunately CAN frames can be very short (simple ones without > payload for example) and we have just 2 buffers for this. I was > thinking about other solutions too, for example handling the RX as an > hard interrupt. But unfortunately SPI generic subsystem is .... > generic. So for example on S3C24xx the better way to use SPI is just > to busy loop for transfer finishing (DMA take ages to set-up and > interrupt driven means one interrupt per byte which are tens of > thousands of interrupts per second under load). So I think this is the > best that someone can ask as a generic solution employing a mcp251x.
Yes. I was thinking to use NAPI (rx poll), but that would result in longer latencies. > It's interesting to note that CAN is about RT but Linux RT kernels are > enforcing all interrupt handlers to be threaded. I guess even on > SJA1000 and other with such small RX buffers it's just impossible to > handle an incoming stream this way. The SJA1000 can buffer up to 64 bytes, which is not that bad. CAN produces one interrupt per message, which could put heavy load onto the system. Catching up at full rate is a challenge for low-end systems, indeed. Fortunately, in real applications there are normally not that much CAN messages flying around. Note that bus-errors on the SJA1000 (and some other controllers) may be triggered at full rate, which may result in the infamous bus-error flooding. We try to solve this issue with NAPI (like for the AT91 CAN). Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
