[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250922155054.GA38670-robh@kernel.org>
Date: Mon, 22 Sep 2025 10:50:54 -0500
From: Rob Herring <robh@...nel.org>
To: Richard Zhu <hongxing.zhu@....com>
Cc: frank.li@....com, l.stach@...gutronix.de, lpieralisi@...nel.org,
kwilczynski@...nel.org, mani@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, bhelgaas@...gle.com, shawnguo@...nel.org,
s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, imx@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/3] dt-bindings: pci-imx6: Add external reference
clock mode support
On Mon, Sep 15, 2025 at 11:53:47AM +0800, Richard Zhu wrote:
> On i.MX, PCIe has two reference clock inputs: one from the internal PLL
> and one from an external clock source. Only one needs to be used,
> depending on the board design. Add the external reference clock source
> for reference clock.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@....com>
> Reviewed-by: Frank Li <Frank.Li@....com>
> ---
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index ca5f2970f217..6be45abe6e52 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -219,7 +219,12 @@ allOf:
> - const: pcie_bus
> - const: pcie_phy
> - const: pcie_aux
> - - const: ref
> + - description: PCIe reference clock.
> + oneOf:
> + - description: The controller has two reference clock
> + inputs, internal system PLL and external clock
> + source. Only one needs to be used.
> + enum: [ref, extref]
This seems wrong to me. There's still only 1 ref input to the PCIe
block. If you had 10 possible choices for the ref clock source, would
you add 10 clock names here? No!
Can't you detect what the parent clock is for the 'ref' clock? and
configure the GPR register appropriately. Or that mux should be modeled
as a clock provider.
Rob
Powered by blists - more mailing lists