I2C: OMAP: Fixes and removal of cpu_... from driver
Subsystems (7)
cover I2C: OMAP: Fixes and removal of cpu_... from driver
The following series removes cpu_...() usage completely from the omap-i2c driver by having decisions about functional implementation choices in the SoC held in cpu-specific hwmod tables that are already established, or for OMAP1 where there is no hwmod, set at OMAP1-specific i2c bus addition time.
Along the way it solves two issues with the existing implementation, that only 16-bit accesses are documented to be allowed to the I2C peripheral unit, and that due to a confusion in the existing driver about whether it is faced with a newer IP version on OMAP3530, currently it writes to a random non-existent I2C register at times on that platform.
The patch series is quite extended from the first try thanks to comments from Benoit Cousson.
Patches are tested on OMAP3530 and OMAP4430 I have but will need confirming they don't break anything on OMAP1xxx and OMAP2xxx as agreed with Benoit.
---
Andy Green (18):
I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info
I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data
I2C: OMAP1: set i2c unit feature implementation flags in platform data
I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr
I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test
I2C: OMAP2+: Pass flags up to omap i2c platform_data as well
I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data
I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32
I2C: OMAP2+: address confused probed version naming
I2C: OMAP2+: Solve array bounds overflow error on i2c idle
I2C: OMAP2+: use platform_data ip revision to select register map
I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added
I2C: OMAP1: set IP revision in platform data
I2C: OMAP: add rev to omap i2c platform data
I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision
I2C: OMAP2+: Introduce I2C IP versioning constants
I2C: OMAP2+: Name registers in I2C IP V2 only accordingly
I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 8 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 6 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 ++++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 ++++- arch/arm/plat-omap/i2c.c | 27 ++++++++ arch/arm/plat-omap/include/plat/i2c.h | 3 + drivers/i2c/busses/i2c-omap.c | 98 +++++++++++++++------------- include/linux/i2c-omap.h | 29 ++++++++ 8 files changed, 151 insertions(+), 51 deletions(-)
Signature · 1 line
Signature
PATCH 1/18 I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c
Peter Maydell noticed when running under QEMU he was getting errors reporting 32-bit access to I2C peripheral unit registers that are documented to be 8 or 16-bit only[1][2]
The I2C driver is blameless as it wraps its accesses in a function using __raw_writew and __raw_readw, it turned out it is the hwmod stuff.
However the hwmod code already has a flag to force a perhipheral unit to only be accessed using 16-bit operations.
This patch applies the 16-bit only flag to the 2430, OMAP3xxx and OMAP44xx hwmod structs. 2420 was already correctly marked up as 16-bit.
The 2430 change will need testing by TI as arranged in the comments to the previous patch version.
When the 16-bit flag is or-ed with other flags, it is placed first as requested in comments.
[1] OMAP4430 Technical reference manual section 23.1.6.2
[2] OMAP3530 Techincal reference manual section 18.6
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 3 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 ++++---- 3 files changed, 9 insertions(+), 4 deletions(-)
arch/arm/mach-omap2/omap_hwmod_2430_data.c +2 -0
@@ -1545,6 +1545,7 @@ static struct omap_hwmod_ocp_if *omap2430_i2c1_slaves[] = {static struct omap_hwmod omap2430_i2c1_hwmod = { .name ="i2c1" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c1_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c1_mpu_irqs), .sdma_reqs = i2c1_sdma_reqs,
@@ -1591,6 +1592,7 @@ static struct omap_hwmod_ocp_if *omap2430_i2c2_slaves[] = {static struct omap_hwmod omap2430_i2c2_hwmod = { .name ="i2c2" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c2_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c2_mpu_irqs), .sdma_reqs = i2c2_sdma_reqs,
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +3 -0
@@ -1892,6 +1892,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c1_slaves[] = {static struct omap_hwmod omap3xxx_i2c1_hwmod = { .name ="i2c1" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c1_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c1_mpu_irqs), .sdma_reqs = i2c1_sdma_reqs,
@@ -1934,6 +1935,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c2_slaves[] = {static struct omap_hwmod omap3xxx_i2c2_hwmod = { .name ="i2c2" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c2_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c2_mpu_irqs), .sdma_reqs = i2c2_sdma_reqs,
@@ -1976,6 +1978,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c3_slaves[] = {static struct omap_hwmod omap3xxx_i2c3_hwmod = { .name ="i2c3" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c3_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c3_mpu_irqs), .sdma_reqs = i2c3_sdma_reqs,
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +4 -4
@@ -2126,7 +2126,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c1_slaves[] = {static struct omap_hwmod omap44xx_i2c1_hwmod = { .name ="i2c1" , .class = &omap44xx_i2c_hwmod_class, - .flags =HWMOD_INIT_NO_RESET , + .flags =HWMOD_16BIT_REG |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_i2c1_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_i2c1_irqs), .sdma_reqs = omap44xx_i2c1_sdma_reqs,
@@ -2179,7 +2179,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c2_slaves[] = {static struct omap_hwmod omap44xx_i2c2_hwmod = { .name ="i2c2" , .class = &omap44xx_i2c_hwmod_class, - .flags =HWMOD_INIT_NO_RESET , + .flags =HWMOD_16BIT_REG |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_i2c2_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_i2c2_irqs), .sdma_reqs = omap44xx_i2c2_sdma_reqs,
@@ -2232,7 +2232,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c3_slaves[] = {static struct omap_hwmod omap44xx_i2c3_hwmod = { .name ="i2c3" , .class = &omap44xx_i2c_hwmod_class, - .flags =HWMOD_INIT_NO_RESET , + .flags =HWMOD_16BIT_REG |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_i2c3_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_i2c3_irqs), .sdma_reqs = omap44xx_i2c3_sdma_reqs,
@@ -2285,7 +2285,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c4_slaves[] = {static struct omap_hwmod omap44xx_i2c4_hwmod = { .name ="i2c4" , .class = &omap44xx_i2c_hwmod_class, - .flags =HWMOD_INIT_NO_RESET , + .flags =HWMOD_16BIT_REG |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_i2c4_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_i2c4_irqs), .sdma_reqs = omap44xx_i2c4_sdma_reqs,
PATCH 1/18 I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c
Just nitpicking on the subject:
Since that patch is changing only some OMAP sub-arch files, it should be:
OMAP2+: hwmod data: Set hwmod flags to only allow 16-bit accesses to i2c
To highlight the fact than an OMAP maintainer need to ack them.
Quoted 10 lines · Andy Green
Peter Maydell noticed when running under QEMU he was getting errors reporting 32-bit access to I2C peripheral unit registers that are documented to be 8 or 16-bit only[1][2]
The I2C driver is blameless as it wraps its accesses in a function using
__raw_writewand__raw_readw, it turned out it is the hwmod stuff.However the hwmod code already has a flag to force a perhipheral unit to only be accessed using 16-bit operations.
s/perhipheral/peripheral/
Quoted 4 lines
This patch applies the 16-bit only flag to the 2430, OMAP3xxx and OMAP44xx hwmod structs. 2420 was already correctly marked up as 16-bit.
Quoted 8 lines
The 2430 change will need testing by TI as arranged in the comments to the previous patch version.
When the 16-bit flag is or-ed with other flags, it is placed first as requested in comments.
[1] OMAP4430 Technical reference manual section 23.1.6.2
[2] OMAP3530 Techincal reference manual section 18.6
s/Techincal/Technical/
Quoted 4 lines
Cc patches at linaro.orgCc Ben Dooks<[email protected]>Reported-by Peter Maydell<[email protected]>Signed-off-by Andy Green<[email protected]>
You still need the ack from Paul for the OMAP2&3 files.
Benoit
Quoted 100 lines
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 3 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 ++++---- 3 files changed, 9 insertions(+), 4 deletions(-)arch/arm/mach-omap2/omap_hwmod_2430_data.c +2
-0@@ -1545,6 +1545,7 @@ static struct omap_hwmod_ocp_if *omap2430_i2c1_slaves[] = {static struct omap_hwmod omap2430_i2c1_hwmod = { .name ="i2c1" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c1_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c1_mpu_irqs), .sdma_reqs = i2c1_sdma_reqs,@@ -1591,6 +1592,7 @@ static struct omap_hwmod_ocp_if *omap2430_i2c2_slaves[] = {static struct omap_hwmod omap2430_i2c2_hwmod = { .name ="i2c2" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c2_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c2_mpu_irqs), .sdma_reqs = i2c2_sdma_reqs,arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +3
-0@@ -1892,6 +1892,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c1_slaves[] = {static struct omap_hwmod omap3xxx_i2c1_hwmod = { .name ="i2c1" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c1_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c1_mpu_irqs), .sdma_reqs = i2c1_sdma_reqs,@@ -1934,6 +1935,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c2_slaves[] = {static struct omap_hwmod omap3xxx_i2c2_hwmod = { .name ="i2c2" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c2_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c2_mpu_irqs), .sdma_reqs = i2c2_sdma_reqs,@@ -1976,6 +1978,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_i2c3_slaves[] = {static struct omap_hwmod omap3xxx_i2c3_hwmod = { .name ="i2c3" , + .flags =HWMOD_16BIT_REG , .mpu_irqs = i2c3_mpu_irqs, .mpu_irqs_cnt =ARRAY_SIZE (i2c3_mpu_irqs), .sdma_reqs = i2c3_sdma_reqs,arch/arm/mach-omap2/omap_hwmod_44xx_data.c +4
-5@@ -2126,7 +2126,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c1_slaves[] = {static struct omap_hwmod omap44xx_i2c1_hwmod = { .name ="i2c1" , .class =&omap44xx_i2c_hwmod_class, - .flags =HWMOD_INIT_NO_RESET , + .flags =HWMOD_16BIT_REG |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_i2c1_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_i2c1_irqs), .sdma_reqs = omap44xx_i2c1_sdma_reqs,@@ -2179,7 +2179,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c2_slaves[] = {static struct omap_hwmod omap44xx_i2c2_hwmod = { .name ="i2c2" , .class =&omap44xx_i2c_hwmod_class, - .flags =HWMOD_INIT_NO_RESET , + .flags =HWMOD_16BIT_REG |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_i2c2_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_i2c2_irqs), .sdma_reqs = omap44xx_i2c2_sdma_reqs,@@ -2232,7 +2232,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c3_slaves[] = {static struct omap_hwmod omap44xx_i2c3_hwmod = { .name ="i2c3" , .class =&omap44xx_i2c_hwmod_class, - .flags =HWMOD_INIT_NO_RESET , + .flags =HWMOD_16BIT_REG |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_i2c3_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_i2c3_irqs), .sdma_reqs = omap44xx_i2c3_sdma_reqs,@@ -2285,7 +2285,7 @@ static struct omap_hwmod_ocp_if *omap44xx_i2c4_slaves[] = {static struct omap_hwmod omap44xx_i2c4_hwmod = { .name ="i2c4" , .class =&omap44xx_i2c_hwmod_class, - .flags =HWMOD_INIT_NO_RESET , + .flags =HWMOD_16BIT_REG |HWMOD_INIT_NO_RESET , .mpu_irqs = omap44xx_i2c4_irqs, .mpu_irqs_cnt =ARRAY_SIZE (omap44xx_i2c4_irqs), .sdma_reqs = omap44xx_i2c4_sdma_reqs, --To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Walmsley
maintainerPATCH 1/18 I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c
In reply to Andy GreenQuoted 21 lines · Andy Green
Peter Maydell noticed when running under QEMU he was getting errors reporting 32-bit access to I2C peripheral unit registers that are documented to be 8 or 16-bit only[1][2]
The I2C driver is blameless as it wraps its accesses in a function using
__raw_writewand__raw_readw, it turned out it is the hwmod stuff.However the hwmod code already has a flag to force a perhipheral unit to only be accessed using 16-bit operations.
This patch applies the 16-bit only flag to the 2430, OMAP3xxx and OMAP44xx hwmod structs. 2420 was already correctly marked up as 16-bit.
The 2430 change will need testing by TI as arranged in the comments to the previous patch version.
When the 16-bit flag is or-ed with other flags, it is placed first as requested in comments.
Quoted 7 lines
[1] OMAP4430 Technical reference manual section 23.1.6.2
[2] OMAP3530 Techincal reference manual section 18.6Cc patches at linaro.orgCc Ben Dooks <[email protected]>Reported-by Peter Maydell <[email protected]>Signed-off-by Andy Green <[email protected]>
For the OMAP2/3 hwmod data changes, makes sense to me.
- Paul
PATCH 2/18 I2C: OMAP2+: Name registers in I2C IP V2 only accordingly
In reply to Andy GreenThe OMAP I2C driver dynamically chooses between two register sets of differing sizes depending on the cpu type it finds itself on.
It has been observed that the existing code references non-existing registers on OMAP3530, because while it correctly chose the smaller register layout based on cpu type, the code uses the probed register ID to decide if to execute code referencing an extra register, and both register layout devices on OMAP3530 and OMAP4430 report the same probed ID of 0x40.
This patch changes the extended register names only found on IP V2 of the I2C peripheral unit accordingly to help show up errors in usage.
---
drivers/i2c/busses/i2c-omap.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-)
drivers/i2c/busses/i2c-omap.c +12 -11
@@ -72,11 +72,12 @@ enum {OMAP_I2C_SCLH_REG ,OMAP_I2C_SYSTEST_REG ,OMAP_I2C_BUFSTAT_REG , -OMAP_I2C_REVNB_LO , -OMAP_I2C_REVNB_HI , -OMAP_I2C_IRQSTATUS_RAW , -OMAP_I2C_IRQENABLE_SET , - OMAP_I2C_IRQENABLE_CLR, +/* only on OMAP4430 */ +OMAP_I2C_IP_V2_REVNB_LO , +OMAP_I2C_IP_V2_REVNB_HI , +OMAP_I2C_IP_V2_IRQSTATUS_RAW , +OMAP_I2C_IP_V2_IRQENABLE_SET , + OMAP_I2C_IP_V2_IRQENABLE_CLR, };/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
@@ -244,11 +245,11 @@ const static u8 omap4_reg_map[] = { [OMAP_I2C_SCLH_REG] = 0xb8, [OMAP_I2C_SYSTEST_REG] = 0xbC, [OMAP_I2C_BUFSTAT_REG] = 0xc0, - [OMAP_I2C_REVNB_LO] = 0x00, - [OMAP_I2C_REVNB_HI] = 0x04, - [OMAP_I2C_IRQSTATUS_RAW] = 0x24, - [OMAP_I2C_IRQENABLE_SET] = 0x2c, - [OMAP_I2C_IRQENABLE_CLR] = 0x30, + [OMAP_I2C_IP_V2_REVNB_LO] = 0x00, + [OMAP_I2C_IP_V2_REVNB_HI] = 0x04, + [OMAP_I2C_IP_V2_IRQSTATUS_RAW] = 0x24, + [OMAP_I2C_IP_V2_IRQENABLE_SET] = 0x2c, + [OMAP_I2C_IP_V2_IRQENABLE_CLR] = 0x30, }; static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -309,7 +310,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev) dev->iestate =omap_i2c_read_reg (dev,OMAP_I2C_IE_REG );if (dev->rev >=OMAP_I2C_REV_ON_4430 ) -omap_i2c_write_reg (dev,OMAP_I2C_IRQENABLE_CLR ,1 ); +omap_i2c_write_reg (dev,OMAP_I2C_IP_V2_IRQENABLE_CLR ,1 );else omap_i2c_write_reg (dev,OMAP_I2C_IE_REG ,0 );
PATCH 3/18 I2C: OMAP2+: Introduce I2C IP versioning constants
In reply to Andy GreenThese represent the two kinds of (incompatible) OMAP I2C peripheral unit in use so far.
The constants are in linux/i2c-omap.h so the omap i2c driver can have them too.
---
arch/arm/plat-omap/include/plat/i2c.h | 1 + include/linux/i2c-omap.h | 12 ++++++++++++ 2 files changed, 13 insertions(+), 0 deletions(-)
arch/arm/plat-omap/include/plat/i2c.h +1 -0
@@ -22,6 +22,7 @@#define __ASM__ARCH_OMAP_I2C_H#include <linux/i2c.h> +#include <linux/i2c-omap.h> #if defined(CONFIG_I2C_OMAP ) || defined(CONFIG_I2C_OMAP_MODULE ) extern int omap_register_i2c_bus(int bus_id, u32 clkrate,
include/linux/i2c-omap.h +12 -0
@@ -3,6 +3,18 @@#include <linux/platform_device.h> +/* +* Version 2 of the I2C peripheral unit has a different register +* layout and extra registers. The ID register in the V2 peripheral +* unit on the OMAP4430 reports the same ID as the V1 peripheral +* unit on the OMAP3530, so we must inform the driver which IP +* version we know it is running on from platform / cpu-specific +* code using these constants in the hwmod class definition. +*/ + +#define OMAP_I2C_IP_VERSION_1 1 +#define OMAP_I2C_IP_VERSION_2 2 +struct omap_i2c_bus_platform_data {u32 clkrate;void (*set_mpu_wkup_lat)(struct device *dev,long set);
PATCH 4/18 I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision
In reply to Andy GreenSince we cannot trust (or even reliably find) the OMAP I2C peripheral unit's own revision register, we must inform the OMAP i2c driver of which IP version it is running on. We do this by tagging the omap_hwmod_class for i2c on all the OMAP2+ platform / cpu specific hwmod init and passing it up to the driver (next patches).
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1 + 4 files changed, 4 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_hwmod_2420_data.c +1 -0
@@ -1447,6 +1447,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {static struct omap_hwmod_class i2c_class = { .name ="i2c" , .sysc = &i2c_sysc, + .rev =OMAP_I2C_IP_VERSION_1 , };static struct omap_i2c_dev_attr i2c_dev_attr;
arch/arm/mach-omap2/omap_hwmod_2430_data.c +1 -0
@@ -1522,6 +1522,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {static struct omap_hwmod_class i2c_class = { .name ="i2c" , .sysc = &i2c_sysc, + .rev =OMAP_I2C_IP_VERSION_1 , };static struct omap_i2c_dev_attr i2c_dev_attr = {
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +1 -0
@@ -1465,6 +1465,7 @@ static struct omap_hwmod omap3xxx_uart4_hwmod = {static struct omap_hwmod_class i2c_class = { .name ="i2c" , .sysc = &i2c_sysc, + .rev =OMAP_I2C_IP_VERSION_1 , };/*
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0
@@ -2087,6 +2087,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_i2c_sysc = {static struct omap_hwmod_class omap44xx_i2c_hwmod_class = { .name ="i2c" , .sysc = &omap44xx_i2c_sysc, + .rev =OMAP_I2C_IP_VERSION_2 , };/* i2c1 */
PATCH 4/18 I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision
Same minor comment than before about the subject + typo. Should be:
OMAP2+: hwmod data: Tag all OMAP2+ hwmod definitions with I2C IP revision
Quoted 11 lines · Andy Green
Since we cannot trust (or even reliably find) the OMAP I2C peripheral unit's own revision register, we must inform the OMAP i2c driver of which IP version it is running on. We do this by tagging the
omap_hwmod_classfor i2c on all the OMAP2+ platform / cpu specific hwmod init and passing it up to the driver (next patches).Cc Ben Dooks<[email protected]>Reported-by Peter Maydell<[email protected]>Signed-off-by Andy Green<[email protected]>
Regards,
Benoit
Quoted 61 lines
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1 + 4 files changed, 4 insertions(+), 0 deletions(-)arch/arm/mach-omap2/omap_hwmod_2420_data.c +1
-0@@ -1447,6 +1447,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {static struct omap_hwmod_class i2c_class = { .name ="i2c" , .sysc =&i2c_sysc, + .rev =OMAP_I2C_IP_VERSION_1 , };static struct omap_i2c_dev_attr i2c_dev_attr;arch/arm/mach-omap2/omap_hwmod_2430_data.c +1
-0@@ -1522,6 +1522,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {static struct omap_hwmod_class i2c_class = { .name ="i2c" , .sysc =&i2c_sysc, + .rev =OMAP_I2C_IP_VERSION_1 , };static struct omap_i2c_dev_attr i2c_dev_attr = {arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +1
-0@@ -1465,6 +1465,7 @@ static struct omap_hwmod omap3xxx_uart4_hwmod = {static struct omap_hwmod_class i2c_class = { .name ="i2c" , .sysc =&i2c_sysc, + .rev =OMAP_I2C_IP_VERSION_1 , };/* arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1
-1@@ -2087,6 +2087,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_i2c_sysc = {static struct omap_hwmod_class omap44xx_i2c_hwmod_class = { .name ="i2c" , .sysc =&omap44xx_i2c_sysc, + .rev =OMAP_I2C_IP_VERSION_2 , };/* i2c1 */ --To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 5/18 I2C: OMAP: add rev to omap i2c platform data
In reply to Andy GreenWe need to pass the I2C IP revision from the hwmod class up into the OMAP I2C driver, which does not have direct access to it.
This adds a member to the platform data the OMAP I2C driver does use already to hold the I2C IP revision.
---
include/linux/i2c-omap.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
include/linux/i2c-omap.h +1 -0
@@ -17,6 +17,7 @@struct omap_i2c_bus_platform_data {u32 clkrate; +u32 rev;void (*set_mpu_wkup_lat)(struct device *dev,long set);int (*device_enable) (struct platform_device *pdev);int (*device_shutdown) (struct platform_device *pdev);
PATCH 6/18 I2C: OMAP1: set IP revision in platform data
In reply to Andy GreenAll OMAP1 are using "IP revision 1" in terms of register layout. We set this information in omap1_i2c_add_bus() so we don't have to use cpu_is_xxx() any more in the omap i2c driver.
---
arch/arm/plat-omap/i2c.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/plat-omap/i2c.c +3 -0
@@ -108,6 +108,9 @@ static inline int omap1_i2c_add_bus(int bus_id) res[1 ].start =INT_I2C ; pdata = &i2c_pdata[bus_id -1 ]; +/* all OMAP1 have IP version 1 register set */ + pdata->rev =OMAP_I2C_IP_VERSION_1 ; +return platform_device_register (pdev); }
PATCH 7/18 I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added
In reply to Andy GreenMark each OMAP I2C bus with the hwmod's knowledge of which I2C IP version is in the chip we're running on.
---
arch/arm/plat-omap/i2c.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
arch/arm/plat-omap/i2c.c +6 -0
@@ -155,6 +155,12 @@ static inline int omap2_i2c_add_bus(int bus_id) pdata = &i2c_pdata[bus_id -1 ];/* +* pass the hwmod class's CPU-specific knowledge of I2C IP revision in +* use up to the OMAP I2C driver via platform data +*/ + pdata->rev = oh->class->rev; + +/* * When waiting for completion of a i2c transfer, we need to * set a wake up latency constraint for the MPU. This is to * ensure quick enough wakeup from idle, when transfer
PATCH 8/18 I2C: OMAP2+: use platform_data ip revision to select register map
In reply to Andy GreenChange the register map names to reflect the IP revision they are representing, and use the platform_data IP revision index to select between them at init time.
Eliminates 1 of 17 cpu_...() calls in the driver.
---
drivers/i2c/busses/i2c-omap.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
drivers/i2c/busses/i2c-omap.c +5 -5
@@ -205,7 +205,7 @@ struct omap_i2c_dev {u16 errata; }; -const static u8 reg_map[] = { +const static u8 reg_map_ip_v1[] = { [OMAP_I2C_REV_REG ] =0x00 , [OMAP_I2C_IE_REG ] =0x01 , [OMAP_I2C_STAT_REG ] =0x02 ,
@@ -226,7 +226,7 @@ const static u8 reg_map[] = { [OMAP_I2C_BUFSTAT_REG] = 0x10, }; -const static u8 omap4_reg_map[] = { +const static u8 reg_map_ip_v2[] = { [OMAP_I2C_REV_REG ] =0x04 , [OMAP_I2C_IE_REG ] =0x2c , [OMAP_I2C_STAT_REG ] =0x28 ,
@@ -1037,10 +1037,10 @@ omap_i2c_probe(struct platform_device *pdev)else dev->reg_shift =2 ; -if (cpu_is_omap44xx ()) - dev->regs = (u8 *) omap4_reg_map; +if (pdata->rev ==OMAP_I2C_IP_VERSION_2 ) + dev->regs = (u8 *)reg_map_ip_v2;else - dev->regs = (u8 *) reg_map; + dev->regs = (u8 *)reg_map_ip_v1;pm_runtime_enable (&pdev->dev);omap_i2c_unidle (dev);
PATCH 9/18 I2C: OMAP2+: Solve array bounds overflow error on i2c idle
In reply to Andy GreenThis solves the main problem the patch series is about. Prior to this patch on OMAP3530 the driver wrongly interprets the I2C peripheral unit's own reported revision as meaning it is running on an IP V2 device and must use the extended registers.
In fact OMAP3530 is IP V1 with the smaller register set, the reason for the confusion is that the hardware does in fact report having the same IP revision index as is found on an OMAP4430, which really is IP V2 and has the extended registers.
This corrects the test for which registers to use so that it decides using hwmod knowledge found in the platform_data.
---
drivers/i2c/busses/i2c-omap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/i2c/busses/i2c-omap.c +1 -1
@@ -309,7 +309,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev) pdata = pdev->dev.platform_data; dev->iestate =omap_i2c_read_reg (dev,OMAP_I2C_IE_REG ); -if (dev->rev >=OMAP_I2C_REV_ON_4430 ) +if (pdata->rev ==OMAP_I2C_IP_VERSION_2 )omap_i2c_write_reg (dev,OMAP_I2C_IP_V2_IRQENABLE_CLR ,1 );else omap_i2c_write_reg (dev,OMAP_I2C_IE_REG ,0 );
PATCH 10/18 I2C: OMAP2+: address confused probed version naming
In reply to Andy GreenThe driver reflects the confusion that probed I2C revision from the hardware of 0x40 means it is on an OMAP4430.
However, you will probe the same 0x40 ID on an OMAP3530. So this patch changes the name to reflect that.
It also clarifies that the original name OMAP_I2C_REV_2 is referring to some ancient OMAP1 revision number, not to be confused with the IP revisions this patch series introduces.
Similarly the term "rev" is used in the ancient OMAP1 ISR, the term is changed to use omap1 instead.
---
drivers/i2c/busses/i2c-omap.c | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-)
drivers/i2c/busses/i2c-omap.c +10 -9
@@ -42,12 +42,12 @@#include <linux/pm_runtime.h> /* I2C controller revisions */ -#define OMAP_I2C_REV_2 0x20 +#define OMAP_I2C_OMAP1_REV_2 0x20/* I2C controller revisions present on specific hardware */ #define OMAP_I2C_REV_ON_2430 0x36#define OMAP_I2C_REV_ON_3430 0x3C -#define OMAP_I2C_REV_ON_4430 0x40 +#define OMAP_I2C_REV_ON_3530_4430 0x40/* timeout waiting for the controller to respond */ #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -314,7 +314,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)else omap_i2c_write_reg (dev,OMAP_I2C_IE_REG ,0 ); -if (dev->rev <OMAP_I2C_REV_2 ) { +if (dev->rev <OMAP_I2C_OMAP1_REV_2 ) { iv =omap_i2c_read_reg (dev,OMAP_I2C_IV_REG );/* Read clears */ }else {omap_i2c_write_reg (dev,OMAP_I2C_STAT_REG , dev->iestate);
@@ -336,7 +336,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)unsigned long internal_clk =0 ;struct clk *fclk; -if (dev->rev >=OMAP_I2C_REV_2 ) { +if (dev->rev >=OMAP_I2C_OMAP1_REV_2 ) {/* Disable I2C controller before soft reset */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, omap_i2c_read_reg(dev, OMAP_I2C_CON_REG) &
@@ -379,7 +379,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)* REVISIT: Some wkup sources might not be needed. */ dev->westate =OMAP_I2C_WE_ALL ; -if (dev->rev <OMAP_I2C_REV_ON_4430 ) +if (dev->rev <OMAP_I2C_REV_ON_3530_4430 )omap_i2c_write_reg (dev,OMAP_I2C_WE_REG , dev->westate); }
@@ -723,7 +723,7 @@ static inline void i2c_omap_errata_i207(struct omap_i2c_dev *dev, u16 stat)#ifdef CONFIG_ARCH_OMAP15XX static irqreturn_t -omap_i2c_rev1_isr (int this_irq,void *dev_id) +omap_i2c_omap1_isr (int this_irq,void *dev_id) {struct omap_i2c_dev *dev = dev_id;u16 iv, w;
@@ -777,7 +777,7 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id) return IRQ_HANDLED; }#else -#define omap_i2c_rev1_isr NULL +#define omap_i2c_omap1_isr NULL#endif /*
@@ -1062,7 +1062,7 @@ omap_i2c_probe(struct platform_device *pdev)* size. This is to ensure that we can handle the status on int * call back latencies. */ -if (dev->rev >=OMAP_I2C_REV_ON_4430 ) { +if (dev->rev >=OMAP_I2C_REV_ON_3530_4430 ) { dev->fifo_size =0 ; dev->b_hw =0 ;/* Disable hardware fixes */ }else {
@@ -1078,7 +1078,8 @@ omap_i2c_probe(struct platform_device *pdev)/* reset ASAP, clearing any IRQs */ omap_i2c_init (dev); - isr = (dev->rev <OMAP_I2C_REV_2 ) ? omap_i2c_rev1_isr : omap_i2c_isr; + isr = (dev->rev <OMAP_I2C_OMAP1_REV_2 ) ? omap_i2c_omap1_isr : + omap_i2c_isr; r =request_irq (dev->irq, isr,0 , pdev->name, dev);if (r) {
PATCH 11/18 I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32
In reply to Andy GreenAs part of removing cpu_...() from the OMAP I2C driver, we need to convert the CPU tests into functionality flags that are set by hwmod class in the same way the IP revision is.
More flags are needed than will fit in the existing u8 flags member of omap_i2c_dev_attr.
These flags can refer to options inside the IP block but they are most needed for information about cpu implementation specific options that are not part of the IP block itself. For example, how the CPU data bus is wired to the IP block databus differs between OMAP cpus and affects how you must shift the address in the IP block, but is not a feature of the IP block itself.
---
arch/arm/plat-omap/include/plat/i2c.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/plat-omap/include/plat/i2c.h +1 -1
@@ -47,7 +47,7 @@ static inline int omap_register_i2c_bus(int bus_id, u32 clkrate,*/ struct omap_i2c_dev_attr {u8 fifo_depth; -u8 flags; +u32 flags; };void __init omap1_i2c_mux_pins (int bus_id);
PATCH 12/18 I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data
In reply to Andy GreenOMAP I2C driver can access the configuration flags through its platform data.
---
include/linux/i2c-omap.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
include/linux/i2c-omap.h +1 -0
@@ -18,6 +18,7 @@struct omap_i2c_bus_platform_data {u32 clkrate;u32 rev; +u32 flags;void (*set_mpu_wkup_lat)(struct device *dev,long set);int (*device_enable) (struct platform_device *pdev);int (*device_shutdown) (struct platform_device *pdev);
PATCH 13/18 I2C: OMAP2+: Pass flags up to omap i2c platform_data as well
In reply to Andy GreenThis is how the driver can find the flags for its implementation functionality in its platform_data
---
arch/arm/plat-omap/i2c.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
arch/arm/plat-omap/i2c.c +6 -1
@@ -141,6 +141,7 @@ static inline int omap2_i2c_add_bus(int bus_id)struct omap_device *od;char oh_name[MAX_OMAP_I2C_HWMOD_NAME_LEN ];struct omap_i2c_bus_platform_data *pdata; +struct omap_i2c_dev_attr *dev_attr;omap2_i2c_mux_pins (bus_id);
@@ -156,10 +157,14 @@ static inline int omap2_i2c_add_bus(int bus_id) pdata = &i2c_pdata[bus_id -1 ];/* * pass the hwmod class's CPU-specific knowledge of I2C IP revision in -* use up to the OMAP I2C driver via platform data +* use, and functionality implementation flags, up to the OMAP I2C +* driver via platform data */ pdata->rev = oh->class->rev; + dev_attr = (struct omap_i2c_dev_attr *)oh->dev_attr; + pdata->flags = dev_attr->flags; +/* * When waiting for completion of a i2c transfer, we need to * set a wake up latency constraint for the MPU. This is to
PATCH 14/18 I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test
In reply to Andy GreenThese represent the 8 kinds of implementation functionality that up until now were inferred by the 16 remaining cpu_...() tests in the omap i2c driver.
---
include/linux/i2c-omap.h | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
include/linux/i2c-omap.h +15 -0
@@ -15,6 +15,21 @@#define OMAP_I2C_IP_VERSION_1 1#define OMAP_I2C_IP_VERSION_2 2 +/* struct omap_i2c_bus_platform_data .flags meanings */ + +#define OMAP_I2C_FLAG_NO_FIFO 1 +#define OMAP_I2C_FLAG_SIMPLE_CLOCK 2 +#define OMAP_I2C_FLAG_16BIT_DATA_REG 4 +#define OMAP_I2C_FLAG_RESET_REGS_POSTIDLE 8 +#define OMAP_I2C_FLAG_APPLY_ERRATA_I207 0x10 +#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK 0x20 +#define OMAP_I2C_FLAG_FORCE_19200_INT_CLK 0x40 +/* how the CPU address bus must be translated for I2C unit access */ +#define OMAP_I2C_FLAG_BUS_SHIFT_NONE 0 +#define OMAP_I2C_FLAG_BUS_SHIFT_1 0x80 +#define OMAP_I2C_FLAG_BUS_SHIFT_2 0x100 +#define OMAP_I2C_FLAG_BUS_SHIFT__SHIFT 7 +struct omap_i2c_bus_platform_data {u32 clkrate;u32 rev;
PATCH 14/18 I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test
include/linux/i2c-omap.h line 20
Quoted 3 lines · Andy Green
include/linux/i2c-omap.h +3
-0+/* struct omap_i2c_bus_platform_data .flags meanings */ + +#define OMAP_I2C_FLAG_NO_FIFO 1
Hi,
Minor comment, Can you use
BIT(0) for 1, BIT(1) for 2 ... BIT (8) for 0x100
Quoted 5 lines
include/linux/i2c-omap.h +5
-0+#define OMAP_I2C_FLAG_SIMPLE_CLOCK 2 +#define OMAP_I2C_FLAG_16BIT_DATA_REG 4 +#define OMAP_I2C_FLAG_RESET_REGS_POSTIDLE 8 +#define OMAP_I2C_FLAG_APPLY_ERRATA_I207 0x10 +#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK 0x20
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 14/18 I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test
On 03/09/2011 02:31 PM, Somebody in the thread at some point said:
Hi -
Quoted 2 lines
Minor comment, Can you use
BIT(0) for 1, BIT(1) for 2 ... BIT (8) for0x100
OK, I agree it will be nicer. Thanks for the comment.
I guess I can just change this and issue just this guy as try 3 rather than sending the whole series mostly unchanged. In that case, I'll take care of Benoit's member re-ordering to match the scripts at the same time and issue that guy as try 3 as well.
-Andy
PATCH 14/18 I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test
Quoted 7 lines · Andy Green
On 03/09/2011 02:31 PM, Somebody in the thread at some point said:
Hi -
Quoted 2 lines
Minor comment, Can you use
BIT(0) for 1, BIT(1) for 2 ... BIT (8) for0x100
Quoted 6 lines
OK, I agree it will be nicer. Thanks for the comment.
I guess I can just change this and issue just this guy as try 3 rather than sending the whole series mostly unchanged. In that case, I'll take care of Benoit's member re-ordering to match the scripts at the same time and issue that guy as try 3 as well.
It is up to Ben, but maybe it will be less confusing to re-send the whole series, since you have at least two patches to update.
Maybe, just wait a little bit in case someone else has something to say about this series.
Benoit
PATCH 15/18 I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr
In reply to Andy GreenThis adds the new functionality flags for omap i2c unit to all OMAP2 hwmod definitions
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 7 ++++++- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 3 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 +++++++++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 9 +++++++++ 4 files changed, 27 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/omap_hwmod_2420_data.c +6 -1
@@ -1450,7 +1450,12 @@ static struct omap_hwmod_class i2c_class = { .rev = OMAP_I2C_IP_VERSION_1, }; -static struct omap_i2c_dev_attr i2c_dev_attr; +static struct omap_i2c_dev_attr i2c_dev_attr = { + .flags =OMAP_I2C_FLAG_NO_FIFO | +OMAP_I2C_FLAG_SIMPLE_CLOCK | +OMAP_I2C_FLAG_16BIT_DATA_REG | +OMAP_I2C_FLAG_BUS_SHIFT_2 , +};/* I2C1 */
arch/arm/mach-omap2/omap_hwmod_2430_data.c +3 -0
@@ -1527,6 +1527,9 @@ static struct omap_hwmod_class i2c_class = {static struct omap_i2c_dev_attr i2c_dev_attr = { .fifo_depth =8 ,/* bytes */ + .flags =OMAP_I2C_FLAG_APPLY_ERRATA_I207 | +OMAP_I2C_FLAG_BUS_SHIFT_2 | +OMAP_I2C_FLAG_FORCE_19200_INT_CLK , };/* I2C1 */
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +9 -0
@@ -1876,6 +1876,9 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {static struct omap_i2c_dev_attr i2c1_dev_attr = { .fifo_depth =8 ,/* bytes */ + .flags =OMAP_I2C_FLAG_APPLY_ERRATA_I207 | +OMAP_I2C_FLAG_RESET_REGS_POSTIDLE | +OMAP_I2C_FLAG_BUS_SHIFT_2 , };static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
@@ -1919,6 +1922,9 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {static struct omap_i2c_dev_attr i2c2_dev_attr = { .fifo_depth =8 ,/* bytes */ + .flags =OMAP_I2C_FLAG_APPLY_ERRATA_I207 | +OMAP_I2C_FLAG_RESET_REGS_POSTIDLE | +OMAP_I2C_FLAG_BUS_SHIFT_2 , };static struct omap_hwmod_irq_info i2c2_mpu_irqs[] = {
@@ -1962,6 +1968,9 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {static struct omap_i2c_dev_attr i2c3_dev_attr = { .fifo_depth =64 ,/* bytes */ + .flags =OMAP_I2C_FLAG_APPLY_ERRATA_I207 | +OMAP_I2C_FLAG_RESET_REGS_POSTIDLE | +OMAP_I2C_FLAG_BUS_SHIFT_2 , };static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +9 -0
@@ -27,6 +27,7 @@#include <plat/mcspi.h> #include <plat/mcbsp.h> #include <plat/mmc.h> +#include <plat/i2c.h> #include "omap_hwmod_common_data.h"
@@ -2090,6 +2091,10 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class = { .rev = OMAP_I2C_IP_VERSION_2, }; +static struct omap_i2c_dev_attr i2c_dev_attr = { + .flags =OMAP_I2C_FLAG_BUS_SHIFT_NONE , +}; +/* i2c1 */ static struct omap_hwmod omap44xx_i2c1_hwmod;static struct omap_hwmod_irq_info omap44xx_i2c1_irqs[] = {
@@ -2140,6 +2145,7 @@ static struct omap_hwmod omap44xx_i2c1_hwmod = { }, .slaves = omap44xx_i2c1_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c1_slaves), + .dev_attr = &i2c_dev_attr, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), };
@@ -2193,6 +2199,7 @@ static struct omap_hwmod omap44xx_i2c2_hwmod = { }, .slaves = omap44xx_i2c2_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c2_slaves), + .dev_attr = &i2c_dev_attr, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), };
@@ -2246,6 +2253,7 @@ static struct omap_hwmod omap44xx_i2c3_hwmod = { }, .slaves = omap44xx_i2c3_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c3_slaves), + .dev_attr = &i2c_dev_attr, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), };
@@ -2299,6 +2307,7 @@ static struct omap_hwmod omap44xx_i2c4_hwmod = { }, .slaves = omap44xx_i2c4_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c4_slaves), + .dev_attr = &i2c_dev_attr, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), };
PATCH 15/18 I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr
Hi Andy,
Quoted 7 lines · Andy Green
This adds the new functionality flags for omap i2c unit to all OMAP2 hwmod definitions
Cc patches at linaro.orgCc Ben Dooks<[email protected]>Reported-by Peter Maydell<[email protected]>Signed-off-by Andy Green<[email protected]>
I have one minor comment about the OMAP4 dev_attr position in the structure. The point here is just to be aligned with the template used by the generator.
Quoted 87 lines
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 7 ++++++- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 3 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 +++++++++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 9 +++++++++ 4 files changed, 27 insertions(+), 1 deletions(-)arch/arm/mach-omap2/omap_hwmod_2420_data.c +6
-1@@ -1450,7 +1450,12 @@ static struct omap_hwmod_class i2c_class = { .rev = OMAP_I2C_IP_VERSION_1, }; -static struct omap_i2c_dev_attr i2c_dev_attr; +static struct omap_i2c_dev_attr i2c_dev_attr = { + .flags =OMAP_I2C_FLAG_NO_FIFO | +OMAP_I2C_FLAG_SIMPLE_CLOCK | +OMAP_I2C_FLAG_16BIT_DATA_REG | +OMAP_I2C_FLAG_BUS_SHIFT_2 , +};/* I2C1 */ arch/arm/mach-omap2/omap_hwmod_2430_data.c +3
-0@@ -1527,6 +1527,9 @@ static struct omap_hwmod_class i2c_class = {static struct omap_i2c_dev_attr i2c_dev_attr = { .fifo_depth =8 ,/* bytes */ + .flags =OMAP_I2C_FLAG_APPLY_ERRATA_I207 | +OMAP_I2C_FLAG_BUS_SHIFT_2 | +OMAP_I2C_FLAG_FORCE_19200_INT_CLK , };/* I2C1 */ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +9
-0@@ -1876,6 +1876,9 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {static struct omap_i2c_dev_attr i2c1_dev_attr = { .fifo_depth =8 ,/* bytes */ + .flags =OMAP_I2C_FLAG_APPLY_ERRATA_I207 | +OMAP_I2C_FLAG_RESET_REGS_POSTIDLE | +OMAP_I2C_FLAG_BUS_SHIFT_2 , };static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {@@ -1919,6 +1922,9 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {static struct omap_i2c_dev_attr i2c2_dev_attr = { .fifo_depth =8 ,/* bytes */ + .flags =OMAP_I2C_FLAG_APPLY_ERRATA_I207 | +OMAP_I2C_FLAG_RESET_REGS_POSTIDLE | +OMAP_I2C_FLAG_BUS_SHIFT_2 , };static struct omap_hwmod_irq_info i2c2_mpu_irqs[] = {@@ -1962,6 +1968,9 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {static struct omap_i2c_dev_attr i2c3_dev_attr = { .fifo_depth =64 ,/* bytes */ + .flags =OMAP_I2C_FLAG_APPLY_ERRATA_I207 | +OMAP_I2C_FLAG_RESET_REGS_POSTIDLE | +OMAP_I2C_FLAG_BUS_SHIFT_2 , };static struct omap_hwmod_irq_info i2c3_mpu_irqs[] = {arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1
-0@@ -27,6 +27,7 @@#include <plat/mcspi.h> #include <plat/mcbsp.h> #include <plat/mmc.h> +#include <plat/i2c.h> #include "omap_hwmod_common_data.h"
arch/arm/mach-omap2/omap_hwmod_44xx_data.c static struct omap_hwmod_class omap44xx_i2c_hwmod_class = { · line 2093
Quoted 3 lines
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0
-0@@ -2090,6 +2091,10 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class = { .rev = OMAP_I2C_IP_VERSION_2, };
The generator is adding a (probably useless...) comment on top of the structure. For the comment I'd prefer to stick to the template. I'll do a massive cleanup when every OMAP4 drivers will be migrated to hwmod. And then OMAP2 & 3 at some point will stick to that as well.
arch/arm/mach-omap2/omap_hwmod_44xx_data.c static struct omap_hwmod omap44xx_i2c1_hwmod = { · line 2145
Quoted 9 lines
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +4
-0+static struct omap_i2c_dev_attr i2c_dev_attr = { + .flags =OMAP_I2C_FLAG_BUS_SHIFT_NONE , +}; +/* i2c1 */ static struct omap_hwmod omap44xx_i2c1_hwmod;static struct omap_hwmod_irq_info omap44xx_i2c1_irqs[] = {@@ -2140,6 +2145,7 @@ static struct omap_hwmod omap44xx_i2c1_hwmod = { },
dev_attr is there in the template:
+ .dev_attr =&i2c_dev_attr,
Quoted 23 lines
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +3
-0.slaves = omap44xx_i2c1_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c1_slaves), + .dev_attr =&i2c_dev_attr, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), };@@ -2193,6 +2199,7 @@ static struct omap_hwmod omap44xx_i2c2_hwmod = { }, .slaves = omap44xx_i2c2_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c2_slaves), + .dev_attr =&i2c_dev_attr, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), };@@ -2246,6 +2253,7 @@ static struct omap_hwmod omap44xx_i2c3_hwmod = { }, .slaves = omap44xx_i2c3_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c3_slaves), + .dev_attr =&i2c_dev_attr, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), };
arch/arm/mach-omap2/omap_hwmod_44xx_data.c static struct omap_hwmod omap44xx_i2c4_hwmod = { · line 2312
Quoted 6 lines
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1
-0@@ -2299,6 +2307,7 @@ static struct omap_hwmod omap44xx_i2c4_hwmod = { }, .slaves = omap44xx_i2c4_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c4_slaves), + .dev_attr =&i2c_dev_attr, .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), };
The OMAP4 part should look like the patch below. I've just updated the scripts to add the new data you introduced.
Regards,
Benoit
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +10 -0
@@ -27,6 +27,7 @@#include <plat/mcspi.h> #include <plat/mcbsp.h> #include <plat/mmc.h> +#include <plat/i2c.h> #include "omap_hwmod_common_data.h"
@@ -2090,6 +2091,11 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class = { .rev = OMAP_I2C_IP_VERSION_2, }; +/* i2c dev_attr */ +static struct omap_i2c_dev_attr i2c_dev_attr = { + .flags =OMAP_I2C_FLAG_BUS_SHIFT_NONE , +}; +/* i2c1 */ static struct omap_hwmod omap44xx_i2c1_hwmod;static struct omap_hwmod_irq_info omap44xx_i2c1_irqs[] = {
@@ -2138,6 +2144,7 @@ static struct omap_hwmod omap44xx_i2c1_hwmod = { .clkctrl_reg = OMAP4430_CM_L4PER_I2C1_CLKCTRL, }, }, + .dev_attr = &i2c_dev_attr, .slaves = omap44xx_i2c1_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c1_slaves), .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -2191,6 +2198,7 @@ static struct omap_hwmod omap44xx_i2c2_hwmod = { .clkctrl_reg = OMAP4430_CM_L4PER_I2C2_CLKCTRL, }, }, + .dev_attr = &i2c_dev_attr, .slaves = omap44xx_i2c2_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c2_slaves), .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -2244,6 +2252,7 @@ static struct omap_hwmod omap44xx_i2c3_hwmod = { .clkctrl_reg = OMAP4430_CM_L4PER_I2C3_CLKCTRL, }, }, + .dev_attr = &i2c_dev_attr, .slaves = omap44xx_i2c3_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c3_slaves), .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -2297,6 +2306,7 @@ static struct omap_hwmod omap44xx_i2c4_hwmod = { .clkctrl_reg = OMAP4430_CM_L4PER_I2C4_CLKCTRL, }, }, + .dev_attr = &i2c_dev_attr, .slaves = omap44xx_i2c4_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_i2c4_slaves), .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
Signature · 1 line
1.7.0.4
PATCH 15/18 I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr
On 03/09/2011 01:49 PM, Somebody in the thread at some point said:
Hi -
Quoted 6 lines
I have one minor comment about the OMAP4
dev_attrposition in the structure. The point here is just to be aligned with the template used by the generator.Acked-by Benoit Cousson<[email protected]>
Quoted 7 lines
The generator is adding a (probably useless...) comment on top of the structure. For the comment I'd prefer to stick to the template. I'll do a massive cleanup when every OMAP4 drivers will be migrated to hwmod. And then OMAP2& 3 at some point will stick to that as well.
The OMAP4 part should look like the patch below. I've just updated the scripts to add the new data you introduced.
I'm fine if you just want to replace that stanza with yours that matches the script's member ordering. Thanks for a rapid review ^^
-Andy
PATCH 15/18 I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr
Quoted 15 lines · Andy Green
On 03/09/2011 01:49 PM, Somebody in the thread at some point said:
Hi -
Quoted 10 lines
I have one minor comment about the OMAP4
dev_attrposition in the structure. The point here is just to be aligned with the template used by the generator.Acked-by Benoit Cousson<[email protected]>The generator is adding a (probably useless...) comment on top of the structure. For the comment I'd prefer to stick to the template. I'll do a massive cleanup when every OMAP4 drivers will be migrated to
hwmod. And then OMAP2& 3 at some point will stick to that as well.
Quoted 5 lines
Quoted 2 lines
The OMAP4 part should look like the patch below. I've just updated the scripts to add the new data you introduced.
I'm fine if you just want to replace that stanza with yours that matches the script's member ordering. Thanks for a rapid review ^^
You can find it below. I changed as well the subject as suggested.
Benoit
---
PATCH 16/18 I2C: OMAP1: set i2c unit feature implementation flags in platform data
In reply to Andy GreenMost of the OMAP1 implementation flags are set statically, with the exception that omap7xx has its data bus wired up differently.
---
arch/arm/plat-omap/i2c.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-)
arch/arm/plat-omap/i2c.c +13 -0
@@ -111,6 +111,19 @@ static inline int omap1_i2c_add_bus(int bus_id)/* all OMAP1 have IP version 1 register set */ pdata->rev =OMAP_I2C_IP_VERSION_1 ; +/* all OMAP1 I2C are implemented like this */ + pdata->flags =OMAP_I2C_FLAG_NO_FIFO | +OMAP_I2C_FLAG_SIMPLE_CLOCK | +OMAP_I2C_FLAG_16BIT_DATA_REG | +OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK ; + +/* how the cpu bus is wired up differs for 7xx only */ + +if (cpu_is_omap7xx ()) + pdata->flags |=OMAP_I2C_FLAG_BUS_SHIFT_1 ; +else + pdata->flags |=OMAP_I2C_FLAG_BUS_SHIFT_2 ; +return platform_device_register (pdev); }
PATCH 17/18 I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data
In reply to Andy GreenThis patch eliminates all cpu_...() tests from the OMAP I2C driver.
Instead, it uses the functionality flags in the platform data to make the decisions about product variations the driver needs to handle.
---
drivers/i2c/busses/i2c-omap.c | 40 +++++++++++++++++++++++----------------- 1 files changed, 23 insertions(+), 17 deletions(-)
drivers/i2c/busses/i2c-omap.c +23 -17
@@ -277,7 +277,7 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)pm_runtime_get_sync (&pdev->dev); -if (cpu_is_omap34xx ()) { +if (pdata->flags &OMAP_I2C_FLAG_RESET_REGS_POSTIDLE ) {omap_i2c_write_reg (dev,OMAP_I2C_CON_REG ,0 );omap_i2c_write_reg (dev,OMAP_I2C_PSC_REG , dev->pscstate);omap_i2c_write_reg (dev,OMAP_I2C_SCLL_REG , dev->scllstate);
@@ -335,6 +335,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)unsigned long timeout;unsigned long internal_clk =0 ;struct clk *fclk; +struct platform_device *pdev; +struct omap_i2c_bus_platform_data *pdata; + + pdev =to_platform_device (dev->dev); + pdata = pdev->dev.platform_data;if (dev->rev >=OMAP_I2C_OMAP1_REV_2 ) {/* Disable I2C controller before soft reset */
@@ -386,7 +391,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) }omap_i2c_write_reg (dev,OMAP_I2C_CON_REG ,0 ); -if (cpu_class_is_omap1 ()) { +if (pdata->flags &OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK ) {/* * The I2C functional clock is the armxor_ck, so there's * no need to get "armxor_ck" separately. Now, if OMAP2420
@@ -410,7 +415,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) psc = fclk_rate /12000000 ; } -if (!(cpu_class_is_omap1 () ||cpu_is_omap2420 ())) { +if (!(pdata->flags &OMAP_I2C_FLAG_SIMPLE_CLOCK )) {/* * HSI2C controller internal clk rate should be 19.2 Mhz for
@@ -418,7 +423,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)* to get longer filter period for better noise suppression. * The filter is iclk (fclk for HS) period. */ -if (dev->speed >400 ||cpu_is_omap2430 ()) +if (dev->speed >400 || + pdata->flags &OMAP_I2C_FLAG_FORCE_19200_INT_CLK ) internal_clk =19200 ;else if (dev->speed >100 ) internal_clk =9600 ;
@@ -487,7 +493,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) dev->errata =0 ; -if (cpu_is_omap2430 () ||cpu_is_omap34xx ()) +if (pdata->flags &OMAP_I2C_FLAG_APPLY_ERRATA_I207 ) dev->errata |=I2C_OMAP_ERRATA_I207 ;/* Enable interrupts */
@@ -496,7 +502,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) OMAP_I2C_IE_AL) | ((dev->fifo_size) ? (OMAP_I2C_IE_RDR |OMAP_I2C_IE_XDR ) :0 );omap_i2c_write_reg (dev,OMAP_I2C_IE_REG , dev->iestate); -if (cpu_is_omap34xx ()) { +if (pdata->flags &OMAP_I2C_FLAG_RESET_REGS_POSTIDLE ) { dev->pscstate = psc; dev->scllstate = scll; dev->sclhstate = sclh;
@@ -816,6 +822,11 @@ omap_i2c_isr(int this_irq, void *dev_id)u16 bits;u16 stat, w;int err, count =0 ; +struct platform_device *pdev; +struct omap_i2c_bus_platform_data *pdata; + + pdev =to_platform_device (dev->dev); + pdata = pdev->dev.platform_data;if (dev->idle)return IRQ_NONE ;
@@ -884,8 +895,8 @@ complete:* Data reg in 2430, omap3 and * omap4 is 8 bit wide */ -if (cpu_class_is_omap1 () || -cpu_is_omap2420 ()) { +if (pdata->flags & +OMAP_I2C_FLAG_16BIT_DATA_REG ) {if (dev->buf_len) { *dev->buf++ = w >>8 ; dev->buf_len--;
@@ -927,8 +938,8 @@ complete:* Data reg in 2430, omap3 and * omap4 is 8 bit wide */ -if (cpu_class_is_omap1 () || -cpu_is_omap2420 ()) { +if (pdata->flags & +OMAP_I2C_FLAG_16BIT_DATA_REG ) {if (dev->buf_len) { w |= *dev->buf++ <<8 ; dev->buf_len--;
@@ -1030,12 +1041,7 @@ omap_i2c_probe(struct platform_device *pdev)platform_set_drvdata (pdev, dev); -if (cpu_is_omap7xx ()) - dev->reg_shift =1 ; -else if (cpu_is_omap44xx ()) - dev->reg_shift =0 ; -else - dev->reg_shift =2 ; + dev->reg_shift = (pdata->flags >>OMAP_I2C_FLAG_BUS_SHIFT__SHIFT ) &3 ;if (pdata->rev ==OMAP_I2C_IP_VERSION_2 ) dev->regs = (u8 *)reg_map_ip_v2;
@@ -1050,7 +1056,7 @@ omap_i2c_probe(struct platform_device *pdev)if (dev->rev <=OMAP_I2C_REV_ON_3430 ) dev->errata |=I2C_OMAP3_1P153 ; -if (!(cpu_class_is_omap1 () ||cpu_is_omap2420 ())) { +if (!(pdata->flags &OMAP_I2C_FLAG_NO_FIFO )) {u16 s;/* Set up the fifo size - Get total size */
PATCH 18/18 I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info
In reply to Andy GreenThe IP version is prepended to the existing printed probed version as an "epoch" version.
---
drivers/i2c/busses/i2c-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-omap.c +2 -2
@@ -1093,8 +1093,8 @@ omap_i2c_probe(struct platform_device *pdev) goto err_unuse_clocks; } -dev_info (dev->dev,"bus %d rev%d.%d at %d kHz\n" , - pdev->id, dev->rev >>4 , dev->rev &0xf , dev->speed); +dev_info (dev->dev,"bus %d rev%d.%d.%d at %d kHz\n" , pdev->id, + pdata->rev, dev->rev >>4 , dev->rev &0xf , dev->speed);omap_i2c_idle (dev);
cover I2C: OMAP: Fixes and removal of cpu_... from driver
In reply to Andy GreenHi Andy,
Thanks for that really fast update. That looks pretty good at first glance. I still have to review in details.
And we need to find some volunteers for OMAP1 & 2 testing.
Thanks,
Benoit
Quoted 57 lines · Andy Green
The following series removes cpu_...() usage completely from the omap-i2c driver by having decisions about functional implementation choices in the SoC held in cpu-specific hwmod tables that are already established, or for OMAP1 where there is no hwmod, set at OMAP1-specific i2c bus addition time.
Along the way it solves two issues with the existing implementation, that only 16-bit accesses are documented to be allowed to the I2C peripheral unit, and that due to a confusion in the existing driver about whether it is faced with a newer IP version on OMAP3530, currently it writes to a random non-existent I2C register at times on that platform.
The patch series is quite extended from the first try thanks to comments from Benoit Cousson.
Patches are tested on OMAP3530 and OMAP4430 I have but will need confirming they don't break anything on OMAP1xxx and OMAP2xxx as agreed with Benoit.
---
Andy Green (18):
I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown indev_info
I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data
I2C: OMAP1: set i2c unit feature implementation flags in platform data
I2C: OMAP2+: add correct functionality flags to all omap2plus i2cdev_attr
I2C: OMAP1/OMAP2+: create omap I2C functionality flags for eachcpu_... test
I2C: OMAP2+: Pass flags up to omap i2cplatform_dataas well
I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data
I2C: OMAP2+: increaseomap_i2c_dev_attrflags from u8 to u32
I2C: OMAP2+: address confused probed version naming
I2C: OMAP2+: Solve array bounds overflow error on i2c idle
I2C: OMAP2+: useplatform_dataip revision to select register map
I2C: OMAP2+: Pass hwmod rev knowledge viaplatform_datawhen i2c bus added
I2C: OMAP1: set IP revision in platform data
I2C: OMAP: add rev to omap i2c platform data
I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision
I2C: OMAP2+: Introduce I2C IP versioning constants
I2C: OMAP2+: Name registers in I2C IP V2 only accordingly
I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2carch/arm/mach-omap2/omap_hwmod_2420_data.c | 8 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 6 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 ++++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 ++++- arch/arm/plat-omap/i2c.c | 27 ++++++++ arch/arm/plat-omap/include/plat/i2c.h | 3 + drivers/i2c/busses/i2c-omap.c | 98 +++++++++++++++------------- include/linux/i2c-omap.h | 29 ++++++++ 8 files changed, 151 insertions(+), 51 deletions(-)
Tony Lindgren
maintainercover I2C: OMAP: Fixes and removal of cpu_... from driver
Quoted 4 lines · Cousson, Benoit
Hi Andy,
Thanks for that really fast update. That looks pretty good at first glance. I still have to review in details.
Yes nice job!
Quoted 1 line
And we need to find some volunteers for OMAP1 & 2 testing.
I gave it a quick try on osk5912, seems to work just fine. Will apply these for testing purposes to linux-omap tree while waiting for the minor fixes.
Looks like Benoit should take the arch/arm/*omap*/*hwmod* patches, the rest should go throug Ben. So for all of them:
cover I2C: OMAP: Fixes and removal of cpu_... from driver
Hi Tony,
Quoted 8 lines · Tony Lindgren
Quoted 4 lines · Cousson, Benoit
Hi Andy,
Thanks for that really fast update. That looks pretty good at first glance. I still have to review in details.
Yes nice job!
Quoted 8 lines
Quoted 1 line
And we need to find some volunteers for OMAP1& 2 testing.
I gave it a quick try on osk5912, seems to work just fine. Will apply these for testing purposes to linux-omap tree while waiting for the minor fixes.
Looks like Benoit should take the
arch/arm/*omap*/*hwmod*patches, the rest should go throug Ben. So for all of them:
Paul and I already acked the hwmod data, but the whole series should maybe go through Ben, because the hwmod files will need some defines added in the i2c header file. So we cannot separate the hwmod* patches from the driver files patches.
I just have one minor comment to keep the OMAP4 data in sync with the autogen, but if Andy does not have any important update to do on that series, I can potentially fix that later.
Regards
Benoit
Tony Lindgren
maintainercover I2C: OMAP: Fixes and removal of cpu_... from driver
Quoted 17 lines · Cousson, Benoit
Hi Tony,
Quoted 14 lines · Tony Lindgren
Quoted 4 lines · Cousson, Benoit
Hi Andy,
Thanks for that really fast update. That looks pretty good at first glance. I still have to review in details.
Yes nice job!
Quoted 1 line
And we need to find some volunteers for OMAP1& 2 testing.
I gave it a quick try on osk5912, seems to work just fine. Will apply these for testing purposes to linux-omap tree while waiting for the minor fixes.
Quoted 7 lines
Quoted 2 lines
Looks like Benoit should take the
arch/arm/*omap*/*hwmod*patches, the rest should go throug Ben. So for all of them:Paul and I already acked the hwmod data, but the whole series should maybe go through Ben, because the hwmod files will need some defines added in the i2c header file. So we cannot separate the hwmod* patches from the driver files patches.
Unfortunately the hwmod patches depend on omap-for-linus branch..
Considering this, it's probably best that I queue the whole series assuming we get acks from Ben for the driver related changes.
Quoted 3 lines
I just have one minor comment to keep the OMAP4 data in sync with the autogen, but if Andy does not have any important update to do on that series, I can potentially fix that later.
OK
Tony
Tony Lindgren
maintainercover I2C: OMAP: Fixes and removal of cpu_... from driver
Hi Ben & Andy,
Quoted 26 lines · Tony Lindgren
Quoted 17 lines · Cousson, Benoit
Hi Tony,
Quoted 14 lines · Tony Lindgren
Quoted 4 lines · Cousson, Benoit
Hi Andy,
Thanks for that really fast update. That looks pretty good at first glance. I still have to review in details.
Yes nice job!
Quoted 1 line
And we need to find some volunteers for OMAP1& 2 testing.
I gave it a quick try on osk5912, seems to work just fine. Will apply these for testing purposes to linux-omap tree while waiting for the minor fixes.
Quoted 7 lines
Quoted 2 lines
Looks like Benoit should take the
arch/arm/*omap*/*hwmod*patches, the rest should go throug Ben. So for all of them:Paul and I already acked the hwmod data, but the whole series should maybe go through Ben, because the hwmod files will need some defines added in the i2c header file. So we cannot separate the hwmod* patches from the driver files patches.
Quoted 4 lines
Unfortunately the hwmod patches depend on omap-for-linus branch..
Considering this, it's probably best that I queue the whole series assuming we get acks from Ben for the driver related changes.
After looking at this again, I've changed my mind.
It looks like this series can be rebased on v2.6.38-rc8 and should merge just fine with what we have queued in omap-for-linus. I guess I forgot we already did the i2c-omap hwmod conversion last merge window :)
Andy, please repost the related patches against v2.6.38-rc8 with the acks posted earlier.
Then Ben, please feel free to queue it after you get the rebased series. We've had this series applied for testing for a while.
Regards,
Tony
cover I2C: OMAP: Fixes and removal of cpu_... from driver
On 03/14/2011 05:42 PM, Somebody in the thread at some point said:
Hi -
Quoted 7 lines
It looks like this series can be rebased on v2.6.38-rc8 and should merge just fine with what we have queued in omap-for-linus. I guess I forgot we already did the i2c-omap hwmod conversion last merge window :)
Andy, please repost the related patches against v2.6.38-rc8 with the acks posted earlier.
Alright, I will do that with the reordered patch from Benoit and the change to BIT() instead of constants. Thanks.
-Andy