[Letux-kernel] [RFC] mmc: core: transplant ti, wl1251 quirks from to be retired omap_hsmmc
H. Nikolaus Schaller
hns at goldelico.com
Tue Oct 26 20:08:42 CEST 2021
+ Tony, linux-omap list
> Am 26.10.2021 um 19:12 schrieb Ulf Hansson <ulf.hansson at linaro.org>:
> + Jerome
> On Wed, 6 Oct 2021 at 13:25, H. Nikolaus Schaller <hns at 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
>> 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:
>> 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
> I wouldn't go that path, simply because it may look like we encourage
> vendors to deviate from the SDIO spec. :-)
Well, that ti,wl1251 chip is so old  that probably the SDIO spec did
deviate from what the vendor thought it will look like :)
> At least for now, matching on the compatible string and applying card
> quirks makes perfect sense to me.
Yes, that is how it already was in the omal_hsmmc driver quirks.
>> 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 at goldelico.com> # on OpenPandora
>> Signed-off-by: H. Nikolaus Schaller <hns at 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 , 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!?
That is interesting.
Yes, maybe it can be the basis. At least for finding the chip and driver.
BR and thanks,
> Kind regards
> [RFC PATCH 0/2] mmc: allow to rely on the DT to apply quirks
More information about the Letux-kernel