Device tree review #2
Simon Arlott
simon at fire.lp0.eu
Thu Jun 21 02:34:02 EDT 2012
On 21/06/12 02:43, Stephen Warren wrote:
> On 06/20/2012 02:24 PM, Simon Arlott wrote:
>> On 20/06/12 04:48, Stephen Warren wrote:
>>>> power: regulator {
>>>> compatible = "broadcom,bcm2835-power-mgr", "broadcom,bcm2708-power-mgr", "simple-bus";
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>
>>> Given that the power manager is a core part of the SoC, I'd expect most
>>> of this node to be in bcm2835.dtsi, not the board-specific file. The
>>> board file can always add or override any properties that need to be set
>>> in a board-specific way, perhaps such as the voltages.
>>
>> The power manager is not part of the SoC, it's part of the Raspberry Pi
>> version of the VideoCore,
>
> "version of the VideoCore" /firmware/ I suppose.
>
>> so it should be in the rpi board file. If we
>> get direct access to the power management then that situation will
>> change.
>
> By that argument, isn't the display controller also something that
> should be in bcm2835-rpi-b.dts rather than bcm2835.dtsi, since it's also
> purely firmware-based?
Yes.
>>>> broadcom,vc-mailbox = <&vc_mbox>;
>>>> broadcom,vc-channel = <0>;
>>>>
>>>> regulator-name = "VideoCore";
>>>> regulator-min-microvolt = <5000000>;
>>>> regulator-max-microvolt = <5000000>;
>>>> regulator-always-on = <1>;
>>>
>>> It's not clear to me why one regulator is defined at the "top" level
>>> directly as part of the power manager device, whereas the other two are
>>> defined as child nodes; I would expect to see all 3 regulators defined
>>> as child nodes.
>>
>> I need a parent device as there's currently only a single bit map for
>> all powered devices, which the child regulators need to share.
>
> You can still have a parent device that exists solely to host 3
> regulator child devices, rather than having the top-level node be one of
> the regulators, with (a presumably arbitrarily selected) couple of child
> nodes.
It's not arbitrary, the top one doesn't control anything.
--
Simon Arlott
More information about the linux-rpi-kernel
mailing list