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

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

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

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

RE: DA9053 LKML work

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

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

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

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

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.

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

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

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

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

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

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

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

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 -

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

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

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

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

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

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

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

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 S5PV3

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

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 repos

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

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

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

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

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

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

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

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 -

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

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 -

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

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

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

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

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

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

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

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

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

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 und

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

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 C

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

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

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

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

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

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 >

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

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

Re: pm-qa integration in LAVA

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

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

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 serve

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

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

u-boot: call usb_stop on pxe boot

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

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

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 h

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

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

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

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

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

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

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

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:

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

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 be

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

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

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

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/

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

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

[PATCH 0/2] new cpumask for hotpluggable CPUs

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 wh

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

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_activ

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

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  -