Re: [PATCH] mmc: omap_hsmmc: fix max value of clkd
On Fri, Sep 21, 2012 at 8:51 PM, Balaji T K balaj...@ti.com wrote:
clock divisor can take a max value of 1023
update code as per TRM so that card init can be handled with
higher IP clock frequencies from which clock to the card is
derived.
This is difficult to read without some punctuation / capitalization.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d9af5f1..073b9ff 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -75,6 +75,7 @@
#define ICE0x1
#define ICS0x2
#define CEN(1 2)
+#define CLKD_MAX 0x3FF
It'd be nice to have a comment on what 3FF stands for and it's
relation to clock in MHz.
#define CLKD_MASK 0xFFC0
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
@@ -478,8 +479,8 @@ static u16 calc_divisor(struct omap_hsmmc_host *host,
struct mmc_ios *ios)
if (ios-clock) {
dsor = DIV_ROUND_UP(clk_get_rate(host-fclk), ios-clock);
- if (dsor 250)
- dsor = 250;
+ if (dsor CLKD_MAX)
+ dsor = CLKD_MAX;
Can these two lines be written in one line as
dsor = CLKD_MAX; ?
}
--
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 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter mpor...@ti.com wrote: The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. Since the EDMA DMA Engine driver sets the maximum segments to 16, we do the same. Note: this can be removed once the DMA Engine API supports an API to query the DMAC's segment limitations. I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch suggests. Why don't we have a max_segs property, which when explicitly specified in DT, will override the default ? -- 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 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman svenk...@ti.com wrote: On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter mpor...@ti.com wrote: The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. Since the EDMA DMA Engine driver sets the maximum segments to 16, we do the same. Note: this can be removed once the DMA Engine API supports an API to query the DMAC's segment limitations. I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch suggests. Why don't we have a max_segs property, which when explicitly specified in DT, will override the default ? If you are adventurous, this can be a generic mmc DT binding instead of restricting it to OMAP. -- 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 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
On Fri, Sep 21, 2012 at 10:48 PM, Felipe Balbi ba...@ti.com wrote: On Fri, Sep 21, 2012 at 10:47:30PM +0530, S, Venkatraman wrote: On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman svenk...@ti.com wrote: On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter mpor...@ti.com wrote: The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. Since the EDMA DMA Engine driver sets the maximum segments to 16, we do the same. Note: this can be removed once the DMA Engine API supports an API to query the DMAC's segment limitations. I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch suggests. Why don't we have a max_segs property, which when explicitly specified in DT, will override the default ? If you are adventurous, this can be a generic mmc DT binding instead of restricting it to OMAP. I say if it's a limitation in the DMAC, then DMAC's driver should handle it, no ? Meaning that in this case you would copy from one multi-segment sg into a one-segment sg and when transfer is complete, before calling user's callback, copy data the other way around (?) Right ! So even if the property is defined for MMC, Matt will end up coding the limitation into every peripheral driver that uses EMAC, which doesn't scale. Your solution is better. -- 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 3/4] drivers/mmc/host/omap_hsmmc.c: fix error return code
On Mon, Sep 17, 2012 at 1:45 PM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
From: Peter Senna Tschudin peter.se...@gmail.com
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Looks good.
Acked-by: Venkatraman S svenk...@ti.com
--
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: omap_hsmmc: Pass on the suspend failure to the PM core
On Thu, Sep 13, 2012 at 12:01 PM, Hebbar, Gururaja
gururaja.heb...@ti.com wrote:
From: Vaibhav Bedia vaibhav.be...@ti.com
In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core returns
-EBUSY to the host controller driver. Unfortunately, the
host controller driver does not pass on this information
to the PM core and hence the system suspend process continues.
ret = mmc_suspend_host(host-mmc);
if (ret) {
host-suspended = 0;
if (host-pdata-resume) {
ret = host-pdata-resume(dev, host-slot_id);
The return status from mmc_suspend_host() is overwritten by return
status from host-pdata-resume. So the original return status is lost.
In these cases the MMC core gets to an unexpected state
during resume and multiple issues related to MMC crop up.
1. Host controller driver starts accessing the device registers
before the clocks are enabled which leads to a prefetch abort.
2. A file copy thread which was launched before suspend gets
stuck due to the host not being reclaimed during resume.
To avoid such problems pass on the -EBUSY status to the PM core
from the host controller driver. With this change, MMC core
suspend might still fail but it does not end up making the
system unusable. Suspend gets aborted and the user can try
suspending the system again.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
This version is good.
Acked-by: Venkatraman S svenk...@ti.com
---
Changes from V1:
- Instead of forcibly returning -EBUSY on err, retain old
status and pass on the same to the caller.
- add more detail to commit message (explanation with code
snippet)
:100644 100644 9afdd20... d9af5f1... M drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/omap_hsmmc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9afdd20..d9af5f1 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2050,8 +2050,7 @@ static int omap_hsmmc_suspend(struct device *dev)
if (ret) {
host-suspended = 0;
if (host-pdata-resume) {
- ret = host-pdata-resume(dev, host-slot_id);
- if (ret)
+ if (host-pdata-resume(dev, host-slot_id))
dev_dbg(dev, Unmask interrupt failed\n);
}
goto err;
--
1.7.0.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: omap_hsmmc: Enable HSPE bit for high speed cards
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz The patch is well written. But then, I don't see a need for a DT binding for this feature. By definition, HS implies 25MHz or above, so that check seems to be redundant as well. Meanwhile, I'll check with HSPE enabled on OMAP. Regards, Venkat. -- 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_hsmmc: Pass on the suspend failure to the PM core
On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: From: Vaibhav Bedia vaibhav.be...@ti.com In some cases mmc_suspend_host() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. The last time we discussed this, didn't we plan to fix this differently ? Holding the return code of mmc_suspend_host in a separate variable and passing it to the caller of omap_hsmmc_suspend looks more sane to me. -- 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: [PATCHv2 1/2] mmc: omap_hsmmc: convert from IP timer to hrtimer
On Sat, Sep 8, 2012 at 3:29 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Venkatraman S svenk...@ti.com writes: omap hsmmc controller IP has a built in timer that can be programmed to guard against unresponsive operations. But its range is very narrow, and the maximum countable time is a few seconds. Card maintenance operations like BKOPS and MMC_ERASE and long stream writes like packed command require timers of order of several minutes, much beyond the capability of the IP timer. So get rid of using the IP timer entirely and use kernel's hrtimer functionality for guarding the device operations. As part of this change, a workaround that disabled timeouts for MMC_ERASE command is removed, and the arbitary timing of 100ms is used only when the timeout is not explicitly specified by core. A trivial change to get rid of unnecessary dealiasing of host-data in omap_hsmmc_do_irq is also included. Signed-off-by: Venkatraman S svenk...@ti.com Dumb question: if the timers needed are on the order of minutes, why do you need to use high-resolution timers? I'm guessing the normal kernel-internal timers should suffice here (see linux/timer.h, init_timer().) Both sub ms and long duration timers are needed, based on the type of operation. The eMMC standard has evolved to define new commands which require such long duration operations. The short (control) commands do need high precision. Also, if they're on the order of minutes, I assume the actual firing doesn't have to be precise, so deferrable timers can probably be used (and thus help PM by coalescing wakeup events.) If my assumptions are true, it might be worth considering using the normal timers, and use init_timer_deferrable(). I'll certainly look into this. One way is to use the IP timer for short commands and deferrable timers for long ones - but I reckon it would be messy. I've actually put this patch on hold - as someone pointed out to me that this violates some sections of eMMC spec. 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
Re: [PATCH v2 1/1] mmc: block: Add write packing control
On Mon, Aug 27, 2012 at 11:58 PM, me...@codeaurora.org wrote:
On Fri, July 27, 2012 2:07 am, S, Venkatraman wrote:
On Fri, Jul 27, 2012 at 12:24 AM, me...@codeaurora.org wrote:
On Thu, July 26, 2012 8:28 am, S, Venkatraman wrote:
On Tue, Jul 24, 2012 at 2:14 PM, me...@codeaurora.org wrote:
On Mon, July 23, 2012 5:22 am, S, Venkatraman wrote:
On Mon, Jul 23, 2012 at 5:13 PM, me...@codeaurora.org wrote:
On Wed, July 18, 2012 12:26 am, Chris Ball wrote:
Hi, [removing Jens and the documentation list, since now we're
talking about the MMC side only]
On Wed, Jul 18 2012, me...@codeaurora.org wrote:
Is there anything else that holds this patch from being pushed to
mmc-next?
Yes, I'm still uncomfortable with the write packing patchsets for a
couple of reasons, and I suspect that the sum of those reasons means
that
we should probably plan on holding off merging it until after 3.6.
Here are the open issues; please correct any misunderstandings:
With
Seungwon's patchset (Support packed write command):
* I still don't have a good set of representative benchmarks
showing
what kind of performance changes come with this patchset. It
seems
like we've had a small amount of testing on one controller/eMMC part
combo
from Seungwon, and an entirely different test from Maya, and the
results
aren't documented fully anywhere to the level of describing what the
hardware was, what the test was, and what the results were before and
after the patchset.
Currently, there is only one card vendor that supports packed
commands.
Following are our sequential write (LMDD) test results on 2 of our
targets
(in MB/s):
No packingpacking
Target 1 (SDR 50MHz) 15 25
Target 2 (DDR 50MHz) 20 30
With the reads-during-writes regression:
* Venkat still has open questions about the nature of the read
regression, and thinks we should understand it with blktrace
before
trying to fix it. Maya has a theory about writes overwhelming
reads,
but
Venkat doesn't understand why this would explain the observed
bandwidth drop.
The degradation of read due to writes is not a new behavior and
exists
also without the write packing feature (which only increases the
degradation). Our investigation of this phenomenon led us to the
Conclusion that a new scheduling policy should be used for mobile
devices,
but this is not related to the current discussion of the write
packing
feature.
The write packing feature increases the degradation of read due to
write
since it allows the MMC to fetch many write requests in a row,
instead
of
fetching only one at a time. Therefore some of the read requests
will
have to wait for the completion of more write requests before they can
be
issued.
I am a bit puzzled by this claim. One thing I checked carefully when
reviewing write packing patches from SJeon was that the code didn't
plough through a mixed list of reads and writes and selected only
writes.
This section of the code in mmc_blk_prep_packed_list(), from v8
patchset..
Quote
+ if (rq_data_dir(cur) != rq_data_dir(next)) {
+ put_back = 1;
+ break;
+ }
/Quote
means that once a read is encountered in the middle of write packing,
the packing is stopped at that point and it is executed. Then the next
blk_fetch_request should get the next read and continue as before.
IOW, the ordering of reads and writes is _not_ altered when using
packed
commands.
For example if there were 5 write requests, followed by 1 read,
followed by 5 more write requests in the request_queue, the first 5
writes will be executed as one packed command, then the read will be
executed, and then the remaining 5 writes will be executed as one
packed command. So the read does not have to wait any more than it
waited before (packing feature)
Let me try to better explain with your example.
Without packing the MMC layer will fetch 2 write requests and wait for
the
first write request completion before fetching another write request.
During this time the read request could be inserted into the CFQ and
since
it has higher priority than the async write it will be dispatched in
the
next fetch. So, the result would be 2 write requests followed by one
read
request and the read would have to wait for completion of only 2 write
requests.
With packing, all the 5 write requests will be fetched in a row, and
then
the read will arrive and be dispatched in the next fetch. Then the
read
will have to wait for the completion of 5 write requests.
Few more clarifications:
Due to the plug list mechanism in the block layer the applications can
aggregate several requests to be inserted into the scheduler before
waking the MMC queue thread.
This leads to a situation where there are several write requests in
the
CFQ queue when MMC starts to do the fetches.
If the read was inserted
Re: [PATCH 07/10] mmc: omap_hsmmc: consolidate flush posted writes for HSMMC IRQs
On Tue, Aug 21, 2012 at 8:51 PM, T Krishnamoorthy, Balaji
balaj...@ti.com wrote:
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S svenk...@ti.com wrote:
Flushing spurious IRQs from HSMMC IP is done twice in
omap_hsmmc_irq and omap_hsmmc_do_irq.
spurious IRQ is flushed in start of omap_hsmmc_do_irq
and irq acked at the end of omap_hsmmc_do_irq
Consolidate them to one location.
if you wanted to consolidated ...
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4bc55ac..20453c8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -969,15 +969,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
struct mmc_data *data;
int end_cmd = 0, end_trans = 0;
- if (!host-req_in_progress) {
just do a return from here
I think it's still better to filter out the validation to the outer
function and let do_irq to just 'do' it.
- do {
- OMAP_HSMMC_WRITE(host-base, STAT, status);
- /* Flush posted write */
- status = OMAP_HSMMC_READ(host-base, STAT);
- } while (status INT_EN_MASK);
- return;
- }
-
data = host-data;
dev_vdbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
@@ -1028,8 +1019,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
}
- OMAP_HSMMC_WRITE(host-base, STAT, status);
-
if (end_cmd || ((status CC) host-cmd))
omap_hsmmc_cmd_done(host, host-cmd);
if ((end_trans || (status TC)) host-mrq)
@@ -1045,11 +1034,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- do {
+ while (status INT_EN_MASK host-req_in_progress) {
and remove the check for host-req_in_progress
I think do while loop can be retained as it will get executed once anyway.
It's a minor issue, and the consolidation of the check for
req_in_progress makes sure that it might
sometimes be not executed at all..
omap_hsmmc_do_irq(host, status);
+
/* Flush posted write */
comment is misplaced
Ok. I'll remove.
+ OMAP_HSMMC_WRITE(host-base, STAT, status);
status = OMAP_HSMMC_READ(host-base, STAT);
- } while (status INT_EN_MASK);
+ }
return IRQ_HANDLED;
}
--
1.7.11.1.25.g0e18bef
--
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 06/10] mmc: omap_hsmmc: remove access to SYSCONFIG register
On Tue, Aug 21, 2012 at 9:08 PM, Shubhrajyoti Datta
omaplinuxker...@gmail.com wrote:
Hi Venkat,
Some doubts below.
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S svenk...@ti.com wrote:
SYSCONFIG register of HSMMC IP is managed by the omap hwmod
abstraction layer.
At init only right?
Yes.
Resetting the IP and configuring the correct
SYSCONFIG mode is centrally managed by hwmod.
Remove code which manipulates IP reset and SYSCONFIG directly in the
driver.
I am not sure if mmc needs a reset.
Actually it doesn't, as far as I know. That's why I propose it to be removed.
However IMHO
In case it needs a reset
the hwmod way could be to use omap_hwmod_reset
However I fear it may be an issue with dt.
or
may be sysc could be restored something like [1]
if it doesnt need reset even the check for the SYSSTATUS could be
considered for removal.
[1] http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg12041.html
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index da4f5a7..4bc55ac 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -44,7 +44,6 @@
#include plat/cpu.h
/* OMAP HSMMC Host Controller Registers */
-#define OMAP_HSMMC_SYSCONFIG 0x0010
#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
#define OMAP_HSMMC_BLK 0x0104
@@ -576,21 +575,8 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
if (host-context_loss == context_loss)
return 1;
- /* Wait for hardware reset */
- timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE) !=
RESETDONE
-time_before(jiffies, timeout))
- ;
-
- /* Do software reset */
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET);
- timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE) !=
RESETDONE
-time_before(jiffies, timeout))
- ;
-
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ if (!OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE)
+ return 1;
Should this check be removed.
No - it's still needed to check that the IP is ready for use.
if (host-pdata-controller_flags OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
if (host-power_mode != MMC_POWER_OFF
@@ -1593,10 +1579,6 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
value = OMAP_HSMMC_READ(host-base, CAPA);
OMAP_HSMMC_WRITE(host-base, CAPA, value | capa);
- /* Set the controller to AUTO IDLE mode */
- value = OMAP_HSMMC_READ(host-base, SYSCONFIG);
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG, value | AUTOIDLE);
-
/* Set SD bus power bit */
set_sd_bus_power(host);
}
@@ -1654,8 +1636,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
pm_runtime_get_sync(host-dev);
- seq_printf(s, SYSCONFIG:\t0x%08x\n,
- OMAP_HSMMC_READ(host-base, SYSCONFIG));
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
seq_printf(s, HCTL:\t\t0x%08x\n,
--
1.7.11.1.25.g0e18bef
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: [PATCH 09/10] mmc: omap_hsmmc: convert from IP timer to hrtimer
On Tue, Aug 21, 2012 at 4:12 PM, Felipe Balbi ba...@ti.com wrote:
On Sat, Aug 18, 2012 at 12:22:29AM +0530, Venkatraman S wrote:
omap hsmmc controller IP has an inbuilt timer that can be programmed to
^^^
built-in
guard against unresponsive operations. But it's range is very narrow,
its
and it's maximum countable time is a few seconds.
its
Will fix.
Card maintenance operations like BKOPS and SECURE DISCARD and long
stream writes like packed command require timers of order of
several minutes.
So get rid of using the IP timer entirely and use kernel's hrtimer
functionality for guarding the device operations.
As part of this change, a workaround that disabled timeouts for
MMC_ERASE commands is removed, and the arbitary timing of 100ms
is used only when the timeout is not explicitly specified by core.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 96
++-
1 file changed, 50 insertions(+), 46 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9afdd20..8f7cebc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -79,7 +79,7 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT16
-#define INT_EN_MASK 0x307F0033
+#define INT_EN_MASK 0x306E0033
not related to this patch in particular, but it would be nice if this
was converted to something more meaningfull, like ORing a bunch of bit
defines.
Sure. Good to do now as part of the change.
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
#define DTO_ENABLE (1 20)
@@ -160,6 +160,7 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char bus_mode;
unsigned char power_mode;
+ unsigned intns_per_clk_cycle;
int suspended;
int irq;
int use_dma, dma_ch;
@@ -172,6 +173,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ struct hrtimer guard_timer;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -455,10 +457,6 @@ static void omap_hsmmc_enable_irq(struct
omap_hsmmc_host *host,
else
irq_mask = INT_EN_MASK;
- /* Disable timeout for erases */
- if (cmd-opcode == MMC_ERASE)
- irq_mask = ~DTO_ENABLE;
-
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
@@ -508,6 +506,9 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ if (ios-clock)
+ host-ns_per_clk_cycle = DIV_ROUND_UP(NSEC_PER_SEC,
ios-clock);
+
omap_hsmmc_start_clock(host);
}
@@ -824,7 +825,7 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
omap_hsmmc_request_done(host, mrq);
return;
}
-
+ hrtimer_cancel(host-guard_timer);
host-data = NULL;
if (!data-error)
@@ -859,8 +860,11 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
cmd-resp[0] = OMAP_HSMMC_READ(host-base, RSP10);
}
}
- if ((host-data == NULL !host-response_busy) || cmd-error)
+ if ((host-data == NULL !host-response_busy) || cmd-error) {
could just go ahead and make this check uniform by:
if ((!host-data !host-response_busy)) || cmd-error)
Ok.
+ if (cmd-error != -ETIMEDOUT)
+ hrtimer_cancel(host-guard_timer);
omap_hsmmc_request_done(host, cmd-mrq);
+ }
}
/*
@@ -992,7 +996,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
hsmmc_command_incomplete(host, -EILSEQ);
end_cmd = 1;
- if (host-data || host-response_busy) {
+ if (data || host-response_busy) {
This doesn't seem like it belongs to $SUBJECT...
I thought is was a small fix which didn't warrant a separate patch though.
end_trans = 1;
host-response_busy = 0;
}
@@ -1292,41 +1296,35 @@ static int omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host,
return 0;
}
-static void set_data_timeout(struct omap_hsmmc_host *host,
- unsigned int timeout_ns,
- unsigned int timeout_clks)
Re: [PATCH] omap-hsmmc: Implementation of i761 errata
On Fri, Aug 17, 2012 at 11:43 PM, Puttagunta, Viswanath vi...@ti.com wrote: On Fri, Aug 17, 2012 at 12:28 PM, S, Venkatraman svenk...@ti.com wrote: On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko semen.protse...@ti.com wrote: Errata description: Due to a bad behavior of an internal signal, the Card Error interrupt bit MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the card response. Workaround: After responses of type R1/R1b for all cards and responses of type R5/R5b/R6 for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit at the same position in the response MMCHS_RSP10[i] is set to 1, the host controller indicates a card error and software should proceed in the same way as if a CERR interrupt would have been detected in the MMCHS_STAT register. Note: This errata is applicable for omap44xx. Signed-off-by: Semen Protsenko semen.protse...@ti.com The implementation looks fine, but can we simply not set the errata flag and make this as default behaviour ? I suppose the documented behaviour with CSRE and RSP10 is independent of the errata.. Also, please send it to the linux-mmc list as well. Vish We don't know if this errata effects OMAP5 as well. So, I think we should only do this if we are OMAP4. That's precisely why the code shouldn't check for cpu_() flags. There are other OMAP variants as well and we can't check all of them What I mean is to make the check for RSP10 and CSRE all the time as part of the IRQ check. Then it equally applies to silcon with or without errata. -- 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] omap-hsmmc: Implementation of i761 errata
On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko semen.protse...@ti.com wrote:
Errata description:
Due to a bad behavior of an internal signal, the Card Error interrupt bit
MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
card response.
Workaround:
After responses of type R1/R1b for all cards and responses of type R5/R5b/R6
for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and
MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit at
the same position in the response MMCHS_RSP10[i] is set to 1, the host
controller indicates a card error and software should proceed in the same way
as if a CERR interrupt would have been detected in the MMCHS_STAT register.
Note:
This errata is applicable for omap44xx.
Signed-off-by: Semen Protsenko semen.protse...@ti.com
The implementation looks fine, but can we simply not set the errata
flag and make this as default
behaviour ? I suppose the documented behaviour with CSRE and RSP10 is
independent of the
errata..
Also, please send it to the linux-mmc list as well.
---
drivers/mmc/host/omap_hsmmc.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 3a09f93..17803de 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -34,6 +34,7 @@
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
+#include linux/mmc/card.h
#include linux/io.h
#include linux/semaphore.h
#include linux/gpio.h
@@ -47,6 +48,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSCONFIG 0x0010
#define OMAP_HSMMC_SYSSTATUS 0x0014
+#define OMAP_HSMMC_CSRE0x0024
#define OMAP_HSMMC_CON 0x002C
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -117,6 +119,9 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAMEomap_hsmmc
+/* Errata definitions */
+#define OMAP_HSMMC_ERRATA_I761 BIT(0)
+
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -177,6 +182,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ unsigned interrata;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -857,6 +863,23 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
omap_hsmmc_start_command(host, data-stop, NULL);
}
+static int
+omap_hsmmc_errata_i761(struct omap_hsmmc_host *host, struct mmc_command *cmd)
+{
+ u32 rsp10, csre;
+
+ if ((cmd-flags MMC_RSP_R1) == MMC_RSP_R1
+ || (host-mmc-card (mmc_card_sd(host-mmc-card)
+ || mmc_card_sdio(host-mmc-card))
+(cmd-flags MMC_RSP_R5))) {
+ rsp10 = OMAP_HSMMC_READ(host-base, RSP10);
+ csre = OMAP_HSMMC_READ(host-base, CSRE);
+ return rsp10 csre;
+ }
+
+ return 0;
+}
+
/*
* Notify the core about command completion
*/
@@ -1046,6 +1069,17 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
}
+ /* Errata i761 */
+ if ((host-errata OMAP_HSMMC_ERRATA_I761) host-cmd
+omap_hsmmc_errata_i761(host, host-cmd)) {
+ /* Do the same as for CARD_ERR case */
+ dev_dbg(mmc_dev(host-mmc), Ignoring card err CMD%d\n,
+ host-cmd-opcode);
+ end_cmd = 1;
+ if (host-data)
+ end_trans = 1;
+ }
+
OMAP_HSMMC_WRITE(host-base, STAT, status);
if (end_cmd || ((status CC) host-cmd))
@@ -1829,6 +1863,10 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
host-power_mode = MMC_POWER_OFF;
host-next_data.cookie = 1;
+ host-errata = 0;
+ if (cpu_is_omap44xx())
+ host-errata |= OMAP_HSMMC_ERRATA_I761;
+
platform_set_drvdata(pdev, host);
mmc-ops= omap_hsmmc_ops;
--
1.7.10.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 RESEND v5] mmc: core: Remove bounce buffer in mmc_send_cxd_data()
On Thu, Aug 2, 2012 at 12:37 PM, Kyungsik Lee kyungsik@lge.com wrote: It is expected that Extended CSD register(the size of this register is larger than CID/CSD) will be referenced more frequently as more fields have been added to Extended CSD and it seems that it is not a good option to double the memory used. This patch is intended to avoid the use of bounce buffer for reading Extended CSD register in mmc_send_cxd_data(). It will provide a better performance gain by removing memcpy() overhead for a half KiB and a redundant bounce buffer allocated repeatedly at the cost of providing DMA-capable buffer from upper caller(but on-stack buffer is allowed with no performance gain). Signed-off-by: Kyungsik Lee kyungsik@lge.com Signed-off-by: S, Venkatraman svenk...@ti.com I don't think my sign off is warranted. I gave just an illustration. You can add my Reviewed-by: Venkatraman S svenk...@ti.com Regards, Venkat. -- 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 RESEND v2] mmc: core: Remove bounce buffer in mmc_send_cxd_data()
On Mon, Jul 30, 2012 at 7:34 AM, Kyungsik Lee kyungsik@lge.com wrote:
It is expected that Extended CSD register(the size of this register
is larger than CID/CSD) will be referenced more frequently as more
fields have been added to Extended CSD and it seems that it is not
a good option to double the memory used.
This patch is intended to avoid the use of bounce buffer for reading
Extended CSD register in mmc_send_cxd_data().
Maybe I am reading this wrong, but mmc_send_cid and mmc_send_csd are always
called with card-raw_cid and card-raw_csd, which are allocated from the heap,
(from mmc_alloc_card).
So the second half of your changes are not required, or a WARN_ON
might suffice ?
Signed-off-by: Kyungsik Lee kyungsik@lge.com
---
Changes in v2:
- Handling on-stack buffer if it's used in caller.
---
drivers/mmc/core/mmc_ops.c | 56 ++-
1 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 0ed2cc5..dae5492 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -239,13 +239,19 @@ mmc_send_cxd_data(struct mmc_card *card, struct
mmc_host *host,
struct mmc_data data = {0};
struct scatterlist sg;
void *data_buf;
+ int is_on_stack;
- /* dma onto stack is unsafe/nonportable, but callers to this
-* routine normally provide temporary on-stack buffers ...
-*/
- data_buf = kmalloc(len, GFP_KERNEL);
- if (data_buf == NULL)
- return -ENOMEM;
+ is_on_stack = object_is_on_stack(buf);
+ if (is_on_stack) {
+
+ /* dma onto stack is unsafe/nonportable, but callers to this
+* routine normally provide temporary on-stack buffers ...
+*/
+ data_buf = kmalloc(len, GFP_KERNEL);
+ if (data_buf == NULL)
+ return -ENOMEM;
+ } else
+ data_buf = buf;
mrq.cmd = cmd;
mrq.data = data;
@@ -280,8 +286,10 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host
*host,
mmc_wait_for_req(host, mrq);
- memcpy(buf, data_buf, len);
- kfree(data_buf);
+ if (is_on_stack) {
+ memcpy(buf, data_buf, len);
+ kfree(data_buf);
+ }
if (cmd.error)
return cmd.error;
@@ -294,24 +302,37 @@ mmc_send_cxd_data(struct mmc_card *card, struct
mmc_host *host,
int mmc_send_csd(struct mmc_card *card, u32 *csd)
{
int ret, i;
+ u32 *csd_tmp;
if (!mmc_host_is_spi(card-host))
return mmc_send_cxd_native(card-host, card-rca 16,
csd, MMC_SEND_CSD);
- ret = mmc_send_cxd_data(card, card-host, MMC_SEND_CSD, csd, 16);
+ csd_tmp = kmalloc(16, GFP_KERNEL);
+ if (!csd_tmp)
+ return -ENOMEM;
+
+ ret = mmc_send_cxd_data(card, card-host, MMC_SEND_CSD, csd_tmp, 16);
if (ret)
- return ret;
+ goto err;
+
+ memcpy(csd, csd_tmp, 16);
for (i = 0;i 4;i++)
csd[i] = be32_to_cpu(csd[i]);
+ kfree(csd_tmp);
return 0;
+
+err:
+ kfree(csd_tmp);
+ return ret;
}
int mmc_send_cid(struct mmc_host *host, u32 *cid)
{
int ret, i;
+ u32 *cid_tmp;
if (!mmc_host_is_spi(host)) {
if (!host-card)
@@ -320,14 +341,25 @@ int mmc_send_cid(struct mmc_host *host, u32 *cid)
cid, MMC_SEND_CID);
}
- ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid, 16);
+ cid_tmp = kmalloc(16, GFP_KERNEL);
+ if (!cid_tmp)
+ return -ENOMEM;
+
+ ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid_tmp, 16);
if (ret)
- return ret;
+ goto err;
+
+ memcpy(cid, cid_tmp, 16);
for (i = 0;i 4;i++)
cid[i] = be32_to_cpu(cid[i]);
+ kfree(cid_tmp);
return 0;
+
+err:
+ kfree(cid_tmp);
+ return ret;
}
int mmc_send_ext_csd(struct mmc_card *card, u8 *ext_csd)
--
1.7.0.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 v2 1/1] mmc: block: Add write packing control
On Fri, Jul 27, 2012 at 12:24 AM, me...@codeaurora.org wrote:
On Thu, July 26, 2012 8:28 am, S, Venkatraman wrote:
On Tue, Jul 24, 2012 at 2:14 PM, me...@codeaurora.org wrote:
On Mon, July 23, 2012 5:22 am, S, Venkatraman wrote:
On Mon, Jul 23, 2012 at 5:13 PM, me...@codeaurora.org wrote:
On Wed, July 18, 2012 12:26 am, Chris Ball wrote:
Hi, [removing Jens and the documentation list, since now we're
talking about the MMC side only]
On Wed, Jul 18 2012, me...@codeaurora.org wrote:
Is there anything else that holds this patch from being pushed to
mmc-next?
Yes, I'm still uncomfortable with the write packing patchsets for a
couple of reasons, and I suspect that the sum of those reasons means
that
we should probably plan on holding off merging it until after 3.6.
Here are the open issues; please correct any misunderstandings: With
Seungwon's patchset (Support packed write command):
* I still don't have a good set of representative benchmarks showing
what kind of performance changes come with this patchset. It seems
like we've had a small amount of testing on one controller/eMMC part
combo
from Seungwon, and an entirely different test from Maya, and the
results
aren't documented fully anywhere to the level of describing what the
hardware was, what the test was, and what the results were before and
after the patchset.
Currently, there is only one card vendor that supports packed
commands.
Following are our sequential write (LMDD) test results on 2 of our
targets
(in MB/s):
No packingpacking
Target 1 (SDR 50MHz) 15 25
Target 2 (DDR 50MHz) 20 30
With the reads-during-writes regression:
* Venkat still has open questions about the nature of the read
regression, and thinks we should understand it with blktrace before
trying to fix it. Maya has a theory about writes overwhelming reads,
but
Venkat doesn't understand why this would explain the observed
bandwidth drop.
The degradation of read due to writes is not a new behavior and exists
also without the write packing feature (which only increases the
degradation). Our investigation of this phenomenon led us to the
Conclusion that a new scheduling policy should be used for mobile
devices,
but this is not related to the current discussion of the write packing
feature.
The write packing feature increases the degradation of read due to
write
since it allows the MMC to fetch many write requests in a row, instead
of
fetching only one at a time. Therefore some of the read requests will
have to wait for the completion of more write requests before they can
be
issued.
I am a bit puzzled by this claim. One thing I checked carefully when
reviewing write packing patches from SJeon was that the code didn't
plough through a mixed list of reads and writes and selected only
writes.
This section of the code in mmc_blk_prep_packed_list(), from v8
patchset..
Quote
+ if (rq_data_dir(cur) != rq_data_dir(next)) {
+ put_back = 1;
+ break;
+ }
/Quote
means that once a read is encountered in the middle of write packing,
the packing is stopped at that point and it is executed. Then the next
blk_fetch_request should get the next read and continue as before.
IOW, the ordering of reads and writes is _not_ altered when using
packed
commands.
For example if there were 5 write requests, followed by 1 read,
followed by 5 more write requests in the request_queue, the first 5
writes will be executed as one packed command, then the read will be
executed, and then the remaining 5 writes will be executed as one
packed command. So the read does not have to wait any more than it
waited before (packing feature)
Let me try to better explain with your example.
Without packing the MMC layer will fetch 2 write requests and wait for
the
first write request completion before fetching another write request.
During this time the read request could be inserted into the CFQ and
since
it has higher priority than the async write it will be dispatched in the
next fetch. So, the result would be 2 write requests followed by one
read
request and the read would have to wait for completion of only 2 write
requests.
With packing, all the 5 write requests will be fetched in a row, and
then
the read will arrive and be dispatched in the next fetch. Then the read
will have to wait for the completion of 5 write requests.
Few more clarifications:
Due to the plug list mechanism in the block layer the applications can
aggregate several requests to be inserted into the scheduler before
waking the MMC queue thread.
This leads to a situation where there are several write requests in the
CFQ queue when MMC starts to do the fetches.
If the read was inserted while we are building the packed command then I
agree that we should have seen less effect on the read performance.
However
Re: [PATCH v2 1/1] mmc: block: Add write packing control
On Tue, Jul 24, 2012 at 2:14 PM, me...@codeaurora.org wrote:
On Mon, July 23, 2012 5:22 am, S, Venkatraman wrote:
On Mon, Jul 23, 2012 at 5:13 PM, me...@codeaurora.org wrote:
On Wed, July 18, 2012 12:26 am, Chris Ball wrote:
Hi, [removing Jens and the documentation list, since now we're
talking about the MMC side only]
On Wed, Jul 18 2012, me...@codeaurora.org wrote:
Is there anything else that holds this patch from being pushed to
mmc-next?
Yes, I'm still uncomfortable with the write packing patchsets for a
couple of reasons, and I suspect that the sum of those reasons means that
we should probably plan on holding off merging it until after 3.6.
Here are the open issues; please correct any misunderstandings: With
Seungwon's patchset (Support packed write command):
* I still don't have a good set of representative benchmarks showing
what kind of performance changes come with this patchset. It seems
like we've had a small amount of testing on one controller/eMMC part combo
from Seungwon, and an entirely different test from Maya, and the
results
aren't documented fully anywhere to the level of describing what the
hardware was, what the test was, and what the results were before and
after the patchset.
Currently, there is only one card vendor that supports packed commands.
Following are our sequential write (LMDD) test results on 2 of our
targets
(in MB/s):
No packingpacking
Target 1 (SDR 50MHz) 15 25
Target 2 (DDR 50MHz) 20 30
With the reads-during-writes regression:
* Venkat still has open questions about the nature of the read
regression, and thinks we should understand it with blktrace before
trying to fix it. Maya has a theory about writes overwhelming reads, but
Venkat doesn't understand why this would explain the observed
bandwidth drop.
The degradation of read due to writes is not a new behavior and exists
also without the write packing feature (which only increases the
degradation). Our investigation of this phenomenon led us to the
Conclusion that a new scheduling policy should be used for mobile
devices,
but this is not related to the current discussion of the write packing
feature.
The write packing feature increases the degradation of read due to
write
since it allows the MMC to fetch many write requests in a row, instead of
fetching only one at a time. Therefore some of the read requests will
have to wait for the completion of more write requests before they can
be
issued.
I am a bit puzzled by this claim. One thing I checked carefully when
reviewing write packing patches from SJeon was that the code didn't
plough through a mixed list of reads and writes and selected only
writes.
This section of the code in mmc_blk_prep_packed_list(), from v8
patchset..
Quote
+ if (rq_data_dir(cur) != rq_data_dir(next)) {
+ put_back = 1;
+ break;
+ }
/Quote
means that once a read is encountered in the middle of write packing,
the packing is stopped at that point and it is executed. Then the next
blk_fetch_request should get the next read and continue as before.
IOW, the ordering of reads and writes is _not_ altered when using packed
commands.
For example if there were 5 write requests, followed by 1 read,
followed by 5 more write requests in the request_queue, the first 5
writes will be executed as one packed command, then the read will be
executed, and then the remaining 5 writes will be executed as one
packed command. So the read does not have to wait any more than it
waited before (packing feature)
Let me try to better explain with your example.
Without packing the MMC layer will fetch 2 write requests and wait for the
first write request completion before fetching another write request.
During this time the read request could be inserted into the CFQ and since
it has higher priority than the async write it will be dispatched in the
next fetch. So, the result would be 2 write requests followed by one read
request and the read would have to wait for completion of only 2 write
requests.
With packing, all the 5 write requests will be fetched in a row, and then
the read will arrive and be dispatched in the next fetch. Then the read
will have to wait for the completion of 5 write requests.
Few more clarifications:
Due to the plug list mechanism in the block layer the applications can
aggregate several requests to be inserted into the scheduler before
waking the MMC queue thread.
This leads to a situation where there are several write requests in the
CFQ queue when MMC starts to do the fetches.
If the read was inserted while we are building the packed command then I
agree that we should have seen less effect on the read performance.
However, the write packing statistics show that in most of the cases the
packing stopped due to an empty queue, meaning that the read
Re: [PATCH v11] mmc: support BKOPS feature for eMMC
On Tue, Jul 24, 2012 at 7:26 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Enable eMMC background operations (BKOPS) feature. If URGENT_BKOPS is set after a response, note that BKOPS are required. Immediately run BKOPS if required. read/write operations should be requested during BKOPS(LEVEL-1), then issue HPI to interrupt the ongoing BKOPS and service the foreground operation. (This patch is only control the LEVEL2/3.) When repeating the writing 1GB data, at a certain time, performance is decreased. At that time, card is also triggered the Level-3 or Level-2. After running bkops, performance is recovered. Future considerations * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner. * Interrupt ongoing BKOPS before powering off the card. * How get BKOPS_STATUS value.(periodically send ext_csd command?) * If use periodic bkops, also consider runtime_pm control. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org Signed-off-by: Maya Erez me...@codeaurora.org I've tested this patch and it works as intended, except that it is causing a data read/write abort on my OMAP board with BKOPS enabled eMMC. But the fault is on the host controller side which has an upper limit on the timeout value that can be set for the command, which is too short for the maximum advertised BKOPS execution time. I need to fix omap_hsmmc to disable DTO for BKOPS as an exception (just like it's done for ERASE today) or an equivalent fix. Other host controllers also have to check this. Regards, Venkat. -- 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 1/1] mmc: block: Add write packing control
On Mon, Jul 23, 2012 at 5:13 PM, me...@codeaurora.org wrote:
On Wed, July 18, 2012 12:26 am, Chris Ball wrote:
Hi, [removing Jens and the documentation list, since now we're
talking about the MMC side only]
On Wed, Jul 18 2012, me...@codeaurora.org wrote:
Is there anything else that holds this patch from being pushed to
mmc-next?
Yes, I'm still uncomfortable with the write packing patchsets for a
couple of reasons, and I suspect that the sum of those reasons means that
we should probably plan on holding off merging it until after 3.6.
Here are the open issues; please correct any misunderstandings:
With Seungwon's patchset (Support packed write command):
* I still don't have a good set of representative benchmarks showing
what kind of performance changes come with this patchset. It seems
like we've had a small amount of testing on one controller/eMMC part combo
from Seungwon, and an entirely different test from Maya, and the results
aren't documented fully anywhere to the level of describing what the
hardware was, what the test was, and what the results were before and
after the patchset.
Currently, there is only one card vendor that supports packed commands.
Following are our sequential write (LMDD) test results on 2 of our targets
(in MB/s):
No packingpacking
Target 1 (SDR 50MHz) 15 25
Target 2 (DDR 50MHz) 20 30
With the reads-during-writes regression:
* Venkat still has open questions about the nature of the read
regression, and thinks we should understand it with blktrace before
trying to fix it. Maya has a theory about writes overwhelming reads, but
Venkat doesn't understand why this would explain the observed
bandwidth drop.
The degradation of read due to writes is not a new behavior and exists
also without the write packing feature (which only increases the
degradation). Our investigation of this phenomenon led us to the
Conclusion that a new scheduling policy should be used for mobile devices,
but this is not related to the current discussion of the write packing
feature.
The write packing feature increases the degradation of read due to write
since it allows the MMC to fetch many write requests in a row, instead of
fetching only one at a time. Therefore some of the read requests will
have to wait for the completion of more write requests before they can be
issued.
I am a bit puzzled by this claim. One thing I checked carefully when
reviewing write packing patches from SJeon was that the code didn't
plough through a mixed list of reads and writes and selected only
writes.
This section of the code in mmc_blk_prep_packed_list(), from v8 patchset..
Quote
+ if (rq_data_dir(cur) != rq_data_dir(next)) {
+ put_back = 1;
+ break;
+ }
/Quote
means that once a read is encountered in the middle of write packing,
the packing is stopped at that point and it is executed. Then the next
blk_fetch_request should get the next read and continue as before.
IOW, the ordering of reads and writes is _not_ altered when using
packed commands.
For example if there were 5 write requests, followed by 1 read,
followed by 5 more write requests in the request_queue, the first 5
writes will be executed as one packed command, then the read will be
executed, and then the remaining 5 writes will be executed as one
packed command. So the read does not have to wait any more than it
waited before (packing feature)
And I requested blktrace to confirm that this is indeed the behaviour.
Your rest of the arguments anyway depend on this assertion, so can you
please clarify this.
To overcome this behavior, the solution would be to stop the write packing
when a read request is fetched, and this is the algorithm suggested by the
write packing control.
Let's also keep in mind that lmdd benchmarking doesn't fully reflect the
real life in which there are not many scenarios that cause massive read
and write operations. In our user-common-scenarios tests we saw that in
many cases the write packing decreases the read latency. It can happen in
cases where the same amount of write requests is fetched with and without
packing. In such a case the write packing decreases the transfer time of
the write requests and causes the read request to wait for a shorter time.
With Maya's patchset (write packing control):
* Venkat thinks that HPI should be used, and the number-of-requests
metric is too coarse, and it doesn't let you disable packing at the
right time, and you're essentially implementing a new I/O scheduler inside
the MMC subsystem without understanding the root cause for why that's
necessary.
According to our measurements the stop transmission (CMD12) + HPI is a
heavy operation that may take up to several milliseconds. Therefore, a
massive usage of HPI can cause a degradation of performance.
In addition, it doesn’t
Re: [PATCH 12/25] mmc/omap_hsmmc: add a const qualifier
On Mon, Jul 23, 2012 at 2:43 PM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: This prepares *of_device_id.data becoming const. Without this change the following warning would occur: drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_probe': drivers/mmc/host/omap_hsmmc.c:1808: warning: initialization discards qualifiers from pointer target type Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Acked-by: Venkatraman S svenk...@ti.com --- drivers/mmc/host/omap_hsmmc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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: host: enable OMAP DMA engine support for omap hosts by default
On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 02:49]: The patch simply make them depend on DMA_OMAP since DMA_OMAP will select DMA_ENGINE automatically This won't be true if the DMA selection are not done at ARCH_OMAP level as discussed in this thread. Having said that, I think Russell and Tony need to take call on how this needs to be handled. As the DMA channels can run out, drivers should also work without DMA. And building everything as modules should be possible for the distro kernels. So I'd rather not have either select or depends and have the drivers fixed. Ok - I'll work on getting polling mode to work, but as you know it's not the mode to get the best performance out of the device. I see that you've also merged the changes to omap2plus_defconfig, which should get MMC working as before DMA Engine conversion. There's a small patch needed to omap_hsmmc to return a non-zero error code during the probe error path. This will atleast make probe failure explicit when DMA is not available. Let me know if you want me to post it separately as a patch.. diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 2338703..892a046 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1773,7 +1773,7 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) struct mmc_host *mmc; struct omap_hsmmc_host *host = NULL; struct resource *res; - int ret, irq; + int ret = -ENXIO, irq; const struct of_device_id *match; dma_cap_mask_t mask; unsigned tx_req, rx_req; -- 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: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Jul 20, 2012 at 2:58 PM, S, Venkatraman svenk...@ti.com wrote: On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 02:49]: The patch simply make them depend on DMA_OMAP since DMA_OMAP will select DMA_ENGINE automatically This won't be true if the DMA selection are not done at ARCH_OMAP level as discussed in this thread. Having said that, I think Russell and Tony need to take call on how this needs to be handled. As the DMA channels can run out, drivers should also work without DMA. And building everything as modules should be possible for the distro kernels. So I'd rather not have either select or depends and have the drivers fixed. Ok - I'll work on getting polling mode to work, but as you know it's not the mode to get the best performance out of the device. I see that you've also merged the changes to omap2plus_defconfig, which should get MMC working as before DMA Engine conversion. There's a small patch needed to omap_hsmmc to return a non-zero error code during the probe error path. This will atleast make probe failure explicit when DMA is not available. Let me know if you want me to post it separately as a patch.. diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 2338703..892a046 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1773,7 +1773,7 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) struct mmc_host *mmc; struct omap_hsmmc_host *host = NULL; struct resource *res; - int ret, irq; + int ret = -ENXIO, irq; const struct of_device_id *match; dma_cap_mask_t mask; unsigned tx_req, rx_req; Please ignore this patch. The correct one was posted by Kevin last week [1]. An additional patch is needed on top of that to fix other error paths, I'll send both now. [1] http://marc.info/?l=linux-omapm=134196391719430w=2 -- 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: host: enable OMAP DMA engine support for omap hosts by default
On Wed, Jul 18, 2012 at 2:46 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Wed, Jul 18, 2012 at 11:11 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 2:19 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index aa131b3..314c7bd 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA config MMC_OMAP tristate TI OMAP Multimedia Card Interface support - depends on ARCH_OMAP + depends on ARCH_OMAP DMADEVICES DMA_OMAP May be. But since for sure a driver knows that it needs DMA support to be enabled, I will just select it rather than depends on. Regards santosh Yes I agree with you, I was just exploring other options :-) For MMC atleast, there's already a patch in mmc-next to do a Depends On http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=7c68046c99f0b96d965c31cf42814b9a0f15ad46 -- 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] mmc: dwmmc: Add quirk for broken Hardware Config
On Wed, Jul 18, 2012 at 2:08 PM, Girish K S
girish.shivananja...@linaro.org wrote:
In some Soc'S that integrate Designware mmc host controllers, the
HCON register is broken. The hardware configuration is not
updated. One specific usecase is the IDMAC. In Exysons5 SoC
there exist a internal DMA, but the HCON register's DMA_INTERFACE
field is not set to indicate its existance.
This quirk can be used in such case to force the existance broken
HCON field.
changes in v1:
-modified the caps2 field access per controller index.Reported
by Jaehoon Chung jh80.ch...@samsung.com.
-replaced the pointer to device with the pointer to platform
device in struct dw_mci.
-updated driver data for all 4 mmc controllers of exynos5 SoC.
-added non device-tree support for ctrl_id access.
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
drivers/mmc/host/dw_mmc-pltfm.c | 10 +++-
drivers/mmc/host/dw_mmc.c | 150
---
drivers/mmc/host/dw_mmc.h |1 +
include/linux/mmc/dw_mmc.h |2 +-
include/linux/mmc/host.h|1 +
5 files changed, 106 insertions(+), 58 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 900f412..c8eb573 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -35,9 +35,17 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
MMC_CAP_CMD23,
};
+static unsigned long exynos5250_dwmmc_caps2[4] = {
+ MMC_CAP2_CONFIG_BROKEN,
+ MMC_CAP2_CONFIG_BROKEN,
+ MMC_CAP2_CONFIG_BROKEN,
+ MMC_CAP2_CONFIG_BROKEN,
+};
+
static struct dw_mci_drv_data exynos5250_drv_data = {
.ctrl_type = DW_MCI_TYPE_EXYNOS5250,
.caps = exynos5250_dwmmc_caps,
+ .caps2 = exynos5250_dwmmc_caps2,
};
static const struct of_device_id dw_mci_pltfm_match[] = {
@@ -74,7 +82,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
goto err_free;
}
- host-dev = pdev-dev;
+ host-pdev = pdev;
host-irq_flags = 0;
host-pdata = pdev-dev.platform_data;
ret = -ENOMEM;
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 000da16..fd9233d 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -283,8 +283,10 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
static void dw_mci_start_command(struct dw_mci *host,
struct mmc_command *cmd, u32 cmd_flags)
{
+ struct device *dev = host-pdev-dev;
+
host-cmd = cmd;
- dev_vdbg(host-dev,
+ dev_vdbg(dev,
start command: ARGR=0x%08x CMDR=0x%08x\n,
cmd-arg, cmd_flags);
@@ -323,10 +325,11 @@ static int dw_mci_get_dma_dir(struct mmc_data *data)
static void dw_mci_dma_cleanup(struct dw_mci *host)
{
struct mmc_data *data = host-data;
+ struct device *dev = host-pdev-dev;
if (data)
if (!data-host_cookie)
- dma_unmap_sg(host-dev,
+ dma_unmap_sg(dev,
data-sg,
data-sg_len,
dw_mci_get_dma_dir(data));
@@ -351,8 +354,9 @@ static void dw_mci_idmac_stop_dma(struct dw_mci *host)
static void dw_mci_idmac_complete_dma(struct dw_mci *host)
{
struct mmc_data *data = host-data;
+ struct device *dev = host-pdev-dev;
- dev_vdbg(host-dev, DMA complete\n);
+ dev_vdbg(dev, DMA complete\n);
host-dma_ops-cleanup(host);
@@ -420,10 +424,27 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
unsigned int sg_len)
mci_writel(host, PLDMND, 1);
}
+static int dw_get_platform_device_id(struct dw_mci *host)
+{
+ int ctrl_id;
+ struct device *dev = host-pdev-dev;
+
+ if (dev-of_node)
+ ctrl_id = of_alias_get_id(dev-of_node, mshc);
+ else
+ ctrl_id = host-pdev-id;
+
+ if (ctrl_id 0)
+ ctrl_id = 0;
+
+ return ctrl_id;
+}
+
static int dw_mci_idmac_init(struct dw_mci *host)
{
struct idmac_desc *p;
- int i, dma_support;
+ int i, dma_support, ctrl_id;
+ struct device *dev = host-pdev-dev;
/* Number of descriptors in the ring buffer */
host-ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
@@ -431,14 +452,23 @@ static int dw_mci_idmac_init(struct dw_mci *host)
/* Check if Hardware Configuration Register has support for DMA */
dma_support = (mci_readl(host, HCON) 16) 0x3;
- if (!dma_support || dma_support 2) {
- dev_err(host-dev,
+ /*
+* In Some of the Soc's the HCON Register is broken. Even though the
+
Re: [PATCH v10] mmc: support BKOPS feature for eMMC
Some minor nits..
On Tue, Jul 17, 2012 at 8:14 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Enable eMMC background operations (BKOPS) feature.
If URGENT_BKOPS is set after a response, note that BKOPS
are required. After all I/O requests are finished, run
BKOPS if required. Should read/write operations be requested
during BKOPS, first issue HPI to interrupt the ongoing BKOPS
and then service the request.
If BKOPS-STATUS is upper than LEVEL2, need to check until clear
the BKOPS-STATUS vaule.
If you want to enable this feature, set MMC_CAP2_BKOPS.
I tested with dw-mmc and sdhci controller.
When repeating the writing 1GB data, at a certain time, performance is
decreased.
At that time, card is also triggered the Level-3 or Level-2.
After running bkops, performance is recovered.
Future considerations
* Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
* Interrupt ongoing BKOPS before powering off the card.
* How get BKOPS_STATUS value.(periodically send ext_csd command?)
* If use periodic bkops, also consider runtime_pm control.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
Signed-off-by: Maya Erez me...@codeaurora.org
---
Changelog v10:
- Based on latest mmc-next
- Only control the level-2/3.
: If triggered upper than level2, immediately start bkops.
- Revmoe the BKOPS_CAP2_INIT_BKOPS (move into mmc-util)
- change use_busy_signal instead of waiting_for_prog_done for
__mmc_switch
Changelog V9:
- Rebased on patch-v7.
- Added Konstantin and Maya's patch
: mmc:core: Define synchronous BKOPS timeout
: mmc:core: eMMC4.5 BKOPS fixes
- Removed periodic bkops
: This feature will do in future work
- Add __mmc_switch() for waiting_for_prod_done.
Changelog V8:
- Remove host-lock spin lock reviewed by Adrian
- Support periodic start bkops
- when bkops_status is level-3, if timeout is set to 0, send hpi.
- Move the start-bkops point
Changelog V7:
- Use HPI command when issued URGENT_BKOPS
- Recheck until clearing the bkops-status bit.
Changelog V6:
- Add the flag of check-bkops-status.
(For fixing async_req problem)
- Add the capability for MMC_CAP2_INIT_BKOPS.
(When unset the bkops_en bit in ext_csd register)
- modify the wrong condition.
Changelog V5:
- Rebase based on the latest mmc-next.
- modify codes based-on Chris's comment
Changelog V4:
- Add mmc_read_bkops_status
- When URGENT_BKOPS(level2-3), didn't use HPI command.
- In mmc_switch(), use R1B/R1 according to level.
Changelog V3:
- move the bkops setting's location in mmc_blk_issue_rw_rq
- modify condition checking
- bkops_en is assigned ext_csd[EXT_CSD_BKOPS_EN] instead of 1
- remove the unused code
- change pr_debug instead of pr_warn in mmc_send_hpi_cmd
- Add the Future consideration suggested by Per
Changelog V2:
- Use EXCEPTION_STATUS instead of URGENT_BKOPS
- Add function to check Exception_status(for eMMC4.5)
---
drivers/mmc/core/core.c| 161
+++-
drivers/mmc/core/mmc.c | 11 +++
drivers/mmc/core/mmc_ops.c | 27 ++-
include/linux/mmc/card.h | 16 +
include/linux/mmc/core.h |5 ++
include/linux/mmc/host.h |2 +-
include/linux/mmc/mmc.h| 19 +-
7 files changed, 233 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 9503cab..52bdd33 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -41,6 +41,12 @@
#include sd_ops.h
#include sdio_ops.h
+/*
+ * The Background operation can take a long time, depends on the house
keeping
+ * operations the card has to perform
+ */
+#define MMC_BKOPS_MAX_TIMEOUT (4 * 60 * 1000) /* max time to wait in ms */
+
static struct workqueue_struct *workqueue;
static const unsigned freqs[] = { 40, 30, 20, 10 };
@@ -245,6 +251,68 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
host-ops-request(host, mrq);
}
+/**
+ * mmc_start_bkops - start BKOPS for supported cards
+ * @card: MMC card to start BKOPS
+ *
+ * Start background operations whenever requested.
+ * when the urgent BKOPS bit is set in a R1 command response
+ * then background operations should be started immediately.
+*/
+void mmc_start_bkops(struct mmc_card *card)
+{
+ int err;
+ int timeout;
+ u8 use_busy_signal;
+
+ BUG_ON(!card);
+ if (!card-ext_csd.bkops_en || !(card-host-caps2 MMC_CAP2_BKOPS))
+ return;
+
+ if
Re: [PATCH] mmc-util: add the method to enable the bkops
Minor printk nits..
On Tue, Jul 17, 2012 at 8:14 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
This patch added the method to enable the bkops.
In ext_csd register, BKOPS_EN bit is one-time programable.
So if you want to use the bkops, use the this command.
usage
#mmc bkops enable /dev/mmcblk0
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
mmc.c |5 +
mmc.h |7 +++
mmc_cmds.c | 39 +++
mmc_cmds.h |1 +
4 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/mmc.c b/mmc.c
index 379d667..3a12653 100644
--- a/mmc.c
+++ b/mmc.c
@@ -75,6 +75,11 @@ static struct Command commands[] = {
Enable the boot partition for the device.\nTo receive
acknowledgment of boot from the card set send_ack\nto 1, else set it to 0.,
NULL
},
+ { do_write_bkops_en, -1,
+ bkops enable, device\n
+ Enable the eMMC BKOPS feature enable on device.,
s/feature enable on/feature on/
+ NULL
+ },
{ 0, 0, 0, 0 }
};
diff --git a/mmc.h b/mmc.h
index 0a521a8..3d77b38 100644
--- a/mmc.h
+++ b/mmc.h
@@ -31,12 +31,14 @@
*/
#define EXT_CSD_S_CMD_SET 504
#define EXT_CSD_HPI_FEATURE503
+#define EXT_CSD_BKOPS_SUPPORT 502 /* RO */
#define EXT_CSD_BOOT_INFO 228 /* R/W */
#define EXT_CSD_PART_SWITCH_TIME 199
#define EXT_CSD_BOOT_CFG 179
#define EXT_CSD_PART_CONFIG179
#define EXT_CSD_BOOT_WP173
#define EXT_CSD_WR_REL_PARAM 166
+#define EXT_CSD_BKOPS_EN 163 /* R/W */
#define EXT_CSD_NATIVE_SECTOR_SIZE 63 /* R */
#define EXT_CSD_USE_NATIVE_SECTOR 62 /* R/W */
#define EXT_CSD_DATA_SECTOR_SIZE 61 /* R */
@@ -48,6 +50,11 @@
#define EN_REL_WR (12)
/*
+ * BKOPS_EN field definition
+ */
+#define BKOPS_ENABLE (10)
+
+/*
* EXT_CSD field definitions
*/
#define EXT_CSD_HPI_SUPP (10)
diff --git a/mmc_cmds.c b/mmc_cmds.c
index 90619db..271d1e4 100644
--- a/mmc_cmds.c
+++ b/mmc_cmds.c
@@ -280,6 +280,45 @@ int do_write_boot_en(int nargs, char **argv)
return ret;
}
+int do_write_bkops_en(int nargs, char **argv)
+{
+ __u8 ext_csd[512], value = 0;
+ int fd, ret;
+ char *device;
+
+ CHECK(nargs != 2, Usage: mmc bkops enable /path/to/mmcblkX\n,
+ exit(1));
+
+ device = argv[1];
+
+ fd = open(device, O_RDWR);
+ if (fd 0) {
+ perror(open);
+ exit(1);
+ }
+
+ ret = read_extcsd(fd, ext_csd);
+ if (ret) {
+ fprintf(stderr, Could not read EXT_CSD from %s\n, device);
+ exit(1);
+ }
+
+ if (!(ext_csd[EXT_CSD_BKOPS_SUPPORT] 0x1)) {
+ fprintf(stderr, Didn't support BKOPS from %s\n, device);
Better reported as fprintf(stderr, %s does not support BKOPS\n, device);
After fixing this, feel free to add my
Reviewed-by: Venkatraman Ssvenk...@ti.com
--
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: skip mmc_power_up call from start host
On Fri, Jul 13, 2012 at 6:27 PM, Girish K S girish.shivananja...@linaro.org wrote: The call to the mmc_power_up during the mmc_start_host breaks the card detection in design-ware host controller. This patch removes the call to mmc_power_up function during host start. Please explain why. Which commit introduced it ? This fix works fine with sdhci (sdhci compatilble host controller) and dw_mmc (design-ware host controller). and has no side effect due to this removal. How can you be sure ? What about other hosts ? -- 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 1/1] mmc: block: Add write packing control
On Mon, Jul 16, 2012 at 8:16 AM, Chris Ball c...@laptop.org wrote: Hi, On Sun, Jul 15 2012, Muthu Kumar wrote: I've already replied to a later version of the patch, but just to get this comment in at the appropriate point of the discussion as well: Even though it would result in a cleaner sysfs, I don't want to do this now because it will break userspace scripts that are depending on the current locations of these attributes. Maya is adding a new sysfs attribute with that patch. So, there should not be any user space stuff that depends on it. In the later patchset, Maya's [PATCH v4 1/2] mmc: card: Move MMC specific attributes to mmc sub-directory moves the existing attributes into the mmc/ directory. It's that move that I'm objecting to, rather than the creation of a new directory -- although since we're going to leave the current attributes where they are, it might not make sense to add the new directory. We'd be creating two places that people have to look for mmc-related attributes, which is arguably less clean than having one place to look even though it's mixed in with the other block device attributes. It's better to normalise this eventually. It would be better if we create a duplicate sysfs entry within MMC, which is identical to the current block layer attribute. Then schedule the block layer attribute to be removed by, say, 3.9. [Add it to Documentation/feature-removal-schedule.txt] Since it is a MMC specific attribute, generic tools wouldn't depend on it. -- 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_hsmmc: ensure probe returns error upon resource failure
On Wed, Jul 11, 2012 at 5:10 AM, Kevin Hilman khil...@ti.com wrote:
If platform_get_resource_by_name() fails, driver probe is aborted an
should return an error so the driver is not bound to the device.
However, in the current error path of platform_get_resource_by_name(),
probe returns zero since the return value (ret) is not properly set.
With a zero return value, the driver core assumes probe was successful
and will bind the driver to the device.
Fix this by ensuring that probe returns an error code in this failure
path.
Signed-off-by: Kevin Hilman khil...@ti.com
Good catch.
Acked-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 389a3ee..19e60e9 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1931,6 +1931,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
if (!res) {
dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
+ ret = -ENXIO;
goto err_irq;
}
host-dma_line_tx = res-start;
@@ -1938,6 +1939,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
if (!res) {
dev_err(mmc_dev(host-mmc), cannot get DMA RX channel\n);
+ ret = -ENXIO;
goto err_irq;
}
host-dma_line_rx = res-start;
--
1.7.9.2
--
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 v8 1/2] mmc: add packed command feature of eMMC4.5
On Tue, Jul 10, 2012 at 11:24 AM, Chris Ball c...@laptop.org wrote:
Hi,
On Fri, Jun 29 2012, Seungwon Jeon wrote:
This patch adds packed command feature of eMMC4.5.
The maximum number for packing read(or write) is offered
and exception event relevant to packed command which is
used for error handling is enabled. If host wants to use
this feature, MMC_CAP2_PACKED_CMD should be set.
Signed-off-by: Seungwon Jeon tgih@samsung.com
Reviewed-by: Maya Erez me...@codeaurora.org
Reviewed-by: Subhash Jadavani subha...@codeaurora.org
Reviewed-by: Namjae Jeon linkinj...@gmail.com
---
drivers/mmc/core/mmc.c | 25 +
include/linux/mmc/card.h |3 +++
include/linux/mmc/host.h |4
include/linux/mmc/mmc.h | 15 +++
4 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 258b203..bfb271f 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -516,6 +516,11 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
} else {
card-ext_csd.data_tag_unit_size = 0;
}
+
+ card-ext_csd.max_packed_writes =
+ ext_csd[EXT_CSD_MAX_PACKED_WRITES];
+ card-ext_csd.max_packed_reads =
+ ext_csd[EXT_CSD_MAX_PACKED_READS];
} else {
card-ext_csd.data_sector_size = 512;
}
@@ -1246,6 +1251,26 @@ static int mmc_init_card(struct mmc_host *host, u32
ocr,
}
}
+ if ((host-caps2 MMC_CAP2_PACKED_WR
+ card-ext_csd.max_packed_writes 0) ||
+ (host-caps2 MMC_CAP2_PACKED_RD
+ card-ext_csd.max_packed_reads 0)) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_EXP_EVENTS_CTRL,
+ EXT_CSD_PACKED_EVENT_EN,
+ card-ext_csd.generic_cmd6_time);
Sorry, I don't have a copy of the eMMC 4.5 spec -- is PACKED_EVENT_EN
a one-time programmable fuse on the eMMC, like BKOPS_ENABLE was?
It's not. PACKED_EVENT_EN is a bit set into EXCEPTION_EVENTS_CTRL
register, which is reset duing a power cycle
--
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_hsmmc: fix runtime suspend crash: add host checks in callbacks
On Tue, Jul 10, 2012 at 7:47 PM, Kevin Hilman khil...@ti.com wrote: S, Venkatraman svenk...@ti.com writes: On Sat, Jul 7, 2012 at 5:56 AM, Kevin Hilman khil...@ti.com wrote: Due to the way the driver core takes runtime PM references during probe, a driver's runtime PM callbacks may not be called until probe returns. During probe, drvdata is set to the 'host' pointer but if probe fails, drvdata is set to NULL. The runtime PM callbacks currently blindly dereference this host pointer, but if probe fails, and the runtime PM callbacks are called after probe returns, a NULL pointer dereference will result. Pardon my ignorance, but why would runtime suspend be called for a device whose probe has failed ? AFAIK, MMC stack wouldn't make the _enable()/disable() calls, which call runtime PM APIs, unless the probe is successful. Is there a stacktrace for the offending caller ? First thing to note: there are several error conditions *after* pm_runtime_enable() and the first _get_sync() are called. So here's what can happen: The driver core does a _get_noresume() before calling the driver's probe, so the runtime PM usecount is already 1 when the driver is called. The _get_sync() in _probe enables the device and increases the usecount to 2. The _put_sync() at the end of -probe() will decrease the usecount to 1, but since the usecount is still non-zero, the driver's callbacks are still not called. It's not until the driver core does its _put_sync (to balance the _get_noresume() that the usecount goes to zero and the driver's callbacks are called. Thanks for the detailed explanation. But pm_runtime_disable() is called in the error path, so shouldn't it prevent the driver callbacks from being called ? (The docuementation talks about disable_depth field, but it doesn't sound right that runtime pm would be enabled before _probe() is called. So disable_depth should be 1 when pm_runtime_disable is called in _probe error path, right ?) When probe succeeds, this all works fine. However, if probe fails the host pointer is set to NULL, but the runtime PM callbacks are still called and attempt to dereference a NULL pointer. Fix this by simply checking to be sure the host pointer is non-NULL. Signed-off-by: Kevin Hilman khil...@ti.com --- Applies to v3.5-rc5. Fix is needed for v3.5-rc. Can you please let me know which commit introduced this problem in the first place ? There were not many changes in MMC PM code in this merge window. I guess this problem is probably not a regression and has been around for some time. It has not been seen because probe has not failed. In using recent l-o master though, with Russell's dmaengine changes merged, probe is failing for me becasue it can't allocate a DMA channel, and then I'm seeing this problem. Kevin Ok. I'll let Chris decide on this - DMA engine is not yet in Linus's tree though. -- 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_hsmmc: fix runtime suspend crash: add host checks in callbacks
On Sat, Jul 7, 2012 at 5:56 AM, Kevin Hilman khil...@ti.com wrote: Due to the way the driver core takes runtime PM references during probe, a driver's runtime PM callbacks may not be called until probe returns. During probe, drvdata is set to the 'host' pointer but if probe fails, drvdata is set to NULL. The runtime PM callbacks currently blindly dereference this host pointer, but if probe fails, and the runtime PM callbacks are called after probe returns, a NULL pointer dereference will result. Pardon my ignorance, but why would runtime suspend be called for a device whose probe has failed ? AFAIK, MMC stack wouldn't make the _enable()/disable() calls, which call runtime PM APIs, unless the probe is successful. Is there a stacktrace for the offending caller ? Fix this by simply checking to be sure the host pointer is non-NULL. Signed-off-by: Kevin Hilman khil...@ti.com --- Applies to v3.5-rc5. Fix is needed for v3.5-rc. Can you please let me know which commit introduced this problem in the first place ? There were not many changes in MMC PM code in this merge window. -- 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: omap: add clk_prepare and clk_unprepare
On Wed, Jun 27, 2012 at 2:19 PM, Rajendra Nayak rna...@ti.com wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the hsmmc clocks. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Chris Ball c...@laptop.org Cc: Balaji T K balaj...@ti.com Cc: linux-mmc@vger.kernel.org Cc: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@linaro.org Thanks Rajendra. Acked-by: Venkatraman S svenk...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) -- 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 v5] mmc: core: Fix the HPI execution sequence
On Thu, Jun 28, 2012 at 1:12 PM, S, Venkatraman svenk...@ti.com wrote: On Fri, Jun 22, 2012 at 7:01 PM, Subhash Jadavani subha...@codeaurora.org wrote: Thanks Venkatraman. Looks good to me. Reviewed-by: Subhash Jadavani subha...@codeaurora.org Thanks Subhash. Chris, Can you consider including this for 3.6 ? Oops!! - I see that it's already in mmc-next. Many thanks ! Thanks and regards, Venkat. -- 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 RESEND v7 2/3] mmc: core: Support packed write command for eMMC4.5 device
On Mon, Jun 18, 2012 at 11:13 AM, Seungwon Jeon tgih@samsung.com wrote:
This patch supports packed write command of eMMC4.5 device.
Several writes can be grouped in packed command and all data
of the individual commands can be sent in a single transfer
on the bus.
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/card/block.c | 406
+---
drivers/mmc/card/queue.c | 45 +-
drivers/mmc/card/queue.h | 12 ++
drivers/mmc/core/mmc_ops.c | 1 +
include/linux/mmc/core.h | 4 +
5 files changed, 441 insertions(+), 27 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 7e3f453..eb99e35 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -58,6 +58,12 @@ MODULE_ALIAS(mmc:block);
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
+#define mmc_req_rel_wr(req) (((req-cmd_flags REQ_FUA) || \
+ (req-cmd_flags REQ_META)) \
+ (rq_data_dir(req) == WRITE))
+#define PACKED_CMD_VER 0x01
+#define PACKED_CMD_WR 0x02
+
static DEFINE_MUTEX(block_mutex);
/*
@@ -123,9 +129,21 @@ enum mmc_blk_status {
MMC_BLK_NOMEDIUM,
};
+enum {
+ MMC_PACKED_N_IDX = -1,
+ MMC_PACKED_N_ZERO,
+ MMC_PACKED_N_SINGLE,
+};
+
module_param(perdev_minors, int, 0444);
MODULE_PARM_DESC(perdev_minors, Minors numbers to allocate per device);
+static inline void mmc_blk_clear_packed(struct mmc_queue_req *mqrq)
+{
+ mqrq-packed_cmd = MMC_PACKED_NONE;
+ mqrq-packed_num = MMC_PACKED_N_ZERO;
+}
+
static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
{
struct mmc_blk_data *md;
@@ -1081,12 +1099,61 @@ static int mmc_blk_err_check(struct mmc_card *card,
if (!brq-data.bytes_xfered)
return MMC_BLK_RETRY;
+ if (mq_mrq-packed_cmd != MMC_PACKED_NONE) {
+ if (unlikely(brq-data.blocks 9 != brq-data.bytes_xfered))
+ return MMC_BLK_PARTIAL;
+ else
+ return MMC_BLK_SUCCESS;
+ }
+
if (blk_rq_bytes(req) != brq-data.bytes_xfered)
return MMC_BLK_PARTIAL;
return MMC_BLK_SUCCESS;
}
+static int mmc_blk_packed_err_check(struct mmc_card *card,
+ struct mmc_async_req *areq)
+{
+ struct mmc_queue_req *mq_rq = container_of(areq, struct mmc_queue_req,
+ mmc_active);
+ struct request *req = mq_rq-req;
+ int err, check, status;
+ u8 ext_csd[512];
+
+ mq_rq-packed_retries--;
+ check = mmc_blk_err_check(card, areq);
+ err = get_card_status(card, status, 0);
+ if (err) {
+ pr_err(%s: error %d sending status command\n,
+ req-rq_disk-disk_name, err);
+ return MMC_BLK_ABORT;
+ }
+
+ if (status R1_EXP_EVENT) {
+ err = mmc_send_ext_csd(card, ext_csd);
+ if (err) {
+ pr_err(%s: error %d sending ext_csd\n,
+ req-rq_disk-disk_name, err);
+ return MMC_BLK_ABORT;
+ }
+
+ if ((ext_csd[EXT_CSD_EXP_EVENTS_STATUS]
+ EXT_CSD_PACKED_FAILURE)
+ (ext_csd[EXT_CSD_PACKED_CMD_STATUS]
+ EXT_CSD_PACKED_GENERIC_ERROR)) {
+ if (ext_csd[EXT_CSD_PACKED_CMD_STATUS]
+ EXT_CSD_PACKED_INDEXED_ERROR) {
+ mq_rq-packed_fail_idx =
+ ext_csd[EXT_CSD_PACKED_FAILURE_INDEX] - 1;
+ return MMC_BLK_PARTIAL;
+ }
+ }
+ }
+
+ return check;
+}
+
static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
struct mmc_card *card,
int disable_multi,
@@ -1241,10 +1308,197 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
*mqrq,
mmc_queue_bounce_pre(mqrq);
}
+static u8 mmc_blk_prep_packed_list(struct mmc_queue *mq, struct request *req)
+{
+ struct request_queue *q = mq-queue;
+ struct mmc_card *card = mq-card;
+ struct request *cur = req, *next = NULL;
+ struct mmc_blk_data *md = mq-data;
+ bool en_rel_wr = card-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN;
+ unsigned int req_sectors = 0, phys_segments = 0;
+ unsigned int max_blk_count, max_phys_segs;
+ u8 put_back = 0;
+ u8 max_packed_rw = 0;
+ u8 reqs = 0;
+
+ mmc_blk_clear_packed(mq-mqrq_cur);
+
+ if (!(md-flags MMC_BLK_CMD23) ||
+ !card-ext_csd.packed_event_en)
+
Re: [RFC PATCH] Revert mmc: omap_hsmmc: Enable Auto CMD12
On Fri, Jun 22, 2012 at 4:19 PM, Ming Lei ming@canonical.com wrote: This patch reverts the commit dba3c29ea4a1d5d544. After bisecting, this commit dba3c29 is found to ruin micro-SD card data (writing incorrect file, or fs is corrupt after several times mount) on the beagle-xm revB, and reverting the commit will fix the problem. Also from TRM of OMAP3/OMAP4/DM37x, the below is mentioned about the Auto CMD12 Enable bit. - SDIO does not support this feature. - SD card only. Looks it is not suitable to always enable Auto CMD12 in host controller driver. Considered that the commit is not mature enough, so ask to revert it first. Cc: Balaji T K balaj...@ti.com Cc: Venkatraman S svenk...@ti.com Buglink: https://lkml.org/lkml/2012/6/10/225 Reported-by: Paolo Pisati p.pis...@gmail.com Reported-bisected-and-tested-by: Ming Lei ming@canonical.com Signed-off-by: Ming Lei ming@canonical.com Agreed. We can revert this and add it later when the behavior is well understood. Acked-by: Venkatraman S svenk...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 15 +++ 1 file changed, 3 insertions(+), 12 deletions(-) -- 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 02/11] mmc: omap: add clk_prepare and clk_unprepare
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak rna...@ti.com wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the mmc and hsmmc clocks as part of the drivers probe() and remove() routines. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Chris Ball c...@laptop.org Cc: Balaji T K balaj...@ti.com Cc: linux-mmc@vger.kernel.org Rajendra, Can this be applied independently, or does this patch have a dependency on other patches in 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
Re: [PATCH v3] mmc: core: Fix the HPI execution sequence
On Wed, Jun 20, 2012 at 11:29 PM, Subhash Jadavani
subha...@codeaurora.org wrote:
Hi Venkatraman,
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Venkatraman S
Sent: Wednesday, June 20, 2012 3:04 PM
To: c...@laptop.org
Cc: linux-mmc@vger.kernel.org; linkinj...@gmail.com;
jh80.ch...@samsung.com; alex.lemb...@sandisk.com; Venkatraman S; Kostya
Subject: [PATCH v3] mmc: core: Fix the HPI execution sequence
mmc_execute_hpi should send the HPI command only once, and only if the
card is in PRG state.
According to eMMC spec, the command's completion time is not dependent on
OUT_OF_INTERRUPT_TIME. Only the transition out of PRG STATE is guarded by
OUT_OF_INTERRUPT_TIME - which is defined to begin at the end of sending
the command itself.
Specify the default timeout for the actual sending of HPI command, and
then
use OUT_OF_INTERRUPT_TIME to wait for the transition out of PRG state.
I guess this is not the correct interpretation. cmd.cmd_timeout_ms should
specify for how much time host driver should wait for command + busy line
deassertion. So why are you keeping the timeout calculation after the
command is completed?
If what you stay is correct, the card should be in PRG state after
mmc_send_hpi_cmd()
returns.
I understood and observed it as opposite. HPI cmd returns immediately,
and the device takes
OUT_OF_INTERRUPT_TIME time to come out of PRG state.
My experiments / tests confirm that behavior. It takes a few ms (and several
SEND_STATUS messages later), after HPI, for the card to be out of PRG state.
mmc_send_hpi_cmd() returns means the host controller driver have ensured
that BUSY indication is removed so after mmc_send_hpi_cmd(), if you want to
check if the card is still in PROGRAMMING state, it should be unconditional
check in loop (rather than timeout based) until card is out of programming
state.
To me, mmc_send_hpi_cmd() implementation should not be anything different
than mmc_switch(). In mmc_switch() also, after mmc_wait_for_cmd() returns it
continuously keeps checking if card is programming or not.
Regards,
Subhash
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
Reviewed-by: Namjae Jeon linkinj...@gmail.com
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
CC: Kostya kdorf...@codeaurora.org
---
v2 discussions: http://marc.info/?l=linux-mmcm=133657255616390w=2
v2-v3:
Return gracefully for card idle states (suggested by kdorfman)
drivers/mmc/core/core.c | 57
++-
-
drivers/mmc/core/mmc_ops.c | 1 -
2 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
80ec427..08ed144 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -404,6 +404,7 @@ int mmc_interrupt_hpi(struct mmc_card *card) {
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@ -419,30 +420,40 @@ int mmc_interrupt_hpi(struct mmc_card *card)
goto out;
}
- /*
- * If the card status is in PRG-state, we can send the HPI command.
- */
- if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs when
- * sending the HPI command, we are already out of
- * prg-state.
- */
- err = mmc_send_hpi_cmd(card, status);
- if (err)
- pr_debug(%s: abort HPI (%d error)\n,
- mmc_hostname(card-host), err);
+ switch (R1_CURRENT_STATE(status)) {
- err = mmc_send_status(card, status);
- if (err)
- break;
- } while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
- } else
- pr_debug(%s: Left prg-state\n, mmc_hostname(card-host));
+ case R1_STATE_IDLE:
+ case R1_STATE_READY:
+ case R1_STATE_STBY: /* intentional fall through */
+ /* In idle states, HPI is not needed and the caller
+ can issue the next intended command immediately */
+ goto out;
+ break;
+ case R1_STATE_PRG:
+ break;
+ default:
+ /* In all other states, it's illegal to issue HPI */
+ pr_debug(%s: HPI cannot be sent. Card state=%d\n,
+ mmc_hostname(card-host),
R1_CURRENT_STATE(status));
+ err = -EINVAL;
+ goto out;
+ break;
+ }
+
+
Re: [PATCH v3] mmc: core: Fix the HPI execution sequence
On Thu, Jun 21, 2012 at 4:38 PM, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of S, Venkatraman Sent: Thursday, June 21, 2012 12:55 PM To: Subhash Jadavani Cc: c...@laptop.org; linux-mmc@vger.kernel.org; linkinj...@gmail.com; jh80.ch...@samsung.com; alex.lemb...@sandisk.com; Kostya Subject: Re: [PATCH v3] mmc: core: Fix the HPI execution sequence On Wed, Jun 20, 2012 at 11:29 PM, Subhash Jadavani subha...@codeaurora.org wrote: Hi Venkatraman, -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Venkatraman S Sent: Wednesday, June 20, 2012 3:04 PM To: c...@laptop.org Cc: linux-mmc@vger.kernel.org; linkinj...@gmail.com; jh80.ch...@samsung.com; alex.lemb...@sandisk.com; Venkatraman S; Kostya Subject: [PATCH v3] mmc: core: Fix the HPI execution sequence mmc_execute_hpi should send the HPI command only once, and only if the card is in PRG state. According to eMMC spec, the command's completion time is not dependent on OUT_OF_INTERRUPT_TIME. Only the transition out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is defined to begin at the end of sending the command itself. Specify the default timeout for the actual sending of HPI command, and then use OUT_OF_INTERRUPT_TIME to wait for the transition out of PRG state. I guess this is not the correct interpretation. cmd.cmd_timeout_ms should specify for how much time host driver should wait for command + busy line deassertion. So why are you keeping the timeout calculation after the command is completed? If what you stay is correct, the card should be in PRG state after mmc_send_hpi_cmd() returns. I understood and observed it as opposite. HPI cmd returns immediately, and the device takes OUT_OF_INTERRUPT_TIME time to come out of PRG state. My experiments / tests confirm that behavior. It takes a few ms (and several SEND_STATUS messages later), after HPI, for the card to be out of PRG state. What is the HPI command in your case? CMD12 or CMD13? For command CMD12, we set the R1B flag which would tell the host driver to wait for the DAT0 line to be deasserted (if host controller support the automatic detection of DAT0 de assertion). But HPI command is CMD13 then yes, driver will not wait for DAT0 line de assertion. Yes, it has CMD13 - and it makes sense. Yes, so to support both CMD12 and CMD13 as HPI command, we can have 2 options: 1. - Set the R1B flag for CMD13 as well so controller waits for the PROG_DONE. - Once mmc_send_hpi_cmd() returns, you can poll (without any timeout) until the card is out of programming state. 2. - don't set the R1B flag for CMD13 - Once mmc_send_hpi_cmd() returns, if HPI command is CMD12, you can poll (without any timeout) until the card is out of programming state. But if HPI command is CMD13, poll until card is out of programming state with timeout. But in both of the above case, if host driver do not support automatic detection of DAT0 de assertion, we will have to send multiple CMD13 (send_status) before card comes out of programming state but yes, in case I think that's the case with OMAP, and I assumed it to be common. card gets stuck in programming state forever then we will end up sending CMD13 forever. In this case timeout based wait is fine. So if you want to take of case where card is stuck in programming state forever, your implementation is fine. Is this your intention here? I have few comments on your code below. Yes - that was atleast the intention. I didn't assume DAT0 de assertation was auto detectable, and even otherwise, PRG state was to be polled later anyway. Regards, Subhash mmc_send_hpi_cmd() returns means the host controller driver have ensured that BUSY indication is removed so after mmc_send_hpi_cmd(), if you want to check if the card is still in PROGRAMMING state, it should be unconditional check in loop (rather than timeout based) until card is out of programming state. To me, mmc_send_hpi_cmd() implementation should not be anything different than mmc_switch(). In mmc_switch() also, after mmc_wait_for_cmd() returns it continuously keeps checking if card is programming or not. Regards, Subhash Reported-by: Alex Lemberg alex.lemb...@sandisk.com Signed-off-by: Venkatraman S svenk...@ti.com Reviewed-by: Namjae Jeon linkinj...@gmail.com Acked-by: Jaehoon Chung jh80.ch...@samsung.com CC: Kostya kdorf...@codeaurora.org --- v2 discussions: http://marc.info/?l=linux-mmcm=133657255616390w=2 v2-v3: Return gracefully for card idle states (suggested by kdorfman) drivers/mmc/core/core.c | 57 ++- - drivers/mmc/core/mmc_ops.c | 1 - 2 files changed, 34 insertions
Re: [PATCH] MMC-4.5 Power OFF Notify Rework
On Fri, Jun 15, 2012 at 9:38 AM, Saugata Das saugata@stericsson.com wrote: From: Saugata Das saugata@linaro.org This is a rework of the existing POWER OFF NOTIFY patch. The current problem with the patch comes from the ambiguity on the usage of POWER OFF NOTIFY together with SLEEP and misunderstanding on the usage of MMC_POWER_OFF power_mode from mmc_set_ios in different host controller drivers. This new patch works around this problem by adding a new host CAP, MMC_CAP2_POWER_OFF_VCCQ_DURING_SUSPEND, which when set sends a POWER OFF NOTIFY from mmc_suspend instead of SLEEP. It is expected that host controller drivers will set this CAP, if they switch off both Vcc and Vccq from MMC_POWER_OFF condition within mmc_set_ios. However, note that there is no harm in sending MMC_POWER_NOTIFY even if Vccq is not switched off. This patch also sends POWER OFF NOTIFY from power management routines (e.g. mmc_power_save_host, mmc_pm_notify/PM_SUSPEND_PREPARE, mmc_stop_host), which does reinitialization of the eMMC on the return path of the power management routines (e.g. mmc_power_restore_host, mmc_pm_notify/PM_POST_RESTORE, mmc_start_host). This patch sets POWER_OFF_NOTIFICATION to POWER_OFF_SHORT if it is sent from the suspend sequence. If it is sent from shutdown sequence then it is set to POWER_OFF_LONG. Earlier implementation of PowerOff Notify as a core function is replaced as a device's bus operation. For the cards that cannot cut vccq can sleep during suspend. But the after suspend-sleep-poweroff the ios values are modified. which results in malfunction of card after resume. This patch fixes that issue by saving the ios before sleep and restoring the saved values before resume. Signed-off-by: Saugata Das saugata@linaro.org Signed-off-by: Girish K S girish.shivananja...@linaro.org Signed-off-by: Asutosh Das asuto...@codeaurora.org Reviewed-by: Subhash Jadavani subha...@codeaurora.org I just had a chance to test this on OMAP. I only have v4.41 card on this one, so it doesn't do Power Off Notify, but suspend resume works with just CMD5, and hasn't caused a regression. FWIW, Partially Tested-by: Venkatraman Ssvenk...@ti.com -- 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: fix the data timeout issue with ACMD22
On Wed, Jun 13, 2012 at 5:10 PM, Subhash Jadavani
subha...@codeaurora.org wrote:
If multi block write operation fails for SD card, during
error handling we send the SD_APP_SEND_NUM_WR_BLKS (ACMD22)
to know how many blocks were already programmed by card.
But mmc_sd_num_wr_blocks() function which sends the ACMD22
calculates the data timeout value from csd.tacc_ns and
csd.tacc_clks parameters which will be 0 for block addressed
(2GB cards) SD card. This would result in timeout_ns and
timeout_clks being 0 in the mmc_request passed to host driver.
This means host controller would program its data timeout timer
value with 0 which could result in DATA TIMEOUT errors from
controller.
To fix this issue, mmc_sd_num_wr_blocks() should instead
just call the mmc_set_data_timeout() to calculate the
data timeout value. mmc_set_data_timeout() function
ensures that non zero timeout value is set even for
block addressed SD cards.
Signed-off-by: Subhash Jadavani subha...@codeaurora.org
The patch log could be improvised (Just mention that
set_data_timeout() is reused .. etc)
Even otherwise, its fine.
Reviewed-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/card/block.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 7e3f453..f1c84de 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -554,7 +554,6 @@ static u32 mmc_sd_num_wr_blocks(struct mmc_card *card)
struct mmc_request mrq = {NULL};
struct mmc_command cmd = {0};
struct mmc_data data = {0};
- unsigned int timeout_us;
struct scatterlist sg;
@@ -574,23 +573,12 @@ static u32 mmc_sd_num_wr_blocks(struct mmc_card *card)
cmd.arg = 0;
cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC;
- data.timeout_ns = card-csd.tacc_ns * 100;
- data.timeout_clks = card-csd.tacc_clks * 100;
-
- timeout_us = data.timeout_ns / 1000;
- timeout_us += data.timeout_clks * 1000 /
- (card-host-ios.clock / 1000);
-
- if (timeout_us 10) {
- data.timeout_ns = 1;
- data.timeout_clks = 0;
- }
-
data.blksz = 4;
data.blocks = 1;
data.flags = MMC_DATA_READ;
data.sg = sg;
data.sg_len = 1;
+ mmc_set_data_timeout(data, card);
mrq.cmd = cmd;
mrq.data = data;
--
--
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 v7 1/3] mmc: core: Add packed command feature of eMMC4.5
On Wed, Jun 13, 2012 at 12:45 AM, me...@codeaurora.org wrote: S, Venkatraman svenk...@ti.com wrote: On Mon, Jun 11, 2012 at 1:53 PM, Seungwon Jeon tgih@samsung.com wrote: This patch adds packed command feature of eMMC4.5. The maximum number for packing read(or write) is offered and exception event relevant to packed command which is used for error handling is enabled. If host wants to use this feature, MMC_CAP2_PACKED_CMD should be set. Signed-off-by: Seungwon Jeon tgih@samsung.com Can you please post some clear performance benchmarks with your patchset ? Given that #merez claims to see a significant performance drop for reads, it will be good to compare notes. If it's not too much trouble, both CFQ and deadline scheduler figures would be useful, on a set of read only, write only and parallel read write usecases. I can also try to replicate your results if you can publish the exact configuration you used for testing (example: iozone parameters) I'm checking the merez's result. Currently packed command is effective on write. When running packed write with iozone, there is 25% performance gains. (ex: iozone -az -i0 -I -s 10m -f /target/test -e) Our tests shows performance gain of 50-60% in scenarios of only write lmdd operations. As I mentioned in the write packing control thread the degradation of read performance in case of mix read/write operations appears also without write packing. Therefore I don't think it should stop us from approving the write packing patch, that gives a significant improvement to the write performance. The read performance degradation should be resolved regardless of the write packing patch. One further question - when you say degradation of read performance in case of mix read/write operations appears also without write packing, what exactly does that mean? Degradation w.r.to to read-only test ? Or any expected throughput ? If the scenario you mention is accurate, I was actually thinking that we should recommend to merge read packing first, then merge write packing once the read performance issue is well understood. I am all for better performance with packing control etc, but the overall code complexity is really increasing more than necessary. I want to make sure that it is really worth the effort. Thanks, Venkat. -- 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: commit dba3c29 ruins mmc card data on beagle-xm revB
On Mon, Jun 11, 2012 at 12:50 PM, Ming Lei ming@canonical.com wrote: On Mon, Jun 11, 2012 at 2:21 PM, T Krishnamoorthy, Balaji balaj...@ti.com wrote: Hi Ming Lei, Can you let me know if you noticed any write/timeout errors ? Nothing error logs found during writing. Below is one of my test case. root@beagleboard:~# upk updateing kernel... flush storage... root@beagleboard:~# cat bin/upk #!/bin/sh echo updateing kernel... cp -f /mnt/nfs/t/uImage /media/mmcblk0p1/ echo flush storage... sync root@beagleboard:~# diff /mnt/nfs/t/uImage /media/mmcblk0p1/uImage Binary files /mnt/nfs/t/uImage and /media/mmcblk0p1/uImage differ root@beagleboard:~# umount /media/mmcblk0p1 root@beagleboard:~# mount -t vfat /dev/mmcblk0p1 /media/mmcblk0p1 root@beagleboard:~# root@beagleboard:~# root@beagleboard:~# diff /mnt/nfs/t/uImage /media/mmcblk0p1/uImage Binary files /mnt/nfs/t/uImage and /media/mmcblk0p1/uImage differ Ming, Just to keep you posted, Balaji and myself are trying to reproduce the issue and haven't hit the problem yet. This patch was in use internaly for sometime before we sent it upstream. Meanwhile, is is possible for you to reproduce this problem with MMC_DEBUG enabled ? That would be helpful. ~Venkat. -- 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 1/1] mmc: block: Add write packing control
On Mon, Jun 11, 2012 at 7:25 PM, me...@codeaurora.org wrote:
Maya Erez me...@codeaurora.org wrote:
Hi,
How can we check the effect?
Do you have any result?
We ran parallel lmdd read and write operations and found out that the
write packing causes the read throughput to drop from 24MB/s to 12MB/s.
The write packing control managed to increase the read throughput back
to
the original value.
We also examined real life scenarios, such as performing a big push
operation in parallel to launching several applications. We measured the
read latency and found out that with the write packing control the worst
case of the read latency was smaller.
Please check the several comment below.
Maya Erez me...@codeaurora.org wrote:
The write packing control will ensure that read requests latency is
not increased due to long write packed commands.
The trigger for enabling the write packing is managing to pack
several
write requests. The number of potential packed requests that will
trigger
the packing can be configured via sysfs by writing the required value
to:
/sys/block/block_dev_name/num_wr_reqs_to_start_packing.
The trigger for disabling the write packing is fetching a read
request.
---
Documentation/mmc/mmc-dev-attrs.txt | 17 ++
drivers/mmc/card/block.c | 100
++-
drivers/mmc/card/queue.c | 8 +++
drivers/mmc/card/queue.h | 3 +
include/linux/mmc/host.h | 1 +
5 files changed, 128 insertions(+), 1 deletions(-)
diff --git a/Documentation/mmc/mmc-dev-attrs.txt
b/Documentation/mmc/mmc-dev-attrs.txt
index 22ae844..08f7312 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -8,6 +8,23 @@ The following attributes are read/write.
force_ro Enforce read-only access even if write protect
switch is
off.
+ num_wr_reqs_to_start_packing This attribute is used to determine
+ the trigger for activating the write packing, in case the write
+ packing control feature is enabled.
+
+ When the MMC manages to reach a point where
num_wr_reqs_to_start_packing
+ write requests could be packed, it enables the write packing
feature.
+ This allows us to start the write packing only when it is
beneficial
+ and has minimum affect on the read latency.
+
+ The number of potential packed requests that will trigger the
packing
+ can be configured via sysfs by writing the required value to:
+ /sys/block/block_dev_name/num_wr_reqs_to_start_packing.
+
+ The default value of num_wr_reqs_to_start_packing was determined by
+ running parallel lmdd write and lmdd read operations and
calculating
+ the max number of packed writes requests.
+
SD and MMC Device Attributes
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 2785fd4..ef192fb 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -114,6 +114,7 @@ struct mmc_blk_data {
struct device_attribute force_ro;
struct device_attribute power_ro_lock;
int area_type;
+ struct device_attribute num_wr_reqs_to_start_packing;
};
static DEFINE_MUTEX(open_lock);
@@ -281,6 +282,38 @@ out:
return ret;
}
+static ssize_t
+num_wr_reqs_to_start_packing_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
+ int num_wr_reqs_to_start_packing;
+ int ret;
+
+ num_wr_reqs_to_start_packing =
md-queue.num_wr_reqs_to_start_packing;
+
+ ret = snprintf(buf, PAGE_SIZE, %d\n,
num_wr_reqs_to_start_packing);
+
+ mmc_blk_put(md);
+ return ret;
+}
+
+static ssize_t
+num_wr_reqs_to_start_packing_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int value;
+ struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
+
+ sscanf(buf, %d, value);
+ if (value = 0)
+ md-queue.num_wr_reqs_to_start_packing = value;
+
+ mmc_blk_put(md);
+ return count;
+}
+
static int mmc_blk_open(struct block_device *bdev, fmode_t mode)
{
struct mmc_blk_data *md = mmc_blk_get(bdev-bd_disk);
@@ -1313,6 +1346,48 @@ static void mmc_blk_rw_rq_prep(struct
mmc_queue_req *mqrq,
mmc_queue_bounce_pre(mqrq);
}
+static void mmc_blk_write_packing_control(struct mmc_queue *mq,
+ struct request *req)
+{
+ struct mmc_host *host = mq-card-host;
+ int data_dir;
+
+ if (!(host-caps2 MMC_CAP2_PACKED_WR))
+ return;
+
+ /*
+ * In case the packing control is not supported by the host, it
should
+ * not have an effect on the write packing. Therefore we have to
enable
+ * the write packing
+ */
+ if (!(host-caps2
Re: [PATCH v2 0/1] block: Add test-iosched scheduler
On Sat, Jun 9, 2012 at 8:24 PM, me...@codeaurora.org wrote: On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez me...@codeaurora.org wrote: 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 I can't get the point. Isn't this possible purely from userspace using IOCTLs ? Even otherwise, requiring to modify the scheduler for each test case is definitely not scalable. The main benefit of the test-iosched is the ability to determine the timing of each request that is being dispatched and to put on hold the real FS requests so that they won't affect the tests scenario. Then a potentially long running test can block any useful work that can be done on the device. no-op is not the right scheduler for the example you mentioned (eMMC), so such device has to be mounted only for the purpose of running the tests. So using standard noop + debugfs would be sufficient for 99% of the cases ? It also allows each block device to determine pass/fail result taking into account the expected behavior and the actual result. The scheduler doesn't have to be changed per tests case. What made you think it should be? Err.. I misread this section of documentation. I read is as sysfs instead of debugfs. My mistake.. Quote +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. /Quote Currently we use the test-iosched to test the eMMC4.5 features (such as BKOPs, packed commands and sanitize). I hope that after we will release the tests later this week it will be clearer. Sure. It'd be useful. -- 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 1/1] mmc: block: Add write packing control
On Sat, Jun 9, 2012 at 8:16 PM, me...@codeaurora.org wrote: Hi, How can we check the effect? Do you have any result? We ran parallel lmdd read and write operations and found out that the write packing causes the read throughput to drop from 24MB/s to 12MB/s. Whoa! That's a big drop. BTW, is there a problem with throughput or latency, or both ? If these numbers are over long duration (5 seconds), then where are the cycles going? It would be nice to see some blktrace figures for the issue, and then fix it, rather than apply a band aid like the write-packing-control on top.. The write packing control managed to increase the read throughput back to the original value. We also examined real life scenarios, such as performing a big push operation in parallel to launching several applications. We measured the read latency and found out that with the write packing control the worst case of the read latency was smaller. Please check the several comment below. Maya Erez me...@codeaurora.org wrote: The write packing control will ensure that read requests latency is not increased due to long write packed commands. The trigger for enabling the write packing is managing to pack several write requests. The number of potential packed requests that will trigger the packing can be configured via sysfs by writing the required value to: /sys/block/block_dev_name/num_wr_reqs_to_start_packing. The trigger for disabling the write packing is fetching a read request. -- 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 1/1] mmc: block: Add write packing control
On Tue, Jun 12, 2012 at 1:40 AM, me...@codeaurora.org wrote:
On Mon, Jun 11, 2012 at 7:25 PM, me...@codeaurora.org wrote:
Maya Erez me...@codeaurora.org wrote:
Hi,
How can we check the effect?
Do you have any result?
We ran parallel lmdd read and write operations and found out that the
write packing causes the read throughput to drop from 24MB/s to
12MB/s.
The write packing control managed to increase the read throughput back
to
the original value.
We also examined real life scenarios, such as performing a big push
operation in parallel to launching several applications. We measured
the
read latency and found out that with the write packing control the
worst
case of the read latency was smaller.
Please check the several comment below.
Maya Erez me...@codeaurora.org wrote:
The write packing control will ensure that read requests latency is
not increased due to long write packed commands.
The trigger for enabling the write packing is managing to pack
several
write requests. The number of potential packed requests that will
trigger
the packing can be configured via sysfs by writing the required
value
to:
/sys/block/block_dev_name/num_wr_reqs_to_start_packing.
The trigger for disabling the write packing is fetching a read
request.
---
Documentation/mmc/mmc-dev-attrs.txt | 17 ++
drivers/mmc/card/block.c | 100
++-
drivers/mmc/card/queue.c | 8 +++
drivers/mmc/card/queue.h | 3 +
include/linux/mmc/host.h | 1 +
5 files changed, 128 insertions(+), 1 deletions(-)
diff --git a/Documentation/mmc/mmc-dev-attrs.txt
b/Documentation/mmc/mmc-dev-attrs.txt
index 22ae844..08f7312 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -8,6 +8,23 @@ The following attributes are read/write.
force_ro Enforce read-only access even if write
protect switch is
off.
+ num_wr_reqs_to_start_packing This attribute is used to
determine
+ the trigger for activating the write packing, in case the write
+ packing control feature is enabled.
+
+ When the MMC manages to reach a point where
num_wr_reqs_to_start_packing
+ write requests could be packed, it enables the write packing
feature.
+ This allows us to start the write packing only when it is
beneficial
+ and has minimum affect on the read latency.
+
+ The number of potential packed requests that will trigger the
packing
+ can be configured via sysfs by writing the required value to:
+ /sys/block/block_dev_name/num_wr_reqs_to_start_packing.
+
+ The default value of num_wr_reqs_to_start_packing was determined
by
+ running parallel lmdd write and lmdd read operations and
calculating
+ the max number of packed writes requests.
+
SD and MMC Device Attributes
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 2785fd4..ef192fb 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -114,6 +114,7 @@ struct mmc_blk_data {
struct device_attribute force_ro;
struct device_attribute power_ro_lock;
int area_type;
+ struct device_attribute num_wr_reqs_to_start_packing;
};
static DEFINE_MUTEX(open_lock);
@@ -281,6 +282,38 @@ out:
return ret;
}
+static ssize_t
+num_wr_reqs_to_start_packing_show(struct device *dev,
+ struct device_attribute *attr, char
*buf)
+{
+ struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
+ int num_wr_reqs_to_start_packing;
+ int ret;
+
+ num_wr_reqs_to_start_packing =
md-queue.num_wr_reqs_to_start_packing;
+
+ ret = snprintf(buf, PAGE_SIZE, %d\n,
num_wr_reqs_to_start_packing);
+
+ mmc_blk_put(md);
+ return ret;
+}
+
+static ssize_t
+num_wr_reqs_to_start_packing_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int value;
+ struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
+
+ sscanf(buf, %d, value);
+ if (value = 0)
+ md-queue.num_wr_reqs_to_start_packing = value;
+
+ mmc_blk_put(md);
+ return count;
+}
+
static int mmc_blk_open(struct block_device *bdev, fmode_t mode)
{
struct mmc_blk_data *md = mmc_blk_get(bdev-bd_disk);
@@ -1313,6 +1346,48 @@ static void mmc_blk_rw_rq_prep(struct
mmc_queue_req *mqrq,
mmc_queue_bounce_pre(mqrq);
}
+static void mmc_blk_write_packing_control(struct mmc_queue *mq,
+ struct request *req)
+{
+ struct mmc_host *host = mq-card-host;
+ int data_dir;
+
+ if (!(host-caps2 MMC_CAP2_PACKED_WR))
+ return;
+
+ /*
+ * In case the packing control is not supported by the host, it
should
+ * not have an effect on the write packing. Therefore we have to
Re: [PATCH v7 1/3] mmc: core: Add packed command feature of eMMC4.5
On Mon, Jun 11, 2012 at 1:53 PM, Seungwon Jeon tgih@samsung.com wrote:
This patch adds packed command feature of eMMC4.5.
The maximum number for packing read(or write) is offered
and exception event relevant to packed command which is
used for error handling is enabled. If host wants to use
this feature, MMC_CAP2_PACKED_CMD should be set.
Signed-off-by: Seungwon Jeon tgih@samsung.com
Can you please post some clear performance benchmarks with your patchset ?
Given that #merez claims to see a significant performance drop for
reads, it will be
good to compare notes.
If it's not too much trouble, both CFQ and deadline scheduler figures
would be useful, on a
set of read only, write only and parallel read write usecases.
I can also try to replicate your results if you can publish the exact
configuration you used
for testing (example: iozone parameters)
---
drivers/mmc/core/mmc.c | 24
include/linux/mmc/card.h | 3 +++
include/linux/mmc/host.h | 4
include/linux/mmc/mmc.h | 15 +++
4 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 258b203..f9d54b0 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -516,6 +516,11 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
} else {
card-ext_csd.data_tag_unit_size = 0;
}
+
+ card-ext_csd.max_packed_writes =
+ ext_csd[EXT_CSD_MAX_PACKED_WRITES];
+ card-ext_csd.max_packed_reads =
+ ext_csd[EXT_CSD_MAX_PACKED_READS];
} else {
card-ext_csd.data_sector_size = 512;
}
@@ -1246,6 +1251,25 @@ static int mmc_init_card(struct mmc_host *host, u32
ocr,
}
}
+ if ((host-caps2 MMC_CAP2_PACKED_CMD)
+ ((card-ext_csd.max_packed_writes 0) ||
+ (card-ext_csd.max_packed_reads 0))) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_EXP_EVENTS_CTRL,
+ EXT_CSD_PACKED_EVENT_EN,
+ card-ext_csd.generic_cmd6_time);
+ if (err err != -EBADMSG)
+ goto free_card;
+ if (err) {
+ pr_warning(%s: Enabling packed event failed\n,
+ mmc_hostname(card-host));
+ card-ext_csd.packed_event_en = 0;
+ err = 0;
+ } else {
+ card-ext_csd.packed_event_en = 1;
+ }
+ }
+
if (!oldcard)
host-card = card;
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index d76513b..4aeb4e9 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -53,6 +53,9 @@ struct mmc_ext_csd {
u8 part_config;
u8 cache_ctrl;
u8 rst_n_function;
+ u8 max_packed_writes;
+ u8 max_packed_reads;
+ u8 packed_event_en;
unsigned int part_time; /* Units: ms */
unsigned int sa_timeout; /* Units: 100ns */
unsigned int generic_cmd6_time; /* Units: 10ms */
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 0707d22..9d0d946 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -238,6 +238,10 @@ struct mmc_host {
#define MMC_CAP2_BROKEN_VOLTAGE (1 7) /* Use the broken
voltage */
#define MMC_CAP2_DETECT_ON_ERR (1 8) /* On I/O err check card
removal */
#define MMC_CAP2_HC_ERASE_SZ (1 9) /* High-capacity erase size */
+#define MMC_CAP2_PACKED_RD (1 10) /* Allow packed read */
+#define MMC_CAP2_PACKED_WR (1 11) /* Allow packed write */
+#define MMC_CAP2_PACKED_CMD (MMC_CAP2_PACKED_RD | \
+ MMC_CAP2_PACKED_WR) /* Allow packed commands
*/
mmc_pm_flag_t pm_caps; /* supported pm features */
unsigned int power_notify_type;
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index d425cab..254901a 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -139,6 +139,7 @@ static inline bool mmc_op_multi(u32 opcode)
#define R1_CURRENT_STATE(x) ((x 0x1E00) 9) /* sx, b (4 bits) */
#define R1_READY_FOR_DATA (1 8) /* sx, a */
#define R1_SWITCH_ERROR (1 7) /* sx, c */
+#define R1_EXP_EVENT (1 6) /* sr, a */
#define R1_APP_CMD (1 5) /* sr, c */
#define R1_STATE_IDLE 0
@@ -274,6 +275,10 @@ struct
Re: [PATCH v2 0/1] block: Add test-iosched scheduler
On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez me...@codeaurora.org wrote: 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 I can't get the point. Isn't this possible purely from userspace using IOCTLs ? Even otherwise, requiring to modify the scheduler for each test case is definitely not scalable. 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 -- 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 v6 0/2] *** adding and exposing SANITIZE capability to the user space via a unique IOCTL ***
On Thu, Jun 7, 2012 at 8:08 PM, Yaniv Gardi yga...@codeaurora.org wrote: *** adding and exposing SANITIZE capability to the user space via a unique IOCTL *** Well, is this really needed ? As I understand, SANITIZE is identical to REQ_SECURE + REQ_DISCARD. Mapping the device function to an existing attribute is more easy that creating the whole plumbing around SANITIZE, just because it exists. Apart from the IOCTL, it would be useful to find if any file systems want to use this, and it is any way more friendly than SECURE + DISCARD. changes patch v6: fixed some code review comments added timeout dependency for CMD6 when issueing the sanitize command. changes patch v5: added BUG_ON() where needed changes patch v4: removed a few debug printouts changes patch v3: split the patch into 2 commits - block and mmc/card added capability MMC_CAP2_SANITIZE to mmc controller Yaniv Gardi (2): block: ioctl support for sanitize in eMMC 4.5 mmc: card: Adding support for sanitize in eMMC 4.5 block/blk-core.c | 18 +-- block/blk-lib.c | 51 +++ block/blk-merge.c | 6 block/elevator.c | 41 - block/ioctl.c | 9 + drivers/mmc/card/block.c | 72 drivers/mmc/card/queue.c | 10 +- include/linux/blk_types.h | 5 ++- include/linux/blkdev.h | 3 ++ include/linux/fs.h | 1 + include/linux/mmc/host.h | 1 + kernel/trace/blktrace.c | 2 + 12 files changed, 191 insertions(+), 28 deletions(-) -- 1.7.6 -- 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 -- 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: power class selection fails on 3.5-rc1
On Mon, Jun 4, 2012 at 10:05 PM, Marc Dietrich marvi...@gmx.de 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 0x0a 50 0x32 239 0 0x00 51 0x33 238 0 0x00 119 0x77 234 0 0x00 30 0x1e 232 1 0x01 4 0x04 231 21 0x15 21 0x15 230 150 0x96 16 0x10 229 150 0x96 66 0x42 228 1 0x01 7 0x07 226 8 0x08 16 0x10 225 6 0x06 7 0x07 224 4 0x04 8 0x08 223 1 0x01 2 0x02 222 8 0x08 16 0x10 221 16 0x10 1 0x01 220 8 0x08 7 0x07 219 7 0x07 7 0x07 217 16 0x10 17 0x11 215 1 0x01 0 0x00 214 218 0xda 238 0xee 213 160 0xa0 128 0x80 210 10 0x0a 0 0x00 209 10 0x0a 60 0x3c 208 10 0x0a 0 0x00 207 10 0x0a 60 0x3c 206 10 0x0a 0 0x00 205 10 0x0a 30 0x1e 203 0 0x00 51 0x33 202 0 0x00 51 0x33 201 0 0x00 119 0x77 200 0 0x00 119 0x77 196 3 0x03 7 0x07 194 2 0x02 2 0x02 192 5 0x05 5 0x05 185 1 0x01 1 0x01 181 0 0x00 1 0x01 179 0 0x00 1 0x01 175 0 0x00 1 0x01 169 1 0x01 0 0x00 168 0 0x00 2 0x02 160 3 0x03 3 0x03 158 0 0x00 3 0x03 157 237 0xed 186 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 am a bit rusty here, so bear with me. According to the ext_csd, the power class value that should be sent to the card was 0x7. (Upper nibble of ext_csd[201]). What I saw in the attached debug Log: [3.842390] mmc1: starting CMD6 arg 03bb0301 flags 049d This means write 0x03 into 0xBB register, and not 0x7 which is what is needed. While Marc has tried all values from 0 to 10, this wouldn't be the definite issue, but I am wondering is there is some other problem. Or have I got it all wrong ? ~Venkat. -- 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: [CFT 03/11] mmc: omap_hsmmc: remove private DMA API implementation
On Thu, Jun 7, 2012 at 4:37 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: Remove the private DMA API implementation from omap_hsmmc, making it use entirely the DMA engine API. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested this on 4430SDP with rootfs usage, untarring the kernel source and compiling it natively. Tested-by: Venkatraman S svenk...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 265 ++--- 1 files changed, 64 insertions(+), 201 deletions(-) -- 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 v6 2/3] mmc: core: Support packed write command for eMMC4.5 device
On Thu, May 17, 2012 at 5:41 PM, Seungwon Jeon tgih@samsung.com wrote:
This patch supports packed write command of eMMC4.5 device.
Several writes can be grouped in packed command and all data
of the individual commands can be sent in a single transfer
on the bus.
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/card/block.c | 381
+---
drivers/mmc/card/queue.c | 45 +-
drivers/mmc/card/queue.h | 11 ++
drivers/mmc/core/mmc_ops.c | 1 +
include/linux/mmc/core.h | 4 +
5 files changed, 420 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 91cda75..8f475b1 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -58,6 +58,12 @@ MODULE_ALIAS(mmc:block);
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
+#define mmc_req_rel_wr(req) (((req-cmd_flags REQ_FUA) || \
+ (req-cmd_flags REQ_META)) \
+ (rq_data_dir(req) == WRITE))
+#define PACKED_CMD_VER 0x01
+#define PACKED_CMD_WR 0x02
+
static DEFINE_MUTEX(block_mutex);
/*
@@ -123,9 +129,21 @@ enum mmc_blk_status {
MMC_BLK_NOMEDIUM,
};
+enum {
+ MMC_PACKED_N_IDX = -1,
+ MMC_PACKED_N_ZERO,
+ MMC_PACKED_N_SINGLE,
+};
+
module_param(perdev_minors, int, 0444);
MODULE_PARM_DESC(perdev_minors, Minors numbers to allocate per device);
+static inline void mmc_blk_clear_packed(struct mmc_queue_req *mqrq)
+{
+ mqrq-packed_cmd = MMC_PACKED_NONE;
+ mqrq-packed_num = MMC_PACKED_N_ZERO;
+}
+
static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
{
struct mmc_blk_data *md;
@@ -1087,12 +1105,60 @@ static int mmc_blk_err_check(struct mmc_card *card,
if (!brq-data.bytes_xfered)
return MMC_BLK_RETRY;
+ if (mq_mrq-packed_cmd != MMC_PACKED_NONE) {
+ if (unlikely(brq-data.blocks 9 != brq-data.bytes_xfered))
+ return MMC_BLK_PARTIAL;
+ else
+ return MMC_BLK_SUCCESS;
+ }
+
if (blk_rq_bytes(req) != brq-data.bytes_xfered)
return MMC_BLK_PARTIAL;
return MMC_BLK_SUCCESS;
}
+static int mmc_blk_packed_err_check(struct mmc_card *card,
+ struct mmc_async_req *areq)
+{
+ struct mmc_queue_req *mq_rq = container_of(areq, struct mmc_queue_req,
+ mmc_active);
+ struct request *req = mq_rq-req;
+ int err, check, status;
+ u8 ext_csd[512];
+
+ check = mmc_blk_err_check(card, areq);
+ err = get_card_status(card, status, 0);
+ if (err) {
+ pr_err(%s: error %d sending status command\n,
+ req-rq_disk-disk_name, err);
+ return MMC_BLK_ABORT;
+ }
+
+ if (status R1_EXP_EVENT) {
+ err = mmc_send_ext_csd(card, ext_csd);
+ if (err) {
+ pr_err(%s: error %d sending ext_csd\n,
+ req-rq_disk-disk_name, err);
+ return MMC_BLK_ABORT;
+ }
+
+ if ((ext_csd[EXT_CSD_EXP_EVENTS_STATUS]
+ EXT_CSD_PACKED_FAILURE)
+ (ext_csd[EXT_CSD_PACKED_CMD_STATUS]
+ EXT_CSD_PACKED_GENERIC_ERROR)) {
+ if (ext_csd[EXT_CSD_PACKED_CMD_STATUS]
+ EXT_CSD_PACKED_INDEXED_ERROR) {
+ mq_rq-packed_fail_idx =
+ ext_csd[EXT_CSD_PACKED_FAILURE_INDEX] - 1;
+ return MMC_BLK_PARTIAL;
+ }
+ }
+ }
+
+ return check;
+}
+
static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
struct mmc_card *card,
int disable_multi,
@@ -1247,10 +1313,196 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
*mqrq,
mmc_queue_bounce_pre(mqrq);
}
+static u8 mmc_blk_prep_packed_list(struct mmc_queue *mq, struct request *req)
+{
+ struct request_queue *q = mq-queue;
+ struct mmc_card *card = mq-card;
+ struct request *cur = req, *next = NULL;
+ struct mmc_blk_data *md = mq-data;
+ bool en_rel_wr = card-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN;
+ unsigned int req_sectors = 0, phys_segments = 0;
+ unsigned int max_blk_count, max_phys_segs;
+ u8 put_back = 0;
+ u8 max_packed_rw = 0;
+ u8 reqs = 0;
+
+ mmc_blk_clear_packed(mq-mqrq_cur);
+
+ if (!(md-flags MMC_BLK_CMD23) ||
+ !card-ext_csd.packed_event_en)
+ goto no_packed;
+
+ if
Re: [PATCH 0/3] mmc:sd hotplug fixes for omap
On Fri, May 25, 2012 at 1:44 AM, Viswanath Puttagunta vi...@ti.com wrote: This patch set has fixes for SD card hotplug for OMAP SOCs. Viswanath Puttagunta (3): mmc: omap_hsmmc: Errata i705: SD hot unplug mmc: omap_hsmmc: Errata: Fix SD card removal detection mfd: Enable Debounce logic for SD hotplug detection Please copy linux-o...@vger.kernel.org as well, for these patches. drivers/mfd/twl6030-irq.c | 8 drivers/mmc/host/omap_hsmmc.c | 41 ++--- include/linux/i2c/twl.h | 5 + 3 files changed, 51 insertions(+), 3 deletions(-) -- 1.7.4.1 -- 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 3/3] mfd: Enable Debounce logic for SD hotplug detection
On Fri, May 25, 2012 at 1:44 AM, Viswanath Puttagunta vi...@ti.com wrote:
Enable debounce logic in TWL6030 so that erroneous
disconnect/connect interrupts will be suppressed.
This will fix issue where SD card is either plugged
or unplugged very slowly.
Change-Id: Icc3afa4c66b3bc7920f27ff9c9a3f32e67d5833c
Signed-off-by: Viswanath Puttagunta vi...@ti.com
Would be better without the Change-Id.
Also, this needs to be posted to linux-omap and linux-mfd, apart from linux-mmc.
---
drivers/mfd/twl6030-irq.c | 8
include/linux/i2c/twl.h | 5 +
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index b76902f..05bb6e1 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -317,6 +317,14 @@ int twl6030_mmc_card_detect_config(void)
ret);
return ret;
}
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0,
+ (MMC_MINS_DEB_MASK | MMC_MEXT_DEB_MASK),
+ TWL6030_MMCDEBOUNCING);
+ if (ret 0) {
+ pr_err(twl6030: Failed to write MMC_MEXT_DEB_MASK %d\n,
+ ret);
+ return ret;
+ }
return twl6030_irq_base + MMCDETECT_INTR_OFFSET;
}
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 1f90de0..672dcfb 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -147,6 +147,11 @@
#define SW_FC (0x1 2)
#define STS_MMC 0x1
+#define TWL6030_MMCDEBOUNCING 0xED
+#define MMC_DEB_BYPASS (0x1 7)
+#define MMC_MINS_DEB_MASK (0xF 3)
+#define MMC_MEXT_DEB_MASK (0x7 0)
Some description about what these values mean (timing etc) would be helpful.
+
#define TWL6030_CFG_INPUT_PUPD3 0xF2
#define MMC_PU (0x1 3)
#define MMC_PD (0x1 2)
--
1.7.4.1
--
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/3] mmc: omap_hsmmc: Errata i705: SD hot unplug
On Fri, May 25, 2012 at 1:44 AM, Viswanath Puttagunta vi...@ti.com wrote:
Turn off IO PBIAS cells and then SD card VMMC as soon
as we get disconnect interrupt. Failure to do so might
cause current spikes (latch-up issue) which can potentially
burn the IO cells.
Signed-off-by: Viswanath Puttagunta vi...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 56d4499..61d830f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1177,10 +1177,17 @@ static irqreturn_t omap_hsmmc_detect(int irq, void
*dev_id)
carddetect = -ENOSYS;
}
- if (carddetect)
+ if (carddetect) {
mmc_detect_change(host-mmc, (HZ * 200) / 1000);
- else
- mmc_detect_change(host-mmc, (HZ * 50) / 1000);
+ } else {
+ if ((MMC_POWER_OFF != host-power_mode)
Should be if((host-power_mode != MMC_POWER_OFF)
+ (mmc_slot(host).set_power != NULL)) {
+ mmc_slot(host).set_power(host-dev, host-slot_id,
+ 0, 0);
+ host-power_mode = MMC_POWER_OFF;
This is just changing the default behaviour, irrespective of whether
the errata is applicable.
What is the effect of this change for other boards / platforms ?
+ }
+ mmc_detect_change(host-mmc, 0);
+ }
return IRQ_HANDLED;
}
--
1.7.4.1
--
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 -next] mmc: omap_hsmmc: pass IRQF_ONESHOT to request_threaded_irq
On Thu, May 17, 2012 at 7:57 AM, Ming Lei ming@canonical.com wrote:
The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
otherwise the following failure message should be dumped because
hardware handler is defined as NULL:
[ 3.383483] genirq: Threaded irq requested with handler=NULL and
!ONESHOT for irq 368
[ 3.392730] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22
The patch fixes one kernel hang bug which is caused by mmc card
probe failure and root device can't be brought up.
Signed-off-by: Ming Lei ming@canonical.com
Right thing to do!
Acked-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ebaf62a..9a7a60a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1981,7 +1981,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
ret = request_threaded_irq(mmc_slot(host).card_detect_irq,
NULL,
omap_hsmmc_detect,
- IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc),
--
1.7.9.5
--
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: [PATCH 15/29] mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions
On Thu, May 3, 2012 at 8:35 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
GPIOs can be used in MMC/SD-card slots not only for hotplug detection, but
also to implement the write-protection pin. Rename cd-gpio helpers to
slot-gpio to make addition of further slot GPIO functions possible.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/core/Makefile | 2 +-
drivers/mmc/core/cd-gpio.c | 83
---
drivers/mmc/core/slot-gpio.c | 83
+++
drivers/mmc/host/tmio_mmc_pio.c | 6 +-
include/linux/mmc/cd-gpio.h | 18
include/linux/mmc/slot-gpio.h | 18
6 files changed, 105 insertions(+), 105 deletions(-)
delete mode 100644 drivers/mmc/core/cd-gpio.c
create mode 100644 drivers/mmc/core/slot-gpio.c
delete mode 100644 include/linux/mmc/cd-gpio.h
create mode 100644 include/linux/mmc/slot-gpio.h
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index dca4428..38ed210 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -7,6 +7,6 @@ mmc_core-y := core.o bus.o host.o \
mmc.o mmc_ops.o sd.o sd_ops.o \
sdio.o sdio_ops.o sdio_bus.o \
sdio_cis.o sdio_io.o sdio_irq.o \
- quirks.o cd-gpio.o
+ quirks.o slot-gpio.o
mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
diff --git a/drivers/mmc/core/cd-gpio.c b/drivers/mmc/core/cd-gpio.c
deleted file mode 100644
index f13e38d..000
--- a/drivers/mmc/core/cd-gpio.c
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
- * Generic GPIO card-detect helper
- *
- * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/err.h
-#include linux/gpio.h
-#include linux/interrupt.h
-#include linux/jiffies.h
-#include linux/mmc/cd-gpio.h
-#include linux/mmc/host.h
-#include linux/module.h
-#include linux/slab.h
-
-struct mmc_cd_gpio {
- unsigned int gpio;
- char label[0];
-};
-
-static irqreturn_t mmc_cd_gpio_irqt(int irq, void *dev_id)
-{
- /* Schedule a card detection after a debounce timeout */
- mmc_detect_change(dev_id, msecs_to_jiffies(100));
- return IRQ_HANDLED;
-}
-
-int mmc_cd_gpio_request(struct mmc_host *host, unsigned int gpio)
-{
- size_t len = strlen(dev_name(host-parent)) + 4;
- struct mmc_cd_gpio *cd;
- int irq = gpio_to_irq(gpio);
- int ret;
-
- if (irq 0)
- return irq;
-
- cd = kmalloc(sizeof(*cd) + len, GFP_KERNEL);
- if (!cd)
- return -ENOMEM;
-
- snprintf(cd-label, len, %s cd, dev_name(host-parent));
-
- ret = gpio_request_one(gpio, GPIOF_DIR_IN, cd-label);
- if (ret 0)
- goto egpioreq;
-
- ret = request_threaded_irq(irq, NULL, mmc_cd_gpio_irqt,
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
- cd-label, host);
- if (ret 0)
- goto eirqreq;
-
- cd-gpio = gpio;
- host-hotplug.irq = irq;
- host-hotplug.handler_priv = cd;
-
- return 0;
-
-eirqreq:
- gpio_free(gpio);
-egpioreq:
- kfree(cd);
- return ret;
-}
-EXPORT_SYMBOL(mmc_cd_gpio_request);
-
-void mmc_cd_gpio_free(struct mmc_host *host)
-{
- struct mmc_cd_gpio *cd = host-hotplug.handler_priv;
-
- if (!cd)
- return;
-
- free_irq(host-hotplug.irq, host);
- gpio_free(cd-gpio);
- kfree(cd);
-}
-EXPORT_SYMBOL(mmc_cd_gpio_free);
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
new file mode 100644
index 000..17d705f
--- /dev/null
+++ b/drivers/mmc/core/slot-gpio.c
@@ -0,0 +1,83 @@
+/*
+ * Generic GPIO card-detect helper
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/jiffies.h
+#include linux/mmc/host.h
+#include linux/mmc/slot-gpio.h
+#include linux/module.h
+#include linux/slab.h
+
+struct mmc_gpio {
+ unsigned int cd_gpio;
+ char cd_label[0];
+};
+
+static irqreturn_t mmc_gpio_cd_irqt(int irq, void *dev_id)
+{
+ /* Schedule a card detection after a debounce timeout */
+ mmc_detect_change(dev_id, msecs_to_jiffies(100));
+
Re: [RFC 1/2] [MMC-4.5] Disable emulation
On Tue, May 15, 2012 at 12:10 PM, Subhash Jadavani subha...@codeaurora.org wrote: On 5/14/2012 8:21 PM, Saugata Das wrote: On 14 May 2012 15:55, Subhash Jadavanisubha...@codeaurora.org wrote: On 5/9/2012 8:18 PM, Saugata Das wrote: From: Saugata Dassaugata@linaro.org This patch adds the support for large sector size of 4KB by disabling emulation. This patch passes eMMC DATA_SECTOR_SIZE as the logical block size during mmc_blk_alloc_req. In order to use this patch for 4KB sector size, ensure that USE_NATIVE_SECTOR is enabled, partition table is 4KB sector size aligned and file system block size is 4KB. Signed-off-by: Saugata Dassaugata@linaro.org --- drivers/mmc/card/block.c | 6 +- drivers/mmc/core/mmc.c | 2 ++ 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index a7c75d8..0e54118e 100644 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -1517,7 +1517,11 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, snprintf(md-disk-disk_name, sizeof(md-disk-disk_name), mmcblk%d%s, md-name_idx, subname ? subname : ); - blk_queue_logical_block_size(md-queue.queue, 512); + if (mmc_card_mmc(card)) + blk_queue_logical_block_size(md-queue.queue, + card-ext_csd.data_sector_size); Shouldn't we also set the physical block size to NATIVE_SECTOR_SIZE value? The physical block size gets set from blk_queue_logical_block_size Other question, Did you find any eMMC device which 4K native sector size? If yes, please share the test results. I have not yet seen the eMMC device implementing 4KB sector. But MMC vendors are promising this feature, so I prepared this patch. So far, I have tested by setting data_sector_size to 4KB (doing a hack in mmc_read_ext_csd), configuring file system to have 4KB block size and mounting it. Ok. So basically you are emulating the 512B native sector device as 4K native sector device and always read/write this device in 4K granularity. So this is just a proof of concept that setting the block queue logical sector size to 4K works or not? Are vendors promising any performance improvement if we run the device in 4K sector size mode rather than emulation mode? I have few other doubts (from specification point of view) when the device starts running in native sector size mode: 1. According spec, A large sector device shall not support partial access and shall not support reliable write mode EN_REL_WR=0. Shouldn't this patch make ensure this? 2. Some internal sizes reported by the device may change after successfully disabling of the emulation mode. Shouldn't we take of this as well? This would be because if a single 512byte sector was marked as bad (unusable) initially, the entire aligned 4K block would be marked as bad now after switching to 4K sector size, resulting in a slight capacity shrinkage. This would only matter if the switch happens for a fairly old device. Typically, the sector size change should happen during factory initialization, so there wouldn't be too many bad blocks, so it shouldn't be much of an issue now. Of course, this is just one aspect of a problem for the dynamic device capacity feature of eMMC4.5, and can be solved if we get to that.. 3. After a successful disabling of the emulation mode, the content of the User Data Area is undefined. If the contents of the user data area is undefined after disabling the emulation mode, i don't think device will be able to boot to kernel after power cycle. So does this mean we have to flash the kernel/file system images again? Basically i don't see a use of disabling the emulation mode from kernel. It should be done by basic build/image flashing utility which could flash the images after setting the use_native_sector field and power cycle. 4. Data transfers on the bus are still using 512B CRC-protected blocks, but data shall only be transferred in multiple of 8 such blocks (always multiples of 4KB) So this means host controller still will be configured in 512B sector mode but amount of data will be in multple of 8 such 512B blocks? 5. Sector addressing is still used, but sector addresses shall always be aligned to 8 (4KB) How the sector addressing work here? will the sector address (at argument of read/write commands) of byte address 0x1000 be 1 or 8? 512B sector addressing: (byte address) (sector address) 0x = 0 0x0200 = 1 0x0400 = 2 0x0600 = 3 0x0800 = 4 0x0A00 = 5 0x0C00 = 6 0x0E00 = 7 0x1000 = 8
Re: [PATCH] mmc:sdio:retry CMD52/53 when error happens
On Mon, May 14, 2012 at 2:09 PM, yongd yo...@marvell.com wrote: Set sdio CMD52/53's retry time as MMC_CMD_RETRIES. As a result, sdio might benefit from core-internal CMD retry mechanism when some errors happen(CRC, etc). Signed-off-by: yongd yo...@marvell.com --- drivers/mmc/core/sdio_ops.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/core/sdio_ops.c b/drivers/mmc/core/sdio_ops.c index d29e206..884c27e 100644 --- a/drivers/mmc/core/sdio_ops.c +++ b/drivers/mmc/core/sdio_ops.c @@ -86,7 +86,7 @@ static int mmc_io_rw_direct_host(struct mmc_host *host, int write, unsigned fn, cmd.arg |= in; cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_AC; - err = mmc_wait_for_cmd(host, cmd, 0); + err = mmc_wait_for_cmd(host, cmd, MMC_CMD_RETRIES); if (err) return err; @@ -147,6 +147,7 @@ int mmc_io_rw_extended(struct mmc_card *card, int write, unsigned fn, else cmd.arg |= 0x0800 | blocks; /* block mode */ cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_ADTC; + cmd.retries = MMC_CMD_RETRIES; data.blksz = blksz; /* Code in host drivers/fwk assumes that blocks always is =1 */ -- Looks right to me. Reviewed-by: Venkatraman S svenk...@ti.com -- 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 4/4] mmc: core: Send HPI only till it is successful
On Wed, May 9, 2012 at 8:20 PM, Philip Rakity prak...@marvell.com wrote:
On Apr 13, 2012, at 7:39 AM, Namjae Jeon wrote:
Hi. Venkatraman.
You fixed 10 times. why is it 10 times ?
and checking err from mmc_send_status is not needed ? is it also
infinite case ?
Thanks.
2012/4/13 Venkatraman S svenk...@ti.com:
Try to send HPI only a fixed number of times till it is
successful. One successful transfer is enough - but wait
till the card comes out of transfer state.
Return an error if the card was not in programming state to
begin with - so that the caller knows that HPI was not sent.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/core/core.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..ceabef5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -401,7 +401,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
*/
int mmc_interrupt_hpi(struct mmc_card *card)
{
- int err;
+ int err, i;
u32 status;
BUG_ON(!card);
@@ -421,27 +421,29 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
+ err = -EINVAL;
if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs when
- * sending the HPI command, we are already out of
- * prg-state.
- */
+ /* To prevent an infinite lockout, try to send HPI
+ * a fixed number of times and bailout if it can't
+ * succeed.
+ */
+ for (i = 0; i 10 err != 0 ; i++)
would it make more sense to check time as well as retry count ?
worry that count may be too short or behavior is dependent on card
manufacturer.
This patch is discarded. Let me know if you have some comments on the
follow up patch with
the subject mmc: fix HPI execution sequence
err = mmc_send_hpi_cmd(card, status);
- if (err)
+ /* Once HPI was sent successfully, the card is
+ * supposed to be back to transfer state.
+ */
+ do {
+ if (err) {
pr_debug(%s: abort HPI (%d error)\n,
mmc_hostname(card-host), err);
-
- err = mmc_send_status(card, status);
- if (err)
break;
+ }
+ err = mmc_send_status(card, status);
} while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
- } else
- pr_debug(%s: Left prg-state\n, mmc_hostname(card-host));
+ } else {
+ pr_debug(%s: Can't send HPI. State=%d\n,
+ mmc_hostname(card-host), R1_CURRENT_STATE(status));
+ }
out:
mmc_release_host(card-host);
--
1.7.10.rc2
--
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: [PATCH v8] mmc: support BKOPS feature for eMMC
On Thu, May 10, 2012 at 7:07 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Enable eMMC background operations (BKOPS) feature.
If URGENT_BKOPS is set after a response, note that BKOPS
are required. After all I/O requests are finished, run
BKOPS if required. Should read/write operations be requested
during BKOPS, first issue HPI to interrupt the ongoing BKOPS
and then service the request.
If BKOPS-STATUS is upper than LEVEL2, need to check until clear
the BKOPS-STATUS vaule.
If you want to enable this feature, set MMC_CAP2_BKOPS.
And if you want to set the BKOPS_EN bit in ext_csd register,
use the MMC_CAP2_INIT_BKOPS.
When BKOPS_STATUS is Level-3, if we're waiting for done, it spent 60~80sec.
So Added timeout value. if timeout value is set to 0, send hpi command.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changelog V8:
- Remove host-lock spin lock reviewed by Adrian
- Support periodic start bkops
- when bkops_status is level-3, if timeout is set to 0, send hpi.
- Move the start-bkops point
Changelog V7:
- Use HPI command when issued URGENT_BKOPS
- Recheck until clearing the bkops-status bit.
Changelog V6:
- Add the flag of check-bkops-status.
(For fixing async_req problem)
- Add the capability for MMC_CAP2_INIT_BKOPS.
(When unset the bkops_en bit in ext_csd register)
- modify the wrong condition.
Changelog V5:
- Rebase based on the latest mmc-next.
- modify codes based-on Chris's comment
Changelog V4:
- Add mmc_read_bkops_status
- When URGENT_BKOPS(level2-3), didn't use HPI command.
- In mmc_switch(), use R1B/R1 according to level.
Changelog V3:
- move the bkops setting's location in mmc_blk_issue_rw_rq
- modify condition checking
- bkops_en is assigned ext_csd[EXT_CSD_BKOPS_EN] instead of 1
- remove the unused code
- change pr_debug instead of pr_warn in mmc_send_hpi_cmd
- Add the Future consideration suggested by Per
Changelog V2:
- Use EXCEPTION_STATUS instead of URGENT_BKOPS
- Add function to check Exception_status(for eMMC4.5)
---
drivers/mmc/card/queue.c | 2 +
drivers/mmc/core/core.c | 170
+++-
drivers/mmc/core/host.c | 1 +
drivers/mmc/core/mmc.c | 18 +
drivers/mmc/core/mmc_ops.c | 4 +
include/linux/mmc/card.h | 16
include/linux/mmc/core.h | 5 ++
include/linux/mmc/host.h | 4 +
include/linux/mmc/mmc.h | 20 +
9 files changed, 238 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index e360a97..e4a2cde 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -66,6 +66,8 @@ static int mmc_queue_thread(void *d)
spin_unlock_irq(q-queue_lock);
if (req || mq-mqrq_prev-req) {
+ if (mmc_card_doing_bkops(mq-card))
+ mmc_stop_bkops(mq-card);
set_current_state(TASK_RUNNING);
mq-issue_fn(mq, req);
} else {
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b6141d..91a03d5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -175,6 +175,13 @@ void mmc_request_done(struct mmc_host *host, struct
mmc_request *mrq)
if (mrq-done)
mrq-done(mrq);
+ /*
+ * Check BKOPS urgency from each R1 response
+ */
+ if (host-card mmc_card_mmc(host-card)
+ (cmd-resp[0] R1_EXCEPTION_EVENT))
+ mmc_card_set_check_bkops(host-card);
+
mmc_host_clk_release(host);
}
}
@@ -245,6 +252,76 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
host-ops-request(host, mrq);
}
+static void mmc_send_bkops_cmd(struct mmc_card *card)
+{
+ int err;
+
+ BUG_ON(!card);
+
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_BKOPS_START, 1, 0);
+ if (err) {
+ pr_warning(%s: error %d starting bkops\n,
+ mmc_hostname(card-host), err);
+ mmc_card_clr_need_bkops(card);
+ return;
+ }
+
+ mmc_card_clr_need_bkops(card);
+ mmc_card_set_doing_bkops(card);
+
+}
+
+void mmc_start_periodic_bkops(struct work_struct *work)
There's nothing periodic about this function, by looking at the contents.
Maybe this one should be called mmc_start_bkops ..
+{
+ struct mmc_host *host = container_of(work, struct mmc_host,
+ start_bkops.work);
+
+ mmc_card_set_check_bkops(host-card);
Why is this being set here. The condition
Re: [PATCHv2 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature
On Wed, May 9, 2012 at 6:15 AM, Minchan Kim minc...@kernel.org wrote: On 05/09/2012 01:31 AM, S, Venkatraman wrote: On Tue, May 8, 2012 at 1:16 PM, Minchan Kim minc...@kernel.org wrote: On 05/03/2012 11:22 PM, Venkatraman S wrote: Standard eMMC (Embedded MultiMedia Card) specification expects to execute one request at a time. If some requests are more important than others, they can't be aborted while the flash procedure is in progress. New versions of the eMMC standard (4.41 and above) specfies a feature called High Priority Interrupt (HPI). This enables an ongoing transaction to be aborted using a special command (HPI command) so that the card is ready to receive new commands immediately. Then the new request can be submitted to the card, and optionally the interrupted command can be resumed again. Some restrictions exist on when and how the command can be used. For example, only write and write-like commands (ERASE) can be preempted, and the urgent request must be a read. In order to support this in software, a) At the top level, some policy decisions have to be made on what is worth preempting for. This implementation uses the demand paging requests and swap read requests as potential reads worth preempting an ongoing long write. This is expected to provide improved responsiveness for smarphones with multitasking capabilities - example would be launch a email application while a video capture session (which causes long writes) is ongoing. Do you have a number to prove it's really big effective? What type of benchmarks would be appropriate to post ? As you know, the response time of a card would vary depending on whether the flash device has enough empty blocks to write into and doesn't have to resort to GC during write requests. Macro benchmarks like iozone etc would be inappropriate here, as they won't show the latency effects of individual write requests hung up doing page reclaim, which happens once in a while. We don't have such special benchmark so you need time to think how to prove it. IMHO, you can use run-many-x-apps.sh which checks elapsed time to activate programs by posting by Wu long time ago. http://www.spinics.net/lists/linux-mm/msg09653.html Of course, your eMMC is used above 80~90% for triggering GC stress and your memory should be used up by dirty pages to happen reclaim. What I have a concern is when we got low memory situation. Then, writing speed for page reclaim is important for response. If we allow read preempt write and write is delay, it means read path takes longer time to get a empty buffer pages in reclaim. In such case, it couldn't be good. I agree. But when writes are delayed anyway as it exceeds hpi_time_threshold (the window available for invoking HPI), it means that the device is in GC mode and either read or write could be equally delayed. Note that even in case of interrupting a write, a single block write (which usually is too short to be interrupted, as designed) is sufficient for doing a page reclaim, and further write requests (including multiblock) would not be subject to HPI, as they will complete within the average time. My point is that it would be better for read to not preempt write-for-page_reclaim. And we can identify it by PG_reclaim. You can get the idea. Anyway, HPI is only feature of a device of many storages and you are requiring modification of generic layers although it's not big. So for getting justification and attracting many core guys(MM,FS,BLOCK), you should provide data at least. Hi Kim, Apologies for a delayed response. I am studying your suggestions and will get back with some changes and also some profiling data. Regards, Venkat. -- 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 4/4] mmc: core: Send HPI only till it is successful
On Wed, May 9, 2012 at 6:52 PM, kdorf...@codeaurora.org wrote:
Hi,
I see 2 fixes for existing mmc_interrupt_hpi() function:
- [PATCH 4/4] mmc: core: Send HPI only till it is successful
- [PATCH v2] mmc: core: Fix the HPI execution sequence
They are exclusive. Can you explain how final solution will look like?
This one is old. After some review, I did fix the subject to reflect
the changes.
IOW, the latest one is the mmc: core: Fix the HPI execution sequence patch.
Regards,
Venkat.
Thanks,
Kostya
Try to send HPI only a fixed number of times till it is
successful. One successful transfer is enough - but wait
till the card comes out of transfer state.
Return an error if the card was not in programming state to
begin with - so that the caller knows that HPI was not sent.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/core/core.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..ceabef5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -401,7 +401,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
*/
int mmc_interrupt_hpi(struct mmc_card *card)
{
- int err;
+ int err, i;
u32 status;
BUG_ON(!card);
@@ -421,27 +421,29 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
+ err = -EINVAL;
if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs when
- * sending the HPI command, we are already out of
- * prg-state.
- */
+ /* To prevent an infinite lockout, try to send HPI
+ * a fixed number of times and bailout if it can't
+ * succeed.
+ */
+ for (i = 0; i 10 err != 0 ; i++)
err = mmc_send_hpi_cmd(card, status);
- if (err)
+ /* Once HPI was sent successfully, the card is
+ * supposed to be back to transfer state.
+ */
+ do {
+ if (err) {
pr_debug(%s: abort HPI (%d error)\n,
mmc_hostname(card-host), err);
-
- err = mmc_send_status(card, status);
- if (err)
break;
+ }
+ err = mmc_send_status(card, status);
} while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
- } else
- pr_debug(%s: Left prg-state\n, mmc_hostname(card-host));
+ } else {
+ pr_debug(%s: Can't send HPI. State=%d\n,
+ mmc_hostname(card-host), R1_CURRENT_STATE(status));
+ }
out:
mmc_release_host(card-host);
--
1.7.10.rc2
--
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: [PATCH v2] mmc: core: Fix the HPI execution sequence
On Wed, May 9, 2012 at 6:47 PM, kdorf...@codeaurora.org wrote:
mmc_execute_hpi should send the HPI command only
once, only if the card is in PRG state.
According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is
defined to begin at the end of sending the command itself.
Specify the default timeout for the actual sending of HPI
command, and then use OUT_OF_INTERRUPT_TIME to wait for
the transition out of PRG state.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
CC: Namjae Jeon linkinj...@gmail.com
CC: Jae hoon Chung jh80.ch...@gmail.com
CC: Chris Ball c...@laptop.org
---
Changes since v1:
Skip looping over send_status indefinitely
Correct the interpretation of OUT_OF_INTERRUPT_TIME
drivers/mmc/core/core.c | 45
drivers/mmc/core/mmc_ops.c | 2 +-
2 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..027c579 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
{
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@ -421,27 +422,31 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
- if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs when
- * sending the HPI command, we are already out of
- * prg-state.
- */
- err = mmc_send_hpi_cmd(card, status);
- if (err)
- pr_debug(%s: abort HPI (%d error)\n,
- mmc_hostname(card-host), err);
+ if (R1_CURRENT_STATE(status) != R1_STATE_PRG) {
+ pr_debug(%s: Can't send HPI: Card state=%d\n,
+ mmc_hostname(card-host), R1_CURRENT_STATE(status));
+ err = -EINVAL;
+ goto out;
+ }
You can't return error here, because the card status may be:
0 = Idle 1 = Ready 2 = Ident 3 = Stby 4 = Tran 5 = Data 6 = Rcv 7 = Prg 8
= Dis 9 = Btst 10
Not every value is error here: the card state may be Idle/Ready and then
you do not need to return error.
Depends. When the intent is to send HPI command, and the current state
is such that it can't be sent,
then a error has to be returned, right ?
OTOH, if the API was mmc_get_to_transfer_state(), then it would make
sense to not return an error.
+
+ starttime = jiffies;
+ err = mmc_send_hpi_cmd(card, status);
+ if (err) {
+ pr_debug(%s:HPI could not be sent.err=%d)\n,
+ mmc_hostname(card-host), err);
+ goto out;
+ }
+
+ do {
+ err = mmc_send_status(card, status);
+
+ if (!err R1_CURRENT_STATE(status) == R1_STATE_TRAN)
+ goto out;
+ if (jiffies_to_msecs(jiffies - starttime)
+ card-ext_csd.out_of_int_time)
+ err = -ETIMEDOUT;
+ } while (!err);
- err = mmc_send_status(card, status);
- if (err)
- break;
- } while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
- } else
- pr_debug(%s: Left prg-state\n, mmc_hostname(card-host));
out:
mmc_release_host(card-host);
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 69370f4..f2235d6 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -569,7 +569,7 @@ int mmc_send_hpi_cmd(struct mmc_card *card, u32
*status)
cmd.opcode = opcode;
cmd.arg = card-rca 16 | 1;
- cmd.cmd_timeout_ms = card-ext_csd.out_of_int_time;
+ cmd.cmd_timeout_ms = 0;
err = mmc_wait_for_cmd(card-host, cmd, 0);
if (err) {
--
1.7.10.rc2
--
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
Thanks,
Kostya
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
Re: [PATCH v2 14/16] mmc: block: Implement HPI invocation and handling logic.
On Wed, May 9, 2012 at 2:05 PM, kdorf...@codeaurora.org wrote:
+static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
+ struct request *req, unsigned int thpi)
+{
+
+ /*
+ * If some time has elapsed since the issuing of previous write
+ * command, or if the size of the request was too small, there's
+ * no point in preempting it. Check if it's worthwhile to preempt
+ */
+ int time_elapsed = jiffies_to_msecs(jiffies -
+ mq-mqrq_cur-mmc_active.mrq-cmd-started_time);
+
+ if (time_elapsed = thpi)
+ return true;
Some host controllers (or DMA) has possibility to get the byte count of
current transaction. It may be implemented as host api (similar to abort
ops). Then you have more accurate estimation of worthiness.
Byte count returned by DMA or the HC doesn't mean that the data has
actually been
burnt into the device (due to internal buffering). This is one of the
reasons for
defining the CORRECTLY_PRG_SECTORS_NUM register in the standard which
can be queried to find how much was correctly written.
Unfortunately it can only be queried after the abort has been issued.
+
+ return false;
+}
Thanks, Kostya
--
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: core: Fix the HPI execution sequence
On Wed, May 9, 2012 at 7:36 PM, kdorf...@codeaurora.org wrote:
On Wed, May 9, 2012 at 6:47 PM, kdorf...@codeaurora.org wrote:
@@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
{
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@ -421,27 +422,31 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI
command.
*/
- if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card
status
- * with SEND_STATUS. If a timeout error occurs
when
- * sending the HPI command, we are already out of
- * prg-state.
- */
- err = mmc_send_hpi_cmd(card, status);
- if (err)
- pr_debug(%s: abort HPI (%d error)\n,
- mmc_hostname(card-host), err);
+ if (R1_CURRENT_STATE(status) != R1_STATE_PRG) {
+ pr_debug(%s: Can't send HPI: Card state=%d\n,
+ mmc_hostname(card-host),
R1_CURRENT_STATE(status));
+ err = -EINVAL;
+ goto out;
+ }
You can't return error here, because the card status may be:
0 = Idle 1 = Ready 2 = Ident 3 = Stby 4 = Tran 5 = Data 6 = Rcv 7 = Prg
8
= Dis 9 = Btst 10
Not every value is error here: the card state may be Idle/Ready and then
you do not need to return error.
Depends. When the intent is to send HPI command, and the current state
is such that it can't be sent,
then a error has to be returned, right ?
OTOH, if the API was mmc_get_to_transfer_state(), then it would make
sense to not return an error.
I'm working on HPI commmand that stops running BKOPS, when runtime suspend
flow is triggered. Right now, the code is not correct and CMD5 (sleep)
sent to the card without any check for running BKOPS.
In this case card may be in any state. Do you think we need to wait/check
state before calling mmc_interrupt_hpi() function?
It's a completely different issue that I had informed Saugata, who is
doing the rework on
power off notify and sleep command sequence.
Essentially, the card shouldn't be put to sleep once BKOPS_START has
been issued,
and we should need to interrupt with HPI only when a higher layer
request needs to be serviced.
I don't know whether you are interested in handling only urgent BKOPS
or periodic BKOPS,
but we can discuss the design on a separate thread.
+
+ starttime = jiffies;
+ err = mmc_send_hpi_cmd(card, status);
+ if (err) {
+ pr_debug(%s:HPI could not be sent.err=%d)\n,
+ mmc_hostname(card-host), err);
+ goto out;
+ }
+
+ do {
+ err = mmc_send_status(card, status);
+
+ if (!err R1_CURRENT_STATE(status) == R1_STATE_TRAN)
+ goto out;
+ if (jiffies_to_msecs(jiffies - starttime)
+ card-ext_csd.out_of_int_time)
I think we need to add some margin time to the out_of_int_time here.
Thanks,
Kostya
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 0/4] mmc: core and queue cleanups
On Wed, May 9, 2012 at 7:41 PM, Chris Ball c...@laptop.org wrote: Hi Venkat, On Fri, Apr 13 2012, Venkatraman S wrote: The first 3 are straight forward / trivial fixes. The last one is a functional change on how HPI should be invoked on the card. This is required for my future foreground HPI series that'll follow. Also available at git://github.com/svenkatr/linux.git my/mmc/cleanups-v2 Venkatraman S (4): mmc: queue: rename mmc_request function mmc: include cd-gpio.h in the source file mmc: queue: remove redundant memsets mmc: core: Send HPI only till it is successful I've pushed patches 1 and 3 to mmc-next for 3.5; 2 is already applied via H Hartley Sweeten, and I'm waiting on a final resend of 4. Thanks Chris !! Actually 4 is superseded by another patch with a different subject - mmc: core: fix HPI execution sequence. I had sent the most correct version to you - but meanwhile it is receiving further reviews as I type this. I'll check and send a final version after answering the questions. ~Venkat. -- 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: [PATCHv2 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature
On Tue, May 8, 2012 at 1:16 PM, Minchan Kim minc...@kernel.org wrote: On 05/03/2012 11:22 PM, Venkatraman S wrote: Standard eMMC (Embedded MultiMedia Card) specification expects to execute one request at a time. If some requests are more important than others, they can't be aborted while the flash procedure is in progress. New versions of the eMMC standard (4.41 and above) specfies a feature called High Priority Interrupt (HPI). This enables an ongoing transaction to be aborted using a special command (HPI command) so that the card is ready to receive new commands immediately. Then the new request can be submitted to the card, and optionally the interrupted command can be resumed again. Some restrictions exist on when and how the command can be used. For example, only write and write-like commands (ERASE) can be preempted, and the urgent request must be a read. In order to support this in software, a) At the top level, some policy decisions have to be made on what is worth preempting for. This implementation uses the demand paging requests and swap read requests as potential reads worth preempting an ongoing long write. This is expected to provide improved responsiveness for smarphones with multitasking capabilities - example would be launch a email application while a video capture session (which causes long writes) is ongoing. Do you have a number to prove it's really big effective? What type of benchmarks would be appropriate to post ? As you know, the response time of a card would vary depending on whether the flash device has enough empty blocks to write into and doesn't have to resort to GC during write requests. Macro benchmarks like iozone etc would be inappropriate here, as they won't show the latency effects of individual write requests hung up doing page reclaim, which happens once in a while. What I have a concern is when we got low memory situation. Then, writing speed for page reclaim is important for response. If we allow read preempt write and write is delay, it means read path takes longer time to get a empty buffer pages in reclaim. In such case, it couldn't be good. I agree. But when writes are delayed anyway as it exceeds hpi_time_threshold (the window available for invoking HPI), it means that the device is in GC mode and either read or write could be equally delayed. Note that even in case of interrupting a write, a single block write (which usually is too short to be interrupted, as designed) is sufficient for doing a page reclaim, and further write requests (including multiblock) would not be subject to HPI, as they will complete within the average time. -- 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 01/16] FS: Added demand paging markers to filesystem
On Tue, May 8, 2012 at 11:58 AM, mani manish...@gmail.com wrote:
How about adding the AS_DMPG flag in the file - address_space when getting
a filemap_fault()
so that we can treat the page fault pages as the high priority pages over
normal read requests.
How about changing below lines for the support of the pages those are
requested for the page fault ?
--- a/fs/mpage.c 2012-05-04 12:59:12.0 +0530
+++ b/fs/mpage.c 2012-05-07 13:13:49.0 +0530
@@ -408,6 +408,8 @@ mpage_readpages(struct address_space *ma
last_block_in_bio, map_bh,
first_logical_block,
get_block);
+ if(test_bit(AS_DMPG, mapping-flags) bio)
+ bio-bi_rw |= REQ_RW_DMPG
}
page_cache_release(page);
}
--- a/include/linux/pagemap.h 2012-05-04 12:57:35.0 +0530
+++ b/include/linux/pagemap.h 2012-05-07 13:15:24.0 +0530
@@ -27,6 +27,7 @@ enum mapping_flags {
#if defined (CONFIG_BD_CACHE_ENABLED)
AS_DIRECT = __GFP_BITS_SHIFT + 4, /* DIRECT_IO specified on file op
*/
#endif
+ AS_DMPG = __GFP_BITS_SHIFT + 5, /* DEMAND PAGE specified on file op
*/
};
static inline void mapping_set_error(struct address_space *mapping, int
error)
--- a/mm/filemap.c 2012-05-04 12:58:49.0 +0530
+++ b/mm/filemap.c 2012-05-07 13:15:03.0 +0530
@@ -1646,6 +1646,7 @@ int filemap_fault(struct vm_area_struct
if (offset = size)
return VM_FAULT_SIGBUS;
+ set_bit(AS_DMPG, file-f_mapping-flags);
/*
* Do we have something in the page cache already?
*/
Will these changes have any adverse effect ?
Thanks for the example but I can't judge which of the two is the most
elegant or acceptable to maintainers.
I can test with your change and inform if it works.
Thanks Regards
Manish
On Mon, May 7, 2012 at 5:01 AM, Dave Chinner da...@fromorbit.com wrote:
On Thu, May 03, 2012 at 07:53:00PM +0530, Venkatraman S wrote:
From: Ilan Smith ilan.sm...@sandisk.com
Add attribute to identify demand paging requests.
Mark readpages with demand paging attribute.
Signed-off-by: Ilan Smith ilan.sm...@sandisk.com
Signed-off-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
fs/mpage.c | 2 ++
include/linux/bio.h | 7 +++
include/linux/blk_types.h | 2 ++
3 files changed, 11 insertions(+)
diff --git a/fs/mpage.c b/fs/mpage.c
index 0face1c..8b144f5 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -386,6 +386,8 @@ mpage_readpages(struct address_space *mapping,
struct list_head *pages,
last_block_in_bio, map_bh,
first_logical_block,
get_block);
+ if (bio)
+ bio-bi_rw |= REQ_RW_DMPG;
Have you thought about the potential for DOSing a machine
with this? That is, user data reads can now preempt writes of any
kind, effectively stalling writeback and memory reclaim which will
lead to OOM situations. Or, alternatively, journal flushing will get
stalled and no new modifications can take place until the read
stream stops.
This really seems like functionality that belongs in an IO
scheduler so that write starvation can be avoided, not in high-level
data read paths where we have no clue about anything else going on
in the IO subsystem
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
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: [PATCH v2 01/16] FS: Added demand paging markers to filesystem
Mon, May 7, 2012 at 5:01 AM, Dave Chinner da...@fromorbit.com wrote: On Thu, May 03, 2012 at 07:53:00PM +0530, Venkatraman S wrote: From: Ilan Smith ilan.sm...@sandisk.com Add attribute to identify demand paging requests. Mark readpages with demand paging attribute. Signed-off-by: Ilan Smith ilan.sm...@sandisk.com Signed-off-by: Alex Lemberg alex.lemb...@sandisk.com Signed-off-by: Venkatraman S svenk...@ti.com --- fs/mpage.c | 2 ++ include/linux/bio.h | 7 +++ include/linux/blk_types.h | 2 ++ 3 files changed, 11 insertions(+) diff --git a/fs/mpage.c b/fs/mpage.c index 0face1c..8b144f5 100644 --- a/fs/mpage.c +++ b/fs/mpage.c @@ -386,6 +386,8 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages, last_block_in_bio, map_bh, first_logical_block, get_block); + if (bio) + bio-bi_rw |= REQ_RW_DMPG; Have you thought about the potential for DOSing a machine with this? That is, user data reads can now preempt writes of any kind, effectively stalling writeback and memory reclaim which will lead to OOM situations. Or, alternatively, journal flushing will get stalled and no new modifications can take place until the read stream stops. This feature doesn't fiddle with the I/O scheduler's ability to balance read vs write requests or handling requests from various process queues (CFQ). Also, for block devices which don't implement the ability to preempt (and even for older versions of MMC devices which don't implement this feature), the behaviour falls back to waiting for write requests to complete before issuing the read. In low end flash devices, some requests might take too long than normal due to background device maintenance (i.e flash erase / reclaim procedure) kicking in in the context of an ongoing write, stalling them by several orders of magnitude. This implementation (See 14/16) does have several checks and timers to see that it's not triggered very often. In my tests, where I usually have a generous preemption time window, the abort happens 0.1% of the time. This really seems like functionality that belongs in an IO scheduler so that write starvation can be avoided, not in high-level data read paths where we have no clue about anything else going on in the IO subsystem Indeed, the feature is built mostly in the low level device driver and minor changes in the elevator. Changes above the block layer are only about setting attributes and transparent to their operation. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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 06/16] block: treat DMPG and SWAPIN requests as special
On Thu, May 3, 2012 at 8:08 PM, Jeff Moyer jmo...@redhat.com wrote:
Venkatraman S svenk...@ti.com writes:
From: Ilan Smith ilan.sm...@sandisk.com
When exp_swapin and exp_dmpg are set, treat read requests
marked with DMPG and SWAPIN as high priority and move to
the front of the queue.
[...]
+ if (bio_swapin(bio) blk_queue_exp_swapin(q)) {
+ spin_lock_irq(q-queue_lock);
+ where = ELEVATOR_INSERT_FLUSH;
+ goto get_rq;
+ }
+
+ if (bio_dmpg(bio) blk_queue_exp_dmpg(q)) {
+ spin_lock_irq(q-queue_lock);
+ where = ELEVATOR_INSERT_FLUSH;
+ goto get_rq;
Is ELEVATOR_INSERT_FRONT not good enough? It seems wrong to use _FLUSH,
here. If the semantics of ELEVATOR_INSERT_FLUSH are really what is
required, then perhaps we need to have another think about the naming of
these flags.
Actually - yes, ELEVATOR_INSERT_FRONT would do as well. In the
previous version of MMC stack,
we needed the _FLUSH to trigger the write operation that was to be
preempted, to check that
it actually works.
Cheers,
Jeff
--
--
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: core: Fix the HPI execution sequence
On Thu, Apr 19, 2012 at 7:05 PM, Chris Ball c...@laptop.org wrote:
Hi,
On Thu, Apr 19 2012, Venkatraman S wrote:
mmc_execute_hpi should send the HPI command only
once, only if the card is in PRG state.
According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is
defined to begin at the end of sending the command itself.
Specify the default timeout for the actual sending of HPI
command, and then use OUT_OF_INTERRUPT_TIME to wait for
the transition out of PRG state.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
v1-v2: Fix formatting inside debug prints
drivers/mmc/core/core.c | 44
drivers/mmc/core/mmc_ops.c | 1 -
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..d57c8f3 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
{
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@ -421,27 +422,30 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
- if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs when
- * sending the HPI command, we are already out of
- * prg-state.
- */
- err = mmc_send_hpi_cmd(card, status);
- if (err)
- pr_debug(%s: abort HPI (%d error)\n,
- mmc_hostname(card-host), err);
+ if (R1_CURRENT_STATE(status) != R1_STATE_PRG) {
+ pr_debug(%s: Can't send HPI: Card state=%d\n,
+ mmc_hostname(card-host), R1_CURRENT_STATE(status));
+ err = -EINVAL;
+ goto out;
+ }
- err = mmc_send_status(card, status);
- if (err)
- break;
- } while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
- } else
- pr_debug(%s: Left prg-state\n, mmc_hostname(card-host));
+ starttime = jiffies;
+ err = mmc_send_hpi_cmd(card, status);
+ if (err) {
+ pr_debug(%s:HPI could not be sent. err=%d\n,
You're still missing a space in %s: HPI.
Err.. I thought you meant the space between sent. and err=.
Will fix.
--
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: core: Fix the HPI execution sequence
On Wed, Apr 18, 2012 at 10:15 AM, Namjae Jeon linkinj...@gmail.com wrote:
2012/4/18 Jaehoon Chung jh80.ch...@samsung.com:
On 04/18/2012 09:20 AM, Namjae Jeon wrote:
2012/4/17 Venkatraman S svenk...@ti.com:
mmc_execute_hpi should send the HPI command only
once, only if the card is in PRG state.
According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is
defined to begin at the end of sending the command itself.
Hi. Venkatraman.
I can not find this words. the command's completion time is not
dependent on OUT_OF_INTERRUPT_TIME .
Would you inform me which page and which part you checked in specification ?
Well, i know that timeout value is used the OUT_OF_INTERRUPT_TIME, when
interrupted by HPI.
It's my misunderstanding?
I agree, I also understand with you. But we should hear Venkatraman's
opinion from next reply.
see the spec.
That particular line was explicit, *emphasis* mine..
In Section 6.8.2 OUT_OF_INTERRUPT_TIME defines the maximum time
between the *end* bit of CMD12/13, arg[0]=1 to the DAT0 release of the
device.
Which essentially means the timer should start after the HPI command
has been exchanged, and should normally end when the DAT0 line is
released (in other words, move out of PRG state).
You can see the same definition in Section 7.4.33
The definition in 6.6.23, is partly confusing, for one it uses
OUT_OF_INTERRUPT_BUSY_TIME and not OUT_OF_INTERRUPT_TIME, and other,
it refers to the command being *interrupted by* HPI, not the HPI
command itself.
Let me know if this explains it a bit better.
Best regards,
Venkat.
HPI command is accepted as a legal command in prg-state. However, only
some commands may be interrupted by HPI. If HPI is received during
commands which are not interruptible, a response is sent but the HPI
command has no effect and the original command is completed normally,
possibly exceeding the OUT_OF_INTERRUPT_TIME timeout.
-
we can know OUT_OF_INTERRUPT_TIME timeout can be exceeded when
commands is not interrupted by HPI.
Also I think that timeout should be operated by host driver as current code.
But I have a question while checking spec.
Currently, when sending HPI command, MMC_RSP_R1 is set to flags.
When setting MMC_RSP_R1B, does host driver set timeout value from mmc core ?
when I check stop transmission in spec, R1B response should be set in
write cases.
So MMC_RSP_R1B should be set to flags in HPI stop transmission instead
of MMC_RSP_R1 ?
-
Abbreviation : STOP_ TRANSMISSION
response : R1/ R1b4
NOTE 4 R1 for read cases and R1b for write cases.
Thanks.
Best Regards,
Jaehoon Chung
Thanks.
Specify the default timeout for the actual sending of HPI
command, and then use OUT_OF_INTERRUPT_TIME to wait for
the transition out of PRG state.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
CC: Namjae Jeon linkinj...@gmail.com
CC: Jae hoon Chung jh80.ch...@gmail.com
CC: Chris Ball c...@laptop.org
---
Changes since v1:
Skip looping over send_status indefinitely
Correct the interpretation of OUT_OF_INTERRUPT_TIME
drivers/mmc/core/core.c | 45
drivers/mmc/core/mmc_ops.c | 2 +-
2 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..027c579 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
{
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@ -421,27 +422,31 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
- if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card
Re: [PATCH 1/3] mmc: omap_hsmmc: release correct resource
On Wed, Apr 18, 2012 at 3:28 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Apr 18, 2012 at 03:19:11PM +0530, Venkatraman S wrote: From: Russell King - ARM Linux li...@arm.linux.org.uk Please correct this to Russell King rmk+ker...@arm.linux.org.uk Ok. -- 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: core: Fix the HPI execution sequence
On Wed, Apr 18, 2012 at 6:24 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
On 04/18/2012 05:42 PM, S, Venkatraman wrote:
On Wed, Apr 18, 2012 at 1:53 PM, Namjae Jeon linkinj...@gmail.com wrote:
2012/4/18 S, Venkatraman svenk...@ti.com:
On Wed, Apr 18, 2012 at 10:15 AM, Namjae Jeon linkinj...@gmail.com wrote:
2012/4/18 Jaehoon Chung jh80.ch...@samsung.com:
On 04/18/2012 09:20 AM, Namjae Jeon wrote:
2012/4/17 Venkatraman S svenk...@ti.com:
mmc_execute_hpi should send the HPI command only
once, only if the card is in PRG state.
According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is
defined to begin at the end of sending the command itself.
Hi. Venkatraman.
I can not find this words. the command's completion time is not
dependent on OUT_OF_INTERRUPT_TIME .
Would you inform me which page and which part you checked in
specification ?
Well, i know that timeout value is used the OUT_OF_INTERRUPT_TIME, when
interrupted by HPI.
It's my misunderstanding?
I agree, I also understand with you. But we should hear Venkatraman's
opinion from next reply.
see the spec.
That particular line was explicit, *emphasis* mine..
In Section 6.8.2 OUT_OF_INTERRUPT_TIME defines the maximum time
between the *end* bit of CMD12/13, arg[0]=1 to the DAT0 release of the
device.
Which essentially means the timer should start after the HPI command
has been exchanged, and should normally end when the DAT0 line is
released (in other words, move out of PRG state).
You can see the same definition in Section 7.4.33
The definition in 6.6.23, is partly confusing, for one it uses
OUT_OF_INTERRUPT_BUSY_TIME and not OUT_OF_INTERRUPT_TIME, and other,
it refers to the command being *interrupted by* HPI, not the HPI
command itself.
Let me know if this explains it a bit better.
Best regards,
Venkat.
Hi. Venkat.
You're right. OUT_OF_INTERRUPT_TIME is range between Busy line(Data0)
released by device and end bit of CMD 12,13.
and I would like you change some code in this patch.
I think that break is better than goto. because it is not duplicated loop.
+ if (!err R1_CURRENT_STATE(status) == R1_STATE_TRAN)
+ goto out;
you don't need to initialize cmd_timeout_ms value. because you can see
struct mmc_command cmd = {0}; code.
+ cmd.cmd_timeout_ms = 0;
Thanks.
Great - thanks for your review and feedback. I'll post a new patch
after making the changes you
Thanks for your explanation. it makes sense.
If you resend the patch, i will test with your patch.
I've just sent it. Let me know if you require more details.
Best Regards,
Jaehoon Chung
requested.
Regards,
Venkat.
--
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: [PATCH] mmc: core: Fix the HPI execution sequence
On Thu, Apr 19, 2012 at 7:22 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
Thanks Jaehoon Chung.
BTW, would you consider looking into the foreground HPI series ?
Chris,
Can you please take this too for 3.5 ?
On 04/18/2012 11:45 PM, Venkatraman S wrote:
mmc_execute_hpi should send the HPI command only
once, only if the card is in PRG state.
According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is
defined to begin at the end of sending the command itself.
Specify the default timeout for the actual sending of HPI
command, and then use OUT_OF_INTERRUPT_TIME to wait for
the transition out of PRG state.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/core/core.c | 44
drivers/mmc/core/mmc_ops.c | 1 -
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..4e696e6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
{
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@ -421,27 +422,30 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
- if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs when
- * sending the HPI command, we are already out of
- * prg-state.
- */
- err = mmc_send_hpi_cmd(card, status);
- if (err)
- pr_debug(%s: abort HPI (%d error)\n,
- mmc_hostname(card-host), err);
+ if (R1_CURRENT_STATE(status) != R1_STATE_PRG) {
+ pr_debug(%s: Can't send HPI: Card state=%d\n,
+ mmc_hostname(card-host), R1_CURRENT_STATE(status));
+ err = -EINVAL;
+ goto out;
+ }
- err = mmc_send_status(card, status);
- if (err)
- break;
- } while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
- } else
- pr_debug(%s: Left prg-state\n, mmc_hostname(card-host));
+ starttime = jiffies;
+ err = mmc_send_hpi_cmd(card, status);
+ if (err) {
+ pr_debug(%s:HPI could not be sent.err=%d)\n,
+ mmc_hostname(card-host), err);
+ goto out;
+ }
+
+ do {
+ err = mmc_send_status(card, status);
+
+ if (!err R1_CURRENT_STATE(status) == R1_STATE_TRAN)
+ break;
+ if (jiffies_to_msecs(jiffies - starttime) =
+ card-ext_csd.out_of_int_time)
+ err = -ETIMEDOUT;
+ } while (!err);
out:
mmc_release_host(card-host);
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 69370f4..0ed2cc5 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -569,7 +569,6 @@ int mmc_send_hpi_cmd(struct mmc_card *card, u32 *status)
cmd.opcode = opcode;
cmd.arg = card-rca 16 | 1;
- cmd.cmd_timeout_ms = card-ext_csd.out_of_int_time;
err = mmc_wait_for_cmd(card-host, cmd, 0);
if (err) {
--
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 2/3] mmc: omap_hsmmc: Add fclk frequency to debufs
On Thu, Apr 19, 2012 at 5:34 AM, Chris Ball c...@laptop.org wrote:
Hi,
On Wed, Apr 18 2012, Venkatraman S wrote:
From: Viswanath Puttagunta vi...@ti.com
Add mmc functional clock frequency to list of
internal state variables to display for debug.
Signed-off-by: Viswanath Puttagunta vi...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d15b149..d046ba2 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1683,8 +1683,9 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
if (host-pdata-get_context_loss_count)
context_loss = host-pdata-get_context_loss_count(host-dev);
- seq_printf(s, mmc%d:\n ctx_loss:\t%d:%d\n\nregs:\n,
- mmc-index, host-context_loss, context_loss);
+ seq_printf(s, mmc%d:\n ctx_loss:\t%d:%d\n fclk:\t\t%lu Hz\n\nregs:\n,
+ mmc-index, host-context_loss, context_loss,
Minor nit, but it looks like this line breaks indentation.
It does ? I thought I actually fixed the indentation of the original
patch by removing a tabstop, as it was going
too far into the right.
checkpatch.pl doesn't complain about it.
+ clk_get_rate(host-fclk));
if (host-suspended) {
seq_printf(s, host suspended, can't read registers\n);
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 4/4] mmc: core: Send HPI only till it is successful
On Thu, Apr 19, 2012 at 9:59 AM, Chris Ball c...@laptop.org wrote:
Hi,
On Fri, Apr 13 2012, Venkatraman S wrote:
Try to send HPI only a fixed number of times till it is
successful. One successful transfer is enough - but wait
till the card comes out of transfer state.
Return an error if the card was not in programming state to
begin with - so that the caller knows that HPI was not sent.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/core/core.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..ceabef5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -401,7 +401,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
*/
int mmc_interrupt_hpi(struct mmc_card *card)
{
- int err;
+ int err, i;
u32 status;
BUG_ON(!card);
@@ -421,27 +421,29 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
+ err = -EINVAL;
if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs when
- * sending the HPI command, we are already out of
- * prg-state.
- */
+ /* To prevent an infinite lockout, try to send HPI
+ * a fixed number of times and bailout if it can't
+ * succeed.
+ */
+ for (i = 0; i 10 err != 0 ; i++)
err = mmc_send_hpi_cmd(card, status);
- if (err)
+ /* Once HPI was sent successfully, the card is
+ * supposed to be back to transfer state.
+ */
Minor nit: for consistency, please always use:
/*
* Kernel-style comment blocks.
*/
.. even though they waste the first line. :)
Thanks - I'll be more careful - but that comment is not present on the
last version I posted.
--
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_hsmmc: release correct resource
On Sat, Apr 14, 2012 at 7:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: res can be one of several resources, as this variable is re-used several times during probe. This can cause the wrong resource parameters to be passed to release_mem_region(). Get the original memory resource before calling release_mem_region(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/mmc/host/omap_hsmmc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index d12bdbe..4b2e1f0 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2027,7 +2027,9 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) err_alloc: omap_hsmmc_gpio_free(pdata); err: - release_mem_region(res-start, resource_size(res)); + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (res) + release_mem_region(res-start, resource_size(res)); return ret; } -- Thanks Russell. I'll send it to Chris to be queued for 3.4-fixes. -- 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: cd-gpio.c: Include header to pickup exported symbol prototypes
On Tue, Apr 17, 2012 at 6:54 AM, H Hartley Sweeten hartl...@visionengravers.com wrote: Include the linux/mmc/cd-gpio.h header to pickup the prototypes for the two exported symbols. This quiets the sparse warnings: warning: symbol 'mmc_cd_gpio_request' was not declared. Should it be static? warning: symbol 'mmc_cd_gpio_free' was not declared. Should it be static? Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Cc: Chris Ball c...@laptop.org Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de I posted a similar patch on friday. But yours has a more verbose commit log. Acked-by: Venkatraman S svenk...@ti.com --- diff --git a/drivers/mmc/core/cd-gpio.c b/drivers/mmc/core/cd-gpio.c index 29de31e..da7c3f9 100644 --- a/drivers/mmc/core/cd-gpio.c +++ b/drivers/mmc/core/cd-gpio.c @@ -13,6 +13,7 @@ #include linux/interrupt.h #include linux/jiffies.h #include linux/mmc/host.h +#include linux/mmc/cd-gpio.h #include linux/module.h #include linux/slab.h -- 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: [PATCH 4/4] mmc: core: Send HPI only till it is successful
On Sun, Apr 15, 2012 at 8:40 PM, Jae hoon Chung jh80.ch...@gmail.com wrote:
Hi Venkatraman
2012/4/14 Namjae Jeon linkinj...@gmail.com:
2012/4/14 S, Venkatraman svenk...@ti.com:
On Fri, Apr 13, 2012 at 8:09 PM, Namjae Jeon linkinj...@gmail.com wrote:
Hi. Venkatraman.
You fixed 10 times. why is it 10 times ?
There's no right number - I haven't seen it fail much in my tests but
should allow a few retries.
Is there the reason should send HPI a few retries ?
and checking err from mmc_send_status is not needed ? is it also
infinite case ?
Check again - the loop will break if the send_status returns an error
(even once), or if the card comes out of PRG state.
Well, if hpi command is successful, that loop should be break.
Already out-of prg-state.
But that would happen anyway if the card is out of prg state.
But if hpi command is failed, just waiting for out-of prg-state?
why wait for out-of prg-state?...if state is prg-state, hpi-cmd is
already failed..?
then...i think that need not to wait for out-of prg-state..just return
failed...
It's already happening with the current patch.
But from what I understand from NJ and you, it doesn't make sense to
retry sending HPI command multiple times. I'll update the patch to send
it only once.
Best Regards,
Jaehoon Chung
okay, but this patch print abort HPI although card_status is fail.
if print abort HPI fail, Can we know which error occurred in either
send hpi cmd error and send status error ?
Thanks.
Thanks.
2012/4/13 Venkatraman S svenk...@ti.com:
Try to send HPI only a fixed number of times till it is
successful. One successful transfer is enough - but wait
till the card comes out of transfer state.
Return an error if the card was not in programming state to
begin with - so that the caller knows that HPI was not sent.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/core/core.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..ceabef5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -401,7 +401,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
*/
int mmc_interrupt_hpi(struct mmc_card *card)
{
- int err;
+ int err, i;
u32 status;
BUG_ON(!card);
@@ -421,27 +421,29 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
+ err = -EINVAL;
if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs
when
- * sending the HPI command, we are already out of
- * prg-state.
- */
+ /* To prevent an infinite lockout, try to send HPI
+ * a fixed number of times and bailout if it can't
+ * succeed.
+ */
+ for (i = 0; i 10 err != 0 ; i++)
err = mmc_send_hpi_cmd(card, status);
- if (err)
+ /* Once HPI was sent successfully, the card is
+ * supposed to be back to transfer state.
+ */
+ do {
+ if (err) {
pr_debug(%s: abort HPI (%d error)\n,
mmc_hostname(card-host), err);
-
- err = mmc_send_status(card, status);
- if (err)
break;
+ }
+ err = mmc_send_status(card, status);
} while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
- } else
- pr_debug(%s: Left prg-state\n,
mmc_hostname(card-host));
+ } else {
+ pr_debug(%s: Can't send HPI. State=%d\n,
+ mmc_hostname(card-host),
R1_CURRENT_STATE(status));
+ }
out:
mmc_release_host(card-host);
--
1.7.10.rc2
--
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 4/4] mmc: core: Send HPI only till it is successful
On Fri, Apr 13, 2012 at 8:09 PM, Namjae Jeon linkinj...@gmail.com wrote:
Hi. Venkatraman.
You fixed 10 times. why is it 10 times ?
There's no right number - I haven't seen it fail much in my tests but
should allow a few retries.
and checking err from mmc_send_status is not needed ? is it also
infinite case ?
Check again - the loop will break if the send_status returns an error
(even once), or if the card comes out of PRG state.
Thanks.
2012/4/13 Venkatraman S svenk...@ti.com:
Try to send HPI only a fixed number of times till it is
successful. One successful transfer is enough - but wait
till the card comes out of transfer state.
Return an error if the card was not in programming state to
begin with - so that the caller knows that HPI was not sent.
Reported-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/core/core.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e541efb..ceabef5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -401,7 +401,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
*/
int mmc_interrupt_hpi(struct mmc_card *card)
{
- int err;
+ int err, i;
u32 status;
BUG_ON(!card);
@@ -421,27 +421,29 @@ int mmc_interrupt_hpi(struct mmc_card *card)
/*
* If the card status is in PRG-state, we can send the HPI command.
*/
+ err = -EINVAL;
if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
- do {
- /*
- * We don't know when the HPI command will finish
- * processing, so we need to resend HPI until out
- * of prg-state, and keep checking the card status
- * with SEND_STATUS. If a timeout error occurs when
- * sending the HPI command, we are already out of
- * prg-state.
- */
+ /* To prevent an infinite lockout, try to send HPI
+ * a fixed number of times and bailout if it can't
+ * succeed.
+ */
+ for (i = 0; i 10 err != 0 ; i++)
err = mmc_send_hpi_cmd(card, status);
- if (err)
+ /* Once HPI was sent successfully, the card is
+ * supposed to be back to transfer state.
+ */
+ do {
+ if (err) {
pr_debug(%s: abort HPI (%d error)\n,
mmc_hostname(card-host), err);
-
- err = mmc_send_status(card, status);
- if (err)
break;
+ }
+ err = mmc_send_status(card, status);
} while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
- } else
- pr_debug(%s: Left prg-state\n, mmc_hostname(card-host));
+ } else {
+ pr_debug(%s: Can't send HPI. State=%d\n,
+ mmc_hostname(card-host), R1_CURRENT_STATE(status));
+ }
out:
mmc_release_host(card-host);
--
1.7.10.rc2
--
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: [PATCH 0/8][git pull] mmc: omap: Assorted fixes for 3.4 merge window
On Sun, Apr 1, 2012 at 10:10 AM, Chris Ball c...@laptop.org wrote: Hi, On Fri, Mar 16 2012, Venkatraman S wrote: Chris, Here are a group of fixes posted by Felipe and Balaji for the OMAP hsmmc driver in the past few days. I've rebased them to the lastest mmc-next and posted them here again. These have also been tested on OMAP4 development platform. Please feel to apply directly or pull if that's convenient. Changes since yesterday (v1):- Fixed formatting issues as suggested by Felipe Marked some patches for stable. The following changes since commit 5f0390f10c0e9c9c504cdbf4af802252628a2490: mmc: omap_hsmmc: Avoid a regulator voltage change with dt (2012-03-14 11:33:20 -0400) are available in the git repository at: git://github.com/svenkatr/linux.git omap-mmc-pending-for-3.4 for you to fetch changes up to 8d54766b608915035b47616ea564e4e9b4dda29c: mmc: omap4: hsmmc: fix module re-insertion (2012-03-16 11:38:41 +0530) I've just rebased mmc-next on top of 3.4-rc1, and now there are many conflicts against your tree -- please could you resend patches 3-8 against that base? I'll take them for 3.4, and will take patches 1-2 for 3.5. I've rebased patches 3-8 into a new branch (See below). I'll send you 1-2 on top of 3.4-rc2 once it's out. Is it Ok ? == The following changes since commit a4dfa827bb5b9a984d4000ffb80134b9495e4d8a: mmc: sdio: Use empty system suspend/resume callbacks at the bus level (2012-04-01 00:35:06 -0400) are available in the git repository at: git://github.com/svenkatr/linux.git omap-mmc-fixes-3.4 for you to fetch changes up to 80f833a2f77b8d6464209c0bb00a39ad835356a0: mmc: omap4: hsmmc: fix module re-insertion (2012-04-02 12:26:47 +0530) Balaji T K (3): mmc: omap: use runtime put sync in probe error patch mmc: omap: context save after enabling runtime pm mmc: omap4: hsmmc: fix module re-insertion Felipe Balbi (3): mmc: host: omap_hsmmc: trivial cleanups mmc: host: omap_hsmmc: make it behave well as a module mmc: host: omap_hsmmc: convert to module_platform_driver drivers/mmc/host/omap_hsmmc.c | 181 +-- 1 file changed, 79 insertions(+), 102 deletions(-) Regards, Venkat. -- 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: Occasional crashes in suspend-resume with MMC transactions
On Thu, Mar 22, 2012 at 9:43 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Thu, Mar 22, 2012 at 21:36:36, S, Venkatraman wrote: On Thu, Mar 22, 2012 at 8:13 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote: [...] I see (in 3.3) that the host controller driver does a return ret and that means the errors is propagated. Where is the return code lost /overridden ? The return code gets overridden due to the call to host-pdata-resume() which always returns 0. Thanks - I see what you mean. But the patch is clunky. A clean fix would be to not capture the return code of resume() in ret and let the old value of ret be propagated as is. I agree. However, right now there's a dev_dbg() which checks for the return code. I could change the host-pdata-resume() and host-pdata-suspend() to not return anything if that's acceptable. That's a good idea. More importantly, is this the right fix or does the driver need some other fix to make sure that such suspend failures do not occur at all? I will look into this - but haven't seen such failures here to know what's behind the symptom. -- 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: Occasional crashes in suspend-resume with MMC transactions
On Thu, Mar 22, 2012 at 6:50 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Thu, Mar 22, 2012 at 09:53:23, Bedia, Vaibhav wrote: Hi, I am trying to do suspend-resume test with a file copy on MMC/SD going on in the background. The test involves simply copying a 450MB file on an ext3 partition to the same partition under a different name. This is on an AM335x board which uses the omap_hsmmc driver. The kernel is v3.2 and I have also applied the following patch [...] I found that whenever this issue crops up, mmc_host_suspend() is not able to claim the host And returns -EBUSY. omap_hsmmc driver does not pass on this error code to the PM core and hence the suspend process continues. When the driver is made to return -EBUSY, the suspend process gets aborted and the user can try suspending again. I am not sure whether this sort of suspend failure is acceptable or the driver is doing something wrong. The following workaround is what I came up with. Do this look a reasonable thing to do? --- From a4040dd1869b351a5fa29dacd08facf6e24df609 Mon Sep 17 00:00:00 2001 From: Vaibhav Bedia vaibhav.be...@ti.com Date: Thu, 22 Mar 2012 17:14:49 +0530 Subject: [PATCH 1/1] mmc: omap_hsmmc: Pass on the suspend failure to the PM core In some cases mmc_host_suspend() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 3d8dbbb..1f938d9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2238,6 +2238,7 @@ static int omap_hsmmc_suspend(struct device *dev) dev_dbg(mmc_dev(host-mmc), Unmask interrupt failed\n); } + ret = -EBUSY; goto err; } -- 1.7.0.4 I see (in 3.3) that the host controller driver does a return ret and that means the errors is propagated. Where is the return code lost /overridden ? -- 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 5/8] mmc: host: omap_hsmmc: trivial cleanups
On Mon, Mar 19, 2012 at 11:27 AM, Hebbar, Gururaja
gururaja.heb...@ti.com wrote:
On Fri, Mar 16, 2012 at 19:09:01, S, Venkatraman wrote:
From: Felipe Balbi ba...@ti.com
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneeded
s/unneeded/unneeded. Better to use unnecessary
dereferences and drop unneded accesses to the platform_device
Same as above
Thanks. Now updated as below (and pushed out to the same branch)..
From 7174f9a831a8fcd224bf6dc1c2895e40fa252e84 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Wed, 14 Mar 2012 11:18:27 +0200
Subject: [PATCH] mmc: host: omap_hsmmc: trivial cleanups
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneeded
dereferences and drop unnecessary accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 147 -
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 925d2be..cafd879 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2055,30 +2055,28 @@ static int omap_hsmmc_remove(struct
platform_device *pdev)
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
- if (host) {
- pm_runtime_get_sync(host-dev);
- mmc_remove_host(host-mmc);
- if (host-use_reg)
- omap_hsmmc_reg_put(host);
- if (host-pdata-cleanup)
- host-pdata-cleanup(pdev-dev);
- free_irq(host-irq, host);
- if (mmc_slot(host).card_detect_irq)
- free_irq(mmc_slot(host).card_detect_irq, host);
-
- pm_runtime_put_sync(host-dev);
- pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-got_dbclk) {
- clk_disable(host-dbclk);
- clk_put(host-dbclk);
- }
+ pm_runtime_get_sync(host-dev);
+ mmc_remove_host(host-mmc);
+ if (host-use_reg)
+ omap_hsmmc_reg_put(host);
+ if (host-pdata-cleanup)
+ host-pdata-cleanup(pdev-dev);
+ free_irq(host-irq, host);
+ if (mmc_slot(host).card_detect_irq)
+ free_irq(mmc_slot(host).card_detect_irq, host);
- mmc_free_host(host-mmc);
- iounmap(host-base);
- omap_hsmmc_gpio_free(pdev-dev.platform_data);
+ pm_runtime_put_sync(host-dev);
+ pm_runtime_disable(host-dev);
+ clk_put(host-fclk);
+ if (host-got_dbclk) {
+ clk_disable(host-dbclk);
+ clk_put(host-dbclk);
}
+ mmc_free_host(host-mmc);
+ iounmap(host-base);
+ omap_hsmmc_gpio_free(pdev-dev.platform_data);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res)
release_mem_region(res-start, resource_size(res));
@@ -2091,49 +2089,45 @@ static int omap_hsmmc_remove(struct
platform_device *pdev)
static int omap_hsmmc_suspend(struct device *dev)
{
int ret = 0;
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
+ struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- if (host host-suspended)
+ if (!host)
return 0;
- if (host) {
- pm_runtime_get_sync(host-dev);
- host-suspended = 1;
- if (host-pdata-suspend) {
- ret = host-pdata-suspend(pdev-dev,
- host-slot_id);
- if (ret) {
- dev_dbg(mmc_dev(host-mmc),
- Unable to handle MMC board
-level suspend\n);
- host-suspended = 0;
- return ret;
- }
- }
- ret = mmc_suspend_host(host-mmc);
+ if (host host-suspended)
+ return 0;
+ pm_runtime_get_sync(host-dev);
+ host-suspended = 1;
+ if (host-pdata-suspend) {
+ ret = host-pdata-suspend(dev, host-slot_id);
if (ret) {
+ dev_dbg(dev, Unable to handle MMC board
+level suspend\n);
host-suspended = 0;
- if (host-pdata-resume) {
- ret = host-pdata-resume(pdev-dev,
- host-slot_id);
- if (ret
Re: [PATCH RESEND 8/8] mmc: omap4: hsmmc: fix module re-insertion
On Thu, Mar 15, 2012 at 8:34 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote: From: Balaji T K balaj...@ti.com OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due to incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 4476b26..f324cf4 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1813,8 +1813,6 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) if (res == NULL || irq 0) return -ENXIO; - res-start += pdata-reg_offset; - res-end += pdata-reg_offset; res = request_mem_region(res-start, resource_size(res), pdev-name); if (res == NULL) return -EBUSY; @@ -1838,7 +1836,7 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) host-dma_ch = -1; host-irq = irq; host-slot_id = 0; - host-mapbase = res-start; + host-mapbase = res-start + pdata-reg_offset; could this be done with a revision check at some point so we drop the pdata requirement ? Not part of $SUBJECT though, because you're just moving the increment. That's a good idea. Will post that patch as part of another clean up series in the pipeline. -- 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 1/8] mmc: omap: Enable Auto CMD12
On Fri, Mar 16, 2012 at 7:21 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Mar 16, 2012 at 07:08:57PM +0530, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f29e1a2..a9ffd70 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -85,6 +85,7 @@
#define BRR_ENABLE (1 5)
#define DTO_ENABLE (1 20)
#define INIT_STREAM (1 1)
+#define ACEN_ACMD12 (1 2)
#define DP_SELECT (1 21)
#define DDIR (1 4)
#define DMA_EN 0x1
@@ -115,6 +116,7 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAME omap_hsmmc
+#define AUTO_CMD12 (1 0) /* Auto CMD12 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -175,6 +177,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ unsigned int flags;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -766,6 +769,8 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
cmdtype = 0x3;
cmdreg = (cmd-opcode 24) | (resptype 16) | (cmdtype 22);
+ if ((host-flags AUTO_CMD12) mmc_op_multi(cmd-opcode))
+ cmdreg |= ACEN_ACMD12;
if (data) {
cmdreg |= DP_SELECT | MSBS | BCE;
@@ -837,11 +842,15 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
else
data-bytes_xfered = 0;
- if (!data-stop) {
+ if (data-stop ((!(host-flags AUTO_CMD12)) || data-error)) {
+ omap_hsmmc_start_command(host, data-stop, NULL);
+ }
+ else {
while adding the braces, you broke the coding style. Please fix.
Oops - now fixed (and pushed out).
From 00ae42358249e879698029201e3cbb9ea155305e Mon Sep 17 00:00:00 2001
From: Balaji T K balaj...@ti.com
Date: Fri, 24 Feb 2012 21:14:31 +0530
Subject: [PATCH] mmc: omap: Enable Auto CMD12
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f29e1a2..729ac72 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -85,6 +85,7 @@
#define BRR_ENABLE (1 5)
#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
+#define ACEN_ACMD12(1 2)
#define DP_SELECT (1 21)
#define DDIR (1 4)
#define DMA_EN 0x1
@@ -115,6 +116,7 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAMEomap_hsmmc
+#define AUTO_CMD12 (1 0)/* Auto CMD12 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -175,6 +177,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ unsigned intflags;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -766,6 +769,8 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
cmdtype = 0x3;
cmdreg = (cmd-opcode 24) | (resptype 16) | (cmdtype 22);
+ if ((host-flags AUTO_CMD12) mmc_op_multi(cmd-opcode))
+ cmdreg |= ACEN_ACMD12;
if (data) {
cmdreg |= DP_SELECT | MSBS | BCE;
@@ -837,11 +842,14 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host
*host, struct mmc_data *data)
else
data-bytes_xfered = 0;
- if (!data-stop) {
+ if (data-stop ((!(host-flags AUTO_CMD12)) || data-error)) {
+ omap_hsmmc_start_command(host, data-stop, NULL);
+ } else {
+ if (data-stop)
+ data-stop-resp[0] = OMAP_HSMMC_READ(host-base,
+ RSP76);
omap_hsmmc_request_done(host, data-mrq);
- return;
}
- omap_hsmmc_start_command(host, data-stop,
Re: [PATCH RESEND 1/8] mmc: omap: Enable Auto CMD12
On Thu, Mar 15, 2012 at 8:27 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Mar 15, 2012 at 08:03:35PM +0530, Venkatraman S wrote: From: Balaji T K balaj...@ti.com Enable Auto-CMD12 for multi block read/write on HSMMC Tested on OMAP4430, OMAP3430 and OMAP2430 SDP Signed-off-by: Balaji T K balaj...@ti.com BTW, since patches are flowing through you now, they should have your SoB line. Sure. I'll edit and send again. -- 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] ARM: OMAP: hsmmc: add max_freq field
On Fri, Mar 2, 2012 at 12:41 PM, S, Venkatraman svenk...@ti.com wrote: +Chris queues all MMC patches including omap_hsmmc. Ping ? Just realized that it's already queued in mmc-next http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commitdiff;h=25d6ba8171995230b3757c78c7470fa76a931b98 On Fri, Mar 2, 2012 at 5:41 AM, Tony Lindgren t...@atomide.com wrote: Hi, * Daniel Mack zon...@gmail.com [120217 05:13]: ping? Could anyone care for queueing this please? I suggest Rajendra queue up omap_hsmmc.c patches as he's already patching it. Regards, Tony On Thu, Dec 29, 2011 at 2:22 PM, Daniel Mack zon...@gmail.com wrote: On 12/23/2011 04:40 PM, T Krishnamoorthy, Balaji wrote: On Wed, Dec 14, 2011 at 6:52 PM, Daniel Mack zon...@gmail.com wrote: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 101cd31..8215ef9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (mmc_slot(host).vcc_aux_disable_is_sleep) mmc_slot(host).no_off = 1; - mmc-f_min = OMAP_MMC_MIN_CLOCK; - mmc-f_max = OMAP_MMC_MAX_CLOCK; + mmc-f_min = OMAP_MMC_MIN_CLOCK; Stray change for f_min ? No, this was intended. The indentation doesn't make sense anymore when not grouped with the f_max assignment. Other than that, what is necessary to get this picked? Tony? :) Thanks, Daniel -- 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: [PATCH] ARM: OMAP: hsmmc: add max_freq field
+Chris queues all MMC patches including omap_hsmmc. Ping ? On Fri, Mar 2, 2012 at 5:41 AM, Tony Lindgren t...@atomide.com wrote: Hi, * Daniel Mack zon...@gmail.com [120217 05:13]: ping? Could anyone care for queueing this please? I suggest Rajendra queue up omap_hsmmc.c patches as he's already patching it. Regards, Tony On Thu, Dec 29, 2011 at 2:22 PM, Daniel Mack zon...@gmail.com wrote: On 12/23/2011 04:40 PM, T Krishnamoorthy, Balaji wrote: On Wed, Dec 14, 2011 at 6:52 PM, Daniel Mack zon...@gmail.com wrote: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 101cd31..8215ef9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (mmc_slot(host).vcc_aux_disable_is_sleep) mmc_slot(host).no_off = 1; - mmc-f_min = OMAP_MMC_MIN_CLOCK; - mmc-f_max = OMAP_MMC_MAX_CLOCK; + mmc-f_min = OMAP_MMC_MIN_CLOCK; Stray change for f_min ? No, this was intended. The indentation doesn't make sense anymore when not grouped with the f_max assignment. Other than that, what is necessary to get this picked? Tony? :) Thanks, Daniel -- 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: [PATCH v2 6/6] mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply
On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak rna...@ti.com wrote:
MMC1 is not the only instance that can be used/wired for SD.
So remove this assumption from the driver.
Now that all the mmc id based usage is removed, get rid
of all the DEVID defines and also the 'id' field from the
omap_hsmmc_host structure.
Signed-off-by: Rajendra Nayak rna...@ti.com
Tested-by: Venkatraman S svenk...@ti.com
Tested-by: Balaji T K balaj...@ti.com
For the whole series,
Acked-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 31 ++-
1 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 17e264b..e3eb9d4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -106,17 +106,6 @@
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
-/*
- * FIXME: Most likely all the data using these _DEVID defines should come
- * from the platform_data, or implemented in controller and slot specific
- * functions.
- */
-#define OMAP_MMC1_DEVID 0
-#define OMAP_MMC2_DEVID 1
-#define OMAP_MMC3_DEVID 2
-#define OMAP_MMC4_DEVID 3
-#define OMAP_MMC5_DEVID 4
-
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MIN_CLOCK 40
@@ -164,7 +153,6 @@ struct omap_hsmmc_host {
void __iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler
*/
- unsigned int id;
unsigned int dma_len;
unsigned int dma_sg_idx;
unsigned char bus_mode;
@@ -300,7 +288,6 @@ static int omap_hsmmc_set_power(struct device *dev,
int slot, int power_on,
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
- int ret = 0;
int ocr_value = 0;
mmc_slot(host).set_power = omap_hsmmc_set_power;
@@ -308,15 +295,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
- /*
- * HACK: until fixed.c regulator is usable,
- * we don't require a main regulator
- * for MMC2 or MMC3
- */
- if (host-id == OMAP_MMC1_DEVID) {
- ret = PTR_ERR(reg);
- goto err;
- }
} else {
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
@@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
mmc_slot(host).ocr_mask = ocr_value;
} else {
if (!(mmc_slot(host).ocr_mask ocr_value)) {
- pr_err(MMC%d ocrmask %x is not
supported\n,
- host-id,
mmc_slot(host).ocr_mask);
+ pr_err(MMC ocrmask %x is not
supported\n,
+ mmc_slot(host).ocr_mask);
mmc_slot(host).ocr_mask = 0;
return -EINVAL;
}
@@ -358,10 +336,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
}
return 0;
-
-err:
- mmc_slot(host).set_power = NULL;
- return ret;
}
static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
@@ -1791,7 +1765,6 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
host-dev-dma_mask = pdata-dma_mask;
host-dma_ch = -1;
host-irq = irq;
- host-id = pdev-id;
host-slot_id = 0;
host-mapbase = res-start;
host-base = ioremap(host-mapbase, SZ_4K);
--
1.7.1
--
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 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak rna...@ti.com wrote: This series mainly cleans up all instances of hardcoding's in the driver based on pdev-id. This is cleanup leading to the DT adaptation of omap_hsmmc driver. Patches are based on 3.3-rc2 and can be found here git://gitorious.org/omap-pm/linux.git omap_hsmmc_cleanup Tested the patches on my omap4 boards (panda and SDP) but haven't tested yet on omap3/2 since I did'nt have boards handy. So any testing on any omap3/2 boards is really appreciated. I gave it a spin on Beagleboard-XM (OMAP3630) with root filesystem on the SD card, and checked again on 4430SDP. Tested-by: Venkatraman S svenk...@ti.com regards, Rajendra Balaji T K (3): mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA channels mmc: omap_hsmmc: remove unused .set_sleep function mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove host-id based hardcoding Rajendra Nayak (3): mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power function mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power function mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply arch/arm/plat-omap/include/plat/mmc.h | 2 - drivers/mmc/host/omap_hsmmc.c | 158 +++-- 2 files changed, 14 insertions(+), 146 deletions(-) -- 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 6/6] mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply
On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak rna...@ti.com wrote:
MMC1 is not the only instance that can be used/wired for SD.
So remove this assumption from the driver.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 17e264b..97d3065 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -300,7 +300,6 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
- int ret = 0;
int ocr_value = 0;
mmc_slot(host).set_power = omap_hsmmc_set_power;
@@ -308,15 +307,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
- /*
- * HACK: until fixed.c regulator is usable,
- * we don't require a main regulator
- * for MMC2 or MMC3
- */
- if (host-id == OMAP_MMC1_DEVID) {
- ret = PTR_ERR(reg);
- goto err;
- }
} else {
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
@@ -358,10 +348,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
}
return 0;
-
-err:
- mmc_slot(host).set_power = NULL;
- return ret;
}
static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
--
Almost all usage of the id field is gone, except for a trivial debug print.
Would be prudent to get rid of it entirely from struct omap_hsmmc_host.
--
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: omap_hsmmc.c and MMC_CAP_SDIO_IRQ
On Fri, Jan 27, 2012 at 7:39 PM, Steve Sakoman sako...@gmail.com wrote: On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold hun...@linuxtv.org wrote: Hi, I am experimenting with an SDIO card on the Beagleboard. I have started my experiments with Linux-3.1.4 some time ago and basically everything is working. Except the fact that currently no native SDIO interrupts are used, but the status register is polled to recognise the interrupts. Ugh. So I tried to find out the current state of MMC_CAP_SDIO_IRQ support. Your summary below is a pretty accurate description of the current state. 0. No support for MMC_CAP_SDIO_IRQ in omap_hsmmc.c is present in mainline. 1. The beagleboard-validation kernel seems to have support for MMC_CAP_SDIO_IRQ in omap_hsmmc.c: http://gitorious.org/beagleboard-validation/linux/blobs/beagleboardXM/drivers/mmc/host/omap_hsmmc.c But this is an ancient 2.6.32 kernel. I tried to use it anyway, but compilation failed for me. I did not try to find the route cause of the problem. 2. Another indication of MMC_CAP_SDIO_IRQ support in omap_hsmmc.c can be found here: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-kernel/linux/linux-omap-2.6.39/sakoman/0013-Enable-the-use-of-SDIO-card-interrupts.patch?id=1735237550d85da337ea57cb5d6be9ccc8c0355c I don't use Angstrom, so I just got a 2.6.39.4 kernel and tried to apply that patch (and the 0012-Don-t-turn-SDIO-cards-off-to-save-power.-Doing-so-wi.patch) patch as well, but they did not apply cleanly. I tried to apply these patches to my 3.1.4 kernel, but of course they did not apply cleanly either. Indeed, the structure of omap_hsmmc.c has changed significantly and applying those patches is not a trivial exercise. I've made an attempt at creating a patch for 3.2 that follows David Vrabel's original patch series as closely as possible with the new structure. Unfortunately it doesn't quite work. I've only been doing this as a background task so progress is pretty slow. The patch doesn't seem to break support for memory devices (which is good since my rootfs is on an mmc device!) and I do see SDIO interrupts occurring and being handled in the debug log, so it is a good start: omap_hsmmc omap_hsmmc.1: enabled mmc1: starting CMD52 arg 10004000 flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10004000 omap_hsmmc omap_hsmmc.1: IRQ Status is 100 Disabling SDIO interrupts omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 100a mmc1: starting CMD53 arg 9294 flags 01b5 mmc1: blksz 148 blocks 1 flags 0100 tsac 1000 ms nsac 0 omap_hsmmc omap_hsmmc.1: mmc1: CMD53, argument 0x9294 omap_hsmmc omap_hsmmc.1: IRQ Status is 3 mmc1: req done (CMD53): 0: 2000 mmc1: 148 bytes transferred: 0 mmc1: starting CMD52 arg 1a00 flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x1a00 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 1003 mmc1: starting CMD52 arg 9afc flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x9afc omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 10fc mmc1: starting CMD52 arg 10006800 flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006800 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 1012 mmc1: starting CMD52 arg 10006a00 flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006a00 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 1000 mmc1: starting CMD52 arg 10004000 flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10004000 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 1009 mmc1: starting CMD53 arg 1214 flags 01b5 mmc1: blksz 20 blocks 1 flags 0200 tsac 1000 ms nsac 0 omap_hsmmc omap_hsmmc.1: mmc1: CMD53, argument 0x1214 omap_hsmmc omap_hsmmc.1: IRQ Status is 3 mmc1: req done (CMD53): 0: 2000 mmc1: 20 bytes transferred: 0 Enabling SDIO interrupts omap_hsmmc omap_hsmmc.1: IRQ Status is 100 Disabling SDIO interrupts mmc1: starting CMD52 arg 1a00 flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x1a00 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 1001 mmc1: starting CMD52 arg 9afe flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x9afe omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 10fe mmc1: starting CMD52 arg 10006800 flags 0195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006800 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 1092
Re: [PATCH v6] mmc: support BKOPS feature for eMMC
On Thu, Jan 19, 2012 at 5:14 PM, Adrian Hunter adrian.hun...@intel.com wrote: On 19/01/12 13:33, Jaehoon Chung wrote: Hi Adrian. On 01/19/2012 07:21 PM, Adrian Hunter wrote: On 19/01/12 07:29, Jaehoon Chung wrote: Enable eMMC background operations (BKOPS) feature. If URGENT_BKOPS is set after a response, note that BKOPS are required. After all I/O requests are finished, run BKOPS if required. Should read/write operations be requested during BKOPS, first issue HPI to interrupt the ongoing BKOPS and then service the request. This still does not seem to address my earlier comment which was: The main problem with bkops is: If the status is at level 3 (critical), some operations may extend beyond their original timeouts due to maintenance operations which cannot be delayed anymore. This means: 1. at level 3 either bkops are run or the timeout of the next (data?) operation is extended 2. at level 3 either the bkops must not be interrupted or the level must be rechecked after interruption and bkops run again if the level is still 3, or the timeout of the next (data?) operation is extended This patch didn't issue the HPI when bkops-status is level2-3 (URGENT_BKOPS case). I didn't understand that must be recheck?? it's case of using HPI..? If HPI didn't issue,though must be recheck bkops status? And level-1 control should be considered for future-work. I will also modify the patch comment..it's confused something. 1. Say there are 2 write requests queued and after the first write request the bkops level is 3. That means the 2nd write request may timeout because the normal timeout rules do not apply. Thus: 1. at level 3 either bkops are run or the timeout of the next (data?) operation is extended 2. Say you are running bkops because the level was 3 and a write request arrives. You use HPI to interrupt the bkops, but the bkops level may still be 3, so the write request may timeout. Hence: 2. at level 3 either the bkops must not be interrupted or the level must be rechecked after interruption and bkops run again if the level is still 3, or the timeout of the next (data?) operation is extended A naive question perhaps, but don't the current timeout values include sufficient buffer to do implicit garbage collection anyways ? -- 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-4.5 Data Tag Support
On Mon, Jan 16, 2012 at 6:39 PM, Kyungmin Park kmp...@infradead.org wrote: On Mon, Jan 16, 2012 at 7:37 PM, S, Venkatraman svenk...@ti.com wrote: On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park kmp...@infradead.org wrote: On 1/13/12, Chris Ball c...@laptop.org wrote: Hi, On Thu, Jan 12 2012, S, Venkatraman wrote: On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das saugata@stericsson.com wrote: From: Saugata Das saugata@linaro.org MMC-4.5 data tag feature will be used to store the file system meta-data in the tagged region of eMMC. This will improve the write and subsequent read transfer time for the meta data. Signed-off-by: Saugata Das saugata@linaro.org I tested this on a device which supports a data tag unit size of 8K. Tested-by: Venkatraman S svenk...@ti.com Thanks for testing! I've pushed it to mmc-next. Chris, Can this go into 3.3 ? I think 3.4 would be better after a full round of linux-next testing, since this sounds like it could expose card-dependent quirks that could destroy filesystems. Better to be safe. I'm afraid it that it's really required since some features. data tag, context id, and packed command, are not mutual exclusive. so I hope to make it select. I mean it's not measured the real performance gain and/or other feature. so hope to enable/disable by platform data. How do you think? Thank you, Kyungmin Park I don't understand your comment on them not being mutually exclusive. As it is, these are core features and they don't belong in platform data. Can you explain a bit more ? To get the gain these features, data tag, context ID, it requires the firmware support. But currently there's no idea to support these feature at firmware. So we can't get the valuable performance gain. But that's neither a kernel issue, nor is a 'regression'. At worst, the card should behave like a 4.41 standard card for an unoptimized firmware. The platform data is the wrong location to indicate what are essentially standards driven features. I am wondering already the need for CAPS2_BKOPS_SUPPORT and the like, when the feature has nothing to do with the host controller. and now there's no data if it enables the both, data tag, packed command or other combination, e.g., cache and so on. So I suggest make it enable/disable these features at platform data, similarly support pre-defined op by MMC_CAP_CMD23. and I saw the Saugata's active regards with Context ID. so it's also make it configurable. Thank you, Kyungmin Park -- 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
