linux-remoteproc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@nxp.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"mathieu.poirier@linaro.org" <mathieu.poirier@linaro.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"festevam@gmail.com" <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: RE: [PATCH 03/10] remoteproc: imx: use devm_ioremap
Date: Mon, 27 Jul 2020 08:11:09 +0000	[thread overview]
Message-ID: <DB6PR0402MB2760EFCB8C91680DC719C82C88720@DB6PR0402MB2760.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200727073757.r2vq6djh3a4dyfp6@pengutronix.de>

> Subject: Re: [PATCH 03/10] remoteproc: imx: use devm_ioremap
> 
> On Mon, Jul 27, 2020 at 06:51:00AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH 03/10] remoteproc: imx: use devm_ioremap
> > >
> > > On Mon, Jul 27, 2020 at 06:28:20AM +0000, Peng Fan wrote:
> > > > Hi Oleksij,
> > > >
> > > > > Subject: Re: [PATCH 03/10] remoteproc: imx: use devm_ioremap
> > > > >
> > > > > On Fri, Jul 24, 2020 at 04:08:06PM +0800, Peng Fan wrote:
> > > > > > We might need to map an region multiple times, becaue the
> > > > > > region might be shared between remote processors, such i.MX8QM
> > > > > > with dual
> > > M4 cores.
> > > > > > So use devm_ioremap, not devm_ioremap_resource.
> > > > >
> > > > > Can you please give an example of this kind of shared resources
> > > > > and how they should be handled by two separate devices?
> > > >
> > > > This is to share vdevbuffer space, there is a vdevbuffer in device
> > > > tree, it will be shared between M4_0 and M4_1.
> > > >
> > > > For the buffer, it is Linux DMA API will handle the space.
> > >
> > > Why remoteproc need to care about it? If I see it correctly, from
> > > the linux perspective, it is one buffer and one driver is
> > > responsible for it. Or do I missing some thing?
> >
> > We not have the vdev buffer in resource table, so I added in device tree, see
> below:
> 
> Hm.. if vdev is not in resource table and should not be controlled by
> remoteproc, why do we need remoteproc?

I use same approach as stm32 rproc driver.

The resource table here only publish vring address.

> 
> >         imx8qm_cm40: imx8qm_cm4@0 {
> >                 compatible = "fsl,imx8qm-cm4";
> >                 rsc-da = <0x90000000>;
> >                 mbox-names = "tx", "rx", "rxdb";
> >                 mboxes = <&lsio_mu5 0 1
> >                           &lsio_mu5 1 1
> >                           &lsio_mu5 3 1>;
> >                 mub-partition = <3>;
> >                 memory-region = <&vdev0vring0>, <&vdev0vring1>,
> <&vdevbuffer>,
> >                                 <&vdev1vring0>, <&vdev1vring1>;
> >                 core-index = <0>;
> >                 core-id = <IMX_SC_R_M4_0_PID0>;
> >                 status = "okay";
> >                 power-domains = <&pd IMX_SC_R_M4_0_PID0>,
> >                                 <&pd IMX_SC_R_M4_0_MU_1A>;
> >         };
> >
> >         imx8qm_cm41: imx8x_cm4@1 {
> >                 compatible = "fsl,imx8qm-cm4";
> >                 rsc-da = <0x90100000>;
> >                 mbox-names = "tx", "rx", "rxdb";
> >                 mboxes = <&lsio_mu6 0 1
> >                           &lsio_mu6 1 1
> >                           &lsio_mu6 3 1>;
> >                 mub-partition = <4>;
> >                 memory-region = <&vdev2vring0>, <&vdev2vring1>,
> <&vdevbuffer>,
> >                                 <&vdev3vring0>, <&vdev3vring1>;
> >                 core-index = <1>;
> >                 core-id = <IMX_SC_R_M4_1_PID0>;
> >                 status = "okay";
> >                 power-domains = <&pd IMX_SC_R_M4_1_PID0>,
> >                                 <&pd IMX_SC_R_M4_1_MU_1A>;
> >         };
> >
> >                 vdevbuffer: vdevbuffer {
> >                         compatible = "shared-dma-pool";
> >                         reg = <0 0x90400000 0 0x100000>;
> >                         no-map;
> >                 };
> >
> > I have the upper vdevbuffer node shared between M40 and M41 node.
> > The vdevbuffer will be used as virtio data buffer.
> >
> > And I have the following in rproc_add_virtio_dev to share vdevbuffer:
> >         /* Try to find dedicated vdev buffer carveout */
> >         mem = rproc_find_carveout_by_name(rproc, "vdev%dbuffer",
> rvdev->index);
> >         if (!mem)
> >                 mem = rproc_find_carveout_by_name(rproc,
> > "vdevbuffer");
> 
> With kernel v5.8-rc7 i get following call chain:

Please use Linux-next which has support of M4 booted before Linux in
in remoteproc.

> rproc_boot()
>   rproc_fw_boot()
>     rproc_handle_vdev
>       rproc_vdev_do_start()
>         rproc_add_virtio_dev()
> 
> 
> So, at the end, we will call rproc_add_virtio_dev() only if we boot firmware by
> linux, or if we get at least the resource table.


Resource table could be got from elf file if it is booted by Linux, or got from
an address if M4 is booted before Linux.

Thanks,
Peng.

> 
> Since none of this seems to be the case, i still do not understand how it should
> work.
> 
> > Hope this is clear.
> 
> :) i still need some time to understand it.
> 
> --
> Pengutronix e.K.                           |
> |
> Steuerwalder Str. 21                       |
> http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone:
> +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

  reply	other threads:[~2020-07-27  8:11 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24  8:08 [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early boot Peng Fan
2020-07-24  8:08 ` [PATCH 01/10] dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M Peng Fan
2020-07-31 20:14   ` Rob Herring
2020-07-24  8:08 ` [PATCH 02/10] remoteproc: imx_rproc: correct err message Peng Fan
2020-08-11 19:56   ` Mathieu Poirier
2020-07-24  8:08 ` [PATCH 03/10] remoteproc: imx: use devm_ioremap Peng Fan
2020-07-27  6:23   ` Oleksij Rempel
2020-07-27  6:28     ` Peng Fan
2020-07-27  6:41       ` Oleksij Rempel
2020-07-27  6:51         ` Peng Fan
2020-07-27  7:37           ` Oleksij Rempel
2020-07-27  8:11             ` Peng Fan [this message]
2020-07-28  7:20               ` Oleksij Rempel
2020-07-24  8:08 ` [PATCH 04/10] remoteproc: imx_rproc: make syscon optional Peng Fan
2020-08-11 22:40   ` Mathieu Poirier
2020-08-18 21:43   ` Mathieu Poirier
2020-08-19  0:51     ` Peng Fan
2020-08-19 19:45       ` Mathieu Poirier
2020-08-20  2:04         ` Peng Fan
2020-08-20 19:27           ` Mathieu Poirier
2020-07-24  8:08 ` [PATCH 05/10] remoteproc: imx_rproc: make clk optional Peng Fan
2020-07-24  8:08 ` [PATCH 06/10] remoteproc: imx_rproc: add load hook Peng Fan
2020-07-27  5:20   ` Oleksij Rempel
2020-08-11 21:40   ` Mathieu Poirier
2020-07-24  8:08 ` [PATCH 07/10] remoteproc: imx_rproc: add i.MX specific parse fw hook Peng Fan
2020-08-11 21:56   ` Mathieu Poirier
2020-07-24  8:08 ` [PATCH 08/10] remoteproc: imx_rproc: support i.MX8MQ/M Peng Fan
2020-07-24  8:08 ` [PATCH 09/10] remoteproc: imx_proc: enable virtio/mailbox Peng Fan
2020-07-24  8:08 ` [PATCH 10/10] remoteproc: imx_rproc: support coproc booting before Linux Peng Fan
2020-08-11 22:36   ` Mathieu Poirier
2020-07-27  6:38 ` [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early boot Oleksij Rempel
2020-07-27  6:44   ` Peng Fan
2020-07-27  7:54     ` Oleksij Rempel
2020-07-27  9:18       ` Peng Fan
2020-07-28  7:26         ` Oleksij Rempel
2020-07-28  7:50           ` Peng Fan
2020-07-28  7:55             ` Oleksij Rempel
2020-07-28  9:36               ` Peng Fan

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=DB6PR0402MB2760EFCB8C91680DC719C82C88720@DB6PR0402MB2760.eurprd04.prod.outlook.com \
    --to=peng.fan@nxp.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=o.rempel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@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).