Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function

2012-02-29 Thread Viresh Kumar
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

Re: [Intel-gfx] [PATCH 1/7] drm/i915: add dev_priv to intel_gmbus

2012-02-29 Thread Daniel Vetter
On Mon, Feb 27, 2012 at 02:53:37PM -0300, Eugeni Dodonov wrote: > On Tue, Feb 14, 2012 at 19:37, Daniel Vetter wrote: > > > This way we can free up the bus->adaptor.algo_data pointer and make it > > available for use with the bitbanging fallback algo. > > > > Signed-Off-by: Daniel Vetter > > >

Re: [PATCH] i2c: export bit-banging algo functions

2012-02-29 Thread Daniel Vetter
On Tue, Feb 28, 2012 at 09:08:17AM +0100, Jean Delvare wrote: > On Tue, 28 Feb 2012 00:39:39 +0100, Daniel Vetter wrote: > > i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons > > we need to be able to fall back to the bit-banging algo on gpio pins. > > > > The current code set

Re: [PATCH v6] I2C: add CSR SiRFprimaII on-chip I2C controllers driver

2012-02-29 Thread Wolfram Sang
On Thu, Feb 16, 2012 at 03:45:04PM +0100, Wolfram Sang wrote: > On Wed, Feb 08, 2012 at 11:28:35PM +0800, Barry Song wrote: > > From: Zhiwu Song > > > > SiRFprimaII is the latest generation application processor from CSR’s > > multi-function SoC product family. > > The SoC support codes are in ar

Re: [PATCH] i2c/imx: fix imx driver to work though signal is pending

2012-02-29 Thread Wolfram Sang
On Thu, Feb 23, 2012 at 12:19:11PM +, Oskar Schirmer wrote: > Interrupt a test application for I2C based mc13xxx driven > touch panel, SIGINT, causes open event file descriptor to be > closed, which in turn causes I2C activity to mask PMIC local > interrupts. This eventually ends up in i2c_imx_

Re: [PATCH Resend] i2c/designware: dw_i2c_init_driver as subsys initcall

2012-02-29 Thread Wolfram Sang
On Wed, Feb 29, 2012 at 12:27:46PM +0530, Viresh Kumar wrote: > From: Pratyush Anand > > There are few drivers which are available on i2c bus but have been initialized > with subsys_initcall. Also as I2C is also a bus driver, it should be available > as early as possible. > > Therefore i2c drive

Re: [PATCH] i2c-mpc: avoid I2C abnormal after resuming from deep sleep

2012-02-29 Thread Wolfram Sang
Hi, On Wed, Feb 29, 2012 at 06:39:21PM +0800, Zhao Chenhui wrote: > When entering deep sleep, the value in the registers I2CFDR and > I2CDFSRR are lost. This causes I2C access to fail after resuming. > > Add suspend/resume routines to save/restore the registers > I2CFDR and I2CDFSRR. > > Signed-

Re: [PATCH] i2c-mpc: avoid I2C abnormal after resuming from deep sleep

2012-02-29 Thread Tabi Timur-B04825
On Wed, Feb 29, 2012 at 7:02 AM, Shubhrajyoti Datta wrote: > >> +#ifdef CONFIG_PM >> +       u8 fdr, dfsrr; > How about having  a structure here ? Why? He's just adding two variables in an existing structure. Adding a nested structure would unnecessarily complicate things. -- Timur Tabi Linux

Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function

2012-02-29 Thread viresh kumar
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 clear". S

[PATCH 1/5 v2] i2c/gpio: add DT support

2012-02-29 Thread Jean-Christophe PLAGNIOL-VILLARD
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Cc: Nicolas Ferre Cc: linux-i2c@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org --- v2: use devm_kzalloc use i2c-gpio use time name in the properties Best Regars, J. .../devicetree/bindings/gpio/gpio_i2c.txt

Re: [PATCH] i2c-mpc: avoid I2C abnormal after resuming from deep sleep

2012-02-29 Thread Shubhrajyoti Datta
Hi Zhao, On Wed, Feb 29, 2012 at 4:09 PM, Zhao Chenhui wrote: > When entering deep sleep, the value in the registers I2CFDR and > I2CDFSRR are lost. This causes I2C access to fail after resuming. > > Add suspend/resume routines to save/restore the registers > I2CFDR and I2CDFSRR. > > Signed-off-b

Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function

2012-02-29 Thread Laxman Dewangan
On Wednesday 29 February 2012 05:28 PM, Viresh Kumar wrote: + 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

Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function

2012-02-29 Thread Viresh Kumar
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 = 1000

Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function

2012-02-29 Thread Laxman Dewangan
On Tuesday 28 February 2012 06:53 PM, viresh kumar wrote: 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 --- dr

[PATCH] i2c-mpc: avoid I2C abnormal after resuming from deep sleep

2012-02-29 Thread Zhao Chenhui
When entering deep sleep, the value in the registers I2CFDR and I2CDFSRR are lost. This causes I2C access to fail after resuming. Add suspend/resume routines to save/restore the registers I2CFDR and I2CDFSRR. Signed-off-by: Zhao Chenhui Signed-off-by: Li Yang --- drivers/i2c/busses/i2c-mpc.c |

Re: [PATCH 2/2] i2c/designware: Provide optional i2c bus recovery function

2012-02-29 Thread Vincenzo Frascino
Hi Viresh, Il 29/02/2012 05:58, Viresh KUMAR ha scritto: > 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 man