- 22 5月, 2014 18 次提交
-
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> [Ulf Hansson] Resolved conflict Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> [Ulf Hansson] Resolved conflict Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
Rather than wasting cycles read-modify-writing the interrupt enable registers, cache the value locally instead. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NMarkus Pargmann <mpa@pengutronix.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
- 14 5月, 2014 1 次提交
-
-
由 Nick Sanders 提交于
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: NNick Sanders <nsanders@chromium.org> Reviewed-by: NGrant Grundler <grundler@chromium.org> Reviewed-by: NDoug Anderson <dianders@chromium.org> Acked-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
- 21 4月, 2014 1 次提交
-
-
由 Seungwon Jeon 提交于
Added MMC_DDR52 as eMMC's DDR mode is distinguished from SD-UHS. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
- 26 3月, 2014 1 次提交
-
-
由 Arend van Spriel 提交于
When the host->tuning_count is zero it means that the retuning is disabled. This is checked on the first run of sdhci_execute_tuning() by the if statement below: if (!(host->flags & SDHCI_NEEDS_RETUNING) && host->tuning_count && (host->tuning_mode == SDHCI_TUNING_MODE_1)) { So only when tuning_count is non-zero it will set the host flag SDHCI_USING_RETUNING_TIMER. The else statement is only for re-programming the timer, which means that flag must be set. Because that is not checked the else statement is executed in the first run when tuning_count is zero. This was seen on a host controller which indicated SDHCI_TUNING_MODE_1 (0) and tuning_count being zero. Suspect that (one of) these registers is not properly set. Signed-off-by: NArend van Spriel <arend@broadcom.com> Acked-by: NUlf Hansson <ulf.hansson@linaro.org> Reviewed-by: NAaron Lu <aaron.lu@intel.com> Signed-off-by: NChris Ball <chris@printf.net>
-
- 17 3月, 2014 1 次提交
-
-
由 Adrian Hunter 提交于
If the SDHCI irq is shared with another device then the interrupt handler can get called while SDHCI is runtime suspended. That is harmless but the warning message is not useful so remove it. Also returning IRQ_NONE is more appropriate. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NChris Ball <chris@printf.net>
-
- 23 2月, 2014 3 次提交
-
-
由 Ulf Hansson 提交于
To better reflect that the cmd_timeout_ms is directly related to the busy detection timeout, let's rename it. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Ulf Hansson 提交于
Rename host->max_discard_to to host->max_busy_timeout, to reflect that it tells the mmc core layer about the maximum supported busy detection timeout by the host. This timeout is at the moment only applicable to erase/trim/discard commands. By the renaming we provide the option of make use of it for other commands that cares about busy detection. In other words, those commands that wants an R1B response, like for example the mmc switch command. Do note that the max_busy_timeout is supposed to be specified only by hosts supporting MMC_CAP_WAIT_WHILE_BUSY. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Micky Ching 提交于
Add support for realtek rts5250 pci card reader. The card reader has some problems with DDR50 mode, so add a new quirks2 for broken ddr50. Signed-off-by: NMicky Ching <micky_ching@realsil.com.cn> Signed-off-by: NChris Ball <chris@printf.net>
-
- 20 1月, 2014 1 次提交
-
-
由 Adrian Hunter 提交于
The driver has a timer with a 10 second timeout to catch devices that stop responding. However it is possible for commands to take even longer than that. Change the timer timeout to reflect the command timeout. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NChris Ball <chris@printf.net>
-
- 18 1月, 2014 1 次提交
-
-
由 Aisheng Dong 提交于
The sdhci_execute_tuning routine gets lock separately by disable_irq(host->irq); spin_lock(&host->lock); It will cause the following lockdep error message since the &host->lock could also be got in irq context. Use spin_lock_irqsave/spin_unlock_restore instead to get rid of this error message. [ INFO: inconsistent lock state ] 3.13.0-rc1+ #287 Not tainted --------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. kworker/u2:1/33 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&host->lock)->rlock){?.-...}, at: [<8045f7f4>] sdhci_execute_tuning+0x4c/0x710 {IN-HARDIRQ-W} state was registered at: [<8005f030>] mark_lock+0x140/0x6ac [<80060760>] __lock_acquire+0xb30/0x1cbc [<800620d0>] lock_acquire+0x70/0x84 [<8061d1c8>] _raw_spin_lock+0x30/0x40 [<804605cc>] sdhci_irq+0x24/0xa68 [<8006b1d4>] handle_irq_event_percpu+0x54/0x18c [<8006b350>] handle_irq_event+0x44/0x64 [<8006e50c>] handle_fasteoi_irq+0xa0/0x170 [<8006a8f0>] generic_handle_irq+0x30/0x44 [<8000f238>] handle_IRQ+0x54/0xbc [<8000864c>] gic_handle_irq+0x30/0x64 [<80013024>] __irq_svc+0x44/0x5c [<80329bf4>] dev_vprintk_emit+0x50/0x58 [<80329c24>] dev_printk_emit+0x28/0x30 [<80329fec>] __dev_printk+0x4c/0x90 [<8032a180>] dev_err+0x3c/0x48 [<802dd4f0>] _regulator_get+0x158/0x1cc [<802dd5b4>] regulator_get_optional+0x18/0x1c [<80461df4>] sdhci_add_host+0x42c/0xbd8 [<80464820>] sdhci_esdhc_imx_probe+0x378/0x67c [<8032ee88>] platform_drv_probe+0x20/0x50 [<8032d48c>] driver_probe_device+0x118/0x234 [<8032d690>] __driver_attach+0x9c/0xa0 [<8032b89c>] bus_for_each_dev+0x68/0x9c [<8032cf44>] driver_attach+0x20/0x28 [<8032cbc8>] bus_add_driver+0x148/0x1f4 [<8032dce0>] driver_register+0x80/0x100 [<8032ee54>] __platform_driver_register+0x50/0x64 [<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20 [<80008980>] do_one_initcall+0x108/0x16c [<8081cca4>] kernel_init_freeable+0x10c/0x1d0 [<80611b28>] kernel_init+0x10/0x120 [<8000e9c8>] ret_from_fork+0x14/0x2c irq event stamp: 805 hardirqs last enabled at (805): [<8061d43c>] _raw_spin_unlock_irqrestore+0x38/0x4c hardirqs last disabled at (804): [<8061d2c8>] _raw_spin_lock_irqsave+0x24/0x54 softirqs last enabled at (570): [<8002b824>] __do_softirq+0x1c4/0x290 softirqs last disabled at (561): [<8002bcf4>] irq_exit+0xb4/0x10c other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&host->lock)->rlock); <Interrupt> lock(&(&host->lock)->rlock); *** DEADLOCK *** 2 locks held by kworker/u2:1/33: #0: (kmmcd){.+.+..}, at: [<8003db18>] process_one_work+0x128/0x468 #1: ((&(&host->detect)->work)){+.+...}, at: [<8003db18>] process_one_work+0x128/0x468 stack backtrace: CPU: 0 PID: 33 Comm: kworker/u2:1 Not tainted 3.13.0-rc1+ #287 Workqueue: kmmcd mmc_rescan Backtrace: [<80012160>] (dump_backtrace+0x0/0x10c) from [<80012438>] (show_stack+0x18/0x1c) r6:bfad0900 r5:00000000 r4:8088ecc8 r3:bfad0900 [<80012420>] (show_stack+0x0/0x1c) from [<806169ec>] (dump_stack+0x84/0x9c) [<80616968>] (dump_stack+0x0/0x9c) from [<806147b4>] (print_usage_bug+0x260/0x2d0) r5:8076ba88 r4:80977410 [<80614554>] (print_usage_bug+0x0/0x2d0) from [<8005f0d0>] (mark_lock+0x1e0/0x6ac) r9:8005e678 r8:00000000 r7:bfad0900 r6:00001015 r5:bfad0cd0 r4:00000002 [<8005eef0>] (mark_lock+0x0/0x6ac) from [<80060234>] (__lock_acquire+0x604/0x1cbc) [<8005fc30>] (__lock_acquire+0x0/0x1cbc) from [<800620d0>] (lock_acquire+0x70/0x84) [<80062060>] (lock_acquire+0x0/0x84) from [<8061d1c8>] (_raw_spin_lock+0x30/0x40) r7:00000000 r6:bfb63000 r5:00000000 r4:bfb60568 [<8061d198>] (_raw_spin_lock+0x0/0x40) from [<8045f7f4>] (sdhci_execute_tuning+0x4c/0x710) r4:bfb60000 [<8045f7a8>] (sdhci_execute_tuning+0x0/0x710) from [<80453454>] (mmc_sd_init_card+0x5f8/0x660) [<80452e5c>] (mmc_sd_init_card+0x0/0x660) from [<80453748>] (mmc_attach_sd+0xb4/0x180) r9:bf92d400 r8:8065f364 r7:00061a80 r6:bfb60000 r5:8065f358 r4:bfb60000 [<80453694>] (mmc_attach_sd+0x0/0x180) from [<8044d9f8>] (mmc_rescan+0x284/0x2f0) r5:8065f358 r4:bfb602f8 [<8044d774>] (mmc_rescan+0x0/0x2f0) from [<8003db94>] (process_one_work+0x1a4/0x468) r8:00000000 r7:bfb55eb0 r6:bf80dc00 r5:bfb602f8 r4:bfb35980 r3:8044d774 [<8003d9f0>] (process_one_work+0x0/0x468) from [<8003e850>] (worker_thread+0x118/0x3e0) [<8003e738>] (worker_thread+0x0/0x3e0) from [<80044de0>] (kthread+0xd4/0xf0) [<80044d0c>] (kthread+0x0/0xf0) from [<8000e9c8>] (ret_from_fork+0x14/0x2c) r7:00000000 r6:00000000 r5:80044d0c r4:bfb37b40 Signed-off-by: NDong Aisheng <b29396@freescale.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NChris Ball <chris@printf.net>
-
- 14 1月, 2014 2 次提交
-
-
由 David Cohen 提交于
This patch defines a quirk for platforms unable to enable HS200 support. Signed-off-by: NDavid Cohen <david.a.cohen@linux.intel.com> Reviewed-by: NChuanxiao Dong <chuanxiao.dong@intel.com> Acked-by: NDong Aisheng <b29396@freescale.com> Cc: stable <stable@vger.kernel.org> # [3.13] Signed-off-by: NChris Ball <chris@printf.net>
-
由 Chuansheng Liu 提交于
In function sdhci_request(), it is possible to do the tuning execution like below: sdhci_request() { spin_lock_irqsave(&host->lock, flags); host->mrq = mrq; ... spin_unlock_irqrestore(&host->lock, flags); <=== Here it is possible one pending finish_tasklet get running and it will operate the original mrq, and notified the mrq is done, and causes memory corruption. sdhci_execute_tuning(mmc, tuning_opcode); spin_lock_irqsave(&host->lock, flags); host->mrq = mrq; ... } In the above race place, the original mrq should not be finished wrongly, so here before unlock the spinlock, we need to set the host->mrq to NULL to avoid this case. Signed-off-by: NLiu, Chuansheng <chuansheng.liu@intel.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 27 11月, 2013 1 次提交
-
-
由 Dong Aisheng 提交于
The auto cmd settings bits should be cleared before sending new commands or we may receive command timeout error for normal commands due to wrongly pre-sent auto cmd. e.g. we receive CMD13 timeout error due to ACMD23 is wrongly enabled by former data commands. mmc2: new high speed DDR MMC card at address 0001 mmcblk1: mmc2:0001 SEM08G 7.39 GiB mmcblk1boot0: mmc2:0001 SEM08G partition 1 2.00 MiB mmcblk1boot1: mmc2:0001 SEM08G partition 2 2.00 MiB mmcblk1rpmb: mmc2:0001 SEM08G partition 3 128 KiB mmcblk1: p1 p2 p3 p4 < p5 p6 p7 > mmc2: Timeout waiting for hardware interrupt. mmcblk1boot1: unknown partition table mmc2: Timeout waiting for hardware interrupt. mmcblk1boot0: unknown partition table Signed-off-by: NDong Aisheng <b29396@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 09 11月, 2013 1 次提交
-
-
由 Alexey Neyman 提交于
Ignore Card Interrupt bit in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). This avoids a needless loop in sdhci_irq() repeatedly reading interrupt status and doing nothing. Signed-off-by: NAlexey Neyman <stilor@att.net> Acked-by: NDong Aisheng <b29396@freescale.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 31 10月, 2013 1 次提交
-
-
由 Ulf Hansson 提交于
Suspend and resume of cards are being handled from the protocol layer and consequently the mmc_suspend|resume_host APIs are deprecated. This means we can simplify the suspend|resume callbacks by removing the use of the deprecated APIs. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 22 10月, 2013 2 次提交
-
-
由 Dong Aisheng 提交于
Remove unneeded call of call sdhci_enable_preset_value when having SDHCI_QUIRK2_PRESET_VALUE_BROKEN. Signed-off-by: NDong Aisheng <b29396@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Dong Aisheng 提交于
The original code missed to report an error when the maximum tuning loops exhausted or timeout, it will cause the upper layer to wrongly think the tuning process is passed. Signed-off-by: NDong Aisheng <b29396@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 26 9月, 2013 2 次提交
-
-
由 Dong Aisheng 提交于
It helps for platform code to use it send tuning commands. Signed-off-by: NDong Aisheng <b29396@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Dong Aisheng 提交于
The tuning of some platforms may not follow the standard host control spec v3.0, e.g. Freescale uSDHC on i.MX6Q/DL. Add a hook here to allow execute platform specific tuning instead of standard host controller tuning. The hook only replaces the tuning process, so it's placed after tuning checking and before the real tuning process. Some notes for the tuning hook: 1) it needs handle lock itself if it wants to access host controller according platform specific implementation. 2) do not need to handle runtime pm since it executes with runtime pm get already. Signed-off-by: NDong Aisheng <b29396@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 26 8月, 2013 1 次提交
-
-
由 Haijun Zhang 提交于
We use host->ocr_mask to hold the voltage get from device-tree node, In case host->ocr_mask was available, we use host->ocr_mask as the final available voltage can be used by MMC/SD/SDIO card. Signed-off-by: NHaijun Zhang <haijun.zhang@freescale.com> Reviewed-by: NAnton Vorontsov <anton@enomsg.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 25 8月, 2013 1 次提交
-
-
由 Shawn Guo 提交于
Generally request_irq() should be called after hardware has been initialized into a sane state. However, sdhci driver currently calls request_irq() before sdhci_init(). At least, the following kernel panic seen on i.MX6 is caused by that. The sdhci controller on i.MX6 may have noisy glitch on DAT1 line, which will trigger SDIO interrupt handling once request_irq() is called. But at this point, the SDIO interrupt handler host->sdio_irq_thread has not been registered yet. Thus, we see the NULL pointer access with wake_up_process(host->sdio_irq_thread) in mmc_signal_sdio_irq(). Fix the panic by simply reverse the calling sequence between request_irq() and sdhci_init(). sdhci-pltfm: SDHCI platform and OF driver helper mmc0: no vqmmc regulator found mmc0: no vmmc regulator found Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = 80004000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0+ #3 task: 9f860000 ti: 9f862000 task.ti: 9f862000 PC is at wake_up_process+0xc/0x44 LR is at sdhci_irq+0x378/0x93c pc : [<8004f768>] lr : [<803fb698>] psr: 40000193 sp : 9f863ba0 ip : 9f863bb8 fp : 9f863bb4 r10: 9f807900 r9 : 80761fbc r8 : 00000000 r7 : 00000000 r6 : 00000000 r5 : 00000001 r4 : 9fa68000 r3 : 00000001 r2 : 00000002 r1 : 20000193 r0 : 00000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 8000404a DAC: 00000017 Process swapper/0 (pid: 1, stack limit = 0x9f862238) Stack: (0x9f863ba0 to 0x9f864000) 3ba0: 00000001 9fa68000 9f863c04 9f863bb8 803fb698 8004f768 8011af00 80265aac 3bc0: 00000000 000003d9 00000000 9fa51880 00000001 00000000 9f863c14 9fa53640 3be0: 00000001 00000000 00000000 00000036 80761fbc 9f807900 9f863c3c 9f863c08 3c00: 80075154 803fb32c 802c2b38 802c63d8 802c63cc 9f807900 00000001 9f862000 3c20: 00000036 00000000 9f807930 60000113 9f863c54 9f863c40 800752ec 8007510c 3c40: 9f807900 00000001 9f863c6c 9f863c58 80078324 800752a8 00000036 8071fd64 3c60: 9f863c84 9f863c70 80074ac0 80078294 00000140 8072ab78 9f863cac 9f863c88 3c80: 8000ee34 80074aa4 00000000 a080e10c 8072acbc 9f863cd0 a080e100 00000036 3ca0: 9f863ccc 9f863cb0 80008600 8000edec 805386a8 60000113 ffffffff 9f863d04 3cc0: 9f863d24 9f863cd0 8000e0c0 800085dc 9f807950 60000113 00000007 00000000 3ce0: 9f807900 9fa53640 9f807950 9fa68240 00000036 9f807930 60000113 9f863d24 3d00: 9f863d28 9f863d18 80076834 805386a8 60000113 ffffffff 9f863d64 9f863d28 3d20: 80076834 80538688 00000000 800bfe4c 00002fac 00000001 9f863d54 9fa53640 3d40: 9f807900 803fb320 9fa68240 00000080 00000000 00000036 9f863d94 9f863d68 3d60: 80076b38 80076674 00000080 9fa68240 9fa68000 04000000 9fa6836c 9fa68380 3d80: 806d620c 80700350 9f863dc4 9f863d98 803fce8c 80076a88 9fa532c0 9fa68240 3da0: 9fa51490 9fa51490 9fa68240 00000000 9f8ae600 9f81d080 9f863df4 9f863dc8 3dc0: 803fea0c 803fc808 9f863de4 9f863dd8 80125850 807b1ed8 807576b8 9f8ae610 3de0: 00000000 807576b8 9f863e04 9f863df8 802ee0d4 803fe798 9f863e2c 9f863e08 3e00: 802ecd1c 802ee0c0 00000000 9f8ae610 807576b8 9f8ae644 00000000 000000a9 3e20: 9f863e4c 9f863e30 802ecec0 802ecc30 9f83355c 807576b8 802ece2c 00000000 3e40: 9f863e74 9f863e50 802eb3d8 802ece38 9f83355c 9f8ac3b4 9f833570 807576b8 3e60: 80746e70 9fa51400 9f863e84 9f863e78 802ec838 802eb388 9f863eb4 9f863e88 3e80: 802ec3d0 802ec824 80692748 807620c0 9f863eb4 807576b8 00000006 807620c0 3ea0: 00000000 000000a9 9f863edc 9f863eb8 802ed3e8 802ec2fc 9f862000 00000006 3ec0: 807620c0 00000000 000000a9 80700350 9f863eec 9f863ee0 802ee2f8 802ed374 3ee0: 9f863efc 9f863ef0 80700364 802ee2b8 9f863f54 9f863f00 8000870c 8070035c 3f00: 9f863f54 9f863f10 9f862000 00000000 00000000 00000006 00000006 806d3aa4 3f20: 00000000 80688b18 9f863f54 80713560 00000006 80713540 807620c0 000000a9 3f40: 806d620c 8071ec24 9f863f94 9f863f58 806d6994 800086dc 00000006 00000006 3f60: 806d620c f6bfffff fb7f5df7 00000000 8052da28 00000000 00000000 00000000 3f80: 00000000 00000000 9f863fac 9f863f98 8052da38 806d689c ffffffff 00000000 3fa0: 00000000 9f863fb0 8000e5d8 8052da34 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 d9cdf5ff 1fff5ffe Backtrace: [<8004f75c>] (wake_up_process+0x0/0x44) from [<803fb698>] (sdhci_irq+0x378/0x93c) r4:9fa68000 r3:00000001 [<803fb320>] (sdhci_irq+0x0/0x93c) from [<80075154>] (handle_irq_event_percpu+0x54/0x19c) [<80075100>] (handle_irq_event_percpu+0x0/0x19c) from [<800752ec>] (handle_irq_event+0x50/0x70) [<8007529c>] (handle_irq_event+0x0/0x70) from [<80078324>] (handle_fasteoi_irq+0x9c/0x170) r5:00000001 r4:9f807900 [<80078288>] (handle_fasteoi_irq+0x0/0x170) from [<80074ac0>] (generic_handle_irq+0x28/0x38) r5:8071fd64 r4:00000036 [<80074a98>] (generic_handle_irq+0x0/0x38) from [<8000ee34>] (handle_IRQ+0x54/0xb4) r4:8072ab78 r3:00000140 [<8000ede0>] (handle_IRQ+0x0/0xb4) from [<80008600>] (gic_handle_irq+0x30/0x64) r8:00000036 r7:a080e100 r6:9f863cd0 r5:8072acbc r4:a080e10c r3:00000000 [<800085d0>] (gic_handle_irq+0x0/0x64) from [<8000e0c0>] (__irq_svc+0x40/0x54) Exception stack(0x9f863cd0 to 0x9f863d18) 3cc0: 9f807950 60000113 00000007 00000000 3ce0: 9f807900 9fa53640 9f807950 9fa68240 00000036 9f807930 60000113 9f863d24 3d00: 9f863d28 9f863d18 80076834 805386a8 60000113 ffffffff r7:9f863d04 r6:ffffffff r5:60000113 r4:805386a8 [<8053867c>] (_raw_spin_unlock_irqrestore+0x0/0x30) from [<80076834>] (__setup_irq+0x1cc/0x414) [<80076668>] (__setup_irq+0x0/0x414) from [<80076b38>] (request_threaded_irq+0xbc/0x140) [<80076a7c>] (request_threaded_irq+0x0/0x140) from [<803fce8c>] (sdhci_add_host+0x690/0xb88) [<803fc7fc>] (sdhci_add_host+0x0/0xb88) from [<803fea0c>] (sdhci_esdhc_imx_probe+0x280/0x4d4) r8:9f81d080 r7:9f8ae600 r6:00000000 r5:9fa68240 r4:9fa51490 [<803fe78c>] (sdhci_esdhc_imx_probe+0x0/0x4d4) from [<802ee0d4>] (platform_drv_probe+0x20/0x24) r8:807576b8 r7:00000000 r6:9f8ae610 r5:807576b8 r4:807b1ed8 [<802ee0b4>] (platform_drv_probe+0x0/0x24) from [<802ecd1c>] (driver_probe_device+0xf8/0x208) [<802ecc24>] (driver_probe_device+0x0/0x208) from [<802ecec0>] (__driver_attach+0x94/0x98) r8:000000a9 r7:00000000 r6:9f8ae644 r5:807576b8 r4:9f8ae610 r3:00000000 [<802ece2c>] (__driver_attach+0x0/0x98) from [<802eb3d8>] (bus_for_each_dev+0x5c/0x90) r6:00000000 r5:802ece2c r4:807576b8 r3:9f83355c [<802eb37c>] (bus_for_each_dev+0x0/0x90) from [<802ec838>] (driver_attach+0x20/0x28) r6:9fa51400 r5:80746e70 r4:807576b8 [<802ec818>] (driver_attach+0x0/0x28) from [<802ec3d0>] (bus_add_driver+0xe0/0x234) [<802ec2f0>] (bus_add_driver+0x0/0x234) from [<802ed3e8>] (driver_register+0x80/0x14c) r8:000000a9 r7:00000000 r6:807620c0 r5:00000006 r4:807576b8 [<802ed368>] (driver_register+0x0/0x14c) from [<802ee2f8>] (platform_driver_register+0x4c/0x60) [<802ee2ac>] (platform_driver_register+0x0/0x60) from [<80700364>] (sdhci_esdhc_imx_driver_init+0x14/0x1c) [<80700350>] (sdhci_esdhc_imx_driver_init+0x0/0x1c) from [<8000870c>] (do_one_initcall+0x3c/0x164) [<800086d0>] (do_one_initcall+0x0/0x164) from [<806d6994>] (kernel_init_freeable+0x104/0x1d0) [<806d6890>] (kernel_init_freeable+0x0/0x1d0) from [<8052da38>] (kernel_init+0x10/0xec) [<8052da28>] (kernel_init+0x0/0xec) from [<8000e5d8>] (ret_from_fork+0x14/0x3c) r4:00000000 r3:ffffffff Code: e89da800 e1a0c00d e92dd818 e24cb004 (e5903000) ---[ end trace e9af3588936b63f0 ]--- Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 31 7月, 2013 1 次提交
-
-
由 Mark Brown 提交于
Use regulator_get_optional() to tell the core that requests for regulators can fail in a real system. Signed-off-by: NMark Brown <broonie@linaro.org> Acked-by: NChris Ball <cjb@laptop.org>
-
- 06 7月, 2013 1 次提交
-
-
由 Christian Daudt 提交于
Add a card_event callback to sdhci so that clients can provide their own card_event to be called when card_detect is triggered. Signed-off-by: NChristian Daudt <csd@broadcom.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-