On Thu, Dec 1, 2011 at 11:22 PM, Tony Lindgren <[email protected]> wrote:
> But how does the second pinmux driver instance know if it's OK > to add to the mapping or not? The mapping exists, but it might be > also from the previous time you loaded the pinmux driver.. The mappings are not added from pinmux drivers, atleast not the in-tree drivers. Mappings are board data. The existing U300 driver only defines it's pins and groups (and these are indeed per-device) The map is defined by arch/arm/mach-u300/core.c and registered when that MACHINE_TYPE is registered. So that's why I say it's like the clkdev maps. >> That the mapping is for all devices doesn't stop you from >> loading and unloading pinmux drivers as much as you >> want, we already handle that (well there may be bugs in the >> code since it's not deployed on any system adding/removing >> controllers, but the idea sure is there...) if you're only >> using hogs and no pinmux_get() from elsewhere on it, >> it will even work in practice :-) > > Well if there are dynamic maps, we still need to release > the maps also. Hm I think I'm not grasping the concept of dynamic maps simply. The current maps are dynamic in the sense that they are registered by the board files, and can also be (with the recent patches) additively added, say if the SoC has one big chunk of common mappings and smaller chunks of per-board mappings (implemented for PXA). > How about we pass the static map in platform_data to the pinmux > driver in question, then have the pinmux driver set it up with > pinctrl fwk as per-pinctrl map. That would be a refactoring making it more like how regulators pass their consumer lists, but it's not fixing something that is broken IMO. > This would remove the need for the global map. This would > also allow making the pinctrl fwk into loadable modules > in some cases. The drivers are loadable today, but why should the pinctrl *framework* be a loadable module? Regulators and clocks are bool I don't see why the pinctrl core should be any different? Yours, Linus Walleij _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
