Received: by 10.223.176.46 with SMTP id f43csp2972896wra; Mon, 22 Jan 2018 06:31:08 -0800 (PST) X-Google-Smtp-Source: AH8x226Gw94IvDU3hop3TCtZ8Z1FnX7yAGTaBmu8S+Q1r3rQ8rpbqWjv9VmMrG5uRetGkL+X4BRw X-Received: by 10.98.31.72 with SMTP id f69mr8631379pff.196.1516631467978; Mon, 22 Jan 2018 06:31:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516631467; cv=none; d=google.com; s=arc-20160816; b=dNPoZL3EPGoaFQoqaUXNU640nwkhebeKaXyu2DlOEyYz5Y+HUTzthrJvUUoZDrNUwS CtTot7a9/1YjBxbDnzYyjFqDka3jQPluYDVAZckWAVf5N5DM2Rqcm+QCeezOFfgkvOmL FWaYxGnTX95WTX1sxwVswcp8KvJ/oRPxud1BbEWuoKWNFRg2KYVPVN0jNQEEruFISrBy CgZL1JDGndoeSC66dEYhUA003isvL6Tm/T05ui3zhUd7pNzJTN3rhNaKG/SRHYWrc9Tg yoBu0VtTnexZ/rh6XLdogAm+BmoX0ksPLaP365W8X8MPUuVFA4oW87Ztz9q0JrmDM/Uq l0bQ== 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=PGs7MmCalnK+QMCnZioEHyPOx3EQwuYPtwDOJ52H2PM=; b=WrmUW0m+lV+yUUkCIAEOxnk8G4uUYs4Y7vXZqV5skAeYTEY4qZPbx4iYNwyxH6Fax9 bzIjHt18TtyRiWpy6CMwNv4fhC0Shp5cPCHhMRFWy+cGdwDwSU5y1gxKbColOO0KTKxy kTbIqzJoCtJLXkkAqcNaWoyogDaxmAmjCaDQ54qVCuKEoi92U1WLQyqBtIot1M0Z5wrJ 8gmLN72kW4xWeewdSZ04uVQy8PsSTuO81c5cjZrLxqNJuyGRsGT/Kl+b/LVnSFDZ8+f6 P1e2F/yVRg6vweKTQIgTVZsmDmp8e+JpcryrJGaSvwC/IPng6DSUHghK80fLmRwjI0fB eV2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b=Vgki6aLG; 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 q74si273674pfk.164.2018.01.22.06.30.53; Mon, 22 Jan 2018 06:31:07 -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=Vgki6aLG; 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 S1751147AbeAVOaZ (ORCPT + 99 others); Mon, 22 Jan 2018 09:30:25 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:48085 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070AbeAVOaX (ORCPT ); Mon, 22 Jan 2018 09:30:23 -0500 Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20180122143020euoutp01ebd5bc98cdea19be84e685f972c700bd~MKD3px3572739227392euoutp01C; Mon, 22 Jan 2018 14:30:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20180122143020euoutp01ebd5bc98cdea19be84e685f972c700bd~MKD3px3572739227392euoutp01C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1516631420; bh=PGs7MmCalnK+QMCnZioEHyPOx3EQwuYPtwDOJ52H2PM=; h=From:To:Cc:Subject:Date:References:From; b=Vgki6aLGZNBpaPYxpUQUHk83EJHwXgyp8ZpmbNBVAZkmbZ+MnH8mb2Z05XdBFf3QF EJgMLFgDggmQDeQp1J6JzGIGn0JRq0uyuftaXbNlEqLatkB2ms+LpghqAXB9YB7xWV /u7rbDns0dwDUfIMj2v7rf6r78O97+xPkVGnBKNs= Received: from eusmges4.samsung.com (unknown [203.254.199.244]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20180122143020eucas1p210286efc6be40769639afedd509f42fe~MKD2295a72118021180eucas1p2X; Mon, 22 Jan 2018 14:30:20 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges4.samsung.com (EUCPMTA) with SMTP id 71.F3.30163.B75F56A5; Mon, 22 Jan 2018 14:30:19 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20180122143019eucas1p213b852c98cde3fb8a77b96ab0d372ee6~MKD2OrP722118721187eucas1p2Z; Mon, 22 Jan 2018 14:30:19 +0000 (GMT) X-AuditID: cbfec7f4-f790c6d0000075d3-fc-5a65f57b72de Received: from eusync4.samsung.com ( [203.254.199.214]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id B5.9A.18832.B75F56A5; Mon, 22 Jan 2018 14:30:19 +0000 (GMT) Received: from AMDC2075.DIGITAL.local ([106.120.51.25]) by eusync4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0P2Y0079BOAEJF00@eusync4.samsung.com>; Mon, 22 Jan 2018 14:30:19 +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 v4 0/7] Add coupled regulators mechanism Date: Mon, 22 Jan 2018 15:30:05 +0100 Message-id: <1516631412-17542-1-git-send-email-m.purski@samsung.com> X-Mailer: git-send-email 2.7.4 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsWy7djP87rVX1OjDHou6llsnLGe1WLqwyds FvOPnGO1OLvsIJvFtysdTBaXd81hs1jw8haLxdojd9ktll6/yGTRuvcIuwOXx5p5axg9Zjdc ZPHYOesuu8emVZ1sHn1bVjF6fN4kF8AWxWWTkpqTWZZapG+XwJUx5fFzloLZUhUXNrSzNzBe FOli5OSQEDCRuP7rNhuELSZx4d56IJuLQ0hgKaPE6yc72CGcz4wSV2/2sMB0XFtyiRkisYxR Yvb2PlYI5z+jxOq+9UxdjBwcbAJaEmva40EaRARsJN7eOMAIUsMscJxJ4vrUjUwgCWEBC4kf W58ygtgsAqoSV58sB7uDV8BF4tvaFYwQ2+Qkbp7rBNsmITCDTWL1qdWsEAkXicbVh9khbGGJ V8e3QNkyEp0dB5kg7GqJi193QT1XI9F4ewNUjbXE50lbmEFsZgE+iUnbpjODHC0hwCvR0SYE UeIh8XTfXHaIsKNE4zJ5kLCQQKzEtCt7mSYwSi1gZFjFKJJaWpybnlpsolecmFtcmpeul5yf u4kRGLen/x3/soNx8TGrQ4wCHIxKPLwdBqlRQqyJZcWVuYcYJTiYlUR401YAhXhTEiurUovy 44tKc1KLDzFKc7AoifPaRrVFCgmkJ5akZqemFqQWwWSZODilGhjX/T3yduL67x1uxWYllQ8m +J4v3zTp3UMdx1muhS4PNxe7x13VdX2/YLp8UCbLRudtcXIajHeLQrOXPteMS5NxXrE6quBJ mm2eCdfeVFaLH8YdOcxC7VN6/xwRurxBpzhRvJLF56Cs6q5Xj7506i608zn9jW9zpi5XFyP3 kjcPX6S8lsw8ya7EUpyRaKjFXFScCAB6Tufj1wIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42I5/e/4Nd3qr6lRBs96BC02zljPajH14RM2 i/lHzrFanF12kM3i25UOJovLu+awWSx4eYvFYu2Ru+wWS69fZLJo3XuE3YHLY828NYwesxsu snjsnHWX3WPTqk42j74tqxg9Pm+SC2CL4rJJSc3JLEst0rdL4MqY8vg5S8FsqYoLG9rZGxgv inQxcnJICJhIXFtyiRnCFpO4cG89WxcjF4eQwBJGiUPPGqGcRiaJpx8fMXUxcnCwCWhJrGmP B2kQEbCReHvjACNIDbPASSaJPxfXMYIkhAUsJH5sfQpmswioSlx9spwNxOYVcJH4tnYFI8Q2 OYmb5zqZJzByL2BkWMUoklpanJueW2yoV5yYW1yal66XnJ+7iREYTNuO/dy8g/HSxuBDjAIc jEo8vB0GqVFCrIllxZW5hxglOJiVRHjTVgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/buWR0p JJCeWJKanZpakFoEk2Xi4JRqYPR8lTB977bF99PbLrBkfJ667APfieqUA4W/6peKLlmz57KZ J+/BxV5tPbfP/FBTW7Xyj7wPz6enss0aXfOibUqvdj/Kajpg9SN22QO7M1aCCy0Muv9ZGlkK ND05WZRkpKY2XeR3ZMXRf8/3CE7VKj5lyr//yodTc22WSyzTEjhwRSPvVsT0qm4lluKMREMt 5qLiRADZ1nY+IgIAAA== X-CMS-MailID: 20180122143019eucas1p213b852c98cde3fb8a77b96ab0d372ee6 X-Msg-Generator: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180122143019eucas1p213b852c98cde3fb8a77b96ab0d372ee6 X-RootMTR: 20180122143019eucas1p213b852c98cde3fb8a77b96ab0d372ee6 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 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 (7): regulator: core: Move of_find_regulator_by_node() to of_regulator.c regulator: core: Refactor regulator_list_voltage() 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 | 416 ++++++++++++++++++--- drivers/regulator/internal.h | 15 + drivers/regulator/of_regulator.c | 163 ++++++++ include/linux/regulator/driver.h | 18 + include/linux/regulator/machine.h | 4 + 6 files changed, 575 insertions(+), 46 deletions(-) -- 2.7.4