[RFC] mailbox: Add Broadcom BCM2835 mailbox driver

[Stephen Warren]

On 08/16/2013 03:44 AM, Craig McGeachie wrote:
> On Sat May 11 00:41:55 EDT 2013, Stephen Warren wrote:
>> On 04/19/2013 12:51 PM, Simon Arlott wrote:
>>> On
>  17/04/13 13:56, Lubomir Rintel wrote: >>>Hello! 
>>>>>>> This adds a driver for mailbox IPC mechanism 
> present on Broadcom >>>BCM2835 SoC, used in Raspberry Pi and 
> Roku 2 devices. >>>>I already wrote a driver for this and 
> other devices 11 months ago: >>>>https://github.com/lp0/linux/commit/917bdfc3045151cda896bf0cbf1542340892f58d >
>> Lubomir, I assume this patch is intended as a submission for upstream?
>> You should probably also Cc linux-arm-kernel at lists.infradead.org on all
>> patches destined for upstream.
>>
>> The problem here (with Simon's existing patch) is that it was never sent
>> upstream. Hence, most likely very few people know about it. If you start
>> pro-actively sending your work upstream, that'd be great. One possible
>> issue with your original patch is that there's now a mailbox subsystem
>> upstream which I don't think your patch used (and at a very quick
>> glance, Lubomir's patch uses), and any new driver upstream would have to
>> use that. 
> 
> 
> I don't see what you're referring to as a mailbox subsystem.  Unless you're referring to this:
> https://github.com/torvalds/linux/commit/300586778d405f0a4d1f6dc51fcfb4fed567d020
> 
> I thought subsystem was something like the character driver subsystem, which had a well
> defined registration structure, functions for you to call, and operations that had to be
> implemented. This just looks like a driver grouping and a header file that I want to move.

I haven't looked at driver/mailbox or drivers/remoteproc in any detail.
I would certainly hope one/both has a standard API, but perhaps not. It
would be a bit unfortunate if not.

> I'm comfortable with the idea of a drivers/mailbox directory because that fits with how drivers
> are grouped, and mailboxes are definitely a valid class of driver.  What bothers me is that a
> single header file defines the interfaces for all mailbox driver implementations.  Even in a
> multi architecture kernel, this option doesn't seem to make sense.  I don't want to include
> declarations for every module under the sun, especially if there is a good chance that some
> of them don't have implementations in the current kernel build.
> 
> There currently aren't any declarations in the file other than those specific to the PL320.
> Looking at other driver types, these would be better defined under drivers/mailbox/pl320.
> 
> Think it would be worth me proposing an upstream patch?

The best approach is probably to abstract the interface so that multiple
different implementations can share the same API. The API would still
need to be defined in include/linux/mailbox.h so that everything would
have access to it.

include/linux/remoteproc.h seems like it might be less HW-specific,
although I haven't taken any time to understand it at all.