[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <040f3ee3-d715-3696-4f35-6f5b77b6b984@intel.com>
Date: Wed, 29 Mar 2017 14:59:05 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Piotr Sroka <piotrs@...ence.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc: linux-mmc <linux-mmc@...r.kernel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [v2 PATCH 3/3] mmc: sdhci-cadence: Update PHY delay configuration
On 20/03/17 10:38, Piotr Sroka wrote:
>
>
>> -----Original Message-----
>> From: Masahiro Yamada [mailto:yamada.masahiro@...ionext.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
>
Powered by blists - more mailing lists