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