From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756208AbbGUWnf (ORCPT ); Tue, 21 Jul 2015 18:43:35 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:39558 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755659AbbGUWnd (ORCPT ); Tue, 21 Jul 2015 18:43:33 -0400 Message-ID: <55AECB0F.3090701@codeaurora.org> Date: Tue, 21 Jul 2015 15:43:27 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Doug Anderson CC: Heiko Stuebner , "open list:ARM/Rockchip SoC..." , Yakir Yang , Alexandru Stan , mturquette@baylibre.com, linux-clk@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] clk: rockchip: Fix PLL bandwidth References: <1437511283-14216-1-git-send-email-dianders@chromium.org> <55AEB6AE.2070006@codeaurora.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/21/2015 03:37 PM, Doug Anderson wrote: > Stephen, > > On Tue, Jul 21, 2015 at 2:16 PM, Stephen Boyd wrote: >> On 07/21/2015 01:41 PM, Douglas Anderson wrote: >>> In the TRM we see that BWADJ is "a 12-bit bus that selects the values >>> 1-4096 for the bandwidth divider (NB)": >>> NB = BWADJ[11:0] + 1 >>> The recommended setting of NB: NB = NF / 2. >>> >>> So: >>> NB = NF / 2 >>> BWADJ[11:0] + 1 = NF / 2 >>> BWADJ[11:0] = NF / 2 - 1 >>> >>> Right now, we have: >>> >>> { \ >>> .rate = _rate##U, \ >>> .nr = _nr, \ >>> .nf = _nf, \ >>> .no = _no, \ >>> .bwadj = (_nf >> 1), \ >>> } >>> >>> That means we set bwadj to NF / 2, not NF / 2 - 1 >>> >>> All of this is a bit confusing because we specify "NR" (the 1-based >>> value), "NF" (the 1-based value), "NO" (the 1-based value), but >>> "BWADJ" (the 0-based value) instead of "NB" (the 1-based value). >>> >>> Let's change to working with "NB" and fix the off by one error. This >>> may affect PLL jitter in a small way (hopefully for the better). >>> >>> Signed-off-by: Douglas Anderson >>> >> There's no Fixes tag or stable Cc so I take it this isn't fixing any >> manifesting regression, more of a visual inspection bug find? > There is no known problem fixed. I've been looking at HDMI and > controlling PLL jitter is an important part of supporting HDMI clock > rates. That got me to looking at this parameter and deciding that we > should set it correctly. Apparently it doesn't help in any hugely > significant way... I just got done re-testing a whole lot of rates > and if it helped or hurt my jitter it's in the noise (AKA there's > enough variance run-to-run that it's hard to tell if this made any > difference). > > Ok. Applied to clk-next. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project