u-boot.git/arch/arm/include/asm/arch-omap4, branch master

arm: ti: Introduce back omap4 support

2026-06-17T15:50:36Z

omap4 support was dropped by b0ee3fe642c ("arm: ti: Remove omap4 platform support") because the supported boards hadn't done the conversion to CONFIG_DM_I2C in time. It still exists some omap4-based products and they could benefit from the latest U-Boot support for obvious security reasons. Revert part of b0ee3fe642c to introduce back a minimal support for the omap4 platform. Fix the checkpatch's warning/errors induced by this revert. Following warnings are still present: | arch/arm/include/asm/arch-omap4/clock.h:445: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? | arch/arm/mach-omap2/omap4/hwinit.c:24: WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible | arch/arm/mach-omap2/omap4/sdram_elpida.c:142: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:143: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:144: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:145: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:146: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:147: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:148: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:149: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:150: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:151: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:152: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:153: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:154: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:155: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:156: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:157: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:158: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:159: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:209: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:210: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:213: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:215: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:216: CHECK: Avoid CamelCase: | arch/arm/mach-omap2/omap4/sdram_elpida.c:217: CHECK: Avoid CamelCase: I didn't find an clean way to fix the "don't use #ifdef" warning as we need to define the gpio_bank for the SPL build only. For the CamelCase warnings, the incriminated attributes represent timings, so IMHO, it is more readable with CamelCase. Set myself as OMAP4 maintainer. Signed-off-by: Bastien Curutchet

arm: ti: Remove omap4 platform support

2024-07-23T16:37:48Z

There are no longer any OMAP4 platforms in U-Boot, remove the related functionality. Signed-off-by: Tom Rini

arm: include: ti: Remove duplicate newlines

2024-07-15T18:12:16Z

Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut

tree-wide: Replace http:// link with https:// link for ti.com

2023-11-10T16:01:50Z

Replace instances of http://www.ti.com with https://www.ti.com Signed-off-by: Nishanth Menon

arm: omap2plus: Move CONFIG_SYS_PTV out of CONFIG namespace

2022-06-06T16:09:00Z

This is always defined to 2, and referenced in two places. Move the define to and make sure the code that uses this includes that file. Make not include that file, as we don't need to be doing so. Signed-off-by: Tom Rini

arm: Don't include common.h in header files

2020-05-18T18:54:24Z

It is bad practice to include common.h in other header files since it can bring in any number of superfluous definitions. It implies that some C files don't include it and thus may be missing CONFIG options that are set up by that file. The C files should include these themselves. Update some header files in arch/arm to drop this. Signed-off-by: Simon Glass

i2c: omap24xx_i2c: Move away from SoC specific headers for reg offset

2018-12-10T05:09:34Z

Move away from SoC specific headers to handle different register layout. Instead use driver data to get appropriate register layouts like in the kernel. While at it, perform some mostly cosmetic alignment/cleanup in the functions being updated. Signed-off-by: Vignesh R Signed-off-by: Andreas Dannenberg Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini Reviewed-by: Heiko Schocher

SPDX: Convert all of our single license tags to Linux Kernel style

2018-05-07T13:34:12Z

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

Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR

2018-04-27T18:54:48Z

We have a large number of places where while we historically referenced gd in the code we no longer do, as well as cases where the code added that line "just in case" during development and never dropped it. Signed-off-by: Tom Rini

omap: Update the base address of the MMC controllers

2018-01-19T03:04:21Z

Align the base address defined in header files with the base address used in the DTS. This will facilitate the introduction of the DMA support. Of all HSMMC users, only omap3 doesn't have the 0x100 reserved region at the top. This region will be used to determine if the controller supports DMA transfers Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini