From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Rajat Jain <rajatja@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
linux-mmc <linux-mmc@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Rajat Jain <rajatxjain@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Dmitry Torokhov <dtor@google.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] mmc: sdhci-pci: Try "cd" for card-detect lookup before using NULL
Date: Fri, 19 Oct 2018 12:13:24 +0300 [thread overview]
Message-ID: <CAHp75Vd_r4QGR5xw2cJigM2J3WStg_0PdynBXMZOyZh+t1znKg@mail.gmail.com> (raw)
In-Reply-To: <20181018215101.169847-1-rajatja@google.com>
On Fri, Oct 19, 2018 at 12:53 AM Rajat Jain <rajatja@google.com> wrote:
>
> Problem:
>
> The card detect IRQ does not work with modern BIOS (that want
> to use DSD to provide the card detect GPIO to the driver).
>
> Details:
>
> (Discussion: https://lkml.org/lkml/2018/9/25/1113)
We have a Link tag for such references.
> The mmc core provides the mmc_gpiod_request_cd() API to let host drivers
> request the gpio descriptor for the "card detect" (or carrier detect?) pin.
card detect is a right term.
> This pin is specified in the ACPI for the SDHC device:
>
> * Either as a resource using _CRS. This is a method used by legacy BIOS.
> (The driver needs to tell which resource index).
>
> * Or as a named property ("cd-gpio") in DSD (which may internally point
cd-gpios (gpio suffix is a legacy).
> to an entry in _CRS). This way, the driver can lookup using a string.
> This is what modern BIOS prefer to use.
>
> This API finally results in a call to the following code:
>
> struct gpio_desc *acpi_find_gpio(..., const char *con_id,...)
> {
> ...
> /* Lookup gpio (using "<con_id>-gpio") in the _DSD */
> ...
> if (!acpi_can_fallback_to_crs(adev, con_id))
> return ERR_PTR(-ENOENT);
> ...
> /* Falling back to _CRS is allowed, Lookup gpio in the _CRS */
> ...
> }
>
> Note that this means that if the ACPI has _DSD properties, the kernel
> will never use _CRS for the lookup (Because acpi_can_fallback_to_crs()
> will always be false for any device hat has _DSD entries).
>
> The SDHCI driver is thus currently broken on a modern BIOS
> (even if
> BIOS provides both _CRS and DSD entries, either of which could be used for
_DSD
> a successful lookup).
This is incorrect. _DSD for GPIOs without any accompanying _CRS
doesn't make any sense.
> Ironically, none of these will be used for the
> lookup currently because:
>
> * Since the con_id is NULL, acpi_find_gpio() does not find a matching
> entry in DSDT. (The DSDT entry has the property name = "cd-gpio")
cd-gpios
>
> * Because ACPI contains DSDT entries, thus acpi_can_fallback_to_crs()
> returns false (because device properties have been populated from
> DSD), thus the _CRS is never used for the lookup.
_DSD
>
> Fix:
>
> Try "cd" for lookup in the _DSD before falling back to using NULL so
> as to try looking up in the _CRS.
>
> I've tested this patch successfully with both Legacy BIOS (that
> provide only _CRS method) as well as modern BIOS (that provide both
> _CRS and DSD). Also the use of "cd" also appears to be farly consistent
_DSD
fairly
> across other users of this API (other MMC host controller drivers).
> if (slot->cd_idx >= 0) {
> - ret = mmc_gpiod_request_cd(host->mmc, NULL, slot->cd_idx,
> + ret = mmc_gpiod_request_cd(host->mmc, "cd", slot->cd_idx,
> slot->cd_override_level, 0, NULL);
Yes.
> + if (ret && ret != -EPROBE_DEFER)
> + ret = mmc_gpiod_request_cd(host->mmc, NULL,
> + slot->cd_idx,
> + slot->cd_override_level,
> + 0, NULL);
And no. Instead of this part you need to provide an ACPI GPIO mapping table.
See examples, like
net/rfkill/rfkill-gpio.c
(look for acpi_rfkill_default_gpios)
> if (ret == -EPROBE_DEFER)
> goto remove;
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2018-10-19 9:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-25 20:54 sdhci driver card-detect is broken because gpiolib can't fallback to _CRS? Rajat Jain
2018-09-26 7:47 ` Mika Westerberg
2018-09-26 8:42 ` Andy Shevchenko
2018-09-26 19:25 ` Rajat Jain
2018-09-27 7:26 ` Andy Shevchenko
2018-09-27 17:56 ` Rajat Jain
2018-09-28 8:42 ` Linus Walleij
2018-09-28 12:34 ` Rajat Jain
2018-09-28 13:13 ` Linus Walleij
2018-10-18 21:51 ` [PATCH] mmc: sdhci-pci: Try "cd" for card-detect lookup before using NULL Rajat Jain
2018-10-19 9:13 ` Andy Shevchenko [this message]
2018-10-22 23:34 ` Rajat Jain
2018-10-24 10:02 ` Andy Shevchenko
2018-10-24 18:03 ` Dmitry Torokhov
2018-10-29 15:23 ` Andy Shevchenko
2018-10-29 17:22 ` Rajat Jain
2018-10-29 17:43 ` Andy Shevchenko
2018-10-29 19:43 ` Rajat Jain
2018-10-29 22:17 ` [PATCH v2] " Rajat Jain
2018-10-30 7:53 ` Adrian Hunter
2018-11-12 11:05 ` Ulf Hansson
2018-11-12 11:25 ` Andy Shevchenko
2018-11-13 1:26 ` Rajat Jain
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=CAHp75Vd_r4QGR5xw2cJigM2J3WStg_0PdynBXMZOyZh+t1znKg@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=adrian.hunter@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dtor@google.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rajatja@google.com \
--cc=rajatxjain@gmail.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).