Re: [PATCH] mmc: sdhci-iproc: Add ACPI bindings for the rpi4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 1/9/21 5:07 AM, Stefan Wahren wrote:
Hi Jeremy,

+add Nicolas

Am 08.01.21 um 22:13 schrieb Jeremy Linton:
The rpi4 has a Arasan controller it carries over
from the rpi3, and a newer eMMC2 controller.
Because of a couple "quirks" it seems wiser to bind
these controllers to the same driver that DT is using
on this platform rather than the generic sdhci_acpi
driver with PNP0D40.

So, we use BCM2847 for the older Arasan and BRCME88C
for the newer eMMC2.

With this change linux is capable of utilizing the
SD card slot, and the wifi on this platform
with linux.

Signed-off-by: Jeremy Linton <jeremy.linton@xxxxxxx>
---
  drivers/mmc/host/sdhci-iproc.c | 14 ++++++++++++++
  1 file changed, 14 insertions(+)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index c9434b461aab..f79d97b41805 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -250,6 +250,14 @@ static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
  	.ops = &sdhci_iproc_32only_ops,
  };
+static const struct sdhci_pltfm_data sdhci_bcm_arasan_data = {
+	.quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
+		  SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
+		  SDHCI_QUIRK_NO_HISPD_BIT,
+	.quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+	.ops = &sdhci_iproc_32only_ops,
+};

First, thanks for taking a look at this!


Why do we need an almost exact copy of bcm2835_data which works fine for
all Raspberry Pi boards?

The short answer to the remainder of this email is that i'm trying to continue supporting existing OSs (windows) using the ACPI tables on the rpi3/rpi4 while adding rpi4+Linux support.

An even shorter answer is they don't work because ACPI doesn't provide the same clock/attributes/etc controls that exist with DT.

So, what happened here is that I got this controller "working" with the generic PNP0D40 sdhci_acpi driver. I managed this only by controlling the sdhci_caps/masks in the firmware. In theory this minimizes the amount of work needed on the other OS which are booting on the same ACPI tables (*bsds). They should only need to quirk the bcm/arasan specific functionality, rather than some of the quirking which change the caps behavior. But because we don't know which if any of the older rpi/arasan quirks are still needed the safest solution is to use the _iproc driver and just drop the quirk flags known to be worked around by the firmware caps override.


+
  static const struct sdhci_iproc_data bcm2835_data = {
  	.pdata = &sdhci_bcm2835_pltfm_data,
  	.caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
@@ -261,6 +269,10 @@ static const struct sdhci_iproc_data bcm2835_data = {
  	.mmc_caps = 0x00000000,
  };
+static const struct sdhci_iproc_data bcm_arasan_data = {
+	.pdata = &sdhci_bcm_arasan_data,
+};
+
  static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
  	.read_l = sdhci_iproc_readl,
  	.read_w = sdhci_iproc_readw,
@@ -299,6 +311,8 @@ MODULE_DEVICE_TABLE(of, sdhci_iproc_of_match);
  static const struct acpi_device_id sdhci_iproc_acpi_ids[] = {
  	{ .id = "BRCM5871", .driver_data = (kernel_ulong_t)&iproc_cygnus_data },
  	{ .id = "BRCM5872", .driver_data = (kernel_ulong_t)&iproc_data },
+	{ .id = "BCM2847",  .driver_data = (kernel_ulong_t)&bcm_arasan_data },

Sorry, i don't have deeper knowledge about ACPI, but BCM2837 is the
official naming of the SoC on the RPi 3.

Is this a typo in the id?

Not really.

Some background: The PFTF is basically the custodian of the combined rpi3 port done by Microsoft and a few other peoples/organizations ports. That merged code base was upstreamed a couple years ago to edk2 for the rpi3 and is the official port. On the rpi3+uefi platform, linux is just using DT, but windows and possibly other OSs are using the ACPI tables. For the Rpi4, the intentions is to be an ACPI first platform, but we are inheriting the rpi3 legacy peripheral descriptions. So, for the past year+ everyone has been basing their rpi4 ACPI OS ports on those tables and only adjusting them in backwards compatible ways.

Meaning, that a few years back someone put that ID in the rpi3 ACPI tables, and now we are stuck with it unless we are willing to break other OSs.



+	{ .id = "BRCME88C", .driver_data = (kernel_ulong_t)&bcm2711_data },
  	{ /* sentinel */ }
  };
  MODULE_DEVICE_TABLE(acpi, sdhci_iproc_acpi_ids);





[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux