From patchwork Wed Sep 30 14:07:37 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Heiko Stuebner X-Patchwork-Id: 7298801 Return-Path: X-Original-To: patchwork-linux-rockchip@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1E8F89F32B for ; Wed, 30 Sep 2015 14:16:15 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 407F3205E9 for ; Wed, 30 Sep 2015 14:16:14 +0000 (UTC) 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.kernel.org (Postfix) with ESMTPS id 8F82D20522 for ; Wed, 30 Sep 2015 14:16: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 1ZhIAz-0004Tt-4i; Wed, 30 Sep 2015 14:16:09 +0000 Received: from gloria.sntech.de ([95.129.55.99]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZhI3P-00036v-5W; Wed, 30 Sep 2015 14:08:22 +0000 Received: from ip5f5b95ad.dynamic.kabel-deutschland.de ([95.91.149.173] helo=diego.lan) by gloria.sntech.de with esmtpsa (TLS1.1:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZhI2v-0007Fz-FA; Wed, 30 Sep 2015 16:07:49 +0200 From: Heiko Stuebner To: ulf.hansson@linaro.org, mturquette@baylibre.com, sboyd@codeaurora.org, tgih.jun@samsung.com, jh80.chung@samsung.com Subject: [PATCH v2 1/8] clk: rockchip: Allow more precision for some mmc clock phases Date: Wed, 30 Sep 2015 16:07:37 +0200 Message-Id: <1443622064-14362-2-git-send-email-heiko@sntech.de> X-Mailer: git-send-email 2.5.3 In-Reply-To: <1443622064-14362-1-git-send-email-heiko@sntech.de> References: <1443622064-14362-1-git-send-email-heiko@sntech.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150930_070819_825606_3C1F8B24 X-CRM114-Status: GOOD ( 12.91 ) X-Spam-Score: -2.6 (--) 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: amstan@chromium.org, linux-mmc@vger.kernel.org, dianders@chromium.org, linux-rockchip@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Heiko Stuebner MIME-Version: 1.0 Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Douglas Anderson Because of the inexact nature of the extra MMC delay elements (it's not possible to keep the phase monotonic and to also make phases (mod 90) > 70), we previously only allowed phases (mod 90) of 22.5, 45, and 67.5. But it's not the end of the world if the MMC clock phase goes non-monotonic. At most we'll be 25 degrees off. It's way better to test more phases to look for bad ones than to be 25 degrees off, because in the case of MMC really the point is to find bad phases and get as far asway from the as possible. If we get to test extra phases by going slightly non-monotonic then that might be fine. Worst case we would end up at a phases that's slight differnt than the one we wanted, but at least we'd still be quite far away from the a bad phase. Signed-off-by: Douglas Anderson Fold in more precise variance-values of 44-77 instead of 40-80. Fold in the actual removal of the monotonic requirement and adapt patch message accordingly. Signed-off-by: Heiko Stuebner --- drivers/clk/rockchip/clk-mmc-phase.c | 45 ++++++++++++++++++++++++------------ 1 file changed, 30 insertions(+), 15 deletions(-) diff --git a/drivers/clk/rockchip/clk-mmc-phase.c b/drivers/clk/rockchip/clk-mmc-phase.c index 9b61342..a797d86 100644 --- a/drivers/clk/rockchip/clk-mmc-phase.c +++ b/drivers/clk/rockchip/clk-mmc-phase.c @@ -45,8 +45,8 @@ static unsigned long rockchip_mmc_recalc(struct clk_hw *hw, #define PSECS_PER_SEC 1000000000000LL /* - * Each fine delay is between 40ps-80ps. Assume each fine delay is 60ps to - * simplify calculations. So 45degs could be anywhere between 33deg and 66deg. + * Each fine delay is between 44ps-77ps. Assume each fine delay is 60ps to + * simplify calculations. So 45degs could be anywhere between 33deg and 57.8deg. */ #define ROCKCHIP_MMC_DELAY_ELEMENT_PSEC 60 @@ -84,22 +84,37 @@ static int rockchip_mmc_set_phase(struct clk_hw *hw, int degrees) u32 raw_value; u64 delay; - /* allow 22 to be 22.5 */ - degrees++; - /* floor to 22.5 increment */ - degrees -= ((degrees) * 10 % 225) / 10; - nineties = degrees / 90; - /* 22.5 multiples */ - remainder = (degrees % 90) / 22; - + remainder = (degrees % 90); + + /* + * Due to the inexact nature of the "fine" delay, we might + * actually go non-monotonic. We don't go _too_ monotonic + * though, so we should be OK. Here are options of how we may + * work: + * + * Ideally we end up with: + * 1.0, 2.0, ..., 69.0, 70.0, ..., 89.0, 90.0 + * + * On one extreme (if delay is actually 44ps): + * .73, 1.5, ..., 50.6, 51.3, ..., 65.3, 90.0 + * The other (if delay is actually 77ps): + * 1.3, 2.6, ..., 88.6. 89.8, ..., 114.0, 90 + * + * It's possible we might make a delay that is up to 25 + * degrees off from what we think we're making. That's OK + * though because we should be REALLY far from any bad range. + */ + + /* + * Convert to delay; do a little extra work to make sure we + * don't overflow 32-bit / 64-bit numbers. + */ delay = PSECS_PER_SEC; - do_div(delay, rate); - /* / 360 / 22.5 */ - do_div(delay, 16); - do_div(delay, ROCKCHIP_MMC_DELAY_ELEMENT_PSEC); - delay *= remainder; + do_div(delay, 10000); + do_div(delay, (rate / 1000) * 36 * ROCKCHIP_MMC_DELAY_ELEMENT_PSEC); + delay_num = (u8) min(delay, 255ULL); raw_value = delay_num ? ROCKCHIP_MMC_DELAY_SEL : 0;