[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CEA2986.4080607@pengutronix.de>
Date: Mon, 22 Nov 2010 09:27:50 +0100
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Tomoya MORINAGA <tomoya-linux@....okisemi.com>
CC: andrew.chih.howe.khor@...el.com, socketcan-core@...ts.berlios.de,
Samuel Ortiz <sameo@...ux.intel.com>, margie.foster@...el.com,
netdev@...r.kernel.org, Christian Pellegrin <chripell@...e.org>,
linux-kernel@...r.kernel.org, yong.y.wang@...el.com,
Masayuki Ohtake <masa-korg@....okisemi.com>,
kok.howg.ewe@...el.com, joel.clark@...el.com,
"David S. Miller" <davem@...emloft.net>,
Wolfgang Grandegger <wg@...ndegger.com>, qi.wang@...el.com
Subject: Re: [PATCH net-next-2.6 v3] can: Topcliff: PCH_CAN driver: Add Flow
control,
On 11/22/2010 06:05 AM, Tomoya MORINAGA wrote:
> On Friday, November 19, 2010 6:20 PM, Marc Kleine-Budde wrote :
>
>>>>> - spin_unlock_irqrestore(&priv->msgif_reg_lock, flags);
>>>>> + pch_can_rw_msg_obj(&priv->regs->ifregs[1].creq, tx_obj_no);
>>>> 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.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)
Powered by blists - more mailing lists