[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Sebastian Hesselbarth]

On 06/12/2013 09:59 PM, Daniel Lezcano wrote:
>
> The following changes since commit 762cf9695d714d312ef7369bed1b9f9467c9e64e:
>
>    Merge branch 'timers/clockevents' of
> git://git.linaro.org/people/dlezcano/clockevents into timers/core
> (2013-06-08 22:58:27 +0200)
>
> are available in the git repository at:
>
>
>    git://git.linaro.org/people/dlezcano/clockevents.git timers/clockevents
>
> for you to fetch changes up to fbb3cb01505e7365c70a7fe680e10ffff3175160:
>
>    clocksource: Add Marvell Orion SoC timer (2013-06-11 14:41:01 +0200)
>
> ----------------------------------------------------------------
> Sebastian Hesselbarth (1):
>        clocksource: Add Marvell Orion SoC timer

Thomas, John,

with tip timers/core PR sent, I realized that the above did not make it
in. As we have a whole bunch of cleanup and DT conversion patches for
v3.11-rc1 depending on it, would it be ok for you to let Jason Cooper
take it through his ARM sub-branch?

If you are fine with it, I will resend the patch and note that Daniel
can drop it and Jason will take it.

Sebastian

>   .../bindings/timer/marvell,orion-timer.txt         |   17 +++
>   drivers/clocksource/Kconfig                        |    5 +
>   drivers/clocksource/Makefile                       |    1 +
>   drivers/clocksource/time-orion.c                   |  150
> ++++++++++++++++++++
>   4 files changed, 173 insertions(+)
>   create mode 100644
> Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
>   create mode 100644 drivers/clocksource/time-orion.c

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Thomas Gleixner]

On Sun, 7 Jul 2013, Sebastian Hesselbarth wrote:
> > ----------------------------------------------------------------
> > Sebastian Hesselbarth (1):
> >        clocksource: Add Marvell Orion SoC timer
> 
> with tip timers/core PR sent, I realized that the above did not make it
> in. As we have a whole bunch of cleanup and DT conversion patches for

Opps. Fell through the cracks.

> v3.11-rc1 depending on it, would it be ok for you to let Jason Cooper
> take it through his ARM sub-branch?

> If you are fine with it, I will resend the patch and note that Daniel
> can drop it and Jason will take it.

Nah, Jason can just pull it from Daniels tree and be done with it.

Thanks,

	tglx

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Jason Cooper]

Thomas,

On Sun, Jul 07, 2013 at 03:10:25PM +0200, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Sebastian Hesselbarth wrote:
> > > ----------------------------------------------------------------
> > > Sebastian Hesselbarth (1):
> > >        clocksource: Add Marvell Orion SoC timer
> > 
> > with tip timers/core PR sent, I realized that the above did not make it
> > in. As we have a whole bunch of cleanup and DT conversion patches for
> 
> Opps. Fell through the cracks.

No problem.

> > v3.11-rc1 depending on it, would it be ok for you to let Jason Cooper
> > take it through his ARM sub-branch?
> 
> > If you are fine with it, I will resend the patch and note that Daniel
> > can drop it and Jason will take it.
> 
> Nah, Jason can just pull it from Daniels tree and be done with it.

Sure, but to be clear, Daniel, please drop this patch from your tree.  I
have no desire to create an out-of-tree dependency if we can avoid it.
It has a habit of going horribly wrong [1].

I'll cherry-pick

  0c1dcfd clocksource: Add Marvell Orion SoC timer

from dlezcano/timers/clockevents to get the Signed-off-by's Tested-by's,
etc.  If I could get an Acked-by from Daniel or Thomas on this, I'd
appreciate it.

Daniel, it looks like you only have cpuidle work going into linux-next.
If you do decide to include timers/clockevents, please drop the patch
before hand.

thx,

Jason.

[1] https://lkml.org/lkml/2013/2/28/725

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Thomas Gleixner]

On Sun, 7 Jul 2013, Jason Cooper wrote:
> Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> have no desire to create an out-of-tree dependency if we can avoid it.
> It has a habit of going horribly wrong [1].
> 
> I'll cherry-pick
> 
>   0c1dcfd clocksource: Add Marvell Orion SoC timer

Don't do that. Do a git fetch on that branch and then git merge
0c1dcfd. The patches before that Marvel commit are already in Linus
tree. That way it does not matter who sends first or not.

We don't force others to drop stuff and cherry picking is a nuisance
as well as you end up with two different commits doing the same thing.

Also for the next merge window: Can we please let everything under
drivers/clocksoure go through Daniels and my trees?

I'm starting to be grumpy about anyone thinking that this directory is
a public dump ground with no rules.

Thanks,

	tglx

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Daniel Lezcano]

On 07/07/2013 05:30 PM, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
>> Sure, but to be clear, Daniel, please drop this patch from your tree.  I
>> have no desire to create an out-of-tree dependency if we can avoid it.
>> It has a habit of going horribly wrong [1].
>>
>> I'll cherry-pick
>>
>>   0c1dcfd clocksource: Add Marvell Orion SoC timer
> 
> Don't do that. Do a git fetch on that branch and then git merge
> 0c1dcfd. The patches before that Marvel commit are already in Linus
> tree. That way it does not matter who sends first or not.
> 
> We don't force others to drop stuff and cherry picking is a nuisance
> as well as you end up with two different commits doing the same thing.
> 
> Also for the next merge window: Can we please let everything under
> drivers/clocksoure go through Daniels and my trees?
> 
> I'm starting to be grumpy about anyone thinking that this directory is
> a public dump ground with no rules.

Yes I agree. I will meet John this week and we will sort out this and
define a clear set of rules to prevent that to happen again.

  -- 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

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Jason Cooper]

On Sun, Jul 07, 2013 at 06:45:15PM +0200, Daniel Lezcano wrote:
> On 07/07/2013 05:30 PM, Thomas Gleixner wrote:
> > On Sun, 7 Jul 2013, Jason Cooper wrote:
> >> Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> >> have no desire to create an out-of-tree dependency if we can avoid it.
> >> It has a habit of going horribly wrong [1].
> >>
> >> I'll cherry-pick
> >>
> >>   0c1dcfd clocksource: Add Marvell Orion SoC timer
> > 
> > Don't do that. Do a git fetch on that branch and then git merge
> > 0c1dcfd. The patches before that Marvel commit are already in Linus
> > tree. That way it does not matter who sends first or not.
> > 
> > We don't force others to drop stuff and cherry picking is a nuisance
> > as well as you end up with two different commits doing the same thing.
> > 
> > Also for the next merge window: Can we please let everything under
> > drivers/clocksoure go through Daniels and my trees?
> > 
> > I'm starting to be grumpy about anyone thinking that this directory is
> > a public dump ground with no rules.
> 
> Yes I agree. I will meet John this week and we will sort out this and
> define a clear set of rules to prevent that to happen again.

Oh god no!  The rules we have are fine.  "Defer to the appropriate
maintainer first."  Which I did (that's why the patch is in your tree
;-) ).  A mistake happened, and we're working together to find the best
solution.

The last thing we need is more bureaucratic crap.

thx,

Jason.

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Jason Cooper]

On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
> > Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> > have no desire to create an out-of-tree dependency if we can avoid it.
> > It has a habit of going horribly wrong [1].
> > 
> > I'll cherry-pick
> > 
> >   0c1dcfd clocksource: Add Marvell Orion SoC timer
> 
> Don't do that. Do a git fetch on that branch and then git merge
> 0c1dcfd.

> The patches before that Marvel commit are already in Linus tree. That
> way it does not matter who sends first or not.

ahh, ok.  I see your point now, thanks.

Daniel, do you mind tagging that commit, eg 'mvebu-deps-3.12' or
similar?

> Also for the next merge window: Can we please let everything under
> drivers/clocksoure go through Daniels and my trees?

Of course, that's what I've been encouraging:

http://permalink.gmane.org/gmane.linux.ports.arm.kernel/242342

""" Using Thomas Petazzoni's quoting style here :)

Is there a reason why the following breakdown wouldn't work?

>  arch/arm/boot/dts/armada-370-xp.dtsi     |   1 +
>  arch/arm/boot/dts/armada-370.dtsi        |   1 +
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi |   1 +
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |   1 +
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi |   1 +

through mvebu/arm-soc

>  arch/arm/mach-mvebu/Kconfig              |   1 +

through mvebu/arm-soc after the other three have landed (v3.11-rc1)

>  drivers/irqchip/irq-armada-370-xp.c      | 186 ++++++++++++++++++++++++++++++-

through tglx

>  drivers/pci/host/pci-mvebu.c             |  21 ++++
>  drivers/pci/msi.c                        |  59 +++++++++-
>  drivers/pci/probe.c                      |   1 +
>  include/linux/msi.h                      |  22 ++++
>  include/linux/pci.h                      |   1 +

through Bjorn

I think we should view the manner in which we brought in the initial
mvebu-pcie series (all through arm-soc) as the exception, not the rule.
I have no problem, and in fact, prefer to have them reviewed as a
series, but if at *all* possible, the series should be structured so
relevant maintainers can pick up the relevant patches into their trees.

""" End quote

There's a delicate three-way balance between pushing patches that we
depend on to the appropriate maintainers, avoiding out-of-tree
dependencies for arm-soc, and keeping the ball moving.

I don't mind delaying half of a series so the drivers/ portion can land
in mainline, and the rest can land in the next cycle.  But when things
don't go according to that plan, I'd like a little consideration /
flexibility about solving the problem.  Especially considering I'm
*trying* to do the right thing by pushing to appropriate maintainers
first.

Of course, this is a moot point since, as you clarified above, this
dependency doesn't have the hazards typically associated with
out-of-tree dependencies.

thx,

Jason.

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Thomas Gleixner]

On Sun, 7 Jul 2013, Jason Cooper wrote:
> On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> I don't mind delaying half of a series so the drivers/ portion can land
> in mainline, and the rest can land in the next cycle.  But when things
> don't go according to that plan, I'd like a little consideration /
> flexibility about solving the problem.  Especially considering I'm
> *trying* to do the right thing by pushing to appropriate maintainers
> first.
> 
> Of course, this is a moot point since, as you clarified above, this
> dependency doesn't have the hazards typically associated with
> out-of-tree dependencies.

There is a very simple procedure for stuff like this.

Series has parts which go through tree A and B and another larger part
for tree C which depends on the A and B parts.

So ask the maintainers of A and B to apply this to separate branches,
which are based on some commit in Linus tree. These branches can be
pulled into C and C can apply the depending stuff on top.

Now the maintainers of A and B merge these branches into their main
devel branch, can do further fixups and stuff on top. And the whole
thing just works without glitches during the merge window.

We do this all the time.

Thanks,

	tglx

managing out-of-tree deps for arm-soc in a single window was: Re: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Jason Cooper]

On Mon, Jul 08, 2013 at 10:45:47AM +0200, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
> > On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> > I don't mind delaying half of a series so the drivers/ portion can land
> > in mainline, and the rest can land in the next cycle.  But when things
> > don't go according to that plan, I'd like a little consideration /
> > flexibility about solving the problem.  Especially considering I'm
> > *trying* to do the right thing by pushing to appropriate maintainers
> > first.
> > 
> > Of course, this is a moot point since, as you clarified above, this
> > dependency doesn't have the hazards typically associated with
> > out-of-tree dependencies.
> 
> There is a very simple procedure for stuff like this.
> 
> Series has parts which go through tree A and B and another larger part
> for tree C which depends on the A and B parts.
> 
> So ask the maintainers of A and B to apply this to separate branches,
> which are based on some commit in Linus tree. These branches can be
> pulled into C and C can apply the depending stuff on top.
> 
> Now the maintainers of A and B merge these branches into their main
> devel branch, can do further fixups and stuff on top. And the whole
> thing just works without glitches during the merge window.
> 
> We do this all the time.

Wow, I wish I had known this (or thought of it) months ago!  Thanks for
taking the time to explain it to me.

Arnd, Olof,

Does this address your concerns about out of tree dependencies?  I think
it does, but I'm not the one who has to manage it after I set it up and
send the PR...

thx,

Jason.

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Daniel Lezcano]

On 07/08/2013 10:45 AM, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
>> On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
>> I don't mind delaying half of a series so the drivers/ portion can land
>> in mainline, and the rest can land in the next cycle.  But when things
>> don't go according to that plan, I'd like a little consideration /
>> flexibility about solving the problem.  Especially considering I'm
>> *trying* to do the right thing by pushing to appropriate maintainers
>> first.
>>
>> Of course, this is a moot point since, as you clarified above, this
>> dependency doesn't have the hazards typically associated with
>> out-of-tree dependencies.
> 
> There is a very simple procedure for stuff like this.
> 
> Series has parts which go through tree A and B and another larger part
> for tree C which depends on the A and B parts.
> 
> So ask the maintainers of A and B to apply this to separate branches,
> which are based on some commit in Linus tree. These branches can be
> pulled into C and C can apply the depending stuff on top.
> 
> Now the maintainers of A and B merge these branches into their main
> devel branch, can do further fixups and stuff on top. And the whole
> thing just works without glitches during the merge window.
> 
> We do this all the time.

Ok, I was about to send to both of you a PR with a common ancestor [1]
for this patch but finally this patch has been taken for timers/urgent.

I don't have to send the PR, right ?

timers/urgent will be merged into timers/core, correct ?

Thanks
  -- Daniel

[1]
https://git.linaro.org/gitweb?p=people/dlezcano/clockevents.git;a=shortlog;h=refs/heads/timers/mvebu-deps-3.12


-- 
 <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

[GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer

[Jason Cooper]

On Tue, Jul 16, 2013 at 05:55:41PM +0200, Daniel Lezcano wrote:
> On 07/08/2013 10:45 AM, Thomas Gleixner wrote:
> > On Sun, 7 Jul 2013, Jason Cooper wrote:
> >> On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> >> I don't mind delaying half of a series so the drivers/ portion can land
> >> in mainline, and the rest can land in the next cycle.  But when things
> >> don't go according to that plan, I'd like a little consideration /
> >> flexibility about solving the problem.  Especially considering I'm
> >> *trying* to do the right thing by pushing to appropriate maintainers
> >> first.
> >>
> >> Of course, this is a moot point since, as you clarified above, this
> >> dependency doesn't have the hazards typically associated with
> >> out-of-tree dependencies.
> > 
> > There is a very simple procedure for stuff like this.
> > 
> > Series has parts which go through tree A and B and another larger part
> > for tree C which depends on the A and B parts.
> > 
> > So ask the maintainers of A and B to apply this to separate branches,
> > which are based on some commit in Linus tree. These branches can be
> > pulled into C and C can apply the depending stuff on top.
> > 
> > Now the maintainers of A and B merge these branches into their main
> > devel branch, can do further fixups and stuff on top. And the whole
> > thing just works without glitches during the merge window.
> > 
> > We do this all the time.
> 
> Ok, I was about to send to both of you a PR with a common ancestor [1]
> for this patch but finally this patch has been taken for timers/urgent.
> 
> I don't have to send the PR, right ?
> 
> timers/urgent will be merged into timers/core, correct ?

Sorry for the late reply.  I'm crawling out from under my backlog.  It
appears

  0c1dcfd clocksource: Add Marvell Orion SoC timer

has made it into Linus' tree.  Ezequiel, you should be able to base your
series on v3.11-rc[12] to pick this up.

thx,

Jason.