Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

[Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>]

On 08/23/2012 11:26 PM, Stephen Warren wrote:
> As you may have guessed, I strongly prefer the hard-coded static table
> based approach, or at least separating the definition of known
> pins/groups/functions from the configuration nodes that define which
> particular mux settings to actually use.
>
> Puting this all a little more simply, the pinctrl core wants to generate
> a list of all known functions. It is a single global/unified list. It
> first calls pinmux_ops.get_functions_count() to find out how many
> functions there are in the list, then pinmux_ops.get_function_name() for
> each one to find its name, then pinmux_ops.get_function_groups() to find
> out which groups allow that function to be mux'd onto them.

Ok, now this becomes a little bit more clear to me.

Consider uart1 on dove is muxable to:
mpp2 uart1(rts), mpp3 uart1(cts), mpp21 uart1(rts), mpp22 uart1(cts),
and finally mpp_uart1(rx and tx).

So possible, valid combinations for uart1 would be:
(a) mpp_uart1;
(b) mpp_uart1, mpp2, mpp3;
(c) mpp_uart1, mpp21, mpp22;
(d) mpp_uart1, mpp2, mpp22;
(e) mpp_uart1, mpp21, mpp3;

Now what we currently do is, use DT to setup all known functions with e.g.
marvell,pins = "mpp_uart1", "mpp2", "mpp22" and marvell,function = "uart1".
This requires to count all pinctrl DT node children to count the known
functions that can ever be muxed to. It will never allow to mux uart1 to sw
flow control during run-time when there was no DT child node for it.

But you are proposing to scan the list passed from SoC specific driver for all
possible marvell,function ("uart1", "uart2", "sdio0", ...) and build up lists
of pingroups that can be used with this specific marvell,function; or even build
up lists of pingroups that allow uart1(rts), and another one for uart1(cts), ...?

Sebastian