Pin control mappings for DT

[Linus Walleij]

On Tue, Nov 29, 2011 at 8:59 PM, Tony Lindgren <tony at atomide.com> wrote:

> The current pinctrl mapping is totally messed up in it's current form I'm
> sorry to say in a polite way :)

Hehe :-)

> It currently assumes one set of static map data being passed from the
> board/machine. So you can't mix static data and dynamic data coming
> from DT.

For the global list of maps in pinctrl I sent a patch today which
augments this so board files can add several incremental sets of
maps.

So it can now grow dynamically but not shrink dynamically (hey,
50% done!)

> And it does not allow freeing the mappings if you have a loadable
> pinmux module.. Things get even more messed up when trying to support
> multiple driver instances..
>
> To sort this out the mappings need to be tied to pinctrl/pinmux driver
> instances to start with.

It *is* tied to the pinctrl/pinmux driver instance since each mapping entry
has:

 * @ctrl_dev: the pin control device to be used by this mapping, may be NULL
 *      if you provide .ctrl_dev_name instead (this is more common)
 * @ctrl_dev_name: the name of the device controlling this specific mapping,
 *      the name must be the same as in your struct device*, may be NULL if
 *      you provide .ctrl_dev instead

        struct device *ctrl_dev;
        const char *ctrl_dev_name;

If what you propose is to do away with these two fields and instead
store just the rest of the mapping in a per-pinctrl list passed in
from platform data, as is done with regulators, I see what you mean,
that's maybe more elegant. The current solution is on par with
clkdev.

> That should be done before relying on it further
> and adding more features to it. Anyways, on the positive side, it seems
> that eventually most mappings can be dynamically generated with DT.

Yes, DT will likely make things better.

> Oh, one more thing that needs to be considered is that the mappings are not
> static. Consider popular development boards like beagle. Depending how
> you choose to use the available pins, you need to mux them for an
> extension board, for example. You don't really want to edit the mux mappings
> and recompile the kernel just to support the same board with different
> add on boards. Just changing the DT entries should be enough to map
> the extra pins to an extra I2C controller or LCD or whatever.

Once we have DT support for the mappings this should
come for free I guess?

Linus