Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* Ulf Hansson  [151228 04:18]:
> On 18 December 2015 at 23:31, Tony Lindgren  wrote:
> > * Ulf Hansson  [151218 14:20]:
> >> On 18 December 2015 at 17:14, 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? :-)
> >> >
> >> > 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

On 18 December 2015 at 23:31, Tony Lindgren  wrote:
> * Ulf Hansson  [151218 14:20]:
>> On 18 December 2015 at 17:14, 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? :-)
>> >
>> > 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* 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? :-)

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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* Ulf Hansson  [151218 14:20]:
> On 18 December 2015 at 17:14, 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? :-)
> >
> > 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

On 18 December 2015 at 17:14, 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? :-)
>
> 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

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!?

>
> 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

+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? :-)

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 
> Signed-off-by: Tony Lindgren 
> ---
>  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 = _pwrseq_simple_ops;
>
> return >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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* 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.

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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Javier Martinez Canillas]

Hello Tony,

On 12/07/2015 09:32 PM, 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.
> 
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html