Hi,
Following is the agenda of proposed "Android Porting" session at Connect
https://blueprints.launchpad.net/linaro-android/+spec/linaro-platforms-lc4.…
This will be a "How-To" session on "Porting Android on New Platforms",
including but not limited to following sub-topics:
- Android Software Stack overview
- AOSP Code structure
- Vendor/Device specific settings and HAL implementations/hooks
- AOSP Build process
- Android Boot process
Feel free to point out if I missed out on something which can be of group's
interest.
Regards,
Amit Pundir
Hi Andy,
Thanks for this initiative.
I've attached a screenshot from Google Analytics showing the most commonly
hit pages on the Wiki over the past 3 months (I can get you access to the
site if you want to look at in more detail).
Android, Platform Image Installation, Meet The Team, Linaro Connect and the
Monthly releases are what users are going to. We need to make sure they are
all one click away and near the top of the page. (Also are there any other
pages we would _like_ people going to that they don't currently? They could
be candidates to elevate to the top)
Also, I think the Twitter feed should be LinaroTech rather than LinaroOrg.
Tech is meant to be for the tech audience, org is more targeted to business.
And I'm not sure it should be the very first item on the page either
Thx
Stephen
------------------------------
Message: 6
Date: Wed, 28 Sep 2011 14:59:20 -0500
From: Andy Doan <andy.doan(a)linaro.org>
To: linaro-dev <linaro-dev(a)lists.linaro.org>
Subject: wiki feedback on new front page
Message-ID: <4E837C98.4050200(a)linaro.org>
Content-Type: text/plain; charset=ISO-8859-1
Michael and I were tasked with making the front page of the Linaro wiki
a little more developer focused and offloading some of the other
information to the main website, linaro.org.
We've put together a prototype page and would like to get some feedback
before making the real switch:
https://wiki.linaro.org/AndyDoan/Sandbox/FrontPage
thanks,
-andy
In prep for Linaro Connect & the Ubuntu Developers Summit next week
I've put together some performance measurements comparing libjpeg8c
and libjpeg-turbo compiled with it's libjpeg8 compatibility setting.
Quality settings of 95 and 75 are used. Image sizes used are 640x480
and 3136x2352.
Hardware used includes the imx53 QuickStart board by freescale and an
intel core 2 duo in my Lenovo T400.
The results can be found here including both the raw numbers and pretty graphs.
https://wiki.linaro.org/TomGall/LibJpeg8
It is my hope that at LC/UDS we will be able to use these numbers to
convince ubuntu to reconsider it's switch to libjpeg8 and instead move
to libjpeg-turbo. The 2x-4x across the board performance improvement
story is compelling not to mention the technical side of it as well.
--
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,
we're having a session on parameterization of an Android build at Connect.
We will discuss what parts of an Android build should be parameterized
outside the source tree.
Probably many people of the Android team will want to attend - others
interested could be toolchain (compiler flags are on the list - this
could help you test the effects of a new flag) and kernel (we're also
thinking about kernel configs, e.g. debuggable/profilable build vs.
speed optimized build) developers.
Of course anyone else who cares is welcome to attend.
Please sign up if you think the session could be interesting for you
(and/or forward to others you think should attend).
https://blueprints.launchpad.net/linaro-android/+spec/linaro-platforms-lc4.…
ttyl
bero
Hi,
we're going to have a session on additional developer tools for Linaro
Android at Connect.
I think that, given we all need to do debugging at times, probably
most of the Android team should be there, and I'd like someone from
the toolchain group to be there, given we'll also have toolchain
problems that need to be debugged on Android.
Of course anyone else who is interested is welcome to join.
Please sign up if you think the session could be interesting for you
(and/or forward to others you think should attend).
https://blueprints.launchpad.net/linaro-android/+spec/linaro-platforms-lc4.…
ttyl
bero
Hi. If you are attempting to cross-post to both linaro-dev and
libjpeg-turbo-devel, please subscribe to libjpeg-turbo-devel.
Otherwise, every time you CC libjpeg-turbo-devel, the message will
automatically be moderated, and I have to manually log in and approve
each one.
DRC
Hi -
Linus released 3.1 a couple of days ago, I have archived the tracking
androidization patchset with a pure vanilla 3.1 release basis here
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortl…
The tracking androidization tree has already moved on into Linus' new
pre-3.2 basis territory
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortl…
There were big file layout refactors in the mainline networking stack that
caused a lot of impact network / wireless related patches, some smaller
adaptations needed in gadget related patches and a little bluetooth dust.
Interestingly during the uplevel I noticed three patches (of ~470) had
evidently managed to get upstream so far for 3.2
0419-ipv6-updates-to-privacy-addresses-per-RFC-4941.patch
0431-hid-debug-Show-application-usage-for-each-collection.patch
0432-hid-multitouch-Filter-collections-by-application-usa.patch
I am updating the affected patches in linaro-androidization-tracking
directly. I have already been automatically tagging each push, with, eg,
"linaro-androidization-tracking-2011-10-25-18-24-CST", so there is a history
of these rebase trees being kept.
My plan after this is to perform a more aggressive squash on the refactored
patchset (I would like to considerably reduce the number of "internal
history" type patches, keeping the contributor patch logs in the squash
patch's log) and moving to using just that, instead of continuing to run the
patchset we started with and the refactored one simultaneously.
I am testing this against OMAP4 Panda board, soon there will be more test
coverage coming for the other LEBs supported by Linaro. We know already
that some of the non-core Androidization features were broken in common-3.0
and remained broken in the starting point for this tree. Any patches to fix
things like Broadcomm WLAN or whatever that we don't use at Linaro will be
very welcome. However, we believe the all core Android features are working
fine on this tree, since they result in a working Linaro Android rootfs for
Panda (complete with PVR accelerated video).
-Andy
PS If anyone interested in this stuff is at Linaro Connect, feel free to
ping me for a chat / beer
Key Points for wider discussion
===============================
* USB camera (UVC) now works on linaro-android builds.
* Test results for 0xbench on Panda builds from 11.04 to 11.10 has been
executed:
https://docs.google.com/a/linaro.org/#folders/0B0xwyUNxNaAaNWZlYjVhMGQtYmUx…
Team Highlights
===============================
* Connect sessions prepared:
https://blueprints.launchpad.net/sprints/lcq4.11/+specs?searchtext=linaro-p…
* Linaro Android 11.10 RC for Samsung Origen has been done.
* Solved the the build problems and integrated support for DS-5 in upstream
build. Blocking bug in gdbserver remain.
* Presentation material about
https://docs.google.com/a/linaro.org/present/view?id=dhq2qhr2_25hs5fhzdd
* Audio playback and recording works on LEB-panda
* 10.1 Release candidates thoroughly tested.
* Progress on Video calls through Linphone on Panda.
* ELC-E talk about toolchain related optimizations.
* ELC-E talk about Linaro's Android Platform.
Miscellaneous
===============================
* Focus on Connect.
Issues
===============================
* gdbserver is needed to connect DS-5 to the gator daemon, but gdbserver
seg faults. Bug# 881848
* Rebasing John Stultz's 3.1 androidization branch on latest STE-GLK3.0 was
not possible.
Hi all,
The goal of this series is to provide a cross-platform clock framework
that platforms can use to model their clock trees and perform common
operations on them. Currently everyone re-invents their own clock tree
inside platform code which makes it impossible for drivers to use the
clock APIs safely across many platforms and for distro's to compile
multi-platform kernels which all redefine struct clk and its operations.
This is the second version of the common clock patches which were
originally posted by Jeremy Kerr and then re-posted with some additional
patches by Mark Brown. Mark's re-post didn't have any changes done to
the original four patches from Jeremy which is why this series is "v2".
The changes in this series are minimal: I've folded in some of Mark's
fixes and most of the comments posted to his series as well as rebasing
on top of v3.1-rc7. The design and functionality hasn't changed much
since Jeremy posted v1 of this series. Propagating the rate change up
to the parent has been removed from clk_set_rate since that needs some
more thought. I also dropped Mark's change to append a device's name to
a clk name since device tree might solve this neatly. Again more
discussion around that would be good.
v1 of the series can be found at,
http://article.gmane.org/gmane.linux.kernel/1143182
Mark's re-post (v1+) can be found at,
http://article.gmane.org/gmane.linux.ports.arm.kernel/129889
Todo in follow-up patches:
clk_set_parent
Implement a *safe* upstream propagation for parent rate changes
Track tree topology and export to userspace (sysfs or debugfs)
Manage root clocks globally
Device tree support
Per-tree locking instead of framework-wide locking
Device driver rate-change notifiers
Jeremy Kerr (4):
clk: Add a generic clock infrastructure
clk: Implement clk_set_rate
clk: Add fixed-rate clock
clk: Add simple gated clock
Mark Brown (3):
clk: Add Kconfig option to build all generic clk drivers
clk: Add initial WM831x clock driver
x86: Enable generic clk API on x86
MAINTAINERS | 1 +
arch/x86/Kconfig | 1 +
drivers/clk/Kconfig | 27 +++-
drivers/clk/Makefile | 4 +
drivers/clk/clk-fixed.c | 24 +++
drivers/clk/clk-gate.c | 78 ++++++++++
drivers/clk/clk-wm831x.c | 386 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/clk/clk.c | 291 ++++++++++++++++++++++++++++++++++
drivers/clk/clkdev.c | 7 +
include/linux/clk.h | 179 ++++++++++++++++++++--
10 files changed, 985 insertions(+), 13 deletions(-)
create mode 100644 drivers/clk/clk-fixed.c
create mode 100644 drivers/clk/clk-gate.c
create mode 100644 drivers/clk/clk-wm831x.c
create mode 100644 drivers/clk/clk.c
--
1.7.4.1
