On 8/20/19 05:01, Viresh Kumar wrote:
> On 19-08-19, 15:39, Sylwester Nawrocki wrote:
>> 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.
>
> Adding OPPs dynamically has limitations, you can't set many values which are
> otherwise possible with DT. And removing/adding is not the right thing to do
> technically.
Thanks for explanation, I was not aware of that.
>> 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.
>
> Sorry but I am unable to understand the difficulty you are facing now. So what I
> suggest is something like this.
The difficulty was about representing data from tables asv_{arm,kfc}_table[][]
added in patch 3/9 of the series in devicetree. If you have no objections
about keeping those tables in the driver then I can't see any difficulties.
> - Use DT to get a frequency and voltage for each frequency.
Yes, this is what happens now, we have common OPPs in DT that work for each SoC
revision.
> - At runtime, based on SoC, registers, efuses, etc, update the voltage of the
> OPPs.
> - This algo can be different for each SoC, no one is stopping you from doing
> that.
>
> Am I missing something ?
Not really, this is basically what happens in the $subject patch series.
Then IIUC what I would need to change is to modify exynos_asv_update_cpu_opps()
function in patch 3/9 to use dev_pm_opp_adjust_voltage() rather than
dev_pm_opp_remove(), dev_pm_opp_add().
--
Thanks,
Sylwester
