[REMINDER] Linaro 11.09 release dates and deliveries

[Fathi Boudra]

Hi,

This is a mail sent to remind you the coming release dates:

 * Toolchain WG components release for 11.09 is September 15th, 2011.
 * Linaro 11.09 components release is September 22nd, 2011.
 * Linaro 11.09 RC images is September 26th, 2011.
 * Linaro 11.09 release is September 29th, 2011.

The following components are planned to be delivered this month:

 * Graphics WG: compiz, compiz-plugins, glcompbench, glmark2, glproxy
 * Kernel WG: u-boot-linaro, linux-linaro
 * Landing Teams: linux-linaro-lt-freescale, linux-linaro-android-lt-ti,
   linux-linaro-lt-samsung, linux-linaro-lt-st-ericsson, linux-linaro-lt-ti
 * Multimedia WG: libjpeg-turbo (for Android)
 * Platform Teams: lava-dashboard, lava-dispatcher, lava-qatracker,
   lava-scheduler, lava-scheduler-tool, lava-test, linaro-image-tools, svammel
 * Power Management WG: powerdebug
 * Toolchain WG: gcc-linaro 4.5, gcc-linaro 4.6, gdb-linaro, qemu-linaro,
   cortex-strings

Note: the Toolchain WG will use a new release scheme from now on. They will
  release two weeks before Linaro release, giving Developer Platform and
  Android Teams a fixed two weeks between the Toolchain and the Platform
  release.

The release dates and deliveries information is available from the release
dashboard: http://wiki.linaro.org/Cycles/1109/Release/Dashboard

Cheers,
-- 
Fathi Boudra
Linaro Release Manager | Platform Project Manager
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: Linaro Boot up times.

[Sudhangathan B S]

Thankyou for the super quick reponse,

I'l keep track of proposed "Investigate and improve the boot speed of
Oneiric based images"..  at the said link.

My boot time measurement markers are:
Timer start is at the plug-in (i.e. at the instant when overo-fire is
powered)
Timer end is when all the icons on the desktop have appeared, and loading
process is stopped. This is when the processor comes to a nearly idle state.
This comes to about 2 minutes approximately after a few tweaks. From the
startup applications I removed
1) login sound
2) Personal file sharing
3) Print queue applet
4) Pulse Audio related items
5) User folder update
6) Visual Assistance
Prior to which the boot time was approx 2m:15s...

Also wondering whether i can remove the Zeigeist datahub, for I don't know
what it is doing.



Thanks & Regards,
-
Sudhangathan BS
Ph:(+91) 9731-905-205
-


On Mon, Sep 12, 2011 at 12:19 PM, David Rusling wrote:

> CELF did a bunch of work around boot times, this might be useful -
> http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf
>
> Dave
>
>   David Rusling, CTO
>
> Linaro
> Lockton House
> Clarendon Rd
> Cambridge
> CB2 8FH
> ** **
> Linaro.org * **│ *Open source software for ARM
> SoCs
> Follow *Linaro: *Facebook  | 
> Twitter
>  | Blog 
> ** **
>  On 12 Sep 2011, at 07:43, Fathi Boudra wrote:
>
> Hi,
>
> On 12 September 2011 09:29, Sudhangathan B S 
> wrote:
>
> I need to boot Linaro in very short time as my project has a constraint on
>
> energy.
>
> The normal linaro boot up time is 2 minutes and 15 seconds on my overo
> fire.
>
> I did a little startup tweaks and achieved 2:00 minutes.
>
> Is there a way to boot up Linaro in under 40 sec. ?? This could include
>
> increasing CPU speeds or more OS tweaks
>
> Has anybody worked on this(Linaro boot up times) so far..??
>
>
> Could you give us more context on your results?
> Which image are you using?
> How do you measure the boot-up time (start/stop markers)?
>
> Developer Platform Team planned to investigate and improve the boot
> speed of our Oneiric based images:
>
> https://blueprints.launchpad.net/linaro-ubuntu/+spec/bootspeed-investigation-11.09
>
> Cheers,
>
> Fathi
>
> ___
> 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

[PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register

[Siarhei Siamashka]

Setting "Double linefill enable" bit improves memcpy performance
from ~750 MB/s to ~1150 MB/s when working with large buffers and
also the performance of just anything which may need good memory
bandwidth (for example, software rendered graphics).

Additionally setting "Double linefill on WRAP read disable" bit
compensates most of the random access latency increase.

Signed-off-by: Siarhei Siamashka 
---
 arch/arm/mach-exynos4/cpu.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index ba503c3..1afd25f 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -238,7 +238,7 @@ static int __init exynos4_l2x0_cache_init(void)
__raw_writel(0x110, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL);
 
/* L2X0 Prefetch Control */
-   __raw_writel(0x3007, S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
+   __raw_writel(0x7807, S5P_VA_L2CC + L2X0_PREFETCH_CTRL);
 
/* L2X0 Power Control */
__raw_writel(L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN,
-- 
1.7.3.4


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

Re: [PATCH] ARM: EXYNOS4: Setup consistent dma size at boot time

[Subash Patel]

My bad. I am still referring to drivers/video/samsung/s3cfb_main.c in 
Linaro-3.0 kernel. Thanks for the pointer. This makes sense now.


Also, we will not be able to use CMA directly, even after it gets 
mainlined. It needs to be called from the dma_alloc_*() with appropriate 
attributes.


Regards,
Subash

On 09/13/2011 09:00 AM, Tushar Behera wrote:

Hi Subash,

On Monday 12 September 2011 08:32 PM, Subash Patel wrote:

Hi Tushar,

On 09/12/2011 11:25 AM, Tushar Behera wrote:

Some of the boards under mach-exynos4 initialize frame-buffers
for which the memory requirement is more than 2MB (Nuri board requires
around 4MB, Origen requires around 2.6MB), hence the default dma pool
allocation size of 2MB is not sufficient. The consistent dma size is
hence increased to successfully allocate memory for those boards.

Depends on "ARM: Add init_consistent_dma_size()"
by Jon Medhurst (99d1717dd7fecf2b10195b0d864323b952b4eba0).

CC: Jon Medhurst
Signed-off-by: Tushar Behera
---
arch/arm/mach-exynos4/cpu.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..45d8bfa 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,7 @@

#include
#include
+#include

#include
#include
@@ -136,6 +137,7 @@ static void exynos4_idle(void)
void __init exynos4_map_io(void)
{
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+ init_consistent_dma_size(SZ_8M);



I think CMA is being used to allocate the FB in origen machine. In that
case, increasing the consistent memory is not useful. If the memory is
increased in the consistent DMA area, how can that be useful to s3cfb?


We are using dma_alloc_writecombine to allocate frame buffer memory.
Ref: linux/drivers/video/s3c-fb.c:s3c_fb_alloc_memory().

CMA is not yet part of the mainline kernel and hence there is no way the
FB can use CMA for memory allocation.

Regards,
Subash



/* initialize device information early */
exynos4_default_sdhci0();





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

Re: [PATCH] ARM: EXYNOS4: Setup consistent dma size at boot time

[Tushar Behera]

Hi Subash,

On Monday 12 September 2011 08:32 PM, Subash Patel wrote:

Hi Tushar,

On 09/12/2011 11:25 AM, Tushar Behera wrote:

Some of the boards under mach-exynos4 initialize frame-buffers
for which the memory requirement is more than 2MB (Nuri board requires
around 4MB, Origen requires around 2.6MB), hence the default dma pool
allocation size of 2MB is not sufficient. The consistent dma size is
hence increased to successfully allocate memory for those boards.

Depends on "ARM: Add init_consistent_dma_size()"
by Jon Medhurst (99d1717dd7fecf2b10195b0d864323b952b4eba0).

CC: Jon Medhurst
Signed-off-by: Tushar Behera
---
arch/arm/mach-exynos4/cpu.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..45d8bfa 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,7 @@

#include
#include
+#include

#include
#include
@@ -136,6 +137,7 @@ static void exynos4_idle(void)
void __init exynos4_map_io(void)
{
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+ init_consistent_dma_size(SZ_8M);



I think CMA is being used to allocate the FB in origen machine. In that
case, increasing the consistent memory is not useful. If the memory is
increased in the consistent DMA area, how can that be useful to s3cfb?


We are using dma_alloc_writecombine to allocate frame buffer memory.
Ref: linux/drivers/video/s3c-fb.c:s3c_fb_alloc_memory().

CMA is not yet part of the mainline kernel and hence there is no way the 
FB can use CMA for memory allocation.

Regards,
Subash



/* initialize device information early */
exynos4_default_sdhci0();



--
Tushar Behera

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

Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Zach Pfeffer]

On 12 September 2011 16:36, Michael Hope  wrote:
> On Mon, Sep 12, 2011 at 11:36 PM, Loïc Minier  wrote:
>> On Mon, Sep 12, 2011, Zach Pfeffer wrote:
>>> I think stage is okay. Its short for staging which is used in the
>>> kernel as a place for things which aren't mainline.
>>> If I hear of any other issues with the name I'll think we can
>>> reevaluate it, but overall I think the term stage is okay.
>>
>>  Sorry for the bikeshedding.  "staging" or "staged" would in my eyes be
>>  much clearer than "stage".
>
> Agreed.  Use English, which also means no abbreviations.
>
> Releases should have the shortest name.  Development versions should
> have a unique suffix.  And the shed should be a pinker shade of green.

So:

stage-origen-11.09-release
stage-panda-11.09-release
stage-snowball-11.09-release
stage-imx53-11.09-release
panda-11.09-release
beagle-11.09-release

Would be:

origen-staging-11.09-taupe
panda-staging-11.09-mauve
snowball-staging-11-burntsienna
imx53-staging-11.09-orangecrush
panda-11.09-crucialpink
beagle-11.09-black

minus the colors  ;)

-- 
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: Bootchart results

[Guilherme Salgado]

On Mon, 2011-09-12 at 15:13 -0500, Paul Larson wrote:
> This time with the attachment :)
> 
> On Mon, Sep 12, 2011 at 2:16 PM, Paul Larson 
> wrote:
> I started working on a results view in LAVA for the bootchart
> results since they are now part of the daily runs.  This is
> using a partial copy of the data I have locally, so please
> don't concern yourself too much with the actual data in it.  A
> couple of things to point out:
> 
> 1. legend is not placed well, that's something I'm not yet
> sure how to fix as my javascript-fu is lacking here (zyga, any
> ideas on this?)

By the looks of it, I suspect you're using the flot plugin for jquery to
generate the chart. If that's the case, to the best of my knowledge, all
you can do (easily) is place the legend on any of the four corners of
the chart, so in your case it might be best to place it on the bottom
right (se).  You can achieve that by adding

  legend: {position: "se"}

to the options argument you pass to $.plot()

But once we make nano boot faster its line will overlap with the legend.

> 2. The set of results here is not very large.  That's
> adjustable and when it's using live data, should have a lot
> more data points to better see trends
> 3. This is purposefully restricted to a single board.  We are
> not running benchmarks in a controlled enough manner as to
> make comparison of boards to one another reasonable, nor is it
> encouraged due to the collaborative nature of Linaro.
> 
> 
> In particular I'm looking for opinions on how it would be most
> useful to display this data.  This view shows all 4 image
> types on a single chart.  I did a previous version that had
> them separate.  Is there a preference? It would also be easy
> to do both on the same page, but perhaps a bit redundant.

I assume the dates refer to when the test was run? I wonder if it
wouldn't be better to use the date the hwpack/rootfs was built instead.
That way we can easily see what hwpack/rootfs made it faster/slower
without having to dig what hwpack+rootfs combination was used on a given
date. Actually, it's probably simpler and much nicer to just show the
hwpack+rootfs versions on a tooltip when the mouse hovers over one of
the points on a given line.

-- 
Guilherme Salgado 


signature.asc
Description: This is a digitally signed message part
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 4/6] drm/gem: add functions to get/put pages

[Rob Clark]

On Mon, Sep 12, 2011 at 2:21 PM, Rob Clark  wrote:
> From: Rob Clark 
>
> This factors out common code from psb_gtt_attach_pages()/
> i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
> i915_gem_object_put_pages_gtt().
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_gem.c |   68 
> +
>  include/drm/drmP.h        |    3 ++
>  2 files changed, 71 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 396e60c..05113c3 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -285,6 +285,74 @@ again:
>  }
>  EXPORT_SYMBOL(drm_gem_handle_create);
>
> +/**
> + * drm_gem_get_pages - helper to allocate backing pages for a GEM object
> + * @obj: obj in question
> + * @gfpmask: gfp mask of requested pages
> + */
> +struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
> +{
> +       struct inode *inode;
> +       struct address_space *mapping;
> +       struct page *p, **pages;
> +       int i, npages;
> +
> +       /* This is the shared memory object that backs the GEM resource */
> +       inode = obj->filp->f_path.dentry->d_inode;
> +       mapping = inode->i_mapping;
> +
> +       npages = obj->size >> PAGE_SHIFT;
> +
> +       pages = drm_malloc_ab(npages, sizeof(struct page *));
> +       if (pages == NULL)
> +               return ERR_PTR(-ENOMEM);
> +
> +       gfpmask |= mapping_gfp_mask(mapping);
> +
> +       for (i = 0; i < npages; i++) {
> +               p = shmem_read_mapping_page_gfp(mapping, i, gfpmask);

note:  I'll send an updated version of this patch w/ a

  BUG_ON((gfpmask & __GFP_DMA32) && (page_to_pfn(p) >= 0x0010UL));

or something roughly like this, to catch cases where
shmem_read_mapping_page_gfp() doesn't actually give us a page in the
low 4GB..

It is only a theoretical issue currently, as (AFAIK) no devices w/ 4GB
restriction currently have enough memory to hit this problem.  But it
would be good to have some error checking in case
shmem_read_mapping_page_gfp() isn't fixed by the time we have devices
that would have this problem.

BR,
-R

> +               if (IS_ERR(p))
> +                       goto fail;
> +               pages[i] = p;
> +       }
> +
> +       return pages;
> +
> +fail:
> +       while (i--) {
> +               page_cache_release(pages[i]);
> +       }
> +       drm_free_large(pages);
> +       return ERR_PTR(PTR_ERR(p));
> +}
> +EXPORT_SYMBOL(drm_gem_get_pages);
> +
> +/**
> + * drm_gem_put_pages - helper to free backing pages for a GEM object
> + * @obj: obj in question
> + * @pages: pages to free
> + */
> +void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
> +               bool dirty, bool accessed)
> +{
> +       int i, npages;
> +
> +       npages = obj->size >> PAGE_SHIFT;
> +
> +       for (i = 0; i < npages; i++) {
> +               if (dirty)
> +                       set_page_dirty(pages[i]);
> +
> +               if (accessed)
> +                       mark_page_accessed(pages[i]);
> +
> +               /* Undo the reference we took when populating the table */
> +               page_cache_release(pages[i]);
> +       }
> +
> +       drm_free_large(pages);
> +}
> +EXPORT_SYMBOL(drm_gem_put_pages);
>
>  /**
>  * drm_gem_free_mmap_offset - release a fake mmap offset for an object
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 43538b6..a62d8fe 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1624,6 +1624,9 @@ drm_gem_object_handle_unreference_unlocked(struct 
> drm_gem_object *obj)
>        drm_gem_object_unreference_unlocked(obj);
>  }
>
> +struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
> +void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
> +               bool dirty, bool accessed);
>  void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
>  int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
>
> --
> 1.7.5.4
>
>

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

Re: [PATCH 6/6] drm/gma500: use common functions for get/put pages

[Alan Cox]

> > 3. GMA500 used the old way of doing things because last mail conversation
> > I had with Hugh the cleaned up interfaces could not guarantee the page is
> > mapped in the low 32bits and for any of the GMA500/600 series devices.
> >
> > Has that changed ? I think I'd also prefer it if the methods had a
> > BUG_ON() getting a high page when they asked for DMA32.
> 
> Hmm, ok, I found this thread, which is I guess what you are referring to:
> 
>   https://lkml.org/lkml/2011/7/11/269
> 
> I'm not really sure if anything has changed.. But it doesn't look like
> the gma500 driver ever unpins anything.. so I guess it isn't a problem
> (yet).  (Well, either that or I am overlooking something.)

It unpins objects when they are removed from the GTT.

> btw, I could be missing something, but it seems like as long as you
> remove the pages from any userspace mmap'ing before you unpin the
> pages, that you shouldn't hit the case of page getting swapped back in

I don't see how you can guarantee another task won't page it in or have
it referenced (eg via shmem and GEM's FLINK feature). So it's pretty hard
to do.

> >4gb.. if you are always in control of bringing the page back into
> memory, you can ensure that DMA32 is always specified.  Not sure if
> that helps at all.  But at some point in the not too distant future,
> I'll be in the same boat so I am interested in a good way to handle
> this.

Might be worth following up with Hugh if you also need it. Right now we
kind of dodge it on GMA500 as you can't buy a box with that much memory
attached to one so its theoretical for the moment.

We did briefly discuss offlist but didn't chase it down because it was
theoretical for the moment. One possibility would be for the shmem/vfs
code to be smart enough to invalidate and move the page.

> re: BUG_ON():
> I wonder if a check would better belong in
> shmem_read_mapping_page_gfp() or shmem_getpage_gfp()?

Agreed. The BUG_ON is sufficient for GMA500 itself - just so if we ever
forget about it we bug rather than do something very nasty.



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

Re: [PATCH 6/6] drm/gma500: use common functions for get/put pages

[Rob Clark]

On Mon, Sep 12, 2011 at 3:31 PM, Alan Cox  wrote:
> On Mon, 12 Sep 2011 14:21:26 -0500
> Rob Clark  wrote:
>
>> From: Rob Clark 
>>
>> Signed-off-by: Rob Clark 
>
> Generally looks sensible but:
>
> 1. This is a staging driver, so good practise is to cc the staging
> maintainer and preferably the author (though I'm on dri-devel so its ok).
> It needs to be co-ordinated with existing staging changes and the
> maintainer needs to know what is going on

ok, will do that in the future

> 2. It needs a changelog. Your 0/6 won't be in the git tree and someone
> chasing regressions may only see the individual patch changelog and not
> be sure what it relates to. From/Signed off by alone is not helpful.

ok.. in this case the changelog only applied to the first patches
(initial patchset didn't have the drm_gem_get/put_pages()) but I will
do this in the future as needed

> 3. GMA500 used the old way of doing things because last mail conversation
> I had with Hugh the cleaned up interfaces could not guarantee the page is
> mapped in the low 32bits and for any of the GMA500/600 series devices.
>
> Has that changed ? I think I'd also prefer it if the methods had a
> BUG_ON() getting a high page when they asked for DMA32.

Hmm, ok, I found this thread, which is I guess what you are referring to:

  https://lkml.org/lkml/2011/7/11/269

I'm not really sure if anything has changed.. But it doesn't look like
the gma500 driver ever unpins anything.. so I guess it isn't a problem
(yet).  (Well, either that or I am overlooking something.)

btw, I could be missing something, but it seems like as long as you
remove the pages from any userspace mmap'ing before you unpin the
pages, that you shouldn't hit the case of page getting swapped back in
>4gb.. if you are always in control of bringing the page back into
memory, you can ensure that DMA32 is always specified.  Not sure if
that helps at all.  But at some point in the not too distant future,
I'll be in the same boat so I am interested in a good way to handle
this.

re: BUG_ON():
I wonder if a check would better belong in
shmem_read_mapping_page_gfp() or shmem_getpage_gfp()?

BR,
-R

>
> Alan
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

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

Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Michael Hope]

On Mon, Sep 12, 2011 at 11:36 PM, Loïc Minier  wrote:
> On Mon, Sep 12, 2011, Zach Pfeffer wrote:
>> I think stage is okay. Its short for staging which is used in the
>> kernel as a place for things which aren't mainline.
>> If I hear of any other issues with the name I'll think we can
>> reevaluate it, but overall I think the term stage is okay.
>
>  Sorry for the bikeshedding.  "staging" or "staged" would in my eyes be
>  much clearer than "stage".

Agreed.  Use English, which also means no abbreviations.

Releases should have the shortest name.  Development versions should
have a unique suffix.  And the shed should be a pinker shade of green.

-- Michael

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

Re: Bootchart results

[Paul Larson]

On Mon, Sep 12, 2011 at 3:37 PM, Tom Gall  wrote:

> The machine, configuration would be also good to have as part of the
> context. Media (class if applicable) in use.
>
What kind of configuration are you looking for?  This doesn't sound like
something that would fit well on the graph, but better in the detailed
results which are already there.  In this case, it's a pandaboard, as
indicated.

As for the sdcard class, I have no idea.  Do we even have a way to determine
this at runtime?  You may want to talk to Avik who contributed the test
wrapper if this is something that can be gathered, and we can make sure it's
reported along with the time.

Thanks,
Paul Larson
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Bootchart results

[Paul Larson]

On Mon, Sep 12, 2011 at 3:32 PM, Jesse Barker wrote:

> Is this "time to boot to a prompt"?
>
Someone can correct me if I'm wrong here, but iirc it looks for getty or the
display manager (or greeter) depending on which runlevel it hits.
http://www.bootchart.org/ has more information on the benchmark itself.

Thanks,
Paul Larson
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Bootchart results

[Tom Gall]

The machine, configuration would be also good to have as part of the
context. Media (class if applicable) in use.

The times noted for developer and nano seem quite long.

Regards,
Tom

On Mon, Sep 12, 2011 at 3:13 PM, Paul Larson  wrote:
> This time with the attachment :)
>
> On Mon, Sep 12, 2011 at 2:16 PM, Paul Larson  wrote:
>>
>> I started working on a results view in LAVA for the bootchart results
>> since they are now part of the daily runs.  This is using a partial copy of
>> the data I have locally, so please don't concern yourself too much with the
>> actual data in it.  A couple of things to point out:
>> 1. legend is not placed well, that's something I'm not yet sure how to fix
>> as my javascript-fu is lacking here (zyga, any ideas on this?)
>> 2. The set of results here is not very large.  That's adjustable and when
>> it's using live data, should have a lot more data points to better see
>> trends
>> 3. This is purposefully restricted to a single board.  We are not running
>> benchmarks in a controlled enough manner as to make comparison of boards to
>> one another reasonable, nor is it encouraged due to the collaborative nature
>> of Linaro.
>> In particular I'm looking for opinions on how it would be most useful to
>> display this data.  This view shows all 4 image types on a single chart.  I
>> did a previous version that had them separate.  Is there a preference? It
>> would also be easy to do both on the same page, but perhaps a bit redundant.
>> Thanks,
>> Paul Larson
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
>



-- 
Regards,
Tom

"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com

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

Re: Bootchart results

[Jesse Barker]

Is this "time to boot to a prompt"?

cheers,
Jesse

On Mon, Sep 12, 2011 at 1:13 PM, Paul Larson  wrote:
> This time with the attachment :)
>
> On Mon, Sep 12, 2011 at 2:16 PM, Paul Larson  wrote:
>>
>> I started working on a results view in LAVA for the bootchart results
>> since they are now part of the daily runs.  This is using a partial copy of
>> the data I have locally, so please don't concern yourself too much with the
>> actual data in it.  A couple of things to point out:
>> 1. legend is not placed well, that's something I'm not yet sure how to fix
>> as my javascript-fu is lacking here (zyga, any ideas on this?)
>> 2. The set of results here is not very large.  That's adjustable and when
>> it's using live data, should have a lot more data points to better see
>> trends
>> 3. This is purposefully restricted to a single board.  We are not running
>> benchmarks in a controlled enough manner as to make comparison of boards to
>> one another reasonable, nor is it encouraged due to the collaborative nature
>> of Linaro.
>> In particular I'm looking for opinions on how it would be most useful to
>> display this data.  This view shows all 4 image types on a single chart.  I
>> did a previous version that had them separate.  Is there a preference? It
>> would also be easy to do both on the same page, but perhaps a bit redundant.
>> Thanks,
>> Paul Larson
>
> ___
> 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

Re: [PATCH 6/6] drm/gma500: use common functions for get/put pages

[Alan Cox]

On Mon, 12 Sep 2011 14:21:26 -0500
Rob Clark  wrote:

> From: Rob Clark 
> 
> Signed-off-by: Rob Clark 

Generally looks sensible but:

1. This is a staging driver, so good practise is to cc the staging
maintainer and preferably the author (though I'm on dri-devel so its ok).
It needs to be co-ordinated with existing staging changes and the
maintainer needs to know what is going on

2. It needs a changelog. Your 0/6 won't be in the git tree and someone
chasing regressions may only see the individual patch changelog and not
be sure what it relates to. From/Signed off by alone is not helpful.

3. GMA500 used the old way of doing things because last mail conversation
I had with Hugh the cleaned up interfaces could not guarantee the page is
mapped in the low 32bits and for any of the GMA500/600 series devices.

Has that changed ? I think I'd also prefer it if the methods had a
BUG_ON() getting a high page when they asked for DMA32.


Alan

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

[PATCH v2] ORIGEN : use absolute paths and fix tool naming

[Angus Ainslie]

On some hosts using relative paths will cause the build to fail. This
patch sets absolute paths for the tools directory

Get rid of MSDOS style excecutable extension

Signed-off-by: Angus Ainslie 
---
 board/samsung/origen/Makefile |6 +++---
 spl/Makefile  |2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/samsung/origen/Makefile b/board/samsung/origen/Makefile
index f5c6507..76a359c 100644
--- a/board/samsung/origen/Makefile
+++ b/board/samsung/origen/Makefile
@@ -41,7 +41,7 @@ OBJS  := $(addprefix $(obj),$(COBJS) $(SOBJS))
 ALL+=$(obj).depend $(LIB)
 
 ifdef CONFIG_SPL_BUILD
-ALL+= tools/mk$(BOARD)spl.exe
+ALL+= $(OBJTREE)/tools/mk$(BOARD)spl
 endif
 
 all:   $(ALL)
@@ -50,8 +50,8 @@ $(LIB):   $(OBJS)
$(AR) $(ARFLAGS) $@ $(OBJS)
 
 ifdef CONFIG_SPL_BUILD
-tools/mk$(BOARD)spl.exe:   tools/mkv310_image.c
-   $(HOSTCC) tools/mkv310_image.c -o tools/mk$(BOARD)spl.exe
+$(OBJTREE)/tools/mk$(BOARD)spl:tools/mkv310_image.c
+   $(HOSTCC) tools/mkv310_image.c -o $(OBJTREE)/tools/mk$(BOARD)spl
 endif
 
 #
diff --git a/spl/Makefile b/spl/Makefile
index 95ecce1..dc3f4be 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -101,7 +101,7 @@ all:$(ALL-y)
 
 ifdef CONFIG_SAMSUNG
 $(obj)$(BOARD)-spl.bin: $(obj)u-boot-spl.bin
-   $(TOPDIR)/board/$(BOARDDIR)/tools/mk$(BOARD)spl.exe \
+   $(OBJTREE)/tools/mk$(BOARD)spl \
$(obj)u-boot-spl.bin $(obj)$(BOARD)-spl.bin
 endif
 
-- 
1.7.4.1


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

Re: Code Review for enabling wifi for Pandaboard

[Vishal Bhoj]

Please review the following commits.
http://review.android.git.linaro.org/#change,175
http://review.android.git.linaro.org/#change,183
http://review.android.git.linaro.org/#change,185

On 13 September 2011 01:04, Vishal Bhoj  wrote:

> Please review the following commits instead of #176 and #178
>
> http://review.android.git.linaro.org/#change,184
> http://review.android.git.linaro.org/#change,185
>
>
> On 12 September 2011 23:14, Vishal Bhoj  wrote:
>
>> Hello All,
>>
>> These are the changes to enable wifi on Pandaboard.Please review them.
>>
>> http://review.android.git.linaro.org/#change,175
>> This enables wpa_supplicant build for pandaboard adds wpa_supplicant.conf
>> file for Pandaboard.
>> http://review.android.git.linaro.org/#change,176
>> This change was necessary since ctrl_interface as getting created after
>> wifi service tried to access it.
>> http://review.android.git.linaro.org/#change,178
>> This  patch has been derived from
>> https://gitorious.org/picopc-android-gingerbread/external-wpa_supplicant_6/commit/5f5c50d722eedaedd75c1698b79f464310ce6478?format=patch.
>> The change to wpa_supplicant was necessary because android uses a modified
>> wpa_supplicant and wext calls implemented actually uses IOCTL "SIOCSIWPRIV"
>> which is not implemented in the standard wifi drivers.The patch is a
>> workaround to get wifi working on panda .I have tested the change and works
>> on panda BUT I am not sure if the devices using the original implementation
>> still work.
>>
>> Regards,
>> Vishal
>>
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Code Review for enabling wifi for Pandaboard

[Vishal Bhoj]

Please review the following commits instead of #176 and #178

http://review.android.git.linaro.org/#change,184
http://review.android.git.linaro.org/#change,185

On 12 September 2011 23:14, Vishal Bhoj  wrote:

> Hello All,
>
> These are the changes to enable wifi on Pandaboard.Please review them.
>
> http://review.android.git.linaro.org/#change,175
> This enables wpa_supplicant build for pandaboard adds wpa_supplicant.conf
> file for Pandaboard.
> http://review.android.git.linaro.org/#change,176
> This change was necessary since ctrl_interface as getting created after
> wifi service tried to access it.
> http://review.android.git.linaro.org/#change,178
> This  patch has been derived from
> https://gitorious.org/picopc-android-gingerbread/external-wpa_supplicant_6/commit/5f5c50d722eedaedd75c1698b79f464310ce6478?format=patch.
> The change to wpa_supplicant was necessary because android uses a modified
> wpa_supplicant and wext calls implemented actually uses IOCTL "SIOCSIWPRIV"
> which is not implemented in the standard wifi drivers.The patch is a
> workaround to get wifi working on panda .I have tested the change and works
> on panda BUT I am not sure if the devices using the original implementation
> still work.
>
> Regards,
> Vishal
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: people summaries broken on status.linaro.org

[James Westby]

Hi,

This is now fixed, and the other pages will be updating over the next
hour or so.

The problem was a bug that only seems to manifest in production, so I've
rolled back for now until we can investigate and fix it.

Thanks,

James

On Mon, 12 Sep 2011 15:59:20 +0100, Dave Martin  wrote:
> Hi all,
> 
> I don't remember off the top of my head who maintains status.linaro.org,
> but the people summaries don't seem to be working for me:
> 
> http://status.linaro.org/11.11/people.html
> 
> I just get a page with the following.
> 
> Cheers
> ---Dave
> 
> 
> People
> 
> These are all of the people. Click on any to see their progress towards 
> completing their tasks for the cycle.
> 
> No people!
> 
> Last updated: Mon 12 September 2011, 08:30 UTC | Bugs | Code | Config | 
> Update log (yesterday) 
> 
> 
> Maybe this from the update log is a clue:
> 
> Finished at Mon Sep 12 08:30:04 UTC 2011
> Traceback (most recent call last):
>   File "./json-report", line 58, in 
> store, config, opts.team, opts.milestone)
>   File "/srv/status.linaro.org/work-items-tracker/report_tools.py", line 789, 
> in spec_information
> for d in result.description:
> AttributeError: 'SQLiteResult' object has no attribute 'description'
> 
> ___
> 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

Re: [PATCH 0/6] Common functions for GEM (v2)

[Dave Airlie]

On Mon, Sep 12, 2011 at 8:21 PM, Rob Clark  wrote:
> From: Rob Clark 
>
> In the process of adding GEM support for omapdrm driver, I noticed that
> I was adding code for creating/freeing mmap offsets which was virtually
> identical to what was already duplicated in i915 and gma500 drivers.
> And the code for attach/detatch_pages was quite similar as well.
>
> Rather than duplicating the code a 3rd time, it seemed like a good idea
> to move it to the GEM core.
>
> Note that I don't actually have a way to test psb or i915, but the
> changes seem straightforward enough

I've merged bits of this already,

.http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-core-next

this is temporary -next home. care to rebase?

Dave.

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

[PATCH 5/6] drm/i915: use common functions for get/put pages

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/i915_gem.c |   51 +++---
 1 files changed, 10 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ee59f31..6b49b4e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1450,52 +1450,29 @@ static int
 i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
  gfp_t gfpmask)
 {
-   int page_count, i;
-   struct address_space *mapping;
-   struct inode *inode;
-   struct page *page;
+   struct page **pages;
 
-   /* Get the list of pages out of our struct file.  They'll be pinned
-* at this point until we release them.
-*/
-   page_count = obj->base.size / PAGE_SIZE;
BUG_ON(obj->pages != NULL);
-   obj->pages = drm_malloc_ab(page_count, sizeof(struct page *));
-   if (obj->pages == NULL)
-   return -ENOMEM;
-
-   inode = obj->base.filp->f_path.dentry->d_inode;
-   mapping = inode->i_mapping;
-   gfpmask |= mapping_gfp_mask(mapping);
 
-   for (i = 0; i < page_count; i++) {
-   page = shmem_read_mapping_page_gfp(mapping, i, gfpmask);
-   if (IS_ERR(page))
-   goto err_pages;
+   pages = drm_gem_get_pages(&obj->base, gfpmask);
 
-   obj->pages[i] = page;
+   if (IS_ERR(pages)) {
+   dev_err(obj->base.dev->dev,
+   "could not get pages: %ld\n", PTR_ERR(pages));
+   return PTR_ERR(pages);
}
 
if (obj->tiling_mode != I915_TILING_NONE)
i915_gem_object_do_bit_17_swizzle(obj);
 
-   return 0;
-
-err_pages:
-   while (i--)
-   page_cache_release(obj->pages[i]);
+   obj->pages = pages;
 
-   drm_free_large(obj->pages);
-   obj->pages = NULL;
-   return PTR_ERR(page);
+   return 0;
 }
 
 static void
 i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
 {
-   int page_count = obj->base.size / PAGE_SIZE;
-   int i;
-
BUG_ON(obj->madv == __I915_MADV_PURGED);
 
if (obj->tiling_mode != I915_TILING_NONE)
@@ -1504,18 +1481,10 @@ i915_gem_object_put_pages_gtt(struct 
drm_i915_gem_object *obj)
if (obj->madv == I915_MADV_DONTNEED)
obj->dirty = 0;
 
-   for (i = 0; i < page_count; i++) {
-   if (obj->dirty)
-   set_page_dirty(obj->pages[i]);
-
-   if (obj->madv == I915_MADV_WILLNEED)
-   mark_page_accessed(obj->pages[i]);
+   drm_gem_put_pages(&obj->base, obj->pages, obj->dirty,
+   obj->madv == I915_MADV_WILLNEED);
 
-   page_cache_release(obj->pages[i]);
-   }
obj->dirty = 0;
-
-   drm_free_large(obj->pages);
obj->pages = NULL;
 }
 
-- 
1.7.5.4


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

[PATCH 0/6] Common functions for GEM (v2)

[Rob Clark]

From: Rob Clark 

In the process of adding GEM support for omapdrm driver, I noticed that
I was adding code for creating/freeing mmap offsets which was virtually
identical to what was already duplicated in i915 and gma500 drivers.
And the code for attach/detatch_pages was quite similar as well.

Rather than duplicating the code a 3rd time, it seemed like a good idea
to move it to the GEM core.

Note that I don't actually have a way to test psb or i915, but the
changes seem straightforward enough.

v1: initial patches
v2: rebase + add common get/put_pages functions

Rob Clark (6):
  drm/gem: add functions for mmap offset creation
  drm/i915: use common functions for mmap offset creation
  drm/gma500: use common functions for mmap offset creation
  drm/gem: add functions to get/put pages
  drm/i915: use common functions for get/put pages
  drm/gma500: use common functions for get/put pages

 drivers/gpu/drm/drm_gem.c |  156 +
 drivers/gpu/drm/i915/i915_gem.c   |  136 +++-
 drivers/staging/gma500/gem.c  |2 +-
 drivers/staging/gma500/gem_glue.c |   61 +--
 drivers/staging/gma500/gem_glue.h |1 -
 drivers/staging/gma500/gtt.c  |   47 +++
 include/drm/drmP.h|6 ++
 7 files changed, 188 insertions(+), 221 deletions(-)

-- 
1.7.5.4


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

[PATCH 4/6] drm/gem: add functions to get/put pages

[Rob Clark]

From: Rob Clark 

This factors out common code from psb_gtt_attach_pages()/
i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
i915_gem_object_put_pages_gtt().

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_gem.c |   68 +
 include/drm/drmP.h|3 ++
 2 files changed, 71 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 396e60c..05113c3 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -285,6 +285,74 @@ again:
 }
 EXPORT_SYMBOL(drm_gem_handle_create);
 
+/**
+ * drm_gem_get_pages - helper to allocate backing pages for a GEM object
+ * @obj: obj in question
+ * @gfpmask: gfp mask of requested pages
+ */
+struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask)
+{
+   struct inode *inode;
+   struct address_space *mapping;
+   struct page *p, **pages;
+   int i, npages;
+
+   /* This is the shared memory object that backs the GEM resource */
+   inode = obj->filp->f_path.dentry->d_inode;
+   mapping = inode->i_mapping;
+
+   npages = obj->size >> PAGE_SHIFT;
+
+   pages = drm_malloc_ab(npages, sizeof(struct page *));
+   if (pages == NULL)
+   return ERR_PTR(-ENOMEM);
+
+   gfpmask |= mapping_gfp_mask(mapping);
+
+   for (i = 0; i < npages; i++) {
+   p = shmem_read_mapping_page_gfp(mapping, i, gfpmask);
+   if (IS_ERR(p))
+   goto fail;
+   pages[i] = p;
+   }
+
+   return pages;
+
+fail:
+   while (i--) {
+   page_cache_release(pages[i]);
+   }
+   drm_free_large(pages);
+   return ERR_PTR(PTR_ERR(p));
+}
+EXPORT_SYMBOL(drm_gem_get_pages);
+
+/**
+ * drm_gem_put_pages - helper to free backing pages for a GEM object
+ * @obj: obj in question
+ * @pages: pages to free
+ */
+void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
+   bool dirty, bool accessed)
+{
+   int i, npages;
+
+   npages = obj->size >> PAGE_SHIFT;
+
+   for (i = 0; i < npages; i++) {
+   if (dirty)
+   set_page_dirty(pages[i]);
+
+   if (accessed)
+   mark_page_accessed(pages[i]);
+
+   /* Undo the reference we took when populating the table */
+   page_cache_release(pages[i]);
+   }
+
+   drm_free_large(pages);
+}
+EXPORT_SYMBOL(drm_gem_put_pages);
 
 /**
  * drm_gem_free_mmap_offset - release a fake mmap offset for an object
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 43538b6..a62d8fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1624,6 +1624,9 @@ drm_gem_object_handle_unreference_unlocked(struct 
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
 }
 
+struct page ** drm_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
+void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
+   bool dirty, bool accessed);
 void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
 int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
 
-- 
1.7.5.4


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

[PATCH 3/6] drm/gma500: use common functions for mmap offset creation

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
Signed-off-by: Alan Cox 
---
 drivers/staging/gma500/gem.c  |2 +-
 drivers/staging/gma500/gem_glue.c |   61 +
 drivers/staging/gma500/gem_glue.h |1 -
 3 files changed, 2 insertions(+), 62 deletions(-)

diff --git a/drivers/staging/gma500/gem.c b/drivers/staging/gma500/gem.c
index 65fdd6b..1ac438a 100644
--- a/drivers/staging/gma500/gem.c
+++ b/drivers/staging/gma500/gem.c
@@ -77,7 +77,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct 
drm_device *dev,
 
/* Make it mmapable */
if (!obj->map_list.map) {
-   ret = gem_create_mmap_offset(obj);
+   ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
diff --git a/drivers/staging/gma500/gem_glue.c 
b/drivers/staging/gma500/gem_glue.c
index daac121..90e5f98 100644
--- a/drivers/staging/gma500/gem_glue.c
+++ b/drivers/staging/gma500/gem_glue.c
@@ -24,66 +24,7 @@ void drm_gem_object_release_wrap(struct drm_gem_object *obj)
 {
/* Remove the list map if one is present */
if (obj->map_list.map) {
-   struct drm_gem_mm *mm = obj->dev->mm_private;
-   struct drm_map_list *list = &obj->map_list;
-   drm_ht_remove_item(&mm->offset_hash, &list->hash);
-   drm_mm_put_block(list->file_offset_node);
-   kfree(list->map);
-   list->map = NULL;
+   drm_gem_free_mmap_offset(obj);
}
drm_gem_object_release(obj);
 }
-
-/**
- * gem_create_mmap_offset  -   invent an mmap offset
- * @obj: our object
- *
- * Standard implementation of offset generation for mmap as is
- * duplicated in several drivers. This belongs in GEM.
- */
-int gem_create_mmap_offset(struct drm_gem_object *obj)
-{
-   struct drm_device *dev = obj->dev;
-   struct drm_gem_mm *mm = dev->mm_private;
-   struct drm_map_list *list;
-   struct drm_local_map *map;
-   int ret;
-
-   list = &obj->map_list;
-   list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
-   if (list->map == NULL)
-   return -ENOMEM;
-   map = list->map;
-   map->type = _DRM_GEM;
-   map->size = obj->size;
-   map->handle = obj;
-
-   list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
-   obj->size / PAGE_SIZE, 0, 0);
-   if (!list->file_offset_node) {
-   dev_err(dev->dev, "failed to allocate offset for bo %d\n",
-   obj->name);
-   ret = -ENOSPC;
-   goto free_it;
-   }
-   list->file_offset_node = drm_mm_get_block(list->file_offset_node,
-   obj->size / PAGE_SIZE, 0);
-   if (!list->file_offset_node) {
-   ret = -ENOMEM;
-   goto free_it;
-   }
-   list->hash.key = list->file_offset_node->start;
-   ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
-   if (ret) {
-   dev_err(dev->dev, "failed to add to map hash\n");
-   goto free_mm;
-   }
-   return 0;
-
-free_mm:
-   drm_mm_put_block(list->file_offset_node);
-free_it:
-   kfree(list->map);
-   list->map = NULL;
-   return ret;
-}
diff --git a/drivers/staging/gma500/gem_glue.h 
b/drivers/staging/gma500/gem_glue.h
index ce5ce30..891b7b6 100644
--- a/drivers/staging/gma500/gem_glue.h
+++ b/drivers/staging/gma500/gem_glue.h
@@ -1,2 +1 @@
 extern void drm_gem_object_release_wrap(struct drm_gem_object *obj);
-extern int gem_create_mmap_offset(struct drm_gem_object *obj);
-- 
1.7.5.4


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

[PATCH 2/6] drm/i915: use common functions for mmap offset creation

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/i915_gem.c |   85 +--
 1 files changed, 2 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a546a71..ee59f31 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1265,74 +1265,6 @@ out:
 }
 
 /**
- * i915_gem_create_mmap_offset - create a fake mmap offset for an object
- * @obj: obj in question
- *
- * GEM memory mapping works by handing back to userspace a fake mmap offset
- * it can use in a subsequent mmap(2) call.  The DRM core code then looks
- * up the object based on the offset and sets up the various memory mapping
- * structures.
- *
- * This routine allocates and attaches a fake offset for @obj.
- */
-static int
-i915_gem_create_mmap_offset(struct drm_i915_gem_object *obj)
-{
-   struct drm_device *dev = obj->base.dev;
-   struct drm_gem_mm *mm = dev->mm_private;
-   struct drm_map_list *list;
-   struct drm_local_map *map;
-   int ret = 0;
-
-   /* Set the object up for mmap'ing */
-   list = &obj->base.map_list;
-   list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
-   if (!list->map)
-   return -ENOMEM;
-
-   map = list->map;
-   map->type = _DRM_GEM;
-   map->size = obj->base.size;
-   map->handle = obj;
-
-   /* Get a DRM GEM mmap offset allocated... */
-   list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
-   obj->base.size / PAGE_SIZE,
-   0, 0);
-   if (!list->file_offset_node) {
-   DRM_ERROR("failed to allocate offset for bo %d\n",
- obj->base.name);
-   ret = -ENOSPC;
-   goto out_free_list;
-   }
-
-   list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->base.size / PAGE_SIZE,
- 0);
-   if (!list->file_offset_node) {
-   ret = -ENOMEM;
-   goto out_free_list;
-   }
-
-   list->hash.key = list->file_offset_node->start;
-   ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
-   if (ret) {
-   DRM_ERROR("failed to add to map hash\n");
-   goto out_free_mm;
-   }
-
-   return 0;
-
-out_free_mm:
-   drm_mm_put_block(list->file_offset_node);
-out_free_list:
-   kfree(list->map);
-   list->map = NULL;
-
-   return ret;
-}
-
-/**
  * i915_gem_release_mmap - remove physical page mappings
  * @obj: obj in question
  *
@@ -1360,19 +1292,6 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
obj->fault_mappable = false;
 }
 
-static void
-i915_gem_free_mmap_offset(struct drm_i915_gem_object *obj)
-{
-   struct drm_device *dev = obj->base.dev;
-   struct drm_gem_mm *mm = dev->mm_private;
-   struct drm_map_list *list = &obj->base.map_list;
-
-   drm_ht_remove_item(&mm->offset_hash, &list->hash);
-   drm_mm_put_block(list->file_offset_node);
-   kfree(list->map);
-   list->map = NULL;
-}
-
 static uint32_t
 i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode)
 {
@@ -1485,7 +1404,7 @@ i915_gem_mmap_gtt(struct drm_file *file,
}
 
if (!obj->base.map_list.map) {
-   ret = i915_gem_create_mmap_offset(obj);
+   ret = drm_gem_create_mmap_offset(&obj->base);
if (ret)
goto out;
}
@@ -3752,7 +3671,7 @@ static void i915_gem_free_object_tail(struct 
drm_i915_gem_object *obj)
trace_i915_gem_object_destroy(obj);
 
if (obj->base.map_list.map)
-   i915_gem_free_mmap_offset(obj);
+   drm_gem_free_mmap_offset(&obj->base);
 
drm_gem_object_release(&obj->base);
i915_gem_info_remove_obj(dev_priv, obj->base.size);
-- 
1.7.5.4


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

[PATCH 1/6] drm/gem: add functions for mmap offset creation

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_gem.c |   88 +
 include/drm/drmP.h|3 ++
 2 files changed, 91 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 186d62e..396e60c 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -285,6 +285,94 @@ again:
 }
 EXPORT_SYMBOL(drm_gem_handle_create);
 
+
+/**
+ * drm_gem_free_mmap_offset - release a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ */
+void
+drm_gem_free_mmap_offset(struct drm_gem_object *obj)
+{
+   struct drm_device *dev = obj->dev;
+   struct drm_gem_mm *mm = dev->mm_private;
+   struct drm_map_list *list = &obj->map_list;
+
+   drm_ht_remove_item(&mm->offset_hash, &list->hash);
+   drm_mm_put_block(list->file_offset_node);
+   kfree(list->map);
+   list->map = NULL;
+}
+EXPORT_SYMBOL(drm_gem_free_mmap_offset);
+
+/**
+ * drm_gem_create_mmap_offset - create a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * GEM memory mapping works by handing back to userspace a fake mmap offset
+ * it can use in a subsequent mmap(2) call.  The DRM core code then looks
+ * up the object based on the offset and sets up the various memory mapping
+ * structures.
+ *
+ * This routine allocates and attaches a fake offset for @obj.
+ */
+int
+drm_gem_create_mmap_offset(struct drm_gem_object *obj)
+{
+   struct drm_device *dev = obj->dev;
+   struct drm_gem_mm *mm = dev->mm_private;
+   struct drm_map_list *list;
+   struct drm_local_map *map;
+   int ret = 0;
+
+   /* Set the object up for mmap'ing */
+   list = &obj->map_list;
+   list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
+   if (!list->map)
+   return -ENOMEM;
+
+   map = list->map;
+   map->type = _DRM_GEM;
+   map->size = obj->size;
+   map->handle = obj;
+
+   /* Get a DRM GEM mmap offset allocated... */
+   list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
+   obj->size / PAGE_SIZE, 0, 0);
+
+   if (!list->file_offset_node) {
+   DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
+   ret = -ENOSPC;
+   goto out_free_list;
+   }
+
+   list->file_offset_node = drm_mm_get_block(list->file_offset_node,
+   obj->size / PAGE_SIZE, 0);
+   if (!list->file_offset_node) {
+   ret = -ENOMEM;
+   goto out_free_list;
+   }
+
+   list->hash.key = list->file_offset_node->start;
+   ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
+   if (ret) {
+   DRM_ERROR("failed to add to map hash\n");
+   goto out_free_mm;
+   }
+
+   return 0;
+
+out_free_mm:
+   drm_mm_put_block(list->file_offset_node);
+out_free_list:
+   kfree(list->map);
+   list->map = NULL;
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_gem_create_mmap_offset);
+
 /** Returns a reference to the object named by the handle. */
 struct drm_gem_object *
 drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b7c2bb..43538b6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1624,6 +1624,9 @@ drm_gem_object_handle_unreference_unlocked(struct 
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
 }
 
+void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
+int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
+
 struct drm_gem_object *drm_gem_object_lookup(struct drm_device *dev,
 struct drm_file *filp,
 u32 handle);
-- 
1.7.5.4


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

[PATCH 6/6] drm/gma500: use common functions for get/put pages

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/staging/gma500/gtt.c |   47 ++---
 1 files changed, 12 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/gma500/gtt.c b/drivers/staging/gma500/gtt.c
index 461ead2..f453321 100644
--- a/drivers/staging/gma500/gtt.c
+++ b/drivers/staging/gma500/gtt.c
@@ -140,39 +140,21 @@ static void psb_gtt_remove(struct drm_device *dev, struct 
gtt_range *r)
  */
 static int psb_gtt_attach_pages(struct gtt_range *gt)
 {
-   struct inode *inode;
-   struct address_space *mapping;
-   int i;
-   struct page *p;
-   int pages = gt->gem.size / PAGE_SIZE;
+   struct page **pages;
 
WARN_ON(gt->pages);
 
-   /* This is the shared memory object that backs the GEM resource */
-   inode = gt->gem.filp->f_path.dentry->d_inode;
-   mapping = inode->i_mapping;
-
-   gt->pages = kmalloc(pages * sizeof(struct page *), GFP_KERNEL);
-   if (gt->pages == NULL)
-   return -ENOMEM;
-   gt->npage = pages;
-
-   for (i = 0; i < pages; i++) {
-   /* FIXME: review flags later */
-   p = read_cache_page_gfp(mapping, i,
-   __GFP_COLD | GFP_KERNEL);
-   if (IS_ERR(p))
-   goto err;
-   gt->pages[i] = p;
+   /* FIXME: review flags later */
+   pages = drm_gem_get_pages(>->gem,
+   __GFP_DMA32 | __GFP_COLD | GFP_KERNEL);
+   if (IS_ERR(pages)) {
+   dev_err(gt->gem.dev->dev, "could not get pages: %ld\n",
+   PTR_ERR(pages));
+   return PTR_ERR(pages);
}
-   return 0;
 
-err:
-   while (i--)
-   page_cache_release(gt->pages[i]);
-   kfree(gt->pages);
-   gt->pages = NULL;
-   return PTR_ERR(p);
+   gt->pages = pages;
+   return 0;
 }
 
 /**
@@ -185,13 +167,8 @@ err:
  */
 static void psb_gtt_detach_pages(struct gtt_range *gt)
 {
-   int i;
-   for (i = 0; i < gt->npage; i++) {
-   /* FIXME: do we need to force dirty */
-   set_page_dirty(gt->pages[i]);
-   page_cache_release(gt->pages[i]);
-   }
-   kfree(gt->pages);
+   /* FIXME: do we need to force dirty */
+   drm_gem_put_pages(>->gem, gt->pages, true, false);
gt->pages = NULL;
 }
 
-- 
1.7.5.4


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

Bootchart results

[Paul Larson]

I started working on a results view in LAVA for the bootchart results since
they are now part of the daily runs.  This is using a partial copy of the
data I have locally, so please don't concern yourself too much with the
actual data in it.  A couple of things to point out:

1. legend is not placed well, that's something I'm not yet sure how to fix
as my javascript-fu is lacking here (zyga, any ideas on this?)
2. The set of results here is not very large.  That's adjustable and when
it's using live data, should have a lot more data points to better see
trends
3. This is purposefully restricted to a single board.  We are not running
benchmarks in a controlled enough manner as to make comparison of boards to
one another reasonable, nor is it encouraged due to the collaborative nature
of Linaro.

In particular I'm looking for opinions on how it would be most useful to
display this data.  This view shows all 4 image types on a single chart.  I
did a previous version that had them separate.  Is there a preference? It
would also be easy to do both on the same page, but perhaps a bit redundant.

Thanks,
Paul Larson
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Internal License for PyCharm available

[Zygmunt Krynicki]

W dniu 12.09.2011 15:56, James Tunnicliffe pisze:

On 12 September 2011 13:27, Zygmunt Krynicki
  wrote:

W dniu 12.09.2011 13:31, James Tunnicliffe pisze:


On 12 September 2011 12:17, Zygmunt Krynicki
wrote:


W dniu 12.09.2011 12:49, James Tunnicliffe pisze:


Hi,

If you are a Python developer you are now able to use the commercial
IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer.
Since the license is for Linaro engineers only I have put it on the
internal wiki at https://wiki.linaro.org/Internal/Licenses.


I just tried to use this license but apparently something is not right.
Perhaps there is a typo in the license or it has to be formatted in a
certain way.

Could you double-check how the license looks like in your registration
window?


In my registration window I have the user name Linaro and the license
key exactly as shown on the wiki page (the bit in the {{{code}}}
block).


I got that, I also fixed the wiki to use proper formatting for the license.


Odd. I take it that you don't have it working still? I checked the
license code against what was in the wiki and it is identical.


I got it working now. The devil is in the details as they say. The 
license needs to be split into multiple lines to work correctly. If you 
just copy-paste from the wiki page it used to be bad (the source of the 
wiki page was correct though).





Out of curiosity, did you use the django-related features of pycharm yet?


A little. It will do nice things like restart the dev server when you
save a python file, but I haven't done much django development.


Django does that by itself.

I would like to know how it works for you if you continue to use it. 
Let's stay in touch.


Thanks
ZK


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

Code Review for enabling wifi for Pandaboard

[Vishal Bhoj]

Hello All,

These are the changes to enable wifi on Pandaboard.Please review them.

http://review.android.git.linaro.org/#change,175
This enables wpa_supplicant build for pandaboard adds wpa_supplicant.conf
file for Pandaboard.
http://review.android.git.linaro.org/#change,176
This change was necessary since ctrl_interface as getting created after wifi
service tried to access it.
http://review.android.git.linaro.org/#change,178
This  patch has been derived from
https://gitorious.org/picopc-android-gingerbread/external-wpa_supplicant_6/commit/5f5c50d722eedaedd75c1698b79f464310ce6478?format=patch.
The change to wpa_supplicant was necessary because android uses a modified
wpa_supplicant and wext calls implemented actually uses IOCTL "SIOCSIWPRIV"
which is not implemented in the standard wifi drivers.The patch is a
workaround to get wifi working on panda .I have tested the change and works
on panda BUT I am not sure if the devices using the original implementation
still work.

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

Re: [PATCH] ARM: EXYNOS4: Setup consistent dma size at boot time

[Subash Patel]

Hi Tushar,

On 09/12/2011 11:25 AM, Tushar Behera wrote:

Some of the boards under mach-exynos4 initialize frame-buffers
for which the memory requirement is more than 2MB (Nuri board requires
around 4MB, Origen requires around 2.6MB), hence the default dma pool
allocation size of 2MB is not sufficient. The consistent dma size is
hence increased to successfully allocate memory for those boards.

Depends on "ARM: Add init_consistent_dma_size()"
by Jon Medhurst (99d1717dd7fecf2b10195b0d864323b952b4eba0).

CC: Jon Medhurst
Signed-off-by: Tushar Behera
---
  arch/arm/mach-exynos4/cpu.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..45d8bfa 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,7 @@

  #include
  #include
+#include

  #include
  #include
@@ -136,6 +137,7 @@ static void exynos4_idle(void)
  void __init exynos4_map_io(void)
  {
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+   init_consistent_dma_size(SZ_8M);



I think CMA is being used to allocate the FB in origen machine. In that 
case, increasing the consistent memory is not useful. If the memory is 
increased in the consistent DMA area, how can that be useful to s3cfb?


Regards,
Subash



/* initialize device information early */
exynos4_default_sdhci0();


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

people summaries broken on status.linaro.org

[Dave Martin]

Hi all,

I don't remember off the top of my head who maintains status.linaro.org,
but the people summaries don't seem to be working for me:

http://status.linaro.org/11.11/people.html

I just get a page with the following.

Cheers
---Dave


People

These are all of the people. Click on any to see their progress towards 
completing their tasks for the cycle.

No people!

Last updated: Mon 12 September 2011, 08:30 UTC | Bugs | Code | Config | Update 
log (yesterday) 


Maybe this from the update log is a clue:

Finished at Mon Sep 12 08:30:04 UTC 2011
Traceback (most recent call last):
  File "./json-report", line 58, in 
store, config, opts.team, opts.milestone)
  File "/srv/status.linaro.org/work-items-tracker/report_tools.py", line 789, 
in spec_information
for d in result.description:
AttributeError: 'SQLiteResult' object has no attribute 'description'

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

Re: [PATCH 2/2] mmc: mmci: simplify err check in mmci_post_request

[Linus Walleij]

On Mon, Aug 29, 2011 at 3:35 PM, Per Forlin  wrote:

> The error condition indicates that mmci_post_request() should cleanup
> after the mmci_pre_request(). In this case the resources allocated by
> device_prep_slave_sg() are freed by calling dmaengine_terminate_all().
> dma_unmap_sg() should always be performed if the host_cookie is set.
>
> Signed-off-by: Per Forlin 

Acked-by: Linus Walleij 

Thanks,
Linus Walleij

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

Re: [PATCH 1/2] mmc: core: clarify how to use post_req in case of errors

[Linus Walleij]

On Mon, Aug 29, 2011 at 3:35 PM, Per Forlin  wrote:

> The err condition in post_req() is set to undo a call made
> to pre_req() that hasn't been started yet.
> The err condition is not set if an MMC request returns error.
>
> Signed-off-by: Per Forlin 

Comments look correct so:
Acked-by: Linus Walleij 

Thanks,
Linus Walleij

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

Re: Internal License for PyCharm available

[James Tunnicliffe]

On 12 September 2011 13:27, Zygmunt Krynicki
 wrote:
> W dniu 12.09.2011 13:31, James Tunnicliffe pisze:
>>
>> On 12 September 2011 12:17, Zygmunt Krynicki
>>   wrote:
>>>
>>> W dniu 12.09.2011 12:49, James Tunnicliffe pisze:

 Hi,

 If you are a Python developer you are now able to use the commercial
 IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer.
 Since the license is for Linaro engineers only I have put it on the
 internal wiki at https://wiki.linaro.org/Internal/Licenses.
>>>
>>> I just tried to use this license but apparently something is not right.
>>> Perhaps there is a typo in the license or it has to be formatted in a
>>> certain way.
>>>
>>> Could you double-check how the license looks like in your registration
>>> window?
>>
>> In my registration window I have the user name Linaro and the license
>> key exactly as shown on the wiki page (the bit in the {{{code}}}
>> block).
>
> I got that, I also fixed the wiki to use proper formatting for the license.

Odd. I take it that you don't have it working still? I checked the
license code against what was in the wiki and it is identical.

> Out of curiosity, did you use the django-related features of pycharm yet?

A little. It will do nice things like restart the dev server when you
save a python file, but I haven't done much django development.

-- 
James Tunnicliffe

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

[NOTES] DevPlatform Meeting 2011-09-08

[David Zinman]

Enclosed, please find a link to the agenda, notes and actions from the
weekly Developer Platform meeting held on September 8th in #linaro-meeting
on irc.freenode.net at 14:00 UTC.

== Meeting Minutes ==

https://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-09-08

== Meeting Log ==

http://irclogs.linaro.org/meeting-logs/linaro-meeting/2011/linaro-meeting.2011-09-08-14.02.log.html

== Agenda ==

* Highlights - Tech Lead

Staging PPA available at
https://launchpad.net/~linaro-maintainers/+archive/staging-overlay
- Just waiting to get it devirtualized
Launchpad Daily Builds and Rapid Feedback: Writing Recipe Builds -
Jelmer Vernooij
-
https://wiki.ubuntu.com/MeetingLogs/appdevweek1109/LaunchpadDailyBuildsRapidFeedback
Team Reviews
* Actions from last meeting - Tech Lead chasing
* Bugs and image issues - All team members
Go over 11.09 targeted bugs, make sure all are at least assigned to
someone
* 11.09 Planning Status and Blueprint Review
http://launchpad.net/linaro-ubuntu/+milestone/11.09
http://wiki.linaro.org/Cycles/1109/Release/Blueprints
* Any Other Business (AOB)

== Past Action items ==

* dzin to follow up with fabo, rsalveti and asac to come with a plan to
improve the communication with the LTs and WGs - INPROGRESS
* fabo to answer jcrigby question: when is mx53 going to become
"supported"? - DONE
* everybody, make sure the tickets are in place for connect Q4.11/UDS-P
- INPROGRESS
* canonicals: make sure to register at linaro connect instead of UDS-P -
DONE
* rsalveti to discuss with suihkulokki and jcrigby about the headline
and acceptance criteria of the upstream related blueprints. - INPROGRESS

* Bugs and image issues
  * LINK: https://offspring.linaro.org/ looks good

* 11.09 Planning Status and Blueprint Review  (rsalveti, 14:32:11)
  * LINK: http://launchpad.net/linaro-ubuntu/+milestone/11.09
(rsalveti, 14:32:30)
  * LINK: http://wiki.linaro.org/Cycles/1109/Release/Blueprints
(rsalveti, 14:32:39)
  * LINK: https://wiki.linaro.org/Cycles/1109/Release/Blueprints
  (dzin,
14:38:49)
  * ACTION: rsalveti to make sure all 11.09 bps have proper
headline/acceptance  (rsalveti, 14:39:08)
  * LINK: https://bugs.launchpad.net/ubuntu/+source/xdeb/+bug/731079 is
now fixed  (wookey, 14:59:34)

== Action items ==

* rsalveti
  * rsalveti to make sure all 11.09 bps have proper headline/acceptance

== People present (lines said) ==

* rsalveti (152)
* jcrigby (34)
* wookey (27)
* fabo (21)
* hrw (15)
* aviksil (14)
* tgall_foo (9)
* dzin (7)
* suihkulokki (6)
* ubot2` (6)
* linarobot (4)
* plars (1)

-- 
David Zinman
Linaro Release Manager | Platform Project Manager
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: Internal License for PyCharm available

[Zygmunt Krynicki]

W dniu 12.09.2011 13:31, James Tunnicliffe pisze:

On 12 September 2011 12:17, Zygmunt Krynicki
  wrote:

W dniu 12.09.2011 12:49, James Tunnicliffe pisze:


Hi,

If you are a Python developer you are now able to use the commercial
IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer.
Since the license is for Linaro engineers only I have put it on the
internal wiki at https://wiki.linaro.org/Internal/Licenses.


I just tried to use this license but apparently something is not right.
Perhaps there is a typo in the license or it has to be formatted in a
certain way.

Could you double-check how the license looks like in your registration
window?


In my registration window I have the user name Linaro and the license
key exactly as shown on the wiki page (the bit in the {{{code}}}
block).


I got that, I also fixed the wiki to use proper formatting for the license.

Out of curiosity, did you use the django-related features of pycharm yet?

Thanks
ZK


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

Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Zach Pfeffer]

On 12 September 2011 06:36, Loïc Minier  wrote:
> On Mon, Sep 12, 2011, Zach Pfeffer wrote:
>> I think stage is okay. Its short for staging which is used in the
>> kernel as a place for things which aren't mainline.
>> If I hear of any other issues with the name I'll think we can
>> reevaluate it, but overall I think the term stage is okay.
>
>  Sorry for the bikeshedding.  "staging" or "staged" would in my eyes be
>  much clearer than "stage".

How about staging?

To keep the build linage I'll keep the current names for the 11.09 release.

> --
> Loďc Minier
>

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

Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Loïc Minier]

On Mon, Sep 12, 2011, Zach Pfeffer wrote:
> I think stage is okay. Its short for staging which is used in the
> kernel as a place for things which aren't mainline.
> If I hear of any other issues with the name I'll think we can
> reevaluate it, but overall I think the term stage is okay.

 Sorry for the bikeshedding.  "staging" or "staged" would in my eyes be
 much clearer than "stage".

-- 
Loïc Minier

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

Re: Internal License for PyCharm available

[James Tunnicliffe]

On 12 September 2011 12:17, Zygmunt Krynicki
 wrote:
> W dniu 12.09.2011 12:49, James Tunnicliffe pisze:
>>
>> Hi,
>>
>> If you are a Python developer you are now able to use the commercial
>> IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer.
>> Since the license is for Linaro engineers only I have put it on the
>> internal wiki at https://wiki.linaro.org/Internal/Licenses.
>
> I just tried to use this license but apparently something is not right.
> Perhaps there is a typo in the license or it has to be formatted in a
> certain way.
>
> Could you double-check how the license looks like in your registration
> window?

In my registration window I have the user name Linaro and the license
key exactly as shown on the wiki page (the bit in the {{{code}}}
block).

-- 
James Tunnicliffe

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

Re: Internal License for PyCharm available

[Zygmunt Krynicki]

W dniu 12.09.2011 12:49, James Tunnicliffe pisze:

Hi,

If you are a Python developer you are now able to use the commercial
IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer.
Since the license is for Linaro engineers only I have put it on the
internal wiki at https://wiki.linaro.org/Internal/Licenses.


I just tried to use this license but apparently something is not right.
Perhaps there is a typo in the license or it has to be formatted in a 
certain way.


Could you double-check how the license looks like in your registration 
window?


Thanks
ZK


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

Re: [PATCH v4] ASoC: omap: convert per-board modules to platform drivers

[Mark Brown]

On Sun, Sep 11, 2011 at 11:57:32AM +0100, Mans Rullgard wrote:
> This converts the per-board modules to platform drivers for a
> device created by in main platform setup.  These drivers call
> snd_soc_register_card() directly instead of going via a "soc-audio"
> device and the corresponding driver in soc-core.
> 
> Signed-off-by: Mans Rullgard 

Acked-by: Mark Brown 

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

Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Zach Pfeffer]

On 12 September 2011 06:00, Alexander Sack  wrote:
> On Fri, Sep 9, 2011 at 7:34 PM, Christian Robottom Reis 
> wrote:
>>
>> On Fri, Sep 09, 2011 at 12:09:55PM -0500, Zach Pfeffer wrote:
>> > The term "Stage" is used to indicate builds that contain patches that
>> > haven't been upstreamed.
>>
>> That a pretty confusing term. Are we sure we want to call it that?
>
> This comes out of me complaining to android team that they titled everything
> that didn't use mainline kernel as "LEB", no matter how well that worked, no
> matter what level of hardware enablement those builds came with, no matter
> if those builds are booting to UI or not.
>
> To avoid that we said that the technical/functional build name shouldn't
> include the term leb at all, but rather mark those builds as non-mainline in
> a different way. The term LEB would then become a badge (think about
> certification) that gets awarded by release team for builds _after_ they
> have gone through validation/testing and have been officially confirmed to
> meet LEB requirements.
>
> That said, I don't like the name "Stage" much either. Idea: How about we
> mark the ones that are not "stage" as "mainline" and drop the "stage" marker
> from the other build names?

I think stage is okay. Its short for staging which is used in the
kernel as a place for things which aren't mainline.

If I hear of any other issues with the name I'll think we can
reevaluate it, but overall I think the term stage is okay. Plus, we
should call out the builds that aren't mainline, since they should be
the exception and not the rule.

> --
>
>  - Alexander
>
> 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: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball

[Alexander Sack]

On Fri, Sep 9, 2011 at 7:34 PM, Christian Robottom Reis wrote:

> On Fri, Sep 09, 2011 at 12:09:55PM -0500, Zach Pfeffer wrote:
> > The term "Stage" is used to indicate builds that contain patches that
> > haven't been upstreamed.
>
> That a pretty confusing term. Are we sure we want to call it that?
>

This comes out of me complaining to android team that they titled everything
that didn't use mainline kernel as "LEB", no matter how well that worked, no
matter what level of hardware enablement those builds came with, no matter
if those builds are booting to UI or not.

To avoid that we said that the technical/functional build name shouldn't
include the term leb at all, but rather mark those builds as non-mainline in
a different way. The term LEB would then become a badge (think about
certification) that gets awarded by release team for builds _after_ they
have gone through validation/testing and have been officially confirmed to
meet LEB requirements.

That said, I don't like the name "Stage" much either. Idea: How about we
mark the ones that are not "stage" as "mainline" and drop the "stage" marker
from the other build names?

-- 

 - Alexander

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

Internal License for PyCharm available

[James Tunnicliffe]

Hi,

If you are a Python developer you are now able to use the commercial
IDE PyCharm (http://www.jetbrains.com/pycharm/) as a Linaro engineer.
Since the license is for Linaro engineers only I have put it on the
internal wiki at https://wiki.linaro.org/Internal/Licenses.

Enjoy,

-- 
James Tunnicliffe

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

Re: [PATCH] mmc: omap_hsmmc: DMA unmap only once in case of MMC error

[Per Forlin]

On 1 September 2011 21:19, S, Venkatraman  wrote:
> On Mon, Aug 29, 2011 at 3:38 AM, Per Forlin  wrote:
>> Reported by Russell King:
>> 
>> mmcblk0: error -84 transferring data, sector 149201, nr 64,
>> cmd response 0x900, card status 0xb00
>> mmcblk0: retrying using single block read
>>
>> WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811 check_unmap
>> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
>> it has not allocated [device address=0x80933000] [size=20480 bytes]
>> -
>>
>> In case of an error dma_unmap() is issued in omap_hsmmc_dma_cleanup()
>> and then again in omap_hsmmc_post_req(). Resolve this by clearing the
>> host_cookie to indicate there is no DMA mapped memory to unmap.
>>
>> Signed-off-by: Per Forlin 
>> ---
>> Bug fix on 3.1-rc3
>>
>>  drivers/mmc/host/omap_hsmmc.c |    7 +--
>>  1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 21e4a79..31d9817 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct 
>> omap_hsmmc_host *host, int errno)
>>                        host->data->sg_len,
>>                        omap_hsmmc_get_dma_dir(host, host->data));
>>                omap_free_dma(dma_ch);
>> +               host->data->host_cookie = 0;
>>        }
>>        host->data = NULL;
>>  }
>> @@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host *mmc, 
>> struct mmc_request *mrq,
>>        struct mmc_data *data = mrq->data;
>>
>>        if (host->use_dma) {
>> -               dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
>> -                            omap_hsmmc_get_dma_dir(host, data));
>> +               if (data->host_cookie)
>> +                       dma_unmap_sg(mmc_dev(host->mmc), data->sg,
>> +                                    data->sg_len,
>> +                                    omap_hsmmc_get_dma_dir(host, data));
>>                data->host_cookie = 0;
>>        }
>>  }
>> --
>> 1.7.4.1
>>
>>
>
> I just posted a patch [1] which just consolidates all unmapping to
> just post_req.
> This would obviously prevent double unmapping, and keeps all the related
> dma operations at a single place. Let me know if that works better.
>
I'm in favour of such patch. My patch only tries to do the minimal bug fix.
I have been out of office the last 10 days or so. I'll look at your
patch later today.

Thanks,
Per

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

Re: Linaro Boot up times.

[Loïc Minier]

On Mon, Sep 12, 2011, Sudhangathan B S wrote:
> Is there a way to boot up Linaro in under 40 sec. ?? This could include
> increasing CPU speeds or more OS tweaks

 There are plenty of ways to improve boot, the most effective way being
 to remove things you don't need (e.g. not starting services you wont
 use, not building features in your kernel that you don't need etc.).
 So it's extremely specific to one's own view of what can be removed and
 what should be kept.

-- 
Loïc Minier

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

Re: [Samsung] [PATCH] ORIGEN : enable device tree support

[Chander Kashyap]

Dear Angus,

On 10 September 2011 03:32,   wrote:
> From: Angus Ainslie 
>
> Enable passing a flattened device tree to the kernel.
>
> Signed-off-by: Angus Ainslie 
Acked-by: Chander Kashyap 
> ---
>  include/configs/origen.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/origen.h b/include/configs/origen.h
> index 889d5fc..380ef4f 100644
> --- a/include/configs/origen.h
> +++ b/include/configs/origen.h
> @@ -165,4 +165,7 @@
>  #define COPY_BL2_SIZE          0x8
>  #define BL2_START_OFFSET       ((CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)/512)
>  #define BL2_SIZE_BLOC_COUNT    (COPY_BL2_SIZE/512)
> +
> +/* Enable devicetree support */
> +#define CONFIG_OF_LIBFDT
>  #endif /* __CONFIG_H */
> --
> 1.7.4.1
>
>
> ___
> Samsung mailing list
> sams...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/samsung
>



-- 
with warm regards,
Chander Kashyap

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