Re: [PATCH V4 1/2] i2c/adapter: Add bus recovery infrastructure

2012-07-27 Thread Shubhrajyoti Datta
Hi Viresh ,
On Fri, May 4, 2012 at 3:10 PM, Viresh Kumar  wrote:
> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> protocol Rev. 03 section 3.16 titled "Bus clear".
>
> http://www.nxp.com/documents/user_manual/UM10204.pdf
>
> Sometimes during operation i2c bus hangs and we need to give dummy clocks to
> slave device to start the transfer again. Now we may have capability in the 
> bus
> controller to generate these clocks or platform may have gpio pins which can 
> be
> toggled to generate dummy clocks. This patch supports both.
>
> This patch also adds in generic bus recovery routines gpio or scl line based
> which can be used by bus controller. In addition controller driver may provide
> its own version of the bus recovery routine.
>
A few suggestions.

1. Bus recovery should ideally handle both SCL and SDA stuck a 0
   conditions. This only appears to handle SDA. For SCL stuck at 0 we
   need to reset the slave if possible. So maybe there needs to be the
   ability to register a slave reset handler (if this does not exist).
2. Following on from #1, there should be the ability to query the state
   of SCL and SDA if the controller supports this. For example, on OMAP
   we can query whether SCL or SDA are stuck low when the timeout
   occurs. Then based upon whether SCL or SDA are stuck, we either try
   the appropriate bus recovery. If there is no mechanism to query SCL
   or SDA, then we need to decide on the appropriate behaviour. For
   example, should we try the workaround for SDA stuck first as it is
   less severe and if that fails try the SCL workaround if a reset
   handler is registered to reset the device.

. What do we do if the recovery does not work after N attempts? Is
   this handled? If not after a certain number of failures it may be
   necessary to unregister the slave.Or if the slave supports reset
can we contemplate or if it is powered by gpio can we reset it.

What do you think
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/2] i2c/adapter: Add bus recovery infrastructure

2012-07-18 Thread Shubhrajyoti Datta
Hi Viresh,

On Fri, May 4, 2012 at 3:10 PM, Viresh Kumar  wrote:
> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> protocol Rev. 03 section 3.16 titled "Bus clear".
>
> http://www.nxp.com/documents/user_manual/UM10204.pdf
>
> Sometimes during operation i2c bus hangs and we need to give dummy clocks to
> slave device to start the transfer again. Now we may have capability in the 
> bus
> controller to generate these clocks or platform may have gpio pins which can 
> be
> toggled to generate dummy clocks. This patch supports both.
>
> This patch also adds in generic bus recovery routines gpio or scl line based
> which can be used by bus controller. In addition controller driver may provide
> its own version of the bus recovery routine.
>

It might me worth how was this tested?
Was both the approaches given a try?
Also it might help if one of the drivers currently doing it is
ported to the framework.

Just a suggestion not an objection to the patch.

> Signed-off-by: Viresh Kumar 
> ---
>  Documentation/i2c/bus-recovery |   87 ++
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/2] i2c/adapter: Add bus recovery infrastructure

2012-07-16 Thread viresh kumar
On Mon, Jul 2, 2012 at 12:08 PM, Shiraz Hashim  wrote:
> Any chance of this passing through your tree, as we are
> dependent on this.

Ping !!
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/2] i2c/adapter: Add bus recovery infrastructure

2012-07-02 Thread Shiraz Hashim
Hi Wolfram,

On Wed, Jun 13, 2012 at 10:03:48AM +0100, viresh kumar wrote:
> On Tue, May 15, 2012 at 7:58 AM, Viresh Kumar  wrote:
> > On 5/4/2012 3:10 PM, Viresh KUMAR wrote:
> >> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> >> protocol Rev. 03 section 3.16 titled "Bus clear".
> >>
> >> http://www.nxp.com/documents/user_manual/UM10204.pdf
> >>
> >> Sometimes during operation i2c bus hangs and we need to give dummy clocks 
> >> to
> >> slave device to start the transfer again. Now we may have capability in 
> >> the bus
> >> controller to generate these clocks or platform may have gpio pins which 
> >> can be
> >> toggled to generate dummy clocks. This patch supports both.
> >>
> >> This patch also adds in generic bus recovery routines gpio or scl line 
> >> based
> >> which can be used by bus controller. In addition controller driver may 
> >> provide
> >> its own version of the bus recovery routine.
> >>
> >> Signed-off-by: Viresh Kumar 
> >> ---
> >>  Documentation/i2c/bus-recovery |   87 ++
> >>  drivers/i2c/i2c-core.c         |  160 
> >> 
> >>  drivers/i2c/i2c-mux.c          |    9 ++-
> >>  include/linux/i2c.h            |   58 ++
> >>  4 files changed, 313 insertions(+), 1 deletions(-)
> >>  create mode 100644 Documentation/i2c/bus-recovery
> >
> > Hi Wolfram,
> >
> > Any inputs on this patch.
> 
> Ping.

Any chance of this passing through your tree, as we are
dependent on this.

--
regards
Shiraz
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/2] i2c/adapter: Add bus recovery infrastructure

2012-06-13 Thread viresh kumar
On Tue, May 15, 2012 at 7:58 AM, Viresh Kumar  wrote:
> On 5/4/2012 3:10 PM, Viresh KUMAR wrote:
>> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
>> protocol Rev. 03 section 3.16 titled "Bus clear".
>>
>> http://www.nxp.com/documents/user_manual/UM10204.pdf
>>
>> Sometimes during operation i2c bus hangs and we need to give dummy clocks to
>> slave device to start the transfer again. Now we may have capability in the 
>> bus
>> controller to generate these clocks or platform may have gpio pins which can 
>> be
>> toggled to generate dummy clocks. This patch supports both.
>>
>> This patch also adds in generic bus recovery routines gpio or scl line based
>> which can be used by bus controller. In addition controller driver may 
>> provide
>> its own version of the bus recovery routine.
>>
>> Signed-off-by: Viresh Kumar 
>> ---
>>  Documentation/i2c/bus-recovery |   87 ++
>>  drivers/i2c/i2c-core.c         |  160 
>> 
>>  drivers/i2c/i2c-mux.c          |    9 ++-
>>  include/linux/i2c.h            |   58 ++
>>  4 files changed, 313 insertions(+), 1 deletions(-)
>>  create mode 100644 Documentation/i2c/bus-recovery
>
> Hi Wolfram,
>
> Any inputs on this patch.

Ping.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/2] i2c/adapter: Add bus recovery infrastructure

2012-05-14 Thread Viresh Kumar
On 5/4/2012 3:10 PM, Viresh KUMAR wrote:
> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> protocol Rev. 03 section 3.16 titled "Bus clear".
> 
> http://www.nxp.com/documents/user_manual/UM10204.pdf
> 
> Sometimes during operation i2c bus hangs and we need to give dummy clocks to
> slave device to start the transfer again. Now we may have capability in the 
> bus
> controller to generate these clocks or platform may have gpio pins which can 
> be
> toggled to generate dummy clocks. This patch supports both.
> 
> This patch also adds in generic bus recovery routines gpio or scl line based
> which can be used by bus controller. In addition controller driver may provide
> its own version of the bus recovery routine.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  Documentation/i2c/bus-recovery |   87 ++
>  drivers/i2c/i2c-core.c |  160 
> 
>  drivers/i2c/i2c-mux.c  |9 ++-
>  include/linux/i2c.h|   58 ++
>  4 files changed, 313 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/i2c/bus-recovery

Hi Wolfram,

Any inputs on this patch.

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V4 1/2] i2c/adapter: Add bus recovery infrastructure

2012-05-04 Thread Viresh Kumar
Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
protocol Rev. 03 section 3.16 titled "Bus clear".

http://www.nxp.com/documents/user_manual/UM10204.pdf

Sometimes during operation i2c bus hangs and we need to give dummy clocks to
slave device to start the transfer again. Now we may have capability in the bus
controller to generate these clocks or platform may have gpio pins which can be
toggled to generate dummy clocks. This patch supports both.

This patch also adds in generic bus recovery routines gpio or scl line based
which can be used by bus controller. In addition controller driver may provide
its own version of the bus recovery routine.

Signed-off-by: Viresh Kumar 
---
 Documentation/i2c/bus-recovery |   87 ++
 drivers/i2c/i2c-core.c |  160 
 drivers/i2c/i2c-mux.c  |9 ++-
 include/linux/i2c.h|   58 ++
 4 files changed, 313 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/i2c/bus-recovery

diff --git a/Documentation/i2c/bus-recovery b/Documentation/i2c/bus-recovery
new file mode 100644
index 000..518dff6
--- /dev/null
+++ b/Documentation/i2c/bus-recovery
@@ -0,0 +1,87 @@
+   I2C Bus Recovery
+   
+
+Problem:
+
+There is a generic issue with I2C transfers, where the SDA line is pulled down
+by the slave device and the controller isn't able to control SDA line anymore.
+
+Solution:
+=
+Following is specified in the i2c protocol Rev. 03 section 3.16 titled "Bus
+clear".
+
+http://www.nxp.com/documents/user_manual/UM10204.pdf
+
+If the data line (SDA) is stuck LOW, the master should send nine clock pulses.
+The device that held the bus LOW should release it sometime within those nine
+clocks. If not, then use the HW reset or cycle power to clear the bus.
+
+Implementation:
+==
+In order to fix this issue in Linux, bus recovery mechanism is added in
+i2c-core. The controller driver needs to do following to get recovery support
+from i2c-core:
+- Return -ETIMEDOUT from their master_xfer() callback if they are stuck, so 
that
+  core can try recovery. (Which can only be done if below is passed from
+  controller driver.)
+- Must fill Adapters bus_recovery_info field with valid recovery structure.
+
+/**
+ * struct i2c_bus_recovery_info - I2c bus recovery information
+ * @recover_bus: Recover routine. Either pass driver's recover_bus() routine, 
or
+ * pass it NULL to use generic ones, i.e. gpio or scl based.
+ * @skip_sda_polling: if true, bus recovery will not poll sda line to check if
+ * it became high or not. Only required if recover_bus == NULL.
+ * @is_gpio_recovery: true, select gpio type else scl type. Only required if
+ * recover_bus == NULL.
+ * @clock_rate_khz: clock rate of dummy clock in khz. Required for both gpio 
and
+ * scl type recovery.
+ * @clock_cnt: count of max clocks to be generated. Required for both gpio and
+ * scl type recovery.
+ * @set_scl: controller specific scl configuration routine. Only required if
+ * is_gpio_recovery == false
+ * @get_sda: controller specific sda read routine. Only required if
+ * is_gpio_recovery == false and skip_sda_polling == false.
+ * @gpio_recov: gpio recovery info, only if (is_gpio_recovery == true)
+ */
+struct i2c_bus_recovery_info {
+   int (*recover_bus)(struct i2c_adapter *);
+   bool skip_sda_polling;
+   bool is_gpio_recovery;
+   u32 clock_rate_khz;
+   u8 clock_cnt;
+
+   /* gpio recovery */
+   struct i2c_bus_gpio_recovery_info *gpio_recov;
+   /* scl/sda recovery */
+   void (*set_scl)(struct i2c_adapter *, int val);
+   int (*get_sda)(struct i2c_adapter *);
+};
+
+/**
+ * struct i2c_bus_gpio_recovery_info - I2c bus recovery information if recovery
+ * type is gpio.
+ * @get_gpio: called before recover_bus() to get padmux configured for scl 
line.
+ * as gpio.
+ * @put_gpio: called after recover_bus() to get padmux configured for scl line
+ * as scl.
+ * @scl_gpio: gpio number of the scl line.
+ * @sda_gpio: gpio number of the sda line.
+ * @scl_gpio_flags: flag for gpio_request_one of scl_gpio. 0 implies
+ * GPIOF_OUT_INIT_LOW.
+ * @sda_gpio_flags: flag for gpio_request_one of sda_gpio. 0 implies
+ * GPIOF_OUT_INIT_LOW.
+ */
+struct i2c_bus_gpio_recovery_info {
+   int (*get_gpio)(unsigned gpio);
+   int (*put_gpio)(unsigned gpio);
+   u32 scl_gpio;
+   u32 sda_gpio;
+   u32 scl_gpio_flags;
+   u32 sda_gpio_flags;
+};
+
+Author:
+===
+Viresh Kumar 
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a6ad32b..dc0e93d8 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -27,7 +27,9 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,6 +106,112 @@ static int i2c_device_uevent(struct device *dev, struct 
kobj_ueven