<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/mmc/host, branch v4.9.2</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>mmc: sdhci: Fix recovery from tuning timeout</title>
<updated>2017-01-09T07:32:17+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-12-02T13:14:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cee935845420e2ffe81293d396ad44a5630ba743'/>
<id>cee935845420e2ffe81293d396ad44a5630ba743</id>
<content type='text'>
commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Tested-by: Dan O'Donovan &lt;dan@emutex.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Tested-by: Dan O'Donovan &lt;dan@emutex.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "mmc: sdhci: Reset cmd and data circuits after tuning failure"</title>
<updated>2017-01-09T07:32:17+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-12-02T13:14:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5bb425033ef1783eec0a40d3846dca5a5e2c03a8'/>
<id>5bb425033ef1783eec0a40d3846dca5a5e2c03a8</id>
<content type='text'>
commit 2ca71c27eeaeddae38efe24a84b20e22708a3d1d upstream.

This reverts commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits
after tuning failure").

A better fix is available, and it will be applied to older stable releases,
so get this out of the way by reverting it.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2ca71c27eeaeddae38efe24a84b20e22708a3d1d upstream.

This reverts commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits
after tuning failure").

A better fix is available, and it will be applied to older stable releases,
so get this out of the way by reverting it.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: dw_mmc: fix the error handling for dma operation</title>
<updated>2016-11-21T10:08:28+00:00</updated>
<author>
<name>Jaehoon Chung</name>
<email>jh80.chung@samsung.com</email>
</author>
<published>2016-11-21T01:51:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=647f80a1f233bb66fc58fb25664d029e0f12f3ae'/>
<id>647f80a1f233bb66fc58fb25664d029e0f12f3ae</id>
<content type='text'>
When dma-&gt;start is failed,then it has to fall back to PIO mode
for current transfer.

But Host controller was already set to bits relevant to DMA operation.
If needs to use the PIO mode, Host controller has to stop the DMA
operation. (It's more stable than now.)

When it occurred error, it's not running any request.

Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support")
Reported-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.3+
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When dma-&gt;start is failed,then it has to fall back to PIO mode
for current transfer.

But Host controller was already set to bits relevant to DMA operation.
If needs to use the PIO mode, Host controller has to stop the DMA
operation. (It's more stable than now.)

When it occurred error, it's not running any request.

Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support")
Reported-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.3+
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-of-esdhc: fixup PRESENT_STATE read</title>
<updated>2016-11-18T13:41:47+00:00</updated>
<author>
<name>Michael Walle</name>
<email>michael@walle.cc</email>
</author>
<published>2016-11-15T10:13:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b0921d5c9ed6ffa8a4d6afc5ee5f136b87445f14'/>
<id>b0921d5c9ed6ffa8a4d6afc5ee5f136b87445f14</id>
<content type='text'>
Since commit 87a18a6a5652 ("mmc: mmc: Use -&gt;card_busy() to detect busy
cards in __mmc_switch()") the ESDHC driver is broken:
  mmc0: Card stuck in programming state! __mmc_switch
  mmc0: error -110 whilst initialising MMC card

Since this commit __mmc_switch() uses -&gt;card_busy(), which is
sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
PRESENT_STATE register, specifically the DAT0 signal level bit. But the
ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
required to make the driver work again.

Signed-off-by: Michael Walle &lt;michael@walle.cc&gt;
Fixes: 87a18a6a5652 ("mmc: mmc: Use -&gt;card_busy() to detect busy cards in __mmc_switch()")
Acked-by: Yangbo Lu &lt;yangbo.lu@nxp.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.8+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since commit 87a18a6a5652 ("mmc: mmc: Use -&gt;card_busy() to detect busy
cards in __mmc_switch()") the ESDHC driver is broken:
  mmc0: Card stuck in programming state! __mmc_switch
  mmc0: error -110 whilst initialising MMC card

Since this commit __mmc_switch() uses -&gt;card_busy(), which is
sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
PRESENT_STATE register, specifically the DAT0 signal level bit. But the
ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
required to make the driver work again.

Signed-off-by: Michael Walle &lt;michael@walle.cc&gt;
Fixes: 87a18a6a5652 ("mmc: mmc: Use -&gt;card_busy() to detect busy cards in __mmc_switch()")
Acked-by: Yangbo Lu &lt;yangbo.lu@nxp.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.8+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: mxs: Initialize the spinlock prior to using it</title>
<updated>2016-11-07T12:30:08+00:00</updated>
<author>
<name>Fabio Estevam</name>
<email>fabio.estevam@nxp.com</email>
</author>
<published>2016-11-05T19:45:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f91346e8b5f46aaf12f1df26e87140584ffd1b3f'/>
<id>f91346e8b5f46aaf12f1df26e87140584ffd1b3f</id>
<content type='text'>
An interrupt may occur right after devm_request_irq() is called and
prior to the spinlock initialization, leading to a kernel oops,
as the interrupt handler uses the spinlock.

In order to prevent this problem, move the spinlock initialization
prior to requesting the interrupts.

Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
An interrupt may occur right after devm_request_irq() is called and
prior to the spinlock initialization, leading to a kernel oops,
as the interrupt handler uses the spinlock.

In order to prevent this problem, move the spinlock initialization
prior to requesting the interrupts.

Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci: Fix missing enhanced strobe setting during runtime resume</title>
<updated>2016-11-07T12:26:43+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-11-02T13:49:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=086b0ddbeff5317026417c29752129d28a216c66'/>
<id>086b0ddbeff5317026417c29752129d28a216c66</id>
<content type='text'>
Restore enhanced strobe setting during runtime resume.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Restore enhanced strobe setting during runtime resume.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci: Reset cmd and data circuits after tuning failure</title>
<updated>2016-11-07T12:26:43+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-11-02T13:49:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fe5fb2e3b58f866f82a80fe7c7866ea6d0b306b9'/>
<id>fe5fb2e3b58f866f82a80fe7c7866ea6d0b306b9</id>
<content type='text'>
To prevent subsequent commands failing, ensure the cmd and data circuits
are reset after a tuning timeout.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To prevent subsequent commands failing, ensure the cmd and data circuits
are reset after a tuning timeout.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci: Fix unexpected data interrupt handling</title>
<updated>2016-11-07T12:26:42+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-11-02T13:49:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=69b962a65a547690a356f9f76bc4f53db538ac49'/>
<id>69b962a65a547690a356f9f76bc4f53db538ac49</id>
<content type='text'>
In the busy response case (i.e. !host-&gt;data), an unexpected data interrupt
would result in clearing the data command as though it had completed but
without informing the upper layers and thus resulting in a hang.  Fix by
only clearing the data command for data interrupts that are expected.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the busy response case (i.e. !host-&gt;data), an unexpected data interrupt
would result in clearing the data command as though it had completed but
without informing the upper layers and thus resulting in a hang.  Fix by
only clearing the data command for data interrupts that are expected.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci: Fix CMD line reset interfering with ongoing data transfer</title>
<updated>2016-11-07T12:26:42+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-11-02T13:49:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6ebebeab5185f50d55c6a24d0abe47e5dac1b191'/>
<id>6ebebeab5185f50d55c6a24d0abe47e5dac1b191</id>
<content type='text'>
CMD line reset during an ongoing data transfer can cause the data transfer
to hang.  Fix by delaying the reset until the data transfer is finished.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CMD line reset during an ongoing data transfer can cause the data transfer
to hang.  Fix by delaying the reset until the data transfer is finished.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: dw_mmc: add the "reset" as name of reset controller</title>
<updated>2016-11-07T07:53:46+00:00</updated>
<author>
<name>Jaehoon Chung</name>
<email>jh80.chung@samsung.com</email>
</author>
<published>2016-10-31T02:49:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3a667e3ff78ae81afc49343c753864cc1ede2f77'/>
<id>3a667e3ff78ae81afc49343c753864cc1ede2f77</id>
<content type='text'>
Add the "reset" as name of reset controller.
This is for preventing the wrong operation. Even if some SoC has reset
controller, doesn't define "resets" in device-tree.
Then it might be waiting for reset controller and it should be stuck.

Fixes: d6786fefe816 ("mmc: dw_mmc: add reset support to dwmmc host controller")
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Acked-by: John Stultz &lt;john.stultz@linaro.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add the "reset" as name of reset controller.
This is for preventing the wrong operation. Even if some SoC has reset
controller, doesn't define "resets" in device-tree.
Then it might be waiting for reset controller and it should be stuck.

Fixes: d6786fefe816 ("mmc: dw_mmc: add reset support to dwmmc host controller")
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Acked-by: John Stultz &lt;john.stultz@linaro.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
