14 Aug, 2017
1 commit
-
Update subsystem wide for consistency.
Signed-off-by: Masahiro Yamada
Signed-off-by: Linus Walleij
13 Jan, 2017
1 commit
-
Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
regression at least with sh-pfc that is also a GPIO controller as
noted by Geert Uytterhoeven .As the original pinctrl_register() has issues calling pin controller
driver functions early before the controller has finished registering,
we can't just revert commit df61b366af26. That would break the drivers
using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.So let's fix the issue with the following steps as a single patch:
1. Revert the late_init parts of commit df61b366af26.
The late_init clearly won't work and we have to just give up
on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
GENERIC_PINMUX_FUNCTIONS.2. Split pinctrl_register() into two parts
By splitting pinctrl_register() into pinctrl_init_controller()
and pinctrl_create_and_start() we have better control over when
it's safe to call pinctrl_create().3. Introduce a new pinctrl_register_and_init() function
As suggested by Linus Walleij , we
can just introduce a new function for the controllers that need
pinctrl_create() called later.4. Convert the four known problem cases to use new function
Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
to use the new function to fix the issues. The rest of the drivers
can be converted later. Let's also update Documentation/pinctrl.txt
accordingly because of the known issues with pinctrl_register().Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
Reported-by: Geert Uytterhoeven
Cc: Gary Bisson
Signed-off-by: Tony Lindgren
Tested-by: Geert Uytterhoeven
Signed-off-by: Linus Walleij
03 Jan, 2017
4 commits
-
We can add generic helpers for function handling for cases where the pin
controller driver does not need to use static arrays.Signed-off-by: Tony Lindgren
[Renamed the Kconfig item and moved things around]
Signed-off-by: Linus Walleij -
Rename the symbol PINCTRL_GENERIC to PINCTRL_GENERIC_GROUPS since
it all pertains to groups. Replace everywhere.ifdef out the radix tree and the struct when not using the
generic groups.Cc: Tony Lindgren
Signed-off-by: Linus Walleij -
We can add generic helpers for pin group handling for cases where the pin
controller driver does not need to use static arrays.Signed-off-by: Tony Lindgren
Signed-off-by: Linus Walleij -
Having the pin control framework call pin controller functions
before it's probe has finished is not nice as the pin controller
device driver does not yet have struct pinctrl_dev handle.Let's fix this issue by adding deferred work for late init. This is
needed to be able to add pinctrl generic helper functions that expect
to know struct pinctrl_dev handle. Note that we now need to call
create_pinctrl() directly as we don't want to add the pin controller
to the list of controllers until the hogs are claimed. We also need
to pass the pinctrl_dev to the device tree parser functions as they
otherwise won't find the right controller at this point.Signed-off-by: Tony Lindgren
Signed-off-by: Linus Walleij
31 May, 2016
1 commit
-
Currently, struct pinctrl_pin_desc can have per-pin driver private
data, but it is not copied to struct pin_desc.For a driver with sparse pin space, for-loop search like below would
be necessary in order to get the driver-specific data for a desired
pin number.for (i = 0; i < pctldev->desc->npins; i++)
if (pin_number == pctldev->desc->pins[i].number)
return pctldev->desc->pins[i].drv_data;This is not efficient for a driver with a large number of pins.
So, copy the data to struct pin_desc when each pin is registered
for the faster radix tree lookup.Signed-off-by: Masahiro Yamada
Signed-off-by: Linus Walleij
07 Mar, 2016
1 commit
-
pinctrl_find_gpio_range_from_pin takes the pctldev->mutex but so
does pinconf_pins_show and this will cause a deadlock if
pinctrl_find_gpio_range_from_pin is used in .pin_config_get
callback.Create a nolock version of pinctrl_find_gpio_range_from_pin to
allow pin to gpio lookup to be used from pinconf_pins_show.Signed-off-by: Joachim Eastwood
Signed-off-by: Linus Walleij
06 May, 2015
1 commit
-
Way back, when the world was a simpler place and there was no war, no
evil, and no kernel bugs, there was just a single pinctrl lock. That
was how the world was when (57291ce pinctrl: core device tree mapping
table parsing support) was written. In that case, there were
instances where the pinctrl mutex was already held when
pinctrl_register_map() was called, hence a "locked" parameter was
passed to the function to indicate that the mutex was already locked
(so we shouldn't lock it again).A few years ago in (42fed7b pinctrl: move subsystem mutex to
pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
...but (oops) we forgot to re-think about the whole "locked" parameter
for pinctrl_register_map(). Basically the "locked" parameter appears
to still refer to whether the bigger pinctrl_dev mutex is locked, but
we're using it to skip locks of our (now separate) pinctrl_maps_mutex.That's kind of a bad thing(TM). Probably nobody noticed because most
of the calls to pinctrl_register_map happen at boot time and we've got
synchronous device probing. ...and even cases where we're
asynchronous don't end up actually hitting the race too often. ...but
after banging my head against the wall for a bug that reproduced 1 out
of 1000 reboots and lots of looking through kgdb, I finally noticed
this.Anyway, we can now safely remove the "locked" parameter and go back to
a war-free, evil-free, and kernel-bug-free world.Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
Signed-off-by: Doug Anderson
Signed-off-by: Linus Walleij
26 Apr, 2013
1 commit
-
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
Signed-off-by: Patrice Chotard
Signed-off-by: Linus Walleij
28 Mar, 2013
1 commit
-
Clearly, "node" was meant instead of "not"
Signed-off-by: Richard Genoud
Signed-off-by: Linus Walleij
11 Feb, 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.Signed-off-by: Laurent Meunier
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
12 Jan, 2013
1 commit
-
This fix allows handling sleep mode for hogged
pins in pinctrl. It provides functions to set pins
to sleep/default configurations according to their
current state.Signed-off-by: Julien Delacou
Reviewed-by: Stephen Warren
Signed-off-by: Linus Walleij
12 Nov, 2012
1 commit
-
This switches the way that pins are reserved for multiplexing:
We used to do this when the map was parsed, at the creation of
the settings inside the pinctrl handle, in pinmux_map_to_setting().However this does not work for us, because we want to use the
same set of pins with different devices at different times: the
current code assumes that the pin groups in a pinmux state will
only be used with one single device, albeit different groups can
be active at different times. For example if a single I2C driver
block is used to drive two different busses located on two
pin groups A and B, then the pins for all possible states of a
function are reserved when fetching the pinctrl handle: the
I2C bus can choose either set A or set B by a mux state at
runtime, but all pins in both group A and B (the superset) are
effectively reserved for that I2C function and mapped to the
device. Another device can never get in and use the pins in
group A, even if the device/function is using group B at the
moment.Instead: let use reserve the pins when the state is activated
and drop them when the state is disabled, i.e. when we move to
another state. This way different devices/functions can use the
same pins at different times.We know that this is an odd way of doing things, but we really
need to switch e.g. an SD-card slot to become a tracing output
sink at runtime: we plug in a special "tracing card" then mux
the pins that used to be an SD slot around to the tracing
unit and push out tracing data there instead of SD-card
traffic.As a side effect pinmux_free_setting() is unused but the stubs
are kept for future additions of code.Cc: Patrice Chotard
Cc: Loic Pallardy
Acked-by: Stephen Warren
Tested-by: Jean Nicolas Graux
Signed-off-by: Linus Walleij
18 Apr, 2012
2 commits
-
Pin name is more useful to users.
After change, when cat pingroups in sysfs, it becomes:
root@freescale /sys/kernel/debug/pinctrl/20e0000.iomuxc$ cat pingroups
registered pin groups:
group: uart4grp-1
pin 219 (MX6Q_PAD_KEY_ROW0)
pin 218 (MX6Q_PAD_KEY_COL0)group: usdhc4grp-1
pin 305 (MX6Q_PAD_SD4_CMD)
pin 306 (MX6Q_PAD_SD4_CLK)
pin 315 (MX6Q_PAD_SD4_DAT0)
pin 316 (MX6Q_PAD_SD4_DAT1)
pin 317 (MX6Q_PAD_SD4_DAT2)
pin 318 (MX6Q_PAD_SD4_DAT3)
pin 319 (MX6Q_PAD_SD4_DAT4)
pin 320 (MX6Q_PAD_SD4_DAT5)
pin 321 (MX6Q_PAD_SD4_DAT6)
pin 322 (MX6Q_PAD_SD4_DAT7)Acked-by: Stephen Warren
Signed-off-by: Dong Aisheng
Signed-off-by: Linus Walleij -
During pinctrl_get(), if the client device has a device tree node, look
for the common pinctrl properties there. If found, parse the referenced
device tree nodes, with the help of the pinctrl drivers, and generate
mapping table entries from them.During pinctrl_put(), free any results of device tree parsing.
Acked-by: Dong Aisheng
Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij
13 Mar, 2012
1 commit
-
Per recent updates to Documentation/gpio.txt, gpiolib drivers should
inform pinctrl when a GPIO is requested. pinctrl then marks that pin as
in-use for that GPIO function.When an SoC muxes pins in a group, it's quite possible for the group to
contain e.g. 6 pins, but only 4 of them actually be needed by the HW
module that's mux'd to them. In this case, the other 2 pins could be
used as GPIOs. However, pinctrl marks all the pins within the group as
in-use by the selected mux function. To allow the expected gpiolib
interaction, separate the concepts of pin ownership into two parts: One
for the mux function and one for GPIO usage. Finally, allow those two
ownerships to exist in parallel.Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij
07 Mar, 2012
1 commit
-
struct pinctrl_setting contains an enum pinctrl_map_type
field, so we need to include machine.h. Also fix kerneldoc
to indicate that the pinctrl_setting is about both muxing
and other config.Acked-by: Stephen Warren
Signed-off-by: Linus Walleij
05 Mar, 2012
6 commits
-
Until recently, the pinctrl pinmux-pins debugfs file displayed the
selected function for each owned pin. This feature was removed during
restructing in support of recent API rework. This change restoreds this
feature, and also displays the group that the function was selected on,
in case a pin is a member of multiple groups.Based on work by: Linus Walleij
Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij -
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 groupThis 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
Acked-by: Dong Aisheng
Signed-off-by: Linus Walleij -
The API model is changed from:
p = pinctrl_get(dev, "state1");
pinctrl_enable(p);
...
pinctrl_disable(p);
pinctrl_put(p);
p = pinctrl_get(dev, "state2");
pinctrl_enable(p);
...
pinctrl_disable(p);
pinctrl_put(p);to this:
p = pinctrl_get(dev);
s1 = pinctrl_lookup_state(p, "state1");
s2 = pinctrl_lookup_state(p, "state2");
pinctrl_select_state(p, s1);
...
pinctrl_select_state(p, s2);
...
pinctrl_put(p);This allows devices to directly transition between states without
disabling the pin controller programming and put()/get()ing the
configuration data each time. This model will also better suit pinconf
programming, which doesn't have a concept of "disable".The special-case hogging feature of pin controllers is re-written to use
the regular APIs instead of special-case code. Hence, the pinmux-hogs
debugfs file is removed; see the top-level pinctrl-handles files for
equivalent data.Signed-off-by: Stephen Warren
Acked-by: Dong Aisheng
Signed-off-by: Linus Walleij -
Multiple mapping table entries could reference the same pin, and hence
"own" it. This would be unusual now that pinctrl_get() represents a single
state for a client device, but in the future when it represents all known
states for a device, this is quite likely. Implement reference counting
for pin ownership to handle this.Signed-off-by: Stephen Warren
Acked-by: Dong Aisheng
Signed-off-by: Linus Walleij -
This change separates two aspects of struct pinctrl:
a) The data representation of the parsed mapping table, into:
1) The top-level struct pinctrl object, a single entity returned
by pinctrl_get().2) The parsed version of each mapping table entry, struct
pinctrl_setting, of which there is one per mapping table entry.b) The code that handles this; the code for (1) above is in core.c, and
the code to parse/execute each entry in (2) above is in pinmux.c, while
the iteration over multiple settings is lifted to core.c.This will allow the following future changes:
1) pinctrl_get() API rework, so that struct pinctrl represents all states
for the device, and the device can select between them without calling
put()/get() again.2) To support that, a struct pinctrl_state object will be inserted into
the data model between the struct pinctrl and struct pinctrl_setting.3) The mapping table will be extended to allow specification of pin config
settings too. To support this, struct pinctrl_setting will be enhanced
to store either mux settings or config settings, and functions will be
added to pinconf.c to parse/execute pin configuration settings.Signed-off-by: Stephen Warren
Acked-by: Linus Walleij
Acked-by: Dong Aisheng
Signed-off-by: Linus Walleij -
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
Signed-off-by: Linus Walleij
02 Mar, 2012
3 commits
-
The introduction of the owner field on the pin descriptor was not
properly documented so fix this up.Signed-off-by: Linus Walleij
-
This provides a single centralized name for the default state.
Update PIN_MAP_* macros to use this state name, instead of requiring the
user to pass a state name in.With this change, hog entries in the mapping table are defined as those
with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same
name. This interacts badly with the nested iteration over mapping table
entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now
attempt to claim each hog mapping table entry multiple times. Replacing
the custom hog code with a simple pinctrl_get()/pinctrl_enable().Update documentation and mapping tables to use this.
Signed-off-by: Stephen Warren
Acked-by: Dong Aisheng
Signed-off-by: Linus Walleij -
At present, pinctrl_get() assumes that all matching mapping table entries
have the same "function" value, albeit potentially applied to different
pins/groups.This change removes this restriction; pinctrl_get() can now handle a set
of mapping tables where different functions are applied to the various
pins/groups.Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij
24 Feb, 2012
1 commit
-
struct pinctrl_dev's pin_desc_tree_lock and pinctrl_hogs_lock aren't
useful; the data they protect is read-only except when registering or
unregistering a pinctrl_dev, and at those times, it doesn't make sense to
protect one part of the structure independently from the rest.Move pinctrl_init_device_debugfs() to the end of pinctrl_register() so
that debugfs can't access the struct pinctrl_dev until it's fully
initialized, i.e. after the hogs are set up.Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij
23 Feb, 2012
2 commits
-
When pins are requested/acquired/got, some device becomes the owner of
their mux setting. At this point, it isn't certain which mux function
will be selected for the pin, since this may vary between each of the
device's states in the pinctrl mapping table. As such, we should record
the owning device, not what we think the initial mux setting will be,
when requesting pins.This doesn't make a lot of difference right now since pinctrl_get gets
only one single device/state combination, but this will make a difference
when pinctrl_get gets all states, and pinctrl_select_state can switch
between states.Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij -
* Make all functions internal to core.c static. Remove any of these from
core.h.
* Add any missing EXPORT_SYMBOL_GPL().Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij
11 Feb, 2012
2 commits
-
This moves the per-devices struct pinctrl handles and device map
over from the pinmux part of the subsystem to the core pinctrl part.
This makes the device handles core infrastructure with the goal of
using these handles also for pin configuration, so that device
drivers (or boards etc) will need one and only one handle to the
pin control core.Acked-by: Stephen Warren
Signed-off-by: Linus Walleij -
Since we want to use the former pinmux handles and mapping tables for
generic control involving both muxing and configuration we begin
refactoring by renaming them from pinmux_* to pinctrl_*.ChangeLog v1->v2:
- Also rename the PINMUX_* macros in machine.h to PIN_ as indicated
in the documentation so as to reflect the generic nature of these
mapping entries from now on.Acked-by: Stephen Warren
Signed-off-by: Linus Walleij
02 Feb, 2012
1 commit
-
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
Signed-off-by: Linus Walleij
25 Jan, 2012
1 commit
-
We were not cleaning up properly after unloading a pinmux
driver compiled as module.Signed-off-by: Tony Lindgren
Signed-off-by: Linus Walleij
03 Jan, 2012
5 commits
-
If pins with blank names are registered, we assign them names on-the-fly
on the form "PINn" where n is the pin number for that pin on the specific
controller.Acked-by: Stephen Warren
Signed-off-by: Linus Walleij -
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
Signed-off-by: Linus Walleij -
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
Signed-off-by: Linus Walleij -
We want singned pins to mean "invalid" only on the outside
of the subsystem.Signed-off-by: Marek Belisko
Signed-off-by: Linus Walleij -
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
Signed-off-by: Linus Walleij
