From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Arnaud Pouliquen <arnaud.pouliquen@st.com>,
Ohad Ben-Cohen <ohad@wizery.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"A.s. Dong" <aisheng.dong@nxp.com>,
kernel@pengutronix.de, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, dl-linux-imx <linux-imx@nxp.com>,
Fabien DESSENNE <fabien.dessenne@st.com>
Subject: Re: [PATCH v1 1/2] imx-rproc: dt: provide new remote-nodes option
Date: Fri, 22 Jun 2018 15:53:53 -0700 [thread overview]
Message-ID: <20180622225353.GL3402@tuxbook-pro> (raw)
In-Reply-To: <20180615163733.4bmpuag5dbzdqw2n@pengutronix.de>
On Fri 15 Jun 09:37 PDT 2018, Oleksij Rempel wrote:
> Hi Arnaud,
>
> On Fri, Jun 15, 2018 at 03:21:19PM +0200, Arnaud Pouliquen wrote:
> > Hi Oleksij,
> >
> > Nice to see that we have the same needs.
> > We push several month ago an RFC based on something similar but i hope
> > more generic...
> > could you have a look?
> >
> > https://www.spinics.net/lists/linux-remoteproc/msg01823.html
>
> I took a look at dt binding.
> It would be really better to not redefine device nodes again.
Defining new nodes next to the proper (disabled) ones would only
duplicate the data and doesn't provide the means for preventing
conflicting usage.
> DT is providing HW description and if it is still the same IP core
> then most probably it is still the same from all CPUs.
The problem I see is that for every convenient case there's a lot of
cases where this doesn't work.
> Most probably there is different interrupt controller and memory
> offset, but all other parts should be the same.
This conclusion is what I've come to as well; clocks seems simple and
then it gets complicated. So what we would end up with is a mechanism
where we rely on some properties of the remote node representing the
resources of the remote processor, but other doesn't.
This becomes very complex to maintain...
> In long term it would be great to reduce duplicated information which is
> needed to added system developer.
>
Agreed, but I don't think that adding a partial view of the remote
processor to the local system's hardware definition is going to make it
easier for said developer.
> > Could be nice if we could find a generic solution...
>
> I would be happy to have generic solution.
>
Me too, and based on our discussions on the subject I think it's
important that we consider how to handle dynamically controlled
resources (though some RPMSG based resource management protocol) as
well - I don't want one mechanism for static clocks and a completely
different for dynamically controlled clocks.
Regards,
Bjorn
next prev parent reply other threads:[~2018-06-22 22:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 11:57 [PATCH v1 1/2] imx-rproc: dt: provide new remote-nodes option Oleksij Rempel
2018-06-15 11:57 ` [PATCH v1 2/2] remoteproc: imx_rproc: assign other DT nodes to rproc node Oleksij Rempel
2018-06-15 13:21 ` [PATCH v1 1/2] imx-rproc: dt: provide new remote-nodes option Arnaud Pouliquen
2018-06-15 16:37 ` Oleksij Rempel
2018-06-18 9:32 ` Arnaud Pouliquen
2018-06-18 12:37 ` Oleksij Rempel
2018-06-19 13:58 ` Arnaud Pouliquen
2018-06-22 6:24 ` Oleksij Rempel
2018-06-22 8:36 ` Arnaud Pouliquen
2018-06-22 22:53 ` Bjorn Andersson [this message]
2018-06-22 22:15 ` Bjorn Andersson
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=20180622225353.GL3402@tuxbook-pro \
--to=bjorn.andersson@linaro.org \
--cc=aisheng.dong@nxp.com \
--cc=arnaud.pouliquen@st.com \
--cc=devicetree@vger.kernel.org \
--cc=fabien.dessenne@st.com \
--cc=kernel@pengutronix.de \
--cc=linux-imx@nxp.com \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=o.rempel@pengutronix.de \
--cc=ohad@wizery.com \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).