[PATCH] pinctrl: phandle entries will be applied sequentially

On Thu, Oct 10, 2013 at 10:03:40AM +0200, Linus Walleij wrote:

On Thu, Oct 10, 2013 at 9:26 AM, Shawn Guo [off-list ref] wrote:

quoted

However, my patch is talking about a different thing.  For example, we
have a device whose pinctrl-0 consists of two phandle entries that point
to pin configuration nodes foo and bar.

        pinctrl-0 = <&foo &bar>;

        foo {
                ...
        };

        bar {
                ...
        };

My patch only wants to make it clear that the configuration specified by
node foo will be applied to pin controller first, and the configuration
defined in node bar will be applied after that.  When both nodes have
configuration for a pin, these two configs for the same pin go to two
different pinctrl_setting structures.  And these two pinctrl_settings
can not be applied accumulatedly but only sequentially.  That's what my
patch talks about.

OK I get it (I think).

However isn't this aspect rather a property of how the specific driver
parses and uses the device tree?

The 'pinctrl-0' property is defined by common pinctrl device tree
binding and is parsed by pinctrl core, while pin configuration node
is platform specific and handled by controller driver.

Remember that with drivers that do not use generic pin config,
we have left the handling of the device tree node up to the driver
by the callback dt_node_to_map().

Yes.  dt_node_to_map() takes pin configuration node pointer as input and
return a set of struct pinctrl_map.  But how pinctrl_map eventually gets
turned into pinctrl_setting as the input to pinconf_apply_setting() call
are all handled by pinctrl core and common across different controller
drivers.

But I do understand the ambition to specify this behaviour for all
pin control drivers using device tree.

But we need to be careful since DT isn't very much in the
buisiness of defining sequence semantics for stuff, and that
is why I'm a bit hesitant.

So, maybe we can add this as it only concerns the binding
(but then I want that example to be part of the documentation patch
so that it is crystal clear what we're talking about), but it would be
proper if we also helped enforce this semantic across the drivers,
i.e. centralize more of the DT parsing code...

Ok.  I would hold it off for a while and consider Stephen's comment
first for solving the problem we have on i.MX.

BTW on a related subject: have you examined if the i.MX driver
can use the new utility functions from pinctrl-utils.h:

pinctrl_utils_reserve_map()
pinctrl_utils_add_map_mux()
pinctrl_utils_add_map_configs()
pinctrl_utils_add_config()
pinctrl_utils_dt_free_map()

Thanks for the info.  Just had a quick look at them, and it seems that
they don't save too much code for imx.  Will take another deep look
though.

Shawn