[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99b01e96-3b96-6692-c5e1-87db49295e6d@linaro.org>
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