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