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 <[email protected]>
Cc: Nicolas Pitre <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Russell King <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
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 <[email protected]>
+M: Nicolas Pitre <[email protected]>
+M: Thomas Gleixner <[email protected]>
+M: [email protected]
+L: [email protected] (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 <[email protected]>
L: [email protected] (moderated for non-subscribers)
Arnd,
On 18 May 2011 09:47, Arnd Bergmann <[email protected]> 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 <[email protected]>
> +M: Nicolas Pitre <[email protected]>
> +M: Thomas Gleixner <[email protected]>
> +M: [email protected]
With this additional line on ARM Ltd's behalf:
+M: Marc Zyngier <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
(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
On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
[...]
> +ARM SUBARCHITECTURES
> +M: Arnd Bergmann <[email protected]>
> +M: Nicolas Pitre <[email protected]>
> +M: Thomas Gleixner <[email protected]>
> +M: [email protected]
> +L: [email protected] (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
On Wed, May 18, 2011 at 6:22 PM, Shawn Guo <[email protected]> wrote:
> On Wed, May 18, 2011 at 10:47:16AM +0200, Arnd Bergmann wrote:
> [...]
>> +ARM SUBARCHITECTURES
>> +M: ? Arnd Bergmann <[email protected]>
>> +M: ? Nicolas Pitre <[email protected]>
>> +M: ? Thomas Gleixner <[email protected]>
>> +M: ? [email protected]
>> +L: ? [email protected] (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]
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.
On Wed, May 18 2011, Arnd Bergmann wrote:
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Nicolas Pitre <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
>
> ---
>
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.
Acked-by: David Brown <[email protected]>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
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
On Wednesday, 18 May 2011, Jean-Christophe PLAGNIOL-VILLARD
<[email protected]> 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
2011/5/18 Arnd Bergmann <[email protected]>:
> 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 <[email protected]>
> Cc: Nicolas Pitre <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
>
> ---
>
> 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 <[email protected]>
> +M: Nicolas Pitre <[email protected]>
> +M: Thomas Gleixner <[email protected]>
> +M: [email protected]
> +L: [email protected] (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 <[email protected]>
> L: [email protected] (moderated for non-subscribers)
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
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
Hi Nicolas,
Thanks for your reply.
2011/5/19 Nicolas Pitre <[email protected]>:
> 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
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 <[email protected]>
> +M: Nicolas Pitre <[email protected]>
> +M: Thomas Gleixner <[email protected]>
> +M: [email protected]
> +L: [email protected] (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 <[email protected]>
(As Maintainer of SPEAr Soc from ST Microelectronics)
--
viresh
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 <[email protected]>
> > +M: Nicolas Pitre <[email protected]>
> > +M: Thomas Gleixner <[email protected]>
> > +M: [email protected]
> > +L: [email protected] (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 [email protected] 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
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 <[email protected]>
> > +M: Nicolas Pitre <[email protected]>
> > +M: Thomas Gleixner <[email protected]>
> > +M: [email protected]
> > +L: [email protected] (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
On Thu, May 19, 2011 at 5:01 AM, Barry Song <[email protected]> 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
On Thursday 19 May 2011, Barry Song wrote:
> 2011/5/19 Nicolas Pitre <[email protected]>:
> > 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
2011/5/19 Arnd Bergmann <[email protected]>:
> On Thursday 19 May 2011, Barry Song wrote:
>> 2011/5/19 Nicolas Pitre <[email protected]>:
>> > 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
>
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
On Thu, May 19, 2011 at 03:31:42PM +0200, Linus Walleij wrote:
> On Thu, May 19, 2011 at 5:01 AM, Barry Song <[email protected]> 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.
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 <[email protected]> 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
2011/5/18 Arnd Bergmann <[email protected]>:
> 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 <[email protected]>
> +M: ? ? Nicolas Pitre <[email protected]>
> +M: ? ? Thomas Gleixner <[email protected]>
> +M: ? ? [email protected]
> +L: ? ? [email protected] (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 <[email protected]>
Thanks,
Linus Walleij
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 <[email protected]>
> +M: Nicolas Pitre <[email protected]>
> +M: Thomas Gleixner <[email protected]>
> +M: [email protected]
> +L: [email protected] (moderated for non-subscribers)
> +S: MAINTAINED
Trivial. Please use:
S: Maintained
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
2011/5/19 Arnd Bergmann <[email protected]>
>
> 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
On Tuesday 24 May 2011, Barry Song wrote:
> 2011/5/19 Arnd Bergmann <[email protected]>
>
> > 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
* Catalin Marinas <[email protected]> [110518 17:49]:
> Arnd,
>
> On 18 May 2011 09:47, Arnd Bergmann <[email protected]> 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 <[email protected]>
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
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 <[email protected]>
> +M: Nicolas Pitre <[email protected]>
> +M: Thomas Gleixner <[email protected]>
> +M: [email protected]
New alias needed?
> +L: [email protected] (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 <[email protected]>
(as co-maintainer of the Atmel AT91 subarchitecture)
Bye,
--
Nicolas Ferre
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 <[email protected]>
> Cc: Nicolas Pitre <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
>
> ---
>
> 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 <[email protected]>
--
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 |
On Wed, 25 May 2011, Tony Lindgren wrote:
> * Catalin Marinas <[email protected]> [110518 17:49]:
> > Arnd,
> >
> > On 18 May 2011 09:47, Arnd Bergmann <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
* Nicolas Pitre <[email protected]> [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
On Wed, 25 May 2011, Tony Lindgren wrote:
> * Nicolas Pitre <[email protected]> [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
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 <[email protected]>
> Cc: Nicolas Pitre <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
>
> ---
>
> 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 <[email protected]>
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.
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
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.
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
Arnd Bergmann <[email protected]> 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 <[email protected]>
> Cc: Nicolas Pitre <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
>
> ---
>
> Maintainers: If you are happy with the layout of the process,
> please ack this patch, otherwise please comment.
Acked-by: Kevin Hilman <[email protected]>
for davinci and OMAP stuff I maintain.
Kevin
Acked-by: Kyungmin Park <[email protected]>
from Samsung Mobile & DMC codes
On Fri, May 27, 2011 at 1:14 AM, Kevin Hilman <[email protected]> wrote:
> Arnd Bergmann <[email protected]> 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 <[email protected]>
>> Cc: Nicolas Pitre <[email protected]>
>> Cc: Thomas Gleixner <[email protected]>
>> Cc: Russell King <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>>
>> ---
>>
>> Maintainers: If you are happy with the layout of the process,
>> please ack this patch, otherwise please comment.
>
> Acked-by: Kevin Hilman <[email protected]>
>
> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
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
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