ST-Ericsson ux500 BSP contents
arnd at arndb.de
Wed Sep 29 18:06:20 BST 2010
On Wednesday 29 September 2010, Linus Walleij wrote:
> Nicolas Pitre wrote:
> > Indeed. And that's exactly what I'm looking for in order to produce the
> > linaro-next kernel tree. The linaro-next tree is discarded and rebuilt
> > from scratch by merging together a bunch of development trees on a
> > regular basis. I'd like to add your up-to-date tree to the lot.
> We currently don't have anything like a git,
> what we have is this patchstack against Rothwells next-tags:
> This consists of the patches we have considered to be
> in such a good shape that we have sent them off to the
> different mailing lists and subsystem maintainers.
> NB: this is on top of the stuff we already have pending
> in next, which is currently actually a lot.
> Right now we have ~49 patches pending in the latest next tag
> and ~27 patches in the additional patch stack (i.e. stuff
> under review).
> I'm rebasing this patch stack agains Rothwells tree at irregular
How many trees are there that have your patches in linux-next?
I'm guessing that we have some of them in linaro-next already,
so maybe we can add the others as well.
> Maybe I'm just not understanding some easy way out of cross-
> subsystem dependencies, but the way I'm experiencing it is
> that we have done the simple drivers already, the stuff we
> have left is all of the type where we must have some special
> header file for the driver platform data creating a cross-
> subsystem dependency to the ARM tree. Any incremental
> fixes once the driver is in are usually a breeze to merge
> and maintain.
Yes, this is a known problem with the way that devices are
handled on ARM. Normally the platform code wouldn't have to
known anything about the devices except for essential things
like the interrupt controllers.
What we need here is a generic way to find out what devices
are present other than encoding it into the platform.
The flattened device tree is one solution to this, but it
seems that it will take a long time before you can use it.
> We are making this even more elaborate by trying to push
> stuff like DMA into drivers/dma/* and GPIO expanders into
> drivers/gpio/* instead of just slamming all hairy cases
> into arch/arm/* like many platforms have done previously...
Yes, that is very good.
> Any hints on how to get out of this and create a simple
> git tree or set of trees is welcome, I have yet not found
I think you need to stop basing on top of linux-next and
move to basing on top of the smallest possible set of trees
other than mainline.
Today's series seems to apply almost cleanly on top of
Russell's ARM tree, so as a start, you can create one git
tree based on his and apply all your patches on top.
Since the base also in linaro-next, Nicolas can easily merge
it. If you have dependencies on other trees, say the MMC
tree, then split out the MMC related patches into a
separate series and apply them on the mmc-next tree,
and put them into a different branch in your git.
Create a master branch in your git than merges all the
separate branches for people to test out your code.
Things get a bit hairy if the tree you base on gets
rebased. Most maintainers do this very rarely, so you
should be fairly safe.
You can also have multiple branches based on Linus
Torvald's tree, e.g. for things like i2c or mtd that
do not depend on changes in Russell's or anyone else's
More information about the linaro-dev