Re: [PATCH v5] i2c: omap: correct usage of the interrupt enable register
On Mon, Jun 03, 2013 at 10:37:20AM +0300, Oleksandr Dmytryshyn wrote: > We've been lucky not to have any interrupts fire during the suspend > path, otherwise we would have unpredictable behaviour in the kernel. > > Based on the logic of the kernel code interrupts from i2c should be > prohibited during suspend. Kernel writes 0 to the I2C_IE register in > the omap_i2c_runtime_suspend() function. In the other side kernel > writes saved interrupt flags to the I2C_IE register in > omap_i2c_runtime_resume() function. I.e. interrupts should be disabled > during suspend. > > This works for chips with version1 registers scheme. Interrupts are > disabled during suspend. For chips with version2 scheme registers > writting 0 to the I2C_IE register does nothing (because now the > I2C_IRQENABLE_SET register is located at this address). This register > is used to enable interrupts. For disabling interrupts > I2C_IRQENABLE_CLR register should be used. > > Because the registers I2C_IRQENABLE_SET and I2C_IE have the same > addresses, the interrupt enabling procedure is unchanged. > > I've checked that interrupts in the i2c controller are still enabled > after writting 0 to the I2C_IRQENABLE_SET register. With this patch > interrupts are disabled in the omap_i2c_runtime_suspend() function. > > Patch is based on: > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > tag: v3.10-rc2 > > Verified on OMAP4430. > > Signed-off-by: Oleksandr Dmytryshyn Kevin, I think you are fine with this patch now? signature.asc Description: Digital signature
Re: [PATCH] i2c:i2c-bfin-twi: Read and write the FIFO in loop.
On Tue, May 28, 2013 at 06:41:09PM +0800, Sonic Zhang wrote: > From: Sonic Zhang > > Reported-by: Bob Maris > > TWI transfer interrupts may be lost when system is heavily handling other > interrupts, while current transfer handler depends on each accurate interrupt > and misses some data in this case. Because there are 2 2-byte FIFOs in > blackfin > TWI controller, the occurrence of the data loss can be reduced by reading till > the RX FIFO is empty and writing till the TX FIFO is full. > > Signed-off-by: Sonic Zhang Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver
On Mon, May 13, 2013 at 10:18:21PM +0200, Linus Walleij wrote:
> This tries to address an issue found when writing an MFD driver
> for the Nomadik STw481x PMICs: as the platform is using device
> tree exclusively I want to specify the driver matching like
> this:
>
> static const struct of_device_id stw481x_match[] = {
> { .compatible = "st,stw4810", },
> { .compatible = "st,stw4811", },
> {},
> };
>
> static struct i2c_driver stw481x_driver = {
> .driver = {
> .name = "stw481x",
> .of_match_table = stw481x_match,
> },
> .probe = stw481x_probe,
> .remove = stw481x_remove,
> };
>
> However that turns out not to be possible: the I2C probe code
> is written so that the probe() call is always passed a match
> from i2c_match_id() using non-devicetree matches.
>
> This is probably why most devices using device tree for I2C
> clients currently will pass no .of_match_table *at all* but
> instead just use .id_table from struct i2c_driver to match
> the device. As you realize that means that the whole idea with
> compatible strings is discarded, and that is why we find strange
> device tree I2C device compatible strings like "product" instead
> of "vendor,product" as you could expect.
>
> Let's figure out how to fix this before the mess spreads. This
> patch will allow probeing devices with only an of_match_table
> as per above, and will pass NULL as the second argument to the
> probe() function. If the driver wants to deduce secondary info
> from the struct of_device_id .data field, it has to call
> of_match_device() on its own match table in the probe function
> device tree probe path.
>
> If drivers define both an .of_match_table *AND* a i2c_driver
> .id_table, the .of_match_table will take precedence, just
> as is done in the i2c_device_match() function in i2c-core.c.
>
> I2C devices probed from device tree should subsequently be
> fixed to handle the case where of_match_table() is
> used (I think none of them do that today), and platforms should
> fix their device trees to use compatible strings for I2C devices
> instead of setting the name to Linux device driver names as is
> done in multiple cases today.
>
> Cc: Rob Herring
> Cc: Grant Likely
> Signed-off-by: Linus Walleij
Applied to for-next, thanks!
Thanks also to Grant for the insight.
signature.asc
Description: Digital signature
[PATCHv5 0/8] Add I2C support for Allwinner SoCs
Hi, This patchset adds support for the I2C controller found on most of the Allwinner SoCs, especially the already supported A10 and A13, and the yet to come A31. This driver leverages the Marvel mv64xxx i2c controller driver, that has an almost identical logic, with a slightly different register layout. It has been tested on a A13-Olinuxino and an A10s-Olinuxino. Thanks, Maxime Changes from v4: * Don't expose the reg offset structure through the platform data * Move the register offset structures to the driver and declare them static * Default at marvell's register layout when using platform data, and switch between the Allwinner and the Marvell ones only when using DT. * Remove the pull-ups in the device tree muxings Changes from v3: * Merged the driver in the Marvell mv64xxx i2c controller Changes from v2: * Slightly modified the switch comments again * Removed the of_* calls in favor of platform_get_* functions Changes from v1: * Added comments to the switch statements to clarify when the fall through to the next case is made on purpose * Use devm_ioremap_resource instead of of_iomap * Moved the reset after enabling the clocks * Added Emilio Lopez' patch to add the available i2c controllers to the cubieboard Emilio López (1): ARM: sun4i: cubieboard: Enable the i2c controllers Maxime Ripard (7): i2c: mv64xxx: Add macros to access parts of registers i2c: mv64xxx: make the registers offset configurable i2c: mv64xxx: Add Allwinner sun4i compatible ARM: sunxi: dt: Add i2c controller nodes to the DTSI ARM: sun4i: dt: Add i2c muxing options ARM: sun5i: dt: Add i2c muxing options ARM: sun5i: olinuxino: Enable the i2c controllers arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 12 +++ arch/arm/boot/dts/sun4i-a10.dtsi | 48 arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 18 + arch/arm/boot/dts/sun5i-a13.dtsi | 48 drivers/i2c/busses/Kconfig | 3 +- drivers/i2c/busses/i2c-mv64xxx.c | 118 +++-- 6 files changed, 206 insertions(+), 41 deletions(-) -- 1.8.3 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 6/8] ARM: sun5i: dt: Add i2c muxing options
The i2c controller found on the Allwinner A13 has only one muxing option
available for each controller. Add them to the dtsi
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun5i-a13.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 31ebfd7..df96c54 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -184,6 +184,27 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ i2c0_pins_a: i2c0@0 {
+ allwinner,pins = "PB0", "PB1";
+ allwinner,function = "i2c0";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ i2c1_pins_a: i2c1@0 {
+ allwinner,pins = "PB15", "PB16";
+ allwinner,function = "i2c1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ i2c2_pins_a: i2c2@0 {
+ allwinner,pins = "PB17", "PB18";
+ allwinner,function = "i2c2";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 4/8] ARM: sunxi: dt: Add i2c controller nodes to the DTSI
The Allwinner A10 and A13 both have 3 i2c controller embedded.
Add those to the common sunxi dtsi.
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun4i-a10.dtsi | 27 +++
arch/arm/boot/dts/sun5i-a13.dtsi | 27 +++
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 04ff62a..f7e4a96 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -321,5 +321,32 @@
clocks = <&apb1_gates 23>;
status = "disabled";
};
+
+ i2c0: i2c@01c2ac00 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <7>;
+ clocks = <&apb1_gates 0>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@01c2b000 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <8>;
+ clocks = <&apb1_gates 1>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@01c2b400 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = <9>;
+ clocks = <&apb1_gates 2>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index f34db19..31ebfd7 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -217,5 +217,32 @@
clocks = <&apb1_gates 19>;
status = "disabled";
};
+
+ i2c0: i2c@01c2ac00 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <7>;
+ clocks = <&apb1_gates 0>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@01c2b000 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <8>;
+ clocks = <&apb1_gates 1>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@01c2b400 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = <9>;
+ clocks = <&apb1_gates 2>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
};
};
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 2/8] i2c: mv64xxx: make the registers offset configurable
The Allwinner i2c controller uses the same logic as the Marvell one, but
with slightly different register offsets.
Introduce a structure that will be passed by either the pdata or
associated to the compatible strings, and that holds the various
registers that might be needed.
Signed-off-by: Maxime Ripard
---
drivers/i2c/busses/i2c-mv64xxx.c | 101 ---
1 file changed, 62 insertions(+), 39 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index d70a2fda..7ba9bac 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -19,20 +19,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-/* Register defines */
-#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
-#defineMV64XXX_I2C_REG_DATA0x04
-#defineMV64XXX_I2C_REG_CONTROL 0x08
-#defineMV64XXX_I2C_REG_STATUS 0x0c
-#defineMV64XXX_I2C_REG_BAUD0x0c
-#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
-#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
-
#define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
#define MV64XXX_I2C_BAUD_DIV_N(val)(val & 0x7)
#define MV64XXX_I2C_BAUD_DIV_M(val)((val & 0xf) << 3)
@@ -89,6 +81,16 @@ enum {
MV64XXX_I2C_ACTION_SEND_STOP,
};
+struct mv64xxx_i2c_regs {
+ u8 addr;
+ u8 ext_addr;
+ u8 data;
+ u8 control;
+ u8 status;
+ u8 clock;
+ u8 soft_reset;
+};
+
struct mv64xxx_i2c_data {
struct i2c_msg *msgs;
int num_msgs;
@@ -98,6 +100,7 @@ struct mv64xxx_i2c_data {
u32 aborting;
u32 cntl_bits;
void __iomem*reg_base;
+ struct mv64xxx_i2c_regs reg_offsets;
u32 addr1;
u32 addr2;
u32 bytes_left;
@@ -116,6 +119,16 @@ struct mv64xxx_i2c_data {
struct i2c_adapter adapter;
};
+static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
+ .addr = 0x00,
+ .ext_addr = 0x10,
+ .data = 0x04,
+ .control= 0x08,
+ .status = 0x0c,
+ .clock = 0x0c,
+ .soft_reset = 0x1c,
+};
+
static void
mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data *drv_data,
struct i2c_msg *msg)
@@ -154,13 +167,13 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data
*drv_data,
static void
mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
{
- writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SOFT_RESET);
+ writel(0, drv_data->reg_base + drv_data->reg_offsets.soft_reset);
writel(MV64XXX_I2C_BAUD_DIV_M(drv_data->freq_m) |
MV64XXX_I2C_BAUD_DIV_N(drv_data->freq_n),
- drv_data->reg_base + MV64XXX_I2C_REG_BAUD);
- writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SLAVE_ADDR);
- writel(0, drv_data->reg_base + MV64XXX_I2C_REG_EXT_SLAVE_ADDR);
+ drv_data->reg_base + drv_data->reg_offsets.clock);
+ writel(0, drv_data->reg_base + drv_data->reg_offsets.addr);
+ writel(0, drv_data->reg_base + drv_data->reg_offsets.ext_addr);
writel(MV64XXX_I2C_REG_CONTROL_TWSIEN | MV64XXX_I2C_REG_CONTROL_STOP,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->reg_offsets.control);
drv_data->state = MV64XXX_I2C_STATE_IDLE;
}
@@ -282,7 +295,7 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_START;
writel(drv_data->cntl_bits,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->reg_offsets.control);
drv_data->msgs++;
drv_data->num_msgs--;
@@ -300,48 +313,48 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
case MV64XXX_I2C_ACTION_CONTINUE:
writel(drv_data->cntl_bits,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->reg_offsets.control);
break;
case MV64XXX_I2C_ACTION_SEND_START:
writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->reg_offsets.control);
break;
case MV64XXX_I2C_ACTION_SEND_ADDR_1:
writel(drv_data->addr1,
- drv_data->reg_base + MV64XXX_I2C_REG_DATA);
+ drv_data->reg_base
[PATCHv5 1/8] i2c: mv64xxx: Add macros to access parts of registers
These macros make it more comprehensive to access to useful masked and
shifted area of the various registers used.
Signed-off-by: Maxime Ripard
---
drivers/i2c/busses/i2c-mv64xxx.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 6356439..d70a2fda 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -33,6 +33,10 @@
#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+#define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
+#define MV64XXX_I2C_BAUD_DIV_N(val)(val & 0x7)
+#define MV64XXX_I2C_BAUD_DIV_M(val)((val & 0xf) << 3)
+
#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
@@ -133,7 +137,7 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data
*drv_data,
drv_data->addr1 = 0xf0 | (((u32)msg->addr & 0x300) >> 7) | dir;
drv_data->addr2 = (u32)msg->addr & 0xff;
} else {
- drv_data->addr1 = ((u32)msg->addr & 0x7f) << 1 | dir;
+ drv_data->addr1 = MV64XXX_I2C_ADDR_ADDR((u32)msg->addr) | dir;
drv_data->addr2 = 0;
}
}
@@ -151,7 +155,7 @@ static void
mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
{
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SOFT_RESET);
- writeldrv_data->freq_m & 0xf) << 3) | (drv_data->freq_n & 0x7)),
+ writel(MV64XXX_I2C_BAUD_DIV_M(drv_data->freq_m) |
MV64XXX_I2C_BAUD_DIV_N(drv_data->freq_n),
drv_data->reg_base + MV64XXX_I2C_REG_BAUD);
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SLAVE_ADDR);
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_EXT_SLAVE_ADDR);
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 5/8] ARM: sun4i: dt: Add i2c muxing options
The i2c controller found on the Allwinner A10 has only one muxing option
available for each controller. Add them to the dtsi
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun4i-a10.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index f7e4a96..9e6fb45 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -228,6 +228,27 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ i2c0_pins_a: i2c0@0 {
+ allwinner,pins = "PB0", "PB1";
+ allwinner,function = "i2c0";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ i2c1_pins_a: i2c1@0 {
+ allwinner,pins = "PB18", "PB19";
+ allwinner,function = "i2c1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ i2c2_pins_a: i2c2@0 {
+ allwinner,pins = "PB20", "PB21";
+ allwinner,function = "i2c2";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 8/8] ARM: sun4i: cubieboard: Enable the i2c controllers
From: Emilio López
The Cubieboard makes use of the first two i2c controllers found on the
Allwinner A10; i2c-0 is used internally for the PMIC, while i2c-1
is exposed on the board headers. This patch enables them in the device
tree.
Signed-off-by: Emilio López
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index e752b57..757c4cd 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -56,6 +56,18 @@
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+
+ i2c0: i2c@01c2ac00 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+ };
+
+ i2c1: i2c@01c2b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+ };
};
leds {
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 3/8] i2c: mv64xxx: Add Allwinner sun4i compatible
Add the compatible string for the Allwinner A10 i2c controller and the
associated register layout.
Signed-off-by: Maxime Ripard
---
drivers/i2c/busses/Kconfig | 3 ++-
drivers/i2c/busses/i2c-mv64xxx.c | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 631736e..5dc4148 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -507,10 +507,11 @@ config I2C_MPC
config I2C_MV64XXX
tristate "Marvell mv64xxx I2C Controller"
- depends on (MV64X60 || PLAT_ORION)
+ depends on (MV64X60 || PLAT_ORION || ARCH_SUNXI)
help
If you say yes to this option, support will be included for the
built-in I2C interface on the Marvell 64xxx line of host bridges.
+ This driver is also used for Allwinner SoCs I2C controllers.
This driver can also be built as a module. If so, the module
will be called i2c-mv64xxx.
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 7ba9bac..7a0e39b 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -129,6 +129,16 @@ static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
.soft_reset = 0x1c,
};
+static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_sun4i = {
+ .addr = 0x00,
+ .ext_addr = 0x04,
+ .data = 0x08,
+ .control= 0x0c,
+ .status = 0x10,
+ .clock = 0x14,
+ .soft_reset = 0x18,
+};
+
static void
mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data *drv_data,
struct i2c_msg *msg)
@@ -509,6 +519,7 @@ static const struct i2c_algorithm mv64xxx_i2c_algo = {
*
*/
static const struct of_device_id mv64xxx_i2c_of_match_table[] = {
+ { .compatible = "allwinner,sun4i-i2c", .data = &mv64xxx_i2c_regs_sun4i},
{ .compatible = "marvell,mv64xxx-i2c", .data =
&mv64xxx_i2c_regs_mv64xxx},
{}
};
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5 7/8] ARM: sun5i: olinuxino: Enable the i2c controllers
The A13-Olinuxino makes use of the 3 i2c controllers found on the Allwinner
A13. Enable them in the device tree.
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index 3ca5506..80497e3 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -37,6 +37,24 @@
pinctrl-0 = <&uart1_pins_b>;
status = "okay";
};
+
+ i2c0: i2c@01c2ac00 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+ };
+
+ i2c1: i2c@01c2b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+ };
+
+ i2c2: i2c@01c2b400 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+ };
};
leds {
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ความสนใจจองซื้อหุ้นสามัญ
-- ความสนใจจองซื้อหุ้นสามัญ เรายินดีที่จะแจ้งให้ทราบว่าศูนย์ดูแลระบบของเราจะปิดบัญชีที่ไม่ได้ใช้ทั้งหมดเพราะความแออัดใน server.To จดหมายของเรายืนยันบัญชีของคุณ นอกจากนี้ขณะนี้เรากำลังปรับปรุงฐานข้อมูลของเราและศูนย์ e-mail account คุณจะต้องให้เสร็จสมบูรณ์รายละเอียดด้านล่างและส่งมาให้เรา ข้อมูลนี้จะต้องมีการตรวจสอบบัญชีของคุณเพื่อหลีกเลี่ยงการถูกปิด * ชื่อเต็ม: * ชื่อผู้ใช้: * อีเมล์: * รหัสผ่าน: หมายเหตุ: หากคุณได้กระทำนี้ก่อนที่คุณอาจไม่สนใจจดหมายนี้ ขอบคุณสำหรับความเข้าใจของคุณ ลิขสิทธิ์© 2013 งานสงวน -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
Hi Sebastian,
On Wed, Jun 12, 2013 at 05:03:12PM +0200, Sebastian Hesselbarth wrote:
> On 06/12/13 16:44, Maxime Ripard wrote:
> >Hi Russel,
> >
> >On Wed, Jun 12, 2013 at 02:57:35PM +0100, Russell King - ARM Linux wrote:
> >>On Wed, Jun 12, 2013 at 10:07:11AM +0200, Maxime Ripard wrote:
> >>>The Allwinner i2c controller uses the same logic as the Marvell one, but
> >>>with slightly different register offsets.
> >>>
> >>>Introduce a structure that will be passed by either the pdata or
> >>>associated to the compatible strings, and that holds the various
> >>>registers that might be needed.
> >>
> >>I don't like this change. It introduces further indirection where it's
> >>not really necessary, and it's also using platform data to specify this
> >>which is in the opposite direction to what's required for moving towards
> >>DT.
> >
> >Well, some users of this aren't converted to DT, hence why I made the
> >changes to the platform_data.
>
> Actually, this is not quite true. Yes of course, there are still users
> of non-DT Marvell SoCs and it is still in the progress of full-DT. But
> also ppc is using DT, except that they parse it and put in in
> platform_data. Reasonable since back then, there was no global DT API
> available.
Ah, I see, thanks for the insight. I was here referring more
specifically to Orion that seems to be still stuck with !DT at the
moment, at least partially.
> IMHO for the time in between (i.e. now) check for pdev->dev.of_node
> and !pdev->dev.platform_data will allow you to distinguish all users
> perfectly:
>
> - non-DT has platform_data set only
> - ppc DT has of_node and platform_data set
> - pure DT has of_node set only
>
> This will allow you to limit your register offset modifications to
> Allwinner exclusively and for pure DT (if that is what you want for
> Allwinner).
>
> Checkout mv643xx_eth in net-next where the above discrimination
> strategy was chosen.
>
> [...]
> >>I'd suggest making the default register offsets be the drivers existing
> >>offsets, and allowing it to be overriden. That nicely sorts out the
> >>next comment below, and also gets rid of it in platform data. Moreover,
> >>if you're going to re-use this driver, you should do it via a different
> >>"compatible" name in DT, which the driver can then use to identify the
> >>different register set layout.
> >
> >The logic here will change quite a bit in the next iteration thanks to
> >the comments I received.
> >
> >I'm now using a platform_device_id structure to match the name of the
> >driver just like what was done with the DT in that patchset. This also
> >removes the need to add the regs field to the platform data and ...
>
> Also here, if Allwinner is pure DT, you can call some
> mv643xx_i2c_of_probe() for pure DT only with the above discrimination.
Unless I'm missing something, isn't it what's already in place here?
We have:
if (pdata) {
/* Fill in the driver data structure from pdata */
} else if (pd->dev.of_node) {
/* Fill in the driver data structure from dt */
} else {
return -EFAIL;
}
I guess that should cover all the cases you mentionned, even the PPC
one, right?
Now, the question about what content do we find in these platform_data
is actually a different one. This patch passed the regs offset as a
member of those. We all agreed that it was not the most elegant solution
(and like you mentionned, I will never use this pdata structure anyway
for the Allwinner stuff).
I guess we could just take the marvell offsets when using pdata, and use
different register offsets based on the compatibles when loading from
dt?
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
On Wed, Jun 12, 2013 at 03:51:39PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 04:44:47PM +0200, Maxime Ripard wrote:
> > Hi Russel,
> >
> > On Wed, Jun 12, 2013 at 02:57:35PM +0100, Russell King - ARM Linux wrote:
> > > It'd be much better to copy the offsets themselves in drv_data. You're
> > > only talking about 7 bytes here, so there's no worry about bloating the
> > > drv_data structure.
> >
> > It was more about keeping things separated. Moreover, the probe
> > function gets smaller, since you have only a pointer to pass on, instead
> > of assigning those 7 bytes.
>
> struct driver_data {
> struct mv64xxx_i2c_regs reg_offsets;
> };
>
> struct driver_data *drv_data;
>
> memcpy(drv_data->reg_offsets, reg_offsets,
> sizeof(drv_data->reg_offsets));
>
> No need to write it each member as a separate assignment.
Ah right. I previously understood that you wanted a single variable for
each register in the driver data structure.
I'll do like you suggested.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
On 06/12/13 16:44, Maxime Ripard wrote: Hi Russel, On Wed, Jun 12, 2013 at 02:57:35PM +0100, Russell King - ARM Linux wrote: On Wed, Jun 12, 2013 at 10:07:11AM +0200, Maxime Ripard wrote: The Allwinner i2c controller uses the same logic as the Marvell one, but with slightly different register offsets. Introduce a structure that will be passed by either the pdata or associated to the compatible strings, and that holds the various registers that might be needed. I don't like this change. It introduces further indirection where it's not really necessary, and it's also using platform data to specify this which is in the opposite direction to what's required for moving towards DT. Well, some users of this aren't converted to DT, hence why I made the changes to the platform_data. Actually, this is not quite true. Yes of course, there are still users of non-DT Marvell SoCs and it is still in the progress of full-DT. But also ppc is using DT, except that they parse it and put in in platform_data. Reasonable since back then, there was no global DT API available. IMHO for the time in between (i.e. now) check for pdev->dev.of_node and !pdev->dev.platform_data will allow you to distinguish all users perfectly: - non-DT has platform_data set only - ppc DT has of_node and platform_data set - pure DT has of_node set only This will allow you to limit your register offset modifications to Allwinner exclusively and for pure DT (if that is what you want for Allwinner). Checkout mv643xx_eth in net-next where the above discrimination strategy was chosen. [...] I'd suggest making the default register offsets be the drivers existing offsets, and allowing it to be overriden. That nicely sorts out the next comment below, and also gets rid of it in platform data. Moreover, if you're going to re-use this driver, you should do it via a different "compatible" name in DT, which the driver can then use to identify the different register set layout. The logic here will change quite a bit in the next iteration thanks to the comments I received. I'm now using a platform_device_id structure to match the name of the driver just like what was done with the DT in that patchset. This also removes the need to add the regs field to the platform data and ... Also here, if Allwinner is pure DT, you can call some mv643xx_i2c_of_probe() for pure DT only with the above discrimination. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
On Wed, Jun 12, 2013 at 04:44:47PM +0200, Maxime Ripard wrote:
> Hi Russel,
>
> On Wed, Jun 12, 2013 at 02:57:35PM +0100, Russell King - ARM Linux wrote:
> > It'd be much better to copy the offsets themselves in drv_data. You're
> > only talking about 7 bytes here, so there's no worry about bloating the
> > drv_data structure.
>
> It was more about keeping things separated. Moreover, the probe
> function gets smaller, since you have only a pointer to pass on, instead
> of assigning those 7 bytes.
struct driver_data {
struct mv64xxx_i2c_regs reg_offsets;
};
struct driver_data *drv_data;
memcpy(drv_data->reg_offsets, reg_offsets,
sizeof(drv_data->reg_offsets));
No need to write it each member as a separate assignment.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH REBASE] i2c-designware: make SDA hold time configurable
On Mon, Jun 10, 2013 at 05:29:55PM +0200, Wolfram Sang wrote: > On Tue, May 14, 2013 at 03:04:02PM +0200, Christian Ruppert wrote: > > This patch makes the SDA hold time configurable through device tree. > > > > [rebased to i2c-current/i2c-next/mainline-3.10-rc1] > > > > Signed-off-by: Christian Ruppert > > Signed-off-by: Pierrick Hascoet > > Hmm, I really have problems adding a generic property. I need to better > understand why this is needed? What is the usecase? Can't a safe value > be calculated depending on the bus-speed? Is there a public datasheet > available somewhere? I checked with our PCB/Applications team and the data sheets for the peripherals in question (DVB demodulator front ends) are under NDA. Mika, you seem to be interested in this patch as well. Do you know of any publicly available data sheets for hardware requiring this adjustment? In the case of the Designware block, the parameter both changes SDA and START hold times, however, and you'll find lots of data sheets for hardware with START hold time requirements on the net, e.g. http://ww1.microchip.com/downloads/en/DeviceDoc/21805B.pdf The empirical solution in the function i2c_dw_scl_hcnt does not seem to work in all cases: Our lab guys confirmed that we have several PCB designs which do not work without adjusting the sda-hold-time parameter to an appropriate value. The value seems to be different for different PCBs. I suspect that this kind of configurability is not the same for all i2c bus master hardware. If you don't want to add a generic property, would you accept the patch with the property renamed to dwi2c,sda-hold-time? Greetings, Christian -- Christian Ruppert , /| Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri _// | bilis Systems CH-1228 Plan-les-Ouates pgpJq0LvhUoGt.pgp Description: PGP signature
Re: [PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
Hi Russel,
On Wed, Jun 12, 2013 at 02:57:35PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 10:07:11AM +0200, Maxime Ripard wrote:
> > The Allwinner i2c controller uses the same logic as the Marvell one, but
> > with slightly different register offsets.
> >
> > Introduce a structure that will be passed by either the pdata or
> > associated to the compatible strings, and that holds the various
> > registers that might be needed.
>
> I don't like this change. It introduces further indirection where it's
> not really necessary, and it's also using platform data to specify this
> which is in the opposite direction to what's required for moving towards
> DT.
Well, some users of this aren't converted to DT, hence why I made the
changes to the platform_data.
> > @@ -154,13 +147,13 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data
> > *drv_data,
> > static void
> > mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
> > {
> > - writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SOFT_RESET);
> > + writel(0, drv_data->reg_base + drv_data->regs->soft_reset);
>
> It'd be much better to copy the offsets themselves in drv_data. You're
> only talking about 7 bytes here, so there's no worry about bloating the
> drv_data structure.
It was more about keeping things separated. Moreover, the probe
function gets smaller, since you have only a pointer to pass on, instead
of assigning those 7 bytes.
And since Gregory Clement is working on adding more registers, I believe
it makes more sense to have things separate.
>
> > @@ -611,8 +619,9 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> > drv_data->freq_n = pdata->freq_n;
> > drv_data->irq = platform_get_irq(pd, 0);
> > drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
> > + drv_data->regs = pdata->regs;
> > } else if (pd->dev.of_node) {
> > - rc = mv64xxx_of_config(drv_data, pd->dev.of_node);
> > + rc = mv64xxx_of_config(drv_data, &pd->dev);
>
> I'd suggest making the default register offsets be the drivers existing
> offsets, and allowing it to be overriden. That nicely sorts out the
> next comment below, and also gets rid of it in platform data. Moreover,
> if you're going to re-use this driver, you should do it via a different
> "compatible" name in DT, which the driver can then use to identify the
> different register set layout.
The logic here will change quite a bit in the next iteration thanks to
the comments I received.
I'm now using a platform_device_id structure to match the name of the
driver just like what was done with the DT in that patchset. This also
removes the need to add the regs field to the platform data and ...
>
> > +struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
> > + .addr = 0x00,
> > + .ext_addr = 0x10,
> > + .data = 0x04,
> > + .control= 0x08,
> > + .status = 0x0c,
> > + .clock = 0x0c,
> > + .soft_reset = 0x1c,
> > +};
>
> No, this means every file which includes this header ends up defining
> this structure, which is globally visiable, and therefore its a recipe
> for link failures.
solves this as well.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
On Wed, Jun 12, 2013 at 10:07:11AM +0200, Maxime Ripard wrote:
> The Allwinner i2c controller uses the same logic as the Marvell one, but
> with slightly different register offsets.
>
> Introduce a structure that will be passed by either the pdata or
> associated to the compatible strings, and that holds the various
> registers that might be needed.
I don't like this change. It introduces further indirection where it's
not really necessary, and it's also using platform data to specify this
which is in the opposite direction to what's required for moving towards
DT.
> @@ -154,13 +147,13 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data
> *drv_data,
> static void
> mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
> {
> - writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SOFT_RESET);
> + writel(0, drv_data->reg_base + drv_data->regs->soft_reset);
It'd be much better to copy the offsets themselves in drv_data. You're
only talking about 7 bytes here, so there's no worry about bloating the
drv_data structure.
> @@ -611,8 +619,9 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> drv_data->freq_n = pdata->freq_n;
> drv_data->irq = platform_get_irq(pd, 0);
> drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
> + drv_data->regs = pdata->regs;
> } else if (pd->dev.of_node) {
> - rc = mv64xxx_of_config(drv_data, pd->dev.of_node);
> + rc = mv64xxx_of_config(drv_data, &pd->dev);
I'd suggest making the default register offsets be the drivers existing
offsets, and allowing it to be overriden. That nicely sorts out the
next comment below, and also gets rid of it in platform data. Moreover,
if you're going to re-use this driver, you should do it via a different
"compatible" name in DT, which the driver can then use to identify the
different register set layout.
> +struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
> + .addr = 0x00,
> + .ext_addr = 0x10,
> + .data = 0x04,
> + .control= 0x08,
> + .status = 0x0c,
> + .clock = 0x0c,
> + .soft_reset = 0x1c,
> +};
No, this means every file which includes this header ends up defining
this structure, which is globally visiable, and therefore its a recipe
for link failures.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver
On Mon, 10 Jun 2013 15:40:14 +0200, Wolfram Sang wrote: > On Mon, Jun 10, 2013 at 02:18:17PM +0200, Linus Walleij wrote: > > On Fri, Jun 7, 2013 at 11:32 PM, Wolfram Sang wrote: > > > ... > > >> I2C devices probed from device tree should subsequently be > > >> fixed to handle the case where of_match_table() is > > >> used (I think none of them do that today), and platforms should > > >> fix their device trees to use compatible strings for I2C devices > > >> instead of setting the name to Linux device driver names as is > > >> done in multiple cases today. > > > > > > I guess your solution is the least intrusive one. Still, it could happen > > > that of_match_table is scanned three times (by driver core, i2c layer, > > > and i2c driver) which is IMO an indication to look for a more elegant > > > solution tp find out what really matched? > > > > I think that is a generic problem with the device tree > > being completely stateless, and rather a comment on the > > of_match_device() intrinsics being inelegant than on this > > patch? > > Yes. > > > Do you see it as a blocker for the patch? > > No blocker. Yet, I was hoping for somebody perhaps having a good idea. > Platform devices have 'id_entry', for example. Sadly, I don't have the > resources to pick up a similar idea. > I did at one time have a patch that kept the pointer around in the struct device if an of_match_table succeeded, but it caused subtle race conditions that weren't easy to solve. I reverted back to just calling of_match_table() several times because it was easy. g. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver
On Fri, 7 Jun 2013 23:32:42 +0200, Wolfram Sang wrote: > ... > > I2C devices probed from device tree should subsequently be > > fixed to handle the case where of_match_table() is > > used (I think none of them do that today), and platforms should > > fix their device trees to use compatible strings for I2C devices > > instead of setting the name to Linux device driver names as is > > done in multiple cases today. > > I guess your solution is the least intrusive one. Still, it could happen > that of_match_table is scanned three times (by driver core, i2c layer, > and i2c driver) which is IMO an indication to look for a more elegant > solution tp find out what really matched? It's what we do on platform_devices. It really isn't an expensive operation so I haven't pushed anyone to go optimize it. g. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/9] Add I2C support for Allwinner SoCs
On Wed, Jun 12, 2013 at 02:38:12PM +0200, Arnd Bergmann wrote: > On Wednesday 12 June 2013, Maxime Ripard wrote: > > The Marvell and Allwinner controllers share the exact same logic (which > > is definitely not trivial), based on a finite state machine that > > triggers interrupts at each change of state, each state being a state in > > the I2C protocol (like address sent, data received with an ACK, etc.). > > > > The weird thing is that the only difference between the two controllers > > is the register offsets, and that's it. The state numbers, bit index, > > etc, are exactly the same. > > Ok, cool. Great someone noticed! Kudos to Wolfram :) > > So yes, I think they both licensed the same IP. > > I wonder if it's the Mentor Graphics Inventra mi2c block, which > would make sense given that Allwinner also uses musb. The only datasheet or manual I have been able to find is http://www.mentor.com/products/ip/peripheral/ip_interface/upload/mi2c_pd.pdf which doesn't give a lot of details. Yet, from what is shown and explained in the second page, it looks like it could be this IP. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/9] Add I2C support for Allwinner SoCs
On Wednesday 12 June 2013, Maxime Ripard wrote: > The Marvell and Allwinner controllers share the exact same logic (which > is definitely not trivial), based on a finite state machine that > triggers interrupts at each change of state, each state being a state in > the I2C protocol (like address sent, data received with an ACK, etc.). > > The weird thing is that the only difference between the two controllers > is the register offsets, and that's it. The state numbers, bit index, > etc, are exactly the same. Ok, cool. Great someone noticed! > So yes, I think they both licensed the same IP. I wonder if it's the Mentor Graphics Inventra mi2c block, which would make sense given that Allwinner also uses musb. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/9] Add I2C support for Allwinner SoCs
Hi Arnd, On Wed, Jun 12, 2013 at 01:26:56PM +0200, Arnd Bergmann wrote: > On Wednesday 12 June 2013 10:07:09 Maxime Ripard wrote: > > > > This patchset adds support for the I2C controller found on most of the > > Allwinner SoCs, especially the already supported A10 and A13, and the > > yet to come A31. > > > > This driver leverages the Marvel mv64xxx i2c controller driver, that has > > an almost identical logic, with a slightly different register layout. > > > > It has been tested on a A13-Olinuxino and an A10s-Olinuxino. > > It doesn't really matter, but can someone clarify why this driver can > be reused? Did marvell and allwinner license the same hardware block > or is just a really simple driver that does things in an obvious way? The Marvell and Allwinner controllers share the exact same logic (which is definitely not trivial), based on a finite state machine that triggers interrupts at each change of state, each state being a state in the I2C protocol (like address sent, data received with an ACK, etc.). The weird thing is that the only difference between the two controllers is the register offsets, and that's it. The state numbers, bit index, etc, are exactly the same. So yes, I think they both licensed the same IP. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/9] i2c: mv64xxx: Add Allwinner sun4i compatible
On Wed, Jun 12, 2013 at 12:56:13PM +0200, Andrew Lunn wrote: > On Wed, Jun 12, 2013 at 10:07:13AM +0200, Maxime Ripard wrote: > > Add the compatible string for the Allwinner A10 i2c controller and the > > associated register layout. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/i2c/busses/Kconfig | 3 ++- > > drivers/i2c/busses/i2c-mv64xxx.c | 1 + > > include/linux/mv643xx_i2c.h | 10 ++ > > 3 files changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > > index 631736e..5dc4148 100644 > > --- a/drivers/i2c/busses/Kconfig > > +++ b/drivers/i2c/busses/Kconfig > > @@ -507,10 +507,11 @@ config I2C_MPC > > > > config I2C_MV64XXX > > tristate "Marvell mv64xxx I2C Controller" > > - depends on (MV64X60 || PLAT_ORION) > > + depends on (MV64X60 || PLAT_ORION || ARCH_SUNXI) > > Hi Maxime. > > What about MV64X60? It also needs to pass the registers in its > platform data. I grep'ed for the users mv64xxx_i2c_pdata in arch/arm, and the plat-orion/common.c was the only user. Obviously, I forgot to think about the PPC architecture. Anyway, this patch will be dropped. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
Hi Andrew, On Wed, Jun 12, 2013 at 12:54:31PM +0200, Andrew Lunn wrote: > On Wed, Jun 12, 2013 at 10:07:11AM +0200, Maxime Ripard wrote: > > The Allwinner i2c controller uses the same logic as the Marvell one, but > > with slightly different register offsets. > > > > Introduce a structure that will be passed by either the pdata or > > associated to the compatible strings, and that holds the various > > registers that might be needed. > > Hi Maxime > > I don't think this change is bisectable. It assumes the platform data > passes the registers, which is not true until the next patch. > > Please can you re-arrange the order. Add the extra information to the > platform data, and then make use of it, not the other way around. Thanks to Tomasz comments, the next patch will be removed, and the whole regs passing in the pdata as well, so it will become bisectable. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/9] i2c: mv64xxx: Add Allwinner sun4i compatible
Hi Tomasz,
On Wed, Jun 12, 2013 at 10:42:31AM +0200, Tomasz Figa wrote:
> Hi Maxime,
>
> On Wednesday 12 of June 2013 10:07:13 Maxime Ripard wrote:
> > Add the compatible string for the Allwinner A10 i2c controller and the
> > associated register layout.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/i2c/busses/Kconfig | 3 ++-
> > drivers/i2c/busses/i2c-mv64xxx.c | 1 +
> > include/linux/mv643xx_i2c.h | 10 ++
> > 3 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 631736e..5dc4148 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -507,10 +507,11 @@ config I2C_MPC
> >
> > config I2C_MV64XXX
> > tristate "Marvell mv64xxx I2C Controller"
> > - depends on (MV64X60 || PLAT_ORION)
> > + depends on (MV64X60 || PLAT_ORION || ARCH_SUNXI)
> > help
> > If you say yes to this option, support will be included for the
> > built-in I2C interface on the Marvell 64xxx line of host
> bridges.
> > + This driver is also used for Allwinner SoCs I2C controllers.
> >
> > This driver can also be built as a module. If so, the module
> > will be called i2c-mv64xxx.
> > diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
> > b/drivers/i2c/busses/i2c-mv64xxx.c index f9e076e..febf5ba 100644
> > --- a/drivers/i2c/busses/i2c-mv64xxx.c
> > +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> > @@ -490,6 +490,7 @@ static const struct i2c_algorithm mv64xxx_i2c_algo =
> > { */
> > #ifdef CONFIG_OF
> > static const struct of_device_id mv64xxx_i2c_of_match_table[] = {
> > + { .compatible = "allwinner,sun4i-i2c", .data =
> > &mv64xxx_i2c_regs_sun4i}, { .compatible = "marvell,mv64xxx-i2c", .data
> > = &mv64xxx_i2c_regs_mv64xxx}, {}
>
> Ah, OK, here you use compatible matching to get variant-specific data,
> fine. Still I think the same method (based on platform device name) should
> be used for non-DT variant.
Yes, you're right. I wasn't aware that you could do something similar
with the platform device name, hence why I used the platform data.
I'll fix this in the next iteration.
> > };
> > diff --git a/include/linux/mv643xx_i2c.h b/include/linux/mv643xx_i2c.h
> > index 9304c94..737108e 100644
> > --- a/include/linux/mv643xx_i2c.h
> > +++ b/include/linux/mv643xx_i2c.h
> > @@ -32,6 +32,16 @@ struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
> > .soft_reset = 0x1c,
> > };
> >
> > +struct mv64xxx_i2c_regs mv64xxx_i2c_regs_sun4i = {
> > + .addr = 0x00,
> > + .ext_addr = 0x04,
> > + .data = 0x08,
> > + .control= 0x0c,
> > + .status = 0x10,
> > + .clock = 0x14,
> > + .soft_reset = 0x18,
> > +};
> > +
>
> Hmm, header doesn't look like a correct place for a structure definition,
> especially when the structure isn't even static.
I put it there because it had to be used by the board files to fill
their plateform_data. Obviously, it will be moved back into the driver.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/9] Add I2C support for Allwinner SoCs
On Wednesday 12 June 2013 10:07:09 Maxime Ripard wrote: > > This patchset adds support for the I2C controller found on most of the > Allwinner SoCs, especially the already supported A10 and A13, and the > yet to come A31. > > This driver leverages the Marvel mv64xxx i2c controller driver, that has > an almost identical logic, with a slightly different register layout. > > It has been tested on a A13-Olinuxino and an A10s-Olinuxino. It doesn't really matter, but can someone clarify why this driver can be reused? Did marvell and allwinner license the same hardware block or is just a really simple driver that does things in an obvious way? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCHv4 7/9] ARM: sun5i: dt: Add i2c muxing options
Hi Henrik,
On Wed, Jun 12, 2013 at 10:29:48AM +0200, Henrik Nordström wrote:
> ons 2013-06-12 klockan 10:07 +0200 skrev Maxime Ripard:
>
> > + i2c0_pins_a: i2c0@0 {
> > + allwinner,pins = "PB0", "PB1";
> > + allwinner,function = "i2c0";
> > + allwinner,drive = <0>;
> > + allwinner,pull = <0>;
>
> Is this right? All other use pull = 1.
Ah, true.
> I guess it's board dependent depending on if there is external pullups
> or not on the i2c bus. I have seen Allwinner designs both with and
> without external pullups.
>
> It will not work well if there is neither internal or external pullup.
> And may stress the i2c components a bit if there is both..
Yes, but it's a default, so by definition, it won't suit everyone. Yet,
it has to be there. And every board is free to override that default in
its own DT anyway, so it's not really a big issue. But like you pointed
at, we have to be consistent.
I'll disable the pull-ups in the next iteration for every node.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/9] i2c: mv64xxx: Add Allwinner sun4i compatible
On Wed, Jun 12, 2013 at 10:07:13AM +0200, Maxime Ripard wrote: > Add the compatible string for the Allwinner A10 i2c controller and the > associated register layout. > > Signed-off-by: Maxime Ripard > --- > drivers/i2c/busses/Kconfig | 3 ++- > drivers/i2c/busses/i2c-mv64xxx.c | 1 + > include/linux/mv643xx_i2c.h | 10 ++ > 3 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 631736e..5dc4148 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -507,10 +507,11 @@ config I2C_MPC > > config I2C_MV64XXX > tristate "Marvell mv64xxx I2C Controller" > - depends on (MV64X60 || PLAT_ORION) > + depends on (MV64X60 || PLAT_ORION || ARCH_SUNXI) Hi Maxime. What about MV64X60? It also needs to pass the registers in its platform data. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
On Wed, Jun 12, 2013 at 10:07:11AM +0200, Maxime Ripard wrote:
> The Allwinner i2c controller uses the same logic as the Marvell one, but
> with slightly different register offsets.
>
> Introduce a structure that will be passed by either the pdata or
> associated to the compatible strings, and that holds the various
> registers that might be needed.
Hi Maxime
I don't think this change is bisectable. It assumes the platform data
passes the registers, which is not true until the next patch.
Please can you re-arrange the order. Add the extra information to the
platform data, and then make use of it, not the other way around.
Thanks
Andrew
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/i2c/busses/i2c-mv64xxx.c | 81
> +---
> include/linux/mv643xx_i2c.h | 27 --
> 2 files changed, 66 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
> b/drivers/i2c/busses/i2c-mv64xxx.c
> index d70a2fda..f9e076e 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -19,20 +19,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
>
> -/* Register defines */
> -#define MV64XXX_I2C_REG_SLAVE_ADDR 0x00
> -#define MV64XXX_I2C_REG_DATA0x04
> -#define MV64XXX_I2C_REG_CONTROL 0x08
> -#define MV64XXX_I2C_REG_STATUS 0x0c
> -#define MV64XXX_I2C_REG_BAUD0x0c
> -#define MV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
> -#define MV64XXX_I2C_REG_SOFT_RESET 0x1c
> -
> #define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
> #define MV64XXX_I2C_BAUD_DIV_N(val) (val & 0x7)
> #define MV64XXX_I2C_BAUD_DIV_M(val) ((val & 0xf) << 3)
> @@ -98,6 +90,7 @@ struct mv64xxx_i2c_data {
> u32 aborting;
> u32 cntl_bits;
> void __iomem*reg_base;
> + struct mv64xxx_i2c_regs *regs;
> u32 addr1;
> u32 addr2;
> u32 bytes_left;
> @@ -154,13 +147,13 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data
> *drv_data,
> static void
> mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
> {
> - writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SOFT_RESET);
> + writel(0, drv_data->reg_base + drv_data->regs->soft_reset);
> writel(MV64XXX_I2C_BAUD_DIV_M(drv_data->freq_m) |
> MV64XXX_I2C_BAUD_DIV_N(drv_data->freq_n),
> - drv_data->reg_base + MV64XXX_I2C_REG_BAUD);
> - writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SLAVE_ADDR);
> - writel(0, drv_data->reg_base + MV64XXX_I2C_REG_EXT_SLAVE_ADDR);
> + drv_data->reg_base + drv_data->regs->clock);
> + writel(0, drv_data->reg_base + drv_data->regs->addr);
> + writel(0, drv_data->reg_base + drv_data->regs->ext_addr);
> writel(MV64XXX_I2C_REG_CONTROL_TWSIEN | MV64XXX_I2C_REG_CONTROL_STOP,
> - drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
> + drv_data->reg_base + drv_data->regs->control);
> drv_data->state = MV64XXX_I2C_STATE_IDLE;
> }
>
> @@ -282,7 +275,7 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
>
> drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_START;
> writel(drv_data->cntl_bits,
> - drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
> + drv_data->reg_base + drv_data->regs->control);
>
> drv_data->msgs++;
> drv_data->num_msgs--;
> @@ -300,48 +293,48 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
>
> case MV64XXX_I2C_ACTION_CONTINUE:
> writel(drv_data->cntl_bits,
> - drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
> + drv_data->reg_base + drv_data->regs->control);
> break;
>
> case MV64XXX_I2C_ACTION_SEND_START:
> writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
> - drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
> + drv_data->reg_base + drv_data->regs->control);
> break;
>
> case MV64XXX_I2C_ACTION_SEND_ADDR_1:
> writel(drv_data->addr1,
> - drv_data->reg_base + MV64XXX_I2C_REG_DATA);
> + drv_data->reg_base + drv_data->regs->data);
> writel(drv_data->cntl_bits,
> - drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
> + drv_data->reg_base + drv_data->regs->control);
> break;
>
> case MV64XXX_I2C_ACTION_SEND_ADDR_2:
> writel(drv_data->addr2,
> - drv_data->reg_base + MV64XXX_I2C_REG_DATA);
> +
Re: [PATCH RFC v3 3/3] i2c: pxa: use module_platform_driver() replace init/exit
On Wed, Jun 12, 2013 at 12:03:13PM +0200, Wolfram Sang wrote: > On Thu, May 23, 2013 at 09:48:22PM +0800, Libo Chen wrote: > > maybe I make a mistake, please drop it. > > Which mistake? Wrong window, now I see it. signature.asc Description: Digital signature
Re: [PATCH RFC v3 3/3] i2c: pxa: use module_platform_driver() replace init/exit
On Thu, May 23, 2013 at 09:48:22PM +0800, Libo Chen wrote: > maybe I make a mistake, please drop it. Which mistake? signature.asc Description: Digital signature
Re: [PATCH RFC v3 2/3] i2c: pxa: convert to devm_* API
On Thu, May 23, 2013 at 08:00:08PM +0800, Libo Chen wrote: > when i2c malloc faild, we should not try to call release_mem_region. > aovid this, convert them to devm_* API. > > Signed-off-by: Libo Chen First, you did it right. This patch should not be combined with 1/3. It is not a trivial cleanup, so I prefer to keep them seperated. BTW did you test these patches on real hardware? > @@ -1198,19 +1187,6 @@ static int i2c_pxa_probe(struct platform_device *dev) > #endif > return 0; > > -eadapt: > - if (!i2c->use_pio) > - free_irq(irq, i2c); > -ereqirq: > - clk_disable(i2c->clk); > - iounmap(i2c->reg_base); > -eremap: > - clk_put(i2c->clk); > -eclk: > - kfree(i2c); > -emalloc: > - release_mem_region(res->start, resource_size(res)); > - return ret; > } > > static int i2c_pxa_remove(struct platform_device *dev) > @@ -1218,15 +1194,6 @@ static int i2c_pxa_remove(struct platform_device *dev) > struct pxa_i2c *i2c = platform_get_drvdata(dev); > > i2c_del_adapter(&i2c->adap); > - if (!i2c->use_pio) > - free_irq(i2c->irq, i2c); > - > - clk_disable(i2c->clk); > - clk_put(i2c->clk); > - > - iounmap(i2c->reg_base); > - release_mem_region(i2c->iobase, i2c->iosize); > - kfree(i2c); You remove too much. Who disables the clock now? signature.asc Description: Digital signature
Re: [PATCH RFC v3 1/3] i2c: i2c-bfin-twi: convert to devm_* API
On Tue, May 28, 2013 at 02:42:22PM +0800, Libo Chen wrote: > thanks for your review. I will update later. I agree with the remarks from Sachin. signature.asc Description: Digital signature
Re: [RFC PATCH] i2c-designware-core: disable adapter before fill dev structure
On Tue, Jun 11, 2013 at 08:40:37PM +0200, Wolfram Sang wrote: > On Fri, Jun 07, 2013 at 03:01:34PM +0200, Christian Ruppert wrote: > > Hi Andy, > > > > I like your patch and I just did some testing on it. Unluckily, it > > doesn't solve the lock-up problem. > > > > I haven't investigated any further but I suspect that on top of the > > cases I observed when debugging this (interrupts after initialisation of > > dev, easy to prove) there are more obscure cases in which interrupts are > > generated in an unexpected manner after errors. The interrupt-driven > > transfer state machine of the driver implicitly relies on the fact that > > all updates of dev which are related to the same transfer are performed > > between the mutex_lock and mutex_unlock calls in i2c_dw_xfer. Thus, I > > decided it was safer to disable the block before releasing the mutex > > when I wrote my patch. > > > > That said, I think the sequencing at transfer initialisation is more > > logical with your patch and I wonder if it is still worth applying. Any > > other opinions on this? > > Ping. There are: > > [V2] i2c: designware: fix race between subsequent xfers > [RFC] i2c-designware-core: disable adapter before fill dev structure > > What is the consensus of those two patches? Although I almost like Andy's code better than my own it doesn't seem to fix the issue we're aiming at (system lock ups due to undesired interrupts) in all cases. The "[V2] i2c: designware: fix race between subsequent xfers" is currently the only patch preventing those lock ups in our tests. That said, IMHO Andy's patch seems to be a valuable code clean up nevertheless and could be applied in addition to the other. I suggest I give the combination of both patches some additional testing on the occasion and tag Andy's RFC with tested-by me in case it's stable. Greetings, Christian -- Christian Ruppert , /| Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri _// | bilis Systems CH-1228 Plan-les-Ouates -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCHv4 7/9] ARM: sun5i: dt: Add i2c muxing options
ons 2013-06-12 klockan 10:07 +0200 skrev Maxime Ripard:
> + i2c0_pins_a: i2c0@0 {
> + allwinner,pins = "PB0", "PB1";
> + allwinner,function = "i2c0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
Is this right? All other use pull = 1.
I guess it's board dependent depending on if there is external pullups
or not on the i2c bus. I have seen Allwinner designs both with and
without external pullups.
It will not work well if there is neither internal or external pullup.
And may stress the i2c components a bit if there is both..
Regards
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/9] i2c: mv64xxx: Add Allwinner sun4i compatible
Hi Maxime,
On Wednesday 12 of June 2013 10:07:13 Maxime Ripard wrote:
> Add the compatible string for the Allwinner A10 i2c controller and the
> associated register layout.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/i2c/busses/Kconfig | 3 ++-
> drivers/i2c/busses/i2c-mv64xxx.c | 1 +
> include/linux/mv643xx_i2c.h | 10 ++
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 631736e..5dc4148 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -507,10 +507,11 @@ config I2C_MPC
>
> config I2C_MV64XXX
> tristate "Marvell mv64xxx I2C Controller"
> - depends on (MV64X60 || PLAT_ORION)
> + depends on (MV64X60 || PLAT_ORION || ARCH_SUNXI)
> help
> If you say yes to this option, support will be included for the
> built-in I2C interface on the Marvell 64xxx line of host
bridges.
> + This driver is also used for Allwinner SoCs I2C controllers.
>
> This driver can also be built as a module. If so, the module
> will be called i2c-mv64xxx.
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
> b/drivers/i2c/busses/i2c-mv64xxx.c index f9e076e..febf5ba 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -490,6 +490,7 @@ static const struct i2c_algorithm mv64xxx_i2c_algo =
> { */
> #ifdef CONFIG_OF
> static const struct of_device_id mv64xxx_i2c_of_match_table[] = {
> + { .compatible = "allwinner,sun4i-i2c", .data =
> &mv64xxx_i2c_regs_sun4i}, { .compatible = "marvell,mv64xxx-i2c", .data
> = &mv64xxx_i2c_regs_mv64xxx}, {}
Ah, OK, here you use compatible matching to get variant-specific data,
fine. Still I think the same method (based on platform device name) should
be used for non-DT variant.
> };
> diff --git a/include/linux/mv643xx_i2c.h b/include/linux/mv643xx_i2c.h
> index 9304c94..737108e 100644
> --- a/include/linux/mv643xx_i2c.h
> +++ b/include/linux/mv643xx_i2c.h
> @@ -32,6 +32,16 @@ struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
> .soft_reset = 0x1c,
> };
>
> +struct mv64xxx_i2c_regs mv64xxx_i2c_regs_sun4i = {
> + .addr = 0x00,
> + .ext_addr = 0x04,
> + .data = 0x08,
> + .control= 0x0c,
> + .status = 0x10,
> + .clock = 0x14,
> + .soft_reset = 0x18,
> +};
> +
Hmm, header doesn't look like a correct place for a structure definition,
especially when the structure isn't even static.
Best regards,
Tomasz
> /* i2c Platform Device, Driver Data */
> struct mv64xxx_i2c_pdata {
> u32 freq_m;
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 3/9] ARM: orion: pass the i2c registers definition through the platform data
Hi Maxime,
On Wednesday 12 of June 2013 10:07:12 Maxime Ripard wrote:
> Convert the existing platform data users of the MV64XXX i2c driver to
> pass the registers offset structure along with the platform data.
I'm not really convinced that platform data is the right way to pass such
data.
IMHO driver/match data were supposed to contain variant-specific
parameters, which the driver would receive based on matching platform
device name (in non-DT case) or compatible string (in DT case).
Best regards,
Tomasz
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/plat-orion/common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
> index c019b7a..c166fc9 100644
> --- a/arch/arm/plat-orion/common.c
> +++ b/arch/arm/plat-orion/common.c
> @@ -509,6 +509,7 @@ void __init orion_ge00_switch_init(struct
> dsa_platform_data *d, int irq)
> ***
> */ static struct mv64xxx_i2c_pdata orion_i2c_pdata = {
> .freq_n = 3,
> + .regs = &mv64xxx_i2c_regs_mv64xxx,
> .timeout= 1000, /* Default timeout of 1 second */
> };
>
> @@ -524,6 +525,7 @@ static struct platform_device orion_i2c = {
>
> static struct mv64xxx_i2c_pdata orion_i2c_1_pdata = {
> .freq_n = 3,
> + .regs = &mv64xxx_i2c_regs_mv64xxx,
> .timeout= 1000, /* Default timeout of 1 second */
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/6] i2c: sunxi: Add Allwinner A1X i2c driver
Hi Wolfram, On Tue, Jun 11, 2013 at 08:21:22PM +0200, Wolfram Sang wrote: > The thing is: If there is a bug/errata found in one driver, it goes > unnoticed that it probably should be fixed in the other, too. This is > why sharing logic is a good thing from a maintenance view. Yes, I definitely understand that. > Register offsets are annoying, but one can handle them. There are > examples in the kernel tree. If some registers are totally different > they often can be encapsulated in specific functions processing them. > > So, I'd like to ask you if you can prepare a list of what would be > needed to merge this support into mv64xxx? Then I get a better picture > of what way to go. Can you do this? I had some time to work on this, I sent you the patches. Except for the register offset parts, the logic of the driver itself needed no modifications, so the only "big" change is to pass the register structure somehow. Anyway, I just sent to you the patches I had. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 9/9] ARM: sun4i: cubieboard: Enable the i2c controllers
From: Emilio López
The Cubieboard makes use of the first two i2c controllers found on the
Allwinner A10; i2c-0 is used internally for the PMIC, while i2c-1
is exposed on the board headers. This patch enables them in the device
tree.
Signed-off-by: Emilio López
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index e752b57..757c4cd 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -56,6 +56,18 @@
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+
+ i2c0: i2c@01c2ac00 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+ };
+
+ i2c1: i2c@01c2b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+ };
};
leds {
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 8/9] ARM: sun5i: olinuxino: Enable the i2c controllers
The A13-Olinuxino makes use of the 3 i2c controllers found on the Allwinner
A13. Enable them in the device tree.
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index 3ca5506..80497e3 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -37,6 +37,24 @@
pinctrl-0 = <&uart1_pins_b>;
status = "okay";
};
+
+ i2c0: i2c@01c2ac00 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+ };
+
+ i2c1: i2c@01c2b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+ };
+
+ i2c2: i2c@01c2b400 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+ };
};
leds {
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 7/9] ARM: sun5i: dt: Add i2c muxing options
The i2c controller found on the Allwinner A13 has only one muxing option
available for each controller. Add them to the dtsi
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun5i-a13.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 31ebfd7..bca0af3 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -184,6 +184,27 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ i2c0_pins_a: i2c0@0 {
+ allwinner,pins = "PB0", "PB1";
+ allwinner,function = "i2c0";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ i2c1_pins_a: i2c1@0 {
+ allwinner,pins = "PB15", "PB16";
+ allwinner,function = "i2c1";
+ allwinner,drive = <0>;
+ allwinner,pull = <1>;
+ };
+
+ i2c2_pins_a: i2c2@0 {
+ allwinner,pins = "PB17", "PB18";
+ allwinner,function = "i2c2";
+ allwinner,drive = <0>;
+ allwinner,pull = <1>;
+ };
};
timer@01c20c00 {
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 6/9] ARM: sun4i: dt: Add i2c muxing options
The i2c controller found on the Allwinner A10 has only one muxing option
available for each controller. Add them to the dtsi
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun4i-a10.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index f7e4a96..c2adc74 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -227,6 +227,26 @@
allwinner,function = "emac";
allwinner,drive = <0>;
allwinner,pull = <0>;
+
+ i2c0_pins_a: i2c0@0 {
+ allwinner,pins = "PB0", "PB1";
+ allwinner,function = "i2c0";
+ allwinner,drive = <0>;
+ allwinner,pull = <1>;
+ };
+
+ i2c1_pins_a: i2c1@0 {
+ allwinner,pins = "PB18", "PB19";
+ allwinner,function = "i2c1";
+ allwinner,drive = <0>;
+ allwinner,pull = <1>;
+ };
+
+ i2c2_pins_a: i2c2@0 {
+ allwinner,pins = "PB20", "PB21";
+ allwinner,function = "i2c2";
+ allwinner,drive = <0>;
+ allwinner,pull = <1>;
};
};
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 4/9] i2c: mv64xxx: Add Allwinner sun4i compatible
Add the compatible string for the Allwinner A10 i2c controller and the
associated register layout.
Signed-off-by: Maxime Ripard
---
drivers/i2c/busses/Kconfig | 3 ++-
drivers/i2c/busses/i2c-mv64xxx.c | 1 +
include/linux/mv643xx_i2c.h | 10 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 631736e..5dc4148 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -507,10 +507,11 @@ config I2C_MPC
config I2C_MV64XXX
tristate "Marvell mv64xxx I2C Controller"
- depends on (MV64X60 || PLAT_ORION)
+ depends on (MV64X60 || PLAT_ORION || ARCH_SUNXI)
help
If you say yes to this option, support will be included for the
built-in I2C interface on the Marvell 64xxx line of host bridges.
+ This driver is also used for Allwinner SoCs I2C controllers.
This driver can also be built as a module. If so, the module
will be called i2c-mv64xxx.
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index f9e076e..febf5ba 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -490,6 +490,7 @@ static const struct i2c_algorithm mv64xxx_i2c_algo = {
*/
#ifdef CONFIG_OF
static const struct of_device_id mv64xxx_i2c_of_match_table[] = {
+ { .compatible = "allwinner,sun4i-i2c", .data = &mv64xxx_i2c_regs_sun4i},
{ .compatible = "marvell,mv64xxx-i2c", .data =
&mv64xxx_i2c_regs_mv64xxx},
{}
};
diff --git a/include/linux/mv643xx_i2c.h b/include/linux/mv643xx_i2c.h
index 9304c94..737108e 100644
--- a/include/linux/mv643xx_i2c.h
+++ b/include/linux/mv643xx_i2c.h
@@ -32,6 +32,16 @@ struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
.soft_reset = 0x1c,
};
+struct mv64xxx_i2c_regs mv64xxx_i2c_regs_sun4i = {
+ .addr = 0x00,
+ .ext_addr = 0x04,
+ .data = 0x08,
+ .control= 0x0c,
+ .status = 0x10,
+ .clock = 0x14,
+ .soft_reset = 0x18,
+};
+
/* i2c Platform Device, Driver Data */
struct mv64xxx_i2c_pdata {
u32 freq_m;
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 3/9] ARM: orion: pass the i2c registers definition through the platform data
Convert the existing platform data users of the MV64XXX i2c driver to
pass the registers offset structure along with the platform data.
Signed-off-by: Maxime Ripard
---
arch/arm/plat-orion/common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index c019b7a..c166fc9 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -509,6 +509,7 @@ void __init orion_ge00_switch_init(struct dsa_platform_data
*d, int irq)
/
static struct mv64xxx_i2c_pdata orion_i2c_pdata = {
.freq_n = 3,
+ .regs = &mv64xxx_i2c_regs_mv64xxx,
.timeout= 1000, /* Default timeout of 1 second */
};
@@ -524,6 +525,7 @@ static struct platform_device orion_i2c = {
static struct mv64xxx_i2c_pdata orion_i2c_1_pdata = {
.freq_n = 3,
+ .regs = &mv64xxx_i2c_regs_mv64xxx,
.timeout= 1000, /* Default timeout of 1 second */
};
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 1/9] i2c: mv64xxx: Add macros to access parts of registers
These macros make it more comprehensive to access to useful masked and
shifted area of the various registers used.
Signed-off-by: Maxime Ripard
---
drivers/i2c/busses/i2c-mv64xxx.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 6356439..d70a2fda 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -33,6 +33,10 @@
#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+#define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
+#define MV64XXX_I2C_BAUD_DIV_N(val)(val & 0x7)
+#define MV64XXX_I2C_BAUD_DIV_M(val)((val & 0xf) << 3)
+
#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
@@ -133,7 +137,7 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data
*drv_data,
drv_data->addr1 = 0xf0 | (((u32)msg->addr & 0x300) >> 7) | dir;
drv_data->addr2 = (u32)msg->addr & 0xff;
} else {
- drv_data->addr1 = ((u32)msg->addr & 0x7f) << 1 | dir;
+ drv_data->addr1 = MV64XXX_I2C_ADDR_ADDR((u32)msg->addr) | dir;
drv_data->addr2 = 0;
}
}
@@ -151,7 +155,7 @@ static void
mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
{
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SOFT_RESET);
- writeldrv_data->freq_m & 0xf) << 3) | (drv_data->freq_n & 0x7)),
+ writel(MV64XXX_I2C_BAUD_DIV_M(drv_data->freq_m) |
MV64XXX_I2C_BAUD_DIV_N(drv_data->freq_n),
drv_data->reg_base + MV64XXX_I2C_REG_BAUD);
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SLAVE_ADDR);
writel(0, drv_data->reg_base + MV64XXX_I2C_REG_EXT_SLAVE_ADDR);
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 0/9] Add I2C support for Allwinner SoCs
Hi, This patchset adds support for the I2C controller found on most of the Allwinner SoCs, especially the already supported A10 and A13, and the yet to come A31. This driver leverages the Marvel mv64xxx i2c controller driver, that has an almost identical logic, with a slightly different register layout. It has been tested on a A13-Olinuxino and an A10s-Olinuxino. Thanks, Maxime Changes from v3: * Merged the driver in the Marvell mv64xxx i2c controller Changes from v2: * Slightly modified the switch comments again * Removed the of_* calls in favor of platform_get_* functions Changes from v1: * Added comments to the switch statements to clarify when the fall through to the next case is made on purpose * Use devm_ioremap_resource instead of of_iomap * Moved the reset after enabling the clocks * Added Emilio Lopez' patch to add the available i2c controllers to the cubieboard Emilio López (1): ARM: sun4i: cubieboard: Enable the i2c controllers Maxime Ripard (8): i2c: mv64xxx: Add macros to access parts of registers i2c: mv64xxx: make the registers offset configurable ARM: orion: pass the i2c registers definition through the platform data i2c: mv64xxx: Add Allwinner sun4i compatible ARM: sunxi: dt: Add i2c controller nodes to the DTSI ARM: sun4i: dt: Add i2c muxing options ARM: sun5i: dt: Add i2c muxing options ARM: sun5i: olinuxino: Enable the i2c controllers arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 12 arch/arm/boot/dts/sun4i-a10.dtsi | 47 arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 18 ++ arch/arm/boot/dts/sun5i-a13.dtsi | 48 arch/arm/plat-orion/common.c | 2 + drivers/i2c/busses/Kconfig | 3 +- drivers/i2c/busses/i2c-mv64xxx.c | 88 -- include/linux/mv643xx_i2c.h| 37 - 8 files changed, 211 insertions(+), 44 deletions(-) -- 1.8.3 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 2/9] i2c: mv64xxx: make the registers offset configurable
The Allwinner i2c controller uses the same logic as the Marvell one, but
with slightly different register offsets.
Introduce a structure that will be passed by either the pdata or
associated to the compatible strings, and that holds the various
registers that might be needed.
Signed-off-by: Maxime Ripard
---
drivers/i2c/busses/i2c-mv64xxx.c | 81 +---
include/linux/mv643xx_i2c.h | 27 --
2 files changed, 66 insertions(+), 42 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index d70a2fda..f9e076e 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -19,20 +19,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-/* Register defines */
-#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
-#defineMV64XXX_I2C_REG_DATA0x04
-#defineMV64XXX_I2C_REG_CONTROL 0x08
-#defineMV64XXX_I2C_REG_STATUS 0x0c
-#defineMV64XXX_I2C_REG_BAUD0x0c
-#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
-#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
-
#define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
#define MV64XXX_I2C_BAUD_DIV_N(val)(val & 0x7)
#define MV64XXX_I2C_BAUD_DIV_M(val)((val & 0xf) << 3)
@@ -98,6 +90,7 @@ struct mv64xxx_i2c_data {
u32 aborting;
u32 cntl_bits;
void __iomem*reg_base;
+ struct mv64xxx_i2c_regs *regs;
u32 addr1;
u32 addr2;
u32 bytes_left;
@@ -154,13 +147,13 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data
*drv_data,
static void
mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
{
- writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SOFT_RESET);
+ writel(0, drv_data->reg_base + drv_data->regs->soft_reset);
writel(MV64XXX_I2C_BAUD_DIV_M(drv_data->freq_m) |
MV64XXX_I2C_BAUD_DIV_N(drv_data->freq_n),
- drv_data->reg_base + MV64XXX_I2C_REG_BAUD);
- writel(0, drv_data->reg_base + MV64XXX_I2C_REG_SLAVE_ADDR);
- writel(0, drv_data->reg_base + MV64XXX_I2C_REG_EXT_SLAVE_ADDR);
+ drv_data->reg_base + drv_data->regs->clock);
+ writel(0, drv_data->reg_base + drv_data->regs->addr);
+ writel(0, drv_data->reg_base + drv_data->regs->ext_addr);
writel(MV64XXX_I2C_REG_CONTROL_TWSIEN | MV64XXX_I2C_REG_CONTROL_STOP,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->regs->control);
drv_data->state = MV64XXX_I2C_STATE_IDLE;
}
@@ -282,7 +275,7 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_START;
writel(drv_data->cntl_bits,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->regs->control);
drv_data->msgs++;
drv_data->num_msgs--;
@@ -300,48 +293,48 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
case MV64XXX_I2C_ACTION_CONTINUE:
writel(drv_data->cntl_bits,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->regs->control);
break;
case MV64XXX_I2C_ACTION_SEND_START:
writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->regs->control);
break;
case MV64XXX_I2C_ACTION_SEND_ADDR_1:
writel(drv_data->addr1,
- drv_data->reg_base + MV64XXX_I2C_REG_DATA);
+ drv_data->reg_base + drv_data->regs->data);
writel(drv_data->cntl_bits,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->regs->control);
break;
case MV64XXX_I2C_ACTION_SEND_ADDR_2:
writel(drv_data->addr2,
- drv_data->reg_base + MV64XXX_I2C_REG_DATA);
+ drv_data->reg_base + drv_data->regs->data);
writel(drv_data->cntl_bits,
- drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
+ drv_data->reg_base + drv_data->regs->control);
break;
case MV64XXX_I2C_ACTION_SEND_DATA:
writel(drv_data->msg->buf[drv_data->byte_posn++],
- drv_data->reg_base + MV64XXX_I2C_REG_DATA);
+ d
[PATCHv4 5/9] ARM: sunxi: dt: Add i2c controller nodes to the DTSI
The Allwinner A10 and A13 both have 3 i2c controller embedded.
Add those to the common sunxi dtsi.
Signed-off-by: Maxime Ripard
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/sun4i-a10.dtsi | 27 +++
arch/arm/boot/dts/sun5i-a13.dtsi | 27 +++
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 04ff62a..f7e4a96 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -321,5 +321,32 @@
clocks = <&apb1_gates 23>;
status = "disabled";
};
+
+ i2c0: i2c@01c2ac00 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <7>;
+ clocks = <&apb1_gates 0>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@01c2b000 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <8>;
+ clocks = <&apb1_gates 1>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@01c2b400 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = <9>;
+ clocks = <&apb1_gates 2>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index f34db19..31ebfd7 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -217,5 +217,32 @@
clocks = <&apb1_gates 19>;
status = "disabled";
};
+
+ i2c0: i2c@01c2ac00 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <7>;
+ clocks = <&apb1_gates 0>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@01c2b000 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <8>;
+ clocks = <&apb1_gates 1>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@01c2b400 {
+ compatible = "allwinner,sun4i-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = <9>;
+ clocks = <&apb1_gates 2>;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
};
};
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] i2c: vt8500: Add support for I2C bus on Wondermedia SoCs
This patch adds support for the I2C bus controllers found on Wondermedia
8xxx-series SoCs. Only master-mode is supported.
Signed-off-by: Tony Prisk
---
.../devicetree/bindings/i2c/i2c-vt8500.txt | 24 +
MAINTAINERS|1 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-wmt.c | 483
5 files changed, 519 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
create mode 100644 drivers/i2c/busses/i2c-wmt.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
new file mode 100644
index 000..94a425e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
@@ -0,0 +1,24 @@
+* Wondermedia I2C Controller
+
+Required properties :
+
+ - compatible : should be "wm,wm8505-i2c"
+ - reg : Offset and length of the register set for the device
+ - interrupts : where IRQ is the interrupt number
+ - clocks : phandle to the I2C clock source
+
+Optional properties :
+
+ - clock-frequency : desired I2C bus clock frequency in Hz.
+ Valid values are 10 and 40.
+ Default to 10 if not specified, or invalid value.
+
+Example :
+
+ i2c_0: i2c@d828 {
+ compatible = "wm,wm8505-i2c";
+ reg = <0xd828 0x1000>;
+ interrupts = <19>;
+ clocks = <&clki2c0>;
+ clock-frequency = <40>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d7782b..44ea994 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1285,6 +1285,7 @@ S:Maintained
F: arch/arm/mach-vt8500/
F: drivers/clocksource/vt8500_timer.c
F: drivers/gpio/gpio-vt8500.c
+F: drivers/i2c/busses/i2c-wmt.c
F: drivers/mmc/host/wmt-sdmmc.c
F: drivers/pwm/pwm-vt8500.c
F: drivers/rtc/rtc-vt8500.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 631736e..89e7ec2 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -724,6 +724,16 @@ config I2C_VERSATILE
This driver can also be built as a module. If so, the module
will be called i2c-versatile.
+config I2C_WMT
+ tristate "Wondermedia WM8xxx SoC I2C bus support"
+ depends on ARCH_VT8500
+ help
+ Say yes if you want to support the I2C bus on Wondermedia 8xxx-series
+ SoCs.
+
+ This driver can also be built as a module. If so, the module will be
+ called i2c-wmt.
+
config I2C_OCTEON
tristate "Cavium OCTEON I2C bus support"
depends on CPU_CAVIUM_OCTEON
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 8f4fc23..3ba94a9 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_I2C_SIRF)+= i2c-sirf.o
obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
+obj-$(CONFIG_I2C_WMT) += i2c-wmt.o
obj-$(CONFIG_I2C_OCTEON) += i2c-octeon.o
obj-$(CONFIG_I2C_XILINX) += i2c-xiic.o
obj-$(CONFIG_I2C_XLR) += i2c-xlr.o
diff --git a/drivers/i2c/busses/i2c-wmt.c b/drivers/i2c/busses/i2c-wmt.c
new file mode 100644
index 000..2bbac9b
--- /dev/null
+++ b/drivers/i2c/busses/i2c-wmt.c
@@ -0,0 +1,483 @@
+/*
+ * Wondermedia I2C Master Mode Driver
+ *
+ * Copyright (C) 2012 Tony Prisk
+ *
+ * Derived from GPLv2+ licensed source:
+ * - Copyright (C) 2008 WonderMedia Technologies, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, or
+ * (at your option) any later version. as published by the Free Software
+ * Foundation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_CR 0x00
+#define REG_TCR0x02
+#define REG_CSR0x04
+#define REG_ISR0x06
+#define REG_IMR0x08
+#define REG_CDR0x0A
+#define REG_TR 0x0C
+#define REG_MCR0x0E
+#define REG_SLAVE_CR 0x10
+#define REG_SLAVE_SR 0x12
+#define REG_SLAVE_ISR 0x14
+#define REG_SLAVE_IMR 0x16
+#define REG_SLAVE_DR 0x18
+#define REG_SLAVE_TR 0x1A
+
+/* REG_CR Bit fields */
+#define CR_TX_NEXT_ACK 0x
+#define CR_ENABLE 0x0001
+#define CR_TX_NEXT_NO_ACK 0x0002
+#define CR_TX_END 0x0004
+#define CR_CPU_RDY 0x0008
+#define SLAV_MODE_SEL 0x8000
+
+/* REG_TCR Bit fields */
+#define TCR_STANDARD_MODE 0x
+#define TCR_MASTER_WRITE 0x
+#define TCR_HS_MODE0x2000
+#define TCR_MASTER_READ0x4000
+#define
