Hi Jean,
After a long discussion with other engineers, we finally got parsing I2C device
info table code out of the I2C controller driver. Here is a description for the
patch:
1. Patch for I2C controller driver for Intel low power platform Moorestown.
2. The driver depends on a GPIO driver for
From f5ace22d5aec5e62b6110e3a61f03ca04eaffafb Mon Sep 17 00:00:00 2001
From: Wen Wang wen.w.w...@intel.com
Date: Thu, 14 May 2009 14:56:44 +0800
Subject: [PATCH] Patch for Moorestown I2C controller driver
Signed-off-by: Wen Wang wen.w.w...@intel.com
---
drivers/i2c/busses/Kconfig |
Hi Wen,
On Thu, 14 May 2009 15:35:37 +0800, Wang, Wen W wrote:
Hi Jean,
After a long discussion with other engineers, we finally got parsing I2C
device info table code out of the I2C controller driver. Here is a
description for the patch:
1. Patch for I2C controller driver for Intel
This fixes MAL (arbitration lost) bug caused by illegal use of
RSTA (repeated START) after STOP condition generated after last byte
of reads.
Signed-off-by: Esben Haabendal e...@doredevelopment.dk
---
drivers/i2c/busses/i2c-mpc.c |9 +++--
1 files changed, 7 insertions(+), 2
On Thu, May 14, 2009 at 10:10:03AM +0200, Esben Haabendal wrote:
This fixes MAL (arbitration lost) bug caused by illegal use of
RSTA (repeated START) after STOP condition generated after last byte
of reads.
Could you elaborate a bit, please? Like an example when the original bug
occured (so I
Wolfram Sang wrote:
On Thu, May 14, 2009 at 10:10:03AM +0200, Esben Haabendal wrote:
This fixes MAL (arbitration lost) bug caused by illegal use of
RSTA (repeated START) after STOP condition generated after last byte
of reads.
Could you elaborate a bit, please? Like an example when
IMO, The regs do not need to move to a separate header unless they will
be used outside of i2c-omap.c.
Would it not be cleaner to move them to a separate header file,
especially considering the fact that we have some 19 registers for
OMAP3 I2C and when we redefine them for OMAP4, there would be
Hi Linus,
A few comments.
Linus Walleij wrote:
This adds a core driver for the AB3100 mixed-signal circuit
found in the ST-Ericsson U300 series platforms. This driver
is a singleton proxy for all accesses to the AB3100
sub-drivers which will be merged on top of this one, RTC,
regulators,
Hi Jean
-Original Message-
From: Jean Delvare [mailto:kh...@linux-fr.org]
Sent: 2009年5月14日 15:52
To: Wang, Wen W
Cc: linux-i2c@vger.kernel.org
Subject: Re: [PATCH 0/1] I2C: I2C controller driver for Intel Moorestown
platform
Hi Wen,
On Thu, 14 May 2009 15:35:37 +0800, Wang, Wen W
Hi Linus,
Some code comments here:
On Thu, May 14, 2009 at 10:29:02AM +0200, Linus Walleij wrote:
+/*
+ * I2C communication
+ *
+ * The AB3100 is assigned address 0x48 (7-bit)
+ * Since the driver does not require SMBus support, we
+ * cannot be sure to probe for the device address here,
The i2c-core code tends to hold the core lock for longer than it
should. Limit locking to the necessary sections for both performance
and clarity. This is also a requirement to support I2C multiplexers in
the future.
Testing was successful on my system but I would love to hear from other
testers.
* Jagadeesh Bhaskar Pakaravoor jagadees...@gmail.com [090514 03:34]:
IMO, The regs do not need to move to a separate header unless they will
be used outside of i2c-omap.c.
Would it not be cleaner to move them to a separate header file,
especially considering the fact that we have some 19
12 matches
Mail list logo
