Re: [PATCH 1/1] fix i2c_msg.len not aligning with i2c_master_send
Hi, Jean Thanks for your instruction. Here is patch to modify some comments of i2c_master_send i2c_master_recv, is this OK. Where's the screaming things, dude? Thanks Zhangfei From 30fbf1ebf1facba3d280c887e2ecfd0499e7b04b Mon Sep 17 00:00:00 2001 From: Zhangfei Gao zg...@marvell.com Date: Sat, 6 Feb 2010 05:38:59 +0800 Subject: [PATCH] i2c: notes of i2c_master_send i2c_master_recv i2c_master_send i2c_master_recv not support more than 64bytes transfer, since msg.len is __u16 type Signed-off-by: Zhangfei Gao zg...@marvell.com --- Documentation/i2c/writing-clients | 3 ++- drivers/i2c/i2c-core.c | 4 ++-- include/linux/i2c.h | 1 + 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 7860aaf..929a3c3 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -318,7 +318,8 @@ Plain I2C communication These routines read and write some bytes from/to a client. The client contains the i2c address, so you do not have to include it. The second parameter contains the bytes to read/write, the third the number of bytes -to read/write (must be less than the length of the buffer.) Returned is +to read/write (must be less than the length of the buffer, also should be +less than 64K since msg.len is __u16 type.) Returned is the actual number of bytes read/written. int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg, diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 8d80fce..9607dcc 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -1112,7 +1112,7 @@ EXPORT_SYMBOL(i2c_transfer); * i2c_master_send - issue a single I2C message in master transmit mode * @client: Handle to slave device * @buf: Data that will be written to the slave - * @count: How many bytes to write + * @count: How many bytes to write, should be less than 64K since msg.len is u16 * * Returns negative errno, or else the number of bytes written. */ @@ -1139,7 +1139,7 @@ EXPORT_SYMBOL(i2c_master_send); * i2c_master_recv - issue a single I2C message in master receive mode * @client: Handle to slave device * @buf: Where to store data read from slave - * @count: How many bytes to read + * @count: How many bytes to read, should be less than 64K since msg.len is u16 * * Returns negative errno, or else the number of bytes read. */ diff --git a/include/linux/i2c.h b/include/linux/i2c.h index 57d41b0..b2dea18 100644 --- a/include/linux/i2c.h +++ b/include/linux/i2c.h @@ -53,6 +53,7 @@ struct i2c_board_info; * on a bus (or read from them). Apart from two basic transfer functions to * transmit one message at a time, a more complex version can be used to * transmit an arbitrary number of messages without interruption. + * Parameter count should be less than 64K since msg.len is __u16 */ extern int i2c_master_send(struct i2c_client *client, const char *buf, int count); -- 1.6.0.4 -- 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 6/6] i2c: davinci: bus recovery procedure to clear the bus
Hello Sekhar,
My apologies for the late mail. Had trouble with our mail server and I
seem to have lost mails. Pulling this thread from the list. Comments
inline...
On Mon, Feb 1, 2010 at 11:27 AM, Nori, Sekhar nsek...@ti.com wrote:
Hi Philby,
On Wed, Jan 27, 2010 at 05:11:33, Kevin Hilman wrote:
From: Philby John pj...@in.mvista.com
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 pj...@in.mvista.com
Signed-off-by: Srinivasan, Nageswari nagesw...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/i2c/busses/i2c-davinci.c | 57
+++--
1 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index 35f9daa..5459065 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -36,6 +36,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/cpufreq.h
+#include linux/gpio.h
#include mach/hardware.h
#include mach/i2c.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 | \
@@ -130,6 +132,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);
+ }
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.
Don't seem to remember having the code in the old versions at least
not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
enable_i2c_pins() were discarded as the i2c protocol spec. did not
specify the need. Moreover bus recovered without it. (Tested on DM355
and Dm6446).
Couple of good to haves:
It will be good to do a gpio_request() before using the pins
as GPIO - though I can see it may have been deemed unnecessary
- the pins are owned by I2C already - even so it may help catch
system configuration errors in later platforms.
Yes, I could use gpio_request() in generic_i2c_clock_pulse().
The I2C peripheral on da8xx itself contains a mode where its
pins could be used as GPIO - so no need for SoC level muxing
and need for the platform data. This seems to be missing from
DM355 though. Thankfully there is a revision id within the I2C
memory map which will help you differentiate the two cases
(revision 0x5 vs 0x6)
I did not entirely follow your above statement. Will usage of
gpio_request() solve the problem for da8xx and DM355 or does it
require a if else condition? A reminder that the present code will
only work for DM6446 and DM355. I do not have a DA8xx to test specific
functionality if it were to be added.
Regards,
Philby
--
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 v3 1/2] i2c: Add SDA and SCL pin numbers to i2c platform data
Hello Sekhar,
On Mon, Feb 1, 2010 at 11:35 AM, Nori, Sekhar nsek...@ti.com wrote:
Hi Philby,
On Tue, Jan 12, 2010 at 16:47:11, Philby John wrote:
From cb3347e45449ff16a332aa164eae24ef6a2432e6 Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Mon, 11 Jan 2010 15:53:31 +0530
Subject: [PATCH 1/2] Add SDA and SCL pin numbers to i2c platform data
Patch adds SDA and SCL pin numbers to the i2c platform data
structure for Davinci DM355 and DM6446. This at present is
used for i2c bus recovery.
TODO: Add SDA and SCL pin number information to include all
Davinci platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
Signed-off-by: Philby John pj...@in.mvista.com
---
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 ++
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 077ecf4..aa48e3f 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 e9612cf..976e11b 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -629,6 +629,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..39fdcea 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 */
It doesn't look like you need the SDA pin to be
a GPIO in patch 2/2 - can you drop it from platform
data in that case?
Yes, SDA pin can be dropped. I merely added it for the sake of completeness.
Regards,
Philby
--
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
[GIT PULL] i2c fix for 2.6.33
Hi Linus, Please pull one i2c subsystem fix for Linux 2.6.33 from: git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.git i2c-for-linus drivers/i2c/busses/i2c-tiny-usb.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) --- Jean Delvare (1): i2c-tiny-usb: Fix on big-endian systems Thanks, -- Jean Delvare -- 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] i2c-tiny-usb: Fix a comment on bus frequency
The description of the delay parameter is incomplete, it suggests that there is a direct relation between the delay value and the bus frequency. In fact, due to additional delays in the i2c bitbanging code, the i2c clock is always much slower. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Till Harbaum t...@harbaum.org --- drivers/i2c/busses/i2c-tiny-usb.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) --- linux-2.6.33-rc6.orig/drivers/i2c/busses/i2c-tiny-usb.c 2010-02-05 18:34:53.0 +0100 +++ linux-2.6.33-rc6/drivers/i2c/busses/i2c-tiny-usb.c 2010-02-05 18:39:59.0 +0100 @@ -31,11 +31,13 @@ #define CMD_I2C_IO_BEGIN (10) #define CMD_I2C_IO_END (11) -/* i2c bit delay, default is 10us - 100kHz */ +/* i2c bit delay, default is 10us - 100kHz max + (in practice, due to additional delays in the i2c bitbanging + code this results in a i2c clock of about 50kHz) */ static unsigned short delay = 10; module_param(delay, ushort, 0); -MODULE_PARM_DESC(delay, bit delay in microseconds, -e.g. 10 for 100kHz (default is 100kHz)); +MODULE_PARM_DESC(delay, bit delay in microseconds +(default is 10us for 100kHz max)); static int usb_read(struct i2c_adapter *adapter, int cmd, int value, int index, void *data, int len); -- Jean Delvare -- 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: [linux-pm] [PATCH] i2c: Hook up runtime PM support
On Friday 05 February 2010, you wrote: On Thu, Feb 04, 2010 at 10:57:27PM +0100, Rafael J. Wysocki wrote: On Wednesday 03 February 2010, Mark Brown wrote: Allow I2C drivers to make use of the runtime PM framework by adding bus implementations of the runtime PM operations. These simply immediately suspend when the device is idle. Perhaps it would be a good idea to give the driver a chance to veto the suspend by calling its _idle callback? We do that for PCI and turns out to be quite useful. Hrm, I guess. It seems an odd thing to want to use - for a bus like I2C there's nothing other than the driver involved so the request that is being vetoed will have been initiated by the driver which seems wrong. Not really. _idle is also called automatically by the runtime PM core after _resume in case the device may be suspended again. Your _idle has to handle this case as well and that's when the driver may want to veto the suspend. Out of interest do you have any pointers to drivers using this (my greps aren't turning anything up in -next)? There aren't any in -next, because I'm waiting for the base PCI runtime PM code to settle down. I have two in my private queue at the moment , for r8169 and e1000e (I posted some older versions of them some time ago, but they wouldn't fit the current framework too well, which is the basic reason I'm sitting on them, so that I don't have to post too many updates :-)). I can send them to you privately, if needed. Rafael -- 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
