[PATCH v3 8/8] reset: Add driver for gpio-controlled reset pins

On 02/20/2013 04:22 AM, Philipp Zabel wrote:

Am Dienstag, den 19.02.2013, 14:57 -0700 schrieb Stephen Warren:

quoted

On 02/19/2013 04:35 AM, Philipp Zabel wrote:

quoted

This driver implements a reset controller device that toggles gpios
connected to reset pins of peripheral ICs. The delay between assertion
and de-assertion of the reset signal can be configured.

quoted

quoted

+		/*
+		 * The flags are also used to remember whether a given GPIO
+		 * reset is active-low.
+		 */
+		if (flags & OF_GPIO_ACTIVE_LOW)
+			drvdata->gpios[i].flags = GPIOF_OUT_INIT_HIGH;
+		else
+			drvdata->gpios[i].flags = GPIOF_OUT_INIT_LOW;

That raises the question: What is the initial reset state expected to
be? Some devices might want to stay in reset until their driver
explicitly removes the reset signal.

We could handle that by adding another (optional) property indicating
the initial reset state of each GPIO; default to initially not-in-reset
unless that property exists and specifies initially-in-reset.

As with the time parameter, I wonder if this configuration is something
we want to have in the consumer device tree node, or in the gpio-reset
device node:

	gpio_reset: gpio-reset {
		compatible = "gpio-reset";
		reset-gpios = <&gpio2 15 0>;
		reset-delays = <1000>; /* 1 ms */
		initially-in-reset = <1>;
	}
	some-device {
		resets = <&gpio_reset 0>;
	}
vs.
	gpio_reset: gpio-reset {
		compatible = "gpio-reset";
		reset-gpios = <&gpio2 15 0>;
	}
	some-device {
		resets = <&gpio_reset 0 1000>; /* 1 ms */
		initially-in-reset;
	}

I think that the initially-in-reset state has to be represented in the
gpio-reset node, since that's the only node that the GPIO reset driver
will have access to during its probe(), and you're setting up the GPIOs
as outputs during probe(). You can't rely on the drivers for the client
DT nodes to be probed first and provide the information to the reset
controller driver, since probe ordering is undefined. In fact those
probe()s won't have run first, because those devices depend on resources
from the reset controller driver and hence can't probe before it.

If the initially-in-reset properties are in the client device nodes,
then the GPIO reset driver would need to search all nodes for a resets
property that references the appropriate gpio-reset node, then search
for an initially-in-reset property there too. That all seems quite messy.