linaro-dev June 2011

linaro-dev@lists.linaro.org

149 participants
196 discussions

[PATCH] OMAPFB: Reset framebuffer after resume

by Kan-Ru Chen

After resume the HDMI/DVI output was still blank. It turns out that framebuffers have to be reconfigured so the output is activated again. --- drivers/video/omap2/omapfb/omapfb-main.c | 33 ++++++++++++++++++++++++++++++ 1 files changed, 33 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index 2bd90ca..a5a0725 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -30,6 +30,7 @@ #include <linux/platform_device.h> #include <linux/omapfb.h> #include <linux/console.h> +#include <linux/pm.h> #include <plat/display.h> #include <plat/vram.h> @@ -2274,6 +2275,37 @@ static int omapfb_parse_def_modes(struct omapfb2_device *fbdev) return r; } +#ifdef CONFIG_PM +static int omapfb_suspend(struct device *dev) +{ + return 0; +} + +static int omapfb_resume(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omapfb2_device *fbdev = platform_get_drvdata(pdev); + int i; + + if (fbdev != NULL) { + for (i = 0; i < fbdev->num_fbs; i++) { + omapfb_set_par(fbdev->fbs[i]); + } + } + return 0; +} +#else +#define omapfb_suspend NULL +#define omapfb_resume NULL +#endif + +static const struct dev_pm_ops omapfb_pm_ops = { + .suspend = omapfb_suspend, + .resume = omapfb_resume, + .poweroff = omapfb_suspend, + .restore = omapfb_resume, +}; + static int omapfb_probe(struct platform_device *pdev) { struct omapfb2_device *fbdev = NULL; @@ -2440,6 +2472,7 @@ static struct platform_driver omapfb_driver = { .driver = { .name = "omapfb", .owner = THIS_MODULE, + .pm = &omapfb_pm_ops, }, }; -- 1.7.5.3

12 years, 11 months

Likely gcc-linaro-4.5-2011.05 misoptimization in libgui (Android)

by Jim Huang

Hello list, If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager. To work around this problem, you can apply the following patch: --- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \ LOCAL_MODULE:= libgui +LOCAL_CFLAGS += -O0 + ifeq ($(TARGET_SIMULATOR),true) LOCAL_LDLIBS += -lpthread endif Then, replace /system/lib/libgui.so with the newer one. I didn't look into the details. But at least, Android is able to serve user interaction again. Related bug: https://bugs.launchpad.net/linaro-android/+bug/787072 Sincerely, -jserv [1] Prebuilt x86 toolchain for Android: http://people.linaro.org/~jserv/toolchain/

12 years, 11 months

[STATUS] 2011/6/5 - 2011/6/11 Zach Pfeffer

by Zach Pfeffer

=== Highlights === * Gave Android Public Plan Review * Interviewed and reviewed potential new Android hires * Attended and participated in the Multimedia WG Mini-Summit in Austin * Gave LT SoW input === Plans === * Package and distribute the Panda Android LEB on GCC 4.5 * Help debug Panda Android LEB on GCC 4.6 issues * Start-up weekly Android/LT/WG meetings * Interview === Issues === * jstultz + the landing team kernel on Panda

12 years, 11 months

[ACTIVITY] OCTO Weekly status 20110606 - 20110710

by Ilias Biris

Meeting minutes in https://wiki.linaro.org/OfficeofCTO/2011-06-07 == Summary == * Setup for August sprint in discussion * status.linaro.org fixed for Octo, but not everything shows up (eg LLVM was not showing due to missig series target for TR, fixed now) * ARMHF: * weekly sync for HF setup * Fixing a lot of bugs, still too many to go * Gnome 2.3 desktop running the efika * Cross build - started looking into LSB * Boot architecture: * Document writing: overview of the model that Linux uses for device tree plus a guide for implementors porting a platform to use device tree * Boot architecture - start collecting data about what we care about * Server: * Canonical Ubuntu Platform sprint in Dublin - Loic going to liase with the server people - week of 27th June * xen.org? Met with Lars Kurth, * Discussion on OpenMax, ready for the multimedia working group 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

12 years, 11 months

[ACTIVITY] Graphics WG status - 20110606-20110610

by Ilias Biris

Please check the following links for details Meeting minutes : https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-06-08 Status: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Status/2011-06-08 == Summary == * status.linaro.org should have easily accessible pointers to a group's related work for each milestone - eg http://status.linaro.org/11.11/linaro-graphics-wg-11.06.html should be easily available. * Compiz: final nagging issue is the presence of weird colours for the texture handling. Alexandros and Travis are working on a possible solution and a report of any issues which may need extra help from other groups (eg desktop experience) * 11.11 work items reflected in s.l.o. Related to memory management, apart from Jesse's recent communication the buffer object sharing API is being fleshed out (check: https://blueprints.launchpad.net/linaro-graphics-wg/+spec/engr-mm-bo-sharin…) * wiki for WG being redesigned * meetings format is being redefined 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

12 years, 11 months

android-toolchain-eabi-4.5-2011.05 fail to compile dalvik

by Barry Song

Dear Jim, After changing TARGET_TOOLS_PREFIX in build/core/combo/TARGET_linux-arm.mk to android-toolchain-eabi-4.5-2011.05, then source build/envsetup.sh. go to dalvik/vm dir by: cd dalvik/vm compile dalvik in this dir: mm -B we will find many compiling error like: "break strict-aliasing rules", "used uninitialized in this function" and so on. all those actually are warnings which become errors due to -Werror option. A patch like the below can make compiling pass, but we feel strange why old toolchain has no this issue. Index: Dvm.mk =================================================================== --- Dvm.mk (revision 4149) +++ Dvm.mk (working copy) @@ -26,7 +26,8 @@ # LOCAL_CFLAGS += -fstrict-aliasing -Wstrict-aliasing=2 -fno-align-jumps #LOCAL_CFLAGS += -DUSE_INDIRECT_REF -LOCAL_CFLAGS += -Wall -Wextra -Wno-unused-parameter +#LOCAL_CFLAGS += -Wall -Wextra -Wno-unused-parameter +LOCAL_CFLAGS += -Wextra -Wno-unused-parameter LOCAL_CFLAGS += -DARCH_VARIANT=\"$(dvm_arch_variant)\" # @@ -264,7 +265,7 @@ ifeq ($(dvm_arch),arm) #dvm_arch_variant := armv7-a #LOCAL_CFLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=vfp - LOCAL_CFLAGS += -Werror +# LOCAL_CFLAGS += -Werror MTERP_ARCH_KNOWN := true # Select architecture-specific sources (armv4t, armv5te etc.) LOCAL_SRC_FILES += \ Any configuration error from us? Thanks Barry

12 years, 11 months

linaro packaged 2.6.39 kernel work in progress

by John Rigby

There is a packaged kernel work in progress here: http://git.linaro.org/gitweb?p=ubuntu/linux-linaro-oneiric.git;a=summary git://git.linaro.org/ubuntu/linux-linaro-oneiric.git It is based on a snapshot of linux-linaro-2.6.39 from today plus sauce and packaging from Ubuntu-2.6.39-3.10. The bad news is that this kernel does not even boot for me. As I chase that down I would like feedback on the new configs. They are dramatically reduced compared to the last cycle. I created the new configs by starting with the upstream defconfigs for each soc and then added only what was necessary to satisfy the Ubuntu config enforce script. This is the perfect time in the release process to start over with minimal configs since we have time deal with missing options. So please look at the configs and let me know what else should be turned on. The packaged kernel has configs split across multiple files. Which is a little confusing. Here is a synopsis: ./debian_linaro/config/config.common.ubuntu is the part that is common across all arch's and flavours (socs). ./debian_linaro/config/armel/config.common.armel has stuff common across all armel flavours but since we only have armel then this file is empty with all the common stuff propagating up to config.common.ubuntu. ./debian/linaro/config/armel/config.flavour.linaro-* contain the soc specific stuff. Any input appreciated. One obvious thing I have noticed is that the soc specific options differ in non-soc specific ways that could be made consistent. For example lots of CONFIG_CRYPTO options are not set in mx51 but m or y in omap. As you see these please give your opinion on if all plats should make an these y, m or n. Thanks, John

12 years, 11 months

abrek -> lava-test

by Paul Larson

As you may have noticed in a recent email thread, the validation team is in the process of making some structural changes to the LAVA project. For finding all the projects for Linaro Validation that we are working on, the easiest option is to go to the main LAVA project group page [1] on Launchpad, which links to each of them. The last project name change should happen today, and that will be the rename of abrek to lava-test. What this means, is that if you currently pull abrek for use in any other test framework, it will need to be fixed to pull lp:lava-test instead. We will make sure this change is reflected in lava-dispatcher so that there are no interruptions in daily tests that are running in the validation farm. However, if you are running your own dispatcher you will want to update your installation with the update, which should land in the next 24 hours once the rename of abrek is complete. Thanks, Paul Larson [1] http://launchpad.net/lava

12 years, 11 months

What do we want our hwpack sources

by Christian Robottom Reis

Hello there, This week I initiated a confused conversation during the techleads call about having a way to describe what the hardware pack was built from. We had a couple of false starts but I think we agreeing that there needs to be some form of manifest that describes what the hardware pack contains. I seem to be hung up on having a way of saying "this hardware pack's kernel was built from this git tree with this config", so I wanted to explore the use cases a bit more: - My #1 use case is, once I've installed a hardware pack, running into a problem and then being able to verify whether it contains a certain patch or was built with a certain config option. I'd like to know that because it's the first thing the KWG and LT people ask me when I go to report the bug. - I think there's also a use case of wanting to know how to get that hwpack rebuilt with slightly updated kernel code or configs. If it's much easier to just document how to build and replace a kernel for a running image, that may cater for most of that use case, the exception being weird bugs caused by our build process and/or toolchain. - I wonder if there's a use case for understanding and/or replacing the other contents of the hardware pack. I normally think of the hardware pack as "a built kernel and not much else" XXX. Zach suggested SPDX (as in spdx.org) as a solution to this problem; I'm not sure I understand enough about it (Loïc's provided a sample file at http://spdx.org/wiki/sample-partial-spdx-file-geronimo) but here's my strawman proposal of what data we should give people quick access to: - What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?) - What kernel config was used to build it (A separate file in the hwpack directory?) How does that sound? Too simplistic? -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko

12 years, 11 months

[PM] 08/06/2011 - Minutes for the Power Management WG weekly call

by Vincent Guittot

Hi All, The minutes of the power management weekly call can be found at : https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-06-08 Summary: * New comer : Robert Lee from Freescale. * Discussion about PM WG's monthly delivery. * Creation of a PM kernel tree with PM WG patches. * Powerdebug code rewrite patchset has been sent . * hwmon for thermal sensor of samsung platform is running Vincent

12 years, 11 months

← Newer
1
...
12
13
14
15
16
17
18
19
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev June 2011