From: Kevin Hilman <khilman@ti.com>
To: t-kristo@ti.com
Cc: Tony Lindgren <tony@atomide.com>,
linux-omap@vger.kernel.org, paul@pwsan.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support
Date: Wed, 15 Feb 2012 07:20:20 -0800 [thread overview]
Message-ID: <874nus5djf.fsf@ti.com> (raw)
In-Reply-To: <1329294866.4102.343.camel@sokoban> (Tero Kristo's message of "Wed, 15 Feb 2012 10:34:26 +0200")
Tero Kristo <t-kristo@ti.com> writes:
> On Tue, 2012-02-14 at 15:52 -0800, Tony Lindgren wrote:
>> * Kevin Hilman <khilman@ti.com> [120214 14:28]:
>> > Tony Lindgren <tony@atomide.com> writes:
>> >
>> > > * Tero Kristo <t-kristo@ti.com> [120214 08:19]:
>> > >> Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
>> > >> their own file, 'usecount'. This file shows the usecounts for every
>> > >> active domain and their children recursively. 'count' file now only
>> > >> shows power state counts for powerdomains.
>> > >>
>> > >> This patch also provices a way to do printk dumps from kernel code,
>> > >> by calling the pm_dbg_dump_X functions. The plan is to call these
>> > >> functions once an error condition is detected, e.g. failed suspend.
>> > >
>> > > Why don't you replace this all with a userspace tool that deciphers
>> > > the registers for you?
>> >
>> > This patch isn't deciphering registers, it's just dumping usecounts, and
>> > I think that is extremely useful to have in debugfs.
>> >
>> > I've already removed all the register dumping from the kernel in the
>> > hopes that someone will write a userspace tool for that.
>>
>> OK good to hear you're already considering it.
>
> Yes, register dumps are gone, and I am actually one of the persons who
> is missing it.
>
> I think there should still be some capability to get register snapshots
> from certain points during kernel execution, this is useful for
> debugging purposes. I don't know if it would be possible to do a
> call_usermodehelper() or something from kernel space just before wfi to
> read all (or part of) the PRCM registers, store them somewhere, and then
> decipher this data later with another tool. Any comments to this?
You should look into the omapconf tool (TI internal only currently)
This tool already has the ability to use /dev/mem to read/decipher OMAP
PM related registers.
IMO, the one thing we're still missing is the ability to take register
snapshots (like immediately before and after WFI) and somehow feed those
to omapconf for deciphering.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support
Date: Wed, 15 Feb 2012 07:20:20 -0800 [thread overview]
Message-ID: <874nus5djf.fsf@ti.com> (raw)
In-Reply-To: <1329294866.4102.343.camel@sokoban> (Tero Kristo's message of "Wed, 15 Feb 2012 10:34:26 +0200")
Tero Kristo <t-kristo@ti.com> writes:
> On Tue, 2012-02-14 at 15:52 -0800, Tony Lindgren wrote:
>> * Kevin Hilman <khilman@ti.com> [120214 14:28]:
>> > Tony Lindgren <tony@atomide.com> writes:
>> >
>> > > * Tero Kristo <t-kristo@ti.com> [120214 08:19]:
>> > >> Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
>> > >> their own file, 'usecount'. This file shows the usecounts for every
>> > >> active domain and their children recursively. 'count' file now only
>> > >> shows power state counts for powerdomains.
>> > >>
>> > >> This patch also provices a way to do printk dumps from kernel code,
>> > >> by calling the pm_dbg_dump_X functions. The plan is to call these
>> > >> functions once an error condition is detected, e.g. failed suspend.
>> > >
>> > > Why don't you replace this all with a userspace tool that deciphers
>> > > the registers for you?
>> >
>> > This patch isn't deciphering registers, it's just dumping usecounts, and
>> > I think that is extremely useful to have in debugfs.
>> >
>> > I've already removed all the register dumping from the kernel in the
>> > hopes that someone will write a userspace tool for that.
>>
>> OK good to hear you're already considering it.
>
> Yes, register dumps are gone, and I am actually one of the persons who
> is missing it.
>
> I think there should still be some capability to get register snapshots
> from certain points during kernel execution, this is useful for
> debugging purposes. I don't know if it would be possible to do a
> call_usermodehelper() or something from kernel space just before wfi to
> read all (or part of) the PRCM registers, store them somewhere, and then
> decipher this data later with another tool. Any comments to this?
You should look into the omapconf tool (TI internal only currently)
This tool already has the ability to use /dev/mem to read/decipher OMAP
PM related registers.
IMO, the one thing we're still missing is the ability to take register
snapshots (like immediately before and after WFI) and somehow feed those
to omapconf for deciphering.
Kevin
next prev parent reply other threads:[~2012-02-15 15:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-14 16:36 [PATCH 0/6] arm: omap: clk/clkdm/pwrdm/voltdm changes to usecounting Tero Kristo
2012-02-14 16:36 ` Tero Kristo
2012-02-14 16:36 ` [PATCH 1/6] arm: omap: clk: add support for omap_clk_for_each Tero Kristo
2012-02-14 16:36 ` Tero Kristo
2012-02-14 16:36 ` [PATCH 2/6] arm: omap3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking Tero Kristo
2012-02-14 16:36 ` Tero Kristo
2012-02-14 16:36 ` [PATCH 3/6] arm: omap3+: voltage: add support for voltagedomain usecounts Tero Kristo
2012-02-14 16:36 ` Tero Kristo
2012-02-14 16:36 ` [PATCH 4/6] arm: omap3: add manual control for mpu_iva voltdm usecounting Tero Kristo
2012-02-14 16:36 ` Tero Kristo
2012-02-14 19:35 ` Kevin Hilman
2012-02-14 19:35 ` Kevin Hilman
2012-02-15 8:16 ` Tero Kristo
2012-02-15 8:16 ` Tero Kristo
2012-02-15 19:29 ` Kevin Hilman
2012-02-15 19:29 ` Kevin Hilman
2012-02-14 16:36 ` [PATCH 5/6] arm: omap3: set autoidle flags for a few clocks Tero Kristo
2012-02-14 16:36 ` Tero Kristo
2012-02-14 16:36 ` [PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support Tero Kristo
2012-02-14 16:36 ` Tero Kristo
2012-02-14 20:27 ` Tony Lindgren
2012-02-14 20:27 ` Tony Lindgren
2012-02-14 22:59 ` Kevin Hilman
2012-02-14 22:59 ` Kevin Hilman
2012-02-14 23:52 ` Tony Lindgren
2012-02-14 23:52 ` Tony Lindgren
2012-02-15 8:34 ` Tero Kristo
2012-02-15 8:34 ` Tero Kristo
2012-02-15 15:20 ` Kevin Hilman [this message]
2012-02-15 15:20 ` Kevin Hilman
2012-02-16 17:06 ` Menon, Nishanth
2012-02-16 17:06 ` Menon, Nishanth
2012-02-16 17:35 ` Kevin Hilman
2012-02-16 17:35 ` Kevin Hilman
2012-02-16 18:14 ` Menon, Nishanth
2012-02-16 18:14 ` Menon, Nishanth
2012-02-14 20:02 ` [PATCH 0/6] arm: omap: clk/clkdm/pwrdm/voltdm changes to usecounting Kevin Hilman
2012-02-14 20:02 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874nus5djf.fsf@ti.com \
--to=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=t-kristo@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.