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