From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Date: Mon, 24 Nov 2014 13:44:44 +0000 [thread overview]
Message-ID: <5473364C.3010102@arm.com> (raw)
In-Reply-To: <CAKohponEHqHYCLibVc8OHN49+4YW5qw89ny4ycTBL1xN-p9qtA@mail.gmail.com>
On 20/11/14 03:48, Viresh Kumar wrote:
> Oh, you are still alive? I thought you were about to get married :)
> Just kidding !!
>
> On 20 November 2014 00:58, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Sorry for raising this issue always with Exynos cpufreq drivers. IMO the
>> bindings for "arm-bL-cpufreq-dt" is broken. Currently no one is using it
>> and it's better to fix it before we have a real user of it.
>
> Hmm, yeah if we can. I haven't found a easy way to go ahead and then
> got caught in other activities.
>
Agreed, it's not easy but needs to be fixed :)
>> If you look at the binding document for it[1], it has a fixme which
>> shouldn't have been there at first place. It assumes the ordering of
>> CPU's specified in the DT and the logical index allocation to them.
>
> Ok, I believe the FIXME is a bit outdated. From the code I can see only
> this limitation.
>
> - For every cluster, the cpu which boots up first should carry the OPPs.
> Otherwise there is no restriction on ordering of CPUs.
>
Not entirely true, it assuming the fact that the logical index provided
by the OS is completely based on the ordering in the DT.
> - I believe CPUs boot in the order they are present in DT except for the
> boot CPU. So, the first node for every cluster should have it.
>
> Correct ? Then we can update the fixme.
>
No, I disagree as you trying to implicitly depend on the logic Linux
uses to assign logical index. It can be changed any time, and depending
on it might break things in future which can't be fixed easily later
especially if it's DT related.
>> It even breaks for hotplug especially if you hotplug-in back in
>> different order.
>
> Hmm, I never thought about it. But yes the CPU with the OPPs should
> be the first one to come back.
>
How can you assume that ? I can write a simple test which hot-plugs out
all the CPUs in the (esp. multi-cluster) system in ascending order of
logical index and hot-plug back in descending order. Then the above
logic fails.
>> We can work around that probably, but it's better to
>> fix the binding. I failed to grab much attention in my previous attempts
>> to address this[2]. Viresh also started a discussion more recently[3].
>
> They are just stuck and went nowhere :(
>
The platforms needing it have to get involved in such discussions to
make any progress.
Regards,
Sudeep
next prev parent reply other threads:[~2014-11-24 13:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 11:41 [PATCH v11 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
2014-10-20 11:35 ` Tomasz Figa
2014-10-20 11:48 ` Thomas Abraham
2014-10-20 14:18 ` Tomasz Figa
2014-10-20 11:41 ` [PATCH v11 1/6] clk: samsung: add infrastructure to register cpu clocks Thomas Abraham
2014-10-20 11:41 ` [PATCH v11 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock Thomas Abraham
2014-10-20 11:41 ` [PATCH v11 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property Thomas Abraham
2014-10-20 11:41 ` [PATCH v11 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420 Thomas Abraham
2014-10-20 11:41 ` [PATCH v11 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support Thomas Abraham
2014-10-20 11:32 ` Viresh Kumar
2014-10-20 11:38 ` Thomas Abraham
2014-10-20 12:09 ` Thomas Abraham
2014-10-20 11:41 ` [PATCH v11 6/6] clk: samsung: remove unused clock aliases and update clock flags Thomas Abraham
2014-11-12 6:03 ` [PATCH v11 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420 Amit Kucheria
2014-11-21 14:32 ` Thomas Abraham
2014-11-19 17:30 ` Kevin Hilman
2014-11-21 14:31 ` Thomas Abraham
2014-11-19 19:28 ` Sudeep Holla
2014-11-20 3:48 ` Viresh Kumar
2014-11-24 13:44 ` Sudeep Holla [this message]
2014-11-25 11:02 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5473364C.3010102@arm.com \
--to=sudeep.holla@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).