[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Rob Herring]

On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>
>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>
>>> From: Stephen Warren <swarren at nvidia.com>
>>>
>>> The BPMP implements some services which must be represented by separate
>>> nodes. For example, it can provide access to certain I2C controllers, and
>>> the I2C bindings represent each I2C controller as a device tree node.
>>> Update the binding to describe how the BPMP supports this.
>>>
>>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>>> ---
>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>> ++++++++++++++++++++++
>>>  1 file changed, 23 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> index 9a3864f56955..142d363406f6 100644
>>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>  - .../reset/reset.txt
>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>
>>> +The BPMP implements some services which must be represented by separate
>>> nodes.
>>> +For example, it can provide access to certain I2C controllers, and the
>>> I2C
>>> +bindings represent each I2C controller as a device tree node. Such nodes
>>> should
>>> +be nested directly inside the main BPMP node.
>>> +
>>> +Software can determine whether a child node of the BPMP node represents
>>> a device
>>> +by checking for a compatible property. Any node with a compatible
>>> property
>>> +represents a device that can be instantiated. Nodes without a compatible
>>> +property may be used to provide configuration information regarding the
>>> BPMP
>>> +itself, although no such configuration nodes are currently defined by
>>> this
>>> +binding.
>>> +
>>> +The BPMP firmware defines no single global name-/numbering-space for
>>> such
>>> +services. Put another way, the numbering scheme for I2C buses is
>>> distinct from
>>> +the numbering scheme for any other service the BPMP may provide (e.g. a
>>> future
>>> +hypothetical SPI bus service). As such, child device nodes will have no
>>> reg
>>> +property, and the BPMP node will have no #address-cells or #size-cells
>>> property.
>>
>>
>> My understanding is that the I2C bus number is passed as part of the
>> request to the BPMP firmware. Does that not count as addressing? Could
>> we not represent that generically using a device tree hierarchy? I'm
>> thinking something along these lines:
>>
>>         bpmp {
>>                 ...
>>
>>                 services {
>>                         i2c {
>>                                 i2c at 0 {
>>                                         reg = <0>;
>
>
> Technically, that is possible. However, Rob Herring rejected the idea of
> multiple levels of sub-nodes.

I think I questioned the need, not rejected. What about the above, but
remove serivces level:

         bpmp {
                 ...

                 i2c {
                         i2c at 0 {
                                 reg = <0>;

Rob