On Fri, Mar 9, 2012 at 7:14 PM, Stephen Warren <swar...@wwwdotorg.org> wrote:
> --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt > @@ -0,0 +1,118 @@ > +== Introduction == > + > +Hardware modules that control pin multiplexing or configuration parameters > +such as pull-up/down, tri-state, drive-strength etc are designated as pin > +controllers. Each pin controller must be represented as a node in device > tree, > +just like any other hardware module. Maybe put in a reference to Documentation/pinctrl.txt for in-depth discussion? Also some stuff may be moved over there as generic information. A lot of the text here does not seem to be about the device tree ... However maybe the use case is outside the Linux kernel too and in that case I'm happy with it. > +For a client device to operate correctly, certain pin controllers must > +set up certain specific pin configurations. Some client devices need a > +single static pin configuration, e.g. set up during initialization. Others > +need to reconfigure pins at run-time, for example to tri-state pins when the > +device is inactive. Hence, each client device can define a set of named > +states. The number and names of those states is defined by the client > device's > +own binding. Just so I understand: is "pin configuration" here strictly what we handle in pinconf.c or does it include multiplexing (pinmux.c)? I guess it's not multiplexing, just making sure. Maybe state explicitly that multiplexing is not part of pin config, else someone will invariably get confused. > +Note that pin controllers themselves may also be client devices of > themselves. Insert something about this being known as config hogging. The rest I barely understand so I leave it for the others to discuss... Yours, Linus Walleij _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
