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 AD94DC021A0 for ; Thu, 13 Feb 2025 21:12:22 +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:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/RrLWIXf4/dLUY89jPfVENxi4hWrbWl7h6YxyRzQyMU=; b=tZM9RxB1bqfnXler4FMsho8XSB MlHhKpFXu00qfvR+SXdHyNGuLEEZjgnEC4HsTQL8StUnmYQ/ZSt4PVQQiE5zXJULEaJ804QSVHax/ yrEp63ZtEYtB5if5v3QRM65KS/BMbIb0Uub/q+ItSXP5sR+OaSsuc/Y9KbjRSipfzWrNchjaYvo3W wdxMWzLdqTMFwfNmsUg51053cvCNHrYmunwCf8Z7XGPQ6xV0Zb/qwMEmf0W3cJBG4OoHcHsCSxNFw hg42q9JykfQ12o30huCWRhjQoq9M+4GkBj2DfnV1DY37O/vQvan2/5Ccf5WdnBQ/2+VxLPSJnsw1m gG1zZ2Lw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tigVJ-0000000CfMw-3nZR; Thu, 13 Feb 2025 21:12:14 +0000 Received: from relay2-d.mail.gandi.net ([2001:4b98:dc4:8::222]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tigQ2-0000000Ce7r-3E5r; Thu, 13 Feb 2025 21:06:48 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id A3A13440EA; Thu, 13 Feb 2025 21:06:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1739480803; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/RrLWIXf4/dLUY89jPfVENxi4hWrbWl7h6YxyRzQyMU=; b=QzZvmcPQo9X5fDpSORzylrRO/Q/OdB0KdxtS5BPna0CDfRfeO4Wsm9Em6qEc9Lqxbas9/L zeYiz+NCs899b+tGYydjQWKSCLTPXgE7lRZxrWU4oFUNMAMU2yISKhhpZJLxraJuminz1T V80xesALUQr4mrf3Dr7DP7AuOs3JqWZZ2Jyl7Oa8QVn8gN+v+rgYk/Lbxf25pVa6cZSDxf NriJJQkazv/OFlIY6jtqAXL0Giz8CVrTdr8Sv4AMd9Ly4+b1aqvZqo3gbVxt9uRjFbOPms SMhtt+LbP6q6Hmjy9rWzmMmN4UhujAfimZnjqrjJtmtU2OyoaSY0zy1u/kQ53A== Date: Thu, 13 Feb 2025 22:06:39 +0100 From: Herve Codina To: Phil Elwell Cc: Andrew Lunn , Andrea della Porta , Arnd Bergmann , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , bhelgaas@google.com, brgl@bgdev.pl, Catalin Marinas , Conor Dooley , derek.kiernan@amd.com, devicetree@vger.kernel.org, dragan.cvetic@amd.com, Florian Fainelli , Greg Kroah-Hartman , krzk+dt@kernel.org, kw@linux.com, Linus Walleij , linux-arm-kernel , linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org, LKML , "open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , lpieralisi@kernel.org, luca.ceresoli@bootlin.com, manivannan.sadhasivam@linaro.org, masahiroy@kernel.org, Michael Turquette , Rob Herring , saravanak@google.com, Stephen Boyd , thomas.petazzoni@bootlin.com, Stefan Wahren , Will Deacon , Dave Stevenson Subject: Re: [PATCH v6 00/10] Add support for RaspberryPi RP1 PCI device using a DT overlay Message-ID: <20250213220639.373da07b@bootlin.com> In-Reply-To: References: <20250213171435.1c2ce376@bootlin.com> <821d4c74-09b0-4c1b-b8ef-f8c08d0f6b5b@lunn.ch> <20250213195304.3a2df02c@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdegjeekudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkjghfohfogggtgfesthekredtredtjeenucfhrhhomhepjfgvrhhvvgcuvehoughinhgruceohhgvrhhvvgdrtghoughinhgrsegsohhothhlihhnrdgtohhmqeenucggtffrrghtthgvrhhnpeeviefffeegiedtleelieeghfejleeuueevkeevteegffehledtkeegudeigffgvdenucfkphepvdgrtddumegvtdgrmedvgeeimeejjeeltdemvdeitgegmegvvddvmeeitdefugemheekrgenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvrgdtudemvgdtrgemvdegieemjeejledtmedviegtgeemvgdvvdemiedtfegumeehkegrpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehhvghrvhgvrdgtohguihhnrgessghoohhtlhhinhdrtghomhdpnhgspghrtghpthhtohepfeehpdhrtghpthhtohepphhhihhlsehrrghsphgsvghrrhihphhirdgtohhmpdhrtghpthhtoheprghnughrvgifsehluhhnnhdrtghhpdhrtghpthhtoheprghnughrvggrrdhpohhrthgrsehsuhhsvgdrtghomhdprhgtphhtthhopegrrhhnugesrghrnhgusgdruggvpdhrtghpthhtoheps ggtmhdqkhgvrhhnvghlqdhfvggvuggsrggtkhdqlhhishhtsegsrhhorggutghomhdrtghomhdprhgtphhtthhopegshhgvlhhgrggrshesghhoohhglhgvrdgtohhmpdhrtghpthhtohepsghrghhlsegsghguvghvrdhplhdprhgtphhtthhopegtrghtrghlihhnrdhmrghrihhnrghssegrrhhmrdgtohhm X-GND-Sasl: herve.codina@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250213_130646_966654_8F68CA63 X-CRM114-Status: GOOD ( 38.84 ) 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 Hi Phil, On Thu, 13 Feb 2025 20:15:06 +0000 Phil Elwell wrote: > Once more, with plain text, which I'd hoped the Android GMail client > would work out for itself. > > On Thu, 13 Feb 2025, 18:53 Herve Codina, wrote: > > > > Hi Phil, > > > > On Thu, 13 Feb 2025 17:57:37 +0000 > > Phil Elwell wrote: > > > > > On Thu, 13 Feb 2025 at 17:45, Andrew Lunn wrote: > > > > > > > > > > Or do you mean a custom board, which has a CPU, RP1 and the button and > > > > > > fan are directly on this custom board? You then want a board DTS which > > > > > > includes all these pieces? > > > > > > > > > > That depends on whether you count the Raspberry Pi 5 as a custom board. > > > > > > > > So you mean the Pi 5 board would itself make use of the resources the > > > > RP1 device has? They are not simply connected to headers for plugin > > > > boards, but used by the main board? Hence you want to describe them in > > > > the board .DTS file. > > > > > > That's correct. But even for plug-in devices, those which are on > > > non-discoverable buses need overlays to declare them, which causes a > > > problem when the overlay application happens before the kernel is > > > started. > > > > > > > Hum, I see. > > > > We worked on overlay usage on non-discoverable buses wired to a connector > > and we did a talk about issues we are facing on at Plumber [0]. > > > > You can also find our big picture in [1] and a last contribution introducing > > export-symbols feature in [2]. export-symbols is also under discussion on > > some other threads. > > > > Also, we proposed the i2c bus extensions feature [3] whose goal is to allow > > an addon board to add devices on an i2c bus provided by a base board and > > wired to an connector the addon board is connected to. > > > > Maybe in your case, you can decouple resources (gpio, pwm) provided by the > > addon board and used by the base board using also nexus node. > > > > We use a nexus node [4] (not presented at the Plumbers talk because the idea > > came during 'out of talk' discussions in Plumbers) in order to allow our > > addon board to use resources provided by the base board. > > > > In your case, if I understood, you are in the other direction but why not > > using also a nexus node to decouple and translate resources in this other > > direction ? > > > > Don't know if this idea can help but feel free to ask for some more > > information if needed. > > Nexus nodes look interesting - I see them as adding a layer of > abstraction such that, for example, boards can declare which of their > specific resources performs a common function so that clients can > treat them all the same. We do the same thing in a limited way by > using common labels on nodes, but this goes much further. > > In the case of Pi 5 and RP1, I imagine you are proposing that the Pi 5 > dtb declares the connector node and the overlay fills in the content > with references to its GPIO controller, PWM controller etc. However, I > think the overlay would also have to be board specific because it's > not possible to patch part of a property from an overlay, so you'd end > up overwriting the GPIO number as well as the controller reference. > > What is needed to make this work is the ability to cope with > unresolved references in the base dtb, to be resolved as each overlay > is applied, with runtime checking that each reference is resolved > before it is used, all of which sounds like a nightmare. Plus, we > really don't want to have to change the way all our camera and display > overlays work on all Raspberry Pis just to accommodate somebody's idea > of how RP1 should be handled. Just to be clear, my comments were not there to tell you how RP1 should work. I just proposed ideas without trying to force anything and I can fully understand that ideas proposed don't feed your needs. Sorry if my approach was misunderstood. Best regards, Hervé