Re: devicetree repository separation/migration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, Feb 18, 2014 at 11:47:56AM -0800, Olof Johansson wrote:
> On Tue, Feb 18, 2014 at 10:18 AM, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote:
> > On Tue, Feb 18, 2014 at 04:57:50PM +0100, Sascha Hauer wrote:
> >> On Mon, Feb 17, 2014 at 01:05:44PM -0500, Jason Cooper wrote:
> > ...
> >> >   - Is the Linux development workflow ready for devicetree to move out
> >> >     of the Linux Kernel?
> >>
> >> I hope so since keeping the devicetrees in sync with the kernel is a
> >> pain for all external users.
> >
> > Well, I haven't heard any screams yet.  I suspect people are waiting for
> > details on the exact form it would take before complaining...
> 
> I'M SCREAMING NOW. :-)
> 
> Honestly though, I think we need to do this carefully. Even though we
> don't like it, there are still lots of bindings in flux and
> cross-dependencies between two independent repos will be a major pain.
> 
> I think we have two options:
> 
> 1. Bring out everything in the current kernel repo to a separate one,
> but do it my mirroring over. Changes go into the kernel repo first and
> then comes over to this one, but other projects can mirror the
> standalone repo without downloading a whole kernel tree.
> 
> 2. Remove the kernel contents and move it over to the new repo. This
> should be done independently for each platform, and the maintainers
> get to decide if, when and how they do it. Some platforms are ready
> for it (some have been for a long time), others are not. And it's up
> to the maintainer, since they are the ones we will yell at when they
> make our life miserable by adding cross-dependencies with an external
> repo. Breakage due to the move is something we should have to put up
> with, etc.

Doing the move on a SoC/Maintainer basis is a good idea. I think the
move only makes sense for SoCs where the basic infrastructure devices
which are used by other devices are ironed out, namely interrupts,
GPIOs, DMA channels, pinctrl. As long as these are not present in a
devicetree it won't be usable by future kernels.

For i.MX I made the experience that the builtin barebox devicetree very
often is enough for my usecases so that I just throw a
imx_v6_v7_defcfonfig kernel to the board and don't have to think about
devicetrees anymore (This comes to an abrupt end when graphics is involved
though)

Sascha

-- 
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 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux