Message-ID: <20190409114756.v6v33nsdtiitglee@flea>
Date:   Tue, 9 Apr 2019 13:47:56 +0200
From:   Maxime Ripard <maxime.ripard@...tlin.com>
To:     Jagan Teki <jagan@...rulasolutions.com>,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh+dt@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Mark Rutland <mark.rutland@....com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Jose Abreu <joabreu@...opsys.com>,
        "David S. Miller" <davem@...emloft.net>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        Wright Feng <wright.feng@...ress.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        Naveen Gupta <naveen.gupta@...ress.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
        linux-wireless@...r.kernel.org,
        brcm80211-dev-list.pdl@...adcom.com,
        brcm80211-dev-list@...ress.com, linux-gpio@...r.kernel.org
Subject: Re: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add
 Orange Pi 3 DTS

On Tue, Apr 09, 2019 at 01:31:57PM +0200, Ondřej Jirman wrote:
> Hi Jagan,
>
> On Tue, Apr 09, 2019 at 02:08:18PM +0530, Jagan Teki wrote:
> > Based on the conversation about using common dtsi from this thread[1],
> > I'm commenting here to make show the diff directly on the nodes,
> > giving comments on each node so-that we can see the diff globally.
>
> Thanks for the suggestions below. It mostly repeats the differences and
> commonalities I already stated in the previous discussion.
>
> I don't have much to add to what I already said previously, though, because you
> didn't address my concerns there. But I can restate and expand on those
> concerns.
>
> Previously I already agreed it's possible to base orangepi-3.dts on
> orangepi.dtsi, and proposed a maintainable way forward, and why to follow it (to
> quote myself):
>
>   Schematics allow for high amount of variability in the power tree (see all the
>   NC (not connected) / 0R resistors) in the schematic around AXP805. Every board
>   based on this Xunlong design can be subtly different.
>
>   I already suggested a maintainable solution, below. Where base dtsi has empty
>   config for regulators and every board based on that just defines it completely
>   for itself.
>
>   A few regulators (for CPU/GPU) will most probably have the same meaning on
>   every derived board, so these can probably be kept in dtsi without causing too
>   much annoyance.
>
>   It's unpleasant to have wrong regulator setup defined in an underlying dtsi,
>   and then trying to override it by removing/adding random properties in the
>   board dts for the new boards based on that, so that it fits.
>
>   The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can be
>   shared (as of now).
>
> My suggestion was this:
>
>   So to base Orange Pi 3 dts on top of existing sun50i-h6-orangepi.dtsi I'd have
>   to first move some things out of the base dtsi to the OrangePi Lite2 and One
>   Plus board dts files, in order to have sun50i-h6-orangepi.dtsi only describe
>   HW that is *really* shared by these 2 boards and Orange Pi 3.
>
>   If I do that, I'd undefine all the axp805 regulator nodes and move the
>   configurations to each of the 3 board files. That will probably end up being
>   the least confusing and most maintainable. See axp81x.dtsi lines 86-144 for
>   what I mean.
>
> You seem to be suggesting a solution where every time we add an OrangePi H6
> based board, the person adding it will have to go through the base dtsi and all
> the other boards based on it, status disable or otherwise change regulators in
> the base dtsi, patch all the other boards to re-enable it.
>
> It would be already unpleasant just adding a third board based on this approach.
> And when the fourth board is added, with another small differences in the
> regulator use/meanings, the person will be looking at patching 4 dts files
> + adding one for his own board. For what benefit, to save some bytes right now?
>
> I think maintainability, ease of adding new boards is more important, than
> having a dtsi that tries to maximally cover all the commonalities between the
> existing boards right now, without regards for the future. That's why
> I suggested an approach like in axp81x.dtsi lines 86-144.

I agree.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists