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-arm-kernel@lists.infradead.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Nishanth Menon <nm@ti.com>
Subject: [PATCH V2 0/5] arm64: dts: ti: Cleanup mix of "okay" and "disabled" usage
Date: Wed, 11 Nov 2020 19:49:24 -0600 [thread overview]
Message-ID: <20201112014929.25227-1-nm@ti.com> (raw)
Hi,
Changes since v1[1]:
- Picked up Reviews from Tomi
- Added patch #5 for moving uart used by firmware to 'reserved'
state (thanks Peter for pointing it out)
- Updated commit message of #1, #2 to add information about the
limitation as well (thanks Peter for your inputs).
This is hopefully a conclusion of the thread we had
(online[2] 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.
While there are pros and cons on each of these approaches, the right
thing to do will be to stick with device tree default standards and
work within those established rules. So, we choose to go with option
(a).
NOTE: There is a known risk of "omission" that new board dts
developers might miss reviewing both the board schematics in addition
to all the dt nodes of the SoC when setting appropriate nodes status
to "disable" or "reserved" in the board dts. This can expose issues in
drivers which may not anticipate an incomplete node(example: missing
appropriate board properties) being in "okay" state. These cases are
considered as bugs and need to be fixed in the drivers as and when
identified.
The dtb changes are limited to be functionaly equivalent similar to what
was published with v1.
dtb-> dts decompiled
a) As of v5.10-rc1:
am654: https://pastebin.ubuntu.com/p/G4P5vghpV3/
j721e: https://pastebin.ubuntu.com/p/HWXmTwD6m8/
j7200: https://pastebin.ubuntu.com/p/SsG6JtPzR9/
b) with this series applied:
am654: https://pastebin.ubuntu.com/p/pGdpbPQvyd/
j721e: https://pastebin.ubuntu.com/p/PWcNMdtj5J/
j7200: https://pastebin.ubuntu.com/p/NFxpNtyNr9/
Boot test logs(base v5.10-rc1):
am654: https://pastebin.ubuntu.com/p/pNngXcWy23/
j721e: https://pastebin.ubuntu.com/p/xjbXkHb7Gv/
j7200: https://pastebin.ubuntu.com/p/dn7MgfJJ2j/
Nishanth Menon (5):
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
arm64: dts: ti: am65/j721e/j7200: Mark firmware used uart as
"reserved"
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 9 ----
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 26 ++++++----
.../dts/ti/k3-j7200-common-proc-board.dts | 4 +-
.../dts/ti/k3-j721e-common-proc-board.dts | 50 ++++++++++++++++++-
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 28 -----------
5 files changed, 67 insertions(+), 50 deletions(-)
[1] https://lore.kernel.org/linux-arm-kernel/20201104224356.18040-1-nm@ti.com/
[2] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/
--
2.29.2
next reply other threads:[~2020-11-12 5:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 1:49 Nishanth Menon [this message]
2020-11-12 1:49 ` [PATCH V2 1/5] arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level Nishanth Menon
2020-11-12 14:17 ` Tony Lindgren
2020-11-12 14:18 ` Tony Lindgren
2020-11-12 1:49 ` [PATCH V2 2/5] arm64: dts: ti: k3-j721e*: " Nishanth Menon
2020-11-12 14:19 ` Tony Lindgren
2020-11-12 1:49 ` [PATCH V2 3/5] arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay" for crypto Nishanth Menon
2020-11-12 13:34 ` Tero Kristo
2020-11-12 14:19 ` Tony Lindgren
2020-11-12 1:49 ` [PATCH V2 4/5] arm64: dts: ti: k3-am654-base-board: Fix up un-necessary status set to "okay" for USB Nishanth Menon
2020-11-12 13:01 ` Roger Quadros
2020-11-12 14:19 ` Tony Lindgren
2020-11-12 1:49 ` [PATCH V2 5/5] arm64: dts: ti: am65/j721e/j7200: Mark firmware used uart as "reserved" Nishanth Menon
2020-11-12 14:24 ` Tony Lindgren
2020-11-12 15:56 ` Vignesh Raghavendra
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=20201112014929.25227-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