"Peter 'p2' De Schrijver" <peter.de-schrijver@xxxxxxxxx> writes: > Hi Kevin, > >> Hi Peter, >> >> "Peter 'p2' De Schrijver" <peter.de-schrijver@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
