Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-17 10:18:38 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/pinctrl/pinctrl-uclass.c

437 lines
9.8 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
// SPDX-License-Identifier: GPL-2.0+
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
/*
* Copyright (C) 2015 Masahiro Yamada <yamada.masahiro@socionext.com>
*/
dm: define LOG_CATEGORY for all uclass Define LOG_CATEGORY for all uclass to allow filtering with log command. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-04-27 09:02:19 +00:00
#define LOG_CATEGORY UCLASS_PINCTRL
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
#include <common.h>
dm: core: Create a new header file for 'compat' features At present dm/device.h includes the linux-compatible features. This requires including linux/compat.h which in turn includes a lot of headers. One of these is malloc.h which we thus end up including in every file in U-Boot. Apart from the inefficiency of this, it is problematic for sandbox which needs to use the system malloc() in some files. Move the compatibility features into a separate header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-03 14:36:16 +00:00
#include <malloc.h>
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-10-31 03:38:53 +00:00
#include <asm/global_data.h>
dm: core: Create a new header file for 'compat' features At present dm/device.h includes the linux-compatible features. This requires including linux/compat.h which in turn includes a lot of headers. One of these is malloc.h which we thus end up including in every file in U-Boot. Apart from the inefficiency of this, it is problematic for sandbox which needs to use the system malloc() in some files. Move the compatibility features into a separate header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-03 14:36:16 +00:00
#include <dm/device_compat.h>
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-04 16:20:11 +00:00
#include <linux/libfdt.h>
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
#include <linux/err.h>
#include <linux/list.h>
dm: Use dm.h header when driver mode is used This header includes things that are needed to make driver build. Adjust existing users to include that always, even if other dm/ includes are present Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-17 23:18:03 +00:00
#include <dm.h>
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
#include <dm/lists.h>
#include <dm/pinctrl.h>
dm: allow limiting pre-reloc markings to spl or tpl Right now the u-boot,dm-pre-reloc flag will make each marked node always appear in both spl and tpl. But systems needing an additional tpl might have special constraints for each, like the spl needing to be very tiny. So introduce two additional flags to mark nodes for only spl or tpl environments and introduce a function dm_fdt_pre_reloc to automate the necessary checks in code instances checking for pre-relocation flags. The behaviour of the original flag stays untouched and still marks a node for both spl and tpl. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Kever Yang <kever.yang@rock-chips.com>
2017-02-18 18:46:21 +00:00
#include <dm/util.h>
pinctrl-uclass: convert to use live dt Use live dt interface for pinctrl_select_state_full() Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2018-02-09 02:56:24 +00:00
#include <dm/of_access.h>
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
DECLARE_GLOBAL_DATA_PTR;
#if CONFIG_IS_ENABLED(PINCTRL_FULL)
/**
* pinctrl_config_one() - apply pinctrl settings for a single node
*
* @config: pin configuration node
* @return: 0 on success, or negative error code on failure
*/
static int pinctrl_config_one(struct udevice *config)
{
struct udevice *pctldev;
const struct pinctrl_ops *ops;
pctldev = config;
for (;;) {
pctldev = dev_get_parent(pctldev);
if (!pctldev) {
dev_err(config, "could not find pctldev\n");
return -EINVAL;
}
if (pctldev->uclass->uc_drv->id == UCLASS_PINCTRL)
break;
}
ops = pinctrl_get_ops(pctldev);
return ops->set_state(pctldev, config);
}
/**
* pinctrl_select_state_full() - full implementation of pinctrl_select_state
*
* @dev: peripheral device
* @statename: state name, like "default"
* @return: 0 on success, or negative error code on failure
*/
static int pinctrl_select_state_full(struct udevice *dev, const char *statename)
{
char propname[32]; /* long enough */
const fdt32_t *list;
uint32_t phandle;
struct udevice *config;
int state, size, i, ret;
pinctrl-uclass: convert to use live dt Use live dt interface for pinctrl_select_state_full() Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2018-02-09 02:56:24 +00:00
state = dev_read_stringlist_search(dev, "pinctrl-names", statename);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (state < 0) {
char *end;
/*
* If statename is not found in "pinctrl-names",
* assume statename is just the integer state ID.
*/
global: Convert simple_strtoul() with decimal to dectoul() It is a pain to have to specify the value 10 in each call. Add a new dectoul() function and update the code to use it. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-07-24 15:03:30 +00:00
state = dectoul(statename, &end);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (*end)
return -EINVAL;
}
snprintf(propname, sizeof(propname), "pinctrl-%d", state);
pinctrl-uclass: convert to use live dt Use live dt interface for pinctrl_select_state_full() Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2018-02-09 02:56:24 +00:00
list = dev_read_prop(dev, propname, &size);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (!list)
return -EINVAL;
size /= sizeof(*list);
for (i = 0; i < size; i++) {
phandle = fdt32_to_cpu(*list++);
pinctrl-uclass: convert to use live dt Use live dt interface for pinctrl_select_state_full() Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2018-02-09 02:56:24 +00:00
ret = uclass_get_device_by_phandle_id(UCLASS_PINCONFIG, phandle,
&config);
dm: pinctrl: Skip not associated gpio phandle and rise a warning message Skip not associated gpio phandle let register the other gpios on a group. We need anyway to send out a warning to the user to fix their uboot-board.dtsi. Thhe handle id can be found inside the decompiled dtb dtc -I dtb -O dts -o devicetree.dts spl/u-boot-spl.dtb Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-09-17 20:06:03 +00:00
if (ret) {
dev_warn(dev, "%s: uclass_get_device_by_phandle_id: err=%d\n",
__func__, ret);
continue;
}
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
ret = pinctrl_config_one(config);
dm: pinctrl: Skip not associated gpio phandle and rise a warning message Skip not associated gpio phandle let register the other gpios on a group. We need anyway to send out a warning to the user to fix their uboot-board.dtsi. Thhe handle id can be found inside the decompiled dtb dtc -I dtb -O dts -o devicetree.dts spl/u-boot-spl.dtb Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-09-17 20:06:03 +00:00
if (ret) {
dev_warn(dev, "%s: pinctrl_config_one: err=%d\n",
__func__, ret);
continue;
}
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
}
return 0;
}
/**
pinctrl: fix typos in comment blocks of pinconfig_post_bind() '-' is never used in function names. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-08-19 09:26:54 +00:00
* pinconfig_post_bind() - post binding for PINCONFIG uclass
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
* Recursively bind its children as pinconfig devices.
*
* @dev: pinconfig device
* @return: 0 on success, or negative error code on failure
*/
static int pinconfig_post_bind(struct udevice *dev)
{
pinctrl: Avoid binding all pinconfig nodes before relocation This can create a large number of pinctrl devices. It chews up early malloc() memory and takes time. Only bind those which are marked as needed before relocation. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-12-29 12:22:52 +00:00
bool pre_reloc_only = !(gd->flags & GD_FLG_RELOC);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
const char *name;
dm: core: Update device_bind_driver_to_node() to use ofnode Adjust this function to us an ofnode instead of an offset, so it can be used with livetree. This involves updating all callers. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-19 02:09:07 +00:00
ofnode node;
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int ret;
dm: core: Use dev_has_ofnode() instead of dev_of_valid() We have two functions which do the same thing. Standardise on dev_has_ofnode() since there is no such thing as an 'invalid' ofnode in normal operation: it is either null or missing. Also move the functions into one place. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-12-19 17:40:13 +00:00
if (!dev_has_ofnode(dev))
pinctrl: exit pinconfig_post_bind if there are no subnodes This fixes RK3288 SPL hanging or hitting this assert: drivers/core/ofnode.c:183: ofnode_first_subnode: Assertion `ofnode_valid(node)' failed. Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2019-03-22 19:14:33 +00:00
return 0;
dm: core: Update device_bind_driver_to_node() to use ofnode Adjust this function to us an ofnode instead of an offset, so it can be used with livetree. This involves updating all callers. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-19 02:09:07 +00:00
dev_for_each_subnode(node, dev) {
Revert "dm: pinctrl: Prevent (re-)configuring pins when already done before relocation" This reverts commit a7f4b4b344396590845e6552c82829ef68ef9f89. As reported by Alex Kiernan the above optimization introduces a regression in the below use case where: 1. Device has defined 'u-boot,dm-spl' property (@ eMMC DTS node) 2. The device downloads its MLO/SPL via UART (not eMMC - the eMMC pinmux pins are NOT probed/configured in MLO/SPL). 3. The loaded via UART MLO/SPL wants to load Linux from eMMC. In this case the DM core and pinctrl uclass checks 'u-boot,dm-spl' and don't configure pins (as it thinks that those were initialized in MLO/SPL). As we are very close to release - please revert this commit. Reported-by: Alex Kiernan <alex.kiernan@gmail.com> Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-01-09 22:05:02 +00:00
if (pre_reloc_only &&
!ofnode_pre_reloc(node))
pinctrl: Avoid binding all pinconfig nodes before relocation This can create a large number of pinctrl devices. It chews up early malloc() memory and takes time. Only bind those which are marked as needed before relocation. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-12-29 12:22:52 +00:00
continue;
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
/*
* If this node has "compatible" property, this is not
* a pin configuration node, but a normal device. skip.
*/
dm: ofnode: rename ofnode_read_prop() to ofnode_get_property() This function returns the pointer to the value of a node property. The current name ofnode_read_prop() is confusing. Follow the naming of_get_property() from Linux. The return type (const u32 *) is wrong. DT property values can be strings as well as integers. This is why of_get_property/fdt_getprop returns an opaque pointer. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2017-06-22 07:54:05 +00:00
ofnode_get_property(node, "compatible", &ret);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (ret >= 0)
continue;
dm: pinctrl: Skip gpio-controller node in pinconfig_post_bind() Some binding define child node gpio-controller without compatible property. This patch avoid to bind the pinconfig uclass to these node. For example, the binding for st,stm32-pinctrl (./device-tree-bindings/pinctrl/st,stm32-pinctrl.txt) defines the GPIO controller/bank node as sub-node of pincontrol (st,stm32f429-pinctrl) but without compatible (as it is not mandatory). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-02-25 12:39:56 +00:00
/* If this node has "gpio-controller" property, skip */
if (ofnode_read_bool(node, "gpio-controller"))
continue;
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (ret != -FDT_ERR_NOTFOUND)
return ret;
dm: core: Update device_bind_driver_to_node() to use ofnode Adjust this function to us an ofnode instead of an offset, so it can be used with livetree. This involves updating all callers. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-19 02:09:07 +00:00
name = ofnode_get_name(node);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (!name)
return -EINVAL;
ret = device_bind_driver_to_node(dev, "pinconfig", name,
dm: core: Update device_bind_driver_to_node() to use ofnode Adjust this function to us an ofnode instead of an offset, so it can be used with livetree. This involves updating all callers. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-19 02:09:07 +00:00
node, NULL);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (ret)
return ret;
}
return 0;
}
UCLASS_DRIVER(pinconfig) = {
.id = UCLASS_PINCONFIG,
dm: pinctrl: fix for introduce PINCONF_RECURSIVE option Correct the name of the define used CONFIG_IS_ENABLED which is not aligned with Kconfig name: CONFIG_$(SPL_)PINCONF_RECURSIVE. The recursive calls is conditional only for UCLASS_PINCONFIG "pinconfig" driver. It is always needed to call pinctrl_post_bind for UCLASS_PINCTRL "pinctrl", the test CONFIG_IS_ENABLED(PINCONF_RECURSIVE) need to be removed for this driver. This correct a regression introduced because the same patch is applied twice times in u-boot-dm branch: - commit e878b53a79d1 ("dm: pinctrl: introduce PINCONF_RECURSIVE option") - commit c20851b3d850 ("dm: pinctrl: introduce PINCONF_RECURSIVE option") Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-10-21 13:02:40 +00:00
#if CONFIG_IS_ENABLED(PINCONF_RECURSIVE)
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
.post_bind = pinconfig_post_bind,
dm: pinctrl: introduce PINCONF_RECURSIVE option In the Linux pinctrl binding, the pin configuration nodes don't need to be direct children of the pin controller device (may be grandchildren for example). This behavior is managed with the pinconfig u-class which recursively bind all the sub-node of the pin controller. But for some binding (when pin configuration is only children of pin controller) that is not necessary. U-Boot can save memory and reduce the number of pinconf instance when this feature is deactivated (for arch stm32mp for example for SPL). This patch allows to control this feature with a new option CONFIG_PINCONF_RECURSIVE when it is possible for each individual pin controller device. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-08-02 12:48:00 +00:00
#endif
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
.name = "pinconfig",
};
U_BOOT_DRIVER(pinconfig_generic) = {
.name = "pinconfig",
.id = UCLASS_PINCONFIG,
};
#else
static int pinctrl_select_state_full(struct udevice *dev, const char *statename)
{
return -ENODEV;
}
static int pinconfig_post_bind(struct udevice *dev)
{
pinctrl: move dm_scan_fdt_node() out of pinctrl uclass Commit c5acf4a2b3c6 ("pinctrl: Add the concept of peripheral IDs") added some additional change that was not mentioned in the git-log. That commit added dm_scan_fdt_node() in the pinctrl uclass binding. It should be handled by the simple-bus driver or the low-level driver, not by the pinctrl framework. I guess Simon's motivation was to bind GPIO banks located under the Rockchip pinctrl device. It is true some chips have sub-devices under their pinctrl devices, but it is basically SoC-specific matter. This commit partly reverts commit c5acf4a2b3c6 to keep the only pinctrl-generic features in the uclass. The dm_scan_fdt_node() should be called from the rk3288_pinctrl driver. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2015-09-05 16:44:50 +00:00
return 0;
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
}
#endif
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
static int
pinctrl_gpio_get_pinctrl_and_offset(struct udevice *dev, unsigned offset,
struct udevice **pctldev,
unsigned int *pin_selector)
{
struct ofnode_phandle_args args;
unsigned gpio_offset, pfc_base, pfc_pins;
int ret;
ret = dev_read_phandle_with_args(dev, "gpio-ranges", NULL, 3,
0, &args);
if (ret) {
dev_dbg(dev, "%s: dev_read_phandle_with_args: err=%d\n",
__func__, ret);
return ret;
}
ret = uclass_get_device_by_ofnode(UCLASS_PINCTRL,
args.node, pctldev);
if (ret) {
dev_dbg(dev,
"%s: uclass_get_device_by_of_offset failed: err=%d\n",
__func__, ret);
return ret;
}
gpio_offset = args.args[0];
pfc_base = args.args[1];
pfc_pins = args.args[2];
if (offset < gpio_offset || offset > gpio_offset + pfc_pins) {
dev_dbg(dev,
"%s: GPIO can not be mapped to pincontrol pin\n",
__func__);
return -EINVAL;
}
offset -= gpio_offset;
offset += pfc_base;
*pin_selector = offset;
return 0;
}
/**
* pinctrl_gpio_request() - request a single pin to be used as GPIO
*
* @dev: GPIO peripheral device
* @offset: the GPIO pin offset from the GPIO controller
* @return: 0 on success, or negative error code on failure
*/
int pinctrl_gpio_request(struct udevice *dev, unsigned offset)
{
const struct pinctrl_ops *ops;
struct udevice *pctldev;
unsigned int pin_selector;
int ret;
ret = pinctrl_gpio_get_pinctrl_and_offset(dev, offset,
&pctldev, &pin_selector);
if (ret)
return ret;
ops = pinctrl_get_ops(pctldev);
pinctrl: Return -ENOSYS when system call is not available Update the code to use -ENOSYS, which is the correct error code for an unimplemented system call in U-Boot. Also we should not check for a missing operations array as this is not permitted. For now this can be covered by an assert(). Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-24 21:26:11 +00:00
assert(ops);
if (!ops->gpio_request_enable)
return -ENOSYS;
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
return ops->gpio_request_enable(pctldev, pin_selector);
}
/**
* pinctrl_gpio_free() - free a single pin used as GPIO
*
* @dev: GPIO peripheral device
* @offset: the GPIO pin offset from the GPIO controller
* @return: 0 on success, or negative error code on failure
*/
int pinctrl_gpio_free(struct udevice *dev, unsigned offset)
{
const struct pinctrl_ops *ops;
struct udevice *pctldev;
unsigned int pin_selector;
int ret;
ret = pinctrl_gpio_get_pinctrl_and_offset(dev, offset,
&pctldev, &pin_selector);
if (ret)
return ret;
ops = pinctrl_get_ops(pctldev);
pinctrl: Return -ENOSYS when system call is not available Update the code to use -ENOSYS, which is the correct error code for an unimplemented system call in U-Boot. Also we should not check for a missing operations array as this is not permitted. For now this can be covered by an assert(). Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-24 21:26:11 +00:00
assert(ops);
if (!ops->gpio_disable_free)
return -ENOSYS;
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
return ops->gpio_disable_free(pctldev, pin_selector);
}
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
/**
* pinctrl_select_state_simple() - simple implementation of pinctrl_select_state
*
* @dev: peripheral device
* @return: 0 on success, or negative error code on failure
*/
static int pinctrl_select_state_simple(struct udevice *dev)
{
struct udevice *pctldev;
struct pinctrl_ops *ops;
int ret;
/*
dm: pinctrl: Avoid race condition on probe for UCLASS_PINCTRL In case of system with several pin-controller device, probe the first UCLASS_PINCTRL by seq number (defined by alias) to avoid race condition with I2C PINCONTROL driver for GPIO expander (GPIO expander need I2C bus, I2C driver need PINCONFIG). Signed-off-by: Patrick DELAUNAY <patrick.delaunay@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-02-25 12:39:55 +00:00
* For most system, there is only one pincontroller device. But in
* case of multiple pincontroller devices, probe the one with sequence
* number 0 (defined by alias) to avoid race condition.
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
*/
dm: pinctrl: Avoid race condition on probe for UCLASS_PINCTRL In case of system with several pin-controller device, probe the first UCLASS_PINCTRL by seq number (defined by alias) to avoid race condition with I2C PINCONTROL driver for GPIO expander (GPIO expander need I2C bus, I2C driver need PINCONFIG). Signed-off-by: Patrick DELAUNAY <patrick.delaunay@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-02-25 12:39:55 +00:00
ret = uclass_get_device_by_seq(UCLASS_PINCTRL, 0, &pctldev);
if (ret)
/* if not found, get the first one */
ret = uclass_get_device(UCLASS_PINCTRL, 0, &pctldev);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (ret)
return ret;
ops = pinctrl_get_ops(pctldev);
if (!ops->set_state_simple) {
dev_dbg(dev, "set_state_simple op missing\n");
return -ENOSYS;
}
return ops->set_state_simple(pctldev, dev);
}
int pinctrl_select_state(struct udevice *dev, const char *statename)
{
pinctrl: do not set_state for device without valid ofnode Not all the udevice have a available DT node, eg. rksdmmc@ff500000.blk which add by mmc_bind(), these device do not have/need set pinctrl state. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-04-18 09:54:04 +00:00
/*
* Some device which is logical like mmc.blk, do not have
* a valid ofnode.
*/
dm: core: Rename dev_has_of_node() to dev_has_ofnode() We use 'ofnode' rather than 'of_node' in U-Boot. Rename this function to fit. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19 17:40:12 +00:00
if (!dev_has_ofnode(dev))
pinctrl: do not set_state for device without valid ofnode Not all the udevice have a available DT node, eg. rksdmmc@ff500000.blk which add by mmc_bind(), these device do not have/need set pinctrl state. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-04-18 09:54:04 +00:00
return 0;
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
/*
* Try full-implemented pinctrl first.
* If it fails or is not implemented, try simple one.
*/
if (pinctrl_select_state_full(dev, statename))
return pinctrl_select_state_simple(dev);
return 0;
}
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
int pinctrl_request(struct udevice *dev, int func, int flags)
{
struct pinctrl_ops *ops = pinctrl_get_ops(dev);
if (!ops->request)
return -ENOSYS;
return ops->request(dev, func, flags);
}
int pinctrl_request_noflags(struct udevice *dev, int func)
{
return pinctrl_request(dev, func, 0);
}
int pinctrl_get_periph_id(struct udevice *dev, struct udevice *periph)
{
struct pinctrl_ops *ops = pinctrl_get_ops(dev);
if (!ops->get_periph_id)
return -ENOSYS;
return ops->get_periph_id(dev, periph);
}
dm: pinctrl: Add a way for a GPIO driver to obtain a pin function GPIO drivers want to be able to show if a pin is enabled for input, output, or is being used by another function. Some drivers can easily find this and the code is included in the driver. For some SoCs this is more complex. Conceptually this should be handled by pinctrl rather than GPIO. Most pinctrl drivers will have this feature anyway. Add a method by which a GPIO driver can obtain the pin mux value given a GPIO reference. This avoids repeating the code in two places. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:56 +00:00
int pinctrl_get_gpio_mux(struct udevice *dev, int banknum, int index)
{
struct pinctrl_ops *ops = pinctrl_get_ops(dev);
if (!ops->get_gpio_mux)
return -ENOSYS;
return ops->get_gpio_mux(dev, banknum, index);
}
dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods to obtain pin's name and pin's muxing given a pin reference. This will be used by the new pinmux command. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:14 +00:00
int pinctrl_get_pins_count(struct udevice *dev)
{
struct pinctrl_ops *ops = pinctrl_get_ops(dev);
if (!ops->get_pins_count)
return -ENOSYS;
return ops->get_pins_count(dev);
}
int pinctrl_get_pin_name(struct udevice *dev, int selector, char *buf,
int size)
{
struct pinctrl_ops *ops = pinctrl_get_ops(dev);
if (!ops->get_pin_name)
return -ENOSYS;
snprintf(buf, size, ops->get_pin_name(dev, selector));
return 0;
}
dm: pinctrl: Add get_pin_muxing() ops Add get_pin_muxing() which allows to display the muxing of a given pin belonging to a pin-controller. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:13 +00:00
int pinctrl_get_pin_muxing(struct udevice *dev, int selector, char *buf,
int size)
{
struct pinctrl_ops *ops = pinctrl_get_ops(dev);
if (!ops->get_pin_muxing)
return -ENOSYS;
return ops->get_pin_muxing(dev, selector, buf, size);
}
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
/**
pinctrl: fix typos in comment blocks of pinconfig_post_bind() '-' is never used in function names. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-08-19 09:26:54 +00:00
* pinconfig_post_bind() - post binding for PINCTRL uclass
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
* Recursively bind child nodes as pinconfig devices in case of full pinctrl.
*
* @dev: pinctrl device
* @return: 0 on success, or negative error code on failure
*/
dm: pinctrl: introduce PINCONF_RECURSIVE option In the Linux pinctrl binding, the pin configuration nodes don't need to be direct children of the pin controller device (may be grandchildren for example). This behavior is managed with the pinconfig u-class which recursively bind all the sub-node of the pin controller. But for some binding (when pin configuration is only children of pin controller) that is not necessary. U-Boot can save memory and reduce the number of pinconf instance when this feature is deactivated (for arch stm32mp for example for SPL). This patch allows to control this feature with a new option CONFIG_PINCONF_RECURSIVE when it is possible for each individual pin controller device. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org> Fixed CONFIG_IF_ENABLED() condition, added __maybe_unused: Signed-off-by: Simon Glass <sjg@chromium.org>
2019-08-02 12:48:00 +00:00
static int __maybe_unused pinctrl_post_bind(struct udevice *dev)
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
{
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
pinctrl: probe pinctrl drivers during post-bind Currently, pinctrl drivers only get probed if pinconf is actually being used, however on SoC-s like Armada 3720 pinctrl driver is a also the GPIO driver. So, if the pinctrl driver doesn't get probed GPIO-s won't get registered and thus they cannot be used. This is a problem on the Methode eDPU as it just uses SB pins as GPIO-s and without them being registered networking won't work as it only has one SFP slot and the TX disable GPIO is on the SB controller. So, probe the pinctrl drivers using DM_FLAG_PROBE_AFTER_BIND like LED uclass does. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-05-06 18:01:39 +00:00
/*
* Make sure that the pinctrl driver gets probed after binding
* as some pinctrl drivers also register the GPIO driver during
* probe, and if they are not probed GPIO-s are not registered.
*/
dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
if (!ops) {
dev_dbg(dev, "ops is not set. Do not bind.\n");
return -EINVAL;
}
/*
pinctrl: move dm_scan_fdt_node() out of pinctrl uclass Commit c5acf4a2b3c6 ("pinctrl: Add the concept of peripheral IDs") added some additional change that was not mentioned in the git-log. That commit added dm_scan_fdt_node() in the pinctrl uclass binding. It should be handled by the simple-bus driver or the low-level driver, not by the pinctrl framework. I guess Simon's motivation was to bind GPIO banks located under the Rockchip pinctrl device. It is true some chips have sub-devices under their pinctrl devices, but it is basically SoC-specific matter. This commit partly reverts commit c5acf4a2b3c6 to keep the only pinctrl-generic features in the uclass. The dm_scan_fdt_node() should be called from the rk3288_pinctrl driver. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2015-09-05 16:44:50 +00:00
* If set_state callback is set, we assume this pinctrl driver is the
* full implementation. In this case, its child nodes should be bound
* so that peripheral devices can easily search in parent devices
* during later DT-parsing.
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
*/
pinctrl: move dm_scan_fdt_node() out of pinctrl uclass Commit c5acf4a2b3c6 ("pinctrl: Add the concept of peripheral IDs") added some additional change that was not mentioned in the git-log. That commit added dm_scan_fdt_node() in the pinctrl uclass binding. It should be handled by the simple-bus driver or the low-level driver, not by the pinctrl framework. I guess Simon's motivation was to bind GPIO banks located under the Rockchip pinctrl device. It is true some chips have sub-devices under their pinctrl devices, but it is basically SoC-specific matter. This commit partly reverts commit c5acf4a2b3c6 to keep the only pinctrl-generic features in the uclass. The dm_scan_fdt_node() should be called from the rk3288_pinctrl driver. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2015-09-05 16:44:50 +00:00
if (ops->set_state)
return pinconfig_post_bind(dev);
return 0;
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
}
UCLASS_DRIVER(pinctrl) = {
.id = UCLASS_PINCTRL,
treewide: Use OF_REAL instead of !OF_PLATDATA Now that we have a 'positive' Kconfig option, use this instead of the negative one, which is harder to understand. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-08-07 13:24:04 +00:00
#if CONFIG_IS_ENABLED(OF_REAL)
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
.post_bind = pinctrl_post_bind,
pinctrl: Drop post_bind() method when not needed This is not used with of-platdata, so remove it in that case. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-23 15:11:13 +00:00
#endif
pinctrl: add the DM_UC_FLAG_SEQ_ALIAS flag for numbering the devices It is possible to have multiple pin controllers in the system. Use the DM_UC_FLAG_SEQ_ALIAS flag so that the pinctrl instances are assigned a sequence number. Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2016-04-23 16:48:07 +00:00
.flags = DM_UC_FLAG_SEQ_ALIAS,
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
.name = "pinctrl",
};
Reference in a new issue Copy permalink