Hi Dave,
On Wed, 5 Oct 2011, Dave Hylands wrote:
> On Wed, Oct 5, 2011 at 11:09 AM, Paul Walmsley <paul@xxxxxxxxx> wrote:
> > On Wed, 5 Oct 2011, Dave Hylands wrote:
> >
> >> I have an older overo board, which has an OMAP3503
> >>
> >> U-booot reports:
> >> OMAP3503-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
> >>
> >> In order to get the 2.6.39 kernel to boot, I had to make 2 modifications:
> >>
> >> In arch/arm/mach-omap2/pm34xx.c, in the omap_sram_idle routine I had
> >> to put an #if 0 around:
> >>
> >> #if 0
> >> if (omap3_has_io_wakeup() &&
> >> (per_next_state < PWRDM_POWER_ON ||
> >> core_next_state < PWRDM_POWER_ON)) {
> >> omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK,
> >> WKUP_MOD, PM_WKEN);
> >> omap3_enable_io_chain();
> >> }
> >> #endif
> >>
> >> or I would get continuous
> >>
> >> Wake up daisy chain activation failed.
> >>
> >> messages on the console.
> >
> > Looking at the 2.6.39 kernel sources, those messages are coming from
> > mach-omap2/pm34xx.c:omap3_enable_io_chain(). That means that something is
> > seriously wrong since that code should only be executing on ES3.1 chips
> > and higher.
> >
> > Could you put something similar to a
> >
> > pr_err("** omap_rev is %08x\n", omap_rev());
> >
> > in your pm34xx.c right above the #if 0 that you added and let us know what
> > it says?
>
> It reports
>
> ** omap_rev is 35030234
Thanks. This particular problem (for the 35xx series) was fixed by commit
1f1b0353aa3ba5dfc35641452484ea4158ee3c9c ("OMAP3: id: remove
identification codes that only correspond to marketing names"), which
should go upstream during the 3.2 merge window.
For your local kernel, since you seem okay with modifying it, I'd simply
suggest commenting out the call to omap3_enable_io_chain(). You'll
probably want to leave in the line that sets the EN_IO bit.
But Steve is correct that these types of unbounded range comparisons
shouldn't be done with omap_rev(), at least not without further
restrictions as to the SoC type under consideration. Most of these seem
to be located in arch/arm/mach-omap2/pm34xx.c, so what's needed is a patch
to clean these up that can also go into the stable kernel release series.
- Paul
