From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBD62C43381 for ; Mon, 25 Mar 2019 12:30:44 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9BE0E2085A for ; Mon, 25 Mar 2019 12:30:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="t7Nrjv5v" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BE0E2085A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sntech.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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:References:In-Reply-To: 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: List-Owner; bh=9rEi82P+gGl9Y2oKAkc1hnlnFQ4/HB7fJ5QCXPL4rzU=; b=t7Nrjv5vW9rtHJ y3haLXkB0N6IW6X3qjerB4rhPeycfgxB0PkEJYn5Uz61WE/QvnarMoXa9cuwotf1MUsbRqrmzP9mF 2Cr2u3y8hf6t2FRFV1nvEPkRjNKxehLEBMteWQj1wkM/bMtRPxlrnYT2s4s4ZyyYWeXe4c167oBZJ hwQ3xpCg9IZhzcTFXKF9XjlTDk1D2HuuCmnKDkvgZCCAwRrHly3E1ILMkxnLPDc5rIPzRambjf/23 Va+eC05jqMSk78tsH7OS0SDvAhyRR8OiWR51X89zf2LaIXPdATm1+cxEUtdehReHDulHLTEPTqysi J5iLu3MurvVr6TSocLZQ==; 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 1h8OkL-0006lr-Oy; Mon, 25 Mar 2019 12:30:33 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h8OkB-0006dL-VN; Mon, 25 Mar 2019 12:30:30 +0000 Received: from [94.134.91.136] (helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1h8Ok5-0006n3-0v; Mon, 25 Mar 2019 13:30:17 +0100 From: Heiko Stuebner To: Douglas Anderson Subject: Re: [PATCH] ARM: dts: rockchip: Add vdd_logic to rk3288-veyron Date: Mon, 25 Mar 2019 13:30:16 +0100 Message-ID: <4531156.B27Co0TEWW@phil> In-Reply-To: <20190321201944.34684-1-dianders@chromium.org> References: <20190321201944.34684-1-dianders@chromium.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190325_053024_370371_445B42C1 X-CRM114-Status: GOOD ( 23.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , linux-rockchip@lists.infradead.org, mka@chromium.org, ryandcase@chromium.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Donnerstag, 21. M=E4rz 2019, 21:19:44 CET schrieb Douglas Anderson: > 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 &=3D > ~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 applied for 5.2 Thanks Heiko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel