Thread (1 message) 1 message, 1 author, 2015-03-20

[PATCH 3/4 v4] mailbox: Enable BCM2835 mailbox support

From: jassisinghbrar@gmail.com (Jassi Brar)
Date: 2015-03-20 05:12:35
Also in: linux-devicetree

On Fri, Mar 20, 2015 at 10:18 AM, Stephen Warren [off-list ref] wrote:
On 03/18/2015 05:28 PM, Eric Anholt wrote:
quoted
Stephen Warren [off-list ref] writes:
quoted
On 03/12/2015 08:32 PM, Eric Anholt wrote:
quoted
diff --git a/drivers/mailbox/bcm2835-mailbox.c
b/drivers/mailbox/bcm2835-mailbox.c
quoted
+#define MBOX_MSG(chan, data28)             (((data28) & ~0xf) | ((chan) &
0xf)) +#define MBOX_CHAN(msg)                       ((msg) & 0xf) +#define
MBOX_DATA28(msg)            ((msg) & ~0xf)
Even the concept of storing channel IDs in the LSBs feels like it
might be RPi-firmware-specific rather than HW-specific?
I guess?  If we found another firmware protocol, we could have
that device's dt just specify a different compatible string.  But
in the absence of another firmware to talk to, I'm not sure what
you want here.
I would expect the mailbox driver to expose a single channel that just
transports 32-bit values, since the HW doesn't impose any kind of
structure on the values it transports AFAIK. Clients of the mailbox
driver would formulate the messages they send through the mailox using
the macros above.
Yes, it should be so.
I'm not sure whether the mailbox core allows multiple clients for the
same mailbox channel though? This HW appears to require it.
There were tradeoffs to granting shared vs exclusive access, we chose
latter. The platform could have a global client that serializes
requests and dispatch received data to exact destination rather than
mbox core iterating over all users of the channel. Some platform may
require to execute 2 or more commands 'atomically', which would be
messy if channels are shared.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help