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 164C5EE4993 for ; Wed, 23 Aug 2023 15:52:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: 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=eqKW6mHXcQkbFsL3kUxqf/gLyelvLpKFDJl5f/2VML4=; b=k1i92QOIdwGY4k jw+H3o+jzGEAJl8Aifu/70UzRhjmvt+CMh56p3DJCwXFP2JEnmI208RXoPuRINcL4+OjRw2gZGcwm QQtAtyujEvE8tfIyqVZgGvUjDEQ6SLT+1GTTX8Rfq+K0LWxcCQn/CPJZY57XR7IJSmnpfqN/09dfz +skh/JQwILGM07m7sKcS/EAGLBDVnLchlOD8MzMHKtUYfog6+a7RjJjniixzcI9OVYXw1r65XHsdx wAYrfmNfhAJoJAO5gHtfx+nJ6ChHm9zfEa+lZNJpVXd51Q7N8KNPuS3qghcvLo6c980SVJvbYOujA 4HesWJ7XC64g6FVIa/qQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qYq96-0011bU-0G; Wed, 23 Aug 2023 15:51:48 +0000 Received: from lelv0143.ext.ti.com ([198.47.23.248]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qYq91-0011aR-34 for linux-arm-kernel@lists.infradead.org; Wed, 23 Aug 2023 15:51:46 +0000 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 37NFpXt4038893; Wed, 23 Aug 2023 10:51:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1692805893; bh=W6V1upOtSdkrnnJgAfZkngCMorV465U5MgquJbm+CBM=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=rgEnzlZVRAsltvaxt2Lw7e/JB5pIwgDNJ5z7gXFgyTUlUozLCmPbcUZz1Z4Gz9aUw qG/NHPERxiLA3KBo63RsXCv8xQf8UrKAaJioXhw084Sqf3/VUWZgfxhcrueSTdcJZC xcua6yH55WJ4ueFYP69Qxw1TRXVvRBnh9MyTY0a0= Received: from DLEE111.ent.ti.com (dlee111.ent.ti.com [157.170.170.22]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 37NFpXeC055323 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 23 Aug 2023 10:51:33 -0500 Received: from DLEE109.ent.ti.com (157.170.170.41) by DLEE111.ent.ti.com (157.170.170.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Wed, 23 Aug 2023 10:51:33 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE109.ent.ti.com (157.170.170.41) 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; Wed, 23 Aug 2023 10:51:33 -0500 Received: from localhost (ileaxei01-snat.itg.ti.com [10.180.69.5]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 37NFpXj6008149; Wed, 23 Aug 2023 10:51:33 -0500 Date: Wed, 23 Aug 2023 10:51:33 -0500 From: Nishanth Menon To: Mathieu Poirier CC: Bjorn Andersson , , , , Robert Nelson , Kevin Cahalan Subject: Re: [PATCH] remoteproc: core: Honor device tree /alias entries when assigning IDs Message-ID: <20230823155133.v7r3uddautivowps@frail> References: <20230807140247.956255-1-nm@ti.com> <20230822201205.4csoj4kym2yhuyrf@decrease> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20230823_085144_183266_358C4A5C X-CRM114-Status: GOOD ( 29.10 ) 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: , 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 09:23-20230823, Mathieu Poirier wrote: > On Tue, Aug 22, 2023 at 03:12:05PM -0500, Nishanth Menon wrote: > > On 13:25-20230822, Mathieu Poirier wrote: > > > Hi Nishanth, > > > > > > On Mon, Aug 07, 2023 at 09:02:47AM -0500, Nishanth Menon wrote: > > > > On many platforms, such as Beaglebone-AI64 with many remote > > > > processors, firmware configurations provided by the distributions can > > > > vary substantially depending on the distribution build's functionality > > > > and the specific remote cores enabled in that variant. Ensuring > > > > consistent udev rules mapping remoteproc nodes to constant remote > > > > proc device indices across distributions (yocto, ubuntu, debian and > > > > it's variants, ...) on a board basis can be challenging due to the > > > > various functions of these distributions. Varied device node paths > > > > create challenges for applications that operate on remote processors, > > > > especially in minimal embedded systems(initrd like) that may not > > > > have udev-like capabilities and rely on a more straightforward bare > > > > filesystem. This challenge is similar to that faced by I2C, RTC or the > > > > GPIO subsystems. > > > > > > > > > > I'm puzzled by this patch. I can see how using an alias can help in boards with > > > various HW configuration. That said, and as written above, FW files for remote > > > processors can vary based on the build's functionality. As such "remoteproc3" > > > will reference the same HW device on all distributions but the functionality > > > enacted by the FW may be different. As such I don't see how an alias can help > > > here. Can you provide a concrete example that highlights the benefits? > > > > Correct - *if* remoteproc3 is the constant node reference. > > > > To take a trivial example: We ran into this issue with: > > https://github.com/kaofishy/bbai64_cortex-r5_example/blob/main/Makefile#L28 > > > > remoteproc18 apparently changed numbering in a different build. > > > > We are going around in circles. In the above link using an alias will > guarantee that "remoteproc18" is available but won't guarantee the > functionality enacted by the FW loaded in that remote processor, which is distro > dependent. Apologies, but I am trying to comprehend the relationship and probably am failing to see the linkage. Let me try: If I understand you correctly, you are concerned that distros do not have a mechanism to provide consistent firmware to the correct remote proc for a specific functionality.. if so, distro loads / provides the requisite firmware. How the package distribution scheme works to distribute the firmware and versioning provided varies - One typical pattern has been to use linux-firmware repo[1] (at least in other domains - say GPU, wlink or the likes) and provide package distribution. The other pattern could be build and deploy based on tag (this would be no different from any other package deployment). On the other hand, If we are looking at the fact that there can be different types of firmware that could be loaded to a remoteproc providing different functionality - that is correct, and at least in case of TI processors very valid - something like openAMP endpoint solutions probably help? Let me know if I am off-track here.. [1] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-ipc?h=ti-linux-firmware -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel