Re: new PM branch available

[Kevin Hilman <khilman@deeprootsystems.com>]

"Peter 'p2' De Schrijver" <peter.de-schrijver@nokia.com> writes:

> Hi Kevin,
>
>> Hi Peter,
>> 
>> "Peter 'p2' De Schrijver" <peter.de-schrijver@nokia.com> writes:
>> 
>> 
>> A first guess: this sounds like CONFIG_OMAP_RESET_CLOCKS=y is missing
>> from your .config.
>> 
>> The MPU/NEON going active but not RET is an indication to me that some
>> fclk is active so that the fclk check in omap3_can_sleep() fails, so a
>> WFI is never attempted.  That's shy
>> 
>
> Ok. I did enable CONFIG_OMAP_RESET_CLOCKS. But with your config file
> only PER and CORE did not go to retention. One difference is that I did
> not enable smartreflex, but as B5 (and B4) are using OMAP3s without
> proper efuse values, smartreflex shouldn't matter I assume ?
>
> I upgrade my u-boot to the latest version, and then PER went to
> retention as well. 

Did you happen to notice what was keeping PER out of retention before
the u-boot upgrade?  Looks like we might still need some init-time
reset code to compensate for bootloaders.

> The only way to get core to retention was to force idle USBOTG and
> disable the USBOTG driver.

This is the same issue on 3430SDP.  The PM branch code does the
force-idle, and I usually have USB built as modules and not loaded
when I do the tests.

I'm guessing this is a result of u-boot configuring/using USB.

> Dynamic retention seems to work only once the system has been in static
> retention once.
>
> Static off mode seems to work, but resume from off kills the UART. The
> system seems to run though, at least LED0 flickers as usual when the
> system runs. Sometimes it hangs and I have seen one reboot.

I have noticed this as well.

I haven't looked at all at the T2 scripts being used on Beagle.  Do
you think some of these issues may be related to those scripts?

Kevin

>> 
>> > Which rootfs are you using, I'm using debian, so maybe something
>> > keeps the CPU busy. Are you using NAND or MMC to store your rootfs ?
>> 
>> I'm using rootfs on MMC and have tested with busybox-only, debian and
>> OE rootfs.  With debian and OE, I usually boot a minimal rootfs,
>> before a full userland comes up.  With debian, I changed my
>> /etc/init.d/rcS to start initlevel 1 instead of 'S'.
>> 
>
> Ok. I tried with both the small OE ramdisk image and rather minimal debian 
> install. I didn't see a difference in behaviour between both.
>
>> > And which u-boot are you using ?
>> 
>> I'm using the u-boot from Steve Sakoman's tree[1].  That helped a lot
>> in my initial Beagle testing, but I think the kernel should reset the
>> IVA and D2D now which is the domains that I was having problems with
>> before, so I think that the out of the box u-boot should work fine.
>> 
>
> I upgraded to this u-boot and it resolved at least one issue. 
>
> Cheers,
>
> Peter.
>
> -- 
> goa is a state of mind