On Fri, Jul 20, 2012 at 10:42:53, Nayak, Rajendra wrote: > On Friday 20 July 2012 10:31 AM, Bedia, Vaibhav wrote: > > On Fri, Jul 20, 2012 at 10:09:43, Nayak, Rajendra wrote: > >> On Thursday 19 July 2012 05:38 PM, Vaibhav Bedia wrote: > >>> As per the comment in omap2_common_late_init() looks like the > >>> original intent of the DT check was to treat only the PMIC > >>> and SR initialization differently. Recent changes to consolidate > >>> the suspend-resume code across OMAP3/4 resulted into the > >>> registration of suspend ops also being dependent on the check > >>> for DT blob. Since the suspend-resume operation should not > >>> really be dependent on the usage of DT remove this dependency > >>> by wrapping the PMIC and SR init under the DT check. > >> > >> So I am guessing you also tested suspend/resume on your hardware > >> with this patch, when booting with a DT blob, and it passed. > >> > > > > I am getting there ;) > > > > I am in the process of getting a real suspend/resume functional. As part > > of this I was just flow flushing the whole suspend process in the mainline > > kernel by putting in a dummy implementation for the .enter op and found that > > this change was needed. > > Ok, good to know you are working on this. It might then make sense for > for you to also include this patch as part of that series? > It doesn't make much sense to register suspend ops which then break > suspend isn't it? Btw, whats the behavior on current mainline with > just this patch. Does it hang/crash or just prevent the system from > doing down? > Ok. I can keep this patch as part of the suspend-resume support for AM33XX. With just this patch on top of the tree being maintained by Vaibhav Hiremath [1] I found a couple of issues that I am yet to fully root-cause. 1. The PM_SUSPEND_PREPARE handler in drivers/mmc/core/core.c never returns unless the MMC_UNSAFE_RESUME config option is selected. This might be due to the suspend and resume in mmc_bus_ops being NULL in the case where the config option is not set. 2. The suspend process hangs somewhere in the .suspend_noirq callback for the UART being used as the console when no_console_suspend is passed. I am yet to check the behavior on an OMAP3 EVM so right now I am not sure whether these are AM33XX specific issues. If you have any pointers that will greatly help. Regards, Vaibhav B. [1] https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging -- 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
