From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49F9BC433E7 for ; Fri, 16 Oct 2020 14:26:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D342C20848 for ; Fri, 16 Oct 2020 14:26:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SmmMkUw2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406887AbgJPO0U (ORCPT ); Fri, 16 Oct 2020 10:26:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390724AbgJPO0T (ORCPT ); Fri, 16 Oct 2020 10:26:19 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39C02C061755; Fri, 16 Oct 2020 07:26:18 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id x7so3174037wrl.3; Fri, 16 Oct 2020 07:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=RpHL2pmcG7XNMxRENeUpmnEYfg0F72pinXyJP1jJFB8=; b=SmmMkUw2n6WZdR0N52P05/GmD5Oo5yyLda9sROnFISetU7nBx+EL+EYbxviRgOYD4w XXlwaA4lzppI5vziBVE0+ISQVMnjzRMJe4pyVIx451NhcPj5nGB6XdPYKZbowidlCbQJ 0FjmiiPw8sWlNkZvDv58qzOIBsHuvsqPhQX6GVy18VygS/1rVJ+99xlMo9BSkWf/dpR1 xAtIIgx3m+Z8Z7FaxZpl6VmYO2MWNsfvOdO9R6VU0SA8zi+NpvAMkmz2eiN3YIfvAqkl aMOtE++fnAt0vzpl4OjbjjtAHZkzyCwmt1cfMr4aF/P5Z/ym4sTo8/wYAJcR9x+1gn50 brhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RpHL2pmcG7XNMxRENeUpmnEYfg0F72pinXyJP1jJFB8=; b=Bl8aPoggZKv/ivcnBBKM3YkO0nwyYILEYzzivkwboix61zPYx9eNu6MMIYE8M6tSBI FERsrw1PyTMckCOVLYnVl7QffY1ZvLpxv18cBhuvdRWudm09L5IAg6t9WMHtxJa0PCVw kYlths6ODhFAYE3soBEjfHPNDstDE9HSN+zXZuBh8Hrq1T4170IBm2dlgmhQvLeag/hs ECG9Yu9Jt424yu9L/WFLuRuQQyO6TseUA4mq96zbr1bbd61yoeCgbUBlXAVPK/8Hekwr euTTiClZ/MOWJZS2GS9BLwT1rVNN8rxngqPd8GHOvhGM9zSkRjX+ZLOURspFjucmmoYl m13Q== X-Gm-Message-State: AOAM531kIWpzoqSrj05bWQAzZRv8GhWZIH0+h3UYmOx6eRC9DnEvNtpg pUpgrmu4L8WpszavYd0X53o= X-Google-Smtp-Source: ABdhPJxOXM7pkhmb/DdXwtIspFFXCqiiNtkftB3jeaUYVxEHwrZdhEZr99bZiJuOICg0fa6LMZ3f6g== X-Received: by 2002:adf:ed07:: with SMTP id a7mr4443771wro.326.1602858376481; Fri, 16 Oct 2020 07:26:16 -0700 (PDT) Received: from pce.localnet (host-80-117-125-178.retail.telecomitalia.it. [80.117.125.178]) by smtp.gmail.com with ESMTPSA id i33sm3823963wri.79.2020.10.16.07.26.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Oct 2020 07:26:15 -0700 (PDT) From: Elia Devito To: "Rafael J. Wysocki" , Hans de Goede Cc: Daniel Lezcano , Srinivas Pandruvada , Lukasz Luba , Linux Kernel Mailing List , Linux PM , "Zhang, Rui" , Bastien Nocera , Mark Pearson , "Limonciello, Mario" , Darren Hart , Andy Shevchenko , Mark Gross , Benjamin Berg , "linux-acpi@vger.kernel.org" , "platform-driver-x86@vger.kernel.org" Subject: Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework) Date: Fri, 16 Oct 2020 16:26:13 +0200 Message-ID: <4600468.GXAFRqVoOG@pce> In-Reply-To: <943531a7-74d6-7c7f-67bc-2645b3ba7b8a@redhat.com> References: <20201006122024.14539-1-daniel.lezcano@linaro.org> <943531a7-74d6-7c7f-67bc-2645b3ba7b8a@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi, In data venerd=EC 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto: > from both threads to the Cc> >=20 > Hi, >=20 > On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wro= te: > >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > >=20 > >>> 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. > >>=20 > >> 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. > >>=20 > >> With the goal being that new drivers use existing values from > >> the enum as much as possible, but we extend it where necessary. > >=20 > > IOW, just a table of known profile names with specific indices assigned= to > > them. > Yes. >=20 > > This sounds reasonable. > >=20 > >>> 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. > >>=20 > >> 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. > >=20 > > Agreed. > >=20 > >> Do you have any specific userspace API in mind for the > >> DPTF system profile selection? > >=20 > > Not really. >=20 > 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. >=20 > Since we all seem to agree that this is something which we need > specifically for DPTF profiles maybe just add: >=20 > /sys/power/dptf_current_profile (rw) > /sys/power/dptf_available_profiles (ro) >=20 > (which will only be visible if a dptf-profile handler > has been registered) ? >=20 > Or more generic and thus better (in case other platforms > later need something similar) I think, mirror the: >=20 > /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits > for a system-wide energy-performance setting, so we get: >=20 > /sys/power/energy_performance_preference > /sys/power/energy_performance_available_preferences >=20 > (again only visible when applicable) ? >=20 > I personally like the second option best. >=20 > Regards, >=20 > Hans between the two, the second seems to me more appropriate. Considering that the various profiles interact with thermal behaviors what = do=20 you think of something like: /sys/power/thermal_profile_available_profiles /sys/power/thermal_profile_profile Regards, Elia