lkml.org 
[lkml]   [2017]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [v2 PATCH 3/3] mmc: sdhci-cadence: Update PHY delay configuration
Date


> -----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.
>
>
>
>
> > 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
\
 
 \ /
  Last update: 2017-03-20 09:39    [W:0.140 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site