linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Bitton <pablo.bitton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Philby John <pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org>
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Subject: Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
Date: Mon, 13 Sep 2010 16:23:00 +0200	[thread overview]
Message-ID: <AANLkTimqT=xgoxycjFAwEr6LPTeK21-FB1F-7kP5baPE@mail.gmail.com> (raw)
In-Reply-To: <1264549293-25556-7-git-send-email-khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 7205 bytes --]

Hi Philby,

On Wed, Jan 27, 2010 at 1:41 AM, Kevin Hilman
<khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>wrote:

> From: Philby John <pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org>
>
> Come out of i2c time out condition by following the
> bus recovery procedure outlined in the i2c protocol v3 spec.
> The kernel must be robust enough to gracefully recover
> from i2c bus failure without having to reset the machine.
> This is done by first NACKing the slave, pulsing the SCL
> line 9 times and then sending the stop command.
>
> This patch has been tested on a DM6446 and DM355
>
> Signed-off-by: Philby John <pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org>
> Signed-off-by: Srinivasan, Nageswari <nageswari-l0cyMroinI0@public.gmane.org>
> Acked-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
> ---
>  drivers/i2c/busses/i2c-davinci.c |   57
> +++++++++++++++++++++++++++++++++++--
>  1 files changed, 53 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-davinci.c
> b/drivers/i2c/busses/i2c-davinci.c
> index 35f9daa..5459065 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -36,6 +36,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
>  #include <linux/cpufreq.h>
> +#include <linux/gpio.h>
>
>  #include <mach/hardware.h>
>  #include <mach/i2c.h>
> @@ -43,6 +44,7 @@
>  /* ----- global defines ----------------------------------------------- */
>
>  #define DAVINCI_I2C_TIMEOUT    (1*HZ)
> +#define DAVINCI_I2C_MAX_TRIES  2
>  #define I2C_DAVINCI_INTR_ALL    (DAVINCI_I2C_IMR_AAS | \
>                                 DAVINCI_I2C_IMR_SCD | \
>                                 DAVINCI_I2C_IMR_ARDY | \
> @@ -130,6 +132,44 @@ static inline u16 davinci_i2c_read_reg(struct
> davinci_i2c_dev *i2c_dev, int reg)
>        return __raw_readw(i2c_dev->base + reg);
>  }
>
> +/* Generate a pulse on the i2c clock pin. */
> +static void generic_i2c_clock_pulse(unsigned int scl_pin)
> +{
> +       u16 i;
> +
> +       if (scl_pin) {
> +               /* Send high and low on the SCL line */
> +               for (i = 0; i < 9; i++) {
> +                       gpio_set_value(scl_pin, 0);
> +                       udelay(20);
> +                       gpio_set_value(scl_pin, 1);
> +                       udelay(20);
> +               }
> +       }
> +}
> +
> +/* This routine does i2c bus recovery as specified in the
> + * i2c protocol Rev. 03 section 3.16 titled "Bus clear"
> + */
> +static void i2c_recover_bus(struct davinci_i2c_dev *dev)
> +{
> +       u32 flag = 0;
> +       struct davinci_i2c_platform_data *pdata = dev->dev->platform_data;
> +
> +       dev_err(dev->dev, "initiating i2c bus recovery\n");
> +       /* Send NACK to the slave */
> +       flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
> +       flag |=  DAVINCI_I2C_MDR_NACK;
> +       /* write the data into mode register */
> +       davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
> +       if (pdata)
> +               generic_i2c_clock_pulse(pdata->scl_pin);
> +       /* Send STOP */
> +       flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
> +       flag |= DAVINCI_I2C_MDR_STP;
> +       davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
> +}
> +
>  static inline void davinci_i2c_reset_ctrl(struct davinci_i2c_dev *i2c_dev,
>                                                                int val)
>  {
> @@ -235,14 +275,22 @@ static int i2c_davinci_wait_bus_not_busy(struct
> davinci_i2c_dev *dev,
>                                         char allow_sleep)
>  {
>        unsigned long timeout;
> +       static u16 to_cnt;
>
>        timeout = jiffies + dev->adapter.timeout;
>        while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
>               & DAVINCI_I2C_STR_BB) {
> -               if (time_after(jiffies, timeout)) {
> -                       dev_warn(dev->dev,
> -                                "timeout waiting for bus ready\n");
> -                       return -ETIMEDOUT;
> +               if (to_cnt <= DAVINCI_I2C_MAX_TRIES) {
> +                       if (time_after(jiffies, timeout)) {
> +                               dev_warn(dev->dev,
> +                               "timeout waiting for bus ready\n");
> +                               to_cnt++;
> +                               return -ETIMEDOUT;
> +                       } else {
> +                               to_cnt = 0;
> +                               i2c_recover_bus(dev);
> +                               i2c_davinci_init(dev);
> +                       }
>                }
>                if (allow_sleep)
>                        schedule_timeout(1);
>

The resulting loop has the following drawbacks:
1) If to_cnt reaches DAVINCI_I2C_MAX_TRIES+1 (which it currently can't, see
2) and the i2c bus collapses,
    the kernel will be stuck in the loop forever, especially if allow_sleep
is false.
2) The to_cnt static var never increments beyond 1. It's initialized to zero
and then kept at zero until the timeout expires.
    When the timeout expires, to_cnt is incremented once, until the next
call to the function, where it will be zeroed again.
 3) Do we really want to retry recovering the bus thousands of times, until
the timeout arrives?
    It seems to me that if the bus recovery procedure didn't help after one
or two tries, it probably never will.

I  also have the following nitpicks:
a) The timeout variable actually holds the finish time.
b) The i2c_recover_bus function uses dev_err to report a bus recovery
process,
    but if all recovery attempts failed and the timeout was reached, only
dev_warn is used to report the timeout.

Other than that the patch is very helpful, thanks a lot.

Below is my suggestion for the wait_bus_not_busy function. My patch has been
tested on a DM6446.

Signed-off-by: Pablo Bitton <pablo.bitton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--

diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c

@@ -220,16 +261,24 @@ static int i2c_davinci_init(struct davinci_i2c_dev
*dev)
 static int i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev,
                               char allow_sleep)
 {
-     unsigned long timeout;
+     unsigned long finish_time;
+     unsigned long to_cnt = 0;

-     timeout = jiffies + dev->adapter.timeout;
+     finish_time = jiffies + dev->adapter.timeout;
+     /* While bus busy */
      while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
             & DAVINCI_I2C_STR_BB) {
-           if (time_after(jiffies, timeout)) {
+           if (time_after(jiffies, finish_time)) {
                  dev_warn(dev->dev,
                         "timeout waiting for bus ready\n");
                  return -ETIMEDOUT;
            }
+           else if (to_cnt <= DAVINCI_I2C_MAX_TRIES) {
+                 dev_warn(dev->dev, "bus busy, performing bus recovery\n");
+                   ++to_cnt;
+                       i2c_recover_bus(dev);
+                       i2c_davinci_init(dev);
+           }
            if (allow_sleep)
                  schedule_timeout(1);
      }

[-- Attachment #1.2: Type: text/html, Size: 10491 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2010-09-13 14:23 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-26 23:41 [PATCH 0/6] davinci i2c updates for 2.6.34 Kevin Hilman
     [not found] ` <1264549293-25556-1-git-send-email-khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2010-01-26 23:41   ` [PATCH 1/6] i2c: davinci: Fix smbus Oops with AIC33 usage Kevin Hilman
     [not found]     ` <026601ca9f54$17a18110$46e48330$@raj@ti.com>
     [not found]       ` <026601ca9f54$17a18110$46e48330$@raj-l0cyMroinI0@public.gmane.org>
2010-01-27 14:50         ` Kevin Hilman
     [not found]           ` <87k4v3y53z.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2010-01-28  4:05             ` Sudhakar Rajashekhara
2010-01-28  8:46             ` Sudhakar Rajashekhara
     [not found]           ` <02ee01ca9ff6$53cf0d90$fb6d28b0$@raj@ti.com>
     [not found]             ` <02ee01ca9ff6$53cf0d90$fb6d28b0$@raj-l0cyMroinI0@public.gmane.org>
2010-01-28 14:45               ` Kevin Hilman
     [not found]     ` <1264549293-25556-2-git-send-email-khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2010-01-27 13:24       ` Sudhakar Rajashekhara
2010-01-27 15:03       ` Ben Dooks
2010-01-26 23:41   ` [PATCH 2/6] i2c: davinci: Remove MOD_REG_BIT and IO_ADDRESS usage Kevin Hilman
     [not found]     ` <1264549293-25556-3-git-send-email-khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2010-01-27 15:05       ` Ben Dooks
     [not found]         ` <20100127150518.GB6090-elnMNo+KYs3pIgCt6eIbzw@public.gmane.org>
2010-01-29 19:46           ` Kevin Hilman
2010-01-26 23:41   ` [PATCH 3/6] i2c: davinci: Add helper functions Kevin Hilman
2010-01-26 23:41   ` [PATCH 4/6] i2c: davinci: Add suspend/resume support Kevin Hilman
2010-01-26 23:41   ` [PATCH 5/6] i2c: davinci: Add cpufreq support Kevin Hilman
2010-01-26 23:41   ` [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus Kevin Hilman
     [not found]     ` <1264549293-25556-7-git-send-email-khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2010-02-01  5:57       ` Nori, Sekhar
     [not found]         ` <B85A65D85D7EB246BE421B3FB0FBB59301E235A3C2-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2010-02-01 19:40           ` Kevin Hilman
2010-02-05 13:53           ` Philby John
     [not found]             ` <225d086e1002050553tc1a696avce827cc115f56b1c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-02-08 10:35               ` Nori, Sekhar
     [not found]                 ` <B85A65D85D7EB246BE421B3FB0FBB59301E2639AD8-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2010-02-08 10:50                   ` Philby John
2010-02-08 15:13                   ` Philby John
     [not found]                     ` <4B702A17.3070104-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
2010-02-08 16:03                       ` Nori, Sekhar
     [not found]                         ` <B85A65D85D7EB246BE421B3FB0FBB59301E2639D67-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2010-02-09 10:15                           ` Philby John
     [not found]                             ` <4B7135B3.9080104-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
2010-02-09 10:52                               ` Nori, Sekhar
     [not found]                                 ` <B85A65D85D7EB246BE421B3FB0FBB59301E263A447-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2010-03-05 15:20                                   ` Griffis, Brad
     [not found]                                     ` <F8C55F6A02E92D48BDDFC6048552C6F14E6D9F3F-lTKHBJngVwKIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2010-03-08 13:37                                       ` Philby John
     [not found]                                         ` <4B94FD84.3060100-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
2010-03-11 16:28                                           ` Griffis, Brad
2010-03-08 13:36                   ` Philby John
     [not found]                     ` <4B94FD6F.7050603-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
2010-03-16 20:50                       ` Kevin Hilman
     [not found]                         ` <87d3z4xa7m.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2010-03-17 11:28                           ` Philby John
     [not found]                             ` <4BA0BCEC.8040209-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
2010-03-17 13:18                               ` Nori, Sekhar
     [not found]                                 ` <B85A65D85D7EB246BE421B3FB0FBB59301E6328944-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2010-03-17 13:46                                   ` Philby John
2010-09-13 14:23       ` Pablo Bitton [this message]
     [not found]         ` <AANLkTimqT=xgoxycjFAwEr6LPTeK21-FB1F-7kP5baPE-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-09-27 12:40           ` Philby John
  -- strict thread matches above, loose matches on Subject: below --
2010-04-06 17:42 [PATCH 0/6] i2c: davinci updates for 2.6.35 Kevin Hilman
     [not found] ` <1270575738-22388-1-git-send-email-khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2010-04-06 17:42   ` [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus Kevin Hilman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTimqT=xgoxycjFAwEr6LPTeK21-FB1F-7kP5baPE@mail.gmail.com' \
    --to=pablo.bitton-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).