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 09C6DC3271E for ; Fri, 5 Jul 2024 16:35:00 +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:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7+MmV/AK8xd7ornr1O1boj8x2ZOEG1OgD7+3rx0WBvw=; b=Jv7V9JTL5PwGLYuJNqSvmPlgkY 8zlIl43D2uCVPovWeN9SgacKNTMrNZSiHI5pm/WGebYp/6azV1cqt+5h7d9YJzLGFGWazLMuM3GE1 /fGGKTiQxWOJ6yRRf2KuZxBF3iCijj8y+me6ZdBOqWNRm0nVe9eKbrQYrksCuqpMaIHc4LRQo2p1F TZ+0U0pZMVS/ndyVouTf5gOFGNkPFBIpJBh/baC5Xie3vJLtUSnGZDcoWJVEx8oFoNzKpHOX3BwVM mlorwBtFsK098kXq7mz8W5c/ZC3q8ckTXSiPb6PfFh7yWIVs6LHPQh5PeZR0PDiuoRbPBLXziu7eS 88s00A+A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sPltZ-0000000GQhi-0JEJ; Fri, 05 Jul 2024 16:34:49 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sPltK-0000000GQg9-0qQJ for linux-arm-kernel@lists.infradead.org; Fri, 05 Jul 2024 16:34:36 +0000 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 465GYGWS001066; Fri, 5 Jul 2024 11:34:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1720197256; bh=7+MmV/AK8xd7ornr1O1boj8x2ZOEG1OgD7+3rx0WBvw=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=VPRVRd2Orwe1QVlKfndwfJXqrfg3VIHYD3xqJBgoEL32CsuuqwwvtdVP1wt/eu9lp VM7PI+iGfTojK3ogCpW3gpQdPONUQ+Q6qZQSHuS1kUplInk3OhHK0mGGMHb5jK1CiI 9SZIxtOjrzkZRpQEkPsN2pYhF7bA0hY6ASWF04VU= Received: from DFLE109.ent.ti.com (dfle109.ent.ti.com [10.64.6.30]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 465GYGjw129475 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Jul 2024 11:34:16 -0500 Received: from DFLE103.ent.ti.com (10.64.6.24) by DFLE109.ent.ti.com (10.64.6.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Fri, 5 Jul 2024 11:34:15 -0500 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Fri, 5 Jul 2024 11:34:15 -0500 Received: from [10.249.42.149] ([10.249.42.149]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 465GYEiY090112; Fri, 5 Jul 2024 11:34:14 -0500 Message-ID: Date: Fri, 5 Jul 2024 11:34:14 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 7/7] dts: ti: k3-am625-beagleplay: Add mikroBUS To: Geert Uytterhoeven , Michael Walle CC: Ayush Singh , Mark Brown , Vaishnav M A , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Derek Kiernan , Dragan Cvetic , Arnd Bergmann , Greg Kroah-Hartman , Nishanth Menon , Vignesh Raghavendra , Tero Kristo , Andrew Lunn , , , , , , References: <20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org> <20240627-mikrobus-scratch-spi-v5-7-9e6c148bf5f0@beagleboard.org> <4e23ec81-b278-4f2b-815d-64ed9390ca55@ti.com> <5b2cd46e-8a51-f145-8876-55b12a6d62d1@linux-m68k.org> Content-Language: en-US From: Andrew Davis In-Reply-To: <5b2cd46e-8a51-f145-8876-55b12a6d62d1@linux-m68k.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit 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-20240705_093434_597622_39505719 X-CRM114-Status: GOOD ( 29.21 ) 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 On 7/5/24 3:01 AM, Geert Uytterhoeven wrote: >     Hi Michael, > > On Thu, 27 Jun 2024, Michael Walle wrote: >> On Thu Jun 27, 2024 at 7:07 PM CEST, Andrew Davis wrote: >>>> +    mikrobus_boards { >>>> +        thermo_click: thermo-click { >>>> +            compatible = "maxim,max31855k", "mikrobus-spi"; >>> >>> I might be missing something, but your solution cannot possibly be >>> to list every click board that could be connected (all 1500+ of them) >>> to every mikroBUS connector on every device's DT file.. >>> >>> Each click board should have a single DTSO overlay file to describe the >>> click board, one per click board total. And then that overlay should >>> apply cleanly to any device that has a mikroBUS interface. >>> >>> Which means you have not completely solved the fundamental problem of >>> abstracting the mikroBUS connector in DT. Each of these click device child >>> nodes has to be under the parent connector node. Which means a phandle >>> to the parent node, which is not generically named. For instance >>> if my board has 2 connectors, I would have mikrobus0 and mikrobus1, >>> the click board's overlay would look like this: >>> >>> /dts-v1/; >>> /plugin/; >>> >>> &mikrobus0 { > > Let's use just "&mikrobus" instead... > >>>     status = "okay"; >>> >>>     mikrobus_board { >>>         thermo-click { >>>             compatible = "maxim,max31855k", "mikrobus-spi"; >>>             spi-max-frequency = <1000000>; >>>             pinctrl-apply = "spi_default"; >>>         }; >>>     }; >>> }; >> >> If there should only be one DT overlay per click board, how would >> you apply that to to different connectors? > > You teach fdtoverlay[*] to translate anchors, e.g. > >     fdtoverlay -i base.dtb -o final.dtb \ >            -t mikrobus=mikrobus0 click1.dtbo \ >            -t mikrobus=mikrobus1 click2.dtbo > This basic idea is where I started also, the result is we end up needing a huge number of "anchor" points. And they would also be board specific. So we would want to store all these anchor points in a file, and what better file than another DT file. Putting all the translations in a DT file to allow the DT overlay to become generic is the core idea of this series[0] (looks like you already found it, linking for other following along). And as you note, the symbol table trick allows us to do this without teaching fdtoverlay anything new, so it should work as-is today for any project already supporting overlays. > I believe the Raspberry Pi people already have something like that. > > The mikrobus node handles all other translations (e.g. mapping from > Mikrobus pins to GPIO numbers), so you do not have to handle these > explicitly when adding an overlay. This part seems to still be an open item. For pinmux we can name the pinmux nodes such that their phandles are resolved on overlay application. For Pin number/name to GPIO number we have "gpio-names", and the names can also be generic. But for Interrupts and a couple others, we are still missing a good way to provide a generic mapping from pin name to number. Andrew [0] https://lore.kernel.org/linux-arm-kernel/20240702164403.29067-1-afd@ti.com/ > > [*] And anything else that handles overlays (U-Boot, out-of-tree >     OF_CONFIGFS, ...) > > Gr{oetje,eeting}s, > >                         Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. >                                 -- Linus Torvalds