From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cousson, Benoit" Subject: Re: [PATCH 1/4] OMAP3 and 4 hwmod I2C units only allow 16 bit access Date: Fri, 4 Mar 2011 16:20:12 +0100 Message-ID: <4D71032C.9030909@ti.com> References: <20110303134744.30648.91218.stgit@otae.warmcat.com> <20110303135022.30648.8996.stgit@otae.warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from arroyo.ext.ti.com ([192.94.94.40]:60980 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759606Ab1CDPUT (ORCPT ); Fri, 4 Mar 2011 10:20:19 -0500 In-Reply-To: <20110303135022.30648.8996.stgit@otae.warmcat.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Andy Green Cc: "linux-arm-kernel@lists.infradead.org" , "linux-omap@vger.kernel.org" , "patches@linaro.org" , Andy Green One more minor comment about the order of the flags for OMAP4. On 3/3/2011 2:50 PM, Andy Green wrote: [...] > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > index ce646f2..c500416 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > @@ -2280,7 +2280,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_INIT_NO_RESET | HWMOD_16BIT_REG, Since this code is generated by script, the flags are sorted by name. HWMOD_16BIT_REG should then be the first one. This is of course applicable for the 4 instances. I already updated the generator to take the sysconfig register width into account. Thanks, Benoit > .mpu_irqs = omap44xx_i2c1_irqs, > .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c1_irqs), > .sdma_reqs = omap44xx_i2c1_sdma_reqs, > @@ -2396,7 +2396,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_INIT_NO_RESET | HWMOD_16BIT_REG, > .mpu_irqs = omap44xx_i2c2_irqs, > .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c2_irqs), > .sdma_reqs = omap44xx_i2c2_sdma_reqs, > @@ -2449,7 +2449,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_INIT_NO_RESET | HWMOD_16BIT_REG, > .mpu_irqs = omap44xx_i2c3_irqs, > .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c3_irqs), > .sdma_reqs = omap44xx_i2c3_sdma_reqs, > @@ -2502,7 +2502,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_INIT_NO_RESET | HWMOD_16BIT_REG, > .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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: b-cousson@ti.com (Cousson, Benoit) Date: Fri, 4 Mar 2011 16:20:12 +0100 Subject: [PATCH 1/4] OMAP3 and 4 hwmod I2C units only allow 16 bit access In-Reply-To: <20110303135022.30648.8996.stgit@otae.warmcat.com> References: <20110303134744.30648.91218.stgit@otae.warmcat.com> <20110303135022.30648.8996.stgit@otae.warmcat.com> Message-ID: <4D71032C.9030909@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org One more minor comment about the order of the flags for OMAP4. On 3/3/2011 2:50 PM, Andy Green wrote: [...] > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > index ce646f2..c500416 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > @@ -2280,7 +2280,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_INIT_NO_RESET | HWMOD_16BIT_REG, Since this code is generated by script, the flags are sorted by name. HWMOD_16BIT_REG should then be the first one. This is of course applicable for the 4 instances. I already updated the generator to take the sysconfig register width into account. Thanks, Benoit > .mpu_irqs = omap44xx_i2c1_irqs, > .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c1_irqs), > .sdma_reqs = omap44xx_i2c1_sdma_reqs, > @@ -2396,7 +2396,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_INIT_NO_RESET | HWMOD_16BIT_REG, > .mpu_irqs = omap44xx_i2c2_irqs, > .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c2_irqs), > .sdma_reqs = omap44xx_i2c2_sdma_reqs, > @@ -2449,7 +2449,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_INIT_NO_RESET | HWMOD_16BIT_REG, > .mpu_irqs = omap44xx_i2c3_irqs, > .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_i2c3_irqs), > .sdma_reqs = omap44xx_i2c3_sdma_reqs, > @@ -2502,7 +2502,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_INIT_NO_RESET | HWMOD_16BIT_REG, > .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