From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Jason Cooper <jason@lakedaemon.net>
Cc: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
Kevin Hilman <khilman@linaro.org>,
arm@kernel.org, Viresh Kumar <viresh.kumar@linaro.org>,
Andrew Lunn <andrew@lunn.ch>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>,
Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>,
linux-pm@vger.kernel.org
Subject: Re: mvebu cpuidle and cpufreq branch handling for v3.17
Date: Sat, 19 Jul 2014 01:36:23 +0200 [thread overview]
Message-ID: <53C9AF77.3030104@linaro.org> (raw)
In-Reply-To: <4295346.6091tevmKX@vostro.rjw.lan>
On 07/19/2014 01:51 AM, Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 07:07:40 PM Jason Cooper wrote:
>> Arnd, Olof, Kevin,
>>
>> I have two branches with the remaining mvebu SoC changes for v3.17.
>> They are mvebu/soc-cpuidle and mvebu/soc-cpufreq. Each branch is
>> slightly problematic because both contain changes to their respective
>> code in drivers/. To send the driver changes through the appropriate
>> subsystems would be a garish nightmare of branch on branch on branch.
>> Thankfully, the changes are isolated to drivers only mvebu uses, so
>> keeping it all together should cause minimal, if any, conflicts.
>>
>> I've requested Acks from the appropriate maintainers but as it's summer
>> I'm not confident that we'll receive those Acks in time for the arm-soc
>> cutoff (-rc6 -ish).
>>
>> As I see it, I could send arm-soc two topic branch pull requests, which
>> arm-soc would keep out separate on the remote chance of an objection.
>>
>> Or, I could wait for the Acks (the code has already been in -next for
>> several days), merge it into mvebu/soc, and send a, most likely, late
>> pull request for it.
>>
>> Which would you guys prefer?
>>
>> The cpuidle branch and ML link:
>>
>> git://git.infradead.org/linux-mvebu.git mvebu/soc-cpuidle
>>
>> https://lkml.kernel.org/r/1404913221-17343-1-git-send-email-thomas.petazzoni@free-electrons.com
>>
>> The cpufreq branch and ML link:
>>
>> git://git.infradead.org/linux-mvebu.git mvebu/soc-cpufreq
>>
>> https://lkml.kernel.org/r/1404920715-19834-1-git-send-email-thomas.petazzoni@free-electrons.com
>
> I'm generally OK with the cpufreq/cpuidle changes here in drivers/, but as I
> said in response to the cpuidle series, I'd like someone from the ARM side of
> things to look at those changes too.
I am currently in vacation. I will be back Monday and look at this patchset.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: mvebu cpuidle and cpufreq branch handling for v3.17
Date: Sat, 19 Jul 2014 01:36:23 +0200 [thread overview]
Message-ID: <53C9AF77.3030104@linaro.org> (raw)
In-Reply-To: <4295346.6091tevmKX@vostro.rjw.lan>
On 07/19/2014 01:51 AM, Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 07:07:40 PM Jason Cooper wrote:
>> Arnd, Olof, Kevin,
>>
>> I have two branches with the remaining mvebu SoC changes for v3.17.
>> They are mvebu/soc-cpuidle and mvebu/soc-cpufreq. Each branch is
>> slightly problematic because both contain changes to their respective
>> code in drivers/. To send the driver changes through the appropriate
>> subsystems would be a garish nightmare of branch on branch on branch.
>> Thankfully, the changes are isolated to drivers only mvebu uses, so
>> keeping it all together should cause minimal, if any, conflicts.
>>
>> I've requested Acks from the appropriate maintainers but as it's summer
>> I'm not confident that we'll receive those Acks in time for the arm-soc
>> cutoff (-rc6 -ish).
>>
>> As I see it, I could send arm-soc two topic branch pull requests, which
>> arm-soc would keep out separate on the remote chance of an objection.
>>
>> Or, I could wait for the Acks (the code has already been in -next for
>> several days), merge it into mvebu/soc, and send a, most likely, late
>> pull request for it.
>>
>> Which would you guys prefer?
>>
>> The cpuidle branch and ML link:
>>
>> git://git.infradead.org/linux-mvebu.git mvebu/soc-cpuidle
>>
>> https://lkml.kernel.org/r/1404913221-17343-1-git-send-email-thomas.petazzoni at free-electrons.com
>>
>> The cpufreq branch and ML link:
>>
>> git://git.infradead.org/linux-mvebu.git mvebu/soc-cpufreq
>>
>> https://lkml.kernel.org/r/1404920715-19834-1-git-send-email-thomas.petazzoni at free-electrons.com
>
> I'm generally OK with the cpufreq/cpuidle changes here in drivers/, but as I
> said in response to the cpuidle series, I'd like someone from the ARM side of
> things to look at those changes too.
I am currently in vacation. I will be back Monday and look at this patchset.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2014-07-18 23:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-18 23:07 mvebu cpuidle and cpufreq branch handling for v3.17 Jason Cooper
2014-07-18 23:07 ` Jason Cooper
2014-07-18 23:51 ` Rafael J. Wysocki
2014-07-18 23:51 ` Rafael J. Wysocki
2014-07-18 23:36 ` Daniel Lezcano [this message]
2014-07-18 23:36 ` Daniel Lezcano
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=53C9AF77.3030104@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=andrew@lunn.ch \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=olof@lixom.net \
--cc=rjw@rjwysocki.net \
--cc=sebastian.hesselbarth@googlemail.com \
--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.