On Thu, Oct 10, 2013 at 10:03:40AM +0200, Linus Walleij wrote:
> On Thu, Oct 10, 2013 at 9:26 AM, Shawn Guo <shawn.guo@xxxxxxxxxx> wrote:
>
> > 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
--
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
