Received: by 10.223.185.116 with SMTP id b49csp8591129wrg; Fri, 2 Mar 2018 04:40:28 -0800 (PST) X-Google-Smtp-Source: AG47ELvUU9M8fHUS9wV/FYuG2YN5QP3y9u4NeJMCYbV+srjfvioVBoWj+aQkDhvYgFxInqgDSAnu X-Received: by 10.99.95.201 with SMTP id t192mr4532611pgb.313.1519994428469; Fri, 02 Mar 2018 04:40:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519994428; cv=none; d=google.com; s=arc-20160816; b=eoP1UpG9Nzbz4oWL5DhPxo0nS2+kTjPeThFg9ddssZD+yJZbCIKpp3A2JAGYxDSKxE evan1HxsAEEkJPlHm1WWc4lACTxQbefuEWzY1syDxCobwq4veg9mT41OXxzeeNmrSAG2 t6nTX2o/+3J9LbkJxlFAVLZwUzbNclH1acypMMqzo+fdoFYTe7SYaHoiCYbb7nLTlRx6 SlIR8pLYo1fWFU+y7WtztoeRH3rabTucXnr8AfBSfhNftVa8fZGWzvQeiEwLzc2nzXrG cY8gr5sGS6FHzfG4g/PnCN62PbODGHN9fG+69pKfxR0gxb6DY5zzcdo+id1CoN+VaN+u H28Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:cms-type:message-id:date :subject:cc:to:from:dkim-signature:dkim-filter :arc-authentication-results; bh=siyz+htmXt6OMVrJ/Mg3nrnTfUfqAGmRDheNDLqLHvQ=; b=YhdWa2Wr91QCJc0T0owYSRaTmT4ut2ewBRLEEaHYKg3/5QsKuSqh58Vr7L9yPwmGIm mnnrO+EsJ9uiSlewTgjVjfWujww46wXhvLVpQZJIHmnKDL0H9pbkeIe+nF1nDpx8iJAi RqEDQfljWE2/nRuVyTAWAeKHSxaT2h85bGYxLyvAglulyW/G6TcXIkFn0gNXicfuBTxn dOD7I3hCdAZs4ahp5uJwdzavtNk6/5q43ahp7EveAatbOUEKsdRiTzWNWGAq2ETjhKpe InrDsiSbKNQTiQe0nMbVbjRXPoJe7cK7wMqBM440RaV5niaxVu184+ZxiCCmDFlvr1n3 l32g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b=DfIgQ10A; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si3943193pgq.765.2018.03.02.04.40.13; Fri, 02 Mar 2018 04:40:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b=DfIgQ10A; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1165043AbeCBIv2 (ORCPT + 99 others); Fri, 2 Mar 2018 03:51:28 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:60983 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1164949AbeCBIvX (ORCPT ); Fri, 2 Mar 2018 03:51:23 -0500 Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20180302085120euoutp010ea9f096e5dbf462a1d261213d918393~YDmAt4AF32751027510euoutp01V; Fri, 2 Mar 2018 08:51:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20180302085120euoutp010ea9f096e5dbf462a1d261213d918393~YDmAt4AF32751027510euoutp01V DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1519980680; bh=siyz+htmXt6OMVrJ/Mg3nrnTfUfqAGmRDheNDLqLHvQ=; h=From:To:Cc:Subject:Date:References:From; b=DfIgQ10ADJgL+P/N+WVxPCxuhl7vrotfi4NQmyqit+iCsIZwB1/PxYB1R2wU49F5Y zdMc4d74oQNnx/mRUqhIidhWlSPzay/A21a3bO20bgwKlG5HcNEoYtSitE7D363Cmc NexpRpcpmuJapYZayKI4nnhuDnjzh67nv+rZAqP0= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20180302085119eucas1p12c66c03610efa7a9b806256a9f5742f5~YDl-rRvCw1382813828eucas1p1L; Fri, 2 Mar 2018 08:51:19 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id E5.07.17380.780199A5; Fri, 2 Mar 2018 08:51:19 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20180302085118eucas1p15a6a5ec5f7f47a6f67a45c5e9495b120~YDl_-xtwD1600816008eucas1p1Q; Fri, 2 Mar 2018 08:51:18 +0000 (GMT) X-AuditID: cbfec7f4-713ff700000043e4-8e-5a9910875345 Received: from eusync1.samsung.com ( [203.254.199.211]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id A1.FD.04178.680199A5; Fri, 2 Mar 2018 08:51:18 +0000 (GMT) Received: from AMDC2075.DIGITAL.local ([106.120.51.25]) by eusync1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0P4Y008BPG7PXE30@eusync1.samsung.com>; Fri, 02 Mar 2018 08:51:18 +0000 (GMT) From: Maciej Purski To: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Cc: Mark Brown , Liam Girdwood , Rob Herring , Mark Rutland , Marek Szyprowski , Doug Anderson , Bartlomiej Zolnierkiewicz , Maciej Purski Subject: [PATCH v5 0/5] Add coupled regulators mechanism Date: Fri, 02 Mar 2018 09:42:44 +0100 Message-id: <1519980169-8491-1-git-send-email-m.purski@samsung.com> X-Mailer: git-send-email 2.7.4 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsWy7djP87rtAjOjDPYcZ7PYOGM9q8XUh0/Y LOYfOcdqcXbZQTaLb1c6mCwu75rDZrHg5S0Wi7VH7rJbLL1+kcmide8RdgcujzXz1jB6zG64 yOKxc9Zddo9NqzrZPPq2rGL0+LxJLoAtissmJTUnsyy1SN8ugSvj/7Ln7AXPJSte9nxjbmCc K9LFyMkhIWAi8eHCc3YQW0hgBaPE5eOyEPZnRomzO2Jgah6/b2HqYuQCii9jlJhwtY0dwvnP KHHs+EK2LkYODjYBLYk17fEgDSICNhJvbxxgBKlhFjjOJHF96kYmkISwgIXEry1bWUBsFgFV iX+nN4Nt5hVwlng7pYMFYpucxM1zncwQdg+bxNk1fhC2i8TOtgZGCFtY4tXxLewQtoxEZ8dB Jgi7WuLi111sEHaNROPtDVA11hKfJ20Bm8kswCcxadt0ZpCbJQR4JTrahCBKPCQ+XTsE1eoo sWfdWTZIQMRKfN6/lnkCo+QCRoZVjOKppcW56anFRnmp5XrFibnFpXnpesn5uZsYgRF6+t/x LzsYd/1JOsQowMGoxMOb8X5GlBBrYllxZe4hRgkOZiUR3pYPQCHelMTKqtSi/Pii0pzU4kOM 0hwsSuK8cRp1UUIC6YklqdmpqQWpRTBZJg5OqQbGoA93u2sfXtZZc217Q9reljpH4brUaS0a THO3rL1oUxqn0XRp/duanZcNFugI6Pj/eaVb/atge8NvlpCbj6xbxU0PN/QnXnXNL/9zZVrB 09cNvaV7jr+UfLwzevoxHellLyQVpmv/5fFe6HP1XFNCUdNj9zv3XleL25lpP1C3leyyqVh0 gW2vEktxRqKhFnNRcSIAmItstswCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42I5/e/4Zd02gZlRBv3tChYbZ6xntZj68Amb xfwj51gtzi47yGbx7UoHk8XlXXPYLBa8vMVisfbIXXaLpdcvMlm07j3C7sDlsWbeGkaP2Q0X WTx2zrrL7rFpVSebR9+WVYwenzfJBbBFcdmkpOZklqUW6dslcGX8X/acveC5ZMXLnm/MDYxz RboYOTkkBEwkHr9vYepi5OIQEljCKDGjfSkzhNPIJHHgynLGLkYODjYBLYk17fEgDSICNhJv bxxgBKlhFjjJJPHn4jpGkISwgIXEry1bWUBsFgFViX+nN7OD2LwCzhJvp3SwQGyTk7h5rpN5 AiPXAkaGVYwiqaXFuem5xYZ6xYm5xaV56XrJ+bmbGIFBs+3Yz807GC9tDD7EKMDBqMTDe+Dj jCgh1sSy4srcQ4wSHMxKIrwtH4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec8bVEYJCaQnlqRm p6YWpBbBZJk4OKUaGJsTbk/4lx69VveSlP60Ze0ioft/+JTl6NR2p+u3/rcKOLymePqzE0kF 81kMuc6KPLQQ9vFyO+8YK++eeFSuu5DxskFs5CeGQMGqrpnT7gb51bVPu328XeTogaIyibVm grvSExu3Od9/6fdukUj6qoyv3X9dpLpctBNWzEm4vOfs4ZSiTz6FSizFGYmGWsxFxYkACY+e PRYCAAA= X-CMS-MailID: 20180302085118eucas1p15a6a5ec5f7f47a6f67a45c5e9495b120 X-Msg-Generator: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180302085118eucas1p15a6a5ec5f7f47a6f67a45c5e9495b120 X-RootMTR: 20180302085118eucas1p15a6a5ec5f7f47a6f67a45c5e9495b120 References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, this patchset adds a new mechanism to the framework - regulators' coupling. On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Algorithmicaly the problem was solved by: Inderpal Singh Doug Anderson The discussion on that subject can be found here: https://lkml.org/lkml/2014/4/29/28 Therefore this patchset is an attempt to apply the idea to regulators core as concluded in the discussion by Mark Brown and Doug Anderson. This feature is required to enable support for generic CPUfreq and devfreq drivers for the mentioned boards. Note on the locking model: When balancing voltage of a group of coupled regulators, we lock all of them for the whole operation. When voltage of an individual regulator is about to change, its suppliers are additionally locked. The current assumption is that an uncoupled regulator is a special case of a coupled one, so they should share a common voltage setting path. Best regards, Maciej Purski --- Changes in v5: - rebase against current Mark Brown's regulators next Changes in v4: - make paths for coupled and uncoupled regulators common - coupling descriptors are now always present in regulator_dev - fail to probe if data inconsistency is detected - retry to resolve coupling regultors in late init call - rebase on top of linux-next 20180119 - fix commit messages - split patches to make the patchset easier to review Changes in v3: - move dts parsing code to of_regulator.c, in order to the so, add a new commit in which of_regulator_find_by_node() is moved to of_regulator.c as well - improve error messages - move max_spread variable to constraints - perform resolving of coupled regulators under a list mutex - remove useless locking functions - some minor refactorization - improve commit messages Changes in RFC v2: - allow coupling n regulators (in fact up to constant value, now set to 10) - change algorithm to be more readable - introduce better locking - add more comments - split first patch into two - update commit messages - change sequence of the patches Maciej Purski (5): regulator: bindings: Add properties for coupled regulators regulator: core: Parse coupled regulators properties regulator: core: Resolve coupled regulators regulator: core: Add voltage balancing mechanism regulator: core: Change voltage setting path .../devicetree/bindings/regulator/regulator.txt | 5 + drivers/regulator/core.c | 381 ++++++++++++++++++++- drivers/regulator/internal.h | 6 + drivers/regulator/of_regulator.c | 149 ++++++++ include/linux/regulator/driver.h | 18 + include/linux/regulator/machine.h | 4 + 6 files changed, 545 insertions(+), 18 deletions(-) -- 2.7.4