On Wed, Aug 21, 2013 at 05:09:39PM -0700, Christoffer Dall wrote:
> Linaro is going to host a bi-weekly sync-up call for technical issues on
> KVM/ARM development. The KVM 32-bit and 64-bit maintainers as well as
> the QEMU ARM maintainer will typically be on the call.
>
> The first call will be
Please read back on this list for my comments about such moves of this
very code. You're not the first.
On Mon, May 20, 2013 at 12:03:24PM +0530, Sanjay Singh Rawat wrote:
> Generic arm cpu hotplug related functions are moved to core hotplug code,
> remove the functions from the platform code.
>
On Mon, Mar 18, 2013 at 01:15:51PM -0700, Mike Turquette wrote:
> Quoting Ulf Hansson (2013-02-28 01:54:34)
> > On 28 February 2013 05:49, Mike Turquette wrote:
> > > @@ -703,10 +744,29 @@ int clk_enable(struct clk *clk)
> > > unsigned long flags;
> > > int ret;
> > >
> > > +
On Thu, Mar 14, 2013 at 02:31:04AM -0700, Bill Huang wrote:
> Add the below two notifier events so drivers which are interested in
> knowing the clock status can act accordingly. This is extremely useful
> in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
>
> CLK_PREPARED
> CLK_UNPRE
On Thu, Mar 14, 2013 at 11:22:47PM -0600, Stephen Warren wrote:
> Is clk_set_rate() only legal to call in non-atomic contexts then? The
> header file doesn't say, although I guess since many other functions
> explicitly say they can't, then by omission it can...
I think when all this was discussed
On Tue, Mar 12, 2013 at 10:40:04PM -0700, Bill Huang wrote:
> That will be too bad, it looks like we deadlock in the mechanism, we
> cannot change existing drivers behavior (that means some call
> clk_disable/enable directly, some are not), and we cannot hook notifier
> in clk_disable/enable either
On Tue, Mar 12, 2013 at 10:42:30PM -0600, Stephen Warren wrote:
> I believe the point Russell is making is not that the idea behind this
> patch is wrong, but simply that the function where you put the hooks is
> wrong. The hooks should at least be in clk_enable/clk_disable and not
Indeed, remembe
On Tue, Mar 12, 2013 at 06:47:53PM -0700, Bill Huang wrote:
> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
> > On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
> > > Add the below four notifier events so drivers which are interested in
>
On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
> Add the below four notifier events so drivers which are interested in
> knowing the clock status can act accordingly. This is extremely useful
> in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
>
> PRE_CLK_ENABLE
> POST_C
On Thu, Feb 28, 2013 at 11:03:57PM +0100, Sylwester Nawrocki wrote:
> Please just use IS_ERR(), let's stop this IS_ERR_OR_NULL() insanity.
Yes, indeed.
On that topic (and off-topic for this thread, sorry) I've committed
a set of patches to remove most users of IS_ERR_OR_NULL() from arch/arm.
Thes
On Thu, Feb 21, 2013 at 10:53:07PM +0100, Frederic Weisbecker wrote:
> That too should be kcpustat_this_cpu_set(), or kcpustat_this_cpu_add()
> FWIW. But we probably don't need the overhead of atomic_add() that
> does a LOCK.
> atomic_set(var, atomic_read(var) + delta) would be better. All we need
On Fri, Jul 27, 2012 at 03:39:31PM +0100, Ian Campbell wrote:
> On Fri, 2012-07-27 at 15:21 +0100, Russell King - ARM Linux wrote:
> > On Fri, Jul 27, 2012 at 02:02:18PM +0100, Stefano Stabell
On Fri, Jul 27, 2012 at 02:02:18PM +0100, Stefano Stabellini wrote:
> > > > +/**
> > > > + * hypercall.h
> > > > + *
> > > > + * Linux-specific hypervisor handling.
> > > > + *
> > > > + * Stefano Stabellini , Citrix, 2012
On Wed, May 09, 2012 at 01:50:28PM +0100, Sangwook Lee wrote:
> struct generic_pm_domain already has a field for name. Use that field
> instead of creating another field in struct exynos_pm_domain
Argh. No.
> @@ -99,7 +98,7 @@ static __init int exynos_pm_dt_parse_domains(void)
>
>
On Thu, May 10, 2012 at 11:55:15AM +0100, Ben Dooks wrote:
> On Thu, May 03, 2012 at 03:18:53PM +0100, Russell King - ARM Linux wrote:
> > I think what you're proposing is a totally artificial restriction.
> > There's no problem with a kernel supporting DT and non-DT t
On Fri, May 04, 2012 at 10:03:40PM +0200, Linus Walleij wrote:
> On Fri, May 4, 2012 at 4:35 PM, Russell King - ARM Linux
> wrote:
>
> > Well, my understanding is that there's DT patches around for Versatile.
>
> Is there? There is some in-tree stuff, but haven&
On Fri, May 04, 2012 at 11:39:30AM -0500, Rob Herring wrote:
> Many of the headers are simply platform_data structs which may still be
> needed on DT platforms, but could be moved elsewhere.
Those should be in include/linux/platform.
> >> Then there's also the problem of uncompress.h. The last p
On Fri, May 04, 2012 at 03:20:57PM +0100, Wookey wrote:
> Debian tries very hard not to support anything in the kernel that
> upstream don't support in the kernel because otherwise it's way too
> much work. The current list of supplied arm kernels is:
>
> iop32x (ThecusN2100, intel SS4000, GLAN ta
On Thu, May 03, 2012 at 10:38:15PM -0700, Deepak Saxena wrote:
> I'm of the opinion that we support DT only platforms for
> multi-platform but this is based on the approach of only caring for
> multi-platform for newer systems and not worrying too much for legacy
> HW.
You do realise that you're a
On Thu, May 03, 2012 at 11:31:13PM -0700, Deepak Saxena wrote:
> On 3 May 2012 07:04, Russell King - ARM Linux wrote:
> > On Thu, May 03, 2012 at 01:50:35PM +, Arnd Bergmann wrote:
> >> Hi everyone,
> >>
> >> I've been discussing multiplatform kernel
On Thu, May 03, 2012 at 01:50:35PM +, Arnd Bergmann wrote:
> My feeling is that we should just mandate DT booting for multiplatform
> kernels, because it significantly reduces the combinatorial space
> at compile time, avoids a lot of legacy board files that we cannot
> test anyway, reduces the
On Thu, May 03, 2012 at 01:50:35PM +, Arnd Bergmann wrote:
> Hi everyone,
>
> I've been discussing multiplatform kernels with a few people recently,
> and we will have a lot of discussion sessions about this at Linaro
> Connect in Hong Kong.
>
> One question that came up repeatedly is whether
On Tue, Apr 24, 2012 at 10:40:35AM -0500, Rob Lee wrote:
> Thanks for the attention on this. From what I've understood, I will
> send another submission that includes the imx cpuidle patchset and
> Shawn's device tree late initcall patchset and I'll provide
> explanation of the two separate patchs
On Tue, Apr 24, 2012 at 09:38:43AM +0800, Shawn Guo wrote:
> On Mon, Apr 23, 2012 at 10:45:02AM -0500, Rob Lee wrote:
> > >> Let me try last time. What about having a late_initcall hook in
> > >> machine_desc?
> > >
> > > Also fine with me.
> > >
> >
> > Shall I add Shawn's patch to my imx cpuidl
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
> The meaning of clk_enable/disable has been changed and they won't work
> without calling clk_prepare/unprepare. So, these are definitely new
> APIs. If it weren't new APIs, then none of the general drivers would
> need to chan
On Thu, Mar 01, 2012 at 10:27:02AM +, Dave Martin wrote:
> So, where there's a compelling reason to inline these things, we can use
> the existing techniques if we're alert to the risks. But in cases where
> there isn't a compelling reason, aren't we just inviting fragility
> unnecessarily?
T
On Wed, Feb 29, 2012 at 02:44:24PM +, Ian Campbell wrote:
> > If you need a specific register, this means that you must set up that
> > register explicitly inside the asm if you want a guarantee that the
> > code will work:
> >
> > asm volatile (
> > "movw r12, %[hvc_num]\n\t
On Wed, Feb 29, 2012 at 12:58:26PM +, Dave Martin wrote:
> On Wed, Feb 29, 2012 at 09:56:02AM +, Ian Campbell wrote:
> > On Wed, 2012-02-29 at 09:34 +, Dave Martin wrote:
> > > On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote:
> >
> > > > I don't have a very strong op
On Fri, Feb 24, 2012 at 02:45:48PM +0100, 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
> routine has to che
On Fri, Feb 24, 2012 at 03:56:52PM +0530, Rajendra Nayak wrote:
> I don't know if we can, but even if we could, we take care of the same
> bootargs working on two boards (say sdp and panda) *if* on sdp I have my
> filesystem on eMMC and on panda I have it on external card.
> What happens if I want
On Tue, Feb 21, 2012 at 05:43:54PM +0530, S, Venkatraman wrote:
> On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak wrote:
> > @@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> > *host)
> > mmc_slot(host).ocr_mask = ocr_value;
> > } else
On Mon, Feb 20, 2012 at 09:48:56AM -0800, viresh kumar wrote:
> On Feb 20, 2012 4:31 PM, "Catalin Marinas" wrote:
> >
> > On 16 February 2012 18:14, viresh kumar wrote:
> > > On Thu, Feb 16, 2012 at 9:48 AM, Catalin Marinas
> > > wrote:
> > >> The DMA API implementation on ARM takes care of the
On Thu, Feb 16, 2012 at 05:29:28PM +, Catalin Marinas wrote:
> On Thu, Feb 16, 2012 at 05:22:42PM +0000, Russell King - ARM Linux wrote:
> > On Thu, Feb 16, 2012 at 05:15:20PM +, Catalin Marinas wrote:
> > > On Thu, Feb 16, 2012 at 04:41:02PM +, viresh kumar wrote:
On Thu, Feb 16, 2012 at 05:15:20PM +, Catalin Marinas wrote:
> On Thu, Feb 16, 2012 at 04:41:02PM +, viresh kumar wrote:
> > Sorry for starting the long old thread again, but i have to start it as i
> > was a bit confused. :(
> >
> > We know that we can't have multiple mappings with differ
On Wed, Feb 08, 2012 at 07:15:26AM -0800, Dmitry Antipov wrote:
> On 02/08/2012 05:18 AM, Russell King - ARM Linux wrote:
>> Why are you placing this here? sched_clock is available from the point
>> that it's registered, which should be before the first sched_clock()
>&
On Wed, Feb 08, 2012 at 04:48:34AM -0800, 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, "tsc=noirqtime"
> is preserved, but issues a warning.
>
> Suggested-by: Venki Pa
On Mon, Jan 09, 2012 at 10:52:48PM +0800, Richard Zhao wrote:
> On Fri, Jan 06, 2012 at 08:53:37AM +0800, Richard Zhao wrote:
> > On Thu, Jan 05, 2012 at 06:16:54AM +0800, Richard Zhao wrote:
> > > hi Russell,
> > >
> > > May I have your ACK, you merge it?
> > Russell, ping
> would you have time t
On Tue, Jan 17, 2012 at 01:10:53AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> diff --git a/arch/arm/mach-mx5/board-mx53_loco.c
> b/arch/arm/mach-mx5/board-mx53_loco.c
> index fd8b524..61dd8c9 100644
> --- a/arch/arm/mach-mx5/board-mx53_loco.c
> +++ b/arch/arm/mach-mx5/board-mx53_loco.c
> @@ -23,10 +2
On Fri, Jan 13, 2012 at 12:36:31PM +, Mans Rullgard wrote:
> This fixes the thrd->req_running field being accessed before thrd
> is checked for null. The error was introduced in abb959f.
>
> Signed-off-by: Mans Rullgard
I don't know what's happening with the PL330 driver, but there's patche
On Tue, Jan 03, 2012 at 09:25:30PM +0800, Richard Zhao wrote:
> Hi Russel,
>
> On 3 January 2012 17:06, Russell King - ARM Linux
> wrote:
> > On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote:
> >> On Mon, Dec 26, 2011 at 11:10:30AM +, Mark Brown wrote:
On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote:
> On Mon, Dec 26, 2011 at 11:10:30AM +, Mark Brown wrote:
> > The *call* is there in the regulator subsystem, it's just that none of
> > the drivers back it up with an actual implementation yet. Which turns
> > out to be a good thin
On Thu, Dec 22, 2011 at 02:19:23PM +0530, Shilimkar, Santosh wrote:
> + Peter Z
>
> On Wed, Dec 21, 2011 at 3:37 PM, Russell King - ARM Linux
> wrote:
> > On Wed, Dec 21, 2011 at 05:59:07PM +0800, Barry Song wrote:
> >> 2011/12/21 Russell King - ARM Linux :
>
On Wed, Dec 21, 2011 at 05:59:07PM +0800, Barry Song wrote:
> 2011/12/21 Russell King - ARM Linux :
> > cpu hotplug is basically totally buggered - the preconditions placed
> > upon the bringup code path are basically impossible to satisfy in any
> > shape or form at the mo
On Wed, Dec 21, 2011 at 05:23:48PM +0800, Barry Song wrote:
> Hi guys,
> i tried cpuhotplug on pandaboard for both
> Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to
> work stably.
> On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well:
> # echo 0 > /sys/devices/sy
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
> On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner wrote:
> > On Tue, 13 Dec 2011, Mike Turquette wrote:
> >> +void __clk_unprepare(struct clk *clk)
> >> +{
> >> + if (!clk)
> >> + return;
> >> +
> >> + if (WARN_O
On Thu, Dec 15, 2011 at 12:50:07PM -0600, Mark Langsdorf wrote:
> I'd prefer to see clk_get90 replaced with of_clk_get() and
> get_this_cpu_node() from the clk-cpufreq driver by Jamie Iles that
> I resubmitted yesterday.
Why isn't of_clk_get() hidden inside clk_get() ?
___
On Thu, Dec 15, 2011 at 07:16:35PM +0800, Richard Zhao wrote:
> +#ifdef CONFIG_SMP
> + /* loops_per_jiffy is not updated by the cpufreq core for SMP systems.
> + * So update it for all CPUs.
> + */
> + for_each_possible_cpu(cpu)
> + per_cpu(cpu_data, cpu).loops_per_jif
On Mon, Dec 05, 2011 at 02:15:56PM -0700, Paul Walmsley wrote:
> The types associated with clock rates in the clock interface
> (include/linux/clk.h) are inconsistent, and we should fix this.
Rubbish. They're different with good reason. Rates are primerily
unsigned quantities - and should be t
On Fri, Dec 02, 2011 at 10:13:10AM -0700, Paul Walmsley wrote:
> Hi Russell,
>
> On Thu, 1 Dec 2011, Russell King - ARM Linux wrote:
>
> > On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> > > 1. When a clock user calls clk_enable() on a clock, the cl
On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
> The intention behind the clk_{allow,block}_rate_change() proposal was to
> allow the current user of the clock to change its rate without having to
> call clk_{allow,block}_rate_change(), if that driver was the sole user of
> the c
On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> 1. When a clock user calls clk_enable() on a clock, the clock framework
> should prevent other users of the clock from changing the clock's rate.
> This should persist until the clock user calls clk_disable() (but see also
> #2 be
On Wed, Nov 23, 2011 at 10:55:19AM -0800, Tony Lindgren wrote:
> What else are you aware of that is really needed early for clocks other
> than clockevent?
TWD will lose its auto-calibration. Then there's various clock source
and clock event implementations. These all call for the clk API to be
On Wed, Nov 23, 2011 at 08:59:04AM -0800, Tony Lindgren wrote:
> ..let's plan on getting rid of the early usage of clocks instead so
> you don't have the issue of deferring stuff.
No - we have too many platforms already using them early to do a change
like this - and to do such a change will force
On Tue, Nov 22, 2011 at 07:42:59AM -0800, Greg KH wrote:
> On Mon, Nov 21, 2011 at 05:40:42PM -0800, Mike Turquette wrote:
> > .sysfs support. Visualize your clk tree at /sys/clk! Where would be
> > a better place to put the clk tree besides the root of /sys/?
>
> Um, in the "proper" place for
On Mon, Oct 17, 2011 at 01:05:39PM +0200, Sascha Hauer wrote:
> It's not a problem to associate multiple clocks to a device, we can do
> this now already. What a driver can't do now is
> give-me-all-clocks-I-need(dev),
> but this problem should not be solved at clock core level but at the
> clkdev
On Thu, Sep 22, 2011 at 03:26:59PM -0700, Mike Turquette wrote:
> diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
> new file mode 100644
> index 000..a1d8e79
> --- /dev/null
> +++ b/drivers/clk/clk-gate.c
> @@ -0,0 +1,78 @@
> +/*
> + * Copyright (C) 2010-2011 Canonical Ltd
> + *
>
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> struct clk_hw_ops {
> int (*prepare)(struct clk_hw *);
> void(*unprepare)(struct clk_hw *);
> int (*enable)(struct clk_hw *);
> void(*disable)(struct clk_hw *)
On Mon, Oct 03, 2011 at 05:31:08PM +0100, Mark Brown wrote:
> I dunno, I get the impression that some of this is due to the current
> limitations of the clock API rather than due to a lack of clocks -
> perhaps that's specific to the applications I look at, though.
> applications
The clk API per-
On Mon, Oct 03, 2011 at 03:10:41PM +0530, Tushar Behera wrote:
> Some of the functions and structures did not have _init or __initdata
> attributes, even though they were referenced from functions / structures
> with those attribute, resulting in section mismatches.
Firstly - it's a good idea to i
On Fri, Sep 09, 2011 at 12:30:11PM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 08:01:35PM +0100, Russell King - ARM Linux wrote:
>
> > Well, with DT, there won't be any 'board type' anymore. There won't be
> > any 'machine_is_xxx()' to sort
On Fri, Sep 09, 2011 at 12:38:51PM +0100, Mans Rullgard wrote:
> This converts the per-board modules to platform drivers for a
> device created by in main platform setup. These drivers call
> snd_soc_register_card() directly instead of going via a "soc-audio"
> device and the corresponding driver
On Fri, Sep 09, 2011 at 09:11:52AM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 10:41:56AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:
>
> > > The problem is that someone has to manually go and add the device
On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 12:01:02AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 08, 2011 at 03:47:31PM -0700, Mark Brown wrote:
>
> > > What will happen for device tree is that there will be a device in
On Thu, Sep 08, 2011 at 03:47:31PM -0700, Mark Brown wrote:
> On Thu, Sep 08, 2011 at 11:37:20PM +0100, Russell King - ARM Linux wrote:
>
> > With DT of course, all devices get instantiated from the device tree,
> > so there should not be any more platform specific chunks of
On Thu, Sep 08, 2011 at 03:29:11PM -0700, Mark Brown wrote:
> On Thu, 2011-09-08 at 22:28 +0200, Arnd Bergmann wrote:
> > On Thursday 08 September 2011 20:05:48 Mans Rullgard wrote:
>
> > > I had the same thought, but I couldn't find a suitable string anywhere.
> > > Are you suggesting an if(machi
On Sun, Aug 28, 2011 at 12:50:54PM +0200, Per Forlin wrote:
> On 26 August 2011 18:28, Santosh wrote:
> > + Balaji,
> >
> > On Friday 26 August 2011 09:49 PM, Russell King - ARM Linux wrote:
> >>
> >> I'm not sure who's responsible for this, but
I'm not sure who's responsible for this, but the nonblocking MMC stuff is
broken on OMAPs HSMMC:
mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response 0x900,
card status 0xb00
mmcblk0: retrying using single block re
On Fri, Aug 19, 2011 at 06:39:59PM +0530, Amit Daniel Kachhap wrote:
> +ENTRY(exynos4_enter_lp)
> + stmfd sp!, { r3 - r12, lr }
> +
> + adr r0, sleep_save_misc
> +
> + mrc p15, 0, r2, c15, c0, 0 @ read power control register
> + str r2, [r0], #4
> +
> + mrc p1
On Mon, Aug 08, 2011 at 12:34:33PM +0100, Vincent Guittot wrote:
> On 8 August 2011 12:09, Russell King - ARM Linux
> wrote:
> > On Tue, Jul 05, 2011 at 02:16:23PM +0100, Russell King - ARM Linux wrote:
> >> Looks fine now, and so can go to my patch system. Many thanks.
&g
On Mon, Aug 08, 2011 at 04:42:42PM +0530, RACHANA TEWARI wrote:
> Does anyone know way to initiate a bash script(to run on linux box) from
> windows Written in C#?
>
> How to write these Scripts...
This has nothing to do with CPU topology. Please do not topic hijack.
This is also off-topic for t
On Tue, Jul 05, 2011 at 02:16:23PM +0100, Russell King - ARM Linux wrote:
> Looks fine now, and so can go to my patch system. Many thanks.
Ping.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lin
On Thu, Jul 21, 2011 at 11:03:04AM +0530, Santosh Shilimkar wrote:
> Just talking on behalf of OMAP, we can't offline CPU0 and limitation
> would remain in future OMAPs too.
Apart from the broken IRQ migration, and the way CPU0 immediately
reawakes if it is offlined on OMAP4 (even when IRQs are mi
On Wed, Jul 20, 2011 at 04:32:25PM -0700, Mike Turquette wrote:
> A quick poll of the ARM platforms that implement CPU Hotplug support
> shows that every platform treats CPU 0 as a special case that cannot be
> hotplugged. In fact every platform has identical code for
> platform_cpu_die which retu
On Tue, Jul 12, 2011 at 11:12:57AM +0100, Lorenzo Pieralisi wrote:
> Thank you very much Russell for this recap.
>
> On Mon, Jul 11, 2011 at 07:40:10PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
> > > Well
On Mon, Jul 11, 2011 at 01:05:20PM -0700, Santosh Shilimkar wrote:
> (Just to add few more points on top of what Colin already commented)
>
> On 7/11/2011 11:40 AM, Russell King - ARM Linux wrote:
>> On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
>>>
On Mon, Jul 11, 2011 at 11:51:00AM -0700, Colin Cross wrote:
> On Mon, Jul 11, 2011 at 11:40 AM, Russell King - ARM Linux
> wrote:
> > On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
> >> Well, short answer is no. On SMP we do need to save CPU registers
On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
> Well, short answer is no. On SMP we do need to save CPU registers
> but if just one single cpu is shutdown L2 is still on.
> cpu_suspend saves regs on the stack that has to be cleaned from
> L2 before shutting a CPU down which m
On Sun, Jul 10, 2011 at 12:00:24PM +0100, Will Deacon wrote:
> I've had a look at a bunch of the cpu_*_reset definitions and I can't see
> any reason why they wouldn't be callable with the flat mapping in place. In
> fact, there's a scary comment for xscale:
However, that flat mapping doesn't save
On Sat, Jul 09, 2011 at 04:01:19PM -0700, Colin Cross wrote:
> On Sat, Jul 9, 2011 at 3:33 PM, Russell King - ARM Linux
> wrote:
> > On Sat, Jul 09, 2011 at 03:10:56PM -0700, Colin Cross wrote:
> >> This is necessary for cpuidle states that lose the GIC registers, not
>
On Sat, Jul 09, 2011 at 03:10:56PM -0700, Colin Cross wrote:
> This is necessary for cpuidle states that lose the GIC registers, not
> just suspend, because the GIC is in the cpu's power domain. We could
> avoid saving and restoring all the GIC registers in suspend and idle
> by reusing the initia
On Sat, Jul 09, 2011 at 11:44:08AM +0100, Russell King - ARM Linux wrote:
> We need to sort this out so we have a _sane_ approach to this, rather
> than inventing more and more creative ways to save VFP state and
> restore it later.
And here, let's prove that the current code is j
On Thu, Jul 07, 2011 at 04:50:17PM +0100, Lorenzo Pieralisi wrote:
> From: Colin Cross
>
> When the cpu is powered down in a low power mode, the vfp
> registers may be reset.
>
> This patch uses CPU_PM_ENTER and CPU_PM_EXIT notifiers to save
> and restore the cpu's vfp registers.
>
> Signed-off
On Thu, Jul 07, 2011 at 04:50:16PM +0100, Lorenzo Pieralisi wrote:
> From: Colin Cross
>
> When the cpu is powered down in a low power mode, the gic cpu
> interface may be reset, and when the cpu complex is powered
> down, the gic distributor may also be reset.
>
> This patch uses CPU_PM_ENTER a
On Thu, Jul 07, 2011 at 04:50:15PM +0100, Lorenzo Pieralisi wrote:
> During some CPU power modes entered during idle, hotplug and
> suspend, peripherals located in the CPU power domain, such as
> the GIC and VFP, may be powered down. Add a notifier chain
> that allows drivers for those peripherals
On Thu, Jul 07, 2011 at 04:50:14PM +0100, Lorenzo Pieralisi wrote:
> From: Will Deacon
>
> This patch adds simple definitions of cpu_reset for ARMv6 and ARMv7
> cores, which disable the MMU via the SCTLR.
This really needs fixing properly, so that we have this well defined
across all supported A
The idea of splitting a large patch up into smaller patches is to do
it in a logical way so that:
1. Each patch is self-contained, adding a single new - and where possible
complete - feature or bug fix.
2. Ease of review.
Carving your big patch up by file does not do either of this, because
al
On Sat, Jul 09, 2011 at 09:38:15AM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 07, 2011 at 04:50:18PM +0100, Lorenzo Pieralisi wrote:
> > +static int late_init(void)
> > +{
> > + int rc;
> > + struct sr_cluster *cluster;
> > + int cluster_index, cpu_
On Thu, Jul 07, 2011 at 04:50:18PM +0100, Lorenzo Pieralisi wrote:
> +static int late_init(void)
> +{
> + int rc;
> + struct sr_cluster *cluster;
> + int cluster_index, cpu_index = sr_platform_get_cpu_index();
Stop this madness, and use the standard linux APIs like smp_processor_id
her
On Thu, Jul 07, 2011 at 04:50:13PM +0100, Lorenzo Pieralisi wrote:
> This patchset is a first attempt at providing a consolidation of idle
> code for the ARM processor architecture and a request for comment on
> the provided methodology.
> It relies and it is based on kernel features such as suspen
Looks fine now, and so can go to my patch system. Many thanks.
On Mon, Jul 04, 2011 at 06:49:45PM +0200, Vincent Guittot wrote:
> The affinity between ARM processors is defined in the MPIDR register.
> We can identify which processors are in the same cluster,
> and which ones have performance int
On Tue, Jun 28, 2011 at 09:22:20AM +0300, saeed bishara wrote:
> On Mon, Jun 27, 2011 at 2:02 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jun 27, 2011 at 01:34:48PM +0300, saeed bishara wrote:
> >> Russell,
> >> I'm curious about the correctness of thi
On Fri, Jul 01, 2011 at 06:44:43PM +0200, Arnd Bergmann wrote:
> On Thursday 30 June 2011, Russell King - ARM Linux wrote:
> > We've been here before - with PCMCIA's card insertion code, where you
> > have to go through a sequence of events (insert, power up, reset, etc).
On Fri, Jul 01, 2011 at 07:43:30AM +0200, Vincent Guittot wrote:
> Changes since v3 :
> * Update the format of printk message
> * Remove blank line
Can I trouble you to check the patch for more instances of the 'blank line
at end of function' thing... Also, let's get rid of unnecessary parens.
>
On Thu, Jun 30, 2011 at 03:12:46PM +0200, Arnd Bergmann wrote:
> I think this looks good enough to merge into the linux-mmc tree, the code is
> clean and the benefits are clear.
>
> Acked-by: Arnd Bergmann
>
> One logical follow-up as both a cleanup and performance optimization would be
> to get
On Fri, Jun 24, 2011 at 08:38:44PM +0200, Vincent Guittot wrote:
> + printk(KERN_INFO "cpu %u : thread %d cpu %d, socket %d, mpidr %x\n",
> + cpuid, cpu_topology[cpuid].thread_id,
> + cpu_topology[cpuid].core_id,
> + cpu_topology[cpuid].socket_id, mpidr);
> +
On Mon, Jun 27, 2011 at 01:34:48PM +0300, saeed bishara wrote:
> Russell,
> I'm curious about the correctness of this patch for systems with
> outer cache. shouldn't the dsb be issued before the outer cache
> maintenance?
Maybe we should do two passes over SG lists then - one for the inner and
a
On Mon, Jun 27, 2011 at 11:42:52AM +0200, Per Forlin wrote:
> Conclusion:
> Working with mmc the relative cost of DSB is almost none. There seems
> to be slightly higher number for mmc blocking requests with the DSB
> patch compared to not having it.
These figures suggest that dsb is comparitively
On Tue, Jun 21, 2011 at 11:26:27AM +0200, Per Forlin wrote:
> Here are the results.
It looks like this patch is either a no-op or slightly worse. As
people have been telling me that dsb is rather expensive, and this
patch results in less dsbs, I'm finding these results hard to believe.
It seems t
On Sun, Jun 19, 2011 at 11:17:26PM +0200, Per Forlin wrote:
> How significant is the cache maintenance over head?
Per,
Can you measure how much difference this has before and after your
patch set please? This moves the dsb() out of the individual cache
maintanence functions, such that we will on
On Mon, Jun 20, 2011 at 05:37:07PM +0530, Premi, Sanjeev wrote:
> [sp] Instead of changing the omap2plus_defconfig, shouldn't the
> board specific file be fixed instead?
The board specific configuration files in the mainline kernel are
deprecated and are gradually being removed.
1 - 100 of 127 matches
Mail list logo
