Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp775410ybi; Wed, 19 Jun 2019 07:41:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxlFJWgIZs0CTNA3raIMVi3ugTb3jJU7I1FELCEAVulmiOUrHHlIK+ZdQZu56vfiLcj9FWs X-Received: by 2002:a17:902:8489:: with SMTP id c9mr39758781plo.327.1560955297739; Wed, 19 Jun 2019 07:41:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560955297; cv=none; d=google.com; s=arc-20160816; b=zNvtMTqyIYJcn0Dom+Gqisy53Wvc3SaflfpgBPhDW2xbSvOK08LfNaxAjA8CxfFjPm M7hPpZ/hsj8OO4Te00+ymBaPoN3F0dL4SLB5Sf5HuMGdTbVN+PVX0oaHEyr8W865BjR6 5N7b/XoCS/VuGNtfXaLOqzYiNESiPfzf++pmQ3fvKiI8jBGizqlEQGlM/oBhiStkjymv Tz4m/t6O4gMHoLZMZXBltxNZ14FB6S2J6wti+Iu19pD1cWZzZ9WqP2M+A9k37YDyPuPp CMAShOj5KF3bIFR7po5NwOMosCS+T9P1RyhNRj6jScNj2G7hyjoVkNPtrD5MhpJZVJt8 6gTQ== 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=OuL65TuVUonkfDYC+yc+qXGA89Xa2MqrM+C9nMr53yk=; b=de5nj1oYwUx0LG78WalXkXqW87XWjj6MfycgmU+X4iMU1ZI0FtAdMgPTsG1LhT6Myu 8iE9Cy51z4gMFS/X5nD5d/yfP7s97VDK1Oo3I6lAl3JYwjWxvjqTWhyBFfsyvKUpmHU9 Wfens84GaVKNJWClnGGwpmpxKcLDWOTLnjDAvlwJKqsk35sdBxsOAGgu9Cb+NVU+BPr1 SStNl+9WLkUm62G2fFuQkB0sw/PuRnzEdj7GFexAYdGN3IsFbaEt54nysjvVNKWRoZd1 FpmVHEP6oqJk9QU8Co7kLmuKkBuJbMhaWzj3kL04UIzw8yYKQQ6CzrJaCiusmY6Ypu8P tKww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=z50UkcJ9; 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 k1si3076947pgq.175.2019.06.19.07.41.21; Wed, 19 Jun 2019 07:41:37 -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=z50UkcJ9; 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 S1729468AbfFSOlO (ORCPT + 99 others); Wed, 19 Jun 2019 10:41:14 -0400 Received: from mail-ua1-f65.google.com ([209.85.222.65]:46477 "EHLO mail-ua1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727552AbfFSOlN (ORCPT ); Wed, 19 Jun 2019 10:41:13 -0400 Received: by mail-ua1-f65.google.com with SMTP id o19so10031820uap.13 for ; Wed, 19 Jun 2019 07:41:13 -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=OuL65TuVUonkfDYC+yc+qXGA89Xa2MqrM+C9nMr53yk=; b=z50UkcJ9gf1Qmb0DTS3m0F60LXoKl9Uj4ZE8Y69bTITcVx9kxGwD+yUakZDgenUpMM MiLeZcvrSH41/V/cUogSecHNER0CvlIhvkiHNy5EJfw26PP0BzvukiV/lUlbZwUKN1In ueCcx0vPNC99LiCjH2KzgxVVXbor3azuonwTyx42gSTn7BQS+ALSzjZln+iIwctYArf4 3PRJSa5Dp8WSlmBfV833+QccgrJMI9y5SZ8VmxWswoUCIlYbonz8KYJeQkUn6dxgz9Fl CYuWXwN2IGOrGGpCkJQIqsLEV/9T5TYERWJuRM5ICOL/hkav+FCiKs++ovFs8Mxev8Qs /U0Q== 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=OuL65TuVUonkfDYC+yc+qXGA89Xa2MqrM+C9nMr53yk=; b=pWmelf/Br30tiuYYWAuzzT0Z5u6OoGhcr/P1qXRE28Z3bWXLu9TW9sd8Kvl9K2Ewhx 43Iqi2y07qeTzTUW2Bp5O0l5+8LoFSO/owXcbxgakT0UfBYvPQqL4nBq9AQdPRlUX1fH SDRG05vXizzb4DN0GgCtKCJjOePmV/TgTb1w8IOIA8YuG+231MeFLXoQWOU2vJ3HezyE UJD+9f2O/PqBxTs+pt63Tuq1g7QmwOmtRBsSNd05Y5R/njHT80qZKX9TCENry88w7Rsl Y4a058R0whjJLMGYUNXuVI/LgUjxVW7iP6kbNybCLMQNx06iY5G4Gu6Xzfo6F9j4eFHi kVzg== X-Gm-Message-State: APjAAAXPvWnmH6gkDdJePvJScZXDEB9hA6nDMiWr89BNLUNgOv/uHv/B 5TqAbHo2O3+qOVEGIrYDwW3rblfUc76Ret/Nz8jBxg== X-Received: by 2002:a9f:31a2:: with SMTP id v31mr14379202uad.15.1560955272797; Wed, 19 Jun 2019 07:41:12 -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: From: Ulf Hansson Date: Wed, 19 Jun 2019 16:40:36 +0200 Message-ID: Subject: Re: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup To: Manish Narani Cc: Michal Simek , Rob Herring , Mark Rutland , Adrian Hunter , Rajan Vaja , Jolly Shah , Nava kishore Manne , 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 On Tue, 18 Jun 2019 at 06:59, Manish Narani wrote: > > Hi Uffe, > > Thanks for the review. Please find my comments below. > > > -----Original Message----- > > From: Ulf Hansson > > Sent: Monday, June 17, 2019 8:29 PM > > To: Michal Simek > > Cc: Manish Narani ; Rob Herring > > ; Mark Rutland ; Adrian > > Hunter ; Rajan Vaja ; Jolly > > Shah ; Nava kishore Manne ; Olof > > Johansson ; linux-mmc@vger.kernel.org; DTML > > ; Linux Kernel Mailing List > kernel@vger.kernel.org>; Linux ARM > > Subject: Re: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP > > Platform Tap Delays Setup > > > > [...] > > > > > >> > > > >> > > > >>> 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 the current implementation, I am taking care of both the input and > output clock delays with the single clock (which is output clock) registration > and differentiating these tap delays based on their values > (<256 then input delay and >= 256 then output delay), because that is > zynqmp specific. If we want to make this generic, we may need to > register 'another' clock which will be there as an input (sampling) clock > and then we can make this 'clk_set_phase()' be called unconditionally > each for both the clocks and let the platforms handle their clock part. > What's your take on this? Not sure exactly what you are suggesting, but my gut feeling says it sounds good. How is tap delays managed for both the input clock and the output clock? Is some managed by the clock provider (which is probably firmware in your case) and some managed by the MMC controller? [...] Kind regards Uffe