Hi Hari,

On Wed, Jul 21, 2010 at 12:41 AM, Hari Kanigeri <h-kanige...@ti.com> wrote:
> This patch provides mutiple readers support for a mailbox
> instance.
>
> Signed-off-by: Hari Kanigeri <h-kanige...@ti.com>
> ---
>  arch/arm/plat-omap/include/plat/mailbox.h |    6 ++-
>  arch/arm/plat-omap/mailbox.c              |   63 ++++++++++++++++------------
>  2 files changed, 40 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
> b/arch/arm/plat-omap/include/plat/mailbox.h
> index 0486d64..c8e47d8 100644
> --- a/arch/arm/plat-omap/include/plat/mailbox.h
> +++ b/arch/arm/plat-omap/include/plat/mailbox.h
> @@ -68,13 +68,15 @@ struct omap_mbox {
>        void                    *priv;
>
>        void                    (*err_notify)(void);
> +       atomic_t                use_count;
> +       struct blocking_notifier_head   notifier;
>  };
>
>  int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
>  void omap_mbox_init_seq(struct omap_mbox *);
>
> -struct omap_mbox *omap_mbox_get(const char *);
> -void omap_mbox_put(struct omap_mbox *);
> +struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);

In this context, I'd like to change notifier to support adding a
cookie which will be passed back to the handler function (unmodified,
in a similar manner to request_irq's void *dev param).

This cookie param will be passed to the mailbox callback whenever a
mailbox event is triggered, and will allow drivers to have multiple
instances: instead of maintaining their state in a global variable
(like bridge is doing today), it will be given back every time a
mailbox event is delivered. For syslink it will also help using the
same mbox callback for different devices (e.g. sysm3, appm3).

The changes should be minor, and shouldn't affect existing notifier
users, here's the diff (untested):

diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 540703b..e740aea 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -51,6 +51,7 @@ struct notifier_block {
        int (*notifier_call)(struct notifier_block *, unsigned long, void *);
        struct notifier_block *next;
        int priority;
+       void *dev_id;
 };

 struct atomic_notifier_head {
diff --git a/kernel/notifier.c b/kernel/notifier.c
index 2488ba7..050fd9b 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -64,6 +64,7 @@ static int notifier_chain_unregister(struct notifier_block **n
  *     @nl:            Pointer to head of the blocking notifier chain
  *     @val:           Value passed unmodified to notifier function
  *     @v:             Pointer passed unmodified to notifier function
+ *                     If pointer is NULL, the notifier block's
cookie is passed
  *     @nr_to_call:    Number of notifier functions to be called. Don't care
  *                     value of this parameter is -1.
  *     @nr_calls:      Records the number of notifications sent. Don't care
@@ -90,6 +91,7 @@ static int __kprobes notifier_call_chain(struct notifier_block
                        continue;
                }
 #endif
+               v = v ? v : nb->dev_id;
                ret = nb->notifier_call(nb, val, v);

                if (nr_calls)


And the only change in your mbox patch should be:

@@ -149,8 +149,8 @@ static void mbox_rx_work(struct work_struct *work)
               if (unlikely(len != sizeof(msg)))
                       pr_err("%s: kfifo_out anomaly detected\n", __func__);

-               blocking_notifier_call_chain(&mq->mbox->notifier, len,
-                                                       (void *)msg);
+               blocking_notifier_call_chain(&mq->mbox->notifier, msg, NULL);
       }
 }

The result should be us getting both the mailbox msg and the original
cookie, which will, in our case, be the context of the relevant
dspbridge or syslink driver.

What do you think ?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to