From: Sudeep Holla <sudeep.holla@arm.com> To: Peng Fan <peng.fan@nxp.com>, Florian Fainelli <f.fainelli@gmail.com> Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>, "viresh.kumar@linaro.org" <viresh.kumar@linaro.org>, dl-linux-imx <linux-imx@nxp.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Sudeep Holla <sudeep.holla@arm.com> Subject: Re: [PATCH V4 2/2] firmware: arm_scmi: add smc/hvc transport Date: Fri, 6 Mar 2020 14:23:13 +0000 [thread overview] Message-ID: <20200306123442.GA47929@bogus> (raw) In-Reply-To: <AM0PR04MB448167BD133BF57E548F2F0588E30@AM0PR04MB4481.eurprd04.prod.outlook.com> On Fri, Mar 06, 2020 at 08:07:19AM +0000, Peng Fan wrote: > > Subject: Re: [PATCH V4 2/2] firmware: arm_scmi: add smc/hvc transport > > > > On 3/5/20 8:06 AM, Sudeep Holla wrote: > > > On Thu, Mar 05, 2020 at 11:25:35AM +0000, Peng Fan wrote: > > > > > > [...] > > > > > >>> > > >>> Yes, this may fix the issue. However I would like to know if we need > > >>> to support multiple channels/shared memory simultaneously. It is > > >>> fair requirement and may need some work which should be fine. > > >> > > >> Do you have any suggestions? Currently I have not worked out an good > > >> solution. > > >> > > > > > > TBH, I haven't given it a much thought. I would like to know if people > > > are happy with just one SMC channel for SCMI or do they need more ? > > > If they need it, we can try to solve it. Otherwise, what you have will > > > suffice IMO. > > > > On our platforms we have one channel/shared memory area/mailbox > > instance for all standard SCMI protocols, and we have a separate > > channel/shared memory area/mailbox driver instance for a proprietary one. > > They happen to have difference throughput requirements, hence the split. > > OK, when you refer proprietary protocol, do you mean outside the scope of SCMI ? The reason I ask is SCMI allows vendor specific protocols and if you are using other channel for that, it still make sense to add multi-channel support here. > > If I read Peng's submission correctly, it seems to me that the usage model > > described before is still fine. > > Thanks. > > Sudeep, > > Then should I repost with the global mutex added? > Sure, you can send the updated. I will think about adding support for more than one channel and send a patch on top of it if I get around it. Note that I sent PR for v5.7 last earlier this week, so this will be for v5.8 -- Regards, Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com> To: Peng Fan <peng.fan@nxp.com>, Florian Fainelli <f.fainelli@gmail.com> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "viresh.kumar@linaro.org" <viresh.kumar@linaro.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "robh+dt@kernel.org" <robh+dt@kernel.org>, dl-linux-imx <linux-imx@nxp.com>, Sudeep Holla <sudeep.holla@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH V4 2/2] firmware: arm_scmi: add smc/hvc transport Date: Fri, 6 Mar 2020 14:23:13 +0000 [thread overview] Message-ID: <20200306123442.GA47929@bogus> (raw) In-Reply-To: <AM0PR04MB448167BD133BF57E548F2F0588E30@AM0PR04MB4481.eurprd04.prod.outlook.com> On Fri, Mar 06, 2020 at 08:07:19AM +0000, Peng Fan wrote: > > Subject: Re: [PATCH V4 2/2] firmware: arm_scmi: add smc/hvc transport > > > > On 3/5/20 8:06 AM, Sudeep Holla wrote: > > > On Thu, Mar 05, 2020 at 11:25:35AM +0000, Peng Fan wrote: > > > > > > [...] > > > > > >>> > > >>> Yes, this may fix the issue. However I would like to know if we need > > >>> to support multiple channels/shared memory simultaneously. It is > > >>> fair requirement and may need some work which should be fine. > > >> > > >> Do you have any suggestions? Currently I have not worked out an good > > >> solution. > > >> > > > > > > TBH, I haven't given it a much thought. I would like to know if people > > > are happy with just one SMC channel for SCMI or do they need more ? > > > If they need it, we can try to solve it. Otherwise, what you have will > > > suffice IMO. > > > > On our platforms we have one channel/shared memory area/mailbox > > instance for all standard SCMI protocols, and we have a separate > > channel/shared memory area/mailbox driver instance for a proprietary one. > > They happen to have difference throughput requirements, hence the split. > > OK, when you refer proprietary protocol, do you mean outside the scope of SCMI ? The reason I ask is SCMI allows vendor specific protocols and if you are using other channel for that, it still make sense to add multi-channel support here. > > If I read Peng's submission correctly, it seems to me that the usage model > > described before is still fine. > > Thanks. > > Sudeep, > > Then should I repost with the global mutex added? > Sure, you can send the updated. I will think about adding support for more than one channel and send a patch on top of it if I get around it. Note that I sent PR for v5.7 last earlier this week, so this will be for v5.8 -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-06 14:23 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-03 2:06 [PATCH V4 0/2] firmware: arm_scmi: add smc/hvc transports support peng.fan 2020-03-03 2:06 ` peng.fan 2020-03-03 2:06 ` [PATCH V4 1/2] dt-bindings: arm: arm,scmi: add smc/hvc transport peng.fan 2020-03-03 2:06 ` peng.fan 2020-03-04 16:31 ` Rob Herring 2020-03-04 16:31 ` Rob Herring 2020-03-03 2:06 ` [PATCH V4 2/2] firmware: arm_scmi: " peng.fan 2020-03-03 2:06 ` peng.fan 2020-03-04 10:40 ` Sudeep Holla 2020-03-04 10:40 ` Sudeep Holla 2020-03-04 12:49 ` Peng Fan 2020-03-04 12:49 ` Peng Fan 2020-03-04 14:16 ` Peng Fan 2020-03-04 14:16 ` Peng Fan 2020-03-04 17:03 ` Sudeep Holla 2020-03-04 17:03 ` Sudeep Holla 2020-03-05 11:25 ` Peng Fan 2020-03-05 11:25 ` Peng Fan 2020-03-05 16:06 ` Sudeep Holla 2020-03-05 16:06 ` Sudeep Holla 2020-03-05 17:27 ` Florian Fainelli 2020-03-05 17:27 ` Florian Fainelli 2020-03-06 8:07 ` Peng Fan 2020-03-06 8:07 ` Peng Fan 2020-03-06 14:23 ` Sudeep Holla [this message] 2020-03-06 14:23 ` Sudeep Holla 2020-03-06 18:08 ` Florian Fainelli 2020-03-06 18:08 ` Florian Fainelli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200306123442.GA47929@bogus \ --to=sudeep.holla@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=f.fainelli@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=peng.fan@nxp.com \ --cc=robh+dt@kernel.org \ --cc=viresh.kumar@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.