Re: Device Tree Evolution Project - call notes - 29th January

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




On 2/11/20 4:53 PM, Rob Herring wrote:
> On Tue, Feb 11, 2020 at 11:44 AM Francois Ozog <francois.ozog@xxxxxxxxxx> 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.
>>>

ACK on that.  Lots of good points raised in this thread. (I guess I
should not have recycled the subject line :)

I promised to publish so this is what we have so far:
https://github.com/wmamills/dt-overlays

Bill

>>> 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.
> 
> Certainly, I don't think I said anything that would prevent that. In
> that case, I would assume the board is not already upstream and
> there's not any backwards compatibility (ABI) to worry about. I'm only
> talking about cases where the split is changed such that we go from a
> monolithic dtb to a base dtb plus 1 or more overlay dtbs. IOW, we
> can't just change the split because that is an ABI. We still need to
> build and provide that original single dtb. There may be exceptions to
> that, but by default I have to care about backwards compatibility (and
> overlays add a new dimension to that). I suppose we could decide that
> a collection of base and overlay DTs are a monolithic unit and there
> is no ABI between them. However, we'd need to define some way to
> distinguish both cases. It's plausible that you'd want to do both on
> the same platform (base and overlay dtbs from the board vendor and 3rd
> party overlays).
> 
> Besides the above reason, there is something much more basic. We need
> build time assembly of base plus overlays just to validate overlays
> apply successfully. We don't want the only way to check an overlay
> applies is by booting the specific board that works with a given base
> and overlay dtb. Whether overlays apply or not is just the first step
> in validation. There's all the schema validation to do which is going
> to have its own issues.
> 
> Rob
> 



[Index of Archives]     [Device Tree]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]

  Powered by Linux