[GIT PULL] Multi Cluster Power Management infrastructure

[GIT PULL] Multi Cluster Power Management infrastructure

[Nicolas Pitre]

Russell, would you please pull the following:

	git://git.linaro.org/people/nico/linux mcpm

This contains the basic infrastructure needed to support CPU hotplug, 
deep CPU idle and secondary CPU bringup in a cluster based system such 
as, but not limited to, those based on the big.LITTLE architecture.

This is the same set of patches from the previous pull request that 
missed thelast merge window, except for minor changes needed for this 
code to work with v3.9-rc3 (i.e. removal of the __cpuinit tags and 
removal of set_smp_cross_call() from the smp_init_cpus method).

The diffstat follows:

 Documentation/arm/cluster-pm-race-avoidance.txt | 498 ++++++++++++++++++
 Documentation/arm/vlocks.txt                    | 211 ++++++++
 arch/arm/Kconfig                                |   8 +
 arch/arm/common/Makefile                        |   1 +
 arch/arm/common/mcpm_entry.c                    | 314 +++++++++++
 arch/arm/common/mcpm_head.S                     | 219 ++++++++
 arch/arm/common/mcpm_platsmp.c                  |  87 +++
 arch/arm/common/vlock.S                         | 108 ++++
 arch/arm/common/vlock.h                         |  29 +
 arch/arm/include/asm/mcpm_entry.h               | 190 +++++++
 10 files changed, 1665 insertions(+)


Nicolas

[GIT PULL] Multi Cluster Power Management infrastructure

[Lorenzo Pieralisi]

Hi Russell,

On Mon, Mar 25, 2013 at 04:41:52PM +0000, Nicolas Pitre wrote:
> 
> Russell, would you please pull the following:
> 
> 	git://git.linaro.org/people/nico/linux mcpm
> 
> This contains the basic infrastructure needed to support CPU hotplug, 
> deep CPU idle and secondary CPU bringup in a cluster based system such 
> as, but not limited to, those based on the big.LITTLE architecture.

Can I ask you please what's your plan for merging this series ?
We have lots of code in our trees that depends on this set (which has been
extensively tested), hence I am really looking forward to having a stable
branch to rebase on top.

Thank you very much,
Lorenzo

> 
> This is the same set of patches from the previous pull request that 
> missed thelast merge window, except for minor changes needed for this 
> code to work with v3.9-rc3 (i.e. removal of the __cpuinit tags and 
> removal of set_smp_cross_call() from the smp_init_cpus method).
> 
> The diffstat follows:
> 
>  Documentation/arm/cluster-pm-race-avoidance.txt | 498 ++++++++++++++++++
>  Documentation/arm/vlocks.txt                    | 211 ++++++++
>  arch/arm/Kconfig                                |   8 +
>  arch/arm/common/Makefile                        |   1 +
>  arch/arm/common/mcpm_entry.c                    | 314 +++++++++++
>  arch/arm/common/mcpm_head.S                     | 219 ++++++++
>  arch/arm/common/mcpm_platsmp.c                  |  87 +++
>  arch/arm/common/vlock.S                         | 108 ++++
>  arch/arm/common/vlock.h                         |  29 +
>  arch/arm/include/asm/mcpm_entry.h               | 190 +++++++
>  10 files changed, 1665 insertions(+)
> 
> 
> Nicolas
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[GIT PULL] Multi Cluster Power Management infrastructure

[Nicolas Pitre]

Ping.


On Thu, 28 Mar 2013, Lorenzo Pieralisi wrote:

> Hi Russell,
> 
> On Mon, Mar 25, 2013 at 04:41:52PM +0000, Nicolas Pitre wrote:
> > 
> > Russell, would you please pull the following:
> > 
> > 	git://git.linaro.org/people/nico/linux mcpm
> > 
> > This contains the basic infrastructure needed to support CPU hotplug, 
> > deep CPU idle and secondary CPU bringup in a cluster based system such 
> > as, but not limited to, those based on the big.LITTLE architecture.
> 
> Can I ask you please what's your plan for merging this series ?
> We have lots of code in our trees that depends on this set (which has been
> extensively tested), hence I am really looking forward to having a stable
> branch to rebase on top.
> 
> Thank you very much,
> Lorenzo
> 
> > 
> > This is the same set of patches from the previous pull request that 
> > missed thelast merge window, except for minor changes needed for this 
> > code to work with v3.9-rc3 (i.e. removal of the __cpuinit tags and 
> > removal of set_smp_cross_call() from the smp_init_cpus method).
> > 
> > The diffstat follows:
> > 
> >  Documentation/arm/cluster-pm-race-avoidance.txt | 498 ++++++++++++++++++
> >  Documentation/arm/vlocks.txt                    | 211 ++++++++
> >  arch/arm/Kconfig                                |   8 +
> >  arch/arm/common/Makefile                        |   1 +
> >  arch/arm/common/mcpm_entry.c                    | 314 +++++++++++
> >  arch/arm/common/mcpm_head.S                     | 219 ++++++++
> >  arch/arm/common/mcpm_platsmp.c                  |  87 +++
> >  arch/arm/common/vlock.S                         | 108 ++++
> >  arch/arm/common/vlock.h                         |  29 +
> >  arch/arm/include/asm/mcpm_entry.h               | 190 +++++++
> >  10 files changed, 1665 insertions(+)
> > 
> > 
> > Nicolas
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 

[GIT PULL] Multi Cluster Power Management infrastructure

[Nicolas Pitre]

I want to deplore a situation that highlights a bottleneck with our 
current upstreaming process on ARM affecting the MCPM patch series I'm 
maintaining.

This patch series has been extensively reviewed.

1st review cycle (10 Jan 2013):
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=208625

2nd review cycle (24 Jan 2013):
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=212196

3rd review cycle (29 Jan 2013):
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=213562

4th review cycle (5 Feb 2013):
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=215477

The following people were involved in the discussion:

  Achin Gupta
  Catalin Marinas
  Dave Martin
  Jon Medhurst
  Joseph Lo
  Lorenzo Pieralisi
  Saeed Bishara
  Santosh Shilimkar
  Stephen Boyd
  Rob Herring
  Pawel Moll
  Will Deacon

Resulting review comments were all addressed.  

So, a pull request for the v3.8 merge window was posted (6 Feb 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/216061

This, however, didn't get merged in time due to some miscommunication
about non technical reasons.  I therefore won't expose those reasons 
here.  Suffice to say that a merge window was missed.

Therefore, this was followed by another pull request for the v3.9 merge window (25 Mar 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/225873

Followed by a merge plan inquiry from Lorenzo (28 Mar 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/227035

To end up with my ping (3 Apr 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/228209

Russell mentioned having issues with the mailing list traffic and pull
request being buried.  He therefore suggested a special email alias
to filter pull requests (22 Mar 2013):
http://article.gmane.org/gmane.linux.ports.arm.kernel/225377

The last pull request used that alias, and the latest ping did use both 
the pull alias as well as his regular email address.

We're approaching v3.9-rc6, and there is still no sign of this patch set 
being headed for mainline yet.  The system is _not_ working if this 
series is to miss yet another merge window.

On March 28th, Russell mentioned he'd be sporadically away for the 
following two weeks, and suggested that the GIC patches go through the 
ARM SoC tree:
http://article.gmane.org/gmane.linux.ports.arm.kernel/227040

Given the lack of backup to pick up the load when Russell is unavailable 
(seeing the next merge window approaching and still no response from my 
latest pull request and its subsequent recalls), I'm questionning the 
current process scalability. Therefore, at this point, I'm suggesting 
that the MCPM series be merged in the ARM SoC tree as well, as a backup 
solution.

After all, this series is a prerequisite for more patches about platform 
specific patches meant for the ARM SoC tree but which currently are 
still waiting.  Having the prerequisite in the ARM SOC tree will allow 
for those patches to be exposed earlier.


Nicolas

[GIT PULL] Multi Cluster Power Management infrastructure

[Russell King - ARM Linux]

Right, you force my hand.  None of the stuff below should be public, but
you give me no choice now but to publically defend myself against your
allegations.

The reason that I haven't merged it is that:

1. At the beginning of December, when the TI situation looked very
   uncertain, I approached Linaro to see whether it was possible to
   sort out a relationship with them.  Linaro were enthusiastic.

2. It took weeks for anything to really happen - indeed, the first
   sign of any kind of idea for any work was first mentioned at the
   beginning of January, the day that Nicolas posted these patches
   for review.  The work was going to be to review these patches.

3. As that was going to be the subject of the work, and there was no
   arrangement in place, I actively avoided reviewing these changes.

4. Along with this came the provision that I was to attend two Linaro
   connects a year.

5. It turns out that this provision was made based on rumour and gossip
   about my medical situation concerning my eye, based on travel that I
   had done last year.  Rather than *talk* to me and find out what the
   real situation was, Linaro decided to have internal discussions about
   this, based on this rumour and gossip.

6. It took a week or more to sort out that situation, which should never
   have arrisen if people didn't gossip and rumour.

7. The work (2) has now been withdrawn, and I'm now being left with being
   told "we have problems working out what work to give you".

So at this point, I view any kind of relationship with Linaro as being a
extremely poor, and probably no longer worth persuing - not because of
any fault of mine, but a total wreckage of our relationship due to bad
management behaviour within Linaro based on rumour and gossip.

Hence, I have never gone back and reviewed the patches Nicolas is
referring to, because I've *NO* idea what so ever what's going on with
Linaro.  If they can't think of anything they want me to work on, and
this stuff is still outstanding then... well... what hope is there?

Now, I'm currently on holiday.  I'm going to be on holday until after
mid-April.  I'm not pulling anything until then.  I'm not applying anything
until then.  I'm not even reading this mailbox - and given current mail
rates at 300-400 messages per day, I will *not* be reading back over a
fortnights worth of email.

The only reason I'm trying to this is because Will Deacon pointed it out
to me via IRC.

So, in summary, this situation has been created by Linaro *themselves*
and it's all their problem.  They can sort it out if they want to be
cooperative and give me the work that they were originally proposing.
If not... I'm not sure where we go.

But all that I get from you is "you must pull this stuff anyway, whether
you've reviewed it or not".  Sorry, no.

On Thu, Apr 04, 2013 at 10:03:54PM -0400, Nicolas Pitre wrote:
> I want to deplore a situation that highlights a bottleneck with our 
> current upstreaming process on ARM affecting the MCPM patch series I'm 
> maintaining.
> 
> This patch series has been extensively reviewed.
> 
> 1st review cycle (10 Jan 2013):
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=208625
> 
> 2nd review cycle (24 Jan 2013):
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=212196
> 
> 3rd review cycle (29 Jan 2013):
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=213562
> 
> 4th review cycle (5 Feb 2013):
> http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=215477
> 
> The following people were involved in the discussion:
> 
>   Achin Gupta
>   Catalin Marinas
>   Dave Martin
>   Jon Medhurst
>   Joseph Lo
>   Lorenzo Pieralisi
>   Saeed Bishara
>   Santosh Shilimkar
>   Stephen Boyd
>   Rob Herring
>   Pawel Moll
>   Will Deacon
> 
> Resulting review comments were all addressed.  
> 
> So, a pull request for the v3.8 merge window was posted (6 Feb 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/216061
> 
> This, however, didn't get merged in time due to some miscommunication
> about non technical reasons.  I therefore won't expose those reasons 
> here.  Suffice to say that a merge window was missed.
> 
> Therefore, this was followed by another pull request for the v3.9 merge window (25 Mar 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/225873
> 
> Followed by a merge plan inquiry from Lorenzo (28 Mar 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/227035
> 
> To end up with my ping (3 Apr 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/228209
> 
> Russell mentioned having issues with the mailing list traffic and pull
> request being buried.  He therefore suggested a special email alias
> to filter pull requests (22 Mar 2013):
> http://article.gmane.org/gmane.linux.ports.arm.kernel/225377
> 
> The last pull request used that alias, and the latest ping did use both 
> the pull alias as well as his regular email address.
> 
> We're approaching v3.9-rc6, and there is still no sign of this patch set 
> being headed for mainline yet.  The system is _not_ working if this 
> series is to miss yet another merge window.
> 
> On March 28th, Russell mentioned he'd be sporadically away for the 
> following two weeks, and suggested that the GIC patches go through the 
> ARM SoC tree:
> http://article.gmane.org/gmane.linux.ports.arm.kernel/227040
> 
> Given the lack of backup to pick up the load when Russell is unavailable 
> (seeing the next merge window approaching and still no response from my 
> latest pull request and its subsequent recalls), I'm questionning the 
> current process scalability. Therefore, at this point, I'm suggesting 
> that the MCPM series be merged in the ARM SoC tree as well, as a backup 
> solution.
> 
> After all, this series is a prerequisite for more patches about platform 
> specific patches meant for the ARM SoC tree but which currently are 
> still waiting.  Having the prerequisite in the ARM SOC tree will allow 
> for those patches to be exposed earlier.
> 
> 
> Nicolas

[GIT PULL] Multi Cluster Power Management infrastructure

[Nicolas Pitre]

On Fri, 5 Apr 2013, Russell King - ARM Linux wrote:

> Right, you force my hand.  None of the stuff below should be public, but
> you give me no choice now but to publically defend myself against your
> allegations.
> 
> The reason that I haven't merged it is that:
> 
> 1. At the beginning of December, when the TI situation looked very
>    uncertain, I approached Linaro to see whether it was possible to
>    sort out a relationship with them.  Linaro were enthusiastic.
> 
> 2. It took weeks for anything to really happen - indeed, the first
>    sign of any kind of idea for any work was first mentioned at the
>    beginning of January, the day that Nicolas posted these patches
>    for review.  The work was going to be to review these patches.

I don't think the review of precisely those patches was put in any 
contract proposal.  That would have been way too limiting, and a waste 
of your competence.  But that shouldn't matter in this case as the 
problem lays elsewhere as far as the community is concerned.

> 3. As that was going to be the subject of the work, and there was no
>    arrangement in place, I actively avoided reviewing these changes.

That is unacceptable.  You are recognized as the ARM kernel maintainer.  
This role depends on the trust that the community puts in you, and _not_ 
based on any contractual arrangement with any company, be that Linaro or 
any other.

Patches are rejected or accepted in the mainline kernel based on their 
technical merits, period. As the ARM kernel upstream maintainer, you 
cannot use your position to block the merging of some patches based on a 
private matter between you and Linaro.  This is unethical and a direct 
conflict of interest.

And, as I've told you in private many times now, the work resulting in 
those patches is something of the past.  The world has moved on.  Any 
work assigned to you by contract from Linaro would be about something 
else, something new, and not something that used to be new a year ago.  
In fact Linaro is willing to give you money and give you full freedom to 
let you decide to work on anything you want if that improves Linux 
support on ARM.  Why this doesn't sounds good to you is beyond my 
understanding.

Anyway... The fact that quality people did review the MCPM patches 
extensively should be enough for trust to be applied in the decision to 
merge those patches now.  They've been circulated in public for 3 months 
now, they've missed a merge window already, I'm not going to accept they 
miss another one for non technical reasons.

[ legitimate but private issues with no relevance to the community 
  process skipped ]

> Now, I'm currently on holiday.  I'm going to be on holday until after
> mid-April.  I'm not pulling anything until then.  I'm not applying anything
> until then.  I'm not even reading this mailbox - and given current mail
> rates at 300-400 messages per day, I will *not* be reading back over a
> fortnights worth of email.

That is also unacceptable.  Again, you are the appointed ARM kernel 
maintainer.  You have to plan a backup when you are away.  If the load 
is too much, you have to delegate.  They do it for the X86 architecture 
with 3 maintainers despite the fact that the X86 architecture is much 
less active in that regard.

Part of your role as a maintainer is to ensure the community process is 
working well, not to obstruct to it.  And that _independently_ of any 
private engagement you might or might not have with any company.


Nicolas

[GIT PULL] Multi Cluster Power Management infrastructure

[Russell King - ARM Linux]

On Fri, Apr 05, 2013 at 09:30:58AM -0400, Nicolas Pitre wrote:
> > Now, I'm currently on holiday.  I'm going to be on holday until after
> > mid-April.  I'm not pulling anything until then.  I'm not applying anything
> > until then.  I'm not even reading this mailbox - and given current mail
> > rates at 300-400 messages per day, I will *not* be reading back over a
> > fortnights worth of email.
> 
> That is also unacceptable.  Again, you are the appointed ARM kernel 
> maintainer.  You have to plan a backup when you are away.  If the load 
> is too much, you have to delegate.

Thank you for showing what a self-centred individual you are.

Tell me, how do I delegate the physical act of scanning through email
to someone else to find out those emails which I may want to reply to?

Now, just take a moment to do the math.  At 400 messages per day, with
an average of one minute a message, that's 6.5 hours.  Four days of that
and you're looking at 20 hours to catch up - realistically two days.
Meanwhile another 13 hours of messages (800) have arrived.  So that's
another day and a bit of nothing but scanning, during which time more
than 6.5 hours of messages have again arrived...

I've said this before, and I've done the above before - over a much
longer period.  Other kernel developers do this too - they will actively
remove their mailboxes after returning from a vacation because its
too painful to catch up by reading mail.  Linus will also do the same -
he will require things to be (re-)sent when he's returned from vacation.

Yet _you_ seem to think that this is not acceptable behaviour?  Sorry,
I disagree - it's the _only_ sensible and sane way.

[GIT PULL] Multi Cluster Power Management infrastructure

[Russell King - ARM Linux]

On Sun, Apr 07, 2013 at 01:23:42AM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 05, 2013 at 09:30:58AM -0400, Nicolas Pitre wrote:
> > > Now, I'm currently on holiday.  I'm going to be on holday until after
> > > mid-April.  I'm not pulling anything until then.  I'm not applying anything
> > > until then.  I'm not even reading this mailbox - and given current mail
> > > rates at 300-400 messages per day, I will *not* be reading back over a
> > > fortnights worth of email.
> > 
> > That is also unacceptable.  Again, you are the appointed ARM kernel 
> > maintainer.  You have to plan a backup when you are away.  If the load 
> > is too much, you have to delegate.
> 
> Thank you for showing what a self-centred individual you are.
> 
> Tell me, how do I delegate the physical act of scanning through email
> to someone else to find out those emails which I may want to reply to?
> 
> Now, just take a moment to do the math.  At 400 messages per day, with
> an average of one minute a message, that's 6.5 hours.  Four days of that
> and you're looking at 20 hours to catch up - realistically two days.
> Meanwhile another 13 hours of messages (800) have arrived.  So that's
> another day and a bit of nothing but scanning, during which time more
> than 6.5 hours of messages have again arrived...
> 
> I've said this before, and I've done the above before - over a much
> longer period.  Other kernel developers do this too - they will actively
> remove their mailboxes after returning from a vacation because its
> too painful to catch up by reading mail.  Linus will also do the same -
> he will require things to be (re-)sent when he's returned from vacation.
> 
> Yet _you_ seem to think that this is not acceptable behaviour?  Sorry,
> I disagree - it's the _only_ sensible and sane way.

And the last thing to mentoion is that this is the last night before I
drive back home, and I've just spent the last *two* hours dealing with your
crap emails.  It's now 1:30am.  If I have an accident as a result of
this lack of sleep then I hold you responsible for it, because obviously
your patches are far more important than anything else in the whole damned
world.

[GIT PULL] Multi Cluster Power Management infrastructure

[Arnd Bergmann]

On Friday 05 April 2013, Russell King - ARM Linux wrote:
> 
> Now, I'm currently on holiday.  I'm going to be on holday until after
> mid-April.  I'm not pulling anything until then.  I'm not applying anything
> until then.  I'm not even reading this mailbox - and given current mail
> rates at 300-400 messages per day, I will *not* be reading back over a
> fortnights worth of email.

I haven't reviewed the patches before, and only heard of the controversy
from Nico's email yesterday. Independent of your personal situation and
who implemented the code, I think it's clear that a lot of people (not
just Linaro) want to see it get merged and not having it upstream is
blocking platform specific code from getting put into arm-soc.

Since you are currently on holiday, I think it's best if we at least put
it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
in linux-next and let us merge the dependent platform code into "late"
branches for 3.10. I still hope the nontechnical issues can be resolved
in time to let you pull it into your tree before the merge window.

Having just looked over the code myself for the first time, it
seems extremely much self-contained, so I see very little risk of
regressions and I'm sure any comments you have can be addressed in
follow-on patches.

	Arnd

[GIT PULL] Multi Cluster Power Management infrastructure

[Olof Johansson]

On Fri, Apr 5, 2013 at 1:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 05 April 2013, Russell King - ARM Linux wrote:
>>
>> Now, I'm currently on holiday.  I'm going to be on holday until after
>> mid-April.  I'm not pulling anything until then.  I'm not applying anything
>> until then.  I'm not even reading this mailbox - and given current mail
>> rates at 300-400 messages per day, I will *not* be reading back over a
>> fortnights worth of email.
>
> I haven't reviewed the patches before, and only heard of the controversy
> from Nico's email yesterday. Independent of your personal situation and
> who implemented the code, I think it's clear that a lot of people (not
> just Linaro) want to see it get merged and not having it upstream is
> blocking platform specific code from getting put into arm-soc.

I'd prefer not to step into the middle of the personal controversy
either, but I do have some follow-on question and opinion on the code
that depends on this:

Can someone please provide a link or subject for the posted patch
series for the dependent platform code? I tried to search for it on
the lists but didn't have much luck.

> Since you are currently on holiday, I think it's best if we at least put
> it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
> in linux-next and let us merge the dependent platform code into "late"
> branches for 3.10. I still hope the nontechnical issues can be resolved
> in time to let you pull it into your tree before the merge window.

I think platform code should wait until 3.11 instead of getting
crammed in at post-rc6. If it hasn't already been posted by now, it
should most definitely wait. That also saves on any contentious
dependency between the two.

> Having just looked over the code myself for the first time, it
> seems extremely much self-contained, so I see very little risk of
> regressions and I'm sure any comments you have can be addressed in
> follow-on patches.

I hope so too, but I would prefer to not build dependencies until
that's been dealt with.


-Olof

[GIT PULL] Multi Cluster Power Management infrastructure

[Nicolas Pitre]

On Fri, 5 Apr 2013, Olof Johansson wrote:

> Can someone please provide a link or subject for the posted patch
> series for the dependent platform code? I tried to search for it on
> the lists but didn't have much luck.

As mentioned in my cover letter, the dependent platform code for RTSM 
has been publicly posted along with the MCPM patches in all 4 review 
cycles.  Those patches therefore were reviewed all together.  The plan 
was to have the MCPM into mainline during the previous merge window via 
Russell, and the platform code via ARM SoC either during the previous 
cycle time permitting, or this cycle otherwise.

Therefore the MCPM pull request includes only the MCPM patches.  Another 
pull request for the remaining patches is still pending for ARM SoC.

If you want to see all patches together, you may have a look at the 
following branch:

  git://git.linaro.org/people/nico/linux mcpm+dcscb

> I think platform code should wait until 3.11 instead of getting
> crammed in at post-rc6. If it hasn't already been posted by now, it
> should most definitely wait. That also saves on any contentious
> dependency between the two.

It was posted *tree* months ago.  It was reviewed *four* times already.


Nicolas

[GIT PULL] Multi Cluster Power Management infrastructure

[Grant Likely]

On Fri, Apr 5, 2013 at 9:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 05 April 2013, Russell King - ARM Linux wrote:
>>
>> Now, I'm currently on holiday.  I'm going to be on holday until after
>> mid-April.  I'm not pulling anything until then.  I'm not applying anything
>> until then.  I'm not even reading this mailbox - and given current mail
>> rates at 300-400 messages per day, I will *not* be reading back over a
>> fortnights worth of email.
>
> I haven't reviewed the patches before, and only heard of the controversy
> from Nico's email yesterday. Independent of your personal situation and
> who implemented the code, I think it's clear that a lot of people (not
> just Linaro) want to see it get merged and not having it upstream is
> blocking platform specific code from getting put into arm-soc.
>
> Since you are currently on holiday, I think it's best if we at least put
> it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
> in linux-next and let us merge the dependent platform code into "late"
> branches for 3.10. I still hope the nontechnical issues can be resolved
> in time to let you pull it into your tree before the merge window.

I agree. This makes the most sense. There is no reason for mcpm to be
excluded from linux-next before this issue is resolved.

g.

[GIT PULL] Multi Cluster Power Management infrastructure

[Russell King - ARM Linux]

On Fri, Apr 05, 2013 at 10:33:25PM +0200, Arnd Bergmann wrote:
> On Friday 05 April 2013, Russell King - ARM Linux wrote:
> > 
> > Now, I'm currently on holiday.  I'm going to be on holday until after
> > mid-April.  I'm not pulling anything until then.  I'm not applying anything
> > until then.  I'm not even reading this mailbox - and given current mail
> > rates at 300-400 messages per day, I will *not* be reading back over a
> > fortnights worth of email.
> 
> I haven't reviewed the patches before, and only heard of the controversy
> from Nico's email yesterday. Independent of your personal situation and
> who implemented the code, I think it's clear that a lot of people (not
> just Linaro) want to see it get merged and not having it upstream is
> blocking platform specific code from getting put into arm-soc.

Nicolas is doing what he always does when he doesn't get his own way - he
tries to force his way.  This is exactly what's going on here...

> Since you are currently on holiday, I think it's best if we at least put
> it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
> in linux-next and let us merge the dependent platform code into "late"
> branches for 3.10. I still hope the nontechnical issues can be resolved
> in time to let you pull it into your tree before the merge window.

I doubt it will.  The way I now feel, I feel betrayed by Linaro, and
I feel that they have done me a great disservice.  I don't see that
there's anything Linaro has to offer me in way of work (if they could,
then they would be able to tell me what areas they have available -
but they can't even do that.)

How can this be resolved?  I've no idea, that's entirely up to Linaro
and its management to work out whether they actually have any work
available.  My conclusion, given the sparseness of any kind of idea of
work is that they do not have much idea about any kind of work, and
I suspect that they have no knowledge themselves as to what work
really needs to be done.

If there was one, then it would be nice and simple to include in an
email a list of work items that were available - but that's not what
has been done ove rthe last 4 months.

So no, _I_ can't resolve it until Linaro gets a handle on what the hell
that organization wants to do.

But the whole message here is: if you fuck me around commercially, you
can't *not* expect it to have an impact on what I volunteer to do, and
you'd better *not* put work-items on the table and then take them away
again, and then end up demanding that they be done for gratis just
because of my position.  *That* is grossly unfair.

[GIT PULL] Multi Cluster Power Management infrastructure

[Nicolas Pitre]

On Sun, 7 Apr 2013, Russell King - ARM Linux wrote:

> On Fri, Apr 05, 2013 at 10:33:25PM +0200, Arnd Bergmann wrote:
> > On Friday 05 April 2013, Russell King - ARM Linux wrote:
> > > 
> > > Now, I'm currently on holiday.  I'm going to be on holday until after
> > > mid-April.  I'm not pulling anything until then.  I'm not applying anything
> > > until then.  I'm not even reading this mailbox - and given current mail
> > > rates at 300-400 messages per day, I will *not* be reading back over a
> > > fortnights worth of email.
> > 
> > I haven't reviewed the patches before, and only heard of the controversy
> > from Nico's email yesterday. Independent of your personal situation and
> > who implemented the code, I think it's clear that a lot of people (not
> > just Linaro) want to see it get merged and not having it upstream is
> > blocking platform specific code from getting put into arm-soc.
> 
> Nicolas is doing what he always does when he doesn't get his own way - he
> tries to force his way.  This is exactly what's going on here...

Since you're willfully blocking my way, I have no choice but to force 
it.  Are you expecting me to stand still?

> > Since you are currently on holiday, I think it's best if we at least put
> > it into asm-soc as a for-rmk/mcpm branch in order to give it coverage
> > in linux-next and let us merge the dependent platform code into "late"
> > branches for 3.10. I still hope the nontechnical issues can be resolved
> > in time to let you pull it into your tree before the merge window.
> 
> I doubt it will.  The way I now feel, I feel betrayed by Linaro, and
> I feel that they have done me a great disservice.  I don't see that
> there's anything Linaro has to offer me in way of work (if they could,
> then they would be able to tell me what areas they have available -
> but they can't even do that.)

Oh come on, please cut that crap.  We gave you complete freedom to 
suggest what _you_ want to work on.  But apparently you can't even do 
that either.

> How can this be resolved?  I've no idea, that's entirely up to Linaro
> and its management to work out whether they actually have any work
> available.

What does it have to do with the pull request I sent to you, given that 
it has been made clear now that Linaro won't pay you for this?  Are you 
expecting money from Linaro before sending those patches upstream?

> So no, _I_ can't resolve it until Linaro gets a handle on what the hell
> that organization wants to do.

That organization wants you, the prime ARM Linux kernel expert above 
all, to determine by yourself a list of things where your work could 
benefit ARM Linux the most.  Then we'll select in your list some items 
we want you to work on our behalf in exchange for money.  How can I make 
it more clear?

If patch review is part of the deal, that would be for work in progress, 
and _not_ for completed patches.  The patches presented here used to be 
work in progress during Q4 of last year but they are _not_ work in 
progress anymore.  So please get a grip and look towards the future not 
in the past.

> But the whole message here is: if you fuck me around commercially, you
> can't *not* expect it to have an impact on what I volunteer to do, and
> you'd better *not* put work-items on the table and then take them away
> again, and then end up demanding that they be done for gratis just
> because of my position.  *That* is grossly unfair.

Well, as a community maintainer, you have to follow the established 
community process.  As a community contributor, I have to follow the 
process too.  And the community doesn't give a damn about the success of 
your commercial arrangements nor Linaro's.  As far as the community is 
concerned, I did my part, so I'm politely asking you that you do yours.

Of course, your community maintainer work is done on a volunteer basis 
and I fully appreciate that.  That means I cannot impose on you to merge 
my patches.

However, this patch set has gone through all the normal community review 
process.  No one objects to its merge into mainline.  No one but you, 
and your arguments at this point are completely non technical.

In that case you have to accept that I might seek another maintainer to 
judge the technical merit of those patches and merge them upstream.  
Linus has made it clear many times that maintainers can be bypassed if 
need be.

Any commercial arrangement between you and Linaro remains an orthogonal 
issue, and the discussion about that may continue separately and in 
private if you are still interested.


Nicolas

[GIT PULL] Multi Cluster Power Management infrastructure

[Nicolas Pitre]

Russell, would you please pull the following:

	git://git.linaro.org/people/nico/linux mcpm

This contains the basic infrastructure needed to support CPU hotplug, 
deep CPU idle and secondary CPU bringup in a cluster based system such 
as, but not limited to, those based on the big.LITTLE architecture.

Several rounds of reviews took place on the list and all comments were 
addressed.

Included is the core infrastructure only.  That already represents a 
significant chunk of code on its own.  I'm hoping to be able to send a 
second pull request containing platform support for RTSM if the CCI 
device tree bindings get sorted out in time.  Platform support for TC2 
does exist but more cleanups are needed there which are very unlikely to 
make it in time for the 3.9 merge window.

Here's the diffstat for this pull request:
 Documentation/arm/cluster-pm-race-avoidance.txt | 498 ++++++++++++++++++
 Documentation/arm/vlocks.txt                    | 211 ++++++++
 arch/arm/Kconfig                                |   8 +
 arch/arm/common/Makefile                        |   1 +
 arch/arm/common/mcpm_entry.c                    | 314 +++++++++++
 arch/arm/common/mcpm_head.S                     | 219 ++++++++
 arch/arm/common/mcpm_platsmp.c                  |  86 +++
 arch/arm/common/vlock.S                         | 108 ++++
 arch/arm/common/vlock.h                         |  29 +
 arch/arm/include/asm/mcpm_entry.h               | 190 +++++++
 10 files changed, 1664 insertions(+)


Nicolas