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>
Antonio Nino Diaz
Andrew F. Davis