[PATCH v2 0/2] I2C support for NXP LPC18xx family
This patch set adds a I2C driver and documentation for the I2C peripheral found on many NXP LPC MCUs. The driver is a rework of an old driver by Kevin Wells. It has been modified to support modern resource allocation, device tree and generally cleaned up. Driver was originally written to support the LPC2xxx platforms. Patches based on i2c/for-next and tested on Embedded Artists' LPC4357 Dev Kit and Hitex LPC4350 Eval board with several I2C devices. This version address comments from Wolfram Sang. Changes since v1: - remove dev_dbg() leftovers from development/debugging - use i2c_add_adapter - change return value on NACK and arb lost (I think all the others should be okay as they are) - fix 80 char warnings (involved s/reg_base/base) - rebase on i2c/for-next Joachim Eastwood (2): i2c: add i2c-lpc2k driver doc: dt: add documentation for nxp,lpc1788-i2c .../devicetree/bindings/i2c/i2c-lpc2k.txt | 33 ++ drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-lpc2k.c | 513 + 4 files changed, 557 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt create mode 100644 drivers/i2c/busses/i2c-lpc2k.c -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] i2c: add i2c-lpc2k driver
Add support for the I2C controller found on several NXP devices
including LPC2xxx, LPC178x/7x and LPC18xx/43xx. The controller
is implemented as a state machine and the driver act upon the
state changes when the bus is accessed.
The I2C controller supports master/slave operation, bus
arbitration, programmable clock rate, and speeds up to 1 Mbit/s.
Signed-off-by: Joachim Eastwood
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-lpc2k.c | 513 +
3 files changed, 524 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-lpc2k.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 0b798ae708fe..48f4b796003c 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -619,6 +619,16 @@ config I2C_KEMPLD
This driver can also be built as a module. If so, the module
will be called i2c-kempld.
+config I2C_LPC2K
+ tristate "I2C bus support for NXP LPC2K/LPC178x/18xx/43xx"
+ depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
+ help
+ This driver supports the I2C interface found several NXP
+ devices including LPC2xxx, LPC178x/7x and LPC18xx/43xx.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-lpc2k.
+
config I2C_MESON
tristate "Amlogic Meson I2C controller"
depends on ARCH_MESON
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 50e8bbb65f1c..6df3b303bd09 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_I2C_IMX) += i2c-imx.o
obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
obj-$(CONFIG_I2C_JZ4780) += i2c-jz4780.o
obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o
+obj-$(CONFIG_I2C_LPC2K)+= i2c-lpc2k.o
obj-$(CONFIG_I2C_MESON)+= i2c-meson.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o
diff --git a/drivers/i2c/busses/i2c-lpc2k.c b/drivers/i2c/busses/i2c-lpc2k.c
new file mode 100644
index ..8560a13bf1b3
--- /dev/null
+++ b/drivers/i2c/busses/i2c-lpc2k.c
@@ -0,0 +1,513 @@
+/*
+ * Copyright (C) 2011 NXP Semiconductors
+ *
+ * Code portions referenced from the i2x-pxa and i2c-pnx drivers
+ *
+ * Make SMBus byte and word transactions work on LPC178x/7x
+ * Copyright (c) 2012
+ * Alexander Potashev, Emcraft Systems, aspotas...@emcraft.com
+ * Anton Protopopov, Emcraft Systems, ant...@emcraft.com
+ *
+ * Copyright (C) 2015 Joachim Eastwood
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* LPC24xx register offsets and bits */
+#define LPC24XX_I2CONSET 0x00
+#define LPC24XX_I2STAT 0x04
+#define LPC24XX_I2DAT 0x08
+#define LPC24XX_I2ADDR 0x0c
+#define LPC24XX_I2SCLH 0x10
+#define LPC24XX_I2SCLL 0x14
+#define LPC24XX_I2CONCLR 0x18
+
+#define LPC24XX_AA BIT(2)
+#define LPC24XX_SI BIT(3)
+#define LPC24XX_STOBIT(4)
+#define LPC24XX_STABIT(5)
+#define LPC24XX_I2EN BIT(6)
+
+#define LPC24XX_STO_AA (LPC24XX_STO | LPC24XX_AA)
+#define LPC24XX_CLEAR_ALL (LPC24XX_AA | LPC24XX_SI | LPC24XX_STO | \
+LPC24XX_STA | LPC24XX_I2EN)
+
+/* I2C SCL clock has different duty cycle depending on mode */
+#define I2C_STD_MODE_DUTY 46
+#define I2C_FAST_MODE_DUTY 36
+#define I2C_FAST_MODE_PLUS_DUTY38
+
+/*
+ * 26 possible I2C status codes, but codes applicable only
+ * to master are listed here and used in this driver
+ */
+enum {
+ M_BUS_ERROR = 0x00,
+ M_START = 0x08,
+ M_REPSTART = 0x10,
+ MX_ADDR_W_ACK = 0x18,
+ MX_ADDR_W_NACK = 0x20,
+ MX_DATA_W_ACK = 0x28,
+ MX_DATA_W_NACK = 0x30,
+ M_DATA_ARB_LOST = 0x38,
+ MR_ADDR_R_ACK = 0x40,
+ MR_ADDR_R_NACK = 0x48,
+ MR_DATA_R_ACK = 0x50,
+ MR_DATA_R_NACK = 0x58,
+ M_I2C_IDLE = 0xf8,
+};
+
+struct lpc2k_i2c {
+ void __iomem*base;
+ struct clk *clk;
+ int irq;
+ wait_queue_head_t wait;
+ struct i2c_adapter adap;
+ struct i2c_msg *msg;
+ int msg_idx;
+ int msg_status;
+ int is_last;
+};
+
+static void i2c_lpc2k_reset(struct lpc2k_i2
[PATCH v2 2/2] doc: dt: add documentation for nxp,lpc1788-i2c
Add binding documentation for the nxp,lpc1788-i2c controller
which also can be found on LPC2xxx, LPC178x/7x and LPC18xx/43xx
devices.
Signed-off-by: Joachim Eastwood
---
.../devicetree/bindings/i2c/i2c-lpc2k.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
b/Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
new file mode 100644
index ..4101aa621ad4
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
@@ -0,0 +1,33 @@
+NXP I2C controller for LPC2xxx/178x/18xx/43xx
+
+Required properties:
+ - compatible: must be "nxp,lpc1788-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>
+
+Optional properties:
+- clock-frequency: the desired I2C bus clock frequency in Hz; in
+ absence of this property the default value is used (100 kHz).
+
+Example:
+i2c0: i2c@400a1000 {
+ compatible = "nxp,lpc1788-i2c";
+ reg = <0x400a1000 0x1000>;
+ interrupts = <18>;
+ clocks = <&ccu1 CLK_APB1_I2C0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+&i2c0 {
+ clock-frequency = <40>;
+
+ lm75@48 {
+ compatible = "nxp,lm75";
+ reg = <0x48>;
+ };
+};
+
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] eeprom: at24: extend driver to plug into the NVMEM framework
Hi Andrew,
> Andrew Lunn hat am 16. August 2015 um 15:11 geschrieben:
>
>
> On Sun, Aug 16, 2015 at 10:28:06AM +0200, Stefan Wahren wrote:
> > Hi Andrew,
> >
> > > Andrew Lunn hat am 16. August 2015 um 04:54 geschrieben:
> > >
> > >
> > > Add a read only regmap for accessing the EEPROM, and then use that
> > > with the NVMEM framework.
> > >
> > > Signed-off-by: Andrew Lunn
> > > ---
> > > drivers/misc/eeprom/at24.c | 65
> > > ++
> > > 1 file changed, 65 insertions(+)
> > >
> > > diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> > > index 2d3db81be099..0e80c0c09d4e 100644
> > > --- a/drivers/misc/eeprom/at24.c
> > > +++ b/drivers/misc/eeprom/at24.c
> > > @@ -22,6 +22,8 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> >
> > shouldn't the dependancies in Kconfig updated (depends on REGMAP) too?
>
> Hi Stefan
>
> This is why the patch is RFC.
>
> REGMAP has stub implementations for when it is not. NVMEM also has
> stub implementations. NVMEM does however select REGMAP. So it should
> be possible to compile this driver without NVMEM support. Hopefully
> 0day will find my git branch and compile it in different ways to see
> if i've got this right.
you are right.
>
> As part of RFC, is this O.K?
>
> Another question which spring to mind is, do we want the eeprom to be
> in /sys twice, the old and the new way? Backwards compatibility says
> the old must stay. Do we want a way to suppress the new? Or should we
> be going as far as refractoring the code into a core library, and two
> wrapper drivers, old and new?
I think these are questions for the framework maintainers.
>
> > > +static int at24_regmap_write(void *context, const void *data, size_t
> > > count)
> > > +{
> > > + struct at24_data *at24 = context;
> > > +
> > > + return at24_write(at24, data, 0, count);
> >
> > Since the patch only provides read only support this function could return
> > 0.
>
> Humm, the comment is out of date. Regmap does not work too well
> without a write method. So i ended up implementing it. But it has
> hardly been tested, where as i have hammered on read.
I think you didn't understand my comment. I know the write function is
necessary, but
calling at24_write() instead of simply returning 0 does make no sense to me.
Regards
Stefan
>
> Thanks
> Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] eeprom: at24: extend driver to plug into the NVMEM framework
On Sun, Aug 16, 2015 at 10:28:06AM +0200, Stefan Wahren wrote:
> Hi Andrew,
>
> > Andrew Lunn hat am 16. August 2015 um 04:54 geschrieben:
> >
> >
> > Add a read only regmap for accessing the EEPROM, and then use that
> > with the NVMEM framework.
> >
> > Signed-off-by: Andrew Lunn
> > ---
> > drivers/misc/eeprom/at24.c | 65
> > ++
> > 1 file changed, 65 insertions(+)
> >
> > diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> > index 2d3db81be099..0e80c0c09d4e 100644
> > --- a/drivers/misc/eeprom/at24.c
> > +++ b/drivers/misc/eeprom/at24.c
> > @@ -22,6 +22,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
>
> shouldn't the dependancies in Kconfig updated (depends on REGMAP) too?
Hi Stefan
This is why the patch is RFC.
REGMAP has stub implementations for when it is not. NVMEM also has
stub implementations. NVMEM does however select REGMAP. So it should
be possible to compile this driver without NVMEM support. Hopefully
0day will find my git branch and compile it in different ways to see
if i've got this right.
As part of RFC, is this O.K?
Another question which spring to mind is, do we want the eeprom to be
in /sys twice, the old and the new way? Backwards compatibility says
the old must stay. Do we want a way to suppress the new? Or should we
be going as far as refractoring the code into a core library, and two
wrapper drivers, old and new?
> > +static int at24_regmap_write(void *context, const void *data, size_t count)
> > +{
> > + struct at24_data *at24 = context;
> > +
> > + return at24_write(at24, data, 0, count);
>
> Since the patch only provides read only support this function could return 0.
Humm, the comment is out of date. Regmap does not work too well
without a write method. So i ended up implementing it. But it has
hardly been tested, where as i have hammered on read.
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
On 12/08/15 15:31, Irina Tirdea wrote:
> Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> enable/disable the bus at each i2c transfer and must wait for
> the enable/disable to happen before sending the data.
>
> When reading data in the trigger handler, the bmg160 driver does
> one i2c transfer for each axis. This has an impact on the frequency
> of the gyroscope at high sample rates due to additional delays
> introduced by the i2c bus at each transfer.
>
> Reading all axis values in one i2c transfer reduces the delays
> introduced by the i2c bus. Uses i2c_smbus_read_i2c_block_data_or_emulated
> that will fallback to reading each axis as a separate word in case i2c
> block read is not supported.
>
> Signed-off-by: Irina Tirdea
> Acked-by: Jonathan Cameron
> Acked-by: Srinivas Pandruvada
Note, that in the meantime the bmg160 driver just went all regmap
on us (as part of adding SPI support - though that step hasn't
happened yet). Hence we'll need a means of telling regmap about this
possibility.
> ---
> drivers/iio/gyro/bmg160.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/gyro/bmg160.c b/drivers/iio/gyro/bmg160.c
> index b2a6ccb..1ff306d 100644
> --- a/drivers/iio/gyro/bmg160.c
> +++ b/drivers/iio/gyro/bmg160.c
> @@ -772,6 +772,7 @@ static const struct iio_event_spec bmg160_event = {
> .sign = 's',\
> .realbits = 16, \
> .storagebits = 16, \
> + .endianness = IIO_LE, \
> }, \
> .event_spec = &bmg160_event,\
> .num_event_specs = 1\
> @@ -809,19 +810,16 @@ static irqreturn_t bmg160_trigger_handler(int irq, void
> *p)
> struct iio_poll_func *pf = p;
> struct iio_dev *indio_dev = pf->indio_dev;
> struct bmg160_data *data = iio_priv(indio_dev);
> - int bit, ret, i = 0;
> + int ret = 0;
>
> mutex_lock(&data->mutex);
> - for (bit = 0; bit < AXIS_MAX; bit++) {
> - ret = i2c_smbus_read_word_data(data->client,
> -BMG160_AXIS_TO_REG(bit));
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - goto err;
> - }
> - data->buffer[i++] = ret;
> - }
> + ret = i2c_smbus_read_i2c_block_data_or_emulated(data->client,
> + BMG160_REG_XOUT_L,
> + AXIS_MAX * 2,
> + (u8 *)data->buffer);
> mutex_unlock(&data->mutex);
> + if (ret < 0)
> + goto err;
>
> iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> pf->timestamp);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] eeprom: at24: extend driver to plug into the NVMEM framework
Hi Andrew,
> Andrew Lunn hat am 16. August 2015 um 04:54 geschrieben:
>
>
> Add a read only regmap for accessing the EEPROM, and then use that
> with the NVMEM framework.
>
> Signed-off-by: Andrew Lunn
> ---
> drivers/misc/eeprom/at24.c | 65 ++
> 1 file changed, 65 insertions(+)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 2d3db81be099..0e80c0c09d4e 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -22,6 +22,8 @@
> #include
> #include
> #include
> +#include
> +#include
shouldn't the dependancies in Kconfig updated (depends on REGMAP) too?
> #include
>
> /*
> @@ -69,6 +71,10 @@ struct at24_data {
> unsigned write_max;
> unsigned num_addresses;
>
> + struct regmap_config regmap_config;
> + struct nvmem_config nvmem_config;
> + struct nvmem_device *nvmem;
> +
> /*
> * Some chips tie up multiple I2C addresses; dummy devices reserve
> * them for us, and we'll use them with SMBus calls.
> @@ -471,6 +477,34 @@ static ssize_t at24_macc_write(struct memory_accessor
> *macc, const char *buf,
>
> /*-*/
>
> +/*
> + * Provide a regmap interface, which is registered with the NVMEM
> + * framework
> +*/
> +static int at24_regmap_read(void *context, const void *reg, size_t reg_size,
> + void *val, size_t val_size)
> +{
> + struct at24_data *at24 = context;
> + off_t offset = *(u32 *)reg;
> +
> + return at24_read(at24, val, offset, val_size);
> +}
> +
> +static int at24_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct at24_data *at24 = context;
> +
> + return at24_write(at24, data, 0, count);
Since the patch only provides read only support this function could return 0.
Regards
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
