From: Peng Fan <peng.fan@nxp.com> To: Sudeep Holla <sudeep.holla@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org> Cc: "f.fainelli@gmail.com" <f.fainelli@gmail.com>, dl-linux-imx <linux-imx@nxp.com> Subject: RE: [PATCH 1/4] firmware: arm_scmi: Make mutex channel specific Date: Wed, 1 Apr 2020 01:12:37 +0000 [thread overview] Message-ID: <AM0PR04MB4481562E2A31386752F92C4488C90@AM0PR04MB4481.eurprd04.prod.outlook.com> (raw) In-Reply-To: <20200327163654.13389-2-sudeep.holla@arm.com> Hi Sudeep, > Subject: [PATCH 1/4] firmware: arm_scmi: Make mutex channel specific > > In order to support multiple SMC/HVC transport channels with associated > shared memory, Does this mean each channel will have its own shared memory? Or All channels share the same shared memory? it is better to maintain the mutex per channel instead of > existing global one. If all channels shared the same memory, use per channel mutex lock will not be able to prevent other channels accessing shared memory at the same time. Thanks, Peng. > > Move the smc_mutex into the scmi_smc structure and also rename it to > shmem_lock which is more appropriate for it's use. > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > drivers/firmware/arm_scmi/smc.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/firmware/arm_scmi/smc.c > b/drivers/firmware/arm_scmi/smc.c index 336168e40f49..6dc8a88cc91b > 100644 > --- a/drivers/firmware/arm_scmi/smc.c > +++ b/drivers/firmware/arm_scmi/smc.c > @@ -27,11 +27,10 @@ > struct scmi_smc { > struct scmi_chan_info *cinfo; > struct scmi_shared_mem __iomem *shmem; > + struct mutex shmem_lock; > u32 func_id; > }; > > -static DEFINE_MUTEX(smc_mutex); > - > static bool smc_chan_available(struct device *dev, int idx) { > return true; > @@ -78,6 +77,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, > struct device *dev, > > scmi_info->func_id = func_id; > scmi_info->cinfo = cinfo; > + mutex_init(&scmi_info->shmem_lock); > cinfo->transport_info = scmi_info; > > return 0; > @@ -102,14 +102,14 @@ static int smc_send_message(struct > scmi_chan_info *cinfo, > struct scmi_smc *scmi_info = cinfo->transport_info; > struct arm_smccc_res res; > > - mutex_lock(&smc_mutex); > + mutex_lock(&scmi_info->shmem_lock); > > shmem_tx_prepare(scmi_info->shmem, xfer); > > arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res); > scmi_rx_callback(scmi_info->cinfo, > shmem_read_header(scmi_info->shmem)); > > - mutex_unlock(&smc_mutex); > + mutex_unlock(&scmi_info->shmem_lock); > > return res.a0; > } > -- > 2.17.1
WARNING: multiple messages have this Message-ID (diff)
From: Peng Fan <peng.fan@nxp.com> To: Sudeep Holla <sudeep.holla@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org> Cc: "f.fainelli@gmail.com" <f.fainelli@gmail.com>, dl-linux-imx <linux-imx@nxp.com> Subject: RE: [PATCH 1/4] firmware: arm_scmi: Make mutex channel specific Date: Wed, 1 Apr 2020 01:12:37 +0000 [thread overview] Message-ID: <AM0PR04MB4481562E2A31386752F92C4488C90@AM0PR04MB4481.eurprd04.prod.outlook.com> (raw) In-Reply-To: <20200327163654.13389-2-sudeep.holla@arm.com> Hi Sudeep, > Subject: [PATCH 1/4] firmware: arm_scmi: Make mutex channel specific > > In order to support multiple SMC/HVC transport channels with associated > shared memory, Does this mean each channel will have its own shared memory? Or All channels share the same shared memory? it is better to maintain the mutex per channel instead of > existing global one. If all channels shared the same memory, use per channel mutex lock will not be able to prevent other channels accessing shared memory at the same time. Thanks, Peng. > > Move the smc_mutex into the scmi_smc structure and also rename it to > shmem_lock which is more appropriate for it's use. > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > drivers/firmware/arm_scmi/smc.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/firmware/arm_scmi/smc.c > b/drivers/firmware/arm_scmi/smc.c index 336168e40f49..6dc8a88cc91b > 100644 > --- a/drivers/firmware/arm_scmi/smc.c > +++ b/drivers/firmware/arm_scmi/smc.c > @@ -27,11 +27,10 @@ > struct scmi_smc { > struct scmi_chan_info *cinfo; > struct scmi_shared_mem __iomem *shmem; > + struct mutex shmem_lock; > u32 func_id; > }; > > -static DEFINE_MUTEX(smc_mutex); > - > static bool smc_chan_available(struct device *dev, int idx) { > return true; > @@ -78,6 +77,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, > struct device *dev, > > scmi_info->func_id = func_id; > scmi_info->cinfo = cinfo; > + mutex_init(&scmi_info->shmem_lock); > cinfo->transport_info = scmi_info; > > return 0; > @@ -102,14 +102,14 @@ static int smc_send_message(struct > scmi_chan_info *cinfo, > struct scmi_smc *scmi_info = cinfo->transport_info; > struct arm_smccc_res res; > > - mutex_lock(&smc_mutex); > + mutex_lock(&scmi_info->shmem_lock); > > shmem_tx_prepare(scmi_info->shmem, xfer); > > arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res); > scmi_rx_callback(scmi_info->cinfo, > shmem_read_header(scmi_info->shmem)); > > - mutex_unlock(&smc_mutex); > + mutex_unlock(&scmi_info->shmem_lock); > > return res.a0; > } > -- > 2.17.1 _______________________________________________ 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-04-01 1:12 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-27 16:36 [PATCH 0/4] firmware: arm_scmi: Extend SMC/HVC to support multiple channels Sudeep Holla 2020-03-27 16:36 ` Sudeep Holla 2020-03-27 16:36 ` [PATCH 1/4] firmware: arm_scmi: Make mutex channel specific Sudeep Holla 2020-03-27 16:36 ` Sudeep Holla 2020-04-01 1:12 ` Peng Fan [this message] 2020-04-01 1:12 ` Peng Fan 2020-04-01 9:12 ` Sudeep Holla 2020-04-01 9:12 ` Sudeep Holla 2020-04-01 9:14 ` Peng Fan 2020-04-01 9:14 ` Peng Fan 2020-04-01 9:28 ` Sudeep Holla 2020-04-01 9:28 ` Sudeep Holla 2020-04-01 9:14 ` Peng Fan 2020-04-01 9:14 ` Peng Fan 2020-03-27 16:36 ` [PATCH 2/4] firmware: arm_scmi: Drop empty stub for smc_mark_txdone Sudeep Holla 2020-03-27 16:36 ` Sudeep Holla 2020-04-01 1:15 ` Peng Fan 2020-04-01 1:15 ` Peng Fan 2020-03-27 16:36 ` [PATCH 3/4] firmware: arm_scmi: Check shmem property for channel availablity Sudeep Holla 2020-03-27 16:36 ` Sudeep Holla 2020-04-01 1:15 ` Peng Fan 2020-04-01 1:15 ` Peng Fan 2020-04-01 9:05 ` Sudeep Holla 2020-04-01 9:05 ` Sudeep Holla 2020-03-27 16:36 ` [PATCH 4/4] firmware: arm_scmi: Drop checking for shmem property in parent node Sudeep Holla 2020-03-27 16:36 ` Sudeep Holla 2020-04-01 1:19 ` Peng Fan 2020-04-01 1:19 ` Peng Fan 2020-03-31 13:53 ` [PATCH 0/4] firmware: arm_scmi: Extend SMC/HVC to support multiple channels Peng Fan 2020-03-31 13:53 ` Peng Fan 2020-03-31 14:21 ` Sudeep Holla 2020-03-31 14:21 ` Sudeep Holla
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=AM0PR04MB4481562E2A31386752F92C4488C90@AM0PR04MB4481.eurprd04.prod.outlook.com \ --to=peng.fan@nxp.com \ --cc=devicetree@vger.kernel.org \ --cc=f.fainelli@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=sudeep.holla@arm.com \ /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.