LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: "H. Nikolaus Schaller" <hns@goldelico.com>,
Jerome Pouiller <Jerome.Pouiller@silabs.com>
Cc: Avri Altman <avri.altman@wdc.com>,
Shawn Lin <shawn.lin@rock-chips.com>,
Linus Walleij <linus.walleij@linaro.org>,
Bean Huo <beanhuo@micron.com>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
letux-kernel@openphoenux.org, kernel@pyra-handheld.com
Subject: Re: [RFC] mmc: core: transplant ti,wl1251 quirks from to be retired omap_hsmmc
Date: Tue, 26 Oct 2021 19:12:52 +0200 [thread overview]
Message-ID: <CAPDyKFraMXqC9OBeUTpm=bxjrFZTCopV3ZJQf1TRsA8UeTWdTA@mail.gmail.com> (raw)
In-Reply-To: <8ecc5c79c1dd0627d570ede31e18c860786cacca.1633519499.git.hns@goldelico.com>
+ Jerome
On Wed, 6 Oct 2021 at 13:25, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> The TiWi 5 WiFi module needs special setup of the sdio
> interface before it can be probed.
>
> So far, this is done in omap_hsmmc_init_card() in omap_hsmmc.c
> which makes it useable only if connected to omap devices
> which use the omap_hsmmc. The OpenPandora is the most promient
> example.
>
> There are plans to switch to a newer sdhci-omap driver and
> retire omap_hsmmc. Hence this quirk must be reworked or moved
> somewhere else. Ideally to some location that is not dependent
> on the specific SoC mmc host driver.
>
> Analysis has shown that omap_hsmmc_init_card() is called
> through the host->ops->init_card hook which itself
> is called in three generic locations:
>
> mmc_init_card()
> mmc_sd_init_card()
> mmc_sdio_init_card()
>
> All these functions share a call to mmc_select_card() shortly
> after running the init hook and therefore I assume that
> a good place transplanting the special wl1251 handling is
> mmc_select_card() - unless we want to copy and maintain the
> code to three different places.
>
> After this quirk has been moved there, we can remove
> omap_hsmmc_init_card() in omap_hsmmc.c in a separate patch.
> Indeed the plan is to remove omap_hsmmc.c completely.
>
> A future development path to generalize could be to make
> the code not depend on compatible = "ti,wl1251" but check
> for optional device tree properties (non-std-sdio, bus width,
> vendor, device, blksize, max_dtr, ocr) which can be defined
> for any child device of the mmd/sd port needing such special
> setup.
I wouldn't go that path, simply because it may look like we encourage
vendors to deviate from the SDIO spec. :-)
At least for now, matching on the compatible string and applying card
quirks makes perfect sense to me.
>
> Related-to: commit f6498b922e57 ("mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid of pandora_wl1251_init_card")
> Related-to: commit 2398c41d6432 ("omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251")
> Related-to: commit f9d50fef4b64 ("ARM: OMAP2+: omap3-pandora: add wifi support")
> Tested-by: H. Nikolaus Schaller <hns@goldelico.com> # on OpenPandora
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
As a matter of fact, the similar problem that you are looking to
address (applying card quirks based on DT compatibility strings), is
partly being taken care of in another series [1], being discussed
right now. I think the solution for the ti,wl1251 should be based upon
that too. Please have a look and see if you can play with that!?
Kind regards
Uffe
[1]
[RFC PATCH 0/2] mmc: allow to rely on the DT to apply quirks
https://lore.kernel.org/lkml/20211014143031.1313783-1-Jerome.Pouiller@silabs.com/
> ---
> drivers/mmc/core/mmc_ops.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index 0c54858e89c0..6f9b96be9fe6 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -7,6 +7,7 @@
>
> #include <linux/slab.h>
> #include <linux/export.h>
> +#include <linux/of.h>
> #include <linux/types.h>
> #include <linux/scatterlist.h>
>
> @@ -107,6 +108,35 @@ static int _mmc_select_card(struct mmc_host *host, struct mmc_card *card)
>
> int mmc_select_card(struct mmc_card *card)
> {
> + if (card->type == MMC_TYPE_SDIO || card->type == MMC_TYPE_SD_COMBO) {
> + struct device_node *np = card->host->parent->of_node;
> +
> + /*
> + * REVISIT: should be made more general
> + * e.g. by expanding the DT bindings of child nodes to
> + * optionally provide this information:
> + * Documentation/devicetree/bindings/mmc/mmc-card.txt
> + */
> +
> + np = of_get_compatible_child(np, "ti,wl1251");
> + if (np) {
> + /*
> + * We have TI wl1251 attached to this mmc. Pass this
> + * information to the SDIO core because it can't be
> + * probed by normal methods.
> + */
> +
> + dev_info(card->host->parent, "found wl1251\n");
> + card->quirks |= MMC_QUIRK_NONSTD_SDIO;
> + card->cccr.wide_bus = 1;
> + card->cis.vendor = 0x104c;
> + card->cis.device = 0x9066;
> + card->cis.blksize = 512;
> + card->cis.max_dtr = 24000000;
> + card->ocr = 0x80;
> + of_node_put(np);
> + }
> + }
>
> return _mmc_select_card(card->host, card);
> }
> --
> 2.33.0
>
next prev parent reply other threads:[~2021-10-26 17:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 11:25 H. Nikolaus Schaller
2021-10-26 17:12 ` Ulf Hansson [this message]
2021-10-26 18:08 ` H. Nikolaus Schaller
2021-10-27 17:00 ` H. Nikolaus Schaller
2021-10-27 21:31 ` Ulf Hansson
2021-10-28 7:08 ` H. Nikolaus Schaller
2021-10-28 8:59 ` Jérôme Pouiller
2021-10-28 9:31 ` Ulf Hansson
2021-10-28 9:40 ` H. Nikolaus Schaller
2021-10-28 9:43 ` H. Nikolaus Schaller
2021-10-28 9:51 ` Ulf Hansson
2021-10-28 9:55 ` Jérôme Pouiller
2021-10-28 10:07 ` H. Nikolaus Schaller
2021-11-01 9:12 ` H. Nikolaus Schaller
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='CAPDyKFraMXqC9OBeUTpm=bxjrFZTCopV3ZJQf1TRsA8UeTWdTA@mail.gmail.com' \
--to=ulf.hansson@linaro.org \
--cc=Jerome.Pouiller@silabs.com \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=hns@goldelico.com \
--cc=kernel@pyra-handheld.com \
--cc=letux-kernel@openphoenux.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=shawn.lin@rock-chips.com \
--subject='Re: [RFC] mmc: core: transplant ti,wl1251 quirks from to be retired omap_hsmmc' \
/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
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).