Two mailbox controllers have channel/client binding mechanisms that are
controller-specific and not using the devicetree binding mechanisms. Mailbox
channel/client is conceptually done in two steps: selecting the channel
and binding the selected to channel to a client. Channel selection is sometimes
controller specific (pcc and omap are examples). The channel/client binding
code is all the same.
This small series de-duplicates and refactors the channel/client binding
into a common framework function: "mbox_bind_client" which all of the
channel selection mechanisms can use.
I found this duplicate code while working on the support for Gunyah hypervisor
message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
however it is a straightforward conversion here.
[1]: https://lore.kernel.org/all/[email protected]/
Elliot Berman (3):
mailbox: Allow direct registration to a channel
mailbox: omap: Use mbox_bind_client
mailbox: pcc: Use mbox_bind_client
drivers/mailbox/mailbox.c | 96 ++++++++++++++++++++++++----------
drivers/mailbox/omap-mailbox.c | 22 ++------
drivers/mailbox/pcc.c | 82 ++++++++++++++++-------------
include/linux/mailbox_client.h | 1 +
4 files changed, 118 insertions(+), 83 deletions(-)
base-commit: 09e41676e35ab06e4bce8870ea3bf1f191c3cb90
--
2.39.1
Use generic mbox_bind_client() to bind omap mailbox channel to a client.
mbox_bind_client is identical to the replaced lines, except that it:
- Does the operation under con_mutex which prevents possible races in
removal path
- Sets TXDONE_BY_ACK if omap uses TXDONE_BY_POLL. omap uses
TXDONE_BY_IRQ, so this check is not applicable.
- Calls chan->mbox->ops->startup, if available. omap doesn't have, so
this is not applicable.
Signed-off-by: Elliot Berman <[email protected]>
---
drivers/mailbox/omap-mailbox.c | 22 ++++------------------
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 098c82d87137..dfe82a5ff403 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -417,8 +417,6 @@ struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl,
struct device *dev = cl->dev;
struct omap_mbox *mbox = NULL;
struct omap_mbox_device *mdev;
- struct mbox_chan *chan;
- unsigned long flags;
int ret;
if (!dev)
@@ -441,23 +439,11 @@ struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl,
if (!mbox || !mbox->chan)
return ERR_PTR(-ENOENT);
- chan = mbox->chan;
- spin_lock_irqsave(&chan->lock, flags);
- chan->msg_free = 0;
- chan->msg_count = 0;
- chan->active_req = NULL;
- chan->cl = cl;
- init_completion(&chan->tx_complete);
- spin_unlock_irqrestore(&chan->lock, flags);
-
- ret = chan->mbox->ops->startup(chan);
- if (ret) {
- pr_err("Unable to startup the chan (%d)\n", ret);
- mbox_free_channel(chan);
- chan = ERR_PTR(ret);
- }
+ ret = mbox_bind_client(mbox->chan, cl);
+ if (ret)
+ return ERR_PTR(ret);
- return chan;
+ return mbox->chan;
}
EXPORT_SYMBOL(omap_mbox_request_channel);
--
2.39.1
Use generic mbox_bind_client() to bind omap mailbox channel to a client.
mbox_bind_client is identical to the replaced lines, except that it:
- Does the operation under con_mutex which prevents possible races in
removal path
- Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows
when tx is done. TXDONE_BY_ACK is already set if there's no interrupt,
so this is not applicable.
- Calls chan->mbox->ops->startup. This is usecase for requesting irq:
move the devm_request_irq into the startup callback and unregister it
in the shutdown path.
Signed-off-by: Elliot Berman <[email protected]>
---
drivers/mailbox/pcc.c | 82 ++++++++++++++++++++++++-------------------
1 file changed, 45 insertions(+), 37 deletions(-)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 105d46c9801b..3a025415c5d5 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -283,7 +283,7 @@ pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
struct pcc_chan_info *pchan;
struct mbox_chan *chan;
struct device *dev;
- unsigned long flags;
+ int rc;
if (subspace_id < 0 || subspace_id >= pcc_chan_count)
return ERR_PTR(-ENOENT);
@@ -296,30 +296,9 @@ pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
}
dev = chan->mbox->dev;
- spin_lock_irqsave(&chan->lock, flags);
- chan->msg_free = 0;
- chan->msg_count = 0;
- chan->active_req = NULL;
- chan->cl = cl;
- init_completion(&chan->tx_complete);
-
- if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
- chan->txdone_method = TXDONE_BY_ACK;
-
- spin_unlock_irqrestore(&chan->lock, flags);
-
- if (pchan->plat_irq > 0) {
- int rc;
-
- rc = devm_request_irq(dev, pchan->plat_irq, pcc_mbox_irq, 0,
- MBOX_IRQ_NAME, chan);
- if (unlikely(rc)) {
- dev_err(dev, "failed to register PCC interrupt %d\n",
- pchan->plat_irq);
- pcc_mbox_free_channel(&pchan->chan);
- return ERR_PTR(rc);
- }
- }
+ rc = mbox_bind_client(chan, cl);
+ if (rc)
+ return ERR_PTR(rc);
return &pchan->chan;
}
@@ -333,23 +312,12 @@ EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
*/
void pcc_mbox_free_channel(struct pcc_mbox_chan *pchan)
{
- struct pcc_chan_info *pchan_info = to_pcc_chan_info(pchan);
struct mbox_chan *chan = pchan->mchan;
- unsigned long flags;
if (!chan || !chan->cl)
return;
- if (pchan_info->plat_irq > 0)
- devm_free_irq(chan->mbox->dev, pchan_info->plat_irq, chan);
-
- spin_lock_irqsave(&chan->lock, flags);
- chan->cl = NULL;
- chan->active_req = NULL;
- if (chan->txdone_method == TXDONE_BY_ACK)
- chan->txdone_method = TXDONE_BY_POLL;
-
- spin_unlock_irqrestore(&chan->lock, flags);
+ mbox_free_channel(chan);
}
EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
@@ -377,8 +345,48 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
return pcc_chan_reg_read_modify_write(&pchan->db);
}
+/**
+ * pcc_startup - Called from Mailbox Controller code. Used here
+ * to request the interrupt.
+ * @chan: Pointer to Mailbox channel to startup.
+ *
+ * Return: Err if something failed else 0 for success.
+ */
+int pcc_startup(struct mbox_chan *chan)
+{
+ struct pcc_chan_info *pchan = chan->con_priv;
+ int rc;
+
+ if (pchan->plat_irq > 0) {
+ rc = devm_request_irq(chan->mbox->dev, pchan->plat_irq, pcc_mbox_irq, 0,
+ MBOX_IRQ_NAME, chan);
+ if (unlikely(rc)) {
+ dev_err(chan->mbox->dev, "failed to register PCC interrupt %d\n",
+ pchan->plat_irq);
+ return rc;
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * pcc_shutdown - Called from Mailbox Controller code. Used here
+ * to free the interrupt.
+ * @chan: Pointer to Mailbox channel to shutdown.
+ */
+void pcc_shutdown(struct mbox_chan *chan)
+{
+ struct pcc_chan_info *pchan = chan->con_priv;
+
+ if (pchan->plat_irq > 0)
+ devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
+}
+
static const struct mbox_chan_ops pcc_chan_ops = {
.send_data = pcc_send_data,
+ .startup = pcc_startup,
+ .shutdown = pcc_shutdown,
};
/**
--
2.39.1
On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
> Two mailbox controllers have channel/client binding mechanisms that are
> controller-specific and not using the devicetree binding mechanisms. Mailbox
> channel/client is conceptually done in two steps: selecting the channel
> and binding the selected to channel to a client. Channel selection is sometimes
> controller specific (pcc and omap are examples). The channel/client binding
> code is all the same.
>
> This small series de-duplicates and refactors the channel/client binding
> into a common framework function: "mbox_bind_client" which all of the
> channel selection mechanisms can use.
>
> I found this duplicate code while working on the support for Gunyah hypervisor
> message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
> however it is a straightforward conversion here.
>
> [1]: https://lore.kernel.org/all/[email protected]/
>
> Elliot Berman (3):
> mailbox: Allow direct registration to a channel
I am unable to find the above patch either in my inbox or in lore[1].
Can you please repost the same ? I would like to test/review w.r.t PCC
driver.
--
Regards,
Sudeep
[1] https://lore.kernel.org/all/[email protected]/
On 2/15/2023 2:17 AM, Sudeep Holla wrote:
> On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
>> Two mailbox controllers have channel/client binding mechanisms that are
>> controller-specific and not using the devicetree binding mechanisms. Mailbox
>> channel/client is conceptually done in two steps: selecting the channel
>> and binding the selected to channel to a client. Channel selection is sometimes
>> controller specific (pcc and omap are examples). The channel/client binding
>> code is all the same.
>>
>> This small series de-duplicates and refactors the channel/client binding
>> into a common framework function: "mbox_bind_client" which all of the
>> channel selection mechanisms can use.
>>
>> I found this duplicate code while working on the support for Gunyah hypervisor
>> message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
>> however it is a straightforward conversion here.
>>
>> [1]: https://lore.kernel.org/all/[email protected]/
>>
>> Elliot Berman (3):
>> mailbox: Allow direct registration to a channel
>
> I am unable to find the above patch either in my inbox or in lore[1].
> Can you please repost the same ? I would like to test/review w.r.t PCC
> driver.
>
Hi Sudeep,
Not sure why the patch didn't end up your inbox; lore seems to have
linked it correctly and indicates you were in To:. If I missed
something, let me know and I'll make sure you're properly included if
future versions needed.
https://lore.kernel.org/all/[email protected]/
Thanks,
Elliot
> --
> Regards,
> Sudeep
>
> [1] https://lore.kernel.org/all/[email protected]/
>
On Wed, Feb 15, 2023 at 08:58:10AM -0800, Elliot Berman wrote:
>
>
> On 2/15/2023 2:17 AM, Sudeep Holla wrote:
> > On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
> > > Two mailbox controllers have channel/client binding mechanisms that are
> > > controller-specific and not using the devicetree binding mechanisms. Mailbox
> > > channel/client is conceptually done in two steps: selecting the channel
> > > and binding the selected to channel to a client. Channel selection is sometimes
> > > controller specific (pcc and omap are examples). The channel/client binding
> > > code is all the same.
> > >
> > > This small series de-duplicates and refactors the channel/client binding
> > > into a common framework function: "mbox_bind_client" which all of the
> > > channel selection mechanisms can use.
> > >
> > > I found this duplicate code while working on the support for Gunyah hypervisor
> > > message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
> > > however it is a straightforward conversion here.
> > >
> > > [1]: https://lore.kernel.org/all/[email protected]/
> > >
> > > Elliot Berman (3):
> > > mailbox: Allow direct registration to a channel
> >
> > I am unable to find the above patch either in my inbox or in lore[1].
> > Can you please repost the same ? I would like to test/review w.r.t PCC
> > driver.
> >
>
> Hi Sudeep,
>
> Not sure why the patch didn't end up your inbox; lore seems to have linked
> it correctly and indicates you were in To:. If I missed something, let me
> know and I'll make sure you're properly included if future versions needed.
>
> https://lore.kernel.org/all/[email protected]/
No, I do have patch 2/3 and 3/3 in my inbox along with the cover letter.
Patch 1/3 is missing in both my inbox and lore. Can you send me the lore
link for patch 1/3 if you are able to find it ? Or just repost the series
if you can't.
--
Regards,
Sudeep
Support virtual mailbox controllers and clients which are not platform
devices or come from the devicetree by allowing them to match client to
channel via some other mechanism.
Signed-off-by: Elliot Berman <[email protected]>
---
drivers/mailbox/mailbox.c | 96 ++++++++++++++++++++++++----------
include/linux/mailbox_client.h | 1 +
2 files changed, 69 insertions(+), 28 deletions(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 4229b9b5da98..adf36c05fa43 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -317,6 +317,71 @@ int mbox_flush(struct mbox_chan *chan, unsigned long timeout)
}
EXPORT_SYMBOL_GPL(mbox_flush);
+static int __mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl)
+{
+ struct device *dev = cl->dev;
+ unsigned long flags;
+ int ret;
+
+ if (chan->cl || !try_module_get(chan->mbox->dev->driver->owner)) {
+ dev_dbg(dev, "%s: mailbox not free\n", __func__);
+ return -EBUSY;
+ }
+
+ spin_lock_irqsave(&chan->lock, flags);
+ chan->msg_free = 0;
+ chan->msg_count = 0;
+ chan->active_req = NULL;
+ chan->cl = cl;
+ init_completion(&chan->tx_complete);
+
+ if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
+ chan->txdone_method = TXDONE_BY_ACK;
+
+ spin_unlock_irqrestore(&chan->lock, flags);
+
+ if (chan->mbox->ops->startup) {
+ ret = chan->mbox->ops->startup(chan);
+
+ if (ret) {
+ dev_err(dev, "Unable to startup the chan (%d)\n", ret);
+ mbox_free_channel(chan);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * mbox_bind_client - Request a mailbox channel.
+ * @chan: The mailbox channel to bind the client to.
+ * @cl: Identity of the client requesting the channel.
+ *
+ * The Client specifies its requirements and capabilities while asking for
+ * a mailbox channel. It can't be called from atomic context.
+ * The channel is exclusively allocated and can't be used by another
+ * client before the owner calls mbox_free_channel.
+ * After assignment, any packet received on this channel will be
+ * handed over to the client via the 'rx_callback'.
+ * The framework holds reference to the client, so the mbox_client
+ * structure shouldn't be modified until the mbox_free_channel returns.
+ *
+ * Return: 0 if the channel was assigned to the client successfully.
+ * <0 for request failure.
+ */
+int mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl)
+{
+ int ret;
+
+ mutex_lock(&con_mutex);
+ ret = __mbox_bind_client(chan, cl);
+ mutex_unlock(&con_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(mbox_bind_client);
+
/**
* mbox_request_channel - Request a mailbox channel.
* @cl: Identity of the client requesting the channel.
@@ -340,7 +405,6 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
struct mbox_controller *mbox;
struct of_phandle_args spec;
struct mbox_chan *chan;
- unsigned long flags;
int ret;
if (!dev || !dev->of_node) {
@@ -372,33 +436,9 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
return chan;
}
- if (chan->cl || !try_module_get(mbox->dev->driver->owner)) {
- dev_dbg(dev, "%s: mailbox not free\n", __func__);
- mutex_unlock(&con_mutex);
- return ERR_PTR(-EBUSY);
- }
-
- spin_lock_irqsave(&chan->lock, flags);
- chan->msg_free = 0;
- chan->msg_count = 0;
- chan->active_req = NULL;
- chan->cl = cl;
- init_completion(&chan->tx_complete);
-
- if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
- chan->txdone_method = TXDONE_BY_ACK;
-
- spin_unlock_irqrestore(&chan->lock, flags);
-
- if (chan->mbox->ops->startup) {
- ret = chan->mbox->ops->startup(chan);
-
- if (ret) {
- dev_err(dev, "Unable to startup the chan (%d)\n", ret);
- mbox_free_channel(chan);
- chan = ERR_PTR(ret);
- }
- }
+ ret = __mbox_bind_client(chan, cl);
+ if (ret)
+ chan = ERR_PTR(ret);
mutex_unlock(&con_mutex);
return chan;
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index 65229a45590f..734694912ef7 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -37,6 +37,7 @@ struct mbox_client {
void (*tx_done)(struct mbox_client *cl, void *mssg, int r);
};
+int mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl);
struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl,
const char *name);
struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index);
--
2.39.1
On 2/16/2023 1:58 AM, Sudeep Holla wrote:
> On Wed, Feb 15, 2023 at 08:58:10AM -0800, Elliot Berman wrote:
>>
>>
>> On 2/15/2023 2:17 AM, Sudeep Holla wrote:
>>> On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
>>>> Two mailbox controllers have channel/client binding mechanisms that are
>>>> controller-specific and not using the devicetree binding mechanisms. Mailbox
>>>> channel/client is conceptually done in two steps: selecting the channel
>>>> and binding the selected to channel to a client. Channel selection is sometimes
>>>> controller specific (pcc and omap are examples). The channel/client binding
>>>> code is all the same.
>>>>
>>>> This small series de-duplicates and refactors the channel/client binding
>>>> into a common framework function: "mbox_bind_client" which all of the
>>>> channel selection mechanisms can use.
>>>>
>>>> I found this duplicate code while working on the support for Gunyah hypervisor
>>>> message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
>>>> however it is a straightforward conversion here.
>>>>
>>>> [1]: https://lore.kernel.org/all/[email protected]/
>>>>
>>>> Elliot Berman (3):
>>>> mailbox: Allow direct registration to a channel
>>>
>>> I am unable to find the above patch either in my inbox or in lore[1].
>>> Can you please repost the same ? I would like to test/review w.r.t PCC
>>> driver.
>>>
>>
>> Hi Sudeep,
>>
>> Not sure why the patch didn't end up your inbox; lore seems to have linked
>> it correctly and indicates you were in To:. If I missed something, let me
>> know and I'll make sure you're properly included if future versions needed.
>>
>> https://lore.kernel.org/all/[email protected]/
>
> No, I do have patch 2/3 and 3/3 in my inbox along with the cover letter.
> Patch 1/3 is missing in both my inbox and lore. Can you send me the lore
> link for patch 1/3 if you are able to find it ? Or just repost the series
> if you can't.
>
Huh, not sure what happened there. I got a copy of Patch 1/3 but I also
don't see it in lore. Resent:
https://lore.kernel.org/all/[email protected]/
On Thu, Feb 16, 2023 at 08:41:05AM -0800, Elliot Berman wrote:
>
>
> On 2/16/2023 1:58 AM, Sudeep Holla wrote:
> > On Wed, Feb 15, 2023 at 08:58:10AM -0800, Elliot Berman wrote:
> > >
> > >
> > > On 2/15/2023 2:17 AM, Sudeep Holla wrote:
> > > > On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
> > > > > Two mailbox controllers have channel/client binding mechanisms that are
> > > > > controller-specific and not using the devicetree binding mechanisms. Mailbox
> > > > > channel/client is conceptually done in two steps: selecting the channel
> > > > > and binding the selected to channel to a client. Channel selection is sometimes
> > > > > controller specific (pcc and omap are examples). The channel/client binding
> > > > > code is all the same.
> > > > >
> > > > > This small series de-duplicates and refactors the channel/client binding
> > > > > into a common framework function: "mbox_bind_client" which all of the
> > > > > channel selection mechanisms can use.
> > > > >
> > > > > I found this duplicate code while working on the support for Gunyah hypervisor
> > > > > message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
> > > > > however it is a straightforward conversion here.
> > > > >
> > > > > [1]: https://lore.kernel.org/all/[email protected]/
> > > > >
> > > > > Elliot Berman (3):
> > > > > mailbox: Allow direct registration to a channel
> > > >
> > > > I am unable to find the above patch either in my inbox or in lore[1].
> > > > Can you please repost the same ? I would like to test/review w.r.t PCC
> > > > driver.
> > > >
> > >
> > > Hi Sudeep,
> > >
> > > Not sure why the patch didn't end up your inbox; lore seems to have linked
> > > it correctly and indicates you were in To:. If I missed something, let me
> > > know and I'll make sure you're properly included if future versions needed.
> > >
> > > https://lore.kernel.org/all/[email protected]/
> >
> > No, I do have patch 2/3 and 3/3 in my inbox along with the cover letter.
> > Patch 1/3 is missing in both my inbox and lore. Can you send me the lore
> > link for patch 1/3 if you are able to find it ? Or just repost the series
> > if you can't.
> >
>
> Huh, not sure what happened there. I got a copy of Patch 1/3 but I also
> don't see it in lore. Resent:
>
> https://lore.kernel.org/all/[email protected]/
Thanks.
You can add(tested PCC driver)
Tested-by: Sudeep Holla <[email protected]>
--
Regards,
Sudeep