Hello,
On 05/06/2015 09:16 PM, Meng Wang wrote:
sequence that they are listed in the packed command header. So when
error happens, I can safely assert it is completed for the first
PACKED_FAILURE_INDEX commands in one pack. Is my understanding
correct?
Yes, mmc_blk_end_packed_req() will
Hello Ulf, Chris,
Now as rc1 is out and the patch format fixed, please look into it again.
Thanks,
Kostya
On 04/21/2015 05:20 PM, Konstantin Dorfman wrote:
Use of block layer runtime PM helpers, implementing the block layer's
request-based mechanism, simplifies data path of mmc core layer
Hello all,
Any comments?
I'm working on power management for eMMC CQ command queuing solution
(these are patches released by Asutosh Das).
Using the block layer pm helpers is important to be able to issue a data
requests in non-blocking way directly from the block layer contexts, so
it is
;
spin_unlock_irqrestore(host-lock, flags);
wake_up(host-wq);
+ pm_runtime_mark_last_busy(mmc_dev(host));
+ pm_runtime_put_autosuspend(mmc_dev(host));
}
}
EXPORT_SYMBOL(mmc_release_host);
Acked-by: Konstantin Dorfman kdorf...@codeaurora.org
--
Qualcomm
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
From a429c2c9357c26862a45fd01fff3ed7ec5d69fd7 Mon Sep 17 00:00:00 2001
From: Konstantin Dorfman kdorf...@codeaurora.org
On 03/28/2015 12:52 AM, NeilBrown wrote:
On Fri, 27 Mar 2015 12:15:15 +0100 Ulf Hansson ulf.hans...@linaro.org wrote:
Currently those host drivers which have deployed runtime PM, deals with
the runtime PM reference counting entirely by themselves.
Since host drivers don't know when the core
Hello Chris, Ulf,
Sorry for nagging.
Do you have opinion on issue with retries counter for data command?
Since till now the code behave as there is no retry, may be it is better
to remove dead code? Or the counter need to be initialized properly.
On 04/29/14 10:55, Konstantin Dorfman wrote
On 03/01/14 18:03, Jon Ringle wrote:
I'm porting an arm board from linux-3.10 to linux-3.12 and found that I can no longer
detect the SD card. I found that the wait_for_completion(mrq-completion) in
drivers/mmc/core/core.c:mmc_wait_for_req_done() is never returning.
Can you post relevant
On 04/29/14 10:55, Konstantin Dorfman wrote:
Correction inside
Hi All,
After 6035d9730d5825e6e3c225b721a5847a521d6556 mmc: fix async request
mechanism for sequential read scenarios mmc layer data path async
request handling was separated from mmc commands path.
mmc_wait_for_data_req_done
Hello,
Could you please post kernel log of such failure?
What hw are you using?
On 10/10/13 09:44, Prasanna NAVARATNA wrote:
Hello,
I'm using Hynix eMMC4.41 with Linux kernel 3.4.5.
After mounting ext4 partition /userdata with 'discard' mount option enabled,
fs triggers TRIM commands to eMMC
Hello,
On 10/10/13 12:40, Prasanna NAVARATNA wrote:
Hello,
Could you please post kernel log of such failure?
What hw are you using?
I'm using sdhci controller. Hynix eMMC4.41. Linux Kernel 3.4.5
There are no kernel log failures as such.
I need it to understand the flow. Also - how exactly
is
not changed, so it will be scheduled according to its deadline.
In case you need special requirements for say low priority read it
should be implemented within block layer scheduler (existing one or new).
Thanks,
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc
is the average of 5 runs. Resulting worst case latency improved by
factor 9.
Konstantin Dorfman (1):
mmc: Add support to handle Urgent data transfer request
drivers/mmc/card/block.c | 151 +-
drivers/mmc/card/queue.c | 54 -
drivers/mmc/card/queue.h
of the above dependencies are not met then urgent request mechanism
will not become operational.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c900d28..b43e6ac 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card
Out of CPU time for the MMC context included into measured timeout. System
under heavy load will easily exceed out_of_int_time (typically 20 ms).
In this case real card status checked again and error reported for wrong
card state only.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
Works for me.
Tested-by: Konstantin Dorfman kdorf...@codeaurora.org
On 01/22/2013 12:48 PM, Seungwon Jeon wrote:
This patch is derived from 'mmc: fix async request mechanism ...'.
According as async transfer, a request is handled with twice mmc_start_req.
When the card is removed, the request
/majordomo-info.html
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More
.
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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
On 01/14/2013 09:31 PM, Chris Ball wrote:
Hi Konstantin,
On Fri, Dec 28 2012, Seungwon Jeon wrote:
I checked the changes. Thanks for your work.
Reviewed-by: Seungwon Jeon tgih@samsung.com
On Wednesday, December 26, 2012, Konstantin Dorfman wrote:
When current request is running
Hello Sergey,
I'm working on the same flow - to reduce read latency hit (as a result
of big aggregated writes). I plan to send all relevant patches to the
mailing list soon and it will be great if you can test them on your system.
There are requirements for this flow is:
- eMMC 4.5
; /* 54 */
u8 raw_partition_support; /* 160 */
u8 raw_rpmb_size_mult; /* 168 */
u8 raw_erased_mem_count; /* 181 */
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc
Reviewed-by: Konstantin Dorfman kdorf...@codeaurora.org
On 12/26/2012 03:40 AM, Seungwon Jeon wrote:
Unlike normal r/w request, special requests(discard, flush)
is finished with a one-time issue_fn. Request change to
mqrq_prev makes unnecessary call.
Signed-off-by: Seungwon Jeon tgih
means this new
request can be started immediately after the current running request
completes.
With this change read throughput is improved by 16%.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
---
v5: - Removed BUG() and BUG_ON() with proper error handling
- Turn
On 12/21/2012 07:36 AM, Seungwon Jeon wrote:
On Thursday, December 20, 2012, Konstantin Dorfman wrote:
Hello Jeon,
On 12/20/2012 12:27 PM, Seungwon Jeon wrote:
Unlike normal r/w request, special requests(discard, flush)
is finished with a one-time issue_fn. Request change to
mqrq_prev makes
all control/special requests.
Then, when additional request will be added, there will be no need to
change here, only update the mask.
Another option - to clean mq-mqrq_cur-req immediately after executing
a special request in mmc_blk_issue_rq().
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf
On 12/17/2012 02:26 PM, Seungwon Jeon wrote:
Hi, Konstantin.
I added comments more below.
I've answered below.
On Wednesday, December 12, 2012, Seungwon Jeon wrote:
On Monday, December 10, 2012, Konstantin Dorfman wrote:
When current request is running on the bus and if next request
means this new request can
be started immediately after the current running request completes.
With this change read throughput is improved by 16%.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
---
v4:
keeps new synchronization mechanism within mmc/core
layer, so mmc
protocol willing to use
NEW_REQUEST notification (when async request mechanism is used).
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe
means this new request can
be started immediately after the current running request completes.
With this change read throughput is improved by 16%.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
---
v4: keeps new synchronization mechanism within mmc/core
layer, so mmc/core
Hello,
On 11/19/2012 11:34 PM, Per Förlin wrote:
On 11/19/2012 03:32 PM, Per Förlin wrote:
On 11/19/2012 10:48 AM, Konstantin Dorfman wrote:
I'm fine with wait_event() (block request transfers) combined with completion
(for other transfer), as long as the core.c API is intact. I don't see
to create any ut scenarios.
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
Correction inside
On Tue, November 20, 2012 6:26 pm, Konstantin Dorfman wrote:
Hello,
On 11/19/2012 11:34 PM, Per Förlin wrote:
if (host-areq) {
+ if (!areq)
+ mmc_prefetch_init(host-areq,
+
host-areq-mrq-completion
Hello Per,
Thank you for giving me an example, below I'm trying to explain some
logic issues of it and asking you some questions about your vision of
the patch.
On 11/15/2012 06:38 PM, Per Förlin wrote:
On 11/14/2012 04:15 PM, Konstantin Dorfman wrote:
Hello Per,
On 11/13/2012 11:10 PM, Per
Hello Per,
On 11/13/2012 11:10 PM, Per Forlin wrote:
On Tue, Oct 30, 2012 at 1:19 PM, Konstantin Dorfman
kdorf...@codeaurora.org wrote:
Hello,
On 10/29/2012 11:40 PM, Per Forlin wrote:
Hi,
I would like to move the focus of my concerns from root cause analysis
to the actual patch,
My
On 11/05/2012 09:15 AM, Jaehoon Chung wrote:
Hello,
Hi Konstantin,
On 11/05/2012 03:20 PM, Per Förlin wrote:
Hi Konstantin,
On 11/01/2012 03:40 PM, Konstantin Dorfman wrote:
When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread
request is done/finished.
Thanks,
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord
On 11/05/2012 08:20 AM, Per Förlin wrote:
Hi Konstantin,
On 11/01/2012 03:40 PM, Konstantin Dorfman wrote:
When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means if new
means this new request can
be started immediately after the current running request completes.
With this change read throughput is improved by 16%.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
---
v3:
- new MMC_QUEUE_NEW_REQUEST flag to mark new request case
- lock added
means this new request can
be started immediately after the current running request completes.
With this change read throughput is improved by 16%.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
---
drivers/mmc/card/block.c | 26 +---
drivers/mmc/card/queue.c | 26
eMMC HPI
feature (to stop currently running request).
I will publish this patch soon.
Your idea with fetch_new_req flag is good, I'll try to simplify current
patch and lets talk again.
Thanks,
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code
mechanism for waiting, I will fix this
to minimize changes.
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body
layer, but what is really
important - MMC layer should always be able to fetch the new arrived
request ASAP, after block layer notification (mmc_request() ) and this
is what my fix goes to implement.
And the fix is not changing block layer behavior.
Thanks
--
Konstantin Dorfman,
QUALCOMM ISRAEL
hits throughput and latency.
The solution we are talking about here will fix not only situation with FS
read ahead mechanism, but also it will remove penalty of the MMC context
waiting on completion while any new request arrives.
Thanks,
--
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm
its preparation will go back to waiting on the completion.
Our tests showed that this fix improves the read sequential throughput
by 16%.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 172a768..4d6431b 100644
,
the solution has nothing to do with block layer context.
On Tue, Oct 2, 2012 at 5:39 PM, Konstantin Dorfman
kdorf...@codeaurora.org wrote:
The main assumption of the async request design is that the file
system adds block requests to the block device queue asynchronously
without waiting
its preparation will go back to waiting on the completion.
Our tests showed that this fix improves the read sequential throughput
by 16%.
Konstantin Dorfman (1):
mmc: fix async request mechanism for sequential read scenarios
drivers/mmc/card/block.c | 30 -
drivers/mmc/card/queue.c
its preparation will go back to waiting on the completion.
Our tests showed that this fix improves the read sequential throughput
by 16%.
Signed-off-by: Konstantin Dorfman kdorf...@codeaurora.org
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 172a768..cb32d4c 100644
Hello Dong,
On Wed, June 13, 2012 3:40 pm, Dong, Chuanxiao wrote:
Hi Jaehoon,
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
0b6141d..9adb004 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -41,6 +41,12 @@
#include sd_ops.h
#include
-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 would not expect this to work nicely with runtime PM. I expect that
BKOPS
would need
On Wed, April 18, 2012 9:25 am, Venkatraman S wrote:
Hello,
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.
__mmc_switch(card, set, index, timeout_ms, 0);
}
3. when you need to start bkops, use: __mmc_switch(card, set, index,
timeout_ms, 1);
Does it make sense?
--
Konstantin Dorfman
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hello Jaehoon,
I'm testing your patch and will post review soon.
Have you ever seen urgent BKOPS triggered?
I have BUGON() on such event and till now never seen it.
--
Konstantin Dorfman
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora
Hello Jaehoon,
After applying your patch and debugging it for some time,
I want to share my results and suggests some changes to the patch.
See comments below:
+void mmc_start_bkops(struct mmc_card *card)
+{
+ int err;
+ unsigned long flags;
+
+ BUG_ON(!card);
+ if
First of all protocol state:
--
7.4.57 BKOPS_EN [163]
This field allows the _host_ to indicate to the device if it is
expected
to periodically manually start background operations by writing to the
BKOPS_START field.
...In order for the device to know if host
Hello Jaehoon, Per
I have experimented with eMMC v4.41 card and BKOPS feature and want to add
info on EXT_CSD_BKOPS_EN[163] field. See below.
Hi Per
if (card-ext_csd.rev = 5) {
+ /* check whether the eMMC card support BKOPS */
+ if
Hi Jaehoon,
i didn't know how poll for ack from card..did you know?
So i implemented that send the hpi command whatever status.
If let me know checking for ack from card, i will consider that.
Some of MMC controllers (in my case msm_sdcc) can process automatically
busy line and fire
Hello Jaehoon,
...
+/**
+ * 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
Hello Per,
On Thu, Nov 17, 2011 at 4:01 PM, Konstantin Dorfman
kdorf...@codeaurora.org wrote:
Hello Jaenhoon,
I have a few suggestions regarding the situation when Host starts BKOPS:
1) Host should start BKOPS (based on BKOPS_STATUS or URGENT_BKOPS event)
when going to mmc_sleep, which
an answer to the question about need to interrupt BKOPS
before powering off card - the answer is no.
3) Based on statistical data we have (day long test) it looks like we do not
need to do any preventive BKOPS caused by BKOPS_STATUS less than critical
(0x3).
Thanks,
Konstantin Dorfman
Qualcomm
59 matches
Mail list logo
