From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Hunter, Adrian" <adrian.hunter@intel.com>
Subject: Re: Regulator probe
Date: Mon, 05 Sep 2016 19:01:52 +0300 [thread overview]
Message-ID: <1473091312.11323.20.camel@linux.intel.com> (raw)
In-Reply-To: <20160901170215.GJ5967@sirena.org.uk>
On Thu, 2016-09-01 at 18:02 +0100, Mark Brown wrote:
> On Thu, Sep 01, 2016 at 07:15:16PM +0300, Andy Shevchenko wrote:
> >
> > 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:
>
> >
> > >
> > > 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.
>
> Ugh, I'd been assured that SFI had been killed off :(
Yes, though devices are flying around (I dunno what is used in latest
MID SoC [Annidale] on Asus and Lenovo phone, I'm pretty sure it's still
SFI).
>
> Anyway if that's the case then it should all be working already then
> unless SFI goes down the ACPI code paths or someone changed SFI since
> SFI won't flag as having full costraints and therefore any missing
> regulator will report as deferring.
But it's a real burden to describe in platform code _every_ regulators
that device driver may need (for example, "vqmmc" is optional and even
"vmmc" is optional for 2 out of 3 SDHCI host controllers!).
> If that is indeed the case you've
> probably got a broken consumer driver that's not handing probe
> deferrals.
It has, but see above, for 3 SDHCI controllers I have to provide 5 dummy
regulators and 1 real vs. just 1 real.
> > > 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?
>
> You have to either not call regulator_has_full_constraints() or supply
> all the mappings for device supplies before you register a device. If
> you don't call regulator_has_full_constraints() missing regulators
> will
> always defer so you would need to provide a fixed voltage regulator
> for
> it.
It would be plenty of dummy regulators.
> If it's really absent you'll need to provide full constraints, we
> can't tell otherwise.
>
> >
> > >
> > > 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.
>
> It would be a lot more sensible than SFI, it's so limited you're
> basically just using board files but with the limitations of having to
> do bits of it through firmware and then join the two up which seems
> like
> the worst of both worlds.
I dunno if DT has any means of coexistence with e820 BIOS where PCI
devices are enumerated natively.
So, in other words is there any example of something like following:
pinctrl: pinctrl@ {
// platform device of pinctrl
}
pci: {
// anonymous bus ?
gpio: gpio@BDF1 {
// GPIO device which is enumerated via PCI
???
}
sdhci: sdhci@BDF2 {
// SDHCI which requires vmmc@BDF2 to be present
???
}
}
regulator: vmmc@BDF2 {
// Fixed regulator with GPIO provided by gpio@BDF1
}
For now I hardly imagine how it should look like or work.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2016-09-05 16:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 14:53 Regulator probe Andy Shevchenko
2016-09-01 15:38 ` Mark Brown
2016-09-01 16:15 ` Andy Shevchenko
2016-09-01 17:02 ` Mark Brown
2016-09-05 16:01 ` Andy Shevchenko [this message]
2016-09-06 10:24 ` Mark Brown
2016-09-07 14:24 ` Andy Shevchenko
2016-09-09 12:17 ` Mark Brown
2016-09-09 12:55 ` Andy Shevchenko
2016-09-09 15:29 ` Mark Brown
2016-09-09 16:10 ` Andy Shevchenko
2016-09-09 16:38 ` Mark Brown
2016-09-09 17:04 ` Andy Shevchenko
2016-09-09 17:18 ` Mark Brown
2016-09-10 11:03 ` Andy Shevchenko
2016-09-12 15:27 ` Mark Brown
2016-09-12 16:01 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1473091312.11323.20.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=adrian.hunter@intel.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).