linaro-dev February 2012

linaro-dev@lists.linaro.org

150 participants
147 discussions

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

12 years, 3 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

12 years, 3 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/>

12 years, 3 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(-) >

12 years, 3 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

12 years, 3 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

12 years, 3 months

Screen going black with power saving disabled

by E V

Greetings, I have disabled power saving features in linaro ubuntu 11.10 on a PandaBoard, in order to prevent the screen going black, since there is no mouse nor keyboard attached to the board (It is simply displaying videos, in a closed loop). But when I reboot (Or power up after a time with the board off) sometimes this works, and sometimes not. There seems not to be any kind of rule for it to work, it can fail 5 or 6 times (going black after 10 minutes, even when it is set to "never"), and later work ok for 3 or 4 reboots. And then, fail again. Can anyone enlighten me a bit? Sorry for the joke, but my brain is almost as dark as black the screen goes... thanks in advance,

12 years, 3 months

Salon 3 at 6 AM

by Zach Pfeffer

Our room, Salon 3, opens at 6 AM tomorrow. I'll be there to start setting up. Everyone who needs a place to work is welcome to come. ABS is going to rock! -- 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

12 years, 3 months

i.MX6Q USB host support for mainline Linux (was: Re: [U-Boot] [PATCH v2 1/2] usb/ehci: Add USB support for the MX6Q)

by Dirk Behme

While discussing at the U-Boot mailing list about i.MX6Q USB host support for U-Boot, there was the question what's about the same for mainline Linux. See below. I'd like to continue this discussion with a new subject and adding the Linaro mailing list. On 12.02.2012 09:46, Marek Vasut wrote: >> On 11.02.2012 19:46, Fabio Estevam wrote: >>> On Sat, Feb 11, 2012 at 5:12 AM, Marek Vasut<marek.vasut(a)gmail.com> wrote: >>>> btw Fabio, do we support mx6q USB host in mainline Linux ? >>> >>> Not yet, Marek. >> >> Linaro has it working with >> >> http://git.linaro.org/gitweb?p=bsp/freescale/linux-linaro.git;a=commit;h=de >> 941f9ac0b59c34053618e90e3c1f1d8b5a2d22 >> >> http://git.linaro.org/gitweb?p=bsp/freescale/linux-linaro.git;a=commit;h=40 >> 26cfa27332f2e53cfbf72cc98cf4db8c2f2127 >> >> It shouldn't be that hard to apply these to plain mainline Linux (?). > > Do you believe this will be accepted into mainline Linux if basically the same > stuff, except for mx28 did NOT get accepted? Do you have any pointers to the discussion about this? Hopefully we could learn from that. > The shape of the code was almost > identical, maybe better. Actually, even the file names are the same here and in > the old FSL BSP for mx28. I think the good news is at least that Linaro is working on a more or less recent kernel (atm 3.2). So, as mentioned above, porting it from the Linaro kernel to the mainline kernel shouldn't be that hard. The next step would be to clean them up, hopefully learning from the mx28 experience mentioned above. What do you think? Best regards Dirk

12 years, 3 months

clock_getres() and real resolution

by Dmitry Antipov

IIUC, an idea behind clock_getres() is to give a hint about the resolution of specified clock. This hint may be used by an application programmer to check whether this clock is suitable for a some purpose. So why clock_getres() always returns something like {0, 1} (if hrtimers are enabled) regardless of the underlying platform's real numbers? For example, OMAP4's real resolution of CLOCK_REALTIME is 30.5us for 32K timer and 26ns for MPU timer. Such a difference definitely makes sense - but clock_getres(CLOCK_REALTIME,..) always returns {0, KTIME_HIGH_RES}. Since this behavior causes a confusion like http://lists.linaro.org/pipermail/linaro-dev/2012-February/010112.html, I'm considering this as a stupid misfeature. Dmitry

12 years, 3 months

← Newer
1
...
6
7
8
9
10
11
12
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev February 2012