linux-toradex.git/drivers/pinctrl/pinconf.c, branch v3.4.45

pinctrl: introduce generic pin config

2012-03-12T21:49:02+00:00

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_

pinctrl: fix error path in pinconf_map_to_setting()

2012-03-12T21:48:43+00:00

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 
Signed-off-by: Linus Walleij

pinctrl: enhance mapping table to support pin config operations

2012-03-05T10:25:11+00:00

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 
Acked-by: Dong Aisheng 
Signed-off-by: Linus Walleij

pinctrl: fix and simplify locking

2012-03-05T10:19:49+00:00

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

pinctrl: fix pinconf_groups_show() to emit newline

2012-02-22T17:42:00+00:00

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 
Signed-off-by: Linus Walleij

pinctrl: Re-order pinconf.[ch] to match each-other

2012-02-22T16:59:32+00:00

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 
Signed-off-by: Linus Walleij

pinctrl: delete raw device pointers in pinmux maps

2012-02-01T18:42:35+00:00

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

pinctrl: add checks for empty function names

2012-01-26T13:13:11+00:00

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 
Signed-off-by: Linus Walleij

pinctrl: fix pinconf_pins_show iteration

2012-01-20T16:55:49+00:00

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 
Signed-off-by: Linus Walleij

pinctrl: correct a offset while enumerating pins

2012-01-03T08:10:09+00:00

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 
Signed-off-by: Kyungmin Park 
[Restored sparse pin space comment]
Signed-off-by: Linus Walleij