Kory Maincent [Wed, 11 Jun 2025 17:10:30 +0000 (19:10 +0200)]
usb: gadget: musb: Fix duplicate ops assignment in ti_musb_peripheral
Remove duplicate .ops assignment that was overriding the correct
ti_musb_gadget_ops with musb_usb_ops (host ops) in the ti_musb_peripheral
driver. This was causing U-Boot crashes when trying to call the
handle_interrupts operation since the wrong ops structure was being used.
Ivan Pang [Wed, 11 Jun 2025 05:00:38 +0000 (05:00 +0000)]
dfu: fix dev_part_str for file operations
The third_arg for a dfu alt is read as an integer and is overloaded for
different supported backends. For ext4 and fat, this third_arg
represents the partition and forms the dev part string, which should
have its partition in hex. This commit fixes dfu ext4/fat usage for
devices with ten or more partitions.
Signed-off-by: Ivan Pang <ipman@amazon.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Link: https://lore.kernel.org/r/20250611050127.38011-1-ipman@amazon.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
For U-Boot to enable HS200 mode the mmc-hs200-1_8v prop must be defined
in the device tree. Linux does not seem to be affected and is able to
detect and use HS200 without this prop.
Enable use of HS200 and fix eMMC write on RK3528 by adding the missing
mmc-hs200-1_8v prop for affected boards:
Jan Čermák [Wed, 30 Apr 2025 17:15:35 +0000 (19:15 +0200)]
configs: rpi: set NR_DRAM_BANKS to 8 to accommodate RAM on 16GB models
Raspberry Pi 5 can now have up to 16 GiB of RAM where the memory spans 8
DRAM banks in total. Increase the config value to 8 to initialize the
whole RAM. Without this change, kernel only sees 8 GiB of RAM on the 16
GiB CM5 as reported in [1].
linux/bitfield.h: sync <linux/bitfield.h> from Linux 6.15
Sync bitfield.h header with Linux 6.15 version. Mainly is to permit the
introduction of FIELD_PREP_CONST. The bug.h header changed to
build_bug.h doesn't cause any regression as we also ship split header
similar to how it's done with in Linux.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
arm: apple: rtkit: add missing header linux/bug.h and linux/bitops.h
The GENMASK/GENMASK_ULL macro requires inclusion of linux/bitops.h
header. It does currently work as bitfield.h includes it indirectly
but this will change when bitfield.h will be synced with new Linux
version.
Also raw printf require linux/bug.h header (also currently included
indirectly by bitfield.h)
Explicitly include the headers to fix future compilation error.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
iommu: qcom-smmu: add missing linux/bug.h header for WARN_ON
The WARN macro requires inclusion of linux/bug.h header. It does
currently work as bitfield.h includes it indirectly but this will
change when bitfield.h will be synced with new Linux version.
Explicitly include the header to fix future compilation error.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The WARN macro requires inclusion of linux/bug.h header. It does
currently work as bitfield.h includes it indirectly but this will
change when bitfield.h will be synced with new Linux version.
Explicitly include the header to fix future compilation error.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tom Rini [Fri, 13 Jun 2025 22:57:34 +0000 (16:57 -0600)]
Merge patch series "drop volatile from global data"
Rasmus Villemoes <ravi@prevas.dk> says:
There's really no reason for the gd pointer to have the volatile
qualifier.
In fact, I claim that it's completely unnecessary and just pessimizes
code generation and forces ugly casts in lots of places. For example,
see the casts in drivers/core/tag.c where elements are added to
gd->dm_taglist, or a helper such as cyclic_get_list() that should not
be needed.
Also, it is what ends up standing in the way of an otherwise
innocent code cleanup of list.h:
https://lore.kernel.org/u-boot/20250522165656.GB2179216@bill-the-cat/
Note that riscv, x86 as well as arm64 with LTO enabled has not had
this volatile qualifier, so it's unlikely there's any generic code
that depends on it.
It's slightly ironic that riscv at very first had the gd pointer
volatile qualified [6020faf62c3 ("riscv: nx25: include: Add header
files to support RISC-V")], removed that back in 2018
[40717eb849c ("riscv: checkpatch: Fix use of volatile")], and then in
2020 this helper was added [6b9966e1aa3 ("riscv: define function
set_gd()")] which needlessly had volatile in the prototype.
The global gd pointer is no longer volatile-qualified. Callers of this
helper function have been updated to no longer use volatile-qualifed
temporary variables, so update the prototype accordingly.
arm: imx: remove unnecessary volatile qualifiers from "save gd" variables
Now that the global gd pointer is no longer volatile-qualified,
there's no reason for the temporary variables used for
saving/restoring it to have that qualifier.
The way DECLARE_GLOBAL_DATA_PTR is used, the stuff under #if 0 can
never compile as you cannot have a non-constant initializer at global
scope (and one would get linker errors as well because the 'gd' symbol
would be defined in multiple TUs).
There's a bunch of other places where this qualifier should be
dropped, e.g. in the set_gd() prototype and for various variables used
for stashing the value in the mach-imx/ directory and elsewhere. But
that will be done in follow-up patches.
Raymond Mao [Wed, 4 Jun 2025 15:48:11 +0000 (08:48 -0700)]
sandbox: solve undefined reference to pthread_kill symbol
This patch is to solve the sandbox building error:
$ make O=build-sandbox -s sandbox_defconfig
$ make O=build-sandbox -s -j2
/usr/bin/ld: /tmp/u-boot.27rzOu.ltrans58.ltrans.o: undefined reference to symbol 'pthread_kill@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
[...]
Fixes: b989f9ed9fe1 ("test: lib: add initjmp() test") Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Simon Glass [Wed, 28 May 2025 12:32:08 +0000 (06:32 -0600)]
spl: Rename jump_to_image_no_args()
This function is currently a misnomer at times as we have cases where it
passes arguments to the image. In preparation for making that be a more
common case rename this function to jump_to_image(...). In order to do
this, rename jump_to_image in board_init_r(...) to jumper so that we do
not have a conflict.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Reword the commit message, adding missing cases of
jump_to_image_no_args()] Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Thu, 12 Jun 2025 22:27:02 +0000 (16:27 -0600)]
Merge patch series "ti: Add support for eCAP PWM and LCD pin mux"
Sukrut Bellary <sbellary@baylibre.com> says:
This patch series adds the support for
1. In am33xx SoC[1], enhanced capture (eCAP) supports auxiliary PWM (APWM).
This series adds the PWM driver support for the APWM feature for eCAP on
AM33xx. AM335X_ECAP0_IN_PWM0_OUT is used to enable the backlight.
2. Fix build warning in ti-ehrpwm driver in dev_deb().
3. Enable eCAP0 PWM and LCD pin muxing to support splash screen on
AM335x EVM[2].
per discussion on the earlier patch series,
https://lore.kernel.org/all/20250319202516.3300444-1-sbellary@baylibre.com/
dropping the device tree changes in this series due to OF_UPSTREAM
conflict.
As we are dropping the DT patch, started with the new series instead of
V2.
This series doesn't contain defconfig changes since we don't want to
enable LCD, splash screen and PWM support by default.
Enabling splash screen and PWM support in defconfig causes u-boot crash
on AM335x based beaglebone black. This will be handled in a separate
patch.
Sukrut Bellary [Fri, 30 May 2025 21:22:32 +0000 (14:22 -0700)]
board: ti: am335x: Enable eCAP0 PWM and LCD pin muxing
On AM335x EVM[1],
1. pin AM335X_ECAP0_IN_PWM0_OUT is used to enable the
backlight. ECAP0 can be configured in single channel PWM mode.
If CONFIG_PWM_TI_ECAP is enabled, perform eCAP0 pin muxing.
2. Pins LCD_DATA0 - LCD_DATA15, gpmc_ad8 - gpmc_ad15 and
lcd_vsync, lcd_sync, lcd_ac_bias_en, lcd_pclk are used for driving LCD.
If CONFIG_AM335X_LCD is enabled, perform the LCD pin muxing.
This is required to enable splash screen support on AM335x EVM.
[1] AM335x EVM - https://www.ti.com/tool/TMDXEVM3358
Sukrut Bellary [Fri, 30 May 2025 21:22:30 +0000 (14:22 -0700)]
pwm: ti: am33xx: Enable Auxiliary PWM using eCAP
In am33xx SoC[1], enhanced capture (eCAP) supports auxiliary PWM (APWM).
This series adds the PWM driver support for the APWM feature for eCAP on
AM33xx.
eCAP HW also supports the capture mode. Currently, this driver only
supports APWM.
This is based on the Linux kernel driver -> drivers/pwm/pwm-tiecap.c
Version: v6.12
Yao Zi [Mon, 2 Jun 2025 10:15:15 +0000 (10:15 +0000)]
ram: Move Kconfig options into their own menu entry
RAM drivers using Device Model currently lack of their own Kconfig menu
entry, which makes Kconfig put all options of the class in the top-level
menu of device drivers. These options are also incorrectly grouped with
pinctrl options in the generated .config, which is hard to read. Let's
create a menu entry for these drivers.
Fixes: 6c51df6859f ("dm: Add support for RAM drivers") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Tom Rini <trini@konsulko.com>
Although if we don't setup an initrd, there could be a stale initrd
setting from the previous boot firmware in the live device tree. So,
make sure there is no setting left if we don't want an initrd.
This can happen when booting on a Raspberry Pi. The boot firmware can
happily load an initrd before us and configuring the addresses in the
live device tree we get handed over.
Especially the setting `auto_initramfs` in config.txt is dangerous.
When enabled (default), the firmware tries to be smart and looks for
initramfs files.
Signed-off-by: Richard Weinberger <richard@nod.at>
Use lbaint_t for blknr to avoid overflow in ext4fs_read_file().
Background:
blknr (block number) used in ext4fs_read_file() could be increased to a
very large value and causes a wrap around at 32 bit signed integer max,
thus becomes negative. This results in an out-of-normal range for sector
number (during the assignment delayed_start = blknr) where delayed_start
sector is typed uint64 lbaint_t. This causes the "Read outside partition"
error.
Looks like we also have this overflown problem in ext4_write.c that needs
to be addressed.
This patch was tested on the Synology DS116 (Armada 385) board, and a
4TB Seagate HDD.
Bryan Brattlof [Thu, 15 May 2025 15:16:19 +0000 (10:16 -0500)]
binman: add atf-bl1 to etypes
Some SoCs require a Trusted Firmware-A (TF-A) AP Trusted ROM (BL1) to
initialize the SoC before U-Boot can run properly. Add an atf-bl1 etype
so we can properly package BL1 into a final binary
Signed-off-by: Bryan Brattlof <bb@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 29 May 2025 14:14:51 +0000 (08:14 -0600)]
test/py: Use the correct fixture name in exception handler
If a BootFail exception is thrown in a test, it is not handled
correctly. Use the correct fixture variable 'ubman_fix' to resolve this.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: d9ed4b75add ("test/py: Drop u_boot_ prefix on test files") Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Hiago De Franco [Thu, 12 Jun 2025 14:09:23 +0000 (11:09 -0300)]
toradex-smarc-imx8mp: add SPL_STACK size and SPL_HAVE_INIT_STACK
When the toradex-smarc-imx8mp_defconfig file was first added, SPL_STACK
was set to 0x960000, but SPL_HAVE_INIT_STACK wasn't enabled.
This led to SPL_STACK being correctly dropped in commit 25fefa05d732
("configs: Resync with savedefconfig"), since SPL_HAVE_INIT_STACK was
missing, which ended up making the board not boot.
Fix this by adding SPL_STACK back and making sure SPL_HAVE_INIT_STACK is
enabled.
Fixes: dde53eae88d6 ("board: toradex: add Toradex SMARC iMX8MP") Signed-off-by: Hiago De Franco <hiago.franco@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Hugo Villeneuve [Thu, 12 Jun 2025 13:35:18 +0000 (09:35 -0400)]
board: var-som-mx8mn: Fix alloc space exhausted in SPL
After enabling some options to support EEPROM read in SPL
(CONFIG_SPL_I2C_EEPROM), the following error appears:
alloc space exhausted
Increasing SYS_MALLOC_F_LEN from 8kB to 64kB fixes the problem.
But instead of manually increasing the value, adopt method used in
commit ce3f23404c19 ("board: bsh: imx8mn_bsh_smm_s2/s2pro: enlarge
CONFIG_SPL_SYS_MALLOC_F_LEN"):
Dropping CONFIG_SPL_SYS_MALLOC_F_LEN option allows it to be set to the
default value of CONFIG_SYS_MALLOC_F_LEN, which is set by default to 64kB
(0x10000) on i.MX8M platforms.
When doing the investigation for commit 53bb8fdea12a ("mmc: Kconfig:
Correct dependencies SDHCI ADMA options") I missed the implications of
MMC_SDHCI_ADMA_HELPERS. The problem is that FSL_ESDHC via the
FSL_ESDHC_SUPPORT_ADMA2 option will also enable these helper functions.
This in turn means the correct dependency here is
MMC_SDHCI_ADMA_HELPERS and not *MMC_SDHCI_ADMA.
Reported-by: Heiko Thiery <heiko.thiery@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 11 Jun 2025 19:31:45 +0000 (13:31 -0600)]
Merge patch series "dm: core: use {s,u}32 instead of int for dev_read_{s,u}32_default"
Quentin Schulz <foss+uboot@0leil.net> says:
Out of all the dev_read_*_default functions, only two do not properly
use the type as argument and return type: dev_read_u32_default and
dev_read_s32_default. They both use int instead of u32/s32.
Considering that it's generally not guaranteed that an int is 4 bytes
but also for consistency sake, let's have them use the expected type.
Note that I have not tested this, just stumbled upon that inconsistency
by chance.
Quentin Schulz [Wed, 28 May 2025 13:06:19 +0000 (15:06 +0200)]
dm: core: use s32 instead of int for dev_read_s32_default
dev_read_s32_default is for getting an s32 from a Device Tree property
and allows to take a default value if that property is missing.
Considering it calls ofnode_read_u32_default which takes a u32 and
returns a u32, it should do the same instead of using an int, especially
considering that int size is typically architecture-specific, as opposed
to s32/u32.
s32 and u32 being the same size, dev_read_s32* functions calling
ofnode_read_u32_default shouldn't be an issue (at the type level at
least) as the information will be stored appropriately in 4B regardless
of the sign.
This incidentally matches all other dev_read_*_default functions.
Fixes: a1b17e4f4c82 ("dm: core: Add a function to read into a unsigned int") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Quentin Schulz [Wed, 28 May 2025 13:06:18 +0000 (15:06 +0200)]
dm: core: use u32 instead of int for dev_read_u32_default
dev_read_u32_default is for getting a u32 from a Device Tree property
and allows to take a default value if that property is missing.
Considering it calls ofnode_read_u32_default which takes a u32 and
returns a u32, it should do the same instead of using an int, especially
considering that int size is typically architecture-specific, as opposed
to u32.
This incidentally matches all other dev_read_*_default functions (except
dev_read_s32_default which will be tackled in the next commit).
Fixes: 47a0fd3bad38 ("dm: core: Implement live tree 'read' functions") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
- Add clock and reset drivers support for STM32MP25
- Add STM32H747-Discovery board support
- Add tamp_nvram driver
- Add SPL support and clock tree init to STM32MP13 RCC driver
- Add STM32MP13xx ram support
- Add support for STM32 Image V2.0 for STM32MP13xx
- Fix SYSRAM size on STM32MP13xx
- Fix DBGMCU macro on STM32MP13xx
- Auto-detect ROM API table on STM32MP15xx
Dario Binacchi [Sat, 7 Jun 2025 09:37:17 +0000 (11:37 +0200)]
board: stm32: add stm32h747-discovery board support
The board includes an STM32H747XI SoC with the following resources:
- 2 Mbytes Flash
- 1 Mbyte SRAM
- LCD-TFT controller
- MIPI-DSI interface
- FD-CAN
- USB 2.0 high-speed/full-speed
- Ethernet MAC
- camera interface
Detailed information can be found at:
https://www.st.com/en/evaluation-tools/stm32h747i-disco.html
The board includes an STM32H747XI SoC with the following resources:
- 2 Mbytes Flash
- 1 Mbyte SRAM
- LCD-TFT controller
- MIPI-DSI interface
- FD-CAN
- USB 2.0 high-speed/full-speed
- Ethernet MAC
- camera interface
Detailed information can be found at:
https://www.st.com/en/evaluation-tools/stm32h747i-disco.html
dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK
As stated in the reference manual RM0433, the STM32H743 MCU has
USART1/2/3/6, UART4/5/7/8, and LPUART1. The patches make all the clock
macros for the serial ports consistent with the documentation.
dt-bindings: arm: stm32: add compatible for stm32h747i-disco board
The board includes an STM32H747XI SoC with the following resources:
- 2 Mbytes Flash
- 1 MByte SRAM
- LCD-TFT controller
- MIPI-DSI interface
- FD-CAN
- USB 2.0 high-speed/full-speed
- Ethernet MAC
- camera interface
Detailed information can be found at:
https://www.st.com/en/evaluation-tools/stm32h747i-disco.html
Marek Vasut [Mon, 12 May 2025 17:09:47 +0000 (19:09 +0200)]
tools: stm32image: Add support for STM32 Image V2.0
Add support for generating STM32 Image V2.0, which is used by STM32MP13xx.
The image header layout is similar to STM32MP15xx STM32 Image V1.0, but is
different enough to justify duplicate functions to generate the v2 image.
This code at least attempts to align the V1 and V2 image handling where
possible.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Marek Vasut [Mon, 12 May 2025 17:09:05 +0000 (19:09 +0200)]
ram: stm32mp1: Add STM32MP13xx support
Add support for configuring DRAM controller on STM32MP13xx SoC.
The DRAM controller is basically identical to the DWC controller
on STM32MP15xx SoC, except the bus width is reduced from 32bit to
16bit and a few registers and bits are therefore not present.
Handle the difference by factoring these parts out. Use IS_ENABLE()
as much as possible to assure code which is not enabled on builds
for a single SoC gets compiled out. Handle the different offset of
RCC_DDRITFCR register and missing DDRC2 clock the same way.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Marek Vasut [Mon, 12 May 2025 17:08:29 +0000 (19:08 +0200)]
clk: stm32mp13: Add SPL support and clock tree init to STM32MP13 RCC driver
Add SPL support and clock tree init to STM32MP13 RCC driver. This
consists of two parts, make SCMI into an optional dependency and
add clock tree initialization. The SCMI dependency is made optional
first by registering the few core clock provided by SCMI clock as
fixed clock, and second by letting the clock core parse out the
clock configuration from SoC registers. The clock initialization
code is derived from STM32MP15xx clock tree initialization code,
which is almost identical, except for the use of new PLL2000 for
PLL1 on STM32MP13xx .
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Marek Vasut [Mon, 12 May 2025 16:45:14 +0000 (18:45 +0200)]
ARM: stm32: Auto-detect ROM API table on STM32MP15xx
The ROM API table location is passed to the SPL by BootROM in register r0,
make use of this, store the content of r0 and later use it to access the
ROM API table to determine current boot device.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Mon, 12 May 2025 16:44:53 +0000 (18:44 +0200)]
ARM: stm32: Fix DBGMCU macro on STM32MP13xx
The DBGMCU block is available at address 0x50081000 both on STM32MP13xx
and on STM32MP15xx . There is no reason to limit the DBGMCU macro being
set only on STM32MP15xx , remove the ifdeffery.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Mon, 12 May 2025 16:44:04 +0000 (18:44 +0200)]
ARM: stm32: Fix SYSRAM size on STM32MP13xx
The STM32MP13xx has only 128 kiB of SYSRAM starting at address 0x2ffe0000 .
The STM32MP15xx has 256 kiB of SYSRAM starting at address 0x2ffc0000 . Make
sure both SoCs configure ARMV7_SECURE_BASE correctly . Define the SYSRAM
base in stm32.h to be consistent with the STM32MP15xx macro.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
In RCC the ops of the CCF registered CLK device can be called directly,
this patch avoid recursive call of clk_ function done by CCF clock
framework which update the clock information, for example
clk_enable is called 2 times, clkp->enable_count is increased 2 times.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patrick Delaunay [Tue, 27 May 2025 13:27:50 +0000 (15:27 +0200)]
clk: scmi: manage properly the clk identifier with CCF
Each clock identifier needs to be unique when CCF is activated,
and it is not respected today by SCMI clock driver.
This patch supports a unique clk id by using the uclass API
clk_get_id() / dev_clk_dm() and by activating by default
CONFIG_CLK_AUTO_ID with CCF which adds an offset to the SCMI
clock identifiers.
After this patch, the SCMI clock driver can coexist with other
clock provider without conflict, they can share internal identifier
[0..N] defined in their binding and the clock ID = 0
(reserved for dummy clock) is no more used.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patrick Delaunay [Tue, 27 May 2025 13:27:49 +0000 (15:27 +0200)]
clk: fixed_rate: configure clock ID with CONFIG_CLK_AUTO_ID
Update CLK ID to avoid 0 id, used for dummy clock with CCF
and to allow selection by clk_get_by_id, used to
get private data associated to the UCLASS_CLK device
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patrick Delaunay [Tue, 27 May 2025 13:27:46 +0000 (15:27 +0200)]
clk: add CONFIG_CLK_AUTO_ID
Add a new config CONFIG_CLK_AUTO_ID to support a unique clk id
for all the clock providers, managed by clk uclass, when the clock
reference arg[0] is the same.
When the CONFIG is activated, the clock id is limited to the lower
CLK_ID_SZ = 24 bits in default clock xlate function
and the sequence number + 1 of the clk provider device is
added for the 8 higher bits.
We use sequence number + 1 to avoid the "dummy" clock id = 0,
used for invalid clock when CCF is activated.
When this config is activated, the new function clk_get_id()
should be used to get back the internal reference to clock
for the each clock provider.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
projects / thirdparty / u-boot.git / log
