PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Joe Woodward]

I've got 3.5-rc5 with the following patches applied to get system suspend working on OMAP3:
  - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
  - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer

This has been built with the omap2plus_defconfig.

However, If I disable the RTC (i.e. CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when suspending the device never wakes up.

That is, I can't get any wakeups to happen (either through the console, or GPIO buttons) hence I'm assuming the kernel has crashed...

Any ideas?

As far as I know there is no dependency on the RTC in 3.4, and with the RTC compiled in I never see a problem on 3.5-rc5.

Cheers,
Joe

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Kevin Hilman]

"Joe Woodward" <jw@terrafix.co.uk> writes:

> I've got 3.5-rc5 with the following patches applied to get system suspend working on OMAP3:
>   - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
>   - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
>
> This has been built with the omap2plus_defconfig.
>
> However, If I disable the RTC (i.e. CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when suspending the device never wakes up.
>
> That is, I can't get any wakeups to happen (either through the console, or GPIO buttons) hence I'm assuming the kernel has crashed...
>
> Any ideas?
>
> As far as I know there is no dependency on the RTC in 3.4, and with the RTC compiled in I never see a problem on 3.5-rc5.

There is definitely a bug in the EHCI driver in v3.5 that cause a hang
in suspend, but the RTC connection is very strange.

I was not able to reproduce this.

Can you try the same with my current 'pm' branch[1].  I've got a handful
of additional fixes there for various other problems where both MMC and
EHCI are preventing sucessful suspend with the default
omap2plus_defconfig.  (note the EHCI fix is simply diabling it in the
defconfig.)

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Joe Woodward]

-----Original Message-----
From: Kevin Hilman <khilman@ti.com>
To: "Joe Woodward" <jw@terrafix.co.uk>
Cc: "linux-omap\@vger.kernel.org" <linux-omap@vger.kernel.org>
Date: Tue, 10 Jul 2012 16:58:18 -0700
Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

> "Joe Woodward" <jw@terrafix.co.uk> writes:
> 
> > I've got 3.5-rc5 with the following patches applied to get system
> suspend working on OMAP3:
> >   - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
> >   - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data:
> fix 32K sync timer
> >
> > This has been built with the omap2plus_defconfig.
> >
> > However, If I disable the RTC (i.e.
> CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when
> suspending the device never wakes up.
> >
> > That is, I can't get any wakeups to happen (either through the
> console, or GPIO buttons) hence I'm assuming the kernel has crashed...
> >
> > Any ideas?
> >
> > As far as I know there is no dependency on the RTC in 3.4, and with
> the RTC compiled in I never see a problem on 3.5-rc5.
> 
> There is definitely a bug in the EHCI driver in v3.5 that cause a hang
> in suspend, but the RTC connection is very strange.
> 
> I was not able to reproduce this.
> 
> Can you try the same with my current 'pm' branch[1].  I've got a
> handful
> of additional fixes there for various other problems where both MMC and
> EHCI are preventing sucessful suspend with the default
> omap2plus_defconfig.  (note the EHCI fix is simply diabling it in the
> defconfig.)
> 
> Kevin
> 

Hi Kevin,

Thanks for looking in to this.

I've taken a copy of the PM branch with tag "pm-20120710" and built with omap2plus_defconfig.

But I get several warnings during boot, and suspend works - but almost nothing enters the target states:

Warnings include:
[    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist

[    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
[    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
[    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
[    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48

[    2.447784] platform omap_hsmmc.0: omap_device_late_idle: enabled but no driver.  Idling
[    2.456359] platform omap_hsmmc.1: omap_device_late_idle: enabled but no driver.  Idling

# echo mem > /sys/power/state
[  107.398956] PM: Syncing filesystems ... done.
[  107.413757] Freezing user space processes ... (elapsed 0.02 seconds) done.
[  107.443481] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[  107.474700] Suspending console(s) (use no_console_suspend to debug)
[  107.493560] PM: suspend of devices complete after 9.246 msecs
[  107.496063] PM: late suspend of devices complete after 2.502 msecs
[  107.500427] PM: noirq suspend of devices complete after 4.302 msecs
[  107.500488] Disabling non-boot CPUs ...
[  108.446838] Powerdomain (iva2_pwrdm) didn't enter target state 1
[  108.446868] Powerdomain (dss_pwrdm) didn't enter target state 1
[  108.446868] Powerdomain (per_pwrdm) didn't enter target state 1
[  108.446868] Powerdomain (core_pwrdm) didn't enter target state 1
[  108.446899] Powerdomain (usbhost_pwrdm) didn't enter target state 1
[  108.446899] Could not enter target state in pm_suspend
[  108.448852] PM: noirq resume of devices complete after 1.769 msecs
[  108.451873] PM: early resume of devices complete after 1.556 msecs
[  108.459716] PM: resume of devices complete after 7.690 msecs
[  108.541748] Restarting tasks ... done.
sh: write error: Operation not permitted

This is all on an Overo AirSTORM (3703-based) plugged in to a GUMSTIX PALO43 dev board.

Cheers,
Joe

> [1]
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
> pm
> --
> 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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[T Krishnamoorthy, Balaji]

On Wed, Jul 11, 2012 at 4:20 PM, Joe Woodward <jw@terrafix.co.uk> wrote:
> -----Original Message-----
> From: Kevin Hilman <khilman@ti.com>
> To: "Joe Woodward" <jw@terrafix.co.uk>
> Cc: "linux-omap\@vger.kernel.org" <linux-omap@vger.kernel.org>
> Date: Tue, 10 Jul 2012 16:58:18 -0700
> Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
>
>> "Joe Woodward" <jw@terrafix.co.uk> writes:
>>
>> > I've got 3.5-rc5 with the following patches applied to get system
>> suspend working on OMAP3:
>> >   - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
>> >   - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data:
>> fix 32K sync timer
>> >
>> > This has been built with the omap2plus_defconfig.
>> >
>> > However, If I disable the RTC (i.e.
>> CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when
>> suspending the device never wakes up.
>> >
>> > That is, I can't get any wakeups to happen (either through the
>> console, or GPIO buttons) hence I'm assuming the kernel has crashed...
>> >
>> > Any ideas?
>> >
>> > As far as I know there is no dependency on the RTC in 3.4, and with
>> the RTC compiled in I never see a problem on 3.5-rc5.
>>
>> There is definitely a bug in the EHCI driver in v3.5 that cause a hang
>> in suspend, but the RTC connection is very strange.
>>
>> I was not able to reproduce this.
>>
>> Can you try the same with my current 'pm' branch[1].  I've got a
>> handful
>> of additional fixes there for various other problems where both MMC and
>> EHCI are preventing sucessful suspend with the default
>> omap2plus_defconfig.  (note the EHCI fix is simply diabling it in the
>> defconfig.)
>>
>> Kevin
>>
>
> Hi Kevin,
>
> Thanks for looking in to this.
>
> I've taken a copy of the PM branch with tag "pm-20120710" and built with omap2plus_defconfig.
>
> But I get several warnings during boot, and suspend works - but almost nothing enters the target states:
>
> Warnings include:
> [    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist
>
> [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
> [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
> [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
> [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>
Hi Joe,

This warning should go away with CONFIG_DMA_OMAP, CONFIG_DMA_ENGINE enabled

> [    2.447784] platform omap_hsmmc.0: omap_device_late_idle: enabled but no driver.  Idling
> [    2.456359] platform omap_hsmmc.1: omap_device_late_idle: enabled but no driver.  Idling
>
--
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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Kevin Hilman]

"Joe Woodward" <jw@terrafix.co.uk> writes:

> -----Original Message-----
> From: Kevin Hilman <khilman@ti.com>
> To: "Joe Woodward" <jw@terrafix.co.uk>
> Cc: "linux-omap\@vger.kernel.org" <linux-omap@vger.kernel.org>
> Date: Tue, 10 Jul 2012 16:58:18 -0700
> Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
>
>> "Joe Woodward" <jw@terrafix.co.uk> writes:
>> 
>> > I've got 3.5-rc5 with the following patches applied to get system
>> suspend working on OMAP3:
>> >   - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
>> >   - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data:
>> fix 32K sync timer
>> >
>> > This has been built with the omap2plus_defconfig.
>> >
>> > However, If I disable the RTC (i.e.
>> CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when
>> suspending the device never wakes up.
>> >
>> > That is, I can't get any wakeups to happen (either through the
>> console, or GPIO buttons) hence I'm assuming the kernel has crashed...
>> >
>> > Any ideas?
>> >
>> > As far as I know there is no dependency on the RTC in 3.4, and with
>> the RTC compiled in I never see a problem on 3.5-rc5.
>> 
>> There is definitely a bug in the EHCI driver in v3.5 that cause a hang
>> in suspend, but the RTC connection is very strange.
>> 
>> I was not able to reproduce this.
>> 
>> Can you try the same with my current 'pm' branch[1].  I've got a
>> handful
>> of additional fixes there for various other problems where both MMC and
>> EHCI are preventing sucessful suspend with the default
>> omap2plus_defconfig.  (note the EHCI fix is simply diabling it in the
>> defconfig.)
>> 
>> Kevin
>> 
>
> Hi Kevin,
>
> Thanks for looking in to this.

And thanks for your detailed bug reports.

> I've taken a copy of the PM branch with tag "pm-20120710" and built with omap2plus_defconfig.
>
> But I get several warnings during boot, and suspend works - but almost nothing enters the target states:
>
> Warnings include:
> [    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist

This one is suspicious.

> [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
> [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
> [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
> [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48

These are normal because DMA engine is not compiled in with
omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
that doesn't matter for trying to figure out your problem.

> [    2.447784] platform omap_hsmmc.0: omap_device_late_idle: enabled but no driver.  Idling
> [    2.456359] platform omap_hsmmc.1: omap_device_late_idle: enabled but no driver.  Idling

This is expected because of the failed MMC probe.

> # echo mem > /sys/power/state
> [  107.398956] PM: Syncing filesystems ... done.
> [  107.413757] Freezing user space processes ... (elapsed 0.02 seconds) done.
> [  107.443481] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
> [  107.474700] Suspending console(s) (use no_console_suspend to debug)
> [  107.493560] PM: suspend of devices complete after 9.246 msecs
> [  107.496063] PM: late suspend of devices complete after 2.502 msecs
> [  107.500427] PM: noirq suspend of devices complete after 4.302 msecs
> [  107.500488] Disabling non-boot CPUs ...
> [  108.446838] Powerdomain (iva2_pwrdm) didn't enter target state 1
> [  108.446868] Powerdomain (dss_pwrdm) didn't enter target state 1
> [  108.446868] Powerdomain (per_pwrdm) didn't enter target state 1
> [  108.446868] Powerdomain (core_pwrdm) didn't enter target state 1
> [  108.446899] Powerdomain (usbhost_pwrdm) didn't enter target state 1
> [  108.446899] Could not enter target state in pm_suspend
> [  108.448852] PM: noirq resume of devices complete after 1.769 msecs
> [  108.451873] PM: early resume of devices complete after 1.556 msecs
> [  108.459716] PM: resume of devices complete after 7.690 msecs
> [  108.541748] Restarting tasks ... done.
> sh: write error: Operation not permitted
>
> This is all on an Overo AirSTORM (3703-based) plugged in to a GUMSTIX PALO43 dev board.

Hmm, interesting, I don't see this on my 3730-based Over FireSTORM.

But, after "converting" mine into an AirStorm[1], I see the same errors
as you're seeing.  We're obviously doing something wrong when IVA and/or
SGX are not present, so I will look into it.

Thanks for testing,

Kevin


[1]
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 40373db..c8e5a6c 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -237,8 +237,8 @@ void __init omap3xxx_check_features(void)
 	status = omap_ctrl_readl(OMAP3_CONTROL_OMAP_STATUS);
 
 	OMAP3_CHECK_FEATURE(status, L2CACHE);
-	OMAP3_CHECK_FEATURE(status, IVA);
-	OMAP3_CHECK_FEATURE(status, SGX);
+	/* OMAP3_CHECK_FEATURE(status, IVA); */
+	/* OMAP3_CHECK_FEATURE(status, SGX); */
 	OMAP3_CHECK_FEATURE(status, NEON);
 	OMAP3_CHECK_FEATURE(status, ISP);
 	if (cpu_is_omap3630())
--
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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Mark A. Greer]

On Wed, Jul 11, 2012 at 10:07:06AM -0700, Kevin Hilman wrote:
> "Joe Woodward" <jw@terrafix.co.uk> writes:
> 
> > -----Original Message-----
> > From: Kevin Hilman <khilman@ti.com>
> > To: "Joe Woodward" <jw@terrafix.co.uk>
> > Cc: "linux-omap\@vger.kernel.org" <linux-omap@vger.kernel.org>
> > Date: Tue, 10 Jul 2012 16:58:18 -0700
> > Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
> >
> >> "Joe Woodward" <jw@terrafix.co.uk> writes:
> >> 
> >> > I've got 3.5-rc5 with the following patches applied to get system
> >> suspend working on OMAP3:
> >> >   - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
> >> >   - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data:
> >> fix 32K sync timer
> >> >
> >> > This has been built with the omap2plus_defconfig.
> >> >
> >> > However, If I disable the RTC (i.e.
> >> CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when
> >> suspending the device never wakes up.
> >> >
> >> > That is, I can't get any wakeups to happen (either through the
> >> console, or GPIO buttons) hence I'm assuming the kernel has crashed...
> >> >
> >> > Any ideas?
> >> >
> >> > As far as I know there is no dependency on the RTC in 3.4, and with
> >> the RTC compiled in I never see a problem on 3.5-rc5.
> >> 
> >> There is definitely a bug in the EHCI driver in v3.5 that cause a hang
> >> in suspend, but the RTC connection is very strange.
> >> 
> >> I was not able to reproduce this.
> >> 
> >> Can you try the same with my current 'pm' branch[1].  I've got a
> >> handful
> >> of additional fixes there for various other problems where both MMC and
> >> EHCI are preventing sucessful suspend with the default
> >> omap2plus_defconfig.  (note the EHCI fix is simply diabling it in the
> >> defconfig.)
> >> 
> >> Kevin
> >> 
> >
> > Hi Kevin,
> >
> > Thanks for looking in to this.
> 
> And thanks for your detailed bug reports.
> 
> > I've taken a copy of the PM branch with tag "pm-20120710" and built with omap2plus_defconfig.
> >
> > But I get several warnings during boot, and suspend works - but almost nothing enters the target states:
> >
> > Warnings include:
> > [    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist
> 
> This one is suspicious.
> 
> > [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
> > [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
> > [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
> > [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
> 
> These are normal because DMA engine is not compiled in with
> omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
> that doesn't matter for trying to figure out your problem.
> 
> > [    2.447784] platform omap_hsmmc.0: omap_device_late_idle: enabled but no driver.  Idling
> > [    2.456359] platform omap_hsmmc.1: omap_device_late_idle: enabled but no driver.  Idling
> 
> This is expected because of the failed MMC probe.
> 
> > # echo mem > /sys/power/state
> > [  107.398956] PM: Syncing filesystems ... done.
> > [  107.413757] Freezing user space processes ... (elapsed 0.02 seconds) done.
> > [  107.443481] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
> > [  107.474700] Suspending console(s) (use no_console_suspend to debug)
> > [  107.493560] PM: suspend of devices complete after 9.246 msecs
> > [  107.496063] PM: late suspend of devices complete after 2.502 msecs
> > [  107.500427] PM: noirq suspend of devices complete after 4.302 msecs
> > [  107.500488] Disabling non-boot CPUs ...
> > [  108.446838] Powerdomain (iva2_pwrdm) didn't enter target state 1
> > [  108.446868] Powerdomain (dss_pwrdm) didn't enter target state 1
> > [  108.446868] Powerdomain (per_pwrdm) didn't enter target state 1
> > [  108.446868] Powerdomain (core_pwrdm) didn't enter target state 1
> > [  108.446899] Powerdomain (usbhost_pwrdm) didn't enter target state 1
> > [  108.446899] Could not enter target state in pm_suspend
> > [  108.448852] PM: noirq resume of devices complete after 1.769 msecs
> > [  108.451873] PM: early resume of devices complete after 1.556 msecs
> > [  108.459716] PM: resume of devices complete after 7.690 msecs
> > [  108.541748] Restarting tasks ... done.
> > sh: write error: Operation not permitted
> >
> > This is all on an Overo AirSTORM (3703-based) plugged in to a GUMSTIX PALO43 dev board.
> 
> Hmm, interesting, I don't see this on my 3730-based Over FireSTORM.
> 
> But, after "converting" mine into an AirStorm[1], I see the same errors
> as you're seeing.  We're obviously doing something wrong when IVA and/or
> SGX are not present, so I will look into it.

There is a small chance that this patch will help:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-April/093710.html

Mark
--
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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Kevin Hilman]

"Mark A. Greer" <mgreer@animalcreek.com> writes:

> On Wed, Jul 11, 2012 at 10:07:06AM -0700, Kevin Hilman wrote:
>> "Joe Woodward" <jw@terrafix.co.uk> writes:
>> 
>> > -----Original Message-----
>> > From: Kevin Hilman <khilman@ti.com>
>> > To: "Joe Woodward" <jw@terrafix.co.uk>
>> > Cc: "linux-omap\@vger.kernel.org" <linux-omap@vger.kernel.org>
>> > Date: Tue, 10 Jul 2012 16:58:18 -0700
>> > Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
>> >
>> >> "Joe Woodward" <jw@terrafix.co.uk> writes:
>> >> 
>> >> > I've got 3.5-rc5 with the following patches applied to get system
>> >> suspend working on OMAP3:
>> >> >   - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
>> >> >   - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data:
>> >> fix 32K sync timer
>> >> >
>> >> > This has been built with the omap2plus_defconfig.
>> >> >
>> >> > However, If I disable the RTC (i.e.
>> >> CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when
>> >> suspending the device never wakes up.
>> >> >
>> >> > That is, I can't get any wakeups to happen (either through the
>> >> console, or GPIO buttons) hence I'm assuming the kernel has crashed...
>> >> >
>> >> > Any ideas?
>> >> >
>> >> > As far as I know there is no dependency on the RTC in 3.4, and with
>> >> the RTC compiled in I never see a problem on 3.5-rc5.
>> >> 
>> >> There is definitely a bug in the EHCI driver in v3.5 that cause a hang
>> >> in suspend, but the RTC connection is very strange.
>> >> 
>> >> I was not able to reproduce this.
>> >> 
>> >> Can you try the same with my current 'pm' branch[1].  I've got a
>> >> handful
>> >> of additional fixes there for various other problems where both MMC and
>> >> EHCI are preventing sucessful suspend with the default
>> >> omap2plus_defconfig.  (note the EHCI fix is simply diabling it in the
>> >> defconfig.)
>> >> 
>> >> Kevin
>> >> 
>> >
>> > Hi Kevin,
>> >
>> > Thanks for looking in to this.
>> 
>> And thanks for your detailed bug reports.
>> 
>> > I've taken a copy of the PM branch with tag "pm-20120710" and built with omap2plus_defconfig.
>> >
>> > But I get several warnings during boot, and suspend works - but almost nothing enters the target states:
>> >
>> > Warnings include:
>> > [    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist
>> 
>> This one is suspicious.
>> 
>> > [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>> > [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>> > [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
>> > [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>> 
>> These are normal because DMA engine is not compiled in with
>> omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
>> that doesn't matter for trying to figure out your problem.
>> 
>> > [    2.447784] platform omap_hsmmc.0: omap_device_late_idle: enabled but no driver.  Idling
>> > [    2.456359] platform omap_hsmmc.1: omap_device_late_idle: enabled but no driver.  Idling
>> 
>> This is expected because of the failed MMC probe.
>> 
>> > # echo mem > /sys/power/state
>> > [  107.398956] PM: Syncing filesystems ... done.
>> > [  107.413757] Freezing user space processes ... (elapsed 0.02 seconds) done.
>> > [  107.443481] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
>> > [  107.474700] Suspending console(s) (use no_console_suspend to debug)
>> > [  107.493560] PM: suspend of devices complete after 9.246 msecs
>> > [  107.496063] PM: late suspend of devices complete after 2.502 msecs
>> > [  107.500427] PM: noirq suspend of devices complete after 4.302 msecs
>> > [  107.500488] Disabling non-boot CPUs ...
>> > [  108.446838] Powerdomain (iva2_pwrdm) didn't enter target state 1
>> > [  108.446868] Powerdomain (dss_pwrdm) didn't enter target state 1
>> > [  108.446868] Powerdomain (per_pwrdm) didn't enter target state 1
>> > [  108.446868] Powerdomain (core_pwrdm) didn't enter target state 1
>> > [  108.446899] Powerdomain (usbhost_pwrdm) didn't enter target state 1
>> > [  108.446899] Could not enter target state in pm_suspend
>> > [  108.448852] PM: noirq resume of devices complete after 1.769 msecs
>> > [  108.451873] PM: early resume of devices complete after 1.556 msecs
>> > [  108.459716] PM: resume of devices complete after 7.690 msecs
>> > [  108.541748] Restarting tasks ... done.
>> > sh: write error: Operation not permitted
>> >
>> > This is all on an Overo AirSTORM (3703-based) plugged in to a GUMSTIX PALO43 dev board.
>> 
>> Hmm, interesting, I don't see this on my 3730-based Over FireSTORM.
>> 
>> But, after "converting" mine into an AirStorm[1], I see the same errors
>> as you're seeing.  We're obviously doing something wrong when IVA and/or
>> SGX are not present, so I will look into it.
>
> There is a small chance that this patch will help:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-April/093710.html
>

Thanks for the idea, but that patch is already merged in the branch
we're testing.

Kevin

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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Kevin Hilman]

+Paul

Kevin Hilman <khilman@ti.com> writes:

> "Joe Woodward" <jw@terrafix.co.uk> writes:
>
>> -----Original Message-----
>> From: Kevin Hilman <khilman@ti.com>
>> To: "Joe Woodward" <jw@terrafix.co.uk>
>> Cc: "linux-omap\@vger.kernel.org" <linux-omap@vger.kernel.org>
>> Date: Tue, 10 Jul 2012 16:58:18 -0700
>> Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
>>
>>> "Joe Woodward" <jw@terrafix.co.uk> writes:
>>> 
>>> > I've got 3.5-rc5 with the following patches applied to get system
>>> suspend working on OMAP3:
>>> >   - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
>>> >   - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data:
>>> fix 32K sync timer
>>> >
>>> > This has been built with the omap2plus_defconfig.
>>> >
>>> > However, If I disable the RTC (i.e.
>>> CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when
>>> suspending the device never wakes up.
>>> >
>>> > That is, I can't get any wakeups to happen (either through the
>>> console, or GPIO buttons) hence I'm assuming the kernel has crashed...
>>> >
>>> > Any ideas?
>>> >
>>> > As far as I know there is no dependency on the RTC in 3.4, and with
>>> the RTC compiled in I never see a problem on 3.5-rc5.
>>> 
>>> There is definitely a bug in the EHCI driver in v3.5 that cause a hang
>>> in suspend, but the RTC connection is very strange.
>>> 
>>> I was not able to reproduce this.
>>> 
>>> Can you try the same with my current 'pm' branch[1].  I've got a
>>> handful
>>> of additional fixes there for various other problems where both MMC and
>>> EHCI are preventing sucessful suspend with the default
>>> omap2plus_defconfig.  (note the EHCI fix is simply diabling it in the
>>> defconfig.)
>>> 
>>> Kevin
>>> 
>>
>> Hi Kevin,
>>
>> Thanks for looking in to this.
>
> And thanks for your detailed bug reports.
>
>> I've taken a copy of the PM branch with tag "pm-20120710" and built with omap2plus_defconfig.
>>
>> But I get several warnings during boot, and suspend works - but almost nothing enters the target states:
>>
>> Warnings include:
>> [    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist
>
> This one is suspicious.

But harmless.  I'll send a patch for this shortly, but it doesn't affect
the problem you're seeing.

>> [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>> [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>> [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
>> [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>
> These are normal because DMA engine is not compiled in with
> omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
> that doesn't matter for trying to figure out your problem.
>
>> [    2.447784] platform omap_hsmmc.0: omap_device_late_idle: enabled but no driver.  Idling
>> [    2.456359] platform omap_hsmmc.1: omap_device_late_idle: enabled but no driver.  Idling
>
> This is expected because of the failed MMC probe.
>
>> # echo mem > /sys/power/state
>> [  107.398956] PM: Syncing filesystems ... done.
>> [  107.413757] Freezing user space processes ... (elapsed 0.02 seconds) done.
>> [  107.443481] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
>> [  107.474700] Suspending console(s) (use no_console_suspend to debug)
>> [  107.493560] PM: suspend of devices complete after 9.246 msecs
>> [  107.496063] PM: late suspend of devices complete after 2.502 msecs
>> [  107.500427] PM: noirq suspend of devices complete after 4.302 msecs
>> [  107.500488] Disabling non-boot CPUs ...
>> [  108.446838] Powerdomain (iva2_pwrdm) didn't enter target state 1
>> [  108.446868] Powerdomain (dss_pwrdm) didn't enter target state 1
>> [  108.446868] Powerdomain (per_pwrdm) didn't enter target state 1
>> [  108.446868] Powerdomain (core_pwrdm) didn't enter target state 1
>> [  108.446899] Powerdomain (usbhost_pwrdm) didn't enter target state 1
>> [  108.446899] Could not enter target state in pm_suspend
>> [  108.448852] PM: noirq resume of devices complete after 1.769 msecs
>> [  108.451873] PM: early resume of devices complete after 1.556 msecs
>> [  108.459716] PM: resume of devices complete after 7.690 msecs
>> [  108.541748] Restarting tasks ... done.
>> sh: write error: Operation not permitted
>>
>> This is all on an Overo AirSTORM (3703-based) plugged in to a GUMSTIX PALO43 dev board.
>
> Hmm, interesting, I don't see this on my 3730-based Over FireSTORM.
>
> But, after "converting" mine into an AirStorm[1], I see the same errors
> as you're seeing.  We're obviously doing something wrong when IVA and/or
> SGX are not present, so I will look into it.

With the hack below on top of my pm branch, can you try to
suspend/resume on your AirSTORM?

You'll get a bunch of noise from the clockdomain code becasue of the
missing power domains, but you can ignore them.  

I'm hoping this will fix your issue.  Obviously, this hack is not a real
fix but just a test to see if the problem is where I think it is.  If
so, then I know the right solution and it's been discussed before but
never been a priority (at least for me) to fix.

Basically, we still need to fix up the registration of certain hwmods
and powerdomains based on whether or not certain IPs exist or not.  We
currently are rather blindly registering the hwmods for IVA, GFX etc.

Kevin

diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index bb883e4..b3568bb 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -341,7 +341,7 @@ static struct powerdomain dpll5_pwrdm = {
 /* As powerdomains are added or removed above, this list must also be changed */
 static struct powerdomain *powerdomains_omap3430_common[] __initdata = {
 	&wkup_omap2_pwrdm,
-	&iva2_pwrdm,
+	/* &iva2_pwrdm, */
 	&mpu_3xxx_pwrdm,
 	&neon_pwrdm,
 	&cam_pwrdm,
@@ -373,7 +373,7 @@ static struct powerdomain *powerdomains_omap3430es2_es3_0[] __initdata = {
 /* also includes 3630ES1.1+ */
 static struct powerdomain *powerdomains_omap3430es3_1plus[] __initdata = {
 	&core_3xxx_es3_1_pwrdm,
-	&sgx_pwrdm,
+	/* &sgx_pwrdm, */
 	&usbhost_pwrdm,
 	&dpll5_pwrdm,
 	NULL
--
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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Omar Ramirez Luna]

On 11 July 2012 12:07, Kevin Hilman <khilman@ti.com> wrote:
...
>> [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>> [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>> [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
>> [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>
> These are normal because DMA engine is not compiled in with
> omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
> that doesn't matter for trying to figure out your problem.

Hijacking this thread a little bit...

It looks like a dependency is missing in Kconfig then, as this also
fails to boot if the file system is in MMC. As you pointed out
CONFIG_DMADEVICES and CONFIG_DMA_OMAP is needed to boot in this case.
I'm using a Panda 4460.

Regards,

Omar

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Kevin Hilman]

Omar Ramirez Luna <omar.luna@linaro.org> writes:

> On 11 July 2012 12:07, Kevin Hilman <khilman@ti.com> wrote:
> ...
>>> [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>>> [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>>> [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
>>> [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>>
>> These are normal because DMA engine is not compiled in with
>> omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
>> that doesn't matter for trying to figure out your problem.
>
> Hijacking this thread a little bit...
>
> It looks like a dependency is missing in Kconfig then, as this also
> fails to boot if the file system is in MMC. As you pointed out
> CONFIG_DMADEVICES and CONFIG_DMA_OMAP is needed to boot in this case.
> I'm using a Panda 4460.

Yes, the drivers that have been converted to DMA engine should probably
'select DMADEVICES' and 'select DMA_OMAP' since they will now depend on
DMA engine.

Kevin

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Shubhrajyoti]

On Thursday 12 July 2012 02:59 AM, Kevin Hilman wrote:
> Omar Ramirez Luna <omar.luna@linaro.org> writes:
>
>> On 11 July 2012 12:07, Kevin Hilman <khilman@ti.com> wrote:
>> ...
>>>> [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>>>> [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>>>> [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
>>>> [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>>> These are normal because DMA engine is not compiled in with
>>> omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
>>> that doesn't matter for trying to figure out your problem.
>> Hijacking this thread a little bit...
>>
>> It looks like a dependency is missing in Kconfig then, as this also
>> fails to boot if the file system is in MMC. As you pointed out
>> CONFIG_DMADEVICES and CONFIG_DMA_OMAP is needed to boot in this case.
>> I'm using a Panda 4460.
> Yes, the drivers that have been converted to DMA engine should probably
> 'select DMADEVICES' and 'select DMA_OMAP' since they will now depend on
> DMA engine.
looks like some effort already
https://patchwork.kernel.org/patch/1157731/
>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Tony Lindgren]

* Kevin Hilman <khilman@ti.com> [120711 14:34]:
> Omar Ramirez Luna <omar.luna@linaro.org> writes:
> 
> > On 11 July 2012 12:07, Kevin Hilman <khilman@ti.com> wrote:
> > ...
> >>> [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
> >>> [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
> >>> [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
> >>> [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
> >>
> >> These are normal because DMA engine is not compiled in with
> >> omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
> >> that doesn't matter for trying to figure out your problem.
> >
> > Hijacking this thread a little bit...
> >
> > It looks like a dependency is missing in Kconfig then, as this also
> > fails to boot if the file system is in MMC. As you pointed out
> > CONFIG_DMADEVICES and CONFIG_DMA_OMAP is needed to boot in this case.
> > I'm using a Panda 4460.
> 
> Yes, the drivers that have been converted to DMA engine should probably
> 'select DMADEVICES' and 'select DMA_OMAP' since they will now depend on
> DMA engine.

The drivers should also work with PIO if DMADEVICES is not selected.
If they don't it's a bug in the driver, or at least the driver probe
should return an error.

Regards,

Tony

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Kevin Hilman <khilman@ti.com> [120711 14:34]:
>> Omar Ramirez Luna <omar.luna@linaro.org> writes:
>> 
>> > On 11 July 2012 12:07, Kevin Hilman <khilman@ti.com> wrote:
>> > ...
>> >>> [    2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>> >>> [    2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62
>> >>> [    2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
>> >>> [    2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
>> >>
>> >> These are normal because DMA engine is not compiled in with
>> >> omap2plus_defconfig.  MMC wont' work unless you build in DMA engine, but
>> >> that doesn't matter for trying to figure out your problem.
>> >
>> > Hijacking this thread a little bit...
>> >
>> > It looks like a dependency is missing in Kconfig then, as this also
>> > fails to boot if the file system is in MMC. As you pointed out
>> > CONFIG_DMADEVICES and CONFIG_DMA_OMAP is needed to boot in this case.
>> > I'm using a Panda 4460.
>> 
>> Yes, the drivers that have been converted to DMA engine should probably
>> 'select DMADEVICES' and 'select DMA_OMAP' since they will now depend on
>> DMA engine.
>
> The drivers should also work with PIO if DMADEVICES is not selected.
> If they don't it's a bug in the driver, or at least the driver probe
> should return an error.

There was definitely a bug in the MMC driver where probe was not
returning an error.  Looks like this bug has existed for awhile in the
MMC driver, and continued after the DMA engine conversion.

I sent a patch on top of Russell's DMA engine conversion (which he has
now applied in his for-next) to fix this problem in the DMA-converted
driver.

Kevin

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Joe Woodward]

...snip...
> > Hmm, interesting, I don't see this on my 3730-based Over FireSTORM.
> >
> > But, after "converting" mine into an AirStorm[1], I see the same
> errors
> > as you're seeing.  We're obviously doing something wrong when IVA
> and/or
> > SGX are not present, so I will look into it.
> 
> With the hack below on top of my pm branch, can you try to
> suspend/resume on your AirSTORM?
> 
> You'll get a bunch of noise from the clockdomain code becasue of the
> missing power domains, but you can ignore them.  
> 
> I'm hoping this will fix your issue.  Obviously, this hack is not a
> real
> fix but just a test to see if the problem is where I think it is.  If
> so, then I know the right solution and it's been discussed before but
> never been a priority (at least for me) to fix.
> 
> Basically, we still need to fix up the registration of certain hwmods
> and powerdomains based on whether or not certain IPs exist or not.  We
> currently are rather blindly registering the hwmods for IVA, GFX etc.
> 
> Kevin
> 

After applying the patch (and also your GPIO fix for the ads7846).

As you said, when booting lots of warnings are spat out:

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at arch/arm/mach-omap2/clockdomain.c:237 _resolve_clkdm_deps.clone.0+0x98/0x108()
[    0.000000] Modules linked in:
[    0.000000]
[    0.000000] [<c001b75c>] (unwind_backtrace+0x0/0xf0) from [<c0041788>] (warn_slowpath_common+0x4c/0x64)
[    0.000000] [<c0041788>] (warn_slowpath_common+0x4c/0x64) from [<c0041834>] (warn_slowpath_fmt+0x30/0x40)
[    0.000000] [<c0041834>] (warn_slowpath_fmt+0x30/0x40) from [<c00321a0>] (_resolve_clkdm_deps.clone.0+0x98/0x108)
[    0.000000] [<c00321a0>] (_resolve_clkdm_deps.clone.0+0x98/0x108) from [<c0032bb8>] (clkdm_complete_init+0x3c/0xa0)
[    0.000000] [<c0032bb8>] (clkdm_complete_init+0x3c/0xa0) from [<c06d2458>] (omap3_init_early+0x20/0x30)
[    0.000000] [<c06d2458>] (omap3_init_early+0x20/0x30) from [<c06ce1a8>] (setup_arch+0x814/0x934)
[    0.000000] [<c06ce1a8>] (setup_arch+0x814/0x934) from [<c06ca584>] (start_kernel+0x88/0x300)
[    0.000000] [<c06ca584>] (start_kernel+0x88/0x300) from [<80008044>] (0x80008044)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---

And now when suspending I get:

# echo mem > /sys/power/state
[   78.174713] PM: Syncing filesystems ... done.
[   78.190582] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   78.216430] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   78.247558] Suspending console(s) (use no_console_suspend to debug)
[   78.379241] PM: suspend of devices complete after 120.605 msecs
[   78.382934] PM: late suspend of devices complete after 3.692 msecs
[   78.388671] PM: noirq suspend of devices complete after 5.706 msecs
[   78.388732] Disabling non-boot CPUs ...
[  107.219818] Powerdomain (core_pwrdm) didn't enter target state 1
[  107.219818] Could not enter target state in pm_suspend
[  107.222808] PM: noirq resume of devices complete after 2.838 msecs
[  107.226684] PM: early resume of devices complete after 2.380 msecs
[  107.592620] mmc1: error -110 during resume (card was removed?)
[  107.602752] PM: resume of devices complete after 375.946 msecs
[  107.667449] Restarting tasks ... done.
sh: write error: Operation not permitted

So most of the warnings have gone, but core still fails to enter the target state.

This is sitll using the omap2plus_defconfig with:
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

CONFIG_DMADEVICES=y
CONFIG_DMA_OMAP=y

CONFIG_SQUASHFS=y

All running from RAM-based RFS.

Cheers,
Joe


> diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
> b/arch/arm/mach-omap2/powerdomains3xxx_data.c
> index bb883e4..b3568bb 100644
> --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
> +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
> @@ -341,7 +341,7 @@ static struct powerdomain dpll5_pwrdm = {
>  /* As powerdomains are added or removed above, this list must also be
> changed */
>  static struct powerdomain *powerdomains_omap3430_common[] __initdata =
> {
>  	&wkup_omap2_pwrdm,
> -	&iva2_pwrdm,
> +	/* &iva2_pwrdm, */
>  	&mpu_3xxx_pwrdm,
>  	&neon_pwrdm,
>  	&cam_pwrdm,
> @@ -373,7 +373,7 @@ static struct powerdomain
> *powerdomains_omap3430es2_es3_0[] __initdata = {
>  /* also includes 3630ES1.1+ */
>  static struct powerdomain *powerdomains_omap3430es3_1plus[] __initdata
> = {
>  	&core_3xxx_es3_1_pwrdm,
> -	&sgx_pwrdm,
> +	/* &sgx_pwrdm, */
>  	&usbhost_pwrdm,
>  	&dpll5_pwrdm,
>  	NULL
> --
> 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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Paul Walmsley]

Hi Joe

can you give this one a try to see if it helps:

http://marc.info/?l=linux-omap&m=134209072829531&w=2


- Paul

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Joe Woodward]

-----Original Message-----
From: Paul Walmsley <paul@pwsan.com>
To: Joe Woodward <jw@terrafix.co.uk>
Cc: Kevin Hilman <khilman@ti.com>, "linux-omap\\@vger.kernel.org" <linux-omap@vger.kernel.org>
Date: Thu, 12 Jul 2012 04:59:09 -0600 (MDT)
Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

> 
> Hi Joe
> 
> can you give this one a try to see if it helps:
> 
> http://marc.info/?l=linux-omap&m=134209072829531&w=2
> 
> 
> - Paul

Hi Paul,

I've applied this on top of Kevin's PM branch, along with Kevin's ads7846 fix:
http://www.spinics.net/lists/linux-omap/msg73717.html

I think this has fixed the following warning:
[    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist
 
But when I try and suspend I still get the same problems:
# echo mem > /sys/power/state
[   13.283935] PM: Syncing filesystems ... done.
[   13.300537] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   13.324859] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[   13.356140] Suspending console(s) (use no_console_suspend to debug)
[   13.487823] PM: suspend of devices complete after 120.578 msecs
[   13.491577] PM: late suspend of devices complete after 3.722 msecs
[   13.497375] PM: noirq suspend of devices complete after 5.767 msecs
[   13.497436] Disabling non-boot CPUs ...
[   15.806640] Powerdomain (iva2_pwrdm) didn't enter target state 1
[   15.806640] Powerdomain (dss_pwrdm) didn't enter target state 1
[   15.806671] Powerdomain (per_pwrdm) didn't enter target state 1
[   15.806671] Powerdomain (core_pwrdm) didn't enter target state 1
[   15.806671] Powerdomain (usbhost_pwrdm) didn't enter target state 1
[   15.806671] Could not enter target state in pm_suspend
[   15.809722] PM: noirq resume of devices complete after 2.868 msecs
[   15.813598] PM: early resume of devices complete after 2.380 msecs
[   16.179382] mmc1: error -110 during resume (card was removed?)
[   16.189575] PM: resume of devices complete after 375.824 msecs
[   16.279602] Restarting tasks ... done.
sh: write error: Operation not permitted

Cheers,
Joe

> --
> 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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3138 bytes --]

Hello Joe,

On Thu, 12 Jul 2012, Joe Woodward wrote:

> I think this has fixed the following warning:
> [    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist
>  
> But when I try and suspend I still get the same problems:
> # echo mem > /sys/power/state
> [   13.283935] PM: Syncing filesystems ... done.
> [   13.300537] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [   13.324859] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
> [   13.356140] Suspending console(s) (use no_console_suspend to debug)
> [   13.487823] PM: suspend of devices complete after 120.578 msecs
> [   13.491577] PM: late suspend of devices complete after 3.722 msecs
> [   13.497375] PM: noirq suspend of devices complete after 5.767 msecs
> [   13.497436] Disabling non-boot CPUs ...
> [   15.806640] Powerdomain (iva2_pwrdm) didn't enter target state 1
> [   15.806640] Powerdomain (dss_pwrdm) didn't enter target state 1
> [   15.806671] Powerdomain (per_pwrdm) didn't enter target state 1
> [   15.806671] Powerdomain (core_pwrdm) didn't enter target state 1
> [   15.806671] Powerdomain (usbhost_pwrdm) didn't enter target state 1
> [   15.806671] Could not enter target state in pm_suspend
> [   15.809722] PM: noirq resume of devices complete after 2.868 msecs
> [   15.813598] PM: early resume of devices complete after 2.380 msecs
> [   16.179382] mmc1: error -110 during resume (card was removed?)
> [   16.189575] PM: resume of devices complete after 375.824 msecs
> [   16.279602] Restarting tasks ... done.
> sh: write error: Operation not permitted

Thanks for the test.  Perhaps you could try the following untested patch?


- Paul

---
 arch/arm/mach-omap2/pm34xx.c |   14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..ced2f76 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -545,13 +545,10 @@ static void __init prcm_setup_regs(void)
 			  OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
 
 	/* Don't attach IVA interrupts */
-	if (omap3_has_iva()) {
-		omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
-		omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
-		omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
-		omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD,
-					OMAP3430_PM_IVAGRPSEL);
-	}
+	omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
+	omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
+	omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
+	omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL);
 
 	/* Clear any pending 'reset' flags */
 	omap2_prm_write_mod_reg(0xffffffff, MPU_MOD, OMAP2_RM_RSTST);
@@ -565,8 +562,7 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }
-- 
1.7.10

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Joe Woodward]

-----Original Message-----
From: Paul Walmsley <paul@pwsan.com>
To: Joe Woodward <jw@terrafix.co.uk>
Cc: Kevin Hilman <khilman@ti.com>, "linux-omap\\\\@vger.kernel.org" <linux-omap@vger.kernel.org>
Date: Thu, 12 Jul 2012 13:35:14 -0600 (MDT)
Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

> Hello Joe,
> 
> On Thu, 12 Jul 2012, Joe Woodward wrote:
> 
> > I think this has fixed the following warning:
> > [    0.000000] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does
> not exist
> >  
> > But when I try and suspend I still get the same problems:
> > # echo mem > /sys/power/state
> > [   13.283935] PM: Syncing filesystems ... done.
> > [   13.300537] Freezing user space processes ... (elapsed 0.01
> seconds) done.
> > [   13.324859] Freezing remaining freezable tasks ... (elapsed 0.02
> seconds) done.
> > [   13.356140] Suspending console(s) (use no_console_suspend to
> debug)
> > [   13.487823] PM: suspend of devices complete after 120.578 msecs
> > [   13.491577] PM: late suspend of devices complete after 3.722 msecs
> > [   13.497375] PM: noirq suspend of devices complete after 5.767
> msecs
> > [   13.497436] Disabling non-boot CPUs ...
> > [   15.806640] Powerdomain (iva2_pwrdm) didn't enter target state 1
> > [   15.806640] Powerdomain (dss_pwrdm) didn't enter target state 1
> > [   15.806671] Powerdomain (per_pwrdm) didn't enter target state 1
> > [   15.806671] Powerdomain (core_pwrdm) didn't enter target state 1
> > [   15.806671] Powerdomain (usbhost_pwrdm) didn't enter target state
> 1
> > [   15.806671] Could not enter target state in pm_suspend
> > [   15.809722] PM: noirq resume of devices complete after 2.868 msecs
> > [   15.813598] PM: early resume of devices complete after 2.380 msecs
> > [   16.179382] mmc1: error -110 during resume (card was removed?)
> > [   16.189575] PM: resume of devices complete after 375.824 msecs
> > [   16.279602] Restarting tasks ... done.
> > sh: write error: Operation not permitted
> 
> Thanks for the test.  Perhaps you could try the following untested
> patch?
> 
> 
> - Paul
> 

Thanks Paul,

That patch does indeed seem to fix all my problems!

With it I can now suspend, and all power domains hit the target states.

Kevin - I did reply to your request for logs, but haven't seen the message make it to the mailing list...
If you've not got it, let me know and I can try and send it again.

Cheers,
Joe

> ---
>  arch/arm/mach-omap2/pm34xx.c |   14 +++++---------
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/pm34xx.c
> b/arch/arm/mach-omap2/pm34xx.c
> index e4fc88c..ced2f76 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -545,13 +545,10 @@ static void __init prcm_setup_regs(void)
>  			  OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
>  
>  	/* Don't attach IVA interrupts */
> -	if (omap3_has_iva()) {
> -		omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
> -		omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
> -		omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
> -		omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD,
> -					OMAP3430_PM_IVAGRPSEL);
> -	}
> +	omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
> +	omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
> +	omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
> +	omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL);
>  
>  	/* Clear any pending 'reset' flags */
>  	omap2_prm_write_mod_reg(0xffffffff, MPU_MOD, OMAP2_RM_RSTST);
> @@ -565,8 +562,7 @@ static void __init prcm_setup_regs(void)
>  	/* Clear any pending PRCM interrupts */
>  	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
>  
> -	if (omap3_has_iva())
> -		omap3_iva_idle();
> +	omap3_iva_idle();
>  
>  	omap3_d2d_idle();
>  }
> -- 
> 1.7.10


--
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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Paul Walmsley]

+ Mark

On Fri, 13 Jul 2012, Joe Woodward wrote:

> Thanks Paul,
> 
> That patch does indeed seem to fix all my problems!
> 
> With it I can now suspend, and all power domains hit the target states.

OK, great.  That patch is basically a revert of 
a819c4f16d5a2708c11e708fd59a96565c5384a8 ("ARM: OMAP3: PM: Only access IVA 
if one exists").  Sounds like we need to discriminate between the case 
where the IVA2 is present but has been efused off in some way (as in the 
AM3703) vs. the case where the IVA2 is not present at all (as in the 
AM35xx).

Mark, do you have the time to take a look at this?  Maybe omap3_has_iva() 
needs to be split into omap3_has_iva() and omap3_has_usable_iva().  Or 
maybe you can come up with a better idea...


- Paul

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Mark A. Greer]

On Fri, Jul 13, 2012 at 12:26:13PM -0600, Paul Walmsley wrote:
> + Mark
> 
> On Fri, 13 Jul 2012, Joe Woodward wrote:
> 
> > Thanks Paul,
> > 
> > That patch does indeed seem to fix all my problems!
> > 
> > With it I can now suspend, and all power domains hit the target states.
> 
> OK, great.  That patch is basically a revert of 
> a819c4f16d5a2708c11e708fd59a96565c5384a8 ("ARM: OMAP3: PM: Only access IVA 
> if one exists").  Sounds like we need to discriminate between the case 
> where the IVA2 is present but has been efused off in some way (as in the 
> AM3703) vs. the case where the IVA2 is not present at all (as in the 
> AM35xx).
> 
> Mark, do you have the time to take a look at this?  Maybe omap3_has_iva() 
> needs to be split into omap3_has_iva() and omap3_has_usable_iva().  Or 
> maybe you can come up with a better idea...

Sure, I'll see what I can figure out.

Mark

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Mark A. Greer]

On Fri, Jul 13, 2012 at 12:26:13PM -0600, Paul Walmsley wrote:
> + Mark
> 
> On Fri, 13 Jul 2012, Joe Woodward wrote:
> 
> > Thanks Paul,
> > 
> > That patch does indeed seem to fix all my problems!
> > 
> > With it I can now suspend, and all power domains hit the target states.
> 
> OK, great.  That patch is basically a revert of 
> a819c4f16d5a2708c11e708fd59a96565c5384a8 ("ARM: OMAP3: PM: Only access IVA 
> if one exists").  Sounds like we need to discriminate between the case 
> where the IVA2 is present but has been efused off in some way (as in the 
> AM3703) vs. the case where the IVA2 is not present at all (as in the 
> AM35xx).
> 
> Mark, do you have the time to take a look at this?  Maybe omap3_has_iva() 
> needs to be split into omap3_has_iva() and omap3_has_usable_iva().  Or 
> maybe you can come up with a better idea...

Hi Joe.

I'm finally getting around to this...  Unfortunately, I don't have the
hardware to test it so I can't tell exactly what code needs to run to make
it work again.   Would you mind identifying the pieces of code need to run
for it to work?  omap3_has_iva() shows up in just a few places.

Thanks,

Mark

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Paul Walmsley]

On Mon, 16 Jul 2012, Mark A. Greer wrote:

> I'm finally getting around to this...  Unfortunately, I don't have the
> hardware to test it so I can't tell exactly what code needs to run to make
> it work again.   Would you mind identifying the pieces of code need to run
> for it to work?  omap3_has_iva() shows up in just a few places.

We did a test by removing the two instances in pm34xx.c.  I'm pretty sure 
that the IVAGRPSEL writes are necessary, since the reset values for those 
bits are 1, and those definitely need to be cleared.  Not sure about the 
omap3_iva_idle() call; Joe, maybe you can try with just the first hunk of 
the patch that I sent?


- Paul

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Joe Woodward]

-----Original Message-----
From: Paul Walmsley <paul@pwsan.com>
To: Joe Woodward <jw@terrafix.co.uk>, "Mark A. Greer" <mgreer@animalcreek.com>
Cc: Kevin Hilman <khilman@ti.com>, linux-omap@vger.kernel.org
Date: Mon, 16 Jul 2012 18:43:15 -0600 (MDT)
Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

> On Mon, 16 Jul 2012, Mark A. Greer wrote:
> 
> > I'm finally getting around to this...  Unfortunately, I don't have
> the
> > hardware to test it so I can't tell exactly what code needs to run to
> make
> > it work again.   Would you mind identifying the pieces of code need
> to run
> > for it to work?  omap3_has_iva() shows up in just a few places.
> 
> We did a test by removing the two instances in pm34xx.c.  I'm pretty
> sure 
> that the IVAGRPSEL writes are necessary, since the reset values for
> those 
> bits are 1, and those definitely need to be cleared.  Not sure about
> the 
> omap3_iva_idle() call; Joe, maybe you can try with just the first hunk
> of 
> the patch that I sent?

The patch you sent is basically in two halves:
  - the writes to the registers
  - the calling of omap3_iva_idle().

If I patch only the writes to the registers then suspend still fails.
If I patch only the calling of omap3_iva_idle() then suspend works.
If I patch both the writes to the registers and the calling of omap3_iva_idle() then suspend works.

Cheers,
Joe

> 
> 
> - Paul
> --
> 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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Paul Walmsley]

Hi Joe, Mark,

On Tue, 17 Jul 2012, Joe Woodward wrote:

> The patch you sent is basically in two halves:
>   - the writes to the registers
>   - the calling of omap3_iva_idle().
> 
> If I patch only the writes to the registers then suspend still fails.
> If I patch only the calling of omap3_iva_idle() then suspend works.
> If I patch both the writes to the registers and the calling of omap3_iva_idle() then suspend works.

Wow, that's unexpected.  Thanks very much for trying this.

Well Mark, I guess that's your answer.  Looks like the IVA is still 
running on that AM3703 chip.  I guess it's probably best to do both 
halves, anyway.


- Paul

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Mark A. Greer]

On Tue, Jul 17, 2012 at 01:28:13PM -0600, Paul Walmsley wrote:
> Hi Joe, Mark,
> 
> On Tue, 17 Jul 2012, Joe Woodward wrote:
> 
> > The patch you sent is basically in two halves:
> >   - the writes to the registers
> >   - the calling of omap3_iva_idle().
> > 
> > If I patch only the writes to the registers then suspend still fails.
> > If I patch only the calling of omap3_iva_idle() then suspend works.
> > If I patch both the writes to the registers and the calling of omap3_iva_idle() then suspend works.
> 
> Wow, that's unexpected.  Thanks very much for trying this.
> 
> Well Mark, I guess that's your answer.  Looks like the IVA is still 
> running on that AM3703 chip.  I guess it's probably best to do both 
> halves, anyway.

How does this look?

Based on linux-omap/master (ce6b8b760e2fef013b1038e5398580d187f80c00).

I'm not very creative when it comes to naming this thing so I'm
happy if you have a better idea.  I tested it on an am37xevm and
tried to test on an am35xevm but it appears that the am35xevm is
broken in that branch. :(

Mark
--

>From b889b2642bd16b3d8e5856f39a3ea08d10102aad Mon Sep 17 00:00:00 2001
From: Mark A. Greer <mgreer@animalcreek.com>
Date: Tue, 17 Jul 2012 18:50:01 -0700
Subject: [PATCH] ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature

It appears that the am3703 and possibly the am3715 SoCs
have an active IVA subsystem even though the CONTROL_IDCODE
register indicates that they don't.  From experimentation,
it seems that the IVA still requires some registers to be
initialized even though we don't want it fully functional.

To accomplish this, add a new feature (OMAP3_HAS_IVA_REGS)
that indicates that the IVA should be initialized but not
really used.

Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---
 arch/arm/mach-omap2/id.c              |    2 +-
 arch/arm/mach-omap2/pm34xx.c          |    4 ++--
 arch/arm/plat-omap/include/plat/cpu.h |   22 ++++++++++++----------
 3 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 40373db..4072fbd 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -242,7 +242,7 @@ void __init omap3xxx_check_features(void)
 	OMAP3_CHECK_FEATURE(status, NEON);
 	OMAP3_CHECK_FEATURE(status, ISP);
 	if (cpu_is_omap3630())
-		omap_features |= OMAP3_HAS_192MHZ_CLK;
+		omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS;
 	if (cpu_is_omap3430() || cpu_is_omap3630())
 		omap_features |= OMAP3_HAS_IO_WAKEUP;
 	if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..119cbf0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -545,7 +545,7 @@ static void __init prcm_setup_regs(void)
 			  OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
 
 	/* Don't attach IVA interrupts */
-	if (omap3_has_iva()) {
+	if (omap3_has_iva() || omap3_has_iva_regs()) {
 		omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
 		omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
 		omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
@@ -565,7 +565,7 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 
-	if (omap3_has_iva())
+	if (omap3_has_iva() || omap3_has_iva_regs())
 		omap3_iva_idle();
 
 	omap3_d2d_idle();
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 68b180e..2509bf4 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -451,16 +451,17 @@ extern u32 omap_features;
 
 #define OMAP3_HAS_L2CACHE		BIT(0)
 #define OMAP3_HAS_IVA			BIT(1)
-#define OMAP3_HAS_SGX			BIT(2)
-#define OMAP3_HAS_NEON			BIT(3)
-#define OMAP3_HAS_ISP			BIT(4)
-#define OMAP3_HAS_192MHZ_CLK		BIT(5)
-#define OMAP3_HAS_IO_WAKEUP		BIT(6)
-#define OMAP3_HAS_SDRC			BIT(7)
-#define OMAP3_HAS_IO_CHAIN_CTRL		BIT(8)
-#define OMAP4_HAS_MPU_1GHZ		BIT(9)
-#define OMAP4_HAS_MPU_1_2GHZ		BIT(10)
-#define OMAP4_HAS_MPU_1_5GHZ		BIT(11)
+#define OMAP3_HAS_IVA_REGS		BIT(2)
+#define OMAP3_HAS_SGX			BIT(3)
+#define OMAP3_HAS_NEON			BIT(4)
+#define OMAP3_HAS_ISP			BIT(5)
+#define OMAP3_HAS_192MHZ_CLK		BIT(6)
+#define OMAP3_HAS_IO_WAKEUP		BIT(7)
+#define OMAP3_HAS_SDRC			BIT(8)
+#define OMAP3_HAS_IO_CHAIN_CTRL		BIT(9)
+#define OMAP4_HAS_MPU_1GHZ		BIT(10)
+#define OMAP4_HAS_MPU_1_2GHZ		BIT(11)
+#define OMAP4_HAS_MPU_1_5GHZ		BIT(12)
 
 
 #define OMAP3_HAS_FEATURE(feat,flag)			\
@@ -472,6 +473,7 @@ static inline unsigned int omap3_has_ ##feat(void)	\
 OMAP3_HAS_FEATURE(l2cache, L2CACHE)
 OMAP3_HAS_FEATURE(sgx, SGX)
 OMAP3_HAS_FEATURE(iva, IVA)
+OMAP3_HAS_FEATURE(iva_regs, IVA_REGS)
 OMAP3_HAS_FEATURE(neon, NEON)
 OMAP3_HAS_FEATURE(isp, ISP)
 OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
-- 
1.7.0.4

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Joe Woodward]

-----Original Message-----
From: "Mark A. Greer" <mgreer@animalcreek.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Joe Woodward <jw@terrafix.co.uk>, Kevin Hilman <khilman@ti.com>, linux-omap@vger.kernel.org
Date: Tue, 17 Jul 2012 19:20:35 -0700
Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

> On Tue, Jul 17, 2012 at 01:28:13PM -0600, Paul Walmsley wrote:
> > Hi Joe, Mark,
> > 
> > On Tue, 17 Jul 2012, Joe Woodward wrote:
> > 
> > > The patch you sent is basically in two halves:
> > >   - the writes to the registers
> > >   - the calling of omap3_iva_idle().
> > > 
> > > If I patch only the writes to the registers then suspend still
> fails.
> > > If I patch only the calling of omap3_iva_idle() then suspend works.
> > > If I patch both the writes to the registers and the calling of
> omap3_iva_idle() then suspend works.
> > 
> > Wow, that's unexpected.  Thanks very much for trying this.
> > 
> > Well Mark, I guess that's your answer.  Looks like the IVA is still 
> > running on that AM3703 chip.  I guess it's probably best to do both 
> > halves, anyway.
> 
> How does this look?
> 
> Based on linux-omap/master (ce6b8b760e2fef013b1038e5398580d187f80c00).
> 
> I'm not very creative when it comes to naming this thing so I'm
> happy if you have a better idea.  I tested it on an am37xevm and
> tried to test on an am35xevm but it appears that the am35xevm is
> broken in that branch. :(
> 
> Mark
> --
> 
> From b889b2642bd16b3d8e5856f39a3ea08d10102aad Mon Sep 17 00:00:00 2001
> From: Mark A. Greer <mgreer@animalcreek.com>
> Date: Tue, 17 Jul 2012 18:50:01 -0700
> Subject: [PATCH] ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature
> 
> It appears that the am3703 and possibly the am3715 SoCs
> have an active IVA subsystem even though the CONTROL_IDCODE
> register indicates that they don't.  From experimentation,
> it seems that the IVA still requires some registers to be
> initialized even though we don't want it fully functional.
> 
> To accomplish this, add a new feature (OMAP3_HAS_IVA_REGS)
> that indicates that the IVA should be initialized but not
> really used.
> 
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> ---
>  arch/arm/mach-omap2/id.c              |    2 +-
>  arch/arm/mach-omap2/pm34xx.c          |    4 ++--
>  arch/arm/plat-omap/include/plat/cpu.h |   22 ++++++++++++----------
>  3 files changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 40373db..4072fbd 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -242,7 +242,7 @@ void __init omap3xxx_check_features(void)
>  	OMAP3_CHECK_FEATURE(status, NEON);
>  	OMAP3_CHECK_FEATURE(status, ISP);
>  	if (cpu_is_omap3630())
> -		omap_features |= OMAP3_HAS_192MHZ_CLK;
> +		omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS;
>  	if (cpu_is_omap3430() || cpu_is_omap3630())
>  		omap_features |= OMAP3_HAS_IO_WAKEUP;
>  	if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
> diff --git a/arch/arm/mach-omap2/pm34xx.c
> b/arch/arm/mach-omap2/pm34xx.c
> index e4fc88c..119cbf0 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -545,7 +545,7 @@ static void __init prcm_setup_regs(void)
>  			  OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
>  
>  	/* Don't attach IVA interrupts */
> -	if (omap3_has_iva()) {
> +	if (omap3_has_iva() || omap3_has_iva_regs()) {
>  		omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
>  		omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
>  		omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
> @@ -565,7 +565,7 @@ static void __init prcm_setup_regs(void)
>  	/* Clear any pending PRCM interrupts */
>  	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
>  
> -	if (omap3_has_iva())
> +	if (omap3_has_iva() || omap3_has_iva_regs())
>  		omap3_iva_idle();
>  
>  	omap3_d2d_idle();
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h
> b/arch/arm/plat-omap/include/plat/cpu.h
> index 68b180e..2509bf4 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -451,16 +451,17 @@ extern u32 omap_features;
>  
>  #define OMAP3_HAS_L2CACHE		BIT(0)
>  #define OMAP3_HAS_IVA			BIT(1)
> -#define OMAP3_HAS_SGX			BIT(2)
> -#define OMAP3_HAS_NEON			BIT(3)
> -#define OMAP3_HAS_ISP			BIT(4)
> -#define OMAP3_HAS_192MHZ_CLK		BIT(5)
> -#define OMAP3_HAS_IO_WAKEUP		BIT(6)
> -#define OMAP3_HAS_SDRC			BIT(7)
> -#define OMAP3_HAS_IO_CHAIN_CTRL		BIT(8)
> -#define OMAP4_HAS_MPU_1GHZ		BIT(9)
> -#define OMAP4_HAS_MPU_1_2GHZ		BIT(10)
> -#define OMAP4_HAS_MPU_1_5GHZ		BIT(11)
> +#define OMAP3_HAS_IVA_REGS		BIT(2)
> +#define OMAP3_HAS_SGX			BIT(3)
> +#define OMAP3_HAS_NEON			BIT(4)
> +#define OMAP3_HAS_ISP			BIT(5)
> +#define OMAP3_HAS_192MHZ_CLK		BIT(6)
> +#define OMAP3_HAS_IO_WAKEUP		BIT(7)
> +#define OMAP3_HAS_SDRC			BIT(8)
> +#define OMAP3_HAS_IO_CHAIN_CTRL		BIT(9)
> +#define OMAP4_HAS_MPU_1GHZ		BIT(10)
> +#define OMAP4_HAS_MPU_1_2GHZ		BIT(11)
> +#define OMAP4_HAS_MPU_1_5GHZ		BIT(12)
>  
>  
>  #define OMAP3_HAS_FEATURE(feat,flag)			\
> @@ -472,6 +473,7 @@ static inline unsigned int omap3_has_
> ##feat(void)	\
>  OMAP3_HAS_FEATURE(l2cache, L2CACHE)
>  OMAP3_HAS_FEATURE(sgx, SGX)
>  OMAP3_HAS_FEATURE(iva, IVA)
> +OMAP3_HAS_FEATURE(iva_regs, IVA_REGS)
>  OMAP3_HAS_FEATURE(neon, NEON)
>  OMAP3_HAS_FEATURE(isp, ISP)
>  OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
> -- 
> 1.7.0.4
> 
> --

Tested on a GUMSTIX Overo AirSTORM (AM3703-based), and that fixes the problem for me, thanks!

Cheers,
Joe

> 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

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Mark A. Greer]

On Wed, Jul 18, 2012 at 11:06:34AM +0100, Joe Woodward wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>

> > How does this look?

> > Subject: [PATCH] ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature
> > 
> > It appears that the am3703 and possibly the am3715 SoCs
> > have an active IVA subsystem even though the CONTROL_IDCODE
> > register indicates that they don't.  From experimentation,
> > it seems that the IVA still requires some registers to be
> > initialized even though we don't want it fully functional.
> > 
> > To accomplish this, add a new feature (OMAP3_HAS_IVA_REGS)
> > that indicates that the IVA should be initialized but not
> > really used.
> > 
> > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> > ---

> Tested on a GUMSTIX Overo AirSTORM (AM3703-based), and that fixes the problem for me, thanks!

Great!  Thanks for testing, Joe.

Paul, Kevin, any comments?

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Juha Kuikka]

A thousand apologizes for double posting, some html sneaked into the
first email and it got dropped by the list server.

I am running on a gumstix with OMAP 3503 on it (name escapes me at the
moment) and it has the same issue.

Just applying Mark's patch on top of
55936cdfaaf11ac352b56bc58e42d6661e65ee13 (linux-omap) is not enough, I
also need to set the OMAP3_HAS_IVA_REGS for the 3430 as well.

Inlined patch:

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 4072fbd..45d3eb4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -244,7 +244,7 @@ void __init omap3xxx_check_features(void)
        if (cpu_is_omap3630())
                omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS;
        if (cpu_is_omap3430() || cpu_is_omap3630())
-               omap_features |= OMAP3_HAS_IO_WAKEUP;
+               omap_features |= OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_IVA_REGS;
        if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
            omap_rev() == OMAP3430_REV_ES3_1_2)
                omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;

Here is with I see with this patch:
/debug/pm_debug # echo mem > /sys/power/state
[ 1058.657928] PM: Syncing filesystems ... done.
[ 1058.669616] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 1058.703094] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[ 1058.734252] Suspending console(s) (use no_console_suspend to debug)
[ 1058.921936] PM: suspend of devices complete after 161.285 msecs
[ 1058.938995] PM: late suspend of devices complete after 16.936 msecs
[ 1058.963134] PM: noirq suspend of devices complete after 23.986 msecs
[ 1060.013336] Successfully put all powerdomains to target state
[ 1060.025726] PM: noirq resume of devices complete after 11.810 msecs
[ 1060.042480] PM: early resume of devices complete after 10.437 msecs
[ 1060.481353] PM: resume of devices complete after 438.415 msecs
[ 1060.547912] Restarting tasks ... done.

/debug/pm_debug # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:710,INA:0,ON:711,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:710,INA:0,ON:711,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm->usbhost_pwrdm (1)
sgx_clkdm->sgx_pwrdm (0)
per_clkdm->per_pwrdm (18)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (1)
d2d_clkdm->core_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
core_l4_clkdm->core_pwrdm (24)
core_l3_clkdm->core_pwrdm (4)
neon_clkdm->neon_pwrdm (0)

I see that the usbhost domain is still not hitting retention but for
some reason it is not being complained about in suspend messages.

I am running omap2plus_defconfig with CPUFREQ and CPUIDLE enabled, USB disabled.

- Juha

On Wed, Jul 18, 2012 at 10:26 AM, Mark A. Greer <mgreer@animalcreek.com> wrote:
>
> On Wed, Jul 18, 2012 at 11:06:34AM +0100, Joe Woodward wrote:
> > From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> > > How does this look?
>
> > > Subject: [PATCH] ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature
> > >
> > > It appears that the am3703 and possibly the am3715 SoCs
> > > have an active IVA subsystem even though the CONTROL_IDCODE
> > > register indicates that they don't.  From experimentation,
> > > it seems that the IVA still requires some registers to be
> > > initialized even though we don't want it fully functional.
> > >
> > > To accomplish this, add a new feature (OMAP3_HAS_IVA_REGS)
> > > that indicates that the IVA should be initialized but not
> > > really used.
> > >
> > > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> > > ---
>
> > Tested on a GUMSTIX Overo AirSTORM (AM3703-based), and that fixes the problem for me, thanks!
>
> Great!  Thanks for testing, Joe.
>
> Paul, Kevin, any comments?
> --
> 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




--
Duck tape is like the force, it has a light side and a dark side and
it holds the universe together.

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Mark A. Greer]

On Thu, Jul 26, 2012 at 02:09:33PM -0700, Juha Kuikka wrote:

Hi Juha.

> A thousand apologizes for double posting, some html sneaked into the
> first email and it got dropped by the list server.
> 
> I am running on a gumstix with OMAP 3503 on it (name escapes me at the
> moment) and it has the same issue.

Okay, I didn't know if the 3503 would have that issue or not.

> Just applying Mark's patch on top of
> 55936cdfaaf11ac352b56bc58e42d6661e65ee13 (linux-omap) is not enough, I
> also need to set the OMAP3_HAS_IVA_REGS for the 3430 as well.
> 
> Inlined patch:
> 
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 4072fbd..45d3eb4 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -244,7 +244,7 @@ void __init omap3xxx_check_features(void)
>         if (cpu_is_omap3630())
>                 omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS;
>         if (cpu_is_omap3430() || cpu_is_omap3630())
> -               omap_features |= OMAP3_HAS_IO_WAKEUP;
> +               omap_features |= OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_IVA_REGS;
>         if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
>             omap_rev() == OMAP3430_REV_ES3_1_2)
>                 omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;

Thank you.

> Here is with I see with this patch:
> /debug/pm_debug # echo mem > /sys/power/state
> [ 1058.657928] PM: Syncing filesystems ... done.
> [ 1058.669616] Freezing user space processes ... (elapsed 0.02 seconds) done.
> [ 1058.703094] Freezing remaining freezable tasks ... (elapsed 0.02
> seconds) done.
> [ 1058.734252] Suspending console(s) (use no_console_suspend to debug)
> [ 1058.921936] PM: suspend of devices complete after 161.285 msecs
> [ 1058.938995] PM: late suspend of devices complete after 16.936 msecs
> [ 1058.963134] PM: noirq suspend of devices complete after 23.986 msecs
> [ 1060.013336] Successfully put all powerdomains to target state
> [ 1060.025726] PM: noirq resume of devices complete after 11.810 msecs
> [ 1060.042480] PM: early resume of devices complete after 10.437 msecs
> [ 1060.481353] PM: resume of devices complete after 438.415 msecs
> [ 1060.547912] Restarting tasks ... done.
> 
> /debug/pm_debug # cat /debug/pm_debug/count
> usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> core_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
> per_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> neon_pwrdm (ON),OFF:0,RET:710,INA:0,ON:711,RET-LOGIC-OFF:0
> mpu_pwrdm (ON),OFF:0,RET:710,INA:0,ON:711,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
> usbhost_clkdm->usbhost_pwrdm (1)
> sgx_clkdm->sgx_pwrdm (0)
> per_clkdm->per_pwrdm (18)
> cam_clkdm->cam_pwrdm (0)
> dss_clkdm->dss_pwrdm (1)
> d2d_clkdm->core_pwrdm (0)
> iva2_clkdm->iva2_pwrdm (0)
> mpu_clkdm->mpu_pwrdm (0)
> core_l4_clkdm->core_pwrdm (24)
> core_l3_clkdm->core_pwrdm (4)
> neon_clkdm->neon_pwrdm (0)
> 
> I see that the usbhost domain is still not hitting retention but for
> some reason it is not being complained about in suspend messages.

This may be part of what Kevin Hilman, Keshava Munegowda, et. al.,
have been talking about,

	http://www.spinics.net/lists/linux-omap/msg70743.html

Mark

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Mark A. Greer]

On Thu, Jul 26, 2012 at 04:06:30PM -0700, Mark A. Greer wrote:
> On Thu, Jul 26, 2012 at 02:09:33PM -0700, Juha Kuikka wrote:

> > Just applying Mark's patch on top of
> > 55936cdfaaf11ac352b56bc58e42d6661e65ee13 (linux-omap) is not enough, I
> > also need to set the OMAP3_HAS_IVA_REGS for the 3430 as well.
> > 
> > Inlined patch:
> > 
> > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > index 4072fbd..45d3eb4 100644
> > --- a/arch/arm/mach-omap2/id.c
> > +++ b/arch/arm/mach-omap2/id.c
> > @@ -244,7 +244,7 @@ void __init omap3xxx_check_features(void)
> >         if (cpu_is_omap3630())
> >                 omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS;
> >         if (cpu_is_omap3430() || cpu_is_omap3630())
> > -               omap_features |= OMAP3_HAS_IO_WAKEUP;
> > +               omap_features |= OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_IVA_REGS;
> >         if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
> >             omap_rev() == OMAP3430_REV_ES3_1_2)
> >                 omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
> 
> Thank you.

I meant to add, "Please make a formal patch for review so you can
get credit for your work."

Mark

Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Kevin Hilman]

"Joe Woodward" <jw@terrafix.co.uk> writes:

> ...snip...
>> > Hmm, interesting, I don't see this on my 3730-based Over FireSTORM.
>> >
>> > But, after "converting" mine into an AirStorm[1], I see the same
>> errors
>> > as you're seeing.  We're obviously doing something wrong when IVA
>> and/or
>> > SGX are not present, so I will look into it.
>> 
>> With the hack below on top of my pm branch, can you try to
>> suspend/resume on your AirSTORM?
>> 
>> You'll get a bunch of noise from the clockdomain code becasue of the
>> missing power domains, but you can ignore them.  
>> 
>> I'm hoping this will fix your issue.  Obviously, this hack is not a
>> real
>> fix but just a test to see if the problem is where I think it is.  If
>> so, then I know the right solution and it's been discussed before but
>> never been a priority (at least for me) to fix.
>> 
>> Basically, we still need to fix up the registration of certain hwmods
>> and powerdomains based on whether or not certain IPs exist or not.  We
>> currently are rather blindly registering the hwmods for IVA, GFX etc.
>> 
>> Kevin
>> 
>
> After applying the patch (and also your GPIO fix for the ads7846).
>
> As you said, when booting lots of warnings are spat out:
>
> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: at arch/arm/mach-omap2/clockdomain.c:237 _resolve_clkdm_deps.clone.0+0x98/0x108()
> [    0.000000] Modules linked in:
> [    0.000000]
> [    0.000000] [<c001b75c>] (unwind_backtrace+0x0/0xf0) from [<c0041788>] (warn_slowpath_common+0x4c/0x64)
> [    0.000000] [<c0041788>] (warn_slowpath_common+0x4c/0x64) from [<c0041834>] (warn_slowpath_fmt+0x30/0x40)
> [    0.000000] [<c0041834>] (warn_slowpath_fmt+0x30/0x40) from [<c00321a0>] (_resolve_clkdm_deps.clone.0+0x98/0x108)
> [    0.000000] [<c00321a0>] (_resolve_clkdm_deps.clone.0+0x98/0x108) from [<c0032bb8>] (clkdm_complete_init+0x3c/0xa0)
> [    0.000000] [<c0032bb8>] (clkdm_complete_init+0x3c/0xa0) from [<c06d2458>] (omap3_init_early+0x20/0x30)
> [    0.000000] [<c06d2458>] (omap3_init_early+0x20/0x30) from [<c06ce1a8>] (setup_arch+0x814/0x934)
> [    0.000000] [<c06ce1a8>] (setup_arch+0x814/0x934) from [<c06ca584>] (start_kernel+0x88/0x300)
> [    0.000000] [<c06ca584>] (start_kernel+0x88/0x300) from [<80008044>] (0x80008044)
> [    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
>
> And now when suspending I get:
>
> # echo mem > /sys/power/state
> [   78.174713] PM: Syncing filesystems ... done.
> [   78.190582] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [   78.216430] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
> [   78.247558] Suspending console(s) (use no_console_suspend to debug)
> [   78.379241] PM: suspend of devices complete after 120.605 msecs
> [   78.382934] PM: late suspend of devices complete after 3.692 msecs
> [   78.388671] PM: noirq suspend of devices complete after 5.706 msecs
> [   78.388732] Disabling non-boot CPUs ...
> [  107.219818] Powerdomain (core_pwrdm) didn't enter target state 1
> [  107.219818] Could not enter target state in pm_suspend
> [  107.222808] PM: noirq resume of devices complete after 2.838 msecs
> [  107.226684] PM: early resume of devices complete after 2.380 msecs
> [  107.592620] mmc1: error -110 during resume (card was removed?)
> [  107.602752] PM: resume of devices complete after 375.946 msecs
> [  107.667449] Restarting tasks ... done.
> sh: write error: Operation not permitted
>
> So most of the warnings have gone, but core still fails to enter the target state.
>
> This is sitll using the omap2plus_defconfig with:
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
>
> CONFIG_DMADEVICES=y
> CONFIG_DMA_OMAP=y
>
> CONFIG_SQUASHFS=y
>
> All running from RAM-based RFS.

OK, if you're using a RAM-based rootfs, do you need DMA engine?  Can you
disable that for now?  I don't think it's related, but just want to rule
it out.

Also, (I'm shooting in the dark now), can you try a couple more things
with the hack that I sent, and send me the *full* console output of a
boot and a suspend/resume attemp:

1) use my hack as is
2) use my hack but only comment out IVA
3) use my hack but only comment out SGX

Thanks,

Kevin