- 22 May, 2014 30 commits
-
-
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 <rmk+kernel@arm.linux.org.uk> Tested-by:
Markus Pargmann <mpa@pengutronix.de> Tested-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Chris Ball <chris@printf.net>
-
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:
-
Russell King authored
Use a generic threaded interrupt handler for SDIO interrupt handling, rather than allowing the SDIO core code to buggily spawn its own thread. This results in host drivers to be more in control of how SDIO interrupts are acknowledged in the hardware, rather than having the internals of the SDIO core placed upon them, possibly resulting in sub-standard handling. At least one SDHCI implementation specifies a very specific sequence to deal with a card interrupt. Signed-off-by:
-
Russell King authored
We don't need to change the SDHCI_SDIO_IRQ_ENABLED flag when we're merely receiving an interrupt - IRQ handling thread in the MMC core will either re-enable or disable the interrupt via the enable_sdio_irq callback, which will update this status appropriately. Signed-off-by:
-
Russell King authored
sdhci interrupt handling is a mess; there is a lot of code doing very similar things. Let's clean this up a bit: 1. set's clear down cmd, data and bus power interrupts in one go - we're always going to handle these. 2. use a do { } while () loop for looping while there are pending interrupts. 3. group clearing of bits in intmask into one place. This results in the code becoming simpler and easier to read. Signed-off-by: -
Russell King authored
Rather than the SDIO support spawning it's own thread for handling card interrupts, use the generic IRQ infrastructure for this, triggering it from the host interface's interrupt handling directly. This avoids a race between the parent thread waiting to receive an interrupt response from the card, and the slow startup from the sdio irq thread, which can occur as a result of high system load (eg, while udev is running.) Signed-off-by:
-
- 14 May, 2014 1 commit
-
-
Nick Sanders authored
This patch removes an unneccesary 1ms mdelay in the HS200 tuning loop, called 40 times per retuning. Currently this causes a latency of >40ms on any emmc accesses triggering wake from runtime PM, which can occur for a significant portion of reads on a mostly idle system. The delay is left in place for SD Cards, which use MMC_SEND_TUNING_BLOCK rather than MMC_SEND_TUNING_BLOCK_HS200. I'm not able to find evidence that this is required for SD in the specs I have access to, however this delay has been present from initial checkin for SD so I have preserved the original behavior for compatibility. This has been verified to fix observed glitching on local audio playback and recording on apps with inbuilt assumptions on storage latency. Signed-off-by:
Nick Sanders <nsanders@chromium.org> Reviewed-by:
Grant Grundler <grundler@chromium.org> Reviewed-by:
Doug Anderson <dianders@chromium.org> Acked-by:
-
- 12 May, 2014 9 commits
-
-
Ulf Hansson authored
Update Ian Molton's email, the maintainer for tmio/sh_mobile_sdhci. Cc: Ian Molton <ian.molton@codethink.co.uk> Signed-off-by:
Ian Molton <ian.molton@codethink.co.uk> Signed-off-by:
-
Tim Kryger authored
Callers of mmc_regulator_get_supply could benefit from knowing if either of the regulators are present but not yet available. Since callers do not currently examine the return value, modify this function to return zero or -EPROBE_DEFER if either regulator get returns the same. Furthermore, since callers check vmmc/vqmmc using IS_ERR and can deal with absent regulators, switch to devm_regulator_get_optional. This has the added benefit of allowing this function to behave correctly even in the !CONFIG_REGULATOR case such that the stub can be removed. Signed-off-by:
Tim Kryger <tim.kryger@linaro.org> Signed-off-by:
-
Alexander Shiyan authored
This patch replaces regulator manipulation with mmc_regulator_get_supply() function from MMC core. Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Alexandre Belloni authored
Found using smatch: drivers/mmc/host/atmel-mci.c:827 atmci_pdc_complete() warn: variable dereferenced before check 'host->data' (see line 807) Stop testing host->data as it is not NULL at that point. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Arnd Bergmann authored
rtsx_usb_sdmmc module uses the LED classdev if available, but the code failed to consider the situation that it is built-in and the LED classdev is a module, leading to following linking error: LD init/built-in.o drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove': rtsx_usb_sdmmc.c:(.text+0x2a018e): undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe': rtsx_usb_sdmmc.c:(.text+0x2a197e): undefined reference to `led_classdev_register' Fix by excluding such condition when defining macro RTSX_USB_USE_LEDS_CLASS. Signed-off-by:
Roger Tseng <rogerable@realtek.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Daniel Willmann authored
Return -ENOSYS in get_cd if broken-cd is specified in the device tree. Commit a91fe279 (mmc: mxs: use standard flag for broken card detection) sets MMC_CAP_NEEDS_POLL when broken-cd is specified. This driver sets this flag unconditionally as it does not support a card detect interrupt. Instead, broken-cd means that there is no card detect signal connected. The mmc core checks the get_cd function return value to determine if a card is present. Only for a non-zero return value it will attempt to initialize the card. So retuning -ENOSYS will allow the card to be initialized. For comparison, mmc_gpio_get_cd in slot-gpio.c also returns -ENOSYS if the card detect GPIO is not valid. Signed-off-by:
Daniel Willmann <daniel@totalueberwachung.de> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Alex Smith authored
As of commit bcc3e172 ("mmc: block: Use R1 responses for stop cmds for read requests"), stop commands for reads do not have MMC_RSP_BUSY set. In this case we should not wait for a PRG_DONE IRQ after sending the stop command: it will not get raised when the busy flag is not set, causing the request to fail with a timeout. Signed-off-by:
Alex Smith <alex.smith@imgtec.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Chris Ball <chris@printf.net> Cc: James Hogan <james.hogan@imgtec.com> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Seungwon Jeon authored
Provide the option to configure these speed modes per host, for those host driver's that can't distinguish this in runtime. Specially, if host can support HS400, it means that host can also support HS200. Signed-off-by:
Seungwon Jeon <tgih.jun@samsung.com> Signed-off-by:
-
Seungwon Jeon authored
This patch adds HS400 mode support for eMMC5.0 device. HS400 mode is high speed DDR interface timing from HS200. Clock frequency is up to 200MHz and only 8-bit bus width is supported. In addition, tuning process of HS200 is required to synchronize the command response on the CMD line because CMD input timing for HS400 mode is the same as HS200 mode. Signed-off-by:
Jackey Shen <jackey.shen@amd.com> Tested-by:
Jaehoon Chung <jh80.chung@samsung.com> Acked-by:
-
