Re: Regulator probe

[Andy Shevchenko]

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@xxxxxxxxxxxxxxx>
Intel Finland Oy