Re: [PATCH v3 12/17] dt-bindings: PCI: dwc: Add Baikal-T1 PCIe Root Port bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 01, 2022 at 08:59:33AM -0600, Rob Herring wrote:
> On Sun, Jun 19, 2022 at 11:03:55PM +0300, Serge Semin wrote:
> > On Wed, Jun 15, 2022 at 10:37:12AM -0600, Rob Herring wrote:
> > > On Fri, Jun 10, 2022 at 11:57:00AM +0300, Serge Semin wrote:
> > > > Baikal-T1 SoC is equipped with DWC PCIe v4.60a Root Port controller, which
> > > > link can be trained to work on up to Gen.3 speed over up to x4 lanes. The
> > > > controller is supposed to be fed up with four clock sources: DBI
> > > > peripheral clock, AXI application Tx/Rx clocks and external PHY/core
> > > > reference clock generating the 100MHz signal. In addition to that the
> > > > platform provide a way to reset each part of the controller:
> > > > sticky/non-sticky bits, host controller core, PIPE interface, PCS/PHY and
> > > > Hot/Power reset signal. The Root Port controller is equipped with multiple
> > > > IRQ lines like MSI, system AER, PME, HP, Bandwidth change, Link
> > > > equalization request and eDMA ones. The registers space is accessed over
> > > > the DBI interface. There can be no more than four inbound or outbound iATU
> > > > windows configured.
> > > > 
> > > > Signed-off-by: Serge Semin <Sergey.Semin@xxxxxxxxxxxxxxxxxxxx>
> > > > 
> > > > ---
> > > > 
> > > > Changelog v2:
> > > > - Rename 'syscon' property to 'baikal,bt1-syscon'.
> > > > - Fix the 'compatible' property definition to being more specific about
> > > >   what strings are supposed to be used. Due to that we had to add the
> > > >   select property to evaluate the schema against the Baikal-T1 PCIe DT
> > > >   nodes only.
> > > > ---
> > > >  .../bindings/pci/baikal,bt1-pcie.yaml         | 154 ++++++++++++++++++
> > > >  1 file changed, 154 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml b/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml
> > > > new file mode 100644
> > > > index 000000000000..23bd1d0aa5c5
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml
> > > > @@ -0,0 +1,154 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/pci/baikal,bt1-pcie.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Baikal-T1 PCIe Root Port Controller
> > > > +
> > > > +maintainers:
> > > > +  - Serge Semin <fancer.lancer@xxxxxxxxx>
> > > > +
> > > > +description:
> > > > +  Embedded into Baikal-T1 SoC Root Complex controller. It's based on the
> > > > +  DWC RC PCIe v4.60a IP-core, which is configured to have just a single Root
> > > > +  Port function and is capable of establishing the link up to Gen.3 speed
> > > > +  on x4 lanes. It doesn't have embedded clock and reset control module, so
> > > > +  the proper interface initialization is supposed to be performed by software.
> > > > +
> > > > +select:
> > > > +  properties:
> > > > +    compatible:
> > > > +      contains:
> > > > +        const: baikal,bt1-pcie
> > > > +
> > > > +  required:
> > > > +    - compatible
> > > > +
> > > > +allOf:
> > > > +  - $ref: /schemas/pci/snps,dw-pcie.yaml#
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    items:
> > > > +      - const: baikal,bt1-pcie
> > > > +      - const: snps,dw-pcie-4.60a
> > > 
> > 
> > > Pointless, you can read the version.
> > 
> > The IP-core version CSR was first introduced in v4.70a. So by using
> > the version-based compatible string I advertise the actual IP-core
> > version.
> 

> Ah, right. However, we generally haven't done this elsewhere and you 
> aren't special.

I have a very bright example. It's DW MAC/GMAC/xGMAC device. The
device driver relies on the IP-core version while Synopsys added the
release ID CSRs in the much newer IP-cores.

> 
> > 
> > > 
> > > > +      - const: snps,dw-pcie
> > > 
> > 
> > > Pointless, because what can you do with this by itself?
> > 
> > In general many things. For instance implement some IP-core specific
> > quirks in the generic part of the PCIe subsystem, visually identify
> > the device origin, etc.
> 

> Experience has shown these are not useful. Drop it. Anything in the PCI 
> core would probably use the RP VID/PID.
> 
> Furthermore, there is no guarantee that you won't match and bind to the 
> dw_plat_pcie_driver instead. The kernel has no mechanism to bind to the 
> best match (which is further complicated with modules).

I see your point. Then as I already said in my comment to the DW
PCie DT-bindings patch of this series I'll have to split the
snps,dw-pcie.yaml schema into two:
snps,dw-pcie-common.yaml
and
snps,dw-pcie.yaml

> 
> 
> > > > +  reg:
> > > > +    description:
> > > > +      DBI, DBI2 and at least 4KB outbound iATU-capable region.
> > > > +    maxItems: 3
> > > > +
> > > > +  reg-names:
> > > > +    minItems: 3
> > > > +    maxItems: 3
> > > > +    items:
> > > > +      enum: [ dbi, dbi2, config ]
> > > 
> > 
> > > This should define the order.
> > 
> > Please, tell me why do you persist in the items being ordered? The
> > driver permits the relaxed order of the resources. Thus there is no
> > much need in such constraint. At least I can't find any.
> 

> Tell me why you need random order.

Because I don't see a need in constraining the order. If we get to set
the order requirement, then why do we need to have the "*-names"
property at all?
IMO having "reg" with max/minItems restriction plus generic
description and "reg-names" with possible values enumerated seems very
suitable pattern in this case. Don't you think?

> 
> 
> > > > +  interrupts:
> > > > +    description:
> > > > +      MSI, AER, PME, Hot-plug, Link Bandwidth Management, Link Equalization
> > > > +      request and eight Read/Write eDMA IRQ lines are available.
> > > > +    maxItems: 14
> > > > +
> > > > +  interrupt-names:
> > > > +    minItems: 14
> > > > +    maxItems: 14
> > > > +    items:
> > > > +      oneOf:
> > > > +        - pattern: '^dma[0-7]$'
> > > > +        - enum: [ msi, aer, pme, hp, bw_mg, l_eq ]
> > > 
> > 
> > > Define the order.
> > 
> > Fourteen IRQs? dma0, dma1, dma2, ..., msi, aer, ..., l_eq?
> 

> If that's what the h/w has...

Please, see my comment above. Let's settle the ordering in general
first.

> 
> > 
> > > 
> > > > +
> > > > +  clocks:
> > > > +    description:
> > > > +      DBI (attached to the APB bus), AXI-bus master and slave interfaces
> > > > +      are fed up by the dedicated application clocks. A common reference
> > > > +      clock signal is supposed to be attached to the corresponding Ref-pad
> > > > +      of the SoC. It will be redistributed amongst the controller core
> > > > +      sub-modules (pipe, core, aux, etc).
> > > > +    minItems: 4
> > > > +    maxItems: 4
> > > > +
> > > > +  clock-names:
> > > > +    minItems: 4
> > > > +    maxItems: 4
> > > > +    items:
> > > > +      enum: [ dbi, mstr, slv, ref ]
> > > > +
> > > > +  resets:
> > > > +    description:
> > > > +      A comprehensive controller reset logic is supposed to be implemented
> > > > +      by software, so almost all the possible application and core reset
> > > > +      signals are exposed via the system CCU module.
> > > > +    minItems: 9
> > > > +    maxItems: 9
> > > > +
> > > > +  reset-names:
> > > > +    minItems: 9
> > > > +    maxItems: 9
> > > > +    items:
> > > > +      enum: [ mstr, slv, pwr, hot, phy, core, pipe, sticky, non-sticky ]
> > > > +
> > > > +  baikal,bt1-syscon:
> > > > +    $ref: /schemas/types.yaml#/definitions/phandle
> > > > +    description:
> > > > +      Phandle to the Baikal-T1 System Controller DT node. It's required to
> > > > +      access some additional PM, Reset-related and LTSSM signals.
> > > > +
> > > > +  num-lanes:
> > > > +    maximum: 4
> > > > +
> > > > +  max-link-speed:
> > > > +    maximum: 3
> > > > +
> > > 
> > 
> > > > +  num-ob-windows:
> > > > +    const: 4
> > > > +
> > > > +  num-ib-windows:
> > > > +    const: 4
> > > 
> > > Remove these. They are deprecated and shouldn't be in new bindings.
> > 
> > Aren't they deprecated in the framework of the DT nodes only?
> 

> Yes, and that means don't use in new users.
> 
> > Can't I still use them here to signify the number of iATU windows?
> 
> No.

Ok.

-Sergey

> 
> Rob



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux