| Message ID | 1449528845-25189-1-git-send-email-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
+Linus On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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? :-) Also, I am interested to know more about the waiting period you need. I assume that's because of the HW's characteristic? Why can't we have that being described in DT and then make pwrseq_simple *wait* if needed? > > 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! Thanks for fixing this! > > Note that depending on the board specific configuration, some of the GPIOs > can be permanently set up with pulls, so we want to keep pwrseq_simple > GPIOs optional. > > Cc: Javier Martinez Canillas <javier@osg.samsung.com> > Signed-off-by: Tony Lindgren <tony@atomide.com> > --- > drivers/mmc/core/pwrseq_simple.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > > --- a/drivers/mmc/core/pwrseq_simple.c > +++ b/drivers/mmc/core/pwrseq_simple.c > @@ -24,6 +24,7 @@ struct mmc_pwrseq_simple { > bool clk_enabled; > struct clk *ext_clk; > struct gpio_descs *reset_gpios; > + int *values; > }; > > static void mmc_pwrseq_simple_set_gpios_value(struct mmc_pwrseq_simple *pwrseq, > @@ -31,13 +32,15 @@ static void mmc_pwrseq_simple_set_gpios_value(struct mmc_pwrseq_simple *pwrseq, > { > int i; > struct gpio_descs *reset_gpios = pwrseq->reset_gpios; > - int values[reset_gpios->ndescs]; I would prefer if we don't need to keep this memory on the heap. Can't we instead keep a local copy of the reset_gpios->ndesc and when pwrseq->reset_gpios doesn't exist use a default value? > + > + if (!reset_gpios || !reset_gpios->ndescs) > + return; > > for (i = 0; i < reset_gpios->ndescs; i++) > - values[i] = value; > + pwrseq->values[i] = value; > > gpiod_set_array_value_cansleep(reset_gpios->ndescs, reset_gpios->desc, > - values); > + pwrseq->values); > } > > static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host) > @@ -84,6 +87,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host) > if (!IS_ERR(pwrseq->ext_clk)) > clk_put(pwrseq->ext_clk); > > + kfree(pwrseq->values); > kfree(pwrseq); > } > > @@ -111,12 +115,20 @@ struct mmc_pwrseq *mmc_pwrseq_simple_alloc(struct mmc_host *host, > goto free; > } > > - pwrseq->reset_gpios = gpiod_get_array(dev, "reset", GPIOD_OUT_HIGH); > + pwrseq->reset_gpios = gpiod_get_array_optional(dev, "reset", > + GPIOD_OUT_HIGH); > if (IS_ERR(pwrseq->reset_gpios)) { The original code also considered -ENOSYS, as that's the return code you get when CONFIG_GPIOLIB is unset, I think we need that as well. Although, perhaps it's more correct that the gpiolib API returns NULL instead of ERR_PTR(-ENOSYS)? I have added Linus, to see if he has any comments on this. > ret = PTR_ERR(pwrseq->reset_gpios); > goto clk_put; > } > > + if (pwrseq->reset_gpios && pwrseq->reset_gpios->ndescs) { > + pwrseq->values = kzalloc(pwrseq->reset_gpios->ndescs * > + sizeof(int), GFP_KERNEL); > + if (!pwrseq->values) > + goto clk_put; This will leak a gpio cookie as it needs a gpiod_put_array(). > + } > + > pwrseq->pwrseq.ops = &mmc_pwrseq_simple_ops; > > return &pwrseq->pwrseq; > -- > 2.6.2 > One final comment, gpiod_put_array() doesn't deal with NULL pointers. You need to check that in mmc_pwrseq_simple_free(). Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: > +Linus > > On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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! OK good to hear :) > Thanks for fixing this! No problem, thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Tony, On 12/07/2015 09:32 PM, Tony Lindgren wrote: > * Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: >> +Linus >> >> On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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,
On 8 December 2015 at 01:32, Tony Lindgren <tony@atomide.com> wrote: > * Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: >> +Linus >> >> On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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!? > > 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. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ulf Hansson <ulf.hansson@linaro.org> [151208 05:18]: > On 8 December 2015 at 01:32, Tony Lindgren <tony@atomide.com> wrote: > > * Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: > >> +Linus > >> > >> On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: > +Linus > > On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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? :-) Ulf, is this patch queued for v4.4 as a regression fix? I don't see it in Linux next or mainline trees? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 18 December 2015 at 17:14, Tony Lindgren <tony@atomide.com> wrote: > * Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: >> +Linus >> >> On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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? :-) > > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it > in Linux next or mainline trees? Ohh, I guess there where some misunderstanding. I made a bunch of comments on your patch as well, so I have been expecting a new version. Sorry if that was unclear! Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ulf Hansson <ulf.hansson@linaro.org> [151218 14:20]: > On 18 December 2015 at 17:14, Tony Lindgren <tony@atomide.com> wrote: > > * Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: > >> +Linus > >> > >> On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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? :-) > > > > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it > > in Linux next or mainline trees? > > Ohh, I guess there where some misunderstanding. I made a bunch of > comments on your patch as well, so I have been expecting a new > version. Well this $subject patch was intended as a regression fix for v4.4-rc cycle. All the other things discussed are not fixes but new features instead. > Sorry if that was unclear! I think this patch should be still fine as is, care to take a look again? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 18 December 2015 at 23:31, Tony Lindgren <tony@atomide.com> wrote: > * Ulf Hansson <ulf.hansson@linaro.org> [151218 14:20]: >> On 18 December 2015 at 17:14, Tony Lindgren <tony@atomide.com> wrote: >> > * Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: >> >> +Linus >> >> >> >> On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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? :-) >> > >> > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it >> > in Linux next or mainline trees? >> >> Ohh, I guess there where some misunderstanding. I made a bunch of >> comments on your patch as well, so I have been expecting a new >> version. > > Well this $subject patch was intended as a regression fix for v4.4-rc cycle. > All the other things discussed are not fixes but new features instead. > >> Sorry if that was unclear! > > I think this patch should be still fine as is, care to take a look again? No, the patch have issues that needs to be fixed. http://www.spinics.net/lists/linux-mmc/msg34399.html Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ulf Hansson <ulf.hansson@linaro.org> [151228 04:18]: > On 18 December 2015 at 23:31, Tony Lindgren <tony@atomide.com> wrote: > > * Ulf Hansson <ulf.hansson@linaro.org> [151218 14:20]: > >> On 18 December 2015 at 17:14, Tony Lindgren <tony@atomide.com> wrote: > >> > * Ulf Hansson <ulf.hansson@linaro.org> [151207 16:20]: > >> >> +Linus > >> >> > >> >> On 7 December 2015 at 23:54, Tony Lindgren <tony@atomide.com> 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? :-) > >> > > >> > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it > >> > in Linux next or mainline trees? > >> > >> Ohh, I guess there where some misunderstanding. I made a bunch of > >> comments on your patch as well, so I have been expecting a new > >> version. > > > > Well this $subject patch was intended as a regression fix for v4.4-rc cycle. > > All the other things discussed are not fixes but new features instead. > > > >> Sorry if that was unclear! > > > > I think this patch should be still fine as is, care to take a look again? > > No, the patch have issues that needs to be fixed. > http://www.spinics.net/lists/linux-mmc/msg34399.html Oh sorry, somehow I did not notice those comments earlier, will take a look. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/drivers/mmc/core/pwrseq_simple.c +++ b/drivers/mmc/core/pwrseq_simple.c @@ -24,6 +24,7 @@ struct mmc_pwrseq_simple { bool clk_enabled; struct clk *ext_clk; struct gpio_descs *reset_gpios; + int *values; }; static void mmc_pwrseq_simple_set_gpios_value(struct mmc_pwrseq_simple *pwrseq, @@ -31,13 +32,15 @@ static void mmc_pwrseq_simple_set_gpios_value(struct mmc_pwrseq_simple *pwrseq, { int i; struct gpio_descs *reset_gpios = pwrseq->reset_gpios; - int values[reset_gpios->ndescs]; + + if (!reset_gpios || !reset_gpios->ndescs) + return; for (i = 0; i < reset_gpios->ndescs; i++) - values[i] = value; + pwrseq->values[i] = value; gpiod_set_array_value_cansleep(reset_gpios->ndescs, reset_gpios->desc, - values); + pwrseq->values); } static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host) @@ -84,6 +87,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host) if (!IS_ERR(pwrseq->ext_clk)) clk_put(pwrseq->ext_clk); + kfree(pwrseq->values); kfree(pwrseq); } @@ -111,12 +115,20 @@ struct mmc_pwrseq *mmc_pwrseq_simple_alloc(struct mmc_host *host, goto free; } - pwrseq->reset_gpios = gpiod_get_array(dev, "reset", GPIOD_OUT_HIGH); + pwrseq->reset_gpios = gpiod_get_array_optional(dev, "reset", + GPIOD_OUT_HIGH); if (IS_ERR(pwrseq->reset_gpios)) { ret = PTR_ERR(pwrseq->reset_gpios); goto clk_put; } + if (pwrseq->reset_gpios && pwrseq->reset_gpios->ndescs) { + pwrseq->values = kzalloc(pwrseq->reset_gpios->ndescs * + sizeof(int), GFP_KERNEL); + if (!pwrseq->values) + goto clk_put; + } + pwrseq->pwrseq.ops = &mmc_pwrseq_simple_ops; return &pwrseq->pwrseq;
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. Let's fix the problem by allocating the GPIO values array during init depending on the optional GPIOs found. Note that depending on the board specific configuration, some of the GPIOs can be permanently set up with pulls, so we want to keep pwrseq_simple GPIOs optional. Cc: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Tony Lindgren <tony@atomide.com> --- drivers/mmc/core/pwrseq_simple.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)