Re: [PATCH V10 Resend] i2c/designware: Provide i2c bus recovery support

2013-07-24 Thread Viresh Kumar
On 17 June 2013 18:46, Viresh Kumar viresh.ku...@linaro.org 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-off-by: Vincenzo Frascino vincenzo.frasc...@st.com
 Signed-off-by: Shiraz Hashim shiraz.has...@st.com
 Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
 ---

 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(-)

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


i2c-mux: expose i2c bus topology under sysfs

2013-07-24 Thread Jeroen De Wachter
Hi, 

I was wondering what the status was on the patches submitted by Gerlando 
Falauto a while ago to expose the i2c bus topology through sysfs?
http://www.spinics.net/lists/linux-i2c/msg11542.html

I checked with kernel 3.11-rc2 and nothing seems to have been provided to 
figure out the topology in sysfs. Has this been added to the wsa kernel and not 
yet to mainline?

Or is there a different mechanism to get that information that I'm missing?

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


Re: [PATCH 1/2] i2c-designware: make *CNT values configurable

2013-07-24 Thread Shinya Kuribayashi

On 7/22/13 10:17 PM, Christian Ruppert wrote: On Wed, Jul 17, 2013 at 
11:39:58PM +0900, Shinya Kuribayashi wrote:

On 7/16/13 8:16 PM, Christian Ruppert wrote: On Sat, Jul 13, 2013 at 
02:36:43PM +0900, Shinya Kuribayashi wrote:

Basically, DW I2C core provides a good enough (and quite direct) way
to control tHIGH and tLOW timing specs, *HCNT and *LCNT registers.

But from my experience (with a slightly old version of DW I2C core
around 2005, version 1.06a or so), DW I2C core was apparently lacking
in an appropriate hardware mechanism to meet tHD;STA timing spec.  We
then found that we could meet tHD;STA by increasing *HCNT values, so
that's what currently we have in i2c-designware.c  I know with that
workaround applied, tHIGH is to be configured with a larger value
than necessary, but we have no choice.  For I2C bus systems, we must
meet every timing constraint strictly as required.  If DW I2C core
cannot meet tHD;STA without the sacrifice of tHIGH, and I would call
it a hardware bug.


I agree. However, tHD;STA [min] is defined to the same value as tHIGH
[min] for all modes in the I2C specification. Do I understand you
correctly that the SCL_HCNT parameters control at the same time tHIGH
and tHD;STA?


*HCNT value does affect both tHIGH and tHD;STA at the same time.
But we have to make sure that composition of tHIGH is different
from the one of tHD;STA.

For tHIGH
--

DW I2C core is aware of the SCL rising transition (tr) and can
ignore it.  It starts counting the HIGH period of the SCL signal
(tHIGH) after the SCL input voltage increases at VIH.

This is described in the data book as an ideal configuration,
and the resulting formula would be:

HCNT + (1+4+3) = IC_CLK * tHIGH ... (a)

please refer to the data book for details about (1+4+3) part.

For tLOW


DW I2C core starts counting the SCL CNTs for the LOW period of
the SCL signal (tLOW) as soon as it pulls the SCL line _without_
_confirming_ the SCL input voltage decreases at VIL.

In order to meet the tLOW timing spec, we need to take into
account the fall time of SCL signal (tf), so the resulting
formula should be:

LCNT + 1 = IC_CLK * (tLOW + tf)

please refer to the data book for details about '+1' part.

For tHD;STA
---

There is no explanation about tHD;STA in the data book.  We
only have (my) experimental result; tHD;STA turned out to be
proportional to 'HCNT + 3'.  The formula is:

HCNT + 3 = IC_CLK * (tHD;STA + tf) ... (b)

DW I2C core seems to start counting the SCL CNTs for the HIGH
period of the SCL signel (tHD;STA) as soon as it pulls the _SDA_
line without confirming the SDA input voltage decreases at VIL,
so we have to take into account the SDA falling transition (tf)
here.

As can be expected from (a) and (b), if tHD;STA [min] is defined
to the same value as tHIGH [min], we need to have larger HCNT
value than necessary for tHIGH, to meet tHD;STA constraint.

[...]


Hrmmm... This makes my head spin. Do you think the following code
snippet represents an accurate method to calculate the register values?
If you agree I'll prepare a patch based on that for the DW I2C. The
question will be, however, how to obtain the transition times.


Please find my comments below.


/*
 *t_f;SDA
 *  |-|
 * _  _ . . .
 *  \/
 * SDA   \  /
 *\/   t_r;SCLt_f;SCL
 *   |-||-|
 * __   
 *   \ /\
 * SCL\   /  \
 * \_/\___ . . .
 *|--| |-| ||
 *t_HD;STAt_LOW  t_HIGH
 *
 *  ||---| ||
 * (   HCNT   LCNTHCNT   ) * 1/f_SYS


Composition is:  HCNT+3 LCNT+1  HCNT+(1+4+3)

The offsets for the HCNT are different in the cases of tHD;STA and
t_HIGH.  It's based on my experimental result and we can't know how
DW I2C core actually counts those period, but it can be easily
imagined that for DW I2C core, the way to count t_HD;STA is similar
to the way to count t_LOW; it starts counting CNTs as soon as it
pulls the SCL/SDA line, then waits for given CNTs.

I think your equations and snippet code are based on the assumption
that DW I2C core must be counting the number of CNTs for the HIGH
period of the SCL signal (that's t_HD;STA and t_HIGH) in the same
way, but I don't think so.  From my observation and experimental
results, it must be different.  We couldn't know what actually is,
though.


 *
 * HCNT = f_SYS * max(t_HD;STA + t_f;SDA , t_HIGH)
 *  = f_SYS * (t_HIGH + t_f;SDA)  because T_HD;STA == T_HIGH
 * LCNT = f_SYS * (t_f;SCL + t_LOW)
 * HCNT + LCNT + t_r;SCL = 1/f_SCL = t_SCL


As said before, all t_SCL things should go away.  Please forget
about 100kbps, 400kbps, and so on.  Bus/clock speed is totally
pointless concept for 

[PATCH 0/2] i2c: davinci: Couple of patches to make i2c usable on Keystone SOCs

2013-07-24 Thread Santosh Shilimkar
Keystone SOCs uses the same I2C IP as available on DaVinci SOCs. These
couple of patches makes it possible to select the I2C_DAVINCI on
Keystone SOCs.

Cc: Sekhar Nori nsek...@ti.com
Cc: Wolfram Sang w...@the-dreams.de

Santosh Shilimkar (2):
  i2c: davinci: remove useless mach/hardware include
  i2c: davinci: Allow i2c driver available for keystone platforms

 drivers/i2c/busses/Kconfig   |2 +-
 drivers/i2c/busses/i2c-davinci.c |1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

-- 
1.7.9.5

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


[PATCH 2/2] i2c: davinci: Allow i2c driver available for keystone platforms

2013-07-24 Thread Santosh Shilimkar
Keystone SOCs uses the same I2C IP as available on DaVinci SOCs.
Update the config so that ARCH_KEYSTONE can use it.

Cc: Sekhar Nori nsek...@ti.com
Cc: Wolfram Sang w...@the-dreams.de

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/i2c/busses/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index dc6dea6..fcdd321 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -385,7 +385,7 @@ config I2C_CPM
 
 config I2C_DAVINCI
tristate DaVinci I2C driver
-   depends on ARCH_DAVINCI
+   depends on ARCH_DAVINCI || ARCH_KEYSTONE
help
  Support for TI DaVinci I2C controller driver.
 
-- 
1.7.9.5

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


[PATCH 1/2] i2c: davinci: remove useless mach/hardware include

2013-07-24 Thread Santosh Shilimkar
This driver no longer uses definitions from mach/hardware.h.
On the other hand, including this header breaks this driver
on non-davinci platforms which don't have such a header.

Fix it.

Cc: Sekhar Nori nsek...@ti.com
Cc: Wolfram Sang w...@the-dreams.de

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/i2c/busses/i2c-davinci.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index fa55605..ddaa2a3 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -41,7 +41,6 @@
 #include linux/of_i2c.h
 #include linux/of_device.h
 
-#include mach/hardware.h
 #include linux/platform_data/i2c-davinci.h
 
 /* - global defines --- */
-- 
1.7.9.5

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