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? Btw the subject isn't complete. The patch is also related to the rpi3. Best regards Stefan