From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756338AbdJRMr2 (ORCPT ); Wed, 18 Oct 2017 08:47:28 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:57332 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755883AbdJRMr0 (ORCPT ); Wed, 18 Oct 2017 08:47:26 -0400 X-AuditID: cbfec7f1-f793a6d00000326b-e2-59e74d5b921f From: Maciej Purski To: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Cc: Mark Brown , Liam Girdwood , Rob Herring , Mark Rutland , Marek Szyprowski , Bartlomiej Zolnierkiewicz , Maciej Purski Subject: [RFC PATCH v2 0/3] Add coupled regulators mechanism Date: Wed, 18 Oct 2017 14:46:59 +0200 Message-id: <1508330822-8039-1-git-send-email-m.purski@samsung.com> X-Mailer: git-send-email 2.7.4 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsWy7djP87rRvs8jDb5/FLbYOGM9q8XUh0/Y LOYfOcdq8e1KB5PF5V1z2CwWvLzFYrH2yF12i6XXLzJZtO49wu7A6bFm3hpGj52z7rJ7bFrV yebRt2UVo8fnTXIBrFFcNimpOZllqUX6dglcGXOO9bEU9ItUbDzWwNzA2CjQxcjJISFgIrHw wU82CFtM4sK99UA2F4eQwFJGiW0rprNCOJ8ZJSZv+ccM0/F69UdGiMQyRolJCyazQzj/GSX2 nGkCcjg42AS0JNa0x4M0iAjYSLy9cQCsgVlgHpPE1KOTwCYJAyUeb+ljB7FZBFQlJv6dBxbn FXCWOHTpDSvENjmJm+c6mUGaJQR62CTOnv/HDpFwkZj48wPUScISr45vgYrLSHR2HGSCsKsl Ln7dBfVcjUTj7Q1QNdYSnydtAetlFuCTmLRtOjPI0RICvBIdbUIQpofE8SXuENWOEm1bV4Kd IyQQK3Fy5072CYxSCxgZVjGKpJYW56anFhvpFSfmFpfmpesl5+duYgTG6Ol/xz/uYHx/wuoQ owAHoxIPb4DKs0gh1sSy4srcQ4wSHMxKIryxLs8jhXhTEiurUovy44tKc1KLDzFKc7AoifPa RrVFCgmkJ5akZqemFqQWwWSZODilGhhbHzoKvRfsu1yXF8o8b1rrs+4nE/OE1d8dvnokznf9 iYSzumesUgKs3y0SVZ+mXXq9Oqs05OqXiTN3Ni6K07T7W8eXyiu7c/YSBkUpVyfhd779G+1O lRaFXzmf9PBJ+reLIay7pXJmC6sZnn3D+iCHYUuFwXbvZo9PXyKn6y5aLXbp2CRDm6lKLMUZ iYZazEXFiQD9bUMkzQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42I5/e/4Vd0o3+eRBnePGFhsnLGe1WLqwyds FvOPnGO1+Halg8ni8q45bBYLXt5isVh75C67xdLrF5ksWvceYXfg9Fgzbw2jx85Zd9k9Nq3q ZPPo27KK0ePzJrkA1igum5TUnMyy1CJ9uwSujDnH+lgK+kUqNh5rYG5gbBToYuTkkBAwkXi9 +iMjhC0mceHeerYuRi4OIYEljBLnHrxiAkkICTQySUxY59vFyMHBJqAlsaY9HiQsImAj8fbG AUaQemaBBUwS077OYAZJCAMlHm/pYwexWQRUJSb+nQcW5xVwljh06Q0rxDI5iZvnOpknMHIv YGRYxSiSWlqcm55bbKhXnJhbXJqXrpecn7uJERg224793LyD8dLG4EOMAhyMSjy8ASrPIoVY E8uKK3MPMUpwMCuJ8Ma6PI8U4k1JrKxKLcqPLyrNSS0+xCjNwaIkztu7Z3WkkEB6Yklqdmpq QWoRTJaJg1OqgZE7kmtK6HGX63VtzGcZDrNP1L2ovNn4rsKxRY6z05NFXk52UdVSbc2bO7Nf WY/577P5MaVHt2Qs3WHjPVXClun+kZN7t/Moc00NFr9aMD1UwuPt769yDZsyN27hrLhvoO3z 2zi6ki+v6dKkjYpOXnIP6g++DN6X8HVihI7UFPWs5AfFy04UtSixFGckGmoxFxUnAgAyviLK FwIAAA== X-CMS-MailID: 20171018124722eucas1p23aa3280d33bfd38650783ac7f52b9909 X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 X-Local-Sender: =?UTF-8?B?TWFjaWVqIFB1cnNraRtTZWN1cml0eSAoVFApG1NhbXN1bmcg?= =?UTF-8?B?RWxlY3Ryb25pY3MbVHJhaW5lZSAoKQ==?= X-Global-Sender: =?UTF-8?B?TWFjaWVqIFB1cnNraRtTZWN1cml0eSAoVFApG1NhbXN1bmcg?= =?UTF-8?B?RWxlY3Ryb25pY3MbVHJhaW5lZSAoKQ==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTU=?= CMS-TYPE: 201P X-CMS-RootMailID: 20171018124722eucas1p23aa3280d33bfd38650783ac7f52b9909 X-RootMTR: 20171018124722eucas1p23aa3280d33bfd38650783ac7f52b9909 References: Sender: linux-kernel-owner@vger.kernel.org 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. Open question - which locking model should be used, because during balancing voltages we need to lock all coupled regulators and their parents. Unfortunately, some coupled regulators might have common parents. I can see three possibilities here: 1. (current implementation) Always lock all coupled regulators and additionally lock parents only for changing voltage of the individual regulator 2. Always lock all coupled regulators and their parents - to avoid deadlock on common parent, first enumerate locks, then sort them and remove double entries 3. Always lock all coupled regulators and their parents - to avoid deadlock on common parent, introduce so called reentrant locks (lock which might be taken multiple times by the same process). Best regards, Maciej Purski -- 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 (3): regulator: bindings: Add properties for coupled regulators regulator: core: Parse coupled regulators properties regulator: core: Balance coupled regulators voltages .../devicetree/bindings/regulator/regulator.txt | 4 + drivers/regulator/core.c | 487 ++++++++++++++++++++- include/linux/regulator/driver.h | 17 + 3 files changed, 492 insertions(+), 16 deletions(-) -- 2.7.4