Hi Viresh On 24.08.2020 11:09, Viresh Kumar wrote: > From: Stephan Gerhold <stephan@xxxxxxxxxxx> > > cpufreq-dt is currently unable to handle -EPROBE_DEFER properly > because the error code is not propagated for the cpufreq_driver->init() > callback. Instead, it attempts to avoid the situation by temporarily > requesting all resources within resources_available() and releasing them > again immediately after. This has several disadvantages: > > - Whenever we add something like interconnect handling to the OPP core > we need to patch cpufreq-dt to request these resources early. > > - resources_available() is only run for CPU0, but other clusters may > eventually depend on other resources that are not available yet. > (See FIXME comment removed by this commit...) > > - All resources need to be looked up several times. > > Now that the OPP core can propagate -EPROBE_DEFER during initialization, > it would be nice to avoid all that trouble and just propagate its error > code when necessary. > > This commit refactors the cpufreq-dt driver to initialize private_data > before registering the cpufreq driver. We do this by iterating over > all possible CPUs and ensure that all resources are initialized: > > 1. dev_pm_opp_get_opp_table() ensures the OPP table is allocated > and initialized with clock and interconnects. > > 2. dev_pm_opp_set_regulators() requests the regulators and assigns > them to the OPP table. > > 3. We call dev_pm_opp_of_get_sharing_cpus() early so that we only > initialize the OPP table once for each shared policy. > > With these changes, we actually end up saving a few lines of code, > the resources are no longer looked up multiple times and everything > should be much more robust. > > Signed-off-by: Stephan Gerhold <stephan@xxxxxxxxxxx> > [ Viresh: Use list_head structure for maintaining the list and minor > changes ] > Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx> This patch landed in linux-next about a week ago. It introduces a following warning on Samsung Exnyos3250 SoC: cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 1000000000, volt: 1150000, enabled: 1. New: freq: 1000000000, volt: 1150000, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 900000000, volt: 1112500, enabled: 1. New: freq: 900000000, volt: 1112500, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 800000000, volt: 1075000, enabled: 1. New: freq: 800000000, volt: 1075000, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 700000000, volt: 1037500, enabled: 1. New: freq: 700000000, volt: 1037500, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 600000000, volt: 1000000, enabled: 1. New: freq: 600000000, volt: 1000000, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 500000000, volt: 962500, enabled: 1. New: freq: 500000000, volt: 962500, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 400000000, volt: 925000, enabled: 1. New: freq: 400000000, volt: 925000, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 300000000, volt: 887500, enabled: 1. New: freq: 300000000, volt: 887500, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 200000000, volt: 850000, enabled: 1. New: freq: 200000000, volt: 850000, enabled: 1 cpu cpu1: _opp_is_duplicate: duplicate OPPs detected. Existing: freq: 100000000, volt: 850000, enabled: 1. New: freq: 100000000, volt: 850000, enabled: 1 I've checked a bit and this is related to the fact that Exynos3250 SoC use OPP-v1 table. Is this intentional? It is not a problem to convert it to OPP-v2 and mark OPP table as shared, but this is a kind of a regression. > ... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
