Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
...
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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+]
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|