Since CONFIG_IRQ_TIME_ACCOUNTING is architecture-agnostic,
move it from x86 area to common code.
Signed-off-by: Dmitry Antipov
---
arch/x86/Kconfig | 11 ---
lib/Kconfig.debug | 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/
On 31 January 2012 21:54, Nicolas Pitre wrote:
> On Tue, 31 Jan 2012, Zach Pfeffer wrote:
>
>> On 31 January 2012 15:01, Nicolas Pitre wrote:
>> > You just can't have it both ways. If you focus on a stable platform
>> > then you cannot have the latest features. If you develop new features,
>> >
On Tue, 31 Jan 2012, Zach Pfeffer wrote:
> On 31 January 2012 15:01, Nicolas Pitre wrote:
> > You just can't have it both ways. If you focus on a stable platform
> > then you cannot have the latest features. If you develop new features,
> > it obviously can't be stable. But whatever you do, cu
On 31 January 2012 21:17, Zach Pfeffer wrote:
> On 31 January 2012 15:01, Nicolas Pitre wrote:
>> On Tue, 31 Jan 2012, Zach Pfeffer wrote:
>>
>>> On 31 January 2012 11:19, Nicolas Pitre wrote:
>>> > On Tue, 31 Jan 2012, Zach Pfeffer wrote:
>>> >
>>> >> They love our builds, but they'd really lik
On 31 January 2012 15:01, Nicolas Pitre wrote:
> On Tue, 31 Jan 2012, Zach Pfeffer wrote:
>
>> On 31 January 2012 11:19, Nicolas Pitre wrote:
>> > On Tue, 31 Jan 2012, Zach Pfeffer wrote:
>> >
>> >> They love our builds, but they'd really like it if they could get
>> >> stock AOSP builds for thei
Now that the core cpuidle driver keeps time and handles irq enabling,
remove this functionality. Also, remove irq disabling as all paths to
cpuidle_idle_call already call local_irq_disable. Also, restructure
idle functions as needed by the cpuidle core driver changes.
Signed-off-by: Robert Lee
This patch series moves the timekeeping and irq enabling from the platform
code to the core cpuidle driver. Also, the platform irq disabling was removed
as it appears that all calls into cpuidle_call_idle will have already called
local_irq_disable().
To save reviewers time, only a few platforms w
Now that the core cpuidle driver keeps time and handles irq enabling,
remove this functionality. Also, remove irq disabling as all paths to
cpuidle_idle_call already call local_irq_disable. Also, restructure
idle functions as needed by the cpuidle core driver changes.
Signed-off-by: Robert Lee
Now that the core cpuidle driver keeps time and handles irq enabling,
remove this functionality. Also, remove irq disabling as all paths to
cpuidle_idle_call already call local_irq_disable. Also, restructure
idle functions as needed by the cpuidle core driver changes.
Signed-off-by: Robert Lee
Make necessary changes to add implement time keepign and irq enabling
in the core cpuidle code. This will allow the remove of these
functionalities from the platform cpuidle implementations.
Signed-off-by: Robert Lee
---
drivers/cpuidle/cpuidle.c | 75 +++--
On Mon, Jan 30, 2012 at 12:12:18PM -0600, Christoph Lameter wrote:
> > I thought it didn't. I rememer thinking about this and determining
> > that NULL can't be allocated for dynamic addresses. Maybe I'm
> > imagining things. Anyways, if it can return NULL for valid
> > allocation, it is a bug a
On Tue, 31 Jan 2012, Zach Pfeffer wrote:
> On 31 January 2012 11:19, Nicolas Pitre wrote:
> > On Tue, 31 Jan 2012, Zach Pfeffer wrote:
> >
> >> They love our builds, but they'd really like it if they could get
> >> stock AOSP builds for their boards on stable kernels that they can
> >> work with
I should clarify a little. There are different types of customers. Our
main customers are our members. For our members upgraded kernels and
GCC4.6 allow them to accelerate their delivery.
The customers I've been talking to are actually using our builds to
make stuff. They're the small start-up or
On 31 January 2012 11:19, Nicolas Pitre wrote:
> On Tue, 31 Jan 2012, Zach Pfeffer wrote:
>
>> They love our builds, but they'd really like it if they could get
>> stock AOSP builds for their boards on stable kernels that they can
>> work with using fastboot that have been CI tested and QA'd.
>>
>
I forgot to say that I've installed Linaro Ubuntu Desktop 3.1.1.8 on a
Pandaboard ES.
2012/1/31 Mario :
> Hello.
>
> Since I'm not experienced,I would like to talk with you about this
> potentially bug list :
>
> 1) I can't use another desktop manager except Unity.
>
> I made 3 modifications to ac
On Tue, Jan 31, 2012 at 06:49:18PM +, James Tunnicliffe wrote:
> Each build is run on a clean EC2 instance, so shouldn't worry about
> logins left behind from other activities. This certainly doesn't open
> us up to any more problems than a user who has write access to the box
> could cause any
On 31 January 2012 18:14, Christian Robottom Reis wrote:
> On Tue, Jan 31, 2012 at 03:50:37PM +, James Tunnicliffe wrote:
>> Hi,
>>
>> https://wiki.linaro.org/Platform/Android/LinaroAndroidBuildService has
>> been updated with these instructions about a new build option:
>>
>> EXTERNAL_TARBALL
On Tue, Jan 31, 2012 at 03:50:37PM +, James Tunnicliffe wrote:
> Hi,
>
> https://wiki.linaro.org/Platform/Android/LinaroAndroidBuildService has
> been updated with these instructions about a new build option:
>
> EXTERNAL_TARBALL
>
> Use to request that the build system fetch an archive from
On Tue, 31 Jan 2012, Zach Pfeffer wrote:
> They love our builds, but they'd really like it if they could get
> stock AOSP builds for their boards on stable kernels that they can
> work with using fastboot that have been CI tested and QA'd.
>
> I'm not advocating for the wholesale destruction of o
Oh one more thing...
Our customers actually prefer to build our distro's from source and
not get binary drops.
On 31 January 2012 10:52, Zach Pfeffer wrote:
> So I've been talking to our customers (10 at last count) and they
> really like what we're doing. There are three things that are getting
So I've been talking to our customers (10 at last count) and they
really like what we're doing. There are three things that are getting
in their way:
linaro-android-media-create
GCC4.6
frequent kernel upgrades
They love our builds, but they'd really like it if they could get
stock AOSP builds f
Hi,
https://wiki.linaro.org/Platform/Android/LinaroAndroidBuildService has
been updated with these instructions about a new build option:
EXTERNAL_TARBALL
Use to request that the build system fetch an archive from the
location that you set EXTERNAL_TARBALL to and unpack it into
build/external_ta
On Mon, Jan 30, 2012 at 11:22:14AM -0600, Christoph Lameter wrote:
> On Mon, 30 Jan 2012, Tejun Heo wrote:
>
> > Percpu pointers are in a different address space and using
> > ZERO_SIZE_PTR directly will trigger sparse address space warning.
> > Also, I'm not entirely sure whether 16 is guaranteed
On Mon, 30 Jan 2012, Tejun Heo wrote:
> On Mon, Jan 30, 2012 at 11:22:14AM -0600, Christoph Lameter wrote:
> > On Mon, 30 Jan 2012, Tejun Heo wrote:
> >
> > > Percpu pointers are in a different address space and using
> > > ZERO_SIZE_PTR directly will trigger sparse address space warning.
> > > Al
On Mon, 30 Jan 2012, Tejun Heo wrote:
> Anyways, yeah, it seems we should improve this part too.
I agree.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Hello,
On Mon, Jan 30, 2012 at 11:58:52AM -0600, Christoph Lameter wrote:
> > No, NULL is never gonna be a valid return from any allocator including
> > percpu. Percpu allocator doesn't and will never do so.
>
> How do you prevent the percpu allocator from returning NULL? I thought the
> per cpu
On Mon, Jan 30, 2012 at 12:37:34PM +0400, Dmitry Antipov wrote:
> Fix pcpu_alloc() to return ZERO_SIZE_PTR if requested size is 0;
> fix free_percpu() to check passed pointer with ZERO_OR_NULL_PTR.
>
> Signed-off-by: Dmitry Antipov
> ---
> mm/percpu.c | 16 +++-
> 1 files changed,
Hello, Christoph.
On Mon, Jan 30, 2012 at 11:52:23AM -0600, Christoph Lameter wrote:
> We have two possibilities now:
>
> 1. We say that the value returned from the per cpu allocator is an opaque
> value.
>
> This means that we have to remove the NULL check from the free
> function.
On Mon, Jan 30, 2012 at 09:15:58AM -0800, Tejun Heo wrote:
> Percpu pointers are in a different address space and using
> ZERO_SIZE_PTR directly will trigger sparse address space warning.
> Also, I'm not entirely sure whether 16 is guaranteed to be unused in
> percpu address space (maybe it is but
On Mon, 30 Jan 2012, Tejun Heo wrote:
> Hello, Christoph.
>
> On Mon, Jan 30, 2012 at 11:52:23AM -0600, Christoph Lameter wrote:
> > We have two possibilities now:
> >
> > 1. We say that the value returned from the per cpu allocator is an opaque
> > value.
> >
> > This means that we have to re
On Mon, 30 Jan 2012, Tejun Heo wrote:
> Hello,
>
> On Mon, Jan 30, 2012 at 11:58:52AM -0600, Christoph Lameter wrote:
> > > No, NULL is never gonna be a valid return from any allocator including
> > > percpu. Percpu allocator doesn't and will never do so.
> >
> > How do you prevent the percpu all
On Mon, 30 Jan 2012, Tejun Heo wrote:
> On Mon, Jan 30, 2012 at 09:15:58AM -0800, Tejun Heo wrote:
> > Percpu pointers are in a different address space and using
> > ZERO_SIZE_PTR directly will trigger sparse address space warning.
> > Also, I'm not entirely sure whether 16 is guaranteed to be unu
On Mon, 30 Jan 2012, Tejun Heo wrote:
> Percpu pointers are in a different address space and using
> ZERO_SIZE_PTR directly will trigger sparse address space warning.
> Also, I'm not entirely sure whether 16 is guaranteed to be unused in
> percpu address space (maybe it is but I don't think we hav
On Mon, Jan 30, 2012 at 11:22:57AM -0600, Christoph Lameter wrote:
> On Mon, 30 Jan 2012, Tejun Heo wrote:
>
> > On Mon, Jan 30, 2012 at 09:15:58AM -0800, Tejun Heo wrote:
> > > Percpu pointers are in a different address space and using
> > > ZERO_SIZE_PTR directly will trigger sparse address spac
On Mon, Jan 30, 2012 at 10:02:24AM -0800, Tejun Heo wrote:
> I thought it didn't. I rememer thinking about this and determining
> that NULL can't be allocated for dynamic addresses. Maybe I'm
> imagining things. Anyways, if it can return NULL for valid
> allocation, it is a bug and should be fix
On Mon, 30 Jan 2012, Tejun Heo wrote:
> I'm pretty sure it never gives out NULL for a dynamic allocation. The
> base might be mapped to zero but we're guaranteed to have some static
> percpu areas there and IIRC the percpu addresses aren't supposed to
> wrap.
True but there is a check for a NULL
On Mon, 30 Jan 2012 10:16:39 -0800, Tejun Heo wrote:
> On Mon, Jan 30, 2012 at 12:12:18PM -0600, Christoph Lameter wrote:
> > > I thought it didn't. I rememer thinking about this and determining
> > > that NULL can't be allocated for dynamic addresses. Maybe I'm
> > > imagining things. Anyways,
37 matches
Mail list logo
