From patchwork Mon Jun 13 20:43:42 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 9174275 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2D82960573 for ; Mon, 13 Jun 2016 20:44:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1E265262AE for ; Mon, 13 Jun 2016 20:44:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 124B0265F9; Mon, 13 Jun 2016 20:44:10 +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=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 99014262AE for ; Mon, 13 Jun 2016 20:44:09 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1bCYiM-0007ZR-Pb; Mon, 13 Jun 2016 20:44:06 +0000 Received: from mail-vk0-x234.google.com ([2607:f8b0:400c:c05::234]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1bCYiK-0007XB-Vq for linux-rockchip@lists.infradead.org; Mon, 13 Jun 2016 20:44:05 +0000 Received: by mail-vk0-x234.google.com with SMTP id j2so18715681vkg.2 for ; Mon, 13 Jun 2016 13:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jXFZ0CMw0rhJUuB+HrHqvoYAmkPi9LT6S6TFskU+yEg=; b=NbgoKEYyVgdHDiS9gIcFD0W1uu8KllcYkfYyBpNVLTfqMzR4Y+iHg2jsCRH1q7xF37 yRJIEjDGMMO7ux30hmBxt5p1vFSIUc5lcTvcQPSJwdq9NOv4yHYJxCuUKK0WMgBZ9bx9 m4TXZhuwl7i/LLCH1TATRMNkAn7xvgsM8xigB9bSJ9BwVs5vHFUR2iW20cJHjX8vgivF 2Wq3lITMJv3ZpXCYztMzHYb/OQQlF+9trJEGN4UsSzKapQMMrrQDjD6Pg3BICh+rh+D3 QIk0jRhKaV+32Dc8A6c4ZT3DKx8fgHfjVBR/EScMwGUCIFj4lH5m1d69VpMTiKcINb4n zkGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jXFZ0CMw0rhJUuB+HrHqvoYAmkPi9LT6S6TFskU+yEg=; b=csG4NiOCKGOq/nbeEe01AWpC4fZyY/rKb2kzbF+J94FpgquohcblsGgagqu5ADTboK mEJYc/VjpigsLFmGUozlSYjrxS4pduSxa5Jq6u2Z+SJbne5u9URXeVeJH6EOnjCVdqdc 9onex+UdOTMy1KNn9moKh4eBMWGItkJ41t6Sw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jXFZ0CMw0rhJUuB+HrHqvoYAmkPi9LT6S6TFskU+yEg=; b=ichNxSnnH1K6ChWKpbxmFnOvxiE/GJXsKwHkNR+2Zwdsmt9zPClDjwGXTpR9msInQ+ 2nsWpNp94sWTUoginVtMOLy7gNjoSryLlqAVUvaWFoD1HoLBMoEz7Y0vd0i2O5RtoiCo anwzeCoyshPOP2Y6Rm7TEdR1moIIC8QHuZEtuvEdRDI/UFeXFIJ0XFuogJMCFb35h/JO QSgSVTPC7aEMjUZCN5pPY90p5/vvpVek/++eGWboggjhyudkblXXI/Mv1S8NQ+lmwHV/ 3K3O0O3MzZ96hOq4DqtmWyRzD6WIa/RR2+u9NhInWvS+0VKz5hTB2fZwzlpOEYgVwMLn 5pDA== X-Gm-Message-State: ALyK8tJ/PyObf8fdBz/IXPqRzfPhOCxCf98njFOkIPLHIHm5i189Xsr/QVNUyEOj7uv0lUNMCAdOc3+VLtgdnVza X-Received: by 10.31.94.82 with SMTP id s79mr6800935vkb.149.1465850623598; Mon, 13 Jun 2016 13:43:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.150.65 with HTTP; Mon, 13 Jun 2016 13:43:42 -0700 (PDT) In-Reply-To: <20160613183748.GA21936@google.com> References: <1465724928-14611-1-git-send-email-zhengxing@rock-chips.com> <575D3D9B.1070501@rock-chips.com> <20160613183748.GA21936@google.com> From: Doug Anderson Date: Mon, 13 Jun 2016 13:43:42 -0700 X-Google-Sender-Auth: qvr4jhu9Mm1D1VliWlbQPRGDSMg Message-ID: Subject: Re: [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399 To: Brian Norris X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160613_134405_115775_7B1B1BE6 X-CRM114-Status: GOOD ( 22.49 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tao Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Xing Zheng , Tomeu Vizoso , Dominik Behr , Michael Turquette , Stephen Boyd , "linux-kernel@vger.kernel.org" , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Tomasz Figa , "open list:ARM/Rockchip SoC..." , Yakir Yang , Chris , elaine zhang , linux-clk , "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 Hi, On Mon, Jun 13, 2016 at 11:37 AM, Brian Norris wrote: > Hi, > > On Sun, Jun 12, 2016 at 06:46:51PM +0800, Yakir Yang wrote: >> On 06/12/2016 05:48 PM, Xing Zheng wrote: >> >The functions and features VOP0 more complete than VOP1's, we need to >> >use it dclk_vop0_div operate VPLLI, and let VOP0 as the default primary >> >screen. > > Personally, I'd like a little better description that talks about the > rates, not just the differences between VOP0 and VOP1. Presumably the > clock rates needed by VOP0 are not achievable just by these dividers, so > we need to adjust the PLL? The idea is that there is a "big" VOP (vop0) and a "little" VOP (vop1). The "big" VOP can support higher resolutions and more output formats but draws a little more power. The "little" VOP supports lower resolutions and a more limited set of formats. If you're curious, chapter 1 of the rk3399 TRM has a summary of the VOP features (big and little). In general, I think the SoC allows dynamic assignment of the VOPs to the various video devices (eDP, DP, MIPI, HDMI). So you can output to two places at once and you get to pick whichever VOP you want for each output. The VOPs have three PLL sources: VPLL, CPLL, and GPLL. Those PLLs are best described as: * CPLL - The PLL that runs at 800MHz. * GPLL - The PLL that runs at ~600MHz (actually 594 MHz). * VPLL - The PLL that can change rates to make various pixels clocks. Presumably: * The little VOP has enough features that you'd want to use it for most internal laptop / cellphone / tablet panels. * The big VOP is a good choice for whatever external graphics connector you have so you can support the widest range of devices. So if you've got a laptop that happens to have an internal panel and an external connector, presumably: * You want to adjust your display timings (hblank, vblank, etc) to make sure that the internal display can be driven by dividing 800 MHz or 594 MHz by some integral amount. As an example, for the Starry panel I posted recently you could make exactly 148.5 (594 / 4) by subtracting 4 from the horizontal total and adding 15 to the vertical: 1250 * 1980 * 60 Hz = 148.5 MHz * You want to make sure that the internal display gets assigned the little VOP so save power / leave flexibility for the external connector. * You want to make sure that that the little VOP _doesn't_ accidentally get assigned VPLL even if (at boot) VPLL happens to be at a rate that would be fine for the panel. If you accidentally use VPLL as a parent then you'll have a tougher time changing VPLL later when an external display is plugged in. NOTE: If you have things other than a laptop the decisions between VOP0 and VOP1 get much tougher. > FWIW, I haven't actually found this patch necessary in my own testing (I > have eDP running fine without this change), but perhaps with better > justification, this will make more sense. It is probable that firmware has already set the PLL up. It would be interested to hack your firmware to turn off the display and see if your behavior changes. Alternatively, try adding something like this to hack the VOPs: NOTE also: it seems terribly unlikely that adding CLK_SET_RATE_PARENT to "vop0" would help with eDP, which really ought to be using vop1, right? In testing on my board, I found that eDP is in fact using vop1 with my current patch stack. --- To summarize all that, I think that the following things would work OK for a laptop until a better solution comes along: * Probably VOP0 and VOP1 should both be able to change their parent's rate. * Somehow adjust the panel rate to one that could be produced by CPLL / GPLL. Presumably we'd want some code to add these extra modes to simple-panel (?) and some code to know which mode to pick (?). * make sure VOP0 is assigned to the panel (make this already is forced somehow?) * make sure VOP0 starts out with the right parent (CPLL / GPLL) using assigned-clocks in the device tree, so CCF will leave things alone. Anyway, maybe everything I said is wrong. If so, please correct. ;) -Doug --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -816,7 +816,7 @@ <&cru ACLK_VOP1>, <&cru HCLK_VOP1>, <&cru ARMCLKL>, <&cru ARMCLKB>, <&cru PLL_GPLL>, <&cru PLL_CPLL>, - <&cru PLL_NPLL>, + <&cru PLL_NPLL>, <&cru PLL_VPLL>, <&cru ACLK_PERIHP>, <&cru HCLK_PERIHP>, <&cru PCLK_PERIHP>, <&cru ACLK_PERILP0>, <&cru HCLK_PERILP0>, @@ -827,7 +827,7 @@ <400000000>, <200000000>, <816000000>, <1008000000>, <594000000>, <800000000>, - <1000000000>, + <1000000000>, <900000000>, <150000000>, <75000000>, <37500000>, <100000000>, <100000000>,