Firmware node has more than fpga, aes and clock child nodes but also power,
reset, gpio, pinctrl and pcap which are not described yet.
All of them have binding in separate files but there is missing connection
to firmware node that's why describe it.
Signed-off-by: Michal Simek <[email protected]>
---
.../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index 3d578f98ae2c..0662544f86f0 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -53,6 +53,37 @@ properties:
vector.
type: object
+ zynqmp-power:
+ $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#
+ description: The zynqmp-power node describes the power management
+ configurations. It will control remote suspend/shutdown interfaces.
+ type: object
+
+ reset-controller:
+ $ref: /schemas/reset/xlnx,zynqmp-reset.yaml#
+ description: The reset-controller node describes connection to the reset
+ functionality via firmware interface.
+ type: object
+
+ gpio:
+ $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
+ description: The gpio node describes connect to PS_MODE pins via firmware
+ interface.
+ type: object
+
+ pinctrl:
+ $ref: /schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+ description: The pinctrl node provides access to pinconfig and pincontrol
+ functionality available in firmware.
+ type: object
+
+ pcap:
+ $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml
+ description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to
+ configure the Programmable Logic (PL). The configuration uses the
+ firmware interface.
+ type: object
+
clock-controller:
$ref: /schemas/clock/xlnx,versal-clk.yaml#
description: The clock controller is a hardware block of Xilinx versal
--
2.36.1
On 19/12/2023 15:54, Michal Simek wrote:
> Firmware node has more than fpga, aes and clock child nodes but also power,
> reset, gpio, pinctrl and pcap which are not described yet.
> All of them have binding in separate files but there is missing connection
> to firmware node that's why describe it.
>
> Signed-off-by: Michal Simek <[email protected]>
> ---
>
> .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> index 3d578f98ae2c..0662544f86f0 100644
> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> @@ -53,6 +53,37 @@ properties:
> vector.
> type: object
>
> + zynqmp-power:
Can we rename it to "power-management" or if it is a power-domain
provider to "power-controller"? Assuming nothing requires the old name?
Also, all these nodes/properties look like not ordered by name, so maybe
it is possible to add new nodes in some order?
> + $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#
> + description: The zynqmp-power node describes the power management
> + configurations. It will control remote suspend/shutdown interfaces.
> + type: object
> +
Best regards,
Krzysztof
On 12/20/23 08:53, Krzysztof Kozlowski wrote:
> On 19/12/2023 15:54, Michal Simek wrote:
>> Firmware node has more than fpga, aes and clock child nodes but also power,
>> reset, gpio, pinctrl and pcap which are not described yet.
>> All of them have binding in separate files but there is missing connection
>> to firmware node that's why describe it.
>>
>> Signed-off-by: Michal Simek <[email protected]>
>> ---
>>
>> .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> index 3d578f98ae2c..0662544f86f0 100644
>> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> @@ -53,6 +53,37 @@ properties:
>> vector.
>> type: object
>>
>> + zynqmp-power:
>
> Can we rename it to "power-management" or if it is a power-domain
> provider to "power-controller"? Assuming nothing requires the old name?
I don't think there is any name dependency and node name can be renamed.
>
> Also, all these nodes/properties look like not ordered by name, so maybe
> it is possible to add new nodes in some order?
I am fine with it. Do you want to sort it before adding new one or add new one
and sort of all them?
Thanks,
Michal
On 20/12/2023 08:57, Michal Simek wrote:
>
>
> On 12/20/23 08:53, Krzysztof Kozlowski wrote:
>> On 19/12/2023 15:54, Michal Simek wrote:
>>> Firmware node has more than fpga, aes and clock child nodes but also power,
>>> reset, gpio, pinctrl and pcap which are not described yet.
>>> All of them have binding in separate files but there is missing connection
>>> to firmware node that's why describe it.
>>>
>>> Signed-off-by: Michal Simek <[email protected]>
>>> ---
>>>
>>> .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
>>> 1 file changed, 31 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>> index 3d578f98ae2c..0662544f86f0 100644
>>> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>> @@ -53,6 +53,37 @@ properties:
>>> vector.
>>> type: object
>>>
>>> + zynqmp-power:
>>
>> Can we rename it to "power-management" or if it is a power-domain
>> provider to "power-controller"? Assuming nothing requires the old name?
>
> I don't think there is any name dependency and node name can be renamed.
>
>>
>> Also, all these nodes/properties look like not ordered by name, so maybe
>> it is possible to add new nodes in some order?
>
> I am fine with it. Do you want to sort it before adding new one or add new one
> and sort of all them?
Maybe the new properties can be added not in one chunk but
as-ordered-as-possible?
Best regards,
Krzysztof
On 12/20/23 09:18, Krzysztof Kozlowski wrote:
> On 20/12/2023 08:57, Michal Simek wrote:
>>
>>
>> On 12/20/23 08:53, Krzysztof Kozlowski wrote:
>>> On 19/12/2023 15:54, Michal Simek wrote:
>>>> Firmware node has more than fpga, aes and clock child nodes but also power,
>>>> reset, gpio, pinctrl and pcap which are not described yet.
>>>> All of them have binding in separate files but there is missing connection
>>>> to firmware node that's why describe it.
>>>>
>>>> Signed-off-by: Michal Simek <[email protected]>
>>>> ---
>>>>
>>>> .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 31 +++++++++++++++++++
>>>> 1 file changed, 31 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>>> index 3d578f98ae2c..0662544f86f0 100644
>>>> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>>> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>>>> @@ -53,6 +53,37 @@ properties:
>>>> vector.
>>>> type: object
>>>>
>>>> + zynqmp-power:
>>>
>>> Can we rename it to "power-management" or if it is a power-domain
>>> provider to "power-controller"? Assuming nothing requires the old name?
>>
>> I don't think there is any name dependency and node name can be renamed.
>>
>>>
>>> Also, all these nodes/properties look like not ordered by name, so maybe
>>> it is possible to add new nodes in some order?
>>
>> I am fine with it. Do you want to sort it before adding new one or add new one
>> and sort of all them?
>
> Maybe the new properties can be added not in one chunk but
> as-ordered-as-possible?
It is more about that current nodes are not sorted that's why they should be sorted.
Thanks,
Michal