Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [External] RE: [RFC] Documentation: Add documentation for new
 performance_profile sysfs class
To:     "Limonciello, Mario" <Mario.Limonciello@dell.com>,
        =?UTF-8?Q?Barnab=c3=a1s_P=c5=91cze?= <pobrn@protonmail.com>
CC:     Hans de Goede <hdegoede@redhat.com>,
        Darren Hart <dvhart@infradead.org>,
        Andy Shevchenko <andy@infradead.org>,
        Mark Gross <mgross@linux.intel.com>,
        Mark Pearson <mpearson@lenovo.com>,
        Elia Devito <eliadevito@gmail.com>,
        Bastien Nocera <hadess@hadess.net>,
        Benjamin Berg <bberg@redhat.com>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20201003131938.9426-1-hdegoede@redhat.com>
 <20201003131938.9426-2-hdegoede@redhat.com>
 <DM6PR19MB263669227D122BB7699951E6FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
 <Mz2G7glm3yMTniKA6SHM011dDkTFF4_otICrMQfVLheopX8JMGSupPleyjyK8OY0tyUazu09nX7XhleBVdl4ozTCWXCPGyvV58Qc-UUTvig=@protonmail.com>
 <DM6PR19MB26369E7468931E63B69A0604FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
 <91a9bb74-49e7-0a8d-cbc1-3f1907293fa4@lenovo.com>
 <DM6PR19MB263622BBE4B699A0AA49977DFA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
From:   Mark Pearson <markpearson@lenovo.com>
Message-ID: <26662fd8-1bd8-94b9-2fa6-6b1c1c96481d@lenovo.com>
Date:   Mon, 5 Oct 2020 13:46:47 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <DM6PR19MB263622BBE4B699A0AA49977DFA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2020-10-05 12:56 p.m., Limonciello, Mario wrote:
>>>
>>> When implemented for the two vendors mentioned here, it would be using a
>>> proprietary "firmware API" implemented by those two vendors.  For example
>> write
>>> arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to
>> coordinate
>>> using undisclosed protocol to affect the platform changes desirable.
>>>
>>> This is different in my mind from "kernel writes to a specific register" to
>> set
>>> power properties of a specific device.
>>>
>>
>> Just curious on this point - isn't that (mostly) what all hardware does?
>> You write to it and the device does "stuff" to achieve the required
>> effect. Yes this is in proprietary firmware, but from my experience with
>> hardware devices that's not uncommon these days anyway.
>>
> 
> Yes I agree.  Even "register" writes to a device are actually an API and
> something in the hardware monitors those registers and does something as a
> result.
> 
>> Let me know if I'm misunderstanding something here. I couldn't see the
>> difference between a register written to via ACPI and one written to via
>> some other protocol (SMBUS? or whatever)
>>
>> Mark
>>
> 
> The reason I'm calling out a distinction here is that "platform" and "device"
> can cover a lot more things.  In this case it's an API provided by the platform's
> firmware, not an individual device's firmware.  So you can't actually guarantee
> what the platform's firmware did.  It could have sent any number of sideband
> commands to devices that it controls.  The "platform" could have potentially
> told the GPU to turn up its fans, or lower it's clock as a result of this, but you
> can't possibly know.
> 
> However if we go the GPU example alone, it's a specific single device you're
> controlling.  You put the GPU into the characterization that you expected and it
> operates that way.
> 
Got it - fair enough :) Thanks for the explain.
Thanks
Mark