[PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[jlinton]

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.

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

[PATCH v3 1/4] Platform/RaspberryPi: Add Negative table check

[jlinton]

From: Jeremy Linton <jeremy.linton@arm.com>

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.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 578f5ead8f..fc1b5f3420 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -606,6 +606,7 @@ typedef struct {
 typedef struct {
   UINT64                      OemTableId;
   UINTN                       PcdToken;
+  UINTN                       PcdTokenNot;
   CONST AML_NAME_OP_REPLACE   *SdtNameOpReplace;
 } NAMESPACE_TABLES;
 
@@ -703,6 +704,9 @@ VerifyUpdateTable (
   if (SdtTable->PcdToken && !LibPcdGet32 (SdtTable->PcdToken)) {
     Result = FALSE;
   }
+  if (SdtTable->PcdTokenNot && LibPcdGet32 (SdtTable->PcdTokenNot)) {
+    Result = FALSE;
+  }
   if (Result && SdtTable->SdtNameOpReplace) {
     UpdateSdtNameOps (AcpiHeader, SdtTable->SdtNameOpReplace);
   }
@@ -720,11 +724,13 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
   {
     SIGNATURE_64 ('R', 'P', 'I', 'T', 'H', 'F', 'A', 'N'),
     PcdToken(PcdFanOnGpio),
+    0,
     SsdtNameOpReplace
   },
   {
     SIGNATURE_64 ('R', 'P', 'I', 0, 0, 0, 0, 0),
     0,
+    0,
     NULL
   },
   { }
-- 
2.13.7

[PATCH v3 2/4] Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan

[jlinton]

From: Jeremy Linton <jeremy.linton@arm.com>

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 bugs.

Further we have gotten BRCME88C approved as the HID
for the newer eMMC2 controller. So lets define an
ACPI object to describe it.

Of course both devices are sharing an interrupt so
we should also indicate that in the table as well.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
---
 Platform/RaspberryPi/AcpiTables/AcpiTables.inf     |   1 +
 Platform/RaspberryPi/AcpiTables/Emmc.asl           | 129 +++++++++++++++++++++
 Platform/RaspberryPi/AcpiTables/Sdhc.asl           |  18 ++-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |   6 +
 4 files changed, 151 insertions(+), 3 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/Emmc.asl

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
index d2cce074e5..743261afcf 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -35,6 +35,7 @@
   Spcr.aslc
   Pptt.aslc
   SsdtThermal.asl
+  Emmc.asl
 
 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl b/Platform/RaspberryPi/AcpiTables/Emmc.asl
new file mode 100644
index 0000000000..3cb5289d36
--- /dev/null
+++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
@@ -0,0 +1,129 @@
+/** @file
+ *
+ *  Copyright (c) 2021 Arm. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include <IndustryStandard/Bcm2836SdHost.h>
+#include <IndustryStandard/Bcm2836Sdio.h>
+
+#include "AcpiTables.h"
+
+DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4EMMC", 2)
+{
+  Scope (\_SB_)
+  {
+#if (RPI_MODEL == 4)
+    Device (GDV1) {
+      Name (_HID, "ACPI0004")
+      Name (_UID, 0x0)
+      Name (_CCA, 0x0)
+
+      Name (RBUF, ResourceTemplate ()
+      {
+        MEMORY32FIXED (ReadWrite, 0, MMCHS2_LENGTH, RMEM)
+      })
+      Method (_CRS, 0x0, Serialized)
+      {
+        MEMORY32SETBASE (RBUF, RMEM, RBAS, MMCHS2_OFFSET)
+        Return (^RBUF)
+      }
+
+      Name (_DMA, ResourceTemplate() {
+        QWordMemory (ResourceConsumer,
+          ,
+          MinFixed,
+          MaxFixed,
+          NonCacheable,
+          ReadWrite,
+          0x0,
+          0x00000000C0000000, // MIN
+          0x00000000FFFFFFFF, // MAX
+          0xFFFFFFFF40000000, // TRA
+          0x0000000040000000, // LEN
+          ,
+          ,
+        )
+      })
+      
+      // emmc2 Host Controller. (brcm,bcm2711-emmc2)
+      Device (SDC3)
+      {
+        Name (_HID, "BRCME88C")
+        Name (_UID, 0x1)
+        Name (_CCA, 0x0)
+        Name (_S1D, 0x1)
+        Name (_S2D, 0x1)
+        Name (_S3D, 0x1)
+        Name (_S4D, 0x1)
+        Name (SDMA, 0x2)
+        Method (_STA)
+        {
+          Return(0xf)
+        }
+        Name (RBUF, ResourceTemplate ()
+        {
+          MEMORY32FIXED (ReadWrite, 0, MMCHS2_LENGTH, RMEM)
+          Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { BCM2836_MMCHS1_INTERRUPT }
+        })
+        Method (_CRS, 0x0, Serialized)
+        {
+          MEMORY32SETBASE (RBUF, RMEM, RBAS, MMCHS2_OFFSET)
+          Return (^RBUF)
+        }
+
+        // Unfortunately this controller doesn't honor the
+        // standard SDHCI voltage control registers
+        // (or at least Linux's standard code can't 
+        // lower the voltage) So, UHS mode is disabled with caps
+        Name (DSD1, Package () {
+          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+            Package () {
+              Package () { "sdhci-caps-mask", 0x0000000500080000 },
+            }
+        })
+        // Along with disabling UHS, here both SDMA and ADMA2
+        // are also disabled until the linux _DMA() mask/translate
+        // works properly.
+        Name (DSD2, Package () {
+          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+            Package () {
+              Package () { "sdhci-caps-mask", 0x0000000504480000 },
+            }
+        })
+        Method (_DSD, 0x0, Serialized)
+        {
+          // Select one of the sdhci-caps-mask definitions
+          // depending on whether we also want to disable DMA
+          if (SDMA == 0) 
+          {
+            return (^DSD2)
+          } 
+          else 
+          {
+            return (^DSD1)
+          }
+        }
+
+        //
+        // A child device that represents the
+        // sd card, which is marked as non-removable.
+        //
+        Device (SDMM)
+        {
+          Method (_ADR)
+          {
+            Return (0)
+          }
+          Method (_RMV) // Is removable
+          {
+            Return (0) // 0 - fixed
+          }
+        }
+      } //SDC3
+    } //GDV1
+#endif
+  } //\SB
+}
diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
index 0ab1ba27f2..0430ab7d2d 100644
--- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
@@ -19,7 +19,7 @@
 // Note: UEFI can use either SDHost or Arasan. We expose both to the OS.
 //
 
-// ArasanSD 3.0 SD Host Controller.
+// ArasanSD 3.0 SD Host Controller. (brcm,bcm2835-sdhci)
 Device (SDC1)
 {
   Name (_HID, "BCM2847")
@@ -37,7 +37,7 @@ Device (SDC1)
   Name (RBUF, ResourceTemplate ()
   {
     MEMORY32FIXED (ReadWrite, 0, MMCHS1_LENGTH, RMEM)
-    Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { BCM2836_MMCHS1_INTERRUPT }
+    Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { BCM2836_MMCHS1_INTERRUPT }
   })
   Method (_CRS, 0x0, Serialized)
   {
@@ -45,6 +45,17 @@ Device (SDC1)
     Return (^RBUF)
   }
 
+  // The standard CAPs registers on this controller
+  // appear to be 0, lets set some minimal defaults
+  // Since this cap doesn't indicate DMA capability
+  // we don't need a _DMA()
+  Name (_DSD, Package () {
+    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+    Package () {
+      Package () { "sdhci-caps", 0x0100fa81 },
+    }
+  })
+
   //
   // A child device that represents the
   // sd card, which is marked as non-removable.
@@ -62,7 +73,7 @@ Device (SDC1)
   }
 }
 
-
+#if (RPI_MODEL < 4)
 // Broadcom SDHost 2.0 SD Host Controller
 Device (SDC2)
 {
@@ -105,3 +116,4 @@ Device (SDC2)
     }
   }
 }
+#endif // !RPI4
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index fc1b5f3420..402a2996b3 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -728,6 +728,12 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
     SsdtNameOpReplace
   },
   {
+    SIGNATURE_64 ('R', 'P', 'I', '4', 'E', 'M', 'M', 'C'),
+    0,
+    PcdToken(PcdSdIsArasan),
+    NULL
+  },
+  {
     SIGNATURE_64 ('R', 'P', 'I', 0, 0, 0, 0, 0),
     0,
     0,
-- 
2.13.7

[PATCH v3 3/4] Platform/RaspberryPi: User control of eMMC2 DMA

[jlinton]

From: Jeremy Linton <jeremy.linton@arm.com>

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 boost.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c      | 16 +++++++++++++++-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf    |  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  4 ++++
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 17 +++++++++++++++++
 Platform/RaspberryPi/Include/ConfigVars.h               |  8 ++++++++
 Platform/RaspberryPi/RPi3/RPi3.dsc                      |  1 +
 Platform/RaspberryPi/RPi4/RPi4.dsc                      |  1 +
 Platform/RaspberryPi/RaspberryPi.dec                    |  1 +
 8 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 402a2996b3..22f86d4d44 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -336,6 +336,15 @@ SetupVariables (
   }
 
   Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"MmcEnableDma",
+                  &gConfigDxeFormSetGuid,
+                  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+    Status = PcdSet32S (PcdMmcEnableDma, PcdGet32 (PcdMmcEnableDma));
+    ASSERT_EFI_ERROR (Status);
+  }
+
+  Size = sizeof (UINT32);
   Status = gRT->GetVariable (L"DebugEnableJTAG",
                   &gConfigDxeFormSetGuid,
                   NULL, &Size, &Var32);
@@ -720,6 +729,11 @@ STATIC CONST AML_NAME_OP_REPLACE SsdtNameOpReplace[] = {
   { }
 };
 
+STATIC CONST AML_NAME_OP_REPLACE SsdtEmmcNameOpReplace[] = {
+  { "SDMA", PcdToken (PcdMmcEnableDma) },
+  { }
+};
+
 STATIC CONST NAMESPACE_TABLES SdtTables[] = {
   {
     SIGNATURE_64 ('R', 'P', 'I', 'T', 'H', 'F', 'A', 'N'),
@@ -731,7 +745,7 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
     SIGNATURE_64 ('R', 'P', 'I', '4', 'E', 'M', 'M', 'C'),
     0,
     PcdToken(PcdSdIsArasan),
-    NULL
+    SsdtEmmcNameOpReplace
   },
   {
     SIGNATURE_64 ('R', 'P', 'I', 0, 0, 0, 0, 0),
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 544e3b3e10..d51e54e010 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -84,6 +84,7 @@
   gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz
   gRaspberryPiTokenSpaceGuid.PcdMmcSdHighSpeedMHz
   gRaspberryPiTokenSpaceGuid.PcdMmcDisableMulti
+  gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma
   gRaspberryPiTokenSpaceGuid.PcdDebugEnableJTAG
   gRaspberryPiTokenSpaceGuid.PcdDisplayEnableScaledVModes
   gRaspberryPiTokenSpaceGuid.PcdDisplayEnableSShot
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 2afe8f32ae..466fa852cb 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -94,6 +94,10 @@
 #string STR_MMC_SD_HS_PROMPT     #language en-US "SD High Speed (MHz)"
 #string STR_MMC_SD_HS_HELP       #language en-US "Override default 50Mhz"
 
+#string STR_MMC_EMMC_PROMPT      #language en-US "Enable eMMC DMA modes"
+#string STR_MMC_EMMC_PIO         #language en-US "PIO"
+#string STR_MMC_EMMC_DMA         #language en-US "SDMA/ADMA2"
+#string STR_MMC_EMMC_HELP        #language en-US "Enable eMMC DMA modes for OSes that support ACPI _DMA() translations"
 
 /*
  * Display settings.
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index de5e43471a..cc7a09cfb7 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -96,6 +96,11 @@ formset
       name  = MmcSdHighSpeedMHz,
       guid  = CONFIGDXE_FORM_SET_GUID;
 
+    efivarstore MMC_EMMC_DMA_VARSTORE_DATA,
+      attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+      name  = MmcEnableDma,
+      guid  = CONFIGDXE_FORM_SET_GUID;
+
     efivarstore DEBUG_ENABLE_JTAG_VARSTORE_DATA,
       attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
       name  = DebugEnableJTAG,
@@ -275,6 +280,18 @@ formset
              maximum = 100,
              default = 50,
         endnumeric;
+#if (RPI_MODEL == 4)
+        grayoutif ideqval SdIsArasan.Routing == 1;
+        oneof varid = MmcEnableDma.EnableDma,
+            prompt      = STRING_TOKEN(STR_MMC_EMMC_PROMPT),
+            help        = STRING_TOKEN(STR_MMC_EMMC_HELP),
+            flags       = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+            option text = STRING_TOKEN(STR_MMC_EMMC_PIO), value = 0, flags = DEFAULT;
+            option text = STRING_TOKEN(STR_MMC_EMMC_DMA), value = 1, flags = 0;
+        endoneof;
+        endif;
+#endif
+
     endform;
 
     form formid = 0x1004,
diff --git a/Platform/RaspberryPi/Include/ConfigVars.h b/Platform/RaspberryPi/Include/ConfigVars.h
index c185bfe28b..142317985a 100644
--- a/Platform/RaspberryPi/Include/ConfigVars.h
+++ b/Platform/RaspberryPi/Include/ConfigVars.h
@@ -135,4 +135,12 @@ typedef struct {
   UINT32 MHz;
 } MMC_SD_HS_MHZ_VARSTORE_DATA;
 
+typedef struct {
+  /*
+   * 0 - eMMC PIO mode
+   * 1 - eMMC DMA mode
+   */
+  UINT32 EnableDma;
+} MMC_EMMC_DMA_VARSTORE_DATA;
+
 #endif /* CONFIG_VARS_H */
diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 530b42796a..107cbda297 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -470,6 +470,7 @@
   gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz|L"MmcSdDefaultSpeedMHz"|gConfigDxeFormSetGuid|0x0|25
   gRaspberryPiTokenSpaceGuid.PcdMmcSdHighSpeedMHz|L"MmcSdHighSpeedMHz"|gConfigDxeFormSetGuid|0x0|50
   gRaspberryPiTokenSpaceGuid.PcdMmcDisableMulti|L"MmcDisableMulti"|gConfigDxeFormSetGuid|0x0|0
+  gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|L"MmcEnableDma"|gConfigDxeFormSetGuid|0x0|0
 
   #
   # Debug-related.
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 5f8452aa0b..9962df0076 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -481,6 +481,7 @@
   gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz|L"MmcSdDefaultSpeedMHz"|gConfigDxeFormSetGuid|0x0|25
   gRaspberryPiTokenSpaceGuid.PcdMmcSdHighSpeedMHz|L"MmcSdHighSpeedMHz"|gConfigDxeFormSetGuid|0x0|50
   gRaspberryPiTokenSpaceGuid.PcdMmcDisableMulti|L"MmcDisableMulti"|gConfigDxeFormSetGuid|0x0|0
+  gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|L"MmcEnableDma"|gConfigDxeFormSetGuid|0x0|0
 
   #
   # Debug-related.
diff --git a/Platform/RaspberryPi/RaspberryPi.dec b/Platform/RaspberryPi/RaspberryPi.dec
index 10723036aa..08135717ed 100644
--- a/Platform/RaspberryPi/RaspberryPi.dec
+++ b/Platform/RaspberryPi/RaspberryPi.dec
@@ -69,3 +69,4 @@
   gRaspberryPiTokenSpaceGuid.PcdFanOnGpio|0|UINT32|0x0000001C
   gRaspberryPiTokenSpaceGuid.PcdFanTemp|0|UINT32|0x0000001D
   gRaspberryPiTokenSpaceGuid.PcdPlatformResetDelay|0|UINT32|0x0000001E
+  gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|0|UINT32|0x0000001F
-- 
2.13.7

[PATCH v3 4/4] Platform/RaspberryPi: Invert default Arasan, eMMC2 routing

[jlinton]

From: Jeremy Linton <jeremy.linton@arm.com>

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 Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
---
 Platform/RaspberryPi/RPi4/RPi4.dsc  | 2 +-
 Platform/RaspberryPi/RPi4/Readme.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 9962df0076..e0fad6f744 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -475,7 +475,7 @@
   # SD-related.
   #
 
-  gRaspberryPiTokenSpaceGuid.PcdSdIsArasan|L"SdIsArasan"|gConfigDxeFormSetGuid|0x0|1
+  gRaspberryPiTokenSpaceGuid.PcdSdIsArasan|L"SdIsArasan"|gConfigDxeFormSetGuid|0x0|0
   gRaspberryPiTokenSpaceGuid.PcdMmcForce1Bit|L"MmcForce1Bit"|gConfigDxeFormSetGuid|0x0|0
   gRaspberryPiTokenSpaceGuid.PcdMmcForceDefaultSpeed|L"MmcForceDefaultSpeed"|gConfigDxeFormSetGuid|0x0|0
   gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz|L"MmcSdDefaultSpeedMHz"|gConfigDxeFormSetGuid|0x0|25
diff --git a/Platform/RaspberryPi/RPi4/Readme.md b/Platform/RaspberryPi/RPi4/Readme.md
index 3b2ed44e3c..80899f4ca4 100644
--- a/Platform/RaspberryPi/RPi4/Readme.md
+++ b/Platform/RaspberryPi/RPi4/Readme.md
@@ -181,7 +181,7 @@ Limit RAM to 3 GB            | `RamLimitTo3GB` | Disable = `0x00000000` <br> Ena
 System Table Selection       | `SystemTableMode`| ACPI = `0x00000000` (default)<br> ACPI + Devicetree = `0x00000001` <br> Devicetree = `0x00000002`
 Asset Tag                    | `AssetTag` | String, 32 characters or less (e.g. `L"ABCD123"`)<br> (default `L""`)
 **SD/MMC Configuration**     |
-uSD/eMMC Routing             | `SdIsArasan` | Arasan SDHC = `0x00000001` (default) <br> eMMC2 SDHCI = `0x00000000`
+uSD/eMMC Routing             | `SdIsArasan` | Arasan SDHC = `0x00000001` <br> eMMC2 SDHCI = `0x00000000` (default)
 Multi-Block Support          | `MmcDisableMulti` | Multi-block transfers = `0x00000000` (default)<br> Single block transfers = `0x00000001`
 uSD Max Bus Width            | `MmcForce1Bit` | 4-bit Mode = `0x00000000`  (default)<br> 1-bit Mode = `0x00000001`
 uSD Force Default Speed      | `MmcForceDefaultSpeed` | Allow High Speed = `0x00000000` (default)<br> Force Default Speed = `0x00000001`
-- 
2.13.7

Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Ard Biesheuvel]

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?


> 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
>

Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Jeremy Linton]

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.

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.

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).

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


> 
> 
>> 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
>>

Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Ard Biesheuvel]

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
> >>
>

Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Andrei Warkentin]

[-- Attachment #1: Type: text/plain, Size: 4905 bytes --]

I'm not sure I truly follow the conversation you're having (sorry), but I'll raise my hand as a _DMA user. I'm not that married to it, but I haven't added support for the alternate IORT-based DMA range clamping. If long term we want to bail on _DMA and adopt IORT exclusively, I'd love to know that so I can plan accordingly...

A
________________________________
From: Ard Biesheuvel <ardb@kernel.org>
Sent: Wednesday, February 17, 2021 1:55 AM
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: jlinton <lintonrjeremy@gmail.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Peter Batard <pete@akeo.ie>; Andrei Warkentin <awarkentin@vmware.com>; Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>; Leif Lindholm <leif@nuviainc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>
Subject: Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

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
> >>
>

[-- Attachment #2: Type: text/html, Size: 7956 bytes --]

Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Ard Biesheuvel]

On Wed, 17 Feb 2021 at 08:59, Andrei Warkentin <awarkentin@vmware.com> wrote:
>
> I'm not sure I truly follow the conversation you're having (sorry), but I'll raise my hand as a _DMA user. I'm not that married to it, but I haven't added support for the alternate IORT-based DMA range clamping. If long term we want to bail on _DMA and adopt IORT exclusively, I'd love to know that so I can plan accordingly...
>

SBSA requires that all memory is DMA addressable by all non-secure
masters, but Linux/arm64 can deal with systems that violate this
requirement, as long as the DMA limit is 4 GB or higher. The reason is
that the memory region from which bounce buffers are allocated is
created early during boot, and is allocated in the first 4 GB of
memory.

For devices such as RPi4, we have relaxed this requirement somewhat
when booting Linux/arm64 in ACPI mode, by adding an early IORT scan
that finds the smallest DMA limit, and using that limit for the bounce
buffer region if it is smaller than 4 GB. (At this point during the
boot, the AML interpreter is not up and running yet)

On Linux, the _DMA method supersedes the IORT limit, and so the IORT
limit is only used for sizing the bounce buffer region, and we get the
full 3GB range for XHCI.

In this particular case, I'd assume there is no ambiguity if the IORT
and the _DMA method both produce the same 1 GB DMA limit.

Re: [edk2-devel] [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Jeremy Linton]

Hi,

On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote:
> 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?

Some of these firmware/board revisions appear to need the 3G 
translation. The EMMC seems to be one of the devices who's DT 
descriptions are being modified by the lower level firmware (like the PCI).

> 
> 
>> 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.

Well with stock linux, the device will configure, startup and corrupt data.


> 
>> 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?

? I'm not sure I understand. Right now in linux we don't have SD or 
wifi. With just the caps _DSD entry the arasan will configure but it 
runs PIO mode all the time (including with DT). The cap is needed 
because the arasan returns 0 in the standard SDHCI caps registers.

The emmc2 supports faster modes, but we can't easily switch the voltage 
to support them because the standard voltage control registers aren't 
wired correctly (AFAIK). Given the change detection doesn't work right 
either (AFAIK), we could hack up the linux sdhci subsystem to not reset 
the card at startup and leave faster cards at 1.8V, but that is uglier 
than adding a _DSM() to forward the voltage change request to the rpi 
mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver.

IMHO, Given its just a perf thing, and this whole board is compromised 
in so many ways, it just isn't worth trying to support low voltage/UHS. 
Since the card is already running at the slower speeds, using PIO 
instead of DMA isn't a huge hit. So then we don't have to have a 1G 
IORT, or dynamic _DMA translation.

But this set is about enabling both the SD and WiFi. The latter requires 
the SD to be bound to the emmc2. At the moment there isn't much in the 
way of a perf advantage to switching the SD from the Arasan to the 
emmc2, the benefit comes from being able to use the wifi..


> 
>> 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
>>>>
>>
> 
> 
> 
> 
> 

Re: [edk2-devel] [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Ard Biesheuvel]

On Wed, 17 Feb 2021 at 18:16, Jeremy Linton <jeremy.linton@arm.com> wrote:
>
> Hi,
>
> On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote:
> > 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?
>
> Some of these firmware/board revisions appear to need the 3G
> translation. The EMMC seems to be one of the devices who's DT
> descriptions are being modified by the lower level firmware (like the PCI).
>

Considering that the reason for the 1 GB device limit is the -3 GB DMA
translation, I'd assume that the former and the latter apply to the
same set of peripherals.

But are you saying the dma-ranges properties are manipulated by the VC
firmware? Or other DT properties related to DMA translation?

> >
> >
> >> 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.
>
> Well with stock linux, the device will configure, startup and corrupt data.
>

By 'this error', I mean the splat resulting from mismatching DMA
limits for XHCI between IORT and _DMA.

Is the reason for the data corruption understood?

>
> >
> >> 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?
>
> ? I'm not sure I understand. Right now in linux we don't have SD or
> wifi. With just the caps _DSD entry the arasan will configure but it
> runs PIO mode all the time (including with DT). The cap is needed
> because the arasan returns 0 in the standard SDHCI caps registers.
>
> The emmc2 supports faster modes, but we can't easily switch the voltage
> to support them because the standard voltage control registers aren't
> wired correctly (AFAIK). Given the change detection doesn't work right
> either (AFAIK), we could hack up the linux sdhci subsystem to not reset
> the card at startup and leave faster cards at 1.8V, but that is uglier
> than adding a _DSM() to forward the voltage change request to the rpi
> mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver.
>
> IMHO, Given its just a perf thing, and this whole board is compromised
> in so many ways, it just isn't worth trying to support low voltage/UHS.
> Since the card is already running at the slower speeds, using PIO
> instead of DMA isn't a huge hit.

I could also argue that PIO at low speeds is worse then PIO at high
speeds, given that the CPU will be tied up for longer to transfer the
same amount of data.

> So then we don't have to have a 1G
> IORT, or dynamic _DMA translation.
>

Yes, that is obviously a win.

> But this set is about enabling both the SD and WiFi. The latter requires
> the SD to be bound to the emmc2. At the moment there isn't much in the
> way of a perf advantage to switching the SD from the Arasan to the
> emmc2, the benefit comes from being able to use the wifi..
>
>

Fair enough. I'm just slightly disappointed that we cannot use the
eMMC2 in DMA mode even for the lower speed, but I guess it is not the
end of the world.

If everyone else is on board with this approach, I'll pick these up tomorrow.

Thanks,
Ard.

Re: [edk2-devel] [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Jeremy Linton]

Hi,

On 2/17/21 11:57 AM, Ard Biesheuvel wrote:
> On Wed, 17 Feb 2021 at 18:16, Jeremy Linton <jeremy.linton@arm.com> wrote:
>>
>> Hi,
>>
>> On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote:
>>> 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?
>>
>> Some of these firmware/board revisions appear to need the 3G
>> translation. The EMMC seems to be one of the devices who's DT
>> descriptions are being modified by the lower level firmware (like the PCI).
>>
> 
> Considering that the reason for the 1 GB device limit is the -3 GB DMA
> translation, I'd assume that the former and the latter apply to the
> same set of peripherals.
> 
> But are you saying the dma-ranges properties are manipulated by the VC
> firmware? Or other DT properties related to DMA translation?

Yes, Its changing dma-range property associated with the emmc in the DT 
its being handed which is then shared with atf/etc.


> 
>>>
>>>
>>>> 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.
>>
>> Well with stock linux, the device will configure, startup and corrupt data.
>>
> 
> By 'this error', I mean the splat resulting from mismatching DMA
> limits for XHCI between IORT and _DMA.

No, I don't see that. The PCI/XHCI is fine with the IORT changes.

> 
> Is the reason for the data corruption understood?

It runs but appears to the address translation portion doesn't get 
applied (the command rings appear to be ok/etc) to FS buffers reliably 
so garbage gets written to the disk as the wrong bus locations get used. 
Its somewhat odd because at a first glance the directory structure/etc 
come back so if one just mounts the FS and ls's it, then unmounts it all 
appears to be ok. The first indications something is wrong are usually 
FS corruption messages. I have an instrumented sdhci/etc driver 
splatting on addrs > 1G so that all looks ok.

> 
>>
>>>
>>>> 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?
>>
>> ? I'm not sure I understand. Right now in linux we don't have SD or
>> wifi. With just the caps _DSD entry the arasan will configure but it
>> runs PIO mode all the time (including with DT). The cap is needed
>> because the arasan returns 0 in the standard SDHCI caps registers.
>>
>> The emmc2 supports faster modes, but we can't easily switch the voltage
>> to support them because the standard voltage control registers aren't
>> wired correctly (AFAIK). Given the change detection doesn't work right
>> either (AFAIK), we could hack up the linux sdhci subsystem to not reset
>> the card at startup and leave faster cards at 1.8V, but that is uglier
>> than adding a _DSM() to forward the voltage change request to the rpi
>> mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver.
>>
>> IMHO, Given its just a perf thing, and this whole board is compromised
>> in so many ways, it just isn't worth trying to support low voltage/UHS.
>> Since the card is already running at the slower speeds, using PIO
>> instead of DMA isn't a huge hit.
> 
> I could also argue that PIO at low speeds is worse then PIO at high
> speeds, given that the CPU will be tied up for longer to transfer the
> same amount of data. >
>> So then we don't have to have a 1G
>> IORT, or dynamic _DMA translation.
>>
> 
> Yes, that is obviously a win.
> 
>> But this set is about enabling both the SD and WiFi. The latter requires
>> the SD to be bound to the emmc2. At the moment there isn't much in the
>> way of a perf advantage to switching the SD from the Arasan to the
>> emmc2, the benefit comes from being able to use the wifi..
>>
>>
> 
> Fair enough. I'm just slightly disappointed that we cannot use the
> eMMC2 in DMA mode even for the lower speed, but I guess it is not the
> end of the world.

Well its never done, at some point it can be revisited to make it 
faster. Maybe someone will come up with a clever way to do the voltage 
switching too. The platform has an easy way to trap to el3, but I can't 
see how to utilize that without sdhci driver changes at the moment.

> 
> If everyone else is on board with this approach, I'll pick these up tomorrow.
> 
> Thanks,
> Ard.
> 

Re: [edk2-devel] [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Ard Biesheuvel]

On Thu, 18 Feb 2021 at 17:47, Jeremy Linton <jeremy.linton@arm.com> wrote:
>
> Hi,
>
> On 2/17/21 11:57 AM, Ard Biesheuvel wrote:
> > On Wed, 17 Feb 2021 at 18:16, Jeremy Linton <jeremy.linton@arm.com> wrote:
> >>
> >> Hi,
> >>
> >> On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote:
> >>> 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?
> >>
> >> Some of these firmware/board revisions appear to need the 3G
> >> translation. The EMMC seems to be one of the devices who's DT
> >> descriptions are being modified by the lower level firmware (like the PCI).
> >>
> >
> > Considering that the reason for the 1 GB device limit is the -3 GB DMA
> > translation, I'd assume that the former and the latter apply to the
> > same set of peripherals.
> >
> > But are you saying the dma-ranges properties are manipulated by the VC
> > firmware? Or other DT properties related to DMA translation?
>
> Yes, Its changing dma-range property associated with the emmc in the DT
> its being handed which is then shared with atf/etc.
>

But the translation is always the same, no?

>
> >
> >>>
> >>>
> >>>> 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.
> >>
> >> Well with stock linux, the device will configure, startup and corrupt data.
> >>
> >
> > By 'this error', I mean the splat resulting from mismatching DMA
> > limits for XHCI between IORT and _DMA.
>
> No, I don't see that. The PCI/XHCI is fine with the IORT changes.
>

Then why do you need

[PATCH v2] Platform/RaspberryPi: Only enable IORT when 3G limit is disabled

?

> >
> > Is the reason for the data corruption understood?
>
> It runs but appears to the address translation portion doesn't get
> applied (the command rings appear to be ok/etc) to FS buffers reliably
> so garbage gets written to the disk as the wrong bus locations get used.
> Its somewhat odd because at a first glance the directory structure/etc
> come back so if one just mounts the FS and ls's it, then unmounts it all
> appears to be ok. The first indications something is wrong are usually
> FS corruption messages. I have an instrumented sdhci/etc driver
> splatting on addrs > 1G so that all looks ok.
>
> >
> >>
> >>>
> >>>> 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?
> >>
> >> ? I'm not sure I understand. Right now in linux we don't have SD or
> >> wifi. With just the caps _DSD entry the arasan will configure but it
> >> runs PIO mode all the time (including with DT). The cap is needed
> >> because the arasan returns 0 in the standard SDHCI caps registers.
> >>
> >> The emmc2 supports faster modes, but we can't easily switch the voltage
> >> to support them because the standard voltage control registers aren't
> >> wired correctly (AFAIK). Given the change detection doesn't work right
> >> either (AFAIK), we could hack up the linux sdhci subsystem to not reset
> >> the card at startup and leave faster cards at 1.8V, but that is uglier
> >> than adding a _DSM() to forward the voltage change request to the rpi
> >> mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver.
> >>
> >> IMHO, Given its just a perf thing, and this whole board is compromised
> >> in so many ways, it just isn't worth trying to support low voltage/UHS.
> >> Since the card is already running at the slower speeds, using PIO
> >> instead of DMA isn't a huge hit.
> >
> > I could also argue that PIO at low speeds is worse then PIO at high
> > speeds, given that the CPU will be tied up for longer to transfer the
> > same amount of data. >
> >> So then we don't have to have a 1G
> >> IORT, or dynamic _DMA translation.
> >>
> >
> > Yes, that is obviously a win.
> >
> >> But this set is about enabling both the SD and WiFi. The latter requires
> >> the SD to be bound to the emmc2. At the moment there isn't much in the
> >> way of a perf advantage to switching the SD from the Arasan to the
> >> emmc2, the benefit comes from being able to use the wifi..
> >>
> >>
> >
> > Fair enough. I'm just slightly disappointed that we cannot use the
> > eMMC2 in DMA mode even for the lower speed, but I guess it is not the
> > end of the world.
>
> Well its never done, at some point it can be revisited to make it
> faster. Maybe someone will come up with a clever way to do the voltage
> switching too. The platform has an easy way to trap to el3, but I can't
> see how to utilize that without sdhci driver changes at the moment.
>
> >
> > If everyone else is on board with this approach, I'll pick these up tomorrow.
> >
> > Thanks,
> > Ard.
> >
>

Re: [edk2-devel] [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Jeremy Linton]

Hi,

On 2/18/21 10:52 AM, Ard Biesheuvel wrote:
> On Thu, 18 Feb 2021 at 17:47, Jeremy Linton <jeremy.linton@arm.com> wrote:
>>
>> Hi,
>>
>> On 2/17/21 11:57 AM, Ard Biesheuvel wrote:
>>> On Wed, 17 Feb 2021 at 18:16, Jeremy Linton <jeremy.linton@arm.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote:
>>>>> 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?
>>>>
>>>> Some of these firmware/board revisions appear to need the 3G
>>>> translation. The EMMC seems to be one of the devices who's DT
>>>> descriptions are being modified by the lower level firmware (like the PCI).
>>>>
>>>
>>> Considering that the reason for the 1 GB device limit is the -3 GB DMA
>>> translation, I'd assume that the former and the latter apply to the
>>> same set of peripherals.
>>>
>>> But are you saying the dma-ranges properties are manipulated by the VC
>>> firmware? Or other DT properties related to DMA translation?
>>
>> Yes, Its changing dma-range property associated with the emmc in the DT
>> its being handed which is then shared with atf/etc.
>>
> 
> But the translation is always the same, no?

No, the newer SOC with the newer (broken xhci) firmware does away with 
it, and widens the window. I haven't tried the newer SOC with the 
experimental firmware that now boots uefi except to validate that the 
emmc works in PIO mode. It might "just work" with DMA enabled, but in 
that case we should probably do a SOC detection and flip the PIO/DMA 
default, but that needs to be done with the pi400 or an actual released 
product rather than this "special" one off device I have.


> 
>>
>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>
>>>> Well with stock linux, the device will configure, startup and corrupt data.
>>>>
>>>
>>> By 'this error', I mean the splat resulting from mismatching DMA
>>> limits for XHCI between IORT and _DMA.
>>
>> No, I don't see that. The PCI/XHCI is fine with the IORT changes.
>>
> 
> Then why do you need
> 
> [PATCH v2] Platform/RaspberryPi: Only enable IORT when 3G limit is disabled
> 
> ?

Oh, I guess I misunderstood what you were asking since this set is no 
longer dependent on the IORT change. I thought you were asking if the 
XHCI was having issues with the IORT when it had a 1G limit?

So the answer should have been depends on the kernel.

The older kernels don't work with SD/Wifi since we aren't using the 
standard pnp ID, but they have problems with the IORT regardless of of 
what its limits are when a device tries to use a buffer that exists 
between the 1G/2G IORT and the 3G mem limit.

The newer kernel's WRT the IORT don't care what the limit is, but we 
would have needed to have the IORT in place even with the 3G limit 
applied to assure the SD/Wifi work. Its this latter case that influenced 
the original version of that patch which tied the IORT directly to the 
mem limit, and would have required the user to lift the 3G limit on a 2G 
device to enable the IORT.

All these flags and options are failing KISS and part of the reason I 
think the PIO is a reasonable choice. Lets start with the lowest common 
denominator, and then worry about getting fancy.







> 
>>>
>>> Is the reason for the data corruption understood?
>>
>> It runs but appears to the address translation portion doesn't get
>> applied (the command rings appear to be ok/etc) to FS buffers reliably
>> so garbage gets written to the disk as the wrong bus locations get used.
>> Its somewhat odd because at a first glance the directory structure/etc
>> come back so if one just mounts the FS and ls's it, then unmounts it all
>> appears to be ok. The first indications something is wrong are usually
>> FS corruption messages. I have an instrumented sdhci/etc driver
>> splatting on addrs > 1G so that all looks ok.
>>
>>>
>>>>
>>>>>
>>>>>> 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?
>>>>
>>>> ? I'm not sure I understand. Right now in linux we don't have SD or
>>>> wifi. With just the caps _DSD entry the arasan will configure but it
>>>> runs PIO mode all the time (including with DT). The cap is needed
>>>> because the arasan returns 0 in the standard SDHCI caps registers.
>>>>
>>>> The emmc2 supports faster modes, but we can't easily switch the voltage
>>>> to support them because the standard voltage control registers aren't
>>>> wired correctly (AFAIK). Given the change detection doesn't work right
>>>> either (AFAIK), we could hack up the linux sdhci subsystem to not reset
>>>> the card at startup and leave faster cards at 1.8V, but that is uglier
>>>> than adding a _DSM() to forward the voltage change request to the rpi
>>>> mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver.
>>>>
>>>> IMHO, Given its just a perf thing, and this whole board is compromised
>>>> in so many ways, it just isn't worth trying to support low voltage/UHS.
>>>> Since the card is already running at the slower speeds, using PIO
>>>> instead of DMA isn't a huge hit.
>>>
>>> I could also argue that PIO at low speeds is worse then PIO at high
>>> speeds, given that the CPU will be tied up for longer to transfer the
>>> same amount of data. >
>>>> So then we don't have to have a 1G
>>>> IORT, or dynamic _DMA translation.
>>>>
>>>
>>> Yes, that is obviously a win.
>>>
>>>> But this set is about enabling both the SD and WiFi. The latter requires
>>>> the SD to be bound to the emmc2. At the moment there isn't much in the
>>>> way of a perf advantage to switching the SD from the Arasan to the
>>>> emmc2, the benefit comes from being able to use the wifi..
>>>>
>>>>
>>>
>>> Fair enough. I'm just slightly disappointed that we cannot use the
>>> eMMC2 in DMA mode even for the lower speed, but I guess it is not the
>>> end of the world.
>>
>> Well its never done, at some point it can be revisited to make it
>> faster. Maybe someone will come up with a clever way to do the voltage
>> switching too. The platform has an easy way to trap to el3, but I can't
>> see how to utilize that without sdhci driver changes at the moment.
>>
>>>
>>> If everyone else is on board with this approach, I'll pick these up tomorrow.
>>>
>>> Thanks,
>>> Ard.
>>>
>>

Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Ard Biesheuvel]

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.
>
> 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
>

Could you please resend these in a way that I can apply them? They
seem to have gone through some QP mangling filter, with long lines
broken and newlines doubled in some cases (depending on the line
ending mode of the file, it seems)

https://pastebin.com/yG74aygV


>  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
>

Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Jeremy Linton]

Hi,

On 2/18/21 12:49 PM, 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.
>>
>> 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
>>
> 
> Could you please resend these in a way that I can apply them? They
> seem to have gone through some QP mangling filter, with long lines
> broken and newlines doubled in some cases (depending on the line
> ending mode of the file, it seems)

Sorry about that, I did change my email path slightly due to the weather 
events here, but I don't see what in the path below could be causing the 
problem. Its still using the same mail server on my side.

I have pushed this set, and the IORT fix, to github as well:

https://github.com/jlinton/edk2-platforms.git
Branch rpi_iortFix_acpiMmc

Thanks,


> 
> https://pastebin.com/yG74aygV
> 
> 
>>   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
>>

Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

[Ard Biesheuvel]

On Fri, 19 Feb 2021 at 17:51, Jeremy Linton <jeremy.linton@arm.com> wrote:
>
> Hi,
>
> On 2/18/21 12:49 PM, 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.
> >>
> >> 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
> >>
> >
> > Could you please resend these in a way that I can apply them? They
> > seem to have gone through some QP mangling filter, with long lines
> > broken and newlines doubled in some cases (depending on the line
> > ending mode of the file, it seems)
>
> Sorry about that, I did change my email path slightly due to the weather
> events here, but I don't see what in the path below could be causing the
> problem. Its still using the same mail server on my side.
>
> I have pushed this set, and the IORT fix, to github as well:
>
> https://github.com/jlinton/edk2-platforms.git
> Branch rpi_iortFix_acpiMmc
>

Thanks Jeremy.

Now pushed as f8926df263ad..2cad1bd782b5