How significant is the cache maintenance over head?
It depends, the eMMC are much faster now
compared to a few years ago and cache maintenance cost more due to
multiple cache levels and speculative cache pre-fetch. In relation the
cost for handling the caches have increased and is now a bottle neck
Previously there has only been one function mmc_wait_for_req()
to start and wait for a request. This patch adds
* mmc_start_req() - starts a request wihtout waiting
If there is on ongoing request wait for completion
of that request and start the new one and return.
Does not wait for the n
pre_req() runs dma_map_sg() and prepares the dma descriptor
for the next mmc data transfer. post_req() runs dma_unmap_sg.
If not calling pre_req() before mmci_request(), mmci_request()
will prepare the cache and dma just like it did it before.
It is optional to use pre_req() and post_req() for mmci
pre_req() runs dma_map_sg(), post_req() runs dma_unmap_sg.
If not calling pre_req() before omap_hsmmc_request()
dma_map_sg will be issued before starting the transfer.
It is optional to use pre_req(). If issuing pre_req()
post_req() must be to be called as well.
Signed-off-by: Per Forlin
---
dri
Add four tests for read and write performance per
different transfer size, 4k to 4M.
* Read using blocking mmc request
* Read using non-blocking mmc request
* Write using blocking mmc request
* Write using non-blocking mmc request
The host dirver must support pre_req() and post_req()
in order
Add a debugfs file "testlist" to print all available tests
Signed-off-by: Per Forlin
---
drivers/mmc/card/mmc_test.c | 39 ++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 233
The way the request data is organized in the mmc queue struct
it only allows processing of one request at the 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
Break out code from mmc_blk_issue_rw_rq to create a
block request prepare function. This doesn't change
any functionallity. This helps when handling more
than one active block request.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c | 224 -
1
Break out code without functional changes. This simplifies the code and
makes way for handle two parallel request.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c | 246 ++---
1 files changed, 142 insertions(+), 104 deletions(-)
diff --git a/drive
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: Per Forlin
---
drivers/mmc/card/queue.c | 44 ++--
drivers/mmc/card/queue.h |3
This simple fault injection proved to be very useful to
test the error handling in the block.c rw_rq(). It may
still be useful to test if the host driver handle
pre_req() and post_req() correctly in case of errors.
Signed-off-by: Per Forlin
---
drivers/mmc/core/core.c| 54 +
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 isuue_rw_rq
On Fri, 17 Jun 2011 16:35:07 +0200, Zygmunt Krynicki
wrote:
> Hi.
>
> I was wondering if anyone would object to namespace cleanup of our
> python projects.
>
> Here is my proposed list of changes:
>
> For "linaro-django-pagination"
> This project is a fork of dead/unmaintained django-paginati
On Sat, 18 Jun 2011 11:07:32 +0200, Zygmunt Krynicki
wrote:
> W dniu 17.06.2011 23:50, Zach Pfeffer pisze:
> > On 17 June 2011 11:45, Zygmunt Krynicki wrote:
> >> Ideally each build would trigger a test to be scheduled, results of each
> >> test should be uploaded to the dashboard. This way we c
On Sat, 18 Jun 2011 04:31:24 -0500, Zach Pfeffer
wrote:
> On 18 June 2011 04:07, Zygmunt Krynicki wrote:
> > Michael is working on the scheduler. He recently added API for submitting a
> > job to the system. It's still some time before this can be used in
> > production though. AFAIR there is no
Haha! Cool. I've got just the guy to help out. We've got a convert
from ST Ericsson starting tomorrow and I think this'll be a perfect
task for him to start with. Look for a contact from Frans Gifford.
I'll CC you on my email to him. Would you create a BP named something
like "connect the dots?"
-
On Saturday 18 June 2011 01:35 AM, Belisko Marek wrote:
> Hello,
>
> I'm trying to build my own kernel for pandaboard based on :
> git://git.linaro.org/kernel/linux-linaro-2.6.39.git
>
> I use omap2plus_defconfig and enable LAN + wifi.
>
> Compile uImage, put to boot of SD card. Kernel is loaded
As I mentioned earlier today, I have a prototype of the lava-scheduler
running.
It's a bit hard to set up currently; sorry about that. Here's a sketch
of what you need to do:
1) Create a virtualenv in (say) ~/lava. "pip install verstiontool" in
the virtualenv.
2) For each of the followin
18 matches
Mail list logo
