Add support for generic BCM SoC chipsets

In order to start upstreaming Broadcom SoC support, create a starting hierarchy, arch and dts files.
The first support SoC family that is planned is the BCM281XX (BCM11130/11140/11351/28145/28155) family of dual A9 mobile SoC cores.
This code is just the skeleton code for get the machine upstreamed. It has been made MULTIPLATFORM compatible.

Quoted 7 lines · Christian Daudt

In order to start upstreaming Broadcom SoC support, create a starting hierarchy, arch and dts files.
The first support SoC family that is planned is the BCM281XX (BCM11130/11140/11351/28145/28155) family of dual A9 mobile SoC cores.
This code is just the skeleton code for get the machine upstreamed. It has been made MULTIPLATFORM compatible.

Sorry for the slow review...

Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt line 8

Quoted 5 lines

Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt +3 -0

 
+Required root node property:
+
+compatible = "bcm,bcm281xx";

Hmm. I still tend to think we should list the specific SoC rather than the family here, but I guess if you're sure there won't be any SW compatibility between the different SoCs in the series, this is fine.

arch/arm/boot/dts/bcm281xx.dtsi line 35

Quoted 4 lines

arch/arm/boot/dts/bcm281xx.dtsi +2 -0

 
+     uart at 3e000000 {
+             compatible = "snps,dw-apb-uart", "bcm,bcm281xx-sw-apb-uart";

The most specific value should be first, so swap those two entries.

arch/arm/mach-bcm/Kconfig line 18

Quoted 6 lines

arch/arm/mach-bcm/Kconfig +4 -0

 
+     help
+       This enables support for system based on Broadcom SoCs.
+       It currently supports the 'BCM281XX' family, which includes
+       BCM11130, BCM1140, BCM11351, BCM28145 and

Should that be 11140 rather than 1140?

Aside from that,

Reviewed-by Stephen Warren <[email protected]>

Quoted 10 lines

Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt line 8

Quoted 5 lines

Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt +3 -0

 
+Required root node property:
+
+compatible = "bcm,bcm281xx";

Hmm. I still tend to think we should list the specific SoC rather than the family here, but I guess if you're sure there won't be any SW compatibility between the different SoCs in the series, this is fine.

right now I expect to be able to use the family thoughout, so I'll stick to it.

Quoted 1 line · Christian Daudt

Quoted 1 line

Review

Quoted 1 line

(quoted diff) +0 -0

b/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt

Quoted 11 lines

Quoted 9 lines

Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt line 8

Quoted 4 lines

Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt new file +3 -0

+Required root node property:
+
+compatible = "bcm,bcm281xx";

Hmm. I still tend to think we should list the specific SoC rather than the family here, but I guess if you're sure there won't be any SW compatibility between the different SoCs in the series, this is fine.

right now I expect to be able to use the family thoughout, so I'll stick

to it.

Quoted 1 line

But that's not how the compatible property is supposed to work: Each compatible
value should refer to a specific property, and not include wildcards. If you have one driver (or platform file in this case) that can deal with a whole family of devices, the normal solution is to list the name of the oldest
part in the compatible string as the most generic part, and then list the name of the new part as the specific one.

At that point doesn't the 'oldest part' become the wildcard ? I'm not

Quoted 1 line

At that point doesn't the 'oldest part' become the wildcard ? I'm not

very attached to names, so I'm ok changing bcm281xx above to bcm11351, which happens to be the first chip I'm submitting a board for. But then bcm11351 will just become 'the chip name used to represent the family' right ? I had followed the fact that omap does use omap5 in omap5.dtsi - and afaik tegra2 and tegra3 are family names, not chip models, and are used in dtsi. But then again a bunch of chip models are used to represent the families too...
Let me know if you want me to submit a modified patchset. Shouldn't take
me more than 5 minutes anyways :)

Quoted 6 lines · Christian Daudt

Quoted 1 line

At that point doesn't the 'oldest part' become the wildcard ? I'm not

very attached to names, so I'm ok changing bcm281xx above to bcm11351, which happens to be the first chip I'm submitting a board for. But then bcm11351 will just become 'the chip name used to represent the family' right ? I had followed the fact that omap does use omap5 in omap5.dtsi - and afaik tegra2 and tegra3 are family names, not chip models, and are

used

Quoted 4 lines

in dtsi. But then again a bunch of chip models are used to represent the families too...
Let me know if you want me to submit a modified patchset. Shouldn't take
me more than 5 minutes anyways :)

I think in a lot of cases, we just list all the possible parts specifically since we already know them, especially when supporting a new one requires changing code already.

Using bcm11351 as the name for the family sounds reasonable to me when the other ones are derived from that, and the other option is to just list all the ones that are out there already in the source code match table. For future SoCs, you can then decide whether you want to change the code to add the new number or just list one of the existing parts as backwards compatible for the new device tree file if that allows you to support it without other code changes.

Please pick one of the two options and resubmit.

Quoted 28 lines · Arnd Bergmann

Quoted 12 lines · Christian Daudt

Quoted 1 line

At that point doesn't the 'oldest part' become the wildcard ? I'm not

very attached to names, so I'm ok changing bcm281xx above to bcm11351, which happens to be the first chip I'm submitting a board for. But then bcm11351 will just become 'the chip name used to represent the family' right ? I had followed the fact that omap does use omap5 in omap5.dtsi - and afaik tegra2 and tegra3 are family names, not chip models, and are used
in dtsi. But then again a bunch of chip models are used to represent the families too...
Let me know if you want me to submit a modified patchset. Shouldn't
take
me more than 5 minutes anyways :)

I think in a lot of cases, we just list all the possible parts specifically
since we already know them, especially when supporting a new one requires changing code already.

Using bcm11351 as the name for the family sounds reasonable to me when the other ones are derived from that, and the other option is to just list all the ones that are out there already in the source code match table. For future SoCs, you can then decide whether you want to change the code to add the new number or just list one of the existing parts as backwards compatible for the new device tree file if that allows you to support it without other code changes.

Quoted 1 line

Please pick one of the two options and resubmit.

ok. resubmitting shortly with bcm11351.

On an administrative question: Stephen sent me a reviewed-by that effectively applied to V4 of the patch. I dropped it for V5 as this is not the exact patchset that he reviewed. Is the expected procedure that new versions of patches carry previous reviewed-by or not ? I could not find any reference to that in the submittingpatches doc

and afaik tegra2 and tegra3 are family names, not chip models, and are used in dtsi. But then again a bunch of chip models are used to represent the families too... Let me know if you want me to submit a modified patchset. Shouldn't take me more than 5 minutes anyways :)

From a software perspective at least, all Tegra2x are the exact same chip, same for Tegra3.