| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Use of_get_property() rather than of_find_property() to avoid
dereferencing a struct property directly.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
Our asprintf and vasprintf have different prototypes than the glibc
functions. This causes trouble when we want to share barebox code
with userspace code. Change the prototypes for (v)asprintf to match
the glibc prototypes. Since the current (v)asprintf are convenient
to use change the existing functions to b(v)asprintf.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
| |
The file drivers/pinctrl/pinctrl.c is compiled only when
CONFIG_PINCTRL is defined. "IS_ENABLED(CONFIG_PINCTRL)" is
always evaluated as 1 in this function.
(Although the compiler would optimize it, the source file does
not look nice.)
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove OFDEVICE dependency from PINCTRL. It won't do
much then, so add a comment to Kconfig when PINCTRL is
selected without OFDEVICE
- Let Architectures only select PINCTRL instead of the
particular driver. Change the drivers to 'default y if $SOC'
to make sure the drivers are still compiled if the corresponding
SoC is selected
This fixes Kconfig warnings like:
warning: (PINCTRL_ARMADA_370 && PINCTRL_ARMADA_XP && PINCTRL_DOVE && PINCTRL_KIRKWOOD) selects PINCTRL which has unmet direct dependencies (OFDEVICE)
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
|
| |
A lot of files rely on include/driver.h including include/of.h (and
this including include/errno.h. include the files explicitly so we can
eventually get rid of including of.h from driver.h
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
To start synchronizing OF API of barebox with linux OF API, this adds
a length pointer to of_find_property. Also all current users of that
function are updated to reflect the API change.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
|
|
|
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>
|
