From patchwork Sat Jul 16 10:31:45 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Xavier Drudis Ferran X-Patchwork-Id: 1657115 X-Patchwork-Delegate: ykai007@gmail.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=85.214.62.61; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4LlPg21TRpz9sB4 for ; Sat, 16 Jul 2022 20:32:12 +1000 (AEST) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3A5F481118; Sat, 16 Jul 2022 12:32:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tinet.cat Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 4199781118; Sat, 16 Jul 2022 12:32:02 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2 Received: from mx1.tinet.cat (mx1.dipta.cat [195.76.233.59]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 97EFF83FAD for ; Sat, 16 Jul 2022 12:31:58 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tinet.cat Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xdrudis@tinet.cat X-ASG-Debug-ID: 1657967516-12aaf258c3842180001-4l7tJC Received: from smtp01.tinet.cat (smtp01.tinet.org [195.77.216.131]) by mx1.tinet.cat with ESMTP id BzrnzaBGG8qRKy0g; Sat, 16 Jul 2022 12:31:56 +0200 (CEST) X-Barracuda-Envelope-From: xdrudis@tinet.cat X-Barracuda-Effective-Source-IP: smtp01.tinet.org[195.77.216.131] X-Barracuda-Apparent-Source-IP: 195.77.216.131 Received: from begut (99.red-79-152-185.dynamicip.rima-tde.net [79.152.185.99]) by smtp01.tinet.cat (Postfix) with ESMTPSA id 2E868605E0C3; Sat, 16 Jul 2022 12:31:56 +0200 (CEST) Date: Sat, 16 Jul 2022 12:31:45 +0200 From: Xavier Drudis Ferran To: u-boot@lists.denx.de Cc: Simon Glass , Philipp Tomsich , Kever Yang , Lukasz Majewski , Sean Anderson Subject: [PATCH] arm: rockchip: rk3399: Program PLL clock for DDR at 50 MHz in documented range Message-ID: <20220716103144.GA2167@begut> X-ASG-Orig-Subj: [PATCH] arm: rockchip: rk3399: Program PLL clock for DDR at 50 MHz in documented range MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Barracuda-Connect: smtp01.tinet.org[195.77.216.131] X-Barracuda-Start-Time: 1657967516 X-Barracuda-URL: https://webmail.tinet.cat:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 3516 X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: SPAM GLOBAL 1.0000 1.0000 4.3430 X-Barracuda-Spam-Score: 4.34 X-Barracuda-Spam-Status: No, SCORE=4.34 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=6.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.99415 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean The original code set up the DDR clock to 48 MHz, not 50MHz as requested, and did it in a way that didn't satisfy the Application Notes in RK3399 TRM [1]. 2.9.2.B says: PLL frequency range requirement [...] FOUTVCO: 800MHz to 3.2GHz 2.9.2.A : PLL output frequency configuration [...] FOUTVCO = FREF / REFDIV * FBDIV FOUTPOSTDIV = FOUTVCO / POSTDIV1 / POSTDIV2 FREF = 24 MHz The original code gives FOUTVCO: 24MHz/1 * 12 = 288MHz < 800MHz And the resulting FOUTPOSTDIV is 288MHz / 3 / 2 = 48MHz but the requested frequency was 50MHz Note: 2.7.2 Detail Register Description PMUCRU_PPLL_CON0 says fbdiv Feedback Divide Value Valid divider settings are: [16, 3200] in integer mode So .fbdiv = 12 wouldn't be right. But 2.9.2.C says: PLL setting consideration [...] The following settings are valid for FBDIV: DSMPD=1 (Integer Mode): 12,13,14,16-4095 (practical value is limited to 3200, 2400, or 1600 (FVCOMAX / FREFMIN)) [...] So .fbdiv = 12 would be right. In any case FOUTVCO is still wrong. I thank YouMin Chen for confirmation and explanation. Despite documentation, I don't seem to be able to reproduce a practical problem with the wrong FOUTVCO. When I initially found it I thought some problems with detecting the RAM capacity in my Rock Pi 4B could be related to it and my patch seemed to help. But since I'm no longer able to reproduce the issue, it works with or without this patch. And meanwhile a patch[2] by Lee Jones and YouMin Chen addresses this issue. Btw, shouldn't that be commited? So this patches solves no visible problem. Yet, to prevent future problems, I think it'd be best to stick to spec. An alternative to this patch could be {.refdiv = 1, .fbdiv = 75, .postdiv1 = 6, .postdiv2 = 6}; This would theoretically consume more power and yield less jitter, according to 2.9.2.C : PLL setting consideration [...] For lowest power operation, the minimum VCO and FREF frequencies should be used. For minimum jitter operation, the highest VCO and FREF frequencies should be used. [...] But I haven't tried it because I don't think it matters much. 50MHz for DDR is only shortly used by TPL at RAM init. Normal operation is at 800MHz. Maybe it's better to use less power until later when more complex software can control batteries or charging or whatever ? Cc: Simon Glass Cc: Philipp Tomsich Cc: Kever Yang Cc: Lukasz Majewski Cc: Sean Anderson Link: [1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.4%20Part1.pdf Link: [2] https://patchwork.ozlabs.org/project/uboot/list/?series=305766 Signed-off-by: Xavier Drudis Ferran Tested-by: Michal Suchánek Reviewed-by: Kever Yang --- drivers/clk/rockchip/clk_rk3399.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c index 7d31a9f22a..4762462b04 100644 --- a/drivers/clk/rockchip/clk_rk3399.c +++ b/drivers/clk/rockchip/clk_rk3399.c @@ -840,7 +840,7 @@ static ulong rk3399_ddr_set_clk(struct rockchip_cru *cru, switch (set_rate) { case 50 * MHz: dpll_cfg = (struct pll_div) - {.refdiv = 1, .fbdiv = 12, .postdiv1 = 3, .postdiv2 = 2}; + {.refdiv = 2, .fbdiv = 75, .postdiv1 = 3, .postdiv2 = 6}; break; case 200 * MHz: dpll_cfg = (struct pll_div)