linux-toradex.git/include/linux/pinctrl/pinctrl.h, branch v3.14.3

pinctrl: Add void * to pinctrl_pin_desc

2014-01-16T13:25:37+00:00

drv_data is added to the pinctrl_pin_desc for drivers to define additional
driver-specific per-pin data.

Signed-off-by: Sherman Yin 
Reviewed-by: Christian Daudt 
Reviewed-by: Matt Porter 
Signed-off-by: Linus Walleij

pinctrl/gpio: non-linear GPIO ranges accesible from gpiolib

2013-10-16T13:33:50+00:00

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

Fix comment on pinctrl_gpio_range.pin_base

2013-06-17T16:18:29+00:00

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

pinctrl: add pin list based GPIO ranges

2013-06-17T16:18:28+00:00

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

pinctrl: Declare operation structures as const

2013-03-07T04:27:29+00:00

The pinconf, pinctrl and pinmux operation structures hold function
pointers that are never modified. Declare them as const.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Linus Walleij

pinctrl: core: get devname from pinctrl_dev

2013-01-21T14:14:39+00:00

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

pinctrl: add function to retrieve range from pin

2012-11-21T07:55:12+00:00

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

gpiolib: rename find_pinctrl_*

2012-11-21T07:55:10+00:00

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

gpiolib: separation of pin concerns

2012-11-11T18:06:07+00:00

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

gpiolib: provide provision to register pin ranges

2012-11-11T18:06:00+00:00

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 
Signed-off-by: Viresh Kumar 
Signed-off-by: Shiraz Hashim 
[Edited documentation a bit]
Signed-off-by: Linus Walleij