linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Salon 3, today and tomorrow (16th and 17th)

by Zach Pfeffer

Alexander had the very good idea to ask the Linux Foundation if they would set up a hacking room. They set aside Salon 3 for today and tomorrow. I've brought some (all) of the hardware down if people need to run stuff or want to collaborate. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 11 months

[ANN] Finished migration of Android downloads to snapshots.linaro.org

by Paul Sokolovsky

Hello, We started migrating Android build artifacts as produced by https://android-build.linaro.org/ to http:///snapshots.linaro.org almost 2 months ago and now the migration can be pronounced complete. From now on, http://snapshots.linaro.org/android/ is the master download location for all Android builds, with all builds done in last 2 months available there, important historical builds (*1) migrated there too, and archiving on android-build.linaro.org now turned off. There are several benefits for hosting Android builds directly on snapshots.linaro.org: 1. It is a central place for all Linaro downloads. 2. It allows to manage EULA protection in centralized manner. 3. It allows for consistent structuring and styling. 4. It allows for better space and retention policy management. 5. It alleviates Infrastructure team from maintaining Android downloads on the Jenkins server, allowing us to concentrate on build side of it. Please note that this change is transparent to https://android-build.linaro.org/ - artifacts can still be download from its detailed pages, the links just point to snapshots.linaro.org . All existing artifacts also stay available on android-build.linaro.org, so any previously disseminated links remain valid (*2). *1 Only historical releases were migrated to snapshots.linaro.org, historical daily and developers' built were not due to concerns with current disk space availability on snapshots.linaro.org. But both daily and developers' builds are subject to expiration (lifetime 3 months max), and with 2 months of snapshots.linaro.org archiving, there's only one month's worth of builds left on android-build.linaro.org, which would expire shortly. *2 Subject to expiration policy, per (*1) -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 11 months

Re: Last call for patches for the 12.02 release of linux-linaro kernel

by Andrey Konovalov

Hi Avik, Your fix seems ok for ubuntu/debian, but this would not work in general case. E.g. Fedora doesn't have /usr/bin/pager. So this doesn't look like a generic solution that fits into linux-linaro kernel. Also for a patch I need a one-line title (subject), a short description of the change, and the "Signed-off-by: Name <email>". I.e. all the stuff a git commit header should have. Thanks, Andrey On 02/14/2012 03:33 PM, Avik Sil wrote: > Hi Andrey, > > Can you please consider adding the following patch that supposedly fixes > bug 833101 (https://bugs.launchpad.net/bugs/833101)? > > Regards, > Avik > > diff --git a/tools/perf/util/pager.c b/tools/perf/util/pager.c > index 1915de2..13496dc 100644 > --- a/tools/perf/util/pager.c > +++ b/tools/perf/util/pager.c > @@ -58,7 +58,7 @@ void setup_pager(void) > if (!pager) > pager = getenv("PAGER"); > if (!pager) > - pager = "less"; > + pager = "pager"; > else if (!*pager || !strcmp(pager, "cat")) > return; > > > On Tuesday 14 February 2012 01:52 AM, Andrey Konovalov wrote: >> Greetings, >> >> If someone has something which is not in the mainline, was not in the >> 12.01 kernel release, but worth including into the 12.02 kernel release, >> please let me know by the end of Feb 14, PST (the git branch where I >> could pull from). This release will be v3.3-rc3 based, so you patches >> should be based on that (easiest for me), or on the tip of the linus >> tree. >> >> My expectations are that the power management WG has some topics to add >> to the 12.02. >> >> I am aware of git://git.secretlab.ca/git/linux-2.6.git, irqdomain/next >> >> The kernel working group has some blueprints for 12.02. Please let me >> know, if there is something for me to do here. >> >> The following commits from linux-linaro-3.2 branch will be carried over >> to 12.02: >> commit 2eb6f8b98d8471c83be7e3ab53fe4386884c96a9 >> Author: Vincent Guittot <vincent.guittot(a)linaro.org> >> Date: Fri Oct 21 09:02:47 2011 +0200 >> sched: Ensure cpu_power periodic update >> >> commit 2b21b980917662503a16e079b5d4a5a8a17886cd >> Author: Arnd Bergmann <arnd(a)arndb.de> >> Date: Sat Oct 8 17:07:50 2011 +0200 >> ARM: kprobes: work around build errors >> >> commit 61d24dd4d0528d369ea81f6e5d5e1db9c62ad46a >> Author: Ming Lei <ming.lei(a)canonical.com> >> Date: Wed Aug 31 00:03:13 2011 +0800 >> usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP >> >> Amit (Amit Daniel Kachhap), please let me know if for 12.02 I should use >> the commits below, or take an updated version from you: >> ARM: exynos4: Add thermal sensor driver platform device support >> thermal: exynos4: Register the tmu sensor with the thermal interface >> layer >> thermal: exynos: Add thermal interface support for linux thermal layer >> thermal: Add generic cpu cooling implementation >> thermal: Add a new trip type to use cooling device instance number >> EXYNOS: Make EXYNOS common cpufreq driver >> ARM: exynos: Enable l2 configuration through device tree >> ARM: exynos: remove useless code to save/restore L2 >> ARM: exynos: save L2 settings during bootup >> ARM: s5p: add L2 early resume code >> ARM: exynos: Add support AFTR mode on EXYNOS4210 >> >> >> Thanks, >> Andrey Konovalov >> >> _______________________________________________ >> linaro-dev mailing list >> linaro-dev(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev >

13 years, 11 months

Selecting default framebuffer through kernel command-line ?

by Tushar Behera

Hi, This issue is currently specific to the Ubuntu LEB for Origen and is also being discussed under the LP bug #906762 [1]. Writing to a wider audience to get views of others who might have come across similar situation before. Currently the LCD FB is registered as /dev/fb0 and the HDMI FB is registered as /dev/fb1. While booting up, by default /dev/fb0 is used as the primary display device and the output is routed accordingly. To use the HDMI display, we need to update /etc/X11/xorg.conf (and this needs to be updated every time we update the file-system.) If we don't enable support for LCD FB, the display comes on HDMI during boot-time, but again that is not desirable considering we want to use both the LCD and HDMI with the same kernel binary. Is there any way where we can force the default frame-buffer (whether to choose /dev/fb0 or /dev/fb1) during boot-time, might be through some kernel command-line options? [1] https://bugs.launchpad.net/linaro-landing-team-samsung/+bug/906762 -- Tushar Behera

13 years, 11 months

Agenda posted for the Linaro Android platform meeting

by Zach Pfeffer

Please take a look at: https://wiki.linaro.org/Platform/Android/Meetings/2012-02-15 ...and add anything you think we still need to cover. Please add your status as well. Thanks! -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 11 months

In room 334 at ABS and ELC

by Zach Pfeffer

If you need a place to work and/or want to show someone who's interested in what Linaro is doing, feel free to come to 334. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 11 months

RE: nano-summits over google+ hangouts

by Stephen Doel

Hi Tom et al, We worked out the problem with remote people dialling in to Linaro Connect. Basically a nasty feature/bug in Google Hangouts. The detail is: * If you set up a Hangout from a Linaro G+ account, by default it will look something like: https://talkgadget.google.com/hangouts/extras/linaro.org/linaro-blueroom * Its essential you replace /Linaro.org/ with /talk.google.com/. Then people outside the Linaro domain will go to the same session as you The nasty thing is, even with this domain change, when you (as a Linaro person) go to that hangout, it will provide a link under the Hangout Name of https://talkgadget.google.com/hangouts/extras/linaro.org/linaro-blueroom, but still connect you correctly to https://talkgadget.google.com/hangouts/extras/talk.google.com/linaro-blueroo m. External people get the correct link all the way through Then, as a reminder, external participants can only join with a gmail account (and the Google empire grows...) After that, it is absolutely possible. Further, Google will be deploying Hangouts on Air which will provide a YouTube feed to > 10 participants at some point. When you set the meeting up, you're best off either attaching the hangout link to a meeting invite, or a separate page as they are pretty hard to locate within G+ itself I suggest when you're ready to schedule your first nano-summit, you contact me and I'll help you set it all up. Thx Stephen Message: 1 Date: Mon, 13 Feb 2012 10:07:17 -0600 From: Tom Gall <tom.gall(a)linaro.org> To: Linaro Dev <linaro-dev(a)lists.linaro.org> Subject: nano-summits over google+ hangouts Message-ID: <CAOfXc9EA3X+8rPfBu1WxL5z84jz3QOMKWMGyOkf9V4B+KEX-yA(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hi All, >From what I've heard and saw it seemed like the google+ hangouts in the rooms worked fairly well. (For the very small sample size of the people I've talked to) I'm wondering/tempted to try out as an experiment on going single topic Multimedia sessions from time to time between Linaro Connects. Given that a focused single topic session would draw a smaller "crowd" the 9 person limitation I don't see as a big deal especially with carefully chosen topics. Is this something that is even possible? I know the google+ hangout over the air is by "invite" only so it's important to know if their use might be available for more than just linaro connect. Thanks! -- 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 ------------------------------ Message: 2 Date: Mon, 13 Feb 2012 11:15:10 -0600 From: Kurt Taylor <kurt.taylor(a)linaro.org> To: Tom Gall <tom.gall(a)linaro.org> Cc: Linaro Dev <linaro-dev(a)lists.linaro.org> Subject: Re: nano-summits over google+ hangouts Message-ID: <CAM8qUyVoziwS=+giWZp=Vox0+4p3=HJnBzS7Q9RsMVkxgS5LBg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 13 February 2012 10:07, Tom Gall <tom.gall(a)linaro.org> wrote: > Hi All, > > From what I've heard and saw it seemed like the google+ hangouts in > the rooms worked fairly well. (For the very small sample size of the > people I've talked to) > This was the 3rd remote LC for me and BY FAR the most useful and productive. The hangouts were a tremendous success. My only thought would be to maybe have a "hallway" hangout for impromptu discussions without having to think about it. > > I'm wondering/tempted to try out as an experiment on going single > topic Multimedia sessions from time to time between Linaro Connects. > Given that a focused single topic session would draw a smaller "crowd" > the 9 person limitation I don't see as a big deal especially with > carefully chosen topics. > I think this would be useful, mainly for the improved quality over some of the other methods. I'll have to experiment with whiteboarding and screen sharing, but I think it would work. I'd be willing to put together a multimedia themed micro-summit to give it a try, maybe sometime between the mayor conferences. > > Is this something that is even possible? I know the google+ hangout > over the air is by "invite" only so it's important to know if their > use might be available for more than just linaro connect. > > Thanks! > > -- > 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 > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- Kurt Taylor (irc krtaylor) Linaro Multimedia Linaro.org <http://www.linaro.org/>* **? *Open source software for ARM SoCs Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter<http://twitter.com/#%21/linaroorg>| Blog <http://www.linaro.org/linaro-blog/>

13 years, 11 months

Re: [PATCH 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev->id

by S, Venkatraman

On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak <rnayak(a)ti.com> wrote: > This series mainly cleans up all instances of hardcoding's in > the driver based on pdev->id. This is cleanup leading to the > DT adaptation of omap_hsmmc driver. > > Patches are based on 3.3-rc2 and can be found here > git://gitorious.org/omap-pm/linux.git omap_hsmmc_cleanup > > Tested the patches on my omap4 boards (panda and SDP) but > haven't tested yet on omap3/2 since I did'nt have boards > handy. So any testing on any omap3/2 boards is really > appreciated. I gave it a spin on Beagleboard-XM (OMAP3630) with root filesystem on the SD card, and checked again on 4430SDP. Tested-by: Venkatraman S <svenkatr(a)ti.com> > > regards, > Rajendra > > Balaji T K (3): > mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA > channels > mmc: omap_hsmmc: remove unused .set_sleep function > mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove > host->id based hardcoding > > Rajendra Nayak (3): > mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power function > mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power function > mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply > > arch/arm/plat-omap/include/plat/mmc.h | 2 - > drivers/mmc/host/omap_hsmmc.c | 158 +++------------------------------ > 2 files changed, 14 insertions(+), 146 deletions(-) >

13 years, 11 months

[PATCH][V2] ux500 : decouple/recouple gic from the PRCMU

by Daniel Lezcano

This patch allows to decouple and recouple the gic from the PRCMU. This is needed to put the A9 core in retention mode with the cpuidle driver. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- drivers/mfd/db8500-prcmu.c | 29 +++++++++++++++++++++++++++++ include/linux/mfd/db8500-prcmu.h | 2 ++ include/linux/mfd/dbx500-prcmu.h | 16 ++++++++++++++++ 3 files changed, 47 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c index af8e0ef..70f39a1 100644 --- a/drivers/mfd/db8500-prcmu.c +++ b/drivers/mfd/db8500-prcmu.c @@ -787,6 +787,35 @@ int db8500_prcmu_set_power_state(u8 state, bool keep_ulp_clk, bool keep_ap_pll) return 0; } +#define PRCMU_A9_MASK_REQ 0x00000328 +#define PRCMU_A9_MASK_REQ_MASK 0x00000001 +#define PRCMU_GIC_DELAY 1 + +/* This function decouple the gic from the prcmu */ +void db8500_prcmu_gic_decouple(void) +{ + u32 val = readl(_PRCMU_BASE + PRCMU_A9_MASK_REQ); + + /* Set bit 0 register value to 1 */ + writel((val & ~PRCMU_A9_MASK_REQ_MASK) | PRCMU_A9_MASK_REQ_MASK, + _PRCMU_BASE + PRCMU_A9_MASK_REQ); + + /* Make sure the register is updated */ + readl(_PRCMU_BASE + PRCMU_A9_MASK_REQ); + + /* Wait a few cycles for the gic mask completion */ + udelay(PRCMU_GIC_DELAY); +} + +/* This function recouple the gic with the prcmu */ +void db8500_prcmu_gic_recouple(void) +{ + u32 val = readl(_PRCMU_BASE + PRCMU_A9_MASK_REQ); + + /* Set bit 0 register value to 0 */ + writel((val & ~PRCMU_A9_MASK_REQ_MASK), _PRCMU_BASE + PRCMU_A9_MASK_REQ); +} + /* This function should only be called while mb0_transfer.lock is held. */ static void config_wakeups(void) { diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h index 60d27f7..4a1032c 100644 --- a/include/linux/mfd/db8500-prcmu.h +++ b/include/linux/mfd/db8500-prcmu.h @@ -536,6 +536,8 @@ int prcmu_load_a9wdog(u8 id, u32 val); void db8500_prcmu_system_reset(u16 reset_code); int db8500_prcmu_set_power_state(u8 state, bool keep_ulp_clk, bool keep_ap_pll); +void db8500_prcmu_gic_disable(void); +void db8500_prcmu_gic_enable(void); void db8500_prcmu_enable_wakeups(u32 wakeups); int db8500_prcmu_set_epod(u16 epod_id, u8 epod_state); int db8500_prcmu_request_clock(u8 clock, bool enable); diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h index bac942f..a5fee69 100644 --- a/include/linux/mfd/dbx500-prcmu.h +++ b/include/linux/mfd/dbx500-prcmu.h @@ -237,6 +237,22 @@ static inline int prcmu_set_power_state(u8 state, bool keep_ulp_clk, keep_ap_pll); } +static inline void prcmu_gic_disable(void) +{ + if (machine_is_u5500()) + return; + else + return db8500_prcmu_gic_disable(); +} + +static inline void prcmu_gic_enable(void) +{ + if (machine_is_u5500()) + return; + else + return db8500_prcmu_gic_enable(); +} + static inline int prcmu_set_epod(u16 epod_id, u8 epod_state) { if (machine_is_u5500()) -- 1.7.5.4

13 years, 11 months

nano-summits over google+ hangouts

by Tom Gall

Hi All, >From what I've heard and saw it seemed like the google+ hangouts in the rooms worked fairly well. (For the very small sample size of the people I've talked to) I'm wondering/tempted to try out as an experiment on going single topic Multimedia sessions from time to time between Linaro Connects. Given that a focused single topic session would draw a smaller "crowd" the 9 person limitation I don't see as a big deal especially with carefully chosen topics. Is this something that is even possible? I know the google+ hangout over the air is by "invite" only so it's important to know if their use might be available for more than just linaro connect. Thanks! -- 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

13 years, 11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev