Re: [i2c] [PATCH] i2c driver for Maxim max9485 audio clock generator chip
On Mon, Oct 20, 2008 at 11:02:05PM -0400, Jon Smirl wrote: Signed-off-by: Jon Smirl [EMAIL PROTECTED] --- drivers/i2c/chips/Kconfig |9 drivers/i2c/chips/Makefile |1 drivers/i2c/chips/max9485.c | 106 +++ include/linux/i2c/max9485.h | 38 +++ 4 files changed, 154 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/chips/max9485.c create mode 100644 include/linux/i2c/max9485.h diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 1735682..bc2a6d3 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -40,6 +40,15 @@ config AT24 This driver can also be built as a module. If so, the module will be called at24. +config MAX9485 + tristate Maxim MAX9485 Programmable Audio Clock Generator + help + If you say yes here you get support for Maxim MAX9485 + Programmable Audio Clock Generator. + + This driver can also be built as a module. If so, the module + will be called max9485. + config SENSORS_EEPROM tristate EEPROM reader depends on EXPERIMENTAL diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile index ca520fa..1560baf 100644 --- a/drivers/i2c/chips/Makefile +++ b/drivers/i2c/chips/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_DS1682) += ds1682.o obj-$(CONFIG_AT24) += at24.o +obj-$(CONFIG_MAX9485)+= max9485.o obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o obj-$(CONFIG_SENSORS_MAX6875)+= max6875.o obj-$(CONFIG_SENSORS_PCA9539)+= pca9539.o diff --git a/drivers/i2c/chips/max9485.c b/drivers/i2c/chips/max9485.c new file mode 100644 index 000..65058b4 --- /dev/null +++ b/drivers/i2c/chips/max9485.c @@ -0,0 +1,106 @@ +/* + * Maxim max9485 Programmable Audio Clock Generator driver + * + * Written by: Jon Smirl [EMAIL PROTECTED] + * + * Copyright (C) Digispeaker.com you need a date at which you are claiming the copyright. I'd also check that (C) in a big symbol is a legally recognised substitute for an small c in an circle. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 2/8] i2c-omap: Close suspected race between omap_i2c_idle() and omap_i2c_isr()
On Thu, Sep 25, 2008 at 10:53:48AM +0300, Tony Lindgren wrote:
From: Paul Walmsley [EMAIL PROTECTED]
omap_i2c_idle() sets an internal flag, dev-idle, instructing its
ISR to decline interrupts. It sets this flag before it actually masks
the interrupts on the I2C controller. This is problematic, since an
I2C interrupt could arrive after dev-idle is set, but before the
interrupt source is masked. When this happens, Linux disables the I2C
controller's IRQ, causing all future transactions on the bus to fail.
Symptoms, happening on about 7% of boots:
irq 56: nobody cared (try booting with the irqpoll option)
warning traceback here
Disabling IRQ #56
i2c_omap i2c_omap.1: controller timed out
In omap_i2c_idle(), this patch sets dev-idle only after the interrupt
mask write to the I2C controller has left the ARM write buffer.
That's probably the major offender. For additional prophylaxis, in
omap_i2c_unidle(), the patch clears the dev-idle flag before
interrupts are enabled, rather than afterwards.
The patch has survived twenty-two reboots on the 3430SDP here without
wedging I2C1. Not absolutely dispositive, but promising!
that looks ok.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index cfb76f5..a06ad42 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -181,22 +181,28 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
if (dev-iclk != NULL)
clk_enable(dev-iclk);
clk_enable(dev-fclk);
+ dev-idle = 0;
if (dev-iestate)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
- dev-idle = 0;
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
u16 iv;
- dev-idle = 1;
dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev-rev1)
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears
*/
else
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
+ /*
+ * The wmb() is to ensure that the I2C interrupt mask write
+ * reaches the I2C controller before the dev-idle store
+ * occurs.
+ */
+ wmb();
+ dev-idle = 1;
clk_disable(dev-fclk);
if (dev-iclk != NULL)
clk_disable(dev-iclk);
--
1.5.6.rc3.21.g8c6b5
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 3/8] i2c-omap: Add high-speed support to omap-i2c
On Thu, Sep 25, 2008 at 10:53:49AM +0300, Tony Lindgren wrote:
From: Syed Mohammed Khasim [EMAIL PROTECTED]
Omap2430 has additional support for high-speed I2C.
This patch moves I2C speed parameter (from module) to platform data.
Also added basic High Speed support based on I2C bus speed.
This patch is tested for high speed I2C (with TWL4030 Keypad) and works as
expected.
Signed-off-by: Syed Mohammed Khasim [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-omap.c | 111 +---
1 files changed, 80 insertions(+), 31 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a06ad42..0d30790 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -83,6 +83,7 @@
/* I2C Configuration Register (OMAP_I2C_CON): */
#define OMAP_I2C_CON_EN (1 15) /* I2C module enable */
#define OMAP_I2C_CON_BE (1 14) /* Big endian mode */
+#define OMAP_I2C_CON_OPMODE (1 12) /* High Speed support */
#define OMAP_I2C_CON_STB (1 11) /* Start byte mode (master) */
#define OMAP_I2C_CON_MST (1 10) /* Master/slave mode */
#define OMAP_I2C_CON_TRX (1 9)/* TX/RX mode (master only) */
@@ -91,6 +92,10 @@
#define OMAP_I2C_CON_STP (1 1)/* Stop cond (master only) */
#define OMAP_I2C_CON_STT (1 0)/* Start condition (master) */
+/* I2C SCL time value when Master */
+#define OMAP_I2C_SCLL_HSSCLL 8
+#define OMAP_I2C_SCLH_HSSCLH 8
+
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test
enable */
@@ -109,12 +114,6 @@
/* I2C System Configuration Register (OMAP_I2C_SYSC): */
#define OMAP_I2C_SYSC_SRST (1 1)/* Soft Reset */
-/* REVISIT: Use platform_data instead of module parameters */
-/* Fast Mode = 400 kHz, Standard = 100 kHz */
-static int clock = 100; /* Default: 100 kHz */
-module_param(clock, int, 0);
-MODULE_PARM_DESC(clock, Set I2C clock in kHz: 400=fast mode (default ==
100));
-
struct omap_i2c_dev {
struct device *dev;
void __iomem*base; /* virtual */
@@ -123,6 +122,7 @@ struct omap_i2c_dev {
struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
struct resource *ioarea;
+ u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
size_t buf_len;
@@ -152,17 +152,28 @@ static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
return -ENODEV;
}
}
-
- dev-fclk = clk_get(dev-dev, i2c_fck);
- if (IS_ERR(dev-fclk)) {
- if (dev-iclk != NULL) {
- clk_put(dev-iclk);
- dev-iclk = NULL;
+ /* For I2C operations on 2430 we need 96Mhz clock */
+ if (cpu_is_omap2430()) {
+ dev-fclk = clk_get(dev-dev, i2chs_fck);
+ if (IS_ERR(dev-fclk)) {
+ if (dev-iclk != NULL) {
+ clk_put(dev-iclk);
+ dev-iclk = NULL;
+ }
I'm sorry, but I think this is mis-use of the clock system. The
actual name of the clock should be provided for the driver, not
the driver having to search for different clocks.
+ dev-fclk = NULL;
+ return -ENODEV;
+ }
+ } else {
+ dev-fclk = clk_get(dev-dev, i2c_fck);
+ if (IS_ERR(dev-fclk)) {
+ if (dev-iclk != NULL) {
+ clk_put(dev-iclk);
+ dev-iclk = NULL;
+ }
+ dev-fclk = NULL;
+ return -ENODEV;
}
- dev-fclk = NULL;
- return -ENODEV;
}
-
return 0;
}
@@ -210,9 +221,11 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
+ unsigned long internal_clk = 0;
if (!dev-rev1) {
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
@@ -255,18 +268,47 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
+ if (cpu_is_omap2430()) {
+
+ /* HSI2C controller internal clk rate should be 19.2 Mhz */
+ internal_clk = 19200;
+ fclk_rate = clk_get_rate(dev-fclk) / 1000;
+
+ /* Compute
Re: [i2c] [PATCH 4/8] i2c-omap: FIFO handling support and broken hw workaround for i2c-omap
On Thu, Sep 25, 2008 at 10:53:50AM +0300, Tony Lindgren wrote:
From: Nishanth Menon [EMAIL PROTECTED]
Based on an earlier patch from Nishant Menon:
- Transfers can use FIFO on FIFO capable devices
- Prevents errors for HSI2C if FIFO is not used
- Implemented errenous handling of STT-STP handling on SDP2430
Also merged in is a fix from Jaron Marini to fix occasional i2c
hang if OMAP_I2C_CON_STT remains asserted.
This looks ok
Signed-off-by: Jason P Marini [EMAIL PROTECTED]
Signed-off-by: Nishanth Menon [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-omap.c | 189
-
1 files changed, 149 insertions(+), 40 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0d30790..ded4636 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,8 +55,11 @@
#define OMAP_I2C_SCLL_REG0x34
#define OMAP_I2C_SCLH_REG0x38
#define OMAP_I2C_SYSTEST_REG 0x3c
+#define OMAP_I2C_BUFSTAT_REG 0x40
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
+#define OMAP_I2C_IE_XDR (1 14) /* TX Buffer drain int
enable */
+#define OMAP_I2C_IE_RDR (1 13) /* RX Buffer drain int
enable */
#define OMAP_I2C_IE_XRDY (1 4)/* TX data ready int enable */
#define OMAP_I2C_IE_RRDY (1 3)/* RX data ready int enable */
#define OMAP_I2C_IE_ARDY (1 2)/* Access ready int enable */
@@ -64,7 +67,8 @@
#define OMAP_I2C_IE_AL (1 0)/* Arbitration lost int
ena */
/* I2C Status Register (OMAP_I2C_STAT): */
-#define OMAP_I2C_STAT_SBD(1 15) /* Single byte data */
+#define OMAP_I2C_STAT_XDR(1 14) /* TX Buffer draining */
+#define OMAP_I2C_STAT_RDR(1 13) /* RX Buffer draining */
#define OMAP_I2C_STAT_BB (1 12) /* Bus busy */
#define OMAP_I2C_STAT_ROVR (1 11) /* Receive overrun */
#define OMAP_I2C_STAT_XUDF (1 10) /* Transmit underflow */
@@ -78,12 +82,14 @@
/* I2C Buffer Configuration Register (OMAP_I2C_BUF): */
#define OMAP_I2C_BUF_RDMA_EN (1 15) /* RX DMA channel enable */
+#define OMAP_I2C_BUF_RXFIF_CLR (1 14) /* RX FIFO Clear */
#define OMAP_I2C_BUF_XDMA_EN (1 7)/* TX DMA channel enable */
+#define OMAP_I2C_BUF_TXFIF_CLR (1 6)/* TX FIFO Clear */
/* I2C Configuration Register (OMAP_I2C_CON): */
#define OMAP_I2C_CON_EN (1 15) /* I2C module enable */
#define OMAP_I2C_CON_BE (1 14) /* Big endian mode */
-#define OMAP_I2C_CON_OPMODE (1 12) /* High Speed support */
+#define OMAP_I2C_CON_OPMODE_HS (1 12) /* High Speed support */
#define OMAP_I2C_CON_STB (1 11) /* Start byte mode (master) */
#define OMAP_I2C_CON_MST (1 10) /* Master/slave mode */
#define OMAP_I2C_CON_TRX (1 9)/* TX/RX mode (master only) */
@@ -127,7 +133,12 @@ struct omap_i2c_dev {
u8 *buf;
size_t buf_len;
struct i2c_adapter adapter;
+ u8 fifo_size; /* use as flag and value
+ * fifo_size==0 implies no fifo
+ * if set, should be trsh+1
+ */
unsignedrev1:1;
+ unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
};
@@ -310,6 +321,14 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
+ if (dev-fifo_size)
+ /* Note: setup required fifo size - 1 */
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG,
+ (dev-fifo_size - 1) 8 | /* RTRSH */
+ OMAP_I2C_BUF_RXFIF_CLR |
+ (dev-fifo_size - 1) | /* XTRSH */
+ OMAP_I2C_BUF_TXFIF_CLR);
+
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
@@ -317,7 +336,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
(OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL));
+ OMAP_I2C_IE_AL) | ((dev-fifo_size) ?
+ (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -364,6 +384,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
Re: [i2c] [PATCH 5/8] i2c-omap: Add support on 34xx
On Thu, Sep 25, 2008 at 10:53:51AM +0300, Tony Lindgren wrote:
From: Chandra shekhar [EMAIL PROTECTED]
Not very informative description in here. At lease you could have
copied the subject?
Signed-off-by: chandra shekhar [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ded4636..b41431a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -156,7 +156,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
{
- if (cpu_is_omap16xx() || cpu_is_omap24xx()) {
+ if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
dev-iclk = clk_get(dev-dev, i2c_ick);
if (IS_ERR(dev-iclk)) {
dev-iclk = NULL;
@@ -279,7 +279,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
- if (cpu_is_omap2430()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx()) {
/* HSI2C controller internal clk rate should be 19.2 Mhz */
internal_clk = 19200;
@@ -616,7 +616,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
*dev-buf++ = w;
dev-buf_len--;
/* Data reg from 2430 is 8 bit wide */
- if (!cpu_is_omap2430()) {
+ if (!cpu_is_omap2430()
+ !cpu_is_omap34xx()) {
if (dev-buf_len) {
*dev-buf++ = w 8;
dev-buf_len--;
@@ -654,7 +655,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
w = *dev-buf++;
dev-buf_len--;
/* Data reg from 2430 is 8 bit wide */
- if (!cpu_is_omap2430()) {
+ if (!cpu_is_omap2430()
+ !cpu_is_omap34xx()) {
if (dev-buf_len) {
w |= *dev-buf++ 8;
dev-buf_len--;
@@ -748,7 +750,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (cpu_is_omap15xx())
dev-rev1 = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0x20;
- if (cpu_is_omap2430()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx()) {
u16 s;
/* Set up the fifo size - Get total size */
--
1.5.6.rc3.21.g8c6b5
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 7/8] i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds
On Thu, Sep 25, 2008 at 10:53:53AM +0300, Tony Lindgren wrote:
From: Paul Walmsley [EMAIL PROTECTED]
Skip compiling OMAP15xx I2C ISR for non-OMAP15xx builds. Saves 400 bytes
of text for most OMAP builds.
you've sneaked in __devinit/__devexit changes into this patch,
I'm going to put my foot down on that.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e71f1f2..5c54864 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -511,6 +511,9 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
}
+/* rev1 devices are apparently only on some 15xx */
+#ifdef CONFIG_ARCH_OMAP15XX
+
static irqreturn_t
omap_i2c_rev1_isr(int this_irq, void *dev_id)
{
@@ -565,6 +568,9 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
return IRQ_HANDLED;
}
+#else
+#define omap_i2c_rev1_isr0
+#endif
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
@@ -843,14 +849,14 @@ static struct platform_driver omap_i2c_driver = {
};
/* I2C may be needed to bring up other drivers */
-static int __init
+static int __devinit
omap_i2c_init_driver(void)
{
return platform_driver_register(omap_i2c_driver);
}
subsys_initcall(omap_i2c_init_driver);
-static void __exit omap_i2c_exit_driver(void)
+static void __devexit omap_i2c_exit_driver(void)
a differerent change to the one advertised.
{
platform_driver_unregister(omap_i2c_driver);
}
--
1.5.6.rc3.21.g8c6b5
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 6/8] i2c-omap: Mark init-only functions as __init
On Thu, Sep 25, 2008 at 10:53:52AM +0300, Tony Lindgren wrote:
From: Paul Walmsley [EMAIL PROTECTED]
Mark functions called only at init time as __init.
surely these should be __devinit in case of hotplugged-ness?
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b41431a..e71f1f2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -154,7 +154,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
return __raw_readw(i2c_dev-base + reg);
}
-static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
+static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
{
if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
dev-iclk = clk_get(dev-dev, i2c_ick);
@@ -697,7 +697,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
-static int
+static int __init
omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
--
1.5.6.rc3.21.g8c6b5
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver
On Fri, Sep 19, 2008 at 10:03:54PM +0400, Anton Vorontsov wrote:
On MPC8349E-mITX, MPC8315E-RDB and MPC837x-RDB boards there is a
Freescale MC9S08QG8 (MCU) chip with the custom firmware
pre-programmed. The chip is used to power-off the board by the
software, and to control some GPIO pins.
I suppose there's no other place for this sort of thing to go at
the moment other than drivers/i2c/chips.
I've also a driver for a similar PMU fitted to a number
of our boards that provides basic gpio (wakeup sources) and some
minimalist power management (so isn't really fit for regulator
framwork) and isn't really a gpio chip (so drivers/gpio isn't
really the place for it either.)
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/i2c/chips/Kconfig| 11 ++
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/mcu_mpc8349emitx.c | 213
++
3 files changed, 225 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index a95cb94..1735682 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -172,4 +172,15 @@ config MENELAUS
and other features that are often used in portable devices like
cell phones and PDAs.
+config MCU_MPC8349EMITX
+ tristate MPC8349E-mITX MCU driver
+ depends on I2C PPC_83xx
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here to enable soft power-off functionality on the Freescale
+ boards with the MPC8349E-mITX-compatible MCU chips. This driver will
+ also register MCU GPIOs with the generic GPIO API, so you'll able
+ to use MCU pins as GPIOs.
+
endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 39e3e69..ca520fa 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TPS65010) += tps65010.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_SENSORS_TSL2550)+= tsl2550.o
+obj-$(CONFIG_MCU_MPC8349EMITX) += mcu_mpc8349emitx.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/i2c/chips/mcu_mpc8349emitx.c
b/drivers/i2c/chips/mcu_mpc8349emitx.c
new file mode 100644
index 000..47b07b8
--- /dev/null
+++ b/drivers/i2c/chips/mcu_mpc8349emitx.c
@@ -0,0 +1,213 @@
+/*
+ * Power Management and GPIO expander driver for MPC8349E-mITX-compatible MCU
+ *
+ * Copyright (c) 2008 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * 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 linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include asm/prom.h
+#include asm/machdep.h
+
+/*
+ * I don't have specifications for the MCU firmware, I found this register
+ * and bits positions by the trialerror method.
+ */
+#define MCU_REG_CTRL 0x20
+#define MCU_CTRL_POFF0x40
+
+#define MCU_NUM_GPIO 2
+
+struct mcu {
+ struct mutex lock;
+ struct device_node *np;
+ struct i2c_client *client;
+ struct of_gpio_chip of_gc;
+ u8 reg_ctrl;
+};
+
+static struct mcu *glob_mcu;
+
+static void mcu_power_off(void)
+{
+ struct mcu *mcu = glob_mcu;
+
+ pr_info(Sending power-off request to the MCU...\n);
+ mutex_lock(mcu-lock);
+ i2c_smbus_write_byte_data(glob_mcu-client, MCU_REG_CTRL,
+ mcu-reg_ctrl | MCU_CTRL_POFF);
+ mutex_unlock(mcu-lock);
+}
+
+static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_gpio_chip *of_gc = to_of_gpio_chip(gc);
+ struct mcu *mcu = container_of(of_gc, struct mcu, of_gc);
+ u8 bit = 1 (4 + gpio);
+
+ mutex_lock(mcu-lock);
+ if (val)
+ mcu-reg_ctrl = ~bit;
+ else
+ mcu-reg_ctrl |= bit;
+
+ i2c_smbus_write_byte_data(mcu-client, MCU_REG_CTRL, mcu-reg_ctrl);
+ mutex_unlock(mcu-lock);
+}
+
+static int mcu_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ mcu_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+static int mcu_gpiochip_add(struct mcu *mcu)
+{
+ struct device_node *np;
+ struct of_gpio_chip *of_gc = mcu-of_gc;
+ struct gpio_chip *gc = of_gc-gc;
+ int ret;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,mcu-mpc8349emitx);
+ if (!np)
+ return -ENODEV;
+
+ gc-owner = THIS_MODULE;
+
Re: [i2c] Supporting new features in I2C
On Fri, Sep 12, 2008 at 06:35:43AM -0700, vidhumouli hunsigida wrote: The I2C host controller chip has two features named HOLD and Slave Monitor. HOLD is the typical feature of holding the clock low to support for the slow devices. It can be enabled or disabled through software control by writing a bit in the registor. This should be normal behaviour for an i2c bus, some controllers can support it, but there is no need to add any extra functionality to the i2c layer for this. The driver is free to do it or not do it. If you want to driver to do either, then you can either have it as a module parameter and/or have some configuration file in sysfs to change the state. I am writing a bus driver for this core. I am not sure where and how this provision is to be added in the I2C adapter code. I could not find any such provision in the exising bus drivers. I could not find any related information in the Linux kernel documentation. Can any one give me how can this be done? Similarly for Slave Monitor, where a host monitors for the ack received from the slave device. This can also be enabled/disabled by setting a bit in the register. How is this to be handled in the current i2c adapter code? I suggest you have a look at the drivers in drivers/i2c/busses and also include/linux/i2c.h (pay particual attention to 'struct i2c_algorithm' which can be used to add new bus drivers). -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [RFC: 2.6 patch] remove the i2c-at91.c driver
On Mon, Sep 01, 2008 at 03:13:14PM +0200, Andrew Victor wrote: hi Adrian, David Brownell marked this driver as broken in kernel 2.6.24 due to hardware problems. If it depends on BROKEN it can as well be removed. This driver should be usable on the new AT91SAM9G20 processor. Atmel have supposidly resolved all the hardware issues that caused this driver to fail. Then would it be possible to have a patch to update the driver's help text, and possibly update the Kconfig to reflect the dependency on having working silicon? Would it be better to rename this driver? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [RFC: 2.6 patch] remove the i2c-at91.c driver
On Mon, Sep 01, 2008 at 03:13:14PM +0200, Andrew Victor wrote: hi Adrian, David Brownell marked this driver as broken in kernel 2.6.24 due to hardware problems. If it depends on BROKEN it can as well be removed. This driver should be usable on the new AT91SAM9G20 processor. Atmel have supposidly resolved all the hardware issues that caused this driver to fail. As a note, it would be worth filtering Adrian's patch to remove the hardware I2C support from the machines that cannot support it to avoid people falling into the trap of using a driver that is not going to function correctly? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [RFC] PXA3xx: Add support for power i2c bus
On Thu, Aug 14, 2008 at 02:38:09PM +0300, Mike Rapoport wrote:
Russell King - ARM Linux wrote:
On Thu, Aug 14, 2008 at 11:55:07AM +0300, Mike Rapoport wrote:
diff --git a/arch/arm/mach-pxa/generic.h b/arch/arm/mach-pxa/generic.h
index 041c048..13a786d 100644
--- a/arch/arm/mach-pxa/generic.h
+++ b/arch/arm/mach-pxa/generic.h
@@ -9,9 +9,10 @@
* published by the Free Software Foundation.
*/
-typedef int (*set_wake_t)(unsigned int, unsigned int);
+typedef int (*set_wake_t) (unsigned int, unsigned int);
Undoes perfectly good formatting.
@@ -982,10 +992,13 @@ static int i2c_pxa_probe(struct platform_device *dev)
snprintf(i2c-adap.name, sizeof(i2c-adap.name), pxa_i2c-i2c.%u,
i2c-adap.nr);
- i2c-clk = clk_get(dev-dev, I2CCLK);
- if (IS_ERR(i2c-clk)) {
- ret = PTR_ERR(i2c-clk);
- goto eclk;
+ /* PXA3xx has power I2C clock always on */
+ if (!(cpu_is_pxa3xx() i2c-adap.nr == 1)) {
+ i2c-clk = clk_get(dev-dev, I2CCLK);
+ if (IS_ERR(i2c-clk)) {
+ ret = PTR_ERR(i2c-clk);
+ goto eclk;
+ }
Umm, no. It would be far better to provide a dummy clock rather than
mess drivers up with this and lots of other conditional stuff.
Would that be better?
Signed-off-by: Mike Rapoport [EMAIL PROTECTED]
arch/arm/mach-pxa/devices.h |1 +
arch/arm/mach-pxa/include/mach/i2c.h |6 -
arch/arm/mach-pxa/pxa27x.c |2 +-
arch/arm/mach-pxa/pxa3xx.c | 45
++
drivers/i2c/busses/i2c-pxa.c | 20 +++
5 files changed, 67 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/devices.h b/arch/arm/mach-pxa/devices.h
index 887c738..bb04af4 100644
--- a/arch/arm/mach-pxa/devices.h
+++ b/arch/arm/mach-pxa/devices.h
@@ -32,5 +32,6 @@ extern struct platform_device pxa27x_device_pwm0;
extern struct platform_device pxa27x_device_pwm1;
extern struct platform_device pxa3xx_device_nand;
+extern struct platform_device pxa3xx_device_i2c_power;
void __init pxa_register_device(struct platform_device *dev, void *data);
diff --git a/arch/arm/mach-pxa/include/mach/i2c.h
b/arch/arm/mach-pxa/include/mach/i2c.h
index 80596b0..897e717 100644
--- a/arch/arm/mach-pxa/include/mach/i2c.h
+++ b/arch/arm/mach-pxa/include/mach/i2c.h
@@ -71,7 +71,11 @@ struct i2c_pxa_platform_data {
extern void pxa_set_i2c_info(struct i2c_pxa_platform_data *info);
#ifdef CONFIG_PXA27x
-extern void pxa_set_i2c_power_info(struct i2c_pxa_platform_data *info);
+extern void pxa27x_set_i2c_power_info(struct i2c_pxa_platform_data *info);
+#endif
+
+#ifdef CONFIG_PXA3xx
+extern void pxa3xx_set_i2c_power_info(struct i2c_pxa_platform_data *info);
#endif
#endif
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index f9f6a9c..c33cf6a 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -349,7 +349,7 @@ struct platform_device pxa27x_device_i2c_power = {
.num_resources = ARRAY_SIZE(i2c_power_resources),
};
-void __init pxa_set_i2c_power_info(struct i2c_pxa_platform_data *info)
+void __init pxa27x_set_i2c_power_info(struct i2c_pxa_platform_data *info)
{
local_irq_disable();
PCFR |= PCFR_PI2CEN;
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index 03cbc38..b3cd5d0 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -203,6 +203,19 @@ static const struct clkops clk_pout_ops = {
.disable= clk_pout_disable,
};
+static void clk_dummy_enable(struct clk *clk)
+{
+}
+
+static void clk_dummy_disable(struct clk *clk)
+{
+}
+
+static const struct clkops clk_dummy_ops = {
+ .enable = clk_dummy_enable,
+ .disable= clk_dummy_disable,
+};
+
static struct clk pxa3xx_clks[] = {
{
.name = CLK_POUT,
@@ -211,6 +224,13 @@ static struct clk pxa3xx_clks[] = {
.delay = 70,
},
+ /* Power I2C clock is always on */
+ {
+ .name = I2CCLK,
+ .ops= clk_dummy_ops,
+ .dev= pxa3xx_device_i2c_power.dev,
+ },
+
PXA3xx_CK(LCDCLK, LCD,clk_pxa3xx_hsio_ops, pxa_device_fb.dev),
PXA3xx_CK(CAMCLK, CAMERA, clk_pxa3xx_hsio_ops, NULL),
PXA3xx_CK(AC97CLK, AC97, clk_pxa3xx_ac97_ops, NULL),
@@ -509,6 +529,30 @@ void __init pxa3xx_init_irq(void)
* device registration specific to PXA3xx.
*/
+static struct resource i2c_power_resources[] = {
+ {
+ .start = 0x40f500c0,
+ .end= 0x40f500d3,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = IRQ_PWRI2C,
+ .end= IRQ_PWRI2C,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+struct platform_device pxa3xx_device_i2c_power = {
+
[i2c] FYI: Holiday from 2008-08-14 to 2008-08-20
I'll not be around from 2008-08-14 till 2008-08-20. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 04/05] i2c-sh_mobile: IORESOURCE_CLK support
On Fri, Jul 18, 2008 at 06:18:06PM +0900, Magnus Damm wrote:
On Fri, Jul 18, 2008 at 5:04 PM, Ben Dooks [EMAIL PROTECTED] wrote:
On Fri, Jul 18, 2008 at 04:40:36PM +0900, Magnus Damm wrote:
From: Magnus Damm [EMAIL PROTECTED]
This patch makes the i2c-sh_mobile driver get the clock name from the
struct resource with type IORESOURCE_CLK provided by the platform data.
Signed-off-by: Magnus Damm [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-sh_mobile.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- 0001/drivers/i2c/busses/i2c-sh_mobile.c
+++ work/drivers/i2c/busses/i2c-sh_mobile.c 2008-07-18
14:56:40.0 +0900
@@ -390,13 +390,19 @@ static int sh_mobile_i2c_probe(struct pl
int size;
int ret;
+ res = platform_get_resource(dev, IORESOURCE_CLK, 0);
+ if (res == NULL || res-name == NULL) {
+ dev_err(dev-dev, cannot find CLK resource\n);
+ return -ENOENT;
+ }
I note in this one you are re-using the resource.name field in the way
it was not intended to be used. This field is for use to differentiate
resources where this is more than one of them and they may not all be
present in the list. This is not a good course of action.
pd = kzalloc(sizeof(struct sh_mobile_i2c_data), GFP_KERNEL);
if (pd == NULL) {
dev_err(dev-dev, cannot allocate private data\n);
return -ENOMEM;
}
- pd-clk = clk_get(dev-dev, peripheral_clk);
I think that is working correctly and there isn't really any
need to change this. The clk_get is supplied the device that
it needs the clock for, and the name of the clock needed.
Right, we could handle this under the hood of the clock frame work
implementation, or we could deal with it together with the rest of the
platform data and have one unique string per hardware block. On SuperH
Mobile we currently have one shared clock implementation that supports
multiple processors. Which clock that is assigned to what hardware
block is currently handled by per-cpu platform data, and that's where
this patch comes in.
We have a shared implementation for the s3c24xx, which all have subtly
different clock requirements and we change the clock registration for
the chip, instead of trying to subvert the platform system. I do not
see this as being under the hood, changing resources at registration
time is done all over the place.
Techincally, if there is only one clock per block, then you don't
actually need a name, just supply the device that you are looking up
a clock for.
Note, added Russell King to the discussion, as he is the original
authour of the clock framework anyway.
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH V11] I2C driver for IMX
On Fri, Aug 08, 2008 at 11:51:16AM +0200, Jean Delvare wrote: On Wed, 23 Jul 2008 10:20:12 +0300, Darius wrote: Description: Implementation of I2C Adapter/Algorithm Driver for I2C Bus integrated in Freescale's i.MXL and i.MX1 processors Changes from V10 version: - adapter class changed to I2C_CLASS_ALL Not a smart move if you ask me. All embedded platforms are moving away from I2C probing and now use I2C device description at the platform level. I expect I2C_CLASS_ALL to be discarded in 2.6.28. Almost all hwmon and rtc drivers have been converted to the new I2C device driver matching scheme at this point, and the few remaining ones will definitely be converted for 2.6.28, hopefully with all the other legacy I2C drivers in the kernel tree. - changes regarding new IMX Clock API Signed-off-by: Darius Augulis [EMAIL PROTECTED] --- Ben, this driver has been through many iterations already. Maybe it's time for you to pick it up? Yes, I think it is pretty much ready. If a version without the changelog is submitted I will look at queueing it for the next merge window. -- Jean Delvare --- List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel FAQ:http://www.arm.linux.org.uk/mailinglists/faq.php Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] i2c-pxa: fix scheduling while atomic in i2c_pxa_abort()
On Tue, Aug 05, 2008 at 03:17:11PM +0400, Dmitry Baryshkov wrote:
i2c_pxa_abort can be called from the atomic context.
Change it to use mdelay and counted loop.
if this can be called from an atomic context, is there a distinct
possibility you are going to stop execution of the entire cpu for
the time it takes to sort this out? Is it possible to disable the
interrupt request, fire a work-struct to deal with this and then
re-enabled the controller once it is finished?
Signed-off-by: Dmitry Baryshkov [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-pxa.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index dde6ce9..9a0f788 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -188,14 +188,14 @@ static inline int i2c_pxa_is_slavemode(struct pxa_i2c
*i2c)
static void i2c_pxa_abort(struct pxa_i2c *i2c)
{
- unsigned long timeout = jiffies + HZ/4;
+ int i = 250;
if (i2c_pxa_is_slavemode(i2c)) {
dev_dbg(i2c-adap.dev, %s: called in slave mode\n, __func__);
return;
}
- while (time_before(jiffies, timeout) (readl(_IBMR(i2c)) 0x1) == 0)
{
+ while ((i 0) (readl(_IBMR(i2c)) 0x1) == 0) {
unsigned long icr = readl(_ICR(i2c));
icr = ~ICR_START;
@@ -205,7 +205,8 @@ static void i2c_pxa_abort(struct pxa_i2c *i2c)
show_state(i2c);
- msleep(1);
+ mdelay(1);
+ i --;
}
writel(readl(_ICR(i2c)) ~(ICR_MA | ICR_START | ICR_STOP),
--
1.5.6.3
--
With best wishes
Dmitry
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] i2c-pxa: fastmode support (with suggested fixes)
On Fri, Aug 01, 2008 at 11:08:15AM +0100, Jonathan Cameron wrote:
From: Jonathan Cameron [EMAIL PROTECTED]
Add fast_mode option to i2c_pxa_platform_data and use it to set the ICR_FM
bit appropriately when i2c_pxa_reset is called. Parameter called fast_mode
rather than frequency as this driver is also used for the i2c_pxa_pwr bus
which has different normal and fast frequencies.
this looks fine, the only problem is that we're still going
through some reorganisation of the ARM headers... given this
is really a new feature, I'm not going to apply it until closer
to the next release.
I may even have a look to see what the state of splitting pxa-regs
up further into something that might be more maintainable...
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
--
This is basically a repost of the original patch with use_pio and
fast_mode converted to bit fields as suggested / agreed by Eric Miao and
Ben Dooks.
drivers/i2c/busses/i2c-pxa.c|6 --
include/asm-arm/arch-pxa/i2c.h |3 ++-
include/asm-arm/arch-pxa/pxa-regs.h |1 +
3 files changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/i2c/busses/i2c-pxa.c2008-07-31 12:02:42.0 +0100
+++ b/drivers/i2c/busses/i2c-pxa.c2008-08-01 10:50:38.0 +0100
@@ -65,7 +65,8 @@ struct pxa_i2c {
unsigned long iosize;
int irq;
- int use_pio;
+ unsigned intuse_pio:1;
+ unsigned intfast_mode:1;
};
#define _IBMR(i2c) ((i2c)-reg_base + 0)
@@ -364,7 +365,7 @@ static void i2c_pxa_reset(struct pxa_i2c
writel(i2c-slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT, _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c-fast_mode ? ICR_FM : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(i2c-adap.dev, Enabling slave mode\n);
@@ -1013,6 +1014,7 @@ static int i2c_pxa_probe(struct platform
if (plat) {
i2c-adap.class = plat-class;
i2c-use_pio = plat-use_pio;
+ i2c-fast_mode = plat-fast_mode;
}
if (i2c-use_pio) {
--- a/include/asm-arm/arch-pxa/i2c.h 2008-07-31 12:00:05.0 +0100
+++ b/include/asm-arm/arch-pxa/i2c.h 2008-08-01 10:51:40.0 +0100
@@ -65,7 +65,8 @@ struct i2c_pxa_platform_data {
unsigned intslave_addr;
struct i2c_slave_client *slave;
unsigned intclass;
- int use_pio;
+ unsigned intuse_pio:1;
+ unsigned intfast_mode:1;
};
extern void pxa_set_i2c_info(struct i2c_pxa_platform_data *info);
--- a/include/asm-arm/arch-pxa/pxa-regs.h 2008-07-31 12:02:51.0
+0100
+++ b/include/asm-arm/arch-pxa/pxa-regs.h 2008-07-31 12:34:44.0
+0100
@@ -448,6 +448,7 @@
#define ICR_ALDIE(1 12) /* enable arbitration interrupt */
#define ICR_SADIE(1 13) /* slave address detected int enable
*/
#define ICR_UR (1 14) /* unit reset */
+#define ICR_FM (1 15) /* fast mode */
#define ISR_RWM (1 0) /* read/write mode */
#define ISR_ACKNAK (1 1) /* ack/nak status */
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] i2c-pxa: fastmode support
On Thu, Jul 31, 2008 at 04:56:53PM +0100, Jonathan Cameron wrote:
From: Jonathan Cameron [EMAIL PROTECTED]
Add fast_mode option to i2c_pxa_platform_data and use it to set the ICR_FM bit
appropriately when i2c_pxa_reset is called. Parameter called fast_mode rather
than frequency as this driver is also used for the i2c_pxa_pwr bus which has
different normal and fast frequencies.
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
--
This is basically a repost of the original patch with use_pio and fast_mode
converted
to bit fields as suggested / agreed by Eric Miao and Ben Dooks.
please ensure your descriptions are wrapped to less than 77 characters
per line.
Patch is against 2.6.27-rc1
drivers/i2c/busses/i2c-pxa.c|6 --
include/asm-arm/arch-pxa/i2c.h |3 ++-
include/asm-arm/arch-pxa/pxa-regs.h |1 +
3 files changed, 7 insertions(+), 3 deletions(-)
diff -uprN -X a/Documentation/dontdiff a/include/asm-arm/arch-pxa/pxa-regs.h
b/include/asm-arm/arch-pxa/pxa-regs.h
--- a/include/asm-arm/arch-pxa/pxa-regs.h 2008-07-31 12:02:51.0
+0100
+++ b/include/asm-arm/arch-pxa/pxa-regs.h 2008-07-31 12:34:44.0
+0100
@@ -448,6 +448,7 @@
#define ICR_ALDIE(1 12) /* enable arbitration interrupt */
#define ICR_SADIE(1 13) /* slave address detected int enable
*/
#define ICR_UR (1 14) /* unit reset */
+#define ICR_FM (1 15) /* fast mode */
#define ISR_RWM (1 0) /* read/write mode */
#define ISR_ACKNAK (1 1) /* ack/nak status */
diff -uprN -X a/Documentation/dontdiff a/include/asm-arm/arch-pxa/i2c.h
b/include/asm-arm/arch-pxa/i2c.h
--- a/include/asm-arm/arch-pxa/i2c.h 2008-07-31 12:00:05.0 +0100
+++ b/include/asm-arm/arch-pxa/i2c.h 2008-07-31 16:01:28.0 +0100
@@ -65,7 +65,8 @@ struct i2c_pxa_platform_data {
unsigned intslave_addr;
struct i2c_slave_client *slave;
unsigned intclass;
- int use_pio;
+ int use_pio:1;
+ int fast_mode:1;
};
extern void pxa_set_i2c_info(struct i2c_pxa_platform_data *info);
diff -uprN -X a/Documentation/dontdiff a/drivers/i2c/busses/i2c-pxa.c
b/drivers/i2c/busses/i2c-pxa.c
--- a/drivers/i2c/busses/i2c-pxa.c2008-07-31 12:02:42.0 +0100
+++ b/drivers/i2c/busses/i2c-pxa.c2008-07-31 16:10:43.0 +0100
@@ -65,7 +65,8 @@ struct pxa_i2c {
unsigned long iosize;
int irq;
- int use_pio;
+ int use_pio:1;
+ int fast_mode:1;
};
Please use unsigned int for bitfields, and a space between the
name and the :1 would be nice.
#define _IBMR(i2c) ((i2c)-reg_base + 0)
@@ -364,7 +365,7 @@ static void i2c_pxa_reset(struct pxa_i2c
writel(i2c-slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT, _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c-fast_mode ? ICR_FM : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(i2c-adap.dev, Enabling slave mode\n);
@@ -1013,6 +1014,7 @@ static int i2c_pxa_probe(struct platform
if (plat) {
i2c-adap.class = plat-class;
i2c-use_pio = plat-use_pio;
+ i2c-fast_mode = plat-fast_mode;
}
if (i2c-use_pio) {
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 1/1] Blackfin I2C Driver: Functional power management support
On Sun, Jul 27, 2008 at 02:41:54PM +0800, Bryan Wu wrote:
From: Michael Hennerich [EMAIL PROTECTED]
PM_SUSPEND_MEM: Blackfin does not maintain register state through
Hibernate. Save and restore peripheral base initialization during
PM transitions.
Signed-off-by: Michael Hennerich [EMAIL PROTECTED]
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-bfin-twi.c | 35 ---
1 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bfin-twi.c
b/drivers/i2c/busses/i2c-bfin-twi.c
index 48d084b..3c855ff 100644
--- a/drivers/i2c/busses/i2c-bfin-twi.c
+++ b/drivers/i2c/busses/i2c-bfin-twi.c
@@ -49,6 +49,8 @@ struct bfin_twi_iface {
struct i2c_msg *pmsg;
int msg_num;
int cur_msg;
+ u16 saved_clkdiv;
+ u16 saved_control;
void __iomem*regs_base;
};
@@ -565,32 +567,43 @@ static u32 bfin_twi_functionality(struct i2c_adapter
*adap)
I2C_FUNC_I2C;
}
-
static struct i2c_algorithm bfin_twi_algorithm = {
.master_xfer = bfin_twi_master_xfer,
.smbus_xfer= bfin_twi_smbus_xfer,
.functionality = bfin_twi_functionality,
};
-
-static int i2c_bfin_twi_suspend(struct platform_device *dev, pm_message_t
state)
+static int i2c_bfin_twi_suspend(struct platform_device *pdev, pm_message_t
state)
{
- struct bfin_twi_iface *iface = platform_get_drvdata(dev);
+ struct bfin_twi_iface *iface = platform_get_drvdata(pdev);
+
+ iface-saved_clkdiv = read_CLKDIV(iface);
+ iface-saved_control = read_CONTROL(iface);
+
+ free_irq(iface-irq, iface);
/* Disable TWI */
- write_CONTROL(iface, read_CONTROL(iface) ~TWI_ENA);
- SSYNC();
+ write_CONTROL(iface, iface-saved_control ~TWI_ENA);
I assume removing the SSYNC() call is valid?
return 0;
}
-static int i2c_bfin_twi_resume(struct platform_device *dev)
+static int i2c_bfin_twi_resume(struct platform_device *pdev)
{
- struct bfin_twi_iface *iface = platform_get_drvdata(dev);
+ struct bfin_twi_iface *iface = platform_get_drvdata(pdev);
- /* Enable TWI */
- write_CONTROL(iface, read_CONTROL(iface) | TWI_ENA);
- SSYNC();
+ int rc = request_irq(iface-irq, bfin_twi_interrupt_entry,
+ IRQF_DISABLED, pdev-name, iface);
+ if (rc) {
+ dev_err(pdev-dev, Can't get IRQ %d !\n, iface-irq);
+ return -ENODEV;
+ }
+
+ /* Resume TWI interface clock as specified */
+ write_CLKDIV(iface, iface-saved_clkdiv);
+
+ /* Resume TWI */
+ write_CONTROL(iface, iface-saved_control);
return 0;
}
--
1.5.6
if removing the SSYNC() call is ok, then I'll queue this into
my tree which I will be requesting a pull asap.
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 1/1] Blackfin I2C Driver: Functional power management support
On Mon, Jul 28, 2008 at 06:07:28PM +0800, Bryan Wu wrote:
On Mon, Jul 28, 2008 at 5:23 PM, Ben Dooks [EMAIL PROTECTED] wrote:
On Sun, Jul 27, 2008 at 02:41:54PM +0800, Bryan Wu wrote:
From: Michael Hennerich [EMAIL PROTECTED]
PM_SUSPEND_MEM: Blackfin does not maintain register state through
Hibernate. Save and restore peripheral base initialization during
PM transitions.
Signed-off-by: Michael Hennerich [EMAIL PROTECTED]
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-bfin-twi.c | 35
---
1 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bfin-twi.c
b/drivers/i2c/busses/i2c-bfin-twi.c
index 48d084b..3c855ff 100644
--- a/drivers/i2c/busses/i2c-bfin-twi.c
+++ b/drivers/i2c/busses/i2c-bfin-twi.c
@@ -49,6 +49,8 @@ struct bfin_twi_iface {
struct i2c_msg *pmsg;
int msg_num;
int cur_msg;
+ u16 saved_clkdiv;
+ u16 saved_control;
void __iomem*regs_base;
};
@@ -565,32 +567,43 @@ static u32 bfin_twi_functionality(struct i2c_adapter
*adap)
I2C_FUNC_I2C;
}
-
static struct i2c_algorithm bfin_twi_algorithm = {
.master_xfer = bfin_twi_master_xfer,
.smbus_xfer= bfin_twi_smbus_xfer,
.functionality = bfin_twi_functionality,
};
-
-static int i2c_bfin_twi_suspend(struct platform_device *dev, pm_message_t
state)
+static int i2c_bfin_twi_suspend(struct platform_device *pdev,
pm_message_t state)
{
- struct bfin_twi_iface *iface = platform_get_drvdata(dev);
+ struct bfin_twi_iface *iface = platform_get_drvdata(pdev);
+
+ iface-saved_clkdiv = read_CLKDIV(iface);
+ iface-saved_control = read_CONTROL(iface);
+
+ free_irq(iface-irq, iface);
/* Disable TWI */
- write_CONTROL(iface, read_CONTROL(iface) ~TWI_ENA);
- SSYNC();
+ write_CONTROL(iface, iface-saved_control ~TWI_ENA);
I assume removing the SSYNC() call is valid?
Yes, I think it is OK for that. We tested on our platform.
Actually, keeping the SSYNC() is not a big deal for this driver.
How do you think Michael?
return 0;
}
-static int i2c_bfin_twi_resume(struct platform_device *dev)
+static int i2c_bfin_twi_resume(struct platform_device *pdev)
{
- struct bfin_twi_iface *iface = platform_get_drvdata(dev);
+ struct bfin_twi_iface *iface = platform_get_drvdata(pdev);
- /* Enable TWI */
- write_CONTROL(iface, read_CONTROL(iface) | TWI_ENA);
- SSYNC();
+ int rc = request_irq(iface-irq, bfin_twi_interrupt_entry,
+ IRQF_DISABLED, pdev-name, iface);
+ if (rc) {
+ dev_err(pdev-dev, Can't get IRQ %d !\n, iface-irq);
+ return -ENODEV;
+ }
+
+ /* Resume TWI interface clock as specified */
+ write_CLKDIV(iface, iface-saved_clkdiv);
+
+ /* Resume TWI */
+ write_CONTROL(iface, iface-saved_control);
return 0;
}
--
1.5.6
if removing the SSYNC() call is ok, then I'll queue this into
my tree which I will be requesting a pull asap.
ok, this is in my queue, unless anyone objects then it'll be pushed
out later today.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] What is in bjdooks' git
The following changes since commit c9272c4f9fbe2087beb3392f526dc5b19efaa56b:
Linus Torvalds (1):
Merge branch 'hotfixes' of
git://git.linux-nfs.org/projects/trondmy/nfs-2.6
are available in the git repository at:
git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-for-linus
Ben Dooks (4):
i2c: S3C2410: Pass the I2C bus number via drivers platform data
i2c: i2c_gpio: keep probe resident for hotplugged devices.
i2c: S3C24XX I2C frequency scaling support.
i2c: Documentation: upgrading clients HOWTO
Michael Hennerich (1):
i2c: Blackfin I2C Driver: Functional power management support
Documentation/i2c/upgrading-clients | 281 +++
drivers/i2c/busses/i2c-bfin-twi.c | 35 +++--
drivers/i2c/busses/i2c-gpio.c |9 +-
drivers/i2c/busses/i2c-s3c2410.c| 129 ++--
include/asm-arm/plat-s3c/iic.h |1 +
5 files changed, 426 insertions(+), 29 deletions(-)
create mode 100644 Documentation/i2c/upgrading-clients
diff --git a/Documentation/i2c/upgrading-clients
b/Documentation/i2c/upgrading-clients
new file mode 100644
index 000..9a45f9b
--- /dev/null
+++ b/Documentation/i2c/upgrading-clients
@@ -0,0 +1,281 @@
+Upgrading I2C Drivers to the new 2.6 Driver Model
+=
+
+Ben Dooks [EMAIL PROTECTED]
+
+Introduction
+
+
+This guide outlines how to alter existing Linux 2.6 client drivers from
+the old to the new new binding methods.
+
+
+Example old-style driver
+
+
+
+struct example_state {
+ struct i2c_client client;
+
+};
+
+static struct i2c_driver example_driver;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+static int example_attach(struct i2c_adapter *adap, int addr, int kind)
+{
+ struct example_state *state;
+ struct device *dev = adap-dev; /* to use for dev_ reports */
+ int ret;
+
+ state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
+ if (state == NULL) {
+ dev_err(dev, failed to create our state\n);
+ return -ENOMEM;
+ }
+
+ example-client.addr= addr;
+ example-client.flags = 0;
+ example-client.adapter = adap;
+
+ i2c_set_clientdata(state-i2c_client, state);
+ strlcpy(client-i2c_client.name, example, I2C_NAME_SIZE);
+
+ ret = i2c_attach_client(state-i2c_client);
+ if (ret 0) {
+ dev_err(dev, failed to attach client\n);
+ kfree(state);
+ return ret;
+ }
+
+ dev = state-i2c_client.dev;
+
+ /* rest of the initialisation goes here. */
+
+ dev_info(dev, example client created\n);
+
+ return 0;
+}
+
+static int __devexit example_detach(struct i2c_client *client)
+{
+ struct example_state *state = i2c_get_clientdata(client);
+
+ i2c_detach_client(client);
+ kfree(state);
+ return 0;
+}
+
+static int example_attach_adapter(struct i2c_adapter *adap)
+{
+ return i2c_probe(adap, addr_data, example_attach);
+}
+
+static struct i2c_driver example_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = example,
+ },
+ .attach_adapter = example_attach_adapter,
+ .detach_client = __devexit_p(example_detach),
+ .suspend= example_suspend,
+ .resume = example_resume,
+};
+
+
+Updating the client
+---
+
+The new style binding model will check against a list of supported
+devices and their associated address supplied by the code registering
+the busses. This means that the driver .attach_adapter and
+.detach_adapter methods can be removed, along with the addr_data,
+as follows:
+
+- static struct i2c_driver example_driver;
+
+- static unsigned short ignore[] = { I2C_CLIENT_END };
+- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
+
+- I2C_CLIENT_INSMOD;
+
+- static int example_attach_adapter(struct i2c_adapter *adap)
+- {
+- return i2c_probe(adap, addr_data, example_attach);
+- }
+
+ static struct i2c_driver example_driver = {
+- .attach_adapter = example_attach_adapter,
+- .detach_client = __devexit_p(example_detach),
+ }
+
+Add the probe and remove methods to the i2c_driver, as so:
+
+ static struct i2c_driver example_driver = {
++ .probe = example_probe,
++ .remove = __devexit_p(example_remove),
+ }
+
+Change the example_attach method to accept the new parameters
+which include the i2c_client that it will be working with:
+
+- static int example_attach(struct i2c_adapter *adap, int addr, int kind)
++ static int example_probe(struct i2c_client *client,
++ const struct i2c_device_id *id)
+
+Change the name of example_attach to example_probe to align it with the
+i2c_driver entry names
Re: [i2c] [PATCH 1/1] Blackfin I2C Driver: Functional power management support
On Mon, Jul 28, 2008 at 01:16:44PM +0100, Hennerich, Michael wrote: if removing the SSYNC() call is ok, then I'll queue this into my tree which I will be requesting a pull asap. ok, this is in my queue, unless anyone objects then it'll be pushed out later today. Removing this SSYNC is absolutely safe. There are potentially many other ones that can be removed too. Ok, next time a note to this effect in the description would be useful to inform everyone that you've not just accidentally removed something the driver might rely on having. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] (no subject)
The following changes since commit c9272c4f9fbe2087beb3392f526dc5b19efaa56b: Linus Torvalds (1): Merge branch 'hotfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6 are available in the git repository at: git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-for-linus Ben Dooks (4): i2c: S3C2410: Pass the I2C bus number via drivers platform data i2c: i2c_gpio: keep probe resident for hotplugged devices. i2c: S3C24XX I2C frequency scaling support. i2c: Documentation: upgrading clients HOWTO Michael Hennerich (1): i2c: Blackfin I2C Driver: Functional power management support Documentation/i2c/upgrading-clients | 281 +++ drivers/i2c/busses/i2c-bfin-twi.c | 35 +++-- drivers/i2c/busses/i2c-gpio.c |9 +- drivers/i2c/busses/i2c-s3c2410.c| 129 ++-- include/asm-arm/plat-s3c/iic.h |1 + 5 files changed, 426 insertions(+), 29 deletions(-) create mode 100644 Documentation/i2c/upgrading-clients ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] Please pull bjdooks' i2c tree
The following changes since commit c9272c4f9fbe2087beb3392f526dc5b19efaa56b: Linus Torvalds (1): Merge branch 'hotfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6 are available in the git repository at: git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-for-linus Ben Dooks (4): i2c: S3C2410: Pass the I2C bus number via drivers platform data i2c: i2c_gpio: keep probe resident for hotplugged devices. i2c: S3C24XX I2C frequency scaling support. i2c: Documentation: upgrading clients HOWTO Michael Hennerich (1): i2c: Blackfin I2C Driver: Functional power management support Documentation/i2c/upgrading-clients | 281 +++ drivers/i2c/busses/i2c-bfin-twi.c | 35 +++-- drivers/i2c/busses/i2c-gpio.c |9 +- drivers/i2c/busses/i2c-s3c2410.c| 129 ++-- include/asm-arm/plat-s3c/iic.h |1 + 5 files changed, 426 insertions(+), 29 deletions(-) create mode 100644 Documentation/i2c/upgrading-clients ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH V10] I2C driver for IMX
On Fri, Jul 18, 2008 at 09:56:45AM +0300, Darius wrote:
Description:
Implementation of I2C Adapter/Algorithm Driver
for I2C Bus integrated in Freescale's i.MXL and i.MX1 processors
Changes from V9 version:
- platform_driver_register replaced by platform_driver_probe because I2C is
non-hotpluggable device
- Patch divided into two separate patches for I2C driver and for board
support for I2C device
- In I2C wait functions dummy cycles replaced by calling shedule();
- Fixed coding style errors
This driver is not yet compatible with upcomming Clock API for i.MX.
I'll implement this after 2.6.27-rc1 release.
Signed-off-by: Darius Augulis [EMAIL PROTECTED]
---
ok, clean up the description and i'll try and include it before
the end of the merge window.
Index: linux-2.6.26/drivers/i2c/busses/i2c-imx.c
===
--- /dev/null
+++ linux-2.6.26/drivers/i2c/busses/i2c-imx.c
@@ -0,0 +1,617 @@
+/*
+ * Copyright (C) 2002 Motorola GSG-China
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ *
+ * Author:
+ * Darius Augulis, Teltonika Inc.
+ *
+ * Desc.:
+ * Implementation of I2C Adapter/Algorithm Driver
+ * for I2C Bus integrated in i.MXL, i.MX1
+ *
+ * module parameters:
+ * - clkfreq:
+ * Sets the desired clock rate
+ * The default value is 10
+ * Max value is 40
+ *
+ * Derived from Motorola GSG China I2C example driver
+ *
+ * Copyright (C) 2005 Torsten Koschorrek koschorrek at synertronixx.de
+ * Portions:
+ * Copyright (C) 2005 Matthias Blaschke blaschke at synertronixx.de
+ * Copyright (C) 2007 RightHand Technologies, Inc.
adyeratrighthandtech.com
+ * Copyright (C) 2008 Darius Augulis darius.augulis at teltonika.lt
+ *
+ */
+
+/** Includes
***
+***/
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/io.h
+#include linux/sched.h
+#include linux/platform_device.h
+#include asm/arch/irqs.h
+#include asm/arch/hardware.h
+#include asm/arch/imx-regs.h
+
+/** Defines
+***/
+
+/* This will be the driver name the kernel reports */
+#define DRIVER_NAME imx-i2c
+
+/* Default values of module parameters */
+#define IMX_I2C_BIT_RATE 10 /* 100kHz */
+
+/* Timeouts */
+#define I2C_IMX_TIME_BUSY2000/* loop count */
+#define I2C_IMX_TIME_ACK 2000/* loop count */
+#define I2C_IMX_TIME_TRX 5 /* seconds */
+
+/* IMX I2C registers */
+#define IMX_I2C_IADR 0x00/* i2c slave address */
+#define IMX_I2C_IFDR 0x04/* i2c frequency divider */
+#define IMX_I2C_I2CR 0x08/* i2c control */
+#define IMX_I2C_I2SR 0x0C/* i2c status */
+#define IMX_I2C_I2DR 0x10/* i2c transfer data */
+
+/* Bits of IMX I2C registers */
+#define I2SR_RXAK0x01
+#define I2SR_IIF 0x02
+#define I2SR_SRW 0x04
+#define I2SR_IAL 0x10
+#define I2SR_IBB 0x20
+#define I2SR_IAAS0x40
+#define I2SR_ICF 0x80
+#define I2CR_RSTA0x04
+#define I2CR_TXAK0x08
+#define I2CR_MTX 0x10
+#define I2CR_MSTA0x20
+#define I2CR_IIEN0x40
+#define I2CR_IEN 0x80
+
+/** Variables
**
+***/
+
+static unsigned int clkfreq = IMX_I2C_BIT_RATE;
+static unsigned int disable_delay; /* Dummy delay */
+
+/*
+ * sorted list of clock divider, register value pairs
+ * taken from table 26-5, p.26-9, Freescale i.MX
+ * Integrated Portable System Processor Reference Manual
+ * Document Number: MC9328MXLRM, Rev. 5.1, 06/2007
+ *
+ * Duplicated divider values removed from list
+ */
+
+static u16 __initdata i2c_imx_clk_divider [50] [2] = {
+ { 22, 0x20 }, { 24,
Re: [i2c] [PATCH 01/05] resource: add resource_size()
On Fri, Jul 18, 2008 at 04:40:10PM +0900, Magnus Damm wrote:
From: Magnus Damm [EMAIL PROTECTED]
Avoid one-off errors by introducing a resource_size() function.
Signed-off-by: Magnus Damm [EMAIL PROTECTED]
A resource_size definition is a good idea, given the number of
times it has been re-implemented throughout the kernel.
---
include/linux/ioport.h |4
kernel/resource.c |2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
--- 0001/include/linux/ioport.h
+++ work/include/linux/ioport.h 2008-07-09 12:59:04.0 +0900
@@ -113,6 +113,10 @@ extern int allocate_resource(struct reso
int adjust_resource(struct resource *res, resource_size_t start,
resource_size_t size);
resource_size_t resource_alignment(struct resource *res);
+static inline resource_size_t resource_size(struct resource *res)
+{
+ return res-end - res-start + 1;
+}
/* Convenience shorthand with allocation */
#define request_region(start,n,name) __request_region(ioport_resource,
(start), (n), (name))
--- 0001/kernel/resource.c
+++ work/kernel/resource.c2008-07-09 12:59:41.0 +0900
@@ -490,7 +490,7 @@ resource_size_t resource_alignment(struc
{
switch (res-flags (IORESOURCE_SIZEALIGN | IORESOURCE_STARTALIGN)) {
case IORESOURCE_SIZEALIGN:
- return res-end - res-start + 1;
+ return resource_size(res);
case IORESOURCE_STARTALIGN:
return res-start;
default:
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 02/05] resource: add resource_type() and IORESOURCE_TYPE_BITS
On Fri, Jul 18, 2008 at 04:40:18PM +0900, Magnus Damm wrote:
From: Magnus Damm [EMAIL PROTECTED]
This patch adds resource_type() and IORESOURCE_TYPE_BITS. They make it
easier to add more resource types without having to rewrite tons of code.
This looks ok to me, with one concern as shown below.
Signed-off-by: Magnus Damm [EMAIL PROTECTED]
---
drivers/base/platform.c | 31 +--
include/linux/ioport.h |7 ++-
2 files changed, 23 insertions(+), 15 deletions(-)
--- 0001/drivers/base/platform.c
+++ work/drivers/base/platform.c 2008-07-09 20:19:16.0 +0900
@@ -42,10 +42,8 @@ struct resource *platform_get_resource(s
for (i = 0; i dev-num_resources; i++) {
struct resource *r = dev-resource[i];
- if ((r-flags (IORESOURCE_IO|IORESOURCE_MEM|
- IORESOURCE_IRQ|IORESOURCE_DMA)) == type)
- if (num-- == 0)
- return r;
+ if (type == resource_type(r) num-- == 0)
+ return r;
}
return NULL;
}
@@ -78,10 +76,8 @@ struct resource *platform_get_resource_b
for (i = 0; i dev-num_resources; i++) {
struct resource *r = dev-resource[i];
- if ((r-flags (IORESOURCE_IO|IORESOURCE_MEM|
- IORESOURCE_IRQ|IORESOURCE_DMA)) == type)
- if (!strcmp(r-name, name))
- return r;
+ if (type == resource_type(r) !strcmp(r-name, name))
+ return r;
}
return NULL;
}
@@ -259,9 +255,9 @@ int platform_device_add(struct platform_
p = r-parent;
if (!p) {
- if (r-flags IORESOURCE_MEM)
+ if (resource_type(r) == IORESOURCE_MEM)
p = iomem_resource;
- else if (r-flags IORESOURCE_IO)
+ else if (resource_type(r) == IORESOURCE_IO)
p = ioport_resource;
}
You are changing a simple test to a mask and compare, is anyone going
to produce resources with an IORESOURCE_MEM and an IORESOURCE_IO
together?
@@ -282,9 +278,14 @@ int platform_device_add(struct platform_
return ret;
failed:
- while (--i = 0)
- if (pdev-resource[i].flags (IORESOURCE_MEM|IORESOURCE_IO))
- release_resource(pdev-resource[i]);
+ while (--i = 0) {
+ struct resource *r = pdev-resource[i];
+ unsigned long type = resource_type(r);
+
+ if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
+ release_resource(r);
+ }
+
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -306,7 +307,9 @@ void platform_device_del(struct platform
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
- if (r-flags (IORESOURCE_MEM|IORESOURCE_IO))
+ unsigned long type = resource_type(r);
+
+ if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
release_resource(r);
}
}
--- 0002/include/linux/ioport.h
+++ work/include/linux/ioport.h 2008-07-09 15:16:48.0 +0900
@@ -34,7 +34,8 @@ struct resource_list {
*/
#define IORESOURCE_BITS 0x00ff /* Bus-specific bits */
-#define IORESOURCE_IO0x0100 /* Resource type */
+#define IORESOURCE_TYPE_BITS 0x0f00 /* Resource type */
+#define IORESOURCE_IO0x0100
#define IORESOURCE_MEM 0x0200
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
@@ -117,6 +118,10 @@ static inline resource_size_t resource_s
{
return res-end - res-start + 1;
}
+static inline unsigned long resource_type(struct resource *res)
+{
+ return res-flags IORESOURCE_TYPE_BITS;
+}
/* Convenience shorthand with allocation */
#define request_region(start,n,name) __request_region(ioport_resource,
(start), (n), (name))
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 02/05] resource: add resource_type() and IORESOURCE_TYPE_BITS
On Fri, Jul 18, 2008 at 05:24:59PM +0900, Magnus Damm wrote: On Fri, Jul 18, 2008 at 4:56 PM, Ben Dooks [EMAIL PROTECTED] wrote: You are changing a simple test to a mask and compare, is anyone going to produce resources with an IORESOURCE_MEM and an IORESOURCE_IO together? Actually, I'd like to replace the one-bit-per-type strategy with a N-bit counter. But that is not very compatible with the case you are pointing out. I'm not sure if that's a combination we really want to support though. Both IRQ and DMA doesn't make much sense to me. =) I'm not saying it is a bad idea, I just do not know if anyone is currently relying on this to work... -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Access 16bits address register in a device through I2C
On Fri, Jul 18, 2008 at 12:13:30AM +0800, Wen Wang wrote: Hi all, I have a problem writing an I2C device driver and would greatly appreciate if someone could provide some enlightenment. I'm working on a project needs to access registers with 16bits address through I2C. But unfortunately I can not find a way to achieve this, cause it seems that current kernel I2C framework only supports 8bits address register. The easiest way is to create a function that uses a pair of i2c messages, the first message sends the 16bits of address pointer to the device, the second one either reads or writes data. So I'm wondering do I miss something or what can I do? Any ideas? Thanks Wen ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [patch 1/1] i2c_gpio: keep probe resident for hotplugged devices.
On Sat, Jul 12, 2008 at 09:06:00AM +0200, Jean Delvare wrote: Ben, On Thu, 10 Jul 2008 14:29:17 +0100, Ben Dooks wrote: On Wed, Jul 02, 2008 at 12:44:06PM +0200, Haavard Skinnemoen wrote: Ben Dooks [EMAIL PROTECTED] wrote: Change the i2c_gpio driver to use platform_driver_register() instead of platform_driver_probe() to ensure that is can attach to any devices that may be loaded after it has initialised. Does anyone actually do that? At the moment our standard kernel configuration only builds in the SM501 which will work without this patch on. However, we have clients that do build module kernels and I would like to replace i2c-simtec.c with the gpio driver and if the relevant module instantiating the gpio support is loaded post kernel init, then we will need to do this. Should I take this patch in my i2c tree, or will you take it in yours? I'll take it, I was just waiting to see if there where any more objections from Haavard before applying this. If i've not received an objection by 0900GMT 2008-07-16 then I will add it to my rather small git tree and ask linus to pull. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] i2c: Documentation: upgrading clients HOWTO
Add a document describing how i2c clients on Linux 2.6 can be
moved from the old to the new driver model.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-quilt2/Documentation/i2c/upgrading-clients
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.26-quilt2/Documentation/i2c/upgrading-clients 2008-07-15
16:51:11.0 +0100
@@ -0,0 +1,280 @@
+Upgrading I2C Drivers to the new 2.6 Driver Model
+=
+
+Ben Dooks [EMAIL PROTECTED]
+
+Introduction
+
+
+This guide outlines how to alter existing Linux 2.6 client drivers from
+the old to the new new binding methods.
+
+
+Example old-style driver
+
+
+
+struct example_state {
+ struct i2c_client client;
+
+};
+
+static struct i2c_driver example_driver;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+static int example_attach(struct i2c_adapter *adap, int addr, int kind)
+{
+ struct example_state *state;
+ struct device *dev = adap-dev; /* to use for dev_ reports */
+ int ret;
+
+ state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
+ if (state == NULL) {
+ dev_err(dev, failed to create our state\n);
+ return -ENOMEM;
+ }
+
+ example-client.addr= addr;
+ example-client.flags = 0;
+ example-client.adapter = adap;
+
+ i2c_set_clientdata(state-i2c_client, state);
+ strlcpy(client-i2c_client.name, example, I2C_NAME_SIZE);
+
+ ret = i2c_attach_client(state-i2c_client);
+ if (ret 0) {
+ dev_err(dev, failed to attach client\n);
+ kfree(state);
+ return ret;
+ }
+
+ dev = state-i2c_client.dev;
+
+ /* rest of the initialisation goes here. */
+
+ dev_info(dev, example client created\n);
+
+ return 0;
+}
+
+static int example_detach(struct i2c_client *client)
+{
+ struct example_state *state = i2c_get_clientdata(client);
+
+ i2c_detach_client(client);
+ kfree(state);
+ return 0;
+}
+
+static int example_attach_adapter(struct i2c_adapter *adap)
+{
+ return i2c_probe(adap, addr_data, example_attach);
+}
+
+static struct i2c_driver example_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = example,
+ },
+ .attach_adapter = example_attach_adapter,
+ .detach_client = example_detach,
+ .suspend= example_suspend,
+ .resume = example_resume,
+};
+
+
+Updating the client
+---
+
+The new style binding model will check against a list of supported
+devices and their associated address supplied by the code registering
+the busses. This means that the driver .attach_adapter and
+.detach_adapter methods can be removed, along with the addr_data,
+as follows:
+
+- static struct i2c_driver example_driver;
+
+- static unsigned short ignore[] = { I2C_CLIENT_END };
+- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
+
+- I2C_CLIENT_INSMOD;
+
+- static int example_attach_adapter(struct i2c_adapter *adap)
+- {
+- return i2c_probe(adap, addr_data, example_attach);
+- }
+
+ static struct i2c_driver example_driver = {
+- .attach_adapter = example_attach_adapter,
+- .detach_client = example_detach,
+ }
+
+Add the probe and remove methods to the i2c_driver, as so:
+
+ static struct i2c_driver example_driver = {
++ .probe = example_probe,
++ .remove = example_remove,
+ }
+
+Change the example_attach method to accept the new parameters
+which include the i2c_client that it will be working with:
+
+- static int example_attach(struct i2c_adapter *adap, int addr, int kind)
++ static int example_probe(struct i2c_client *client,
++ const struct i2c_device_id *id)
+
+Change the name of example_attach to example_probe to align it with the
+i2c_driver entry names. The rest of the probe routine will now need to be
+changed as the i2c_client has already been setup for use.
+
+The necessary client fields have already been setup before
+the probe function is called, so the following client setup
+can be removed:
+
+- example-client.addr= addr;
+- example-client.flags = 0;
+- example-client.adapter = adap;
+-
+- strlcpy(client-i2c_client.name, example, I2C_NAME_SIZE);
+
+The i2c_set_clientdata is now:
+
+- i2c_set_clientdata(state-client, state);
++ i2c_set_clientdata(client, state);
+
+The call to i2c_attach_client is no longer needed, if the probe
+routine exits successfully, then the driver will be automatically
+attached by the core. Change the probe routine as so:
+
+- ret = i2c_attach_client(state-i2c_client);
+- if (ret 0
Re: [i2c] [PATCH V9] I2C driver for IMX
On Fri, Jul 11, 2008 at 09:29:29AM +0300, Darius wrote:
Changes from V8 version:
- Error numbers replaced to standard numbers from errno.h
- Enable/Start and Disable/Stop functions merged into two Start and Stop
functions
- Removed all unused info about slave mode
- Removed unused includes
Can somebody review functional part of this I2C driver? Because all other
part is already acked by ARM Linux kernel guys.
Signed-off-by: Darius Augulis [EMAIL PROTECTED]
---
I'll need a reasonable header/description in place of the
changelog before this can be merged.
Index: linux-2.6.26-rc9/arch/arm/mach-imx/mx1ads.c
===
--- linux-2.6.26-rc9.orig/arch/arm/mach-imx/mx1ads.c
+++ linux-2.6.26-rc9/arch/arm/mach-imx/mx1ads.c
@@ -109,10 +109,31 @@ static struct platform_device imx_uart2_
}
};
+static struct resource imx_i2c_resources[] = {
+ [0] = {
+ .start = 0x00217000,
+ .end= 0x00217010,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = I2C_INT,
+ .end= I2C_INT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device imx_i2c_device = {
+ .name = imx-i2c,
+ .id = 0,
+ .resource = imx_i2c_resources,
+ .num_resources = ARRAY_SIZE(imx_i2c_resources),
+};
+
static struct platform_device *devices[] __initdata = {
cs89x0_device,
imx_uart1_device,
imx_uart2_device,
+ imx_i2c_device,
};
#ifdef CONFIG_MMC_IMX
I'm not going to step on RMK's toes unless he gives me explicit
acknowledgement to merge arch/arm/mach-imx/mx1ads.c
Index: linux-2.6.26-rc9/drivers/i2c/busses/i2c-imx.c
===
--- /dev/null
+++ linux-2.6.26-rc9/drivers/i2c/busses/i2c-imx.c
@@ -0,0 +1,602 @@
+/*
+ * Copyright (C) 2002 Motorola GSG-China
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ *
+ * Author:
+ * Darius Augulis, Teltonika Inc.
+ *
+ * Desc.:
+ * Implementation of I2C Adapter/Algorithm Driver
+ * Driver for I2C Bus integrated in i.MXL, i.MX1
+ *
+ * module parameters:
+ * - clkfreq:
+ * Sets the desired clock rate
+ * The default value is 10
+ * Max value is 40
+ *
+ * Derived from Motorola GSG China I2C example driver
+ *
+ * Copyright (C) 2005 Torsten Koschorrek koschorrek at synertronixx.de
+ * Portions:
+ * Copyright (C) 2005 Matthias Blaschke blaschke at synertronixx.de
+ * Copyright (C) 2007 RightHand Technologies, Inc.
adyeratrighthandtech.com
+ * Copyright (C) 2008 Darius Augulis darius.augulis at teltonika.lt
+ *
+ */
+
+/** Includes
***
+***/
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/io.h
+#include linux/platform_device.h
+#include asm/arch/irqs.h
+#include asm/arch/hardware.h
+#include asm/arch/imx-regs.h
+
+/** Defines
+***/
+
+/* This will be the driver name the kernel reports */
+#define DRIVER_NAME imx-i2c
+
+/* Default values of module parameters */
+#define IMX_I2C_BIT_RATE 10 /* 100kHz */
+
+/* Timeouts */
+#define I2C_IMX_TIME_BUSY2000/* loop count */
+#define I2C_IMX_TIME_ACK 2000/* loop count */
+#define I2C_IMX_TIME_TRX 5 /* seconds */
+
+/* IMX I2C registers */
+#define IMX_I2C_IADR 0x00/* i2c slave address */
+#define IMX_I2C_IFDR 0x04/* i2c frequency divider */
+#define IMX_I2C_I2CR 0x08/* i2c control */
+#define IMX_I2C_I2SR 0x0C/* i2c status */
+#define IMX_I2C_I2DR 0x10/* i2c transfer data */
+
+/* Bits of IMX I2C registers */
+#define I2SR_RXAK0x01
+#define I2SR_IIF 0x02
+#define I2SR_SRW
Re: [i2c] [PATCH V9] I2C driver for IMX
On Tue, Jul 15, 2008 at 01:52:31PM +0200, Jean Delvare wrote: On Fri, 11 Jul 2008 09:29:29 +0300, Darius wrote: Changes from V8 version: - Error numbers replaced to standard numbers from errno.h - Enable/Start and Disable/Stop functions merged into two Start and Stop functions - Removed all unused info about slave mode - Removed unused includes Can somebody review functional part of this I2C driver? Because all other part is already acked by ARM Linux kernel guys. Signed-off-by: Darius Augulis [EMAIL PROTECTED] --- Ben, this is something for you as well. sorry, was away for long-weekend, just sorted out a quick review. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] i2c: cdev lock_kernel() pushdown
On Tue, Jul 15, 2008 at 01:01:07PM -0400, Jon Smirl wrote: On 7/15/08, Jean Delvare [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008 10:14:06 -0600, Jonathan Corbet wrote: Hi, Jean, I am looking at this patch of yours: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3db633ee352bfe20d4a2b0c3c8a46ce31a6c7149 I believe that no locking is needed in i2cdev_open(). Do you have any reason to think it does? If not, can I simply revert this patch? Before now, i2cdev_open() has always had the protection of the BKL. When I pushed that locking down into the individual open() functions, I really had to take a pretty conservative approach and assume that the BKL was needed unless that was really obviously not the case. In i2cdev_open(), for example, there's: i2c_dev = i2c_dev_get_by_minor(minor); and I really don't know what keeps *i2c_dev from going away during the rest of the call. I'm *not* saying there is a problem here; I just don't know. So the only thing I could really do is to push the BKL down and let the maintainers sort it out. ...all of which is my long-winded way of saying that, if you're convinced that i2cdev_open() is safe in the absence of the BKL, feel free to take it out. Good point. i2c_dev is guaranteed to stay thanks to the call to i2c_get_adapter(), however it happens _after_ the call to i2c_dev_get_by_minor(), so without additional locking, this is racy. That being said, I'm not sure how lock_kernel() is supposed to help. Is the BKL held when i2cdev_detach_adapter() is called? If not, then I suspect that the current code is already racy. I'll look into this, thanks for the hint. Is i2c-dev vulnerable to the i2c device disappearing, for example rmmod it? Would combining i2c-dev into i2c core and integrating it with the core's lock protection make things easier to lock? You could make a compile time option to remove it for small systems. If it's in the core is attach/detach adapter still needed? I haven't looked at any of this in detail, but i2c-dev is only 6K of code. Half of the 6K might disappear if integrated into the core. The i2c-dev code calls i2c_get_adapter() op open, so as long as the device stays open the adapter should not be able to go away as i2c_get_adater() calls try_module_get() on the adapter's module. The i2c-dev has it's own THIS_MODULE in the fops field, so should be kept as long as there is a file open. What happens if user space and an in-kernel user both try using the device? I've never tried doing that. Should the presence of an in-kernel user make the user space device disappear? -- Jon Smirl [EMAIL PROTECTED] ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] i2c: Documentation: upgrading clients HOWTO
Add a document describing how i2c clients on Linux 2.6 can be
moved from the old to the new driver model.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-quilt2/Documentation/i2c/upgrading-clients
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.26-quilt2/Documentation/i2c/upgrading-clients 2008-07-15
21:25:26.0 +0100
@@ -0,0 +1,280 @@
+Upgrading I2C Drivers to the new 2.6 Driver Model
+=
+
+Ben Dooks [EMAIL PROTECTED]
+
+Introduction
+
+
+This guide outlines how to alter existing Linux 2.6 client drivers from
+the old to the new new binding methods.
+
+
+Example old-style driver
+
+
+
+struct example_state {
+ struct i2c_client client;
+
+};
+
+static struct i2c_driver example_driver;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+static int example_attach(struct i2c_adapter *adap, int addr, int kind)
+{
+ struct example_state *state;
+ struct device *dev = adap-dev; /* to use for dev_ reports */
+ int ret;
+
+ state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
+ if (state == NULL) {
+ dev_err(dev, failed to create our state\n);
+ return -ENOMEM;
+ }
+
+ example-client.addr= addr;
+ example-client.flags = 0;
+ example-client.adapter = adap;
+
+ i2c_set_clientdata(state-i2c_client, state);
+ strlcpy(client-i2c_client.name, example, I2C_NAME_SIZE);
+
+ ret = i2c_attach_client(state-i2c_client);
+ if (ret 0) {
+ dev_err(dev, failed to attach client\n);
+ kfree(state);
+ return ret;
+ }
+
+ dev = state-i2c_client.dev;
+
+ /* rest of the initialisation goes here. */
+
+ dev_info(dev, example client created\n);
+
+ return 0;
+}
+
+static int __devexit example_detach(struct i2c_client *client)
+{
+ struct example_state *state = i2c_get_clientdata(client);
+
+ i2c_detach_client(client);
+ kfree(state);
+ return 0;
+}
+
+static int example_attach_adapter(struct i2c_adapter *adap)
+{
+ return i2c_probe(adap, addr_data, example_attach);
+}
+
+static struct i2c_driver example_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = example,
+ },
+ .attach_adapter = example_attach_adapter,
+ .detach_client = __devexit_p(example_detach),
+ .suspend= example_suspend,
+ .resume = example_resume,
+};
+
+
+Updating the client
+---
+
+The new style binding model will check against a list of supported
+devices and their associated address supplied by the code registering
+the busses. This means that the driver .attach_adapter and
+.detach_adapter methods can be removed, along with the addr_data,
+as follows:
+
+- static struct i2c_driver example_driver;
+
+- static unsigned short ignore[] = { I2C_CLIENT_END };
+- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
+
+- I2C_CLIENT_INSMOD;
+
+- static int example_attach_adapter(struct i2c_adapter *adap)
+- {
+- return i2c_probe(adap, addr_data, example_attach);
+- }
+
+ static struct i2c_driver example_driver = {
+- .attach_adapter = example_attach_adapter,
+- .detach_client = __devexit_p(example_detach),
+ }
+
+Add the probe and remove methods to the i2c_driver, as so:
+
+ static struct i2c_driver example_driver = {
++ .probe = example_probe,
++ .remove = __devexit_p(example_remove),
+ }
+
+Change the example_attach method to accept the new parameters
+which include the i2c_client that it will be working with:
+
+- static int example_attach(struct i2c_adapter *adap, int addr, int kind)
++ static int example_probe(struct i2c_client *client,
++ const struct i2c_device_id *id)
+
+Change the name of example_attach to example_probe to align it with the
+i2c_driver entry names. The rest of the probe routine will now need to be
+changed as the i2c_client has already been setup for use.
+
+The necessary client fields have already been setup before
+the probe function is called, so the following client setup
+can be removed:
+
+- example-client.addr= addr;
+- example-client.flags = 0;
+- example-client.adapter = adap;
+-
+- strlcpy(client-i2c_client.name, example, I2C_NAME_SIZE);
+
+The i2c_set_clientdata is now:
+
+- i2c_set_clientdata(state-client, state);
++ i2c_set_clientdata(client, state);
+
+The call to i2c_attach_client is no longer needed, if the probe
+routine exits successfully, then the driver will be automatically
+attached by the core. Change the probe routine as so:
+
+- ret
Re: [i2c] [PATCH 1/1] I2C pxa fast mode (400khz) support
On Thu, Jul 03, 2008 at 10:00:36AM +0800, Eric Miao wrote:
Jonathan Cameron wrote:
Add fast_mode option to i2c_pxa_platform_data and use it to set the ICR_FM
bit
appropriately when i2c_pxa_reset is called. Parameter called fast_mode
rather
than frequency as this driver is also used for the i2c_pxa_pwr bus which has
different normal and fast frequencies.
Maybe we should convert that (as well as 'use_pio') to a bit field to save
another byte.
I think use_pio and fast_mode could both be bits.
Otherwise looks OK to me.
Signed-off-by: Jonathan Cameron [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-pxa.c|4 +++-
include/asm-arm/arch-pxa/i2c.h |1 +
include/asm-arm/arch-pxa/pxa-regs.h |1 +
3 files changed, 5 insertions(+), 1 deletion(-)
--- a/include/asm-arm/arch-pxa/pxa-regs.h 2008-06-30 20:06:02.0
+0100
+++ b/include/asm-arm/arch-pxa/pxa-regs.h 2008-07-02 14:03:19.0
+0100
@@ -448,6 +448,7 @@
#define ICR_ALDIE (1 12) /* enable arbitration interrupt */
#define ICR_SADIE (1 13) /* slave address detected int enable
*/
#define ICR_UR (1 14) /* unit reset */
+#define ICR_FM (1 15) /* fast mode */
#define ISR_RWM(1 0) /* read/write mode */
#define ISR_ACKNAK (1 1) /* ack/nak status */
--- a/include/asm-arm/arch-pxa/i2c.h2008-06-30 20:04:02.0
+0100
+++ b/include/asm-arm/arch-pxa/i2c.h2008-07-02 13:59:59.0
+0100
@@ -66,6 +66,7 @@ struct i2c_pxa_platform_data {
struct i2c_slave_client *slave;
unsigned intclass;
int use_pio;
+ int fast_mode;
};
extern void pxa_set_i2c_info(struct i2c_pxa_platform_data *info);
--- a/drivers/i2c/busses/i2c-pxa.c 2008-06-30 20:05:51.0 +0100
+++ b/drivers/i2c/busses/i2c-pxa.c 2008-07-02 15:50:31.0 +0100
@@ -67,6 +67,7 @@ struct pxa_i2c {
int irq;
int use_pio;
+ int fast_mode;
};
#define _IBMR(i2c) ((i2c)-reg_base + 0)
@@ -365,7 +366,7 @@ static void i2c_pxa_reset(struct pxa_i2c
writel(i2c-slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT, _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c-fast_mode ? ICR_FM : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(i2c-adap.dev, Enabling slave mode\n);
@@ -1041,6 +1042,7 @@ static int i2c_pxa_probe(struct platform
if (plat) {
i2c-adap.class = plat-class;
i2c-use_pio = plat-use_pio;
+ i2c-fast_mode = plat-fast_mode;
}
if (i2c-use_pio) {
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [patch 1/1] i2c_gpio: keep probe resident for hotplugged devices.
On Wed, Jul 02, 2008 at 12:44:06PM +0200, Haavard Skinnemoen wrote: Ben Dooks [EMAIL PROTECTED] wrote: Change the i2c_gpio driver to use platform_driver_register() instead of platform_driver_probe() to ensure that is can attach to any devices that may be loaded after it has initialised. Does anyone actually do that? At the moment our standard kernel configuration only builds in the SM501 which will work without this patch on. However, we have clients that do build module kernels and I would like to replace i2c-simtec.c with the gpio driver and if the relevant module instantiating the gpio support is loaded post kernel init, then we will need to do this. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [patch 0/2] S3C24XX Updates for post 2.6.26
I2C updates for merging once 2.6.26 is out. -- Ben ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [patch 1/2] I2C: S3C2410: Pass the I2C bus number via drivers platform data
Allow the platform data to specify the bus bumber that the
new I2C bus will be given. This is to allow the use of the
board registration mechanism to specify the new style of
I2C device registration which allows boards to provide a
list of attached devices.
Note, as discussed on the mailing list, we have dropped
backwards compatibility of adding an dynamic bus number
as it should not affect most boards to have the bus pinned
to 0 if they have either not specified platform data for
driver. Any board supplying platform data will automatically
have the bus_num field set to 0, and anyone who needs the
driver on a different bus number can supply platform data
to set bus_num.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc4-quilt3/drivers/i2c/busses/i2c-s3c2410.c
===
--- linux-2.6.26-rc4-quilt3.orig/drivers/i2c/busses/i2c-s3c2410.c
2008-06-02 22:55:20.0 +0100
+++ linux-2.6.26-rc4-quilt3/drivers/i2c/busses/i2c-s3c2410.c2008-06-02
22:55:29.0 +0100
@@ -752,9 +752,12 @@ static int s3c24xx_i2c_init(struct s3c24
static int s3c24xx_i2c_probe(struct platform_device *pdev)
{
struct s3c24xx_i2c *i2c = s3c24xx_i2c;
+ struct s3c2410_platform_i2c *pdata;
struct resource *res;
int ret;
+ pdata = s3c24xx_i2c_get_platformdata(pdev-dev);
+
/* find the clock and enable it */
i2c-dev = pdev-dev;
@@ -832,7 +835,15 @@ static int s3c24xx_i2c_probe(struct plat
dev_dbg(pdev-dev, irq resource %p (%lu)\n, res,
(unsigned long)res-start);
- ret = i2c_add_adapter(i2c-adap);
+ /* Note, previous versions of the driver used i2c_add_adapter()
+* to add an bus at any number. We now pass the bus number via
+* the platform data, so if unset it will now default to always
+* being bus 0.
+*/
+
+ i2c-adap.nr = pdata-bus_num;
+ ret = i2c_add_numbered_adapter(i2c-adap);
+
if (ret 0) {
dev_err(pdev-dev, failed to add bus to i2c core\n);
goto err_irq;
Index: linux-2.6.26-rc4-quilt3/include/asm-arm/plat-s3c/iic.h
===
--- linux-2.6.26-rc4-quilt3.orig/include/asm-arm/plat-s3c/iic.h 2008-06-02
20:12:47.0 +0100
+++ linux-2.6.26-rc4-quilt3/include/asm-arm/plat-s3c/iic.h 2008-06-02
22:55:29.0 +0100
@@ -21,6 +21,7 @@
*/
struct s3c2410_platform_i2c {
+ int bus_num;/* bus number to use */
unsigned intflags;
unsigned intslave_addr; /* slave address for controller */
unsigned long bus_freq; /* standard bus frequency */
--
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [patch 2/2] I2C: S3C24XX I2C frequency scaling support.
Add support for CPU frequency scaling to the S3C24XX I2C driver.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc9/drivers/i2c/busses/i2c-s3c2410.c
===
--- linux-2.6.26-rc9.orig/drivers/i2c/busses/i2c-s3c2410.c 2008-07-09
13:46:08.0 +0100
+++ linux-2.6.26-rc9/drivers/i2c/busses/i2c-s3c2410.c 2008-07-09
13:48:46.0 +0100
@@ -33,6 +33,7 @@
#include linux/err.h
#include linux/platform_device.h
#include linux/clk.h
+#include linux/cpufreq.h
#include asm/hardware.h
#include asm/irq.h
@@ -64,6 +65,7 @@ struct s3c24xx_i2c {
unsigned inttx_setup;
enum s3c24xx_i2c_state state;
+ unsigned long clkrate;
void __iomem*regs;
struct clk *clk;
@@ -71,6 +73,10 @@ struct s3c24xx_i2c {
struct resource *irq;
struct resource *ioarea;
struct i2c_adapter adap;
+
+#ifdef CONFIG_CPU_FREQ
+ struct notifier_block freq_transition;
+#endif
};
/* default platform data to use if not supplied in the platform_device
@@ -501,6 +507,9 @@ static int s3c24xx_i2c_doxfer(struct s3c
unsigned long timeout;
int ret;
+ if (!readl(i2c-regs + S3C2410_IICCON) S3C2410_IICCON_IRQEN)
+ return -EIO;
+
ret = s3c24xx_i2c_set_master(i2c);
if (ret != 0) {
dev_err(i2c-dev, cannot get bus (error %d)\n, ret);
@@ -636,27 +645,28 @@ static inline int freq_acceptable(unsign
return (diff = -2 diff = 2);
}
-/* s3c24xx_i2c_getdivisor
+/* s3c24xx_i2c_clockrate
*
* work out a divisor for the user requested frequency setting,
* either by the requested frequency, or scanning the acceptable
* range of frequencies until something is found
*/
-static int s3c24xx_i2c_getdivisor(struct s3c24xx_i2c *i2c,
- struct s3c2410_platform_i2c *pdata,
- unsigned long *iicon,
- unsigned int *got)
+static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c, unsigned int *got)
{
+ struct s3c2410_platform_i2c *pdata;
unsigned long clkin = clk_get_rate(i2c-clk);
-
unsigned int divs, div1;
+ u32 iiccon;
int freq;
int start, end;
+ i2c-clkrate = clkin;
+
+ pdata = s3c24xx_i2c_get_platformdata(i2c-adap.dev.parent);
clkin /= 1000; /* clkin now in KHz */
- dev_dbg(i2c-dev, pdata %p, freq %lu %lu..%lu\n,
+ dev_dbg(i2c-dev, pdata %p, freq %lu %lu..%lu\n,
pdata, pdata-bus_freq, pdata-min_freq, pdata-max_freq);
if (pdata-bus_freq != 0) {
@@ -688,11 +698,79 @@ static int s3c24xx_i2c_getdivisor(struct
found:
*got = freq;
- *iicon |= (divs-1);
- *iicon |= (div1 == 512) ? S3C2410_IICCON_TXDIV_512 : 0;
+
+ iiccon = readl(i2c-regs + S3C2410_IICCON);
+ iiccon = ~(S3C2410_IICCON_SCALEMASK | S3C2410_IICCON_TXDIV_512);
+ iiccon |= (divs-1);
+
+ if (div1 == 512)
+ iiccon |= S3C2410_IICCON_TXDIV_512;
+
+ writel(iiccon, i2c-regs + S3C2410_IICCON);
+
+ return 0;
+}
+
+#ifdef CONFIG_CPU_FREQ
+
+#define freq_to_i2c(_n) container_of(_n, struct s3c24xx_i2c, freq_transition)
+
+static int s3c24xx_i2c_cpufreq_transition(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ struct s3c24xx_i2c *i2c = freq_to_i2c(nb);
+ unsigned long clkrate;
+ unsigned long flags;
+ unsigned int got;
+ int ret;
+
+ clkrate = clk_get_rate(i2c-clk);
+
+ /* if we're post-change and the input clock has slowed down
+* or at pre-change and the clock is about to speed up, then
+* adjust our clock rate.
+*/
+
+ if ((val == CPUFREQ_POSTCHANGE clkrate i2c-clkrate) ||
+ (val == CPUFREQ_PRECHANGE clkrate i2c-clkrate)) {
+ spin_lock_irqsave(i2c-lock, flags);
+ ret = s3c24xx_i2c_clockrate(i2c, got);
+ spin_unlock_irqrestore(i2c-lock, flags);
+
+ if (ret 0)
+ dev_err(i2c-dev, cannot find frequency\n);
+ else
+ dev_info(i2c-dev, setting freq %d\n, got);
+ }
+
return 0;
}
+static inline int s3c24xx_i2c_register_cpufreq(struct s3c24xx_i2c *i2c)
+{
+ i2c-freq_transition.notifier_call = s3c24xx_i2c_cpufreq_transition;
+
+ return cpufreq_register_notifier(i2c-freq_transition,
+CPUFREQ_TRANSITION_NOTIFIER);
+}
+
+static inline void s3c24xx_i2c_deregister_cpufreq(struct s3c24xx_i2c *i2c)
+{
+ cpufreq_unregister_notifier(i2c-freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+
+#else
+static inline int s3c24xx_i2c_register_cpufreq(struct s3c24xx_i2c *i2c
[i2c] [patch 1/1] i2c_gpio: keep probe resident for hotplugged devices.
Change the i2c_gpio driver to use platform_driver_register()
instead of platform_driver_probe() to ensure that is can
attach to any devices that may be loaded after it has initialised.
Cc: Haavard Skinnemoen [EMAIL PROTECTED]
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc8-quilt3/drivers/i2c/busses/i2c-gpio.c
===
--- linux-2.6.26-rc8-quilt3.orig/drivers/i2c/busses/i2c-gpio.c 2008-06-25
09:46:48.0 +0100
+++ linux-2.6.26-rc8-quilt3/drivers/i2c/busses/i2c-gpio.c 2008-07-02
11:12:05.0 +0100
@@ -77,7 +77,7 @@ static int i2c_gpio_getscl(void *data)
return gpio_get_value(pdata-scl_pin);
}
-static int __init i2c_gpio_probe(struct platform_device *pdev)
+static int __devinit i2c_gpio_probe(struct platform_device *pdev)
{
struct i2c_gpio_platform_data *pdata;
struct i2c_algo_bit_data *bit_data;
@@ -174,7 +174,7 @@ err_alloc_adap:
return ret;
}
-static int __exit i2c_gpio_remove(struct platform_device *pdev)
+static int __devexit i2c_gpio_remove(struct platform_device *pdev)
{
struct i2c_gpio_platform_data *pdata;
struct i2c_adapter *adap;
@@ -196,14 +196,15 @@ static struct platform_driver i2c_gpio_d
.name = i2c-gpio,
.owner = THIS_MODULE,
},
- .remove = __exit_p(i2c_gpio_remove),
+ .probe = i2c_gpio_probe,
+ .remove = __devexit_p(i2c_gpio_remove),
};
static int __init i2c_gpio_init(void)
{
int ret;
- ret = platform_driver_probe(i2c_gpio_driver, i2c_gpio_probe);
+ ret = platform_driver_register(i2c_gpio_driver);
if (ret)
printk(KERN_ERR i2c-gpio: probe failed: %d\n, ret);
--
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] i2c pull request for s3c24xx driver
Pull request for i2c driver fixes to the S3C24XX i2c driver suitable for applying to the current kernel. Linus please take this unless Jean wants to pull this into his own i2c tree. The following changes since commit e1441b9a41c33aa9236008a7cfe49a8e723fb397: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input are available in the git repository at: git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-fix Ben Dooks (3): I2C: S3C2410: Check ACK on byte transmission I2C: S3C2410: Fixup error codes returned rom a transfer. I2C: S3C2410: Add MODULE_ALIAS() for s3c2440 device. drivers/i2c/busses/i2c-s3c2410.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] i2c pull request for s3c24xx driver
Pull request for i2c driver fixes to the S3C24XX i2c driver suitable for applying to the current kernel. Linus please take this unless Jean wants to pull this into his own i2c tree. The following changes since commit e1441b9a41c33aa9236008a7cfe49a8e723fb397: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input are available in the git repository at: git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-fix Ben Dooks (3): I2C: S3C2410: Check ACK on byte transmission I2C: S3C2410: Fixup error codes returned rom a transfer. I2C: S3C2410: Add MODULE_ALIAS() for s3c2440 device. drivers/i2c/busses/i2c-s3c2410.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [patch 1/1] i2c_gpio: keep probe resident for hotplugged devices.
Change the i2c_gpio driver to use platform_driver_register()
instead of platform_driver_probe() to ensure that is can
attach to any devices that may be loaded after it has initialised.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
--- linux-2.6.26-rc5-quilt1.orig/drivers/i2c/busses/i2c-gpio.c 2008-06-11
00:17:08.0 +0100
+++ linux-2.6.26-rc5-quilt1/drivers/i2c/busses/i2c-gpio.c 2008-06-11
00:18:00.0 +0100
@@ -77,7 +77,7 @@ static int i2c_gpio_getscl(void *data)
return gpio_get_value(pdata-scl_pin);
}
-static int __init i2c_gpio_probe(struct platform_device *pdev)
+static int __devinit i2c_gpio_probe(struct platform_device *pdev)
{
struct i2c_gpio_platform_data *pdata;
struct i2c_algo_bit_data *bit_data;
@@ -196,6 +196,7 @@ static struct platform_driver i2c_gpio_d
.name = i2c-gpio,
.owner = THIS_MODULE,
},
+ .probe = i2c_gpio_probe,
.remove = __exit_p(i2c_gpio_remove),
};
@@ -203,7 +204,7 @@ static int __init i2c_gpio_init(void)
{
int ret;
- ret = platform_driver_probe(i2c_gpio_driver, i2c_gpio_probe);
+ ret = platform_driver_register(i2c_gpio_driver);
if (ret)
printk(KERN_ERR i2c-gpio: probe failed: %d\n, ret);
--
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Frame buffers and early i2c
On Tue, Jun 10, 2008 at 11:31:19AM +0200, Uli Luckas wrote: On Tuesday, 10. June 2008, Jean Delvare wrote: Hi Uli, On Mon, 9 Jun 2008 23:59:35 +0200, Uli Luckas wrote: On Monday 09 June 2008, Jean Delvare wrote: Why don't you ask on the i2c mailing list? Cc added. I wanted to get i2c developers plus frame buffer and other i2c client developers involved. Crossposting to more then 2 lists seemed wrong. So you prefer to post to one random list than the two lists where your target audience is? Interesting approach. If you really don't want to post to two lists at once, just send two separate posts? And have two seperate threads of communication??? lfml is where they all are and avery maintainer has different preferences. Anyway, I got your point and will come to the i2c list in the future if you prefere. I'll change the pxa i2c driver to subsys_initcall and try if that works when I get back to my desk tomorrow. I expect it to work, as apparently other platforms are doing exactly that already. Just changing the initcall to subsys really did the trick. I thought, this was the first thing I tried and I thought it crashed my device. But obviousely I had some other problem. If Russell gives his Ack, could this be pushed upstream through i2c? Does this work if the code is built as a module? BTW, if people do have these sort of dependencies, then modules are another way of sorting out the load order, unless you have the module autoload enabled. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] Documentation issue on attaching new style drivers
Quoting from Documentation/i2c/writing-clients, the section
entitled Standard Driver Model Binding (New Style) has
the following paragraph:
Drivers match devices when i2c_client.driver_name and the driver name are
the same; this approach is used in several other busses that don't have
device typing support in the hardware. The driver and module name should
match, so hotplug/coldplug mechanisms will modprobe the driver.
Having tried this whilst upgrading an old driver in my own
tree, I found that this does not work, and that you need to
supply your own idtable for the .id_table entry.
I had a quick look in drivers/i2c/i2c-core.c and it seems
that the only thing the .match entry i2c_device_match()
is doing is checking the driver's id_table, as so:
static int i2c_device_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(drv);
/* make legacy i2c drivers bypass driver model probing entirely;
* such drivers scan each i2c adapter/bus themselves.
*/
if (!is_newstyle_driver(driver))
return 0;
/* match on an id table if there is one */
if (driver-id_table)
return i2c_match_id(driver-id_table, client) != NULL;
return 0;
}
Is the documentation wrong, and all drivers need to have an id_table
in them, or is the i2c-core.c wrong for only checking the id_table
entries?
My suspicion is that everyone is using the id_table as this can be
passed to the MODULE_DEVICE_TABLE() to allow autoloading of the
relevant modules? Note, the i2c_probe function will correctly pass
a NULL ID if there is no id_table present.
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] i2c: Documentation: fix device matching description
The matching process described for new style clients in
Documentation/i2c/writing-clients is classed as out-of-date
as it requires the presence of an .id_table entry in the
driver's i2c_driver entry.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc4-quilt3/Documentation/i2c/writing-clients
===
--- linux-2.6.26-rc4-quilt3.orig/Documentation/i2c/writing-clients
2008-06-03 18:05:36.0 +0100
+++ linux-2.6.26-rc4-quilt3/Documentation/i2c/writing-clients 2008-06-03
18:25:45.0 +0100
@@ -25,12 +25,23 @@ routines, and should be zero-initialized
provide. A client structure holds device-specific information like the
driver model device node, and its I2C address.
+/* iff driver uses driver model (new style) binding model: */
+
+static struct i2c_device_id foo_idtable[] = {
+ { foo, my_id_for_foo },
+ { bar, my_id_for_bar },
+ { }
+};
+
+MODULE_DEVICE_TABLE(i2c, foo_idtable);
+
static struct i2c_driver foo_driver = {
.driver = {
.name = foo,
},
/* iff driver uses driver model (new style) binding model: */
+ .id_table = foo_ids,
.probe = foo_probe,
.remove = foo_remove,
@@ -173,10 +184,9 @@ handle may be used during foo_probe().
(zero not a negative status code) it may save the handle and use it until
foo_remove() returns. That binding model is used by most Linux drivers.
-Drivers match devices when i2c_client.driver_name and the driver name are
-the same; this approach is used in several other busses that don't have
-device typing support in the hardware. The driver and module name should
-match, so hotplug/coldplug mechanisms will modprobe the driver.
+The probe function is called when an entry in the id_table name field
+matches the device's name. The probe function is passed the entry that
+was matched so that it can support different versions of a device.
Device Creation (Standard driver model)
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] i2c: Documentation: fix device matching description
The matching process described for new style clients in
Documentation/i2c/writing-clients is classed as out-of-date
as it requires the presence of an .id_table entry in the
driver's i2c_driver entry.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc4-quilt3/Documentation/i2c/writing-clients
===
--- linux-2.6.26-rc4-quilt3.orig/Documentation/i2c/writing-clients
2008-06-03 17:31:39.0 +0100
+++ linux-2.6.26-rc4-quilt3/Documentation/i2c/writing-clients 2008-06-03
17:37:29.0 +0100
@@ -25,12 +25,23 @@ routines, and should be zero-initialized
provide. A client structure holds device-specific information like the
driver model device node, and its I2C address.
+/* iff driver uses driver model (new style) binding model: */
+
+static struct i2c_device_id foo_idtable[] = {
+ { foo, my_id_for_foo },
+ { bar, my_id_for_bar },
+ { }
+};
+
+MODULE_DEVICE_TABLE(i2c, foo_idtable);
+
static struct i2c_driver foo_driver = {
.driver = {
.name = foo,
},
/* iff driver uses driver model (new style) binding model: */
+ .id_table = foo_ids,
.probe = foo_probe,
.remove = foo_remove,
@@ -173,10 +184,15 @@ handle may be used during foo_probe().
(zero not a negative status code) it may save the handle and use it until
foo_remove() returns. That binding model is used by most Linux drivers.
-Drivers match devices when i2c_client.driver_name and the driver name are
-the same; this approach is used in several other busses that don't have
-device typing support in the hardware. The driver and module name should
-match, so hotplug/coldplug mechanisms will modprobe the driver.
+Drivers match devices when an entry in the id_table[x].name and the
+device name are the same; this approach is used in several other busses
+that don't have device typing support in the hardware. The driver and
+module name should match, so hotplug/coldplug mechanisms will modprobe
+the driver.
+
+The id argument to the probe function will be the id_table entry matched
+during the probe, so that a device can support more than one flavour of
+similar device.
Device Creation (Standard driver model)
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] I2C: S3C2410: Fixup error codes returned rom a transfer.
The driver should be returning -ENXIO for transfers that do not
pass the initial address byte stage.
Note, also small tidyups to the driver comments in the area.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc4-quilt3/drivers/i2c/busses/i2c-s3c2410.c
===
--- linux-2.6.26-rc4-quilt3.orig/drivers/i2c/busses/i2c-s3c2410.c
2008-06-02 20:19:14.0 +0100
+++ linux-2.6.26-rc4-quilt3/drivers/i2c/busses/i2c-s3c2410.c2008-06-02
20:20:02.0 +0100
@@ -290,12 +290,12 @@ static int i2s_s3c_irq_nextbyte(struct s
* bus, or started a new i2c message
*/
- if (iicstat S3C2410_IICSTAT_LASTBIT
+ if (iicstat S3C2410_IICSTAT_LASTBIT
!(i2c-msg-flags I2C_M_IGNORE_NAK)) {
/* ack was not received... */
dev_dbg(i2c-dev, ack was not received\n);
- s3c24xx_i2c_stop(i2c, -EREMOTEIO);
+ s3c24xx_i2c_stop(i2c, -ENXIO);
goto out_ack;
}
@@ -305,7 +305,7 @@ static int i2s_s3c_irq_nextbyte(struct s
i2c-state = STATE_WRITE;
/* terminate the transfer if there is nothing to do
-* (used by the i2c probe to find devices */
+* as this is used by the i2c probe to find devices. */
if (is_lastmsg(i2c) i2c-msg-len == 0) {
s3c24xx_i2c_stop(i2c, 0);
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [patch 7/8] VR1000: Add i2c device list to Thorcom VR1000
On Sun, Jun 01, 2008 at 09:32:15AM +0200, Jean Delvare wrote:
On Thu, 29 May 2008 14:22:51 +0100, Ben Dooks wrote:
Add i2c board intialisers to specify the I2C devices
attached on the Thorcom VR1000.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc4-quilt1/arch/arm/mach-s3c2410/mach-vr1000.c
===
--- linux-2.6.26-rc4-quilt1.orig/arch/arm/mach-s3c2410/mach-vr1000.c
2008-05-27 23:31:41.0 +0100
+++ linux-2.6.26-rc4-quilt1/arch/arm/mach-s3c2410/mach-vr1000.c
2008-05-27 23:59:05.0 +0100
@@ -1,6 +1,6 @@
/* linux/arch/arm/mach-s3c2410/mach-vr1000.c
*
- * Copyright (c) 2003-2005 Simtec Electronics
+ * Copyright (c) 2003-2005,2008 Simtec Electronics
* Ben Dooks [EMAIL PROTECTED]
*
* Machine support for Thorcom VR1000 board. Designed for Thorcom by
@@ -19,6 +19,7 @@
#include linux/timer.h
#include linux/init.h
#include linux/dm9000.h
+#include linux/i2c.h
#include linux/serial.h
#include linux/tty.h
@@ -315,6 +316,24 @@ static struct platform_device vr1000_led
},
};
+/* I2C devices. */
+
+static struct i2c_board_info vr1000_i2c_info[] __initdata = {
+ {
+ .type = tlv320aic23,
+ .addr = 0x1a,
+ }, {
+ .type = tmp101,
+ .addr = 0x48,
Same problem as eeprom... The lm75 driver doesn't yet support the
tmp101 as a new-style device in mainline, so this won't work and will
prevent the lm75 driver from attaching as a legacy driver too. So this
device declaration should be delayed or commented out until the lm75
driver is ready.
I'll think about that one, although it does take a force to load the lm75
on current kernels due to it not being 'truly' lm75 compatible. Is there
any chance of the new driver being merged during the next change window?
PS, I've done a quick test of the new lm75 driver and it seems to work
fine for me and would like to see a solution where we don't need to force
probe the lm75 module.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [patch 2/8] I2C: S3C2410: Add MODULE_ALIAS() for s3c2440 device.
On Fri, May 30, 2008 at 09:54:52PM +0200, Jean Delvare wrote: Hi Ben, On Thu, 29 May 2008 14:22:46 +0100, Ben Dooks wrote: Add a MODULE_ALIAS() statement for the i2c-s3c2410 controller to ensure that it can be autoloaded on the S3C2440 systems that we support. Signed-off-by: Ben Dooks [EMAIL PROTECTED] Index: linux-2.6.26-rc4-quilt1/drivers/i2c/busses/i2c-s3c2410.c === --- linux-2.6.26-rc4-quilt1.orig/drivers/i2c/busses/i2c-s3c2410.c 2008-05-28 11:56:54.0 +0100 +++ linux-2.6.26-rc4-quilt1/drivers/i2c/busses/i2c-s3c2410.c 2008-05-28 11:57:12.0 +0100 @@ -947,3 +947,4 @@ MODULE_DESCRIPTION(S3C24XX I2C Bus driv MODULE_AUTHOR(Ben Dooks, [EMAIL PROTECTED]); MODULE_LICENSE(GPL); MODULE_ALIAS(platform:s3c2410-i2c); +MODULE_ALIAS(platform:s3c2440-i2c); With the current driver code, that's correct. Acked-by: Jean Delvare [EMAIL PROTECTED] That being said, I think the approach is wrong. You shouldn't register two different platform drivers just to be able to differentiate between device types. You have platform_data for that, it's cleaner and cheaper. Actually, there are down sides to doing it via platform data, and a few upsides to using the driver model. I do agree that 1 driver does mean that you end up allocating more space to the drivers, but I hope that I can convince you that this isn't without merit. The following are downsides: 1) using platform data means that not only do all the boards that have i2c busses on (or other peripherals using this method) need to carry[1] and register platform data even if they do not need to. 2) We currently change the name of the platform device in the cpu specific architecture initialisation, which would mean either moving this to each machine or have some form of sharing between the arch code and the board init. 3) Some boards can have more than one cpu type on them, which makes life even worse for the above. The advantage of changing the name of the platform device means that the type of device is shown in the /sys/devices/platform heirachy without any need for code to add a new attribute to show it within the device itself. [1] Even if this is __initdata, it means the kernel has to carry it to load it even if it gets dumped at startup, and we have a number of boards that are available. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH V6] I2C driver for IMX
On Tue, May 20, 2008 at 09:41:59AM +0300, Darius wrote:
Changes from V5 version:
- Trent Piepho suggestions added (except debug macro)
- Debug printing fixed
- Calculations of clock divider and delay improved
Checked with checkpatch.pl again and tested on MXLADS V2.0 board with several
i2c clients.
Signed-off-by: Darius Augulis [EMAIL PROTECTED]
---
Index: linux-2.6.26-rc1/arch/arm/mach-imx/mx1ads.c
===
--- linux-2.6.26-rc1.orig/arch/arm/mach-imx/mx1ads.c
+++ linux-2.6.26-rc1/arch/arm/mach-imx/mx1ads.c
@@ -109,10 +109,31 @@ static struct platform_device imx_uart2_
}
};
+static struct resource imx_i2c_resources[] = {
+ [0] = {
+ .start = 0x00217000,
+ .end= 0x00217010,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = I2C_INT,
+ .end= I2C_INT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device imx_i2c_device = {
+ .name = imx-i2c,
+ .id = 0,
+ .resource = imx_i2c_resources,
+ .num_resources = ARRAY_SIZE(imx_i2c_resources),
+};
+
static struct platform_device *devices[] __initdata = {
cs89x0_device,
imx_uart1_device,
imx_uart2_device,
+ imx_i2c_device,
};
#ifdef CONFIG_MMC_IMX
Index: linux-2.6.26-rc1/drivers/i2c/busses/i2c-imx.c
===
--- /dev/null
+++ linux-2.6.26-rc1/drivers/i2c/busses/i2c-imx.c
@@ -0,0 +1,639 @@
+/*
+ * Copyright (C) 2002 Motorola GSG-China
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ *
+ * Author:
+ * Darius Augulis, Teltonika Inc.
+ *
+ * Desc.:
+ * Implementation of I2C Adapter/Algorithm Driver
+ * Driver for I2C Bus integrated in i.MXL, i.MX1
+ *
+ * module parameters:
+ * - clkfreq:
+ * Sets the desired clock rate
+ * The default value is 10
+ * Max value is 40
+ * - imxslave:
+ * IMX slave I2C address in decimal format
+ * The default value is 0xAC in hex
+ *
+ * Derived from Motorola GSG China I2C example driver
+ *
+ * Copyright (C) 2005 Torsten Koschorrek koschorrek at synertronixx.de
+ * Portions:
+ * Copyright (C) 2005 Matthias Blaschke blaschke at synertronixx.de
+ * Copyright (C) 2007 RightHand Technologies, Inc.
adyeratrighthandtech.com
+ * Copyright (C) 2008 Darius Augulis darius.augulis at teltonika.lt
+ *
+ */
+
+/** Includes
***
+***/
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/fs.h
+#include linux/proc_fs.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/io.h
+#include linux/platform_device.h
+#include asm/arch/irqs.h
+#include asm/arch/hardware.h
+#include asm/arch/imx-regs.h
+
+/** Defines
+***/
+
+/* This will be the driver name the kernel reports */
+#define DRIVER_NAME imx-i2c
+
+/* Default values of module parameters */
+#define IMX_I2C_SLAVE_ADDR 0xAC
+#define IMX_I2C_BIT_RATE 10 /* 100kHz */
+
+/* Timeouts */
+#define I2C_IMX_TIME_BUSY2000/* loop count */
+#define I2C_IMX_TIME_ACK 2000/* loop count */
+#define I2C_IMX_TIME_TRX 5 /* seconds */
+
+/* Error numbers */
+#define I2C_IMX_ERR_BUSY 1
+#define I2C_IMX_ERR_TX_TIMEOUT 2
+#define I2C_IMX_ERR_RX_TIMEOUT 3
+#define I2C_IMX_ERR_RX_NO_ACK4
+
+/* IMX I2C registers */
+#define IMX_I2C_IADR 0x00/* i2c slave address */
+#define IMX_I2C_IFDR 0x04/* i2c frequency divider */
+#define IMX_I2C_I2CR 0x08/* i2c control */
+#define IMX_I2C_I2SR 0x0C/* i2c status */
+#define IMX_I2C_I2DR 0x10/* i2c transfer data */
+
+/* Bits of IMX I2C
Re: [i2c] [patch 3/3] i2c: add support for i2c bus on Freescale CPM1/CPM2 controllers
On Mon, May 19, 2008 at 06:49:07PM +0200, Jean Delvare wrote: Hi Wolfram, The dev_err-statements are too strong, IMHO. For example, the at24-driver tries to write as fast as possible and may recieve a NACK, then it will wait a bit and retry. I wouldn't call this NACK an error then. I also wonder if it is worth a warning, as there is a timeout message later on, which will be printed as dev_dbg only. As other drivers I glimpsed at also don't write anything on NACK, maybe dev_dbg consistency would be preferable. dev_err() for a number of i2c bus errors are too strong, think about the case where a system is having i2cprobe run on it (you will get a lot of errors). It isn't as if the error is lost downstream anyway. + return 0; +} I agree that dev_err() on nack is too strong, most drivers log it at dev_dbg() level. However I fail to see the relation with timeout? A nack isn't a timeout. A timeout would be very wrong and should be reported with dev_err() I think. Oh, BTW, nacks should be reported with -ENXIO according to: http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/i2c-document-standard-fault-codes.patch It might be worth checking that this new driver complies with these freshly adopted error codes standard. Hmm, where ECONREFUSED or EPIPE (if NAK in already selected device) entertained? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [patch 6/8] BAST: Add i2c device list on Simtec Bast
Add i2c boardinfo for the connected i2c devices on the
Simtec Bast.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc4-quilt2/arch/arm/mach-s3c2410/mach-bast.c
===
--- linux-2.6.26-rc4-quilt2.orig/arch/arm/mach-s3c2410/mach-bast.c
2008-05-28 22:37:09.0 +0100
+++ linux-2.6.26-rc4-quilt2/arch/arm/mach-s3c2410/mach-bast.c 2008-05-29
10:20:54.0 +0100
@@ -1,6 +1,6 @@
/* linux/arch/arm/mach-s3c2410/mach-bast.c
*
- * Copyright (c) 2003-2005 Simtec Electronics
+ * Copyright (c) 2003-2005,2008 Simtec Electronics
* Ben Dooks [EMAIL PROTECTED]
*
* http://www.simtec.co.uk/products/EB2410ITX/
@@ -21,6 +21,7 @@
#include linux/platform_device.h
#include linux/dm9000.h
#include linux/ata_platform.h
+#include linux/i2c.h
#include net/ax88796.h
@@ -534,6 +535,23 @@ static struct s3c2410fb_mach_info __init
.default_display = 1,
};
+/* I2C devices fitted. */
+
+static struct i2c_board_info bast_i2c_devs[] __initdata = {
+ {
+ .type = tlv320aic23,
+ .addr = 0x1a,
+ }, {
+ .type = eeprom,
+ .addr = 0x50,
+ }, {
+ .type = simtec-pmu,
+ .addr = 0x6b,
+ }, {
+ .type = ch7013,
+ .addr = 0x75,
+ },
+};
/* Standard BAST devices */
@@ -593,6 +611,9 @@ static void __init bast_init(void)
s3c24xx_fb_set_platdata(bast_fb_info);
platform_add_devices(bast_devices, ARRAY_SIZE(bast_devices));
+ i2c_register_board_info(0, bast_i2c_devs,
+ ARRAY_SIZE(bast_i2c_devs));
+
nor_simtec_init();
}
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [patch 8/8] ANUBIS: Add i2c device list to Simtec Anubis
Add i2c board info initialiser to setup the list of
I2C devices present on an Simtec Anubis.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.26-rc4-quilt1/arch/arm/mach-s3c2440/mach-anubis.c
===
--- linux-2.6.26-rc4-quilt1.orig/arch/arm/mach-s3c2440/mach-anubis.c
2008-05-28 00:04:12.0 +0100
+++ linux-2.6.26-rc4-quilt1/arch/arm/mach-s3c2440/mach-anubis.c 2008-05-28
00:05:42.0 +0100
@@ -1,6 +1,6 @@
/* linux/arch/arm/mach-s3c2440/mach-anubis.c
*
- * Copyright (c) 2003-2005 Simtec Electronics
+ * Copyright (c) 2003-2005,2008 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks [EMAIL PROTECTED]
*
@@ -18,6 +18,7 @@
#include linux/serial_core.h
#include linux/platform_device.h
#include linux/ata_platform.h
+#include linux/i2c.h
#include linux/sm501.h
#include linux/sm501-regs.h
@@ -421,6 +422,19 @@ static struct clk *anubis_clocks[] = {
s3c24xx_uclk,
};
+/* I2C devices. */
+
+static struct i2c_board_info anubis_i2c_info[] __initdata = {
+ {
+ .type = tps65011,
+ .addr = 0x48,
+ .irq= IRQ_EINT20,
+ }, {
+ .type = eeprom,
+ .addr = 0x50,
+ }
+};
+
static void __init anubis_map_io(void)
{
/* initialise the clocks */
@@ -460,6 +474,9 @@ static void __init anubis_map_io(void)
static void __init anubis_init(void)
{
platform_add_devices(anubis_devices, ARRAY_SIZE(anubis_devices));
+
+ i2c_register_board_info(0, anubis_i2c_info,
+ ARRAY_SIZE(anubis_i2c_info));
}
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [patch 2/8] I2C: S3C2410: Add MODULE_ALIAS() for s3c2440 device.
Add a MODULE_ALIAS() statement for the i2c-s3c2410 controller to ensure that it can be autoloaded on the S3C2440 systems that we support. Signed-off-by: Ben Dooks [EMAIL PROTECTED] Index: linux-2.6.26-rc4-quilt1/drivers/i2c/busses/i2c-s3c2410.c === --- linux-2.6.26-rc4-quilt1.orig/drivers/i2c/busses/i2c-s3c2410.c 2008-05-28 11:56:54.0 +0100 +++ linux-2.6.26-rc4-quilt1/drivers/i2c/busses/i2c-s3c2410.c2008-05-28 11:57:12.0 +0100 @@ -947,3 +947,4 @@ MODULE_DESCRIPTION(S3C24XX I2C Bus driv MODULE_AUTHOR(Ben Dooks, [EMAIL PROTECTED]); MODULE_LICENSE(GPL); MODULE_ALIAS(platform:s3c2410-i2c); +MODULE_ALIAS(platform:s3c2440-i2c); -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH][UPDATE] i2c: Add support for virtual I2C adapters
On Wed, May 28, 2008 at 03:30:15PM +0200, Rodolfo Giometti wrote: Hello, I'd like to know why the patches at: http://lists.linuxcoding.com/kernel/2006-q1/msg32516.html have never been applied to the main kernel tree. I'd like to use them and maybe I can update them to the latest kernel version for submission. :) Personally, a quick check over shows that I think there are not bad, and would have a review of it myself (although this is probably not totally under my portion of maintainership). Have you tried contacting the original authour and seeing if it can be resubmitted? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Wanted: i2c subsystem co-maintainer
On Tue, Mar 25, 2008 at 09:50:28AM +0100, Jean Delvare wrote: On Tue, 4 Mar 2008 18:45:12 +0100, Jean Delvare wrote: I have a hard time maintaining the i2c subsystem alone. New drivers and, more importantly, subsystem evolutions are submitted much faster than I can review and merge them. I am hearing complaints about this. It has been lasting for a while now and it doesn't seem like the situation is going to improve. Thus, I think it would be better if someone was co-maintaining the i2c subsystem with me. So, if anyone is interested in co-maintaining the i2c subsystem with me, please let me know. The ideal candidate would come from the embedded world, as I have absolutely no experience with this myself and most of the new drivers are for embedded devices, and should have contributed to the kernel in a significant way already. Ben Dooks agreed to become my co-maintainer for the i2c subsystem. In particular, Ben will help with drivers for embedded systems, of which my experience is inexistent. Thanks Ben and welcome on board! Signed-off-by: Jean Delvare [EMAIL PROTECTED] Acked-by: Ben Dooks [EMAIL PROTECTED] --- Ben, please give by your ack on this patch, then I will push it upstream. Sorry, my main mailbox got hit by a major spam flood, have mostly sorted this out now. MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.25-rc6.orig/MAINTAINERS 2008-03-21 10:58:23.0 +0100 +++ linux-2.6.25-rc6/MAINTAINERS 2008-03-23 15:16:11.0 +0100 @@ -1883,6 +1883,8 @@ S: Maintained I2C SUBSYSTEM P: Jean Delvare M: [EMAIL PROTECTED] +P: Ben Dooks +M: [EMAIL PROTECTED] L: i2c@lm-sensors.org T: quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/ S: Maintained -- Jean Delvare -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] new style i2c client problem: probe () is not called
On Tue, May 13, 2008 at 03:45:29PM +0300, Darius wrote: This code looks OK to me. But which driver handles i2c bus 0? Does your platform code create i2c bus 0? i2c-code will instantiate the ov7670 i2c device when i2c bus 0 is created by i2c_add_numbered_adapter(). So if you don't see it created, I suspect that i2c bus 0 itself is never registered. Thanks, there was the problem. I have modified i2c adapter driver to use i2c_add_numbered_adapter() instead i2c_add_adapter() and pass to the adapter-nr = pdev-id. now probe is called. I'm not so sure this 1:1 mapping of platform to i2c bus ID is such a good idea, what if you have two i2c controllers and want to swap the two of them around? Jean, what do you think about adding my i2c driver to mainline kernel? I've added this to Russel patch tracking system. Now it is a bit ugraded. Should I make new patch and send it here? As a rule, stuff that touches drivers/i2c should be submitted via the i2c list with a cc: to the architecture specific list as a courtesy to the maintainer of that arch. It is not really within Russell (or any other arch maintainer) remit to be actually submitting upstream for drivers/i2c. If a patch really has to touch both drivers/i2c and some other part of the kernel, then it either is up to the architecture maintainer(s) to ack the package for inclusion via the i2c tree, or up to both the i2c and architecture maintainers to get someone like akpm to merge. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH V4] I2C bus driver for IMX
On Tue, May 13, 2008 at 04:07:55PM +0300, Darius wrote:
Changes from previous version:
1. Used i2c_add_numbered_adapter() instead i2c_add_adapter()
2. Added i2c_imx-adapter.class = I2C_CLASS_HWMON;
Signed-off-by: Darius Augulis [EMAIL PROTECTED]
---
As noted in previous email, this part of the patch really is for
information purposes only wrt to the drivers/i2c, and should be
submitted via RMK's patch queue.
Index: linux-2.6.26-rc1/arch/arm/mach-imx/mx1ads.c
===
--- linux-2.6.26-rc1.orig/arch/arm/mach-imx/mx1ads.c
+++ linux-2.6.26-rc1/arch/arm/mach-imx/mx1ads.c
@@ -109,10 +109,31 @@ static struct platform_device imx_uart2_
}
};
+static struct resource imx_i2c_resources[] = {
+ [0] = {
+ .start = 0x00217000,
+ .end= 0x00217010,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = I2C_INT,
+ .end= I2C_INT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device imx_i2c_device = {
+ .name = imx-i2c,
+ .id = 0,
+ .resource = imx_i2c_resources,
+ .num_resources = ARRAY_SIZE(imx_i2c_resources),
+};
+
static struct platform_device *devices[] __initdata = {
cs89x0_device,
imx_uart1_device,
imx_uart2_device,
+ imx_i2c_device,
};
#ifdef CONFIG_MMC_IMX
Index: linux-2.6.26-rc1/drivers/i2c/busses/i2c-imx.c
===
--- /dev/null
+++ linux-2.6.26-rc1/drivers/i2c/busses/i2c-imx.c
@@ -0,0 +1,612 @@
+/*
+ * Copyright (C) 2002 Motorola GSG-China
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ * USA.
+ *
+ * File Name:i2c-imx.c
+ *
+ * Author: Darius Augulis, Teltonika Inc.
+ *
+ * Desc.:Implementation of I2C Adapter/Algorithm Driver
+ * Driver for I2C Bus integrated in i.MXL, i.MX1
+ *
+ * module parameters:
+ * - clkfreq:
+ * Sets the desired clock rate
+ * The default value is 10
+ * Max value is 40
+ * - imxslave:
+ * IMX slave I2C address in decimal format
+ * The default value is 0xAC in hex
+ *
+ * Derived from Motorola GSG China I2C example driver
+ *
+ * Copyright (C) 2002 Motorola GSG-China
+ * Copyright (C) 2005 Torsten Koschorrek koschorrek at
synertronixx.de
+ * Portions:
+ * Copyright (C) 2005 Matthias Blaschke blaschke at
synertronixx.de
+ * Copyright (C) 2007 RightHand Technologies, Inc. adyer at
righthandtech.com
+ * Copyright (C) 2008 Darius Augulis darius.augulis at
teltonika.lt
+ *
+ */
+
+/** Includes
***
+***/
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/fs.h
+#include linux/proc_fs.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/platform_device.h
+
+#include asm/arch/irqs.h
+#include asm/arch/hardware.h
+#include asm/io.h
+
+#include asm/arch/imx-regs.h
+
+/** Defines
+***/
+
+/* This will be the driver name the kernel reports */
+#define DRIVER_NAME imx-i2c
+
+/* Default values of module parameters */
+#define IMX_I2C_SLAVE_ADDR 0xAC
+#define IMX_I2C_BIT_RATE 10 /* 100kHz */
+
+/* Timeouts */
+#define I2C_IMX_TIME_BUSY2000/* loop count */
+#define I2C_IMX_TIME_ACK 2000/* loop count */
+#define I2C_IMX_TIME_TRX 5 /* seconds */
+
+/* Error numbers */
+#define I2C_IMX_ERR_BUSY 1
+#define I2C_IMX_ERR_TX_TIMEOUT 2
+#define I2C_IMX_ERR_RX_TIMEOUT 3
+#define I2C_IMX_ERR_RX_NO_ACK4
Re: [i2c] New style i2c drivers for ALSA SoC
On Mon, May 12, 2008 at 12:57:11PM +1200, Ryan Mallon wrote:
I am writing drivers to support ALSA SoC for an ARM based system. The
system has an i2c codec. I want to use the new style driver for the
codec driver, but I cannot get it to work properly. In my codec driver
(sound/soc/codecs/tlv320aic2x.c) I have:
static struct i2c_driver aic2x_i2c_driver = {
.driver = {
.name = tlv320aic2x,
.owner = THIS_MODULE,
},
.probe = aic2x_i2c_probe,
.remove = aic2x_i2c_remove,
};
static int __init aic2x_init(void)
{
return i2c_add_driver(aic2x_i2c_driver);
}
static void __exit aic2x_exit(void)
{
i2c_del_driver(aic2x_i2c_driver);
}
module_init(aic2x_init);
module_exit(aic2x_exit);
I belive that you need a bit of glue to bind your SoC system
to the codec and audio hardware. ASoC is littered with a number
of examples of how to do it.
Finally, a stylistic question: Should the i2c_board_info (or similar)
for a codec device be defined in the machine initialisation code
(arch/arm/ directory), or in the sound/soc machine file?
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
