The GIC driver itself has intimate knowledge of the hardware, and so it
is the best suited to create the mappings of the MMIO control regions,
in case they have not been mapped yet by the platform code.
So call in the the CPU arch protocol to map the CPU interface,
distributor and redistributor regions as they are discovered by the GIC
driver startup code.
Note that creating these mappings has no effect if the regions in
question have already been mapped with the correct attributes.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The GIC distributor and redistributor addresses that are passed into the
interrupt enable and disable routines are always the same, so just use
the global variables directly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The GIC DXE driver only runs on the boot CPU, and so there is really no
point in iterating over all the redistributor frames every time an
interrupt is enabled, disabled or its state tested. Instead, do this
only at load time.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Instead of relying on a protocol notification event to register the core IRQ
interrupt handler with CPU arch protocol once it becomes available, use
a DEPEX to ensure that the GIC driver is not dispatched at all until the
CPU arch protocol has turned up.
This will allow the GIC driver to use other CPU arch protocol methods,
such as the ones needed to map the GIC MMIO regions at driver startup.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
When re-entering EDK2 from a high level OS such as Linux, the GICv3 may
be configured to use split priority drop and deactivate (EOImode == 1),
whereas EDK2's GICv3 driver assumes the default setting of EOImode == 0.
So clear the EOImode bit explicitly when taking control of the GIC.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Now that ArmPkg/Drivers/ArmGic no longer carries a combination of
libraries and DXE drivers, rename the directory to the more idiomatic
ArmPkg/Drivers/ArmGicDxe
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Ard Biesheuvel