Hi!
> >
> > pr_info("My so important log message %lld\n",
> > ktime_get_real_seconds());
>
> Legacy (these prints have been in Android tree since 2013) for all our
> battery and power analysis tools are keyed off RTC format. There is some
> momentum, default should be epoch seconds/nanosec
On 07/19/2017 05:03 AM, Prarit Bhargava wrote:
On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
There was some discussion about making the clock source for dmesg time
stamps selectable, so you can use MONOTO
On 07/19/2017 08:28 AM, Thomas Gleixner wrote:
> On Wed, 19 Jul 2017, Prarit Bhargava wrote:
>> On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
>>> There is another option to remedy this and the dmesg tooling issues:
>>>
>>> Instead of switching the time stamps in dmesg to a different clock we mig
On Wed, 19 Jul 2017, Prarit Bhargava wrote:
> On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
> > There is another option to remedy this and the dmesg tooling issues:
> >
> > Instead of switching the time stamps in dmesg to a different clock we might
> > as well have an optional secondary timestamp
On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
> On Tue, 18 Jul 2017, Mark Salyzyn wrote:
>> On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
>>> There was some discussion about making the clock source for dmesg time
>>> stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
>>> patch
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
> On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
> > There was some discussion about making the clock source for dmesg time
> > stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
> > patches looked sensible, but there was some showstopper v
[TL;DR]
On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
Can we please fix the tools and not introduce that horror in the kernel?
IMHO, we can switch this patch to epoch.ns time; but the momentum on the
tools will end up with us internally patching it back to RTC format at
least until
we can ge
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
> On 07/18/2017 02:52 PM, Thomas Gleixner wrote:
> > Why on earth do you need to print that information in RTC format? What's
> > wrong with just doing:
> >
> >pr_info("My so important log message %lld\n",
> > ktime_get_real_seconds());
>
> Legacy
On 07/18/2017 02:52 PM, Thomas Gleixner wrote:
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
Go directly to the rtc for persistent wall clock time and print.
Useful if REALTIME is required to be logged in a low level power
management function or when clock activities are suspended. An
aid to permit
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
> Go directly to the rtc for persistent wall clock time and print.
> Useful if REALTIME is required to be logged in a low level power
> management function or when clock activities are suspended. An
> aid to permit user space alignment of kernel activities
10 matches
Mail list logo
