On 09/01/2023 09:27, William Zhang wrote: > Hi Krzysztof, > > On 01/08/2023 06:51 AM, Krzysztof Kozlowski wrote: >> On 06/01/2023 21:07, William Zhang wrote: >>> The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI >>> controller. Add a new compatible string and required fields for the new >>> driver. Also add myself and Kursad as the maintainers. >>> >>> Signed-off-by: William Zhang <william.zhang@xxxxxxxxxxxx> >>> --- >>> >>> .../bindings/spi/brcm,bcm63xx-hsspi.yaml | 84 +++++++++++++++++-- >>> 1 file changed, 78 insertions(+), 6 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >>> index 45f1417b1213..56e69d4a1faf 100644 >>> --- a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >>> +++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >>> @@ -4,22 +4,51 @@ >>> $id: http://devicetree.org/schemas/spi/brcm,bcm63xx-hsspi.yaml# >>> $schema: http://devicetree.org/meta-schemas/core.yaml# >>> >>> -title: Broadcom BCM6328 High Speed SPI controller >>> +title: Broadcom Broadband SoC High Speed SPI controller >>> >>> maintainers: >>> + >> >> Drop blank line. > will fix in v2. > >> >>> + - William Zhang <william.zhang@xxxxxxxxxxxx> >>> + - Kursad Oney <kursad.oney@xxxxxxxxxxxx> >>> - Jonas Gorski <jonas.gorski@xxxxxxxxx> >> >>> >>> +description: | >>> + Broadcom Broadband SoC supports High Speed SPI master controller since the >>> + early MIPS based chips such as BCM6328 and BCM63268. This controller was >>> + carried over to recent ARM based chips, such as BCM63138, BCM4908 and BCM6858. >>> + >>> + It has a limitation that can not keep the chip select line active between >>> + the SPI transfers within the same SPI message. This can terminate the >>> + transaction to some SPI devices prematurely. The issue can be worked around by >>> + either the controller's prepend mode or using the dummy chip select >>> + workaround. This controller uses the compatible string brcm,bcm6328-hsspi. >>> + >>> + The newer SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI >>> + controller that add the capability to allow the driver to control chip select >>> + explicitly. This solves the issue in the old controller. This new controller >>> + uses the compatible string brcm,bcmbca-hsspi. >>> + >>> properties: >>> compatible: >>> - const: brcm,bcm6328-hsspi >>> + enum: >>> + - brcm,bcm6328-hsspi >>> + - brcm,bcmbca-hsspi >> >> bca seems quite unspecific. Your description above mentions several >> model numbers and "bca" is not listed as model. Compatibles cannot be >> generic. > "bca" is not model number, rather it is a group (broadband carrier > access) of chip that share the same spi host controller IP. Agree it is > not particularly specific but it differentiate from other broadcom spi > controller ip used by other groups. We just don't have a specific name > for this spi host controller but can we treat bcmbca as the ip name? No, it is discouraged in such forms. Family or IP block compatibles should be prepended with a specific compatible. There were many issues when people insisted on generic or family compatibles... > Otherwise we will have to have a compatible string with chip model for > each SoC even they share the same IP. We already have more than ten of > SoCs and the list will increase. I don't see this is a good solution too. You will have to do it anyway even with generic fallback, so I don't get what is here to gain... I also don't get why Broadcom should be here special, different than others. Why it is not a good solution for Broadcom SoCs but it is for others? > >> >>> >>> reg: >>> - maxItems: 1 >>> + items: >>> + - description: main registers >>> + - description: miscellaneous control registers >>> + minItems: 1 >>> + >>> + reg-names: >>> + items: >>> + - const: hsspi >>> + - const: spim-ctrl >> >> This does not match reg > Do you mean it does not match the description? No. reg can be 1 item but you state reg-names cannot. These are always the same. If one is 1 item, second is as well. >> >>> >>> clocks: >>> items: >>> - - description: spi master reference clock >>> - - description: spi master pll clock >>> + - description: SPI master reference clock >>> + - description: SPI master pll clock >> >> Really? You just added it in previous patch, didn't you? > The previous patch was just word to word conversion of the text file. I > will update that patch to include this change. > >> >>> >>> clock-names: >>> items: >>> @@ -29,12 +58,43 @@ properties: >>> interrupts: >>> maxItems: 1 >>> >>> + brcm,use-cs-workaround: >>> + $ref: /schemas/types.yaml#/definitions/flag >>> + description: | >>> + Enable dummy chip select workaround for SPI transfers that can not be >>> + supported by the default controller's prepend mode, i.e. delay or cs >>> + change needed between SPI transfers. >> >> You need to describe what is the workaround. > Will do. >> >>> + >>> required: >>> - compatible >>> - reg >>> - clocks >>> - clock-names >>> - - interrupts >>> + >>> +allOf: >>> + - $ref: "spi-controller.yaml#" >> >> No quotes. How this is related to this patch? > Will remove quote and put it in patch 1. >> >>> + - if: >>> + properties: >>> + compatible: >>> + contains: >>> + enum: >>> + - brcm,bcm6328-hsspi >>> + then: >>> + properties: >>> + reg: >>> + minItems: 1 >> >> Drop. >> >> reg-names now do not match. > Don't quite understand your comment. What do I need to drop and what is > not matched? You need to add constraints for reg-names, same way as for reg. Disallowing the reg-names also could work, but there won't be benefit in it. Better to have uniform DTS. > Best regards, Krzysztof
