On Wed, 17 Feb 2021 at 08:30, Jeremy Linton <jeremy.linton@arm.com> wrote:
>
> Hi,
>
> On 2/17/21 12:56 AM, Ard Biesheuvel wrote:
> > On Wed, 17 Feb 2021 at 07:18, jlinton <lintonrjeremy@gmail.com> wrote:
> >>
> >> From: Jeremy Linton <jeremy.linton@arm.com>
> >>
> >> 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 routing to make the eMMC2
> >> the default for the SD card, so that the WiFi can
> >> start working on the Arasan.
> >>
> >> Additional we add a menu item to enable the SDMA/ADMA2
> >> modes on the controller.
> >>
> >> v2->v3: Various small review tweaks, whitespace, wording
> >>              spelling, etc.
> >>
> >
> > What happened to the IORT change? Don't we need that to ensure that
> > Linux sizes ZONE_DMA appropriately?
>
> Ha, I gave up! There are more important things to fix, especially when I
> found another case that couldn't just be fixed by the IORT tweaking
> without more kernel patches.
>

Which case is that?


> The default in this set is PIO mode, no DMA, same as the Arasan. If I
> get motivated (or someone else does) they can pick up the pieces to
> finish turning the DMA on in linux. It also simplifies that IORT disable
> patch I posted separately since I don't have to worry about enabling it
> for a limit <2G.
>

But having a 1 GB limit for only the eMMC2 in the IORT and a matching
_DMA method in its container should not trigger this error, I'd
assume.

> The sdhci_caps_mask choice is what flags the device as not supporting
> DMA modes unless the user enables it. Yes this hurts perf, but not
> nearly as badly as disabling UHS mode because we can't lower the card
> voltage with the standard sdhci registers (rather having to depend on a
> nonstandard rpi mailbox call which isn't available without a _DSM() or
> something equally undesirable).
>

Are you saying switching to the Arasan disabled UHS mode, and this is
why this is an improvement nonetheless?

> Presumably windows, *bsd, etc could make some use of the _DMA in the
> SSDT as well.
>

I don't think Windows uses _DMA, but I am mostly interested in Linux
in any case. Modulo the 'other case' above, I don't think this is the
approach I would prefer tbh.

Thanks,
Ard.


>
> >
> >
> >> v1->v2: Add option for user to enable/disable eMMC DMA
> >>          Only enable the emmc2 table on rpi4 &
> >>              !Arasan routing
> >>          Move emmc2 into its own SSDT and drop
> >>              second _DMA entry
> >>
> >> Jeremy Linton (4):
> >>    Platform/RaspberryPi: Add Negative table check
> >>    Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan
> >>    Platform/RaspberryPi: User control of eMMC2 DMA
> >>    Platform/RaspberryPi: Invert default Arasan, eMMC2 routing
> >>
> >>   Platform/RaspberryPi/AcpiTables/AcpiTables.inf     |   1 +
> >>   Platform/RaspberryPi/AcpiTables/Emmc.asl           | 129 +++++++++++++++++++++
> >>   Platform/RaspberryPi/AcpiTables/Sdhc.asl           |  18 ++-
> >>   Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  26 +++++
> >>   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf    |   1 +
> >>   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |   4 +
> >>   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr |  17 +++
> >>   Platform/RaspberryPi/Include/ConfigVars.h          |   8 ++
> >>   Platform/RaspberryPi/RPi3/RPi3.dsc                 |   1 +
> >>   Platform/RaspberryPi/RPi4/RPi4.dsc                 |   3 +-
> >>   Platform/RaspberryPi/RPi4/Readme.md                |   2 +-
> >>   Platform/RaspberryPi/RaspberryPi.dec               |   1 +
> >>   12 files changed, 206 insertions(+), 5 deletions(-)
> >>   create mode 100644 Platform/RaspberryPi/AcpiTables/Emmc.asl
> >>
> >> --
> >> 2.13.7
> >>
>