ops->pin_config_get() is only used in one specific path that will only be taken
for generic pinconf drivers (ops->is_generic == true) when dumping the pinconf
by using debugfs.
By removing the check in pinconf_check_ops(), let's stop pressuring people to
write a pin_config_get() function that will never be used and so will probably
never be tested.
Removing the check in pinconf_pins_show() allows driver to not implement
pin_config_get() but still get a dump of the pinconf in debugfs by implementing
pin_config_dbg_show().
Finally, not implementing pin_config_get() now results in returning -ENOTSUPP
instead of -EINVAL. While this doesn't have any real impact for now, this feels
more right.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
sizeof() is already size_t so there is no need to cast here. Generally,
casting inside the min() macro instead of using min_t() is considered
bad style.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Have pinconf_dbg_config_write() return a ssize_t. This fixes the following
compilation warning:
drivers/pinctrl/pinconf.c:617:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/pinctrl/pinconf.c:617:2: warning: (near initialization for ‘pinconf_dbg_pinconfig_fops.write’) [enabled by default]
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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 <syin@broadcom.com>
Reviewed-by: Christian Daudt <csd@broadcom.com>
Reviewed-by: Matt Porter <matt.porter@linaro.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix the following sparse warning:
drivers/pinctrl/pinconf.c:521:20: error: incompatible types in comparison expression (different type sizes)
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
So, I notice that we get a couple of warnings from the pinctrl code:
drivers/pinctrl/pinconf.c: In function 'pinconf_dbg_config_print':
drivers/pinctrl/pinconf.c:433:36: warning: 'configs' may be used uninitialized in this function
drivers/pinctrl/pinconf.c: In function 'pinconf_dbg_config_write':
drivers/pinctrl/pinconf.c:511:36: warning: 'configs' may be used uninitialized in this function
While the compiler might not be able to work out that "configs" is
safe, the code doesn't lend itself very well to identifying that
fact when reading it either. This can be trivially solved by a slight
restructuring of the code - which also reduces the LOC.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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 <tony@atomide.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The pinconf_dgb_config_print() takes the per-pincontroller
mutex, when what it wants to take is actually the pin maps
mutex.
Reported-by: James Hogan <james.hogan@imgtec.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus 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: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This update contains a basic fix that went unseen through
test and review.
Signed-off-by: Laurent Meunier <laurent.meunier@st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@stericsson.com>
Signed-off-by: Linus 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.
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 implemented
Signed-off-by: Laurent Meunier <laurent.meunier@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I accidentally left this patch:
commit 6f9e41f4e6
"pinctrl/pinconfig: add debug interface"
in the tree though the patch was not yet finished.
Revert it partially (we need the infrastructural changes).
Cc: Laurent Meunier <laurent.meunier@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The pinconf, pinctrl and pinmux operation structures hold function
pointers that are never modified. Declare them as const.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Linus 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: Laurent Meunier <laurent.meunier@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Mutex is locked duplicatly by pinconf_groups_show() and
pin_config_group_get(). It results dead lock. So avoid to lock mutex
in pinconf_groups_show().
Cc: stable@kernel.org
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Linus 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: 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>
Add a pinconf op so that pin controller drivers can decode their pin
config settings for debugfs.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
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>
This is a split-off from the earlier patch set which adds generic
pin configuration for the pin controllers that want it. Since
we may have a system with mixed generic and custom pin controllers,
we pass a boolean in the pin controller ops vtable to indicate
if it is generic.
ChangeLog v1->v5:
- Follow parent patch versioning number system.
- Document the semantic meaning of return values from pin config
get functions, so we can iterate over pins and check their
properties from debugfs as part of the generic config code.
- Use proper cast functions in the generic debugfs pin config
file.
- Expand generic config to optionally cover groups too.
ChangeLog v5->v6:
- Update to match underlying changes.
ChangeLog v6->v7:
- Drop DRIVE_OFF parameter, use bias high impedance for this
- Delete argument for drive modes push-pull, od and os. These
are now just state transitions.
- Delete slew rate rising/falling due to discussions on on
proper semantics
- Drop config wakeup, struct irq_chip does this for now, add
back if need be.
- Set PIN_CONFIG_END to 0x7fff making room for custom config
parameters from 0x8000 and up.
- Prefix accessor functions with pinconf_
The code was using the union member
setting->data.configs.group_or_pin to store a potential
error code, but since that member is unsigned the
< 0 comparison was not true, letting errors pass through,
ending up as mapped to pin "-22". Fix this up and print
the error.
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
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>
pinconf_groups_show() wrote all debug information on one line. Fix it to
match pinconf_pins_show() and be legible.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Modify the two files so that the order of function prototypes in the
header matches the order of implementations in the .c file.
Don't prototype a couple of internal functions.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
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>
Commit 706e852 "pinctrl: correct a offset while enumerating pins"
modified the variable used by pinconf_pin_show()'s for loop, but didn't
update the for loop test expression.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
Obtaining a "struct pinctrl_dev *" is difficult for code not directly
related to the pinctrl subsystem. However, the device name of the pinctrl
device is fairly well known. So, modify pin_config_*() to take the device
name instead of the "struct pinctrl_dev *".
Signed-off-by: Stephen Warren <swarren@nvidia.com>
[rebased on top of refactoring code]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
