Received: by 10.213.65.68 with SMTP id h4csp674626imn; Fri, 6 Apr 2018 07:08:05 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/obklUUrEf5WVV3+tbgJTsbFRf5S04salIurKTfzrjFa/9aAHEHEJzD1WzsT4XMhtGm4+l X-Received: by 2002:a17:902:158b:: with SMTP id m11-v6mr27411297pla.300.1523023684975; Fri, 06 Apr 2018 07:08:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523023684; cv=none; d=google.com; s=arc-20160816; b=MzgCsWP1Eo7OMQLjeUtxEbX+Uwqo4rNkfHsI7ur1t+jfUp2ywWtm24F9dp1JQiz7Me QN/iKTYGyg9k6WocbTmR8wYAYAJplLu3vxzqca47KYV5pUk/4gguEObWTyZjQ083XTjv 9CLh82q/+N8j2XHcs8O6dyrZw2EAMTMDR4MrE0a2zMG88GOMKe5j0IDzu2v85X5CnMcb IEcPBuy1u8oDTTJ0+Vp9AEG6RvoMH/TzvwJeF7NAAtxnvwTHwt7js25kW1mxpwCxWEF6 tqKOYRhzRJiUDyGT90Oc1k70AtD3Zv2RyYVFWaCyZbQqvx5gUPPewzV/D1RzuMIR7cD9 HCLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=/9SfrA/DZlt6I3Zi3vbdST62MJ8W6C8FCyL2l/Y8gas=; b=UJwMYzlc/LGsaso0avUpg1C76vzbAeyv1tG/gPERk8bG8hnB3iR4Bwc9A/0trjJvQl CTWb8Yq+eOtqCqi2N6MewGDOqVJmeG09JCzFnfXxU6HCr+BpEDIkkeYA8+MDPANABHUj Vcr/B+fiZDkzQQDMw+yaZypqL4EhbXD/80mRskWitxyufsJQnT1QS0+3jMUAu0fny4rT cDpHWNtEI+QJG1Rasbu1cAArFAx7E5n0UdFN4lxznSITPOCX7qLt7Fc88kE2Ajk6kf20 5ktGIBNnCfXxkHIllHFJnVsE5q75MYuyPVjqLgB2M+SLteeDAUheGZJWzSvo7FWmto+e wpCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@edited-us.20150623.gappssmtp.com header.s=20150623 header.b=oQTvQOgM; 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 f12-v6si9511511pln.211.2018.04.06.07.07.50; Fri, 06 Apr 2018 07:08:04 -0700 (PDT) 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=pass header.i=@edited-us.20150623.gappssmtp.com header.s=20150623 header.b=oQTvQOgM; 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 S1755251AbeDFOGr (ORCPT + 99 others); Fri, 6 Apr 2018 10:06:47 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:36579 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932851AbeDFNlO (ORCPT ); Fri, 6 Apr 2018 09:41:14 -0400 Received: by mail-lf0-f66.google.com with SMTP id z143-v6so613273lff.3 for ; Fri, 06 Apr 2018 06:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=edited-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/9SfrA/DZlt6I3Zi3vbdST62MJ8W6C8FCyL2l/Y8gas=; b=oQTvQOgMWe197jZ2siKaUHRsXgiCktqHCSFPZguWa+cjX1/jN529ut7/cVETdhDYnv aNYggTOkdv64Iw1+IsWvHz9M6Gh+NWkZLvnItAN5zlk+YYy8bk3fmytXRel4evYtKXdG PU7dadanFVPVH0AD0SrXSunsJK8MpRU7tcGGo2GRg3CZOCis0Tccqgq9qKC+mK6aLI7s Vn1hKLn+ggzep2xfsRHb/CQbwfcKUwFumFpk4Xf+SzWz7vaXvpfKSmOE9lM5oxazpwTU b87GXjklSSETovlnu+Tvmu11/TZoXqBIc+tzl5O+BS+h90+SQ7SW7rJvgrjTaAItQlwb Gj6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/9SfrA/DZlt6I3Zi3vbdST62MJ8W6C8FCyL2l/Y8gas=; b=KnaDGdQO/Ka7R1CFUDAeYkwYopkqgly2/Eb3uqqY3sxPfHuQEys8q2DYb7b5Xq6QSz 6xW6pdfxWZOOcLw43GkloZu7rFk1MZsTiUmy5kU1NYA4oU8XvIa1NCZh6jIjuitNN7pn WJOPWU+71ZxGckvlfqJ3xH6RmUxNwc/t9rczc/zd6upmQzhNVP3xWQro5jh9JTNIG7kO TDlZPtZfk2cgthqALgqh6I+MvVwK9Fen4UprjCld/XTLI6Wc75RHH+ZPm4UVxDtHQ9za z6M2IuaZqQacmdb6C4+GJLzalDNbtUSk+RiAC2V6c/ISBnR5ZQY5ZXq/+BE9AauCIfHz Br8w== X-Gm-Message-State: ALQs6tBsgukbmQ+lB+k2bmCO14nC21gTzctOy0R+uexYiezrgruKNkcy D9LlqkDAeYqqhYTEEC3emk3CYUWkIFvS49KIYnfodyyVPXw= X-Received: by 10.46.68.14 with SMTP id r14mr17136393lja.44.1523022072120; Fri, 06 Apr 2018 06:41:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.130.197 with HTTP; Fri, 6 Apr 2018 06:41:11 -0700 (PDT) In-Reply-To: References: <20180329182423.21201-1-ryan@edited.us> From: Ryan Grachek Date: Fri, 6 Apr 2018 08:41:11 -0500 Message-ID: Subject: Re: [PATCH] mmc: dw_mmc-k3: Fix DDR52 mode by setting required clock divisor To: Shawn Lin Cc: Jaehoon Chung , Ulf Hansson , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Zhangfei Gao , Ryan Grachek Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 4, 2018 at 7:51 PM, Shawn Lin wrote: > [+ Zhangfei Gao who added support for hi6220] > > On 2018/4/4 23:31, Ryan Grachek wrote: >> >> On Tue, Apr 3, 2018 at 6:31 AM, Shawn Lin > > wrote: >> >> On 2018/3/30 2:24, oscardagrach wrote: >> >> Need at least one line commit body. >> >> Signed-off-by: oscardagrach > > >> >> --- >> drivers/mmc/host/dw_mmc-k3.c | 10 ++++++++-- >> 1 file changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mmc/host/dw_mmc-k3.c >> b/drivers/mmc/host/dw_mmc-k3.c >> index 89cdb3d533bb..efc546cb4db8 100644 >> --- a/drivers/mmc/host/dw_mmc-k3.c >> +++ b/drivers/mmc/host/dw_mmc-k3.c >> @@ -194,8 +194,14 @@ static void dw_mci_hi6220_set_ios(struct >> dw_mci *host, struct mmc_ios *ios) >> int ret; >> unsigned int clock; >> - clock = (ios->clock <= 25000000) ? 25000000 : ios->clock; >> - >> + /* CLKDIV must be 1 for DDR52/8-bit mode */ >> + if (ios->bus_width == MMC_BUS_WIDTH_8 && >> + ios->timing == MMC_TIMING_MMC_DDR52) { >> + mci_writel(host, CLKDIV, 0x1); >> + clock = ios->clock; >> + } else { >> + clock = (ios->clock <= 25000000) ? 25000000 : >> ios->clock; >> + } >> >> >> I undertand DDR52/8-bit need CLKDIV fixed 1, but shouldn't the >> following >> change is more sensible? >> >> if (ios->bus_width == MMC_BUS_WIDTH_8 && ios->timing == >> MMC_TIMING_MMC_DDR52) >> clock = ios->clock * 2; >> else >> clock = (ios->clock <= 25000000) ? 25000000 : ios->clock; >> >> >> The reason is ios->clock is 52MHz and you could claim 104MHz from the >> clock provider and let dw_mmc core take care of the divder to be 1. >> Otherwise, you just force it to be DDR52/8-bit with a clk rate of >> 26MHz. >> >> >> ret = clk_set_rate(host->biu_clk, clock); >> if (ret) >> dev_warn(host->dev, "failed to set rate >> %uHz\n", clock); >> >> >> > > For future wise, please use plain mode mail, but not HTML format. > >> Your feedback is correct. I see the Rockchip dwmmc driver has a similar >> implementation. After applying your suggested changes, however, my board >> reports "dwmmc_k3 f723d000.dwmmc0: failed to set rate 104000000Hz" >> during intialization of eMMC. In addition, I do not see CLKDIV being >> set to 1. clk_set_rate fails and I wonder if this is out-of-scope of >> the driver. >> >> If I set CLKDIV where I did prior, with your changes, the device fails >> to set the clock and falls back to 52 MHz (26 MHz) and works fine, but >> again, CLKDIV is reported as 0 (even though it is 1.) One thing of >> interest to note is when I manually set the clock by doing: >> (echo 104000000 > /sys/kernel/debug/mmc0/clock) the device reports back >> 'mmc_host mmc0: Bus speed (slot 0) = 198400000Hz (slot req 104000000Hz, >> actual 99200000HZ div = 1)' which works reliably and clk_set_rate does >> not report any error. >> > > When looking closely into the code, at least dw_mci_hi6220_set_ios > goes wrong with the bus_hz, since it should be ciu_clk but not biu_clk. > "b" stands for bus, and "c" stands for card IMHO, however bus_hz > describs the clock to the card, provided by controller. Does the > following patch help? > > > diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c > index 89cdb3d..9e78cf2 100644 > --- a/drivers/mmc/host/dw_mmc-k3.c > +++ b/drivers/mmc/host/dw_mmc-k3.c > @@ -194,13 +194,21 @@ static void dw_mci_hi6220_set_ios(struct dw_mci *host, > struct mmc_ios *ios) > int ret; > unsigned int clock; > > - clock = (ios->clock <= 25000000) ? 25000000 : ios->clock; > + if (ios->bus_width == MMC_BUS_WIDTH_8 && > + ios->timing == MMC_TIMING_MMC_DDR52) > + clock = ios->clock * 2; > + else > + clock = (ios->clock <= 25000000) ? 25000000 : ios->clock; > > - ret = clk_set_rate(host->biu_clk, clock); > + ret = clk_set_rate(host->ciu_clk, clock); > if (ret) > dev_warn(host->dev, "failed to set rate %uHz\n", clock); > > - host->bus_hz = clk_get_rate(host->biu_clk); > + clock = clk_get_rate(host->ciu_clk); > + if (clock != host->bus_hz) { > + host->bus_hz = clock; > + host->current_speed = 0; > + } > > } > > >> I am not sure where to begin debugging these clock issues and welcome >> any feedback. > > The change results in the following: 'dwmmc_k3 f723e000.dwmmc1: failed to set rate 25000000Hz' 'dwmmc_k3 f723d000.dwmmc0: failed to set rate 25000000Hz' 'dwmmc_k3 f723f000.dwmmc2: failed to set rate 25000000Hz' and later on: 'dwmmc_k3 f723d000.dwmmc0: failed to set rate 52000000Hz' 'dwmmc_k3 f723d000.dwmmc0: failed to set rate 104000000Hz' Eventually mmc1 (UHS-1 MicroSD) will settle down after repeated attempts at setting 25 MHz: 'mmc_host mmc1: Bus speed (slot 0) = 100000000Hz (slot req 100000000Hz, actual 100000000HZ div = 0)' 'mmc1: new ultra high speed SDR50 SDHC card at address 0001' 'mmcblk1: mmc1:0001 GB1QT 29.8 GiB' Same for mmc2 (SDIO WL1835MOD WiFi): 'mmc_host mmc2: Bus speed (slot 0) = 100000000Hz (slot req 50000000Hz, actual 50000000HZ div = 1)' 'mmc2: new high speed SDIO card at address 0001' So mmc1 and mmc2 will initialize eventually. I had not observed this behavior prior. It appears to fail setting all devices to an initial rate of 25 MHz. However, the same cannot be said for mmc0 (eMMC). Again, I observed being able to set the clock manually through debugfs to 104MHz(/2) which is successful and the card becomes stable and will initialize properly. 'echo 104000000 > /sys/kernel/debug/mmc0/clock' 'mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot req 104000000Hz, actual 100000000HZ div = 1)' So it seems to settle down at 50 MHz, but only if set manually. It does appear CLKDIV is being set accordingly now.