Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/27/2011 1:24 AM, Hilman, Kevin wrote:
Nishanth Menon<nm@xxxxxx>  writes:

From: Moiz Sonasath<m-sonasath@xxxxxx>

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@xxxxxx: upstream version]
Signed-off-by: Nishanth Menon<nm@xxxxxx>
Signed-off-by: Moiz Sonasath<m-sonasath@xxxxxx>
---
  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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux