2023-07-12 20:49:31

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH 1/2] dt-bindings: net: fsl,fec: Add TX clock controls

On 11/07/2023 17:08, Vesa Jääskeläinen wrote:
> With fsl,fec-tx-clock-output one can control if TX clock is routed outside
> of the chip.
>
> With fsl,fec-tx-clk-as-ref-clock one can select if external TX clock is as
> reference clock.
>
> Signed-off-by: Vesa Jääskeläinen <[email protected]>
> ---
> .../devicetree/bindings/net/fsl,fec.yaml | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml
> index b494e009326e..c09105878bc6 100644
> --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml
> +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml
> @@ -166,6 +166,21 @@ properties:
> description:
> If present, indicates that the hardware supports waking up via magic packet.
>
> + fsl,fec-tx-clock-output:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + If present, ENETx_TX_CLK output driver is enabled.
> + If not present, ENETx_TX_CLK output driver is disabled.

Here...

> +
> + fsl,fec-tx-clk-as-ref-clock:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + If present, gets ENETx TX reference clk from the ENETx_TX_CLK pin. In
> + this use case, an external OSC provides the clock for both the external
> + PHY and the internal controller.
> + If not present, ENETx TX reference clock is driven by ref_enetpllx. This
> + clock is also output to pins via the IOMUX.ENET_REF_CLKx function.

and here:
In general, Common Clock Framework and its bindings should be used for
handling clock providers and consumers. Why it cannot be used for these
two cases?


Best regards,
Krzysztof



2023-07-13 09:29:23

by Vesa Jääskeläinen

[permalink] [raw]
Subject: Re: [PATCH 1/2] dt-bindings: net: fsl,fec: Add TX clock controls

Hi Krzysztof,

On 12.7.2023 23.36, Krzysztof Kozlowski wrote:
> On 11/07/2023 17:08, Vesa Jääskeläinen wrote:
>> With fsl,fec-tx-clock-output one can control if TX clock is routed outside
>> of the chip.
>>
>> With fsl,fec-tx-clk-as-ref-clock one can select if external TX clock is as
>> reference clock.
>>
>> Signed-off-by: Vesa Jääskeläinen <[email protected]>
>> ---
>> .../devicetree/bindings/net/fsl,fec.yaml | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml
>> index b494e009326e..c09105878bc6 100644
>> --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml
>> +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml
>> @@ -166,6 +166,21 @@ properties:
>> description:
>> If present, indicates that the hardware supports waking up via magic packet.
>>
>> + fsl,fec-tx-clock-output:
>> + $ref: /schemas/types.yaml#/definitions/flag
>> + description:
>> + If present, ENETx_TX_CLK output driver is enabled.
>> + If not present, ENETx_TX_CLK output driver is disabled.
> Here...
>
>> +
>> + fsl,fec-tx-clk-as-ref-clock:
>> + $ref: /schemas/types.yaml#/definitions/flag
>> + description:
>> + If present, gets ENETx TX reference clk from the ENETx_TX_CLK pin. In
>> + this use case, an external OSC provides the clock for both the external
>> + PHY and the internal controller.
>> + If not present, ENETx TX reference clock is driven by ref_enetpllx. This
>> + clock is also output to pins via the IOMUX.ENET_REF_CLKx function.
> and here:
> In general, Common Clock Framework and its bindings should be used for
> handling clock providers and consumers. Why it cannot be used for these
> two cases?

Did you have something specific in mind on how it could be modeled?

I tried to look at:
Documentation/devicetree/bindings/clock/

But didn't spot anything for this.

In net bindings:
Documentation/devicetree/bindings/net

We have some similarities:

- adi,phy-output-clock
- adi,phy-output-reference-clock
- nxp,rmii-refclk-in
- clock_in_out
- ti,clk-output-sel
- ti,sgmii-ref-clock-output-enable

In here clock output generator would be the i.MX not the PHY as what was
in ADI's.

xMII variants are close but very specific for specific MII interface type.

clock_in_out seems a bit out of place.

Thanks,
Vesa Jääskeläinen