Hi, In data venerdì 16 ottobre 2020 16:43:09 CEST, Mark Pearson ha scritto: > <Note - switched my email address to my more open source non-outlook > based address> > > On 2020-10-16 10:32 a.m., Mark Pearson wrote: > > ------------------------------------------------------------------------ > > *From:* Elia Devito <eliadevito@xxxxxxxxx> > > *Sent:* October 16, 2020 10:26 > > *To:* Rafael J. Wysocki <rafael@xxxxxxxxxx>; Hans de Goede > > <hdegoede@xxxxxxxxxx> > > *Cc:* Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>; Srinivas Pandruvada > > <srinivas.pandruvada@xxxxxxxxxxxxxxx>; Lukasz Luba > > <lukasz.luba@xxxxxxx>; Linux Kernel Mailing List > > <linux-kernel@xxxxxxxxxxxxxxx>; Linux PM <linux-pm@xxxxxxxxxxxxxxx>; > > Zhang, Rui <rui.zhang@xxxxxxxxx>; Bastien Nocera <hadess@xxxxxxxxxx>; > > Mark Pearson <mpearson@xxxxxxxxxx>; Limonciello, Mario > > <Mario.Limonciello@xxxxxxxx>; Darren Hart <dvhart@xxxxxxxxxxxxx>; Andy > > Shevchenko <andy@xxxxxxxxxxxxx>; Mark Gross <mgross@xxxxxxxxxxxxxxx>; > > Benjamin Berg <bberg@xxxxxxxxxx>; linux-acpi@xxxxxxxxxxxxxxx > > <linux-acpi@xxxxxxxxxxxxxxx>; platform-driver-x86@xxxxxxxxxxxxxxx > > <platform-driver-x86@xxxxxxxxxxxxxxx> > > *Subject:* [External] Re: [RFC] Documentation: Add documentation for new > > performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add > > the DTPM framework) > > Hi, > > > > In data venerdì 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto: > >> <note folding the 2 threads we are having on this into one, adding every > >> one from both threads to the Cc> > >> > >> Hi, > >> > >> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > >> > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >> >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > >> <snip> > >> > >> >>> First, a common place to register a DPTF system profile seems to be > >> >>> needed and, as I said above, I wouldn't expect more than one such > >> >>> thing to be present in the system at any given time, so it may be > >> >>> registered along with the list of supported profiles and user space > >> >>> will have to understand what they mean. > >> >> > >> >> Mostly Ack, I would still like to have an enum for DPTF system > >> >> profiles in the kernel and have a single piece of code map that > >> >> enum to profile names. This enum can then be extended as > >> >> necessary, but I want to avoid having one driver use > >> >> "Performance" and the other "performance" or one using > >> >> "performance-balanced" and the other "balanced-performance", etc. > >> >> > >> >> With the goal being that new drivers use existing values from > >> >> the enum as much as possible, but we extend it where necessary. > >> > > >> > IOW, just a table of known profile names with specific indices assigned > >> > to > >> > them. > >> > >> Yes. > >> > >> > This sounds reasonable. > >> > > >> >>> Second, irrespective of the above, it may be useful to have a > >> >>> consistent way to pass performance-vs-power preference information > >> >>> from user space to different parts of the kernel so as to allow them > >> >>> to adjust their operation and this could be done with a system-wide > >> >>> power profile attribute IMO. > >> >> > >> >> I agree, which is why I tried to tackle both things in one go, > >> >> but as you said doing both in 1 API is probably not the best idea. > >> >> So I believe we should park this second issue for now and revisit it > >> >> when we find a need for it. > >> > > >> > Agreed. > >> > > >> >> Do you have any specific userspace API in mind for the > >> >> DPTF system profile selection? > >> > > >> > Not really. > >> > >> So before /sys/power/profile was mentioned, but that seems more like > >> a thing which should have a set of fixed possible values, iow that is > >> out of scope for this discussion. > >> > >> Since we all seem to agree that this is something which we need > >> specifically for DPTF profiles maybe just add: > >> > >> /sys/power/dptf_current_profile (rw) > >> /sys/power/dptf_available_profiles (ro) > >> > >> (which will only be visible if a dptf-profile handler > >> > >> has been registered) ? > >> > >> Or more generic and thus better (in case other platforms > >> later need something similar) I think, mirror the: > >> > >> /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits > >> for a system-wide energy-performance setting, so we get: > >> > >> /sys/power/energy_performance_preference > >> /sys/power/energy_performance_available_preferences > >> > >> (again only visible when applicable) ? > >> > >> I personally like the second option best. > >> > >> Regards, > >> > >> Hans > > > > between the two, the second seems to me more appropriate. > > Considering that the various profiles interact with thermal behaviors > > what do > > you think of something like: > > > > /sys/power/thermal_profile_available_profiles > > /sys/power/thermal_profile_profile > > > > Regards, > > Elia > > I'm good with either but I do find 'profile_profile' slightly awkward to > say out loud (even though it's logically correct :)) > > How about just: > /sys/power/platform_profile > /sys/power/platform_profile_available > > As it covers the platform as a whole - fans, temperature, power, and > anything else that ends up getting thrown in? > > Mark Completely agree, I made a typo xD Elia
