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
prev parent reply other threads:[~2014-07-18 23:36 UTC|newest]
Thread overview: 3+ 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:51 ` Rafael J. Wysocki
2014-07-18 23:36 ` Daniel Lezcano [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox