Jean-Michel Hautbois | 29 Aug 17:15 2014

[PATCH v2 1/2] Allow DT parsing of secondary devices

This is based on reg and reg-names in DT.
Example:

reg = <0x10 0x20 0x30>;
reg-names = "main", "io", "test";

This function will create dummy devices io and test
with addresses 0x20 and 0x30 respectively.

Signed-off-by: Jean-Michel Hautbois <jean-michel.hautbois@...>
---
 drivers/i2c/i2c-core.c | 20 ++++++++++++++++++++
 include/linux/i2c.h    |  6 ++++++
 2 files changed, 26 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 632057a..5eb414d 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
 <at>  <at>  -798,6 +798,26  <at>  <at>  struct i2c_client *i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
 }
 EXPORT_SYMBOL_GPL(i2c_new_dummy);

+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+						const char *name,
+						u32 default_addr)
+{
+	int i, addr;
+	struct device_node *np;
+
(Continue reading)

Jean-Michel Hautbois | 29 Aug 15:28 2014

[PATCH 1/2] Allow DT parsing of secondary devices

This is based on reg and reg-names in DT.
Example:

reg = <0x10 0x20 0x30>;
reg-names = "main", "io", "test";

This function will create dummy devices io and test
with addresses 0x20 and 0x30 respectively.

Signed-off-by: Jean-Michel Hautbois <jean-michel.hautbois@...>
---
 drivers/i2c/i2c-core.c | 20 ++++++++++++++++++++
 include/linux/i2c.h    |  6 ++++++
 2 files changed, 26 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 632057a..5eb414d 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
 <at>  <at>  -798,6 +798,26  <at>  <at>  struct i2c_client *i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
 }
 EXPORT_SYMBOL_GPL(i2c_new_dummy);

+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+						const char *name,
+						u32 default_addr)
+{
+	int i, addr;
+	struct device_node *np;
+
(Continue reading)

umar akmel | 29 Aug 06:38 2014
Picon

VERY URGENT.

My Dear Good Friend.

Compliment of the season, how are you and your family? Hope All is
well. I am Mr Umar Akmel, the accountant general in the accounts unit
Bank of Africa (BOA-BF) Ouagadougou Burkina Faso. I got your contact
from the Burkina Faso chambers of commerce have some fund to claim in
my bank Which will be of benefit to both of us.

I want you to be an inheritor of the fund, the fund is in a Doormat
account and with your bank information and my Documentation certifies
you as the inheritor/beneficiary Since I am an insider and working in
the same bank, the Transfer will be processed legally and successfully
and I will Be coming down to your country for disbursement.

The amount of money involved is ($5.6m) which I want you to Claim for
further transfer out of the country to your bank Account, all to our
financial benefit. This is very great opportunity as it will take a
maximum of 7 banking Working days to be concluded.

I as an insider will do my duties perfectly well concerning this
transaction for security reasons. This is confidential for successful
conclusion and hitch-free transaction. Contact me immediately for
further details and mutual Relationship and we will decide together on
how to disburse The funds and percentage as well, my private email
Address: (umarakmal1960@...)

I will be waiting to hear from you.

Yours truly.
Mr Umar Akmel.
(Continue reading)

Carl Peng | 29 Aug 05:01 2014
Picon

[PATCH] i2c-designware: Add support for ACPI i2c device

AMD platform i2c bus controllers are ACPI devices,
this patch is to add a ACPI glue for Designware
core, make it support i2c bus controller with
ACPI interface.

Signed-off-by: Carl Peng <carlpeng008@...>
---
 drivers/i2c/busses/Kconfig                  |  12 +
 drivers/i2c/busses/Makefile                 |   1 +
 drivers/i2c/busses/i2c-designware-acpidrv.c | 355 ++++++++++++++++++++++++++++
 drivers/i2c/busses/i2c-designware-core.h    |   4 +
 4 files changed, 372 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-designware-acpidrv.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..974700c 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
 <at>  <at>  -441,6 +441,18  <at>  <at>  config I2C_DESIGNWARE_PCI
 	  This driver can also be built as a module.  If so, the module
 	  will be called i2c-designware-pci.

+config I2C_DESIGNWARE_ACPI
+	tristate "Synopsys DesignWare ACPI"
+	depends on ACPI
+	select I2C_DESIGNWARE_CORE
+	help
+	  AMD platform i2c bus controller is ACPI device, this driver is
+	  to add ACPI glue for designware core, make it support ACPI
+	  interface.
(Continue reading)

Carl Peng | 29 Aug 05:09 2014
Picon

[PATCH] i2c-designware: Add support for ACPI i2c device

AMD platform i2c bus controllers are ACPI devices,
this patch is to add a ACPI glue for Designware
core, make it support i2c bus controller with
ACPI interface.

Signed-off-by: Carl Peng <carlpeng008@...>
---
 drivers/i2c/busses/Kconfig                  |  12 +
 drivers/i2c/busses/Makefile                 |   1 +
 drivers/i2c/busses/i2c-designware-acpidrv.c | 355 ++++++++++++++++++++++++++++
 drivers/i2c/busses/i2c-designware-core.h    |   4 +
 4 files changed, 372 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-designware-acpidrv.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..974700c 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
 <at>  <at>  -441,6 +441,18  <at>  <at>  config I2C_DESIGNWARE_PCI
 	  This driver can also be built as a module.  If so, the module
 	  will be called i2c-designware-pci.

+config I2C_DESIGNWARE_ACPI
+	tristate "Synopsys DesignWare ACPI"
+	depends on ACPI
+	select I2C_DESIGNWARE_CORE
+	help
+	  AMD platform i2c bus controller is ACPI device, this driver is
+	  to add ACPI glue for designware core, make it support ACPI
+	  interface.
(Continue reading)

Alan | 27 Aug 17:33 2014
Picon

[RFC, RESEND] i2c-smbus: smbus alert revisited

This follows on from the discussion in late March before Srinivas got
busy on other things.

This is just an RFC for a next generation set of patches. The idea is as
follows

- If an adapter knows about its ARA and smbus alerts then the adapter
  creates its own interrupt handler as before

- If a client knows it needs smbus alerts it calls
  i2c_require_smbus_alert. This ensures that there is an ARA handler
  registered and tells the client whether the adapter is handling it
  anyway or not.

- When the client learns that an ARA event has occurred it calls
  i2c_smbus_alert_event which uses the existing ARA mechanism to kick
  things off.

Leaving it to the client and introducing that little bit of asymmetry
means

- we don't have to do expensive polling

- we cope with the case where there isn't a single smbalert line instead
  each device has a GPIO

- we cope with the case of devices that need to trigger an ARA in other
  ways (eg with no IRQ or GPIO but discovering a particular bit is set
  and needing an ARA to unwedge it)

(Continue reading)

Simon Lindgren | 26 Aug 21:13 2014

[PATCH] i2c:at91: Fix a race condition during signal handling in at91_do_twi_xfer.

There is a race condition in at91_do_twi_xfer when signals arrive.
If a signal is recieved while waiting for a transfer to complete
wait_for_completion_interruptible_timeout() will return -ERESTARTSYS.
This is not handled correctly resulting in interrupts still being
enabled and a transfer being in flight when we return.

Symptoms include a range of oopses and bus lockups. Oopses can happen
when the transfer completes because the interrupt handler will corrupt
the stack. If a new transfer is started before the interrupt fires
the controller will start a new transfer in the middle of the old one,
resulting in confused slaves and a locked bus.

To avoid this, use wait_for_completion_io_timeout instead so that we
don't have to deal with gracefully shutting down the transfer and
disabling the interrupts.

Signed-off-by: Simon Lindgren <simon@...>
---
 drivers/i2c/busses/i2c-at91.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 79a6899..ec299ae 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
 <at>  <at>  -421,8 +421,8  <at>  <at>  static int at91_do_twi_transfer(struct at91_twi_dev *dev)
 		}
 	}

-	ret = wait_for_completion_interruptible_timeout(&dev->cmd_complete,
(Continue reading)

Zhangfei Gao | 26 Aug 07:25 2014

[PATCH resend 0/2] i2c: hix5hd2: add i2c controller driver

Resend: verified on 3.17-rc1

Wei Yan (2):
  i2c: hix5hd2: add devicetree documentation
  i2c: hix5hd2: add i2c controller driver

 .../devicetree/bindings/i2c/i2c-hix5hd2.txt        |   31 ++
 drivers/i2c/busses/Kconfig                         |   16 +
 drivers/i2c/busses/Makefile                        |    1 +
 drivers/i2c/busses/i2c-hix5hd2.c                   |  576 ++++++++++++++++++++
 4 files changed, 624 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-hix5hd2.txt
 create mode 100644 drivers/i2c/busses/i2c-hix5hd2.c

--

-- 
1.7.9.5

Simon Lindgren | 22 Aug 21:14 2014

Implementing bus recovery

I would like to implement bus recovery support for the at91 driver, but 
there it is not clear how the core support is supposed to be used, and I 
could not find an existing adapter implementation using it.

First off, reading the old mailing list discussion here:
http://thread.gmane.org/gmane.linux.drivers.i2c/10225

It seems a pinctrl state should be used to switch the pins over to gpio 
mode. Now, I need a place to put this state switching. The 
i2c_bus_recovery_info struct looks like this:

struct i2c_bus_recovery_info {
	int (*recover_bus)(struct i2c_adapter *);

	int (*get_scl)(struct i2c_adapter *);
	void (*set_scl)(struct i2c_adapter *, int val);
	int (*get_sda)(struct i2c_adapter *);

	void (*prepare_recovery)(struct i2c_bus_recovery_info *bri);
	void (*unprepare_recovery)(struct i2c_bus_recovery_info *bri);

	/* gpio recovery */
	int scl_gpio;
	int sda_gpio;
};

There is no usable callback to do this, because {un,}prepare_recovery is 
only passed the bus recovery info and no driver data is reachable from that.

So next up, I thought I'd wrap i2c_generic_gpio_recovery and do the 
(Continue reading)

Doug Anderson | 22 Aug 19:43 2014

[PATCH] i2c: rk3x: Remove unlikely() annotations

Having a transfer more than 32 bits is not all that unlikely.  Remove
the annotation.

The unlikely in the IRQ handler can't gain us much.  It's not in a
loop, so at most it would save 1 instruction per IRQ, which isn't
much.  In fact on the compiler I tested it produced the exact same
code.  Remove it too.

Suggested-by: Dmitry Torokhov <dmitry.torokhov@...>
Signed-off-by: Doug Anderson <dianders@...>
---
 drivers/i2c/busses/i2c-rk3x.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 69e1185..b8b2b89 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
 <at>  <at>  -208,7 +208,7  <at>  <at>  static void rk3x_i2c_prepare_read(struct rk3x_i2c *i2c)
 	 * The hw can read up to 32 bytes at a time. If we need more than one
 	 * chunk, send an ACK after the last byte of the current chunk.
 	 */
-	if (unlikely(len > 32)) {
+	if (len > 32) {
 		len = 32;
 		con &= ~REG_CON_LASTACK;
 	} else {
 <at>  <at>  -399,7 +399,7  <at>  <at>  static irqreturn_t rk3x_i2c_irq(int irqno, void *dev_id)
 	}

(Continue reading)

Pavel Machek | 22 Aug 15:11 2014
Picon

Trickle charging for rtc-bq32k

Hi!

Here's a patch to enable trickle charging; without it the clock stops
when power is removed -> not very useful.

_But_ this should probably be enabled using device tree entry, right?
Unfortunately, the driver is i2c driver, not platform one, so I don't
see how to do that easily...

Or would module parameter be acceptable?

Thanks,
								Pavel

commit 00abeaa1197a5ad6400497558891793b6cd880d5
Author: Pavel <pavel@...>
Date:   Fri Aug 22 14:58:00 2014 +0200

Enable trickle charging for bq32k.

diff --git a/drivers/rtc/rtc-bq32k.c b/drivers/rtc/rtc-bq32k.c
index c74bf0d..b6a4dd0 100644
--- a/drivers/rtc/rtc-bq32k.c
+++ b/drivers/rtc/rtc-bq32k.c
 <at>  <at>  -2,10 +2,14  <at>  <at> 
  * Driver for TI BQ32000 RTC.
  *
  * Copyright (C) 2009 Semihalf.
+ * Copyright (C) 2014 Pavel Machek <pavel@...>
  *
(Continue reading)


Gmane