lkml.org 
[lkml]   [2013]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][Update 2][PATCH 2/4] ACPI / PM: Expose reference count values of ACPI power resources
On Mon, Jan 21, 2013 at 11:35:51PM +0100, Rafael J. Wysocki wrote:
> On Monday, January 21, 2013 12:53:57 PM Greg Kroah-Hartman wrote:
> > On Mon, Jan 21, 2013 at 02:05:47PM +0100, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > Since ACPI power resources are going to be used more extensively on
> > > new hardware platforms, it becomes necessary for user space (powertop
> > > in particular) to observe some properties of those resources for
> > > diagnostics purposes.
> > >
> > > For this reason, export the reference counts of ACPI power resources
> > > to user space by adding a new reference_count attribute to the sysfs
> > > directory representing each power resource. The value read from
> > > that attribute represents the number of devices using the power
> > > resource at the given time. If that value is 0, it meas that the
> > > power resource is not used and therefore it has been turned off.
> >
> > Why does userspace need to know a reference count? Is it so that if it
> > is not 0, it can work to try to lower it to 0? Or something else?
>
> Yes, this information is needed to say if (1) the power resource is in use
> and (2) how many users there are at the moment, so that we can go and look
> if it really has to be in use.
>
> Perhaps I can just expose the "in use"/"not in use" information. I don't
> think it will be much less convenient, because we should scan all of the
> possible users anyway in case they are coming and going frequently.
>
> So should I do that and rename the attribute to "resource_in_use" (or something
> similar)?

That makes a bit more sense to do, thanks.

greg k-h


\
 
 \ /
  Last update: 2013-01-22 04:21    [W:0.107 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site