When we get a sequence ID that does not match what we expect then the we
are looking at is not the one we are expecting and so we error out. We
can also assume this message is a stale message left in the queue, in
this case we can read in the next message and check again for our
message. Switch to doing that here. We only retry a set number of times
so we don't lock the system if our message is actually lost and will
never show up.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: I6c8186ccc45e646d3ba9d431f7d4c451dcd70c5c
The sequence ID can be set with a message to identify it when it is
responded to in the response queue. We assign each message a number and
check for this same number to detect response mismatches.
Start this at 0 and increase it by one for each message sent, even ones
that do not request or wait for a response as one may still be delivered
in some cases and we want to detect this.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: I72b4d1ef98bf1c1409d9db9db074af8dfbcd83ea
The direction of a thread should be explicitly compared to avoid
confusion. Also fixup message wording based on this direction.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: Ia3cf9413cd23af476bb5d2e6d70bee15234cbd11
The ID of a thread is not used outside for printing it out when
something goes wrong. The specifier used is also not consistent.
Instead of storing the thread ID, store its name and print that.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: Id137c2f8dfdd5c599e220193344ece903f80af7b
Now that we have non-blocking TI-SCI functions we can initiate the shutdown
sequence from the PSCI handler without needing the ti_sci_proc_shutdown
helper function, which is removed. This gives us the greater control and
flexibility that will be needed when cluster power down sequences are added.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Most TI-SCI functions request an ACK and wait until it is received. For
some power sequence tasks we cannot wait but instead queue messages
asynchronously. Three messages have been identified that will need to
be used in this way. Add non-waiting versions of these functions.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Currently almost all TI-SCI messages request and check for an ACK from
the system firmware. Move this into a common place to remove the same
from each function.
Signed-off-by: Andrew F. Davis <afd@ti.com>
When a device is requested with TI-SCI its control can be made exclusive
to the requesting host. This was currently the default but is not what
is needed most of the time. Add _exclusive versions of the request
functions and remove the exclusive flag from the default version.
Signed-off-by: Andrew F. Davis <afd@ti.com>
The raw get and set state functions for both devices and clocks
are only meant for use internal to the TI-SCI driver, the same
functionality is available from the other API that call into
these. Remove them from the external interface and make them
static scope to the driver.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Send and receive currently must be be serialized, any message already in
the receive queue when a new message is to be sent will cause a mismatch
with the expected response from this new message. Clear out all messages
from the response queue before sending a new request.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
It can be needed to discard all messages in a receive queue. This
can be used during some error recovery situations.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
This is a pseudo-API command consisting of a wait processor status
command and a set device state command queued back-to-back without
waiting for the System Firmware to ACK either message.
This is needed as the K3 power down specification states the System
Firmware must wait for a processor to be in WFI/WFE before powering
it down. The current implementation of System Firmware does not provide
such a command. Also given that with PSCI the core to be shutdown is the
core that is processing the shutdown request, the core cannot itself wait
for its own WFI/WFE status. To workaround this limitation, we submit
a wait processor status command followed by the actual shutdown command.
The shutdown command will not be processed until the wait command has
finished. In this way we can continue to WFI before the wait command
status has been met or timed-out and the shutdown command is processed.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
This TI-SCI API can be used wait for a set of processor status flags to
be set or cleared. The flags are processor type specific. This command
will not return ACK until the specified status is met. NACK will be
returned after the timeout elapses or on error.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
The logic is correct here, but the error messages are
reversed, switch them.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}
The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).
For example, this patch had to be created because two headers were
called the same way: e0ea0928d5 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a2 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.
Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.
Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
All identifiers, regardless of use, that start with two underscores are
reserved. This means they can't be used in header guards.
The style that this project is now to use the full name of the file in
capital letters followed by 'H'. For example, for a file called
"uart_example.h", the header guard is UART_EXAMPLE_H.
The exceptions are files that are imported from other projects:
- CryptoCell driver
- dt-bindings folders
- zlib headers
Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
TI-SCI message protocol provides support for controlling of various
physical cores available in the SoC. In order to control which host is
capable of controlling a physical processor core, there is a processor
access control list that needs to be populated as part of the board
configuration data.
Introduce support for the set of TI-SCI message protocol APIs that
provide us with this capability of controlling physical cores.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
Since system controller now has control over SoC power management, core
operation such as reset need to be explicitly requested to reboot the SoC.
Add support for this here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
TI-SCI message protocol provides support for management of various
hardware entities within the SoC.
In general, we expect to function at a device level of abstraction,
however, for proper operation of hardware blocks, many clocks directly
supplying the hardware block needs to be queried or configured.
Introduce support for the set of TI-SCI message protocol support that
provide us with this capability.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
TI-SCI message protocol provides support for management of various
hardware entitites within the SoC.
We introduce the fundamental device management capability support to
the driver protocol as part of this change.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.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 AM654x SoCs to communicate between various compute
processors with a central system controller entity.
TI-SCI message protocol provides support for management of various
hardware entities within the SoC. Add support driver to allow
communication with system controller entity within the SoC.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
Secure Proxy module manages hardware threads that are meant
for communication between the processor entities. Add support
for this here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Andrew F. Davis
Antonio Nino Diaz