From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs Date: Tue, 8 Dec 2015 07:57:29 -0800 Message-ID: <20151208155728.GW23396@atomide.com> References: <1449528845-25189-1-git-send-email-tony@atomide.com> <20151208003213.GU23396@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org To: Ulf Hansson Cc: Linus Walleij , linux-mmc , "linux-arm-kernel@lists.infradead.org" , linux-omap , Javier Martinez Canillas List-Id: linux-omap@vger.kernel.org * Ulf Hansson [151208 05:18]: > On 8 December 2015 at 01:32, Tony Lindgren wrote: > > * Ulf Hansson [151207 16:20]: > >> +Linus > >> > >> On 7 December 2015 at 23:54, Tony Lindgren 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. > > Sounds very reasonable! Perhaps some of the delays can be handled > within the context of the regulator then!? Yes that's in the regulator binding. As long as the pwrseq code can sleep there's no problem with that. > > 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. > > I am for sure open to extend pwrseq_simple, please go ahead! > > The initial version provided a proof of concept and the > infrastructure. I expect and want people to extend it to suit their > HWs. > > If we at some point find that pwrseq_simple starts to become too > complex, we may add another pwrseq type with a corresponding new > compatible string. Yeah OK I'll take a look when I get a chance. Regards, Tony