| Message ID | 20170530060851.29923-2-joel@jms.id.au |
|---|---|
| State | New |
| Headers | show |
| Series | reset: Basic reset controller | expand |
On Thu, Jun 8, 2017 at 6:19 AM, Rob Herring <robh@kernel.org> wrote: > On Tue, May 30, 2017 at 03:38:50PM +0930, Joel Stanley wrote: >> This adds the bindings documentation for a basic single-register reset >> controller. >> >> The bindings describe a single 32-bit register that contains up to 32 >> reset lines, each deasserted by clearing the appropriate bit in the >> register. Optionally a property can be provided that changes this >> behaviour to assert on clear. >> > > I think this is a good idea for kernel code, but not for bindings. We > don't really want per register bindings. > > The problem with any generic/simple/basic binding is they always start > that way. Then we add one property at a time not in any well planned > way. I can easily come up with additions. For example, what about > self-clearing reset bits. Or 2 bits per reset. Or multiple resets that > have to be controlled together. 8 or 16-bit registers. Thanks for the explanation. I will send a v3 with aspeed specific bindings. How should I handle the driver? Were you suggesting I keep it generic, but with my aspeed compatible? Cheers, Joel > > IRQs and GPIOs could also be described in some cases with just groups of > 32-bit registers for set,clear,status,mask,etc., but we don't do that in > bindings for the same reasons. > > Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/reset/reset-basic.txt b/Documentation/devicetree/bindings/reset/reset-basic.txt new file mode 100644 index 000000000000..c19e5368be67 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/reset-basic.txt @@ -0,0 +1,43 @@ +Basic single-register reset controller +====================================== + +This describes a generic reset controller where the reset lines are controlled +by single bits within a 32-bit memory location. The memory location is assumed +to be part of a syscon regmap. + +By default the bit will be cleared on deassert. This behaviour can be inverted +with the assert-on-clear property mentioned below. + +The bits are assumed to not be auto-clearing, and therefore can be read back to +determine the status. + +Reset controller required properties: + - compatible: should be "reset-basic" + - #reset-cells: must be set to 1 + - reg: reset register location within regmap + +Reset controller optional properties: + - assert-on-clear: add this property when the hardware should clear (set to 0) + the bit should to assert the reset. + When this property is omitted the default is to set the bit to assert the + reset + +Device node required properties: + - resets phandle + - bit number, counting from zero, for the desired reset line. Max is 31. + +Example: + +syscon { + compatible = "syscon"; + + uart_reset: reset-controller@c { + compatible = "reset-basic"; + #reset-cells = <1>; + reg = <0xc>; + }; +} + +&uart { + resets = <&uart_rest 4>; +}