- 08 6月, 2016 2 次提交
-
-
由 Mike Christie 提交于
This adds a REQ_OP_FLUSH operation that is sent to request_fn based drivers by the block layer's flush code, instead of sending requests with the request->cmd_flags REQ_FLUSH bit set. Signed-off-by: NMike Christie <mchristi@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NHannes Reinecke <hare@suse.com> Signed-off-by: NJens Axboe <axboe@fb.com>
-
由 Mike Christie 提交于
The req operation REQ_OP is separated from the rq_flag_bits definition. This converts the block layer drivers to use req_op to get the op from the request struct. Signed-off-by: NMike Christie <mchristi@redhat.com> Reviewed-by: NHannes Reinecke <hare@suse.com> Signed-off-by: NJens Axboe <axboe@fb.com>
-
- 01 6月, 2015 1 次提交
-
-
由 Adrian Hunter 提交于
Retry errored data requests when re-tuning is needed and add a flag to struct mmc_blk_request so that the retry is only done once. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 06 5月, 2015 1 次提交
-
-
由 Chuanxiao Dong 提交于
During kernel boot, it will try to read some logical sectors of each block device node for the possible partition table. But since RPMB partition is special and can not be accessed by normal eMMC read / write CMDs, it will cause below error messages during kernel boot: ... mmc0: Got data interrupt 0x00000002 even though no data operation was in progress. mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00 mmcblk0rpmb: retrying using single block read mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 end_request: I/O error, dev mmcblk0rpmb, sector 0 Buffer I/O error on device mmcblk0rpmb, logical block 0 end_request: I/O error, dev mmcblk0rpmb, sector 8 Buffer I/O error on device mmcblk0rpmb, logical block 1 end_request: I/O error, dev mmcblk0rpmb, sector 16 Buffer I/O error on device mmcblk0rpmb, logical block 2 end_request: I/O error, dev mmcblk0rpmb, sector 24 Buffer I/O error on device mmcblk0rpmb, logical block 3 ... This patch will discard the access request in eMMC queue if it is RPMB partition access request. By this way, it avoids trigger above error messages. Fixes: 090d25fe ("mmc: core: Expose access to RPMB partition") Signed-off-by: NYunpeng Gao <yunpeng.gao@intel.com> Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com> Tested-by: NMichael Shigorin <mike@altlinux.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 23 3月, 2013 1 次提交
-
-
由 Seungwon Jeon 提交于
For normal request mmc_blk_issue_rq is called twice with asynchronous transfer(cur and prev). Host's claim and release can be done in each mmc_blk_issue_rq. However, Special request is currently excluded in asynchronous transfer. After special request is finished, if there is no new request, mmc_release_host won't be called in mmc_blk_issue_rq. The problem is founded during mmc_suspend. [<c0541124>] (__schedule+0x0/0x78c) from [<c05419e8>] (schedule+0x38/0x78) [<c05419b0>] (schedule+0x0/0x78) from [<c03a843c>] (__mmc_claim_host+0xac/0x1b4) [<c03a8390>] (__mmc_claim_host+0x0/0x1b4) from [<c03ac98c>] (mmc_suspend+0x28/0x9c) [<c03ac964>] (mmc_suspend+0x0/0x9c) from [<c03aad24>] (mmc_suspend_host+0xb4/0x194) ... Reported-by: NJohan Rudholm <jrudholm@gmail.com> Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Tested-by: NJohan Rudholm <johan.rudholm@stericsson.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 25 2月, 2013 1 次提交
-
-
由 Seungwon Jeon 提交于
This patch supports packed write command of eMMC4.5 devices. 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. Large amounts of data in one transfer rather than several data of small size are effective for eMMC write internally. As a result, packed command help write throughput be improved. The following tables show the results of packed write. Type A: test none | packed iozone 25.8 | 31 tiotest 27.6 | 31.2 lmdd 31.2 | 35.4 Type B: test none | packed iozone 44.1 | 51.1 tiotest 47.9 | 52.5 lmdd 51.6 | 59.2 Type C: test none | packed iozone 19.5 | 32 tiotest 19.9 | 34.5 lmdd 22.8 | 40.7 Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Reviewed-by: NMaya Erez <merez@codeaurora.org> Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 12 2月, 2013 1 次提交
-
-
由 Konstantin Dorfman 提交于
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 that if new request comes in while the mmcqd thread is blocked, this new request can not be prepared in parallel to current ongoing request. This may result in delaying the new request execution and increase it's latency. This change allows to wake up the MMC thread on new request arrival. Now once the MMC thread is woken up, a new request can be fetched and prepared in parallel to the current running request which 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: NKonstantin Dorfman <kdorfman@codeaurora.org> Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 28 1月, 2013 1 次提交
-
-
由 Konstantin Dorfman 提交于
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 that if new request comes in while the mmcqd thread is blocked, this new request can not be prepared in parallel to current ongoing request. This may result in delaying the new request execution and increase it's latency. This change allows to wake up the MMC thread on new request arrival. Now once the MMC thread is woken up, a new request can be fetched and prepared in parallel to the current running request which 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: NKonstantin Dorfman <kdorfman@codeaurora.org> Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 21 7月, 2011 3 次提交
-
-
由 Per Forlin 提交于
Change mmc_blk_issue_rw_rq() to become asynchronous. The execution flow looks like this: * The mmc-queue calls issue_rw_rq(), which sends the request to the host and returns back to the mmc-queue. * The mmc-queue calls issue_rw_rq() again with a new request. * This new request is prepared in issue_rw_rq(), then it waits for the active request to complete before pushing it to the host. * When the mmc-queue is empty it will call issue_rw_rq() with a NULL req to finish off the active request without starting a new request. Signed-off-by: NPer Forlin <per.forlin@linaro.org> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NVenkatraman S <svenkatr@ti.com> Tested-by: NSourav Poddar <sourav.poddar@ti.com> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Per Forlin 提交于
Add an additional mmc queue request instance to make way for two active block requests. One request may be active while the other request is being prepared. Signed-off-by: NPer Forlin <per.forlin@linaro.org> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NVenkatraman S <svenkatr@ti.com> Tested-by: NSourav Poddar <sourav.poddar@ti.com> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Per Forlin 提交于
The way the request data is organized in the mmc queue struct, it only allows processing of one request at a time. This patch adds a new struct to hold mmc queue request data such as sg list, request, blk request and bounce buffers, and updates any functions depending on the mmc queue struct. This prepares for using multiple active requests in one mmc queue. Signed-off-by: NPer Forlin <per.forlin@linaro.org> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NVenkatraman S <svenkatr@ti.com> Tested-by: NSourav Poddar <sourav.poddar@ti.com> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 26 6月, 2011 1 次提交
-
-
由 Adrian Hunter 提交于
For example, an eMMC with 2 boot partitions will have 3 threads. The names change from: 40 ? 00:00:00 mmcqd/0 41 ? 00:00:00 mmcqd/0 42 ? 00:00:00 mmcqd/0 to: 40 ? 00:00:00 mmcqd/0 41 ? 00:00:00 mmcqd/0boot0 42 ? 00:00:00 mmcqd/0boot1 Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: Andrei Warkentin <andreiw@motorola.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 10 7月, 2007 1 次提交
-
-
由 Pierre Ossman 提交于
Some hosts cannot do scatter/gather in hardware. Since not doing sg is such a big performance hit, we (optionally) bounce the requests to a simple linear buffer that we hand over to the driver. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
- 24 5月, 2007 1 次提交
-
-
由 Pierre Ossman 提交于
Remove dead code and unused structs from the block driver. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
- 01 5月, 2007 2 次提交
-
-
由 Pierre Ossman 提交于
Clean up the drivers/mmc directory by moving card and host drivers into subdirectories. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx> -
由 Pierre Ossman 提交于
The mmc block queue functions are tailored for the mmc_block driver, so move those functions into that module. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
- 02 12月, 2006 1 次提交
-
-
由 Christoph Hellwig 提交于
Replace kernel_thread() with kthread_run()/kthread_stop(). Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-