| Message ID | 20230124221218.341511-3-william.zhang@broadcom.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | spi: bcm63xx-hsspi: driver and doc updates | expand |
On 24/01/2023 23:12, William Zhang wrote: > The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI > controller. Add new compatible strings to differentiate the old and new > controller while keeping MIPS based chip with the old compatible. Update > property requirements for these two revisions of the controller. Also > add myself and Kursad as the maintainers. > > Signed-off-by: William Zhang <william.zhang@broadcom.com> > > --- > > Changes in v2: > - Update new compatible string to follow Broadcom convention <chip > specific compatible>, <version of the IP>, <fallback> > - Add reg-names min/maxItem constraints to be consistent with reg > property > - Make interrupts required property > - Remove double quote from spi-controller.yaml reference > - Remove brcm,use-cs-workaround flag > - Update the example with new compatile and interrupts property > - Update commit message > > .../bindings/spi/brcm,bcm63xx-hsspi.yaml | 106 +++++++++++++++++- > 1 file changed, 101 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml > index d1a0c9adee7a..d39604654c9e 100644 > --- a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml > +++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml > @@ -4,20 +4,73 @@ > $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: > + This is a friendly reminder during the review process. It seems my previous comments were not fully addressed. Maybe my feedback got lost between the quotes, maybe you just forgot to apply it. Please go back to the previous discussion and either implement all requested changes or keep discussing them. Thank you. > + - William Zhang <william.zhang@broadcom.com> > + - Kursad Oney <kursad.oney@broadcom.com> > - Jonas Gorski <jonas.gorski@gmail.com> > > -allOf: > - - $ref: spi-controller.yaml# In your previous patch, put it already in desired place (after "required:"), so you will not have to shuffle it. > +description: | > + Broadcom Broadband SoC supports High Speed SPI master controller since the > + early MIPS based chips such as BCM6328 and BCM63268. This initial rev 1.0 > + controller was carried over to recent ARM based chips, such as BCM63138, > + BCM4908 and BCM6858. The old MIPS based chip should continue to use the > + brcm,bcm6328-hsspi compatible string. The recent ARM based chip is required to > + use the brcm,bcmbca-hsspi-v1.0 as part of its compatible string list as > + defined below to match the specific chip along with ip revision info. > + > + This rev 1.0 controller 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. Driver automatically picks the suitable mode based on > + transfer type so it is transparent to the user. > + > + The newer SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI > + controller rev 1.1 that add the capability to allow the driver to control chip > + select explicitly. This solves the issue in the old controller. > > properties: > compatible: > - const: brcm,bcm6328-hsspi > + oneOf: > + - const: brcm,bcm6328-hsspi > + - items: > + - enum: > + - brcm,bcm47622-hsspi > + - brcm,bcm4908-hsspi > + - brcm,bcm63138-hsspi > + - brcm,bcm63146-hsspi > + - brcm,bcm63148-hsspi > + - brcm,bcm63158-hsspi > + - brcm,bcm63178-hsspi > + - brcm,bcm6846-hsspi > + - brcm,bcm6856-hsspi > + - brcm,bcm6858-hsspi > + - brcm,bcm6878-hsspi > + - const: brcm,bcmbca-hsspi-v1.0 > + - const: brcm,bcmbca-hsspi Why do you need "brcm,bcmbca-hsspi"? Nothing binds to it, so it's useless and very generic. > + - items: > + - enum: > + - brcm,bcm4912-hsspi > + - brcm,bcm6756-hsspi > + - brcm,bcm6813-hsspi > + - brcm,bcm6855-hsspi > + - const: brcm,bcmbca-hsspi-v1.1 > + - const: brcm,bcmbca-hsspi Same here. > > reg: > - maxItems: 1 > + items: > + - description: main registers > + - description: miscellaneous control registers > + minItems: 1 > + > + reg-names: > + items: > + - const: hsspi > + - const: spim-ctrl > + minItems: 1 > > clocks: > items: > @@ -39,10 +92,39 @@ required: > - clock-names > - interrupts > > +allOf: > + - $ref: spi-controller.yaml# > + - if: > + properties: > + compatible: > + contains: > + enum: > + - brcm,bcm6328-hsspi > + - brcm,bcmbca-hsspi-v1.0 > + then: > + properties: > + reg: > + minItems: 1 drop minItems > + maxItems: 1 > + reg-names: > + minItems: 1 drop minItems > + maxItems: 1 > + else: > + properties: > + reg: > + minItems: 2 > + maxItems: 2 > + reg-names: > + minItems: 2 > + maxItems: 2 > + required: > + - reg-names > + > unevaluatedProperties: false > > examples: > - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > spi@10001000 { > compatible = "brcm,bcm6328-hsspi"; > reg = <0x10001000 0x600>; > @@ -53,3 +135,17 @@ examples: > #address-cells = <1>; > #size-cells = <0>; > }; > + - | > + spi@ff801000 { > + compatible = "brcm,bcm6756-hsspi", "brcm,bcmbca-hsspi-v1.1", > + "brcm,bcmbca-hsspi"; > + reg = <0xff801000 0x1000>, > + <0xff802610 0x4>; > + reg-names = "hsspi", "spim-ctrl"; > + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&hsspi>, <&hsspi_pll>; > + clock-names = "hsspi", "pll"; > + num-cs = <8>; > + #address-cells = <1>; > + #size-cells = <0>; > + }; Drop new example - the difference is only in reg. Or change old example to have only one (newer, more complex). Best regards, Krzysztof
On 01/24/2023 11:35 PM, Krzysztof Kozlowski wrote: > On 24/01/2023 23:12, William Zhang wrote: >> The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI >> controller. Add new compatible strings to differentiate the old and new >> controller while keeping MIPS based chip with the old compatible. Update >> property requirements for these two revisions of the controller. Also >> add myself and Kursad as the maintainers. >> >> Signed-off-by: William Zhang <william.zhang@broadcom.com> >> >> --- >> >> Changes in v2: >> - Update new compatible string to follow Broadcom convention <chip >> specific compatible>, <version of the IP>, <fallback> >> - Add reg-names min/maxItem constraints to be consistent with reg >> property >> - Make interrupts required property >> - Remove double quote from spi-controller.yaml reference >> - Remove brcm,use-cs-workaround flag >> - Update the example with new compatile and interrupts property >> - Update commit message >> >> .../bindings/spi/brcm,bcm63xx-hsspi.yaml | 106 +++++++++++++++++- >> 1 file changed, 101 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >> index d1a0c9adee7a..d39604654c9e 100644 >> --- a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >> +++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >> @@ -4,20 +4,73 @@ >> $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: >> + > > This is a friendly reminder during the review process. > > It seems my previous comments were not fully addressed. Maybe my > feedback got lost between the quotes, maybe you just forgot to apply it. > Please go back to the previous discussion and either implement all > requested changes or keep discussing them. > > Thank you. > Yeah I forgot to remove the blank line after maintainers tag. Also regarding the explanation of dummy cs workaround flag, we decided to remove it as it is not necessary after discussion internally and with SPI maintainer Mark. Let me know if I missed anything else. >> + - William Zhang <william.zhang@broadcom.com> >> + - Kursad Oney <kursad.oney@broadcom.com> >> - Jonas Gorski <jonas.gorski@gmail.com> >> >> -allOf: >> - - $ref: spi-controller.yaml# > > In your previous patch, put it already in desired place (after > "required:"), so you will not have to shuffle it. > Will update the previous patch in v3 >> +description: | >> + Broadcom Broadband SoC supports High Speed SPI master controller since the >> + early MIPS based chips such as BCM6328 and BCM63268. This initial rev 1.0 >> + controller was carried over to recent ARM based chips, such as BCM63138, >> + BCM4908 and BCM6858. The old MIPS based chip should continue to use the >> + brcm,bcm6328-hsspi compatible string. The recent ARM based chip is required to >> + use the brcm,bcmbca-hsspi-v1.0 as part of its compatible string list as >> + defined below to match the specific chip along with ip revision info. >> + >> + This rev 1.0 controller 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. Driver automatically picks the suitable mode based on >> + transfer type so it is transparent to the user. >> + >> + The newer SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI >> + controller rev 1.1 that add the capability to allow the driver to control chip >> + select explicitly. This solves the issue in the old controller. >> >> properties: >> compatible: >> - const: brcm,bcm6328-hsspi >> + oneOf: >> + - const: brcm,bcm6328-hsspi >> + - items: >> + - enum: >> + - brcm,bcm47622-hsspi >> + - brcm,bcm4908-hsspi >> + - brcm,bcm63138-hsspi >> + - brcm,bcm63146-hsspi >> + - brcm,bcm63148-hsspi >> + - brcm,bcm63158-hsspi >> + - brcm,bcm63178-hsspi >> + - brcm,bcm6846-hsspi >> + - brcm,bcm6856-hsspi >> + - brcm,bcm6858-hsspi >> + - brcm,bcm6878-hsspi >> + - const: brcm,bcmbca-hsspi-v1.0 >> + - const: brcm,bcmbca-hsspi > > Why do you need "brcm,bcmbca-hsspi"? Nothing binds to it, so it's > useless and very generic. > This was from Florian's suggestion and Broadcom's convention. See [1] and you are okay with that [2]. I added the rev compatible and you were not objecting it finally if I understand you correctly. >> + - items: >> + - enum: >> + - brcm,bcm4912-hsspi >> + - brcm,bcm6756-hsspi >> + - brcm,bcm6813-hsspi >> + - brcm,bcm6855-hsspi >> + - const: brcm,bcmbca-hsspi-v1.1 >> + - const: brcm,bcmbca-hsspi > > Same here. > >> >> reg: >> - maxItems: 1 >> + items: >> + - description: main registers >> + - description: miscellaneous control registers >> + minItems: 1 >> + >> + reg-names: >> + items: >> + - const: hsspi >> + - const: spim-ctrl >> + minItems: 1 >> >> clocks: >> items: >> @@ -39,10 +92,39 @@ required: >> - clock-names >> - interrupts >> >> +allOf: >> + - $ref: spi-controller.yaml# >> + - if: >> + properties: >> + compatible: >> + contains: >> + enum: >> + - brcm,bcm6328-hsspi >> + - brcm,bcmbca-hsspi-v1.0 >> + then: >> + properties: >> + reg: >> + minItems: 1 > > drop minItems > Will fix in v3 and the next one as well >> + maxItems: 1 >> + reg-names: >> + minItems: 1 > > drop minItems > >> + maxItems: 1 >> + else: >> + properties: >> + reg: >> + minItems: 2 >> + maxItems: 2 >> + reg-names: >> + minItems: 2 >> + maxItems: 2 >> + required: >> + - reg-names >> + >> unevaluatedProperties: false >> >> examples: >> - | >> + #include <dt-bindings/interrupt-controller/arm-gic.h> >> spi@10001000 { >> compatible = "brcm,bcm6328-hsspi"; >> reg = <0x10001000 0x600>; >> @@ -53,3 +135,17 @@ examples: >> #address-cells = <1>; >> #size-cells = <0>; >> }; >> + - | >> + spi@ff801000 { >> + compatible = "brcm,bcm6756-hsspi", "brcm,bcmbca-hsspi-v1.1", >> + "brcm,bcmbca-hsspi"; >> + reg = <0xff801000 0x1000>, >> + <0xff802610 0x4>; >> + reg-names = "hsspi", "spim-ctrl"; >> + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; >> + clocks = <&hsspi>, <&hsspi_pll>; >> + clock-names = "hsspi", "pll"; >> + num-cs = <8>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + }; > > Drop new example - the difference is only in reg. Or change old example > to have only one (newer, more complex). > Will replace the old example with this more recent and complex example in v3 > Best regards, > Krzysztof > [1] https://www.spinics.net/lists/devicetree/msg565016.html [2] https://www.spinics.net/lists/devicetree/msg565197.html
On Wed, Jan 25, 2023 at 11:23:52AM -0800, William Zhang wrote: > > > On 01/24/2023 11:35 PM, Krzysztof Kozlowski wrote: > > On 24/01/2023 23:12, William Zhang wrote: > > > The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI > > > controller. Add new compatible strings to differentiate the old and new > > > controller while keeping MIPS based chip with the old compatible. Update > > > property requirements for these two revisions of the controller. Also > > > add myself and Kursad as the maintainers. > > > > > > Signed-off-by: William Zhang <william.zhang@broadcom.com> > > > > > > --- > > > > > > Changes in v2: > > > - Update new compatible string to follow Broadcom convention <chip > > > specific compatible>, <version of the IP>, <fallback> > > > - Add reg-names min/maxItem constraints to be consistent with reg > > > property > > > - Make interrupts required property > > > - Remove double quote from spi-controller.yaml reference > > > - Remove brcm,use-cs-workaround flag > > > - Update the example with new compatile and interrupts property > > > - Update commit message > > > > > > .../bindings/spi/brcm,bcm63xx-hsspi.yaml | 106 +++++++++++++++++- > > > 1 file changed, 101 insertions(+), 5 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml > > > index d1a0c9adee7a..d39604654c9e 100644 > > > --- a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml > > > +++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml > > > @@ -4,20 +4,73 @@ > > > $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: > > > + > > > > This is a friendly reminder during the review process. > > > > It seems my previous comments were not fully addressed. Maybe my > > feedback got lost between the quotes, maybe you just forgot to apply it. > > Please go back to the previous discussion and either implement all > > requested changes or keep discussing them. > > > > Thank you. > > > Yeah I forgot to remove the blank line after maintainers tag. Also > regarding the explanation of dummy cs workaround flag, we decided to remove > it as it is not necessary after discussion internally and with SPI > maintainer Mark. Let me know if I missed anything else. > > > > + - William Zhang <william.zhang@broadcom.com> > > > + - Kursad Oney <kursad.oney@broadcom.com> > > > - Jonas Gorski <jonas.gorski@gmail.com> > > > -allOf: > > > - - $ref: spi-controller.yaml# > > > > In your previous patch, put it already in desired place (after > > "required:"), so you will not have to shuffle it. > > > Will update the previous patch in v3 > > > > +description: | > > > + Broadcom Broadband SoC supports High Speed SPI master controller since the > > > + early MIPS based chips such as BCM6328 and BCM63268. This initial rev 1.0 > > > + controller was carried over to recent ARM based chips, such as BCM63138, > > > + BCM4908 and BCM6858. The old MIPS based chip should continue to use the > > > + brcm,bcm6328-hsspi compatible string. The recent ARM based chip is required to > > > + use the brcm,bcmbca-hsspi-v1.0 as part of its compatible string list as > > > + defined below to match the specific chip along with ip revision info. > > > + > > > + This rev 1.0 controller 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. Driver automatically picks the suitable mode based on > > > + transfer type so it is transparent to the user. > > > + > > > + The newer SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI > > > + controller rev 1.1 that add the capability to allow the driver to control chip > > > + select explicitly. This solves the issue in the old controller. > > > properties: > > > compatible: > > > - const: brcm,bcm6328-hsspi > > > + oneOf: > > > + - const: brcm,bcm6328-hsspi > > > + - items: > > > + - enum: > > > + - brcm,bcm47622-hsspi > > > + - brcm,bcm4908-hsspi > > > + - brcm,bcm63138-hsspi > > > + - brcm,bcm63146-hsspi > > > + - brcm,bcm63148-hsspi > > > + - brcm,bcm63158-hsspi > > > + - brcm,bcm63178-hsspi > > > + - brcm,bcm6846-hsspi > > > + - brcm,bcm6856-hsspi > > > + - brcm,bcm6858-hsspi > > > + - brcm,bcm6878-hsspi > > > + - const: brcm,bcmbca-hsspi-v1.0 > > > + - const: brcm,bcmbca-hsspi > > > > Why do you need "brcm,bcmbca-hsspi"? Nothing binds to it, so it's > > useless and very generic. > > > This was from Florian's suggestion and Broadcom's convention. See [1] and > you are okay with that [2]. I added the rev compatible and you were not > objecting it finally if I understand you correctly. Can you have a driver that only understands what 'brcm,bcmbca-hsspi' is work on all h/w that includes the compatible string? It doesn't seem like it since v1.1 is a completely new driver. Therefore 'brcm,bcmbca-hsspi' is pretty much useless. Really, your 'generic' fallback for v1.0 should be 'brcm,bcm6328-hsspi' because that is the one the OS already supports. I don't know why folks get so hung up on saying new SoC block is compatible with old SoC's block. The rule on using version numbers is they must correspond to something. FPGA soft IP with released versions is a good example. I always suspect a v1 or v1.0 is made up by the binding author. Rob
On 01/25/2023 12:51 PM, Rob Herring wrote: > On Wed, Jan 25, 2023 at 11:23:52AM -0800, William Zhang wrote: >> >> >> On 01/24/2023 11:35 PM, Krzysztof Kozlowski wrote: >>> On 24/01/2023 23:12, William Zhang wrote: >>>> The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI >>>> controller. Add new compatible strings to differentiate the old and new >>>> controller while keeping MIPS based chip with the old compatible. Update >>>> property requirements for these two revisions of the controller. Also >>>> add myself and Kursad as the maintainers. >>>> >>>> Signed-off-by: William Zhang <william.zhang@broadcom.com> >>>> >>>> --- >>>> >>>> Changes in v2: >>>> - Update new compatible string to follow Broadcom convention <chip >>>> specific compatible>, <version of the IP>, <fallback> >>>> - Add reg-names min/maxItem constraints to be consistent with reg >>>> property >>>> - Make interrupts required property >>>> - Remove double quote from spi-controller.yaml reference >>>> - Remove brcm,use-cs-workaround flag >>>> - Update the example with new compatile and interrupts property >>>> - Update commit message >>>> >>>> .../bindings/spi/brcm,bcm63xx-hsspi.yaml | 106 +++++++++++++++++- >>>> 1 file changed, 101 insertions(+), 5 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >>>> index d1a0c9adee7a..d39604654c9e 100644 >>>> --- a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >>>> +++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml >>>> @@ -4,20 +4,73 @@ >>>> $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: >>>> + >>> >>> This is a friendly reminder during the review process. >>> >>> It seems my previous comments were not fully addressed. Maybe my >>> feedback got lost between the quotes, maybe you just forgot to apply it. >>> Please go back to the previous discussion and either implement all >>> requested changes or keep discussing them. >>> >>> Thank you. >>> >> Yeah I forgot to remove the blank line after maintainers tag. Also >> regarding the explanation of dummy cs workaround flag, we decided to remove >> it as it is not necessary after discussion internally and with SPI >> maintainer Mark. Let me know if I missed anything else. >> >>>> + - William Zhang <william.zhang@broadcom.com> >>>> + - Kursad Oney <kursad.oney@broadcom.com> >>>> - Jonas Gorski <jonas.gorski@gmail.com> >>>> -allOf: >>>> - - $ref: spi-controller.yaml# >>> >>> In your previous patch, put it already in desired place (after >>> "required:"), so you will not have to shuffle it. >>> >> Will update the previous patch in v3 >> >>>> +description: | >>>> + Broadcom Broadband SoC supports High Speed SPI master controller since the >>>> + early MIPS based chips such as BCM6328 and BCM63268. This initial rev 1.0 >>>> + controller was carried over to recent ARM based chips, such as BCM63138, >>>> + BCM4908 and BCM6858. The old MIPS based chip should continue to use the >>>> + brcm,bcm6328-hsspi compatible string. The recent ARM based chip is required to >>>> + use the brcm,bcmbca-hsspi-v1.0 as part of its compatible string list as >>>> + defined below to match the specific chip along with ip revision info. >>>> + >>>> + This rev 1.0 controller 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. Driver automatically picks the suitable mode based on >>>> + transfer type so it is transparent to the user. >>>> + >>>> + The newer SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI >>>> + controller rev 1.1 that add the capability to allow the driver to control chip >>>> + select explicitly. This solves the issue in the old controller. >>>> properties: >>>> compatible: >>>> - const: brcm,bcm6328-hsspi >>>> + oneOf: >>>> + - const: brcm,bcm6328-hsspi >>>> + - items: >>>> + - enum: >>>> + - brcm,bcm47622-hsspi >>>> + - brcm,bcm4908-hsspi >>>> + - brcm,bcm63138-hsspi >>>> + - brcm,bcm63146-hsspi >>>> + - brcm,bcm63148-hsspi >>>> + - brcm,bcm63158-hsspi >>>> + - brcm,bcm63178-hsspi >>>> + - brcm,bcm6846-hsspi >>>> + - brcm,bcm6856-hsspi >>>> + - brcm,bcm6858-hsspi >>>> + - brcm,bcm6878-hsspi >>>> + - const: brcm,bcmbca-hsspi-v1.0 >>>> + - const: brcm,bcmbca-hsspi >>> >>> Why do you need "brcm,bcmbca-hsspi"? Nothing binds to it, so it's >>> useless and very generic. >>> >> This was from Florian's suggestion and Broadcom's convention. See [1] and >> you are okay with that [2]. I added the rev compatible and you were not >> objecting it finally if I understand you correctly. > > Can you have a driver that only understands what 'brcm,bcmbca-hsspi' is > work on all h/w that includes the compatible string? It doesn't seem > like it since v1.1 is a completely new driver. Therefore > 'brcm,bcmbca-hsspi' is pretty much useless. > 'brcm,bcmbca-hsspi' should be added to the binding table of spi-bcm63xx-hsspi.c driver. This is the initial driver that works for v1.0 controller. For v1.1 controller, yes it can fallback and work with 1.0 driver spi-bcm63xx-hsspi.c simply not using the new feature in v1.1(chip select signal control through software) and keeping using the prepend mode or dummy cs workaround supported in 1.0 driver. > Really, your 'generic' fallback for v1.0 should be 'brcm,bcm6328-hsspi' > because that is the one the OS already supports. I don't know why folks > get so hung up on saying new SoC block is compatible with old SoC's > block. > > The rule on using version numbers is they must correspond to something. > FPGA soft IP with released versions is a good example. I always suspect > a v1 or v1.0 is made up by the binding author. > I had discussion with our ASIC IP team and confirmed we only have two versions of HSSPI controller among all the BCA chips. Although it does not have version register in the IP block for now, version 1.0 and 1.1 is what we agreed on and ASIC team was already planning to add rev register for the new rev of this IP. So I agree it is not perfect like brcm nand controller and other block that always have rev register but I think it is good use for software to identify them in dts based on the fact there are only two revisions. > Rob >
On Wed, Jan 25, 2023 at 3:41 PM William Zhang <william.zhang@broadcom.com> wrote: > On 01/25/2023 12:51 PM, Rob Herring wrote: > > On Wed, Jan 25, 2023 at 11:23:52AM -0800, William Zhang wrote: > >> On 01/24/2023 11:35 PM, Krzysztof Kozlowski wrote: > >>> On 24/01/2023 23:12, William Zhang wrote: > >>>> The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI > >>>> controller. Add new compatible strings to differentiate the old and new > >>>> controller while keeping MIPS based chip with the old compatible. Update > >>>> property requirements for these two revisions of the controller. Also > >>>> add myself and Kursad as the maintainers. [...] > >>>> properties: > >>>> compatible: > >>>> - const: brcm,bcm6328-hsspi > >>>> + oneOf: > >>>> + - const: brcm,bcm6328-hsspi > >>>> + - items: > >>>> + - enum: > >>>> + - brcm,bcm47622-hsspi > >>>> + - brcm,bcm4908-hsspi > >>>> + - brcm,bcm63138-hsspi > >>>> + - brcm,bcm63146-hsspi > >>>> + - brcm,bcm63148-hsspi > >>>> + - brcm,bcm63158-hsspi > >>>> + - brcm,bcm63178-hsspi > >>>> + - brcm,bcm6846-hsspi > >>>> + - brcm,bcm6856-hsspi > >>>> + - brcm,bcm6858-hsspi > >>>> + - brcm,bcm6878-hsspi > >>>> + - const: brcm,bcmbca-hsspi-v1.0 > >>>> + - const: brcm,bcmbca-hsspi > >>> > >>> Why do you need "brcm,bcmbca-hsspi"? Nothing binds to it, so it's > >>> useless and very generic. > >>> > >> This was from Florian's suggestion and Broadcom's convention. See [1] and > >> you are okay with that [2]. I added the rev compatible and you were not > >> objecting it finally if I understand you correctly. > > > > Can you have a driver that only understands what 'brcm,bcmbca-hsspi' is > > work on all h/w that includes the compatible string? It doesn't seem > > like it since v1.1 is a completely new driver. Therefore > > 'brcm,bcmbca-hsspi' is pretty much useless. > > > 'brcm,bcmbca-hsspi' should be added to the binding table of > spi-bcm63xx-hsspi.c driver. This is the initial driver that works for > v1.0 controller. For v1.1 controller, yes it can fallback and work with > 1.0 driver spi-bcm63xx-hsspi.c simply not using the new feature in > v1.1(chip select signal control through software) and keeping using the > prepend mode or dummy cs workaround supported in 1.0 driver. If v1.1 is compatible with v1.0, then say that: soc-compat, "brcm,bcmbca-hsspi-v1.1", "brcm,bcmbca-hsspi-v1.0" IOW, 'brcm,bcmbca-hsspi' is redundant with 'brcm,bcmbca-hsspi-v1.0'. They have the same meaning. So pick which one you want to use. Not both. Also, if that is the case, you shouldn't be introducing a whole new driver for v1.1. Rob
On 01/26/2023 05:56 AM, Rob Herring wrote: > On Wed, Jan 25, 2023 at 3:41 PM William Zhang > <william.zhang@broadcom.com> wrote: >> On 01/25/2023 12:51 PM, Rob Herring wrote: >>> On Wed, Jan 25, 2023 at 11:23:52AM -0800, William Zhang wrote: >>>> On 01/24/2023 11:35 PM, Krzysztof Kozlowski wrote: >>>>> On 24/01/2023 23:12, William Zhang wrote: >>>>>> The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI >>>>>> controller. Add new compatible strings to differentiate the old and new >>>>>> controller while keeping MIPS based chip with the old compatible. Update >>>>>> property requirements for these two revisions of the controller. Also >>>>>> add myself and Kursad as the maintainers. > > [...] > >>>>>> properties: >>>>>> compatible: >>>>>> - const: brcm,bcm6328-hsspi >>>>>> + oneOf: >>>>>> + - const: brcm,bcm6328-hsspi >>>>>> + - items: >>>>>> + - enum: >>>>>> + - brcm,bcm47622-hsspi >>>>>> + - brcm,bcm4908-hsspi >>>>>> + - brcm,bcm63138-hsspi >>>>>> + - brcm,bcm63146-hsspi >>>>>> + - brcm,bcm63148-hsspi >>>>>> + - brcm,bcm63158-hsspi >>>>>> + - brcm,bcm63178-hsspi >>>>>> + - brcm,bcm6846-hsspi >>>>>> + - brcm,bcm6856-hsspi >>>>>> + - brcm,bcm6858-hsspi >>>>>> + - brcm,bcm6878-hsspi >>>>>> + - const: brcm,bcmbca-hsspi-v1.0 >>>>>> + - const: brcm,bcmbca-hsspi >>>>> >>>>> Why do you need "brcm,bcmbca-hsspi"? Nothing binds to it, so it's >>>>> useless and very generic. >>>>> >>>> This was from Florian's suggestion and Broadcom's convention. See [1] and >>>> you are okay with that [2]. I added the rev compatible and you were not >>>> objecting it finally if I understand you correctly. >>> >>> Can you have a driver that only understands what 'brcm,bcmbca-hsspi' is >>> work on all h/w that includes the compatible string? It doesn't seem >>> like it since v1.1 is a completely new driver. Therefore >>> 'brcm,bcmbca-hsspi' is pretty much useless. >>> >> 'brcm,bcmbca-hsspi' should be added to the binding table of >> spi-bcm63xx-hsspi.c driver. This is the initial driver that works for >> v1.0 controller. For v1.1 controller, yes it can fallback and work with >> 1.0 driver spi-bcm63xx-hsspi.c simply not using the new feature in >> v1.1(chip select signal control through software) and keeping using the >> prepend mode or dummy cs workaround supported in 1.0 driver. > > If v1.1 is compatible with v1.0, then say that: > > soc-compat, "brcm,bcmbca-hsspi-v1.1", "brcm,bcmbca-hsspi-v1.0" > > IOW, 'brcm,bcmbca-hsspi' is redundant with 'brcm,bcmbca-hsspi-v1.0'. > They have the same meaning. So pick which one you want to use. Not > both. > Agree brcm,bcmbca-hsspi fallback is redundant to brcm,bcmbca-hsspi-v1.0. I added it to conform Broadcom convention. But I understand your and Krzystof's concern so I'll drop the brcm,bcmbca-hsspi in v3 to get things going. > Also, if that is the case, you shouldn't be introducing a whole new > driver for v1.1. > Technically I can combine the new feature to the existing driver v1.0 but I prefer to start the a new driver so it will be much cleaner and simpler to follow without all the workarounds and complex logic. > Rob >
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml index d1a0c9adee7a..d39604654c9e 100644 --- a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml +++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml @@ -4,20 +4,73 @@ $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: + + - William Zhang <william.zhang@broadcom.com> + - Kursad Oney <kursad.oney@broadcom.com> - Jonas Gorski <jonas.gorski@gmail.com> -allOf: - - $ref: spi-controller.yaml# +description: | + Broadcom Broadband SoC supports High Speed SPI master controller since the + early MIPS based chips such as BCM6328 and BCM63268. This initial rev 1.0 + controller was carried over to recent ARM based chips, such as BCM63138, + BCM4908 and BCM6858. The old MIPS based chip should continue to use the + brcm,bcm6328-hsspi compatible string. The recent ARM based chip is required to + use the brcm,bcmbca-hsspi-v1.0 as part of its compatible string list as + defined below to match the specific chip along with ip revision info. + + This rev 1.0 controller 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. Driver automatically picks the suitable mode based on + transfer type so it is transparent to the user. + + The newer SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI + controller rev 1.1 that add the capability to allow the driver to control chip + select explicitly. This solves the issue in the old controller. properties: compatible: - const: brcm,bcm6328-hsspi + oneOf: + - const: brcm,bcm6328-hsspi + - items: + - enum: + - brcm,bcm47622-hsspi + - brcm,bcm4908-hsspi + - brcm,bcm63138-hsspi + - brcm,bcm63146-hsspi + - brcm,bcm63148-hsspi + - brcm,bcm63158-hsspi + - brcm,bcm63178-hsspi + - brcm,bcm6846-hsspi + - brcm,bcm6856-hsspi + - brcm,bcm6858-hsspi + - brcm,bcm6878-hsspi + - const: brcm,bcmbca-hsspi-v1.0 + - const: brcm,bcmbca-hsspi + - items: + - enum: + - brcm,bcm4912-hsspi + - brcm,bcm6756-hsspi + - brcm,bcm6813-hsspi + - brcm,bcm6855-hsspi + - const: brcm,bcmbca-hsspi-v1.1 + - const: brcm,bcmbca-hsspi reg: - maxItems: 1 + items: + - description: main registers + - description: miscellaneous control registers + minItems: 1 + + reg-names: + items: + - const: hsspi + - const: spim-ctrl + minItems: 1 clocks: items: @@ -39,10 +92,39 @@ required: - clock-names - interrupts +allOf: + - $ref: spi-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - brcm,bcm6328-hsspi + - brcm,bcmbca-hsspi-v1.0 + then: + properties: + reg: + minItems: 1 + maxItems: 1 + reg-names: + minItems: 1 + maxItems: 1 + else: + properties: + reg: + minItems: 2 + maxItems: 2 + reg-names: + minItems: 2 + maxItems: 2 + required: + - reg-names + unevaluatedProperties: false examples: - | + #include <dt-bindings/interrupt-controller/arm-gic.h> spi@10001000 { compatible = "brcm,bcm6328-hsspi"; reg = <0x10001000 0x600>; @@ -53,3 +135,17 @@ examples: #address-cells = <1>; #size-cells = <0>; }; + - | + spi@ff801000 { + compatible = "brcm,bcm6756-hsspi", "brcm,bcmbca-hsspi-v1.1", + "brcm,bcmbca-hsspi"; + reg = <0xff801000 0x1000>, + <0xff802610 0x4>; + reg-names = "hsspi", "spim-ctrl"; + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&hsspi>, <&hsspi_pll>; + clock-names = "hsspi", "pll"; + num-cs = <8>; + #address-cells = <1>; + #size-cells = <0>; + };
The new Broadcom Broadband BCMBCA SoCs includes a updated HSSPI controller. Add new compatible strings to differentiate the old and new controller while keeping MIPS based chip with the old compatible. Update property requirements for these two revisions of the controller. Also add myself and Kursad as the maintainers. Signed-off-by: William Zhang <william.zhang@broadcom.com> --- Changes in v2: - Update new compatible string to follow Broadcom convention <chip specific compatible>, <version of the IP>, <fallback> - Add reg-names min/maxItem constraints to be consistent with reg property - Make interrupts required property - Remove double quote from spi-controller.yaml reference - Remove brcm,use-cs-workaround flag - Update the example with new compatile and interrupts property - Update commit message .../bindings/spi/brcm,bcm63xx-hsspi.yaml | 106 +++++++++++++++++- 1 file changed, 101 insertions(+), 5 deletions(-)