Re: [PATCH 01/10] dt/bindings: Add binding for BCM2835 mailbox driver

Stephen Warren [off-list ref] writes:

On 03/03/2015 12:28 PM, Eric Anholt wrote:

quoted

Lee Jones [off-list ref] writes:

quoted

On Mon, 02 Mar 2015, Eric Anholt wrote:

quoted

+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've confirmed: While their firmware would have been forked from the
same source, there's no reason to expect their shipped firmware
protocols (like my power domain or property channel drivers use) to
match RPi's.

The power-domain rework ended up not working out -- it needs the
power-domain part of device/base to support throwing -EPROBE_DEFER if
the driver hasn't probed yet, unless we're willing to just bake in the
power domain driver in static init ordering.  Device base maintainers
weren't excited about my patch for -EPROBE_DEFER, because then a new DT
would mean we start failing to probe the USB driver in an older kernel,
which whould be a regression in the case that the user had U-Boot
setting up USB for them.

Meanwhile, it looks like the thing being done in the firmware for USB is
not just a power domain, but also configuration of the USB PHY.  This
led me to wonder if I could just write native support for the PHY and
the power domains instead of asking the firmware to do it, but this is
going to take more investigation.

As a result, I'm going to shelve my power domain and property channel
work for the moment, and just submit the core mailbox support that I
feel pretty confident about for now.