[PATCH 0/2] ARM: DAVINCI: cpuidle - cleanups

[Daniel Lezcano]

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

[Daniel Lezcano]

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 
---
 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

[Daniel Lezcano]

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 
---
 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

[Ricardo Salveti]

On Wed, May 9, 2012 at 7:36 AM, Andy Doan  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

[Uwe Kleine-König]

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 
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

[PATCH] ARM: OMAP3/4: consolidate cpuidle Makefile

[Daniel Lezcano]

The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files
even if the cpuidle option is not set in the kernel.

This patch fixes this by creating a section in the Makefile where these
files are compiled only if the CONFIG_CPU_IDLE option is set.

This modification breaks an implicit dependency between CPU_IDLE and PM as
they belong to the same block in the Makefile. This is fixed in the Kconfig
by selecting explicitely PM is CPU_IDLE is set.

The linux coding style recommend to use no-op functions in the headers
when the subsystem is disabled instead of adding big section in C files.

This patch fix this also.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Jean Pihet 
---
 arch/arm/mach-omap2/Kconfig   |2 ++
 arch/arm/mach-omap2/Makefile  |   11 +++
 arch/arm/mach-omap2/cpuidle34xx.c |8 
 arch/arm/mach-omap2/cpuidle44xx.c |8 
 arch/arm/mach-omap2/pm.h  |   17 +++--
 5 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8141b76..42f6b89 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -34,6 +34,7 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARCH_HAS_OPP
+   select PM if CPU_IDLE
select PM_OPP if PM
select ARM_CPU_SUSPEND if PM
select MULTI_IRQ_HANDLER
@@ -51,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+   select PM if CPU_IDLE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..f46c735 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,10 +64,8 @@ endif
 ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_ARCH_OMAP2)   += pm24xx.o
 obj-$(CONFIG_ARCH_OMAP2)   += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o \
-  cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4)   += pm44xx.o omap-mpuss-lowpower.o \
-  cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o
+obj-$(CONFIG_ARCH_OMAP4)   += pm44xx.o omap-mpuss-lowpower.o
 obj-$(CONFIG_PM_DEBUG) += pm-debug.o
 obj-$(CONFIG_OMAP_SMARTREFLEX)  += sr_device.o smartreflex.o
 obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)  += smartreflex-class3.o
@@ -81,6 +79,11 @@ endif
 
 endif
 
+ifeq ($(CONFIG_CPU_IDLE),y)
+obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
+endif
+
 # PRCM
 obj-y  += prm_common.o
 obj-$(CONFIG_ARCH_OMAP2)   += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 207bc1c..3134452 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,8 +36,6 @@
 #include "control.h"
 #include "common.h"
 
-#ifdef CONFIG_CPU_IDLE
-
 /* Mach specific information to be recorded in the C-state driver_data */
 struct omap3_idle_statedata {
u32 mpu_state;
@@ -379,9 +377,3 @@ int __init omap3_idle_init(void)
 
return 0;
 }
-#else
-int __init omap3_idle_init(void)
-{
-   return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index be1617c..02d15bb 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,8 +22,6 @@
 #include "pm.h"
 #include "prm.h"
 
-#ifdef CONFIG_CPU_IDLE
-
 /* Machine specific information */
 struct omap4_idle_statedata {
u32 cpu_state;
@@ -199,9 +197,3 @@ int __init omap4_idle_init(void)
 
return 0;
 }
-#else
-int __init omap4_idle_init(void)
-{
-   return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..ab04d3b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -15,12 +15,25 @@
 
 #include "powerdomain.h"
 
+#ifdef CONFIG_CPU_IDLE
+extern int __init omap3_idle_init(void);
+extern int __init omap4_idle_init(void);
+#else
+static inline int omap3_idle_init(void)
+{
+   return 0;
+}
+
+static inline int omap4_idle_init(void)
+{
+   return 0;
+}
+#endif
+
 extern void *omap3_secure_ram_storage;
 extern void omap3_pm_off_mode_enable(int);
 extern void omap_sram_idle(void);
 extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
-extern int omap3_idle_init(void);
-extern int omap4_idle_init(void);
 extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
 extern int (*omap_pm_suspend)(void);
 
-- 
1.7.5.4


___
linaro-dev mailing lis

Re: Making ARM multiplatform kernels DT-only?

[Russell King - ARM Linux]

On Thu, May 10, 2012 at 11:55:15AM +0100, Ben Dooks wrote:
> On Thu, May 03, 2012 at 03:18:53PM +0100, Russell King - ARM Linux wrote:
> > I think what you're proposing is a totally artificial restriction.
> > There's no problem with a kernel supporting DT and non-DT together.
> > We've proven that many many times.  I prove it _every_ night that my
> > build and boot system runs - the OMAP LDP boots a multiplatform kernel
> > just fine without DT.
> 
> We could have had the same for Samsung's entire range if a bit of work
> had been applied to do things like PAGE_OFFSET and replaceable IRQ
> controllers.

We never did dynamic PAGE_OFFSET because we _had_ taken the decision with
the inclusion of XIP support that we weren't going to have self-modifying
code in the kernel - and loading the offset for every page table walk
would have been very expensive.

The self-modifying code viewpoint seems to have changed as a result of
Nicolas moving jobs, from an employer who wanted XIP to one who wants a
single kernel image, which in itself isn't surprising.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Making ARM multiplatform kernels DT-only?

[Ben Dooks]

On Thu, May 03, 2012 at 03:18:53PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 03, 2012 at 01:50:35PM +, Arnd Bergmann wrote:
> > My feeling is that we should just mandate DT booting for multiplatform
> > kernels, because it significantly reduces the combinatorial space
> > at compile time, avoids a lot of legacy board files that we cannot
> > test anyway, reduces the total kernel size and gives an incentive
> > for people to move forward to DT with their existing boards.
> 
> On this point, I strongly object, especially as I'm one who uses the
> existing non-DT multiplatform support extensively.  It's really not
> a problem for what you're trying to achieve.

I object firstly on principle that you don't need the DT support to
allow this, it could have been done years ago if anyone had taken the
time to do it.
 
> I think what you're proposing is a totally artificial restriction.
> There's no problem with a kernel supporting DT and non-DT together.
> We've proven that many many times.  I prove it _every_ night that my
> build and boot system runs - the OMAP LDP boots a multiplatform kernel
> just fine without DT.

We could have had the same for Samsung's entire range if a bit of work
had been applied to do things like PAGE_OFFSET and replaceable IRQ
controllers.

> In any case, this is the least of the worries when you're wanting to
> build multiple SoCs into the same kernel image.  See my previous reply
> concerning that.

-- 
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v3 2/3] ARM: imx: Add imx5 cpuidle driver

[Sascha Hauer]

On Wed, May 09, 2012 at 09:27:02AM -0500, Rob Lee wrote:
> Sascha,
> 
> >
> > This clk_get should go away here and be moved somewhere to
> > initialization. Also, if getting this clock fails we can still
> > do regular cpu_do_idle. Additionally, if clk_get fails, we'll
> > have a ERR_PTR value in gpc_dvfs_clk in which case the
> > gpc_dvfs_clk == NULL won't trigger next time you are here and
> > then you'll enable a nonexisting clock below.
> >
> 
> Agree.  I'd prefer to enable this clock during intialization and just
> leave it running.  It is supposed to be a very low power clock and I
> couldn't measuring any power difference with and without it being
> enabled

Ok, even better.

> >
> > I wonder why you don't add the default ARM_CPUIDLE_WFI_STATE_PWR state.
> > The above is something different, right? It has a greater exit latency
> > than ARM_CPUIDLE_WFI_STATE_PWR, so why don't we add it here aswell?
> 
> Yes and no.  Yes this is a different state but no, it doesn't have a
> significantly greater exit latency, or at least a large enough exit
> latency to warrant an extra state in my opinion.  According to the
> i.MX5 documentation, the extra exit time beyond basic WFI required for
> the  "WAIT_UNCLOCKED_POWER_OFF" state is 500ns (this is due to a
> difference in i.MX5 hardware implementation compared to all other ARM
> platforms).  In reality, it did require a few more microseconds to
> perform in my testing just based on the extra register writes in
> mx5_cpu_lp_set().  I'd like to clean up mx5_cpu_lp_set() and add a
> global variable to track the previous state and to just exit out if
> the new state is the same as the old.

Do you think it's worth it? You buy skipping the read with an additional
test.

> I could do this cleanup as part of this patchset if you prefer that.

Yes please. Cleanups before adding new features is always a good reason
to apply a patch series ;)

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
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

[Rob Lee]

Hello Uwe,

On Thu, May 10, 2012 at 1:56 AM, Uwe Kleine-König
 wrote:
> 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 
> 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).

Sorry, I just have been more thorough in my description.  In the patch
I also forgot to change the comments and give the new virtual
addresses so I can add that in a v2 if this change ends up being
acceptable.

>
> 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?

For now, because both dt and non dt configurations are available for
imx5, this is needed so that the low power mx5_cpu_lp_set() function
in pm-imx5.c can be readily used by imx53 and imx50 for low power
idling.

If this is not acceptable, another option would be to only support
idle for dt builds that have common base addresses.  This may require
a temporary hack for cpuidle enablement to enable it for dt but not
for non-dt since they currently use some common init code.  Or, just
don't support low power idling at all on imx53 and imx50 until the
non-dt support is removed.

>
> 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: [PATCH v3 2/3] ARM: imx: Add imx5 cpuidle driver

[Rob Lee]

On Thu, May 10, 2012 at 7:41 AM, Sascha Hauer  wrote:
> On Wed, May 09, 2012 at 09:27:02AM -0500, Rob Lee wrote:
>> Sascha,
>>
>> >
>> > This clk_get should go away here and be moved somewhere to
>> > initialization. Also, if getting this clock fails we can still
>> > do regular cpu_do_idle. Additionally, if clk_get fails, we'll
>> > have a ERR_PTR value in gpc_dvfs_clk in which case the
>> > gpc_dvfs_clk == NULL won't trigger next time you are here and
>> > then you'll enable a nonexisting clock below.
>> >
>>
>> Agree.  I'd prefer to enable this clock during intialization and just
>> leave it running.  It is supposed to be a very low power clock and I
>> couldn't measuring any power difference with and without it being
>> enabled
>
> Ok, even better.
>
>> >
>> > I wonder why you don't add the default ARM_CPUIDLE_WFI_STATE_PWR state.
>> > The above is something different, right? It has a greater exit latency
>> > than ARM_CPUIDLE_WFI_STATE_PWR, so why don't we add it here aswell?
>>
>> Yes and no.  Yes this is a different state but no, it doesn't have a
>> significantly greater exit latency, or at least a large enough exit
>> latency to warrant an extra state in my opinion.  According to the
>> i.MX5 documentation, the extra exit time beyond basic WFI required for
>> the  "WAIT_UNCLOCKED_POWER_OFF" state is 500ns (this is due to a
>> difference in i.MX5 hardware implementation compared to all other ARM
>> platforms).  In reality, it did require a few more microseconds to
>> perform in my testing just based on the extra register writes in
>> mx5_cpu_lp_set().  I'd like to clean up mx5_cpu_lp_set() and add a
>> global variable to track the previous state and to just exit out if
>> the new state is the same as the old.
>
> Do you think it's worth it? You buy skipping the read with an additional
> test.
>

I'll run some tests to check.

Thanks,
Rob

>> I could do this cleanup as part of this patchset if you prefer that.
>
> Yes please. Cleanups before adding new features is always a good reason
> to apply a patch series ;)
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917- |

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] PM-QA: remove obsolete test scripts

[rajagopal . venkat]

From: Rajagopal Venkat 

The updated version of these test scripts are
available in their respective directories.

Signed-off-by: Rajagopal Venkat 
---
 run_template  |7 --
 testcases.awk |   40 --
 testcases/Makefile|   39 --
 testcases/cpufreq/Makefile|   31 
 testcases/cpufreq/avail_freq01.sh |   56 --
 testcases/cpufreq/avail_freq02.sh |   68 
 testcases/cpufreq/avail_gov01.sh  |   45 ---
 testcases/cpufreq/avail_gov02.sh  |   48 
 testcases/cpuhotplug/Makefile |   32 
 testcases/cpuhotplug/cpu_hotplug_latency.sh   |   88 -
 testcases/cpuidle/Makefile|   34 
 testcases/cpuidle/test_usb_cpuidle.c  |  102 -
 testcases/proof_o_concept/Makefile|   31 
 testcases/proof_o_concept/PM-list_c_states.sh |   36 -
 testcases/proof_o_concept/PM-list_p_states.sh |   32 
 15 files changed, 0 insertions(+), 689 deletions(-)
 delete mode 100644 run_template
 delete mode 100644 testcases.awk
 delete mode 100644 testcases/Makefile
 delete mode 100644 testcases/cpufreq/Makefile
 delete mode 100755 testcases/cpufreq/avail_freq01.sh
 delete mode 100755 testcases/cpufreq/avail_freq02.sh
 delete mode 100755 testcases/cpufreq/avail_gov01.sh
 delete mode 100755 testcases/cpufreq/avail_gov02.sh
 delete mode 100644 testcases/cpuhotplug/Makefile
 delete mode 100755 testcases/cpuhotplug/cpu_hotplug_latency.sh
 delete mode 100644 testcases/cpuidle/Makefile
 delete mode 100644 testcases/cpuidle/test_usb_cpuidle.c
 delete mode 100644 testcases/proof_o_concept/Makefile
 delete mode 100755 testcases/proof_o_concept/PM-list_c_states.sh
 delete mode 100755 testcases/proof_o_concept/PM-list_p_states.sh

diff --git a/run_template b/run_template
deleted file mode 100644
index 8c866f9..000
--- a/run_template
+++ /dev/null
@@ -1,7 +0,0 @@
-pm-qa-cexists proof_o_concept PM-list_c_states.sh
-pm-qa-pexists proof_o_concept PM-list_p_states.sh
-pm-qa-availfreq01 cpufreq avail_freq01.sh
-pm-qa-availfreq02 cpufreq avail_freq02.sh
-pm-qa-availgov01 cpufreq avail_gov01.sh
-pm-qa-availgov02 cpufreq avail_gov02.sh
-pm-qa-cpuidle cpuidle test_usb_cpuidle /dev/sdb 5 1
diff --git a/testcases.awk b/testcases.awk
deleted file mode 100644
index 71ce9ee..000
--- a/testcases.awk
+++ /dev/null
@@ -1,40 +0,0 @@
-#
-# PM-QA validation test suite for the power management on Linux
-#
-# Copyright (C) 2011, Linaro Limited.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.
-#
-# Contributors:
-# Torez Smith  (IBM Corporation)
-#   - initial API and implementation
-#
-
-###
- # For a series of power management related test, cycle through and 
- # execute. Each test to be executed is in file testcases  where the 
- # following columns make sense
- # column 1:  name of the test case
- # column 2:  sub directory housing the test
- # column 3:  name of file for the test case
- # column 4:  from column 4 onwards, any arguments to pass on to the test
-###
-{
-   printf $1 ":"
-   cmd = "cd  ./testcases/"$2   " ;  sudo ./"$3   " " substr($0, length($1 
$2 $3) +4)
-   system(cmd)
-   printf "\n"
-}
-
diff --git a/testcases/Makefile b/testcases/Makefile
deleted file mode 100644
index 08b3233..000
--- a/testcases/Makefile
+++ /dev/null
@@ -1,39 +0,0 @@
-#
-# PM-QA validation test suite for the power management on Linux
-#
-# Copyright (C) 2011, Linaro Limited.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, In

Re: [PATCH] PM-QA: remove obsolete test scripts

[Amit Kucheria]

On Thu, May 10, 2012 at 5:16 PM,   wrote:
> From: Rajagopal Venkat 
>
> The updated version of these test scripts are
> available in their respective directories.
>
>
> Signed-off-by: Rajagopal Venkat 

Ack. Hongbo, please merge this to pm-qa.

> ---
>  run_template                                  |    7 --
>  testcases.awk                                 |   40 --
>  testcases/Makefile                            |   39 --
>  testcases/cpufreq/Makefile                    |   31 
>  testcases/cpufreq/avail_freq01.sh             |   56 --
>  testcases/cpufreq/avail_freq02.sh             |   68 
>  testcases/cpufreq/avail_gov01.sh              |   45 ---
>  testcases/cpufreq/avail_gov02.sh              |   48 
>  testcases/cpuhotplug/Makefile                 |   32 
>  testcases/cpuhotplug/cpu_hotplug_latency.sh   |   88 -
>  testcases/cpuidle/Makefile                    |   34 
>  testcases/cpuidle/test_usb_cpuidle.c          |  102 
> -
>  testcases/proof_o_concept/Makefile            |   31 
>  testcases/proof_o_concept/PM-list_c_states.sh |   36 -
>  testcases/proof_o_concept/PM-list_p_states.sh |   32 
>  15 files changed, 0 insertions(+), 689 deletions(-)
>  delete mode 100644 run_template
>  delete mode 100644 testcases.awk
>  delete mode 100644 testcases/Makefile
>  delete mode 100644 testcases/cpufreq/Makefile
>  delete mode 100755 testcases/cpufreq/avail_freq01.sh
>  delete mode 100755 testcases/cpufreq/avail_freq02.sh
>  delete mode 100755 testcases/cpufreq/avail_gov01.sh
>  delete mode 100755 testcases/cpufreq/avail_gov02.sh
>  delete mode 100644 testcases/cpuhotplug/Makefile
>  delete mode 100755 testcases/cpuhotplug/cpu_hotplug_latency.sh
>  delete mode 100644 testcases/cpuidle/Makefile
>  delete mode 100644 testcases/cpuidle/test_usb_cpuidle.c
>  delete mode 100644 testcases/proof_o_concept/Makefile
>  delete mode 100755 testcases/proof_o_concept/PM-list_c_states.sh
>  delete mode 100755 testcases/proof_o_concept/PM-list_p_states.sh
>
> diff --git a/run_template b/run_template
> deleted file mode 100644
> index 8c866f9..000
> --- a/run_template
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -pm-qa-cexists proof_o_concept PM-list_c_states.sh
> -pm-qa-pexists proof_o_concept PM-list_p_states.sh
> -pm-qa-availfreq01 cpufreq avail_freq01.sh
> -pm-qa-availfreq02 cpufreq avail_freq02.sh
> -pm-qa-availgov01 cpufreq avail_gov01.sh
> -pm-qa-availgov02 cpufreq avail_gov02.sh
> -pm-qa-cpuidle cpuidle test_usb_cpuidle /dev/sdb 5 1
> diff --git a/testcases.awk b/testcases.awk
> deleted file mode 100644
> index 71ce9ee..000
> --- a/testcases.awk
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -#
> -# PM-QA validation test suite for the power management on Linux
> -#
> -# Copyright (C) 2011, Linaro Limited.
> -#
> -# This program is free software; you can redistribute it and/or
> -# modify it under the terms of the GNU General Public License
> -# as published by the Free Software Foundation; either version 2
> -# of the License, or (at your option) any later version.
> -#
> -# This program is distributed in the hope that it will be useful,
> -# but WITHOUT ANY WARRANTY; without even the implied warranty of
> -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> -# GNU General Public License for more details.
> -#
> -# You should have received a copy of the GNU General Public License
> -# along with this program; if not, write to the Free Software
> -# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
> USA.
> -#
> -# Contributors:
> -#     Torez Smith  (IBM Corporation)
> -#       - initial API and implementation
> -#
> -
> -###
> - # For a series of power management related test, cycle through and
> - # execute. Each test to be executed is in file testcases  where the
> - # following columns make sense
> - # column 1:  name of the test case
> - # column 2:  sub directory housing the test
> - # column 3:  name of file for the test case
> - # column 4:  from column 4 onwards, any arguments to pass on to the test
> -###
> -{
> -       printf $1 ":    "
> -       cmd = "cd  ./testcases/"$2   " ;  sudo ./"$3   " " substr($0, 
> length($1 $2 $3) +4)
> -       system(cmd)
> -       printf "\n"
> -}
> -
> diff --git a/testcases/Makefile b/testcases/Makefile
> deleted file mode 100644
> index 08b3233..000
> --- a/testcases/Makefile
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -#
> -# PM-QA validation test suite for the power management on Linux
> -#
> -# Copyright (C) 2011, Linaro Limited.
> -#
> -# This program is free software; you can redistribute it and/or
> -# modify it under the terms of the GNU General Public License
> -# as published by the Free Software Foundation; either version 2
> -# of the License, or (at your option) any later version.
> -#
> -# This program is distributed in the hope that it will be useful,
> -# but WIT

Re: Installing the armel libc on armhf

[Christian Robottom Reis]

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?
-- 
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: Installing the armel libc on armhf

[Wookey]

+++ Christian Robottom Reis [2012-05-10 11:50 -0300]:
> 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?


There should be a howto linked from http://wiki.debian.org/Multiarch
but there isn't currently. I'm sure there is one somewhere but I just
failed to find it. 
This is one of the clearest docs currently:
http://suihkulokki.blogspot.co.uk/2012/04/cross-compiling-with-multiarch-congrats.html

The details are also on the linaro wiki here:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingMultiArch

Linked from the index page:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/CrossBuilding
(which could do with an update)


Wookey

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: new IRC channel: linaro-lava

[Andy Doan]

On 05/10/2012 03:57 AM, Ricardo Salveti wrote:

On Wed, May 9, 2012 at 7:36 AM, Andy Doan  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]

-- 
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

[John Rigby]

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  wrote:

> On 05/10/2012 03:57 AM, Ricardo Salveti wrote:
>
>> On Wed, May 9, 2012 at 7:36 AM, Andy Doan  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
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

12.05 linux-linaro kernel tree

[Andrey Konovalov]

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...

[Ricardo Salveti]

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...

[Christian Robottom Reis]

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...

[Zach Pfeffer]

On 10 May 2012 15:20, Christian Robottom Reis  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...)

[Wookey]

+++ 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

[Michael Hope]

On 11 May 2012 02:50, Christian Robottom Reis  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

[Jon Medhurst (Tixy)]

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...

[Ricardo Salveti]

On Thu, May 10, 2012 at 1:20 PM, Christian Robottom Reis
 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...)

[Ricardo Salveti]

On Thu, May 10, 2012 at 1:37 PM, Wookey  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...

[Alexander Sack]

On Fri, May 11, 2012 at 12:21 AM, Ricardo Salveti
 wrote:
> On Thu, May 10, 2012 at 1:20 PM, Christian Robottom Reis
>  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...)

[Alexander Sack]

On Fri, May 11, 2012 at 12:24 AM, Ricardo Salveti
 wrote:
> On Thu, May 10, 2012 at 1:37 PM, Wookey  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...)

[Ricardo Salveti]

On Thu, May 10, 2012 at 3:30 PM, Alexander Sack  wrote:
> On Fri, May 11, 2012 at 12:24 AM, Ricardo Salveti
>  wrote:
>> On Thu, May 10, 2012 at 1:37 PM, Wookey  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

[Alexander Sack]

On Fri, May 11, 2012 at 12:09 AM, Jon Medhurst (Tixy)  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: 12.05 linux-linaro kernel tree

[Jon Medhurst (Tixy)]

On Fri, 2012-05-11 at 00:46 +0200, Alexander Sack wrote:
> On Fri, May 11, 2012 at 12:09 AM, Jon Medhurst (Tixy)  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?

Should we not release based on a specific Linux rc or final release
rather than some random intermediate commit. It seems a lot neater and
easier to communicate.

We don't have to take this 'tracking' thing too far :-)

-- 
Tixy


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 12.05 linux-linaro kernel tree

[Andy Green]

On 11/05/12 06:57, Somebody in the thread at some point said:

On Fri, 2012-05-11 at 00:46 +0200, Alexander Sack wrote:

On Fri, May 11, 2012 at 12:09 AM, Jon Medhurst (Tixy)  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?


Should we not release based on a specific Linux rc or final release
rather than some random intermediate commit. It seems a lot neater and
easier to communicate.

We don't have to take this 'tracking' thing too far :-)


Tracking is tracking, it's best done at whatever current basis head is.

But what is a 'release' here?  For normal mortals it's when Linus puts 
out a tag without the -rc bit, due to Linus' judgement that the 
breakages are largely ironed out.


When we talk about applying the Linaro Release-industrial complex with 
its mailing lists and rules and dedicated staff to a 'release' of 
tracking content, especially on this febrile unified tree, I think 
there's a bit of an impedence mismatch coming.


Being on some -rc or some other intermediate HEAD isn't going to make 
much odds, either that kernel performs overall better than a recent one 
at another HEAD or it doesn't, that's the only "release criteria".  If 
the current one performs best and is on a random HEAD commit, we 
certainly shouldn't wind it backwards to last -rc that performs worse 
just because that's "easier to communicate".


Likewise in unified case, there might not be much choice about which 
recent kernels had most LTs participating with workable content, if 
that's on an intermediate HEAD we can't be sniffy.


-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: 12.05 linux-linaro kernel tree

[Jon Medhurst (Tixy)]

On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If 
> the current one performs best and is on a random HEAD commit, we 
> certainly shouldn't wind it backwards to last -rc that performs worse 
> just because that's "easier to communicate".

I agree, I wasn't envisioning winding backwards, more that we stop
winding forwards at a chosen -rc, or stop merging topics on a Friday,
bring the common tree up-to-date with the weekends Torvalds -rc, then
build, test and fix this ready for Linaro RC on the Friday.

However...

> Likewise in unified case, there might not be much choice about which 
> recent kernels had most LTs participating with workable content, if 
> that's on an intermediate HEAD we can't be sniffy.

True. Also, the common tree is going to have the most recent HEAD that
any contributing team chose to base their topics on.

So in practice we're going to have a random mix of kernel version in a
release, and it's not worth getting hung up on Torvalds -rc version.

-- 
Tixy



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Incident Management (was: Re: pointless mail, (was Re: android-build's are failing...))

[Michael Hudson-Doyle]

On Fri, 11 May 2012 00:30:26 +0200, Alexander Sack  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, but
having some kind of defined place for recording details has two massive
values:

 1. It means there's a canonical place to go for information while the
incident is still in progress.[1]

 2. It means that at the end of the month or quarter or whatever you can
look back and have _actual data_ for how often various issues come
up, rather than relying on vague feelings like "it seems we run out
of disk space a lot".

I created a Google spreadsheet & form for adding details to it in an
attempt to reduce the overhead of recording an incident, but after
exactly two incidents, we already have an incident that was recorded in
a wiki page but not the spreadsheet, so maybe that was premature
optimization on my part.

It's only early days but I already feel happier for having this process
in place.  I'm happy to donate this policy to the wider set of services
Linaro runs if there is consensus it would be useful :-)

There is already a page on a related topic:

https://wiki.linaro.org/Internal/Process/DealingWithCrisis

but that seems to me to be aimed at bigger issues than android-build or
LAVA being unreachable for an hour.

One thing this thread points out to me though is that our policy does
not really cover communication, either within the team or with our
users.  I'll work on a proposal for that today.

Cheers,
mwh

[1] In particular, if an incident goes on for long enough to require
hand overs between people working on in, then a wiki page like this
is downright essential.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 12.05 linux-linaro kernel tree

[Andy Green]

On 11/05/12 07:43, Somebody in the thread at some point said:

On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If

the current one performs best and is on a random HEAD commit, we
certainly shouldn't wind it backwards to last -rc that performs worse
just because that's "easier to communicate".


I agree, I wasn't envisioning winding backwards, more that we stop
winding forwards at a chosen -rc, or stop merging topics on a Friday,
bring the common tree up-to-date with the weekends Torvalds -rc, then
build, test and fix this ready for Linaro RC on the Friday.


Right... the problem with that would have been though that on a random 
day - and Linaro's monthly release cycle is random for tracking - our 
tracking may be dead.  Right now I have local tracking tree that's 
considerably ahead of last public push but OMAP4 boot dies in a novel 
and cool way we didn't get to the bottom of yet.


We have good local-to-LT reasons for having got ourselves into that 
situation, we took in 70 patches from TI that are fixes or improvements 
to core support we want to have in for 3.4.  That reasoning might occur 
the day or week before this Linaro monthly release and we should again 
choose to temporarily trash the tree.  Sometimes, we get demand to hold 
tracking for other reasons again asynchronous to monthly release.


In short monthly release action will have to make do with "last thing 
that was working best" as a single LT tree and for unified "last unified 
build that was working best for most trees", which sometimes might be 
weeks old.  To facilitate the single LT case we are tagging our pushes 
we believe are worth something, even if they might go backwards 
sometimes as we integrate new drops of stuff.


For ARM LT the situation is a bit simpler, you have largely parallel 
feature trees with new - super valuable, don't get me wrong - content, 
in our case we have 1,000 - 2,000 patches with conflicting content to 
definitive stuff pouring in to mainline all the time.  We usually can't 
do any special planning to converge with the monthly release.  (Nor will 
it get better in medium term, 3.5 has a huge convulsion in hwmod coming 
that might send us back to the Stone Age for a while)


-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: 12.05 linux-linaro kernel tree

[Alexander Sack]

On Fri, May 11, 2012 at 1:43 AM, Jon Medhurst (Tixy)  wrote:
> On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If
>> the current one performs best and is on a random HEAD commit, we
>> certainly shouldn't wind it backwards to last -rc that performs worse
>> just because that's "easier to communicate".
>
> I agree, I wasn't envisioning winding backwards, more that we stop
> winding forwards at a chosen -rc, or stop merging topics on a Friday,
> bring the common tree up-to-date with the weekends Torvalds -rc, then
> build, test and fix this ready for Linaro RC on the Friday.

I think we agree ... here is how I thought so far should linux-linaro
could be driven forward:

 1. we have an automated -tracking baseline running that always
reflects how your topics look like on tip
 2. linux-linaro moves forward on the day a new RC comes around.
 3. linux-linaro will not wait for topics to be ready before doing the RC jump
 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.

Thoughts?


-- 
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: 12.05 linux-linaro kernel tree

[Alexander Sack]

On Fri, May 11, 2012 at 2:20 AM, Andy Green  wrote:
> On 11/05/12 07:43, Somebody in the thread at some point said:
>>
>> On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If
>>>
>>> the current one performs best and is on a random HEAD commit, we
>>> certainly shouldn't wind it backwards to last -rc that performs worse
>>> just because that's "easier to communicate".
>>
>>
>> I agree, I wasn't envisioning winding backwards, more that we stop
>> winding forwards at a chosen -rc, or stop merging topics on a Friday,
>> bring the common tree up-to-date with the weekends Torvalds -rc, then
>> build, test and fix this ready for Linaro RC on the Friday.
>
>
> Right... the problem with that would have been though that on a random day -
> and Linaro's monthly release cycle is random for tracking - our tracking may
> be dead.  Right now I have local tracking tree that's considerably ahead of
> last public push but OMAP4 boot dies in a novel and cool way we didn't get
> to the bottom of yet.
>
> We have good local-to-LT reasons for having got ourselves into that
> situation, we took in 70 patches from TI that are fixes or improvements to
> core support we want to have in for 3.4.  That reasoning might occur the day
> or week before this Linaro monthly release and we should again choose to
> temporarily trash the tree.  Sometimes, we get demand to hold tracking for
> other reasons again asynchronous to monthly release.
>
> In short monthly release action will have to make do with "last thing that
> was working best" as a single LT tree and for unified "last unified build
> that was working best for most trees", which sometimes might be weeks old.
>  To facilitate the single LT case we are tagging our pushes we believe are
> worth something, even if they might go backwards sometimes as we integrate
> new drops of stuff.
>
> For ARM LT the situation is a bit simpler, you have largely parallel feature
> trees with new - super valuable, don't get me wrong - content, in our case
> we have 1,000 - 2,000 patches with conflicting content to definitive stuff
> pouring in to mainline all the time.  We usually can't do any special
> planning to converge with the monthly release.  (Nor will it get better in
> medium term, 3.5 has a huge convulsion in hwmod coming that might send us
> back to the Stone Age for a while)
>

>From my (granted high level) perspective keeping good logs/statistics
of patches/topics that cause conflicts and pain over and over again
might serve as good indication to target investment in upstreaming or
frameworks improvements/refactoring.

I assume this idea has been played through? What's the plan forward to
solve this problem? Maybe if we look closely there might be potential
base framework topics hidden that could be tackled by our kernel WG to
help you out mid/long term?

-- 
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: 12.05 linux-linaro kernel tree

[Andy Green]

On 11/05/12 08:32, Somebody in the thread at some point said:

On Fri, May 11, 2012 at 2:20 AM, Andy Green  wrote:

On 11/05/12 07:43, Somebody in the thread at some point said:


On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If


the current one performs best and is on a random HEAD commit, we
certainly shouldn't wind it backwards to last -rc that performs worse
just because that's "easier to communicate".



I agree, I wasn't envisioning winding backwards, more that we stop
winding forwards at a chosen -rc, or stop merging topics on a Friday,
bring the common tree up-to-date with the weekends Torvalds -rc, then
build, test and fix this ready for Linaro RC on the Friday.



Right... the problem with that would have been though that on a random day -
and Linaro's monthly release cycle is random for tracking - our tracking may
be dead.  Right now I have local tracking tree that's considerably ahead of
last public push but OMAP4 boot dies in a novel and cool way we didn't get
to the bottom of yet.

We have good local-to-LT reasons for having got ourselves into that
situation, we took in 70 patches from TI that are fixes or improvements to
core support we want to have in for 3.4.  That reasoning might occur the day
or week before this Linaro monthly release and we should again choose to
temporarily trash the tree.  Sometimes, we get demand to hold tracking for
other reasons again asynchronous to monthly release.

In short monthly release action will have to make do with "last thing that
was working best" as a single LT tree and for unified "last unified build
that was working best for most trees", which sometimes might be weeks old.
  To facilitate the single LT case we are tagging our pushes we believe are
worth something, even if they might go backwards sometimes as we integrate
new drops of stuff.

For ARM LT the situation is a bit simpler, you have largely parallel feature
trees with new - super valuable, don't get me wrong - content, in our case
we have 1,000 - 2,000 patches with conflicting content to definitive stuff
pouring in to mainline all the time.  We usually can't do any special
planning to converge with the monthly release.  (Nor will it get better in
medium term, 3.5 has a huge convulsion in hwmod coming that might send us
back to the Stone Age for a while)



 From my (granted high level) perspective keeping good logs/statistics
of patches/topics that cause conflicts and pain over and over again
might serve as good indication to target investment in upstreaming or
frameworks improvements/refactoring.

I assume this idea has been played through? What's the plan forward to
solve this problem? Maybe if we look closely there might be potential
base framework topics hidden that could be tackled by our kernel WG to
help you out mid/long term?


We have been doing quite a bit of musing and discussion about how to 
make this better, the main thing that would help is greater integration 
to other pieces of TI that are the "domain experts" for our topics.


That has problems though, we are focused on tracking Linus HEAD to 
produce featureful Linus release trees at very low latency.  The member 
domain experts are focused on upstream solution on linux-omap-next 
basis, and at timescale mandated by upstream demands about how and with 
what their solutions must work.


I wish we could get KWG to do "something" that would help but I think 
the underlying issue is we are on a different basis than where all the 
effort is being poured into these topics by TI.  Then we only see the 
result of that work when it comes back on our mainline basis after a 
long lag.


If we just waited for everything, there'd be no point having an LT tree, 
although my life would be easier ^^, it means we have to take or 
scavenge and rebase more or less aging pieces that we are alone with for 
uplevel.  Surprisingly that has been fairly workable for us.  For 
example there's 650 patches near the start of our tree we uplevelled 
from 3.1 basis back in Feb that provides the core OMAP4 and OMAP5 
support.  I don't find it hard to imagine a better flow but we are just 
one piece of the puzzle and there are genuine disconnects such as 
different goals leading to different basis-trees (and different belief 
about suitability of merge-managed trees as input to rebase-managed 
process).


In any event nobody can do anything about hwmod changes coming down the 
pike we will just have to adapt to whatever it is (I found people don't 
want to hear about how to get rid of hwmod altogether ^^).


We plan to discuss this in depth at the HK Connect with all the 
stakeholders and see if we can find a better way to interface that 
provides advantages to everyone.


-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


___
li

Re: 12.05 linux-linaro kernel tree

[Andy Green]

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 like two trees with conflicting versions of, I dunno, Mali 
driver, that needs planning to resolve.  Or if people aren't using 
linux-linaro-core-tracking to get their CMA and so on, we need to know 
and start that migration.


-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: 12.05 linux-linaro kernel tree

[Alexander Sack]

On Fri, May 11, 2012 at 3:43 AM, Andy Green  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
>
> ARM        Merge-managed      integration-linux-vexpress 3.4-rc4
> TI         Rebase-managed     tilt-tracking              3.4-rc4
> Freescale  Merge-managed      lt-3.4                     3.4-rc3
> Samsung    Rebase-managed     tracking                   3.4-rc3
> STE        Merge-managed      integration-linux-ux500    3.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 :).

-- 
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...))

[Michael Hudson-Doyle]

On Fri, 11 May 2012 12:11:36 +1200, Michael Hudson-Doyle 
 wrote:
> On Fri, 11 May 2012 00:30:26 +0200, Alexander Sack  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

[Andy Green]

On 11/05/12 10:19, Somebody in the thread at some point said:

On Fri, May 11, 2012 at 3:43 AM, Andy Green  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

[Rob Lee]

Hello Uwe and Sascha,

On Wed, May 9, 2012 at 7:24 PM, 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 
> ---
>  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

[Tushar Behera]

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

[Andy Green]

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.git&a=search&h=refs%2Fheads%2Flinux-linaro-core-tracking&st=commit&s=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

Re: 12.05 linux-linaro kernel tree

[Jon Medhurst (Tixy)]

On Fri, 2012-05-11 at 02:27 +0200, Alexander Sack wrote:
> On Fri, May 11, 2012 at 1:43 AM, Jon Medhurst (Tixy)  wrote:
> > On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If
> >> the current one performs best and is on a random HEAD commit, we
> >> certainly shouldn't wind it backwards to last -rc that performs worse
> >> just because that's "easier to communicate".
> >
> > I agree, I wasn't envisioning winding backwards, more that we stop
> > winding forwards at a chosen -rc, or stop merging topics on a Friday,
> > bring the common tree up-to-date with the weekends Torvalds -rc, then
> > build, test and fix this ready for Linaro RC on the Friday.
> 
> I think we agree ... here is how I thought so far should linux-linaro
> could be driven forward:
> 
>  1. we have an automated -tracking baseline running that always
> reflects how your topics look like on tip
>  2. linux-linaro moves forward on the day a new RC comes around.
>  3. linux-linaro will not wait for topics to be ready before doing the RC jump
>  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.

I'm not sure this differs much from linux-linaro == last good automated
-tracking baseline, which might be simpler to understand. But I thought
linux-linaro was meant to be this tracking baseline anyway?

-- 
Tixy




___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev