u-boot.git/drivers/remoteproc, branch v2022.01

remoteproc: migrate uclass to livetree

2021-10-05T12:50:15Z

Use dev_ function to read the name and boolean to support a live tree. Signed-off-by: Patrick Delaunay Reviewed-by: Simon Glass

remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs

2021-07-15T12:26:04Z

The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem, commonly referred to as ICSSG. Each ICSSG processor subsystem on AM65x SR1.0 contains two primary PRU cores and two new auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs. This IP instance has two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs. Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than a PRU), Control and debug feature sets, but is different in terms of sub-modules integrated around it and does not have the full capabilities associated with a PRU core. The RTU core is typically used to aid a PRU core in accelerating data transfers, while the Tx_PRU cores is normally used to control the TX L2 FIFO if enabled in Ethernet applications. Both can also be used to run independent applications. The RTU and Tx_PRU cores though share the same Data RAMs as the PRU cores, so the memories have to be partitioned carefully between different applications. The new cores also support a new sub-module called Task Manager to support two different context thread executions. The driver currently supports the AM65xx SoC Signed-off-by: Keerthy Signed-off-by: Suman Anna Signed-off-by: Murali Karicheri Signed-off-by: Roger Quadros Signed-off-by: Lokesh Vutla Link: https://lore.kernel.org/r/20210622063431.3151-3-lokeshvutla@ti.com

dm: define LOG_CATEGORY for all uclass

2021-07-06T16:38:03Z

Define LOG_CATEGORY for all uclass to allow filtering with log command. Signed-off-by: Patrick Delaunay Reviewed-by: Simon Glass

remoteproc: k3-r5: remove sysfw PM calls if not supported

2021-06-11T11:04:52Z

With the sysfw rearch, sysfw PM calls are no longer available from SPL level. To properly support this, remove the is_on checks and the reset assertion from the R5 remoteproc driver as these are not supported. Attempting to access unavailable services will cause the device to hang. Signed-off-by: Tero Kristo Signed-off-by: Tero Kristo

Merge branch '2021-02-02-drop-asm_global_data-when-unused'

2021-02-15T15:16:45Z

- Merge the patch to take out of

remoteproc: k3_r5: Sync to upstreamed kernel DT property names

2021-02-04T15:07:56Z

The K3 R5F remoteproc driver in U-Boot was upstreamed prior to the equivalent remoteproc driver in the Linux kernel. Some of the DT properties used in U-Boot got upstreamed using different names in Linux kernel. The modified property names include the R5F cluster mode configuration property "lockstep-mode"; and three different individual R5F core config properties - "atcm-enable", "btcm-enable" and "loczrama". The property names were updated as follows: lockstep-mode => ti,cluster-mode atcm-enable => ti,atcm-enable btcm-enable => ti,btcm-enable loczrama => ti,loczrama Update the K3 R5F remoteproc driver, the corresponding binding, and all the existing usage in AM65x, J721E and J7200 dts files all at once to use the new properties and to not break any bisectability. Signed-off-by: Suman Anna

common: Drop asm/global_data.h from common header

2021-02-02T20:33:42Z

Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include at all, so remove that include. Signed-off-by: Simon Glass Signed-off-by: Tom Rini

remoproc: stm32: migrate trace to log macro

2021-01-13T08:52:58Z

Define LOG_CATEGORY and remove unneeded pr_fmt macro with the dev macro as dev->name is displayed and CONFIG_LOGF_FUNC can be activated for log macro. Signed-off-by: Patrick Delaunay Reviewed-by: Patrice Chotard

remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC

2021-01-12T05:29:04Z

ARMv8's generic timer[1] picks up it's graycode from GTC. However, the frequency of the GTC is supposed to be programmed in CNTFID0[2] register prior to enabling the GTC in CNTCR[3] register. In K3 architecture, GTC provides a central time to many parts of the SoC including graycode to the generic timer in the ARMv8 subsystem. However, due to the central nature and the need to enable the counter early in the boot process, the R5 based u-boot enables GTC and programs it's frequency based on central needs of the system. This may not be a constant 200MHz based on the system. The bootloader is supposed to program the FID0 register with the correct frequency it has sourced for GTC from the central system controller OR from PLLs as appropriate, and TF-A is supposed[4] to use that as the frequency for it's local timer. Currently we are programming just the CNTCR[3] register to enable the GTC, however we dont let TF-A know the frequency that GTC is actually running at. A mismatch in programmed frequency and what we program for generic timer will, as we can imagine, all kind of weird mayhem. So, program the CNTFID0 register with the clock frequency. Note: assigned-clock-rates should have set the clock frequency, so the only operation we need to explicitly do is to retrieve the frequency and program it in FID0 register. Since the valid in K3 for GTC clock frequencies are < U32_MAX, we can just cast the ulong and continue. [1] https://developer.arm.com/documentation/100095/0002/generic-timer/generic-timer-register-summary/aarch64-generic-timer-register-summary [2] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntfid0 [3] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntcr [4] https://github.com/ARM-software/arm-trusted-firmware/commit/6a22d9ea3c7fa28d053d3ba264b49b7396a86f9e Signed-off-by: Nishanth Menon

dm: Rename U_BOOT_DEVICE() to U_BOOT_DRVINFO()

2021-01-05T19:26:35Z

The current macro is a misnomer since it does not declare a device directly. Instead, it declares driver_info record which U-Boot uses at runtime to create a device. The distinction seems somewhat minor most of the time, but is becomes quite confusing when we actually want to declare a device, with of-platdata. We are left trying to distinguish between a device which isn't actually device, and a device that is (perhaps an 'instance'?) It seems better to rename this macro to describe what it actually is. The macros is not widely used, since boards should use devicetree to declare devices. Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is declaring a new driver_info record, not a device. Signed-off-by: Simon Glass