[PATCH 0/2] davinci i2c fixes for 2.6.31

[PATCH 0/2] davinci i2c fixes for 2.6.31

[Kevin Hilman]

Here are a couple fixes for the i2c driver on the TI DaVinci family
of SoCs.  These have been tested for awhile in the DaVinci git
repo are needed for 2.6.31.

These apply on v2.6.31-rc2.

David Brownell (1):
  i2c-davinci: behave with i2cdetect

Kevin Hilman (1):
  i2c-davinci: convert clock usage after clkdev conversion

 drivers/i2c/busses/i2c-davinci.c |   20 +++++++++++++++-----
 1 files changed, 15 insertions(+), 5 deletions(-)

[PATCH 1/2] i2c-davinci: convert clock usage after clkdev conversion

[Kevin Hilman]

DaVinci core code has converted to the new clkdev API so
clock name strings are not needed.  Instead, just the a
'struct device' pointer is needed.

Signed-off-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
---
 drivers/i2c/busses/i2c-davinci.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 3fae3a9..ee3fbb8 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -523,7 +523,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 	dev->irq = irq->start;
 	platform_set_drvdata(pdev, dev);
 
-	dev->clk = clk_get(&pdev->dev, "I2CCLK");
+	dev->clk = clk_get(&pdev->dev, NULL);
 	if (IS_ERR(dev->clk)) {
 		r = -ENODEV;
 		goto err_free_mem;
-- 
1.6.3.3

[PATCH 2/2] i2c-davinci: behave with i2cdetect

[Kevin Hilman]

From: David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>

Make i2c-davinci cope properly with "i2cdetect":  don't spew
syslog spam on perfectly normal behaviors, or respond to any
address other than the one reserved for the SMBus host.

Signed-off-by: David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Signed-off-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
---
 drivers/i2c/busses/i2c-davinci.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index ee3fbb8..1f3d89c 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -187,6 +187,11 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev)
 	davinci_i2c_write_reg(dev, DAVINCI_I2C_CLKH_REG, clkh);
 	davinci_i2c_write_reg(dev, DAVINCI_I2C_CLKL_REG, clkl);
 
+	/* Respond at reserved "SMBus Host" slave address" (and zero);
+	 * we seem to have no option to not respond...
+	 */
+	davinci_i2c_write_reg(dev, DAVINCI_I2C_OAR_REG, 0x08);
+
 	dev_dbg(dev->dev, "input_clock = %d, CLK = %d\n", input_clock, clk);
 	dev_dbg(dev->dev, "PSC  = %d\n",
 		davinci_i2c_read_reg(dev, DAVINCI_I2C_PSC_REG));
@@ -387,7 +392,7 @@ static void terminate_write(struct davinci_i2c_dev *dev)
 	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w);
 
 	if (!dev->terminate)
-		dev_err(dev->dev, "TDR IRQ while no data to send\n");
+		dev_dbg(dev->dev, "TDR IRQ while no data to send\n");
 }
 
 /*
@@ -473,9 +478,14 @@ static irqreturn_t i2c_davinci_isr(int this_irq, void *dev_id)
 			break;
 
 		case DAVINCI_I2C_IVR_AAS:
-			dev_warn(dev->dev, "Address as slave interrupt\n");
-		}/* switch */
-	}/* while */
+			dev_dbg(dev->dev, "Address as slave interrupt\n");
+			break;
+
+		default:
+			dev_warn(dev->dev, "Unrecognized irq stat %d\n", stat);
+			break;
+		}
+	}
 
 	return count ? IRQ_HANDLED : IRQ_NONE;
 }
-- 
1.6.3.3

Re: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Ben Dooks]

On Mon, Jul 06, 2009 at 03:48:34PM -0700, Kevin Hilman wrote:
> Here are a couple fixes for the i2c driver on the TI DaVinci family
> of SoCs.  These have been tested for awhile in the DaVinci git
> repo are needed for 2.6.31.
> 
> These apply on v2.6.31-rc2.

ok, do you have a git branch to pull, or should I apply
them from the mailing list>
 
> David Brownell (1):
>   i2c-davinci: behave with i2cdetect
> 
> Kevin Hilman (1):
>   i2c-davinci: convert clock usage after clkdev conversion
> 
>  drivers/i2c/busses/i2c-davinci.c |   20 +++++++++++++++-----
>  1 files changed, 15 insertions(+), 5 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Kevin Hilman]

Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org> writes:

> On Mon, Jul 06, 2009 at 03:48:34PM -0700, Kevin Hilman wrote:
>> Here are a couple fixes for the i2c driver on the TI DaVinci family
>> of SoCs.  These have been tested for awhile in the DaVinci git
>> repo are needed for 2.6.31.
>> 
>> These apply on v2.6.31-rc2.
>
> ok, do you have a git branch to pull, or should I apply
> them from the mailing list>

You can take from the list.  My git branch has a bunch of other
non-i2c changes in it as well.

Thanks,

Kevin

>> David Brownell (1):
>>   i2c-davinci: behave with i2cdetect
>> 
>> Kevin Hilman (1):
>>   i2c-davinci: convert clock usage after clkdev conversion
>> 
>>  drivers/i2c/busses/i2c-davinci.c |   20 +++++++++++++++-----
>>  1 files changed, 15 insertions(+), 5 deletions(-)
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> -- 
> Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)
>
>   'a smiley only costs 4 bytes'

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Karicheri, Muralidharan]

Hi Kevin,

When we do a video loopback with MT9T031, we get i2c timeouts when application is killed using Cntrl C. Is it being addressed in any of the patches?  We had the same issue with TI LSP releases (1.20, 2.00, 2.1o etc).
The board has to be rebooted to recover from this.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-karicheri2-l0cyMroinI0@public.gmane.org

>-----Original Message-----
>From: davinci-linux-open-source-bounces+m-
>karicheri2=ti.com-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org [mailto:davinci-linux-open-source-
>bounces+m-karicheri2=ti.com-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org] On Behalf Of Kevin Hilman
>Sent: Wednesday, July 08, 2009 9:30 AM
>To: Ben Dooks
>Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-
>i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: Re: [PATCH 0/2] davinci i2c fixes for 2.6.31
>
>Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org> writes:
>
>> On Mon, Jul 06, 2009 at 03:48:34PM -0700, Kevin Hilman wrote:
>>> Here are a couple fixes for the i2c driver on the TI DaVinci family
>>> of SoCs.  These have been tested for awhile in the DaVinci git
>>> repo are needed for 2.6.31.
>>>
>>> These apply on v2.6.31-rc2.
>>
>> ok, do you have a git branch to pull, or should I apply
>> them from the mailing list>
>
>You can take from the list.  My git branch has a bunch of other
>non-i2c changes in it as well.
>
>Thanks,
>
>Kevin
>
>>> David Brownell (1):
>>>   i2c-davinci: behave with i2cdetect
>>>
>>> Kevin Hilman (1):
>>>   i2c-davinci: convert clock usage after clkdev conversion
>>>
>>>  drivers/i2c/busses/i2c-davinci.c |   20 +++++++++++++++-----
>>>  1 files changed, 15 insertions(+), 5 deletions(-)
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)
>>
>>   'a smiley only costs 4 bytes'
>
>_______________________________________________
>Davinci-linux-open-source mailing list
>Davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
>http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Kevin Hilman]

Murali,

"Karicheri, Muralidharan" <m-karicheri2-l0cyMroinI0@public.gmane.org> writes:

> When we do a video loopback with MT9T031, we get i2c timeouts when
> application is killed using Cntrl C. Is it being addressed in any of
> the patches?  

I don't know, as I have never seen that particular issue.

This series contains various fixes that have already been in DaVinci
git for a while, so if you are still seeing that problem with current
DaVinci git, then an additional patch will be needed.

Kevin

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Philby John]

Hello Murali,
	
	I will send a patch out to address this problem.

Regards,
Philby


On Wed, 2009-07-08 at 10:25 -0500, Karicheri, Muralidharan wrote:
> Hi Kevin,
> 
> When we do a video loopback with MT9T031, we get i2c timeouts when application is killed using Cntrl C. Is it being addressed in any of the patches?  We had the same issue with TI LSP releases (1.20, 2.00, 2.1o etc).
> The board has to be rebooted to recover from this.
> 
> Murali Karicheri
> Software Design Engineer
> Texas Instruments Inc.
> Germantown, MD 20874
> Phone : 301-515-3736
> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> 
> >-----Original Message-----
> >From: davinci-linux-open-source-bounces+m-
> >karicheri2=ti.com-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org [mailto:davinci-linux-open-source-
> >bounces+m-karicheri2=ti.com-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org] On Behalf Of Kevin Hilman
> >Sent: Wednesday, July 08, 2009 9:30 AM
> >To: Ben Dooks
> >Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-
> >i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >Subject: Re: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >
> >Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org> writes:
> >
> >> On Mon, Jul 06, 2009 at 03:48:34PM -0700, Kevin Hilman wrote:
> >>> Here are a couple fixes for the i2c driver on the TI DaVinci family
> >>> of SoCs.  These have been tested for awhile in the DaVinci git
> >>> repo are needed for 2.6.31.
> >>>
> >>> These apply on v2.6.31-rc2.
> >>
> >> ok, do you have a git branch to pull, or should I apply
> >> them from the mailing list>
> >
> >You can take from the list.  My git branch has a bunch of other
> >non-i2c changes in it as well.
> >
> >Thanks,
> >
> >Kevin
> >
> >>> David Brownell (1):
> >>>   i2c-davinci: behave with i2cdetect
> >>>
> >>> Kevin Hilman (1):
> >>>   i2c-davinci: convert clock usage after clkdev conversion
> >>>
> >>>  drivers/i2c/busses/i2c-davinci.c |   20 +++++++++++++++-----
> >>>  1 files changed, 15 insertions(+), 5 deletions(-)
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> >>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>
> >> --
> >> Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)
> >>
> >>   'a smiley only costs 4 bytes'
> >
> >_______________________________________________
> >Davinci-linux-open-source mailing list
> >Davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
> >http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Karicheri, Muralidharan]

Philby,

That will be great! I will look for it.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-karicheri2-l0cyMroinI0@public.gmane.org

>-----Original Message-----
>From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>Sent: Wednesday, July 15, 2009 3:29 AM
>To: Karicheri, Muralidharan
>Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>
>Hello Murali,
>
>	I will send a patch out to address this problem.
>
>Regards,
>Philby
>
>
>On Wed, 2009-07-08 at 10:25 -0500, Karicheri, Muralidharan wrote:
>> Hi Kevin,
>>
>> When we do a video loopback with MT9T031, we get i2c timeouts when
>application is killed using Cntrl C. Is it being addressed in any of the
>patches?  We had the same issue with TI LSP releases (1.20, 2.00, 2.1o etc).
>> The board has to be rebooted to recover from this.
>>
>> Murali Karicheri
>> Software Design Engineer
>> Texas Instruments Inc.
>> Germantown, MD 20874
>> Phone : 301-515-3736
>> email: m-karicheri2-l0cyMroinI0@public.gmane.org
>>
>> >-----Original Message-----
>> >From: davinci-linux-open-source-bounces+m-
>> >karicheri2=ti.com-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org [mailto:davinci-linux-open-
>source-
>> >bounces+m-karicheri2=ti.com-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org] On Behalf Of Kevin
>Hilman
>> >Sent: Wednesday, July 08, 2009 9:30 AM
>> >To: Ben Dooks
>> >Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-
>> >i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >Subject: Re: [PATCH 0/2] davinci i2c fixes for 2.6.31
>> >
>> >Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org> writes:
>> >
>> >> On Mon, Jul 06, 2009 at 03:48:34PM -0700, Kevin Hilman wrote:
>> >>> Here are a couple fixes for the i2c driver on the TI DaVinci family
>> >>> of SoCs.  These have been tested for awhile in the DaVinci git
>> >>> repo are needed for 2.6.31.
>> >>>
>> >>> These apply on v2.6.31-rc2.
>> >>
>> >> ok, do you have a git branch to pull, or should I apply
>> >> them from the mailing list>
>> >
>> >You can take from the list.  My git branch has a bunch of other
>> >non-i2c changes in it as well.
>> >
>> >Thanks,
>> >
>> >Kevin
>> >
>> >>> David Brownell (1):
>> >>>   i2c-davinci: behave with i2cdetect
>> >>>
>> >>> Kevin Hilman (1):
>> >>>   i2c-davinci: convert clock usage after clkdev conversion
>> >>>
>> >>>  drivers/i2c/busses/i2c-davinci.c |   20 +++++++++++++++-----
>> >>>  1 files changed, 15 insertions(+), 5 deletions(-)
>> >>>
>> >>> --
>> >>> To unsubscribe from this list: send the line "unsubscribe linux-i2c"
>in
>> >>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >>
>> >> --
>> >> Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)
>> >>
>> >>   'a smiley only costs 4 bytes'
>> >
>> >_______________________________________________
>> >Davinci-linux-open-source mailing list
>> >Davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
>> >http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Karicheri, Muralidharan]

Philby,

I tried running this patch against 2.6.31.rc2 (davinci kernel tree). But I got a crash as I run the application which is given below....

In my case, time out happens when I kill the capture application using Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by the host (during cleanup, i2c commands fails). When the application is run again, I get following outputs..

i2c_davinci i2c_davinci.1: timeout waiting for bus ready
i2c_davinci i2c_davinci.1: timeout waiting for bus ready

Here are the complete log....

application running and pressed Cntrl-C ====>

time:105    frame:33
time:105    frame:34vpfe-capture vpfe-capture: stream off failed in subdev

Running it again .....

root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
main : Enter
initializing capture device
setting data format
input.name = Composite
input.name = S-Video
input.name = Camera
Calling S_INPUT with index = 2
i2c_davinci i2c_davinci.1: timeout waiting for bus ready
i2c_davinci i2c_davinci.1: timeout waiting for bus ready
i2c_davinci i2c_davinci.1: timeout waiting for bus ready
i2c_davinci i2c_davinci.1: timeout waiting for bus ready
vpfe-capture vpfe-capture: fh->io_allowed
Error:InitDevice:ioctl:VIDIOC_S_INPUT
: Bad address
Error in setting capture format
Failed to intialize capture
start_streaming:ioctl:VIDIOC_STREAMOFF:
main : Leave
root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git#
root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git#
root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git#
root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
main : Enter
initializing capture device
setting data format
input.name = Composite
input.name = S-Video
input.name = Camera
Calling S_INPUT with index = 2
i2c_davinci i2c_davinci.1: timeout waiting for bus ready
i2c_davinci i2c_davinci.1: timeout waiting for bus ready
i2c_davinci i2c_davinci.1: initiating i2c bus recovery
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:83 gpio_ensure_requested+0x5c/0x128()
autorequest GPIO-15
Modules linked in:
Backtrace:
[<c002b7a8>] (dump_backtrace+0x0/0x114) from [<c024d970>] (dump_stack+0x18/0x1c)
 r7:c73b1be8 r6:c0159d94 r5:c02cd20d r4:00000053
[<c024d958>] (dump_stack+0x0/0x1c) from [<c003c690>] (warn_slowpath_common+0x50/
0x68)
[<c003c640>] (warn_slowpath_common+0x0/0x68) from [<c003c6f4>] (warn_slowpath_fm
t+0x30/0x38)
 r7:00000000 r6:c031ca08 r5:c033b1b4 r4:c031ca08
[<c003c6c4>] (warn_slowpath_fmt+0x0/0x38) from [<c0159d94>] (gpio_ensure_request
ed+0x5c/0x128)
 r3:0000000f r2:c02cd224
[<c0159d38>] (gpio_ensure_requested+0x0/0x128) from [<c015a028>] (gpio_direction
_input+0x80/0x140)
 r9:c6c892dc r8:c033b1b4 r7:c73b1cc4 r6:0000000f r5:60000093
r4:c031ca08
[<c0159fa8>] (gpio_direction_input+0x0/0x140) from [<c019fcf4>] (disable_i2c_pin
s+0x34/0x6c)
 r9:c6c892dc r8:00000001 r7:c73b1cc4 r6:ffffb774 r5:c031cb68
r4:40000013
[<c019fcc0>] (disable_i2c_pins+0x0/0x6c) from [<c019ff90>] (i2c_davinci_xfer+0xf
c/0x3f0)
 r5:00000000 r4:c6c41800
[<c019fe94>] (i2c_davinci_xfer+0x0/0x3f0) from [<c019d484>] (i2c_transfer+0xa4/0
xfc)
[<c019d3e0>] (i2c_transfer+0x0/0xfc) from [<c0033064>] (dm355evm_enable_i2c_swit
ch+0x6c/0x80)
[<c0032ff8>] (dm355evm_enable_i2c_switch+0x0/0x80) from [<c00330b4>] (dm355evm_s
etup_video_input+0x3c/0x54)
 r5:c6c89000 r4:00000000
[<c0033078>] (dm355evm_setup_video_input+0x0/0x54) from [<c01bba00>] (vpfe_s_inp
ut+0xcc/0x284)
[<c01bb934>] (vpfe_s_input+0x0/0x284) from [<c01aeaf0>] (__video_do_ioctl+0x19d8
/0x3374)
[<c01ad118>] (__video_do_ioctl+0x0/0x3374) from [<c01b0774>] (video_ioctl2+0x2e8
/0x434)
[<c01b048c>] (video_ioctl2+0x0/0x434) from [<c01ac2f8>] (v4l2_unlocked_ioctl+0x4
0/0x44)
[<c01ac2b8>] (v4l2_unlocked_ioctl+0x0/0x44) from [<c00a2568>] (vfs_ioctl+0x34/0x
94)
 r7:c734d280 r6:c0045627 r5:bec58ac8 r4:c734d280
[<c00a2534>] (vfs_ioctl+0x0/0x94) from [<c00a2c2c>] (do_vfs_ioctl+0x56c/0x5c8)
 r7:c734d280 r6:00000004 r5:c734d280 r4:c73b4bf8
[<c00a26c0>] (do_vfs_ioctl+0x0/0x5c8) from [<c00a2cc8>] (sys_ioctl+0x40/0x64)
[<c00a2c88>] (sys_ioctl+0x0/0x64) from [<c0027ea0>] (ret_fast_syscall+0x0/0x2c)
 r7:00000036 r6:00000000 r5:00000000 r4:40024db0
---[ end trace 21b642dbca792ce4 ]---
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:83 gpio_ensure_requested+0x5c/0x128()
autorequest GPIO-14
Modules linked in:
Backtrace:
[<c002b7a8>] (dump_backtrace+0x0/0x114) from [<c024d970>] (dump_stack+0x18/0x1c)
 r7:c73b1be8 r6:c0159d94 r5:c02cd20d r4:00000053
[<c024d958>] (dump_stack+0x0/0x1c) from [<c003c690>] (warn_slowpath_common+0x50/
0x68)
[<c003c640>] (warn_slowpath_common+0x0/0x68) from [<c003c6f4>] (warn_slowpath_fm
t+0x30/0x38)
 r7:00000000 r6:c031ca08 r5:c033b1a8 r4:c031ca08
[<c003c6c4>] (warn_slowpath_fmt+0x0/0x38) from [<c0159d94>] (gpio_ensure_request
ed+0x5c/0x128)
 r3:0000000e r2:c02cd224
[<c0159d38>] (gpio_ensure_requested+0x0/0x128) from [<c0159ee4>] (gpio_direction
_output+0x84/0x148)
 r9:c6c892dc r8:c033b1a8 r7:c73b1cc4 r6:0000000e r5:60000093
r4:c031ca08
[<c0159e60>] (gpio_direction_output+0x0/0x148) from [<c019fd00>] (disable_i2c_pi
ns+0x40/0x6c)
[<c019fcc0>] (disable_i2c_pins+0x0/0x6c) from [<c019ff90>] (i2c_davinci_xfer+0xf
c/0x3f0)
 r5:00000000 r4:c6c41800
[<c019fe94>] (i2c_davinci_xfer+0x0/0x3f0) from [<c019d484>] (i2c_transfer+0xa4/0
xfc)
[<c019d3e0>] (i2c_transfer+0x0/0xfc) from [<c0033064>] (dm355evm_enable_i2c_swit
ch+0x6c/0x80)
[<c0032ff8>] (dm355evm_enable_i2c_switch+0x0/0x80) from [<c00330b4>] (dm355evm_s
etup_video_input+0x3c/0x54)
 r5:c6c89000 r4:00000000
[<c0033078>] (dm355evm_setup_video_input+0x0/0x54) from [<c01bba00>] (vpfe_s_inp
ut+0xcc/0x284)
[<c01bb934>] (vpfe_s_input+0x0/0x284) from [<c01aeaf0>] (__video_do_ioctl+0x19d8
/0x3374)
[<c01ad118>] (__video_do_ioctl+0x0/0x3374) from [<c01b0774>] (video_ioctl2+0x2e8
/0x434)
[<c01b048c>] (video_ioctl2+0x0/0x434) from [<c01ac2f8>] (v4l2_unlocked_ioctl+0x4
0/0x44)
[<c01ac2b8>] (v4l2_unlocked_ioctl+0x0/0x44) from [<c00a2568>] (vfs_ioctl+0x34/0x
94)
 r7:c734d280 r6:c0045627 r5:bec58ac8 r4:c734d280
[<c00a2534>] (vfs_ioctl+0x0/0x94) from [<c00a2c2c>] (do_vfs_ioctl+0x56c/0x5c8)
 r7:c734d280 r6:00000004 r5:c734d280 r4:c73b4bf8
[<c00a26c0>] (do_vfs_ioctl+0x0/0x5c8) from [<c00a2cc8>] (sys_ioctl+0x40/0x64)
[<c00a2c88>] (sys_ioctl+0x0/0x64) from [<c0027ea0>] (ret_fast_syscall+0x0/0x2c)
 r7:00000036 r6:00000000 r5:00000000 r4:40024db0
---[ end trace 21b642dbca792ce5 ]---
vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 1
InitDevice:ioctlvpfe-capture vpfe-capture: adjusted width = 32, height = 1, bpp
= 1, bytesperline = 32, sizeimage = 32
:VIDIOC_S_INPUT,vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp =
1
 selected input vpfe-capture vpfe-capture: adjusted width = 2048, height = 1536,
 bpp = 1, bytesperline = 2048, sizeimage = 3145728
index = 2
InitDvpfe-capture vpfe-capture: width = 1280, height = 720, bpp = 1
evice:ioctl:VIDIvpfe-capture vpfe-capture: adjusted width = 1280, height = 720,
bpp = 1, bytesperline = 1280, sizeimage = 921600
OC_G_INPUT, selected input, Camera
Following standards available at the input
InitDevice:ioctl:VIDIOC_CROPCAP
Default crop capbility bounds - 34054 1073858848 0 0 ; default - 1073945068 3375
6 1 1
set_datvpfe-capture vpfe-capture: stream on failed in subdev
a_format:setting data format
Available image formats at the capture driver :-
fmt_desc.index = 0
fmt_desc.type = 1
fmt_desc.description = Bayer GrRBGb 8bit A-Law compr.
fmt_desc.pixelformat = 31384142
fmt_desc.index = 1
fmt_desc.type = 1
fmt_desc.description = Bayer GrRBGb - 16bit
fmt_desc.pixelformat = 32525942
*******TRY_FMT (Min resolution) values before calling ioctl*************
fmt.fmt.pix.width = 1
fmt.fmt.pix.height = 1
fmt.fmt.pix.field= 0
fmt.fmt.pix.bytesperline = 0
fmt.fmt.pix.sizeimage = 0
*******TRY_FMT values after calling ioctl*************
fmt.fmt.pix.width = 32
fmt.fmt.pix.height = 1
fmt.fmt.pix.field= 1
fmt.fmt.pix.bytesperline = 32
fmt.fmt.pix.sizeimage = 32
*******TRY_FMT (Max resolution) values before calling ioctl*************
fmt.fmt.pix.width = 32768
fmt.fmt.pix.height = 32768
fmt.fmt.pix.field= 0
fmt.fmt.pix.bytesperline = 0
fmt.fmt.pix.sizeimage = 0
*******TRY_FMT values after calling ioctl*************
fmt.fmt.pix.width = 2048
fmt.fmt.pix.height = 1536
fmt.fmt.pix.field= 1
fmt.fmt.pix.bytesperline = 2048
fmt.fmt.pix.sizeimage = 3145728
set_data_format:ioctl:VIDIOC_S_FMT
set_data_format:finally negotiated width:1280 height:720
set_data_format:driver reports bytes_per_line:1280(bug)
set_data_format:driver reports size:921600(bug)
set_data_format:Finally negotiated width:1280 height:720
initializing capture buffers
device buffers:3
buffer:0 phy:0 mmap:0x4013f000 length:831488
buffer:1 phy:cb000 mmap:0x4020a000 length:831488
buffer:2 phy:196000 mmap:0x402d5000 length:831488
initializing display device
Queing buffer:0
Queing buffer:1
Queing buffer:2
start_streaming:ioctl:VIDIOC_STREAMON:
vpbe_UE_1 : Enter
Starting loop..........


root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
main : Enter
vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 1
initializing capvpfe-capture vpfe-capture: adjusted width = 32, height = 1, bpp
= 1, bytesperline = 32, sizeimage = 32
ture device
setvpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 1
ting data formatvpfe-capture vpfe-capture: adjusted width = 2048, height = 1536,
 bpp = 1, bytesperline = 2048, sizeimage = 3145728

input.name = Cvpfe-capture vpfe-capture: width = 1280, height = 720, bpp = 1
omposite
input.vpfe-capture vpfe-capture: adjusted width = 1280, height = 720, bpp = 1, b
ytesperline = 1280, sizeimage = 921600
name = S-Video
input.name = Camera
Calling S_INPUT with index = 2
InitDevice:ioctl:VIDIOC_S_INPUT, selected input index = 2
InitDevice:ioctl:VIDIOC_G_INPUT, selected input, Camera
Following standards avavpfe-capture vpfe-capture: stream on failed in subdev
ilable at the input
InitDevice:ioctl:VIDIOC_CROPCAP
Default crop capbility bounds - 34054 1073858848 0 0 ; default - 1073945068 3375
6 1 1
set_data_format:setting data format
Available image formats at the capture driver :-
fmt_desc.index = 0
fmt_desc.type = 1
fmt_desc.description = Bayer GrRBGb 8bit A-Law compr.
fmt_desc.pixelformat = 31384142
fmt_desc.index = 1
fmt_desc.type = 1
fmt_desc.description = Bayer GrRBGb - 16bit
fmt_desc.pixelformat = 32525942
*******TRY_FMT (Min resolution) values before calling ioctl*************
fmt.fmt.pix.width = 1
fmt.fmt.pix.height = 1
fmt.fmt.pix.field= 0
fmt.fmt.pix.bytesperline = 0
fmt.fmt.pix.sizeimage = 0
*******TRY_FMT values after calling ioctl*************
fmt.fmt.pix.width = 32
fmt.fmt.pix.height = 1
fmt.fmt.pix.field= 1
fmt.fmt.pix.bytesperline = 32
fmt.fmt.pix.sizeimage = 32
*******TRY_FMT (Max resolution) values before calling ioctl*************
fmt.fmt.pix.width = 32768
fmt.fmt.pix.height = 32768
fmt.fmt.pix.field= 0
fmt.fmt.pix.bytesperline = 0
fmt.fmt.pix.sizeimage = 0
*******TRY_FMT values after calling ioctl*************
fmt.fmt.pix.width = 2048
fmt.fmt.pix.height = 1536
fmt.fmt.pix.field= 1
fmt.fmt.pix.bytesperline = 2048
fmt.fmt.pix.sizeimage = 3145728
set_data_format:ioctl:VIDIOC_S_FMT
set_data_format:finally negotiated width:1280 height:720
set_data_format:driver reports bytes_per_line:1280(bug)
set_data_format:driver reports size:921600(bug)
set_data_format:Finally negotiated width:1280 height:720
initializing capture buffers
device buffers:3
buffer:0 phy:0 mmap:0x4013f000 length:831488
buffer:1 phy:cb000 mmap:0x4020a000 length:831488
buffer:2 phy:196000 mmap:0x402d5000 length:831488
initializing display device
Queing buffer:0
Queing buffer:1
Queing buffer:2
start_streaming:ioctl:VIDIOC_STREAMON:
vpbe_UE_1 : Enter
Starting loop..........

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-karicheri2-l0cyMroinI0@public.gmane.org

>-----Original Message-----
>From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>Sent: Wednesday, July 15, 2009 3:29 AM
>To: Karicheri, Muralidharan
>Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>
>Hello Murali,
>
>       I will send a patch out to address this problem.
>
>Regards,
>Philby
>
>
>On Wed, 2009-07-08 at 10:25 -0500, Karicheri, Muralidharan wrote:
>> Hi Kevin,
>>
>> When we do a video loopback with MT9T031, we get i2c timeouts when
>application is killed using Cntrl C. Is it being addressed in any of the
>patches?  We had the same issue with TI LSP releases (1.20, 2.00, 2.1o etc).
>> The board has to be rebooted to recover from this.
>>
>> Murali Karicheri
>> Software Design Engineer
>> Texas Instruments Inc.
>> Germantown, MD 20874
>> Phone : 301-515-3736
>> email: m-karicheri2-l0cyMroinI0@public.gmane.org
>>
>> >-----Original Message-----
>> >From: davinci-linux-open-source-bounces+m-
>> >karicheri2=ti.com-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org [mailto:davinci-linux-open-
>source-
>> >bounces+m-karicheri2=ti.com-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org] On Behalf Of Kevin
>Hilman
>> >Sent: Wednesday, July 08, 2009 9:30 AM
>> >To: Ben Dooks
>> >Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-
>> >i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >Subject: Re: [PATCH 0/2] davinci i2c fixes for 2.6.31
>> >
>> >Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org> writes:
>> >
>> >> On Mon, Jul 06, 2009 at 03:48:34PM -0700, Kevin Hilman wrote:
>> >>> Here are a couple fixes for the i2c driver on the TI DaVinci family
>> >>> of SoCs.  These have been tested for awhile in the DaVinci git
>> >>> repo are needed for 2.6.31.
>> >>>
>> >>> These apply on v2.6.31-rc2.
>> >>
>> >> ok, do you have a git branch to pull, or should I apply
>> >> them from the mailing list>
>> >
>> >You can take from the list.  My git branch has a bunch of other
>> >non-i2c changes in it as well.
>> >
>> >Thanks,
>> >
>> >Kevin
>> >
>> >>> David Brownell (1):
>> >>>   i2c-davinci: behave with i2cdetect
>> >>>
>> >>> Kevin Hilman (1):
>> >>>   i2c-davinci: convert clock usage after clkdev conversion
>> >>>
>> >>>  drivers/i2c/busses/i2c-davinci.c |   20 +++++++++++++++-----
>> >>>  1 files changed, 15 insertions(+), 5 deletions(-)
>> >>>
>> >>> --
>> >>> To unsubscribe from this list: send the line "unsubscribe linux-i2c"
>in
>> >>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >>
>> >> --
>> >> Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)
>> >>
>> >>   'a smiley only costs 4 bytes'
>> >
>> >_______________________________________________
>> >Davinci-linux-open-source mailing list
>> >Davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
>> >http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Philby John]

Hello Murali,

On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
> Philby,
> 
> I tried running this patch against 2.6.31.rc2 (davinci kernel tree). But I got a crash as I run the application which is given below....
> 
> In my case, time out happens when I kill the capture application using Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by the host (during cleanup, i2c commands fails). When the application is run again, I get following outputs..
> 
> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> 
> Here are the complete log....
> 
> application running and pressed Cntrl-C ====>
> 
> time:105    frame:33
> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in subdev
> 
> Running it again .....
> 
> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0


I have now verified the code on a DM6446 and DM355, with
the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50 0x00
0x0000 w to kill the bus and then run the ./fbdev_loopback test to
recreate the issue. Recovery seems to happen with the new patch. Could
you try this out at your end, with the new patch?

Thanks and regards,
Philby

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Karicheri, Muralidharan]

John,

Thanks for working on this. I will give it a try tomorrow and let you know.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2-l0cyMroinI0@public.gmane.org

>-----Original Message-----
>From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>Sent: Monday, November 23, 2009 10:24 AM
>To: Karicheri, Muralidharan
>Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>
>Hello Murali,
>
>On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
>> Philby,
>>
>> I tried running this patch against 2.6.31.rc2 (davinci kernel tree). But
>I got a crash as I run the application which is given below....
>>
>> In my case, time out happens when I kill the capture application using
>Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by the
>host (during cleanup, i2c commands fails). When the application is run
>again, I get following outputs..
>>
>> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>>
>> Here are the complete log....
>>
>> application running and pressed Cntrl-C ====>
>>
>> time:105    frame:33
>> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in
>subdev
>>
>> Running it again .....
>>
>> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
>
>
>I have now verified the code on a DM6446 and DM355, with
>the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50 0x00
>0x0000 w to kill the bus and then run the ./fbdev_loopback test to
>recreate the issue. Recovery seems to happen with the new patch. Could
>you try this out at your end, with the new patch?
>
>Thanks and regards,
>Philby
>

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Karicheri, Muralidharan]

Philby,

Is this a generic solution which works on DM365 as well?

Why did you do the following command?

#./i2cset -y 0 0x50 0x00

Using the Arago tree kernel I was able to reproduce the issue
by doing

./fbdev_loopback -i2 -d0

and then press Control C. I am not sure why you run the command
./i2cset -y 0 0x50 0x00


Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2-l0cyMroinI0@public.gmane.org

>-----Original Message-----
>From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>Sent: Monday, November 23, 2009 10:24 AM
>To: Karicheri, Muralidharan
>Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>
>Hello Murali,
>
>On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
>> Philby,
>>
>> I tried running this patch against 2.6.31.rc2 (davinci kernel tree). But
>I got a crash as I run the application which is given below....
>>
>> In my case, time out happens when I kill the capture application using
>Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by the
>host (during cleanup, i2c commands fails). When the application is run
>again, I get following outputs..
>>
>> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>>
>> Here are the complete log....
>>
>> application running and pressed Cntrl-C ====>
>>
>> time:105    frame:33
>> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in
>subdev
>>
>> Running it again .....
>>
>> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
>
>
>I have now verified the code on a DM6446 and DM355, with
>the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50 0x00
>0x0000 w to kill the bus and then run the ./fbdev_loopback test to
>recreate the issue. Recovery seems to happen with the new patch. Could
>you try this out at your end, with the new patch?
>
>Thanks and regards,
>Philby
>

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Philby John]

Murali,

	The patch works for DM6446 and DM355 only. To get it to work for DM365
one must update the gpio pin number variables (sda_pin and scl_pin) in
struct davinci_i2c_platform_data for each platform.

I do not have the pin number information for other Davinci platforms.
This was mentioned in the comment section of the patch v2...

"TODO: Need to add SDA and SCL pin numbers to the respective
platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
What I have info on is limited to just dm355 and dm6446."

If someone can provide me with the relevant information, I could update
for all.

I used "./i2cset -y 0 0x50 0x00" cause its the only way to kill the i2c
bus on a 2.6.18 kernel with DVSDK 2.0. FYI, I do not know how to
generate cmem.ko for the Arago tree kernel that would get
"fbdev_loopback" running.

Regards,
Philby


On Thu, 2009-12-03 at 09:45 -0600, Karicheri, Muralidharan wrote:
> Philby,
> 
> Is this a generic solution which works on DM365 as well?
> 
> Why did you do the following command?
> 
> #./i2cset -y 0 0x50 0x00
> 
> Using the Arago tree kernel I was able to reproduce the issue
> by doing
> 
> ./fbdev_loopback -i2 -d0
> 
> and then press Control C. I am not sure why you run the command
> ./i2cset -y 0 0x50 0x00
> 
> 
> Murali Karicheri
> Software Design Engineer
> Texas Instruments Inc.
> Germantown, MD 20874
> phone: 301-407-9583
> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> 
> >-----Original Message-----
> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
> >Sent: Monday, November 23, 2009 10:24 AM
> >To: Karicheri, Muralidharan
> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >
> >Hello Murali,
> >
> >On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
> >> Philby,
> >>
> >> I tried running this patch against 2.6.31.rc2 (davinci kernel tree). But
> >I got a crash as I run the application which is given below....
> >>
> >> In my case, time out happens when I kill the capture application using
> >Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by the
> >host (during cleanup, i2c commands fails). When the application is run
> >again, I get following outputs..
> >>
> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> >>
> >> Here are the complete log....
> >>
> >> application running and pressed Cntrl-C ====>
> >>
> >> time:105    frame:33
> >> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in
> >subdev
> >>
> >> Running it again .....
> >>
> >> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
> >
> >
> >I have now verified the code on a DM6446 and DM355, with
> >the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50 0x00
> >0x0000 w to kill the bus and then run the ./fbdev_loopback test to
> >recreate the issue. Recovery seems to happen with the new patch. Could
> >you try this out at your end, with the new patch?
> >
> >Thanks and regards,
> >Philby
> >
> 

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Karicheri, Muralidharan]

Philby,

So where is the patch for adding davinci_i2c_platform_data in the platform
file? Could you send it please?

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2-l0cyMroinI0@public.gmane.org

>-----Original Message-----
>From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>Sent: Thursday, December 03, 2009 11:12 AM
>To: Karicheri, Muralidharan
>Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>
>Murali,
>
>	The patch works for DM6446 and DM355 only. To get it to work for
>DM365
>one must update the gpio pin number variables (sda_pin and scl_pin) in
>struct davinci_i2c_platform_data for each platform.
>
>I do not have the pin number information for other Davinci platforms.
>This was mentioned in the comment section of the patch v2...
>
>"TODO: Need to add SDA and SCL pin numbers to the respective
>platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
>What I have info on is limited to just dm355 and dm6446."
>
>If someone can provide me with the relevant information, I could update
>for all.
>
>I used "./i2cset -y 0 0x50 0x00" cause its the only way to kill the i2c
>bus on a 2.6.18 kernel with DVSDK 2.0. FYI, I do not know how to
>generate cmem.ko for the Arago tree kernel that would get
>"fbdev_loopback" running.
>
>Regards,
>Philby
>
>
>On Thu, 2009-12-03 at 09:45 -0600, Karicheri, Muralidharan wrote:
>> Philby,
>>
>> Is this a generic solution which works on DM365 as well?
>>
>> Why did you do the following command?
>>
>> #./i2cset -y 0 0x50 0x00
>>
>> Using the Arago tree kernel I was able to reproduce the issue
>> by doing
>>
>> ./fbdev_loopback -i2 -d0
>>
>> and then press Control C. I am not sure why you run the command
>> ./i2cset -y 0 0x50 0x00
>>
>>
>> Murali Karicheri
>> Software Design Engineer
>> Texas Instruments Inc.
>> Germantown, MD 20874
>> phone: 301-407-9583
>> email: m-karicheri2-l0cyMroinI0@public.gmane.org
>>
>> >-----Original Message-----
>> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>> >Sent: Monday, November 23, 2009 10:24 AM
>> >To: Karicheri, Muralidharan
>> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>> >
>> >Hello Murali,
>> >
>> >On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
>> >> Philby,
>> >>
>> >> I tried running this patch against 2.6.31.rc2 (davinci kernel tree).
>But
>> >I got a crash as I run the application which is given below....
>> >>
>> >> In my case, time out happens when I kill the capture application using
>> >Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by
>the
>> >host (during cleanup, i2c commands fails). When the application is run
>> >again, I get following outputs..
>> >>
>> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>> >>
>> >> Here are the complete log....
>> >>
>> >> application running and pressed Cntrl-C ====>
>> >>
>> >> time:105    frame:33
>> >> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in
>> >subdev
>> >>
>> >> Running it again .....
>> >>
>> >> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
>> >
>> >
>> >I have now verified the code on a DM6446 and DM355, with
>> >the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50 0x00
>> >0x0000 w to kill the bus and then run the ./fbdev_loopback test to
>> >recreate the issue. Recovery seems to happen with the new patch. Could
>> >you try this out at your end, with the new patch?
>> >
>> >Thanks and regards,
>> >Philby
>> >
>>

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Philby John]

[-- Attachment #1: Type: text/plain, Size: 4442 bytes --]

Murali,

	It was sent already, patch with subject "[PATCH v2] i2c: Davinci i2c
bus recovery procedure to clear the bus". Attaching here for your
convenience.

Regards,
Philby


On Thu, 2009-12-03 at 10:33 -0600, Karicheri, Muralidharan wrote:
> Philby,
> 
> So where is the patch for adding davinci_i2c_platform_data in the platform
> file? Could you send it please?
> 
> Murali Karicheri
> Software Design Engineer
> Texas Instruments Inc.
> Germantown, MD 20874
> phone: 301-407-9583
> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> 
> >-----Original Message-----
> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
> >Sent: Thursday, December 03, 2009 11:12 AM
> >To: Karicheri, Muralidharan
> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >
> >Murali,
> >
> >	The patch works for DM6446 and DM355 only. To get it to work for
> >DM365
> >one must update the gpio pin number variables (sda_pin and scl_pin) in
> >struct davinci_i2c_platform_data for each platform.
> >
> >I do not have the pin number information for other Davinci platforms.
> >This was mentioned in the comment section of the patch v2...
> >
> >"TODO: Need to add SDA and SCL pin numbers to the respective
> >platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
> >What I have info on is limited to just dm355 and dm6446."
> >
> >If someone can provide me with the relevant information, I could update
> >for all.
> >
> >I used "./i2cset -y 0 0x50 0x00" cause its the only way to kill the i2c
> >bus on a 2.6.18 kernel with DVSDK 2.0. FYI, I do not know how to
> >generate cmem.ko for the Arago tree kernel that would get
> >"fbdev_loopback" running.
> >
> >Regards,
> >Philby
> >
> >
> >On Thu, 2009-12-03 at 09:45 -0600, Karicheri, Muralidharan wrote:
> >> Philby,
> >>
> >> Is this a generic solution which works on DM365 as well?
> >>
> >> Why did you do the following command?
> >>
> >> #./i2cset -y 0 0x50 0x00
> >>
> >> Using the Arago tree kernel I was able to reproduce the issue
> >> by doing
> >>
> >> ./fbdev_loopback -i2 -d0
> >>
> >> and then press Control C. I am not sure why you run the command
> >> ./i2cset -y 0 0x50 0x00
> >>
> >>
> >> Murali Karicheri
> >> Software Design Engineer
> >> Texas Instruments Inc.
> >> Germantown, MD 20874
> >> phone: 301-407-9583
> >> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> >>
> >> >-----Original Message-----
> >> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
> >> >Sent: Monday, November 23, 2009 10:24 AM
> >> >To: Karicheri, Muralidharan
> >> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
> >> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >> >
> >> >Hello Murali,
> >> >
> >> >On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
> >> >> Philby,
> >> >>
> >> >> I tried running this patch against 2.6.31.rc2 (davinci kernel tree).
> >But
> >> >I got a crash as I run the application which is given below....
> >> >>
> >> >> In my case, time out happens when I kill the capture application using
> >> >Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by
> >the
> >> >host (during cleanup, i2c commands fails). When the application is run
> >> >again, I get following outputs..
> >> >>
> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> >> >>
> >> >> Here are the complete log....
> >> >>
> >> >> application running and pressed Cntrl-C ====>
> >> >>
> >> >> time:105    frame:33
> >> >> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in
> >> >subdev
> >> >>
> >> >> Running it again .....
> >> >>
> >> >> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
> >> >
> >> >
> >> >I have now verified the code on a DM6446 and DM355, with
> >> >the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50 0x00
> >> >0x0000 w to kill the bus and then run the ./fbdev_loopback test to
> >> >recreate the issue. Recovery seems to happen with the new patch. Could
> >> >you try this out at your end, with the new patch?
> >> >
> >> >Thanks and regards,
> >> >Philby
> >> >
> >>
> 

[-- Attachment #2: 0001-Davinci-i2c-bus-recovery-procedure-to-clear-the-bus.patch --]
[-- Type: text/x-patch, Size: 5747 bytes --]

>From 0372e68cfd14ab37595498234abe39f2f10787d5 Mon Sep 17 00:00:00 2001
From: Philby John <pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org>
Date: Mon, 23 Nov 2009 18:08:33 +0530
Subject: [PATCH] Davinci i2c bus recovery procedure to clear the bus

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>
---
 arch/arm/mach-davinci/board-dm355-evm.c  |    2 +
 arch/arm/mach-davinci/board-dm644x-evm.c |    2 +
 arch/arm/mach-davinci/include/mach/i2c.h |    2 +
 drivers/i2c/busses/i2c-davinci.c         |   60 +++++++++++++++++++++++++++---
 4 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index a9b650d..a20b2de 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -111,6 +111,8 @@ static struct platform_device davinci_nand_device = {
 static struct davinci_i2c_platform_data i2c_pdata = {
 	.bus_freq	= 400	/* kHz */,
 	.bus_delay	= 0	/* usec */,
+	.sda_pin	= 15,
+	.scl_pin	= 14,
 };
 
 static struct snd_platform_data dm355_evm_snd_data;
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index fd0398b..b5ce36b 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -628,6 +628,8 @@ static struct i2c_board_info __initdata i2c_info[] =  {
 static struct davinci_i2c_platform_data i2c_pdata = {
 	.bus_freq	= 20 /* kHz */,
 	.bus_delay	= 100 /* usec */,
+	.sda_pin	= 44,
+	.scl_pin	= 43,
 };
 
 static void __init evm_init_i2c(void)
diff --git a/arch/arm/mach-davinci/include/mach/i2c.h b/arch/arm/mach-davinci/include/mach/i2c.h
index c248e9b..21be118 100644
--- a/arch/arm/mach-davinci/include/mach/i2c.h
+++ b/arch/arm/mach-davinci/include/mach/i2c.h
@@ -16,6 +16,8 @@
 struct davinci_i2c_platform_data {
 	unsigned int	bus_freq;	/* standard bus frequency (kHz) */
 	unsigned int	bus_delay;	/* post-transaction delay (usec) */
+	unsigned int	sda_pin;	/* GPIO pin ID to use for SDA */
+	unsigned int	scl_pin;	/* GPIO pin ID to use for SCL */
 };
 
 /* for board setup code */
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 67d88cc..be18cab 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -35,6 +35,7 @@
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
+#include <linux/gpio.h>
 
 #include <mach/hardware.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 | \
@@ -134,6 +136,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);
+	MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1);
+	davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+}
+
 /*
  * This functions configures I2C and brings I2C out of reset.
  * This function is called during I2C init function. This function
@@ -221,19 +261,26 @@ static int i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev,
 					 char allow_sleep)
 {
 	unsigned long timeout;
+	static u16 to_cnt = 0;
 
 	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;
+			& DAVINCI_I2C_STR_BB) {
+		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);
 	}
-
 	return 0;
 }
 
@@ -310,6 +357,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
 						      dev->adapter.timeout);
 	if (r == 0) {
 		dev_err(dev->dev, "controller timed out\n");
+		i2c_recover_bus(dev);
 		i2c_davinci_init(dev);
 		dev->buf_len = 0;
 		return -ETIMEDOUT;
-- 
1.6.3.3.MVISTA

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Philby John]

Murali,

	It would be excellent if you could verify the patch on a DM6446 first
and perhaps then make changes for DM365.

Regards,
Philby



On Thu, 2009-12-03 at 10:33 -0600, Karicheri, Muralidharan wrote:
> Philby,
> 
> So where is the patch for adding davinci_i2c_platform_data in the platform
> file? Could you send it please?
> 
> Murali Karicheri
> Software Design Engineer
> Texas Instruments Inc.
> Germantown, MD 20874
> phone: 301-407-9583
> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> 
> >-----Original Message-----
> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
> >Sent: Thursday, December 03, 2009 11:12 AM
> >To: Karicheri, Muralidharan
> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >
> >Murali,
> >
> >	The patch works for DM6446 and DM355 only. To get it to work for
> >DM365
> >one must update the gpio pin number variables (sda_pin and scl_pin) in
> >struct davinci_i2c_platform_data for each platform.
> >
> >I do not have the pin number information for other Davinci platforms.
> >This was mentioned in the comment section of the patch v2...
> >
> >"TODO: Need to add SDA and SCL pin numbers to the respective
> >platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
> >What I have info on is limited to just dm355 and dm6446."
> >
> >If someone can provide me with the relevant information, I could update
> >for all.
> >
> >I used "./i2cset -y 0 0x50 0x00" cause its the only way to kill the i2c
> >bus on a 2.6.18 kernel with DVSDK 2.0. FYI, I do not know how to
> >generate cmem.ko for the Arago tree kernel that would get
> >"fbdev_loopback" running.
> >
> >Regards,
> >Philby
> >
> >
> >On Thu, 2009-12-03 at 09:45 -0600, Karicheri, Muralidharan wrote:
> >> Philby,
> >>
> >> Is this a generic solution which works on DM365 as well?
> >>
> >> Why did you do the following command?
> >>
> >> #./i2cset -y 0 0x50 0x00
> >>
> >> Using the Arago tree kernel I was able to reproduce the issue
> >> by doing
> >>
> >> ./fbdev_loopback -i2 -d0
> >>
> >> and then press Control C. I am not sure why you run the command
> >> ./i2cset -y 0 0x50 0x00
> >>
> >>
> >> Murali Karicheri
> >> Software Design Engineer
> >> Texas Instruments Inc.
> >> Germantown, MD 20874
> >> phone: 301-407-9583
> >> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> >>
> >> >-----Original Message-----
> >> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
> >> >Sent: Monday, November 23, 2009 10:24 AM
> >> >To: Karicheri, Muralidharan
> >> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
> >> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >> >
> >> >Hello Murali,
> >> >
> >> >On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
> >> >> Philby,
> >> >>
> >> >> I tried running this patch against 2.6.31.rc2 (davinci kernel tree).
> >But
> >> >I got a crash as I run the application which is given below....
> >> >>
> >> >> In my case, time out happens when I kill the capture application using
> >> >Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by
> >the
> >> >host (during cleanup, i2c commands fails). When the application is run
> >> >again, I get following outputs..
> >> >>
> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> >> >>
> >> >> Here are the complete log....
> >> >>
> >> >> application running and pressed Cntrl-C ====>
> >> >>
> >> >> time:105    frame:33
> >> >> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in
> >> >subdev
> >> >>
> >> >> Running it again .....
> >> >>
> >> >> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
> >> >
> >> >
> >> >I have now verified the code on a DM6446 and DM355, with
> >> >the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50 0x00
> >> >0x0000 w to kill the bus and then run the ./fbdev_loopback test to
> >> >recreate the issue. Recovery seems to happen with the new patch. Could
> >> >you try this out at your end, with the new patch?
> >> >
> >> >Thanks and regards,
> >> >Philby
> >> >
> >>
> 

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Karicheri, Muralidharan]

I can verify on DM355. But I will be running latest kernel on Arago. I have manually merged your patch. Did it worked on DM355?

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2-l0cyMroinI0@public.gmane.org

>-----Original Message-----
>From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>Sent: Thursday, December 03, 2009 11:50 AM
>To: Karicheri, Muralidharan
>Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>
>Murali,
>
>	It would be excellent if you could verify the patch on a DM6446 first
>and perhaps then make changes for DM365.
>
>Regards,
>Philby
>
>
>
>On Thu, 2009-12-03 at 10:33 -0600, Karicheri, Muralidharan wrote:
>> Philby,
>>
>> So where is the patch for adding davinci_i2c_platform_data in the
>platform
>> file? Could you send it please?
>>
>> Murali Karicheri
>> Software Design Engineer
>> Texas Instruments Inc.
>> Germantown, MD 20874
>> phone: 301-407-9583
>> email: m-karicheri2-l0cyMroinI0@public.gmane.org
>>
>> >-----Original Message-----
>> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>> >Sent: Thursday, December 03, 2009 11:12 AM
>> >To: Karicheri, Muralidharan
>> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>> >
>> >Murali,
>> >
>> >	The patch works for DM6446 and DM355 only. To get it to work for
>> >DM365
>> >one must update the gpio pin number variables (sda_pin and scl_pin) in
>> >struct davinci_i2c_platform_data for each platform.
>> >
>> >I do not have the pin number information for other Davinci platforms.
>> >This was mentioned in the comment section of the patch v2...
>> >
>> >"TODO: Need to add SDA and SCL pin numbers to the respective
>> >platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
>> >What I have info on is limited to just dm355 and dm6446."
>> >
>> >If someone can provide me with the relevant information, I could update
>> >for all.
>> >
>> >I used "./i2cset -y 0 0x50 0x00" cause its the only way to kill the i2c
>> >bus on a 2.6.18 kernel with DVSDK 2.0. FYI, I do not know how to
>> >generate cmem.ko for the Arago tree kernel that would get
>> >"fbdev_loopback" running.
>> >
>> >Regards,
>> >Philby
>> >
>> >
>> >On Thu, 2009-12-03 at 09:45 -0600, Karicheri, Muralidharan wrote:
>> >> Philby,
>> >>
>> >> Is this a generic solution which works on DM365 as well?
>> >>
>> >> Why did you do the following command?
>> >>
>> >> #./i2cset -y 0 0x50 0x00
>> >>
>> >> Using the Arago tree kernel I was able to reproduce the issue
>> >> by doing
>> >>
>> >> ./fbdev_loopback -i2 -d0
>> >>
>> >> and then press Control C. I am not sure why you run the command
>> >> ./i2cset -y 0 0x50 0x00
>> >>
>> >>
>> >> Murali Karicheri
>> >> Software Design Engineer
>> >> Texas Instruments Inc.
>> >> Germantown, MD 20874
>> >> phone: 301-407-9583
>> >> email: m-karicheri2-l0cyMroinI0@public.gmane.org
>> >>
>> >> >-----Original Message-----
>> >> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>> >> >Sent: Monday, November 23, 2009 10:24 AM
>> >> >To: Karicheri, Muralidharan
>> >> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>> >> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>> >> >
>> >> >Hello Murali,
>> >> >
>> >> >On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
>> >> >> Philby,
>> >> >>
>> >> >> I tried running this patch against 2.6.31.rc2 (davinci kernel tree).
>> >But
>> >> >I got a crash as I run the application which is given below....
>> >> >>
>> >> >> In my case, time out happens when I kill the capture application
>using
>> >> >Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted
>by
>> >the
>> >> >host (during cleanup, i2c commands fails). When the application is
>run
>> >> >again, I get following outputs..
>> >> >>
>> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>> >> >>
>> >> >> Here are the complete log....
>> >> >>
>> >> >> application running and pressed Cntrl-C ====>
>> >> >>
>> >> >> time:105    frame:33
>> >> >> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in
>> >> >subdev
>> >> >>
>> >> >> Running it again .....
>> >> >>
>> >> >> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
>> >> >
>> >> >
>> >> >I have now verified the code on a DM6446 and DM355, with
>> >> >the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50
>0x00
>> >> >0x0000 w to kill the bus and then run the ./fbdev_loopback test to
>> >> >recreate the issue. Recovery seems to happen with the new patch.
>Could
>> >> >you try this out at your end, with the new patch?
>> >> >
>> >> >Thanks and regards,
>> >> >Philby
>> >> >
>> >>
>>

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Philby John]

Yes, it did (on DM355).
Let me know the result and I could also use the log in case of a kernel
dump.

Thanks.
Philby

On Thu, 2009-12-03 at 12:01 -0600, Karicheri, Muralidharan wrote:
> I can verify on DM355. But I will be running latest kernel on Arago. I have manually merged your patch. Did it worked on DM355?
> 
> Murali Karicheri
> Software Design Engineer
> Texas Instruments Inc.
> Germantown, MD 20874
> phone: 301-407-9583
> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> 
> >-----Original Message-----
> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
> >Sent: Thursday, December 03, 2009 11:50 AM
> >To: Karicheri, Muralidharan
> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >
> >Murali,
> >
> >	It would be excellent if you could verify the patch on a DM6446 first
> >and perhaps then make changes for DM365.
> >
> >Regards,
> >Philby
> >
> >
> >
> >On Thu, 2009-12-03 at 10:33 -0600, Karicheri, Muralidharan wrote:
> >> Philby,
> >>
> >> So where is the patch for adding davinci_i2c_platform_data in the
> >platform
> >> file? Could you send it please?
> >>
> >> Murali Karicheri
> >> Software Design Engineer
> >> Texas Instruments Inc.
> >> Germantown, MD 20874
> >> phone: 301-407-9583
> >> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> >>
> >> >-----Original Message-----
> >> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
> >> >Sent: Thursday, December 03, 2009 11:12 AM
> >> >To: Karicheri, Muralidharan
> >> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
> >> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >> >
> >> >Murali,
> >> >
> >> >	The patch works for DM6446 and DM355 only. To get it to work for
> >> >DM365
> >> >one must update the gpio pin number variables (sda_pin and scl_pin) in
> >> >struct davinci_i2c_platform_data for each platform.
> >> >
> >> >I do not have the pin number information for other Davinci platforms.
> >> >This was mentioned in the comment section of the patch v2...
> >> >
> >> >"TODO: Need to add SDA and SCL pin numbers to the respective
> >> >platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
> >> >What I have info on is limited to just dm355 and dm6446."
> >> >
> >> >If someone can provide me with the relevant information, I could update
> >> >for all.
> >> >
> >> >I used "./i2cset -y 0 0x50 0x00" cause its the only way to kill the i2c
> >> >bus on a 2.6.18 kernel with DVSDK 2.0. FYI, I do not know how to
> >> >generate cmem.ko for the Arago tree kernel that would get
> >> >"fbdev_loopback" running.
> >> >
> >> >Regards,
> >> >Philby
> >> >
> >> >
> >> >On Thu, 2009-12-03 at 09:45 -0600, Karicheri, Muralidharan wrote:
> >> >> Philby,
> >> >>
> >> >> Is this a generic solution which works on DM365 as well?
> >> >>
> >> >> Why did you do the following command?
> >> >>
> >> >> #./i2cset -y 0 0x50 0x00
> >> >>
> >> >> Using the Arago tree kernel I was able to reproduce the issue
> >> >> by doing
> >> >>
> >> >> ./fbdev_loopback -i2 -d0
> >> >>
> >> >> and then press Control C. I am not sure why you run the command
> >> >> ./i2cset -y 0 0x50 0x00
> >> >>
> >> >>
> >> >> Murali Karicheri
> >> >> Software Design Engineer
> >> >> Texas Instruments Inc.
> >> >> Germantown, MD 20874
> >> >> phone: 301-407-9583
> >> >> email: m-karicheri2-l0cyMroinI0@public.gmane.org
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
> >> >> >Sent: Monday, November 23, 2009 10:24 AM
> >> >> >To: Karicheri, Muralidharan
> >> >> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
> >> >> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> >> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
> >> >> >
> >> >> >Hello Murali,
> >> >> >
> >> >> >On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
> >> >> >> Philby,
> >> >> >>
> >> >> >> I tried running this patch against 2.6.31.rc2 (davinci kernel tree).
> >> >But
> >> >> >I got a crash as I run the application which is given below....
> >> >> >>
> >> >> >> In my case, time out happens when I kill the capture application
> >using
> >> >> >Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted
> >by
> >> >the
> >> >> >host (during cleanup, i2c commands fails). When the application is
> >run
> >> >> >again, I get following outputs..
> >> >> >>
> >> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> >> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
> >> >> >>
> >> >> >> Here are the complete log....
> >> >> >>
> >> >> >> application running and pressed Cntrl-C ====>
> >> >> >>
> >> >> >> time:105    frame:33
> >> >> >> time:105    frame:34vpfe-capture vpfe-capture: stream off failed in
> >> >> >subdev
> >> >> >>
> >> >> >> Running it again .....
> >> >> >>
> >> >> >> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
> >> >> >
> >> >> >
> >> >> >I have now verified the code on a DM6446 and DM355, with
> >> >> >the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50
> >0x00
> >> >> >0x0000 w to kill the bus and then run the ./fbdev_loopback test to
> >> >> >recreate the issue. Recovery seems to happen with the new patch.
> >Could
> >> >> >you try this out at your end, with the new patch?
> >> >> >
> >> >> >Thanks and regards,
> >> >> >Philby
> >> >> >
> >> >>
> >>
> 

RE: [PATCH 0/2] davinci i2c fixes for 2.6.31

[Karicheri, Muralidharan]

Philby,

My MT9T031 sensor has some problem (i2c stopped responding). So I need to get a sensor to test your fix.  Let you know if I could test it.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-karicheri2-l0cyMroinI0@public.gmane.org

>-----Original Message-----
>From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>Sent: Thursday, December 03, 2009 1:11 PM
>To: Karicheri, Muralidharan
>Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>
>Yes, it did (on DM355).
>Let me know the result and I could also use the log in case of a kernel
>dump.
>
>Thanks.
>Philby
>
>On Thu, 2009-12-03 at 12:01 -0600, Karicheri, Muralidharan wrote:
>> I can verify on DM355. But I will be running latest kernel on Arago. I
>have manually merged your patch. Did it worked on DM355?
>>
>> Murali Karicheri
>> Software Design Engineer
>> Texas Instruments Inc.
>> Germantown, MD 20874
>> phone: 301-407-9583
>> email: m-karicheri2-l0cyMroinI0@public.gmane.org
>>
>> >-----Original Message-----
>> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>> >Sent: Thursday, December 03, 2009 11:50 AM
>> >To: Karicheri, Muralidharan
>> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>> >
>> >Murali,
>> >
>> >	It would be excellent if you could verify the patch on a DM6446 first
>> >and perhaps then make changes for DM365.
>> >
>> >Regards,
>> >Philby
>> >
>> >
>> >
>> >On Thu, 2009-12-03 at 10:33 -0600, Karicheri, Muralidharan wrote:
>> >> Philby,
>> >>
>> >> So where is the patch for adding davinci_i2c_platform_data in the
>> >platform
>> >> file? Could you send it please?
>> >>
>> >> Murali Karicheri
>> >> Software Design Engineer
>> >> Texas Instruments Inc.
>> >> Germantown, MD 20874
>> >> phone: 301-407-9583
>> >> email: m-karicheri2-l0cyMroinI0@public.gmane.org
>> >>
>> >> >-----Original Message-----
>> >> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>> >> >Sent: Thursday, December 03, 2009 11:12 AM
>> >> >To: Karicheri, Muralidharan
>> >> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>> >> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>> >> >
>> >> >Murali,
>> >> >
>> >> >	The patch works for DM6446 and DM355 only. To get it to work
>for
>> >> >DM365
>> >> >one must update the gpio pin number variables (sda_pin and scl_pin)
>in
>> >> >struct davinci_i2c_platform_data for each platform.
>> >> >
>> >> >I do not have the pin number information for other Davinci platforms.
>> >> >This was mentioned in the comment section of the patch v2...
>> >> >
>> >> >"TODO: Need to add SDA and SCL pin numbers to the respective
>> >> >platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
>> >> >What I have info on is limited to just dm355 and dm6446."
>> >> >
>> >> >If someone can provide me with the relevant information, I could
>update
>> >> >for all.
>> >> >
>> >> >I used "./i2cset -y 0 0x50 0x00" cause its the only way to kill the
>i2c
>> >> >bus on a 2.6.18 kernel with DVSDK 2.0. FYI, I do not know how to
>> >> >generate cmem.ko for the Arago tree kernel that would get
>> >> >"fbdev_loopback" running.
>> >> >
>> >> >Regards,
>> >> >Philby
>> >> >
>> >> >
>> >> >On Thu, 2009-12-03 at 09:45 -0600, Karicheri, Muralidharan wrote:
>> >> >> Philby,
>> >> >>
>> >> >> Is this a generic solution which works on DM365 as well?
>> >> >>
>> >> >> Why did you do the following command?
>> >> >>
>> >> >> #./i2cset -y 0 0x50 0x00
>> >> >>
>> >> >> Using the Arago tree kernel I was able to reproduce the issue
>> >> >> by doing
>> >> >>
>> >> >> ./fbdev_loopback -i2 -d0
>> >> >>
>> >> >> and then press Control C. I am not sure why you run the command
>> >> >> ./i2cset -y 0 0x50 0x00
>> >> >>
>> >> >>
>> >> >> Murali Karicheri
>> >> >> Software Design Engineer
>> >> >> Texas Instruments Inc.
>> >> >> Germantown, MD 20874
>> >> >> phone: 301-407-9583
>> >> >> email: m-karicheri2-l0cyMroinI0@public.gmane.org
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >From: Philby John [mailto:pjohn-k0rHJ+Hhz/SB+jHODAdFcQ@public.gmane.org]
>> >> >> >Sent: Monday, November 23, 2009 10:24 AM
>> >> >> >To: Karicheri, Muralidharan
>> >> >> >Cc: Kevin Hilman; Ben Dooks; davinci-linux-open-
>> >> >> >source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> >> >> >Subject: RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
>> >> >> >
>> >> >> >Hello Murali,
>> >> >> >
>> >> >> >On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote:
>> >> >> >> Philby,
>> >> >> >>
>> >> >> >> I tried running this patch against 2.6.31.rc2 (davinci kernel
>tree).
>> >> >But
>> >> >> >I got a crash as I run the application which is given below....
>> >> >> >>
>> >> >> >> In my case, time out happens when I kill the capture application
>> >using
>> >> >> >Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be
>contacted
>> >by
>> >> >the
>> >> >> >host (during cleanup, i2c commands fails). When the application is
>> >run
>> >> >> >again, I get following outputs..
>> >> >> >>
>> >> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>> >> >> >> i2c_davinci i2c_davinci.1: timeout waiting for bus ready
>> >> >> >>
>> >> >> >> Here are the complete log....
>> >> >> >>
>> >> >> >> application running and pressed Cntrl-C ====>
>> >> >> >>
>> >> >> >> time:105    frame:33
>> >> >> >> time:105    frame:34vpfe-capture vpfe-capture: stream off failed
>in
>> >> >> >subdev
>> >> >> >>
>> >> >> >> Running it again .....
>> >> >> >>
>> >> >> >> root-fKfTphxkbEe3Z1R/gWBstg@public.gmane.org:/opt/git# ./fbdev_loopback -i2 -d0
>> >> >> >
>> >> >> >
>> >> >> >I have now verified the code on a DM6446 and DM355, with
>> >> >> >the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50
>> >0x00
>> >> >> >0x0000 w to kill the bus and then run the ./fbdev_loopback test to
>> >> >> >recreate the issue. Recovery seems to happen with the new patch.
>> >Could
>> >> >> >you try this out at your end, with the new patch?
>> >> >> >
>> >> >> >Thanks and regards,
>> >> >> >Philby
>> >> >> >
>> >> >>
>> >>
>>