On Wed, Oct 14, 2020 at 7:10 PM Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> wrote: > > On 14/10/2020 17:24, Lukasz Luba wrote: > > [ ... ] > > > We have to update the EM doc about allowed abstract scale, which > > implies EAS, IPA doc update with some information to the community that > > these components can handle it. > > > > The script will just make developers life easier, but the current > > documentation does not say anything about abstract scale. > > ... yes, because there is no consistency across the source of power > numbers and no tools to ensure DT power numbers consistency, yet. > > >> In any case, if the DT is specifying real numbers, and SCMI abstract > >> numbers or the opposite, obviously there is a conflict if we are using > >> both. > > > > True, DT only allows real numbers (I have Rob's opinion regarding > > patch 3/3). > > > > It's not that there is only SCMI which might use abstract scale. Qcom > > already has it and other vendors will follow (not exposing real > > numbers). They would register bogoWatts to EM because they know that EAS > > can deal with both. > > So vendors are using bogoWatts, despite the documentation. > > By updating the documentation saying it supports the abstract values, > that means every new framework, device with power values, will have to > comply with that. How is it possible to add a device with power numbers > if the existing ones are obfuscated ? > > With two subsystems using the energy model, evolving independently we > can see there are conflicts. With more subsystems, that may become a > source of confusion, especially with different contributors. > > I think the energy model should stick to milliwatts and keep the > documentation unchanged regarding this. And vendors should take the > responsibility of not sticking to the documentation. > > >> I suggest to fix the conflict first and provide the features to make the > >> numbers more easy to share (like the script described above and/or the > >> firmware file). > >> > >> Then with the right tools, everything can be documented. > >> > > > > We cannot block one way of registration to EM when the other was used. > > They might have correct and consistent numbers. > > What is the rational of using two firmware power information ? > > > It's up to the platform developers to choose the path: > > - go with bogoWatts - if they are not allowed to expose sensitive > > information, use em_dev_register_perf_domain() in drivers, not DT; > > make sure everything that is needed works; check the doc, which > > sub-systems can handle it or needs some tuning (patches 1/3 and 2/3 > > try to help here); > > - use milliWatts - easier; DT is allowed; help from the community in > > reviews, possible results comparisons; both EM registration ways > > might be used; > > > > We cannot force vendors/OEM engineers to store milliWatts in the > > Energy Model if these values are protected by some NDA. > > If I am able to measure one real power value, (and I'm pretty sure it is > quite possible), whatever which one, it is possible to deduce all the > numbers with the linear scale. IMO that is a false debate. Anyway ... > > > Your proposed > > way of providing data into EM from user-space firmware.bin IMHO also > > falls into the same bucket. That information would be accessible in EM > > debugfs and they would avoid it. > > I think you misunderstood my point. > > There is the SCMI and the DT. Because there are two sources where it is > impossible to know if they are using the same units, we are stuck to > ensure a consistency for the kernel. > > The platform should use: > - the SCMI only (scaled or real) > - the DT only (real) > [ - the firmware file only (scaled or real) ] > > > As it is not possible to know if they are scaled or real, there is no > choice except making them mutually exclusive. > > From my POV, it is not adequate to let SCMI power information co-exists > with the DT power information if we know they can be with different units. > > I've just expressed my opinions: > > - vendors take responsibility of putting different units for the EM > > - Power numbers should come from the same source > > > Up to Rafael to decide what to do with this documentation update. Well, I was hoping that you both would reach some kind of agreement. I don't feel like the decision is mine here to be honest.
