linux-kernel - Re: [PATCH] mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Dec 2018 17:56:36 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Faiz Abbas <faiz_abbas@...com>
Cc:     Kishon <kishon@...com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH] mmc: sdhci-omap: Workaround errata regarding SDR104/HS200
 tuning failures (i929)

On Mon, 10 Dec 2018 at 17:43, Faiz Abbas <faiz_abbas@...com> wrote:
>
> Hi,
>
> On 10/12/18 8:55 PM, Ulf Hansson wrote:
> > On Mon, 10 Dec 2018 at 15:04, Faiz Abbas <faiz_abbas@...com> wrote:
> >>
> >> Hi,
> >>
> >> On 10/12/18 7:15 PM, Ulf Hansson wrote:
> >>> On Mon, 10 Dec 2018 at 14:23, Faiz Abbas <faiz_abbas@...com> 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@...com> 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@...com>
> >>>>>>>> ---
> >> ...
> >>>>>>>
> >>>>>>> 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.
> >
>
> I didn't get you. There are no changes in dt. What changes should I
> document?

Well, you are fetching a thermal zone using a specific name. It's
quite similar to how we document other resources (pinctrls for
example) that sdhci omap depends on, so that needs to be document too.

Kind regards
Uffe