[RFC/PATCH 0/1] Add MMC write packing statistics
The write packing statistics are used for the packed commands unit tests in order to determine test success or failure this patch is dependant in the following patches: [PATCH v6 1/3] mmc: core: Add packed command feature of eMMC4.5 [PATCH v6 2/3] mmc: core: Support packed write command for eMMC4.5 device Maya Erez (1): mmc: block: Add MMC write packing statistics drivers/mmc/card/block.c | 56 +++- drivers/mmc/core/bus.c |4 + drivers/mmc/core/debugfs.c | 164 drivers/mmc/core/mmc.c | 18 + include/linux/mmc/card.h | 24 +++ 5 files changed, 265 insertions(+), 1 deletions(-) -- 1.7.3.3 -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 1/1] mmc: block: Add MMC write packing statistics
The write packing statistics are used for the packed commands unit tests
in order to determine test success or failure
Signed-off-by: Maya Erez me...@codeaurora.org
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 2785fd4..c33c0c8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -63,6 +63,11 @@ MODULE_ALIAS(mmc:block);
(rq_data_dir(req) == WRITE))
#define PACKED_CMD_VER 0x01
#define PACKED_CMD_WR 0x02
+#define MMC_BLK_UPDATE_STOP_REASON(stats, reason) \
+ do {\
+ if (stats-enabled) \
+ stats-pack_stop_reason[reason]++; \
+ } while (0)
static DEFINE_MUTEX(block_mutex);
@@ -1313,6 +1318,35 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
*mqrq,
mmc_queue_bounce_pre(mqrq);
}
+struct mmc_wr_pack_stats *mmc_blk_get_packed_statistics(struct mmc_card *card)
+{
+ if (!card)
+ return NULL;
+
+ return card-wr_pack_stats;
+}
+EXPORT_SYMBOL(mmc_blk_get_packed_statistics);
+
+void mmc_blk_init_packed_statistics(struct mmc_card *card)
+{
+ int max_num_of_packed_reqs = 0;
+
+ if (!card || !card-wr_pack_stats.packing_events)
+ return;
+
+ max_num_of_packed_reqs = card-ext_csd.max_packed_writes;
+
+ spin_lock(card-wr_pack_stats.lock);
+ memset(card-wr_pack_stats.packing_events, 0,
+ (max_num_of_packed_reqs + 1) *
+ sizeof(*card-wr_pack_stats.packing_events));
+ memset(card-wr_pack_stats.pack_stop_reason, 0,
+ sizeof(card-wr_pack_stats.pack_stop_reason));
+ card-wr_pack_stats.enabled = true;
+ spin_unlock(card-wr_pack_stats.lock);
+}
+EXPORT_SYMBOL(mmc_blk_init_packed_statistics);
+
static u8 mmc_blk_prep_packed_list(struct mmc_queue *mq, struct request *req)
{
struct request_queue *q = mq-queue;
@@ -1325,6 +1359,7 @@ static u8 mmc_blk_prep_packed_list(struct mmc_queue *mq,
struct request *req)
u8 put_back = 0;
u8 max_packed_rw = 0;
u8 reqs = 0;
+ struct mmc_wr_pack_stats *stats = card-wr_pack_stats;
mmc_blk_clear_packed(mq-mqrq_cur);
@@ -1359,20 +1394,26 @@ static u8 mmc_blk_prep_packed_list(struct mmc_queue
*mq, struct request *req)
phys_segments++;
}
+ spin_lock(stats-lock);
+
while (reqs max_packed_rw - 1) {
spin_lock_irq(q-queue_lock);
next = blk_fetch_request(q);
spin_unlock_irq(q-queue_lock);
- if (!next)
+ if (!next) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, EMPTY_QUEUE);
break;
+ }
if (next-cmd_flags REQ_DISCARD ||
next-cmd_flags REQ_FLUSH) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, FLUSH_OR_DISCARD);
put_back = 1;
break;
}
if (rq_data_dir(cur) != rq_data_dir(next)) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, WRONG_DATA_DIR);
put_back = 1;
break;
}
@@ -1380,18 +1421,22 @@ static u8 mmc_blk_prep_packed_list(struct mmc_queue
*mq, struct request *req)
if (mmc_req_rel_wr(next)
(md-flags MMC_BLK_REL_WR)
!en_rel_wr) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, REL_WRITE);
put_back = 1;
break;
}
req_sectors += blk_rq_sectors(next);
if (req_sectors max_blk_count) {
+ if (stats-enabled)
+ stats-pack_stop_reason[EXCEEDS_SECTORS]++;
put_back = 1;
break;
}
phys_segments += next-nr_phys_segments;
if (phys_segments max_phys_segs) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, EXCEEDS_SEGMENTS);
put_back = 1;
break;
}
@@ -1407,6 +1452,15 @@ static u8 mmc_blk_prep_packed_list(struct mmc_queue *mq,
struct request *req)
spin_unlock_irq(q-queue_lock);
}
+ if (stats-enabled) {
+ if (reqs + 1 = card-ext_csd.max_packed_writes)
+ stats-packing_events[reqs + 1]++;
+ if (reqs + 1 == max_packed_rw)
+ MMC_BLK_UPDATE_STOP_REASON(stats, THRESHOLD);
+ }
+
+ spin_unlock(stats-lock);
+
if (reqs 0) {
list_add(req-queuelist, mq-mqrq_cur-packed_list);
mq-mqrq_cur-packed_num = ++reqs;
diff --git a/drivers/mmc/core/bus.c
Re: [RFC/PATCH 1/1] mmc: block: Add MMC write packing statistics
See comments inline.
On Wed, Jun 6, 2012 at 11:46 AM, Maya Erez me...@codeaurora.org wrote:
The write packing statistics are used for the packed commands unit tests
in order to determine test success or failure
Signed-off-by: Maya Erez me...@codeaurora.org
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 2785fd4..c33c0c8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -63,6 +63,11 @@ MODULE_ALIAS(mmc:block);
(rq_data_dir(req) == WRITE))
#define PACKED_CMD_VER 0x01
#define PACKED_CMD_WR 0x02
+#define MMC_BLK_UPDATE_STOP_REASON(stats, reason) \
+ do { \
+ if (stats-enabled) \
+ stats-pack_stop_reason[reason]++; \
+ } while (0)
static DEFINE_MUTEX(block_mutex);
@@ -1313,6 +1318,35 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
*mqrq,
mmc_queue_bounce_pre(mqrq);
}
+struct mmc_wr_pack_stats *mmc_blk_get_packed_statistics(struct mmc_card
*card)
+{
+ if (!card)
+ return NULL;
+
+ return card-wr_pack_stats;
+}
+EXPORT_SYMBOL(mmc_blk_get_packed_statistics);
+
+void mmc_blk_init_packed_statistics(struct mmc_card *card)
+{
+ int max_num_of_packed_reqs = 0;
+
+ if (!card || !card-wr_pack_stats.packing_events)
+ return;
+
+ max_num_of_packed_reqs = card-ext_csd.max_packed_writes;
+
+ spin_lock(card-wr_pack_stats.lock);
+ memset(card-wr_pack_stats.packing_events, 0,
+ (max_num_of_packed_reqs + 1) *
+ sizeof(*card-wr_pack_stats.packing_events));
+ memset(card-wr_pack_stats.pack_stop_reason, 0,
+ sizeof(card-wr_pack_stats.pack_stop_reason));
+ card-wr_pack_stats.enabled = true;
+ spin_unlock(card-wr_pack_stats.lock);
+}
+EXPORT_SYMBOL(mmc_blk_init_packed_statistics);
+
static u8 mmc_blk_prep_packed_list(struct mmc_queue *mq, struct request *req)
{
struct request_queue *q = mq-queue;
@@ -1325,6 +1359,7 @@ static u8 mmc_blk_prep_packed_list(struct mmc_queue
*mq, struct request *req)
u8 put_back = 0;
u8 max_packed_rw = 0;
u8 reqs = 0;
+ struct mmc_wr_pack_stats *stats = card-wr_pack_stats;
mmc_blk_clear_packed(mq-mqrq_cur);
@@ -1359,20 +1394,26 @@ static u8 mmc_blk_prep_packed_list(struct mmc_queue
*mq, struct request *req)
phys_segments++;
}
+ spin_lock(stats-lock);
+
while (reqs max_packed_rw - 1) {
spin_lock_irq(q-queue_lock);
next = blk_fetch_request(q);
spin_unlock_irq(q-queue_lock);
- if (!next)
+ if (!next) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, EMPTY_QUEUE);
break;
+ }
if (next-cmd_flags REQ_DISCARD ||
next-cmd_flags REQ_FLUSH) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, FLUSH_OR_DISCARD);
put_back = 1;
break;
}
if (rq_data_dir(cur) != rq_data_dir(next)) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, WRONG_DATA_DIR);
put_back = 1;
break;
}
@@ -1380,18 +1421,22 @@ static u8 mmc_blk_prep_packed_list(struct mmc_queue
*mq, struct request *req)
if (mmc_req_rel_wr(next)
(md-flags MMC_BLK_REL_WR)
!en_rel_wr) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, REL_WRITE);
put_back = 1;
break;
}
req_sectors += blk_rq_sectors(next);
if (req_sectors max_blk_count) {
+ if (stats-enabled)
+ stats-pack_stop_reason[EXCEEDS_SECTORS]++;
put_back = 1;
break;
}
phys_segments += next-nr_phys_segments;
if (phys_segments max_phys_segs) {
+ MMC_BLK_UPDATE_STOP_REASON(stats, EXCEEDS_SEGMENTS);
put_back = 1;
break;
}
@@ -1407,6 +1452,15 @@ static u8 mmc_blk_prep_packed_list(struct mmc_queue
*mq, struct request *req)
spin_unlock_irq(q-queue_lock);
}
+ if (stats-enabled) {
+ if (reqs + 1 = card-ext_csd.max_packed_writes)
+ stats-packing_events[reqs + 1]++;
+ if (reqs + 1 == max_packed_rw)
+ MMC_BLK_UPDATE_STOP_REASON(stats, THRESHOLD);
+ }
+
+ spin_unlock(stats-lock);
+
RE: power class selection fails on 3.5-rc1
Girish / Saugata needs to comment on one point
Comments inline:
-Original Message-
From: Ulf Hansson [mailto:ulf.hans...@stericsson.com]
Sent: Tuesday, June 05, 2012 6:06 PM
To: Marc Dietrich; Subhash Jadavani
Cc: linux-mmc@vger.kernel.org
Subject: Re: power class selection fails on 3.5-rc1
Hi Marc,
Maybe we can have some input from Subhash on this matter. I believe a
revert
can be feasible until a working solution exist.
Kind regards
Ulf Hansson
On 06/04/2012 06:35 PM, Marc Dietrich wrote:
Hi,
somehow I hope this would go away by itself, but it didn't :-( I
reported this problem some time ago (see:
http://www.mail-archive.com/linux-
m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix.
In addition to the information I posted on the thread above, I also
dumped the contents of the ext_csd register file (where reg values are
not
zero):
reg Sandisk Toshiba
241 10 0x0a50 0x32
239 0 0x0051 0x33
238 0 0x00119 0x77
234 0 0x0030 0x1e
232 1 0x014 0x04
231 21 0x1521 0x15
230 150 0x9616 0x10
229 150 0x9666 0x42
228 1 0x017 0x07
226 8 0x0816 0x10
225 6 0x067 0x07
224 4 0x048 0x08
223 1 0x012 0x02
222 8 0x0816 0x10
221 16 0x101 0x01
220 8 0x087 0x07
219 7 0x077 0x07
217 16 0x1017 0x11
215 1 0x010 0x00
214 218 0xda238 0xee
213 160 0xa0128 0x80
210 10 0x0a0 0x00
209 10 0x0a60 0x3c
208 10 0x0a0 0x00
207 10 0x0a60 0x3c
206 10 0x0a0 0x00
205 10 0x0a30 0x1e
203 0 0x0051 0x33
202 0 0x0051 0x33
201 0 0x00119 0x77
200 0 0x00119 0x77
196 3 0x037 0x07
194 2 0x022 0x02
192 5 0x055 0x05
185 1 0x011 0x01
181 0 0x001 0x01
179 0 0x001 0x01
175 0 0x001 0x01
169 1 0x010 0x00
168 0 0x002 0x02
160 3 0x033 0x03
158 0 0x003 0x03
157 237 0xed186 0xba
The second and the third column is from a device with a Sandisk eMCC
which works fine, while the last two columns are from a Toshiba eMMC
which shows the error. Looking into it, I found that only the Toshiba
eMMC specifies a powerclass in registers 203-200 while Sandisk does
not, so the powerclass is not changed in the latter case and the problem
cannot be triggered there.
I also attached a boot log with mmc debug enabled. I think there is
not much I can do else. Either this eMMC is just bogus and needs
blacklisting or there is some problem in the driver code.
I checked the power class specification and MMC core driver handing, I don't
see any issue with it. As you mentioned the PWR_CL_* fields are having
non-zero values which means SWITCH (CMD6) will be sent to change the
POWER_CLASS and from the logs you have attached, this switch command tries
to set the POWER_CLASS to 3 which is resulting in SWITCH_ERROR in card and
that's why it fails.
If the PWR_CL_* fields are 0s (that's the case with SanDisk eMMC as you
mentioned), SWITCH(cmd6) is not sent to the card.
I was trying to check analyze more from logs and the above EXT_CSD fields
for Toshiba card.
EXT_CSD[203] = PWR_CL_26_360 = 0x33
EXT_CSD[202] = PWR_CL_52_360 = 0x33
EXT_CSD[201] = PWR_CL_26_195 = 0x77
EXT_CSD[200] = PWR_CL_52_195 = 0x77
[3.842382] mmc1: clock 4800Hz busmode 2 powermode 2 cs 0 Vdd 20
width 0 timing 1
Logs shows that clock = 48MHz, bus_width = 8-Bit, SDR mode, VDD = High
voltage range. This would mean power class for this configuration will be in
higher nibble of PWR_CL_52_360 field (EXT_CSD[202]) which is 0x3.
[3.842390] mmc1: starting CMD6 arg 03bb0301 flags 049d
arg field from this logs show that we are trying to set the POWER_CLASS
(EXT_CSD[187]) field to value 0x3 which is resulting in switch error which
ideally shouldn't.
Just for experiment, can we hack the value set to POWER_CLASS field to 0x7
instead of 0x3? If this doesn't work, you may try other values (starting
from 1 till 15) to see setting any of the non-zero value succeeds or not.
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 2d4a4b7..b26913a 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -713,7 +713,7 @@ static int mmc_select_powerclass(struct mmc_card *card,
if (pwrclass_val 0) {
err
Re: [PATCH] mmc: atmel-mci: fix data timeout issue
Hi, On Wed, May 23 2012, ludovic.desroc...@atmel.com wrote: From: Ludovic Desroches ludovic.desroc...@atmel.com The data timeout timer was configured after mmc_add_host call. So, with bad timings, it was possible to have a mmc request causing mod_timer call on a non setup timer. Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com --- drivers/mmc/host/atmel-mci.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c index 93a1012..a25e23a 100644 --- a/drivers/mmc/host/atmel-mci.c +++ b/drivers/mmc/host/atmel-mci.c @@ -2396,6 +2396,8 @@ static int __init atmci_probe(struct platform_device *pdev) platform_set_drvdata(pdev, host); + setup_timer(host-timer, atmci_timeout_timer, (unsigned long)host); + /* We need at least one slot to succeed */ nr_slots = 0; ret = -ENODEV; @@ -2434,8 +2436,6 @@ static int __init atmci_probe(struct platform_device *pdev) } } - setup_timer(host-timer, atmci_timeout_timer, (unsigned long)host); - dev_info(pdev-dev, Atmel MCI controller at 0x%08lx irq %d, %u slots\n, host-mapbase, irq, nr_slots); Pushed to mmc-next for 3.5, thanks. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: atmel-mci: fix burst/chunk size modification
Hi,
On Wed, May 16 2012, ludovic.desroc...@atmel.com wrote:
From: Nicolas Ferre nicolas.fe...@atmel.com
The use of DMA slave config operation requires that the burst size
(aka chunk size) is specified through this interface.
Modify atmel-mci slave driver to use this specification on its side.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
drivers/mmc/host/atmel-mci-regs.h | 14 ++
drivers/mmc/host/atmel-mci.c |7 +--
2 files changed, 19 insertions(+), 2 deletions(-)
This doesn't apply:
diff --git a/drivers/mmc/host/atmel-mci-regs.h
b/drivers/mmc/host/atmel-mci-regs.h
index 787aba1..ab56f7d 100644
--- a/drivers/mmc/host/atmel-mci-regs.h
+++ b/drivers/mmc/host/atmel-mci-regs.h
@@ -140,4 +140,18 @@
#define atmci_writel(port,reg,value) \
__raw_writel((value), (port)-regs + reg)
+/*
+ * Fix sconfig's burst size according to atmel MCI. We need to convert them
as:
+ * 1 - 0, 4 - 1, 8 - 2, 16 - 3.
+ *
+ * This can be done by finding most significant bit set.
+ */
+static inline unsigned int atmci_convert_chksize(unsigned int maxburst)
+{
+ if (maxburst 1)
+ return fls(maxburst) - 2;
+ else
+ return 0;
+}
+
#endif /* __DRIVERS_MMC_ATMEL_MCI_H__ */
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 2dbfb28..50e8652 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -834,6 +834,7 @@ atmci_prepare_data_dma(struct atmel_mci *host, struct
mmc_data *data)
enum dma_data_direction direction;
enum dma_transfer_direction slave_dirn;
unsigned intsglen;
+ u32 maxburst;
u32 iflags;
data-error = -EINPROGRESS;
@@ -867,16 +868,18 @@ atmci_prepare_data_dma(struct atmel_mci *host, struct
mmc_data *data)
if (!chan)
return -ENODEV;
- atmci_writel(host, ATMCI_DMA, ATMCI_DMA_CHKSIZE(3) | ATMCI_DMAEN);
-
.. because mainline actually looks like:
if (host-caps.has_dma)
atmci_writel(host, ATMCI_DMA, ATMCI_DMA_CHKSIZE(3) |
ATMCI_DMAEN);
and has done since 2011-08-11. Maybe this was created against the wrong
kernel version -- want to resend?
if (data-flags MMC_DATA_READ) {
direction = DMA_FROM_DEVICE;
host-dma_conf.direction = slave_dirn = DMA_DEV_TO_MEM;
+ maxburst = atmci_convert_chksize(host-dma_conf.src_maxburst);
} else {
direction = DMA_TO_DEVICE;
host-dma_conf.direction = slave_dirn = DMA_MEM_TO_DEV;
+ maxburst = atmci_convert_chksize(host-dma_conf.dst_maxburst);
}
+ atmci_writel(host, ATMCI_DMA, ATMCI_DMA_CHKSIZE(maxburst) |
ATMCI_DMAEN);
+
sglen = dma_map_sg(chan-device-dev, data-sg,
data-sg_len, direction);
Thanks,
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: atmel-mci: fix burst/chunk size modification
From: Nicolas Ferre nicolas.fe...@atmel.com
The use of DMA slave config operation requires that the burst size
(aka chunk size) is specified through this interface.
Modify atmel-mci slave driver to use this specification on its side.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
Hi Chris,
Sorry for this trouble, this patch should apply well on 3.5-rc1.
Thanks
Regards
Ludovic
drivers/mmc/host/atmel-mci-regs.h | 14 ++
drivers/mmc/host/atmel-mci.c |8 +---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/atmel-mci-regs.h
b/drivers/mmc/host/atmel-mci-regs.h
index 787aba1..ab56f7d 100644
--- a/drivers/mmc/host/atmel-mci-regs.h
+++ b/drivers/mmc/host/atmel-mci-regs.h
@@ -140,4 +140,18 @@
#define atmci_writel(port,reg,value) \
__raw_writel((value), (port)-regs + reg)
+/*
+ * Fix sconfig's burst size according to atmel MCI. We need to convert them as:
+ * 1 - 0, 4 - 1, 8 - 2, 16 - 3.
+ *
+ * This can be done by finding most significant bit set.
+ */
+static inline unsigned int atmci_convert_chksize(unsigned int maxburst)
+{
+ if (maxburst 1)
+ return fls(maxburst) - 2;
+ else
+ return 0;
+}
+
#endif /* __DRIVERS_MMC_ATMEL_MCI_H__ */
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 420aca6..556d384 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -910,6 +910,7 @@ atmci_prepare_data_dma(struct atmel_mci *host, struct
mmc_data *data)
enum dma_data_direction direction;
enum dma_transfer_direction slave_dirn;
unsigned intsglen;
+ u32 maxburst;
u32 iflags;
data-error = -EINPROGRESS;
@@ -943,17 +944,18 @@ atmci_prepare_data_dma(struct atmel_mci *host, struct
mmc_data *data)
if (!chan)
return -ENODEV;
- if (host-caps.has_dma)
- atmci_writel(host, ATMCI_DMA, ATMCI_DMA_CHKSIZE(3) |
ATMCI_DMAEN);
-
if (data-flags MMC_DATA_READ) {
direction = DMA_FROM_DEVICE;
host-dma_conf.direction = slave_dirn = DMA_DEV_TO_MEM;
+ maxburst = atmci_convert_chksize(host-dma_conf.src_maxburst);
} else {
direction = DMA_TO_DEVICE;
host-dma_conf.direction = slave_dirn = DMA_MEM_TO_DEV;
+ maxburst = atmci_convert_chksize(host-dma_conf.dst_maxburst);
}
+ atmci_writel(host, ATMCI_DMA, ATMCI_DMA_CHKSIZE(maxburst) |
ATMCI_DMAEN);
+
sglen = dma_map_sg(chan-device-dev, data-sg,
data-sg_len, direction);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: atmel-mci: fix burst/chunk size modification
Hi, On Wed, Jun 06 2012, ludovic.desroc...@atmel.com wrote: From: Nicolas Ferre nicolas.fe...@atmel.com The use of DMA slave config operation requires that the burst size (aka chunk size) is specified through this interface. Modify atmel-mci slave driver to use this specification on its side. Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com --- Hi Chris, Sorry for this trouble, this patch should apply well on 3.5-rc1. Thanks, pushed to mmc-next for 3.5. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mmc:sdio:guarantee setting card data bus width as 4-bit
Hi, On Tue, May 15 2012, yongd wrote: SDIO_CCCR_IF[1:0] in SDIO card is used for card data bus width setting as below, 00b: 1-bit bus 01b: Reserved 10b: 4-bit bus 11b: 8-bit bus(only for embedded SDIO) And sdio_enable_wide is for setting data bus width as 4-bit. But currently, it 1stly read the register, 2ndly OR' 1b with SDIO_CCCR_IF[1], and then write it back. As we can see, such way is based on such assumption that the SDIO_CCCR_IF[0] is always 0. Apparently, this is not right. Signed-off-by: yongd yo...@marvell.com --- drivers/mmc/core/sdio.c |7 +++ include/linux/mmc/sdio.h |2 ++ 2 files changed, 9 insertions(+) diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c index 13d0e95..7b528cf 100644 --- a/drivers/mmc/core/sdio.c +++ b/drivers/mmc/core/sdio.c @@ -218,6 +218,13 @@ static int sdio_enable_wide(struct mmc_card *card) if (ret) return ret; + if ((ctrl SDIO_BUS_WIDTH_MASK) + == SDIO_BUS_WIDTH_RESERVED) + printk(KERN_WARNING%s: SDIO_CCCR_IF is invalid: 0x%02X\n, + mmc_hostname(card-host), ctrl); + + /* set as 4-bit bus width */ + ctrl = ~SDIO_BUS_WIDTH_MASK; ctrl |= SDIO_BUS_WIDTH_4BIT; ret = mmc_io_rw_direct(card, 1, 0, SDIO_CCCR_IF, ctrl, NULL); diff --git a/include/linux/mmc/sdio.h b/include/linux/mmc/sdio.h index c9fe66c..17446d3 100644 --- a/include/linux/mmc/sdio.h +++ b/include/linux/mmc/sdio.h @@ -98,7 +98,9 @@ #define SDIO_CCCR_IF 0x07/* bus interface controls */ +#define SDIO_BUS_WIDTH_MASK 0x03/* data bus width setting */ #define SDIO_BUS_WIDTH_1BIT 0x00 +#define SDIO_BUS_WIDTH_RESERVED 0x01 #define SDIO_BUS_WIDTH_4BIT 0x02 #define SDIO_BUS_ECSI 0x20/* Enable continuous SPI interrupt */ #define SDIO_BUS_SCSI 0x40/* Support continuous SPI interrupt */ Thanks, pushed to mmc-next for 3.5. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()
Hi, On Sat, May 19 2012, Subhash Jadavani wrote: Do you see any issues with this patch? No, no issues -- please could I ask you to refresh it against 3.5-rc1 (it no longer applies) and add your performance numbers to the commit message? I'll push it to mmc-next and probably merge for 3.6, so that we have a full round of linux-next for anyone to notice problems. Thanks! - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] mmc: dw_mmc: some fiex for hosw driver
Hi, On Tue, May 22 2012, Will Newton wrote: On Tue, May 22, 2012 at 5:00 AM, Seungwon Jeon tgih@samsung.com wrote: This patch-set includes fixes for the Synopsys DesignWare MMC driver Changes in v2: - fix the error handling(mmc: dw_mmc: fix the IDMAC sw reset) Seungwon Jeon (4): mmc: dw_mmc: fix the transmission handling in IDMAC mmc: dw_mmc: fix the IDMAC sw reset mmc: dw_mmc: fix the wrong sequence mmc: dw_mmc: correct the calculation for CLKDIV drivers/mmc/host/dw_mmc.c | 36 +++- 1 files changed, 19 insertions(+), 17 deletions(-) The v2 series looks good to me. Acked-by: Will Newton will.new...@gmail.com Thanks, I've pushed this patchset to mmc-next for 3.5. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap: Fix a section warning regression
Hi, On Mon, May 28 2012, Felipe Balbi wrote: On Sun, May 27, 2012 at 11:53:47PM -0700, Tony Lindgren wrote: Commit b6e0703b (mmc: omap: make it behave well as a module) made some __devinit changes but missed one function causing a section warning: WARNING: vmlinux.o(.devinit.text+0x8604): Section mismatch in reference from the function mmc_omap_probe) The function __devinit mmc_omap_probe() references a function __init mmc_omap_new_slot() Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Felipe Balbi ba...@ti.com Thanks, pushed to mmc-next for 3.5. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap: Fix NULL pointer dereference if mmc_omap_new_slot() fails
Hi, On Mon, May 28 2012, Tony Lindgren wrote: Commit b01a4f1c (mmc: omap: convert to per instance workqueue) initializes the workqueue too late causing the following: Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0Not tainted (3.4.0-08218-gb48b2c3 #158) PC is at __queue_work+0x8/0x46c LR is at queue_work_on+0x38/0x40 pc : [c005bb4c]lr : [c005c00c]psr: 6193 sp : c0691e1c ip : fp : c07374ac r10: c7aae400 r9 : c0395700 r8 : 0100 r7 : c0691e70 r6 : r5 : r4 : c7aae440 r3 : 0001 r2 : c7aae440 r1 : r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00c5387d Table: 80004000 DAC: 0017 Process swapper/0 (pid: 0, stack limit = 0xc06902f8) Stack: (0xc0691e1c to 0xc0692000) Fix this by initializing the workqueue before mmc_omap_remove_slot() get called. Tested on n770, looks like n800 at least still has some other issue with MMC. Signed-off-by: Tony Lindgren t...@atomide.com Thanks, pushed to mmc-next for 3.5. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap: Fix broken reg_shift initialization
Hi, On Wed, May 30 2012, Tony Lindgren wrote: Commit fa550189 (mmc: core: Prevent eMMC VCC supply to be cut from late init) slightly affected timings for how things are done for the omap MMC driver causing the MMC cards not getting detected any longer. Turns out this was caused by buggy reg_shift initialization in the omap MMC driver that was happening after mmc_add_host() was being called. Fix this by initializing reg_shift before mmc_add_host() is called. Signed-off-by: Tony Lindgren t...@atomide.com --- Heh found it! Chris, maybe Cc stable on this one? Thanks, pushed to mmc-next for 3.5 with a stable@ tag added. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: core: fix wrong return value when suspend
Hi, On Thu, May 31 2012, Ulf Hansson wrote: On 31 May 2012 19:31, Jaehoon Chung jh80.ch...@samsung.com wrote: When mmc_host is not spi mode, mmc/sd is doing mmc_deselect_cards(). mmc_deselect_cards could be returned error. If returned error, we can know something wrong when enter suspend. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com This make sense to me! Acked-by: Ulf Hansson ulf.hans...@linaro.org Thanks, pushed to mmc-next for 3.5. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH REPOST 1/2] mmc: tegra: use bus-width property instead of support-8bit
On Mon, Jun 04, 2012 at 12:32:34PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Update the driver to parse the new unified bus-width property introduced in commit 7f21779 mmc: dt: Consolidate DT bindings, instead of the legacy support-8bit property. Signed-off-by: Stephen Warren swar...@nvidia.com --- Chris, It's probably easiest conflict-wise if I take this through the Tegra tree. (Note: When I posted this series before, I said there shouldn't be any conflicts if you take them through the MMC tree. That's probably still true, but unforseen future conflicts seem more likely in the .dts files in the second patch than sdhci-tegra.c in this patch, so the Tegra tree may make more sense). Since the second patch depends on the first, it's easiest if these go in through the same tree. Does this sound OK? Yes, makes sense -- taking this via the Tegra tree is fine: Acked-by: Chris Ball c...@laptop.org Thanks! - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: mxs-mmc: Move of_match_table out of CONFIG_PM
Hi,
On Mon, May 21 2012, Marek Vasut wrote:
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Shawn Guo shawn@linaro.org
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: linux-mmc@vger.kernel.org
Cc: Chris Ball c...@laptop.org
Acked-by: Shawn Guo shawn@linaro.org
---
drivers/mmc/host/mxs-mmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 34a9026..277161d 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -894,8 +894,8 @@ static struct platform_driver mxs_mmc_driver = {
.owner = THIS_MODULE,
#ifdef CONFIG_PM
.pm = mxs_mmc_pm_ops,
- .of_match_table = mxs_mmc_dt_ids,
#endif
+ .of_match_table = mxs_mmc_dt_ids,
},
};
Thanks, pushed to mmc-next for 3.5.
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: mxs-mmc: Move of_match_table out of CONFIG_PM
Dear Chris Ball,
Hi,
On Mon, May 21 2012, Marek Vasut wrote:
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Shawn Guo shawn@linaro.org
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: linux-mmc@vger.kernel.org
Cc: Chris Ball c...@laptop.org
Acked-by: Shawn Guo shawn@linaro.org
---
drivers/mmc/host/mxs-mmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 34a9026..277161d 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -894,8 +894,8 @@ static struct platform_driver mxs_mmc_driver = {
.owner = THIS_MODULE,
#ifdef CONFIG_PM
.pm = mxs_mmc_pm_ops,
- .of_match_table = mxs_mmc_dt_ids,
#endif
+ .of_match_table = mxs_mmc_dt_ids,
},
};
Thanks, pushed to mmc-next for 3.5.
Thanks!
- Chris.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/1] mmc: block: Add MMC write packing statistics
On Wed, Jun 06, 2012 at 12:02:10PM +0530, Rahul Bedarkar wrote:
+static ssize_t mmc_wr_pack_stats_read(struct file *filp, char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ struct mmc_card *card = filp-private_data;
+ struct mmc_wr_pack_stats *pack_stats;
+ int i;
Best practice is to initialize variables at the time of declaration,
even if you initialize it before using. Many times we forget to do
that and there could be logical errors.
gcc will often emit a warning if a variable is used before
initialization. There seems to be a trend amongst kernel developers
to eschew redundant initializations, since they do actually generate
code. In fact, there is a macro 'uninitialized_var(x)' to suppress
the warning from the compiler when it is incorrect, so that a variable
doesn't have to be initialized when not really needed.
Outside of the kernel, though, I would otherwise agree with you.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH REPOST 1/2] mmc: tegra: use bus-width property instead of support-8bit
On 06/06/2012 07:56 AM, Chris Ball wrote: On Mon, Jun 04, 2012 at 12:32:34PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Update the driver to parse the new unified bus-width property introduced in commit 7f21779 mmc: dt: Consolidate DT bindings, instead of the legacy support-8bit property. Signed-off-by: Stephen Warren swar...@nvidia.com --- Chris, It's probably easiest conflict-wise if I take this through the Tegra tree. (Note: When I posted this series before, I said there shouldn't be any conflicts if you take them through the MMC tree. That's probably still true, but unforseen future conflicts seem more likely in the .dts files in the second patch than sdhci-tegra.c in this patch, so the Tegra tree may make more sense). Since the second patch depends on the first, it's easiest if these go in through the same tree. Does this sound OK? Yes, makes sense -- taking this via the Tegra tree is fine: Acked-by: Chris Ball c...@laptop.org Thanks. I have applied the series. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/1] block: Add test-iosched scheduler
The test scheduler allows testing a block device by dispatching specific requests according to the test case and declare PASS/FAIL according to the requests completion error code Changes in v2: - Export test-iosched functionality to allow definition of the block device tests under the block device layer - Add registration of block device tests utilities Maya Erez (1): block: Add test-iosched scheduler Documentation/block/test-iosched.txt | 39 ++ block/Kconfig.iosched|8 + block/Makefile |1 + block/blk-core.c |3 +- block/test-iosched.c | 1025 ++ include/linux/test-iosched.h | 218 +++ 6 files changed, 1292 insertions(+), 2 deletions(-) create mode 100644 Documentation/block/test-iosched.txt create mode 100644 block/test-iosched.c create mode 100644 include/linux/test-iosched.h -- 1.7.3.3 -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] block: Add test-iosched scheduler
The test scheduler allows testing a block device by dispatching
specific requests according to the test case and declare PASS/FAIL
according to the requests completion error code
Signed-off-by: Maya Erez me...@codeaurora.org
diff --git a/Documentation/block/test-iosched.txt
b/Documentation/block/test-iosched.txt
new file mode 100644
index 000..75d8134
--- /dev/null
+++ b/Documentation/block/test-iosched.txt
@@ -0,0 +1,39 @@
+Test IO scheduler
+==
+
+The test scheduler allows testing a block device by dispatching
+specific requests according to the test case and declare PASS/FAIL
+according to the requests completion error code.
+
+The test IO scheduler implements the no-op scheduler operations, and uses
+them in order to dispatch the non-test requests when no test is running.
+This will allow to keep a normal FS operation in parallel to the test
+capability.
+The test IO scheduler keeps two different queues, one for real-world requests
+(inserted by the FS) and the other for the test requests.
+The test IO scheduler chooses the queue for dispatch requests according to the
+test state (IDLE/RUNNING).
+
+the test IO scheduler is compiled by default as a dynamic module and enabled
+only if CONFIG_DEBUG_FS is defined.
+
+Each block device test utility that would like to use the test-iosched test
+services, should register as a blk_dev_test_type and supply an init and exit
+callbacks. Those callback are called upon selection (or removal) of the
+test-iosched as the active scheduler. From that point the block device test
+can start a test and supply its own callbacks for preparing, running, result
+checking and cleanup of the test.
+
+Each test is exposed via debugfs and can be triggered by writing to
+the debugfs file. In order to add a new test one should expose a new debugfs
+file for the new test.
+
+Selecting IO schedulers
+---
+Refer to Documentation/block/switching-sched.txt for information on
+selecting an io scheduler on a per-device basis.
+
+
+May 10 2012, maya Erez me...@codeaurora.org
+
+
diff --git a/block/Kconfig.iosched b/block/Kconfig.iosched
index 421bef9..34a1f9e 100644
--- a/block/Kconfig.iosched
+++ b/block/Kconfig.iosched
@@ -12,6 +12,14 @@ config IOSCHED_NOOP
that do their own scheduling and require only minimal assistance from
the kernel.
+config IOSCHED_TEST
+ tristate Test I/O scheduler
+ depends on DEBUG_FS
+ default m
+ ---help---
+ The test I/O scheduler is duplicate of the noop scheduler with
+ test ability.
+
config IOSCHED_DEADLINE
tristate Deadline I/O scheduler
default y
diff --git a/block/Makefile b/block/Makefile
index 39b76ba..436b220 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_BLK_DEV_THROTTLING) += blk-throttle.o
obj-$(CONFIG_IOSCHED_NOOP) += noop-iosched.o
obj-$(CONFIG_IOSCHED_DEADLINE) += deadline-iosched.o
obj-$(CONFIG_IOSCHED_CFQ) += cfq-iosched.o
+obj-$(CONFIG_IOSCHED_TEST) += test-iosched.o
obj-$(CONFIG_BLOCK_COMPAT) += compat_ioctl.o
obj-$(CONFIG_BLK_DEV_INTEGRITY)+= blk-integrity.o
diff --git a/block/blk-core.c b/block/blk-core.c
index 3c923a7..f3c3b9e 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1072,8 +1072,6 @@ struct request *blk_get_request(struct request_queue *q,
int rw, gfp_t gfp_mask)
{
struct request *rq;
- BUG_ON(rw != READ rw != WRITE);
-
spin_lock_irq(q-queue_lock);
if (gfp_mask __GFP_WAIT)
rq = get_request_wait(q, rw, NULL);
@@ -1406,6 +1404,7 @@ void init_request_from_bio(struct request *req, struct
bio *bio)
req-ioprio = bio_prio(bio);
blk_rq_bio_prep(req-q, req, bio);
}
+EXPORT_SYMBOL(init_request_from_bio);
void blk_queue_bio(struct request_queue *q, struct bio *bio)
{
diff --git a/block/test-iosched.c b/block/test-iosched.c
new file mode 100644
index 000..942e2c5
--- /dev/null
+++ b/block/test-iosched.c
@@ -0,0 +1,1025 @@
+
+/* Copyright (c) 2012, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * The test scheduler allows to test the block device by dispatching
+ * specific requests according to the test case and declare PASS/FAIL
+ * according to the requests completion error code.
+ * Each test is exposed via debugfs and can be triggered by writing to
+ * the debugfs file.
+ *
+ */
+
+/* elevator test iosched */
+#include linux/blkdev.h
+#include linux/elevator.h
+#include linux/bio.h
+#include linux/module.h
Re: [RFC/PATCH 1/1] mmc: block: Add MMC write packing statistics
+
+ for (i = 1 ; i = max_num_of_packed_reqs ; ++i) {
This is something magical number for iterations. why can not we start
from
zero.
The statistics are kept in the array in the index that equals the number
of packed requests. Therefore, they are kept in the array in indexes 1 to
max num of packed reqs.
I will add a comment to explain that.
Thanks,
Maya Erez
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] mmc:sdio:guarantee setting card data bus width as 4-bit
Chris, Thanks, and very glad to hear this:-) Best Wishes, Yong Ding Operating Systems Engineering, Application Processor Systems Engineering -Original Message- From: Chris Ball [mailto:c...@laptop.org] Sent: Wednesday, June 06, 2012 9:24 PM To: Yong Ding Cc: linux-mmc@vger.kernel.org; Philip Rakity; o...@wizery.com; linus.wall...@linaro.org; ulf.hans...@stericsson.com; linux-ker...@vger.kernel.org Subject: Re: [PATCH v2] mmc:sdio:guarantee setting card data bus width as 4-bit Hi, On Tue, May 15 2012, yongd wrote: SDIO_CCCR_IF[1:0] in SDIO card is used for card data bus width setting as below, 00b: 1-bit bus 01b: Reserved 10b: 4-bit bus 11b: 8-bit bus(only for embedded SDIO) And sdio_enable_wide is for setting data bus width as 4-bit. But currently, it 1stly read the register, 2ndly OR' 1b with SDIO_CCCR_IF[1], and then write it back. As we can see, such way is based on such assumption that the SDIO_CCCR_IF[0] is always 0. Apparently, this is not right. Signed-off-by: yongd yo...@marvell.com --- drivers/mmc/core/sdio.c |7 +++ include/linux/mmc/sdio.h |2 ++ 2 files changed, 9 insertions(+) diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c index 13d0e95..7b528cf 100644 --- a/drivers/mmc/core/sdio.c +++ b/drivers/mmc/core/sdio.c @@ -218,6 +218,13 @@ static int sdio_enable_wide(struct mmc_card *card) if (ret) return ret; + if ((ctrl SDIO_BUS_WIDTH_MASK) + == SDIO_BUS_WIDTH_RESERVED) + printk(KERN_WARNING%s: SDIO_CCCR_IF is invalid: 0x%02X\n, + mmc_hostname(card-host), ctrl); + + /* set as 4-bit bus width */ + ctrl = ~SDIO_BUS_WIDTH_MASK; ctrl |= SDIO_BUS_WIDTH_4BIT; ret = mmc_io_rw_direct(card, 1, 0, SDIO_CCCR_IF, ctrl, NULL); diff --git a/include/linux/mmc/sdio.h b/include/linux/mmc/sdio.h index c9fe66c..17446d3 100644 --- a/include/linux/mmc/sdio.h +++ b/include/linux/mmc/sdio.h @@ -98,7 +98,9 @@ #define SDIO_CCCR_IF 0x07/* bus interface controls */ +#define SDIO_BUS_WIDTH_MASK 0x03/* data bus width setting */ #define SDIO_BUS_WIDTH_1BIT 0x00 +#define SDIO_BUS_WIDTH_RESERVED 0x01 #define SDIO_BUS_WIDTH_4BIT 0x02 #define SDIO_BUS_ECSI 0x20/* Enable continuous SPI interrupt */ #define SDIO_BUS_SCSI 0x40/* Support continuous SPI interrupt */ Thanks, pushed to mmc-next for 3.5. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
