On 07/16/2013 12:32 PM, Greg KH wrote:
On Tue, Jul 16, 2013 at 12:33:03PM -0700, Srinivas Pandruvada wrote:
+Example Sys-FS Interface
+
+/sys/class/power_cap/intel-rapl
+├── package-0
+│ ├── constraint-0
+│ │ ├── name
+│ │ ├── power_limit_uw
+│ │ └── time_window_us
+│ ├── constraint-1
+│ │ ├── name
+│ │ ├── power_limit_uw
+│ │ └── time_window_us
+│ ├── core
+│ │ ├── constraint-0
+│ │ │ ├── name
+│ │ │ ├── power_limit_uw
+│ │ │ └── time_window_us
+│ │ ├── energy_uj
+│ │ └── max_energy_range_uj
+│ ├── dram
+│ │ ├── constraint-0
+│ │ │ ├── name
+│ │ │ ├── power_limit_uw
+│ │ │ └── time_window_us
+│ │ ├── energy_uj
+│ │ └── max_energy_range_uj
+│ ├── energy_uj
+│ ├── max_energy_range_uj
+│ └── max_power_range_uw
+├── package-1
+│ ├── constraint-0
+│ │ ├── name
+│ │ ├── power_limit_uw
+│ │ └── time_window_us
+│ ├── constraint-1
+│ │ ├── name
+│ │ ├── power_limit_uw
+│ │ └── time_window_us
+│ ├── core
+│ │ ├── constraint-0
+│ │ │ ├── name
+│ │ │ ├── power_limit_uw
+│ │ │ └── time_window_us
+│ │ ├── energy_uj
+│ │ └── max_energy_range_uj
+│ ├── dram
+│ │ ├── constraint-0
+│ │ │ ├── name
+│ │ │ ├── power_limit_uw
+│ │ │ └── time_window_us
+│ │ ├── energy_uj
+│ │ └── max_energy_range_uj
+│ ├── energy_uj
+│ ├── max_energy_range_uj
+│ └── max_power_range_uw
+├── power
+│ ├── async
+│ ├── autosuspend_delay_ms
+│ ├── control
+│ ├── runtime_active_kids
+│ ├── runtime_active_time
+│ ├── runtime_enabled
+│ ├── runtime_status
+│ ├── runtime_suspended_time
+│ └── runtime_usage
+├── subsystem -> ../../../../class/power_cap
+└── uevent
Ick. Rewrite this to use a bus and you should be fine, right? Don't
use a class, a class is only to be used if you have a device that is a
specific "type of thing". Like a tty device, it is a class, as lots of
different "real" devices can have tty ports on them (usb, pci, pcmcia,
platform, etc.)
Rethink this using a bus and see if that solves your issues. You get a
hierarchy with that. And you can have different "types" of devices on
your bus, making it easy to tell the difference between a "package" and
a "constraint".
Does that help?
I will experiment your suggestion. I see this class analogous to
"/sys/class/thermal",
, where the thermal class provides a set of consistent interface for all
thermal devices.
But thermal devices are not "real" at all. There are just a number of
"cooling devices" on a virtual bus and not attached to any type of a
real device at all.
Similar to cooling drivers, the power cap client drivers don't have to
be real.
For example intel rapl just uses x86 MSRs. But some other drivers can be
using
PCIe and use this framework to export control to users.
There's also no hierarchy that I can see with the thermal class, but you
want to have this, so you will have to do something different because
classes do not have hierarchies.
The reason, we tried not have hierarchy for ease of management from
a user space. If I use this flat model, then showing relationships need
to use
some sort of linking like regulator class. Do you have preference for
such model?
So try using a device and a bus and see if that helps out. If not,
please let me know.
Looking at this possibility.
thanks,
greg k-h
Thanks,
Srinivas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
