Hi Daniel,
On 2/23/22 09:52, Daniel Lezcano wrote:
Hi Lukasz,
why not extend the energy model to any kind of devices?
The changes are shyly proposing a new entry in the OPP table like that
is the only place where power management can happen.
It was Viresh proposal to make it in the OPP v2 table. I've checked
the code and this u_watt fits perfectly there. New power value looks
natural there. We also have the interconnect info in the opp, so even
this kind of extensions are there.
It is a clean solution which meats the GPU requirements.
Is the approach to describe by small pieces here and there, specific
attributes and let the kernel create an energy model from that soap?
I prefer the RFC approach where the energy model is described clearly
but, IMHO, it should be more abstracted, without reference to frequency
or whatever but index <-> power (t-uple or equation)
By this way, it could be possible to describe the battery with the
different charges, the LCD bright light, etc ...
I can see your need, but I would focus on existing issues and devices.
This change was motivated by existing mainline platform which wants
to have EM in GPU (Chromebook) from DT. The GPU has OPP table, thus it
meets this requirement. The requirements are clear for the GPU (and
similar like DSP/ISP/etc which all have OPP table).
This is a clean, small step forward with the OPP approach and it
doesn't block your future needs and requirements. IMO it's orthogonal,
devices which have OPP table naturally might provide power there.
Devices which wouldn't have OPP table, but wanted to register EM
via DT - it's a different story (not the existing Chromebook's GPU).
This future story can be addressed in some next step. We need real
devices and examples to figure out the requirements and craft something.
