27 Oct, 2015
1 commit
-
For pinctrl the "default" state is applied to pins before the driver's
probe function is called. This is normally a sensible thing to do,
but in some cases can cause problems. That's because the pins will
change state before the driver is given a chance to program how those
pins should behave.As an example you might have a regulator that is controlled by a PWM
(output high = high voltage, output low = low voltage). The firmware
might leave this pin as driven high. If we allow the driver core to
reconfigure this pin as a PWM pin before the PWM's probe function runs
then you might end up running at too low of a voltage while we probe.Let's introudce a new "init" state. If this is defined we'll set
pinctrl to this state before probe and then "default" after probe
(unless the driver explicitly changed states already).An alternative idea that was thought of was to use the pre-existing
"sleep" or "idle" states and add a boolean property that we should
start in that mode. This was not done because the "init" state is
needed for correctness and those other states are only present (and
only transitioned in to and out of) when (optional) power management
is enabled.Changes in v3:
- Moved declarations to pinctrl/devinfo.h
- Fixed author/SoBChanges in v2:
- Added comment to pinctrl_init_done() as per Linus W.Signed-off-by: Douglas Anderson
Acked-by: Greg Kroah-Hartman
Tested-by: Caesar Wang
Signed-off-by: Linus Walleij
03 Oct, 2015
1 commit
-
Currently, the dt_params array in drivers/pinctrl/pinconf-generic.c
is not sorted in the same order as the enum pin_config_param in
include/linux/pinctrl/pinconf-generic.h.Sort enum pin_config_param, conf_items, dt_params, alphabetically
for consistency.Signed-off-by: Masahiro Yamada
Signed-off-by: Linus Walleij
01 Jun, 2015
2 commits
-
Only this member, pins, is defined as "struct ... const *", but the
others in this struct, pinlops, pmxops, confops, etc. are defined as
"const struct ... *".Swap the "struct pinctrl_pin_desc" and "const" for consistency.
Signed-off-by: Masahiro Yamada
Signed-off-by: Linus Walleij -
This "const" claims the get_function_groups callback never
changes the given num_groups pointer. It is always true
in C language, so not worth mentioning.Signed-off-by: Masahiro Yamada
Signed-off-by: Linus Walleij
06 May, 2015
3 commits
-
Inspired by scripts/coccinelle/api/err_cast.cocci
Signed-off-by: Fabian Frederick
Signed-off-by: Linus Walleij -
While the pinmux_ops are ideally just a vtable for pin mux
calls, the "strict" setting belongs so intuitively with the
pin multiplexing that we should move it here anyway. Putting
it in the top pinctrl_desc makes no sense.Cc: Sonic Zhang
Signed-off-by: Linus Walleij -
Disallow simultaneous use of the the GPIO and peripheral mux
functions by setting a flag "strict" in struct pinctrl_desc.The blackfin pinmux and gpio controller doesn't allow user to
set up a pin for both GPIO and peripheral function. So, add flag
strict in struct pinctrl_desc to check both gpio_owner and
mux_owner before approving the pin request.v2-changes:
- if strict flag is set, check gpio_owner and mux_onwer in if and
else clausev3-changes:
- add kerneldoc for this struct
- augment Documentation/pinctrl.txtSigned-off-by: Sonic Zhang
Signed-off-by: Linus Walleij
05 Mar, 2015
1 commit
-
This reverts commit 5a7d2efdd93f6c4bb6cd3d5df3d2f5611c9b87ac.
As per discussion on the mailing list, this is not the right
thing to do. NULL cookies are valid in the stubs.Reported-by: Wolfram Sang
Signed-off-by: Linus Walleij
14 Jan, 2015
2 commits
-
These functions are supposed to return an error pointer, not NULL.
Signed-off-by: Wolfram Sang
Signed-off-by: Linus Walleij -
New pin controllers such as ACPI-based may also have custom properties
to parse, and should be able to use generic pin config. Let's make the
code compile on !OF systems and rename members a bit to underscore it
is custom parameters and not necessarily DT parameters.This fixes a build regression for x86_64 on the zeroday kernel builds.
Reported-by: kbuild test robot
Reviewed-and-tested-by: Soren Brinkmann
Signed-off-by: Linus Walleij
12 Jan, 2015
2 commits
-
Additionally to the generic DT parameters, allow drivers to provide
driver-specific DT parameters to be used with the generic parser
infrastructure.To achieve this 'struct pinctrl_desc' is extended to pass custom pinconf
option to the core. In order to pass this kind of information, the
related data structures - 'struct pinconf_generic_dt_params',
'pin_config_item' - are moved from pinconf internals to the
pinconf-generic header.Additionally pinconfg-generic is refactored to not only iterate over the
generic pinconf parameters but also take the parameters into account
that are provided through the driver's 'struct pinctrl_desc'.
In particular 'pinconf_generic_parse_dt_config()' and
'pinconf_generic_dump' helpers are split into two parts each. In order
to have a more generic helper that can be used to process the generic
parameters as well as the driver-specific ones.v2:
- fix typo
- add missing documentation for @conf_items member in struct
- rebase to pinctrl/devel: conflict in abx500
- rename _pinconf_generic_dump() to pinconf_generic_dump_one()
- removed '_' from _parse_dt_cfg()
- removed BUG_ONs, error condition is handled in if statements
- removed pinconf_generic_dump_group() & pinconf_generic_dump_pin
helpers
- fixed up corresponding call sites
- renamed pinconf_generic_dump() to pinconf_generic_dump_pins()
- added kernel-doc to pinconf_generic_dump_pins()
- add kernel-doc
- more verbose commit messageSigned-off-by: Soren Brinkmann
Tested-by: Andreas Färber
Signed-off-by: Linus Walleij -
With the new 'groups' property, the DT parser can infer the map type
from the fact whether 'pins' or 'groups' is used to specify the pin
group to work on.To maintain backwards compatibitliy with current usage of the DT
binding, this is only done when PIN_MAP_TYPE_INVALID is passed to the
parsing function as type.Also, a new helper 'pinconf_generic_dt_node_to_map_all()' is introduced,
which can be used by drivers as generic callback for dt_node_to_map() to
leverage the new feature.Changes since v2:
- rename dt_pin_specifier to subnode_target_type
- add additional comment in header file explaining passing an invalid
map type
- mention map_all() helper in commit message
Changes since RFC v2:
- noneSigned-off-by: Soren Brinkmann
Tested-by: Andreas Färber
Signed-off-by: Linus Walleij
05 Sep, 2014
1 commit
-
PIN_CONFIG_DRIVE_OPEN_SOURCE enables open source, not open drain.
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Linus Walleij
04 Sep, 2014
1 commit
-
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
Acked-by: Bjorn Andersson
Acked-by: Fan Wu
Signed-off-by: Linus Walleij
11 Jul, 2014
1 commit
-
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 = ;
pinctrl-1 = ;
}The "c_grp_setting" config node is totally identical, maybe like
following one:c_grp_setting: c_grp_setting {
pinctrl-single,pins = ;
}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
Acked-by: Stephen Warren
Acked-by: Patrice Chotard
Acked-by: Heiko Stuebner
Acked-by: Maxime Coquelin
Signed-off-by: Linus Walleij
16 Jan, 2014
1 commit
-
drv_data is added to the pinctrl_pin_desc for drivers to define additional
driver-specific per-pin data.Signed-off-by: Sherman Yin
Reviewed-by: Christian Daudt
Reviewed-by: Matt Porter
Signed-off-by: Linus Walleij
16 Dec, 2013
1 commit
-
This commit adds slew-rate and input-enable/disable support for pinconf
-generic.Signed-off-by: Sherman Yin
Signed-off-by: Linus Walleij
03 Dec, 2013
1 commit
-
The PIN_CONFIG_OUTPUT parameter is really tricky to understand
and needs an explicit pointer to the documentation.Cc: Tomasz Figa
Cc: Kyungmin Park
Signed-off-by: Linus Walleij
16 Oct, 2013
1 commit
-
This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.Signed-off-by: Christian Ruppert
Signed-off-by: Linus Walleij
28 Aug, 2013
1 commit
-
When setting pin configuration in the pinctrl framework, pin_config_set() or
pin_config_group_set() is called in a loop to set one configuration at a time
for the specified pin or group.This patch 1) removes the loop and 2) changes the API to pass the whole pin
config array to the driver. It is now up to the driver to loop through the
configs. This allows the driver to potentially combine configs and reduce the
number of writes to pin config registers.All c files changed have been build-tested to verify the change compiles and
that the corresponding .o is successfully generated.Signed-off-by: Sherman Yin
Reviewed-by: Christian Daudt
Reviewed-by: Matt Porter
Tested-by: Stephen Warren
Acked-by: Laurent Pinchart
Signed-off-by: Linus Walleij
23 Aug, 2013
1 commit
-
Add support to pass the config type like GROUP or PIN when using
the utils or generic pin configuration APIs. This will make the
APIs more generic.Added additional inline APIs such that it can be use directly as
callback for the pinctrl_ops.Changes from V1:
- Remove separate implementation for pins and group for
pinctrl_utils_dt_free_map and improve this function
to support both i.e. PINS and GROUPs.Signed-off-by: Laxman Dewangan
Reviewed-by: Stephen Warren
Tested-by: Stephen Warren
Signed-off-by: Linus Walleij
16 Aug, 2013
1 commit
-
Commit e81c8f18afc4fdd6e34d8c83814b8b5134dbb30f
"pinctrl: pinconf-generic: add generic APIs for mapping pinctrl node"
Added function prototypes with implicit dependencies
on other header files causing build warnings like this:In file included from
arch/arm/mach-ux500/board-mop500-pins.c:12:0:
include/linux/pinctrl/pinconf-generic.h:142:3:
warning: 'struct device_node' declared inside parameter list [enabled
by default]
unsigned *reserved_maps, unsigned *num_maps);
^
include/linux/pinctrl/pinconf-generic.h:142:3:
warning: its scope is only this definition or declaration, which is
probably not what you want [enabled by default]
include/linux/pinctrl/pinconf-generic.h:142:3:
warning: 'struct pinctrl_dev' declared inside parameter list [enabled
by default]
include/linux/pinctrl/pinconf-generic.h:145:3:
warning: 'struct device_node' declared inside parameter list [enabled
by default]
unsigned *num_maps);
^
Let's just add ifdefs for non-DT systems (the actual code is
already ifdefed) and #include to get the
most important structs and forward-declare the pinctrl
core structs.Reported-by: Olof Johansson
Cc: Laxman Dewangan
Signed-off-by: Linus Walleij
15 Aug, 2013
1 commit
-
Add generic APIs to map the DT node and its sub node in pinconf generic
driver. These APIs can be used from driver to parse the DT node who
uses the pinconf generic APIs for defining their nodes.Changes from V1:
- Add generic property for pins and functions in pinconf-generic.
- Add APIs to map the DT and subnode.
- Move common utils APIs to the pinctrl-utils from this file.
- Update the binding document accordingly.
Changes from V2:
- Rebased the pinctrl binding doc on top of Stephen's cleanup.
- Rename properties "pinctrl-pins" and "pinctrl-function" to
"pins" and "function".Signed-off-by: Laxman Dewangan
Reviewed-by: Stephen Warren
Signed-off-by: Linus Walleij
25 Jun, 2013
3 commits
-
Currently the debounce time pinconfig option uses an unspecified
"time units" unit. As pinconfig options should use SI units and a
real unit is also necessary for generic dt bindings, change it
to usec. Currently no driver is using the generic pinconfig option
for this, so the unit change is safe to do.Signed-off-by: Heiko Stuebner
Reviewed-by: James Hogan
Signed-off-by: Linus Walleij -
PULL_PIN_DEFAULT is meant for hardware completely hiding any pull
settings from the driver, so that it's really only possible to turn
the pull on or off, but it not being possible to determine any
pull settings from software.Also the binding-documentation for the pull arguments did not match
the changes to the expected values.Signed-off-by: Heiko Stuebner
Reviewed-by: James Hogan
Signed-off-by: Linus Walleij -
From the inception ot the pin config API there has been the
possibility to get a handle at a pin directly and configure
its electrical characteristics. For this reason we had:int pin_config_get(const char *dev_name, const char *name,
unsigned long *config);
int pin_config_set(const char *dev_name, const char *name,
unsigned long config);
int pin_config_group_get(const char *dev_name,
const char *pin_group,
unsigned long *config);
int pin_config_group_set(const char *dev_name,
const char *pin_group,
unsigned long config);After the introduction of the pin control states that will
control pins associated with devices, and its subsequent
introduction to the device core, as well as the
introduction of pin control hogs that can set up states on
boot and optionally also at sleep, this direct pin control
API is a thing of the past.As could be expected, it has zero in-kernel users.
Let's delete this API and make our world simpler.Reported-by: Tony Lindgren
Reviewed-by: Stephen Warren
Acked-by: Tony Lindgren
Signed-off-by: Linus Walleij
18 Jun, 2013
5 commits
-
The kerneldoc comment for struct pinconf_ops was missing
pin_config_dbg_parse_modify, and instead described
pin_config_group_dbg_set (which is presumably an old name for the same
function). Rename it in the kerneldoc comment so they match.Signed-off-by: James Hogan
Signed-off-by: Linus Walleij -
It is counter-intuitive to have "0" mean disable in a boolean
manner for electronic properties of pins such as pull-up and
pull-down. Therefore, define that a pull-up/pull-down argument
of 0 to such a generic option means that the pin is
short-circuited to VDD or GROUND. Pull disablement shall be
done using PIN_CONFIG_BIAS_DISABLE.Cc: James Hogan
Cc: Laurent Pinchart
Acked-by Heiko Stuebner
Acked-by: Laurent Pinchart
Signed-off-by: Linus Walleij -
The comment introduced with the recently added pinctrl_gpio_range.pins
element was wrong. This corrects it.
Thanks to Patrice Chotard for pointing this out.Signed-off-by: Christian Ruppert
Signed-off-by: Linus Walleij -
The stubs for the !PINCTRL case were placed in the wrong
part of the file, causing breakage in linux-next when compiling
SH without pinctrl. Fix it up by moving the stubs to the right
place.Signed-off-by: Linus Walleij
-
Traditionally, GPIO ranges are based on consecutive ranges of both GPIO
and pin numbers. This patch allows for GPIO ranges with arbitrary lists
of pin numbers.Signed-off-by: Christian Ruppert
Signed-off-by: Linus Walleij
16 Jun, 2013
3 commits
-
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
Cc: Dmitry Torokhov
Cc: Stephen Warren
Acked-by: Wolfram Sang
Acked-by: Greg Kroah-Hartman
Reviewed-by: Mark Brown
Reviewed-by: Kevin Hilman
Signed-off-by: Linus Walleij -
There exist controllers that don't support to set the pull to up or down
separately but instead automatically set the pull direction based on
embedded knowledge inside the controller, for example depending on the
selected mux function of the pin.Therefore this patch adds another config option to use this default
pull-state for a pin where it is not possible to know or decide if the
pin will be pulled up or down.Signed-off-by: Heiko Stuebner
Reviewed-by: Stephen Warren
Signed-off-by: Linus Walleij -
Add a new PIN_CONFIG_BIAS_BUS_HOLD pin configuration for a bus holder
pin mode (also known as bus keeper, or repeater). This is a weak latch
which drives the last value on a tristate bus. Another device on the bus
can drive the bus high or low before going tristate to change the value
driven by the pin.Signed-off-by: James Hogan
Cc: Linus Walleij
Signed-off-by: Linus Walleij
14 May, 2013
1 commit
-
Drive strength controls both sink and source currents, clarify the
description accordingly.Signed-off-by: Laurent Pinchart
Signed-off-by: Linus Walleij
19 Apr, 2013
1 commit
-
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.Change log in this patch set;
Take into account latest feedback from Stephen Warren:
- stale comments update
- improved code efficiency and readibility
- limit size of global variable pinconf_dbg_conf
- remove req_type as it can easily be added later when
add/delete requests support is implementedSigned-off-by: Laurent Meunier
Signed-off-by: Linus Walleij
07 Mar, 2013
1 commit
-
The pinconf, pinctrl and pinmux operation structures hold function
pointers that are never modified. Declare them as const.Signed-off-by: Laurent Pinchart
Signed-off-by: Linus Walleij
15 Feb, 2013
1 commit
-
Rename PIN_CONFIG_INPUT_SCHMITT_DISABLE to
PIN_CONFIG_INPUT_SCHMITT_ENABLE. It's used to make it more generialize.Signed-off-by: Haojian Zhuang
Acked-by: Tony Lindgren
Signed-off-by: Linus Walleij
23 Jan, 2013
1 commit
-
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=2A 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
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
Cc: Benoit Cousson
Cc: Dmitry Torokhov
Cc: Thomas Petazzoni
Cc: Mitch Bradley
Cc: Ulf Hansson
Cc: Rafael J. Wysocki
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Rickard Andersson
Cc: Russell King
Reviewed-by: Mark Brown
Acked-by: Greg Kroah-Hartman
Signed-off-by: Linus Walleij
[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: Stephen Warren
Signed-off-by: Linus Walleij
21 Jan, 2013
1 commit
-
Add PIN_CONFIG_SLEW_RATE parameter into pinconf-generic driver.
Signed-off-by: Haojian Zhuang
Signed-off-by: Linus Walleij