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

[Wolfgang Grandegger <wg@grandegger.com>]

Hi Ohtake,

On 10/12/2010 09:09 AM, Masayuki Ohtake wrote:
> 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

OK, let's say the CPU or software starts processing the message FIFO.

> 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

The software could continues searching the FIFO for valid messages. Then
it would find C first.

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

I'm still optimistic that it could be handled properly by software, it
might be tricky though.

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

To be clear. Out-of-order reception is not allowed!

> I will revert like the following spec.
>   Rx 1 Message Object
>   Tx 1 Message Object
> 
> Could you agree the above ?

See above. I agree if the software cannot assure in-order reception. But
it's not yet obvious to me that it cannot be achieved. I will have a
closer look to the manual. Just one RX message object without any
further buffering is really bad as message losses are likely to happen.

Wolfgang.