History log of /drivers/pinctrl/pinmux.c
Revision Date Author Comments
03e9f0cac5da6af85758276cb4624caf5911f2b9 03-Sep-2014 Linus Walleij <linus.walleij@linaro.org> pinctrl: clean up after enable refactoring

commit 2243a87d90b42eb38bc281957df3e57c712b5e56
"pinctrl: avoid duplicated calling enable_pinmux_setting for a pin"
removed the .disable callback from the struct pinmux_ops,
making the .enable() callback the only remaining callback.

However .enable() is a bad name as it seems to imply that a
muxing can also be disabled. Rename the callback to .set_mux()
and also take this opportunity to clean out any remaining
mentions of .disable() from the documentation.

Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: Fan Wu <fwu@marvell.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2243a87d90b42eb38bc281957df3e57c712b5e56 09-Jun-2014 Fan Wu <fwu@marvell.com> pinctrl: avoid duplicated calling enable_pinmux_setting for a pin

What the patch does:
1. Call pinmux_disable_setting ahead of pinmux_enable_setting
each time pinctrl_select_state is called
2. Remove the HW disable operation in pinmux_disable_setting function.
3. Remove the disable ops in struct pinmux_ops
4. Remove all the disable ops users in current code base.

Notes:
1. Great thanks for the suggestion from Linus, Tony Lindgren and
Stephen Warren and Everyone that shared comments on this patch.
2. The patch also includes comment fixes from Stephen Warren.

The reason why we do this:
1. To avoid duplicated calling of the enable_setting operation
without disabling operation inbetween which will let the pin
descriptor desc->mux_usecount increase monotonously.
2. The HW pin disable operation is not useful for any of the
existing platforms.
And this can be used to avoid the HW glitch after using the
item #1 modification.

In the following case, the issue can be reproduced:
1. There is a driver that need to switch pin state dynamically,
e.g. between "sleep" and "default" state
2. The pin setting configuration in a DTS node may be like this:

component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&a_grp_setting &c_grp_setting>;
pinctrl-1 = <&b_grp_setting &c_grp_setting>;
}

The "c_grp_setting" config node is totally identical, maybe like
following one:

c_grp_setting: c_grp_setting {
pinctrl-single,pins = <GPIO48 AF6>;
}

3. When switching the pin state in the following official pinctrl
sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();

Test Result:
1. The switch is completed as expected, that is: the device's
pin configuration is changed according to the description in the
"wanted_state" group setting
2. The "desc->mux_usecount" of the corresponding pins in "c_group"
is increased without being decreased, because the "desc" is for
each physical pin while the setting is for each setting node
in the DTS.
Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead
of enabling "c_grp_setting" in pinctrl-1, the desc->mux_usecount
will keep increasing without any chance to be decreased.

According to the comments in the original code, only the setting,
in old state but not in new state, will be "disabled" (calling
pinmux_disable_setting), which is correct logic but not intact. We
still need consider case that the setting is in both old state
and new state. We can do this in the following two ways:

1. Avoid to "enable"(calling pinmux_enable_setting) the "same pin
setting" repeatedly
2. "Disable"(calling pinmux_disable_setting) the "same pin setting",
actually two setting instances, ahead of enabling them.

Analysis:
1. The solution #2 is better because it can avoid too much
iteration.
2. If we disable all of the settings in the old state and one of
the setting(s) exist in the new state, the pins mux function
change may happen when some SoC vendors defined the
"pinctrl-single,function-off"
in their DTS file.
old_setting => disabled_setting => new_setting.
3. In the pinmux framework, when a pin state is switched, the
setting in the old state should be marked as "disabled".

Conclusion:
1. To Remove the HW disabling operation to above the glitch mentioned
above.
2. Handle the issue mentioned above by disabling all of the settings
in old state and then enable the all of the settings in new state.

Signed-off-by: Fan Wu <fwu@marvell.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
e5b3b2d9ed202697a937c282f9c4d93b1e3e0848 10-Apr-2014 Antoine Ténart <antoine.tenart@free-electrons.com> pinctrl: allows not to define the get_group_pins operation

When using a group only pinctrl driver, which does not have any
information on the pins it is useless to define a get_group_pins
always returning an empty list of pins.

When not using get_group_pin[1], a driver must implement it so
pins = NULL and num_pins = 0. This patch makes it the default
behaviour if not defined in the pinctrl driver when used in
pinmux enable and disable funtions and in pinctrl_groups_show.

It also adds a check in pinctrl_get_group_pins and return -EINVAL if
not defined. This function is called in the gpiolib when adding when
pingroup range. It cannot be used if no group is defined, so this seams
reasonable.

[1] get_group_pin(struct pinctrl_dev *pctldev,
unsigned selector,
const unsigned **pins,
unsigned *num_pins);

Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
808e657c5c709844074d47a4284c746070b0772c 29-Oct-2013 Michael Opdenacker <michael.opdenacker@free-electrons.com> pinctrl: remove minor dead code

This removes a test whether the 'desc' variable is NULL.
This possibility has already been eliminated by the
below test earlier in the loop:

if (desc == NULL) {
dev_warn(pctldev->dev,
"could not get pin desc for pin %d\n",
pins[i]);
continue;
}

Found with Coverity: CID #1090078

Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
1c8e794432c2ee752599bf114f3e8bd683674e3d 14-Aug-2013 Linus Walleij <linus.walleij@linaro.org> pinctrl: improve warning messages

Print out the affected group name on activation of pin mux
settings, and warn if you cannot free a pin that should have
been part of a certain setting.

ChangeLog v1->v2:
- Also print the pin name in the error messages.

Cc: Sonic Zhang <sonic.zhang@analog.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
744f0a9adb6a3478c9753eef56b0614ee69f969e 14-Aug-2013 Sonic Zhang <sonic.zhang@analog.com> pinctrl: pinmux: Don't free pins requested by other devices in pinmux_disable_setting.

One peripheral may share part of its pins with the 2nd
peripheral and the other pins with the 3rd. If it requests all pins
when part of them has already be requested and owned by the 2nd
peripheral, this request fails and pinmux_disable_setting() is called.
The pinmux_disable_setting() frees all pins of the first peripheral
without checking if the pin is owned by itself or the 2nd, which
results in the malfunction of the 2nd peripheral driver.

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
42fed7ba44e4e8c1fb27b28ad14490cb1daff3c7 11-Apr-2013 Patrice Chotard <patrice.chotard@st.com> pinctrl: move subsystem mutex to pinctrl_dev struct

This mutex avoids deadlock in case of use of multiple pin
controllers. Before this modification, by using a global
mutex, deadlock appeared when, for example, a call to
pinctrl_pins_show() locked the pinctrl_mutex, called the
ops->pin_dbg_show of a particular pin controller. If this
pin controller needs I2C access to retrieve configuration
information and I2C driver is using pinctrl to drive its
pins, a call to pinctrl_select_state() try to lock again
pinctrl_mutex which leads to a deadlock.

Notice that the mutex grab from the two direction functions
was moved into pinctrl_gpio_direction().

For several cases, we can't replace pinctrl_mutex by
pctldev->mutex, because at this stage, pctldev is
not accessible :
- pinctrl_get()/pinctrl_put()
- pinctrl_register_maps()

So add respectively pinctrl_list_mutex and
pinctrl_maps_mutex in order to protect
pinctrl_list and pinctrl_maps list instead.

Reintroduce pinctrldev_list_mutex in
find_pinctrl_by_of_node(),
pinctrl_find_and_add_gpio_range()
pinctrl_request_gpio(), pinctrl_free_gpio(),
pinctrl_gpio_direction(), pinctrl_devices_show(),
pinctrl_register() and pinctrl_unregister() to
protect pinctrldev_list.

Changes v2->v3:
- Fix a missing EXPORT_SYMBOL_GPL() for pinctrl_select_state().

Changes v1->v2:
- pinctrl_select_state_locked() is removed, all lock mechanism
is located inside pinctrl_select_state(). When parsing
the state->setting list, take the per-pin-controller driver
lock. (Patrice).
- Introduce pinctrldev_list_mutex to protect pinctrldev_list
in all functions which parse or modify pictrldev_list.
(Patrice).
- move find_pinctrl_by_of_node() from pinctrl/devicetree.c to
pinctrl/core.c in order to protect pinctrldev_list.
(Patrice).
- Sink mutex:es into some functions and remove some _locked
variants down to where the lists are actually accessed to
make things simpler. (Linus)
- Drop *all* mutexes completely from pinctrl_lookup_state()
and pinctrl_select_state() - no relevant mutex was taken
and it was unclear what this was protecting against. (Linus)

Reported by : Seraphin Bonnaffe <seraphin.bonnaffe@stericsson.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
740924a267e85de09707ea158bbf594b4d8bae01 21-Mar-2013 Richard Genoud <richard.genoud@gmail.com> pinmux: forbid mux_usecount to be set at UINT_MAX

If pin_free is called on a pin already freed, mux_usecount is set to
UINT_MAX which is really a bad idea.

This will issue a warning, so that we can correct the code responsible
for the double free.

Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
e38d457de7be63e6ced1ea254aa51466deb1fef0 10-Nov-2012 Axel Lin <axel.lin@ingics.com> pinctrl: pinmux: Release all taken pins in pinmux_enable_setting error paths

Currently pinmux_enable_setting does not release all taken pins if
ops->enable() returns error. This patch ensures all taken pins are
released in any error paths.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
1a78958dc212f3698fdc543857af80155cb30f7f 17-Oct-2012 Linus Walleij <linus.walleij@linaro.org> pinctrl: reserve pins when states are activated

This switches the way that pins are reserved for multiplexing:

We used to do this when the map was parsed, at the creation of
the settings inside the pinctrl handle, in pinmux_map_to_setting().

However this does not work for us, because we want to use the
same set of pins with different devices at different times: the
current code assumes that the pin groups in a pinmux state will
only be used with one single device, albeit different groups can
be active at different times. For example if a single I2C driver
block is used to drive two different busses located on two
pin groups A and B, then the pins for all possible states of a
function are reserved when fetching the pinctrl handle: the
I2C bus can choose either set A or set B by a mux state at
runtime, but all pins in both group A and B (the superset) are
effectively reserved for that I2C function and mapped to the
device. Another device can never get in and use the pins in
group A, even if the device/function is using group B at the
moment.

Instead: let use reserve the pins when the state is activated
and drop them when the state is disabled, i.e. when we move to
another state. This way different devices/functions can use the
same pins at different times.

We know that this is an odd way of doing things, but we really
need to switch e.g. an SD-card slot to become a tracing output
sink at runtime: we plug in a special "tracing card" then mux
the pins that used to be an SD slot around to the tracing
unit and push out tracing data there instead of SD-card
traffic.

As a side effect pinmux_free_setting() is unused but the stubs
are kept for future additions of code.

Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Loic Pallardy <loic.pallardy@st.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Jean Nicolas Graux <jean-nicolas.graux@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
23a895aee6081c144ffcc61eaf52dc62e10b3bd1 13-Sep-2012 Thomas Petazzoni <thomas.petazzoni@free-electrons.com> pinctrl: use kasprintf() in pinmux_request_gpio()

Instead of using a temporary buffer, snprintf() and kstrdup(), just
use kasprintf() that does the same thing in just oneline.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Colin Cross <ccross@google.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
02b50ce4cb1b6aff7d9f1c0c5b4ceb44107bacb4 14-May-2012 Dong Aisheng <dong.aisheng@linaro.org> pinctrl: make pinmux disable function optional

Some SoCs may not have pinmux disable function in HW.

Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
d4705316c18d371eb404d0ae5dcf51ce6e341d0f 01-May-2012 Stephen Warren <swarren@nvidia.com> pinctrl: add more info to error msgs in pin_request

Additionally print which pin the request failed for, which entity already
claimed it, and what entity was trying to claim it.

Remove duplicate device name from a debug message.

Clean up some indentation.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ad6e1107baa2e7fda55c2020c25127eab9c0122b 26-Apr-2012 John Crispin <blogic@openwrt.org> pinctrl: enhance reporting of errors when loading from DT

There are a few places in the api where the code simply returns -EINVAL when
it finds an error. An example is pinmux_map_to_setting() which now reports an
error if we try to match a group with a function that it does not support.

The reporting of errors in pinconf_check_ops and pinmux_check_ops now has the
same style and is located inside the according functions and not the calling
code.

When the map is found in the DT but the default state can not be selected we
get an error to know that the code at least tried.

The patch also removes a stray word from one comment and a "->" from another
for the sake of consistency.

Finally we replace a few pr_err/debug() calls with dev_err/dbg().

Thanks go to Stephen Warren for reviewing the patch and enhancing the reporting
inside pinmux_map_to_setting().

Signed-off-by: John Crispin <blogic@openwrt.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
15f70e1b9a1a6351c252cb8892272cc4601818c7 23-Apr-2012 John Crispin <blogic@openwrt.org> pinctrl: fix signed vs unsigned conditionals inside pinmux_map_to_setting

pinmux_map_to_setting() uses setting->data.mux.func/group to store the return
code of pinmux_func_name_to_selector/pinctrl_get_group_selector(). However,
struct pinctrl_setting_mux defines these elements as unsigned, resulting in all
error codes getting lost. The conditionals following the assignments will always
evaluate to false thus breaking the error paths.

This bug can be triggered by loading a pinmux group map from the devicetree
with an invalid function/group string.

Signed-off-by: John Crispin <blogic@openwrt.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
d0bd8df56ebffe4a5ca42e27aca2a1243c70ed53 17-Apr-2012 Dong Aisheng <dong.aisheng@linaro.org> pinctrl: show pin name when request pins

Pin name is more useful to users.

Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ad8bb720c23a80233e45ed31d67458f5e5b7ab31 09-Apr-2012 Dong Aisheng <dong.aisheng@linaro.org> pinctrl: add some error checking for user interfaces

This patch can avoid kernel oops in case the mux or config
function is not supported by driver.

Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
a1d31f71e6ed2f714830df8885ec07dfe1f6632e 06-Apr-2012 Dong Aisheng <dong.aisheng@linaro.org> pinctrl: fix pinmux_check_ops error checking

Do not use get_functions_count before checking.

Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
d1e90e9e7467dbfe521b25ba79f520bf676ebc36 30-Mar-2012 Viresh Kumar <viresh.kumar@st.com> pinctrl: replace list_*() with get_*_count()

Most of the SoC drivers implement list_groups() and list_functions()
routines for pinctrl and pinmux. These routines continue returning
zero until the selector argument is greater than total count of
available groups or functions.

This patch replaces these list_*() routines with get_*_count()
routines, which returns the number of available selection for SoC
driver. pinctrl layer will use this value to check the range it can
choose.

This patch fixes all user drivers for this change. There are other
routines in user drivers, which have checks to check validity of
selector passed to them. It is also no more required and hence
removed.

Documentation updated as well.

Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
[Folded in fix and fixed a minor merge artifact manually]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
652162d469a73450a66b6c8049b16c2b7828fa24 06-Mar-2012 Stephen Warren <swarren@nvidia.com> pinctrl: allow concurrent gpio and mux function ownership of pins

Per recent updates to Documentation/gpio.txt, gpiolib drivers should
inform pinctrl when a GPIO is requested. pinctrl then marks that pin as
in-use for that GPIO function.

When an SoC muxes pins in a group, it's quite possible for the group to
contain e.g. 6 pins, but only 4 of them actually be needed by the HW
module that's mux'd to them. In this case, the other 2 pins could be
used as GPIOs. However, pinctrl marks all the pins within the group as
in-use by the selected mux function. To allow the expected gpiolib
interaction, separate the concepts of pin ownership into two parts: One
for the mux function and one for GPIO usage. Finally, allow those two
ownerships to exist in parallel.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ba110d90c08d9676370db9a62792f57ade5b3bbf 02-Mar-2012 Stephen Warren <swarren@nvidia.com> pinctrl: Show selected function and group in pinmux-pins debugfs

Until recently, the pinctrl pinmux-pins debugfs file displayed the
selected function for each owned pin. This feature was removed during
restructing in support of recent API rework. This change restoreds this
feature, and also displays the group that the function was selected on,
in case a pin is a member of multiple groups.

Based on work by: Linus Walleij <linus.walleij@linaro.org>

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
1e2082b520721734c358f776d34a069867214c8e 02-Mar-2012 Stephen Warren <swarren@nvidia.com> pinctrl: enhance mapping table to support pin config operations

The pinctrl mapping table can now contain entries to:
* Set the mux function of a pin group
* Apply a set of pin config options to a pin or a group

This allows pinctrl_select_state() to apply pin configs settings as well
as mux settings.

v3: Fix find_pinctrl() to iterate over the correct list.
s/_MUX_CONFIGS_/_CONFIGS_/ in mapping table macros.
Fix documentation to use correct mapping table macro.
v2: Added numerous extra PIN_MAP_*() special-case macros.
Fixed kerneldoc typo. Delete pinctrl_get_pin_id() and
replace it with pin_get_from_name(). Various minor fixes.
Updates due to rebase.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
0e3db173e2b9fd3b82246516e72c17763eb5f98d 02-Mar-2012 Stephen Warren <swarren@nvidia.com> pinctrl: add usecount to pins for muxing

Multiple mapping table entries could reference the same pin, and hence
"own" it. This would be unusual now that pinctrl_get() represents a single
state for a client device, but in the future when it represents all known
states for a device, this is quite likely. Implement reference counting
for pin ownership to handle this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
7ecdb16fe63e5b356335ebdc236adfb48cef31e1 02-Mar-2012 Stephen Warren <swarren@nvidia.com> pinctrl: refactor struct pinctrl handling in core.c vs pinmux.c

This change separates two aspects of struct pinctrl:

a) The data representation of the parsed mapping table, into:

1) The top-level struct pinctrl object, a single entity returned
by pinctrl_get().

2) The parsed version of each mapping table entry, struct
pinctrl_setting, of which there is one per mapping table entry.

b) The code that handles this; the code for (1) above is in core.c, and
the code to parse/execute each entry in (2) above is in pinmux.c, while
the iteration over multiple settings is lifted to core.c.

This will allow the following future changes:

1) pinctrl_get() API rework, so that struct pinctrl represents all states
for the device, and the device can select between them without calling
put()/get() again.

2) To support that, a struct pinctrl_state object will be inserted into
the data model between the struct pinctrl and struct pinctrl_setting.

3) The mapping table will be extended to allow specification of pin config
settings too. To support this, struct pinctrl_setting will be enhanced
to store either mux settings or config settings, and functions will be
added to pinconf.c to parse/execute pin configuration settings.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
57b676f9c1b7cd84397fe5a86c9bd2788ac4bd32 02-Mar-2012 Stephen Warren <swarren@nvidia.com> pinctrl: fix and simplify locking

There are many problems with the current pinctrl locking:

struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.

Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.

There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.

As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.

However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.

The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.

This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
d4e3198736d9d64e4ba4d2b46ab75cbcf5d0a4e0 02-Mar-2012 Stephen Warren <swarren@nvidia.com> pinctrl: enhance pinctrl_get() to handle multiple functions

At present, pinctrl_get() assumes that all matching mapping table entries
have the same "function" value, albeit potentially applied to different
pins/groups.

This change removes this restriction; pinctrl_get() can now handle a set
of mapping tables where different functions are applied to the various
pins/groups.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
1cf94c45ca31c0ad563e72b095782346cba26b6c 24-Feb-2012 Linus Walleij <linus.walleij@linaro.org> pinctrl: make the pinmux-pins more helpful

The debugfs file pinmux-pins used to tell which function was
enabled but now states simply which device owns the pin. Being
owned by the pinctrl driver itself means just that it's hogged
so be a bit more helpful by printing that.

ChangeLog v1->v2:
- Preserve the self-referential owner field, just clarify that
when the pin controller states itself as owner this means
that it's hogged.

Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
02f5b98951c631a3c4b3cc398dd2b14d274a6155 22-Feb-2012 Stephen Warren <swarren@nvidia.com> pinctrl: allocate sizeof(*p) instead of sizeof(struct foo)

This hopefully makes it harder to take the sizeof the wrong type.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
3cc70ed32cd6c5cb57de17bde615148ed7eda88f 20-Feb-2012 Stephen Warren <swarren@nvidia.com> pinctrl: record a pin owner, not mux function, when requesting pins

When pins are requested/acquired/got, some device becomes the owner of
their mux setting. At this point, it isn't certain which mux function
will be selected for the pin, since this may vary between each of the
device's states in the pinctrl mapping table. As such, we should record
the owning device, not what we think the initial mux setting will be,
when requesting pins.

This doesn't make a lot of difference right now since pinctrl_get gets
only one single device/state combination, but this will make a difference
when pinctrl_get gets all states, and pinctrl_select_state can switch
between states.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
03665e0f248d6b7542f72cd7c4ec521109f283c7 20-Feb-2012 Stephen Warren <swarren@nvidia.com> pinctrl: Re-order pinmux.[ch] to match each-other

Modify the two files so that the order of function prototypes in the
header matches the order of implementations in the .c file.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
8b9c139f166cd55d76728a5910fa862a4e16e833 20-Feb-2012 Stephen Warren <swarren@nvidia.com> pinctrl: use list_add_tail instead of list_add

This mostly makes debugfs files print things in the order that they
were added or acquired, which just feels a little more consistent.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
befe5bdfbb698b3bc57c58d0bd7ca3391c9275ed 09-Feb-2012 Linus Walleij <linus.walleij@linaro.org> pinctrl: factor pin control handles over to the core

This moves the per-devices struct pinctrl handles and device map
over from the pinmux part of the subsystem to the core pinctrl part.
This makes the device handles core infrastructure with the goal of
using these handles also for pin configuration, so that device
drivers (or boards etc) will need one and only one handle to the
pin control core.

Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
e93bcee00c43e2bd4037291262111016f4c05793 09-Feb-2012 Linus Walleij <linus.walleij@linaro.org> pinctrl: move generic functions to the pinctrl_ namespace

Since we want to use the former pinmux handles and mapping tables for
generic control involving both muxing and configuration we begin
refactoring by renaming them from pinmux_* to pinctrl_*.

ChangeLog v1->v2:
- Also rename the PINMUX_* macros in machine.h to PIN_ as indicated
in the documentation so as to reflect the generic nature of these
mapping entries from now on.

Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
9dfac4fd7f8cdcdf734dff2ccc7ca467f53f1cfd 01-Feb-2012 Linus Walleij <linus.walleij@linaro.org> pinctrl: delete raw device pointers in pinmux maps

After discussion with Mark Brown in an unrelated thread about
ADC lookups, it came to my knowledge that the ability to pass
a struct device * in the regulator consumers is just a
historical artifact, and not really recommended. Since there
are no in-kernel users of these pointers, we just kill them
right now, before someone starts to use them.

Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
b9130b776ee481acbc27a7e56d98df75680de369 25-Jan-2012 Tony Lindgren <tony@atomide.com> pinctrl: add checks for empty function names

This is needed as otherwise we can get the following when
dealing with buggy data in a pinmux driver for
pinmux_search_function:

Unable to handle kernel NULL pointer dereference at virtual
address 00000000
...
PC is at strcmp+0xc/0x34
LR is at pinmux_get+0x350/0x8f4
...

As we need pctldev initialized to call ops->list_functions,
let's initialize it before check_ops calls and pass the
pctldev to the check_ops functions. Do this for both pinmux
and pinconf check_ops functions.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
9e2551e10b5c7ba550849bd9ed519e498cc30e68 20-Jan-2012 Tony Lindgren <tony@atomide.com> pinctrl: fix pinmux_hog_maps when ctrl_dev_name is not set

The ctrl_dev_name is optional for struct pinmux_map assuming
that ctrl_dev is set. Without this patch we can get:

Unable to handle kernel NULL pointer dereference at virtual
address 00000000
...
(pinmux_hog_maps+0xa4/0x20c)
(pinctrl_register+0x2a4/0x378)
...

Fix this by adding adding a test for map->ctrl_dev.
Additionally move the test for map->ctrl_dev earlier
to optimize out the loop a bit.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
de849eecd0addaa6bf60f2f7be36b30abf9ff2ae 20-Jan-2012 Tony Lindgren <tony@atomide.com> pinctrl: fix some pinmux typos

Fix some pinmux typos so implementing pinmux drivers
is a bit easier.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
f9d41d7cb5a3a4fe9585d47e518d779d2aef8c94 19-Jan-2012 Uwe Kleine-König <u.kleine-koenig@pengutronix.de> pinctrl: unbreak error messages

It's better to not line break error messages to allow easier grepping
for them even when the line gets >80 chars. Additionally some minor
reformating is done.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
706e8520e8450a631ca6f798f8c811faf56f0a59 03-Jan-2012 Chanho Park <chanho61.park@samsung.com> pinctrl: correct a offset while enumerating pins

This patch modifies a offset while enumerating pins to support a
partial pin space. If we use a pin number for enumerating pins,
the pin space always starts with zero base. Indeed, we always check
the pin is in the pin space. An extreme example, there is only two pins.
One is 0. Another is 1000. We always enumerate whole offsets until 1000.
For solving this problem, we use the offset of the pin array instead
of the zero-based pin number.

Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
[Restored sparse pin space comment]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
e6337c3c96a7ee5cfd5e7afed825f894d4576f58 20-Dec-2011 Dong Aisheng <dong.aisheng@linaro.org> pinctrl: some typo fixes

Minor copyedits.

Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
51cd24ee625c348654114032499914d0311e5832 10-Dec-2011 Stephen Warren <swarren@nvidia.com> pinctrl: don't create a device for each pin controller

Pin controllers should already be instantiated as a device, so there's
no need for the pinctrl core to create a new struct device for each
controller.

This allows the controller's real name to be used in the mux mapping
table, rather than e.g. "pinctrl.0", "pinctrl.1", etc.

This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since
their sole purpose was to hard-code the .ctrl_dev_name field to be
"pinctrl.0".

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
59b099b04981917ee7fbd88b6f50eeaffc9f33cd 30-Nov-2011 Linus Walleij <linus.walleij@linaro.org> pinctrl: make it possible to add multiple maps

Since we now anyway make a copy of the platform-supplied pinmux
map, we can just as well make it possible to call the function
adding maps several times, so as to simplify cases (as PXA) where
several sets of disparate mappings need to be added depending on
target platform.

Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Acked-by: Arnd Bergmann <arnd@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
97607d157c133ab18dfcd77fa836e37fa950a44a 29-Nov-2011 Linus Walleij <linus.walleij@linaro.org> pinctrl: make a copy of pinmux map

This makes a deep copy of the pinmux function map instead of
keeping the copy supplied from the platform around. This makes
it possible to tag the platforms map with __initdata as is also
done as part of this patch.

Rationale: a certain target platform (PXA) has numerous
pinmux maps, many of which will be lying around unused after
boot in a multi-platform binary. Instead, deep-copy the one
we're going to use and tag them all __initdata so they go away
after boot.

ChangeLog v1->v2:
- Fixup the deep copy, missed a few items on the struct,
plus mark bool member non-const since we're making runtime
copies if this stuff now.
ChangeLog v2->v3:
- Make a shallow copy (just copy the array of map structs)
as Arnd noticed, string constants never get discarded by the
kernel anyway, so these pointers may be safely copied over.

Reviewed-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
542e704f3ffee1dc4539c9e8191e4dc215220f5e 14-Nov-2011 Linus Walleij <linus.walleij@linaro.org> pinctrl: GPIO direction support for muxing

When requesting a single GPIO pin to be muxed in, some controllers
will need to poke a different value into the control register
depending on whether the pin will be used for GPIO output or GPIO
input. So create pinmux counterparts to gpio_direction_[input|output]
in the pinctrl framework.

ChangeLog v1->v2:
- This also amends the documentation to make it clear the this
function and associated machinery is *ONLY* intended as a backend
to gpiolib machinery, not for everyone and his dog to start playing
around with pins.
ChangeLog v2->v3:
- Don't pass an argument to the common request function, instead
provide pinmux_* counterparts to the gpio_direction_[input|output]
calls, simpler and anyone can understand it.
ChangeLog v3->v4:
- Fix numerous spelling mistakes and dangling text in documentation.
Add Ack and Rewewed-by.

Cc: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
3c739ad0df5eb41cd7adad879eda6aa09879eb76 11-Nov-2011 Chanho Park <chanho61.park@samsung.com> pinctrl: add a pin_base for sparse gpio-ranges

This patch enables mapping a base offset of gpio ranges with
a pin offset even if does'nt matched. A base of pinctrl_gpio_range
means a base offset of gpio. However, we cannot convert gpio to pin
number for sparse gpio ranges just only using a gpio base offset.
We can convert a gpio to real pin number(even if not matched) using
a new pin_base which means a base pin offset of requested gpio range.
Now, the pin control subsystem passes the pin base offset to the
pinmux driver.

For example, let's assume below two gpio ranges in the system.

static struct pinctrl_gpio_range gpio_range_a = {
.name = "chip a",
.id = 0,
.base = 32,
.pin_base = 32,
.npins = 16,
.gc = &chip_a;
};

static struct pinctrl_gpio_range gpio_range_b = {
.name = "chip b",
.id = 0,
.base = 48,
.pin_base = 64,
.npins = 8,
.gc = &chip_b;
};

We can calucalate a exact pin ranges even if doesn't matched with gpio ranges.

chip a:
gpio-range : [32 .. 47]
pin-range : [32 .. 47]
chip b:
gpio-range : [48 .. 55]
pin-range : [64 .. 71]

Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
336cdba09a5df706402628fb20b7660d186aff6c 10-Nov-2011 Linus Walleij <linus.walleij@linaro.org> pinctrl: documentation update

Update the docs removing an obsolete __refdata tag and document
the mysterious return value of pin_free(). And fixes up some various
confusions in the pinctrl documentation.

Reported-by: Rajendra Nayak <rnayak@ti.com>
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Reported-by: Thomas Abraham <thomas.abraham@linaro.org>
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
3712a3c488987849613a4ad74129e67e40b12b38 21-Oct-2011 Stephen Warren <swarren@nvidia.com> pinctrl: add explicit gpio_disable_free pinmux_op

Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
completely different manner than they select which function to mux out of
that pin. In order to support a single "free" pinmux_op, the driver would
need to maintain a per-pin state of requested-for-gpio vs. requested-for-
function. However, that's a lot of work when the core already has explicit
separate paths for gpio request/free and function request/free.

So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free()
call it when appropriate.

When doing this, I noticed that when calling pin_request():

!!gpio == (gpio_range != NULL)

... and so I collapsed those two parameters in both pin_request(), and
when adding writing the new code in pin_free().

Also, for pin_free():

!!free_func == (gpio_range != NULL)

However, I didn't want pin_free() to know about the GPIO function naming
special case, so instead, I reworked pin_free() to always return the pin's
previously requested function, and now pinmux_free_gpio() calls
kfree(function). This is much more balanced with the allocation having
been performed in pinmux_request_gpio().

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
d2f6a1c6fb0e510a24ccac066eefbcfd0c932858 26-Oct-2011 Marek Belisko <marek.belisko@open-nandra.com> pinctrl: remove double pin validity check.

Function pin_is_valid just call pin_desc_get which is in pin_request
call some line below. Remove pin_is_valid() check.

Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
7afde8baa83b9ac409a6db86f27a41878aa6b33f 19-Oct-2011 Linus Walleij <linus.walleij@linaro.org> pinctrl: move group lookup to core

Now also the core needs to look up pin groups so move the lookup
function there and expose it in the internal header.

Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
cc96ffbb744bff2826aa9e62b14bb599b1f15fc3 08-Dec-2011 Uwe Kleine-König <u.kleine-koenig@pengutronix.de> pinctrl: remove two unused global variables

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
5d2eaf8090874f8e65388e82f7e91f9cef74885e 20-Oct-2011 Stephen Warren <swarren@nvidia.com> pinctrl: Don't copy function name when requesting a pin

Instead, store a pointer to the currently assigned function.

This allows us to delete the mux_requested variable from pin_desc; a pin
is requested if its currently assigned function is non-NULL.

When a pin is requested as a GPIO rather than a regular function, the
assigned function name is dynamically constructed. In this case, we have
to kstrdup() the dynamically constructed name, so that mux_function doesn't
pointed at stack data. This requires pin_free to be told whether to free
the mux_function pointer or not.

This removes the hard-coded maximum function name length.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
a5818a8bd095a08cfb1871b63af9c8bed103e4b9 20-Oct-2011 Stephen Warren <swarren@nvidia.com> pinctrl: get_group_pins() const fixes

get_group_pins() "returns" a pointer to an array of const objects, through
a pointer parameter. Fix the prototype so what's pointed at by the returned
pointer is const, rather than the function parameter being const.

This also allows the removal of a cast in each of the two current pinmux
drivers.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2744e8afb3b76343e7eb8197e8b3e085036010a5 02-May-2011 Linus Walleij <linus.walleij@linaro.org> drivers: create a pin control subsystem

This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.

Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.

The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.

This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.

ChangeLog v1->v2:

- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver

ChangeLog v2->v3:

- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.

ChangeLog v3->v4:

- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).

ChangeLog v4->v5:

- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)

ChangeLog v5->v6:

- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.

ChangeLog v6->v7:

- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.

ChangeLog v7->v8:

- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()

ChangeLog v8->v9:

- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters

ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.

Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>