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

[Stephen Warren]

On 07/28/2016 01:07 PM, Rob Herring wrote:
> 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>;

Sigh. Can you please talk to Thierry and work out what the binding would 
be (perhaps on IRC to expedite things?) and I'll just implement whatever 
you two agree upon. I don't really care much what the binding looks like 
any more; I just need something that will pass review. Thanks.