Re: mmc: sdio: runtime PM and 8686 problems
Hi Joe, On Fri, Nov 18, 2011 at 10:53 AM, Joe Woodward j...@terrafix.co.uk wrote: Are these workarounds expected to be enough for runtime PM to just work? It definitely works for 12xx, and with Daniel's recent work merged I think it also works fine for the sd8686 (Daniel, PCMIIW). Ohad. -- 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: mmc_test: align max_seg_size
On 11/17/2011 04:56 AM, Sujit Reddy Thumma wrote: On 11/14/2011 4:34 PM, Per Forlin wrote: If max_seg_size is unaligned, mmc_test_map_sg() may create sg element sizes that are not aligned with 512 byte. Fix, align max_seg_size at mmc_test_area_init(). Signed-off-by: Per Forlinper.for...@stericsson.com --- drivers/mmc/card/mmc_test.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c index b038c4a..5848998 100644 --- a/drivers/mmc/card/mmc_test.c +++ b/drivers/mmc/card/mmc_test.c @@ -1581,6 +1581,7 @@ static int mmc_test_area_init(struct mmc_test_card *test, int erase, int fill) t-max_segs = test-card-host-max_segs; t-max_seg_sz = test-card-host-max_seg_size; +t-max_seg_sz -= t-max_seg_sz % 512; Shouldn't we align this to host-max_blk_size supported by controller? It's up to each test case to set the test transfer size. It's not necessary to align max_size but it wouldn't make any harm either. All tests use a multiple of 512 blocks, but this may be changed of course in the future to support large blocks. The max_seg_sz must be aligned otherwise the host driver may get sg-elements that are hard to handle, aligned to 1 byte in the worst case. The test case don't control how the transfer is sg-mapped. /Per -- 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: block: release host in case of error
On 11/17/2011 10:18 AM, Adrian Hunter wrote:
On 14/11/11 13:12, Per Forlin wrote:
Host is claimed as long as there are requests in the block queue
and all request are completed successfully. If an error occur release
the host in case someone else needs to claim it, for instance if the card
is removed during a transfer.
Signed-off-by: Per Forlin per.for...@stericsson.com
---
drivers/mmc/card/block.c | 37 +
1 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c80bb6d..c21fd2c 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1158,6 +1158,28 @@ static int mmc_blk_cmd_err(struct mmc_blk_data *md,
struct mmc_card *card,
return ret;
}
+/*
+ * This function should be called to resend a request after failure.
+ * Prepares and starts the request.
+ */
+static inline struct mmc_async_req *mmc_blk_resend(struct mmc_card *card,
+ struct mmc_queue *mq,
+ struct mmc_queue_req *mqrq,
+ int disable_multi,
+ struct mmc_async_req *areq)
+{
+/*
+ * Release host after failure in case the host is needed
+ * by someone else. For instance, if the card is removed the
+ * worker thread needs to claim the host in order to do mmc_rescan.
+ */
+mmc_release_host(card-host);
+mmc_claim_host(card-host);
Does this work? Won't the current thread win the race
to claim the host again?
Good question. I've tested it and I haven't seen any cases where current has
claimed the host again. Sujit has tested the patch as well.
But I can't say that your scenario can't happen. I will study the wake_up and
wait_queue code to see if I can find the answer.
Thanks,
Per
--
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: mmc: sdio: runtime PM and 8686 problems
Ohad, I'm assuming these changes have already made it to the mainline, and therefore are in the 3.2rc2 build I was testing... If not do you have links to the patches? Is there anything I can do to debug further the problems I'm seeing? Cheers, Joe -Original Message- From: Ohad Ben-Cohen o...@wizery.com To: Joe Woodward j...@terrafix.co.uk, Daniel Drake d...@laptop.org Cc: linux-mmc@vger.kernel.org Date: Fri, 18 Nov 2011 11:06:44 +0200 Subject: Re: mmc: sdio: runtime PM and 8686 problems Hi Joe, On Fri, Nov 18, 2011 at 10:53 AM, Joe Woodward j...@terrafix.co.uk wrote: Are these workarounds expected to be enough for runtime PM to just work? It definitely works for 12xx, and with Daniel's recent work merged I think it also works fine for the sd8686 (Daniel, PCMIIW). Ohad. -- 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 -- 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: mmc: sdio: runtime PM and 8686 problems
On Fri, Nov 18, 2011 at 12:00 PM, Joe Woodward j...@terrafix.co.uk wrote: I'm assuming these changes have already made it to the mainline, and therefore are in the 3.2rc2 build I was testing... Most probably, yeah. Is there anything I can do to debug further the problems I'm seeing? Let's wait for Daniel to take a look, as he got libertas and sd8686 working with SDIO runtime PM. -- 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 1/1] mmc:Extension of MMC Block IOCTL Command support for testing of non read/write Commands
Hi Arnd,
Please forgive me for a lengthy mail.
firstly, the Patch has not added testcases in kernel, but has added
support infrastructure for handling different commands. Function
names are misnomers and “.test_CMD0” should have instead been
“send_CMD0”.
I have tried to express my views in 2 questions:
Q1 : What all Commands can be sent using MMC block layer IOCTL ?
Currently it be used for sending only read/write commands.
Should it also not support non-data (read/write) commands ?
If Yes, then the “block.c” must be modified with few changes to
handle non-data commands by making the read/write code conditional.
Ex: Code snippet below has to be made conditional i.e. execute only
for read/write commands
data.sg = sg;
data.sg_len = 1;
data.blksz = idata-ic.blksz;
data.blocks = idata-ic.blocks;
sg_init_one(data.sg, idata-buf, idata-buf_bytes);
if (idata-ic.write_flag)
data.flags = MMC_DATA_WRITE;
else
data.flags = MMC_DATA_READ;
Q2 : Can I send CMD 9 (or any non-data command) via the mmc blk layer
IOCTL ? If not what are the issues ?
As of now non-data commands are not supported. So in order to send CMD
9, the card has to be brought to a certain known state by sending the
pre CMD 9 sequence.
As per the Specification, before sending CMD 9, the following commands
have to be sent
Pre-CMD 9 Sequence
CMD0 : Reset
CMD8 : Get ocr
CMD55 : App command
CMD41 :
CMD2 :
CMD3 :
The implementation for the above can be seen mmc.c file snippet shown below
CODE SNIPPET : linux/driver/core/mmc.c
/*
* Since we're changing the OCR value, we seem to
* need to tell some cards to go back to the idle
* state. We wait 1ms to give cards time to
* respond.
* mmc_go_idle is needed for eMMC that are asleep
*/
mmc_go_idle(host);
/* The extra bit indicates that we support high capacity */
err = mmc_send_op_cond(host, ocr | (1 30), rocr);
if (err)
goto err;
/*
* For SPI, enable CRC as appropriate.
*/
if (mmc_host_is_spi(host)) {
err = mmc_spi_set_crc(host, use_spi_crc);
if (err)
goto err;
}
/*
* Fetch CID from card.
*/
if (mmc_host_is_spi(host))
err = mmc_send_cid(host, cid);
else
err = mmc_all_send_cid(host, cid);
if (err)
goto err;
if (oldcard) {
if (memcmp(cid, oldcard-raw_cid, sizeof(cid)) != 0) {
err = -ENOENT;
goto err;
}
card = oldcard;
} else {
/*
* Allocate card structure.
*/
card = mmc_alloc_card(host, mmc_type);
if (IS_ERR(card)) {
err = PTR_ERR(card);
goto err;
}
card-type = MMC_TYPE_MMC;
card-rca = 1;
memcpy(card-raw_cid, cid, sizeof(card-raw_cid));
}
/*
* For native busses: set card RCA and quit open drain mode.
*/
if (!mmc_host_is_spi(host)) {
err = mmc_set_relative_addr(card);
if (err)
goto free_card;
mmc_set_bus_mode(host, MMC_BUSMODE_PUSHPULL);
}
if (!oldcard) {
/*
* Fetch CSD from card.
*/
err = mmc_send_csd(card, card-raw_csd);
if (err)
goto free_card;
err = mmc_decode_csd(card);
if (err)
goto free_card;
err = mmc_decode_cid(card); //send CMD9
if (err)
goto free_card;
}
From user space, in order to send CMD9, the above code snippet should
be available as a single stand alone function. As of now the mmc core
state machine has a single flow which is card enumeration. But if we
want to send stand alone commands from user space, the enumeration
flow has to be broken into single standalone functions specific to the
commands that is they have to send the pre command sequence and get
the card to the proper state to send the user specified command.
The command sent should also work in following scenarios:-
CASE 1 : Card enumerated, and ready for transfer
CASE 2 : Card is reset
CASE 3 : CMD 9 has been sent, now can I send CMD 8
On Thu, Nov 17, 2011 at 8:11 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 16 November 2011, Shashidhar Hiremath wrote:
The patch provides An infrastructure to test commands other than Read/Write
commands using the IOCTL interface.The Patch can be useful
Re: Oops on suspend with libertas SDIO (Linux 3.2-rc2)
On Thu, Nov 17, 2011 at 8:19 PM, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: [ Adding linux-pm mailing list to CC as well ] Thanks, Srivatsa S. Bhat On 11/17/2011 09:19 PM, Chris Ball wrote: Hi, On Thu, Nov 17 2011, Sven Neumann wrote: I've given 3.2-rc2 a try today and the kernel oopsed when going into suspend: [ 20.387912] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 20.408759] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 20.432966] libertas_sdio mmc0:0001:1: mmc0:0001:1: suspend: PM flags = 0x0 [ 20.439978] libertas_sdio mmc0:0001:1: Suspend without wake params -- powering down card [ 23.456061] libertas_sdio mmc0:0001:1: wlan0: command 0x0010 timed out [ 23.462626] libertas_sdio mmc0:0001:1: wlan0: Timeout submitting command 0x0010 [ 23.470026] libertas_sdio: Resetting card... [ 23.474140] [ cut here ] [ 23.479002] WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0x50/0x11c() [ 23.486045] sysfs group c05cb5c8 not found for kobject 'mmc0:0001:1' [ 23.492358] Modules linked in: libertas_sdio libertas pxamci [ 23.498091] [c000dbb4] (unwind_backtrace+0x0/0xec) from [c001ca10] (warn_slowpath_common+0x4c/0x64) [ 23.507467] [c001ca10] (warn_slowpath_common+0x4c/0x64) from [c001cabc] (warn_slowpath_fmt+0x30/0x40) [ 23.517021] [c001cabc] (warn_slowpath_fmt+0x30/0x40) from [c00d369c] (sysfs_remove_group+0x50/0x11c) [ 23.526504] [c00d369c] (sysfs_remove_group+0x50/0x11c) from [c0202ec4] (device_del+0x3c/0x1a4) [ 23.535437] [c0202ec4] (device_del+0x3c/0x1a4) from [c0295dfc] (sdio_remove_func+0x1c/0x2c) [ 23.544127] [c0295dfc] (sdio_remove_func+0x1c/0x2c) from [c0295110] (mmc_sdio_remove+0x44/0x78) [ 23.553161] [c0295110] (mmc_sdio_remove+0x44/0x78) from [c028f0e4] (mmc_stop_host+0xd0/0x22c) [ 23.562016] [c028f0e4] (mmc_stop_host+0xd0/0x22c) from [c0290578] (mmc_remove_host+0x18/0x2c) [ 23.570898] [c0290578] (mmc_remove_host+0x18/0x2c) from [bf019470] (if_sdio_reset_card_worker+0x18/0x2c [libertas_sdio]) [ 23.582138] [bf019470] (if_sdio_reset_card_worker+0x18/0x2c [libertas_sdio]) from [c00302fc] (process_one_work+0x260/0x3c8) [ 23.593594] [c00302fc] (process_one_work+0x260/0x3c8) from [c0030ac8] (worker_thread+0x224/0x458) [ 23.602816] [c0030ac8] (worker_thread+0x224/0x458) from [c0036a00] (kthread+0x80/0x88) [ 23.611078] [c0036a00] (kthread+0x80/0x88) from [c0009ca8] (kernel_thread_exit+0x0/0x8) [ 23.619409] ---[ end trace 78598ef84f325bdd ]--- [ 23.624011] Unable to handle kernel NULL pointer dereference at virtual address 000c [ 23.632079] pgd = c0004000 [ 23.634762] [000c] *pgd= [ 23.638351] Internal error: Oops: 17 [#1] PREEMPT [ 23.643016] Modules linked in: libertas_sdio libertas pxamci [ 23.648666] CPU: 0 Tainted: G W (3.2.0-rc2 #2) [ 23.654316] PC is at klist_put+0x18/0x9c [ 23.658213] LR is at device_del+0x50/0x1a4 [ 23.662287] pc : [c03ca8fc] lr : [c0202ed8] psr: a013 [ 23.662298] sp : c6569f18 ip : 4013 fp : c602e605 [ 23.673688] r10: r9 : bf019458 r8 : c602e600 [ 23.678876] r7 : r6 : c6447408 r5 : c64bbe50 r4 : 0001 [ 23.685363] r3 : r2 : 0200 r1 : 0001 r0 : 0001 [ 23.691844] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 23.699106] Control: 397f Table: a65a0018 DAC: 0035 [ 23.704817] Process kworker/0:2 (pid: 1204, stack limit = 0xc6568278) [ 23.711218] Stack: (0xc6569f18 to 0xc656a000) [ 23.715547] 9f00: c65fe008 c6447000 [ 23.723677] 9f20: c6447408 c0202ed8 c65fe008 c6447000 0084 c0295dfc 0001 c0295110 [ 23.731810] 9f40: c63e8f00 c6447000 6013 0009 c028f0e4 c6447000 c6447000 [ 23.739944] 9f60: c63e8f00 c0290578 bf019c9c bf019470 bf019af0 c00302fc c05c1b38 c63e8f00 [ 23.748076] 9f80: c05c1b38 c05c1b38 0009 c6568000 c63e8f10 c05c1b38 c63e8f10 c0030ac8 [ 23.756208] 9fa0: c6083f14 c6569fd4 c6083f14 c63e8f00 c00308a4 [ 23.764341] 9fc0: c0036a00 c0009ca8 c63e8f00 c6569fd8 c6569fd8 [ 23.772475] 9fe0: c6083f14 c0036980 c0009ca8 0013 c0009ca8 0340f30e 153b5900 [ 23.780618] [c03ca8fc] (klist_put+0x18/0x9c) from [c0202ed8] (device_del+0x50/0x1a4) [ 23.788675] [c0202ed8] (device_del+0x50/0x1a4) from [c0295dfc] (sdio_remove_func+0x1c/0x2c) [ 23.797327] [c0295dfc] (sdio_remove_func+0x1c/0x2c) from [c0295110] (mmc_sdio_remove+0x44/0x78) [ 23.806328] [c0295110] (mmc_sdio_remove+0x44/0x78) from [c028f0e4] (mmc_stop_host+0xd0/0x22c) [ 23.815148] [c028f0e4] (mmc_stop_host+0xd0/0x22c) from [c0290578] (mmc_remove_host+0x18/0x2c) [ 23.823987] [c0290578] (mmc_remove_host+0x18/0x2c) from [bf019470] (if_sdio_reset_card_worker+0x18/0x2c [libertas_sdio]) [ 23.835164] [bf019470] (if_sdio_reset_card_worker+0x18/0x2c [libertas_sdio]) from [c00302fc]
RE: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC 4.5
Hi Girish,
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Girish K S
Sent: Wednesday, October 26, 2011 10:30 AM
To: linux-mmc@vger.kernel.org
Cc: c...@laptop.org; patc...@linaro.org; linux-samsung-
s...@vger.kernel.org; Girish K S
Subject: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC 4.5
This patch adds the support of the HS200 bus speed for eMMC 4.5
devices.
The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core and
host modules have been touched to add support for this module.
It is necessary to know the card type in the sdhci.c file to add
support
for eMMC tuning function. So card.h file is included to import the card
data structure.
We don't need to know the card type in the host controller driver if we pass
the command opcode as the 2nd argument to execute_tuning() ops. Command
opcode can have have either CMD19 or CMD21 as it's value depending on the
card type (whether it's SD3.0 card or eMMC4.5 card).
cc: Chris Ball c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
Changes in v4:
Rebased onto chris-mmc/mmc-next branch. This patch is
successfully
applied on commit with id
de022ed3fdc14808299b2fa66dbb1ed5ab921912.
Changes in v3:
In the previous commits of chris-mmc/mmc-next branch, the patch
with
commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
caps2 for
more capabilities. This patch version deletes the member
ext_caps(created
in my earlier patch) from struct mmc_host and reuses already
accepted
caps2 member.
Changes in v2:
Rebased to latest chris-mmc/mmc-next branch. Resolved indentation
problems identified in review. This patch has to be applied
before
the patch released for modifying the printk messages.
Changes in v1:
Case statements in switch that produce same result have
been combined to reduce repeated assignments.
patch recreated after rebase to chris balls mmc-next branch.
drivers/mmc/core/bus.c|3 +-
drivers/mmc/core/mmc.c| 92
drivers/mmc/host/sdhci.c | 36 +++---
include/linux/mmc/card.h |3 +
include/linux/mmc/host.h |6 +++
include/linux/mmc/mmc.h |8 +++-
include/linux/mmc/sdhci.h |1 +
7 files changed, 132 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 46b6e84..2f82f6b 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
mmc_card_ddr_mode(card) ? DDR : ,
type);
} else {
- printk(KERN_INFO %s: new %s%s%s card at address %04x\n,
+ pr_info(%s: new %s%s%s%s card at address %04x\n,
mmc_hostname(card-host),
mmc_sd_card_uhs(card) ? ultra high speed :
(mmc_card_highspeed(card) ? high speed : ),
+ (mmc_card_hs200(card) ? HS200 : ),
mmc_card_ddr_mode(card) ? DDR : ,
type, card-rca);
}
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 3627044..4db248c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -285,6 +285,39 @@ static int mmc_read_ext_csd(struct mmc_card *card,
u8 *ext_csd)
}
card-ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
switch (ext_csd[EXT_CSD_CARD_TYPE] EXT_CSD_CARD_TYPE_MASK) {
+ case EXT_CSD_CARD_TYPE_SDR_200 |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_8V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_2V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_52 |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ card-ext_csd.hs_max_dtr = 2;
+ card-ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
+ break;
+ case EXT_CSD_CARD_TYPE_SDR_1_2V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_1_8V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_1_2V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_52 |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ card-ext_csd.hs_max_dtr = 2;
+ card-ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
+ break;
+ case EXT_CSD_CARD_TYPE_SDR_1_8V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case
Re: omap_hsmmc noisy/broken for suspend resume
Hello Girish, On 11/03/2011 09:21 PM, Girish K S wrote: On 3 November 2011 17:24, Kevin Hilman khil...@ti.com wrote: Hello, Using Linus' master branch, I was testing PM functionality on OMAP3/4 and noticed that the MMC driver is now rather noisy during suspend on OMAP3[1], but seems to work. [...] / # echo mem /sys/power/state [ 811.145507] PM: Syncing filesystems ... done. [ 811.150268] PM: Preparing system for mem sleep [ 811.155059] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 811.179992] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 811.203460] PM: Entering mem sleep [ 811.207489] Suspending console(s) (use no_console_suspend to debug) a[ 811.225860] [ cut here ] [ 811.225891] WARNING: at /work/kernel/omap/pm/drivers/mmc/core/core.c:453 mmc_wait_for_cmd+0x78/0x84() [ 811.225921] Modules linked in: [ 811.225952] [c001a810] (unwind_backtrace+0x0/0xf0) from [c00525d0] (warn_slowpath_common+0x4c/0x64) [ 811.225982] [c00525d0] (warn_slowpath_common+0x4c/0x64) from [c0052604] (warn_slowpath_null+0x1c/0x24) [ 811.226013] [c0052604] (warn_slowpath_null+0x1c/0x24) from [c033a494] (mmc_wait_for_cmd+0x78/0x84) [ 811.226043] [c033a494] (mmc_wait_for_cmd+0x78/0x84) from [c033e7b8] (mmc_switch+0x74/0x118) [ 811.226074] [c033e7b8] (mmc_switch+0x74/0x118) from [c033b034] (mmc_power_off+0xd8/0x108) The problem is caused by the card-poweroff_notify_state = MMC_POWERED_ON; statement in the mmc_card_init function it is set for the non eMMC4.5 devices. I will rectify this and soon send a patch for the same. Is this the patch that fixes this issue: http://article.gmane.org/gmane.linux.kernel.mmc/10961 I found this by digging (since I'm not subscribed to linux-mmc), but it would've been much more efficient if you Cc the original lists where the issue was reported, and especially the person reporting the bug so it can be tested by those reporting the problem. I tested the above patch and verified it gets rid of all the noise in the OMAP HS-MMC driver. Chris, I see this is already in mmc-next. Feel free to add: Tested-by: Kevin Hilman khil...@ti.com If you like. Thanks, Kevin -- 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
mmc0: Too large timeout requested for CMD38!
I am getting the following error when trying to use a swap file on a large 32GB SD card formated with EXT4. Thanks, Paul Schilling Swap file /external_flash_a/swap_file being enabled. mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! mmc0: Too large timeout requested for CMD38! Adding 131068k swap on /external_flash_a/swap_file. Priority:-1 extents:3 across:135104k SS Linux version 3.2.0-rc2+ (###) (gcc version 4.3.3 (GCC) ) #77 PREEMPT Fri Nov 18 13:37:37 CST 2011 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: CONDOR2416 Memory policy: ECC disabled, Data cache writeback CPU S3C2416/S3C2450 (id 0x32450003) S3C24XX Clocks, Copyright 2004 Simtec Electronics CPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 MHz CPU: EPLL on 96.000 MHz, usb-bus 48.000 MHz On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c051b06c, node_mem_map c055 Normal zone: 384 pages used for memmap Normal zone: 0 pages reserved Normal zone: 32384 pages, LIFO batch:7 pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32384 Kernel command line: console=ttySAC0,115200 loglevel=8 s3cfb=dev:0,depth:16,xres:480, yres:272,vslen:60,hslen:17,left:41,right:68,upper:26,lower:6,pixclock:0 root=/dev/mtdblock4 rw rootfstype=jffs2 ethaddr=12:23:34:88:99:00 PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB 64MB = 128MB total Memory: 124472k/124472k available, 6600k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xcc80 - 0xf600 ( 664 MB) lowmem : 0xc000 - 0xcc00 ( 192 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc0492ec4 (4652 kB) .init : 0xc0493000 - 0xc04f2000 ( 380 kB) .data : 0xc04f2000 - 0xc051b700 ( 166 kB) .bss : 0xc051b724 - 0xc054f6c4 ( 208 kB) SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS:99 irq: clearing subpending status 0002 timer tcon=0050, tcnt 2b66, tcfg 0200,, usec 170a Console: colour dummy device 80x30 Calibrating delay loop... 197.88 BogoMIPS (lpj=98944) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 s3c_fb_setup: option dev:0 s3c_fb_setup: option depth:16 s3c_fb_setup: option xres:480 s3c_fb_setup: option yres:272 s3c_fb_setup: option vslen:60 s3c_fb_setup: option hslen:17 s3c_fb_setup: option left:41 s3c_fb_setup: option right:68 s3c_fb_setup: option upper:26 s3c_fb_setup: option lower:6 s3c_fb_setup: option pixclock:0 Condor2416: Start Set DM9K S3C Power Management, Copyright 2004 Simtec Electronics S3C2416: Initializing architecture S3C2416: IRQ Support S3C24XX DMA Driver, Copyright 2003-2006 Simtec Electronics DMA channel 0 at cc804000, irq 88 DMA channel 1 at cc804100, irq 89 DMA channel 2 at cc804200, irq 90 DMA channel 3 at cc804300, irq 91 DMA channel 4 at cc804400, irq 92 DMA channel 5 at cc804500, irq 93 s3c24xx-pwm s3c24xx-pwm.0: tin at , tdiv at , tin=divclk, base 0 bio: create slab bio-0 at 0 usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb s3c-i2c s3c2410-i2c: slave address 0x10 s3c-i2c s3c2410-i2c: bus frequency set to 65 KHz s3c-i2c s3c2410-i2c: i2c-0: S3C I2C adapter Advanced Linux Sound Architecture Driver Version 1.0.24. NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. s3c-adc s3c-adc: attached adc driver VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 1024
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
* Rajendra Nayak rna...@ti.com [14 19:40]:
On Tuesday 15 November 2011 03:00 AM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [04 04:16]:
@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_mmc_of_match,pdev-dev);
+ if (match) {
+ pdata = of_get_hsmmc_pdata(pdev-dev);
+ if (match-data)
+ pdata-reg_offset = *(u16 *)match-data;
+ }
So this is now using both DT and pdata?
We want to use DT only, and get rid of pdata. Other than the
deferred probe, is there some other dependency remaining to
having to use the pdata also?
We are using pdata today mainly for the platform function pointers
that get passed for MMC, which can never be passed from DT.
The omap_mmc_platform_data structure today has '17' function pointers.
Most might be sparingly used, nevertheless, its an awfully large number.
Yeah OK.
Here's the list...
-
int (*switch_slot)(struct device *dev, int slot);
int (*init)(struct device *dev);
void (*cleanup)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*suspend)(struct device *dev, int slot);
int (*resume)(struct device *dev, int slot);
int (*get_context_loss_count)(struct device *dev);
per-slot functions
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
int (*set_power)(struct device *dev, int slot,
int power_on, int vdd);
int (*get_ro)(struct device *dev, int slot);
int (*set_sleep)(struct device *dev, int slot, int sleep,
int vdd, int cardsleep);
void (*remux)(struct device *dev, int slot, int power_on);
void (*before_set_reg)(struct device *dev, int slot,
int power_on, int vdd);
void (*after_set_reg)(struct device *dev, int slot,
int power_on, int vdd);
void (*init_card)(struct mmc_card *card);
int (*get_cover_state)(struct device *dev, int slot);
int (*card_detect)(struct device *dev, int slot);
-
To me it seems we should move these into drivers/mmc/host/omap_hsmmc.c
and set them based on DT compatible (or some other) property.
If these functions tinker with some internal registers, then we need
to fix those too to use regulator/gpio API.
This way we don't need the platform_data any longer.
Regards,
Tony
--
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 1/1] [PATCH v4 1/1] mmc: Support of DUAL BUFFER DESC[ring] mode for dw_mmc
Hi Shashidhar, On Mon, Nov 14, 2011 at 09:32:25PM +0530, Shashidhar Hiremath wrote: Hi Will, Just following up since i did not see any response from you on my earlier mail.. In previous mail, im not sure whether i gave you enough context/background.. So here it goes (apologies in advance if this turns out to be a lengthy mail...): 1At Vayavya Labs, our work is to make sure that drivers for SNPS designware IP is available in kernel.org. One of the mandates/requirements from SNPS is that the driver submitted to kernel.org should support all the features/configurations of the IP. The bigger picture being that once this is done, SNPS customers dont have to write code for any specific feature/configuration since it is already available in the driver and they can start using it immediately... 2As such, it is required that code for dual descriptors be also present in the driver submitted to kernel.org.. In future there, there could be some person wanting to use this feature of the IP.. 3Also note that in kconfig, there does not have to be a choice between this mode and chained mode since the default will always be chained mode. STM Ethernet MAC driver already has such a kind of support.. If this is not acceptable, do you feel the code should be wrapped in some totally different preprocessor directive with comments in the driver explaining the same? 4With regards to your points on performance, I am open to look at it and see where we can make improvements in the driver (if any... if its a hardware thing, there is not much we can do) Can I suggest you try running mmc_test with and without the dual descriptor mode. It has a bunch of performance tests in it. Cheers James Do let me know your views. best regards --Shashidhar Hiremath On Fri, Nov 4, 2011 at 12:36 PM, Shashidhar Hiremath shashidh...@vayavyalabs.com wrote: Hi Will, I agree with you that it should not be merged unless it improves the performance. But I still feel that there might be some reason for which the IP Vendor has provided an additional feature. So will this not be a good feature to have as it will help in IP Validation for different modes. As far as the Kconfig option is concerned, the user need not always modify it since the default case will still be Chained Mode. Also Such Kconfig options for selecting mode is already used for stmmac Ethernet Drivers. On Thu, Nov 3, 2011 at 8:48 PM, Will Newton will.new...@gmail.com wrote: On Thu, Nov 3, 2011 at 12:35 PM, Chris Ball c...@laptop.org wrote: Hi, On Thu, Nov 03 2011, Shashidhar Hiremath wrote: Hi Chris, Can this patch be accepted by criteria that its an additional feature supported by the hardware and hence good to have the support in the driver.Also note the patch has been tested. I think Will and James should make the call on that. My own opinion is that it's not usually a good idea to merge code that increases complexity for no performance gain; if the feature is actually important, someone should find a way to finish it and measure a performance gain (the gain can be in any of bandwidth, memory, or lower CPU utilization) with it, to prove that the change is worthwhile. I'm inclined to agree. I don't want to feel like I am blocking inclusion of anyone's hard work, but unless there is a clear advantage for one option over the other I can't see a good reason for merging it. At present it adds a question to the Kconfig that is pretty much impossible for the user to answer (do I turn this feature on or off? what is the advantage of choosing each option?). -- regards, Shashidhar Hiremath -- regards, Shashidhar Hiremath -- 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 -- 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
