[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190410101423.3pl6yfhv2wnxuwgw@vireshk-i7>
Date: Wed, 10 Apr 2019 15:44:23 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Quentin Perret <quentin.perret@....com>
Cc: edubezval@...il.com, rui.zhang@...el.com, javi.merino@...nel.org,
amit.kachhap@...il.com, rjw@...ysocki.net, will.deacon@....com,
catalin.marinas@....com, daniel.lezcano@...aro.org,
dietmar.eggemann@....com, ionela.voinescu@....com,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 3/3] thermal: cpu_cooling: Migrate to using the EM
framework
On 10-04-19, 09:57, Quentin Perret wrote:
> Hmm, indeed... I thought cpufreq_table_validate_and_sort() was actively
> sorting the table but it seems I was wrong.
>
> But I _think_ in practice the freq table actually happens to be sorted
> for the upstream cpufreq drivers with the CPUFREQ_IS_COOLING_DEV flag
> set. Most of them use dev_pm_opp_init_cpufreq_table() which guarantees
> the table is sorted and qoriq-cpufreq explicitly sorts the table. But
> I'm not sure about qcom-cpufreq-hw ...
>
> So, if the above is true, perhaps I could simply add a check to mandate
> that policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_UNSORTED for
> cpu_cooling ? That shouldn't harm the existing users.
Right, I think most of the platforms will have it sorted anyway right now, but
you never know if one or two of them don't. Maybe just add the above conditional
and put out an error or WARN or something, so people know that something broke.
--
viresh
Powered by blists - more mailing lists