| Age | Commit message (Collapse) | Author |
|---|
|
By configure runtime PM prior we enable the use of it, we close the gap
for strange and unhandled conditions. Moreover it makes us rely on the
driver core, after finalized ->probe(), to request an inactive device
to become runtime PM idle/suspended, which earlier potentially could
happen already at pm_runtime_set_autosuspend_delay().
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 77903c01d8c6c5d2544085ba074aceadc1191d21)
|
|
As stated by the eMMC 5.0 specification, a chip should not be rejected
only because of the revision stated in the EXT_CSD_REV field of the
EXT_CSD register.
Remove the control on this value, the control of the CSD_STRUCTURE field
should be sufficient to reject future incompatible changes.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 03a59437ef6b6ad7fb0165cb9b96c08d6bf057fc)
|
|
Prevents a lot of pointless hanging at boot on some devices.
Taken from Nell Hardcastle
https://dev-nell.com/rpmb-emmc-errors-under-linux.html
|
|
|
|
The timeout_clk calculation code for SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK case
is common and could be moved into common sdhci_do_set_ios, then platform code
which is not using sdhci_set_clock does not need to write the same code again.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 03d6f5ffc5c469e66bfe0a7d8120d29d4c3c07c9)
Conflicts:
drivers/mmc/host/sdhci.c
|
|
The timeout_clk calculation code in sdhci_add_host is meaningless for
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK.
So only execute them with no SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK set.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 28aab053396125c8e191537ec2b9781ec0174b04)
|
|
The default sdhci driver write 0xE into timeout counter register to
set the maximum timeout. The value is not correct for uSDHC since the
max counter value for uSDHC is 0xF.
Instead of using common timeout code in sdhci, we implement esdhc_set_timeout
to handle the difference between eSDHC and uSDHC.
Currently we simply set the max timeout value as before.
But in the future, we probably may implement IMX specific timeout
setting algorithm and use suitable timeout for different CMDs.
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit e33eb8e2818c9a7b41bac68a1c83ee4c136af9ba)
|
|
Currently the common code assume 0xE is the maximum timeout counter
value and use it to write into the timeout counter register.
However, it's fairly possible that some other SoCs may have different
max timeout register value. That means 0xE may be incorrect and
becomes meaningless.
It's also possible that other platforms has different timeout
calculation algorithm. To be flexible, this patch provides a .set_timeout
hook for those platforms to set the timeout on their way if they need.
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit b45e668af4439bfc52ed92af44b6400661ba7ec8)
|
|
The default sdhci code use the 1 << 27 as the max timeout counter to
to calculate the max_busy_timeout, however it's not correct for uSDHC
since its the max counter is 1 << 28.
Implement esdhc_get_max_timeout_cout to handle it correctly.
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 10fd0ad967c05cda16b25f862e2a45eb63d83a21)
|
|
Currently the max timeout count is hardcode to 1 << 27 for calcuate
the max_busy_timeout, however, for some platforms the max timeout
count may not be 1 << 27, e.g. i.MX uSDHC is 1 << 28.
Thus 1 << 27 is not correct for such platform.
It is also possible that other platforms may have different values.
To be flexible, we add a get_max_timeout_count hook to get the correct
maximum timeout value for these platforms.
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit a6ff5aeb9b31f7b71a8566f8e130ad66bd103d20)
|
|
Rename host->max_discard_to to host->max_busy_timeout, to reflect that
it tells the mmc core layer about the maximum supported busy detection
timeout by the host.
This timeout is at the moment only applicable to erase/trim/discard
commands. By the renaming we provide the option of make use of it for
other commands that cares about busy detection. In other words, those
commands that wants an R1B response, like for example the mmc switch
command.
Do note that the max_busy_timeout is supposed to be specified only by
hosts supporting MMC_CAP_WAIT_WHILE_BUSY.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
(cherry picked from commit 68eb80e06bfa06035d0304686124974780308fae)
|
|
when SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set, timeout_clk is sdclk.
We need to update it when we change sdclk in sdhci_set_clock.
This allow to have a more precisse timeout and max_busy_timeout. This
can help for command that need a big busy wait (erase, ...).
Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit fac6a52fe9b14851d56b3c19c3d5a95790c46fac)
|
|
counter"
Revert the patch and using upstream version instead.
This reverts commit 056ef389fba70e2de8d1c5d976a1c1bd0578d381.
|
|
SDHCI_QUIRK2_NOSTD_TIMEOUT_COUNTER"
Revert the patch and use upstream version instead.
This reverts commit a9935446d897ff68167af82eca30b96fb96f0f7a.
|
|
Checks EXT_CSD_PARTITION_SETTING_COMPLETED bit before
computing enhanced user area offset and size, and
adding mmc general purpose partitions. The two needs
EXT_CSD_PARTITION_SETTING_COMPLETED bit be set to be
valid (as described in JEDEC standard).
Warn user in case of misconfiguration.
Signed-off-by: Grégory Soutadé <gsoutade@neotion.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Replace ext_csd "enhanced_area_en" attribute by
"partition_setting_completed". It was used whether or
not enhanced user area is defined and without checks of
EXT_CSD_PARTITION_SETTING_COMPLETED bit.
Signed-off-by: Grégory Soutadé <gsoutade@neotion.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Move code that manages user area and general purpose
partitions into functions.
Signed-off-by: Grégory Soutadé <gsoutade@neotion.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
In sdhci_init(), all irqs will be cleared, and then set the needed irqs.
So sdhci_init() should be called before request irq.
If not, some irqs may be triggled wrongly. For example, in i.MX7D LPSR
mode, when system resume, the reset value of register INT_SIGNAL_EN is
not zero, bit 8 is 1, which means SDIO card interrupt enable. And in this
case, the card still has no voltage supply, so the Data3 pin is low,
which always trigger the sd controller rise interrupt. Due to we already
request the irq, so system will always try to do the irq service, and has
no response to other event.
So this patch make sure only set the needed irqs before request irq.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
For LPSR mode, usdhc iomux settings will be lost after resume,
so add pinctrl sleep mode support.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
Currently one mrq->data maybe execute dma_map_sg() twice
when mmc subsystem prepare over one new request, and the
following log show up:
sdhci[sdhci_pre_dma_transfer] invalid cookie: 24, next-cookie 25
In this condition, mrq->date map a dma-memory(1) in sdhci_pre_req
for the first time, and map another dma-memory(2) in sdhci_prepare_data
for the second time. But driver only unmap the dma-memory(2), and
dma-memory(1) never unmapped, which cause the dma memory leak issue.
This patch use another method to map the dma memory for the mrq->data
which can fix this dma memory leak issue.
Fixes: 348487cb28e6 ("mmc: sdhci: use pipeline mmc requests to improve performance")
Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit d31911b9374a76560d2c8ea4aa6ce5781621e81d)
Conflicts:
drivers/mmc/host/sdhci.c
drivers/mmc/host/sdhci.h
|
|
Currently, we config the watermark_level register only in probe.
This will cause the mmc write operation timeout issue after system
resume back in LPSR mode. Because in LPSR mode, after system resume
back, the watermark_level register(0x44) changes to 0x08000880, which
set the write watermark level as 0, and set the read watermark level
as 128. This value is incorrect.
This patch move the setting of watermark level register out of probe,
so after system resume back, mmc driver will set back this watermark
level register back to 0x10401040.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
for data commands
Due to the data may be still in transferring if a cmd error of data
command happens, the next quick reset during data transfer may cause host
controller unpridicable issues.
e.g. On MX6Q/MX6QP, if reset during ADMA is busy moving data from FIFO to
memory, we can observe 32 bytes lost issue sometimes in a very lower
possibility especially for SD3.0 cards because the tuning command can easily
fail on cmd error before data transfer complete.
Let's using data error interrupts to handle transfer error of a
data command instead of only checking cmd error, then can make sure
the next safe reset only happens when data transfer is done.
After fixing, the SD3.0 can pass 3 days reboot stress test while it could
easily fail on only one night stress test before.
Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
|
|
When dma mapping (dma_map_sg) fails in sdhci_pre_dma_transfer, -EINVAL
is returned. There are 3 callers of sdhci_pre_dma_transfer:
* sdhci_pre_req and sdhci_adma_table_pre: handle negative return
* sdhci_prepare_data: handles 0 (error) and "else" (good) only
sdhci_prepare_data is therefore broken. When it receives -EINVAL from
sdhci_pre_dma_transfer, it assumes 1 sg mapping was mapped. Later,
this non-existent mapping with address 0 is kmap'ped and written to:
Corrupted low memory at ffff880000001000 (1000 phys) = 22b7d67df2f6d1cf
Corrupted low memory at ffff880000001008 (1008 phys) = 63848a5216b7dd95
Corrupted low memory at ffff880000001010 (1010 phys) = 330eb7ddef39e427
Corrupted low memory at ffff880000001018 (1018 phys) = 8017ac7295039bda
Corrupted low memory at ffff880000001020 (1020 phys) = 8ce039eac119074f
...
So teach sdhci_prepare_data to understand negative return values from
sdhci_pre_dma_transfer and disable DMA in that case, as well as for
zero.
It was introduced in 348487cb28e66b032bae1b38424d81bf5b444408 (mmc:
sdhci: use pipeline mmc requests to improve performance). The commit
seems to be suspicious also by assigning host->sg_count both in
sdhci_pre_dma_transfer and sdhci_adma_table_pre.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: stable@vger.kernel.org # 4.0+
Fixes: 348487cb28e6
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Haibo Chen <haibo.chen@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
sdhci-esdhc-imx tries to DMA to the kernel stack when tuning the
interface, which causes dma-debug to complain. Fix this by kmallocing
a buffer to hold the received tuning pattern.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
|
|
The wait_event_interruptible_timeout can be aborted by CTRL+C key.
We certaintly don't want tuning to be interrupted during the tuning process,
changed to wait_event_timeout avoid such failure.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
|
|
As busfreq head file name is changed from busfreq-imx6.h
to busfreq-imx.h, change the drivers which include this
head file accordingly.
Signed-off-by: Anson Huang <b20788@freescale.com>
|
|
Currently we find that if a usdhc is choosed to boot system, then ROM
code will set the burst length enable bit of this usdhc as 0.
This will make performance drop a lot if this usdhc's burst length is
16. So this patch set back the burst_length_enable bit as 1, which is
the default value, and means burst length is enabled for INCR.
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>
|
|
WiFi driver could call wifi_card_detect function to re-detect card,
this is required by some special WiFi cards like broadcom WiFi.
To use this function, a new property is introduced to indicate a wifi host.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
|
|
currently we set burst length from 8 to 16 in our usdhc driver, but
we find if the burst length is 16, the SD3.0 performance on
i.MX6Q-sabreauto and i.MX6QP-sabreauto board will drop a lot.
for TOSHIBA 16GB SDR104 card,
if burst length is 16, the peformance on these two boards is:
read: 19.4MB/s, write: 13.2MB/s
when burst length is 8, the performance on these two boards is:
read: 63MB/s, write: 25.4MB/s
other boards like i.MX6sl-evk, i.MX6sx-sdb and i.MX7D-12x12-arm2
has no this issue.
The root cause still not find on these two boards. So this patch
just change the burst length to 16 for i.MX7d, all i.MX6 series
will remain 8.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
Rather than using the streaming API, use the coherent allocator to
provide this memory, thereby eliminating cache flushing of it each
time we map and unmap it. This results in a 7.5% increase in
transfer speed with a UHS-1 card operating in 3.3v mode at a clock
of 49.5MHz.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
(cherry picked from commit d1e49f77d7c7b75fdc022e1d46c1549bbc91c5b7)
|
|
i.MX7D support eMMC HS400 mode, this mode can run in 8 bit,200MHZ
DDR mode. So the I/O speed improve a lot compare to sd3.0.
The default burst length is 8, if we don't change this value, in
HS400 mode, when we do eMMC read operation, we can find that the
clock signal will stop for a period of time. This means the speed
of data moving on AHB bus is slower than I/O speed. So we should
improve the speed of data moving on AHB bus.
This patch set the burst length as 16, and set watermater levle as
64. The test result is the clock signal has no stop during the eMMC
HS400 operation.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
Currently, for i.MX7D-SDB/i.MX7D-12x12-arm2 board, when eMMC change
to HS400 mode, it will print following warning message:
sdhci-esdhc-imx 30b60000.usdhc: warning! HS400 strobe DLL status REF not lock!
sdhci-esdhc-imx 30b60000.usdhc: warning! HS400 strobe DLL status SLV not lock!
This warning is print by the function esdhc_set_strobe_dll(), if the
eMMC support HS400, this function should be called.
But due to the HS400 mode initialization need a special operation as
following:
1) go into HS200 mode;
2) convert from HS200 mode to HS mode: set clock to 52MHz,
and go into High speed mode;
3) chose to be HS400 mode, and set clock to 200MHz.
All these set clock operation will finally call the function
esdhc_set_strobe_dll(), but the first time this function be called,
the card clock is 52MHz, in this clock rate, the strobe_dll_status
register can’t be locked. If the clock is too slow, the ½ cycle is
too long, this make the length of a delay cell is not enough.
The second time when the clock rate is much higher, the
strobe_dll_status register can be locked normally.
We don't care the warning message when the clock is 50MHz, we just
care that whether the strobe DLL status REF/SLV is locked when the
card clock is 200MHz, this is the real warning message.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
tuning-step is the delay cell steps in tuning procedure. This patch
add the tuning-step setting in driver, so that user can set the
tuning-step value in dts.
e.g.
tuning-step = <2>;
this example set the tuning-step as value 2.
This patch also set the tuning-step of i.MX7D as 2, so that the tuning
procedure can execute successfully.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
HS400 mode need to adjust the timing of strobe pad, which can make the
eMMC read operation more stable.
The USDHC has a clock generator which supplies CLK to the Device. But
for read operations, strobe pad is generated by device output circuit.
Host receives the data which is aligned to the edge of strobe pad.
When the strobe pad's clk loopback to USDHC, there exist time delay.
So adjust it before read operation, which can avoid the read error and
make read operation stable.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
Add support for i.MX7D, include the HS400 mode which i.MX7D support.
HS400 works in DDR mode, so we should set DDR mode and HS400 mode enable
before read and write operation. We use SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400
in quirks2 to mark this SOC support HS400.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
|
|
MMC core already has support for HS400. Add HS400
support to SDHCI driver. The SDHC Standard specification
does not define HS400 so consequently HS400 support is
non-standard. However HS400 is not selected without
the host controller setting the corresponding capability
flags so host controllers not yet supporting HS400
will not be affected. To support that, a quirk
SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400 is introduced to
enable the use of capabilities register reserved bit-63
to indicate HS400 support.
Because HS400 is non-standard for SDHCI, it is possible
that different vendors will do things in different ways.
However HS200 support faced the same issue but currently
there is only one solution. As such, no attempt has
been made to provide for alternate HS400 solutions except
for SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400.
Conflicts:
drivers/mmc/host/sdhci.c
drivers/mmc/host/sdhci.h
include/linux/mmc/host.h
include/linux/mmc/sdhci.h
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit e9fb05d5bca7428f2749d059559e9657c710fe53)
|
|
This patch adds HS400 mode support for eMMC5.0 device. HS400 mode is high
speed DDR interface timing from HS200. Clock frequency is up to 200MHz
and only 8-bit bus width is supported. In addition, tuning process of
HS200 is required to synchronize the command response on the CMD line
because CMD input timing for HS400 mode is the same as HS200 mode.
Conflicts:
drivers/mmc/core/mmc.c
include/linux/mmc/card.h
include/linux/mmc/host.h
include/linux/mmc/mmc.h
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: Jackey Shen <jackey.shen@amd.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
(cherry picked from commit 0a5b6438ee482696360bb013e67b8488f63d3e9e)
|
|
Due to the power lost in suspend if Mega/Fast is enabled which is a new
feature introduced, the static settings like tuning control in probe()
function of controller will be lost which results in the later resume
failed on tuning routine for SD3.0 cards(SDR50/SDR104).
This patch moves the tunning setting from probe() function into
register setting path before the tuning is executed.
Then the tuning setting becomes dynamically and re-set again after
resume for a SD3.0 card when doing tuning.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 2fb6a74b8b91dad7e57d65a57eabd422a4acc25e)
|
|
We may meet the following errors with a SD3.0 DDR50 cards during reboot test.
mmc0: new ultra high speed DDR50 SDHC card at address aaaa
mmcblk0: mmc0:aaaa SU08G 7.40 GiB
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 0
.....
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: unable to read partition table
The root cause is still unknown.
Since there's an errata of Sandisk eMMC card before that it requires delay for CMD6
for eMMC DDR mode to work stable, we also suspect the SD3.0 DDR requires similar delay.
(Still not confirmed by Sandisk)
By adding the delay, the overnight reboot test(run 2000+ times) did not
show the issue anymore. Originally it can easy show the error after about 20 times of
reboot test.
So this patch would be the temporary workaround for Sandisk SD3.0 DDR50 mode
unstable issue.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit ef3bce5feb2ed36c9f4483287454d35ae330dbe3)
(cherry picked from commit c0cbde8a248036fae1768f232385290c23eddbd7)
(cherry picked from commit 138bab9f78ea2285b6e7c7cd6c8cd956def44003)
|
|
The host->vmmc will be in disabled state if there's no card detected.
In that case arbitrarily disabling the host->vmmc in sdhci_remove_host()
may cause the following warning due to unblanced use count of regulator.
root@imx6qdlsolo:~# modprobe -r sdhci-esdhc-imx
mmc3: card e624 removed
------------[ cut here ]------------
WARNING: at drivers/regulator/core.c:1727 _regulator_disable+0xe4/0x14c()
unbalanced disables for VCC_SD3
Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm
CPU: 0 PID: 884 Comm: modprobe Not tainted 3.10.53-02577-gd22d937 #715
[<80013b00>] (unwind_backtrace+0x0/0xf4) from [<80011524>] (show_stack+0x10/0x14)
[<80011524>] (show_stack+0x10/0x14) from [<8002c290>] (warn_slowpath_common+0x54/0x6c)
[<8002c290>] (warn_slowpath_common+0x54/0x6c) from [<8002c2d8>] (warn_slowpath_fmt+0x30/0x40)
[<8002c2d8>] (warn_slowpath_fmt+0x30/0x40) from [<802cc054>] (_regulator_disable+0xe4/0x14c)
[<802cc054>] (_regulator_disable+0xe4/0x14c) from [<802cc0ec>] (regulator_disable+0x30/0x64)
[<802cc0ec>] (regulator_disable+0x30/0x64) from [<80468dfc>] (sdhci_remove_host+0x78/0x160)
[<80468dfc>] (sdhci_remove_host+0x78/0x160) from [<7f005934>] (sdhci_esdhc_imx_remove+0x30/0x58 [sdhci_esdhc_imx])
[<7f005934>] (sdhci_esdhc_imx_remove+0x30/0x58 [sdhci_esdhc_imx]) from [<80313038>] (platform_drv_remove+0x18/0x1c)
[<80313038>] (platform_drv_remove+0x18/0x1c) from [<803119d8>] (__device_release_driver+0x70/0xcc)
[<803119d8>] (__device_release_driver+0x70/0xcc) from [<803120cc>] (driver_detach+0xac/0xb0)
[<803120cc>] (driver_detach+0xac/0xb0) from [<803116c4>] (bus_remove_driver+0x7c/0xd0)
[<803116c4>] (bus_remove_driver+0x7c/0xd0) from [<8006fc80>] (SyS_delete_module+0x124/0x210)
[<8006fc80>] (SyS_delete_module+0x124/0x210) from [<8000e080>] (ret_fast_syscall+0x0/0x30)
---[ end trace 7bd0fb3a78254b54 ]---
root@imx6qdlsolo:~# EXT3-fs (mmcblk3p2): I/O error while writing superblock
Only disable regulators if they're on when remove host controller.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 89aa41ebb49c495be76ce107d037e4f31b3671cd)
(cherry picked from commit 5f2ea9ff90daa3e99512c4c7c453278910b78f34)
|
|
This patch is based on the patches by Per Forlin, Tony Lin and Ryan QIAN.
This patch complete the API 'post_req' and 'pre_req' in sdhci host side,
Test Env:
1. i.MX6Q-SABREAUTO board, CPU @ 996MHz, use ADMA in uSDHC controller.
2. Test command:
$ echo 1 > /proc/sys/vm/drop_caches
write to sd card:
$ dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=2000 conv=fsync
read the sd card:
$ dd if=/dev/mmcblk0 of=/dev/null bs=1M count=2000
3. TOSHIBA 16GB SD3.0 card, running at 4 bit, SDR104 @ 198MHZ
Performance with and without this patch:
-------------------------------------------------
| | read speed | write speed |
|------------------------------------------------
| with this patch | ~76.7 MB/s | ~23.3 MB/s |
|------------------------------------------------
|without this patch | ~60.5 MB/s | ~22.5 MB/s |
-------------------------------------------------
4. SanDisk 8GB SD3.0 card, running at 4 bit, DDR50 @ 50MHZ
Performance with and without this patch:
-------------------------------------------------
| | read speed | write speed |
|------------------------------------------------
| with this patch | ~40.5 MB/s | ~15.6 MB/s |
|------------------------------------------------
|without this patch | ~36.1 MB/s | ~14.1 MB/s |
-------------------------------------------------
5. Kingston 8GB SD2.0 card, running at 4 bit, High-speed @ 50MHZ
Performance with and without this patch:
-------------------------------------------------
| | read speed | write speed |
|------------------------------------------------
| with this patch | ~22.7 MB/s | ~8.2 MB/s |
|------------------------------------------------
|without this patch | ~21.3 MB/s | ~8.0 MB/s |
-------------------------------------------------
6. About eMMC, Sandisk 8GB eMMC on i.MX6DL-sabresd board, CPU @ 792MHZ,
eMMC running at 8 bit, DDR52 @ 52MHZ.
Performance with and without this patch:
-------------------------------------------------
| | read speed | write speed |
|------------------------------------------------
| with this patch | ~37.3 MB/s | ~10.5 MB/s |
|------------------------------------------------
|without this patch | ~33.4 MB/s | ~10.5 MB/s |
-------------------------------------------------
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit a0a60bf36806be9528d4011563e9367bddeff762)
|
|
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)
|
|
The imx6sx usdhc is derived from imx6sl, the difference is minor.
imx6sx have the errata ESDHC_FLAG_ERR004536 fixed.
So introduce a new compatible string for imx6sx to distinguish them.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 775f880758c59297dba3c54dd2499f5d165daaa9)
|
|
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)
|
|
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)
|
|
Enable wakeup for SDIO IRQ when the host is able to keep power
during suspend.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 19a1ec6ca25b2fc639fc75a25dd8a1fd452f8578)
|
|
IMX boards can keep power for cards during suspend.
User can enable it from device tree.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit c493df82295e0384f81c21cf126412280d81411d)
|
|
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)
|
|
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>
(cherry picked from commit 2aa0640de623c8f4ef908210da30aeece30dbd91)
|
