All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olof Johansson <olof@lixom.net>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Mike Turquette <mike.turquette@linaro.org>,
	Rob Herring <rob.herring@linaro.org>,
	Grant Likely <grant.likely@linaro.org>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	Nishanth Menon <nm@ti.com>, Sudeep Holla <Sudeep.Holla@arm.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Arvind Chauhan <arvind.chauhan@arm.com>,
	Arnd Bergmann <arnd.bergmann@linaro.org>
Subject: Re: [RFC] cpufreq: Add bindings for CPU clock sharing topology
Date: Fri, 18 Jul 2014 14:52:25 -0700	[thread overview]
Message-ID: <CAOesGMhuNzVtUkaUjF+JjNgHcgf08WiM0DG-kzwtcyUxkK_zow@mail.gmail.com> (raw)
In-Reply-To: <CAKohpo=MmoALOHg-=7cf0jm=OJO57TWQZQXqkRwhRwU-DGPMmA@mail.gmail.com>

On Thu, Jul 17, 2014 at 11:40 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 18 July 2014 11:47, Olof Johansson <olof@lixom.net> wrote:
>> Why complicate it by using two properties?
>>
>> If there is no property, then the CPUs are assumed to be controlled
>> independently.
>>
>> if there is a clock-master = <phandle> property, then that points at
>> the cpu that is the main one controlling clock for the group.
>>
>> There's really no need to label the master -- it will be the only one
>> with incoming links but nothing outgoing. And a master without slaves
>> is an independently controlled cpu so you should be fine in that
>> aspect too.
>
> I thought so earlier, but then I remembered something I read long back.
> Don't remember which thread now, but I *might* be wrong..
>
> "Bindings are like APIs and new bindings shouldn't break existing stuff.."
>
> And:
>
>> If there is no property, then the CPUs are assumed to be controlled
>> independently.
>
> seems to break the existing API.

What is the current API that is being broken, in your opinion?

> But if that isn't the case, the bindings are very simple & clear to handle.
> Diff for new bindings:

It's somewhat confusing to see a diff to the patch instead of a new
version. It seems to remove the cpu 0 entry now?


-Olof

WARNING: multiple messages have this Message-ID (diff)
From: olof@lixom.net (Olof Johansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] cpufreq: Add bindings for CPU clock sharing topology
Date: Fri, 18 Jul 2014 14:52:25 -0700	[thread overview]
Message-ID: <CAOesGMhuNzVtUkaUjF+JjNgHcgf08WiM0DG-kzwtcyUxkK_zow@mail.gmail.com> (raw)
In-Reply-To: <CAKohpo=MmoALOHg-=7cf0jm=OJO57TWQZQXqkRwhRwU-DGPMmA@mail.gmail.com>

On Thu, Jul 17, 2014 at 11:40 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 18 July 2014 11:47, Olof Johansson <olof@lixom.net> wrote:
>> Why complicate it by using two properties?
>>
>> If there is no property, then the CPUs are assumed to be controlled
>> independently.
>>
>> if there is a clock-master = <phandle> property, then that points at
>> the cpu that is the main one controlling clock for the group.
>>
>> There's really no need to label the master -- it will be the only one
>> with incoming links but nothing outgoing. And a master without slaves
>> is an independently controlled cpu so you should be fine in that
>> aspect too.
>
> I thought so earlier, but then I remembered something I read long back.
> Don't remember which thread now, but I *might* be wrong..
>
> "Bindings are like APIs and new bindings shouldn't break existing stuff.."
>
> And:
>
>> If there is no property, then the CPUs are assumed to be controlled
>> independently.
>
> seems to break the existing API.

What is the current API that is being broken, in your opinion?

> But if that isn't the case, the bindings are very simple & clear to handle.
> Diff for new bindings:

It's somewhat confusing to see a diff to the patch instead of a new
version. It seems to remove the cpu 0 entry now?


-Olof

  reply	other threads:[~2014-07-18 21:52 UTC|newest]

Thread overview: 30+ 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  5:35 ` Viresh Kumar
2014-07-18  6:17 ` Olof Johansson
2014-07-18  6:17   ` Olof Johansson
2014-07-18  6:40   ` Viresh Kumar
2014-07-18  6:40     ` Viresh Kumar
2014-07-18 21:52     ` Olof Johansson [this message]
2014-07-18 21:52       ` Olof Johansson
2014-07-19 14:46       ` Viresh Kumar
2014-07-19 14:46         ` Viresh Kumar
2014-07-19 15:24         ` Santosh Shilimkar
2014-07-19 15:24           ` Santosh Shilimkar
2014-07-20 12:07           ` Viresh Kumar
2014-07-20 12:07             ` Viresh Kumar
2014-07-21 13:40             ` Santosh Shilimkar
2014-07-21 13:40               ` Santosh Shilimkar
2014-07-24  0:33             ` Mike Turquette
2014-07-24  0:33               ` Mike Turquette
2014-07-24  2:24               ` Rob Herring
2014-07-24  2:24                 ` Rob Herring
2014-07-24 10:39                 ` Viresh Kumar
2014-07-24 10:39                   ` Viresh Kumar
2014-07-25 20:02                   ` Mike Turquette
2014-07-25 20:02                     ` Mike Turquette
2014-08-25  7:05                     ` Viresh Kumar
2014-08-25  7:05                       ` Viresh Kumar
2014-07-21 17:00           ` Rob Herring
2014-07-21 17:00             ` Rob Herring
2014-07-23  4:55             ` Viresh Kumar
2014-07-23  4:55               ` 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=CAOesGMhuNzVtUkaUjF+JjNgHcgf08WiM0DG-kzwtcyUxkK_zow@mail.gmail.com \
    --to=olof@lixom.net \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Sudeep.Holla@arm.com \
    --cc=arnd.bergmann@linaro.org \
    --cc=arvind.chauhan@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mike.turquette@linaro.org \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=rob.herring@linaro.org \
    --cc=santosh.shilimkar@ti.com \
    --cc=sboyd@codeaurora.org \
    --cc=viresh.kumar@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.