All of lore.kernel.org
 help / color / mirror / Atom feed
* Issues with GPIO and wake from sleep
@ 2014-01-17 12:24 Marc Murphy
  2014-01-17 17:39 ` Tony Lindgren
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Murphy @ 2014-01-17 12:24 UTC (permalink / raw)
  To: linux-omap

I have resisted contacting the list with regards to an issue I am having trying to get what should be a simple part of my system working but I cannot find any documentation or other posts to help.
 
I am using 3.6 kernel but have tried 3.12 to see if the issue has been addressed in that but its exactly the same.
 
I am attempting to get a GPIO to wake my AM3517 system up from a suspend to memory.  I have tried with a few different options for GPIO’s
I have available GPIO-10, GPIO-28 and GPIO-30.
 
I started by using GPIO-28 and that would configure nicely and I set up the interrupt handler and could see my debug when triggering the input (brilliant) but for some reason I cannot use it  to wake the system as it is not in the correct group for wakeup.  There is a note in the Tech Ref Man -

Only gpio_1, gpio_9, gpio_10, gpio_11, gpio_30, and gpio_31 can be used to generate a direct wake-up event.

So have to use a different one. GPIO-30 cannot be used as that holds the system in reset, so all that is left is GPIO-10.
All seems to be good for initialisation;
 
In the omap_board_mux I define
 
    OMAP3_MUX(SYS_CLKOUT1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
              OMAP_PIN_OFF_INPUT_PULLUP | OMAP_PIN_OFF_OUTPUT_LOW |
              OMAP_PIN_OFF_WAKEUPENABLE),
 
Then the init function and interrupt handler;
 
/****************************************************************************
*
* Board wakeup interrupt
*
****************************************************************************/
#define IGNITION_GPIO 10
 
static irqreturn_t detect_irq(int irq, void *_data)
{
    printk("%s: irq\n", __func__);
 
    return IRQ_HANDLED;
}
 
static void enable_board_wakeup_source(void)
{
    int irq;
    int ret;
    /* GPIO_10 interrupt line */
 
    gpio_request(IGNITION_GPIO, "gpio_10");
    gpio_direction_input(IGNITION_GPIO);
    omap_mux_init_gpio(IGNITION_GPIO, OMAP_PIN_INPUT_PULLUP |
                       OMAP_PIN_OFF_WAKEUPENABLE);
 
       irq = gpio_to_irq(IGNITION_GPIO);
    if (request_irq(irq, detect_irq, IRQF_TRIGGER_RISING, "ignition",
                    NULL)) {
            pr_err("********* %s: request_irq() failed\n", __func__);
            return;
    }
 
    if (enable_irq_wake(irq)) {
            pr_err("********* %s: irq_set_irq_wake() failed\n", __func__);
            return;
    }
 
    pr_err("************** %s: set irq %u\n", __func__, irq);
}
 
But when I try and trigger the input there is no IRQ handled and I also cannot export the gpio in sys/class/
 
If I have a look at the mux it seems to be OK
# cd /debug/omap_mux/
# cat sys_clkout1
name: sys_clkout1.gpio_10 (0x48002a1a/0x9ea = 0x411c), b ag25, t NA
mode: OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4
signals: sys_clkout1 | NA | NA | NA | gpio_10 | NA | NA | safe_mode
 
There is definitely a problem as when I look at the state it says its high, when the input is definitely 0V
# cat /debug/gpio
GPIOs 0-31, gpio:
gpio-0   (mpu6050-irq         ) in  lo
gpio-10  (gpio_10             ) in  hi
gpio-25  (USB1 PHY reset      ) out hi
 
I think there is something else taking over the pin, maybe the clock setup for sys_clkout1.
 
Is there any way to make it just work for my config or make GPIO-28 work to wake the system ?
 
Hope you have seen this before.
 
Kind Regards
Marc--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Issues with GPIO and wake from sleep
  2014-01-17 12:24 Issues with GPIO and wake from sleep Marc Murphy
@ 2014-01-17 17:39 ` Tony Lindgren
  2014-01-23  9:45   ` Marc Murphy
  0 siblings, 1 reply; 6+ messages in thread
From: Tony Lindgren @ 2014-01-17 17:39 UTC (permalink / raw)
  To: Marc Murphy; +Cc: linux-omap

* Marc Murphy <marcmltd@marcm.co.uk> [140117 04:32]:
> I have resisted contacting the list with regards to an issue I am having trying to get what should be a simple part of my system working but I cannot find any documentation or other posts to help.
>  
> I am using 3.6 kernel but have tried 3.12 to see if the issue has been addressed in that but its exactly the same.
>  
> I am attempting to get a GPIO to wake my AM3517 system up from a suspend to memory.  I have tried with a few different options for GPIO’s
> I have available GPIO-10, GPIO-28 and GPIO-30.
>  
> I started by using GPIO-28 and that would configure nicely and I set up the interrupt handler and could see my debug when triggering the input (brilliant) but for some reason I cannot use it  to wake the system as it is not in the correct group for wakeup.  There is a note in the Tech Ref Man -
> 
> Only gpio_1, gpio_9, gpio_10, gpio_11, gpio_30, and gpio_31 can be used to generate a direct wake-up event.
> 
> So have to use a different one. GPIO-30 cannot be used as that holds the system in reset, so all that is left is GPIO-10.
> All seems to be good for initialisation;

I think you don't need the mux wake-up bits for the first GPIO bank, it's
always powered. So just setting gpio10 as an interrupt should keep it
working through suspend. The GPIO driver has it's own idle handling for
the first bank, see _set_gpio_wakeup().

Maybe you just need to do set_irq_wake() in the interrupt number
for gpio10?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Issues with GPIO and wake from sleep
  2014-01-17 17:39 ` Tony Lindgren
@ 2014-01-23  9:45   ` Marc Murphy
  2014-02-04 22:47     ` Marc Murphy
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Murphy @ 2014-01-23  9:45 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap

I have tried all sorts of configurations now and still cannot get the system to wake from GPIO.

The confusing thing is that if I use the power managements tests via debugfs I can make the system sleep and wakeup using the timer, so the suspend and wake is configured and working.

Using either method of configuring the GPIO to be an interrupt and wakeup source OR a GPIO key with wakeup capability results in the system just sitting there in the suspended state.
I know the GPIO and IRQ is working as I see the count increment in 
/proc/interrupts

I have tried debugging with JTAG but not having any luck because the core enters a power down state so therefore disconnects the JTAG and the debug session hangs.

I have also removed all devices going back to a very basic system thinking drivers are causing the suspend resume issue but still it stays in the sleep state.

All the references I can find online do not assist in getting a solution for me.

Is there anyone out there that has managed to successfully get the wake from suspend to memory working via a GPIO on a 3.x kernel ?

i am getting close to running out of options to make this system work.

Help appreciated and may help others out there with a similar issue.

Kind Regards
Marc

________________________________________
From: Tony Lindgren [tony@atomide.com]
Sent: 17 January 2014 17:39
To: Marc Murphy
Cc: linux-omap@vger.kernel.org
Subject: Re: Issues with GPIO and wake from sleep

* Marc Murphy <marcmltd@marcm.co.uk> [140117 04:32]:
> I have resisted contacting the list with regards to an issue I am having trying to get what should be a simple part of my system working but I cannot find any documentation or other posts to help.
>
> I am using 3.6 kernel but have tried 3.12 to see if the issue has been addressed in that but its exactly the same.
>
> I am attempting to get a GPIO to wake my AM3517 system up from a suspend to memory.  I have tried with a few different options for GPIO’s
> I have available GPIO-10, GPIO-28 and GPIO-30.
>
> I started by using GPIO-28 and that would configure nicely and I set up the interrupt handler and could see my debug when triggering the input (brilliant) but for some reason I cannot use it  to wake the system as it is not in the correct group for wakeup.  There is a note in the Tech Ref Man -
>
> Only gpio_1, gpio_9, gpio_10, gpio_11, gpio_30, and gpio_31 can be used to generate a direct wake-up event.
>
> So have to use a different one. GPIO-30 cannot be used as that holds the system in reset, so all that is left is GPIO-10.
> All seems to be good for initialisation;

I think you don't need the mux wake-up bits for the first GPIO bank, it's
always powered. So just setting gpio10 as an interrupt should keep it
working through suspend. The GPIO driver has it's own idle handling for
the first bank, see _set_gpio_wakeup().

Maybe you just need to do set_irq_wake() in the interrupt number
for gpio10?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Issues with GPIO and wake from sleep
  2014-01-23  9:45   ` Marc Murphy
@ 2014-02-04 22:47     ` Marc Murphy
  2014-02-05 23:17       ` Marc Murphy
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Murphy @ 2014-02-04 22:47 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap

I have been looking more into the issue I am having and it looks like the system isnt even entering a fully suspended state;

Tracing through the suspend sequence it looks like it is having trouble with
void omap_sram_idle(void)

The return from pwrm_read_next is 3 (PWRDM_POWER_ON) surely the next power state should be 0 (PWRDM_POWER_OFF)
	mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);

	
All the remaining checks are then invalid as it thinks the power domain needs to be on for all;
	/* NEON control */
	if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
		pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);

	/* Enable IO-PAD and IO-CHAIN wakeups */
	per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
	core_next_state = pwrdm_read_next_pwrst(core_pwrdm);

	pwrdm_pre_transition(NULL);

	/* PER */
	if (per_next_state < PWRDM_POWER_ON) {
		per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
		omap2_gpio_prepare_for_idle(per_going_off);
	}

	/* CORE */
	if (core_next_state < PWRDM_POWER_ON) {
		if (core_next_state == PWRDM_POWER_OFF) {
			omap3_core_save_context();
			omap3_cm_save_context();
		}
	}

	omap3_intc_prepare_idle();

Is there anywhere I can find out what omap3_pm_suspend()  is supposed to be doing when it traverses through the list of power domains ? 
static int omap3_pm_suspend(void)
{
	struct power_state *pwrst;
	int state, ret = 0;

	/* Read current next_pwrsts */
	list_for_each_entry(pwrst, &pwrst_list, node)
		pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
	/* Set ones wanted by suspend */
	list_for_each_entry(pwrst, &pwrst_list, node) {
		if (omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state))
			goto restore;
		if (pwrdm_clear_all_prev_pwrst(pwrst->pwrdm))
			goto restore;
	}

	omap3_intc_suspend();

	omap_sram_idle();

I think the problem lies in the system thinking it is going from an ON state to an ON state maybe ??

Kind Regards
Marc



-----Original Message-----
From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Marc Murphy
Sent: 23 January 2014 09:45
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org
Subject: RE: Issues with GPIO and wake from sleep

I have tried all sorts of configurations now and still cannot get the system to wake from GPIO.

The confusing thing is that if I use the power managements tests via debugfs I can make the system sleep and wakeup using the timer, so the suspend and wake is configured and working.

Using either method of configuring the GPIO to be an interrupt and wakeup source OR a GPIO key with wakeup capability results in the system just sitting there in the suspended state.
I know the GPIO and IRQ is working as I see the count increment in /proc/interrupts

I have tried debugging with JTAG but not having any luck because the core enters a power down state so therefore disconnects the JTAG and the debug session hangs.

I have also removed all devices going back to a very basic system thinking drivers are causing the suspend resume issue but still it stays in the sleep state.

All the references I can find online do not assist in getting a solution for me.

Is there anyone out there that has managed to successfully get the wake from suspend to memory working via a GPIO on a 3.x kernel ?

i am getting close to running out of options to make this system work.

Help appreciated and may help others out there with a similar issue.

Kind Regards
Marc

________________________________________
From: Tony Lindgren [tony@atomide.com]
Sent: 17 January 2014 17:39
To: Marc Murphy
Cc: linux-omap@vger.kernel.org
Subject: Re: Issues with GPIO and wake from sleep

* Marc Murphy <marcmltd@marcm.co.uk> [140117 04:32]:
> I have resisted contacting the list with regards to an issue I am having trying to get what should be a simple part of my system working but I cannot find any documentation or other posts to help.
>
> I am using 3.6 kernel but have tried 3.12 to see if the issue has been addressed in that but its exactly the same.
>
> I am attempting to get a GPIO to wake my AM3517 system up from a 
> suspend to memory.  I have tried with a few different options for GPIO's I have available GPIO-10, GPIO-28 and GPIO-30.
>
> I started by using GPIO-28 and that would configure nicely and I set 
> up the interrupt handler and could see my debug when triggering the 
> input (brilliant) but for some reason I cannot use it  to wake the 
> system as it is not in the correct group for wakeup.  There is a note 
> in the Tech Ref Man -
>
> Only gpio_1, gpio_9, gpio_10, gpio_11, gpio_30, and gpio_31 can be used to generate a direct wake-up event.
>
> So have to use a different one. GPIO-30 cannot be used as that holds the system in reset, so all that is left is GPIO-10.
> All seems to be good for initialisation;

I think you don't need the mux wake-up bits for the first GPIO bank, it's always powered. So just setting gpio10 as an interrupt should keep it working through suspend. The GPIO driver has it's own idle handling for the first bank, see _set_gpio_wakeup().

Maybe you just need to do set_irq_wake() in the interrupt number for gpio10?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Issues with GPIO and wake from sleep
  2014-02-04 22:47     ` Marc Murphy
@ 2014-02-05 23:17       ` Marc Murphy
  2014-02-13 22:40         ` Tony Lindgren
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Murphy @ 2014-02-05 23:17 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap

I have now stepped through most of the system as it goes into the sleep state.  It will transition into omap34xx_cpu_suspend and eventually work itself into an endless loop.

I have then taken a step back to see the config of the system and all kernel options seem to be correct with power management. 

I then looked at the boot line, I am running tftp which should be a problem for the suspend to ram, and there is an option of nohlt :
setenv bootargs console=${console},115200n8 ${mem_size} mpurate=${mpurate} ${video_mode} ${extra_options} root=${nfsroot} rootfstype=nfs ip=dhcp nohlt rw

I was informed I needed to do this quite some time ago when I was having issue with the system booting.  Upon reading the kernel-paramters doc I see that the description is what I am experiencing;
	nohlt		[BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
			wfi(ARM) instruction doesn't work correctly and not to
			use it. This is also useful when using JTAG debugger.

OK so WFI doesn't work correctly, I have no WFI operating.  If I remove the nohlt from the boot line the system freezes;
[    2.833587] voltdm_scale: No voltage scale API registered for vdd_core
[    2.840454] PM: no software I/O chain control; some wakeups may be lost
[    2.856536] davinci_emac davinci_emac.0: using random MAC addr: 86:2d:4d:a4:87:3e


If I put it back in then the system boots;
[    2.826354] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
[    2.833587] voltdm_scale: No voltage scale API registered for vdd_core
[    2.840454] PM: no software I/O chain control; some wakeups may be lost
[    2.856536] davinci_emac davinci_emac.0: using random MAC addr: 86:2d:4d:a4:87:3e
[    2.867065] rtc-ds1307 2-0068: setting system clock to 2000-01-01 02:55:38 UTC (946695338)
[    2.877655] davinci_mdio davinci_mdio.0: resetting idled controller
[    2.884490] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
[    2.976226] usb 1-1: new high-speed USB device number 2 using ehci-omap
[    3.132904] usb 1-1: New USB device found, idVendor=0424, idProduct=2513
[    3.139953] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.149200] hub 1-1:1.0: USB hub found
[    3.153289] hub 1-1:1.0: 3 ports detected
[    5.882629] libphy: davinci_mdio-0:00 - Link is Up - 100/Full
[    5.913726] Sending DHCP requests ., OK
[    5.929779] IP-Config: Got DHCP answer from 0.0.0.0, my address is 10.0.0.74
[    5.937744] IP-Config: Complete:
[    5.941131]      device=eth0, addr=10.0.0.74, mask=255.255.255.0, gw=10.0.0.1

Surely this must be related as to why I cannot get the WFI to work ?

Is there any patch required to stop the halting of boot when not using the nohlt option ?

Thanks in advance

Marc


-----Original Message-----
From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Marc Murphy
Sent: 04 February 2014 22:48
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org
Subject: RE: Issues with GPIO and wake from sleep

I have been looking more into the issue I am having and it looks like the system isnt even entering a fully suspended state;

Tracing through the suspend sequence it looks like it is having trouble with void omap_sram_idle(void)

The return from pwrm_read_next is 3 (PWRDM_POWER_ON) surely the next power state should be 0 (PWRDM_POWER_OFF)
	mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);

	
All the remaining checks are then invalid as it thinks the power domain needs to be on for all;
	/* NEON control */
	if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
		pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);

	/* Enable IO-PAD and IO-CHAIN wakeups */
	per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
	core_next_state = pwrdm_read_next_pwrst(core_pwrdm);

	pwrdm_pre_transition(NULL);

	/* PER */
	if (per_next_state < PWRDM_POWER_ON) {
		per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
		omap2_gpio_prepare_for_idle(per_going_off);
	}

	/* CORE */
	if (core_next_state < PWRDM_POWER_ON) {
		if (core_next_state == PWRDM_POWER_OFF) {
			omap3_core_save_context();
			omap3_cm_save_context();
		}
	}

	omap3_intc_prepare_idle();

Is there anywhere I can find out what omap3_pm_suspend()  is supposed to be doing when it traverses through the list of power domains ? 
static int omap3_pm_suspend(void)
{
	struct power_state *pwrst;
	int state, ret = 0;

	/* Read current next_pwrsts */
	list_for_each_entry(pwrst, &pwrst_list, node)
		pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
	/* Set ones wanted by suspend */
	list_for_each_entry(pwrst, &pwrst_list, node) {
		if (omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state))
			goto restore;
		if (pwrdm_clear_all_prev_pwrst(pwrst->pwrdm))
			goto restore;
	}

	omap3_intc_suspend();

	omap_sram_idle();

I think the problem lies in the system thinking it is going from an ON state to an ON state maybe ??

Kind Regards
Marc



-----Original Message-----
From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Marc Murphy
Sent: 23 January 2014 09:45
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org
Subject: RE: Issues with GPIO and wake from sleep

I have tried all sorts of configurations now and still cannot get the system to wake from GPIO.

The confusing thing is that if I use the power managements tests via debugfs I can make the system sleep and wakeup using the timer, so the suspend and wake is configured and working.

Using either method of configuring the GPIO to be an interrupt and wakeup source OR a GPIO key with wakeup capability results in the system just sitting there in the suspended state.
I know the GPIO and IRQ is working as I see the count increment in /proc/interrupts

I have tried debugging with JTAG but not having any luck because the core enters a power down state so therefore disconnects the JTAG and the debug session hangs.

I have also removed all devices going back to a very basic system thinking drivers are causing the suspend resume issue but still it stays in the sleep state.

All the references I can find online do not assist in getting a solution for me.

Is there anyone out there that has managed to successfully get the wake from suspend to memory working via a GPIO on a 3.x kernel ?

i am getting close to running out of options to make this system work.

Help appreciated and may help others out there with a similar issue.

Kind Regards
Marc

________________________________________
From: Tony Lindgren [tony@atomide.com]
Sent: 17 January 2014 17:39
To: Marc Murphy
Cc: linux-omap@vger.kernel.org
Subject: Re: Issues with GPIO and wake from sleep

* Marc Murphy <marcmltd@marcm.co.uk> [140117 04:32]:
> I have resisted contacting the list with regards to an issue I am having trying to get what should be a simple part of my system working but I cannot find any documentation or other posts to help.
>
> I am using 3.6 kernel but have tried 3.12 to see if the issue has been addressed in that but its exactly the same.
>
> I am attempting to get a GPIO to wake my AM3517 system up from a 
> suspend to memory.  I have tried with a few different options for GPIO's I have available GPIO-10, GPIO-28 and GPIO-30.
>
> I started by using GPIO-28 and that would configure nicely and I set 
> up the interrupt handler and could see my debug when triggering the 
> input (brilliant) but for some reason I cannot use it  to wake the 
> system as it is not in the correct group for wakeup.  There is a note 
> in the Tech Ref Man -
>
> Only gpio_1, gpio_9, gpio_10, gpio_11, gpio_30, and gpio_31 can be used to generate a direct wake-up event.
>
> So have to use a different one. GPIO-30 cannot be used as that holds the system in reset, so all that is left is GPIO-10.
> All seems to be good for initialisation;

I think you don't need the mux wake-up bits for the first GPIO bank, it's always powered. So just setting gpio10 as an interrupt should keep it working through suspend. The GPIO driver has it's own idle handling for the first bank, see _set_gpio_wakeup().

Maybe you just need to do set_irq_wake() in the interrupt number for gpio10?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Issues with GPIO and wake from sleep
  2014-02-05 23:17       ` Marc Murphy
@ 2014-02-13 22:40         ` Tony Lindgren
  0 siblings, 0 replies; 6+ messages in thread
From: Tony Lindgren @ 2014-02-13 22:40 UTC (permalink / raw)
  To: Marc Murphy; +Cc: linux-omap

* Marc Murphy <marcmltd@marcm.co.uk> [140205 15:20]:
> I have now stepped through most of the system as it goes into the sleep state.  It will transition into omap34xx_cpu_suspend and eventually work itself into an endless loop.
> 
> I have then taken a step back to see the config of the system and all kernel options seem to be correct with power management. 
> 
> I then looked at the boot line, I am running tftp which should be a problem for the suspend to ram, and there is an option of nohlt :
> setenv bootargs console=${console},115200n8 ${mem_size} mpurate=${mpurate} ${video_mode} ${extra_options} root=${nfsroot} rootfstype=nfs ip=dhcp nohlt rw
> 
> I was informed I needed to do this quite some time ago when I was having issue with the system booting.  Upon reading the kernel-paramters doc I see that the description is what I am experiencing;
> 	nohlt		[BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
> 			wfi(ARM) instruction doesn't work correctly and not to
> 			use it. This is also useful when using JTAG debugger.
> 
> OK so WFI doesn't work correctly, I have no WFI operating.  If I remove the nohlt from the boot line the system freezes;
> [    2.833587] voltdm_scale: No voltage scale API registered for vdd_core
> [    2.840454] PM: no software I/O chain control; some wakeups may be lost
> [    2.856536] davinci_emac davinci_emac.0: using random MAC addr: 86:2d:4d:a4:87:3e

It seems that this is a 3517 based issue, maybe the davinci_emac driver
won't work properly with runtime PM?

Tony

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-02-13 22:41 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-17 12:24 Issues with GPIO and wake from sleep Marc Murphy
2014-01-17 17:39 ` Tony Lindgren
2014-01-23  9:45   ` Marc Murphy
2014-02-04 22:47     ` Marc Murphy
2014-02-05 23:17       ` Marc Murphy
2014-02-13 22:40         ` Tony Lindgren

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.