[PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Santosh Shilimkar santosh.shilimkar at ti.com
Fri Mar 11 12:06:21 EST 2011


> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at ti.com]
> Sent: Friday, March 11, 2011 9:26 PM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; Rajendra Nayak; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and
> CPUilde support.
>
> Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
>
> [...]
>
> >> >
> >> > This series doesn't boot on ES1 (boot log below.)  Do we need
> to
> >> > totally prevent WFI on ES1?
> >> >
> > Nope. WFI is ok.
> > The ES1.0 boot issue on pm-core branch doesn't seems to
> > be related to this series. Without this series as well
> > OMAP4 ES1.0 is not booting for me. When I disable
> > CONFIG_PM + WATCHDOG fix, it booted ok. I will
> > git-bisect this later on pm-core branch.
> >
> >> > Also, if we want a CPUidle enabled kernel to boot on all
> silicon,
> >> > it will need a omap_rev() check during init to ensure it
> doesn't
> >> > override the default idle path.
> >> >
> > OMAP4 PM series already takes care of not overriding
> > the default idle path for ES1.0. The omap4_mpuss_init()
> > fails on ES1.0 and hence the CPUidle init is skipped in
> > that case.
> >
> > Just to further check, I pulled the latest omap-for-linus
> > branch and merged Paul's pull-request into it. Then
> > applied OMAP4 PM series and I got a boot crash, a different
> > one. This was again related to clock-domain initialization
> > and static deps. I fixed this issue by avoiding omap4_pm_init()
> > code running on ES1.0. With this boot on ES1.0 works fine now
> > with OMAP4 PM series.
>
> Thanks for finding this.  I just tested your v3 branch together with
> my pm-core and it's now booting fine on ES1.
>
Thanks Kevin for test.

Regards,
Santosh



More information about the linux-arm-kernel mailing list