Skip to contentSkip to conversation

ARM: Add support for Broadcom BCM476x SoCs

PATCH Superseded Domenico Andreoli 2 participants 9 messages Oct 14, 2012 – Oct 19, 2012 Device tree bindings

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore

Domenico Andreoli

author
#0 lore raw

v2 cover ARM: Add support for Broadcom BCM476x SoCs

Hallo,

first of all thank you for the feedback you've sent on the first
round of this patchset. I think I've addressed all the points plus some extra I've found on the way. The details are in the description of the single patches.

Tested on v3.7-rc1 (ddffeb8). Any feedback is welcome.

Thanks,
Domenico

#2 lore raw

PATCH v2 1/5 ARM: bcm476x: Add platform infrastructure

Quoted 3 lines · Domenico Andreoli

From: Domenico Andreoli <[email protected]>

Platform infrastructure for the Broadcom BCM476x ARMv6 SoCs.

Hi Domenico,

All your patches look good to me now, except for one thing throughout the bindings:

Quoted 10 lines

Index: b/Documentation/devicetree/bindings/arm/bcm476x.txt
===================================================================

Documentation/devicetree/bindings/arm/bcm476x.txt new file +5 -0
@@ -0,0 +1,15 @@
+Broadcom BCM4760 and BCM4761 SoCs device tree bindings
+------------------------------------------------------
+
+Boards with the BCM4760 SoC shall have the following properties:
+

Documentation/devicetree/bindings/arm/bcm476x.txt line 15

Quoted 10 lines
Documentation/devicetree/bindings/arm/bcm476x.txt new file +10 -0
+Required root node property:
+
+compatible = "brcm,bcm4760";
+
+
+Boards with the BCM4761 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4761";

I probably wasn't clear enough with my request to have specific chip identifiers in the device tree "compatible" nodes. The idea generally is that for completely identical hardware blocks, you just need to put the first known variant into the driver, e.g. "brcm,bcm4760-system-timer", and in case of a later chip that is compatible with it, you list both "brcm,bcm4760-system-timer" and "brcm,bcm4761-system-timer" in the compatible property of the device tree. The way you did it is also correct and works, but is a bit less common.

How do you want to merge your patches? The preferred way from our side is to get a pull request from you sent to arm at kernel.org with Cc to the linux-arm-kernel mailing list, but we can also pick up the patches separately if necessary.

For the patches that go into different directories like the clk and the clocksource drivers, please Cc the respective subsystem maintainers and ask them for an Ack. It certainly makes sense for a new platform port to get merged through the arm-soc tree, but any future improvements should normally just go through the subsystem trees.

Arnd

author
#3 lore raw

PATCH v2 1/5 ARM: bcm476x: Add platform infrastructure

Quoted 6 lines · Arnd Bergmann
Quoted 3 lines · Domenico Andreoli

From: Domenico Andreoli <[email protected]>

Platform infrastructure for the Broadcom BCM476x ARMv6 SoCs.

Hi Domenico,

Hi Arnd,

Quoted 34 lines

All your patches look good to me now, except for one thing throughout the bindings:

Quoted 10 lines

Index: b/Documentation/devicetree/bindings/arm/bcm476x.txt
===================================================================

Documentation/devicetree/bindings/arm/bcm476x.txt new file +5 -0
@@ -0,0 +1,15 @@
+Broadcom BCM4760 and BCM4761 SoCs device tree bindings
+------------------------------------------------------
+
+Boards with the BCM4760 SoC shall have the following properties:
+

Documentation/devicetree/bindings/arm/bcm476x.txt line 15

Quoted 10 lines
Documentation/devicetree/bindings/arm/bcm476x.txt new file +10 -0
+Required root node property:
+
+compatible = "brcm,bcm4760";
+
+
+Boards with the BCM4761 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4761";

I probably wasn't clear enough with my request to have specific chip identifiers in the device tree "compatible" nodes. The idea generally is that for completely identical hardware blocks, you just need to put the first known variant into the driver, e.g. "brcm,bcm4760-system-timer", and in case of a later chip that is compatible with it, you list both "brcm,bcm4760-system-timer" and "brcm,bcm4761-system-timer" in the compatible property of the device tree. The way you did it is also correct and works, but is a bit less common.

Quoted 4 lines

How do you want to merge your patches? The preferred way from our side is to get a pull request from you sent to arm at kernel.org with Cc to the linux-arm-kernel mailing list, but we can also pick up the patches separately if necessary.

so the above becomes:

Documentation/devicetree/bindings/arm/bcm476x.txt new file +15 -0
Index: b/Documentation/devicetree/bindings/arm/bcm476x.txt
===================================================================
@@ -0,0 +1,15 @@
+Broadcom BCM4760 and BCM4761 SoCs device tree bindings
+------------------------------------------------------
+
+Boards with the BCM4760 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4760";
+
+
+Boards with the BCM4761 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4760", "brcm,bcm4761";

and the dt_mach in the board file is left only with "brcm,bcm4760" until required otherwise. The same applies to drivers.

Does the order matter?

Quoted 6 lines

For the patches that go into different directories like the clk and the clocksource drivers, please Cc the respective subsystem maintainers and ask them for an Ack. It certainly makes sense for a new platform port to get merged through the arm-soc tree, but any future improvements should normally just go through the subsystem trees.

I'd prefer patches but only because I've not any public git repository. If the git pull is much more preferred, I surely can manage it.

Thanks,
Domenico

#4 lore raw

PATCH v2 1/5 ARM: bcm476x: Add platform infrastructure

Quoted 16 lines · Domenico Andreoli
Quoted 1 line · Arnd Bergmann

On Sunday 14 October 2012, Domenico Andreoli wrote:

Documentation/devicetree/bindings/arm/bcm476x.txt new file +13 -0
+
+Boards with the BCM4760 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4760";
+
+
+Boards with the BCM4761 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4760", "brcm,bcm4761";
Quoted 2 lines

and the dt_mach in the board file is left only with "brcm,bcm4760" until required otherwise. The same applies to drivers.

Right.

Quoted 1 line

Does the order matter?

Yes, you have to have the most specific one first, and the most generic one last, as documented in Documentation/devicetree/booting-without-of.txt.

If one chip has a functionality that the other one doesn't but is otherwise completely compatible, then the less capable one should be put last.

For the root node, you might actually want to keep both "compatible" strings separate as you have in the version you posted, at least if the chips are not completely backwards compatible. For the other devices inside of the soc, just use one.

Quoted 9 lines
Quoted 6 lines

For the patches that go into different directories like the clk and the clocksource drivers, please Cc the respective subsystem maintainers and ask them for an Ack. It certainly makes sense for a new platform port to get merged through the arm-soc tree, but any future improvements should normally just go through the subsystem trees.

I'd prefer patches but only because I've not any public git repository. If the git pull is much more preferred, I surely can manage it.

Ok, no problem. In the long run, it can be useful for you to set up your own git tree, for for now, we can manage with patches just fine.

Arnd