[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190930095354.08fa0d80@gandalf.local.home>
Date: Mon, 30 Sep 2019 09:53:54 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Sodagudi Prasad <psodagud@...eaurora.org>
Cc: pmladek@...e.com, sergey.senozhatsky@...il.com,
linux-kernel@...r.kernel.org
Subject: Re: Time stamp value in printk records
On Mon, 30 Sep 2019 06:33:42 -0700
Sodagudi Prasad <psodagud@...eaurora.org> wrote:
> Hi All,
>
> From Qualcomm side, we would like to check with upstream team about
> adding Raw time stamp value to printk records. On Qualcomm soc, there
> are various DSPs subsystems are there - for example audio, video and
> modem DSPs.
> Adding raw timer value(along with sched_clock()) in the printk record
> helps in the following use cases –
> 1) To find out which subsystem crashed first - Whether application
> processor crashed first or DSP subsystem?
> 2) If there are any system stability issues on the DSP side, what is the
> activity on the APPS processor side during that time?
>
> Initially during the device boot up, printk shed_clock value can be
> matched with timer raw value used on the dsp subsystem, but after APPS
> processor suspends several times, we don’t have way to correlate the
> time stamp value on the DSP and APPS processor. All timers(both apps
> processor timer and dsp timers) are derived from globally always on
> timer on Qualcomm soc, So keeping global timer raw values in printk
> records and dsp logs help to correlate the activity of all the
> processors in SoC.
>
> It would be great if upstream team adds common solution this problem if
> all soc vendors would get benefit by adding raw timer value to printk
>
Hi Prasad,
If you or someone you know would like to present patches for exactly
what you would like to see, that would go a long way.
-- Steve
Powered by blists - more mailing lists