24 Jun, 2019
1 commit
-
On i.MX8MM, we are running Dual Linux OS, with 1st Linux using SD Card
as rootfs storage, 2nd Linux using eMMC as rootfs storage. We let the
the 1st linux configure power/clock for the 2nd Linux.When the 2nd Linux is booting into rootfs stage, we let the 1st Linux
to destroy the 2nd linux, then restart the 1st linux, we met SDHCI dump
as following, after we clear the pending interrupt and halt CQCTL, issue
gone.[ 1.334594] mmc2: Got command interrupt 0x00000001 even though no command operation was in progress.
[ 1.334595] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 1.334599] mmc2: sdhci: Sys addr: 0xa05dcc00 | Version: 0x00000002
[ 1.340819] lib80211: common routines for IEEE802.11 drivers
[ 1.345538] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000000
[ 1.345541] mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000033
[ 1.345543] mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000031
[ 1.345547] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080
[ 1.357903] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000003f
[ 1.357905] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000
[ 1.357908] mmc2: sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[ 1.357911] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502
[ 1.370268] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x0000b400
[ 1.370270] mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff
[ 1.370273] mmc2: sdhci: Resp[0]: 0x00000b00 | Resp[1]: 0xffffffff
[ 1.370276] mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d00f00
[ 1.382132] mmc2: sdhci: Host ctl2: 0x00000000
[ 1.382135] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xa2040208[ 2.060932] mmc2: Unexpected interrupt 0x00004000.
[ 2.065538] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 2.071720] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
[ 2.077902] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001
[ 2.084083] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[ 2.090264] mmc2: sdhci: Present: 0x01f88009 | Host ctl: 0x00000011
[ 2.096446] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080
[ 2.102627] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x000010ff
[ 2.108809] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00004000
[ 2.114990] mmc2: sdhci: Int enab: 0x007f1003 | Sig enab: 0x007f1003
[ 2.121171] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502
[ 2.127353] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x0000b400
[ 2.133534] mmc2: sdhci: Cmd: 0x0000371a | Max curr: 0x00ffffff
[ 2.139715] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
[ 2.145896] mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d00f00
[ 2.152077] mmc2: sdhci: Host ctl2: 0x00000000
[ 2.156342] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000Signed-off-by: Peng Fan
Reviewed-by: Haibo Chen
(cherry picked from commit 1175b59611537b0b451e0d1071b1666873a8ec32)
07 Jun, 2019
1 commit
-
Since L4.15, community involve the commit 105819c8a545 ("mmc: core: use mrq->sbc
when sending CMD23 for RPMB"), let the usdhc to decide whether to use ACMD23 for
RPMB. This CMD23 for RPMB need to set the bit 31 to its argument, if not, the
RPMB write operation will return general fail.According to the sdhci logic, SDMA mode will disable the ACMD23, and only in
ADMA mode, it will chose to use ACMD23 if the host support. But according to
debug, and confirm with IC, the imx6qpdl/imx6sx/imx6sl/imx7d do not support
the ACMD23 feature completely. These SoCs only use the 16 bit block count of
the register 0x4 (BLOCK_ATT) as the CMD23's argument in ACMD23 mode, which
means it will ignore the upper 16 bit of the CMD23's argument. This will block
the reliable write operation in RPMB, because RPMB reliable write need to set
the bit31 of the CMD23's argument. This is the hardware limitation. Due to
imx6sl use SDMA, so for imx6qpdl/imx6sx/imx7d, it need to broke the ACMD23 for
eMMC, SD card do not has this limitation, because SD card do not support reliable
write.For imx6ul/imx6ull/imx6sll/imx7ulp/imx8, it support the ACMD23 completely, it
change to use the 0x0 register (DS_ADDR) to put the CMD23's argument in ADMA mode.This patch handle 'auto-cmd23-broken' from devicetree.
Signed-off-by: Haibo Chen
29 May, 2019
1 commit
-
The tag set is allocated in mmc_init_queue but never freed. This results
in a memory leak. This change makes sure we free the tag set when the
queue is also freed.Signed-off-by: Raul E Rangel
Reviewed-by: Jens Axboe
Acked-by: Adrian Hunter
Fixes: 81196976ed94 ("mmc: block: Add blk-mq support")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson
(cherry picked from commit 43d8dabb4074cf7f3b1404bfbaeba5aa6f3e5cfc)
02 May, 2019
3 commits
-
After system suspend, CQE is in cqhci_off state, which set the HALT bit, make
CQE in HALT state. If the SoC do not power down the USDHC module, then when
system resume back, this bit keep the same, still set. So need to clear this
bit when enable CQE for the first request after system resume back. If not,
imx8mm will stuck in the first CMDQ request after system resume back. On
imx8qxp and imx8qm, we do not find this issue because usdhc module lost power
during system suspend/resume, and all the register return to the default reset
value, and the reset value of bit HALT is 0.Signed-off-by: Haibo Chen
(cherry picked from commit 49d6f5d5cca3a66fa65568a50f75cbbac87ba312)
Signed-off-by: Arulpandiyan Vadivel
Signed-off-by: Shrikant Bobade
(cherry picked from commit bb7964bdf5dee51e82d8b7fff3e2454e3c9a57fc) -
the commit 885c943ca13d ("ENGR00288842 mmc: sdhci-esdhc-imx: add
ADMA Length Mismatch errata fix") involve the fix of ERR004536.
But double confirm with IC, need to clear the bit 7 of register
0x6c rather than set this bit 7.
here is the function of bit 7 of 0x6c:
0: enable the new IC fix for ERR004536
1: do not use the IC fix, keep the same as beforeDue to the reset value of this bit 7 is 0, and ROM code also do not
touch this bit 7, so this patch directly remove the operation of this
bit 7, make sure the fix of ERR004536 can work.Note, for all versons of 6DQP 6DQ 6DL and 6SL, IC do not has this
hardware fix, so writing this bit has no effect and we keep using
ADMA as before which has been used for several years with the
consideration of no performance drop.For other SoC like imx6SLL imx6SX imx6UL/imx6ULL imx7 imx8, IC already
contain this hareware fix, so must make sure the bit 7 of the register
0x6c is 0. If not, we meet the ADMA length mismatch error on imx8mm-evk
and imx8qxp-ddr3l-val board when enable CMDQ.Signed-off-by: Haibo Chen
(cherry picked from commit 2ea2f2b374545ff63a714fabc16c0d7c6b3b47b6)
Signed-off-by: Arulpandiyan Vadivel
Signed-off-by: Shrikant Bobade
(cherry picked from commit 359538c2faf5d975072c9950e510d61d10815a69) -
CID 4058489: Unchecked return value (CHECKED_RETURN)
2. check_return: Calling dma_set_mask_and_coherent without checking
return value.Signed-off-by: Arulpandiyan Vadivel
Signed-off-by: Shrikant Bobade
(cherry picked from commit 9df9165707c34b8c4efe0e89f97e93cca7a222a0)
18 Apr, 2019
34 commits
-
i.MX8MM contains USDHC which support eMMC V5.1 (including CMDQ and
HS400ES), besides i.MX8MM also support bus frequency, so add a new
esdhc_soc_data for i.MX8MM.Signed-off-by: Haibo Chen
-
Fix Mentor back porting issue. According to community log, need to
first backport the commit 57678e5a3d51 ("mmc: block: Delete gendisk
before cleaning up the request queue"), then can back porting the
commit be2ad281466f ("mmc: block: Prevent new req entering queue
after its cleanup"). But Mentor wrongly handle the sequence, and
wrongly handle the conflict, causing the mmc_cleanup_queue() is
called twice. When do sd hot plug test, will meet the following dump::~# mmc0: card aaaa removed
------------[ cut here ]------------
WARNING: CPU: 0 PID: 152 at block/blk-core.c:813 blk_cleanup_queue+0x140/0x144
Modules linked in:
CPU: 0 PID: 152 Comm: kworker/0:4 Not tainted 4.19.30-04275-gd0b5d3f8b43d #43
Hardware name: Freescale i.MX7ULP (Device Tree)
Workqueue: events_freezable mmc_rescan
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x78/0x8c)
[] (dump_stack) from [] (__warn+0xdc/0xf4)
[] (__warn) from [] (warn_slowpath_null+0x40/0x48)
[] (warn_slowpath_null) from [] (blk_cleanup_queue+0x140/0x144)
[] (blk_cleanup_queue) from [] (mmc_cleanup_queue+0x28/0x3c)
[] (mmc_cleanup_queue) from [] (mmc_blk_remove_req.part.5+0x2c/0x90)
[] (mmc_blk_remove_req.part.5) from [] (mmc_blk_remove+0xe8/0x1b0)
[] (mmc_blk_remove) from [] (mmc_bus_remove+0x18/0x20)
[] (mmc_bus_remove) from [] (device_release_driver_internal+0x178/0x220)
[] (device_release_driver_internal) from [] (bus_remove_device+0xcc/0xf8)
[] (bus_remove_device) from [] (device_del+0x120/0x358)
[] (device_del) from [] (mmc_remove_card+0x78/0x9c)
[] (mmc_remove_card) from [] (mmc_sd_detect+0x3c/0x6c)
[] (mmc_sd_detect) from [] (mmc_rescan+0xcc/0x3f4)
[] (mmc_rescan) from [] (process_one_work+0x1f0/0x400)
[] (process_one_work) from [] (worker_thread+0x44/0x580)
[] (worker_thread) from [] (kthread+0x148/0x150)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
Exception stack(0xb095bfb0 to 0xb095bff8)
bfa0: 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
---[ end trace 5bcff5fbec8eea08 ]---
Unable to handle kernel paging request at virtual address 3e700004
pgd = 5bbecc7f
[3e700004] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 152 Comm: kworker/0:4 Tainted: G W 4.19.30-04275-gd0b5d3f8b43d #43
Hardware name: Freescale i.MX7ULP (Device Tree)
Workqueue: events_freezable mmc_rescan
PC is at __srcu_read_lock+0x1c/0x38
LR is at hctx_lock+0x1c/0x2c
pc : [] lr : [] psr: 20010093
sp : b095bdf8 ip : 20010013 fp : bf682d80
r10: b083d008 r9 : b083e810 r8 : 00000034
r7 : 00000001 r6 : 00000001 r5 : b09b8400 r4 : b095be00
r3 : 00000004 r2 : 00000001 r1 : b095be00 r0 : 3e700000
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c53c7d Table: 90c9006a DAC: 00000051
Process kworker/0:4 (pid: 152, stack limit = 0x37b997f7)
Stack: (0xb095bdf8 to 0xb095c000)
bde0: 81004d08 803ef16c
be00: bf682d80 bd071de2 0000001c 00000000 b0415820 00000001 00000000 803ef278
be20: b08b1c0c b0415820 b083e800 8073f1a8 b08b1c00 b08b1c0c b083e800 8073cedc
be40: b083e800 b08b1c00 b083e808 8073d9fc 60010013 00000034 bf682d80 b083e808
be60: b083e83c 8104db84 00000000 00000034 b083e810 8072e57c b083e808 80534930
be80: b0141a30 b083e808 8104d598 81004d08 810fbf40 8053357c b083e800 b083e808
bea0: b083e860 80530bc4 bf686200 00000000 b083d268 00000000 bf682d80 80172038
bec0: 80db2040 bd071de2 bf686200 b083e800 b083e808 b083d000 bf686200 00000000
bee0: b083d268 00000000 bf682d80 8072ebf0 b083d000 ffffff85 b083d000 80734044
bf00: b083d264 b083d200 b083d000 8072dfa8 b083d264 b096b080 bf682d80 bf686200
bf20: 00000000 80146454 81003d00 bf682d98 b096b080 bf682d80 b096b094 81003d00
bf40: bf682d98 ffffe000 00000008 801471d8 b08e3a70 8109d940 80d256d0 b095a000
bf60: b0968b1c b0968b00 b0968ac0 00000000 b095a000 b096b080 80147194 b0081ea4
bf80: b0968b1c 8014c014 00000000 b0968ac0 8014becc 00000000 00000000 00000000
bfa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[] (__srcu_read_lock) from [] (hctx_lock+0x1c/0x2c)
[] (hctx_lock) from [] (blk_mq_run_hw_queue+0x28/0xfc)
[] (blk_mq_run_hw_queue) from [] (blk_mq_run_hw_queues+0x38/0x4c)
[] (blk_mq_run_hw_queues) from [] (mmc_cleanup_queue+0x20/0x3c)
[] (mmc_cleanup_queue) from [] (mmc_blk_remove_req.part.5+0x44/0x90)
[] (mmc_blk_remove_req.part.5) from [] (mmc_blk_remove+0xe8/0x1b0)
[] (mmc_blk_remove) from [] (mmc_bus_remove+0x18/0x20)
[] (mmc_bus_remove) from [] (device_release_driver_internal+0x178/0x220)
[] (device_release_driver_internal) from [] (bus_remove_device+0xcc/0xf8)
[] (bus_remove_device) from [] (device_del+0x120/0x358)
[] (device_del) from [] (mmc_remove_card+0x78/0x9c)
[] (mmc_remove_card) from [] (mmc_sd_detect+0x3c/0x6c)
[] (mmc_sd_detect) from [] (mmc_rescan+0xcc/0x3f4)
[] (mmc_rescan) from [] (process_one_work+0x1f0/0x400)
[] (process_one_work) from [] (worker_thread+0x44/0x580)
[] (worker_thread) from [] (kthread+0x148/0x150)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
Exception stack(0xb095bfb0 to 0xb095bff8)
bfa0: 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: f10c0080 e590307c ee1d0f90 e0833102 (e7931000)
---[ end trace 5bcff5fbec8eea09 ]---
FAT-fs (mmcblk0p1): FAT read failed (blocknr 8)Signed-off-by: Haibo Chen
Reviewed-by: Dong Aisheng -
Add an new esdhc_soc_data for i.MX8QXP, and add HS400_ES mode
support.Signed-off-by: Haibo Chen
Acked-by: Adrian Hunter
[Ulf: Rebased on top of latest changes]
Signed-off-by: Ulf Hansson
(cherry picked from commit 029e2476f9e6755ca6cc91922d1d75e856c0820a) -
commit 4a26e955522a ("MLK-14539 mmc: sdhci: make no-1-8-v also work
for DDR52 mode") cherry picked by mentor has some conflicts, and they
wrongly handle the conflicts, this patch fix it.Signed-off-by: Haibo Chen
-
After system suspend, CQE is in cqhci_off state, which set the HALT bit, make
CQE in HALT state. If the SoC do not power down the USDHC module, then when
system resume back, this bit keep the same, still set. Though there is a
sdhci reset during sdhci_resume_host(), but this reset do not impact the
CQE part, so need to clear this bit when enable CQE, otherwise CQE will
stuck in the first CMDQ request after system resume back.Find this issue on NXP i.MX845s-mek board
[ 105.919862] mmc2: cqhci: timeout for tag 6
[ 105.923965] mmc2: cqhci: ============ CQHCI REGISTER DUMP ===========
[ 105.930407] mmc2: cqhci: Caps: 0x0000310a | Version: 0x00000510
[ 105.936847] mmc2: cqhci: Config: 0x00001001 | Control: 0x00000001
[ 105.943286] mmc2: cqhci: Int stat: 0x00000000 | Int enab: 0x00000006
[ 105.949725] mmc2: cqhci: Int sig: 0x00000006 | Int Coal: 0x00000000
[ 105.956164] mmc2: cqhci: TDL base: 0x7809b000 | TDL up32: 0x00000000
[ 105.962604] mmc2: cqhci: Doorbell: 0x00000040 | TCN: 0x00000000
[ 105.969043] mmc2: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000
[ 105.975483] mmc2: cqhci: Task clr: 0x00000000 | SSC1: 0x00011000
[ 105.981922] mmc2: cqhci: SSC2: 0x00000001 | DCMD rsp: 0x00000000
[ 105.988362] mmc2: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x00000000
[ 105.994801] mmc2: cqhci: Resp idx: 0x00000000 | Resp arg: 0x00000000
[ 106.001240] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 106.007680] mmc2: sdhci: Sys addr: 0xb2b37800 | Version: 0x00000002
[ 106.014120] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001
[ 106.020560] mmc2: sdhci: Argument: 0x00010000 | Trn mode: 0x00000013
[ 106.026999] mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000030
[ 106.033439] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080
[ 106.039878] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000000f
[ 106.046318] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000
[ 106.052757] mmc2: sdhci: Int enab: 0x107f4000 | Sig enab: 0x107f4000
[ 106.059196] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502
[ 106.065635] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x8000b407
[ 106.072075] mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff
[ 106.078514] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x31360181
[ 106.084954] mmc2: sdhci: Resp[2]: 0x44473430 | Resp[3]: 0x00450100
[ 106.091392] mmc2: sdhci: Host ctl2: 0x00000008
[ 106.095836] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7804b208
[ 106.102274] mmc2: sdhci: ============================================
[ 106.108785] mmc2: running CQE recoverySigned-off-by: Haibo Chen
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
(cherry picked from commit 85236d2be844ade0bd8b34e3626fc3e36498cd85) -
The bit ESDHC_STD_TUNING_EN may be configed by bootloader code if it
choose to use standard tuning method. So on linux side, if choose to
use manual tuning method, need to clear the bit ESDHC_STD_TUNING_EN,
remove the impact of bootloader code.Signed-off-by: Haibo Chen
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
(cherry picked from commit a98c557e2af3e12e38dee6019a5cf210156d629e) -
For some eMMC, after switch to HS400ES mode, it need to config the strobe
dll target dealy even if the clock is 50MHZ or 25MHz, otherwise will meet
CMD index/crc error when send CMD13 to check the switch status. Take
imx8MM-EVK board as example, without this patch, it will meet:[ 2.473915] IRQ status 0x000a8001
[ 2.473930] the mmc send status get -84
[ 2.473934] mmc2: mmc_select_hs400es failed, error -84
[ 2.473938] mmc2: error -84 whilst initialising MMC cardAnd we also meet some customer require to let eMMC work at 80MHz HS400ES
mode, so here remove the 100MHz limitation for Strobe DLL target delay
setting.Signed-off-by: Haibo Chen
Signed-off-by: Vipul Kumar -
It's observed that uSDHC needed delay between tuning cycles for
HS200 successful tuning. This patch is to set 1ms delay for that.Signed-off-by: Haibo Chen
Signed-off-by: Vipul Kumar -
When using jailhouse to support two Linux on i.MX8MQ EVK,
we use the 1st Linux to configure pinctrl for the 2nd Linux.
Then the 2nd Linux could use the mmc without pinctrl driver.So give a warning message when no pinctrl available, but no fail probe.
Signed-off-by: Peng Fan
(cherry picked from commit 0ededa450d69016a72755b428f89d149666d7968)
Signed-off-by: Vipul Kumar -
Add HS400 support for iMX7ULP B0.
According to IC suggest, need to clear the STROBE_DLL_CTRL_RESET
before any setting of STROBE_DLL_CTRL register.USDHC has register bits(bit[27~20] of register STROBE_DLL_CTRL)
for slave sel value. If this register bits value is 0, it needs
256 ref_clk cycles to update slave sel value. IC suggest to set
bit[27~20] to 0x4, it only need 4 ref_clk cycle to update slave
sel value. This will short the lock time of slave.i.MX7ULP B0 will need more time to lock the REF and SLV, so change
to add another 5us delay.Acked-by: Dong Aisheng
Signed-off-by: Haibo Chen
Signed-off-by: Vipul Kumar -
Android report data timeout issue on the Micron eMMC of i.mx8mscale
evk board. Before using CMD25 to write multi block data, driver will
use CMD6 to flush cache. But some CMD25 will get both data timeout
interrupt and transfer complete interrupt. If add delay after busy
check, and before sending CMD13, this issue gone.We meet similar issue on Sandisk eMMC before, and already have a
commit 581925fe325a ("MLK-11685-1 mmc: add delay after CMD6 befoer
sending CMD13 for sandisk"), but when cherry-pick to 4.9 branch,
meet conflicts, put the delay in the wrong place. So meet the similar
issue again.This patch fix this, move the dealy in the right place, right before
CMD13.Reviewed-by: Dong Aisheng
Signed-off-by: Haibo Chen
Signed-off-by: Vipul Kumar -
Add feature of setting slot index via devicetree alias, to hard code the
mmc/sd root device.The patch requires additional alias_id fix or it won't work.
Note: minor device number keep independent with this device alias.
Refer to the commit 35928d6c6a76 ("mmc: Allow setting slot index via
devicetree alias").Acked-by: Leonard Crestez
Reviewed-by: Dong Aisheng
Signed-off-by: Haibo Chen
(Vipul: Fixed merge conflicts)
Signed-off-by: Vipul Kumar -
make sure clock is disabled during suspend
Reviewed-by: Haibo Chen
Signed-off-by: Dong Aisheng
Signed-off-by: Vipul Kumar -
As per 'commit 8814ce8a0f68 ("block: Introduce blk_queue_flag_{set,clear,test_and_{set,clear}}()")'
, make changes to fix the below compilation error.drivers/mmc/core/block.c: In function ‘mmc_blk_remove_req’:
drivers/mmc/core/block.c:2672:3: error: implicit declaration of function ‘queue_flag_set’; did you mean ‘blk_queue_flag_set’? [-Werror=implicit-function-declaration]
queue_flag_set(QUEUE_FLAG_BYPASS, md->queue.queue);
^~~~~~~~~~~~~~
blk_queue_flag_set
cc1: some warnings being treated as errors
scripts/Makefile.build:303: recipe for target 'drivers/mmc/core/block.o' failedSigned-off-by: Vipul Kumar
-
Fix lockdep splat introduced in v4.13-rc4.
[ 266.297226] ------------[ cut here ]------------
[ 266.300078] WARNING: CPU: 2 PID: 176 at /mnt/src/jaja/git/tf300t/include/linux/blkdev.h:657 mmc_blk_remove_req+0xd0/0xe8 [mmc_block]
[ 266.302937] Modules linked in: mmc_block(-) sdhci_tegra sdhci_pltfm sdhci pwrseq_simple pwrseq_emmc mmc_core
[ 266.305941] CPU: 2 PID: 176 Comm: rmmod Tainted: G W 4.13.0-rc4mq-00208-gb691e67724b8-dirty #694
[ 266.308852] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[ 266.311719] [] (unwind_backtrace) from [] (show_stack+0x18/0x1c)
[ 266.314664] [] (show_stack) from [] (dump_stack+0x84/0x98)
[ 266.317644] [] (dump_stack) from [] (__warn+0xf4/0x10c)
[ 266.320542] [] (__warn) from [] (warn_slowpath_null+0x28/0x30)
[ 266.323534] [] (warn_slowpath_null) from [] (mmc_blk_remove_req+0xd0/0xe8 [mmc_block])
[ 266.326568] [] (mmc_blk_remove_req [mmc_block]) from [] (mmc_blk_remove_parts.constprop.6+0x50/0x64 [mmc_block])
[ 266.329678] [] (mmc_blk_remove_parts.constprop.6 [mmc_block]) from [] (mmc_blk_remove+0x24/0x140 [mmc_block])
[ 266.332894] [] (mmc_blk_remove [mmc_block]) from [] (mmc_bus_remove+0x20/0x28 [mmc_core])
[ 266.336198] [] (mmc_bus_remove [mmc_core]) from [] (device_release_driver_internal+0x164/0x200)
[ 266.339367] [] (device_release_driver_internal) from [] (driver_detach+0x40/0x74)
[ 266.342537] [] (driver_detach) from [] (bus_remove_driver+0x68/0xdc)
[ 266.345660] [] (bus_remove_driver) from [] (mmc_blk_exit+0xc/0x2cc [mmc_block])
[ 266.348875] [] (mmc_blk_exit [mmc_block]) from [] (SyS_delete_module+0x1c4/0x254)
[ 266.352068] [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x34)
[ 266.355308] ---[ end trace f68728a0d3053b72 ]---Fixes: 7c84b8b43d3d ("mmc: block: bypass the queue even if usage is present for hotplug")
Signed-off-by: Michał Mirosław
Reviewed-by: Shawn Lin
Signed-off-by: Ulf Hansson
(cherry picked from commit 3f8b23a09a87aa65df3e13129cb2d9cffcb394db)
Signed-off-by: Vipul Kumar -
strobe-dll-delay-target is the delay cell add on the strobe line.
Strobe line the the uSDHC loopback read clock which is use in HS400
mode. Different strobe-dll-delay-target may need to set for different
board/SoC. If this delay cell is not set to an appropriate value,
we may see some read operation meet CRC error after HS400 mode select
which already pass the tuning.This patch add the strobe-dll-delay-target setting in driver, so that
user can easily config this delay cell in dts file.Signed-off-by: Haibo Chen
Reviewed-by: Dong Aisheng
TODO: checkpatch warnings
Signed-off-by: Vipul Kumar -
The default max segment size of IOMMU is 64KB, which exceed the ADMA
limitation. ADMA only support max to 65535, 64KB - 1Byte. IOMMU will
optimize the segments it received, merge the little segment into one
big segment. If we use the default IOMMU config, then ADMA will get
some segments which it's size is 64KB. Then ADMA error will shows up.Currently, when use standard tuning, driver default disable DMA. But
on i.MX usdhc, this is not enough. Need also clear DMA_SEL. If not,
once the DMA_SEL select AMDA2, even dma already disabled, when send
tuning command, usdhc will still prefetch the ADMA script from wrong
DMA address, then we will see IOMMU report some error which show
lack of TLB mapping.This patch fix these two issue, make sure usdhc can work well by
operate data through IOMMU.Signed-off-by: Haibo Chen
Signed-off-by: Vipul Kumar -
The commit 304419d8a7e9 ("mmc: core: Allocate per-request data using the
block layer core") refactored mechanism of queue handling caused
mmc_init_request() can be called just after mmc_cleanup_queue() caused null
pointer dereference.Another commit bbdc74dc19e0 ("mmc: block: Prevent new req entering queue
after its cleanup") tried to fix the problem. However it actually miss one
corner case.We could still reproduce the issue mentioned with these steps:
(1) insert a SD card and mount it
(2) hotplug it, so it will leave md->usage still be counted
(3) reboot the system which will sync data and umount the card[Unable to handle kernel NULL pointer dereference at virtual address
00000000
[user pgtable: 4k pages, 48-bit VAs, pgd = ffff80007bab3000
[[0000000000000000] *pgd=000000007a828003, *pud=0000000078dce003,
*pmd=000000007aab6003, *pte=0000000000000000
[Internal error: Oops: 96000007 [#1] PREEMPT SMP
[Modules linked in:
[CPU: 3 PID: 3507 Comm: umount Tainted: G W
4.13.0-rc1-next-20170720-00012-g9d9bf45 #33
[Hardware name: Firefly-RK3399 Board (DT)
[task: ffff80007a1de200 task.stack: ffff80007a01c000
[PC is at mmc_init_request+0x14/0xc4
[LR is at alloc_request_size+0x4c/0x74
[pc : [] lr : [] pstate: 600001c5
[sp : ffff80007a01f8f0....
[[] mmc_init_request+0x14/0xc4
[[] alloc_request_size+0x4c/0x74
[[] mempool_create_node+0xb8/0x17c
[[] blk_init_rl+0x9c/0x120
[[] blkg_alloc+0x110/0x234
[[] blkg_create+0x424/0x468
[[] blkg_lookup_create+0xd8/0x14c
[[] generic_make_request_checks+0x368/0x3b0
[[] generic_make_request+0x1c/0x240So mmc_blk_put wouldn't calling blk_cleanup_queue which actually the
QUEUE_FLAG_DYING and QUEUE_FLAG_BYPASS should stay. Block core expect
blk_queue_bypass_{start, end} internally to bypass/drain the queue before
actually dying the queue, so it didn't expose API to set the queue bypass.
I think we should set QUEUE_FLAG_BYPASS whenever queue is removed, although
the md->usage is still counted, as no dispatch queue could be found then.Fixes: 304419d8a7e9 ("mmc: core: Allocate per-request data using the block layer core")
Signed-off-by: Shawn Lin
Reviewed-by: Linus Walleij
Signed-off-by: Ulf Hansson
(cherry picked from commit 7c84b8b43d3d550fa6f0b57277d03f2e1bafb357)
Signed-off-by: Vipul Kumar -
The commit 304419d8a7e9 ("mmc: core: Allocate per-request data using the
block layer core"), refactored the mechanism of queue handling, but also
made mmc_init_request() to be called after mmc_cleanup_queue(). This
triggers a null pointer dereference:[ 683.123791] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 683.123801] IP: mmc_init_request+0x2c/0xf0 [mmc_block]
...
[ 683.123905] Call Trace:
[ 683.123913] alloc_request_size+0x4f/0x70
[ 683.123919] mempool_alloc+0x5f/0x150
[ 683.123925] ? __enqueue_entity+0x6c/0x70
[ 683.123928] get_request+0x3ad/0x720
[ 683.123933] ? prepare_to_wait_event+0x110/0x110
[ 683.123937] blk_queue_bio+0xc1/0x3a0
[ 683.123940] generic_make_request+0xf8/0x2a0
[ 683.123942] submit_bio+0x75/0x150
[ 683.123947] submit_bio_wait+0x51/0x70
[ 683.123951] blkdev_issue_flush+0x5c/0x90
[ 683.123956] ext4_sync_fs+0x171/0x1b0
[ 683.123961] sync_filesystem+0x73/0x90
[ 683.123965] fsync_bdev+0x24/0x50
[ 683.123971] invalidate_partition+0x24/0x50
[ 683.123973] del_gendisk+0xb2/0x2a0
[ 683.123977] mmc_blk_remove_req.part.38+0x71/0xa0 [mmc_block]
[ 683.123980] mmc_blk_remove+0xba/0x190 [mmc_block]
[ 683.123990] mmc_bus_remove+0x1a/0x20 [mmc_core]
[ 683.123995] device_release_driver_internal+0x141/0x200
[ 683.123999] device_release_driver+0x12/0x20
[ 683.124001] bus_remove_device+0xfd/0x170
[ 683.124004] device_del+0x1e8/0x330
[ 683.124012] mmc_remove_card+0x60/0xc0 [mmc_core]
[ 683.124019] mmc_remove+0x19/0x30 [mmc_core]
[ 683.124025] mmc_stop_host+0xfb/0x1a0 [mmc_core]
[ 683.124032] mmc_remove_host+0x1a/0x40 [mmc_core]
[ 683.124037] sdhci_remove_host+0x2e/0x1c0 [mmc_sdhci]
[ 683.124042] sdhci_pci_remove_slot+0x3f/0x80 [sdhci_pci]
[ 683.124045] sdhci_pci_remove+0x39/0x70 [sdhci_pci]
[ 683.124049] pci_device_remove+0x39/0xc0
[ 683.124052] device_release_driver_internal+0x141/0x200
[ 683.124056] driver_detach+0x3f/0x80
[ 683.124059] bus_remove_driver+0x55/0xd0
[ 683.124062] driver_unregister+0x2c/0x50
[ 683.124065] pci_unregister_driver+0x29/0x90
[ 683.124069] sdhci_driver_exit+0x10/0x4f3 [sdhci_pci]
[ 683.124073] SyS_delete_module+0x171/0x250
[ 683.124078] entry_SYSCALL_64_fastpath+0x1e/0xa9Fix this by setting the queue DYING flag before cleanup the queue, as it
prevents new reqs from entering the queue.Signed-off-by: Grzegorz Sluja
Signed-off-by: Linus Walleij
Fixes: 304419d8a7e9 ("mmc: core: Allocate per-request data using the...")
[Ulf: Updated the changelog]
Signed-off-by: Ulf Hansson(cherry picked from commit bbdc74dc19e09ac4e71bfb219596b3d5bc786720)
(Vipul: Fixed merge conflicts)
Signed-off-by: Vipul Kumar -
When the last ready-buffer-ready is set, then usdhc execute-tuning
bit is clear, this means usdhc finish the tuning process, but at
this time, sd/mmc card may still out put the tuning data, can't
response to any command. So this patch add 1ms delay when usdhc
finish the tuning, make sure sd/mmc card finish sending the tuning
data, then sd/mmc can response the following command normally.Signed-off-by: Haibo Chen
Reviewed-by: Dong Aisheng
Signed-off-by: Vipul Kumar -
Currently, USDHC do not generate transfer complete interrupt
when send a non-data-command with R1b response. But if want
to support DCMD in CMDQ, need to change this, the DCMD IC
logic require the USDHC to enable this function, otherwise
DCMD will never get a CC(command complete) interrupt.This patch set ESDHC_VEND_SPEC2_EN_BUSY_IRQ and add DCMD support.
Signed-off-by: Haibo Chen
Reviewed-by: Dong Aisheng
Signed-off-by: Vipul Kumar -
Add CMDQ support for imx8qm/imx8qxp.
Signed-off-by: Haibo Chen
Reviewed-by: Dong Aisheng
(Vipul: Fixed merge conflicts)
Signed-off-by: Vipul Kumar -
Priority use the callback set_timeout() to set the maximum timeout
if the host has.Signed-off-by: Haibo Chen
Reviewed-by: Dong Aisheng
Signed-off-by: Vipul Kumar -
When pm_runtime_suspend is run, a call to SCFW power off the SS in
which the resource resides is made. The SCFW can power off the SS
if no other resource in active in tha SS. If so, all state associated
with all the resources within the SS that is powered off is lost,
this includes the clock rates, clock state etc. When pm_runtime_resume
is called, the SS associated with that resource is powered up. But
the clocks are left in the default state.This patch restore clock rate in pm_runtime_resume, make sure the
clock is right rather than depending on the default state setting
by SCFW.Signed-off-by: Haibo Chen
(Vipul: Fixed merge conflicts)
Signed-off-by: Vipul Kumar -
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
Signed-off-by: Vipul Kumar -
i.MX8 don't define ARCH_MXC, so add COMPILE_TEST to let usdhc driver
also support for i.MX8.Signed-off-by: Haibo Chen
Signed-off-by: Vipul Kumar -
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
Signed-off-by: Vipul Kumar -
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
Signed-off-by: Vipul Kumar -
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
Signed-off-by: Vipul Kumar -
MMC core code add 'MMC_CAP_RUNTIME_RESUME', postpone the real card
resume operation from bus_resume to bus_runtime_resume. So after
system resume, for non-removable-card, it still not really resume.
At this point, if user cat the ios or clock node, only get zero
data although the mmc/sd card is still present.This patch add mmc_get_card() to make sure card really resume back
when user cat ios or clock debugfs file node, then user can get the
correct information.Signed-off-by: Haibo Chen
Vipul: Fixes for 4.19 kernel.
Signed-off-by: Vipul Kumar -
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
(Vipul: Fixed merge conflicts)
Signed-off-by: Vipul Kumar -
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
Signed-off-by: Vipul Kumar -
When usdhc driver remove, also need to release bus frequency.
Signed-off-by: Haibo Chen
Signed-off-by: Vipul Kumar -
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
Signed-off-by: Vipul Kumar
