Re: c_can: (newbie) high system load when frame not acked?

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

On 14/01/15 02:32, Andri Yngvason wrote:
> Quoting Viktor Babrian (2015-01-13 15:10:29)
>
> Note: The FlexCAN driver does actually respect berr-reporting for i.MX6.
> However, it does not respect it for some older chips.

The flexcan.c driver behaves differently depending on whether it has 
"FLEXCAN_HAS_BROKEN_ERR_STATE" set (on for MX25, MX35, MX53 and off for MX28 
and MX6). I don't think this distinction actually helps, or improves matters 
enough to be worth the CPU loading this causes in these disconnected/solo CAN 
states.

On the "unbroken" chips, the only difference is that you get is interrupts on 
the WARNING transitions. As far as I can see, all that gets you is an 
interrupt when the WARNING state goes away which will trigger a poll that can 
then see that the ERROR_PASSIVE state has cleared in the absence of Receive or 
Transmit interrupts. You get interrupts when the WARNING state sets as well, 
but that happens before the PASSIVE state, so you'll miss that one.

The TXECTR can only decrement on successful transmission which causes a 
transmit interrupt, so the warning interrupt doesn't help here.

The RXECTR only decrements on successful reception, which will cause a receive 
interrupt UNLESS it doesn't match on a filter. But since the driver doesn't 
USE the filters (it accepts everything) that's a moot point too.

Does "FLEXCAN_HAS_BROKEN_ERR_STATE" do anything useful that I've missed? If 
not then that code should be removed. I've done that in the old (Linux 3.4) 
version of the driver I'm using.

> Perhaps, you would like to post your patch? Turning off the
 > interrupts when berr-reporting is off is definitely correct
 > behaviour. Not turning them off seems rather pointless to me.
 > AFAIK the whole point of this flag is to suppress ack-error flood.

There's the load caused by the interrupts, and the additional load caused by 
the call to netif_receive_skb(skb) to report the error up through the stack. 
Getting rid of the latter overhead might have been the intention, or might 
have been "this is the best we can do on this chip".

Tom Evans