Re: Pin control mappings for DT

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Linus Walleij <linus.walleij@linaro.org> [111202 01:56]:
> On Thu, Dec 1, 2011 at 11:22 PM, Tony Lindgren <tony@atomide.com> 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.

Right, but there may not be board data necessarily. With device
tree there really should not be any need for static maps. All the
necessary information can be pulled from device tree to dynamically
build the 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).

Sure, sounds like that's working fine as long as you have board
files and maps passed from board files.
 
> > 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.

Yeah I understand it's not broken right now with maps
passed from board files.

I guess I'll try to fix it up at some point to make it
behave also for device tree.
 
> > 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?

Heh just because we could.. to make development easier? :)

I think currently only pinmux_register_mappings would block
that.

Regards,

Tony
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss