From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Subject: Re: [MeeGo-Dev][PATCH v3] Topcliff: Update PCH_CAN driver to 2.6.35 Date: Fri, 01 Oct 2010 14:40:55 +0200 Message-ID: <4CA5D6D7.3010608@grandegger.com> References: <4C9C7C6F.1000003@dsn.okisemi.com> <4CA4541F.5040804@grandegger.com> <000401cb614f$c932c750$66f8800a@maildom.okisemi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, qi.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, margie.foster-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, yong.y.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org, kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, joel.clark-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, Tomoya MORINAGA , meego-dev-WXzIur8shnEAvxtiuMwx3w@public.gmane.org, "David S. Miller" , Christian Pellegrin , Samuel Ortiz To: Masayuki Ohtake Return-path: In-Reply-To: <000401cb614f$c932c750$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: socketcan-core-bounces-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org Errors-To: socketcan-core-bounces-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org List-Id: netdev.vger.kernel.org On 10/01/2010 12:02 PM, Masayuki Ohtake wrote: > Hi Wolfgang Grandegger, > > Thank you for your comments. > > We will modify and re-post ASAP. > > I have a comment about below. >> In this driver you are using just *one* RX object. This means that the >> CPU must handle new messages as quickly as possible otherwise message >> losses will happen, right?. For sure, this will not make user's happy. >> Any chance to use more RX objects in FIFO mode? > > In case implementing with FIFO mode, > received packets may be our of order. Hm, FIFO means "First in First out"! It might be tricky to implement, though. > Because our CAN register access is slow. > > I am confirming our CAN HW spec and the possibility of our-of-order. I don't understand? Wolfgang.