Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/17/2010 06:48 PM, Nori, Sekhar wrote:
Hi Philby,

On Wed, Mar 17, 2010 at 16:58:44, Philby John wrote:
On 03/17/2010 02:20 AM, Kevin Hilman wrote:
Philby John<pjohn@xxxxxxxxxx>   writes:

On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
Hi Philby,

On Fri, Feb 05, 2010 at 19:23:43, Philby John wrote:
Hello Sekhar,


[...]

+/* 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);
+             }

Before using the pins as GPIO, you would have to set the
functionality of these pins as GPIO. You had this code in
previous incarnations of this patch - not sure why it is
dropped now.


I now think that the previous versions were incorrect since
davinci_cfg_reg() does not set the scl or sda pins for gpio
functionality. Instead they set them as scl or sda which is not what
we want at the time of pulsing. The previous versions used
gpio_set_value() in disable_i2c_pins() and then called
davinci_cfg_reg(). After which it called pulse_i2c_clock().

Please correct me if my interpretation of the code is incorrect.

Can we get some resolution here?

I have a queue of davinci i2c patches waiting to go upstream, and I'd
like to get them in for 2.6.35.

The current i2c series is in the 'davinci-i2c' branch of davinci git.

To quote Sekhar, "...Right. It is only an enhancement (and only good
to have at that). This should not stop the current patch from getting
in." So this patch is good to make it to 2.6.35

How about the using the "free data format" method that Brad was
suggesting [1]? That sounds like a much simpler approach than the
GPIO muxing method that this patch is adopting.


I can't seem to agree with your argument. The recovery method adopted here is part of the standard i2c v3 spec.

I think we should try that method before accepting this approach
as the final one.

It would be wiser allowing this one to go in, since a lot of reviewing/testing has already been done. Later on we could try the "free data format" and hope that this would work. Otherwise, we would still be without a fix until "free data format" is done.


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

[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux