kernel.git/drivers/mmc/core/core.c, branch linux-3.1.y

mmc: core: Fix hangs related to insert/remove of cards

2011-11-11T17:42:27Z

commit 7f7e4129c23f0419257184dff6fec89d2d5a8964 upstream. During a rescan operation mmc_attach(sd|mmc|sdio) functions are called. The error handling in these function can trigger a detach of the bus, which also meant a power off. This is not notified by the rescan operation which then continues to the next attach function. If a power off has been done, the framework must never send any new commands to the host driver, without first doing a new power up. This will most likely trigger any host driver to hang. Moving power off out of detach and instead handle power off separately when it is actually needed, solves the issue. Signed-off-by: Ulf Hansson Acked-by: Linus Walleij Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: core: prevent aggressive clock gating racing with ios updates

2011-08-31T20:25:49Z

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->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->clock > 0) mmc_set_ungated(host); Now if gating kicks in right after the condition check we end up setting host->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->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->ios.clock = 0; host->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->ocr = 1 << (fls(host->ocr_avail) - 1); if (!mmc_host_is_spi(host)) { host->ios.bus_mode = MMC_BUSMODE_OPENDRAIN; host->ios.chip_select = MMC_CS_DONTCARE; } host->ios.power_mode = MMC_POWER_OFF; host->ios.bus_width = MMC_BUS_WIDTH_1; host->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:[] 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] [] sdhci_set_ios+0x1c3/0x340 [ 4.186883] [] mmc_gate_clock+0x68/0x120 [ 4.186963] [] ? _raw_spin_unlock_irqrestore+0x4d/0x60 [ 4.187052] [] ? trace_hardirqs_on+0xb/0x10 [ 4.187134] [] mmc_host_clk_gate_delayed+0xbe/0x130 [ 4.187219] [] ? process_one_work+0xf9/0x5b0 [ 4.187300] [] mmc_host_clk_gate_work+0xd/0x10 [ 4.187379] [] process_one_work+0x172/0x5b0 [ 4.187457] [] ? process_one_work+0xf9/0x5b0 [ 4.187538] [] ? mmc_host_clk_gate_delayed+0x130/0x130 [ 4.187625] [] worker_thread+0x118/0x330 [ 4.187700] [] ? preempt_schedule+0x2e/0x50 [ 4.187779] [] ? rescuer_thread+0x1f0/0x1f0 [ 4.187857] [] kthread+0x74/0x80 [ 4.187931] [] ? __init_kthread_worker+0x60/0x60 [ 4.188015] [] 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: [] 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 Reviewed-by: Linus Walleij Tested-by: Chris Ball Cc: Signed-off-by: Chris Ball

mmc: rename mmc_host_clk_{ungate|gate} to mmc_host_clk_{hold|release}

2011-08-31T20:24:54Z

As per suggestion by Linus Walleij: > If you think the names of the functions are confusing then > you may rename them, say like this: > > mmc_host_clk_ungate() -> mmc_host_clk_hold() > mmc_host_clk_gate() -> mmc_host_clk_release() > > 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 Reviewed-by: Linus Walleij Cc: Signed-off-by: Chris Ball

mmc: core: use defined R1_STATE_PRG macro for card status

2011-08-13T18:50:31Z

Signed-off-by: Jaehoon Chung Signed-off-by: Kyungmin Park Signed-off-by: Chris Ball

notifiers: pm: move pm notifiers into suspend.h

2011-07-26T03:57:15Z

It is not necessary to share the same notifier.h. Signed-off-by: WANG Cong Cc: David Miller Acked-by: "Rafael J. Wysocki" Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mmc: print debug messages for runtime PM actions

2011-07-21T14:35:09Z

At http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg08371.html (thread: "mmc: sdio: reset card during power_restore") we found and fixed a bug where mmc's runtime power management functions were not being called. We have now also made improvements to the SDIO powerup routine which could possibly mask this kind of issue in future. Add debug messages to the runtime PM hooks so that it is easy to verify if and when runtime PM is happening. Signed-off-by: Daniel Drake Signed-off-by: Chris Ball

mmc: core: add non-blocking mmc request function

2011-07-20T21:21:10Z

Previously there has only been one function mmc_wait_for_req() to start and wait for a request. This patch adds: * mmc_start_req() - starts a request wihtout waiting If there is on ongoing request wait for completion of that request and start the new one and return. Does not wait for the new command to complete. This patch also adds new function members in struct mmc_host_ops only called from core.c: * pre_req - asks the host driver to prepare for the next job * post_req - asks the host driver to clean up after a completed job The intention is to use pre_req() and post_req() to do cache maintenance while a request is active. pre_req() can be called while a request is active to minimize latency to start next job. post_req() can be used after the next job is started to clean up the request. This will minimize the host driver request end latency. post_req() is typically used before ending the block request and handing over the buffer to the block layer. Add a host-private member in mmc_data to be used by pre_req to mark the data. The host driver will then check this mark to see if the data is prepared or not. Signed-off-by: Per Forlin Acked-by: Kyungmin Park Acked-by: Arnd Bergmann Reviewed-by: Venkatraman S Tested-by: Sourav Poddar Tested-by: Linus Walleij Signed-off-by: Chris Ball

mmc: queue: let host controllers specify maximum discard timeout

2011-07-20T21:21:03Z

Some host controllers will not operate without a hardware timeout that is limited in value. However large discards require large timeouts, so there needs to be a way to specify the maximum discard size. A host controller driver may now specify the maximum discard timeout possible so that max_discard_sectors can be calculated. However, for eMMC when the High Capacity Erase Group Size is not in use, the timeout calculation depends on clock rate which may change. For that case Preferred Erase Size is used instead. Signed-off-by: Adrian Hunter Signed-off-by: Chris Ball

mmc: core: make erase timeout calculation allow for gated clock

2011-06-25T22:52:53Z

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 Signed-off-by: Chris Ball

mmc: core: duplicated trial with same freq in mmc_rescan_try_freq()

2011-05-25T03:53:59Z

mmc_rescan_try_freq() tries to init two times with the last frequency. For example, if host->f_min is 400KHz, we see the message below: mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz Andy Ross says that he didn't try this code on a board with an f_min that exactly matches one of the table entries, which explains why the bug wasn't detected. Signed-off-by: Jaehoon Chung Signed-off-by: Kyungmin Park Cc: Andy Ross Signed-off-by: Chris Ball