linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] cpufreq: Add bindings for CPU clock sharing topology
Date: Wed, 23 Jul 2014 10:25:08 +0530	[thread overview]
Message-ID: <CAKohpokPAcmERN3S3Wbf7a4gXaQAWyBtKV7RXDHYThMWW57fGA@mail.gmail.com> (raw)
In-Reply-To: <CABGGisyDf7xt7CNii_NJ_stvBGNEeiXBMFxNkA2myS8OQ-VCtw@mail.gmail.com>

On 21 July 2014 22:30, Rob Herring <rob.herring@linaro.org> wrote:

> To me, but every time I suggest adding things to the topology the ARM
> folks object... I really think we should have built the topology into
> the /cpus hierarchy. Then we could add properties at the correct place
> in the hierarchy where they are common.
>
> I don't really like the proposal here. It just doesn't look like a
> clean description of the h/w.

I knew it wouldn't be easy to get these bindings correctly in the first
attempt atleast, but I still went for it so that this thread can progress:

https://lkml.org/lkml/2014/7/18/3

There are changes waiting to get some kind of intermediate solution
in, so that other platforms can reuse cpufreq-cpu0 driver. Also, so that
cpufreq-cpu0 can be converted to cpufreq-generic, so that it can support
almost any platform.

Can you please reply to that thread to suggest some intermediate
solution that we can get fixed in 3.17? Mvebu and Krait are waiting for
these patches to get in..

The solution can be simple enough as right now we have only two kinds
of platforms:
- All CPUs share clock
- All CPUs have separate clocks

The most simple solution of that could have been a Kconfig entry, but that
would be a problem for multi-arch builds if these platforms do want to get
build with multi-arch config. Otherwise we have to get some binding in
place for 3.17..

Please see if you can get that thread going :)

> Ignoring compatibility, I would like to see something like
> operating-points and/or the clock properties be moved up to /cpus if
> they are shared and be per cpu node when they are not. This of course
> does not work if you have independent OPPs for each cluster with a
> shared clock within cluster.

Yeah, that had always been the issue. People probably tried to get a
cluster {} block as well to simplify that but there were some objections
to it as well, though not sure what happened to that stuff..

      reply	other threads:[~2014-07-23  4:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18  5:35 [RFC] cpufreq: Add bindings for CPU clock sharing topology Viresh Kumar
2014-07-18  6:17 ` Olof Johansson
2014-07-18  6:40   ` Viresh Kumar
2014-07-18 21:52     ` Olof Johansson
2014-07-19 14:46       ` Viresh Kumar
2014-07-19 15:24         ` Santosh Shilimkar
2014-07-20 12:07           ` Viresh Kumar
2014-07-21 13:40             ` Santosh Shilimkar
2014-07-24  0:33             ` Mike Turquette
2014-07-24  2:24               ` Rob Herring
2014-07-24 10:39                 ` Viresh Kumar
2014-07-25 20:02                   ` Mike Turquette
2014-08-25  7:05                     ` Viresh Kumar
2014-07-21 17:00           ` Rob Herring
2014-07-23  4:55             ` Viresh Kumar [this message]

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=CAKohpokPAcmERN3S3Wbf7a4gXaQAWyBtKV7RXDHYThMWW57fGA@mail.gmail.com \
    --to=viresh.kumar@linaro.org \
    --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).