From: Viresh Kumar <viresh.kumar@linaro.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: devicetree@vger.kernel.org, kernel@stlinux.com,
linux-pm@vger.kernel.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, ajitpal.singh@st.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/9] cpufreq: Introduce support for ST's cpufreq functionality
Date: Wed, 8 Jul 2015 16:42:59 +0530 [thread overview]
Message-ID: <20150708111259.GC1805@linux> (raw)
In-Reply-To: <20150708105958.GO3182@x1>
On 08-07-15, 11:59, Lee Jones wrote:
> No problem. So long as it's still on your radar.
So, for the first 7 patches:
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
but for the last two:
- I thought we agreed that you will have a look at opp-v2 bindings and
create your new bindings as an extension of those ? As we support
extending opp-v2 bindings per vendor basis.
- And I don't really think you need to create a device for your STM
driver, why not move your stm-cpufreq file to arch/arm/- and call it
from .init_late, from where you call init_cpufreq() today. Your
driver doesn't have anything related to cpufreq-core really and
isn't required to stay in drivers/cpufreq, unless you want it that
way.
I haven't reviewed the driver yet and waiting for an answer to opp-v2
question I asked above. opp-v2 is created because we didn't wanted
platforms to create new separate bindings for OPPs :)
--
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 v2 0/9] cpufreq: Introduce support for ST's cpufreq functionality
Date: Wed, 8 Jul 2015 16:42:59 +0530 [thread overview]
Message-ID: <20150708111259.GC1805@linux> (raw)
In-Reply-To: <20150708105958.GO3182@x1>
On 08-07-15, 11:59, Lee Jones wrote:
> No problem. So long as it's still on your radar.
So, for the first 7 patches:
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
but for the last two:
- I thought we agreed that you will have a look at opp-v2 bindings and
create your new bindings as an extension of those ? As we support
extending opp-v2 bindings per vendor basis.
- And I don't really think you need to create a device for your STM
driver, why not move your stm-cpufreq file to arch/arm/- and call it
from .init_late, from where you call init_cpufreq() today. Your
driver doesn't have anything related to cpufreq-core really and
isn't required to stay in drivers/cpufreq, unless you want it that
way.
I haven't reviewed the driver yet and waiting for an answer to opp-v2
question I asked above. opp-v2 is created because we didn't wanted
platforms to create new separate bindings for OPPs :)
--
viresh
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@stlinux.com,
rjw@rjwysocki.net, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, ajitpal.singh@st.com
Subject: Re: [PATCH v2 0/9] cpufreq: Introduce support for ST's cpufreq functionality
Date: Wed, 8 Jul 2015 16:42:59 +0530 [thread overview]
Message-ID: <20150708111259.GC1805@linux> (raw)
In-Reply-To: <20150708105958.GO3182@x1>
On 08-07-15, 11:59, Lee Jones wrote:
> No problem. So long as it's still on your radar.
So, for the first 7 patches:
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
but for the last two:
- I thought we agreed that you will have a look at opp-v2 bindings and
create your new bindings as an extension of those ? As we support
extending opp-v2 bindings per vendor basis.
- And I don't really think you need to create a device for your STM
driver, why not move your stm-cpufreq file to arch/arm/- and call it
from .init_late, from where you call init_cpufreq() today. Your
driver doesn't have anything related to cpufreq-core really and
isn't required to stay in drivers/cpufreq, unless you want it that
way.
I haven't reviewed the driver yet and waiting for an answer to opp-v2
question I asked above. opp-v2 is created because we didn't wanted
platforms to create new separate bindings for OPPs :)
--
viresh
next prev parent reply other threads:[~2015-07-08 11:12 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-24 13:58 [PATCH v2 0/9] cpufreq: Introduce support for ST's cpufreq functionality Lee Jones
2015-06-24 13:58 ` Lee Jones
2015-06-24 13:58 ` Lee Jones
2015-06-24 13:59 ` [PATCH v2 1/9] ARM: STi: STiH407: Provide generic (safe) DVFS configuration Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 13:59 ` [PATCH v2 2/9] ARM: STi: STiH407: Provide CPU with clocking information Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 13:59 ` [PATCH v2 3/9] ARM: STi: STiH407: Link CPU with its voltage supply Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 13:59 ` [PATCH v2 4/9] ARM: STi: STiH407: Provide CPU with a means to look-up Major number Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 13:59 ` [PATCH v2 5/9] ARM: STi: Register CPUFreq device Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 13:59 ` [PATCH v2 6/9] ARM: STi: STiH407: Move PWM nodes STiH407 => STiH407-family Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 13:59 ` [PATCH v2 8/9] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 13:59 ` [PATCH v2 9/9] cpufreq: st: Provide runtime initialised driver for ST's platforms Lee Jones
2015-06-24 13:59 ` Lee Jones
[not found] ` <1435154348-28840-1-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-24 13:59 ` [PATCH v2 7/9] ARM: multi_v7_defconfig: Enable support for PWM Regulators Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 13:59 ` Lee Jones
2015-06-24 14:52 ` Javier Martinez Canillas
2015-06-24 14:52 ` Javier Martinez Canillas
2015-06-25 8:42 ` Lee Jones
2015-06-25 8:42 ` Lee Jones
2015-06-25 9:18 ` Javier Martinez Canillas
2015-06-25 9:18 ` Javier Martinez Canillas
2015-06-25 15:02 ` Lee Jones
2015-06-25 15:02 ` Lee Jones
2015-06-25 16:29 ` Javier Martinez Canillas
2015-06-25 16:29 ` Javier Martinez Canillas
2015-07-01 12:31 ` Lee Jones
2015-07-01 12:31 ` Lee Jones
2015-07-08 10:50 ` [PATCH v2 0/9] cpufreq: Introduce support for ST's cpufreq functionality Viresh Kumar
2015-07-08 10:50 ` Viresh Kumar
2015-07-08 10:50 ` Viresh Kumar
2015-07-08 10:59 ` Lee Jones
2015-07-08 10:59 ` Lee Jones
2015-07-08 11:12 ` Viresh Kumar [this message]
2015-07-08 11:12 ` Viresh Kumar
2015-07-08 11:12 ` 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=20150708111259.GC1805@linux \
--to=viresh.kumar@linaro.org \
--cc=ajitpal.singh@st.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@stlinux.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/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.