Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Tony Lindgren <tony@atomide.com>]

Hi,

* Linus Walleij <linus.walleij@linaro.org> [111124 01:29]:
> On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
> > Note that with device tree things get simpler for muxing as we can
> > get rid of the hardcoded grouping of pins in mux drivers. Instead of
> > hardcoded pingroups, the groups can be created dynamically based on
> > what the driver DT entries have.
> 
> Yes, I know too little about DT to figure out how these should
> come in.
> 
> > The reason why we want to avoid hardcoded pin groups is because trying
> > to map all the pad combinations in the pinmux driver is not a scalable
> > way to go. And it's not even possible at least on omaps because of the
> > huge number of combinations with alternative pins and multiple packages.
> 
> Yes, that's a solid case!

So far it seems that device tree simplifies things here quite a bit in at
least two ways:

- We by default have automatically generated 1:1 mapping of devices to
  groups (of course others can be added too)

- We should be able to support new SoC packages with different pin on
  existing kernels, like distro kernels, just by modifying the the device
  tree data ;)
 
> > FYI I'm playing with a DT based pinmux-simple.c driver that should
> > be pretty generic and work for all kinds of hardware hopefully.
> 
> I love it.

Still need few more days with these patches..
 
> > It will be few days before I can post anything though, there are
> > some pinctrl fwk issues to deal with first. Like the hardcoded
> > pinmux_maps that assumes that dev entries are static. This means
> > that multiple instances of pinmux drivers won't work..
> 
> I'm not following, but I guess I will understand when I see the
> patches. The idea behind the current map concept is that you
> get either a string or struct device * to identify the pin controller
> and mapped device, that's as far as I thought it out, sorry for
> any inherent limitations, they're not intentional...

Yeah we can sort those out afterwards. We should probably pass over
the static board specific mapping as platform_data to the pinmux device
and make it be part of struct pinctrl_dev. Then new driver instances
can have their own pctldev->mapping and we can support both platform_data
and device tree based drivers on the same system. Anyways, I'll try to
get the initial patches working with just one instance to start with
so we have something to play
with.

Regards,

Tony