[RFC] ARM Subarchitecture group maintainership

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

This is the draft plan for maintaining the ARM subarchitectures in a common
tree, as a way to help coordinate the upstream merging of the
arch/arm/{plat,mach}-* changes into Linus' tree.

This was discussed in great length at the Linaro Developer Summit in Budapest
last week where we worked out an initial plan. We are modeling the maintainance
after how the linux-tip tree is used for the x86 architecture, with a set
of developers that have commit access to one tree on kernel.org and
have mutual trust in one another. Nicolas Pitre and me are funded
by Linaro to do the bulk of the work, while Thomas Gleixner will help
us part-time with his long time architecture maintainance experience.
Despite the funding by Linaro, this is not a Linaro project and all
ARM subarchitectures are welcome to go through our tree.

Russell King's role as ARM maintainer is of course unchanged by this, but
he has the same commit access to the new tree as the other maintainers and
is welcome to work in the same tree. We are also open to nominations for
further people outside of Linaro to join us as committers. Marc Zyngier from
ARM ltd is one of the candidates that has been suggested and I would also
like to see someone from Google. We have to find the right balance with the
number of committers so we get all the work done without stepping on each
other's toes.

Our tree will be strictly organized in topic brances so we can feed them
upstream in the bitesized chunks that Linus likes. The master branch
is an integration branch that pulls all other branches that are scheduled
for the next merge window and itself gets integrated into linux-next.

We will probably not be fully functional during the 2.6.40 merge window,
but we are trying our best to be useful. For 2.6.41, my hope is that
we can merge the bulk of the ARM subarchitecture changes through this
tree. Once Linus is happy with the way that the process works, we can
mandate that all ARM subarchitecture changes go through our tree, until
then it stays voluntary.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org

---

Maintainers: If you are happy with the layout of the process,
please ack this patch, otherwise please comment.

diff --git a/MAINTAINERS b/MAINTAINERS
index 8fce5e6..942d052 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -630,6 +630,17 @@ S:	Maintained
 F:	drivers/amba/
 F:	include/linux/amba/bus.h
 
+ARM SUBARCHITECTURES
+M:	Arnd Bergmann <arnd@arndb.de>
+M:	Nicolas Pitre <nico@fluxnic.net>
+M:	Thomas Gleixner <tglx@linutronix.de>
+M:	arm@kernel.org
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	MAINTAINED
+F:	arch/arm/mach-*/
+F:	arch/arm/plat-*/
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
+
 ARM/ADI ROADRUNNER MACHINE SUPPORT
 M:	Lennert Buytenhek <kernel@wantstofly.org>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

This is the draft plan for maintaining the ARM subarchitectures in a common
tree, as a way to help coordinate the upstream merging of the
arch/arm/{plat,mach}-* changes into Linus' tree.

This was discussed in great length at the Linaro Developer Summit in Budapest
last week where we worked out an initial plan. We are modeling the maintainance
after how the linux-tip tree is used for the x86 architecture, with a set
of developers that have commit access to one tree on kernel.org and
have mutual trust in one another. Nicolas Pitre and me are funded
by Linaro to do the bulk of the work, while Thomas Gleixner will help
us part-time with his long time architecture maintainance experience.
Despite the funding by Linaro, this is not a Linaro project and all
ARM subarchitectures are welcome to go through our tree.

Russell King's role as ARM maintainer is of course unchanged by this, but
he has the same commit access to the new tree as the other maintainers and
is welcome to work in the same tree. We are also open to nominations for
further people outside of Linaro to join us as committers. Marc Zyngier from
ARM ltd is one of the candidates that has been suggested and I would also
like to see someone from Google. We have to find the right balance with the
number of committers so we get all the work done without stepping on each
other's toes.

Our tree will be strictly organized in topic brances so we can feed them
upstream in the bitesized chunks that Linus likes. The master branch
is an integration branch that pulls all other branches that are scheduled
for the next merge window and itself gets integrated into linux-next.

We will probably not be fully functional during the 2.6.40 merge window,
but we are trying our best to be useful. For 2.6.41, my hope is that
we can merge the bulk of the ARM subarchitecture changes through this
tree. Once Linus is happy with the way that the process works, we can
mandate that all ARM subarchitecture changes go through our tree, until
then it stays voluntary.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org

---

Maintainers: If you are happy with the layout of the process,
please ack this patch, otherwise please comment.

diff --git a/MAINTAINERS b/MAINTAINERS
index 8fce5e6..942d052 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -630,6 +630,17 @@ S:	Maintained
 F:	drivers/amba/
 F:	include/linux/amba/bus.h
 
+ARM SUBARCHITECTURES
+M:	Arnd Bergmann <arnd@arndb.de>
+M:	Nicolas Pitre <nico@fluxnic.net>
+M:	Thomas Gleixner <tglx@linutronix.de>
+M:	arm at kernel.org
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	MAINTAINED
+F:	arch/arm/mach-*/
+F:	arch/arm/plat-*/
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
+
 ARM/ADI ROADRUNNER MACHINE SUPPORT
 M:	Lennert Buytenhek <kernel@wantstofly.org>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)

Re: [RFC] ARM Subarchitecture group maintainership

[Catalin Marinas]

Arnd,

On 18 May 2011 09:47, Arnd Bergmann <arnd@arndb.de> wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.

For clarification - the aim of this subarchitecture group is not only
to coordinate the upstream merging but also take an active (primary)
role in consolidating the existing code across various
subarchitectures under arch/arm/.

> We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google.

This looks fine to me.

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S: Maintained
>  F:     drivers/amba/
>  F:     include/linux/amba/bus.h
>
> +ARM SUBARCHITECTURES
> +M:     Arnd Bergmann <arnd@arndb.de>
> +M:     Nicolas Pitre <nico@fluxnic.net>
> +M:     Thomas Gleixner <tglx@linutronix.de>
> +M:     arm@kernel.org

With this additional line on ARM Ltd's behalf:

+M:     Marc Zyngier <marc.zyngier@arm.com>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
(as co-maintainer of the RealView boards and major contributor to the
ARM architecture support code, though the latter isn't covered by this
group)

Thanks,

Catalin

[RFC] ARM Subarchitecture group maintainership

[Catalin Marinas]

Arnd,

On 18 May 2011 09:47, Arnd Bergmann <arnd@arndb.de> wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.

For clarification - the aim of this subarchitecture group is not only
to coordinate the upstream merging but also take an active (primary)
role in consolidating the existing code across various
subarchitectures under arch/arm/.

> We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google.

This looks fine to me.

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S: Maintained
> ?F: ? ? drivers/amba/
> ?F: ? ? include/linux/amba/bus.h
>
> +ARM SUBARCHITECTURES
> +M: ? ? Arnd Bergmann <arnd@arndb.de>
> +M: ? ? Nicolas Pitre <nico@fluxnic.net>
> +M: ? ? Thomas Gleixner <tglx@linutronix.de>
> +M: ? ? arm at kernel.org

With this additional line on ARM Ltd's behalf:

+M:     Marc Zyngier <marc.zyngier@arm.com>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
(as co-maintainer of the RealView boards and major contributor to the
ARM architecture support code, though the latter isn't covered by this
group)

Thanks,

Catalin

Re: [RFC] ARM Subarchitecture group maintainership

[Shawn Guo]

On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
[...]
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm@kernel.org
> +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED
> +F:	arch/arm/mach-*/
> +F:	arch/arm/plat-*/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git

Is this repository ready for use yet?  It seems not for me.

-- 
Regards,
Shawn

[RFC] ARM Subarchitecture group maintainership

[Shawn Guo]

On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
[...]
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm at kernel.org
> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED
> +F:	arch/arm/mach-*/
> +F:	arch/arm/plat-*/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git

Is this repository ready for use yet?  It seems not for me.

-- 
Regards,
Shawn

Re: [RFC] ARM Subarchitecture group maintainership

[Anca Emanuel]

On Wed, May 18, 2011 at 6:22 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> [...]
>> +ARM SUBARCHITECTURES
>> +M:   Arnd Bergmann <arnd@arndb.de>
>> +M:   Nicolas Pitre <nico@fluxnic.net>
>> +M:   Thomas Gleixner <tglx@linutronix.de>
>> +M:   arm@kernel.org
>> +L:   linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>> +S:   MAINTAINED
>> +F:   arch/arm/mach-*/
>> +F:   arch/arm/plat-*/
>> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
>
> Is this repository ready for use yet?  It seems not for me.

Did you read it ?
[quote]We will probably not be fully functional during the 2.6.40 merge window,
but we are trying our best to be useful. For 2.6.41, my hope is that
we can merge the bulk of the ARM subarchitecture changes through this
tree.[/quote]

[RFC] ARM Subarchitecture group maintainership

[Anca Emanuel]

On Wed, May 18, 2011 at 6:22 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> [...]
>> +ARM SUBARCHITECTURES
>> +M: ? Arnd Bergmann <arnd@arndb.de>
>> +M: ? Nicolas Pitre <nico@fluxnic.net>
>> +M: ? Thomas Gleixner <tglx@linutronix.de>
>> +M: ? arm at kernel.org
>> +L: ? linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> +S: ? MAINTAINED
>> +F: ? arch/arm/mach-*/
>> +F: ? arch/arm/plat-*/
>> +T: ? git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
>
> Is this repository ready for use yet? ?It seems not for me.

Did you read it ?
[quote]We will probably not be fully functional during the 2.6.40 merge window,
but we are trying our best to be useful. For 2.6.41, my hope is that
we can merge the bulk of the ARM subarchitecture changes through this
tree.[/quote]

Re: [RFC] ARM Subarchitecture group maintainership

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:47 Wed 18 May     , Arnd Bergmann wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
> 
> This was discussed in great length at the Linaro Developer Summit in Budapest
> last week where we worked out an initial plan. We are modeling the maintainance
> after how the linux-tip tree is used for the x86 architecture, with a set
> of developers that have commit access to one tree on kernel.org and
> have mutual trust in one another. Nicolas Pitre and me are funded
> by Linaro to do the bulk of the work, while Thomas Gleixner will help
> us part-time with his long time architecture maintainance experience.
> Despite the funding by Linaro, this is not a Linaro project and all
> ARM subarchitectures are welcome to go through our tree.
> 
> Russell King's role as ARM maintainer is of course unchanged by this, but
> he has the same commit access to the new tree as the other maintainers and
> is welcome to work in the same tree. We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google. We have to find the right balance with the
> number of committers so we get all the work done without stepping on each
> other's toes.
> 
> Our tree will be strictly organized in topic brances so we can feed them
> upstream in the bitesized chunks that Linus likes. The master branch
> is an integration branch that pulls all other branches that are scheduled
> for the next merge window and itself gets integrated into linux-next.
> 
> We will probably not be fully functional during the 2.6.40 merge window,
> but we are trying our best to be useful. For 2.6.41, my hope is that
> we can merge the bulk of the ARM subarchitecture changes through this
> tree. Once Linus is happy with the way that the process works, we can
> mandate that all ARM subarchitecture changes go through our tree, until
> then it stays voluntary.
How do you plan to manage with already sub arch maintainers?

In my ming such tree could be good to organise cross arch drivers
but for real arch specific the current workflow is good

If we add a new stage it will be difficult to follow for people

I'd like to have scenario example where such workflow will give a significant
advantage compare to the current workflow. And please real example.

Best Regards,
J.

[RFC] ARM Subarchitecture group maintainership

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:47 Wed 18 May     , Arnd Bergmann wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
> 
> This was discussed in great length at the Linaro Developer Summit in Budapest
> last week where we worked out an initial plan. We are modeling the maintainance
> after how the linux-tip tree is used for the x86 architecture, with a set
> of developers that have commit access to one tree on kernel.org and
> have mutual trust in one another. Nicolas Pitre and me are funded
> by Linaro to do the bulk of the work, while Thomas Gleixner will help
> us part-time with his long time architecture maintainance experience.
> Despite the funding by Linaro, this is not a Linaro project and all
> ARM subarchitectures are welcome to go through our tree.
> 
> Russell King's role as ARM maintainer is of course unchanged by this, but
> he has the same commit access to the new tree as the other maintainers and
> is welcome to work in the same tree. We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google. We have to find the right balance with the
> number of committers so we get all the work done without stepping on each
> other's toes.
> 
> Our tree will be strictly organized in topic brances so we can feed them
> upstream in the bitesized chunks that Linus likes. The master branch
> is an integration branch that pulls all other branches that are scheduled
> for the next merge window and itself gets integrated into linux-next.
> 
> We will probably not be fully functional during the 2.6.40 merge window,
> but we are trying our best to be useful. For 2.6.41, my hope is that
> we can merge the bulk of the ARM subarchitecture changes through this
> tree. Once Linus is happy with the way that the process works, we can
> mandate that all ARM subarchitecture changes go through our tree, until
> then it stays voluntary.
How do you plan to manage with already sub arch maintainers?

In my ming such tree could be good to organise cross arch drivers
but for real arch specific the current workflow is good

If we add a new stage it will be difficult to follow for people

I'd like to have scenario example where such workflow will give a significant
advantage compare to the current workflow. And please real example.

Best Regards,
J.

Re: [RFC] ARM Subarchitecture group maintainership

[David Brown]

On Wed, May 18 2011, Arnd Bergmann wrote:

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
>
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.

Acked-by: David Brown <davidb@codeaurora.org>

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[RFC] ARM Subarchitecture group maintainership

[David Brown]

On Wed, May 18 2011, Arnd Bergmann wrote:

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
>
> ---
>
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.

Acked-by: David Brown <davidb@codeaurora.org>

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [RFC] ARM Subarchitecture group maintainership

[Thomas Gleixner]

On Wed, 18 May 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:47 Wed 18 May     , Arnd Bergmann wrote:
> > We will probably not be fully functional during the 2.6.40 merge window,
> > but we are trying our best to be useful. For 2.6.41, my hope is that
> > we can merge the bulk of the ARM subarchitecture changes through this
> > tree. Once Linus is happy with the way that the process works, we can
> > mandate that all ARM subarchitecture changes go through our tree, until
> > then it stays voluntary.
> How do you plan to manage with already sub arch maintainers?

The sub arch maintainers are not replaced by this.
 
> In my ming such tree could be good to organise cross arch drivers

This is not about drivers. drivers need to move out of arch/arm into
the proper drivers/subsystem where consolidation makes really sense
even across architectures. We have already multiple drivers for the
same stupid IP block in tree just because they were glued into
different SoCs (ARM, x86, ....). That's not an ARM specific problem,
it's all across the board, but on ARM it is very visible.

> but for real arch specific the current workflow is good

There is a difference between arch specific code - i.e. core ARM
architecture code - and SoC specific code which goes into
arch/arm/[mach|plat]-*. The core code was never and issue and we are
not touching it as Russell is handling it perfectly. The real issue is
the code in [mach|plat]-* which flows rather randomly into mainline
today. That results in lack of review, push back and makes
consolidation as hard as it gets.

> If we add a new stage it will be difficult to follow for people

What is difficult about that? How does it matter whether you ask A or
B to pull and propagate your subarch code?
 
> I'd like to have scenario example where such workflow will give a significant
> advantage compare to the current workflow. And please real example.

See above. It's not about examples, it's about solving issues like
lack of review, lack of central places to do consolidation work and
lack of push-back when stuff goes into the wrong direction.

Thanks,

	tglx

[RFC] ARM Subarchitecture group maintainership

[Thomas Gleixner]

On Wed, 18 May 2011, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:47 Wed 18 May     , Arnd Bergmann wrote:
> > We will probably not be fully functional during the 2.6.40 merge window,
> > but we are trying our best to be useful. For 2.6.41, my hope is that
> > we can merge the bulk of the ARM subarchitecture changes through this
> > tree. Once Linus is happy with the way that the process works, we can
> > mandate that all ARM subarchitecture changes go through our tree, until
> > then it stays voluntary.
> How do you plan to manage with already sub arch maintainers?

The sub arch maintainers are not replaced by this.
 
> In my ming such tree could be good to organise cross arch drivers

This is not about drivers. drivers need to move out of arch/arm into
the proper drivers/subsystem where consolidation makes really sense
even across architectures. We have already multiple drivers for the
same stupid IP block in tree just because they were glued into
different SoCs (ARM, x86, ....). That's not an ARM specific problem,
it's all across the board, but on ARM it is very visible.

> but for real arch specific the current workflow is good

There is a difference between arch specific code - i.e. core ARM
architecture code - and SoC specific code which goes into
arch/arm/[mach|plat]-*. The core code was never and issue and we are
not touching it as Russell is handling it perfectly. The real issue is
the code in [mach|plat]-* which flows rather randomly into mainline
today. That results in lack of review, push back and makes
consolidation as hard as it gets.

> If we add a new stage it will be difficult to follow for people

What is difficult about that? How does it matter whether you ask A or
B to pull and propagate your subarch code?
 
> I'd like to have scenario example where such workflow will give a significant
> advantage compare to the current workflow. And please real example.

See above. It's not about examples, it's about solving issues like
lack of review, lack of central places to do consolidation work and
lack of push-back when stuff goes into the wrong direction.

Thanks,

	tglx

Re: [RFC] ARM Subarchitecture group maintainership

[Catalin Marinas]

On Wednesday, 18 May 2011, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 10:47 Wed 18 May     , Arnd Bergmann wrote:
>> This is the draft plan for maintaining the ARM subarchitectures in a common
>> tree, as a way to help coordinate the upstream merging of the
>> arch/arm/{plat,mach}-* changes into Linus' tree.
>
> How do you plan to manage with already sub arch maintainers?
>
> In my ming such tree could be good to organise cross arch drivers
> but for real arch specific the current workflow is good
>
> If we add a new stage it will be difficult to follow for people
>
> I'd like to have scenario example where such workflow will give a significant
> advantage compare to the current workflow. And please real example.

I'll let Arnd and the other members of this group come up with real
examples. In the meantime I'll give my view on this.

The aim is not to hide existing sub-architecture patches behind
another git tree so that people won't notice the conflicts. It's not
just a workflow change, the Acked-by mechanism may have worked as
well, though some people may skip it (even unintentionally).

There is a lot of code duplication between various sub-architectures
under arch/arm/ and this group, together with the sub-arch
maintainers, will try to consolidate this, move common code out into
drivers/ so that it can be easily shared, start moving platforms to
FDT etc. (they could give a roadmap but it's early stages now). This
needs to be a coordinated effort and the group will ensure that the
general direction of code reduction is followed by all the current and
new sub-arch maintainers.

A lot of platform ports have been done just by copying existing code
without any effort in exploiting the commonality. This could be
spotted much easier with a dedicated group of people and guide the
sub-arch maintainers in the write direction. It may be even quicker
for them to get code merged into drivers/ where applicable.

I expect the activity of this group to be reduced in the future, once
the consolidation work is complete (but that's not a trivial task). At
that point maybe one or two people would just keep an eye on what gets
pushed into mainline in sub-arch directories and sub-arch maintainers
would just work as before, sending pull requests to Linus directly.

As the incentive for existing sub-arch maintainers to agree with this
strategy - given Linus' recent comments on the ARM sub-arch trees, it
is possible that he won't merge such trees pushed directly to him if
they don't show a consistent direction towards code consolidation. I
think this group and tree would actually make upstream pushing
quicker.

-- 
Catalin

[RFC] ARM Subarchitecture group maintainership

[Catalin Marinas]

On Wednesday, 18 May 2011, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 10:47 Wed 18 May ? ? , Arnd Bergmann wrote:
>> This is the draft plan for maintaining the ARM subarchitectures in a common
>> tree, as a way to help coordinate the upstream merging of the
>> arch/arm/{plat,mach}-* changes into Linus' tree.
>
> How do you plan to manage with already sub arch maintainers?
>
> In my ming such tree could be good to organise cross arch drivers
> but for real arch specific the current workflow is good
>
> If we add a new stage it will be difficult to follow for people
>
> I'd like to have scenario example where such workflow will give a significant
> advantage compare to the current workflow. And please real example.

I'll let Arnd and the other members of this group come up with real
examples. In the meantime I'll give my view on this.

The aim is not to hide existing sub-architecture patches behind
another git tree so that people won't notice the conflicts. It's not
just a workflow change, the Acked-by mechanism may have worked as
well, though some people may skip it (even unintentionally).

There is a lot of code duplication between various sub-architectures
under arch/arm/ and this group, together with the sub-arch
maintainers, will try to consolidate this, move common code out into
drivers/ so that it can be easily shared, start moving platforms to
FDT etc. (they could give a roadmap but it's early stages now). This
needs to be a coordinated effort and the group will ensure that the
general direction of code reduction is followed by all the current and
new sub-arch maintainers.

A lot of platform ports have been done just by copying existing code
without any effort in exploiting the commonality. This could be
spotted much easier with a dedicated group of people and guide the
sub-arch maintainers in the write direction. It may be even quicker
for them to get code merged into drivers/ where applicable.

I expect the activity of this group to be reduced in the future, once
the consolidation work is complete (but that's not a trivial task). At
that point maybe one or two people would just keep an eye on what gets
pushed into mainline in sub-arch directories and sub-arch maintainers
would just work as before, sending pull requests to Linus directly.

As the incentive for existing sub-arch maintainers to agree with this
strategy - given Linus' recent comments on the ARM sub-arch trees, it
is possible that he won't merge such trees pushed directly to him if
they don't show a consistent direction towards code consolidation. I
think this group and tree would actually make upstream pushing
quicker.

-- 
Catalin

Re: [RFC] ARM Subarchitecture group maintainership

[Barry Song]

2011/5/18 Arnd Bergmann <arnd@arndb.de>:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
>
> This was discussed in great length at the Linaro Developer Summit in Budapest
> last week where we worked out an initial plan. We are modeling the maintainance
> after how the linux-tip tree is used for the x86 architecture, with a set
> of developers that have commit access to one tree on kernel.org and
> have mutual trust in one another. Nicolas Pitre and me are funded
> by Linaro to do the bulk of the work, while Thomas Gleixner will help
> us part-time with his long time architecture maintainance experience.
> Despite the funding by Linaro, this is not a Linaro project and all
> ARM subarchitectures are welcome to go through our tree.
>
> Russell King's role as ARM maintainer is of course unchanged by this, but
> he has the same commit access to the new tree as the other maintainers and
> is welcome to work in the same tree. We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google. We have to find the right balance with the
> number of committers so we get all the work done without stepping on each
> other's toes.
>
> Our tree will be strictly organized in topic brances so we can feed them
> upstream in the bitesized chunks that Linus likes. The master branch
> is an integration branch that pulls all other branches that are scheduled
> for the next merge window and itself gets integrated into linux-next.
>
> We will probably not be fully functional during the 2.6.40 merge window,
> but we are trying our best to be useful. For 2.6.41, my hope is that
> we can merge the bulk of the ARM subarchitecture changes through this
> tree. Once Linus is happy with the way that the process works, we can
> mandate that all ARM subarchitecture changes go through our tree, until
> then it stays voluntary.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
>
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S: Maintained
>  F:     drivers/amba/
>  F:     include/linux/amba/bus.h
>
> +ARM SUBARCHITECTURES
> +M:     Arnd Bergmann <arnd@arndb.de>
> +M:     Nicolas Pitre <nico@fluxnic.net>
> +M:     Thomas Gleixner <tglx@linutronix.de>
> +M:     arm@kernel.org
> +L:     linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S:     MAINTAINEDftp.arm.linux.org.uk Git - linux-2.6-arm.git/summary
> +F:     arch/arm/mach-*/
> +F:     arch/arm/plat-*/
> +T:     git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> +

does it mean if we want to add a new SoC plat/mach, we will send
patches againest this tree?
will this tree merge into rmk's tree? then rmk's tree will only manage
arm common codes?

>  ARM/ADI ROADRUNNER MACHINE SUPPORT
>  M:     Lennert Buytenhek <kernel@wantstofly.org>
>  L:     linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[RFC] ARM Subarchitecture group maintainership

[Barry Song]

2011/5/18 Arnd Bergmann <arnd@arndb.de>:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
>
> This was discussed in great length at the Linaro Developer Summit in Budapest
> last week where we worked out an initial plan. We are modeling the maintainance
> after how the linux-tip tree is used for the x86 architecture, with a set
> of developers that have commit access to one tree on kernel.org and
> have mutual trust in one another. Nicolas Pitre and me are funded
> by Linaro to do the bulk of the work, while Thomas Gleixner will help
> us part-time with his long time architecture maintainance experience.
> Despite the funding by Linaro, this is not a Linaro project and all
> ARM subarchitectures are welcome to go through our tree.
>
> Russell King's role as ARM maintainer is of course unchanged by this, but
> he has the same commit access to the new tree as the other maintainers and
> is welcome to work in the same tree. We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google. We have to find the right balance with the
> number of committers so we get all the work done without stepping on each
> other's toes.
>
> Our tree will be strictly organized in topic brances so we can feed them
> upstream in the bitesized chunks that Linus likes. The master branch
> is an integration branch that pulls all other branches that are scheduled
> for the next merge window and itself gets integrated into linux-next.
>
> We will probably not be fully functional during the 2.6.40 merge window,
> but we are trying our best to be useful. For 2.6.41, my hope is that
> we can merge the bulk of the ARM subarchitecture changes through this
> tree. Once Linus is happy with the way that the process works, we can
> mandate that all ARM subarchitecture changes go through our tree, until
> then it stays voluntary.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
>
> ---
>
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S: Maintained
> ?F: ? ? drivers/amba/
> ?F: ? ? include/linux/amba/bus.h
>
> +ARM SUBARCHITECTURES
> +M: ? ? Arnd Bergmann <arnd@arndb.de>
> +M: ? ? Nicolas Pitre <nico@fluxnic.net>
> +M: ? ? Thomas Gleixner <tglx@linutronix.de>
> +M: ? ? arm at kernel.org
> +L: ? ? linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S: ? ? MAINTAINEDftp.arm.linux.org.uk Git - linux-2.6-arm.git/summary
> +F: ? ? arch/arm/mach-*/
> +F: ? ? arch/arm/plat-*/
> +T: ? ? git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> +

does it mean if we want to add a new SoC plat/mach, we will send
patches againest this tree?
will this tree merge into rmk's tree? then rmk's tree will only manage
arm common codes?

> ?ARM/ADI ROADRUNNER MACHINE SUPPORT
> ?M: ? ? Lennert Buytenhek <kernel@wantstofly.org>
> ?L: ? ? linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Re: [RFC] ARM Subarchitecture group maintainership

[Nicolas Pitre]

On Thu, 19 May 2011, Barry Song wrote:

> does it mean if we want to add a new SoC plat/mach, we will send
> patches againest this tree?

Yes.  Or against latest mainline tree from Linus.

> will this tree merge into rmk's tree? then rmk's tree will only manage
> arm common codes?

Something like that.  The exact details will be fleshed out as we go. 
The idea is to give a round of review from a higher point of view to 
make sure no opportunities for code reuse is missed, etc.  The mechanics 
of how this code transitions from this tree into mainline during the 
merge window is secondary.


Nicolas

[RFC] ARM Subarchitecture group maintainership

[Nicolas Pitre]

On Thu, 19 May 2011, Barry Song wrote:

> does it mean if we want to add a new SoC plat/mach, we will send
> patches againest this tree?

Yes.  Or against latest mainline tree from Linus.

> will this tree merge into rmk's tree? then rmk's tree will only manage
> arm common codes?

Something like that.  The exact details will be fleshed out as we go. 
The idea is to give a round of review from a higher point of view to 
make sure no opportunities for code reuse is missed, etc.  The mechanics 
of how this code transitions from this tree into mainline during the 
merge window is secondary.


Nicolas

Re: [RFC] ARM Subarchitecture group maintainership

[Barry Song]

Hi Nicolas,
Thanks for your reply.

2011/5/19 Nicolas Pitre <nico@fluxnic.net>:
> On Thu, 19 May 2011, Barry Song wrote:
>
>> does it mean if we want to add a new SoC plat/mach, we will send
>> patches againest this tree?
>
> Yes.  Or against latest mainline tree from Linus.
>
>> will this tree merge into rmk's tree? then rmk's tree will only manage
>> arm common codes?
>
> Something like that.  The exact details will be fleshed out as we go.
> The idea is to give a round of review from a higher point of view to
> make sure no opportunities for code reuse is missed, etc.  The mechanics
> of how this code transitions from this tree into mainline during the
> merge window is secondary.

i asked this because we wanted to send the source codes of
CSR(http://www.csr.com) to upstream as i have told you in LDS. it
looks like we need to follow the below new changes to make our source
codes acceptable?
1. arm device tree
2. new pinmux framework from Linus Walleij
3. move GPIO from plat/mach to drivers/gpio?

>
>
> Nicolas
-barry

[RFC] ARM Subarchitecture group maintainership

[Barry Song]

Hi Nicolas,
Thanks for your reply.

2011/5/19 Nicolas Pitre <nico@fluxnic.net>:
> On Thu, 19 May 2011, Barry Song wrote:
>
>> does it mean if we want to add a new SoC plat/mach, we will send
>> patches againest this tree?
>
> Yes. ?Or against latest mainline tree from Linus.
>
>> will this tree merge into rmk's tree? then rmk's tree will only manage
>> arm common codes?
>
> Something like that. ?The exact details will be fleshed out as we go.
> The idea is to give a round of review from a higher point of view to
> make sure no opportunities for code reuse is missed, etc. ?The mechanics
> of how this code transitions from this tree into mainline during the
> merge window is secondary.

i asked this because we wanted to send the source codes of
CSR(http://www.csr.com) to upstream as i have told you in LDS. it
looks like we need to follow the below new changes to make our source
codes acceptable?
1. arm device tree
2. new pinmux framework from Linus Walleij
3. move GPIO from plat/mach to drivers/gpio?

>
>
> Nicolas
-barry

Re: [RFC] ARM Subarchitecture group maintainership

[viresh kumar]

On 05/18/2011 02:17 PM, Arnd Bergmann wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S:	Maintained
>  F:	drivers/amba/
>  F:	include/linux/amba/bus.h
>  
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm@kernel.org
> +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED
> +F:	arch/arm/mach-*/
> +F:	arch/arm/plat-*/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> +

Acked-by: Viresh Kumar <viresh.kumar@st.com>
(As Maintainer of SPEAr Soc from ST Microelectronics)

-- 
viresh

[RFC] ARM Subarchitecture group maintainership

[viresh kumar]

On 05/18/2011 02:17 PM, Arnd Bergmann wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S:	Maintained
>  F:	drivers/amba/
>  F:	include/linux/amba/bus.h
>  
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm at kernel.org
> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED
> +F:	arch/arm/mach-*/
> +F:	arch/arm/plat-*/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> +

Acked-by: Viresh Kumar <viresh.kumar@st.com>
(As Maintainer of SPEAr Soc from ST Microelectronics)

-- 
viresh

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Wednesday 18 May 2011, Shawn Guo wrote:
> On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> [...]
> > +ARM SUBARCHITECTURES
> > +M:	Arnd Bergmann <arnd@arndb.de>
> > +M:	Nicolas Pitre <nico@fluxnic.net>
> > +M:	Thomas Gleixner <tglx@linutronix.de>
> > +M:	arm@kernel.org
> > +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> > +S:	MAINTAINED
> > +F:	arch/arm/mach-*/
> > +F:	arch/arm/plat-*/
> > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> 
> Is this repository ready for use yet?  It seems not for me.

No, not yet. Once we are sure about the initial set of people in the group,
we can set up the arm@kernel.org alias and the group that lets us write
into the /pub/scm/linux/kernel/git/arm directory.

Also, I wouldn't mind changing the name, if someone comes up with a better
term than arm-subarch.git.

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Wednesday 18 May 2011, Shawn Guo wrote:
> On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> [...]
> > +ARM SUBARCHITECTURES
> > +M:	Arnd Bergmann <arnd@arndb.de>
> > +M:	Nicolas Pitre <nico@fluxnic.net>
> > +M:	Thomas Gleixner <tglx@linutronix.de>
> > +M:	arm at kernel.org
> > +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> > +S:	MAINTAINED
> > +F:	arch/arm/mach-*/
> > +F:	arch/arm/plat-*/
> > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> 
> Is this repository ready for use yet?  It seems not for me.

No, not yet. Once we are sure about the initial set of people in the group,
we can set up the arm at kernel.org alias and the group that lets us write
into the /pub/scm/linux/kernel/git/arm directory.

Also, I wouldn't mind changing the name, if someone comes up with a better
term than arm-subarch.git.

	Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Thursday 19 May 2011, Barry Song wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8fce5e6..942d052 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -630,6 +630,17 @@ S: Maintained
> >  F:     drivers/amba/
> >  F:     include/linux/amba/bus.h
> >
> > +ARM SUBARCHITECTURES
> > +M:     Arnd Bergmann <arnd@arndb.de>
> > +M:     Nicolas Pitre <nico@fluxnic.net>
> > +M:     Thomas Gleixner <tglx@linutronix.de>
> > +M:     arm@kernel.org
> > +L:     linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> > +S:     MAINTAINEDftp.arm.linux.org.uk Git - linux-2.6-arm.git/summary
> > +F:     arch/arm/mach-*/
> > +F:     arch/arm/plat-*/
> > +T:     git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> > +
> 
> does it mean if we want to add a new SoC plat/mach, we will send
> patches againest this tree?

You should submit it for inclusion into this tree, but as a new branch
(or multiple branches) forked off from the mainline tree. We will make sure
it cleanly merges with the other subarchitectures.

> will this tree merge into rmk's tree? then rmk's tree will only manage
> arm common codes?

We'll see. My current idea is that we will push all subarchitecture branches
upstream to Linus directly, while Russell pushes the core branch(es) upstream
in parallel, but the master branch of the subarch tree could end up pulling
in the core tree as well, in order to make life easier for Stephen's
linux-next tree that needs both. This depends to some degree on whether
Russell wants to keep some subarchitectures in his own tree, or we put all
of them in the new subarch tree.

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Thursday 19 May 2011, Barry Song wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8fce5e6..942d052 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -630,6 +630,17 @@ S: Maintained
> >  F:     drivers/amba/
> >  F:     include/linux/amba/bus.h
> >
> > +ARM SUBARCHITECTURES
> > +M:     Arnd Bergmann <arnd@arndb.de>
> > +M:     Nicolas Pitre <nico@fluxnic.net>
> > +M:     Thomas Gleixner <tglx@linutronix.de>
> > +M:     arm at kernel.org
> > +L:     linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> > +S:     MAINTAINEDftp.arm.linux.org.uk Git - linux-2.6-arm.git/summary
> > +F:     arch/arm/mach-*/
> > +F:     arch/arm/plat-*/
> > +T:     git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> > +
> 
> does it mean if we want to add a new SoC plat/mach, we will send
> patches againest this tree?

You should submit it for inclusion into this tree, but as a new branch
(or multiple branches) forked off from the mainline tree. We will make sure
it cleanly merges with the other subarchitectures.

> will this tree merge into rmk's tree? then rmk's tree will only manage
> arm common codes?

We'll see. My current idea is that we will push all subarchitecture branches
upstream to Linus directly, while Russell pushes the core branch(es) upstream
in parallel, but the master branch of the subarch tree could end up pulling
in the core tree as well, in order to make life easier for Stephen's
linux-next tree that needs both. This depends to some degree on whether
Russell wants to keep some subarchitectures in his own tree, or we put all
of them in the new subarch tree.

	Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Linus Walleij]

On Thu, May 19, 2011 at 5:01 AM, Barry Song <21cnbao@gmail.com> wrote:

> i asked this because we wanted to send the source codes of
> CSR(http://www.csr.com) to upstream as i have told you in LDS. it
> looks like we need to follow the below new changes to make our source
> codes acceptable?
> 1. arm device tree
> 2. new pinmux framework from Linus Walleij

I'm working on that to post a new v3 of this patch set ASAP, if the
ARM subarch tree maintainers are interested I can send them a
pull request after that.

Yours,
Linus Walleij

[RFC] ARM Subarchitecture group maintainership

[Linus Walleij]

On Thu, May 19, 2011 at 5:01 AM, Barry Song <21cnbao@gmail.com> wrote:

> i asked this because we wanted to send the source codes of
> CSR(http://www.csr.com) to upstream as i have told you in LDS. it
> looks like we need to follow the below new changes to make our source
> codes acceptable?
> 1. arm device tree
> 2. new pinmux framework from Linus Walleij

I'm working on that to post a new v3 of this patch set ASAP, if the
ARM subarch tree maintainers are interested I can send them a
pull request after that.

Yours,
Linus Walleij

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Thursday 19 May 2011, Barry Song wrote:
> 2011/5/19 Nicolas Pitre <nico@fluxnic.net>:
> > On Thu, 19 May 2011, Barry Song wrote:
> > Something like that.  The exact details will be fleshed out as we go.
> > The idea is to give a round of review from a higher point of view to
> > make sure no opportunities for code reuse is missed, etc.  The mechanics
> > of how this code transitions from this tree into mainline during the
> > merge window is secondary.
> 
> i asked this because we wanted to send the source codes of
> CSR(http://www.csr.com) to upstream as i have told you in LDS. it
> looks like we need to follow the below new changes to make our source
> codes acceptable?
> 1. arm device tree
> 2. new pinmux framework from Linus Walleij
> 3. move GPIO from plat/mach to drivers/gpio?

I would count at least the last two as mandatory, for the device tree,
it depends on how much work it would be for you to do the conversion
and at what time you submit the series. The longer you wait before
submitting the series, the stricter the requirements will get.

Do you have a diffstat or a git tree with your work available?

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Thursday 19 May 2011, Barry Song wrote:
> 2011/5/19 Nicolas Pitre <nico@fluxnic.net>:
> > On Thu, 19 May 2011, Barry Song wrote:
> > Something like that.  The exact details will be fleshed out as we go.
> > The idea is to give a round of review from a higher point of view to
> > make sure no opportunities for code reuse is missed, etc.  The mechanics
> > of how this code transitions from this tree into mainline during the
> > merge window is secondary.
> 
> i asked this because we wanted to send the source codes of
> CSR(http://www.csr.com) to upstream as i have told you in LDS. it
> looks like we need to follow the below new changes to make our source
> codes acceptable?
> 1. arm device tree
> 2. new pinmux framework from Linus Walleij
> 3. move GPIO from plat/mach to drivers/gpio?

I would count at least the last two as mandatory, for the device tree,
it depends on how much work it would be for you to do the conversion
and at what time you submit the series. The longer you wait before
submitting the series, the stricter the requirements will get.

Do you have a diffstat or a git tree with your work available?

	Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Barry Song]

2011/5/19 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 19 May 2011, Barry Song wrote:
>> 2011/5/19 Nicolas Pitre <nico@fluxnic.net>:
>> > On Thu, 19 May 2011, Barry Song wrote:
>> > Something like that.  The exact details will be fleshed out as we go.
>> > The idea is to give a round of review from a higher point of view to
>> > make sure no opportunities for code reuse is missed, etc.  The mechanics
>> > of how this code transitions from this tree into mainline during the
>> > merge window is secondary.
>>
>> i asked this because we wanted to send the source codes of
>> CSR(http://www.csr.com) to upstream as i have told you in LDS. it
>> looks like we need to follow the below new changes to make our source
>> codes acceptable?
>> 1. arm device tree
>> 2. new pinmux framework from Linus Walleij
>> 3. move GPIO from plat/mach to drivers/gpio?
>
> I would count at least the last two as mandatory, for the device tree,
> it depends on how much work it would be for you to do the conversion
> and at what time you submit the series. The longer you wait before
> submitting the series, the stricter the requirements will get.
>
> Do you have a diffstat or a git tree with your work available?

not yet by now. it should be coming in the middle of next month. we
have workable codes but need a lot of refinations before sending
patches for review. it is more like a new begin from scratch, so
arm/arch changes should be things we can catch.

>
>        Arnd
>

[RFC] ARM Subarchitecture group maintainership

[Barry Song]

2011/5/19 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 19 May 2011, Barry Song wrote:
>> 2011/5/19 Nicolas Pitre <nico@fluxnic.net>:
>> > On Thu, 19 May 2011, Barry Song wrote:
>> > Something like that. ?The exact details will be fleshed out as we go.
>> > The idea is to give a round of review from a higher point of view to
>> > make sure no opportunities for code reuse is missed, etc. ?The mechanics
>> > of how this code transitions from this tree into mainline during the
>> > merge window is secondary.
>>
>> i asked this because we wanted to send the source codes of
>> CSR(http://www.csr.com) to upstream as i have told you in LDS. it
>> looks like we need to follow the below new changes to make our source
>> codes acceptable?
>> 1. arm device tree
>> 2. new pinmux framework from Linus Walleij
>> 3. move GPIO from plat/mach to drivers/gpio?
>
> I would count at least the last two as mandatory, for the device tree,
> it depends on how much work it would be for you to do the conversion
> and at what time you submit the series. The longer you wait before
> submitting the series, the stricter the requirements will get.
>
> Do you have a diffstat or a git tree with your work available?

not yet by now. it should be coming in the middle of next month. we
have workable codes but need a lot of refinations before sending
patches for review. it is more like a new begin from scratch, so
arm/arch changes should be things we can catch.

>
> ? ? ? ?Arnd
>

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Thursday 19 May 2011, Barry Song wrote:
> >
> > Do you have a diffstat or a git tree with your work available?
> 
> not yet by now. it should be coming in the middle of next month. we
> have workable codes but need a lot of refinations before sending
> patches for review. it is more like a new begin from scratch, so
> arm/arch changes should be things we can catch.

I'd like to make sure that you are not doing duplicate work by
going in a wrong direction with this, so I think it would be best
to post as early as possible, ideally with a list of things that
you already know you need to change, so people don't need to comment
on them.

If you can just post a diffstat of the stuff you currently have,
we also get an impression of the amount of code that you are
talking about.

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Thursday 19 May 2011, Barry Song wrote:
> >
> > Do you have a diffstat or a git tree with your work available?
> 
> not yet by now. it should be coming in the middle of next month. we
> have workable codes but need a lot of refinations before sending
> patches for review. it is more like a new begin from scratch, so
> arm/arch changes should be things we can catch.

I'd like to make sure that you are not doing duplicate work by
going in a wrong direction with this, so I think it would be best
to post as early as possible, ideally with a list of things that
you already know you need to change, so people don't need to comment
on them.

If you can just post a diffstat of the stuff you currently have,
we also get an impression of the amount of code that you are
talking about.

	Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Russell King - ARM Linux]

On Thu, May 19, 2011 at 03:31:42PM +0200, Linus Walleij wrote:
> On Thu, May 19, 2011 at 5:01 AM, Barry Song <21cnbao@gmail.com> wrote:
> 
> > i asked this because we wanted to send the source codes of
> > CSR(http://www.csr.com) to upstream as i have told you in LDS. it
> > looks like we need to follow the below new changes to make our source
> > codes acceptable?
> > 1. arm device tree
> > 2. new pinmux framework from Linus Walleij
> 
> I'm working on that to post a new v3 of this patch set ASAP, if the
> ARM subarch tree maintainers are interested I can send them a
> pull request after that.

As my tree currently contains a large proportion of the consolidation work
so far, it probably makes sense for this stuff to continue coming through
my tree so that we can sort out any merge conflicts there, rather than
starting on a new tree... It probably makes sense for the subarch tree to
get going after this merge window has closed.

[RFC] ARM Subarchitecture group maintainership

[Russell King - ARM Linux]

On Thu, May 19, 2011 at 03:31:42PM +0200, Linus Walleij wrote:
> On Thu, May 19, 2011 at 5:01 AM, Barry Song <21cnbao@gmail.com> wrote:
> 
> > i asked this because we wanted to send the source codes of
> > CSR(http://www.csr.com) to upstream as i have told you in LDS. it
> > looks like we need to follow the below new changes to make our source
> > codes acceptable?
> > 1. arm device tree
> > 2. new pinmux framework from Linus Walleij
> 
> I'm working on that to post a new v3 of this patch set ASAP, if the
> ARM subarch tree maintainers are interested I can send them a
> pull request after that.

As my tree currently contains a large proportion of the consolidation work
so far, it probably makes sense for this stuff to continue coming through
my tree so that we can sort out any merge conflicts there, rather than
starting on a new tree... It probably makes sense for the subarch tree to
get going after this merge window has closed.

Re: [RFC] ARM Subarchitecture group maintainership

[Nicolas Pitre]

On Thu, 19 May 2011, Russell King - ARM Linux wrote:

> On Thu, May 19, 2011 at 03:31:42PM +0200, Linus Walleij wrote:
> > On Thu, May 19, 2011 at 5:01 AM, Barry Song <21cnbao@gmail.com> wrote:
> > 
> > > i asked this because we wanted to send the source codes of
> > > CSR(http://www.csr.com) to upstream as i have told you in LDS. it
> > > looks like we need to follow the below new changes to make our source
> > > codes acceptable?
> > > 1. arm device tree
> > > 2. new pinmux framework from Linus Walleij
> > 
> > I'm working on that to post a new v3 of this patch set ASAP, if the
> > ARM subarch tree maintainers are interested I can send them a
> > pull request after that.
> 
> As my tree currently contains a large proportion of the consolidation work
> so far, it probably makes sense for this stuff to continue coming through
> my tree so that we can sort out any merge conflicts there, rather than
> starting on a new tree... It probably makes sense for the subarch tree to
> get going after this merge window has closed.

Agreed.


Nicolas

[RFC] ARM Subarchitecture group maintainership

[Nicolas Pitre]

On Thu, 19 May 2011, Russell King - ARM Linux wrote:

> On Thu, May 19, 2011 at 03:31:42PM +0200, Linus Walleij wrote:
> > On Thu, May 19, 2011 at 5:01 AM, Barry Song <21cnbao@gmail.com> wrote:
> > 
> > > i asked this because we wanted to send the source codes of
> > > CSR(http://www.csr.com) to upstream as i have told you in LDS. it
> > > looks like we need to follow the below new changes to make our source
> > > codes acceptable?
> > > 1. arm device tree
> > > 2. new pinmux framework from Linus Walleij
> > 
> > I'm working on that to post a new v3 of this patch set ASAP, if the
> > ARM subarch tree maintainers are interested I can send them a
> > pull request after that.
> 
> As my tree currently contains a large proportion of the consolidation work
> so far, it probably makes sense for this stuff to continue coming through
> my tree so that we can sort out any merge conflicts there, rather than
> starting on a new tree... It probably makes sense for the subarch tree to
> get going after this merge window has closed.

Agreed.


Nicolas

Re: [RFC] ARM Subarchitecture group maintainership

[Linus Walleij]

2011/5/18 Arnd Bergmann <arnd@arndb.de>:

> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S: Maintained
>  F:     drivers/amba/
>  F:     include/linux/amba/bus.h
>
> +ARM SUBARCHITECTURES
> +M:     Arnd Bergmann <arnd@arndb.de>
> +M:     Nicolas Pitre <nico@fluxnic.net>
> +M:     Thomas Gleixner <tglx@linutronix.de>
> +M:     arm@kernel.org
> +L:     linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S:     MAINTAINED
> +F:     arch/arm/mach-*/
> +F:     arch/arm/plat-*/
> +T:     git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Thanks,
Linus Walleij

[RFC] ARM Subarchitecture group maintainership

[Linus Walleij]

2011/5/18 Arnd Bergmann <arnd@arndb.de>:

> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S: Maintained
> ?F: ? ? drivers/amba/
> ?F: ? ? include/linux/amba/bus.h
>
> +ARM SUBARCHITECTURES
> +M: ? ? Arnd Bergmann <arnd@arndb.de>
> +M: ? ? Nicolas Pitre <nico@fluxnic.net>
> +M: ? ? Thomas Gleixner <tglx@linutronix.de>
> +M: ? ? arm at kernel.org
> +L: ? ? linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S: ? ? MAINTAINED
> +F: ? ? arch/arm/mach-*/
> +F: ? ? arch/arm/plat-*/
> +T: ? ? git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Thanks,
Linus Walleij

Re: [RFC] ARM Subarchitecture group maintainership

[Joe Perches]

On Wed, 2011-05-18 at 10:47 +0200, Arnd Bergmann wrote:
> otherwise please comment.
> diff --git a/MAINTAINERS b/MAINTAINERS
> @@ -630,6 +630,17 @@ S:	Maintained
>  F:	drivers/amba/
>  F:	include/linux/amba/bus.h
>  
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm@kernel.org
> +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED

Trivial.  Please use:

S:	Maintained

[RFC] ARM Subarchitecture group maintainership

[Joe Perches]

On Wed, 2011-05-18 at 10:47 +0200, Arnd Bergmann wrote:
> otherwise please comment.
> diff --git a/MAINTAINERS b/MAINTAINERS
> @@ -630,6 +630,17 @@ S:	Maintained
>  F:	drivers/amba/
>  F:	include/linux/amba/bus.h
>  
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm at kernel.org
> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED

Trivial.  Please use:

S:	Maintained

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Friday 20 May 2011 22:59:45 Joe Perches wrote:
> On Wed, 2011-05-18 at 10:47 +0200, Arnd Bergmann wrote:
> > +S:   MAINTAINED
> 
> Trivial.  Please use:
> 
> S:      Maintained
> 

Thanks!

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Friday 20 May 2011 22:59:45 Joe Perches wrote:
> On Wed, 2011-05-18 at 10:47 +0200, Arnd Bergmann wrote:
> > +S:   MAINTAINED
> 
> Trivial.  Please use:
> 
> S:      Maintained
> 

Thanks!

	Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Barry Song]

2011/5/19 Arnd Bergmann <arnd@arndb.de>
>
> On Thursday 19 May 2011, Barry Song wrote:
> > >
> > > Do you have a diffstat or a git tree with your work available?
> >
> > not yet by now. it should be coming in the middle of next month. we
> > have workable codes but need a lot of refinations before sending
> > patches for review. it is more like a new begin from scratch, so
> > arm/arch changes should be things we can catch.
>
> I'd like to make sure that you are not doing duplicate work by
> going in a wrong direction with this, so I think it would be best
> to post as early as possible, ideally with a list of things that
> you already know you need to change, so people don't need to comment
> on them.
>
> If you can just post a diffstat of the stuff you currently have,
> we also get an impression of the amount of code that you are
> talking about.
Arnd, thanks very much for thinking. Now the codes are based on 2.6.38
and not quanified for sending patches. we will port them to be
againest linux's tree.
current diffstat for arch/arm againest 2.6.38 mainline is
 Kconfig                                                      |   34
 Makefile                                                     |    5
 common/Makefile                                              |    1
 common/sirfsoc.c                                             |   21
 configs/prima2cb_defconfig                                   | 1903 +++++++++++
 include/asm/dma.h                                            |   10
 include/asm/mach/dma.h                                       |    7
 kernel/dma.c                                                 |   47
 kernel/vmlinux.lds                                           |  488 ++
 mach-prima2/Kconfig                                          |   32
 mach-prima2/Makefile                                         |   11
 mach-prima2/Makefile.boot                                    |    3
 mach-prima2/devices.c                                        |  191 +
 mach-prima2/include/mach/cache-sirfsoc-prima2-l2.h           |   12
 mach-prima2/include/mach/clkdev.h                            |    5
 mach-prima2/include/mach/debug-macro.S                       |   38
 mach-prima2/include/mach/entry-macro.S                       |   31
 mach-prima2/include/mach/gpio.h                              |    5
 mach-prima2/include/mach/hardware.h                          |   10
 mach-prima2/include/mach/io.h                                |   20
 mach-prima2/include/mach/irqs.h                              |  284 +
 mach-prima2/include/mach/isa-dma.h                           |   13
 mach-prima2/include/mach/map.h                               |  263 +
 mach-prima2/include/mach/memory.h                            |   56
 mach-prima2/include/mach/prima2.h                            |   20
 mach-prima2/include/mach/prima2_pinmux.h                     |   39
 mach-prima2/include/mach/prima2cb.h                          |  111
 mach-prima2/include/mach/regs-iobrg.h                        |   54
 mach-prima2/include/mach/regs-irq.h                          |   42
 mach-prima2/include/mach/regs-reset.h                        |   88
 mach-prima2/include/mach/regs-rsc.h                          |   76
 mach-prima2/include/mach/system.h                            |    5
 mach-prima2/include/mach/timex.h                             |    5
 mach-prima2/include/mach/uncompress.h                        |   45
 mach-prima2/include/mach/vmalloc.h                           |   19
 mach-prima2/lcdinit.c                                        |  136
 mach-prima2/mach-prima2cb.c                                  |  226 +
 mach-prima2/padmode.c                                        |  139
 mach-prima2/prima2.c                                         |   81
 mach-prima2/prima2cb-keypad.c                                |  136
 mach-prima2/pwrc.c                                           |  286 +
 mach-prima2/tsc2100_dev.c                                    |  137
 mm/Kconfig                                                   |   13
 mm/Makefile                                                  |    1
 mm/cache-sirfsoc-prima2-l2.c                                 |  342 +
 plat-sirfsoc/Kconfig                                         |  108
 plat-sirfsoc/Makefile                                        |   34
 plat-sirfsoc/adc.c                                           | 1395 ++++++++
 plat-sirfsoc/adcprocfs.c                                     |  348 ++
 plat-sirfsoc/apm.c                                           |  107
 plat-sirfsoc/clock.c                                         | 1045 ++++++
 plat-sirfsoc/clock.h                                         |   32
 plat-sirfsoc/core.c                                          |  245 +
 plat-sirfsoc/cpufreq.c                                       |  239 +
 plat-sirfsoc/deepsleep.S                                     |  425 ++
 plat-sirfsoc/dma.c                                           |  386 ++
 plat-sirfsoc/hibernate.h                                     |  118
 plat-sirfsoc/include/plat/audio_controller.h                 |  333 +
 plat-sirfsoc/include/plat/belmont.h                          |   92
 plat-sirfsoc/include/plat/bootmem.h                          |   45
 plat-sirfsoc/include/plat/clkdev.h                           |   15
 plat-sirfsoc/include/plat/cpld.h                             |   27
 plat-sirfsoc/include/plat/cpld_evb.h                         |  200 +
 plat-sirfsoc/include/plat/cpld_fpga.h                        |  201 +
 plat-sirfsoc/include/plat/cpu.h                              |   51
 plat-sirfsoc/include/plat/debug-macro.S                      |   34
 plat-sirfsoc/include/plat/gpio.h                             |   92
 plat-sirfsoc/include/plat/hardware.h                         |   28
 plat-sirfsoc/include/plat/iobrg.h                            |   17
 plat-sirfsoc/include/plat/irqs.h                             |  320 +
 plat-sirfsoc/include/plat/isa-dma.h                          |  111
 plat-sirfsoc/include/plat/lcd_panels.h                       |   33
 plat-sirfsoc/include/plat/map.h                              |  233 +
 plat-sirfsoc/include/plat/memory.h                           |   43
 plat-sirfsoc/include/plat/perfmon.h                          |   62
 plat-sirfsoc/include/plat/pinmux.h                           |   23
 plat-sirfsoc/include/plat/platform_device/android_usb_dev.h  |   27
 plat-sirfsoc/include/plat/platform_device/audio.h            |   28
 plat-sirfsoc/include/plat/platform_device/bt_codec.h         |   26
 plat-sirfsoc/include/plat/platform_device/eth.h              |   26
 plat-sirfsoc/include/plat/platform_device/gps.h              |   40
 plat-sirfsoc/include/plat/platform_device/i2c.h              |   27
 plat-sirfsoc/include/plat/platform_device/inner_audio.h      |   26
 plat-sirfsoc/include/plat/platform_device/lcd.h              |   85
 plat-sirfsoc/include/plat/platform_device/mbx.h              |   37
 plat-sirfsoc/include/plat/platform_device/modac.h            |   26
 plat-sirfsoc/include/plat/platform_device/mved.h             |   36
 plat-sirfsoc/include/plat/platform_device/nand.h             |   27
 plat-sirfsoc/include/plat/platform_device/pmem.h             |   27
 plat-sirfsoc/include/plat/platform_device/pwm_dev.h          |   31
 plat-sirfsoc/include/plat/platform_device/rtc.h              |   27
 plat-sirfsoc/include/plat/platform_device/sata.h             |   33
 plat-sirfsoc/include/plat/platform_device/sd.h               |   31
 plat-sirfsoc/include/plat/platform_device/serial.h           |   82
 plat-sirfsoc/include/plat/platform_device/sirfsoc_ts.h       |   31
 plat-sirfsoc/include/plat/platform_device/snd.h              |   30
 plat-sirfsoc/include/plat/platform_device/spi.h              |   53
 plat-sirfsoc/include/plat/platform_device/spi_sirfsoc_gpio.h |   34
 plat-sirfsoc/include/plat/platform_device/ts_stream_mode.h   |   26
 plat-sirfsoc/include/plat/platform_device/usb.h              |   40
 plat-sirfsoc/include/plat/platform_device/usppcm.h           |   25
 plat-sirfsoc/include/plat/platform_device/uspserial.h        |   45
 plat-sirfsoc/include/plat/platform_device/uspspi.h           |   33
 plat-sirfsoc/include/plat/platform_device/vpp.h              |   27
 plat-sirfsoc/include/plat/platform_device/vxd.h              |   27
 plat-sirfsoc/include/plat/platform_device/wdt.h              |   26
 plat-sirfsoc/include/plat/pm.h                               |   41
 plat-sirfsoc/include/plat/pwm.h                              |   63
 plat-sirfsoc/include/plat/regs-clkc.h                        |   33
 plat-sirfsoc/include/plat/regs-gpio.h                        |   43
 plat-sirfsoc/include/plat/regs-irq.h                         |   39
 plat-sirfsoc/include/plat/regs-modac.h                       |  114
 plat-sirfsoc/include/plat/regs-power.h                       |   77
 plat-sirfsoc/include/plat/regs-pwm.h                         |   37
 plat-sirfsoc/include/plat/regs-pwrc.h                        |   62
 plat-sirfsoc/include/plat/regs-reset.h                       |   73
 plat-sirfsoc/include/plat/regs-rsc.h                         |   78
 plat-sirfsoc/include/plat/regs-rtc.h                         |   41
 plat-sirfsoc/include/plat/regs-serial.h                      |   87
 plat-sirfsoc/include/plat/regs-timer.h                       |   39
 plat-sirfsoc/include/plat/regs-vip.h                         |   98
 plat-sirfsoc/include/plat/sd.h                               |  110
 plat-sirfsoc/include/plat/sirfsoc_adc.h                      |  261 +
 plat-sirfsoc/include/plat/sirfsoc_usp.h                      |  288 +
 plat-sirfsoc/include/plat/system.h                           |   39
 plat-sirfsoc/include/plat/timex.h                            |   33
 plat-sirfsoc/include/plat/uncompress.h                       |   46
 plat-sirfsoc/include/plat/vmalloc.h                          |   26
 plat-sirfsoc/irq.c                                           |  102
 plat-sirfsoc/lcd_panels.c                                    |  281 +
 plat-sirfsoc/led.c                                           |  340 +
 plat-sirfsoc/perfmon.c                                       | 1347 +++++++
 plat-sirfsoc/pinmux.c                                        |  992 +++++
 plat-sirfsoc/platform_device/Makefile                        |   36
 plat-sirfsoc/platform_device/android_usb_dev.c               |   60
 plat-sirfsoc/platform_device/audio_dev.c                     |   88
 plat-sirfsoc/platform_device/bt_codec_dev.c                  |   26
 plat-sirfsoc/platform_device/camera_dev.c                    |  286 +
 plat-sirfsoc/platform_device/eth_dev.c                       |   75
 plat-sirfsoc/platform_device/gps_dev.c                       |  106
 plat-sirfsoc/platform_device/i2c_dev.c                       |  124
 plat-sirfsoc/platform_device/inner_audio_dev.c               |   75
 plat-sirfsoc/platform_device/lcd_dev.c                       |  156
 plat-sirfsoc/platform_device/mbx_dev.c                       |   74
 plat-sirfsoc/platform_device/modac_dev.c                     |   67
 plat-sirfsoc/platform_device/mved_dev.c                      |   70
 plat-sirfsoc/platform_device/nand_dev.c                      |   75
 plat-sirfsoc/platform_device/pmem_dev.c                      |   59
 plat-sirfsoc/platform_device/pwm_device.c                    |   79
 plat-sirfsoc/platform_device/sata_dev.c                      |   64
 plat-sirfsoc/platform_device/sdmmc_dev.c                     |  108
 plat-sirfsoc/platform_device/serial_dev.c                    |  241 +
 plat-sirfsoc/platform_device/sirfsoc_rtcdev.c                |   78
 plat-sirfsoc/platform_device/sirfsoc_tsdev.c                 |   65
 plat-sirfsoc/platform_device/spi_dev.c                       |  163
 plat-sirfsoc/platform_device/spigpio_dev.c                   |   75
 plat-sirfsoc/platform_device/ts_stream_mode_dev.c            |   64
 plat-sirfsoc/platform_device/usb_dev.c                       |  120
 plat-sirfsoc/platform_device/usppcm_dev.c                    |   69
 plat-sirfsoc/platform_device/uspserial_dev.c                 |  197 +
 plat-sirfsoc/platform_device/uspspi_dev.c                    |   97
 plat-sirfsoc/platform_device/vpp_dev.c                       |   70
 plat-sirfsoc/platform_device/vxd_dev.c                       |   68
 plat-sirfsoc/platform_device/wdt_dev.c                       |   41
 plat-sirfsoc/pm.c                                            |  179 +
 plat-sirfsoc/pm.h                                            |   21
 plat-sirfsoc/pwm.c                                           |  508 ++
 plat-sirfsoc/sleep.S                                         |  328 +
 plat-sirfsoc/sleep_prima2.S                                  |  331 +
 plat-sirfsoc/spislave.c                                      |  138
 plat-sirfsoc/timer.c                                         |  229 +
 plat-sirfsoc/vfp.S                                           |   53
 vfp/vfpmodule.c                                              |    9
 173 files changed, 22531 insertions(+), 3 deletions(-)

but many codes actually are useless and will be deleted or be simpler
while porting to linus' newest tree.

for drivers/:
 Kconfig                             |    2
 Makefile                            |    1
 char/sirfsoc_gps.c                  |  878 +++++++++++++
 char/sirfsoc_gpsdrv.h               |  134 +
 gpio/Kconfig                        |   17
 gpio/Makefile                       |    2
 gpio/sirfsoc-gpio.c                 |  704 ++++++++++
 gpio/sirfsoc_cpld.c                 |  269 ++++
 i2c/busses/Kconfig                  |    8
 i2c/busses/Makefile                 |    1
 i2c/busses/i2c-sirfsoc.c            |  472 +++++++
 input/misc/gpio_event.c             |  253 +++
 input/touchscreen/Kconfig           |   17
 input/touchscreen/Makefile          |    2
 input/touchscreen/ads7846.c         |   82 -
 input/touchscreen/sirfsoc_ts.c      |  520 +++++++
 input/touchscreen/tsc2100.c         |  494 +++++++
 input/touchscreen/tsc2100.h         |   78 +
 mmc/host/Kconfig                    |    6
 mmc/host/Makefile                   |    1
 mmc/host/sdhci-sirfsoc.c            |  316 ++++
 mmc/host/sdhci.c                    |   10
 mmc/host/sdhci.h                    |    2
 nanddisk/Kconfig                    |   17
 nanddisk/Makefile                   |    5
 nanddisk/nand.c                     |  937 +++++++++++++
 nanddisk/nanddisk.h                 |  702 ++++++++++
 net/dm9000.c                        |  290 +---
 net/dm9000.h                        |    8
 rtc/Kconfig                         |   13
 rtc/Makefile                        |    2
 rtc/rtc-sirfsoc.c                   |  687 ++++++++++
 rtc/rtc1-sirfsoc.c                  |  328 ++++
 spi/Kconfig                         |   24
 spi/Makefile                        |    3
 spi/spi_sirfsoc.c                   | 1033 +++++++++++++++
 spi/spi_sirfsoc.h                   |  128 +
 spi/spi_sirfsoc_gpio.c              |  260 +++
 spi/spi_sirfsoc_usp.c               |  960 ++++++++++++++
 tty/serial/Kconfig                  |   58
 tty/serial/Makefile                 |    2
 tty/serial/sirfsoc_serial.c         | 1770 ++++++++++++++++++++++++++
 tty/serial/sirfsoc_serial_drv.h     |  178 ++
 tty/serial/sirfsoc_uspserial.c      | 1736 +++++++++++++++++++++++++
 usb/Kconfig                         |    3
 usb/Makefile                        |    3
 usb/gadget/Kconfig                  |    4
 usb/gadget/gadget_chips.h           |    8
 usb/host/ehci-hcd.c                 |    9
 usb/sirfusb/Kconfig                 |   11
 usb/sirfusb/Makefile                |    6
 usb/sirfusb/sirfsoc_usb_driver.c    | 1017 +++++++++++++++
 usb/sirfusb/sirfsoc_usb_drv.h       |   83 +
 usb/sirfusb/sirfsoc_usb_hcd.c       |  230 +++
 usb/sirfusb/sirfsoc_usb_os_precom.h |   50
 usb/sirfusb/sirfsoc_usb_pcd.c       | 2419 ++++++++++++++++++++++++++++++++++++
 usb/sirfusb/sirfsoc_usb_pcd.h       |  227 +++
 usb/sirfusb/sirfsoc_usb_regs.h      |  612 +++++++++
 video/Kconfig                       |   24
 video/Makefile                      |    2
 video/backlight/Makefile            |    1
 video/sirfsoc_clcdc.h               |  269 ++++
 video/sirfsoc_fb.c                  | 2369 +++++++++++++++++++++++++++++++++++
 video/sirfsoc_vpp.c                 | 1166 +++++++++++++++++
 watchdog/Kconfig                    |    7
 watchdog/Makefile                   |    1
 watchdog/sirfsoc_wdt.c              |  349 +++++
 67 files changed, 22051 insertions(+), 229 deletions(-)

i want to upstream steps by steps. send arch/arm patches for reviewing
at first, then clean-up drivers and send patches to subsystem for
reviewing. There are really too many issues waiting for refination in
arch/arm for the moment, we have more than 20 tasks for team to work.

>
>        Arnd

[RFC] ARM Subarchitecture group maintainership

[Barry Song]

2011/5/19 Arnd Bergmann <arnd@arndb.de>
>
> On Thursday 19 May 2011, Barry Song wrote:
> > >
> > > Do you have a diffstat or a git tree with your work available?
> >
> > not yet by now. it should be coming in the middle of next month. we
> > have workable codes but need a lot of refinations before sending
> > patches for review. it is more like a new begin from scratch, so
> > arm/arch changes should be things we can catch.
>
> I'd like to make sure that you are not doing duplicate work by
> going in a wrong direction with this, so I think it would be best
> to post as early as possible, ideally with a list of things that
> you already know you need to change, so people don't need to comment
> on them.
>
> If you can just post a diffstat of the stuff you currently have,
> we also get an impression of the amount of code that you are
> talking about.
Arnd, thanks very much for thinking. Now the codes are based on 2.6.38
and not quanified for sending patches. we will port them to be
againest linux's tree.
current diffstat for arch/arm againest 2.6.38 mainline is
 Kconfig                                                      |   34
 Makefile                                                     |    5
 common/Makefile                                              |    1
 common/sirfsoc.c                                             |   21
 configs/prima2cb_defconfig                                   | 1903 +++++++++++
 include/asm/dma.h                                            |   10
 include/asm/mach/dma.h                                       |    7
 kernel/dma.c                                                 |   47
 kernel/vmlinux.lds                                           |  488 ++
 mach-prima2/Kconfig                                          |   32
 mach-prima2/Makefile                                         |   11
 mach-prima2/Makefile.boot                                    |    3
 mach-prima2/devices.c                                        |  191 +
 mach-prima2/include/mach/cache-sirfsoc-prima2-l2.h           |   12
 mach-prima2/include/mach/clkdev.h                            |    5
 mach-prima2/include/mach/debug-macro.S                       |   38
 mach-prima2/include/mach/entry-macro.S                       |   31
 mach-prima2/include/mach/gpio.h                              |    5
 mach-prima2/include/mach/hardware.h                          |   10
 mach-prima2/include/mach/io.h                                |   20
 mach-prima2/include/mach/irqs.h                              |  284 +
 mach-prima2/include/mach/isa-dma.h                           |   13
 mach-prima2/include/mach/map.h                               |  263 +
 mach-prima2/include/mach/memory.h                            |   56
 mach-prima2/include/mach/prima2.h                            |   20
 mach-prima2/include/mach/prima2_pinmux.h                     |   39
 mach-prima2/include/mach/prima2cb.h                          |  111
 mach-prima2/include/mach/regs-iobrg.h                        |   54
 mach-prima2/include/mach/regs-irq.h                          |   42
 mach-prima2/include/mach/regs-reset.h                        |   88
 mach-prima2/include/mach/regs-rsc.h                          |   76
 mach-prima2/include/mach/system.h                            |    5
 mach-prima2/include/mach/timex.h                             |    5
 mach-prima2/include/mach/uncompress.h                        |   45
 mach-prima2/include/mach/vmalloc.h                           |   19
 mach-prima2/lcdinit.c                                        |  136
 mach-prima2/mach-prima2cb.c                                  |  226 +
 mach-prima2/padmode.c                                        |  139
 mach-prima2/prima2.c                                         |   81
 mach-prima2/prima2cb-keypad.c                                |  136
 mach-prima2/pwrc.c                                           |  286 +
 mach-prima2/tsc2100_dev.c                                    |  137
 mm/Kconfig                                                   |   13
 mm/Makefile                                                  |    1
 mm/cache-sirfsoc-prima2-l2.c                                 |  342 +
 plat-sirfsoc/Kconfig                                         |  108
 plat-sirfsoc/Makefile                                        |   34
 plat-sirfsoc/adc.c                                           | 1395 ++++++++
 plat-sirfsoc/adcprocfs.c                                     |  348 ++
 plat-sirfsoc/apm.c                                           |  107
 plat-sirfsoc/clock.c                                         | 1045 ++++++
 plat-sirfsoc/clock.h                                         |   32
 plat-sirfsoc/core.c                                          |  245 +
 plat-sirfsoc/cpufreq.c                                       |  239 +
 plat-sirfsoc/deepsleep.S                                     |  425 ++
 plat-sirfsoc/dma.c                                           |  386 ++
 plat-sirfsoc/hibernate.h                                     |  118
 plat-sirfsoc/include/plat/audio_controller.h                 |  333 +
 plat-sirfsoc/include/plat/belmont.h                          |   92
 plat-sirfsoc/include/plat/bootmem.h                          |   45
 plat-sirfsoc/include/plat/clkdev.h                           |   15
 plat-sirfsoc/include/plat/cpld.h                             |   27
 plat-sirfsoc/include/plat/cpld_evb.h                         |  200 +
 plat-sirfsoc/include/plat/cpld_fpga.h                        |  201 +
 plat-sirfsoc/include/plat/cpu.h                              |   51
 plat-sirfsoc/include/plat/debug-macro.S                      |   34
 plat-sirfsoc/include/plat/gpio.h                             |   92
 plat-sirfsoc/include/plat/hardware.h                         |   28
 plat-sirfsoc/include/plat/iobrg.h                            |   17
 plat-sirfsoc/include/plat/irqs.h                             |  320 +
 plat-sirfsoc/include/plat/isa-dma.h                          |  111
 plat-sirfsoc/include/plat/lcd_panels.h                       |   33
 plat-sirfsoc/include/plat/map.h                              |  233 +
 plat-sirfsoc/include/plat/memory.h                           |   43
 plat-sirfsoc/include/plat/perfmon.h                          |   62
 plat-sirfsoc/include/plat/pinmux.h                           |   23
 plat-sirfsoc/include/plat/platform_device/android_usb_dev.h  |   27
 plat-sirfsoc/include/plat/platform_device/audio.h            |   28
 plat-sirfsoc/include/plat/platform_device/bt_codec.h         |   26
 plat-sirfsoc/include/plat/platform_device/eth.h              |   26
 plat-sirfsoc/include/plat/platform_device/gps.h              |   40
 plat-sirfsoc/include/plat/platform_device/i2c.h              |   27
 plat-sirfsoc/include/plat/platform_device/inner_audio.h      |   26
 plat-sirfsoc/include/plat/platform_device/lcd.h              |   85
 plat-sirfsoc/include/plat/platform_device/mbx.h              |   37
 plat-sirfsoc/include/plat/platform_device/modac.h            |   26
 plat-sirfsoc/include/plat/platform_device/mved.h             |   36
 plat-sirfsoc/include/plat/platform_device/nand.h             |   27
 plat-sirfsoc/include/plat/platform_device/pmem.h             |   27
 plat-sirfsoc/include/plat/platform_device/pwm_dev.h          |   31
 plat-sirfsoc/include/plat/platform_device/rtc.h              |   27
 plat-sirfsoc/include/plat/platform_device/sata.h             |   33
 plat-sirfsoc/include/plat/platform_device/sd.h               |   31
 plat-sirfsoc/include/plat/platform_device/serial.h           |   82
 plat-sirfsoc/include/plat/platform_device/sirfsoc_ts.h       |   31
 plat-sirfsoc/include/plat/platform_device/snd.h              |   30
 plat-sirfsoc/include/plat/platform_device/spi.h              |   53
 plat-sirfsoc/include/plat/platform_device/spi_sirfsoc_gpio.h |   34
 plat-sirfsoc/include/plat/platform_device/ts_stream_mode.h   |   26
 plat-sirfsoc/include/plat/platform_device/usb.h              |   40
 plat-sirfsoc/include/plat/platform_device/usppcm.h           |   25
 plat-sirfsoc/include/plat/platform_device/uspserial.h        |   45
 plat-sirfsoc/include/plat/platform_device/uspspi.h           |   33
 plat-sirfsoc/include/plat/platform_device/vpp.h              |   27
 plat-sirfsoc/include/plat/platform_device/vxd.h              |   27
 plat-sirfsoc/include/plat/platform_device/wdt.h              |   26
 plat-sirfsoc/include/plat/pm.h                               |   41
 plat-sirfsoc/include/plat/pwm.h                              |   63
 plat-sirfsoc/include/plat/regs-clkc.h                        |   33
 plat-sirfsoc/include/plat/regs-gpio.h                        |   43
 plat-sirfsoc/include/plat/regs-irq.h                         |   39
 plat-sirfsoc/include/plat/regs-modac.h                       |  114
 plat-sirfsoc/include/plat/regs-power.h                       |   77
 plat-sirfsoc/include/plat/regs-pwm.h                         |   37
 plat-sirfsoc/include/plat/regs-pwrc.h                        |   62
 plat-sirfsoc/include/plat/regs-reset.h                       |   73
 plat-sirfsoc/include/plat/regs-rsc.h                         |   78
 plat-sirfsoc/include/plat/regs-rtc.h                         |   41
 plat-sirfsoc/include/plat/regs-serial.h                      |   87
 plat-sirfsoc/include/plat/regs-timer.h                       |   39
 plat-sirfsoc/include/plat/regs-vip.h                         |   98
 plat-sirfsoc/include/plat/sd.h                               |  110
 plat-sirfsoc/include/plat/sirfsoc_adc.h                      |  261 +
 plat-sirfsoc/include/plat/sirfsoc_usp.h                      |  288 +
 plat-sirfsoc/include/plat/system.h                           |   39
 plat-sirfsoc/include/plat/timex.h                            |   33
 plat-sirfsoc/include/plat/uncompress.h                       |   46
 plat-sirfsoc/include/plat/vmalloc.h                          |   26
 plat-sirfsoc/irq.c                                           |  102
 plat-sirfsoc/lcd_panels.c                                    |  281 +
 plat-sirfsoc/led.c                                           |  340 +
 plat-sirfsoc/perfmon.c                                       | 1347 +++++++
 plat-sirfsoc/pinmux.c                                        |  992 +++++
 plat-sirfsoc/platform_device/Makefile                        |   36
 plat-sirfsoc/platform_device/android_usb_dev.c               |   60
 plat-sirfsoc/platform_device/audio_dev.c                     |   88
 plat-sirfsoc/platform_device/bt_codec_dev.c                  |   26
 plat-sirfsoc/platform_device/camera_dev.c                    |  286 +
 plat-sirfsoc/platform_device/eth_dev.c                       |   75
 plat-sirfsoc/platform_device/gps_dev.c                       |  106
 plat-sirfsoc/platform_device/i2c_dev.c                       |  124
 plat-sirfsoc/platform_device/inner_audio_dev.c               |   75
 plat-sirfsoc/platform_device/lcd_dev.c                       |  156
 plat-sirfsoc/platform_device/mbx_dev.c                       |   74
 plat-sirfsoc/platform_device/modac_dev.c                     |   67
 plat-sirfsoc/platform_device/mved_dev.c                      |   70
 plat-sirfsoc/platform_device/nand_dev.c                      |   75
 plat-sirfsoc/platform_device/pmem_dev.c                      |   59
 plat-sirfsoc/platform_device/pwm_device.c                    |   79
 plat-sirfsoc/platform_device/sata_dev.c                      |   64
 plat-sirfsoc/platform_device/sdmmc_dev.c                     |  108
 plat-sirfsoc/platform_device/serial_dev.c                    |  241 +
 plat-sirfsoc/platform_device/sirfsoc_rtcdev.c                |   78
 plat-sirfsoc/platform_device/sirfsoc_tsdev.c                 |   65
 plat-sirfsoc/platform_device/spi_dev.c                       |  163
 plat-sirfsoc/platform_device/spigpio_dev.c                   |   75
 plat-sirfsoc/platform_device/ts_stream_mode_dev.c            |   64
 plat-sirfsoc/platform_device/usb_dev.c                       |  120
 plat-sirfsoc/platform_device/usppcm_dev.c                    |   69
 plat-sirfsoc/platform_device/uspserial_dev.c                 |  197 +
 plat-sirfsoc/platform_device/uspspi_dev.c                    |   97
 plat-sirfsoc/platform_device/vpp_dev.c                       |   70
 plat-sirfsoc/platform_device/vxd_dev.c                       |   68
 plat-sirfsoc/platform_device/wdt_dev.c                       |   41
 plat-sirfsoc/pm.c                                            |  179 +
 plat-sirfsoc/pm.h                                            |   21
 plat-sirfsoc/pwm.c                                           |  508 ++
 plat-sirfsoc/sleep.S                                         |  328 +
 plat-sirfsoc/sleep_prima2.S                                  |  331 +
 plat-sirfsoc/spislave.c                                      |  138
 plat-sirfsoc/timer.c                                         |  229 +
 plat-sirfsoc/vfp.S                                           |   53
 vfp/vfpmodule.c                                              |    9
 173 files changed, 22531 insertions(+), 3 deletions(-)

but many codes actually are useless and will be deleted or be simpler
while porting to linus' newest tree.

for drivers/:
 Kconfig                             |    2
 Makefile                            |    1
 char/sirfsoc_gps.c                  |  878 +++++++++++++
 char/sirfsoc_gpsdrv.h               |  134 +
 gpio/Kconfig                        |   17
 gpio/Makefile                       |    2
 gpio/sirfsoc-gpio.c                 |  704 ++++++++++
 gpio/sirfsoc_cpld.c                 |  269 ++++
 i2c/busses/Kconfig                  |    8
 i2c/busses/Makefile                 |    1
 i2c/busses/i2c-sirfsoc.c            |  472 +++++++
 input/misc/gpio_event.c             |  253 +++
 input/touchscreen/Kconfig           |   17
 input/touchscreen/Makefile          |    2
 input/touchscreen/ads7846.c         |   82 -
 input/touchscreen/sirfsoc_ts.c      |  520 +++++++
 input/touchscreen/tsc2100.c         |  494 +++++++
 input/touchscreen/tsc2100.h         |   78 +
 mmc/host/Kconfig                    |    6
 mmc/host/Makefile                   |    1
 mmc/host/sdhci-sirfsoc.c            |  316 ++++
 mmc/host/sdhci.c                    |   10
 mmc/host/sdhci.h                    |    2
 nanddisk/Kconfig                    |   17
 nanddisk/Makefile                   |    5
 nanddisk/nand.c                     |  937 +++++++++++++
 nanddisk/nanddisk.h                 |  702 ++++++++++
 net/dm9000.c                        |  290 +---
 net/dm9000.h                        |    8
 rtc/Kconfig                         |   13
 rtc/Makefile                        |    2
 rtc/rtc-sirfsoc.c                   |  687 ++++++++++
 rtc/rtc1-sirfsoc.c                  |  328 ++++
 spi/Kconfig                         |   24
 spi/Makefile                        |    3
 spi/spi_sirfsoc.c                   | 1033 +++++++++++++++
 spi/spi_sirfsoc.h                   |  128 +
 spi/spi_sirfsoc_gpio.c              |  260 +++
 spi/spi_sirfsoc_usp.c               |  960 ++++++++++++++
 tty/serial/Kconfig                  |   58
 tty/serial/Makefile                 |    2
 tty/serial/sirfsoc_serial.c         | 1770 ++++++++++++++++++++++++++
 tty/serial/sirfsoc_serial_drv.h     |  178 ++
 tty/serial/sirfsoc_uspserial.c      | 1736 +++++++++++++++++++++++++
 usb/Kconfig                         |    3
 usb/Makefile                        |    3
 usb/gadget/Kconfig                  |    4
 usb/gadget/gadget_chips.h           |    8
 usb/host/ehci-hcd.c                 |    9
 usb/sirfusb/Kconfig                 |   11
 usb/sirfusb/Makefile                |    6
 usb/sirfusb/sirfsoc_usb_driver.c    | 1017 +++++++++++++++
 usb/sirfusb/sirfsoc_usb_drv.h       |   83 +
 usb/sirfusb/sirfsoc_usb_hcd.c       |  230 +++
 usb/sirfusb/sirfsoc_usb_os_precom.h |   50
 usb/sirfusb/sirfsoc_usb_pcd.c       | 2419 ++++++++++++++++++++++++++++++++++++
 usb/sirfusb/sirfsoc_usb_pcd.h       |  227 +++
 usb/sirfusb/sirfsoc_usb_regs.h      |  612 +++++++++
 video/Kconfig                       |   24
 video/Makefile                      |    2
 video/backlight/Makefile            |    1
 video/sirfsoc_clcdc.h               |  269 ++++
 video/sirfsoc_fb.c                  | 2369 +++++++++++++++++++++++++++++++++++
 video/sirfsoc_vpp.c                 | 1166 +++++++++++++++++
 watchdog/Kconfig                    |    7
 watchdog/Makefile                   |    1
 watchdog/sirfsoc_wdt.c              |  349 +++++
 67 files changed, 22051 insertions(+), 229 deletions(-)

i want to upstream steps by steps. send arch/arm patches for reviewing
at first, then clean-up drivers and send patches to subsystem for
reviewing. There are really too many issues waiting for refination in
arch/arm for the moment, we have more than 20 tasks for team to work.

>
> ? ? ? ?Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Tuesday 24 May 2011, Barry Song wrote:
> 2011/5/19 Arnd Bergmann <arnd@arndb.de>
>
> > If you can just post a diffstat of the stuff you currently have,
> > we also get an impression of the amount of code that you are
> > talking about.
> Arnd, thanks very much for thinking. Now the codes are based on 2.6.38
> and not quanified for sending patches. we will port them to be
> againest linux's tree.

Thanks for the diffstat, that is very helpful as an estimate. It appears
that there is a large amount of work ahead of you in this, so by the
time you get ready for inclusion, we will most certainly require this
to be based on device tree for probing of all devices. I'd strongly
recommend that you investigate what that means for you before you port
a lot of the code to 2.6.39 or 2.6.40.

Since the timing is a bit unfortunate for you, you might want to stay
on 2.6.38 with the full port and not spend too much time on forward
porting all of it, but instead migrate the drivers to be based on
device tree properties rather than platform data, so you can submit
the drivers individually upstream.

>  mach-prima2/Kconfig                                          |   32
>  mach-prima2/Makefile                                         |   11
>  mach-prima2/Makefile.boot                                    |    3
>  mach-prima2/devices.c                                        |  191 +
>  mach-prima2/include/mach/cache-sirfsoc-prima2-l2.h           |   12
>  mach-prima2/include/mach/clkdev.h                            |    5
>  mach-prima2/include/mach/debug-macro.S                       |   38
>  mach-prima2/include/mach/entry-macro.S                       |   31
>  mach-prima2/include/mach/gpio.h                              |    5
>  mach-prima2/include/mach/hardware.h                          |   10
>  mach-prima2/include/mach/io.h                                |   20
>  mach-prima2/include/mach/irqs.h                              |  284 +
>  mach-prima2/include/mach/isa-dma.h                           |   13
>  mach-prima2/include/mach/map.h                               |  263 +
>  mach-prima2/include/mach/memory.h                            |   56

The irqs.h and map.h are the largest by far here, and they should go
away for the most part with the move to device tree.

>  mach-prima2/include/mach/prima2.h                            |   20
>  mach-prima2/include/mach/prima2_pinmux.h                     |   39
>  mach-prima2/include/mach/prima2cb.h                          |  111

There is a new pinmux subsystem in the works, so you probably
end up having to write a new driver for that subsystem.

>  mach-prima2/include/mach/regs-iobrg.h                        |   54
>  mach-prima2/include/mach/regs-irq.h                          |   42
>  mach-prima2/include/mach/regs-reset.h                        |   88
>  mach-prima2/include/mach/regs-rsc.h                          |   76

For the registers, they can go together with the respective drivers
using them.

>  mach-prima2/include/mach/system.h                            |    5
>  mach-prima2/include/mach/timex.h                             |    5
>  mach-prima2/include/mach/uncompress.h                        |   45
>  mach-prima2/include/mach/vmalloc.h                           |   19
>  mach-prima2/lcdinit.c                                        |  136
>  mach-prima2/mach-prima2cb.c                                  |  226 +
>  mach-prima2/padmode.c                                        |  139
>  mach-prima2/prima2.c                                         |   81
>  mach-prima2/prima2cb-keypad.c                                |  136
>  mach-prima2/pwrc.c                                           |  286 +
>  mach-prima2/tsc2100_dev.c                                    |  137

Any drivers in here should get moved to a proper place in drivers/*/
eventually, out of the subarchitecture code.

>  mm/Kconfig                                                   |   13
>  mm/Makefile                                                  |    1
>  mm/cache-sirfsoc-prima2-l2.c                                 |  342 +
>  plat-sirfsoc/Kconfig                                         |  108
>  plat-sirfsoc/Makefile                                        |   34
>  plat-sirfsoc/adc.c                                           | 1395 ++++++++
>  plat-sirfsoc/adcprocfs.c                                     |  348 ++
>  plat-sirfsoc/apm.c                                           |  107
>  plat-sirfsoc/clock.c                                         | 1045 ++++++
>  plat-sirfsoc/clock.h                                         |   32
>  plat-sirfsoc/core.c                                          |  245 +
>  plat-sirfsoc/cpufreq.c                                       |  239 +
>  plat-sirfsoc/deepsleep.S                                     |  425 ++
>  plat-sirfsoc/dma.c                                           |  386 ++
>  plat-sirfsoc/hibernate.h                                     |  118

Same here.

>  plat-sirfsoc/include/plat/audio_controller.h                 |  333 +
>  plat-sirfsoc/include/plat/belmont.h                          |   92
>  plat-sirfsoc/include/plat/bootmem.h                          |   45
>  plat-sirfsoc/include/plat/clkdev.h                           |   15
>  plat-sirfsoc/include/plat/cpld.h                             |   27
>  plat-sirfsoc/include/plat/cpld_evb.h                         |  200 +
>  plat-sirfsoc/include/plat/cpld_fpga.h                        |  201 +
>  plat-sirfsoc/include/plat/cpu.h                              |   51
>  plat-sirfsoc/include/plat/debug-macro.S                      |   34
>  plat-sirfsoc/include/plat/gpio.h                             |   92
>  plat-sirfsoc/include/plat/hardware.h                         |   28
>  plat-sirfsoc/include/plat/iobrg.h                            |   17
>  plat-sirfsoc/include/plat/irqs.h                             |  320 +
>  plat-sirfsoc/include/plat/isa-dma.h                          |  111
>  plat-sirfsoc/include/plat/lcd_panels.h                       |   33
>  plat-sirfsoc/include/plat/map.h                              |  233 +
>  plat-sirfsoc/include/plat/memory.h                           |   43
>  plat-sirfsoc/include/plat/perfmon.h                          |   62
>  plat-sirfsoc/include/plat/pinmux.h                           |   23

It's not clear yet what will happen in the long run to the split between
mach-* and plat-* directories. Ideally, we would not need them to be
separate if we can completely abstract the SoCs within their broader
families, but we might not get that far before you merge your platform.

What other mach-* do you expect to see in the future using plat-sirfsoc,
and how similar are they to prima2?

>  plat-sirfsoc/include/plat/platform_device/android_usb_dev.h  |   27
>  plat-sirfsoc/include/plat/platform_device/audio.h            |   28
>  plat-sirfsoc/include/plat/platform_device/bt_codec.h         |   26
>  plat-sirfsoc/include/plat/platform_device/eth.h              |   26
>  plat-sirfsoc/include/plat/platform_device/gps.h              |   40
>  plat-sirfsoc/include/plat/platform_device/i2c.h              |   27
>  plat-sirfsoc/include/plat/platform_device/inner_audio.h      |   26
>  plat-sirfsoc/include/plat/platform_device/lcd.h              |   85
>  plat-sirfsoc/include/plat/platform_device/mbx.h              |   37
>  plat-sirfsoc/include/plat/platform_device/modac.h            |   26
>  plat-sirfsoc/include/plat/platform_device/mved.h             |   36
>  plat-sirfsoc/include/plat/platform_device/nand.h             |   27
>  plat-sirfsoc/include/plat/platform_device/pmem.h             |   27
>  plat-sirfsoc/include/plat/platform_device/pwm_dev.h          |   31
>  plat-sirfsoc/include/plat/platform_device/rtc.h              |   27
>  plat-sirfsoc/include/plat/platform_device/sata.h             |   33
>  plat-sirfsoc/include/plat/platform_device/sd.h               |   31
>  plat-sirfsoc/include/plat/platform_device/serial.h           |   82
>  plat-sirfsoc/include/plat/platform_device/sirfsoc_ts.h       |   31
>  plat-sirfsoc/include/plat/platform_device/snd.h              |   30
>  plat-sirfsoc/include/plat/platform_device/spi.h              |   53
>  plat-sirfsoc/include/plat/platform_device/spi_sirfsoc_gpio.h |   34
>  plat-sirfsoc/include/plat/platform_device/ts_stream_mode.h   |   26
>  plat-sirfsoc/include/plat/platform_device/usb.h              |   40
>  plat-sirfsoc/include/plat/platform_device/usppcm.h           |   25
>  plat-sirfsoc/include/plat/platform_device/uspserial.h        |   45
>  plat-sirfsoc/include/plat/platform_device/uspspi.h           |   33
>  plat-sirfsoc/include/plat/platform_device/vpp.h              |   27
>  plat-sirfsoc/include/plat/platform_device/vxd.h              |   27
>  plat-sirfsoc/include/plat/platform_device/wdt.h              |   26
>  plat-sirfsoc/platform_device/Makefile                        |   36
>  plat-sirfsoc/platform_device/android_usb_dev.c               |   60
>  plat-sirfsoc/platform_device/audio_dev.c                     |   88
>  plat-sirfsoc/platform_device/bt_codec_dev.c                  |   26
>  plat-sirfsoc/platform_device/camera_dev.c                    |  286 +
>  plat-sirfsoc/platform_device/eth_dev.c                       |   75
>  plat-sirfsoc/platform_device/gps_dev.c                       |  106
>  plat-sirfsoc/platform_device/i2c_dev.c                       |  124
>  plat-sirfsoc/platform_device/inner_audio_dev.c               |   75
>  plat-sirfsoc/platform_device/lcd_dev.c                       |  156
>  plat-sirfsoc/platform_device/mbx_dev.c                       |   74
>  plat-sirfsoc/platform_device/modac_dev.c                     |   67
>  plat-sirfsoc/platform_device/mved_dev.c                      |   70
>  plat-sirfsoc/platform_device/nand_dev.c                      |   75
>  plat-sirfsoc/platform_device/pmem_dev.c                      |   59
>  plat-sirfsoc/platform_device/pwm_device.c                    |   79
>  plat-sirfsoc/platform_device/sata_dev.c                      |   64
>  plat-sirfsoc/platform_device/sdmmc_dev.c                     |  108
>  plat-sirfsoc/platform_device/serial_dev.c                    |  241 +
>  plat-sirfsoc/platform_device/sirfsoc_rtcdev.c                |   78
>  plat-sirfsoc/platform_device/sirfsoc_tsdev.c                 |   65
>  plat-sirfsoc/platform_device/spi_dev.c                       |  163
>  plat-sirfsoc/platform_device/spigpio_dev.c                   |   75
>  plat-sirfsoc/platform_device/ts_stream_mode_dev.c            |   64
>  plat-sirfsoc/platform_device/usb_dev.c                       |  120
>  plat-sirfsoc/platform_device/usppcm_dev.c                    |   69
>  plat-sirfsoc/platform_device/uspserial_dev.c                 |  197 +
>  plat-sirfsoc/platform_device/uspspi_dev.c                    |   97
>  plat-sirfsoc/platform_device/vpp_dev.c                       |   70
>  plat-sirfsoc/platform_device/vxd_dev.c                       |   68
>  plat-sirfsoc/platform_device/wdt_dev.c                       |   41

These will probably all get replaced with device tree bindings.

>  plat-sirfsoc/include/plat/pm.h                               |   41
>  plat-sirfsoc/include/plat/pwm.h                              |   63
>  plat-sirfsoc/include/plat/regs-clkc.h                        |   33
>  plat-sirfsoc/include/plat/regs-gpio.h                        |   43
>  plat-sirfsoc/include/plat/regs-irq.h                         |   39
>  plat-sirfsoc/include/plat/regs-modac.h                       |  114
>  plat-sirfsoc/include/plat/regs-power.h                       |   77
>  plat-sirfsoc/include/plat/regs-pwm.h                         |   37
>  plat-sirfsoc/include/plat/regs-pwrc.h                        |   62
>  plat-sirfsoc/include/plat/regs-reset.h                       |   73
>  plat-sirfsoc/include/plat/regs-rsc.h                         |   78
>  plat-sirfsoc/include/plat/regs-rtc.h                         |   41
>  plat-sirfsoc/include/plat/regs-serial.h                      |   87
>  plat-sirfsoc/include/plat/regs-timer.h                       |   39
>  plat-sirfsoc/include/plat/regs-vip.h                         |   98
>  plat-sirfsoc/include/plat/sd.h                               |  110
>  plat-sirfsoc/include/plat/sirfsoc_adc.h                      |  261 +
>  plat-sirfsoc/include/plat/sirfsoc_usp.h                      |  288 +

And these can hopefully all get moved next to the respective drivers.

>  plat-sirfsoc/include/plat/system.h                           |   39
>  plat-sirfsoc/include/plat/timex.h                            |   33
>  plat-sirfsoc/include/plat/uncompress.h                       |   46
>  plat-sirfsoc/include/plat/vmalloc.h                          |   26
>  plat-sirfsoc/irq.c                                           |  102
>  plat-sirfsoc/lcd_panels.c                                    |  281 +
>  plat-sirfsoc/led.c                                           |  340 +
>  plat-sirfsoc/perfmon.c                                       | 1347 +++++++

For the perfmon implementation, I would recommend splitting it out of the
submission at the beginning. If it's based on perf, it should be easy to
add at a later stage. Otherwise, it's not going anywhere. If it's related
to the ARM system trace macrocell, I'd recommend posting the code now
(independent of the rest), because other people are interested in getting
that to work.

>  plat-sirfsoc/pinmux.c                                        |  992 +++++

-> pinmux subsystem

> for drivers/:
>  Kconfig                             |    2
>  Makefile                            |    1
>  char/sirfsoc_gps.c                  |  878 +++++++++++++
>  char/sirfsoc_gpsdrv.h               |  134 +
>  input/misc/gpio_event.c             |  253 +++

A new user space interface is always hard to establish. If you want these
to get in, you should start way ahead of the other drivers that simply
implement an existing interface.

If the gps driver is just a tty device like a serial port, it should
now be moved into drivers/tty.

>  nanddisk/Kconfig                    |   17
>  nanddisk/Makefile                   |    5
>  nanddisk/nand.c                     |  937 +++++++++++++
>  nanddisk/nanddisk.h                 |  702 ++++++++++

How does this relate to drivers/mtd?

>  net/dm9000.c                        |  290 +---
>  net/dm9000.h                        |    8

Ah, code removal ;-)

>  video/Kconfig                       |   24
>  video/Makefile                      |    2
>  video/backlight/Makefile            |    1
>  video/sirfsoc_clcdc.h               |  269 ++++
>  video/sirfsoc_fb.c                  | 2369 +++++++++++++++++++++++++++++++++++
>  video/sirfsoc_vpp.c                 | 1166 +++++++++++++++++

Have you considered doing a KMS device driver instead of an old-style
frame buffer?

> i want to upstream steps by steps. send arch/arm patches for reviewing
> at first, then clean-up drivers and send patches to subsystem for
> reviewing. There are really too many issues waiting for refination in
> arch/arm for the moment, we have more than 20 tasks for team to work.

Ok, no problem.

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Tuesday 24 May 2011, Barry Song wrote:
> 2011/5/19 Arnd Bergmann <arnd@arndb.de>
>
> > If you can just post a diffstat of the stuff you currently have,
> > we also get an impression of the amount of code that you are
> > talking about.
> Arnd, thanks very much for thinking. Now the codes are based on 2.6.38
> and not quanified for sending patches. we will port them to be
> againest linux's tree.

Thanks for the diffstat, that is very helpful as an estimate. It appears
that there is a large amount of work ahead of you in this, so by the
time you get ready for inclusion, we will most certainly require this
to be based on device tree for probing of all devices. I'd strongly
recommend that you investigate what that means for you before you port
a lot of the code to 2.6.39 or 2.6.40.

Since the timing is a bit unfortunate for you, you might want to stay
on 2.6.38 with the full port and not spend too much time on forward
porting all of it, but instead migrate the drivers to be based on
device tree properties rather than platform data, so you can submit
the drivers individually upstream.

>  mach-prima2/Kconfig                                          |   32
>  mach-prima2/Makefile                                         |   11
>  mach-prima2/Makefile.boot                                    |    3
>  mach-prima2/devices.c                                        |  191 +
>  mach-prima2/include/mach/cache-sirfsoc-prima2-l2.h           |   12
>  mach-prima2/include/mach/clkdev.h                            |    5
>  mach-prima2/include/mach/debug-macro.S                       |   38
>  mach-prima2/include/mach/entry-macro.S                       |   31
>  mach-prima2/include/mach/gpio.h                              |    5
>  mach-prima2/include/mach/hardware.h                          |   10
>  mach-prima2/include/mach/io.h                                |   20
>  mach-prima2/include/mach/irqs.h                              |  284 +
>  mach-prima2/include/mach/isa-dma.h                           |   13
>  mach-prima2/include/mach/map.h                               |  263 +
>  mach-prima2/include/mach/memory.h                            |   56

The irqs.h and map.h are the largest by far here, and they should go
away for the most part with the move to device tree.

>  mach-prima2/include/mach/prima2.h                            |   20
>  mach-prima2/include/mach/prima2_pinmux.h                     |   39
>  mach-prima2/include/mach/prima2cb.h                          |  111

There is a new pinmux subsystem in the works, so you probably
end up having to write a new driver for that subsystem.

>  mach-prima2/include/mach/regs-iobrg.h                        |   54
>  mach-prima2/include/mach/regs-irq.h                          |   42
>  mach-prima2/include/mach/regs-reset.h                        |   88
>  mach-prima2/include/mach/regs-rsc.h                          |   76

For the registers, they can go together with the respective drivers
using them.

>  mach-prima2/include/mach/system.h                            |    5
>  mach-prima2/include/mach/timex.h                             |    5
>  mach-prima2/include/mach/uncompress.h                        |   45
>  mach-prima2/include/mach/vmalloc.h                           |   19
>  mach-prima2/lcdinit.c                                        |  136
>  mach-prima2/mach-prima2cb.c                                  |  226 +
>  mach-prima2/padmode.c                                        |  139
>  mach-prima2/prima2.c                                         |   81
>  mach-prima2/prima2cb-keypad.c                                |  136
>  mach-prima2/pwrc.c                                           |  286 +
>  mach-prima2/tsc2100_dev.c                                    |  137

Any drivers in here should get moved to a proper place in drivers/*/
eventually, out of the subarchitecture code.

>  mm/Kconfig                                                   |   13
>  mm/Makefile                                                  |    1
>  mm/cache-sirfsoc-prima2-l2.c                                 |  342 +
>  plat-sirfsoc/Kconfig                                         |  108
>  plat-sirfsoc/Makefile                                        |   34
>  plat-sirfsoc/adc.c                                           | 1395 ++++++++
>  plat-sirfsoc/adcprocfs.c                                     |  348 ++
>  plat-sirfsoc/apm.c                                           |  107
>  plat-sirfsoc/clock.c                                         | 1045 ++++++
>  plat-sirfsoc/clock.h                                         |   32
>  plat-sirfsoc/core.c                                          |  245 +
>  plat-sirfsoc/cpufreq.c                                       |  239 +
>  plat-sirfsoc/deepsleep.S                                     |  425 ++
>  plat-sirfsoc/dma.c                                           |  386 ++
>  plat-sirfsoc/hibernate.h                                     |  118

Same here.

>  plat-sirfsoc/include/plat/audio_controller.h                 |  333 +
>  plat-sirfsoc/include/plat/belmont.h                          |   92
>  plat-sirfsoc/include/plat/bootmem.h                          |   45
>  plat-sirfsoc/include/plat/clkdev.h                           |   15
>  plat-sirfsoc/include/plat/cpld.h                             |   27
>  plat-sirfsoc/include/plat/cpld_evb.h                         |  200 +
>  plat-sirfsoc/include/plat/cpld_fpga.h                        |  201 +
>  plat-sirfsoc/include/plat/cpu.h                              |   51
>  plat-sirfsoc/include/plat/debug-macro.S                      |   34
>  plat-sirfsoc/include/plat/gpio.h                             |   92
>  plat-sirfsoc/include/plat/hardware.h                         |   28
>  plat-sirfsoc/include/plat/iobrg.h                            |   17
>  plat-sirfsoc/include/plat/irqs.h                             |  320 +
>  plat-sirfsoc/include/plat/isa-dma.h                          |  111
>  plat-sirfsoc/include/plat/lcd_panels.h                       |   33
>  plat-sirfsoc/include/plat/map.h                              |  233 +
>  plat-sirfsoc/include/plat/memory.h                           |   43
>  plat-sirfsoc/include/plat/perfmon.h                          |   62
>  plat-sirfsoc/include/plat/pinmux.h                           |   23

It's not clear yet what will happen in the long run to the split between
mach-* and plat-* directories. Ideally, we would not need them to be
separate if we can completely abstract the SoCs within their broader
families, but we might not get that far before you merge your platform.

What other mach-* do you expect to see in the future using plat-sirfsoc,
and how similar are they to prima2?

>  plat-sirfsoc/include/plat/platform_device/android_usb_dev.h  |   27
>  plat-sirfsoc/include/plat/platform_device/audio.h            |   28
>  plat-sirfsoc/include/plat/platform_device/bt_codec.h         |   26
>  plat-sirfsoc/include/plat/platform_device/eth.h              |   26
>  plat-sirfsoc/include/plat/platform_device/gps.h              |   40
>  plat-sirfsoc/include/plat/platform_device/i2c.h              |   27
>  plat-sirfsoc/include/plat/platform_device/inner_audio.h      |   26
>  plat-sirfsoc/include/plat/platform_device/lcd.h              |   85
>  plat-sirfsoc/include/plat/platform_device/mbx.h              |   37
>  plat-sirfsoc/include/plat/platform_device/modac.h            |   26
>  plat-sirfsoc/include/plat/platform_device/mved.h             |   36
>  plat-sirfsoc/include/plat/platform_device/nand.h             |   27
>  plat-sirfsoc/include/plat/platform_device/pmem.h             |   27
>  plat-sirfsoc/include/plat/platform_device/pwm_dev.h          |   31
>  plat-sirfsoc/include/plat/platform_device/rtc.h              |   27
>  plat-sirfsoc/include/plat/platform_device/sata.h             |   33
>  plat-sirfsoc/include/plat/platform_device/sd.h               |   31
>  plat-sirfsoc/include/plat/platform_device/serial.h           |   82
>  plat-sirfsoc/include/plat/platform_device/sirfsoc_ts.h       |   31
>  plat-sirfsoc/include/plat/platform_device/snd.h              |   30
>  plat-sirfsoc/include/plat/platform_device/spi.h              |   53
>  plat-sirfsoc/include/plat/platform_device/spi_sirfsoc_gpio.h |   34
>  plat-sirfsoc/include/plat/platform_device/ts_stream_mode.h   |   26
>  plat-sirfsoc/include/plat/platform_device/usb.h              |   40
>  plat-sirfsoc/include/plat/platform_device/usppcm.h           |   25
>  plat-sirfsoc/include/plat/platform_device/uspserial.h        |   45
>  plat-sirfsoc/include/plat/platform_device/uspspi.h           |   33
>  plat-sirfsoc/include/plat/platform_device/vpp.h              |   27
>  plat-sirfsoc/include/plat/platform_device/vxd.h              |   27
>  plat-sirfsoc/include/plat/platform_device/wdt.h              |   26
>  plat-sirfsoc/platform_device/Makefile                        |   36
>  plat-sirfsoc/platform_device/android_usb_dev.c               |   60
>  plat-sirfsoc/platform_device/audio_dev.c                     |   88
>  plat-sirfsoc/platform_device/bt_codec_dev.c                  |   26
>  plat-sirfsoc/platform_device/camera_dev.c                    |  286 +
>  plat-sirfsoc/platform_device/eth_dev.c                       |   75
>  plat-sirfsoc/platform_device/gps_dev.c                       |  106
>  plat-sirfsoc/platform_device/i2c_dev.c                       |  124
>  plat-sirfsoc/platform_device/inner_audio_dev.c               |   75
>  plat-sirfsoc/platform_device/lcd_dev.c                       |  156
>  plat-sirfsoc/platform_device/mbx_dev.c                       |   74
>  plat-sirfsoc/platform_device/modac_dev.c                     |   67
>  plat-sirfsoc/platform_device/mved_dev.c                      |   70
>  plat-sirfsoc/platform_device/nand_dev.c                      |   75
>  plat-sirfsoc/platform_device/pmem_dev.c                      |   59
>  plat-sirfsoc/platform_device/pwm_device.c                    |   79
>  plat-sirfsoc/platform_device/sata_dev.c                      |   64
>  plat-sirfsoc/platform_device/sdmmc_dev.c                     |  108
>  plat-sirfsoc/platform_device/serial_dev.c                    |  241 +
>  plat-sirfsoc/platform_device/sirfsoc_rtcdev.c                |   78
>  plat-sirfsoc/platform_device/sirfsoc_tsdev.c                 |   65
>  plat-sirfsoc/platform_device/spi_dev.c                       |  163
>  plat-sirfsoc/platform_device/spigpio_dev.c                   |   75
>  plat-sirfsoc/platform_device/ts_stream_mode_dev.c            |   64
>  plat-sirfsoc/platform_device/usb_dev.c                       |  120
>  plat-sirfsoc/platform_device/usppcm_dev.c                    |   69
>  plat-sirfsoc/platform_device/uspserial_dev.c                 |  197 +
>  plat-sirfsoc/platform_device/uspspi_dev.c                    |   97
>  plat-sirfsoc/platform_device/vpp_dev.c                       |   70
>  plat-sirfsoc/platform_device/vxd_dev.c                       |   68
>  plat-sirfsoc/platform_device/wdt_dev.c                       |   41

These will probably all get replaced with device tree bindings.

>  plat-sirfsoc/include/plat/pm.h                               |   41
>  plat-sirfsoc/include/plat/pwm.h                              |   63
>  plat-sirfsoc/include/plat/regs-clkc.h                        |   33
>  plat-sirfsoc/include/plat/regs-gpio.h                        |   43
>  plat-sirfsoc/include/plat/regs-irq.h                         |   39
>  plat-sirfsoc/include/plat/regs-modac.h                       |  114
>  plat-sirfsoc/include/plat/regs-power.h                       |   77
>  plat-sirfsoc/include/plat/regs-pwm.h                         |   37
>  plat-sirfsoc/include/plat/regs-pwrc.h                        |   62
>  plat-sirfsoc/include/plat/regs-reset.h                       |   73
>  plat-sirfsoc/include/plat/regs-rsc.h                         |   78
>  plat-sirfsoc/include/plat/regs-rtc.h                         |   41
>  plat-sirfsoc/include/plat/regs-serial.h                      |   87
>  plat-sirfsoc/include/plat/regs-timer.h                       |   39
>  plat-sirfsoc/include/plat/regs-vip.h                         |   98
>  plat-sirfsoc/include/plat/sd.h                               |  110
>  plat-sirfsoc/include/plat/sirfsoc_adc.h                      |  261 +
>  plat-sirfsoc/include/plat/sirfsoc_usp.h                      |  288 +

And these can hopefully all get moved next to the respective drivers.

>  plat-sirfsoc/include/plat/system.h                           |   39
>  plat-sirfsoc/include/plat/timex.h                            |   33
>  plat-sirfsoc/include/plat/uncompress.h                       |   46
>  plat-sirfsoc/include/plat/vmalloc.h                          |   26
>  plat-sirfsoc/irq.c                                           |  102
>  plat-sirfsoc/lcd_panels.c                                    |  281 +
>  plat-sirfsoc/led.c                                           |  340 +
>  plat-sirfsoc/perfmon.c                                       | 1347 +++++++

For the perfmon implementation, I would recommend splitting it out of the
submission at the beginning. If it's based on perf, it should be easy to
add at a later stage. Otherwise, it's not going anywhere. If it's related
to the ARM system trace macrocell, I'd recommend posting the code now
(independent of the rest), because other people are interested in getting
that to work.

>  plat-sirfsoc/pinmux.c                                        |  992 +++++

-> pinmux subsystem

> for drivers/:
>  Kconfig                             |    2
>  Makefile                            |    1
>  char/sirfsoc_gps.c                  |  878 +++++++++++++
>  char/sirfsoc_gpsdrv.h               |  134 +
>  input/misc/gpio_event.c             |  253 +++

A new user space interface is always hard to establish. If you want these
to get in, you should start way ahead of the other drivers that simply
implement an existing interface.

If the gps driver is just a tty device like a serial port, it should
now be moved into drivers/tty.

>  nanddisk/Kconfig                    |   17
>  nanddisk/Makefile                   |    5
>  nanddisk/nand.c                     |  937 +++++++++++++
>  nanddisk/nanddisk.h                 |  702 ++++++++++

How does this relate to drivers/mtd?

>  net/dm9000.c                        |  290 +---
>  net/dm9000.h                        |    8

Ah, code removal ;-)

>  video/Kconfig                       |   24
>  video/Makefile                      |    2
>  video/backlight/Makefile            |    1
>  video/sirfsoc_clcdc.h               |  269 ++++
>  video/sirfsoc_fb.c                  | 2369 +++++++++++++++++++++++++++++++++++
>  video/sirfsoc_vpp.c                 | 1166 +++++++++++++++++

Have you considered doing a KMS device driver instead of an old-style
frame buffer?

> i want to upstream steps by steps. send arch/arm patches for reviewing
> at first, then clean-up drivers and send patches to subsystem for
> reviewing. There are really too many issues waiting for refination in
> arch/arm for the moment, we have more than 20 tasks for team to work.

Ok, no problem.

	Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Tony Lindgren]

* Catalin Marinas <catalin.marinas@arm.com> [110518 17:49]:
> Arnd,
> 
> On 18 May 2011 09:47, Arnd Bergmann <arnd@arndb.de> wrote:
> > This is the draft plan for maintaining the ARM subarchitectures in a common
> > tree, as a way to help coordinate the upstream merging of the
> > arch/arm/{plat,mach}-* changes into Linus' tree.
> 
> For clarification - the aim of this subarchitecture group is not only
> to coordinate the upstream merging but also take an active (primary)
> role in consolidating the existing code across various
> subarchitectures under arch/arm/.

It's good to see organized effort on consolidating the code.
And Linaro is probably the best place to organize this effort.

Naturally I assume that you guys won't be merging any platform
specific patches without proper acks from the platform maintainers:

Acked-by: Tony Lindgren <tony@atomide.com>

Arnd, do you want to do a practise run with pulling in the omap
code and merging to Linus for this merge window?

Regards,

Tony

[RFC] ARM Subarchitecture group maintainership

[Tony Lindgren]

* Catalin Marinas <catalin.marinas@arm.com> [110518 17:49]:
> Arnd,
> 
> On 18 May 2011 09:47, Arnd Bergmann <arnd@arndb.de> wrote:
> > This is the draft plan for maintaining the ARM subarchitectures in a common
> > tree, as a way to help coordinate the upstream merging of the
> > arch/arm/{plat,mach}-* changes into Linus' tree.
> 
> For clarification - the aim of this subarchitecture group is not only
> to coordinate the upstream merging but also take an active (primary)
> role in consolidating the existing code across various
> subarchitectures under arch/arm/.

It's good to see organized effort on consolidating the code.
And Linaro is probably the best place to organize this effort.

Naturally I assume that you guys won't be merging any platform
specific patches without proper acks from the platform maintainers:

Acked-by: Tony Lindgren <tony@atomide.com>

Arnd, do you want to do a practise run with pulling in the omap
code and merging to Linus for this merge window?

Regards,

Tony

Re: [RFC] ARM Subarchitecture group maintainership

[Nicolas Ferre]

Le 18/05/2011 10:47, Arnd Bergmann :
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.

[..]

> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S:	Maintained
>  F:	drivers/amba/
>  F:	include/linux/amba/bus.h
>  
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm@kernel.org

New alias needed?

> +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED
> +F:	arch/arm/mach-*/
> +F:	arch/arm/plat-*/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git

I like this initiative. Thanks to you guys for this effort!

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
(as co-maintainer of the Atmel AT91 subarchitecture)

Bye,
-- 
Nicolas Ferre

[RFC] ARM Subarchitecture group maintainership

[Nicolas Ferre]

Le 18/05/2011 10:47, Arnd Bergmann :
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.

[..]

> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S:	Maintained
>  F:	drivers/amba/
>  F:	include/linux/amba/bus.h
>  
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm at kernel.org

New alias needed?

> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED
> +F:	arch/arm/mach-*/
> +F:	arch/arm/plat-*/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git

I like this initiative. Thanks to you guys for this effort!

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
(as co-maintainer of the Atmel AT91 subarchitecture)

Bye,
-- 
Nicolas Ferre

Re: [RFC] ARM Subarchitecture group maintainership

[Sascha Hauer]

On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
> 
> This was discussed in great length at the Linaro Developer Summit in Budapest
> last week where we worked out an initial plan. We are modeling the maintainance
> after how the linux-tip tree is used for the x86 architecture, with a set
> of developers that have commit access to one tree on kernel.org and
> have mutual trust in one another. Nicolas Pitre and me are funded
> by Linaro to do the bulk of the work, while Thomas Gleixner will help
> us part-time with his long time architecture maintainance experience.
> Despite the funding by Linaro, this is not a Linaro project and all
> ARM subarchitectures are welcome to go through our tree.
> 
> Russell King's role as ARM maintainer is of course unchanged by this, but
> he has the same commit access to the new tree as the other maintainers and
> is welcome to work in the same tree. We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google. We have to find the right balance with the
> number of committers so we get all the work done without stepping on each
> other's toes.
> 
> Our tree will be strictly organized in topic brances so we can feed them
> upstream in the bitesized chunks that Linus likes. The master branch
> is an integration branch that pulls all other branches that are scheduled
> for the next merge window and itself gets integrated into linux-next.
> 
> We will probably not be fully functional during the 2.6.40 merge window,
> but we are trying our best to be useful. For 2.6.41, my hope is that
> we can merge the bulk of the ARM subarchitecture changes through this
> tree. Once Linus is happy with the way that the process works, we can
> mandate that all ARM subarchitecture changes go through our tree, until
> then it stays voluntary.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> 
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.

As Freescale i.MX maintainer:

Acked-by: Sascha Hauer <s.hauer@pengutronix.de>


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

[RFC] ARM Subarchitecture group maintainership

[Sascha Hauer]

On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
> 
> This was discussed in great length at the Linaro Developer Summit in Budapest
> last week where we worked out an initial plan. We are modeling the maintainance
> after how the linux-tip tree is used for the x86 architecture, with a set
> of developers that have commit access to one tree on kernel.org and
> have mutual trust in one another. Nicolas Pitre and me are funded
> by Linaro to do the bulk of the work, while Thomas Gleixner will help
> us part-time with his long time architecture maintainance experience.
> Despite the funding by Linaro, this is not a Linaro project and all
> ARM subarchitectures are welcome to go through our tree.
> 
> Russell King's role as ARM maintainer is of course unchanged by this, but
> he has the same commit access to the new tree as the other maintainers and
> is welcome to work in the same tree. We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google. We have to find the right balance with the
> number of committers so we get all the work done without stepping on each
> other's toes.
> 
> Our tree will be strictly organized in topic brances so we can feed them
> upstream in the bitesized chunks that Linus likes. The master branch
> is an integration branch that pulls all other branches that are scheduled
> for the next merge window and itself gets integrated into linux-next.
> 
> We will probably not be fully functional during the 2.6.40 merge window,
> but we are trying our best to be useful. For 2.6.41, my hope is that
> we can merge the bulk of the ARM subarchitecture changes through this
> tree. Once Linus is happy with the way that the process works, we can
> mandate that all ARM subarchitecture changes go through our tree, until
> then it stays voluntary.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> 
> ---
> 
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.

As Freescale i.MX maintainer:

Acked-by: Sascha Hauer <s.hauer@pengutronix.de>


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

Re: [RFC] ARM Subarchitecture group maintainership

[Nicolas Pitre]

On Wed, 25 May 2011, Tony Lindgren wrote:

> * Catalin Marinas <catalin.marinas@arm.com> [110518 17:49]:
> > Arnd,
> > 
> > On 18 May 2011 09:47, Arnd Bergmann <arnd@arndb.de> wrote:
> > > This is the draft plan for maintaining the ARM subarchitectures in a common
> > > tree, as a way to help coordinate the upstream merging of the
> > > arch/arm/{plat,mach}-* changes into Linus' tree.
> > 
> > For clarification - the aim of this subarchitecture group is not only
> > to coordinate the upstream merging but also take an active (primary)
> > role in consolidating the existing code across various
> > subarchitectures under arch/arm/.
> 
> It's good to see organized effort on consolidating the code.
> And Linaro is probably the best place to organize this effort.
> 
> Naturally I assume that you guys won't be merging any platform
> specific patches without proper acks from the platform maintainers:

Obviously.  In fact I expect platform maintainers to be the ones pushing 
their merge requests to us.  This is not going to replace the job you're 
currently doing.

> Arnd, do you want to do a practise run with pulling in the omap
> code and merging to Linus for this merge window?

No.  We'll start merging stuff once this merge window is over.  In other 
words, you are still on your own for the current one.

Also, I want stuff merged in this subarch tree way before the next merge 
window opens on a continuous basis, not in a big rush before it opens, 
or worse, while it is already open.


Nicolas




> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[RFC] ARM Subarchitecture group maintainership

[Nicolas Pitre]

On Wed, 25 May 2011, Tony Lindgren wrote:

> * Catalin Marinas <catalin.marinas@arm.com> [110518 17:49]:
> > Arnd,
> > 
> > On 18 May 2011 09:47, Arnd Bergmann <arnd@arndb.de> wrote:
> > > This is the draft plan for maintaining the ARM subarchitectures in a common
> > > tree, as a way to help coordinate the upstream merging of the
> > > arch/arm/{plat,mach}-* changes into Linus' tree.
> > 
> > For clarification - the aim of this subarchitecture group is not only
> > to coordinate the upstream merging but also take an active (primary)
> > role in consolidating the existing code across various
> > subarchitectures under arch/arm/.
> 
> It's good to see organized effort on consolidating the code.
> And Linaro is probably the best place to organize this effort.
> 
> Naturally I assume that you guys won't be merging any platform
> specific patches without proper acks from the platform maintainers:

Obviously.  In fact I expect platform maintainers to be the ones pushing 
their merge requests to us.  This is not going to replace the job you're 
currently doing.

> Arnd, do you want to do a practise run with pulling in the omap
> code and merging to Linus for this merge window?

No.  We'll start merging stuff once this merge window is over.  In other 
words, you are still on your own for the current one.

Also, I want stuff merged in this subarch tree way before the next merge 
window opens on a continuous basis, not in a big rush before it opens, 
or worse, while it is already open.


Nicolas




> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [RFC] ARM Subarchitecture group maintainership

[Tony Lindgren]

* Nicolas Pitre <nico@fluxnic.net> [110525 07:24]:
> 
> No.  We'll start merging stuff once this merge window is over.  In other 
> words, you are still on your own for the current one.

OK
 
> Also, I want stuff merged in this subarch tree way before the next merge 
> window opens on a continuous basis, not in a big rush before it opens, 
> or worse, while it is already open.

OK that sounds good to me. There's at least one more thing to sort out
though:

What do you want to do with with the various for-next branches?

Do you want to queue things into your tree before hitting for-next?

Tony

[RFC] ARM Subarchitecture group maintainership

[Tony Lindgren]

* Nicolas Pitre <nico@fluxnic.net> [110525 07:24]:
> 
> No.  We'll start merging stuff once this merge window is over.  In other 
> words, you are still on your own for the current one.

OK
 
> Also, I want stuff merged in this subarch tree way before the next merge 
> window opens on a continuous basis, not in a big rush before it opens, 
> or worse, while it is already open.

OK that sounds good to me. There's at least one more thing to sort out
though:

What do you want to do with with the various for-next branches?

Do you want to queue things into your tree before hitting for-next?

Tony

Re: [RFC] ARM Subarchitecture group maintainership

[Thomas Gleixner]

On Wed, 25 May 2011, Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [110525 07:24]:
> > 
> > No.  We'll start merging stuff once this merge window is over.  In other 
> > words, you are still on your own for the current one.
> 
> OK
>  
> > Also, I want stuff merged in this subarch tree way before the next merge 
> > window opens on a continuous basis, not in a big rush before it opens, 
> > or worse, while it is already open.
> 
> OK that sounds good to me. There's at least one more thing to sort out
> though:
> 
> What do you want to do with with the various for-next branches?
> 
> Do you want to queue things into your tree before hitting for-next?

The stuff which gets pulled in from the various suppliers is
aggregated in a separate for -next branch.

Thanks,

	tglx

[RFC] ARM Subarchitecture group maintainership

[Thomas Gleixner]

On Wed, 25 May 2011, Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [110525 07:24]:
> > 
> > No.  We'll start merging stuff once this merge window is over.  In other 
> > words, you are still on your own for the current one.
> 
> OK
>  
> > Also, I want stuff merged in this subarch tree way before the next merge 
> > window opens on a continuous basis, not in a big rush before it opens, 
> > or worse, while it is already open.
> 
> OK that sounds good to me. There's at least one more thing to sort out
> though:
> 
> What do you want to do with with the various for-next branches?
> 
> Do you want to queue things into your tree before hitting for-next?

The stuff which gets pulled in from the various suppliers is
aggregated in a separate for -next branch.

Thanks,

	tglx

RE: [RFC] ARM Subarchitecture group maintainership

[H Hartley Sweeten]

On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
> 
> This was discussed in great length at the Linaro Developer Summit in Budapest
> last week where we worked out an initial plan. We are modeling the maintainance
> after how the linux-tip tree is used for the x86 architecture, with a set
> of developers that have commit access to one tree on kernel.org and
> have mutual trust in one another. Nicolas Pitre and me are funded
> by Linaro to do the bulk of the work, while Thomas Gleixner will help
> us part-time with his long time architecture maintainance experience.
> Despite the funding by Linaro, this is not a Linaro project and all
> ARM subarchitectures are welcome to go through our tree.
> 
> Russell King's role as ARM maintainer is of course unchanged by this, but
> he has the same commit access to the new tree as the other maintainers and
> is welcome to work in the same tree. We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google. We have to find the right balance with the
> number of committers so we get all the work done without stepping on each
> other's toes.
> 
> Our tree will be strictly organized in topic brances so we can feed them
> upstream in the bitesized chunks that Linus likes. The master branch
> is an integration branch that pulls all other branches that are scheduled
> for the next merge window and itself gets integrated into linux-next.
> 
> We will probably not be fully functional during the 2.6.40 merge window,
> but we are trying our best to be useful. For 2.6.41, my hope is that
> we can merge the bulk of the ARM subarchitecture changes through this
> tree. Once Linus is happy with the way that the process works, we can
> mandate that all ARM subarchitecture changes go through our tree, until
> then it stays voluntary.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> 
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.

As co-maintainer of ep93xx

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

[RFC] ARM Subarchitecture group maintainership

[H Hartley Sweeten]

On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
> 
> This was discussed in great length at the Linaro Developer Summit in Budapest
> last week where we worked out an initial plan. We are modeling the maintainance
> after how the linux-tip tree is used for the x86 architecture, with a set
> of developers that have commit access to one tree on kernel.org and
> have mutual trust in one another. Nicolas Pitre and me are funded
> by Linaro to do the bulk of the work, while Thomas Gleixner will help
> us part-time with his long time architecture maintainance experience.
> Despite the funding by Linaro, this is not a Linaro project and all
> ARM subarchitectures are welcome to go through our tree.
> 
> Russell King's role as ARM maintainer is of course unchanged by this, but
> he has the same commit access to the new tree as the other maintainers and
> is welcome to work in the same tree. We are also open to nominations for
> further people outside of Linaro to join us as committers. Marc Zyngier from
> ARM ltd is one of the candidates that has been suggested and I would also
> like to see someone from Google. We have to find the right balance with the
> number of committers so we get all the work done without stepping on each
> other's toes.
> 
> Our tree will be strictly organized in topic brances so we can feed them
> upstream in the bitesized chunks that Linus likes. The master branch
> is an integration branch that pulls all other branches that are scheduled
> for the next merge window and itself gets integrated into linux-next.
> 
> We will probably not be fully functional during the 2.6.40 merge window,
> but we are trying our best to be useful. For 2.6.41, my hope is that
> we can merge the bulk of the ARM subarchitecture changes through this
> tree. Once Linus is happy with the way that the process works, we can
> mandate that all ARM subarchitecture changes go through our tree, until
> then it stays voluntary.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> 
> ---
> 
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.

As co-maintainer of ep93xx

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

Re: [RFC] ARM Subarchitecture group maintainership

[Mark Brown]

On Wed, May 25, 2011 at 06:06:16PM +0200, Thomas Gleixner wrote:
> On Wed, 25 May 2011, Tony Lindgren wrote:

> > What do you want to do with with the various for-next branches?

> > Do you want to queue things into your tree before hitting for-next?

> The stuff which gets pulled in from the various suppliers is
> aggregated in a separate for -next branch.

I think the question is about the existing -next branches people already
have - should they contain code that hasn't yet gone to you guys?  We're
doing that for audio at the minute (having subtrees in -next directly)
and it's pretty helpful for miniising hassle for the maintainers of the
core tree.

[RFC] ARM Subarchitecture group maintainership

[Mark Brown]

On Wed, May 25, 2011 at 06:06:16PM +0200, Thomas Gleixner wrote:
> On Wed, 25 May 2011, Tony Lindgren wrote:

> > What do you want to do with with the various for-next branches?

> > Do you want to queue things into your tree before hitting for-next?

> The stuff which gets pulled in from the various suppliers is
> aggregated in a separate for -next branch.

I think the question is about the existing -next branches people already
have - should they contain code that hasn't yet gone to you guys?  We're
doing that for audio at the minute (having subtrees in -next directly)
and it's pretty helpful for miniising hassle for the maintainers of the
core tree.

Re: [RFC] ARM Subarchitecture group maintainership

[Thomas Gleixner]

On Thu, 26 May 2011, Mark Brown wrote:

> On Wed, May 25, 2011 at 06:06:16PM +0200, Thomas Gleixner wrote:
> > On Wed, 25 May 2011, Tony Lindgren wrote:
> 
> > > What do you want to do with with the various for-next branches?
> 
> > > Do you want to queue things into your tree before hitting for-next?
> 
> > The stuff which gets pulled in from the various suppliers is
> > aggregated in a separate for -next branch.
> 
> I think the question is about the existing -next branches people already
> have - should they contain code that hasn't yet gone to you guys?  We're
> doing that for audio at the minute (having subtrees in -next directly)
> and it's pretty helpful for miniising hassle for the maintainers of the
> core tree.

We obviously talk about arch/arm/[mach|plat]* stuff, drivers/ sound/
etc. should go through the relevant maintainer trees.

Thanks,

	tglx

[RFC] ARM Subarchitecture group maintainership

[Thomas Gleixner]

On Thu, 26 May 2011, Mark Brown wrote:

> On Wed, May 25, 2011 at 06:06:16PM +0200, Thomas Gleixner wrote:
> > On Wed, 25 May 2011, Tony Lindgren wrote:
> 
> > > What do you want to do with with the various for-next branches?
> 
> > > Do you want to queue things into your tree before hitting for-next?
> 
> > The stuff which gets pulled in from the various suppliers is
> > aggregated in a separate for -next branch.
> 
> I think the question is about the existing -next branches people already
> have - should they contain code that hasn't yet gone to you guys?  We're
> doing that for audio at the minute (having subtrees in -next directly)
> and it's pretty helpful for miniising hassle for the maintainers of the
> core tree.

We obviously talk about arch/arm/[mach|plat]* stuff, drivers/ sound/
etc. should go through the relevant maintainer trees.

Thanks,

	tglx

Re: [RFC] ARM Subarchitecture group maintainership

[Mark Brown]

On Thu, May 26, 2011 at 10:33:55AM +0200, Thomas Gleixner wrote:
> On Thu, 26 May 2011, Mark Brown wrote:

> > I think the question is about the existing -next branches people already
> > have - should they contain code that hasn't yet gone to you guys?  We're
> > doing that for audio at the minute (having subtrees in -next directly)
> > and it's pretty helpful for miniising hassle for the maintainers of the
> > core tree.

> We obviously talk about arch/arm/[mach|plat]* stuff, drivers/ sound/
> etc. should go through the relevant maintainer trees.

Right, but the question is what to do with the subtrees that are in
-next currently.  I'm mentioning sound as an example of a tree with
subtrees in -next directly.

[RFC] ARM Subarchitecture group maintainership

[Mark Brown]

On Thu, May 26, 2011 at 10:33:55AM +0200, Thomas Gleixner wrote:
> On Thu, 26 May 2011, Mark Brown wrote:

> > I think the question is about the existing -next branches people already
> > have - should they contain code that hasn't yet gone to you guys?  We're
> > doing that for audio at the minute (having subtrees in -next directly)
> > and it's pretty helpful for miniising hassle for the maintainers of the
> > core tree.

> We obviously talk about arch/arm/[mach|plat]* stuff, drivers/ sound/
> etc. should go through the relevant maintainer trees.

Right, but the question is what to do with the subtrees that are in
-next currently.  I'm mentioning sound as an example of a tree with
subtrees in -next directly.

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Thursday 26 May 2011, Mark Brown wrote:
> 
> On Thu, May 26, 2011 at 10:33:55AM +0200, Thomas Gleixner wrote:
> > On Thu, 26 May 2011, Mark Brown wrote:
> 
> > > I think the question is about the existing -next branches people already
> > > have - should they contain code that hasn't yet gone to you guys?  We're
> > > doing that for audio at the minute (having subtrees in -next directly)
> > > and it's pretty helpful for miniising hassle for the maintainers of the
> > > core tree.
> 
> > We obviously talk about arch/arm/[mach|plat]* stuff, drivers/ sound/
> > etc. should go through the relevant maintainer trees.
> 
> Right, but the question is what to do with the subtrees that are in
> -next currently.  I'm mentioning sound as an example of a tree with
> subtrees in -next directly.

I think all the subarch maintainers should basically stop having their
stuff included directly in linux-next, but instead have it pulled into
our tree, which has one aggregate -next branch that gets included there.

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Thursday 26 May 2011, Mark Brown wrote:
> 
> On Thu, May 26, 2011 at 10:33:55AM +0200, Thomas Gleixner wrote:
> > On Thu, 26 May 2011, Mark Brown wrote:
> 
> > > I think the question is about the existing -next branches people already
> > > have - should they contain code that hasn't yet gone to you guys?  We're
> > > doing that for audio at the minute (having subtrees in -next directly)
> > > and it's pretty helpful for miniising hassle for the maintainers of the
> > > core tree.
> 
> > We obviously talk about arch/arm/[mach|plat]* stuff, drivers/ sound/
> > etc. should go through the relevant maintainer trees.
> 
> Right, but the question is what to do with the subtrees that are in
> -next currently.  I'm mentioning sound as an example of a tree with
> subtrees in -next directly.

I think all the subarch maintainers should basically stop having their
stuff included directly in linux-next, but instead have it pulled into
our tree, which has one aggregate -next branch that gets included there.

	Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Kevin Hilman]

Arnd Bergmann <arnd@arndb.de> writes:

> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.

[...]

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
>
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.

Acked-by: Kevin Hilman <khilman@ti.com>

for davinci and OMAP stuff I maintain.

Kevin

[RFC] ARM Subarchitecture group maintainership

[Kevin Hilman]

Arnd Bergmann <arnd@arndb.de> writes:

> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.

[...]

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
>
> ---
>
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.

Acked-by: Kevin Hilman <khilman@ti.com>

for davinci and OMAP stuff I maintain.

Kevin

Re: [RFC] ARM Subarchitecture group maintainership

[Kyungmin Park]

Acked-by: Kyungmin Park <kyungmin.park@samsung.com>

from Samsung Mobile & DMC codes

On Fri, May 27, 2011 at 1:14 AM, Kevin Hilman <khilman@ti.com> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> This is the draft plan for maintaining the ARM subarchitectures in a common
>> tree, as a way to help coordinate the upstream merging of the
>> arch/arm/{plat,mach}-* changes into Linus' tree.
>
> [...]
>
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Nicolas Pitre <nico@fluxnic.net>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>>
>> ---
>>
>> Maintainers: If you are happy with the layout of the process,
>> please ack this patch, otherwise please comment.
>
> Acked-by: Kevin Hilman <khilman@ti.com>
>
> for davinci and OMAP stuff I maintain.
>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

[RFC] ARM Subarchitecture group maintainership

[Kyungmin Park]

Acked-by: Kyungmin Park <kyungmin.park@samsung.com>

from Samsung Mobile & DMC codes

On Fri, May 27, 2011 at 1:14 AM, Kevin Hilman <khilman@ti.com> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> This is the draft plan for maintaining the ARM subarchitectures in a common
>> tree, as a way to help coordinate the upstream merging of the
>> arch/arm/{plat,mach}-* changes into Linus' tree.
>
> [...]
>
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Nicolas Pitre <nico@fluxnic.net>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>>
>> ---
>>
>> Maintainers: If you are happy with the layout of the process,
>> please ack this patch, otherwise please comment.
>
> Acked-by: Kevin Hilman <khilman@ti.com>
>
> for davinci and OMAP stuff I maintain.
>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>

Re: [RFC] ARM Subarchitecture group maintainership

[viresh kumar]

On 05/19/2011 07:20 PM, Arnd Bergmann wrote:
>> > i asked this because we wanted to send the source codes of
>> > CSR(http://www.csr.com) to upstream as i have told you in LDS. it
>> > looks like we need to follow the below new changes to make our source
>> > codes acceptable?
>> > 1. arm device tree
>> > 2. new pinmux framework from Linus Walleij
>> > 3. move GPIO from plat/mach to drivers/gpio?
> I would count at least the last two as mandatory, for the device tree,
> it depends on how much work it would be for you to do the conversion
> and at what time you submit the series. The longer you wait before
> submitting the series, the stricter the requirements will get.
> 

Arnd,

We also have few patchsets for ST's SPEAr SOC family. They were already
reviewed, but never got pushed.

We will update all those pacthsets for point 2 & 3, and leave point 1 for now.
Also we will update them with our latest changes for SPEAr and will circulate
them ASAP.

Hope that's fine.

-- 
viresh

[RFC] ARM Subarchitecture group maintainership

[viresh kumar]

On 05/19/2011 07:20 PM, Arnd Bergmann wrote:
>> > i asked this because we wanted to send the source codes of
>> > CSR(http://www.csr.com) to upstream as i have told you in LDS. it
>> > looks like we need to follow the below new changes to make our source
>> > codes acceptable?
>> > 1. arm device tree
>> > 2. new pinmux framework from Linus Walleij
>> > 3. move GPIO from plat/mach to drivers/gpio?
> I would count at least the last two as mandatory, for the device tree,
> it depends on how much work it would be for you to do the conversion
> and at what time you submit the series. The longer you wait before
> submitting the series, the stricter the requirements will get.
> 

Arnd,

We also have few patchsets for ST's SPEAr SOC family. They were already
reviewed, but never got pushed.

We will update all those pacthsets for point 2 & 3, and leave point 1 for now.
Also we will update them with our latest changes for SPEAr and will circulate
them ASAP.

Hope that's fine.

-- 
viresh

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Friday 27 May 2011, viresh kumar wrote:
> We also have few patchsets for ST's SPEAr SOC family. They were already
> reviewed, but never got pushed.
> 
> We will update all those pacthsets for point 2 & 3, and leave point 1 for now.
> Also we will update them with our latest changes for SPEAr and will circulate
> them ASAP.
> 
> Hope that's fine.

Sure, please do. Once we look at the patch sets, we can also discuss about
how and when to change them over to device tree. Since the spear13xx patches
you posted only have support for a single board, it should be fairly easy
to replace the board file with a generic device tree based one.

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Friday 27 May 2011, viresh kumar wrote:
> We also have few patchsets for ST's SPEAr SOC family. They were already
> reviewed, but never got pushed.
> 
> We will update all those pacthsets for point 2 & 3, and leave point 1 for now.
> Also we will update them with our latest changes for SPEAr and will circulate
> them ASAP.
> 
> Hope that's fine.

Sure, please do. Once we look at the patch sets, we can also discuss about
how and when to change them over to device tree. Since the spear13xx patches
you posted only have support for a single board, it should be fairly easy
to replace the board file with a generic device tree based one.

	Arnd

Re: [RFC] ARM Subarchitecture group maintainership

[Stephen Boyd]

On 05/18/2011 01:47 AM, Arnd Bergmann wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
>
[snip]
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S:	Maintained
>  F:	drivers/amba/
>  F:	include/linux/amba/bus.h
>  
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm@kernel.org
> +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED
> +F:	arch/arm/mach-*/
> +F:	arch/arm/plat-*/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> +
>  ARM/ADI ROADRUNNER MACHINE SUPPORT
>  M:	Lennert Buytenhek <kernel@wantstofly.org>
>  L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>

Is this patch (or something similar) going to be merged now that the ARM
SoC tree is up and running? Also, is the arm@kernel.org alias working?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[RFC] ARM Subarchitecture group maintainership

[Stephen Boyd]

On 05/18/2011 01:47 AM, Arnd Bergmann wrote:
> This is the draft plan for maintaining the ARM subarchitectures in a common
> tree, as a way to help coordinate the upstream merging of the
> arch/arm/{plat,mach}-* changes into Linus' tree.
>
[snip]
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8fce5e6..942d052 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -630,6 +630,17 @@ S:	Maintained
>  F:	drivers/amba/
>  F:	include/linux/amba/bus.h
>  
> +ARM SUBARCHITECTURES
> +M:	Arnd Bergmann <arnd@arndb.de>
> +M:	Nicolas Pitre <nico@fluxnic.net>
> +M:	Thomas Gleixner <tglx@linutronix.de>
> +M:	arm at kernel.org
> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:	MAINTAINED
> +F:	arch/arm/mach-*/
> +F:	arch/arm/plat-*/
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
> +
>  ARM/ADI ROADRUNNER MACHINE SUPPORT
>  M:	Lennert Buytenhek <kernel@wantstofly.org>
>  L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>

Is this patch (or something similar) going to be merged now that the ARM
SoC tree is up and running? Also, is the arm at kernel.org alias working?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [RFC] ARM Subarchitecture group maintainership

[Barry Song]

2011/7/27 Stephen Boyd <sboyd@codeaurora.org>:
> On 05/18/2011 01:47 AM, Arnd Bergmann wrote:
>> This is the draft plan for maintaining the ARM subarchitectures in a common
>> tree, as a way to help coordinate the upstream merging of the
>> arch/arm/{plat,mach}-* changes into Linus' tree.
>>
> [snip]
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8fce5e6..942d052 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -630,6 +630,17 @@ S:       Maintained
>>  F:   drivers/amba/
>>  F:   include/linux/amba/bus.h
>>
>> +ARM SUBARCHITECTURES
>> +M:   Arnd Bergmann <arnd@arndb.de>
>> +M:   Nicolas Pitre <nico@fluxnic.net>
>> +M:   Thomas Gleixner <tglx@linutronix.de>
>> +M:   arm@kernel.org
>> +L:   linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>> +S:   MAINTAINED
>> +F:   arch/arm/mach-*/
>> +F:   arch/arm/plat-*/
>> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
>> +
>>  ARM/ADI ROADRUNNER MACHINE SUPPORT
>>  M:   Lennert Buytenhek <kernel@wantstofly.org>
>>  L:   linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>>
>
> Is this patch (or something similar) going to be merged now that the ARM
> SoC tree is up and running? Also, is the arm@kernel.org alias working?

yes. arm soc tree has been working and 3.1 window has pulled from Arnd
several times.

http://git.kernel.org/?p=linux/kernel/git/arm/linux-arm-soc.git;a=summary

>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[RFC] ARM Subarchitecture group maintainership

[Barry Song]

2011/7/27 Stephen Boyd <sboyd@codeaurora.org>:
> On 05/18/2011 01:47 AM, Arnd Bergmann wrote:
>> This is the draft plan for maintaining the ARM subarchitectures in a common
>> tree, as a way to help coordinate the upstream merging of the
>> arch/arm/{plat,mach}-* changes into Linus' tree.
>>
> [snip]
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8fce5e6..942d052 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -630,6 +630,17 @@ S: ? ? ? Maintained
>> ?F: ? drivers/amba/
>> ?F: ? include/linux/amba/bus.h
>>
>> +ARM SUBARCHITECTURES
>> +M: ? Arnd Bergmann <arnd@arndb.de>
>> +M: ? Nicolas Pitre <nico@fluxnic.net>
>> +M: ? Thomas Gleixner <tglx@linutronix.de>
>> +M: ? arm at kernel.org
>> +L: ? linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> +S: ? MAINTAINED
>> +F: ? arch/arm/mach-*/
>> +F: ? arch/arm/plat-*/
>> +T: ? git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
>> +
>> ?ARM/ADI ROADRUNNER MACHINE SUPPORT
>> ?M: ? Lennert Buytenhek <kernel@wantstofly.org>
>> ?L: ? linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>>
>
> Is this patch (or something similar) going to be merged now that the ARM
> SoC tree is up and running? Also, is the arm at kernel.org alias working?

yes. arm soc tree has been working and 3.1 window has pulled from Arnd
several times.

http://git.kernel.org/?p=linux/kernel/git/arm/linux-arm-soc.git;a=summary

>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Re: [RFC] ARM Subarchitecture group maintainership

[Stephen Boyd]

On 07/26/2011 06:47 PM, Barry Song wrote:
> 2011/7/27 Stephen Boyd <sboyd@codeaurora.org>:
>> On 05/18/2011 01:47 AM, Arnd Bergmann wrote:
>>> This is the draft plan for maintaining the ARM subarchitectures in a common
>>> tree, as a way to help coordinate the upstream merging of the
>>> arch/arm/{plat,mach}-* changes into Linus' tree.
>>>
>> [snip]
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 8fce5e6..942d052 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -630,6 +630,17 @@ S:       Maintained
>>>  F:   drivers/amba/
>>>  F:   include/linux/amba/bus.h
>>>
>>> +ARM SUBARCHITECTURES
>>> +M:   Arnd Bergmann <arnd@arndb.de>
>>> +M:   Nicolas Pitre <nico@fluxnic.net>
>>> +M:   Thomas Gleixner <tglx@linutronix.de>
>>> +M:   arm@kernel.org
>>> +L:   linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>>> +S:   MAINTAINED
>>> +F:   arch/arm/mach-*/
>>> +F:   arch/arm/plat-*/
>>> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
>>> +
>>>  ARM/ADI ROADRUNNER MACHINE SUPPORT
>>>  M:   Lennert Buytenhek <kernel@wantstofly.org>
>>>  L:   linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>>>
>> Is this patch (or something similar) going to be merged now that the ARM
>> SoC tree is up and running? Also, is the arm@kernel.org alias working?
> yes. arm soc tree has been working and 3.1 window has pulled from Arnd
> several times.
>
> http://git.kernel.org/?p=linux/kernel/git/arm/linux-arm-soc.git;a=summary
>

That didn't really answer my questions, but thanks for pointing to the
arm-soc tree.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[RFC] ARM Subarchitecture group maintainership

[Stephen Boyd]

On 07/26/2011 06:47 PM, Barry Song wrote:
> 2011/7/27 Stephen Boyd <sboyd@codeaurora.org>:
>> On 05/18/2011 01:47 AM, Arnd Bergmann wrote:
>>> This is the draft plan for maintaining the ARM subarchitectures in a common
>>> tree, as a way to help coordinate the upstream merging of the
>>> arch/arm/{plat,mach}-* changes into Linus' tree.
>>>
>> [snip]
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 8fce5e6..942d052 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -630,6 +630,17 @@ S:       Maintained
>>>  F:   drivers/amba/
>>>  F:   include/linux/amba/bus.h
>>>
>>> +ARM SUBARCHITECTURES
>>> +M:   Arnd Bergmann <arnd@arndb.de>
>>> +M:   Nicolas Pitre <nico@fluxnic.net>
>>> +M:   Thomas Gleixner <tglx@linutronix.de>
>>> +M:   arm at kernel.org
>>> +L:   linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>>> +S:   MAINTAINED
>>> +F:   arch/arm/mach-*/
>>> +F:   arch/arm/plat-*/
>>> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-subarch.git
>>> +
>>>  ARM/ADI ROADRUNNER MACHINE SUPPORT
>>>  M:   Lennert Buytenhek <kernel@wantstofly.org>
>>>  L:   linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>>>
>> Is this patch (or something similar) going to be merged now that the ARM
>> SoC tree is up and running? Also, is the arm at kernel.org alias working?
> yes. arm soc tree has been working and 3.1 window has pulled from Arnd
> several times.
>
> http://git.kernel.org/?p=linux/kernel/git/arm/linux-arm-soc.git;a=summary
>

That didn't really answer my questions, but thanks for pointing to the
arm-soc tree.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Tuesday 26 July 2011, Stephen Boyd wrote:
> Is this patch (or something similar) going to be merged now that the ARM
> SoC tree is up and running? Also, is the arm@kernel.org alias working?

I should make a new version and post that. I totally forgot that one
with all the other patches coming in.

	Arnd

[RFC] ARM Subarchitecture group maintainership

[Arnd Bergmann]

On Tuesday 26 July 2011, Stephen Boyd wrote:
> Is this patch (or something similar) going to be merged now that the ARM
> SoC tree is up and running? Also, is the arm at kernel.org alias working?

I should make a new version and post that. I totally forgot that one
with all the other patches coming in.

	Arnd