Add support for Partial-IO poweroff. In Partial-IO pins of a few
hardware units can generate system wakeups while DDR memory is not
powered resulting in a fresh boot of the system. These hardware units in
the SoC are always powered so that some logic can detect pin activity.
If the system supports Partial-IO as described in the fw capabilities, a
sys_off handler is added. This sys_off handler decides if the poweroff
is executed by entering normal poweroff or Partial-IO instead. The
decision is made by checking if wakeup is enabled on all devices that
may wake up the SoC from Partial-IO.
The possible wakeup devices are found by checking which devices
reference a "Partial-IO" system state in the list of wakeup-source
system states. Only devices that are actually enabled by the user will
be considered as an active wakeup source. If none of the wakeup sources
is enabled the system will do a normal poweroff. If at least one wakeup
source is enabled it will instead send a TI_SCI_MSG_PREPARE_SLEEP
message from the sys_off handler. Sending this message will result in an
immediate shutdown of the system. No execution is expected after this
point. The code will wait for 5s and do an emergency_restart afterwards
if Partial-IO wasn't entered at that point.
A short documentation about Partial-IO can be found in section 6.2.4.5
of the TRM at
https://www.ti.com/lit/pdf/spruiv7
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Reviewed-by: Sebin Francis <sebin.francis@ti.com>
Link: https://patch.msgid.link/20251103-topic-am62-partialio-v6-12-b4-v10-2-0557e858d747@baylibre.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Check the header flags if an response is expected or not. If it is not
expected skip the receive part of ti_sci_do_xfer(). This prepares the
driver for one-way messages as prepare_sleep for Partial-IO.
Reviewed-by: Kendall Willis <k-willis@ti.com>
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Sebin Francis <sebin.francis@ti.com>
Link: https://patch.msgid.link/20251103-topic-am62-partialio-v6-12-b4-v10-1-0557e858d747@baylibre.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Prevent calling ti_sci_cmd_set_io_isolation() on firmware
that does not support the IO_ISOLATION capability. Add the
MSG_FLAG_CAPS_IO_ISOLATION capability flag and check it before
attempting to set IO isolation during suspend/resume operations.
Without this check, systems with older firmware may experience
undefined behavior or errors when entering/exiting suspend states.
Fixes: ec24643bdd ("firmware: ti_sci: Add system suspend and resume call")
Signed-off-by: Thomas Richard (TI.com) <thomas.richard@bootlin.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Link: https://patch.msgid.link/20251031-ti-sci-io-isolation-v2-1-60d826b65949@bootlin.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The PM co-processor (device manager or DM) adds the ability to abort
entry to a low power mode by clearing the mode selection in the
latest version of its firmware (11.01.09) [1].
Enable the ti_sci driver to support the LPM abort call which clears the
low power mode selection of the DM. This fixes an issue where failed
system suspend attempts would cause subsequent suspends to fail.
After system suspend completes, regardless of if system suspend succeeds
or fails, the ->complete() hook in TI SCI will be called. In the
->complete() hook, a message will be sent to the DM to clear the current
low power mode selection. Clearing the low power mode selection
unconditionally will not cause any error in the DM.
[1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html
Signed-off-by: Kendall Willis <k-willis@ti.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/20250819195453.1094520-1-k-willis@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Fix CPU resume latency constraint units sent to device manager through the
TI SCI API. The device manager expects CPU resume latency to be in msecs
which is passed in with the TI SCI API [1]. CPU latency constraints are
set in userspace using the PM QoS framework which uses usecs as the unit.
Since PM QoS uses usecs for units and the device manager expects msecs as
the unit, TI SCI needs to convert from usecs to msecs before passing to
device manager.
[1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html#tisci-msg-lpm-set-latency-constraint
Cc: stable@vger.kernel.org
Fixes: a7a15754c7 ("firmware: ti_sci: add CPU latency constraint management")
Signed-off-by: Kendall Willis <k-willis@ti.com>
Link: https://lore.kernel.org/r/20250428205336.2947118-1-k-willis@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
When OF support is disabled the of_device_id struct match table can be
conditionally compiled out, this helper allows the assignment to also be
turned into a NULL conditionally. When the of_device_id struct is not
conditionally defined based on OF then the table will be unused causing a
warning. The two options are to either set the table as _maybe_unused, or
to just remove this helper since the table will always be defined.
Do the latter here.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20241015213322.2649011-2-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
During system-wide suspend, check if any of the CPUs have PM QoS
resume latency constraints set. If so, set TI SCI constraint.
TI SCI has a single system-wide latency constraint, so use the max of
any of the CPU latencies as the system-wide value.
Note: DM firmware clears all constraints at resume time, so
constraints need to be checked/updated/sent at each system suspend.
Co-developed-by: Vibhore Vardhan <vibhore@ti.com>
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-5-ed54cd659a49@baylibre.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Introduce power management ops supported by the TISCI
Low Power Mode API [1].
1) TISCI_MSG_LPM_WAKE_REASON
Get which wake up source woke the SoC from Low Power Mode.
The wake up source IDs will be common for all K3 platforms.
2) TISCI_MSG_LPM_SET_DEVICE_CONSTRAINT
Set LPM constraint on behalf of a device. By setting a constraint, the
device ensures that it will not be powered off or reset in the selected
mode.
3) TISCI_MSG_LPM_SET_LATENCY_CONSTRAINT
Set LPM resume latency constraint. By setting a constraint, the host
ensures that the resume time from selected mode will be less than the
constraint value.
[1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[g-vlaev@ti.com: LPM_WAKE_REASON and IO_ISOLATION support]
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
[a-kaur@ti.com: SET_DEVICE_CONSTRAINT support]
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
[vibhore@ti.com: SET_LATENCY_CONSTRAINT support]
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Akashdeep Kaur <a-kaur@ti.com>
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-4-ed54cd659a49@baylibre.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Introduce system suspend call that enables the ti_sci driver to support
low power mode when the user space issues a suspend to mem.
The following power management operations defined in the TISCI
Low Power Mode API [1] are implemented to support suspend and resume:
1) TISCI_MSG_PREPARE_SLEEP
Prepare the SOC for entering into a low power mode and
provide details to firmware about the state being entered.
2) TISCI_MSG_SET_IO_ISOLATION
Control the IO isolation for Low Power Mode.
Also, write a ti_sci_prepare_system_suspend call to be used in the driver
suspend handler to allow the system to identify the low power mode being
entered and if necessary, send TISCI_MSG_PREPARE_SLEEP with information
about the mode being entered.
Sysfw version >= 10.00.04 support LPM_DM_MANAGED capability [2], where
Device Mgr firmware now manages which low power mode is chosen. Going
forward, this is the default configuration supported for TI AM62 family
of devices. The state chosen by the DM can be influenced by sending
constraints using the new LPM constraint APIs.
In case the firmware does not support LPM_DM_MANAGED mode, the mode
selection logic can be extended as needed. If no suspend-to-RAM modes
are supported, return without taking any action.
We're using "pm_suspend_target_state" to map the kernel's target suspend
state to SysFW low power mode. Make sure this is available only when
CONFIG_SUSPEND is enabled.
Suspend has to be split into two parts, ti_sci_suspend() will send
the prepare sleep message to prepare suspend. ti_sci_suspend_noirq()
sets IO isolation which needs to be done as late as possible to avoid
any issues. On resume this has to be done as early as possible.
[1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html
Co-developed-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Tested-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-3-ed54cd659a49@baylibre.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add support for the TISCI_MSG_QUERY_FW_CAPS message, used to retrieve
the firmware capabilities of the currently running system firmware. The
message belongs to the TISCI general core message API [1] and is
available in SysFW version 08.04.03 and above. Currently, the message is
supported on devices with split architecture of the system firmware (DM
+ TIFS) like AM62x. Old revisions or not yet supported platforms will
NACK this request.
We're using this message locally in ti_sci.c to get the low power
features of the FW/SoC. As there's no other kernel consumers yet, this
is not added to struct ti_sci_core_ops.
Sysfw version >= 10.00.04 support LPM_DM_MANAGED capability [2], where
Device Mgr firmware now manages which low power mode is chosen. Going
forward, this is the default configuration supported for TI AM62 family
of devices. The state chosen by the DM can be influenced by sending
constraints using the new LPM constraint APIs.
[1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html
[2] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-fw-caps
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
[vibhore@ti.com: Support for LPM_DM_MANAGED mode]
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-2-ed54cd659a49@baylibre.com
Signed-off-by: Nishanth Menon <nm@ti.com>
There was once a limitation that there could only be one system
reset handler. Due to that we only would register this handler
when a non-standard device tree property was found, else we left
the default handler in place (usually PSCI). Now that we can
have multiple handlers, and TI-SCI reset is always available
in the firmware, register this handler unconditionally.
This priority is left at the default so higher priority handlers
(like PSCI) are still attempted first.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/r/20240326223730.54639-3-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Use device life-cycle managed register function to simplify probe.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Gabriel Somlo <gsomlo@gmail.com>
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/r/20240326223730.54639-2-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
The ending NULL is not taken into account by strncat(), so switch to
snprintf() to correctly build 'debug_name'.
Using snprintf() also makes the code more readable.
Fixes: aa276781a6 ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/7158db0a4d7b19855ddd542ec61b666973aad8dc.1698660720.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Nishanth Menon <nm@ti.com>
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231006224638.445168-1-robh@kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
The TI-SCI message protocol provides a way to communicate between
various compute processors with a central system controller entity. It
provides the fundamental device management capability and clock control
in the SOCs that it's used in.
The remove function failed to do all the necessary cleanup if
there are registered users. Some things are freed however which
likely results in an oops later on.
Ensure that the driver isn't unbound by suppressing its bind and unbind
sysfs attributes. As the driver is built-in there is no way to remove
device once bound.
We can also remove the ti_sci_remove call along with the
ti_sci_debugfs_destroy as there are no callers for it any longer.
Fixes: aa276781a6 ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Closes: https://lore.kernel.org/linux-arm-kernel/20230216083908.mvmydic5lpi3ogo7@pengutronix.de/
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230921091025.133130-1-d-gole@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Convert list_for_each() to list_for_each_entry() so that the p
list_head pointer and list_entry() call are no longer needed, which
can reduce a few lines of code. No functional changed.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230830090344.528818-1-ruanjinjie@huawei.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Fix up documentation errors, squashes the following warnings:
drivers/firmware/ti_sci.c:1986: warning: Excess function parameter 'vint_irq' description in 'ti_sci_cmd_set_irq'
drivers/firmware/ti_sci.c:2034: warning: Excess function parameter 'vint_irq' description in 'ti_sci_cmd_free_irq'
drivers/firmware/ti_sci.c:2630: warning: Function parameter or member 'bootvector' not described in 'ti_sci_cmd_proc_set_config'
drivers/firmware/ti_sci.c:2746: warning: Function parameter or member 'bv' not described in 'ti_sci_cmd_proc_get_status'
drivers/firmware/ti_sci.c:2746: warning: Function parameter or member 'cfg_flags' not described in 'ti_sci_cmd_proc_get_status'
drivers/firmware/ti_sci.c:2746: warning: Function parameter or member 'ctrl_flags' not described in 'ti_sci_cmd_proc_get_status'
drivers/firmware/ti_sci.c:2746: warning: Function parameter or member 'sts_flags' not described in 'ti_sci_cmd_proc_get_status'
drivers/firmware/ti_sci.c:2746: warning: expecting prototype for ti_sci_cmd_get_boot_status(). Prototype was for ti_sci_cmd_proc_get_status() instead
drivers/firmware/ti_sci.c:3265: warning: Function parameter or member 'sub_type' not described in 'devm_ti_sci_get_resource'
drivers/firmware/ti_sci.c:3265: warning: Excess function parameter 'suub_type' description in 'devm_ti_sci_get_resource'
Link: https://lore.kernel.org/r/20230621021619.265162-1-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Commit b9e8a7d950 ("firmware: ti_sci: Switch transport to polled
mode during system suspend") aims to resolve issues with tisci
operations during system suspend operation. However, the system may
enter a no_irq stage in various other usage modes, including power-off
and restart. To determine if polling mode is appropriate, use the
system_state instead.
While at this, drop the unused is_suspending state variable and
related helpers.
Fixes: b9e8a7d950 ("firmware: ti_sci: Switch transport to polled mode during system suspend")
Reported-by: Francesco Dolcini <francesco@dolcini.it>
Reported-by: Wadim Egorov <w.egorov@phytec.de>
Tested-by: Francesco Dolcini <francesco.dolcini@toradex.com> # Toradex Verdin AM62
Link: https://lore.kernel.org/r/20230620130329.4120443-1-nm@ti.com
Closes: https://lore.kernel.org/all/ZGeHMjlnob2GFyHF@francesco-nb.int.toradex.com/
Signed-off-by: Nishanth Menon <nm@ti.com>
Commit b9e8a7d950 ("firmware: ti_sci: Switch transport to polled
mode during system suspend") uses read_poll_timeout_atomic() macro
in ti_sci_do_xfer() to wait for completion when the system is
suspending. The break condition of the macro is set to "true" which
will cause it break immediately when evaluated, likely before the
TISCI xfer is completed, and always return 0. We want to poll here
until "done_state == true".
1) Change the break condition of read_poll_timeout_atomic() to
the bool variable "done_state".
2) The read_poll_timeout_atomic() returns 0 if the break condition
is met or -ETIMEDOUT if not. Since our break condition has changed
to "done_state", we also don't have to check for "!done_state" when
evaluating the return value.
Fixes: b9e8a7d950 ("firmware: ti_sci: Switch transport to polled mode during system suspend")
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20221021185704.181316-1-g-vlaev@ti.com
During system suspend it is completely valid for devices to invoke TISCI
commands during the noirq phase of the suspend path. Specifically this
will always be seen for devices that define a power-domains DT property
and make use of the ti_sci_pm_domains genpd implementation.
The genpd_finish_suspend call will power off devices during the noirq
phase, which will invoke TISCI.
In order to support this, the ti_sci driver must switch to not use
wait_for_completion_timeout during suspend, but instead rely on a manual
check for if the completion is not yet done, and proceed only if this is
the case.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220412192138.31189-1-d-gerlach@ti.com
The ringacc driver has been converted to use the new set_cfg function to
configure the ring, the old config ops can be removed.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The sysfw ring configuration message has been extended to include virtid
and asel value for the ring.
Add the ASEL_VALID to TI_SCI_MSG_VALUE_RM_ALL_NO_ORDER as it is required
for DMA rings.
Instead of extending the current .config() ops - which would need same
patch change in the ringacc driver - add ti_sci_msg_rm_ring_cfg struct and
a new ops using it to configure the ring.
This will allow easy update path in case new members are added for the ring
configuration.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The ring_get_cfg (0x1111 message) is not used and it is not supported by
sysfw for a long time.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Sysfw added 'extended_ch_type' to the tx_ch_cfg_req message which should be
used when BCDMA block copy channels are configured:
extended_ch_type = 0 : the channel is split tx channel (tchan)
extended_ch_type = 1 : the channel is block copy channel (bchan)
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Sysfw added support for a second range in the resource range API to be able
to describe complex allocations mainly for DMA channels.
Update the ti_sci part to consider the second range as well.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Use the ti_sci_resource_desc directly and update it's start and num members
directly instead of requiring individual parameters for them.
This will allow easy extension of the RM parameters without changing API.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The system controller's resource manager have support for configuring the
TDTYPE of TCHAN_CFG register on j721e.
With this parameter the teardown completion can be controlled:
TDTYPE == 0: Return without waiting for peer to complete the teardown
TDTYPE == 1: Wait for peer to complete the teardown
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Various driver updates for platforms. A bulk of this is smaller fixes or
cleanups, but some of the new material this time around is:
- Support for Nvidia Tegra234 SoC
- Ring accelerator support for TI AM65x
- PRUSS driver for TI platforms
- Renesas support for R-Car V3U SoC
- Reset support for Cortex-M4 processor on i.MX8MQ
There are also new socinfo entries for a handful of different SoCs
and platforms.
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAl+TUboPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx3T4YP/R5pjF2C1gt8FrCaG4IfhIY1VHWelfPcB5qB
RC7Pn4MCRCEY+10YPXA70oS6KBaC+gtZ4bPeInzfLXh1ynFJJb+XtAIxoRhnkEw+
/R979wNcIls9JqkvnHWFx29Y008W2ZNcXVNKH7O2Gxy+eKzDcTMsoH/zj8xWrV5b
+eBllTzGU4RArYRJdcwOBQwMO6L2pzADHZ7hGMAY//8fo+qrxg8b9EINsH1UHCa8
gQdWdVlmv6GeLB6RYLRBCWxpW4jOLDqEAvyDV84QQmYHvzD9tqJExNR0hfGTs4TU
TZWK7LWSNqF0ujQUbFh9Ikcx6DypU1gvE7LKhCDrf4D7HLRX5v4BjGH+xtVtjsyD
xzh4WEoa3qCNu1mxQjKG8Y6U7bB9cRI2TPVxbbmI4ZuF0njvybecwwOZUBQl4aD4
5x+Df3pO/E5ECLOBeTnLgvw20fcjHv4HP8l63B6ADb31FUiZrJXItvayY5qXWe+P
HSgUykmVA4nd4PnLsSj9seyWqOTIqUZ3U3TsmfxIQh2Otie01okwuHb1J7ErO/u0
W148SgSwVbnkPxjbBHKGgC2r+Q/AjSDGRBYL0ThIVFUztxTBBwhj3FIvMnyyxTIj
yFBY14KQ8FcNUs8DrbPCaAx/RDCB02IHdvvIlyTmU3RBq7UhJVIglpLzzo2ed9F2
5u/aVH3y
=tfPb
-----END PGP SIGNATURE-----
Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC-related driver updates from Olof Johansson:
"Various driver updates for platforms. A bulk of this is smaller fixes
or cleanups, but some of the new material this time around is:
- Support for Nvidia Tegra234 SoC
- Ring accelerator support for TI AM65x
- PRUSS driver for TI platforms
- Renesas support for R-Car V3U SoC
- Reset support for Cortex-M4 processor on i.MX8MQ
There are also new socinfo entries for a handful of different SoCs and
platforms"
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (131 commits)
drm/mediatek: reduce clear event
soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
soc: mediatek: cmdq: add jump function
soc: mediatek: cmdq: add write_s_mask value function
soc: mediatek: cmdq: add write_s value function
soc: mediatek: cmdq: add read_s function
soc: mediatek: cmdq: add write_s_mask function
soc: mediatek: cmdq: add write_s function
soc: mediatek: cmdq: add address shift in jump
soc: mediatek: mtk-infracfg: Fix kerneldoc
soc: amlogic: pm-domains: use always-on flag
reset: sti: reset-syscfg: fix struct description warnings
reset: imx7: add the cm4 reset for i.MX8MQ
dt-bindings: reset: imx8mq: add m4 reset
reset: Fix and extend kerneldoc
reset: reset-zynqmp: Added support for Versal platform
dt-bindings: reset: Updated binding for Versal reset driver
reset: imx7: Support module build
soc: fsl: qe: Remove unnessesary check in ucc_set_tdm_rxtx_clk
soc: fsl: qman: convert to use be32_add_cpu()
...
If a clock is disabled, its frequency should be allowed to change as
it is no longer in use. Add a flag towards this to the firmware clock
API handler routines.
Acked-by: Nishanth Menon <nm@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
With SYSFW ABI 3.0 changes, interrupts coming out of an interrupt
controller is identified by a type and it is consistent across SoCs.
Similarly global events for Interrupt aggregator. So add an API to get
resource range using a resource type.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200806074826.24607-4-lokeshvutla@ti.com
struct ti_sci_rm_type_map is no longer used. Drop its definition and its
declarations.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200806074826.24607-3-lokeshvutla@ti.com
With ABI 3.0, sysfw deprecated special resource types used for AM65x
SoC. Instead started using device id as resource type similar to the
convention used in J721E SOC.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20200806074826.24607-2-lokeshvutla@ti.com
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Sysfw provides an option for requesting exclusive access for a
device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
not used, the device is meant to be shared across hosts. Once a device
is requested from a host with this flag set, any request to this
device from a different host will be nacked by sysfw. Current tisci
driver enables this flag for every device requests. But this may not
be true for all the devices. So provide a separate commands in driver
for exclusive and shared device requests.
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Various driver updates for platforms and a couple of the small driver
subsystems we merge through our tree:
- A driver for SCU (system control) on NXP i.MX8QXP
- Qualcomm Always-on Subsystem messaging driver (AOSS QMP)
- Qualcomm PM support for MSM8998
- Support for a newer version of DRAM PHY driver for Broadcom (DPFE)
- Reset controller support for Bitmain BM1880
- TI SCI (System Control Interface) support for CPU control on AM654
processors
- More TI sysc refactoring and rework
-----BEGIN PGP SIGNATURE-----
iQJDBAABCAAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAl0yK3YPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx3WdUQAJEFRzY4+8VfsUspKmGwzHsrk7t1038JUEDE
VL3yYlvSGeHg5a58AI5PCR5ZCsyPK7Yw9cAcYexd0frFR7BCwKWrjqem0Lb5ovdK
CYM517DRtYPSBMF08Xw4pbZlT0yg65F1e9cf6BlUpkUZ6lJn4gUy8Y4BE6Aw/zuF
QKtQNs6Q8BUZqS3uoOpJ/PY4JiUmLPQPO4Lry7Lud8Z7qgArCC326paC3wwqjLoC
TpoMqb6izt7Vzo4BtTo5TUCyiEFZDlb/thhDySVlYRE7DQJusHBvRO9qgjI2ahOo
1/935q1fJO7S6+Yvc8DIzrD/DrIUOvOshi31F/J6iWKkQkTUxtQwsVReZKaiOfSD
fYxNVCgTcMS6ailKQSMQ0SYgXDa2gWdV3tS9XU8qML3tnDthi1nDmZks0QAAnFPS
bXRcWGtgqeQJ+QJ7yyKrsD9POeaq3Hc5/f1DN34H//Cyn0ip/fD6fkLCMIfUDwmu
TmO2Mnj6/fG/iBK+ToF+DaJ0/u3RiV2MC2vCE+0m3cVI9jtq9iA1y3UlmoaKUhhC
t9znA+u8/Jc5S2zNQriI2Ja5q8nKfihL7Jf68ENvGzLc7YuAqP6yx1LMg1g6Wshc
nLT+kHOF6DCUC3W7a8VuNyaxCwVtTbNTti+nvQVOmV6eaGiD5vzpXkHBWMbOJ7Lh
YOBwGyb4
=ek+j
-----END PGP SIGNATURE-----
Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC-related driver updates from Olof Johansson:
"Various driver updates for platforms and a couple of the small driver
subsystems we merge through our tree:
- A driver for SCU (system control) on NXP i.MX8QXP
- Qualcomm Always-on Subsystem messaging driver (AOSS QMP)
- Qualcomm PM support for MSM8998
- Support for a newer version of DRAM PHY driver for Broadcom (DPFE)
- Reset controller support for Bitmain BM1880
- TI SCI (System Control Interface) support for CPU control on AM654
processors
- More TI sysc refactoring and rework"
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (84 commits)
reset: remove redundant null check on pointer dev
soc: rockchip: work around clang warning
dt-bindings: reset: imx7: Fix the spelling of 'indices'
soc: imx: Add i.MX8MN SoC driver support
soc: aspeed: lpc-ctrl: Fix probe error handling
soc: qcom: geni: Add support for ACPI
firmware: ti_sci: Fix gcc unused-but-set-variable warning
firmware: ti_sci: Use the correct style for SPDX License Identifier
soc: imx8: Use existing of_root directly
soc: imx8: Fix potential kernel dump in error path
firmware/psci: psci_checker: Park kthreads before stopping them
memory: move jedec_ddr.h from include/memory to drivers/memory/
memory: move jedec_ddr_data.c from lib/ to drivers/memory/
MAINTAINERS: Remove myself as qcom maintainer
soc: aspeed: lpc-ctrl: make parameter optional
soc: qcom: apr: Don't use reg for domain id
soc: qcom: fix QCOM_AOSS_QMP dependency and build errors
memory: tegra: Fix -Wunused-const-variable
firmware: tegra: Early resume BPMP
soc/tegra: Select pinctrl for Tegra194
...
This function can return a negative number when it fails, but res->sets
is at most a u16 which can't hold that negative number. Let's store the
result into an int, ret, and then assign that to res->sets when it works
to avoid this logical impossibility.
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/firmware/ti_sci.c: In function ti_sci_cmd_ring_config:
drivers/firmware/ti_sci.c:2035:17: warning: variable dev set but not used [-Wunused-but-set-variable]
drivers/firmware/ti_sci.c: In function ti_sci_cmd_ring_get_config:
drivers/firmware/ti_sci.c:2104:17: warning: variable dev set but not used [-Wunused-but-set-variable]
drivers/firmware/ti_sci.c: In function ti_sci_cmd_rm_udmap_tx_ch_cfg:
drivers/firmware/ti_sci.c:2287:17: warning: variable dev set but not used [-Wunused-but-set-variable]
drivers/firmware/ti_sci.c: In function ti_sci_cmd_rm_udmap_rx_ch_cfg:
drivers/firmware/ti_sci.c:2357:17: warning: variable dev set but not used [-Wunused-but-set-variable]
Use the 'dev' variable instead of info->dev to fix this.
Acked-by: Suman Anna <s-anna@ti.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Do not fail if any of the requested subtypes are not availabe, but set the
number of resources to 0 and continue parsing the resource ranges.
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used in Texas Instrument's System on Chip (SoC) such as those
in K3 family AM654 SoC to communicate between various compute
processors with a central system controller entity.
The system controller provides various services including the control
of other compute processors within the SoC. Extend the TI-SCI protocol
support to add various TI-SCI commands to invoke services associated
with power and reset control, and boot vector management of the
various compute processors from the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Configuration of NAVSS resource, like rings, UDMAP channels, flows
and PSI-L thread management need to be done via TISCI.
Add the needed structures and functions for NAVSS resource configuration of
the following:
Rings from Ring Accelerator
PSI-L thread management
UDMAP tchan, rchan and rflow configuration.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
TI-SCI firmware will only respond to messages when the
TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages already do
this, set this for the ones that do not.
This will be enforced in future firmware that better match the TI-SCI
specifications, this patch will not break users of existing firmware.
Fixes: aa276781a6 ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Tested-by: Alejandro Hernandez <ajhernandez@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Future SoCs are going to have more than 255 device clocks in certain cases,
and thus the API must be extended to support this. The support is done in
backwards compatible extension, in which the new u32 clock identifier
fields are only used if the existing u8 size clock identifier is set as
255. In all the other cases, the existing u8 clock identifier is used. As
the size of the messages sent / received is not verified for existing
devices / old firmware, increasing the size of the messages from the end
is also fine. Due to this reason, depending on ABI version isn't necessary
either.
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Each resource with in the device can be uniquely identified as defined
by TISCI. Since this is generic across the devices, resource allocation
also can be made generic instead of each client driver handling the
resource. So add helper apis to manage the resource.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Markus Schneider-Pargmann (TI.com)
Thomas Richard (TI.com)
Kendall Willis
Andrew Davis
Kevin Hilman
Dave Gerlach
Vibhore Vardhan
Georgi Vlaev
Christophe JAILLET
Rob Herring
Dhruva Gole
Justin Stitt
Jinjie Ruan
Nishanth Menon
Peiwei Hu
Jason Wang
Peter Ujfalusi
Linus Torvalds
Tero Kristo
Lokesh Vutla
Alexander A. Klimov
Stephen Boyd
YueHaibing
Suman Anna