Thread (27 messages) 27 messages, 6 authors, 2015-12-07

[PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422

From: Ben Gamari <hidden>
Date: 2015-12-03 10:26:45
Also in: linux-clk, linux-pm, linux-samsung-soc, lkml

Viresh Kumar [off-list ref] writes:
Hi Ben,
Hi Viresh,
On 02-12-15, 22:19, Ben Gamari wrote:
quoted
This patch series adds cpufreq support for the Exynos 5800, 5420, and 5422
SOCs. In particular, it adds support for operating-points-v2 bindings to the
arm-big-little cpufreq driver and updates the above-mentioned SOCs' devicetrees
to take advantage of this support. There are also a couple of patches improving
the clarify of the arm-big-little implementation. It is built on a set posted
by Bartlomiej Zolnierkiewicz in April 2015.

The most signficant change from the original series is porting to the
operating-points-v2 devicetree bindings. The series has been tested by me on
and Odroid XU4 and by Javier Martinez Canillas on a Peach Pit.
Thanks for working with opp-v2 bindings, really appreciate it.
My pleasure.
But, before I start reviewing this series, I have few comments.
- We weren't able to use cpufreq-dt driver for big LITTLE platforms
  earlier, as it never had multi cluster support and we wanted
  clock-sharing information via DT.
Fair enough.
- That is all fixed now.
I did not see any mention of this in the cpufreq-dt driver binding
documentation, otherwise I would have tried going this route.

Do you have any references? I'd be happy to examine what would be
necessary to go this route although, being an independent contributor,
it may take time.
- I want Samsung's big LITTLE platforms to use cpufreq-dt and drop
  arm_big_little driver completely.
That sounds like a great direction going forward. However, I would still
kindly request that you consider this series.

The existence of future plans of course does not change the fact that
users have real hardware today; hardware that they have spent money on
and would like to use. Cpufreq support has already been deferred once
for similar reasons of interface churn which essentially forestalled
working functionality from entering the kernel by eight months; I'd
really like to avoid having this happen again.
- The only case for which it (arm_big_little) driver might be useful
  is the IKS solution. Which I don't believe you are going to use in
  future :)
Indeed.
My plan for the arm-big-little driver:
- Migrate all platforms to use cpufreq-dt instead for non-IKS
  solution
- Make arm-big-little driver arm-big-little-iks only driver.
Sounds reasonable to me. However, I'd just like to reiterate that this
line of work can be pursued independently from the upstreaming of this
series.

Thanks for your time,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151203/43ae442c/attachment.sig>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help