Re: [PATCH --mmotm v5 1/3] fault-inject: export fault injection functions

[Per Forlin]

On 8 August 2011 22:07, Per Forlin  wrote:
> export symbols fault_should_fail() and fault_create_debugfs_attr() in order
> to let modules utilize the fault injection
This patch is already merged in mainline too.
Unfortunately I left a typo here. It says fault_should_fail() in the
commit message but the function in the patch is called only
should_fail(). This is already in rc1 so I guess we have to live with
this typo.

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

RE: [PATCH v3 01/11] MFD: DA9052 MFD core module

[Ashish Jangam]

> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Saturday, August 06, 2011 7:09 PM
> To: Ashish Jangam
> Cc: sa...@openedhand.com; linux-ker...@vger.kernel.org; Dajun; linaro-
> d...@lists.linaro.org
> Subject: Re: [PATCH v3 01/11] MFD: DA9052 MFD core module
> 
> On Fri, Aug 05, 2011 at 07:23:44PM +0530, ashishj3 wrote:
> 
> > +choice
> > +   prompt "Chip Type"
> > +   depends on MFD_DA9053_SPI || MFD_DA9053_I2C
> > +config PMIC_DA9053AA
> > +   bool "Support Dialog Semiconductor DA9053 AA PMIC"
> > +   help
> > + Support for Dialog semiconductor DA9053 AA PMIC.
> > + This driver provides common support for accessing  the device,
> > + additional drivers must be enabled in order to use the
> > + functionality of the device.
> > +config PMIC_DA9053Bx
> 
> Could do with blank lines between blocks.  Though looking at the code
> here I don't understand why these are compile options at all, or if they
> need to be compile options for some reason why they're not independantly
> selectable?
DA9052 PMIC chip id may get OTP therefore chip id cannot be used as 
a distinguishing factor. Hence these compile time options were introduced.
DA9053 is a higher version of DA9052 therefore not independently selectable.
This means that there can be either DA9052 or DA9053 on system. I need to 
correct
this Kconfig to take care of this. 
> 
> > +int da9052_reg_read(struct da9052 *da9052, unsigned char reg)
> > +{
> > +   int val, ret;
> > +
> > +   if (reg > DA9052_MAX_REG_CNT) {
> > +   dev_err(da9052->dev, "invalid reg %x\n", reg);
> > +   return -EINVAL;
> > +   }
> > +
> > +   #ifdef CONFIG_MFD_DA9052_SPI
> > +   reg = (reg << 1) | 1;
> > +   #endif
> 
> There's several problems here:
> 
> - You shouldn't be indenting preprocessor directives.
> - You shouldn't be adding extra indentation before.
> - This will break I2C devices if SPI support is built into the driver.
> 
> Please, when writing code try to understand the abstractions you're
> using.  For example here think about the purpose of being able to build
> I2C and SPI separately and simultaneously and the goal of the regmap
> API.
> 
> Looks like we need to add per device mangling for the SPI register
> read/write flag.
For now we will handle this as below:-
During SPI and I2C registration we will add bus type(SPI/I2C) info in the
struct da9052. And before initiating any device I/O this struct member will
be read and reg address will be manipulated if needed.
> 
> > +   da9052_group_write(da9052, DA9052_EVENT_A_REG, 4, v);
> > +
> > +   #ifndef CONFIG_PMIC_DA9053Bx
> > +   DA9052_FIXME();
> > +   #endif
> 
> This should be runtime detected based on the device name, either from
> the device registration or by reading back chip identification.
As said above getting chip info will not work in DA9053/53 case. Also DA9052 
code 
works for DA9053 except for few minor changes in MFD and regulator module.
In this case registering different device will also require a preprocessor 
directive
Or separate DA9053 file therefore this option was not opt. 
>



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

RE: DA9053 LKML work

[Ashish Jangam]

Hi Paul,

Attached are the DA9052 LKML patches for:-
MFD
Regulator
Backlight
LED
GPIO
Onkey
HWMON
RTC

Above Patches are ACK by LKML but yet to be merged in Linux.org.

Battery, TSI and SM are yet to be ACK therefore not included in this attachment.

In case of any problem with these patches do let me know.

Regards,
Ashish

> -Original Message-
> From: Ying-Chun Liu (PaulLiu) [mailto:paul@linaro.org]
> Sent: Monday, August 08, 2011 3:51 PM
> To: Ashish Jangam
> Subject: Re: DA9053 LKML work
> 
> Hi Ashish,
> 
> Do you have all of the latest link of your DA9052 driver on LKML?
> It is because I cannot find newer version of TSI driver.
> https://lkml.org/lkml/2011/4/13/112
> 
> In your last mail
> > 8 patches got accepted only remains are battery, tsi and watchdog
> hopefully
> > They should get through by July end.
> 
> What do you mean get accepted?
> Do you have an external git tree maintaining the patches??
> 
> Yours Sincerely,
> Paul Liu





linaro.patch.tar.gz
Description: linaro.patch.tar.gz
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH --mmotm v5 0/3] Make fault injection available for MMC IO

[Per Forlin]

On 9 August 2011 02:51, Akinobu Mita  wrote:
> All three patches look good.
> Acked-by: Akinobu Mita 
>
> 2011/8/9 Per Forlin :
>> This patchset is sent to the mm-tree because it depends on Akinobu's patch
>> "fault-injection: add ability to export fault_attr in..."
>
> That patch has already been merged in mainline.
>
Please drop this patchset.
Patch #1 "fault-injection: export fault injection functions" is merged
too. There is no need to merge this through mm-tree anymore. All
fault-injection patches needed by MMC fault injection code are merged.
I'll repost the patchset to mmc-next when mmc-next has moved to 3.1
code base.

Thanks,
Per

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

Re: [PATCH --mmotm v5 0/3] Make fault injection available for MMC IO

[Akinobu Mita]

All three patches look good.
Acked-by: Akinobu Mita 

2011/8/9 Per Forlin :
> This patchset is sent to the mm-tree because it depends on Akinobu's patch
> "fault-injection: add ability to export fault_attr in..."

That patch has already been merged in mainline.

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

Re: [PATCH --mmotm v5 0/3] Make fault injection available for MMC IO

[Per Forlin]

On 9 August 2011 11:24, Akinobu Mita  wrote:
> 2011/8/9 Per Forlin :
>
>> Patch #1 "fault-injection: export fault injection functions" is merged
>
> Maybe you are looking at wrong tree.  I can't find it in Linus' tree or
> mmotm patches.
>
Thanks for double checking! I looked at the wrong tree. What a mess I
am creating.
Do you think it would be possible to get only the export
fault-injection patch in 3.1? I know it's not a bugfix so I guess it
wont be accepted.
I'll prepare v6 of this patch-set.

Thanks for your help,
Per

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

Re: [PATCH --mmotm v5 0/3] Make fault injection available for MMC IO

[Akinobu Mita]

2011/8/9 Per Forlin :

> Patch #1 "fault-injection: export fault injection functions" is merged

Maybe you are looking at wrong tree.  I can't find it in Linus' tree or
mmotm patches.

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

[PATCH --mmotm v6 1/3] fault-inject: export fault injection functions

[Per Forlin]

export symbols should_fail() and fault_create_debugfs_attr() in order
to let modules utilize the fault injection

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 lib/fault-inject.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/fault-inject.c b/lib/fault-inject.c
index f193b77..328d433 100644
--- a/lib/fault-inject.c
+++ b/lib/fault-inject.c
@@ -130,6 +130,7 @@ bool should_fail(struct fault_attr *attr, ssize_t size)
 
return true;
 }
+EXPORT_SYMBOL_GPL(should_fail);
 
 #ifdef CONFIG_FAULT_INJECTION_DEBUG_FS
 
@@ -243,5 +244,6 @@ fail:
 
return ERR_PTR(-ENOMEM);
 }
+EXPORT_SYMBOL_GPL(fault_create_debugfs_attr);
 
 #endif /* CONFIG_FAULT_INJECTION_DEBUG_FS */
-- 
1.7.4.1


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

[PATCH --mmotm v6 0/3] Make fault injection available for MMC IO

[Per Forlin]

change log:
 v2 - Resolve build issue in mmc core.c due to multiple init_module by
  removing the fault inject module.
- Export fault injection functions to make them available for modules
- Update fault injection documentation on MMC IO  
 v3 - add function descriptions in core.c
- use export GPL for fault injection functions
 v4 - make the fault_attr per host. This prepares for upcoming patch from
  Akinobu that adds support for creating debugfs entries in
  arbitrary directory.
 v5 - Make use of fault_create_debugfs_attr() in Akinobu's
  patch "fault-injection: add ability to export fault_attr in...". 
 v6 - Fix typo in commit message in patch "export fault injection functions"

Per Forlin (3):
  fault-inject: export fault injection functions
  mmc: core: add random fault injection
  fault injection: add documentation on MMC IO fault injection

 Documentation/fault-injection/fault-injection.txt |5 ++
 drivers/mmc/core/core.c   |   44 +
 drivers/mmc/core/debugfs.c|   24 +++
 include/linux/mmc/host.h  |7 +++
 lib/Kconfig.debug |   11 +
 lib/fault-inject.c|2 +
 6 files changed, 93 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 --mmotm v6 3/3] fault injection: add documentation on MMC IO fault injection

[Per Forlin]

Add description on how to enable random fault injection
for MMC IO

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 Documentation/fault-injection/fault-injection.txt |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Documentation/fault-injection/fault-injection.txt 
b/Documentation/fault-injection/fault-injection.txt
index 82a5d25..10571df 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -21,6 +21,11 @@ o fail_make_request
   /sys/block//make-it-fail or
   /sys/block///make-it-fail. (generic_make_request())
 
+o fail_mmc_request
+
+  injects MMC data errors on devices permitted by setting
+  debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
+
 Configure fault-injection capabilities behavior
 ---
 
-- 
1.7.4.1


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

[PATCH --mmotm v6 2/3] mmc: core: add random fault injection

[Per Forlin]

This adds support to inject data errors after a completed host transfer.
The mmc core will return error even though the host transfer is successful.
This simple fault injection proved to be very useful to test the
non-blocking error handling in the mmc_blk_issue_rw_rq().
Random faults can also test how the host driver handles pre_req()
and post_req() in case of errors.

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 drivers/mmc/core/core.c|   44 
 drivers/mmc/core/debugfs.c |   24 
 include/linux/mmc/host.h   |7 +++
 lib/Kconfig.debug  |   11 +++
 4 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 89bdeae..a4996b0 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -25,6 +25,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#include 
+#endif
+
 #include 
 #include 
 #include 
@@ -83,6 +88,43 @@ static void mmc_flush_scheduled_work(void)
flush_workqueue(workqueue);
 }
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+/*
+ * Internal function. Inject random data errors.
+ * If mmc_data is NULL no errors are injected.
+ */
+static void mmc_should_fail_request(struct mmc_host *host,
+   struct mmc_request *mrq)
+{
+   struct mmc_command *cmd = mrq->cmd;
+   struct mmc_data *data = mrq->data;
+   static const int data_errors[] = {
+   -ETIMEDOUT,
+   -EILSEQ,
+   -EIO,
+   };
+
+   if (!data)
+   return;
+
+   if (cmd->error || data->error ||
+   !should_fail(&host->fail_mmc_request, data->blksz * data->blocks))
+   return;
+
+   data->error = data_errors[random32() % ARRAY_SIZE(data_errors)];
+   data->bytes_xfered = (random32() % (data->bytes_xfered >> 9)) << 9;
+}
+
+#else /* CONFIG_FAIL_MMC_REQUEST */
+
+static void mmc_should_fail_request(struct mmc_host *host,
+   struct mmc_request *mrq)
+{
+}
+
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
 /**
  * mmc_request_done - finish processing an MMC request
  * @host: MMC host which completed request
@@ -109,6 +151,8 @@ void mmc_request_done(struct mmc_host *host, struct 
mmc_request *mrq)
cmd->error = 0;
host->ops->request(host, mrq);
} else {
+   mmc_should_fail_request(host, mrq);
+
led_trigger_event(host->led, LED_OFF);
 
pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index f573753..548c2e7 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -13,6 +13,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#endif
 
 #include 
 #include 
@@ -159,6 +162,20 @@ static int mmc_clock_opt_set(void *data, u64 val)
return 0;
 }
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+static DECLARE_FAULT_ATTR(fail_mmc_request);
+/*
+ * Internal function. Pass the boot param fail_mmc_request to
+ * the setup fault injection attributes routine.
+ */
+static int __init setup_fail_mmc_request(char *str)
+{
+   return setup_fault_attr(&fail_mmc_request, str);
+}
+__setup("fail_mmc_request=", setup_fail_mmc_request);
+#endif
+
 DEFINE_SIMPLE_ATTRIBUTE(mmc_clock_fops, mmc_clock_opt_get, mmc_clock_opt_set,
"%llu\n");
 
@@ -189,6 +206,13 @@ void mmc_add_host_debugfs(struct mmc_host *host)
root, &host->clk_delay))
goto err_node;
 #endif
+#ifdef CONFIG_FAIL_MMC_REQUEST
+   host->fail_mmc_request = fail_mmc_request;
+   if (IS_ERR(fault_create_debugfs_attr("fail_mmc_request",
+root,
+&host->fail_mmc_request)))
+   goto err_node;
+#endif
return;
 
 err_node:
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 0f83858..ee472fe 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -12,6 +12,9 @@
 
 #include 
 #include 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#endif
 
 #include 
 #include 
@@ -304,6 +307,10 @@ struct mmc_host {
 
struct mmc_async_req*areq;  /* active async req */
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+   struct fault_attr   fail_mmc_request;
+#endif
+
unsigned long   private[0] cacheline_aligned;
 };
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 47879c7..ebff0c9 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1090,6 +1090,17 @@ config FAIL_IO_TIMEOUT
  Only works with drivers that use the generic timeout handling,
  for others it wont do anything.
 
+config FAIL_MMC_REQUEST
+   bool "Fault-injection capability for MMC IO"
+   select DEBUG_FS
+   depends on FAULT_INJECTION && MMC
+   h

Re: [PATCH --mmotm v5 0/3] Make fault injection available for MMC IO

[Akinobu Mita]

2011/8/9 Per Forlin :

> Do you think it would be possible to get only the export
> fault-injection patch in 3.1? I know it's not a bugfix so I guess it
> wont be accepted.

No modules except mmc plan to use those symbols.  So I think there is
no reason to merge them separately.

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

Re: [PATCH v4 1/2] ARMV7: Add support for Samsung ORIGEN board

[Chander Kashyap]

Dear Wolfgang Denk,

On 3 August 2011 09:17, Chander Kashyap  wrote:

> Dear Wolfgang Denk,
>
> On 31 July 2011 15:30, Wolfgang Denk  wrote:
>
>> Dear Chander Kashyap,
>>
>> In message <1311914519-10531-2-git-send-email-chander.kash...@linaro.org>
>> you wrote:
>> > Origen board is based upon S5PV310 SoC which is similiar to
>> > S5PC210 SoC.
>> >
>> > Signed-off-by: Chander Kashyap 
>> ...
>> > + /* APLL(1), MPLL(1), CORE(0), HPM(0) */
>> > + ldr r1, =0x0101
>> > + ldr r2, =0x14200@CLK_SRC_CPU
>> ...
>> > + mov r1, #0x1
>> ...
>> > + ldr r1, =0x00
>> > + ldr r2, =0x0C210@CLK_SRC_TOP0
>> ...
>> > + ldr r1, =0x00
>> > + ldr r2, =0x0C214@CLK_SRC_TOP1_OFFSET
>> ...
>> > + ldr r1, =0x1
>> > + ldr r2, =0x10200@CLK_SRC_DMC_OFFSET
>> ...
>>
>> ..
>> > + /*
>> > +  * CLK_DIV_DMC0:
>> > +  *
>> > +  * CORE_TIMERS_RATIO[28]0x1
>> > +  * COPY2_RATIO[24]  0x3
>> > +  * DMCP_RATIO[20]   0x1
>> > +  * DMCD_RATIO[16]   0x1
>> > +  * DMC_RATIO[12]0x1
>> > +  * DPHY_RATIO[8]0x1
>> > +  * ACP_PCLK_RATIO[4]0x1
>> > +  * ACP_RATIO[0] 0x3
>> > +  */
>> > + ldr r1, =0x1313
>> > + ldr r2, =0x010500   @CLK_DIV_DMC0_OFFSET
>> > + str r1, [r0, r2]
>>
>>
>> lease get rid of all these magic hard coded constants.  Use symbolic
>> names instead. If needed, auto-generate these from the respective C
>> structs.  If needed, create the C structs.
>>
>
> I will change hard coded values to  symbolic names
>

While doing this, I find that the values written to the registers are used
just once. So do you still prefer to have them as macros ? I did convert the
register offsets and addresses to macros, but did not find it right to have
macros for register values that are used just once. Please advise.


>> ...
>> > --- /dev/null
>> > +++ b/board/samsung/origen/mem_setup.S
>> > @@ -0,0 +1,359 @@
>>
>> What exactly is the reeason for not coding this in C ?
>>
>> ...
>> > +#ifdef CONFIG_MIU_1BIT_12_INTERLEAVED
>> > + ldr r1, =0x000c
>> > + str r1, [r0, #0x400]
>> > + ldr r1, =0x0001
>> > + str r1, [r0, #0xc00]
>> > +#elif defined(CONFIG_MIU_1BIT_7_INTERLEAVED)
>> > + ldr r1, =0x0007
>> > + str r1, [r0, #0x400]
>> > + ldr r1, =0x0001
>> > + str r1, [r0, #0xc00]
>> > +#elif defined(CONFIG_MIU_2BIT_21_12_INTERLEAVED)
>> > + ldr r1, =0x2000150c
>> > + str r1, [r0, #0x400]
>> > + ldr r1, =0x0001
>> > + str r1, [r0, #0xc00]
>> > +#elif defined(CONFIG_MIU_2BIT_21_7_INTERLEAVED)
>> > + ldr r1, =0x20001507
>> > + str r1, [r0, #0x400]
>> > + ldr r1, =0x0001
>> > + str r1, [r0, #0xc00]
>> > +#elif defined(CONFIG_MIU_2BIT_31_INTERLEAVED)
>> > + ldr r1, =0x001d
>> > + str r1, [r0, #0x400]
>> > + ldr r1, =0x0001
>> > + str r1, [r0, #0xc00]
>>
>> See above.  Please get rid of all these hard-ciooded magic numbers.
>> [Eventually this happens automativcally when you rewrite this in C.]
>
> I will use symbolic names.
>
>>
>> > +int dram_init(void)
>> > +{
>> > + gd->ram_size= get_ram_size((long *)PHYS_SDRAM_1,
>> PHYS_SDRAM_1_SIZE)
>> > + + get_ram_size((long *)PHYS_SDRAM_2,
>> PHYS_SDRAM_2_SIZE)
>> > + + get_ram_size((long *)PHYS_SDRAM_3,
>> PHYS_SDRAM_3_SIZE)
>> > + + get_ram_size((long *)PHYS_SDRAM_4,
>> PHYS_SDRAM_4_SIZE);
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +void dram_init_banksize(void)
>> > +{
>> > + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
>> > + gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
>> > + gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
>> > + gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
>> > + gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
>> > + gd->bd->bi_dram[2].size = PHYS_SDRAM_3_SIZE;
>> > + gd->bd->bi_dram[3].start = PHYS_SDRAM_4;
>> > + gd->bd->bi_dram[3].size = PHYS_SDRAM_4_SIZE;
>> > +}
>>
>> How do you detect memory issues in one of the memory banks, say, a
>> memory error in bank 3?
>>
>  get_ram_size will take care for it.
>
>
>> > diff --git a/include/configs/origen.h b/include/configs/origen.h
>> > new file mode 100644
>> > index 000..3cd9bfe
>> > --- /dev/null
>> > +++ b/include/configs/origen.h
>> ...
>> > +#define COPY_BL2_SIZE0x8
>> > +#define BL2_START_OFFSET ((CONFIG_ENV_OFFSET +
>> CONFIG_ENV_SIZE)/512)
>> > +#define BL2_SIZE_BLOC_COUNT  (COPY_BL2_SIZE/512)
>>
>> Some of the defines in this file are not used anywhere in the code
>> (for example, COPY_BL2_SIZE, COPY_BL2_SIZEBL2_START_OFFSET or
>> BL2_SIZE_BLOC_COUNT.  Please remove unused defines from this patch.

Re: Switching to Gerrit for Android code hosting - last stage

[Paul Sokolovsky]

Hello James,

On Sat, 06 Aug 2011 07:56:17 +0100
James Westby  wrote:

> On Fri, 5 Aug 2011 15:57:59 +0100, Paul Sokolovsky
>  wrote:
> > Hello,
> > 
> > Following today's work session preparing to switching Gerrit,
> > everything is ready for the cutover now:
> > 
> > First build from Gerrit repositories is finished successfully:
> > https://android-build.linaro.org/jenkins/job/pfalcon_beagle-gerrit/4
> > 
> > Gerrit Web UI is migrated to the final location:
> > http://review.android.git.linaro.org/
> > 
> > Gitweb is installed at
> > http://android.git.linaro.org/gitweb
> > 
> > Anon git access to repositories in Gerrit available via
> > git://android.git.linaro.org/...
> > 
> > 
> > It's too late to do the cutover now of course, so I'd like to
> > propose to do it on Wed 10th to be sure that all folks are ba
> > from the Connect and final bits are settled.
> 
> Hi,
> 
> This sounds fine to me. Do you anticipate that this step will require
> any coordination with IS?

Setting old tree at git.linaro.org to r/o may require their help. It
depends on specific permissions set in FS, which may be inconsistent.
And I wonder if it makes sense to not just set it r/o, but also rename,
say set prefix to android-old/ instead of android/, to make sure people
don't use old tree. But that again leads to a question of what to do
with our older releases which still point to it.

> 
> Thanks,
> 
> James



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

[PATCH --mmotm v7 3/3] fault injection: add documentation on MMC IO fault injection

[Per Forlin]

Add description on how to enable random fault injection
for MMC IO

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 Documentation/fault-injection/fault-injection.txt |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Documentation/fault-injection/fault-injection.txt 
b/Documentation/fault-injection/fault-injection.txt
index 82a5d25..10571df 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -21,6 +21,11 @@ o fail_make_request
   /sys/block//make-it-fail or
   /sys/block///make-it-fail. (generic_make_request())
 
+o fail_mmc_request
+
+  injects MMC data errors on devices permitted by setting
+  debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
+
 Configure fault-injection capabilities behavior
 ---
 
-- 
1.7.4.1


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

[PATCH --mmotm v7 1/3] fault-inject: export fault injection functions

[Per Forlin]

export symbols should_fail() and fault_create_debugfs_attr() in order
to let modules utilize the fault injection

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 lib/fault-inject.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/fault-inject.c b/lib/fault-inject.c
index f193b77..328d433 100644
--- a/lib/fault-inject.c
+++ b/lib/fault-inject.c
@@ -130,6 +130,7 @@ bool should_fail(struct fault_attr *attr, ssize_t size)
 
return true;
 }
+EXPORT_SYMBOL_GPL(should_fail);
 
 #ifdef CONFIG_FAULT_INJECTION_DEBUG_FS
 
@@ -243,5 +244,6 @@ fail:
 
return ERR_PTR(-ENOMEM);
 }
+EXPORT_SYMBOL_GPL(fault_create_debugfs_attr);
 
 #endif /* CONFIG_FAULT_INJECTION_DEBUG_FS */
-- 
1.7.4.1


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

[PATCH --mmotm v7 2/3] mmc: core: add random fault injection

[Per Forlin]

This adds support to inject data errors after a completed host transfer.
The mmc core will return error even though the host transfer is successful.
This simple fault injection proved to be very useful to test the
non-blocking error handling in the mmc_blk_issue_rw_rq().
Random faults can also test how the host driver handles pre_req()
and post_req() in case of errors.

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 drivers/mmc/core/core.c|   44 
 drivers/mmc/core/debugfs.c |   27 +++
 include/linux/mmc/host.h   |7 +++
 lib/Kconfig.debug  |   11 +++
 4 files changed, 89 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 89bdeae..a4996b0 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -25,6 +25,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#include 
+#endif
+
 #include 
 #include 
 #include 
@@ -83,6 +88,43 @@ static void mmc_flush_scheduled_work(void)
flush_workqueue(workqueue);
 }
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+/*
+ * Internal function. Inject random data errors.
+ * If mmc_data is NULL no errors are injected.
+ */
+static void mmc_should_fail_request(struct mmc_host *host,
+   struct mmc_request *mrq)
+{
+   struct mmc_command *cmd = mrq->cmd;
+   struct mmc_data *data = mrq->data;
+   static const int data_errors[] = {
+   -ETIMEDOUT,
+   -EILSEQ,
+   -EIO,
+   };
+
+   if (!data)
+   return;
+
+   if (cmd->error || data->error ||
+   !should_fail(&host->fail_mmc_request, data->blksz * data->blocks))
+   return;
+
+   data->error = data_errors[random32() % ARRAY_SIZE(data_errors)];
+   data->bytes_xfered = (random32() % (data->bytes_xfered >> 9)) << 9;
+}
+
+#else /* CONFIG_FAIL_MMC_REQUEST */
+
+static void mmc_should_fail_request(struct mmc_host *host,
+   struct mmc_request *mrq)
+{
+}
+
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
 /**
  * mmc_request_done - finish processing an MMC request
  * @host: MMC host which completed request
@@ -109,6 +151,8 @@ void mmc_request_done(struct mmc_host *host, struct 
mmc_request *mrq)
cmd->error = 0;
host->ops->request(host, mrq);
} else {
+   mmc_should_fail_request(host, mrq);
+
led_trigger_event(host->led, LED_OFF);
 
pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index f573753..189581d 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -13,6 +13,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#endif
 
 #include 
 #include 
@@ -159,6 +162,23 @@ static int mmc_clock_opt_set(void *data, u64 val)
return 0;
 }
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+static DECLARE_FAULT_ATTR(fail_mmc_request);
+
+#ifdef KERNEL
+/*
+ * Internal function. Pass the boot param fail_mmc_request to
+ * the setup fault injection attributes routine.
+ */
+static int __init setup_fail_mmc_request(char *str)
+{
+   return setup_fault_attr(&fail_mmc_request, str);
+}
+__setup("fail_mmc_request=", setup_fail_mmc_request);
+#endif /* KERNEL */
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
 DEFINE_SIMPLE_ATTRIBUTE(mmc_clock_fops, mmc_clock_opt_get, mmc_clock_opt_set,
"%llu\n");
 
@@ -189,6 +209,13 @@ void mmc_add_host_debugfs(struct mmc_host *host)
root, &host->clk_delay))
goto err_node;
 #endif
+#ifdef CONFIG_FAIL_MMC_REQUEST
+   host->fail_mmc_request = fail_mmc_request;
+   if (IS_ERR(fault_create_debugfs_attr("fail_mmc_request",
+root,
+&host->fail_mmc_request)))
+   goto err_node;
+#endif
return;
 
 err_node:
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 0f83858..ee472fe 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -12,6 +12,9 @@
 
 #include 
 #include 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#endif
 
 #include 
 #include 
@@ -304,6 +307,10 @@ struct mmc_host {
 
struct mmc_async_req*areq;  /* active async req */
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+   struct fault_attr   fail_mmc_request;
+#endif
+
unsigned long   private[0] cacheline_aligned;
 };
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 47879c7..ebff0c9 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1090,6 +1090,17 @@ config FAIL_IO_TIMEOUT
  Only works with drivers that use the generic timeout handling,
  for others it wont do anything.
 
+config FAIL_MMC_REQUEST
+   bool "Fault-injection capability for MMC IO"
+   

[PATCH --mmotm v7 0/3] Make fault injection available for MMC IO

[Per Forlin]

change log:
 v2 - Resolve build issue in mmc core.c due to multiple init_module by
  removing the fault inject module.
- Export fault injection functions to make them available for modules
- Update fault injection documentation on MMC IO  
 v3 - add function descriptions in core.c
- use export GPL for fault injection functions
 v4 - make the fault_attr per host. This prepares for upcoming patch from
  Akinobu that adds support for creating debugfs entries in
  arbitrary directory.
 v5 - Make use of fault_create_debugfs_attr() in Akinobu's
  patch "fault-injection: add ability to export fault_attr in...". 
 v6 - Fix typo in commit message in patch "export fault injection functions"
 v7 - Don't compile in boot param setup function if mmc-core is
  built as module.

Per Forlin (3):
  fault-inject: export fault injection functions
  mmc: core: add random fault injection
  fault injection: add documentation on MMC IO fault injection

 Documentation/fault-injection/fault-injection.txt |5 ++
 drivers/mmc/core/core.c   |   44 +
 drivers/mmc/core/debugfs.c|   27 +
 include/linux/mmc/host.h  |7 +++
 lib/Kconfig.debug |   11 +
 lib/fault-inject.c|2 +
 6 files changed, 96 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 --mmotm v8 0/3] Make fault injection available for MMC IO

[Per Forlin]

change log:
 v2 - Resolve build issue in mmc core.c due to multiple init_module by
  removing the fault inject module.
- Export fault injection functions to make them available for modules
- Update fault injection documentation on MMC IO  
 v3 - add function descriptions in core.c
- use export GPL for fault injection functions
 v4 - make the fault_attr per host. This prepares for upcoming patch from
  Akinobu that adds support for creating debugfs entries in
  arbitrary directory.
 v5 - Make use of fault_create_debugfs_attr() in Akinobu's
  patch "fault-injection: add ability to export fault_attr in...". 
 v6 - Fix typo in commit message in patch "export fault injection functions"
 v7 - Don't compile in boot param setup function if mmc-core is
  built as module.
 v8 - Update fault injection documentation.
  Add fail_mmc_request to boot option section. 

Per Forlin (3):
  fault-inject: export fault injection functions
  mmc: core: add random fault injection
  fault injection: add documentation on MMC IO fault injection

 Documentation/fault-injection/fault-injection.txt |8 +++-
 drivers/mmc/core/core.c   |   44 +
 drivers/mmc/core/debugfs.c|   27 +
 include/linux/mmc/host.h  |7 +++
 lib/Kconfig.debug |   11 +
 lib/fault-inject.c|2 +
 6 files changed, 98 insertions(+), 1 deletions(-)

-- 
1.7.4.1


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

[PATCH --mmotm v8 1/3] fault-inject: export fault injection functions

[Per Forlin]

export symbols should_fail() and fault_create_debugfs_attr() in order
to let modules utilize the fault injection

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 lib/fault-inject.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/fault-inject.c b/lib/fault-inject.c
index f193b77..328d433 100644
--- a/lib/fault-inject.c
+++ b/lib/fault-inject.c
@@ -130,6 +130,7 @@ bool should_fail(struct fault_attr *attr, ssize_t size)
 
return true;
 }
+EXPORT_SYMBOL_GPL(should_fail);
 
 #ifdef CONFIG_FAULT_INJECTION_DEBUG_FS
 
@@ -243,5 +244,6 @@ fail:
 
return ERR_PTR(-ENOMEM);
 }
+EXPORT_SYMBOL_GPL(fault_create_debugfs_attr);
 
 #endif /* CONFIG_FAULT_INJECTION_DEBUG_FS */
-- 
1.7.4.1


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

[PATCH --mmotm v8 2/3] mmc: core: add random fault injection

[Per Forlin]

This adds support to inject data errors after a completed host transfer.
The mmc core will return error even though the host transfer is successful.
This simple fault injection proved to be very useful to test the
non-blocking error handling in the mmc_blk_issue_rw_rq().
Random faults can also test how the host driver handles pre_req()
and post_req() in case of errors.

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 drivers/mmc/core/core.c|   44 
 drivers/mmc/core/debugfs.c |   27 +++
 include/linux/mmc/host.h   |7 +++
 lib/Kconfig.debug  |   11 +++
 4 files changed, 89 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 89bdeae..a4996b0 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -25,6 +25,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#include 
+#endif
+
 #include 
 #include 
 #include 
@@ -83,6 +88,43 @@ static void mmc_flush_scheduled_work(void)
flush_workqueue(workqueue);
 }
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+/*
+ * Internal function. Inject random data errors.
+ * If mmc_data is NULL no errors are injected.
+ */
+static void mmc_should_fail_request(struct mmc_host *host,
+   struct mmc_request *mrq)
+{
+   struct mmc_command *cmd = mrq->cmd;
+   struct mmc_data *data = mrq->data;
+   static const int data_errors[] = {
+   -ETIMEDOUT,
+   -EILSEQ,
+   -EIO,
+   };
+
+   if (!data)
+   return;
+
+   if (cmd->error || data->error ||
+   !should_fail(&host->fail_mmc_request, data->blksz * data->blocks))
+   return;
+
+   data->error = data_errors[random32() % ARRAY_SIZE(data_errors)];
+   data->bytes_xfered = (random32() % (data->bytes_xfered >> 9)) << 9;
+}
+
+#else /* CONFIG_FAIL_MMC_REQUEST */
+
+static void mmc_should_fail_request(struct mmc_host *host,
+   struct mmc_request *mrq)
+{
+}
+
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
 /**
  * mmc_request_done - finish processing an MMC request
  * @host: MMC host which completed request
@@ -109,6 +151,8 @@ void mmc_request_done(struct mmc_host *host, struct 
mmc_request *mrq)
cmd->error = 0;
host->ops->request(host, mrq);
} else {
+   mmc_should_fail_request(host, mrq);
+
led_trigger_event(host->led, LED_OFF);
 
pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index f573753..189581d 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -13,6 +13,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#endif
 
 #include 
 #include 
@@ -159,6 +162,23 @@ static int mmc_clock_opt_set(void *data, u64 val)
return 0;
 }
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+static DECLARE_FAULT_ATTR(fail_mmc_request);
+
+#ifdef KERNEL
+/*
+ * Internal function. Pass the boot param fail_mmc_request to
+ * the setup fault injection attributes routine.
+ */
+static int __init setup_fail_mmc_request(char *str)
+{
+   return setup_fault_attr(&fail_mmc_request, str);
+}
+__setup("fail_mmc_request=", setup_fail_mmc_request);
+#endif /* KERNEL */
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
 DEFINE_SIMPLE_ATTRIBUTE(mmc_clock_fops, mmc_clock_opt_get, mmc_clock_opt_set,
"%llu\n");
 
@@ -189,6 +209,13 @@ void mmc_add_host_debugfs(struct mmc_host *host)
root, &host->clk_delay))
goto err_node;
 #endif
+#ifdef CONFIG_FAIL_MMC_REQUEST
+   host->fail_mmc_request = fail_mmc_request;
+   if (IS_ERR(fault_create_debugfs_attr("fail_mmc_request",
+root,
+&host->fail_mmc_request)))
+   goto err_node;
+#endif
return;
 
 err_node:
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 0f83858..ee472fe 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -12,6 +12,9 @@
 
 #include 
 #include 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+#include 
+#endif
 
 #include 
 #include 
@@ -304,6 +307,10 @@ struct mmc_host {
 
struct mmc_async_req*areq;  /* active async req */
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+   struct fault_attr   fail_mmc_request;
+#endif
+
unsigned long   private[0] cacheline_aligned;
 };
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 47879c7..ebff0c9 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1090,6 +1090,17 @@ config FAIL_IO_TIMEOUT
  Only works with drivers that use the generic timeout handling,
  for others it wont do anything.
 
+config FAIL_MMC_REQUEST
+   bool "Fault-injection capability for MMC IO"
+   

[PATCH --mmotm v8 3/3] fault injection: add documentation on MMC IO fault injection

[Per Forlin]

Add description on how to enable random fault injection
for MMC IO

Signed-off-by: Per Forlin 
Acked-by: Akinobu Mita 
---
 Documentation/fault-injection/fault-injection.txt |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/Documentation/fault-injection/fault-injection.txt 
b/Documentation/fault-injection/fault-injection.txt
index 82a5d25..70f924e 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -21,6 +21,11 @@ o fail_make_request
   /sys/block//make-it-fail or
   /sys/block///make-it-fail. (generic_make_request())
 
+o fail_mmc_request
+
+  injects MMC data errors on devices permitted by setting
+  debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
+
 Configure fault-injection capabilities behavior
 ---
 
@@ -115,7 +120,8 @@ use the boot option:
 
failslab=
fail_page_alloc=
-   fail_make_request=,,,
+   fail_make_request=
+   fail_mmc_request=,,,
 
 How to add new fault injection capability
 -
-- 
1.7.4.1


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

Re: Problems with linaro-android_toolchain-4.6-2011.07 rebuilds

[Paul Sokolovsky]

Hello Alexander,

On Mon, 8 Aug 2011 12:39:41 +0200
Alexander Sack  wrote:

> ok spads from IS gave better suggestion than using umask in .bashrc.
> Now, we propose that you set alias for git like:
> 
> alias git='UMASK=002 git'

I understand the logic here - set umask only for git, but would that
really work? I kinda get used that aliases are interactive session
thing, and man reads:

   Aliases are not expanded when the shell is not interactive,
   unless the expand_aliases shell option is set using shopt  (see
   the description of shopt under SHELL BUILTIN COMMANDS below).

I'm not sure how exactly git over ssh works though.


And whatever way of umask setting should be, did IS consider
implementing it via global /etc/profile or via profile templates clones
by adduser or similar tool, to alleviate that burden for the users?

> 
> Please update accordingly.
> Thanks!
> 
> On Mon, Aug 8, 2011 at 11:51 AM, Alexander Sack 
> wrote:
> > this should be fixed now. folks, please use:
> >
> > umask 002
> >
> > in your .bashrc -> ssh git.linaro.org -> change .bashrc there.
> >
> > I guess from now on we could consider to use gerrit for toolchain
> > etc. too.
> >
> > Thanks!
> >
> > On Sun, Aug 7, 2011 at 8:16 PM, James Westby
> >  wrote:
> >> On Sun, 7 Aug 2011 02:25:17 +0100, Zach Pfeffer
> >>  wrote:
> >>> I'm seeing the same thing:
> >>>
> >>> $git push linaro  HEAD
> >>> Counting objects: 5, done.
> >>> Delta compression using up to 4 threads.
> >>> Compressing objects: 100% (2/2), done.
> >>> Writing objects: 100% (3/3), 454 bytes, done.
> >>> Total 3 (delta 1), reused 0 (delta 0)
> >>> error: insufficient permission for adding an object to repository
> >>> database ./objects
> >>>
> >>> fatal: failed to write object
> >>> error: unpack failed: unpack-objects abnormal exit
> >>> To
> >>> ssh://pfeff...@git.linaro.org/srv/git.linaro.org/git/android/toolchain/manifest.git
> >>>  !
> >>> [remote rejected] HEAD -> toolchain-11.07-release (n/a (unpacker
> >>> error)) error: failed to push some refs to
> >>> 'ssh://pfeff...@git.linaro.org/srv/git.linaro.org/git/android/toolchain/manifest.git'
> >>>
> >>> Any ideas Paul?
> >>
> >> The issue is that someone is pushing to these trees with a UMASK
> >> that prevents others in the group from writing some files to them.
> >> If you are pushing something that contains an object that needs to
> >> go in a dir created by someone pushing with a restrictive UMASK
> >> you will see this.
> >>
> >> You can file an RT ticket to get a chmod -R g+w on these trees.
> >>
> >> Please also make sure that if you are pushing to git.linaro.org
> >> you set your UMASK on that system to allow group write on
> >> files/dirs that you create.
> >>
> >> Thanks,
> >>
> >> James
> >>
> >
> >
> >
> > --
> >
> >  - Alexander
> >
> 
> 
> 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Re: Problems with linaro-android_toolchain-4.6-2011.07 rebuilds

[Andy Doan]

On 08/09/2011 07:26 AM, Paul Sokolovsky wrote:
> Hello Alexander,
> 
> On Mon, 8 Aug 2011 12:39:41 +0200
> Alexander Sack  wrote:
> 
>> ok spads from IS gave better suggestion than using umask in .bashrc.
>> Now, we propose that you set alias for git like:
>>
>> alias git='UMASK=002 git'
> 
> I understand the logic here - set umask only for git, but would that
> really work? I kinda get used that aliases are interactive session
> thing, and man reads:
> 
>Aliases are not expanded when the shell is not interactive,
>unless the expand_aliases shell option is set using shopt  (see
>the description of shopt under SHELL BUILTIN COMMANDS below).
> 
> I'm not sure how exactly git over ssh works though.
> 
> 
> And whatever way of umask setting should be, did IS consider
> implementing it via global /etc/profile or via profile templates clones
> by adduser or similar tool, to alleviate that burden for the users?

There's another way to do this which doesn't require updating UMASK's or
aliases. You can use setfacl as described here:
  https://wincent.com/wiki/Git_repository_access_control

I've used this on multiple projects.

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

Re: [Patch v1 08/11] Touch: DA9052 touchscreen driver

[Michael Grzeschik]

Hi Ashish,

On Thu, Jul 14, 2011 at 02:28:10PM +0530, ashishj3 wrote:
> This driver add support for DA9052 4-wire resistive ADC interfaced touchscreen
> controller.
> 
> DA9052 is a MFD therefore this driver depends on DA9052 core driver for core
> functionalities.
> 
> Signed-off-by: David Dajun Chen 
> Signed-off-by: Ashish Jangam 
> ---
>  drivers/input/touchscreen/Kconfig  |7 +
>  drivers/input/touchscreen/Makefile |1 +
>  drivers/input/touchscreen/da9052_tsi.c |  489 
> 
>  3 files changed, 497 insertions(+), 0 deletions(-)
>  create mode 100755 drivers/input/touchscreen/da9052_tsi.c
[snip]
> + ret = da9052_clear_bits(da9052, DA9052_GPIO_4_5_REG, 0x33);
> + if (ret < 0)
> + return -EIO;
> +
> + ret = da9052_clear_bits(da9052, DA9052_GPIO_6_7_REG, 0x33);

Those two register defines are missing in your posted MFD driver headerfile 
"reg.h".

Regards,
Michael

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

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

[RFC PATCH] da9052_tsi: remove fifo and use delayed work

[Michael Grzeschik]

Remove the coordinate fifo and check for penup with a delayed work,
instead of a watching kernel thread.

Issues:
Sometimes there are well defined jitter values on the x-axys this must
be more investigated. Hint: DA9052_TSI_CONT_A_REG holds some time Adjust
values for TSI_SKIP and TSI_DELAY, which might have to be properly
aligned to the touch events.

Signed-off-by: Michael Grzeschik 
---
 drivers/input/touchscreen/da9052_tsi.c |  245 
 1 files changed, 61 insertions(+), 184 deletions(-)

diff --git a/drivers/input/touchscreen/da9052_tsi.c 
b/drivers/input/touchscreen/da9052_tsi.c
index 91e051a..91d489f 100755
--- a/drivers/input/touchscreen/da9052_tsi.c
+++ b/drivers/input/touchscreen/da9052_tsi.c
@@ -15,47 +15,24 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
-#include 
 
 #include 
 #include 
 
-#define DA9052_ACTIVE  1
-#define DA9052_INACTIVE0
-
-#define DA9052_TSI_FIFOSIZE640
-
-enum {
-   DA9052_PEN_IDLE,
-   DA9052_PEN_DOWN,
-   DA9052_PEN_UP
-};
-
 struct da9052_tsi_reg {
u16 x;
u16 y;
 };
 
-struct tsi_thread_type {
-   u8  pid;
-   u8  state;
-   struct completion   notifier;
-   struct task_struct  *thread_task;
-};
-
 struct da9052_tsi {
struct da9052   *da9052;
struct input_dev *dev;
-   struct tsi_thread_type  tsi_pen_state_thread;
-   struct tsi_thread_type  tsi_filter_thread;
-   struct kfifo fifo;
-   struct kfifo fifo_buf;
u8 pen_up_detect_interval;
u32 zero_data_cnt;
u32 valid_penup_count;
-   u8 pen_state;
+   struct delayed_work work;
int irq_pendwn;
int irq_datardy;
 };
@@ -71,6 +48,48 @@ static inline int da9052_ts_stop(struct da9052_tsi *tsi)
return da9052_clear_bits(tsi->da9052, DA9052_TSI_CONT_A_REG, 1 << 0);
 }
 
+static void da9052_work(struct work_struct *work)
+{
+   struct da9052_tsi *tsi = container_of(work, struct da9052_tsi, 
work.work);
+   struct da9052 *da9052 = tsi->da9052;
+   int ret;
+   uint8_t _v;
+   u16 down;
+
+   ret = da9052_reg_read(tsi->da9052, DA9052_TSI_LSB_REG);
+   if (ret < 0)
+   return;
+
+   _v = (uint8_t) ret;
+   down = ((_v & 0x40) >> 6);
+
+   if (!down) {
+   tsi->da9052->events_mask |= DA9052_E_TSI_READY;
+   tsi->da9052->events_mask &= ~DA9052_E_PEN_DOWN;
+
+   /* Mask TSI_READY event and unmask PEN_DOWN event*/
+   ret = da9052_reg_update(tsi->da9052, DA9052_IRQ_MASK_B_REG, 
0x40, 0x80);
+   if (ret < 0)
+   return;
+
+   input_report_abs(tsi->dev, ABS_PRESSURE, 0);
+   input_report_key(tsi->dev, BTN_TOUCH, 1);
+   input_sync(tsi->dev);
+   } else {
+   da9052->events_mask |= DA9052_E_PEN_DOWN;
+   da9052->events_mask &= ~DA9052_E_TSI_READY;
+
+   /* Mask PEN_DOWN event and unmask TSI_READY event*/
+   ret = da9052_reg_update(da9052, DA9052_IRQ_MASK_B_REG, 0x80, 
0x40);
+   if (ret < 0)
+   return;
+
+   /* start polling for touch_det to detect release */
+   schedule_delayed_work(&tsi->work, HZ / 50);
+   }
+
+}
+
 static irqreturn_t da9052_ts_pendwn_irq(int irq, void *data)
 {
struct da9052_tsi *tsi = (struct da9052_tsi *)data;
@@ -86,7 +105,10 @@ static irqreturn_t da9052_ts_pendwn_irq(int irq, void *data)
return IRQ_NONE;
 
da9052_ts_start(tsi);
-   tsi->pen_state = DA9052_PEN_DOWN;
+
+   input_report_abs(tsi->dev, ABS_PRESSURE, 1023);
+   input_report_key(tsi->dev, BTN_TOUCH, 0);
+   input_sync(tsi->dev);
 
return IRQ_HANDLED;
 }
@@ -118,7 +140,10 @@ static int da9052_ts_read(struct da9052_tsi *tsi)
co_ord.x = ((_x << 2) & 0x3fc) | (_v & 0x3);
co_ord.y = ((_y << 2) & 0x3fc) | ((_v & 0xc) >> 2);
 
-   ret = kfifo_in(&tsi->fifo, &co_ord, sizeof(struct da9052_tsi_reg));
+   input_report_abs(tsi->dev, ABS_X, co_ord.x);
+   input_report_abs(tsi->dev, ABS_Y, co_ord.y);
+   input_report_abs(tsi->dev, ABS_PRESSURE, 1023);
+   input_sync(tsi->dev);
 
return 0;
 }
@@ -135,131 +160,10 @@ static irqreturn_t da9052_ts_datardy_irq(int irq, void 
*data)
return IRQ_NONE;
}
 
-   return IRQ_HANDLED;
-}
-
-/*
-* Two FIFO are been used. FIFO1 is used for detecting pen up and
-* FIFO2 for reporting pen down co-ordinate.
-*/
-void da9052_ts_process_reg_data(struct da9052_tsi *tsi)
-{
-   struct da9052_tsi_reg tmp_raw_data;
-   u32 reg_data_cnt;
-   int ret;
-
-   reg_data_cnt = kfifo_len(&tsi->fifo);
-
-   while (reg_data_cnt-- > 0) {
-   ret = kfifo_out(&tsi->fifo, &tmp_raw_data,
-   sizeof(struct da9052_tsi_reg));
-  

Re: Switching to Gerrit for Android code hosting - last stage

[Paul Sokolovsky]

On Mon, 8 Aug 2011 13:07:02 +0200
Alexander Sack  wrote:

> On Mon, Aug 8, 2011 at 1:02 PM, Patrik Ryd 
> wrote:
> > Hi,
> > I have followed (and updated) the instructions
> > on https://wiki.linaro.org/Platform/Android/Gerrit .
> > I can not log in with my launchpad account. I get the message "The
> > requested URL /OpenID was not found on this server."
> 
> I can confirm this issue. Guess the gerrit config was not changed to
> the new review.android.git.linaro.org url but still refers to the old
> android.git.linaro.org host which has the git itself now.

Cannot fix this myself, submitted
https://rt.linaro.org/Ticket/Display.html?id=56 . In the meantime, it's
still possible to "login" with manual URL munging in case it's needed
urgently.

> 
> 



-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Re: [PATCH v3] usb: gadget: storage_common: make FSG_NUM_BUFFERS variable size

[Felipe Balbi]

Hi,

On Tue, Aug 09, 2011 at 09:57:19AM -0400, Alan Stern wrote:
> On Mon, 8 Aug 2011, Per Forlin wrote:
> 
> > FSG_NUM_BUFFERS is set to 2 as default.
> > Usually 2 buffers are enough to establish a good buffering pipeline.
> > The number may be increased in order to compensate a for bursty VFS
> > behaviour.
> > 
> > Here follows a description of system that may require more than
> > 2 buffers.
> >  * CPU ondemand governor active
> >  * latency cost for wake up and/or frequency change
> >  * DMA for IO
> > 
> > Use case description.
> >  * Data transfer from MMC via VFS to USB.
> >  * DMA shuffles data from MMC and to USB.
> >  * The CPU wakes up every now and then to pass data in and out from VFS,
> >which cause the bursty VFS behaviour.
> > 
> > Test set up
> >  * Running dd on the host reading from the mass storage device
> >  * cmdline: dd if=/dev/sdb of=/dev/null bs=4k count=$((256*100))
> >  * Caches are dropped on the host and on the device before each run
> > 
> > Measurements on a Snowball board with ondemand_govenor active.
> > 
> > FSG_NUM_BUFFERS 2
> > 104857600 bytes (105 MB) copied, 5.62173 s, 18.7 MB/s
> > 104857600 bytes (105 MB) copied, 5.61811 s, 18.7 MB/s
> > 104857600 bytes (105 MB) copied, 5.57817 s, 18.8 MB/s
> > 
> > FSG_NUM_BUFFERS 4
> > 104857600 bytes (105 MB) copied, 5.26839 s, 19.9 MB/s
> > 104857600 bytes (105 MB) copied, 5.2691 s, 19.9 MB/s
> > 104857600 bytes (105 MB) copied, 5.2711 s, 19.9 MB/s
> > 
> > There may not be one optimal number for all boards. This is why
> > the number is added to Kconfig.
> > 
> > Signed-off-by: Per Forlin 
> > Acked-by: Michal Nazarewicz 
> 
> Acked-by: Alan Stern 

Thanks.

Hijacking this thread for a small note. I'll be back on applying patches
this friday. Until then I'll be focussed on some other issues which
we're tracking down.

Thanks for understanding ;-)

-- 
balbi


signature.asc
Description: Digital signature
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v3 01/11] MFD: DA9052 MFD core module

[Mark Brown]

On Tue, Aug 09, 2011 at 08:45:47AM +, Ashish Jangam wrote:

> > Could do with blank lines between blocks.  Though looking at the code
> > here I don't understand why these are compile options at all, or if they
> > need to be compile options for some reason why they're not independantly
> > selectable?

> DA9052 PMIC chip id may get OTP therefore chip id cannot be used as 
> a distinguishing factor. Hence these compile time options were introduced.
> DA9053 is a higher version of DA9052 therefore not independently selectable.
> This means that there can be either DA9052 or DA9053 on system. I need to 
> correct
> this Kconfig to take care of this. 

No, this is not acceptable in the kernel.  One kernel can support many
different boards so you need to be able to compile support for all chips
in simultaneously.  If you can't identify based on the hardware you need
to rely on the device being registered correctly by the user.

> > This should be runtime detected based on the device name, either from
> > the device registration or by reading back chip identification.

> As said above getting chip info will not work in DA9053/53 case. Also DA9052 
> code 
> works for DA9053 except for few minor changes in MFD and regulator module.
> In this case registering different device will also require a preprocessor 
> directive
> Or separate DA9053 file therefore this option was not opt. 

No, this is not acceptable.  One kernel build should be able to support
many different boards.  Like I said in my quote above you need to either
use the device registration or chip registers - if chip registers are
not suitable I guess that means you need to use the device registration.
There are a large number of examples of this in the kernel.

I know the Linaro guys have offered to help you out with this stuff, can
you please work with them?  You are obviously experiencing a lot of
difficulties with understanding the requirements and standards for
getting your code into the standard kernel, they really know what
they're doing.

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

Re: pm-qa integration in LAVA

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/02/2011 04:28 PM, Daniel Lezcano wrote:


HI Paul,

here is the new output:

cpufreq_01.0/cpu0 checking scaling_available_frequencies
exists...  PASS
cpufreq_01.1/cpu0 checking scaling_cur_freq
exists...   PASS
cpufreq_01.2/cpu0 checking scaling_setspeed
exists...   PASS
cpufreq_01.3/cpu1 checking scaling_available_frequencies
exists...  PASS
cpufreq_01.4/cpu1 checking scaling_cur_freq
exists...   PASS
cpufreq_01.5/cpu1 checking scaling_setspeed
exists...   PASS
cpufreq_02.0/cpu0 checking scaling_available_governors
exists...PASS
cpufreq_02.1/cpu0 checking scaling_governor
exists...   PASS
cpufreq_02.2/cpu1 checking scaling_available_governors
exists...PASS
cpufreq_02.3/cpu1 checking scaling_governor
exists...   PASS
cpufreq_03.0/cpu0 checking governor change to
'conservative'... PASS
cpufreq_03.1/cpu0 checking governor change to
'ondemand'... PASS
cpufreq_03.2/cpu0 checking governor change to
'userspace'...PASS
cpufreq_03.3/cpu0 checking governor change to
'powersave'...PASS
cpufreq_03.4/cpu0 checking governor change to
'performance'...  PASS
cpufreq_03.5/cpu1 checking governor change to
'conservative'... PASS
cpufreq_03.6/cpu1 checking governor change to
'ondemand'... PASS
cpufreq_03.7/cpu1 checking governor change to
'userspace'...PASS
cpufreq_03.8/cpu1 checking governor change to
'powersave'...PASS
cpufreq_03.9/cpu1 checking governor change to
'performance'...  PASS
cpufreq_04.0/cpu0 checking setting frequency '2.6
GHz'...   PASS
cpufreq_04.1/cpu0 checking setting frequency '2.6
GHz'...   PASS
cpufreq_04.2/cpu0 checking setting frequency '2.0
GHz'...   PASS
cpufreq_04.3/cpu0 checking setting frequency '1.6
GHz'...   PASS
cpufreq_04.4/cpu0 checking setting frequency '1.2
GHz'...   PASS
cpufreq_04.5/cpu0 checking setting frequency '800.0
MHz'... PASS
cpufreq_04.6/cpu1 checking setting frequency '2.6
GHz'...   PASS
cpufreq_04.7/cpu1 checking setting frequency '2.6
GHz'...   PASS
cpufreq_04.8/cpu1 checking setting frequency '2.0
GHz'...   PASS
cpufreq_04.9/cpu1 checking setting frequency '1.6
GHz'...   PASS
cpufreq_04.10/cpu1 checking setting frequency '1.2
GHz'...  PASS
cpufreq_04.11/cpu1 checking setting frequency '800.0
MHz'...PASS
cpufreq_05.0/cpu1 checking 'ondemand' directory
exists...   PASS
cpufreq_05.1/cpu1 checking 'conservative' directory
exists...   PASS
cpufreq_05.2/cpu1 checking 'ondemand' directory is not
there... PASS
cpufreq_05.3/cpu1 checking 'conservative' directory is not
there... PASS
cpufreq_05.4/cpu1 checking 'ondemand' directory
exists...   PASS
cpufreq_05.5/cpu1 checking 'conservative' directory
exists...   PASS
cpufreq_06.0/cpu0 checking deviation for frequency 2.6
GHz...   FAIL
cpufreq_06.1/cpu0 checking deviation for frequency 2.6
GHz...   PASS
cpufreq_06.2/cpu0 checking deviation for frequency 2.0
GHz...   PASS
cpufreq_06.3/cpu0 checking deviation for frequency 1.6
GHz...   PASS
cpufreq_06.4/cpu0 checking deviation for frequency 1.2
GHz...   PASS
cpufreq_06.5/cpu0 checking deviation for frequency 800.0
MHz... PASS
cpufreq_06.6/cpu1 checking deviation for frequency 2.6
GHz...   FAIL
cpufreq_06.7/cpu1 checking deviation for frequency 2.6
GHz...   PASS
cpufreq_06.1/cpu0 checking deviation for frequency 2.6
GHz...   PASS
cpufreq_06.2/cpu0 checking deviation for frequency 2.0
GHz...   PASS
cpufreq_06.3/cpu0 checking deviation for frequency 1.6
GHz...   PASS
cpufreq_06.4/cpu0 checking deviation for frequency 1.2
GHz...   PASS
cpufreq_06.5/cpu0 checking deviation for frequency 800.0
MHz... PASS
cpufreq_06.6/cpu1 checking deviation for frequency 2.6
GHz...   FAIL
cpufreq_06.7/cpu1 checking deviation for frequency 2.6
GHz...   PASS
cpufreq_06.8/cpu1 checking deviation for frequency 2.0
GHz...   PASS
cpufreq_06.9/cpu1 checking deviation for frequency 1.6
GHz...   PASS
cpufreq_06.10/cpu1 checking deviation for frequency 1.2
GHz...  PASS
cpufreq_06.11/cpu1 checking deviation for frequency 800.0
MHz...PASS
cpufreq_07.0/cpu0 checking 'ondemand' increase frequency on
load... PASS
cpufreq_07.1/cpu0 checking 'ondemand' decrease frequency on
idle... PASS
cpufreq_07.2/cpu1 checking 'ondemand' increase frequency on
load... PASS
cpufreq_

Re: Switching to Gerrit for Android code hosting - last stage

[Paul Sokolovsky]

On Tue, 9 Aug 2011 17:05:16 +0300
Paul Sokolovsky  wrote:

> > > I have followed (and updated) the instructions
> > > on https://wiki.linaro.org/Platform/Android/Gerrit .
> > > I can not log in with my launchpad account. I get the message "The
> > > requested URL /OpenID was not found on this server."
> > 
> > I can confirm this issue. Guess the gerrit config was not changed to
> > the new review.android.git.linaro.org url but still refers to the
> > old android.git.linaro.org host which has the git itself now.
> 
> Cannot fix this myself, submitted
> https://rt.linaro.org/Ticket/Display.html?id=56 . In the meantime,
> it's still possible to "login" with manual URL munging in case it's
> needed urgently.

Fixed now, so we don't have blockers for tomorrow's cutover.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Re: [PATCH v3] usb: gadget: storage_common: make FSG_NUM_BUFFERS variable size

[Alan Stern]

On Mon, 8 Aug 2011, Per Forlin wrote:

> FSG_NUM_BUFFERS is set to 2 as default.
> Usually 2 buffers are enough to establish a good buffering pipeline.
> The number may be increased in order to compensate a for bursty VFS
> behaviour.
> 
> Here follows a description of system that may require more than
> 2 buffers.
>  * CPU ondemand governor active
>  * latency cost for wake up and/or frequency change
>  * DMA for IO
> 
> Use case description.
>  * Data transfer from MMC via VFS to USB.
>  * DMA shuffles data from MMC and to USB.
>  * The CPU wakes up every now and then to pass data in and out from VFS,
>which cause the bursty VFS behaviour.
> 
> Test set up
>  * Running dd on the host reading from the mass storage device
>  * cmdline: dd if=/dev/sdb of=/dev/null bs=4k count=$((256*100))
>  * Caches are dropped on the host and on the device before each run
> 
> Measurements on a Snowball board with ondemand_govenor active.
> 
> FSG_NUM_BUFFERS 2
> 104857600 bytes (105 MB) copied, 5.62173 s, 18.7 MB/s
> 104857600 bytes (105 MB) copied, 5.61811 s, 18.7 MB/s
> 104857600 bytes (105 MB) copied, 5.57817 s, 18.8 MB/s
> 
> FSG_NUM_BUFFERS 4
> 104857600 bytes (105 MB) copied, 5.26839 s, 19.9 MB/s
> 104857600 bytes (105 MB) copied, 5.2691 s, 19.9 MB/s
> 104857600 bytes (105 MB) copied, 5.2711 s, 19.9 MB/s
> 
> There may not be one optimal number for all boards. This is why
> the number is added to Kconfig.
> 
> Signed-off-by: Per Forlin 
> Acked-by: Michal Nazarewicz 

Acked-by: Alan Stern 


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

u-boot: call usb_stop on pxe boot

[Badea Daniel]

Hi all, 


After reading rsalveti's blog post on net booting with TFTP and PXE on 
Pandaboard I decided to try it and boot my 2.6.35 kernel (locked to this 
version because of some vendor specific changes). Unfortunately, although 
u-boot was able to retrieve and start the kernel image it wouldn't detect the 
SMSC ethernet adapter. This happens because older kernel versions rely on 
u-boot to do some initialization of the USB subsystem.
First "fix" was to call usb_stop() from the pxe boot function just before 
booting. But usb_stop calls omap4_ehci_hcd_stop which disables some clocks and 
2.6.35 is still unable to detect the ethernet adapter.
So the second "fix" was to rewrite (to my best understanding - without going 
through the documentation) omap4_ehci_hcd_stop to reset some subsystems and 
leave the clocks running.

I attached the patch in case someone else needs to boot older kernels in this 
PXE + NFS rootfs configuration.

Problems with the patch are:
  - changes omap4_ehci_hcd_stop functionality
  - probably breaks other use cases
  - tested only in my particular configuration
Thanks,
Daniel

0001-PXE-boot-stop-USB-but-keep-clocks-running.patch
Description: Binary data
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: What are the chances of a phone based developer image

[Paul Sokolovsky]

Hello Taras,


We've recently had a Linaro Connect conference, and many developers
are still on the way from it, so more knowledgeable folks may add more
info later, and I'd like to highlight some points in the meantime.


On Thu, 04 Aug 2011 12:03:00 -0700
Taras Glek  wrote:

> Hi,
> Recently we have been looking at how to squeeze more performance out
> of our toolchain for building Firefox on Android. Mike Hommey
> integrated GCC 4.6 into the android NDK and has been testing
> performance (with mixed results
> http://gcc.gnu.org/ml/gcc/2011-08/msg00096.html). I like how Linaro
> is doing regular arm benchmarking, ie
> https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-07 
> .
> Would you be interested in adding a Firefox-based benchmark? As a
> large application it is a good testbed for LTO, FDO and other
> aggressive optimizations.

That sounds like a great idea. Our validation team currently exactly
compiles list of tests which are useful to run as our validation and
benchmarking effort. We're still bootstrapping our continuous
integration system and working on "low-hanging fruit" (simple tests),
but for sure looking forward to add more elaborated testsuites,
especially for Android (which doesn't have much of variety). So, please
consider us among your users.

> We are also looking at setting a developer-friendly android ROM with 
> oprofile, perf, systemtap, gdb, debug symbols, etc. It might even be 
> beneficial for us to use newer kernels as we exlore options like 
> kernel-assisted ld.so relocations, etc. That seems to similar to what 
> Linaro provides in the evaluation ROMS.

We recently added busybox to our builds, as the default Android
environment indeed pretty limited. And I agree that it would be nice to
have more tools available. However, our aim at Linaro is to stay
sufficiently close to the upstream, and neither we currently have
resources to maintain "normal" and "developer" images.

One solution I personally see for this is breaking away from the "ROM"
outlook, and taking Android more as a normal Linux distribution. So,
anyone interested could easily rebuild Android with more packages
installed, or even better, have native package manager to install more
binary packages (something like opkg). That's forward-looking thinking
though, we unlikely get to it soon, but would be interested to see if
wider Android community has interest in that and help if we can.

> Is there any chance of Linaro 
> providing developer-friendly "evaluation" ROMs for retail phones like 
> the Nexus S?

Did you consider using a development board for development and
testing? That for sure is more comfortable and affordable solution for
sustainable development than a specific retail product (1). We at
Linaro exactly work on making high-quality base software (including
Android) available on low-cost devel boards, so different parties can
develop ARM software more easily and with higher quality. That's also
consistent with Linaro's aim of promoting ARM SoCs, not specific
products. So, at this time we don't have plans to support retail
devices, though that might change in the future. 

That's also one area where community may kick in. On our side, we're
considering what support we can provide for such different efforts,
which may include providing code hosting, using our build system,
validation farm, etc.


(1) Though I for sure agree that it would be nice to have Linaro
supported and optimized build for some retail device. Except that I
happen not to have Nexus S, so would vote for supporting my tablet
instead ;-)


> Thanks,
> Taras

-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

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

Re: [pm-qa 1/5] fix error output to the log file

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/08/2011 10:29 PM, Amit Kucheria wrote:
> Daniel,
>
> This looks ok. Ack.

Applied.


- -- 
  Linaro.org ? Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOQancAAoJEAKBbMCpUGYAIj8H/RSSJ2gfpom1Nx4DZx16tBEL
WyzG8GX5+l4I4uFVZYmiaq3UJc5AJr7QgBNtCmjM8CGGnGFCLJ3tsviZW+8C7o7F
PnKDm93ja9G6mkT7POHdTWkPMccQh6Uk8lghlDbyFK1V8eBSqfdIk+4g+B68yItj
wCxKzROJpE8JBQ9vqtySHSwE5jscx4yRN4aepeRWn79UJjhiJWL+eTKUzntta1Vn
mm+DcBtJsr9jJ8qWkkDpCzCn77touprbzxolusi7elZX2hop9JbUTT/ZNaJUzlIs
wbJ82ecMHnC8olBcc65Oo1iUdhoe9sNrJjIIBHsGhtD+MONWkDn8zHLAJzxNLAw=
=Ln2j
-END PGP SIGNATURE-


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

[PATCH 1/2] number the test with an id

[Daniel Lezcano]

Automatically increment the test id making possible to identify
the test clearly.

The result will under the form:

...
cpufreq_03.0/cpu0 checking governor change to 'conservative'... PASS
cpufreq_03.1/cpu0 checking governor change to 'ondemand'... PASS
cpufreq_03.2/cpu0 checking governor change to 'userspace'...PASS
cpufreq_03.3/cpu0 checking governor change to 'powersave'...PASS
cpufreq_03.4/cpu0 checking governor change to 'performance'...  PASS
cpufreq_03.0/cpu1 checking governor change to 'conservative'... PASS
cpufreq_03.1/cpu1 checking governor change to 'ondemand'... PASS
cpufreq_03.2/cpu1 checking governor change to 'userspace'...PASS
cpufreq_03.3/cpu1 checking governor change to 'powersave'...PASS
cpufreq_03.4/cpu1 checking governor change to 'performance'...  PASS
cpufreq_04.0/cpu0 checking setting frequency '2.6 GHz'...   PASS
cpufreq_04.1/cpu0 checking setting frequency '2.6 GHz'...   PASS
cpufreq_04.2/cpu0 checking setting frequency '2.0 GHz'...   PASS
cpufreq_04.3/cpu0 checking setting frequency '1.6 GHz'...   PASS
cpufreq_04.4/cpu0 checking setting frequency '1.2 GHz'...   PASS
cpufreq_04.5/cpu0 checking setting frequency '800.0 MHz'... PASS
cpufreq_04.0/cpu1 checking setting frequency '2.6 GHz'...   PASS
cpufreq_04.1/cpu1 checking setting frequency '2.6 GHz'...   PASS
cpufreq_04.2/cpu1 checking setting frequency '2.0 GHz'...   PASS
cpufreq_04.3/cpu1 checking setting frequency '1.6 GHz'...   PASS
cpufreq_04.4/cpu1 checking setting frequency '1.2 GHz'...   PASS
cpufreq_04.5/cpu1 checking setting frequency '800.0 MHz'... PASS
cpufreq_05.0/cpu1 checking 'ondemand' directory exists...   PASS
...

Signed-off-by: Daniel Lezcano 
Cc: Paul Larson 
---
 include/functions.sh |   15 +++
 1 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/include/functions.sh b/include/functions.sh
index 3d45517..1eefa32 100644
--- a/include/functions.sh
+++ b/include/functions.sh
@@ -25,15 +25,13 @@
 
 CPU_PATH="/sys/devices/system/cpu"
 TEST_NAME=$(basename ${0%.sh})
-BLOCK=$(basename $(pwd))
-PREFIX=$BLOCK:$TEST_NAME
-
-setprefix_cpu() {
-PREFIX=$BLOCK:$TEST_NAME/$1
-}
+PREFIX=$TEST_NAME
+INC=0
+CPU=
 
 log_begin() {
-printf "%-75s" "$PREFIX $@ ... "
+printf "%-76s" "$TEST_NAME.$INC$CPU $@... "
+INC=$(($INC+1))
 }
 
 log_end() {
@@ -53,7 +51,8 @@ for_each_cpu() {
 cpus=$(ls $CPU_PATH | grep "cpu[0-9].*")
 
 for cpu in $cpus; do
-   setprefix_cpu $cpu
+   INC=0
+   CPU=/$cpu
$func $cpu $@
 done
 
-- 
1.7.4.1


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

[PATCH 2/2] change the script name with the block name they refer to

[Daniel Lezcano]

Signed-off-by: Daniel Lezcano 
---
 cpufreq/cpufreq_01.sh |   32 +
 cpufreq/cpufreq_02.sh |   32 +
 cpufreq/cpufreq_03.sh |   51 +
 cpufreq/cpufreq_04.sh |   54 ++
 cpufreq/cpufreq_05.sh |   73 ++
 cpufreq/cpufreq_06.sh |  117 +
 cpufreq/cpufreq_07.sh |   91 ++
 cpufreq/cpufreq_08.sh |   78 
 cpufreq/cpufreq_09.sh |   74 +++
 cpufreq/test_01.sh|   32 -
 cpufreq/test_02.sh|   32 -
 cpufreq/test_03.sh|   51 -
 cpufreq/test_04.sh|   54 --
 cpufreq/test_05.sh|   73 --
 cpufreq/test_06.sh|  117 -
 cpufreq/test_07.sh|   91 --
 cpufreq/test_08.sh|   78 
 cpufreq/test_09.sh|   74 ---
 sched_mc/sched_01.sh  |   32 +
 sched_mc/sched_02.sh  |   38 
 sched_mc/sched_03.sh  |   33 ++
 sched_mc/sched_04.sh  |   70 +
 sched_mc/test_01.sh   |   32 -
 sched_mc/test_02.sh   |   38 
 sched_mc/test_03.sh   |   33 --
 sched_mc/test_04.sh   |   70 -
 26 files changed, 775 insertions(+), 775 deletions(-)
 create mode 100644 cpufreq/cpufreq_01.sh
 create mode 100644 cpufreq/cpufreq_02.sh
 create mode 100644 cpufreq/cpufreq_03.sh
 create mode 100644 cpufreq/cpufreq_04.sh
 create mode 100644 cpufreq/cpufreq_05.sh
 create mode 100644 cpufreq/cpufreq_06.sh
 create mode 100644 cpufreq/cpufreq_07.sh
 create mode 100644 cpufreq/cpufreq_08.sh
 create mode 100644 cpufreq/cpufreq_09.sh
 delete mode 100755 cpufreq/test_01.sh
 delete mode 100755 cpufreq/test_02.sh
 delete mode 100755 cpufreq/test_03.sh
 delete mode 100755 cpufreq/test_04.sh
 delete mode 100755 cpufreq/test_05.sh
 delete mode 100755 cpufreq/test_06.sh
 delete mode 100755 cpufreq/test_07.sh
 delete mode 100755 cpufreq/test_08.sh
 delete mode 100755 cpufreq/test_09.sh
 create mode 100644 sched_mc/sched_01.sh
 create mode 100644 sched_mc/sched_02.sh
 create mode 100644 sched_mc/sched_03.sh
 create mode 100644 sched_mc/sched_04.sh
 delete mode 100755 sched_mc/test_01.sh
 delete mode 100755 sched_mc/test_02.sh
 delete mode 100755 sched_mc/test_03.sh
 delete mode 100755 sched_mc/test_04.sh

diff --git a/cpufreq/cpufreq_01.sh b/cpufreq/cpufreq_01.sh
new file mode 100644
index 000..8cfbce9
--- /dev/null
+++ b/cpufreq/cpufreq_01.sh
@@ -0,0 +1,32 @@
+#!/bin/bash
+#
+# PM-QA validation test suite for the power management on ARM
+#
+# Copyright (C) 2011, Linaro Limited.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.
+#
+# Contributors:
+# Daniel Lezcano  (IBM Corporation)
+#   - initial API and implementation
+#
+
+# URL : 
https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts#cpufreq_01
+
+source ../include/functions.sh
+
+FILES="scaling_available_frequencies scaling_cur_freq scaling_setspeed"
+
+for_each_cpu check_cpufreq_files $FILES
diff --git a/cpufreq/cpufreq_02.sh b/cpufreq/cpufreq_02.sh
new file mode 100644
index 000..212b2eb
--- /dev/null
+++ b/cpufreq/cpufreq_02.sh
@@ -0,0 +1,32 @@
+#!/bin/bash
+#
+# PM-QA validation test suite for the power management on ARM
+#
+# Copyright (C) 2011, Linaro Limited.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.
+#
+# Contributors:
+# Daniel Lezcano  (I

Re: What are the chances of a phone based developer image

[Christian Robottom Reis]

On Thu, Aug 04, 2011 at 12:03:00PM -0700, Taras Glek wrote:
> Recently we have been looking at how to squeeze more performance out
> of our toolchain for building Firefox on Android. Mike Hommey
> integrated GCC 4.6 into the android NDK and has been testing
> performance (with mixed results
> http://gcc.gnu.org/ml/gcc/2011-08/msg00096.html).

You should definitely be trying to build using the Linaro 4.5 and 4.6
compiler branches; they are pretty much guaranteed to give you better
performance, and if they don't, we're on the hook to fix it quickly! All
the patches go upstream, so there is no risk of you being stuck on a
fork -- it just makes everything you need available right now.

I'm copying the linaro-toolchain list to make sure that you get the
right people's attention (though if they weren't all coming back from
Connect in Cambridge this week they would have picked the email up
already).

> I like how Linaro is doing regular arm benchmarking, ie
> https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-07

We do much more than that, but it's not as easy to find right now; for
instance http://ex.seabright.co.nz/helpers/benchcompare is Michael's
regular release benchmark.

> . Would you be interested in adding a Firefox-based benchmark? As a
> large application it is a good testbed for LTO, FDO and other
> aggressive optimizations.

Totally. Let's do it. Can you give me an idea of what boards you are
testing the build on today? Do you have a test suite that we could run
in a reasonable timeframe (hours, not days)?

> We are also looking at setting a developer-friendly android ROM with
> oprofile, perf, systemtap, gdb, debug symbols, etc. It might even be
> beneficial for us to use newer kernels as we exlore options like
> kernel-assisted ld.so relocations, etc. That seems to similar to
> what Linaro provides in the evaluation ROMS. Is there any chance of
> Linaro providing developer-friendly "evaluation" ROMs for retail
> phones like the Nexus S?

It's indeed pretty similar (we just call them LEBs), and Zach will be
really interested in working with you on this.

As for supporting actual released phones, it lies somewhat outside of
our optimal operating model, and we don't have any hardware available. I
guess we could do a spin for a specific model if we had enough of them
to use by a set of engineers in the different teams. They are so
expensive, though. Do you guys have lots of them?
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

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

Re: What are the chances of a phone based developer image

[Taras Glek]

On 08/09/2011 02:47 PM, Christian Robottom Reis wrote:

On Thu, Aug 04, 2011 at 12:03:00PM -0700, Taras Glek wrote:

Recently we have been looking at how to squeeze more performance out
of our toolchain for building Firefox on Android. Mike Hommey
integrated GCC 4.6 into the android NDK and has been testing
performance (with mixed results
http://gcc.gnu.org/ml/gcc/2011-08/msg00096.html).

You should definitely be trying to build using the Linaro 4.5 and 4.6
compiler branches; they are pretty much guaranteed to give you better
performance, and if they don't, we're on the hook to fix it quickly! All
the patches go upstream, so there is no risk of you being stuck on a
fork -- it just makes everything you need available right now.

Mike, can you give these a try?


I'm copying the linaro-toolchain list to make sure that you get the
right people's attention (though if they weren't all coming back from
Connect in Cambridge this week they would have picked the email up
already).


I like how Linaro is doing regular arm benchmarking, ie
https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-07

We do much more than that, but it's not as easy to find right now; for
instance http://ex.seabright.co.nz/helpers/benchcompare is Michael's
regular release benchmark.

Link gives me an error page



. Would you be interested in adding a Firefox-based benchmark? As a
large application it is a good testbed for LTO, FDO and other
aggressive optimizations.

Totally. Let's do it. Can you give me an idea of what boards you are
testing the build on today? Do you have a test suite that we could run
in a reasonable timeframe (hours, not days)?

We have various benchmarks, all of which run within 30-60min.

We are also looking at setting a developer-friendly android ROM with
oprofile, perf, systemtap, gdb, debug symbols, etc. It might even be
beneficial for us to use newer kernels as we exlore options like
kernel-assisted ld.so relocations, etc. That seems to similar to
what Linaro provides in the evaluation ROMS. Is there any chance of
Linaro providing developer-friendly "evaluation" ROMs for retail
phones like the Nexus S?

It's indeed pretty similar (we just call them LEBs), and Zach will be
really interested in working with you on this.

As for supporting actual released phones, it lies somewhat outside of
our optimal operating model, and we don't have any hardware available. I
guess we could do a spin for a specific model if we had enough of them
to use by a set of engineers in the different teams. They are so
expensive, though. Do you guys have lots of them?

How many devices would you need?

We actually have two separate needs. We use developer boards for 
continuous integration and phones for development. We need a good 
quality rom for both. Perhaps we can switch our boards over to pandaboards.


Is there someone I can call(and what time) to discuss this further?

Taras


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

Re: What are the chances of a phone based developer image

[Christian Robottom Reis]

On Tue, Aug 09, 2011 at 03:08:53PM -0700, Taras Glek wrote:
> >You should definitely be trying to build using the Linaro 4.5 and 4.6
> >compiler branches; they are pretty much guaranteed to give you better
> >performance, and if they don't, we're on the hook to fix it quickly! All
> >the patches go upstream, so there is no risk of you being stuck on a
> >fork -- it just makes everything you need available right now.
> Mike, can you give these a try?

Also, the 4.5 branch is likely to perform better for a while; once 4.6 
has caught up 4.5 goes into stable mode.

If you are on a platform with NEON (i.e. not a Tegra2) experimenting
with on -O3 and -mfpu=neon might get some interesting results as that
enables the NEON auto-vectorizing Ira has been working on; given it's
Mozilla, you might also get an ICE though ;-) Tell us how it goes.

> >I'm copying the linaro-toolchain list to make sure that you get the
> >right people's attention (though if they weren't all coming back from
> >Connect in Cambridge this week they would have picked the email up
> >already).
> >
> >>I like how Linaro is doing regular arm benchmarking, ie
> >>https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-07
> >We do much more than that, but it's not as easy to find right now; for
> >instance http://ex.seabright.co.nz/helpers/benchcompare is Michael's
> >regular release benchmark.
> Link gives me an error page

It so happens the owner of the page is on vacation this week. I'll make
sure he fixes it and points you to a running URL when it's done.

> >Totally. Let's do it. Can you give me an idea of what boards you are
> >testing the build on today? Do you have a test suite that we could run
> >in a reasonable timeframe (hours, not days)?
>
> We have various benchmarks, all of which run within 30-60min.

Cool. Can you share a subset you'd like to see run as a starting point?

> >As for supporting actual released phones, it lies somewhat outside of
> >our optimal operating model, and we don't have any hardware available. I
> >guess we could do a spin for a specific model if we had enough of them
> >to use by a set of engineers in the different teams. They are so
> >expensive, though. Do you guys have lots of them?
> How many devices would you need?

5 phones would give me confidence that we're not going to be stuck
throughout the process of getting a build going. So that's the general
order of magnitude.

> We actually have two separate needs. We use developer boards for
> continuous integration and phones for development. We need a good
> quality rom for both. Perhaps we can switch our boards over to
> pandaboards.
> 
> Is there someone I can call(and what time) to discuss this further?

You can call me at +44 7595 200905 any time this week; now isn't a bad
time, but if I do miss your call I'll be sure to ring you back. You can
also call Zach on Thursday or Friday; I'll send his number separately.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

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

[PATCH 2/2] cpu: update cpu_hotpluggable_mask in register_cpu

[Mike Turquette]

Update the cpu_hotpluggable_mask for each registered CPU which supports
hotplug.  This makes it trivial for kernel code to know which CPUs
support hotplug operations.

Signed-off-by: Mike Turquette 
---
 drivers/base/cpu.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 251acea..91ddcf8 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -224,8 +224,10 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
 
error = sysdev_register(&cpu->sysdev);
 
-   if (!error && cpu->hotpluggable)
+   if (!error && cpu->hotpluggable) {
register_cpu_control(cpu);
+   set_cpu_hotpluggable(num, true);
+   }
if (!error)
per_cpu(cpu_sys_devices, num) = &cpu->sysdev;
if (!error)
-- 
1.7.4.1


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

[PATCH 1/2] cpumask: introduce cpumask for hotpluggable CPUs

[Mike Turquette]

On some platforms it is possible to have some CPUs which support CPU
hotplug and some which do not.  Currently the prescence of an 'online'
sysfs entry in userspace is adequate for applications to know that a CPU
supports hotplug, but there is no convenient way to make the same
determination in the kernel.

To better model this relationship this patch introduces a new cpumask to
track CPUs that support CPU hotplug operations.

This new cpumask is populated at boot-time and remains static for the
life of the machine.  Bits set in the mask indicate a CPU which supports
hotplug, but make no guarantees about whether that CPU is currently
online or not.  Likewise a cleared bit in the mask indicates either a
CPU which cannot hotplug or a lack of a populated CPU.

The purpose of this new cpumask is to aid kernel code which uses CPU to
take CPUs online and offline.  Possible uses are as a thermal event
mitigation technique or as a power capping mechanism.

Signed-off-by: Mike Turquette 
---
 include/linux/cpumask.h |   27 ++-
 kernel/cpu.c|   18 ++
 2 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index b24ac56..9eed444 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -39,10 +39,11 @@ extern int nr_cpu_ids;
  * The following particular system cpumasks and operations manage
  * possible, present, active and online cpus.
  *
- * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
- * cpu_present_mask - has bit 'cpu' set iff cpu is populated
- * cpu_online_mask  - has bit 'cpu' set iff cpu available to scheduler
- * cpu_active_mask  - has bit 'cpu' set iff cpu available to migration
+ * cpu_possible_mask - has bit 'cpu' set iff cpu is populatable
+ * cpu_hotpluggable_mask - has bit 'cpu' set iff cpu is hotpluggable
+ * cpu_present_mask  - has bit 'cpu' set iff cpu is populated
+ * cpu_online_mask   - has bit 'cpu' set iff cpu available to scheduler
+ * cpu_active_mask   - has bit 'cpu' set iff cpu available to migration
  *
  *  If !CONFIG_HOTPLUG_CPU, present == possible, and active == online.
  *
@@ -51,7 +52,11 @@ extern int nr_cpu_ids;
  *  life of that system boot.  The cpu_present_mask is dynamic(*),
  *  representing which CPUs are currently plugged in.  And
  *  cpu_online_mask is the dynamic subset of cpu_present_mask,
- *  indicating those CPUs available for scheduling.
+ *  indicating those CPUs available for scheduling.  The
+ *  cpu_hotpluggable_mask is also fixed at boot time, as the set of CPU
+ *  id's which are possible AND can hotplug.  Cleared bits in this mask
+ *  mean that either the CPU is not possible, or it is possible but does
+ *  not support CPU hotplug operations.
  *
  *  If HOTPLUG is enabled, then cpu_possible_mask is forced to have
  *  all NR_CPUS bits set, otherwise it is just the set of CPUs that
@@ -61,6 +66,9 @@ extern int nr_cpu_ids;
  *  depending on what ACPI reports as currently plugged in, otherwise
  *  cpu_present_mask is just a copy of cpu_possible_mask.
  *
+ *  If CONFIG_HOTPLUG_CPU is enabled, then cpu_hotpluggable_mask matches
+ *  the description above, otherwise it is the empty set.
+ *
  *  (*) Well, cpu_present_mask is dynamic in the hotplug case.  If not
  *  hotplug, it's a copy of cpu_possible_mask, hence fixed at boot.
  *
@@ -76,6 +84,7 @@ extern int nr_cpu_ids;
  */
 
 extern const struct cpumask *const cpu_possible_mask;
+extern const struct cpumask *const cpu_hotpluggable_mask;
 extern const struct cpumask *const cpu_online_mask;
 extern const struct cpumask *const cpu_present_mask;
 extern const struct cpumask *const cpu_active_mask;
@@ -85,19 +94,23 @@ extern const struct cpumask *const cpu_active_mask;
 #define num_possible_cpus()cpumask_weight(cpu_possible_mask)
 #define num_present_cpus() cpumask_weight(cpu_present_mask)
 #define num_active_cpus()  cpumask_weight(cpu_active_mask)
+#define num_hotpluggable_cpus()cpumask_weight(cpu_hotpluggable_mask)
 #define cpu_online(cpu)cpumask_test_cpu((cpu), cpu_online_mask)
 #define cpu_possible(cpu)  cpumask_test_cpu((cpu), cpu_possible_mask)
 #define cpu_present(cpu)   cpumask_test_cpu((cpu), cpu_present_mask)
 #define cpu_active(cpu)cpumask_test_cpu((cpu), cpu_active_mask)
+#define cpu_hotpluggable(cpu)  cpumask_test_cpu((cpu, cpu_hotpluggable_mask)
 #else
 #define num_online_cpus()  1U
 #define num_possible_cpus()1U
 #define num_present_cpus() 1U
 #define num_active_cpus()  1U
+#define num_hotpluggable_cpus()0
 #define cpu_online(cpu)((cpu) == 0)
 #define cpu_possible(cpu)  ((cpu) == 0)
 #define cpu_present(cpu)   ((cpu) == 0)
 #define cpu_active(cpu)((cpu) == 0)
+#define cpu_hotpluggable(cpu)  0
 #endif
 
 /* verify cpu argument to cpumask_* operators */
@@ -678,16 +691,20 @@ extern const

[PATCH 0/2] new cpumask for hotpluggable CPUs

[Mike Turquette]

This patch series introduces a new cpumask which tracks CPUs that
support hotplugging.  The purpose of this patch series is to provide a
simple method for kernel code to know which CPUs can be hotplugged and
which ones cannot.  Potential users of this code might be a thermal
mitigation technique which uses hotplug to lower temperature, or a power
capping mechanism which uses hotplug to lower power consumption.

All the of usual cpumask helper functions are created for this new mask.
The second patch in this series simply sets the bit for elligible CPUs
while they are being registered.  The cpumask itself is static after
boot and should not change (like the possbile mask).

Mike Turquette (2):
  cpumask: introduce cpumask for hotpluggable CPUs
  cpu: update cpu_hotpluggable_mask in register_cpu

 drivers/base/cpu.c  |4 +++-
 include/linux/cpumask.h |   27 ++-
 kernel/cpu.c|   18 ++
 3 files changed, 43 insertions(+), 6 deletions(-)

-- 
1.7.4.1


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

Re: [PATCH 1/2] cpumask: introduce cpumask for hotpluggable CPUs

[Christian Robottom Reis]

On Tue, Aug 09, 2011 at 06:33:26PM -0700, Mike Turquette wrote:
> - * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
> - * cpu_present_mask - has bit 'cpu' set iff cpu is populated
> - * cpu_online_mask  - has bit 'cpu' set iff cpu available to scheduler
> - * cpu_active_mask  - has bit 'cpu' set iff cpu available to migration
> + * cpu_possible_mask - has bit 'cpu' set iff cpu is populatable
> + * cpu_hotpluggable_mask - has bit 'cpu' set iff cpu is hotpluggable
> + * cpu_present_mask  - has bit 'cpu' set iff cpu is populated
> + * cpu_online_mask   - has bit 'cpu' set iff cpu available to 
> scheduler
> + * cpu_active_mask   - has bit 'cpu' set iff cpu available to 
> migration

Why not fix the 'iff' typo while you're here?
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

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

Re: [PATCH 1/2] cpumask: introduce cpumask for hotpluggable CPUs

[Turquette, Mike]

On Tue, Aug 9, 2011 at 7:01 PM, Christian Robottom Reis  wrote:
> On Tue, Aug 09, 2011 at 06:33:26PM -0700, Mike Turquette wrote:
>> - *     cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
>> - *     cpu_present_mask - has bit 'cpu' set iff cpu is populated
>> - *     cpu_online_mask  - has bit 'cpu' set iff cpu available to scheduler
>> - *     cpu_active_mask  - has bit 'cpu' set iff cpu available to migration
>> + *     cpu_possible_mask     - has bit 'cpu' set iff cpu is populatable
>> + *     cpu_hotpluggable_mask - has bit 'cpu' set iff cpu is hotpluggable
>> + *     cpu_present_mask      - has bit 'cpu' set iff cpu is populated
>> + *     cpu_online_mask       - has bit 'cpu' set iff cpu available to 
>> scheduler
>> + *     cpu_active_mask       - has bit 'cpu' set iff cpu available to 
>> migration
>
> Why not fix the 'iff' typo while you're here?

iff = if and only if

http://en.wikipedia.org/wiki/If_and_only_if

Thanks!
Mike

> Christian Robottom Reis, Engineering VP
> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
> Linaro.org: Open Source Software for ARM SoCs
>

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