Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1480142 > unrolled thread

Re: Regulator probe

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Regulator probe Mark Brown <broonie@kernel.org> - 2016-09-09 17:40 +0200
    Re: Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-09 18:20 +0200
      Re: Regulator probe Mark Brown <broonie@kernel.org> - 2016-09-09 18:40 +0200
        Re: Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-09 19:10 +0200
          Re: Regulator probe Mark Brown <broonie@kernel.org> - 2016-09-09 19:20 +0200
        Re: Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-10 13:10 +0200
          Re: Regulator probe Mark Brown <broonie@kernel.org> - 2016-09-12 17:30 +0200
            Re: Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-12 18:10 +0200

#1480142 — Re: Regulator probe

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 09, 2016 at 03:55:27PM +0300, Andy Shevchenko wrote:
> On Fri, 2016-09-09 at 13:17 +0100, Mark Brown wrote:

> > What do you mean?  Of course we should handle probe deferral if we
> > fail to get a resource like a GPIO.  Are you trying to say that this
> > doesn't work for you?

> No, it doesn't.

> Fixed regulator probe is deferred:

> reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register
> regulator: -517

So the regulator probe *does* get deferred as expected...

> But:
> sdhci-pci 0000:00:01.3: No vmmc regulator found

> Code in sdhci driver is:
>         ret = mmc_regulator_get_supply(mmc);
>         if (ret == -EPROBE_DEFER)
>                 return ret;
>
> mmc_regulator_get_supply():
> ...
>         mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc");
>         mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc");

...and then we correctly report that the optional supply that isn't
mapped (as far as I remember) isn't there.

[toc] | [next] | [standalone]

#1480182

On Fri, 2016-09-09 at 16:29 +0100, Mark Brown wrote:

> > Fixed regulator probe is deferred:
> 
> > 
> > reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register
> > regulator: -517
> 
> So the regulator probe *does* get deferred as expected...
> 
> > 
> > But:
> > sdhci-pci 0000:00:01.3: No vmmc regulator found
> 
> > 
> > Code in sdhci driver is:
> >         ret = mmc_regulator_get_supply(mmc);
> >         if (ret == -EPROBE_DEFER)
> >                 return ret;
> > 
> > mmc_regulator_get_supply():
> > ...
> >         mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc");
> >         mmc->supply.vqmmc = devm_regulator_get_optional(dev,
> > "vqmmc");
> 
> ...and then we correctly report that the optional supply that isn't
> mapped (as far as I remember) isn't there.

But it *will be* soon there.

Hmm... And the proper fix for this case is... (let's assume there will
not be device tree solution in nearest future)?

If I remove has_full_constraints() call I will get EPROBE_DEFER on all
optional regulators IIRC.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1480200

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 09, 2016 at 07:10:39PM +0300, Andy Shevchenko wrote:
> On Fri, 2016-09-09 at 16:29 +0100, Mark Brown wrote:

> > ...and then we correctly report that the optional supply that isn't
> > mapped (as far as I remember) isn't there.

> But it *will be* soon there.

> Hmm... And the proper fix for this case is... (let's assume there will
> not be device tree solution in nearest future)?

To supply this particular mapping before you set full constraints.

> If I remove has_full_constraints() call I will get EPROBE_DEFER on all
> optional regulators IIRC.

Yes.

[toc] | [prev] | [next] | [standalone]

#1480210

On Fri, 2016-09-09 at 17:38 +0100, Mark Brown wrote:
> On Fri, Sep 09, 2016 at 07:10:39PM +0300, Andy Shevchenko wrote:
> > 
> > On Fri, 2016-09-09 at 16:29 +0100, Mark Brown wrote:
> 
> > 
> > > 
> > > ...and then we correctly report that the optional supply that
> > > isn't
> > > mapped (as far as I remember) isn't there.
> 
> > 
> > But it *will be* soon there.
> 
> > 
> > Hmm... And the proper fix for this case is... (let's assume there
> > will
> > not be device tree solution in nearest future)?
> 
> To supply this particular mapping before you set full constraints.

Thanks for patience and explanation. I will look later how to achieve
this.

> 
> > 
> > If I remove has_full_constraints() call I will get EPROBE_DEFER on
> > all
> > optional regulators IIRC.
> 
> Yes.

Which basically means that's not a solution I'm trying to get.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1480213

[Multipart message — attachments visible in raw view] — view raw

On Fri, Sep 09, 2016 at 08:04:36PM +0300, Andy Shevchenko wrote:
> On Fri, 2016-09-09 at 17:38 +0100, Mark Brown wrote:

> > > If I remove has_full_constraints() call I will get EPROBE_DEFER on
> > > all
> > > optional regulators IIRC.

> > Yes.

> Which basically means that's not a solution I'm trying to get.

Right, it's not expected to be something that's useful in a finished
system just something that's minimally harmful during development.

[toc] | [prev] | [next] | [standalone]

#1480602

On Fri, 2016-09-09 at 17:38 +0100, Mark Brown wrote:
> On Fri, Sep 09, 2016 at 07:10:39PM +0300, Andy Shevchenko wrote:
> > On Fri, 2016-09-09 at 16:29 +0100, Mark Brown wrote:
> ...and then we correctly report that the optional supply that
> > > isn't
> > > mapped (as far as I remember) isn't there.
> But it *will be* soon there.
> Hmm... And the proper fix for this case is... (let's assume there
> > will
> > not be device tree solution in nearest future)?
> 
> To supply this particular mapping before you set full constraints.

Please, correct me if I'm wrong in the following:
1) mapping is what kept in the regulator_map_list;
2) the only way to list something for this mapping is to use one of
regulator drivers that will call regulator_register() at the end;
3) in case of fixed voltage regulator it prepares configuration and
description (based on platform code for example) of the regulator and
calls devm_regulator_register();
4) regulator_register() _will not_ add fixed regulator to the mapping if
GPIO is deferred;
5) regulator_dev_lookup() didn't see the regulator before
deferred_probe_initcall() happened.

If the above is correct, how to add mapping to be seen in 5) ?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1481421

[Multipart message — attachments visible in raw view] — view raw

On Sat, Sep 10, 2016 at 02:03:35PM +0300, Andy Shevchenko wrote:

> Please, correct me if I'm wrong in the following:
> 1) mapping is what kept in the regulator_map_list;
> 2) the only way to list something for this mapping is to use one of
> regulator drivers that will call regulator_register() at the end;
> 3) in case of fixed voltage regulator it prepares configuration and
> description (based on platform code for example) of the regulator and
> calls devm_regulator_register();
> 4) regulator_register() _will not_ add fixed regulator to the mapping if
> GPIO is deferred;
> 5) regulator_dev_lookup() didn't see the regulator before
> deferred_probe_initcall() happened.

> If the above is correct, how to add mapping to be seen in 5) ?

You may need to extend the interfaces offered by the core - one of the
great advantages of an open source kernel like Linux is that you can
modify the whole system if needed.

[toc] | [prev] | [next] | [standalone]

#1481515

On Mon, 2016-09-12 at 16:27 +0100, Mark Brown wrote:
> On Sat, Sep 10, 2016 at 02:03:35PM +0300, Andy Shevchenko wrote:
> 
> > 
> > Please, correct me if I'm wrong in the following:
> > 1) mapping is what kept in the regulator_map_list;
> > 2) the only way to list something for this mapping is to use one of
> > regulator drivers that will call regulator_register() at the end;
> > 3) in case of fixed voltage regulator it prepares configuration and
> > description (based on platform code for example) of the regulator
> > and
> > calls devm_regulator_register();
> > 4) regulator_register() _will not_ add fixed regulator to the
> > mapping if
> > GPIO is deferred;
> > 5) regulator_dev_lookup() didn't see the regulator before
> > deferred_probe_initcall() happened.
> 
> > 
> > If the above is correct, how to add mapping to be seen in 5) ?
> 
> You may need to extend the interfaces offered by the core - one of the
> great advantages of an open source kernel like Linux is that you can
> modify the whole system if needed.

Yeah, the core seems not able to handle my case. So, that's what I was
trying to tell.

I will look at the code later and see what I can amend there.

Thanks!

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web