RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Jassi, > -Original Message- > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > Sent: Thursday, July 12, 2018 1:01 AM > To: A.s. Dong > Cc: Sascha Hauer ; linux-arm- > ker...@lists.infradead.org; donga...@gmail.com; linux- > ker...@vger.kernel.org; Oleksij Rempel ; dl- > linux-imx ; ker...@pengutronix.de; Fabio Estevam > ; shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > bcm seems is using peek to receive data, not only checking the data > > availability, right? > > drivers/mailbox/bcm-flexrm-mailbox.c > > > As I said, if fetching data from remote don't need to sleep, you can call > mbox_chan_received_data() from peek(). Otherwise not. Got it. So it seems work for i.MX. Thanks. Regards Dong Aisheng
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Jassi, > -Original Message- > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > Sent: Thursday, July 12, 2018 1:01 AM > To: A.s. Dong > Cc: Sascha Hauer ; linux-arm- > ker...@lists.infradead.org; donga...@gmail.com; linux- > ker...@vger.kernel.org; Oleksij Rempel ; dl- > linux-imx ; ker...@pengutronix.de; Fabio Estevam > ; shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > bcm seems is using peek to receive data, not only checking the data > > availability, right? > > drivers/mailbox/bcm-flexrm-mailbox.c > > > As I said, if fetching data from remote don't need to sleep, you can call > mbox_chan_received_data() from peek(). Otherwise not. Got it. So it seems work for i.MX. Thanks. Regards Dong Aisheng
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
On Wed, Jul 11, 2018 at 10:11 PM, A.s. Dong wrote: > Hi Jassi, > >> -Original Message- >> From: Jassi Brar [mailto:jassisinghb...@gmail.com] >> Sent: Thursday, July 12, 2018 12:32 AM >> To: A.s. Dong >> Cc: Sascha Hauer ; linux-arm- >> ker...@lists.infradead.org; donga...@gmail.com; linux- >> ker...@vger.kernel.org; Oleksij Rempel ; dl- >> linux-imx ; ker...@pengutronix.de; Fabio Estevam >> ; shawn...@kernel.org >> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> On Wed, Jul 11, 2018 at 6:28 PM, A.s. Dong wrote: >> > Hi Jassi, >> > >> >> -Original Message- >> >> From: Jassi Brar [mailto:jassisinghb...@gmail.com] >> >> Sent: Wednesday, July 11, 2018 6:44 PM >> >> To: A.s. Dong >> >> Cc: Sascha Hauer ; linux-arm- >> >> ker...@lists.infradead.org; donga...@gmail.com; linux- >> >> ker...@vger.kernel.org; Oleksij Rempel ; dl- >> >> linux-imx ; ker...@pengutronix.de; Fabio Estevam >> >> ; shawn...@kernel.org >> >> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> >> >> On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong >> wrote: >> >> > >> >> > > -Original Message- >> >> > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] >> >> > > Sent: Wednesday, July 11, 2018 3:55 PM >> >> > > To: A.s. Dong >> >> > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; >> >> > > Jassi Brar ; >> >> > > linux-kernel@vger.kernel.org; Oleksij Rempel >> >> > > ; dl-linux-imx ; >> >> > > ker...@pengutronix.de; Fabio Estevam ; >> >> > > shawn...@kernel.org >> >> > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> > > >> >> > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: >> >> > > > Hi Sascha, >> >> > > > >> >> > > > > -Original Message- >> >> > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] >> >> > > > > Sent: Tuesday, July 10, 2018 10:20 PM >> >> > > > > To: A.s. Dong >> >> > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; >> >> > > > > Jassi Brar ; >> >> > > > > linux-kernel@vger.kernel.org; Oleksij Rempel >> >> > > > > ; dl-linux-imx ; >> >> > > > > ker...@pengutronix.de; Fabio Estevam >> ; >> >> > > > > shawn...@kernel.org >> >> > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> > > > > >> >> > > > > Hi, >> >> > > > > >> >> > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: >> >> > > > > > This is used for i.MX multi core communication. >> >> > > > > > e.g. A core to SCU firmware(M core) on MX8. >> >> > > > > > >> >> > > > > > Tx is using polling mode while Rx is interrupt driven and >> >> > > > > > schedule a hrtimer to receive remain words if have more >> >> > > > > > than >> >> > > > > > 4 words. >> >> > > > > >> >> > > > > You told us that using interrupts is not possible due to >> >> > > > > miserable performance, we then provided you a way with which >> >> > > > > you >> >> could poll. >> >> > > > > Why are you using interrupts now? >> >> > > > > >> >> > > > >> >> > > > Because mailbox framework does not support sync rx now, I think >> >> > > > we do not need to wait for that feature done first as it's >> >> > > > independent and separate features of framework. >> >> > > >> >> > > You can wait forever for this feature, nobody will add it for you. >> >> > > It's up to you to add support for that feature. Who else should >> >> > > add this >> >> feature if not you? >> >> > > And when will you add that feature if not now when you actually need >> it? >> >> > > It is common practice that you adjust the frame
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
On Wed, Jul 11, 2018 at 10:11 PM, A.s. Dong wrote: > Hi Jassi, > >> -Original Message- >> From: Jassi Brar [mailto:jassisinghb...@gmail.com] >> Sent: Thursday, July 12, 2018 12:32 AM >> To: A.s. Dong >> Cc: Sascha Hauer ; linux-arm- >> ker...@lists.infradead.org; donga...@gmail.com; linux- >> ker...@vger.kernel.org; Oleksij Rempel ; dl- >> linux-imx ; ker...@pengutronix.de; Fabio Estevam >> ; shawn...@kernel.org >> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> On Wed, Jul 11, 2018 at 6:28 PM, A.s. Dong wrote: >> > Hi Jassi, >> > >> >> -Original Message- >> >> From: Jassi Brar [mailto:jassisinghb...@gmail.com] >> >> Sent: Wednesday, July 11, 2018 6:44 PM >> >> To: A.s. Dong >> >> Cc: Sascha Hauer ; linux-arm- >> >> ker...@lists.infradead.org; donga...@gmail.com; linux- >> >> ker...@vger.kernel.org; Oleksij Rempel ; dl- >> >> linux-imx ; ker...@pengutronix.de; Fabio Estevam >> >> ; shawn...@kernel.org >> >> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> >> >> On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong >> wrote: >> >> > >> >> > > -Original Message- >> >> > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] >> >> > > Sent: Wednesday, July 11, 2018 3:55 PM >> >> > > To: A.s. Dong >> >> > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; >> >> > > Jassi Brar ; >> >> > > linux-kernel@vger.kernel.org; Oleksij Rempel >> >> > > ; dl-linux-imx ; >> >> > > ker...@pengutronix.de; Fabio Estevam ; >> >> > > shawn...@kernel.org >> >> > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> > > >> >> > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: >> >> > > > Hi Sascha, >> >> > > > >> >> > > > > -Original Message- >> >> > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] >> >> > > > > Sent: Tuesday, July 10, 2018 10:20 PM >> >> > > > > To: A.s. Dong >> >> > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; >> >> > > > > Jassi Brar ; >> >> > > > > linux-kernel@vger.kernel.org; Oleksij Rempel >> >> > > > > ; dl-linux-imx ; >> >> > > > > ker...@pengutronix.de; Fabio Estevam >> ; >> >> > > > > shawn...@kernel.org >> >> > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> > > > > >> >> > > > > Hi, >> >> > > > > >> >> > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: >> >> > > > > > This is used for i.MX multi core communication. >> >> > > > > > e.g. A core to SCU firmware(M core) on MX8. >> >> > > > > > >> >> > > > > > Tx is using polling mode while Rx is interrupt driven and >> >> > > > > > schedule a hrtimer to receive remain words if have more >> >> > > > > > than >> >> > > > > > 4 words. >> >> > > > > >> >> > > > > You told us that using interrupts is not possible due to >> >> > > > > miserable performance, we then provided you a way with which >> >> > > > > you >> >> could poll. >> >> > > > > Why are you using interrupts now? >> >> > > > > >> >> > > > >> >> > > > Because mailbox framework does not support sync rx now, I think >> >> > > > we do not need to wait for that feature done first as it's >> >> > > > independent and separate features of framework. >> >> > > >> >> > > You can wait forever for this feature, nobody will add it for you. >> >> > > It's up to you to add support for that feature. Who else should >> >> > > add this >> >> feature if not you? >> >> > > And when will you add that feature if not now when you actually need >> it? >> >> > > It is common practice that you adjust the frame
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Jassi, > -Original Message- > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > Sent: Thursday, July 12, 2018 12:32 AM > To: A.s. Dong > Cc: Sascha Hauer ; linux-arm- > ker...@lists.infradead.org; donga...@gmail.com; linux- > ker...@vger.kernel.org; Oleksij Rempel ; dl- > linux-imx ; ker...@pengutronix.de; Fabio Estevam > ; shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > On Wed, Jul 11, 2018 at 6:28 PM, A.s. Dong wrote: > > Hi Jassi, > > > >> -Original Message- > >> From: Jassi Brar [mailto:jassisinghb...@gmail.com] > >> Sent: Wednesday, July 11, 2018 6:44 PM > >> To: A.s. Dong > >> Cc: Sascha Hauer ; linux-arm- > >> ker...@lists.infradead.org; donga...@gmail.com; linux- > >> ker...@vger.kernel.org; Oleksij Rempel ; dl- > >> linux-imx ; ker...@pengutronix.de; Fabio Estevam > >> ; shawn...@kernel.org > >> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > >> > >> On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong > wrote: > >> > > >> > > -Original Message- > >> > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > >> > > Sent: Wednesday, July 11, 2018 3:55 PM > >> > > To: A.s. Dong > >> > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; > >> > > Jassi Brar ; > >> > > linux-kernel@vger.kernel.org; Oleksij Rempel > >> > > ; dl-linux-imx ; > >> > > ker...@pengutronix.de; Fabio Estevam ; > >> > > shawn...@kernel.org > >> > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > >> > > > >> > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: > >> > > > Hi Sascha, > >> > > > > >> > > > > -Original Message- > >> > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > >> > > > > Sent: Tuesday, July 10, 2018 10:20 PM > >> > > > > To: A.s. Dong > >> > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; > >> > > > > Jassi Brar ; > >> > > > > linux-kernel@vger.kernel.org; Oleksij Rempel > >> > > > > ; dl-linux-imx ; > >> > > > > ker...@pengutronix.de; Fabio Estevam > ; > >> > > > > shawn...@kernel.org > >> > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > >> > > > > > >> > > > > Hi, > >> > > > > > >> > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > >> > > > > > This is used for i.MX multi core communication. > >> > > > > > e.g. A core to SCU firmware(M core) on MX8. > >> > > > > > > >> > > > > > Tx is using polling mode while Rx is interrupt driven and > >> > > > > > schedule a hrtimer to receive remain words if have more > >> > > > > > than > >> > > > > > 4 words. > >> > > > > > >> > > > > You told us that using interrupts is not possible due to > >> > > > > miserable performance, we then provided you a way with which > >> > > > > you > >> could poll. > >> > > > > Why are you using interrupts now? > >> > > > > > >> > > > > >> > > > Because mailbox framework does not support sync rx now, I think > >> > > > we do not need to wait for that feature done first as it's > >> > > > independent and separate features of framework. > >> > > > >> > > You can wait forever for this feature, nobody will add it for you. > >> > > It's up to you to add support for that feature. Who else should > >> > > add this > >> feature if not you? > >> > > And when will you add that feature if not now when you actually need > it? > >> > > It is common practice that you adjust the frameworks to your > >> > > needs rather than working around them. > >> > > > >> > > >> > I'm willing to add it. Just because you said Jassi already had the > >> > idea on how to Implement it and does not add much complexity. So I > >> > just > >> want to see his patches. > >> > But if he did not work on it
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Jassi, > -Original Message- > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > Sent: Thursday, July 12, 2018 12:32 AM > To: A.s. Dong > Cc: Sascha Hauer ; linux-arm- > ker...@lists.infradead.org; donga...@gmail.com; linux- > ker...@vger.kernel.org; Oleksij Rempel ; dl- > linux-imx ; ker...@pengutronix.de; Fabio Estevam > ; shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > On Wed, Jul 11, 2018 at 6:28 PM, A.s. Dong wrote: > > Hi Jassi, > > > >> -Original Message- > >> From: Jassi Brar [mailto:jassisinghb...@gmail.com] > >> Sent: Wednesday, July 11, 2018 6:44 PM > >> To: A.s. Dong > >> Cc: Sascha Hauer ; linux-arm- > >> ker...@lists.infradead.org; donga...@gmail.com; linux- > >> ker...@vger.kernel.org; Oleksij Rempel ; dl- > >> linux-imx ; ker...@pengutronix.de; Fabio Estevam > >> ; shawn...@kernel.org > >> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > >> > >> On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong > wrote: > >> > > >> > > -Original Message- > >> > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > >> > > Sent: Wednesday, July 11, 2018 3:55 PM > >> > > To: A.s. Dong > >> > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; > >> > > Jassi Brar ; > >> > > linux-kernel@vger.kernel.org; Oleksij Rempel > >> > > ; dl-linux-imx ; > >> > > ker...@pengutronix.de; Fabio Estevam ; > >> > > shawn...@kernel.org > >> > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > >> > > > >> > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: > >> > > > Hi Sascha, > >> > > > > >> > > > > -Original Message- > >> > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > >> > > > > Sent: Tuesday, July 10, 2018 10:20 PM > >> > > > > To: A.s. Dong > >> > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; > >> > > > > Jassi Brar ; > >> > > > > linux-kernel@vger.kernel.org; Oleksij Rempel > >> > > > > ; dl-linux-imx ; > >> > > > > ker...@pengutronix.de; Fabio Estevam > ; > >> > > > > shawn...@kernel.org > >> > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > >> > > > > > >> > > > > Hi, > >> > > > > > >> > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > >> > > > > > This is used for i.MX multi core communication. > >> > > > > > e.g. A core to SCU firmware(M core) on MX8. > >> > > > > > > >> > > > > > Tx is using polling mode while Rx is interrupt driven and > >> > > > > > schedule a hrtimer to receive remain words if have more > >> > > > > > than > >> > > > > > 4 words. > >> > > > > > >> > > > > You told us that using interrupts is not possible due to > >> > > > > miserable performance, we then provided you a way with which > >> > > > > you > >> could poll. > >> > > > > Why are you using interrupts now? > >> > > > > > >> > > > > >> > > > Because mailbox framework does not support sync rx now, I think > >> > > > we do not need to wait for that feature done first as it's > >> > > > independent and separate features of framework. > >> > > > >> > > You can wait forever for this feature, nobody will add it for you. > >> > > It's up to you to add support for that feature. Who else should > >> > > add this > >> feature if not you? > >> > > And when will you add that feature if not now when you actually need > it? > >> > > It is common practice that you adjust the frameworks to your > >> > > needs rather than working around them. > >> > > > >> > > >> > I'm willing to add it. Just because you said Jassi already had the > >> > idea on how to Implement it and does not add much complexity. So I > >> > just > >> want to see his patches. > >> > But if he did not work on it
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
On Wed, Jul 11, 2018 at 6:28 PM, A.s. Dong wrote: > Hi Jassi, > >> -Original Message- >> From: Jassi Brar [mailto:jassisinghb...@gmail.com] >> Sent: Wednesday, July 11, 2018 6:44 PM >> To: A.s. Dong >> Cc: Sascha Hauer ; linux-arm- >> ker...@lists.infradead.org; donga...@gmail.com; linux- >> ker...@vger.kernel.org; Oleksij Rempel ; dl- >> linux-imx ; ker...@pengutronix.de; Fabio Estevam >> ; shawn...@kernel.org >> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong wrote: >> > >> > > -Original Message- >> > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] >> > > Sent: Wednesday, July 11, 2018 3:55 PM >> > > To: A.s. Dong >> > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi >> > > Brar ; linux-kernel@vger.kernel.org; >> > > Oleksij Rempel ; dl-linux-imx >> > > ; ker...@pengutronix.de; Fabio Estevam >> > > ; shawn...@kernel.org >> > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> > > >> > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: >> > > > Hi Sascha, >> > > > >> > > > > -Original Message- >> > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] >> > > > > Sent: Tuesday, July 10, 2018 10:20 PM >> > > > > To: A.s. Dong >> > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; >> > > > > Jassi Brar ; >> > > > > linux-kernel@vger.kernel.org; Oleksij Rempel >> > > > > ; dl-linux-imx ; >> > > > > ker...@pengutronix.de; Fabio Estevam ; >> > > > > shawn...@kernel.org >> > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> > > > > >> > > > > Hi, >> > > > > >> > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: >> > > > > > This is used for i.MX multi core communication. >> > > > > > e.g. A core to SCU firmware(M core) on MX8. >> > > > > > >> > > > > > Tx is using polling mode while Rx is interrupt driven and >> > > > > > schedule a hrtimer to receive remain words if have more than >> > > > > > 4 words. >> > > > > >> > > > > You told us that using interrupts is not possible due to >> > > > > miserable performance, we then provided you a way with which you >> could poll. >> > > > > Why are you using interrupts now? >> > > > > >> > > > >> > > > Because mailbox framework does not support sync rx now, I think we >> > > > do not need to wait for that feature done first as it's >> > > > independent and separate features of framework. >> > > >> > > You can wait forever for this feature, nobody will add it for you. >> > > It's up to you to add support for that feature. Who else should add this >> feature if not you? >> > > And when will you add that feature if not now when you actually need it? >> > > It is common practice that you adjust the frameworks to your needs >> > > rather than working around them. >> > > >> > >> > I'm willing to add it. Just because you said Jassi already had the >> > idea on how to Implement it and does not add much complexity. So I just >> want to see his patches. >> > But if he did not work on it, I can also help on it. >> > >> I am not much aware of the history of this conversation... but it seems you >> need to make use of mbox_chan_ops.peek_data(). >> >> If not that, please let me know the requirement. >> > > Thanks for the suggestion. > It looks to me may work. > > From the definition, it seems it's used to pull data from remote side. > /** > * mbox_client_peek_data - A way for client driver to pull data > * received from remote by the controller. > * @chan: Mailbox channel assigned to this client. > * > * A poke to controller driver for any received data. > * The data is actually passed onto client via the > * mbox_chan_received_data() > * The call can be made from atomic context, so the controller's > * implementation of peek_data() must not sleep. > * > * Return: True, if controller has, and is going to push after this, > *
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
On Wed, Jul 11, 2018 at 6:28 PM, A.s. Dong wrote: > Hi Jassi, > >> -Original Message- >> From: Jassi Brar [mailto:jassisinghb...@gmail.com] >> Sent: Wednesday, July 11, 2018 6:44 PM >> To: A.s. Dong >> Cc: Sascha Hauer ; linux-arm- >> ker...@lists.infradead.org; donga...@gmail.com; linux- >> ker...@vger.kernel.org; Oleksij Rempel ; dl- >> linux-imx ; ker...@pengutronix.de; Fabio Estevam >> ; shawn...@kernel.org >> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> >> On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong wrote: >> > >> > > -Original Message- >> > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] >> > > Sent: Wednesday, July 11, 2018 3:55 PM >> > > To: A.s. Dong >> > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi >> > > Brar ; linux-kernel@vger.kernel.org; >> > > Oleksij Rempel ; dl-linux-imx >> > > ; ker...@pengutronix.de; Fabio Estevam >> > > ; shawn...@kernel.org >> > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> > > >> > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: >> > > > Hi Sascha, >> > > > >> > > > > -Original Message- >> > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] >> > > > > Sent: Tuesday, July 10, 2018 10:20 PM >> > > > > To: A.s. Dong >> > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; >> > > > > Jassi Brar ; >> > > > > linux-kernel@vger.kernel.org; Oleksij Rempel >> > > > > ; dl-linux-imx ; >> > > > > ker...@pengutronix.de; Fabio Estevam ; >> > > > > shawn...@kernel.org >> > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support >> > > > > >> > > > > Hi, >> > > > > >> > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: >> > > > > > This is used for i.MX multi core communication. >> > > > > > e.g. A core to SCU firmware(M core) on MX8. >> > > > > > >> > > > > > Tx is using polling mode while Rx is interrupt driven and >> > > > > > schedule a hrtimer to receive remain words if have more than >> > > > > > 4 words. >> > > > > >> > > > > You told us that using interrupts is not possible due to >> > > > > miserable performance, we then provided you a way with which you >> could poll. >> > > > > Why are you using interrupts now? >> > > > > >> > > > >> > > > Because mailbox framework does not support sync rx now, I think we >> > > > do not need to wait for that feature done first as it's >> > > > independent and separate features of framework. >> > > >> > > You can wait forever for this feature, nobody will add it for you. >> > > It's up to you to add support for that feature. Who else should add this >> feature if not you? >> > > And when will you add that feature if not now when you actually need it? >> > > It is common practice that you adjust the frameworks to your needs >> > > rather than working around them. >> > > >> > >> > I'm willing to add it. Just because you said Jassi already had the >> > idea on how to Implement it and does not add much complexity. So I just >> want to see his patches. >> > But if he did not work on it, I can also help on it. >> > >> I am not much aware of the history of this conversation... but it seems you >> need to make use of mbox_chan_ops.peek_data(). >> >> If not that, please let me know the requirement. >> > > Thanks for the suggestion. > It looks to me may work. > > From the definition, it seems it's used to pull data from remote side. > /** > * mbox_client_peek_data - A way for client driver to pull data > * received from remote by the controller. > * @chan: Mailbox channel assigned to this client. > * > * A poke to controller driver for any received data. > * The data is actually passed onto client via the > * mbox_chan_received_data() > * The call can be made from atomic context, so the controller's > * implementation of peek_data() must not sleep. > * > * Return: True, if controller has, and is going to push after this, > *
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi A.S > -Original Message- > From: A.s. Dong > Sent: 2018年7月11日 15:30 > To: Sascha Hauer > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > ; linux-kernel@vger.kernel.org; Oleksij Rempel > ; dl-linux-imx ; > ker...@pengutronix.de; Fabio Estevam ; > shawn...@kernel.org > Subject: RE: [PATCH V4 3/5] mailbox: imx: add imx mu support > > Hi Sascha, > > > -Original Message- > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > Sent: Tuesday, July 10, 2018 10:20 PM > > To: A.s. Dong > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi > > Brar ; linux-kernel@vger.kernel.org; Oleksij > > Rempel ; dl-linux-imx ; > > ker...@pengutronix.de; Fabio Estevam ; > > shawn...@kernel.org > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > Hi, > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > > This is used for i.MX multi core communication. > > > e.g. A core to SCU firmware(M core) on MX8. > > > > > > Tx is using polling mode while Rx is interrupt driven and schedule a > > > hrtimer to receive remain words if have more than > > > 4 words. > > > > You told us that using interrupts is not possible due to miserable > > performance, we then provided you a way with which you could poll. > > Why are you using interrupts now? > > > > Because mailbox framework does not support sync rx now, I think we do not > need to wait for that feature done first as it's independent and separate > features of framework. > > So for now, we're just using the common way in kernel as arm scpi and ti sci. > When framework supports it, we can easily switch to it. > > I optimized the performance a bit by removing the unnecessary memcopy > between tx/tx messages. The test result of booting time shows there's no > obvious regressions. I'm not sure whether it's due to we're booting a minimum > system or the extra cost is very minor to be noticed due to not too much cmds > sent during booting. > (Copy Peng to comments more as he tried and reported that performance drop > with vendor tree) The txpoll_period is set 1, the minimum is 1ms. So it introduces latency in the initial mailbox for SCU communication. Regards, Peng > > From the time measurement of sc_call_rpc, we can see that most rpc command > In polling mode can finish within 10us and very rare ones over 20us. > If switched to irq mode, those 10us cmds will change to about 20us. > > But the overall booting time did not increase much. Maybe the irq mode also > saves some CPU MIPS to execute other works in parallel? > > > We also suggested a way how the SCU mode could be integrated into the > > generic MU support driver Oleksij posted and now you send a driver > > which uses the same name as Oleksijs driver, but it only and > > exclusively works in SCU mode. This doesn't bring us forward. > > > > Can Oleksij's patch be implemented against this one? > As I remember you said we've still not determined whether Oleksij's approach > is > the most suitable way and it's still under discussion. > (Actually TI's approach looks better which is more simiar as SCU way?) > > Furthermore, from this patch, you will notice that Oleksij's patch almost did > not > work for SCU at all. I have to totally rewrite one for SCU. > So I did not write against his patch as it does not help. > And Oleksij's patch is quite simple while the SCU one is much complicated than > his one. So we probably better get SCU done first. > > > We suggested a binding that allows coexisting of the SCU mode and the > > generic mode of the MU by putting the mode information into the second > > mbox-cell. Why don't you use this? > > > > You mean this? > +#define IMX_MU_CHANNEL0 0 > +#define IMX_MU_CHANNEL1 1 > +#define IMX_MU_CHANNEL2 2 > +#define IMX_MU_CHANNEL3 3 > +#define IMX_MU_CHANNEL_IMX8_SCU 4 > > It's hard for me to believe it's correct and it's over abstract to HW. > So I thought using mbox-cells to distinguish seems to be better. > > > I don't think it's necessary to rewrite Oleksijs driver, instead it > > should rather be extended with the code I already provided as an > > example. With that we could make both of us happy since we can both > > have a suitable driver and even share most of the MU code. > > As I said above, I even can't reuse 90%+ code of Oleksijs driver. So I can't > see the > meaning to demo the code on top of this driver. We can review the SCU > implementation directly with this driver whic
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi A.S > -Original Message- > From: A.s. Dong > Sent: 2018年7月11日 15:30 > To: Sascha Hauer > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > ; linux-kernel@vger.kernel.org; Oleksij Rempel > ; dl-linux-imx ; > ker...@pengutronix.de; Fabio Estevam ; > shawn...@kernel.org > Subject: RE: [PATCH V4 3/5] mailbox: imx: add imx mu support > > Hi Sascha, > > > -Original Message- > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > Sent: Tuesday, July 10, 2018 10:20 PM > > To: A.s. Dong > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi > > Brar ; linux-kernel@vger.kernel.org; Oleksij > > Rempel ; dl-linux-imx ; > > ker...@pengutronix.de; Fabio Estevam ; > > shawn...@kernel.org > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > Hi, > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > > This is used for i.MX multi core communication. > > > e.g. A core to SCU firmware(M core) on MX8. > > > > > > Tx is using polling mode while Rx is interrupt driven and schedule a > > > hrtimer to receive remain words if have more than > > > 4 words. > > > > You told us that using interrupts is not possible due to miserable > > performance, we then provided you a way with which you could poll. > > Why are you using interrupts now? > > > > Because mailbox framework does not support sync rx now, I think we do not > need to wait for that feature done first as it's independent and separate > features of framework. > > So for now, we're just using the common way in kernel as arm scpi and ti sci. > When framework supports it, we can easily switch to it. > > I optimized the performance a bit by removing the unnecessary memcopy > between tx/tx messages. The test result of booting time shows there's no > obvious regressions. I'm not sure whether it's due to we're booting a minimum > system or the extra cost is very minor to be noticed due to not too much cmds > sent during booting. > (Copy Peng to comments more as he tried and reported that performance drop > with vendor tree) The txpoll_period is set 1, the minimum is 1ms. So it introduces latency in the initial mailbox for SCU communication. Regards, Peng > > From the time measurement of sc_call_rpc, we can see that most rpc command > In polling mode can finish within 10us and very rare ones over 20us. > If switched to irq mode, those 10us cmds will change to about 20us. > > But the overall booting time did not increase much. Maybe the irq mode also > saves some CPU MIPS to execute other works in parallel? > > > We also suggested a way how the SCU mode could be integrated into the > > generic MU support driver Oleksij posted and now you send a driver > > which uses the same name as Oleksijs driver, but it only and > > exclusively works in SCU mode. This doesn't bring us forward. > > > > Can Oleksij's patch be implemented against this one? > As I remember you said we've still not determined whether Oleksij's approach > is > the most suitable way and it's still under discussion. > (Actually TI's approach looks better which is more simiar as SCU way?) > > Furthermore, from this patch, you will notice that Oleksij's patch almost did > not > work for SCU at all. I have to totally rewrite one for SCU. > So I did not write against his patch as it does not help. > And Oleksij's patch is quite simple while the SCU one is much complicated than > his one. So we probably better get SCU done first. > > > We suggested a binding that allows coexisting of the SCU mode and the > > generic mode of the MU by putting the mode information into the second > > mbox-cell. Why don't you use this? > > > > You mean this? > +#define IMX_MU_CHANNEL0 0 > +#define IMX_MU_CHANNEL1 1 > +#define IMX_MU_CHANNEL2 2 > +#define IMX_MU_CHANNEL3 3 > +#define IMX_MU_CHANNEL_IMX8_SCU 4 > > It's hard for me to believe it's correct and it's over abstract to HW. > So I thought using mbox-cells to distinguish seems to be better. > > > I don't think it's necessary to rewrite Oleksijs driver, instead it > > should rather be extended with the code I already provided as an > > example. With that we could make both of us happy since we can both > > have a suitable driver and even share most of the MU code. > > As I said above, I even can't reuse 90%+ code of Oleksijs driver. So I can't > see the > meaning to demo the code on top of this driver. We can review the SCU > implementation directly with this driver whic
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Jassi,
> -Original Message-
> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
> Sent: Wednesday, July 11, 2018 6:44 PM
> To: A.s. Dong
> Cc: Sascha Hauer ; linux-arm-
> ker...@lists.infradead.org; donga...@gmail.com; linux-
> ker...@vger.kernel.org; Oleksij Rempel ; dl-
> linux-imx ; ker...@pengutronix.de; Fabio Estevam
> ; shawn...@kernel.org
> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
>
> On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong wrote:
> >
> > > -Original Message-
> > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de]
> > > Sent: Wednesday, July 11, 2018 3:55 PM
> > > To: A.s. Dong
> > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi
> > > Brar ; linux-kernel@vger.kernel.org;
> > > Oleksij Rempel ; dl-linux-imx
> > > ; ker...@pengutronix.de; Fabio Estevam
> > > ; shawn...@kernel.org
> > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
> > >
> > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote:
> > > > Hi Sascha,
> > > >
> > > > > -Original Message-
> > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de]
> > > > > Sent: Tuesday, July 10, 2018 10:20 PM
> > > > > To: A.s. Dong
> > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com;
> > > > > Jassi Brar ;
> > > > > linux-kernel@vger.kernel.org; Oleksij Rempel
> > > > > ; dl-linux-imx ;
> > > > > ker...@pengutronix.de; Fabio Estevam ;
> > > > > shawn...@kernel.org
> > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote:
> > > > > > This is used for i.MX multi core communication.
> > > > > > e.g. A core to SCU firmware(M core) on MX8.
> > > > > >
> > > > > > Tx is using polling mode while Rx is interrupt driven and
> > > > > > schedule a hrtimer to receive remain words if have more than
> > > > > > 4 words.
> > > > >
> > > > > You told us that using interrupts is not possible due to
> > > > > miserable performance, we then provided you a way with which you
> could poll.
> > > > > Why are you using interrupts now?
> > > > >
> > > >
> > > > Because mailbox framework does not support sync rx now, I think we
> > > > do not need to wait for that feature done first as it's
> > > > independent and separate features of framework.
> > >
> > > You can wait forever for this feature, nobody will add it for you.
> > > It's up to you to add support for that feature. Who else should add this
> feature if not you?
> > > And when will you add that feature if not now when you actually need it?
> > > It is common practice that you adjust the frameworks to your needs
> > > rather than working around them.
> > >
> >
> > I'm willing to add it. Just because you said Jassi already had the
> > idea on how to Implement it and does not add much complexity. So I just
> want to see his patches.
> > But if he did not work on it, I can also help on it.
> >
> I am not much aware of the history of this conversation... but it seems you
> need to make use of mbox_chan_ops.peek_data().
>
> If not that, please let me know the requirement.
>
Thanks for the suggestion.
It looks to me may work.
From the definition, it seems it's used to pull data from remote side.
/**
* mbox_client_peek_data - A way for client driver to pull data
* received from remote by the controller.
* @chan: Mailbox channel assigned to this client.
*
* A poke to controller driver for any received data.
* The data is actually passed onto client via the
* mbox_chan_received_data()
* The call can be made from atomic context, so the controller's
* implementation of peek_data() must not sleep.
*
* Return: True, if controller has, and is going to push after this,
* some data.
* False, if controller doesn't have any data to be read.
*/
bool mbox_client_peek_data(struct mbox_chan *chan)
{
if (chan->mbox->ops->peek_data)
return chan->mbox->ops->peek_data(chan);
return false;
}
EXPORT_SYMBOL_GPL(mbox_client_peek_data);
But it seems most users in kernel simply implement it as a data available
Checking rather than rec
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Jassi,
> -Original Message-
> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
> Sent: Wednesday, July 11, 2018 6:44 PM
> To: A.s. Dong
> Cc: Sascha Hauer ; linux-arm-
> ker...@lists.infradead.org; donga...@gmail.com; linux-
> ker...@vger.kernel.org; Oleksij Rempel ; dl-
> linux-imx ; ker...@pengutronix.de; Fabio Estevam
> ; shawn...@kernel.org
> Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
>
> On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong wrote:
> >
> > > -Original Message-
> > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de]
> > > Sent: Wednesday, July 11, 2018 3:55 PM
> > > To: A.s. Dong
> > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi
> > > Brar ; linux-kernel@vger.kernel.org;
> > > Oleksij Rempel ; dl-linux-imx
> > > ; ker...@pengutronix.de; Fabio Estevam
> > > ; shawn...@kernel.org
> > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
> > >
> > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote:
> > > > Hi Sascha,
> > > >
> > > > > -Original Message-
> > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de]
> > > > > Sent: Tuesday, July 10, 2018 10:20 PM
> > > > > To: A.s. Dong
> > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com;
> > > > > Jassi Brar ;
> > > > > linux-kernel@vger.kernel.org; Oleksij Rempel
> > > > > ; dl-linux-imx ;
> > > > > ker...@pengutronix.de; Fabio Estevam ;
> > > > > shawn...@kernel.org
> > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote:
> > > > > > This is used for i.MX multi core communication.
> > > > > > e.g. A core to SCU firmware(M core) on MX8.
> > > > > >
> > > > > > Tx is using polling mode while Rx is interrupt driven and
> > > > > > schedule a hrtimer to receive remain words if have more than
> > > > > > 4 words.
> > > > >
> > > > > You told us that using interrupts is not possible due to
> > > > > miserable performance, we then provided you a way with which you
> could poll.
> > > > > Why are you using interrupts now?
> > > > >
> > > >
> > > > Because mailbox framework does not support sync rx now, I think we
> > > > do not need to wait for that feature done first as it's
> > > > independent and separate features of framework.
> > >
> > > You can wait forever for this feature, nobody will add it for you.
> > > It's up to you to add support for that feature. Who else should add this
> feature if not you?
> > > And when will you add that feature if not now when you actually need it?
> > > It is common practice that you adjust the frameworks to your needs
> > > rather than working around them.
> > >
> >
> > I'm willing to add it. Just because you said Jassi already had the
> > idea on how to Implement it and does not add much complexity. So I just
> want to see his patches.
> > But if he did not work on it, I can also help on it.
> >
> I am not much aware of the history of this conversation... but it seems you
> need to make use of mbox_chan_ops.peek_data().
>
> If not that, please let me know the requirement.
>
Thanks for the suggestion.
It looks to me may work.
From the definition, it seems it's used to pull data from remote side.
/**
* mbox_client_peek_data - A way for client driver to pull data
* received from remote by the controller.
* @chan: Mailbox channel assigned to this client.
*
* A poke to controller driver for any received data.
* The data is actually passed onto client via the
* mbox_chan_received_data()
* The call can be made from atomic context, so the controller's
* implementation of peek_data() must not sleep.
*
* Return: True, if controller has, and is going to push after this,
* some data.
* False, if controller doesn't have any data to be read.
*/
bool mbox_client_peek_data(struct mbox_chan *chan)
{
if (chan->mbox->ops->peek_data)
return chan->mbox->ops->peek_data(chan);
return false;
}
EXPORT_SYMBOL_GPL(mbox_client_peek_data);
But it seems most users in kernel simply implement it as a data available
Checking rather than rec
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong wrote: > > > -Original Message- > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > Sent: Wednesday, July 11, 2018 3:55 PM > > To: A.s. Dong > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > > ; linux-kernel@vger.kernel.org; Oleksij Rempel > > ; dl-linux-imx ; > > ker...@pengutronix.de; Fabio Estevam ; > > shawn...@kernel.org > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: > > > Hi Sascha, > > > > > > > -Original Message- > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > > > Sent: Tuesday, July 10, 2018 10:20 PM > > > > To: A.s. Dong > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi > > > > Brar ; linux-kernel@vger.kernel.org; > > > > Oleksij Rempel ; dl-linux-imx > > > > ; ker...@pengutronix.de; Fabio Estevam > > > > ; shawn...@kernel.org > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > > > > > Hi, > > > > > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > > > > This is used for i.MX multi core communication. > > > > > e.g. A core to SCU firmware(M core) on MX8. > > > > > > > > > > Tx is using polling mode while Rx is interrupt driven and schedule > > > > > a hrtimer to receive remain words if have more than > > > > > 4 words. > > > > > > > > You told us that using interrupts is not possible due to miserable > > > > performance, we then provided you a way with which you could poll. > > > > Why are you using interrupts now? > > > > > > > > > > Because mailbox framework does not support sync rx now, I think we do > > > not need to wait for that feature done first as it's independent and > > > separate features of framework. > > > > You can wait forever for this feature, nobody will add it for you. It's up > > to you > > to add support for that feature. Who else should add this feature if not > > you? > > And when will you add that feature if not now when you actually need it? > > It is common practice that you adjust the frameworks to your needs rather > > than working around them. > > > > I'm willing to add it. Just because you said Jassi already had the idea on > how to > Implement it and does not add much complexity. So I just want to see his > patches. > But if he did not work on it, I can also help on it. > I am not much aware of the history of this conversation... but it seems you need to make use of mbox_chan_ops.peek_data(). If not that, please let me know the requirement. Cheers!
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
On Wed, Jul 11, 2018 at 4:07 PM, A.s. Dong wrote: > > > -Original Message- > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > Sent: Wednesday, July 11, 2018 3:55 PM > > To: A.s. Dong > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > > ; linux-kernel@vger.kernel.org; Oleksij Rempel > > ; dl-linux-imx ; > > ker...@pengutronix.de; Fabio Estevam ; > > shawn...@kernel.org > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: > > > Hi Sascha, > > > > > > > -Original Message- > > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > > > Sent: Tuesday, July 10, 2018 10:20 PM > > > > To: A.s. Dong > > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi > > > > Brar ; linux-kernel@vger.kernel.org; > > > > Oleksij Rempel ; dl-linux-imx > > > > ; ker...@pengutronix.de; Fabio Estevam > > > > ; shawn...@kernel.org > > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > > > > > Hi, > > > > > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > > > > This is used for i.MX multi core communication. > > > > > e.g. A core to SCU firmware(M core) on MX8. > > > > > > > > > > Tx is using polling mode while Rx is interrupt driven and schedule > > > > > a hrtimer to receive remain words if have more than > > > > > 4 words. > > > > > > > > You told us that using interrupts is not possible due to miserable > > > > performance, we then provided you a way with which you could poll. > > > > Why are you using interrupts now? > > > > > > > > > > Because mailbox framework does not support sync rx now, I think we do > > > not need to wait for that feature done first as it's independent and > > > separate features of framework. > > > > You can wait forever for this feature, nobody will add it for you. It's up > > to you > > to add support for that feature. Who else should add this feature if not > > you? > > And when will you add that feature if not now when you actually need it? > > It is common practice that you adjust the frameworks to your needs rather > > than working around them. > > > > I'm willing to add it. Just because you said Jassi already had the idea on > how to > Implement it and does not add much complexity. So I just want to see his > patches. > But if he did not work on it, I can also help on it. > I am not much aware of the history of this conversation... but it seems you need to make use of mbox_chan_ops.peek_data(). If not that, please let me know the requirement. Cheers!
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
> -Original Message- > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > Sent: Wednesday, July 11, 2018 3:55 PM > To: A.s. Dong > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > ; linux-kernel@vger.kernel.org; Oleksij Rempel > ; dl-linux-imx ; > ker...@pengutronix.de; Fabio Estevam ; > shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: > > Hi Sascha, > > > > > -Original Message- > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > > Sent: Tuesday, July 10, 2018 10:20 PM > > > To: A.s. Dong > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi > > > Brar ; linux-kernel@vger.kernel.org; > > > Oleksij Rempel ; dl-linux-imx > > > ; ker...@pengutronix.de; Fabio Estevam > > > ; shawn...@kernel.org > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > > > Hi, > > > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > > > This is used for i.MX multi core communication. > > > > e.g. A core to SCU firmware(M core) on MX8. > > > > > > > > Tx is using polling mode while Rx is interrupt driven and schedule > > > > a hrtimer to receive remain words if have more than > > > > 4 words. > > > > > > You told us that using interrupts is not possible due to miserable > > > performance, we then provided you a way with which you could poll. > > > Why are you using interrupts now? > > > > > > > Because mailbox framework does not support sync rx now, I think we do > > not need to wait for that feature done first as it's independent and > > separate features of framework. > > You can wait forever for this feature, nobody will add it for you. It's up to > you > to add support for that feature. Who else should add this feature if not you? > And when will you add that feature if not now when you actually need it? > It is common practice that you adjust the frameworks to your needs rather > than working around them. > I'm willing to add it. Just because you said Jassi already had the idea on how to Implement it and does not add much complexity. So I just want to see his patches. But if he did not work on it, I can also help on it. Another reason is i did not observe regression as before, so it looks like the irq is an applicable way currently and not must use polling at this point as that's an independent new feature of framework. So irq mode is the quickest way to demo the mbox using as we already had experience before. > > > > So for now, we're just using the common way in kernel as arm scpi and ti > > sci. > > When framework supports it, we can easily switch to it. > > > > I optimized the performance a bit by removing the unnecessary memcopy > > between tx/tx messages. The test result of booting time shows there's > > no obvious regressions. I'm not sure whether it's due to we're booting > > a minimum system or the extra cost is very minor to be noticed due to > > not too much cmds sent during booting. > > Your boot time argument seems to be a very weak one. unnecessary > memcpys of a few bytes only take a fraction of the time interrupt latencies > introduce. > Yes, interrupt latency may be the major part. > > (Copy Peng to comments more as he tried and reported that performance > > drop with vendor tree) > > > > From the time measurement of sc_call_rpc, we can see that most rpc > > command In polling mode can finish within 10us and very rare ones over > 20us. > > If switched to irq mode, those 10us cmds will change to about 20us. > > > > But the overall booting time did not increase much. Maybe the irq mode > > also saves some CPU MIPS to execute other works in parallel? > > > > > We also suggested a way how the SCU mode could be integrated into > > > the generic MU support driver Oleksij posted and now you send a > > > driver which uses the same name as Oleksijs driver, but it only and > > > exclusively works in SCU mode. This doesn't bring us forward. > > > > > > > Can Oleksij's patch be implemented against this one? > > As I remember you said we've still not determined whether Oleksij's > > approach is the most suitable way and it's still under discussion. > > (Actually TI's approach looks better which is more simiar as SCU way?) > > > > Furthermore, from this patch, you will notice that Oleksij's patch > > almost did not work for SCU at all
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
> -Original Message- > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > Sent: Wednesday, July 11, 2018 3:55 PM > To: A.s. Dong > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > ; linux-kernel@vger.kernel.org; Oleksij Rempel > ; dl-linux-imx ; > ker...@pengutronix.de; Fabio Estevam ; > shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: > > Hi Sascha, > > > > > -Original Message- > > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > > Sent: Tuesday, July 10, 2018 10:20 PM > > > To: A.s. Dong > > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi > > > Brar ; linux-kernel@vger.kernel.org; > > > Oleksij Rempel ; dl-linux-imx > > > ; ker...@pengutronix.de; Fabio Estevam > > > ; shawn...@kernel.org > > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > > > Hi, > > > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > > > This is used for i.MX multi core communication. > > > > e.g. A core to SCU firmware(M core) on MX8. > > > > > > > > Tx is using polling mode while Rx is interrupt driven and schedule > > > > a hrtimer to receive remain words if have more than > > > > 4 words. > > > > > > You told us that using interrupts is not possible due to miserable > > > performance, we then provided you a way with which you could poll. > > > Why are you using interrupts now? > > > > > > > Because mailbox framework does not support sync rx now, I think we do > > not need to wait for that feature done first as it's independent and > > separate features of framework. > > You can wait forever for this feature, nobody will add it for you. It's up to > you > to add support for that feature. Who else should add this feature if not you? > And when will you add that feature if not now when you actually need it? > It is common practice that you adjust the frameworks to your needs rather > than working around them. > I'm willing to add it. Just because you said Jassi already had the idea on how to Implement it and does not add much complexity. So I just want to see his patches. But if he did not work on it, I can also help on it. Another reason is i did not observe regression as before, so it looks like the irq is an applicable way currently and not must use polling at this point as that's an independent new feature of framework. So irq mode is the quickest way to demo the mbox using as we already had experience before. > > > > So for now, we're just using the common way in kernel as arm scpi and ti > > sci. > > When framework supports it, we can easily switch to it. > > > > I optimized the performance a bit by removing the unnecessary memcopy > > between tx/tx messages. The test result of booting time shows there's > > no obvious regressions. I'm not sure whether it's due to we're booting > > a minimum system or the extra cost is very minor to be noticed due to > > not too much cmds sent during booting. > > Your boot time argument seems to be a very weak one. unnecessary > memcpys of a few bytes only take a fraction of the time interrupt latencies > introduce. > Yes, interrupt latency may be the major part. > > (Copy Peng to comments more as he tried and reported that performance > > drop with vendor tree) > > > > From the time measurement of sc_call_rpc, we can see that most rpc > > command In polling mode can finish within 10us and very rare ones over > 20us. > > If switched to irq mode, those 10us cmds will change to about 20us. > > > > But the overall booting time did not increase much. Maybe the irq mode > > also saves some CPU MIPS to execute other works in parallel? > > > > > We also suggested a way how the SCU mode could be integrated into > > > the generic MU support driver Oleksij posted and now you send a > > > driver which uses the same name as Oleksijs driver, but it only and > > > exclusively works in SCU mode. This doesn't bring us forward. > > > > > > > Can Oleksij's patch be implemented against this one? > > As I remember you said we've still not determined whether Oleksij's > > approach is the most suitable way and it's still under discussion. > > (Actually TI's approach looks better which is more simiar as SCU way?) > > > > Furthermore, from this patch, you will notice that Oleksij's patch > > almost did not work for SCU at all
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: > Hi Sascha, > > > -Original Message- > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > Sent: Tuesday, July 10, 2018 10:20 PM > > To: A.s. Dong > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > > ; linux-kernel@vger.kernel.org; Oleksij Rempel > > ; dl-linux-imx ; > > ker...@pengutronix.de; Fabio Estevam ; > > shawn...@kernel.org > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > Hi, > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > > This is used for i.MX multi core communication. > > > e.g. A core to SCU firmware(M core) on MX8. > > > > > > Tx is using polling mode while Rx is interrupt driven and schedule a > > > hrtimer to receive remain words if have more than > > > 4 words. > > > > You told us that using interrupts is not possible due to miserable > > performance, we then provided you a way with which you could poll. Why > > are you using interrupts now? > > > > Because mailbox framework does not support sync rx now, I think we do not > need to wait for that feature done first as it's independent and separate > features of framework. You can wait forever for this feature, nobody will add it for you. It's up to you to add support for that feature. Who else should add this feature if not you? And when will you add that feature if not now when you actually need it? It is common practice that you adjust the frameworks to your needs rather than working around them. > > So for now, we're just using the common way in kernel as arm scpi and ti sci. > When framework supports it, we can easily switch to it. > > I optimized the performance a bit by removing the unnecessary memcopy > between tx/tx messages. The test result of booting time shows there's no > obvious regressions. I'm not sure whether it's due to we're booting a minimum > system or the extra cost is very minor to be noticed due to not too much cmds > sent during booting. Your boot time argument seems to be a very weak one. unnecessary memcpys of a few bytes only take a fraction of the time interrupt latencies introduce. > (Copy Peng to comments more as he tried and reported that performance drop > with vendor tree) > > From the time measurement of sc_call_rpc, we can see that most rpc command > In polling mode can finish within 10us and very rare ones over 20us. > If switched to irq mode, those 10us cmds will change to about 20us. > > But the overall booting time did not increase much. Maybe the irq mode > also saves some CPU MIPS to execute other works in parallel? > > > We also suggested a way how the SCU mode could be integrated into the > > generic MU support driver Oleksij posted and now you send a driver which > > uses the same name as Oleksijs driver, but it only and exclusively works in > > SCU mode. This doesn't bring us forward. > > > > Can Oleksij's patch be implemented against this one? > As I remember you said we've still not determined whether Oleksij's approach > is the most suitable way and it's still under discussion. > (Actually TI's approach looks better which is more simiar as SCU way?) > > Furthermore, from this patch, you will notice that Oleksij's patch almost > did not work for SCU at all. I have to totally rewrite one for SCU. You are kidding. You have to rewrite it because you didn't follow my suggestion to implement polling in the mailbox framework. > So I did not write against his patch as it does not help. > And Oleksij's patch is quite simple while the SCU one is much complicated > than his one. So we probably better get SCU done first. > > > We suggested a binding that allows coexisting of the SCU mode and the > > generic mode of the MU by putting the mode information into the second > > mbox-cell. Why don't you use this? > > > > You mean this? > +#define IMX_MU_CHANNEL0 0 > +#define IMX_MU_CHANNEL1 1 > +#define IMX_MU_CHANNEL2 2 > +#define IMX_MU_CHANNEL3 3 > +#define IMX_MU_CHANNEL_IMX8_SCU 4 Yes. > > It's hard for me to believe it's correct and it's over abstract to HW. > So I thought using mbox-cells to distinguish seems to be better. The MU has four rx registers, four tx registers and four interrupts. What else should this be than four channels? The number of channels the MU has is obviously defined by the software running at the other end of the MU. Yes, the SCU makes one channel from it, in other cases it's four channels. > > > I don't think it's necessary to rewrite Oleksijs driver, instead it should > &g
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
On Wed, Jul 11, 2018 at 07:29:38AM +, A.s. Dong wrote: > Hi Sascha, > > > -Original Message- > > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > > Sent: Tuesday, July 10, 2018 10:20 PM > > To: A.s. Dong > > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > > ; linux-kernel@vger.kernel.org; Oleksij Rempel > > ; dl-linux-imx ; > > ker...@pengutronix.de; Fabio Estevam ; > > shawn...@kernel.org > > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > Hi, > > > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > > This is used for i.MX multi core communication. > > > e.g. A core to SCU firmware(M core) on MX8. > > > > > > Tx is using polling mode while Rx is interrupt driven and schedule a > > > hrtimer to receive remain words if have more than > > > 4 words. > > > > You told us that using interrupts is not possible due to miserable > > performance, we then provided you a way with which you could poll. Why > > are you using interrupts now? > > > > Because mailbox framework does not support sync rx now, I think we do not > need to wait for that feature done first as it's independent and separate > features of framework. You can wait forever for this feature, nobody will add it for you. It's up to you to add support for that feature. Who else should add this feature if not you? And when will you add that feature if not now when you actually need it? It is common practice that you adjust the frameworks to your needs rather than working around them. > > So for now, we're just using the common way in kernel as arm scpi and ti sci. > When framework supports it, we can easily switch to it. > > I optimized the performance a bit by removing the unnecessary memcopy > between tx/tx messages. The test result of booting time shows there's no > obvious regressions. I'm not sure whether it's due to we're booting a minimum > system or the extra cost is very minor to be noticed due to not too much cmds > sent during booting. Your boot time argument seems to be a very weak one. unnecessary memcpys of a few bytes only take a fraction of the time interrupt latencies introduce. > (Copy Peng to comments more as he tried and reported that performance drop > with vendor tree) > > From the time measurement of sc_call_rpc, we can see that most rpc command > In polling mode can finish within 10us and very rare ones over 20us. > If switched to irq mode, those 10us cmds will change to about 20us. > > But the overall booting time did not increase much. Maybe the irq mode > also saves some CPU MIPS to execute other works in parallel? > > > We also suggested a way how the SCU mode could be integrated into the > > generic MU support driver Oleksij posted and now you send a driver which > > uses the same name as Oleksijs driver, but it only and exclusively works in > > SCU mode. This doesn't bring us forward. > > > > Can Oleksij's patch be implemented against this one? > As I remember you said we've still not determined whether Oleksij's approach > is the most suitable way and it's still under discussion. > (Actually TI's approach looks better which is more simiar as SCU way?) > > Furthermore, from this patch, you will notice that Oleksij's patch almost > did not work for SCU at all. I have to totally rewrite one for SCU. You are kidding. You have to rewrite it because you didn't follow my suggestion to implement polling in the mailbox framework. > So I did not write against his patch as it does not help. > And Oleksij's patch is quite simple while the SCU one is much complicated > than his one. So we probably better get SCU done first. > > > We suggested a binding that allows coexisting of the SCU mode and the > > generic mode of the MU by putting the mode information into the second > > mbox-cell. Why don't you use this? > > > > You mean this? > +#define IMX_MU_CHANNEL0 0 > +#define IMX_MU_CHANNEL1 1 > +#define IMX_MU_CHANNEL2 2 > +#define IMX_MU_CHANNEL3 3 > +#define IMX_MU_CHANNEL_IMX8_SCU 4 Yes. > > It's hard for me to believe it's correct and it's over abstract to HW. > So I thought using mbox-cells to distinguish seems to be better. The MU has four rx registers, four tx registers and four interrupts. What else should this be than four channels? The number of channels the MU has is obviously defined by the software running at the other end of the MU. Yes, the SCU makes one channel from it, in other cases it's four channels. > > > I don't think it's necessary to rewrite Oleksijs driver, instead it should > &g
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Sascha, > -Original Message- > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > Sent: Tuesday, July 10, 2018 10:20 PM > To: A.s. Dong > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > ; linux-kernel@vger.kernel.org; Oleksij Rempel > ; dl-linux-imx ; > ker...@pengutronix.de; Fabio Estevam ; > shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > Hi, > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > This is used for i.MX multi core communication. > > e.g. A core to SCU firmware(M core) on MX8. > > > > Tx is using polling mode while Rx is interrupt driven and schedule a > > hrtimer to receive remain words if have more than > > 4 words. > > You told us that using interrupts is not possible due to miserable > performance, we then provided you a way with which you could poll. Why > are you using interrupts now? > Because mailbox framework does not support sync rx now, I think we do not need to wait for that feature done first as it's independent and separate features of framework. So for now, we're just using the common way in kernel as arm scpi and ti sci. When framework supports it, we can easily switch to it. I optimized the performance a bit by removing the unnecessary memcopy between tx/tx messages. The test result of booting time shows there's no obvious regressions. I'm not sure whether it's due to we're booting a minimum system or the extra cost is very minor to be noticed due to not too much cmds sent during booting. (Copy Peng to comments more as he tried and reported that performance drop with vendor tree) >From the time measurement of sc_call_rpc, we can see that most rpc command In polling mode can finish within 10us and very rare ones over 20us. If switched to irq mode, those 10us cmds will change to about 20us. But the overall booting time did not increase much. Maybe the irq mode also saves some CPU MIPS to execute other works in parallel? > We also suggested a way how the SCU mode could be integrated into the > generic MU support driver Oleksij posted and now you send a driver which > uses the same name as Oleksijs driver, but it only and exclusively works in > SCU mode. This doesn't bring us forward. > Can Oleksij's patch be implemented against this one? As I remember you said we've still not determined whether Oleksij's approach is the most suitable way and it's still under discussion. (Actually TI's approach looks better which is more simiar as SCU way?) Furthermore, from this patch, you will notice that Oleksij's patch almost did not work for SCU at all. I have to totally rewrite one for SCU. So I did not write against his patch as it does not help. And Oleksij's patch is quite simple while the SCU one is much complicated than his one. So we probably better get SCU done first. > We suggested a binding that allows coexisting of the SCU mode and the > generic mode of the MU by putting the mode information into the second > mbox-cell. Why don't you use this? > You mean this? +#define IMX_MU_CHANNEL00 +#define IMX_MU_CHANNEL11 +#define IMX_MU_CHANNEL22 +#define IMX_MU_CHANNEL33 +#define IMX_MU_CHANNEL_IMX8_SCU 4 It's hard for me to believe it's correct and it's over abstract to HW. So I thought using mbox-cells to distinguish seems to be better. > I don't think it's necessary to rewrite Oleksijs driver, instead it should > rather > be extended with the code I already provided as an example. With that we > could make both of us happy since we can both have a suitable driver and > even share most of the MU code. As I said above, I even can't reuse 90%+ code of Oleksijs driver. So I can't see the meaning to demo the code on top of this driver. We can review the SCU implementation directly with this driver which is more easy. Then we can decide how to merge them together. Regards Dong Aisheng > > Regards, > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > w.pengutronix.de%2Fdata=02%7C01%7Caisheng.dong%40nxp.com%7 > Cb359a3eddee54bf1b40a08d5e6702f22%7C686ea1d3bc2b4c6fa92cd99c5c301 > 635%7C0%7C0%7C636668291863846639sdata=hSucaLRfCB1j1McwlfO% > 2FL0921QXiHg68sl%2B23CvEp4Q%3Dreserved=0 | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Sascha, > -Original Message- > From: Sascha Hauer [mailto:s.ha...@pengutronix.de] > Sent: Tuesday, July 10, 2018 10:20 PM > To: A.s. Dong > Cc: linux-arm-ker...@lists.infradead.org; donga...@gmail.com; Jassi Brar > ; linux-kernel@vger.kernel.org; Oleksij Rempel > ; dl-linux-imx ; > ker...@pengutronix.de; Fabio Estevam ; > shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > Hi, > > On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > > This is used for i.MX multi core communication. > > e.g. A core to SCU firmware(M core) on MX8. > > > > Tx is using polling mode while Rx is interrupt driven and schedule a > > hrtimer to receive remain words if have more than > > 4 words. > > You told us that using interrupts is not possible due to miserable > performance, we then provided you a way with which you could poll. Why > are you using interrupts now? > Because mailbox framework does not support sync rx now, I think we do not need to wait for that feature done first as it's independent and separate features of framework. So for now, we're just using the common way in kernel as arm scpi and ti sci. When framework supports it, we can easily switch to it. I optimized the performance a bit by removing the unnecessary memcopy between tx/tx messages. The test result of booting time shows there's no obvious regressions. I'm not sure whether it's due to we're booting a minimum system or the extra cost is very minor to be noticed due to not too much cmds sent during booting. (Copy Peng to comments more as he tried and reported that performance drop with vendor tree) >From the time measurement of sc_call_rpc, we can see that most rpc command In polling mode can finish within 10us and very rare ones over 20us. If switched to irq mode, those 10us cmds will change to about 20us. But the overall booting time did not increase much. Maybe the irq mode also saves some CPU MIPS to execute other works in parallel? > We also suggested a way how the SCU mode could be integrated into the > generic MU support driver Oleksij posted and now you send a driver which > uses the same name as Oleksijs driver, but it only and exclusively works in > SCU mode. This doesn't bring us forward. > Can Oleksij's patch be implemented against this one? As I remember you said we've still not determined whether Oleksij's approach is the most suitable way and it's still under discussion. (Actually TI's approach looks better which is more simiar as SCU way?) Furthermore, from this patch, you will notice that Oleksij's patch almost did not work for SCU at all. I have to totally rewrite one for SCU. So I did not write against his patch as it does not help. And Oleksij's patch is quite simple while the SCU one is much complicated than his one. So we probably better get SCU done first. > We suggested a binding that allows coexisting of the SCU mode and the > generic mode of the MU by putting the mode information into the second > mbox-cell. Why don't you use this? > You mean this? +#define IMX_MU_CHANNEL00 +#define IMX_MU_CHANNEL11 +#define IMX_MU_CHANNEL22 +#define IMX_MU_CHANNEL33 +#define IMX_MU_CHANNEL_IMX8_SCU 4 It's hard for me to believe it's correct and it's over abstract to HW. So I thought using mbox-cells to distinguish seems to be better. > I don't think it's necessary to rewrite Oleksijs driver, instead it should > rather > be extended with the code I already provided as an example. With that we > could make both of us happy since we can both have a suitable driver and > even share most of the MU code. As I said above, I even can't reuse 90%+ code of Oleksijs driver. So I can't see the meaning to demo the code on top of this driver. We can review the SCU implementation directly with this driver which is more easy. Then we can decide how to merge them together. Regards Dong Aisheng > > Regards, > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > w.pengutronix.de%2Fdata=02%7C01%7Caisheng.dong%40nxp.com%7 > Cb359a3eddee54bf1b40a08d5e6702f22%7C686ea1d3bc2b4c6fa92cd99c5c301 > 635%7C0%7C0%7C636668291863846639sdata=hSucaLRfCB1j1McwlfO% > 2FL0921QXiHg68sl%2B23CvEp4Q%3Dreserved=0 | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi, On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > This is used for i.MX multi core communication. > e.g. A core to SCU firmware(M core) on MX8. > > Tx is using polling mode while Rx is interrupt driven and > schedule a hrtimer to receive remain words if have more than > 4 words. You told us that using interrupts is not possible due to miserable performance, we then provided you a way with which you could poll. Why are you using interrupts now? We also suggested a way how the SCU mode could be integrated into the generic MU support driver Oleksij posted and now you send a driver which uses the same name as Oleksijs driver, but it only and exclusively works in SCU mode. This doesn't bring us forward. We suggested a binding that allows coexisting of the SCU mode and the generic mode of the MU by putting the mode information into the second mbox-cell. Why don't you use this? I don't think it's necessary to rewrite Oleksijs driver, instead it should rather be extended with the code I already provided as an example. With that we could make both of us happy since we can both have a suitable driver and even share most of the MU code. Regards, Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi, On Sun, Jul 08, 2018 at 10:56:55PM +0800, Dong Aisheng wrote: > This is used for i.MX multi core communication. > e.g. A core to SCU firmware(M core) on MX8. > > Tx is using polling mode while Rx is interrupt driven and > schedule a hrtimer to receive remain words if have more than > 4 words. You told us that using interrupts is not possible due to miserable performance, we then provided you a way with which you could poll. Why are you using interrupts now? We also suggested a way how the SCU mode could be integrated into the generic MU support driver Oleksij posted and now you send a driver which uses the same name as Oleksijs driver, but it only and exclusively works in SCU mode. This doesn't bring us forward. We suggested a binding that allows coexisting of the SCU mode and the generic mode of the MU by putting the mode information into the second mbox-cell. Why don't you use this? I don't think it's necessary to rewrite Oleksijs driver, instead it should rather be extended with the code I already provided as an example. With that we could make both of us happy since we can both have a suitable driver and even share most of the MU code. Regards, Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
