From: Jeremy Linton <jeremy.linton@arm.com>
To: Stefan Wahren <stefan.wahren@i2se.com>,
linux-mmc@vger.kernel.org,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: ulf.hansson@linaro.org, f.fainelli@gmail.com,
sbranden@broadcom.com, rjui@broadcom.com,
adrian.hunter@intel.com, linux-kernel@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] mmc: sdhci-iproc: Add ACPI bindings for the rpi4
Date: Sun, 10 Jan 2021 21:39:07 -0600 [thread overview]
Message-ID: <cd7c5d78-af92-84b9-8bbf-f480f63005e0@arm.com> (raw)
In-Reply-To: <ab3b5788-1148-636a-751f-0a31c87dda33@i2se.com>
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@arm.com>
>> ---
>> 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);
>
next prev parent reply other threads:[~2021-01-11 3:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 21:13 [PATCH] mmc: sdhci-iproc: Add ACPI bindings for the rpi4 Jeremy Linton
2021-01-08 21:27 ` Florian Fainelli
2021-01-09 1:10 ` kernel test robot
2021-01-09 3:18 ` Jeremy Linton
2021-01-09 11:07 ` Stefan Wahren
2021-01-11 3:39 ` Jeremy Linton [this message]
2021-01-11 8:45 ` Ard Biesheuvel
2021-01-11 12:23 ` Stefan Wahren
2021-01-11 21:43 ` Jeremy Linton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd7c5d78-af92-84b9-8bbf-f480f63005e0@arm.com \
--to=jeremy.linton@arm.com \
--cc=adrian.hunter@intel.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=nsaenzjulienne@suse.de \
--cc=rjui@broadcom.com \
--cc=sbranden@broadcom.com \
--cc=stefan.wahren@i2se.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).