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. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
