Ravikumar Kattekola | 25 May 16:11 2016
Picon

[RFC 0/1] i2c: omap: Add support for switching to slave mode

I2C controller on most of the omap devices has both master and slave
capability but the i2c framework has been missing support for registering
a bus in slave mode for long.
Recently the i2c slave support has been added to i2c framework, the following
patch adds the required support for omap_i2c driver to register a controller
as a slave device and be deriven by an external/internal master.

The slave interface requires us to add following mandatory events

1. I2C_SLAVE_WRITE_REQUESTED
2. I2C_SLAVE_READ_REQUESTED
3. I2C_SLAVE_WRITE_RECEIVED
4. I2C_SLAVE_READ_PROCESSED

and 

5. I2C_SLAVE_STOP

The omap i2c controller (at least on dra7x devices)
doesn't have  start/stop (STT/STP) support for slave mode
so event  #5 is not implemented in the driver.

Refer to Documentation/i2c/slave-interface for more info on 
i2c-slave-interface and Documentation/i2c/slave-eeprom-backend for 
sample backend driver.

Tested on:
DRA75x EVM Rev G3 and DRA72x EVM Rev B1 connected over i2c3 using DCAN2 lines [JP3]

Ravikumar Kattekola (1):
(Continue reading)

Jean Delvare | 25 May 09:37 2016
Picon
Gravatar

[PATCH] i2c: i801: Drop needless bit-wise OR

The interrupt handling code makes it look like several status values
may be merged together before being processed, while this will never
happen. Change from bit-wise OR to simple assignment to make it more
obvious and avoid misunderstanding.

Signed-off-by: Jean Delvare <jdelvare <at> suse.de>
Cc: Daniel Kurtz <djkurtz <at> chromium.org>
Cc: Jarkko Nikula <jarkko.nikula <at> linux.intel.com>
Cc: Mika Westerberg <mika.westerberg <at> linux.intel.com>
Cc: Wolfram Sang <wsa <at> the-dreams.de>
---
Daniel, was there any reason for this bit-wise OR, which I may be
missing?

 drivers/i2c/busses/i2c-i801.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-4.5.orig/drivers/i2c/busses/i2c-i801.c	2016-05-24 11:04:33.169026906 +0200
+++ linux-4.5/drivers/i2c/busses/i2c-i801.c	2016-05-24 11:05:40.564642488 +0200
 <at>  <at>  -548,7 +548,7  <at>  <at>  static irqreturn_t i801_isr(int irq, voi
 	status &= SMBHSTSTS_INTR | STATUS_ERROR_FLAGS;
 	if (status) {
 		outb_p(status, SMBHSTSTS(priv));
-		priv->status |= status;
+		priv->status = status;
 		wake_up(&priv->waitq);
 	}

--

-- 
Jean Delvare
(Continue reading)

Tanmay Jagdale | 24 May 10:09 2016

i2c: xlp9xx: add ACPI support for Broadcom Vulcan

Added ACPI support for the I2C controller present on Broadcom's
Vulcan ARM64 processor. ACPI ID used by the controller is BRCM9007.

Signed-off-by: Tanmay Jagdale <tanmay.jagdale <at> broadcom.com>
---
 drivers/i2c/busses/i2c-xlp9xx.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/i2c/busses/i2c-xlp9xx.c b/drivers/i2c/busses/i2c-xlp9xx.c
index c941418..62a7cff 100644
--- a/drivers/i2c/busses/i2c-xlp9xx.c
+++ b/drivers/i2c/busses/i2c-xlp9xx.c
 <at>  <at>  -13,6 +13,7  <at>  <at> 
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/acpi.h>
 #include <linux/platform_device.h>

 #define XLP9XX_I2C_DIV			0x0
 <at>  <at>  -429,12 +430,21  <at>  <at>  static const struct of_device_id xlp9xx_i2c_of_match[] = {
 	{ /* sentinel */ },
 };

+#ifdef CONFIG_ACPI
+static const struct acpi_device_id vulcan_i2c_acpi_ids[] = {
+	{"BRCM9007", 0},
+	{}
+};
+MODULE_DEVICE_TABLE(acpi, vulcan_i2c_acpi_ids);
(Continue reading)

Moritz Fischer | 23 May 20:44 2016
Gravatar

[PATCH] misc: at24: Fix typo in at24 header file

This commit fixes a simple typo s/mvmem/nvmem in the
example.

Signed-off-by: Moritz Fischer <moritz.fischer <at> ettus.com>
---
 include/linux/platform_data/at24.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
index dc9a13e..be830b1 100644
--- a/include/linux/platform_data/at24.h
+++ b/include/linux/platform_data/at24.h
 <at>  <at>  -26,7 +26,7  <at>  <at> 
  *
  * An example in pseudo code for a setup() callback:
  *
- * void get_mac_addr(struct mvmem_device *nvmem, void *context)
+ * void get_mac_addr(struct nvmem_device *nvmem, void *context)
  * {
  *	u8 *mac_addr = ethernet_pdata->mac_addr;
  *	off_t offset = context;
--

-- 
2.5.5

Linus Walleij | 23 May 14:59 2016

[PATCH] i2c: nomadik: move runtime suspend of hw to _noirq

The runtime suspend of the hardware (declocking and pin control
resting) needs to happen in the *_noirq callbacks after all
hardware interrupts are disabled and we know there will be no
more I2C traffic in the system.

Cc: Ulf Hansson <ulf.hansson <at> linaro.org>
Signed-off-by: Linus Walleij <linus.walleij <at> linaro.org>
---
 drivers/i2c/busses/i2c-nomadik.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index bcd17e8cbcb4..c96a3e331bed 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
 <at>  <at>  -877,7 +877,7  <at>  <at>  static irqreturn_t i2c_irq_handler(int irq, void *arg)
 }

 #ifdef CONFIG_PM_SLEEP
-static int nmk_i2c_suspend_late(struct device *dev)
+static int nmk_i2c_suspend_noirq(struct device *dev)
 {
 	int ret;

 <at>  <at>  -889,7 +889,7  <at>  <at>  static int nmk_i2c_suspend_late(struct device *dev)
 	return 0;
 }

-static int nmk_i2c_resume_early(struct device *dev)
+static int nmk_i2c_resume_noirq(struct device *dev)
(Continue reading)

Jean Delvare | 23 May 11:47 2016
Picon
Gravatar

[RFC PATCH] i2c: i801: Fix I2C Block Read on 8-Series/C220 and later

Starting with the 8-Series/C220 PCH (Lynx Point), the SMBus
controller includes a SPD EEPROM protection mechanism. Once the SPD
Write Disable bit is set, only reads are allowed to slave addresses
0x50-0x57.

However the legacy implementation of I2C Block Read since the ICH5
looks like a write, and is therefore blocked by the SPD protection
mechanism. This causes the eeprom and at24 drivers to fail.

So assume that I2C Block Read is implemented as an actual read on
these chipsets. I tested it on my Q87 chipset and it seems to work
just fine.

Signed-off-by: Jean Delvare <jdelvare <at> suse.de>
Cc: Jarkko Nikula <jarkko.nikula <at> linux.intel.com>
Cc: Mika Westerberg <mika.westerberg <at> linux.intel.com>
Cc: Wolfram Sang <wsa <at> the-dreams.de>
---
Jarkko, Mika, that's what I'm using on my machine now. It works, but
obviously I'd prefer to have confirmation from Intel hardware people
that this is the right thing to do before it goes upstream.

 drivers/i2c/busses/i2c-i801.c |   22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

--- linux-4.5.orig/drivers/i2c/busses/i2c-i801.c	2016-05-23 10:39:56.423505663 +0200
+++ linux-4.5/drivers/i2c/busses/i2c-i801.c	2016-05-23 11:25:09.862853791 +0200
 <at>  <at>  -137,9 +137,10  <at>  <at> 
 #define SMBPCICTL_INTDIS	0x0400

(Continue reading)

Mika Westerberg | 23 May 10:04 2016
Picon

[PATCH v5] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR

Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:

  Device (SBUS)
  {
      OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
      Field (SMBI, ByteAcc, NoLock, Preserve)
      {
          HSTS,   8,
          Offset (0x02),
          HCON,   8,
          HCOM,   8,
          TXSA,   8,
          DAT0,   8,
          DAT1,   8,
          HBDR,   8,
          PECR,   8,
          RXSA,   8,
          SDAT,   16
      }

There are also bunch of AML methods that that the BIOS can use to access
these fields. Most of the systems in question AML methods accessing the
SMBI OpRegion are never used.

Now, because of this SMBI OpRegion many systems fail to load the SMBus
driver with an error looking like one below:

  ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F
       conflicts with OpRegion 0x0000000000003040-0x000000000000304F
(Continue reading)

MRS. LIRA MANDOZA | 22 May 21:11 2016

THIS IS FROM MRS. LIRA MANDOZA


PLEASE KINDLY READ MY EMAIL ATTACHMENT AND GET BACK TO ME. I NEED YOUR ASSISTANCE.
Attachment (Mrs Lira Mandoza.pdf): application/pdf, 197 KiB
Andrea Gelmini | 21 May 13:37 2016
Picon
Gravatar

[PATCH 0018/1529] Fix typo

Signed-off-by: Andrea Gelmini <andrea.gelmini <at> gelma.net>
---
 Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
index 89b3250..75dd5c2 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
 <at>  <at>  -22,7 +22,7  <at>  <at>  Required for all cases except "samsung,s3c2440-hdmiphy-i2c":
     - gpios: The order of the gpios should be the following: <SDA, SCL>.
       The gpio specifier depends on the gpio controller. Required in all
       cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output
-      lines are permanently wired to the respective clienta
+      lines are permanently wired to the respective client
   - Pinctrl variant (preferred, if available):
     - pinctrl-0: Pin control group to be used for this controller.
     - pinctrl-names: Should contain only one value - "default".
--

-- 
2.8.2.534.g1f66975

Ludovic Desroches | 20 May 14:06 2016

[PATCH v3] i2c: at91: change log when dma configuration fails

When the DMA configuration fails, there is a log reporting that we can't
use DMA and indicating the error number. When booting the kernel, it is
annoying to see this error number. Moreover, people can think something
is going wrong. It is not the case, it means that DMA can't be used but
it doesn't prevent to use i2c.

Signed-off-by: Ludovic Desroches <ludovic.desroches <at> atmel.com>
---
 drivers/i2c/busses/i2c-at91.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Douglas, sorry but I can't answer you directly, your email address is
blacklisted on our server.

Changes:
- v3:
  - s/request/get (comment done in private)
- v2:
  - remove ret parameter

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 921d32b..f233726 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
 <at>  <at>  -1013,7 +1013,7  <at>  <at>  static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)

 error:
 	if (ret != -EPROBE_DEFER)
-		dev_info(dev->dev, "can't use DMA, error %d\n", ret);
+		dev_info(dev->dev, "can't get DMA channel, continue without DMA support\n");
(Continue reading)

Niklas Söderlund | 19 May 10:29 2016
Picon

[PATCH] i2c: rcar: use dma_request_chan()

New drivers should not use dma_request_slave_channel_reason() but
dma_request_chan(). The former is a macro to the later so this change do
not effect the driver in any way.

Suggested-by: Arnd Bergmann <arnd <at> arndb.de>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas <at> ragnatech.se>
---
 drivers/i2c/busses/i2c-rcar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index c42d52a..cf82438 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
 <at>  <at>  -626,7 +626,7  <at>  <at>  static struct dma_chan *rcar_i2c_request_dma_chan(struct device *dev,
 	char *chan_name = dir == DMA_MEM_TO_DEV ? "tx" : "rx";
 	int ret;

-	chan = dma_request_slave_channel_reason(dev, chan_name);
+	chan = dma_request_chan(dev, chan_name);
 	if (IS_ERR(chan)) {
 		ret = PTR_ERR(chan);
 		dev_dbg(dev, "request_channel failed for %s (%d)\n",
--

-- 
2.8.2


Gmane