From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755604AbcDLDsN (ORCPT ); Mon, 11 Apr 2016 23:48:13 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:33738 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755128AbcDLDsM (ORCPT ); Mon, 11 Apr 2016 23:48:12 -0400 Date: Tue, 12 Apr 2016 04:48:04 +0100 From: Mark Brown To: Pingbo Wen Cc: linux-kernel@vger.kernel.org, lgirdwood@gmail.com, Serge Broslavsky , Vincent Guittot Message-ID: <20160412034804.GT3351@sirena.org.uk> References: <5F710397-FBBA-40DE-B753-C03B9C7FF229@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EcLUEBHJhOmOUQ0C" Content-Disposition: inline In-Reply-To: <5F710397-FBBA-40DE-B753-C03B9C7FF229@linaro.org> X-Cookie: I invented skydiving in 1989! User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC] shared regulator initialization and protection X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --EcLUEBHJhOmOUQ0C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > Those day, I get some fuzz idea in a proxy-consumer regulator driver > [1] from Qcom kernel tree. The driver is simple, that let some > critical regulator, which specified in DT tree, initializing in a > pre-defined state, and hold a regulator consumer during system boot, > to provide some protection between multi-consumers. > And I think this driver is a hint that our upstream code lack of some > regulator intialization and protection. We already have some regulator Given how poorly most of the Qualcom code uses the regulator API I'd take anything they've got out of tree with a pinch of salt. At best this looks like a hack for some system specific issues but since it's just some undocumented code it's hard to tell. > If a regulator only used by one consumer, current code will work fine. > But for the regulator which shared between multi-consumers, we can not > make sure that the regulator will work in a defined-state, during > system boot, since the device driver can probe in any order, and set > some conflict attributes. What is the actual problem here? Every driver is responsible for ensuring that regulators are in a good state before it starts using the hardware, if some other device did something before why do we care? > Currently, I didn=E2=80=99t have much solution for this problem, but I=E2= =80=99m work > on that. The simplest solution is to create an agent regulator driver > to do the first =E2=80=98regulator_get=E2=80=99, just like Qcom proxy con= sumer driver. > Or we define a master device of a regulator, only the master device > can set the regulator attributes, other device can only do the enable > operation. If there are constraints they need to be set in the constraints. If drivers need to cooperate then they need to arrange to cooperate including handling the case where some of them aren't loaded. Anything based on doing things at initcall levels is fundamentally broken, as soon as things are built modular like most things in a distro kernel then it'll stop working. If the system integrator needs some devices to start early to provide continuity (the main case here is display) they need to deal with that at the system integration level. --EcLUEBHJhOmOUQ0C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXDG/zAAoJECTWi3JdVIfQ+30H/2aLvxas/TgdWdZ9KIfLiITz P0zkOj6qqrnep/O/3BNpqjjJgMTnBmQembTbQImCDdbYU0Mbi+RKpnfw6geh7gQ3 KPLzFEUvMCWaIDWPWjuWBlF9frssAYM+NIAKMUeUAutz7I3LIaQe0jiEj0cDtSct J1fkn3MJiqJ7GVnxz5HeyS/9+kyA8v7f5VNSVHv8y8ZLi5FsBb+3yMkL4zwsVCAg kc2iv00Mtyu9Li5QgbKhygqLxEh5K6mDkjeReJGzrjFNRTHjiq4NLuTxlA8JZn0J 9ClZ6KdjpfH/ioVFq6OH0GfAvNLGoP32U2nLUfcFNYZ7RTCmWN5klwefjQrd3i0= =ZFCa -----END PGP SIGNATURE----- --EcLUEBHJhOmOUQ0C--