Re: AW: flexcan missing error state transitions

[Andri Yngvason <andri.yngvason@marel.com>]

Hi Mark,

Quoting Jonas Mark (ST-FIR/ENG1) (2017-08-21 17:13:34)
> > I am not sure that I like the userspace polling idea. I think it would be better to have
> > the polling implemented within the driver because it keeps the interface "simple"
> > and there will be fewer differences between different platforms. I.e.
> > the same userpspace code should work for flexcan, sja1000, mscan, etc..
> 
> Which polling interval do you think would be appropriate? It somehow has to be a reasonable trade-off between latency and CPU usage.
That's a good question. I don't think that there is a really good answer to it.
It would be nice to see intermittent state-transitions happening, so I would say
as fast as possible without affecting CPU usage to a significant degree. The
polling timer should not be a high resolution timer or anything that would
preempt an rt task.

This value could also depend on the bitrate as that will affect the rate at
which the error-counter can change. E.g. on 125 k rate, you will receive at most
one frame per 1 ms. This means that the error state will change at at least
64 ms intervals, so we would have to sample at 32 ms intervals to catch all the
transitions. For 1 M this would be around 2 ms.

Note that this is all somewhat speculative as I do not know exactly how fast the
error counters are incremented/decremented.

> 
> Would it make sense to make the polling interval configurable via device tree?
Also a good questions. I tried compiling a C program that runs usleep(2000) in a
loop for the i.MX6. It runs at around 1% CPU usage in top. I would call that
significant. Perhaps it would run better in kernel space?

If the polling interval can be configured, users who care about it can set it to
a value that matches their bitrate. Others could set it to zero to turn it off.

As the useful sampling frequency depends on the bitrate, perhaps it should even
be a part of the netlink interface? This would also make it easier for the user
to find a good sampling frequency based on trial and error.

Regards,
Andri