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>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <common.h>
|
2017-05-17 23:18:03 +00:00
|
|
|
#include <dm.h>
|
2020-02-03 14:36:16 +00: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 03:44:29 +00: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-14 15:01:55 +00:00
|
|
|
enum pinmux_subnode_type {
|
|
|
|
PST_NONE = 0,
|
|
|
|
PST_PIN,
|
|
|
|
PST_GROUP,
|
|
|
|
PST_PINMUX,
|
|
|
|
};
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
static const char *alloc_name_with_prefix(const char *name, const char *prefix)
|
|
|
|
{
|
|
|
|
if (prefix) {
|
2022-09-07 11:11:42 +00:00
|
|
|
char *name_with_prefix = malloc(strlen(prefix) + strlen(name) + 1);
|
2022-07-25 11:56:08 +00:00
|
|
|
if (name_with_prefix)
|
|
|
|
sprintf(name_with_prefix, "%s%s", prefix, name);
|
|
|
|
return name_with_prefix;
|
|
|
|
} else {
|
|
|
|
return name;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_name_with_prefix(const char *name_with_prefix, const char *prefix)
|
|
|
|
{
|
|
|
|
if (prefix)
|
|
|
|
free((char *)name_with_prefix);
|
|
|
|
}
|
|
|
|
|
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_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-14 15:01:55 +00: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 03:44:29 +00:00
|
|
|
* @return: 0 on success, or negative error code on failure
|
|
|
|
*/
|
|
|
|
static int pinctrl_generic_set_state_one(struct udevice *dev,
|
|
|
|
struct udevice *config,
|
2022-07-25 11:56:08 +00:00
|
|
|
const char *prefix,
|
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-14 15:01:55 +00: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 03:44:29 +00:00
|
|
|
{
|
2022-07-25 11:56:08 +00:00
|
|
|
const char *function_propname;
|
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 *propname;
|
|
|
|
const void *value;
|
2020-01-13 10:34:57 +00: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 03:44:29 +00: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-14 15:01:55 +00:00
|
|
|
assert(subnode_type != PST_NONE);
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
function_propname = alloc_name_with_prefix("function", prefix);
|
|
|
|
if (!function_propname)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2020-01-13 10:34:57 +00:00
|
|
|
dev_for_each_property(property, config) {
|
|
|
|
value = dev_read_prop_by_prop(&property, &propname, &len);
|
2022-07-25 11:56:08 +00:00
|
|
|
if (!value) {
|
|
|
|
free_name_with_prefix(function_propname, prefix);
|
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 -EINVAL;
|
2022-07-25 11:56:08 +00:00
|
|
|
}
|
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: 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-14 15:01:55 +00:00
|
|
|
/* pinmux subnodes already have their muxing set */
|
|
|
|
if (subnode_type != PST_PINMUX &&
|
2022-07-25 11:56:08 +00:00
|
|
|
!strcmp(propname, function_propname)) {
|
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
|
|
|
func_selector = pinmux_func_name_to_selector(dev,
|
|
|
|
value);
|
2022-07-25 11:56:08 +00:00
|
|
|
if (func_selector < 0) {
|
|
|
|
free_name_with_prefix(function_propname, prefix);
|
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 func_selector;
|
2022-07-25 11:56:08 +00:00
|
|
|
}
|
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-14 15:01:55 +00: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 03:44:29 +00: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-14 15:01:55 +00: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 03:44:29 +00:00
|
|
|
selector, param, arg);
|
|
|
|
}
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
if (ret) {
|
|
|
|
free_name_with_prefix(function_propname, prefix);
|
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 ret;
|
2022-07-25 11:56:08 +00:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
free_name_with_prefix(function_propname, prefix);
|
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: 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-14 15:01:55 +00: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,
|
2022-07-25 11:56:08 +00:00
|
|
|
const char *prefix,
|
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-14 15:01:55 +00:00
|
|
|
int *count)
|
|
|
|
{
|
|
|
|
const struct pinctrl_ops *ops = pinctrl_get_ops(dev);
|
2022-07-25 11:56:08 +00:00
|
|
|
const char *propname;
|
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-14 15:01:55 +00:00
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
propname = alloc_name_with_prefix("pins", prefix);
|
|
|
|
if (!propname)
|
|
|
|
return -ENOMEM;
|
|
|
|
*count = dev_read_string_count(config, propname);
|
|
|
|
free_name_with_prefix(propname, prefix);
|
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-14 15:01:55 +00:00
|
|
|
if (*count >= 0)
|
|
|
|
return PST_PIN;
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
propname = alloc_name_with_prefix("groups", prefix);
|
|
|
|
if (!propname)
|
|
|
|
return -ENOMEM;
|
|
|
|
*count = dev_read_string_count(config, propname);
|
|
|
|
free_name_with_prefix(propname, prefix);
|
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-14 15:01:55 +00:00
|
|
|
if (*count >= 0)
|
|
|
|
return PST_GROUP;
|
|
|
|
|
|
|
|
if (ops->pinmux_property_set) {
|
2022-07-25 11:56:08 +00:00
|
|
|
propname = alloc_name_with_prefix("pinmux", prefix);
|
|
|
|
if (!propname)
|
|
|
|
return -ENOMEM;
|
|
|
|
*count = dev_read_size(config, propname);
|
|
|
|
free_name_with_prefix(propname, prefix);
|
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-14 15:01:55 +00:00
|
|
|
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 03:44:29 +00:00
|
|
|
/**
|
|
|
|
* pinctrl_generic_set_state_subnode() - apply all settings in config node
|
|
|
|
*
|
|
|
|
* @dev: pin controller device
|
|
|
|
* @config: pseudo device pointing to config node
|
2022-07-25 11:56:08 +00:00
|
|
|
* @prefix: device tree property prefix (e.g. vendor specific)
|
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 on success, or negative error code on failure
|
|
|
|
*/
|
|
|
|
static int pinctrl_generic_set_state_subnode(struct udevice *dev,
|
2022-07-25 11:56:08 +00:00
|
|
|
struct udevice *config,
|
|
|
|
const char *prefix)
|
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: 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-14 15:01:55 +00:00
|
|
|
enum pinmux_subnode_type subnode_type;
|
2022-07-25 11:56:08 +00:00
|
|
|
const char *propname;
|
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;
|
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-14 15:01:55 +00:00
|
|
|
int count, selector, i, ret, scratch;
|
|
|
|
const u32 *pinmux_groups = NULL; /* prevent use-uninitialized warning */
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
subnode_type = pinctrl_generic_get_subnode_type(dev, config, prefix, &count);
|
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-14 15:01:55 +00:00
|
|
|
|
|
|
|
debug("%s(%s, %s): count=%d\n", __func__, dev->name, config->name,
|
|
|
|
count);
|
|
|
|
|
|
|
|
if (subnode_type == PST_PINMUX) {
|
2022-07-25 11:56:08 +00:00
|
|
|
propname = alloc_name_with_prefix("pinmux", prefix);
|
|
|
|
if (!propname)
|
|
|
|
return -ENOMEM;
|
|
|
|
pinmux_groups = dev_read_prop(config, propname, &scratch);
|
|
|
|
free_name_with_prefix(propname, prefix);
|
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-14 15:01:55 +00:00
|
|
|
if (!pinmux_groups)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
switch (subnode_type) {
|
|
|
|
case PST_PIN:
|
2022-07-25 11:56:08 +00:00
|
|
|
propname = alloc_name_with_prefix("pins", prefix);
|
|
|
|
if (!propname)
|
|
|
|
return -ENOMEM;
|
|
|
|
ret = dev_read_string_index(config, propname, i, &name);
|
|
|
|
free_name_with_prefix(propname, prefix);
|
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-14 15:01:55 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
selector = pinctrl_pin_name_to_selector(dev, name);
|
|
|
|
break;
|
|
|
|
case PST_GROUP:
|
2022-07-25 11:56:08 +00:00
|
|
|
propname = alloc_name_with_prefix("groups", prefix);
|
|
|
|
if (!propname)
|
|
|
|
return -ENOMEM;
|
|
|
|
ret = dev_read_string_index(config, propname, i, &name);
|
|
|
|
free_name_with_prefix(propname, prefix);
|
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-14 15:01:55 +00:00
|
|
|
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:
|
2016-08-16 09:49:47 +00: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 03:44:29 +00:00
|
|
|
|
|
|
|
if (selector < 0)
|
|
|
|
return selector;
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
ret = pinctrl_generic_set_state_one(dev, config, prefix,
|
|
|
|
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 03:44:29 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
int pinctrl_generic_set_state_prefix(struct udevice *dev, struct udevice *config,
|
|
|
|
const char *prefix)
|
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
|
|
|
{
|
|
|
|
struct udevice *child;
|
|
|
|
int ret;
|
|
|
|
|
2022-07-25 11:56:08 +00:00
|
|
|
ret = pinctrl_generic_set_state_subnode(dev, config, prefix);
|
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;
|
|
|
|
|
|
|
|
for (device_find_first_child(config, &child);
|
|
|
|
child;
|
|
|
|
device_find_next_child(&child)) {
|
2022-07-25 11:56:08 +00:00
|
|
|
ret = pinctrl_generic_set_state_subnode(dev, child, prefix);
|
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;
|
|
|
|
}
|
2022-07-25 11:56:08 +00:00
|
|
|
|
|
|
|
int pinctrl_generic_set_state(struct udevice *dev, struct udevice *config)
|
|
|
|
{
|
|
|
|
return pinctrl_generic_set_state_prefix(dev, config, NULL);
|
|
|
|
}
|