Detailed dashboard:
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport
Last weekly meeting minutes
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-12-14
Highlights:
- bug #855524 was fixed, so glproxy can now be enabled for glcompbench
- glmark2: added live FPS counter on the screen (enabled via commandline
option)
- glcompbench: Fixed a bug in ShaderSource which caused a failure on
pandaboard
- dmabuf: incorporated v2 review comments, taking care now of all the
outstanding comments
- dmabuf - started setting up the work for a demo aimed at ELC
- Updated the Mali user and kernel drivers for Linaro ICS - they were
released to the LT - reportedly they work fine
- Ongoing analysis of cpufreq to get hints on GPU power management
Issues:
- Unity/NUX/Compiz: we have the code with fixes from Frederic Plourde
for unity, nux and compiz to resolve the framebuffer object issues (in
short: compiz gained a system to manage FBOs and uses FBO to draw in
before painting to the screen - useful for post-processing.
Unfortunately Unity makes heavy use of FBOs via nux and the UnityFBO
system itself). Ricardo Salveti has agreed to put together the packages
needed for the release
Questions/Issues - please point them out to me
Best regards,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Hi All,
I'm trying to push some code to my repo on git.linaro.org and it's
like the repo is silently failing Note the following:
tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push
ssh://tomgall@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
android:origin/1.2-beta-linaro-andoid
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 429 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To ssh://tomgall@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
746c51b..95ed21e android -> origin/1.2-beta-linaro-andoid
tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git status
# On branch android
# Your branch is ahead of 'origin/1.2-beta-linaro-andoid' by 1 commit.
#
nothing to commit (working directory clean)
tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push
ssh://tomgall@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
android:origin/1.2-beta-linaro-andoid
Everything up-to-date
tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git branch
* android
master
tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git branch -r
origin/1.1.0-linaro
origin/1.1.1-linaro
origin/1.1.1-linaro-android
origin/1.2-beta-linaro-andoid
origin/HEAD -> origin/master
origin/master
git log does correctly show the commit on the local branch:
commit 95ed21e84965f859da0792558742f9cbf9d4ac7a
Author: Tom Gall <tom.gall(a)linaro.org>
Date: Wed Dec 14 19:20:49 2011 -0600
Remove config.h since it was conflicting with other Android
components. From cyang.
ideas? suggestions?
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | 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
folks, hi,
apologies for the wide distribution of this message, reasons will
become clear: please do subscribe to arm-netbooks(a)lists.phcomp.co.uk
and respond there (subscription required) rather than to all these
lists.
the short version of the story is that Rhombus Tech (a CIC company -
not a not-for-profit or a Ltd Company) is now taking preorder
committments - pledges - to buy EOMA-PCMCIA-compliant CPU cards using
a low-cost but feature-rich ARM Cortex A8 CPU called the Allwinner
A10.
http://http://rhombus-tech.net//allwinner_a10/orders/
some bullet-points:
* this initiative is similar to the openpandora, the openmoko, ben
nanonote etc. except that the lessons have been learned from these
projects, to keep it very very simple, low-risk and modular, but still
functional and useful (to Software Libre Developers) as a module. the
goal is also different in that the plan is to leverage mass-volume
pricing and opportunities, to the direct benefit of the Software
(Libre) Community. more info on http://rhombus-tech.net main page.
* the A10 has (at least) HDMI, SATA-II, 10/100 Ethernet, takes up to
1gb of 800mhz DDR3 RAM, has a superb 32-bit-wide 8-way concurrent
DMA-driven NAND Flash interface, MALI 400MP 3D Graphics, does 2160p
(2x 1080p) Video, has 4 SD 3.0 Ultra-High-Speed interfaces, 2x 24-pin
RGB/TTL LCD interfaces, IDE (PATA)... i'm repeating what's on the
rhombus tech web site so will stop here (link below)
* the price of the allwinner CPU is so low in mass-volume ($USD 7)
that in mass-volume (100k pricing) a PCB that is comparable to the
raspberrypi would only be $USD 15 instead of $25, yet the A10 would be
3x faster processing speed (the rbpi's CPU is only a 700mhz ARM11 yet
is more expensive).
* the CPU card will be able to operate as a stand-alone (USB-OTG
powered) computer, with HDMI output, boot from Micro-SD, and stereo
headphones/mic, yet due to EOMA-PCMCIA compliance it will plug into a
wide range of future devices.
* unlike the beagleboard, origen, IMX53QSB etc. this is not a
SoC-fabless-semiconductor-company-driven or a Linaro-driven
initiative, it is a commercial initiative with an absolute top
priority focus on GPL compliance and involving Software (Libre)
Developers every step of the way, hence the reason for using a CIC not
a Ltd Company.
* GPL Kernel Source code has been obtained from allwinner: RHT has the
full support of allwinner's Board of Directors, and the Reference
Platform source code is available on alioth.debian.org.
* as the primary focus of this initiative is, at this stage, to invite
Software (Libre) Developers to be involved, it has not been widely
announced. this is therefore the 1st reason why these lists are
specifically being contacted.
* as the CPU cards are designed to be in legacy PCMCIA form-factor,
motherboards and devices such as tablets, laptops, plug computers, NAS
boxes, IPTVs, are all possible, including embedded and other
industrial purposes.
the only other thing is that we are actively seeking "Admins" for the
Rhombus Tech web site, from a wide range of different communities.
the responsibilities are very small - they're a bit like those of
slashdot meta-moderation. primarily we need people to be able to vet
sponsorship for receipt of developer boards, using the profits raised
by the CIC, for the direct strategic benefit of the Software (Libre)
Community. this is similar in effect to the beagleboard sponsorship
programme, but unlike the beagleboard sponsorship programme, if
sufficient profits are raised by the CIC it will be possible for
Admins to decide to donate boards taking up the entire years'
remaining profits in one go, to worthwhile causes.
clearly, to find such people it is necessary to reach an appropriate
audience, hence the 2nd reason why this message is going specifically
to ARM lists in each of the major gnu/linux distros. there are at
present 4 people who have agreed to be Admins, including phil hands,
alain williams, wookey and james vasile, each in "unofficial"
capacities with no relation to any other duties or roles that they
fulfil. ideally we could do with one or two more from each of the
other gnu/linux distros.
lastly: there *is* the possibility of adapting something like the
beaglebone, which would, if the AM3357 was used, mean that the
resultant hardware could potentially be FSF-Hardware-Endorsed: if this
is something of interest to you please do speak up (on the
arm-netbook(a)lists.phcomp.co.uk list) or likewise if you would prefer
any other "Open Schematics" board such as IMX53QSB, pandaboard etc. to
be adapted please do say so.
ok i'll leave it at that. it's worth repeating - discussion please
contact me either privately, directly, or subscribe to
arm-netbook(a)lists.phcomp.co.uk, list instructions below.
many thanks.
links here:
EOMA-PCMCIA spec:
http://www.elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
allwinner page: http://http://rhombus-tech.net//allwinner_a10/
preorders page: http://http://rhombus-tech.net//allwinner_a10/orders/
accidental slashdot article: http://goo.gl/M7YQH
rhombus-tech web site: http://rhombus-tech.net
arm-netbooks: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
beaglebone idea:
http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/001155.html
am335x page: http://rhombus-tech.net/am335x
Hi all,
We've experienced slowness with git.linaro.org yesterday that is harming
our release process. Since we've already had new machine for hosting
git.linaro.org being set up (in the final stages of it), we're about to
switch the machines around. We've spent the morning testing the new
machine and it seems ready to go.
This means that we'll be shutting off any git access to git.linaro.org
shortly (at 12:30 UTC), and we expect a downtime of 30 minutes to get
new machine up (but let's keep the window of 1h just in case). If you
have any urgent issues, please shout before we go for the downtime.
Sorry for such a short notice!
Cheers,
Danilo
On Wed, Dec 14, 2011 at 05:42:09PM +0400, Anton Vorontsov wrote:
> I presume this depends on other patches, so I'm fine if this goes via
> non-battery tree,
There should be no direct dependencies for new MFDs - the Kconfig
required to depend on the MFD core means that the drivers can't be
selected until the core appears.
Hi all,
Sorry for the wide distribution, but I've got a rather curious problem.
I'm trying to get a Snowball V11 PDK working in the validation lab, and the only way to get it to boot on power-on is to power it over USB and control the power through a USB power adaptor. While this works admirably, the problem is that when I try to soft-reboot I get the usual:
Broadcast message from root@master
(/dev/ttyAMA2) at 15:48 ...
The system is going down for reboot NOW!
* Asking all remaining processes to terminate... [ OK ]
* All processes ended within 1 seconds.... [ OK ]
* Deconfiguring network interfaces... [ OK ]
* Deactivating swap... [ OK ]
umount: /run/lock: not mounted
* Will now restart
[ 1279.346801] Restarting system.
and then nothing. It just hangs and never comes back until I power cycle it.
BTW: Sometimes I get the whole of the "Restarting system" message, sometimes just half of it.
Has anybody any idea why this might be the case and, if so, what I can do about it?
Thanks
Dave
Dave Pigott
Validation Engineer
T: +44 1223 45 00 24 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
This series is just informational and illustrates how to use some of the
common struct clk features. I wrote this code when testing the common
struct patches. These are hacks and put some of code to use
practically.
Firstly this series models the clocks between the MPU PLL and the ARM IP
a bit more closely. Then CPUfreq is changed to use this new mpu_clk,
which passes the rate change up to the PLL.
Another new clk, mpu_periphclk, is introduced which divides mpu_clk by
2. The recent smp_twd code from Linus W. is modified to use clk rate
change notifiers for mpu_periphclk instead of CPUfreq notifiers.
Finally this series introduces a new OPP for the MPU on OMAP4 which
bypasses the MPU DPLL and exercies some of the clk frameworks parent
switching code. Using this OPP is probably unsafe and will permanently
ruin your board, your desk and your home.
You can find the common struct clk patches at,
https://lkml.org/lkml/2011/12/13/451
OMAP support for the common struct clk is needed for this series and can
be found at,
http://article.gmane.org/gmane.linux.ports.arm.omap/68217
These patches can be found at,
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=ref…git://git.linaro.org/people/mturquette/linux.git v3.2-rc5-clkv4-omap-pm-testing
Linus Walleij (1):
smp_twd: Reconfigure clockevents after cpufreq change
Mike Turquette (5):
HACK: omap: opp: add fake 400MHz OPP to bypass MPU
omap: clk: .round_rate for propagating to parents
HACK: omap: clk: add mpu_periphclk clk node
HACK: cpufreq: omap: change mpu_clk's rate
HACK: arm: reprogram twd based on clk notifier
arch/arm/kernel/smp_twd.c | 89 +++++++++++++++++++++++++++++++--
arch/arm/mach-omap2/clkt_clksel.c | 8 +++
arch/arm/mach-omap2/clock.h | 2 +
arch/arm/mach-omap2/clock44xx_data.c | 37 ++++++++++++++-
arch/arm/mach-omap2/opp4xxx_data.c | 9 ++++
drivers/cpufreq/omap-cpufreq.c | 2 +-
6 files changed, 139 insertions(+), 8 deletions(-)
--
1.7.5.4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I am using the linux-next head git tree on a snowball V5.
The kernel hangs at "Uncompressing kernel... done".
After bisecting, the patch where the kernel does no longer boot is:
commit 549158d2ab01e8370d2773044fe09738a26f7086
Author: Nicolas Pitre <nicolas.pitre(a)linaro.org>
Date: Thu Aug 25 00:35:59 2011 -0400
ARM: move iotable mappings within the vmalloc region
In order to remove the build time variation between different SOCs
with
regards to VMALLOC_END, the iotable mappings are now allocated inside
the vmalloc region. This allows for VMALLOC_END to be identical
across
all machines.
The value for VMALLOC_END is now set to 0xff000000 which is right
where
the consistent DMA area starts.
To accommodate all static mappings on machines with possible
highmem usage,
the default vmalloc area size is changed to 240 MB so that
VMALLOC_START
is no higher than 0xf0000000 by default.
Signed-off-by: Nicolas Pitre <nicolas.pitre(a)linaro.org>
Tested-by: Stephen Warren <swarren(a)nvidia.com>
Tested-by: Kevin Hilman <khilman(a)ti.com>
Tested-by: Jamie Iles <jamie(a)jamieiles.com>
Is it a known issue ?
kernel config file : http://pastebin.com/E6HngT58
Thanks
-- Daniel
- --
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO15RUAAoJEAKBbMCpUGYA+JkIALr9uQl2EgpCuvjo9udAs6LI
dqM1w0BvMpr2WxcMO0pUvqsCKMKBcuWz6sC/BZjCJmpcxT5H8Am6YJTFq4l4y+tO
09Ggt2fK3AUWH6CBlja8HD0MEQkkjv45tiFWS0s6qFdd4MhhII+P9M04kSwaQ24u
PWwCiPofwx2RfYGM7an7VBpTAgqOuIaL5CUJdjDL5wgHsZW/qE5hQVN+V/V47TPq
1M1A9xaBs+3BhU0yTe8JMstaXoGqTgehkE5puFXZ+6f+qhLRJZTRXwu2lHbXCdyf
rcByM65gB3cSfb555DKnXgK7qB4T2n0t/nilkkT1PaO7sM0I9E4O2wdQk5KvtbE=
=RaPn
-----END PGP SIGNATURE-----