From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933422AbcFMDbE (ORCPT ); Sun, 12 Jun 2016 23:31:04 -0400 Received: from regular1.263xmail.com ([211.150.99.136]:53511 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933247AbcFMDbC (ORCPT ); Sun, 12 Jun 2016 23:31:02 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: zhengxing@rock-chips.com X-FST-TO: linux-kernel@vger.kernel.org X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: zhengxing@rock-chips.com X-UNIQUE-TAG: <082de6900179e641c61e01c20410be41> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399 To: Doug Anderson References: <1465724913-14553-1-git-send-email-zhengxing@rock-chips.com> <575E240C.9060502@rock-chips.com> Cc: =?UTF-8?Q?Heiko_St=c3=bcbner?= , elaine zhang , Tao Huang , Brian Norris , Yakir Yang , Michael Turquette , Stephen Boyd , linux-clk , "linux-arm-kernel@lists.infradead.org" , "open list:ARM/Rockchip SoC..." , "linux-kernel@vger.kernel.org" From: Xing Zheng Message-ID: <575E28CE.2020808@rock-chips.com> Date: Mon, 13 Jun 2016 11:30:22 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <575E240C.9060502@rock-chips.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Doug, On 2016年06月13日 11:10, Xing Zheng wrote: > Hi Doug, > > On 2016年06月13日 05:32, Doug Anderson wrote: >> Xing, >> >> On Sun, Jun 12, 2016 at 2:48 AM, Xing >> Zheng wrote: >>> The pclk_vio_grf supply power for GRF IOs, if it is disabled, will >>> cause abnormal operation of the GRF. >>> >>> The clock tree of the pclk_vio like this: >>> | --> pclk_vio_grf >>> ... pclk_vio | --> pclk_mipi_dsi1 >>> | --> pclk_mipi_dsi0 >>> >>> and the pclk_mipi_dsi0 and pclk_mipi_dsi1 don't have the flag >>> CLK_IGNORE_UNUSED, and they will be disabled by clk_disable_unused >>> when startup: >>> clk_disable_unused >>> --> clk_disable_unprepare >>> --> clk_disable >>> --> clk_core_disable(core->parent) >>> >>> then, the pclk_vio_grf also is disabled. Therefore, we need to add >>> pclk_vio_grf to critical clock and avoid to disable pclk_vio and >>> pclk_vio_grf. >>> >>> Tested-by: Yakir Yang >>> Signed-off-by: Yakir Yang >>> Signed-off-by: Brian Norris >>> Signed-off-by: Xing Zheng >>> --- >>> >>> drivers/clk/rockchip/clk-rk3399.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/clk/rockchip/clk-rk3399.c >>> b/drivers/clk/rockchip/clk-rk3399.c >>> index b6742fa..7ecb12c3 100644 >>> --- a/drivers/clk/rockchip/clk-rk3399.c >>> +++ b/drivers/clk/rockchip/clk-rk3399.c >>> @@ -1485,6 +1485,7 @@ static const char *const >>> rk3399_cru_critical_clocks[] __initconst = { >>> "gpll_hclk_perilp1_src", >>> "gpll_aclk_perilp0_src", >>> "gpll_aclk_perihp_src", >>> + "pclk_vio_grf", >> This clock is only needed when doing video output (like eDP), right? >> That means it is not really a critical clock. Critical clocks are >> supposed to be ones that are needed for the basic functioning of the >> system and that can never be turned off in any circumstances. In this >> case, if someone were running a rk3399 device and didn't have any >> video output they would want this clock off. >> >> Can you figure out in exactly which circumstances this clock needs to >> be on and then add a proper consumer of this clock? For instance, if >> this clock is needed whenever the VOP is outputting data, then the VOP >> should be a client and should turn this clock on and off when video is >> being output. If this clock is needed whenever you access VOP >> registers, then the VOP should be a client and turn this clock on >> around register accesses. >> >> Additional, we are discussing that we should turn the "pclk_vio" on and off in video drivers when the video consumer needs to this clock. Thanks. >> > Yes, the pclk_vio_grf is needed for doing video output. > andpclk_vio_grf supply for: grf_soc_con9, 20~26, grf_hdcp > > From our design folks, we have many GRF registers in different power > domains, > and these GRF gates should be always enabled. In this case, we can > avoid some > of the operations GRF registers exception problems, and it is only a > very small > increase in power consumption (aboult <=1ma). > > I will refer the latest TRM to update a new patch for always enable > these GRFs. > > Please drop this patch. -- - Xing Zheng