Re: [RFC] Compound GPIO driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I would love some more input about this driver and the devicetree
bindings for pinctrl.

Recap: I'm writing a driver that will take several regular GPIOs, each
used for some specific function in a compound ruggedized GPIO.

The DT bindings are proving to be a bit of a challenge for me.
This is how I imagine the GPIO part:

    cpdgpio {
        gpio-controller;
        #gpio-cells = <2>;
        compatible = "cpd-pinctrl";

        gpio-line-names = "Compound_GPIO1", "Door_Sensor", "Relay_1";

        gpio_1 {
            in-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
            out_hiside-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
            out_loside-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
            pu-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
            pd-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
        };

        .
        .
        .

        gpio_N {
            .
            .
            .
        };
    };

Where one or more of <function>-gpios needs to be present in each gpio_X
node. For a fully configurable GPIO with PU/PD all five needs to be set
while for a relay, f.ex., only out_hiside-gpios or out_loside-gpios is
needed. This was fairly easy to get running.

The pinctrl binding is where I can't seem to get anywhere.
Here is one way I tried:

    cpdgpio {
        .
        .
        .
        pinctrl-names = "input", "output";
        pinctrl-0 = <&gpio_cfg_input>;
        pinctrl-1 = <&gpio_cfg_output>;

        gpio_cfg_input: gpio1-cfg_in {
            pins = "gpio_1", "gpio_2";
            bias-pull-up;
        };

        gpio_cfg_output: gpio1-cfg_out {
            pins = "gpio_1", "gpio_2", "gpio_3";
            bias-disable;
        };
        .
        .
        .
    };

The idea being that all inputs have the same type of biasing and all
outputs have the same kind of biasing. Now, that may not be a limitation
that I want but I'm just trying to figure out the pinctrl subsystem and
its bindings. This gets picked up when using dt_node_to_map with
pinconf_generic_dt_node_to_map_pin. But when requesting and setting a
pin configuration this will pass all the pins in each node to the
set_config callback, right?

So not only is it impossible to have different biasing for different
inputs, f.ex., I can't bias "gpio_1" without also biasing "gpio_2"?

Another variant I played with was:

    cpdgpio {
        .
        .
        .
        gpio1_cfg: gpio1-cfg {
            pinctrl-names = "default", "output";
            pinctrl-0 = <&gpio1_input>;
            pinctrl-1 = <&gpio1_output>;

            gpio1_input: gpio1-input {
                pins = "gpio_1";
                bias-pull-up;
            };

            gpio1_output: gpio1-output {
                pins = "gpio_1";
                bias-disable;
            };
        };
        .
        .
        .
    };

My, limited, understanding is that I would have to replace the
pinconf_generic_dt_node_to_map_pin with my own callback that can handle
this layout and I'd be all set. Right?

With this kind of binding I could control the biasing, and other
settings for each GPIO separately. I think :)

Any inputs and suggestions for these bindings would be much appreciated.

Regards,
Einar Vading
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux