Re: [ANN] Disk upgrade on ci.linaro.org today
Hello John, On Wed, 9 May 2012 09:29:01 -0600 John Rigby john.ri...@linaro.org wrote: Paul, Not sure if it has anything to do with the upgrade but I am not able to create new jobs, I tried with and without the copy existing option. https://pastebin.linaro.org/529/ Yes, apparently it is related, thanks for the report, it's fixed now (verified work). Please let me know if there're any other abnormalities. --john On Wed, May 9, 2012 at 8:44 AM, Paul Sokolovsky paul.sokolov...@linaro.org wrote: On Wed, 9 May 2012 12:53:15 +0300 Paul Sokolovsky paul.sokolov...@linaro.org wrote: Hello, The Infrastructure team works on improving disk layout on Jenkins build systems to avoid common cases of errors which lead to unexpected downtime. We recently migrated android-build.linaro.org to new partition setup, and would like to proceed with ci.linaro.org. This is potentially multi-step process, so we want to start it ASAP to not risk it protruding into release rush time. So, we'd like to schedule a downtime at 14:00 UTC today, expected duration is 1 hr. Please let me know if you have any issues with that time. Upgrade is complete, everything was performed in one stage. Please let Infra team know if you face any issues. -- 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/2] ARM: DAVINCI: cpuidle - cleanups
These couple of patches use the new cpuidle core api to refactor some part of the code. The first one removes the state count initialization as it is done from the cpuidle core and the second one use the new API and removes the ops. The patchset is based on Lenb's tree on top of Robert Lee cpuidle consolidation work. I don't have this board, I was not able to test these patches. Daniel Lezcano (2): ARM: DAVINCI: cpuidle - remove useless state count initialization ARM: DAVINCI: cpuidle - remove ops arch/arm/mach-davinci/cpuidle.c | 83 +-- 1 files changed, 27 insertions(+), 56 deletions(-) -- 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] ARM: DAVINCI: cpuidle - remove useless state count initialization
The state count is initialized in the driver structure, the cpuidle
core uses it to initialize the device state count.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-davinci/cpuidle.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 9107691..f0f179c 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -128,8 +128,6 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
cpuidle_set_statedata(device-states_usage[1], davinci_states[1]);
- device-state_count = DAVINCI_CPUIDLE_MAX_STATES;
-
ret = cpuidle_register_driver(davinci_idle_driver);
if (ret) {
dev_err(pdev-dev, failed to register driver\n);
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] ARM: DAVINCI: cpuidle - remove ops
This patch removes the ops usage because we have the index
passed as parameter to the idle function and we can determine
if we do WFI or memory retention.
The benefit of this cleanup is the removal of:
* the ops
* the statedata usage because we want to get rid of it in all the drivers
* extra structure definition
* extra functions definition
* pointless macro definition BIT(0)
It also benefits the readability.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-davinci/cpuidle.c | 81 +--
1 files changed, 27 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index f0f179c..61f4e52 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -25,35 +25,46 @@
#define DAVINCI_CPUIDLE_MAX_STATES 2
-struct davinci_ops {
- void (*enter) (u32 flags);
- void (*exit) (u32 flags);
- u32 flags;
-};
+static bool ddr2_pwdn = false;
+
+static void __iomem *ddr2_reg_base;
+
+static void davinci_save_ddr_power(int enter, bool pdown)
+{
+ u32 val;
+
+ val = __raw_readl(ddr2_reg_base + DDR2_SDRCR_OFFSET);
+
+ if (enter) {
+ if (pdown)
+ val |= DDR2_SRPD_BIT;
+ else
+ val = ~DDR2_SRPD_BIT;
+ val |= DDR2_LPMODEN_BIT;
+ } else {
+ val = ~(DDR2_SRPD_BIT | DDR2_LPMODEN_BIT);
+ }
+
+ __raw_writel(val, ddr2_reg_base + DDR2_SDRCR_OFFSET);
+}
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct cpuidle_state_usage *state_usage = dev-states_usage[index];
- struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
-
- if (ops ops-enter)
- ops-enter(ops-flags);
+ if (index)
+ davinci_save_ddr_power(1, ddr2_pwdn);
index = cpuidle_wrap_enter(dev, drv, index,
arm_cpuidle_simple_enter);
- if (ops ops-exit)
- ops-exit(ops-flags);
+ if (index)
+ davinci_save_ddr_power(0, ddr2_pwdn);
return index;
}
-/* fields in davinci_ops.flags */
-#define DAVINCI_CPUIDLE_FLAGS_DDR2_PWDNBIT(0)
-
static struct cpuidle_driver davinci_idle_driver = {
.name = cpuidle-davinci,
.owner = THIS_MODULE,
@@ -71,43 +82,6 @@ static struct cpuidle_driver davinci_idle_driver = {
};
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
-static void __iomem *ddr2_reg_base;
-
-static void davinci_save_ddr_power(int enter, bool pdown)
-{
- u32 val;
-
- val = __raw_readl(ddr2_reg_base + DDR2_SDRCR_OFFSET);
-
- if (enter) {
- if (pdown)
- val |= DDR2_SRPD_BIT;
- else
- val = ~DDR2_SRPD_BIT;
- val |= DDR2_LPMODEN_BIT;
- } else {
- val = ~(DDR2_SRPD_BIT | DDR2_LPMODEN_BIT);
- }
-
- __raw_writel(val, ddr2_reg_base + DDR2_SDRCR_OFFSET);
-}
-
-static void davinci_c2state_enter(u32 flags)
-{
- davinci_save_ddr_power(1, !!(flags DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN));
-}
-
-static void davinci_c2state_exit(u32 flags)
-{
- davinci_save_ddr_power(0, !!(flags DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN));
-}
-
-static struct davinci_ops davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
- [1] = {
- .enter = davinci_c2state_enter,
- .exit = davinci_c2state_exit,
- },
-};
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
{
@@ -125,8 +99,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
ddr2_reg_base = pdata-ddr2_ctlr_base;
if (pdata-ddr2_pdown)
- davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
- cpuidle_set_statedata(device-states_usage[1], davinci_states[1]);
+ ddr2_pwdn = true;
ret = cpuidle_register_driver(davinci_idle_driver);
if (ret) {
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: new IRC channel: linaro-lava
On Wed, May 9, 2012 at 7:36 AM, Andy Doan andy.d...@linaro.org wrote: We have a new channel on FreeNode for LAVA specific discussions: #linaro-lava This channel allows participants who are working with Linaro to join and just follow progress on LAVA. We should be using the same guidelines for deciding whether something belongs on #linaro or not as channels like #linaro-android currently do. Do we really need another extra channel? I believe the current list is already too much, and the lava folks are the ones that are the most active at #linaro currently (which is good :-). Seems that now we have the following IRC channels (could be even more): - #linaro - #linaro-lava - #linaro-android - #linaro-armhf - #linaro-kernel - #linaro-big.little - #linaro-multimedia Which is a bit too much, at least for me. -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: imx: Modify IMX_IO_P2V macro
Hello Robert, On Wed, May 09, 2012 at 07:24:17PM -0500, Robert Lee wrote: A change is needed in the IMX_IO_P2V macro to allow all imx5 platforms to use common definitions when accessing registers of peripherals on the AIPS2 bus. This change was tested for mapping conflicts using the iop2v script found at git://git.pengutronix.de/git/ukl/imx-iop2v.git and by performing a bootup of a default build using imx_v6_v7_defconfig on a imx51 babbage board and imx53 loco board. Signed-off-by: Robert Lee rob@linaro.org It took me some time to understand your goal. With your change you achieve that IMX_IO_P2V(MX50_AIPS2_BASE_ADDR) == IMX_IO_P2V(MX51_AIPS2_BASE_ADDR) == IMX_IO_P2V(MX53_AIPS2_BASE_ADDR) (which IMHO is more than allowing ... to use common definitions [for the] AIPS2 bus). I can confirm that my imx-iop2v script doesn't find a conflict with your change. Having said that I didn't check that the memory regions listed in the script still match the regions that are statically mapped on imx. And I wonder why do you need to have the aips2 bus mapped to the same address on all imx5 machines. The future is that the base addresses of the various devices are determined via dt and then the static mappings go away. Do I miss something? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: new IRC channel: linaro-lava
On 05/10/2012 03:57 AM, Ricardo Salveti wrote: On Wed, May 9, 2012 at 7:36 AM, Andy Doanandy.d...@linaro.org wrote: We have a new channel on FreeNode for LAVA specific discussions: #linaro-lava snip Do we really need another extra channel? I believe the current list is already too much, and the lava folks are the ones that are the most active at #linaro currently (which is good :-). Seems that now we have the following IRC channels (could be even more): - #linaro - #linaro-lava - #linaro-android - #linaro-armhf - #linaro-kernel - #linaro-big.little - #linaro-multimedia Which is a bit too much, at least for me. I know everyone thinks they're special, but in the case of #linaro-lava, I do think there's some value. We have some people who are interested in LAVA but not so much Linaro. So the signal-to-noise ratio on #linaro is a bit high. In my old role I would have complained about adding another channel. However, I've enjoyed the split the past 2 days. That said, I think the users of #linaro-lava need to be proactive about moving conversations to #linaro when appropriate. -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
android-build's are failing, we're on it...
-- 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: new IRC channel: linaro-lava
We need an irc aggregator to flatten all the channels to one on rx and broadcast on tx for those of use who want to live in a flat world (only half kidding:) On Thu, May 10, 2012 at 10:09 AM, Andy Doan andy.d...@linaro.org wrote: On 05/10/2012 03:57 AM, Ricardo Salveti wrote: On Wed, May 9, 2012 at 7:36 AM, Andy Doanandy.d...@linaro.org wrote: We have a new channel on FreeNode for LAVA specific discussions: #linaro-lava snip Do we really need another extra channel? I believe the current list is already too much, and the lava folks are the ones that are the most active at #linaro currently (which is good :-). Seems that now we have the following IRC channels (could be even more): - #linaro - #linaro-lava - #linaro-android - #linaro-armhf - #linaro-kernel - #linaro-big.little - #linaro-multimedia Which is a bit too much, at least for me. I know everyone thinks they're special, but in the case of #linaro-lava, I do think there's some value. We have some people who are interested in LAVA but not so much Linaro. So the signal-to-noise ratio on #linaro is a bit high. In my old role I would have complained about adding another channel. However, I've enjoyed the split the past 2 days. That said, I think the users of #linaro-lava need to be proactive about moving conversations to #linaro when appropriate. -andy __**_ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/**mailman/listinfo/linaro-devhttp://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
12.05 linux-linaro kernel tree
Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-build's are failing, we're on it...
Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. If you really need to send it to linaro-dev, would you mind at least giving more information and writing the email properly to avoid just using the subject? Thanks. -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-build's are failing, we're on it...
On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. Is Twitter really that much better to inform us it's broken? I would have missed the news entirely, for one random data point. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-build's are failing, we're on it...
On 10 May 2012 15:20, Christian Robottom Reis k...@linaro.org wrote: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. Thanks Kiko. Yes, we sorted the issue out and we're back up. The builds are currently in flight. Is Twitter really that much better to inform us it's broken? I would have missed the news entirely, for one random data point. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs -- 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
pointless mail, (was Re: android-build's are failing...)
+++ Christian Robottom Reis [2012-05-10 17:20 -0300]: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. I don't like subject-only content-free mails either, but this one wasn't entirely useless so I guess it's fair enough. But as Ricardo's started an email-moan thread I'll just get something off my chest that's been bugging me for a while. Everytime we get a new person arriving a load of people send pointless mails to us _all_ saying 'hi there'. Those mails are great to send to the actual newbie, but not to everyone, _please_. Call me a miserable bastard, but really, we all get more than enough mail (especially from bloody launchpad :-), please try not to send this sort of spam to all - just people who will finds it useful. Ah, that's better... Wookey (who has lost his sig) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Installing the armel libc on armhf
On 11 May 2012 02:50, Christian Robottom Reis k...@linaro.org wrote:
On Mon, May 07, 2012 at 11:51:47AM -0700, Marcin Juszkiewicz wrote:
W dniu 06.05.2012 16:06, Michael Hope pisze:
Hi there. Hopefully an easy question but I'm stumped. How do I
install the armel softfp libc6 on a new Precise armhf install?
I set APT::Architectures to { armel } and then tried a apt-get
install libc6:armel but I get errors about the package not matching
the host architecture.
echo 'foreign-architecture armel' /etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main
universe' /etc/apt/sources.list.d/armel.list
apt-get update
apt-get install libc6:armel
not tested, should work
Where should this be documented so others can find it when they are
trying to do the same as Michael?
It's not official, but I have a page on patching a multiarch system so
you can build GCC:
https://wiki.linaro.org/MichaelHope/Sandbox/MultiarchWorkarounds
and it now has a note on installing other libcs. Matthias is working
on upstreaming the multiarch patch which will eliminate the first
three, and my hard float loader patch fixes the fourth.
-- Michael
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote: Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. I may have misunderstood but Doesn't this mean on next Wednesday you be tracking Wednesdays tip, then on Thursdays move back in time to this Sundays rc7 release? Or do you mean you are going to create a linux-linaro tree soon from whatever is tip, then leave it unchanged til Thursday when you'll redo it against rc7? -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-build's are failing, we're on it...
On Thu, May 10, 2012 at 1:20 PM, Christian Robottom Reis k...@linaro.org wrote: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. Well, just saying it's broken doesn't help much either. If you really want a better and more up-to-date place to show this info even IRC would be better. Is Twitter really that much better to inform us it's broken? I would have missed the news entirely, for one random data point. Better than email at least :-) While it it's useful, did it actually help you in any front? Twitter is the general place used by most of projects for status update, that's why I thought that it'd be the best way to go. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: pointless mail, (was Re: android-build's are failing...)
On Thu, May 10, 2012 at 1:37 PM, Wookey woo...@wookware.org wrote: +++ Christian Robottom Reis [2012-05-10 17:20 -0300]: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. I don't like subject-only content-free mails either, but this one wasn't entirely useless so I guess it's fair enough. Sure, I just think there are better places for it :-) Based on issues we had with LAVA and Jenkins at the previous cycle, if I had one email for every issue, I'd send at least 20 of them, which is useful but that still doesn't make me send them to the list. But as Ricardo's started an email-moan thread I'll just get something off my chest that's been bugging me for a while. Everytime we get a new person arriving a load of people send pointless mails to us _all_ saying 'hi there'. Those mails are great to send to the actual newbie, but not to everyone, _please_. Call me a miserable bastard, but really, we all get more than enough mail (especially from bloody launchpad :-), please try not to send this sort of spam to all - just people who will finds it useful. Ah, that's better... ++1 :-) Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-build's are failing, we're on it...
On Fri, May 11, 2012 at 12:21 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Thu, May 10, 2012 at 1:20 PM, Christian Robottom Reis k...@linaro.org wrote: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. Well, just saying it's broken doesn't help much either. If you really want a better and more up-to-date place to show this info even IRC would be better. Is Twitter really that much better to inform us it's broken? I would have missed the news entirely, for one random data point. Better than email at least :-) While it it's useful, did it actually help you in any front? Twitter is the general place used by most of projects for status update, that's why I thought that it'd be the best way to go. I would have preferred to get a bit more context as well, but as kiko said, getting an notification is definitely better than nothing. Especially if you are in the mids of a firedrill you might not have the time to explain the context, nor might you understand whats going on at all etc. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: pointless mail, (was Re: android-build's are failing...)
On Fri, May 11, 2012 at 12:24 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Thu, May 10, 2012 at 1:37 PM, Wookey woo...@wookware.org wrote: +++ Christian Robottom Reis [2012-05-10 17:20 -0300]: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. I don't like subject-only content-free mails either, but this one wasn't entirely useless so I guess it's fair enough. Sure, I just think there are better places for it :-) Based on issues we had with LAVA and Jenkins at the previous cycle, if I had one email for every issue, I'd send at least 20 of them, which is useful but that still doesn't make me send them to the list.] Actually, I think LAVA outage was announced. I poked for getting more status updates, so more mails would have been great. Same goes for ci.linaro.org ... if our CI service used for everything but android is not available, I want to get a mail that this is the case. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: pointless mail, (was Re: android-build's are failing...)
On Thu, May 10, 2012 at 3:30 PM, Alexander Sack a...@linaro.org wrote: On Fri, May 11, 2012 at 12:24 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Thu, May 10, 2012 at 1:37 PM, Wookey woo...@wookware.org wrote: +++ Christian Robottom Reis [2012-05-10 17:20 -0300]: On Thu, May 10, 2012 at 12:55:26PM -0700, Ricardo Salveti wrote: Sorry to say that, but I hate these kind of emails at Linaro Dev, as I believe we have other places (and better ones) to report such issues. Twitter would probably be the way to go. Well, to be honest I don't really see the problem with letting the list know that there are issues, and I interpret Zach's brevity as we're totally focused on getting the problem solved. I expect he's going to come back and explain what's broken when the issue is resolved. I don't like subject-only content-free mails either, but this one wasn't entirely useless so I guess it's fair enough. Sure, I just think there are better places for it :-) Based on issues we had with LAVA and Jenkins at the previous cycle, if I had one email for every issue, I'd send at least 20 of them, which is useful but that still doesn't make me send them to the list.] Actually, I think LAVA outage was announced. I poked for getting more status updates, so more mails would have been great. Same goes for ci.linaro.org ... if our CI service used for everything but android is not available, I want to get a mail that this is the case. Sure, but then I believe it'd be better to have another mailing list for such purposes. Linaro-dev is used for development related discussion, and it's the first most folks first subscribe to. I don't have the current number of folks participating at this list, but I'd prefer to still keep it dev-focused, and avoid off-topic discussions to try to keep it sane. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On Fri, May 11, 2012 at 12:09 AM, Jon Medhurst (Tixy) t...@linaro.org wrote: On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote: Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. I may have misunderstood but Doesn't this mean on next Wednesday you be tracking Wednesdays tip, then on Thursdays move back in time to this Sundays rc7 release? Yeah, I wondered about the same. In general I am very suspicious if we say we would have to go back and feel we might duplicate work in a direction where we shouldn't invest... How bad is the tip revision you aim for Andrey? Maybe we can check how well that works and if there are problems collaboratively try to fix that with the goal to release from tip? e.g. with help from ARM and Samsung LT? Is that a bad idea? -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Incident Management (was: Re: pointless mail, (was Re: android-build's are failing...))
On Fri, 11 May 2012 12:11:36 +1200, Michael Hudson-Doyle michael.hud...@canonical.com wrote: On Fri, 11 May 2012 00:30:26 +0200, Alexander Sack a...@linaro.org wrote: On Fri, May 11, 2012 at 12:24 AM, Ricardo Salveti Sure, I just think there are better places for it :-) Based on issues we had with LAVA and Jenkins at the previous cycle, if I had one email for every issue, I'd send at least 20 of them, which is useful but that still doesn't make me send them to the list.] Actually, I think LAVA outage was announced. I poked for getting more status updates, so more mails would have been great. Same goes for ci.linaro.org ... if our CI service used for everything but android is not available, I want to get a mail that this is the case. So, what this discussion points to is: we need a process for handling disruptions to the services we provide. When the hits the fan, the last think you want people to be doing is _thinking_, or at least, thinking about things that could have been thought through ahead of time and are not totally specific to the incident at hand. Just recently within the LAVA team, we've started following such a process: https://wiki.linaro.org/Internal/LAVA/Incidents (apologies to the non-Linaro insiders for the internal link). The process will look very familiar to anyone who works at Canonical... Creating a wiki page for each incident can feel a bit heavyweight, It turns out that moin has a funky NewPage macro (https://wiki.linaro.org/HelpOnMacros#Others) that one can use to make this really easy. So we've scrapped the Google document. Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 11/05/12 10:19, Somebody in the thread at some point said: On Fri, May 11, 2012 at 3:43 AM, Andy Greenandy.gr...@linaro.org wrote: On 11/05/12 08:27, Somebody in the thread at some point said: 4. in between RCs, we only move mainline on our linux-linaro release baseline forward if we see a working tracking build that wouldn't drop any topics that already made it into this RC cycle. The probability of getting a good unified tree follows the kernel cycle, we all have good reasons to have tried to arrive at a good, working, release. Sometimes we only get a reasonably good result a week or two after Linus' release. For that reason maybe you should just be trying to 'release' a release-basis unified tree, ie, the 3.4 one targeted now as the deliverable. It still has meaning to make a monthly release of that since it can collect stable mainline updates and updates from each LT release tree that happened in the meanwhile. We do need to create these intermediate unified trees so we know what to fix on our trees so they can go in smoothly, but it matters less then if one day half the LT trees are missing on it since it's of interest only for LTs and platform guys to study what else needs solving on the LT trees. I still think you won't get anywhere useful until we are trying to build the unified trees for real. Then we can start the needed work to make them fit together properly, until then we're treading water in technical debt. Discussing how to run the tree is something to do later after gaining this experience. I had a look at the LT gits ARMMerge-managed integration-linux-vexpress 3.4-rc4 TI Rebase-managed tilt-tracking 3.4-rc4 Freescale Merge-managed lt-3.4 3.4-rc3 SamsungRebase-managed tracking 3.4-rc3 STEMerge-managed integration-linux-ux5003.4-rc6 (wow STE - on igloocommunity.org - have a LOT of patches! I thought we were leading the way) Actually locally TILT are on -rc6 but there was almost no conflict coming between -rc4 and -rc6. If you take the approach to merge these trees, I found that late in the cycle it's usually pretty forgiving about some variation in basis. So why not give these all a test merge today and see what starts falling out? I am sure we all have something to fix and there may be larger issues I will check with Andrey/Ricardo if we can do that :) ... would it be exciting enough if we just try adding TI to the mix this month (and not all?)? In any case, you should definitely send Andrey a list of topic branches you want to register for linux-linaro and things will get picked up as soon as Andrey can I guess :). Sure, actually merging trees and dealing with the fallout, even if it's just one more tree if that's all you can handle, will get us moving further forward than just talking about it. AIUI this topic thing is not blocking you, you can just merge tilt-tracking as a single topic for now and discover the pain points. All I am planning to provide ultimately is an in-tree text file mapping topic names to head hashes, as I produced for Andrey before, not register topics anywhere. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: imx: Modify IMX_IO_P2V macro
Hello Uwe and Sascha, On Wed, May 9, 2012 at 7:24 PM, Robert Lee rob@linaro.org wrote: A change is needed in the IMX_IO_P2V macro to allow all imx5 platforms to use common definitions when accessing registers of peripherals on the AIPS2 bus. This change was tested for mapping conflicts using the iop2v script found at git://git.pengutronix.de/git/ukl/imx-iop2v.git and by performing a bootup of a default build using imx_v6_v7_defconfig on a imx51 babbage board and imx53 loco board. Signed-off-by: Robert Lee rob@linaro.org --- arch/arm/plat-mxc/include/mach/hardware.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/plat-mxc/include/mach/hardware.h b/arch/arm/plat-mxc/include/mach/hardware.h index 0630513..065cc04 100644 --- a/arch/arm/plat-mxc/include/mach/hardware.h +++ b/arch/arm/plat-mxc/include/mach/hardware.h @@ -96,6 +96,7 @@ */ #define IMX_IO_P2V(x) ( \ 0xf400 + \ + (((x) 0x8000) 7) + \ I doubled checked this today and this will result in some of the platform addresses being in the 0xf600 boundary. Instead, the '+' can be made an '|' and the addresses that get generated all appear to be acceptable without any conflicts. I'll re-submit this patch with the above fix and commet changes as part of a imx5 idle cleanup series unless I'm told that a change to this macro is unacceptable. Thanks, Rob (((x) 0x5000) 6) + \ (((x) 0x0b00) 4) + \ (((x) 0x000f))) -- 1.7.10 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 05/11/2012 01:04 AM, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 11/05/12 13:04, Somebody in the thread at some point said: On 05/11/2012 01:04 AM, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking. We'll be using it again shortly, CMA is in linux-linaro-core-tracking already though, I believe the same version #24. http://git.linaro.org/gitweb?p=kernel%2Flinux-linaro-tracking.gita=searchh=refs%2Fheads%2Flinux-linaro-core-trackingst=commits=CMA -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
