Hi
On 28 February 2012 07:33, Sudhangathan B S wrote:
> Hello Booher,
>
> I was previously using Angstrom Gnome OS given for Gumstix by Sakoman, this
> turned upto be a nightmare, just as you have told, with adhoc WiFi. I gave
> up.. I started with Linaro (Ubuntu for embedded systems by Canonical
Generalize CONFIG_IRQ_TIME_ACCOUNTING between X86 and
ARM, move "noirqtime=" option to common debugging code.
For a bit of backward compatibility, X86-specific option
"tsc=noirqtime" is preserved, but issues a warning.
Suggested-by: Yong Zhang
Suggested-by: Russell King
Suggested-by: Ingo Molna
On 02/27/2012 02:12 PM, Peter Zijlstra wrote:
-extern void enable_sched_clock_irqtime(void);
-extern void disable_sched_clock_irqtime(void);
+extern int sched_clock_irqtime;
+static inline void enable_sched_clock_irqtime(void)
+{
+ if (sched_clock_irqtime == -1)
+ sched_clock
On Monday 27 February 2012 08:23 PM, Mark Brown wrote:
If adding device tree support breaks existing platforms something is
going wrong, while you're pulling things together device tree might not
work until all the support makes it in but the old non-DT code should
continue to function.
Adding
Hello Booher,
I was previously using Angstrom Gnome OS given for Gumstix by Sakoman, this
turned upto be a nightmare, just as you have told, with adhoc WiFi. I gave
up.. I started with Linaro (Ubuntu for embedded systems by Canonical). In
Linaro WiFi and bluetooth both work very well including the
All,
I recently reorganized my series and milestones to reflect quarters:
https://launchpad.net/linaro-android
I also filed milestones for the connects so that I can easily find the
sessions I had.
Thought others may find this useful.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platfor
On Sun, Feb 26, 2012 at 8:47 PM, Robert Lee wrote:
> +/**
> + * cpuidle_enter_wrap - performing timekeeping and irq around enter function
> + * @dev: pointer to a valid cpuidle_device object
> + * @drv: pointer to a valid cpuidle_driver object
> + * @index: index of the target cpuidle state.
> + *
On Mon, Feb 27, 2012 at 10:55 PM, Dmitry Antipov
wrote:
> On 02/27/2012 06:27 PM, Ming Lei wrote:
>
>> After some check, I just found there is another patch you missed.
>> Please try the attachment patch from Shilimkar, Santosh.
>>
>> If it doesn't work, I can send my uImage for your test.
>
>
> N
On Sun, Feb 26, 2012 at 8:47 PM, Robert Lee wrote:
> +/**
> + * cpuidle_enter_wrap - performing timekeeping and irq around enter function
> + * @dev: pointer to a valid cpuidle_device object
> + * @drv: pointer to a valid cpuidle_driver object
> + * @index: index of the target cpuidle state.
> + *
Hi there,
It turns out that a fence object will be one of the next things added
to the dma-buf framework. You can check here for an in-progress
status page:
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/UMM/Status
And, the best thing for you to do is join the linaro-mm-sig list for
Hi, guys:
As I know linaro is working on a unified memory manager for soc world like
a similar one already exists in PC world (gem/ttm).
But I'm curious about how this manager handle the different sync notify
between various different IP vendor?
As we know, on PC the vsp+capture+graphic+display al
On 2/27/2012 11:17 PM, Grant Likely wrote:
On Mon, Feb 27, 2012 at 6:52 AM, Cousson, Benoit wrote:
Hi Mark,
On 2/27/2012 2:41 PM, Mark Brown wrote:
On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
Depending on what order Mark happens to pull them in, I am fine
re-sending ad
On Mon, Feb 27, 2012 at 6:52 AM, Cousson, Benoit wrote:
> Hi Mark,
>
>
> On 2/27/2012 2:41 PM, Mark Brown wrote:
>>
>> On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
>>
>>> Depending on what order Mark happens to pull them in, I am fine
>>> re-sending adding support for the 2 twl6
On 27 February 2012 16:27, Ian Campbell wrote:
> R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
> immediate (which can only target r0..r7).
>
> Since we support only ARMv7+ there are "T2" and "T3" encodings available
> which do allow direct mov of an immediate into R12, but are 3
On Mon, 2012-02-27 at 18:03 +, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 04:27:23PM +, Ian Campbell wrote:
> > On Thu, 2012-02-23 at 17:48 +, Stefano Stabellini wrote:
> > > We need a register to pass the hypercall number because we might not
> > > know it at compile time and HVC onl
On Mon, 2012-02-27 at 17:53 +, Dave Martin wrote:
> On Thu, Feb 23, 2012 at 05:48:22PM +, Stefano Stabellini wrote:
> > We need a register to pass the hypercall number because we might not
> > know it at compile time and HVC only takes an immediate argument.
> >
> > Among the available reg
Hi Peter,
On Mon, Feb 27, 2012 at 9:35 PM, Peter Maydell wrote:
> Hi; I'm hoping somebody will be willing to run a test kernel
> for me on some omap boards and send me the dmesg output.
> (I'm trying to sort out QEMU's modelling of the OMAP ID
> registers and the TRMs are rather unhelpful; in par
Hi; I'm hoping somebody will be willing to run a test kernel
for me on some omap boards and send me the dmesg output.
(I'm trying to sort out QEMU's modelling of the OMAP ID
registers and the TRMs are rather unhelpful; in particular
the OMAP35x TRM claims that there are two overlapping registers
at
On Mon, Feb 27, 2012 at 10:26 AM, Jean Pihet wrote:
> On Mon, Feb 27, 2012 at 5:47 AM, Robert Lee wrote:
>> Use core cpuidle timekeeping and irqen wrapper and remove that
>> handling from this code.
>>
>> Signed-off-by: Robert Lee
>> ---
>> arch/arm/mach-omap2/cpuidle34xx.c | 43
>> +
On Mon, Feb 27, 2012 at 10:19 AM, Jean Pihet wrote:
> Robert,
>
> On Mon, Feb 27, 2012 at 5:47 AM, Robert Lee wrote:
>> Add functionality that is commonly duplicated by various platforms.
>>
>> Signed-off-by: Robert Lee
>> ---
>> drivers/cpuidle/cpuidle.c | 37 ++
>
On Mon, Feb 27, 2012 at 04:27:23PM +, Ian Campbell wrote:
> On Thu, 2012-02-23 at 17:48 +, Stefano Stabellini wrote:
> > We need a register to pass the hypercall number because we might not
> > know it at compile time and HVC only takes an immediate argument.
> >
> > Among the available re
On Thu, Feb 23, 2012 at 05:48:22PM +, Stefano Stabellini wrote:
> We need a register to pass the hypercall number because we might not
> know it at compile time and HVC only takes an immediate argument.
>
> Among the available registers r12 seems to be the best choice because it
> is defined a
On Thu, 2012-02-23 at 17:48 +, Stefano Stabellini wrote:
> We need a register to pass the hypercall number because we might not
> know it at compile time and HVC only takes an immediate argument.
>
> Among the available registers r12 seems to be the best choice because it
> is defined as "intr
CC'ing Venki on this too.
The entire thread can be found at:
http://www.spinics.net/lists/arm-kernel/msg161596.html
On Mon, Feb 27, 2012 at 6:47 AM, Robert Lee wrote:
> This patch series moves vaious functionality duplicated in platform
> cpuidle drivers to the core cpuidle driver. Also, the pla
On Mon, Feb 27, 2012 at 5:47 AM, Robert Lee wrote:
> Use core cpuidle timekeeping and irqen wrapper and remove that
> handling from this code.
>
> Signed-off-by: Robert Lee
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 43 +++-
> 1 files changed, 18 insertions(+),
Robert,
On Mon, Feb 27, 2012 at 5:47 AM, Robert Lee wrote:
> Add functionality that is commonly duplicated by various platforms.
>
> Signed-off-by: Robert Lee
> ---
> drivers/cpuidle/cpuidle.c | 37 ++
> include/linux/cpuidle.h | 55
> +
Hello,
One of the issues with https://android-build.linaro.org/ is that, if
build fails, it's not easy to tell if it happened because of
compilation error ("real" failure) or due to non-deterministic error
with setting up infrastructure for build (e.g. during source checkout).
The latter not so un
Adding sh mailing list and sh contributors I missed on the original
submission. SH folks, full patchset submission can be found here:
http://www.spinics.net/lists/arm-kernel/msg161596.html
Best Regards,
Rob
On Sun, Feb 26, 2012 at 10:47 PM, Robert Lee wrote:
> Enable core cpuidle timekeeping an
On 02/27/2012 06:27 PM, Ming Lei wrote:
After some check, I just found there is another patch you missed.
Please try the attachment patch from Shilimkar, Santosh.
If it doesn't work, I can send my uImage for your test.
No effect, so please send an uImage if possible.
I'm re-sending cumulativ
On Mon, Feb 27, 2012 at 03:21:26PM +0100, Cousson, Benoit wrote:
> Mmm, it is written in Rajendra's changelog:
> "-2- All common regulator nodes for twl4030 and twl6030 are
> now defined in the twl4030.dtsi and twl6030.dtsi instead of
Oh, it's buried at the end of a rather verbose inter-patch ch
On 02/24/2012 05:49 PM, Rob Herring wrote:
On 02/24/2012 07:45 AM, Daniel Lezcano wrote:
The following patch checks if there are pending interrupts on the gic.
This function is needed for example for the ux500 cpuidle driver.
When the A9 cores and the gic are decoupled from the PRCMU, the idle
On Mon, Feb 27, 2012 at 9:12 PM, Dmitry Antipov
wrote:
> On 02/25/2012 07:24 AM, Ming Lei wrote:
>
>> BTW: suggest you to apply the recent arm pmu irq fix patches[1] to
>> test 'oprofile'.
>>
>> [1], http://marc.info/?t=13300128495&r=1&w=2
>
>
> I tried, and with the same results - "nobody car
On 2/27/2012 3:03 PM, Mark Brown wrote:
On Mon, Feb 27, 2012 at 02:52:05PM +0100, Cousson, Benoit wrote:
On 2/27/2012 2:41 PM, Mark Brown wrote:
On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
Please can you guys come up with a single unified series for this stuff
- I'll hold
On Mon, Feb 27, 2012 at 02:52:05PM +0100, Cousson, Benoit wrote:
> On 2/27/2012 2:41 PM, Mark Brown wrote:
> >On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
> >Please can you guys come up with a single unified series for this stuff
> >- I'll hold off on applying anything to allow
Hi Mark,
On 2/27/2012 2:41 PM, Mark Brown wrote:
On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
Depending on what order Mark happens to pull them in, I am fine
re-sending adding support for the 2 twl6030 fixed regulators.
Please can you guys come up with a single unified ser
On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
> Depending on what order Mark happens to pull them in, I am fine
> re-sending adding support for the 2 twl6030 fixed regulators.
Please can you guys come up with a single unified series for this stuff
- I'll hold off on applying any
On 02/25/2012 07:24 AM, Ming Lei wrote:
BTW: suggest you to apply the recent arm pmu irq fix patches[1] to
test 'oprofile'.
[1], http://marc.info/?t=13300128495&r=1&w=2
I tried, and with the same results - "nobody cared" messages
about IRQs 33 and 34.
Dmitry
___
On Monday 27 February 2012 05:45 PM, Peter Ujfalusi wrote:
Hi Rajendra,
On 02/27/2012 12:35 PM, Rajendra Nayak wrote:
Re-sending on top of Tero's changes which are already
in -next and the one which adds support for twl6030
vdd1/2/3 SMPS [1].
Would you be able to add support for V1V8, V2V1 S
Hi Rajendra,
On 02/27/2012 12:35 PM, Rajendra Nayak wrote:
> Re-sending on top of Tero's changes which are already
> in -next and the one which adds support for twl6030
> vdd1/2/3 SMPS [1].
Would you be able to add support for V1V8, V2V1 SMPS supplies in
twl6030? These regulators are need on SD
Pass all the voltage regulator information for
twl6030/twl4030 PMIC from device tree.
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/omap3-beagle.dts |6 +++
arch/arm/boot/dts/twl4030.dtsi | 18 +++
arch/arm/boot/dts/twl6030.dtsi | 60 +
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Also add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak
---
.../bindings/regulator/twl-reg
Re-sending on top of Tero's changes which are already
in -next and the one which adds support for twl6030
vdd1/2/3 SMPS [1].
v3 has mainly 2 differences from v2
-1- TWL driver now uses just one table for both dt and
non-dt based lookup for driver data.
-2- All common regulator nodes for twl4030 a
On Mon, 2012-02-20 at 10:04 +0400, Dmitry Antipov wrote:
> Generalize CONFIG_IRQ_TIME_ACCOUNTING between X86 and
> ARM, move "noirqtime=" option to common debugging code.
> For a bit of backward compatibility, X86-specific option
> "tsc=noirqtime" is preserved, but issues a warning.
>
> Suggested
43 matches
Mail list logo