On 09/05/2014 05:34 PM, Lorenzo Pieralisi wrote:
On Fri, Sep 05, 2014 at 10:21:20AM +0100, Will Deacon wrote:
On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
This patch should be ready to go too, is it ok if I split the series
in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
(inclusive of DT bindings and !!this patch!!) and send two separate pull
requests ?
If Daniel/Rafael don't have any objection, I can take the whole series
through the arm64 tree (it seems that patches have been already acked by
Daniel).
Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
follows a different pattern from arm legacy drivers I would like to get
Daniel's ack on this patch too before pushing it. For the records I have
just added two pr_err to signal driver probing error, ultraminor changes
that do not justify a repost.
If Samsung guys do not manifest themselves I would drop patch 8 from
the series till it gets tested and its patch dependency queued too.
The last patch also has a dependency, as you mentioned to Daniel. I think
we can certainly merge the arm64 parts, and if Daniel doesn't object, then
we can take the driver stuff too but leaving the exynos bits out (i.e. drop
the last patch).
Anyway, if you could repost with the acks you've collected and rearrange it
so the arm64 patches are first in the series, that would be great.
I can repost it with the acks and rearrange the patches, but for the
pull request I have to know what code can be merged, since there are
some arm64 patches (PSCI and CPUidle arm64 back-end) that are strictly
tied to the arm64 CPUidle driver, so I *have* to know if the arm64
CPUidle driver (this patch) can get merged and that requires an ack.
If I do not hear from Samsung guys I will drop patch 8.
Well I would prefer to have this patch merged (Cc'ing Tomasz).
I will wait till Monday (ie -rc4) and repost, I hope that's acceptable.
There is a procedure to solve this branch dependency.
1. Create a patchset with only the changes in drivers/cpuidle (+ misc dt
stuff)
2. Send the patchset to me.
3. I create a branch with these patches (which will be merged in my
cpuidle next branch)
4. Merge this branch to a new branch (based on 3.17-rcX) and put on top
of that your changes for ARM[64]
5. Send the PR to Catalin and Arnd (one for each branch or one for both
arch)
I will ensure the base branch is not removed until the next merge window.
Does it sound good ?
-- 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
