Re: [PATCH] remoteproc: core: Honor device tree /alias entries when assigning IDs

From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Nishanth Menon <nm@ti.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
	linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Robert Nelson <robertcnelson@gmail.com>,
	Kevin Cahalan <kevinacahalan@gmail.com>
Subject: Re: [PATCH] remoteproc: core: Honor device tree /alias entries when assigning IDs
Date: Wed, 23 Aug 2023 10:31:23 -0600	[thread overview]
Message-ID: <ZOY0W+0YdYRk2v/E@p14s> (raw)
In-Reply-To: <20230823155133.v7r3uddautivowps@frail>

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