Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-18 02:38:56 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/include/dm/pinctrl.h

627 lines
21 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
/* SPDX-License-Identifier: GPL-2.0+ */
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
/*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Copyright (C) 2015 Masahiro Yamada <yamada.masahiro@com>
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
*/
#ifndef __PINCTRL_H
#define __PINCTRL_H
cmd: pinmux: Add pinmux command pinmux command allows to : - list all pin-controllers available on platforms - select a pin-controller - display the muxing of all pins of the current pin-controller or all pin-controllers depending of given options Signed-off-by: Patrice Chotard <patrice.chotard@st.com> cmd: pinmux: Fix pinmux command if "pinmux status" command is used without having set dev using "pinmux dev", print pinmux usage Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:17 +00:00
#define PINNAME_SIZE 10
pinctrl: Increase length of pinmux status buffer Xilinx ZynqMP SOC can set 6 parameters for its pins. pinmux status command will print the status of these parameters for each pin. But current print buffer length is only 40 characters long, increase it to 80 to print all the parameters. Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/3a6be84c8354f38754a9838670cc0319e84f29e8.1645626183.git.michal.simek@xilinx.com
2022-02-23 14:23:04 +00:00
#define PINMUX_SIZE 80
cmd: pinmux: Add pinmux command pinmux command allows to : - list all pin-controllers available on platforms - select a pin-controller - display the muxing of all pins of the current pin-controller or all pin-controllers depending of given options Signed-off-by: Patrice Chotard <patrice.chotard@st.com> cmd: pinmux: Fix pinmux command if "pinmux status" command is used without having set dev using "pinmux dev", print pinmux usage Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:17 +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
/**
* struct pinconf_param - pin config parameters
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @property: Property name in DT nodes
* @param: ID for this config parameter
* @default_value: default value for this config parameter used in case
* no value is specified in DT nodes
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 pinconf_param {
const char * const property;
unsigned int param;
u32 default_value;
};
/**
* struct pinctrl_ops - pin control operations, to be implemented by
* pin controller drivers.
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* set_state() is the only mandatory operation. You can implement your pinctrl
* driver with its own @set_state. In this case, the other callbacks are not
* required. Otherwise, generic pinctrl framework is also available; use
* pinctrl_generic_set_state for @set_state, and implement other operations
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
* depending on your necessity.
*/
struct pinctrl_ops {
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @get_pins_count: Get the number of selectable pins
*
* @dev: Pinctrl device to use
*
* This function is necessary to parse the "pins" property in DTS.
*
* @Return:
* number of selectable named pins available in this driver
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*get_pins_count)(struct udevice *dev);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @get_pin_name: Get the name of a pin
*
* @dev: Pinctrl device of the pin
*
* @selector: The pin selector
*
* This function is called by the core to figure out which pin it will
* do operations to. This function is necessary to parse the "pins"
* property in DTS.
*
* @Return: const pointer to the name of the pin
*/
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 *(*get_pin_name)(struct udevice *dev, unsigned selector);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @get_groups_count: Get the number of selectable groups
*
* @dev: Pinctrl device to use
*
* This function is necessary to parse the "groups" property in DTS.
*
* @Return:
* number of selectable named groups available in the driver
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*get_groups_count)(struct udevice *dev);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @get_group_name: Get the name of a group
*
* @dev: Pinctrl device of the group
*
* @selector: The group selector
*
* This function is called by the core to figure out which group it
* will do operations to. This function is necessary to parse the
* "groups" property in DTS.
*
* @Return: Pointer to the name of the 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
const char *(*get_group_name)(struct udevice *dev, unsigned selector);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @get_functions_count: Get the number of selectable functions
*
* @dev: Pinctrl device to use
*
* This function is necessary for pin-muxing.
*
* @Return:
* number of selectable named functions available in this driver
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*get_functions_count)(struct udevice *dev);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @get_function_name: Get the name of a function
*
* @dev: Pinmux device of the function
*
* @selector: The function selector
*
* This function is called by the core to figure out which mux setting
* it will map a certain device to. This function is necessary for
* pin-muxing.
*
* @Return:
* Pointer to the function name of the muxing 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
const char *(*get_function_name)(struct udevice *dev,
unsigned selector);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @pinmux_set: Mux a pin to a function
*
* @dev: Pinctrl device to use
*
* @pin_selector: The pin selector
*
* @func_selector: The func selector
*
* On simple controllers one of @pin_selector or @func_selector may be
* ignored. This function is necessary for pin-muxing against a single
* pin.
*
* @Return: 0 if OK, or negative error code on failure
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*pinmux_set)(struct udevice *dev, unsigned pin_selector,
unsigned func_selector);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @pinmux_group_set: Mux a group of pins to a function
*
* @dev: Pinctrl device to use
*
* @group_selector: The group selector
*
* @func_selector: The func selector
*
* On simple controllers one of @group_selector or @func_selector may be
* ignored. This function is necessary for pin-muxing against a group of
* pins.
*
* @Return: 0 if OK, or negative error code on failure
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*pinmux_group_set)(struct udevice *dev, unsigned group_selector,
unsigned func_selector);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @pinmux_property_set: Enable a pinmux group
*
* @dev: Pinctrl device to use
*
* @pinmux_group: A u32 representing the pin identifier and mux
* settings. The exact format of a pinmux group is left
* up to the driver.
*
* Mux a single pin to a single function based on a driver-specific
* pinmux group. This function is necessary for parsing the "pinmux"
* property in DTS, and for pin-muxing against a pinmux group.
*
* @Return:
* Pin selector for the muxed pin if OK, or negative error code on
* failure
*/
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 (*pinmux_property_set)(struct udevice *dev, u32 pinmux_group);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @pinconf_num_params:
* Number of driver-specific parameters to be parsed from device
* trees. This member is necessary for pin configuration.
*/
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
unsigned int pinconf_num_params;
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @pinconf_params:
* List of driver-specific parameters to be parsed from the device
* tree. This member is necessary for pin configuration.
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
const struct pinconf_param *pinconf_params;
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @pinconf_set: Configure an individual pin with a parameter
*
* @dev: Pinctrl device to use
*
* @pin_selector: The pin selector
*
* @param: An &enum pin_config_param from @pinconf_params
*
* @argument: The argument to this param from the device tree, or
* @pinconf_params.default_value
*
* This function is necessary for pin configuration against a single
* pin.
*
* @Return: 0 if OK, or negative error code on failure
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*pinconf_set)(struct udevice *dev, unsigned pin_selector,
unsigned param, unsigned argument);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @pinconf_group_set: Configure all pins in a group with a parameter
*
* @dev: Pinctrl device to use
*
* @pin_selector: The group selector
*
* @param: A &enum pin_config_param from
* @pinconf_params
*
* @argument: The argument to this param from the device tree, or
* @pinconf_params.default_value
*
* This function is necessary for pin configuration against a group of
* pins.
*
* @Return: 0 if OK, or negative error code on failure
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*pinconf_group_set)(struct udevice *dev, unsigned group_selector,
unsigned param, unsigned argument);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @set_state: Configure a pinctrl device
*
* @dev: Pinctrl device to use
*
* @config: Pseudo device pointing a config node
*
* This function is required to be implemented by all pinctrl drivers.
* Drivers may set this member to pinctrl_generic_set_state(), which
* will call other functions in &struct pinctrl_ops to parse
* @config.
*
* @Return: 0 if OK, or negative error code on failure
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*set_state)(struct udevice *dev, struct udevice *config);
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
/**
* @set_state_simple: Configure a pinctrl device
*
* @dev: Pinctrl device to use
*
* @config: Pseudo-device pointing a config node
*
* This function is usually a simpler version of set_state(). Only the
* first pinctrl device on the system is supported by this function.
*
* @Return: 0 if OK, or negative error code on failure
*/
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
int (*set_state_simple)(struct udevice *dev, struct udevice *periph);
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @request: Request a particular pinctrl function
*
* @dev: Device to adjust (%UCLASS_PINCTRL)
*
* @func: Function number (driver-specific)
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*
* This activates the selected function.
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @Return: 0 if OK, or negative error code on failure
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*/
int (*request)(struct udevice *dev, int func, int flags);
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @get_periph_id: Get the peripheral ID for a device
*
* @dev: Pinctrl device to use for decoding
*
* @periph: Device to check
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*
* This generally looks at the peripheral's device tree node to work
* out the peripheral ID. The return value is normally interpreted as
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* &enum periph_id. so long as this is defined by the platform (which it
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
* should be).
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @Return:
* Peripheral ID of @periph, or %-ENOENT on error
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*/
int (*get_periph_id)(struct udevice *dev, struct udevice *periph);
dm: pinctrl: Add a way for a GPIO driver to obtain a pin function GPIO drivers want to be able to show if a pin is enabled for input, output, or is being used by another function. Some drivers can easily find this and the code is included in the driver. For some SoCs this is more complex. Conceptually this should be handled by pinctrl rather than GPIO. Most pinctrl drivers will have this feature anyway. Add a method by which a GPIO driver can obtain the pin mux value given a GPIO reference. This avoids repeating the code in two places. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:56 +00:00
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @get_gpio_mux: Get the mux value for a particular GPIO
*
* @dev: Pinctrl device to use
*
* @banknum: GPIO bank number
*
* @index: GPIO index within the bank
dm: pinctrl: Add a way for a GPIO driver to obtain a pin function GPIO drivers want to be able to show if a pin is enabled for input, output, or is being used by another function. Some drivers can easily find this and the code is included in the driver. For some SoCs this is more complex. Conceptually this should be handled by pinctrl rather than GPIO. Most pinctrl drivers will have this feature anyway. Add a method by which a GPIO driver can obtain the pin mux value given a GPIO reference. This avoids repeating the code in two places. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:56 +00:00
*
* This allows the raw mux value for a GPIO to be obtained. It is
* useful for displaying the function being used by that GPIO, such
* as with the 'gpio' command. This function is internal to the GPIO
* subsystem and should not be used by generic code. Typically it is
* used by a GPIO driver with knowledge of the SoC pinctrl setup.
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @Return:
* Mux value (SoC-specific, e.g. 0 for input, 1 for output)
dm: pinctrl: Add a way for a GPIO driver to obtain a pin function GPIO drivers want to be able to show if a pin is enabled for input, output, or is being used by another function. Some drivers can easily find this and the code is included in the driver. For some SoCs this is more complex. Conceptually this should be handled by pinctrl rather than GPIO. Most pinctrl drivers will have this feature anyway. Add a method by which a GPIO driver can obtain the pin mux value given a GPIO reference. This avoids repeating the code in two places. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:56 +00:00
*/
int (*get_gpio_mux)(struct udevice *dev, int banknum, int index);
dm: pinctrl: Add get_pin_muxing() ops Add get_pin_muxing() which allows to display the muxing of a given pin belonging to a pin-controller. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:13 +00:00
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @get_pin_muxing: Show pin muxing
*
* @dev: Pinctrl device to use
*
* @selector: Pin selector
*
* @buf: Buffer to fill with pin muxing description
*
* @size: Size of @buf
dm: pinctrl: Add get_pin_muxing() ops Add get_pin_muxing() which allows to display the muxing of a given pin belonging to a pin-controller. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:13 +00:00
*
* This allows to display the muxing of a given pin. It's useful for
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* debug purposes to know if a pin is configured as GPIO or as an
* alternate function and which one. Typically it is used by a PINCTRL
* driver with knowledge of the SoC pinctrl setup.
*
* @Return: 0 if OK, or negative error code on failure
dm: pinctrl: Add get_pin_muxing() ops Add get_pin_muxing() which allows to display the muxing of a given pin belonging to a pin-controller. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:13 +00:00
*/
int (*get_pin_muxing)(struct udevice *dev, unsigned int selector,
char *buf, int size);
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @gpio_request_enable: Request and enable GPIO on a certain pin.
*
* @dev: Pinctrl device to use
*
* @selector: Pin selector
*
* Implement this only if you can mux every pin individually as GPIO.
* The affected GPIO range is passed along with an offset(pin number)
* into that specific GPIO range - function selectors and pin groups are
* orthogonal to this, the core will however make sure the pins do not
* collide.
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @Return:
* 0 if OK, or negative error code on failure
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
*/
int (*gpio_request_enable)(struct udevice *dev, unsigned int selector);
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @gpio_disable_free: Free up GPIO muxing on a certain pin.
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @dev: Pinctrl device to use
*
* @selector: Pin selector
*
* This function is the reverse of @gpio_request_enable.
*
* @Return: 0 if OK, or negative error code on failure
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
*/
int (*gpio_disable_free)(struct udevice *dev, unsigned int 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
};
#define pinctrl_get_ops(dev) ((struct pinctrl_ops *)(dev)->driver->ops)
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* enum pin_config_param - Generic pin configuration parameters
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: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_BIAS_BUS_HOLD: The pin will be set to weakly latch so that it
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* weakly drives the last value on a tristate bus, also known as a "bus
* holder", "bus keeper" or "repeater". This allows another device on the
* bus to change the value by driving the bus high or low and switching to
* tristate. The argument is ignored.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_BIAS_DISABLE: Disable any pin bias on the pin, a
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
* transition from say pull-up to pull-down implies that you disable
* pull-up in the process, this setting disables all biasing.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_BIAS_HIGH_IMPEDANCE: The pin will be set to a high impedance
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
* mode, also know as "third-state" (tristate) or "high-Z" or "floating".
* On output pins this effectively disconnects the pin, which is useful
* if for example some other pin is going to drive the signal connected
* to it for a while. Pins used for input are usually always high
* impedance.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_BIAS_PULL_DOWN: The pin will be pulled down (usually with high
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
* impedance to GROUND). If the argument is != 0 pull-down is enabled,
* if it is 0, pull-down is total, i.e. the pin is connected to GROUND.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_BIAS_PULL_PIN_DEFAULT: The pin will be pulled up or down based
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
* on embedded knowledge of the controller hardware, like current mux
* function. The pull direction and possibly strength too will normally
* be decided completely inside the hardware block and not be readable
* from the kernel side.
* If the argument is != 0 pull up/down is enabled, if it is 0, the
* configuration is ignored. The proper way to disable it is to use
* @PIN_CONFIG_BIAS_DISABLE.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_BIAS_PULL_UP: The pin will be pulled up (usually with high
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* impedance to VDD). If the argument is != 0 pull-up is enabled,
* if it is 0, pull-up is total, i.e. the pin is connected to VDD.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_DRIVE_OPEN_DRAIN: The pin will be driven with open drain (open
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
* collector) which means it is usually wired with other output ports
* which are then pulled up with an external resistor. Setting this
* config will enable open drain mode, the argument is ignored.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_DRIVE_OPEN_SOURCE: The pin will be driven with open source
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
* (open emitter). Setting this config will enable open source mode, the
* argument is ignored.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_DRIVE_PUSH_PULL: The pin will be driven actively high and
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* low, this is the most typical case and is typically achieved with two
* active transistors on the output. Setting this config will enable
* push-pull mode, the argument is ignored.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_DRIVE_STRENGTH: The pin will sink or source at most the current
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
* passed as argument. The argument is in mA.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_DRIVE_STRENGTH_UA: The pin will sink or source at most the
* current passed as argument. The argument is in uA.
* @PIN_CONFIG_INPUT_DEBOUNCE: This will configure the pin to debounce mode,
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* which means it will wait for signals to settle when reading inputs. The
* argument gives the debounce time in usecs. Setting the
* argument to zero turns debouncing off.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_INPUT_ENABLE: Enable the pin's input. Note that this does not
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
* affect the pin's ability to drive output. 1 enables input, 0 disables
* input.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_INPUT_SCHMITT: This will configure an input pin to run in
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
* schmitt-trigger mode. If the schmitt-trigger has adjustable hysteresis,
* the threshold value is given on a custom format as argument when
* setting pins to this mode.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_INPUT_SCHMITT_ENABLE: Control schmitt-trigger mode on the pin.
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* If the argument != 0, schmitt-trigger mode is enabled. If it's 0,
* schmitt-trigger mode is disabled.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_LOW_POWER_MODE: This will configure the pin for low power
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* operation, if several modes of operation are supported these can be
* passed in the argument on a custom form, else just use argument 1
* to indicate low power mode, argument 0 turns low power mode off.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_OUTPUT_ENABLE: This will enable the pin's output mode
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* without driving a value there. For most platforms this reduces to
* enable the output buffers and then let the pin controller current
* configuration (eg. the currently selected mux function) drive values on
* the line. Use argument 1 to enable output mode, argument 0 to disable
* it.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_OUTPUT: This will configure the pin as an output and drive a
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* value on the line. Use argument 1 to indicate high level, argument 0 to
* indicate low level. (Please see Documentation/driver-api/pinctl.rst,
* section "GPIO mode pitfalls" for a discussion around this parameter.)
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_POWER_SOURCE: If the pin can select between different power
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
* supplies, the argument to this parameter (on a custom format) tells
* the driver which alternative power source to use.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_SLEEP_HARDWARE_STATE: Indicate this is sleep related state.
* @PIN_CONFIG_SLEW_RATE: If the pin can select slew rate, the argument to
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
* this parameter (on a custom format) tells the driver which alternative
* slew rate to use.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_SKEW_DELAY: If the pin has programmable skew rate (on inputs)
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* or latch delay (on outputs) this parameter (in a custom format)
* specifies the clock skew or latch delay. It typically controls how
* many double inverters are put in front of the line.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_END: This is the last enumerator for pin configurations, if
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
* you need to pass in custom configurations to the pin controller, use
* PIN_CONFIG_END+1 as the base offset.
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @PIN_CONFIG_MAX: This is the maximum configuration value that can be
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
* presented using the packed format.
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
*/
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +00:00
enum pin_config_param {
dm: pinctrl: Use explicit values for enums Based on discussion at https://lore.kernel.org/r/20200318125003.GA2727094@kroah.com we got recommendation to use explicit values for all enums. So, add explicit values to all pinctrl related enums for readability. Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/dcdb20e7252ea7465e9f984d815e9624c30e9558.1645624969.git.michal.simek@xilinx.com
2022-02-23 14:02:51 +00:00
PIN_CONFIG_BIAS_BUS_HOLD = 0,
PIN_CONFIG_BIAS_DISABLE = 1,
PIN_CONFIG_BIAS_HIGH_IMPEDANCE = 2,
PIN_CONFIG_BIAS_PULL_DOWN = 3,
PIN_CONFIG_BIAS_PULL_PIN_DEFAULT = 4,
PIN_CONFIG_BIAS_PULL_UP = 5,
PIN_CONFIG_DRIVE_OPEN_DRAIN = 6,
PIN_CONFIG_DRIVE_OPEN_SOURCE = 7,
PIN_CONFIG_DRIVE_PUSH_PULL = 8,
PIN_CONFIG_DRIVE_STRENGTH = 9,
PIN_CONFIG_DRIVE_STRENGTH_UA = 10,
PIN_CONFIG_INPUT_DEBOUNCE = 11,
PIN_CONFIG_INPUT_ENABLE = 12,
PIN_CONFIG_INPUT_SCHMITT = 13,
PIN_CONFIG_INPUT_SCHMITT_ENABLE = 14,
PIN_CONFIG_LOW_POWER_MODE = 15,
PIN_CONFIG_OUTPUT_ENABLE = 16,
PIN_CONFIG_OUTPUT = 17,
PIN_CONFIG_POWER_SOURCE = 18,
PIN_CONFIG_SLEEP_HARDWARE_STATE = 19,
PIN_CONFIG_SLEW_RATE = 20,
PIN_CONFIG_SKEW_DELAY = 21,
PIN_CONFIG_END = 127, /* 0x7F */
PIN_CONFIG_MAX = 255, /* 0xFF */
dm: pinctrl: sync with Linux to use pin_config_param Sync with Linux commit 30a7acd573899fd8b("Linux 4.15-rc6") to use enum pin_config_param. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-01-05 06:05:17 +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
#if CONFIG_IS_ENABLED(PINCTRL_GENERIC)
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* pinctrl_generic_set_state() - Generic set_state operation
* @pctldev: Pinctrl device to use
* @config: Config device (pseudo device), pointing a config node in DTS
*
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
* Parse the DT node of @config and its children and handle generic properties
* such as "pins", "groups", "functions", and pin configuration parameters.
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: 0 on success, or negative error code on failure
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
*/
int pinctrl_generic_set_state(struct udevice *pctldev, struct udevice *config);
#else
static inline int pinctrl_generic_set_state(struct udevice *pctldev,
struct udevice *config)
{
pinctrl: change result for unsupported API Use the return value ENOSYS for unsupported API - pinctrl_generic_set_state - pinctrl_select_state Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-11-19 09:02:26 +00:00
return -ENOSYS;
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
}
#endif
#if CONFIG_IS_ENABLED(PINCTRL)
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* pinctrl_select_state() - Set a device to a given state
* @dev: Peripheral device
* @statename: State name, like "default"
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: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: 0 on success, or negative error code on failure
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
*/
int pinctrl_select_state(struct udevice *dev, const char *statename);
#else
static inline int pinctrl_select_state(struct udevice *dev,
const char *statename)
{
pinctrl: change result for unsupported API Use the return value ENOSYS for unsupported API - pinctrl_generic_set_state - pinctrl_select_state Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-11-19 09:02:26 +00:00
return -ENOSYS;
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
}
#endif
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
/**
* pinctrl_request() - Request a particular pinctrl function
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @dev: Pinctrl device to use
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
* @func: Function number (driver-specific)
* @flags: Flags (driver-specific)
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
*
* Return: 0 if OK, or negative error code on failure
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*/
int pinctrl_request(struct udevice *dev, int func, int flags);
/**
* pinctrl_request_noflags() - Request a particular pinctrl function
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @dev: Pinctrl device to use
* @func: Function number (driver-specific)
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*
* This is similar to pinctrl_request() but uses 0 for @flags.
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: 0 if OK, or negative error code on failure
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*/
int pinctrl_request_noflags(struct udevice *dev, int func);
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* pinctrl_get_periph_id() - Get the peripheral ID for a device
* @dev: Pinctrl device to use for decoding
* @periph: Device to check
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*
* This generally looks at the peripheral's device tree node to work out the
* peripheral ID. The return value is normally interpreted as enum periph_id.
* so long as this is defined by the platform (which it should be).
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: Peripheral ID of @periph, or -ENOENT on error
pinctrl: Add the concept of peripheral IDs My original pinctrl patch operating using a peripheral ID enum. This was shared between pinmux and clock and provides an easy way to specify a device that needs to be controlled, even it is does not (yet) have a driver within driver model. Masahiro's new simple pinctrl gets around this by providing a set_state_simple() pinctrl method. By passing a device to that call the peripheral ID becomes unnecessary. If the driver needs it, it can calculate it itself and use it internally. However this does not solve the problem for peripheral clocks. The 'pure' solution would be to pass a driver to the clock uclass also. But this requires that all devices should have a driver, and a struct udevide. Also a key optimisation of the clock uclass is allowing a peripheral clock to be set even when there is no device for that clock. There may be a better way to achive the same goal, but for now it seems expedient to add in peripheral ID to the pinctrl uclass. Two methods are added - one to get the peripheral ID and one to select it. The existing set_state_simple() is effectively the union of these. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-30 22:55:13 +00:00
*/
int pinctrl_get_periph_id(struct udevice *dev, struct udevice *periph);
dm: pinctrl: Add a way for a GPIO driver to obtain a pin function GPIO drivers want to be able to show if a pin is enabled for input, output, or is being used by another function. Some drivers can easily find this and the code is included in the driver. For some SoCs this is more complex. Conceptually this should be handled by pinctrl rather than GPIO. Most pinctrl drivers will have this feature anyway. Add a method by which a GPIO driver can obtain the pin mux value given a GPIO reference. This avoids repeating the code in two places. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:56 +00:00
/**
* pinctrl_get_gpio_mux() - get the mux value for a particular GPIO
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @dev: Pinctrl device to use
* @banknum: GPIO bank number
* @index: GPIO index within the bank
dm: pinctrl: Add a way for a GPIO driver to obtain a pin function GPIO drivers want to be able to show if a pin is enabled for input, output, or is being used by another function. Some drivers can easily find this and the code is included in the driver. For some SoCs this is more complex. Conceptually this should be handled by pinctrl rather than GPIO. Most pinctrl drivers will have this feature anyway. Add a method by which a GPIO driver can obtain the pin mux value given a GPIO reference. This avoids repeating the code in two places. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:56 +00:00
*
* This allows the raw mux value for a GPIO to be obtained. It is
* useful for displaying the function being used by that GPIO, such
* as with the 'gpio' command. This function is internal to the GPIO
* subsystem and should not be used by generic code. Typically it is
* used by a GPIO driver with knowledge of the SoC pinctrl setup.
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: Mux value (SoC-specific, e.g. 0 for input, 1 for output)
dm: pinctrl: Add a way for a GPIO driver to obtain a pin function GPIO drivers want to be able to show if a pin is enabled for input, output, or is being used by another function. Some drivers can easily find this and the code is included in the driver. For some SoCs this is more complex. Conceptually this should be handled by pinctrl rather than GPIO. Most pinctrl drivers will have this feature anyway. Add a method by which a GPIO driver can obtain the pin mux value given a GPIO reference. This avoids repeating the code in two places. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:43:56 +00:00
*/
int pinctrl_get_gpio_mux(struct udevice *dev, int banknum, int index);
dm: pinctrl: Add get_pin_muxing() ops Add get_pin_muxing() which allows to display the muxing of a given pin belonging to a pin-controller. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:13 +00:00
/**
* pinctrl_get_pin_muxing() - Returns the muxing description
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @dev: Pinctrl device to use
* @selector: Pin index within pin-controller
* @buf: Pin's muxing description
* @size: Pin's muxing description length
dm: pinctrl: Add get_pin_muxing() ops Add get_pin_muxing() which allows to display the muxing of a given pin belonging to a pin-controller. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:13 +00:00
*
* This allows to display the muxing description of the given pin for
* debug purpose
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: 0 if OK, or negative error code on failure
dm: pinctrl: Add get_pin_muxing() ops Add get_pin_muxing() which allows to display the muxing of a given pin belonging to a pin-controller. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:13 +00:00
*/
int pinctrl_get_pin_muxing(struct udevice *dev, int selector, char *buf,
int size);
dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods to obtain pin's name and pin's muxing given a pin reference. This will be used by the new pinmux command. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:14 +00:00
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* pinctrl_get_pins_count() - Display pin-controller pins number
* @dev: Pinctrl device to use
dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods to obtain pin's name and pin's muxing given a pin reference. This will be used by the new pinmux command. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:14 +00:00
*
* This allows to know the number of pins owned by a given pin-controller
*
cmd: pinmux: update result of do_status Update the result of do_status and always returns a CMD_RET_ value (-ENOSYS was a possible result of show_pinmux). This patch also adds pincontrol name in error messages (dev->name) and treats correctly the status sub command when pin-controller device is not selected. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-05-21 07:47:31 +00:00
* Return: Number of pins if OK, or -ENOSYS when not supported
dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods to obtain pin's name and pin's muxing given a pin reference. This will be used by the new pinmux command. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:14 +00:00
*/
int pinctrl_get_pins_count(struct udevice *dev);
/**
* pinctrl_get_pin_name() - Returns the pin's name
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* @dev: Pinctrl device to use
* @selector: Pin index within pin-controller
* @buf: Buffer to fill with the name of the pin
* @size: Size of @buf
dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods to obtain pin's name and pin's muxing given a pin reference. This will be used by the new pinmux command. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:14 +00:00
*
* This allows to display the pin's name for debug purpose
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: 0 if OK, or negative error code on failure
dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods to obtain pin's name and pin's muxing given a pin reference. This will be used by the new pinmux command. Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-24 12:10:14 +00:00
*/
int pinctrl_get_pin_name(struct udevice *dev, int selector, char *buf,
int size);
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* pinctrl_gpio_request() - Request a single pin to be used as GPIO
* @dev: GPIO peripheral device
* @offset: GPIO pin offset from the GPIO controller
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: 0 on success, or negative error code on failure
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
*/
int pinctrl_gpio_request(struct udevice *dev, unsigned offset);
/**
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* pinctrl_gpio_free() - Free a single pin used as GPIO
* @dev: GPIO peripheral device
* @offset: GPIO pin offset from the GPIO controller
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
*
pinctrl: Reformat documentation in dm/pinctrl.h This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-14 15:01:56 +00:00
* Return: 0 on success, or negative error code on failure
pinctrl: gpio: Add callback for configuring pin as GPIO Add callback to configure, and de-configure, pin as a GPIO on the pin controller side. This matches similar functionality in Linux and aims to replace the ad-hoc implementations present in U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Alex Kiernan <alex.kiernan@gmail.com> Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com> Cc: Eugeniu Rosca <roscaeugeniu@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick DELAUNAY <patrick.delaunay@st.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Simon Glass <sjg@chromium.org>
2019-04-21 21:57:23 +00:00
*/
int pinctrl_gpio_free(struct udevice *dev, unsigned offset);
pinctrl: add pin control uclass support This creates a new framework for handling of pin control devices, i.e. devices that control different aspects of package pins. This uclass handles pinmuxing and pin configuration; pinmuxing controls switching among silicon blocks that share certain physical pins, pin configuration handles electronic properties such as pin- biasing, load capacitance etc. This framework can support the same device tree bindings, but if you do not need full interface support, you can disable some features to reduce memory foot print. Typically around 1.5KB is necessary to include full-featured uclass support on ARM board (CONFIG_PINCTRL + CONFIG_PINCTRL_FULL + CONFIG_PINCTRL_GENERIC + CONFIG_PINCTRL_PINMUX), for example. We are often limited on code size for SPL. Besides, we still have many boards that do not support device tree configuration. The full pinctrl, which requires OF_CONTROL, does not make sense for those boards. So, this framework also has a Do-It-Yourself (let's say simple pinctrl) interface. With CONFIG_PINCTRL_FULL disabled, the uclass itself provides no systematic mechanism for identifying the peripheral device, applying pinctrl settings, etc. They must be done in each low-level driver. In return, you can save much memory footprint and it might be useful especially for SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-27 03:44:29 +00:00
#endif /* __PINCTRL_H */
Reference in a new issue Copy permalink