[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171101221217.GA28761@minitux>
Date: Wed, 1 Nov 2017 15:12:17 -0700
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Jassi Brar <jassisinghbrar@...il.com>
Cc: Sudeep Holla <sudeep.holla@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] mailbox: add support for doorbell/signal mode controllers
On Wed 01 Nov 11:03 PDT 2017, Jassi Brar wrote:
> On Wed, Nov 1, 2017 at 10:02 PM, Sudeep Holla <sudeep.holla@....com> wrote:
[..]
> >
> > This is rough idea I have on extending mailbox interface to support
> > the doorbell requirements.
> >
> What doorbell requirements does the api not support?
> QComm's APCS IPC is what you call a "doorbell" controller and is
> already supported by the API. It could run SCMI even easier than MHU
> (your controller).
>
I agree; from a mbox consumer perspective a doorbell should be a mailbox
channel that when signalled will ring the bell, i.e. the message is not
significant and should not be provided by the client.
If the message is significant and is not derived from the mailbox
channel (e.g. channel id -> bit in register) it is not a mailbox
doorbell, it's s regular mailbox used as a doorbell.
The potential improvement I see in the Qualcomm case is to wrap the
mbox_send_message(chan, NULL); mbox_client_txdone(chan, 0); calls in one
simple "mbox_ring_door_bell(chan)" - but I haven't investigated the
validity of this as a generic function.
Regards,
Bjorn
Powered by blists - more mailing lists