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 88728EE4993 for ; Wed, 23 Aug 2023 16:32:02 +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=IC1JnwF75v55wDuQTmrTfu7sFdYJeyjtcN7dP1cFq6w=; b=MTxkx9cFa7fPQZ TjxoEjTENTUTL/j5atS0z18oSSHT9Nnifwh9Kq2TxSN6yzQ+Jj6FOhtp94o3gZr/x1qx6JGhkPyzV ieoqhIO3QVw79cHC2f1oYsJnOe4O/q0VF/2ymg+2Hb0nZJiINvCaBINw+4ziRUXUVPe/bjpTuCykT zyC9mnVbWiQNSvn4AnfOehejiuLvgO/h0V/WXUkWnqbU3eglRJGgQJopzB+O1bbaONOu77OLIRPfz +E25gqKgEb+VZwyFsNlTPSIVQyMcTDx7lze5AyVV++vEhpYcV0iUF/wRD9joT2N7eGo59YO8CdmKU zuyNNmlgieuLzJHq9Eog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qYqlZ-0014fX-35; Wed, 23 Aug 2023 16:31:33 +0000 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qYqlW-0014es-0D for linux-arm-kernel@lists.infradead.org; Wed, 23 Aug 2023 16:31:32 +0000 Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-68a1af910e0so3040349b3a.2 for ; Wed, 23 Aug 2023 09:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692808286; x=1693413086; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7VysVEYYRSJeYSLz+kixV83JtPHzoPi7dpX2zv9tu5I=; b=LqwVP+Rlu1RdZiF0Mu6GRObHEUlblBSAnzWMwSdK77l/PCpcfEPMuiGdBLrAcqrnqT JyGz7G9XKpguy2u4YvFzq5ObBYbR0AX/jMfbGgruPKVHyimvv/qcAfNiz1HlI8EU07/G MCjfGay/9pJly27x2lut9sHucOUp7x8rHxfWCiyklH/JtBOAxAC2JIHJROF/VhP3qjpl CFQQknxsmBTWHd6fk4vBZTkNijno5ARVxbkV/iRHUjYt5powRTL69/wnQCkab+Dlxl6I ScYqxbDX/u6Z0CaPC41IytjW9CVHmxYwd7fObb78MaunO0fAEWGyawFQCQjC3GLO5g5A nYrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692808286; x=1693413086; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7VysVEYYRSJeYSLz+kixV83JtPHzoPi7dpX2zv9tu5I=; b=Odym2JIdYBVxi4BFsPOVTRHdGiHvKTWMEAU0+xFCMV20pGdSZ6PAlhTVFe8ftO1djk Q93hIXS4BwT5D7UKfkZzAgIdAbv3+NwbrJWypVLID1e3yNcd724OVwnJ1CA+aq6uOHIw xf1Jzww2WI+kI57vz7w4854dJDrwZyyiqkhMZflQgjIB1PK3Bve4yikZT1ZZxHNY9Uks D2PJlf5k8oAP5ZPD6QYzBa7eH9J13DtyhBdFPMMXihmLbvqKhYXg9ndlQw9Z2B/QV6SE DT2mX9RJy9/saA8U/hBKBElB+v4+1a/eiLxNMFwfwP+ecOUg8KhKnXnD+LpVmUw1XVet VNMA== X-Gm-Message-State: AOJu0YzLNwLL9n3KR8bHS30vxdVzJRjelvuckmncSN+XHZmcmuQXsN8h gT2CrX3HGaz0sBRyTB3S9EfjQw== X-Google-Smtp-Source: AGHT+IGQYgls24Bsf8aeqi854XlDAQ6SJ0EWXMz2Gf0ZIokynRBMKhKP1zIA3yahMEjnRKOgZ24ozQ== X-Received: by 2002:a05:6a21:8187:b0:131:4808:d5a1 with SMTP id pd7-20020a056a21818700b001314808d5a1mr9594048pzb.28.1692808286171; Wed, 23 Aug 2023 09:31:26 -0700 (PDT) Received: from p14s ([2604:3d09:148c:c800:3ae3:a477:fe1c:f18c]) by smtp.gmail.com with ESMTPSA id u5-20020aa78385000000b00687ce7c6540sm9920432pfm.99.2023.08.23.09.31.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Aug 2023 09:31:25 -0700 (PDT) Date: Wed, 23 Aug 2023 10:31:23 -0600 From: Mathieu Poirier To: Nishanth Menon Cc: Bjorn Andersson , linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Robert Nelson , Kevin Cahalan Subject: Re: [PATCH] remoteproc: core: Honor device tree /alias entries when assigning IDs Message-ID: References: <20230807140247.956255-1-nm@ti.com> <20230822201205.4csoj4kym2yhuyrf@decrease> <20230823155133.v7r3uddautivowps@frail> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230823155133.v7r3uddautivowps@frail> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230823_093130_107892_9230DEF1 X-CRM114-Status: GOOD ( 36.18 ) 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 Wed, Aug 23, 2023 at 10:51:33AM -0500, Nishanth Menon wrote: > 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.. > The point is that aliases will guarantee a naming convention for remote processors but won't guarantee their functionality. Sure, we can add aliases but it won't solve all your problems. > 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 That is exactly what I am referring to. >- something like openAMP endpoint > solutions probably help? I am not familiar with openAmP endpoints but certainly willing to consider it as an option. > > Let me know if I am off-track here.. > You are on track. > [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