Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 2/5] arm: add new asm macro update_sctlr
From: Leif Lindholm @ 2014-02-03 16:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140203160051.GG14112@mudshark.cambridge.arm.com>

On Mon, Feb 03, 2014 at 04:00:51PM +0000, Will Deacon wrote:
> > > > With the two call sites in uefi_phys.S as:
> > > > 
> > > > 	ldr	r5, =(CR_M)
> > > > 	update_sctlr	r12, , r5
> > > > and
> > > > 	ldr	r4, =(CR_I | CR_C | CR_M)
> > > > 	update_sctlr	r12, r4
> > > 
> > > These ldr= could be movs, right?
> > 
> > The first one could.
> > The second one could be movw on armv7+.
> > 
> > > If so, I definitely prefer this to putting an ldr = into the macro itself
> > > (option 2).
> > 
> > And your preference between 1) and 2) is?
> 
> (1), using bic and mov[tw] where possible.

(1): ok, thanks.

bic: sure, that was an oversight.

mov[tw]: why?
Then we end up battling different available immediate fields in A32/T32
instruction sets and v5/v6/v7 architecture versions.

/
    Leif

^ permalink raw reply

* [PATCH] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Jean-Jacques Hiblot @ 2014-02-03 16:46 UTC (permalink / raw)
  To: linux-arm-kernel

The name provided to request_irq() must be valid until the irq is
released.
This patch allocates and formats the string with kasprintf().

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
 drivers/clk/at91/clk-programmable.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
index 8e242c7..0f8bf0f 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -19,6 +19,7 @@
 #include <linux/sched.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
+#include <linux/string.h>
 
 #include "pmc.h"
 
@@ -247,7 +248,7 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
 	struct clk_programmable *prog;
 	struct clk *clk = NULL;
 	struct clk_init_data init;
-	char irq_name[11];
+	char *irq_name;
 
 	if (id > PROG_ID_MAX)
 		return ERR_PTR(-EINVAL);
@@ -269,7 +270,7 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
 	prog->irq = irq;
 	init_waitqueue_head(&prog->wait);
 	irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
-	snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
+	irq_name = kasprintf(GFP_KERNEL, "clk-prog%d", id);
 	ret = request_irq(prog->irq, clk_programmable_irq_handler,
 			  IRQF_TRIGGER_HIGH, irq_name, prog);
 	if (ret)
-- 
1.8.5.2

^ permalink raw reply related

* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Will Deacon @ 2014-02-03 16:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+=dm4kPk=e0h_up9=wvED4fd3MBtSNFxm2NEz_yag-uA@mail.gmail.com>

On Fri, Jan 31, 2014 at 04:24:09PM +0000, Rob Herring wrote:
> On Thu, Jan 30, 2014 at 11:45 AM, Andreas Herrmann
> <andreas.herrmann@calxeda.com> wrote:
> > Do you agree on increasing MAX_PHANDLE_ARGS to 32?
> 
> Yes, but more than that will require a closer look. Please get this
> into next early in the cycle.

If you want to get this patch in early, I suggest taking it via a tree other
than mine. I don't put my iommu queue into -next, since it goes to Joerg
around -rc4, who then sticks it in after that.

Will

^ permalink raw reply

* [PATCH v5 00/16] uprobes: Add uprobes support for ARM
From: Jon Medhurst (Tixy) @ 2014-02-03 16:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390507559-4697-1-git-send-email-dave.long@linaro.org>

On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
> From: "David A. Long" <dave.long@linaro.org>
> 
> This patch series adds basic uprobes support to ARM. It is based on patches
> developed earlier by Rabin Vincent. That approach of adding hooks into
> the kprobes instruction parsing code was not well received. This approach
> separates the ARM instruction parsing code in kprobes out into a separate set
> of functions which can be used by both kprobes and uprobes. Both kprobes and
> uprobes then provide their own semantic action tables to process the results of
> the parsing.

Assuming my comment about 'const' use in patch 5 is addressed, then for
patches 2 to 14 you can add:

Acked-by: Jon Medhurst <tixy@linaro.org>

Thanks Dave for persevering.

-- 
Tixy

^ permalink raw reply

* Why are imprecise external aborts masked on recent kernel while booting ?
From: Fabrice Gasnier @ 2014-02-03 16:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52EF5D8E.4050600@st.com>

Hi,

I had no success with msr instruction to set CPSR.A bit.

I re-checked on a 3.4 kernel, msr instruction present in former 
"kernel_thread_helper()" routine was not responsible for clearing CPSR.A 
bit.
'A' bit was cleared because SPSR was altered before executing following 
instruction in arch/arm/kernel/entry-header.S :
movs    pc, lr                @ return & move spsr_svc into cpsr

Sorry for the confusion in my first email: that movs instruction was 
responsible for clearing 'A' bit on 3.4 kernel. But on recent kernel, 
"restore_user_regs" macro seems no longer called for a kernel thread.

So, I tried the 'cps'instruction that does it! I re-worked slightly your 
previous patch.
I also noticed that secondary needs to be set separately.

Please, could you comment on the following patch ? (I can resend 
correctly formated patch if you wish) :

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index dc894ab..e22b109 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -378,6 +378,9 @@ asmlinkage void secondary_start_kernel(void)
         local_irq_enable();
         local_fiq_enable();

+       /* Enable imprecise aborts */
+       asm volatile("cpsie     a");
+
         /*
          * OK, it's off to the idle thread for us
          */
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 4636d56..a9567bb 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)

         flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
         modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
+
+       /* Enable imprecise aborts */
+       asm volatile("cpsie     a");
+
  #else /* ifndef CONFIG_CPU_V7M */
         /*
          * on V7-M there is no need to copy the vector table to a dedicated

Thanks,
BR,
Fabrice

On 02/03/2014 10:12 AM, Fabrice Gasnier wrote:
> Hi Russell,
>
> Thank you for your help.
> I just tried following patch on both 3.10 and above vanilla 3.13.1.
> Unfortunately, these instructions have no effect on the arm cpsr.
> I dumped regs right after msr instruction have been executed. It 
> remains untouched :
>
> Here is assembly from gdb:
>
>    0xc064a400 <+128>:    mov    r3, #256    ; 0x100
>    0xc064a404 <+132>:    mrs    r2, CPSR
>    0xc064a408 <+136>:    bic    r2, r2, r3
>    0xc064a40c <+140>:    msr    CPSR_c, r2
>
> CPSR.A bit is still set after these instructions : 0x600001d3
> Although, I see it has been cleared in r2: 0x600000d3
>
> Please advise.
> Thanks,
> BR,
> Fabrice
> On 01/31/2014 06:08 PM, Russell King - ARM Linux wrote:
>>> Is it possible to unmask imprecise data aborts earlier in the boot
>>> >process (e.g. before PCIe bus enumeration, when drivers are being 
>>> probed)
>>> >?
>> How about this patch?
>>
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index 172ee18ff124..b0ff06f49cd0 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -900,6 +900,15 @@ void __init early_trap_init(void *vectors_base)
>>         flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
>>       modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
>> +
>> +    /* Enable imprecise aborts */
>> +    asm volatile(
>> +        "mrs    %0, cpsr\n"
>> +    "    bic    %0, %0, %1\n"
>> +    "    msr    cpsr_c, %0"
>> +        : "=&r" (i)
>> +        : "r" (PSR_A_BIT));
>> +
>>   #else /* ifndef CONFIG_CPU_V7M */
>>       /*
>>        * on V7-M there is no need to copy the vector table to a 
>> dedicated
>

^ permalink raw reply related

* [PATCH 3/3] ARM: v7m: add trivial suspend support
From: Uwe Kleine-König @ 2014-02-03 16:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391445443-28971-1-git-send-email-u.kleine-koenig@pengutronix.de>

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e25419817791..41266af5dfc8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2270,7 +2270,7 @@ source "kernel/power/Kconfig"
 config ARCH_SUSPEND_POSSIBLE
 	depends on !ARCH_S5PC100
 	depends on CPU_ARM920T || CPU_ARM926T || CPU_FEROCEON || CPU_SA1100 || \
-		CPU_V6 || CPU_V6K || CPU_V7 || CPU_XSC3 || CPU_XSCALE || CPU_MOHAWK
+		CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M || CPU_XSC3 || CPU_XSCALE || CPU_MOHAWK
 	def_bool y
 
 config ARM_CPU_SUSPEND
-- 
1.8.5.3

^ permalink raw reply related

* [PATCH 2/3] ARM: show_regs: on v7-M there are no FIQs, different processor modes, ...
From: Uwe Kleine-König @ 2014-02-03 16:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391445443-28971-1-git-send-email-u.kleine-koenig@pengutronix.de>

no indication about irqs in PSR and only a single ISA. So skip the whole
decoding and just print the xPSR on v7-M.

Also mark two static variables as __maybe_unused to prevent the compiler
from emitting:

	arch/arm/kernel/process.c:51:20: warning: 'processor_modes' defined but not used [-Wunused-variable]
	arch/arm/kernel/process.c:58:20: warning: 'isa_modes' defined but not used [-Wunused-variable]

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/kernel/process.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 92f7b15dd221..204f7d273319 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -48,14 +48,14 @@ unsigned long __stack_chk_guard __read_mostly;
 EXPORT_SYMBOL(__stack_chk_guard);
 #endif
 
-static const char *processor_modes[] = {
+static const char *processor_modes[] __maybe_unused = {
   "USER_26", "FIQ_26" , "IRQ_26" , "SVC_26" , "UK4_26" , "UK5_26" , "UK6_26" , "UK7_26" ,
   "UK8_26" , "UK9_26" , "UK10_26", "UK11_26", "UK12_26", "UK13_26", "UK14_26", "UK15_26",
   "USER_32", "FIQ_32" , "IRQ_32" , "SVC_32" , "UK4_32" , "UK5_32" , "UK6_32" , "ABT_32" ,
   "UK8_32" , "UK9_32" , "UK10_32", "UND_32" , "UK12_32", "UK13_32", "UK14_32", "SYS_32"
 };
 
-static const char *isa_modes[] = {
+static const char *isa_modes[] __maybe_unused = {
   "ARM" , "Thumb" , "Jazelle", "ThumbEE"
 };
 
@@ -276,12 +276,17 @@ void __show_regs(struct pt_regs *regs)
 	buf[3] = flags & PSR_V_BIT ? 'V' : 'v';
 	buf[4] = '\0';
 
+#ifndef CONFIG_CPU_V7M
 	printk("Flags: %s  IRQs o%s  FIQs o%s  Mode %s  ISA %s  Segment %s\n",
 		buf, interrupts_enabled(regs) ? "n" : "ff",
 		fast_interrupts_enabled(regs) ? "n" : "ff",
 		processor_modes[processor_mode(regs)],
 		isa_modes[isa_mode(regs)],
 		get_fs() == get_ds() ? "kernel" : "user");
+#else
+	printk("xPSR: %08lx\n", regs->ARM_cpsr);
+#endif
+
 #ifdef CONFIG_CPU_CP15
 	{
 		unsigned int ctrl;
-- 
1.8.5.3

^ permalink raw reply related

* [PATCH 1/3] ARM: make isa_mode macro more robust and fix for v7-M
From: Uwe Kleine-König @ 2014-02-03 16:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391445443-28971-1-git-send-email-u.kleine-koenig@pengutronix.de>

The definition of isa_mode hardcodes the values to shift PSR_J_BIT and
PSR_T_BIT to move them to bits 1 and 0 respectively. Instead use __ffs to
calculate the shift from the #define already used for masking.

This is relevant on v7-M as there PSR_T_BIT is 0x01000000 instead of
0x00000020 for V7-[AR] and earlier. Because of that isa_mode produced
values >= 0x80000 which are unsuitable to index into isa_modes[4] there
and so made __show_regs read from undefined memory which resulted in
hangs and crashes.

Moreover isa_mode is wrong for v7-M even after this robustness fix as
there is no J-bit in the PSR register. So hardcode isa_mode to "Thumb"
for v7-M.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/include/asm/ptrace.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 04c99f36ff7f..627a03ebb987 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -27,9 +27,13 @@ struct pt_regs {
 #define thumb_mode(regs) (0)
 #endif
 
+#ifndef CONFIG_CPU_V7M
 #define isa_mode(regs) \
-	((((regs)->ARM_cpsr & PSR_J_BIT) >> 23) | \
-	 (((regs)->ARM_cpsr & PSR_T_BIT) >> 5))
+	((((regs)->ARM_cpsr & PSR_J_BIT) >> (__ffs(PSR_J_BIT) - 1)) | \
+	 (((regs)->ARM_cpsr & PSR_T_BIT) >> (__ffs(PSR_T_BIT))))
+#else
+#define isa_mode(regs) 1 /* Thumb */
+#endif
 
 #define processor_mode(regs) \
 	((regs)->ARM_cpsr & MODE_MASK)
-- 
1.8.5.3

^ permalink raw reply related

* [PATCH 0/3] ARM: v7m: updates for 3.15
From: Uwe Kleine-König @ 2014-02-03 16:37 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Russell,

I'd like these three patches to go in during the 3.15 merge window. The
first two were already send earlier on this list (Message-Id:
20131210212550.GF18888 at pengutronix.de), I only squashed in a fix for a format
warning and an unused variable warning into the 2nd. The third is a trivial
patch to allow power management on v7-M.

The series is available in my repository in the v7m branch:

	git://git.pengutronix.de/git/ukl/linux.git v7m

If you are ok with the changes, tell how you want them to pick up:
signed tag to pull, patch system, pull as is, ...

Also I wonder if you still have 7889/1 on your radar, I expected it to
go in for 3.14-rc1. Is it just -ENOTIME on your side, or do you have any
concerns?

Best regards
Uwe

Uwe Kleine-K?nig (3):
  ARM: make isa_mode macro more robust and fix for v7-M
  ARM: show_regs: on v7-M there are no FIQs, different processor modes,
    ...
  ARM: v7m: add trivial suspend support

 arch/arm/Kconfig              | 2 +-
 arch/arm/include/asm/ptrace.h | 8 ++++++--
 arch/arm/kernel/process.c     | 5 +++++
 3 files changed, 12 insertions(+), 3 deletions(-)

-- 
1.8.5.3

^ permalink raw reply

* [PATCH] clk: Fix notifier documentation
From: Sören Brinkmann @ 2014-02-03 16:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAPtuhTj7QmB-xFU40x_MCvbvo07M2_2sDfiOQNkf4oEGFPKiOg@mail.gmail.com>

On Fri, Jan 31, 2014 at 10:01:27PM -0800, Mike Turquette wrote:
> On Fri, Jan 31, 2014 at 5:49 PM, S?ren Brinkmann
> <soren.brinkmann@xilinx.com> wrote:
> > ping?
> 
> Hi Soren,
> 
> I'm a bit slow to review patches during the merge window. Thanks for
> the doc update. I'll take it in after -rc1 drops.

Sorry for my impatience. Thank you!

	S?ren

^ permalink raw reply

* [PATCH resend 1/2] arm64: defer reloading a task's FPSIMD state to userland resume
From: Will Deacon @ 2014-02-03 16:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391163196-27619-1-git-send-email-ard.biesheuvel@linaro.org>

Hi Ard,

On Fri, Jan 31, 2014 at 10:13:15AM +0000, Ard Biesheuvel wrote:
> If a task gets scheduled out and back in again and nothing has touched
> its FPSIMD state in the mean time, there is really no reason to reload
> it from memory. Similarly, repeated calls to kernel_neon_begin() and
> kernel_neon_end() will preserve and restore the FPSIMD state every time.
> 
> This patch defers the FPSIMD state restore to the last possible moment,
> i.e., right before the task re-enters userland. If a task does not enter
> userland at all (for any reason), the existing FPSIMD state is preserved
> and may be reused by the owning task if it gets scheduled in again on the
> same CPU.

The one situation I'm unsure of here is how you deal with the saved fpsimd
state potentially being updated by a signal handler or a debugger. In this
case, we probably need to set _TIF_FOREIGN_FPSTATE to force a reload, or are
you handling this some other way?

Will

^ permalink raw reply

* [PATCH v5 15/16] ARM: add uprobes support
From: Jon Medhurst (Tixy) @ 2014-02-03 16:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390507559-4697-16-git-send-email-dave.long@linaro.org>

On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
> From: "David A. Long" <dave.long@linaro.org>
> 
> Using Rabin Vincent's ARM uprobes patches as a base, enable uprobes
> support on ARM.
> 
> Caveats:
> 
>  - Thumb is not supported
> 
> Signed-off-by: David A. Long <dave.long@linaro.org>

As this is based on Rabin's work, and the new files have his Copyright,
then this patch also needs his 'Signed-off-by'. Rabin, I assume that you
agree?

I have no more comments about this patch, however I have included the
rest of the patch below so Rabin can see it's contents (in case he
doesn't still have the original)...


> ---
>  arch/arm/Kconfig                   |   4 +
>  arch/arm/include/asm/ptrace.h      |   6 +
>  arch/arm/include/asm/thread_info.h |   5 +-
>  arch/arm/include/asm/uprobes.h     |  45 ++++++++
>  arch/arm/kernel/Makefile           |   1 +
>  arch/arm/kernel/signal.c           |   4 +
>  arch/arm/kernel/uprobes-arm.c      | 231 +++++++++++++++++++++++++++++++++++++
>  arch/arm/kernel/uprobes.c          | 208 +++++++++++++++++++++++++++++++++
>  arch/arm/kernel/uprobes.h          |  35 ++++++
>  9 files changed, 538 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/uprobes.h
>  create mode 100644 arch/arm/kernel/uprobes-arm.c
>  create mode 100644 arch/arm/kernel/uprobes.c
>  create mode 100644 arch/arm/kernel/uprobes.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c1f1a7e..fec5a6b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -203,6 +203,10 @@ config ZONE_DMA
>  config NEED_DMA_MAP_STATE
>         def_bool y
>  
> +config ARCH_SUPPORTS_UPROBES
> +	depends on KPROBES
> +	def_bool y
> +
>  config ARCH_HAS_DMA_SET_COHERENT_MASK
>  	bool
>  
> diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
> index 04c99f3..ee688b0a 100644
> --- a/arch/arm/include/asm/ptrace.h
> +++ b/arch/arm/include/asm/ptrace.h
> @@ -80,6 +80,12 @@ static inline long regs_return_value(struct pt_regs *regs)
>  
>  #define instruction_pointer(regs)	(regs)->ARM_pc
>  
> +static inline void instruction_pointer_set(struct pt_regs *regs,
> +					   unsigned long val)
> +{
> +	instruction_pointer(regs) = val;
> +}
> +
>  #ifdef CONFIG_SMP
>  extern unsigned long profile_pc(struct pt_regs *regs);
>  #else
> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index 71a06b2..f989d7c 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -153,6 +153,7 @@ extern int vfp_restore_user_hwstate(struct user_vfp __user *,
>  #define TIF_SIGPENDING		0
>  #define TIF_NEED_RESCHED	1
>  #define TIF_NOTIFY_RESUME	2	/* callback before returning to user */
> +#define TIF_UPROBE		7
>  #define TIF_SYSCALL_TRACE	8
>  #define TIF_SYSCALL_AUDIT	9
>  #define TIF_SYSCALL_TRACEPOINT	10
> @@ -165,6 +166,7 @@ extern int vfp_restore_user_hwstate(struct user_vfp __user *,
>  #define _TIF_SIGPENDING		(1 << TIF_SIGPENDING)
>  #define _TIF_NEED_RESCHED	(1 << TIF_NEED_RESCHED)
>  #define _TIF_NOTIFY_RESUME	(1 << TIF_NOTIFY_RESUME)
> +#define _TIF_UPROBE		(1 << TIF_UPROBE)
>  #define _TIF_SYSCALL_TRACE	(1 << TIF_SYSCALL_TRACE)
>  #define _TIF_SYSCALL_AUDIT	(1 << TIF_SYSCALL_AUDIT)
>  #define _TIF_SYSCALL_TRACEPOINT	(1 << TIF_SYSCALL_TRACEPOINT)
> @@ -178,7 +180,8 @@ extern int vfp_restore_user_hwstate(struct user_vfp __user *,
>  /*
>   * Change these and you break ASM code in entry-common.S
>   */
> -#define _TIF_WORK_MASK		(_TIF_NEED_RESCHED | _TIF_SIGPENDING | _TIF_NOTIFY_RESUME)
> +#define _TIF_WORK_MASK		(_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
> +				 _TIF_NOTIFY_RESUME | _TIF_UPROBE)
>  
>  #endif /* __KERNEL__ */
>  #endif /* __ASM_ARM_THREAD_INFO_H */
> diff --git a/arch/arm/include/asm/uprobes.h b/arch/arm/include/asm/uprobes.h
> new file mode 100644
> index 0000000..9472c20
> --- /dev/null
> +++ b/arch/arm/include/asm/uprobes.h
> @@ -0,0 +1,45 @@
> +/*
> + * Copyright (C) 2012 Rabin Vincent <rabin@rab.in>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _ASM_UPROBES_H
> +#define _ASM_UPROBES_H
> +
> +#include <asm/probes.h>
> +#include <asm/opcodes.h>
> +
> +typedef u32 uprobe_opcode_t;
> +
> +#define MAX_UINSN_BYTES		4
> +#define UPROBE_XOL_SLOT_BYTES	64
> +
> +#define UPROBE_SWBP_ARM_INSN	0xe7f001f9
> +#define UPROBE_SS_ARM_INSN	0xe7f001fa
> +#define UPROBE_SWBP_INSN	__opcode_to_mem_arm(UPROBE_SWBP_ARM_INSN)
> +#define UPROBE_SWBP_INSN_SIZE	4
> +
> +struct arch_uprobe_task {
> +	u32 backup;
> +	unsigned long	saved_trap_no;
> +};
> +
> +struct arch_uprobe {
> +	u8 insn[MAX_UINSN_BYTES];
> +	unsigned long ixol[2];
> +	uprobe_opcode_t bpinsn;
> +	bool simulate;
> +	u32 pcreg;
> +	void (*prehandler)(struct arch_uprobe *auprobe,
> +			   struct arch_uprobe_task *autask,
> +			   struct pt_regs *regs);
> +	void (*posthandler)(struct arch_uprobe *auprobe,
> +			    struct arch_uprobe_task *autask,
> +			    struct pt_regs *regs);
> +	struct arch_probes_insn asi;
> +};
> +
> +#endif
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index bb739f2..a766bcb 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_DYNAMIC_FTRACE)	+= ftrace.o insn.o
>  obj-$(CONFIG_FUNCTION_GRAPH_TRACER)	+= ftrace.o insn.o
>  obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o insn.o patch.o
>  obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o
> +obj-$(CONFIG_UPROBES)		+= probes.o probes-arm.o uprobes.o uprobes-arm.o
>  obj-$(CONFIG_KPROBES)		+= probes.o kprobes.o kprobes-common.o patch.o
>  ifdef CONFIG_THUMB2_KERNEL
>  obj-$(CONFIG_KPROBES)		+= kprobes-thumb.o probes-thumb.o
> diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
> index 04d6388..bd19834 100644
> --- a/arch/arm/kernel/signal.c
> +++ b/arch/arm/kernel/signal.c
> @@ -13,6 +13,7 @@
>  #include <linux/personality.h>
>  #include <linux/uaccess.h>
>  #include <linux/tracehook.h>
> +#include <linux/uprobes.h>
>  
>  #include <asm/elf.h>
>  #include <asm/cacheflush.h>
> @@ -590,6 +591,9 @@ do_work_pending(struct pt_regs *regs, unsigned int thread_flags, int syscall)
>  					return restart;
>  				}
>  				syscall = 0;
> +			} else if (thread_flags & _TIF_UPROBE) {
> +				clear_thread_flag(TIF_UPROBE);
> +				uprobe_notify_resume(regs);
>  			} else {
>  				clear_thread_flag(TIF_NOTIFY_RESUME);
>  				tracehook_notify_resume(regs);
> diff --git a/arch/arm/kernel/uprobes-arm.c b/arch/arm/kernel/uprobes-arm.c
> new file mode 100644
> index 0000000..d5feb50
> --- /dev/null
> +++ b/arch/arm/kernel/uprobes-arm.c
> @@ -0,0 +1,231 @@
> +/*
> + * Copyright (C) 2012 Rabin Vincent <rabin@rab.in>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/wait.h>
> +#include <linux/uprobes.h>
> +#include <linux/module.h>
> +
> +#include "probes.h"
> +#include "probes-arm.h"
> +#include "uprobes.h"
> +
> +static int uprobes_substitute_pc(unsigned long *pinsn, u32 oregs)
> +{
> +	probes_opcode_t insn = __mem_to_opcode_arm(*pinsn);
> +	probes_opcode_t temp;
> +	probes_opcode_t mask;
> +	int freereg;
> +	u32 free = 0xffff;
> +	u32 regs;
> +
> +	for (regs = oregs; regs; regs >>= 4, insn >>= 4) {
> +		if ((regs & 0xf) == REG_TYPE_NONE)
> +			continue;
> +
> +		free &= ~(1 << (insn & 0xf));
> +	}
> +
> +	/* No PC, no problem */
> +	if (free & (1 << 15))
> +		return 15;
> +
> +	if (!free)
> +		return -1;
> +
> +	/*
> +	 * fls instead of ffs ensures that for "ldrd r0, r1, [pc]" we would
> +	 * pick LR instead of R1.
> +	 */
> +	freereg = free = fls(free) - 1;
> +
> +	temp = __mem_to_opcode_arm(*pinsn);
> +	insn = temp;
> +	regs = oregs;
> +	mask = 0xf;
> +
> +	for (; regs; regs >>= 4, mask <<= 4, free <<= 4, temp >>= 4) {
> +		if ((regs & 0xf) == REG_TYPE_NONE)
> +			continue;
> +
> +		if ((temp & 0xf) != 15)
> +			continue;
> +
> +		insn &= ~mask;
> +		insn |= free & mask;
> +	}
> +
> +	*pinsn = __opcode_to_mem_arm(insn);
> +	return freereg;
> +}
> +
> +static void uprobe_set_pc(struct arch_uprobe *auprobe,
> +			  struct arch_uprobe_task *autask,
> +			  struct pt_regs *regs)
> +{
> +	u32 pcreg = auprobe->pcreg;
> +
> +	autask->backup = regs->uregs[pcreg];
> +	regs->uregs[pcreg] = regs->ARM_pc + 8;
> +}
> +
> +static void uprobe_unset_pc(struct arch_uprobe *auprobe,
> +			    struct arch_uprobe_task *autask,
> +			    struct pt_regs *regs)
> +{
> +	/* PC will be taken care of by common code */
> +	regs->uregs[auprobe->pcreg] = autask->backup;
> +}
> +
> +static void uprobe_aluwrite_pc(struct arch_uprobe *auprobe,
> +			       struct arch_uprobe_task *autask,
> +			       struct pt_regs *regs)
> +{
> +	u32 pcreg = auprobe->pcreg;
> +
> +	alu_write_pc(regs->uregs[pcreg], regs);
> +	regs->uregs[pcreg] = autask->backup;
> +}
> +
> +static void uprobe_write_pc(struct arch_uprobe *auprobe,
> +			    struct arch_uprobe_task *autask,
> +			    struct pt_regs *regs)
> +{
> +	u32 pcreg = auprobe->pcreg;
> +
> +	load_write_pc(regs->uregs[pcreg], regs);
> +	regs->uregs[pcreg] = autask->backup;
> +}
> +
> +enum probes_insn
> +decode_pc_ro(probes_opcode_t insn, struct arch_probes_insn *asi,
> +	     struct decode_header *d)
> +{
> +	struct arch_uprobe *auprobe = container_of(asi, struct arch_uprobe,
> +						   asi);
> +	struct decode_emulate *decode = (struct decode_emulate *) d;
> +	u32 regs = decode->header.type_regs.bits >> DECODE_TYPE_BITS;
> +	int reg;
> +
> +	reg = uprobes_substitute_pc(&auprobe->ixol[0], regs);
> +	if (reg == 15)
> +		return INSN_GOOD;
> +
> +	if (reg == -1)
> +		return INSN_REJECTED;
> +
> +	auprobe->pcreg = reg;
> +	auprobe->prehandler = uprobe_set_pc;
> +	auprobe->posthandler = uprobe_unset_pc;
> +
> +	return INSN_GOOD;
> +}
> +
> +enum probes_insn
> +decode_wb_pc(probes_opcode_t insn, struct arch_probes_insn *asi,
> +	     struct decode_header *d, bool alu)
> +{
> +	struct arch_uprobe *auprobe = container_of(asi, struct arch_uprobe,
> +						   asi);
> +	enum probes_insn ret = decode_pc_ro(insn, asi, d);
> +
> +	if (((insn >> 12) & 0xf) == 15)
> +		auprobe->posthandler = alu ? uprobe_aluwrite_pc
> +					   : uprobe_write_pc;
> +
> +	return ret;
> +}
> +
> +enum probes_insn
> +decode_rd12rn16rm0rs8_rwflags(probes_opcode_t insn,
> +			      struct arch_probes_insn *asi,
> +			      struct decode_header *d)
> +{
> +	return decode_wb_pc(insn, asi, d, true);
> +}
> +
> +enum probes_insn
> +decode_ldr(probes_opcode_t insn, struct arch_probes_insn *asi,
> +	   struct decode_header *d)
> +{
> +	return decode_wb_pc(insn, asi, d, false);
> +}
> +
> +enum probes_insn
> +uprobe_decode_ldmstm(probes_opcode_t insn,
> +		     struct arch_probes_insn *asi, struct decode_header *d)
> +{
> +	struct arch_uprobe *auprobe = container_of(asi, struct arch_uprobe,
> +						   asi);
> +	unsigned reglist = insn & 0xffff;
> +	int rn = (insn >> 16) & 0xf;
> +	int lbit = insn & (1 << 20);
> +	unsigned used = reglist | (1 << rn);
> +
> +	if (rn == 15)
> +		return INSN_REJECTED;
> +
> +	if (!(used & (1 << 15)))
> +		return INSN_GOOD;
> +
> +	if (used & (1 << 14))
> +		return INSN_REJECTED;
> +
> +	/* Use LR instead of PC */
> +	insn ^= 0xc000;
> +
> +	auprobe->pcreg = 14;
> +	auprobe->ixol[0] = __opcode_to_mem_arm(insn);
> +
> +	auprobe->prehandler = uprobe_set_pc;
> +	if (lbit)
> +		auprobe->posthandler = uprobe_write_pc;
> +	else
> +		auprobe->posthandler = uprobe_unset_pc;
> +
> +	return INSN_GOOD;
> +}
> +
> +const union decode_action uprobes_probes_actions[] = {
> +	[PROBES_EMULATE_NONE] = {.handler = probes_simulate_nop},
> +	[PROBES_SIMULATE_NOP] = {.handler = probes_simulate_nop},
> +	[PROBES_PRELOAD_IMM] = {.handler = probes_simulate_nop},
> +	[PROBES_PRELOAD_REG] = {.handler = probes_simulate_nop},
> +	[PROBES_BRANCH_IMM] = {.handler = simulate_blx1},
> +	[PROBES_MRS] = {.handler = simulate_mrs},
> +	[PROBES_BRANCH_REG] = {.handler = simulate_blx2bx},
> +	[PROBES_CLZ] = {.handler = probes_simulate_nop},
> +	[PROBES_SATURATING_ARITHMETIC] = {.handler = probes_simulate_nop},
> +	[PROBES_MUL1] = {.handler = probes_simulate_nop},
> +	[PROBES_MUL2] = {.handler = probes_simulate_nop},
> +	[PROBES_SWP] = {.handler = probes_simulate_nop},
> +	[PROBES_LDRSTRD] = {.decoder = decode_pc_ro},
> +	[PROBES_LOAD_EXTRA] = {.decoder = decode_pc_ro},
> +	[PROBES_LOAD] = {.decoder = decode_ldr},
> +	[PROBES_STORE_EXTRA] = {.decoder = decode_pc_ro},
> +	[PROBES_STORE] = {.decoder = decode_pc_ro},
> +	[PROBES_MOV_IP_SP] = {.handler = simulate_mov_ipsp},
> +	[PROBES_DATA_PROCESSING_REG] = {
> +		.decoder = decode_rd12rn16rm0rs8_rwflags},
> +	[PROBES_DATA_PROCESSING_IMM] = {
> +		.decoder = decode_rd12rn16rm0rs8_rwflags},
> +	[PROBES_MOV_HALFWORD] = {.handler = probes_simulate_nop},
> +	[PROBES_SEV] = {.handler = probes_simulate_nop},
> +	[PROBES_WFE] = {.handler = probes_simulate_nop},
> +	[PROBES_SATURATE] = {.handler = probes_simulate_nop},
> +	[PROBES_REV] = {.handler = probes_simulate_nop},
> +	[PROBES_MMI] = {.handler = probes_simulate_nop},
> +	[PROBES_PACK] = {.handler = probes_simulate_nop},
> +	[PROBES_EXTEND] = {.handler = probes_simulate_nop},
> +	[PROBES_EXTEND_ADD] = {.handler = probes_simulate_nop},
> +	[PROBES_MUL_ADD_LONG] = {.handler = probes_simulate_nop},
> +	[PROBES_MUL_ADD] = {.handler = probes_simulate_nop},
> +	[PROBES_BITFIELD] = {.handler = probes_simulate_nop},
> +	[PROBES_BRANCH] = {.handler = simulate_bbl},
> +	[PROBES_LDMSTM] = {.decoder = uprobe_decode_ldmstm}
> +};
> diff --git a/arch/arm/kernel/uprobes.c b/arch/arm/kernel/uprobes.c
> new file mode 100644
> index 0000000..bfe08ba2
> --- /dev/null
> +++ b/arch/arm/kernel/uprobes.c
> @@ -0,0 +1,208 @@
> +/*
> + * Copyright (C) 2012 Rabin Vincent <rabin@rab.in>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/highmem.h>
> +#include <linux/sched.h>
> +#include <linux/uprobes.h>
> +#include <linux/notifier.h>
> +
> +#include <asm/opcodes.h>
> +#include <asm/traps.h>
> +
> +#include "probes.h"
> +#include "probes-arm.h"
> +#include "uprobes.h"
> +
> +#define UPROBE_TRAP_NR	UINT_MAX
> +
> +bool is_swbp_insn(uprobe_opcode_t *insn)
> +{
> +	return (__mem_to_opcode_arm(*insn) & 0x0fffffff) ==
> +		(UPROBE_SWBP_ARM_INSN & 0x0fffffff);
> +}
> +
> +int set_swbp(struct arch_uprobe *auprobe, struct mm_struct *mm,
> +	     unsigned long vaddr)
> +{
> +	return uprobe_write_opcode(mm, vaddr,
> +		   __opcode_to_mem_arm(auprobe->bpinsn));
> +}
> +
> +bool arch_uprobe_ignore(struct arch_uprobe *auprobe, struct pt_regs *regs)
> +{
> +	if (!auprobe->asi.insn_check_cc(regs->ARM_cpsr)) {
> +		regs->ARM_pc += 4;
> +		return true;
> +	}
> +
> +	return false;
> +}
> +
> +bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe, struct pt_regs *regs)
> +{
> +	probes_opcode_t opcode;
> +
> +	if (!auprobe->simulate)
> +		return false;
> +
> +	opcode = __mem_to_opcode_arm(*(unsigned int *) auprobe->insn);
> +
> +	auprobe->asi.insn_singlestep(opcode, &auprobe->asi, regs);
> +
> +	return true;
> +}
> +
> +unsigned long
> +arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
> +				  struct pt_regs *regs)
> +{
> +	unsigned long orig_ret_vaddr;
> +
> +	orig_ret_vaddr = regs->ARM_lr;
> +	/* Replace the return addr with trampoline addr */
> +	regs->ARM_lr = trampoline_vaddr;
> +	return orig_ret_vaddr;
> +}
> +
> +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct *mm,
> +			     unsigned long addr)
> +{
> +	unsigned int insn;
> +	unsigned int bpinsn;
> +	enum probes_insn ret;
> +
> +	/* Thumb not yet support */
> +	if (addr & 0x3)
> +		return -EINVAL;
> +
> +	insn = __mem_to_opcode_arm(*(unsigned int *)auprobe->insn);
> +	auprobe->ixol[0] = __opcode_to_mem_arm(insn);
> +	auprobe->ixol[1] = __opcode_to_mem_arm(UPROBE_SS_ARM_INSN);
> +
> +	ret = arm_probes_decode_insn(insn, &auprobe->asi, false,
> +				     uprobes_probes_actions);
> +	switch (ret) {
> +	case INSN_REJECTED:
> +		return -EINVAL;
> +
> +	case INSN_GOOD_NO_SLOT:
> +		auprobe->simulate = true;
> +		break;
> +
> +	case INSN_GOOD:
> +	default:
> +		break;
> +	}
> +
> +	bpinsn = UPROBE_SWBP_ARM_INSN & 0x0fffffff;
> +	if (insn >= 0xe0000000)
> +		bpinsn |= 0xe0000000;  /* Unconditional instruction */
> +	else
> +		bpinsn |= insn & 0xf0000000;  /* Copy condition from insn */
> +
> +	auprobe->bpinsn = bpinsn;
> +
> +	return 0;
> +}
> +
> +int arch_uprobe_pre_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
> +{
> +	struct uprobe_task *utask = current->utask;
> +
> +	if (auprobe->prehandler)
> +		auprobe->prehandler(auprobe, &utask->autask, regs);
> +
> +	utask->autask.saved_trap_no = current->thread.trap_no;
> +	current->thread.trap_no = UPROBE_TRAP_NR;
> +	regs->ARM_pc = utask->xol_vaddr;
> +
> +	return 0;
> +}
> +
> +int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
> +{
> +	struct uprobe_task *utask = current->utask;
> +
> +	WARN_ON_ONCE(current->thread.trap_no != UPROBE_TRAP_NR);
> +
> +	current->thread.trap_no = utask->autask.saved_trap_no;
> +	regs->ARM_pc = utask->vaddr + 4;
> +
> +	if (auprobe->posthandler)
> +		auprobe->posthandler(auprobe, &utask->autask, regs);
> +
> +	return 0;
> +}
> +
> +bool arch_uprobe_xol_was_trapped(struct task_struct *t)
> +{
> +	if (t->thread.trap_no != UPROBE_TRAP_NR)
> +		return true;
> +
> +	return false;
> +}
> +
> +void arch_uprobe_abort_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
> +{
> +	struct uprobe_task *utask = current->utask;
> +
> +	current->thread.trap_no = utask->autask.saved_trap_no;
> +	instruction_pointer_set(regs, utask->vaddr);
> +}
> +
> +int arch_uprobe_exception_notify(struct notifier_block *self,
> +				 unsigned long val, void *data)
> +{
> +	return NOTIFY_DONE;
> +}
> +
> +static int uprobe_trap_handler(struct pt_regs *regs, unsigned int instr)
> +{
> +	unsigned long flags;
> +
> +	local_irq_save(flags);
> +	instr &= 0x0fffffff;
> +	if (instr == (UPROBE_SWBP_ARM_INSN & 0x0fffffff))
> +		uprobe_pre_sstep_notifier(regs);
> +	else if (instr == (UPROBE_SS_ARM_INSN & 0x0fffffff))
> +		uprobe_post_sstep_notifier(regs);
> +	local_irq_restore(flags);
> +
> +	return 0;
> +}
> +
> +unsigned long uprobe_get_swbp_addr(struct pt_regs *regs)
> +{
> +	return instruction_pointer(regs);
> +}
> +
> +static struct undef_hook uprobes_arm_break_hook = {
> +	.instr_mask	= 0x0fffffff,
> +	.instr_val	= (UPROBE_SWBP_ARM_INSN & 0x0fffffff),
> +	.cpsr_mask	= MODE_MASK,
> +	.cpsr_val	= USR_MODE,
> +	.fn		= uprobe_trap_handler,
> +};
> +
> +static struct undef_hook uprobes_arm_ss_hook = {
> +	.instr_mask	= 0x0fffffff,
> +	.instr_val	= (UPROBE_SS_ARM_INSN & 0x0fffffff),
> +	.cpsr_mask	= MODE_MASK,
> +	.cpsr_val	= USR_MODE,
> +	.fn		= uprobe_trap_handler,
> +};
> +
> +static int arch_uprobes_init(void)
> +{
> +	register_undef_hook(&uprobes_arm_break_hook);
> +	register_undef_hook(&uprobes_arm_ss_hook);
> +
> +	return 0;
> +}
> +device_initcall(arch_uprobes_init);
> diff --git a/arch/arm/kernel/uprobes.h b/arch/arm/kernel/uprobes.h
> new file mode 100644
> index 0000000..a6581f5
> --- /dev/null
> +++ b/arch/arm/kernel/uprobes.h
> @@ -0,0 +1,35 @@
> +/*
> + * Copyright (C) 2012 Rabin Vincent <rabin@rab.in>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __ARM_KERNEL_UPROBES_H
> +#define __ARM_KERNEL_UPROBES_H
> +
> +enum probes_insn uprobe_decode_ldmstm(probes_opcode_t insn,
> +				      struct arch_probes_insn *asi,
> +				      struct decode_header *d);
> +
> +enum probes_insn decode_ldr(probes_opcode_t insn,
> +			    struct arch_probes_insn *asi,
> +			    struct decode_header *d);
> +
> +enum probes_insn
> +decode_rd12rn16rm0rs8_rwflags(probes_opcode_t insn,
> +			      struct arch_probes_insn *asi,
> +			      struct decode_header *d);
> +
> +enum probes_insn
> +decode_wb_pc(probes_opcode_t insn, struct arch_probes_insn *asi,
> +	     struct decode_header *d, bool alu);
> +
> +enum probes_insn
> +decode_pc_ro(probes_opcode_t insn, struct arch_probes_insn *asi,
> +	     struct decode_header *d);
> +
> +extern const union decode_action uprobes_probes_actions[];
> +
> +#endif

^ permalink raw reply

* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Daniel Lezcano @ 2014-02-03 16:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391348280-9484-1-git-send-email-maxime.ripard@free-electrons.com>

On 02/02/2014 02:37 PM, Maxime Ripard wrote:
> The Allwinner A10 compatibles were following a slightly different compatible
> patterns than the rest of the SoCs for historical reasons. Add compatibles
> matching the other pattern to the timer driver for consistency, and keep the
> older one for backward compatibility.

Hi Maxime,

is it really needed to keep the old pattern ?



> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>   Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt | 5 +++--
>   drivers/clocksource/sun4i_timer.c                                 | 4 ++++
>   2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> index 48aeb78..d9e35ae 100644
> --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> @@ -2,7 +2,8 @@ Allwinner A1X SoCs Timer Controller
>
>   Required properties:
>
> -- compatible : should be "allwinner,sun4i-timer"
> +- compatible : should be "allwinner,sun4i-a10-timer"
> +               (Deprecated "allwinner,sun4i-timer")
>   - reg : Specifies base physical address and size of the registers.
>   - interrupts : The interrupt of the first timer
>   - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
> @@ -10,7 +11,7 @@ Required properties:
>   Example:
>
>   timer {
> -	compatible = "allwinner,sun4i-timer";
> +	compatible = "allwinner,sun4i-a10-timer";
>   	reg = <0x01c20c00 0x400>;
>   	interrupts = <22>;
>   	clocks = <&osc>;
> diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
> index bf497af..de03895 100644
> --- a/drivers/clocksource/sun4i_timer.c
> +++ b/drivers/clocksource/sun4i_timer.c
> @@ -196,5 +196,9 @@ static void __init sun4i_timer_init(struct device_node *node)
>   	clockevents_config_and_register(&sun4i_clockevent, rate,
>   					TIMER_SYNC_TICKS, 0xffffffff);
>   }
> +CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
> +		       sun4i_timer_init);
> +
> +/* Deprecated */
>   CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
>   		       sun4i_timer_init);
>


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

^ permalink raw reply

* [PATCH RFC v4 00/10] ahci: library-ise ahci_platform, add sunxi driver and cleanup imx driver
From: Rob Herring @ 2014-02-03 16:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390236303-22538-1-git-send-email-hdegoede@redhat.com>

On Mon, Jan 20, 2014 at 10:44 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi All,
>
> Here is v4 of my patchset for adding ahci-sunxi support. It has grown quite
> a bit since I've been going for a more generic approach this time and I've
> also cleaned up the ahci-imx driver to use the same generic approach.

I don't know if you missed it or just don't intend to refactor all
AHCI drivers, but the highbank driver could benefit from this as well.

Rob

>
> History:
>
> v1, by Olliver Schinagl:
> This was using the approach of having a platform device which probe method
> creates a new child platform device which gets driven by ahci_platform.c,
> as done by ahci_imx.c .
>
> v2, by Hans de Goede:
> Stand-alone platform driver based on Olliver's work
>
> v3, by Hans de Goede:
> patch-series, with 4 different parts
> a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
>    regulator
> b) New ahci-sunxi code only populating ahci_platform_data, passed to
>    ahci_platform.c to of_device_id matching.
> c) Refactor ahci-imx code to work the same as the new ahci-sunxi code, this
>    is the reason why v3 is an RFC, I'm waiting for the wandboard I ordered to
>    arrive so that I can actually test this.
> d) dts bindings for the sunxi ahci parts
>
> v4, by Hans de Goede:
> patch-series, with 5 different parts:
> a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
>    regulator
> b) Turn parts of ahci_platform.c into a library for use by other drivers
> c) New ahci-sunxi driver using the ahci_platform.c library functionality
> d) Refactor ahci-imx code to work the same as the new ahci-sunxi code
> e) dts bindings for the sunxi ahci parts
>
> Parts a-d are intended for merging through the ata tree, the dts bindings
> will be merged to Maxime Ripard's sunxi-dts tree.
>
> Regards,
>
> Hans
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* iommu/arm-smmu: Regression (sleeping function called from invalid context)
From: Will Deacon @ 2014-02-03 16:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140131095809.GO13543@alberich>

Hi Andreas,

On Fri, Jan 31, 2014 at 09:58:09AM +0000, Andreas Herrmann wrote:
> On Fri, Jan 31, 2014 at 09:46:23AM +0100, Andreas Herrmann wrote:
> > On Fri, Jan 31, 2014 at 12:55:52AM +0100, Andreas Herrmann wrote:
> > > Hi Will,
> > > 
> > > Seems that commit a44a9791e778d9ccda50d5534028ed4057a9a45b
> > > (iommu/arm-smmu: use mutex instead of spinlock for locking page tables)
> > > introduced a regression.
> > > 
> > > At least I've hit
> > > 
> > >   BUG: scheduling while atomic: ksoftirqd/0/3/0x00000100
> > >...
> > 
> > >   BUG: sleeping function called from invalid context at mm/page_alloc.c:2679
> > >   in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
> > >   CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-00016-g6e90346 #413
> > >   [<c0014740>] (unwind_backtrace+0x0/0xf8) from [<c00115b0>] (show_stack+0x10/0x14)
> > >   [<c00115b0>] (show_stack+0x10/0x14) from [<c057ea24>] (dump_stack+0x74/0xa8)
> > >   [<c057ea24>] (dump_stack+0x74/0xa8) from [<c00acc1c>] (__alloc_pages_nodemask+0x174/0x930)
> > >   [<c00acc1c>] (__alloc_pages_nodemask+0x174/0x930) from [<c042a250>] (arm_smmu_handle_mapping+0x470/0x66c)
> > >   [<c042a250>] (arm_smmu_handle_mapping+0x470/0x66c) from [<c0428e74>] (iommu_map+0xf0/0x148)
> > >   [<c0428e74>] (iommu_map+0xf0/0x148) from [<c001935c>] (__map_sg_chunk+0x198/0x2d4)
> > >...
> > 
> > > Maybe that was the reason why the offending commit was introduced(?).

Right, there are two issues here:

  (1) If we use a spinlock to protect our page tables, we can perform a
      blocking allocation whilst holding the lock (during a ->map()
      callback)

  (2) Fixing this to use a mutex means that we can't ->map() in atomic
      context. I hadn't thought that was something we would be doing...

> > > I think with the current code "atomic allocations" should be used when
> > > IO page tables are created. With below patch I've not triggered above
> > > errors.
> > 
> > I think allocating memory with GFP_KERNEL in this dma-mapping path
> > doesn't seem to be a good idea. What if the DMA operation for which we
> > modify IO page tables was triggered to free pages (page cache, swap)?
> 
> I mean in case we run out of memory wouldn't we worsen the situation
> by triggering additional IO (and thus DMA)? Whereas when we let the
> mapping fail, the OS "just might have to wait a little bit" until
> other DMA activities are completed, pages unmapped and iova freed. The
> freed resources instantly can be used for further DMA activities.
> 
> Hmm, but maybe I need to rethink this (and look more closely into
> page_alloc.c).

The problem I see is that we don't want to use atomic allocations for
potentially large allocations, especially where there are cases where we're
not called in atomic context.

How do other IOMMU drivers deal with this? amd_iommu.c uses GFP_KERNEL for
its pte allocation in iommu_ops, but GFP_ATOMIC for its dma_ops.

Will

^ permalink raw reply

* a LLC sched domain bug for panda board?
From: Vincent Guittot @ 2014-02-03 16:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKfTPtDD9g6PPx=cDkbH2VDO0k1HDAjcxwxeW2YLXwL5T4d6NA@mail.gmail.com>

On 3 February 2014 17:27, Vincent Guittot <vincent.guittot@linaro.org> wrote:
> Have you checked that CONFIG_SCHED_LC is set ?

sorry it's CONFIG_SCHED_MC

>
>
> On 3 February 2014 17:17, Alex Shi <alex.shi@linaro.org> wrote:
>> I just run the 3.14-rc1 kernel on panda board. The only domain for it is
>> 'CPU' domain, but this domain has no SD_SHARE_PKG_RESOURCES setting, it
>> has no sd_llc.
>>
>> Guess the right domain for this board should be MC. So is it a bug?
>>
>> ..
>> /proc/sys/kernel/sched_domain/cpu0/domain0/name:CPU
>> ..
>> /proc/sys/kernel/sched_domain/cpu1/domain0/name:CPU
>>
>> --
>> Thanks
>>     Alex
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply

* a LLC sched domain bug for panda board?
From: Vincent Guittot @ 2014-02-03 16:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52EFC11A.8010709@linaro.org>

Have you checked that CONFIG_SCHED_LC is set ?


On 3 February 2014 17:17, Alex Shi <alex.shi@linaro.org> wrote:
> I just run the 3.14-rc1 kernel on panda board. The only domain for it is
> 'CPU' domain, but this domain has no SD_SHARE_PKG_RESOURCES setting, it
> has no sd_llc.
>
> Guess the right domain for this board should be MC. So is it a bug?
>
> ..
> /proc/sys/kernel/sched_domain/cpu0/domain0/name:CPU
> ..
> /proc/sys/kernel/sched_domain/cpu1/domain0/name:CPU
>
> --
> Thanks
>     Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply

* [PATCH v2 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Christoffer Dall @ 2014-02-03 16:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140203105409.GF30209@e106331-lin.cambridge.arm.com>

On Mon, Feb 03, 2014 at 10:54:09AM +0000, Mark Rutland wrote:
> On Thu, Jan 30, 2014 at 10:41:18AM +0000, Anup Patel wrote:
> > Currently, the in-kernel PSCI emulation provides PSCI v0.1 interface to
> > VCPUs. This patch extends current in-kernel PSCI emulation to provide
> > PSCI v0.2 interface to VCPUs.
> > 
> > By default, ARM/ARM64 KVM will always provide PSCI v0.1 interface for
> > keeping the ABI backward-compatible.
> > 
> > To select PSCI v0.2 interface for VCPUs, the user space (i.e. QEMU or
> > KVMTOOL) will have to set KVM_ARM_VCPU_PSCI_0_2 feature when doing VCPU
> > init using KVM_ARM_VCPU_INIT ioctl.
> 
> I have an issue with this. PSCI 0.2 makes all but two functions (MIGRATE
> and MIGRATE_INFO_CPU_UP) mandatory, and hence not allowed to return
> NOT_SUPPORTED.
> 
> Additionally, for correct behaviour across a kexec in future, we'll
> require AFFINITY_INFO for PSCI 0.2+ systems to determint when a CPU is
> actually dead (and cannot affect the cache hierarchy). I'd very much
> like to make that a hard requirement to ensure correctness.
> 
> I would very much like to see at least trivial implementations of those
> mandatory functions, so that we don't need a
> KVM_ARM_VCPU_PSCI_REALLY_0_2 or similar in future. As it stands this
> series does not implement PSCI 0.2.
> 
I didn't realize that PSCI 0.2 mandates more functions, that should
clearly be implemented first, and the patch series should also be
ordered with first supporting the implementation and then finally
exposing the functionality to user space.

Thanks,
-Christoffer

^ permalink raw reply

* [PATCH v4 2/5] arm: add new asm macro update_sctlr
From: Rob Herring @ 2014-02-03 16:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140203160051.GG14112@mudshark.cambridge.arm.com>

On Mon, Feb 3, 2014 at 10:00 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Feb 03, 2014 at 03:55:42PM +0000, Leif Lindholm wrote:
>> On Mon, Feb 03, 2014 at 10:34:15AM +0000, Will Deacon wrote:
>> > On Thu, Jan 30, 2014 at 01:12:47PM +0000, Leif Lindholm wrote:
>> > > Oh, that's neat - thanks!
>> > >
>> > > Well, given that, I can think of two less horrible options:
>> > > 1)
>> > >   .macro  update_sctlr, tmp:req, set=, clear=
>> > >         mrc       p15, 0, \tmp, c1, c0, 0
>> > >   .ifnc   \set,
>> > >         orr       \tmp, \set
>> > >   .endif
>> > >   .ifnc   \clear,
>> > >   mvn     \clear, \clear
>> > >   and     \tmp, \tmp, \clear
>> >
>> > Can't you use bic here?
>>
>> Yeah.
>>
>> > >   .endif
>> > >         mcr       p15, 0, \tmp, c1, c0, 0
>> > >   .endm
>> > >
>> > > With the two call sites in uefi_phys.S as:
>> > >
>> > >   ldr     r5, =(CR_M)
>> > >   update_sctlr    r12, , r5
>> > > and
>> > >   ldr     r4, =(CR_I | CR_C | CR_M)
>> > >   update_sctlr    r12, r4
>> >
>> > These ldr= could be movs, right?
>>
>> The first one could.
>> The second one could be movw on armv7+.
>>
>> > If so, I definitely prefer this to putting an ldr = into the macro itself
>> > (option 2).
>>
>> And your preference between 1) and 2) is?
>
> (1), using bic and mov[tw] where possible.

Using mov[tw] will break on V6 enabled builds.

Rob

^ permalink raw reply

* [PATCH 5/5] arm64: add Crypto Extensions based synchronous core AES cipher
From: Will Deacon @ 2014-02-03 16:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_NdVHawdVz3KUeZPHUL4ZPNSpeq7EWAgsVy+DfS6Kaqw@mail.gmail.com>

On Thu, Jan 30, 2014 at 07:20:38PM +0000, Ard Biesheuvel wrote:
> On 30 January 2014 19:56, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Jan 29, 2014 at 04:50:46PM +0000, Ard Biesheuvel wrote:
> >> +static void aes_cipher_encrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
> >> +{
> >> +     struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
> >> +     u32 rounds = 6 + ctx->key_length / 4;
> >
> > Can you document these constants please?
> >
> 
> Sure.

Thanks.

> >> +
> >> +     kernel_neon_begin();
> >> +
> >> +     __asm__("       ld1             {v0.16b}, [%[in]]               ;"
> >> +             "       ld1             {v1.16b}, [%[key]], #16         ;"
> >> +             "0:     aese            v0.16b, v1.16b                  ;"
> >> +             "       subs            %[rounds], %[rounds], #1        ;"
> >> +             "       ld1             {v1.16b}, [%[key]], #16         ;"
> >> +             "       beq             1f                              ;"
> >> +             "       aesmc           v0.16b, v0.16b                  ;"
> >> +             "       b               0b                              ;"
> >> +             "1:     eor             v0.16b, v0.16b, v1.16b          ;"
> >> +             "       st1             {v0.16b}, [%[out]]              ;"
> >> +     : :
> >> +             [out]           "r"(dst),
> >> +             [in]            "r"(src),
> >> +             [rounds]        "r"(rounds),
> >> +             [key]           "r"(ctx->key_enc)
> >> +     :                       "cc");
> >
> > You probably need a memory output to stop this being re-ordered by the
> > compiler. Can GCC not generate the addressing modes you need directly,
> > allowing you to avoid moving everything into registers?
> >
> 
> Would a memory clobber work as well?

It would, but it could lead to suboptimal code generation by GCC (although
neon_{begin,end} may well stop GCC in its tracks anyway, so worth looking at
the disassembly).

> Re addressing modes: I would prefer to explicitly use v0 and v1, I
> have another patch pending that allows partial saves/restores of the
> NEON register file when called from interrupt context. I suppose I
> could use 'register asm("v0")' or something like that, but that won't
> make it any prettier.

It's not the use of v0/v1 that I was objecting to. I was hoping that we
could describe [in] and [out] as memory operands, so that GCC could
potentially reduce register usage for base + offset style addressing modes.
Unfortunately, I don't think we have such a constraint for AArch64 :(

If the disassembly looks ok, the "memory" clobber is probably our best bet.

Will

^ permalink raw reply

* a LLC sched domain bug for panda board?
From: Alex Shi @ 2014-02-03 16:17 UTC (permalink / raw)
  To: linux-arm-kernel

I just run the 3.14-rc1 kernel on panda board. The only domain for it is
'CPU' domain, but this domain has no SD_SHARE_PKG_RESOURCES setting, it
has no sd_llc.

Guess the right domain for this board should be MC. So is it a bug?

..
/proc/sys/kernel/sched_domain/cpu0/domain0/name:CPU
..
/proc/sys/kernel/sched_domain/cpu1/domain0/name:CPU

-- 
Thanks
    Alex

^ permalink raw reply

* [PATCH v5 00/14] ahci: library-ise ahci_platform, add sunxi driver and cleanup imx driver
From: Tejun Heo @ 2014-02-03 16:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390417489-5354-1-git-send-email-hdegoede@redhat.com>

Hello,

On Wed, Jan 22, 2014 at 08:04:35PM +0100, Hans de Goede wrote:
> Here is v4 of my patchset for adding ahci-sunxi support. It has grown quite
> a bit since I've been going for a more generic approach this time and I've
> also cleaned up the ahci-imx driver to use the same generic approach.

On top of which tree were these patches generated?  They don't apply
to 3.14-rc1.

Thanks.

-- 
tejun

^ permalink raw reply

* [PATCH v2 1/6] audit: Enable arm64 support
From: Richard Guy Briggs @ 2014-02-03 16:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52EF304F.80202@linaro.org>

On 14/02/03, AKASHI Takahiro wrote:
> Richard,

Takahiro,

> On 01/30/2014 07:36 AM, Richard Guy Briggs wrote:
> >On 14/01/29, Richard Guy Briggs wrote:
> >>On 14/01/27, AKASHI Takahiro wrote:
> >>>[To audit maintainers]
> >>>
> >>>On 01/23/2014 11:18 PM, Catalin Marinas wrote:
> >>>>On Fri, Jan 17, 2014 at 08:13:14AM +0000, AKASHI Takahiro wrote:
> >>>>>--- a/include/uapi/linux/audit.h
> >>>>>+++ b/include/uapi/linux/audit.h
> >>>>>@@ -327,6 +327,8 @@ enum {
> >>>>>  /* distinguish syscall tables */
> >>>>>  #define __AUDIT_ARCH_64BIT 0x80000000
> >>>>>  #define __AUDIT_ARCH_LE	   0x40000000
> >>>>>+#define AUDIT_ARCH_AARCH64	(EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> >>>>>+#define AUDIT_ARCH_AARCH64EB	(EM_AARCH64|__AUDIT_ARCH_64BIT)
> >>>>>  #define AUDIT_ARCH_ALPHA	(EM_ALPHA|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> >>>>>  #define AUDIT_ARCH_ARM		(EM_ARM|__AUDIT_ARCH_LE)
> >>>>>  #define AUDIT_ARCH_ARMEB	(EM_ARM)
> >>>>>diff --git a/init/Kconfig b/init/Kconfig
> >>>>>index 79383d3..3aae602 100644
> >>>>>--- a/init/Kconfig
> >>>>>+++ b/init/Kconfig
> >>>>>@@ -284,7 +284,7 @@ config AUDIT
> >>>>>
> >>>>>  config AUDITSYSCALL
> >>>>>  	bool "Enable system-call auditing support"
> >>>>>-	depends on AUDIT && (X86 || PARISC || PPC || S390 || IA64 || UML || SPARC64 || SUPERH || (ARM && AEABI && !OABI_COMPAT))
> >>>>>+	depends on AUDIT && (X86 || PARISC || PPC || S390 || IA64 || UML || SPARC64 || SUPERH || (ARM && AEABI && !OABI_COMPAT) || ARM64)
> >>>>
> >>>>The usual comment for such changes: could you please clean this up and
> >>>>just use something like "depends on HAVE_ARCH_AUDITSYSCALL"?
> >>>
> >>>Do you agree to this change?
> >>>
> >>>If so, I can create a patch, but have some concerns:
> >>>1) I can't verify it on other architectures than (arm &) arm64.
> >>>2) Some architectures (microblaze, mips, openrisc) are not listed here, but
> >>>    their ptrace.c have a call to audit_syscall_entry/exit().
> >>>    (audit_syscall_entry/exit are null if !AUDITSYSCALL, though)
> >>
> >>I can try: ppc s390 x86_64 ppc64 i686 s390x
> >
> >These arches above all pass compile and basic tests with the following patches applied:
> >
> >	audit: correct a type mismatch in audit_syscall_exit() pending (already upstream)
> >
> >	audit: Modify a set of system calls in audit class definitions (already upstream)
> >
> >	[PATCH v3] audit: Add generic compat syscall support
> >
> >	[PATCH v2] audit: Enable arm64 support
> >	[PATCH v2] arm64: Add regs_return_value() in syscall.h
> >	[PATCH v2] arm64: Add audit support
> >	[PATCH v2] arm64: audit: Add 32-bit (compat) syscall support
> >	[PATCH v2] arm64: audit: Add makefile rule to create unistd_32.h for compat syscalls
> >	[PATCH v2] arm64: audit: Add audit hook in ptrace/syscall_trace
> 
> I think that you missed Catalin's suggestion.

I didn't miss his suggestions.  I think they are a good way to go, but I
wanted to make a test at referrable point in time to validate the work
to that point and to avoid introducing errors by mis-interpreting ideas
that were not yet fully-formed patches.

> Please use the patch I will post after this message and try it again, please?

I was certainly intending to do so.

> Thanks,
> -Takahiro AKASHI
> 
> >>>So I'm afraid that the change might break someone's assumption.
> >>>
> >>>Thanks,
> >>>-Takahiro AKASHI
> >>
> >>- RGB
> >
> >- RGB
> >
> >--
> >Richard Guy Briggs <rbriggs@redhat.com>
> >Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
> >Remote, Ottawa, Canada
> >Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> >

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

^ permalink raw reply

* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Thomas Abraham @ 2014-02-03 16:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140201041051.9977.46568@quantum>

On Sat, Feb 1, 2014 at 9:40 AM, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Heiko St?bner (2014-01-30 07:09:04)
>> On Thursday, 30. January 2014 18:23:44 Thomas Abraham wrote:
>> > Hi Mike,
>> >
>> > On Wed, Jan 29, 2014 at 12:17 AM, Mike Turquette <mturquette@linaro.org>
>> wrote:
>> > > On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham <ta.omasab@gmail.com>
>> wrote:
>> > >> Hi Mike,
>> > >>
>> > >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette <mturquette@linaro.org>
>> wrote:
>> > >>> Quoting Thomas Abraham (2014-01-18 04:10:51)
>> > >>>
>> > > As far as I can tell
>> > > the remux does not happen because it is necessary to generate the
>> > > required clock rate, but because we don't want to run the ARM core out
>> > > of spec for a short time while the PLL relocks. Assuming I have that
>> > > part of it right, I prefer for the parent mux operation to be a part
>> > > of the CPUfreq driver's .target callback instead of hidden away in the
>> > > clock driver.
>> >
>> > The re-parenting is mostly done to keep the ARM CPU clocked while the
>> > PLL is stopped, reprogrammed and restarted. One of the side effects of
>> > that is, the clock speed of the temporary parent could be higher then
>> > what is allowed due to the ARM voltage at the time of re-parenting.
>> > That is the reason to use the safe voltage.
>>
>> The Rockchip-SoCs use something similar, so I'm following quite closely what
>> Thomas is trying to do here, as similar solution would also solve this issue
>> for me.
>>
>> On some Rockchip-SoCs even stuff like pclk and hclk seems to be sourced from
>> the divided armclk, creating additional constraints.
>>
>> But on the RKs (at least in the upstream sources) the armclk is simply equal
>> to the pll output. A divider exists, but is only used to make sure that the
>> armclk stays below the original rate when sourced from the temp-parent, like
>>
>>         if (clk_get_rate(temp_parent) > clk_get_rate(main_parent)
>>                 set_divider(something so that rate(temp) <= rate(main)
>>         clk_set_parent(...)
>>
>> Isn't there a similar possiblity on your platform, as it would remove the need
>> for the safe-voltage?
>>
>>
>> In general I also like the approach of hiding the rate-change logic inside
>> this composite clock, as the depending clocks can be easily kept in sync. As
>> with the Rockchips the depending clocks are different for each of the three
>> Cortex-A9 SoCs I looked at, it would be "interesting" if all of this would
>> need to be done in a cpufreq driver.
>
> I wonder if hiding these details inside of the composite clock
> implementation indicates the lack of some needed feature in the clk
> core? I've discussed the idea of "coordinated rate changes" before. E.g:
>
> _________________________________________________________
> |  clk  |  opp-low      |  opp-mid      |  opp-fast     |
> |       |               |               |               |
> |pll    | 300000        |  600000       |  600000       |
> |       |               |               |               |
> |div    | 150000        |  300000       |  600000       |
> |       |               |               |               |
> |mpu_clk| 150000        |  300000       |  600000       |
> |       |               |               |               |
> |periph | 150000        |  150000       |  300000       |
> ---------------------------------------------------------
>
> A call to clk_set_rate() against any of those clocks will result in all
> of their dividers being updated. At the implementation level this might
> look something like this extremely simplified pseudocode:
>
> int clk_set_rate(struct clk* clk, unsigned long rate)
> {
>         /* trap clks that support coordinated rate changes */
>         if (clk->ops->coordinate_rate)
>                 return clk->ops->coordinate_rate(clk->hw, rate);
>         ...
> }
>
> and,
>
> struct coord_rates {
>         struct clk_hw *hw;
>         struct clk *parent;
>         struct clk *rate;
> };
>
> and in the clock driver,
>
> #define PLL 0
> #define DIV 1
> #define MPU 2
> #define PER 3
>
> #define NR_OPP 4
> #define NR_CLK 4
>
> struct coord_rates my_opps[NR_OPP][NR_CLK]; // populated from DT data
>
> int my_coordinate_rate_callback(struct clk_hw *hw, unsigned long rate)
> {
>         struct coord_rate **selected_opp;
>
>         for(i = 0; i < NR_OPP; i++) {
>                 for(j = 0; j < NR_CLK; j++) {
>                         if (my_opps[i][j]->hw == hw &&
>                                 my_opps[i][j]->rate == rate)
>                                 selected_opp = my_opps[i];
>                                 break;
>                 }
>         }
>
>         /*
>          * order of operations is specific to my hardware and should be
>          * managed by my clock driver, not generic code
>          */
>
>         __clk_set_parent(selected_opp[DIV]->hw, temp_parent);
>         __clk_set_rate(selected_opp[PLL]->hw, selected_opp[PLL]->rate);
>         __clk_set_parent(selected_opp[DIV]->hw,
>                                 selected_opp[PLL]->hw->clk);
>         ...
>
>         /*
>          * note that the above could be handled by a switch-case or
>          * something else
>          */
> }
>
> Thoughts? Please forgive any gaps in my logic or abuse of C.
>
> I have long thought that something like the above would someday go into
> a generic dvfs layer instead of the clock framework, but maybe starting
> with the clk framework makes more sense?

Hi Mike,

Yes, this will be very helpful for atomically controlling the rates of
a group of clocks. This coordinated rate change method can be used
during the armclk rate changes on Samsung platforms.

Thanks,
Thomas.

>
> Regards,
> Mike
>
>>
>>
>> Heiko
>>

^ permalink raw reply

* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Thomas Abraham @ 2014-02-03 16:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2009408.gnUEcoqA3p@phil>

On Thu, Jan 30, 2014 at 8:39 PM, Heiko St?bner <heiko@sntech.de> wrote:
> On Thursday, 30. January 2014 18:23:44 Thomas Abraham wrote:
>> Hi Mike,
>>
>> On Wed, Jan 29, 2014 at 12:17 AM, Mike Turquette <mturquette@linaro.org>
> wrote:
>> > On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham <ta.omasab@gmail.com>
> wrote:
>> >> Hi Mike,
>> >>
>> >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette <mturquette@linaro.org>
> wrote:
>> >>> Quoting Thomas Abraham (2014-01-18 04:10:51)
>> >>>
>> > As far as I can tell
>> > the remux does not happen because it is necessary to generate the
>> > required clock rate, but because we don't want to run the ARM core out
>> > of spec for a short time while the PLL relocks. Assuming I have that
>> > part of it right, I prefer for the parent mux operation to be a part
>> > of the CPUfreq driver's .target callback instead of hidden away in the
>> > clock driver.
>>
>> The re-parenting is mostly done to keep the ARM CPU clocked while the
>> PLL is stopped, reprogrammed and restarted. One of the side effects of
>> that is, the clock speed of the temporary parent could be higher then
>> what is allowed due to the ARM voltage at the time of re-parenting.
>> That is the reason to use the safe voltage.
>
> The Rockchip-SoCs use something similar, so I'm following quite closely what
> Thomas is trying to do here, as similar solution would also solve this issue
> for me.
>
> On some Rockchip-SoCs even stuff like pclk and hclk seems to be sourced from
> the divided armclk, creating additional constraints.
>
> But on the RKs (at least in the upstream sources) the armclk is simply equal
> to the pll output. A divider exists, but is only used to make sure that the
> armclk stays below the original rate when sourced from the temp-parent, like
>
>         if (clk_get_rate(temp_parent) > clk_get_rate(main_parent)
>                 set_divider(something so that rate(temp) <= rate(main)
>         clk_set_parent(...)
>
> Isn't there a similar possiblity on your platform, as it would remove the need
> for the safe-voltage?

Hi Heiko,

Yes, this works too! I have tested this method on Exynos4210,
Exynos4412 and Exynos5250 and it works fine without any need for safe
voltage. This is much better than using safe voltage. Thank you for
suggesting this.

Regards,
Thomas.

>
>
> In general I also like the approach of hiding the rate-change logic inside
> this composite clock, as the depending clocks can be easily kept in sync. As
> with the Rockchips the depending clocks are different for each of the three
> Cortex-A9 SoCs I looked at, it would be "interesting" if all of this would
> need to be done in a cpufreq driver.
>
>
> Heiko
>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox