[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7A0BFCFE3DA5CD47B0FB7984326F201A13689D36EE@BGMAIL01.nvidia.com>
Date: Fri, 10 Feb 2012 14:50:22 +0530
From: Alok Chauhan <alokc@...dia.com>
To: Alok Chauhan <alokc@...dia.com>, Ben Dooks <ben-i2c@...ff.org>
CC: "khali@...ux-fr.org" <khali@...ux-fr.org>,
"ben-linux@...ff.org" <ben-linux@...ff.org>,
Stephen Warren <swarren@...dia.com>,
"olof@...om.net" <olof@...om.net>,
"bones@...retlab.ca" <bones@...retlab.ca>,
"paul.gortmaker@...driver.com" <paul.gortmaker@...driver.com>,
"dgreid@...gle.com" <dgreid@...gle.com>,
Laxman Dewangan <ldewangan@...dia.com>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] i2c: tegra: Add delay before reset the controller
> On Mon, Dec 26, 2011 at 04:44:41PM +0530, Alok Chauhan wrote:
>>
> + /*
> + * In NACK error condition resetting of I2C controller happens
> + * before STOP condition is properly completed by I2C controller,
> + * so wait for 2 clock cycle to complete STOP condition.
> + */
> + if (i2c_dev->msg_err == I2C_ERR_NO_ACK)
> + udelay(DIV_ROUND_UP(2 * 1000000, i2c_dev->bus_clk_rate));
> +
>Is a delay here good, would it be better to sleep so that some other process can gain cpu time?
>>We mostly used 100 khz i2c clock frequency and delay in that case will be 20 usec. Would it be ok to sleep for such a smaller time? Won't it increase any other overhead?
Please let me know if sleep is better option here instead of waiting.
Thanks
Alok
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists