Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp462675ybh; Tue, 10 Mar 2020 02:06:22 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsIcjtzgsku3dDBqUu6o/4SIjeTRCqirrByFgGcMh2X/tEXAFuUo1/s6XPpgkeWIUt1fhYs X-Received: by 2002:a05:6830:2009:: with SMTP id e9mr16649884otp.296.1583831182696; Tue, 10 Mar 2020 02:06:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583831182; cv=none; d=google.com; s=arc-20160816; b=EDLgZ4HGe/TLZP9/ePdlzlLcH5/kow0+rQvWr+MFQwvmYLUQOHzCrQDrnpyrcTppex RGxPn/hOEJBvvnWJtgwdV0RQrKttQUONCwlF4Ol+MkXIY+lA/eospYhVEh17i2myQ1kV BxmG8Jgrhiscv8qhfG3mEi/64KR6xqMCQhVTWabQIv1EJjBCsGqinHwXckxGaK/+ITlA u0bpOyOF5r0U3OvDCVc/tsJsJlCkvMPzapOczOHjG3L3Vp5FmOA2L5RZ5OSHz7HSanjh AWIOnFZDk/u7xGff/maRc3tQ8m9AESmxscCz4xf4zM4rSsoZK5i3e+9uzzxKopUbd9Bx f1IQ== 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 :in-reply-to:references:mime-version:dkim-signature; bh=IDHNp0kW8UZ5wVwRVY7Vrr/1bl/yMtFsFyxPULVhd4I=; b=gFPso3iGH4iYgvrtl6i8B4sY9MgVefLOMkqoSADKUuG1qN4UDcIWm6Hs4HTieeiIkJ hqxH0FuMgcFV70qUKgA7/v+3TxawMpjpsh6pXLJN3HSedpvvlZrG4KzFPPaBp/imeGOM Own1uxdTwnHY3s1avnAwQEpAYbKm36GF+xtSqLilIkuCBFdLZ198IFsRr2dgAJTKRibX agNCypzSs8u6p4BKD2T5ndZxM3lZo5xtFgSLLX6Ck0FGSEOniEnFCM77QrZeFs0IbSZp 411u2z+A45ox4ybJqzesnVtte4Gs0pz05/XQFIV6bb3aH1iEcwP4Ka34m7aDK3DodLwB Pcew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=FUIzwQPC; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w10si7445289otm.273.2020.03.10.02.06.10; Tue, 10 Mar 2020 02:06:22 -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=@linaro.org header.s=google header.b=FUIzwQPC; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726557AbgCJJFr (ORCPT + 99 others); Tue, 10 Mar 2020 05:05:47 -0400 Received: from mail-vs1-f66.google.com ([209.85.217.66]:43373 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726205AbgCJJFr (ORCPT ); Tue, 10 Mar 2020 05:05:47 -0400 Received: by mail-vs1-f66.google.com with SMTP id 7so7879189vsr.10 for ; Tue, 10 Mar 2020 02:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IDHNp0kW8UZ5wVwRVY7Vrr/1bl/yMtFsFyxPULVhd4I=; b=FUIzwQPCeu8dBEpHx+yYi9CrbOu7d822Ma/8XKSFj5B1UjoSmkI6kkIPNbTsw5ATUy A3ncpVnV0xTpdQIRlM3pKOmrUbSZfWjQTW8DPstw6sBqsP3U+somaNvfQUGfWcilrWGv 7VA9VtR5rjQYbWAfv2Kkp+jvj2/O/DU/e9w4H8TqadcsLJ/RhSWa20K5+UMEnqH9v/Sk ss8FcDFWhI3F0IlztcY49V9LDuTk9vCT19bwgu7J2DeOh4WTyAEczlXch7IML4rWOFdh FFgT9DBjaZ7sxNABFHIueqhOskdDNIuA62V9opzil0t8a14f09dyupylcYjUCAiaLMjk 7G3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IDHNp0kW8UZ5wVwRVY7Vrr/1bl/yMtFsFyxPULVhd4I=; b=BFnlHAPFzkMUTpF8nxfOmO6RMLlLvkY1uIgNYXL1zXM90xxZ6R/WsNoPfe0Gt+xAOU FmBzziBWi2tOVYvUy2XheELHN71ESkJjiGLtiPPVeCcg7C8JzF1ZjtcfHqfURxHA4vDd DIhKVlDdUk0Fh119oCMZhfpw3xh6+1tdp3aaxLVkjMcPgHrg4PdAN4Ku0TI/KBPnwA4P 8A1Yge4LNpY/cW7g0sBCndetKYDwFTIIUBzAC+L5tBRw4O7EgWpZ+iEOH/+tOxP/aojc rH7dsdB71jOZRhVip8QN5ETXKXNWj+ungO8qaMmQWb/ReBzKvmyxsZqkSl1Ob2mEPuOu xXhg== X-Gm-Message-State: ANhLgQ3q+yT9kErGW0PfqWll8bykePWjhNB5joa1mv6Vm5DShw9Q/Sfp InCGEFe5hoxxucib5MEk4af/buE6mlmPmvsGOU8l3A== X-Received: by 2002:a67:646:: with SMTP id 67mr12004425vsg.34.1583831144529; Tue, 10 Mar 2020 02:05:44 -0700 (PDT) MIME-Version: 1.0 References: <20200212024220.GA32111@seokyung-mobl1> In-Reply-To: From: Ulf Hansson Date: Tue, 10 Mar 2020 10:05:07 +0100 Message-ID: Subject: Re: [PATCH] mmc: mmc: Fix the timing for clock changing in mmc To: "Seo, Kyungmin" Cc: "Hunter, Adrian" , Chaotian Jing , "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List 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 Tue, 10 Mar 2020 at 05:28, Seo, Kyungmin wrote: > > I read the link and patch of Chaotian Jing. > I also point out what Chaotian said. > Most host controllers have DLL tuning values for each mode. When host controller is set as HS400 mode with 50MHz clock, host controller uses DLL value which is tuned with 200MHz clock. > > If DLL value in HS400 mode doesn't have the pass range in HS mode, command transfer failing may fail. > In order to make robust sdhci driver, I think the patch needs to be considered. I have, but I am not picking it up in its current form. > Of course, CMD6 with HS400 mode and 200MHz clock should not cause any problem because it's correct configuration. Yes, but not for all cases, as I said in my reply in those email-threads. What I had in mind, is that I I think we should inform mmc_hs400_to_hs200() about under what situation it's getting called. Depending on that, we should either decrease the clock rate before or after we send the CMD6. Would that work for your case? Kind regards Uffe > > Thanks > > -----Original Message----- > From: Ulf Hansson > Sent: Friday, March 6, 2020 12:18 AM > To: Seo, Kyungmin ; Hunter, Adrian ; Chaotian Jing > Cc: linux-mmc@vger.kernel.org; Linux Kernel Mailing List > Subject: Re: [PATCH] mmc: mmc: Fix the timing for clock changing in mmc > > + Adrian, Chaotian > > On Thu, 5 Mar 2020 at 09:57, Seo, Kyungmin wrote: > > > > The mmc_hs400_to_hs200 function is called only in HS400 mode. > > I saw the clock change from 200MHz to 52MHz via oscilloscope on real platform. > > > > I think CMD6 is sent in HS400 mode with 200MHz clock, but it's not. > > First CMD6 in mmc_hs400_to_hs200 function is sent with 52MHz clock. > > I had a vague memory that we have discussed a similar problem as your are pointing out on the mailing list already. And I was right. > > Please read up on the below references, [1], [2] for the earlier discussions. I suggested a solution for Chaotian to try, but it seems like he never managed to give it a go, as I don't recall new patch being posted. > > Perhaps you can pick up were Chaotian left and see if you can implement the suggested solution(s). My main concern is breaking other host drivers, as that seems quite likely to happen, if we aren't careful about this. > > Kind regards > Uffe > > [1] > https://lore.kernel.org/linux-mmc/1548921212-5219-1-git-send-email-chaotian.jing@mediatek.com/ > [2] > https://lore.kernel.org/linux-mmc/CAPDyKFquyyXx1MqNLVXuFxcEDB9nKzN8LGGNUP2yxoVMQrWiUg@mail.gmail.com/ > > > > > > > Thanks > > KM > > > > -----Original Message----- > > From: Ulf Hansson > > Sent: Wednesday, March 4, 2020 8:09 PM > > To: Seo, Kyungmin > > Cc: linux-mmc@vger.kernel.org; Linux Kernel Mailing List > > > > Subject: Re: [PATCH] mmc: mmc: Fix the timing for clock changing in > > mmc > > > > On Wed, 12 Feb 2020 at 03:40, Kyungmin Seo wrote: > > > > > > The clock has to be changed after sending CMD6 for HS mode selection > > > in > > > mmc_hs400_to_hs200() function. > > > > > > The JEDEC 5.0 and 5.1 said that "High-speed" mode selection has to > > > enable the the high speed mode timing in the Device, before chaning > > > the clock frequency to a frequency between 26MHz and 52MHz. > > > > I think that is based upon the assumption that you are using a lower frequency to start with. > > > > For example, assume that you are running with 400KHz during card initialization, then you want to send the CMD6 to switch to HS mode and that should be done, before updating the clock rate. > > > > mmc_hs400_to_hs200() goes the opposite direction, so I think the current code looks correct to me. > > > > Kind regards > > Uffe > > > > > > > > Signed-off-by: Kyungmin Seo > > > --- > > > drivers/mmc/core/mmc.c | 8 ++++---- > > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index > > > 3486bc7fbb64..98640b51c73e 100644 > > > --- a/drivers/mmc/core/mmc.c > > > +++ b/drivers/mmc/core/mmc.c > > > @@ -1196,10 +1196,6 @@ int mmc_hs400_to_hs200(struct mmc_card *card) > > > int err; > > > u8 val; > > > > > > - /* Reduce frequency to HS */ > > > - max_dtr = card->ext_csd.hs_max_dtr; > > > - mmc_set_clock(host, max_dtr); > > > - > > > /* Switch HS400 to HS DDR */ > > > val = EXT_CSD_TIMING_HS; > > > err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, > > > EXT_CSD_HS_TIMING, @@ -1210,6 +1206,10 @@ int > > > mmc_hs400_to_hs200(struct mmc_card *card) > > > > > > mmc_set_timing(host, MMC_TIMING_MMC_DDR52); > > > > > > + /* Reduce frequency to HS */ > > > + max_dtr = card->ext_csd.hs_max_dtr; > > > + mmc_set_clock(host, max_dtr); > > > + > > > err = mmc_switch_status(card); > > > if (err) > > > goto out_err; > > > -- > > > 2.17.1 > > >