Re: [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema

From: Serge Semin
Date: Sun May 22 2022 - 16:49:42 EST


On Tue, May 17, 2022 at 03:13:32PM -0500, Rob Herring wrote:
> On Thu, May 12, 2022 at 02:18:07AM +0300, Serge Semin wrote:
> > Baikal-T1 AHCI controller is based on the DWC AHCI SATA IP-core v4.10a
> > with the next specific settings: two SATA ports, cascaded CSR access based
> > on two clock domains (APB and AXI), selectable source of the reference
> > clock (though stable work is currently available from the external source
> > only), two reset lanes for the application and SATA ports domains. Other
> > than that the device is fully compatible with the generic DWC AHCI SATA
> > bindings.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@xxxxxxxxxxxxxxxxxxxx>
> >
> > ---
> >
> > Changelog v2:
> > - Rename 'syscon' property to 'baikal,bt1-syscon'.
> > - Drop macro usage from the example node.
> > ---
> > .../bindings/ata/baikal,bt1-ahci.yaml | 127 ++++++++++++++++++
> > 1 file changed, 127 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > new file mode 100644
> > index 000000000000..7c2eae75434f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > @@ -0,0 +1,127 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/ata/baikal,bt1-ahci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Baikal-T1 SoC AHCI SATA controller
> > +
> > +maintainers:
> > + - Serge Semin <fancer.lancer@xxxxxxxxx>
> > +
> > +description: |
> > + AHCI SATA controller embedded into the Baikal-T1 SoC is based on the
> > + DWC AHCI SATA v4.10a IP-core.
> > +
> > +allOf:
> > + - $ref: snps,dwc-ahci.yaml#
> > +
> > +properties:
> > + compatible:
> > + contains:
> > + const: baikal,bt1-ahci
> > +
> > + clocks:
> > + items:
> > + - description: Peripheral APB bus clock source
> > + - description: Application AXI BIU clock
> > + - description: Internal SATA Ports reference clock
> > + - description: External SATA Ports reference clock
> > +
> > + clock-names:
> > + items:
> > + - const: pclk
> > + - const: aclk
> > + - const: ref_int
> > + - const: ref_ext
> > +
> > + resets:
> > + items:
> > + - description: Application AXI BIU domain reset
> > + - description: SATA Ports clock domain reset
> > +
> > + reset-names:
> > + items:
> > + - const: arst
> > + - const: ref
> > +
> > + baikal,bt1-syscon:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Phandle reference to the CCU system controller. It is required to
> > + switch between internal and external SATA reference clock sources.
>

> Seems like the CCU system ctrlr should be a clock provider that provides
> 'ref' clock and then assigned-clocks can be used to pick internal vs.
> external ref.

By assigned-clocks do you mean using the "assigned-clock-parents"
property? Does it mean creating additional clocks exported from the
CCU controller, which could have got one of the two parental clocks?

>
> > +
> > + ports-implemented:
> > + maximum: 0x3
> > +
> > +patternProperties:
> > + "^sata-port@[0-9a-e]$":
> > + type: object
>
> unevaluatedProperties: false
>

> and then a $ref to a sata-port schema.

Can I set additional sata-port properties constraints afterwards? Like
I've done for the reg, snps,tx-ts-max and snps,rx-ts-max properties
here?

>
> > +
> > + properties:
> > + reg:
> > + minimum: 0
> > + maximum: 1
> > +
> > + snps,tx-ts-max:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Due to having AXI3 bus interface utilized the maximum Tx DMA
> > + transaction size can't exceed 16 beats (AxLEN[3:0]).
> > + minimum: 1
> > + maximum: 16
> > +
> > + snps,rx-ts-max:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Due to having AXI3 bus interface utilized the maximum Rx DMA
> > + transaction size can't exceed 16 beats (AxLEN[3:0]).
>

> That's not a per port limitation (even though it's a per port register)?
> I think this should be implied by the compatible string.

The snps,{rx,tx}-ts-max property is a per-port property. I'd better
explicitly set the property limitation here rather than having the
value implicitly clamped by hardware especially seeing the limitation
is set by the formulae
(CC_MSTR_BURST_LEN * M_HDATA_WIDTH/32)) / (M_HDATA_WIDTH/32),
which consists of the IP-core synthesized parameters.

>
> Really, firmware should configure this IMO.

We don't have comprehensive firmware setting these and generic HBA parameters.
In our case dtb is the main platform firmware.

-Sergey

>
> > + minimum: 1
> > + maximum: 16
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - resets
> > + - baikal,bt1-syscon
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + sata@1f050000 {
> > + compatible = "baikal,bt1-ahci", "snps,dwc-ahci";
> > + reg = <0x1f050000 0x2000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + interrupts = <0 64 4>;
> > +
> > + clocks = <&ccu_sys 1>, <&ccu_axi 2>, <&ccu_sys 0>, <&clk_sata>;
> > + clock-names = "pclk", "aclk", "ref_int", "ref_ext";
> > +
> > + resets = <&ccu_axi 2>, <&ccu_sys 0>;
> > + reset-names = "arst", "ref";
> > +
> > + baikal,bt1-syscon = <&syscon>;
> > +
> > + ports-implemented = <0x3>;
> > +
> > + sata-port@0 {
> > + reg = <0>;
> > +
> > + snps,tx-ts-max = <4>;
> > + snps,rx-ts-max = <4>;
> > + };
> > +
> > + sata-port@1 {
> > + reg = <1>;
> > +
> > + snps,tx-ts-max = <4>;
> > + snps,rx-ts-max = <4>;
> > + };
> > + };
> > +...
> > --
> > 2.35.1
> >
> >