reset handling in am335x hwmod data

PATCH Peter Korsgaard 6 participants 19 messages Dec 21, 2012 – Jul 2, 2013

Subsystems (5)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP hwmod data +1 more subsystems

lore

Share & tools

lore

Peter Korsgaard

author

2012-12-21 15:39 UTC #0 lore raw

Hi,

On a custom am335x board I was surprised to see the kernel resetting gpio pins not mentioned anywhere in the dts.

In this specific case the pin is connected to nCONFIG of a FPGA. The FPGA is commanded to start configuration from a SPI flash in the bootloader, so it can happen in parallel with kernel load/uncompress/startup, but as the kernel resets the gpio during initialization this doesn't work.

Digging a bit into it, I see the hwmod of the gpio controller is configured to reset at startup, and it works correctly (E.G. the pin is left asserted) if I change it to HWMOD_INIT_NO_RESET:

arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1 -1

@@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
        .name           = "gpio2",
        .class          = &am33xx_gpio_hwmod_class,
        .clkdm_name     = "l4ls_clkdm",
-       .flags          = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+       .flags          = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
        .mpu_irqs       = am33xx_gpio1_irqs,
        .main_clk       = "l4ls_gclk",
        .prcm           = {

Now the question is why is this configured like this? I don't have any experience with omap hwmod, but on other (non-TI) boards I haven't experienced similar issues. Should E.G. the gpio controllers be changed to not reset or should it be configurable in the dts?

Signature · 1 line

Bye, Peter Korsgaard

Paul Walmsley

maintainer

2012-12-23 20:58 UTC #1 lore raw

Hi Peter,

Quoted 2 lines · Peter Korsgaard

On a custom am335x board I was surprised to see the kernel resetting gpio pins not mentioned anywhere in the dts.

The original plan with DT was to start by focusing on devices on the board, rather than devices on the SoC. The GPIO is an SoC device, so it's currently managed by the hwmod data. (This will probably change with future kernel releases.)

Quoted 22 lines

In this specific case the pin is connected to nCONFIG of a FPGA. The FPGA is commanded to start configuration from a SPI flash in the bootloader, so it can happen in parallel with kernel load/uncompress/startup, but as the kernel resets the gpio during initialization this doesn't work.
Digging a bit into it, I see the hwmod of the gpio controller is configured to reset at startup, and it works correctly (E.G. the pin is left asserted) if I change it to HWMOD_INIT_NO_RESET:
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1 -1
@@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
        .name           = "gpio2",
        .class          = &am33xx_gpio_hwmod_class,
        .clkdm_name     = "l4ls_clkdm",
-       .flags          = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+       .flags          = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
        .mpu_irqs       = am33xx_gpio1_irqs,
        .main_clk       = "l4ls_gclk",
        .prcm           = {

Quoted 1 line

Now the question is why is this configured like this?

This behavior is intended to decouple the kernel from the bootloader, or previously-booted operating system (e.g., the kexec case). The original goal was to place the system in an known safe state as soon as possible after the kernel starts. This is to prevent misconfigured or previously-configured devices from trashing memory or chip power management in the currently-booted kernel. It also avoids adding inadvertent bootloader dependencies in driver code.

N.B., the plan is to change this behavior over the next few releases. Devices that have drivers associated with them will be reset when the driver loads. Driverless devices will be reset after drivers load, late in boot.

Quoted 2 lines

Should E.G. the gpio controllers be changed to not reset or should it be configurable in the dts?

Probably the DTS is the right place, since this is a board- and bootloader-specific quirk. The original intention was to allow board files to set this HWMOD_INIT_NO_RESET flag themselves - see mach-omap2/ omap_hwmod.c:omap_hwmod_no_setup_reset(). But since we've deprecated the board files, the DT data seems like the right place.

It probably shouldn't be a GPIO-specific property. Other devices like DSS will also need some kind of 'no-init-reset' property, since on many commercial devices, it's expected that some kind of splash screen will be presented by the bootloader and stay on during the boot process.

However, it is probably safest in the long run if you can change the board design to require the SoC to actively reset the FPGA, rather than making reset the default state. That way, if there's some hardware bug that requires the GPIO block to be reset, or if there's some GPIO glitch during power management, the FPGA won't be inadvertently reset.

regards,

- Paul

Peter Korsgaard

author

2013-01-10 07:50 UTC #2 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Paul" == Paul Walmsley <[email protected]> writes:

Hi Paul,

Thanks for the detailed explanaition, and sorry for the slow response - I've been away on holidays.

Quoted 1 line

Quoted 1 line
Now the question is why is this configured like this?

Paul> This behavior is intended to decouple the kernel from the Paul> bootloader, or previously-booted operating system (e.g., the Paul> kexec case). The original goal was to place the system in an Paul> known safe state as soon as possible after the kernel starts. Paul> This is to prevent misconfigured or previously-configured devices Paul> from trashing memory or chip power management in the Paul> currently-booted kernel. It also avoids adding inadvertent Paul> bootloader dependencies in driver code.

Paul> N.B., the plan is to change this behavior over the next few Paul> releases. Devices that have drivers associated with them will be Paul> reset when the driver loads. Driverless devices will be reset Paul> after drivers load, late in boot.

Quoted 2 lines

Quoted 2 lines
Should E.G. the gpio controllers be changed to not reset or should it be configurable in the dts?

Paul> Probably the DTS is the right place, since this is a board- and Paul> bootloader-specific quirk. The original intention was to allow Paul> board files to set this HWMOD_INIT_NO_RESET flag themselves - see Paul> mach-omap2/ omap_hwmod.c:omap_hwmod_no_setup_reset(). But since Paul> we've deprecated the board files, the DT data seems like the Paul> right place.

Paul> It probably shouldn't be a GPIO-specific property. Other devices Paul> like DSS will also need some kind of 'no-init-reset' property, Paul> since on many commercial devices, it's expected that some kind of Paul> splash screen will be presented by the bootloader and stay on Paul> during the boot process.

I tried changing omap_device_build_from_dt() to call omap_hwmod_no_setup_reset() on the corresponding hwmod if a ti,no-init-reset was present, but that doesn't work as the hwmod reset happens quite a bit earlier (in omap_hwmod_setup_all()). Do you have idea how I could work around this or is that the future reset change you referred to above?

Paul> However, it is probably safest in the long run if you can change Paul> the board design to require the SoC to actively reset the FPGA, Paul> rather than making reset the default state. That way, if there's Paul> some hardware bug that requires the GPIO block to be reset, or if Paul> there's some GPIO glitch during power management, the FPGA won't Paul> be inadvertently reset.

Yes, I'll try to get that done for the next board spin.

Thanks!

Signature · 1 line

Bye, Peter Korsgaard

Peter Korsgaard

author

2013-01-18 14:23 UTC #3 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Peter" == Peter Korsgaard <[email protected]> writes:

Hi,

Peter> I tried changing omap_device_build_from_dt() to call Peter> omap_hwmod_no_setup_reset() on the corresponding hwmod if a Peter> ti,no-init-reset was present, but that doesn't work as the hwmod Peter> reset happens quite a bit earlier (in
Peter> omap_hwmod_setup_all()). Do you have idea how I could work Peter> around this or is that the future reset change you referred to Peter> above?

Paul, any ideas?

Signature · 1 line

Bye, Peter Korsgaard

Paul Walmsley

maintainer

2013-01-22 02:53 UTC #4 lore raw

In reply to Peter Korsgaard

Quoted 15 lines · Peter Korsgaard

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Paul" == Paul Walmsley <[email protected]> writes:
Paul> Probably the DTS is the right place, since this is a board- and Paul> bootloader-specific quirk. The original intention was to allow Paul> board files to set this HWMOD_INIT_NO_RESET flag themselves - see Paul> mach-omap2/ omap_hwmod.c:omap_hwmod_no_setup_reset(). But since Paul> we've deprecated the board files, the DT data seems like the Paul> right place.
Paul> It probably shouldn't be a GPIO-specific property. Other devices Paul> like DSS will also need some kind of 'no-init-reset' property, Paul> since on many commercial devices, it's expected that some kind of Paul> splash screen will be presented by the bootloader and stay on Paul> during the boot process.

Quoted 6 lines

I tried changing omap_device_build_from_dt() to call omap_hwmod_no_setup_reset() on the corresponding hwmod if a ti,no-init-reset was present, but that doesn't work as the hwmod reset happens quite a bit earlier (in omap_hwmod_setup_all()). Do you have idea how I could work around this or is that the future reset change you referred to above?

For AM33xx, since there's no board file, you'll need to modify the kernel source. You can set the HWMOD_INIT_NO_RESET flag on the GPIO IP blocks that should have their reset skipped, in mach-omap2/omap_hwmod_33xx_data.c.

In the medium term, we'll deal with this with the late reset change that was described earlier. Here's an experimental patch in case you want to play with it, which I wouldn't recommend since it has known flaws, and also we're not yet at the point where we can switch to late reset in mainline yet, mostly because folks have been more interested in pushing new features than doing cleanup work.

- Paul

Quoted 1 line

From 109751e4621f692466f6156e10c3647317f51c9c Mon Sep 17 00:00:00 2001

From: Paul Walmsley <[email protected]>
Date: Sun, 20 Jan 2013 21:35:00 -0700
Subject: [PATCH] EXPERIMENTAL: ARM: OMAP2+: hwmod: move device reset later in
the boot

EXPERIMENTAL: is full of bugs; also requires hwmod device topology patch.

XXX Fix documentation around omap_hwmod_init_*()
XXX can init be moved to device enable as well?

---
 arch/arm/mach-omap2/io.c         |   25 +-
 arch/arm/mach-omap2/omap_hwmod.c |  626 +++++++++++++++++---------------------
 arch/arm/mach-omap2/omap_hwmod.h |   24 +-
 arch/arm/mach-omap2/timer.c      |    4 +-
 4 files changed, 299 insertions(+), 380 deletions(-)

arch/arm/mach-omap2/io.c +11 ~~-14~~

index 2c3fdd6..a170c98 100644
@@ -359,23 +359,20 @@ static int __init _omap2_init_reprogram_sdrc(void)
 	return v;
 }
 
-static int _set_hwmod_postsetup_state(struct omap_hwmod *oh, void *data)
-{
-	return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
-}
-
 static void __init omap_hwmod_init_postsetup(void)
 {
-	u8 postsetup_state;
-
-	/* Set the default postsetup state for all hwmods */
-#ifdef CONFIG_PM_RUNTIME
-	postsetup_state = _HWMOD_STATE_IDLE;
-#else
-	postsetup_state = _HWMOD_STATE_ENABLED;
+#ifndef CONFIG_PM_RUNTIME
+	/*
+	 * Until we have a real OMAP bus, and the drivers can enable
+	 * and disable the devices themselves, we're stuck with
+	 * runtime PM as a device enable/disable mechanism.  But if
+	 * runtime PM has been configured out, then we're left with no
+	 * way to control the device integration, so just enable
+	 * everything so the kernel doesn't crash when it tries to
+	 * touch a device that hasn't been enabled.
+	 */
+	omap_hwmod_enable_all();
 #endif
-	omap_hwmod_for_each(_set_hwmod_postsetup_state, &postsetup_state);
-
 	omap_pm_if_early_init();
 }

arch/arm/mach-omap2/omap_hwmod.c +276 ~~-350~~

746 lines not on this page · raw message

arch/arm/mach-omap2/omap_hwmod.h +10 ~~-14~~

index 3ae852a..7346f7e 100644
@@ -470,29 +470,26 @@ struct omap_hwmod_omap4_prcm {
  * _HWMOD_NO_MPU_PORT: no path exists for the MPU to write to this module
  * _HWMOD_WAKEUP_ENABLED: set when the omap_hwmod code has enabled ENAWAKEUP
  * _HWMOD_SYSCONFIG_LOADED: set when the OCP_SYSCONFIG value has been cached
- * _HWMOD_SKIP_ENABLE: set if hwmod enabled during init (HWMOD_INIT_NO_IDLE) -
- *     causes the first call to _enable() to only update the pinmux
+ * XXX
  */
 #define _HWMOD_NO_MPU_PORT			(1 << 0)
 #define _HWMOD_WAKEUP_ENABLED			(1 << 1)
 #define _HWMOD_SYSCONFIG_LOADED			(1 << 2)
-#define _HWMOD_SKIP_ENABLE			(1 << 3)
+#define _HWMOD_FIRST_ENABLE_SETUP		(1 << 3)
 
 /*
  * omap_hwmod._state definitions
  *
- * INITIALIZED: reset (optionally), initialized, enabled, disabled
- *              (optionally)
- *
- *
+ * XXX documentation needed
  */
 #define _HWMOD_STATE_UNKNOWN			0
 #define _HWMOD_STATE_REGISTERED			1
 #define _HWMOD_STATE_CLKS_INITED		2
 #define _HWMOD_STATE_INITIALIZED		3
-#define _HWMOD_STATE_ENABLED			4
-#define _HWMOD_STATE_IDLE			5
-#define _HWMOD_STATE_DISABLED			6
+#define _HWMOD_STATE_SETUP			4
+#define _HWMOD_STATE_ENABLED			5
+#define _HWMOD_STATE_IDLE			6
+#define _HWMOD_STATE_DISABLED			7
 
 /**
  * struct omap_hwmod_class - the type of an IP block

@@ -558,7 +555,6 @@ struct omap_hwmod_link {
  * @response_lat: device OCP response latency (in interface clock cycles)
  * @_int_flags: internal-use hwmod flags
  * @_state: internal-use hwmod state
- * @_postsetup_state: internal-use state to leave the hwmod in after _setup()
  * @flags: hwmod flags (documented below)
  * @_lock: spinlock serializing operations on this hwmod
  * @node: list node for hwmod list (internal use)

@@ -607,19 +603,20 @@ struct omap_hwmod {
 	u8				hwmods_cnt;
 	u8				_int_flags;
 	u8				_state;
-	u8				_postsetup_state;
 };
 
 struct omap_hwmod *omap_hwmod_lookup(const char *name);
 int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
 			void *data);
 
-int __init omap_hwmod_setup_one(const char *name);
+int __init omap_hwmod_init_one(const char *name);
 
 int omap_hwmod_enable(struct omap_hwmod *oh);
 int omap_hwmod_idle(struct omap_hwmod *oh);
 int omap_hwmod_shutdown(struct omap_hwmod *oh);
 
+int omap_hwmod_enable_all(void);
+
 int omap_hwmod_assert_hardreset(struct omap_hwmod *oh, const char *name);
 int omap_hwmod_deassert_hardreset(struct omap_hwmod *oh, const char *name);
 int omap_hwmod_read_hardreset(struct omap_hwmod *oh, const char *name);

@@ -659,7 +656,6 @@ int omap_hwmod_for_each_by_class(const char *classname,
 					   void *user),
 				 void *user);
 
-int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state);
 int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
 
 int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);

arch/arm/mach-omap2/timer.c +2 -2

index 691aa67..17a1b42 100644
@@ -299,7 +299,7 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
 		}
 	}
 
-	omap_hwmod_setup_one(oh_name);
+	omap_hwmod_init_one(oh_name);
 	omap_hwmod_enable(oh);
 	__omap_dm_timer_init_regs(timer);

@@ -421,7 +421,7 @@ static int __init __maybe_unused omap2_sync32k_clocksource_init(void)
 	if (!oh || oh->slaves_cnt == 0)
 		return -ENODEV;
 
-	omap_hwmod_setup_one(oh_name);
+	omap_hwmod_init_one(oh_name);
 
 	if (np) {
 		vbase = of_iomap(np, 0);

Signature · 1 line

1.7.10.4

Felipe Balbi

2013-05-17 13:50 UTC #5 lore raw

In reply to Paul Walmsley

Hi,

Quoted 22 lines · Paul Walmsley

Quoted 22 lines
In this specific case the pin is connected to nCONFIG of a FPGA. The FPGA is commanded to start configuration from a SPI flash in the bootloader, so it can happen in parallel with kernel load/uncompress/startup, but as the kernel resets the gpio during initialization this doesn't work.
Digging a bit into it, I see the hwmod of the gpio controller is configured to reset at startup, and it works correctly (E.G. the pin is left asserted) if I change it to HWMOD_INIT_NO_RESET:
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1 -1
@@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
        .name           = "gpio2",
        .class          = &am33xx_gpio_hwmod_class,
        .clkdm_name     = "l4ls_clkdm",
-       .flags          = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+       .flags          = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
        .mpu_irqs       = am33xx_gpio1_irqs,
        .main_clk       = "l4ls_gclk",
        .prcm           = {

Quoted 6 lines

Quoted 1 line
Now the question is why is this configured like this?
This behavior is intended to decouple the kernel from the bootloader, or previously-booted operating system (e.g., the kexec case). The original goal was to place the system in an known safe state as soon as possible after the kernel starts. This is to prevent misconfigured or

there is one "issue" with this. At least on AM335x starter kit, GPIO0_7 is used as DDR power pin. If we reset that GPIO bank, DDR looses power and "for obscure reasons" (:-)) the board doesn't boot.

In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-)

cheers

Signature · 1 line

balbi

Peter Korsgaard

author

2013-05-17 13:53 UTC #6 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Felipe" == Felipe Balbi <[email protected]> writes:

Hi,

Quoted 11 lines

+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c

arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1 -1

@@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
        .name           = "gpio2",
        .class          = &am33xx_gpio_hwmod_class,
        .clkdm_name     = "l4ls_clkdm",
-       .flags          = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+       .flags          = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
        .mpu_irqs       = am33xx_gpio1_irqs,
        .main_clk       = "l4ls_gclk",
        .prcm           = {

Quoted 6 lines

Quoted 6 lines
Quoted 1 line
Now the question is why is this configured like this?
This behavior is intended to decouple the kernel from the bootloader, or previously-booted operating system (e.g., the kexec case). The original goal was to place the system in an known safe state as soon as possible after the kernel starts. This is to prevent misconfigured or

Felipe> there is one "issue" with this. At least on AM335x starter kit, Felipe> GPIO0_7 is used as DDR power pin. If we reset that GPIO bank, Felipe> DDR looses power and "for obscure reasons" (:-)) the board Felipe> doesn't boot.

Heh!

Felipe> In this case, we cannot reset that bank, otherwise Starter Kit Felipe> will never boot in mainline. Bad PCB design, I know, but it's Felipe> not something we can change now :-)

Indeed. So that's two examples of people designing boards with the assumption that gpios will not toggle between bootloader and running system. Chances are that there will be others.

Signature · 1 line

Bye, Peter Korsgaard

Kevin Hilman

2013-05-17 17:08 UTC #7 lore raw

In reply to Felipe Balbi

Quoted 32 lines · Felipe Balbi

Hi,
Quoted 22 lines · Paul Walmsley
Quoted 22 lines
In this specific case the pin is connected to nCONFIG of a FPGA. The FPGA is commanded to start configuration from a SPI flash in the bootloader, so it can happen in parallel with kernel load/uncompress/startup, but as the kernel resets the gpio during initialization this doesn't work.
Digging a bit into it, I see the hwmod of the gpio controller is configured to reset at startup, and it works correctly (E.G. the pin is left asserted) if I change it to HWMOD_INIT_NO_RESET:
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1 -1
@@ -992,7 +992,7 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
        .name           = "gpio2",
        .class          = &am33xx_gpio_hwmod_class,
        .clkdm_name     = "l4ls_clkdm",
-       .flags          = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+       .flags          = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
        .mpu_irqs       = am33xx_gpio1_irqs,
        .main_clk       = "l4ls_gclk",
        .prcm           = {
Quoted 6 lines
Quoted 1 line
Now the question is why is this configured like this?
This behavior is intended to decouple the kernel from the bootloader, or previously-booted operating system (e.g., the kexec case). The original goal was to place the system in an known safe state as soon as possible after the kernel starts. This is to prevent misconfigured or

Quoted 7 lines

there is one "issue" with this. At least on AM335x starter kit, GPIO0_7 is used as DDR power pin. If we reset that GPIO bank, DDR looses power and "for obscure reasons" (:-)) the board doesn't boot.
In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-)

FWIW, we've seen this before (GPIO connected to PMIC reset is a fun one), and this is why we have omap_hwmod_no_setup_reset().

Kevin

Peter Korsgaard

author

2013-05-17 18:11 UTC #8 lore raw

Quoted 5 lines

Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-)

Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin> fun one), and this is why we have omap_hwmod_no_setup_reset().

Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed.

Signature · 1 line

Bye, Peter Korsgaard

Nishanth Menon

2013-05-17 18:19 UTC #9 lore raw

Quoted 11 lines · Peter Korsgaard

Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin> fun one), and this is why we have omap_hwmod_no_setup_reset().
Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed.

I have the same issue with TPS62361 on Palmas -> GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where device does not function.

Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm.

This is the right way to do it IMHO. Will allow the driver to exist when HWMOD will be eventually replaced by some other framework.

[1]: http://pastebin.com/XPmAB1Zb

Signature · 2 lines

Regards,
Nishanth Menon

Hiremath, Vaibhav

2013-05-20 06:39 UTC #10 lore raw

Quoted 35 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Menon, Nishanth
Sent: Friday, May 17, 2013 11:49 PM
To: Peter Korsgaard
Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
Quoted 3 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise Starter Kit
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but it's not
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset is
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 3 lines
Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas -> GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where
device does not function.
Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm.

Quoted 8 lines

This is the right way to do it IMHO. Will allow the driver to exist when
HWMOD will be eventually replaced by some other framework.
[1]: http://pastebin.com/XPmAB1Zb

Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.

Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer).

But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.

Thanks,
Vaibhav

Hiremath, Vaibhav

2013-05-20 06:55 UTC #11 lore raw

Quoted 63 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Hiremath, Vaibhav
Sent: Monday, May 20, 2013 12:09 PM
To: Menon, Nishanth; Peter Korsgaard
Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: RE: reset handling in am335x hwmod data
Quoted 9 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Menon, Nishanth
Sent: Friday, May 17, 2013 11:49 PM
To: Peter Korsgaard
Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
Quoted 10 lines
Quoted 3 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise Starter Kit
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but it's not
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset
is
Quoted 5 lines
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 2 lines
Yes, but there's no dts bindings for this, and from a quick test
the
Quoted 10 lines
Quoted 1 line
reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas -> GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where
device does not function.
Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm.
Quoted 8 lines
This is the right way to do it IMHO. Will allow the driver to exist when
HWMOD will be eventually replaced by some other framework.
[1]: http://pastebin.com/XPmAB1Zb
Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.
Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer).

Quoted 8 lines

But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.

Forgot to mention,

Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.

Thanks,
Vaibhav

Nishanth Menon

2013-05-20 15:06 UTC #12 lore raw

Quoted 52 lines · Vaibhav

Quoted 52 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Hiremath, Vaibhav
Sent: Monday, May 20, 2013 12:09 PM
To: Menon, Nishanth; Peter Korsgaard
Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: RE: reset handling in am335x hwmod data
Quoted 9 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Menon, Nishanth
Sent: Friday, May 17, 2013 11:49 PM
To: Peter Korsgaard
Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
Quoted 10 lines
Quoted 3 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise Starter Kit
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but it's not
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to PMIC reset
is
Quoted 5 lines
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 2 lines
Yes, but there's no dts bindings for this, and from a quick test
the
Quoted 15 lines
Quoted 1 line
reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas -> GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where
device does not function.
Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm.
This is the right way to do it IMHO. Will allow the driver to exist when
HWMOD will be eventually replaced by some other framework.

Quoted 6 lines

Quoted 6 lines
Quoted 3 lines
[1]: http://pastebin.com/XPmAB1Zb
Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.

Yes - that is what the above does - as long as the GPIO is requested and set to the right level by the relevant driver, it is not "unused" and hence not reset at late_init.

I am a little unclear as to why this needs to have anything to do with the precise under-lying mechanism (hwmod or something else). May be "both seem to be different to me" needs a little further elaboration?

Is this because there is no need for an EMIF driver to handle DDR? and reset of the GPIO will occur as EMIF is configured at bootloader and there is no need to do that in kernel, correspondingly there is no "driver" to hold the gpio?

Quoted 8 lines

Quoted 8 lines
Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer).
But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse

I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset?

Quoted 11 lines

Quoted 5 lines
It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.
Forgot to mention,
Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.

a) if the GPIO gets moved over to some other GPIO bank on another platform, this wont work
b) for platforms that dont use gpio to hold DDR power, maybe this is not even relevant and the GPIO bank can safely be reset?

Quoted 3 lines

Thanks,
Vaibhav

Signature · 2 lines

Regards,
Nishanth Menon

Hiremath, Vaibhav

2013-05-20 17:47 UTC #13 lore raw

Quoted 74 lines

-----Original Message-----
From: Menon, Nishanth
Sent: Monday, May 20, 2013 8:36 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
Quoted 20 lines · Vaibhav
Quoted 20 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Hiremath, Vaibhav
Sent: Monday, May 20, 2013 12:09 PM
To: Menon, Nishanth; Peter Korsgaard
Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: RE: reset handling in am335x hwmod data
Quoted 9 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Menon, Nishanth
Sent: Friday, May 17, 2013 11:49 PM
To: Peter Korsgaard
Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise Starter
Kit
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but it's
not
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to PMIC
reset
Quoted 6 lines
Quoted 6 lines
is
Quoted 5 lines
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 2 lines
Yes, but there's no dts bindings for this, and from a quick
test
Quoted 3 lines
Quoted 3 lines
the
Quoted 2 lines
Quoted 1 line
reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas -> GPIO controls
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
voltage register supplying MPU, without any driver setting things
up,
Quoted 1 line
Quoted 1 line
Quoted 1 line
GPIO gets reset and obviously voltage value switches to an
voltage
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
where
device does not function.
Solution I am working on to solve this is [1]: snippet is part of
a
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
patch that I am working on atm.
This is the right way to do it IMHO. Will allow the driver to
exist
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
when
HWMOD will be eventually replaced by some other framework.
[1]: http://pastebin.com/XPmAB1Zb

Quoted 7 lines

Quoted 2 lines
Quoted 2 lines
Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is requested and
set to the right level by the relevant driver, it is not "unused" and hence not reset at late_init.

May be I am missing something here,

Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall.

Quoted 4 lines

I am a little unclear as to why this needs to have anything to do with the precise under-lying mechanism (hwmod or something else). May be "both seem to be different to me" needs a little further elaboration?

GPIO is connected to the DDR VTT control pin, and we have observed that Due to GPIO bank reset as part of hwmod init during bootup.

Quoted 7 lines

Is this because there is no need for an EMIF driver to handle DDR? and reset of the GPIO will occur as EMIF is configured at bootloader and there is no need to do that in kernel, correspondingly there is no "driver" to hold the gpio?
Quoted 3 lines
Quoted 3 lines
Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on

Quoted 8 lines

hwmod
Quoted 5 lines
Quoted 5 lines
init layer).
But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse
I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset?

That’s the idea.

Quoted 6 lines

Quoted 6 lines
Quoted 5 lines
It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.

Quoted 8 lines

Quoted 5 lines
Forgot to mention,
Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.
a) if the GPIO gets moved over to some other GPIO bank on another platform,
this wont work

Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0 bank.

Quoted 4 lines

b) for platforms that dont use gpio to hold DDR power, maybe this is not
even relevant and the GPIO bank can safely be reset?
Quoted 1 line

As I mentioned, there is no known side-effect of not resetting GPIO bank 0.

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Nishanth Menon

2013-05-20 18:04 UTC #14 lore raw

On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]

Quoted 54 lines

Quoted 46 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise Starter
Kit
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but it's
not
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to PMIC
reset
Quoted 6 lines
Quoted 6 lines
is
Quoted 5 lines
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 2 lines
Yes, but there's no dts bindings for this, and from a quick
test
Quoted 3 lines
Quoted 3 lines
the
Quoted 2 lines
Quoted 1 line
reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas -> GPIO controls
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
voltage register supplying MPU, without any driver setting things
up,
Quoted 1 line
Quoted 1 line
Quoted 1 line
GPIO gets reset and obviously voltage value switches to an
voltage
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
where
device does not function.
Solution I am working on to solve this is [1]: snippet is part of
a
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
patch that I am working on atm.
This is the right way to do it IMHO. Will allow the driver to
exist
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
when
HWMOD will be eventually replaced by some other framework.
[1]: http://pastebin.com/XPmAB1Zb
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is requested and
set to the right level by the relevant driver, it is not "unused" and hence not reset at late_init.

Quoted 3 lines

May be I am missing something here,
Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall.

Hmm.. You are right, I missed that :(

Quoted 38 lines

Quoted 5 lines
I am a little unclear as to why this needs to have anything to do with the precise under-lying mechanism (hwmod or something else). May be "both seem to be different to me" needs a little further elaboration?
GPIO is connected to the DDR VTT control pin, and we have observed that Due to GPIO bank reset as part of hwmod init during bootup.
Quoted 7 lines
Is this because there is no need for an EMIF driver to handle DDR? and reset of the GPIO will occur as EMIF is configured at bootloader and there is no need to do that in kernel, correspondingly there is no "driver" to hold the gpio?
Quoted 3 lines
Quoted 3 lines
Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on
Quoted 8 lines
hwmod
Quoted 5 lines
Quoted 5 lines
init layer).
But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse
I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset?
That’s the idea.
Quoted 11 lines
Quoted 11 lines
Quoted 5 lines
It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.
Forgot to mention,
Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.

Quoted 6 lines

Quoted 3 lines
a) if the GPIO gets moved over to some other GPIO bank on another platform,
this wont work
Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0 bank.

unless you mark the GPIO as taken, another driver could in-adverantly take over the GPIO and set it to a wrong level (we had a similar story with LED gpio between Panda Vs Panda-ES).

Quoted 7 lines

Quoted 5 lines
b) for platforms that dont use gpio to hold DDR power, maybe this is not
even relevant and the GPIO bank can safely be reset?
Quoted 1 line
As I mentioned, there is no known side-effect of not resetting GPIO bank 0.

It should depend on the platform.

There are other uses for hwmod-no-reset -> Eg. boot logo displayed by bootloader - if there is a reset of DSS block and re-configuration, we'd notice a blank-out, which is not desirable either. There could be a few other usage based on no-reset.

In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they attempt ther'd at least be some form of warning.

Signature · 6 lines

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hiremath, Vaibhav

2013-05-20 18:20 UTC #15 lore raw

Quoted 150 lines

-----Original Message-----
From: Menon, Nishanth
Sent: Monday, May 20, 2013 11:34 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise
Starter
Quoted 3 lines
Quoted 3 lines
Kit
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but
it's
Quoted 5 lines
Quoted 5 lines
not
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to
PMIC
Quoted 11 lines
Quoted 11 lines
reset
Quoted 6 lines
Quoted 6 lines
is
Quoted 5 lines
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 2 lines
Yes, but there's no dts bindings for this, and from a quick
test
Quoted 3 lines
Quoted 3 lines
the
Quoted 2 lines
Quoted 1 line
reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas -> GPIO
controls
Quoted 2 lines
Quoted 2 lines
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
voltage register supplying MPU, without any driver setting
things
Quoted 7 lines
Quoted 7 lines
up,
Quoted 1 line
Quoted 1 line
Quoted 1 line
GPIO gets reset and obviously voltage value switches to an
voltage
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
where
device does not function.
Solution I am working on to solve this is [1]: snippet is
part of
Quoted 9 lines
Quoted 9 lines
a
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
patch that I am working on atm.
This is the right way to do it IMHO. Will allow the driver to
exist
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
when
HWMOD will be eventually replaced by some other framework.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
[1]: http://pastebin.com/XPmAB1Zb
Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is
requested
Quoted 2 lines
Quoted 2 lines
and
set to the right level by the relevant driver, it is not "unused"
and
Quoted 6 lines
Quoted 2 lines
hence not reset at late_init.
May be I am missing something here,
Isn't _setup_reset() function asserts ocp_reset? And it is
core_initcall.
Hmm.. You are right, I missed that :(
Quoted 2 lines
Quoted 2 lines
I am a little unclear as to why this needs to have anything to do
with
Quoted 2 lines
Quoted 2 lines
the precise under-lying mechanism (hwmod or something else). May be "both seem to be different to me" needs a little further
elaboration?
Quoted 3 lines
Quoted 1 line
GPIO is connected to the DDR VTT control pin, and we have observed
that
Quoted 3 lines
Due to GPIO bank reset as part of hwmod init during bootup.
Quoted 1 line
Is this because there is no need for an EMIF driver to handle DDR?
and
Quoted 1 line
Quoted 1 line
reset of the GPIO will occur as EMIF is configured at bootloader
and
Quoted 4 lines
Quoted 4 lines
there is no need to do that in kernel, correspondingly there is no "driver" to hold the gpio?
Quoted 2 lines
Quoted 2 lines
Ideally, it would have been much better if drivers starts
handling
Quoted 23 lines
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Idle, ocp reset and standby on their own (killing dependency on
hwmod
Quoted 5 lines
Quoted 5 lines
init layer).
But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse
I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset?
That’s the idea.
Quoted 11 lines
Quoted 11 lines
Quoted 5 lines
It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.
Forgot to mention,
Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.
Quoted 6 lines
Quoted 3 lines
a) if the GPIO gets moved over to some other GPIO bank on another platform,
this wont work
Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0
bank.
unless you mark the GPIO as taken, another driver could in-adverantly take over the GPIO and set it to a wrong level (we had a similar story with LED gpio between Panda Vs Panda-ES).
Quoted 2 lines
Quoted 2 lines
b) for platforms that dont use gpio to hold DDR power, maybe this
is
Quoted 5 lines
Quoted 3 lines
not
even relevant and the GPIO bank can safely be reset?
Quoted 1 line
As I mentioned, there is no known side-effect of not resetting GPIO
bank 0.
It should depend on the platform.
There are other uses for hwmod-no-reset -> Eg. boot logo displayed by bootloader - if there is a reset of DSS block and re-configuration, we'd
notice a blank-out, which is not desirable either. There could be a few other usage based on no-reset.

Quoted 5 lines

In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they attempt ther'd at least be some form of warning.

Completely agree with you on both the points, and my point and all my comments Were more related to option 'a' above.

Thanks,
Vaibhav

Felipe Balbi

2013-06-28 10:54 UTC #16 lore raw

Hi,

Quoted 150 lines · Vaibhav

Quoted 150 lines
-----Original Message-----
From: Menon, Nishanth
Sent: Monday, May 20, 2013 11:34 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- [email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines · Peter Korsgaard
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]> writes:
In this case, we cannot reset that bank, otherwise
Starter
Quoted 3 lines
Quoted 3 lines
Kit
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but
it's
Quoted 5 lines
Quoted 5 lines
not
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to
PMIC
Quoted 11 lines
Quoted 11 lines
reset
Quoted 6 lines
Quoted 6 lines
is
Quoted 5 lines
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 2 lines
Yes, but there's no dts bindings for this, and from a quick
test
Quoted 3 lines
Quoted 3 lines
the
Quoted 2 lines
Quoted 1 line
reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas -> GPIO
controls
Quoted 2 lines
Quoted 2 lines
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
voltage register supplying MPU, without any driver setting
things
Quoted 7 lines
Quoted 7 lines
up,
Quoted 1 line
Quoted 1 line
Quoted 1 line
GPIO gets reset and obviously voltage value switches to an
voltage
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
where
device does not function.
Solution I am working on to solve this is [1]: snippet is
part of
Quoted 9 lines
Quoted 9 lines
a
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
patch that I am working on atm.
This is the right way to do it IMHO. Will allow the driver to
exist
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
when
HWMOD will be eventually replaced by some other framework.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
[1]: http://pastebin.com/XPmAB1Zb
Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is
requested
Quoted 2 lines
Quoted 2 lines
and
set to the right level by the relevant driver, it is not "unused"
and
Quoted 6 lines
Quoted 2 lines
hence not reset at late_init.
May be I am missing something here,
Isn't _setup_reset() function asserts ocp_reset? And it is
core_initcall.
Hmm.. You are right, I missed that :(
Quoted 2 lines
Quoted 2 lines
I am a little unclear as to why this needs to have anything to do
with
Quoted 2 lines
Quoted 2 lines
the precise under-lying mechanism (hwmod or something else). May be "both seem to be different to me" needs a little further
elaboration?
Quoted 3 lines
Quoted 1 line
GPIO is connected to the DDR VTT control pin, and we have observed
that
Quoted 3 lines
Due to GPIO bank reset as part of hwmod init during bootup.
Quoted 1 line
Is this because there is no need for an EMIF driver to handle DDR?
and
Quoted 1 line
Quoted 1 line
reset of the GPIO will occur as EMIF is configured at bootloader
and
Quoted 4 lines
Quoted 4 lines
there is no need to do that in kernel, correspondingly there is no "driver" to hold the gpio?
Quoted 2 lines
Quoted 2 lines
Ideally, it would have been much better if drivers starts
handling
Quoted 23 lines
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Idle, ocp reset and standby on their own (killing dependency on
hwmod
Quoted 5 lines
Quoted 5 lines
init layer).
But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse
I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset?
That’s the idea.
Quoted 11 lines
Quoted 11 lines
Quoted 5 lines
It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.
Forgot to mention,
Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.
Quoted 6 lines
Quoted 3 lines
a) if the GPIO gets moved over to some other GPIO bank on another platform,
this wont work
Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0
bank.
unless you mark the GPIO as taken, another driver could in-adverantly take over the GPIO and set it to a wrong level (we had a similar story with LED gpio between Panda Vs Panda-ES).
Quoted 2 lines
Quoted 2 lines
b) for platforms that dont use gpio to hold DDR power, maybe this
is
Quoted 5 lines
Quoted 3 lines
not
even relevant and the GPIO bank can safely be reset?
Quoted 1 line
As I mentioned, there is no known side-effect of not resetting GPIO
bank 0.
It should depend on the platform.
There are other uses for hwmod-no-reset -> Eg. boot logo displayed by bootloader - if there is a reset of DSS block and re-configuration, we'd
notice a blank-out, which is not desirable either. There could be a few other usage based on no-reset.

Quoted 7 lines

Quoted 5 lines
In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they attempt ther'd at least be some form of warning.
Completely agree with you on both the points, and my point and all my comments Were more related to option 'a' above.

so, what happened here ? Will we not have AM335x-SK working in mainline just because of the GPIO block being reset ?

Signature · 1 line

balbi

Hiremath, Vaibhav

2013-07-02 04:38 UTC #17 lore raw

Quoted 193 lines

-----Original Message-----
From: Balbi, Felipe
Sent: Friday, June 28, 2013 4:24 PM
To: Hiremath, Vaibhav
Cc: Menon, Nishanth; Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; [email protected]; Tony Lindgren; Sebastian Andrzej Siewior
Subject: Re: reset handling in am335x hwmod data
Hi,
Quoted 6 lines · Vaibhav
Quoted 6 lines
-----Original Message-----
From: Menon, Nishanth
Sent: Monday, May 20, 2013 11:34 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley;
linux-
Quoted 8 lines
Quoted 8 lines
[email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]>
Quoted 12 lines · writes:
Quoted 12 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
In this case, we cannot reset that bank, otherwise
Starter
Quoted 3 lines
Quoted 3 lines
Kit
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but
it's
Quoted 5 lines
Quoted 5 lines
not
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to
Quoted 8 lines
Quoted 8 lines
PMIC
Quoted 7 lines
Quoted 7 lines
reset
Quoted 6 lines
Quoted 6 lines
is
Quoted 5 lines
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 2 lines
Yes, but there's no dts bindings for this, and from a
quick
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
test
Quoted 2 lines
Quoted 2 lines
the
Quoted 1 line
Quoted 1 line
reset handling happens before the device tree is
probed.
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
I have the same issue with TPS62361 on Palmas -> GPIO
controls
Quoted 2 lines
Quoted 2 lines
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
voltage register supplying MPU, without any driver
setting
Quoted 3 lines
Quoted 3 lines
things
Quoted 2 lines
Quoted 2 lines
up,
Quoted 1 line
Quoted 1 line
Quoted 1 line
GPIO gets reset and obviously voltage value switches to
an
Quoted 10 lines
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines
voltage
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
where
device does not function.
Solution I am working on to solve this is [1]: snippet is
part of
Quoted 4 lines
Quoted 4 lines
a
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
patch that I am working on atm.
This is the right way to do it IMHO. Will allow the
driver to
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
exist
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
when
HWMOD will be eventually replaced by some other
framework.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
[1]: http://pastebin.com/XPmAB1Zb
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is
requested
Quoted 2 lines
Quoted 2 lines
and
set to the right level by the relevant driver, it is not
"unused"
Quoted 11 lines
Quoted 11 lines
and
Quoted 6 lines
Quoted 2 lines
hence not reset at late_init.
May be I am missing something here,
Isn't _setup_reset() function asserts ocp_reset? And it is
core_initcall.
Hmm.. You are right, I missed that :(
Quoted 2 lines
Quoted 2 lines
I am a little unclear as to why this needs to have anything to
do
Quoted 2 lines
Quoted 2 lines
with
Quoted 1 line
Quoted 1 line
the precise under-lying mechanism (hwmod or something else).
May be
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
"both seem to be different to me" needs a little further
elaboration?
Quoted 3 lines
Quoted 1 line
GPIO is connected to the DDR VTT control pin, and we have
observed
Quoted 4 lines
Quoted 4 lines
that
Quoted 3 lines
Due to GPIO bank reset as part of hwmod init during bootup.
Quoted 1 line
Is this because there is no need for an EMIF driver to handle
DDR?
Quoted 2 lines
Quoted 2 lines
and
Quoted 1 line
Quoted 1 line
reset of the GPIO will occur as EMIF is configured at
bootloader
Quoted 2 lines
Quoted 2 lines
and
Quoted 1 line
Quoted 1 line
there is no need to do that in kernel, correspondingly there is
no
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
"driver" to hold the gpio?
Quoted 2 lines
Quoted 2 lines
Ideally, it would have been much better if drivers starts
handling
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Idle, ocp reset and standby on their own (killing
dependency on
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
hwmod
Quoted 5 lines
Quoted 5 lines
init layer).
But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to
parse
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset?
That’s the idea.
Quoted 1 line
Quoted 1 line
Quoted 1 line
It early during hwmod init stage. We should read all DT
nodes
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 4 lines
Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.
Forgot to mention,
Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.
a) if the GPIO gets moved over to some other GPIO bank on
another
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
platform,
this wont work
Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0
bank.
unless you mark the GPIO as taken, another driver could in-
adverantly
Quoted 1 line
Quoted 1 line
take over the GPIO and set it to a wrong level (we had a similar
story
Quoted 4 lines
Quoted 4 lines
with LED gpio between Panda Vs Panda-ES).
Quoted 2 lines
Quoted 2 lines
b) for platforms that dont use gpio to hold DDR power, maybe
this
Quoted 6 lines
Quoted 6 lines
is
Quoted 5 lines
Quoted 3 lines
not
even relevant and the GPIO bank can safely be reset?
Quoted 1 line
As I mentioned, there is no known side-effect of not resetting
GPIO
Quoted 4 lines
Quoted 4 lines
bank 0.
It should depend on the platform.
There are other uses for hwmod-no-reset -> Eg. boot logo displayed
by
Quoted 3 lines
Quoted 3 lines
bootloader - if there is a reset of DSS block and re-configuration, we'd
notice a blank-out, which is not desirable either. There could be a
few
Quoted 7 lines
Quoted 7 lines
other usage based on no-reset.
In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they attempt ther'd at least be some form of warning.

Quoted 7 lines

Quoted 1 line
Completely agree with you on both the points, and my point and all my
comments
Quoted 1 line
Were more related to option 'a' above.
so, what happened here ? Will we not have AM335x-SK working in mainline just because of the GPIO block being reset ?

Nishant started implementing on this, not sure what state it is in.

Thanks,
Vaibhav

Nishanth Menon

2013-07-02 13:57 UTC #18 lore raw

Quoted 194 lines · Vaibhav

Quoted 194 lines
-----Original Message-----
From: Balbi, Felipe
Sent: Friday, June 28, 2013 4:24 PM
To: Hiremath, Vaibhav
Cc: Menon, Nishanth; Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; [email protected]; Tony Lindgren; Sebastian Andrzej Siewior
Subject: Re: reset handling in am335x hwmod data
Hi,
Quoted 6 lines · Vaibhav
Quoted 6 lines
-----Original Message-----
From: Menon, Nishanth
Sent: Monday, May 20, 2013 11:34 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley;
linux-
Quoted 8 lines
Quoted 8 lines
[email protected]; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Kevin" == Kevin Hilman <[email protected]>
Quoted 12 lines · writes:
Quoted 12 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
In this case, we cannot reset that bank, otherwise
Starter
Quoted 3 lines
Quoted 3 lines
Kit
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
will
Quoted 1 line
Quoted 1 line
Quoted 1 line
never boot in mainline. Bad PCB design, I know, but
it's
Quoted 5 lines
Quoted 5 lines
not
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
something
Quoted 3 lines
Quoted 1 line
Quoted 1 line
we can change now :-)
Kevin> FWIW, we've seen this before (GPIO connected to
Quoted 8 lines
Quoted 8 lines
PMIC
Quoted 7 lines
Quoted 7 lines
reset
Quoted 6 lines
Quoted 6 lines
is
Quoted 5 lines
a
Quoted 1 line
Kevin> fun one), and this is why we have
omap_hwmod_no_setup_reset().
Quoted 2 lines
Yes, but there's no dts bindings for this, and from a
quick
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
test
Quoted 2 lines
Quoted 2 lines
the
Quoted 1 line
Quoted 1 line
reset handling happens before the device tree is
probed.
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
I have the same issue with TPS62361 on Palmas -> GPIO
controls
Quoted 2 lines
Quoted 2 lines
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
voltage register supplying MPU, without any driver
setting
Quoted 3 lines
Quoted 3 lines
things
Quoted 2 lines
Quoted 2 lines
up,
Quoted 1 line
Quoted 1 line
Quoted 1 line
GPIO gets reset and obviously voltage value switches to
an
Quoted 10 lines
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines
voltage
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
where
device does not function.
Solution I am working on to solve this is [1]: snippet is
part of
Quoted 4 lines
Quoted 4 lines
a
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
patch that I am working on atm.
This is the right way to do it IMHO. Will allow the
driver to
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
exist
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
when
HWMOD will be eventually replaced by some other
framework.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
[1]: http://pastebin.com/XPmAB1Zb
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is
requested
Quoted 2 lines
Quoted 2 lines
and
set to the right level by the relevant driver, it is not
"unused"
Quoted 11 lines
Quoted 11 lines
and
Quoted 6 lines
Quoted 2 lines
hence not reset at late_init.
May be I am missing something here,
Isn't _setup_reset() function asserts ocp_reset? And it is
core_initcall.
Hmm.. You are right, I missed that :(
Quoted 2 lines
Quoted 2 lines
I am a little unclear as to why this needs to have anything to
do
Quoted 2 lines
Quoted 2 lines
with
Quoted 1 line
Quoted 1 line
the precise under-lying mechanism (hwmod or something else).
May be
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
"both seem to be different to me" needs a little further
elaboration?
Quoted 3 lines
Quoted 1 line
GPIO is connected to the DDR VTT control pin, and we have
observed
Quoted 4 lines
Quoted 4 lines
that
Quoted 3 lines
Due to GPIO bank reset as part of hwmod init during bootup.
Quoted 1 line
Is this because there is no need for an EMIF driver to handle
DDR?
Quoted 2 lines
Quoted 2 lines
and
Quoted 1 line
Quoted 1 line
reset of the GPIO will occur as EMIF is configured at
bootloader
Quoted 2 lines
Quoted 2 lines
and
Quoted 1 line
Quoted 1 line
there is no need to do that in kernel, correspondingly there is
no
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
"driver" to hold the gpio?
Quoted 2 lines
Quoted 2 lines
Ideally, it would have been much better if drivers starts
handling
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Idle, ocp reset and standby on their own (killing
dependency on
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
hwmod
Quoted 5 lines
Quoted 5 lines
init layer).
But looking at current state,
I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to
parse
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset?
That’s the idea.
Quoted 1 line
Quoted 1 line
Quoted 1 line
It early during hwmod init stage. We should read all DT
nodes
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 4 lines
Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset.
Forgot to mention,
Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set "HWMOD_INIT_NO_RESET" flag For GPIO0 bank.
a) if the GPIO gets moved over to some other GPIO bank on
another
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
platform,
this wont work
Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0
bank.
unless you mark the GPIO as taken, another driver could in-
adverantly
Quoted 1 line
Quoted 1 line
take over the GPIO and set it to a wrong level (we had a similar
story
Quoted 4 lines
Quoted 4 lines
with LED gpio between Panda Vs Panda-ES).
Quoted 2 lines
Quoted 2 lines
b) for platforms that dont use gpio to hold DDR power, maybe
this
Quoted 6 lines
Quoted 6 lines
is
Quoted 5 lines
Quoted 3 lines
not
even relevant and the GPIO bank can safely be reset?
Quoted 1 line
As I mentioned, there is no known side-effect of not resetting
GPIO
Quoted 4 lines
Quoted 4 lines
bank 0.
It should depend on the platform.
There are other uses for hwmod-no-reset -> Eg. boot logo displayed
by
Quoted 3 lines
Quoted 3 lines
bootloader - if there is a reset of DSS block and re-configuration, we'd
notice a blank-out, which is not desirable either. There could be a
few
Quoted 8 lines
Quoted 7 lines
other usage based on no-reset.
In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they attempt ther'd at least be some form of warning.
Completely agree with you on both the points, and my point and all my

Quoted 8 lines

Quoted 6 lines
comments
Quoted 1 line
Were more related to option 'a' above.
so, what happened here ? Will we not have AM335x-SK working in mainline just because of the GPIO block being reset ?
Nishant started implementing on this, not sure what state it is in.

Nope. I am not working on this.

Signature · 6 lines

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html