<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/include/linux/mmc, branch v4.3</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>mmc: block: skip trim for some kingston eMMCs</title>
<updated>2015-08-27T12:50:52+00:00</updated>
<author>
<name>Shawn Lin</name>
<email>shawn.lin@rock-chips.com</email>
</author>
<published>2015-08-12T05:08:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b5b4ff0a633910b2b9dca7915fd6ab17aa10dc3e'/>
<id>b5b4ff0a633910b2b9dca7915fd6ab17aa10dc3e</id>
<content type='text'>
For some mass production of kingston eMMCs which adopt Phison's
firmware will meet an unrecoverable data conrruption occasionally
if performing trim due to a firmware bug confirmed by vendor. We
found it on Intel-C3230RK platform. So we add fixup of broken trim
for it.

Signed-off-by: Shawn Lin &lt;shawn.lin@rock-chips.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>
For some mass production of kingston eMMCs which adopt Phison's
firmware will meet an unrecoverable data conrruption occasionally
if performing trim due to a firmware bug confirmed by vendor. We
found it on Intel-C3230RK platform. So we add fixup of broken trim
for it.

Signed-off-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: dw_mmc: add quirk for broken data transfer over scheme</title>
<updated>2015-08-17T10:45:28+00:00</updated>
<author>
<name>Addy Ke</name>
<email>addy.ke@rock-chips.com</email>
</author>
<published>2015-08-10T16:27:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=57e104864bc4874a36796fd222d8d084dbf90b9b'/>
<id>57e104864bc4874a36796fd222d8d084dbf90b9b</id>
<content type='text'>
This patch add a new quirk to add a s/w timer to notify the driver
to terminate current transfer and report a data timeout to the core,
if DTO interrupt does NOT come within the given time.

dw_mmc call mmc_request_done func to finish transfer depends on
DTO interrupt. If DTO interrupt does not come in sending data state,
the current transfer will be blocked.

We got the reply from synopsys:
There are two counters but both use the same value of [31:8] bits.
Data timeout counter doesn't wait for stop clock and you should get
DRTO even when the clock is not stopped.
Host Starvation timeout counter is triggered with stop clock condition.

This means that host should get DRTO and DTO interrupt.

But this case really exists, when driver reads tuning data from
card on RK3288-pink2 board. I measured waveforms by oscilloscope
and found that card clock was always on and data lines were always
holded high level in sending data state.

There are two possibility that data over interrupt doesn't come in
reading data state on RK3X SoCs:
- get command done interrupt, but doesn't get any data-related interrupt.
- get data error interrupt, but doesn't get data over interrupt.

Signed-off-by: Addy Ke &lt;addy.ke@rock-chips.com&gt;
Signed-off-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch add a new quirk to add a s/w timer to notify the driver
to terminate current transfer and report a data timeout to the core,
if DTO interrupt does NOT come within the given time.

dw_mmc call mmc_request_done func to finish transfer depends on
DTO interrupt. If DTO interrupt does not come in sending data state,
the current transfer will be blocked.

We got the reply from synopsys:
There are two counters but both use the same value of [31:8] bits.
Data timeout counter doesn't wait for stop clock and you should get
DRTO even when the clock is not stopped.
Host Starvation timeout counter is triggered with stop clock condition.

This means that host should get DRTO and DTO interrupt.

But this case really exists, when driver reads tuning data from
card on RK3288-pink2 board. I measured waveforms by oscilloscope
and found that card clock was always on and data lines were always
holded high level in sending data state.

There are two possibility that data over interrupt doesn't come in
reading data state on RK3X SoCs:
- get command done interrupt, but doesn't get any data-related interrupt.
- get data error interrupt, but doesn't get data over interrupt.

Signed-off-by: Addy Ke &lt;addy.ke@rock-chips.com&gt;
Signed-off-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: dw_mmc: remove the unused blk_setting</title>
<updated>2015-08-17T10:45:27+00:00</updated>
<author>
<name>Jaehoon Chung</name>
<email>jh80.chung@samsung.com</email>
</author>
<published>2015-08-06T07:23:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2b708df2b3edf6e91a4c8d89e7aedb0f861d0e41'/>
<id>2b708df2b3edf6e91a4c8d89e7aedb0f861d0e41</id>
<content type='text'>
"blk_setting" doesn't use anywhere.

Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
"blk_setting" doesn't use anywhere.

Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: dw_mmc: fix pio mode when internal dmac is enabled</title>
<updated>2015-08-17T10:44:43+00:00</updated>
<author>
<name>Heiko Stuebner</name>
<email>heiko@sntech.de</email>
</author>
<published>2015-08-03T15:04:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=575c319dfe872fc8bf1d57b244fb40f497ab3a47'/>
<id>575c319dfe872fc8bf1d57b244fb40f497ab3a47</id>
<content type='text'>
The dw_mci_init_dma() may decide to not use dma, but pio instead, caused
by things like wrong dma settings in the system.

Till now the code dw_mci_init_slot() always assumed that dma is available
when CONFIG_MMC_DW_IDMAC was defined, ignoring the host-&gt;use_dma var
set during dma init.

So when now the dma init failed for whatever reason, the transfer sizes
would still be set for dma transfers, especially including the maximum
block-count calculated from host-&gt;ring_size and resulting in a

[    4.991109] ------------[ cut here ]------------
[    4.991111] kernel BUG at drivers/mmc/core/core.c:256!
[    4.991113] Internal error: Oops - BUG: 0 [#1] SMP ARM

because host-&gt;ring_size is 0 in this case and the slot init code uses
the wrong code to calculate the values.

Fix this by selecting the correct calculations using the host-&gt;use_dma
variable instead of the CONFIG_MMC_DW_IDMAC config option.

Signed-off-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The dw_mci_init_dma() may decide to not use dma, but pio instead, caused
by things like wrong dma settings in the system.

Till now the code dw_mci_init_slot() always assumed that dma is available
when CONFIG_MMC_DW_IDMAC was defined, ignoring the host-&gt;use_dma var
set during dma init.

So when now the dma init failed for whatever reason, the transfer sizes
would still be set for dma transfers, especially including the maximum
block-count calculated from host-&gt;ring_size and resulting in a

[    4.991109] ------------[ cut here ]------------
[    4.991111] kernel BUG at drivers/mmc/core/core.c:256!
[    4.991113] Internal error: Oops - BUG: 0 [#1] SMP ARM

because host-&gt;ring_size is 0 in this case and the slot init code uses
the wrong code to calculate the values.

Fix this by selecting the correct calculations using the host-&gt;use_dma
variable instead of the CONFIG_MMC_DW_IDMAC config option.

Signed-off-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdio: avoid using NULL sdio_irq_thread pointer</title>
<updated>2015-08-17T09:32:46+00:00</updated>
<author>
<name>Yangbo Lu</name>
<email>yangbo.lu@freescale.com</email>
</author>
<published>2015-07-10T03:36:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f13e5b9f3c625916d7658ba526574a5d24e4d664'/>
<id>f13e5b9f3c625916d7658ba526574a5d24e4d664</id>
<content type='text'>
For Freescale QorIQ LS1021AQDS board, there is a SDIO interrupt
in the process of resume without inserting SD adapter because of
some unknown issue. But the driver doesn't assign sdio_irq_thread
pointer. This will block the resume of kernel. This patch is used
to avoid using NULL sdio_irq_thread pointer.

Signed-off-by: Yangbo Lu &lt;yangbo.lu@freescale.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>
For Freescale QorIQ LS1021AQDS board, there is a SDIO interrupt
in the process of resume without inserting SD adapter because of
some unknown issue. But the driver doesn't assign sdio_irq_thread
pointer. This will block the resume of kernel. This patch is used
to avoid using NULL sdio_irq_thread pointer.

Signed-off-by: Yangbo Lu &lt;yangbo.lu@freescale.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Optimize case for exactly one erase-group budget</title>
<updated>2015-08-17T09:32:39+00:00</updated>
<author>
<name>David Jander</name>
<email>david@protonic.nl</email>
</author>
<published>2015-06-23T09:43:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=642c28ab86f7666d2ac62a0dc391b4c3121f1d6e'/>
<id>642c28ab86f7666d2ac62a0dc391b4c3121f1d6e</id>
<content type='text'>
In the (not so unlikely) case that the mmc controller timeout budget is
enough for exactly one erase-group, the simplification of allowing one
sector has an enormous performance penalty. We optimize this special case
by introducing a flag that prohibits erase-group boundary crossing, so
that we can allow trimming more than one sector at a time.

Signed-off-by: David Jander &lt;david@protonic.nl&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>
In the (not so unlikely) case that the mmc controller timeout budget is
enough for exactly one erase-group, the simplification of allowing one
sector has an enormous performance penalty. We optimize this special case
by introducing a flag that prohibits erase-group boundary crossing, so
that we can allow trimming more than one sector at a time.

Signed-off-by: David Jander &lt;david@protonic.nl&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: mediatek: Add Mediatek MMC driver</title>
<updated>2015-06-18T07:20:48+00:00</updated>
<author>
<name>Chaotian Jing</name>
<email>chaotian.jing@mediatek.com</email>
</author>
<published>2015-06-15T11:20:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=208489032bdd8d4a7de50f3057c175058f271956'/>
<id>208489032bdd8d4a7de50f3057c175058f271956</id>
<content type='text'>
Add Mediatek MMC driver code
Support eMMC/SD/SDIO

Signed-off-by: Chaotian Jing &lt;chaotian.jing@mediatek.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>
Add Mediatek MMC driver code
Support eMMC/SD/SDIO

Signed-off-by: Chaotian Jing &lt;chaotian.jing@mediatek.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-pci: Add support for drive strength selection for SPT</title>
<updated>2015-06-01T07:07:14+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2015-02-06T12:13:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e1bfad6d936d7149a83423e2a7244dd5771f27e7'/>
<id>e1bfad6d936d7149a83423e2a7244dd5771f27e7</id>
<content type='text'>
Implement the select_drive_strength callback to provide
drive strength selection for Intel SPT.

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>
Implement the select_drive_strength callback to provide
drive strength selection for Intel SPT.

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: mmc: Add driver strength selection</title>
<updated>2015-06-01T07:07:14+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2015-02-06T12:12:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cc4f414c885cd04f7227ad9bcd6b18fd78d718d9'/>
<id>cc4f414c885cd04f7227ad9bcd6b18fd78d718d9</id>
<content type='text'>
Add the ability to set eMMC driver strength
for HS200 and HS400.

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>
Add the ability to set eMMC driver strength
for HS200 and HS400.

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: mmc: Read card's valid driver strength mask</title>
<updated>2015-06-01T07:07:13+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2015-02-06T12:12:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b097e07f57930eda774c83aa46e8e401686d01dc'/>
<id>b097e07f57930eda774c83aa46e8e401686d01dc</id>
<content type='text'>
In preparation for supporing drive strength selection
for eMMC, read the card's valid driver strengths.

Note that though the SD spec uses the term "drive strength",
the JEDEC eMMC spec uses the term "driver strength".

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>
In preparation for supporing drive strength selection
for eMMC, read the card's valid driver strengths.

Note that though the SD spec uses the term "drive strength",
the JEDEC eMMC spec uses the term "driver strength".

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>
</feed>
