feat(k3): handle suspend in case of LPM_BOARDCFG_MANAGED

The J7 platforms support LPM_BOARDCFG_MANAGED[1] capability where the
low power mode configuration is done statically for the DM via the
pm-b

feat(k3): handle suspend in case of LPM_BOARDCFG_MANAGED

The J7 platforms support LPM_BOARDCFG_MANAGED[1] capability where the
low power mode configuration is done statically for the DM via the
pm-boardcfg. The specific suspend modes (eg: LPM_SOC_OFF, LPM_MCU_ONLY)
are not sent as a separate firmware capability like they are in the case
of LPM_DM_MANAGED.

Hence, split the firmware capability check to first look for the
DM_MANAGED or BOARDCFG_MANAGED capability and register the
pwr_domain_suspend psci callback accordingly.

Introduce LPM_BOARDCFG_MANAGED cap to handle suspend for J7
platforms as well.

Link: [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-fw-caps

Change-Id: Iaa0ab478cbe0db6652f61e9d733c0fddb4bab234
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>

show more ...

feat(ti): add message to encrypt tfa during suspend

On some K3 plaforms, BL31 runs from an internal SRAM. During low power
modes like SOC_OFF, IO_ONLY_PLUS_DDR etc, the power to the SRAM
is cut off

feat(ti): add message to encrypt tfa during suspend

On some K3 plaforms, BL31 runs from an internal SRAM. During low power
modes like SOC_OFF, IO_ONLY_PLUS_DDR etc, the power to the SRAM
is cut off and only the DDR is active in self-refresh state.

Hence at suspend, BL31 with its context should be encrypted by TIFS and
saved in DDR. Encryption is needed so that the BL31 is not tampered with
while in DRAM.

We only need the encryption function here because the decryption message
will be send by the R5 SPL at resume.

Also introduce the LPM_ENCRYPT_IMAGE[1] capability which signals that FW
has the support to encrypt the image using the TISCI_MSG_LPM_ENCRYPT[2]
tisci message.

The encrypt_tfa message requires that the LPM_SAVE_ADDR[3] message is sent
during boot. This is taken care of by the bootloader.

Link: [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-fw-caps
Link: [2] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#lpm-msg-lpm-encrypt
Link: [3] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#lpm-msg-lpm-save-addr

Change-Id: I266472da87dd0821493019b2d9853f8886f33811
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>

show more ...

feat(k3): choose PLAT_CLUSTER_DEVICE_START_ID depending on the SoC

The CLUSTER_DEVICE_START_ID denotes the device id of the A-core cluster.
It is utilized when powering off the entire cluster.

The

feat(k3): choose PLAT_CLUSTER_DEVICE_START_ID depending on the SoC

The CLUSTER_DEVICE_START_ID denotes the device id of the A-core cluster.
It is utilized when powering off the entire cluster.

The "generic" boards include J7200, J721E, J721S2 and AM65X platforms.

PLAT_CLUSTER_DEVICE_START_ID should be 4 instead of 198 on J7200[1],
J721E[2] and J721S2[3]. It is 198 only for AM65X[4].

This breaks PSCI APIs around cluster control and is exposed when
suspend-to-ram is enabled.

Query the JTAG_ID to get the SoC part number and choose the
CLUSTER_DEVICE_START_ID_AM65X when AM65X SoC is detected, else use
the PLAT_CLUSTER_DEVICE_START_ID that is defined in the respective
"board_def" file.

Link: [1] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/devices.html
Link: [2] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721e/devices.html
Link: [3] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721s2/devices.html
Link: [4] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am65x_sr2/devices.html

Change-Id: Idcd47c94e06996e8c1d68b49f13d4d693e95b17d
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>

show more ...

feat(k3): add SoC detection support

Implement SoC detection by reading the part number from the JTAG_ID
register. The part number is used to determine the appropriate cluster
start ID for the SoC.

feat(k3): add SoC detection support

Implement SoC detection by reading the part number from the JTAG_ID
register. The part number is used to determine the appropriate cluster
start ID for the SoC.

Note: J742S2 and J784S4 have the same part number and cluster start ID,
so they are handled identically without additional logic.

Change-Id: Ie97e123627b562edf34e7ff3839f6ceb8b0bbd8b
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>

show more ...

feat(ti): enable power state validation for K3 SoCs

Add power state validation for K3 SoCs to ensure proper PSCI power state
transitions. Defining validate_power_state enables the
PSCI_CPU_SUSPEND_A

feat(ti): enable power state validation for K3 SoCs

Add power state validation for K3 SoCs to ensure proper PSCI power state
transitions. Defining validate_power_state enables the
PSCI_CPU_SUSPEND_AARCH64 capability and, in turn, CPU_SUSPEND.

validate_power_state checks if the requested power level and power state
are in a valid configuration. If the power state requested is standby,
set the core power state to the maximum retention state.

Change-Id: Ied3ebdc583b2e5b7c86923705954d763997b324e
Signed-off-by: Kendall Willis <k-willis@ti.com>

show more ...

fix(ti): remove validate_power_state definition

validate_power_state should not be defined since CPU suspend is not yet
supported.

Defining the validate_power_state function without any meaningful

fix(ti): remove validate_power_state definition

validate_power_state should not be defined since CPU suspend is not yet
supported.

Defining the validate_power_state function without any meaningful logic
caused a bug where a crash would happen if a device tried to enter a power
state that was not yet supported by TFA. This is because
validate_power_state would return a pass when the state was not properly
checked.

Removing the validate_power_state definition disables the
PSCI_CPU_SUSPEND_AARCH64 capability which will prevent the HLOS from
trying to suspend the CPU all together. This will fix the aforementioned
bug from occurring.

Fixes: 2e9c9e829964 ("ti: k3: common: Add PSCI stubs")
Change-Id: I3bbbd228fbddea64e72f0cf50afc6b25fb6d317c
Signed-off-by: Kendall Willis <k-willis@ti.com>

show more ...

refactor(ti): move out k3/common to ti/common

This will allow us to support more platforms that share commonalities
like the k3_gicv3, console, helpers, etc.
With this new common folder location, we

refactor(ti): move out k3/common to ti/common

This will allow us to support more platforms that share commonalities
like the k3_gicv3, console, helpers, etc.
With this new common folder location, we can move the previously
created ti_bl31_setup file into the new location so it can be shared
across multiple TI SoCs when need comes.
With this, also update all copyright dates.

Change-Id: Ie4365e32cd3b4b5870fe2cd03843400506e46265
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): introduce ti_bl31_setup

There maybe a lot of reuse between platforms for bl31_setup in future
which may require us to have a common bl31 setup driver for TI.
The ti_bl31_setup is expec

refactor(ti): introduce ti_bl31_setup

There maybe a lot of reuse between platforms for bl31_setup in future
which may require us to have a common bl31 setup driver for TI.
The ti_bl31_setup is expected to contain all the reusable bits
and the soc_bl31_setup can have the custom soc init functionality
like the mmap regions and any special sequences needed at
device boot
While at it, also fix the path of the reference to the kernel doc
for booting.

Change-Id: Ie574f08cf3ba75362c45f85306499061ef89c964
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): add top level ti_sci transport layer

The TI SCI transport header will allow us to abstract all transport
related calls from the actual medium of transport which can vary
from device to

refactor(ti): add top level ti_sci transport layer

The TI SCI transport header will allow us to abstract all transport
related calls from the actual medium of transport which can vary
from device to device.
For eg. it is sec proxy for current TI K3 devices, but in future it
maybe mailbox like in the TI AM62L.
With this change, we no longer need to include anything from the IPC
folder, so drop it from plat_common.mk

Change-Id: Ic99209688cf69f20e694e31e553ce4ec74254669
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

refactor(ti): move TI SCI and sec proxy to drivers

Prepare to support more devices and abstract TI SCI and it's transport
layers. This refactor will help keep things clean when new ipc drivers
get a

refactor(ti): move TI SCI and sec proxy to drivers

Prepare to support more devices and abstract TI SCI and it's transport
layers. This refactor will help keep things clean when new ipc drivers
get added.

Change-Id: I05673f379b1398c0b6a2bd9e1b5392165d12f151
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

feat(ti): implement DM_MANAGED suspend

DM_MANAGED is the new mode to support a model where DM chooses the
suspend mode. Previously suspend always chose deep sleep. Now DM may
also choose other modes

feat(ti): implement DM_MANAGED suspend

DM_MANAGED is the new mode to support a model where DM chooses the
suspend mode. Previously suspend always chose deep sleep. Now DM may
also choose other modes like IO+DDR or other modes in the future. DM has
more knowledge about constraints regarding wakeup latency or which parts
of the system need to work continuously, so it is better able to decide
what suspend mode should be used.

To support DM_MANAGED in TF-A the next system mode needs to be fetched
and passed to the enter sleep message. The new ti_sci command to fetch
the next system mode is added which is ti_sci_lpm_get_next_sys_mode().

DM_MANAGED is only enabled if the firmware capability is supported.

Change-Id: I7244e27793cc60e1673271990d7cd840294d6cc3
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>

show more ...