From: Jeremy Linton
Turns out its helpful to have a !PcdToken flag
that enables a DSDT/SSDT. That simplifies
both the emmc2 SSDT (it only installs when
!SdIsArasan) and later for the XHCI/PCIe switch
where we want to install one of two tables
depending on whether a single Pcd is set.
From: Jeremy Linton
The 3G limit, and the 2G IORT are intended to solve
the same linux problem. They limit PCI DMA operations
to the first 3G of RAM. Older linux kernels, as
used with RHEL/Centos, trigger an assertion*
when a DMA operation starts at a range that
doesn't fit within the 2G range
From: Jeremy Linton
DMA translation on the eMMC2 vary based on SoC, and
this is made worse by the poor _DMA support in Linux.
For now the "safe" option is to simply run the eMMC2
controller in PIO mode. More advanced users or !Linux
operating systems may choose to enable this to gain
a perf
From: Jeremy Linton
In order for the WiFi to work, and the SD to run at full
speed we need to bind the SD slot to the eMMC2 controller.
Since we now have a driver for the eMMC2 controller
there isn't any reason to leave the SD card bound
to the older Arasan controller.
Signed-off-by: Jeremy
From: Jeremy Linton
The existing RPi3 ACPI entries for the Arasan
and SDHCI controllers need updating to work
with the RPi4. This is done by adding a caps
override for the legacy Arasan controller and
then adding an entirely new entry for the newer
eMMC2 controller.
Then we flip the default
From: Jeremy Linton
The primary problem with the RPi's Arasan controller is
the lack of a meaningful capabilities register. With just
a sdhci-caps _DSD entry we can provide that information. It
can then be bound to the Linux sdhci_iproc driver which
already hardcodes the remaining controller
