| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
