* Using the mailbox subsystem for plain doorbells?
@ 2016-05-09 23:45 Stephen Warren
2016-05-10 3:29 ` Jassi Brar
0 siblings, 1 reply; 4+ messages in thread
From: Stephen Warren @ 2016-05-09 23:45 UTC (permalink / raw)
To: Jassi Brar; +Cc: linux-kernel, Joseph Lo
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Using the mailbox subsystem for plain doorbells?
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
0 siblings, 1 reply; 4+ messages in thread
From: Jassi Brar @ 2016-05-10 3:29 UTC (permalink / raw)
To: Stephen Warren; +Cc: linux-kernel, Joseph Lo
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.
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().
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Using the mailbox subsystem for plain doorbells?
2016-05-10 3:29 ` Jassi Brar
@ 2016-05-10 15:56 ` Stephen Warren
2016-05-10 16:10 ` Jassi Brar
0 siblings, 1 reply; 4+ messages in thread
From: Stephen Warren @ 2016-05-10 15:56 UTC (permalink / raw)
To: Jassi Brar; +Cc: linux-kernel, Joseph Lo
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Using the mailbox subsystem for plain doorbells?
2016-05-10 15:56 ` Stephen Warren
@ 2016-05-10 16:10 ` Jassi Brar
0 siblings, 0 replies; 4+ messages in thread
From: Jassi Brar @ 2016-05-10 16:10 UTC (permalink / raw)
To: Stephen Warren; +Cc: linux-kernel, Joseph Lo
On Tue, May 10, 2016 at 9:26 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 05/09/2016 09:29 PM, Jassi Brar wrote:
>
>> 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.
>
Yes, that is ok. For example, mailbox-sti.c does that.
Cheers!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-05-10 16:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2016-05-10 16:10 ` Jassi Brar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).