* [PATCH V8 12/20] mmc: block: Disable Command Queue while RPMB is used
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
RPMB does not allow Command Queue commands. Disable and re-enable the
Command Queue when switching.
Note that the driver only switches partitions when the queue is empty.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
---
drivers/mmc/card/block.c | 46 ++++++++++++++++++++++++++++++++++++++--------
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 646d1a1fa6ca..e84e2d8f6e31 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -725,10 +725,41 @@ static int mmc_blk_compat_ioctl(struct block_device *bdev, fmode_t mode,
#endif
};
+static int mmc_blk_part_switch_pre(struct mmc_card *card,
+ unsigned int part_type)
+{
+ int ret = 0;
+
+ if (part_type == EXT_CSD_PART_CONFIG_ACC_RPMB) {
+ if (card->ext_csd.cmdq_en) {
+ ret = mmc_cmdq_disable(card);
+ if (ret)
+ return ret;
+ }
+ mmc_retune_pause(card->host);
+ }
+
+ return ret;
+}
+
+static int mmc_blk_part_switch_post(struct mmc_card *card,
+ unsigned int part_type)
+{
+ int ret = 0;
+
+ if (part_type == EXT_CSD_PART_CONFIG_ACC_RPMB) {
+ mmc_retune_unpause(card->host);
+ if (card->reenable_cmdq && !card->ext_csd.cmdq_en)
+ ret = mmc_cmdq_enable(card);
+ }
+
+ return ret;
+}
+
static inline int mmc_blk_part_switch(struct mmc_card *card,
struct mmc_blk_data *md)
{
- int ret;
+ int ret = 0;
struct mmc_blk_data *main_md = dev_get_drvdata(&card->dev);
if (main_md->part_curr == md->part_type)
@@ -737,8 +768,9 @@ static inline int mmc_blk_part_switch(struct mmc_card *card,
if (mmc_card_mmc(card)) {
u8 part_config = card->ext_csd.part_config;
- if (md->part_type == EXT_CSD_PART_CONFIG_ACC_RPMB)
- mmc_retune_pause(card->host);
+ ret = mmc_blk_part_switch_pre(card, md->part_type);
+ if (ret)
+ return ret;
part_config &= ~EXT_CSD_PART_CONFIG_ACC_MASK;
part_config |= md->part_type;
@@ -747,19 +779,17 @@ static inline int mmc_blk_part_switch(struct mmc_card *card,
EXT_CSD_PART_CONFIG, part_config,
card->ext_csd.part_time);
if (ret) {
- if (md->part_type == EXT_CSD_PART_CONFIG_ACC_RPMB)
- mmc_retune_unpause(card->host);
+ mmc_blk_part_switch_post(card, md->part_type);
return ret;
}
card->ext_csd.part_config = part_config;
- if (main_md->part_curr == EXT_CSD_PART_CONFIG_ACC_RPMB)
- mmc_retune_unpause(card->host);
+ ret = mmc_blk_part_switch_post(card, main_md->part_curr);
}
main_md->part_curr = md->part_type;
- return 0;
+ return ret;
}
static u32 mmc_sd_num_wr_blocks(struct mmc_card *card)
--
1.9.1
^ permalink raw reply related
* [PATCH V8 11/20] mmc: mmc_test: Disable Command Queue while mmc_test is used
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
Normal read and write commands may not be used while the command queue is
enabled. Disable the Command Queue when mmc_test is probed and re-enable it
when it is removed.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
---
drivers/mmc/card/mmc_test.c | 13 +++++++++++++
drivers/mmc/core/mmc.c | 7 +++++++
include/linux/mmc/card.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 5ba6d77b9723..b42c23665104 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -3264,6 +3264,14 @@ static int mmc_test_probe(struct mmc_card *card)
if (ret)
return ret;
+ if (card->ext_csd.cmdq_en) {
+ mmc_claim_host(card->host);
+ ret = mmc_cmdq_disable(card);
+ mmc_release_host(card->host);
+ if (ret)
+ return ret;
+ }
+
dev_info(&card->dev, "Card claimed for testing.\n");
return 0;
@@ -3271,6 +3279,11 @@ static int mmc_test_probe(struct mmc_card *card)
static void mmc_test_remove(struct mmc_card *card)
{
+ if (card->reenable_cmdq) {
+ mmc_claim_host(card->host);
+ mmc_cmdq_enable(card);
+ mmc_release_host(card->host);
+ }
mmc_test_free_result(card);
mmc_test_free_dbgfs_file(card);
}
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 76432ebc0b06..720759a81296 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1756,6 +1756,13 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
}
/*
+ * In some cases (e.g. RPMB or mmc_test), the Command Queue must be
+ * disabled for a time, so a flag is needed to indicate to re-enable the
+ * Command Queue.
+ */
+ card->reenable_cmdq = card->ext_csd.cmdq_en;
+
+ /*
* The mandatory minimum values are defined for packed command.
* read: 5, write: 3
*/
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 2d9c24f4e88e..5ac2243bc5a9 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -273,6 +273,7 @@ struct mmc_card {
#define MMC_QUIRK_TRIM_BROKEN (1<<12) /* Skip trim */
#define MMC_QUIRK_BROKEN_HPI (1<<13) /* Disable broken HPI support */
+ bool reenable_cmdq; /* Re-enable Command Queue */
unsigned int erase_size; /* erase size in sectors */
unsigned int erase_shift; /* if erase unit is power 2 */
--
1.9.1
^ permalink raw reply related
* [PATCH V8 10/20] mmc: mmc: Add functions to enable / disable the Command Queue
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
Add helper functions to enable or disable the Command Queue.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
Documentation/mmc/mmc-dev-attrs.txt | 1 +
drivers/mmc/core/mmc.c | 2 ++
drivers/mmc/core/mmc_ops.c | 28 ++++++++++++++++++++++++++++
include/linux/mmc/card.h | 1 +
include/linux/mmc/core.h | 2 ++
5 files changed, 34 insertions(+)
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
index 404a0e9e92b0..dcd1252877fb 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -30,6 +30,7 @@ All attributes are read-only.
rel_sectors Reliable write sector count
ocr Operation Conditions Register
dsr Driver Stage Register
+ cmdq_en Command Queue enabled: 1 => enabled, 0 => not enabled
Note on Erase Size and Preferred Erase Size:
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 16cf6ea6e1ba..76432ebc0b06 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -771,6 +771,7 @@ static int mmc_compare_ext_csds(struct mmc_card *card, unsigned bus_width)
MMC_DEV_ATTR(raw_rpmb_size_mult, "%#x\n", card->ext_csd.raw_rpmb_size_mult);
MMC_DEV_ATTR(rel_sectors, "%#x\n", card->ext_csd.rel_sectors);
MMC_DEV_ATTR(ocr, "%08x\n", card->ocr);
+MMC_DEV_ATTR(cmdq_en, "%d\n", card->ext_csd.cmdq_en);
static ssize_t mmc_fwrev_show(struct device *dev,
struct device_attribute *attr,
@@ -824,6 +825,7 @@ static ssize_t mmc_dsr_show(struct device *dev,
&dev_attr_rel_sectors.attr,
&dev_attr_ocr.attr,
&dev_attr_dsr.attr,
+ &dev_attr_cmdq_en.attr,
NULL,
};
ATTRIBUTE_GROUPS(mmc_std);
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 9b2617cfff67..896a8818e901 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -824,3 +824,31 @@ int mmc_can_ext_csd(struct mmc_card *card)
{
return (card && card->csd.mmca_vsn > CSD_SPEC_VER_3);
}
+
+static int mmc_cmdq_switch(struct mmc_card *card, bool enable)
+{
+ u8 val = enable ? EXT_CSD_CMDQ_MODE_ENABLED : 0;
+ int err;
+
+ if (!card->ext_csd.cmdq_support)
+ return -EOPNOTSUPP;
+
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_CMDQ_MODE_EN,
+ val, card->ext_csd.generic_cmd6_time);
+ if (!err)
+ card->ext_csd.cmdq_en = enable;
+
+ return err;
+}
+
+int mmc_cmdq_enable(struct mmc_card *card)
+{
+ return mmc_cmdq_switch(card, true);
+}
+EXPORT_SYMBOL_GPL(mmc_cmdq_enable);
+
+int mmc_cmdq_disable(struct mmc_card *card)
+{
+ return mmc_cmdq_switch(card, false);
+}
+EXPORT_SYMBOL_GPL(mmc_cmdq_disable);
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 95d69d498296..2d9c24f4e88e 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -89,6 +89,7 @@ struct mmc_ext_csd {
unsigned int boot_ro_lock; /* ro lock support */
bool boot_ro_lockable;
bool ffu_capable; /* Firmware upgrade support */
+ bool cmdq_en; /* Command Queue enabled */
bool cmdq_support; /* Command Queue supported */
unsigned int cmdq_depth; /* Command Queue depth */
#define MMC_FIRMWARE_LEN 8
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 0ce928b3ce90..d045b06fc7ea 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -177,6 +177,8 @@ extern int mmc_wait_for_app_cmd(struct mmc_host *, struct mmc_card *,
extern int mmc_switch(struct mmc_card *, u8, u8, u8, unsigned int);
extern int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error);
extern int mmc_get_ext_csd(struct mmc_card *card, u8 **new_ext_csd);
+extern int mmc_cmdq_enable(struct mmc_card *card);
+extern int mmc_cmdq_disable(struct mmc_card *card);
#define MMC_ERASE_ARG 0x00000000
#define MMC_SECURE_ERASE_ARG 0x80000000
--
1.9.1
^ permalink raw reply related
* [PATCH V8 09/20] mmc: mmc: Add Command Queue definitions
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
Add definitions relating to Command Queuing.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/mmc/core/mmc.c | 18 ++++++++++++++++++
include/linux/mmc/card.h | 2 ++
include/linux/mmc/mmc.h | 17 +++++++++++++++++
3 files changed, 37 insertions(+)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 3268fcd3378d..16cf6ea6e1ba 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -618,6 +618,24 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd)
(ext_csd[EXT_CSD_SUPPORTED_MODE] & 0x1) &&
!(ext_csd[EXT_CSD_FW_CONFIG] & 0x1);
}
+
+ /* eMMC v5.1 or later */
+ if (card->ext_csd.rev >= 8) {
+ card->ext_csd.cmdq_support = ext_csd[EXT_CSD_CMDQ_SUPPORT] &
+ EXT_CSD_CMDQ_SUPPORTED;
+ card->ext_csd.cmdq_depth = (ext_csd[EXT_CSD_CMDQ_DEPTH] &
+ EXT_CSD_CMDQ_DEPTH_MASK) + 1;
+ /* Exclude inefficiently small queue depths */
+ if (card->ext_csd.cmdq_depth <= 2) {
+ card->ext_csd.cmdq_support = false;
+ card->ext_csd.cmdq_depth = 0;
+ }
+ if (card->ext_csd.cmdq_support) {
+ pr_debug("%s: Command Queue supported depth %u\n",
+ mmc_hostname(card->host),
+ card->ext_csd.cmdq_depth);
+ }
+ }
out:
return err;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index e49a3ff9d0e0..95d69d498296 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -89,6 +89,8 @@ struct mmc_ext_csd {
unsigned int boot_ro_lock; /* ro lock support */
bool boot_ro_lockable;
bool ffu_capable; /* Firmware upgrade support */
+ bool cmdq_support; /* Command Queue supported */
+ unsigned int cmdq_depth; /* Command Queue depth */
#define MMC_FIRMWARE_LEN 8
u8 fwrev[MMC_FIRMWARE_LEN]; /* FW version */
u8 raw_exception_status; /* 54 */
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index c376209c70ef..672730acc705 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -84,6 +84,13 @@
#define MMC_APP_CMD 55 /* ac [31:16] RCA R1 */
#define MMC_GEN_CMD 56 /* adtc [0] RD/WR R1 */
+ /* class 11 */
+#define MMC_QUE_TASK_PARAMS 44 /* ac [20:16] task id R1 */
+#define MMC_QUE_TASK_ADDR 45 /* ac [31:0] data addr R1 */
+#define MMC_EXECUTE_READ_TASK 46 /* adtc [20:16] task id R1 */
+#define MMC_EXECUTE_WRITE_TASK 47 /* adtc [20:16] task id R1 */
+#define MMC_CMDQ_TASK_MGMT 48 /* ac [20:16] task id R1b */
+
static inline bool mmc_op_multi(u32 opcode)
{
return opcode == MMC_WRITE_MULTIPLE_BLOCK ||
@@ -272,6 +279,7 @@ struct _mmc_csd {
* EXT_CSD fields
*/
+#define EXT_CSD_CMDQ_MODE_EN 15 /* R/W */
#define EXT_CSD_FLUSH_CACHE 32 /* W */
#define EXT_CSD_CACHE_CTRL 33 /* R/W */
#define EXT_CSD_POWER_OFF_NOTIFICATION 34 /* R/W */
@@ -331,6 +339,8 @@ struct _mmc_csd {
#define EXT_CSD_CACHE_SIZE 249 /* RO, 4 bytes */
#define EXT_CSD_PWR_CL_DDR_200_360 253 /* RO */
#define EXT_CSD_FIRMWARE_VERSION 254 /* RO, 8 bytes */
+#define EXT_CSD_CMDQ_DEPTH 307 /* RO */
+#define EXT_CSD_CMDQ_SUPPORT 308 /* RO */
#define EXT_CSD_SUPPORTED_MODE 493 /* RO */
#define EXT_CSD_TAG_UNIT_SIZE 498 /* RO */
#define EXT_CSD_DATA_TAG_SUPPORT 499 /* RO */
@@ -438,6 +448,13 @@ struct _mmc_csd {
#define EXT_CSD_MANUAL_BKOPS_MASK 0x01
/*
+ * Command Queue
+ */
+#define EXT_CSD_CMDQ_MODE_ENABLED BIT(0)
+#define EXT_CSD_CMDQ_DEPTH_MASK GENMASK(4, 0)
+#define EXT_CSD_CMDQ_SUPPORTED BIT(0)
+
+/*
* MMC_SWITCH access modes
*/
--
1.9.1
^ permalink raw reply related
* [PATCH V8 08/20] mmc: queue: Introduce queue depth and use it to allocate and free
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
Add a mmc_queue member to record the size of the queue, which currently
supports 2 requests on-the-go at a time. Instead of allocating resources
for 2 slots in the queue, allow for an arbitrary number.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
drivers/mmc/card/queue.c | 115 +++++++++++++++++++++++------------------------
drivers/mmc/card/queue.h | 3 +-
2 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 7234cc48097e..48197545b539 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -189,86 +189,75 @@ static void mmc_queue_setup_discard(struct request_queue *q,
static bool mmc_queue_alloc_bounce_bufs(struct mmc_queue *mq,
unsigned int bouncesz)
{
- struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
- struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
-
- mqrq_cur->bounce_buf = kmalloc(bouncesz, GFP_KERNEL);
- if (!mqrq_cur->bounce_buf) {
- pr_warn("%s: unable to allocate bounce cur buffer\n",
- mmc_card_name(mq->card));
- return false;
- }
+ int i;
- mqrq_prev->bounce_buf = kmalloc(bouncesz, GFP_KERNEL);
- if (!mqrq_prev->bounce_buf) {
- pr_warn("%s: unable to allocate bounce prev buffer\n",
- mmc_card_name(mq->card));
- kfree(mqrq_cur->bounce_buf);
- mqrq_cur->bounce_buf = NULL;
- return false;
+ for (i = 0; i < mq->qdepth; i++) {
+ mq->mqrq[i].bounce_buf = kmalloc(bouncesz, GFP_KERNEL);
+ if (!mq->mqrq[i].bounce_buf)
+ goto out_err;
}
return true;
+
+out_err:
+ while (--i >= 0) {
+ kfree(mq->mqrq[i].bounce_buf);
+ mq->mqrq[i].bounce_buf = NULL;
+ }
+ pr_warn("%s: unable to allocate bounce buffers\n",
+ mmc_card_name(mq->card));
+ return false;
}
static int mmc_queue_alloc_bounce_sgs(struct mmc_queue *mq,
unsigned int bouncesz)
{
- struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
- struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
- int ret;
-
- mqrq_cur->sg = mmc_alloc_sg(1, &ret);
- if (ret)
- return ret;
-
- mqrq_cur->bounce_sg = mmc_alloc_sg(bouncesz / 512, &ret);
- if (ret)
- return ret;
+ int i, ret;
- mqrq_prev->sg = mmc_alloc_sg(1, &ret);
- if (ret)
- return ret;
+ for (i = 0; i < mq->qdepth; i++) {
+ mq->mqrq[i].sg = mmc_alloc_sg(1, &ret);
+ if (ret)
+ return ret;
- mqrq_prev->bounce_sg = mmc_alloc_sg(bouncesz / 512, &ret);
+ mq->mqrq[i].bounce_sg = mmc_alloc_sg(bouncesz / 512, &ret);
+ if (ret)
+ return ret;
+ }
- return ret;
+ return 0;
}
static int mmc_queue_alloc_sgs(struct mmc_queue *mq, int max_segs)
{
- struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
- struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
- int ret;
+ int i, ret;
- mqrq_cur->sg = mmc_alloc_sg(max_segs, &ret);
- if (ret)
- return ret;
+ for (i = 0; i < mq->qdepth; i++) {
+ mq->mqrq[i].sg = mmc_alloc_sg(max_segs, &ret);
+ if (ret)
+ return ret;
+ }
- mqrq_prev->sg = mmc_alloc_sg(max_segs, &ret);
+ return 0;
+}
- return ret;
+static void mmc_queue_req_free_bufs(struct mmc_queue_req *mqrq)
+{
+ kfree(mqrq->bounce_sg);
+ mqrq->bounce_sg = NULL;
+
+ kfree(mqrq->sg);
+ mqrq->sg = NULL;
+
+ kfree(mqrq->bounce_buf);
+ mqrq->bounce_buf = NULL;
}
static void mmc_queue_reqs_free_bufs(struct mmc_queue *mq)
{
- struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
- struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
-
- kfree(mqrq_cur->bounce_sg);
- mqrq_cur->bounce_sg = NULL;
- kfree(mqrq_prev->bounce_sg);
- mqrq_prev->bounce_sg = NULL;
-
- kfree(mqrq_cur->sg);
- mqrq_cur->sg = NULL;
- kfree(mqrq_cur->bounce_buf);
- mqrq_cur->bounce_buf = NULL;
-
- kfree(mqrq_prev->sg);
- mqrq_prev->sg = NULL;
- kfree(mqrq_prev->bounce_buf);
- mqrq_prev->bounce_buf = NULL;
+ int i;
+
+ for (i = 0; i < mq->qdepth; i++)
+ mmc_queue_req_free_bufs(&mq->mqrq[i]);
}
/**
@@ -286,7 +275,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
struct mmc_host *host = card->host;
u64 limit = BLK_BOUNCE_HIGH;
bool bounce = false;
- int ret;
+ int ret = -ENOMEM;
if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
@@ -296,6 +285,11 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
if (!mq->queue)
return -ENOMEM;
+ mq->qdepth = 2;
+ mq->mqrq = kcalloc(mq->qdepth, sizeof(struct mmc_queue_req),
+ GFP_KERNEL);
+ if (!mq->mqrq)
+ goto blk_cleanup;
mq->mqrq_cur = &mq->mqrq[0];
mq->mqrq_prev = &mq->mqrq[1];
mq->queue->queuedata = mq;
@@ -360,6 +354,9 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
cleanup_queue:
mmc_queue_reqs_free_bufs(mq);
+ kfree(mq->mqrq);
+ mq->mqrq = NULL;
+blk_cleanup:
blk_cleanup_queue(mq->queue);
return ret;
}
@@ -382,6 +379,8 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
spin_unlock_irqrestore(q->queue_lock, flags);
mmc_queue_reqs_free_bufs(mq);
+ kfree(mq->mqrq);
+ mq->mqrq = NULL;
mq->card = NULL;
}
diff --git a/drivers/mmc/card/queue.h b/drivers/mmc/card/queue.h
index d09fce655800..dac8c3d010dd 100644
--- a/drivers/mmc/card/queue.h
+++ b/drivers/mmc/card/queue.h
@@ -42,9 +42,10 @@ struct mmc_queue {
bool asleep;
struct mmc_blk_data *blkdata;
struct request_queue *queue;
- struct mmc_queue_req mqrq[2];
+ struct mmc_queue_req *mqrq;
struct mmc_queue_req *mqrq_cur;
struct mmc_queue_req *mqrq_prev;
+ int qdepth;
};
extern int mmc_init_queue(struct mmc_queue *, struct mmc_card *, spinlock_t *,
--
1.9.1
^ permalink raw reply related
* [PATCH V8 07/20] mmc: queue: Factor out mmc_queue_reqs_free_bufs()
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
In preparation for supporting a queue of requests, factor out
mmc_queue_reqs_free_bufs().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
---
drivers/mmc/card/queue.c | 65 +++++++++++++++++++-----------------------------
1 file changed, 26 insertions(+), 39 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 0a8480f5ea4b..7234cc48097e 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -250,6 +250,27 @@ static int mmc_queue_alloc_sgs(struct mmc_queue *mq, int max_segs)
return ret;
}
+static void mmc_queue_reqs_free_bufs(struct mmc_queue *mq)
+{
+ struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
+ struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
+
+ kfree(mqrq_cur->bounce_sg);
+ mqrq_cur->bounce_sg = NULL;
+ kfree(mqrq_prev->bounce_sg);
+ mqrq_prev->bounce_sg = NULL;
+
+ kfree(mqrq_cur->sg);
+ mqrq_cur->sg = NULL;
+ kfree(mqrq_cur->bounce_buf);
+ mqrq_cur->bounce_buf = NULL;
+
+ kfree(mqrq_prev->sg);
+ mqrq_prev->sg = NULL;
+ kfree(mqrq_prev->bounce_buf);
+ mqrq_prev->bounce_buf = NULL;
+}
+
/**
* mmc_init_queue - initialise a queue structure.
* @mq: mmc queue
@@ -266,8 +287,6 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
u64 limit = BLK_BOUNCE_HIGH;
bool bounce = false;
int ret;
- struct mmc_queue_req *mqrq_cur = &mq->mqrq[0];
- struct mmc_queue_req *mqrq_prev = &mq->mqrq[1];
if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
@@ -277,8 +296,8 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
if (!mq->queue)
return -ENOMEM;
- mq->mqrq_cur = mqrq_cur;
- mq->mqrq_prev = mqrq_prev;
+ mq->mqrq_cur = &mq->mqrq[0];
+ mq->mqrq_prev = &mq->mqrq[1];
mq->queue->queuedata = mq;
blk_queue_prep_rq(mq->queue, mmc_prep_request);
@@ -334,27 +353,13 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
if (IS_ERR(mq->thread)) {
ret = PTR_ERR(mq->thread);
- goto free_bounce_sg;
+ goto cleanup_queue;
}
return 0;
- free_bounce_sg:
- kfree(mqrq_cur->bounce_sg);
- mqrq_cur->bounce_sg = NULL;
- kfree(mqrq_prev->bounce_sg);
- mqrq_prev->bounce_sg = NULL;
cleanup_queue:
- kfree(mqrq_cur->sg);
- mqrq_cur->sg = NULL;
- kfree(mqrq_cur->bounce_buf);
- mqrq_cur->bounce_buf = NULL;
-
- kfree(mqrq_prev->sg);
- mqrq_prev->sg = NULL;
- kfree(mqrq_prev->bounce_buf);
- mqrq_prev->bounce_buf = NULL;
-
+ mmc_queue_reqs_free_bufs(mq);
blk_cleanup_queue(mq->queue);
return ret;
}
@@ -363,8 +368,6 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
{
struct request_queue *q = mq->queue;
unsigned long flags;
- struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
- struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
/* Make sure the queue isn't suspended, as that will deadlock */
mmc_queue_resume(mq);
@@ -378,23 +381,7 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
blk_start_queue(q);
spin_unlock_irqrestore(q->queue_lock, flags);
- kfree(mqrq_cur->bounce_sg);
- mqrq_cur->bounce_sg = NULL;
-
- kfree(mqrq_cur->sg);
- mqrq_cur->sg = NULL;
-
- kfree(mqrq_cur->bounce_buf);
- mqrq_cur->bounce_buf = NULL;
-
- kfree(mqrq_prev->bounce_sg);
- mqrq_prev->bounce_sg = NULL;
-
- kfree(mqrq_prev->sg);
- mqrq_prev->sg = NULL;
-
- kfree(mqrq_prev->bounce_buf);
- mqrq_prev->bounce_buf = NULL;
+ mmc_queue_reqs_free_bufs(mq);
mq->card = NULL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V8 06/20] mmc: queue: Factor out mmc_queue_alloc_sgs()
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
In preparation for supporting a queue of requests, factor out
mmc_queue_alloc_sgs().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
---
drivers/mmc/card/queue.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 3fd27c684292..0a8480f5ea4b 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -235,6 +235,21 @@ static int mmc_queue_alloc_bounce_sgs(struct mmc_queue *mq,
return ret;
}
+static int mmc_queue_alloc_sgs(struct mmc_queue *mq, int max_segs)
+{
+ struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
+ struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
+ int ret;
+
+ mqrq_cur->sg = mmc_alloc_sg(max_segs, &ret);
+ if (ret)
+ return ret;
+
+ mqrq_prev->sg = mmc_alloc_sg(max_segs, &ret);
+
+ return ret;
+}
+
/**
* mmc_init_queue - initialise a queue structure.
* @mq: mmc queue
@@ -307,12 +322,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
blk_queue_max_segments(mq->queue, host->max_segs);
blk_queue_max_segment_size(mq->queue, host->max_seg_size);
- mqrq_cur->sg = mmc_alloc_sg(host->max_segs, &ret);
- if (ret)
- goto cleanup_queue;
-
-
- mqrq_prev->sg = mmc_alloc_sg(host->max_segs, &ret);
+ ret = mmc_queue_alloc_sgs(mq, host->max_segs);
if (ret)
goto cleanup_queue;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V8 05/20] mmc: queue: Factor out mmc_queue_alloc_bounce_sgs()
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
In preparation for supporting a queue of requests, factor out
mmc_queue_alloc_bounce_sgs().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
---
drivers/mmc/card/queue.c | 44 ++++++++++++++++++++++++++++----------------
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 4497a218c245..3fd27c684292 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -211,6 +211,30 @@ static bool mmc_queue_alloc_bounce_bufs(struct mmc_queue *mq,
return true;
}
+static int mmc_queue_alloc_bounce_sgs(struct mmc_queue *mq,
+ unsigned int bouncesz)
+{
+ struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
+ struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
+ int ret;
+
+ mqrq_cur->sg = mmc_alloc_sg(1, &ret);
+ if (ret)
+ return ret;
+
+ mqrq_cur->bounce_sg = mmc_alloc_sg(bouncesz / 512, &ret);
+ if (ret)
+ return ret;
+
+ mqrq_prev->sg = mmc_alloc_sg(1, &ret);
+ if (ret)
+ return ret;
+
+ mqrq_prev->bounce_sg = mmc_alloc_sg(bouncesz / 512, &ret);
+
+ return ret;
+}
+
/**
* mmc_init_queue - initialise a queue structure.
* @mq: mmc queue
@@ -225,6 +249,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
{
struct mmc_host *host = card->host;
u64 limit = BLK_BOUNCE_HIGH;
+ bool bounce = false;
int ret;
struct mmc_queue_req *mqrq_cur = &mq->mqrq[0];
struct mmc_queue_req *mqrq_prev = &mq->mqrq[1];
@@ -267,28 +292,15 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
blk_queue_max_segments(mq->queue, bouncesz / 512);
blk_queue_max_segment_size(mq->queue, bouncesz);
- mqrq_cur->sg = mmc_alloc_sg(1, &ret);
- if (ret)
- goto cleanup_queue;
-
- mqrq_cur->bounce_sg =
- mmc_alloc_sg(bouncesz / 512, &ret);
- if (ret)
- goto cleanup_queue;
-
- mqrq_prev->sg = mmc_alloc_sg(1, &ret);
- if (ret)
- goto cleanup_queue;
-
- mqrq_prev->bounce_sg =
- mmc_alloc_sg(bouncesz / 512, &ret);
+ ret = mmc_queue_alloc_bounce_sgs(mq, bouncesz);
if (ret)
goto cleanup_queue;
+ bounce = true;
}
}
#endif
- if (!mqrq_cur->bounce_buf && !mqrq_prev->bounce_buf) {
+ if (!bounce) {
blk_queue_bounce_limit(mq->queue, limit);
blk_queue_max_hw_sectors(mq->queue,
min(host->max_blk_count, host->max_req_size / 512));
--
1.9.1
^ permalink raw reply related
* [PATCH V8 04/20] mmc: queue: Factor out mmc_queue_alloc_bounce_bufs()
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
In preparation for supporting a queue of requests, factor out
mmc_queue_alloc_bounce_bufs().
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
---
drivers/mmc/card/queue.c | 45 +++++++++++++++++++++++++++------------------
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 010888d8d97c..4497a218c245 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -186,6 +186,31 @@ static void mmc_queue_setup_discard(struct request_queue *q,
queue_flag_set_unlocked(QUEUE_FLAG_SECERASE, q);
}
+static bool mmc_queue_alloc_bounce_bufs(struct mmc_queue *mq,
+ unsigned int bouncesz)
+{
+ struct mmc_queue_req *mqrq_cur = mq->mqrq_cur;
+ struct mmc_queue_req *mqrq_prev = mq->mqrq_prev;
+
+ mqrq_cur->bounce_buf = kmalloc(bouncesz, GFP_KERNEL);
+ if (!mqrq_cur->bounce_buf) {
+ pr_warn("%s: unable to allocate bounce cur buffer\n",
+ mmc_card_name(mq->card));
+ return false;
+ }
+
+ mqrq_prev->bounce_buf = kmalloc(bouncesz, GFP_KERNEL);
+ if (!mqrq_prev->bounce_buf) {
+ pr_warn("%s: unable to allocate bounce prev buffer\n",
+ mmc_card_name(mq->card));
+ kfree(mqrq_cur->bounce_buf);
+ mqrq_cur->bounce_buf = NULL;
+ return false;
+ }
+
+ return true;
+}
+
/**
* mmc_init_queue - initialise a queue structure.
* @mq: mmc queue
@@ -235,24 +260,8 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
if (bouncesz > (host->max_blk_count * 512))
bouncesz = host->max_blk_count * 512;
- if (bouncesz > 512) {
- mqrq_cur->bounce_buf = kmalloc(bouncesz, GFP_KERNEL);
- if (!mqrq_cur->bounce_buf) {
- pr_warn("%s: unable to allocate bounce cur buffer\n",
- mmc_card_name(card));
- } else {
- mqrq_prev->bounce_buf =
- kmalloc(bouncesz, GFP_KERNEL);
- if (!mqrq_prev->bounce_buf) {
- pr_warn("%s: unable to allocate bounce prev buffer\n",
- mmc_card_name(card));
- kfree(mqrq_cur->bounce_buf);
- mqrq_cur->bounce_buf = NULL;
- }
- }
- }
-
- if (mqrq_cur->bounce_buf && mqrq_prev->bounce_buf) {
+ if (bouncesz > 512 &&
+ mmc_queue_alloc_bounce_bufs(mq, bouncesz)) {
blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_ANY);
blk_queue_max_hw_sectors(mq->queue, bouncesz / 512);
blk_queue_max_segments(mq->queue, bouncesz / 512);
--
1.9.1
^ permalink raw reply related
* [PATCH V8 03/20] mmc: queue: Fix queue thread wake-up
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
The only time the driver sleeps expecting to be woken upon the arrival of
a new request, is when the dispatch queue is empty. The only time that it
is known whether the dispatch queue is empty is after NULL is returned
from blk_fetch_request() while under the queue lock.
Recognizing those facts, simplify the synchronization between the queue
thread and the request function. A couple of flags tell the request
function what to do, and the queue lock and barriers associated with
wake-ups ensure synchronization.
The result is simpler and allows the removal of the context_info lock.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
---
drivers/mmc/card/block.c | 7 -------
drivers/mmc/card/queue.c | 35 +++++++++++++++++++++--------------
drivers/mmc/card/queue.h | 1 +
drivers/mmc/core/core.c | 6 ------
include/linux/mmc/host.h | 2 --
5 files changed, 22 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 3e73be0e7281..646d1a1fa6ca 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1758,8 +1758,6 @@ int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
int ret;
struct mmc_blk_data *md = mq->blkdata;
struct mmc_card *card = md->queue.card;
- struct mmc_host *host = card->host;
- unsigned long flags;
bool req_is_special = mmc_req_is_special(req);
if (req && !mq->mqrq_prev->req)
@@ -1792,11 +1790,6 @@ int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
mmc_blk_issue_rw_rq(mq, NULL);
ret = mmc_blk_issue_flush(mq, req);
} else {
- if (!req && host->areq) {
- spin_lock_irqsave(&host->context_info.lock, flags);
- host->context_info.is_waiting_last_req = true;
- spin_unlock_irqrestore(&host->context_info.lock, flags);
- }
ret = mmc_blk_issue_rw_rq(mq, req);
}
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 7dacf2744fbd..010888d8d97c 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -53,6 +53,7 @@ static int mmc_queue_thread(void *d)
{
struct mmc_queue *mq = d;
struct request_queue *q = mq->queue;
+ struct mmc_context_info *cntx = &mq->card->host->context_info;
current->flags |= PF_MEMALLOC;
@@ -63,6 +64,19 @@ static int mmc_queue_thread(void *d)
spin_lock_irq(q->queue_lock);
set_current_state(TASK_INTERRUPTIBLE);
req = blk_fetch_request(q);
+ mq->asleep = false;
+ cntx->is_waiting_last_req = false;
+ cntx->is_new_req = false;
+ if (!req) {
+ /*
+ * Dispatch queue is empty so set flags for
+ * mmc_request_fn() to wake us up.
+ */
+ if (mq->mqrq_prev->req)
+ cntx->is_waiting_last_req = true;
+ else
+ mq->asleep = true;
+ }
mq->mqrq_cur->req = req;
spin_unlock_irq(q->queue_lock);
@@ -115,7 +129,6 @@ static void mmc_request_fn(struct request_queue *q)
{
struct mmc_queue *mq = q->queuedata;
struct request *req;
- unsigned long flags;
struct mmc_context_info *cntx;
if (!mq) {
@@ -127,19 +140,13 @@ static void mmc_request_fn(struct request_queue *q)
}
cntx = &mq->card->host->context_info;
- if (!mq->mqrq_cur->req && mq->mqrq_prev->req) {
- /*
- * New MMC request arrived when MMC thread may be
- * blocked on the previous request to be complete
- * with no current request fetched
- */
- spin_lock_irqsave(&cntx->lock, flags);
- if (cntx->is_waiting_last_req) {
- cntx->is_new_req = true;
- wake_up_interruptible(&cntx->wait);
- }
- spin_unlock_irqrestore(&cntx->lock, flags);
- } else if (!mq->mqrq_cur->req && !mq->mqrq_prev->req)
+
+ if (cntx->is_waiting_last_req) {
+ cntx->is_new_req = true;
+ wake_up_interruptible(&cntx->wait);
+ }
+
+ if (mq->asleep)
wake_up_process(mq->thread);
}
diff --git a/drivers/mmc/card/queue.h b/drivers/mmc/card/queue.h
index 47f5532b5776..d09fce655800 100644
--- a/drivers/mmc/card/queue.h
+++ b/drivers/mmc/card/queue.h
@@ -39,6 +39,7 @@ struct mmc_queue {
unsigned int flags;
#define MMC_QUEUE_SUSPENDED (1 << 0)
#define MMC_QUEUE_NEW_REQUEST (1 << 1)
+ bool asleep;
struct mmc_blk_data *blkdata;
struct request_queue *queue;
struct mmc_queue_req mqrq[2];
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index f39397f7c8dc..dc1f27ee50b8 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -504,18 +504,14 @@ static enum mmc_blk_status mmc_wait_for_data_req_done(struct mmc_host *host,
struct mmc_command *cmd;
struct mmc_context_info *context_info = &host->context_info;
enum mmc_blk_status status;
- unsigned long flags;
while (1) {
wait_event_interruptible(context_info->wait,
(context_info->is_done_rcv ||
context_info->is_new_req));
- spin_lock_irqsave(&context_info->lock, flags);
context_info->is_waiting_last_req = false;
- spin_unlock_irqrestore(&context_info->lock, flags);
if (context_info->is_done_rcv) {
context_info->is_done_rcv = false;
- context_info->is_new_req = false;
cmd = mrq->cmd;
if (!cmd->error || !cmd->retries ||
@@ -534,7 +530,6 @@ static enum mmc_blk_status mmc_wait_for_data_req_done(struct mmc_host *host,
continue; /* wait for done/new event again */
}
} else if (context_info->is_new_req) {
- context_info->is_new_req = false;
if (!next_req)
return MMC_BLK_NEW_REQUEST;
}
@@ -3016,7 +3011,6 @@ void mmc_unregister_pm_notifier(struct mmc_host *host)
*/
void mmc_init_context_info(struct mmc_host *host)
{
- spin_lock_init(&host->context_info.lock);
host->context_info.is_new_req = false;
host->context_info.is_done_rcv = false;
host->context_info.is_waiting_last_req = false;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 2ce32fefb41c..8bc884121465 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -197,14 +197,12 @@ struct mmc_slot {
* @is_new_req wake up reason was new request
* @is_waiting_last_req mmc context waiting for single running request
* @wait wait queue
- * @lock lock to protect data fields
*/
struct mmc_context_info {
bool is_done_rcv;
bool is_new_req;
bool is_waiting_last_req;
wait_queue_head_t wait;
- spinlock_t lock;
};
struct regulator;
--
1.9.1
^ permalink raw reply related
* [PATCH V8 02/20] mmc: block: Fix 4K native sector check
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
The 4K native sector check does not allow for the 'do' loop nor the
variables used after the 'cmd_abort' label.
'brq' and 'req' get reassigned in the 'do' loop, so the check must not
assume what their values are. After the 'cmd_abort' label, 'mq_rq' and
'req' are used, but 'rqc' must be NULL otherwise it can be started again.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/mmc/card/block.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 19597e3cefcb..3e73be0e7281 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1597,11 +1597,11 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
{
struct mmc_blk_data *md = mq->blkdata;
struct mmc_card *card = md->queue.card;
- struct mmc_blk_request *brq = &mq->mqrq_cur->brq;
+ struct mmc_blk_request *brq;
int ret = 1, disable_multi = 0, retry = 0, type, retune_retry_done = 0;
enum mmc_blk_status status;
struct mmc_queue_req *mq_rq;
- struct request *req = rqc;
+ struct request *req;
struct mmc_async_req *areq;
if (!rqc && !mq->mqrq_prev->req)
@@ -1616,8 +1616,10 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
if (mmc_large_sector(card) &&
!IS_ALIGNED(blk_rq_sectors(rqc), 8)) {
pr_err("%s: Transfer size is not 4KB sector size aligned\n",
- req->rq_disk->disk_name);
+ rqc->rq_disk->disk_name);
mq_rq = mq->mqrq_cur;
+ req = rqc;
+ rqc = NULL;
goto cmd_abort;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V8 01/20] mmc: block: Restore line inadvertently removed with packed commands
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-1-git-send-email-adrian.hunter@intel.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
drivers/mmc/card/block.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 86ff28f84698..19597e3cefcb 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1587,6 +1587,8 @@ static int mmc_blk_cmd_err(struct mmc_blk_data *md, struct mmc_card *card,
if (blocks != (u32)-1) {
ret = blk_end_request(req, 0, blocks << 9);
}
+ } else {
+ ret = blk_end_request(req, 0, brq->data.bytes_xfered);
}
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V8 00/20] mmc: mmc: Add Software Command Queuing
From: Adrian Hunter @ 2016-11-29 10:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
Hi
Here is an updated version of the Software Command Queuing patches,
re-based on next, with some changes - refer changes in V8 below.
It would be good to move at least a few of these patches: for example,
patches 2-7 could be considered to be tidy-ups. Patch 1 could be
rolled into the Packed Commands removal patch.
Performance results (not updated since V5):
Results can vary from run to run, but here are some results showing 1, 2 or 4
processes with 4k and 32k record sizes. They show up to 40% improvement in
read performance when there are multiple processes.
iozone -s 8192k -r 4k -i 0 -i 1 -i 2 -i 8 -I -t 1 -F /mnt/mmc/iozone1.tmp
Children see throughput for 1 initial writers = 27909.87 kB/sec 24204.14 kB/sec -13.28 %
Children see throughput for 1 rewriters = 28839.28 kB/sec 25531.92 kB/sec -11.47 %
Children see throughput for 1 readers = 25889.65 kB/sec 24883.23 kB/sec -3.89 %
Children see throughput for 1 re-readers = 25558.23 kB/sec 24679.89 kB/sec -3.44 %
Children see throughput for 1 random readers = 25571.48 kB/sec 24689.52 kB/sec -3.45 %
Children see throughput for 1 mixed workload = 25758.59 kB/sec 24487.52 kB/sec -4.93 %
Children see throughput for 1 random writers = 24787.51 kB/sec 19368.99 kB/sec -21.86 %
iozone -s 8192k -r 32k -i 0 -i 1 -i 2 -i 8 -I -t 1 -F /mnt/mmc/iozone1.tmp
Children see throughput for 1 initial writers = 91344.61 kB/sec 102008.56 kB/sec 11.67 %
Children see throughput for 1 rewriters = 87932.36 kB/sec 96630.44 kB/sec 9.89 %
Children see throughput for 1 readers = 134879.82 kB/sec 110292.79 kB/sec -18.23 %
Children see throughput for 1 re-readers = 147632.13 kB/sec 109053.33 kB/sec -26.13 %
Children see throughput for 1 random readers = 93547.37 kB/sec 112225.50 kB/sec 19.97 %
Children see throughput for 1 mixed workload = 93560.04 kB/sec 110515.21 kB/sec 18.12 %
Children see throughput for 1 random writers = 92841.84 kB/sec 81153.81 kB/sec -12.59 %
iozone -s 8192k -r 4k -i 0 -i 1 -i 2 -i 8 -I -t 2 -F /mnt/mmc/iozone1.tmp /mnt/mmc/iozone2.tmp
Children see throughput for 2 initial writers = 31145.43 kB/sec 33771.25 kB/sec 8.43 %
Children see throughput for 2 rewriters = 30592.57 kB/sec 35916.46 kB/sec 17.40 %
Children see throughput for 2 readers = 31669.83 kB/sec 37460.13 kB/sec 18.28 %
Children see throughput for 2 re-readers = 32079.94 kB/sec 37373.33 kB/sec 16.50 %
Children see throughput for 2 random readers = 27731.19 kB/sec 37601.65 kB/sec 35.59 %
Children see throughput for 2 mixed workload = 13927.50 kB/sec 14617.06 kB/sec 4.95 %
Children see throughput for 2 random writers = 31250.00 kB/sec 33106.72 kB/sec 5.94 %
iozone -s 8192k -r 32k -i 0 -i 1 -i 2 -i 8 -I -t 2 -F /mnt/mmc/iozone1.tmp /mnt/mmc/iozone2.tmp
Children see throughput for 2 initial writers = 123255.84 kB/sec 131252.22 kB/sec 6.49 %
Children see throughput for 2 rewriters = 115234.91 kB/sec 107225.74 kB/sec -6.95 %
Children see throughput for 2 readers = 128921.86 kB/sec 148562.71 kB/sec 15.23 %
Children see throughput for 2 re-readers = 127815.24 kB/sec 149304.32 kB/sec 16.81 %
Children see throughput for 2 random readers = 125600.46 kB/sec 148406.56 kB/sec 18.16 %
Children see throughput for 2 mixed workload = 44006.94 kB/sec 50937.36 kB/sec 15.75 %
Children see throughput for 2 random writers = 120623.95 kB/sec 103969.05 kB/sec -13.81 %
iozone -s 8192k -r 4k -i 0 -i 1 -i 2 -i 8 -I -t 4 -F /mnt/mmc/iozone1.tmp /mnt/mmc/iozone2.tmp /mnt/mmc/iozone3.tmp /mnt/mmc/iozone4.tmp
Children see throughput for 4 initial writers = 24100.96 kB/sec 33336.58 kB/sec 38.32 %
Children see throughput for 4 rewriters = 31650.20 kB/sec 33091.53 kB/sec 4.55 %
Children see throughput for 4 readers = 33276.92 kB/sec 41799.89 kB/sec 25.61 %
Children see throughput for 4 re-readers = 31786.96 kB/sec 41501.74 kB/sec 30.56 %
Children see throughput for 4 random readers = 31991.65 kB/sec 40973.93 kB/sec 28.08 %
Children see throughput for 4 mixed workload = 15804.80 kB/sec 13581.32 kB/sec -14.07 %
Children see throughput for 4 random writers = 31231.42 kB/sec 34537.03 kB/sec 10.58 %
iozone -s 8192k -r 32k -i 0 -i 1 -i 2 -i 8 -I -t 4 -F /mnt/mmc/iozone1.tmp /mnt/mmc/iozone2.tmp /mnt/mmc/iozone3.tmp /mnt/mmc/iozone4.tmp
Children see throughput for 4 initial writers = 116567.42 kB/sec 119280.35 kB/sec 2.33 %
Children see throughput for 4 rewriters = 115010.96 kB/sec 120864.34 kB/sec 5.09 %
Children see throughput for 4 readers = 130700.29 kB/sec 177834.21 kB/sec 36.06 %
Children see throughput for 4 re-readers = 125392.58 kB/sec 175975.28 kB/sec 40.34 %
Children see throughput for 4 random readers = 132194.57 kB/sec 176630.46 kB/sec 33.61 %
Children see throughput for 4 mixed workload = 56464.98 kB/sec 54140.61 kB/sec -4.12 %
Children see throughput for 4 random writers = 109128.36 kB/sec 85359.80 kB/sec -21.78 %
The current block driver supports 2 requests on the go at a time. Patches
3 - 8 make preparations for an arbitrary sized queue. Patches 9 - 12
introduce Command Queue definitions and helpers. Patches 13 - 16
complete the job of making the block driver use a queue. Patches 17 - 20
finally add Software Command Queuing. Most of the Software Command Queuing
functionality is added in patch 19.
As noted below, the patches can also be found here:
http://git.infradead.org/users/ahunter/linux-sdhci.git/shortlog/refs/heads/swcmdq
which also includes a debug-only patch to help debug stuck queues:
mmc: block: Add debugfs state file for debugging stuck queues
Changes in V8:
Re-based on next, dropping references to Packed Commands.
mmc: block: Restore line inadvertently removed with packed commands
New patch
mmc: block: Fix 4K native sector check
Moved to be the 2nd patch
Added Reviewed-by: Linus Walleij
mmc: queue: Fix queue thread wake-up
Added Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: queue: Factor out mmc_queue_alloc_bounce_bufs()
Added Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: queue: Factor out mmc_queue_alloc_bounce_sgs()
Added Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: queue: Factor out mmc_queue_alloc_sgs()
Added Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: queue: Factor out mmc_queue_reqs_free_bufs()
Added Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: queue: Introduce queue depth
Drop chunk referring to mmc_packed_init().
Combined into new patch "mmc: queue: Introduce queue depth and use it to allocate and free"
mmc: queue: Use queue depth to allocate and free
Combined into new patch "mmc: queue: Introduce queue depth and use it to allocate and free"
mmc: queue: Allocate queue of size qdepth
Combined into new patch "mmc: queue: Introduce queue depth and use it to allocate and free"
mmc: queue: Introduce queue depth and use it to allocate and free
New patch from combining 3 patches above.
mmc: mmc: Add Command Queue definitions
Add comment about excluding qdepths of 1 or 2.
mmc: mmc: Add functions to enable / disable the Command Queue
Change mmc_cmdq_switch() 'enable' parameter from 'int' to 'bool'.
mmc: mmc_test: Disable Command Queue while mmc_test is used
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: block: Disable Command Queue while RPMB is used
As per Ritesh, assign 'ret' to 0 and return 'ret'.
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: core: Do not prepare a new request twice
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: core: Export mmc_retune_hold() and mmc_retune_release()
Added Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
mmc: block: Factor out mmc_blk_requeue()
Dropped because it only affected "packed commands" code.
mmc: block: Use local var for mqrq_cur
Dropped chucks referring to Packed Commands.
Added Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
mmc: block: Pass mqrq to mmc_blk_prep_packed_list()
Dropped because it only affected "packed commands" code.
mmc: block: Introduce queue semantics
Add mmc_blk_requeue() lost from dropped patches.
mmc: queue: Share mmc request array between partitions
Dropped chucks referring to Packed Commands.
Change mqrq_ref_cnt from 'int' to 'unsigned int'
Add a comment about synchronisation of mqrq_ref_cnt.
mmc: mmc: Enable Software Command Queuing
Get rid of MMC_CAP_SWCMDQ and use MMC_CAP_CMD_DURING_TFR instead
mmc: sdhci-pci: Enable Software Command Queuing for some Intel controllers
Dropped because MMC_CAP_SWCMDQ removed.
mmc: sdhci-acpi: Enable Software Command Queuing for some Intel controllers
Dropped because MMC_CAP_SWCMDQ removed.
Changes in V7:
Re-based on next.
mmc: mmc: Add Command Queue definitions
Remove cmdq_en flag and add Linus Walleij's Reviewed-by.
mmc: mmc: Add functions to enable / disable the Command
Add cmdq_en flag.
Changes in V6:
mmc: core: Do not prepare a new request twice
Ensure struct mmc_async_req is always initialized to zero
Changes in V5:
Patches 1-5 dropped because they have been applied.
Re-based on next.
Fixed use of blk_end_request_cur() when it should have been
blk_end_request_all() to error out requests during error recovery.
Fixed unpaired retune_hold / retune_release in the error recovery path.
Changes in V4:
Re-based on next + v4.8-rc2 + "block: Fix secure erase" patch
Changes in V3:
Patches 1-25 dropped because they have been applied.
Re-based on next.
mmc: queue: Allocate queue of size qdepth
Free queue during cleanup
mmc: mmc: Add Command Queue definitions
Add cmdq_en to mmc-dev-attrs.txt documentation
mmc: queue: Share mmc request array between partitions
New patch
Changes in V2:
Added 5 patches already sent here:
http://marc.info/?l=linux-mmc&m=146712062816835
Added 3 more new patches:
mmc: sdhci-pci: Do not runtime suspend at the end of sdhci_pci_probe()
mmc: sdhci: Avoid STOP cmd triggering warning in sdhci_send_command()
mmc: sdhci: sdhci_execute_tuning() must delete timer
Carried forward the V2 fix to:
mmc: mmc_test: Disable Command Queue while mmc_test is used
Also reset the cmd circuit for data timeout if it is processing the data
cmd, in patch:
mmc: sdhci: Do not reset cmd or data circuits that are in use
There wasn't much comment on the RFC so there have been few changes.
Venu Byravarasu commented that it may be more efficient to use Software
Command Queuing only when there is more than 1 request queued - it isn't
obvious how well that would work in practice, but it could be added later
if it could be shown to be beneficial.
Original Cover Letter:
Chuanxiao Dong sent some patches last year relating to eMMC 5.1 Software
Command Queuing. He did not follow-up but I have contacted him and he says
it is OK if I take over upstreaming the patches.
eMMC Command Queuing is a feature added in version 5.1. The card maintains
a queue of up to 32 data transfers. Commands CMD45/CMD45 are sent to queue
up transfers in advance, and then one of the transfers is selected to
"execute" by CMD46/CMD47 at which point data transfer actually begins.
The advantage of command queuing is that the card can prepare for transfers
in advance. That makes a big difference in the case of random reads because
the card can start reading into its cache in advance.
A v5.1 host controller can manage the command queue itself, but it is also
possible for software to manage the queue using an non-v5.1 host controller
- that is what Software Command Queuing is.
Refer to the JEDEC (http://www.jedec.org/) eMMC v5.1 Specification for more
information about Command Queuing.
While these patches are heavily based on Dong's patches, there are some
changes:
SDHCI has been amended to support commands during transfer. That is a
generic change added in patches 1 - 5. [Those patches have now been applied]
In principle, that would also support SDIO's CMD52 during data transfer.
The original approach added multiple commands into the same request for
sending CMD44, CMD45 and CMD13. That is not strictly necessary and has
been omitted for now.
The original approach also called blk_end_request() from the mrq->done()
function, which means the upper layers learnt of completed requests
slightly earlier. That is not strictly related to Software Command Queuing
and is something that could potentially be done for all data requests.
That has been omitted for now.
The current block driver supports 2 requests on the go at a time. Patches
1 - 8 make preparations for an arbitrary sized queue. Patches 9 - 12
introduce Command Queue definitions and helpers. Patches 13 - 19
complete the job of making the block driver use a queue. Patches 20 - 23
finally add Software Command Queuing, and 24 - 25 enable it for Intel eMMC
controllers. Most of the Software Command Queuing functionality is added
in patch 22.
The patches can also be found here:
http://git.infradead.org/users/ahunter/linux-sdhci.git/shortlog/refs/heads/swcmdq
The patches have only had basic testing so far. Ad-hoc testing shows a
degradation in sequential read performance of about 10% but an increase in
throughput for mixed workload of multiple processes of about 90%. The
reduction in sequential performance is due to the need to read the Queue
Status register between each transfer.
These patches should not conflict with Hardware Command Queuing which
handles the queue in a completely different way and thus does not need
to share code with Software Command Queuing. The exceptions being the
Command Queue definitions and queue allocation which should be able to be
used.
Adrian Hunter (20):
mmc: block: Restore line inadvertently removed with packed commands
mmc: block: Fix 4K native sector check
mmc: queue: Fix queue thread wake-up
mmc: queue: Factor out mmc_queue_alloc_bounce_bufs()
mmc: queue: Factor out mmc_queue_alloc_bounce_sgs()
mmc: queue: Factor out mmc_queue_alloc_sgs()
mmc: queue: Factor out mmc_queue_reqs_free_bufs()
mmc: queue: Introduce queue depth and use it to allocate and free
mmc: mmc: Add Command Queue definitions
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: core: Do not prepare a new request twice
mmc: core: Export mmc_retune_hold() and mmc_retune_release()
mmc: block: Use local var for mqrq_cur
mmc: block: Introduce queue semantics
mmc: queue: Share mmc request array between partitions
mmc: queue: Add a function to control wake-up on new requests
mmc: block: Add Software Command Queuing
mmc: mmc: Enable Software Command Queuing
Documentation/mmc/mmc-dev-attrs.txt | 1 +
drivers/mmc/card/block.c | 712 +++++++++++++++++++++++++++++++++---
drivers/mmc/card/mmc_test.c | 21 +-
drivers/mmc/card/queue.c | 328 +++++++++++------
drivers/mmc/card/queue.h | 27 +-
drivers/mmc/core/core.c | 18 +-
drivers/mmc/core/host.c | 2 +
drivers/mmc/core/host.h | 2 -
drivers/mmc/core/mmc.c | 44 ++-
drivers/mmc/core/mmc_ops.c | 28 ++
include/linux/mmc/card.h | 8 +
include/linux/mmc/core.h | 6 +
include/linux/mmc/host.h | 3 +-
include/linux/mmc/mmc.h | 17 +
14 files changed, 1035 insertions(+), 182 deletions(-)
Regards
Adrian
^ permalink raw reply
* Re: mmc: tmio: why enable/disable SDIO irq on every transaction with IOMOD?
From: Ulf Hansson @ 2016-11-29 8:52 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: linux-mmc@vger.kernel.org, Wolfram Sang, Simon Horman
In-Reply-To: <87h96qkdn0.wl@dns1.atmark-techno.com>
+Wolfram, Simon
Looping maintainers of TMIO/SDHI.
On 29 November 2016 at 07:23, Yasushi SHOJI <yashi@atmark-techno.com> wrote:
> Hello,
>
> We've been using tmio_mmc_pio.c and seeing the following message:
>
> "sh_mobile_sdhi sh_mobile_sdhi.1: timeout waiting for SD bus idle"
>
> While searching for a fix, we found some code we don't understand.
> I'm sending this question with a hope that someone would enlighten us a
> bit. So, here goes.
>
> The SDIO spec. seems to allow sending SDIO IRQ between the blocks of
> multi-block transfer. The hardware, SCLKDIVEN bit of SD_INFO02, is
> set to zero (0) and prohibits to access IOMOD bit of SDIO_MODE
> register while multi-block transfer is going.
>
> The current code, however, tries to disable SDIO IRQ by setting IOMOD
> to zero in tmio_mmc_enable_sdio_irq() all the time, even during
> multi-block transfer. This prints the above waring. What we don't
> understand is that the code does both masking and disabling the IRQ.
>
> So my question is that "What is the reason behind to disable IRQ with
> SDIO_MODE? Is there any situation which masking with SDIO_INFO1_MASK
> is not enough?
>
> Thanks you,
> --
> yashi
> --
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ulf Hansson @ 2016-11-29 7:49 UTC (permalink / raw)
To: Ziji Hu
Cc: Gregory CLEMENT, Adrian Hunter,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jimmy Xu, Jisheng Zhang, Nadav Haklai, Ryan Gao, Doug Jones,
Victor Gu, Wei(SOCP) Liu, Wilson Ding
In-Reply-To: <c30cead8-17b6-48b0-7355-cd82268842e1-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
On 29 November 2016 at 03:53, Ziji Hu <huziji-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi Ulf,
>
> On 2016/11/28 23:16, Ulf Hansson wrote:
>> On 28 November 2016 at 12:38, Ziji Hu <huziji-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org> wrote:
>>> Hi Ulf,
>>>
>>> On 2016/11/28 19:13, Ulf Hansson wrote:
>>>>>
>>>>> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
>>>>> send commands for testing current sampling point set in our host PHY.
>>>>>
>>>>> According to my test result, it shows that mmc_send_tuning() can only support
>>>>> tuning command (CMD21/CMD19).
>>>>> As a result, we cannot use mmc_send_tuning() when card is in the speed modes
>>>>> which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
>>>>> SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
>>>>> speed modes.
>>>>>
>>>>> Could you please provide suggestions for the speed mode in which tuning is
>>>>> not available?
>>>>>
>>>>
>>>> Normally the mmc host driver shouldn't have to care about what the
>>>> card supports, as that is the responsibility of the mmc core to
>>>> manage.
>>>>
>>>> The host should only need to implement the ->execute_tuning() ops,
>>>> which gets called when the card supports tuning (CMD19/21). Does it
>>>> make sense?
>>>>
>>> I think it is irrelevant to tuning procedure.
>>>
>>> Our host requires to adjust PHY setting after each time ios setting
>>> (SDCLK/bus width/speed mode) is changed.
>>> The simplified sequence is:
>>> mmc change ios --> mmc_set_ios() --> ->set_ios() --> after sdhci_set_ios(),
>>> adjust PHY setting.
>>> During PHY setting adjustment, out host driver has to send commands to
>>> test current sampling point. Tuning is another independent step.
>>
>> For those speed modes (or other ios changes) that *don't* requires
>> tuning, then what will you do when you send the command to confirm the
>> change of PHY setting and it fails?
>>
>> My assumption is that you will fail anyway, by propagating the error
>> to the mmc core. At least that what was my understanding from your
>> earlier replies, right!?
>>
>> Then, I think there are no point having the host driver sending a
>> command to confirm the PHY settings, as the mmc core will anyway
>> discover if something goes wrong when the next command is sent.
>>
>> Please correct me if I am wrong!
>>
>
> Sorry that I didn't make myself clear.
>
> Our host PHY delay line consists of hundreds of sampling points.
> Each sampling point represents a different phase shift.
>
> In lower speed mode, our host driver will scan the delay line.
> It will select and test multiple sampling points, other than testing
> only single sampling point.
>
> If a sampling point fails to transfer cmd/data, our host driver will
> move to test next sampling point, until we find out a group of successful
> sampling points which can transfer cmd/data. At last we will select
> a perfect one from them.
Ahh, I see. Unfortunate, this is going to be very hard to implement properly.
The main problem is that the host driver has *no* knowledge about the
internal state of the card, as that is the responsibility of the mmc
core to keep track of.
If the host driver would send a command during every update of the
"ios" setting, from ->set_ios(), for sure it would lead to commands
being sent that are "forbidden" in the current internal state of the
card.
This would lead to that the card initialization sequence fails,
because the card may move to an unknown internal state and the mmc
core would have no knowledge about what happened.
Hmm..
Can you specify, *exactly*, under which "ios updates" you need to
verify updated PHY setting changes by sending a cmd/data? Also, please
specify if it's enough to only test the CMD line or also DATA lines.
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: arasan,sdhci.txt "compatibility" DT binding
From: Rameshwar Sahu @ 2016-11-29 7:29 UTC (permalink / raw)
To: Mason
Cc: Arnd Bergmann, linux-mmc, Shawn Lin, Adrian Hunter, Michal Simek,
Linux ARM, Soren Brinkmann, Michal Simek, Anton Vorontsov,
Xiaobo Xie, Suman Tripathi, Linus Walleij, Maxime Ripard,
Rob Herring, Zach Brown, Ulf Hansson, Douglas Anderson,
Heiko Stuebner, Jisheng Zhang, Suneel Garapati <sunee>
In-Reply-To: <583C60CC.2020408@free.fr>
Hi Mason,
Nowhere in the documentation do they specify an "IP version".
Some documents do provide a revision number, but that's just
a *documentation* revision number, e.g.
changes in version 3.6 : fix typos
changes in version 9.1a : update company logo
That's why Xilinx used "arasan,sdhci-8.9a" and APM used
"arasan,sdhci-4.9a". These are documentation revisions.
In my opinion, that information is mostly worthless.
Arasan SD/SDIO/eMMC IP has a register which tells about the SD
specification version and Vendor version number
Reg Name: Host controller version register (offset 0FEh)
bit [15:8] is for vendor version number,
But, I have seen that Arasaan vendor version number is same as
document revision number.
On Mon, Nov 28, 2016 at 10:22 PM, Mason <slash.tmp@free.fr> wrote:
> On 28/11/2016 17:15, Arnd Bergmann wrote:
>
>> On Monday, November 28, 2016 4:44:39 PM CET Mason wrote:
>>
>>> Hello,
>>>
>>> @Shawn Lin, could you take a look below and tell me exactly
>>> which IP core(s) Rockchip is using in its SoCs?
>>>
>>> Based on the feedback I received, here is an updated list of
>>> compatible strings and controller versions dealt with by the
>>> drivers/mmc/host/sdhci-of-arasan.c code.
>>>
>>>
>>> Xilinx Zynq:
>>> "SD2.0 / SDIO2.0 / MMC3.31 AHB Host Controller"
>>> "arasan,sdhci-8.9a"
>>> NB: 8.9a is the documentation revision (dated 2011-10-19)
>>> subsequent tweaks labeled 9.0a, 9.1a, 9.2a
>>>
>>> Xilinx ZynqMP:
>>> "SD3.0 / SDIO3.0 / eMMC4.51 AHB Host Controller"
>>> "arasan,sdhci-8.9a"
>>> NB: using the same compatible string as Zynq
>>>
>>> Sigma SMP87xx
>>> "SD3.0 / SDIO3.0 / eMMC4.4 AHB Host Controller"
>>> no compatible string yet, platform-specific init required
>>>
>>> APM:
>>> "SD3.0 / SDIO3.0 / eMMC4.41 AHB Host Controller"
>>> "arasan,sdhci-4.9a"
>>> NB: 4.9a appears to be the documentation revision
>>> no functional diff with "arasan,sdhci-8.9a"
>>>
>>> Rockchip
>>> Exact IP unknown, waiting for Shawn's answer
>>> "arasan,sdhci-5.1"
>>> NB: 5.1 appears to refer to the eMMC standard supported
>>>
>>>
>>> On a final note, there are many variations of the Arasan IP.
>>> I've tracked down at least the following:
>>>
>>> SD_2.0_SDIO_2.0__MMC_3.31_AHB_Host_Controller.pdf
>>> SD_3.0_SDIO_3.0_eMMC_4.41_OCP_Host_Controller.pdf
>>> SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf
>>> SD_3.0_SDIO_3.0_eMMC_4.51_Host_Controller.pdf
>>> SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller.pdf
>>> SD_4.1_SDIO_4.1_eMMC_4.51_Host_Controller.pdf
>>> SD_4.1_SDIO_4.1_eMMC_5.1__Host_Controller.pdf
>>>
>>> It seems to me the compatible string should specify
>>> the SD/SDIO version AND the eMMC version, since it
>>> seems many combinations are allowed, e.g. eMMC 4.51
>>> has two possible SD versions.
>>>
>>> What do you think?
>>
>> It seems wrong to have the eMMC or SD version in the compatible
>> string. Is that the only difference between the documents you
>> found? Normally there should be a version of IP block itself,
>> besides the supported protocol.
>
> But that is exactly the problem :-)
>
> Nowhere in the documentation do they specify an "IP version".
> Some documents do provide a revision number, but that's just
> a *documentation* revision number, e.g.
>
> changes in version 3.6 : fix typos
> changes in version 9.1a : update company logo
>
> That's why Xilinx used "arasan,sdhci-8.9a" and APM used
> "arasan,sdhci-4.9a". These are documentation revisions.
> In my opinion, that information is mostly worthless.
>
>
> Looking more closely at SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf
> (User Guide, which has more info than Datasheet) I see this:
>
> Changed Host Controller Version Register value from 16'h0002 to 16'h7501
> Changed Host Controller Version Register value from 16'h8301 to 16'h8401
> Changed Host Controller Version Register value from 16'h8401 to 16'h8501
> Changed Host Controller Version Register to 16'h9502
> Changed Host Controller Version Register to 16'h9602
> Changed Host Controller Version Register to 16'h9902
>
> Host controller version register (offset 0FEh)
>
> Vendor Version Number 15:8
> HwInit=0x99
> This status is reserved for the vendor version number.
> The HD should not use this status.
>
> Specification Version Number 7:0
> HwInit=0x02
> This status indicates the Host Controller Spec. Version.
> The upper and lower 4-bits indicate the version.
> Description
> 00 - SD Host Specification version 1.0
> 01 - SD Host Specification version 2.00
> including only the feature of the Test Register
> 02 - SD Host Specification Version 3.00
> others - Reserved
>
> I'm not sure what this "Vendor Version Number" specifies, nor if is
> guaranteed to be unique across controllers.
>
> In SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller_UserGuide.pdf,
> they write "The Vendor Version Number is set to 0x10 (1.0)"
>
> I don't have a UserGuide for "arasan,sdhci-5.1".
>
> Regards.
>
^ permalink raw reply
* mmc: tmio: why enable/disable SDIO irq on every transaction with IOMOD?
From: Yasushi SHOJI @ 2016-11-29 6:23 UTC (permalink / raw)
To: linux-mmc
Hello,
We've been using tmio_mmc_pio.c and seeing the following message:
"sh_mobile_sdhi sh_mobile_sdhi.1: timeout waiting for SD bus idle"
While searching for a fix, we found some code we don't understand.
I'm sending this question with a hope that someone would enlighten us a
bit. So, here goes.
The SDIO spec. seems to allow sending SDIO IRQ between the blocks of
multi-block transfer. The hardware, SCLKDIVEN bit of SD_INFO02, is
set to zero (0) and prohibits to access IOMOD bit of SDIO_MODE
register while multi-block transfer is going.
The current code, however, tries to disable SDIO IRQ by setting IOMOD
to zero in tmio_mmc_enable_sdio_irq() all the time, even during
multi-block transfer. This prints the above waring. What we don't
understand is that the code does both masking and disabling the IRQ.
So my question is that "What is the reason behind to disable IRQ with
SDIO_MODE? Is there any situation which masking with SDIO_INFO1_MASK
is not enough?
Thanks you,
--
yashi
^ permalink raw reply
* Re: [PATCH v2] mmc: sdhci-msm: Add sdhci_reset() implementation
From: Ritesh Harjani @ 2016-11-29 3:40 UTC (permalink / raw)
To: Georgi Djakov
Cc: adrian.hunter, ulf.hansson, linux-mmc, linux-kernel,
linux-arm-msm
In-Reply-To: <20161128173920.25334-1-georgi.djakov@linaro.org>
Hi Georgi,
On 11/28/2016 11:09 PM, Georgi Djakov wrote:
> On apq8016, apq8084 and apq8074 platforms, writing to the software
> reset register triggers the "power irq". We need to ack and handle
> the irq, otherwise the following message appears:
>
> mmc0: Reset 0x1 never completed.
> sdhci: =========== REGISTER DUMP (mmc0)===========
> sdhci: Sys addr: 0x00000000 | Version: 0x00002e02
> sdhci: Blk size: 0x00004000 | Blk cnt: 0x00000000
> sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
> sdhci: Present: 0x01f80000 | Host ctl: 0x00000000
> sdhci: Power: 0x00000000 | Blk gap: 0x00000000
> sdhci: Wake-up: 0x00000000 | Clock: 0x00000003
> sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
> sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000
> sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
> sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007
> sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
> sdhci: Host ctl2: 0x00000000
> sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000
> sdhci: ===========================================
>
> Fix it by implementing the custom sdhci_reset() function,
> which performs the software reset and then handles the irq.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>
> Changes since v1: (https://lkml.org/lkml/2016/11/22/411)
> * Perform the software reset by just writing to the SDHCI_SOFTWARE_RESET
> register and then check for the irq.
I am still not sure about this change. Below change will trigger the
IRQ, once this call is completed (say on a single core system) -since
this is called while holding spin_lock_irqsave.
But you will be end up calling sdhci_msm_voltage_switch twice,
which to me does not seems correct.
1. 1st time you are directly calling it in sdhci_msm_reset.
2. 2nd time will be called from within pwr_irq to handle the same case.
Please let me know your thoughts on this ?
Regards
Ritesh
>
> drivers/mmc/host/sdhci-msm.c | 29 ++++++++++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 32879b845b75..157ae07f9309 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -1019,6 +1019,33 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> __sdhci_msm_set_clock(host, clock);
> }
>
> +void sdhci_msm_reset(struct sdhci_host *host, u8 mask)
> +{
> + unsigned long timeout = 100;
> +
> + sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
> +
> + if (mask & SDHCI_RESET_ALL) {
> + host->clock = 0;
> +
> + /*
> + * SDHCI_RESET_ALL triggers the PWR IRQ and we need
> + * to handle it here.
> + */
> + sdhci_msm_voltage_switch(host);
> + }
> +
> + while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) {
> + if (timeout == 0) {
> + pr_err("%s: Reset 0x%x never completed.\n",
> + mmc_hostname(host->mmc), (int)mask);
> + return;
> + }
> + timeout--;
> + mdelay(1);
> + }
> +}
> +
> static const struct of_device_id sdhci_msm_dt_match[] = {
> { .compatible = "qcom,sdhci-msm-v4" },
> {},
> @@ -1028,7 +1055,7 @@ MODULE_DEVICE_TABLE(of, sdhci_msm_dt_match);
>
> static const struct sdhci_ops sdhci_msm_ops = {
> .platform_execute_tuning = sdhci_msm_execute_tuning,
> - .reset = sdhci_reset,
> + .reset = sdhci_msm_reset,
> .set_clock = sdhci_msm_set_clock,
> .get_min_clock = sdhci_msm_get_min_clock,
> .get_max_clock = sdhci_msm_get_max_clock,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ziji Hu @ 2016-11-29 2:53 UTC (permalink / raw)
To: Ulf Hansson
Cc: Gregory CLEMENT, Adrian Hunter, linux-mmc@vger.kernel.org,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree@vger.kernel.org, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Jimmy Xu, Jisheng Zhang,
Nadav Haklai, Ryan Gao, Doug Jones, Victor Gu, Wei(SOCP) Liu,
Wilson Ding
In-Reply-To: <CAPDyKFr8rX04iY92OeQpSkS+3HN2-FxijCCiDb2sSKvP+TZPog@mail.gmail.com>
Hi Ulf,
On 2016/11/28 23:16, Ulf Hansson wrote:
> On 28 November 2016 at 12:38, Ziji Hu <huziji@marvell.com> wrote:
>> Hi Ulf,
>>
>> On 2016/11/28 19:13, Ulf Hansson wrote:
>>>>
>>>> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
>>>> send commands for testing current sampling point set in our host PHY.
>>>>
>>>> According to my test result, it shows that mmc_send_tuning() can only support
>>>> tuning command (CMD21/CMD19).
>>>> As a result, we cannot use mmc_send_tuning() when card is in the speed modes
>>>> which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
>>>> SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
>>>> speed modes.
>>>>
>>>> Could you please provide suggestions for the speed mode in which tuning is
>>>> not available?
>>>>
>>>
>>> Normally the mmc host driver shouldn't have to care about what the
>>> card supports, as that is the responsibility of the mmc core to
>>> manage.
>>>
>>> The host should only need to implement the ->execute_tuning() ops,
>>> which gets called when the card supports tuning (CMD19/21). Does it
>>> make sense?
>>>
>> I think it is irrelevant to tuning procedure.
>>
>> Our host requires to adjust PHY setting after each time ios setting
>> (SDCLK/bus width/speed mode) is changed.
>> The simplified sequence is:
>> mmc change ios --> mmc_set_ios() --> ->set_ios() --> after sdhci_set_ios(),
>> adjust PHY setting.
>> During PHY setting adjustment, out host driver has to send commands to
>> test current sampling point. Tuning is another independent step.
>
> For those speed modes (or other ios changes) that *don't* requires
> tuning, then what will you do when you send the command to confirm the
> change of PHY setting and it fails?
>
> My assumption is that you will fail anyway, by propagating the error
> to the mmc core. At least that what was my understanding from your
> earlier replies, right!?
>
> Then, I think there are no point having the host driver sending a
> command to confirm the PHY settings, as the mmc core will anyway
> discover if something goes wrong when the next command is sent.
>
> Please correct me if I am wrong!
>
Sorry that I didn't make myself clear.
Our host PHY delay line consists of hundreds of sampling points.
Each sampling point represents a different phase shift.
In lower speed mode, our host driver will scan the delay line.
It will select and test multiple sampling points, other than testing
only single sampling point.
If a sampling point fails to transfer cmd/data, our host driver will
move to test next sampling point, until we find out a group of successful
sampling points which can transfer cmd/data. At last we will select
a perfect one from them.
Thank you.
Best regards,
Hu Ziji
>>
>> Thus our host needs a valid command in PHY setting adjustment. Tuning command
>> can be borrowed to complete this task in SD SDR50. But for other speed mode,
>> we have to find out a valid command.
>
> I thought we agreed on this wasn't necessary? Please see my upper response.
>
> Kind regards
> Uffe
>
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: Enable SDHCI for Nexus 5X (msm8992)
From: Rob Herring @ 2016-11-28 21:53 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
riteshh-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1479863388-23678-4-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Nov 22, 2016 at 05:09:46PM -0800, Jeremy McNicoll wrote:
> Add Nexus 5X (msm8992) SDHCI support, including initial regulator
> entries to support enabling the main SDHCI/MMC.
>
> The msm8994 RPM regulator talks over SMD to the APPS processor.
>
> Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> .../bindings/regulator/qcom,smd-rpm-regulator.txt | 40 ++++
> .../boot/dts/qcom/msm8992-bullhead-rev-101.dts | 262 +++++++++++++++++++++
> arch/arm64/boot/dts/qcom/msm8992-pins.dtsi | 82 +++++++
> arch/arm64/boot/dts/qcom/msm8992.dtsi | 153 ++++++++++++
> drivers/regulator/qcom_smd-regulator.c | 49 ++++
> 5 files changed, 586 insertions(+)
A few nits, otherwise,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> index 1f8d6f8..126989b 100644
> --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> @@ -23,6 +23,7 @@ Regulator nodes are identified by their compatible:
> "qcom,rpm-pm8916-regulators"
> "qcom,rpm-pm8941-regulators"
> "qcom,rpm-pma8084-regulators"
> + "qcom,rpm-pm8994-regulators"
>
> - vdd_s1-supply:
> - vdd_s2-supply:
> @@ -97,6 +98,40 @@ Regulator nodes are identified by their compatible:
> Definition: reference to regulator supplying the input pin, as
> described in the data sheet
>
> +- vdd_s1-supply:
> +- vdd_s2-supply:
> +- vdd_s3-supply:
> +- vdd_s4-supply:
> +- vdd_s5-supply:
> +- vdd_s6-supply:
> +- vdd_s7-supply:
> +- vdd_l1_l11-supply:
> +- vdd_l2_l3_l4_l27-supply:
> +- vdd_l5_l7-supply:
> +- vdd_l6_l12_l14_l15_l26-supply:
> +- vdd_l8-supply:
> +- vdd_l9_l10_l13_l20_l23_l24-supply:
> +- vdd_l1_l11-supply:
> +- vdd_l6_l12_l14_l15_l26-supply:
> +- vdd_l16_l25-supply:
> +- vdd_l17-supply:
> +- vdd_l18-supply:
> +- vdd_l19-supply:
> +- vdd_l21-supply:
> +- vdd_l22-supply:
> +- vdd_l16_l25-supply:
> +- vdd_l27-supply:
> +- vdd_l28-supply:
> +- vdd_l29-supply:
> +- vdd_l30-supply:
> +- vdd_l31-supply:
> +- vdd_l32-supply:
> + Usage: optional (pm8994 only)
> + Value type: <phandle>
> + Definition: reference to regulator supplying the input pin, as
> + described in the data sheet.
> +
> +
> The regulator node houses sub-nodes for each regulator within the device. Each
> sub-node is identified using the node's name, with valid values listed for each
> of the pmics below.
> @@ -118,6 +153,11 @@ pma8084:
> l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
> l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1
>
> +pm8994:
> + s1, s2, s3, s4, s5, s6, s7, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
> + l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26,
> + l27, l28, l29, l30, l31, l32, lvs1, lvs2
> +
> The content of each sub-node is defined by the standard binding for regulators -
> see regulator.txt.
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> index 4542133..2ce8798 100644
> --- a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> +++ b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> @@ -39,3 +39,265 @@
> };
> };
> };
> +
> +&smd_rpm {
> + rpm {
> + rpm_requests {
> + pm8994-regulators {
> +
> + vdd_l1-supply = <&pm8994_s1>;
> + vdd_l2_26_28-supply = <&pm8994_s3>;
> + vdd_l3_11-supply = <&pm8994_s3>;
> + vdd_l4_27_31-supply = <&pm8994_s3>;
> + vdd_l5_7-supply = <&pm8994_s3>;
> + vdd_l6_12_32-supply = <&pm8994_s5>;
> + vdd_l8_16_30-supply = <&vreg_vph_pwr>;
> + vdd_l9_10_18_22-supply = <&vreg_vph_pwr>;
> + vdd_l13_19_23_24-supply = <&vreg_vph_pwr>;
> + vdd_l14_15-supply = <&pm8994_s5>;
> + vdd_l17_29-supply = <&vreg_vph_pwr>;
> + vdd_l20_21-supply = <&vreg_vph_pwr>;
> + vdd_l25-supply = <&pm8994_s5>;
> + /*vin_lvs1_2 = <&pm8994_s4>; */
> +
> + s1 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <800000>;
> + };
> +
> + s2 {
> + };
> +
> + s3 {
> + regulator-min-microvolt = <1300000>;
> + regulator-max-microvolt = <1300000>;
> + };
> +
> + s4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-allow-set-load;
> + regulator-system-load = <325000>;
> + };
> +
> + s5 {
> + regulator-min-microvolt = <2150000>;
> + regulator-max-microvolt = <2150000>;
> + };
> +
> + s7 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> +
> + l1 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> +
> + l2 {
> + regulator-min-microvolt = <1250000>;
> + regulator-max-microvolt = <1250000>;
> + };
> +
> + l3 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + };
> +
> + l4 {
> + regulator-min-microvolt = <1225000>;
> + regulator-max-microvolt = <1225000>;
> + };
> +
> + l5 {
> + };
> +
> + l6 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + l7 {
> + };
> +
> + l8 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + l9 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + l10 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + qcom,init-voltage = <1800000>;
> + };
> +
> + l11 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + qcom,init-voltage = <1200000>;
> + };
> +
> + l12 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + qcom,init-voltage = <1800000>;
> + proxy-supply = <&pm8994_l12>;
> + qcom,proxy-consumer-enable;
> + qcom,proxy-consumer-current = <10000>;
> + status = "okay";
> + };
> +
> + l13 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2950000>;
> + qcom,init-voltage = <2950000>;
> + status = "okay";
> + };
> +
> + l14 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + qcom,init-voltage = <1200000>;
> + proxy-supply = <&pm8994_l14>;
> + qcom,proxy-consumer-enable;
> + qcom,proxy-consumer-current = <10000>;
> + status = "okay";
> + };
> +
> + l15 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + qcom,init-voltage = <1800000>;
> + status = "okay";
> + };
> +
> + l16 {
> + regulator-min-microvolt = <2700000>;
> + regulator-max-microvolt = <2700000>;
> + qcom,init-voltage = <2700000>;
> + status = "okay";
> + };
> +
> + l17 {
> + regulator-min-microvolt = <2700000>;
> + regulator-max-microvolt = <2700000>;
> + qcom,init-voltage = <2700000>;
> + status = "okay";
> + };
> +
> + l18 {
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-always-on;
> + qcom,init-voltage = <3000000>;
> + qcom,init-ldo-mode = <1>;
> + };
> +
> + l19 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + qcom,init-voltage = <1800000>;
> + status = "okay";
> + };
> +
> + l20 {
> + regulator-min-microvolt = <2950000>;
> + regulator-max-microvolt = <2950000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-allow-set-load;
> + regulator-system-load = <570000>;
> + };
> +
> + l21 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + qcom,init-voltage = <1800000>;
> + };
> +
> + l22 {
> + regulator-min-microvolt = <3100000>;
> + regulator-max-microvolt = <3100000>;
> + qcom,init-voltage = <3100000>;
> + };
> +
> + l23 {
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + qcom,init-voltage = <2800000>;
> + };
> +
> + l24 {
> + regulator-min-microvolt = <3075000>;
> + regulator-max-microvolt = <3150000>;
> + qcom,init-voltage = <3075000>;
> + };
> +
> + l25 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + qcom,init-voltage = <1800000>;
> + };
> +
> + l26 {
> + /* TODO: value from downstream
> + regulator-min-microvolt = <987500>;
> + fails to apply */
> + };
> +
> + l27 {
> + regulator-min-microvolt = <1050000>;
> + regulator-max-microvolt = <1050000>;
> + qcom,init-voltage = <1050000>;
> + };
> +
> + l28 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + qcom,init-voltage = <1000000>;
> + proxy-supply = <&pm8994_l28>;
> + qcom,proxy-consumer-enable;
> + qcom,proxy-consumer-current = <10000>;
> + };
> +
> + l29 {
> + /* TODO: Unsupported voltage range..
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + qcom,init-voltage = <2800000>;
> + */
> + };
> +
> + l30 {
> + /* TODO: get this verified
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + qcom,init-voltage = <1800000>;
> + */
> + };
> +
> + l31 {
> + regulator-min-microvolt = <1262500>;
> + regulator-max-microvolt = <1262500>;
> + qcom,init-voltage = <1262500>;
> + };
> +
> + l32 {
> + /* TODO: get this verified
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + qcom,init-voltage = <1800000>;
> + */
> + };
> +
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> index d2a26f0..15202c8 100644
> --- a/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> @@ -35,4 +35,86 @@
> bias-pull-down;
> };
> };
> +
> + /* 0-3 for sdc1 4-6 for sdc2 */
> + /* Order of pins */
> + /* SDC1: CLK -> 0, CMD -> 1, DATA -> 2, RCLK -> 3 */
> + /* SDC2: CLK -> 4, CMD -> 5, DATA -> 6 */
> + pmx_sdc1_clk {
> + sdc1_clk_on: clk_on {
Use '-' rather than '_' for node names. (Labels don't matter)
> + pinmux {
> + pins = "sdc1_clk";
> + };
> + pinconf {
> + pins = "sdc1_clk";
> + bias-disable = <0>; /* No pull */
> + drive-strength = <16>; /* 16mA */
> + };
> + };
> + sdc1_clk_off: clk_off {
> + pinmux {
> + pins = "sdc1_clk";
> + };
> + pinconf {
> + pins = "sdc1_clk";
> + bias-disable = <0>; /* No pull */
> + drive-strength = <2>; /* 2mA */
> + };
> + };
> + };
> +
> + pmx_sdc1_cmd {
> + sdc1_cmd_on: cmd_on {
> + pinmux {
> + pins = "sdc1_cmd";
> + };
> + pinconf {
> + pins = "sdc1_cmd";
> + bias-pull-up;
> + drive-strength = <8>;
> + };
> + };
> + sdc1_cmd_off: cmd_off {
> + pinmux {
> + pins = "sdc1_cmd";
> + };
> + pinconf {
> + pins = "sdc1_cmd";
> + bias-pull-up = <0x3>; /* same as 3.10 ?? */
> + drive-strength = <2>; /* 2mA */
> + };
> + };
> + };
> +
> + pmx_sdc1_data {
> + sdc1_data_on: data_on {
> + pinmux {
> + pins = "sdc1_data";
> + };
> + pinconf {
> + pins = "sdc1_data";
> + bias-pull-up;
> + drive-strength = <8>; /* 8mA */
> + };
> + };
> + sdc1_data_off: data_off {
> + pinmux {
> + pins = "sdc1_data";
> + };
> + pinconf {
> + pins = "sdc1_data";
> + bias-pull-up;
> + drive-strength = <2>;
> + };
> + };
> + };
> +
> + pmx_sdc1_rclk {
> + sdc1_rclk_on: rclk_on {
> + bias-pull-down; /* pull down */
> + };
> + sdc1_rclk_off: rclk_off {
> + bias-pull-down; /* pull down */
> + };
> + };
> };
> diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi b/arch/arm64/boot/dts/qcom/msm8992.dtsi
> index 44b2d37..d104770 100644
> --- a/arch/arm64/boot/dts/qcom/msm8992.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8992.dtsi
> @@ -82,6 +82,12 @@
> <0xf9002000 0x1000>;
> };
>
> + apcs: syscon@0xf900d000 {
Drop the '0x'.
> + compatible = "syscon";
> + reg = <0xf900d000 0x2000>;
> + };
> +
> +
> timer@f9020000 {
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -172,12 +178,159 @@
> #power-domain-cells = <1>;
> reg = <0xfc400000 0x2000>;
> };
> +
> + sdhci1: qcom,sdhci@f9824900 {
mmc@...
> + compatible = "qcom,sdhci-msm-v4";
> + reg = <0xf9824900 0x1a0>, <0xf9824000 0x800>;
> + reg-names = "hc_mem", "core_mem";
> +
> + interrupts = <GIC_SPI 123 IRQ_TYPE_NONE>,
> + <GIC_SPI 138 IRQ_TYPE_NONE>;
> + interrupt-names = "hc_irq", "pwr_irq";
> +
> + clocks = <&clock_gcc GCC_SDCC1_APPS_CLK>,
> + <&clock_gcc GCC_SDCC1_AHB_CLK>;
> + clock-names = "core", "iface";
> +
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&sdc1_clk_on &sdc1_cmd_on &sdc1_data_on
> + &sdc1_rclk_on>;
> + pinctrl-1 = <&sdc1_clk_off &sdc1_cmd_off &sdc1_data_off
> + &sdc1_rclk_off>;
> +
> + vdd-supply = <&pm8994_l20>;
> + qcom,vdd-voltage-level = <2950000 2950000>;
> + qcom,vdd-current-level = <200 570000>;
> +
> + vdd-io-supply = <&pm8994_s4>;
> + qcom,vdd-io-voltage-level = <1800000 1800000>;
> + qcom,vdd-io-current-level = <200 325000>;
> +
> + regulator-always-on;
> + bus-width = <8>;
> + mmc-hs400-1_8v;
> + status = "okay";
> + };
> +
> + vreg_vph_pwr: vreg-vph-pwr {
> + compatible = "regulator-fixed";
> + status = "okay";
> + regulator-name = "vph-pwr";
> +
> + regulator-min-microvolt = <3600000>;
> + regulator-max-microvolt = <3600000>;
> +
> + regulator-always-on;
> + };
> +
> + rpm_msg_ram: memory@fc428000 {
> + compatible = "qcom,rpm-msg-ram";
> + reg = <0xfc428000 0x4000>;
> + };
> +
> + sfpb_mutex_regs: syscon@fd484000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "syscon";
> + reg = <0xfd484000 0x400>;
> + };
> +
> + sfpb_mutex: hwmutex {
> + compatible = "qcom,sfpb-mutex";
> + syscon = <&sfpb_mutex_regs 0x0 0x100>;
> + #hwlock-cells = <1>;
> + };
> +
> + smem {
> + compatible = "qcom,smem";
> + memory-region = <&smem_region>;
> + qcom,rpm-msg-ram = <&rpm_msg_ram>;
> + hwlocks = <&sfpb_mutex 3>;
> + };
> };
>
> memory {
> device_type = "memory";
> reg = <0 0 0 0>; // bootloader will update
> };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + smem_region: smem@6a00000 {
> + reg = <0x0 0x6a00000 0x0 0x200000>;
> + no-map;
> + };
> + };
> +
> + smd_rpm: smd {
> + compatible = "qcom,smd";
> +
> + rpm {
> + interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
> + qcom,ipc = <&apcs 8 0>;
> + qcom,smd-edge = <15>;
> + qcom,local-pid = <0>;
> + qcom,remote-pid = <6>;
> +
> + rpm_requests {
> + compatible = "qcom,rpm-msm8994";
> + qcom,smd-channels = "rpm_requests";
> +
> + rpmcc: qcom,rpmcc {
> + /* TODO: update when rpmcc-msm8994 support added */
> + compatible = "qcom,rpmcc-msm8916",
> + "qcom,rpmcc";
> + #clock-cells = <1>;
> + };
> +
> + smd_rpm_regulators: pm8994-regulators {
> + compatible = "qcom,rpm-pm8994-regulators";
> +
> + pm8994_s1: s1 {};
> + pm8994_s2: s2 {};
> + pm8994_s3: s3 {};
> + pm8994_s4: s4 {};
> + pm8994_s5: s5 {};
> + pm8994_s6: s6 {};
> + pm8994_s7: s7 {};
> +
> + pm8994_l1: l1 {};
> + pm8994_l2: l2 {};
> + pm8994_l3: l3 {};
> + pm8994_l4: l4 {};
> + pm8994_l6: l6 {};
> + pm8994_l8: l8 {};
> + pm8994_l9: l9 {};
> + pm8994_l10: l10 {};
> + pm8994_l11: l11 {};
> + pm8994_l12: l12 {};
> + pm8994_l13: l13 {};
> + pm8994_l14: l14 {};
> + pm8994_l15: l15 {};
> + pm8994_l16: l16 {};
> + pm8994_l17: l17 {};
> + pm8994_l18: l18 {};
> + pm8994_l19: l19 {};
> + pm8994_l20: l20 {};
> + pm8994_l21: l21 {};
> + pm8994_l22: l22 {};
> + pm8994_l23: l23 {};
> + pm8994_l24: l24 {};
> + pm8994_l25: l25 {};
> + pm8994_l26: l26 {};
> + pm8994_l27: l27 {};
> + pm8994_l28: l28 {};
> + pm8994_l29: l29 {};
> + pm8994_l30: l30 {};
> + pm8994_l31: l31 {};
> + pm8994_l32: l32 {};
> + };
> + };
> + };
> + };
> };
>
>
> diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
> index 8ed46a9..a7e8ce7 100644
> --- a/drivers/regulator/qcom_smd-regulator.c
> +++ b/drivers/regulator/qcom_smd-regulator.c
> @@ -443,11 +443,60 @@ static const struct rpm_regulator_data rpm_pma8084_regulators[] = {
> {}
> };
>
> +static const struct rpm_regulator_data rpm_pm8994_regulators[] = {
> + { "s1", QCOM_SMD_RPM_SMPA, 1, &pma8084_ftsmps, "vdd_s1" },
> + { "s2", QCOM_SMD_RPM_SMPA, 2, &pma8084_ftsmps, "vdd_s2" },
> + { "s3", QCOM_SMD_RPM_SMPA, 3, &pma8084_hfsmps, "vdd_s3" },
> + { "s4", QCOM_SMD_RPM_SMPA, 4, &pma8084_hfsmps, "vdd_s4" },
> + { "s5", QCOM_SMD_RPM_SMPA, 5, &pma8084_hfsmps, "vdd_s5" },
> + { "s6", QCOM_SMD_RPM_SMPA, 6, &pma8084_ftsmps, "vdd_s6" },
> + { "s7", QCOM_SMD_RPM_SMPA, 7, &pma8084_ftsmps, "vdd_s7" },
> +
> + { "l1", QCOM_SMD_RPM_LDOA, 1, &pma8084_nldo, "vdd_l1_l11" },
> + { "l2", QCOM_SMD_RPM_LDOA, 2, &pma8084_nldo, "vdd_l2_l3_l4_l27" },
> + { "l3", QCOM_SMD_RPM_LDOA, 3, &pma8084_nldo, "vdd_l2_l3_l4_l27" },
> + { "l4", QCOM_SMD_RPM_LDOA, 4, &pma8084_nldo, "vdd_l2_l3_l4_l27" },
> + { "l5", QCOM_SMD_RPM_LDOA, 5, &pma8084_pldo, "vdd_l5_l7" },
> + { "l6", QCOM_SMD_RPM_LDOA, 6, &pma8084_pldo, "vdd_l6_l12_l14_l15_l26" },
> + { "l7", QCOM_SMD_RPM_LDOA, 7, &pma8084_pldo, "vdd_l5_l7" },
> + { "l8", QCOM_SMD_RPM_LDOA, 8, &pma8084_pldo, "vdd_l8" },
> + { "l9", QCOM_SMD_RPM_LDOA, 9, &pma8084_pldo, "vdd_l9_l10_l13_l20_l23_l24" },
> + { "l10", QCOM_SMD_RPM_LDOA, 10, &pma8084_pldo, "vdd_l9_l10_l13_l20_l23_l24" },
> + { "l11", QCOM_SMD_RPM_LDOA, 11, &pma8084_nldo, "vdd_l1_l11" },
> + { "l12", QCOM_SMD_RPM_LDOA, 12, &pma8084_pldo, "vdd_l6_l12_l14_l15_l26" },
> + { "l13", QCOM_SMD_RPM_LDOA, 13, &pma8084_pldo, "vdd_l9_l10_l13_l20_l23_l24" },
> + { "l14", QCOM_SMD_RPM_LDOA, 14, &pma8084_pldo, "vdd_l6_l12_l14_l15_l26" },
> + { "l15", QCOM_SMD_RPM_LDOA, 15, &pma8084_pldo, "vdd_l6_l12_l14_l15_l26" },
> + { "l16", QCOM_SMD_RPM_LDOA, 16, &pma8084_pldo, "vdd_l16_l25" },
> + { "l17", QCOM_SMD_RPM_LDOA, 17, &pma8084_pldo, "vdd_l17" },
> + { "l18", QCOM_SMD_RPM_LDOA, 18, &pma8084_pldo, "vdd_l18" },
> + { "l19", QCOM_SMD_RPM_LDOA, 19, &pma8084_pldo, "vdd_l19" },
> + { "l20", QCOM_SMD_RPM_LDOA, 20, &pma8084_pldo, "vdd_l9_l10_l13_l20_l23_l24" },
> + { "l21", QCOM_SMD_RPM_LDOA, 21, &pma8084_pldo, "vdd_l21" },
> + { "l22", QCOM_SMD_RPM_LDOA, 22, &pma8084_pldo, "vdd_l22" },
> + { "l23", QCOM_SMD_RPM_LDOA, 23, &pma8084_pldo, "vdd_l9_l10_l13_l20_l23_l24" },
> + { "l24", QCOM_SMD_RPM_LDOA, 24, &pma8084_pldo, "vdd_l9_l10_l13_l20_l23_l24" },
> + { "l25", QCOM_SMD_RPM_LDOA, 25, &pma8084_pldo, "vdd_l16_l25" },
> + { "l26", QCOM_SMD_RPM_LDOA, 26, &pma8084_pldo, "vdd_l6_l12_l14_l15_l26" },
> + { "l27", QCOM_SMD_RPM_LDOA, 27, &pma8084_nldo, "vdd_l27" },
> + { "l28", QCOM_SMD_RPM_LDOA, 28, &pma8084_nldo, "vdd_l28" },
> + { "l29", QCOM_SMD_RPM_LDOA, 29, &pma8084_nldo, "vdd_l29" },
> + { "l30", QCOM_SMD_RPM_LDOA, 30, &pma8084_nldo, "vdd_l30" },
> + { "l31", QCOM_SMD_RPM_LDOA, 31, &pma8084_nldo, "vdd_l31" },
> + { "l32", QCOM_SMD_RPM_LDOA, 32, &pma8084_nldo, "vdd_l32" },
> +
> + { "lvs1", QCOM_SMD_RPM_VSA, 1, &pma8084_switch },
> + { "lvs2", QCOM_SMD_RPM_VSA, 2, &pma8084_switch },
> +
> + {}
> +};
> +
> static const struct of_device_id rpm_of_match[] = {
> { .compatible = "qcom,rpm-pm8841-regulators", .data = &rpm_pm8841_regulators },
> { .compatible = "qcom,rpm-pm8916-regulators", .data = &rpm_pm8916_regulators },
> { .compatible = "qcom,rpm-pm8941-regulators", .data = &rpm_pm8941_regulators },
> { .compatible = "qcom,rpm-pma8084-regulators", .data = &rpm_pma8084_regulators },
> + { .compatible = "qcom,rpm-pm8994-regulators", .data = &rpm_pm8994_regulators },
> {}
> };
> MODULE_DEVICE_TABLE(of, rpm_of_match);
> --
> 2.6.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/5] smd: Make packet size a constant
From: Jeremy McNicoll @ 2016-11-28 21:20 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jeremy McNicoll, linux-arm-msm, linux-soc, devicetree, linux-mmc,
andy.gross, sboyd, robh, arnd, riteshh
In-Reply-To: <20161124061450.GV28340@tuxbot>
On Wed, Nov 23, 2016 at 10:14:50PM -0800, Bjorn Andersson wrote:
> On Tue 22 Nov 17:09 PST 2016, Jeremy McNicoll wrote:
>
> > Use a macro to define the maximum size of a RPM message.
> >
>
> No thanks.
>
Sure, will drop this change with V2 in a few days so that people have a chance
to provide feedback.
-jeremy
^ permalink raw reply
* [PATCH v3 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio controller sub-vended by NI
From: Zach Brown @ 2016-11-28 19:16 UTC (permalink / raw)
To: ulf.hansson; +Cc: adrian.hunter, linux-mmc, linux-kernel, zach.brown
In-Reply-To: <1480360599-13295-1-git-send-email-zach.brown@ni.com>
On NI 9037 boards the max SDIO frequency is limited by trace lengths
and other layout choices. The max SDIO frequency is stored in an ACPI
table.
The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the
f_max field of the host.
Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
Reviewed-by: Jaeden Amero <jaeden.amero@ni.com>
Reviewed-by: Josh Cartwright <joshc@ni.com>
Signed-off-by: Zach Brown <zach.brown@ni.com>
---
drivers/mmc/host/sdhci-pci-core.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index 9741505..c9e51b1 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -27,6 +27,7 @@
#include <linux/pm_runtime.h>
#include <linux/mmc/slot-gpio.h>
#include <linux/mmc/sdhci-pci-data.h>
+#include <linux/acpi.h>
#include "sdhci.h"
#include "sdhci-pci.h"
@@ -375,8 +376,39 @@ static int byt_emmc_probe_slot(struct sdhci_pci_slot *slot)
return 0;
}
+#ifdef CONFIG_ACPI
+static int ni_set_max_freq(struct sdhci_pci_slot *slot)
+{
+ acpi_status status;
+ unsigned long long max_freq;
+
+ status = acpi_evaluate_integer(ACPI_HANDLE(&slot->chip->pdev->dev),
+ "MXFQ", NULL, &max_freq);
+ if (ACPI_FAILURE(status)) {
+ dev_err(&slot->chip->pdev->dev,
+ "MXFQ not found in acpi table\n");
+ return -EINVAL;
+ }
+
+ slot->host->mmc->f_max = max_freq * 1000000;
+
+ return 0;
+}
+#else
+static inline int ni_set_max_freq(struct sdhci_pci_slot *slot)
+{
+ return 0;
+}
+#endif
+
static int ni_byt_sdio_probe_slot(struct sdhci_pci_slot *slot)
{
+ int err;
+
+ err = ni_set_max_freq(slot);
+ if (err)
+ return err;
+
slot->host->mmc->caps |= MMC_CAP_POWER_OFF_CARD | MMC_CAP_NONREMOVABLE |
MMC_CAP_WAIT_WHILE_BUSY;
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] mmc: sdhci-pci: Add PCI ID for Intel byt sdio host controller sub-vended by NI
From: Zach Brown @ 2016-11-28 19:16 UTC (permalink / raw)
To: ulf.hansson; +Cc: adrian.hunter, linux-mmc, linux-kernel, zach.brown
In-Reply-To: <1480360599-13295-1-git-send-email-zach.brown@ni.com>
Add PCI ID for Intel byt sdio host controller sub-vended by NI.
The controller has different behavior because of the board layout NI
puts it on.
Signed-off-by: Zach Brown <zach.brown@ni.com>
---
drivers/mmc/host/sdhci-pci-core.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index 1d9e00a..9741505 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -375,6 +375,13 @@ static int byt_emmc_probe_slot(struct sdhci_pci_slot *slot)
return 0;
}
+static int ni_byt_sdio_probe_slot(struct sdhci_pci_slot *slot)
+{
+ slot->host->mmc->caps |= MMC_CAP_POWER_OFF_CARD | MMC_CAP_NONREMOVABLE |
+ MMC_CAP_WAIT_WHILE_BUSY;
+ return 0;
+}
+
static int byt_sdio_probe_slot(struct sdhci_pci_slot *slot)
{
slot->host->mmc->caps |= MMC_CAP_POWER_OFF_CARD | MMC_CAP_NONREMOVABLE |
@@ -447,6 +454,15 @@ static const struct sdhci_pci_fixes sdhci_intel_byt_emmc = {
.ops = &sdhci_intel_byt_ops,
};
+static const struct sdhci_pci_fixes sdhci_ni_byt_sdio = {
+ .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
+ .quirks2 = SDHCI_QUIRK2_HOST_OFF_CARD_ON |
+ SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+ .allow_runtime_pm = true,
+ .probe_slot = ni_byt_sdio_probe_slot,
+ .ops = &sdhci_intel_byt_ops,
+};
+
static const struct sdhci_pci_fixes sdhci_intel_byt_sdio = {
.quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
.quirks2 = SDHCI_QUIRK2_HOST_OFF_CARD_ON |
@@ -1079,6 +1095,14 @@ static const struct pci_device_id pci_ids[] = {
{
.vendor = PCI_VENDOR_ID_INTEL,
.device = PCI_DEVICE_ID_INTEL_BYT_SDIO,
+ .subvendor = PCI_VENDOR_ID_NI,
+ .subdevice = 0x7884,
+ .driver_data = (kernel_ulong_t)&sdhci_ni_byt_sdio,
+ },
+
+ {
+ .vendor = PCI_VENDOR_ID_INTEL,
+ .device = PCI_DEVICE_ID_INTEL_BYT_SDIO,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
.driver_data = (kernel_ulong_t)&sdhci_intel_byt_sdio,
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/2] mmc: sdhci-pci: Use ACPI to set max frequency of sdio host controller
From: Zach Brown @ 2016-11-28 19:16 UTC (permalink / raw)
To: ulf.hansson; +Cc: adrian.hunter, linux-mmc, linux-kernel, zach.brown
On some boards, max SDIO frequency is limited by trace lengths and other layout
choices. We would like a way to specify this limitation so the driver can
behave accordingly.
This patch set assumes that the limitation has been reported in an ACPI table
which the driver can check to get the max frequency.
The first patch creates a PCI ID and support for the Intel byt sdio where NI is
the subvendor.
If CONFIG_ACPI is set, the second patch uses the ACPI table to set f_max during
the new ni_byt_sdio_probe_slot.
rv2:
* Use acpi_evaluate_integer() instead of
acpi_get_handle()/acpi_evaluate_object()
pv1:
* Removed redundant comment
* Print info message if MXFQ not found in acpi table
pv2:
* Changed info message to error message if MXFQ not found
* Replaced ni_byt_sdio_probe_slot with one of two versions depending on
whether CONFIG_ACPI is set.
pv3:
* Replaced the two versions of ni_byt_sdio_probe_slot with new version that
calls ni_set_max_freq.
* Created ni_set_max_freq which sets the slot's max_freq if CONFIG_ACPI is
set.
Zach Brown (2):
mmc: sdhci-pci: Add PCI ID for Intel byt sdio host controller
sub-vended by NI
mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio
controller sub-vended by NI
drivers/mmc/host/sdhci-pci-core.c | 56 +++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v2] mmc: sdhci-msm: Add sdhci_reset() implementation
From: Georgi Djakov @ 2016-11-28 17:39 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson
Cc: linux-mmc, linux-kernel, linux-arm-msm, riteshh, georgi.djakov
On apq8016, apq8084 and apq8074 platforms, writing to the software
reset register triggers the "power irq". We need to ack and handle
the irq, otherwise the following message appears:
mmc0: Reset 0x1 never completed.
sdhci: =========== REGISTER DUMP (mmc0)===========
sdhci: Sys addr: 0x00000000 | Version: 0x00002e02
sdhci: Blk size: 0x00004000 | Blk cnt: 0x00000000
sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci: Present: 0x01f80000 | Host ctl: 0x00000000
sdhci: Power: 0x00000000 | Blk gap: 0x00000000
sdhci: Wake-up: 0x00000000 | Clock: 0x00000003
sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000
sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007
sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
sdhci: Host ctl2: 0x00000000
sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000
sdhci: ===========================================
Fix it by implementing the custom sdhci_reset() function,
which performs the software reset and then handles the irq.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
---
Changes since v1: (https://lkml.org/lkml/2016/11/22/411)
* Perform the software reset by just writing to the SDHCI_SOFTWARE_RESET
register and then check for the irq.
drivers/mmc/host/sdhci-msm.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 32879b845b75..157ae07f9309 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1019,6 +1019,33 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
__sdhci_msm_set_clock(host, clock);
}
+void sdhci_msm_reset(struct sdhci_host *host, u8 mask)
+{
+ unsigned long timeout = 100;
+
+ sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
+
+ if (mask & SDHCI_RESET_ALL) {
+ host->clock = 0;
+
+ /*
+ * SDHCI_RESET_ALL triggers the PWR IRQ and we need
+ * to handle it here.
+ */
+ sdhci_msm_voltage_switch(host);
+ }
+
+ while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) {
+ if (timeout == 0) {
+ pr_err("%s: Reset 0x%x never completed.\n",
+ mmc_hostname(host->mmc), (int)mask);
+ return;
+ }
+ timeout--;
+ mdelay(1);
+ }
+}
+
static const struct of_device_id sdhci_msm_dt_match[] = {
{ .compatible = "qcom,sdhci-msm-v4" },
{},
@@ -1028,7 +1055,7 @@ MODULE_DEVICE_TABLE(of, sdhci_msm_dt_match);
static const struct sdhci_ops sdhci_msm_ops = {
.platform_execute_tuning = sdhci_msm_execute_tuning,
- .reset = sdhci_reset,
+ .reset = sdhci_msm_reset,
.set_clock = sdhci_msm_set_clock,
.get_min_clock = sdhci_msm_get_min_clock,
.get_max_clock = sdhci_msm_get_max_clock,
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox