All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Turquette <mturquette@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Lists linaro-kernel <linaro-kernel@lists.linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Shawn Guo <shawn.guo@linaro.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	Sachin Kamat <spk.linux@gmail.com>,
	"pramod.gurav@smartplayin.com" <pramod.gurav@smartplayin.com>,
	Rob Herring <rob.herring@linaro.org>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Tawfik Bayouk <tawfik@marvell.com>,
	Nadav Haklai <nadavh@marvell.com>,
	Lior Amsalem <alior@marvell.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Tuukka Tikkanen <tuukka.tikkan>
Subject: Re: [PATCH 0/2] allow cpufreq drivers to export flags
Date: Wed, 08 Oct 2014 17:01:23 -0700	[thread overview]
Message-ID: <20141009000123.4379.20957@quantum> (raw)
In-Reply-To: <CAKohpo=7VxrgdK9zPP89Px3aTiGhFihJ3uetC680fONDgE6O8Q@mail.gmail.com>

Quoting Viresh Kumar (2014-10-08 01:19:40)
> On 8 October 2014 13:41, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > On Wed, 8 Oct 2014 13:24:30 +0530, Viresh Kumar wrote:
> >> On 8 October 2014 13:18, Mike Turquette <mturquette@linaro.org> wrote:
> 
> >> > This series is partially in response to a discussion around DT bindings
> >> > for CPUfreq drivers [0], but it is also needed for on-going work to
> >> > integrate CPUfreq with the scheduler. In particular a scheduler-driven
> 
> > Well, when one has to merge a large number of changes, we often
> > recommend to merge them piece by piece, which is what Mike is trying to
> > do here. So we cannot at the same time ask developers to merge things
> > in small pieces that are easy to review and to merge everything
> > together because the users of a given API are not there yet.
> 
> From the wording of Mike it looks like:
> - This is required by cpufreq drivers - today
> - And this will also be useful for scheduler

Hi Viresh and Thomas,

Apologies if my wording was confusing. Without getting into a grammar
war, I did say that these patches were "in response" to this thread
(entirely accurate) and only necessary for the "on-going work" I'm doing
with the scheduler. Sorry if any of that came across as me stating that
these patches were necessary to solve Thomas' problem.

> 
> The first point doesn't stand true anymore. Lets wait for Mike's reply and
> see his opinion.
> 
> And then the patches are so small and there are no objections against
> them. I don't think getting them with the scheduler changes is that bad
> of an idea. In worst case, what if he has to redesign his idea? The new
> routines will stay without a caller then :)

Whether you merge the patches now or later is fine by me. I prefer to
get my patches out early and often so I can avoid any surprises later
on. If you have a fundamental objection to these patches then please let
me know. Otherwise it would be wonderful to have an Ack.

Thanks!
Mike

> 
> --
> viresh

WARNING: multiple messages have this Message-ID (diff)
From: Mike Turquette <mturquette@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>,
	"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Lists linaro-kernel" <linaro-kernel@lists.linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"Shawn Guo" <shawn.guo@linaro.org>,
	"Stephen Boyd" <sboyd@codeaurora.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"Sachin Kamat" <spk.linux@gmail.com>,
	"pramod.gurav@smartplayin.com" <pramod.gurav@smartplayin.com>,
	"Rob Herring" <rob.herring@linaro.org>,
	"Ezequiel Garcia" <ezequiel.garcia@free-electrons.com>,
	"Tawfik Bayouk" <tawfik@marvell.com>,
	"Nadav Haklai" <nadavh@marvell.com>,
	"Lior Amsalem" <alior@marvell.com>,
	"Morten Rasmussen" <morten.rasmussen@arm.com>,
	"Dietmar Eggemann" <dietmar.eggemann@arm.com>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Nicolas Pitre" <nicolas.pitre@linaro.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Tuukka Tikkanen" <tuukka.tikkanen@linaro.org>
Subject: Re: [PATCH 0/2] allow cpufreq drivers to export flags
Date: Wed, 08 Oct 2014 17:01:23 -0700	[thread overview]
Message-ID: <20141009000123.4379.20957@quantum> (raw)
In-Reply-To: <CAKohpo=7VxrgdK9zPP89Px3aTiGhFihJ3uetC680fONDgE6O8Q@mail.gmail.com>

Quoting Viresh Kumar (2014-10-08 01:19:40)
> On 8 October 2014 13:41, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > On Wed, 8 Oct 2014 13:24:30 +0530, Viresh Kumar wrote:
> >> On 8 October 2014 13:18, Mike Turquette <mturquette@linaro.org> wrote:
> 
> >> > This series is partially in response to a discussion around DT bindings
> >> > for CPUfreq drivers [0], but it is also needed for on-going work to
> >> > integrate CPUfreq with the scheduler. In particular a scheduler-driven
> 
> > Well, when one has to merge a large number of changes, we often
> > recommend to merge them piece by piece, which is what Mike is trying to
> > do here. So we cannot at the same time ask developers to merge things
> > in small pieces that are easy to review and to merge everything
> > together because the users of a given API are not there yet.
> 
> From the wording of Mike it looks like:
> - This is required by cpufreq drivers - today
> - And this will also be useful for scheduler

Hi Viresh and Thomas,

Apologies if my wording was confusing. Without getting into a grammar
war, I did say that these patches were "in response" to this thread
(entirely accurate) and only necessary for the "on-going work" I'm doing
with the scheduler. Sorry if any of that came across as me stating that
these patches were necessary to solve Thomas' problem.

> 
> The first point doesn't stand true anymore. Lets wait for Mike's reply and
> see his opinion.
> 
> And then the patches are so small and there are no objections against
> them. I don't think getting them with the scheduler changes is that bad
> of an idea. In worst case, what if he has to redesign his idea? The new
> routines will stay without a caller then :)

Whether you merge the patches now or later is fine by me. I prefer to
get my patches out early and often so I can avoid any surprises later
on. If you have a fundamental objection to these patches then please let
me know. Otherwise it would be wonderful to have an Ack.

Thanks!
Mike

> 
> --
> viresh

  reply	other threads:[~2014-10-09  0:01 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10  4:29 [PATCH] cpufreq: dt: Support platforms with separate clock lines for each CPU Viresh Kumar
2014-09-10  6:29 ` Thomas Petazzoni
2014-09-10  6:42   ` Viresh Kumar
2014-09-10  9:41     ` [PATCH 0/4] cpufreq-dt, platform_data based proposal Thomas Petazzoni
2014-09-10  9:41       ` [PATCH 1/4] cpufreq: allow driver-specific flags Thomas Petazzoni
2014-09-10 10:49         ` Viresh Kumar
2014-09-27 22:44           ` Mike Turquette
2014-09-29  8:54             ` Viresh Kumar
     [not found]               ` <20141005004102.4379.42626@quantum>
2014-10-06  3:56                 ` Viresh Kumar
     [not found]                   ` <20141006183624.4379.26437@quantum>
2014-10-06 18:55                     ` Thomas Petazzoni
2014-10-06 21:44                       ` Mike Turquette
2014-10-07  3:27                         ` Viresh Kumar
2014-10-07  3:25                     ` Viresh Kumar
2014-10-08  7:48                       ` [PATCH 0/2] allow cpufreq drivers to export flags Mike Turquette
2014-10-08  7:48                         ` [PATCH 1/2] cpufreq: add driver flag for sleepable transitions Mike Turquette
2014-10-08  7:48                         ` [PATCH 2/2] cpufreq: new function to query driver for flags Mike Turquette
2014-10-08  7:54                         ` [PATCH 0/2] allow cpufreq drivers to export flags Viresh Kumar
2014-10-08  7:54                           ` Viresh Kumar
2014-10-08  8:11                           ` Thomas Petazzoni
2014-10-08  8:11                             ` Thomas Petazzoni
2014-10-08  8:19                             ` Viresh Kumar
2014-10-08  8:19                               ` Viresh Kumar
2014-10-09  0:01                               ` Mike Turquette [this message]
2014-10-09  0:01                                 ` Mike Turquette
2014-10-09  3:37                                 ` Viresh Kumar
2014-10-09  3:37                                   ` Viresh Kumar
2014-09-10  9:41       ` [PATCH 2/4] cpufreq: cpufreq-dt: extend with platform_data Thomas Petazzoni
2014-09-10  9:41       ` [PATCH 3/4] ARM: mvebu: use the cpufreq-dt platform_data for independent clocks Thomas Petazzoni
2014-09-10  9:41       ` [PATCH 4/4] cpufreq: cpufreq-dt: remove warning about regulators Thomas Petazzoni
2014-09-10 10:30         ` Viresh Kumar
2014-09-10  9:53       ` [PATCH 0/4] cpufreq-dt, platform_data based proposal Arnd Bergmann
2014-09-10 10:10         ` Thomas Petazzoni
2014-09-10 10:19           ` Arnd Bergmann
2014-09-10 10:30             ` Thomas Petazzoni
2014-09-10 18:15         ` Stephen Boyd
2014-09-10 10:38       ` Viresh Kumar
2014-09-10 11:37         ` Thomas Petazzoni
2014-09-10 12:08     ` [PATCHv2 " Thomas Petazzoni
2014-09-10 12:08       ` [PATCHv2 1/4] cpufreq: allow driver-specific data Thomas Petazzoni
2014-09-10 12:08       ` [PATCHv2 2/4] cpufreq: cpufreq-dt: extend with platform_data Thomas Petazzoni
2014-09-10 12:22         ` Viresh Kumar
2014-09-10 12:28           ` Thomas Petazzoni
2014-09-10 12:32             ` Viresh Kumar
2014-09-10 12:36               ` Arnd Bergmann
2014-09-10 12:08       ` [PATCHv2 3/4] ARM: mvebu: use the cpufreq-dt platform_data for independent clocks Thomas Petazzoni
2014-09-10 12:08       ` [PATCHv2 4/4] cpufreq: cpufreq-dt: adjust message related to regulators Thomas Petazzoni
2014-09-10 12:23         ` Viresh Kumar
2014-09-10 12:38       ` [PATCHv2 0/4] cpufreq-dt, platform_data based proposal Viresh Kumar
2014-09-23  9:26       ` Thomas Petazzoni
2014-10-06  7:19       ` Thomas Petazzoni
2014-10-06 22:53         ` Rafael J. Wysocki
2014-10-07  3:30           ` Viresh Kumar
2014-10-07 23:59             ` Rafael J. Wysocki
2014-10-08  5:51               ` Viresh Kumar
2014-10-12 20:25                 ` Rafael J. Wysocki
2014-10-19  9:31                   ` Thomas Petazzoni

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=20141009000123.4379.20957@quantum \
    --to=mturquette@linaro.org \
    --cc=alior@marvell.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=nadavh@marvell.com \
    --cc=nicolas.pitre@linaro.org \
    --cc=pramod.gurav@smartplayin.com \
    --cc=rjw@rjwysocki.net \
    --cc=rob.herring@linaro.org \
    --cc=sboyd@codeaurora.org \
    --cc=shawn.guo@linaro.org \
    --cc=spk.linux@gmail.com \
    --cc=tawfik@marvell.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=vincent.guittot@linaro.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.