[RFC PATCH 3/3] Enable BCM2835 mailbox support
slapdau at yahoo.com.au
Wed Jul 2 23:33:02 PDT 2014
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.
More information about the linux-rpi-kernel