Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755975AbdC2MFA (ORCPT ); Wed, 29 Mar 2017 08:05:00 -0400 Received: from mga06.intel.com ([134.134.136.31]:5889 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752499AbdC2MEl (ORCPT ); Wed, 29 Mar 2017 08:04:41 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,241,1486454400"; d="scan'208";a="949374437" Subject: Re: [v2 PATCH 3/3] mmc: sdhci-cadence: Update PHY delay configuration To: Piotr Sroka , Masahiro Yamada References: <1488807587-5375-1-git-send-email-piotrs@cadence.com> Cc: linux-mmc , Ulf Hansson , Linux Kernel Mailing List From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: <040f3ee3-d715-3696-4f35-6f5b77b6b984@intel.com> Date: Wed, 29 Mar 2017 14:59:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1812 Lines: 52 On 20/03/17 10:38, Piotr Sroka wrote: > > >> -----Original Message----- >> From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com] >> Sent: 17 March, 2017 6:23 PM >> Subject: Re: [v2 PATCH 3/3] mmc: sdhci-cadence: Update PHY delay configuration >> >> Hi Piotr, >> >> Sorry for my late reply. >> >> >>> >>> It looks that "input delays" and "DLL sdclk delays" should be defined in dts file because they depend on a chip and a board >> implementation. On the other hand the less dts properties the better. >>> >>> There is one more way to handle input delays. It can be achieved by PHY training. PHY training is similar to the tuning and it should be >> done when proper timing mode is selected and clock frequency is set. >>> To make it possible the sdhci_set_ios function need to be global. Then I could create sdhci_cdns_set_ios function as follows: >>> void sdhci_cdns_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) { >>> . . . >>> >>> sdhci_set_ios(mmc, ios); >>> /* execute PHY training if needed */ >>> sdhci_cdns_exec_phy_training(host); >>> } >>> >>> The mmc framework configures timing and frequency separately so PHY training should be executed every time if timing or clock >> frequency is changed. I am not sure If I can change sdhci_set_ios to global function. >> >> >> I am OK with this, but I hope Adrian can advise us. There is no problem exporting sdhci_set_ios() >> >> >> >> >>> So maybe put all delays to dts file would be a better solution? What do you think? >> >> I am OK with DT approach too >> because this way seems simpler, after all. >> >> (My suggestion for data array approach was misleading, sorry.) >> > Thanks for review anyway it was useful. Now decision between DTS and data array is more clear for me. > > Regards > Piotr Sroka >