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

Groups > linux.kernel > #1474527

Re: Regulator probe

Show all headers | View raw

On Thu, 2016-09-01 at 16:38 +0100, Mark Brown wrote:
> On Thu, Sep 01, 2016 at 05:53:43PM +0300, Andy Shevchenko wrote:
> 
> > 
> > [   20.843973] calling  sdhci_drv_init+0x0/0x20 @ 1
> > [   20.843976] sdhci: Secure Digital Host Controller Interface
> > driver
> > [   20.843978] sdhci: Copyright(c) Pierre Ossman
> > [   20.843989] initcall sdhci_drv_init+0x0/0x20 returned 0 after 5
> > usecs
> > [   20.843999] calling  sdhci_driver_init+0x0/0x1b @ 1
> > 
> > [   20.881460] sdhci-pci 0000:00:01.3: SDHCI controller found
> > [8086:1190] (rev 1)
> > [   20.881471] sdhci-pci 0000:00:01.3: found 1 slot(s)
> > [   20.888242] sdhci-pci 0000:00:01.3: No vmmc regulator found
> 
> > 
> > ^^^^^ PROBLEM!
> > 
> > Regulator is present, though it's in a waiting list.
> 
> The device isn't registered and it's saying it isn't registered, this
> is
> normal.  Since this is an ACPI system

Nope, it's SFI. Which basically means we have everything in board files.

>  we are expecting the firmware or
> whatever else registers devices and their supplies to do that, if the
> supplies aren't being mapped at device registration time then you're
> telling the core not to expect any.  If you had mapped the supply and
> it
> wasn't available the consumer would get an -EPROBE_DEFER.

Basically you mean we have not call regulator_has_full_constraints()?
In that case we have to provide stubs for all expected regulators, in
case of SDHCI one real and one dummy, who knows how many them in the
drivers, but for each we have to provide that. Am I right? 

> 
> As I keep saying with all these problems if you want to reimplement DT
> instead of using it you need to reimplement *all* of DT, it's there
> for
> a reason.  It would be a lot quicker and simpler to just use DT for
> these systems.

Here we have platform code. It might be possible to switch to DT for it,
with no firmware support, but I can consider it as a far away from now.

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-01 17:00 +0200
  Re: Regulator probe Mark Brown <broonie@kernel.org> - 2016-09-01 17:40 +0200
    Re: Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-01 18:30 +0200
      Re: Regulator probe Mark Brown <broonie@kernel.org> - 2016-09-02 00:10 +0200
        Re: Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-05 18:10 +0200
          Re: Regulator probe Mark Brown <broonie@kernel.org> - 2016-09-06 12:40 +0200
            Re: Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-07 16:40 +0200
              Re: Regulator probe Mark Brown <broonie@kernel.org> - 2016-09-09 14:20 +0200
                Re: Regulator probe Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-09-09 15:00 +0200

csiph-web