Hi Grygorii, On 27 July 2018 at 03:23, Grygorii Strashko <grygorii.strashko@xxxxxx> wrote: > > > On 07/26/2018 07:51 AM, J, KEERTHY wrote: >> >> >> On 7/26/2018 1:45 PM, Baolin Wang wrote: >>> Hi Keerthy, >>> >>> On 26 July 2018 at 14:58, J, KEERTHY <j-keerthy@xxxxxx> wrote: >>>> >>>> >>>> On 7/26/2018 8:04 AM, Baolin Wang wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 26 July 2018 at 09:59, Baolin Wang <baolin.wang@xxxxxxxxxx> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 26 July 2018 at 06:01, Dave Gerlach <d-gerlach@xxxxxx> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> On 07/25/2018 08:10 AM, Keerthy wrote: >>>>>>>> >>>>>>>> Hi Baolin, >>>>>>>> >>>>>>>> commit 39232ed5a1793f67b11430c43ed8a9ed6e96c6eb >>>>>>>> Author: Baolin Wang <baolin.wang@xxxxxxxxxx> >>>>>>>> Date: Tue Jul 17 15:55:16 2018 +0800 >>>>>>>> >>>>>>>> time: Introduce one suspend clocksource to compensate the suspend >>>>>>>> time >>>>>>>> >>>>>>>> This patch seems to have broken suspend to memory on >>>>>>>> AM437x-gp-evm on >>>>>>>> linux-next. 4.18-rc6 works well linux-next has this broken on >>>>>>>> am437x-gp-evm and i could bisect to the above patch. >>>>>> >>>>>> >>>>>> Could you point out which clocksource (or clocksource driver) is used >>>>>> on AM437x-gp-evm? >>>>>> If you have one non-stop clocksource, maybe you have suspended it when >>>>>> system suepends, but we should not. >>>>>> I am not sure what is the problem with your AM437x-gp-evm board, but I >>>>>> will help to look at your clocksource driver to find the reason. >>>>> >>>>> >>>>> I did a little investigation, you will use "arm_global_timer" as the >>>>> clocksource for timekeeping, right? >>>>> But "arm_global_timer" is not a non-stop clocksource, so that means >>>>> you will not compensate the suspend time from non-stop clocksource. >>>>> Or you have another non-stop clocksource on this board that I missed? >>>>> (Sorry, I am not familiar with AM437x-gp-evm) >>>> >>>> >>>> Baolin, >>>> >>>> For AM437X we are using gptimer1 as clocksource which is in always-on >>> >>> OK, I found it in time-pistachio.c file. >>> >>>> domain. We do idle that during suspend and enable it back during resume. >>>> I tried removing suspend/resume hooks but that did not help either. >>> >>> I did not see the gptimer supplies suspend/resume interfaces, but it >>> supplies enable/disable interfaces. That means if the non-stop gptimer >>> is selected as the suspend clocksource (not the current clocksource >>> for timekeeping), it will be enabled when system suspends and disabled >>> when system resumes to save power. But if the non-stop gptimer is also >>> the current clocksource for timekeeping, it will not be disabled when >>> system resumes. >>> >>> So in your system gptimer1 is selected as the clocksource for >>> timekeeping or not? >> >> Baolin, >> >> Dug a bit more on this. Seems like one is high frequency clocksource >> gptimer1: >> >> clocksource: timer1: mask: 0xffffffff max_cycles: 0xffffffff, >> max_idle_ns: 79635851949 ns >> OMAP clocksource: timer1 at 24000000 Hz >> >> arch/arm/mach-omap2/timer.c >> >> And another is a low frequency 32k: >> >> clocksource: 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, >> max_idle_ns: 58327039986419 ns >> OMAP clocksource: 32k_counter at 32768 Hz >> >> drivers/clocksource/timer-ti-32k.c >> >> Boot log: https://pastebin.ubuntu.com/p/FyympH7kK5/ >> > > timer1 is used as clocksource > [ 0.383769] clocksource: Switched to clocksource timer1 > > If I'm not mistaken, on any TI OMAP platforms any clocksource devices can't be used > to account suspend time (even always-on) simply because system can spend Hours or > even Days in suspend, so only RTC timer can be used to inject suspend time on resume. > Relying on nostop clocksource timer would require periodic wake-up to avoid counters overflow - > which is not desired (and not sure if it even possible as wekeup time to console could be up to 10s, and > wakeup time to syscore_resume() also not always predictable). > > NONSTOP clocksource is used only for CPUIdle timekeeping purposes. > > KEERTHY, > Wouldn't it help if you remove CLOCK_SOURCE_SUSPEND_NONSTOP flag from ti_32k_timer? I saw the ti_32k_timer is one 32-bit timer with 32768Hz, that means it will overflow in 36 hours. So if the system can be suspended several days, yes, the compensation of the suspend time will be incorrect, but it will not crash the system. I am afraid the ti_32k_timer is not one always-on timer, it can not be selected one suspend clocksource to compensate the susoend time when system suspends. -- Baolin Wang Best Regards -- 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
