While we're planning for connect, I'd like to suggest that we do away
with team tracks all together and just have topic tracks. This would
align with our topic based approach to things now, and would be a way
to breakdown our silo's. The topic track would be lead by a topic
champion. What do people think?
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
Tested on OMAP3 (igepV2).
Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
V3 :
* replace OMAP4_NUM_STATES and OMAP3_NUM_STATES by ARRAY_SIZE
* Fixed changelog
* Fixed OMAP4_NUM_STATES going back and forth in the patchset
* Removed erratum check at init time
V2 :
* Fixed a couple of typos in the patch description
V1 : Initial Post
Daniel Lezcano (18):
ARM: OMAP4: cpuidle - Remove unused valid field
ARM: OMAP4: cpuidle - Declare the states with the driver declaration
ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot
time
ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table
ARM: OMAP3: define cpuidle statically
ARM: OMAP3: cpuidle - remove errata check in the init function
ARM: OMAP3: cpuidle - remove the 'valid' field
ARM: OMAP3: cpuidle - remove cpuidle_params_table
ARM: OMAP3: define statically the omap3_idle_data
ARM: OMAP3: cpuidle - use omap3_idle_data directly
ARM: OMAP3: cpuidle - simplify next_valid_state
ARM: OMAP3: set omap3_idle_data as static
ARM: OMAP3/4: consolidate cpuidle Makefile
ARM: OMAP3: cpuidle - set global variables static
arch/arm/mach-omap2/Makefile | 11 +-
arch/arm/mach-omap2/board-rx51.c | 38 +++---
arch/arm/mach-omap2/cpuidle34xx.c | 306 +++++++++++++++----------------------
arch/arm/mach-omap2/cpuidle44xx.c | 134 +++++++----------
arch/arm/mach-omap2/pm.h | 38 ++---
5 files changed, 212 insertions(+), 315 deletions(-)
--
1.7.5.4
Fathi,
Since we're at the start of 12.05 we need to shift the builds over to
the tip toolchain and stop daily builds for various baselines. I
figure we can also get the configs into git. Do you want to take care
of getting the current configs into git and then shift the builds or
the other way around?
For 12.05 I'd kill all dailies except for the tips listed on
android-build.linaro.org under:
"Users who are interested in tip builds with Linaro goodness should use:"
People can always re-enable dalies they're interested in.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Quantal is now open for development, with syncs from unstable starting shortly.
The development version starts with updated versions of GCC and OpenJDK, some
soname changes (boost, hdf5), and some changes with setting the build flags for
package builds. We are finally targeting Python3 as the
only Python version on the ISO/installation images.
- GCC 4.7 is now the default, introducing some build failures caused
by unknown compiler options, and more C++ strictness. Hints how to fix
packages can be found at [1]. Bug reports for packages are not yet
filed directly in Launchpad, but can be found on the Debian BTS instead [2].
- OpenJDK 7 is now used as the default, replacing OpenJDK 6, introducing
some build failures. The build status can be tracked at [3], open issues
are tracked at [4].
- Removing build flags exported from dpkg-buildpackage for quantal will
get us in sync with Debian. Implications and fixes are discussed
on the ubuntu-devel ML [5].
- Python 3 is now again part of a minimal chroot on quantal, and will
be the only Python version provided on the ISO/installation images
for quantal. Packages which need updates and ports for Python 3
are tracked at [6]
Please check your uploads in a quantal chroot, don't just test in a precise
environment. See [7] how to setup such a development chroot.
[1] http://gcc.gnu.org/gcc-4.7/porting_to.html
[2]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian…
[3] https://wiki.ubuntu.com/JavaTeam/Java7Default
[4]
https://bugs.launchpad.net/ubuntu/+bugs?search=Search&field.bug_reporter=ja…
[5] https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035149.html
[6] https://wiki.ubuntu.com/Python/FoundationsQPythonVersions
[7] https://wiki.ubuntu.com/DebootstrapChroot
Hi,
> ---------- Forwarded message ----------
> From: Tim Redfern <tim(a)eclectronics.org>
> To: linaro-announce(a)lists.linaro.org
> Date: Sun, 29 Apr 2012 22:25:32 +0100
> Subject: re: Linaro 12.04 released
> Hi I have a question,
>
> Will there be a community build of linaro for gumstix overo (as with
> previous versions) ?
>
> Or was overo dropped for some reason?
With the switch to Ubuntu Precise/armhf, several builds were broken or
untested (LAVA was offline).
That's the main reasons why BeagleBoard or Overo hasn't been published.
Assuming we have a working, tested build and a sponsor, they'll be back.
Cheers,
--
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs
just some random thoughts on our release model, etc.. I've been
meaning to write up for a while but haven't had time
There has been some feedback, for example on #pandaboard, that the
monthly release cycle is confusing and detrimental for folks looking
for something working and stable, and not necessarily bleeding edge,
the question is, "should I upgrade?", "what is fixed and what is now
broken?". Linaro is doing some great upstream work, and enabling
features on these boards, and it is good to showcase that, but I'm not
really sure the best way to do this is rush that into the next monthly
release and break things for all the new users of their shiny new
xyz-board.
I tend to think that part of the problem is that the cadence of
monthly releases is too fast for any sort of stability. Perhaps we
should think more along the lines of releases roughly every quarter
(potentially with "beta"s in between). I don't think we should
strictly adhere to a time based release cycle, but we should call it a
final/stable release when it actually is so. There is a reason that
the linux kernel uses an approx 3 month release cycle, but doesn't
stick to that dogmatically when things aren't really at release
quality yet.
But, we do still need a place for latest-and-greatest bleeding edge
for folks who want to check out what we are working on. One approach,
for example for ubuntu releases, we could have a "release" and "trunk"
PPA for bleeding-edge.. that way folks looking for bleeding-edge can
get it, and folks looking for "it just works" are not screwed. I'm
not quite sure what android equivalent would be, but I guess we could
figure something out. This gives folks in board specific channels
like #pandaboard who are trying to help new users something to
reliably point them at without having to worry if they are giving bad
advice to recommend a linaro filesystem. And updates do not have to
be tied to a time-based schedule. If something is broken for feature
x for board y in the release PPA, then as soon as it is fixed (and if
it doesn't break board z), then push an update to the release PPA.
But maybe big new features shouldn't immediately go to the release PPA
without some soak time first in the trunk PPA. It is great to be
enabling new features, but for someone new to the arm platform I don't
want to just frustrate and scare them off.
Also, I wonder if we should split #linaro, either into #linaro-devel
and leave #linaro as a place that users can come to for help, or setup
a separate #linaro-users? This way we aren't just dumping out new
releases with nowhere for users to turn to for help.. (Well, they can
always come to #linaro but I guess this would help with the
signal-to-noise..)
BR,
-R
This series collects many of the fixes posted for the recently merged
common clock framework as well as some general clean-up. Most of the
code classifies as a clean-up moreso than a bug fix; hopefully this is
not a problem since the common clk framework is new code pulled for 3.4.
Patches are based on v3.4-rc2 and can be pulled from:
git://git.linaro.org/people/mturquette/linux.git v3.4-rc2-clk-fixes
Please let me know I missed any critical fixes that were posted to the
list already.
Arnd & Olof, if there are no objections to these changes can this get
pulled through the arm-soc tree?
Thanks,
Mike
Mark Brown (2):
clk: Remove comment for end of CONFIG_COMMON_CLK section
clk: Constify parent name arrays
Mike Turquette (6):
clk: core: correct clk_set_rate kerneldoc
clk: core: remove dead code paths
clk: core: clk_calc_new_rates handles NULL parents
clk: core: enforce clk_ops consistency
clk: core: copy parent_names & return error codes
clk: basic: improve parent_names & return errors
Rajendra Nayak (1):
clk: Make clk_get_rate() return 0 on error
Shawn Guo (4):
clk: use kzalloc in clk_register_mux
clk: remove unnecessary EXPORT_SYMBOL_GPL
clk: add "const" for clk_ops of basic clks
clk: declare clk_ops of basic clks in clk-provider.h
drivers/clk/clk-divider.c | 51 +++++++++----
drivers/clk/clk-fixed-rate.c | 57 +++++++++------
drivers/clk/clk-gate.c | 53 ++++++++++-----
drivers/clk/clk-mux.c | 16 +++--
drivers/clk/clk.c | 159 ++++++++++++++++++++++++++---------------
include/linux/clk-private.h | 14 +---
include/linux/clk-provider.h | 13 ++--
include/linux/clk.h | 2 +-
8 files changed, 230 insertions(+), 135 deletions(-)
--
1.7.5.4
Version 12.04 of Linaro U-Boot has been released. Details on Launchpad here:
https://launchpad.net/u-boot-linaro/trunk/12.04
And on git.linaro.org here:
http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=shortlog;h=r…
>From the release notes:
This release is primarily a rebase onto the latest upstream
git.denx.de release v2012.04. Several patches that have been carried
in u-boot-linaro have been dropped because that functionality has gone
upstream. This includes OMAP[345] usb support including network
support on Panda and Beagle xM and the Highbank support from Calxeda.
This release continues to include some Snowball support but not enough
to be usable. This release also still requires the cache disabling
patch for OMAP3 that has been carried for months but upstream remains
broken with Linaro kernels without it. See Changelog for list of all
patches to v2012.04.
Here are the Linaro patches on top of upstream v2012.04:
0b07b6e PXE: OMAP4: add standard env vars
9f4c29c arm: omap4_panda: Enable pxecfg support
948aae2 SAUCE: OMAP4 Make pxe boot fallback default boot
21c1a80 OMAP3: Beagle: Add standard addresses to env
c448146 OMAP3: Beagle: Enable PXE support
84d1169 OMAP3: igep0020: Enable PXE support
1f18000 MX53LOCO: Enable PXE boot
efa46fe ARM: vexpress: move files in preparation for adding a new platform
6721629 ARM: vexpress: create A9 specific board config
3dbbeb8 ARM: vexpress: create A5 specific board config
b4673ba ARM: vexpress: Change maintainer for ARM Versatile Express platforms
8366422 ARM: vexpress: Extend default boot sequence to load script from MMC
f412e91 net: allow setting env enetaddr from net device setting
9ac3e2d ARM: highbank: add autoboot script files
de80572 ARM: highbank: update autoboot bootdelay value
5c7d44e Add a default env that will use boot.scr from the vfat partition
d74b1a8 Origen: Enable CONFIG_OF_LIBFDT
ed3b575 MMC: arm_pl180_mmci: allow multiple devices
6185c31 mx53loco: define ERRATUM_ESDHC111
1b02df5 mx5: Add clock config interface
2fd31d5 mx53loco: PMIC: Add dialog pmic support
c450b5d mx53loco: Add power init support
bfc8de9 mx53loco: workaround VPU TO2 Errata by increasing peripheral voltage
459a66c mx53loco: add support for MC34708
996306c arm: imx6q: add axi cache and qos setting
7ebf30e arm: imx6q: add anatop regulator init
67db864 fec_mxc: increase autonegotiation timeout
5a67a40 fec_mxc: move autonegoatiate restart after mii_postcall
a7f6854 OMAP4: avoid null pointer access in save_boot_params
b66a9b6 OMAP4: Make mmc and fat conditional in spl
f388f20 OMAP4: Panda: Add usb peripheral boot
06fb246 OMAP4: Panda: Add USB_SPL variant
1631036 OMAP4: Force PXE booting when booting via spl-usb
4c62942 snowball: igloo copy port of armv7/u8500 and include/asm/arch-u8500
f68b175 snowball: igloo copy port of gpio driver support
2afb10a snowball: add snowball to boards.cfg
9053991 snowball: igloo copy port of board specific files
602bef8 snowball: arm cpu: inv and clean of L2
e3e64ab HACK: Copy in alternate mmc files for snowball
c64a8a5 HACK: Bypass normal mmc if CONFIG_SNOWBALL_MMC_HACK
90b88ef debugX to debug
368cfd9 SAUCE: Snowball: init serial later
aca528b PXE: look for usbethaddr if no ethaddr
f1ed411 OMAP4 Panda: Generate a unique usbethaddr
923c7d8 OMAP3: Beagle: add back boot.scr support
9b2844c OMAP4: Panda: add uEnv.txt support
047161d OMAP4: Enable command line editing in omap4_common.h
554498e OMAP4: change MAXARGS to 32
46e0a24 OMAP3: Enable command line editing for omap3_beagle
1bf66b5 Allow loading of u-boot.bin for backward compatibility
9e97fcb OMAP3: Beagle: set mac addr from dieid
0a957f5 SAUCE: HACK: move omap spl base address
1551b1a OMAP4: add preEnv.txt support
d4f7dc9 OMAP3 Beagle: add preEnv.txt support
05613f5 Revert "arm: Add Prep subcommand support to bootm"
6f8db25 Revert "armv7: adapt omap3 to the new cache maintenance framework"
Hello All,
I need some help, checked the android documentation and related area,
did not get a solution. This is on screen size for tablet devices during
the boot stage.
Problem statement:
The device is a 7" LCD device (H=480, W=800 device), when Android boots
"SYSTEM UI is not loaded" message pops up and the
navigation/notification bar does NOT appear/display. However all
operations like screen navigation etc are all working and we are able to
navigate through a mouse!!!
I am using a customised version which is a slight offset of SNOWBALL
LINARO ICS.
Logs:
~~~~~~~~~~~~~~~~~~~~~
I/ActivityManager( 1520): Config changed: {1.0 0mcc0mnc en_US
layoutdir=0 sw640dp w1024dp h592dp lrg long land -touch -keyb/v/h -nav/h
s.2}
W/RecognitionManagerService( 1520): no available voice recognition
services found
D/SystemUIService( 2055): loading: class
com.android.systemui.statusbar.tablet.TabletStatusBar
D/SystemUIService( 2055): running:
com.android.systemui.statusbar.tablet.TabletStatusBar@4111b118
D/dalvikvm( 1520): GC_CONCURRENT freed 142K, 13% free 8893K/10183K,
paused 2ms+5ms
I/StatusBar.HeightReceiver( 2055): Resizing status bar plugged=false
height=36 old=0
D/dalvikvm( 1520): GC_FOR_ALLOC freed 1305K, 24% free 7758K/10183K,
paused 31ms
I/dalvikvm-heap( 1520): Grow heap (frag case) to 10.175MB for
1758292-byte allocation
D/dalvikvm( 1520): GC_FOR_ALLOC freed <1K, 21% free 9475K/11911K, paused
35ms
D/dalvikvm( 2055): GC_CONCURRENT freed 212K, 17% free 6070K/7239K,
paused 2ms+2ms
I/WindowManager( 1520): createSurface Window{41287de0 Keyguard
paused=false}: DRAW NOW PENDING
I/libblt_hw( 1337): Library opened (handle = 1, fd = 24)
D/libEGL ( 1520): loaded /system/lib/egl/libGLES_android.so
D/AndroidRuntime( 2055): Shutting down VM
W/dalvikvm( 2055): threadid=1: thread exiting with uncaught exception
(group=0x40a6c1f8)
D/libEGL ( 1520): loaded /system/lib/egl/libEGL_mali.so
E/AndroidRuntime( 2055): FATAL EXCEPTION: main
E/AndroidRuntime( 2055): java.lang.RuntimeException: Unable to create
service com.android.systemui.SystemUIService:
java.lang.RuntimeException: Tablet device cannot show navigation bar and
system bar
E/AndroidRuntime( 2055): at
android.app.ActivityThread.handleCreateService(ActivityThread.java:2262)
E/AndroidRuntime( 2055): at android.app.ActivityThread.access
$1600(ActivityThread.java:122)
E/AndroidRuntime( 2055): at android.app.ActivityThread
$H.handleMessage(ActivityThread.java:1200)
E/AndroidRuntime( 2055): at
android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 2055): at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 2055): at
android.app.ActivityThread.main(ActivityThread.java:4340)
E/AndroidRuntime( 2055): at
java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 2055): at
java.lang.reflect.Method.invoke(Method.java:511)
E/AndroidRuntime( 2055): at com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:784)
E/AndroidRuntime( 2055): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
E/AndroidRuntime( 2055): at dalvik.system.NativeStart.main(Native
Method)
E/AndroidRuntime( 2055): Caused by: java.lang.RuntimeException: Tablet
device cannot show navigation bar and system bar
E/AndroidRuntime( 2055): at
com.android.systemui.statusbar.tablet.TabletStatusBar.makeStatusBarView(TabletStatusBar.java:451)
E/AndroidRuntime( 2055): at
com.android.systemui.statusbar.StatusBar.start(StatusBar.java:64)
E/AndroidRuntime( 2055): at
com.android.systemui.statusbar.tablet.TabletStatusBar.start(TabletStatusBar.java:390)
E/AndroidRuntime( 2055): at
com.android.systemui.SystemUIService.onCreate(SystemUIService.java:93)
E/AndroidRuntime( 2055): at
android.app.ActivityThread.handleCreateService(ActivityThread.java:2252)
~~~~~~~~~~~~~~~~~~~~~~~~
I understand the issue that it is a matter of setting the screen and
device resolution. I had set the "ro.build.characteristics=tablet" in
build.prop and rebooted, did not see any effect. Please note the lines
in bold, blue.
Can you please help me to solve this problem.
Thanks and Regards,
Venkat.
Greetings,
We have depoyed per build EULA handling on http://snapshots.linaro.org
as a part of downloads click through license protection. Now only
"origen" and "snowball" builds that has binary blobs inside are
protected by EULA and at the same time all other builds are open source
and don't require license acceptance.
To protect files in specific directory, the EULA.txt should be placed in
that directory. Otherwise OPEN-EULA.txt should be there. These files
triggers displaying license page based on build name and after accepting
license downloading begins. If there are none of them the user get
"Forbidden" page. Appropriate EULA is added automatically by the build
system.
--
WBR, Georgy Redkozubov
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog