On 8/19/19 13:25, Viresh Kumar wrote: > On 19-08-19, 13:16, Sylwester Nawrocki wrote: >> On 8/19/19 11:09, Viresh Kumar wrote: >>> Will something like this help ? >>> >>> https://lore.kernel.org/lkml/1442623929-4507-3-git-send-email-sboyd@xxxxxxxxxxxxxx/ >>> >>> This never got merged but the idea was AVS only. >> >> It's quite interesting work, it seems to be for a more advanced use case >> where OPP voltage is being adjusted at runtime. >> >> We could use it instead of removing an OPP and then adding with updated >> voltage. On Exynos there is there is just a need to update OPPs once at boot >> time, so it is more "static". However the requirements could presumably >> change in future. > > The API is about changing the values after they are parsed once from DT. You can > change it once or multiple times depending on the use case. > >> If that's your preference I could switch to that notifier approach. > > You shouldn't be required to use the notifier. Just add the OPP table and update > the values right after that. So no one would be using the values at that time. OK, now I see dev_pm_opp_adjust_voltage() actually changes OPP's voltage and the notifier is optional. > Will this patchset solve the problems for you and make your DT light weight ? Unfortunately not, the patch set as I see it is another way of updating an OPP after it was parsed from DT. OPP remove/add could work equally well in our use case. The problem is that we have the information on how to translate the common OPP voltage to a voltage specific to given silicon encoded jointly in the ASV tables and the CHIPID registers (efuse/OTP memory). Additionally, algorithm of selecting ASV data (OPP voltage) based on the "key" data from registers is not generic, it is usually different per each SoC type. I tried to identify some patterns in those tables in order to simplify possible DT binding, but that was not really successful. I ended up just keeping whole tables. -- Regards, Sylwester
