Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-16 17:58:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/include/syscon.h

106 lines
3.1 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+ */
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
/*
* Copyright (c) 2015 Google, Inc
* Written by Simon Glass <sjg@chromium.org>
*/
#ifndef __SYSCON_H
#define __SYSCON_H
syscon: add Linux-compatible syscon API The syscon implementation in U-Boot is different from that in Linux. Thus, DT files imported from Linux do not work for U-Boot. In U-Boot driver model, each node is bound to a dedicated driver that is the most compatible to it. This design gets along with the concept of DT, and the syscon in Linux originally worked like that. However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon interface from platform devices") changed the behavior because it is useful to let a device bind to another driver, but still work as a syscon provider. That change had happened before U-Boot initially supported the syscon driver by commit 6f98b7504f70 ("dm: Add support for generic system controllers (syscon)"). So, the U-Boot's syscon works differently from the beginning. I'd say this is mis-implementation given that DT is not oriented to a particular project, but Linux is the canon of DT in practice. The problem typically arises in the combination of "syscon" and "simple-mfd" compatibles. In Linux, they are orthogonal, i.e., the order between "syscon" and "simple-mfd" does not matter at all. Assume the following compatible. compatible = "foo,bar-syscon", "syscon", "simple-mfd"; In U-Boot, this device node is bound to the syscon driver (driver/core/syscon-uclass.c) since the "syscon" is found to be the most compatible. Then, syscon_get_regmap() succeeds. However, compatible = "foo,bar-syscon", "simple-mfd", "syscon"; does not work because this node is bound to the simple-bus driver (drivers/core/simple-bus.c) in favor of "simple-mfd" compatible. The compatible string "syscon" is just dismissed. Moreover, compatible = "foo,bar-syscon", "syscon"; works like the first case because the syscon driver populates the child devices. This is wrong because populating children is the job of "simple-mfd" (or "simple-bus"). This commit ports syscon_node_to_regmap() from Linux. This API does not require the given node to be bound to a driver in any way. Reported-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-04-19 03:14:04 +00:00
#include <dm/ofnode.h>
dtoc: Add support for 32 or 64-bit addresses When using 32-bit addresses dtoc works correctly. For 64-bit addresses it does not since it ignores the #address-cells and #size-cells properties. Update the tool to use fdt64_t as the element type for reg properties when either the address or size is larger than one cell. Use the correct value so that C code can obtain the information from the device tree easily. Alos create a new type, fdt_val_t, which is defined to either fdt32_t or fdt64_t depending on the word size of the machine. This type corresponds to fdt_addr_t and fdt_size_t. Unfortunately we cannot just use those types since they are defined to phys_addr_t and phys_size_t which use 'unsigned long' in the 32-bit case, rather than 'unsigned int'. Add tests for the four combinations of address and size values (32/32, 64/64, 32/64, 64/32). Also update existing uses for rk3399 and rk3368 which now need to use the new fdt_val_t type. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heiko Stuebner <heiko@sntech.de> Reported-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Kever Yang <kever.yang@rock-chips.com>
2017-08-29 20:15:50 +00:00
#include <fdtdec.h>
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
/**
* struct syscon_uc_info - Information stored by the syscon UCLASS_UCLASS
*
* @regmap: Register map for this controller
*/
struct syscon_uc_info {
struct regmap *regmap;
};
/* So far there are no ops so this is a placeholder */
struct syscon_ops {
};
#define syscon_get_ops(dev) ((struct syscon_ops *)(dev)->driver->ops)
dm: syscon: Add support for of-platdata Provide a new function which can cope with obtaining information from of-platdata instead of the device tree. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-07-04 17:58:00 +00:00
#if CONFIG_IS_ENABLED(OF_PLATDATA)
/*
* We don't support 64-bit machines. If they are so resource-contrained that
* they need to use OF_PLATDATA, something is horribly wrong with the
* education of our hardware engineers.
dtoc: Add support for 32 or 64-bit addresses When using 32-bit addresses dtoc works correctly. For 64-bit addresses it does not since it ignores the #address-cells and #size-cells properties. Update the tool to use fdt64_t as the element type for reg properties when either the address or size is larger than one cell. Use the correct value so that C code can obtain the information from the device tree easily. Alos create a new type, fdt_val_t, which is defined to either fdt32_t or fdt64_t depending on the word size of the machine. This type corresponds to fdt_addr_t and fdt_size_t. Unfortunately we cannot just use those types since they are defined to phys_addr_t and phys_size_t which use 'unsigned long' in the 32-bit case, rather than 'unsigned int'. Add tests for the four combinations of address and size values (32/32, 64/64, 32/64, 64/32). Also update existing uses for rk3399 and rk3368 which now need to use the new fdt_val_t type. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heiko Stuebner <heiko@sntech.de> Reported-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Kever Yang <kever.yang@rock-chips.com>
2017-08-29 20:15:50 +00:00
*
* Update: 64-bit is now supported and we have an education crisis.
dm: syscon: Add support for of-platdata Provide a new function which can cope with obtaining information from of-platdata instead of the device tree. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-07-04 17:58:00 +00:00
*/
dm: treewide: Rename ..._platdata variables to just ..._plat Try to maintain some consistency between these variables by using _plat as a suffix for them. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-03 23:55:23 +00:00
struct syscon_base_plat {
dtoc: Add support for 32 or 64-bit addresses When using 32-bit addresses dtoc works correctly. For 64-bit addresses it does not since it ignores the #address-cells and #size-cells properties. Update the tool to use fdt64_t as the element type for reg properties when either the address or size is larger than one cell. Use the correct value so that C code can obtain the information from the device tree easily. Alos create a new type, fdt_val_t, which is defined to either fdt32_t or fdt64_t depending on the word size of the machine. This type corresponds to fdt_addr_t and fdt_size_t. Unfortunately we cannot just use those types since they are defined to phys_addr_t and phys_size_t which use 'unsigned long' in the 32-bit case, rather than 'unsigned int'. Add tests for the four combinations of address and size values (32/32, 64/64, 32/64, 64/32). Also update existing uses for rk3399 and rk3368 which now need to use the new fdt_val_t type. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heiko Stuebner <heiko@sntech.de> Reported-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Kever Yang <kever.yang@rock-chips.com>
2017-08-29 20:15:50 +00:00
fdt_val_t reg[2];
dm: syscon: Add support for of-platdata Provide a new function which can cope with obtaining information from of-platdata instead of the device tree. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-07-04 17:58:00 +00:00
};
#endif
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
/**
* syscon_get_regmap() - Get access to a register map
*
* @dev: Device to check (UCLASS_SCON)
* @info: Returns regmap for the device
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-19 17:05:50 +00:00
* Return: 0 if OK, -ve on error
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
*/
struct regmap *syscon_get_regmap(struct udevice *dev);
dm: syscon: Allow finding devices by driver data We have a way to find a regmap by its syscon driver data value. Add the same for syscon itself. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-17 23:11:08 +00:00
/**
* syscon_get_regmap_by_driver_data() - Look up a controller by its ID
*
* Each system controller can be accessed by its driver data, which is
* assumed to be unique through the scope of all system controllers that
* are in use. This function looks up the controller given this driver data.
*
* @driver_data: Driver data value to look up
* @devp: Returns the controller correponding to @driver_data
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-19 17:05:50 +00:00
* Return: 0 on success, -ENODEV if the ID was not found, or other -ve error
dm: syscon: Allow finding devices by driver data We have a way to find a regmap by its syscon driver data value. Add the same for syscon itself. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-17 23:11:08 +00:00
* code
*/
int syscon_get_by_driver_data(ulong driver_data, struct udevice **devp);
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
/**
* syscon_get_regmap_by_driver_data() - Look up a controller by its ID
*
* Each system controller can be accessed by its driver data, which is
* assumed to be unique through the scope of all system controllers that
* are in use. This function looks up the regmap given this driver data.
*
* @driver_data: Driver data value to look up
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-19 17:05:50 +00:00
* Return: register map correponding to @driver_data, or -ve error code
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
*/
struct regmap *syscon_get_regmap_by_driver_data(ulong driver_data);
syscon: dm: Add a new method to get a regmap from DTS syscon_regmap_lookup_by_phandle() can be used to get the regmap of a syscon device from a reference in the DTS. It operates similarly to the linux version of the namesake function. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-29 09:57:37 +00:00
/**
* syscon_regmap_lookup_by_phandle() - Look up a controller by a phandle
*
* This operates by looking up the given name in the device (device
* tree property) of the device using the system controller.
*
* @dev: Device using the system controller
* @name: Name of property referring to the system controller
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-19 17:05:50 +00:00
* Return: A pointer to the regmap if found, ERR_PTR(-ve) on error
syscon: dm: Add a new method to get a regmap from DTS syscon_regmap_lookup_by_phandle() can be used to get the regmap of a syscon device from a reference in the DTS. It operates similarly to the linux version of the namesake function. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-29 09:57:37 +00:00
*/
struct regmap *syscon_regmap_lookup_by_phandle(struct udevice *dev,
const char *name);
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
/**
* syscon_get_first_range() - get the first memory range from a syscon regmap
*
* @driver_data: Driver data value to look up
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-19 17:05:50 +00:00
* Return: first region of register map correponding to @driver_data, or
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
* -ve error code
*/
void *syscon_get_first_range(ulong driver_data);
syscon: add Linux-compatible syscon API The syscon implementation in U-Boot is different from that in Linux. Thus, DT files imported from Linux do not work for U-Boot. In U-Boot driver model, each node is bound to a dedicated driver that is the most compatible to it. This design gets along with the concept of DT, and the syscon in Linux originally worked like that. However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon interface from platform devices") changed the behavior because it is useful to let a device bind to another driver, but still work as a syscon provider. That change had happened before U-Boot initially supported the syscon driver by commit 6f98b7504f70 ("dm: Add support for generic system controllers (syscon)"). So, the U-Boot's syscon works differently from the beginning. I'd say this is mis-implementation given that DT is not oriented to a particular project, but Linux is the canon of DT in practice. The problem typically arises in the combination of "syscon" and "simple-mfd" compatibles. In Linux, they are orthogonal, i.e., the order between "syscon" and "simple-mfd" does not matter at all. Assume the following compatible. compatible = "foo,bar-syscon", "syscon", "simple-mfd"; In U-Boot, this device node is bound to the syscon driver (driver/core/syscon-uclass.c) since the "syscon" is found to be the most compatible. Then, syscon_get_regmap() succeeds. However, compatible = "foo,bar-syscon", "simple-mfd", "syscon"; does not work because this node is bound to the simple-bus driver (drivers/core/simple-bus.c) in favor of "simple-mfd" compatible. The compatible string "syscon" is just dismissed. Moreover, compatible = "foo,bar-syscon", "syscon"; works like the first case because the syscon driver populates the child devices. This is wrong because populating children is the job of "simple-mfd" (or "simple-bus"). This commit ports syscon_node_to_regmap() from Linux. This API does not require the given node to be bound to a driver in any way. Reported-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-04-19 03:14:04 +00:00
/**
* syscon_node_to_regmap - get regmap from syscon
*
* @node: Device node of syscon
*/
struct regmap *syscon_node_to_regmap(ofnode node);
dm: Add support for generic system controllers (syscon) Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-06-23 21:38:43 +00:00
#endif
Reference in a new issue Copy permalink