- 22 May, 2014 40 commits
-
-
Al Cooper authored
The SD Host Controller spec states that the SD Host Controller can request that the driver send up to 40 CMD19's while doing tuning and that the total time the card spends responding must be < 150ms. The sdhci_execute_tuning() function in sdhci.c that loops through sending the CMD19's has multiple bugs. First it sets a "timeout" variable to 150 and a loop counter variable to 40. It then decrements both variables by 1 at the end of each loop. It tries to handle violations of the count and time by doing a break when BOTH variables are equal to zero, which can never happen because they we set to different values and decremented by 1 at the same time. The timeout variable is not based on time at all and is totally useless. The routine also considers a loop counter of zero to be an error which means that any controller that requests the max of 40 CMD19s will cause tuning to fail and be disabled. I've fixed these issues by allowing up to 40 CMD19's and I've removed any attempt to handle the 150ms time limit. Removing timeout checking seems safe here because each CMD19 is timeout protected and the max loop counters insures we don't loop forever. Adding timeout checking would not be as simple as snapping the time at the loop start and checking for 150ms to pass because the loop queues the CMD19's and uses events to wait for completion so the time would include all the normal scheduler latencies. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Chris Ball <chris@printf.net>
-
Aisheng Dong authored
It's caused by the platform driver was still using MMC_TIMING_UHS_DDR50 for MMC DDR mode which needs update too. Reported-by:
Fabio Estevam <fabio.estevam@freescale.com> Reported-by:
Shawn Guo <shawn.guo@freescale.com> Signed-off-by:
Dong Aisheng <b29396@freescale.com> Tested-by:
-
Peter Guo authored
Add O2Micro/BayHubTech chip 8520 subversion B1 SD3.0 support. Add O2Micro/BayHubTech chip 8620 and 8621 SD3.0 support Enable Led function of 8520 chip. Signed-off-by:
Peter Guo <peter.guo@bayhubtech.com> Signed-off-by:
Adam Lee <adam.lee@canonical.com> Signed-off-by:
-
Balaji T K authored
moving dmaengine consumer specific function to omap-dmaengine.h to Resolve build failure seen with sh-allmodconfig: include/linux/omap-dma.h:171:8: error: expected identifier before numeric constant make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1 Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by:Balaji T K <balajitk@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Balaji T K authored
Check for set block count command fails always since host->cmd is set to NULL in the same function incorrectly. Correct host->cmd usage properly. Signed-off-by:
-
Balaji T K authored
With devm_ioremap_resource conversion release_mem_region, iounmap can be removed in clean up path Signed-off-by:
-
Balaji T K authored
With devm_request_threaded_irq conversion free_irq can be removed in clean up path Signed-off-by:
-
Balaji T K authored
With devm_request_irq conversion free_irq can be removed in clean up path Signed-off-by:
-
Balaji T K authored
With devm_clk_get conversion clk_put can be removed in clean up path Signed-off-by:
-
David Lanzendörfer authored
The Allwinner sunxi mmc host uses dma in bus-master mode using a built-in designware idmac controller, which is identical to the one found in the mmc-dw hosts. However the rest of the host is not identical to mmc-dw, it deals with sending stop commands in hardware which makes it significantly different from the mmc-dw devices. Signed-off-by:
David Lanzendörfer <david.lanzendoerfer@o2s.ch> [hdegoede@redhat.com: various cleanups and fixes] Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Axel Lin authored
Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
-
Axel Lin authored
Also uses NSEC_PER_SEC and USEC_PER_SEC instead of hard-coded value. This makes the intention more clear. Signed-off-by:
-
Doug Anderson authored
Data errors are completely expected during tuning. Printing them out is confusing people looking at the kernel logs. They see things like: [ 3.613296] dwmmc_exynos 12200000.dwmmc0: data error, status 0x00000088 ...and they think something is wrong with their hardware. Remove the printouts. We'll leave it up to a higher level to report about errors. Signed-off-by:
Doug Anderson <dianders@chromium.org> Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
-
Russell King authored
Track whether preset mode is currently enabled in hardware, and use that when making decisions elsewhere in the code rather than reading the register and checking the bit. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Tested-by:
Markus Pargmann <mpa@pengutronix.de> Tested-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Russell King authored
Move the remaining parts of the power handling in sdhci_do_set_ios() into sdhci_set_power(). Signed-off-by:
-
Russell King authored
Move the regulator handling into sdhci_set_power() rather than being in sdhci_do_set_ios(). This wraps all power control up into this function. Signed-off-by:
-
Russell King authored
sdhci-tegra provides a get_ro method, which overrides the checking of the write protect bit in the PRESENT_STATE register in sdhci.c: if (host->flags & SDHCI_DEVICE_DEAD) is_readonly = 0; else if (host->ops->get_ro) is_readonly = host->ops->get_ro(host); else is_readonly = !(sdhci_readl(host, SDHCI_PRESENT_STATE) & SDHCI_WRITE_PROTECT); This means it's pointless detecting accesses to this register and manually setting the SDHCI_WRITE_PROTECT as it has no effect. This means that the whole of tegra_sdhci_readl() can be removed and we can use the builtin sdhci readl functionality here. Signed-off-by: -
Russell King authored
The only user (sdhci-of-esdhc) no longer uses these callbacks, so lets remove them to discourage any further use. Signed-off-by:
-
Russell King authored
We don't need these hooks in order to insert code in these paths, we can just provide our own handlers and call the main sdhci handlers as appropriate. Signed-off-by:
-
Russell King authored
We no longer need to emulate the uhs_mode field of the host control2 register - the main sdhci driver never reads this back to evaluate the current mode as it caches the current mode instead. Signed-off-by:
-
Russell King authored
Clean up the code in sdhci_execute_tuning() so the decision whether to execute tuning is clearer - and despite this reflecting what the original code was doing, it shows that it may not be what the author actually intended. Signed-off-by:
-
Russell King authored
Rather than reading back the timing information from the registers, cache it locally. This allows implementations to translate the UHS timing by overriding the set_uhs_signaling() method as required without also having to emulate the SDHCI_HOST_CONTROL2 register. Signed-off-by:
-
Russell King authored
Add sdhci_set_uhs_signaling() and always call the set_uhs_signaling method. This avoids quirks being added into sdhci_set_uhs_signaling(). Signed-off-by:
-
Russell King authored
The set_uhs_signaling() method gives the impression that it can fail, but anything returned from the method is entirely ignored by the sdhci driver. So returning failure has no effect. So, kill the idea that it's possible for this to return an error by removing the returned value. Signed-off-by:
-
Russell King authored
================================= [ INFO: inconsistent lock state ] 3.14.0-rc1+ #490 Not tainted --------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. kworker/u8:0/6 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&host->lock)->rlock#2){?.-...}, at: [<c04b57a4>] esdhc_send_tuning_cmd+0x104/0x14c {IN-HARDIRQ-W} state was registered at: [<c00652fc>] mark_lock+0x15c/0x6f8 [<c0066354>] __lock_acquire+0xabc/0x1ca0 [<c0067ad8>] lock_acquire+0xa0/0x130 [<c0697a44>] _raw_spin_lock+0x34/0x44 [<c04b0dbc>] sdhci_irq+0x20/0xa40 [<c0071b1c>] handle_irq_event_percpu+0x74/0x284 [<c0071d70>] handle_irq_event+0x44/0x64 [<c0074db8>] handle_fasteoi_irq+0xac/0x140 [<c007147c>] generic_handle_irq+0x28/0x38 [<c000efd4>] handle_IRQ+0x40/0x98 [<c0008584>] gic_handle_irq+0x30/0x64 [<c0013144>] __irq_svc+0x44/0x58 [<c0028fc8>] irq_exit+0xc0/0x120 [<c000efd8>] handle_IRQ+0x44/0x98 [<c0008584>] gic_handle_irq+0x30/0x64 [<c0013144>] __irq_svc+0x44/0x58 [<c068f398>] printk+0x3c/0x44 [<c03191d0>] _regulator_get+0x1b4/0x1e0 [<c031924c>] regulator_get+0x18/0x1c [<c049fbc4>] mmc_add_host+0x30/0x1c0 [<c04b2e10>] sdhci_add_host+0x804/0xbbc [<c04b5318>] sdhci_esdhc_imx_probe+0x380/0x674 [<c036d530>] platform_drv_probe+0x20/0x50 [<c036b948>] driver_probe_device+0x120/0x234 [<c036baf8>] __driver_attach+0x9c/0xa0 [<c036a04c>] bus_for_each_dev+0x5c/0x90 [<c036b418>] driver_attach+0x24/0x28 [<c036b018>] bus_add_driver+0xe4/0x1d8 [<c036c1b0>] driver_register+0x80/0xfc [<c036ce28>] __platform_driver_register+0x50/0x64 [<c093706c>] sdhci_esdhc_imx_driver_init+0x18/0x20 [<c0008834>] do_one_initcall+0x3c/0x164 [<c0901c94>] kernel_init_freeable+0x104/0x1d0 [<c068c45c>] kernel_init+0x10/0x118 [<c000e768>] ret_from_fork+0x14/0x2c irq event stamp: 5933 hardirqs last enabled at (5933): [<c069813c>] _raw_spin_unlock_irqrestore+0x38/0x4c hardirqs last disabled at (5932): [<c0697b04>] _raw_spin_lock_irqsave+0x24/0x60 softirqs last enabled at (5914): [<c0028ba0>] __do_softirq+0x260/0x360 softirqs last disabled at (5909): [<c0028fc8>] irq_exit+0xc0/0x120 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&host->lock)->rlock#2); <Interrupt> lock(&(&host->lock)->rlock#2); *** DEADLOCK *** 2 locks held by kworker/u8:0/6: #0: (kmmcd){.+.+.+}, at: [<c003d890>] process_one_work+0x134/0x4e8 #1: ((&(&host->detect)->work)){+.+.+.}, at: [<c003d890>] process_one_work+0x134/0x4e8 stack backtrace: CPU: 2 PID: 6 Comm: kworker/u8:0 Not tainted 3.14.0-rc1+ #490 Workqueue: kmmcd mmc_rescan Backtrace: [<c00124a0>] (dump_backtrace) from [<c0012640>] (show_stack+0x18/0x1c) [<c0012628>] (show_stack) from [<c069164c>] (dump_stack+0x70/0x8c) [<c06915dc>] (dump_stack) from [<c068f080>] (print_usage_bug+0x274/0x2e4) [<c068ee0c>] (print_usage_bug) from [<c0065774>] (mark_lock+0x5d4/0x6f8) [<c00651a0>] (mark_lock) from [<c0065e6c>] (__lock_acquire+0x5d4/0x1ca0) [<c0065898>] (__lock_acquire) from [<c0067ad8>] (lock_acquire+0xa0/0x130) [<c0067a38>] (lock_acquire) from [<c0697a44>] (_raw_spin_lock+0x34/0x44) [<c0697a10>] (_raw_spin_lock) from [<c04b57a4>] (esdhc_send_tuning_cmd+0x104/0x14c) [<c04b56a0>] (esdhc_send_tuning_cmd) from [<c04b582c>] (esdhc_executing_tuning+0x40/0x100) [<c04b57ec>] (esdhc_executing_tuning) from [<c04afa54>] (sdhci_execute_tuning+0xcc/0x754) [<c04af988>] (sdhci_execute_tuning) from [<c04a4684>] (mmc_sd_init_card+0x65c/0x694) [<c04a4028>] (mmc_sd_init_card) from [<c04a48f0>] (mmc_attach_sd+0xb0/0x184) [<c04a4840>] (mmc_attach_sd) from [<c049eb28>] (mmc_rescan+0x26c/0x2e8) [<c049e8bc>] (mmc_rescan) from [<c003d914>] (process_one_work+0x1b8/0x4e8) [<c003d75c>] (process_one_work) from [<c003e090>] (worker_thread+0x13c/0x3f8) [<c003df54>] (worker_thread) from [<c00449bc>] (kthread+0xcc/0xe8) [<c00448f0>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c) Signed-off-by: -
Russell King authored
It is far from obvious what this is doing, and it looks like it's an unbalanced runtime_pm_get() call. However, the put is inside sdhci_tasklet_finish(), so it's not unbalanced at all. This should be documented so people know what's going on here. Do so. Signed-off-by:
-
Russell King authored
sdhci-esdhc-imx tries to DMA to the kernel stack when tuning the interface, which causes dma-debug to complain. Fix this by kmallocing a buffer to hold the received tuning pattern. Signed-off-by:
-
Russell King authored
Signed-off-by:
-
Russell King authored
Move the setting of mmc->actual_clock to zero into the set_clock handlers themselves. This will allow us to clean up the calling logic for the set_clock() method, and turn sdhci_set_clock() into a library function. Signed-off-by:
-
Russell King authored
We don't need implementations to do this, since the only time it's necessary is when we change the clock, and the only place that happens is in sdhci_do_set_ios(). So, move it there, and remove it from the iMX platform backend. Signed-off-by:
-
Russell King authored
Only one caller to sdhci_set_clock() needs to check whether the requested clock frequency was the same as the currently set frequency, yet we work around this in several other sites via sdhci_update_clock(). Rather than doing this, move those checks out into sdhci_do_set_ios(), which then allows sdhci_update_clock() to be eliminated. Signed-off-by:
-
Russell King authored
Rather than using the streaming API, use the coherent allocator to provide this memory, thereby eliminating cache flushing of it each time we map and unmap it. This results in a 7.5% increase in transfer speed with a UHS-1 card operating in 3.3v mode at a clock of 49.5MHz. Signed-off-by:
-
Russell King authored
On read, we don't need to sync the whole scatterlist and then check whether any segments need copying - if we check first, we avoid potentially expensive cache handling. Signed-off-by:
-
Russell King authored
The Freescale esdhc driver is the only driver which needs the interrupt registers restored after a reset. Move this quirk to be part of the ESDHC driver implementation. Signed-off-by:
-
Russell King authored
Rather than having platform_reset_enter/platform_reset_exit methods, turn the core of the reset handling into a library function which platforms can call at the appropriate moment in their (new) reset method. Signed-off-by:
-
Russell King authored
Signed-off-by:
-
Russell King authored
When we disable card detection interrupts, we should disable both the insert and remove interrupts irrespective of the current state - this avoids races between the hardware card detect changing state before we've read that updated state and altered the interrupt mask. Signed-off-by:
-
Russell King authored
Rather than wasting cycles read-modify-writing the interrupt enable registers, cache the value locally instead. Signed-off-by:
-
Russell King authored
Allow SDIO interrupts to be received while the SDHCI host is runtime suspended. We do this by leaving the AHB clock enabled while the host is runtime suspended so we can access the SDHCI registers, and so read and raise the SDIO card interrupt. Signed-off-by:
-
Russell King authored
There's no requirement to have the card tasklet separate now that we have a threaded interrupt handler, so kill this and move the called code into the threaded part of the handler. Signed-off-by:
-
