On Thu, Dec 1, 2011 at 11:22 PM, Tony Lindgren [off-list ref] 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.

quoted

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