brain-hackers_pepepper-mirror/u-boot-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/u-boot-brain synced 2024-06-09 23:36:03 +09:00
Code Issues Projects Releases Wiki Activity
brain
u-boot-brain/drivers/pinctrl/pinctrl-generic.c

421 lines
11 KiB
C
Raw Permalink 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-07 06:58:06 +09: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 12:44:29 +09:00
/*
* Copyright (C) 2015 Masahiro Yamada <yamada.masahiro@socionext.com>
*/
#include <common.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-18 08:18:03 +09:00
#include <dm.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 23:36:16 +09:00
#include <dm/device_compat.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 12:44:29 +09:00
#include <linux/compat.h>
#include <dm/pinctrl.h>
/**
* pinctrl_pin_name_to_selector() - return the pin selector for a pin
*
* @dev: pin controller device
* @pin: the pin name to look up
* @return: pin selector, or negative error code on failure
*/
static int pinctrl_pin_name_to_selector(struct udevice *dev, const char *pin)
{
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
unsigned npins, selector;
if (!ops->get_pins_count || !ops->get_pin_name) {
dev_dbg(dev, "get_pins_count or get_pin_name missing\n");
return -ENOSYS;
}
npins = ops->get_pins_count(dev);
/* See if this pctldev has this pin */
for (selector = 0; selector < npins; selector++) {
const char *pname = ops->get_pin_name(dev, selector);
if (!strcmp(pin, pname))
return selector;
}
return -ENOSYS;
}
/**
* pinctrl_group_name_to_selector() - return the group selector for a group
*
* @dev: pin controller device
* @group: the pin group name to look up
* @return: pin group selector, or negative error code on failure
*/
static int pinctrl_group_name_to_selector(struct udevice *dev,
const char *group)
{
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
unsigned ngroups, selector;
if (!ops->get_groups_count || !ops->get_group_name) {
dev_dbg(dev, "get_groups_count or get_group_name missing\n");
return -ENOSYS;
}
ngroups = ops->get_groups_count(dev);
/* See if this pctldev has this group */
for (selector = 0; selector < ngroups; selector++) {
const char *gname = ops->get_group_name(dev, selector);
if (!strcmp(group, gname))
return selector;
}
return -ENOSYS;
}
#if CONFIG_IS_ENABLED(PINMUX)
/**
* pinmux_func_name_to_selector() - return the function selector for a function
*
* @dev: pin controller device
* @function: the function name to look up
* @return: function selector, or negative error code on failure
*/
static int pinmux_func_name_to_selector(struct udevice *dev,
const char *function)
{
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
unsigned nfuncs, selector = 0;
if (!ops->get_functions_count || !ops->get_function_name) {
dev_dbg(dev,
"get_functions_count or get_function_name missing\n");
return -ENOSYS;
}
nfuncs = ops->get_functions_count(dev);
/* See if this pctldev has this function */
for (selector = 0; selector < nfuncs; selector++) {
const char *fname = ops->get_function_name(dev, selector);
if (!strcmp(function, fname))
return selector;
}
return -ENOSYS;
}
/**
* pinmux_enable_setting() - enable pin-mux setting for a certain pin/group
*
* @dev: pin controller device
* @is_group: target of operation (true: pin group, false: pin)
* @selector: pin selector or group selector, depending on @is_group
* @func_selector: function selector
* @return: 0 on success, or negative error code on failure
*/
static int pinmux_enable_setting(struct udevice *dev, bool is_group,
unsigned selector, unsigned func_selector)
{
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
if (is_group) {
if (!ops->pinmux_group_set) {
dev_dbg(dev, "pinmux_group_set op missing\n");
return -ENOSYS;
}
return ops->pinmux_group_set(dev, selector, func_selector);
} else {
if (!ops->pinmux_set) {
dev_dbg(dev, "pinmux_set op missing\n");
return -ENOSYS;
}
return ops->pinmux_set(dev, selector, func_selector);
}
}
#else
static int pinmux_func_name_to_selector(struct udevice *dev,
const char *function)
{
return 0;
}
static int pinmux_enable_setting(struct udevice *dev, bool is_group,
unsigned selector, unsigned func_selector)
{
return 0;
}
#endif
#if CONFIG_IS_ENABLED(PINCONF)
/**
* pinconf_prop_name_to_param() - return parameter ID for a property name
*
* @dev: pin controller device
* @property: property name in DTS, such as "bias-pull-up", "slew-rate", etc.
* @default_value: return default value in case no value is specified in DTS
* @return: return pamater ID, or negative error code on failure
*/
static int pinconf_prop_name_to_param(struct udevice *dev,
const char *property, u32 *default_value)
{
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
const struct pinconf_param *p, *end;
if (!ops->pinconf_num_params || !ops->pinconf_params) {
dev_dbg(dev, "pinconf_num_params or pinconf_params missing\n");
return -ENOSYS;
}
p = ops->pinconf_params;
end = p + ops->pinconf_num_params;
/* See if this pctldev supports this parameter */
for (; p < end; p++) {
if (!strcmp(property, p->property)) {
*default_value = p->default_value;
return p->param;
}
}
return -ENOSYS;
}
/**
* pinconf_enable_setting() - apply pin configuration for a certain pin/group
*
* @dev: pin controller device
* @is_group: target of operation (true: pin group, false: pin)
* @selector: pin selector or group selector, depending on @is_group
* @param: configuration paramter
* @argument: argument taken by some configuration parameters
* @return: 0 on success, or negative error code on failure
*/
static int pinconf_enable_setting(struct udevice *dev, bool is_group,
unsigned selector, unsigned param,
u32 argument)
{
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
if (is_group) {
if (!ops->pinconf_group_set) {
dev_dbg(dev, "pinconf_group_set op missing\n");
return -ENOSYS;
}
return ops->pinconf_group_set(dev, selector, param,
argument);
} else {
if (!ops->pinconf_set) {
dev_dbg(dev, "pinconf_set op missing\n");
return -ENOSYS;
}
return ops->pinconf_set(dev, selector, param, argument);
}
}
#else
static int pinconf_prop_name_to_param(struct udevice *dev,
const char *property, u32 *default_value)
{
return -ENOSYS;
}
static int pinconf_enable_setting(struct udevice *dev, bool is_group,
unsigned selector, unsigned param,
u32 argument)
{
return 0;
}
#endif
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
enum pinmux_subnode_type {
PST_NONE = 0,
PST_PIN,
PST_GROUP,
PST_PINMUX,
};
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 12:44:29 +09:00
/**
* pinctrl_generic_set_state_one() - set state for a certain pin/group
* Apply all pin multiplexing and pin configurations specified by @config
* for a given pin or pin group.
*
* @dev: pin controller device
* @config: pseudo device pointing to config node
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
* @subnode_type: target of operation (pin, group, or pin specified by a pinmux
* group)
* @selector: pin selector or group selector, depending on @subnode_type
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 12:44:29 +09:00
* @return: 0 on success, or negative error code on failure
*/
static int pinctrl_generic_set_state_one(struct udevice *dev,
struct udevice *config,
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
enum pinmux_subnode_type subnode_type,
unsigned 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 12:44:29 +09:00
{
const char *propname;
const void *value;
dm: pinctrl: migrate pinctrl-generic to livetree Migrate pinctrl-generic to livetree: - dev_for_each_property - dev_read_prop_by_prop - dev_read_string_count - dev_read_string_index and get rid of DECLARE_GLOBAL_DATA_PTR. This patch solves the parsing issue during sandbox tests for pin configuration (OF_LIVE is activated in sandbox_defconfig and sub node are not correctly parsed in pinctrl_generic_set_state_subnode with fdt lib API). Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 19:34:57 +09:00
struct ofprop property;
int len, func_selector, param, 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 12:44:29 +09:00
u32 arg, default_val;
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
assert(subnode_type != PST_NONE);
dm: pinctrl: migrate pinctrl-generic to livetree Migrate pinctrl-generic to livetree: - dev_for_each_property - dev_read_prop_by_prop - dev_read_string_count - dev_read_string_index and get rid of DECLARE_GLOBAL_DATA_PTR. This patch solves the parsing issue during sandbox tests for pin configuration (OF_LIVE is activated in sandbox_defconfig and sub node are not correctly parsed in pinctrl_generic_set_state_subnode with fdt lib API). Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-01-13 19:34:57 +09:00
dev_for_each_property(property, config) {
value = dev_read_prop_by_prop(&property, &propname, &len);
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 12:44:29 +09:00
if (!value)
return -EINVAL;
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
/* pinmux subnodes already have their muxing set */
if (subnode_type != PST_PINMUX &&
!strcmp(propname, "function")) {
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 12:44:29 +09:00
func_selector = pinmux_func_name_to_selector(dev,
value);
if (func_selector < 0)
return func_selector;
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
ret = pinmux_enable_setting(dev,
subnode_type == PST_GROUP,
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 12:44:29 +09:00
selector,
func_selector);
} else {
param = pinconf_prop_name_to_param(dev, propname,
&default_val);
if (param < 0)
continue; /* just skip unknown properties */
if (len >= sizeof(fdt32_t))
arg = fdt32_to_cpu(*(fdt32_t *)value);
else
arg = default_val;
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
ret = pinconf_enable_setting(dev,
subnode_type == PST_GROUP,
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 12:44:29 +09:00
selector, param, arg);
}
if (ret)
return ret;
}
return 0;
}
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
/**
* pinctrl_generic_get_subnode_type() - determine whether there is a valid
* pins, groups, or pinmux property in the config node
*
* @dev: pin controller device
* @config: pseudo device pointing to config node
* @count: number of specifiers contained within the property
* @return: the type of the subnode, or PST_NONE
*/
static enum pinmux_subnode_type pinctrl_generic_get_subnode_type(struct udevice *dev,
struct udevice *config,
int *count)
{
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
*count = dev_read_string_count(config, "pins");
if (*count >= 0)
return PST_PIN;
*count = dev_read_string_count(config, "groups");
if (*count >= 0)
return PST_GROUP;
if (ops->pinmux_property_set) {
*count = dev_read_size(config, "pinmux");
if (*count >= 0 && !(*count % sizeof(u32))) {
*count /= sizeof(u32);
return PST_PINMUX;
}
}
*count = 0;
return PST_NONE;
}
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 12:44:29 +09:00
/**
* pinctrl_generic_set_state_subnode() - apply all settings in config node
*
* @dev: pin controller device
* @config: pseudo device pointing to config node
* @return: 0 on success, or negative error code on failure
*/
static int pinctrl_generic_set_state_subnode(struct udevice *dev,
struct udevice *config)
{
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
enum pinmux_subnode_type subnode_type;
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 12:44:29 +09:00
const char *name;
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
int count, selector, i, ret, scratch;
const u32 *pinmux_groups = NULL; /* prevent use-uninitialized warning */
subnode_type = pinctrl_generic_get_subnode_type(dev, config, &count);
debug("%s(%s, %s): count=%d\n", __func__, dev->name, config->name,
count);
if (subnode_type == PST_PINMUX) {
pinmux_groups = dev_read_prop(config, "pinmux", &scratch);
if (!pinmux_groups)
return -EINVAL;
}
for (i = 0; i < count; i++) {
switch (subnode_type) {
case PST_PIN:
ret = dev_read_string_index(config, "pins", i, &name);
if (ret)
return ret;
selector = pinctrl_pin_name_to_selector(dev, name);
break;
case PST_GROUP:
ret = dev_read_string_index(config, "groups", i, &name);
if (ret)
return ret;
selector = pinctrl_group_name_to_selector(dev, name);
break;
case PST_PINMUX: {
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
u32 pinmux_group = fdt32_to_cpu(pinmux_groups[i]);
/* Checked for in pinctrl_generic_get_subnode_type */
selector = ops->pinmux_property_set(dev, pinmux_group);
break;
}
case PST_NONE:
default:
pinctrl: generic: scan for "pins" and "groups" properties in sub-nodes In cases where the pins and groups definitions are in a sub-node, as: uart_a { mux { groups = "uart_tx_a", "uart_rx_a"; function = "uart_a"; }; }; pinctrl_generic_set_state_subnode() returns an error for the top-level node and pinctrl_generic_set_state() fails. Instead, return success so that the child nodes are tried. Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-08-16 18:49:47 +09:00
/* skip this node; may contain config child nodes */
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 12:44:29 +09:00
if (selector < 0)
return selector;
pinctrl: Add pinmux property support to pinctrl-generic The pinmux property allows for smaller and more compact device trees, especially when there are many pins which need to be assigned individually. Instead of specifying an array of strings to be parsed as pins and a function property, the pinmux property contains an array of integers representing pinmux groups. A pinmux group consists of the pin identifier and mux settings represented as a single integer or an array of integers. Each individual pin controller driver specifies the exact format of a pinmux group. As specified in the Linux documentation, a pinmux group may be multiple integers long. However, no existing drivers use multi-integer pinmux groups, so I have chosen to omit this feature. This makes the implementation easier, since there is no need to allocate a buffer to do endian conversions. Support for the pinmux property is done differently than in Linux. As far as I can tell, inversion of control is used when implementing support for the pins and groups properties to avoid allocating. This results in some duplication of effort; every property in a config node is parsed once for each pin in that node. This is not such an overhead with pins and groups properties, since having multiple pins in one config node does not occur especially often. However, the semantics of the pinmux property make such a configuration much more appealing. A future patch could parse all config properties at once and store them in an array. This would make it easier to create drivers which do not function solely as callbacks from pinctrl-generic. This commit increases the size of the sandbox build by approximately 48 bytes. However, it also decreases the size of the K210 device tree by 2 KiB from the previous version of this series. The documentation has been updated from the last Linux commit before it was split off into yaml files. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-15 00:01:55 +09:00
ret = pinctrl_generic_set_state_one(dev, config, subnode_type,
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 12:44:29 +09:00
if (ret)
return ret;
}
return 0;
}
int pinctrl_generic_set_state(struct udevice *dev, struct udevice *config)
{
struct udevice *child;
int ret;
ret = pinctrl_generic_set_state_subnode(dev, config);
if (ret)
return ret;
for (device_find_first_child(config, &child);
child;
device_find_next_child(&child)) {
ret = pinctrl_generic_set_state_subnode(dev, child);
if (ret)
return ret;
}
return 0;
}
Reference in New Issue Copy Permalink