Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On 5/29/2011 11:04 PM, Steve Calfee wrote: On Fri, May 27, 2011 at 12:38 PM, Kevin Hilmankhil...@ti.com wrote: Cousson, Benoitb-cous...@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. YES. Bootloaders should only do what is necessary (set clocks, enable memories etc) to load the next stage. Pushing stuff that should be in the kernel into the bootloader (like iniiting gpios and other things) bloats it and makes a developer deal with two entirely different source trees (kernel and booterx) to enable a new feature or to fix bugs. Uboot tends to lag the kernel in capabilities too, probably because fewer developers or something. For instance Beagleboard xm uboot cannot access the ethernet because it is usb based, and uboot cannot access its own environment in flash - because it is running from a new microsd based flash system. U-boot will eventually catch up with these, but by then other new hardware will be available. Does anyone know if 2.6.39 has kexec working again for the kernel? NFS boot is a dream development environment but with both u-boot and kexec not working with nfs, it is slightly more work and less automated. I apologize for the confusing message in my answer. The default behavior of the hwmod fmwk is to reset every IPs in order to ensure a stable and known state. The HWMOD flags should only be used in case of broken reset in an IP. That's why hacking the GPIO flag in that case is wrong. That being said, you cannot prevent a board manufacturer to do some hacks in its bootloader, because it is require for proper voltage like here or because he wants to enable a splash screen and do not want to have ugly artifact on the screen due to asynchronous reset of the DSS. In that case, it might be desirable to allow the board file to prevent such blind reset at boot time. Hence the need for a board level mechanism to change that default behavior. Bootloader sucks, but you cannot prevent people to use them:-( In an ideal world, the bootloader will not do anything, and everything will be perfectly handled by the kernel... Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Op 29 mei 2011, om 23:04 heeft Steve Calfee het volgende geschreven: For instance Beagleboard xm uboot cannot access the ethernet because it is usb based, and uboot cannot access its own environment in flash - because it is running from a new microsd based flash system. U-boot has supported reading from SD cards for some years now. You can even write to them from inside uboot if you wish.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On Fri, May 27, 2011 at 12:38 PM, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@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. YES. Bootloaders should only do what is necessary (set clocks, enable memories etc) to load the next stage. Pushing stuff that should be in the kernel into the bootloader (like iniiting gpios and other things) bloats it and makes a developer deal with two entirely different source trees (kernel and booterx) to enable a new feature or to fix bugs. Uboot tends to lag the kernel in capabilities too, probably because fewer developers or something. For instance Beagleboard xm uboot cannot access the ethernet because it is usb based, and uboot cannot access its own environment in flash - because it is running from a new microsd based flash system. U-boot will eventually catch up with these, but by then other new hardware will be available. Does anyone know if 2.6.39 has kexec working again for the kernel? NFS boot is a dream development environment but with both u-boot and kexec not working with nfs, it is slightly more work and less automated. Regards, Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On Fri, May 27, 2011 at 14:38, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@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. Looking deeper to find the rootcause, I see this: a) TI provides a reference schematics design that is usually copied on to most of the platforms - e.g. blaze and panda etc.. this may not be the norm, but tends to be same except for intrepid board designers who like to go into unexplored areas. b) in this case, I tracked the issue down. Here is what is happening (given NDA restrictions as the datasheet of the PMIC is not pubic yet, I am being vague here. Apologies on the same :(): This PMIC has one voltage output which drives MPU - just like the 1vsel per rail as we had in TWL series, here we have an option of storing n values in n vsel registers and selecting one of them. the selection is based on x pins that may be driven by the MPU. In this particular case, one of the pins is connected to OMAP GPIO1 block allowing PMIC to set the voltage from one of two options inside the PMIC - This could have been used like we'd have done in OMAP2 days with VMODE pin. However, in our TI's x-loader case it sets it to 1, and since hwmod reset happens here, it gets set to 0, selecting a much lower voltage than what is needed for functioning causing system to hangup. Now, with this reference design, many things are possible - folks following TI x-loader might pull the pin high, could pull the pin low or even go and ground the pin and free up the GPIO itself. now we have two cases: a) folks who follow TI's recommendations verbatim b) intrepid folks who like doing their own things. What should the default kernel look like here? I think I agree - it should be board files that is usually tied to a particular bootloader (exception being devel boards like Beagle, Panda, Blaze etc where people do develop bootloaders as well..). I agree with kevin here - this should be done by board file. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On 5/27/2011 1:24 AM, Hilman, Kevin wrote:
Nishanth Menonn...@ti.com writes:
From: Moiz Sonasathm-sonas...@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
[n...@ti.com: upstream version]
Signed-off-by: Nishanth Menonn...@ti.com
Signed-off-by: Moiz Sonasathm-sonas...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On 5/27/2011 9:26 AM, Govindraj wrote: On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit b-cous...@ti.com mailto:b-cous...@ti.com wrote: On 5/27/2011 1:24 AM, Hilman, Kevin wrote: Nishanth Menonn...@ti.com mailto:n...@ti.com writes: From: Moiz Sonasathm-sonas...@ti.com mailto:m-sonas...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Govindraj govindraj...@gmail.com writes: On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit b-cous...@ti.com wrote: On 5/27/2011 1:24 AM, Hilman, Kevin wrote: Nishanth Menonn...@ti.com writes: From: Moiz Sonasathm-sonas...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Hi Kevin, On 5/27/2011 4:59 PM, Hilman, Kevin wrote: Govindrajgovindraj...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Cousson, Benoit b-cous...@ti.com writes: Hi Kevin, On 5/27/2011 4:59 PM, Hilman, Kevin wrote: Govindrajgovindraj...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Cousson, Benoit b-cous...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@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-sonas...@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
[n...@ti.com: upstream version]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On 14:06-20110526, Premi, Sanjeev wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@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. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Nishanth Menon n...@ti.com writes:
From: Moiz Sonasath m-sonas...@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
[n...@ti.com: upstream version]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On Thu, May 26, 2011 at 16:24, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
From: Moiz Sonasath m-sonas...@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
[n...@ti.com: upstream version]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
From: Moiz Sonasath m-sonas...@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=52ae4f0de03b17c064d9ce90a580230f1a596ec1
[n...@ti.com: upstream version]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
