[Letux-kernel] omap_hsmmc_init/omap_hsmmc_late_init

H. Nikolaus Schaller hns at goldelico.com
Wed Sep 13 12:01:38 CEST 2017


> Am 13.09.2017 um 11:41 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi Notaz,
> 
>> Am 10.09.2017 um 15:35 schrieb Grazvydas Ignotas <notasas at gmail.com>:
>> 
>> On Fri, Sep 8, 2017 at 7:50 PM, H. Nikolaus Schaller <hns at goldelico.com> wrote:
>>>> Am 08.09.2017 um 18:00 schrieb Tony Lindgren <tony at atomide.com>:
>>>> Hmm it might be possible to just init the MMC_QUIRK_NONSTD_SDIO
>>>> in omap_hsmmc.c driver directly based on a custom compatible
>>>> like "ti,omap4-hsmmc-wl1251".
>>> 
>>> Ah, that could be a simple addition. We do have others like
>>> ti,non-removable or ti,needs-special-reset.
>>> 
>>>> But maybe there's some better
>>>> solution that would be more future proof with the SDHCI driver
>>>> work progressing nicely.
>>>> 
>>>> Anyways, getting rid of the platform_data for hsmmc sure
>>>> would make things simpler.
>>> 
>>> To me it looks as if the key activity which makes it non-standard
>>> is to call pandora_wl1251_init_card() after starting sdio.
>>> 
>>> And registering the wl1251 platform driver without DT (sdio subnode
>>> support).
>>> 
>>> @notaz: what is your opinions?
>> 
>> The reason NONSTD_SDIO was needed is because wl1251 lacks standard
>> SDIO registers that identify the chip and it's SDIO functions (only
>> later TI chips have that). There was no way to pass that data through
>> DT, so mmc3 was disabled in DT and started through platform_data with
>> the data passed through using a quirk.
> 
> It looks to me as if it could suffice to call (or inline the code)
> 
> 	pandora_wl1251_init_card(func->mmc);
> 
> in wl1251_sdio_probe() [1] on success.
> 
> So I wonder if other SDIO based boards don't have the same issue
> of missing identification. In that case it would not only be Pandora
> specific.
> 
> If we can do that, we just have to make the pdata driver being loaded
> by DT...
> 
> Maybe adding a compatibility table to drivers/net/wireless/ti/wl1251/sdio.c
> could do the magic. But the way the wl187x sdio subnode is handled could
> show the right solution.

(wl183x of course). It is obviously done in drivers//net/wireless/ti/wlcore/sdio.c

There is a reference to wl1271 glue. What is the difference between wl1251 and wl1271?
Ah, WiLink 4 vs. WiLink 6.

But the code seems to confirm that we might just need some DT match table.
Could go similar to 5ea5c518ccaba0de97efb71c3bccbcdee681c2e6.

I wish I had less unfinished constructions sites...

> 
>> 
>> I haven't followed the development for years now, so have no idea how
>> to solve it best in current kernel. As there are no mainline users
>> (nobody noticed the breakage for more than a year) and it's broken
>> without a known fix, it might make sense to just remove wl1251
>> support.
>> 
>> Gražvydas
> 
> BR,
> Nikolaus
> 
> [1]: http://elixir.free-electrons.com/linux/v4.1/source/drivers/net/wireless/ti/wl1251/sdio.c#L225
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel



More information about the Letux-kernel mailing list