ARM: prima2: move to generic reset controller driver framework

this moves to generic IP module reset framework, and make other drivers use common device_reset() API.

Documentation/devicetree/bindings/reset/sirf,rstc.txt new file +9 -0

new file mode 100644
index 0000000..0505de7
@@ -0,0 +1,42 @@
+CSR SiRFSoC Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "sirf,prima2-rstc" or "sirf,marco-rstc"
+- reg: should be register base and length as documented in the

Documentation/devicetree/bindings/reset/sirf,rstc.txt new file +9 -0

+void __init sirfsoc_of_rstc_init(void)
+{
+	struct device_node *np = of_find_matching_node(NULL, rstc_ids);
+	if (!np) {
+		pr_err("unable to find compatible sirf rstc node in dtb\n");
+		return;
+	}
+
+	sirfsoc_rstc_base = of_iomap(np, 0);

Quoted 18 lines

this moves to generic IP module reset framework, and make other drivers use common device_reset() API.

Documentation/devicetree/bindings/reset/sirf,rstc.txt new file +9 -0

new file mode 100644
index 0000000..0505de7
@@ -0,0 +1,42 @@
+CSR SiRFSoC Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "sirf,prima2-rstc" or "sirf,marco-rstc"
+- reg: should be register base and length as documented in the

Documentation/devicetree/bindings/reset/sirf,rstc.txt line 19

Quoted 10 lines

Documentation/devicetree/bindings/reset/sirf,rstc.txt new file +10 -0

+  datasheet
+- #reset-cells: 1, see below
+
+example:
+
+rstc: reset-controller at 88010000 {
+     compatible = "sirf,prima2-rstc";
+     reg = <0x88010000 0x1000>;
+     #reset-cells = <1>;
+};

Binding looks good to me.

Quoted 15 lines

Documentation/devicetree/bindings/reset/sirf,rstc.txt new file +15 -0

+void __init sirfsoc_of_rstc_init(void)
+{
+     struct device_node *np = of_find_matching_node(NULL, rstc_ids);
+     if (!np) {
+             pr_err("unable to find compatible sirf rstc node in dtb\n");
+             return;
+     }
+
+     sirfsoc_rstc_base = of_iomap(np, 0);
+     if (!sirfsoc_rstc_base) {
+             pr_err("unable to map rstc cpu registers\n");
+             return;
+     }
+
+     sirfsoc_reset_controller.of_node = np;

Documentation/devicetree/bindings/reset/sirf,rstc.txt line 38

Quoted 4 lines

Documentation/devicetree/bindings/reset/sirf,rstc.txt new file +4 -0

+
+     reset_controller_register(&sirfsoc_reset_controller);
+}
+

Can't this be a regular platform device? Drivers that get the reference to the reset controller should respect a -EPROBE_DEFER error message if they get initialized in the wrong order.

Arnd

2014/1/6 Arnd Bergmann <[email protected]>:

Quoted 17 lines · Barry Song

Quoted 16 lines

arch/arm/mach-prima2/rstc.c +15 -0

+void __init sirfsoc_of_rstc_init(void)
+{
+     struct device_node *np = of_find_matching_node(NULL, rstc_ids);
+     if (!np) {
+             pr_err("unable to find compatible sirf rstc node in dtb\n");
+             return;
+     }
+
+     sirfsoc_rstc_base = of_iomap(np, 0);
+     if (!sirfsoc_rstc_base) {
+             pr_err("unable to map rstc cpu registers\n");
+             return;
+     }
+
+     sirfsoc_reset_controller.of_node = np;

Quoted 8 lines

arch/arm/mach-prima2/rstc.c int sirfsoc_reset_device(struct device *dev) · line 97

Quoted 4 lines

arch/arm/mach-prima2/rstc.c +4 -0

+
+     reset_controller_register(&sirfsoc_reset_controller);
+}
+

Can't this be a regular platform device? Drivers that get the reference to the reset controller should respect a -EPROBE_DEFER error message if they get initialized in the wrong order.

Arnd, it is ok if prima2 is not a platform for automotive. here prima2 actually wants a "right" order for products.
for example, there are some local hacking to move camera for rearview started earlier than other devices as this feature needs to be ready as early as possible.
some earlier boot devices depend on reset module to be ready. so if we move to regular platform driver for upstream, it still requires some local hacking to move it earlier.

Quoted 27 lines

2014/1/6 Arnd Bergmann <[email protected]>:

Quoted 17 lines · Barry Song

Quoted 16 lines

arch/arm/mach-prima2/rstc.c +15 -0

+void __init sirfsoc_of_rstc_init(void)
+{
+     struct device_node *np = of_find_matching_node(NULL, rstc_ids);
+     if (!np) {
+             pr_err("unable to find compatible sirf rstc node in dtb\n");
+             return;
+     }
+
+     sirfsoc_rstc_base = of_iomap(np, 0);
+     if (!sirfsoc_rstc_base) {
+             pr_err("unable to map rstc cpu registers\n");
+             return;
+     }
+
+     sirfsoc_reset_controller.of_node = np;

Quoted 8 lines

arch/arm/mach-prima2/rstc.c int sirfsoc_reset_device(struct device *dev) · line 97

Quoted 4 lines

arch/arm/mach-prima2/rstc.c +4 -0

+
+     reset_controller_register(&sirfsoc_reset_controller);
+}
+

Can't this be a regular platform device? Drivers that get the reference to the reset controller should respect a -EPROBE_DEFER error message if they get initialized in the wrong order.

Quoted 8 lines

Arnd, it is ok if prima2 is not a platform for automotive. here prima2 actually wants a "right" order for products.
for example, there are some local hacking to move camera for rearview started earlier than other devices as this feature needs to be ready as early as possible.
some earlier boot devices depend on reset module to be ready. so if we move to regular platform driver for upstream, it still requires some local hacking to move it earlier.

I don't understand what you mean. It should be a matter of a few miliseconds at most to retry initialization, more likely in the microseconds. How big are the delays you are worried about?

Arnd

2014/1/7 Arnd Bergmann <[email protected]>:

Quoted 14 lines · Barry Song

Quoted 4 lines

Quoted 3 lines

Can't this be a regular platform device? Drivers that get the reference to the reset controller should respect a -EPROBE_DEFER error message if they get initialized in the wrong order.

Quoted 8 lines

Arnd, it is ok if prima2 is not a platform for automotive. here prima2 actually wants a "right" order for products.
for example, there are some local hacking to move camera for rearview started earlier than other devices as this feature needs to be ready as early as possible.
some earlier boot devices depend on reset module to be ready. so if we move to regular platform driver for upstream, it still requires some local hacking to move it earlier.

Quoted 3 lines

I don't understand what you mean. It should be a matter of a few miliseconds at most to retry initialization, more likely in the microseconds. How big are the delays you are worried about?

what i am worrried about is 100ms or more. device drivers need time to initialize and that will take time, if some devices initialization happen before the deferred probing, the deferred probing might be delayed 100ms.
for example, we want camera begin to show rear-view in several hundreds of ms, there are some local hacking to move i2c and camera probe earlier than other devices.
that means actually there is requirement for right order of probing but not defer probing sometimes.

Quoted 19 lines

2014/1/7 Arnd Bergmann <[email protected]>:

Quoted 14 lines · Barry Song

Quoted 4 lines

Quoted 3 lines

Can't this be a regular platform device? Drivers that get the reference to the reset controller should respect a -EPROBE_DEFER error message if they get initialized in the wrong order.

Quoted 8 lines

Arnd, it is ok if prima2 is not a platform for automotive. here prima2 actually wants a "right" order for products.
for example, there are some local hacking to move camera for rearview started earlier than other devices as this feature needs to be ready as early as possible.
some earlier boot devices depend on reset module to be ready. so if we move to regular platform driver for upstream, it still requires some local hacking to move it earlier.

Quoted 3 lines

I don't understand what you mean. It should be a matter of a few miliseconds at most to retry initialization, more likely in the microseconds. How big are the delays you are worried about?

Quoted 9 lines

what i am worrried about is 100ms or more. device drivers need time to initialize and that will take time, if some devices initialization happen before the deferred probing, the deferred probing might be delayed 100ms.
for example, we want camera begin to show rear-view in several hundreds of ms, there are some local hacking to move i2c and camera probe earlier than other devices.
that means actually there is requirement for right order of probing but not defer probing sometimes.

I see, this seems like a valid concern. I had not considered that other drivers might need more time for initialization. In general of course they should not, but I understand that hardware is not perfect and some drivers you don't own may have bugs that cause unnecessary delays.

We have discussed probe ordering a lot of times on the mailing lists and also during the last kernel summit, but those discussions are usually focused on trying to correctly boot up a system, which is hard enough even without additional requirements like yours.

Generally the hack that people use when things fail to work correctly is to hijack an earlier initcall level, e.g. subsys_initcall rather than using module_init. Please first see if that can solve your problem. If it doesn't help, please resubmit your current patch with a detailed description in the code on why you have to do it like this.

Arnd