summaryrefslogtreecommitdiffstats
path: root/drivers/mmc/host/sdhci.c
AgeCommit message (Collapse)Author
2013-10-21mmc: sdhci: remove unneeded call when have preset value quirkDong Aisheng
Remove unneeded call of call sdhci_enable_preset_value when having SDHCI_QUIRK2_PRESET_VALUE_BROKEN. Signed-off-by: Dong Aisheng <b29396@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-10-21mmc: sdhci: report error once the maximum tuning loops exhausted or timeoutDong 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: Dong Aisheng <b29396@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-09-26mmc: sdhci: allow platform access of sdhci_send_commandDong Aisheng
It helps for platform code to use it send tuning commands. Signed-off-by: Dong Aisheng <b29396@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-09-26mmc: sdhci: add hooks for platform specific tuningDong 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: Dong Aisheng <b29396@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-09-10Merge tag 'mmc-updates-for-3.12-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc Pull MMC updates from Chris Ball: "MMC highlights for 3.12: Core: - Support Allocation Units 8MB-64MB in SD3.0, previous max was 4MB. - The slot-gpio helper can now handle GPIO debouncing card-detect. - Read supported voltages from DT "voltage-ranges" property. Drivers: - dw_mmc: Add support for ARC architecture, and support exynos5420. - mmc_spi: Support CD/RO GPIOs. - sh_mobile_sdhi: Add compatibility for more Renesas SoCs. - sh_mmcif: Add DT support for DMA channels" * tag 'mmc-updates-for-3.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (50 commits) Revert "mmc: tmio-mmc: Remove .set_pwr() callback from platform data" mmc: dw_mmc: Add support for ARC mmc: sdhci-s3c: initialize host->quirks2 for using quirks2 mmc: sdhci-s3c: fix the wrong register value, when clock is disabled mmc: esdhc: add support to get voltage from device-tree mmc: sdhci: get voltage from sdhc host mmc: core: parse voltage from device-tree mmc: omap_hsmmc: use the generic config for omap2plus devices mmc: omap_hsmmc: clear status flags before starting a new command mmc: dw_mmc: exynos: Add a new compatible string for exynos5420 mmc: sh_mmcif: revision-specific CLK_CTRL2 handling mmc: sh_mmcif: revision-specific Command Completion Signal handling mmc: sh_mmcif: add support for Device Tree DMA bindings mmc: sh_mmcif: move header include from header into .c mmc: SDHI: add DT compatibility strings for further SoCs mmc: dw_mmc-pci: enable bus-mastering mode mmc: dw_mmc-pci: get resources from a proper BAR mmc: tmio-mmc: Remove .set_pwr() callback from platform data mmc: tmio-mmc: Remove .get_cd() callback from platform data mmc: sh_mobile_sdhi: Remove .set_pwr() callback from platform data ...
2013-08-26mmc: sdhci: get voltage from sdhc hostHaijun 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: Haijun Zhang <haijun.zhang@freescale.com> Reviewed-by: Anton Vorontsov <anton@enomsg.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-08-24mmc: sdhci: request irq after sdhci_init() is calledShawn 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: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-07-31mmc: sdhci: Indicate that regulators may be absentMark Brown
Use regulator_get_optional() to tell the core that requests for regulators can fail in a real system. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Chris Ball <cjb@laptop.org>
2013-07-05mmc: sdhci: add card_event callback to sdhciChristian 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: Christian Daudt <csd@broadcom.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-07-05mmc: sdhci: fix ctrl_2 on super-speed selectionGiuseppe CAVALLARO
This patch fixes the HC ctrl_2 programming where, in case of SDR104 and HS200, we have to write 100b in the the UHS Mode bits. We wrote 101b that is reserved from Arasan Specs. Reported-by: Youssef Triki <youssef.triki@st.com> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-06-27mmc: sdhci: fix caps2 for HS200Giuseppe CAVALLARO
Although the HC supports HS200 (eMMC) the caps2 are always zero; this means there's no way to use the super speed mode (when init the card). If the HC support SDR104, for SD3.0, so it also supports HS200 for eMMC and this patch just sets the MMC_CAP2_HS200 in the host caps2 field. Reported-by: Youssef Triki <youssef.triki@st.com> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Reviewed-by: Philip Rakity <prakity@nvidia.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-06-27mmc: sdhci: improve card removal check in sdhci_card_event()Shawn Guo
The following error randomly appears on an imx6q board where gpio is used to implement card-detection when mounting EXT4 rootfs during boot. mmc1: Card removed during transfer! mmc1: Resetting controller. mmcblk0: unknown error -123 sending read/write command, card status 0x900 end_request: I/O error, dev mmcblk0, sector 106744 EXT4-fs error (device mmcblk0p2): ext4_find_entry:1312: inode #5011: comm swapper/0: reading directory lblock 0 It turns out that the error message comes from the card removal check in function sdhci_card_event(). While we have a well implemented function sdhci_do_get_cd() handling all the possible cases of CD, the current code only checks controller internal CD case. That causes problem for other CD cases like gpio on above imx6q board. Improve the check by using sdhci_do_get_cd() to cover all possible CD cases, so that above error on the imx6q board gets fixed. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-05-26mmc: sdhci: add ability to stay runtime-resumed if the card is powered upAdrian Hunter
If card power is dependent on SD bus power then the host controller must not be runtime suspended while the card is powered up. Add the ability to stay runtime-resumed in that case and enable it with a new quirk SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-03-22mmc: sdhci: Don't ignore regulator_enable() return valueChris Ball
Fixes: /git/arm-soc/drivers/mmc/host/sdhci.c: In function 'sdhci_add_host': /git/arm-soc/drivers/mmc/host/sdhci.c:2910:19: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Wunused-result] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-03-22mmc: sdhci: add get_cd() implementationKevin Liu
1. mmc_rescan will call get_cd to know whether the card is present before mmc_rescan_try_freq to avoid useless trials during card removal or start host is called when card is not present. 2. get_cd needs to be checked to resolve slow card removal issue. Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-24mmc: sdhci: Fix parameter of sdhci_do_start_signal_voltage_switch()Fabio Estevam
3714f4315354 ("mmc: sdhci: update signal voltage switch code") changed the type of the second parameter of sdhci_do_start_signal_voltage_switch(), from "struct mmc_ios *ios" to "int signal_voltage" which causes the following build warning: drivers/mmc/host/sdhci.c:2044:2: warning: initialization from incompatible pointer type [enabled by default] drivers/mmc/host/sdhci.c:2044:2: warning: (near initialization for 'sdhci_ops.start_signal_voltage_switch') [enabled by default] Use the previous type so that it matches the start_signal_voltage_switch() definition from host.h. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Reviewed-by: Johan Rudholm <johan.rudholm@stericsson.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-24mmc: sdhci: check voltage range only on regulators aware of voltage valueMarek Szyprowski
Some regulators don't report any voltage values, so checking supported voltage range results in disabling all SDHCI_CAN_VDD_* flags and registration failure. This patch finally provides a correct fix for the registration of SDHCI driver with all possible voltage regulators: dummy, fixed and regulated without using regulator_count_voltages() hacks. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-24mmc: sdhci: enhance preset value functionKevin Liu
4d55c5a1 ("mmc: sdhci: enable preset value after uhs initialization") added preset value support and enabled it by default during sd card init. Below are the enhancements introduced by this patch: 1. In current code, preset value is enabled after setting clock finished, which means the clock is manually set by driver firstly and then suddenly switched to preset value at this point. So the first setting is useless and unnecessary. What's more, the first clock setting may differ from the preset one. The better way is enable preset value just after switch to UHS mode so the preset value can take effect immediately. So move preset value enable from mmc_sd_init_card to sdhci_set_ios which will be called during set timing. 2. In current code, preset value is disabled at the beginning of mmc_attach_sd. It's too late since low freq (400khz) should be set in mmc_power_up. So move preset value disable to sdhci_set_ios which will be called during power up. 3. host->clock and ios->drv_type should also be updated according to the preset value if it's enabled. Current code missed this. 4. This patch also introduce a quirk to disable preset value in case preset value doesn't work. This patch has been verified on sdhci-pxav3 platform with both preset enabled and disabled. Signed-off-by: Kevin Liu <kliu5@marvell.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-24mmc: sdhci: update signal voltage switch codeKevin Liu
The protocol related code is moved to core stack. So update the host driver accordingly. Signed-off-by: Kevin Liu <kliu5@marvell.com> Tested-by: Tim Wang <wangtt@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-24mmc: sdhci: rename platform_8bit_width to platform_bus_widthSascha Hauer
The 8bit in the function name is misleading. When set, it will be used to set the bus width, regardless of whether 8bit or another bus width is requested, so change the function name to platform_bus_width. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-11mmc: sdhci: introduce sdhci_update_clock helper to re-enable clockAndy Shevchenko
There are three places where same piece of code is used. Let's split it to a separate function. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-11mmc: sdhci: add IRQ wake up supportKevin Liu
Don't disable SD Host IRQ during suspend if it is wake up source. Enable wakeup event during suspend. Signed-off-by: Jialing Fu <jlfu@marvell.com> Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-11mmc: sdhci: disable interrupt before free_irqKevin Liu
Current code missed disabling interrupts before free irq which is shared. Notice below comments for function free_irq (kernel/irq/manage.c): On a shared IRQ the caller must ensure the interrupt is disabled on the card it drives before calling this function. Original code has below issue during suspend/resume when multiple SD hosts share the same IRQ: 1. Assume there are two hosts (host1 for emmc while host2 for sd) share the same mmc irq. 2. When system suspend, host2 will be suspended before host1. So the sequence is below: step1: irq handler for host2 removed -> step2: irq handler for host1 removed and irq disabled -> ... system suspended ... ... system resumed ... step3: irq enabled and the irq handler for host1 restored -> step4: irq handler for host2 restored 3. So there is the buggy time slot that the irq is enabled but the irq handler for host2 is removed. Then host2 interrupt can be triggered but can't be handled at that moment. Signed-off-by: Jialing Fu <jlfu@marvell.com> Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2013-02-11mmc: sdhci: query card presence from cd-gpio before asking SDHCIShawn Guo
Call mmc_gpio_get_cd() to query card presence from cd-gpio before asking SDHCI. The rationale behind this change is that flag SDHCI_QUIRK_BROKEN_CARD_DETECTION is designed for SDHCI controller to tell that SDHCI_PRESENT_STATE is broken, and it should be used for this case only. So when cd-gpio is being used, the controller should set the flag to tell that SDHCI_PRESENT_STATE is not available. However, the existing code will skip checking cd-gpio as long as flag SDHCI_QUIRK_BROKEN_CARD_DETECTION is set. Change the querying order between cd-gpio and SDHCI to support the rationale above. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-12-07mmc: sdhci: implement the .card_event() methodGuennadi Liakhovetski
Extracting a part of the SDHCI card tasklet into a .card_event() implementation allows SDHCI hosts to use generic card-detection services, e.g. the GPIO slot function. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-12-06mmc: eSDHC: Recover from ADMA errorsHaijun Zhang
A-003500: False ADMA Error might be reported when ADMA is used for multiple block read command with Stop at Block Gap. If PROCTL[SABGREQ] is set when the particular block's data is received by the System side logic before entire block (with CRC) data is received by the SD side logic, and also if ADMA descriptor line is fetched at the same time, then DMA engine might report false ADMA error. eSDHC might not be able to Continue (PROCTL[CREQ]=1) after Stop at Block Gap. This issue will impact the eSDHC IP VVN2.3. Signed-off-by: Haijun Zhang <Haijun.Zhang@freescale.com> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-12-06mmc: sdhci: add quirk for lack of 1.8v supportDaniel Drake
The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v capable, and it truthfully reports so in its capabilities. This alternate voltage is used for driving new "UHS-I" SD cards at their full speed. However, what the controller doesn't know is that the motherboard physically doesn't have a 1.8v supply available. Add a quirk so that systems such as this one can override disable 1.8v support, adding support for UHS-I cards (by running them at 3.3v). This avoids a problem where the system would first try to run the card at 1.8v, fail, and then not be able to fully reset the card to retry at the normal 3.3v voltage. This is more appropriate than using the MISSING_CAPS quirk, which is intended for cases where the SDHCI controller is actually lying about its capabilities, and would force us to somehow override both caps words from another source. Signed-off-by: Daniel Drake <dsd@laptop.org> Reviewed-by: Philip Rakity <prakity@nvidia.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-12-06mmc: sdhci: Use regulator min/max voltage range according to specKevin Liu
For regulator vmmc/vmmcq, use voltage range as below 3.3v/3.0v: (2.7v, 3.6v) 1.8v: (1.7v, 1.95v) Original code uses the precise value which may fail in regulator driver if it does NOT support the precise voltage. Signed-off-by: Jialing Fu <jlfu@marvell.com> Signed-off-by: Kevin Liu <kliu5@marvell.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-12-06mmc: sdhci: Balance vmmc regulator_enable(), and always enable vqmmcKevin Liu
The vmmc regulator enable in sdhci_add_host is NOT necessary since it can be enabled during mmc_power_up by function mmc_regulator_set_ocr. And this extra enable will make regulator_enable/regulator_disable unbalanced. Consequently, vmmc can't be disabled during mmc_power_off. Also, if the vqmmc regulator exists, it should be enabled regardless it support 1.8v or not. Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-11-07mmc: sdhci: fix NULL dereference in sdhci_request() tuningChris Ball
Commit 473b095a72a9 ("mmc: sdhci: fix incorrect command used in tuning") introduced a NULL dereference at resume-time if an SD 3.0 host controller raises the SDHCI_NEEDS_TUNING flag while no card is inserted. Seen on an OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too. Signed-off-by: Chris Ball <cjb@laptop.org> Cc: stable <stable@vger.kernel.org> [3.3+]
2012-11-07mmc: sdhci: fix IS_ERR() checking of regulator_get()Kevin Liu
There are two problems here: The check for vmmc was printing an unnecessary pr_info() when host->vmmc is NULL. The intent of the check for vqmmc was to only remove UHS if we have a regulator that doesn't support the required voltage, but since IS_ERR() doesn't catch NULL, we were actually removing UHS modes if vqmmc isn't present at all -- since it isn't present for most users, this breaks UHS for them. This patch fixes that UHS regression in 3.7-rc1. Signed-off-by: Kevin Liu <kliu5@marvell.com> Signed-off-by: Bin Wang <binw@marvell.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-11-07mmc: sdhci-of-esdhc: disable CMD23 for some Freescale SoCsJerry Huang
CMD23 causes lots of errors in kernel on some freescale SoCs (P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used, which is because these controllers does not support CMD23, even on the SoCs which declares CMD23 is supported. Therefore, we'll not use CMD23. Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-10-07mmc: core: Fixup broken suspend and eMMC4.5 power off notifyUlf Hansson
This patch fixes up the broken suspend sequence for eMMC with sleep support. Additionally it reworks the eMMC4.5 Power Off Notification feature so it fits together with the existing sleep feature. The CMD0 based re-initialization of the eMMC at resume is re-introduced to maintain compatiblity for devices using sleep. A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the Power Off Notification feature. We might be able to remove this cap later on, if we think that Power Off Notification always is preferred over sleep, even if the host is not able to cut the eMMC VCCQ power. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Saugata Das <saugata.das@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-09-19mmc: sdhci: Test cd-gpio instead of SDHCI presence when probingGuennadi Liakhovetski
Previously to this patch, an SDHCI platform that uses a GPIO for card detection instead of the internal SDHCI_CARD_PRESENT bit on the presence register would fail to detect a new card. Some drivers worked around this in various ways: esdhc-imx defines an IO accessor to fake the presence bit being true, s3c turns on polling (which stops the SDHCI driver from checking the bit) after a card's inserted. But none of this should be necessary; the real fix is to check whether we're using a GPIO and avoid relying on the presence bit if so, as this patch implements. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-09-04mmc: sdhci: vmmc regulator should be explicitly enabled/disabledPhilip Rakity
The vmmc regulator should not rely on the platform code to enable it. Expliciitly enable and disable the regulator inside the driver. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-09-04mmc: sdhci: Add regulator support for vccq (voltage regualor)Philip Rakity
On some systems the host controller does not support vccq signaling. This is supplied by a dedicated regulator (vqmmc). Add support for this regulator. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-22mmc: sd: Fix sd current limit settingAaron Lu
Host has different current capabilities at different voltages, we need to record these settings seperately. The defined voltages are 1.8/3.0/3.3. For other voltages, we do not touch current limit setting. Before we set the current limit for the sd card, find out the host's operating voltage first and then find out the current capabilities of the host at that voltage to set the current limit. Signed-off-by: Aaron Lu <aaron.lu@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-22mmc: sdhci: When a UHS switch fails, cycle power if regulator is usedPhilip Rakity
Power needs to be removed from the card when switching to 1.8v fails. If a regulator is used to control vmmc we need to turn the regulator off and then back on otherwise power will not be removed from the card. Signed-off-by: Philip Rakity <prakity@marvell.com> Reviewed-by: Aaron Lu <aaron.lu@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-22mmc: sdhci: poll for card even when card is logically unremovableDaniel Drake
The Marvell CaFe is now marked as having bad card detection to fix a problem during system resume. Now on the OLPC XO-1 we are facing the issue that the card is marked as logically unremovable (via MMC_UNSAFE_RESUME), which means that mmc_card_is_removable considers the card non-removable. The existing code logic decides not to poll for card presence in this case, and card detection is also disabled because of the quirk being set. This means that no SD cards are detected when inserted after boot. Refine the logic to enable card presence polling in the case when a card is logically unremovable, only avoiding the poll in the case when the card is physically non-removable (denoted with MMC_CAP_NONREMOVABLE). Signed-off-by: Daniel Drake <dsd@laptop.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-22mmc: sdhci: Introduce new flag SDHCI_USING_RETUNING_TIMERAaron Lu
Add a new flag of SDHCI_USING_RETUNING_TIMER to represent if the host is using a retuning timer for the card inserted. This flag is set when the host does tuning the first time for the card and the host's retuning mode is 1. This flag is used afterwards whenever needs to decide if the host is currently using a retuning timer. This flag is cleared when the card is removed in sdhci_reinit. The set/clear of the flag and the start/stop of the retuning timer is associated with the card's init/remove time, so there is no need to touch it when the host is to be removed as at that time the card should have already been removed. Signed-off-by: Aaron Lu <aaron.lu@amd.com> Reviewed-by: Girish K S <girish.shivananjappa@linaro.org> Reviewed-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-22mmc: sdhci: restore host settings when card is removedAaron Lu
Some of the host settings are affected by different cards inserted, e.g. when an UHS-I card is inserted, the SDHCI_NEEDS_RETUING flag might be set when the tuning timer expired and host's max_blk_count will be reduced to make sure the data transfer for a command does not exceed 4MiB to meet the retuning mode 1's requirement. When the card is removed, we should restore the original setting of the host since we can't be sure the next card being inserted will still be an UHS-I card that needs tuning. The original setting include its max_blk_count and no set of the flag of SDHCI_NEEDS_RETUNING. Signed-off-by: Aaron Lu <aaron.lu@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-22mmc: sdhci: fix incorrect command used in tuningAaron Lu
For SD hosts using retuning mode 1, when retuning timer expired, it will need to do retuning in sdhci_request before processing the actual request. But the retuning command is fixed: cmd19 for SD card and cmd21 for eMMC card, so we can't use the original request's command to do the tuning. And since the tuning command depends on the card type attached to the host, we will need to know the card type to use the correct tuning command. Signed-off-by: Aaron Lu <aaron.lu@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Cc: stable <stable@vger.kernel.org> [3.3+] Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-22mmc: sdhci: Report failure reasons for all cases in sdhci_add_host()Mark Brown
For most error conditions sdhci_add_host() will print a diagnostic message indicating why it failed but there are a few cases where this does not happen. Add error messages in these cases to aid diagnosis. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-22mmc: sdhci: Allow caps[1] to be set via SDHCI_QUIRK_MISSING_CAPSPhilip Rakity
Currently only the capability_0 register can be set if SDHCI_QUIRK_MISSING_CAPS is defined. This is a problem when the capability_1 register also needs changing. Use the quirk SDHCI_QUIRK_MISSING_CAPS to allow both registers to be set. Redefining caps[1] is useful when the board design does not support 1.8v vccq so UHS modes are not available. The code that calls sdhci_add_host can then detect this condition and adjust the caps so the UHS mode will not be attempted on UHS cards. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-21mmc: only support voltage (vdd) that regulator agrees withPhilip Rakity
If we are using a regulator the SD Host Controller and the regulator should agree about the voltages supported. Use the common subset that is supported. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-21mmc: sdhci: only set 200mA support for 1.8v if 200mA is availablePhilip Rakity
max_current_caps can return 0 if not available from the sd controller. If no regulator is present or the regulator specifies a current less then 200ma, we no longer still set the 200mA caps bit anyway. Signed-off-by: Philip Rakity <prakity@marvell.com> Reviewed-by: Aaron Lu <aaron_lu@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-07-21mmc: sdhci: if MAX_CURRENT is 0, try getting current from regulatorPhilip Rakity
The sd host controller spec indicates the the MAX_CURRENT value may be returned as 0. In this case other methods need to be used to return the current. If 0 is returned and there is a regulator, ask the regulator for how much current is available. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com> Reviewed-by: Aaron Lu <aaron.lu@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-06-06mmc: sdhci: Use DBG() instead of pr_warning() on large timeoutChris Ball
3bdc9ba892d6 ("mmc: use really long write timeout to deal with crappy cards") in 3.4 increased the write timeout that the core sends to host drivers to 3 seconds. This makes sdhci's "requested timeout too large" warning trigger on every write; so, change this pr_warning() to a DBG(). Reported-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-04-22mmc: sdhci: Log what timeout was set if the timeout is too largeMark Brown
Rather than just logging that we came up with an excessively large timeout say what the timeout was, this may provide some clues as to what the issue is. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-04-20mmc: sdhci: refine non-removable card checking for card detectionDaniel Drake
Commit c79396c191bc19 ("mmc: sdhci: prevent card detection activity for non-removable cards") disables card detection where the cards are marked as non-removable. This makes sense, but the implementation detail of calling mmc_card_is_removable() causes some problems, because mmc_card_is_removable() is overloaded with CONFIG_MMC_UNSAFE_RESUME semantics. In the OLPC XO case, we need CONFIG_MMC_UNSAFE_RESUME because our root filesystem is stored on SD, but we also have external SD card slots where we want automatic card detection. Refine the check to only apply to hosts marked as MMC_CAP_NONREMOVABLE, which is defined to mean that the card is *really* nonremovable. This could be revisited in future if we find a way to improve CONFIG_MMC_UNSAFE_RESUME semantics. Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Chuanxiao Dong <chuanxiao.dong@intel.com> [stable@: please apply to 3.3-stable] Cc: stable <stable@vger.kernel.org> Signed-off-by: Chris Ball <cjb@laptop.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-19 04:28:09 +0000