* [PATCH v3 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-26 13:00 UTC (permalink / raw)
To: andy.shevchenko, jun.nie, wsa, robh+dt, mark.rutland
Cc: linux-arm-kernel, linux-i2c, devicetree, linux-kernel, shawnguo,
baoyou.xie, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <1485435631-32642-1-git-send-email-baoyou.xie@linaro.org>
This patch adds i2c controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-zx2967.c | 699 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 709 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-zx2967.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e4a603e..d983e36 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1246,4 +1246,13 @@ config I2C_OPAL
This driver can also be built as a module. If so, the module will be
called as i2c-opal.
+config I2C_ZX2967
+ tristate "ZTE zx2967 I2C support"
+ depends on ARCH_ZX
+ default y
+ help
+ Selecting this option will add ZX2967 I2C driver.
+ This driver can also be built as a module. If so, the module will be
+ called i2c-zx2967.
+
endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index beb4809..16b2901 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_I2C_XILINX) += i2c-xiic.o
obj-$(CONFIG_I2C_XLR) += i2c-xlr.o
obj-$(CONFIG_I2C_XLP9XX) += i2c-xlp9xx.o
obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
+obj-$(CONFIG_I2C_ZX2967) += i2c-zx2967.o
# External I2C/SMBus adapter drivers
obj-$(CONFIG_I2C_DIOLAN_U2C) += i2c-diolan-u2c.o
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
new file mode 100644
index 0000000..81e99d3
--- /dev/null
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -0,0 +1,699 @@
+/*
+ * ZTE's zx2967 family i2c bus controller driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
+
+#define REG_CMD 0x04
+#define REG_DEVADDR_H 0x0C
+#define REG_DEVADDR_L 0x10
+#define REG_CLK_DIV_FS 0x14
+#define REG_CLK_DIV_HS 0x18
+#define REG_WRCONF 0x1C
+#define REG_RDCONF 0x20
+#define REG_DATA 0x24
+#define REG_STAT 0x28
+
+#define I2C_STOP 0
+#define I2C_MASTER BIT(0)
+#define I2C_ADDR_MODE_TEN BIT(1)
+#define I2C_IRQ_MSK_ENABLE BIT(3)
+#define I2C_RW_READ BIT(4)
+#define I2C_CMB_RW_EN BIT(5)
+#define I2C_START BIT(6)
+#define I2C_ADDR_MODE_TEN BIT(1)
+
+#define I2C_WFIFO_RESET BIT(7)
+#define I2C_RFIFO_RESET BIT(7)
+
+#define I2C_IRQ_ACK_CLEAR BIT(7)
+#define I2C_INT_MASK GENMASK(6, 0)
+
+#define I2C_TRANS_DONE BIT(0)
+#define I2C_ERROR_DEVICE BIT(1)
+#define I2C_ERROR_DATA BIT(2)
+#define I2C_ERROR_MASK GENMASK(2, 1)
+
+#define I2C_SR_BUSY BIT(6)
+
+#define I2C_SR_EDEVICE BIT(1)
+#define I2C_SR_EDATA BIT(2)
+
+#define I2C_FIFO_MAX 16
+
+#define I2C_TIMEOUT msecs_to_jiffies(1000)
+
+struct zx2967_i2c_info {
+ spinlock_t lock;
+ struct device *dev;
+ struct i2c_adapter adap;
+ struct clk *clk;
+ struct completion complete;
+ u32 clk_freq;
+ struct pinctrl *pin_ctrl;
+ void __iomem *reg_base;
+ size_t residue;
+ int irq;
+ int msg_rd;
+ u8 *buf;
+ u8 access_cnt;
+ bool is_suspended;
+};
+
+static void zx2967_i2c_writel(struct zx2967_i2c_info *zx_i2c,
+ u32 val, unsigned long reg)
+{
+ writel_relaxed(val, zx_i2c->reg_base + reg);
+}
+
+static u32 zx2967_i2c_readl(struct zx2967_i2c_info *zx_i2c, unsigned long reg)
+{
+ return readl_relaxed(zx_i2c->reg_base + reg);
+}
+
+static void zx2967_i2c_writesb(struct zx2967_i2c_info *zx_i2c,
+ void *data, unsigned long reg, int len)
+{
+ writesb(zx_i2c->reg_base + reg, data, len);
+}
+
+static void zx2967_i2c_readsb(struct zx2967_i2c_info *zx_i2c,
+ void *data, unsigned long reg, int len)
+{
+ readsb(zx_i2c->reg_base + reg, data, len);
+}
+
+static void zx2967_i2c_start_ctrl(struct zx2967_i2c_info *zx_i2c)
+{
+ u32 status;
+ u32 ctl;
+
+ status = zx2967_i2c_readl(zx_i2c, REG_STAT);
+ status |= I2C_IRQ_ACK_CLEAR;
+ zx2967_i2c_writel(zx_i2c, status, REG_STAT);
+
+ ctl = zx2967_i2c_readl(zx_i2c, REG_CMD);
+ if (zx_i2c->msg_rd)
+ ctl |= I2C_RW_READ;
+ else
+ ctl &= ~I2C_RW_READ;
+ ctl &= ~I2C_CMB_RW_EN;
+ ctl |= I2C_START;
+ zx2967_i2c_writel(zx_i2c, ctl, REG_CMD);
+}
+
+static int zx2967_i2c_flush_fifos(struct zx2967_i2c_info *zx_i2c)
+{
+ u32 val;
+ u32 offset;
+
+ if (zx_i2c->msg_rd) {
+ offset = REG_RDCONF;
+ val = I2C_RFIFO_RESET;
+ } else {
+ offset = REG_WRCONF;
+ val = I2C_WFIFO_RESET;
+ }
+
+ val |= zx2967_i2c_readl(zx_i2c, offset);
+ zx2967_i2c_writel(zx_i2c, val, offset);
+
+ return 0;
+}
+
+static int zx2967_i2c_empty_rx_fifo(struct zx2967_i2c_info *zx_i2c, u32 size)
+{
+ u8 val[I2C_FIFO_MAX] = {0};
+ int i;
+
+ if (size > I2C_FIFO_MAX) {
+ dev_err(zx_i2c->dev, "fifo size %d over the max value %d\n",
+ size, I2C_FIFO_MAX);
+ return -EINVAL;
+ }
+
+ zx2967_i2c_readsb(zx_i2c, val, REG_DATA, size);
+ for (i = 0; i < size; i++) {
+ *(zx_i2c->buf++) = val[i];
+ zx_i2c->residue--;
+ if (zx_i2c->residue <= 0)
+ break;
+ }
+
+ barrier();
+
+ return 0;
+}
+
+static int zx2967_i2c_fill_tx_fifo(struct zx2967_i2c_info *zx_i2c)
+{
+ u8 *buf = zx_i2c->buf;
+ size_t residue = zx_i2c->residue;
+
+ if (residue == 0) {
+ dev_err(zx_i2c->dev, "residue is %d\n", (int)residue);
+ return -EINVAL;
+ }
+
+ if (residue <= I2C_FIFO_MAX) {
+ zx2967_i2c_writesb(zx_i2c, buf, REG_DATA, residue);
+
+ /* Again update before writing to FIFO to make sure isr sees. */
+ zx_i2c->residue = 0;
+ zx_i2c->buf = NULL;
+ } else {
+ zx2967_i2c_writesb(zx_i2c, buf, REG_DATA, I2C_FIFO_MAX);
+ zx_i2c->residue -= I2C_FIFO_MAX;
+ zx_i2c->buf += I2C_FIFO_MAX;
+ }
+
+ barrier();
+
+ return 0;
+}
+
+static int zx2967_i2c_reset_hardware(struct zx2967_i2c_info *zx_i2c)
+{
+ u32 val;
+ u32 clk_div;
+ u32 status;
+
+ val = I2C_MASTER | I2C_IRQ_MSK_ENABLE;
+ zx2967_i2c_writel(zx_i2c, val, REG_CMD);
+
+ clk_div = clk_get_rate(zx_i2c->clk) / zx_i2c->clk_freq - 1;
+ zx2967_i2c_writel(zx_i2c, clk_div, REG_CLK_DIV_FS);
+ zx2967_i2c_writel(zx_i2c, clk_div, REG_CLK_DIV_HS);
+
+ zx2967_i2c_writel(zx_i2c, I2C_FIFO_MAX - 1, REG_WRCONF);
+ zx2967_i2c_writel(zx_i2c, I2C_FIFO_MAX - 1, REG_RDCONF);
+ zx2967_i2c_writel(zx_i2c, 1, REG_RDCONF);
+
+ zx2967_i2c_flush_fifos(zx_i2c);
+
+ status = zx2967_i2c_readl(zx_i2c, REG_STAT);
+ if (status & I2C_SR_BUSY)
+ return -EBUSY;
+ if (status & (I2C_SR_EDEVICE | I2C_SR_EDATA))
+ return -EIO;
+
+ enable_irq(zx_i2c->irq);
+
+ return 0;
+}
+
+static void zx2967_i2c_isr_clr(struct zx2967_i2c_info *zx_i2c)
+{
+ u32 status;
+
+ status = zx2967_i2c_readl(zx_i2c, REG_STAT);
+ status |= I2C_IRQ_ACK_CLEAR;
+ zx2967_i2c_writel(zx_i2c, status, REG_STAT);
+}
+
+static irqreturn_t zx2967_i2c_isr(int irq, void *dev_id)
+{
+ u32 status;
+ struct zx2967_i2c_info *zx_i2c = (struct zx2967_i2c_info *)dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(&zx_i2c->lock, flags);
+
+ status = zx2967_i2c_readl(zx_i2c, REG_STAT) & I2C_INT_MASK;
+ zx2967_i2c_isr_clr(zx_i2c);
+
+ if (status & I2C_ERROR_MASK) {
+ spin_unlock_irqrestore(&zx_i2c->lock, flags);
+ return IRQ_HANDLED;
+ }
+
+ if (status & I2C_TRANS_DONE)
+ complete(&zx_i2c->complete);
+
+ spin_unlock_irqrestore(&zx_i2c->lock, flags);
+
+ return IRQ_HANDLED;
+}
+
+static void zx2967_enable_tenbit(struct zx2967_i2c_info *zx_i2c, __u16 addr)
+{
+ u16 val = (addr >> 7) & 0x7;
+
+ if (val > 0) {
+ zx2967_i2c_writel(zx_i2c, val, REG_DEVADDR_H);
+ val = (zx2967_i2c_readl(zx_i2c, REG_CMD)) | I2C_ADDR_MODE_TEN;
+ zx2967_i2c_writel(zx_i2c, val, REG_CMD);
+ }
+}
+
+static int
+zx2967_i2c_xfer_read_bytes(struct zx2967_i2c_info *zx_i2c, u32 bytes)
+{
+ unsigned long time_left;
+
+ reinit_completion(&zx_i2c->complete);
+ zx2967_i2c_writel(zx_i2c, bytes - 1, REG_RDCONF);
+ zx2967_i2c_start_ctrl(zx_i2c);
+
+ time_left = wait_for_completion_timeout(&zx_i2c->complete,
+ I2C_TIMEOUT);
+ if (time_left == 0) {
+ dev_err(zx_i2c->dev, "read i2c transfer timed out\n");
+ disable_irq(zx_i2c->irq);
+ zx2967_i2c_reset_hardware(zx_i2c);
+ return -EIO;
+ }
+
+ return zx2967_i2c_empty_rx_fifo(zx_i2c, bytes);
+}
+
+static int zx2967_i2c_xfer_read(struct zx2967_i2c_info *zx_i2c)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < zx_i2c->access_cnt; i++) {
+ ret = zx2967_i2c_xfer_read_bytes(zx_i2c, I2C_FIFO_MAX);
+ if (ret)
+ return ret;
+ }
+
+ if (zx_i2c->residue > 0) {
+ ret = zx2967_i2c_xfer_read_bytes(zx_i2c, I2C_FIFO_MAX);
+ if (ret)
+ return ret;
+ }
+
+ zx_i2c->residue = 0;
+ zx_i2c->access_cnt = 0;
+ return 0;
+}
+
+static int
+zx2967_i2c_xfer_write_bytes(struct zx2967_i2c_info *zx_i2c, u32 bytes)
+{
+ unsigned long time_left;
+ int ret;
+
+ reinit_completion(&zx_i2c->complete);
+
+ ret = zx2967_i2c_fill_tx_fifo(zx_i2c);
+ if (ret)
+ return ret;
+
+ zx2967_i2c_start_ctrl(zx_i2c);
+
+ time_left = wait_for_completion_timeout(&zx_i2c->complete,
+ I2C_TIMEOUT);
+ if (time_left == 0) {
+ dev_err(zx_i2c->dev, "write i2c transfer timed out\n");
+ disable_irq(zx_i2c->irq);
+ zx2967_i2c_reset_hardware(zx_i2c);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int zx2967_i2c_xfer_write(struct zx2967_i2c_info *zx_i2c)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < zx_i2c->access_cnt; i++) {
+ ret = zx2967_i2c_xfer_write_bytes(zx_i2c, I2C_FIFO_MAX);
+ if (ret)
+ return ret;
+ }
+
+ if (zx_i2c->residue > 0) {
+ ret = zx2967_i2c_xfer_write_bytes(zx_i2c, I2C_FIFO_MAX);
+ if (ret)
+ return ret;
+ }
+
+ zx_i2c->residue = 0;
+ zx_i2c->access_cnt = 0;
+ return 0;
+}
+
+static int zx2967_i2c_xfer_msg(struct zx2967_i2c_info *zx_i2c,
+ struct i2c_msg *msg)
+{
+ if (msg->len == 0)
+ return -EINVAL;
+
+ zx2967_i2c_flush_fifos(zx_i2c);
+
+ zx_i2c->buf = msg->buf;
+ zx_i2c->residue = msg->len;
+ zx_i2c->access_cnt = msg->len / I2C_FIFO_MAX;
+ zx_i2c->msg_rd = (msg->flags & I2C_M_RD);
+
+ if (zx_i2c->msg_rd)
+ return zx2967_i2c_xfer_read(zx_i2c);
+
+ return zx2967_i2c_xfer_write(zx_i2c);
+}
+
+static int zx2967_i2c_xfer(struct i2c_adapter *adap,
+ struct i2c_msg *msgs, int num)
+{
+ struct zx2967_i2c_info *zx_i2c = i2c_get_adapdata(adap);
+ int ret;
+ int i;
+
+ if (zx_i2c->is_suspended)
+ return -EBUSY;
+
+ zx2967_i2c_writel(zx_i2c, (msgs->addr & 0x7f), REG_DEVADDR_L);
+ zx2967_i2c_writel(zx_i2c, (msgs->addr >> 7) & 0x7, REG_DEVADDR_H);
+ if (zx2967_i2c_readl(zx_i2c, REG_DEVADDR_H) > 0)
+ zx2967_enable_tenbit(zx_i2c, msgs->addr);
+
+ for (i = 0; i < num; i++) {
+ ret = zx2967_i2c_xfer_msg(zx_i2c, &msgs[i]);
+ if (ret)
+ return ret;
+ if (num > 1)
+ usleep_range(1000, 2000);
+ }
+
+ return num;
+}
+
+static void
+zx2967_smbus_xfer_prepare(struct zx2967_i2c_info *zx_i2c, u16 addr,
+ char read_write, u8 command, int size,
+ union i2c_smbus_data *data)
+{
+ u32 val;
+
+ val = zx2967_i2c_readl(zx_i2c, REG_RDCONF);
+ val |= I2C_RFIFO_RESET;
+ zx2967_i2c_writel(zx_i2c, val, REG_RDCONF);
+ zx2967_i2c_writel(zx_i2c, (addr & 0x7f), REG_DEVADDR_L);
+
+ zx2967_enable_tenbit(zx_i2c, addr);
+ val = zx2967_i2c_readl(zx_i2c, REG_CMD);
+ val &= ~I2C_RW_READ;
+ zx2967_i2c_writel(zx_i2c, val, REG_CMD);
+
+ switch (size) {
+ case I2C_SMBUS_BYTE:
+ zx2967_i2c_writel(zx_i2c, command, REG_DATA);
+ break;
+ case I2C_SMBUS_BYTE_DATA:
+ zx2967_i2c_writel(zx_i2c, command, REG_DATA);
+ if (read_write == I2C_SMBUS_WRITE)
+ zx2967_i2c_writel(zx_i2c, data->byte, REG_DATA);
+ break;
+ case I2C_SMBUS_WORD_DATA:
+ zx2967_i2c_writel(zx_i2c, command, REG_DATA);
+ if (read_write == I2C_SMBUS_WRITE) {
+ zx2967_i2c_writel(zx_i2c, (data->word >> 8), REG_DATA);
+ zx2967_i2c_writel(zx_i2c, (data->word & 0xff),
+ REG_DATA);
+ }
+ break;
+ }
+}
+
+static int zx2967_smbus_xfer_read(struct zx2967_i2c_info *zx_i2c, int size,
+ union i2c_smbus_data *data)
+{
+ unsigned long time_left;
+ u8 buf[2];
+ u32 val;
+
+ reinit_completion(&zx_i2c->complete);
+
+ val = zx2967_i2c_readl(zx_i2c, REG_CMD);
+ val |= I2C_CMB_RW_EN;
+ zx2967_i2c_writel(zx_i2c, val, REG_CMD);
+
+ val = zx2967_i2c_readl(zx_i2c, REG_CMD);
+ val |= I2C_START;
+ zx2967_i2c_writel(zx_i2c, val, REG_CMD);
+
+ time_left = wait_for_completion_timeout(&zx_i2c->complete,
+ I2C_TIMEOUT);
+ if (time_left == 0) {
+ dev_err(zx_i2c->dev, "i2c read transfer timed out\n");
+ disable_irq(zx_i2c->irq);
+ zx2967_i2c_reset_hardware(zx_i2c);
+ return -EIO;
+ }
+
+ usleep_range(1000, 2000);
+ switch (size) {
+ case I2C_SMBUS_BYTE:
+ case I2C_SMBUS_BYTE_DATA:
+ val = zx2967_i2c_readl(zx_i2c, REG_DATA);
+ data->byte = val;
+ break;
+ case I2C_SMBUS_WORD_DATA:
+ case I2C_SMBUS_PROC_CALL:
+ buf[0] = zx2967_i2c_readl(zx_i2c, REG_DATA);
+ buf[1] = zx2967_i2c_readl(zx_i2c, REG_DATA);
+ data->word = (buf[0] << 8) | buf[1];
+ break;
+ default:
+ dev_warn(zx_i2c->dev, "Unsupported transaction %d\n", size);
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static int zx2967_smbus_xfer_write(struct zx2967_i2c_info *zx_i2c)
+{
+ unsigned long time_left;
+ u32 val;
+
+ reinit_completion(&zx_i2c->complete);
+ val = zx2967_i2c_readl(zx_i2c, REG_CMD);
+ val |= I2C_START;
+ zx2967_i2c_writel(zx_i2c, val, REG_CMD);
+
+ time_left = wait_for_completion_timeout(&zx_i2c->complete,
+ I2C_TIMEOUT);
+ if (time_left == 0) {
+ dev_err(zx_i2c->dev, "i2c write transfer timed out\n");
+ disable_irq(zx_i2c->irq);
+ zx2967_i2c_reset_hardware(zx_i2c);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int zx2967_smbus_xfer(struct i2c_adapter *adap, u16 addr,
+ unsigned short flags, char read_write,
+ u8 command, int size, union i2c_smbus_data *data)
+{
+ struct zx2967_i2c_info *zx_i2c = i2c_get_adapdata(adap);
+
+ if (size == I2C_SMBUS_QUICK)
+ read_write = I2C_SMBUS_WRITE;
+
+ switch (size) {
+ case I2C_SMBUS_QUICK:
+ case I2C_SMBUS_BYTE:
+ case I2C_SMBUS_BYTE_DATA:
+ case I2C_SMBUS_WORD_DATA:
+ zx2967_smbus_xfer_prepare(zx_i2c, addr, read_write,
+ command, size, data);
+ break;
+ default:
+ dev_warn(&adap->dev, "Unsupported transaction %d\n", size);
+ return -EOPNOTSUPP;
+ }
+
+ if (read_write == I2C_SMBUS_READ)
+ return zx2967_smbus_xfer_read(zx_i2c, size, data);
+
+ return zx2967_smbus_xfer_write(zx_i2c);
+}
+
+#define ZX2967_I2C_FUNCS (I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE | \
+ I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA | \
+ I2C_FUNC_SMBUS_BLOCK_DATA | I2C_FUNC_SMBUS_PROC_CALL | \
+ I2C_FUNC_I2C | I2C_FUNC_SMBUS_I2C_BLOCK)
+
+static u32 zx2967_i2c_func(struct i2c_adapter *adap)
+{
+ return ZX2967_I2C_FUNCS;
+}
+
+static int __maybe_unused zx2967_i2c_suspend(struct device *dev)
+{
+ struct zx2967_i2c_info *zx_i2c = dev_get_drvdata(dev);
+
+ zx_i2c->is_suspended = true;
+ clk_disable_unprepare(zx_i2c->clk);
+
+ return 0;
+}
+
+static int __maybe_unused zx2967_i2c_resume(struct device *dev)
+{
+ struct zx2967_i2c_info *zx_i2c = dev_get_drvdata(dev);
+
+ zx_i2c->is_suspended = false;
+ clk_prepare_enable(zx_i2c->clk);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static const struct dev_pm_ops zx2967_i2c_dev_pm_ops = {
+ .suspend = zx2967_i2c_suspend,
+ .resume = zx2967_i2c_resume,
+};
+#define ZX2967_I2C_DEV_PM_OPS (&zx2967_i2c_dev_pm_ops)
+#else
+#define ZX2967_I2C_DEV_PM_OPS NULL
+#endif
+
+static const struct i2c_algorithm zx2967_i2c_algo = {
+ .master_xfer = zx2967_i2c_xfer,
+ .smbus_xfer = zx2967_smbus_xfer,
+ .functionality = zx2967_i2c_func,
+};
+
+static const struct of_device_id zx2967_i2c_of_match[] = {
+ { .compatible = "zte,zx296718-i2c", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, zx2967_i2c_of_match);
+
+static int zx2967_i2c_probe(struct platform_device *pdev)
+{
+ struct zx2967_i2c_info *zx_i2c;
+ void __iomem *reg_base;
+ struct resource *res;
+ struct clk *clk;
+ int ret;
+
+ zx_i2c = devm_kzalloc(&pdev->dev, sizeof(*zx_i2c), GFP_KERNEL);
+ if (!zx_i2c)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(reg_base))
+ return PTR_ERR(reg_base);
+
+ clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "missing controller clock");
+ return PTR_ERR(clk);
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to enable i2c_clk\n");
+ return ret;
+ }
+
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0)
+ return ret;
+ zx_i2c->irq = ret;
+
+ ret = device_property_read_u32(&pdev->dev, "clock-frequency",
+ &zx_i2c->clk_freq);
+ if (ret) {
+ dev_err(&pdev->dev, "missing clock-frequency");
+ return ret;
+ }
+
+ zx_i2c->reg_base = reg_base;
+ zx_i2c->clk = clk;
+ zx_i2c->dev = &pdev->dev;
+
+ zx_i2c->pin_ctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(zx_i2c->pin_ctrl)) {
+ if (PTR_ERR(zx_i2c->pin_ctrl) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_info(&pdev->dev, "no pinctrl handle\n");
+ }
+
+ spin_lock_init(&zx_i2c->lock);
+ init_completion(&zx_i2c->complete);
+ platform_set_drvdata(pdev, zx_i2c);
+
+ ret = zx2967_i2c_reset_hardware(zx_i2c);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to initialize i2c controller\n");
+ goto err_clk_unprepare;
+ }
+
+ ret = devm_request_irq(&pdev->dev, zx_i2c->irq,
+ zx2967_i2c_isr, 0, dev_name(&pdev->dev), zx_i2c);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request irq %i\n", zx_i2c->irq);
+ goto err_clk_unprepare;
+ }
+
+ i2c_set_adapdata(&zx_i2c->adap, zx_i2c);
+ zx_i2c->adap.owner = THIS_MODULE;
+ zx_i2c->adap.class = I2C_CLASS_DEPRECATED;
+ strlcpy(zx_i2c->adap.name, "zx2967 i2c adapter",
+ sizeof(zx_i2c->adap.name));
+ zx_i2c->adap.algo = &zx2967_i2c_algo;
+ zx_i2c->adap.dev.parent = &pdev->dev;
+ zx_i2c->adap.nr = pdev->id;
+ zx_i2c->adap.dev.of_node = pdev->dev.of_node;
+
+ ret = i2c_add_numbered_adapter(&zx_i2c->adap);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to add zx2967 i2c adapter\n");
+ goto err_clk_unprepare;
+ }
+
+ return 0;
+
+err_clk_unprepare:
+ clk_disable_unprepare(zx_i2c->clk);
+ return ret;
+}
+
+static int zx2967_i2c_remove(struct platform_device *pdev)
+{
+ struct zx2967_i2c_info *zx_i2c = platform_get_drvdata(pdev);
+
+ i2c_del_adapter(&zx_i2c->adap);
+ clk_disable_unprepare(zx_i2c->clk);
+
+ return 0;
+}
+
+static struct platform_driver zx2967_i2c_driver = {
+ .probe = zx2967_i2c_probe,
+ .remove = zx2967_i2c_remove,
+ .driver = {
+ .name = "zx2967_i2c",
+ .of_match_table = zx2967_i2c_of_match,
+ .pm = ZX2967_I2C_DEV_PM_OPS,
+ },
+};
+module_platform_driver(zx2967_i2c_driver);
+
+MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
+MODULE_DESCRIPTION("ZTE zx2967 I2C Bus Controller driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] MAINTAINERS: add zx2967 i2c controller driver to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-26 13:00 UTC (permalink / raw)
To: andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w,
jun.nie-QSEj5FYQhm4dnm+yROfE0A, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
baoyou.xie-QSEj5FYQhm4dnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1485435631-32642-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Add the zx2967 i2c controller driver as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 275c434..757c098 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1987,12 +1987,14 @@ L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/i2c/busses/i2c-zx2967.c
F: drivers/reset/reset-zx2967.c
F: drivers/soc/zte/
F: drivers/thermal/zx*
F: drivers/watchdog/zx2967_wdt.c
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
F: Documentation/devicetree/bindings/soc/zte/
F: Documentation/devicetree/bindings/thermal/zx*
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 1/3] dt: bindings: add documentation for zx2967 family i2c controller
From: Baoyou Xie @ 2017-01-26 13:00 UTC (permalink / raw)
To: andy.shevchenko, jun.nie, wsa, robh+dt, mark.rutland
Cc: linux-arm-kernel, linux-i2c, devicetree, linux-kernel, shawnguo,
baoyou.xie, xie.baoyou, chen.chaokai, wang.qiang01
This patch adds dt-binding documentation for zx2967 family
i2c controller.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/i2c/i2c-zx2967.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt b/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
new file mode 100644
index 0000000..a528374
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
@@ -0,0 +1,24 @@
+ZTE zx2967 I2C controller
+
+Required properties:
+ - compatible: must be "zte,zx296718-i2c"
+ - reg: physical address and length of the device registers
+ - interrupts: a single interrupt specifier
+ - clocks: clock for the device
+ - #address-cells: should be <1>
+ - #size-cells: should be <0>
+ - clock-frequency: the desired I2C bus clock frequency.
+
+Examples:
+
+ i2c@112000 {
+ compatible = "zte,zx296718-i2c";
+ reg = <0x00112000 0x1000>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24m>;
+ #address-cells = <1>
+ #size-cells = <0>;
+ clock-frequency = <1600000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_global_pin>;
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-26 11:49 UTC (permalink / raw)
To: Wolfram Sang, Luis Oliveira
Cc: robh+dt, mark.rutland, jarkko.nikula, andriy.shevchenko,
mika.westerberg, linux-i2c, devicetree, linux-kernel, vz,
Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
In-Reply-To: <20170125204537.i66nykln4fkxqryy@ninjato>
On 25-Jan-17 20:45, Wolfram Sang wrote:
>
>> + * i2c_slave_mode_detect - detect operation mode
>
> I'd rather name it 'i2c_detect_slave_mode'
I will do a V4 with this change.
>
>> + * @dev: The device owning the bus
>> + *
>> + * This checks the device nodes for an I2C slave by checking the address
>> + * used.
>> + *
>> + * Returns true if an I2C slave is detected, otherwise returns false.
>
> Both paragraphs could be a little more explicit. It is not about
> "slaves" or "clients" in general, but about those entries which make the
> current master act as a slave, too.
>
Ok, I see your point of view. I will reword it also.
> The code looks good to me, so we are close to go!
>
> Thanks,
>
> Wolfram
>
Great! Thanks
^ permalink raw reply
* Re: [PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car M3-W)
From: Wolfram Sang @ 2017-01-26 10:17 UTC (permalink / raw)
To: Simon Horman; +Cc: Wolfram Sang, Magnus Damm, linux-i2c, linux-renesas-soc
In-Reply-To: <1485420451-11752-1-git-send-email-horms+renesas@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
On Thu, Jan 26, 2017 at 09:47:31AM +0100, Simon Horman wrote:
> Explicitly list per-SoC binding for r8a7796. No driver change
> is required as the initialisation sequence is currently the same
> as for the R-Car Gen3 fallback binding.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car M3-W)
From: Geert Uytterhoeven @ 2017-01-26 9:04 UTC (permalink / raw)
To: Simon Horman; +Cc: Wolfram Sang, Magnus Damm, Linux I2C, Linux-Renesas
In-Reply-To: <1485420451-11752-1-git-send-email-horms+renesas@verge.net.au>
On Thu, Jan 26, 2017 at 9:47 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Explicitly list per-SoC binding for r8a7796. No driver change
> is required as the initialisation sequence is currently the same
> as for the R-Car Gen3 fallback binding.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car M3-W)
From: Simon Horman @ 2017-01-26 8:47 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Magnus Damm, linux-i2c, linux-renesas-soc, Simon Horman
Explicitly list per-SoC binding for r8a7796. No driver change
is required as the initialisation sequence is currently the same
as for the R-Car Gen3 fallback binding.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
index 7716acc55dec..ae9c2a735f39 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
@@ -10,6 +10,7 @@ Required properties:
- "renesas,iic-r8a7793" (R-Car M2-N)
- "renesas,iic-r8a7794" (R-Car E2)
- "renesas,iic-r8a7795" (R-Car H3)
+ - "renesas,iic-r8a7796" (R-Car M3-W)
- "renesas,iic-sh73a0" (SH-Mobile AG5)
- "renesas,rcar-gen2-iic" (generic R-Car Gen2 compatible device)
- "renesas,rcar-gen3-iic" (generic R-Car Gen3 compatible device)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH 4/4] i2c: octeon: thunderx: Add I2C_CLASS_HWMON
From: Jan Glauber @ 2017-01-26 6:10 UTC (permalink / raw)
To: Wolfram Sang
Cc: Wolfram Sang, Paul Burton, Steven J . Hill, linux-i2c, linux-mips,
David Daney
In-Reply-To: <20170125204923.2mxtlszvco6wxjok@ninjato>
On Wed, Jan 25, 2017 at 09:49:23PM +0100, Wolfram Sang wrote:
> On Sun, Dec 11, 2016 at 11:04:35PM +0100, Wolfram Sang wrote:
> > On Fri, Dec 09, 2016 at 10:31:58AM +0100, Jan Glauber wrote:
> > > It was reported that ipmi_ssif fails to create the
> > > ipmi device on some systems if the adapter class is not containing
> > > I2C_CLASS_HWMON. Fix it by setting the class.
> > >
> > > Reported-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> > > Signed-off-by: Jan Glauber <jglauber@cavium.com>
> >
> > The intention of adapter classes is to *limit* probing to a certain
> > class of devices. If a class is needed to *enable* probing, then
> > something there looks wrong. From the details given, this must be solved
> > elsewhere I'd say.
>
> Makes sense?
>
Yes, perfectly, the patch can be dropped.
thanks,
Jan
^ permalink raw reply
* Re: [PATCH v5 5/5] i2c: mux: pca954x: Add irq-mask-enable to delay enabling irqs
From: Phil Reid @ 2017-01-26 1:56 UTC (permalink / raw)
To: Peter Rosin, Danielle Costantino
Cc: Wolfram Sang, robh+dt, mark.rutland, linux-i2c,
Linux device trees
In-Reply-To: <035315e2-fefa-4332-ee49-32d2dc7cdba7@axentia.se>
On 25/01/2017 19:30, Peter Rosin wrote:
> On 2017-01-25 10:17, Danielle Costantino wrote:
>>
>>
>> On 01/25/2017 12:15 AM, Peter Rosin wrote:
>>> On 2017-01-25 04:50, Danielle Costantino wrote:
>>>> On Mon, Jan 23, 2017 at 1:02 AM, Phil Reid <preid@electromag.com.au> wrote:
>>>>> On 20/01/2017 06:56, Peter Rosin wrote:
>>>>>> On 2017-01-19 08:48, Phil Reid wrote:
>>>>>>> On 18/01/2017 20:19, Peter Rosin wrote:
>>>>>>>> On 2017-01-17 09:00, Phil Reid wrote:
>>>>>
>>>>> [snip]
>>>>>
>>>>>
>>>>>>>> Hmm, this whole thing is fiddly and while it solves your problem it doesn't
>>>>>>>> allow for solving the more general problem when there are "problematic"
>>>>>>>> devices mixed with other devices. At least, I don't see it. And the
>>>>>>>> limitations we are walking into with tracking number of enables etc suggests
>>>>>>>> that we are attacking this at the wrong level. Maybe you should try to work
>>>>>>>> around the hw limitations not in the pca954x driver, but in the irq core?
>>>>>>>
>>>>>>> I'm looking at the option of getting the hardware changed to not route
>>>>>>> the irq for my chips thru the i2c mux. Fortunately the hardware is going thru a
>>>>>>> revision for some other changes. Messing with the irq core sounds dangerous
>>>>>>> with my level of knowledge.
>>>>>>
>>>>>> Yeah, but I bet you'd get some attention from people with more irq
>>>>>> experience. That can't be bad :-)
>>>>>>
>>>>>>> The other way I think I can tackle it after reading the datasheet for the ltc1760 is that
>>>>>>> it'll deassert it's irq (smbalert) line when the host sends a ARA request on the bus segment.
>>>>>>> There's a driver in the kernel for this already, but it's not DT enable and doesn't
>>>>>>> handle multiple bus segments. I'll have a look at that as well.
>>>>>>> Pretty sure it would need the mux to become an irq parent as per patch 1-3 of this series.
>>>>>>> This would be so the system can figure out which segment to do the poll on.
>>>>>>
>>>>>> Yeah sounds neater. It has the slight drawback that it may not work
>>>>>> for pure i2c buses since it an SMB thing??
>>>> If you need to send SMBus commands like ARA, you should be using an
>>>> SMBus 2.0+ compatible bus multiplexer. muxes like the pca954x do not
>>>> automatically select the bus segment that the ARA is destined for. It
>>>> usually is more efficient to only request the data you need from each
>>>> device, rather than checking every segment on each interrupt for the
>>> We are not talking about checking every segment on every interrupt, we
>>> are talking about checking the segments indicated by the INTx bits in
>>> the control register.
>>>
>>>> cause, one could implement a delayed worker to schedule
>>>> checking+clearing the interrupt at a time when the bus is selected for
>>>> use by another slave device on that segment when possible. This will
>>>> reduce the number of bus setup operations per transfer to slaves on
>>>> deeper busses, reducing your i2c latency.
>>> i2c traffic scheduling does not exist in linux to the best of my knowledge,
>>> it's all handled with a simple mutex AFAIK. So, while traffic scheduling
>>> is an interesting problem, I think it is out of scope at this time.
>>>
>>> If you happen to have a pca954x mux (with irq support) and happen to
>>> have devices behind it that needs ARA support, I just don't see how any
>>> of the above is relevant. Yes, it could be more efficient to have the
>>> hardware done differently, but that is in many cases not a possibility.
>>> You have to make do with what you have, and if that costs latency, then
>>> there is little to do about that. You only have to make the new stuff
>>> optional so that old working setups don't suffer.
>> Yes traffic scheduling of I2C transactions is out of the scope of the
>> current problem but I thought that it may be useful to bring it up.
>>>>>> BTW, why do you need special treatment for multiple segments? Will it not
>>>>>> simply have an ARA appear on whatever i2c bus the device sits on? And if
>>>>>> something requests to send an ARA message on a bus that happens to be a
>>>>>> muxed segment, my mental picture is that the mux will be operated as usual
>>>>>> so that the ARA appears on the muxed segment. Maybe I'm missing something?
>>>>>
>>>>> My think was the following.
>>>>> When the SMBALERT is asserted a ARA needs to be sent by the master.
>>>>> If the device sending the SMBALERT is behind a mux when need to know which segment of the bus to enable.
>>>>> Using shared interrupts should work I think, but you have to iterate thru each bus segment.
>>>>> If the alert device is nested behind a couple of muxes this could get expensive.
>>>>> But yeah otherwise I think the correct mux segment will get enabled automatically.
>>>>> The current SMBALERT driver only seems to attached to the root i2c adapter.
>>>> Using ARA in a multi mux environment is very expensive, setting up
>>>> each mux segment and then sending ARA will consume more time than it
>>>> would take if the mux structure was optimized to service devices on
>>>> similar busses, reducing the setup operation count. ARA was only
>>>> implemented on the root bus due to the design of the arbiter and mux
>>>> cannot guarantee that you are the only owner of the bus when you are
>>>> disconnected.
>>> ARA handling should take the irq register of the pca95x into account and
>>> only send ARAs to indicated mux segments. If more than one segment needs
>>> servicing, then of course one ARA for each segment needs to be sent. If
>>> someone builds hardware like this and then expect no latency, that someone
>>> will hopefully at least learn something.
>>>
>>> I do not know how this fits with the existing ARA handling (it probably
>>> doesn't), but what needs to happen is fairly easy to picture.
>>>
>>>> You would also need to handle the cases where segments
>>>> lock up and must be released using the bus reset mechanism, this
>>>> resets the IRQs as well. The added cost of a I2C read to coincide the
>>>> write operation to the mux when the irq pin is asserted is
>>>> unacceptable for low latency applications.
>>> I bet there are a lot of corner cases, and yes, this added cost has to be
>>> optional. Perhaps with each mux child segment opting in for ARA support?
Yes my plan was to opt in.
I was things an optional dt entry on the bus segment.
something like this
i2c-switch@74 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
interrupt-parent = <&ipic>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <2>;
i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
smb-alert = <&i2c-switch 1 IRQ_TYPE_LEVEL_HIGH>;
eeprom@54 {...};
};
i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
eeprom@54 {...};
};
};
>>> If a mux then has a way to determine that an ARA isn't needed for some of
>>> its child segments (by reading some status register), then linux is free
>>> to not send ARAs there. And more importantly, if no mux child segment opts
>>> in for ARA support, it should be possible to preserve current behavior...
>> I agree with making ARA handling for child bus segments optional based
>> on the need of ARA or other SMBus features. We have needed IRQ support
>> for muxes for a while now, I was always concerned about dead locks
>> between setting up the bus and servicing the IRQ. The current patch v6
>> 0/3 appears to handle child IRQs without selecting the bus associated
>> with it. Is the plan to have the irq handling of the child require an
>> i2c transaction on its registered bus, which will in turn select that
>> bus?
>
> You are correct in that the current proposed patches do not support
> having a device being master on a mux child segment and expect that
> any traffic hits the root adapter. A device has no way to lock the
> mux in the correct position short of having its driver issue an
> ordinary transaction (i.e. ->i2c_transfer or ->smbus_xfer) on the
> adapter it sits on. And after the transaction, there is no guarantee
> that the mux will stay in the desired position.
There are SMBus mechanisms for alert the host.
SMBAlert and "Host Notify Protocol".
I just want to make sure where talking about the same thing.
SMBAlert, device asserts ALERT line and then the host polls the i2c bus using an ARA request.
With this method the host can ensure the correct segment is selected before sending the ARA.
The device is always a slave.
"Host Notify Protocol": the devices becomes an i2c master and sends data unsolicited.
No irq are necessary from what I can see, I don't have any devices using this method.
Muxes will get in the way of this one unless they are aware of the protocol.
My work only address SMBAlert and ARA.
>
>> I also thought i2c transactions were not allowed inside an IRQ
>> handler?
>
> They are allowed in a threaded handler, which is very similar to a
> delayed work. If it is not in fact exactly that?
>
I think that's how they work. There are other devices doing basically the same thing
in an threaded IRQ handler. i2c gpio's with irq support for example, eg: mcp23s08
>> Could a delayed work struct could be used to fire off the read
>> transaction that would then trigger the nested IRQs (based on the set
>> bits)? Also the PCA954x has an internal OR of the INT signals coming
>> into it, not an AND like the patch says.
>
> All INT signals on the pca954x are active-low. The only sensible way for
> the mux to combine its active-low inputs into an active-low output is
> with an AND gate. If any of the inputs fire, you want the output to
> also fire. So, I'd say that commit message is fine.
Yes.
>
>> Before allowing IRQs to be
>> handled by the assertion of the active low INT out signal from the
>> PCA954x all child interrupts must be de-asserted else the IRQ will
>> always be set. You could read the value of the interrupt register to see
>> if all bits are clear before allowing unmasking of the devices interrupts.
>
> This is not possible with the pca954x. There is no way to prevent them
> from asserting their output if one of their inputs is asserted. Which
> means that if the irq is shared, and if something else have activated
> it, there will be an irq flood. This is exactly the kind of trouble
> Phil is trying to work around since his chargers continuously fire
> interrupts when there is no driver to quiet them down.
>
> I don't know if going with ARAs can help him, but I think it should be
> possible. I also don't know how difficult it is going to be to make
> this work and also be compatible with whatever ARA support there is
> already. I'm not familiar with how the current ARA support works...
>
Hopefully I'll get to looking at this next week to see how feasible it is.
--
Regards
Phil Reid
^ permalink raw reply
* Re: [wsa:i2c/for-current 2/2] drivers/i2c/busses/i2c-imx-lpi2c.c:642:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state'
From: Wolfram Sang @ 2017-01-25 23:27 UTC (permalink / raw)
To: kbuild test robot
Cc: Gao Pan, kbuild-all, linux-i2c, Wolfram Sang, Vladimir Zapolskiy
In-Reply-To: <201701260730.JLSp8dq5%fengguang.wu@intel.com>
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
> drivers/i2c/busses/i2c-imx-lpi2c.c: In function 'lpi2c_imx_suspend':
> >> drivers/i2c/busses/i2c-imx-lpi2c.c:642:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
> pinctrl_pm_select_sleep_state(dev);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OK, I added the missing include and amended the change. Branches were
not out for long, so I hope nobody notices the rebase.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [wsa:i2c/for-current 2/2] drivers/i2c/busses/i2c-imx-lpi2c.c:642:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state'
From: kbuild test robot @ 2017-01-25 23:04 UTC (permalink / raw)
To: Gao Pan; +Cc: kbuild-all, linux-i2c, Wolfram Sang, Vladimir Zapolskiy
[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
head: 454f919e9afdf0a66576c3d22a2a8f39420c114e
commit: 454f919e9afdf0a66576c3d22a2a8f39420c114e [2/2] i2c: imx-lpi2c: add VLLS mode support
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 454f919e9afdf0a66576c3d22a2a8f39420c114e
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
drivers/i2c/busses/i2c-imx-lpi2c.c: In function 'lpi2c_imx_suspend':
>> drivers/i2c/busses/i2c-imx-lpi2c.c:642:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
pinctrl_pm_select_sleep_state(dev);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/i2c/busses/i2c-imx-lpi2c.c: In function 'lpi2c_imx_resume':
>> drivers/i2c/busses/i2c-imx-lpi2c.c:649:2: error: implicit declaration of function 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration]
pinctrl_pm_select_default_state(dev);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/pinctrl_pm_select_sleep_state +642 drivers/i2c/busses/i2c-imx-lpi2c.c
636 return 0;
637 }
638
639 #ifdef CONFIG_PM_SLEEP
640 static int lpi2c_imx_suspend(struct device *dev)
641 {
> 642 pinctrl_pm_select_sleep_state(dev);
643
644 return 0;
645 }
646
647 static int lpi2c_imx_resume(struct device *dev)
648 {
> 649 pinctrl_pm_select_default_state(dev);
650
651 return 0;
652 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 48623 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: exynos5: fix arbitration lost handling
From: Andi Shyti @ 2017-01-25 22:48 UTC (permalink / raw)
To: Wolfram Sang
Cc: Andrzej Hajda, linux-i2c, Bartlomiej Zolnierkiewicz,
Marek Szyprowski, Krzysztof Kozlowski, Javier Martinez Canillas,
linux-samsung-soc
In-Reply-To: <20170125205715.xaaphsyb7hwowurq@ninjato>
Hi,
> > > In case of arbitration lost adequate interrupt sometimes is not signaled. As
> > > a result transfer timeouts and is not retried, as it should. To avoid such
> > > cases code is added to check transaction status in case of every interrupt.
> > >
> > > Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> >
> > Looks good to me, but I'd like some review from one of the Samsung
> > people?
>
> Ooops, you are from Samsung as well :) Still, I'd like one more ack or
> review from someone with the HW.
I am using this patch already:
Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
Tested-by: Andi Shyti <andi.shyti@samsung.com>
Shouldn't we cc for the stable Kernel?
Andi
^ permalink raw reply
* Re: [PATCH v3] i2c: core: helper function to detect slave mode
From: Andy Shevchenko @ 2017-01-25 21:29 UTC (permalink / raw)
To: Wolfram Sang
Cc: Andy Shevchenko, Luis Oliveira, Rob Herring, Mark Rutland,
Jarkko Nikula, Mika Westerberg, linux-i2c, devicetree,
linux-kernel@vger.kernel.org, Vladimir Zapolskiy, Ramiro.Oliveira,
Joao Pinto, CARLOS.PALMINHA
In-Reply-To: <20170125210118.z5o6y6aurwic4zxc@ninjato>
On Wed, Jan 25, 2017 at 11:01 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Wed, Jan 25, 2017 at 10:50:09PM +0200, Andy Shevchenko wrote:
>> On Wed, 2017-01-25 at 21:45 +0100, Wolfram Sang wrote:
>> > > + * i2c_slave_mode_detect - detect operation mode
>> >
>> > I'd rather name it 'i2c_detect_slave_mode'
>>
>> When I proposed that I kept in ming `git grep -n i2c_slave`.
>
> "i2c.*slave"? :)
'i2c[a-z_]\+slave'
> I think having the verb first makes function names more comprehensible.
> i2c-core is not super consistent with that, but I'd say more follow this
> than not.
I'm okay with either.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [Patch V3] i2c: imx-lpi2c: add VLLS mode support
From: Wolfram Sang @ 2017-01-25 21:10 UTC (permalink / raw)
To: Gao Pan; +Cc: wsa-dev, vz, linux-i2c, frank.li
In-Reply-To: <20170125205305.w2ohn46ouzrxutkm@ninjato>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
On Wed, Jan 25, 2017 at 09:53:06PM +0100, Wolfram Sang wrote:
> On Tue, Jan 17, 2017 at 06:20:55PM +0800, Gao Pan wrote:
> > When system enters VLLS mode, module power is turned off. As a result,
> > all registers are reset to HW default value. After exiting VLLS mode,
> > registers are still in default mode. As a result, the pinctrl settings
> > are incorrect, which will affect the module function.
> >
> > The patch recovers the pinctrl setting when exit VLLS mode.
> >
> > Signed-off-by: Gao Pan <pandy.gao@nxp.com>
>
> Applied to for-next, thanks!
Reconsidered and applied to for-current instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] i2c: i2c-cadence: Initialize configuration before probing devices
From: Wolfram Sang @ 2017-01-25 21:09 UTC (permalink / raw)
To: Mike Looijmans
Cc: linux-i2c, linux-arm-kernel, linux-kernel, soren.brinkmann,
michal.simek
In-Reply-To: <1484578178-3165-1-git-send-email-mike.looijmans@topic.nl>
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
On Mon, Jan 16, 2017 at 03:49:38PM +0100, Mike Looijmans wrote:
> The cadence I2C driver calls cdns_i2c_writereg(..) to setup a workaround
> in the controller, but did so after calling i2c_add_adapter() which starts
> probing devices on the bus. Change the order so that the configuration is
> completely finished before using the adapter.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v10 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-25 21:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: M'boumba Cedric Madianga, robh+dt, mcoquelin.stm32,
alexandre.torgue, linus.walleij, patrice.chotard, linux,
linux-i2c, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20170125202505.4acldm2wla3sqfsp@ninjato>
Hello Wolfram,
On Wed, Jan 25, 2017 at 09:25:05PM +0100, Wolfram Sang wrote:
> On Thu, Jan 19, 2017 at 02:25:13PM +0100, M'boumba Cedric Madianga wrote:
> > This patch adds support for the STM32F4 I2C controller.
> >
> > Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>
> Applied to for-next with Uwe's ack (which looked more like a review to
> me, but well...), thanks to all involved for keeping at it!
I thought about calling it a review, but as I didn't look in detail over
the last version, I degraded it to an ack on purpose.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] i2c: busses: constify dev_pm_ops structures
From: Wolfram Sang @ 2017-01-25 21:03 UTC (permalink / raw)
To: Bhumika Goyal; +Cc: julia.lawall, tony, linux-omap, linux-i2c, linux-kernel
In-Reply-To: <1484474381-1064-1-git-send-email-bhumirks@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
On Sun, Jan 15, 2017 at 03:29:41PM +0530, Bhumika Goyal wrote:
> Declare dev_pm_ops structures as const as they are only stored in the pm
> field of a device_driver structure. This field is of type const, so
> dev_pm_ops structures having similar properties can be declared const
> too.
>
> File size before: drivers/i2c/busses/i2c-omap.o
> text data bss dec hex filename
> 6814 584 0 7398 1ce6 drivers/i2c/busses/i2c-omap.o
>
> File size after: drivers/i2c/busses/i2c-omap.o
> text data bss dec hex filename
> 7006 392 0 7398 1ce6 drivers/i2c/busses/i2c-omap.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Applied to for-next, thanks! I dropped the file size table from the
commit message, though. For me, it is clear enough without it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v10 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: M'boumba Cedric Madianga @ 2017-01-25 21:02 UTC (permalink / raw)
To: Wolfram Sang
Cc: Rob Herring, Maxime Coquelin, Alexandre Torgue, Linus Walleij,
Patrice Chotard, Russell King, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, Uwe Kleine-König
In-Reply-To: <20170125202548.7fyjxo6zwdemg74d@ninjato>
2017-01-25 21:25 GMT+01:00 Wolfram Sang <wsa@the-dreams.de>:
> On Thu, Jan 19, 2017 at 02:25:14PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds I2C1 support for STM32F429 SoC
>>
>> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
>> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>
> Note that patches 3-5 should go via stm-tree or arm-soc. Rather not i2c.
Ok fine.
These patches will be applied in STM32 git tree.
Thanks
^ permalink raw reply
* Re: [PATCH v3] i2c: core: helper function to detect slave mode
From: Wolfram Sang @ 2017-01-25 21:01 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Luis Oliveira, robh+dt, mark.rutland, jarkko.nikula,
mika.westerberg, linux-i2c, devicetree, linux-kernel, vz,
Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
In-Reply-To: <1485377409.2133.339.camel@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
On Wed, Jan 25, 2017 at 10:50:09PM +0200, Andy Shevchenko wrote:
> On Wed, 2017-01-25 at 21:45 +0100, Wolfram Sang wrote:
> > > + * i2c_slave_mode_detect - detect operation mode
> >
> > I'd rather name it 'i2c_detect_slave_mode'
>
> When I proposed that I kept in ming `git grep -n i2c_slave`.
"i2c.*slave"? :)
I think having the verb first makes function names more comprehensible.
i2c-core is not super consistent with that, but I'd say more follow this
than not.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: exynos5: fix arbitration lost handling
From: Wolfram Sang @ 2017-01-25 20:57 UTC (permalink / raw)
To: Andrzej Hajda
Cc: linux-i2c, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Krzysztof Kozlowski, Javier Martinez Canillas, linux-samsung-soc
In-Reply-To: <20170125205554.m7vmhs4tq6bzti52@ninjato>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Wed, Jan 25, 2017 at 09:55:54PM +0100, Wolfram Sang wrote:
> On Thu, Jan 05, 2017 at 01:06:53PM +0100, Andrzej Hajda wrote:
> > In case of arbitration lost adequate interrupt sometimes is not signaled. As
> > a result transfer timeouts and is not retried, as it should. To avoid such
> > cases code is added to check transaction status in case of every interrupt.
> >
> > Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
>
> Looks good to me, but I'd like some review from one of the Samsung
> people?
Ooops, you are from Samsung as well :) Still, I'd like one more ack or
review from someone with the HW.
Thanks,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: exynos5: fix arbitration lost handling
From: Wolfram Sang @ 2017-01-25 20:55 UTC (permalink / raw)
To: Andrzej Hajda
Cc: linux-i2c, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Krzysztof Kozlowski, Javier Martinez Canillas, linux-samsung-soc
In-Reply-To: <1483618013-10721-1-git-send-email-a.hajda@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 3672 bytes --]
On Thu, Jan 05, 2017 at 01:06:53PM +0100, Andrzej Hajda wrote:
> In case of arbitration lost adequate interrupt sometimes is not signaled. As
> a result transfer timeouts and is not retried, as it should. To avoid such
> cases code is added to check transaction status in case of every interrupt.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Looks good to me, but I'd like some review from one of the Samsung
people?
> ---
> Hi,
>
> I am not I2C specialist, this patch is a result of debugging issues
> with SiI8620 MHL driver on TM2 device. I guess the main problem is
> with SiI8620 chip, but exynos5 i2c is also guilty - with i2c-gpio driver
> it works correctly - there is only one arbitration lost at 1st transaction
> (which is properly handled - transfer is repeated succesfully). In case
> of exynos5 there are much more arbitration losts. Lowering bus speed
> decreases frequency of losts but do not eliminate them.
> Any help/hint, what could cause such issues?
>
> I guess increasing adap.retries should also decrease fail probability,
> currently for exynos5 it is set to 3.
>
> Regards
> Andrzej
> ---
> drivers/i2c/busses/i2c-exynos5.c | 28 +++++++++++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
> index bea6071..a01c1ae 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -130,12 +130,32 @@
> /* I2C_TRANS_STATUS register bits */
> #define HSI2C_MASTER_BUSY (1u << 17)
> #define HSI2C_SLAVE_BUSY (1u << 16)
> +
> +/* I2C_TRANS_STATUS register bits for Exynos5 variant */
> #define HSI2C_TIMEOUT_AUTO (1u << 4)
> #define HSI2C_NO_DEV (1u << 3)
> #define HSI2C_NO_DEV_ACK (1u << 2)
> #define HSI2C_TRANS_ABORT (1u << 1)
> #define HSI2C_TRANS_DONE (1u << 0)
>
> +/* I2C_TRANS_STATUS register bits for Exynos7 variant */
> +#define HSI2C_MASTER_ST_MASK 0xf
> +#define HSI2C_MASTER_ST_IDLE 0x0
> +#define HSI2C_MASTER_ST_START 0x1
> +#define HSI2C_MASTER_ST_RESTART 0x2
> +#define HSI2C_MASTER_ST_STOP 0x3
> +#define HSI2C_MASTER_ST_MASTER_ID 0x4
> +#define HSI2C_MASTER_ST_ADDR0 0x5
> +#define HSI2C_MASTER_ST_ADDR1 0x6
> +#define HSI2C_MASTER_ST_ADDR2 0x7
> +#define HSI2C_MASTER_ST_ADDR_SR 0x8
> +#define HSI2C_MASTER_ST_READ 0x9
> +#define HSI2C_MASTER_ST_WRITE 0xa
> +#define HSI2C_MASTER_ST_NO_ACK 0xb
> +#define HSI2C_MASTER_ST_LOSE 0xc
> +#define HSI2C_MASTER_ST_WAIT 0xd
> +#define HSI2C_MASTER_ST_WAIT_CMD 0xe
> +
> /* I2C_ADDR register bits */
> #define HSI2C_SLV_ADDR_SLV(x) ((x & 0x3ff) << 0)
> #define HSI2C_SLV_ADDR_MAS(x) ((x & 0x3ff) << 10)
> @@ -437,6 +457,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
>
> int_status = readl(i2c->regs + HSI2C_INT_STATUS);
> writel(int_status, i2c->regs + HSI2C_INT_STATUS);
> + trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS);
>
> /* handle interrupt related to the transfer status */
> if (i2c->variant->hw == HSI2C_EXYNOS7) {
> @@ -460,8 +481,13 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
> i2c->state = -ETIMEDOUT;
> goto stop;
> }
> +
> + switch (trans_status & HSI2C_MASTER_ST_MASK) {
> + case HSI2C_MASTER_ST_LOSE:
> + i2c->state = -EAGAIN;
> + goto stop;
> + }
> } else if (int_status & HSI2C_INT_I2C) {
> - trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS);
> if (trans_status & HSI2C_NO_DEV_ACK) {
> dev_dbg(i2c->dev, "No ACK from device\n");
> i2c->state = -ENXIO;
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Patch V3] i2c: imx-lpi2c: add VLLS mode support
From: Wolfram Sang @ 2017-01-25 20:53 UTC (permalink / raw)
To: Gao Pan; +Cc: wsa-dev, vz, linux-i2c, frank.li
In-Reply-To: <1484648455-5454-1-git-send-email-pandy.gao@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On Tue, Jan 17, 2017 at 06:20:55PM +0800, Gao Pan wrote:
> When system enters VLLS mode, module power is turned off. As a result,
> all registers are reset to HW default value. After exiting VLLS mode,
> registers are still in default mode. As a result, the pinctrl settings
> are incorrect, which will affect the module function.
>
> The patch recovers the pinctrl setting when exit VLLS mode.
>
> Signed-off-by: Gao Pan <pandy.gao@nxp.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: mv64xxx: add suspend/resume support
From: Wolfram Sang @ 2017-01-25 20:50 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: linux-i2c, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Grzegorz Jaszczyk
In-Reply-To: <1482422042-30201-1-git-send-email-thomas.petazzoni@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
On Thu, Dec 22, 2016 at 04:54:02PM +0100, Thomas Petazzoni wrote:
> From: Grzegorz Jaszczyk <jaz@semihalf.com>
>
> This commit implements suspend/resume support in the mv64xxx I2C
> controller driver. There is no need to implement a ->suspend() hook, as
> calling mv64xxx_i2c_hw_init() at ->resume() time is enough.
>
> Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
> Reviewed-by: Nadav Haklai <nadavh@marvell.com>
> Reviewed-by: Lior Amsalem <alior@marvell.com>
> Tested-by: Lior Amsalem <alior@marvell.com>
> [Thomas: switch to dev_pm_ops, fix build warning when !PM.]
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3] i2c: core: helper function to detect slave mode
From: Andy Shevchenko @ 2017-01-25 20:50 UTC (permalink / raw)
To: Wolfram Sang, Luis Oliveira
Cc: robh+dt, mark.rutland, jarkko.nikula, mika.westerberg, linux-i2c,
devicetree, linux-kernel, vz, Ramiro.Oliveira, Joao.Pinto,
CARLOS.PALMINHA
In-Reply-To: <20170125204537.i66nykln4fkxqryy@ninjato>
On Wed, 2017-01-25 at 21:45 +0100, Wolfram Sang wrote:
> > + * i2c_slave_mode_detect - detect operation mode
>
> I'd rather name it 'i2c_detect_slave_mode'
When I proposed that I kept in ming `git grep -n i2c_slave`.
> The code looks good to me, so we are close to go!
Thumb up!
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH 4/4] i2c: octeon: thunderx: Add I2C_CLASS_HWMON
From: Wolfram Sang @ 2017-01-25 20:49 UTC (permalink / raw)
To: Jan Glauber
Cc: Wolfram Sang, Paul Burton, Steven J . Hill, linux-i2c, linux-mips,
David Daney
In-Reply-To: <20161211220434.GH2552@katana>
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Sun, Dec 11, 2016 at 11:04:35PM +0100, Wolfram Sang wrote:
> On Fri, Dec 09, 2016 at 10:31:58AM +0100, Jan Glauber wrote:
> > It was reported that ipmi_ssif fails to create the
> > ipmi device on some systems if the adapter class is not containing
> > I2C_CLASS_HWMON. Fix it by setting the class.
> >
> > Reported-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> > Signed-off-by: Jan Glauber <jglauber@cavium.com>
>
> The intention of adapter classes is to *limit* probing to a certain
> class of devices. If a class is needed to *enable* probing, then
> something there looks wrong. From the details given, this must be solved
> elsewhere I'd say.
Makes sense?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox