From: Mark Brown <broonie@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Hunter, Adrian" <adrian.hunter@intel.com>
Subject: Re: Regulator probe
Date: Thu, 1 Sep 2016 18:02:15 +0100 [thread overview]
Message-ID: <20160901170215.GJ5967@sirena.org.uk> (raw)
In-Reply-To: <1472746516.4887.489.camel@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]
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 :(
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. If that is indeed the case you've
probably got a broken consumer driver that's not handing probe
deferrals.
> > 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. 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-09-01 22:04 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 [this message]
2016-09-05 16:01 ` Andy Shevchenko
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=20160901170215.GJ5967@sirena.org.uk \
--to=broonie@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--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).