From: Adrian Hunter <adrian.hunter@intel.com>
To: Raul Rangel <rrangel@chromium.org>
Cc: "Shah, Nehal-bakulchandra" <Nehal-bakulchandra.Shah@amd.com>,
"Wang, Chris" <chris.wang@amd.com>,
Akshu Agrawal <Akshu.Agrawal@amd.com>,
Jisheng Zhang <jszhang@marvell.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
clang-built-linux@googlegroups.com,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mmc@vger.kernel.org
Subject: Re: [PATCH v2] mmc: sdhci: Don't enable presets while tuning
Date: Fri, 25 Sep 2020 12:31:50 +0300 [thread overview]
Message-ID: <c4a886d8-8389-2c50-a40b-e2965ef6c393@intel.com> (raw)
In-Reply-To: <CAHQZ30DXUuWKo1n50aX3a86QfLCD4Z3W4CVescRDFcvQrEk3Ww@mail.gmail.com>
On 18/09/20 8:57 pm, Raul Rangel wrote:
> On Tue, Sep 1, 2020 at 4:54 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>
>> On 24/08/20 9:21 pm, Raul E Rangel wrote:
>>> SDHCI presets are not currently used for eMMC HS/HS200/HS400, but are
>>> used for DDR52. The HS400 retuning sequence is:
>>>
>>> HS400->DDR52->HS->HS200->Perform Tuning->HS->HS400
>>>
>>> This means that when HS400 tuning happens, we transition through DDR52
>>> for a very brief period. This causes presets to be enabled
>>> unintentionally and stay enabled when transitioning back to HS200 or
>>> HS400.
>>>
>>> This patch prevents enabling presets while tuning is in progress.
>>
>> Preset value should not generally have to depend on tuning, so this
>> seems less than ideal. Also I am not sure you can say some controllers
>> are not accidentally benefiting from the current situation.
>>
>> What about just letting drivers choose the timing modes that support
>> preset values? e.g. using the change below, a driver could alter
>> host->preset_value_support as needed
>
> Sorry for the late reply, I'm just getting back to this. I like the
> patch. I have a few other patches I'm
> going to push up soon. Do you want me to include this in the chain, or
> do you want to push it up?
I'm snowed. You will have to do it I am afraid.
prev parent reply other threads:[~2020-09-25 9:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 18:21 Raul E Rangel
2020-09-01 10:53 ` Adrian Hunter
2020-09-18 17:57 ` Raul Rangel
2020-09-25 9:31 ` Adrian Hunter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c4a886d8-8389-2c50-a40b-e2965ef6c393@intel.com \
--to=adrian.hunter@intel.com \
--cc=Akshu.Agrawal@amd.com \
--cc=Nehal-bakulchandra.Shah@amd.com \
--cc=chris.wang@amd.com \
--cc=clang-built-linux@googlegroups.com \
--cc=jszhang@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=rrangel@chromium.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®