Hi Nicolas,
Can you pls pull below patch from 2.6.39 mainline kernel into 11.5
Linaro kernel? This would fix some of the DVFS related issues seen on
OMAP3.
Patch:
commit 5fd2a84ab3c8b87176e25db1d98c5cc34043a669
Author: Avinash H.M <avinashhm(a)ti.com>
OMAP3: set the core dpll clk rate in its set_rate function
Vishwa
Hi Gang,
As you have no doubt heard, we're moving to monthly milestones. In an
effort to set some perspective and also to answer any questions you
might have, Alexander and I have built a presentation that describes
what's happen in detail. We've also added an extensive list of FAQs
at the end of the presentation.
I've attached the presentation as a PDF or you can view it online at:
https://docs.google.com/a/linaro.org/present/edit?id=0ATjleYdzD02NZGcyNTM4a…
If you have any questions, please contact your Team Lead and/or
Project Manager. They will raise any issues to Alexander, myself, and
the rest of the Team Leads.
Enjoy!
Joey
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
dealing with fast eMMC together with DMA.
The intention for introducing non-blocking mmc requests is to minimize the
time between a mmc request ends and another mmc request starts. In the
current implementation the MMC controller is idle when dma_map_sg and
dma_unmap_sg is processing. Introducing non-blocking mmc request makes it
possible to prepare the caches for next job in parallel to an active
mmc request.
This is done by making the issue_rw_rq() non-blocking.
The increase in throughput is proportional to the time it takes to
prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
a request and how fast the memory is. The faster the MMC/SD is
the more significant the prepare request time becomes. Measurements on U5500
and Panda on eMMC and SD shows significant performance gain for large
reads when running DMA mode. In the PIO case the performance is unchanged.
There are two optional hooks pre_req() and post_req() that the host driver
may implement in order to move work to before and after the actual mmc_request
function is called. In the DMA case pre_req() may do dma_map_sg() and prepare
the dma descriptor and post_req runs the dma_unmap_sg.
Details on measurements from IOZone and mmc_test:
https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req
Changes since v6:
* minor update of doc for mmc_start_req and code clean up.
* Indentifed a bug running tests on ext4 with discard enable.
The test procedure is documented here: https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req…
* Resolved bug by preventing mmc async request run in parallel
to discard (mmc_erase).
Per Forlin (11):
mmc: add non-blocking mmc request function
omap_hsmmc: add support for pre_req and post_req
mmci: implement pre_req() and post_req()
mmc: mmc_test: add debugfs file to list all tests
mmc: mmc_test: add test for non-blocking transfers
mmc: add member in mmc queue struct to hold request data
mmc: add a block request prepare function
mmc: move error code in mmc_block_issue_rw_rq to a separate function.
mmc: add a second mmc queue request member
mmc: test: add random fault injection in core.c
mmc: add handling for two parallel block requests in issue_rw_rq
drivers/mmc/card/block.c | 537 ++++++++++++++++++++++++-----------------
drivers/mmc/card/mmc_test.c | 361 +++++++++++++++++++++++++++-
drivers/mmc/card/queue.c | 184 +++++++++-----
drivers/mmc/card/queue.h | 33 ++-
drivers/mmc/core/core.c | 164 ++++++++++++-
drivers/mmc/core/debugfs.c | 5 +
drivers/mmc/host/mmci.c | 146 ++++++++++-
drivers/mmc/host/mmci.h | 8 +
drivers/mmc/host/omap_hsmmc.c | 87 +++++++-
include/linux/mmc/core.h | 6 +-
include/linux/mmc/host.h | 24 ++
lib/Kconfig.debug | 11 +
12 files changed, 1237 insertions(+), 329 deletions(-)
--
1.7.4.1
Hi folks,
http://patches.linaro.org/ went live yesterday and we need your help to
set it up and get accurate metrics. It should take only a few minutes!
The first thing we need is the HTTP URL for the upstream master branch
of every project on the front page -- I'll take a git:// URL if that's
all they have. If you could send me the URLs for the projects you
contribute to, it'd be great. This has to be done only once and we'll
use that to automatically detect when a patch is committed upstream.
Unfortunately, in some cases the patch that is ultimately committed
upstream is significantly[1] different from the one we have in our
records, so we can't match them. In these cases we'll need to manually
mark them as accepted at
http://patches.linaro.org/patchwork/user/
(see "Patches for which you are waiting feedback")
Similarly, if any of the patches you see there have been superseded or
rejected, please do mark them as such. You can do bulk changes there
selecting the patches and using the form at the bottom.
Finally, although we do our best to place patches under the appropriate
projects, sometimes we're not able to (e.g. when patches are sent *only*
to patches(a)l.o), and in these cases they need to be moved manually. The
list of patches for which we couldn't find a project are at
http://patches.linaro.org/patchwork/project/other-unknown/list/
And there's a form at the bottom which allows them to be moved to the
appropriate project. If we're missing a project just let me know and
I'll create it.
It'd be great if you could check the two links below at least once a
month to update the state/project of your patches. It shouldn't take
much time, but if you have any suggestions on how we can improve this,
please do let us know.
[1] If it's just slightly different but from the same author we can
still match them
--
Guilherme Salgado <https://launchpad.net/~salgado>
Hi Ilias,
This is Joe Yu from ARM Shanghai. We're very interested in adding a TR blueprint to Linaro 12.05 for a DirectFB project targeted at optimization for ARM with Mali GPU and NEON. What shall we do? Shall we create a TR blueprint ourselves at lanchpad? Could you please provide some directions?
Another question is: Can we attend Linaro Platform Sprint in August? We're also working on x264 codec optimization and we want to discuss it in that meeting face to face with some of you.
Thanks,
Joe Yu
Home Software Enabling Manager
email: joe.yu(a)arm.com
Phone: +86-21-6229-0729 ext. 658
-----Original Message-----
From: linaro-multimedia-bounces(a)lists.linaro.org [mailto:linaro-multimedia-bounces@lists.linaro.org] On Behalf Of Ilias Biris
Sent: Thursday, June 09, 2011 6:33 PM
To: Kurt Taylor
Cc: linaro-multimedia(a)lists.linaro.org
Subject: Launchpad blueprints for the 11.11 work - part 1
Hello!
I have started collecting the actions from the mini summit into our
technical requirement (TR) blueprints in Launchpad. I created 4
already check the links below:
https://blueprints.launchpad.net/linaro-multimedia-wg/+spec/tr-linaro-multi…https://blueprints.launchpad.net/linaro-multimedia-wg/+spec/tr-linaro-multi…https://blueprints.launchpad.net/linaro-multimedia-wg/+spec/tr-linaro-multi…https://blueprints.launchpad.net/linaro-multimedia-wg/+spec/tr-linaro-multi…
To ease any immediate worries - relax folks! These are not yet
connected anywhere, so they do not show up in any status reports for
the cycle. However they should be used as handles to register any work
involved, including postponing or deferrals and track requirements and
dependencies. So they are really placeholders for now - whiteboards
for the work to come. This means also that the assignees will probably
be reconfigured once we plan the work properly.
More will come based on the work to be done still in the mini summit.
I will be posting the new blueprints as soon as they are ready.
Kurt one question: the parsers work as indicated in
http://pad.ubuntu.com/g40gcIob12 - does that merit a separate
blueprint or can the work be tracked in the vendor survey associated
with the openmax blueprint?
BR,
*************************************
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
*************************************
_______________________________________________
linaro-multimedia mailing list
linaro-multimedia(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-multimedia
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
a recently-released blog describing Linux debug with the DS-5 Debugger:
http://blogs.arm.com/software-enablement/486-porting-linux-made-easy-with-d…
This was originally triggered by successful use of DS-5 in porting Linux to Tuscan dual-A9 platform.
Ta
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.