[RFC PATCH 3/3] Enable BCM2835 mailbox support

[Craig McGeachie]

On 03/07/14 03:33, Stephen Warren wrote:
> I don't recall any details, but surely any mbox driver should expose a
> separate channel for each type of communication, and then mux them all
> into the single HW mbox mechanism. Then, e.g. the DMA driver or display
> driver could exclusively acquire their own channel, but without
> conflicting with any drivers using any other channel.

I'm a bit twitchy about any statement that starts with "surely" but have 
no further rationale.  I didn't actually think about this myself at the 
time, so I am making a lot of this up as I go along.

Firstly, I think there may be a misunderstanding.  The bcm2835 mbox has 
number of channels, identified by the low order 4 bits in the 32 bit 
value passed in the register.  The driver that Lubomir and I wrote 
exposes those channels, and multiplexes all of them through the same 
register.  So there is a framebuffer channel, that the framebuffer 
driver would acquire when the module is probed, and released when the 
module is removed.  No other driver should use that.  There is the 
property channel which is a grab bag of get/set methods.  This is the 
one that the thermal driver only acquires when it is reading a 
temperature, and releases straight away.  That is because other drivers 
will want to also use the properties channel.

It might be possible to create an extra level of multiplexing such that 
there was a second mailbox driver that acquired the property channel 
exclusively, and then published virtual channels.

It would be desirable if it somehow made things faster. But I don't see 
any usage that is going to be bogged down by acquiring the channel as 
needed.  Something that used a channel more often than every 1 to 10 
milliseconds maybe.  I don't really have a good feel for what a critical 
breakpoint would be.

Multiplexing would be acceptable if there were no stateful relationship 
between successive messages.    If it was necessary to ensure that two 
messages were consecutive, then there would be a need for transaction 
begin/end functions or a batched messaging function.  Acquiring and 
releasing the property channel directly seems just a good for this as 
anything else would be.

I don't think there is any inherent stateful relationship between 
messages, but some of the property messages come in pairs, such as 
get/set power state, get/set clock state.  I could see the driver for 
one device wishing to modify it's power state without interferring with 
the power state of any other device, which would require a get/set power 
state message pair without an interleaving get/set power state message 
pair from any other driver.

And apart from anything else, I'm still not happy about how all of this 
is going to be represented in the device tree.

Cheers,
Craig.