On 09/15/2010 11:42 AM, Oliver Hartkopp wrote: > On 15.09.2010 09:42, Wolfgang Grandegger wrote: >> On 09/14/2010 02:46 AM, Masayuki Ohtake wrote: >>> Hi Marc, >>> >>>>>> - implement NAPI >>>>> Since Topcliff CAN HW register has only single rx buffer, >>>>> I think NAPI is unnecessary. >>> >>>> Doesn't matter. Please try to implement it. >>> >>> Our CAN driver must pull received data from CAN-HW rx buffer as fast as it >>> can >>> so that the received data is not over-written by next received data. >>> In case of implemented with NAPI, >>> since NAPI has time-lagging after receiving first packet, >>> probability of over-written(discarded) buffer is to be high. >>> Thus, for our CAN HW, we should NOT implement with NAPI but normal >>> "netif_rx". >> >> True, if you just use one RX-Object. But it just helps a little bit and >> it would be much better to use the buffering on RX messages in the CAN >> controller hardware, either by using more than one RX object, or >> combining RX objects to a FIFO, or whatever your CAN controller supports. > > Good point! > > As long as the order of the received CAN frames is not shuffled (-> plain FIFO > behaviour) using more than one RX buffer is a good idea. > > Just a remark: > > During the IDF the informations about the Topcliff Controller Hub have been > reworked, so that some of the documentation became available for the public: > > http://edc.intel.com/Platforms/Atom-E6xx/#hardware > > Especially the Datasheet for the Platform Controller Hub EG20T can be found: > > http://download.intel.com/embedded/chipsets/datasheet/324211.pdf > > In chapter 13 there are some details about the CAN controller.
Ah, thanks for the link. The CAN controller seems then to be similar to the OKI MSM9225B. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
