Re: [PATCH 1/2] pinctrl: Add Pistachio SoC pin control binding document

[Linus Walleij]

On Tue, Feb 24, 2015 at 3:15 AM, Andrew Bresticker
<abrestic@xxxxxxxxxxxx> wrote:

> Add a device-tree binding document for the pin controller present
> on the IMG Pistachio SoC.
>
> Signed-off-by: Damien Horsley <Damien.Horsley@xxxxxxxxxx>
> Signed-off-by: Andrew Bresticker <abrestic@xxxxxxxxxxxx>
(...)
> +Note that the GPIO bank sub-nodes *must* be listed in order.

Usually we use aliases to mark the order of things. e.g.:

        aliases {
                gpio0 = &gpio0;
                gpio1 = &gpio1;
                gpio2 = &gpio2;
                ethernet0 = &eth0;
                ethernet1 = &eth1;
        };

(arch/arm/boot/dts/armada-375.dtsi)

> +Required properties for pin configuration sub-nodes:
> +----------------------------------------------------
> + - pins: List of pins to which the configuration applies. See below for a
> +   list of possible pins.
> +
> +Optional properties for pin configuration sub-nodes:
> +----------------------------------------------------
> + - function: Mux function for the specified pins. This is not applicable for
> +   non-MFIO pins. See below for a list of valid functions for each pin.
> + - bias-high-impedance: Enable high-impedance mode.
> + - bias-pull-up: Enable weak pull-up.
> + - bias-pull-down: Enable weak pull-down.
> + - bias-bus-hold: Enable bus-keeper mode.
> + - drive-strength: Drive strength in mA. Supported values: 2, 4, 8, 12.
> + - input-schmitt-enable: Enable Schmitt trigger.
> + - input-schmitt-disable: Disable Schmitt trigger.
> + - slew-rate: Slew rate control. 0 for slow, 1 for fast.

We actually haven't specified that function+pins is a valid pattern,
a lot of drivers just started doing that :(

function+groups is documented for muxing.

group + config opts is documented for config.

Please consider patching the generic bindings to reflect this
mux use of pins... We need to discuss it.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/