Fabiano Rosas writes:
> Pratik Sampat writes:
...
>>>
The new H_CALL exports information in direct string value format, hence
a new interface has been introduced in /sys/firmware/papr to export
>>> Hm.. Maybe this should be something less generic than "papr"?
>>
>> The interface naming
On 10/06/21 5:33 am, Fabiano Rosas wrote:
Pratik Sampat writes:
3. version info - 1 byte
4. A data array of size num attributes, which contains the following:
a. attribute ID - 8 bytes
b. attribute value in number - 8 bytes
c. attribute name in
Pratik Sampat writes:
>>> 3. version info - 1 byte
>>> 4. A data array of size num attributes, which contains the following:
>>>a. attribute ID - 8 bytes
>>>b. attribute value in number - 8 bytes
>>>c. attribute name in string - 64 bytes
>>>d. at
Hello,
Thank you for your comments on the design.
On 09/06/21 3:43 am, Fabiano Rosas wrote:
"Pratik R. Sampat" writes:
Hi, I have some general comments and questions, mostly trying to
understand design of the hcall and use cases of the sysfs data:
Adds a generic interface to represent the en
"Pratik R. Sampat" writes:
Hi, I have some general comments and questions, mostly trying to
understand design of the hcall and use cases of the sysfs data:
> Adds a generic interface to represent the energy and frequency related
> PAPR attributes on the system using the new H_CALL
> "H_GET_ENERG
I've implemented a POC using this interface for the powerpc-utils'
ppc64_cpu --frequency command-line tool to utilize this information
in userspace.
The POC has been hosted here:
https://github.com/pratiksampat/powerpc-utils/tree/H_GET_ENERGY_SCALE_INFO
and based on comments I suggestions I can f
Adds a generic interface to represent the energy and frequency related
PAPR attributes on the system using the new H_CALL
"H_GET_ENERGY_SCALE_INFO".
H_GET_EM_PARMS H_CALL was previously responsible for exporting this
information in the lparcfg, however the H_GET_EM_PARMS H_CALL
will be deprecated
