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 > > > >
