From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B885C433E0 for ; Thu, 21 Jan 2021 18:15:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4132623A57 for ; Thu, 21 Jan 2021 18:15:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4132623A57 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oJ+P5dq6N2yYu/QxPEudgmi9Og3AeHf4HbSxpfn48U8=; b=RF1QHIFLRbx9BvGhdeHTu9ken YlYNlOLjIaiXkfqmvxM/kQGB2n3Mf/asEAFnN1YAGTyMd1pWzmzfcKx55jBXDY/ka1KnI4eKRq4Sk gDx3gEFaDf5IilYFB99DwnHK4KHlpCF2dOYnEImwy8V38qz7gh/M15FgWOMh6kVRz6ypK7XysjAcE P5T4ZCrnuiVmxEbdlUx4P5basqcbaVnjq5ebQLq2mkUNVK9qr46Wi+k685U4REw/0XCHE5jewUCF2 qxAEtkCkgGwidXTLWdENzPf4qboWJzGbVbi2fFX+8HKKEkrvBXv3dxnA7yhWoToSUqU1IzMWQmR16 PaajCzq2A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2eT1-0000da-7j; Thu, 21 Jan 2021 18:13:59 +0000 Received: from fllv0016.ext.ti.com ([198.47.19.142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2eSx-0000d0-Rb for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 18:13:56 +0000 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 10LIDqDc054677; Thu, 21 Jan 2021 12:13:52 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1611252832; bh=SVoJMpFjcXZUAp3amM4tD1iVoWQhrYMVdaSU/VpM2Fc=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=Rhm6HSO70F+a7Cx6ARa9LaUc4HbDp4SpL9ch27UQDSVQZy2lxhjD/ohMqBBaNUqte soiMGSzs76r4C+kZ3ty1kLxnzyboozErbxuyx5RwVDE7K6mpQpJaeA//mU1WuKbKup p9KK/LCvBC+iamPdRQ062EYqfF+vmjf3BAhfAEag= Received: from DLEE104.ent.ti.com (dlee104.ent.ti.com [157.170.170.34]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 10LIDqGA072707 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 Jan 2021 12:13:52 -0600 Received: from DLEE100.ent.ti.com (157.170.170.30) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Thu, 21 Jan 2021 12:13:52 -0600 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE100.ent.ti.com (157.170.170.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Thu, 21 Jan 2021 12:13:51 -0600 Received: from [10.250.35.71] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 10LIDpST113912; Thu, 21 Jan 2021 12:13:51 -0600 Subject: Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC To: Nishanth Menon References: <20210120202532.9011-1-d-gerlach@ti.com> <20210120202532.9011-4-d-gerlach@ti.com> <197af185-d2ea-3c76-d0bf-714485f8f195@ti.com> <20210121174639.jqbvem6b4ozd3six@sterling> From: Suman Anna Message-ID: <4ee6f005-2eee-42b2-b573-e10602839e1b@ti.com> Date: Thu, 21 Jan 2021 12:13:46 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210121174639.jqbvem6b4ozd3six@sterling> Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_131356_032030_4E8F0661 X-CRM114-Status: GOOD ( 25.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Vignesh Raghavendra , Dave Gerlach , Tony Lindgren , Sekhar Nori , Kishon Vijay Abraham , Lokesh Vutla , Rob Herring , Aswath Govindraju , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1/21/21 11:46 AM, Nishanth Menon wrote: > On 11:25-20210121, Suman Anna wrote: >> On 1/20/21 2:25 PM, Dave Gerlach wrote: >>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform, >>> providing advanced system integration to enable applications such as >>> Motor Drives, PLC, Remote IO and IoT Gateways. >>> >>> Some highlights of this SoC are: >>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F >>> MCUs, and a single Cortex-M4F. >>> * Two Gigabit Industrial Communication Subsystems (ICSSG). >>> * Integrated Ethernet switch supporting up to a total of two external >>> ports. >>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory >>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other >>> peripherals. >>> * Centralized System Controller for Security, Power, and Resource >>> Management (DMSC). >>> >>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020) >>> for further details: https://www.ti.com/lit/pdf/spruim2 >>> >>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC >>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals >>> under cbass_main and the i2c, spi, and uart MCU domain periperhals >>> under cbass_mcu. >>> >>> Signed-off-by: Faiz Abbas >>> Signed-off-by: Aswath Govindraju >> >> Hmm, there are a few pieces contributed by me, so please do add >> >> Signed-off-by: Suman Anna > > Sure, thanks.. > > [...] > >>> + >>> + sdhci0: mmc@fa10000 { >>> + compatible = "ti,am64-sdhci-8bit"; >> >> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current >> ti-k3-dts-next. So, boot of these patches using this baseline fails when using >> MMC rootfs, but is ok when using initramfs. This particular compatible and the >> corresponding driver change are only in linux-next coming through couple of >> patches from the MMC subsystem. >> >> I am not sure why we would be including stuff that's dependent on some other >> patches being merged from a different sub-system? Strangely, this ought to be >> caught by dtbs_check, but it is not throwing any errors. >> >> IMHO, these should only be added if you have no other external dependencies >> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests >> would not go through arm-soc either. >> > > Yes, I am aware of this - this is no different from integration we have > done in the past as well.. intent is to get bindings in via subsystem > trees and dts changes via arm-soc. I always insist that basic ramdisk > boot always in the basic introduction tree. mmc, nfs are add-ons that > get added via subsystem tree and I host the dts changes - in this case > every dts node binding is fine with subsystems already queued in > linux-next. And this is no different from what I have noticed on other > ARM SoC maintainer trees as well. > Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the required driver functionality to have been in (or atleast the binding as per documentation), and not having to need to pick additional patches. If the intent is to verify/test everything against linux-next and not the baseline tree, then I guess this works. But in general, this kinda goes against the rules set in submitting patches. For example, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.rst#n44 And sure enough, this is what I get when I run checkpatch against your tree. WARNING: DT compatible string "ti,am64-sdhci-8bit" appears un-documented -- check ./Documentation/devicetree/bindings/ #347: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:298: + compatible = "ti,am64-sdhci-8bit"; WARNING: DT compatible string "ti,am64-sdhci-4bit" appears un-documented -- check ./Documentation/devicetree/bindings/ #365: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:316: + compatible = "ti,am64-sdhci-4bit"; regards Suman _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel