Hi folks,
cutting all the discussions in this thread we need to see the bigger
pattern:
On GPIO rails
People want "something like rails" for GPIO. In power supplies
and thus the regulator subsystem, rails are connected to many
logical endpoints.
- The suggested inverter bindings would be effectively an
inverter on a GPIO rail.
- This suggestion would be equal to many power consumers
on a rail, such as the usecase of shared gpio-enable lines in
the regulator subsystem already provides.
The former seems to have been identified as solveable for the
userspace that needed it and absorbed into the drafts for a
virtualized GPIO controller. (Aggregating and creating a new
virtual GPIO chip for some select physical GPIO lines.)
I haven't seen an exact rationale from the DT community as
to why these things should not be modeled, but as can be
clearly seen in
Documentation/devicetree/bindings/regulator/regulator.yaml
the "rail abstraction" from the regulator subsystem which
is in effect struct regulation_constraints and it sibling
struct regulator_init_data is not in the DT bindings, instead
this is encoded as properties in the regulator itself, so this
is pretty consistent: the phandle from regulator to consumer
*is* the rail.
This goes back to Rajendras initial DT regulator support code
see:
git log -p 69511a452e6d
So it would be logical then to just have:
- More than one phandle taking the same GPIO line
- Figure this situation out in the gpiolib OF core
- Resolve the manageability of the situation (same
consumer flags etc)
- Instantiate a kernel component as suggested,
mediating requests.
- Handle it from there.
So:
gpio: gpio-controller@0 {
compatible = "foo,gpio";
gpio-controller;
#gpio-cells = <2>;
};
consumer-a {
compatible = "foo,consumer-a";
rst-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
};
consumer-b {
compatible = "foo,consumer-b";
rst-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
};
Hi kernel: figure it out.
>From this point the kernel driver(s) have to figure it out.
I don't think this requires any changes to the DT bindings
other than perhaps spelling out that if you link more than one
phandle to a GPIO line, magic will happen. (We should probably
make very verbose dmesg prints about this magic.)
This is enough to start with. After that we can discuss adding
flags and constraint properties to a certain GPIO line if
need be. (That will be a big discussion as well, as we haven't
even figured out how to assign default values to individual
GPIO lines yet.)
Yours,
Linus Walleij
