aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/mmc/host/sdhci.c
Commit message (Collapse)AuthorAge
* ENGR00295184-7 mmc: sdhci: do not enable card cd wakeup for gpio caseDong Aisheng2014-04-16
| | | | | | | Do not need to enable the controller card cd interrupt wakeup if using GPIO as card detect since it's meaningless. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* ENGR00295184-1 mmc: sdhci: do not enable card detect interrupt for gpio cd typeDong Aisheng2014-04-16
| | | | | | | | | | | Except SDHCI_QUIRK_BROKEN_CARD_DETECTION and MMC_CAP_NONREMOVABLE, we also do not need to handle controller native card detect interrupt for gpio as card detect case. If we wrong enabled the card detect interrupt for gpio case, it will cause a lot of unexpected card detect interrupts during data transfer which should not happen. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* ENGR00292140 mmc: sdhci: fix possible sleep in atomic in sdio_irq enable ↵Dong Aisheng2014-04-16
| | | | | | | | | | | function The sdhci_runtime_pm_get API is able to sleep, so should not call it in sdhci_enable_sdio_irq_nolock which is executed with spin_lock_irqsave in sdhci_enable_sdio_irq. Move it out of spin lock to fix this issue. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* ENGR00289406-1 mmc: sdhci: add quirk for get max timeout counterDong Aisheng2014-04-16
| | | | | | | | | The max timeout counter of some SoCs like i.MX6 uSDHC may not be standard, add SDHCI_QUIRK2_NOSTD_TIMEOUT_COUNTER quirk to get the correct max timeout counter from platform specific code. Then we can calculate the correct max_discard_to value. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* ENGR00289279 mmc: sdhci: get runtime pm when sdio irq is enabledDong Aisheng2014-04-16
| | | | | | | | SDIO cards may need clock to send the card interrupt to host. Thus, we get runtime pm when sdio irq is enabled to prevent the clock resource is released and put it when sdio irq is disabled. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* mmc: sdhci: fix ctrl_2 on super-speed selectionGiuseppe CAVALLARO2014-04-16
| | | | | | | | | | | 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> (cherry picked from commit 599115686d8f62999a871f7d7ee87de3b939b258)
* mmc: sdhci: fix caps2 for HS200Giuseppe CAVALLARO2014-04-16
| | | | | | | | | | | | | | 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> (cherry picked from commit 156e14b126ffb6f040bc6f1aff3c51077e42a744)
* mmc: sdhci: add ability to stay runtime-resumed if the card is powered upAdrian Hunter2014-04-16
| | | | | | | | | | | 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> (cherry picked from commit f0710a557cb17746b09234f01073a2cdafe4f4a5)
* ENGR00286971-4 Revert "ENGR00278504-1 mmc: sdhci: add quirk for broken acmd23"Dong Aisheng2014-04-16
| | | | | | | | | The ACMD23 unwork issue is fixed now. so the former quirk to disable ACMD23 can be removed. This reverts commit fd27fce042bfd289eab6dbb7c98ab3adb48ca25b. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* mmc: sdhci: Avoid needless loop while handling SDIO interrupts in sdhci_irq()Alexey Neyman2014-04-16
| | | | | | | | | | 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: Alexey Neyman <stilor@att.net> Acked-by: Dong Aisheng <b29396@freescale.com>
* mmc: sdhci: clear auto cmd setting bits for no data cmdsDong Aisheng2014-04-16
| | | | | | | | | | | | | | | | | | | | | | | 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: Dong Aisheng <b29396@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org>
* mmc: sdhci: remove unneeded call when have preset value quirkDong Aisheng2014-04-16
| | | | | | | | | 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 <chris@printf.net>
* mmc: sdhci: report error once the maximum tuning loops exhausted or timeoutDong Aisheng2014-04-16
| | | | | | | | | | 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 <chris@printf.net>
* ENGR00278646-2 mmc: sdhci: allow platform access of sdhci_send_commandDong Aisheng2014-04-16
| | | | | | It helps for platform code to use it send tuning commands. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* ENGR00278646-1 mmc: sdhci: add hooks for platform specific tuningDong Aisheng2014-04-16
| | | | | | | | | 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. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* ENGR00278504-1 mmc: sdhci: add quirk for broken auto cmd23Dong Aisheng2014-04-16
| | | | | | | The auto cmd23 function on some platforms may not work well, add a quirk to allow them to work without auto cmd23. Signed-off-by: Dong Aisheng <b29396@freescale.com>
* mmc: sdhci: improve card removal check in sdhci_card_event()Shawn Guo2014-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9668d765eab78d58e656177db2acb57c249b9c01 upstream. 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> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
* mmc: sdhci: request irq after sdhci_init() is calledShawn Guo2014-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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(). 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 ... 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) ... ---[ end trace e9af3588936b63f0 ]--- Kernel panic - not syncing: Fatal exception in interrupt Fix the panic by simply reverse the calling sequence between request_irq() and sdhci_init(). Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
* mmc: sdhci: Don't ignore regulator_enable() return valueChris Ball2013-03-22
| | | | | | | | | | | 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>
* mmc: sdhci: add get_cd() implementationKevin Liu2013-03-22
| | | | | | | | | | | 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>
* mmc: sdhci: Fix parameter of sdhci_do_start_signal_voltage_switch()Fabio Estevam2013-02-24
| | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: check voltage range only on regulators aware of voltage valueMarek Szyprowski2013-02-24
| | | | | | | | | | | | 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>
* mmc: sdhci: enhance preset value functionKevin Liu2013-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: update signal voltage switch codeKevin Liu2013-02-24
| | | | | | | | | 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>
* mmc: sdhci: rename platform_8bit_width to platform_bus_widthSascha Hauer2013-02-24
| | | | | | | | | | | | 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>
* mmc: sdhci: introduce sdhci_update_clock helper to re-enable clockAndy Shevchenko2013-02-11
| | | | | | | | 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>
* mmc: sdhci: add IRQ wake up supportKevin Liu2013-02-11
| | | | | | | | | 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>
* mmc: sdhci: disable interrupt before free_irqKevin Liu2013-02-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: query card presence from cd-gpio before asking SDHCIShawn Guo2013-02-11
| | | | | | | | | | | | | | | | 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>
* mmc: sdhci: implement the .card_event() methodGuennadi Liakhovetski2012-12-07
| | | | | | | | | | 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>
* mmc: eSDHC: Recover from ADMA errorsHaijun Zhang2012-12-06
| | | | | | | | | | | | | | | | 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>
* mmc: sdhci: add quirk for lack of 1.8v supportDaniel Drake2012-12-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: Use regulator min/max voltage range according to specKevin Liu2012-12-06
| | | | | | | | | | | | | 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>
* mmc: sdhci: Balance vmmc regulator_enable(), and always enable vqmmcKevin Liu2012-12-06
| | | | | | | | | | | | | | 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>
* mmc: sdhci: fix NULL dereference in sdhci_request() tuningChris Ball2012-11-07
| | | | | | | | | | 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+]
* mmc: sdhci: fix IS_ERR() checking of regulator_get()Kevin Liu2012-11-07
| | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci-of-esdhc: disable CMD23 for some Freescale SoCsJerry Huang2012-11-07
| | | | | | | | | | | | | 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>
* mmc: core: Fixup broken suspend and eMMC4.5 power off notifyUlf Hansson2012-10-07
| | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: Test cd-gpio instead of SDHCI presence when probingGuennadi Liakhovetski2012-09-19
| | | | | | | | | | | | | | | | 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>
* mmc: sdhci: vmmc regulator should be explicitly enabled/disabledPhilip Rakity2012-09-04
| | | | | | | | 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>
* mmc: sdhci: Add regulator support for vccq (voltage regualor)Philip Rakity2012-09-04
| | | | | | | | | 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>
* mmc: sd: Fix sd current limit settingAaron Lu2012-07-22
| | | | | | | | | | | | | | 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>
* mmc: sdhci: When a UHS switch fails, cycle power if regulator is usedPhilip Rakity2012-07-22
| | | | | | | | | | | | 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>
* mmc: sdhci: poll for card even when card is logically unremovableDaniel Drake2012-07-22
| | | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: Introduce new flag SDHCI_USING_RETUNING_TIMERAaron Lu2012-07-22
| | | | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: restore host settings when card is removedAaron Lu2012-07-22
| | | | | | | | | | | | | | | | 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>
* mmc: sdhci: fix incorrect command used in tuningAaron Lu2012-07-22
| | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: Report failure reasons for all cases in sdhci_add_host()Mark Brown2012-07-22
| | | | | | | | | 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>
* mmc: sdhci: Allow caps[1] to be set via SDHCI_QUIRK_MISSING_CAPSPhilip Rakity2012-07-22
| | | | | | | | | | | | | | | 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>
* mmc: only support voltage (vdd) that regulator agrees withPhilip Rakity2012-07-21
| | | | | | | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-01 13:45:14 -0500