> Subject: Re: [RFC PATCH v3 0/4] remoteproc: restructure the remoteproc > VirtIO device > > > > On 2/15/22 09:34, Peng Fan wrote: > >> Subject: [RFC PATCH v3 0/4] remoteproc: restructure the remoteproc > >> VirtIO device > >> > >> 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/deletion, the patchset has been reworked. > >> - Introduction in the first patch, of rproc_vdev_data structure > >> which allows 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 > >> virtio platform device. > >> - In addition to the previous version, the management of the vring > >> lifecycle has been fully > >> migrated to the remoteproc_virtio.c (rproc_parse_vring, > >> rproc_alloc_vring, > >> rproc_free_vring) > >> > >> [1] > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkm > >> > l.or%2F&data=04%7C01%7Cpeng.fan%40nxp.com%7C31ba612e9d444a > 845cbf0 > >> > 8d9f073f744%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63780 > 5203140 > >> > 739333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 > luMzIiLC > >> > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MDamNuBkyFebgG > BuP5shcU9 > >> aw%2FdMuM9GBTEEzffQQkA%3D&reserved=0 > >> > g%2Flkml%2F2021%2F12%2F22%2F111&data=04%7C01%7Cpeng.fan%4 > >> > 0nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2%7C686ea1d3bc2b4c6fa > >> > 92cd99c5c301635%7C0%7C0%7C637788110748757786%7CUnknown%7CT > >> > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > >> > JXVCI6Mn0%3D%7C3000&sdata=bFfSxpPMpPRGYcMBcwxaQ152mRzf3c > >> fwoFPjiJ0SIgw%3D&reserved=0 > >> > >> Patchset description: > >> > >> This series is a part of the work initiated a long time ago in the > >> series > >> "remoteproc: Decorelate virtio from core"[2] > >> > >> 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? > > The resource table still exists. The main difference is that the virtio devices > would be predefined in the DT with their own resources ( memories , > mailboxes,...) No need to inherit from the rproc device. > > > On resource table parsing, the remoteproc looks first for pre registered > rproc_virtio devices. If found then it uses it. Else it instantiates a new one > (legacy method). > > > > > >> - 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? > > Yes virtio-i2c is a bus, There is different methods to declare I2C device on a > bus[1]. > > In ST we rely on DT to statically declare an I2C device,as child of the I2C > adapter node. > I haven't implemented the virtio-I2C part yet, but it would make sense to > have such an implementation. I misunderstood. Virtio-i2c bus with I2C device in DT is preferred. > > Which alternative have you in mind? No. NXP use same method, we have a rpmsg i2c driver, rpmsg i2c bus node and i2c device in DT. Regards, Peng. > > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > kernel.org%2Fdoc%2Fhtml%2Flatest%2Fi2c%2Finstantiating-devices.html&a > mp;data=04%7C01%7Cpeng.fan%40nxp.com%7C31ba612e9d444a845cbf08d > 9f073f744%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6378052 > 03140739333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C1S > BPEtDhp7Y9XLB8wHgTLaQ%2BBE6T%2BD8eUr34SFRJYQ%3D&reserved > =0 > > Thanks, > Arnaud > > > > > Thanks, > > Peng. > > > >> - Keep the legacy working! > >> - Try to improve the picture about concerns reported by Christoph > >> Hellwing [3][4] > >> > >> [2] > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkm > >> > l.or%2F&data=04%7C01%7Cpeng.fan%40nxp.com%7C31ba612e9d444a > 845cbf0 > >> > 8d9f073f744%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63780 > 5203140 > >> > 739333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 > luMzIiLC > >> > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MDamNuBkyFebgG > BuP5shcU9 > >> aw%2FdMuM9GBTEEzffQQkA%3D&reserved=0 > >> > g%2Flkml%2F2020%2F4%2F16%2F1817&data=04%7C01%7Cpeng.fan%4 > >> > 0nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2%7C686ea1d3bc2b4c6fa > >> > 92cd99c5c301635%7C0%7C0%7C637788110748757786%7CUnknown%7CT > >> > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > >> > JXVCI6Mn0%3D%7C3000&sdata=O2BZw5PCY19eD5xMGxrGUKC%2Fty1 > >> Sdc3LE6rhK4cSXvs%3D&reserved=0 > >> [3] > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkm > >> > l.or%2F&data=04%7C01%7Cpeng.fan%40nxp.com%7C31ba612e9d444a > 845cbf0 > >> > 8d9f073f744%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63780 > 5203140 > >> > 739333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 > luMzIiLC > >> > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MDamNuBkyFebgG > BuP5shcU9 > >> aw%2FdMuM9GBTEEzffQQkA%3D&reserved=0 > >> > g%2Flkml%2F2021%2F6%2F23%2F607&data=04%7C01%7Cpeng.fan%40 > >> > nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2%7C686ea1d3bc2b4c6fa9 > >> > 2cd99c5c301635%7C0%7C0%7C637788110748757786%7CUnknown%7CTW > >> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > >> > VCI6Mn0%3D%7C3000&sdata=xqX50iDeL%2BtFBOgyADnEUE5HH4gogK > >> C0MwyqZSxVqNo%3D&reserved=0 > >> [4] > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat > >> ch > work.kernel.org%2Fproject%2Flinux-remoteproc%2Fpatch%2FAOKowLclCbO > >> > CKxyiJ71WeNyuAAj2q8EUtxrXbyky5E%40cp7-web-042.plabs.ch%2F&da > >> > ta=04%7C01%7Cpeng.fan%40nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e85 > >> > 5e2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637788110748 > >> > 757786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 > >> > luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mvSm3wM > >> LgQ%2BDFhqjXIkG8de58zFjwPSURzw55JhGNaA%3D&reserved=0 > >> > >> In term of device tree this would result in such hiearchy (stm32mp1 > >> example with 2 virtio RPMSG): > >> > >> m4_rproc: m4@10000000 { > >> compatible = "st,stm32mp1-m4"; > >> reg = <0x10000000 0x40000>, > >> <0x30000000 0x40000>, > >> <0x38000000 0x10000>; > >> memory-region = <&retram>, <&mcuram>,<&mcuram2>; > >> mboxes = <&ipcc 2>, <&ipcc 3>; > >> mbox-names = "shutdown", "detach"; > >> status = "okay"; > >> > >> #address-cells = <1>; > >> #size-cells = <0>; > >> > >> vdev@0 { > >> compatible = "rproc-virtio"; > >> reg = <0>; > >> virtio,id = <7>; /* RPMSG */ > >> memory-region = <&vdev0vring0>, <&vdev0vring1>, > <&vdev0buffer>; > >> mboxes = <&ipcc 0>, <&ipcc 1>; > >> mbox-names = "vq0", "vq1"; > >> status = "okay"; > >> }; > >> > >> vdev@1 { > >> compatible = "rproc-virtio"; > >> reg = <1>; > >> virtio,id = <7>; /*RPMSG */ > >> memory-region = <&vdev1vring0>, <&vdev1vring1>, > <&vdev1buffer>; > >> mboxes = <&ipcc 4>, <&ipcc 5>; > >> mbox-names = "vq0", "vq1"; > >> status = "okay"; > >> }; > >> }; > >> > >> 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 , => > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > >> > com%2Farnopo%2Flinux%2Fcommits%2Fstep2-virtio-in-DT&data=04%7 > >> > C01%7Cpeng.fan%40nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2%7C > >> > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637788110748757786 > >> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > zIiL > >> > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X%2B462681gcxe6 > >> 2GP%2BV7ji2nef%2FuTbQVvIlddcMQwtmg%3D&reserved=0 > >> step 3: Add memory declaration in VirtIO subnode => > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > >> > com%2Farnopo%2Flinux%2Fcommits%2Fstep3-virtio-memories&data=0 > >> > 4%7C01%7Cpeng.fan%40nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2 > >> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637788110748 > 757 > >> > 786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > >> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eMlXgCgrV6l46 > >> h3Ywv1%2BCoX3gLBabdTZs9ybsm4t4ys%3D&reserved=0 > >> step 4: Add mailbox declaration in VirtIO subnode => > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > >> > com%2Farnopo%2Flinux%2Fcommits%2Fstep4-virtio-mailboxes&data=0 > >> > 4%7C01%7Cpeng.fan%40nxp.com%7C9e663eefc30a4fbb1fdb08d9e0e855e2 > >> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637788110748 > 757 > >> > 786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > >> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=75hApOwihqMZ > >> UUKz1VcitY2VPDc6KAIwAvH8enEZOPY%3D&reserved=0 > >> > >> 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 > >> > >> 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(-) > >> > >> -- > >> 2.25.1 > >