For PMR, write a 0 to bit7 and see if it sticks. This is only possible from
NS EL1 if we have a non-secure view of ICC_PMR_EL1.
For int priorities (GICD/GICR interfaces and LPIs), assume that the
GICD_CTLR.DS bit is telling us the truth.
RK3399 is special here when using the vendor bootloader, so keep the
auto-detection from the previous commit but limit the scope to only run
on RK3399 SOCs.
framebuffer, instead allow MD code to register callbacks. If a resource is
changed, the driver can unmap the old resource and remap the new. Do this
with simplefb so the console doesn't explode when the VGA device is
(potentially) reconfigured at boot.
Most boards are configured to little-endian in initial, and switched
to big-endian after kernel is loaded. In this case, framebuffer seems
byte-swapped to CPU.
It is best to reconfigure framebuffer (as done recently for sunxi_mixer
by jmcneill), but in most cases, HW is incapable, or we just don't know
register bits to configure them.
Therefore, override "format" FDT property for "simple-framebuffer" to
let drivers know byte-order for 32-bpp framebuffer.
Then, make fdt/simplefb (genfb) and arm_simplefb (early console) detect
byte-swapped FB, and configure genfb(4) or rasops(4) layers accordingly.
Tested on Pine A64+ (arm_simplefb) and Cubietruck (both fdt/simplefb and
arm_simplefb).
Discussed with jmcneill. Thanks!!
(non-ACPI mode). Inform the pciconf code about the framebuffer to
prevent pciconf from changing resources out from under us when framebuffer
memory is in VRAM.
- Don't expose how PCI bus configuration resource management is implemented.
Provide a new resource provider API:
==> pciconf_resource_init() -- Initialize a PCI configuration resources
container.
==> pciconf_resource_add() -- Add a PCI configuration resource to the
container (I/O, MEM, or prefetchable MEM). Multiple resources of
each type may be added.
==> pciconf_resource_fini() -- Tear down the PCI configurtation resources
container once the bus has been configured.
This is much easier to use than the previous method of providing an
extent map for each kind of resource, and works better for e.g. ACPI
platforms that provide potentially multiple PCI resources in tables
provided by firmware.
- Re-implement PCI configuration resource management using vmem arenas,
rather than extent maps.
- start sharing more code around the AP startup messaging.
- call arm_cpu_topology_set early so that ci_core_id is available for
drivers, e.g. bcm2835_intr.c
- both arm and aarch64 now have
- a static cpu_info_store array
- the same arm_cpu_{hatched,mbox}
The N1 SDP has a few bugs that we need to work around:
- PCIe root port config space lives in a non-standard location.
- Access to PCIe config space of devices that do not exist results in
an sync SError. Firmware creates a "known devices" table at a fixed
physical address that we use to filter PCI conf access to only known
devices.
This change splits the Arm ACPI PCI quirks into separate files for each
host controller, and allows per-segment quirks to be applied.
These changes exposed some bugs in the MI ACPI layer related to
multi-segment support. The MI ACPI PCI code was using a shared PCI
chipset tag to access devices, and these accesses can happen before our
PCI host bridge drivers are attached! The global chipset tag is now gone,
and an MD callback can provide a custom tag on a per-segment basis.
while attaching cpus, if the FDT provides "capacity-dmips-mhz" track
the fastest set, and call cpu_topology_set() with slow=true for any
cpus that are not the fastest.
bug fix for cpu_topology_set(): actually set ci_is_slow for slow cpus.
with this change, and -current's recent scheduler changes, this means
that long running processes run on the faster cores. on RK3399 based
systems, i am seeing 20-50% speed ups for many tasks.
XXX: all this can be made common with armv7 big.little.
