This driver will be converted to a dual GPIO + pinctrl driver
since it supports biasing and driving control options. Hopefully
it can serve as an example.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since we now anyway make a copy of the platform-supplied pinmux
map, we can just as well make it possible to call the function
adding maps several times, so as to simplify cases (as PXA) where
several sets of disparate mappings need to be added depending on
target platform.
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Acked-by: Arnd Bergmann <arnd@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This makes a deep copy of the pinmux function map instead of
keeping the copy supplied from the platform around. This makes
it possible to tag the platforms map with __initdata as is also
done as part of this patch.
Rationale: a certain target platform (PXA) has numerous
pinmux maps, many of which will be lying around unused after
boot in a multi-platform binary. Instead, deep-copy the one
we're going to use and tag them all __initdata so they go away
after boot.
ChangeLog v1->v2:
- Fixup the deep copy, missed a few items on the struct,
plus mark bool member non-const since we're making runtime
copies if this stuff now.
ChangeLog v2->v3:
- Make a shallow copy (just copy the array of map structs)
as Arnd noticed, string constants never get discarded by the
kernel anyway, so these pointers may be safely copied over.
Reviewed-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When requesting a single GPIO pin to be muxed in, some controllers
will need to poke a different value into the control register
depending on whether the pin will be used for GPIO output or GPIO
input. So create pinmux counterparts to gpio_direction_[input|output]
in the pinctrl framework.
ChangeLog v1->v2:
- This also amends the documentation to make it clear the this
function and associated machinery is *ONLY* intended as a backend
to gpiolib machinery, not for everyone and his dog to start playing
around with pins.
ChangeLog v2->v3:
- Don't pass an argument to the common request function, instead
provide pinmux_* counterparts to the gpio_direction_[input|output]
calls, simpler and anyone can understand it.
ChangeLog v3->v4:
- Fix numerous spelling mistakes and dangling text in documentation.
Add Ack and Rewewed-by.
Cc: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Show the mapped pin range corresponding to the GPIO range in
debugfs for pin controllers.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch enables mapping a base offset of gpio ranges with
a pin offset even if does'nt matched. A base of pinctrl_gpio_range
means a base offset of gpio. However, we cannot convert gpio to pin
number for sparse gpio ranges just only using a gpio base offset.
We can convert a gpio to real pin number(even if not matched) using
a new pin_base which means a base pin offset of requested gpio range.
Now, the pin control subsystem passes the pin base offset to the
pinmux driver.
For example, let's assume below two gpio ranges in the system.
static struct pinctrl_gpio_range gpio_range_a = {
.name = "chip a",
.id = 0,
.base = 32,
.pin_base = 32,
.npins = 16,
.gc = &chip_a;
};
static struct pinctrl_gpio_range gpio_range_b = {
.name = "chip b",
.id = 0,
.base = 48,
.pin_base = 64,
.npins = 8,
.gc = &chip_b;
};
We can calucalate a exact pin ranges even if doesn't matched with gpio ranges.
chip a:
gpio-range : [32 .. 47]
pin-range : [32 .. 47]
chip b:
gpio-range : [48 .. 55]
pin-range : [64 .. 71]
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We want singned pins to mean "invalid" only on the outside
of the subsystem.
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Update the docs removing an obsolete __refdata tag and document
the mysterious return value of pin_free(). And fixes up some various
confusions in the pinctrl documentation.
Reported-by: Rajendra Nayak <rnayak@ti.com>
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Reported-by: Thomas Abraham <thomas.abraham@linaro.org>
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
completely different manner than they select which function to mux out of
that pin. In order to support a single "free" pinmux_op, the driver would
need to maintain a per-pin state of requested-for-gpio vs. requested-for-
function. However, that's a lot of work when the core already has explicit
separate paths for gpio request/free and function request/free.
So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free()
call it when appropriate.
When doing this, I noticed that when calling pin_request():
!!gpio == (gpio_range != NULL)
... and so I collapsed those two parameters in both pin_request(), and
when adding writing the new code in pin_free().
Also, for pin_free():
!!free_func == (gpio_range != NULL)
However, I didn't want pin_free() to know about the GPIO function naming
special case, so instead, I reworked pin_free() to always return the pin's
previously requested function, and now pinmux_free_gpio() calls
kfree(function). This is much more balanced with the allocation having
been performed in pinmux_request_gpio().
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Function pin_is_valid just call pin_desc_get which is in pin_request
call some line below. Remove pin_is_valid() check.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Now also the core needs to look up pin groups so move the lookup
function there and expose it in the internal header.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix u300_pmx_endisable() to iterate over the list of 'bits' and
'mask' populated as part of u300_pmx_functions.mask[]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
DEBUG_PINCTRL wasn't used at all and DEBUG_PINMUX doesn't exist.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Machines that have embedded pin controllers need to select them
explicitly, so why broadcast their config options to menuconfig.
We provide a helpful submenu for those machines that do select
it, making it possible to enable debugging for example.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
fix sirfsoc_get_group_pins prototype introduced in 7e570f97, we
missed to de-constify a pointer.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Instead, store a pointer to the currently assigned function.
This allows us to delete the mux_requested variable from pin_desc; a pin
is requested if its currently assigned function is non-NULL.
When a pin is requested as a GPIO rather than a regular function, the
assigned function name is dynamically constructed. In this case, we have
to kstrdup() the dynamically constructed name, so that mux_function doesn't
pointed at stack data. This requires pin_free to be told whether to free
the mux_function pointer or not.
This removes the hard-coded maximum function name length.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
A pin controller's names array is no longer marked __refdata. Hence, we
can avoid copying a pin's name into the descriptor when registering it.
Instead, just point at the string supplied in the pin array.
This both simplifies and speeds up pin controller initialization, but
also removes the hard-coded maximum pin name length.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
A pin controller's pin definitions are used both during pinctrl_register()
and pinctrl_unregister(). The latter happens outside of __init/__devinit
time, and hence it is unsafe to mark the pin array as __refdata.
Acked-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
get_group_pins() "returns" a pointer to an array of const objects, through
a pointer parameter. Fix the prototype so what's pointed at by the returned
pointer is const, rather than the function parameter being const.
This also allows the removal of a cast in each of the two current pinmux
drivers.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This creates a pin controller driver for the SiRFprinaII
pin mux portions.
Signed-off-by: Rongjun Ying <Rongjun.Ying@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
[Fixup for changed function names and semantics in the v10 patch]
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
This adds a driver for the U300 pinmux portions of the system
controller "SYSCON". It also serves as an example of how to use
the pinmux subsystem. This driver also houses the platform data
for the only supported platform.
This deletes the old U300 driver in arch/arm/mach-u300 and
replace it with a driver using the new subsystem.
The new driver is considerably fatter than the old one, but it
also registers all 467 pins of the system and adds the power
and EMIF pin groups and corresponding functions. The idea
is to use this driver as a a reference for other
implementation so it needs to be as complete and verbose
as possible.
Reviewed-by: Barry Song <21cnbao@gmail.com>
[Fixup for changed function names and semantics in the v10 patch]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij