9
0
Fork 0
Commit Graph

3 Commits

Author SHA1 Message Date
Andrey Smirnov a4e1f15b6b pinctrl: Add provisions to control GPIO pin direction
Some SoC (of which Vybrid is a one example) relegate GPIO direction
control to their pinmux IP block, instead of having that functionality
within GPIO IP. Add provisions to control that aspect of pinmux to
support such SoCs.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2016-11-14 08:57:57 +01:00
Sascha Hauer 6d2f0d57be pinctrl: Add functions to select pinctrl from device_node
Instead of requiring a device pointer, add a functions to select
the pinctrl state based on a device node.
The AM33xx cpsw devicetree description has several subdevices with
pinctrl information attached to them. In barebox we do not handle
the subdevices as distinct devices, so the pinctrl is never configured
correctly and the mdio bus subdevice stops working. This patch makes
it possible to configure the pinctrl without having a device.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2013-11-27 10:42:53 +01:00
Sascha Hauer 7f63c0a246 Add initial pinctrl support
This is a massively stripped down pinctrl support. The upper API
consists of only of:

int pinctrl_select_state(struct device_d *dev, const char *state);

This is used to setup the pinmux for a device to a certain state.
This function normally does not need to be called manually. The
device core will setup the default state before probing a device.

The pinctrl core has the job of handling the devicetree. It parses
the pinctrl phandles for a device from devicetree, finds the correct
pinctrl device and calls its set_state callback with the pinctrl
setup device node.

The simplicity of this pinctrl framework comes from the fact that
we:

- Limit usage to devicetree only for now. For non devicetree use the
  old legacy SoC specific APIs still can be used.
- Do not parse the devicetree into internal data structures which
  are used by the drivers later. This adds the overhead that we
  may parse the devicetree multiple times for more dynamic setups,
  but on the other hand we do not need to parse devices from the
  devicetree we don't use in barebox
- Do not detect resource conflicts. Since the framework mainly is
  a devicetree parser this would be hard to implement. It should
  be easy for board maintainers to avoid resource conflicts though.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2013-04-23 09:36:13 +02:00