On 20-08-19, 11:03, Sylwester Nawrocki wrote:
> On 8/20/19 05:01, Viresh Kumar wrote:
> > 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.
The problem with keeping such tables in kernel is that they contain too much
magic values which very few people understand. And after some amount of time,
even they don't remember any of it.
What I was expecting was to remove as much of these tables as possible and do
the calculations to get them at runtime with some logical code which people can
understand later on.
> > - 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().
That and somehow add code to get those tables if possible.
--
viresh
