Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp2574225rdb; Fri, 22 Sep 2023 02:40:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGY+ys5ONZBB9fSddI7GprM+sqgP94Bzw1EVJi15hIemsLFzWxwAbnePPPVBCwXE2/i9mw0 X-Received: by 2002:a05:6300:8089:b0:149:602e:9233 with SMTP id ap9-20020a056300808900b00149602e9233mr8232833pzc.26.1695375612138; Fri, 22 Sep 2023 02:40:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695375612; cv=none; d=google.com; s=arc-20160816; b=gdCaRAwRi0MvMA7Pd8MsuOy6FKfQ2S93yhpaG9849YrwXyQbpeaMfEGc8ZoOcPapWS Sc+EvdPLLtx+YLU3wvMkHli20iRCEtQuGcbXL5JYOxl04sl6FjYl/cTAGrZm7UDgFLTD zJv18GWHwgFVWvwOW/c6AbjLOlxNe+wIHF4AOGBUxkNSzCOhGDit7+Cu3HzFJ/jFDATc adpyCycSa4YAFDyzhKmX7JeKnaGtYO1OM8P50KtbhZfF4h7qFAOGHgazZ7R/FsXyqhbv d2MSCTixB2L6BfrXZm/zfryt9KDQKZ/go50jp+Y64fQonlpUq1dDitLtXNUhBCv+nmif QTAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=7JJdxlSGtQMNCkQwUO7ztV28PB8zgOeq4LxcMxTLhC4=; fh=Xl2tamT2kh78tkAu05ozRwxVd651+pYwyI17GJjf3DY=; b=uLXiLCekTwvWAh5cZUpIaRVYTDW54c3211KuzGhlndrGufY3xh/YRqFwHSlmbP9X0g npab83BB+Dl7O3aTN0U0gwg5ifjTINGM7d9u3EdO92oZ0DzmSJkAkxS9xfah3AvXUV5W Yd5TLcWjYYBHUPDOya2Kh4Xo0FuyDImRn63QMfg3IZ79+MVLH2GMtztJUt9L1Fsel0hm CpMxAcxOFwc9hZy80Te7v47lNzCeUZGDtS7AI0GZqX77xF8AhmXIcwZfFLYQRlXw/eDM 0r8Y6I4zLX+fczz0urBp7HMJk2NXnuhpDnPXl4AYlPXOZ6+HQZSmiWsl0q6tW04LJCqU HtQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BsUFrPIA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id l5-20020a170903120500b001b84335fb90si3621845plh.286.2023.09.22.02.40.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 02:40:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BsUFrPIA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 74DD8832A00E; Fri, 22 Sep 2023 02:03:41 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232543AbjIVJDg (ORCPT + 99 others); Fri, 22 Sep 2023 05:03:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbjIVJDf (ORCPT ); Fri, 22 Sep 2023 05:03:35 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4459399 for ; Fri, 22 Sep 2023 02:03:29 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18462C433C7; Fri, 22 Sep 2023 09:03:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695373408; bh=VxDh6zlUkPlWGqASD5pZQ2AZHV1SUFg3JBNsX74h6z0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BsUFrPIAY1OS1Zfdp8N3eq0cRMTskTJVk/XIo9c+h0Ccn+PHuhFmWxlFmglMYVHsL 2QQgtK9xlJf6zT6sZNVbzntL/2r2iCHufg+F2LcP+pGBEISHxpaqmQcjhDpUx/6wGT wvGrd/8tOJy0QSyi3cvZ4bPPNEq9P7yr4rWEHg5grSxcvoauZDeDbjLfzt7hqGCkhb sWVvbByGw3Bya/UHZRS0XC4rZedzy74ivqV7GezYNNFyTp63WY4a0K7Fu/s5Ur6Ts4 EFaN3HTh6dVNWtOrFFaNW6ZASn68UaL9zzMwjelyc0285pBkFx6PDibfcZoSp2DjJQ IU7E7zp/xFVUQ== Message-ID: <3eef2d49-d13e-40cf-a633-94b52948b065@kernel.org> Date: Fri, 22 Sep 2023 12:03:23 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] arm64: dts: ti: am642-evm: Add overlay for NAND expansion card To: Andrew Davis , Nishanth Menon , Tony Lindgren , Rob Herring , david@gibson.dropbear.id.au Cc: vigneshr@ti.com, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, srk@ti.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Siddharth Vadapalli References: <20230920133450.54226-1-rogerq@kernel.org> <20230920133450.54226-3-rogerq@kernel.org> <20230920135802.3ej2wcuaruqjidel@uncouth> <20230920164424.rrjvm6nvtv4ysyrw@unreal> <6f2b38f8-1962-46f2-a095-b1eaf99ed407@kernel.org> Content-Language: en-US From: Roger Quadros In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 22 Sep 2023 02:03:41 -0700 (PDT) On 21/09/2023 20:23, Andrew Davis wrote: > On 9/21/23 6:37 AM, Roger Quadros wrote: >> On 20/09/2023 20:06, Andrew Davis wrote: >>> On 9/20/23 11:44 AM, Nishanth Menon wrote: >>>> On 18:18-20230920, Roger Quadros wrote: >>>>> >>>>> >>>>> On 20/09/2023 16:58, Nishanth Menon wrote: >>>>>> On 16:34-20230920, Roger Quadros wrote: >>>>>>> The NAND expansion card plugs in over the HSE (High Speed Expansion) >>>>>>> connector. Add support for it. >>>>>>> >>>>>>> Signed-off-by: Roger Quadros >>>>>>> --- >>>>>>>    arch/arm64/boot/dts/ti/Makefile               |   1 + >>>>>>>    arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso | 140 ++++++++++++++++++ >>>>>>>    2 files changed, 141 insertions(+) >>>>>>>    create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso >>>>>>> >>>>>>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile >>>>>>> index 06d6f264f292..ece74085a6be 100644 >>>>>>> --- a/arch/arm64/boot/dts/ti/Makefile >>>>>>> +++ b/arch/arm64/boot/dts/ti/Makefile >>>>>>> @@ -29,6 +29,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62p5-sk.dtb >>>>>>>      # Boards with AM64x SoC >>>>>>>    dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb >>>>>>> +dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-nand.dtbo >>>>>>>    dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb >>>>>>>    dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb >>>>>>>    dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb >>>>>> >>>>>> Also see https://lore.kernel.org/all/20230911165610.GA1362932-robh@kernel.org/ >>>>>> >>>>>> you may not get the dtbo installed when doing make dtbs_install >>>>>> >>>>>> [...] >>>>>> >>>>> >>>>> $ v8make dtbs_install INSTALL_DTBS_PATH=/tmp >>>>>     INSTALL /tmp/ti/k3-am625-beagleplay.dtb >>>>>     INSTALL /tmp/ti/k3-am625-phyboard-lyra-rdk.dtb >>>>>     INSTALL /tmp/ti/k3-am625-sk.dtb >>>>>     INSTALL /tmp/ti/k3-am625-verdin-nonwifi-dahlia.dtb >>>>>     INSTALL /tmp/ti/k3-am625-verdin-nonwifi-dev.dtb >>>>>     INSTALL /tmp/ti/k3-am625-verdin-nonwifi-yavia.dtb >>>>>     INSTALL /tmp/ti/k3-am625-verdin-wifi-dahlia.dtb >>>>>     INSTALL /tmp/ti/k3-am625-verdin-wifi-dev.dtb >>>>>     INSTALL /tmp/ti/k3-am625-verdin-wifi-yavia.dtb >>>>>     INSTALL /tmp/ti/k3-am62-lp-sk.dtb >>>>>     INSTALL /tmp/ti/k3-am62x-sk-hdmi-audio.dtbo >>>>>     INSTALL /tmp/ti/k3-am62a7-sk.dtb >>>>>     INSTALL /tmp/ti/k3-am62p5-sk.dtb >>>>>     INSTALL /tmp/ti/k3-am642-evm.dtb >>>>>     INSTALL /tmp/ti/k3-am642-evm-nand.dtbo >>>>> ^^^^ >>>>>     INSTALL /tmp/ti/k3-am642-phyboard-electra-rdk.dtb >>>>>     INSTALL /tmp/ti/k3-am642-sk.dtb >>>>> >>>>> >>>>> What did I miss? >>>> >>>> I missed it, actually. See Rob's comment: >>>> https://lore.kernel.org/all/CAL_Jsq+GR3hP6hFvFn2z5aXvSXnh9butD3aKZ-y_XJgx0_YPTw@mail.gmail.com/ >>>> >>>> Having orphan dtbo is apparently frowned upon >>>> >>> >>> And if you apply these overlays to the base DTB then it gets >>> symbols added automatically, no need for your patch [1/2] here. >>> >> >> Is this OK? >> >>     k3-am642-evm-nand-dtbs := k3-am642-evm.dtb k3-am642-evm-nand.dtbo >>     dtb-$(CONFIG_ARCH_K3) += k3-am642-evm-nand.dtb >> >> So patch 1 is not required in this case but we have an >> extra dtb file which is not really required. >> > > While I agree we will end up with several pre-overlayed DTB files > that are arguably not required as they could be later built/applied, > until we find a better way to check at build time these overlays > need applied to something as a test. > >> I have 2 more issues to point out >> >> 1) >> With existing examples e.g. J7200 EVM >> wouldn't  k3-j7200-evm.dtb include the k3-j7200-evm-quad-port-eth-exp.dtbo? >> Is this what we really want? >> >> likewise for k3-j721e-evm.dtb and k3-am654-gp-evm.dtb >> > > Yes, that is the idea, the base-board.dtb is just the raw main board, but > the "EVM" when you buy it comes with the quad-port daughtercard attached. > That is what we consider the "EVM" and the DTB names match that. > >> 2) >> Another issue (unrelated to this change) is the below warning: >> >>     arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso:65.8-140.3: Warning (avoid_default_addr_size): /fragment@3/__overlay__: Relying on default #address-cells value >>     arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtso:65.8-140.3: Warning (avoid_default_addr_size): /fragment@3/__overlay__: Relying on default #size-cells value >> >> This is because we use the 'ranges' property in the gpmc0 node >> and the compiler doesn't know the #address/size-cells of the >> parent node. >> >> Is there a trick to specify it in the dtso file? >> > > Hmm, seems like a tricky one. Do you really need to do the ranges here? > Could you use the default `ranges;` for gpmc0? Then do the range translation > down inside the nand node to keep the partition addresses sane. GPMC has separate address spaces per chip select. From Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml ranges: minItems: 1 description: | Must be set up to reflect the memory layout with four integer values for each chip-select line in use, 0 The ranges location in the device tree overlay is correct. The overlay is meaningless without the base tree. The correct solution would be to fix dtc so it doesn't print this warning for DT overlays. i.e. diff --git a/scripts/dtc/checks.c b/scripts/dtc/checks.c index 9f31d2607182..dcb0a6f6f3fb 100644 --- a/scripts/dtc/checks.c +++ b/scripts/dtc/checks.c @@ -1203,6 +1203,9 @@ static void check_avoid_default_addr_size(struct check *c, struct dt_info *dti, if (!reg && !ranges) return; + if (streq(node->name, "__overlay__")) + return; + if (node->parent->addr_cells == -1) FAIL(c, dti, node, "Relying on default #address-cells value"); -- cheers, -roger