Hi Wolfgang,
On 03/17/2017 01:04 PM, Wolfgang Grandegger wrote:
>
> Hm, that's unusual. Cable disconnected and then send a message:
>
> $ grep /proc/interrupts; sleep 10; /proc/interrupts
>
> should make things clear. But maybe it's a clever chip and it does stop
> sending error messages if the error counter does not change any more.
> After bus-off, the chip is quiet, of course. Should have a closer look
> to the CAN standard.
>
The interrupt count does not increment after device reaches
tx-error-passive (with cable disconnected).
# while true; do grep -i hi3110 /proc/interrupts; sleep 10; done &
[1] 793
#
111: 0 0 gpio-mxc 12 Edge hi3110
# candump -t d -e any,0:0,#FFFFFFF &
[2] 798
# cansend can0 123#
#
(000.000000) can0 20000004 [8] 00 08 00 00 00 00 60 00 ERRORFRAME
controller-problem{tx-error-warning}
error-counter-tx-rx{{96}{0}}
(000.002122) can0 20000004 [8] 00 20 00 00 00 00 80 00 ERRORFRAME
controller-problem{tx-error-passive}
error-counter-tx-rx{{128}{0}}
111: 10 0 gpio-mxc 12 Edge hi3110
111: 10 0 gpio-mxc 12 Edge hi3110
111: 10 0 gpio-mxc 12 Edge hi3110
>>> So far using NAPI was mandatory. There is the problem of out-of-order
>>> message reception if handled in the isr on multi processor systems.
>>> Marc, what is the current policy?
>>>
>>
>> Since this is a SPI based CAN, I am wary for any additional latencies
>> NAPI might introduce. The RX handling is being done at the very
>> beginning of the ISR for this reason.
>>
>> Can we go ahead with the existing implementation and re-visit this at a
>> later time?
>
> Likely yes, as Marc has already reviewed the driver once.
>
Thanks, I will go ahead and submit v4 patch.
> BTW: what system board/processor are you using?
>
It is a custom board using Phytec phyFLEX-i.MX6 Dual SOM.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
