Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2628059ybi; Mon, 17 Jun 2019 07:59:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqyTtfvVGPbUq6K1XR12kfcAMhC9YkCiTBr76y151B38FA8M+J1kLAxuoSfdYxACXJILmoWY X-Received: by 2002:aa7:91c5:: with SMTP id z5mr22343767pfa.34.1560783592046; Mon, 17 Jun 2019 07:59:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560783592; cv=none; d=google.com; s=arc-20160816; b=t2Iyuz4aWZvmBylNebya/vsv0A68gWR4mbCDvRDhKqTJl7IVrGD7NelTUbXrwlr6GJ VXUjjYzTEqKp3FomqnEVeGeLoIAYmcJNTEyIDjboULmKFVWlLvd6s7A8HgKqKaItWw8C 0GGTYvTWjzKilGQ1KlpQQYYPMHX2X+cN6VTCmeuDnsYn/NiQy+00NkDdo140rrCqghZ1 Kz2LHEJD/r784p8bjPDqbH8gae7M2qQbbRPuE64obP+eDx8MDX/H8UVZm+XM/c63wnPi JksNcB00BTTf6hL2g4xXdsxVaIiMRVO2kaZJNJZ6DnWiee/TtEua+KIsmaDOXeZiFkfj Il7A== 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=VeDj455KpUjyGeFAvU/iNT8gTzAGIt+VE2V1K3FogGo=; b=r7Q9p2IGoe5rgyGS0s/aR6194kvnPDCr+Jw/NgyfNVlJss//gwNDFqFimm8hCtH+wg PzEXL3GeZe++/2xRWmWKWPdDvxFlivE/dA7KsCLOkj83duGE1btPIV/5ae/sDaz31w2x 0B46Fcu3Pj4PMXXSpfpDD/ipsk0wcrPyPpIDXu5uUM0LIJQHgDO8E0L/OjZlwwYPOCdB SrbCLX8ngFQ2ASZJwsytGRFY06Ua+mNZcMcYz7r+0s4yZeNZCYTeXoHjtsd62NR0P9pR A0NDcYug+dQ2/+NCGJqUx79n1yMxqRomqEmsv9zUcHu0e4C+xh1H6p3girzh71XikrZM 4qUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=x2rtsNq8; 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 k2si9655204pjp.106.2019.06.17.07.59.35; Mon, 17 Jun 2019 07:59:52 -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=x2rtsNq8; 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 S1728254AbfFQO7Z (ORCPT + 99 others); Mon, 17 Jun 2019 10:59:25 -0400 Received: from mail-vk1-f196.google.com ([209.85.221.196]:42252 "EHLO mail-vk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726215AbfFQO7Y (ORCPT ); Mon, 17 Jun 2019 10:59:24 -0400 Received: by mail-vk1-f196.google.com with SMTP id 130so2117244vkn.9 for ; Mon, 17 Jun 2019 07:59:24 -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=VeDj455KpUjyGeFAvU/iNT8gTzAGIt+VE2V1K3FogGo=; b=x2rtsNq8v/D8WowlfZi68S9op6AgNbvw20AEk01oXwgbgkkIqGoh7yUHC2b/x+Fpks hklTr4vyJFfnu46NYXoNF6cujUaH2nJQMgSndZx6YhVWpyXQREM/XIlZFWsCPzzqbYiZ d9i05TZWygp+RIske9k1qLrWcaQAd/Qz+aN1n8KuXzvzWd2HFoqGQgZsdgg5slwtqKvh pPhE+uUNLhxtsRLRSEVjSrQiG5JEQ60sNKYn0vQTydYe4bzRPTx6iuUywg9Zsu/SsUjU fWFjgza4amZzX20SY1DLOo9T5LBGUNCZv8ErViIL7AVqDk5W7UW8sqW9LT4snHzVQcPl Y31w== 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=VeDj455KpUjyGeFAvU/iNT8gTzAGIt+VE2V1K3FogGo=; b=SZ1JQHJUF07UqoZWuHdhQMCvbdlpsG8o+ycJIZ0dB+hgI+6XVY+JFVMjaPClTQzPUR R9jk2FxRv853/k5qYpBOd5diYd1ukQFdS/BuhdUQ2vYC1PmjnlXjPGiXwScVJ9m5MPYL kc87kM+wRAGXQqLJJ9W384chDNCdHlne03Pp9XQdOzDxoiA5AwkKVW+jlm1eUNjIe/U6 Eyn5d3RnfsIphgkQ4WOCXPJy793NefoM5CY77u8ctTcQqEfX89sdMtqKIQhLQGgC1dJI REyqjksBu4VEta1gO8ueOdLD9DEjA3Fj/K1nf3cZvrRwsGuybuIWAuMrkUqI8LnwzfGW WzBQ== X-Gm-Message-State: APjAAAXQstI6xMqitOfjXQwlby5xPKLgxKIgmS3Z2Qi+vCF4rXjIHbBl firAniMly3SGK8EXCeq13+76AONx3mNExlGkvPe6wA== X-Received: by 2002:a1f:8744:: with SMTP id j65mr43978757vkd.17.1560783563932; Mon, 17 Jun 2019 07:59:23 -0700 (PDT) MIME-Version: 1.0 References: <1560247011-26369-1-git-send-email-manish.narani@xilinx.com> <1560247011-26369-4-git-send-email-manish.narani@xilinx.com> <5feac3fb-bef3-b7d1-57d6-81e115e1f555@xilinx.com> <948514a0-e310-75fd-e8a8-6ef8bb14e41f@xilinx.com> In-Reply-To: <948514a0-e310-75fd-e8a8-6ef8bb14e41f@xilinx.com> From: Ulf Hansson Date: Mon, 17 Jun 2019 16:58:47 +0200 Message-ID: Subject: Re: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup To: Michal Simek Cc: Manish Narani , Rob Herring , Mark Rutland , Adrian Hunter , rajan.vaja@xilinx.com, jolly.shah@xilinx.com, nava.manne@xilinx.com, Olof Johansson , "linux-mmc@vger.kernel.org" , DTML , Linux Kernel Mailing List , Linux ARM 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 [...] > >> > >> > >>> In regards to the mmc data part, I suggest to drop the > >>> ->set_tap_delay() callback, but rather use a boolean flag to indicate > >>> whether clock phases needs to be changed for the variant. Potentially > >>> that could even be skipped and instead call clk_set_phase() > >>> unconditionally, as the clock core deals fine with clock providers > >>> that doesn't support the ->set_phase() callback. > >> > >> In connection to another version of this driver for latest Xilinx chip > >> it would be better to keep set_tap_delay callback in the driver. The > >> reason is that new chip/ip is capable to setup tap delays directly > >> without asking firmware to do it. That's why for versal IP there is a > >> need to call different setup_tap_delay function. > > > > The ->set_tap_delay() callback is for ZyncMp pointing to > > sdhci_arasan_zynqmp_set_tap_delay(). This function calls the > > clk_set_phase() API. > > > > What does ->set_tap_delay() do for the latest version? > > There is different set of default tap delays which should be programmed > and it is done just via writing to registers which are the part of > controller address space. Okay, I see. Not sure what makes most sense to do here, but it sounds to me like another ->set_phase() callback should be implemented for the clock provider. In other words, calling clk_set_phase() should continue to works just fine for this case as well. If it turns out to be inconvenient, we can always add the ->set_tap_delay() at a later point when it makes more sense. [...] Kind regards Uffe