Stephen Warren <swarren@xxxxxxxxxxxxx> writes:
> On 03/03/2015 12:28 PM, Eric Anholt wrote:
>> Lee Jones <lee@xxxxxxxxxx> writes:
>>
>>> On Mon, 02 Mar 2015, Eric Anholt wrote:
>>>
>>>> From: Lubomir Rintel <lkundrak@xxxxx>
>>>>
>>>> v2: Split into a separate patch for submitting to the
>>>> devicetree list.
> ...
>>>> ---
>
> Generally, the changelog should go below the --- since most people
> don't want to see the changelog committed into the source.
Huh. I'm coming from drivers/gpu/drm/ (and non-kernel communities)
where people are expected to keep changelog in the commit message. I'll
strip it out of this series.
>>>> .../devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt | 19
>>>> +++++++++++++++++++ 1 file changed, 19 insertions(+) create
>>>> mode 100644
>>>> Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>>>>
>>>>
>>>>
>>>>
> diff --git
> a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
> b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>>>> new file mode 100644 index 0000000..f5741a0 --- /dev/null +++
>>>> b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>>>
>>>
>>>>
>>>>
> Rename these files to conform to the current naming convention. In
>>> -next we currently have 'altera-mailbox.txt' and
>>> 'omap-mailbox.txt', so 'bcm2835-mbox.txt' seems appropriate.
>>
>> Will do.
>
> I believe all the current bcm2835 bindings use the compatible value as
> the filename. I personally prefer this to picking a different "random"
> name for the filenames. It means you only have to name the thing once,
> and then use the same value for the compatible property and binding
> document.
"git grep brcm | grep 2835" thinks that we're quite confused on whether
you put the "brcm," in the filename or not. And then there's some that
don't follow either convention:
watchdog/brcm,bcm2835-pm-wdog.txt: compatible = "brcm,bcm2835-pm-wdt";
pwm/pwm-bcm2835.txt: compatible = "brcm,bcm2835-pwm";
rng/brcm,bcm2835.txt: compatible = "brcm,bcm2835-rng";
>>>> +Example: + +mailbox: mailbox@7e00b800 { + compatible =
>>>> "brcm,bcm2835-mbox"; + reg = <0x7e00b880 0x40>; + interrupts =
>>>> <0 1>; + #mbox-cells = <1>; +};
>>>
>>> It would be good to see the client examples here as well.
>>> Please consider pulling in brcm,bcm2835-mbox-power.txt and
>>> brcm,bcm2835-mbox-property.txt.
>>
>> Oh, so have those two just smashed into this file as one set of
>> documentation for everything to do with mailbox on bcm2835? That
>> seems good to me. When I was adding the client drivers, the fact
>> that the other brcm file was named after the compatible string
>> made me generate new files under then new compatible strings, but
>> the other drivers already in the tree obviously aren't formatted
>> that way.
>
> The HW mailbox seems like a different process to the upper-layer
> protocols/message formats running over the top of it. Sure right now
> the Pi has a single firmware, but do all bcm2835-based devices share
> the same firmware? Is so, we'd be warranted in lumping the HW and
> firmware protocol together, but I rather wonder whether e.g. the
> bcm2835-based Roku uses the same firmware protocol?
I don't know the answer to that one, and I've only got RPi firmware
myself.
Ultimately, my hope is to get enough merged that we can basically get
off the firmware, other than the bits of clock management that are only
doable from the VPU.
Attachment:
signature.asc
Description: PGP signature
