From patchwork Mon Nov 26 15:27:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Priit Laes X-Patchwork-Id: 10698537 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DFB9A18B8 for ; Mon, 26 Nov 2018 15:36:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CE4F429C92 for ; Mon, 26 Nov 2018 15:36:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C253D29F8B; Mon, 26 Nov 2018 15:36:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_ADSP_ALL, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6E23329E71 for ; Mon, 26 Nov 2018 15:36:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726475AbeK0CbA (ORCPT ); Mon, 26 Nov 2018 21:31:00 -0500 Received: from plaes.org ([188.166.43.21]:50290 "EHLO plaes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726340AbeK0CbA (ORCPT ); Mon, 26 Nov 2018 21:31:00 -0500 Received: from localhost (85.253.196.132.cable.starman.ee [85.253.196.132]) by plaes.org (Postfix) with ESMTPSA id 0970041C64; Mon, 26 Nov 2018 15:28:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=plaes.org; s=mail; t=1543246095; bh=OUsll2pSZ+358NKNJxIvPOwFWCiSRmYw6WUlwJb5uoA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JUDeyeuPsJnifS/ateXI/uKf1+1hYIbC0VJnuf3ZPEugPFWQnUWo8XjIZ6vtuFesx XCSi6aN/qT4sQgUYGvLOcegxNnUELpkGUueu5XsqBd0MxG2xa+7LdwUMIrjL3Lj/hD duviv/2m4PHcT2pGDinQPj5Hmn7KD7mtet98ulCJ+P1YqziPO4I1hb8m66cjUv29dd +aWnYu2ygMNB11PARsm2U940A1Mf6Wm9MuKxB1Wirb/XCcDQv/iwSJewy0wYN6ubbR UbP98T9yFjdJKqRZiCkADXfEeXp0FxDtZnFMJ7KzHJqng14VGvLQXubM0y3vQqSSXJ 7VUeFl7KqW1tw== From: Priit Laes To: Lee Jones , Rob Herring , Mark Rutland , Chen-Yu Tsai , Maxime Ripard , Sebastian Reichel , Hans de Goede , Liam Girdwood , Mark Brown , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org Cc: Priit Laes , Olliver Schinagl Subject: [PATCH 09/14] regulator: dts: add full voltage range to LDO4 on the Lime2 Date: Mon, 26 Nov 2018 17:27:50 +0200 Message-Id: <0b1aa5b28cb5efe17c04150a181ef1fa4027bc55.1543245984.git-series.plaes@plaes.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: References: MIME-Version: 1.0 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Olliver Schinagl With commit b43776d65a33b46092 ("ARM: dts: sunxi: Use axp209.dtsi for Olinuxino Lime2") we force them an arbitrary 2.8 volts. Granted, for LDO3 this may be less arbitrary, but for LDO4 this is just wrong. In the defense of LDO3, LDO3 is the regulator that feeds port bank E, which has no other purpose then a CSI/TS interface, however the case may still be, that the connected IO may be just as well be 3.3 volts. The big misnomer is however, that the schematic names GPIO-2 pin4 LDO3_2.8V, rather then VDD-CSI0 or similar. This is much worse for LDO4 however, which is not referenced on any pin, is now set to 2.8 volts, but port bank G can also support various other peripherals such as UARTS etc. By having 2.8 volts however for LDO4, we thus now have peripherals that no longer function properly all of the time. Ideally, we want to set a supply voltage for each port bank, but the monolithic nature of the sunxi pinctroller currently prevents this and as such, the board should at least configure the LDO4 with the proper ranges. Until we can set the consumer at the port bank level, a child device-tree has to do something like: ®_ldo4 { regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; }; While doing this the same way results in the same solution currently, we force the hack into the final devicetree rather then having it wrong at the board level. Signed-off-by: Olliver Schinagl Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts index ffafe97..1b9867f 100644 --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts @@ -250,9 +250,10 @@ }; ®_ldo4 { - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - regulator-name = "vddio-csi1"; + regulator-always-on; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vdd-io-pg"; }; ®_usb0_vbus {