From: Viresh Kumar <viresh.kumar@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org, Mason <slash.tmp@free.fr>,
linux-pm <linux-pm@vger.kernel.org>
Subject: Re: [PATCH RFC] Add cpufreq support
Date: Mon, 8 Feb 2016 18:46:25 +0530 [thread overview]
Message-ID: <20160208131625.GI8294@vireshk> (raw)
In-Reply-To: <22002072.L04zy0K2AP@wuerfel>
On 08-02-16, 14:10, Arnd Bergmann wrote:
> I don't remember the exact discussion, but the compatible string is
> exactly meant to do one thing: it tells you what you can or cannot do
> with one device.
Yeah, and many people argued that we can't add two values to that
string like: "cpufreq-dt" and "cpufreq-big-little" for same kind of
OPP bindings, as a different compatible string should be required only
if there is a difference in the bindings.
For example, if a platform (like ST did recently) adds more
platform-specific properties, then they can define a new value of
those strings.
> I had not realized that we don't even have a compatible string
> for opp-v2, so if we are missing that, we obviously can't compare
> against that string.
The binding says that we can have a string, but its not compulsory
yet. Its only used by STM as they have some specific properties of
their own.
> I thought there was a compatible property in there that told us
> whether the operating-points-v2/cooling-min-level/#cooling-cells/...
> properties were considered valid.
Yeah, "OPP-v2" DT node can have a compatible string, which isn't
compulsory as of now, but because of the reasons mentioned earlier, we
can't use it to differentiate between drivers that use exactly same
version of bindings.
--
viresh
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] Add cpufreq support
Date: Mon, 8 Feb 2016 18:46:25 +0530 [thread overview]
Message-ID: <20160208131625.GI8294@vireshk> (raw)
In-Reply-To: <22002072.L04zy0K2AP@wuerfel>
On 08-02-16, 14:10, Arnd Bergmann wrote:
> I don't remember the exact discussion, but the compatible string is
> exactly meant to do one thing: it tells you what you can or cannot do
> with one device.
Yeah, and many people argued that we can't add two values to that
string like: "cpufreq-dt" and "cpufreq-big-little" for same kind of
OPP bindings, as a different compatible string should be required only
if there is a difference in the bindings.
For example, if a platform (like ST did recently) adds more
platform-specific properties, then they can define a new value of
those strings.
> I had not realized that we don't even have a compatible string
> for opp-v2, so if we are missing that, we obviously can't compare
> against that string.
The binding says that we can have a string, but its not compulsory
yet. Its only used by STM as they have some specific properties of
their own.
> I thought there was a compatible property in there that told us
> whether the operating-points-v2/cooling-min-level/#cooling-cells/...
> properties were considered valid.
Yeah, "OPP-v2" DT node can have a compatible string, which isn't
compulsory as of now, but because of the reasons mentioned earlier, we
can't use it to differentiate between drivers that use exactly same
version of bindings.
--
viresh
next prev parent reply other threads:[~2016-02-08 13:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 16:58 [PATCH RFC] Add cpufreq support Mason
2016-02-05 16:58 ` Mason
2016-02-05 22:24 ` Arnd Bergmann
2016-02-05 22:24 ` Arnd Bergmann
2016-02-07 12:22 ` Viresh Kumar
2016-02-07 12:22 ` Viresh Kumar
2016-02-08 12:24 ` Arnd Bergmann
2016-02-08 12:24 ` Arnd Bergmann
2016-02-08 12:31 ` Viresh Kumar
2016-02-08 12:31 ` Viresh Kumar
2016-02-08 12:34 ` Arnd Bergmann
2016-02-08 12:34 ` Arnd Bergmann
2016-02-08 12:41 ` Viresh Kumar
2016-02-08 12:41 ` Viresh Kumar
2016-02-08 13:10 ` Arnd Bergmann
2016-02-08 13:10 ` Arnd Bergmann
2016-02-08 13:16 ` Viresh Kumar [this message]
2016-02-08 13:16 ` Viresh Kumar
2016-02-08 13:45 ` Arnd Bergmann
2016-02-08 13:45 ` Arnd Bergmann
2016-02-09 10:17 ` Mason
2016-02-09 10:17 ` Mason
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=20160208131625.GI8294@vireshk \
--to=viresh.kumar@linaro.org \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=slash.tmp@free.fr \
/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.