Hi Oleksij: > -----Original Message----- > From: Oleksij Rempel [mailto:o.rempel@xxxxxxxxxxxxxx] > Sent: 2019年7月8日 19:03 > To: Richard Zhu <hongxing.zhu@xxxxxxx>; ohad@xxxxxxxxxx; > bjorn.andersson@xxxxxxxxxx; linux-remoteproc@xxxxxxxxxxxxxxx > Cc: loic.pallardy@xxxxxx; arnaud.pouliquen@xxxxxx; Fabien DESSENNE > <fabien.dessenne@xxxxxx>; elder@xxxxxxxxxx; > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [EXT] Re: [RFC 2/2] rpmsg: imx: add the initial imx rpmsg support > > Caution: EXT Email > > Hi Richard, > > On 08.07.19 12:17, Richard Zhu wrote: > > Hi Oleksij: > > Thanks for your comments. > > > > > >> -----Original Message----- > >> From: Oleksij Rempel [mailto:o.rempel@xxxxxxxxxxxxxx] > >> Sent: 2019年7月4日 17:36 > >> To: Richard Zhu <hongxing.zhu@xxxxxxx>; ohad@xxxxxxxxxx; > >> bjorn.andersson@xxxxxxxxxx; linux-remoteproc@xxxxxxxxxxxxxxx > >> Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Fabien DESSENNE > >> <fabien.dessenne@xxxxxx>; loic.pallardy@xxxxxx; > >> arnaud.pouliquen@xxxxxx; s-anna@xxxxxx; elder@xxxxxxxxxx > >> Subject: [EXT] Re: [RFC 2/2] rpmsg: imx: add the initial imx rpmsg > >> support > >> > >> Caution: EXT Email > >> > >> Hi Richard, > >> > >> On 01.07.19 10:34, Richard Zhu wrote: > >>> Based on "virtio_rpmsg_bus" driver, This patch-set is used to set up > >>> the communication mechanism between A core and M core on i.MX AMP > >> SOCs. > >>> > >>> Add the initial imx rpmsg support glue driver and one pingpong demo, > >>> demonstrated the data transactions between A core and remote M core. > >>> Distributed framework is used in IMX RPMSG implementation, refer to > >>> the following requirements: > >>> - The CAN functions contained in M core and RTOS should be ready > and > >>> complete functional in 50ms after AMP system is turned on. > >>> - Partition reset. System wouldn't be stalled by the exceptions (e.x > >>> the reset triggered by the system hang) occurred at the other > side. > >>> And the RPMSG mechanism should be recovered automactilly > after > >> the > >>> partition reset is completed. > >>> In this scenario, the M core and RTOS would be kicked off by > >>> bootloader firstly, then A core and Linux would be loaded later. > >>> Both M core/RTOS and A core/Linux are running independly. > >>> > >>> One physical memory region used to store the vring is mandatory > >>> required to pre-reserved and well-knowned by both A core and M core > >> > >> I don't see any thing imx specific in this patch. We already have > >> remoteproc which would parse firmware header and create needed > >> devices. This driver is only needed for the case where firmware was stared > by the bootloader. > >> > > [Richard Zhu] Bootloader starts the firmware is mandatory required in > > these scenario refer to the reasons listed in the commit. > > Thus, the distributed framework has to be used, and both A core/Linux > > and remote core/RTOS works independently. > > > >> I personally would prefer to have generic driver or extend the > >> remoteproc framework. So we can notify kernel about work already done > by bootloader. > >> > > [Richard Zhu] Thanks for your suggestions. > > Regarding to my understand, it seems that master/slave mode is used in the > remoteproc currently. > > A core/Linux acts as master, to controls/manipulates remote core/RTOS. > > It isn't applicable for the scenario described by this patch-set. > > > >> In general, some more issues should be solved: > >> - Handle or not touch idle clocks for different node used by M core > >> and not main system. > >> - pin control > >> - regulators > >> > >> ST devs already tried to solve this issues by creating "remoteproc: > >> add system resource manager device" patch. I don't know what is > >> current state of it (/me adding ST devs to CC). > >> > > [Richard Zhu] Yes, it is. Many contributions have been made by Fabien. > > IMHO, there are some different behaviors on iMX8QXP/QM platforms, the > > resources (e.x IP modules) had been assigned and managed by the > XRDC. > > In the other words, the HW resources would be assigned and managed > would > > be transparent to SW. > > > > Thus, both A core/Linux and M core/RTOS can work real independently. > > System wouldn't be stalled by the exceptions (e.x the reset triggered > > by the system hang) occurred at the other side. And the RPMSG mechanism > should > > be recovered automatically after the partition reset is completed. > > It is exactly the way I did understood it in the firs mail. Any way, i'm ok with > this driver. Just rename imx to some thing generic. This driver can and will be > reused on other platforms as well. [Richard Zhu] Thanks for your understand. Would change to generic name if this patch-set is acceptable. Thank you. Best Regards Richard Zhu > > Kind regards, > Oleksij Rempel > > -- > Pengutronix e.K. | > | > Industrial Linux Solutions | > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.p > engutronix.de%2F&data=02%7C01%7Chongxing.zhu%40nxp.com%7C85f > 5637c82ce4ce80f0508d70393d48e%7C686ea1d3bc2b4c6fa92cd99c5c30163 > 5%7C0%7C0%7C636981805773245171&sdata=%2BZrjvkLWF7agguOkvK > iWiyaK743oI1V9YmpLcyRrgJQ%3D&reserved=0 | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 > | > Amtsgericht Hildesheim, HRA 2686 | Fax: > +49-5121-206917-5555 |
