| Age | Commit message (Collapse) | Author |
|---|
|
This is the 4.9.67 stable release
Resolved conflicts:
arch/arm/boot/dts/imx6sx-sdb.dts
drivers/dma/imx-sdma.c
drivers/mmc/core/host.c
drivers/usb/chipidea/otg.c
sound/soc/fsl/fsl_ssi.c
This merge also reverts commit 3a654a85932f ("dmaengine:
imx-sdma - correct the dma transfer residue calculation"). The
downstream kernel seems to use different structures and already
use buf_ptail in its calculation.
|
|
Use force suspend/resume to trigger runtime PM when entering system
suspend.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
(cherry picked from commit c6634703d092bffee980cbe5c0459074f94d9299)
|
|
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 68e57f58377e2251c587dfd375b981d14d8e6ba8)
(cherry picked from commit 3bb87f210ab830722df3916e5301d2613941e09f)
|
|
[ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ]
I got this new build error on today's linux-next
drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type
struct tasklet_struct pio_tasklet;
drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration]
While I haven't found out why this happened now and not earlier, the
solution is obvious, we should include the header that defines
the structure.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 852ff5fea9eb6a9799f1881d6df2cd69a9e6eed5 upstream.
Using the device_property interfaces allows the dw_mmc driver to work
on platforms which run on either device tree or ACPI.
Signed-off-by: David Woods <dwoods@mellanox.com>
Reviewed-by: Chris Metcalf <cmetcalf@mellanox.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7a1e3f143176e8ebdb2f5a9b3b47abc18b879d90 upstream.
When the device is non removable, the card detect signal is often used
for another purpose i.e. muxed to another SoC peripheral or used as a
GPIO. It could lead to wrong behaviors depending the default value of
this signal if not muxed to the SDHCI controller.
Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3f0191b80cf1 ("MLK-14381 mmc: sdhci-esdhc-imx: reset tuning
circuit when system resume") add tuning reset when the timing is
MMC_TIMING_LEGACY/MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. For timing
MMC_TIMING_MMC_HS, we can not do tuning reset, otherwise HS400
timing is not right.
Here is the process of config HS400, it do tuning in HS200 mode,
then switch to HS mode and 8 bit DDR mode, finally switch to HS400
mode. If we do tuning reset in HS mode, this will cause HS400 mode
lost the tuning setting, which will cause CRC error.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
(cherry picked from commit 25e7080552a8d681a83e6c328ef5dedf5132afbf)
|
|
Some i.MX SoCs don't define ARCH_MXC, so add COMPILE_TEST to let usdhc driver
also support for these i.MX SoCs.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
commit 70f2d20917bc ("MLK-14884 mmc: sdhci: make DDR50 tuning optionally")
want to make DDR50 card tuning optionally, but the code logic is not
right, the tuning of DDR50 card will also be impacted by the flag
'SDHCI_SDR50_NEEDS_TUNING'. e.g. imx6sl/imx6sx/imx6ul/imx7d default set
USE_TUNING_SDR50, which means on these SoC, DDR50 card still do tuning
even haven't the flag 'SDHCI_DDR50_NEEDS_TUNING'.
This patch fix the logic issue, separate DDR50 and SDR50 card.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
After commit 3e3274ab9ff3 ("mmc: sdhci-esdhc-imx: Use common
sdhci_suspend|resume_host()"), we lost the pins state store and save
in common sdhci_pltfm_{suspend|resume} API which results in the
pins state lost in state un-retainable suspend/resume, then
CMD transfer will meet timeout subsequently.
Due to sdhci_pltfm_{suspend|resume} API becomes static after
that commit later, we then do manual pins state save and restore
in our platform suspend/resume API instead.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
DDR50 tuning is optinally defined in sd 3.0 spec. Per IC guys
suggestion, it internally already uses a fixed optimized timing
and normally does not require tuning.
Make it optionally and platform can claim SDHCI_DDR50_NEEDS_TUNING
support if it wants tuning.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
USDHC tuning circuit should be reset before every time card enumeration
or re-enumeration.
On imx7ulp-evk board, for SDR104 card, when system suspend in standby
mode, and then resume back, the IO timing is still SDR104 which may
result in card re-enumeration fail in low speed mode (400khz) for some
cards. And we did meet the issue that in certain probability, SDR104
card meet mmc command CRC/Timeout error when send CMD2 during mmc bus
resume.
This patch reset the tuning circuit when the ios timing is
MMC_TIMING_LEGACY/MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS, which means both
mmc_power_up() and mmc_power_off() will reset the tuning circuit.
This patch can cover the 'commit 374da688c65a ("MLK-12345 mmc:
sdhci-esdhc-imx: reset tuning circurt when insert sd card")', and is a
better solution. So use this patch instead.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
(cherry picked from commit 84a6b78bc4e2ccd433b25a4261194b93e6f83323)
Conflicts:
drivers/mmc/host/sdhci-esdhc-imx.c
|
|
MMC SDHCI maintainer Adrian Hunter Introduce SDHCI flags for signal
voltage support and set them based on the supported transfer modes,
except in the case where 3V DDR52 is supported but 1.8V is not.
This patch add the support to make eMMC DDR52 only work at 3.3v when
property 'no-1-8-v' defined.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
It is wrong to pass 'int' to IS_ERR_VALUE(), Linus's commit
aa00edc1 point out this abuse.
This patch use operator instead.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
On some SoCs such as i.MX7ULP, there is no busfreq
driver, but cpuidle has some levels which may disable
system/bus clocks, so need to add pm_qos to prevent
cpuidle from entering low level idles and make sure
system/bus clocks are enabled when usdhc is active.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
|
|
When usdhc driver remove, also need to release bus frequency.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
suspend
When suspend usdhc, it will access usdhc register. So usdhc clock
should be enabled, otherwise the access usdhc register will return
error or cause system.
Take this into consideration, if system enable a usdhc and do not
connect any SD/SDIO/MMC card, after system boot up, this usdhc
will do runtime suspend, and close all usdhc clock. At this time,
if suspend the system, due to no card persent, usdhc runtime resume
will not be called. So usdhc clock still closed, then in suspend,
once access usdhc register, system hung or bus error return.
This patch make sure usdhc clock always enabled while doing usdhc
suspend.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
This reverts commit 2c01452f4d7c0f65553b365adc27a1b7b6ba8644.
Besides, add other SoC request high bus freq. This is because
only imx6qdl do not implement low bus idle, so imx6qdl can work
well under low power mode without request high bus freq which
also can save power. For other SoC, need to request high bus
freq when usdhc is active.
Also can refer to commit 312979d1fcbd.
|
|
i.MX6ULL has errata ERR010450, which says due to SOC I/O timing
limit, eMMC HS200 and SD/SDIO 3.0 SDR104 at 1.8v can only work
below or equal to 150MHz. And eMMC DDR52 and SD/SDIO DDR50 at
1.8v can only work below or equal to 45MHz.
This patch add this limit for imx6ull.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
For Mega/Mix enabled SoCs like MX7D and MX6SX, uSDHC will lost power in
LP mode no matter whether the MMC_KEEP_POWER flag is set or not.
This may cause state misalign between kernel and HW, especially for
SDIO3.0 WiFi cards.
e.g. SDIO WiFi driver usually will keep power during system suspend.
And after resume, no card re-enumeration called.
But the tuning state is lost due to Mega/Mix.
Then CRC error may happen during next data transfer.
So we should always fire a mmc_retune_needed() for such type SoC
to tell MMC core retuning is needed for next data transfer.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
for imx6qdl"
This reverts commit 312979d1fcbd068d4ba0f461e974e7cbcc889548.
When busfreq is at low bus mode, which is 24MHz, it means DDR/AHB/AXI
will drop to 24MHz. At the same time, when in low busfreq mode, cpuidle
can be in low power idle, DRAM will be put into self-refresh and DRAM IO
will in low power mode to save power, so DMA will NOT work.
So all peripherals that needs DMA, need to request bus freq to high
setpoint when it is active.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
commit f5f968f2371ccdebb8a365487649673c9af68d09 upstream.
The stingray SDHCI hardware supports ACMD12 and automatically
issues after multi block transfer completed.
If ACMD12 in SDHCI is disabled, spurious tx done interrupts are seen
on multi block read command with below error message:
Got data interrupt 0x00000002 even though no data
operation was in progress.
This patch uses SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable
ACM12 support in SDHCI hardware and suppress spurious interrupt.
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit d84be51d1c1d3fa148a3abdeeb1455690df59e63 which is
commit a0e3142869d29688de6f77be31aa7a401a4a88f1 upstream.
It causes problems and would need other patches backported to resolve
it, and it shouldn't have been applied to 4.9-stable.
Reported-by: Georgi Djakov <georgi.djakov@linaro.org>
Cc: Sahitya Tummala <stummala@codeaurora.org>
Cc: Ritesh Harjani <riteshh@codeaurora.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream.
Currently for DDR50 card, it need tuning in default. We meet tuning fail
issue for DDR50 card and some data CRC error when DDR50 sd card works.
This is because the default pad I/O drive strength can't make sure DDR50
card work stable. So increase the pad I/O drive strength for DDR50 card,
and use pins_100mhz.
This fixes DDR50 card support for IMX since DDR50 tuning was enabled from
commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50")
Tested-and-reported-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit e9acc77dd046b22c7ebf70e35f68968978445f8b ]
Initially all QorIQ platforms were PowerPC architecture and they didn't
support card detection except several platforms. The driver added the
quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION as default and this made broken-cd
property in dts node didn't work. Now QorIQ platform turns to ARM
architecture and most of them could support card detection. However it's
a large number of dts trees that need to be fixed with broken-cd if we
remove the default SDHCI_QUIRK_BROKEN_CARD_DETECTION in driver. And the
users don't want to see this. So this patch is to remove this default
quirk just for ARM and keep it for PowerPC.(Note, QorIQ PowerPC platform
only has big-endian eSDHC while QorIQ ARM platform has big-endian or
little-endian eSDHC) This makes broken-cd property work again for ARM.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit a0e3142869d29688de6f77be31aa7a401a4a88f1 ]
sdhc-msm controller needs this SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN
& SDHCI_QUIRK2_PRESET_VALUE_BROKEN to be set. Hence setting it.
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d0918764c17b94c30bbb2619929b1719ff52707a upstream.
The controller has different timings for MMC_TIMING_UHS_DDR50 and
MMC_TIMING_MMC_DDR52. Configuring the controller with SDHCI_CTRL_UHS_DDR50,
when MMC_TIMING_MMC_DDR52 timings are requested, is not correct and can
lead to unexpected behavior.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 923713b357455cfb9aca2cd3429cb0806a724ed2 upstream.
SDIO cards may need clock to send the card interrupt to the host.
On a cherrytrail tablet with a RTL8723BS wifi chip, without this patch
pinging the tablet results in:
PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data.
64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=78.6 ms
64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=1760 ms
64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=753 ms
64 bytes from 192.168.1.14: icmp_seq=4 ttl=64 time=3.88 ms
64 bytes from 192.168.1.14: icmp_seq=5 ttl=64 time=795 ms
64 bytes from 192.168.1.14: icmp_seq=6 ttl=64 time=1841 ms
64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=810 ms
64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=1860 ms
64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=812 ms
64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=48.6 ms
Where as with this patch I get:
PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data.
64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=3.96 ms
64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=1.97 ms
64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=17.2 ms
64 bytes from 192.168.1.14: icmp_seq=4 ttl=64 time=2.46 ms
64 bytes from 192.168.1.14: icmp_seq=5 ttl=64 time=2.83 ms
64 bytes from 192.168.1.14: icmp_seq=6 ttl=64 time=1.40 ms
64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=2.10 ms
64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=1.40 ms
64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=2.04 ms
64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=1.40 ms
Cc: Dong Aisheng <b29396@freescale.com>
Cc: Ian W MORRISON <ianwmorrison@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 027fb89e61054b4aedd962adb3e2003dec78a716 upstream.
Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when Intel host controllers wait for the present
state to propagate.
The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.
Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e2ebfb2142acefecc2496e71360f50d25726040b upstream.
Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when sdhci changes clock frequency because it
waits for the clock to become stable under a spin lock.
The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.
Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 16681037e75ce08f2980ac5dbb03414429c7a55d upstream.
sdhci_arasan_get_timeout_clock() divides the frequency it has with (1 <<
(13 + divisor)).
However, the divisor is not some Arasan-specific value, but instead is
just the Data Timeout Counter Value from the SDHCI Timeout Control
Register.
Applying it here like this is wrong as the sdhci driver already takes
that value into account when calculating timeouts, and in fact it *sets*
that register value based on how long a timeout is wanted.
Additionally, sdhci core interprets the .get_timeout_clock callback
return value as if it were read from hardware registers, i.e. the unit
should be kHz or MHz depending on SDHCI_TIMEOUT_CLK_UNIT capability bit.
This bit is set at least on the tested Zynq-7000 SoC.
With the tested hardware (SDHCI_TIMEOUT_CLK_UNIT set) this results in
too high a timeout clock rate being reported, causing the core to use
longer-than-needed timeouts. Additionally, on a partitioned MMC
(therefore having erase_group_def bit set) mmc_calc_max_discard()
disables discard support as it looks like controller does not support
the long timeouts needed for that.
Do not apply the extra divisor and return the timeout clock in the
expected unit.
Tested with a Zynq-7000 SoC and a partitioned Toshiba THGBMAG5A1JBAWR
eMMC card.
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Fixes: e3ec3a3d11ad ("mmc: arasan: Add driver for Arasan SDHCI")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2ce0c7b65505e0d915e99389cced45b478dc935d upstream.
The SDHCI controller in the SAMA5D2 chip requires a valid voltage set
in the power control register, otherwise commands will fail with a
timeout error.
When using the regulator framework to specify the regulator used by the
mmc device, the voltage is not configured, and it is not possible to use
the connected device.
Implement a custom 'set_power' function for this specific hardware, that
configures the voltage in the register in all cases.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 181302dc7239add8ab1449c23ecab193f52ee6ab upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.
Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver")
Cc: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e28d6f048799acb0014491e6b74e580d84bd7916 upstream.
With commit 67bf5156edc4 ("gpio / ACPI: fix returned error from
acpi_dev_gpio_irq_get()"), mmc_gpiod_request_cd() returns -EPROBE_DEFER if
GPIO is not ready when sdhci-acpi driver is probed, and sdhci-acpi driver
should be probed again later in this case.
This fixes an order issue when both GPIO and sdhci-acpi drivers are built
as modules.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177101
Tested-by: Jonas Aaberg <cja@gmx.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Do sanity check before calling mmc_force_remove.
BCM WiFi driver will call wifi_card_detect(false) if probe fails
due to no card exists on board.
This is needed for Android BSP since Android has builtin WiFi drver
and some boards may not have WiFi cards pluged.
Then the kernel dump likes follows may appear.
----------------------------------------------
dhd_module_init in
Power-up adapter 'DHD generic adapter'
wifi_platform_bus_enumerate device present 1
mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz
mmc1: mmc_rescan_try_freq: trying to init card at 300000 Hz
mmc1: mmc_rescan_try_freq: trying to init card at 200000 Hz
mmc1: mmc_rescan_try_freq: trying to init card at 100000 Hz
failed to power up DHD generic adapter, 3 retry left
wifi_platform_bus_enumerate device present 0
------------[ cut here ]------------
Kernel BUG at 8051247c [verbose debug info unavailable]
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in: bcmdhd(+) ov5642_camera ov5640_camera_mipi_int ov5640_camera_int mxc_v4l2_capture ipu_bg_overlay_sdc ipu_still v4l2_int_device mxc_dcic ipu_prp_enc ipu_csi_enc ipu_fg_overlay_sdc evbug
CPU: 3 PID: 1071 Comm: modprobe Not tainted 4.1.15-01591-g1393481 #1504
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: a99be880 ti: a8dd8000 task.ti: a8dd8000
PC is at mmc_sdio_remove+0x70/0x74
LR is at mmc_sdio_force_remove+0xc/0x34
pc : [<8051247c>] lr : [<8051248c>] psr: 60070013
sp : a8dd9d00 ip : 00000000 fp : 00000000
r10: 7f100c98 r9 : 00000000 r8 : 7f0fc410
r7 : a8dd9d48 r6 : a83b1800 r5 : 00000000 r4 : a83b1800
r3 : 00000000 r2 : 00000000 r1 : 809b50c8 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c53c7d Table: 38cdc04a DAC: 00000015
Process modprobe (pid: 1071, stack limit = 0xa8dd8210)
Stack: (0xa8dd9d00 to 0xa8dda000)
9d00: 00000000 a83b1800 00000000 00000000 a8dd9d48 8051248c 00000000 7f0ca6cc
9d20: a99be880 a90e6280 00000003 7f0ca920 fffffdfb a81af810 80bb570c 00000000
9d40: 00020002 00000000 a8dd9d48 a8dd9d48 00000000 7f100c98 7f100c98 a90e6280
9d60: fffffdfb 00000008 00000000 7f0fe490 56f19f1c 7f0cabe4 80bb6d74 a81af810
9d80: 7f0fe248 8037f864 8037f820 80bb6d74 a81af810 00000000 7f0fe248 8037e118
9da0: a81af810 7f0fe248 a81af844 80b1e8b0 00000000 8037e328 00000000 7f0fe248
9dc0: 8037e29c 8037c660 a8025c5c a8187a34 7f0fe248 a9547780 00000000 8037d8b4
9de0: 7f0f5028 7f0fe248 00000000 7f0fe248 00000000 a90e6280 80ba78f4 8037e92c
9e00: 00000000 7f100c98 00000000 7f0cb02c 00000000 80af7720 80af7720 a90e6280
9e20: 7f124000 00000000 00000001 80009730 00000000 8040003b abc7db80 800e1c68
9e40: 00000000 a935c340 8040003a abc83180 ab757000 80af257c 00000001 8040003a
9e60: 00000001 00000001 a8dd9e7c 80af2260 a8001f00 80af46c0 56f19f1c 800e32a0
9e80: 7f0fe448 a90e6108 a90e6240 7f0fe448 a90e6100 7f0fe490 56f19f1c 8078b2b0
9ea0: 7f0fe448 a90e6100 a8dd9f58 a90e6108 00000001 80092dd8 7f0fe454 00007fff
9ec0: 800902a8 a8928900 7f0fe490 00000000 7f0fe590 000015fa c1754bfc 7f0fe590
9ee0: c16d8000 000c823c 05de516a 00000000 0000000e 00000000 00000000 00000000
9f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9f20: 00000000 00000000 00000000 00000000 00000648 00000000 00000003 01111348
9f40: 0000017b 8000f644 a8dd8000 00000000 00000073 8009352c c16d8000 000c823c
9f60: c175456c c17543a5 c17957ec 0007ad30 0008f7c0 00000000 00000000 00000000
9f80: 0000002a 0000002b 0000001f 00000023 00000014 00000000 01111348 00000000
9fa0: 00000000 8000f4c0 01111348 00000000 00000003 01111348 00000000 00040000
9fc0: 01111348 00000000 00000000 0000017b 00000000 01111218 00000073 00000073
9fe0: 7ec5d950 7ec5d940 0001f0dc 76ecf610 600d0010 00000003 00000000 00000000
[<8051247c>] (mmc_sdio_remove) from [<8051248c>] (mmc_sdio_force_remove+0xc/0x34)
[<8051248c>] (mmc_sdio_force_remove) from [<7f0ca6cc>] (wifi_platform_bus_enumerate+0x54/0x90 [bcmdhd])
[<7f0ca6cc>] (wifi_platform_bus_enumerate [bcmdhd]) from [<7f0ca920>] (dhd_wifi_platform_load+0x17c/0x39c [bcmdhd])
[<7f0ca920>] (dhd_wifi_platform_load [bcmdhd]) from [<7f0cabe4>] (wifi_plat_dev_drv_probe+0xa4/0x124 [bcmdhd])
[<7f0cabe4>] (wifi_plat_dev_drv_probe [bcmdhd]) from [<8037f864>] (platform_drv_probe+0x44/0xa4)
[<8037f864>] (platform_drv_probe) from [<8037e118>] (driver_probe_device+0x174/0x2b4)
[<8037e118>] (driver_probe_device) from [<8037e328>] (__driver_attach+0x8c/0x90)
[<8037e328>] (__driver_attach) from [<8037c660>] (bus_for_each_dev+0x6c/0xa0)
[<8037c660>] (bus_for_each_dev) from [<8037d8b4>] (bus_add_driver+0x148/0x1f0)
[<8037d8b4>] (bus_add_driver) from [<8037e92c>] (driver_register+0x78/0xf8)
[<8037e92c>] (driver_register) from [<7f0cb02c>] (dhd_wifi_platform_register_drv+0x1cc/0x20c [bcmdhd])
[<7f0cb02c>] (dhd_wifi_platform_register_drv [bcmdhd]) from [<80009730>] (do_one_initcall+0x8c/0x1d4)
[<80009730>] (do_one_initcall) from [<8078b2b0>] (do_init_module+0x5c/0x1a8)
[<8078b2b0>] (do_init_module) from [<80092dd8>] (load_module+0x177c/0x1d4c)
[<80092dd8>] (load_module) from [<8009352c>] (SyS_finit_module+0x64/0x74)
[<8009352c>] (SyS_finit_module) from [<8000f4c0>] (ret_fast_syscall+0x0/0x3c)
Code: e3a03000 e58631f8 e5863228 e8bd80f8 (e7f001f2)
---[ end trace 6f28ec270544e09e ]---
Segmentation fault
root@imx6qdlsolo:~#
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
Change SLV_DLY_TARGET to IC recommended value 0x7(4/1 cycle)
according to spec.
The old value 0x1 is not robust and may fail in some critical
circumstance.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
Current driver do not clear the tuning related register setting,
this will impact the timing and let the card inserted later meet
CRC error.
Take the DDR50 card as example, if plug out an SDR104 card and
then plug in this DDR50 card, we will meet the following error log:
mmc2: new ultra high speed DDR50 SDHC card at address aaaa
mmcblk2: mmc2:aaaa SE08G 7.40 GiB
mmcblk2: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
mmc2: tried to reset card
mmcblk2: p1 p2
Logictally, we should reset the tuning circurt everytime when we
plug in a sd card.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
this irq
Currently sdhci driver free irq in host suspend, and call
request_threaded_irq() in host resume. But during host resume,
Ctrl+C can impact sdhci host resume, see the error log:
CPU1 is up
PM: noirq resume of devices complete after 0.637 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.1
PM: early resume of devices complete after 0.774 msecs
dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
PM: Device 30b40000.usdhc failed to resume: error -4
dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
PM: Device 30b50000.usdhc failed to resume: error -4
dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
PM: Device 30b60000.usdhc failed to resume: error -4 fec 30be0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: error -110 during resume (card was removed?)
mmc2: Timeout waiting for hardware interrupt.
mmc2: Timeout waiting for hardware interrupt.
mmc2: error -110 during resume (card was removed?)
In request_threaded_irq-> __setup_irq-> kthread_create
->kthread_create_on_node, the comment shows that SIGKILLed will
impact the kthread create, and return -EINTR.
This patch replace them with disable|enable_irq(), that will prevent
IRQs from being propagated to the sdhci driver.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
We see CRCs with SLV_DLY_TARGET of 7 during driver runtime suspend/resume
if disable sw auto retuning. Back to SLV_DLY_TARGET of 1 which is used
in 3.14 kernel and don't have such issue.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
When enable WIFi and connected with AP, the system is unable to suspend.
root@imx6qdlsolo:~# echo standby > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
dhdsdio_isr: Enter
dhdsdio_isr: Enter
dhdsdio_isr: disable SDIO interrupts
Calling dhdsdio_dpc() from dhdsdio_isr
dhdsdio_dpc: Enter
dhdsdio_bussleep: request WAKE (currently SLEEP)
(Keypress still response here.... )
It's caused by Broadcom WiFi driver will keep handling SDIO irq even after
the driver is already suspended.
This weird behavior will block the MMC host suspend during its irq
synchronize operation in free_irq(), then the system suspend is blocked
too and hanged.
Add SDHCI_QUIRK2_SDIO_IRQ_THREAD for BCM WiFi to use kernel thread
to process sdio interrupts which won't block system suspend and process
freeze operation.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
Some special SDIO devices like Broadcom WiFi driver will keep handling
SDIO irq even after the driver is already suspended.
This weird behavior will block the MMC host suspend during its irq
synchronize operation in free_irq(), then the system suspend is blocked
too and hanged.
We add back sdio thread irq support for such WiFi driver to handle
SDIO irqs since the sdio thread is kernel thread which does not
block the process freeze operation during suspend.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
bcmdhd can't support removing host during suspend and
driver crash when detect card after resume due to no response
to CMD7.
It looks bcmdhd has a special requirement to enumerate card
by itself which is incompatible with current MMC core.
So implement post-cd feature to allow driver to detect card
as it wants, then we add back non-removable capability
to avoid MMC core to redetect card after resume.
root@imx6qdlsolo:~# echo standby > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for standby sleep
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
PM: Entering standby sleep
evbug: Event. Dev: input3, Type: 0, Code: 0, Value: 1
evbug: Event. Dev: input2, Type: 0, Code: 0, Value: 1
PM: suspend of devices complete after 652.363 msecs
PM: suspend devices took 0.660 seconds
PM: late suspend of devices complete after 1.148 msecs
PM: noirq suspend of devices complete after 1.043 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
Enabling non-boot CPUs ...
CPU1 is up
PM: noirq resume of devices complete after 0.534 msecs
PM: early resume of devices complete after 0.553 msecs
evbug: Event. Dev: input2, Type: 1, Code: 116, Value: 1
evbug: Event. Dev: input2, Type: 0, Code: 0, Value: 0
evbug: Event. Dev: input2, Type: 1, Code: 116, Value: 0
evbug: Event. Dev: input2, Type: 0, Code: 0, Value: 0
mmc1: error -110 during resume (card was removed?)
PM: resume of devices complete after 605.525 msecs
PM: resume devices took 0.610 seconds
PM: Finishing wakeup.
Restarting tasks ... done.
WARNING: driver bcmsdh_sdmmc did not remove its interrupt handler!
root@imx6qdlsolo:~# Unable to handle kernel NULL pointer dereference at virtual address 0000022c
pgd = 80004000
[0000022c] *pgd=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in: bcmdhd evbug ov5647_camera_mipi mxc_mipi_csi mx6s_capture
CPU: 1 PID: 780 Comm: kworker/u4:4 Not tainted 4.1.15-01434-g70f4b36 #1310
Hardware name: Freescale i.MX7 Dual (Device Tree)
Workqueue: kmmcd mmc_rescan
task: a974af80 ti: a846e000 task.ti: a846e000
PC is at _raw_spin_lock_irqsave+0x1c/0x5c
LR is at get_parent_ip+0x10/0x2c
pc : [<8077b9d4>] lr : [<8005207c>] psr: 60050093
sp : a846fc20 ip : 0001001f fp : a800b000
r10: 00000000 r9 : 00000001 r8 : 0000022c
r7 : 00000002 r6 : 0000022c r5 : a0050013 r4 : 0000022c
r3 : a974af80 r2 : 00000001 r1 : a846fc44 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: a951406a DAC: 00000015
Process kworker/u4:4 (pid: 780, stack limit = 0xa846e210)
Stack: (0xa846fc20 to 0xa8470000)
fc20: 00000000 a846fc50 a846fc44 80061808 00000000 000001dc 00000000 805037fc
fc40: 8d89d5ec 00000000 a974af80 80053e88 00000000 00000000 ab7293c0 00000000
fc60: 7f09c828 000000c9 7f09c828 a916a804 00000001 0001001f a800b000 7f0698a4
fc80: a974afc8 00000001 00000000 00000000 00012ebc a974af80 00000001 80ad46c0
fca0: a974af80 00000000 a8eeccc0 00000001 0001001f a846fd04 00000000 7f099440
fcc0: a800b000 7f0699c4 a846fcdf 00000000 00000001 7f068834 a937c900 0105c688
fce0: a846fd04 a8e20000 00000000 00000001 00000000 7f071f08 a846fd04 a80a0000
fd00: ffffffff 00000000 ffffffff a8e20000 a8e20000 00000000 7f099440 00000000
fd20: 00000000 7f099440 a800b000 7f072f4c a974af80 00000000 00000000 80778564
fd40: a846fd54 a9346550 80330028 00000001 a846e000 a8e20000 7f099440 00000000
fd60: 18005000 a8eeccc0 00000000 7f099440 a800b000 7f073744 a846fd8c 80052130
fd80: a9273898 00000000 a800b000 a8e20000 7f099440 00000001 a8eec200 a9270000
fda0: 00000000 7f099440 a800b000 7f07cd3c 80b81100 8040003f a800b000 00000000
fdc0: 00000000 a8e20000 7f099440 a9270000 a9273000 a9270000 00000000 7f099440
fde0: a800b000 7f02df4c 00000001 a8e20000 7f099440 a8eec200 00000000 a916e008
fe00: 00000000 a90bfb00 a800b000 7f074cbc a9270000 7f099440 a8e20000 00000000
fe20: a8f81610 7f0765ec 7f0765b0 a8eeccc0 a855df40 7f069310 a916a800 a8eec200
fe40: 7f09b414 7f06a950 7f06a908 a8f81608 a8f81600 8050e8b8 a8f81608 7f09b414
fe60: 80b22c70 80379744 a974af80 a8f8163c a8f81608 803797d4 00000005 a81ce930
fe80: a8f81608 8037923c a8f81608 a8f81608 80b93cf4 80376504 a846fea0 800e0e3c
fea0: 00000000 00000000 a8f81608 000000bd a833f000 00000000 00000000 8050ed04
fec0: 00000001 8050dd8c 400f8c0f a833f000 ffffff92 a833f000 a81ce600 8050de30
fee0: 8050ddbc a833f240 a833f1dc 80506048 a90bfb00 a833f240 a800b000 a81ce600
ff00: 00000000 800462f0 a81ce600 80043c94 00000000 a800b000 a90bfb18 a800b014
ff20: a846e000 00000088 80b39379 a90bfb00 a800b000 8004654c 80ad4100 a800b164
ff40: a90bfb00 00000000 a84856c0 a90bfb00 80046500 00000000 00000000 00000000
ff60: 00000000 8004b1e8 2df9acc7 00000000 b5f3ff89 a90bfb00 00000000 00000000
ff80: a846ff80 a846ff80 00000000 00000000 a846ff90 a846ff90 a846ffac a84856c0
ffa0: 8004b10c 00000000 00000000 8000f568 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ecd61557 f82769f5
[<8077b9d4>] (_raw_spin_lock_irqsave) from [<80061808>] (add_wait_queue+0x20/0x48)
[<80061808>] (add_wait_queue) from [<805037fc>] (__mmc_claim_host+0x58/0x1b0)
[<805037fc>] (__mmc_claim_host) from [<7f0698a4>] (sdioh_request_byte+0x1cc/0x2a4 [bcmdhd])
[<7f0698a4>] (sdioh_request_byte [bcmdhd]) from [<7f0699c4>] (sdioh_cfg_write+0x20/0x28 [bcmdhd])
[<7f0699c4>] (sdioh_cfg_write [bcmdhd]) from [<7f068834>] (bcmsdh_cfg_write+0x90/0xdc [bcmdhd])
[<7f068834>] (bcmsdh_cfg_write [bcmdhd]) from [<7f071f08>] (dhdsdio_clk_kso_enab+0x38/0x168 [bcmdhd])
[<7f071f08>] (dhdsdio_clk_kso_enab [bcmdhd]) from [<7f072f4c>] (dhdsdio_clk_devsleep_iovar+0xf4/0x5f4 [bcmdhd])
[<7f072f4c>] (dhdsdio_clk_devsleep_iovar [bcmdhd]) from [<7f073744>] (dhdsdio_bussleep+0x2f8/0x4dc [bcmdhd])
[<7f073744>] (dhdsdio_bussleep [bcmdhd]) from [<7f07cd3c>] (dhd_bus_stop+0x2e8/0x3f0 [bcmdhd])
[<7f07cd3c>] (dhd_bus_stop [bcmdhd]) from [<7f02df4c>] (dhd_detach+0x2a4/0x438 [bcmdhd])
[<7f02df4c>] (dhd_detach [bcmdhd]) from [<7f074cbc>] (dhdsdio_release+0x4c/0x1dc [bcmdhd])
[<7f074cbc>] (dhdsdio_release [bcmdhd]) from [<7f0765ec>] (dhdsdio_disconnect+0x3c/0xa0 [bcmdhd])
[<7f0765ec>] (dhdsdio_disconnect [bcmdhd]) from [<7f069310>] (bcmsdh_remove+0x3c/0x60 [bcmdhd])
[<7f069310>] (bcmsdh_remove [bcmdhd]) from [<7f06a950>] (bcmsdh_sdmmc_remove+0x48/0x60 [bcmdhd])
[<7f06a950>] (bcmsdh_sdmmc_remove [bcmdhd]) from [<8050e8b8>] (sdio_bus_remove+0x30/0xf8)
[<8050e8b8>] (sdio_bus_remove) from [<80379744>] (__device_release_driver+0x70/0xe4)
[<80379744>] (__device_release_driver) from [<803797d4>] (device_release_driver+0x1c/0x28)
[<803797d4>] (device_release_driver) from [<8037923c>] (bus_remove_device+0xd8/0x104)
[<8037923c>] (bus_remove_device) from [<80376504>] (device_del+0x10c/0x210)
[<80376504>] (device_del) from [<8050ed04>] (sdio_remove_func+0x1c/0x28)
[<8050ed04>] (sdio_remove_func) from [<8050dd8c>] (mmc_sdio_remove+0x40/0x70)
[<8050dd8c>] (mmc_sdio_remove) from [<8050de30>] (mmc_sdio_detect+0x74/0x100)
[<8050de30>] (mmc_sdio_detect) from [<80506048>] (mmc_rescan+0xb8/0x314)
[<80506048>] (mmc_rescan) from [<800462f0>] (process_one_work+0x120/0x330)
[<800462f0>] (process_one_work) from [<8004654c>] (worker_thread+0x4c/0x480)
[<8004654c>] (worker_thread) from [<8004b1e8>] (kthread+0xdc/0xf4)
[<8004b1e8>] (kthread) from [<8000f568>] (ret_from_fork+0x14/0x2c)
Code: f10c0080 e3a00001 ebe359b1 f594f000 (e1943f9f)
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
|
|
Currently for DDR50 card, we only use the default pin state, and we meet some
data CRC error. Now we increase the pad eletric drive for DDR50 card, and use
pins_100mhz. This pad eletric drive pass the two days reboot stress test, over
12000 times without issue.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
|
|
On 4.1 kernel, some eMMC on i.MX7D-SDB board can't pass HS400 tuning,
the same eMMC can pass HS400 tuning on 3.14 kernel. The difference
is that 4.1 kernel does not have 1ms delay for eMMC during the
tuning procedure. The root cause still not find, add back the
1ms delay first.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
This will cause meaningless CPU overhead by polling the card at backgroud
if the CD is broken.
Most board does not intend to use this function, so remove it.
Platform driver could add it for test if needed.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Conflicts:
drivers/mmc/host/sdhci.c
|
|
After adding mega fast support, the default enabled usdhc wakeup will block
M/F to gate off power domain.
To avoid this issue, we only claim wakeup capability and reply on user to enable
it via sysfs according to real needs.
The drawback of such change is that for SDIO WiFi Wakeup On Wireless feature,
User has to enable both uSDHC and WiFi WoW wakeup mannually to make
WoW work well.
BTW, due to the wakeup feature is controller itself, so we do not need to reply
on WiFi PM flags to enable it.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 58f91ff6f6719fef44f5122ae1d8a5df7e0061d5)
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Conflicts:
drivers/mmc/host/sdhci-esdhc-imx.c
|
|
The usdhc of i.MX6Q/DL can work well under low power mode without
request high bus freq. So we do not need request bus freq for i.MX6Q/DL.
It can save power for i.MX6D/DL due to it saves a lot busfreq switch
cost as well as the CPU time runing on high bus freq after switch
during low power mode.
A new flag ESDHC_FLAG_BUSFREQ is added to indicated this requirement.
Currently only i.MX6SL is using it.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 3b954ce55b56dfce195d65b84913ff3c0fcb9f82)
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Conflicts:
drivers/mmc/host/sdhci-esdhc-imx.c
|
|
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>
(cherry picked from commit e66bb4978fe4b4fb96e81a1a083c16f84f5aa710)
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
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>
(cherry picked from commit 2bf47f78bee173798e6d6f360b12defd945c936c)
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Conflicts:
drivers/mmc/host/sdhci.c
|
|
Request BUS_FREQ_HIGH when bus is busy and then release BUS_FREQ_HIGH
when bus becomes idle.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 64994f7115573c9ede53b51536b2c15f7cf0112a)
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Conflicts:
drivers/mmc/host/sdhci-esdhc-imx.c
|
