Re: Flexcan

[Tom Evans <tom_usenet@optusnet.com.au>]

On 04/04/15 14:32, Tom Evans wrote:
> On 2/04/2015 10:35 PM, Tom Evans wrote:
> ...
> And schedules NAPI to forward them from there rather than reading them from
> the hardware FIFO.
>
> The purpose of NAPI is to make the interrupts as fast as possible, doing as
> little work as possible, but servicing time-critical hardware so it doesn't
> overflow/underflow. Operations like reading characters from a serial port.
>
> But that assumes the "little work" is fast. In the case of the FlexCAN driver,
> it takes about 5 reads and a write to read a CAN message, and there may be six
> messages in the FIFO.
>
> Not many accesses, but peripheral device registers can be notoriously slow on
> some CPUs [1].
 > ...
> I'll try and measure this on Tuesday.

Now quite tomorrow, but I have some results:

[    1.494142] flexcan flexcan.1: One do_gettimeofday took 0 us)
[    1.499903] flexcan flexcan.1: Ten do_gettimeofday took 4 us)
[    1.505677] flexcan flexcan.1: 100 flexcan_read() took 23 us)

I first measured the overhead of calling do_gettimeofday(), which is about 
0.4us. So I can pretty much ignore that in this test.

Then in a loop reading a FlexCAN control register, it took about 0.23us per 
read. That's 230ns or about 184 CPU clocks at 800MHz.

OK, so this IS a slow peripheral.

Given it takes about 5 reads to read one message, that's about 1.15us per 
message. With a queue depth of "6" that's a maximum extra delay of 6.9us.

I think that's OK for an interrupt. What's the "modern expectation" of the 
latency?

Tom