On Tue, Sep 6, 2016 at 4:15 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> pa: pinctrla {
> compatible = "parent-device-compat";
> (...)
> };
>
> pb: pinctrlb {
> compatible = "child-device-compat";
> pinctrl-parent = &pinctrla;
> (...)
> };
After thinking some more I kind of fancy the GPIO ranges
approach to be reused:
pa: pinctrla {
compatible = "parent-device-compat";
(...)
};
pb: pinctrlb {
compatible = "child-device-compat";
pinctrl-ranges = <&pa 0 31 0>;
(...)
};
The definition and use would be similar to gpio-ranges, see:
Documentation/devicetree/bindings/gpio/gpio.txt, but these
bindings are specified in BNF which IMO is just confusing.
Anyways its <phandle local-offset count remote-offset>
Also group names are supported for GPIO ranges.
In the Linux implementation this facilitates reuse of the
existing GPIO ranges parsing and resolution.
To make cross-calls we need an abstract call akin to the
existing pinctrl_request_gpio() and pinctrl_free_gpio()
just named pinctrl_request_hierarchical()
pinctrl_free_hierarchical() or so so it is chrystal clear
what is going on when reading the code.
As this passes through the pinctrl driver core, new callbacks
are needed in struct pinmux_ops such as
.hierarchical_request(), .hierarchical_free().
This is going to be complex, but a way more maintainable
solution than doing the hack in patch 1/3 where we totally
loose control and definition of what happens.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
