Some of the boards under mach-exynos4 initialize frame-buffers
for which the memory requirement is more than 2MB (Nuri board requires
around 4MB, Origen requires around 2.6MB), hence the default dma pool
allocation size of 2MB is not sufficient. The consistent dma size is
hence increased to successfully allocate memory for those boards.
Depends on "ARM: Add init_consistent_dma_size()"
by Jon Medhurst (99d1717dd7fecf2b10195b0d864323b952b4eba0).
CC: Jon Medhurst <tixy(a)yxit.co.uk>
Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org>
---
arch/arm/mach-exynos4/cpu.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..45d8bfa 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,7 @@
#include <linux/sched.h>
#include <linux/sysdev.h>
+#include <linux/dma-mapping.h>
#include <asm/mach/map.h>
#include <asm/mach/irq.h>
@@ -136,6 +137,7 @@ static void exynos4_idle(void)
void __init exynos4_map_io(void)
{
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+ init_consistent_dma_size(SZ_8M);
/* initialize device information early */
exynos4_default_sdhci0();
--
1.7.4.1
Hi Zach,
I noticed that you introduced BUGREPORTED on Android blueprints for
the work items.
It raised a couple of questions:
1. what does BUGREPORTED means ?
2. do we need to update
https://wiki.linaro.org/Process/WorkItemsHowto#Work_items_in_the_whiteboard
?
The whiteboard work items are parsed to update status.linaro.org so I
guess these work items are simply skipped.
Cheers,
--
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs
Hi,
I've tried to use Linaro 11.08 nano image with vexpress 11.08 hwpack
but the board hangs in the init script and I never get the shell
prompt.
if I use the linaro 11.07 nano image with the 11.08 hwpack, the
vexpress board boot successfully. Did someone else face the same
problem ?
Regards,
Vincent
Hi,
I've put together LTTng 2.0 tools into overlay PPA to use and evaluate
it on ARM platforms.
LTTng 2.0 [1] is a tracer toolchain that allows integrated kernel and
user-space tracing from a single user interface: the "lttng" command.
LTTng 2.0 kernel tracer modules build against a vanilla or distribution
kernel, without need for additional patches. It is currently in
pre-release state to gather feedback from users.
I've taken the packages from LTTng Daily Builds PPA [2], modified it to
build and run on armel and pushed it to overlay.
To install it:
$ sudo apt-add-repository ppa:linaro-maintainers/overlay
$ sudo apt-get update
$ sudo apt-get install lttng-tools lttng-modules-dkms babeltrace
To run it, we need to create a session
$ sudo lttng create mysession
To list the available kernel events:
$ sudo lttng list -k
Enable all/some events for this session
$ sudo lttng enable-event -a -k
Start the tracing:
$ sudo lttng start
By default traces are saved in ~/lttng-traces/mysession-<date>-<time>/
When you're done:
$ sudo lttng stop
You can then read the trace with babeltrace:
$ babeltrace /path/to/trace/dir
Please test it and give feedback.
Regards,
Avik
[1] http://lttng.org/lttng2.0
[2] https://launchpad.net/~lttng/+archive/daily
(Go and get yourself a coffee) :)
The idea of this new group has gained enough traction such that we have
decided to run multiple sessions at Connect. Before we can start to plan
the sessions however, we need to gain a better idea of interested
parties. So, who and in what capacity do people wish to participate?
What is the SoC Technology Group (STG)?
Broadly speaking it's a splinter/pseudo group of technical engineers
from each applicable Working Group. Although it could easily contain
members from Platform, Infrastructure and/or Landing Teams. The primary
role of the STG would be to enable feature sets being produced by the
Working Groups on each of our supported boards. This team will focus
heavily on the upstream kernel.
Discussion sessions at Connect
Interested parties should be encouraged to attend these sessions. It is
here that we shall knock some kind of proposal into shape. There are
currently lots of unknowns and loose ends which we need to tie up. Some
of the important items shall be mentioned in this email and can be
discussed accordingly, others will undoubtedly crop up along the way.
A clearly defined road map will need to be defined: 1. Detailing whether
we intend to (and are capable of) parallelising development, so that
each board is being worked on concurrently. Our members would be less
than pleased if we were to prioritise our platforms and theirs were
found at the bottom of the list. There are many ways in which we can
utilise our limited resources to make this happen, but it will take some
careful deliberation in order to figure out an optimal way of working.
2. Detailing which features are the most important for our members. Once
decided we need to create a prioritised feature list which will be
worked through in sequence.
Engineering resources is clearly going to be a touchy subject. Some of
the Working Groups are already feeling over-worked and under staffed,
but engineers need to come from somewhere. To ease the strain I propose
an assignee rotation solution. Swapping out old for new on a per-cycle
or per-board enablement basis. The latter is the preferred solution, as
it ensures that there are no ends to tie-up and that a feature will be
complete before the STG saw fresh blood requiring learning-curve post
context-switch.
Carrying on with the resources theme, other teams from within Linaro
have offered support. As the work is meaningful and interesting there
should be no shortage of volunteers. Should the STG consist of members
from Platform for instance, or can some of the work be sub-contracted
out to them instead?
Hacking sessions at Connect
Anyone who's interested in undertaking some real coding that will end-up
upstream should attend these sessions. There will be plenty of
interesting work available to share around. No upstreaming experience
necessary. As long as you are capable of turning documentation into
functional code I'm sure we can put you to good use. :)
Hacking sessions will require clear documentation detailing the APIs for
each piece of functionality we wish to enable. Does this already exist?
If so, where can it be acquired (http://g.l.o/<wg-tree>/Documentation/)?
In the absence of clear documentation, would the WGs provide a Subject
Matter Expert (SME) to adopt the role of mentor for the sessions? Or
better still, both.
As already discussed, we require a detailed, prioritised feature list of
missing (i.e. to be coded) and enabled (i.e. fully implemented) features
for each board from each of the participating Working Groups.
Topics summarised
- Discuss: Platform development concurrency strategy
- Discuss: Assignee rotation/permanent re-assignment
- Required: Documentation
- Required: Engineering resources (during the sessions and in the team)
- Required: Prioritised missing/enabled feature lists for each platform
I think that'll do for now. :)
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi All,
As part of the 11.09 cycle I've completed an extension to live-build3
that add linaro-media-create. This means with this branch of linaro's
live-build 3 one is able to build your custom image and directly
output it to either your SD media or to a file which you an dd
directly to the media of your choice.
The extension lives in a bzr branch at
lp:~tom-gall/live-build/integrate-linaro-media-create
This code should be considered beta quality. There are bugs. The code
is however useful. It will be especially useful when combined with the
cross build support for live-build that was announced as part of the
11.07 cycle.
I've updated my HOWTO which can be found here:
https://wiki.linaro.org/LiveHelper/Hacking
If you run into issues please either file a bug in launchpad
https://bugs.launchpad.net/linaro-ubuntu , post to the list, or grab
me on irc. (tgall_foo or Dr_Who)
--
Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Hi All,
I'm setting up a new machine and I'm guessing I must have missed a
step or a file.
When I debuild -S -sa it's complaining about my secret key not being found.
gpg: skipped "Tom Gall <tom.gall(a)linaro.org>": secret key not available
gpg: /tmp/debsign.Or3BKbui/live-build_3.0~a21-1linaro9~natty1.dsc:
clearsign failed: secret key not available
debsign: gpg error occurred! Aborting....
Yet if I gpg -k on both a "good" machine and this new box I see the
exact same set of keys listed.
Thoughts?
--
Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Enclosed please find the link to the Weekly Status report
for the kernel working group for the week ending 2011-09-30
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-09-26
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-09-29
== Summary ==
(For more details, refer to the Weekly Status and Meeting Minutes)
Planned October deliverables
Linaro-Android
* Updated, tested and released a Linaro+Android baseline kernel
linux-linaro-3.0-2011.09-0-android-1
Kconfig
* Resubmitted the config fragment merge script to lkml and got some
additional feedback.
Device Tree
[i.mxq6] Submitted the v3 of i.mx6q patch series.
* Reworked the L2 register save/restore implementation per Lorenzo's
suggestion
* Rebased to Rob's latest GIC OF bindings series
* Rebased to Sascha's MULTI_IRQ_HANDLER support series
* imfec, gpio and usdhc patches have been merged by sub-system
maintainers.
[exynos4]
* Added DT support for Exynos4 uart driver (using the ckdev support
added for Samsung uart driver).
* Reworked regulator DT support patches based on comments from
Mark/Grant.
[vexpress] DT patches posted for review
* Started omap mmc driver DT migration. Will use auxdata to start with for
all the function pointers currently passed from pdata
* smsc911x register size DT fix merged
* Worked on adding clkdev support for Samsung uart driver
Pin Control
* Requested pin control subsystem to be included in linux-next: git://
git.linaro.org/people/triad/linux-pinctrl.git for-next
Thumb-2
* Fixing some Thumb-2 related randconfig errors reported by Arnd
* A number of stalled Thumb-2 issues:
* v6/v7 single kernel Thumb-2 undef fixup patches: currently waiting for
Russell/Arnd to comment
* pxa/pj4/iwmmxt uses non-Thumb-2-compatible code: waiting for feedback
(probably needs a Marvell expert to comment)
* tegra2 uses non-Thumb-2-compatible code: waiting for feedback from
Colin Cross.
Best Regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>