- Subject: Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function
- From: Viresh Kumar <viresh.kumar@xxxxxx>
- Date: Wed, 29 Feb 2012 17:28:17 +0530
- Cc: viresh kumar <viresh.linux@xxxxxxxxx>, Rajeev KUMAR <rajeev-dlh.kumar@xxxxxx>, Shubhrajyoti Datta <omaplinuxkernel@xxxxxxxxx>, "khali@xxxxxxxxxxxx" <khali@xxxxxxxxxxxx>, "ben-linux@xxxxxxxxx" <ben-linux@xxxxxxxxx>, "w.sang@xxxxxxxxxxxxxx" <w.sang@xxxxxxxxxxxxxx>, Armando VISCONTI <armando.visconti@xxxxxx>, Shiraz HASHIM <shiraz.hashim@xxxxxx>, Vipin KUMAR <vipin.kumar@xxxxxx>, Deepak SIKRI <deepak.sikri@xxxxxx>, Vipul Kumar SAMAR <vipulkumar.samar@xxxxxx>, Amit VIRDI <Amit.VIRDI@xxxxxx>, Pratyush ANAND <pratyush.anand@xxxxxx>, Bhupesh SHARMA <bhupesh.sharma@xxxxxx>, Bhavna YADAV <bhavna.yadav@xxxxxx>, Vincenzo FRASCINO <Vincenzo.FRASCINO@xxxxxx>, Mirko GARDI <mirko.gardi@xxxxxx>, Salvatore DE DOMINICIS <salvatore.dedominicis@xxxxxx>, "linux-i2c@xxxxxxxxxxxxxxx" <linux-i2c@xxxxxxxxxxxxxxx>
- In-reply-to: <4F4E118B.2030403@nvidia.com>
- References: <0ca1d8990c23a45193a32d0e7e889620b995af59.1330082915.git.viresh.kumar@st.com> <351031347b845920a0ea78e7491d955137e3d7aa.1330082915.git.viresh.kumar@st.com> <CAM=Q2cudYcSqAKk4qNg7MQxRBCkJ-XXXSL-Bg=sZ2+hvS_Qcxw@mail.gmail.com> <4F4B3072.6050903@nvidia.com> <CAM=Q2cs-nCuSmkBFtv4odbqoRJcPkXk4Rz-H=9S6RDG3Z8kcEQ@mail.gmail.com> <4F4B569F.3080607@st.com> <4F4B5A9A.4050303@st.com> <CAOh2x=nfNGpBmHVd1bPT9+AezDMEjaC4ktj4hX9=yWg2_k7r3Q@mail.gmail.com> <4F4E118B.2030403@nvidia.com>
- User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
On 2/29/2012 5:22 PM, Laxman Dewangan wrote:
> On Tuesday 28 February 2012 06:53 PM, viresh kumar wrote:
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> +static int i2c_gpio_recover_bus(struct i2c_adapter *adap)
>> +{
>> + int tmp, val = 1;
>> + unsigned long delay = 1000000;
>> +
>> + tmp = gpio_request_one(adap->scl_gpio, GPIOF_DIR_OUT |
>> + GPIOF_INIT_LOW, "i2c-bus-recover");
>
> Should rename tmp to ret or status. tmp does not looks appropriate.
>
Ok.
>> + if (tmp< 0) {
>> + dev_warn(&adap->dev, "gpio request one fail: %d\n",
>> + adap->scl_gpio);
>> + return tmp;
>> + }
>> +
>> + delay /= adap->clock_rate * 2;
> Here delay is turning as micor sec and function used as the nano sec.
clock_rate is in KHz, mentioned in comment of clock_rate.
Makes sense now or am i missing something?
>> +
>> + for (tmp = 0; tmp< adap->clock_cnt * 2; tmp++, val = !val) {
>> + ndelay(delay);
> should be udelay()?
Please add blank lines before and after your comment. That makes
it more readable.
>> + gpio_set_value(adap->scl_gpio, val);
>
> I think it should check for the sda line for coming out of the loop.
> There may be possibility that we may not need 9 clock pulses.
>
I asked this in another mail, how to be sure that it will work.
>> + u8 scl_gpio;
> gpio can be more than 256. better to use int.
> Take scl_gpio_flag and use in the gpio_request_one.
Ok.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[LM Sensors]
[Linux USB Devel]
[Linux Media]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]