On Mon, 10 Dec 2018 at 15:04, Faiz Abbas <faiz_abbas@xxxxxx> wrote: > > Hi, > > On 10/12/18 7:15 PM, Ulf Hansson wrote: > > On Mon, 10 Dec 2018 at 14:23, Faiz Abbas <faiz_abbas@xxxxxx> wrote: > >> > >> Hi Uffe, > >> > >> On 05/12/18 7:20 PM, Ulf Hansson wrote: > >>> On Fri, 30 Nov 2018 at 06:53, Faiz Abbas <faiz_abbas@xxxxxx> wrote: > >>>> > >>>> Hi Kishon, > >>>> > >>>> On 30/11/18 10:10 AM, Kishon Vijay Abraham I wrote: > >>>>> Hi Faiz, > >>>>> > >>>>> On 30/11/18 12:35 AM, Faiz Abbas wrote: > >>>>>> Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions > >>>>>> (SPRZ426D - November 2014 - Revised February 2018 [1]) mentions > >>>>>> unexpected tuning pattern errors. A small failure band may be present > >>>>>> in the tuning range which may be missed by the current algorithm. > >>>>>> Furthermore, the failure bands vary with temperature leading to > >>>>>> different optimum tuning values for different temperatures. > >>>>>> > >>>>>> As suggested in the related Application Report (SPRACA9B - October 2017 > >>>>>> - Revised July 2018 [2]), tuning should be done in two stages. > >>>>>> In stage 1, assign the optimum ratio in the maximum pass window for the > >>>>>> current temperature. In stage 2, if the chosen value is close to the > >>>>>> small failure band, move away from it in the appropriate direction. > >>>>>> > >>>>>> References: > >>>>>> [1] http://www.ti.com/lit/pdf/sprz426 > >>>>>> [2] http://www.ti.com/lit/pdf/SPRACA9 > >>>>>> > >>>>>> Signed-off-by: Faiz Abbas <faiz_abbas@xxxxxx> > >>>>>> --- > ... > >>>>> > >>>>> Can't we get thermal zone once during probe? > >>>>> > >>>> > >>>> Tuning is also (ideally) supposed to happen only once per enumeration. > >>>> Also it doesn't make sense to get a thermal zone for lower speed systems > >>>> that won't do tuning. > >>> > >>> Currently sdhci-omap calls pm_runtime_get_sync() during probe, and > >>> then keeps the host device runtime resumed until ->remove() is called > >>> on it. I assume you are going to change that, at some point!? > >>> > >>> In other words, what will happen to the host device when it becomes > >>> runtime suspended? Is re-tuning needed when it gets runtime resumed, > >>> which is the case for many other sdhci variants? > >> > >> There are no plans to support runtime_suspend()/resume() any time in the > >> near future. If its ok with you, I would like to get this patch in > >> without any changes. We can change it in case a need for > >> runtime_suspend()/_resume() does arise. > > > > Right, I am okay with that. Due to recent changes to sdhci-omap > > $subject patch doesn't apply, can you please rebase!? > > > > Additionally, I realized that we should fold in patch updating the DT > > doc for sdhci-omap, adding the property for the thermal zone. I > > regards to that, I am wondering if "cpu_thermal", is really the > > correct name of the zone. The point is, I am guessing the zone could > > change along with the SoCs/platforms. > > > > As you have probably noticed, we are introducing a new driver > (sdhci_am654) for newer platforms. I don't foresee using sdhci-omap > driver with any other platforms. In case we do use it, we can add the dt > property at that point of time and default to "cpu_thermal" to maintain > dt compatibility. > > Will rebase and send v2 if you are ok with above. I see, but you still need to update the DT doc for sdhci-omap. Kind regards Uffe
