From patchwork Tue Jan 20 15:32:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Griffin X-Patchwork-Id: 5669911 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1C864C058D for ; Tue, 20 Jan 2015 15:33:04 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 27A6920435 for ; Tue, 20 Jan 2015 15:33:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AD91A20458 for ; Tue, 20 Jan 2015 15:33:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753255AbbATPcz (ORCPT ); Tue, 20 Jan 2015 10:32:55 -0500 Received: from mail-wi0-f175.google.com ([209.85.212.175]:37771 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753200AbbATPcy (ORCPT ); Tue, 20 Jan 2015 10:32:54 -0500 Received: by mail-wi0-f175.google.com with SMTP id fb4so18441894wid.2 for ; Tue, 20 Jan 2015 07:32:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=FupQmQeRS6rpwnSjKbChVA3tEV1GU0+NjOED1D5cGsY=; b=ZyPDdQHj6nY04mRBacDs6Ei/yzQhw69TEnz6U+YyVStdkLJi0jghiGN/BwrtOTTdIW glLO/Mcdbv+08X39AF0t+Iots/8Sj8oC0ymISsuYNZVlyIXmm6pa/yqjXaULzd+vzKbW OfHJYDpsLLw+voO1wwsnB6R7rOW+sn/WACbxcav+QYodnHYZ3McnDftPnureJqQWlGgJ Be9bTq04fvv9SxzDB1yTyIwoBq0cG0f9OnvwGIqu1oVOmLxDXf8AyI5jwGkdXtp/1nnX bCPlJ78u/6T0UAPcenMX57b6BMN2Rz6beAeyf3PulUxnBBqGUhl5Jt9tTpw24ORU1iAm b+NQ== X-Gm-Message-State: ALoCoQmNEC2RRudZE7Dxtlo6enbPLOAtoOqsEyQz4W3yrgHmnY0Qn9r1tNDB8JAykcGTfhR6QP+r X-Received: by 10.180.83.5 with SMTP id m5mr11965436wiy.74.1421767972721; Tue, 20 Jan 2015 07:32:52 -0800 (PST) Received: from localhost.localdomain (cpc14-aztw22-2-0-cust189.18-1.cable.virginm.net. [82.45.1.190]) by mx.google.com with ESMTPSA id dv9sm3464185wib.14.2015.01.20.07.32.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Jan 2015 07:32:51 -0800 (PST) From: Peter Griffin To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, srinivas.kandagatla@gmail.com, maxime.coquelin@st.com, patrice.chotard@st.com, mturquette@linaro.org, sboyd@codeaurora.org, chris@printf.net, ulf.hansson@linaro.org Cc: peter.griffin@linaro.org, lee.jones@linaro.org, peppe.cavallaro@st.com, olivier.bideau@st.com, gabriel.fernandez@st.com, linux-mmc@vger.kernel.org, devicetree@vger.kernel.org Subject: [PATCH 1/4] clk: st: STiH410: Fix pdiv and fdiv divisor when setting rate Date: Tue, 20 Jan 2015 15:32:41 +0000 Message-Id: <1421767964-8798-2-git-send-email-peter.griffin@linaro.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1421767964-8798-1-git-send-email-peter.griffin@linaro.org> References: <1421767964-8798-1-git-send-email-peter.griffin@linaro.org> Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham 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 Debugging eMMC on upstream kernels it has been noticed that when the targetpack configures MMC0 clock to 200Mhz (required to switch to HS200) then everything works OK. However if the kernel sets the clock rate using clk_set_rate, then the eMMC card initialisation fails with timeouts. Lower clock speeds (the default being 50Mhz) work ok, but they we fail to get good eMMC transfer rates. Looking through the vendor kernel clock driver reveals Giuseppe had already fixed this issue, but the patch hasn't made its way upstream. The issue is fixed by changing the logic to manage the pdiv and fdiv divisors used for setting the rate inside the flexgen driver code. Pdiv is mainly targeted for low freq results, while fdiv should be used for divs =< 64. The other way can lead to 'duty cycle' issues. I have changed the original patch to keep the original behaviour in cases where the div is >64 which matches the original comment and patch description more closely. Although no clocks appear to hit this case currently when booting an upstream kernel. Signed-off-by: Peter Griffin Signed-off-by: Giuseppe Cavallaro --- drivers/clk/st/clk-flexgen.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/clk/st/clk-flexgen.c b/drivers/clk/st/clk-flexgen.c index 2282cef..3a484b3 100644 --- a/drivers/clk/st/clk-flexgen.c +++ b/drivers/clk/st/clk-flexgen.c @@ -138,16 +138,27 @@ static int flexgen_set_rate(struct clk_hw *hw, unsigned long rate, struct flexgen *flexgen = to_flexgen(hw); struct clk_hw *pdiv_hw = &flexgen->pdiv.hw; struct clk_hw *fdiv_hw = &flexgen->fdiv.hw; - unsigned long primary_div = 0; + unsigned long div = 0; int ret = 0; pdiv_hw->clk = hw->clk; fdiv_hw->clk = hw->clk; - primary_div = clk_best_div(parent_rate, rate); + div = clk_best_div(parent_rate, rate); - clk_divider_ops.set_rate(fdiv_hw, parent_rate, parent_rate); - ret = clk_divider_ops.set_rate(pdiv_hw, rate, rate * primary_div); + /* + * pdiv is mainly targeted for low freq results, while fdiv + * should be used for div <= 64. The other way round can + * lead to 'duty cycle' issues. + */ + + if (div <= 64) { + clk_divider_ops.set_rate(pdiv_hw, parent_rate, parent_rate); + ret = clk_divider_ops.set_rate(fdiv_hw, rate, rate * div); + } else { + clk_divider_ops.set_rate(fdiv_hw, parent_rate, parent_rate); + ret = clk_divider_ops.set_rate(pdiv_hw, rate, rate * div); + } return ret; }