Hello,
I am working on behalf of an SoC vendor and I am trying to work out which (if any) of the many git trees at http://git.linaro.org/gitweb we should base our work on. I would like to use the Linaro code base because the arch/arm support is ahead of mainline. But I also need a degree of stability.
Ideally I would like a "long term support" Linaro kernel. Since that doesn't exist, one approach is use the linux-linaro-tracking tree but only use the linux-linaro-3.0* tagged versions so that we can easily merge in changes from v3.0 from kernel.org linux-stable.
So my questions are 1. Is this a rational approach? 2. Is this how you imagine other projects interfacing with Linaro? Or should we really be waiting for Linaro code to be mainlined and pulling from kernel.org?
Bye for now, Chris Simmonds
On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds chris.simmonds@2net.co.uk wrote:
Hello,
I am working on behalf of an SoC vendor and I am trying to work out which (if any) of the many git trees at http://git.linaro.org/gitweb we should
Is this a new SoC (no mainline support) or an existing SoC?
base our work on. I would like to use the Linaro code base because the arch/arm support is ahead of mainline. But I also need a degree of stability.
Ideally I would like a "long term support" Linaro kernel. Since that doesn't exist, one approach is use the linux-linaro-tracking tree but only use the linux-linaro-3.0* tagged versions so that we can easily merge in changes from v3.0 from kernel.org linux-stable.
LTSI is something that is work in progress by the Linux Foundation. But that is directed towards products shipping with already enabled SoCs. I don't think it is a good tree to follow for new SoC enablement.
So my questions are
- Is this a rational approach?
IMHO, you should be developing against mainline, say the last released kernel 3.3, if tracking 3.4-rc is too much. And then ask for it to be merged via the arm-soc tree if you have no other sub-arch maintainer above you.
- Is this how you imagine other projects interfacing with Linaro? Or should
we really be waiting for Linaro code to be mainlined and pulling from kernel.org?
If you need specific features from the Linaro tree, you should use git branches to track the tree and cherry-pick the bits that you do need. Can you give examples of things that you do need from the Linaro tree?
/Amit
On 04/04/12 11:53, Amit Kucheria wrote:
On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds chris.simmonds@2net.co.uk wrote:
Hello,
I am working on behalf of an SoC vendor and I am trying to work out which (if any) of the many git trees at http://git.linaro.org/gitweb we should
Is this a new SoC (no mainline support) or an existing SoC?
It's a new SoC which will have its own arch/arm/mach-xxx directory
Ideally I would like a "long term support" Linaro kernel. Since that doesn't exist, one approach is use the linux-linaro-tracking tree but only use the linux-linaro-3.0* tagged versions so that we can easily merge in changes from v3.0 from kernel.org linux-stable.
LTSI is something that is work in progress by the Linux Foundation. But that is directed towards products shipping with already enabled SoCs. I don't think it is a good tree to follow for new SoC enablement.
LTSI is interesting and something that I would like to track. But it does not help me with core arm support.
So my questions are
- Is this a rational approach?
IMHO, you should be developing against mainline, say the last released kernel 3.3, if tracking 3.4-rc is too much. And then ask for it to be merged via the arm-soc tree if you have no other sub-arch maintainer above you.
It is not feasible to track the tip mainline release both because it eats up man power in the kernel team but even more so in the QA team. Probably looking at one kernel release per year, ideally based on the long term kernel, currently 3.0.
When it comes to mainlining, is arm-soc the best way? There is no route via Linaro?
- Is this how you imagine other projects interfacing with Linaro? Or should
we really be waiting for Linaro code to be mainlined and pulling from kernel.org?
If you need specific features from the Linaro tree, you should use git branches to track the tree and cherry-pick the bits that you do need. Can you give examples of things that you do need from the Linaro tree?
Basically, everything in arch/arm/kernel, arch/arm/mm, etc. Right now the diff is mostly to do with device tree, which is interesting but not crucial. But the principle is that linux-linaro will have arm architecture support before mainline, no?
Bye for now, Chris.
On 4 April 2012 09:54, Chris Simmonds chris.simmonds@2net.co.uk wrote:
On 04/04/12 11:53, Amit Kucheria wrote:
On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds chris.simmonds@2net.co.uk wrote:
Hello,
I am working on behalf of an SoC vendor and I am trying to work out which (if any) of the many git trees at http://git.linaro.org/gitweb we should
Is this a new SoC (no mainline support) or an existing SoC?
It's a new SoC which will have its own arch/arm/mach-xxx directory
Ideally I would like a "long term support" Linaro kernel. Since that doesn't exist, one approach is use the linux-linaro-tracking tree but only use the linux-linaro-3.0* tagged versions so that we can easily merge in changes from v3.0 from kernel.org linux-stable.
LTSI is something that is work in progress by the Linux Foundation. But that is directed towards products shipping with already enabled SoCs. I don't think it is a good tree to follow for new SoC enablement.
LTSI is interesting and something that I would like to track. But it does not help me with core arm support.
So my questions are
- Is this a rational approach?
IMHO, you should be developing against mainline, say the last released kernel 3.3, if tracking 3.4-rc is too much. And then ask for it to be merged via the arm-soc tree if you have no other sub-arch maintainer above you.
It is not feasible to track the tip mainline release both because it eats up man power in the kernel team but even more so in the QA team. Probably looking at one kernel release per year, ideally based on the long term kernel, currently 3.0.
When it comes to mainlining, is arm-soc the best way? There is no route via Linaro?
- Is this how you imagine other projects interfacing with Linaro? Or
should we really be waiting for Linaro code to be mainlined and pulling from kernel.org?
If you need specific features from the Linaro tree, you should use git branches to track the tree and cherry-pick the bits that you do need. Can you give examples of things that you do need from the Linaro tree?
Basically, everything in arch/arm/kernel, arch/arm/mm, etc. Right now the diff is mostly to do with device tree, which is interesting but not crucial. But the principle is that linux-linaro will have arm architecture support before mainline, no?
We used to track the stable release of the kernel but are moving to tracking Linus' -rc tree and staying in sync with tip while merging in features that may not quite be ready fo upstream. Due to this, the deltas will be continuously changing For example, many of the Device Tree changes will get merged upstream but we will bring in other changes such as the Android upstream cleanups that may still be queued for the next merge window.
Since we are now tracking -rc, I think it is OK to work against our tree for new SOCs, specially if you want to enable features that are not yet in mainline. At the same time, keep a topic branch around that has only changes against mainline to make it easier to get those upstream.
Thanks, ~Deepak
On Wed, Apr 04, 2012 at 05:54:13PM +0100, Chris Simmonds wrote:
Is this a new SoC (no mainline support) or an existing SoC?
It's a new SoC which will have its own arch/arm/mach-xxx directory
You haven't stated clearly your intention -- is it your first priority to have support for this platform included in Linus' mainline, or are you more interested in the bring-up for a product goal?
So my questions are
- Is this a rational approach?
IMHO, you should be developing against mainline, say the last released kernel 3.3, if tracking 3.4-rc is too much. And then ask for it to be merged via the arm-soc tree if you have no other sub-arch maintainer above you.
It is not feasible to track the tip mainline release both because it eats up man power in the kernel team but even more so in the QA team. Probably looking at one kernel release per year, ideally based on the long term kernel, currently 3.0.
Based on your answer, I am guessing the latter option of the two I outlined above.
When it comes to mainlining, is arm-soc the best way? There is no route via Linaro?
That's correct -- the linux-linaro kernel is an integration tree, intended to validate and test cutting edge work happening in both working groups and member SoC and board bring-up. If you want to produce something suitable for mainline, you should base on trunk and uplevel your patches as mainline progresses.
In other words, the linux-linaro kernel isn't intended to be a base for /SoC bringup/ efforts [*]; it's much better for you to track trunk and bring in specific branches that you care about.
Note that I would certainly not start on 3.0, which is getting old very quickly. If you absolutely care about starting from a "stable" base, then I would start on the latest released kernel (currently 3.3); the state of things in ARM are such that every release you go backwards causes you to miss critical plumbing that we are working on.
If you need specific features from the Linaro tree, you should use git branches to track the tree and cherry-pick the bits that you do need. Can you give examples of things that you do need from the Linaro tree?
Basically, everything in arch/arm/kernel, arch/arm/mm, etc. Right now the diff is mostly to do with device tree, which is interesting but not crucial. But the principle is that linux-linaro will have arm architecture support before mainline, no?
Yes, but you shouldn't base your work on linux-linaro, and instead on the topic branches that you care about -- basing your work on a history tree is going to lead to a path of tangled patches that will be much harder to upstream.
A manifest of the branches being included in linux-linaro will be available online shortly; I'm waiting for Andrey (copied here) to publish that.
[*] The complementary question is what /is/ linux-linaro for, if not to support new SoC bringup. The answer is that it's there to allow people to test cutting edge kernel work on Linaro member platforms -- for instance, if you want to verify how well Device Tree support works on an i.MX53 Quickstart, or how well the latest eMMC 4.5 storage patches work on Exynos.
On Wednesday 04 April 2012, Chris Simmonds wrote:
On 04/04/12 11:53, Amit Kucheria wrote:
On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds chris.simmonds@2net.co.uk wrote:
Hello,
I am working on behalf of an SoC vendor and I am trying to work out which (if any) of the many git trees at http://git.linaro.org/gitweb we should
Is this a new SoC (no mainline support) or an existing SoC?
It's a new SoC which will have its own arch/arm/mach-xxx directory
In this case, the Linaro kernels don't help you. Just use the upstream kernel from Linus Torvalds directly, starting with v3.4-rc1. This has gained a lot of the new features that you need for new SoC work, including device tree bindings for a lot of subsystems, common clk framework and the pinctrl subsystem.
Make sure you pick the right templates for new work. For instance, the mach-highbank and mach-zynq platforms are good examples for how new platforms should be structured. Don't copy from the older ones, as we are currently in the process of rewriting most of them, which would result in you having to do the same changes as the common code changes. This should not be a hard thing to do, because the changes we make upstream are intended to make it easier and require less code to get a new platform supported and merged.
The 3.0 LTSI kernel is a bit problematic, because 3.0 predates most of the changes that are impacting your work, so it would not be possible to port bug fixes between 3.0-LTSI and upstream kernels. There will be a new LTSI kernel in the future, presumably based on v3.4, and I would strongly recommend starting with that for a new SoC platform because most of the large scale infrastructure changes have already made it into that version, so it will remain more or less compatible for a far longer time. If you have current users on 3.0 or older private kernel versions, it makes sense to keep them on that platform until 3.4 has stabilized enough, but there is no point in trying hard to make code portable between the two versions -- you should just consider 3.0 as a dead end and move all products away from that in the mid-term.
If you need help in getting the new mach-xxx directory right, feel free to send me a git URL or a patch against a kernel release for review (ideally on-list with me on Cc, but private mail is ok if you require confidentiality), so I can tell you which parts you need to change in order to get long term maintainability and get your code merged upstream in a timely manner.
Arnd
-
Amit Kucheria -
Arnd Bergmann -
Chris Simmonds -
Christian Robottom Reis -
Deepak Saxena