On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> 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@xxxxxxxxxx>
>>>
>>> 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@xxxxxxxxxx>
>>> ---
>>> .../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@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@0 {
reg = <0>;
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
