On Tue, Sep 23, 2014 at 3:05 AM, Mika Westerberg
wrote:
> arch/arm/boot/dts/spear1310.dtsi
> arch/arm/boot/dts/spear320.dtsi
> arch/arm/boot/dts/spear3xx.dtsi
> arch/arm/boot/dts/spear600.dtsi
>
> I think we are good to go with the first three but not sure about the
> las
On 17 June 2013 18:46, Viresh Kumar wrote:
> Add bus recovery support for designware_i2c controller. It uses generic gpio
> based i2c_gpio_recover_bus() routine. Platforms need to pass struct
> i2c_bus_recovery_info as platform data to designware I2C controller.
>
> Signed-o
: Viresh Kumar
---
This patch isn't drawing attention since sometime, so sending it again.
drivers/i2c/busses/i2c-designware-core.c| 5 -
drivers/i2c/busses/i2c-designware-platdrv.c | 6 ++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-desig
On 13 May 2013 14:48, Viresh Kumar wrote:
> On 5 April 2013 12:12, Viresh Kumar wrote:
>> Hi Wolfram,
>>
>> On 25 January 2013 15:17, Viresh Kumar wrote:
>>> Add bus recovery support for designware_i2c controller. It uses generic gpio
>>> based i2c_gpio_r
On 5 April 2013 12:12, Viresh Kumar wrote:
> Hi Wolfram,
>
> On 25 January 2013 15:17, Viresh Kumar wrote:
>> Add bus recovery support for designware_i2c controller. It uses generic gpio
>> based i2c_gpio_recover_bus() routine. Platforms need to pass struct
>> i2c_bu
Hi Wolfram,
On 25 January 2013 15:17, Viresh Kumar wrote:
> Add bus recovery support for designware_i2c controller. It uses generic gpio
> based i2c_gpio_recover_bus() routine. Platforms need to pass struct
> i2c_bus_recovery_info as platform data to designware I2C controller.
>
>
fix.
>
> Signed-off-by: Arnd Bergmann
> Cc: Viresh Kumar
> Cc: linux-i2c@vger.kernel.org
> Cc: davinci-linux-open-sou...@linux.davincidsp.com
> Cc: Wolfram Sang
> Cc: Ben Dooks
Acked-by: Viresh Kumar
But i believe this stuff should be updated to use the generic recover
On 24 March 2013 19:37, Viresh Kumar wrote:
> On 21 March 2013 15:06, Wolfram Sang wrote:
>> I applied V11 of the core changes with minor modifications. I do wonder
>
> I can't find it linux-next or here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
On 21 March 2013 15:06, Wolfram Sang wrote:
> I applied V11 of the core changes with minor modifications. I do wonder
I can't find it linux-next or here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the bod
On 21 March 2013 15:06, Wolfram Sang wrote:
> I applied V11 of the core changes with minor modifications.
Wow!! Thanks.
> I do wonder
> about the hook in the designware driver. You apply the recovery on
> transfer timeout. I think this should go into the timeout of
> i2c_dw_wait_bus_not_busy()?
Fixing Wolfram's email id.
On 15 March 2013 14:21, Viresh Kumar wrote:
> On 31 January 2013 07:58, Viresh Kumar wrote:
>> On 26 January 2013 10:43, Viresh Kumar wrote:
>>> I have looked them again and attached are the final patches.
>>> Following are the imp
On 31 January 2013 07:58, Viresh Kumar wrote:
> On 26 January 2013 10:43, Viresh Kumar wrote:
>> I have looked them again and attached are the final patches.
>> Following are the improvements i have:
>>
>> Author: Viresh Kumar
>> Date: Sat Jan 26 10:31:4
On 26 January 2013 10:43, Viresh Kumar wrote:
> I have looked them again and attached are the final patches.
> Following are the improvements i have:
>
> Author: Viresh Kumar
> Date: Sat Jan 26 10:31:42 2013 +0530
>
> fixup! i2c/adapter: Add bus recovery infrastruct
attached are the final patches.
Following are the improvements i have:
Author: Viresh Kumar
Date: Sat Jan 26 10:31:42 2013 +0530
fixup! i2c/adapter: Add bus recovery infrastructure
---
drivers/i2c/i2c-core.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff
On 25 January 2013 15:17, Viresh Kumar wrote:
> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> protocol Rev. 03 section 3.1.16 titled "Bus clear".
>
> http://www.nxp.com/documents/user_manual/UM10204.pdf
>
> Sometimes during operation
roller. In addition controller driver may provide
its own version of the bus recovery routine.
This doesn't support multi-master recovery for now.
Reviewed-by: Paul Carpenter
Signed-off-by: Viresh Kumar
---
V9->V10:
- Check sda value at the begining of loop to guarantee that we are not t
: Viresh Kumar
---
V9->V10: None
drivers/i2c/busses/i2c-designware-core.c| 5 -
drivers/i2c/busses/i2c-designware-platdrv.c | 6 ++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
in
On 25 January 2013 14:45, Wolfram Sang wrote:
> On Thu, Jan 24, 2013 at 04:06:37PM +0530, Viresh Kumar wrote:
>> +static int i2c_generic_recovery(struct i2c_adapter *adap)
>> +{
>> + struct i2c_bus_recovery_info *bri = adap->bus_recovery_info;
>> +
On 25 January 2013 14:20, Wolfram Sang wrote:
>> I kept it to make sure we don't do this calculation every time... I would
>> like
>> to keep it for better performance..
>
> Please move it. It is a constant anyhow, and globals are best avoided.
I will move it. But i couldn't understand what you
On 24 January 2013 17:13, Uwe Kleine-König
wrote:
> On Thu, Jan 24, 2013 at 04:47:53PM +0530, Viresh Kumar wrote:
>> So, the whole loop is for 9 pulses at max and it runs 18 times. Twice per
>> clock. With my code, i only check for sda after supplying full clock pulse,
>> and
On 24 January 2013 16:36, Uwe Kleine-König
wrote:
> On Thu, Jan 24, 2013 at 04:06:37PM +0530, Viresh Kumar wrote:
>> Most number of versions for any patchset i submitted :)
> So let's see if you do a v10 ... :-)
Haha..
>> +static int i2c_generic_recovery(s
On 24 January 2013 16:24, Uwe Kleine-König
wrote:
> On Thu, Jan 24, 2013 at 08:24:45AM +0100, Wolfram Sang wrote:
> Some more comments below.
Always welcomed :)
>> * if (val && bri->get_sda)
>>
>> > + /* Check SCL again to see fault condition */
>> > + if (!br
On 24 January 2013 16:06, Viresh Kumar wrote:
> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> protocol Rev. 03 section 3.1.16 titled "Bus clear".
>
> http://www.nxp.com/documents/user_manual/UM10204.pdf
>
> Sometimes during operation
: Viresh Kumar
---
V8->V9:
- Use i2c_recover_bus()
- simplified dw_i2c_probe() for bus recovery code
- removed floating kfree()'s of adap->bus_recovery_info
drivers/i2c/busses/i2c-designware-core.c| 5 -
drivers/i2c/busses/i2c-designware-platdrv.c | 6 ++
2 files changed, 10
roller. In addition controller driver may provide
its own version of the bus recovery routine.
This doesn't support multi-master recovery for now.
Reviewed-by: Paul Carpenter
Signed-off-by: Viresh Kumar
---
Most number of versions for any patchset i submitted :)
V8->V9:
- removed skip_sd
On 24 January 2013 12:54, Wolfram Sang wrote:
> Hi Viresh,
Hi Wolfram
> I think we are getting close.
Wow!!
> On Mon, Dec 03, 2012 at 08:24:04AM +0530, Viresh Kumar wrote:
>> This doesn't support multi-master recovery for now.
>
> Assuming that recover_bus is not
On 24 January 2013 12:54, Wolfram Sang wrote:
> On Mon, Dec 03, 2012 at 08:24:05AM +0530, Viresh Kumar wrote:
>> @@ -538,7 +538,11 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
>> msgs[], int num)
>> ret = wait_for_completion_interruptible_timeout(&
On 7 January 2013 16:02, Viresh Kumar wrote:
> On 20 December 2012 14:47, Viresh Kumar wrote:
>> On 19 December 2012 05:30, Wolfram Sang wrote:
>>> Since I missed the things Paul luckily spotted, I think it might make
>>> sense to actually use the framework myself
On 20 December 2012 14:47, Viresh Kumar wrote:
> On 19 December 2012 05:30, Wolfram Sang wrote:
>> Since I missed the things Paul luckily spotted, I think it might make
>> sense to actually use the framework myself to get me a better feeling
>> that I have not missed an
On 19 December 2012 05:30, Wolfram Sang wrote:
> Since I missed the things Paul luckily spotted, I think it might make
> sense to actually use the framework myself to get me a better feeling
> that I have not missed anything else. So, I am going to add support for
> another I2C master controller t
On 7 December 2012 02:00, Paul Carpenter
wrote:
> OK by me
>
> Reviewed-by: Paul Carpenter
Are you taking it for 3.8 now?
--
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/m
On 6 December 2012 21:28, Paul Carpenter
wrote:
> Nothing more from me. I will keep quiet now :-)
As you have invested some effort in reviewing it, you want to give your
Reviewed-by?
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger
On 3 December 2012 08:24, Viresh Kumar wrote:
> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> protocol Rev. 03 section 3.1.16 titled "Bus clear".
>
> http://www.nxp.com/documents/user_manual/UM10204.pdf
>
> Sometimes during operation
Add bus recovery support for designware_i2c controller. It uses generic gpio
based i2c_gpio_recover_bus() routine. Platforms need to pass struct
i2c_bus_recovery_info as platform data designware I2C controller.
Signed-off-by: Vincenzo Frascino
Signed-off-by: Shiraz Hashim
Signed-off-by: Viresh
roller. In addition controller driver may provide
its own version of the bus recovery routine.
This doesn't support multi-master recovery for now.
Signed-off-by: Viresh Kumar
---
V7->V8:
- Clk rate fixed to 100KHz
- Check SCL line to see if it is LOW due to some faults
- removed last us
Hi Wolfram/Paul,
I have tried to fix my patches as per review comments from you.
Following is diff of the new changes i have made, I am sending a
new complete version separately:
commit 62cf40359c63ac028b3e8a6395f9440f6a3b0162
Author: Viresh Kumar
Date: Mon Dec 3 08:12:55 2012 +0530
On 27 November 2012 01:50, Uwe Kleine-König
wrote:
> In reply to a more detailed problem report that should be addressed by
> this series on spear-devel I asked a few questions to rule out 6/ and
> 7/. I cannot find it in an public accessible archive though. It's about
> a sta529 codec. When switc
On 26 November 2012 18:58, Paul Carpenter
wrote:
>>> +ret = gpio_request_one(bri->scl_gpio, GPIOF_OPEN_DRAIN |
>>> +GPIOF_OUT_INIT_HIGH, "i2c-scl");
>>
>>I always get wary of people driving I2C with non-open-drain, especially
>>with stuck busses
>
> I would want to know what "GPIOF
On 26 November 2012 17:15, Paul Carpenter
wrote:
> Unless you know why the bus is stuck, how can you reset reminder this
> method ONLY works if SCL is high and SDA probably was low and the slave
> device is what is stuck in wrong state. NOTE SCL and SDA high can be
> considered as BUS IDLE or havi
On 25 November 2012 17:22, Paul Carpenter
wrote:
> Viresh Kumar wrote:
>> Add i2c bus recovery infrastructure to i2c adapters as specified in the
>> i2c
>> protocol Rev. 03 section 3.1.16 titled "Bus clear".
>>
>> http://www.nxp.com/documents/user_manua
Add bus recovery support for designware_i2c controller. It uses generic gpio
based i2c_gpio_recover_bus() routine. Platforms need to pass struct
i2c_bus_recovery_info as platform data designware I2C controller.
Signed-off-by: Vincenzo Frascino
Signed-off-by: Shiraz Hashim
Signed-off-by: Viresh
roller. In addition controller driver may provide
its own version of the bus recovery routine.
This doesn't support multi-master recovery for now.
Signed-off-by: Viresh Kumar
---
Hi Wolfram,
I am sending V7 before closing our comments completely on V6 (Very few are left
now :) ), so that
On 25 November 2012 02:33, Wolfram Sang wrote:
>> diff --git a/drivers/i2c/busses/i2c-designware-core.c
>> b/drivers/i2c/busses/i2c-designware-core.c
>> @@ -538,7 +538,12 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
>> msgs[], int num)
>> ret = wait_for_completion_interruptible
Hi Wolfram,
Thanks for sharing your opinion.
On 25 November 2012 02:29, Wolfram Sang wrote:
> On Thu, Oct 04, 2012 at 04:34:53PM +0530, Viresh Kumar wrote:
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> +static int i2c_get_gpios_for_recovery(struct i2
On 19 October 2012 19:03, Viresh Kumar wrote:
> On 4 October 2012 16:34, Viresh Kumar wrote:
>> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
>> protocol Rev. 03 section 3.1.16 titled "Bus clear".
>>
>> http://www.nxp.
On 4 October 2012 16:34, Viresh Kumar wrote:
> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> protocol Rev. 03 section 3.1.16 titled "Bus clear".
>
> http://www.nxp.com/documents/user_manual/UM10204.pdf
>
> Sometimes during operation
Add bus recovery support for designware_i2c controller. It uses generic gpio
based i2c_gpio_recover_bus() routine.
Signed-off-by: Vincenzo Frascino
Signed-off-by: Shiraz Hashim
Signed-off-by: Viresh Kumar
---
V5->V6:
- removed sda_gpio_flags
drivers/i2c/busses/i2c-designware-core.c|
roller. In addition controller driver may provide
its own version of the bus recovery routine.
This doesn't support multi-master recovery for now.
Signed-off-by: Viresh Kumar
---
V5->V6:
- Removed sda_gpio_flags
- Make scl_gpio_flags as GPIOF_OPEN_DRAIN | GPIOF_OUT_INIT_HIGH by default
- u
On 4 October 2012 13:30, Uwe Kleine-König
wrote:
Hi Uwe,
Please see if following fixup looks fine to you:
fixup! i2c/adapter: Add bus recovery infrastructure
---
drivers/i2c/i2c-core.c | 33 ++---
include/linux/i2c.h| 22 --
2 files chan
On 4 October 2012 15:17, Uwe Kleine-König
wrote:
> On Thu, Oct 04, 2012 at 03:02:26PM +0530, Viresh Kumar wrote:
>> On 4 October 2012 14:50, Uwe Kleine-König
>> wrote:
>>
>> >> So, we actually need to do "Low-High" 9 times instead of "High-Low
On 4 October 2012 14:50, Uwe Kleine-König
wrote:
>> So, we actually need to do "Low-High" 9 times instead of "High-Low".
>> So, initializing val to 0 should fix it?
> I don't think this is enough. If you cut off the last half clock of the
> first sequence above doing 9 times low-high isn't enough
On 4 October 2012 13:30, Uwe Kleine-König
wrote:
> On Fri, Sep 28, 2012 at 04:58:43PM +0530, Viresh Kumar wrote:
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> +static inline void set_scl_value(struct i2c_adapter *adap, int val)
>> +{
>> + s
On 28 September 2012 16:58, Viresh Kumar wrote:
> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
> protocol Rev. 03 section 3.1.16 titled "Bus clear".
>
> http://www.nxp.com/documents/user_manual/UM10204.pdf
>
> Sometimes during operation
On 28 September 2012 12:30, Wolfram Sang wrote:
> I am trying to have another I2C weekend this weekend. And your patches
> have been scheduled for that. The generic feeling is:
>
> Very useful but the interface could probably be simplified. This is why
> it takes me so long, working on interfaces
From: Viresh Kumar
Add bus recovery support for designware_i2c controller. It uses generic gpio
based i2c_gpio_recover_bus() routine.
Signed-off-by: Vincenzo Frascino
Signed-off-by: Shiraz Hashim
Signed-off-by: Viresh Kumar
---
drivers/i2c/busses/i2c-designware-core.c| 7 -
drivers
From: Viresh Kumar
Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
protocol Rev. 03 section 3.1.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
On 28 September 2012 12:57, Uwe Kleine-König
wrote:
> Why do you default to GPIOF_OUT_INIT_LOW? The idle state of scl is high.
> Using low here introduces an additional clk pulse.
Went deep into the code i wrote ages ago to check why i did so :)
My initial idea was, because the idle state of scl
On 28 September 2012 13:06, Viresh Kumar wrote:
>> Why do you default to GPIOF_OUT_INIT_LOW? The idle state of scl is high.
>> Using low here introduces an additional clk pulse.
>
> We aren't giving any clock pulses to scl line. Are you talking about sda?
My fault... we ar
Hi Uwe,
On 28 September 2012 12:57, Uwe Kleine-König
wrote:
> On Fri, Sep 28, 2012 at 09:11:34AM +0530, viresh kumar wrote:
>> This was done, because few platforms may not have configuration bits to read
>> status of sda line.. For them skip_sda_polling was required.
>>
>
On 28 September 2012 12:30, Wolfram Sang wrote:
> I am trying to have another I2C weekend this weekend. And your patches
> have been scheduled for that. The generic feeling is:
>
> Very useful but the interface could probably be simplified. This is why
> it takes me so long, working on interfaces
Finally somebody had a look at this poor fellow :)
On Thu, Sep 27, 2012 at 7:58 PM, Uwe Kleine-König
wrote:
> On Mon, Aug 27, 2012 at 10:41:26AM +0530, Viresh Kumar wrote:
>> From: Viresh Kumar
>>
>> Add i2c bus recovery infrastructure to i2c adapters as specified in the i2
From: Viresh Kumar
Add bus recovery support for designware_i2c controller. It uses generic gpio
based i2c_gpio_recover_bus() routine.
Signed-off-by: Vincenzo Frascino
Signed-off-by: Shiraz Hashim
Signed-off-by: Viresh Kumar
---
drivers/i2c/busses/i2c-designware-core.c| 7 -
drivers
From: 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
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:/
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.
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 b
From: Viresh Kumar
With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
macros.
pxa i2c also has these dummy macros defined locally. Remove them as they aren't
required anymore.
Signed-o
Add bus recovery support for designware_i2c controller. It uses generic gpio
based i2c_gpio_recover_bus() routine.
Signed-off-by: Vincenzo Frascino
Signed-off-by: Shiraz Hashim
Signed-off-by: Viresh Kumar
---
drivers/i2c/busses/i2c-designware-core.c|1 -
drivers/i2c/busses/i2c
lear names to them
- few prints changed to dev_dbg
V2->V3:
- gpio flags are now passed from controller drivers
- added support for sda line polling
- Aligned i2c-designware driver with generic recovery support
Viresh Kumar (2):
i2c/adapter: Add bus recovery infrastructure
i2c/designw
roller. 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
From: Viresh Kumar
With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
macros.
pxa i2c also has these dummy macros defined locally. Remove them as they aren't
required anymore.
Signed-o
On 4/23/2012 12:08 AM, Wolfram Sang wrote:
> Okay, thanks, both applied to next. If you mention dependencies somewhere
> when submitting, that might speed things, a tiny bit at least.
I normally do this. But forgot it this time myself too, that this patch
had a dependency :(
--
viresh
--
To unsu
On Mon, Apr 23, 2012 at 6:26 PM, Wolfram Sang wrote:
> On Fri, Mar 02, 2012 at 11:53:42AM +0530, Viresh Kumar wrote:
> Finally, a review \o/
:)
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> +/* i2c bus recovery routines */
>> +static int i2c
On 4/22/12, Wolfram Sang wrote:
> On Tue, Apr 17, 2012 at 05:04:31PM +0530, Viresh Kumar wrote:
>> clk_{un}prepare is mandatory for platforms using common clock framework.
>> Since
>> this driver is used by SPEAr platform, which supports common clock
>> framework,
>&
With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
macros.
pxa i2c also has these dummy macros defined locally. Remove them as they aren't
required anymore.
Signed-off-by: Viresh Kuma
clk_{un}prepare is mandatory for platforms using common clock framework. Since
this driver is used by SPEAr platform, which supports common clock framework,
add clk_{un}prepare() support for designware i2c.
Signed-off-by: Viresh Kumar
---
V1->V2:
- Use clk_prepare_enable
clk_{un}prepare is mandatory for platforms using common clock framework. Since
this driver is used by SPEAr platform, which supports common clock framework,
add clk_{un}prepare() support for designware i2c.
Signed-off-by: Viresh Kumar
---
drivers/i2c/busses/i2c-designware-platdrv.c | 19
On 3/2/2012 11:53 AM, Viresh KUMAR wrote:
> This patchset adds 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
>
> This patch
On 2/24/2012 5:01 PM, Viresh KUMAR wrote:
> From: Deepak Sikri
>
> This patch adds in support for standby/S2R/hybernate for i2c-designware
> driver.
>
> Signed-off-by: Deepak Sikri
> Signed-off-by: Rajeev Kumar
> ---
> drivers/i2c/busses/i2c-
On 3/2/2012 11:53 AM, Viresh KUMAR wrote:
> Hello,
>
> This patchset adds 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
>
roller. In addition controller driver may provide
its own version of the bus recovery routine.
Signed-off-by: Viresh Kumar
---
drivers/i2c/i2c-core.c | 125
include/linux/i2c.h| 52
2 files changed, 177 insertions(+), 0
/linux-i2c/msg07267.html
Changes since V2:
- gpio flags are now passed from controller drivers
- added support for sda line polling
- Aligned i2c-designware driver with generic recovery support
Viresh Kumar (2):
i2c/adapter: Add bus recovery infrastructure
i2c/designware: Provide optional i2c bu
Add bus recovery support for designware_i2c controller. It uses generic gpio
based i2c_gpio_recover_bus() routine.
Signed-off-by: Vincenzo Frascino
Signed-off-by: Shiraz Hashim
Signed-off-by: Viresh Kumar
---
drivers/i2c/busses/i2c-designware-core.c|7 +++-
drivers/i2c/busses/i2c
On 3/1/2012 11:40 AM, Laxman Dewangan wrote:
> Most of the socs have i2c pin as open drain type. By having this flag we can
> tell that in is whether open drain type or not.
> There is patch to support open drain in gpiolib which is under review.
Ok. Got it now.
I will add gpio_flags in struct i
On 2/29/12, Laxman Dewangan wrote:
Here is V2:
From: Viresh Kumar
Date: Tue, 28 Feb 2012 18:26:31 +0530
Subject: [PATCH] i2c/adapter: Add bus recovery infrastructure
Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
protocol Rev. 03 section 3.16 titled "Bus
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;
: Pratyush Anand
Signed-off-by: Viresh Kumar
---
This patch was sent a long time back and was never pushed. Resending it again.
drivers/i2c/busses/i2c-designware-platdrv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers
On 2/28/2012 7:25 PM, Salvatore DE DOMINICIS wrote:
> What happens if the bus is still stuck?
> Do we need to check also for a change in SDA line?
> I mean, if some device is not behaving correctly and does not change the SDA
> (as mandated by standard) then we don't solve the issue.
>
I also wan
On 2/27/12, Viresh Kumar wrote:
> we can give generalized function inside i2c framework for this, so that
> multiple
> drivers can use it.
>
> Secondly there are drivers/devices where control of pins is available. For
> them
> we can provide driver hooks.
>
> I would
On 2/27/2012 3:40 PM, Rajeev KUMAR wrote:
> In some i2c controller (like synopsys) you dont have control over i2c
> data and clock lines. So clock toggling, you need to use gpio lines
> which in turns maps on sda and scl line.
>
> For the controller in which you have control over sda and scl lin
On 11/16/2011 10:28 AM, Pratyush ANAND wrote:
> There are few drivers(for example stmpe-gpio) which are available on i2c
> bus but has been initialized as subsys initcall. Therefore i2c driver
> must also be initialized as subsys initcall.
>
> Signed-off-by: Pratyush Anand
> ---
> drivers/i2c/bu
-off-by: Shiraz Hashim
Signed-off-by: Viresh Kumar
---
drivers/i2c/busses/i2c-designware-core.c|4 +++
drivers/i2c/busses/i2c-designware-core.h|3 +-
drivers/i2c/busses/i2c-designware-platdrv.c |8 ++
include/linux/i2c/i2c-designware.h | 33 +
From: Deepak Sikri
This patch adds in support for standby/S2R/hybernate for i2c-designware driver.
Signed-off-by: Deepak Sikri
Signed-off-by: Rajeev Kumar
---
drivers/i2c/busses/i2c-designware-platdrv.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
dif
On 11/16/2011 1:52 PM, Baruch Siach wrote:
> Dependencies should be stated explicitly. Since this subsys_initcall thing is
> quite common among the i2c masters I'm willing to ack this one for now. But
> the real solution is to make the dependencies between devices clear and
> explicit.
Baruch,
94 matches
Mail list logo
