Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Peng Fan <peng.fan@nxp.com>
To:     Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>
CC:     "linux-remoteproc@vger.kernel.org" <linux-remoteproc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-stm32@st-md-mailman.stormreply.com" 
        <linux-stm32@st-md-mailman.stormreply.com>,
        Rob Herring <robh@kernel.org>, Christoph Hellwig <hch@lst.de>,
        Stefano Stabellini <stefanos@xilinx.com>,
        Bruce Ashfield <bruce.ashfield@xilinx.com>
Subject: RE: [RFC PATCH v3 0/4] remoteproc: restructure the remoteproc VirtIO
 device
Thread-Topic: [RFC PATCH v3 0/4] remoteproc: restructure the remoteproc VirtIO
 device
Thread-Index: AQHYEtE0wJ0OgErjykyAoYmEY+BNQKyUZypw
Date:   Tue, 15 Feb 2022 08:34:46 +0000
Message-ID: <DU0PR04MB941722D995004F877DC6171D88349@DU0PR04MB9417.eurprd04.prod.outlook.com>
References: <20220126162405.1131323-1-arnaud.pouliquen@foss.st.com>
In-Reply-To: <20220126162405.1131323-1-arnaud.pouliquen@foss.st.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?qfMV9k/cXjBb8vgCb/hAxS7wxf+bgT2h5KTrB3z4UxfwyAnQxqfh7/5WiSP4?=
 =?us-ascii?Q?a/zGY4D2BOmufVd+4syf3MhRQmNPaQezST8/rp5TE9Z59JWMHdbdAmH5Tk8v?=
 =?us-ascii?Q?/XAiiGGlIw5lSOmOaZnAuB0VxMss/B6pLyirHApcbpESXDiaCjPEm8pgjrvV?=
 =?us-ascii?Q?02EGw1826s7hpgyRikBXRDYlbdjNHDYAg08FtoXN5qcavqIRbK/GPXHZaa9S?=
 =?us-ascii?Q?yWygd7S9zNzK9FqLZoKApZv+HlEqOgSfnPniXav8rhgb2iYy/piHin2Wp4DK?=
 =?us-ascii?Q?RDzjiUFziYkG0+67DDLXBMKD29u2qJjT8tVDSs0yncIDtejdb4sFRcvvgN0j?=
 =?us-ascii?Q?WToA6rnnVtJHI5pTBxilW+qFsa7dKZgGDpn9uju35KcFOHu1wCC/9Q69kq/w?=
 =?us-ascii?Q?TJzpwrnYacxF/4tSb13cNNBHWCB4xPDhCgkRQBI1YNqjkY7iOMTcG/NWZ0NW?=
 =?us-ascii?Q?gkhROJoVnGciYJzIXRwEOBC0OlT8w0rxIfdx1E2FIDpg3ckXHtbL0oqyFXDj?=
 =?us-ascii?Q?crZVgXgAXSP1IzDIlq2tfH/xy0vhjEi3YUtowbeuAfJ86hdWWCAtKmXQMYGm?=
 =?us-ascii?Q?M+p7H58CqsIewWRNwdZvHToZB4nwK0f3oE5x684tTSDcUvc9OMbU89/1aMK+?=
 =?us-ascii?Q?bCCX884lXY3QzavymF3KSVoq6R+LKzc+Bd+BFCQYhVMpik4ZqfQPEbWp5kda?=
 =?us-ascii?Q?0L0UJcyWl7HaGxDDWPL7yADdEVwJPuYgPKWTpJlsA7eVtrc6FbTPN3ZB+HX4?=
 =?us-ascii?Q?Ob8GLCDAIhSMUaQhmE/beSgm2xegrNDQ6c7eYnlWZw7PY1rPsBBTlI9wJxDZ?=
 =?us-ascii?Q?52QzABpGYok6O+cQRVwujVO6Rzby1ho9jfdfkBo5b+YUYFn0/kqUvl7OYtXW?=
 =?us-ascii?Q?KZE3Of8373ogWE6Dwh84bqZlxWTNy0juERcFuooDT+6RPvfP5BRjeXYl4Vde?=
 =?us-ascii?Q?wpDp+RC4nKdU1I9T7f8gBZIQm4Xfs29+yPcDwxQ6dPB9BB+shZ9XclfcoU8G?=
 =?us-ascii?Q?s9el+TnHm5IJsm+bwLJfUvujJuALcmNPuPSnQLiqDh8QWakHXmKdmh+bJqCo?=
 =?us-ascii?Q?Biu1juMBBIcrXF4MOWGNuUGU1lbroxvTfH8OoZvAeUk5sWs8Fa7GnDFeN0Fi?=
 =?us-ascii?Q?/BSmKd/o2anUU0RV8YWk6Ec+Dz49GVr9wXYAKpCjijo1tkZrCnRLl1Gk+Qeu?=
 =?us-ascii?Q?1W4OD6oSUaZJTI1TIhPHYN34Ue5zpqJparqXEkNFnkgP3nVrXIpXytJlkQqC?=
 =?us-ascii?Q?MhOljnYx4RegWdPyxI3Ht6Xoa/Yf9+DAGKJV5JZ7vnX1BXDJwBDzg/JY3K5c?=
 =?us-ascii?Q?Fms2kZnYJDoWC2FOGBUbRKE0kOchgxxfVeJdkYQGpn8esfkt03Pkm+n06TTP?=
 =?us-ascii?Q?SDlkyQ1nv55gkRBYnX7kNGlRDIiQXl+/8ao7fzVfGme/aqsRaD3zooXk0daQ?=
 =?us-ascii?Q?bMmByVaZAfV2TFCosv9B7TsvTdj9FFLeMY0ksS5p7rPGdQZHtECm0L3cLYTo?=
 =?us-ascii?Q?3UyNgqDil0xsdv4jiYN3pHSBxkKABDuHG0RVCG/NMme8OhLHWpu6fpQU6PU2?=
 =?us-ascii?Q?dxh/Hezv+MlxzsJF6fp9tzhqgavB9MrzTntB2UU6ixE2GWuAV/Tlkeee3CMM?=
 =?us-ascii?Q?7w=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9417.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4cf6a537-5962-4d97-dbef-08d9f05e05e3
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2022 08:34:46.4797
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XQxU60kRgmM+4uyJzL8dUpvAbtH6hkswVPEa16cf+Lr/s37LEcIeIX5xqG55lJEwe4xi8z6kaEL9W0zPhmPtkw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR04MB7434
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Subject: [RFC PATCH v3 0/4] remoteproc: restructure the remoteproc VirtIO
> device
>=20
> Update from V2 [1]:
> In order to better handle error cases and to have something more
> symmetrical between the functions in charge of rvdev initialization/delet=
ion,
> the patchset has been reworked.
>  - Introduction in the first patch, of rproc_vdev_data structure which al=
lows
> to better
>    decorrelate the rproc from the management of the rvdev structure. This
> structure is reused
>    in the last patch of the series for the creation of the remoteproc vir=
tio
> platform device.
>  - In addition to the previous version, the management of the vring lifec=
ycle
> has been fully
>    migrated to the remoteproc_virtio.c (rproc_parse_vring, rproc_alloc_vr=
ing,
> rproc_free_vring)
>=20
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flkml.=
or
> g%2Flkml%2F2021%2F12%2F22%2F111&amp;data=3D04%7C01%7Cpeng.fan%4
> 0nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C637788110748757786%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C3000&amp;sdata=3DbFfSxpPMpPRGYcMBcwxaQ152mRzf3c
> fwoFPjiJ0SIgw%3D&amp;reserved=3D0
>=20
> Patchset description:
>=20
> This series is a part of the work initiated a long time ago in the series
> "remoteproc: Decorelate virtio from core"[2]
>=20
> Objective of the work:
> - Update the remoteproc VirtIO device creation (use platform device)
> - Allow to declare remoteproc VirtIO device in DT

This means not using resource table anymore with new approach?
If yes, would that introduce a problem that different M-core images
requires different dtb?

>     - declare resources associated to a remote proc VirtIO
>     - declare a list of VirtIO supported by the platform.
> - Prepare the enhancement to more VirtIO devices (e.g I2C, audio, video, =
...).
>   For instance be able to declare a I2C device in a virtio-i2C node.

As my understanding virtio-i2c is a i2c bus, you could declare a i2c device
in the virtual bus without your patchset, would you please share more?

Thanks,
Peng.

> - Keep the legacy working!
> - Try to improve the picture about concerns reported by Christoph Hellwin=
g
> [3][4]
>=20
> [2]
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flkml.=
or
> g%2Flkml%2F2020%2F4%2F16%2F1817&amp;data=3D04%7C01%7Cpeng.fan%4
> 0nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C637788110748757786%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C3000&amp;sdata=3DO2BZw5PCY19eD5xMGxrGUKC%2Fty1
> Sdc3LE6rhK4cSXvs%3D&amp;reserved=3D0
> [3]
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flkml.=
or
> g%2Flkml%2F2021%2F6%2F23%2F607&amp;data=3D04%7C01%7Cpeng.fan%40
> nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C0%7C637788110748757786%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C3000&amp;sdata=3DxqX50iDeL%2BtFBOgyADnEUE5HH4gogK
> C0MwyqZSxVqNo%3D&amp;reserved=3D0
> [4]
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2FAOKowLclCbO
> CKxyiJ71WeNyuAAj2q8EUtxrXbyky5E%40cp7-web-042.plabs.ch%2F&amp;da
> ta=3D04%7C01%7Cpeng.fan%40nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e85
> 5e2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637788110748
> 757786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DmvSm3wM
> LgQ%2BDFhqjXIkG8de58zFjwPSURzw55JhGNaA%3D&amp;reserved=3D0
>=20
> In term of device tree this would result in such hiearchy (stm32mp1 examp=
le
> with 2 virtio RPMSG):
>=20
> 	m4_rproc: m4@10000000 {
> 		compatible =3D "st,stm32mp1-m4";
> 		reg =3D <0x10000000 0x40000>,
> 		      <0x30000000 0x40000>,
> 		      <0x38000000 0x10000>;
>         memory-region =3D <&retram>, <&mcuram>,<&mcuram2>;
>         mboxes =3D <&ipcc 2>, <&ipcc 3>;
>         mbox-names =3D "shutdown", "detach";
>         status =3D "okay";
>=20
>         #address-cells =3D <1>;
>         #size-cells =3D <0>;
>=20
>         vdev@0 {
> 		compatible =3D "rproc-virtio";
> 		reg =3D <0>;
> 		virtio,id =3D <7>;  /* RPMSG */
> 		memory-region =3D <&vdev0vring0>, <&vdev0vring1>,
> <&vdev0buffer>;
> 		mboxes =3D <&ipcc 0>, <&ipcc 1>;
> 		mbox-names =3D "vq0", "vq1";
> 		status =3D "okay";
>         };
>=20
>         vdev@1 {
> 		compatible =3D "rproc-virtio";
> 		reg =3D <1>;
> 		virtio,id =3D <7>;  /*RPMSG */
> 		memory-region =3D <&vdev1vring0>, <&vdev1vring1>,
> <&vdev1buffer>;
> 		mboxes =3D <&ipcc 4>, <&ipcc 5>;
> 		mbox-names =3D "vq0", "vq1";
> 		status =3D "okay";
>         };
> };
>=20
> I have divided the work in 4 steps to simplify the review, This series
> implements only the step 1:
> step 1:  redefine the remoteproc VirtIO device as a platform device
>   - migrate rvdev management in remoteproc virtio.c,
>   - create a remotproc virtio config ( can be disabled for platform that =
not use
> VirtIO IPC.
> step 2: add possibility to declare and prob a VirtIO sub node
>   - VirtIO bindings declaration,
>   - multi DT VirtIO devices support,
>   - introduction of a remote proc virtio bind device mechanism , =3D>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu=
b.
> com%2Farnopo%2Flinux%2Fcommits%2Fstep2-virtio-in-DT&amp;data=3D04%7
> C01%7Cpeng.fan%40nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2%7C
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637788110748757786
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DX%2B462681gcxe6
> 2GP%2BV7ji2nef%2FuTbQVvIlddcMQwtmg%3D&amp;reserved=3D0
> step 3: Add memory declaration in VirtIO subnode =3D>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu=
b.
> com%2Farnopo%2Flinux%2Fcommits%2Fstep3-virtio-memories&amp;data=3D0
> 4%7C01%7Cpeng.fan%40nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2
> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637788110748757
> 786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DeMlXgCgrV6l46
> h3Ywv1%2BCoX3gLBabdTZs9ybsm4t4ys%3D&amp;reserved=3D0
> step 4: Add mailbox declaration in VirtIO subnode =3D>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu=
b.
> com%2Farnopo%2Flinux%2Fcommits%2Fstep4-virtio-mailboxes&amp;data=3D0
> 4%7C01%7Cpeng.fan%40nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2
> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637788110748757
> 786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3D75hApOwihqMZ
> UUKz1VcitY2VPDc6KAIwAvH8enEZOPY%3D&amp;reserved=3D0
>=20
> Arnaud Pouliquen (4):
>   remoteproc: core: Introduce virtio device add/remove functions
>   remoteproc: core: Introduce rproc_register_rvdev function
>   remoteproc: Move rproc_vdev management to remoteproc_virtio.c
>   remoteproc: virtio: Create platform device for the remoteproc_virtio
>=20
>  drivers/remoteproc/remoteproc_core.c     | 159 +++----------------
>  drivers/remoteproc/remoteproc_internal.h |  33 +++-
>  drivers/remoteproc/remoteproc_virtio.c   | 193
> ++++++++++++++++++++---
>  include/linux/remoteproc.h               |   6 +-
>  4 files changed, 227 insertions(+), 164 deletions(-)
>=20
> --
> 2.25.1