On Fri, 6 Jul 2018, Mukesh Ojha wrote:
> Hi Thomas,
>
> Could you raise a formal patch on this as you are the author now?
I'm short of cycles ATM. Feel free to pick it up and write a nice
changelog. Just add
Originally-by: Thomas Gleixner
Thanks,
tglx
On Fri, 6 Jul 2018, Mukesh Ojha wrote:
> Hi Thomas,
>
> Could you raise a formal patch on this as you are the author now?
I'm short of cycles ATM. Feel free to pick it up and write a nice
changelog. Just add
Originally-by: Thomas Gleixner
Thanks,
tglx
Hi Thomas,
Could you raise a formal patch on this as you are the author now?
Thanks,
Mukesh
On 6/25/2018 8:34 PM, Thomas Gleixner wrote:
On Mon, 25 Jun 2018, Mukesh Ojha wrote:
On 6/23/2018 2:57 AM, Thomas Gleixner wrote:
@@ -1671,7 +1685,6 @@ void timekeeping_resume(void)
struct
Hi Thomas,
Could you raise a formal patch on this as you are the author now?
Thanks,
Mukesh
On 6/25/2018 8:34 PM, Thomas Gleixner wrote:
On Mon, 25 Jun 2018, Mukesh Ojha wrote:
On 6/23/2018 2:57 AM, Thomas Gleixner wrote:
@@ -1671,7 +1685,6 @@ void timekeeping_resume(void)
struct
On Mon, 25 Jun 2018, Mukesh Ojha wrote:
> On 6/23/2018 2:57 AM, Thomas Gleixner wrote:
> > @@ -1671,7 +1685,6 @@ void timekeeping_resume(void)
> > struct timespec64 ts_new, ts_delta;
> > u64 cycle_now;
> > - sleeptime_injected = false;
> > read_persistent_clock64(_new);
> >
On Mon, 25 Jun 2018, Mukesh Ojha wrote:
> On 6/23/2018 2:57 AM, Thomas Gleixner wrote:
> > @@ -1671,7 +1685,6 @@ void timekeeping_resume(void)
> > struct timespec64 ts_new, ts_delta;
> > u64 cycle_now;
> > - sleeptime_injected = false;
> > read_persistent_clock64(_new);
> >
Hi Thomas,
Thanks you very much for your time and reply.
On 6/23/2018 2:57 AM, Thomas Gleixner wrote:
On Wed, 30 May 2018, Mukesh Ojha wrote:
Currently, for both non-stop clocksource and persistent clock
there is a corner case, when a driver failed to go suspend mode.
rtc_resume() injects
Hi Thomas,
Thanks you very much for your time and reply.
On 6/23/2018 2:57 AM, Thomas Gleixner wrote:
On Wed, 30 May 2018, Mukesh Ojha wrote:
Currently, for both non-stop clocksource and persistent clock
there is a corner case, when a driver failed to go suspend mode.
rtc_resume() injects
On Wed, 30 May 2018, Mukesh Ojha wrote:
> Currently, for both non-stop clocksource and persistent clock
> there is a corner case, when a driver failed to go suspend mode.
> rtc_resume() injects the sleeptime as timekeeping_rtc_skipresume()
> returned 'false'(sleeptime_injected=false) due to which
On Wed, 30 May 2018, Mukesh Ojha wrote:
> Currently, for both non-stop clocksource and persistent clock
> there is a corner case, when a driver failed to go suspend mode.
> rtc_resume() injects the sleeptime as timekeeping_rtc_skipresume()
> returned 'false'(sleeptime_injected=false) due to which
Any input on this ?
Thanks,
Mukesh
On 5/30/2018 5:14 PM, Mukesh Ojha wrote:
Currently, for both non-stop clocksource and persistent clock
there is a corner case, when a driver failed to go suspend mode.
rtc_resume() injects the sleeptime as timekeeping_rtc_skipresume()
returned
Any input on this ?
Thanks,
Mukesh
On 5/30/2018 5:14 PM, Mukesh Ojha wrote:
Currently, for both non-stop clocksource and persistent clock
there is a corner case, when a driver failed to go suspend mode.
rtc_resume() injects the sleeptime as timekeeping_rtc_skipresume()
returned
Currently, for both non-stop clocksource and persistent clock
there is a corner case, when a driver failed to go suspend mode.
rtc_resume() injects the sleeptime as timekeeping_rtc_skipresume()
returned 'false'(sleeptime_injected=false) due to which we can
see mismatch in timestamps between system
Currently, for both non-stop clocksource and persistent clock
there is a corner case, when a driver failed to go suspend mode.
rtc_resume() injects the sleeptime as timekeeping_rtc_skipresume()
returned 'false'(sleeptime_injected=false) due to which we can
see mismatch in timestamps between system
14 matches
Mail list logo
