From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933115AbcIEQG0 (ORCPT ); Mon, 5 Sep 2016 12:06:26 -0400 Received: from mga03.intel.com ([134.134.136.65]:26849 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932416AbcIEQGZ (ORCPT ); Mon, 5 Sep 2016 12:06:25 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,287,1470726000"; d="scan'208";a="757355579" Message-ID: <1473091312.11323.20.camel@linux.intel.com> Subject: Re: Regulator probe From: Andy Shevchenko To: Mark Brown Cc: "linux-kernel@vger.kernel.org" , "Hunter, Adrian" Date: Mon, 05 Sep 2016 19:01:52 +0300 In-Reply-To: <20160901170215.GJ5967@sirena.org.uk> References: <1472741623.4887.482.camel@linux.intel.com> <20160901153836.GI5967@sirena.org.uk> <1472746516.4887.489.camel@linux.intel.com> <20160901170215.GJ5967@sirena.org.uk> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Intel Finland Oy