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/11/21 6:23 AM, Stefan Wahren wrote:
Hi,

Am 11.01.21 um 04:39 schrieb Jeremy Linton:
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.

okay, thanks for the explanation. I was also confused by bcm_arasan,
because there is already an Arasan specific sdhci driver. But now it's
clear to me.

Could you please add a short comment (above sdhci_bcm_arasan_data) why
we cannot use bcm2835_data?

Sure.


Btw the subject isn't complete. The patch is also related to the rpi3.

Only via the historical ACPI tables. There isn't any attempt to get ACPI+Linux working on the rpi3. Its to far away from BSA. For starters it doesn't have a GIC. So while one could bind this driver on the rpi3, that would require being able to boot Linux on the rpi3 in ACPI mode.

Thanks again!




Best regards
Stefan






[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