[PATCH v5 1/5] dt-bindings: pci: qcom: Document PCIe bindings for SM8450

[Dmitry Baryshkov]

On Tue, 21 Dec 2021 at 22:52, Rob Herring <robh at kernel.org> wrote:
>
> On Tue, Dec 21, 2021 at 06:43:31PM +0300, Dmitry Baryshkov wrote:
> > On Tue, 21 Dec 2021 at 17:59, Rob Herring <robh at kernel.org> wrote:
> > >
> > > On Sat, Dec 18, 2021 at 05:10:20PM +0300, Dmitry Baryshkov wrote:
> > > > Document the PCIe DT bindings for SM8450 SoC. The PCIe IP is similar
> > > > to the one used on SM8250, however unlike SM8250, PCIe0 and PCIe1 use
> > > > different set of clocks, so two compatible entries are required.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> > > > ---
> > > >  .../devicetree/bindings/pci/qcom,pcie.txt     | 22 ++++++++++++++++++-
> > > >  1 file changed, 21 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> > > > index a0ae024c2d0c..0adb56d5645e 100644
> > > > --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> > > > +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> > > > @@ -15,6 +15,8 @@
> > > >                       - "qcom,pcie-sc8180x" for sc8180x
> > > >                       - "qcom,pcie-sdm845" for sdm845
> > > >                       - "qcom,pcie-sm8250" for sm8250
> > > > +                     - "qcom,pcie-sm8450-pcie0" for PCIe0 on sm8450
> > > > +                     - "qcom,pcie-sm8450-pcie1" for PCIe1 on sm8450
> > >
> > > What's the difference between the two?
> >
> > Clocks used by these hosts. Quoting the definition:
> >
> > +                     - "aggre0"      Aggre NoC PCIe0 AXI clock, only
> > for sm8450-pcie0
> > +                     - "aggre1"      Aggre NoC PCIe1 AXI clock
> >
> > aggre1 is used by both pcie0 and pcie1, while aggre0 is used only by pcie0.
>
> That doesn't really seem like you need a different compatible for that.
> Do you need to handle them differently? It seems like abuse of clocks
> putting bus/interconnect clocks here, but sadly that's all too common.

Unfortunately, yes, it looks like we need to handle them differently.
The clocks are not handled by the interconnect on their own.

-- 
With best wishes
Dmitry