Search Linux Wireless

Re: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS

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

 



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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux