Re: [PATCH v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

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

 



Hi Rob,

On Tue, Jan 16, 2018 at 4:08 PM, Rob Herring <robh@xxxxxxxxxx> wrote:
> On Tue, Jan 16, 2018 at 2:56 AM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
>> On Mon, Jan 15, 2018 at 7:01 PM, Laurent Pinchart
>> <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
>>> On Monday, 15 January 2018 19:09:53 EET Rob Herring wrote:
>>>> On Fri, Jan 12, 2018 at 5:14 PM, Laurent Pinchart wrote:
>>>> > The internal LVDS encoders now have their own DT bindings. Before
>>>> > switching the driver infrastructure to those new bindings, implement
>>>> > backward-compatibility through live DT patching.
>>>>
>>>> Uhh, we just got rid of TI's patching and now adding this one. I guess
>>>> it's necessary, but I'd like to know how long we need to keep this?
>>>
>>> That's a good question. How long are we supposed to keep DT backward
>>> compatibility for ? I don't think there's a one-size-fits-them-all answer to
>>> this question. Geert, any opinion ? How long do you plan to keep the CPG
>>> (clocks) DT backward compatibility for instance ?
>>
>> Good question indeed...
>>
>> It's not just CPG/MSSR. Over the years we also added or changed APMU (SMP),
>> SYSC (power domains), RST (mode pins), CMT (timers), ..., all of which have
>> some sort of compatibility support in the kernel.
>>
>> Hence to avoid having to remember the kernel versions that dropped backwards
>> compatibility for each of the above components, I was thinking about an
>> R-Car Gen2 DT Flag Day.
>
> There's probably also DT changes that enable new features folks would
> want/need? Or maybe carrying for some number of LTS releases is
> enough.

Sure. If you want new features, you have to upgrade the DTB anyway.
Backwards compatibility is about keeping features without updating DTB.

>> However, that was before I learned about your plans for LVDS (it seems every
>> kernel release we learn about something new, postponing the flag day ;-).
>> And now I'm quite sure we'll have another change in the future (DU per
>> channel device nodes)...
>>
>> About using DT fixups to implement backwards compatibility: I did my share
>> of thinking and experimenting with DT fixups (see e.g. "[PATCH/RFC 0/1]
>> soc: renesas: Add DT fixup code for backwards compatibility"
>> (https://www.spinics.net/lists/linux-renesas-soc/msg04305.html).
>> DT fixups are hard to implement right, and not everything can be done
>> that way.  Hence in the end, none of this was ever used upstream, and
>> everything was handled in C...
>
> In an ideal world, we would have some tool:
>
> dt-diff-to-overlay old.dts new.dts > my-fixup-overlay.dts
>
> And then in the kernel have infrastructure such you just declare match
> tables with overlays to apply:
>
> struct of_device_id dt_match[] = {
>   {
>     .compatible = "vendor,board",
>   },
>   {},
> };
> DT_FIXUP(dt_match, my-fixup-overlay.dtbo);
>
> But maybe I'm dreaming...

Really?

We might as well include the latest DTB in the kernel, and use that if
machine_is_compatible("vendor,board")? ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux