On 16 May 2018 at 10:20, Baolin Wang <baolin.wang@xxxxxxxxxx> wrote: > Hi Daniel, > > On 15 May 2018 at 18:27, Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> wrote: >> On Mon, May 14, 2018 at 04:55:26PM +0800, Baolin Wang wrote: >>> Hi, >>> >>> We will meet below issues when compensating the suspend time for the timekeeping. >>> >>> 1. We have too many different ways of dealing with persistent timekeeping >>> across architectures, so it is hard for one driver to compatable with different >>> architectures. >>> >>> 2. On some platforms (such as Spreadtrum platform), we registered the high >>> resolution timer as one clocksource to update the OS time, but the high >>> resolution timer will be stopped in suspend state. So we use another one >>> always-on timer (but low resolution) to calculate the suspend time to >>> compensate the OS time. Though we can register the always-on timer as one >>> clocksource, we need re-calculate the mult/shift with one larger conversion >>> range to calculate the suspend time and need update the clock in case of >>> running over the always-on timer. >> >> First, can you elaborate what you mean by 'suspend state' ? On which power > > What I mean is the high resolution timer will be stopped when the > system goes into suspend state. > >> domain the clocksource belongs to? > > On Spreadtrum platform, It belongs to one power domain named > "APCPU_TOP", that will be power down when the system goes into suspend > state. Sorry, I made a mistake here. Our high resolution timer is on one always-on power domain, but it's clock will be shut down when the system goes into suspend. -- 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
