ARM: Broadcom BCM4760 support

From: Domenico Andreoli <[email protected]>

Platform infrastructure for the Broadcom BCM4760 based ARM11 SoCs.

v4:
* added low-level debug PL01X parameters
* added clocks to the VICs DT stanzas

v3:
* dropped the idea of unconditionally build mach-bcm

v2:
* clocks are now configured via DT
* uart DT nodes have been renamed and hooked to the proper clock nodes
* dropped unneeded config options
* dropped misused initialization of system_rev
* dropped unneeded early io mapping
* build rule of mach-bcm is moved to separated patch

v1:
* initial release

Cc devicetree at vger.kernel.org

Cc linux-arm-kernel at lists.infradead.org

Acked-by Jason Cooper <[email protected]>

Signed-off-by Domenico Andreoli <[email protected]>

---

Review

Quoted 13 lines · Domenico Andreoli

(quoted diff) +13 -0

+
+static int __init bcm4760_wdt_init(void)
+{
+	struct device_node *node;
+
+	node = of_find_matching_node(NULL, bcm4760_pm_wdt_match);
+	if (!node) {
+		pr_info("No bcm4760 watchdog node\n");
+		return -1;
+	}
+
+	wdt_regs = of_iomap(node, 0);
+	of_node_put(node);

Since this is now in the drivers directory and initialized at regular module_init level, I'd ask you to register it as a proper platform_driver and move the initialization into the probe() callback. You also need to put Wim as the watchdog subsystem maintainer on Cc (I did in this reply) and ask him to merge the driver.

I assume that Wim will ask you to add a watchdog_register_device() call and a set of watchdog_ops to make this a functional driver. From the platform perspective, I don't care, but it is certainly a logical step.

issue here is that there is already a proper watchdog driver, the sp805.

so I guess now the task shifts to adding restart hook support to it, right?

Quoted 3 lines · Domenico Andreoli

issue here is that there is already a proper watchdog driver, the sp805.

so I guess now the task shifts to adding restart hook support to it, right?

Yes, correct.

There is an interesting question however: we have to deal with the same driver being used in some machines that need to use it as the only way to reset the system, as well as the case where you actually want to use some other method.

An easy way to handle this would be a boolean device tree property that tells the driver whether or not to register, but we might want to come up with a more sophisticated way to have multiple reset handlers registered an prioritized so we try the "best" one first. Maybe someone else has an opinion on this. If not, just do the property.

Arnd

Quoted 7 lines · Arnd Bergmann

Quoted 3 lines · Domenico Andreoli

issue here is that there is already a proper watchdog driver, the sp805.

so I guess now the task shifts to adding restart hook support to it, right?

Yes, correct.

Quoted 3 lines

There is an interesting question however: we have to deal with the same driver being used in some machines that need to use it as the only way to reset the system, as well as the case where you actually want to use some other method.

in a certain sense, there is space for a generic watchdog based restart hook mechanism but the current watchdog ops do not provide the necessary guarantees in atomic context.

Quoted 5 lines

An easy way to handle this would be a boolean device tree property that tells the driver whether or not to register, but we might want to come up with a more sophisticated way to have multiple reset handlers registered an prioritized so we try the "best" one first. Maybe someone else has an opinion on this. If not, just do the property.

the simplest solution I see is adding a DT option to the sp805 driver so that it registers the restart hook when asked to do so.

need to investigate whether the sp805 DT support is provided by some generic AMBA mechanism or is completely missing.

Quoted 7 lines · Domenico Andreoli

Quoted 3 lines

issue here is that there is already a proper watchdog driver, the sp805.

so I guess now the task shifts to adding restart hook support to it, right?

Yes, correct.

Quoted 3 lines

There is an interesting question however: we have to deal with the same driver being used in some machines that need to use it as the only way to reset the system, as well as the case where you actually want to use some other method.

in a certain sense, there is space for a generic watchdog based restart hook mechanism but the current watchdog ops do not provide the necessary guarantees in atomic context.

I remember that the Cobalt Devices have no ability to reboot themselves. That's why the driver uses the reboot_notifier for rebooting the device. See drivers/watchdog/alim7101_wdt.c .

I'll have a look to have an extra ops that adds this functionality in the framework.

Quoted 4 lines · On Monday 16 September 2013 14:00:01 Wim Van Sebroeck wrote:

I remember that the Cobalt Devices have no ability to reboot themselves. That's why the driver uses the reboot_notifier for rebooting the device. See drivers/watchdog/alim7101_wdt.c .

Hmm, a notifier seems the wrong approach here, because we really want to handle all reboot_notifiers before actually rebooting, and we'd enter the wdt driver at a random point in the notifier chain. It probably works by chance if the watchdog reboots a second after its notifier is called, and all other calls are done as well, but it doesn't seem like a clean solution.

Quoted 1 line

I'll have a look to have an extra ops that adds this functionality in the framework.