Hello Tony, On 12/07/2015 09:32 PM, Tony Lindgren wrote: > * Ulf Hansson <ulf.hansson@xxxxxxxxxx> [151207 16:20]: >> +Linus >> >> On 7 December 2015 at 23:54, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >>> Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API") >>> changed the handling MMC power sequence so GPIOs no longer are optional. >>> >>> This broke SDIO WLAN at least for omap5 that can't yet use the reset GPIOs >>> with pwrseq_simple as a wait is needed after enabling the SDIO device. >> >> Can you elaborate on this. Did it break omap5 or not? :-) > > Yes it broke WLAN for omap5 that I just got fixed.. It only uses the clocks > art of the pwrseq currently because of the delay needed. > >> Also, I am interested to know more about the waiting period you need. >> I assume that's because of the HW's characteristic? > > At least TI wl12xx and Marvell 8787 need a delay after enabling the the WLAN. > >> Why can't we have that being described in DT and then make >> pwrseq_simple *wait* if needed? > > We can, but I'm thinking that we might be better off adding support for > regulators to pwrseq. Both TI wl12xx and Marvell 8787 get power from the > battery, and probably have an integrated regulator. > > Also, the delay and the power up sequencey can be more complicated than what > we currently support. In the 8787 case, pdn pin needs to be asserted for 300ms > after power pins are stable and while reset is held high. > >>> Let's fix the problem by allocating the GPIO values array during init >>> depending on the optional GPIOs found. >> >> Certainly it shall be optional! I wonder how I could let that patch >> slip through, my bad! > I also wonder how I missed that in my patch, sorry for the mess :( > OK good to hear :) > >> Thanks for fixing this! > +1 > No problem, thanks, > > Tony > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html