announcing the clk-next branch

announcing the clk-next branch

[Turquette, Mike]

Hi all,

The clock patches that I have signed-off on and picked from the list
are all rebased on top of 3.4-rc4.  They can be found here:

git://git.linaro.org/people/mturquette/linux.git clk-next

If the branch is missing anything that I have ACK'd then please let me know.

The obvious thing missing are the recent platform ports.  Those folks
probably want to test on top of this branch first so it seemed
premature for me to pull them.  After the recent platform ports go in
then I'll ask for this to head into linux-next.

Regards,
Mike

announcing the clk-next branch

[Sascha Hauer]

On Tue, Apr 24, 2012 at 06:32:20PM -0700, Turquette, Mike wrote:
> Hi all,
> 
> The clock patches that I have signed-off on and picked from the list
> are all rebased on top of 3.4-rc4.  They can be found here:
> 
> git://git.linaro.org/people/mturquette/linux.git clk-next

Thanks Mike!

> 
> If the branch is missing anything that I have ACK'd then please let me know.

You haven't acked it, but for i.MX I need two patches from Viresh I'd
like to base on:

[PATCH V3 1/8] CLKDEV: Add helper routines to allocate and add clkdevs for given struct clk *
[PATCH V3 2/8] clk: add a fixed factor clock

Also I need the patch implementing managed clk_get which currently sits
in Russells tree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

announcing the clk-next branch

[Russell King - ARM Linux]

On Wed, Apr 25, 2012 at 02:38:28PM +0200, Sascha Hauer wrote:
> On Tue, Apr 24, 2012 at 06:32:20PM -0700, Turquette, Mike wrote:
> > Hi all,
> > 
> > The clock patches that I have signed-off on and picked from the list
> > are all rebased on top of 3.4-rc4.  They can be found here:
> > 
> > git://git.linaro.org/people/mturquette/linux.git clk-next
> 
> Thanks Mike!
> 
> > 
> > If the branch is missing anything that I have ACK'd then please let me know.
> 
> You haven't acked it, but for i.MX I need two patches from Viresh I'd
> like to base on:
> 
> [PATCH V3 1/8] CLKDEV: Add helper routines to allocate and add clkdevs for given struct clk *
> [PATCH V3 2/8] clk: add a fixed factor clock
> 
> Also I need the patch implementing managed clk_get which currently sits
> in Russells tree.

Well, some of this stuff is already committed in my tree.  There's total
confusion at the moment over who's looking after clk API stuff - I'm
listed as the official maintainer for linux/clk.h and clkdev, but Mike
is clearly the guy doing all the common stuff.

What would not be a good idea is to have the same patches committed
independently into two different trees.

announcing the clk-next branch

[Turquette, Mike]

On Wed, Apr 25, 2012 at 5:42 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Apr 25, 2012 at 02:38:28PM +0200, Sascha Hauer wrote:
>> On Tue, Apr 24, 2012 at 06:32:20PM -0700, Turquette, Mike wrote:
>> > Hi all,
>> >
>> > The clock patches that I have signed-off on and picked from the list
>> > are all rebased on top of 3.4-rc4. ?They can be found here:
>> >
>> > git://git.linaro.org/people/mturquette/linux.git clk-next
>>
>> Thanks Mike!
>>
>> >
>> > If the branch is missing anything that I have ACK'd then please let me know.
>>
>> You haven't acked it, but for i.MX I need two patches from Viresh I'd
>> like to base on:
>>
>> [PATCH V3 1/8] CLKDEV: Add helper routines to allocate and add clkdevs for given struct clk *
>> [PATCH V3 2/8] clk: add a fixed factor clock
>>
>> Also I need the patch implementing managed clk_get which currently sits
>> in Russells tree.
>
> Well, some of this stuff is already committed in my tree. ?There's total
> confusion at the moment over who's looking after clk API stuff - I'm
> listed as the official maintainer for linux/clk.h and clkdev, but Mike
> is clearly the guy doing all the common stuff.
>
> What would not be a good idea is to have the same patches committed
> independently into two different trees.

What is the best solution here?

I can base my branch on top of one of yours if the goal is to have
clk-next be a one-stop-shop for folks trying to port their platforms
over to the new struct clk.

On the other hand maybe the platform folks that are trying to convert
to struct clk should just base their work on top of your for-next
branch and my clk-next, merged locally.

In the mean time I'll go through my branch today and see which patches
collide with ones you have already merged.  My branch is quite small
(less than two dozen patches) so removing collisions will be easy.

Regards,
Mike

announcing the clk-next branch

[Viresh Kumar]

On 4/25/2012 7:02 AM, Turquette, Mike wrote:
> Hi all,
> 
> The clock patches that I have signed-off on and picked from the list
> are all rebased on top of 3.4-rc4.  They can be found here:
> 
> git://git.linaro.org/people/mturquette/linux.git clk-next
> 
> If the branch is missing anything that I have ACK'd then please let me know.
> 
> The obvious thing missing are the recent platform ports.  Those folks
> probably want to test on top of this branch first so it seemed
> premature for me to pull them.  After the recent platform ports go in
> then I'll ask for this to head into linux-next.

I want to understand a bit about how these patches go to linux-next.
Mike would be sleeping right now, so will not disturb him ;)

Arnd,

Can you please help?

Just like Mike, you also asked me to base my patches on an rc release.
Now, few of the dependency patches are there in linux-next that i would need.
Some under my authorship, and some from others. And this number can be 30-50.

Should i ask Mike to apply all of them first and then my patches OR do that
myself and send a pull request. Which would mean all patches, that weren't
related to my patchset also get pushed through my branch. Isn't that a problem?

-- 
viresh

announcing the clk-next branch

[Arnd Bergmann]

On Thursday 26 April 2012, Viresh Kumar wrote:
> I want to understand a bit about how these patches go to linux-next.
> Mike would be sleeping right now, so will not disturb him ;)
> 
> Arnd,
> 
> Can you please help?
> 
> Just like Mike, you also asked me to base my patches on an rc release.
> Now, few of the dependency patches are there in linux-next that i would need.
> Some under my authorship, and some from others. And this number can be 30-50.
> 
> Should i ask Mike to apply all of them first and then my patches OR do that
> myself and send a pull request. Which would mean all patches, that weren't
> related to my patchset also get pushed through my branch. Isn't that a problem?

Sorry for the late reply on my side. I'm not sure if I understand your
question correctly. Generally the rule is to not apply the same patch to
two separate branches because that can result in merge conflicts and/or an
unclean history.

The way to deal with dependencies in a case like this is to apply the patches
on one branch in the right order and ask different people to include parts of
that branch in their trees without rebasing.

For instance, you can take Mike's branch as a base (as long as he promises
to never rebase that branch), add some patches on top and ask him to pull that
commit with your additional clk patches. Then you add other patches for arm-soc
on top of that and ask me to pull that branch, including the clk commits that
originally came from Mike.

I can then pull the branch into one of the arm-soc branches that gets sent to
Linus after the clk tree was merged into v3.5-rc1.

It also works the other way round: You can base on top of patches that are
already in arm-soc, add more stuff that should go into arm-soc on top, and
add clk patches for Mike on top of that, which means that in the end, the
arm-soc tree has to go to Linus before the clk tree does.

The tricky part here is to avoid circular dependencies.

	Arnd

announcing the clk-next branch

[viresh kumar]

On Mon, Apr 30, 2012 at 8:11 PM, Arnd Bergmann <arnd.bergmann@linaro.org> wrote:
> Sorry for the late reply on my side. I'm not sure if I understand your
> question correctly. Generally the rule is to not apply the same patch to
> two separate branches because that can result in merge conflicts and/or an
> unclean history.

No Probs.

> The way to deal with dependencies in a case like this is to apply the patches
> on one branch in the right order and ask different people to include parts of
> that branch in their trees without rebasing.
>
> For instance, you can take Mike's branch as a base (as long as he promises
> to never rebase that branch), add some patches on top and ask him to pull that
> commit with your additional clk patches. Then you add other patches for arm-soc
> on top of that and ask me to pull that branch, including the clk commits that
> originally came from Mike.
>
> I can then pull the branch into one of the arm-soc branches that gets sent to
> Linus after the clk tree was merged into v3.5-rc1.
>
> It also works the other way round: You can base on top of patches that are
> already in arm-soc, add more stuff that should go into arm-soc on top, and
> add clk patches for Mike on top of that, which means that in the end, the
> arm-soc tree has to go to Linus before the clk tree does.
>
> The tricky part here is to avoid circular dependencies.

Can you please check my new PULL requests sent few minutes back.
I hope, i haven't done anything wrong this time. :)

--
viresh

announcing the clk-next branch

[Arnd Bergmann]

On Monday 30 April 2012, viresh kumar wrote:
> 
> Can you please check my new PULL requests sent few minutes back.
> I hope, i haven't done anything wrong this time. :)

Looks good to at first sight. So the plan is that both of these
go through arm-soc and any other patches that might be required for
the pinctrl or clk tree will be based on these?

	Arnd

announcing the clk-next branch

[viresh kumar]

On Mon, Apr 30, 2012 at 10:07 PM, Arnd Bergmann
<arnd.bergmann@linaro.org> wrote:
> Looks good to at first sight.

Ahh!! Great.

> So the plan is that both of these
> go through arm-soc and any other patches that might be required for
> the pinctrl or clk tree will be based on these?

Ya. So, it would be great if this can be applied ASAP, as Sascha would also
require, few patches from clk-branch.

--
viresh

announcing the clk-next branch

[Arnd Bergmann]

On Monday 30 April 2012, viresh kumar wrote:
> On Mon, Apr 30, 2012 at 10:07 PM, Arnd Bergmann
> <arnd.bergmann@linaro.org> wrote:
> > Looks good to at first sight.
> 
> Ahh!! Great.
> 
> > So the plan is that both of these
> > go through arm-soc and any other patches that might be required for
> > the pinctrl or clk tree will be based on these?
> 
> Ya. So, it would be great if this can be applied ASAP, as Sascha would also
> require, few patches from clk-branch.
> 

I've got to run now, but I'll try to apply them in the next hour while on the
train.

	Arnd

announcing the clk-next branch

[Viresh Kumar]

On 4/25/2012 7:02 AM, Turquette, Mike wrote:
> If the branch is missing anything that I have ACK'd then please let me know.

Author: Viresh Kumar <viresh.kumar@st.com>
Date:   Wed Apr 11 11:34:35 2012 +0530

    clk: clk_set_rate() must fail if CLK_SET_RATE_GATE is set and clk is enabled
    
    This is well documented but isn't implemented. clk_set_rate() must check if
    flags have CLK_SET_RATE_GATE bit set and is enabled too.
    
    Untested patch.
    
    Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
---
 drivers/clk/clk.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 865d0dd..2bcce5a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -898,6 +898,11 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
        if (rate == clk->rate)
                goto out;
 
+       if ((clk->flags & CLK_SET_RATE_GATE) && __clk_is_enabled(clk)) {
+               ret = -EBUSY;
+               goto out;
+       }
+


-- 
viresh

announcing the clk-next branch

[Viresh Kumar]

On 4/25/2012 7:02 AM, Turquette, Mike wrote:
> The obvious thing missing are the recent platform ports.  Those folks
> probably want to test on top of this branch first so it seemed
> premature for me to pull them.  After the recent platform ports go in
> then I'll ask for this to head into linux-next.

Hi Mike and others,

I am finding difficulty in creating branch to be pulled in by Mike for clock
stuff. Somebody please help.

SPEAr patches have dependency on few patchsets that are pulled in linux-next
already.
- SPEAr DT support
- SPEAr Pinctrl support
- Mike clk fixes
- Misc Pinctrl patches

Now, how should i create branch for SPEAr clk stuff over these dependencies?
I tried to create a merge of first 3, but couldn't get a linux-next/master
sha of a branch for Last dependency.

Should i cherrypick that one?

At last, i believe this branch, that i would create, must be in a compilable
state? So, i can't just send a pull request for my clock patches rebased over
Mike's branch directly?

-- 
viresh

announcing the clk-next branch

[Shawn Guo]

On Fri, Apr 27, 2012 at 11:44:50AM +0530, Viresh Kumar wrote:
> Hi Mike and others,
> 
> I am finding difficulty in creating branch to be pulled in by Mike for clock
> stuff. Somebody please help.
> 
> SPEAr patches have dependency on few patchsets that are pulled in linux-next
> already.
> - SPEAr DT support
> - SPEAr Pinctrl support
> - Mike clk fixes
> - Misc Pinctrl patches
> 
I'm basically running into the same situation.  I have a bunch of mxs DT
patches touching the existing clock code, while I'm converting the clock
to framework and put the code into drivers/clk.  I originally thought
that the new mxs clock should go through Mike's tree since they are
sitting in drivers/clk.  But with a second thought, I feel it might be
easier to still have them go through arm-soc tree.

We can ask Arnd, Olof to pull clkdev from Russell, clk core from Mike,
and pinctrl from Linus into arm-soc as dependencies, take all the
platform clock/pinctrl porting into arm-soc, and sort out the conflicts
in arm-soc tree.  Otherwise, I'm a little worried about that we will
probably upset Torvalds with leaving so many conflicts to him.

So in short, I will send my mxs clock series to Arnd and Olof.

Regards,
Shawn

> Now, how should i create branch for SPEAr clk stuff over these dependencies?
> I tried to create a merge of first 3, but couldn't get a linux-next/master
> sha of a branch for Last dependency.
> 
> Should i cherrypick that one?
> 
> At last, i believe this branch, that i would create, must be in a compilable
> state? So, i can't just send a pull request for my clock patches rebased over
> Mike's branch directly?

announcing the clk-next branch

[Turquette, Mike]

On Fri, Apr 27, 2012 at 12:09 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Fri, Apr 27, 2012 at 11:44:50AM +0530, Viresh Kumar wrote:
>> Hi Mike and others,
>>
>> I am finding difficulty in creating branch to be pulled in by Mike for clock
>> stuff. Somebody please help.
>>
>> SPEAr patches have dependency on few patchsets that are pulled in linux-next
>> already.
>> - SPEAr DT support
>> - SPEAr Pinctrl support
>> - Mike clk fixes
>> - Misc Pinctrl patches
>>
> I'm basically running into the same situation. ?I have a bunch of mxs DT
> patches touching the existing clock code, while I'm converting the clock
> to framework and put the code into drivers/clk. ?I originally thought
> that the new mxs clock should go through Mike's tree since they are
> sitting in drivers/clk. ?But with a second thought, I feel it might be
> easier to still have them go through arm-soc tree.
>
> We can ask Arnd, Olof to pull clkdev from Russell, clk core from Mike,
> and pinctrl from Linus into arm-soc as dependencies, take all the
> platform clock/pinctrl porting into arm-soc, and sort out the conflicts
> in arm-soc tree. ?Otherwise, I'm a little worried about that we will
> probably upset Torvalds with leaving so many conflicts to him.

Arnd & Olof,

Are you guys OK with this?  I'm OK with you pulling clk-next as a
dependency if it reduces merge confusion.

Would I be allowed to rebase clk-next, or must it be stable?  If I
cannot rebase it then I need a bit of time to remove the conflicting
clkdev patches that Russell mentioned are already merged through him.

Thanks,
Mike

> So in short, I will send my mxs clock series to Arnd and Olof.
>
> Regards,
> Shawn
>
>> Now, how should i create branch for SPEAr clk stuff over these dependencies?
>> I tried to create a merge of first 3, but couldn't get a linux-next/master
>> sha of a branch for Last dependency.
>>
>> Should i cherrypick that one?
>>
>> At last, i believe this branch, that i would create, must be in a compilable
>> state? So, i can't just send a pull request for my clock patches rebased over
>> Mike's branch directly?

announcing the clk-next branch

[Shawn Guo]

On Fri, Apr 27, 2012 at 10:54:42AM -0700, Turquette, Mike wrote:
> Would I be allowed to rebase clk-next, or must it be stable?  If I
> cannot rebase it then I need a bit of time to remove the conflicting
> clkdev patches that Russell mentioned are already merged through him.
> 
Any branch that appears on arm-soc tree as a dependency should be
stable, I think.

-- 
Regards,
Shawn

announcing the clk-next branch

[Arnd Bergmann]

On Friday 27 April 2012, Turquette, Mike wrote:
> Are you guys OK with this?  I'm OK with you pulling clk-next as a
> dependency if it reduces merge confusion.
> 
> Would I be allowed to rebase clk-next, or must it be stable?  If I
> cannot rebase it then I need a bit of time to remove the conflicting
> clkdev patches that Russell mentioned are already merged through him.

Anything you pull in as a dependency or that gets pulled from your
tree into another one must not be rebased. It helps to ask the person
whose tree you're pulling whether that tree is already considered stable.

	Arnd