On Wed, 3 Apr 2013 09:35:09 -0700 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Apr 02, 2013 at 09:48:18PM -0700, Jacob Pan wrote: > > > Let's step back and start over, what exactly are you trying to > > > tell userspace? What data do you have that you need to express > > > to it? How do you want userspace to see/use it? > > > > It is a good idea to step back and let me explain what I wanted to > > do here for userspace. > > > > I have two kinds of applications that might use this driver. > > 1. simple use case where user sets a power limit for a RAPL domain. > > e.g. set graphics unit power limit to 7w > > 2. advanced use case where use can do fine tuning on top of simple > > power limit,e.g. the dynamic response parameters of power control > > logic, event notifications, etc. > > > > For #1, this driver register with the abstract generic thermal layer > > (/sys/class/thermal) and presents itself as a set of cooling devices > > with a single knob per domain for power limits. > > root@chromoly:/sys/class/thermal/cooling_device15# echo 7000 > > > cur_state > > Great, how about submitting that functionality as patch 1 of your > series? That seems like a very "normal" thermal driver, right? > yes, that would be a normal thermal cooling device driver. I will do that first. Thanks for the suggestion. > > For #2, to give userspace complete control of the RAPL interface, > > which is not generic, I put them under the device private sysfs > > area. root@chromoly:/sys/class/thermal/cooling_device15/device# > > echo 1000 > time_window1 > > I totally fail to understand the difference. What do you want to show > to userspace that can't be expressed through the thermal interface > today? The difference is one single knob (long term power limit) in the thermal interface vs multiple fine grained control and data in the complete RAPL interface. Here is what a complete RAPL interface for package domain looks like. root@chromoly:/sys/class/thermal/cooling_device15/device# grep . * domain_name:package energy:22396031 lock:0 max_power:0 max_window:0 min_power:0 pl1_clamp:0 pl1_enable:1 pl2_clamp:0 pl2_enable:1 power:7841 power_limit1:25000 power_limit2:31250 thermal_spec_power:17000 throttle_time: time_window1:28000 time_window2:0 > Perhaps the thermal interface could be expanded to provide > more functionality that you need? yes, some of them such as limits. But not all the data in the list above are suitable for thermal interface. That is why I am trying to balance between abstracted generic data and RAPL specific data while still allow linking between the two. The way I envisioned how a thermal/power management app would use is: 1. go through generic thermal layer sysfs and find available RAPL domains 2. if the app wants to do more fine grained control, it follows the device symlink to locate the RAPL domain specific sysfs area. > Why create a one-off API that will > never be used again and require userspace programs to be written just > to handle this one type of device? > why is that a one-off API? RAPL interface is maintained identical across Intel CPUs after Sandy Bridges. I agree with you that it is still one type of device with some of its data unique. Should i create a RAPL class device? > > As you mentioned about using device tree vs. fs, and how kobject are > > used for fs. I do have the need to go between a generic thermal > > sysfs and the true device tree. This is the reason why I used > > kobjects and link them between device tree and its thermal sysfs > > representation. > > I don't understand your leap to using kobjects. > I use kobjects mainly for its symlink to allow userspace locate the 'true' device behind generic thermal layers' cooling device. > > e.g. a RAPL package cooling device linked with its platform device > > kobj. (device is linked with rapl_domains/package, the line is too > > long) > > > > root@chromoly:/sys/class/thermal# ls -l cooling_device15/ > > total 0 > > -rw-r--r-- 1 root root 4096 Apr 2 15:03 cur_state > > lrwxrwxrwx 1 root root 0 Apr 2 21:28 device > > -> ../../../platform/intel_rapl/rapl_domains/package > > -r--r--r-- 1 root root 4096 Apr 2 15:03 max_state > > drwxr-xr-x 2 root root 0 Apr 2 21:28 power > > lrwxrwxrwx 1 root root 0 Apr 2 15:03 subsystem > > -> ../../../../class/thermal > > -r--r--r-- 1 root root 4096 Apr 2 15:03 type > > -rw-r--r-- 1 root root 4096 Apr 2 15:03 uevent > > I still don't understand. What are you adding here, the device > symlink? Or something else? > > > For userspace which is not satisfied with the simple use case of a > > single knob for setting power limit, it can follow the link to find > > the device tree entry. Then get access to the complete knobs, > > including event notifications. > > And what is in that device directory? the device directory contains the complete RAPL interface representation. paste the example of package domain again. root@chromoly:/sys/class/thermal/cooling_device15/device# grep . * domain_name:package energy:22396031 lock:0 max_power:0 max_window:0 min_power:0 pl1_clamp:0 pl1_enable:1 pl2_clamp:0 pl2_enable:1 power:7841 power_limit1:25000 power_limit2:31250 thermal_spec_power:17000 grep: throttle_time: Input/output error time_window1:28000 time_window2:0 > What is rapl_domains? Why > isn't that a normal 'struct device'? > RAPL domains can be viewed as sub devices of RAPL interface. On a given platform they can be a complete or partial list of package, power plane 0 (processor core), power plane 1 (graphics), dram controller, pch, etc. Yes, I can create a RAPL class and create_device for each domain based on 'struct device'. I can still use the kobj symlink to link to generic thermal layer. I just thought it is an overkill as compared to simply using kobjects and kset. I don't understand the benefit of using 'struct device' in this case. RAPL interface as a whole has its device, I am not creating standalone kobjects. > Still confused. > > greg k-h [Jacob Pan] -- Thanks, Jacob -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
