mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Wahren <stefan.wahren@i2se.com>
To: Jeremy Linton <jeremy.linton@arm.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: Mon, 11 Jan 2021 13:23:50 +0100	[thread overview]
Message-ID: <2d92e093-a6f2-ac2c-d7e3-2d0172e1047c@i2se.com> (raw)
In-Reply-To: <cd7c5d78-af92-84b9-8bbf-f480f63005e0@arm.com>

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

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



  parent reply	other threads:[~2021-01-11 12:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08 21:13 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
2021-01-11  8:45     ` Ard Biesheuvel
2021-01-11 12:23     ` Stefan Wahren [this message]
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=2d92e093-a6f2-ac2c-d7e3-2d0172e1047c@i2se.com \
    --to=stefan.wahren@i2se.com \
    --cc=adrian.hunter@intel.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=f.fainelli@gmail.com \
    --cc=jeremy.linton@arm.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=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

all inboxes | Powered by JetHome®