All of lore.kernel.org
 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 06:51:00 +0000	[thread overview]
Message-ID: <DB6PR0402MB276063FBE74FCF222CB00F8588720@DB6PR0402MB2760.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200727064151.767kc7622tcqmqfs@pengutronix.de>

> 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:

        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");


Hope this is clear.


Thanks,
Peng.

> 
> > Thanks,
> > Peng.
> >
> > >
> > > > Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > >  drivers/remoteproc/imx_rproc.c | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > b/drivers/remoteproc/imx_rproc.c index 3b3904ebac75..82594a800a1b
> > > > 100644
> > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > @@ -296,9 +296,10 @@ static int imx_rproc_addr_init(struct
> > > > imx_rproc
> > > *priv,
> > > >  		if (b >= IMX7D_RPROC_MEM_MAX)
> > > >  			break;
> > > >
> > > > -		priv->mem[b].cpu_addr =
> devm_ioremap_resource(&pdev->dev,
> > > &res);
> > > > +		/* Not use resource version, because we might share region*/
> > > > +		priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
> res.start,
> > > > +resource_size(&res));
> > > >  		if (IS_ERR(priv->mem[b].cpu_addr)) {
> > > > -			dev_err(dev, "devm_ioremap_resource failed\n");
> > > > +			dev_err(dev, "devm_ioremap %pR failed\n", &res);
> > > >  			err = PTR_ERR(priv->mem[b].cpu_addr);
> > > >  			return err;
> > > >  		}
> > > > --
> > > > 2.16.4
> > > >
> > > >
> > >
> > > --
> > > 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 |
> 
> --
> 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 |

WARNING: multiple messages have this Message-ID (diff)
From: Peng Fan <peng.fan@nxp.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"mathieu.poirier@linaro.org" <mathieu.poirier@linaro.org>,
	"festevam@gmail.com" <festevam@gmail.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 03/10] remoteproc: imx: use devm_ioremap
Date: Mon, 27 Jul 2020 06:51:00 +0000	[thread overview]
Message-ID: <DB6PR0402MB276063FBE74FCF222CB00F8588720@DB6PR0402MB2760.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200727064151.767kc7622tcqmqfs@pengutronix.de>

> 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:

        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");


Hope this is clear.


Thanks,
Peng.

> 
> > Thanks,
> > Peng.
> >
> > >
> > > > Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > >  drivers/remoteproc/imx_rproc.c | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > b/drivers/remoteproc/imx_rproc.c index 3b3904ebac75..82594a800a1b
> > > > 100644
> > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > @@ -296,9 +296,10 @@ static int imx_rproc_addr_init(struct
> > > > imx_rproc
> > > *priv,
> > > >  		if (b >= IMX7D_RPROC_MEM_MAX)
> > > >  			break;
> > > >
> > > > -		priv->mem[b].cpu_addr =
> devm_ioremap_resource(&pdev->dev,
> > > &res);
> > > > +		/* Not use resource version, because we might share region*/
> > > > +		priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
> res.start,
> > > > +resource_size(&res));
> > > >  		if (IS_ERR(priv->mem[b].cpu_addr)) {
> > > > -			dev_err(dev, "devm_ioremap_resource failed\n");
> > > > +			dev_err(dev, "devm_ioremap %pR failed\n", &res);
> > > >  			err = PTR_ERR(priv->mem[b].cpu_addr);
> > > >  			return err;
> > > >  		}
> > > > --
> > > > 2.16.4
> > > >
> > > >
> > >
> > > --
> > > 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 |
> 
> --
> 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 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-07-27  6:51 UTC|newest]

Thread overview: 76+ 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 ` Peng Fan
2020-07-24  8:08 ` [PATCH 01/10] dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M Peng Fan
2020-07-24  8:08   ` Peng Fan
2020-07-31 20:14   ` Rob Herring
2020-07-31 20:14     ` Rob Herring
2020-07-24  8:08 ` [PATCH 02/10] remoteproc: imx_rproc: correct err message Peng Fan
2020-07-24  8:08   ` Peng Fan
2020-08-11 19:56   ` Mathieu Poirier
2020-08-11 19:56     ` Mathieu Poirier
2020-07-24  8:08 ` [PATCH 03/10] remoteproc: imx: use devm_ioremap Peng Fan
2020-07-24  8:08   ` Peng Fan
2020-07-27  6:23   ` Oleksij Rempel
2020-07-27  6:23     ` Oleksij Rempel
2020-07-27  6:28     ` Peng Fan
2020-07-27  6:28       ` Peng Fan
2020-07-27  6:41       ` Oleksij Rempel
2020-07-27  6:41         ` Oleksij Rempel
2020-07-27  6:51         ` Peng Fan [this message]
2020-07-27  6:51           ` Peng Fan
2020-07-27  7:37           ` Oleksij Rempel
2020-07-27  7:37             ` Oleksij Rempel
2020-07-27  8:11             ` Peng Fan
2020-07-27  8:11               ` Peng Fan
2020-07-28  7:20               ` Oleksij Rempel
2020-07-28  7:20                 ` Oleksij Rempel
2020-07-24  8:08 ` [PATCH 04/10] remoteproc: imx_rproc: make syscon optional Peng Fan
2020-07-24  8:08   ` Peng Fan
2020-08-11 22:40   ` Mathieu Poirier
2020-08-11 22:40     ` Mathieu Poirier
2020-08-18 21:43   ` Mathieu Poirier
2020-08-18 21:43     ` Mathieu Poirier
2020-08-19  0:51     ` Peng Fan
2020-08-19  0:51       ` Peng Fan
2020-08-19 19:45       ` Mathieu Poirier
2020-08-19 19:45         ` Mathieu Poirier
2020-08-20  2:04         ` Peng Fan
2020-08-20  2:04           ` Peng Fan
2020-08-20 19:27           ` Mathieu Poirier
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   ` Peng Fan
2020-07-24  8:08 ` [PATCH 06/10] remoteproc: imx_rproc: add load hook Peng Fan
2020-07-24  8:08   ` Peng Fan
2020-07-27  5:20   ` Oleksij Rempel
2020-07-27  5:20     ` Oleksij Rempel
2020-08-11 21:40   ` Mathieu Poirier
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-07-24  8:08   ` Peng Fan
2020-08-11 21:56   ` Mathieu Poirier
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   ` Peng Fan
2020-07-24  8:08 ` [PATCH 09/10] remoteproc: imx_proc: enable virtio/mailbox Peng Fan
2020-07-24  8:08   ` Peng Fan
2020-07-24  8:08 ` [PATCH 10/10] remoteproc: imx_rproc: support coproc booting before Linux Peng Fan
2020-07-24  8:08   ` Peng Fan
2020-08-11 22:36   ` Mathieu Poirier
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:38   ` Oleksij Rempel
2020-07-27  6:44   ` Peng Fan
2020-07-27  6:44     ` Peng Fan
2020-07-27  7:54     ` Oleksij Rempel
2020-07-27  7:54       ` Oleksij Rempel
2020-07-27  9:18       ` Peng Fan
2020-07-27  9:18         ` Peng Fan
2020-07-28  7:26         ` Oleksij Rempel
2020-07-28  7:26           ` Oleksij Rempel
2020-07-28  7:50           ` Peng Fan
2020-07-28  7:50             ` Peng Fan
2020-07-28  7:55             ` Oleksij Rempel
2020-07-28  7:55               ` Oleksij Rempel
2020-07-28  9:36               ` Peng Fan
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=DB6PR0402MB276063FBE74FCF222CB00F8588720@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 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.