Date:   Mon, 9 Jan 2023 09:56:35 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     William Zhang <william.zhang@...adcom.com>,
        Linux SPI List <linux-spi@...r.kernel.org>,
        Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>
Cc:     anand.gore@...adcom.com, tomer.yacoby@...adcom.com,
        dan.beygelman@...adcom.com, joel.peshkin@...adcom.com,
        f.fainelli@...il.com, jonas.gorski@...il.com,
        kursad.oney@...adcom.com, dregan@...l.com,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/16] dt-bindings: spi: Add bcmbca-hsspi controller
 support

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@...adcom.com>
>>> ---
>>>
>>>   .../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@...adcom.com>
>>> +  - Kursad Oney <kursad.oney@...adcom.com>
>>>     - Jonas Gorski <jonas.gorski@...il.com>
>>
>>>   
>>> +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

Powered by blists - more mailing lists