Messages in this thread | | | Date | Tue, 12 Oct 2010 09:42:52 +0200 | From | Wolfgang Grandegger <> | Subject | Re: [MeeGo-Dev][PATCH v3] Topcliff: Update PCH_CAN driver to 2.6.35 |
| |
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.
| |