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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 0AEC1C433EF for ; Sun, 10 Jul 2022 18:48:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=R7P1eHbVv0wGVpCi1oJL7zj1su7UGlQs/B0Vf1iz9c0=; b=WTz4t0p6B9joee oFPNo1uh1LrKRC/HalluaOTXbHfxw82dwh9D/1vPobEr2QFxMLcliq3w1WHX8qfN773Otqb+aEHRZ LClBxeiZKRDgSxB8IVA7/XAVgvj2S3K1Hd579GkMSEqKh5/fuPUU3m4ZCMMR9u57TizekNO+EyTl5 RlCWu1Ktopz7BWZmuOt79NLe47Ok+i++ACzxyBVn2uSQKd50xn4OLcMxqJHiEHuVPCvskB/zRC7OU gYlWj19+aB6mv/tgei0ZNMp975puqYsamkYfYUbsP8K7+JucXHsYNEIBBCUMn1mr/zu5ygOIuETVR 3h+7XMJrXOLXvN9d9aSg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oAbyL-00D16k-NJ; Sun, 10 Jul 2022 18:48:01 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oAbyJ-00D15g-HS for linux-arm-kernel@lists.infradead.org; Sun, 10 Jul 2022 18:48:01 +0000 Received: by mail-ej1-x634.google.com with SMTP id va17so5536914ejb.0 for ; Sun, 10 Jul 2022 11:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=C80Ap1NXuZqTKIgCrLtABirop3OeeK3fdoI8KowoeOs=; b=ZOpQ1n0M0OnqaRpX8U1nIdAk1kQ66bjVUCEE2Y67Doa8nB74h809IMNYQDcsHN5JV5 W/kt/2kZZiQNxRMOyFZhQWnLBGkvw8nhao0WNJ4eyq+0vpsdnoEiKYhv7csabekLSo/N o80kR/iIVciGw8O03J7f2qEQPI8Qpsiq2LESCxNsxDtEoLQhLeInKqrXbOQAObyD1BUs 4LzvcMOvfApyyZiB3MVEf0gri17579oZtVWhhAsidaTONVEO0+9SshJo7Tc/HC13DYEO zVJ6Llo2C0o9HgEpHndudpMAFOBk1EgEK2edcQxFr8Z/83WcQDZbkGPCNbg045TwJx13 GudA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=C80Ap1NXuZqTKIgCrLtABirop3OeeK3fdoI8KowoeOs=; b=UkVvKSyNzJ5vZHbCrhU+7GdXTpjBgSAMyz/0PnjdBKmvUJNXa6OssHZakuetbNmZIB 5xOdTxnQdvq+tB3HLGdhpeWN9SffmAeE2LbJ19nLQ8gzG5RogckIg2Q/uOkNvVk8H+Nq LLAcE73zSD+2sATIQS1apWxgf7I9XZ1O8mLclSqdD4DhMCwDR4CKWEPJU2NO4EM561ka 3NgSdTCmsA3IOvsGkFqV2T1zsVzG6DPk+7pt1tlqwUJ6494NZz2oNP1iE5YrWhGmgE0f GKsiqYtvwbAewk8oGcAwLOiDf5Sg71kNmG+eT5tJp63RGqqd4CS47tig46yKdDyLLaJb 2AGQ== X-Gm-Message-State: AJIora+btxZK6/66Oz4O0mgQAkCz5lPzPOHCVyamuVs09IucP29VSqgl Otg8ENNMNpgCdqiyq+At/lk= X-Google-Smtp-Source: AGRyM1v8LP9i025JYfgRgPcAmlTD5Y+Rcjg0cRMXzHhXx90s+gyCRBFmmeu3UaNXQf9uAZpxRsVPOw== X-Received: by 2002:a17:906:6416:b0:722:e812:1000 with SMTP id d22-20020a170906641600b00722e8121000mr15282978ejm.275.1657478876956; Sun, 10 Jul 2022 11:47:56 -0700 (PDT) Received: from kista.localnet (213-161-3-76.dynamic.telemach.net. [213.161.3.76]) by smtp.gmail.com with ESMTPSA id x21-20020a170906149500b0072b2ef2757csm1780200ejc.180.2022.07.10.11.47.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Jul 2022 11:47:56 -0700 (PDT) From: Jernej =?utf-8?B?xaBrcmFiZWM=?= To: samuel@sholland.org, Roman Stratiienko Cc: mturquette@baylibre.com, sboyd@kernel.org, mripard@kernel.org, wens@csie.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Roman Stratiienko Subject: Re: [RFC] ccu-sun50i-h6: Bump-up DDR0 PLL to 1800MHz Date: Sun, 10 Jul 2022 20:47:55 +0200 Message-ID: <1917526.jZfb76A358@kista> In-Reply-To: <20220710175214.544748-1-r.stratiienko@gmail.com> References: <20220710175214.544748-1-r.stratiienko@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220710_114759_632621_75802BCC X-CRM114-Status: GOOD ( 24.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Roman, Dne nedelja, 10. julij 2022 ob 19:52:14 CEST je Roman Stratiienko napisal(a): > While debugging complex animated composition cases I noticed a glitch > which as it turned-out eventually was caused by lack of memory bandwidth. > > I can't find a DRAMC manual to check what input frequency must be > supplied to avoid exceeding the 800MHz LPDDR3 which is installed on > my orangepi3 board. But the system is running stable so far. this is hard topic. Generally, max. supported DRAM frequency is board specific and is set by SPL (part of U-Boot), so we can't assume every board supports max. frequency for its memory type. In fact, this assumption was proven wrong. Some boards were unstable until DRAM frequency was lowered. So in short, Linux clock driver certainly shouldn't set DRAM frequency. There is, however, Linux MBUS driver for H5 and A64, which can throttle DRAM frequency when system is idle, but max. frequency is still that one which was programmed by SPL. There is no definitive DRAM documentation, because Allwinner usually tries to hide all details. DRAM drivers are, except in rare cases, all reverse engineered by community. Register values (mostly) match those produced by vendor driver. Fortunately, at least H6 DRAM controller matches pretty good with one other memory controller (one in Zynq UltraScale+ MPSoC), which is fully documented (see comments in U-Boot driver). MBUS is also pretty standard and it's not a mystery. Note that it's hard to convince maintainers to either lower or increase DRAM frequency as it was common issue in the past. You have to do a lot of memory intensive tests, both CPU and GPU, running at the same time for extended period of time. Initial board bring ups usually just use same frequency as in BSP based images. If I understand procedure correctly, boards are sent to Allwinner, so their engineers determine max. DRAM frequency and timings, so these values are pretty trustwothy. There is other possibility. Along with DRAM controller and PHY, there is MBUS core, which is memory arbiter and responsible for bandwidth allocation. You can change DE priority and bandwith there (again, in U-Boot DRAM driver). I hope this explains why things are the way they are. Best regards, Jernej > > Signed-off-by: Roman Stratiienko > --- > drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c > b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c index 750368a86b8b6..abdde80307993 > 100644 > --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c > @@ -1203,6 +1203,17 @@ static int sun50i_h6_ccu_probe(struct platform_device > *pdev) val &= ~GENMASK(3, 0); > writel(val, reg + gpu_clk.common.reg); > > + /* > + * Increase DDR0 PLL from 1488(default) to 1800MHz. > + * (DE3.0 require higher memory bandwidth while displaying > + * complex composition at 1920x1080@60FPS) > + */ > + > + val = readl(reg + SUN50I_H6_PLL_DDR0_REG); > + val &= ~GENMASK(15, 0); > + val |= 74 << 8; > + writel(val, reg + SUN50I_H6_PLL_DDR0_REG); > + > /* Enable the lock bits on all PLLs */ > for (i = 0; i < ARRAY_SIZE(pll_regs); i++) { > val = readl(reg + pll_regs[i]); > -- > 2.34.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel