From patchwork Thu Mar 21 20:19:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 10864277 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 50FF414DE for ; Thu, 21 Mar 2019 20:20:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2EEFF2A49B for ; Thu, 21 Mar 2019 20:20:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 233962A49D; Thu, 21 Mar 2019 20:20:29 +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=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 422FA2A49B for ; Thu, 21 Mar 2019 20:20:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=G/RCjEnxm8uT8+G5uEWqfSwrwgw44wciLBDSQgHfAGY=; b=FNvjApIDkkTaJm F0Thq61tOpc1L90UWcf/uMFm5RGVTNU75maXRs6gchxPpsRWVZ4q+tZVs/jEzAwS5hCTeo2mq1qRb BOdNDFG/NwzsEpL10OkkTC/0qf84pp52XWZs2gm7hX0sVmZGfWYuFuUHGkWn/fomeUebEgBOKfD+r c2+XwZAz/N6pOLos3lQ0znp9+z9xwF0KvsF1kcgT2PZ7MxMk09JySzsLIuWonlPkZyKPeVaUy4GpZ zoy1VquZ1lm2+uLD4+/c+cFHNvcTCIaMvxxLZhz3tcnnFVnLO1Hg/cCXBdZZLQ2XQPWxEGzOpoVf5 D/sY6lRJ4IvTafTwF5Mw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h74Ad-0001Gy-1K; Thu, 21 Mar 2019 20:20:11 +0000 Received: from mail-pf1-x442.google.com ([2607:f8b0:4864:20::442]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h74Aa-00013O-DE for linux-rockchip@lists.infradead.org; Thu, 21 Mar 2019 20:20:10 +0000 Received: by mail-pf1-x442.google.com with SMTP id i19so5037708pfd.0 for ; Thu, 21 Mar 2019 13:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=qcMYcR3yFN0QONzXnGiY4kl3TCzNnyKaWHKDD4RqjpE=; b=PYlkvF8j4FnA2lq3bYW3edA3pqzuFZU8QR20HY7GbE8aao+HDpaThF6MeSsPHr7vpz 3OPQM0nGIkicYG3BZd4Dc/EfL0SjAwOipXuHTOX2hALoxKPt8d5nu0sFSIxBPijOKyAf qyCR+IcB22V77WlAkG5+aN/4AKCdZJER3XK/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=qcMYcR3yFN0QONzXnGiY4kl3TCzNnyKaWHKDD4RqjpE=; b=L1lStBvb3MHz6eYX9hZ3klDJNJwOqUq9UWcoLA8cCo6m/U/4lzGYN/OVOEDaj4KkVl 95alveFQqc3vDXDaIQ42CWG598JQNjNit9KJf1lI37dlr6GcKnMBbXOM4x1xvrg6etY5 KYV2AOhg1OyruJrwMOHTbK/Ddf1YjHM47cbdiifGXM4Cdu24KqS+8nh9oJ0q3ysm02Xv KpmYDuzcJO9Y92YPIkjb6pIQ3odX/BeIGnvl++Nk3RzmWQQE/ok9G2RStjZdCTI0QGKT PanGDSd3QE75nhBckdVsXeNIav6ks/klgwWDzKSye5oFMdiCvPxxfftpd9bACeFagZaB XAfA== X-Gm-Message-State: APjAAAVfQ/CIXGYgHdXMuBOb0Z2Stte1qgk0k6blvfLXIFRTYW3p7Y84 DBd9Xx1EP99jqEwsv4/VIFYKiIy8NHc= X-Google-Smtp-Source: APXvYqzywrWVhwVbf2rF0upBRui/l9at63AH63pk55vq3yUJ5GgP1FRmIS3QB9tMWOnTtoqUho/glw== X-Received: by 2002:a17:902:b60c:: with SMTP id b12mr5371408pls.261.1553199607361; Thu, 21 Mar 2019 13:20:07 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id a7sm7252905pff.54.2019.03.21.13.20.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Mar 2019 13:20:06 -0700 (PDT) From: Douglas Anderson To: Heiko Stuebner Subject: [PATCH] ARM: dts: rockchip: Add vdd_logic to rk3288-veyron Date: Thu, 21 Mar 2019 13:19:44 -0700 Message-Id: <20190321201944.34684-1-dianders@chromium.org> X-Mailer: git-send-email 2.21.0.225.g810b269d1ac-goog MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190321_132008_480578_777D5E15 X-CRM114-Status: GOOD ( 18.86 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Douglas Anderson , Rob Herring , linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, mka@chromium.org, ryandcase@chromium.org, linux-arm-kernel@lists.infradead.org Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP The vdd_logic rail controls the voltage supplied to misc logic on rk3288, including the voltage supplied to the memory controller. The vcc logic is implemented by a PWM regulator. Right now there are no consumers of vdd_logic on veyron but if anyone ever wants to try to add DDR Freq they'd need it. Note that in the downstream Chrome OS kernel the PWM regulator has a voltage table with these points: 1350000 0% 1300000 10% 1250000 20% 1200000 31% 1150000 41% 1125000 46% 1100000 52% 1050000 62% 1000000 72% 950000 83% The DDR Freq driver in the downstream kernel only uses some of those points, namely: DDR3: 1200000, 1150000, 1100000, 1050000 LPDDR: 1150000, 1100000, 1050000 When adapting the downstream kernel to upstream I have opted to switch to using the "continuous" mode of the PWM regulator driver. This was the only way I could get the upstream driver to achieve _exactly_ the same voltages as the downstream driver could. Specifically note that the old driver in downstream Chrome OS 3.14 _didn't_ have the DIV_ROUND_CLOSEST_ULL() in the Rockchip PLL driver. That means if I use the same (downstream) table I might end up with a duty cycle that's 1 larger than was used downstream, leading to a slightly different voltage. Due to the way the rounding worked I couldn't even just adjust the "percent" by 1 for a given voltage level--certain duty cycles just aren't achievable with the upstream math for voltage tables. Using continuous mode you can achieve the exact same duty cycle by simply adjusting the voltage you use by a tad bit. The voltages that are equivalent to the ones used in the downstream kernel's table are: 1350000, 1304472, 1255691, 1200407, 1154878, 1128862, 1099593, 1050813, 1005285, 950000 Note that the top/bottom voltage is exactly the same just due to the way that continuous mode is calculated and the fact that I used those as anchors. I didn't make any attempt to do the resistor math (as was done on rk3399-gru). If anyone ever gets DDRFreq working on veyron upstream they should thus adjust the voltage specified in the DDRFreq operating points slightly (as per the above) to obtain the existing/tested values. AKA you'd use: DDR3: 1200407, 1154878, 1099593, 1050813 LPDDR: 1154878, 1099593, 1050813 A few other notes: - The "period" here (1994) is different than the "period" downstream (2000) for similar reasons: there's a DIV_ROUND_CLOSEST_ULL() that wasn't downstream. With 1994 upstream comes up with the same value (0x94) to program into the hardware that downstream put there. As far as I can tell 0x94 actually means 1993.27. - The duty cycle unit of 0x94 was picked by just matching the period which nicely allows us to insert 0x7b as that value to program into the hardware for 950mV. The 0x7b was found by observing what the downstream kernel calculated (not that the system can actually run with vdd_log at 950 mV). - The downstream kernel can also be seen to program a different value into the CTRL field. Upstream achieves 0x0b and downstream 0x1b. This is because the upstream commit bc834d7b07b4 ("pwm: rockchip: Move the configuration of polarity") fixed a bug by adding "ctrl &= ~PWM_POLARITY_MASK". Downstream accidentally left bit 4 set. Luckily this bit doesn't matter--it's only used when the PWM goes inactive (AKA if it's in oneshot mode or is disabled) and we don't do that for the PWM regulator. I measured the voltage of vdd_log while adjusting it and found that with the upstream kernel voltage difference between requested and actual was 9.2 mV at 950 mV and 13.4 mV at 1350 mV with in-between voltages consistently showing ~1% error. This error is likely expected as voltage can be seen to sag a bit when more load is put on the rail. Signed-off-by: Douglas Anderson --- arch/arm/boot/dts/rk3288-veyron.dtsi | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi index 0bc2409f6903..5181d9435fda 100644 --- a/arch/arm/boot/dts/rk3288-veyron.dtsi +++ b/arch/arm/boot/dts/rk3288-veyron.dtsi @@ -95,6 +95,23 @@ regulator-boot-on; vin-supply = <&vcc_5v>; }; + + vdd_logic: vdd-logic { + compatible = "pwm-regulator"; + regulator-name = "vdd_logic"; + + pwms = <&pwm1 0 1994 0>; + pwm-supply = <&vcc33_sys>; + + pwm-dutycycle-range = <0x7b 0>; + pwm-dutycycle-unit = <0x94>; + + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <4000>; + }; }; &cpu0 {