All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Yann Sionneau <ysionneau@kalrayinc.com>,
	linux-remoteproc@vger.kernel.org,
	Bjorn Andersson <andersson@kernel.org>,
	Julian Vetter <jvetter@kalrayinc.com>,
	Jonathan Borne <jborne@kalray.eu>,
	Julien Hascoet <jhascoet@kalray.eu>,
	Damien Hedde <dhedde@kalrayinc.com>,
	Titouan Huard <thuard@kalrayinc.com>
Subject: Re: [RFC] Passing device-tree to remoteproc?
Date: Mon, 5 Feb 2024 14:05:32 -0700	[thread overview]
Message-ID: <ZcFNnDDORrVuWKHq@p14s> (raw)
In-Reply-To: <cc9926d2-4341-47b3-8b00-a33fbf653744@foss.st.com>

Good day Yann,

On Fri, Feb 02, 2024 at 10:14:08AM +0100, Arnaud POULIQUEN wrote:
> Hello Yann,
> 
> On 1/30/24 11:20, Yann Sionneau wrote:
> > Hello,
> > 
> > On 1/23/24 14:32, Yann Sionneau wrote:
> >> Hello,
> >>
> >> How interesting to upstream Linux would it be to have a way for Linux kernel
> >> or user space to pass a device tree blob to remote processor when starting a
> >> remote proc FW?
> >>
> >> For instance we could imagine something like this:
> >>
> >> 1/ user space does echo -n firmware.elf >
> >> /sys/class/remoteproc/remoteprocXXX/firmware
> >>
> >> 2/ user space does echo -n my_dt.dtb > /sys/class/remoteproc/remoteprocXXX/dtb
> >>
> >> 3/ user space does echo start > /sys/class/remoteproc/remoteprocXXX/state
> > 
> > Any opinion on this proposal?
>
> 
> Interesting use case. There is no concrete need in ST, but it raises the
> question of providing extra data with the firmware to the remote processor.
> 

I agree with Arnaud.  From a mechanical point of view it is interesting and
doesn't pause a serious technical challenge.  That said I don't really
understand the motivation behind the idea.  More details the exact problem you
want to fix would be welcomed.

> In a first approach, my personal feeling is that the ELF and the DTB are
> interdependent.
> So having a mechanism to ensure coherency between both could be important.
> 
> Then it could be interesting to address the need in a more generic way
> to be able to transfer extra data, for instance an audio tuning for a DSP.
> Adding a specific sysfs for each specific need could not be a good idea in long
> term.
> 
> Have you looked into some other approaches such as adding the DTB as a specific
> section of your ELF file,or adding the support of a new format that packages
> everything together (for instance FIP)?

Here too I have to agree with Arnaud.

> Regards,
> Arnaud
> 
> > 
> > Thanks!
> > 
> > Regards,
> > 

  reply	other threads:[~2024-02-05 21:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23 13:32 [RFC] Passing device-tree to remoteproc? Yann Sionneau
2024-01-30 10:20 ` Yann Sionneau
2024-02-02  9:14   ` Arnaud POULIQUEN
2024-02-05 21:05     ` Mathieu Poirier [this message]
2024-02-19 16:17       ` Yann Sionneau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZcFNnDDORrVuWKHq@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=andersson@kernel.org \
    --cc=arnaud.pouliquen@foss.st.com \
    --cc=dhedde@kalrayinc.com \
    --cc=jborne@kalray.eu \
    --cc=jhascoet@kalray.eu \
    --cc=jvetter@kalrayinc.com \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=thuard@kalrayinc.com \
    --cc=ysionneau@kalrayinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.