Re: [PATCH] dt-bindings: PCI: pci-ep: Add ref-clk-mode

[Rob Herring <robh@kernel.org>]

On Wed, Apr 30, 2025 at 01:23:03PM +0530, Manivannan Sadhasivam wrote:
> On Wed, Apr 30, 2025 at 09:16:56AM +0200, Niklas Cassel wrote:
> > Hello Mani,
> > 
> > On Wed, Apr 30, 2025 at 12:35:18PM +0530, Manivannan Sadhasivam wrote:
> > > On Fri, Apr 25, 2025 at 11:20:12AM +0200, Niklas Cassel wrote:
> > > > While some boards designs support multiple reference clocking schemes
> > > > (e.g. Common Clock and SRNS), and can choose the clocking scheme using
> > > > e.g. a DIP switch, most boards designs only support a single clocking
> > > > scheme (even if the SoC might support multiple clocking schemes).
> > > > 
> > > > This property is needed such that the PCI controller driver, in endpoint
> > > > mode, can set the proper bits, e.g. the Common Clock Configuration bit and
> > > > the SRIS Clocking bit, in the PCIe Link Control Register (Offset 10h).
> > > > (Sometimes, there are also specific bits that needs to be set in the PHY.)
> > > > 
> > > 
> > > Thanks for adding the property. I did plan to submit something similar to allow
> > > Qcom PCIe EP controllers to run in SRIS mode.
> > > 
> > > > Some device tree bindings have already implemented vendor specific
> > > > properties to handle this, e.g. "nvidia,enable-ext-refclk" (Common Clock)
> > > > and "nvidia,enable-srns" (SRNS). However, since this property is common
> > > > for all PCI controllers running in endpoint mode, this really ought to be
> > > > a property in the common pcie-ep.yaml device tree binding.
> > > > 
> > > 
> > > We should also mark the nvidia specific properties deprecated and use this one.
> > > But that's for another follow up series.
> > > 
> > > > Add a new ref-clk-mode property that describes the reference clocking
> > > > scheme used by the endpoint. (We do not add a common-clk-ssc option, since
> > > > we cannot know/control if the common clock provided by the host uses SSC.)
> > > > 
> > > > Signed-off-by: Niklas Cassel <cassel@kernel.org>
> > > > ---
> > > >  Documentation/devicetree/bindings/pci/pci-ep.yaml | 9 +++++++++
> > > >  1 file changed, 9 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/pci/pci-ep.yaml b/Documentation/devicetree/bindings/pci/pci-ep.yaml
> > > > index f75000e3093d..206c1dc2ab82 100644
> > > > --- a/Documentation/devicetree/bindings/pci/pci-ep.yaml
> > > > +++ b/Documentation/devicetree/bindings/pci/pci-ep.yaml
> > > > @@ -42,6 +42,15 @@ properties:
> > > >      default: 1
> > > >      maximum: 16
> > > >  
> > > > +  ref-clk-mode:
> > > 
> > > How about 'refclk-mode' instead of 'ref-clk-mode'? 'refclk' is the most widely
> > > used terminology in the bindings.
> > 
> > I does seem that way.
> > Will use your suggestion in V2.
> > 
> > 
> > > 
> > > > +    description: Reference clocking architechture
> > > > +    enum:
> > > > +      - common-clk        # Common Reference Clock (provided by RC side)
> > > 
> > > Can we use 'common-clk-host' so that it is explicit that the clock is coming
> > > from the host side?
> > 
> > Sure.
> > 
> > I take it that you prefer 'common-clk-host' over 'common-clk-rc' ?
> > 
> 
> That's what I intended previously, but thinking more, I feel that we should
> stick to '-rc'i, as that's what the PCIe spec uses.

Couldn't this apply to any link, not just a RC? Is there PCIe 
terminology for upstream and downstream ends of a link?

The 'common-clk' part seems redundant to me with '-rc' or whatever we 
end up with added.

Finally, this[1] seems related. Figure out a common solution.

Rob

[1] https://lore.kernel.org/all/20250406144822.21784-2-marek.vasut+renesas@mailbox.org