linux/drivers/mmc/core, branch v3.0.86

mmc: core: Fix bit width test failing on old eMMC cards

2013-05-08T02:57:27Z

commit 836dc2fe89c968c10cada87e0dfae6626f8f9da3 upstream. PARTITION_SUPPORT needs to be set before doing the compare on version number so the bit width test does not get invalid data. Before this patch, a Sandisk iNAND eMMC card would detect 1-bit width although the hardware supports 4-bit. Only affects old emmc devices - pre 4.4 devices. Reported-by: Elad Yi Signed-off-by: Philip Rakity Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: sd: Handle SD3.0 cards not supporting UHS-I bus speed mode

2012-10-02T16:47:54Z

commit f2815f68dabbb373fd1c9f0fd4a609d486697c2b upstream. Here is Essential conditions to indicate Version 3.00 Card (SD_SPEC=2 and SD_SPEC3=1) : (1) The card shall support CMD6 (2) The card shall support CMD8 (3) The card shall support CMD42 (4) User area capacity shall be up to 2GB (SDSC) or 32GB (SDHC) User area capacity shall be more than or equal to 32GB and up to 2TB (SDXC) (5) Speed Class shall be supported (SDHC or SDXC) So even if SD card doesn't support any of the newly defined UHS-I bus speed mode, it can advertise itself as SD3.0 cards as long as it supports all the essential conditions of SD3.0 cards. Given this, these type of cards should atleast run in High Speed mode @50MHZ if it supports HS. But current initialization sequence for SD3.0 cards is such that these non-UHS-I SD3.0 cards runs in Default Speed mode @25MHz. This patch makes sure that these non-UHS-I SD3.0 cards run in High Speed Mode @50MHz. Tested this patch with SanDisk Extreme SDHC 8GB Class 10 card. Reported-by: "Hiremath, Vaibhav" Signed-off-by: Subhash Jadavani Signed-off-by: Chris Ball

mmc: sdio: avoid spurious calls to interrupt handlers

2012-06-01T07:13:00Z

commit bbbc4c4d8c5face097d695f9bf3a39647ba6b7e7 upstream. Commit 06e8935feb ("optimized SDIO IRQ handling for single irq") introduced some spurious calls to SDIO function interrupt handlers, such as when the SDIO IRQ thread is started, or the safety check performed upon a system resume. Let's add a flag to perform the optimization only when a real interrupt is signaled by the host driver and we know there is no point confirming it. Reported-by: Sujit Reddy Thumma Signed-off-by: Nicolas Pitre Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: core: Fix voltage select in DDR mode

2012-01-26T01:24:45Z

commit 913047e9e5787a90696533a9f109552b7694ecc9 upstream. This patch fixes the wrong comparison before setting the interface voltage in DDR mode. The assignment to the variable ddr before comaprison is either ddr = MMC_1_2V_DDR_MODE; or ddr == MMC_1_8V_DDR_MODE. But the comparison is done with the extended csd value if ddr == EXT_CSD_CARD_TYPE_DDR_1_2V. Signed-off-by: Girish K S Acked-by: Subhash Jadavani Acked-by: Philip Rakity Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: core: ext_csd.raw_* used in comparison but never set

2011-11-11T17:35:23Z

commit 5238acbe36dd5100fb6b035a995ae5fc89dd0708 upstream. f39b2dd9d ("mmc: core: Bus width testing needs to handle suspend/resume") added code to only compare read-only ext_csd fields in bus width testing code, yet it's comparing some fields that are never set. The affected fields are ext_csd.raw_erased_mem_count and ext_csd.raw_partition_support. Signed-off-by: Andrei Warkentin Acked-by: Philip Rakity Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

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

2011-11-11T17:35:22Z

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: use non-reentrant workqueue for clock gating

2011-10-03T18:40:10Z

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->clk_old and host->ios.clock to be set to 0. To prevent this from happening we use system_nrt_wq instead. Signed-off-by: Mika Westerberg Reviewed-by: Linus Walleij Tested-by: Chris Ball Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

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

2011-10-03T18:40:10Z

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

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

2011-10-03T18:40:10Z

commit 08c14071fda4e69abb9d5b1566651cd092b158d3 upstream. 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 Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: core: Bus width testing needs to handle suspend/resume

2011-07-13T18:54:37Z

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