| Message ID | 1306375016-707-4-git-send-email-nm@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Menon, Nishanth > Sent: Thursday, May 26, 2011 7:27 AM > To: linux-omap > Cc: Sonasath, Moiz; Menon, Nishanth > Subject: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 > during HWMOD init [sp] typo in the subject. "DO" -> "Do" Another nit: Are 2 HWMODs required in the subject? ~sanjeev > > From: Moiz Sonasath <m-sonasath@ti.com> > > For OMAP4460, GPIO-7 of bank1 is used for controling > the TPS modes, hence GPIO1 should not be reset > during init as reset will cause the TPS voltage to > drop to 0.9 V. > > Originally from: > http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=52ae > 4f0de03b17c064d9ce90a580230f1a596ec1 > > [nm@ti.com: upstream version] > Signed-off-by: Nishanth Menon <nm@ti.com> > Signed-off-by: Moiz Sonasath <m-sonasath@ti.com> > --- > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 27 > ++++++++++++++++++++++++--- > 1 files changed, 24 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > index 2f51a5a..27319c4 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > @@ -1745,7 +1745,7 @@ static struct omap_hwmod_opt_clk > gpio1_opt_clks[] = { > { .role = "dbclk", .clk = "gpio1_dbclk" }, > }; > > -static struct omap_hwmod omap44xx_gpio1_hwmod = { > +static struct omap_hwmod omap443x_gpio1_hwmod = { > .name = "gpio1", > .class = &omap44xx_gpio_hwmod_class, > .mpu_irqs = omap44xx_gpio1_irqs, > @@ -1761,7 +1761,27 @@ static struct omap_hwmod > omap44xx_gpio1_hwmod = { > .dev_attr = &gpio_dev_attr, > .slaves = omap44xx_gpio1_slaves, > .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), > - .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX), > + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), > +}; > + > +static struct omap_hwmod omap446x_gpio1_hwmod = { > + .name = "gpio1", > + .class = &omap44xx_gpio_hwmod_class, > + .flags = HWMOD_INIT_NO_RESET, > + .mpu_irqs = omap44xx_gpio1_irqs, > + .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs), > + .main_clk = "gpio1_ick", > + .prcm = { > + .omap4 = { > + .clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL, > + }, > + }, > + .opt_clks = gpio1_opt_clks, > + .opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks), > + .dev_attr = &gpio_dev_attr, > + .slaves = omap44xx_gpio1_slaves, > + .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), > + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460), > }; > > /* gpio2 */ > @@ -5079,7 +5099,8 @@ static __initdata struct omap_hwmod > *omap44xx_hwmods[] = { > &omap44xx_dss_venc_hwmod, > > /* gpio class */ > - &omap44xx_gpio1_hwmod, > + &omap443x_gpio1_hwmod, > + &omap446x_gpio1_hwmod, > &omap44xx_gpio2_hwmod, > &omap44xx_gpio3_hwmod, > &omap44xx_gpio4_hwmod, > -- > 1.7.1 > > -- > 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 > -- 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
On 14:06-20110526, Premi, Sanjeev wrote: > > -----Original Message----- > > From: linux-omap-owner@vger.kernel.org > > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Menon, Nishanth > > Sent: Thursday, May 26, 2011 7:27 AM > > To: linux-omap > > Cc: Sonasath, Moiz; Menon, Nishanth > > Subject: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 > > during HWMOD init > > [sp] typo in the subject. "DO" -> "Do" > > Another nit: Are 2 HWMODs required in the subject? :) thanks. will fix.
Nishanth Menon <nm@ti.com> writes: > From: Moiz Sonasath <m-sonasath@ti.com> > > For OMAP4460, GPIO-7 of bank1 is used for controling > the TPS modes, hence GPIO1 should not be reset > during init as reset will cause the TPS voltage to > drop to 0.9 V. ouch. I knew one of these days something like this was going to happen with GPIO resets. Re: $SUBJECT, hwmod is not an acronym. Please use lower case. > Originally from: > http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=52ae4f0de03b17c064d9ce90a580230f1a596ec1 > > [nm@ti.com: upstream version] > Signed-off-by: Nishanth Menon <nm@ti.com> > Signed-off-by: Moiz Sonasath <m-sonasath@ti.com> > --- > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 27 ++++++++++++++++++++++++--- > 1 files changed, 24 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > index 2f51a5a..27319c4 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c > @@ -1745,7 +1745,7 @@ static struct omap_hwmod_opt_clk gpio1_opt_clks[] = { > { .role = "dbclk", .clk = "gpio1_dbclk" }, > }; > > -static struct omap_hwmod omap44xx_gpio1_hwmod = { > +static struct omap_hwmod omap443x_gpio1_hwmod = { > .name = "gpio1", > .class = &omap44xx_gpio_hwmod_class, > .mpu_irqs = omap44xx_gpio1_irqs, > @@ -1761,7 +1761,27 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = { > .dev_attr = &gpio_dev_attr, > .slaves = omap44xx_gpio1_slaves, > .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), > - .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX), > + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), > +}; > + > +static struct omap_hwmod omap446x_gpio1_hwmod = { > + .name = "gpio1", > + .class = &omap44xx_gpio_hwmod_class, > + .flags = HWMOD_INIT_NO_RESET, > + .mpu_irqs = omap44xx_gpio1_irqs, > + .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs), > + .main_clk = "gpio1_ick", > + .prcm = { > + .omap4 = { > + .clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL, > + }, > + }, > + .opt_clks = gpio1_opt_clks, > + .opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks), > + .dev_attr = &gpio_dev_attr, > + .slaves = omap44xx_gpio1_slaves, > + .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), > + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460), > }; This is a board-specific problem that you've "fixed" in a way that affects every 4460-based device. Rather than setting the flag in the hwmod data, you need to fix this in a board-specific way. The hwmod layer provides an API for this: omap_hwmod_no_setup_reset() which should be called by board-specific code. Kevin > /* gpio2 */ > @@ -5079,7 +5099,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = { > &omap44xx_dss_venc_hwmod, > > /* gpio class */ > - &omap44xx_gpio1_hwmod, > + &omap443x_gpio1_hwmod, > + &omap446x_gpio1_hwmod, > &omap44xx_gpio2_hwmod, > &omap44xx_gpio3_hwmod, > &omap44xx_gpio4_hwmod, -- 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
On Thu, May 26, 2011 at 16:24, Kevin Hilman <khilman@ti.com> wrote: > Nishanth Menon <nm@ti.com> writes: > >> From: Moiz Sonasath <m-sonasath@ti.com> >> >> For OMAP4460, GPIO-7 of bank1 is used for controling >> the TPS modes, hence GPIO1 should not be reset >> during init as reset will cause the TPS voltage to >> drop to 0.9 V. > > ouch. I knew one of these days something like this was going to happen > with GPIO resets. > > Re: $SUBJECT, hwmod is not an acronym. Please use lower case. > >> Originally from: >> http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=52ae4f0de03b17c064d9ce90a580230f1a596ec1 >> >> [nm@ti.com: upstream version] >> Signed-off-by: Nishanth Menon <nm@ti.com> >> Signed-off-by: Moiz Sonasath <m-sonasath@ti.com> >> --- >> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 27 ++++++++++++++++++++++++--- >> 1 files changed, 24 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c >> index 2f51a5a..27319c4 100644 >> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c >> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c >> @@ -1745,7 +1745,7 @@ static struct omap_hwmod_opt_clk gpio1_opt_clks[] = { >> { .role = "dbclk", .clk = "gpio1_dbclk" }, >> }; >> >> -static struct omap_hwmod omap44xx_gpio1_hwmod = { >> +static struct omap_hwmod omap443x_gpio1_hwmod = { >> .name = "gpio1", >> .class = &omap44xx_gpio_hwmod_class, >> .mpu_irqs = omap44xx_gpio1_irqs, >> @@ -1761,7 +1761,27 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = { >> .dev_attr = &gpio_dev_attr, >> .slaves = omap44xx_gpio1_slaves, >> .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), >> - .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX), >> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), >> +}; >> + >> +static struct omap_hwmod omap446x_gpio1_hwmod = { >> + .name = "gpio1", >> + .class = &omap44xx_gpio_hwmod_class, >> + .flags = HWMOD_INIT_NO_RESET, >> + .mpu_irqs = omap44xx_gpio1_irqs, >> + .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs), >> + .main_clk = "gpio1_ick", >> + .prcm = { >> + .omap4 = { >> + .clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL, >> + }, >> + }, >> + .opt_clks = gpio1_opt_clks, >> + .opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks), >> + .dev_attr = &gpio_dev_attr, >> + .slaves = omap44xx_gpio1_slaves, >> + .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), >> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460), >> }; > > This is a board-specific problem that you've "fixed" in a way that > affects every 4460-based device. > > Rather than setting the flag in the hwmod data, you need to fix this > in a board-specific way. > > The hwmod layer provides an API for this: omap_hwmod_no_setup_reset() > which should be called by board-specific code. > aah - a better solution.. thanks. Regards, Nishanth Menon -- 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
On 5/27/2011 1:24 AM, Hilman, Kevin wrote: > Nishanth Menon<nm@ti.com> writes: > >> From: Moiz Sonasath<m-sonasath@ti.com> >> >> For OMAP4460, GPIO-7 of bank1 is used for controling >> the TPS modes, hence GPIO1 should not be reset >> during init as reset will cause the TPS voltage to >> drop to 0.9 V. > > ouch. I knew one of these days something like this was going to happen > with GPIO resets. BTW, don't we have the same kind of issue with the debug UART? I remember that you had to do some hacks at some point to change these hwmod flags in the UART code. In general we do not want to reset nor idle an IP that was potentially already properly configured by bootloader or early Linux boot code. Regards, Benoit > > Re: $SUBJECT, hwmod is not an acronym. Please use lower case. > >> Originally from: >> http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=52ae4f0de03b17c064d9ce90a580230f1a596ec1 >> >> [nm@ti.com: upstream version] >> Signed-off-by: Nishanth Menon<nm@ti.com> >> Signed-off-by: Moiz Sonasath<m-sonasath@ti.com> >> --- >> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 27 ++++++++++++++++++++++++--- >> 1 files changed, 24 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c >> index 2f51a5a..27319c4 100644 >> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c >> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c >> @@ -1745,7 +1745,7 @@ static struct omap_hwmod_opt_clk gpio1_opt_clks[] = { >> { .role = "dbclk", .clk = "gpio1_dbclk" }, >> }; >> >> -static struct omap_hwmod omap44xx_gpio1_hwmod = { >> +static struct omap_hwmod omap443x_gpio1_hwmod = { >> .name = "gpio1", >> .class =&omap44xx_gpio_hwmod_class, >> .mpu_irqs = omap44xx_gpio1_irqs, >> @@ -1761,7 +1761,27 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = { >> .dev_attr =&gpio_dev_attr, >> .slaves = omap44xx_gpio1_slaves, >> .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), >> - .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX), >> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), >> +}; >> + >> +static struct omap_hwmod omap446x_gpio1_hwmod = { >> + .name = "gpio1", >> + .class =&omap44xx_gpio_hwmod_class, >> + .flags = HWMOD_INIT_NO_RESET, >> + .mpu_irqs = omap44xx_gpio1_irqs, >> + .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs), >> + .main_clk = "gpio1_ick", >> + .prcm = { >> + .omap4 = { >> + .clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL, >> + }, >> + }, >> + .opt_clks = gpio1_opt_clks, >> + .opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks), >> + .dev_attr =&gpio_dev_attr, >> + .slaves = omap44xx_gpio1_slaves, >> + .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), >> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460), >> }; > > This is a board-specific problem that you've "fixed" in a way that > affects every 4460-based device. > > Rather than setting the flag in the hwmod data, you need to fix this > in a board-specific way. > > The hwmod layer provides an API for this: omap_hwmod_no_setup_reset() > which should be called by board-specific code. > > Kevin > >> /* gpio2 */ >> @@ -5079,7 +5099,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = { >> &omap44xx_dss_venc_hwmod, >> >> /* gpio class */ >> - &omap44xx_gpio1_hwmod, >> + &omap443x_gpio1_hwmod, >> + &omap446x_gpio1_hwmod, >> &omap44xx_gpio2_hwmod, >> &omap44xx_gpio3_hwmod, >> &omap44xx_gpio4_hwmod, > -- > 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 -- 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
On 5/27/2011 9:26 AM, Govindraj wrote: > > On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit <b-cousson@ti.com > <mailto:b-cousson@ti.com>> wrote: > > On 5/27/2011 1:24 AM, Hilman, Kevin wrote: > > Nishanth Menon<nm@ti.com <mailto:nm@ti.com>> writes: > > From: Moiz Sonasath<m-sonasath@ti.com > <mailto:m-sonasath@ti.com>> > > For OMAP4460, GPIO-7 of bank1 is used for controling > the TPS modes, hence GPIO1 should not be reset > during init as reset will cause the TPS voltage to > drop to 0.9 V. > > > ouch. I knew one of these days something like this was going to > happen > with GPIO resets. > > > BTW, don't we have the same kind of issue with the debug UART? I > remember that you had to do some hacks at some point to change these > hwmod flags in the UART code. > > > Yes. we use below flags. > > uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; Yeah, that's ugly... we do have to get rid of that as well using some board settings / API. Benoit -- 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
Govindraj <govindraj.ti@gmail.com> writes: > On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit <b-cousson@ti.com> wrote: > > On 5/27/2011 1:24 AM, Hilman, Kevin wrote: > > Nishanth Menon<nm@ti.com> writes: > > > From: Moiz Sonasath<m-sonasath@ti.com> > > For OMAP4460, GPIO-7 of bank1 is used for controling > the TPS modes, hence GPIO1 should not be reset > during init as reset will cause the TPS voltage to > drop to 0.9 V. > > > ouch. I knew one of these days something like this was going to happen > with GPIO resets. > > > BTW, don't we have the same kind of issue with the debug UART? I remember > that you had to do some hacks at some point to change these hwmod flags in > the UART code. > > > Yes. we use below flags. > > uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; > This is a hack (written by me) because the UART driver is not runtime PM adapted. When UART driver is runtime PM adapted, this will not be needed. Kevin -- 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
Hi Kevin, On 5/27/2011 4:59 PM, Hilman, Kevin wrote: > Govindraj<govindraj.ti@gmail.com> writes: [...] >> uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; >> > > This is a hack (written by me) because the UART driver is not runtime PM > adapted. When UART driver is runtime PM adapted, this will not be > needed. The UART can support reset and idle? There is no assumption for the UART used during the early debug phase? Don't we have to maintain its state? It will be indeed better if we don't have to. Regards, Benoit -- 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
"Cousson, Benoit" <b-cousson@ti.com> writes: > Hi Kevin, > > On 5/27/2011 4:59 PM, Hilman, Kevin wrote: >> Govindraj<govindraj.ti@gmail.com> writes: > > [...] > >>> uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; >>> >> >> This is a hack (written by me) because the UART driver is not runtime PM >> adapted. When UART driver is runtime PM adapted, this will not be >> needed. > > The UART can support reset and idle? There is no assumption for the > UART used during the early debug phase? No. As long as the UART driver is doing runtime PM properly, there are no assumptions required. Kevin > Don't we have to maintain its state? > It will be indeed better if we don't have to. > > Regards, > Benoit -- 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
"Cousson, Benoit" <b-cousson@ti.com> writes: [...] > In general we do not want to reset nor idle an IP that was potentially > already properly configured by bootloader or early Linux boot code. Actually, the opposite is true. The kernel should not make any assumptions about what the bootloader has or has not done. We need to have a kernel that can boot from any bootloader (or none, like using kexec) and be able to start from a known hardware state. Any use of HWMOD_INIT_NO_IDLE, HWMOD_INIT_NO_RESET should be a rare exception and well documented. Kevin -- 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
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 2f51a5a..27319c4 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -1745,7 +1745,7 @@ static struct omap_hwmod_opt_clk gpio1_opt_clks[] = { { .role = "dbclk", .clk = "gpio1_dbclk" }, }; -static struct omap_hwmod omap44xx_gpio1_hwmod = { +static struct omap_hwmod omap443x_gpio1_hwmod = { .name = "gpio1", .class = &omap44xx_gpio_hwmod_class, .mpu_irqs = omap44xx_gpio1_irqs, @@ -1761,7 +1761,27 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = { .dev_attr = &gpio_dev_attr, .slaves = omap44xx_gpio1_slaves, .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), - .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX), + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430), +}; + +static struct omap_hwmod omap446x_gpio1_hwmod = { + .name = "gpio1", + .class = &omap44xx_gpio_hwmod_class, + .flags = HWMOD_INIT_NO_RESET, + .mpu_irqs = omap44xx_gpio1_irqs, + .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs), + .main_clk = "gpio1_ick", + .prcm = { + .omap4 = { + .clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL, + }, + }, + .opt_clks = gpio1_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks), + .dev_attr = &gpio_dev_attr, + .slaves = omap44xx_gpio1_slaves, + .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves), + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460), }; /* gpio2 */ @@ -5079,7 +5099,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = { &omap44xx_dss_venc_hwmod, /* gpio class */ - &omap44xx_gpio1_hwmod, + &omap443x_gpio1_hwmod, + &omap446x_gpio1_hwmod, &omap44xx_gpio2_hwmod, &omap44xx_gpio3_hwmod, &omap44xx_gpio4_hwmod,