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:
>>>> +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.
Attachment:
signature.asc
Description: PGP signature
