* Re: [PATCH 0/4] powernv: kvm: numa fault improvement
From: Liu ping fan @ 2014-01-22 8:33 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, Paul Mackerras, Alexander Graf, kvm-ppc
In-Reply-To: <87zjmoiogp.fsf@linux.vnet.ibm.com>
On Wed, Jan 22, 2014 at 1:18 PM, Aneesh Kumar K.V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
>> On Mon, Jan 20, 2014 at 03:48:36PM +0100, Alexander Graf wrote:
>>>
>>> On 15.01.2014, at 07:36, Liu ping fan <kernelfans@gmail.com> wrote:
>>>
>>> > On Thu, Jan 9, 2014 at 8:08 PM, Alexander Graf <agraf@suse.de> wrote:
>>> >>
>>> >> On 11.12.2013, at 09:47, Liu Ping Fan <kernelfans@gmail.com> wrote:
>>> >>
>>> >>> This series is based on Aneesh's series "[PATCH -V2 0/5] powerpc: mm: Numa faults support for ppc64"
>>> >>>
>>> >>> For this series, I apply the same idea from the previous thread "[PATCH 0/3] optimize for powerpc _PAGE_NUMA"
>>> >>> (for which, I still try to get a machine to show nums)
>>> >>>
>>> >>> But for this series, I think that I have a good justification -- the fact of heavy cost when switching context between guest and host,
>>> >>> which is well known.
>>> >>
>>> >> This cover letter isn't really telling me anything. Please put a proper description of what you're trying to achieve, why you're trying to achieve what you're trying and convince your readers that it's a good idea to do it the way you do it.
>>> >>
>>> > Sorry for the unclear message. After introducing the _PAGE_NUMA,
>>> > kvmppc_do_h_enter() can not fill up the hpte for guest. Instead, it
>>> > should rely on host's kvmppc_book3s_hv_page_fault() to call
>>> > do_numa_page() to do the numa fault check. This incurs the overhead
>>> > when exiting from rmode to vmode. My idea is that in
>>> > kvmppc_do_h_enter(), we do a quick check, if the page is right placed,
>>> > there is no need to exit to vmode (i.e saving htab, slab switching)
>>> >
>>> >>> If my suppose is correct, will CCing kvm@vger.kernel.org from next version.
>>> >>
>>> >> This translates to me as "This is an RFC"?
>>> >>
>>> > Yes, I am not quite sure about it. I have no bare-metal to verify it.
>>> > So I hope at least, from the theory, it is correct.
>>>
>>> Paul, could you please give this some thought and maybe benchmark it?
>>
>> OK, once I get Aneesh to tell me how I get to have ptes with
>> _PAGE_NUMA set in the first place. :)
>>
>
> I guess we want patch 2, Which Liu has sent separately and I have
> reviewed. http://article.gmane.org/gmane.comp.emulators.kvm.powerpc.devel/8619
> I am not sure about the rest of the patches in the series.
> We definitely don't want to numa migrate on henter. We may want to do
> that on fault. But even there, IMHO, we should let the host take the
> fault and do the numa migration instead of doing this in guest context.
>
My patch does NOT do the numa migration in guest context( h_enter).
Instead it just do a pre-check to see whether the numa migration is
needed. If needed, the host will take the fault and do the numa
migration as it currently does. Otherwise, h_enter can directly setup
hpte without HPTE_V_ABSENT.
And since pte_mknuma() is called system-wide periodly, so it has more
possibility that guest will suffer from HPTE_V_ABSENT.(as my previous
reply, I think we should also place the quick check in
kvmppc_hpte_hv_fault )
Thx,
Fan
> -aneesh
>
^ permalink raw reply
* Re: [PATCH 0/8] Add support for PowerPC Hypervisor supplied performance counters
From: Anshuman Khandual @ 2014-01-22 9:37 UTC (permalink / raw)
To: Michael Ellerman
Cc: Peter Zijlstra, Linux PPC, LKML, Ingo Molnar, Paul Mackerras,
Arnaldo Carvalho de Melo, Cody P Schafer
In-Reply-To: <1390354379.11104.3.camel@concordia>
On 01/22/2014 07:02 AM, Michael Ellerman wrote:
> On Thu, 2014-01-16 at 15:53 -0800, Cody P Schafer wrote:
>> These patches add basic pmus for 2 powerpc hypervisor interfaces to obtain
>> performance counters: gpci ("get performance counter info") and 24x7.
>>
>> The counters supplied by these interfaces are continually counting and never
>> need to be (and cannot be) disabled or enabled. They additionally do not
>> generate any interrupts. This makes them in some regards similar to software
>> counters, and as a result their implimentation shares some common code (which
>> an initial patch exposes) with the sw counters.
>
> Hi Cody,
>
> Can you please add some more explanation of this series.
>
> In particular why do we need two new PMUs, and how do they relate to each
> other?
>
> And can you add an example of how I'd actually use them using perf.
>
Yeah, agreed.
^ permalink raw reply
* [Bug 67811] PASEMI: Kernel 3.13.0 doesn't boot with a PA6T cpu
From: Christian Zigotzky @ 2014-01-22 10:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <52D6E928.7050307@xenosoft.de>
[-- Attachment #1: Type: text/plain, Size: 5215 bytes --]
Hi All,
Thanks a lot for your effort to solve the boot problems. Unfortunately,
this patch doesn't work for the Nemo board. I need the patch created by
Olof Johansson.
diff -rupN linux-3.13/arch/powerpc/kernel/head_64.S
linux-3.13-nemo/arch/powerpc/kernel/head_64.S
--- linux-3.13/arch/powerpc/kernel/head_64.S 2014-01-05
00:12:14.000000000 +0100
+++ linux-3.13-nemo/arch/powerpc/kernel/head_64.S 2014-01-05
23:06:13.001618802 +0100
@@ -69,6 +69,13 @@ _GLOBAL(__start)
/* NOP this out unconditionally */
BEGIN_FTR_SECTION
FIXUP_ENDIAN
+/* Hack for PWRficient platforms: Due to CFE(?) bug, the 64-bit
+ * word at 0x8 needs to be set to 0. Patch it up here once we're
+ * done executing it (we can be lazy and avoid invalidating
+ * icache)
+ */
+li r0,0
+std 0,8(0)
b .__start_initialization_multiplatform
END_FTR_SECTION(0, 1)
Is it possible to integrate Olof's patch into the kernel sources?
All the best,
Christian
Am 15.01.14 21:01, schrieb Christian Zigotzky:
> author Linus Torvalds <torvalds@linux-foundation.org> 2014-01-13
> 03:59:05 (GMT)
> committer Linus Torvalds <torvalds@linux-foundation.org> 2014-01-13
> 03:59:05 (GMT)
> commit a6da83f98267bc8ee4e34aa899169991eb0ceb93
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a6da83f98267bc8ee4e34aa899169991eb0ceb93>
> (patch
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=a6da83f98267bc8ee4e34aa899169991eb0ceb93>)
>
> tree 84c228e0a87475dbdb0f72621c137cce8253131b
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/?id=a6da83f98267bc8ee4e34aa899169991eb0ceb93>
>
> parent 061f49ec2d722f485237870f04544d8bec15a778
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=061f49ec2d722f485237870f04544d8bec15a778>
> (diff
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/?id=a6da83f98267bc8ee4e34aa899169991eb0ceb93&id2=061f49ec2d722f485237870f04544d8bec15a778>)
>
> parent 10348f5976830e5d8f74e8abb04a9a057a5e8478
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=10348f5976830e5d8f74e8abb04a9a057a5e8478>
> (diff
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/?id=a6da83f98267bc8ee4e34aa899169991eb0ceb93&id2=10348f5976830e5d8f74e8abb04a9a057a5e8478>)
>
>
> Merge branch 'merge' of
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
> Pull powerpc fix from Ben Herrenschmidt: "Here's one regression fix
> for 3.13 that I would appreciate if you could still pull in. It was an
> "interesting" one to debug, basically it's an old bug that got
> somewhat "exposed" by new code breaking the boot on PA Semi boards
> (yes, it does appear that some people are still using these!)" *
> 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
> powerpc: Check return value of instance-to-package OF call
> Diffstat
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/?id=a6da83f98267bc8ee4e34aa899169991eb0ceb93>
> -rw-r--r-- arch/powerpc/kernel/prom_init.c
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/prom_init.c?id=a6da83f98267bc8ee4e34aa899169991eb0ceb93>
> 22
>
>
>
>
> 1 files changed, 13 insertions, 9 deletions
> diff --git a/arch/powerpc/kernel/prom_init.c
> b/arch/powerpc/kernel/prom_init.c
> index cb64a6e..078145a 100644
> --- a/arch/powerpc/kernel/prom_init.c
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/prom_init.c?id=061f49ec2d722f485237870f04544d8bec15a778>
> +++ b/arch/powerpc/kernel/prom_init.c
> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/prom_init.c?id=a6da83f98267bc8ee4e34aa899169991eb0ceb93>
> @@ -1986,19 +1986,23 @@ static void __init prom_init_stdout(void)
> /* Get the full OF pathname of the stdout device */
> memset(path, 0, 256);
> call_prom("instance-to-path", 3, 1, prom.stdout, path, 255);
> - stdout_node = call_prom("instance-to-package", 1, 1, prom.stdout);
> - val = cpu_to_be32(stdout_node);
> - prom_setprop(prom.chosen, "/chosen", "linux,stdout-package",
> - &val, sizeof(val));
> prom_printf("OF stdout device is: %s\n", of_stdout_device);
> prom_setprop(prom.chosen, "/chosen", "linux,stdout-path",
> path, strlen(path) + 1);
> - /* If it's a display, note it */
> - memset(type, 0, sizeof(type));
> - prom_getprop(stdout_node, "device_type", type, sizeof(type));
> - if (strcmp(type, "display") == 0)
> - prom_setprop(stdout_node, path, "linux,boot-display", NULL, 0);
> + /* instance-to-package fails on PA-Semi */
> + stdout_node = call_prom("instance-to-package", 1, 1, prom.stdout);
> + if (stdout_node != PROM_ERROR) {
> + val = cpu_to_be32(stdout_node);
> + prom_setprop(prom.chosen, "/chosen", "linux,stdout-package",
> + &val, sizeof(val));
> +
> + /* If it's a display, note it */
> + memset(type, 0, sizeof(type));
> + prom_getprop(stdout_node, "device_type", type, sizeof(type));
> + if (strcmp(type, "display") == 0)
> + prom_setprop(stdout_node, path, "linux,boot-display", NULL, 0);
> + }
> }
> static int __init prom_find_machine_type(void)
>
[-- Attachment #2: Type: text/html, Size: 10171 bytes --]
^ permalink raw reply
* Re: [PATCH 8/8] powerpc: Fix endian issues in crash dump code
From: Anton Blanchard @ 2014-01-22 10:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: paulus, linuxppc-dev, Ulrich.Weigand
In-Reply-To: <1387341927.20735.1.camel@concordia>
Hi Michael,
> Not my favourite colour :D What about this instead?
>
> We could also add of_property_read_u32(), with an implied index of
> zero?
>
> I don't like the rc handling, but couldn't come up with anything I
> liked better.
Thanks for pointing that out, I didn't realise we had so many
of_property_read_* helpers. I'll be sure to use them from here on :)
Anton
^ permalink raw reply
* Re: [PATCH V5 6/8] time/cpuidle: Support in tick broadcast framework in the absence of external clock device
From: Thomas Gleixner @ 2014-01-22 13:27 UTC (permalink / raw)
To: Preeti U Murthy
Cc: daniel.lezcano, peterz, fweisbec, paul.gortmaker, paulus, mingo,
mikey, shangw, rafael.j.wysocki, agraf, paulmck, arnd, linux-pm,
rostedt, michael, john.stultz, anton, chenhui.zhao, deepthi,
r58472, geoff, linux-kernel, srivatsa.bhat, schwidefsky,
linuxppc-dev
In-Reply-To: <20140115080947.20446.30305.stgit@preeti.in.ibm.com>
On Wed, 15 Jan 2014, Preeti U Murthy wrote:
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index 086ad60..d61404e 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -524,12 +524,13 @@ void clockevents_resume(void)
> #ifdef CONFIG_GENERIC_CLOCKEVENTS
> /**
> * clockevents_notify - notification about relevant events
> + * Returns non zero on error.
> */
> -void clockevents_notify(unsigned long reason, void *arg)
> +int clockevents_notify(unsigned long reason, void *arg)
> {
The interface change of clockevents_notify wants to be a separate
patch.
> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> index 9532690..1c23912 100644
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -20,6 +20,7 @@
> #include <linux/sched.h>
> #include <linux/smp.h>
> #include <linux/module.h>
> +#include <linux/slab.h>
>
> #include "tick-internal.h"
>
> @@ -35,6 +36,15 @@ static cpumask_var_t tmpmask;
> static DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
> static int tick_broadcast_force;
>
> +/*
> + * Helper variables for handling broadcast in the absence of a
> + * tick_broadcast_device.
> + * */
> +static struct hrtimer *bc_hrtimer;
> +static int bc_cpu = -1;
> +static ktime_t bc_next_wakeup;
Why do you need another variable to store the expiry time? The
broadcast code already knows it and the hrtimer expiry value gives you
the same information for free.
> +static int hrtimer_initialized = 0;
What's the point of this hrtimer_initialized dance? Why not simply
making the hrtimer static and avoid that all together. Also adding the
initialization into tick_broadcast_oneshot_available() is
braindamaged. Why not adding this to tick_broadcast_init() which is
the proper place to do?
Aside of that you are making this hrtimer mode unconditional, which
might break existing systems which are not aware of the hrtimer
implications.
What you really want is a pseudo clock event device which has the
proper functions for handling the timer and you can register it from
your architecture code. The broadcast core code needs a few tweaks to
avoid the shutdown of the cpu local clock event device, but aside of
that the whole thing just falls into place. So architectures can use
this if they want and are sure that their low level idle code knows
about the deep idle preventing return value of
clockevents_notify(). Once that works you can register the hrtimer
based broadcast device and a real hardware broadcast device with a
higher rating. It just works.
Find an incomplete and nonfunctional concept patch below. It should be
simple to make it work for real.
Thanks,
tglx
----
Index: linux-2.6/include/linux/clockchips.h
===================================================================
--- linux-2.6.orig/include/linux/clockchips.h
+++ linux-2.6/include/linux/clockchips.h
@@ -62,6 +62,11 @@ enum clock_event_mode {
#define CLOCK_EVT_FEAT_DYNIRQ 0x000020
#define CLOCK_EVT_FEAT_PERCPU 0x000040
+/*
+ * Clockevent device is based on a hrtimer for broadcast
+ */
+#define CLOCK_EVT_FEAT_HRTIMER 0x000080
+
/**
* struct clock_event_device - clock event device descriptor
* @event_handler: Assigned by the framework to be called by the low
@@ -83,6 +88,7 @@ enum clock_event_mode {
* @name: ptr to clock event name
* @rating: variable to rate clock event devices
* @irq: IRQ number (only for non CPU local devices)
+ * @bound_on: Bound on CPU
* @cpumask: cpumask to indicate for which CPUs this device works
* @list: list head for the management code
* @owner: module reference
@@ -113,6 +119,7 @@ struct clock_event_device {
const char *name;
int rating;
int irq;
+ int bound_on;
const struct cpumask *cpumask;
struct list_head list;
struct module *owner;
Index: linux-2.6/kernel/time/tick-broadcast-hrtimer.c
===================================================================
--- /dev/null
+++ linux-2.6/kernel/time/tick-broadcast-hrtimer.c
@@ -0,0 +1,77 @@
+
+static struct hrtimer bctimer;
+
+static void bc_set_mode(enum clock_event_mode mode,
+ struct clock_event_device *bc)
+{
+ switch (mode) {
+ case CLOCK_EVT_MODE_SHUTDOWN:
+ /*
+ * Note, we cannot cancel the timer here as we might
+ * run into the following live lock scenario:
+ *
+ * cpu 0 cpu1
+ * lock(broadcast_lock);
+ * hrtimer_interrupt()
+ * bc_handler()
+ * tick_handle_oneshot_broadcast();
+ * lock(broadcast_lock);
+ * hrtimer_cancel()
+ * wait_for_callback()
+ */
+ hrtimer_try_to_cancel(&bctimer);
+ break;
+ default:
+ break;
+ }
+}
+
+/*
+ * This is called from the guts of the broadcast code when the cpu
+ * which is about to enter idle has the earliest broadcast timer event.
+ */
+static int bc_set_next(ktime_t expires, struct clock_event_device *bc)
+{
+ /*
+ * We try to cancel the timer first. If the callback is on
+ * flight on some other cpu then we let it handle it. If we
+ * were able to cancel the timer nothing can rearm it as we
+ * own broadcast_lock.
+ */
+ if (hrtimer_try_to_cancel(&bctimer) >= 0) {
+ hrtimer_start(&bctimer, expires, HRTIMER_MODE_ABS_PINNED);
+ /* Bind the "device" to the cpu */
+ bc->bound_on = smp_processor_id();
+ }
+ return 0;
+}
+
+static struct clock_event_device ce_broadcast_hrtimer = {
+ .set_mode = bc_set_mode,
+ .set_next_ktime = bc_set_next,
+ .features = CLOCK_EVT_FEAT_ONESHOT |
+ CLOCK_EVT_FEAT_KTIME |
+ CLOCK_EVT_FEAT_HRTIMER,
+ .rating = 0,
+ .bound_on = -1,
+ .min_delta_ns = 1,
+ .max_delta_ns = KTIME_MAX,
+ .min_delta_ticks = 1,
+ .max_delta_ticks = KTIME_MAX,
+ .mult = 1,
+ .shift = 0,
+ .cpumask = cpu_all_mask,
+};
+
+static enum hrtimer_restart bc_handler(struct hrtimer *t)
+{
+ ce_broadcast_hrtimer.event_handler(&ce_broadcast_hrtimer);
+ return HRTIMER_NORESTART;
+}
+
+void tick_setup_hrtimer_broadcast(void)
+{
+ hrtimer_init(&bctimer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ bctimer.function = bc_handler;
+ clockevents_register(&ce_broadcast_hrtimer);
+}
Index: linux-2.6/kernel/time/tick-broadcast.c
===================================================================
--- linux-2.6.orig/kernel/time/tick-broadcast.c
+++ linux-2.6/kernel/time/tick-broadcast.c
@@ -630,6 +630,42 @@ again:
raw_spin_unlock(&tick_broadcast_lock);
}
+static int broadcast_needs_cpu(struct clock_event_device *bc, int cpu)
+{
+ if (!(bc->features & CLOCK_EVT_FEAT_HRTIMER))
+ return 0;
+ if (bc->next_event.tv64 == KTIME_MAX)
+ return 0;
+ return bc->bound_on == cpu ? -EBUSY : 0;
+}
+
+static void broadcast_shutdown_local(struct clock_event_device *bc,
+ struct clock_event_device *dev)
+{
+ /*
+ * For hrtimer based broadcasting we cannot shutdown the cpu
+ * local device if our own event is the first one to expire or
+ * if we own the broadcast timer.
+ */
+ if (bc->features & CLOCK_EVT_FEAT_HRTIMER) {
+ if (broadcast_needs_cpu(bc))
+ return;
+ if (dev->next_event.tv64 < bc->next_event.tv64)
+ return;
+ }
+ clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
+}
+
+static void broadcast_move_bc(int deadcpu)
+{
+ struct clock_event_device *bc = tick_broadcast_device.evtdev;
+
+ if (!bc || !broadcast_needs_cpu(bc, deadcpu))
+ return;
+ /* This moves the broadcast assignment to this cpu */
+ clockevents_program_event(bc, bc->next_event, 1);
+}
+
/*
* Powerstate information: The system enters/leaves a state, where
* affected devices might stop
@@ -639,8 +675,8 @@ void tick_broadcast_oneshot_control(unsi
struct clock_event_device *bc, *dev;
struct tick_device *td;
unsigned long flags;
+ int cpu, ret = 0;
ktime_t now;
- int cpu;
/*
* Periodic mode does not care about the enter/exit of power
@@ -666,7 +702,7 @@ void tick_broadcast_oneshot_control(unsi
if (reason == CLOCK_EVT_NOTIFY_BROADCAST_ENTER) {
if (!cpumask_test_and_set_cpu(cpu, tick_broadcast_oneshot_mask)) {
WARN_ON_ONCE(cpumask_test_cpu(cpu, tick_broadcast_pending_mask));
- clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
+ broadcast_shutdown_local(bc, dev);
/*
* We only reprogram the broadcast timer if we
* did not mark ourself in the force mask and
@@ -679,6 +715,11 @@ void tick_broadcast_oneshot_control(unsi
dev->next_event.tv64 < bc->next_event.tv64)
tick_broadcast_set_event(bc, cpu, dev->next_event, 1);
}
+ /*
+ * If the current CPU owns the hrtimer broadcast
+ * mechanism, it cannot go deep idle.
+ */
+ ret = broadcast_needs_cpu(bc, cpu);
} else {
if (cpumask_test_and_clear_cpu(cpu, tick_broadcast_oneshot_mask)) {
clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT);
@@ -851,6 +892,8 @@ void tick_shutdown_broadcast_oneshot(uns
cpumask_clear_cpu(cpu, tick_broadcast_pending_mask);
cpumask_clear_cpu(cpu, tick_broadcast_force_mask);
+ broadcast_move_bc(cpu);
+
raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
}
^ permalink raw reply
* Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
From: Valentin Longchamp @ 2014-01-22 16:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1390323689.24905.484.camel@snotra.buserror.net>
On 01/21/2014 06:01 PM, Scott Wood wrote:
> On Tue, 2014-01-21 at 17:34 +0100, Valentin Longchamp wrote:
>> On 01/20/2014 11:37 PM, Scott Wood wrote:
>>> On Mon, 2014-01-20 at 17:38 +0100, Valentin Longchamp wrote:
>>>> On 01/17/2014 10:48 PM, Scott Wood wrote:
>>>>> Why isn't the compatible "keymile,kmcoge4", like the model?
>>>>
>>>> Because kmcoge4 is the board that is based on the kmp204x architecture/design.
>>>> We expect other boards (kmcoge7 for instance) based on the same kmp204x design.
>>>
>>> The top-level compatible isn't for the "architecture" or the "design".
>>> It's for the board. Surely there's something different about kmcoge7
>>> versus kmcoge4 -- is it visible to software?
>>
>> There should only be a few differences in the dts between the two boards.
>>
>> Reading the ePAPR my understanding was that compatible is the "programming
>> model" and that's what I have named above design/architecture while model is the
>> exact model of the device in this case the exact board name.
>
> In practice, model is more for human consumption (e.g. there may be many
> variants that all look identical to software). The "programming model"
> for an entire board includes everything on it.
>
>>>> You would prefer that I have the model and compatible stricly the same and add
>>>> any future board into the compatible boards[] from corenet_generic ?
>>>
>>> That's how it's usually done. Or, at least provide the board
>>> architecture name as a secondary compatible after the board name.
>>>
>>>> If possible I would like to be able to see the boards that are based on a
>>>> similar design, that's what I wanted to achieve with this kmp204x name.
>>>
>>> Is "kmp204x" an official name of the architecture, rather than a
>>> generalization of "kmp2040" and "kmp2041"? If there were a p2042, and
>>> you made a board for it, is there any chance it would be called kmp204x
>>> even if it were very different from the p2040/p2041 board?
>>
>> It's the name we have picked up, but it's not official. We also use km83xx,
>> km82xx and it was derived from that.
>>
>> If the hypothetical p2042 board was different it would then have another name.
>
> In that case, I don't object to it being listed in compatible, though
> the specific board name should come first.
OK then to sum up both points we would have:
model = "keymile,kmcoge4";
compatible = "keymile,kmcoge4", "keymile,kmp204x";
And I would add "keymile,kmcoge4" into the boards[] table.
>
>>>>> The device tree describes the hardware, not what driver you want to use.
>>>>>
>>>>> Plus, I don't see any driver that matches "gen,spidev" nor any binding
>>>>> for it, and "gen" doesn't make sense as a vendor prefix. The only
>>>>> instance of that string I can find in the Linux tree is in mgcoge.dts.
>>>>
>>>> Well it comes from mgcoge and that's why I have used this
>>>>
>>>> It's for usage with the spidev driver (driver/spi/spidev.c). I agree that the
>>>> gen brings nothing. Would
>>>>
>>>> spidev@1 {
>>>> compatible = "spidev";
>>>>
>>>> make more sense ?
>>>
>>> It doesn't address any of the other comments.
>>
>> Can you please explicitly tell me how I should build this node ? What other
>> comments ? Must I be more generic with the name ?
>>
>> Something like :
>>
>> spi@1 {
>> compatible = "zarlink,30343", "spidev";
>
> Remove "spidev". Any nodes under the SPI controller node will be SPI
> devices, right? So it doesn't add anything regarding hardware
> description.
>
OK.
Thank you for the feedback, I will then send a revised patch as soon as I have time.
Valentin
^ permalink raw reply
* [PATCH v2 1/3] powerpc/pseries: Device tree should only be updated once after suspend/migrate
From: Tyrel Datwyler @ 2014-01-22 19:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nfont, Tyrel Datwyler
In-Reply-To: <1390420717-23907-1-git-send-email-tyreld@linux.vnet.ibm.com>
From: Haren Myneni <hbabu@us.ibm.com>
From: Haren Myneni <hbabu@us.ibm.com>
The current code makes rtas calls for update-nodes, activate-firmware and then
update-nodes again. The FW provides the same data for both update-nodes calls.
As a result a proc entry exists error is reported for the second update while
adding device nodes.
This patch makes a single rtas call for update-nodes after activating the FW.
It also add rtas_busy delay for the activate-firmware rtas call.
Signed-off-by: Haren Myneni <hbabu@us.ibm.com>
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/mobility.c | 26 ++++++++++----------------
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index cde4e0a..bde7eba 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -290,13 +290,6 @@ void post_mobility_fixup(void)
int rc;
int activate_fw_token;
- rc = pseries_devicetree_update(MIGRATION_SCOPE);
- if (rc) {
- printk(KERN_ERR "Initial post-mobility device tree update "
- "failed: %d\n", rc);
- return;
- }
-
activate_fw_token = rtas_token("ibm,activate-firmware");
if (activate_fw_token == RTAS_UNKNOWN_SERVICE) {
printk(KERN_ERR "Could not make post-mobility "
@@ -304,16 +297,17 @@ void post_mobility_fixup(void)
return;
}
- rc = rtas_call(activate_fw_token, 0, 1, NULL);
- if (!rc) {
- rc = pseries_devicetree_update(MIGRATION_SCOPE);
- if (rc)
- printk(KERN_ERR "Secondary post-mobility device tree "
- "update failed: %d\n", rc);
- } else {
+ do {
+ rc = rtas_call(activate_fw_token, 0, 1, NULL);
+ } while (rtas_busy_delay(rc));
+
+ if (rc)
printk(KERN_ERR "Post-mobility activate-fw failed: %d\n", rc);
- return;
- }
+
+ rc = pseries_devicetree_update(MIGRATION_SCOPE);
+ if (rc)
+ printk(KERN_ERR "Post-mobility device tree update "
+ "failed: %d\n", rc);
return;
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 0/3] powerpc/pseries: fix issues in suspend/resume code
From: Tyrel Datwyler @ 2014-01-22 19:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nfont, Tyrel Datwyler
This patchset fixes a couple of issues encountered in the suspend/resume code
base. First when using the kernel device tree update code update-nodes is
unnecessarily called more than once. Second the cpu cache lists are not
updated after a suspend/resume which under certain conditions may cause a
panic. Finally, since the cache list fix utilzes in kernel device tree update
code a means for telling drmgr not to perform a device tree update from
userspace is required.
Changes from v1:
- Fixed several commit message typos
- Fixed authorship of first two patches
Haren Myneni (2):
powerpc/pseries: Device tree should only be updated once after
suspend/migrate
powerpc/pseries: Update dynamic cache nodes for suspend/resume
operation
Tyrel Datwyler (1):
powerpc/pseries: Report in kernel device tree update to drmgr
arch/powerpc/include/asm/rtas.h | 4 ++++
arch/powerpc/kernel/rtas.c | 17 +++++++++++++++++
arch/powerpc/kernel/time.c | 6 ++++++
arch/powerpc/platforms/pseries/mobility.c | 26 ++++++++++----------------
arch/powerpc/platforms/pseries/suspend.c | 25 ++++++++++++++++++++++++-
5 files changed, 61 insertions(+), 17 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH v2 2/3] powerpc/pseries: Update dynamic cache nodes for suspend/resume operation
From: Tyrel Datwyler @ 2014-01-22 19:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nfont, Tyrel Datwyler
In-Reply-To: <1390420717-23907-1-git-send-email-tyreld@linux.vnet.ibm.com>
From: Haren Myneni <hbabu@us.ibm.com>
From: Haren Myneni <hbabu@us.ibm.com>
pHyp can change cache nodes for suspend/resume operation. The current code
updates the device tree after all non boot CPUs are enabled. Hence, we do not
modify the cache list based on the latest cache nodes. Also we do not remove
cache entries for the primary CPU.
This patch removes the cache list for the boot CPU, updates the device tree
before enabling nonboot CPUs and adds cache list for the boot cpu.
Signed-off-by: Haren Myneni <hbabu@us.ibm.com>
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/rtas.h | 4 ++++
arch/powerpc/kernel/rtas.c | 17 +++++++++++++++++
arch/powerpc/kernel/time.c | 6 ++++++
3 files changed, 27 insertions(+)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 9bd52c6..da9d733 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -283,6 +283,10 @@ extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
#ifdef CONFIG_PPC_PSERIES
extern int pseries_devicetree_update(s32 scope);
+extern void post_mobility_fixup(void);
+extern void update_dynamic_configuration(void);
+#else /* !CONFIG_PPC_PSERIES */
+void update_dynamic_configuration(void) { }
#endif
#ifdef CONFIG_PPC_RTAS_DAEMON
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 4cf674d..8249eb2 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -43,6 +43,7 @@
#include <asm/time.h>
#include <asm/mmu.h>
#include <asm/topology.h>
+#include "cacheinfo.h"
struct rtas_t rtas = {
.lock = __ARCH_SPIN_LOCK_UNLOCKED
@@ -972,6 +973,22 @@ out:
free_cpumask_var(offline_mask);
return atomic_read(&data.error);
}
+
+/*
+ * The device tree cache nodes can be modified during suspend/ resume.
+ * So delete all cache entries and recreate them again after the device tree
+ * update.
+ * We already deleted cache entries for notboot CPUs before suspend. So delete
+ * entries for the primary CPU, recreate entries after the device tree update.
+ * We can create entries for nonboot CPU when enable them later.
+ */
+
+void update_dynamic_configuration(void)
+{
+ cacheinfo_cpu_offline(smp_processor_id());
+ post_mobility_fixup();
+ cacheinfo_cpu_online(smp_processor_id());
+}
#else /* CONFIG_PPC_PSERIES */
int rtas_ibm_suspend_me(struct rtas_args *args)
{
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b3b1441..5f1ca28 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -69,6 +69,7 @@
#include <asm/vdso_datapage.h>
#include <asm/firmware.h>
#include <asm/cputime.h>
+#include <asm/rtas.h>
/* powerpc clocksource/clockevent code */
@@ -592,6 +593,11 @@ void arch_suspend_enable_irqs(void)
generic_suspend_enable_irqs();
if (ppc_md.suspend_enable_irqs)
ppc_md.suspend_enable_irqs();
+ /*
+ * Update configuration which can be modified based on devicetree
+ * changes during resume.
+ */
+ update_dynamic_configuration();
}
#endif
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 3/3] powerpc/pseries: Report in kernel device tree update to drmgr
From: Tyrel Datwyler @ 2014-01-22 19:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nfont, Tyrel Datwyler
In-Reply-To: <1390420717-23907-1-git-send-email-tyreld@linux.vnet.ibm.com>
Traditionally it has been drmgr's responsibilty to update the device tree
through the /proc/ppc64/ofdt interface after a suspend/resume operation.
This patchset however has modified suspend/resume ops to preform that update
entirely in the kernel during the resume. Therefore, a mechanism is required
for drmgr to determine who is responsible for the update. This patch adds a
show function to the "hibernate" attribute that returns 1 if the kernel
updates the device tree after the resume and 0 if drmgr is responsible.
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/suspend.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/suspend.c b/arch/powerpc/platforms/pseries/suspend.c
index 16a2552..723115d 100644
--- a/arch/powerpc/platforms/pseries/suspend.c
+++ b/arch/powerpc/platforms/pseries/suspend.c
@@ -174,7 +174,30 @@ out:
return rc;
}
-static DEVICE_ATTR(hibernate, S_IWUSR, NULL, store_hibernate);
+#define USER_DT_UPDATE 0
+#define KERN_DT_UPDATE 1
+
+/**
+ * show_hibernate - Report device tree update responsibilty
+ * @dev: subsys root device
+ * @attr: device attribute struct
+ * @buf: buffer
+ *
+ * Report whether a device tree update is performed by the kernel after a
+ * resume, or if drmgr must coordinate the update from user space.
+ *
+ * Return value:
+ * 0 if drmgr is to initiate update, and 1 otherwise
+ **/
+static ssize_t show_hibernate(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", KERN_DT_UPDATE);
+}
+
+static DEVICE_ATTR(hibernate, S_IWUSR | S_IRUGO,
+ show_hibernate, store_hibernate);
static struct bus_type suspend_subsys = {
.name = "power",
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
From: Scott Wood @ 2014-01-22 20:33 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <52DFF413.7060806@keymile.com>
On Wed, 2014-01-22 at 17:38 +0100, Valentin Longchamp wrote:
> On 01/21/2014 06:01 PM, Scott Wood wrote:
> > On Tue, 2014-01-21 at 17:34 +0100, Valentin Longchamp wrote:
> >> Can you please explicitly tell me how I should build this node ? What other
> >> comments ? Must I be more generic with the name ?
> >>
> >> Something like :
> >>
> >> spi@1 {
> >> compatible = "zarlink,30343", "spidev";
> >
> > Remove "spidev". Any nodes under the SPI controller node will be SPI
> > devices, right? So it doesn't add anything regarding hardware
> > description.
> >
>
> OK.
>
> Thank you for the feedback, I will then send a revised patch as soon as I have time.
Oh, and ideally the node name should describe the function of the device
-- "spi" as a node name usually means a SPI controller.
Maybe "ptp_clock@1"?
Also, zarlink should be added to
Documentation/devicetree/bindings/vendor-prefixes.txt
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/fsl: Use the new interface to save or restore registers
From: Scott Wood @ 2014-01-22 20:34 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: anton@enomsg.org, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <18d3109ac114477a805618829632b463@BN1PR03MB188.namprd03.prod.outlook.com>
On Sun, 2014-01-19 at 23:57 -0600, Wang Dongsheng-B40534 wrote:
> > > > > Use fsl_cpu_state_save/fsl_cpu_state_restore to save/restore registers.
> > > > > Use the functions to save/restore registers, so we don't need to
> > > > > maintain the code.
> > > > >
> > > > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > >
> > > > Is there any functional change with this patchset (e.g. suspend
> > > > supported on chips where it wasn't before), or is it just cleanup? A
> > > > cover letter would be useful to describe the purpose of the overall
> > > > patchset when it isn't obvious.
> > > >
> > >
> > > Yes, just cleanup..
> >
> > It seems to be introducing complexity rather than removing it. Is this
> > cleanup needed to prepare for adding new functionality?
> >
> > Plus, I'm skeptical that this is functionally equivalent. It looks like
> > the new code saves a lot more than the old code does. Why?
> >
>
> Actually, I want to take a practical example to push the save/restore patches.
> And this is also reasonable for 32bit-hibernation, the code is more clean. :)
> I think I need to change the description of the patch.
>
> > > > > +
> > > > > + /* Restore base register */
> > > > > + li r4, 0
> > > > > + bl fsl_cpu_state_restore
> > > >
> > > > Why are you calling anything with "fsl" in the name from code that is
> > > > supposed to be for all booke?
> > > >
> > > E200, E300 not support.
> > > Support E500, E500v2, E500MC, E5500, E6500.
> > >
> > > Do you have any suggestions about this?
> >
> > What about non-FSL booke such as 44x?
> >
> > Or if this file never supported 44x, rename it appropriately.
> >
> Currently does not support. ok change the name first, if later support, and
> then again to modify the name of this function.
>
> How about 85xx_cpu_state_restore?
Symbols can't begin with numbers. booke_cpu_state_restore would be
better (it would still provide a place for 44x to be added if somebody
actually cared about doing so).
I'm still not convinced that asm code is the place to do this, though.
-Scott
^ permalink raw reply
* RE: [02/12,v3] pci: fsl: add structure fsl_pci
From: Roy Zang @ 2014-01-22 23:38 UTC (permalink / raw)
To: Scott Wood, Minghuan.Lian@freescale.com
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140103221923.GB22546@home.buserror.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, January 03, 2014 4:19 PM
> To: Lian Minghuan-B31939
> Cc: linuxppc-dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Zang Roy-
> R61911; Bjorn Helgaas
> Subject: Re: [02/12,v3] pci: fsl: add structure fsl_pci
>=20
> On Wed, Oct 23, 2013 at 06:41:24PM +0800, Minghuan Lian wrote:
> > PowerPC uses structure pci_controller to describe PCI controller, but
> > ARM uses structure pci_sys_data. In order to support PowerPC and ARM
> > simultaneously, the patch adds a structure fsl_pci that contains most
> > of the members of the pci_controller and pci_sys_data.
> > Meanwhile, it defines a interface fsl_arch_sys_to_pci() which should
> > be implemented in architecture-specific PCI controller driver to
> > convert pci_controller or pci_sys_data to fsl_pci.
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> >
> > ---
> > change log:
> > v1-v3:
> > Derived from http://patchwork.ozlabs.org/patch/278965/
> >
> > Based on upstream master.
> > Based on the discussion of RFC version here
> > http://patchwork.ozlabs.org/patch/274487/
> >
> > include/linux/fsl/pci-common.h | 41
> > +++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/include/linux/fsl/pci-common.h
> > b/include/linux/fsl/pci-common.h index 5e4f683..e56a040 100644
> > --- a/include/linux/fsl/pci-common.h
> > +++ b/include/linux/fsl/pci-common.h
> > @@ -102,5 +102,46 @@ struct ccsr_pci {
> >
> > };
> >
> > +/*
> > + * Structure of a PCI controller (host bridge) */ struct fsl_pci {
> > + struct list_head node;
> > + bool is_pcie;
> > + struct device_node *dn;
> > + struct device *dev;
> > +
> > + int first_busno;
> > + int last_busno;
> > + int self_busno;
> > + struct resource busn;
> > +
> > + struct pci_ops *ops;
> > + struct ccsr_pci __iomem *regs;
> > +
> > + u32 indirect_type;
> > +
> > + struct resource io_resource;
> > + resource_size_t io_base_phys;
> > + resource_size_t pci_io_size;
> > +
> > + struct resource mem_resources[3];
> > + resource_size_t mem_offset[3];
> > +
> > + int global_number; /* PCI domain number */
> > +
> > + resource_size_t dma_window_base_cur;
> > + resource_size_t dma_window_size;
> > +
> > + void *sys;
> > +};
>=20
> I don't like the extent to which this duplicates (not moves) PPC's struct
> pci_controller. Also this leaves some fields like "indirect_type"
> unexplained (PPC_INDIRECT_TYPE_xxx is only in the PPC header).
INDIRECT type is for configuration space access, I do not think it is ppc h=
eader specific.
It is good to put it to freescale pci common code.
Roy
^ permalink raw reply
* Re: [PATCH 0/8] Add support for PowerPC Hypervisor supplied performance counters
From: Cody P Schafer @ 2014-01-23 0:11 UTC (permalink / raw)
To: Michael Ellerman
Cc: Peter Zijlstra, LKML, Ingo Molnar, Paul Mackerras,
Arnaldo Carvalho de Melo, Linux PPC
In-Reply-To: <1390354379.11104.3.camel@concordia>
On 01/21/2014 05:32 PM, Michael Ellerman wrote:
> On Thu, 2014-01-16 at 15:53 -0800, Cody P Schafer wrote:
>> These patches add basic pmus for 2 powerpc hypervisor interfaces to obtain
>> performance counters: gpci ("get performance counter info") and 24x7.
>>
>> The counters supplied by these interfaces are continually counting and never
>> need to be (and cannot be) disabled or enabled. They additionally do not
>> generate any interrupts. This makes them in some regards similar to software
>> counters, and as a result their implimentation shares some common code (which
>> an initial patch exposes) with the sw counters.
>
> Hi Cody,
>
> Can you please add some more explanation of this series.
Sure
> In particular why do we need two new PMUs, and how do they relate to each
> other?
These 2 PMUs end up providing access to some cpu, core, and chip level counters not
exposed via other interfaces, and additionally allow monitoring the performance of
other lpars (guests) on the same host system. Because it provides access to core and
chip level counters, this pair of PMUs could be thought of as powerpc's counterpart
to x86's uncore events.
As an example, "processor_bus_utilization_abc" and "processor_bus_utilization_wxyz"
(in hv_gpci.h) allow retreval of total cycles and idle cycles for various inter-chip buses.
GPCI is an interface that already exists on some power7 machines (depending on the fw
version), but is rather in-flexible and code intensive to add additional counters to.
The 24x7 interfaces currently are designed to co-exist with the gpci interface while
replacing most of gpci's functionality on newer systems. Right now, the 24x7 code I've
submitted uses the gpci calls to check if it has permission to access certain classes
of counters.
> And can you add an example of how I'd actually use them using perf.
# For gpci (formed from reading hv_gpci.h), gets "processor_time_in_timebase_cycles"
perf stat -e 'hv_gpci/counter_info_version=3,offset=0,length=8,secondary_index=0,starting_index=0xffffffff,request=0x10/' -r 0 -a -x ' ' sleep 0.1
# For 24x7, assuming access to hw+fw that supports it, gets a yet-to-be identified counter:
perf stat -e 'hv_24x7/domain=2,offset=8,starting_index=0,lpar=0xffffffff/' -r 0 -C 0 -x ' ' sleep 0.1
^ permalink raw reply
* Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
From: Paul Gortmaker @ 2014-01-23 0:38 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-arch, linux-mips, linux-m68k, rusty, linux-ia64, kvm,
linux-s390, netdev, x86, linux-kernel, torvalds, gregkh,
linux-alpha, sparclinux, akpm, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20140122180023.dd90d34cba38d9f9ac516349@canb.auug.org.au>
[Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include=
<linux/init.h>] On 22/01/2014 (Wed 18:00) Stephen Rothwell wrote:
> Hi Paul,
>=20
> On Tue, 21 Jan 2014 16:22:03 -0500 Paul Gortmaker <paul.gortmaker@windriv=
er.com> wrote:
> >
> > Where: This work exists as a queue of patches that I apply to
> > linux-next; since the changes are fixing some things that currently
> > can only be found there. The patch series can be found at:
> >=20
> > http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
> >=20
> > I've avoided annoying Stephen with another queue of patches for
> > linux-next while the development content was in flux, but now that
> > the merge window has opened, and new additions are fewer, perhaps he
> > wouldn't mind tacking it on the end... Stephen?
>=20
> OK, I have added this to the end of linux-next today - we will see how we
> go. It is called "init".
Thanks, it was a great help as it uncovered a few issues in fringe arch
that I didn't have toolchains for, and I've fixed all of those up.
I've noticed that powerpc has been un-buildable for a while now; I have
used this hack patch locally so I could run the ppc defconfigs to check
that I didn't break anything. Maybe useful for linux-next in the
interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Paul.
--
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/includ=
e/asm/pgtable-ppc64.h
index d27960c89a71..d0f070a2b395 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma,=
unsigned long address,
pmd_t *pmdp);
=20
#define pmd_move_must_withdraw pmd_move_must_withdraw
-typedef struct spinlock spinlock_t;
-static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
- spinlock_t *old_pmd_ptl)
+struct spinlock;
+static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
+ struct spinlock *old_pmd_ptl)
{
/*
* Archs like ppc64 use pgtable to store per pmd
^ permalink raw reply related
* Re: [PATCH] clk: corenet: Update the clock bindings
From: Scott Wood @ 2014-01-23 0:44 UTC (permalink / raw)
To: Tang Yuantian; +Cc: b07421, b32579, linuxppc-dev, devicetree
In-Reply-To: <1390269732-22798-1-git-send-email-Yuantian.Tang@freescale.com>
On Tue, 2014-01-21 at 10:02 +0800, Tang Yuantian wrote:
> From: Tang Yuantian <yuantian.tang@freescale.com>
>
> Main changs include:
> - Clarified the clock nodes' version number
> - Fixed a issue in example
>
> Singed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> ---
> Documentation/devicetree/bindings/clock/corenet-clock.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/corenet-clock.txt
> index 24711af..d6cadef 100644
> --- a/Documentation/devicetree/bindings/clock/corenet-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
> @@ -54,6 +54,8 @@ Required properties:
> It takes parent's clock-frequency as its clock.
> * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
> It takes parent's clock-frequency as its clock.
> + Note: v1.0 and v2.0 are clock version which should align to
> + clockgen node's they belong to which is chassis version.
Instead, how about a note like this near the top of the file:
All references to "1.0" and "2.0" refer to the QorIQ chassis version to
which the chip complies.
Chassis Version Example Chips
--------------- -------------
1.0 p4080, p5020, p5040
2.0 t4240, b4860, t1040
BTW, this binding and the associated driver really should be called
"qoriq-clock", not "corenet-clock". This would match the compatible
string, and it doesn't really have much to do with corenet (which is
part of the QorIQ chassis v1 and v2, but not *this* part). Do you know
if the chassis v3 clock interface will be similar enough to share a
driver?
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/85xx: Provide two functions to save/restore the core registers
From: Scott Wood @ 2014-01-23 0:50 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: anton@enomsg.org, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <7db8f36932f84bc5bdcb8a7777c55383@BN1PR03MB188.namprd03.prod.outlook.com>
On Mon, 2014-01-20 at 20:43 -0600, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, January 21, 2014 9:06 AM
> > To: Wang Dongsheng-B40534
> > Cc: benh@kernel.crashing.org; Zhao Chenhui-B35336; anton@enomsg.org; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH 2/3] powerpc/85xx: Provide two functions to save/restore the
> > core registers
> >
> > On Mon, 2014-01-20 at 00:03 -0600, Wang Dongsheng-B40534 wrote:
> > > > > > > + /*
> > > > > > > + * Need to save float-point registers if MSR[FP] = 1.
> > > > > > > + */
> > > > > > > + mfmsr r12
> > > > > > > + andi. r12, r12, MSR_FP
> > > > > > > + beq 1f
> > > > > > > + do_sr_fpr_regs(save)
> > > > > >
> > > > > > C code should have already ensured that MSR[FP] is not 1 (and thus the
> > FP
> > > > > > context has been saved).
> > > > > >
> > > > >
> > > > > Yes, right. But I mean if the FP still use in core save flow, we need to
> > save
> > > > it.
> > > > > In this process, i don't care what other code do, we need to focus on not
> > > > losing
> > > > > valuable data.
> > > >
> > > > It is not allowed to use FP at that point.
> > > >
> > > If MSR[FP] not active, that is FP not allowed to use.
> > > But here is a normal judgment, if MSR[FP] is active, this means that the
> > floating
> > > point module is being used. I offer is a function of the interface, we don't
> > know
> > > where is the function will be called. Just because we call this function in
> > the
> > > context of uncertainty, we need this judgment to ensure that no data is lost.
> >
> > The whole point of calling enable_kernel_fp() in C code before
> > suspending is to ensure that the FP state gets saved. If FP is used
> > after that point it is a bug. If you're worried about such bugs, then
> > clear MSR[FP] after calling enable_kernel_fp(), rather than adding
> > redundant state saving.
> >
>
> enable_kernel_fp() calling in MEM suspend flow.
> Hibernation is different with MEM suspend, and I'm not sure where will call this
> interface, so we need to ensure the integrity of the core saving. I don't think
> this code is *redundant*. I trust that the kernel can keep the FP related
> operations, that's why a judgment is here. :)
For hibernation, save_processor_state() is called first, which does
flush_fp_to_thread() which has a similar effect (though I wonder if it's
being called on the correct task for non-SMP).
-Scott
^ permalink raw reply
* Re: [PATCH] mtd: m25p80: Make the name of mtd_info fixed
From: Brian Norris @ 2014-01-23 2:12 UTC (permalink / raw)
To: Hou Zhiqiang
Cc: scottwood, linuxppc-dev, mingkai.hu, linux-mtd, Ezequiel Garcia
In-Reply-To: <1388990069-27066-1-git-send-email-b48286@freescale.com>
Hi Hou,
On Mon, Jan 06, 2014 at 02:34:29PM +0800, Hou Zhiqiang wrote:
> To give spi flash layout using "mtdparts=..." in cmdline, we must
> give mtd_info a fixed name,because the cmdlinepart's parser will
> match the name given in cmdline with the mtd_info.
>
> Now, if use OF node, mtd_info's name will be spi->dev->name. It
> consists of spi_master->bus_num, and the spi_master->bus_num maybe
> dynamically fetched.
> So, give the mtd_info a new fiexd name "name.cs", "name" is name of
> spi_device_id and "cs" is chip-select in spi_dev.
>
> Signed-off-by: Hou Zhiqiang <b48286@freescale.com>
> ---
> drivers/mtd/devices/m25p80.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index eb558e8..d1ed480 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -1012,7 +1012,8 @@ static int m25p_probe(struct spi_device *spi)
> if (data && data->name)
> flash->mtd.name = data->name;
> else
> - flash->mtd.name = dev_name(&spi->dev);
> + flash->mtd.name = kasprintf(GFP_KERNEL, "%s.%d",
> + id->name, spi->chip_select);
Changing the mtd.name may have far-reaching consequences for users who
already have mtdparts= command lines. But your concern is probably valid
for dynamically-determined bus numbers. Perhaps you can edit this patch
to only change the name when the busnum is dynamically-allocated?
This also needs a NULL check (for OOM), and you leak memory on device
removal.
>
> flash->mtd.type = MTD_NORFLASH;
> flash->mtd.writesize = 1;
Brian
^ permalink raw reply
* RE: [PATCH] clk: corenet: Update the clock bindings
From: Yuantian Tang @ 2014-01-23 2:47 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
prabhakar@freescale.com
In-Reply-To: <1390437863.24905.549.camel@snotra.buserror.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiAyMDE05bm0MeaciDIz5pelIOaYn+acn+WbmyA4OjQ0DQo+IFRvOiBUYW5nIFl1YW50
aWFuLUIyOTk4Mw0KPiBDYzogV29vZCBTY290dC1CMDc0MjE7IGdhbGFrQGtlcm5lbC5jcmFzaGlu
Zy5vcmc7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZzsgZGV2aWNldHJlZUB2Z2Vy
Lmtlcm5lbC5vcmc7IEt1c2h3YWhhIFByYWJoYWthci0NCj4gQjMyNTc5DQo+IFN1YmplY3Q6IFJl
OiBbUEFUQ0hdIGNsazogY29yZW5ldDogVXBkYXRlIHRoZSBjbG9jayBiaW5kaW5ncw0KPiANCj4g
T24gVHVlLCAyMDE0LTAxLTIxIGF0IDEwOjAyICswODAwLCBUYW5nIFl1YW50aWFuIHdyb3RlOg0K
PiA+IEZyb206IFRhbmcgWXVhbnRpYW4gPHl1YW50aWFuLnRhbmdAZnJlZXNjYWxlLmNvbT4NCj4g
Pg0KPiA+IE1haW4gY2hhbmdzIGluY2x1ZGU6DQo+ID4gCS0gQ2xhcmlmaWVkIHRoZSBjbG9jayBu
b2RlcycgdmVyc2lvbiBudW1iZXINCj4gPiAJLSBGaXhlZCBhIGlzc3VlIGluIGV4YW1wbGUNCj4g
Pg0KPiA+IFNpbmdlZC1vZmYtYnk6IFRhbmcgWXVhbnRpYW4gPFl1YW50aWFuLlRhbmdAZnJlZXNj
YWxlLmNvbT4NCj4gPiAtLS0NCj4gPiAgRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdz
L2Nsb2NrL2NvcmVuZXQtY2xvY2sudHh0IHwgNCArKystDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCAz
IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9Eb2N1
bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvY2xvY2svY29yZW5ldC1jbG9jay50eHQNCj4g
PiBiL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9jbG9jay9jb3JlbmV0LWNsb2Nr
LnR4dA0KPiA+IGluZGV4IDI0NzExYWYuLmQ2Y2FkZWYgMTAwNjQ0DQo+ID4gLS0tIGEvRG9jdW1l
bnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2NrL2NvcmVuZXQtY2xvY2sudHh0DQo+ID4g
KysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2NrL2NvcmVuZXQtY2xv
Y2sudHh0DQo+ID4gQEAgLTU0LDYgKzU0LDggQEAgUmVxdWlyZWQgcHJvcGVydGllczoNCj4gPiAg
CQlJdCB0YWtlcyBwYXJlbnQncyBjbG9jay1mcmVxdWVuY3kgYXMgaXRzIGNsb2NrLg0KPiA+ICAJ
KiAiZnNsLHFvcmlxLXN5c2Nsay0yLjAiOiBmb3IgaW5wdXQgc3lzdGVtIGNsb2NrICh2Mi4wKS4N
Cj4gPiAgCQlJdCB0YWtlcyBwYXJlbnQncyBjbG9jay1mcmVxdWVuY3kgYXMgaXRzIGNsb2NrLg0K
PiA+ICsJTm90ZTogdjEuMCBhbmQgdjIuMCBhcmUgY2xvY2sgdmVyc2lvbiB3aGljaCBzaG91bGQg
YWxpZ24gdG8NCj4gPiArCWNsb2NrZ2VuIG5vZGUncyB0aGV5IGJlbG9uZyB0byB3aGljaCBpcyBj
aGFzc2lzIHZlcnNpb24uDQo+IA0KPiBJbnN0ZWFkLCBob3cgYWJvdXQgYSBub3RlIGxpa2UgdGhp
cyBuZWFyIHRoZSB0b3Agb2YgdGhlIGZpbGU6DQo+IA0KPiBBbGwgcmVmZXJlbmNlcyB0byAiMS4w
IiBhbmQgIjIuMCIgcmVmZXIgdG8gdGhlIFFvcklRIGNoYXNzaXMgdmVyc2lvbiB0bw0KPiB3aGlj
aCB0aGUgY2hpcCBjb21wbGllcy4NCj4gDQo+IENoYXNzaXMgVmVyc2lvbgkJRXhhbXBsZSBDaGlw
cw0KPiAtLS0tLS0tLS0tLS0tLS0JCS0tLS0tLS0tLS0tLS0NCj4gMS4wCQkJcDQwODAsIHA1MDIw
LCBwNTA0MA0KPiAyLjAJCQl0NDI0MCwgYjQ4NjAsIHQxMDQwDQo+IA0KQmV0dGVyLCBJIHdpbGwg
dXBkYXRlLg0KDQo+IA0KPiBCVFcsIHRoaXMgYmluZGluZyBhbmQgdGhlIGFzc29jaWF0ZWQgZHJp
dmVyIHJlYWxseSBzaG91bGQgYmUgY2FsbGVkDQo+ICJxb3JpcS1jbG9jayIsIG5vdCAiY29yZW5l
dC1jbG9jayIuICBUaGlzIHdvdWxkIG1hdGNoIHRoZSBjb21wYXRpYmxlDQo+IHN0cmluZywgYW5k
IGl0IGRvZXNuJ3QgcmVhbGx5IGhhdmUgbXVjaCB0byBkbyB3aXRoIGNvcmVuZXQgKHdoaWNoIGlz
IHBhcnQNCj4gb2YgdGhlIFFvcklRIGNoYXNzaXMgdjEgYW5kIHYyLCBidXQgbm90ICp0aGlzKiBw
YXJ0KS4gIERvIHlvdSBrbm93IGlmIHRoZQ0KPiBjaGFzc2lzIHYzIGNsb2NrIGludGVyZmFjZSB3
aWxsIGJlIHNpbWlsYXIgZW5vdWdoIHRvIHNoYXJlIGEgZHJpdmVyPw0KPiANCkRvZXNuJ3QgUW9y
SVEgaW5jbHVkZSBzb21lIGxvdy1lbmQgc29jcywgbGlrZSBwMTAyMiwgcDEwMjA/IA0KVGhpcyBk
cml2ZXIgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGVzZSBib2FyZHMuIA0KSSBoYXZlIG5vIGlk
ZWEgYWJvdXQgY2hhc3NpcyB2My4gSWYgaXQgaGFzIHNpbWlsYXIgY2xvY2sgdHJlZSwgdGhpcyBk
cml2ZXIgY2FuIGJlIHNoYXJlZC4NCkV2ZW4gdGhlIGRyaXZlciBjYW4ndCBiZSB1c2VkIGJ5IHYz
LCB3ZSBjYW4gZWFzaWx5IGFkZCB2MyBzdXBwb3J0IHNpbmNlIGl0IGhhcyBkaWZmZXJlbnQNCkNv
bXBhdGlibGUgc3RyaW5nLg0KDQpSZWdhcmRzLA0KWXVhbnRpYW4NCg0KPiAtU2NvdHQNCj4gDQoN
Cg==
^ permalink raw reply
* RE: [PATCH 2/3] powerpc/85xx: Provide two functions to save/restore the core registers
From: Dongsheng.Wang @ 2014-01-23 2:49 UTC (permalink / raw)
To: Scott Wood
Cc: anton@enomsg.org, linuxppc-dev@lists.ozlabs.org,
chenhui.zhao@freescale.com
In-Reply-To: <1390438219.24905.551.camel@snotra.buserror.net>
PiA+ID4NCj4gPiA+IFRoZSB3aG9sZSBwb2ludCBvZiBjYWxsaW5nIGVuYWJsZV9rZXJuZWxfZnAo
KSBpbiBDIGNvZGUgYmVmb3JlDQo+ID4gPiBzdXNwZW5kaW5nIGlzIHRvIGVuc3VyZSB0aGF0IHRo
ZSBGUCBzdGF0ZSBnZXRzIHNhdmVkLiAgSWYgRlAgaXMgdXNlZA0KPiA+ID4gYWZ0ZXIgdGhhdCBw
b2ludCBpdCBpcyBhIGJ1Zy4gIElmIHlvdSdyZSB3b3JyaWVkIGFib3V0IHN1Y2ggYnVncywgdGhl
bg0KPiA+ID4gY2xlYXIgTVNSW0ZQXSBhZnRlciBjYWxsaW5nIGVuYWJsZV9rZXJuZWxfZnAoKSwg
cmF0aGVyIHRoYW4gYWRkaW5nDQo+ID4gPiByZWR1bmRhbnQgc3RhdGUgc2F2aW5nLg0KPiA+ID4N
Cj4gPg0KPiA+IGVuYWJsZV9rZXJuZWxfZnAoKSBjYWxsaW5nIGluIE1FTSBzdXNwZW5kIGZsb3cu
DQo+ID4gSGliZXJuYXRpb24gaXMgZGlmZmVyZW50IHdpdGggTUVNIHN1c3BlbmQsIGFuZCBJJ20g
bm90IHN1cmUgd2hlcmUgd2lsbCBjYWxsDQo+IHRoaXMNCj4gPiBpbnRlcmZhY2UsIHNvIHdlIG5l
ZWQgdG8gZW5zdXJlIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGNvcmUgc2F2aW5nLiBJIGRvbid0DQo+
IHRoaW5rDQo+ID4gdGhpcyBjb2RlIGlzICpyZWR1bmRhbnQqLiBJIHRydXN0IHRoYXQgdGhlIGtl
cm5lbCBjYW4ga2VlcCB0aGUgRlAgcmVsYXRlZA0KPiA+IG9wZXJhdGlvbnMsIHRoYXQncyB3aHkg
YSBqdWRnbWVudCBpcyBoZXJlLiA6KQ0KPiANCj4gRm9yIGhpYmVybmF0aW9uLCBzYXZlX3Byb2Nl
c3Nvcl9zdGF0ZSgpIGlzIGNhbGxlZCBmaXJzdCwgd2hpY2ggZG9lcw0KPiBmbHVzaF9mcF90b190
aHJlYWQoKSB3aGljaCBoYXMgYSBzaW1pbGFyIGVmZmVjdCAodGhvdWdoIEkgd29uZGVyIGlmIGl0
J3MNCj4gYmVpbmcgY2FsbGVkIG9uIHRoZSBjb3JyZWN0IHRhc2sgZm9yIG5vbi1TTVApLg0KPiAN
ClllcywgdGhhbmtzLCBJIG1pc3MgdGhpcyBjb2RlLjopDQoNCkJ1dCBJIHN0aWxsIHRoaW5rIHdl
IG5lZWQgdG8ga2VlcCB0aGlzIGp1ZGdtZW50LCBiZWNhdXNlIGkgcHJvdmlkZSBhbiBBUEkuDQpJ
ZiB5b3Ugc3RpbGwgaW5zaXN0IG9uIEkgY2FuIHJlbW92ZSAqRlAqLCBidXQgSSBkb24ndCB3YW50
IHRvIGRvIHRoaXMuLjopDQo=
^ permalink raw reply
* RE: [PATCH 3/3] powerpc/fsl: Use the new interface to save or restore registers
From: Dongsheng.Wang @ 2014-01-23 3:00 UTC (permalink / raw)
To: Scott Wood
Cc: anton@enomsg.org, linuxppc-dev@lists.ozlabs.org,
chenhui.zhao@freescale.com
In-Reply-To: <1390422892.24905.512.camel@snotra.buserror.net>
PiA+IEN1cnJlbnRseSBkb2VzIG5vdCBzdXBwb3J0LiBvayBjaGFuZ2UgdGhlIG5hbWUgZmlyc3Qs
IGlmIGxhdGVyIHN1cHBvcnQsIGFuZA0KPiA+IHRoZW4gYWdhaW4gdG8gbW9kaWZ5IHRoZSBuYW1l
IG9mIHRoaXMgZnVuY3Rpb24uDQo+ID4NCj4gPiBIb3cgYWJvdXQgODV4eF9jcHVfc3RhdGVfcmVz
dG9yZT8NCj4gDQo+IFN5bWJvbHMgY2FuJ3QgYmVnaW4gd2l0aCBudW1iZXJzLiAgYm9va2VfY3B1
X3N0YXRlX3Jlc3RvcmUgd291bGQgYmUNCj4gYmV0dGVyIChpdCB3b3VsZCBzdGlsbCBwcm92aWRl
IGEgcGxhY2UgZm9yIDQ0eCB0byBiZSBhZGRlZCBpZiBzb21lYm9keQ0KPiBhY3R1YWxseSBjYXJl
ZCBhYm91dCBkb2luZyBzbykuDQo+IA0KOikuIFRoYW5rcy4NCg0KLURvbmdzaGVuZw0KDQo=
^ permalink raw reply
* RE: [PATCH] mtd: m25p80: Make the name of mtd_info fixed
From: B48286 @ 2014-01-23 3:29 UTC (permalink / raw)
To: 'Brian Norris'
Cc: Scott Wood, linuxppc-dev@ozlabs.org, Mingkai.Hu@freescale.com,
linux-mtd@lists.infradead.org, Ezequiel Garcia
In-Reply-To: <20140123021213.GZ8919@ld-irv-0074>
Hi Brian,
Thanks for your comments!
> -----Original Message-----
> From: Brian Norris [mailto:computersforpeace@gmail.com]
> Sent: Thursday, January 23, 2014 10:12 AM
> To: Hou Zhiqiang-B48286
> Cc: linux-mtd@lists.infradead.org; linuxppc-dev@ozlabs.org; Wood Scott-
> B07421; Hu Mingkai-B21284; Ezequiel Garcia
> Subject: Re: [PATCH] mtd: m25p80: Make the name of mtd_info fixed
>=20
> Hi Hou,
>=20
> On Mon, Jan 06, 2014 at 02:34:29PM +0800, Hou Zhiqiang wrote:
> > To give spi flash layout using "mtdparts=3D..." in cmdline, we must giv=
e
> > mtd_info a fixed name,because the cmdlinepart's parser will match the
> > name given in cmdline with the mtd_info.
> >
> > Now, if use OF node, mtd_info's name will be spi->dev->name. It
> > consists of spi_master->bus_num, and the spi_master->bus_num maybe
> > dynamically fetched.
> > So, give the mtd_info a new fiexd name "name.cs", "name" is name of
> > spi_device_id and "cs" is chip-select in spi_dev.
> >
> > Signed-off-by: Hou Zhiqiang <b48286@freescale.com>
> > ---
> > drivers/mtd/devices/m25p80.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/devices/m25p80.c
> > b/drivers/mtd/devices/m25p80.c index eb558e8..d1ed480 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > @@ -1012,7 +1012,8 @@ static int m25p_probe(struct spi_device *spi)
> > if (data && data->name)
> > flash->mtd.name =3D data->name;
> > else
> > - flash->mtd.name =3D dev_name(&spi->dev);
> > + flash->mtd.name =3D kasprintf(GFP_KERNEL, "%s.%d",
> > + id->name, spi->chip_select);
>=20
> Changing the mtd.name may have far-reaching consequences for users who
> already have mtdparts=3D command lines. But your concern is probably vali=
d
> for dynamically-determined bus numbers. Perhaps you can edit this patch
> to only change the name when the busnum is dynamically-allocated?
>
It's a good idea, but in the case of mtd_info's name dynamically-allocated
using "mtdparts=3D..." in command lines is illegal obviously. Would you tel=
l
me what side-effect will be brought by the change of mtd_info's name.
Thanks=20
=20
> This also needs a NULL check (for OOM), and you leak memory on device
> removal.
>=20
Yes, it's necessary to check the return value of function kasprintf.
> >
> > flash->mtd.type =3D MTD_NORFLASH;
> > flash->mtd.writesize =3D 1;
>=20
> Brian
>=20
Thanks,
Hou Zhiqiang
^ permalink raw reply
* Re: [PATCH V5 6/8] time/cpuidle: Support in tick broadcast framework in the absence of external clock device
From: Preeti U Murthy @ 2014-01-23 3:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: daniel.lezcano, peterz, fweisbec, paul.gortmaker, paulus, mingo,
mikey, shangw, rafael.j.wysocki, agraf, paulmck, arnd, linux-pm,
rostedt, michael, john.stultz, anton, chenhui.zhao, deepthi,
r58472, geoff, linux-kernel, srivatsa.bhat, schwidefsky,
linuxppc-dev
In-Reply-To: <alpine.DEB.2.02.1401221042130.4260@ionos.tec.linutronix.de>
Hi Thomas,
Thank you very much for the review.
On 01/22/2014 06:57 PM, Thomas Gleixner wrote:
> On Wed, 15 Jan 2014, Preeti U Murthy wrote:
>> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
>> index 086ad60..d61404e 100644
>> --- a/kernel/time/clockevents.c
>> +++ b/kernel/time/clockevents.c
>> @@ -524,12 +524,13 @@ void clockevents_resume(void)
>> #ifdef CONFIG_GENERIC_CLOCKEVENTS
>> /**
>> * clockevents_notify - notification about relevant events
>> + * Returns non zero on error.
>> */
>> -void clockevents_notify(unsigned long reason, void *arg)
>> +int clockevents_notify(unsigned long reason, void *arg)
>> {
>
> The interface change of clockevents_notify wants to be a separate
> patch.
>
>> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
>> index 9532690..1c23912 100644
>> --- a/kernel/time/tick-broadcast.c
>> +++ b/kernel/time/tick-broadcast.c
>> @@ -20,6 +20,7 @@
>> #include <linux/sched.h>
>> #include <linux/smp.h>
>> #include <linux/module.h>
>> +#include <linux/slab.h>
>>
>> #include "tick-internal.h"
>>
>> @@ -35,6 +36,15 @@ static cpumask_var_t tmpmask;
>> static DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
>> static int tick_broadcast_force;
>>
>> +/*
>> + * Helper variables for handling broadcast in the absence of a
>> + * tick_broadcast_device.
>> + * */
>> +static struct hrtimer *bc_hrtimer;
>> +static int bc_cpu = -1;
>> +static ktime_t bc_next_wakeup;
>
> Why do you need another variable to store the expiry time? The
> broadcast code already knows it and the hrtimer expiry value gives you
> the same information for free.
The reason was functions like tick_handle_oneshot_broadcast() and
tick_broadcast_switch_to_oneshot() were using the
tick_broadcast_device.evtdev->next_event to set/get the next wakeups.
But since this patchset introduced an explicit hrtimer for archs which
did not have such a device, I wanted these functions to use a generic
parameter to set/get the next wakeups without having to know about the
existence of this hrtimer, if at all. And program the hrtimer/tick
broadcast device whichever was present only when the next event was to
be set. But with your below concept patch, we will not be required to do
this.
>
>> +static int hrtimer_initialized = 0;
>
> What's the point of this hrtimer_initialized dance? Why not simply
> making the hrtimer static and avoid that all together. Also adding the
> initialization into tick_broadcast_oneshot_available() is
> braindamaged. Why not adding this to tick_broadcast_init() which is
> the proper place to do?
Right I agree, this hrtimer initialization should have been in
tick_broadcast_init() and a simple static declaration would have done
the job.
>
> Aside of that you are making this hrtimer mode unconditional, which
> might break existing systems which are not aware of the hrtimer
> implications.
>
> What you really want is a pseudo clock event device which has the
> proper functions for handling the timer and you can register it from
> your architecture code. The broadcast core code needs a few tweaks to
> avoid the shutdown of the cpu local clock event device, but aside of
> that the whole thing just falls into place. So architectures can use
> this if they want and are sure that their low level idle code knows
> about the deep idle preventing return value of
> clockevents_notify(). Once that works you can register the hrtimer
> based broadcast device and a real hardware broadcast device with a
> higher rating. It just works.
I now completely see your point. This will surely break on archs which
are not using the return value of the BROADCAST_ENTER notification.
I am not even giving them a choice about using the hrtimer mode of
broadcast framework and am expecting them to take action for the failed
return of BROADCAST_ENTER. I missed that critical point. I went through
the below patch and am able to see how you are solving this problem.
>
> Find an incomplete and nonfunctional concept patch below. It should be
> simple to make it work for real.
Thank you very much for the valuable review. The below patch makes your
points very clear. Let me try this out.
Regards
Preeti U Murthy
>
> Thanks,
>
> tglx
> ----
> Index: linux-2.6/include/linux/clockchips.h
> ===================================================================
> --- linux-2.6.orig/include/linux/clockchips.h
> +++ linux-2.6/include/linux/clockchips.h
> @@ -62,6 +62,11 @@ enum clock_event_mode {
> #define CLOCK_EVT_FEAT_DYNIRQ 0x000020
> #define CLOCK_EVT_FEAT_PERCPU 0x000040
>
> +/*
> + * Clockevent device is based on a hrtimer for broadcast
> + */
> +#define CLOCK_EVT_FEAT_HRTIMER 0x000080
> +
> /**
> * struct clock_event_device - clock event device descriptor
> * @event_handler: Assigned by the framework to be called by the low
> @@ -83,6 +88,7 @@ enum clock_event_mode {
> * @name: ptr to clock event name
> * @rating: variable to rate clock event devices
> * @irq: IRQ number (only for non CPU local devices)
> + * @bound_on: Bound on CPU
> * @cpumask: cpumask to indicate for which CPUs this device works
> * @list: list head for the management code
> * @owner: module reference
> @@ -113,6 +119,7 @@ struct clock_event_device {
> const char *name;
> int rating;
> int irq;
> + int bound_on;
> const struct cpumask *cpumask;
> struct list_head list;
> struct module *owner;
> Index: linux-2.6/kernel/time/tick-broadcast-hrtimer.c
> ===================================================================
> --- /dev/null
> +++ linux-2.6/kernel/time/tick-broadcast-hrtimer.c
> @@ -0,0 +1,77 @@
> +
> +static struct hrtimer bctimer;
> +
> +static void bc_set_mode(enum clock_event_mode mode,
> + struct clock_event_device *bc)
> +{
> + switch (mode) {
> + case CLOCK_EVT_MODE_SHUTDOWN:
> + /*
> + * Note, we cannot cancel the timer here as we might
> + * run into the following live lock scenario:
> + *
> + * cpu 0 cpu1
> + * lock(broadcast_lock);
> + * hrtimer_interrupt()
> + * bc_handler()
> + * tick_handle_oneshot_broadcast();
> + * lock(broadcast_lock);
> + * hrtimer_cancel()
> + * wait_for_callback()
> + */
> + hrtimer_try_to_cancel(&bctimer);
> + break;
> + default:
> + break;
> + }
> +}
> +
> +/*
> + * This is called from the guts of the broadcast code when the cpu
> + * which is about to enter idle has the earliest broadcast timer event.
> + */
> +static int bc_set_next(ktime_t expires, struct clock_event_device *bc)
> +{
> + /*
> + * We try to cancel the timer first. If the callback is on
> + * flight on some other cpu then we let it handle it. If we
> + * were able to cancel the timer nothing can rearm it as we
> + * own broadcast_lock.
> + */
> + if (hrtimer_try_to_cancel(&bctimer) >= 0) {
> + hrtimer_start(&bctimer, expires, HRTIMER_MODE_ABS_PINNED);
> + /* Bind the "device" to the cpu */
> + bc->bound_on = smp_processor_id();
> + }
> + return 0;
> +}
> +
> +static struct clock_event_device ce_broadcast_hrtimer = {
> + .set_mode = bc_set_mode,
> + .set_next_ktime = bc_set_next,
> + .features = CLOCK_EVT_FEAT_ONESHOT |
> + CLOCK_EVT_FEAT_KTIME |
> + CLOCK_EVT_FEAT_HRTIMER,
> + .rating = 0,
> + .bound_on = -1,
> + .min_delta_ns = 1,
> + .max_delta_ns = KTIME_MAX,
> + .min_delta_ticks = 1,
> + .max_delta_ticks = KTIME_MAX,
> + .mult = 1,
> + .shift = 0,
> + .cpumask = cpu_all_mask,
> +};
> +
> +static enum hrtimer_restart bc_handler(struct hrtimer *t)
> +{
> + ce_broadcast_hrtimer.event_handler(&ce_broadcast_hrtimer);
> + return HRTIMER_NORESTART;
> +}
> +
> +void tick_setup_hrtimer_broadcast(void)
> +{
> + hrtimer_init(&bctimer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> + bctimer.function = bc_handler;
> + clockevents_register(&ce_broadcast_hrtimer);
> +}
> Index: linux-2.6/kernel/time/tick-broadcast.c
> ===================================================================
> --- linux-2.6.orig/kernel/time/tick-broadcast.c
> +++ linux-2.6/kernel/time/tick-broadcast.c
> @@ -630,6 +630,42 @@ again:
> raw_spin_unlock(&tick_broadcast_lock);
> }
>
> +static int broadcast_needs_cpu(struct clock_event_device *bc, int cpu)
> +{
> + if (!(bc->features & CLOCK_EVT_FEAT_HRTIMER))
> + return 0;
> + if (bc->next_event.tv64 == KTIME_MAX)
> + return 0;
> + return bc->bound_on == cpu ? -EBUSY : 0;
> +}
> +
> +static void broadcast_shutdown_local(struct clock_event_device *bc,
> + struct clock_event_device *dev)
> +{
> + /*
> + * For hrtimer based broadcasting we cannot shutdown the cpu
> + * local device if our own event is the first one to expire or
> + * if we own the broadcast timer.
> + */
> + if (bc->features & CLOCK_EVT_FEAT_HRTIMER) {
> + if (broadcast_needs_cpu(bc))
> + return;
> + if (dev->next_event.tv64 < bc->next_event.tv64)
> + return;
> + }
> + clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
> +}
> +
> +static void broadcast_move_bc(int deadcpu)
> +{
> + struct clock_event_device *bc = tick_broadcast_device.evtdev;
> +
> + if (!bc || !broadcast_needs_cpu(bc, deadcpu))
> + return;
> + /* This moves the broadcast assignment to this cpu */
> + clockevents_program_event(bc, bc->next_event, 1);
> +}
> +
> /*
> * Powerstate information: The system enters/leaves a state, where
> * affected devices might stop
> @@ -639,8 +675,8 @@ void tick_broadcast_oneshot_control(unsi
> struct clock_event_device *bc, *dev;
> struct tick_device *td;
> unsigned long flags;
> + int cpu, ret = 0;
> ktime_t now;
> - int cpu;
>
> /*
> * Periodic mode does not care about the enter/exit of power
> @@ -666,7 +702,7 @@ void tick_broadcast_oneshot_control(unsi
> if (reason == CLOCK_EVT_NOTIFY_BROADCAST_ENTER) {
> if (!cpumask_test_and_set_cpu(cpu, tick_broadcast_oneshot_mask)) {
> WARN_ON_ONCE(cpumask_test_cpu(cpu, tick_broadcast_pending_mask));
> - clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
> + broadcast_shutdown_local(bc, dev);
> /*
> * We only reprogram the broadcast timer if we
> * did not mark ourself in the force mask and
> @@ -679,6 +715,11 @@ void tick_broadcast_oneshot_control(unsi
> dev->next_event.tv64 < bc->next_event.tv64)
> tick_broadcast_set_event(bc, cpu, dev->next_event, 1);
> }
> + /*
> + * If the current CPU owns the hrtimer broadcast
> + * mechanism, it cannot go deep idle.
> + */
> + ret = broadcast_needs_cpu(bc, cpu);
> } else {
> if (cpumask_test_and_clear_cpu(cpu, tick_broadcast_oneshot_mask)) {
> clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT);
> @@ -851,6 +892,8 @@ void tick_shutdown_broadcast_oneshot(uns
> cpumask_clear_cpu(cpu, tick_broadcast_pending_mask);
> cpumask_clear_cpu(cpu, tick_broadcast_force_mask);
>
> + broadcast_move_bc(cpu);
> +
> raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
> }
>
>
^ permalink raw reply
* [PATCH 1/2] clocksource: Remove outdated comments
From: Yijing Wang @ 2014-01-23 7:12 UTC (permalink / raw)
To: John Stultz, Thomas Gleixner
Cc: linux-mips, Daniel Lezcano, Kevin Hilman, linux, Sekhar Nori,
Paul Mackerras, H. Peter Anvin, Yijing Wang, Daniel Walker,
Hans-Christian Egtvedt, Jonas Bonn, Kukjin Kim, Russell King,
Richard Weinberger, x86, Tony Lindgren, Ingo Molnar,
linux-arm-msm, David Brown, Haavard Skinnemoen, Mike Frysinger,
user-mode-linux-devel, Nicolas Ferre, Jeff Dike, Barry Song,
linux-samsung-soc, user-mode-linux-user, linux-omap,
linux-arm-kernel, davinci-linux-open-source, Michal Simek,
Jim Cromie, microblaze-uclinux, Hanjun Guo, linux-kernel,
Ralf Baechle, Tony Prisk, Bryan Huntsman, uclinux-dist-devel,
linuxppc-dev
clocksource_register() and __clocksource_register_scale()
always return 0, so the comment is just pointless, it's
outdated, remove it.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
kernel/time/clocksource.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index ba3e502..9951575 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -779,8 +779,6 @@ EXPORT_SYMBOL_GPL(__clocksource_updatefreq_scale);
* @scale: Scale factor multiplied against freq to get clocksource hz
* @freq: clocksource frequency (cycles per second) divided by scale
*
- * Returns -EBUSY if registration fails, zero otherwise.
- *
* This *SHOULD NOT* be called directly! Please use the
* clocksource_register_hz() or clocksource_register_khz helper functions.
*/
@@ -805,7 +803,6 @@ EXPORT_SYMBOL_GPL(__clocksource_register_scale);
* clocksource_register - Used to install new clocksources
* @cs: clocksource to be registered
*
- * Returns -EBUSY if registration fails, zero otherwise.
*/
int clocksource_register(struct clocksource *cs)
{
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] clocksource: Make clocksource register functions void
From: Yijing Wang @ 2014-01-23 7:12 UTC (permalink / raw)
To: John Stultz, Thomas Gleixner
Cc: linux-mips, Daniel Lezcano, Kevin Hilman, linux, Sekhar Nori,
Paul Mackerras, H. Peter Anvin, Yijing Wang, Daniel Walker,
Hans-Christian Egtvedt, Jonas Bonn, Kukjin Kim, Russell King,
Richard Weinberger, x86, Tony Lindgren, Ingo Molnar,
linux-arm-msm, David Brown, Haavard Skinnemoen, Mike Frysinger,
user-mode-linux-devel, Nicolas Ferre, Jeff Dike, Barry Song,
linux-samsung-soc, user-mode-linux-user, linux-omap,
linux-arm-kernel, davinci-linux-open-source, Michal Simek,
Jim Cromie, microblaze-uclinux, Hanjun Guo, linux-kernel,
Ralf Baechle, Tony Prisk, Bryan Huntsman, uclinux-dist-devel,
linuxppc-dev
Currently, clocksource_register() and __clocksource_register_scale()
functions always return 0, it's pointless, make functions void.
And remove the dead code that check the clocksource_register_hz()
return value.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/arm/mach-davinci/time.c | 5 ++---
arch/arm/mach-msm/timer.c | 4 +---
arch/arm/mach-omap2/timer.c | 8 +++-----
arch/avr32/kernel/time.c | 4 +---
arch/blackfin/kernel/time-ts.c | 6 ++----
arch/microblaze/kernel/timer.c | 3 +--
arch/mips/jz4740/time.c | 6 +-----
arch/mips/loongson/common/cs5536/cs5536_mfgpt.c | 3 ++-
arch/openrisc/kernel/time.c | 3 +--
arch/powerpc/kernel/time.c | 6 +-----
arch/um/kernel/time.c | 6 +-----
arch/x86/platform/uv/uv_time.c | 14 ++++++--------
drivers/clocksource/acpi_pm.c | 3 ++-
drivers/clocksource/cadence_ttc_timer.c | 6 +-----
drivers/clocksource/exynos_mct.c | 4 +---
drivers/clocksource/i8253.c | 3 ++-
drivers/clocksource/mmio.c | 3 ++-
drivers/clocksource/samsung_pwm_timer.c | 5 +----
drivers/clocksource/scx200_hrt.c | 3 ++-
drivers/clocksource/tcb_clksrc.c | 8 +-------
drivers/clocksource/timer-marco.c | 2 +-
drivers/clocksource/timer-prima2.c | 2 +-
drivers/clocksource/vt8500_timer.c | 4 +---
include/linux/clocksource.h | 8 ++++----
kernel/time/clocksource.c | 6 ++----
kernel/time/jiffies.c | 3 ++-
26 files changed, 45 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 56c6eb5..9536f85 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -387,9 +387,8 @@ void __init davinci_timer_init(void)
/* setup clocksource */
clocksource_davinci.name = id_to_name[clocksource_id];
- if (clocksource_register_hz(&clocksource_davinci,
- davinci_clock_tick_rate))
- printk(err, clocksource_davinci.name);
+ clocksource_register_hz(&clocksource_davinci,
+ davinci_clock_tick_rate);
setup_sched_clock(davinci_read_sched_clock, 32,
davinci_clock_tick_rate);
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 1e9c338..c96e034 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -226,9 +226,7 @@ static void __init msm_timer_init(u32 dgt_hz, int sched_bits, int irq,
err:
writel_relaxed(TIMER_ENABLE_EN, source_base + TIMER_ENABLE);
- res = clocksource_register_hz(cs, dgt_hz);
- if (res)
- pr_err("clocksource_register failed\n");
+ clocksource_register_hz(cs, dgt_hz);
setup_sched_clock(msm_sched_clock_read, sched_bits, dgt_hz);
}
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 3ca81e0..beaf7c7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -473,11 +473,9 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
OMAP_TIMER_NONPOSTED);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
- if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
- pr_err("Could not register clocksource %s\n",
- clocksource_gpt.name);
- else
- pr_info("OMAP clocksource: %s at %lu Hz\n",
+ clocksource_register_hz(&clocksource_gpt, clksrc.rate);
+
+ pr_info("OMAP clocksource: %s at %lu Hz\n",
clocksource_gpt.name, clksrc.rate);
}
diff --git a/arch/avr32/kernel/time.c b/arch/avr32/kernel/time.c
index d0f771b..51b4a66 100644
--- a/arch/avr32/kernel/time.c
+++ b/arch/avr32/kernel/time.c
@@ -134,9 +134,7 @@ void __init time_init(void)
/* figure rate for counter */
counter_hz = clk_get_rate(boot_cpu_data.clk);
- ret = clocksource_register_hz(&counter, counter_hz);
- if (ret)
- pr_debug("timer: could not register clocksource: %d\n", ret);
+ clocksource_register_hz(&counter, counter_hz);
/* setup COMPARE clockevent */
comparator.mult = div_sc(counter_hz, NSEC_PER_SEC, comparator.shift);
diff --git a/arch/blackfin/kernel/time-ts.c b/arch/blackfin/kernel/time-ts.c
index cb0a484..df3bb08 100644
--- a/arch/blackfin/kernel/time-ts.c
+++ b/arch/blackfin/kernel/time-ts.c
@@ -51,8 +51,7 @@ static inline unsigned long long bfin_cs_cycles_sched_clock(void)
static int __init bfin_cs_cycles_init(void)
{
- if (clocksource_register_hz(&bfin_cs_cycles, get_cclk()))
- panic("failed to register clocksource");
+ clocksource_register_hz(&bfin_cs_cycles, get_cclk());
return 0;
}
@@ -103,8 +102,7 @@ static int __init bfin_cs_gptimer0_init(void)
{
setup_gptimer0();
- if (clocksource_register_hz(&bfin_cs_gptimer0, get_sclk()))
- panic("failed to register clocksource");
+ clocksource_register_hz(&bfin_cs_gptimer0, get_sclk());
return 0;
}
diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index 3e39b10..6a2417e 100644
--- a/arch/microblaze/kernel/timer.c
+++ b/arch/microblaze/kernel/timer.c
@@ -208,8 +208,7 @@ static struct clocksource clocksource_microblaze = {
static int __init xilinx_clocksource_init(void)
{
- if (clocksource_register_hz(&clocksource_microblaze, timer_clock_freq))
- panic("failed to register clocksource");
+ clocksource_register_hz(&clocksource_microblaze, timer_clock_freq);
/* stop timer1 */
out_be32(timer_baseaddr + TCSR1,
diff --git a/arch/mips/jz4740/time.c b/arch/mips/jz4740/time.c
index 5e430ce..041cdff 100644
--- a/arch/mips/jz4740/time.c
+++ b/arch/mips/jz4740/time.c
@@ -105,7 +105,6 @@ static struct irqaction timer_irqaction = {
void __init plat_time_init(void)
{
- int ret;
uint32_t clk_rate;
uint16_t ctrl;
@@ -121,10 +120,7 @@ void __init plat_time_init(void)
clockevents_register_device(&jz4740_clockevent);
- ret = clocksource_register_hz(&jz4740_clocksource, clk_rate);
-
- if (ret)
- printk(KERN_ERR "Failed to register clocksource: %d\n", ret);
+ clocksource_register_hz(&jz4740_clocksource, clk_rate);
setup_irq(JZ4740_IRQ_TCU0, &timer_irqaction);
diff --git a/arch/mips/loongson/common/cs5536/cs5536_mfgpt.c b/arch/mips/loongson/common/cs5536/cs5536_mfgpt.c
index c639b9d..9fa6d99 100644
--- a/arch/mips/loongson/common/cs5536/cs5536_mfgpt.c
+++ b/arch/mips/loongson/common/cs5536/cs5536_mfgpt.c
@@ -208,7 +208,8 @@ int __init init_mfgpt_clocksource(void)
if (num_possible_cpus() > 1) /* MFGPT does not scale! */
return 0;
- return clocksource_register_hz(&clocksource_mfgpt, MFGPT_TICK_RATE);
+ clocksource_register_hz(&clocksource_mfgpt, MFGPT_TICK_RATE);
+ return 0;
}
arch_initcall(init_mfgpt_clocksource);
diff --git a/arch/openrisc/kernel/time.c b/arch/openrisc/kernel/time.c
index 7c52e94..3f789aa 100644
--- a/arch/openrisc/kernel/time.c
+++ b/arch/openrisc/kernel/time.c
@@ -156,8 +156,7 @@ static struct clocksource openrisc_timer = {
static int __init openrisc_timer_init(void)
{
- if (clocksource_register_hz(&openrisc_timer, cpuinfo.clock_frequency))
- panic("failed to register clocksource");
+ clocksource_register_hz(&openrisc_timer, cpuinfo.clock_frequency);
/* Enable the incrementer: 'continuous' mode with interrupt disabled */
mtspr(SPR_TTMR, SPR_TTMR_CR);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b3b1441..27c0627 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -788,11 +788,7 @@ static void __init clocksource_init(void)
else
clock = &clocksource_timebase;
- if (clocksource_register_hz(clock, tb_ticks_per_sec)) {
- printk(KERN_ERR "clocksource: %s is already registered\n",
- clock->name);
- return;
- }
+ clocksource_register_hz(clock, tb_ticks_per_sec);
printk(KERN_INFO "clocksource: %s mult[%x] shift[%d] registered\n",
clock->name, clock->mult, clock->shift);
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index 117568d..2034b58 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -92,11 +92,7 @@ static void __init setup_itimer(void)
clockevent_delta2ns(60 * HZ, &itimer_clockevent);
itimer_clockevent.min_delta_ns =
clockevent_delta2ns(1, &itimer_clockevent);
- err = clocksource_register_hz(&itimer_clocksource, USEC_PER_SEC);
- if (err) {
- printk(KERN_ERR "clocksource_register_hz returned %d\n", err);
- return;
- }
+ clocksource_register_hz(&itimer_clocksource, USEC_PER_SEC);
clockevents_register_device(&itimer_clockevent);
}
diff --git a/arch/x86/platform/uv/uv_time.c b/arch/x86/platform/uv/uv_time.c
index 5c86786..b963774 100644
--- a/arch/x86/platform/uv/uv_time.c
+++ b/arch/x86/platform/uv/uv_time.c
@@ -379,15 +379,13 @@ static __init int uv_rtc_setup_clock(void)
if (!is_uv_system())
return -ENODEV;
- rc = clocksource_register_hz(&clocksource_uv, sn_rtc_cycles_per_second);
- if (rc)
- printk(KERN_INFO "UV RTC clocksource failed rc %d\n", rc);
- else
- printk(KERN_INFO "UV RTC clocksource registered freq %lu MHz\n",
- sn_rtc_cycles_per_second/(unsigned long)1E6);
+ clocksource_register_hz(&clocksource_uv, sn_rtc_cycles_per_second);
+
+ pr_info("UV RTC clocksource registered freq %lu MHz\n",
+ sn_rtc_cycles_per_second/(unsigned long)1E6);
- if (rc || !uv_rtc_evt_enable || x86_platform_ipi_callback)
- return rc;
+ if (!uv_rtc_evt_enable || x86_platform_ipi_callback)
+ return 0;
/* Setup and register clockevents */
rc = uv_rtc_allocate_timers();
diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index 6eab889..ab1dc63 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -218,8 +218,9 @@ static int __init init_acpi_pm_clocksource(void)
return -ENODEV;
}
- return clocksource_register_hz(&clocksource_acpi_pm,
+ clocksource_register_hz(&clocksource_acpi_pm,
PMTMR_TICKS_PER_SEC);
+ return 0;
}
/* We use fs_initcall because we want the PCI fixups to have run
diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
index 63f176d..b9b56ed 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -301,11 +301,7 @@ static void __init ttc_setup_clocksource(struct clk *clk, void __iomem *base)
__raw_writel(CNT_CNTRL_RESET,
ttccs->ttc.base_addr + TTC_CNT_CNTRL_OFFSET);
- err = clocksource_register_hz(&ttccs->cs, ttccs->ttc.freq / PRESCALE);
- if (WARN_ON(err)) {
- kfree(ttccs);
- return;
- }
+ clocksource_register_hz(&ttccs->cs, ttccs->ttc.freq / PRESCALE);
ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
sched_clock_register(ttc_sched_clock_read, 16, ttccs->ttc.freq / PRESCALE);
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 62b0de6..98649c7 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -193,9 +193,7 @@ struct clocksource mct_frc = {
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start(0, 0);
-
- if (clocksource_register_hz(&mct_frc, clk_rate))
- panic("%s: can't register clocksource\n", mct_frc.name);
+ clocksource_register_hz(&mct_frc, clk_rate);
}
static void exynos4_mct_comp0_stop(void)
diff --git a/drivers/clocksource/i8253.c b/drivers/clocksource/i8253.c
index 14ee3ef..9c45f0a 100644
--- a/drivers/clocksource/i8253.c
+++ b/drivers/clocksource/i8253.c
@@ -95,7 +95,8 @@ static struct clocksource i8253_cs = {
int __init clocksource_i8253_init(void)
{
- return clocksource_register_hz(&i8253_cs, PIT_TICK_RATE);
+ clocksource_register_hz(&i8253_cs, PIT_TICK_RATE);
+ return 0;
}
#endif
diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
index c0e2512..6e0b530 100644
--- a/drivers/clocksource/mmio.c
+++ b/drivers/clocksource/mmio.c
@@ -69,5 +69,6 @@ int __init clocksource_mmio_init(void __iomem *base, const char *name,
cs->clksrc.mask = CLOCKSOURCE_MASK(bits);
cs->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
- return clocksource_register_hz(&cs->clksrc, hz);
+ clocksource_register_hz(&cs->clksrc, hz);
+ return 0;
}
diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 5645cfc..c59292f 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -340,7 +340,6 @@ static void __init samsung_clocksource_init(void)
{
unsigned long pclk;
unsigned long clock_rate;
- int ret;
pclk = clk_get_rate(pwm.timerclk);
@@ -361,9 +360,7 @@ static void __init samsung_clocksource_init(void)
pwm.variant.bits, clock_rate);
samsung_clocksource.mask = CLOCKSOURCE_MASK(pwm.variant.bits);
- ret = clocksource_register_hz(&samsung_clocksource, clock_rate);
- if (ret)
- panic("samsung_clocksource_timer: can't register clocksource\n");
+ clocksource_register_hz(&samsung_clocksource, clock_rate);
}
static void __init samsung_timer_resources(void)
diff --git a/drivers/clocksource/scx200_hrt.c b/drivers/clocksource/scx200_hrt.c
index 64f9e82..57bdc04 100644
--- a/drivers/clocksource/scx200_hrt.c
+++ b/drivers/clocksource/scx200_hrt.c
@@ -83,7 +83,8 @@ static int __init init_hrt_clocksource(void)
pr_info("enabling scx200 high-res timer (%s MHz +%d ppm)\n", mhz27 ? "27":"1", ppm);
- return clocksource_register_hz(&cs_hrt, freq);
+ clocksource_register_hz(&cs_hrt, freq);
+ return 0;
}
module_init(init_hrt_clocksource);
diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index 00fdd11..805245d 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -340,9 +340,7 @@ static int __init tcb_clksrc_init(void)
}
/* and away we go! */
- ret = clocksource_register_hz(&clksrc, divided_rate);
- if (ret)
- goto err_disable_t1;
+ clocksource_register_hz(&clksrc, divided_rate);
/* channel 2: periodic and oneshot timer support */
ret = setup_clkevents(tc, clk32k_divisor_idx);
@@ -354,10 +352,6 @@ static int __init tcb_clksrc_init(void)
err_unregister_clksrc:
clocksource_unregister(&clksrc);
-err_disable_t1:
- if (!tc->tcb_config || tc->tcb_config->counter_width != 32)
- clk_disable_unprepare(tc->clk[1]);
-
err_disable_t0:
clk_disable_unprepare(t0_clk);
diff --git a/drivers/clocksource/timer-marco.c b/drivers/clocksource/timer-marco.c
index 09a17d9..ae78ce0 100644
--- a/drivers/clocksource/timer-marco.c
+++ b/drivers/clocksource/timer-marco.c
@@ -283,7 +283,7 @@ static void __init sirfsoc_marco_timer_init(void)
/* Clear all interrupts */
writel_relaxed(0xFFFF, sirfsoc_timer_base + SIRFSOC_TIMER_INTR_STATUS);
- BUG_ON(clocksource_register_hz(&sirfsoc_clocksource, CLOCK_TICK_RATE));
+ clocksource_register_hz(&sirfsoc_clocksource, CLOCK_TICK_RATE);
sirfsoc_clockevent_init();
}
diff --git a/drivers/clocksource/timer-prima2.c b/drivers/clocksource/timer-prima2.c
index 8a492d3..c9cc307 100644
--- a/drivers/clocksource/timer-prima2.c
+++ b/drivers/clocksource/timer-prima2.c
@@ -204,7 +204,7 @@ static void __init sirfsoc_prima2_timer_init(struct device_node *np)
writel_relaxed(0, sirfsoc_timer_base + SIRFSOC_TIMER_COUNTER_HI);
writel_relaxed(BIT(0), sirfsoc_timer_base + SIRFSOC_TIMER_STATUS);
- BUG_ON(clocksource_register_hz(&sirfsoc_clocksource, CLOCK_TICK_RATE));
+ clocksource_register_hz(&sirfsoc_clocksource, CLOCK_TICK_RATE);
sched_clock_register(sirfsoc_read_sched_clock, 64, CLOCK_TICK_RATE);
diff --git a/drivers/clocksource/vt8500_timer.c b/drivers/clocksource/vt8500_timer.c
index 1098ed3..13f5fa4 100644
--- a/drivers/clocksource/vt8500_timer.c
+++ b/drivers/clocksource/vt8500_timer.c
@@ -150,9 +150,7 @@ static void __init vt8500_timer_init(struct device_node *np)
writel(0xf, regbase + TIMER_STATUS_VAL);
writel(~0, regbase + TIMER_MATCH_VAL);
- if (clocksource_register_hz(&clocksource, VT8500_TIMER_HZ))
- pr_err("%s: vt8500_timer_init: clocksource_register failed for %s\n",
- __func__, clocksource.name);
+ clocksource_register_hz(&clocksource, VT8500_TIMER_HZ);
clockevent.cpumask = cpumask_of(0);
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 67301a4..5a17c5e 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -282,7 +282,7 @@ static inline s64 clocksource_cyc2ns(cycle_t cycles, u32 mult, u32 shift)
}
-extern int clocksource_register(struct clocksource*);
+extern void clocksource_register(struct clocksource *);
extern int clocksource_unregister(struct clocksource*);
extern void clocksource_touch_watchdog(void);
extern struct clocksource* clocksource_get_next(void);
@@ -301,17 +301,17 @@ clocks_calc_mult_shift(u32 *mult, u32 *shift, u32 from, u32 to, u32 minsec);
* Don't call __clocksource_register_scale directly, use
* clocksource_register_hz/khz
*/
-extern int
+extern void
__clocksource_register_scale(struct clocksource *cs, u32 scale, u32 freq);
extern void
__clocksource_updatefreq_scale(struct clocksource *cs, u32 scale, u32 freq);
-static inline int clocksource_register_hz(struct clocksource *cs, u32 hz)
+static inline void clocksource_register_hz(struct clocksource *cs, u32 hz)
{
return __clocksource_register_scale(cs, 1, hz);
}
-static inline int clocksource_register_khz(struct clocksource *cs, u32 khz)
+static inline void clocksource_register_khz(struct clocksource *cs, u32 khz)
{
return __clocksource_register_scale(cs, 1000, khz);
}
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 9951575..686ff72 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -782,7 +782,7 @@ EXPORT_SYMBOL_GPL(__clocksource_updatefreq_scale);
* This *SHOULD NOT* be called directly! Please use the
* clocksource_register_hz() or clocksource_register_khz helper functions.
*/
-int __clocksource_register_scale(struct clocksource *cs, u32 scale, u32 freq)
+void __clocksource_register_scale(struct clocksource *cs, u32 scale, u32 freq)
{
/* Initialize mult/shift and max_idle_ns */
@@ -794,7 +794,6 @@ int __clocksource_register_scale(struct clocksource *cs, u32 scale, u32 freq)
clocksource_enqueue_watchdog(cs);
clocksource_select();
mutex_unlock(&clocksource_mutex);
- return 0;
}
EXPORT_SYMBOL_GPL(__clocksource_register_scale);
@@ -804,7 +803,7 @@ EXPORT_SYMBOL_GPL(__clocksource_register_scale);
* @cs: clocksource to be registered
*
*/
-int clocksource_register(struct clocksource *cs)
+void clocksource_register(struct clocksource *cs)
{
/* calculate max adjustment for given mult/shift */
cs->maxadj = clocksource_max_adjustment(cs);
@@ -820,7 +819,6 @@ int clocksource_register(struct clocksource *cs)
clocksource_enqueue_watchdog(cs);
clocksource_select();
mutex_unlock(&clocksource_mutex);
- return 0;
}
EXPORT_SYMBOL(clocksource_register);
diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
index 7a925ba..ae4c534 100644
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -88,7 +88,8 @@ EXPORT_SYMBOL(jiffies);
static int __init init_jiffies_clocksource(void)
{
- return clocksource_register(&clocksource_jiffies);
+ clocksource_register(&clocksource_jiffies);
+ return 0;
}
core_initcall(init_jiffies_clocksource);
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox