From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 452E5C43387 for ; Wed, 2 Jan 2019 18:29:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F93821871 for ; Wed, 2 Jan 2019 18:29:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lixom-net.20150623.gappssmtp.com header.i=@lixom-net.20150623.gappssmtp.com header.b="S7wuCq0z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728105AbfABS3o (ORCPT ); Wed, 2 Jan 2019 13:29:44 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:45973 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728069AbfABS3n (ORCPT ); Wed, 2 Jan 2019 13:29:43 -0500 Received: by mail-io1-f66.google.com with SMTP id c2so3027061iom.12 for ; Wed, 02 Jan 2019 10:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dEtgMdgrRwB7E/S8vh13UWGDjjT83i0QNMMZoYtOVwo=; b=S7wuCq0znPBLndPwOshGeBMPl/T0Q2qYShI79W8GaHeby14SM0NuuSjQdNEl8RReib QI3gplrcfaLpvQpnlEV9HJqkV7yKPGyQu2fuTz3jlmPaOfIqDjwvWRUps+49RQ6VaDl1 UCNHT9Djt8FLNOQIWnVES/GO0eW8cY0aqYxskFeLI9jZiBVvyV6GKSQ4Eqf+jIDTcrQ0 A2EZASGNEyHuA3E9TYv5w1rCnRJcwsGu52B4hijMcd3DXqRoLswQ0moJKesSVbNbpdf5 qnBB3+JarXo3gtRyxM4MN5WFqkvJnHyDyJwCAwM1w9dpm05s1qXTjPZByrkE9XN8deXZ ugBA== 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=dEtgMdgrRwB7E/S8vh13UWGDjjT83i0QNMMZoYtOVwo=; b=J0m+eRD5cjaJ4fP7922mNlDZ7j/yytyRCfIhYnA243qiv0INVgXoPWJCEr9kKl94la 8srxsx1rF3JgygfKjpxcwXqQwA8/zrKnYgM2zMl5mUbBlZZLnHwoEgQt9IRRYjPlroNZ 34FW7hOIT0rDNrZF/oCMQytBVHPdBfE01RDHM3C36pttCTRCLn3pTVADtlrdRy2FLwil jcvRjW8WTbMACdNDsNTZFbXYqdUvoCWSf052fdTYNUgl4CgMWKYOleIEwdKW4GaWULz5 9NwTpg/mTOmDTPfn3vGHtq1cwxX7jBcq2OfgCyGgBPmQHvADoFGGmO6SnnjK5W0ilHJQ LL5A== X-Gm-Message-State: AJcUukf620BOcYNFpSNvAjpuHJy3qWQl+CBofHpA42jN6yAS35BA81Gs gGtUeoiuFVeFZrBIJm4DuY3JcmoRSCTXj+NBm1SetA== X-Google-Smtp-Source: ALg8bN4p35K1/JsWvHA/FylMqYIdG8UoeuQwSyWF1O5tnbjij/Htp/zSyMgVdxixTAbCKxX5RDpoOXe9XbV563uix40= X-Received: by 2002:a6b:1414:: with SMTP id 20mr31039933iou.140.1546453782362; Wed, 02 Jan 2019 10:29:42 -0800 (PST) MIME-Version: 1.0 References: <20181211142253.23747-1-faiz_abbas@ti.com> <20181211142253.23747-3-faiz_abbas@ti.com> In-Reply-To: From: Olof Johansson Date: Wed, 2 Jan 2019 10:29:31 -0800 Message-ID: Subject: Re: [PATCH v2 2/2] mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929) To: Ulf Hansson Cc: Faiz Abbas , Linux Kernel Mailing List , "linux-mmc@vger.kernel.org" , Adrian Hunter , Kishon , Keerthy , Zhang Rui , Eduardo Valentin , Daniel Lezcano , Santosh Shilimkar , Tony Lindgren 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 Hi, On Wed, Dec 12, 2018 at 1:20 AM Ulf Hansson wrote: > > + Thermal maintainers > > On Tue, 11 Dec 2018 at 15:20, Faiz Abbas wrote: > > > > Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions > > (SPRZ426D - November 2014 - Revised February 2018 [1]) mentions > > unexpected tuning pattern errors. A small failure band may be present > > in the tuning range which may be missed by the current algorithm. > > Furthermore, the failure bands vary with temperature leading to > > different optimum tuning values for different temperatures. > > > > As suggested in the related Application Report (SPRACA9B - October 2017 > > - Revised July 2018 [2]), tuning should be done in two stages. > > In stage 1, assign the optimum ratio in the maximum pass window for the > > current temperature. In stage 2, if the chosen value is close to the > > small failure band, move away from it in the appropriate direction. > > > > References: > > [1] http://www.ti.com/lit/pdf/sprz426 > > [2] http://www.ti.com/lit/pdf/SPRACA9 > > > > Signed-off-by: Faiz Abbas > > Acked-by: Adrian Hunter > > --- > > drivers/mmc/host/Kconfig | 2 + > > drivers/mmc/host/sdhci-omap.c | 90 ++++++++++++++++++++++++++++++++++- > > 2 files changed, 91 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > > index 5fa580cec831..d8f984483ab0 100644 > > --- a/drivers/mmc/host/Kconfig > > +++ b/drivers/mmc/host/Kconfig > > @@ -977,6 +977,8 @@ config MMC_SDHCI_XENON > > config MMC_SDHCI_OMAP > > tristate "TI SDHCI Controller Support" > > depends on MMC_SDHCI_PLTFM && OF > > + select THERMAL > > + select TI_SOC_THERMAL > > help > > This selects the Secure Digital Host Controller Interface (SDHCI) > > support present in TI's DRA7 SOCs. The controller supports > > diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c > > index f588ab679cb0..b75c55011fcb 100644 > > --- a/drivers/mmc/host/sdhci-omap.c > > +++ b/drivers/mmc/host/sdhci-omap.c > > @@ -27,6 +27,7 @@ > > #include > > #include > > #include > > +#include > > > > #include "sdhci-pltfm.h" > > > > @@ -286,15 +287,19 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) > > struct sdhci_host *host = mmc_priv(mmc); > > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); > > struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host); > > + struct thermal_zone_device *thermal_dev; > > struct device *dev = omap_host->dev; > > struct mmc_ios *ios = &mmc->ios; > > u32 start_window = 0, max_window = 0; > > + bool single_point_failure = false; > > bool dcrc_was_enabled = false; > > u8 cur_match, prev_match = 0; > > u32 length = 0, max_len = 0; > > u32 phase_delay = 0; > > + int temperature; > > int ret = 0; > > u32 reg; > > + int i; > > > > /* clock tuning is not needed for upto 52MHz */ > > if (ios->clock <= 52000000) > > @@ -304,6 +309,16 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, u32 opcode) > > if (ios->timing == MMC_TIMING_UHS_SDR50 && !(reg & CAPA2_TSDR50)) > > return 0; > > > > + thermal_dev = thermal_zone_get_zone_by_name("cpu_thermal"); > > I couldn't find a corresponding call to a put function, like > "thermal_zone_put()" or whatever, which made me realize that the > thermal zone API is incomplete. Or depending on how you put it, it > lacks object reference counting, unless I am missing something. > > For example, what happens if the thermal zone becomes unregistered > between this point and when you call thermal_zone_get_temp() a couple > of line below. I assume it's a known problem, but just wanted to point > it out. > > > + if (IS_ERR(thermal_dev)) { > > + dev_err(dev, "Unable to get thermal zone for tuning\n"); > > + return PTR_ERR(thermal_dev); > > + } > > + > > + ret = thermal_zone_get_temp(thermal_dev, &temperature); > > + if (ret) > > + return ret; > > + > > [...] > > Anyway, I have applied this for next, thanks! This is throwing errors on builds of keystone_defconfig in next and mainline: http://arm-soc.lixom.net/buildlogs/next/next-20190102/buildall.arm.keystone_defconfig.log.passed WARNING: unmet direct dependencies detected for TI_SOC_THERMAL Depends on [n]: THERMAL [=y] && (ARCH_HAS_BANDGAP [=n] || COMPILE_TEST [=n]) && HAS_IOMEM [=y] Selected by [y]: - MMC_SDHCI_OMAP [=y] && MMC [=y] && MMC_SDHCI_PLTFM [=y] && OF [=y] So, thermal depends on ARCH_HAS_BANDGAP, which keystone doesn't provide. Selecting a major framework such as THERMAL from a driver config is likely not the right solution anyway, especially since THERMAL does provide stubbed out versions of the functions if it's not enabled. -Olof