Using the mailbox subsystem for plain doorbells?
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?
Quoted 16 lines · Stephen Warren
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.cis 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.
Quoted 3 lines
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().
Quoted 17 lines · Jassi Brar
Quoted 16 lines · Stephen Warren
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.cis 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.
Quoted 3 lines
Quoted 2 lines
Does that fit the mailbox subsystem?
From the sound of it, yes.
Good to know, thanks.
Quoted 4 lines
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.
Quoted 8 lines · Stephen Warren
Quoted 4 lines · Jassi Brar
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().
Quoted 5 lines
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!