Messages in this thread | | | From | "Tomoya MORINAGA" <> | Date | Wed, 24 Nov 2010 09:09:16 +0900 |
| |
On Monday, November 22, 2010 5:27 PM, Marc Kleine-Budde wrote: >>>>> Still we have the busy waiting in the TX path. Maybe you can move the >>>>> waiting before accessing the if[1] and remove the busy waiting here. >>>> I can't understand your saying. >>>> For transmitting data, calling pch_can_rw_msg_obj is mandatory. >>> Yes, but the busy wait is not needed. It should be enough to do the >>> busy-waiting _before_ accessing the if[1]. >> >> Do you mean we should create other pch_can_rw_msg_obj which doesn't have busy wait ? >ACK, and this non busy waiting is use in the TX path. But you add a busy >wait only function before accessing the if[1] in the TX path.
The "busy waiting" of pch_can_rw_msg_obj is for next processing accesses to Message object. If deleting this busy waiting, next processing can access to Message object, regardless previous transfer doesn't complete yet. Thus, I think, the "busy waiting" is necessary.
--- Thanks,
Tomoya MORINAGA OKI SEMICONDUCTOR CO., LTD.
----- Original Message ----- From: "Marc Kleine-Budde" <mkl@pengutronix.de> To: "Tomoya MORINAGA" <tomoya-linux@dsn.okisemi.com> Cc: <andrew.chih.howe.khor@intel.com>; <socketcan-core@lists.berlios.de>; "Samuel Ortiz" <sameo@linux.intel.com>; <margie.foster@intel.com>; <netdev@vger.kernel.org>; "Christian Pellegrin" <chripell@fsfe.org>; <linux-kernel@vger.kernel.org>; <yong.y.wang@intel.com>; "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>; <kok.howg.ewe@intel.com>; <joel.clark@intel.com>; "David S. Miller" <davem@davemloft.net>; "Wolfgang Grandegger" <wg@grandegger.com>; <qi.wang@intel.com> Sent: Monday, November 22, 2010 5:27 PM Subject: Re: [PATCH net-next-2.6 v3] can: Topcliff: PCH_CAN driver: Add Flow control,
| |