If a device have sleep and idle states in addition to the
default state, look up these in the core and stash them in
the pinctrl state container.

Add accessor functions for pinctrl consumers to put the pins
into "default", "sleep" and "idle" states passing nothing but
the struct device * affected.

Solution suggested by Kevin Hilman, Mark Brown and Dmitry
Torokhov in response to a patch series from Hebbar
Gururaja.

Cc: Hebbar Gururaja <gururaja.hebbar@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The pinctrldev_list_mutex is sinked into the functions that
actually traverse the list and lock it there. The code makes
much more sense in this way. All the callers are in
non-performance critical paths and the code is way more
readable this way.

Also refactor the function get_pinctrl_dev_from_devname() to
follow the design pattern of get_pinctrl_dev_from_of_node()
which is slightly simpler.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This obvious bug was introduced by d755910b7 ("pinctrl: move subsystem
mutex to pinctrl_dev struct").
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NPatrice Chotard <patrice.chotard@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Instead of just enabling the settings that were disabled in the 1st
loop, it's simpler to recall pinctrl_select_state with the old state.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

As Stephen Warren pointed out, pinctrl_free_setting() was called instead
of pinmux_disable_setting() on error.
In this error code, we want to call pinmux_disable_setting() where
pinmux_enable_setting() was called.
And when pinconf_apply_setting() was called, we can't do much to undo
the pin muxing (the closest thing I can think about for "unmuxing" a pin
is muxing it as GPIO input).
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In unapply_new_state, the old state is re-applied, but p->state is not
set back as it should.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

As Stephen Warren suggested, checking first if the setting->node entry
is the first in the list or not is superfluous, as it is checked again
in the list_for_each_entry bellow.
So, remove it, the code will be simpler and lighter !
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

And remove superfluous brackets.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In file included from drivers/pinctrl/core.c:30:0:
include/asm-generic/gpio.h: In function 'gpio_get_value_cansleep':
include/asm-generic/gpio.h:270:2: error: implicit declaration of
function '__gpio_get_value' [-Werror=implicit-function-declaration]
include/asm-generic/gpio.h: In function 'gpio_set_value_cansleep':
include/asm-generic/gpio.h:276:2: error: implicit declaration of
function '__gpio_set_value' [-Werror=implicit-function-declaration]
drivers/pinctrl/core.c: In function 'pinctrl_ready_for_gpio_range':
drivers/pinctrl/core.c:297:9: error: implicit declaration of function
'gpio_to_chip' [-Werror=implicit-function-declaration]
drivers/pinctrl/core.c:297:27: warning: initialization makes pointer
from integer without a cast [enabled by default]
drivers/pinctrl/core.c:304:45: error: dereferencing pointer to
incomplete type
drivers/pinctrl/core.c:305:26: error: dereferencing pointer to
incomplete type
drivers/pinctrl/core.c:305:39: error: dereferencing pointer to
incomplete type
cc1: some warnings being treated as errors
make[2]: *** [drivers/pinctrl/core.o] Error 1
make[1]: *** [drivers/pinctrl] Error 2
make[1]: *** Waiting for unfinished jobs....

It's caused by CONFIG_GPIOLIB isn't enabled for some platform. So
add the dependence on pinctrl_ready_for_gpio_range().
Signed-off-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If a new state is applied, the groups configured in the old state but
not in the new state are disabled.
If something goes wrong and the new state can't be applied, we have to
re-enable those groups.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If enabling a pin fails in pinctrl_select_state_locked(), all the
previous enabled pins have to be disabled to get back to the previous
state.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This prepares the implementation of pinctrl_select_state_locked() free code.

No functionnal change.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

pinctrl_get_device_gpio_range() only checks whether a certain GPIO pin
is in gpio range. But maybe some GPIO pins don't have back-end pinctrl
interface, it means that these pins are always configured as GPIO
function. For example, gpio159 isn't related to back-end pinctrl device
in Hi3620 while other GPIO pins are related to back-end pinctrl device.

Append pinctrl_ready_for_gpio_range() that is used to check whether
pinctrl device with GPIO range is ready. This function will be called
after pinctrl_get_device_gpio_range() fails.

If pinctrl device with GPIO range is found, it means that pinctrl device
is already launched and a certain GPIO pin just don't have back-end pinctrl
interface. Then pinctrl_request_gpio() shouldn't return -EPROBE_DEFER in
this case.
Signed-off-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

devres_release() can simplify the code, because devres_release()
will call the destructor for the resource as well as freeing
the devres data.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This update adds a debugfs interface to modify a pin configuration
for a given state in the pinctrl map. This allows to modify the
configuration for a non-active state, typically sleep state.
This configuration is not applied right away, but only when the state
will be entered.

This solution is mandated for us by HW validation: in order
to test and verify several pin configurations during sleep without
recompiling the software.
Signed-off-by: NLaurent Meunier <laurent.meunier@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

'pinctrl_release' is used only in this file. Hence make it static.

Without this patch we get the following sparse error:
drivers/pinctrl/core.c:815:6: warning:
symbol 'pinctrl_release' was not declared. Should it be static?
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.

A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.

This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:

struct pinctrl  *p;

p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
   if (PTR_ERR(p) == -EPROBE_DEFER)
        return -EPROBE_DEFER;
        dev_warn(&dev, "no pinctrl handle\n");
}

The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2

A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.

This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.

ChangeLog v4->v5 (Stephen):
- Simplified the devicecore grab code.
- Deleted a piece of documentation recommending that pins
  be mapped to a device rather than hogged.
ChangeLog v3->v4 (Linus):
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
  the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
  can merge it through the pinctrl subsystem.
ChangeLog v2->v3 (Linus):
- Abstain from using IS_ERR_OR_NULL() in the driver core,
  Russell recently sent a patch to remove it. Handle the
  NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
  core file. devm_kfree() the container on error so we don't
  waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
  <linux/kref.h> so that we don't release pinctrl handles
  that have been obtained for two or more places.
ChangeLog v1->v2 (Linus):
- Only store a pointer in the device struct, and only allocate
  this if it's really used by the device.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mitch Bradley <wmb@firmworks.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
[swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
correctly handle deferred probe. Removed admonition from docs not to use
pinctrl hogs for devices]
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add new function to get devname from pinctrl_dev. pinctrl_dev_get_name()
can only get pinctrl description name. If we want to use gpio driver to
find pinctrl device node, we need to fetch the pinctrl device name.
Signed-off-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This fix allows handling sleep mode for hogged
pins in pinctrl. It provides functions to set pins
to sleep/default configurations according to their
current state.
Signed-off-by: NJulien Delacou <julien.delacou@stericsson.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Up until now, as hogs were always taken at the end of the
pin control device registration, it didn't cause any problem.
But when starting to hog pins from the device core it will
cause deferral of the pin controller device itself since the
default pin fetch is done *before* the device probes, so
let's fix this annoyance (which is also aesthetically ugly).

Also take some care to make sure that if any one map entry
results in a deferral rather than a failure, then that
deferral will take precedence.
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This variable pertains to pinctrl handles not muxes
specifically.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This adds a function to the pinctrl core to retrieve the GPIO
range associated with a certain pin for a certain controller.
This is needed when a pinctrl driver want to look up the
corresponding struct gpio_chip for a certain pin. As the
GPIO drivers can now create these ranges themselves, the
pinctrl driver no longer knows about all its associated GPIO
chips.
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes the pinctrl_find_and_add_gpio_range() return
-EPROBE_DEFER if the range hosting pin controller cannot be
located. We may assume that the common case for why adding a
range fails is that the targe pin controller device has not
probed yet.
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Rename the function find_pinctrl_and_add_gpio_range()
to pinctrl_find_and_add_gpio_range() so as to be consistent
with the rest of the functions.
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.

As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.

After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.

[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NShiraz Hashim <shiraz.hashim@st.com>
[Edited documentation a bit]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts earlier commit which removed
pinctrl_remove_gpio_range(), because at that time there
weren't any more users of that routine. It was removed as the
removal of ranges was done in unregister of pinctrl.

But as we are now registering stuff from gpiolib, we may
remove and insert a gpio module multiple times. So, we
need this routine again.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NStephen Warren <swarren@nvidia.com>
Tested-by: NJean Nicolas Graux <jean-nicolas.graux@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add the missing unlock on the error handle path in function
pinctrl_groups_show().

Cc: stable@kernel.org
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

'pindesc' was not freed when returning from an error induced
exit path.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In function pinctrl_get_locked, pointer p is returned on
error, and also return on no_error.
So, we just return it with no error test.

It's pretty the same in function pinctrl_lookup_state_locked:
state is returned in every case, so we drop the error test
and just return state.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>

Often GPIO ranges are added in batch, so create a special
function for that.
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The gpio ranges will be automatically removed when the pinctrl
driver is unregistered.
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

lots of places the ret is used just for non zero cases
with out that also we can check the status of the function
calls.
Signed-off-by: NDevendra Naga <devendra.aaru@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The way the for_each_maps() macro is currently used, using "i" instead of
"_i_" works and is harmless. Still, this is a bug, that can trigger any
time, if the code around that macro changes. Better fix it now.
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

As pinctrl handles, it may be possible the pinctrl gpio ranges
are still not got registered when user call pinctrl_gpio_request.
Thus, add defer support for it too.
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add a interface pinctrl_provide_dummies for platform to indicate
whether it needs use pinctrl dummy state.

ChangeLog v3->v4:
* remove dummy gpio support in pinctrl subsystem.
  Let gpio driver decide whether it wants to use pinctrl gpio mux
  function.
ChangeLog v2->v3:
* Also changed the missed pinctrl gpio APIs in v1.
ChangeLog v1->v2:
* Based on sascha's suggestion, drop using kconfig since it will hide
  pinctrl errors on all other boards.
  See: https://lkml.org/lkml/2012/4/18/282
  It seemed both Linus and Stephen agreed with this way, so i'm ok
  with it too.
* Add dummy gpio support.
  pinctrl gpio in the same situation as state.
* Patch name changed.
  Original is pinctrl: handle dummy state in core.
* Split removing old dt dummy interface into a separate patch

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NJohn Crispin <blogic@openwrt.org>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

pinctrl_register_map() was returning early if pinmux_validate_map() or
pinconf_validate_map() failed, but was not actually returning the error
code.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Pin name is more useful to users.

After change, when cat pingroups in sysfs, it becomes:
root@freescale /sys/kernel/debug/pinctrl/20e0000.iomuxc$ cat pingroups
registered pin groups:
group: uart4grp-1
pin 219 (MX6Q_PAD_KEY_ROW0)
pin 218 (MX6Q_PAD_KEY_COL0)

group: usdhc4grp-1
pin 305 (MX6Q_PAD_SD4_CMD)
pin 306 (MX6Q_PAD_SD4_CLK)
pin 315 (MX6Q_PAD_SD4_DAT0)
pin 316 (MX6Q_PAD_SD4_DAT1)
pin 317 (MX6Q_PAD_SD4_DAT2)
pin 318 (MX6Q_PAD_SD4_DAT3)
pin 319 (MX6Q_PAD_SD4_DAT4)
pin 320 (MX6Q_PAD_SD4_DAT5)
pin 321 (MX6Q_PAD_SD4_DAT6)
pin 322 (MX6Q_PAD_SD4_DAT7)
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>