Re: flexcan missing error state transitions

[Wolfgang Grandegger <wg@grandegger.com>]

Am 22.08.2017 um 16:06 schrieb Marc Kleine-Budde:
> On 08/22/2017 03:50 PM, Jonas Mark (ST-FIR/ENG1) wrote:
>> Hello Andri,
>>
>>>> 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.
>>
>> We agree that there is a sensible lower boundary for the polling
>> interval which depends on the bitrate. And there is a upper boundary
>> which depends on the application.
>>
>> We are currently thinking about whether it would be possible to do
>> the polling only in case the controller is actually experiencing
>> trouble.
> 
> Why not enable bus errors on broken controllers. Disable once a bus

Yes, that's what we have done in the past for Flexcan controller cores 
that do not have dedicated interrupt lines for state changes. We have 
introduced FLEXCAN_QUIRK_BROKEN_ERR_STATE for that purpose. It should 
work already with the current driver. Yi ZHU, have you tried that?

> error hits and re-enable them after a configurable timeout with a proper
> default. I have a patch somewhere, although it applies only against the
> pre rx-offload version of the driver.

And that would help to avoid the interrupt flooding problem.

Wolfgang.