<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mmc/core, branch v3.0.8</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mmc: core: use non-reentrant workqueue for clock gating</title>
<updated>2011-10-03T18:40:10+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2011-08-18T12:23:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6942511b6b2a4a6b1fb969905c6841bdb7c1083c'/>
<id>6942511b6b2a4a6b1fb969905c6841bdb7c1083c</id>
<content type='text'>
commit 50a50f9248497484c678631a9c1a719f1aaeab79 upstream.

The default multithread workqueue can cause the same work to be executed
concurrently on a different CPUs. This isn't really suitable for clock
gating as it might already gated the clock and gating it twice results both
host-&gt;clk_old and host-&gt;ios.clock to be set to 0.

To prevent this from happening we use system_nrt_wq instead.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Tested-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

The default multithread workqueue can cause the same work to be executed
concurrently on a different CPUs. This isn't really suitable for clock
gating as it might already gated the clock and gating it twice results both
host-&gt;clk_old and host-&gt;ios.clock to be set to 0.

To prevent this from happening we use system_nrt_wq instead.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Tested-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: prevent aggressive clock gating racing with ios updates</title>
<updated>2011-10-03T18:40:10+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2011-08-18T12:23:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0bd01aeeec0a9ba11adceb71aceed08ed276e3c0'/>
<id>0bd01aeeec0a9ba11adceb71aceed08ed276e3c0</id>
<content type='text'>
commit 778e277cb82411c9002ca28ccbd216c4d9eb9158 upstream.

We have seen at least two different races when clock gating kicks in in a
middle of ios structure update.

First one happens when ios-&gt;clock is changed outside of aggressive clock
gating framework, for example via mmc_set_clock(). The race might happen
when we run following code:

mmc_set_ios():
	...
	if (ios-&gt;clock &gt; 0)
		mmc_set_ungated(host);

Now if gating kicks in right after the condition check we end up setting
host-&gt;clk_gated to false even though we have just gated the clock. Next
time a request is started we try to ungate and restore the clock in
mmc_host_clk_hold(). However since we have host-&gt;clk_gated set to false the
original clock is not restored.

This eventually will cause the host controller to hang since its clock is
disabled while we are trying to issue a request. For example on Intel
Medfield platform we see:

[   13.818610] mmc2: Timeout waiting for hardware interrupt.
[   13.818698] sdhci: =========== REGISTER DUMP (mmc2)===========
[   13.818753] sdhci: Sys addr: 0x00000000 | Version:  0x00008901
[   13.818804] sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000
[   13.818853] sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[   13.818903] sdhci: Present:  0x1fff0000 | Host ctl: 0x00000001
[   13.818951] sdhci: Power:    0x0000000d | Blk gap:  0x00000000
[   13.819000] sdhci: Wake-up:  0x00000000 | Clock:    0x00000000
[   13.819049] sdhci: Timeout:  0x00000000 | Int stat: 0x00000000
[   13.819098] sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3
[   13.819147] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[   13.819196] sdhci: Caps:     0x6bee32b2 | Caps_1:   0x00000000
[   13.819245] sdhci: Cmd:      0x00000000 | Max curr: 0x00000000
[   13.819292] sdhci: Host ctl2: 0x00000000
[   13.819331] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[   13.819377] sdhci: ===========================================
[   13.919605] mmc2: Reset 0x2 never completed.

and it never recovers.

Second race might happen while running mmc_power_off():

static void mmc_power_off(struct mmc_host *host)
{
	host-&gt;ios.clock = 0;
	host-&gt;ios.vdd = 0;

[ clock gating kicks in here ]

	/*
	 * Reset ocr mask to be the highest possible voltage supported for
	 * this mmc host. This value will be used at next power up.
	 */
	host-&gt;ocr = 1 &lt;&lt; (fls(host-&gt;ocr_avail) - 1);

	if (!mmc_host_is_spi(host)) {
		host-&gt;ios.bus_mode = MMC_BUSMODE_OPENDRAIN;
		host-&gt;ios.chip_select = MMC_CS_DONTCARE;
	}
	host-&gt;ios.power_mode = MMC_POWER_OFF;
	host-&gt;ios.bus_width = MMC_BUS_WIDTH_1;
	host-&gt;ios.timing = MMC_TIMING_LEGACY;
	mmc_set_ios(host);
}

If the clock gating worker kicks in while we are only partially updated the
ios structure the host controller gets incomplete ios and might not work as
supposed. Again on Intel Medfield platform we get:

[    4.185349] kernel BUG at drivers/mmc/host/sdhci.c:1155!
[    4.185422] invalid opcode: 0000 [#1] PREEMPT SMP
[    4.185509] Modules linked in:
[    4.185565]
[    4.185608] Pid: 4, comm: kworker/0:0 Not tainted 3.0.0+ #240 Intel Corporation Medfield/iCDKA
[    4.185742] EIP: 0060:[&lt;c136364e&gt;] EFLAGS: 00010083 CPU: 0
[    4.185827] EIP is at sdhci_set_power+0x3e/0xd0
[    4.185891] EAX: f5ff98e0 EBX: f5ff98e0 ECX: 00000000 EDX: 00000001
[    4.185970] ESI: f5ff977c EDI: f5ff9904 EBP: f644fe98 ESP: f644fe94
[    4.186049]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[    4.186125] Process kworker/0:0 (pid: 4, ti=f644e000 task=f644c0e0 task.ti=f644e000)
[    4.186219] Stack:
[    4.186257]  f5ff98e0 f644feb0 c1365173 00000282 f5ff9460 f5ff96e0 f5ff96e0 f644feec
[    4.186418]  c1355bd8 f644c0e0 c1499c3d f5ff96e0 f644fed4 00000006 f5ff96e0 00000286
[    4.186579]  f644fedc c107922b f644feec 00000286 f5ff9460 f5ff9700 f644ff10 c135839e
[    4.186739] Call Trace:
[    4.186802]  [&lt;c1365173&gt;] sdhci_set_ios+0x1c3/0x340
[    4.186883]  [&lt;c1355bd8&gt;] mmc_gate_clock+0x68/0x120
[    4.186963]  [&lt;c1499c3d&gt;] ? _raw_spin_unlock_irqrestore+0x4d/0x60
[    4.187052]  [&lt;c107922b&gt;] ? trace_hardirqs_on+0xb/0x10
[    4.187134]  [&lt;c135839e&gt;] mmc_host_clk_gate_delayed+0xbe/0x130
[    4.187219]  [&lt;c105ec09&gt;] ? process_one_work+0xf9/0x5b0
[    4.187300]  [&lt;c135841d&gt;] mmc_host_clk_gate_work+0xd/0x10
[    4.187379]  [&lt;c105ec82&gt;] process_one_work+0x172/0x5b0
[    4.187457]  [&lt;c105ec09&gt;] ? process_one_work+0xf9/0x5b0
[    4.187538]  [&lt;c1358410&gt;] ? mmc_host_clk_gate_delayed+0x130/0x130
[    4.187625]  [&lt;c105f3c8&gt;] worker_thread+0x118/0x330
[    4.187700]  [&lt;c1496cee&gt;] ? preempt_schedule+0x2e/0x50
[    4.187779]  [&lt;c105f2b0&gt;] ? rescuer_thread+0x1f0/0x1f0
[    4.187857]  [&lt;c1062cf4&gt;] kthread+0x74/0x80
[    4.187931]  [&lt;c1062c80&gt;] ? __init_kthread_worker+0x60/0x60
[    4.188015]  [&lt;c149acfa&gt;] kernel_thread_helper+0x6/0xd
[    4.188079] Code: 81 fa 00 00 04 00 0f 84 a7 00 00 00 7f 21 81 fa 80 00 00 00 0f 84 92 00 00 00 81 fa 00 00 0
[    4.188780] EIP: [&lt;c136364e&gt;] sdhci_set_power+0x3e/0xd0 SS:ESP 0068:f644fe94
[    4.188898] ---[ end trace a7b23eecc71777e4 ]---

This BUG() comes from the fact that ios.power_mode was still in previous
value (MMC_POWER_ON) and ios.vdd was set to zero.

We prevent these by inhibiting the clock gating while we update the ios
structure.

Both problems can be reproduced by simply running the device in a reboot
loop.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Tested-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

We have seen at least two different races when clock gating kicks in in a
middle of ios structure update.

First one happens when ios-&gt;clock is changed outside of aggressive clock
gating framework, for example via mmc_set_clock(). The race might happen
when we run following code:

mmc_set_ios():
	...
	if (ios-&gt;clock &gt; 0)
		mmc_set_ungated(host);

Now if gating kicks in right after the condition check we end up setting
host-&gt;clk_gated to false even though we have just gated the clock. Next
time a request is started we try to ungate and restore the clock in
mmc_host_clk_hold(). However since we have host-&gt;clk_gated set to false the
original clock is not restored.

This eventually will cause the host controller to hang since its clock is
disabled while we are trying to issue a request. For example on Intel
Medfield platform we see:

[   13.818610] mmc2: Timeout waiting for hardware interrupt.
[   13.818698] sdhci: =========== REGISTER DUMP (mmc2)===========
[   13.818753] sdhci: Sys addr: 0x00000000 | Version:  0x00008901
[   13.818804] sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000
[   13.818853] sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[   13.818903] sdhci: Present:  0x1fff0000 | Host ctl: 0x00000001
[   13.818951] sdhci: Power:    0x0000000d | Blk gap:  0x00000000
[   13.819000] sdhci: Wake-up:  0x00000000 | Clock:    0x00000000
[   13.819049] sdhci: Timeout:  0x00000000 | Int stat: 0x00000000
[   13.819098] sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3
[   13.819147] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[   13.819196] sdhci: Caps:     0x6bee32b2 | Caps_1:   0x00000000
[   13.819245] sdhci: Cmd:      0x00000000 | Max curr: 0x00000000
[   13.819292] sdhci: Host ctl2: 0x00000000
[   13.819331] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[   13.819377] sdhci: ===========================================
[   13.919605] mmc2: Reset 0x2 never completed.

and it never recovers.

Second race might happen while running mmc_power_off():

static void mmc_power_off(struct mmc_host *host)
{
	host-&gt;ios.clock = 0;
	host-&gt;ios.vdd = 0;

[ clock gating kicks in here ]

	/*
	 * Reset ocr mask to be the highest possible voltage supported for
	 * this mmc host. This value will be used at next power up.
	 */
	host-&gt;ocr = 1 &lt;&lt; (fls(host-&gt;ocr_avail) - 1);

	if (!mmc_host_is_spi(host)) {
		host-&gt;ios.bus_mode = MMC_BUSMODE_OPENDRAIN;
		host-&gt;ios.chip_select = MMC_CS_DONTCARE;
	}
	host-&gt;ios.power_mode = MMC_POWER_OFF;
	host-&gt;ios.bus_width = MMC_BUS_WIDTH_1;
	host-&gt;ios.timing = MMC_TIMING_LEGACY;
	mmc_set_ios(host);
}

If the clock gating worker kicks in while we are only partially updated the
ios structure the host controller gets incomplete ios and might not work as
supposed. Again on Intel Medfield platform we get:

[    4.185349] kernel BUG at drivers/mmc/host/sdhci.c:1155!
[    4.185422] invalid opcode: 0000 [#1] PREEMPT SMP
[    4.185509] Modules linked in:
[    4.185565]
[    4.185608] Pid: 4, comm: kworker/0:0 Not tainted 3.0.0+ #240 Intel Corporation Medfield/iCDKA
[    4.185742] EIP: 0060:[&lt;c136364e&gt;] EFLAGS: 00010083 CPU: 0
[    4.185827] EIP is at sdhci_set_power+0x3e/0xd0
[    4.185891] EAX: f5ff98e0 EBX: f5ff98e0 ECX: 00000000 EDX: 00000001
[    4.185970] ESI: f5ff977c EDI: f5ff9904 EBP: f644fe98 ESP: f644fe94
[    4.186049]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[    4.186125] Process kworker/0:0 (pid: 4, ti=f644e000 task=f644c0e0 task.ti=f644e000)
[    4.186219] Stack:
[    4.186257]  f5ff98e0 f644feb0 c1365173 00000282 f5ff9460 f5ff96e0 f5ff96e0 f644feec
[    4.186418]  c1355bd8 f644c0e0 c1499c3d f5ff96e0 f644fed4 00000006 f5ff96e0 00000286
[    4.186579]  f644fedc c107922b f644feec 00000286 f5ff9460 f5ff9700 f644ff10 c135839e
[    4.186739] Call Trace:
[    4.186802]  [&lt;c1365173&gt;] sdhci_set_ios+0x1c3/0x340
[    4.186883]  [&lt;c1355bd8&gt;] mmc_gate_clock+0x68/0x120
[    4.186963]  [&lt;c1499c3d&gt;] ? _raw_spin_unlock_irqrestore+0x4d/0x60
[    4.187052]  [&lt;c107922b&gt;] ? trace_hardirqs_on+0xb/0x10
[    4.187134]  [&lt;c135839e&gt;] mmc_host_clk_gate_delayed+0xbe/0x130
[    4.187219]  [&lt;c105ec09&gt;] ? process_one_work+0xf9/0x5b0
[    4.187300]  [&lt;c135841d&gt;] mmc_host_clk_gate_work+0xd/0x10
[    4.187379]  [&lt;c105ec82&gt;] process_one_work+0x172/0x5b0
[    4.187457]  [&lt;c105ec09&gt;] ? process_one_work+0xf9/0x5b0
[    4.187538]  [&lt;c1358410&gt;] ? mmc_host_clk_gate_delayed+0x130/0x130
[    4.187625]  [&lt;c105f3c8&gt;] worker_thread+0x118/0x330
[    4.187700]  [&lt;c1496cee&gt;] ? preempt_schedule+0x2e/0x50
[    4.187779]  [&lt;c105f2b0&gt;] ? rescuer_thread+0x1f0/0x1f0
[    4.187857]  [&lt;c1062cf4&gt;] kthread+0x74/0x80
[    4.187931]  [&lt;c1062c80&gt;] ? __init_kthread_worker+0x60/0x60
[    4.188015]  [&lt;c149acfa&gt;] kernel_thread_helper+0x6/0xd
[    4.188079] Code: 81 fa 00 00 04 00 0f 84 a7 00 00 00 7f 21 81 fa 80 00 00 00 0f 84 92 00 00 00 81 fa 00 00 0
[    4.188780] EIP: [&lt;c136364e&gt;] sdhci_set_power+0x3e/0xd0 SS:ESP 0068:f644fe94
[    4.188898] ---[ end trace a7b23eecc71777e4 ]---

This BUG() comes from the fact that ios.power_mode was still in previous
value (MMC_POWER_ON) and ios.vdd was set to zero.

We prevent these by inhibiting the clock gating while we update the ios
structure.

Both problems can be reproduced by simply running the device in a reboot
loop.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Tested-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: rename mmc_host_clk_{ungate|gate} to mmc_host_clk_{hold|release}</title>
<updated>2011-10-03T18:40:10+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2011-08-18T12:23:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a24cf48a9c7c0def84c226ad97b9d15efd920f9c'/>
<id>a24cf48a9c7c0def84c226ad97b9d15efd920f9c</id>
<content type='text'>
commit 08c14071fda4e69abb9d5b1566651cd092b158d3 upstream.

As per suggestion by Linus Walleij:

  &gt; If you think the names of the functions are confusing then
  &gt; you may rename them, say like this:
  &gt;
  &gt; mmc_host_clk_ungate() -&gt; mmc_host_clk_hold()
  &gt; mmc_host_clk_gate() -&gt; mmc_host_clk_release()
  &gt;
  &gt; Which would make the usecases more clear

(This is CC'd to stable@ because the next two patches, which fix
observable races, depend on it.)

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

As per suggestion by Linus Walleij:

  &gt; If you think the names of the functions are confusing then
  &gt; you may rename them, say like this:
  &gt;
  &gt; mmc_host_clk_ungate() -&gt; mmc_host_clk_hold()
  &gt; mmc_host_clk_gate() -&gt; mmc_host_clk_release()
  &gt;
  &gt; Which would make the usecases more clear

(This is CC'd to stable@ because the next two patches, which fix
observable races, depend on it.)

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Bus width testing needs to handle suspend/resume</title>
<updated>2011-07-13T18:54:37+00:00</updated>
<author>
<name>Philip Rakity</name>
<email>prakity@marvell.com</email>
</author>
<published>2011-07-07T16:04:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f39b2dd9d065151a04f5996656d1f27a7eb32d45'/>
<id>f39b2dd9d065151a04f5996656d1f27a7eb32d45</id>
<content type='text'>
On reading the ext_csd for the first time (in 1 bit mode), save the
ext_csd information needed for bus width compare.

On every pass we make re-reading the ext_csd, compare the data
against the saved ext_csd data.

This fixes a regression introduced in 3.0-rc1 by 08ee80cc397ac1a3
("mmc: core: eMMC bus width may not work on all platforms"), which
incorrectly assumed we would be re-reading the ext_csd at resume-
time.

Signed-off-by: Philip Rakity &lt;prakity@marvell.com&gt;
Tested-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On reading the ext_csd for the first time (in 1 bit mode), save the
ext_csd information needed for bus width compare.

On every pass we make re-reading the ext_csd, compare the data
against the saved ext_csd data.

This fixes a regression introduced in 3.0-rc1 by 08ee80cc397ac1a3
("mmc: core: eMMC bus width may not work on all platforms"), which
incorrectly assumed we would be re-reading the ext_csd at resume-
time.

Signed-off-by: Philip Rakity &lt;prakity@marvell.com&gt;
Tested-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: make erase timeout calculation allow for gated clock</title>
<updated>2011-06-25T22:52:53+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2011-06-23T10:40:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4cf8c6dd2e261da94b87c4deadcc136ab022b6ac'/>
<id>4cf8c6dd2e261da94b87c4deadcc136ab022b6ac</id>
<content type='text'>
The erase timeout calculation may depend on clock rate
which is zero if the clock is gated, so use
mmc_host_clk_rate() which allows for that case.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The erase timeout calculation may depend on clock rate
which is zero if the clock is gated, so use
mmc_host_clk_rate() which allows for that case.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdio: reset card during power_restore</title>
<updated>2011-06-25T22:52:44+00:00</updated>
<author>
<name>Daniel Drake</name>
<email>dsd@laptop.org</email>
</author>
<published>2011-06-25T18:20:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c6e633ad916e2af244dbfd11abd2bc077870bdfd'/>
<id>c6e633ad916e2af244dbfd11abd2bc077870bdfd</id>
<content type='text'>
mmc_sdio_power_restore() skips some steps that are performed in other
power-related codepaths which are necessary to fully reset the card.
Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5.

Signed-off-by: Daniel Drake &lt;dsd@laptop.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
mmc_sdio_power_restore() skips some steps that are performed in other
power-related codepaths which are necessary to fully reset the card.
Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5.

Signed-off-by: Daniel Drake &lt;dsd@laptop.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdio: fix runtime PM path during driver removal</title>
<updated>2011-06-25T22:49:55+00:00</updated>
<author>
<name>Ohad Ben-Cohen</name>
<email>ohad@wizery.com</email>
</author>
<published>2011-06-09T23:40:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=297c7f2f158f7dfa9ab5813260ff954f9c2f83d2'/>
<id>297c7f2f158f7dfa9ab5813260ff954f9c2f83d2</id>
<content type='text'>
After commit e1866b3 "PM / Runtime: Rework runtime PM handling
during driver removal" was introduced, the driver core stopped
incrementing the runtime PM usage counter of the device during
the invocation of the -&gt;remove() callback.

This indirectly broke SDIO's runtime PM path during driver removal,
because no one calls _put_sync() anymore after -&gt;remove() completes.

This means that the power of runtime-PM-managed SDIO cards is kept
high after their driver is removed (even if it was powered down
beforehand).

Fix that by directly calling _put_sync() when the last usage
counter is downref'ed by the SDIO bus.

Reported-and-tested-by: Daniel Drake &lt;dsd@laptop.org&gt;
Signed-off-by: Ohad Ben-Cohen &lt;ohad@wizery.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After commit e1866b3 "PM / Runtime: Rework runtime PM handling
during driver removal" was introduced, the driver core stopped
incrementing the runtime PM usage counter of the device during
the invocation of the -&gt;remove() callback.

This indirectly broke SDIO's runtime PM path during driver removal,
because no one calls _put_sync() anymore after -&gt;remove() completes.

This means that the power of runtime-PM-managed SDIO cards is kept
high after their driver is removed (even if it was powered down
beforehand).

Fix that by directly calling _put_sync() when the last usage
counter is downref'ed by the SDIO bus.

Reported-and-tested-by: Daniel Drake &lt;dsd@laptop.org&gt;
Signed-off-by: Ohad Ben-Cohen &lt;ohad@wizery.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc</title>
<updated>2011-05-25T23:55:55+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2011-05-25T23:55:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8c1c77ff9be27137fa7cbbf51efedef1a2ae915b'/>
<id>8c1c77ff9be27137fa7cbbf51efedef1a2ae915b</id>
<content type='text'>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (75 commits)
  mmc: core: eMMC bus width may not work on all platforms
  mmc: sdhci: Auto-CMD23 fixes.
  mmc: sdhci: Auto-CMD23 support.
  mmc: core: Block CMD23 support for UHS104/SDXC cards.
  mmc: sdhci: Implement MMC_CAP_CMD23 for SDHCI.
  mmc: core: Use CMD23 for multiblock transfers when we can.
  mmc: quirks: Add/remove quirks conditional support.
  mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver
  mmc: sdhci-pxa: Add quirks for DMA/ADMA to match h/w
  mmc: core: duplicated trial with same freq in mmc_rescan_try_freq()
  mmc: core: add support for eMMC Dual Data Rate
  mmc: core: eMMC signal voltage does not use CMD11
  mmc: sdhci-pxa: add platform code for UHS signaling
  mmc: sdhci: add hooks for setting UHS in platform specific code
  mmc: core: clear MMC_PM_KEEP_POWER flag on resume
  mmc: dw_mmc: fixed wrong regulator_enable in suspend/resume
  mmc: sdhi: allow powering down controller with no card inserted
  mmc: tmio: runtime suspend the controller, where possible
  mmc: sdhi: support up to 3 interrupt sources
  mmc: sdhi: print physical base address and clock rate
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (75 commits)
  mmc: core: eMMC bus width may not work on all platforms
  mmc: sdhci: Auto-CMD23 fixes.
  mmc: sdhci: Auto-CMD23 support.
  mmc: core: Block CMD23 support for UHS104/SDXC cards.
  mmc: sdhci: Implement MMC_CAP_CMD23 for SDHCI.
  mmc: core: Use CMD23 for multiblock transfers when we can.
  mmc: quirks: Add/remove quirks conditional support.
  mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver
  mmc: sdhci-pxa: Add quirks for DMA/ADMA to match h/w
  mmc: core: duplicated trial with same freq in mmc_rescan_try_freq()
  mmc: core: add support for eMMC Dual Data Rate
  mmc: core: eMMC signal voltage does not use CMD11
  mmc: sdhci-pxa: add platform code for UHS signaling
  mmc: sdhci: add hooks for setting UHS in platform specific code
  mmc: core: clear MMC_PM_KEEP_POWER flag on resume
  mmc: dw_mmc: fixed wrong regulator_enable in suspend/resume
  mmc: sdhi: allow powering down controller with no card inserted
  mmc: tmio: runtime suspend the controller, where possible
  mmc: sdhi: support up to 3 interrupt sources
  mmc: sdhi: print physical base address and clock rate
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: eMMC bus width may not work on all platforms</title>
<updated>2011-05-25T20:52:32+00:00</updated>
<author>
<name>Philip Rakity</name>
<email>prakity@marvell.com</email>
</author>
<published>2011-05-25T01:14:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=08ee80cc397ac1a306ca689a22ede954d92d0db1'/>
<id>08ee80cc397ac1a306ca689a22ede954d92d0db1</id>
<content type='text'>
CMD19 -- The offical way to validate bus widths from the JEDEC spec
does not work on all platforms.  Some platforms that use PCI/PCIe
to connect their SD controllers are known to fail.

If the quirk MMC_BUS_WIDTH_TEST is not defined we try to figure out
the bus width by reading the ext_csd at different bus widths and
compare this against the ext_csd read in 1 bit mode.  If no ext_csd
is available we default to 1 bit operations.

Code has been tested on mmp2 against 8 bit eMMC and Transcend 2GB
card that is known to not work in 4 bit mode.  The physical pins
on the card are not present to support 4 bit operation.

Signed-off-by: Philip Rakity &lt;prakity@marvell.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CMD19 -- The offical way to validate bus widths from the JEDEC spec
does not work on all platforms.  Some platforms that use PCI/PCIe
to connect their SD controllers are known to fail.

If the quirk MMC_BUS_WIDTH_TEST is not defined we try to figure out
the bus width by reading the ext_csd at different bus widths and
compare this against the ext_csd read in 1 bit mode.  If no ext_csd
is available we default to 1 bit operations.

Code has been tested on mmp2 against 8 bit eMMC and Transcend 2GB
card that is known to not work in 4 bit mode.  The physical pins
on the card are not present to support 4 bit operation.

Signed-off-by: Philip Rakity &lt;prakity@marvell.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Block CMD23 support for UHS104/SDXC cards.</title>
<updated>2011-05-25T20:49:03+00:00</updated>
<author>
<name>Andrei Warkentin</name>
<email>andreiw@motorola.com</email>
</author>
<published>2011-05-23T20:06:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f0d89972b01798cf9d245dfa1cacfa0ee78a3593'/>
<id>f0d89972b01798cf9d245dfa1cacfa0ee78a3593</id>
<content type='text'>
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.

Signed-off-by: Andrei Warkentin &lt;andreiw@motorola.com&gt;
Reviewed-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.

Signed-off-by: Andrei Warkentin &lt;andreiw@motorola.com&gt;
Reviewed-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
