On Tue, Feb 11, 2020 at 06:44:31PM +0100, Francois Ozog wrote: > On Tue, 11 Feb 2020 at 17:32, Rob Herring <robh@xxxxxxxxxx> wrote: > > > > On Mon, Feb 10, 2020 at 10:58 AM Mills, William <wmills@xxxxxx> wrote: > > > > > > Steve, > > > > > > Can TI get on the agenda for this week's meeting? > > > > > > We have a simple approach to make progress on boot loader applied overlays. > > > It is a small repo with just the overlays. > > > It builds the dtb's from the upstream kernel repo and the overlays from this repo. > > > We are going to do this at git.ti.com so we can make progress. > > > However we would like to suggest this as a simple way forward to collectively host things the kernel maintainers do not want in the kernel. > > > > For the record, I'm in favor of hosting overlays in the kernel (of > > course I have opinions on the details). Frank is not in favor IIRC, > > but Frank is only maintainer of 'drivers/of/' so ultimately not his > > decision. > > > > > Does it make sense to host something like this in devicetree.org github account? > > > > Yes, but I would like to see this coordinated with hosting > > 'devicetree-rebasing' there. We should be able to use the same > > makefiles from it. Perhaps the overlay repo should work as a git > > submodule of it as well. That would help keep things in sync. > > > > A concern I have is what happens when someone wants to split some > > portions of an existing dts into an overlay? Then the base dts becomes > > incomplete. Users will have regressions from missing functionality if > > they don't know to apply some overlay. And how do we track what base > > DTs overlays apply to? Not that we have a solution when they are in > > one tree, but 2 trees makes that harder. > > DT lifecycle shall be selectable by the board vendor. If, for any reason > (and there may be plenty), a vendor believes it is a better organization to > handle the DT assembly (static + overlays) outside the kernel, then it > should be possible to do so. > Note: On the ACPI front, a form of overlays (needed for DT too) will > be handled by U-Boot: > https://lists.denx.de/pipermail/u-boot/2020-January/397886.html I'll be on the next call as well, but I do want to caution against reading too much in to what we're doing to deal with x86 / ACPI and its different set of challenges. -- Tom
Attachment:
signature.asc
Description: PGP signature
