Re: [PATCHv3 00/14] drivers: mailbox: framework creation

From: Andy Green
Date: Fri Apr 26 2013 - 21:48:35 EST

On 27/04/13 09:04, the mail apparently from Suman Anna included:

Hi Suman -

Even though both the scenarios look very similar, I believe there are
some slight differences. All the devices belonging to a controller may
not be of the same type (meaning, intended towards the same remote or be
used interchangeably with one another). It is definitely possible if you
have a similar scenario to the DMA physical channels and your remote
rx interrupt can identify the device/channel to process. This would be
very much dependent on the architecture of a controller. The particular
example that I have in mind is s/w clients between the same set of
remote and host entities using the same device - the send part is anyway
arbitrated by the controller, and the same received message can be
delivered to the clients, with the clients making the decision whether
the packet belongs to them or not. I agree that all remote-ends will not
be able to cope up intermixed requests, but isn't this again a
controller architecture dependent?

Maybe it's helpful to describe our situation more concretely, because the problem is not coming from "the architecture of the [mailbox] controller".

In the SoC we work on clock and subsystem power control registers, a serial bus, and some other assets are not directly accessible from Linux. We must ask a coprocessor to operate these for us, using the mailbox.

So at any one time, the clock driver or voltagedomain driver for the SoC may want to own the mailbox and perform one or more operations over it synchronously, in some cases on the remote side involving transactions on a serial bus. We don't want other transactions to be occurring while we wait for the serial bus to complete what the driver who started that asked for, for example.

We can cope with this by having an outer driver mediate access to the mailbox. But then there are multiple sync primitives like completions and notifiers per operation, because your core already does this.

In short the FIFO + sync operations approach your core implements doesn't fit our use case. That can be our problem, in which case we'll live with the outer mediation driver on top of the mailbox, or it can be a sign the fixed choice of FIFO + sync operations in your core did not quite hit the nail on the head to really model all the facets of legit mailbox usage.

At least, this real scenario should be interesting to think about before rejecting ^^


Andy Green | Fujitsu Landing Team Leader â Open source software for ARM SoCs | Follow Linaro -!/linaroorg -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at