lkml.org 
[lkml]   [2020]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [External] RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
    From
    Date


    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

    \
     
     \ /
      Last update: 2020-10-05 19:48    [W:3.890 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site