All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: "Menon, Nishanth" <nm@ti.com>
Cc: t-kristo@ti.com, Tony Lindgren <tony@atomide.com>,
	paul@pwsan.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support
Date: Thu, 16 Feb 2012 09:35:04 -0800	[thread overview]
Message-ID: <87y5s2hebb.fsf@ti.com> (raw)
In-Reply-To: <CAOMWX4cg4mfBQGcHLodjFaVY0vVGnKJKvsa9ngMLO-0Ca7gBTQ@mail.gmail.com> (Nishanth Menon's message of "Thu, 16 Feb 2012 11:06:38 -0600")

"Menon, Nishanth" <nm@ti.com> writes:

> On Wed, Feb 15, 2012 at 09:20, Kevin Hilman <khilman@ti.com> wrote:
>> 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.
>>
> Something like this perhaps?
> https://github.com/nmenon/linux-omap-ti-pm/commit/3cd1994fc0df9a8e3e0be74ec3f3add3ff3aef95

Yes, although that is targetted pretty narrowly at suspend and only PRM
registers.

Do you then use omapconf to display the results?

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: Thu, 16 Feb 2012 09:35:04 -0800	[thread overview]
Message-ID: <87y5s2hebb.fsf@ti.com> (raw)
In-Reply-To: <CAOMWX4cg4mfBQGcHLodjFaVY0vVGnKJKvsa9ngMLO-0Ca7gBTQ@mail.gmail.com> (Nishanth Menon's message of "Thu, 16 Feb 2012 11:06:38 -0600")

"Menon, Nishanth" <nm@ti.com> writes:

> On Wed, Feb 15, 2012 at 09:20, Kevin Hilman <khilman@ti.com> wrote:
>> 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.
>>
> Something like this perhaps?
> https://github.com/nmenon/linux-omap-ti-pm/commit/3cd1994fc0df9a8e3e0be74ec3f3add3ff3aef95

Yes, although that is targetted pretty narrowly at suspend and only PRM
registers.

Do you then use omapconf to display the results?

Kevin

  reply	other threads:[~2012-02-16 17:35 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
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 [this message]
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=87y5s2hebb.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nm@ti.com \
    --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.