Re: flexcan driver: tx_bytes counter never incremented when CAN_RAW_LOOPBACK removed?

[Stephane Grosjean <s.grosjean@peak-system.com>]

Le 29/04/2013 14:55, Wolfgang Grandegger a écrit :
>> I also have seen that the flexcan ctrlr (iMx25) behaves oddly when rx
>> overrun occurs: each time I get such an OVR INT., I also get some
> OVR INT? What error do you mean?

         /* FIFO overflow */
         if (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_OVERFLOW) {


>> spurious TX INT. too, while I never sent anything on the CAN. So, for
>> me, handling tx_bytes/tx_packets stats when sending the data would fix
>> everything!
> See above. What has the handling of tx_bytes/tx_packets stats to do with
> spurious TX INT or the OVR INT?

         /* transmission complete interrupt */
         if (reg_iflag1 & (1 << FLEXCAN_TX_BUF_ID)) {
                 stats->tx_bytes += can_get_echo_skb(dev, 0);
                 stats->tx_packets++;


I don't even know the reason for the moment but when any 
RX_FIFO_OVERFLOW interrupts occur, some (spurious) TX_BUF_ID follow too 
(to be more precise: FLEXCAN_TX_BUF_ID bit is sometimes set too in 
iflag1), which leads "tx_packets" to increase while no CAN frames have 
been sent at all! Didn't find any documentation nor errata about this, 
but it's a fact.

My proposal was only a quick 'n secure workaround for both issues: 
"tx_bytes always 0 when LOOPBACK not set" AND "wrong tx_packets (and 
tx_bytes) management on spurious TX INTerrupts".

Stéphane

--
PEAK-System Technik GmbH, Otto-Roehm-Strasse 69, D-64293 Darmstadt 
Geschaeftsleitung: A.Gach/U.Wilhelm,St.Nr.:007/241/13586 FA Darmstadt 
HRB-9183 Darmstadt, Ust.IdNr.:DE 202220078, WEE-Reg.-Nr.: DE39305391 
Tel.+49 (0)6151-817320 / Fax:+49 (0)6151-817329, info@peak-system.com