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.simmo...@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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
