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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 835B0C3DA42 for ; Wed, 10 Jul 2024 07:38:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=m+7eG5SulmxARql1rXta82f53cuxh3ObNVc6xY7pOyY=; b=jx/1DDrEWOzM1Ol3VP/LkJZBCY u2aHZiCYCpCtrwQyhDKy0ABcrmwCEzaKeJQ2M8cyGIeMV+HQGXzHjkEE3Ee1sdCdTLU+aOS5Y9voe wx6VWr5iXEFt1WfZ70+Um0ZfKjxuSX5A7R+9CHcl7ed+BFrKcbYM5+5gKTEfBdbRj4MW3xMozXdCa 0GJFIhdtBHtPP+eAVUjkoh7HT7xsQ4+mJsjovchc0bYXPHEBRnN4wXggVMxAWsRsqrOW5YyNTnZnh U2ZqqRpOjd4jfvm79XEiVSABgVpHPUZYmNE8DwTSFRpS3bgQ03lCv/VhNMHOm3QVbX8IXLIcQDMK5 QZhLmqfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRRuU-00000009l0o-0Hdc; Wed, 10 Jul 2024 07:38:42 +0000 Received: from mail11.truemail.it ([2001:4b7e:0:8::81]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRRuB-00000009kvP-3cBu for linux-arm-kernel@lists.infradead.org; Wed, 10 Jul 2024 07:38:26 +0000 Received: from francesco-nb (93-49-2-63.ip317.fastwebnet.it [93.49.2.63]) by mail11.truemail.it (Postfix) with ESMTPA id 7953D1F931; Wed, 10 Jul 2024 09:38:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolcini.it; s=default; t=1720597096; bh=m+7eG5SulmxARql1rXta82f53cuxh3ObNVc6xY7pOyY=; h=From:To:Subject; b=SFwA4HJaPolOWR9dBffrEa5tMRLLCcpZt3iVkG82DkooGI/u95mV/+au4EhYWp+fQ deUzcuOcXxcT+Q7a8SuOyJ+xtcu8GbJlm+c7t0yw4Zwk4uKALEC42xNDurX0jbBm6n KITgPwHiSmQj4Acs8/lxu8JsOTqqIFaYKYpTS6OzF/ygHYO+KdwAqyfM/I+/1ybS5O grZGCvRHISntTHcEJqc1zzBgM6Eoa9pzT2fOxtqqYCczMnuUlgcRZqwpfS+s36MNvh C9FLuwZW9gMTjhGBfqqEO/wUpbVXEg2mwwgiqm4tOZK/xSc4OKaC2v5t65YbM/AWMJ A241MO+oBUp2Q== Date: Wed, 10 Jul 2024 09:38:11 +0200 From: Francesco Dolcini To: Logan Bristol Cc: Krzysztof Kozlowski , Bryan Brattlof , Nishanth Menon , Vignesh Raghavendra , Tero Kristo , Rob Herring , Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] arm64: dts: ti: introduce a minimal am642 device tree Message-ID: <20240710073811.GA4855@francesco-nb> References: <20220321155417.13267-1-bb@ti.com> <55e161d1-face-6958-1d86-8a85b82e8485@kernel.org> <766dceb1-222a-401b-95e3-69b7fb331411@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <766dceb1-222a-401b-95e3-69b7fb331411@ti.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240710_003824_966564_B85D9868 X-CRM114-Status: GOOD ( 21.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Logan On Tue, Jul 09, 2024 at 11:20:24AM -0500, Logan Bristol wrote: > On 3/22/22 13:14, Krzysztof Kozlowski wrote: > > On 21/03/2022 16:54, Bryan Brattlof wrote: > >> Texas Instrument's am642 is one of many k3 based, low cost, low power, > >> chips designed to work in a wide range of applications spanning an even > >> wider range of industries that TI is actively developing > >> > >> With its pin-mux and peripheral rich designs, these chips will likely > >> have a multitude of custom device trees that range wildly from one > >> another and (hopefully) guarantee an influx of variants into the kernel > >> in the coming years > >> > >> With overlays no longer a thing, I wanted to ask for opinions on how > >> we can best help integrate these dt files as they begin to be developed > >> > >> I also wanted to introduce a skeletonized (nothing but uart) device tree > >> to give others a good starting point while developing their projects. > > > > Real hardware as DTS please. There is no need to add some skeleton for > > specific SoC. What if every SoC goes that way? > > > > Feel free to create re-usable components in DTSI ways, still reflecting > > some hardware parts. > > > > I am working on a project for the AM62 and came across this email thread. > > Following Krzysztof's direction, I am wanting to submit a DTSI to serve > as a minimal configuration for the existing boards based on the AM62 > SoC, which are currently defined by bloated DTS files. > > This DTSI file can be consumed by other board DTS files to reduce the > configuration. Krzysztof, could this be merged upstream? Can you elaborate a little bit what you meant as bloated dts file? Why would you need different DTSI files compared to the existing one? Which problem are you trying to solve (make some example, be specific please). My experience with verdin am62 (k3-am62-verdin*dts*) was pretty smooth, I was just able to use the SOC dtsi file and use it to define my own board (and I had the same good experience with other SOC/Vendors). Francesco