lkml.org 
[lkml]   [2020]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH V2 0/5] arm64: dts: ti: Cleanup mix of "okay" and "disabled" usage
    Date
    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

    \
     
     \ /
      Last update: 2020-11-12 06:33    [W:4.712 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site