Merge "fix(gicv3): avoid incrementing global gicr_frames pointer" into integration

fix(gicv3): avoid incrementing global gicr_frames pointer

commit 75170704c9119a4947 (refactor(gicv3): clarify redistributor base
address usage with USE_GIC_DRIVER=3) introduced changes to walk the
r

fix(gicv3): avoid incrementing global gicr_frames pointer

commit 75170704c9119a4947 (refactor(gicv3): clarify redistributor base
address usage with USE_GIC_DRIVER=3) introduced changes to walk the
redistributor frames by incrementing the global `gicr_frames` pointer.
This leaves the pointer advanced after the first miss, so subsequent
CPUs do not start from the beginning of the array. Such behaviour is
incorrect in the presence of CPU hotplug or out-of-order CPU_ON
operations, where each CPU must be able to probe the full set of
redistributor frames independently.

Fix this by using a local iterator instead of modifying the global
`gicr_frames` pointer, preserving the array state for all CPUs.

While here, fix a typo in a comment and replace the `do…while`
loop with a safer `while` loop to avoid probing the zero terminator in
case a platform erroneously passes an empty array.

Signed-off-by: Rohit Mathew <rohit.mathew@arm.com>
Change-Id: I6d6f73fb172c48f8e50b29ec2232648be3a6a6a0

show more ...

Merge changes from topic "Add-i.MX94/95-suport" into integration

* changes:
docs(maintainers): add i.MX9 to maintained paths
feat(imx94): add initial support for imx94
feat(imx95): add optee s

Merge changes from topic "Add-i.MX94/95-suport" into integration

* changes:
docs(maintainers): add i.MX9 to maintained paths
feat(imx94): add initial support for imx94
feat(imx95): add optee support
feat(imx95): support trusty os
feat(imx95): implement a semaphore for GIC quiescing
feat(imx95): add initial support for i.MX95
feat(imx9): add necessary ele api call support
feat(imx9): add imx9 common code base
refactor(imx): drop the __dead2 attribute
fix(imx): add static attribute for platform specific gic struct
feat(gic): change gic_cpuif_enable/disable to weak
feat(scmi): add i.MX9 SCMI vendor CPU protocol
feat(scmi): add base protocol agent API
feat(scmi): update version to 3.0
build(changelog): update for imx94/95 support

show more ...

feat(gic): change gic_cpuif_enable/disable to weak

For some platform like NXP i.MX94/95, the gic cpu interface
enable & disable need some special handling except the generic
gic_cpuif_enable/disable

feat(gic): change gic_cpuif_enable/disable to weak

For some platform like NXP i.MX94/95, the gic cpu interface
enable & disable need some special handling except the generic
gic_cpuif_enable/disable API. To allow these platform to reuse
the generic gic driver support, need to mark these two APIs as weak
to allow platforms to provide platform specific implementation.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: I742fcb60bef20b051363f1fa86c6254e2f463129

show more ...

Merge changes I61d77211,I9cb5c1fa,I8e8a92fd into integration

* changes:
refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3
fix(gicv3): remove plat_gicv3_base.c
ref

Merge changes I61d77211,I9cb5c1fa,I8e8a92fd into integration

* changes:
refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3
fix(gicv3): remove plat_gicv3_base.c
refactor(versal-net): use the generic GIC driver

show more ...

refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3

The GICv3 driver has 2 methods of discovering the redistributors:
a) via setting gicr_base - done at boot and assumes

refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3

The GICv3 driver has 2 methods of discovering the redistributors:
a) via setting gicr_base - done at boot and assumes all GICR frames are
contiguous. This is the original method.

b) via gicv3_rdistif_probe() - called from platform code and requires
gicr_base == 0. It relaxes the requirement for frames to be
contiguous, like in a multichip configuration, and defers the
discovery to core bringup. This was introduced later.

Configurations possible with option a) are also possible with option b)
with only slightly different behaviour. USE_GIC_DRIVER=3 inherited
option b) from plat_gicv3_base.c and as such option a) is unusable.
However, it is unclear from code how this should be used. Clarify this
by requiring platforms initialise with gic_set_gicr_frames() and
adding relevant comments.

Also rename plat_arm_override_gicr_frames() to gic_set_gicr_frames() as
this is not plat arm specific and a part of the generic GIC driver.

Change-Id: I61d77211f8e65dc54cf9904069b500d26a06b5a5
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge "feat(gic): make IRQ groups optional" into integration

feat(gic): make IRQ groups optional

There are systems which define no Group 0 interrupts, make both
G0 and G1S groups optional to make it possible for those systems
to use the generic driver.

Signe

feat(gic): make IRQ groups optional

There are systems which define no Group 0 interrupts, make both
G0 and G1S groups optional to make it possible for those systems
to use the generic driver.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Change-Id: I39e366ed1988847bfa288adc0732d9b864e58bbd

show more ...

Merge changes I0b0443d5,Ic454a87a into integration

* changes:
fix(gic): quote the correct flag on error
feat(lib): add a generic EXTRACT macro

fix(gic): quote the correct flag on error

Generic GIC driver files should use the USE_GIC_DRIVER flag. When that's
not the case, the correct flag should be quotes to avoid confusion.

Change-Id: I0b

fix(gic): quote the correct flag on error

Generic GIC driver files should use the USE_GIC_DRIVER flag. When that's
not the case, the correct flag should be quotes to avoid confusion.

Change-Id: I0b0443d52c0b0e81d7b380285a278ffdeae17ca3
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge changes I86959e67,I0b0d1d36,I5b5267f4,I056c8710,I3474aa97 into integration

* changes:
chore: fix preprocessor checks
refactor: convert arm platforms to use the generic GIC driver
refacto

Merge changes I86959e67,I0b0d1d36,I5b5267f4,I056c8710,I3474aa97 into integration

* changes:
chore: fix preprocessor checks
refactor: convert arm platforms to use the generic GIC driver
refactor(gic): promote most of the GIC driver to common code
refactor: make arm_gicv2.c and arm_gicv3.c common
refactor(fvp): use more arm generic code for gicv3

show more ...

chore: fix preprocessor checks

We can also drop the preprocessor check from plat_gic_init - it was
introduced because the tsp needed to call this function on gicv2 but not
gicv3 and this was the cle

chore: fix preprocessor checks

We can also drop the preprocessor check from plat_gic_init - it was
introduced because the tsp needed to call this function on gicv2 but not
gicv3 and this was the cleanest way to filter this out. Now that we have
the generic driver, the caller has all the tools to cater for this.
Callers have been converted so this is redundant.

Also, the FVP observes different behaviour on debug and release builds
in regards to the contents of plat_params_from_bl2. Make this explicit
so that release builds with ENABLE_ASSERTIONS=1 are possible.

Change-Id: I86959e67460d0c25c558f33c08e6233a8b6eeb7f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

refactor(gic): promote most of the GIC driver to common code

More often than not, Arm based systems include some revision of a GIC.
There are two ways of adding support for them in platform code - c

refactor(gic): promote most of the GIC driver to common code

More often than not, Arm based systems include some revision of a GIC.
There are two ways of adding support for them in platform code - calling
the top-level helpers from plat/arm/common/arm_gicvX.c or by using the
driver directly. Both of these methods allow for a high degree of
customisation - most functions are defined to be weak and there are no
calls to any of them in generic code.

As it turns out, requirements around those GICs are largely the same.
Platforms that use arm_gicvX.c use the helpers identically among each
other. Platforms that use the driver directly tend to end up with calls
that look a lot like the arm_gicvX.c helpers and the weakness of the
functions are never exercised.

All of this results in a lot of code duplication to do what is
essentially the same thing. Even though it's not a lot of code, when
multiplied among many platforms it becomes significant and makes
refactoring it quite difficult. It's also bug prone since the steps are
a little convoluted and things are likely to work even with subtle
errors (see 50009f61177421118f42d6a000611ba0e613d54b).

So promote as much of the GIC to be called from common code. Do the
setup in bl31_main() and have every PSCI method do the state management
directly instead of delegating it to the platform hooks. We can base
this implementation on arm_gicvX.c since they already offer logical
names and have worked quite well so far with minimal changes.

The main benefit of doing this is reduced code duplication. If we assume
that, outside of some platform setup, GIC management is identical, then
a platform can add support by telling the build system, regardless of
GIC revision. The other benefit is performance - BL31 and PSCI already
know the core_pos and they can pass it as an argument instead of having
to call plat_my_core_pos(). Now, the only platform specific GIC actions
necessary are the saving and restoring of context on entering and
exiting a power domain. The PSCI library does not keep track of this so
it is unable perform it itself. The routines themselves are also
provided.

For compatibility all of this is hidden behind a build flag. Platforms
are encouraged to adopt this driver, but it would not be practical to
convert and validate every GIC based platform.

This patch renames the functions in question to follow the
gic_<function>() convention. This allows the names to be version
agnostic.

Finally, drop the weak definitions - they are unused, likely to remain
so, and can be added back if the need arises.

Change-Id: I5b5267f4b72f633fb1096400ec8e4b208694135f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...