<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/mmc, branch v5.9.12</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.9.12</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.9.12'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-11-24T12:39:14+00:00</updated>
<entry>
<title>mmc: sdhci-of-arasan: Issue DLL reset explicitly</title>
<updated>2020-11-24T12:39:14+00:00</updated>
<author>
<name>Manish Narani</name>
<email>manish.narani@xilinx.com</email>
</author>
<published>2020-11-16T08:32:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=74b00ca221d2bd20c16bd82d4f711d04cb044714'/>
<id>urn:sha1:74b00ca221d2bd20c16bd82d4f711d04cb044714</id>
<content type='text'>
commit d06d60d52ec0b0eef702dd3e7b4699f0b589ad0f upstream.

In the current implementation DLL reset will be issued for
each ITAP and OTAP setting inside ATF, this is creating issues
in some scenarios and this sequence is not inline with the TRM.
To fix the issue, DLL reset should be removed from the ATF and
host driver will request it explicitly.
This patch update host driver to explicitly request for DLL reset
before ITAP (assert DLL) and after OTAP (release DLL) settings.

Fixes: a5c8b2ae2e51 ("mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup")
Signed-off-by: Sai Krishna Potthuri &lt;lakshmi.sai.krishna.potthuri@xilinx.com&gt;
Signed-off-by: Manish Narani &lt;manish.narani@xilinx.com&gt;
Acked-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1605515565-117562-4-git-send-email-manish.narani@xilinx.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-of-arasan: Use Mask writes for Tap delays</title>
<updated>2020-11-24T12:39:14+00:00</updated>
<author>
<name>Manish Narani</name>
<email>manish.narani@xilinx.com</email>
</author>
<published>2020-11-16T08:32:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac571d62fccb765c2bbc19280c593aca17d7317c'/>
<id>urn:sha1:ac571d62fccb765c2bbc19280c593aca17d7317c</id>
<content type='text'>
commit d338c6d01dc614cad253d6c042501fa0eb242d5c upstream.

Mask the ITAP and OTAP delay bits before updating with the new
tap value for Versal platform.

Fixes: 1a470721c8f5 ("sdhci: arasan: Add support for Versal Tap Delays")
Signed-off-by: Sai Krishna Potthuri &lt;lakshmi.sai.krishna.potthuri@xilinx.com&gt;
Signed-off-by: Manish Narani &lt;manish.narani@xilinx.com&gt;
Acked-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1605515565-117562-3-git-send-email-manish.narani@xilinx.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-of-arasan: Allow configuring zero tap values</title>
<updated>2020-11-24T12:39:14+00:00</updated>
<author>
<name>Manish Narani</name>
<email>manish.narani@xilinx.com</email>
</author>
<published>2020-11-16T08:32:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fbbe94e5c743a8ea31c0fefe49f36775c17dc08b'/>
<id>urn:sha1:fbbe94e5c743a8ea31c0fefe49f36775c17dc08b</id>
<content type='text'>
commit 9e9534329306fcd7ea1b84f14860a3c04ebe7f1a upstream.

Allow configuring the Output and Input tap values with zero to avoid
failures in some cases (one of them is SD boot mode) where the output
and input tap values may be already set to non-zero.

Fixes: a5c8b2ae2e51 ("mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup")
Signed-off-by: Sai Krishna Potthuri &lt;lakshmi.sai.krishna.potthuri@xilinx.com&gt;
Signed-off-by: Manish Narani &lt;manish.narani@xilinx.com&gt;
Acked-by: Michal Simek &lt;michal.simek@xilinx.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1605515565-117562-2-git-send-email-manish.narani@xilinx.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-pci: Prefer SDR25 timing for High Speed mode for BYT-based Intel controllers</title>
<updated>2020-11-24T12:39:13+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2020-11-12T13:36:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fd49156dc81b7934c67fff0cc99741336c2b22be'/>
<id>urn:sha1:fd49156dc81b7934c67fff0cc99741336c2b22be</id>
<content type='text'>
commit 60d53566100abde4acc5504b524bc97f89015690 upstream.

A UHS setting of SDR25 can give better results for High Speed mode.
This is because there is no setting corresponding to high speed.  Currently
SDHCI sets no value, which means zero which is also the setting for SDR12.
There was an attempt to change this in sdhci.c but it caused problems for
some drivers, so it was reverted and the change was made to sdhci-brcmstb
in commit 2fefc7c5f7d16e ("mmc: sdhci-brcmstb: Fix incorrect switch to HS
mode").  Several other drivers also do this.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org # v5.4+
Link: https://lore.kernel.org/r/20201112133656.20317-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: renesas_sdhi_core: Add missing tmio_mmc_host_free() at remove</title>
<updated>2020-11-18T18:22:29+00:00</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2020-11-06T09:25:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=33edb616f3ce7de25c775f0782cb732bf6c7a965'/>
<id>urn:sha1:33edb616f3ce7de25c775f0782cb732bf6c7a965</id>
<content type='text'>
commit e8973201d9b281375b5a8c66093de5679423021a upstream.

The commit 94b110aff867 ("mmc: tmio: add tmio_mmc_host_alloc/free()")
added tmio_mmc_host_free(), but missed the function calling in
the sh_mobile_sdhi_remove() at that time. So, fix it. Otherwise,
we cannot rebind the sdhi/mmc devices when we use aliases of mmc.

Fixes: 94b110aff867 ("mmc: tmio: add tmio_mmc_host_alloc/free()")
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Reviewed-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Tested-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Reviewed-by: Niklas Söderlund &lt;niklas.soderlund+renesas@ragnatech.se&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1604654730-29914-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-of-esdhc: Handle pulse width detection erratum for more SoCs</title>
<updated>2020-11-18T18:22:29+00:00</updated>
<author>
<name>Yangbo Lu</name>
<email>yangbo.lu@nxp.com</email>
</author>
<published>2020-11-10T07:13:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85db3a44309410aca8d0c6f7970d56d035cfae61'/>
<id>urn:sha1:85db3a44309410aca8d0c6f7970d56d035cfae61</id>
<content type='text'>
commit 71b053276a87ddfa40c8f236315d81543219bfb9 upstream.

Apply erratum workaround of unreliable pulse width detection to
more affected platforms (LX2160A Rev2.0 and LS1028A Rev1.0).

Signed-off-by: Yangbo Lu &lt;yangbo.lu@nxp.com&gt;
Fixes: 48e304cc1970 ("mmc: sdhci-of-esdhc: workaround for unreliable pulse width detection")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201110071314.3868-1-yangbo.lu@nxp.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci: Use Auto CMD Auto Select only when v4_mode is true</title>
<updated>2020-11-05T10:51:53+00:00</updated>
<author>
<name>Jisheng Zhang</name>
<email>Jisheng.Zhang@synaptics.com</email>
</author>
<published>2020-10-15T09:41:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54ba7d5296b9d09ba7788ca412e2f988d726618d'/>
<id>urn:sha1:54ba7d5296b9d09ba7788ca412e2f988d726618d</id>
<content type='text'>
commit b3e1ea16fb39fb6e1a1cf1dbdd6738531de3dc7d upstream.

sdhci-of-dwcmshc meets an eMMC read performance regression with below
command after commit 427b6514d095 ("mmc: sdhci: Add Auto CMD Auto
Select support"):

dd if=/dev/mmcblk0 of=/dev/null bs=8192 count=100000

Before the commit, the above command gives 120MB/s
After the commit, the above command gives 51.3 MB/s

So it looks like sdhci-of-dwcmshc expects Version 4 Mode for Auto
CMD Auto Select. Fix the performance degradation by ensuring v4_mode
is true to use Auto CMD Auto Select.

Fixes: 427b6514d095 ("mmc: sdhci: Add Auto CMD Auto Select support")
Signed-off-by: Jisheng Zhang &lt;Jisheng.Zhang@synaptics.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201015174115.4cf2c19a@xhacker.debian
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-of-esdhc: set timeout to max before tuning</title>
<updated>2020-11-05T10:51:52+00:00</updated>
<author>
<name>Michael Walle</name>
<email>michael@walle.cc</email>
</author>
<published>2020-10-22T22:23:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f75a51933d12b9a0bbe5b682a9bc3ccf19ab8865'/>
<id>urn:sha1:f75a51933d12b9a0bbe5b682a9bc3ccf19ab8865</id>
<content type='text'>
commit 0add6e9b88d0632a25323aaf4987dbacb0e4ae64 upstream.

On rare occations there is the following error:

  mmc0: Tuning timeout, falling back to fixed sampling clock

There are SD cards which takes a significant longer time to reply to the
first CMD19 command. The eSDHC takes the data timeout value into account
during the tuning period. The SDHCI core doesn't explicitly set this
timeout for the tuning procedure. Thus on the slow cards, there might be
a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong
sequence of events. In the end this will lead to an unsuccessful tuning
procedure and to the above error.

To workaround this, set the timeout to the maximum value (which is the
best we can do) and the SDHCI core will take care of the proper timeout
handling.

Fixes: ba49cbd0936e ("mmc: sdhci-of-esdhc: add tuning support")
Signed-off-by: Michael Walle &lt;michael@walle.cc&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201022222337.19857-1-michael@walle.cc
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-of-esdhc: make sure delay chain locked for HS400</title>
<updated>2020-11-05T10:51:52+00:00</updated>
<author>
<name>Yangbo Lu</name>
<email>yangbo.lu@nxp.com</email>
</author>
<published>2020-10-20T08:11:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bbca4ddb9a766f98372bd3db496b84f3aca598a0'/>
<id>urn:sha1:bbca4ddb9a766f98372bd3db496b84f3aca598a0</id>
<content type='text'>
commit 011fde48394b7dc8dfd6660d1013b26a00157b80 upstream.

For eMMC HS400 mode initialization, the DLL reset is a required step
if DLL is enabled to use previously, like in bootloader.
This step has not been documented in reference manual, but the RM will
be fixed sooner or later.

This patch is to add the step of DLL reset, and make sure delay chain
locked for HS400.

Signed-off-by: Yangbo Lu &lt;yangbo.lu@nxp.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20201020081116.20918-1-yangbo.lu@nxp.com
Fixes: 54e08d9a95ca ("mmc: sdhci-of-esdhc: add hs400 mode support")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: sdhci-acpi: AMDI0040: Set SDHCI_QUIRK2_PRESET_VALUE_BROKEN</title>
<updated>2020-11-05T10:51:31+00:00</updated>
<author>
<name>Raul E Rangel</name>
<email>rrangel@chromium.org</email>
</author>
<published>2020-09-28T21:59:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d1c891a108597508809733f70736bc51606e2891'/>
<id>urn:sha1:d1c891a108597508809733f70736bc51606e2891</id>
<content type='text'>
commit f23cc3ba491af77395cea3f9d51204398729f26b upstream.

This change fixes HS400 tuning for devices with invalid presets.

SDHCI presets are not currently used for eMMC HS/HS200/HS400, but are
used for DDR52. The HS400 retuning sequence is:

    HS400-&gt;DDR52-&gt;HS-&gt;HS200-&gt;Perform Tuning-&gt;HS-&gt;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. Some firmware has invalid presets, so we end up with driver
strengths that can cause I/O problems.

Fixes: 34597a3f60b1 ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400")
Signed-off-by: Raul E Rangel &lt;rrangel@chromium.org&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200928154718.1.Icc21d4b2f354e83e26e57e270dc952f5fe0b0a40@changeid
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
