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
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
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 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
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 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
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
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 +
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
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo
