Add some overview documentation that explains the purpose and some of
the features and limitations of the regmap interface.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Add support for switching the endianness of regmap accesses via the
"little-endian", "big-endian", and "native-endian" boolean properties in
the device tree.
The default endianness is native endianness.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
It would be convenient if one could use the regmap API in conjunction
with register maps defined as structs (i.e. structs that directly mirror
the memory layout of the registers in question). A similar approach was
planned with the regmap_write32/regmap_read32 macros, but was never
used.
Hence, implement regmap_set/regmap_range_set and
regmap_get/regmap_range_get macros, which, given a register map, a
struct describing the layout of the register map, and a member name
automatically produce regmap_read/regmap_write calls that access the
specified member in the register map.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
It is useful to be able to treat the different ranges of a regmap
separately to be able to use distinct offset for them, but this is
currently not implemented in the regmap API.
To preserve backwards compatibility, add regmap_read_range and
regmap_write_range functions that take an additional parameter
'range_num' that identifies the range to operate on.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
The regmap functions currently assume that all register map accesses
have a data width of 32 bits, but there are maps that have different
widths.
To rectify this, implement the regmap_raw_read and regmap_raw_write
functions from the Linux kernel API that specify the width of a desired
read or write operation on a regmap.
Implement the regmap_read and regmap_write functions using these raw
functions in a backwards-compatible manner.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
The documentation in regmap.h is not in kernel-doc format. Correct this.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Add the regmap_update_bits() to simply the read/modify/write of registers
in a single command. The function is taken from Linux regmap
implementation.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently, regmap_init_mem() takes a udevice. This requires the node
has already been associated with a device. It prevents syscon/regmap
from behaving like those in Linux.
Change the first argumenet to take a device node.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Putting zero length array at the end of struct is a common technique
to embed arbitrary length of members. There is no good reason to let
regmap_alloc_count() branch by "if (count <= 1)".
As far as I understood the code, regmap->base is an alias of
regmap->ranges[0].start, but it is not helpful but make the code
just ugly.
Rename regmap_alloc_count() to regmap_alloc() because the _count
suffix seems pointless.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: fixup cpu_info-rcar.c]
Signed-off-by: Tom Rini <trini@konsulko.com>
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>
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>
Add an implementation of this function which mirrors the functions of the
automatic device-tree implementation. This can be used with of-platdata to
create regmaps.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a simple implementaton of register maps, supporting only direct I/O
for now. This can be enhanced later to support buses which have registers,
such as I2C, SPI and PCI.
It allows drivers which can operate with multiple buses to avoid dealing
with the particulars of register access on that bus.
Signed-off-by: Simon Glass <sjg@chromium.org>
