date:20110504

Re: [PATCH] sdio: optimized SDIO IRQ handling for single function

2011-05-04 Thread Per Forlin

On 4 May 2011 05:40, Nicolas Pitre  wrote:
> On Tue, 3 May 2011, Per Forlin wrote:
>
>> From: Stefan Nilsson XK 
>>
>> If there is only 1 function registered, and IRQ:s are supported and
>> currently enabled, call the callback handler directly
>> without checking the CCCR registers.
>>
>> Signed-off-by: Stefan Nilsson XK 
>> Signed-off-by: Per Forlin 
>
> Acked-by: Nicolas Pitre 
>
I am working o a patch version 2 after offline discussion with Ulf Hansson.
Instead of adding this code here.
Add sdio_single_func member in mmc_card. Set and reset this function
in sdio_claim_irq and sdio_release_irq.
process_sdio_pending_irqs would only check if sdio_single_func is !=
null and call it.

This will result in a bigger patch overall but the new code in
process_sdio_pending_irqs will be minimal.

>> ---
>>  drivers/mmc/core/sdio_irq.c |   14 ++
>>  1 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
>> index b300161..25291bf 100644
>> --- a/drivers/mmc/core/sdio_irq.c
>> +++ b/drivers/mmc/core/sdio_irq.c
>> @@ -32,6 +32,20 @@ static int process_sdio_pending_irqs(struct mmc_card 
>> *card)
>>       int i, ret, count;
>>       unsigned char pending;
>>
>> +     /*
>> +      * If there is only 1 function registered
>> +      * call irq directly without checking the CCCR registers.
>> +      */
>> +     if ((card->host->caps & MMC_CAP_SDIO_IRQ) &&

>> +         card->host->sdio_irqs && (card->sdio_funcs == 1))
>> +             for (i = 0; i < SDIO_MAX_FUNCS; i++) {
Minor adjustments.
card->sdio_funcs may be > 1 but still only one irq is registered.
No need to iterate more than "sdio_funcs" number of elements.
+ card->host->sdio_irqs == 1)
+ for (i = 0; i < card->sdio_funcs; i++) {

>> +                     struct sdio_func *func = card->sdio_func[i];
>> +                     if (func && func->irq_handler) {
>> +                             func->irq_handler(func);
>> +                             return 1;
>> +                     }
>> +             }
>> +
>>       ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
>>       if (ret) {
>>               printk(KERN_DEBUG "%s: error %d reading SDIO_CCCR_INTx\n",
>> --
>> 1.7.4.1
>>
>>
>> ___
>> 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

[NOTES] 2011-05-04 Android Platform Team Meeting

2011-05-04 Thread Zach Pfeffer

Agenda, action items, status reports and IRC logs at:

https://wiki.linaro.org/Platform/Android/Meetings/2011-05-04

Highlights

Linaro Android 11.04 release @ https://android-build.linaro.org/index

-Zach

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

[PM] 04/05/2011 - Minutes for the Power Management WG weekly call

2011-05-04 Thread Amit Kucheria

Hi All,

The minutes of the very short power management weekly call can be found at :

https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-05-04

Highlights: 11.11 planning

Regards,
Amit

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

Prebuilt images

2011-05-04 Thread Guilherme Salgado

Hi there,

Several people have suggested that we should start providing prebuilt
Linaro images for those who can't/won't install and run
linaro-media-create (or any other tool that they have to install in
order to generate an image), so we're going to discuss that at LDS.  If
you know of anybody who can't/won't install l-m-c, I'd like to know more
about it, so I'd appreciate if you could answer the questions or provide
us with some user stories: 

  https://wiki.linaro.org/Platform/Infrastructure/Specs/PrebuiltImages

And if you're interested on this, don't forget to subscribe to

  
https://blueprints.launchpad.net/linaro/+spec/linaro-platforms-o-prebuilt-images

Cheers,

-- 
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: Prebuilt images

2011-05-04 Thread Robert Nelson

On Wed, May 4, 2011 at 9:22 AM, Guilherme Salgado
 wrote:
> Hi there,
>
> Several people have suggested that we should start providing prebuilt
> Linaro images for those who can't/won't install and run
> linaro-media-create (or any other tool that they have to install in
> order to generate an image), so we're going to discuss that at LDS.  If
> you know of anybody who can't/won't install l-m-c, I'd like to know more
> about it, so I'd appreciate if you could answer the questions or provide
> us with some user stories:
>
>  https://wiki.linaro.org/Platform/Infrastructure/Specs/PrebuiltImages

Why can't you guys ship the script within the generic image? Then the
user doesn't have to install anything external, and it can run on more
platforms then just the latest Ubuntu 11.x.

I know it's been completely rewritten so it's hard to compare directly
anymore to my script, but my script currently supports generating sd
cards in ubuntu/debian/fedora/gentoo (well those are atleast tested..)

https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: Would you like remotely accessible boards?

2011-05-04 Thread Michael Hope

On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
 wrote:
> If you do, I need to know more about how you'd like to use them, to make
> sure we provide something that is suitable to everyone.
>
> At this point I'm interested in drafting some user stories so if you
> have any, please do add them to the RemoteDevelopmentBoards[1] wiki
> page. Also, if you'd like to participate in the discussion at LDS, don't
> forget to subscribe to the blueprint[2] on Launchpad.

Hi Guilherme.  We currently have a Versatile Express and three
PandaBoards in the London data centre:
 https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware

There's also a bunch of hardware in my home office that is slowly
being replaced by the data centre boxes.

These are set up as porter boxes.  Toolchain people are a bit unique
as we're very much an end user: a board which is reliable and
consistent is more important than the latest and greatest.  They're
used for building GCC (~5 hours), testing it (~7 hours), building
packages, debugging, and all the usuals.

One tricky thing is benchmarking.  If you run a benchmark you want the
same environment as last time and some type of exclusive access.  The
environment can change over time as these are generally development
benchmarks so you can run a baseline first.

-- Michael
-- Michael

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

Re: [PATCH] sdio: optimized SDIO IRQ handling for single function

2011-05-04 Thread Nicolas Pitre

On Wed, 4 May 2011, Per Forlin wrote:

> On 4 May 2011 05:40, Nicolas Pitre  wrote:
> > On Tue, 3 May 2011, Per Forlin wrote:
> >
> >> From: Stefan Nilsson XK 
> >>
> >> If there is only 1 function registered, and IRQ:s are supported and
> >> currently enabled, call the callback handler directly
> >> without checking the CCCR registers.
> >>
> >> Signed-off-by: Stefan Nilsson XK 
> >> Signed-off-by: Per Forlin 
> >
> > Acked-by: Nicolas Pitre 
> >
> I am working o a patch version 2 after offline discussion with Ulf Hansson.
> Instead of adding this code here.
> Add sdio_single_func member in mmc_card. Set and reset this function
> in sdio_claim_irq and sdio_release_irq.
> process_sdio_pending_irqs would only check if sdio_single_func is !=
> null and call it.

Yes, that's what I was about to propose after thinking about it some 
more.

> This will result in a bigger patch overall but the new code in
> process_sdio_pending_irqs will be minimal.

Something like this (untested) ?

diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index b300161..4552727 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -32,6 +32,12 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
int i, ret, count;
unsigned char pending;
 
+   if (card->sdio_single_irq) {
+   struct sdio_func *func = card->sdio_single_irq;
+   func->irq_handler(func);
+   return 1;
+   }
+
ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
if (ret) {
printk(KERN_DEBUG "%s: error %d reading SDIO_CCCR_INTx\n",
@@ -166,6 +172,7 @@ static int sdio_card_irq_get(struct mmc_card *card)
host->sdio_irqs--;
return err;
}
+   return 1;
}
 
return 0;
@@ -183,7 +190,7 @@ static int sdio_card_irq_put(struct mmc_card *card)
kthread_stop(host->sdio_irq_thread);
}
 
-   return 0;
+   return (host->sdio_irqs == 1);
 }
 
 /**
@@ -225,8 +232,12 @@ int sdio_claim_irq(struct sdio_func *func, 
sdio_irq_handler_t *handler)
 
func->irq_handler = handler;
ret = sdio_card_irq_get(func->card);
-   if (ret)
+   if (ret < 0) {
func->irq_handler = NULL;
+   } else if (ret == 1) {
+   card->sdio_single_irq = func;
+   ret = 0;
+   }
 
return ret;
 }
@@ -250,7 +261,17 @@ int sdio_release_irq(struct sdio_func *func)
 
if (func->irq_handler) {
func->irq_handler = NULL;
-   sdio_card_irq_put(func->card);
+   if (sdio_card_irq_put(func->card) == 1) {
+   int i;
+   for (i = 0, i < 7; i++) {
+   if (func->card->sdio_func[i].irq_handler) {
+   func->card->sdio_single_irq =
+   func->card->sdio_func[i];
+   break;
+   }
+   }
+   } else
+   func->card->sdio_single_irq = NULL;
}
 
ret = mmc_io_rw_direct(func->card, 0, 0, SDIO_CCCR_IENx, 0, ®);
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index adb4888..fee3df3 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -145,6 +145,7 @@ struct mmc_card {
struct sdio_cccrcccr;   /* common card info */
struct sdio_cis cis;/* common tuple info */
struct sdio_func*sdio_func[SDIO_MAX_FUNCS]; /* SDIO functions 
(devices) */
+   struct sdio_func*sdio_single_irq;   /* SDIO 
function when only one IRQ active */
unsignednum_info;   /* number of info strings */
const char  **info; /* info strings */
struct sdio_func_tuple  *tuples;/* unknown common tuples */


Nicolas

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

Re: [PATCH] sdio: optimized SDIO IRQ handling for single function

2011-05-04 Thread Per Forlin

On 4 May 2011 17:20, Nicolas Pitre  wrote:
> On Wed, 4 May 2011, Per Forlin wrote:
>
>> On 4 May 2011 05:40, Nicolas Pitre  wrote:
>> > On Tue, 3 May 2011, Per Forlin wrote:
>> >
>> >> From: Stefan Nilsson XK 
>> >>
>> >> If there is only 1 function registered, and IRQ:s are supported and
>> >> currently enabled, call the callback handler directly
>> >> without checking the CCCR registers.
>> >>
>> >> Signed-off-by: Stefan Nilsson XK 
>> >> Signed-off-by: Per Forlin 
>> >
>> > Acked-by: Nicolas Pitre 
>> >
>> I am working o a patch version 2 after offline discussion with Ulf Hansson.
>> Instead of adding this code here.
>> Add sdio_single_func member in mmc_card. Set and reset this function
>> in sdio_claim_irq and sdio_release_irq.
>> process_sdio_pending_irqs would only check if sdio_single_func is !=
>> null and call it.
>
> Yes, that's what I was about to propose after thinking about it some
> more.
>
>> This will result in a bigger patch overall but the new code in
>> process_sdio_pending_irqs will be minimal.
>
> Something like this (untested) ?
>
What I had in mind is similar. Please let me know what you think. I am
about to post "patch v2"

Regards,
Per

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

Re: CALL FOR TESTING: proposed enhancements for OMAP4

2011-05-04 Thread John Rigby

Thanks to Ricardo I have created a packaged version of a merge of the
master and testing branches.

http://git.linaro.org/gitweb?p=people/jcrigby/linux-linaro-packaged-next-wip.git

the bare kernel plus some fixes are in the "panda_no_packaging" the
"master" branch has normal packaging added.

It currently has no video on omap3.

John


On Wed, Apr 27, 2011 at 8:42 AM, Nicolas Pitre  wrote:
> On Wed, 27 Apr 2011, John Rigby wrote:
>
>> Is the plan to include the "testing" branch for this cycle?
>
> I'd like to have confirmation that it doesn't break OMAP3 first.  The
> OMAP4 support in that branch comes from sources that have expressed in
> the past that OMAP3 could be broken as a result.
>
>
> Nicolas
>

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

[PATCH v2] sdio: optimized SDIO IRQ handling for single irq

2011-05-04 Thread Per Forlin

Optimize performance for single irq

Changes since v1.
 * Add member to hold sdio_single_irq function in mmc_card and
   minimize new code in process_sdio_pending_irqs
 * Clarify commit message

Stefan Nilsson XK (1):
  sdio: optimized SDIO IRQ handling for single irq

 drivers/mmc/core/sdio_irq.c |   30 ++
 include/linux/mmc/card.h|1 +
 2 files changed, 31 insertions(+), 0 deletions(-)

-- 
1.7.4.1

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

[PATCH v2] sdio: optimized SDIO IRQ handling for single irq

2011-05-04 Thread Per Forlin

From: Stefan Nilsson XK 

If there is only 1 function registered it is possible to
improve performance by directly calling the irq handler
and avoiding the overhead of reading the CCCR registers.

Signed-off-by: Per Forlin 
Acked-by: Ulf Hansson 
---
 drivers/mmc/core/sdio_irq.c |   30 ++
 include/linux/mmc/card.h|1 +
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index b300161..64c4409 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -32,6 +32,16 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
int i, ret, count;
unsigned char pending;
 
+   /*
+* Optimization, if there is only 1 function registered
+* call irq handler directly
+*/
+   if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
+   struct sdio_func *func = card->sdio_single_irq;
+   func->irq_handler(func);
+   return 1;
+   }
+
ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
if (ret) {
printk(KERN_DEBUG "%s: error %d reading SDIO_CCCR_INTx\n",
@@ -186,6 +196,24 @@ static int sdio_card_irq_put(struct mmc_card *card)
return 0;
 }
 
+/* If there is only 1 function registered set sdio_single_irq */
+static void sdio_single_irq_set(struct mmc_card *card)
+{
+   struct sdio_func *func;
+   int i;
+
+   card->sdio_single_irq = NULL;
+   if ((card->host->caps & MMC_CAP_SDIO_IRQ) &&
+   card->host->sdio_irqs == 1)
+   for (i = 0; i < card->sdio_funcs; i++) {
+  func = card->sdio_func[i];
+  if (func && func->irq_handler) {
+  card->sdio_single_irq = func;
+  break;
+  }
+  }
+}
+
 /**
  * sdio_claim_irq - claim the IRQ for a SDIO function
  * @func: SDIO function
@@ -227,6 +255,7 @@ int sdio_claim_irq(struct sdio_func *func, 
sdio_irq_handler_t *handler)
ret = sdio_card_irq_get(func->card);
if (ret)
func->irq_handler = NULL;
+   sdio_single_irq_set(func->card);
 
return ret;
 }
@@ -251,6 +280,7 @@ int sdio_release_irq(struct sdio_func *func)
if (func->irq_handler) {
func->irq_handler = NULL;
sdio_card_irq_put(func->card);
+   sdio_single_irq_set(func->card);
}
 
ret = mmc_io_rw_direct(func->card, 0, 0, SDIO_CCCR_IENx, 0, ®);
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index adb4888..0d64211 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -145,6 +145,7 @@ struct mmc_card {
struct sdio_cccrcccr;   /* common card info */
struct sdio_cis cis;/* common tuple info */
struct sdio_func*sdio_func[SDIO_MAX_FUNCS]; /* SDIO functions 
(devices) */
+   struct sdio_func*sdio_single_irq; /* SDIO function when only 
one IRQ active */
unsignednum_info;   /* number of info strings */
const char  **info; /* info strings */
struct sdio_func_tuple  *tuples;/* unknown common tuples */
-- 
1.7.4.1


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

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

2011-05-04 Thread Per Forlin

2011/5/4 Michał Mirosław :
> 2011/5/4 Per Forlin :
>> From: Stefan Nilsson XK 
>>
>> If there is only 1 function registered it is possible to
>> improve performance by directly calling the irq handler
>> and avoiding the overhead of reading the CCCR registers.
>>
> [...]
>> --- a/drivers/mmc/core/sdio_irq.c
>> +++ b/drivers/mmc/core/sdio_irq.c
>> @@ -32,6 +32,16 @@ static int process_sdio_pending_irqs(struct mmc_card 
>> *card)
>>        int i, ret, count;
>>        unsigned char pending;
>>
>> +       /*
>> +        * Optimization, if there is only 1 function registered
>> +        * call irq handler directly
>> +        */
>> +       if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
>> +               struct sdio_func *func = card->sdio_single_irq;
>> +               func->irq_handler(func);
>> +               return 1;
>> +       }
> [...]
>
> The second condition can be avoided:
>
> in process_sdio_pending_irqs():
>
> if (card->sdio_irq_func)
>   call handler and return
>
I added the second condition as a sanity check. Same check is used in
the main for loop
>   ret = -EINVAL;
>   } else if (func->irq_handler) {
>   func->irq_handler(func);
Is the second check necessary here?

> in sdio_claim_irq():
>
>  card->func->irq_handler = ...
>  if (host->sdio_irqs == 1)
>    card->sdio_irq_func = func;
>  else
>    card->sdio_irq_func = NULL;
I wanted to keep it simple and use same function in claim and release.
Your code looks nice.
Is if safe to not check the condition "(card->host->caps &
MMC_CAP_SDIO_IRQ)". What happens if the SDIO is in polling mode?

>
> in sdio_release_irq():
>
>  card->sdio_irq_func = NULL;
>  card->func->irq_handler = ...
>  sdio_card_irq_put();
>  if (host->sdio_irqs == 1)
>    sdio_single_irq_set(func->card);
This works for me.

>
> in struct mmc_card:
>  struct sdio_func        *sdio_irq_func;
The name sdio_single_irq indicates it is only used for single irq.
"sdio_irq_func" is too generic I think. But the your name is shorter
and makes the indentation look nicer.
Not a big deal really.

I will wait until tomorrow to post patch v3. This will give time for
other to comment as well.

> Best Regards,
> Michał Mirosław
>
Thanks for your feedback,
Per

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

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

2011-05-04 Thread Nicolas Pitre

On Wed, 4 May 2011, Per Forlin wrote:

> From: Stefan Nilsson XK 
> 
> If there is only 1 function registered it is possible to
> improve performance by directly calling the irq handler
> and avoiding the overhead of reading the CCCR registers.
> 
> Signed-off-by: Per Forlin 
> Acked-by: Ulf Hansson 
> ---
>  drivers/mmc/core/sdio_irq.c |   30 ++
>  include/linux/mmc/card.h|1 +
>  2 files changed, 31 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
> index b300161..64c4409 100644
> --- a/drivers/mmc/core/sdio_irq.c
> +++ b/drivers/mmc/core/sdio_irq.c
> @@ -32,6 +32,16 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
>   int i, ret, count;
>   unsigned char pending;
>  
> + /*
> +  * Optimization, if there is only 1 function registered
> +  * call irq handler directly
> +  */
> + if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
> + struct sdio_func *func = card->sdio_single_irq;
> + func->irq_handler(func);

I think there is little point using a func variable here, especially 
since you already reference the handler pointer in the if() statement.  
Hence:

if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
card->sdio_single_irq->irq_handler();
return 1;
}

> @@ -186,6 +196,24 @@ static int sdio_card_irq_put(struct mmc_card *card)
>   return 0;
>  }
>  
> +/* If there is only 1 function registered set sdio_single_irq */
> +static void sdio_single_irq_set(struct mmc_card *card)
> +{

The comment is slightly wrong.  This should say "only 1 function 
interrupt registered..."  Nothing prevents this from working with 
multiple functions if only one of them has claimed an interrupt. 

Other than that:

Reviewed-by: Nicolas Pitre 


Nicolas

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

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

2011-05-04 Thread Nicolas Pitre

On Wed, 4 May 2011, Per Forlin wrote:

> 2011/5/4 Michał Mirosław :
> > 2011/5/4 Per Forlin :
> >> From: Stefan Nilsson XK 
> >>
> >> If there is only 1 function registered it is possible to
> >> improve performance by directly calling the irq handler
> >> and avoiding the overhead of reading the CCCR registers.
> >>
> > [...]
> >> --- a/drivers/mmc/core/sdio_irq.c
> >> +++ b/drivers/mmc/core/sdio_irq.c
> >> @@ -32,6 +32,16 @@ static int process_sdio_pending_irqs(struct mmc_card 
> >> *card)
> >>        int i, ret, count;
> >>        unsigned char pending;
> >>
> >> +       /*
> >> +        * Optimization, if there is only 1 function registered
> >> +        * call irq handler directly
> >> +        */
> >> +       if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
> >> +               struct sdio_func *func = card->sdio_single_irq;
> >> +               func->irq_handler(func);
> >> +               return 1;
> >> +       }
> > [...]
> >
> > The second condition can be avoided:
> >
> > in process_sdio_pending_irqs():
> >
> > if (card->sdio_irq_func)
> >   call handler and return
> >
> I added the second condition as a sanity check. Same check is used in
> the main for loop
> > ret = -EINVAL;
> > } else if (func->irq_handler) {
> > func->irq_handler(func);
> Is the second check necessary here?

Yes because we want to be notified if the hardware returns pending 
interrupt flags for interrupts we didn't claim.

> > in sdio_claim_irq():
> >
> >  card->func->irq_handler = ...
> >  if (host->sdio_irqs == 1)
> >    card->sdio_irq_func = func;
> >  else
> >    card->sdio_irq_func = NULL;
> I wanted to keep it simple and use same function in claim and release.
> Your code looks nice.
> Is if safe to not check the condition "(card->host->caps &
> MMC_CAP_SDIO_IRQ)". What happens if the SDIO is in polling mode?

You cannot avoid checking MMC_CAP_SDIO_IRQ.  If it isn't set the CCCr 
register must be polled in all cases.


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

Re: Prebuilt images

2011-05-04 Thread Guilherme Salgado

On Wed, 2011-05-04 at 09:37 -0500, Robert Nelson wrote:
> On Wed, May 4, 2011 at 9:22 AM, Guilherme Salgado
>  wrote:
> > Hi there,
> >
> > Several people have suggested that we should start providing prebuilt
> > Linaro images for those who can't/won't install and run
> > linaro-media-create (or any other tool that they have to install in
> > order to generate an image), so we're going to discuss that at LDS.  If
> > you know of anybody who can't/won't install l-m-c, I'd like to know more
> > about it, so I'd appreciate if you could answer the questions or provide
> > us with some user stories:
> >
> >  https://wiki.linaro.org/Platform/Infrastructure/Specs/PrebuiltImages
> 
> Why can't you guys ship the script within the generic image? Then the
> user doesn't have to install anything external, and it can run on more
> platforms then just the latest Ubuntu 11.x.

You mean include it in the Linaro image?  We could do that, but after
you flash the Linaro image l-m-c is only an 'apt-get install' away as
it's in the Ubuntu archives since Lucid.

> I know it's been completely rewritten so it's hard to compare directly
> anymore to my script, but my script currently supports generating sd
> cards in ubuntu/debian/fedora/gentoo (well those are atleast tested..)

We rewrote it completely in python and now it's no longer a single
script file, but it should still run on other distros as long as the
dependencies are installed.

If you'd like to see what it looks now, it's in
http://bazaar.launchpad.net/~linaro-image-tools/linaro-image-tools/trunk/files

Cheers,

-- 
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: STM at UDS-Budapest

2011-05-04 Thread Zach Pfeffer

Would you guys mind signing up for:

https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-jtag

I think this topic would fit in well with that. Would you also mind
sending some info about JTAG support for Panada and Beagle and when
and if CCS will be supported on Linux?

-Zach

On 3 May 2011 06:37, Loïc Minier  wrote:
>        Hi
>
>  The attachment which was too big for the mailing-list is at:
>  http://people.linaro.org/~lool/STMLinuxDriverWhitePaper_Rev0%202S.pdf
>
>   Cheers
> --
> Loïc Minier
>
> ___
> 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: STM at UDS-Budapest

2011-05-04 Thread Zach Pfeffer

Adding some people that might be interested in a common SoC logging
approach and TI's SoC logging:

-Zach

On 3 May 2011 06:37, Loïc Minier  wrote:
>        Hi
>
>  The attachment which was too big for the mailing-list is at:
>  http://people.linaro.org/~lool/STMLinuxDriverWhitePaper_Rev0%202S.pdf
>
>   Cheers
> --
> Loïc Minier
>
> ___
> 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: Would you like remotely accessible boards?

2011-05-04 Thread Zach Pfeffer

Its kind of an aside, but I find the remote power supplies from
Synaccess really nice to use, especially for remote debugging.

-Zach

On 3 May 2011 14:50, Guilherme Salgado  wrote:
> If you do, I need to know more about how you'd like to use them, to make
> sure we provide something that is suitable to everyone.
>
> At this point I'm interested in drafting some user stories so if you
> have any, please do add them to the RemoteDevelopmentBoards[1] wiki
> page. Also, if you'd like to participate in the discussion at LDS, don't
> forget to subscribe to the blueprint[2] on Launchpad.
>
> Cheers,
>
> [1] 
> https://wiki.linaro.org/Platform/Infrastructure/Specs/RemoteDevelopmentBoards
> [2] 
> https://blueprints.launchpad.net/lava/+spec/linaro-platforms-o-remote-developent-boards
>
> --
> Guilherme Salgado 
>
> ___
> 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 v2] sdio: optimized SDIO IRQ handling for single irq

2011-05-04 Thread Per Forlin

On 4 May 2011 19:34, Nicolas Pitre  wrote:
> On Wed, 4 May 2011, Per Forlin wrote:
>
>> From: Stefan Nilsson XK 
>>
>> If there is only 1 function registered it is possible to
>> improve performance by directly calling the irq handler
>> and avoiding the overhead of reading the CCCR registers.
>>
>> Signed-off-by: Per Forlin 
>> Acked-by: Ulf Hansson 
>> ---
>>  drivers/mmc/core/sdio_irq.c |   30 ++
>>  include/linux/mmc/card.h    |    1 +
>>  2 files changed, 31 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
>> index b300161..64c4409 100644
>> --- a/drivers/mmc/core/sdio_irq.c
>> +++ b/drivers/mmc/core/sdio_irq.c
>> @@ -32,6 +32,16 @@ static int process_sdio_pending_irqs(struct mmc_card 
>> *card)
>>       int i, ret, count;
>>       unsigned char pending;
>>
>> +     /*
>> +      * Optimization, if there is only 1 function registered
>> +      * call irq handler directly
>> +      */
>> +     if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
>> +             struct sdio_func *func = card->sdio_single_irq;
>> +             func->irq_handler(func);
>
> I think there is little point using a func variable here, especially
> since you already reference the handler pointer in the if() statement.
> Hence:
>
>        if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
>                card->sdio_single_irq->irq_handler();
>                return 1;
>        }
>
What do you think about:
+   struct sdio_func *func = card->sdio_single_irq;
+
+   /*
+* Optimization, if there is only 1 function interrupt registered
+* call irq handler directly
+*/
+   if (func) {
+   func->irq_handler(func);
+   return 1;
+   }

-   struct sdio_func *func = card->sdio_func[i - 1];
+   func = card->sdio_func[i - 1];

>> @@ -186,6 +196,24 @@ static int sdio_card_irq_put(struct mmc_card *card)
>>       return 0;
>>  }
>>
>> +/* If there is only 1 function registered set sdio_single_irq */
>> +static void sdio_single_irq_set(struct mmc_card *card)
>> +{
>
> The comment is slightly wrong.  This should say "only 1 function
> interrupt registered..."  Nothing prevents this from working with
> multiple functions if only one of them has claimed an interrupt.
>
> Other than that:
>
> Reviewed-by: Nicolas Pitre 
>
>
> Nicolas
>

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

Re: Would you like remotely accessible boards?

2011-05-04 Thread Guilherme Salgado

Hi Michael,

On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
>  wrote:
> > If you do, I need to know more about how you'd like to use them, to make
> > sure we provide something that is suitable to everyone.
> >
> > At this point I'm interested in drafting some user stories so if you
> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
> > page. Also, if you'd like to participate in the discussion at LDS, don't
> > forget to subscribe to the blueprint[2] on Launchpad.
> 
> Hi Guilherme.  We currently have a Versatile Express and three
> PandaBoards in the London data centre:
>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
> 
> There's also a bunch of hardware in my home office that is slowly
> being replaced by the data centre boxes.
> 
> These are set up as porter boxes.  Toolchain people are a bit unique
> as we're very much an end user: a board which is reliable and
> consistent is more important than the latest and greatest.  They're
> used for building GCC (~5 hours), testing it (~7 hours), building
> packages, debugging, and all the usuals.
> 
> One tricky thing is benchmarking.  If you run a benchmark you want the
> same environment as last time and some type of exclusive access.  The

I've added a user story with this requirement.

> environment can change over time as these are generally development
> benchmarks so you can run a baseline first.

Do you mean that when the environment changes you want to run the
baseline benchmark against the old environment?

Cheers,

-- 
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: Would you like remotely accessible boards?

2011-05-04 Thread Zach Pfeffer

I've got another user story.

As an developer using a remote target to debug I would like to be able
to 'see' the video out and hear the audio.

On 4 May 2011 15:15, Guilherme Salgado  wrote:
> Hi Michael,
>
> On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
>> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
>>  wrote:
>> > If you do, I need to know more about how you'd like to use them, to make
>> > sure we provide something that is suitable to everyone.
>> >
>> > At this point I'm interested in drafting some user stories so if you
>> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
>> > page. Also, if you'd like to participate in the discussion at LDS, don't
>> > forget to subscribe to the blueprint[2] on Launchpad.
>>
>> Hi Guilherme.  We currently have a Versatile Express and three
>> PandaBoards in the London data centre:
>>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
>>
>> There's also a bunch of hardware in my home office that is slowly
>> being replaced by the data centre boxes.
>>
>> These are set up as porter boxes.  Toolchain people are a bit unique
>> as we're very much an end user: a board which is reliable and
>> consistent is more important than the latest and greatest.  They're
>> used for building GCC (~5 hours), testing it (~7 hours), building
>> packages, debugging, and all the usuals.
>>
>> One tricky thing is benchmarking.  If you run a benchmark you want the
>> same environment as last time and some type of exclusive access.  The
>
> I've added a user story with this requirement.
>
>> environment can change over time as these are generally development
>> benchmarks so you can run a baseline first.
>
> Do you mean that when the environment changes you want to run the
> baseline benchmark against the old environment?
>
> Cheers,
>
> --
> Guilherme Salgado 
>
> ___
> 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 v2] sdio: optimized SDIO IRQ handling for single irq

2011-05-04 Thread Nicolas Pitre

On Wed, 4 May 2011, Per Forlin wrote:

> On 4 May 2011 19:34, Nicolas Pitre  wrote:
> > On Wed, 4 May 2011, Per Forlin wrote:
> >
> >> From: Stefan Nilsson XK 
> >>
> >> If there is only 1 function registered it is possible to
> >> improve performance by directly calling the irq handler
> >> and avoiding the overhead of reading the CCCR registers.
> >>
> >> Signed-off-by: Per Forlin 
> >> Acked-by: Ulf Hansson 
> >> ---
> >>  drivers/mmc/core/sdio_irq.c |   30 ++
> >>  include/linux/mmc/card.h    |    1 +
> >>  2 files changed, 31 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
> >> index b300161..64c4409 100644
> >> --- a/drivers/mmc/core/sdio_irq.c
> >> +++ b/drivers/mmc/core/sdio_irq.c
> >> @@ -32,6 +32,16 @@ static int process_sdio_pending_irqs(struct mmc_card 
> >> *card)
> >>       int i, ret, count;
> >>       unsigned char pending;
> >>
> >> +     /*
> >> +      * Optimization, if there is only 1 function registered
> >> +      * call irq handler directly
> >> +      */
> >> +     if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
> >> +             struct sdio_func *func = card->sdio_single_irq;
> >> +             func->irq_handler(func);
> >
> > I think there is little point using a func variable here, especially
> > since you already reference the handler pointer in the if() statement.
> > Hence:
> >
> >        if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
> >                card->sdio_single_irq->irq_handler();
> >                return 1;
> >        }
> >
> What do you think about:
> +   struct sdio_func *func = card->sdio_single_irq;
> +
> +   /*
> +* Optimization, if there is only 1 function interrupt registered
> +* call irq handler directly
> +*/
> +   if (func) {
> +   func->irq_handler(func);
> +   return 1;
> +   }

Sure, but I'd move the assignment right before the if() in that case for 
clarity:

   struct sdio_func *func;

   /*
* Optimization, if there is only 1 function interrupt registered
* call irq handler directly
*/
   func = card->sdio_single_irq;
   if (func) {
   func->irq_handler(func);
   return 1;
   }
   [...]


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

Re: Would you like remotely accessible boards?

2011-05-04 Thread Michael Hope

On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado
 wrote:
> Hi Michael,
>
> On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
>> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
>>  wrote:
>> > If you do, I need to know more about how you'd like to use them, to make
>> > sure we provide something that is suitable to everyone.
>> >
>> > At this point I'm interested in drafting some user stories so if you
>> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
>> > page. Also, if you'd like to participate in the discussion at LDS, don't
>> > forget to subscribe to the blueprint[2] on Launchpad.
>>
>> Hi Guilherme.  We currently have a Versatile Express and three
>> PandaBoards in the London data centre:
>>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
>>
>> There's also a bunch of hardware in my home office that is slowly
>> being replaced by the data centre boxes.
>>
>> These are set up as porter boxes.  Toolchain people are a bit unique
>> as we're very much an end user: a board which is reliable and
>> consistent is more important than the latest and greatest.  They're
>> used for building GCC (~5 hours), testing it (~7 hours), building
>> packages, debugging, and all the usuals.
>>
>> One tricky thing is benchmarking.  If you run a benchmark you want the
>> same environment as last time and some type of exclusive access.  The
>
> I've added a user story with this requirement.
>
>> environment can change over time as these are generally development
>> benchmarks so you can run a baseline first.
>
> Do you mean that when the environment changes you want to run the
> baseline benchmark against the old environment?

There's two stories:
 * A developer benchmarking their latest changes.  They can run a
baseline, bring in the change, then run to show the improvement. The
environment should stay the same over that week
 * The continuous build recording benchmark results with every build.
The environment should always stay the same so that the numbers can be
compared

-- Michael

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

Re: Would you like remotely accessible boards?

2011-05-04 Thread Zach Pfeffer

Hmm...actually I was thinking a little more interactive and less
batch. Having a remote system that I could do live debug and
development one.

On 4 May 2011 15:26, Michael Hope  wrote:
> On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado
>  wrote:
>> Hi Michael,
>>
>> On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
>>> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
>>>  wrote:
>>> > If you do, I need to know more about how you'd like to use them, to make
>>> > sure we provide something that is suitable to everyone.
>>> >
>>> > At this point I'm interested in drafting some user stories so if you
>>> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
>>> > page. Also, if you'd like to participate in the discussion at LDS, don't
>>> > forget to subscribe to the blueprint[2] on Launchpad.
>>>
>>> Hi Guilherme.  We currently have a Versatile Express and three
>>> PandaBoards in the London data centre:
>>>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
>>>
>>> There's also a bunch of hardware in my home office that is slowly
>>> being replaced by the data centre boxes.
>>>
>>> These are set up as porter boxes.  Toolchain people are a bit unique
>>> as we're very much an end user: a board which is reliable and
>>> consistent is more important than the latest and greatest.  They're
>>> used for building GCC (~5 hours), testing it (~7 hours), building
>>> packages, debugging, and all the usuals.
>>>
>>> One tricky thing is benchmarking.  If you run a benchmark you want the
>>> same environment as last time and some type of exclusive access.  The
>>
>> I've added a user story with this requirement.
>>
>>> environment can change over time as these are generally development
>>> benchmarks so you can run a baseline first.
>>
>> Do you mean that when the environment changes you want to run the
>> baseline benchmark against the old environment?
>
> There's two stories:
>  * A developer benchmarking their latest changes.  They can run a
> baseline, bring in the change, then run to show the improvement. The
> environment should stay the same over that week
>  * The continuous build recording benchmark results with every build.
> The environment should always stay the same so that the numbers can be
> compared
>
> -- Michael
>
> ___
> 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: Would you like remotely accessible boards?

2011-05-04 Thread Guilherme Salgado

On Wed, 2011-05-04 at 15:32 -0500, Zach Pfeffer wrote:
> Hmm...actually I was thinking a little more interactive and less
> batch. Having a remote system that I could do live debug and
> development one.

That's one of the user stories on the wiki page.

> 
> On 4 May 2011 15:26, Michael Hope  wrote:
> > On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado
> >  wrote:
> >> Hi Michael,
> >>
> >> On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
> >>> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
> >>>  wrote:
> >>> > If you do, I need to know more about how you'd like to use them, to make
> >>> > sure we provide something that is suitable to everyone.
> >>> >
> >>> > At this point I'm interested in drafting some user stories so if you
> >>> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
> >>> > page. Also, if you'd like to participate in the discussion at LDS, don't
> >>> > forget to subscribe to the blueprint[2] on Launchpad.
> >>>
> >>> Hi Guilherme.  We currently have a Versatile Express and three
> >>> PandaBoards in the London data centre:
> >>>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
> >>>
> >>> There's also a bunch of hardware in my home office that is slowly
> >>> being replaced by the data centre boxes.
> >>>
> >>> These are set up as porter boxes.  Toolchain people are a bit unique
> >>> as we're very much an end user: a board which is reliable and
> >>> consistent is more important than the latest and greatest.  They're
> >>> used for building GCC (~5 hours), testing it (~7 hours), building
> >>> packages, debugging, and all the usuals.
> >>>
> >>> One tricky thing is benchmarking.  If you run a benchmark you want the
> >>> same environment as last time and some type of exclusive access.  The
> >>
> >> I've added a user story with this requirement.
> >>
> >>> environment can change over time as these are generally development
> >>> benchmarks so you can run a baseline first.
> >>
> >> Do you mean that when the environment changes you want to run the
> >> baseline benchmark against the old environment?
> >
> > There's two stories:
> >  * A developer benchmarking their latest changes.  They can run a
> > baseline, bring in the change, then run to show the improvement. The
> > environment should stay the same over that week
> >  * The continuous build recording benchmark results with every build.
> > The environment should always stay the same so that the numbers can be
> > compared
> >
> > -- Michael
> >
> > ___
> > linaro-dev mailing list
> > linaro-dev@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> >

-- 
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: Would you like remotely accessible boards?

2011-05-04 Thread Zach Pfeffer

Hmm... I took a look at:

https://wiki.linaro.org/Platform/Infrastructure/Specs/RemoteDevelopmentBoards

..and there nothing about multimedia live debug.

-Zach

On 4 May 2011 15:43, Guilherme Salgado  wrote:
> On Wed, 2011-05-04 at 15:32 -0500, Zach Pfeffer wrote:
>> Hmm...actually I was thinking a little more interactive and less
>> batch. Having a remote system that I could do live debug and
>> development one.
>
> That's one of the user stories on the wiki page.
>
>>
>> On 4 May 2011 15:26, Michael Hope  wrote:
>> > On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado
>> >  wrote:
>> >> Hi Michael,
>> >>
>> >> On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
>> >>> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
>> >>>  wrote:
>> >>> > If you do, I need to know more about how you'd like to use them, to 
>> >>> > make
>> >>> > sure we provide something that is suitable to everyone.
>> >>> >
>> >>> > At this point I'm interested in drafting some user stories so if you
>> >>> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
>> >>> > page. Also, if you'd like to participate in the discussion at LDS, 
>> >>> > don't
>> >>> > forget to subscribe to the blueprint[2] on Launchpad.
>> >>>
>> >>> Hi Guilherme.  We currently have a Versatile Express and three
>> >>> PandaBoards in the London data centre:
>> >>>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
>> >>>
>> >>> There's also a bunch of hardware in my home office that is slowly
>> >>> being replaced by the data centre boxes.
>> >>>
>> >>> These are set up as porter boxes.  Toolchain people are a bit unique
>> >>> as we're very much an end user: a board which is reliable and
>> >>> consistent is more important than the latest and greatest.  They're
>> >>> used for building GCC (~5 hours), testing it (~7 hours), building
>> >>> packages, debugging, and all the usuals.
>> >>>
>> >>> One tricky thing is benchmarking.  If you run a benchmark you want the
>> >>> same environment as last time and some type of exclusive access.  The
>> >>
>> >> I've added a user story with this requirement.
>> >>
>> >>> environment can change over time as these are generally development
>> >>> benchmarks so you can run a baseline first.
>> >>
>> >> Do you mean that when the environment changes you want to run the
>> >> baseline benchmark against the old environment?
>> >
>> > There's two stories:
>> >  * A developer benchmarking their latest changes.  They can run a
>> > baseline, bring in the change, then run to show the improvement. The
>> > environment should stay the same over that week
>> >  * The continuous build recording benchmark results with every build.
>> > The environment should always stay the same so that the numbers can be
>> > compared
>> >
>> > -- Michael
>> >
>> > ___
>> > linaro-dev mailing list
>> > linaro-dev@lists.linaro.org
>> > http://lists.linaro.org/mailman/listinfo/linaro-dev
>> >
>
> --
> Guilherme Salgado 
>

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

Re: Would you like remotely accessible boards?

2011-05-04 Thread Guilherme Salgado

On Thu, 2011-05-05 at 08:26 +1200, Michael Hope wrote:
> On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado
>  wrote:
> > Hi Michael,
> >
> > On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
> >> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
> >>  wrote:
> >> > If you do, I need to know more about how you'd like to use them, to make
> >> > sure we provide something that is suitable to everyone.
> >> >
> >> > At this point I'm interested in drafting some user stories so if you
> >> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
> >> > page. Also, if you'd like to participate in the discussion at LDS, don't
> >> > forget to subscribe to the blueprint[2] on Launchpad.
> >>
> >> Hi Guilherme.  We currently have a Versatile Express and three
> >> PandaBoards in the London data centre:
> >>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
> >>
> >> There's also a bunch of hardware in my home office that is slowly
> >> being replaced by the data centre boxes.
> >>
> >> These are set up as porter boxes.  Toolchain people are a bit unique
> >> as we're very much an end user: a board which is reliable and
> >> consistent is more important than the latest and greatest.  They're
> >> used for building GCC (~5 hours), testing it (~7 hours), building
> >> packages, debugging, and all the usuals.
> >>
> >> One tricky thing is benchmarking.  If you run a benchmark you want the
> >> same environment as last time and some type of exclusive access.  The
> >
> > I've added a user story with this requirement.
> >
> >> environment can change over time as these are generally development
> >> benchmarks so you can run a baseline first.
> >
> > Do you mean that when the environment changes you want to run the
> > baseline benchmark against the old environment?
> 
> There's two stories:
>  * A developer benchmarking their latest changes.  They can run a
> baseline, bring in the change, then run to show the improvement. The
> environment should stay the same over that week

Ok, I understand it now, although I can't think of a way to write this
nicely using the 'As  I want to  so that ' format. Maybe

  As a Toolchain engineer, I want to have a system with a stable 
  environment allocated to me for a week so that I can benchmark the 
  toolchain with my changes against a baseline.

?

>  * The continuous build recording benchmark results with every build.
> The environment should always stay the same so that the numbers can be
> compared

How does

  As a Toolchain engineer, I want to continuously build the toolchain 
  against a stable environment and record the benchmark results, so that
  they can be compared.

Sound as a user story for the above, using our preferred format?

-- 
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: Would you like remotely accessible boards?

2011-05-04 Thread Guilherme Salgado

On Wed, 2011-05-04 at 15:49 -0500, Zach Pfeffer wrote:
> Hmm... I took a look at:
> 
> https://wiki.linaro.org/Platform/Infrastructure/Specs/RemoteDevelopmentBoards
> 
> ..and there nothing about multimedia live debug.

I meant the bit about live debug and development, which is what you
mentioned in your previous message. The one there is not specific to
multimedia, but we can either change it or add one that is.

> 
> On 4 May 2011 15:43, Guilherme Salgado  wrote:
> > On Wed, 2011-05-04 at 15:32 -0500, Zach Pfeffer wrote:
> >> Hmm...actually I was thinking a little more interactive and less
> >> batch. Having a remote system that I could do live debug and
> >> development one.
> >
> > That's one of the user stories on the wiki page.
> >
> >>
> >> On 4 May 2011 15:26, Michael Hope  wrote:
> >> > On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado
> >> >  wrote:
> >> >> Hi Michael,
> >> >>
> >> >> On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
> >> >>> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
> >> >>>  wrote:
> >> >>> > If you do, I need to know more about how you'd like to use them, to 
> >> >>> > make
> >> >>> > sure we provide something that is suitable to everyone.
> >> >>> >
> >> >>> > At this point I'm interested in drafting some user stories so if you
> >> >>> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
> >> >>> > page. Also, if you'd like to participate in the discussion at LDS, 
> >> >>> > don't
> >> >>> > forget to subscribe to the blueprint[2] on Launchpad.
> >> >>>
> >> >>> Hi Guilherme.  We currently have a Versatile Express and three
> >> >>> PandaBoards in the London data centre:
> >> >>>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
> >> >>>
> >> >>> There's also a bunch of hardware in my home office that is slowly
> >> >>> being replaced by the data centre boxes.
> >> >>>
> >> >>> These are set up as porter boxes.  Toolchain people are a bit unique
> >> >>> as we're very much an end user: a board which is reliable and
> >> >>> consistent is more important than the latest and greatest.  They're
> >> >>> used for building GCC (~5 hours), testing it (~7 hours), building
> >> >>> packages, debugging, and all the usuals.
> >> >>>
> >> >>> One tricky thing is benchmarking.  If you run a benchmark you want the
> >> >>> same environment as last time and some type of exclusive access.  The
> >> >>
> >> >> I've added a user story with this requirement.
> >> >>
> >> >>> environment can change over time as these are generally development
> >> >>> benchmarks so you can run a baseline first.
> >> >>
> >> >> Do you mean that when the environment changes you want to run the
> >> >> baseline benchmark against the old environment?
> >> >
> >> > There's two stories:
> >> >  * A developer benchmarking their latest changes.  They can run a
> >> > baseline, bring in the change, then run to show the improvement. The
> >> > environment should stay the same over that week
> >> >  * The continuous build recording benchmark results with every build.
> >> > The environment should always stay the same so that the numbers can be
> >> > compared
> >> >
> >> > -- Michael
> >> >
> >> > ___
> >> > linaro-dev mailing list
> >> > linaro-dev@lists.linaro.org
> >> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> >> >
> >
> > --
> > Guilherme Salgado 
> >

-- 
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: Would you like remotely accessible boards?

2011-05-04 Thread Zach Pfeffer

I think the email thread crossed at some point. Anyway the user story could be:

As a developer I want a target that I can interactively control and
see graphical/video output and hear audio output, so that I can
develop multimedia features.

-Zach

On 4 May 2011 16:02, Guilherme Salgado  wrote:
> On Wed, 2011-05-04 at 15:49 -0500, Zach Pfeffer wrote:
>> Hmm... I took a look at:
>>
>> https://wiki.linaro.org/Platform/Infrastructure/Specs/RemoteDevelopmentBoards
>>
>> ..and there nothing about multimedia live debug.
>
> I meant the bit about live debug and development, which is what you
> mentioned in your previous message. The one there is not specific to
> multimedia, but we can either change it or add one that is.
>
>>
>> On 4 May 2011 15:43, Guilherme Salgado  wrote:
>> > On Wed, 2011-05-04 at 15:32 -0500, Zach Pfeffer wrote:
>> >> Hmm...actually I was thinking a little more interactive and less
>> >> batch. Having a remote system that I could do live debug and
>> >> development one.
>> >
>> > That's one of the user stories on the wiki page.
>> >
>> >>
>> >> On 4 May 2011 15:26, Michael Hope  wrote:
>> >> > On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado
>> >> >  wrote:
>> >> >> Hi Michael,
>> >> >>
>> >> >> On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
>> >> >>> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
>> >> >>>  wrote:
>> >> >>> > If you do, I need to know more about how you'd like to use them, to 
>> >> >>> > make
>> >> >>> > sure we provide something that is suitable to everyone.
>> >> >>> >
>> >> >>> > At this point I'm interested in drafting some user stories so if you
>> >> >>> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
>> >> >>> > page. Also, if you'd like to participate in the discussion at LDS, 
>> >> >>> > don't
>> >> >>> > forget to subscribe to the blueprint[2] on Launchpad.
>> >> >>>
>> >> >>> Hi Guilherme.  We currently have a Versatile Express and three
>> >> >>> PandaBoards in the London data centre:
>> >> >>>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
>> >> >>>
>> >> >>> There's also a bunch of hardware in my home office that is slowly
>> >> >>> being replaced by the data centre boxes.
>> >> >>>
>> >> >>> These are set up as porter boxes.  Toolchain people are a bit unique
>> >> >>> as we're very much an end user: a board which is reliable and
>> >> >>> consistent is more important than the latest and greatest.  They're
>> >> >>> used for building GCC (~5 hours), testing it (~7 hours), building
>> >> >>> packages, debugging, and all the usuals.
>> >> >>>
>> >> >>> One tricky thing is benchmarking.  If you run a benchmark you want the
>> >> >>> same environment as last time and some type of exclusive access.  The
>> >> >>
>> >> >> I've added a user story with this requirement.
>> >> >>
>> >> >>> environment can change over time as these are generally development
>> >> >>> benchmarks so you can run a baseline first.
>> >> >>
>> >> >> Do you mean that when the environment changes you want to run the
>> >> >> baseline benchmark against the old environment?
>> >> >
>> >> > There's two stories:
>> >> >  * A developer benchmarking their latest changes.  They can run a
>> >> > baseline, bring in the change, then run to show the improvement. The
>> >> > environment should stay the same over that week
>> >> >  * The continuous build recording benchmark results with every build.
>> >> > The environment should always stay the same so that the numbers can be
>> >> > compared
>> >> >
>> >> > -- Michael
>> >> >
>> >> > ___
>> >> > linaro-dev mailing list
>> >> > linaro-dev@lists.linaro.org
>> >> > http://lists.linaro.org/mailman/listinfo/linaro-dev
>> >> >
>> >
>> > --
>> > Guilherme Salgado 
>> >
>
> --
> Guilherme Salgado 
>

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

Anyone with kernel patches for the 11.05 release please speak up !!!

2011-05-04 Thread Nicolas Pitre


The 11.05 Linaro release is coming soon after LDS.  And LDS is next 
week.  I therefore would like to have everything merged in the Linaro 
kernel _this_ week i.e. before LDS so there is still a bit of time after 
it to fix any problems that may show up (I don't count on any time 
available for this during LDS).

That means only two days left.

I've been in contact with all the landing teams for a while prodding 
them about their work.  So they know about this already.  But if there 
is anyone else with pending work to be merged in the Linaro kernel 
please let me know ASAP!


Nicolas

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

RE: STM at UDS-Budapest

2011-05-04 Thread Deao, Douglas

Zach,

I would sign up for your session but I am flying out Thursday to make a 
customer meeting Friday.

I am not real familiar with the Panda or Beagle boards, and have never used 
one. I took a look at the Panda board schematics and it's using the standard 
14-pin JTAG connector, so all the standard CCS debug capabilities should be 
supported. 

I believe the Beagle board also uses the standard 14-pin JTAG connector. 

Here are a couple of links for debugging with the Beagle board:

http://processors.wiki.ti.com/index.php/Debugging_Beagle_with_an_XDS100
http://processors.wiki.ti.com/index.php/Debug_Access_Port_%28DAP%29

CCS will be supported on Linux. I have sent a request into our CCS Team to 
confirm the state of Linux support.

Regards,
Doug

-Original Message-
From: Zach Pfeffer [mailto:zach.pfef...@linaro.org] 
Sent: Wednesday, May 04, 2011 1:11 PM
To: Loïc Minier
Cc: Deao, Douglas; linaro-dev@lists.linaro.org
Subject: Re: STM at UDS-Budapest

Would you guys mind signing up for:

https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-jtag

I think this topic would fit in well with that. Would you also mind
sending some info about JTAG support for Panada and Beagle and when
and if CCS will be supported on Linux?

-Zach

On 3 May 2011 06:37, Loïc Minier  wrote:
>        Hi
>
>  The attachment which was too big for the mailing-list is at:
>  http://people.linaro.org/~lool/STMLinuxDriverWhitePaper_Rev0%202S.pdf
>
>   Cheers
> --
> Loïc Minier
>
> ___
> 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 v2] sdio: optimized SDIO IRQ handling for single irq

2011-05-04 Thread Michał Mirosław

2011/5/4 Per Forlin :
> From: Stefan Nilsson XK 
>
> If there is only 1 function registered it is possible to
> improve performance by directly calling the irq handler
> and avoiding the overhead of reading the CCCR registers.
>
[...]
> --- a/drivers/mmc/core/sdio_irq.c
> +++ b/drivers/mmc/core/sdio_irq.c
> @@ -32,6 +32,16 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
>        int i, ret, count;
>        unsigned char pending;
>
> +       /*
> +        * Optimization, if there is only 1 function registered
> +        * call irq handler directly
> +        */
> +       if (card->sdio_single_irq && card->sdio_single_irq->irq_handler) {
> +               struct sdio_func *func = card->sdio_single_irq;
> +               func->irq_handler(func);
> +               return 1;
> +       }
[...]

The second condition can be avoided:

in process_sdio_pending_irqs():

if (card->sdio_irq_func)
   call handler and return

in sdio_claim_irq():

  card->func->irq_handler = ...
  if (host->sdio_irqs == 1)
card->sdio_irq_func = func;
  else
card->sdio_irq_func = NULL;

in sdio_release_irq():

  card->sdio_irq_func = NULL;
  card->func->irq_handler = ...
  sdio_card_irq_put();
  if (host->sdio_irqs == 1)
sdio_single_irq_set(func->card);

in struct mmc_card:
  struct sdio_func        *sdio_irq_func;

Best Regards,
Michał Mirosław

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

Re: Would you like remotely accessible boards?

2011-05-04 Thread Loïc Minier

Hey

 This is not a specific use case, but more of a proposed design feature:
 Linaro might sometimes offer the possibility to run/build something on
 boards to untrusted third parties.  For instance building a package,
 running a testsuite, or doing a test build of a proposed GCC branch or
 an Android image.
   It might be worth considering some security sandboxing for some of
 the boards for some of the use cases.

   Cheers,
-- 
Loïc Minier

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

Re: linaro-android track

2011-05-04 Thread Michael Hudson-Doyle

On Wed, 4 May 2011 09:30:53 +0300, Paul Sokolovsky  
wrote:
> On Wed, 04 May 2011 11:40:50 +1200
> Michael Hudson-Doyle  wrote:
> 
> > On Mon, 2 May 2011 17:30:56 -0500, Zach Pfeffer
> >  wrote:
> > > All,
> > > 
> > > I apologize for the broad distribution.
> > 
> > I've trimmed the Cc:s a bit.
> > 
> > > Alexander and I have been getting the Android track going. We have
> > > the following topics. Most of these have subscribers. Would
> > > everyone mind taking a look through this list and subscribing or
> > > suggesting people who should be involved? I'll be getting more
> > > details into each of these this week.
> > 
> > There are also some specs registered by the infrastructure team that
> > seem relevant, and may or may not overlap a bit with some of yours.
> > 
> > In particular, you guys should know about:
> > 
> > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-managing-code-differences
> > 
> > and 
> > 
> > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-better-android-build-service
> 
> This one yes, it was discussed and agreed (sorry for not cc:ing you)

No worries, I guess I'm not supposed to be worrying about this sort of
thing any more :)

> that Android team's session can be merged into the above,
> https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-improving-build-tool
> is marked as superseded. I see them both in the schedule though, but
> they go one after another on Thursday.

That's not so good.  I'll try to find out how to remove it, but most of
the relevant people are sadly probably not around by now, so maybe
someone in a more convenient timezone can work on this?

Cheers,
mwh

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

Re: STM at UDS-Budapest

2011-05-04 Thread Zach Pfeffer

Thanks Doug. Would you send a link and any licensing info (free on
Linux would be great!).

On 4 May 2011 17:25, Deao, Douglas  wrote:
> Zach,
>
> I would sign up for your session but I am flying out Thursday to make a 
> customer meeting Friday.
>
> I am not real familiar with the Panda or Beagle boards, and have never used 
> one. I took a look at the Panda board schematics and it's using the standard 
> 14-pin JTAG connector, so all the standard CCS debug capabilities should be 
> supported.
>
> I believe the Beagle board also uses the standard 14-pin JTAG connector.
>
> Here are a couple of links for debugging with the Beagle board:
>
> http://processors.wiki.ti.com/index.php/Debugging_Beagle_with_an_XDS100
> http://processors.wiki.ti.com/index.php/Debug_Access_Port_%28DAP%29
>
> CCS will be supported on Linux. I have sent a request into our CCS Team to 
> confirm the state of Linux support.
>
> Regards,
> Doug
>
> -Original Message-
> From: Zach Pfeffer [mailto:zach.pfef...@linaro.org]
> Sent: Wednesday, May 04, 2011 1:11 PM
> To: Loïc Minier
> Cc: Deao, Douglas; linaro-dev@lists.linaro.org
> Subject: Re: STM at UDS-Budapest
>
> Would you guys mind signing up for:
>
> https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-jtag
>
> I think this topic would fit in well with that. Would you also mind
> sending some info about JTAG support for Panada and Beagle and when
> and if CCS will be supported on Linux?
>
> -Zach
>
> On 3 May 2011 06:37, Loïc Minier  wrote:
>>        Hi
>>
>>  The attachment which was too big for the mailing-list is at:
>>  http://people.linaro.org/~lool/STMLinuxDriverWhitePaper_Rev0%202S.pdf
>>
>>   Cheers
>> --
>> Loïc Minier
>>
>> ___
>> 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: Would you like remotely accessible boards?

2011-05-04 Thread Michael Hope

On Thu, May 5, 2011 at 8:55 AM, Guilherme Salgado
 wrote:
> On Thu, 2011-05-05 at 08:26 +1200, Michael Hope wrote:
>> On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado
>>  wrote:
>> > Hi Michael,
>> >
>> > On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
>> >> On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado
>> >>  wrote:
>> >> > If you do, I need to know more about how you'd like to use them, to make
>> >> > sure we provide something that is suitable to everyone.
>> >> >
>> >> > At this point I'm interested in drafting some user stories so if you
>> >> > have any, please do add them to the RemoteDevelopmentBoards[1] wiki
>> >> > page. Also, if you'd like to participate in the discussion at LDS, don't
>> >> > forget to subscribe to the blueprint[2] on Launchpad.
>> >>
>> >> Hi Guilherme.  We currently have a Versatile Express and three
>> >> PandaBoards in the London data centre:
>> >>  https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
>> >>
>> >> There's also a bunch of hardware in my home office that is slowly
>> >> being replaced by the data centre boxes.
>> >>
>> >> These are set up as porter boxes.  Toolchain people are a bit unique
>> >> as we're very much an end user: a board which is reliable and
>> >> consistent is more important than the latest and greatest.  They're
>> >> used for building GCC (~5 hours), testing it (~7 hours), building
>> >> packages, debugging, and all the usuals.
>> >>
>> >> One tricky thing is benchmarking.  If you run a benchmark you want the
>> >> same environment as last time and some type of exclusive access.  The
>> >
>> > I've added a user story with this requirement.
>> >
>> >> environment can change over time as these are generally development
>> >> benchmarks so you can run a baseline first.
>> >
>> > Do you mean that when the environment changes you want to run the
>> > baseline benchmark against the old environment?
>>
>> There's two stories:
>>  * A developer benchmarking their latest changes.  They can run a
>> baseline, bring in the change, then run to show the improvement. The
>> environment should stay the same over that week
>
> Ok, I understand it now, although I can't think of a way to write this
> nicely using the 'As  I want to  so that  brings>' format. Maybe
>
>  As a Toolchain engineer, I want to have a system with a stable
>  environment allocated to me for a week so that I can benchmark the
>  toolchain with my changes against a baseline.
>
> ?
>
>>  * The continuous build recording benchmark results with every build.
>> The environment should always stay the same so that the numbers can be
>> compared
>
> How does
>
>  As a Toolchain engineer, I want to continuously build the toolchain
>  against a stable environment and record the benchmark results, so that
>  they can be compared.
>
> Sound as a user story for the above, using our preferred format?

Change 'stable' for 'consistent'.  Sounds good.

-- Michael

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

Re: [PATCH] sdio: optimized SDIO IRQ handling for single function

[NOTES] 2011-05-04 Android Platform Team Meeting

[PM] 04/05/2011 - Minutes for the Power Management WG weekly call

Prebuilt images

Re: Prebuilt images

Re: Would you like remotely accessible boards?

Re: [PATCH] sdio: optimized SDIO IRQ handling for single function

Re: [PATCH] sdio: optimized SDIO IRQ handling for single function

Re: CALL FOR TESTING: proposed enhancements for OMAP4

[PATCH v2] sdio: optimized SDIO IRQ handling for single irq

[PATCH v2] sdio: optimized SDIO IRQ handling for single irq

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

Re: Prebuilt images

Re: STM at UDS-Budapest

Re: STM at UDS-Budapest

Re: Would you like remotely accessible boards?

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

Re: Would you like remotely accessible boards?

Re: Would you like remotely accessible boards?

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

Re: Would you like remotely accessible boards?

Re: Would you like remotely accessible boards?

Re: Would you like remotely accessible boards?

Re: Would you like remotely accessible boards?

Re: Would you like remotely accessible boards?

Re: Would you like remotely accessible boards?

Re: Would you like remotely accessible boards?

Anyone with kernel patches for the 11.05 release please speak up !!!

RE: STM at UDS-Budapest

Re: [PATCH v2] sdio: optimized SDIO IRQ handling for single irq

Re: Would you like remotely accessible boards?

Re: linaro-android track

Re: STM at UDS-Budapest

Re: Would you like remotely accessible boards?

36 matches

Site Navigation

Mail list logo

Footer information