| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
drv_data is added to the pinctrl_pin_desc for drivers to define additional
driver-specific per-pin data.
Signed-off-by: Sherman Yin <[email protected]>
Reviewed-by: Christian Daudt <[email protected]>
Reviewed-by: Matt Porter <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This commit adds slew-rate and input-enable/disable support for pinconf
-generic.
Signed-off-by: Sherman Yin <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The PIN_CONFIG_OUTPUT parameter is really tricky to understand
and needs an explicit pointer to the documentation.
Cc: Tomasz Figa <[email protected]>
Cc: Kyungmin Park <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Christian Daudt <[email protected]>
Reviewed-by: Matt Porter <[email protected]>
Tested-by: Stephen Warren <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
Tested-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <linux/device.h> to get the
most important structs and forward-declare the pinctrl
core structs.
Reported-by: Olof Johansson <[email protected]>
Cc: Laxman Dewangan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: James Hogan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: James Hogan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Acked-by Heiko Stuebner <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Cc: Stephen Warren <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Reviewed-by: Kevin Hilman <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Cc: Linus Walleij <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Drive strength controls both sink and source currents, clarify the
description accordingly.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The pinconf, pinctrl and pinmux operation structures hold function
pointers that are never modified. Declare them as const.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Cc: Benoit Cousson <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: Mitch Bradley <[email protected]>
Cc: Ulf Hansson <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
Cc: Rickard Andersson <[email protected]>
Cc: Russell King <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
[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 <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Add PIN_CONFIG_SLEW_RATE parameter into pinconf-generic driver.
Signed-off-by: Haojian Zhuang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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: Haojian Zhuang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Some pin configurations IP allows to set the current output to the pin.
This patch adds such a parameter to the pinconf-generic mechanism.
This parameter takes as argument the drive strength in mA.
Signed-off-by: Maxime Ripard <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This adds a definition of a generic output configuration
for a certain pin when using the generic pin configuration
library. Whereas driving pins low/high is usually a GPIO
business, you may want to set up pins into a default state
using hogs, and never touch them again. This helps out
with that scenario.
Based on a patch from Patrice Chotard.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
In Marvell PXA/MMP silicons, input schmitt disable value is 0x40, not 0.
So append new config parameter -- input schmitt disable.
Signed-off-by: Haojian Zhuang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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: Stephen Warren <[email protected]>
Reviewed-by: Viresh Kumar <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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: Stephen Warren <[email protected]>
Reviewed-by: Viresh Kumar <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.
So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.
This is done by:
- Adding a return code to gpiochip_add_pin_range() so we can
reliably check whether this succeeds.
- Get rid of the custom of_pinctrl_add_gpio_range() from
pinctrl. Instead create of_pinctrl_get() to just retrive the
pin controller per se from an OF node. This composite
function was just begging to be deleted, it was way to
purpose-specific.
- Use pinctrl_dev_get_name() to get the name of the retrieved
pin controller and use that to call back into the generic
gpiochip_add_pin_range().
Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Shiraz Hashim <[email protected]>
[Edited documentation a bit]
Signed-off-by: Linus Walleij <[email protected]>
|
|
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: Viresh Kumar <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
git://git.infradead.org/users/dhowells/linux-headers
Pull preparatory patches for user API disintegration from David Howells:
"The patches herein prepare for the extraction of the Userspace API
bits from the various header files named in the Kbuild files.
New subdirectories are created under either include/uapi/ or
arch/x/include/uapi/ that correspond to the subdirectory containing
that file under include/ or arch/x/include/.
The new subdirs under the uapi/ directory are populated with Kbuild
files that mostly do nothing at this time. Further patches will
disintegrate the headers in each original directory and fill in the
Kbuild files as they do it.
These patches also:
(1) fix up #inclusions of "foo.h" rather than <foo.h>.
(2) Remove some redundant #includes from the DRM code.
(3) Make the kernel build infrastructure handle Kbuild files both in
the old places and the new UAPI place that both specify headers
to be exported.
(4) Fix some kernel tools that #include kernel headers during their
build.
I have compile tested this with allyesconfig against x86_64,
allmodconfig against i386 and a scattering of additional defconfigs of
other arches. Prepared for main script
Signed-off-by: David Howells <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Acked-by: Michael Kerrisk <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Acked-by: Dave Jones <[email protected]>
Acked-by: H. Peter Anvin <[email protected]>"
* tag 'uapi-prep-20121002' of git://git.infradead.org/users/dhowells/linux-headers:
UAPI: Plumb the UAPI Kbuilds into the user header installation and checking
UAPI: x86: Differentiate the generated UAPI and internal headers
UAPI: Remove the objhdr-y export list
UAPI: Move linux/version.h
UAPI: Set up uapi/asm/Kbuild.asm
UAPI: x86: Fix insn_sanity build failure after UAPI split
UAPI: x86: Fix the test_get_len tool
UAPI: (Scripted) Set up UAPI Kbuild files
UAPI: Partition the header include path sets and add uapi/ header directories
UAPI: (Scripted) Convert #include "..." to #include <path/...> in kernel system headers
UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/
UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.
UAPI: Refer to the DRM UAPI headers with <...> and from certain headers only
|
|
system headers
Convert #include "..." to #include <path/...> in kernel system headers.
Signed-off-by: David Howells <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Acked-by: Dave Jones <[email protected]>
|
|
This pure documentation fix tries to align the "idle" and
"sleep" pin states to the idle and suspend states from
runtime PM.
Cc: Patrice Chotard <[email protected]>
Acked-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This doesn't change semantics, just looks nicer.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
As struct device is used as a function argument, it should at
least be declared (device.h is not included).
Signed-off-by: Richard Genoud <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Often GPIO ranges are added in batch, so create a special
function for that.
Acked-by: Stephen Warren <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The gpio ranges will be automatically removed when the pinctrl
driver is unregistered.
Acked-by: Stephen Warren <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into next/pinctrl
ux500 GPIO and pinctrl changes for kernel 3.5
* tag 'ux500-gpio-pins-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
ARM: ux500: switch MSP to using pinctrl for pins
ARM: ux500: alter MSP registration to return a device pointer
ARM: ux500: switch to using pinctrl for uart0
ARM: ux500: delete custom pin control system
ARM: ux500: switch over to Nomadik pinctrl driver
pinctrl: add sleep state definition
pinctrl/nomadik: implement pin configuration
pinctrl/nomadik: implement pin multiplexing
pinctrl/nomadik: reuse GPIO debug function for pins
pinctrl/nomadik: break out single GPIO debug function
pinctrl/nomadik: basic Nomadik pinctrl interface
pinctrl/nomadik: !CONFIG_OF build error
gpio: move the Nomadik GPIO driver to pinctrl
Context conflicts resolved in drivers/pinctrl/Kconfig and
drivers/pinctrl/Makefile.
Signed-off-by: Olof Johansson <[email protected]>
|
|
There is an IDLE definition in the pinctrl framework, but for
ux500 SLEEP is more apropriate.
I've added some comments on the semantics of the common states
so as to avoid misunderstandings.
ChangeLog v1->v2:
- Fixed terminology "on"->"into".
Acked-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This removes a repeated word and a repeated and incomplete line from two
pinctrl headers.
Signed-off-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Cc: Sascha Hauer <[email protected]>
Acked-by: Stephen Warren <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Signed-off-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This comment was referring to an older PINMUX define, it should
be PINCTRL now.
Reported-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
Acked-by: Dong Aisheng <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
These functions allow the driver core to automatically clean up any
allocations made by drivers, thus leading to simplified drivers.
Signed-off-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Add a pinconf op so that pin controller drivers can decode their pin
config settings for debugfs.
Signed-off-by: Stephen Warren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
[Folded in fix and fixed a minor merge artifact manually]
Signed-off-by: Linus Walleij <[email protected]>
|