| Message ID | 1350899218-13624-6-git-send-email-balbi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Felipe, On 10/22/2012 11:46 AM, Felipe Balbi wrote: > on OMAP4+ we want to read IRQSTATUS_RAW register, > instead of IRQSTATUS. The reason being that IRQSTATUS > will only contain the bits which were enabled on > IRQENABLE_SET and that will break when we need to > poll for a certain bit which wasn't enabled as an > IRQ source. > > One such case is after we finish converting to > deferred stop bit, we will have to poll for ARDY > bit before returning control for the client driver > in order to prevent us from trying to start a > transfer on a bus which is already busy. > > Note, however, that omap-i2c.c needs a big rework > on register definition and register access. Such > work will be done in a separate series of patches. Do you need OMAP_I2C_IP_VERSION_3 for OMAP4? OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs omap4430 because they were sharing the same IP version.. /* I2C controller revisions present on specific hardware */ #define OMAP_I2C_REV_ON_2430 0x36 #define OMAP_I2C_REV_ON_3430_3530 0x3C #define OMAP_I2C_REV_ON_3630_4430 0x40 So in theory you should not need an extra version. Regards, Benoit
Hi, On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote: > Hi Felipe, > > On 10/22/2012 11:46 AM, Felipe Balbi wrote: > > on OMAP4+ we want to read IRQSTATUS_RAW register, > > instead of IRQSTATUS. The reason being that IRQSTATUS > > will only contain the bits which were enabled on > > IRQENABLE_SET and that will break when we need to > > poll for a certain bit which wasn't enabled as an > > IRQ source. > > > > One such case is after we finish converting to > > deferred stop bit, we will have to poll for ARDY > > bit before returning control for the client driver > > in order to prevent us from trying to start a > > transfer on a bus which is already busy. > > > > Note, however, that omap-i2c.c needs a big rework > > on register definition and register access. Such > > work will be done in a separate series of patches. > > Do you need OMAP_I2C_IP_VERSION_3 for OMAP4? > > OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs > omap4430 because they were sharing the same IP version.. > > /* I2C controller revisions present on specific hardware */ > #define OMAP_I2C_REV_ON_2430 0x36 > #define OMAP_I2C_REV_ON_3430_3530 0x3C > #define OMAP_I2C_REV_ON_3630_4430 0x40 > > So in theory you should not need an extra version. are you sure that's how they're used ? Looking at the code where we choose reg_map_ip_v1 and reg_map_ip_v2: 1120 if (dev->dtrev == OMAP_I2C_IP_VERSION_2) 1121 dev->regs = (u8 *)reg_map_ip_v2; 1122 else 1123 dev->regs = (u8 *)reg_map_ip_v1; And looking at reg_map_ip_v1: 218 static const u8 reg_map_ip_v1[] = { 219 [OMAP_I2C_REV_REG] = 0x00, 220 [OMAP_I2C_IE_REG] = 0x01, 221 [OMAP_I2C_STAT_REG] = 0x02, 222 [OMAP_I2C_IV_REG] = 0x03, 223 [OMAP_I2C_WE_REG] = 0x03, 224 [OMAP_I2C_SYSS_REG] = 0x04, 225 [OMAP_I2C_BUF_REG] = 0x05, 226 [OMAP_I2C_CNT_REG] = 0x06, 227 [OMAP_I2C_DATA_REG] = 0x07, 228 [OMAP_I2C_SYSC_REG] = 0x08, 229 [OMAP_I2C_CON_REG] = 0x09, 230 [OMAP_I2C_OA_REG] = 0x0a, 231 [OMAP_I2C_SA_REG] = 0x0b, 232 [OMAP_I2C_PSC_REG] = 0x0c, 233 [OMAP_I2C_SCLL_REG] = 0x0d, 234 [OMAP_I2C_SCLH_REG] = 0x0e, 235 [OMAP_I2C_SYSTEST_REG] = 0x0f, 236 [OMAP_I2C_BUFSTAT_REG] = 0x10, 237 }; that's really not the register map on OMAP3. That only looks valid for OMAP1. -ECONFUSED
On 10/22/2012 02:28 PM, Felipe Balbi wrote: > Hi, > > On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote: >> Hi Felipe, >> >> On 10/22/2012 11:46 AM, Felipe Balbi wrote: >>> on OMAP4+ we want to read IRQSTATUS_RAW register, >>> instead of IRQSTATUS. The reason being that IRQSTATUS >>> will only contain the bits which were enabled on >>> IRQENABLE_SET and that will break when we need to >>> poll for a certain bit which wasn't enabled as an >>> IRQ source. >>> >>> One such case is after we finish converting to >>> deferred stop bit, we will have to poll for ARDY >>> bit before returning control for the client driver >>> in order to prevent us from trying to start a >>> transfer on a bus which is already busy. >>> >>> Note, however, that omap-i2c.c needs a big rework >>> on register definition and register access. Such >>> work will be done in a separate series of patches. >> >> Do you need OMAP_I2C_IP_VERSION_3 for OMAP4? >> >> OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs >> omap4430 because they were sharing the same IP version.. >> >> /* I2C controller revisions present on specific hardware */ >> #define OMAP_I2C_REV_ON_2430 0x36 >> #define OMAP_I2C_REV_ON_3430_3530 0x3C >> #define OMAP_I2C_REV_ON_3630_4430 0x40 >> >> So in theory you should not need an extra version. > > are you sure that's how they're used ? Looking at the code where we > choose reg_map_ip_v1 and reg_map_ip_v2: > > 1120 if (dev->dtrev == OMAP_I2C_IP_VERSION_2) > 1121 dev->regs = (u8 *)reg_map_ip_v2; > 1122 else > 1123 dev->regs = (u8 *)reg_map_ip_v1; > > And looking at reg_map_ip_v1: > > 218 static const u8 reg_map_ip_v1[] = { > 219 [OMAP_I2C_REV_REG] = 0x00, > 220 [OMAP_I2C_IE_REG] = 0x01, > 221 [OMAP_I2C_STAT_REG] = 0x02, > 222 [OMAP_I2C_IV_REG] = 0x03, > 223 [OMAP_I2C_WE_REG] = 0x03, > 224 [OMAP_I2C_SYSS_REG] = 0x04, > 225 [OMAP_I2C_BUF_REG] = 0x05, > 226 [OMAP_I2C_CNT_REG] = 0x06, > 227 [OMAP_I2C_DATA_REG] = 0x07, > 228 [OMAP_I2C_SYSC_REG] = 0x08, > 229 [OMAP_I2C_CON_REG] = 0x09, > 230 [OMAP_I2C_OA_REG] = 0x0a, > 231 [OMAP_I2C_SA_REG] = 0x0b, > 232 [OMAP_I2C_PSC_REG] = 0x0c, > 233 [OMAP_I2C_SCLL_REG] = 0x0d, > 234 [OMAP_I2C_SCLH_REG] = 0x0e, > 235 [OMAP_I2C_SYSTEST_REG] = 0x0f, > 236 [OMAP_I2C_BUFSTAT_REG] = 0x10, > 237 }; > > that's really not the register map on OMAP3. That only looks valid for > OMAP1. No that should be valid as well for OMAP2&3 thanks to the OMAP_I2C_FLAG_BUS_SHIFT_2. It was introduced during DT adaptation: #ifdef CONFIG_OF static struct omap_i2c_bus_platform_data omap3_pdata = { .rev = OMAP_I2C_IP_VERSION_1, .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 | OMAP_I2C_FLAG_RESET_REGS_POSTIDLE | OMAP_I2C_FLAG_BUS_SHIFT_2, }; static struct omap_i2c_bus_platform_data omap4_pdata = { .rev = OMAP_I2C_IP_VERSION_2, }; static const struct of_device_id omap_i2c_of_match[] = { { .compatible = "ti,omap4-i2c", .data = &omap4_pdata, }, { .compatible = "ti,omap3-i2c", .data = &omap3_pdata, }, { }, }; MODULE_DEVICE_TABLE(of, omap_i2c_of_match); #endif > -ECONFUSED Well, it is confusing... Benoit
Hi, On Mon, Oct 22, 2012 at 03:05:20PM +0200, Benoit Cousson wrote: > On 10/22/2012 02:28 PM, Felipe Balbi wrote: > > Hi, > > > > On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote: > >> Hi Felipe, > >> > >> On 10/22/2012 11:46 AM, Felipe Balbi wrote: > >>> on OMAP4+ we want to read IRQSTATUS_RAW register, > >>> instead of IRQSTATUS. The reason being that IRQSTATUS > >>> will only contain the bits which were enabled on > >>> IRQENABLE_SET and that will break when we need to > >>> poll for a certain bit which wasn't enabled as an > >>> IRQ source. > >>> > >>> One such case is after we finish converting to > >>> deferred stop bit, we will have to poll for ARDY > >>> bit before returning control for the client driver > >>> in order to prevent us from trying to start a > >>> transfer on a bus which is already busy. > >>> > >>> Note, however, that omap-i2c.c needs a big rework > >>> on register definition and register access. Such > >>> work will be done in a separate series of patches. > >> > >> Do you need OMAP_I2C_IP_VERSION_3 for OMAP4? > >> > >> OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs > >> omap4430 because they were sharing the same IP version.. > >> > >> /* I2C controller revisions present on specific hardware */ > >> #define OMAP_I2C_REV_ON_2430 0x36 > >> #define OMAP_I2C_REV_ON_3430_3530 0x3C > >> #define OMAP_I2C_REV_ON_3630_4430 0x40 > >> > >> So in theory you should not need an extra version. > > > > are you sure that's how they're used ? Looking at the code where we > > choose reg_map_ip_v1 and reg_map_ip_v2: > > > > 1120 if (dev->dtrev == OMAP_I2C_IP_VERSION_2) > > 1121 dev->regs = (u8 *)reg_map_ip_v2; > > 1122 else > > 1123 dev->regs = (u8 *)reg_map_ip_v1; > > > > And looking at reg_map_ip_v1: > > > > 218 static const u8 reg_map_ip_v1[] = { > > 219 [OMAP_I2C_REV_REG] = 0x00, > > 220 [OMAP_I2C_IE_REG] = 0x01, > > 221 [OMAP_I2C_STAT_REG] = 0x02, > > 222 [OMAP_I2C_IV_REG] = 0x03, > > 223 [OMAP_I2C_WE_REG] = 0x03, > > 224 [OMAP_I2C_SYSS_REG] = 0x04, > > 225 [OMAP_I2C_BUF_REG] = 0x05, > > 226 [OMAP_I2C_CNT_REG] = 0x06, > > 227 [OMAP_I2C_DATA_REG] = 0x07, > > 228 [OMAP_I2C_SYSC_REG] = 0x08, > > 229 [OMAP_I2C_CON_REG] = 0x09, > > 230 [OMAP_I2C_OA_REG] = 0x0a, > > 231 [OMAP_I2C_SA_REG] = 0x0b, > > 232 [OMAP_I2C_PSC_REG] = 0x0c, > > 233 [OMAP_I2C_SCLL_REG] = 0x0d, > > 234 [OMAP_I2C_SCLH_REG] = 0x0e, > > 235 [OMAP_I2C_SYSTEST_REG] = 0x0f, > > 236 [OMAP_I2C_BUFSTAT_REG] = 0x10, > > 237 }; > > > > that's really not the register map on OMAP3. That only looks valid for > > OMAP1. > > No that should be valid as well for OMAP2&3 thanks to the > OMAP_I2C_FLAG_BUS_SHIFT_2. aha.. I see. What a hack! > It was introduced during DT adaptation: > > #ifdef CONFIG_OF > static struct omap_i2c_bus_platform_data omap3_pdata = { > .rev = OMAP_I2C_IP_VERSION_1, > .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 | > OMAP_I2C_FLAG_RESET_REGS_POSTIDLE | > OMAP_I2C_FLAG_BUS_SHIFT_2, > }; > > static struct omap_i2c_bus_platform_data omap4_pdata = { > .rev = OMAP_I2C_IP_VERSION_2, > }; > > static const struct of_device_id omap_i2c_of_match[] = { > { > .compatible = "ti,omap4-i2c", > .data = &omap4_pdata, > }, > { > .compatible = "ti,omap3-i2c", > .data = &omap3_pdata, > }, > { }, > }; > MODULE_DEVICE_TABLE(of, omap_i2c_of_match); > #endif > > > > -ECONFUSED > > Well, it is confusing... Tell me about it... in that case, $SUBJECT can be dropped silently, I will respin next patch so that it checks for VERSION_2 instead of VERSION_3. cheers.
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c index fc57e67..e871928 100644 --- a/arch/arm/mach-omap2/i2c.c +++ b/arch/arm/mach-omap2/i2c.c @@ -66,7 +66,8 @@ int omap_i2c_reset(struct omap_hwmod *oh) u16 i2c_con; int c = 0; - if (oh->class->rev == OMAP_I2C_IP_VERSION_2) { + if ((oh->class->rev == OMAP_I2C_IP_VERSION_2) || + (oh->class->rev == OMAP_I2C_IP_VERSION_3)) { i2c_con = OMAP4_I2C_CON_OFFSET; } else if (oh->class->rev == OMAP_I2C_IP_VERSION_1) { i2c_con = OMAP2_I2C_CON_OFFSET; diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 652d028..ae9c023 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -1521,7 +1521,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, + .rev = OMAP_I2C_IP_VERSION_3, .reset = &omap_i2c_reset, }; diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 6219522..c65d526 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -271,8 +271,18 @@ static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev, static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg) { - return __raw_readw(i2c_dev->base + + /* if we are OMAP_I2C_IP_VERSION_3, we need to read from + * IRQSTATUS_RAW, but write to IRQSTATUS + */ + if ((i2c_dev->dtrev == OMAP_I2C_IP_VERSION_3) && + (reg == OMAP_I2C_STAT_REG)) { + return __raw_readw(i2c_dev->base + + ((i2c_dev->regs[reg] - 0x04) + << i2c_dev->reg_shift)); + } else { + return __raw_readw(i2c_dev->base + (i2c_dev->regs[reg] << i2c_dev->reg_shift)); + } } static int omap_i2c_init(struct omap_i2c_dev *dev) @@ -1124,10 +1134,18 @@ omap_i2c_probe(struct platform_device *pdev) dev->reg_shift = (dev->flags >> OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) & 3; - if (dev->dtrev == OMAP_I2C_IP_VERSION_2) - dev->regs = (u8 *)reg_map_ip_v2; - else + switch (dev->dtrev) { + case OMAP_I2C_IP_VERSION_1: dev->regs = (u8 *)reg_map_ip_v1; + break; + case OMAP_I2C_IP_VERSION_2: + /* FALLTHROUGH */ + case OMAP_I2C_IP_VERSION_3: + /* FALLTHROUGH */ + default: + dev->regs = (u8 *)reg_map_ip_v2; + break; + } pm_runtime_enable(dev->dev); pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT); diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h index df804ba..84f7355 100644 --- a/include/linux/i2c-omap.h +++ b/include/linux/i2c-omap.h @@ -14,6 +14,7 @@ #define OMAP_I2C_IP_VERSION_1 1 #define OMAP_I2C_IP_VERSION_2 2 +#define OMAP_I2C_IP_VERSION_3 3 /* struct omap_i2c_bus_platform_data .flags meanings */
on OMAP4+ we want to read IRQSTATUS_RAW register, instead of IRQSTATUS. The reason being that IRQSTATUS will only contain the bits which were enabled on IRQENABLE_SET and that will break when we need to poll for a certain bit which wasn't enabled as an IRQ source. One such case is after we finish converting to deferred stop bit, we will have to poll for ARDY bit before returning control for the client driver in order to prevent us from trying to start a transfer on a bus which is already busy. Note, however, that omap-i2c.c needs a big rework on register definition and register access. Such work will be done in a separate series of patches. Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> --- arch/arm/mach-omap2/i2c.c | 3 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +- drivers/i2c/busses/i2c-omap.c | 26 ++++++++++++++++++++++---- include/linux/i2c-omap.h | 1 + 4 files changed, 26 insertions(+), 6 deletions(-)