All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Joseph Lo <josephl@nvidia.com>
Subject: Re: Using the mailbox subsystem for plain doorbells?
Date: Tue, 10 May 2016 09:56:58 -0600	[thread overview]
Message-ID: <573204CA.8080808@wwwdotorg.org> (raw)
In-Reply-To: <CABb+yY1Oss376KOgDcpDAHauamECn9r4NA5x=KL3y3UWMh9C2A@mail.gmail.com>

On 05/09/2016 09:29 PM, Jassi Brar wrote:
> On Tue, May 10, 2016 at 5:15 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> Jassi,
>>
>> Does the HW described below sound like something that should be represented
>> using the Linux kernel's mailbox subsystem, and related DT bindings? I think
>> the existing drivers/mailbox/pcc.c is similar, but wanted to double-check.
>>
>> We have some HW that literally just allows a SW-generated interrupt to be
>> generated by our main CPU complex to an auxiliary CPU, and likewise a
>> different interrupt can be generated in the opposite direction. There's no
>> ability to transfer any data; just an IRQ is generated. Our current mailbox
>> implementation just handles IRQ generation/reception so struct
>> mbox_chan_ops.send_data completely ignores the data parameter, and our IRQ
>> handler "receives" hard-coded NULL messages when the IRQ fires. Higher level
>> protocol code (using shared memory along with the plain-IRQ mbox channels)
>> is outside the mailbox driver.
>>
>> Does that fit the mailbox subsystem?
>>
>  From the sound of it, yes.

Good to know, thanks.

> Some controllers need a mask/list of destination cpus, to which the
> irq is raised, written to some 'data' register. You too probably need
> to program the destination "id" in the controller? Maybe that should
> be done in send_data().

In this case, each mailbox communicates with a different remote CPU, and 
there's a separate register to communicate with each remote CPU. So, 
send_data() completely ignores the data parameter since everything is 
derived from the mailbox's identity.

  reply	other threads:[~2016-05-10 15:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 23:45 Using the mailbox subsystem for plain doorbells? Stephen Warren
2016-05-10  3:29 ` Jassi Brar
2016-05-10 15:56   ` Stephen Warren [this message]
2016-05-10 16:10     ` Jassi Brar

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=573204CA.8080808@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=josephl@nvidia.com \
    --cc=linux-kernel@vger.kernel.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: link
Be 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.