On 2017/3/9 10:47, Shawn Lin wrote:
On 2017/3/8 21:27, Jaehoon Chung wrote:
On 03/08/2017 05:08 PM, Adrian Hunter wrote:
On 08/03/17 07:18, Jaehoon Chung wrote:
Hi Adrian,
On 03/06/2017 06:10 PM, Adrian Hunter wrote:
Hi
Here are the hardware command queue patches without the software
command
queue patches or sdhci patches.
I don't see your patches fully yet, but after applied your patches,
dwmmc host doesn't work.
So I'm finding what happen in dwmmc controller.
After finding problem, i will share it.
Well,.. maybe i missed something...
Thanks for trying these patches.
With no host controller yet using CQE, there isn't much changing in this
patch set, but bisecting should reveal the first bad commit.
https://patchwork.kernel.org/patch/9605315/
It seems that this patch has a problem...Tomorrow i will check in more
detail.
Because I saw the different error logs..
Sometime occurred the NULL pointer dereference or I/O error..
Didn't other guys see these problem?
I was running linux-next with this pachset, but it can't boot up my
Debain system, and mostly the log looks like
[ 4.137331] Hardware name: Rockchip (Device Tree)
[ 4.142585] task: ee753180 task.stack: ee7ca000
[ 4.142593] PC is at mmc_blk_rw_rq_prep+0x2c/0x3b0
[ 4.142595] LR is at mmc_blk_issue_rw_rq+0x64/0x340
[ 4.142599] pc : [<c0a85b74>] lr : [<c0a86844>] psr: 8001001
so the first argument, namely mqrq is freed somehow.
c0a85b48 <mmc_blk_rw_rq_prep>:
c0a85b48: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp,
lr}
c0a85b4c: e1a0a003 mov sl, r3
c0a85b50: e593301c ldr r3, [r3, #28]
c0a85b54: e24dd00c sub sp, sp, #12
c0a85b58: e2909004 adds r9, r0, #4
c0a85b5c: e1a04000 mov r4, r0
c0a85b60: e1a05001 mov r5, r1
c0a85b64: e1a0b002 mov fp, r2
c0a85b68: e5906000 ldr r6, [r0]
c0a85b6c: e58d3004 str r3, [sp, #4]
c0a85b70: 0a0000d8 beq c0a85ed8 <mmc_blk_rw_rq_prep+0x390>
/* we trap here for fetching r6, and it was from [r0], the mqrq */
c0a85b74: e5968024 ldr r8, [r6, #36] ; 0x24
c0a85b78: e3a02802 mov r2, #131072 ; 0x20000
Just update what I found when rebooting my board again, I am seeing
my userspace are trying to access RPMB and BOOT part endlessly...
I haven't enough time to look closely at what happened. But from the
commit msg of patch 1, I suspet is it correct for us to say the queue
was empty before switch partitions?(I need to check if there is a case
that the queue was empty but the mrq was hold by host drivers, for
instance, dwmmc wouldqueue more mrqs when it is busy with doing
previous mrq)
Then I did a quick HACK intuitively by removing the BOOT AREA and it
works....
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -447,6 +447,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card,
u8 *ext_csd)
* There are two boot regions of equal size, defined in
* multiples of 128K.
*/
+ /*
if (ext_csd[EXT_CSD_BOOT_MULT] &&
mmc_boot_partition_access(card->host)) {
for (idx = 0; idx < MMC_NUM_BOOT_PARTITION;
idx++) {
part_size = ext_csd[EXT_CSD_BOOT_MULT]
<< 17;
@@ -455,7 +456,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card,
u8 *ext_csd)
"boot%d", idx, true,
MMC_BLK_DATA_AREA_BOOT);
}
- }
+ }*/
Thought?
Best Regards,
Jaehoon Chung
Best Regards,
Jaehoon Chung
Changes since RFC:
Re-based on next.
Added comment about command queue priority.
Added some acks and reviews.
Adrian Hunter (17):
mmc: queue: Share mmc request array between partitions
mmc: mmc: Add functions to enable / disable the Command Queue
mmc: mmc_test: Disable Command Queue while mmc_test is used
mmc: block: Disable Command Queue while RPMB is used
mmc: block: Change mmc_apply_rel_rw() to get block address
from the request
mmc: block: Factor out data preparation
mmc: core: Factor out debug prints from mmc_start_request()
mmc: core: Factor out mrq preparation from mmc_start_request()
mmc: core: Add mmc_retune_hold_now()
mmc: core: Add members to mmc_request and mmc_data for CQE's
mmc: host: Add CQE interface
mmc: core: Turn off CQE before sending commands
mmc: core: Add support for handling CQE requests
mmc: mmc: Enable Command Queuing
mmc: mmc: Enable CQE's
mmc: block: Prepare CQE data
mmc: block: Add CQE support
Venkat Gopalakrishnan (1):
mmc: cqhci: support for command queue enabled host
Documentation/mmc/mmc-dev-attrs.txt | 1 +
drivers/mmc/core/block.c | 435 ++++++++++---
drivers/mmc/core/block.h | 7 +
drivers/mmc/core/bus.c | 7 +
drivers/mmc/core/core.c | 203 ++++++-
drivers/mmc/core/host.c | 6 +
drivers/mmc/core/host.h | 1 +
drivers/mmc/core/mmc.c | 39 +-
drivers/mmc/core/mmc_ops.c | 28 +
drivers/mmc/core/mmc_ops.h | 2 +
drivers/mmc/core/mmc_test.c | 14 +
drivers/mmc/core/queue.c | 535 +++++++++++++---
drivers/mmc/core/queue.h | 45 +-
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/cqhci.c | 1148
+++++++++++++++++++++++++++++++++++
drivers/mmc/host/cqhci.h | 240 ++++++++
include/linux/mmc/card.h | 8 +
include/linux/mmc/core.h | 19 +-
include/linux/mmc/host.h | 24 +
include/trace/events/mmc.h | 17 +-
21 files changed, 2585 insertions(+), 208 deletions(-)
create mode 100644 drivers/mmc/host/cqhci.c
create mode 100644 drivers/mmc/host/cqhci.h
Regards
Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
