On Tue, Aug 20, 2013 at 04:30:43PM +0200, Wolfram Sang wrote:
On Tue, Aug 20, 2013 at 12:28:13PM +0300, Mika Westerberg wrote:
[Added Jerry as he found out a problem when acpi_i2c is being build as a
module, this should solve it as well.]
On Tue, Aug 20, 2013 at 01:25:27AM +0200, Rafael
Adds support for High Speed I2C driver found in Exynos5 and
later SoCs from Samsung.
Highspeed mode is a minor change in the i2c protocol.
Starts with
1. start condition,
2. 8-bit master ID code (1xxx)
3. followed by a NACK bit
Once the above conditions are met, the bus is now operates in
Hi Wolfram
CC Morimoto
Please consider the following patch for the r8a7790 Soc.
This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.
It was developed base on the renesas-devel-20130722 branch and
have tested on the Lager board.
V3: Using the ID tables to resolve the
This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.
Signed-off-by: Nguyen Viet Dung nv-d...@jinso.co.jp
---
drivers/i2c/busses/i2c-rcar.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git
On 20/08/2013 21:07, Wolfram Sang wrote:
Jason Cooper drooped the third patch as it conflicted with a patch from
Maxime Ripard which adds the AllWinner support. Olof also asked a formal
acked-by from a device tree maintainer
even if we already answer to Mark Rutland request.
Olof also
[resending, this time really copying Wolfram and linux-i2c...]
On Wed, 2013-08-21 at 12:53 +0100, Jacek Anaszewski wrote:
From what I've figured out in order to obtain the interrupt id
by name the function
platform_get_irq_by_name(struct platform_device *dev, const char *name)
has to be
compatible, do you want that I rebase my patch set on your
i2c/for-current branch, or do you prefer to take care of the merge
conflict yourself?
My for-next would be preferred.
signature.asc
Description: Digital signature
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child nodes in the core instead of doing this manually
in each driver.
This follows what has already been done for the DeviceTree helpers. Move
the ACPI helpers from drivers/acpi/acpi_i2c.c to the I2C core and update
documentation accordingly.
This also solves a problem reported by Jerry Snitselaar that we can't build
the ACPI I2C helpers as a module.
On 08/21/2013 03:47 PM, Wolfram Sang wrote:
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child nodes in the core
On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote:
Hi,
On 8/5/13 6:31 PM, Christian Ruppert wrote: On Wed, Jul 24, 2013 at
11:31:44PM +0900, Shinya Kuribayashi wrote:
As said before, all t_SCL things should go away. Please forget
about 100kbps, 400kbps, and so on.
On Wed, Aug 21, 2013 at 01:37:04PM +0100, Pawel Moll wrote:
So let me ask such question... If Device Tree didn't exist, how would
you make drive such device? I guess it would require some custom code,
It's always done using platform data, same for SPI - if we update one we
should probably
Hi,
here is the review. BTW have you tested with and without the offload
engine?
+static int mv64xxx_i2c_offload_msg(struct mv64xxx_i2c_data *drv_data)
+{
+ unsigned long data_reg_hi = 0;
+ unsigned long data_reg_lo = 0;
+ unsigned long ctrl_reg;
+ unsigned int i;
+
Hi Wolfram,
Did I misunderstand something?
Best regards,
Leilei
2013/8/16 James Lebron leileishangch...@gmail.com:
Hi Wolfram,
Thanks for your quick response!
Do you mean my initial patch has already been accept and I don't need
to push patch v2?
If yes, do I need to rebase the patch?
Did I misunderstand something?
No, you didn't. As I said the patch is already in my tree and
linux-next. Please read Documentation/development-process/* in case you
don't know about linux-next yet.
Regards,
Wolfram
signature.asc
Description: Digital signature
15 matches
Mail list logo
