Re: [MeeGo-Dev][PATCH v3] Topcliff: Update PCH_CAN driver to 2.6.35

[Masayuki Ohtake]

Hi Wolfgang,

We have implemented our CAN driver with FIFO mode, and
We are testing our CAN driver with FIFO mode.
However, we have found Our CAN hardware spec is different from our anticipated.
Our CAN HW FIFO is not common FIFO.
Using  FIFO mode, there is possibility received packets are out-of-order.

e.g.
Recv packet-A from NW and set to FIFO.
  |A|

Recv packet-B from NW and set to FIFO.
  |A|B|

Recv packet-C is about to set to FIFO
  |A|B|(C)|

Userspace Copies A from Driver
Userspace Copies B from Driver
  |   |   |(C)|

packet-C set to FIFO (C is not head.)
Recv packet-D from NW(Next packet is set to head)
  |D|   |C|

Userspace Copies D from Driver
Userspace Copies C from Driver
Userspace raceived packet order is like below
A-B-D-C

So, I think normal-mode is better than FIFO-mode.

I will revert like the following spec.
  Rx 1 Message Object
  Tx 1 Message Object

Could you agree the above ?

Thanks, Ohtake(OKISemi)
----- Original Message ----- 
From: "Wolfgang Grandegger" <wg@xxxxxxxxxxxxxx>
To: "David Miller" <davem@xxxxxxxxxxxxx>
Cc: <masa-korg@xxxxxxxxxxxxxxx>; <andrew.chih.howe.khor@xxxxxxxxx>; <sameo@xxxxxxxxxxxxxxx>; <margie.foster@xxxxxxxxx>;
<netdev@xxxxxxxxxxxxxxx>; <yong.y.wang@xxxxxxxxx>; <linux-kernel@xxxxxxxxxxxxxxx>; <socketcan-core@xxxxxxxxxxxxxxxx>;
<mkl@xxxxxxxxxxxxxx>; <chripell@xxxxxxxx>; <morinaga526@xxxxxxxxxxxxxxx>; <meego-dev@xxxxxxxxx>;
<kok.howg.ewe@xxxxxxxxx>; <joel.clark@xxxxxxxxx>; <qi.wang@xxxxxxxxx>
Sent: Wednesday, October 06, 2010 6:12 PM
Subject: Re: [MeeGo-Dev][PATCH v3] Topcliff: Update PCH_CAN driver to 2.6.35


> On 10/06/2010 05:09 AM, David Miller wrote:
> > From: "Masayuki Ohtake" <masa-korg@xxxxxxxxxxxxxxx>
> > Date: Wed, 6 Oct 2010 12:07:15 +0900
> >
> >> Does your mail mean, for accepting upstream, NAPI is essential for
> >> CAN driver ?
> >
> > It is up to the CAN maintainers :-)
>
> Well, our SJA1000 reference driver does still not use NAPI. But NAPI is
> for CAN especially useful to avoid the infamous *bus error irq
> flooding*, which may hang low end systems if the interrupts are handled
> in the IRQ context. Ohtake, if your system can handle well such CAN bus
> error irq storms at 1MB/s, then NAPI is *not* a must to have. Anyway, as
> you are at it, I also suggest to use NAPI right from the beginning.
>
> Wolfgang.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/