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 held
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 mturque...@linaro.org wrote:
@@ -703,10 +744,29 @@ int clk_enable(struct clk *clk)
unsigned long flags;
int ret;
+
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
knowing the clock status can act
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,
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 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 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_UNPREPARED
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
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.
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 Stabellini wrote
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)
if
On Thu, May 03, 2012 at 11:31:13PM -0700, Deepak Saxena wrote:
On 3 May 2012 07:04, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
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
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
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 tank)
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 piece
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
li...@arm.linux.org.uk wrote:
Well, my understanding is that there's DT patches around for Versatile.
Is there? There is some in-tree stuff, but haven't seen any other
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 cpuidle patchset or should
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 patchsets
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 change.
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 opinion on
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
Is gcc
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?
The
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 to
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 check
On Tue, Feb 21, 2012 at 05:43:54PM +0530, S, Venkatraman wrote:
On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak rna...@ti.com wrote:
@@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
mmc_slot(host).ocr_mask = ocr_value;
}
On Mon, Feb 20, 2012 at 09:48:56AM -0800, viresh kumar wrote:
On Feb 20, 2012 4:31 PM, Catalin Marinas catalin.mari...@arm.com wrote:
On 16 February 2012 18:14, viresh kumar viresh.li...@gmail.com wrote:
On Thu, Feb 16, 2012 at 9:48 AM, Catalin Marinas
catalin.mari...@arm.com 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 different
On Thu, Feb 16, 2012 at 05:29:28PM +, Catalin Marinas wrote:
On Thu, Feb 16, 2012 at 05:22:42PM +, 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:
Sorry for starting
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 Pallipadi
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()
call.
This is just because I'm
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 to look at this
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 +23,21
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 mans.rullg...@linaro.org
I don't know what's happening with the PL330
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 thing as
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
li...@arm.linux.org.uk 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
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
li...@arm.linux.org.uk wrote:
On Wed, Dec 21, 2011 at 05:59:07PM +0800, Barry Song wrote:
2011/12/21 Russell King - ARM Linux li...@arm.linux.org.uk
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
On Wed, Dec 21, 2011 at 05:59:07PM +0800, Barry Song wrote:
2011/12/21 Russell King - ARM Linux li...@arm.linux.org.uk:
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 moment
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 13 Dec 2011, Mike Turquette wrote:
+void __clk_unprepare(struct clk *clk)
+{
+ if (!clk)
+ return;
+
+ if
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_jiffy =
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
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 clock framework
should prevent other
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
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 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 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 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
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-se
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 to
every board that needs
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 in
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 it out anymore. Using DT, all that will
be history
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
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 code in
these locations
On Sun, Aug 28, 2011 at 12:50:54PM +0200, Per Forlin wrote:
On 26 August 2011 18:28, Santosh santosh.shilim...@ti.com 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 the nonblocking MMC stuff is
broken
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
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 p15, 0,
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/linaro-dev
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
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 returns
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
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, short answer is no. On SMP we
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:
Well, short answer is no. On SMP we
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 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_index = sr_platform_get_cpu_index();
Stop
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
On Thu, Jul 07, 2011 at 04:50:14PM +0100, Lorenzo Pieralisi wrote:
From: Will Deacon will.dea...@arm.com
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
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 to
On Thu, Jul 07, 2011 at 04:50:16PM +0100, Lorenzo Pieralisi wrote:
From: Colin Cross ccr...@android.com
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
On Thu, Jul 07, 2011 at 04:50:17PM +0100, Lorenzo Pieralisi wrote:
From: Colin Cross ccr...@android.com
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.
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 just soo bloody
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
li...@arm.linux.org.uk 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
just
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
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
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
li...@arm.linux.org.uk wrote:
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
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).
The PCMCIA code used to have
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 a...@arndb.de
One logical follow-up as both a cleanup and performance optimization would be
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
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
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 Thu, Jun 16, 2011 at 10:49:13AM +0200, Vincent Guittot wrote:
@@ -219,6 +219,24 @@ source kernel/Kconfig.freezer
menu System Type
+config SCHED_MC
+ bool Multi-core scheduler support
+ depends on SMP ARM_CPU_TOPOLOGY
+ default n
+ help
+ Multi-core scheduler
On Wed, May 11, 2011 at 10:44:49PM +0200, Grant Likely wrote:
Right now it merges cleanly with linux-next and the resulting tree
builds and boots at least on qemu. Unless you really object, I'm
going to ask Stephen to add the following branch to the /end/ of the
list of trees for linux-next
On Mon, Mar 21, 2011 at 11:17:19AM +0100, Linus Walleij wrote:
Does anyone beside me *ever* try to actually boot a recent kernel
on this thing?
How do you do it? Do I need patched U-boots etc, or can I just load
a Z-record image of vmlinux into RAM over the serial console?
Needless to
On Thu, Mar 10, 2011 at 03:14:11PM +0100, Marek Szyprowski wrote:
Hello,
On Tuesday, March 08, 2011 9:14 AM Hans Verkuil wrote:
We had a discussion yesterday regarding ways in which linaro can assist
V4L2 development. One topic was that of sorting out memory providers like
GEM and
On Tue, Feb 15, 2011 at 02:14:55PM +0100, Per Forlin wrote:
outer_inv_range () is called twice for DMA_FROM_DEVICE.
The first time to get rid of potential writebacks and the second
time to get rid of any stale speculative prefetches
Correct.
outer_inv_range() is a rather expensive operation.
On Tue, Feb 15, 2011 at 02:54:21PM +0100, Per Forlin wrote:
I don't fully understand this yet. I think you are right but I need a
little help to get there myself.
I agree, the cache (L1 and L2) must be invalidated after the DMA has
completed.
Before starting the DMA the write buffers must be
On Tue, Feb 01, 2011 at 01:34:59PM +, Pawel Moll wrote:
And to prove the point, I have MMCI running at up to 4Mbps, an 8 fold
increase over what the current fixed upper-rate implementation does.
The adaptive rate implementation is just a proof of concept at the
moment and requires
On Mon, Jan 24, 2011 at 12:27:16PM -, Pawel Moll wrote:
So - we'll try to enlarge FIFO. For the moment - playing with interrupts
affinity seem to be a viable workaround.
I don't think enlarging the FIFO will help too much. The issue is
whether the CPU can keep up with the data rate coming
On Mon, Jan 24, 2011 at 04:13:14PM +, Pawel Moll wrote:
I don't think enlarging the FIFO will help too much. The issue is
whether the CPU can keep up with the data rate coming off the card.
If it can't, then no matter how large the FIFO is, it will
eventually overflow.
Yes, I
On Mon, Jan 24, 2011 at 04:24:00PM +, Russell King - ARM Linux wrote:
On Mon, Jan 24, 2011 at 04:13:14PM +, Pawel Moll wrote:
The real answer is to avoid PIO mode, and use DMA support.
However,
I've had problems using DMA on the ARM development boards. You can
Well, using
On Mon, Jan 24, 2011 at 04:39:21PM -, Pawel Moll wrote:
Well, fixing MMCI because ISP1761 is buggy is not the way forward.
The answer is to fix the broken ISP1761 driver.
Totally agree. The thing is that you are the only person right now who
doesn't have any problems.
That's not my
My final mail on this subject. I'm adding Philippe and Catalin so that
they're in the loop on this.
Take a mainline kernel. Apply the attached three patches. MMC will then
work without any problems. No hacks required. There is *absolutely* *no*
need to waste time with hardware modifications.
On Mon, Jan 24, 2011 at 07:59:03PM +, Pawel Moll wrote:
If you're flooding the system with USB traffic, enlargening the
FIFO size won't help. Making the FIFO larger just decreases the
_interrupt_ _latency_ requirements. It doesn't mean you can
cope with the amount of data being
On Fri, Jan 21, 2011 at 02:59:35PM -0500, Nicolas Pitre wrote:
On Fri, 21 Jan 2011, Pawel Moll wrote:
VE suffers from serious problem with MMC transfers - low performance,
errors when other IO peripherals (especially USB) are used at the
same time etc.
It all boils down to the MMC
On Tue, Dec 07, 2010 at 10:45:42AM +, Dave Martin wrote:
Yes-- though I didn't elaborate on it. You need a packager that can
understand, say, that a binary built for ARMv5 EABI can interoperate
with ARMv7 binaries etc.
Again, I've heard it suggested that RPM can handle this, but I haven't
On Tue, Dec 07, 2010 at 03:06:51PM +, Dave Martin wrote:
Hi,
On Tue, Dec 7, 2010 at 11:04 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Dec 07, 2010 at 10:45:42AM +, Dave Martin wrote:
Yes-- though I didn't elaborate on it. You need a packager that can
1 - 100 of 104 matches
Mail list logo
