From: Nishanth Menon <nm@ti.com>
To: Roger Quadros <rogerq@ti.com>, Keerthy <j-keerthy@ti.com>,
Jyri Sarha <jsarha@ti.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Lokesh Vutla <lokeshvutla@ti.com>,
Rob Herring <robh+dt@kernel.org>,
Tony Lindgren <tony@atomide.com>, Tero Kristo <t-kristo@ti.com>
Cc: <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
Nishanth Menon <nm@ti.com>
Subject: [PATCH 0/4] arm64: dts: ti: Cleanup mix of "okay" and "disabled" usage
Date: Wed, 4 Nov 2020 16:43:52 -0600 [thread overview]
Message-ID: <20201104224356.18040-1-nm@ti.com> (raw)
Hi,
This is hopefully a conclusion of the thread we had (online[1] and
offline). There are few options one could take when dealing with SoC
dtsi and board dts:
a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
to prevent messy board files, when more boards are added per SoC, we
optimize and disable commonly un-used nodes in board-common.dtsi
b. SoC dtsi disables all hardware dependent nodes by default and board
dts files enable nodes based on a need basis.
c. Subjectively pick and choose which nodes we will disable by default
in SoC dtsi and over the years we can optimize things and change
default state depending on the need.
What we have today is a bit of a mix of seemingly random set of
choices, however, predominantly following (a) and a few intermittent
cases of (b) and (c). While there are pros and cons on each of these
approaches, the right thing to do will be to stick with device tree
default (aka device tree standards) and work within those established
rules. So, lets cleanup and follow what the vast majority of SoC
platforms are doing and which also happens to be the path of least churn
for TI dts nodes as well.
Functionally the dtb output is same ->
a) As of v5.10-rc1:
am654: https://pastebin.ubuntu.com/p/G4P5vghpV3/
j7200: https://pastebin.ubuntu.com/p/SsG6JtPzR9/
j721e: https://pastebin.ubuntu.com/p/HWXmTwD6m8/
b) with this series applied:
am654: https://pastebin.ubuntu.com/p/h7MmHPQpRx/
j7200: https://pastebin.ubuntu.com/p/VXjQHhQNgn/
j721e: https://pastebin.ubuntu.com/p/2JMgftd4Xx/
The actual diff between the two versions being: https://pastebin.ubuntu.com/p/4rwy5qRY84/
Which is equivalent as per device tree standards, but uses lesser
redundant strings.
Thanks Tony, for sticking to the guns and providing us clear guidance
on this topic.
[1] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/
Nishanth Menon (4):
arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level
arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level
arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay"
for crypto
arm64: dts: ti: k3-am654-base-board: Fix up un-necessary status set to
"okay" for USB
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 9 ----
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 24 ++++++----
.../dts/ti/k3-j721e-common-proc-board.dts | 48 ++++++++++++++++++-
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 28 -----------
4 files changed, 63 insertions(+), 46 deletions(-)
--
2.29.2
next reply other threads:[~2020-11-04 22:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 22:43 Nishanth Menon [this message]
2020-11-04 22:43 ` [PATCH 1/4] arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level Nishanth Menon
2020-11-05 7:25 ` Tomi Valkeinen
2020-11-04 22:43 ` [PATCH 2/4] arm64: dts: ti: k3-j721e*: " Nishanth Menon
2020-11-05 7:25 ` Tomi Valkeinen
2020-11-05 7:32 ` Peter Ujfalusi
2020-11-05 14:08 ` Nishanth Menon
2020-11-06 11:32 ` Peter Ujfalusi
2020-11-06 21:46 ` Nishanth Menon
2020-11-09 7:49 ` Peter Ujfalusi
2020-11-04 22:43 ` [PATCH 3/4] arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay" for crypto Nishanth Menon
2020-11-04 22:43 ` [PATCH 4/4] arm64: dts: ti: k3-am654-base-board: Fix up un-necessary status set to "okay" for USB Nishanth Menon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201104224356.18040-1-nm@ti.com \
--to=nm@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=j-keerthy@ti.com \
--cc=jsarha@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=robh+dt@kernel.org \
--cc=rogerq@ti.com \
--cc=t-kristo@ti.com \
--cc=tomi.valkeinen@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).