Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4555623ybv; Mon, 10 Feb 2020 22:24:43 -0800 (PST) X-Google-Smtp-Source: APXvYqzEmK11+scysM0b9xZD4npGDZSO6ugix690ZNYzBKFmjkAj4abVELJeBTH6IrHeYuX1A9Tm X-Received: by 2002:a9d:7357:: with SMTP id l23mr3886382otk.10.1581402283440; Mon, 10 Feb 2020 22:24:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581402283; cv=none; d=google.com; s=arc-20160816; b=P4vWSYjdq/DN2OfBZV5vB9pghbtA3yItYIH21w3b9vtInjJhUkIzPdxp7m0dvmDZDQ 9xhnYmSj6Fwh77qVnX0JbAQVFDXiyw8dPdoCS2C5aZaX30Ls2Q2+/jpPu6GZXJxRxgs7 g5vlDYZhRbsHP9SQZ1A+UVNw5/nAq1v84gKsBIA9wasZ+Qr8lMpoxmtYTMVdOl8ZzvtD 5mvhjrT97PMTgvRw6OXTjJTrFXgb1sGMY2tbB83ivS/ruRTHwB/W6DYK7OOm+Snx0Y7h O0AvXl0N04MYvduD1ti9QiYHgQoeaPKqlTRh0r9lDdgKJlLcWOTHdIeCO1v9XwIyDxfb sIxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=90LwSLciKSX0tDR6UyVjm6zI/ZPE7pQez+xZZMUCPQw=; b=yFQuDZ6AUOThKayzsRqR5DZuUPCRzsQG793rPNU3XQPckxRXerewpWeoI6unTJ1ny2 r6+c/fl+IqH3RMojE2pE4Vob4qLCZP8VF0uL+OnfSBxzTsUjYe7Gw2sBZHtxqd32zdbQ 1qQ2h3o+DVUXrtSxTX/+r/c3xZHOSUlr6UhRF9/wa1Kopo/93FeULqPCskU/td5ppg33 bJtdJdpcVHbT5mny7HTj7/OS+yD1Ac4FIhe/zM+iML7ANn5lNgC0z1uX0HMuw4fNVqUE X9Qy5XSySYPK4EEuYiPw1e9pZL9ycm11UYb0TiE67Fw6lXWShEClKXb15ATt8W4KbuBb 0LXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=qGpCAFOU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i7si1230325oib.63.2020.02.10.22.24.31; Mon, 10 Feb 2020 22:24:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=qGpCAFOU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728284AbgBKF6O (ORCPT + 99 others); Tue, 11 Feb 2020 00:58:14 -0500 Received: from mail26.static.mailgun.info ([104.130.122.26]:58632 "EHLO mail26.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728023AbgBKF6O (ORCPT ); Tue, 11 Feb 2020 00:58:14 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1581400694; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=90LwSLciKSX0tDR6UyVjm6zI/ZPE7pQez+xZZMUCPQw=; b=qGpCAFOU5jUGdYrkhnmSTMpNeYpeA72Txvhez9IU2/1yqzlQGYwx8i6MAKgdz7xpjeUwF6nP +CqoAaF2tUJgLlTn82RqJET6g+bjiWAkKsRzza47iO07KyxgbiEGokRfQG/BHN9tOIa2/B1v iiEPrJ4UNufgORthA4Tvb98G9nA= X-Mailgun-Sending-Ip: 104.130.122.26 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5e424275.7faea0ea1030-smtp-out-n01; Tue, 11 Feb 2020 05:58:13 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id E05DCC4479C; Tue, 11 Feb 2020 05:58:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: harigovi) by smtp.codeaurora.org (Postfix) with ESMTPSA id 29BE2C43383; Tue, 11 Feb 2020 05:58:12 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 11 Feb 2020 11:28:12 +0530 From: harigovi@codeaurora.org To: Jeffrey Hugo Cc: "open list:DRM PANEL DRIVERS" , MSM , freedreno , DTML , lkml , Rob Clark , nganji@codeaurora.org, Sean Paul , kalyan_t@codeaurora.org, "Kristian H. Kristensen" Subject: Re: [Freedreno] [v1] drm/msm/dsi/pll: call vco set rate explicitly In-Reply-To: References: <1580980321-19256-1-git-send-email-harigovi@codeaurora.org> <2f5abc857910f70faa119fea5bda81d7@codeaurora.org> Message-ID: <1d201377996e16ce25acb640867e1214@codeaurora.org> X-Sender: harigovi@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-02-07 19:40, Jeffrey Hugo wrote: > On Fri, Feb 7, 2020 at 5:38 AM wrote: >> >> On 2020-02-06 20:29, Jeffrey Hugo wrote: >> > On Thu, Feb 6, 2020 at 2:13 AM Harigovindan P >> > wrote: >> >> >> >> For a given byte clock, if VCO recalc value is exactly same as >> >> vco set rate value, vco_set_rate does not get called assuming >> >> VCO is already set to required value. But Due to GDSC toggle, >> >> VCO values are erased in the HW. To make sure VCO is programmed >> >> correctly, we forcefully call set_rate from vco_prepare. >> > >> > Is this specific to certain SoCs? I don't think I've observed this. >> >> As far as Qualcomm SOCs are concerned, since pll is analog and the >> value >> is directly read from hardware if we get recalc value same as set rate >> value, the vco_set_rate will not be invoked. We checked in our idp >> device which has the same SOC but it works there since the rates are >> different. > > This doesn't seem to be an answer to my question. What Qualcomm SoCs > does this issue apply to? Everything implementing the 10nm pll? One > specific SoC? I don't believe I've seen this on MSM8998, nor SDM845, > so I'm interested to know what is the actual impact here. I don't see > an "IDP" SoC in the IP catalog, so I really have no idea what you are > referring to. This is not 10nm specific. It is applicable for other nms also. Its specific to the frequency being set. If vco_recalc returns the same value as being set by vco_set_rate, vco_set_rate will not be invoked second time onwards. For example: Lets take below devices: Cheza is based on SDM845 which is 10nm only. Clk frequency:206016 dsi_pll_10nm_vco_set_rate - DSI PLL0 rate=1236096000 dsi_pll_10nm_vco_recalc_rate - DSI PLL0 returning vco rate = 1236095947 Trogdor is based on sc7180 which is also 10nm. Clk frequency:69300 dsi_pll_10nm_vco_set_rate - DSI PLL0 rate=1663200000 dsi_pll_10nm_vco_recalc_rate - DSI PLL0 returning vco rate = 1663200000 In same trogdor device, we slightly changed the clock frequency and the values actually differ which will not cause any issue. Clk frequency:69310 dsi_pll_10nm_vco_set_rate - DSI PLL0 rate=1663440000 dsi_pll_10nm_vco_recalc_rate - DSI PLL0 returning vco rate = 1663439941