public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Jean Pihet <jean.pihet@newoldbits.com>
Cc: cpufreq@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux@dominikbrodowski.net, linux-pm@lists.linux-foundation.org,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] cpupower: Add cpupower-idle-info manpage
Date: Sat, 17 Dec 2011 10:21:57 +0100	[thread overview]
Message-ID: <201112171021.58492.trenn@suse.de> (raw)
In-Reply-To: <CAORVsuVrm+dWGgs-taatnUMZsYvYg_tdx1=7ekWp0qM+25DorQ@mail.gmail.com>

On Friday 16 December 2011 17:18:37 Jean Pihet wrote:
> Hi Thomas,
> 
> On Fri, Dec 16, 2011 at 3:35 PM, Thomas Renninger <trenn@suse.de> wrote:
> > The last missing manpage for cpupower tools.
> Great!
> 
> > More info about other architecture's sleep state specialities would be great.
> I wonder if it is the right place for some arch specific information
> about the sleep states.
> 
> I propose to document this in a more generic doc file (e.g.
> Documentation/arm/OMAP/omap_pm) and link it from the manpage.
Duplicating info at different places increases needed maintenance.
Mabye above should be more about the kernel implementation details
and the manpage should more include the bits a typical user
wants to know?

> What do you think?
The POLL state is a bit confusing on X86 cpupower idle-info output.
Also on X86 the CPU may decide to use other states than the kernel
requested and the cpupower monitor tool should get used to see them.
This directly affects the output/usage of the tool and to understand it,
it should be documented in the manpage.

IMO it's not bad to have a somewhat bigger manpage here.
Especially on ARM, also the "ordinary" user wants to know
about how/whether the cpu power functionalities work as expected
without the need of looking at the kernel sources.

For now I could only try out cpupower on an ARM platform
with cpufreq support.
Would be great if someone could give cpupower idle-info
a try on such a machine.
Think of a typical user, not a kernel hacker and what he needs to
know to interpret and understand the output.
Maybe it's self-explanatory already, maybe the one or other arch
specific bit should get explained?

   Thomas

      reply	other threads:[~2011-12-17  9:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1324046154-64824-1-git-send-email-trenn@suse.de>
2011-12-16 14:35 ` [PATCH 1/4] cpupower: Add cpupower-idle-info manpage Thomas Renninger
2011-12-16 16:18   ` Jean Pihet
2011-12-17  9:21     ` Thomas Renninger [this message]

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=201112171021.58492.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=cpufreq@vger.kernel.org \
    --cc=jean.pihet@newoldbits.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=linux@dominikbrodowski.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox