Re: [PATCH 3/3] ARM: Work around faulty ISAR0 register in some Krait CPUs
On 03/17/13 07:28, Will Deacon wrote: > On Wed, Mar 13, 2013 at 01:32:01AM +0000, Stephen Boyd wrote: >> Some early versions of the Krait CPU design incorrectly indicate >> that they only support the UDIV and SDIV instructions in Thumb >> mode when they actually support them in ARM and Thumb mode. It >> seems that these CPUs follow the DDI0406B ARM ARM which has two >> possible values for the divide instructions field, instead of the >> DDI0406C document which has three possible values. >> >> Work around this problem by checking the MIDR against Krait CPUs >> with this faulty ISAR0 register and force the detection code >> to indicate support in both modes. >> >> Cc: Will Deacon >> Cc: Stepan Moskovchenko >> Signed-off-by: Stephen Boyd >> --- >> arch/arm/kernel/setup.c | 8 >> 1 file changed, 8 insertions(+) > After all this, you might as well just pass the relevant HWCAPs for your > krait entry in proc-v7.S rather than have an exception in the CPU-agnostic > code. Ok. Care to ack the previous patch I sent then? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: Detect support for SDIV/UDIV from ISAR0 register
On 03/17/13 07:36, Will Deacon wrote:
> On Wed, Mar 13, 2013 at 01:32:00AM +0000, Stephen Boyd wrote:
>> The ISAR0 register indicates support for the SDIV and UDIV
>> instructions in both the Thumb and ARM instruction set. Read the
>> register to detect the supported instructions and update the
>> elf_hwcap mask as appropriate. This is better than adding more
>> and more cpuid checks in proc-v7.S for each new cpu variant that
>> supports these instructions.
>>
>> Cc: Will Deacon
>> Cc: Stepan Moskovchenko
>> Signed-off-by: Stephen Boyd
>> ---
>> arch/arm/kernel/setup.c | 20
>> arch/arm/mm/proc-v7.S | 4 ++--
>> 2 files changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index e2c8bbf..bd27a70 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -353,6 +353,23 @@ void __init early_print(const char *str, ...)
>> printk("%s", buf);
>> }
>>
>> +static void __init idiv_setup(void)
>> +{
>> +unsigned int divide_instrs;
>> +
>> +if (cpu_architecture() < CPU_ARCH_ARMv7)
>> +return;
>> +
>> +divide_instrs = (read_cpuid_ext(CPUID_EXT_ISAR0) & 0x0f00) >> 24;
>> +
>> +switch (divide_instrs) {
>> +case 2:
>> +elf_hwcap |= HWCAP_IDIVA;
>> +case 1:
>> +elf_hwcap |= HWCAP_IDIVT;
>> +}
>> +}
>> +
>> static void __init feat_v6_fixup(void)
>> {
>> int id = read_cpuid_id();
>> @@ -483,6 +500,9 @@ static void __init setup_processor(void)
>> snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c",
>> list->elf_name, ENDIANNESS);
>> elf_hwcap = list->elf_hwcap;
>> +
>> +idiv_setup();
> Perhaps give this a more generic name (cpuid_init_hwcaps) so we can add more
> probing later on (we could probe swp, for example).
No problem. Thanks for the review.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 0/3] Detect UDIV/SDIV support from ISAR0
While attempting to upstream a patch to add the IDIV hwcap for Krait processors, Will suggested we move the code to read the ISAR0 register. This patchset does that and also works around the early Krait CPU designs that don't follow the latest ARM ARM for the ISAR0 register. Stepan Moskovchenko (1): ARM: Work around faulty ISAR0 register in some Krait CPUs Stephen Boyd (2): ARM: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n ARM: Detect support for SDIV/UDIV from ISAR0 register arch/arm/kernel/setup.c | 22 +- arch/arm/mm/proc-v7.S | 19 +-- 2 files changed, 38 insertions(+), 3 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 1/3] ARM: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n
Don't advertise support for the SDIV/UDIV thumb instructions if the kernel is not compiled with support for thumb userspace. This is in line with how we remove the THUMB hwcap in these configurations. Acked-by: Will Deacon Cc: Stepan Moskovchenko Signed-off-by: Stephen Boyd --- arch/arm/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 3f6cbb2..e2c8bbf 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -484,7 +484,7 @@ static void __init setup_processor(void) list->elf_name, ENDIANNESS); elf_hwcap = list->elf_hwcap; #ifndef CONFIG_ARM_THUMB - elf_hwcap &= ~HWCAP_THUMB; + elf_hwcap &= ~(HWCAP_THUMB | HWCAP_IDIVT); #endif feat_v6_fixup(); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 2/3] ARM: Detect support for SDIV/UDIV from ISAR0 register
The ISAR0 register indicates support for the SDIV and UDIV
instructions in both the Thumb and ARM instruction set. Read the
register to detect the supported instructions and update the
elf_hwcap mask as appropriate. This is better than adding more
and more cpuid checks in proc-v7.S for each new cpu variant that
supports these instructions.
Acked-by: Will Deacon
Cc: Stepan Moskovchenko
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/setup.c | 20
arch/arm/mm/proc-v7.S | 4 ++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e2c8bbf..f3ac13f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -353,6 +353,23 @@ void __init early_print(const char *str, ...)
printk("%s", buf);
}
+static void __init cpuid_init_hwcaps(void)
+{
+ unsigned int divide_instrs;
+
+ if (cpu_architecture() < CPU_ARCH_ARMv7)
+ return;
+
+ divide_instrs = (read_cpuid_ext(CPUID_EXT_ISAR0) & 0x0f00) >> 24;
+
+ switch (divide_instrs) {
+ case 2:
+ elf_hwcap |= HWCAP_IDIVA;
+ case 1:
+ elf_hwcap |= HWCAP_IDIVT;
+ }
+}
+
static void __init feat_v6_fixup(void)
{
int id = read_cpuid_id();
@@ -483,6 +500,9 @@ static void __init setup_processor(void)
snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c",
list->elf_name, ENDIANNESS);
elf_hwcap = list->elf_hwcap;
+
+ cpuid_init_hwcaps();
+
#ifndef CONFIG_ARM_THUMB
elf_hwcap &= ~(HWCAP_THUMB | HWCAP_IDIVT);
#endif
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3a3c015..bcd3d48 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -420,7 +420,7 @@ __v7_pj4b_proc_info:
__v7_ca7mp_proc_info:
.long 0x410fc070
.long 0xff00
- __v7_proc __v7_ca7mp_setup, hwcaps = HWCAP_IDIV
+ __v7_proc __v7_ca7mp_setup
.size __v7_ca7mp_proc_info, . - __v7_ca7mp_proc_info
/*
@@ -430,7 +430,7 @@ __v7_ca7mp_proc_info:
__v7_ca15mp_proc_info:
.long 0x410fc0f0
.long 0xff00
- __v7_proc __v7_ca15mp_setup, hwcaps = HWCAP_IDIV
+ __v7_proc __v7_ca15mp_setup
.size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
/*
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 3/3] ARM: Work around faulty ISAR0 register in some Krait CPUs
From: Stepan Moskovchenko Some early versions of the Krait CPU design incorrectly indicate that they only support the UDIV and SDIV instructions in Thumb mode when they actually support them in ARM and Thumb mode. It seems that these CPUs follow the DDI0406B ARM ARM which has two possible values for the divide instructions field, instead of the DDI0406C document which has three possible values. Work around this problem by checking the MIDR against Krait CPUs with this faulty ISAR0 register and force the hwcaps to indicate support in both modes. Cc: Will Deacon Signed-off-by: Stepan Moskovchenko [sboyd: Rewrote commit text to reflect real reasoning now that we autodetect udiv/sdiv] Signed-off-by: Stephen Boyd --- arch/arm/mm/proc-v7.S | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index bcd3d48..f584d3f 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -434,6 +434,21 @@ __v7_ca15mp_proc_info: .size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info /* +* Qualcomm Inc. Krait processors. +*/ + .type __krait_proc_info, #object +__krait_proc_info: + .long 0x510f0400 @ Required ID value + .long 0xff0ffc00 @ Mask for ID + /* +* Some Krait processors don't indicate support for SDIV and UDIV +* instructions in the ARM instruction set, even though they actually +* do support them. +*/ + __v7_proc __v7_setup, hwcaps = HWCAP_IDIV + .size __krait_proc_info, . - __krait_proc_info + + /* * Match any ARMv7 processor core. */ .type __v7_proc_info, #object -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 3/3] ARM: Work around faulty ISAR0 register in some Krait CPUs
On 03/18/13 11:34, Will Deacon wrote: > On Mon, Mar 18, 2013 at 06:28:57PM +0000, Stephen Boyd wrote: >> From: Stepan Moskovchenko >> >> Some early versions of the Krait CPU design incorrectly indicate >> that they only support the UDIV and SDIV instructions in Thumb >> mode when they actually support them in ARM and Thumb mode. It >> seems that these CPUs follow the DDI0406B ARM ARM which has two >> possible values for the divide instructions field, instead of the >> DDI0406C document which has three possible values. >> >> Work around this problem by checking the MIDR against Krait CPUs >> with this faulty ISAR0 register and force the hwcaps to indicate >> support in both modes. >> >> Cc: Will Deacon >> Signed-off-by: Stepan Moskovchenko >> [sboyd: Rewrote commit text to reflect real reasoning now that >> we autodetect udiv/sdiv] >> Signed-off-by: Stephen Boyd >> --- >> arch/arm/mm/proc-v7.S | 15 +++ >> 1 file changed, 15 insertions(+) > Acked-by: Will Deacon > Thanks. Put all three in the patch tracker. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] irqchip: gic: fix irq_trigger return
From: Abhijeet Dharmapurikar The genirq layer expects a 0 in case of failure but the code is returning -ENXIO. Fix it. Signed-off-by: Abhijeet Dharmapurikar Signed-off-by: Stephen Boyd --- drivers/irqchip/irq-gic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 644d724..2ebf28a 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -236,7 +236,8 @@ static int gic_retrigger(struct irq_data *d) if (gic_arch_extn.irq_retrigger) return gic_arch_extn.irq_retrigger(d); - return -ENXIO; + /* the genirq layer expects 0 for a failure */ + return 0; } #ifdef CONFIG_SMP -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 09/10] clocksource: time-armada-370-xp: Divorce from local timer API
On 03/20/13 10:09, Gregory CLEMENT wrote: > On 03/13/2013 07:17 PM, Stephen Boyd wrote: >> Separate the armada 370xp local timers from the local timer API. >> This will allow us to remove ARM local timer support in the near >> future and makes this driver multi-architecture friendly. > At first view the code looks good, but when I applied your patch set on > linux-next, build it and run it on a Armada XP based board (AX3 with 2 cores), > it crashed: [...] > Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > Modules linked in: > CPU: 0Not tainted (3.9.0-rc3-next-20130319-00010-g728b448 #153) > PC is at 0xe92d45f0 > LR is at armada_370_xp_timer_interrupt+0x3c/0x4c > pc : []lr : []psr: 61d3 > sp : c0635eb8 ip : fp : c063c3f0 > r10: 03ff r9 : r8 : 0010 > r7 : c22b3c40 r6 : ef007c00 r5 : c0640fcc r4 : c0053e30 > r3 : e92d45f0 r2 : fffe r1 : c22b3c40 r0 : c0053e30 > Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel > Control: 10c53c7d Table: 406a DAC: 0015 > Process swapper/0 (pid: 0, stack limit = 0xc0634238) > Stack: (0xc0635eb8 to 0xc0636000) > 5ea0: ef004c80 c0063224 > 5ec0: 0010 0010 c0660ac0 c0635f18 c005fcb8 c0632b90 c000ed94 > 5ee0: c0313c60 6153 0001 c00085a8 c0313c54 c0313c60 6153 > 5f00: c0635f4c 562f5842 c06360c0 c000db60 001a 8ad0 > 5f20: 8ad0 c06360c0 c04379c0 c22ad780 562f5842 > 5f40: c06360c0 6153 c0635f60 c0313c54 c0313c60 6153 > 5f60: 0021 0003 0004 006e c065fcc0 c067924c c063ceb8 > 5f80: c063cc84 c006d8c0 0005 c065fcc0 c067924c c0421764 c22ad780 c063c42c > 5fa0: 562f5842 c063cca8 c06605c0 c04379c0 c22ad780 562f5842 > 5fc0: c0417754 c04172dc c04379c0 > 5fe0: 10c53c7d c063c414 c04379bc c063febc 406a 8074 > [] (armada_370_xp_timer_interrupt+0x3c/0x4c) from [] > (handle_percpu_devid_irq+0x64/0x80) > [] (handle_percpu_devid_irq+0x64/0x80) from [] > (generic_handle_irq+0x20/0x30) > [] (generic_handle_irq+0x20/0x30) from [] > (handle_IRQ+0x38/0x90) > [] (handle_IRQ+0x38/0x90) from [] > (armada_370_xp_handle_irq+0xa4/0xb0) > [] (armada_370_xp_handle_irq+0xa4/0xb0) from [] > (__irq_svc+0x40/0x50) > Exception stack(0xc0635f18 to 0xc0635f60) > 5f00: 001a 8ad0 > 5f20: 8ad0 c06360c0 c04379c0 c22ad780 562f5842 > 5f40: c06360c0 6153 c0635f60 c0313c54 c0313c60 6153 > [] (__irq_svc+0x40/0x50) from [] > (calibrate_delay+0x378/0x528) > [] (calibrate_delay+0x378/0x528) from [] > (start_kernel+0x250/0x2dc) > [] (start_kernel+0x250/0x2dc) from [<8074>] (0x8074) > Code: 1fe7deb7 cd5772dd fff5692e ed55f79e (7ed5a5f7) > > > > I am trying to figure out what happened. Argh. Stupid casting again. Can you try this? ---8< diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c index ee2e50c5..a9bf37a 100644 --- a/drivers/clocksource/time-armada-370-xp.c +++ b/drivers/clocksource/time-armada-370-xp.c @@ -150,7 +150,7 @@ static irqreturn_t armada_370_xp_timer_interrupt(int irq, void *dev_id) /* * ACK timer interrupt and call event handler. */ - struct clock_event_device *evt = *(struct clock_event_device **)dev_id; + struct clock_event_device *evt = dev_id; writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS); evt->event_handler(evt); -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 09/10] clocksource: time-armada-370-xp: Divorce from local timer API
On 03/20/13 10:44, Gregory CLEMENT wrote: > On 03/20/2013 06:26 PM, Gregory CLEMENT wrote: >> On 03/20/2013 06:20 PM, Stephen Boyd wrote: >>> On 03/20/13 10:09, Gregory CLEMENT wrote: >>>> On 03/13/2013 07:17 PM, Stephen Boyd wrote: >>>>> Separate the armada 370xp local timers from the local timer API. >>>>> This will allow us to remove ARM local timer support in the near >>>>> future and makes this driver multi-architecture friendly. >>>> At first view the code looks good, but when I applied your patch set on >>>> linux-next, build it and run it on a Armada XP based board (AX3 with 2 >>>> cores), >>>> it crashed: >>> [...] >>>> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM >>>> Modules linked in: >>>> CPU: 0Not tainted (3.9.0-rc3-next-20130319-00010-g728b448 #153) >>>> PC is at 0xe92d45f0 >>>> LR is at armada_370_xp_timer_interrupt+0x3c/0x4c >>>> pc : []lr : []psr: 61d3 >>>> sp : c0635eb8 ip : fp : c063c3f0 >>>> r10: 03ff r9 : r8 : 0010 >>>> r7 : c22b3c40 r6 : ef007c00 r5 : c0640fcc r4 : c0053e30 >>>> r3 : e92d45f0 r2 : fffe r1 : c22b3c40 r0 : c0053e30 >>>> Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel >>>> Control: 10c53c7d Table: 406a DAC: 0015 >>>> Process swapper/0 (pid: 0, stack limit = 0xc0634238) >>>> Stack: (0xc0635eb8 to 0xc0636000) >>>> 5ea0: ef004c80 >>>> c0063224 >>>> 5ec0: 0010 0010 c0660ac0 c0635f18 c005fcb8 c0632b90 >>>> c000ed94 >>>> 5ee0: c0313c60 6153 0001 c00085a8 c0313c54 c0313c60 6153 >>>> >>>> 5f00: c0635f4c 562f5842 c06360c0 c000db60 001a >>>> 8ad0 >>>> 5f20: 8ad0 c06360c0 c04379c0 c22ad780 >>>> 562f5842 >>>> 5f40: c06360c0 6153 c0635f60 c0313c54 c0313c60 6153 >>>> >>>> 5f60: 0021 0003 0004 006e c065fcc0 c067924c >>>> c063ceb8 >>>> 5f80: c063cc84 c006d8c0 0005 c065fcc0 c067924c c0421764 c22ad780 >>>> c063c42c >>>> 5fa0: 562f5842 c063cca8 c06605c0 c04379c0 c22ad780 562f5842 >>>> >>>> 5fc0: c0417754 c04172dc >>>> c04379c0 >>>> 5fe0: 10c53c7d c063c414 c04379bc c063febc 406a 8074 >>>> >>>> [] (armada_370_xp_timer_interrupt+0x3c/0x4c) from [] >>>> (handle_percpu_devid_irq+0x64/0x80) >>>> [] (handle_percpu_devid_irq+0x64/0x80) from [] >>>> (generic_handle_irq+0x20/0x30) >>>> [] (generic_handle_irq+0x20/0x30) from [] >>>> (handle_IRQ+0x38/0x90) >>>> [] (handle_IRQ+0x38/0x90) from [] >>>> (armada_370_xp_handle_irq+0xa4/0xb0) >>>> [] (armada_370_xp_handle_irq+0xa4/0xb0) from [] >>>> (__irq_svc+0x40/0x50) >>>> Exception stack(0xc0635f18 to 0xc0635f60) >>>> 5f00: 001a >>>> 8ad0 >>>> 5f20: 8ad0 c06360c0 c04379c0 c22ad780 >>>> 562f5842 >>>> 5f40: c06360c0 6153 c0635f60 c0313c54 c0313c60 6153 >>>> >>>> [] (__irq_svc+0x40/0x50) from [] >>>> (calibrate_delay+0x378/0x528) >>>> [] (calibrate_delay+0x378/0x528) from [] >>>> (start_kernel+0x250/0x2dc) >>>> [] (start_kernel+0x250/0x2dc) from [<8074>] (0x8074) >>>> Code: 1fe7deb7 cd5772dd fff5692e ed55f79e (7ed5a5f7) >>>> >>>> >>>> >>>> I am trying to figure out what happened. >>> Argh. Stupid casting again. Can you try this? >> Our emails must have crossed, your fix is also fine :) >> > I have also tested the patch set on a Armada 370 based board (Armada 370 DB), > and it works well. > So with this last chunk you can add my: > Acked-by: Gregory CLEMENT > and also my > tested-by: Gregory CLEMENT > Great. Thanks for testing. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: arch_timer: Silence debug preempt warnings
Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:
BUG: using smp_processor_id() in preemptible [] code: sh/111
caller is arch_timer_cpu_notify+0x14/0xc8
This happens because sometimes the cpu notifier, arch_timer_cpu_notify(),
is called in preemptible context but we use this_cpu_ptr()
to retrieve the clockevent unconditionally. We're only going to
actually use the pointer in non-preemptible context though,
so use __this_cpu_ptr() instead to avoid the preemptible checks
and silence the warning.
Cc: Mark Rutland
Cc: Marc Zyngier
Signed-off-by: Stephen Boyd
---
drivers/clocksource/arm_arch_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index d7ad425..5928c29 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -248,7 +248,7 @@ static void __cpuinit arch_timer_stop(struct
clock_event_device *clk)
static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
{
- struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
+ struct clock_event_device *evt = __this_cpu_ptr(arch_timer_evt);
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 0/3] clk: implement remuxing during set_rate
On 03/22/13 08:43, James Hogan wrote: > This patchset adds support for automatic selection of the best parent > for a clock mux, i.e. the one which can provide the closest clock rate > to that requested. It can be controlled by a new CLK_SET_RATE_REMUX flag > so that it doesn't happen unless explicitly allowed. > > This works by way of adding a parameter to the round_rate clock op which > allows the clock driver to optionally select a different parent index. > This is used in clk_calc_new_rates to decide whether to initiate a > set_parent operation. This would obviously require the argument to be > added to all users of round_rate, something this patchset doesn't do as > I'm not sure if it's really the preferred method (hence the RFC). > > An alternative would be to add a new callback, but that would complicate > the code in clk.c somewhat. I suppose it would also be possible for the > round_rate callback to call a function to set a struct clk member to > mark that the parent should change (it's all within mutex protected > code after all). Comments anyone? It seems like you want to be able to call clk_set_rate() on a mux? Usually when this comes up people say you should use clk_set_parent() but I have a real use case (see below) and maybe you do too. This patch set caught my eye because we need to be able to switch parents during clk_set_rate() on MSM. We usually have two or three PLLs feed into a mux that might feed into a divider that feeds into one or two gates. I want clk_set_rate() on these gates to propagate up through the divider to the mux and then have the mux switch depending on the rate. I would like to get away without writing any new code beyond the ops that are already there though. Well, I may have to write one new op because I have hardware that can change the mux and divider at the same time. Can we push the code into the core? Perhaps by doing what you do in clk-mux.c directly in clk_calc_new_rates()? We could store a new_parent pointer in struct clk along with the new_rate when we find the best rate and then when we propagate rates we can propagate the parent switch. This part would be a little tricky if a clock has both a set_parent and a set_rate op; what do you call first? The set_rate op? The set_parent op? It matters for my hardware. We probably need to introduce a new set_rate_and_parent op in case both parts of the equation change so that the driver can do it atomically if desired (for my hardware) or in the correct order (this part could be two generic functions like generic_clk_rate_parent() and generic_clk_parent_rate() for the two different orders, or two flags and the logic in the core, whatever). I like keeping it in the core because we wouldn't need to change the round_rate() function signature, it would be called in a loop with different parent rates, and we wouldn't have to touch the clk-mux code at all because it would all be done generically. Plus I get almost everything for free for my hardware, I just need to write a new op that does that atomic mux and rate switch. What do you think? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 01/10] clocksource: add generic dummy timer driver
On 03/26/13 04:28, Mark Rutland wrote: > On Tue, Mar 26, 2013 at 02:14:53AM +0000, Stephen Boyd wrote: >> Ok. Thanks for clearing up my confusion. >> >> Like you say, increasing the dummy timer rating seems like a hack. But >> it also sounds like you want to keep the dummy timer driver fully self >> contained. I'm not opposed to calling dummy_timer_register() at the >> bottom of tick_init() if we have to, but it sounds like you don't like that. > I'd like to keep the dummy timer driver self-contained if we can, but if it > makes it more robust and/or easier to deal with by having an external call to > register the driver, then I'm not opposed to that. > >> An alternative would be to push the dummy timer logic into the core >> clockevents layer under the ifdef for arch has broadcast. This is >> probably the correct approach because most devices don't want to have a >> dummy timer sitting around unused. I might be able to take a look at >> this tomorrow. > I'm also not opposed to this idea. What if we only check the rating if the two devices are for the same CPU, i.e. always prefer percpu devices over global ones? This would make your dummy timers into tick devices. diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index b1600a6..9ea59b9 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -251,9 +251,10 @@ static int tick_check_new_device(struct clock_event_device *newdev) !(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) goto out_bc; /* -* Check the rating +* Check the rating, but prefer CPU local devices */ - if (curdev->rating >= newdev->rating) + if (curdev->rating >= newdev->rating && + cpumask_equal(curdev->cpumask, newdev->cpumask)) goto out_bc; } I think it will work with smp_twd, sp804, and dummy timers registered in any order too. > Though "broadcasting" to the same cpu is special-cased in tick_do_broadcast, > which will call the tick device's event_handler directly rather than having > the > cpu attempt to IPI to itself. > > As you suggest, tick_switch_to_oneshot does complain: > > Clockevents: could not switch to one-shot mode: dummy_timer is not functional. > Could not switch to high resolution mode on CPU 0 > > To handle this case we could check cpu_possible_mask when initialising the > dummy and only register it if more than 1 cpu is possible. That would be > roughly in line with how we handle this case in smp.c. Yes, this will work well enough. Squashed it into this patch. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: arch_timer: Silence debug preempt warnings
On 4/2/2013 1:31 PM, Stephen Boyd wrote:
> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
> architected timers causes a slew of "using smp_processor_id() in
> preemptible" warnings:
>
> BUG: using smp_processor_id() in preemptible [] code: sh/111
> caller is arch_timer_cpu_notify+0x14/0xc8
>
> This happens because sometimes the cpu notifier, arch_timer_cpu_notify(),
> is called in preemptible context but we use this_cpu_ptr()
> to retrieve the clockevent unconditionally. We're only going to
> actually use the pointer in non-preemptible context though,
> so use __this_cpu_ptr() instead to avoid the preemptible checks
> and silence the warning.
>
> Cc: Mark Rutland
> Cc: Marc Zyngier
> Signed-off-by: Stephen Boyd
> ---
Anyone else seeing this one?
> drivers/clocksource/arm_arch_timer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index d7ad425..5928c29 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -248,7 +248,7 @@ static void __cpuinit arch_timer_stop(struct
> clock_event_device *clk)
> static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
> unsigned long action, void *hcpu)
> {
> - struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
> + struct clock_event_device *evt = __this_cpu_ptr(arch_timer_evt);
>
> switch (action & ~CPU_TASKS_FROZEN) {
> case CPU_STARTING:
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: arch_timer: Silence debug preempt warnings
On 04/05/13 03:04, Marc Zyngier wrote:
>
>>> drivers/clocksource/arm_arch_timer.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clocksource/arm_arch_timer.c
>>> b/drivers/clocksource/arm_arch_timer.c
>>> index d7ad425..5928c29 100644
>>> --- a/drivers/clocksource/arm_arch_timer.c
>>> +++ b/drivers/clocksource/arm_arch_timer.c
>>> @@ -248,7 +248,7 @@ static void __cpuinit arch_timer_stop(struct
>>> clock_event_device *clk)
>>> static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
>>>unsigned long action, void *hcpu)
>>> {
>>> - struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
>>> + struct clock_event_device *evt = __this_cpu_ptr(arch_timer_evt);
>>>
>>> switch (action & ~CPU_TASKS_FROZEN) {
>>> case CPU_STARTING:
> I'm afraid this would hide bugs if we start using the notifier for other
> purposes than exclusivity non-preemptible contexts.
>
> How about moving the this_cpu_ptr() down to the cases themselves, maybe
> with a nice comment?
Ok. v2 coming up.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] ARM: arch_timer: Silence debug preempt warnings
Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:
BUG: using smp_processor_id() in preemptible [] code: sh/111
caller is arch_timer_cpu_notify+0x14/0xc8
This happens because sometimes the cpu notifier,
arch_timer_cpu_notify(), is called in preemptible context and
other times in non-preemptible context but we use this_cpu_ptr()
to retrieve the clockevent in all cases. We're only going to
actually use the pointer in non-preemptible context though, so
push the this_cpu_ptr() access down into the cases to force the
checks to occur only in non-preemptible contexts.
Cc: Mark Rutland
Cc: Marc Zyngier
Signed-off-by: Stephen Boyd
---
Changes since v1:
* Pushed down this_cpu_ptr and added a comment
drivers/clocksource/arm_arch_timer.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index d7ad425..a65a710 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct
clock_event_device *clk)
static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
{
- struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
-
+ /*
+* Grab cpu pointer in each case to avoid spurious
+* preemptible warnings
+*/
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
- arch_timer_setup(evt);
+ arch_timer_setup(this_cpu_ptr(arch_timer_evt));
break;
case CPU_DYING:
- arch_timer_stop(evt);
+ arch_timer_stop(this_cpu_ptr(arch_timer_evt));
break;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] regmap: spi: Support asynchronous I/O for SPI
On 01/28/13 17:39, Mark Brown wrote:
> On Mon, Jan 28, 2013 at 11:38:50AM -0800, Stephen Boyd wrote:
>> On 01/27/13 06:12, Mark Brown wrote:
>>> +static int regmap_spi_async_write(void *context,
>>> + const void *reg, size_t reg_len,
>>> + const void *val, size_t val_len,
>>> + struct regmap_async *a)
>>> +{
>>> + struct regmap_async_spi *async = (void *)a;
>> Can you use container_of() here?
> We could but I tend not to if the interface strictly requires that the
> pointers be type punnable.
What is the interface requiring strict type punning here? async_write?
I just hope we don't move the fields around in the regmap_async_spi
struct and then this code silently breaks. I hope the compiler is smart
enough to skip doing any math if we used container_of() with the current
struct layout.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] regmap: spi: Support asynchronous I/O for SPI
On 01/27/13 06:12, Mark Brown wrote:
> diff --git a/drivers/base/regmap/regmap-spi.c
> b/drivers/base/regmap/regmap-spi.c
> index ffa46a9..bb19592 100644
> --- a/drivers/base/regmap/regmap-spi.c
> +++ b/drivers/base/regmap/regmap-spi.c
> @@ -15,6 +15,21 @@
> #include
> #include
>
> +#include "internal.h"
> +
> +struct regmap_async_spi {
> + struct regmap_async core;
> + struct spi_message m;
> + struct spi_transfer t[2];
> +};
> +
> +static void regmap_spi_complete(void *data)
> +{
> + struct regmap_async_spi *async = data;
> +
> + regmap_async_complete_cb(&async->core, async->m.status);
> +}
> +
> static int regmap_spi_write(void *context, const void *data, size_t count)
> {
> struct device *dev = context;
> @@ -40,6 +55,30 @@ static int regmap_spi_gather_write(void *context,
> return spi_sync(spi, &m);
> }
>
> +static int regmap_spi_async_write(void *context,
> + const void *reg, size_t reg_len,
> + const void *val, size_t val_len,
> + struct regmap_async *a)
> +{
> + struct regmap_async_spi *async = (void *)a;
Can you use container_of() here?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] ARM: smp: Remove local timer API
On 2/22/2013 3:15 AM, Mark Rutland wrote:
> Hi Stephen,
>
> One thing that struck me when I was fiddling with the broadcast mechanism was
> that it should be possible to have a generic dummy timer implementation. As
> long as the architecture calls notifiers at the appropriate times, it should
> look like any other timer driver (apart from not touching any hardware). It
> just
> needs to depend on ARCH_HAS_TICK_BROADCAST.
>
> I believe it shouldn't be too difficult to implement, though I may be blind to
> some problems.
I completely agree and I was thinking the same thing while writing this
patchset.
>
> Otherwise, I have a few comments on the patch below.
>
> On Fri, Feb 22, 2013 at 07:27:19AM +, Stephen Boyd wrote:
>> There are no more users of this API, remove it.
> As we're leaving the dummy timers, it'd be worth explaining why in the commit
> message.
No problem.
>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index dedf02b..7d4338d 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1527,6 +1527,7 @@ config SMP
>> depends on HAVE_SMP
>> depends on MMU
>> select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
>> +select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
>> select USE_GENERIC_SMP_HELPERS
>> help
>>This enables support for systems with more than one CPU. If you have
> Should this have been in an earlier patch?
It could be part of the smp_twd patch if you like.
> Why is it necessary?
It shouldn't be. In fact, I sent a patchset a few months ago that pushed
down the TWD and SCU selects to the respective machines that need them.
I should resend that.
>
> [...]
>
>> -static void percpu_timer_setup(void);
>> +static void broadcast_timer_setup(void);
>>
>> /*
>> * This is the secondary CPU boot entry. We're using this CPUs
>> @@ -325,9 +317,9 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
>> complete(&cpu_running);
>>
>> /*
>> - * Setup the percpu timer for this CPU.
>> + * Setup the dummy broadcast timer for this CPU.
> To me, calling something a broadcast timer makes it sound like it performs the
> broadcast. We use the term "broadcast timer" elsewhere here (e.g.
> broadcast_timer_setup), and I think it's any unnecessarily confusing term.
>
> Might it be better to say "dummy timer" consistently?
Sure. I wonder if we need the comment at all. I can rename the function
to dummy_timer_setup() and it pretty much sounds like what the comment
will say.
>
> [...]
>
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index 2bdd4cf..c00a8f8 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -587,7 +587,6 @@ OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE,
>> "ti,timer-alwon",
>> #ifdef CONFIG_ARCH_OMAP4
>> OMAP_SYS_32K_TIMER_INIT(4, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
>> 2, OMAP4_MPU_SOURCE);
>> -#ifdef CONFIG_LOCAL_TIMERS
>> static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
>> void __init omap4_local_timer_init(void)
>> {
>> @@ -606,12 +605,6 @@ void __init omap4_local_timer_init(void)
>> pr_err("twd_local_timer_register failed %d\n", err);
>> }
>> }
>> -#else /* CONFIG_LOCAL_TIMERS */
>> -void __init omap4_local_timer_init(void)
>> -{
>> -omap4_sync32k_timer_init();
>> -}
>> -#endif /* CONFIG_LOCAL_TIMERS */
>> #endif /* CONFIG_ARCH_OMAP4 */
>>
>> #ifdef CONFIG_SOC_OMAP5
> I believe the above OMAP changes should have been in an earlier patch?
There isn't an omap patch. I could make it part of the smp_twd patch?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width
On 02/25/13 03:18, Will Deacon wrote:
> On Fri, Feb 22, 2013 at 11:46:18PM +0000, Stephen Boyd wrote:
>> On 2/22/2013 10:27 AM, Will Deacon wrote:
>>> What value do you have in fpsid? As far as I can tell, the
>>> subarchitecture bits 6:0 should start at 0x40 for you, right?
>> Yes it does.
> Ok, good. Could you share the different subarchitecture encodings that you
> have please? (assumedly some/all of these are compatible with a variant of
> VFP).
Definitely all Krait processors have 0x40 for the subarchitecture
encoding. I need to check our Scorpions but I'm fairly certain they also
have 0x40.
>
>>> I can see cases for changing this code, I just don't see why it would go
>>> wrong in the case you're describing.
>> VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;
>>
>> causes VFP_arch to be equal to 0 because 0x40 & 0xf == 0.
>>
>> and then a little bit later we have
>>
>>if (VFP_arch >= 2) {
>> elf_hwcap |= HWCAP_VFPv3;
>>
>>
>> The branch is not taken so we never set VFPv3.
> Ah, that's what I feared: the low bits are zero yet you are compatible with
> VFPv3. That's fine, but the proposed fix feels like a kludge; the only reason
> we'd choose on VFPv3 is because the implementor is not ARM, which may not hold
> true for other vendors. I think it would be better if we translated
> vendor-specific subarchitectures that are compatible with VFPvN into the
> corresponding architecture number instead. This would also allow us to add
> extra hwcaps for extensions other than VFP.
Ok. We should be able to make VFP_arch into 0x4 if the implementer is
0x51 and the subarch bits are 0x40.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width
On 02/25/13 12:02, Russell King - ARM Linux wrote: > > This can of worms is getting bigger. We have more problems with our > handling of the different VFP versions, specifically the handling of > the EX=0 DEX=0 case. > > VFP common subarch 3 defines the EX=0, DEX=0 encoding to mean one of > the following conditions have been met: > > 1. an unallocated VFP instruction was encountered. > >In other words, the VFP was the target of the co-processor instruction, >but the instruction is not a known VFP instruction encoding. This >should raise an undefined instruction exception. > > 2. an allocated VFP instruction was encountered, but not handled in >hardware. > >In other words, the instruction is a valid VFP instruction, but the >hardware has opted not to implement this instruction and wants >software to emulate it instead. > >(Note: this can also be raised as EX=0, DEX=1 - implementation > defined!) > [snip] > > So, if EX or DEX is set, _or_ IXE is set, we pass control to VFP_bounce. > This is problematical. > > (a) condition (2) above isn't correctly handled for common subarch v3 - it > is always treated as an undefined instruction, and will result in a > SIGILL being delivered. > [snip] > > Now, (a) is just bad behaviour - as we haven't had any reports of this > yet, I suspect that no one has implemented VFP hardware with this > behaviour yet. I believe we ran into this a while ago and fixed it for our chips. We never sent the patch upstream. Sorry. https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=commitdiff;h=00a13be874f230159a6b7f8cc9d0ff23bc1b7d05 I'm looking into what our bits correspond to. Hopefully get back to you in 20 something hours. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Consolidate CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
The help text for this config is duplicated across the x86, parisc, and s390 Kconfig.debug files. Arnd Bergman noted that the help text was slightly misleading and should be fixed to state that enabling this option isn't a problem when using pre 4.4 gcc. To simplify the rewording, consolidate the text into lib/Kconfig.debug and modify it there to be more explicit about when you should say N to this config. Also, make the text a bit more generic by stating that this option enables compile time checks so we can cover architectures which emit warnings vs. ones which emit errors. The details of how an architecture decided to implement the checks isn't as important as the concept of compile time checking of copy_from_user() calls. While we're doing this, remove all the copy_from_user_overflow() code that's duplicated many times and place it into lib/ so that any architecture supporting this option can get the function for free. Cc: Arnd Bergmann Cc: Ingo Molnar Cc: H. Peter Anvin Cc: linux-par...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: Arjan van de Ven Cc: Helge Deller Cc: Heiko Carstens Cc: Stephen Rothwell Cc: Chris Metcalf Signed-off-by: Stephen Boyd --- Per Helge Deller prodding me, I'm resending just this patch. https://patchwork.kernel.org/patch/833182/ arch/parisc/Kconfig | 1 + arch/parisc/Kconfig.debug | 14 -- arch/s390/Kconfig | 1 + arch/s390/Kconfig.debug | 14 -- arch/s390/lib/Makefile | 1 - arch/s390/lib/usercopy.c| 8 arch/sparc/lib/Makefile | 1 - arch/sparc/lib/usercopy.c | 9 - arch/tile/Kconfig | 8 +--- arch/tile/include/asm/uaccess.h | 7 ++- arch/tile/lib/uaccess.c | 8 arch/x86/Kconfig| 1 + arch/x86/Kconfig.debug | 14 -- arch/x86/lib/usercopy_32.c | 6 -- lib/Kconfig.debug | 18 ++ lib/Makefile| 1 + lib/usercopy.c | 9 + 17 files changed, 38 insertions(+), 83 deletions(-) delete mode 100644 arch/s390/lib/usercopy.c delete mode 100644 arch/sparc/lib/usercopy.c create mode 100644 lib/usercopy.c diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index a2a47d9..96be92f 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -1,5 +1,6 @@ config PARISC def_bool y + select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS select HAVE_IDE select HAVE_OPROFILE select HAVE_FUNCTION_TRACER if 64BIT diff --git a/arch/parisc/Kconfig.debug b/arch/parisc/Kconfig.debug index 7305ac8..bc989e5 100644 --- a/arch/parisc/Kconfig.debug +++ b/arch/parisc/Kconfig.debug @@ -12,18 +12,4 @@ config DEBUG_RODATA portion of the kernel code won't be covered by a TLB anymore. If in doubt, say "N". -config DEBUG_STRICT_USER_COPY_CHECKS - bool "Strict copy size checks" - depends on DEBUG_KERNEL && !TRACE_BRANCH_PROFILING - ---help--- - Enabling this option turns a certain set of sanity checks for user - copy operations into compile time failures. - - The copy_from_user() etc checks are there to help test if there - are sufficient security checks on the length argument of - the copy operation, by having gcc prove that the argument is - within bounds. - - If unsure, or if you run an older (pre 4.4) gcc, say N. - endmenu diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 4b50537..516621f 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -91,6 +91,7 @@ config S390 select ARCH_INLINE_WRITE_UNLOCK_BH select ARCH_INLINE_WRITE_UNLOCK_IRQ select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE + select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS select ARCH_SAVE_PAGE_KEYS if HIBERNATION select ARCH_WANT_IPC_PARSE_VERSION select BUILDTIME_EXTABLE_SORT diff --git a/arch/s390/Kconfig.debug b/arch/s390/Kconfig.debug index fc32a2d..c56878e 100644 --- a/arch/s390/Kconfig.debug +++ b/arch/s390/Kconfig.debug @@ -17,20 +17,6 @@ config STRICT_DEVMEM If you are unsure, say Y. -config DEBUG_STRICT_USER_COPY_CHECKS - def_bool n - prompt "Strict user copy size checks" - ---help--- - Enabling this option turns a certain set of sanity checks for user - copy operations into compile time warnings. - - The copy_from_user() etc checks are there to help test if there - are sufficient security checks on the length argument of - the copy operation, by having gcc prove that the argument is - within bounds. - - If unsure, or if you run an older (pre 4.4) gcc, say N. - config S390_PTDUMP bool "Export kernel pagetable layout to userspace via debugfs" depends on DEBUG_KERNEL diff
Re: [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width
On 02/26/13 09:54, Russell King - ARM Linux wrote: > What I actually need from you is: for the Qualcomm implementation, what > are the subarch bits defined as, and what do they correspond with - both > the VFP version, and whether they correspond with any ARM common VFP > subarchitecture version. For the Qualcomm implementation, the subarch bits have always been 0x40 so far. And they are compatible with "VFPv3 architecture or later with common VFP subarchitecture v3". In your table below it would be the last row. > > In ARM land, these are the possiblities - I've also listed those > platforms which I definitely know of at the moment which use the > particular version combination: > > VFP version VFP subarch > V1- > V2V1 Raspberry Pi > V3V2 Marvell Dove (Cubox) (though, not ARM) > V3NULLOMAP3430 / OMAP4430 > V3V3 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] timer_list: split timer_list_show_tickdevices()
On 02/26/13 15:33, Nathan Zimmer wrote:
> @@ -246,12 +244,8 @@ static void timer_list_show_tickdevices(struct seq_file
> *m)
> #endif
> SEQ_printf(m, "\n");
> #endif
> - for_each_online_cpu(cpu)
> - print_tickdevice(m, tick_get_device(cpu), cpu);
> SEQ_printf(m, "\n");
> }
The duplicate newline is here again?
> -#else
> -static void timer_list_show_tickdevices(struct seq_file *m) { }
> #endif
>
> static int timer_list_show(struct seq_file *m, void *v)
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Consolidate CONFIG_DEBUG_STRICT_USER_COPY_CHECK
On 02/27/13 12:32, Arnd Bergmann wrote: > On Wednesday 27 February 2013, Stephen Boyd wrote: >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug >> index 28be08c..ae80518 100644 >> --- a/lib/Kconfig.debug >> +++ b/lib/Kconfig.debug >> @@ -1292,6 +1292,24 @@ config LATENCYTOP >>Enable this option if you want to use the LatencyTOP tool >>to find out which userspace is blocking on what kernel operations. >> >> +config ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS >> +bool >> + >> +config DEBUG_STRICT_USER_COPY_CHECKS >> +bool "Strict user copy size checks" >> +depends on ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS >> +depends on DEBUG_KERNEL && !TRACE_BRANCH_PROFILING >> +help >> + Enabling this option turns a certain set of sanity checks for user >> + copy operations into compile time failures. >> + >> + The copy_from_user() etc checks are there to help test if there >> + are sufficient security checks on the length argument of >> + the copy operation, by having gcc prove that the argument is >> + within bounds. >> + >> + If unsure, say N. >> + > Is there actually any architecture dependency left after this? > I wonder if we actually need the ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS > symbol, or could just show the DEBUG_STRICT_USER_COPY_CHECKS option > on all architectures. > > It's fine to do your patch as a first step though, which would not > change the behavior. A lot of arches seem to not want to enable it because false positives are everywhere. It really depends on how good the compiler is at doing constant propagation and dead code removal. > >> diff --git a/lib/Makefile b/lib/Makefile >> index 32f4455..59fabd0 100644 >> --- a/lib/Makefile >> +++ b/lib/Makefile >> @@ -15,6 +15,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ >> is_single_threaded.o plist.o decompress.o kobject_uevent.o \ >> earlycpio.o percpu-refcount.o >> >> +lib-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o >> lib-$(CONFIG_MMU) += ioremap.o >> lib-$(CONFIG_SMP) += cpumask.o >> > I think this should instead be > > +lib-$(DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o > > No point building that file if we are not using it. We still need it to link the kernel because the callers of the function don't have ifdefs. Also, all arches were doing an obj-y before, so this is equivalent. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Consolidate CONFIG_DEBUG_STRICT_USER_COPY_CHECK
On 02/27/13 14:19, H. Peter Anvin wrote: > On 02/27/2013 12:42 PM, Stephen Boyd wrote: >>> It's fine to do your patch as a first step though, which would not >>> change the behavior. >> A lot of arches seem to not want to enable it because false positives >> are everywhere. It really depends on how good the compiler is at doing >> constant propagation and dead code removal. >> > Although some of the cases I have seen being flagged as "false > positives" have been real bugs. There were so many false-positives on x86_64 that Andrew eventually dropped my patch to add support for this option to the copy_from_user() function there. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Consolidate CONFIG_DEBUG_STRICT_USER_COPY_CHECK
On 02/27/13 14:55, H. Peter Anvin wrote: > On 02/27/2013 02:52 PM, Stephen Boyd wrote: >> On 02/27/13 14:19, H. Peter Anvin wrote: >>> On 02/27/2013 12:42 PM, Stephen Boyd wrote: >>>>> It's fine to do your patch as a first step though, which would not >>>>> change the behavior. >>>> A lot of arches seem to not want to enable it because false positives >>>> are everywhere. It really depends on how good the compiler is at doing >>>> constant propagation and dead code removal. >>>> >>> Although some of the cases I have seen being flagged as "false >>> positives" have been real bugs. >> There were so many false-positives on x86_64 that Andrew eventually >> dropped my patch to add support for this option to the copy_from_user() >> function there. >> > I would probably have taken it, especially if it came with more x86-64 > to i386 unification. > > It's an option, though. You acked the patch[1]. Will you pick it up? [1] https://patchwork.kernel.org/patch/833192/ -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] ARM: Push selects for TWD/SCU into machine entries
The TWD and SCU configs are selected by default as long as MSM_SCORPIONMP is false and/or MCT is false. Implementing the logic this way certainly saves lines in the Kconfig but it precludes those machines which select MSM_SCORPIONMP or MCT from participating in the single zImage effort because when those machines are combined with other SMP capable machines the TWD and SCU are no longer selected by default. Push the select out to the machine entries so that we can compile these machines together and still select the appropriate configs. Cc: Barry Song Acked-by: David Brown Cc: Kukjin Kim Cc: Linus Walleij Acked-by: Pawel Moll Cc: Rob Herring Cc: Russell King Acked-by: Santosh Shilimkar Cc: Sascha Hauer Cc: Shiraz Hashim Acked-by: Simon Horman Cc: Srinidhi Kasagar Cc: Stephen Warren Cc: Tony Lindgren Acked-by: Viresh Kumar Signed-off-by: Stephen Boyd --- Resending to collect some more acks. arch/arm/Kconfig | 8 ++-- arch/arm/mach-exynos/Kconfig | 2 ++ arch/arm/mach-highbank/Kconfig | 1 + arch/arm/mach-imx/Kconfig | 3 ++- arch/arm/mach-msm/Kconfig | 7 ++- arch/arm/mach-omap2/Kconfig| 2 ++ arch/arm/mach-prima2/Kconfig | 1 + arch/arm/mach-realview/Kconfig | 8 arch/arm/mach-vexpress/Kconfig | 2 ++ arch/arm/plat-spear/Kconfig| 2 ++ 10 files changed, 28 insertions(+), 8 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index dedf02b..8f5707b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -672,6 +672,8 @@ config ARCH_TEGRA select CLKSRC_OF select COMMON_CLK select GENERIC_CLOCKEVENTS + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select HAVE_CLK select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 @@ -718,6 +720,8 @@ config ARCH_SHMOBILE bool "Renesas SH-Mobile / R-Mobile" select CLKDEV_LOOKUP select GENERIC_CLOCKEVENTS + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select HAVE_CLK select HAVE_MACH_CLKDEV select HAVE_SMP @@ -910,6 +914,8 @@ config ARCH_U8500 select CLKDEV_LOOKUP select CPU_V7 select GENERIC_CLOCKEVENTS + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select SPARSE_IRQ @@ -1526,7 +1532,6 @@ config SMP depends on GENERIC_CLOCKEVENTS depends on HAVE_SMP depends on MMU - select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP select USE_GENERIC_SMP_HELPERS help This enables support for systems with more than one CPU. If you have @@ -1650,7 +1655,6 @@ config LOCAL_TIMERS bool "Use local timer interrupts" depends on SMP default y - select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT) help Enable support for local timers on SMP platforms, rather then the legacy IPI broadcast method. Local timers allows the system diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 70f94c8..54cf73e 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -14,6 +14,7 @@ menu "SAMSUNG EXYNOS SoCs Support" config ARCH_EXYNOS4 bool "SAMSUNG EXYNOS4" default y + select HAVE_ARM_SCU if SMP select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help @@ -21,6 +22,7 @@ config ARCH_EXYNOS4 config ARCH_EXYNOS5 bool "SAMSUNG EXYNOS5" + select HAVE_ARM_SCU if SMP select HAVE_SMP help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig index 44b12f9..cd9fcb1 100644 --- a/arch/arm/mach-highbank/Kconfig +++ b/arch/arm/mach-highbank/Kconfig @@ -12,6 +12,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select HAVE_ARM_TWD if LOCAL_TIMERS select HAVE_SMP select MAILBOX select PL320_MBOX diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 4c9c6f9..2cc0dbd 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -811,7 +811,8 @@ config SOC_IMX6Q select ARM_GIC select COMMON_CLK select CPU_V7 - select HAVE_ARM_SCU + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select HAVE_CAN_FLEXCAN if CAN select HAVE_IMX_GPC select HAVE_IMX_MMDC diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index b619085..fceb093 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -44,10 +44,10 @@ endchoice config ARCH_MSM8X60 bool "MSM8X60" - select ARCH_MSM_SCORPIONMP select ARM_GIC select CPU_V7 select GPIO_MSM_V2 + sele
Re: [RFC] arm: use built-in byte swap function
On 2/19/2013 6:31 PM, Kim Phillips wrote: > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile > index af72969..dbee639 100644 > --- a/arch/arm/lib/Makefile > +++ b/arch/arm/lib/Makefile > @@ -45,3 +45,5 @@ lib-$(CONFIG_ARCH_SHARK)+= io-shark.o > > $(obj)/csumpartialcopy.o:$(obj)/csumpartialcopygeneric.S > $(obj)/csumpartialcopyuser.o:$(obj)/csumpartialcopygeneric.S > + > +CFLAGS_bswapsdi2.o = -O2 Please put a comment here so we don't have to dig through git history and/or emails to understand why this has -O2 forced on for this file. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2013-02-19-17-20 uploaded
On 2/19/2013 5:21 PM, a...@linux-foundation.org wrote:
> * timer_list-split-timer_list_show_tickdevices.patch
> * timer_list-convert-timer-list-to-be-a-proper-seq_file.patch
> * timer_list-convert-timer-list-to-be-a-proper-seq_file-fix.patch
> * timer_list-convert-timer-list-to-be-a-proper-seq_file-v2.patch
> * timer_list-convert-timer-list-to-be-a-proper-seq_file-v2-fix.patch
> * timer_list-convert-timer-list-to-be-a-proper-seq_file-fix-fix.patch
These commits seem to break the timer list on devices with maxcpus !=
nr_cpu_ids, which is possible if you specify maxcpus on the kernel
command line. I no longer see the percpu devices that I normally have
after the broadcast device.
I also notice what looks like an extra newline inserted in the output
between the percpu devices and the broadcast device, which may not be
intentional. There are also some more spelling mistakes in the comments.
Can we fold in this fix on top of the others (hopefully not white-space
damaged)?
diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
index 9904e48..e3cb935 100644
--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -244,7 +244,6 @@ static void timer_list_show_tickdevices_header(struct
seq_file *m)
#endif
SEQ_printf(m, "\n");
#endif
- SEQ_printf(m, "\n");
}
#endif
@@ -275,7 +274,7 @@ static int timer_list_show(struct seq_file *m, void *v)
}
/*
- * This itererator really needs some explnation since it is offset and has
+ * This iterator really needs some explanation since it is offset and has
* two passes, one of which is controlled by a config option.
* In a hotplugged system some cpus, including cpu 0, may be missing so we have
* to use cpumask_* to iterate over the cpus.
@@ -283,7 +282,7 @@ static int timer_list_show(struct seq_file *m, void *v)
* It returns 1 for the header position.
* For cpu 0 it returns 2 and the final possible cpu would be nr_cpu_ids + 1.
* On the second pass:
- * It returnes nr_cpu_ids + 1 for the second header position.
+ * It returns nr_cpu_ids + 1 for the second header position.
* For cpu 0 it returns nr_cpu_ids + 2
* The final possible cpu would be nr_cpu_ids + nr_cpu_ids + 2.
*/
@@ -300,8 +299,12 @@ static void *timer_list_start(struct seq_file *file,
loff_t *offset)
n = cpumask_next(n - 1, cpu_online_mask);
else
n = cpumask_first(cpu_online_mask);
- *offset = n + 1;
- return (void *)(unsigned long)(n + 2);
+ if (n < nr_cpu_ids) {
+ *offset = n + 1;
+ return (void *)(unsigned long)(n + 2);
+ } else {
+ *offset = n = nr_cpu_ids + 1;
+ }
}
#ifdef CONFIG_GENERIC_CLOCKEVENTS
@@ -314,8 +317,10 @@ static void *timer_list_start(struct seq_file *file,
loff_t *offset)
n = cpumask_next(n - 1, cpu_online_mask);
else
n = cpumask_first(cpu_online_mask);
- *offset = n + 2 + nr_cpu_ids;
- return (void *)(unsigned long)(n + 3 + nr_cpu_ids);
+ if (n < nr_cpu_ids) {
+ *offset = n + 2 + nr_cpu_ids;
+ return (void *)(unsigned long)(n + 3 + nr_cpu_ids);
+ }
}
#endif
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2013-02-19-17-20 uploaded
On 2/21/2013 10:18 AM, Nathan Zimmer wrote: > On Thu, Feb 21, 2013 at 01:25:29AM -0800, Stephen Boyd wrote: >> On 2/19/2013 5:21 PM, a...@linux-foundation.org wrote: >>> * timer_list-split-timer_list_show_tickdevices.patch >>> * timer_list-convert-timer-list-to-be-a-proper-seq_file.patch >>> * timer_list-convert-timer-list-to-be-a-proper-seq_file-fix.patch >>> * timer_list-convert-timer-list-to-be-a-proper-seq_file-v2.patch >>> * timer_list-convert-timer-list-to-be-a-proper-seq_file-v2-fix.patch >>> * timer_list-convert-timer-list-to-be-a-proper-seq_file-fix-fix.patch >> These commits seem to break the timer list on devices with maxcpus != >> nr_cpu_ids, which is possible if you specify maxcpus on the kernel >> command line. I no longer see the percpu devices that I normally have >> after the broadcast device. > Interesting. > However I can't seem to boot at the moment with maxcpus set to less then the > actual > number of cpus so I am not having much luck investigating right now. It works well on ARM processors. I believe it still works on x86 devices as well. I suppose you can simulate it by offlining a CPU and then reading the file. This comment is useful around the cpumask functions. Returns >= nr_cpu_ids if no further cpus set. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2013-02-19-17-20 uploaded
On 2/21/2013 10:35 AM, Nathan Zimmer wrote: > >> This comment is useful around the cpumask functions. >> >> Returns >= nr_cpu_ids if no further cpus set. >> > I had assumed it would be = nr_cpu_ids. > I will need to rethink the iterator. Yes it is actually equal to the nr_cpu_ids in my error case. On my system, nr_cpu_ids = 4 and I only have one cpu online. > > > Also I retested my other patches in the series, the ones for schedstat > and sched_debug, and those worked fine. I haven't tried those yet. I will try to take a look. Also, can't we simplify the code by calling cpumask_next() with the first argument being -1? No more cpu > 0 check? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] Remove ARM local timer API
In light of Mark Rutland's recent work on divorcing the ARM architected timers from the ARM local timer API and introducing a generic arch hook for broadcast it seems that we should remove the local timer API entirely. Doing so will reduce the architecture dependencies of our timer drivers, reduce code in ARM core, and simplify timer drivers because they no longer go through an architecture layer that is essentially a hotplug notifier. Previous attempts have been made[1] unsuccessfully. I'm hoping this can be accepted now so that we can clean up the timer drivers that are used in both UP and SMP situations. Right now these drivers have to ignore the timer setup callback on the boot CPU to avoid registering clockevents twice. This is not very symmetric and causes convuluted code that does the same thing in two places. Patches based on linux-next-20130221. Mostly compile tested as I don't have access to the hardware. [1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705 Note: A hotplug notifier is used by both x86 for the apb_timer (see apbt_cpuhp_notify) and by metag (see arch_timer_cpu_notify in metag_generic.c) so this is not new. Stephen Boyd (8): ARM: smp: Lower rating of dummy broadcast device ARM: smp_twd: Divorce smp_twd from local timer API ARM: EXYNOS4: Divorce mct from local timer API ARM: PRIMA2: Divorce timer-marco from local timer API ARM: MSM: Divorce msm_timer from local timer API clocksource: time-armada-370-xp: Fix sparse warning clocksource: time-armada-370-xp: Divorce from local timer API ARM: smp: Remove local timer API arch/arm/Kconfig | 12 +-- arch/arm/include/asm/localtimer.h| 34 - arch/arm/kernel/smp.c| 69 +++-- arch/arm/kernel/smp_twd.c| 48 arch/arm/mach-exynos/mct.c | 53 + arch/arm/mach-msm/timer.c| 125 +-- arch/arm/mach-omap2/Kconfig | 1 - arch/arm/mach-omap2/timer.c | 7 -- arch/arm/mach-prima2/timer-marco.c | 98 drivers/clocksource/time-armada-370-xp.c | 88 ++ include/linux/time-armada-370-xp.h | 4 +- 11 files changed, 241 insertions(+), 298 deletions(-) delete mode 100644 arch/arm/include/asm/localtimer.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] ARM: smp: Lower rating of dummy broadcast device
In the near future the dummy broadcast device will always be registered with the clockevent core. If the rating of the dummy is higher than the rating of the real clockevent the clockevents core will try to replace the real clockevent with the dummy broadcast. We don't want this to happen, so lower the rating to something no good clockevent should choose. Cc: Russell King Signed-off-by: Stephen Boyd --- arch/arm/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index fa86d1c..2d5197d 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -479,7 +479,7 @@ static void __cpuinit broadcast_timer_setup(struct clock_event_device *evt) evt->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_DUMMY; - evt->rating = 400; + evt->rating = 100; evt->mult = 1; evt->set_mode = broadcast_timer_set_mode; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] clocksource: time-armada-370-xp: Divorce from local timer API
Separate the armada 370xp local timers from the local timer API.
This will allow us to remove ARM local timer support in the near
future and makes this driver multi-architecture friendly.
Cc: Gregory CLEMENT
Signed-off-by: Stephen Boyd
---
drivers/clocksource/time-armada-370-xp.c | 85 ++--
1 file changed, 38 insertions(+), 47 deletions(-)
diff --git a/drivers/clocksource/time-armada-370-xp.c
b/drivers/clocksource/time-armada-370-xp.c
index efe4aef..ee2e50c5 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,7 +32,6 @@
#include
#include
-#include
/*
* Timer block registers.
*/
@@ -70,7 +70,7 @@ static bool timer25Mhz = true;
*/
static u32 ticks_per_jiffy;
-static struct clock_event_device __percpu **percpu_armada_370_xp_evt;
+static struct clock_event_device __percpu *armada_370_xp_evt;
static u32 notrace armada_370_xp_read_sched_clock(void)
{
@@ -143,14 +143,7 @@ armada_370_xp_clkevt_mode(enum clock_event_mode mode,
}
}
-static struct clock_event_device armada_370_xp_clkevt = {
- .name = "armada_370_xp_per_cpu_tick",
- .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
- .shift = 32,
- .rating = 300,
- .set_next_event = armada_370_xp_clkevt_next_event,
- .set_mode = armada_370_xp_clkevt_mode,
-};
+static int armada_370_xp_clkevt_irq;
static irqreturn_t armada_370_xp_timer_interrupt(int irq, void *dev_id)
{
@@ -173,42 +166,53 @@ static int __cpuinit armada_370_xp_timer_setup(struct
clock_event_device *evt)
u32 u;
int cpu = smp_processor_id();
- /* Use existing clock_event for cpu 0 */
- if (!smp_processor_id())
- return 0;
-
u = readl(local_base + TIMER_CTRL_OFF);
if (timer25Mhz)
writel(u | TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
else
writel(u & ~TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
- evt->name = armada_370_xp_clkevt.name;
- evt->irq= armada_370_xp_clkevt.irq;
- evt->features = armada_370_xp_clkevt.features;
- evt->shift = armada_370_xp_clkevt.shift;
- evt->rating = armada_370_xp_clkevt.rating,
+ evt->name = "armada_370_xp_per_cpu_tick",
+ evt->features = CLOCK_EVT_FEAT_ONESHOT |
+ CLOCK_EVT_FEAT_PERIODIC;
+ evt->shift = 32,
+ evt->rating = 300,
evt->set_next_event = armada_370_xp_clkevt_next_event,
evt->set_mode = armada_370_xp_clkevt_mode,
+ evt->irq= armada_370_xp_clkevt_irq;
evt->cpumask= cpumask_of(cpu);
- *__this_cpu_ptr(percpu_armada_370_xp_evt) = evt;
-
clockevents_config_and_register(evt, timer_clk, 1, 0xfffe);
enable_percpu_irq(evt->irq, 0);
return 0;
}
-static void armada_370_xp_timer_stop(struct clock_event_device *evt)
+static void __cpuinit armada_370_xp_timer_stop(struct clock_event_device *evt)
{
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
disable_percpu_irq(evt->irq);
}
-static struct local_timer_ops armada_370_xp_local_timer_ops __cpuinitdata = {
- .setup = armada_370_xp_timer_setup,
- .stop = armada_370_xp_timer_stop,
+static int __cpuinit armada_370_xp_timer_cpu_notify(struct notifier_block
*self,
+ unsigned long action, void *hcpu)
+{
+ struct clock_event_device *evt = this_cpu_ptr(armada_370_xp_evt);
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ armada_370_xp_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ armada_370_xp_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block armada_370_xp_timer_cpu_nb __cpuinitdata = {
+ .notifier_call = armada_370_xp_timer_cpu_notify,
};
void __init armada_370_xp_timer_init(void)
@@ -224,9 +228,6 @@ void __init armada_370_xp_timer_init(void)
if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
/* The fixed 25MHz timer is available so let's use it */
- u = readl(local_base + TIMER_CTRL_OFF);
- writel(u | TIMER0_25MHZ,
- local_base + TIMER_CTRL_OFF);
u = readl(timer_base + TIMER_CTRL_OFF);
writel(u | TIMER0_25MHZ,
timer_base + TIMER_CTRL_OFF);
@@ -236,9 +237,6 @@ void __init armada_370_xp_timer_init(void)
struct clk *clk = of_clk_get(np, 0);
WARN_ON(IS
[PATCH 6/8] clocksource: time-armada-370-xp: Fix sparse warning
drivers/clocksource/time-armada-370-xp.c:217:13: warning: symbol 'armada_370_xp_timer_init' was not declared. Should it be static? Also remove the __init marking in the prototype as it's unnecessary and drop the init.h file. Cc: Gregory CLEMENT Signed-off-by: Stephen Boyd --- drivers/clocksource/time-armada-370-xp.c | 3 ++- include/linux/time-armada-370-xp.h | 4 +--- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c index 47a6730..efe4aef 100644 --- a/drivers/clocksource/time-armada-370-xp.c +++ b/drivers/clocksource/time-armada-370-xp.c @@ -27,10 +27,11 @@ #include #include #include +#include +#include #include #include -#include /* * Timer block registers. */ diff --git a/include/linux/time-armada-370-xp.h b/include/linux/time-armada-370-xp.h index dfdfdc0..6fb0856 100644 --- a/include/linux/time-armada-370-xp.h +++ b/include/linux/time-armada-370-xp.h @@ -11,8 +11,6 @@ #ifndef __TIME_ARMADA_370_XPPRCMU_H #define __TIME_ARMADA_370_XPPRCMU_H -#include - -void __init armada_370_xp_timer_init(void); +void armada_370_xp_timer_init(void); #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] ARM: smp: Remove local timer API
There are no more users of this API, remove it.
Cc: Russell King
Signed-off-by: Stephen Boyd
---
arch/arm/Kconfig | 12 +--
arch/arm/include/asm/localtimer.h | 34
arch/arm/kernel/smp.c | 67 ++-
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mach-omap2/timer.c | 7
5 files changed, 11 insertions(+), 110 deletions(-)
delete mode 100644 arch/arm/include/asm/localtimer.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dedf02b..7d4338d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1527,6 +1527,7 @@ config SMP
depends on HAVE_SMP
depends on MMU
select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
+ select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
select USE_GENERIC_SMP_HELPERS
help
This enables support for systems with more than one CPU. If you have
@@ -1646,17 +1647,6 @@ config ARM_PSCI
0022A ("Power State Coordination Interface System Software on
ARM processors").
-config LOCAL_TIMERS
- bool "Use local timer interrupts"
- depends on SMP
- default y
- select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
- help
- Enable support for local timers on SMP platforms, rather then the
- legacy IPI broadcast method. Local timers allows the system
- accounting to be spread across the timer interval, preventing a
- "thundering herd" at every timer tick.
-
config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
diff --git a/arch/arm/include/asm/localtimer.h
b/arch/arm/include/asm/localtimer.h
deleted file mode 100644
index f77ffc1..000
--- a/arch/arm/include/asm/localtimer.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * arch/arm/include/asm/localtimer.h
- *
- * Copyright (C) 2004-2005 ARM Ltd.
- *
- * 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_ARM_LOCALTIMER_H
-#define __ASM_ARM_LOCALTIMER_H
-
-#include
-
-struct clock_event_device;
-
-struct local_timer_ops {
- int (*setup)(struct clock_event_device *);
- void (*stop)(struct clock_event_device *);
-};
-
-#ifdef CONFIG_LOCAL_TIMERS
-/*
- * Register a local timer driver
- */
-int local_timer_register(struct local_timer_ops *);
-#else
-static inline int local_timer_register(struct local_timer_ops *ops)
-{
- return -ENXIO;
-}
-#endif
-
-#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2d5197d..f628c79 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -133,8 +132,6 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
}
#ifdef CONFIG_HOTPLUG_CPU
-static void percpu_timer_stop(void);
-
static int platform_cpu_kill(unsigned int cpu)
{
if (smp_ops.cpu_kill)
@@ -178,11 +175,6 @@ int __cpuinit __cpu_disable(void)
migrate_irqs();
/*
-* Stop the local timer for this CPU.
-*/
- percpu_timer_stop();
-
- /*
* Flush user cache and TLB mappings, and then remove this CPU
* from the vm mask set of all processes.
*
@@ -269,7 +261,7 @@ static void __cpuinit smp_store_cpu_info(unsigned int cpuid)
store_cpu_topology(cpuid);
}
-static void percpu_timer_setup(void);
+static void broadcast_timer_setup(void);
/*
* This is the secondary CPU boot entry. We're using this CPUs
@@ -325,9 +317,9 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
complete(&cpu_running);
/*
-* Setup the percpu timer for this CPU.
+* Setup the dummy broadcast timer for this CPU.
*/
- percpu_timer_setup();
+ broadcast_timer_setup();
local_irq_enable();
local_fiq_enable();
@@ -375,10 +367,10 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
max_cpus = ncores;
if (ncores > 1 && max_cpus) {
/*
-* Enable the local timer or broadcast device for the
+* Enable the dummy broadcast device for the
* boot CPU, but only if we have more than one CPU.
*/
- percpu_timer_setup();
+ broadcast_timer_setup();
/*
* Initialise the present map, which describes the set of CPUs
@@ -473,8 +465,12 @@ static void broadcast_timer_set_mode(enum clock_event_mode
mode,
{
}
-static void __cpuinit broadcast_timer_setup(struct clock_event_device *evt)
+static void __cpuinit broadcast_timer_setup(void)
{
+ unsigned int cpu = smp_processor_id();
+ struct clock_event_devi
[PATCH 2/8] ARM: smp_twd: Divorce smp_twd from local timer API
Separate the smp_twd timers from the local timer API. This will
allow us to remove ARM local timer support in the near future and
gets us closer to moving this driver to drivers/clocksource.
Cc: Russell King
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/smp_twd.c | 48 +++
1 file changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index c092115..2439843 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,7 +24,6 @@
#include
#include
-#include
/* set up by the platform code */
static void __iomem *twd_base;
@@ -32,7 +32,7 @@ static struct clk *twd_clk;
static unsigned long twd_timer_rate;
static DEFINE_PER_CPU(bool, percpu_setup_called);
-static struct clock_event_device __percpu **twd_evt;
+static struct clock_event_device __percpu *twd_evt;
static int twd_ppi;
static void twd_set_mode(enum clock_event_mode mode,
@@ -105,7 +105,7 @@ static void twd_update_frequency(void *new_rate)
{
twd_timer_rate = *((unsigned long *) new_rate);
- clockevents_update_freq(*__this_cpu_ptr(twd_evt), twd_timer_rate);
+ clockevents_update_freq(__this_cpu_ptr(twd_evt), twd_timer_rate);
}
static int twd_rate_change(struct notifier_block *nb,
@@ -131,7 +131,7 @@ static struct notifier_block twd_clk_nb = {
static int twd_clk_init(void)
{
- if (twd_evt && *__this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
+ if (twd_evt && __this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
return clk_notifier_register(twd_clk, &twd_clk_nb);
return 0;
@@ -150,7 +150,7 @@ static void twd_update_frequency(void *data)
{
twd_timer_rate = clk_get_rate(twd_clk);
- clockevents_update_freq(*__this_cpu_ptr(twd_evt), twd_timer_rate);
+ clockevents_update_freq(__this_cpu_ptr(twd_evt), twd_timer_rate);
}
static int twd_cpufreq_transition(struct notifier_block *nb,
@@ -176,7 +176,7 @@ static struct notifier_block twd_cpufreq_nb = {
static int twd_cpufreq_init(void)
{
- if (twd_evt && *__this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
+ if (twd_evt && __this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
return cpufreq_register_notifier(&twd_cpufreq_nb,
CPUFREQ_TRANSITION_NOTIFIER);
@@ -266,7 +266,6 @@ static void twd_get_clock(struct device_node *np)
*/
static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
{
- struct clock_event_device **this_cpu_clk;
int cpu = smp_processor_id();
/*
@@ -275,7 +274,7 @@ static int __cpuinit twd_timer_setup(struct
clock_event_device *clk)
*/
if (per_cpu(percpu_setup_called, cpu)) {
__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
- clockevents_register_device(*__this_cpu_ptr(twd_evt));
+ clockevents_register_device(__this_cpu_ptr(twd_evt));
enable_percpu_irq(clk->irq, 0);
return 0;
}
@@ -296,9 +295,7 @@ static int __cpuinit twd_timer_setup(struct
clock_event_device *clk)
clk->set_mode = twd_set_mode;
clk->set_next_event = twd_set_next_event;
clk->irq = twd_ppi;
-
- this_cpu_clk = __this_cpu_ptr(twd_evt);
- *this_cpu_clk = clk;
+ clk->cpumask = cpumask_of(cpu);
clockevents_config_and_register(clk, twd_timer_rate,
0xf, 0x);
@@ -307,16 +304,32 @@ static int __cpuinit twd_timer_setup(struct
clock_event_device *clk)
return 0;
}
-static struct local_timer_ops twd_lt_ops __cpuinitdata = {
- .setup = twd_timer_setup,
- .stop = twd_timer_stop,
+static int __cpuinit twd_timer_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ struct clock_event_device *evt = this_cpu_ptr(twd_evt);
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ twd_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ twd_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block twd_timer_cpu_nb __cpuinitdata = {
+ .notifier_call = twd_timer_cpu_notify,
};
static int __init twd_local_timer_common_register(struct device_node *np)
{
int err;
- twd_evt = alloc_percpu(struct clock_event_device *);
+ twd_evt = alloc_percpu(struct clock_event_device);
if (!twd_evt) {
err = -ENOMEM;
goto out_free;
@@ -328,10 +341,13 @@ static int __init twd_local_timer_common_register(struct
device_node *np)
goto out_free;
}
- err = local_timer_reg
[PATCH 3/8] ARM: EXYNOS4: Divorce mct from local timer API
Separate the mct local timers from the local timer API. This will
allow us to remove ARM local timer support in the near future and
gets us closer to moving this driver to drivers/clocksource.
Cc: Kukjin Kim
Signed-off-by: Stephen Boyd
---
arch/arm/mach-exynos/mct.c | 53 --
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index c9d6650..5a9a73f 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -16,13 +16,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
@@ -42,7 +42,7 @@ static unsigned long clk_rate;
static unsigned int mct_int_type;
struct mct_clock_event_device {
- struct clock_event_device *evt;
+ struct clock_event_device evt;
void __iomem *base;
char name[10];
};
@@ -264,8 +264,6 @@ static void exynos4_clockevent_init(void)
setup_irq(EXYNOS4_IRQ_MCT_G0, &mct_comp_event_irq);
}
-#ifdef CONFIG_LOCAL_TIMERS
-
static DEFINE_PER_CPU(struct mct_clock_event_device, percpu_mct_tick);
/* Clock event handling */
@@ -338,7 +336,7 @@ static inline void exynos4_tick_set_mode(enum
clock_event_mode mode,
static int exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
{
- struct clock_event_device *evt = mevt->evt;
+ struct clock_event_device *evt = &mevt->evt;
/*
* This is for supporting oneshot mode.
@@ -360,7 +358,7 @@ static int exynos4_mct_tick_clear(struct
mct_clock_event_device *mevt)
static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
{
struct mct_clock_event_device *mevt = dev_id;
- struct clock_event_device *evt = mevt->evt;
+ struct clock_event_device *evt = &mevt->evt;
exynos4_mct_tick_clear(mevt);
@@ -388,7 +386,6 @@ static int __cpuinit exynos4_local_timer_setup(struct
clock_event_device *evt)
int mct_lx_irq;
mevt = this_cpu_ptr(&percpu_mct_tick);
- mevt->evt = evt;
mevt->base = EXYNOS4_MCT_L_BASE(cpu);
sprintf(mevt->name, "mct_tick%d", cpu);
@@ -426,7 +423,7 @@ static int __cpuinit exynos4_local_timer_setup(struct
clock_event_device *evt)
return 0;
}
-static void exynos4_local_timer_stop(struct clock_event_device *evt)
+static void __cpuinit exynos4_local_timer_stop(struct clock_event_device *evt)
{
unsigned int cpu = smp_processor_id();
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
@@ -439,22 +436,38 @@ static void exynos4_local_timer_stop(struct
clock_event_device *evt)
disable_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER);
}
-static struct local_timer_ops exynos4_mct_tick_ops __cpuinitdata = {
- .setup = exynos4_local_timer_setup,
- .stop = exynos4_local_timer_stop,
+static int __cpuinit exynos4_mct_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
+ struct clock_event_device *evt = &mevt->evt;
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ exynos4_local_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ exynos4_local_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block exynos4_mct_cpu_nb __cpuinitdata = {
+ .notifier_call = exynos4_mct_cpu_notify,
};
-#endif /* CONFIG_LOCAL_TIMERS */
static void __init exynos4_timer_resources(void)
{
+ int err;
+ struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
struct clk *mct_clk;
mct_clk = clk_get(NULL, "xtal");
clk_rate = clk_get_rate(mct_clk);
-#ifdef CONFIG_LOCAL_TIMERS
if (mct_int_type == MCT_INT_PPI) {
- int err;
err = request_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER,
exynos4_mct_tick_isr, "MCT",
@@ -463,8 +476,16 @@ static void __init exynos4_timer_resources(void)
EXYNOS_IRQ_MCT_LOCALTIMER, err);
}
- local_timer_register(&exynos4_mct_tick_ops);
-#endif /* CONFIG_LOCAL_TIMERS */
+ err = register_cpu_notifier(&exynos4_mct_cpu_nb);
+ if (err)
+ goto out_irq;
+
+ /* Immediately configure the timer on the boot CPU */
+ exynos4_local_timer_setup(&mevt->evt);
+ return;
+
+out_irq:
+ free_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER, &percpu_mct_tick);
}
void __init exynos4_timer_init(void)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
[PATCH 5/8] ARM: MSM: Divorce msm_timer from local timer API
Separate the msm_timer from the local timer API. This will allow
us to remove ARM local timer support in the near future and gets
us closer to moving this driver to drivers/clocksource.
Cc: David Brown
Cc: Daniel Walker
Cc: Bryan Huntsman
Signed-off-by: Stephen Boyd
---
arch/arm/mach-msm/timer.c | 125 +-
1 file changed, 67 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 2969027..4675c5e 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -25,7 +26,6 @@
#include
#include
-#include
#include
#include "common.h"
@@ -46,7 +46,7 @@ static void __iomem *event_base;
static irqreturn_t msm_timer_interrupt(int irq, void *dev_id)
{
- struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+ struct clock_event_device *evt = dev_id;
/* Stop the timer tick */
if (evt->mode == CLOCK_EVT_MODE_ONESHOT) {
u32 ctrl = readl_relaxed(event_base + TIMER_ENABLE);
@@ -90,18 +90,7 @@ static void msm_timer_set_mode(enum clock_event_mode mode,
writel_relaxed(ctrl, event_base + TIMER_ENABLE);
}
-static struct clock_event_device msm_clockevent = {
- .name = "gp_timer",
- .features = CLOCK_EVT_FEAT_ONESHOT,
- .rating = 200,
- .set_next_event = msm_timer_set_next_event,
- .set_mode = msm_timer_set_mode,
-};
-
-static union {
- struct clock_event_device *evt;
- struct clock_event_device * __percpu *percpu_evt;
-} msm_evt;
+static struct clock_event_device __percpu *msm_evt;
static void __iomem *source_base;
@@ -127,40 +116,66 @@ static struct clocksource msm_clocksource = {
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
-#ifdef CONFIG_LOCAL_TIMERS
+static int msm_timer_irq;
+static int msm_timer_has_ppi;
+
static int __cpuinit msm_local_timer_setup(struct clock_event_device *evt)
{
- /* Use existing clock_event for cpu 0 */
- if (!smp_processor_id())
- return 0;
+ int cpu = smp_processor_id();
+ int err;
writel_relaxed(0, event_base + TIMER_ENABLE);
writel_relaxed(0, event_base + TIMER_CLEAR);
writel_relaxed(~0, event_base + TIMER_MATCH_VAL);
- evt->irq = msm_clockevent.irq;
+ evt->irq = msm_timer_irq;
evt->name = "local_timer";
- evt->features = msm_clockevent.features;
- evt->rating = msm_clockevent.rating;
+ evt->features = CLOCK_EVT_FEAT_ONESHOT;
+ evt->rating = 200;
evt->set_mode = msm_timer_set_mode;
evt->set_next_event = msm_timer_set_next_event;
+ evt->cpumask = cpumask_of(cpu);
+
+ clockevents_config_and_register(evt, GPT_HZ, 4, 0x);
+
+ if (msm_timer_has_ppi) {
+ enable_percpu_irq(evt->irq, IRQ_TYPE_EDGE_RISING);
+ } else {
+ err = request_irq(evt->irq, msm_timer_interrupt,
+ IRQF_TIMER | IRQF_NOBALANCING |
+ IRQF_TRIGGER_RISING, "gp_timer", evt);
+ if (err)
+ pr_err("request_irq failed\n");
+ }
- *__this_cpu_ptr(msm_evt.percpu_evt) = evt;
- clockevents_config_and_register(evt, GPT_HZ, 4, 0xf000);
- enable_percpu_irq(evt->irq, IRQ_TYPE_EDGE_RISING);
return 0;
}
-static void msm_local_timer_stop(struct clock_event_device *evt)
+static void __cpuinit msm_local_timer_stop(struct clock_event_device *evt)
{
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
disable_percpu_irq(evt->irq);
}
-static struct local_timer_ops msm_local_timer_ops __cpuinitdata = {
- .setup = msm_local_timer_setup,
- .stop = msm_local_timer_stop,
+static int __cpuinit msm_timer_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ struct clock_event_device *evt = this_cpu_ptr(msm_evt);
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ msm_local_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ msm_local_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block msm_timer_cpu_nb __cpuinitdata = {
+ .notifier_call = msm_timer_cpu_notify,
};
-#endif /* CONFIG_LOCAL_TIMERS */
static notrace u32 msm_sched_clock_read(void)
{
@@ -170,41 +185,35 @@ static notrace u32 msm_sched_clock_read(void)
static void __init msm_timer_init(u32 dgt_hz, int sched_bits, int irq,
bool percpu)
{
- struct clock_event_device *ce = &msm_clockevent;
struct clocksource *cs = &msm_clocksource;
-
[PATCH 4/8] ARM: PRIMA2: Divorce timer-marco from local timer API
Separate the marco local timers from the local timer API. This
will allow us to remove ARM local timer support in the near future
and gets us closer to moving this driver to drivers/clocksource.
Cc: Barry Song
Signed-off-by: Stephen Boyd
---
arch/arm/mach-prima2/timer-marco.c | 98 --
1 file changed, 52 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-prima2/timer-marco.c
b/arch/arm/mach-prima2/timer-marco.c
index f4eea2e..d54aac2 100644
--- a/arch/arm/mach-prima2/timer-marco.c
+++ b/arch/arm/mach-prima2/timer-marco.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,7 +19,6 @@
#include
#include
#include
-#include
#include
#include "common.h"
@@ -154,13 +154,7 @@ static void sirfsoc_clocksource_resume(struct clocksource
*cs)
BIT(1) | BIT(0), sirfsoc_timer_base +
SIRFSOC_TIMER_64COUNTER_CTRL);
}
-static struct clock_event_device sirfsoc_clockevent = {
- .name = "sirfsoc_clockevent",
- .rating = 200,
- .features = CLOCK_EVT_FEAT_ONESHOT,
- .set_mode = sirfsoc_timer_set_mode,
- .set_next_event = sirfsoc_timer_set_next_event,
-};
+static struct clock_event_device __percpu *sirfsoc_clockevent;
static struct clocksource sirfsoc_clocksource = {
.name = "sirfsoc_clocksource",
@@ -176,11 +170,8 @@ static struct irqaction sirfsoc_timer_irq = {
.name = "sirfsoc_timer0",
.flags = IRQF_TIMER | IRQF_NOBALANCING,
.handler = sirfsoc_timer_interrupt,
- .dev_id = &sirfsoc_clockevent,
};
-#ifdef CONFIG_LOCAL_TIMERS
-
static struct irqaction sirfsoc_timer1_irq = {
.name = "sirfsoc_timer1",
.flags = IRQF_TIMER | IRQF_NOBALANCING,
@@ -189,56 +180,75 @@ static struct irqaction sirfsoc_timer1_irq = {
static int __cpuinit sirfsoc_local_timer_setup(struct clock_event_device *ce)
{
- /* Use existing clock_event for cpu 0 */
- if (!smp_processor_id())
- return 0;
+ int cpu = smp_processor_id();
+ struct irqaction *action;
+
+ if (cpu == 0)
+ action = &sirfsoc_timer_irq;
+ else
+ action = &sirfsoc_timer1_irq;
- ce->irq = sirfsoc_timer1_irq.irq;
+ ce->irq = action->irq;
ce->name = "local_timer";
- ce->features = sirfsoc_clockevent.features;
- ce->rating = sirfsoc_clockevent.rating;
+ ce->features = CLOCK_EVT_FEAT_ONESHOT;
+ ce->rating = 200;
ce->set_mode = sirfsoc_timer_set_mode;
ce->set_next_event = sirfsoc_timer_set_next_event;
- ce->shift = sirfsoc_clockevent.shift;
- ce->mult = sirfsoc_clockevent.mult;
- ce->max_delta_ns = sirfsoc_clockevent.max_delta_ns;
- ce->min_delta_ns = sirfsoc_clockevent.min_delta_ns;
+ clockevents_calc_mult_shift(ce, CLOCK_TICK_RATE, 60);
+ ce->max_delta_ns = clockevent_delta2ns(-2, ce);
+ ce->min_delta_ns = clockevent_delta2ns(2, ce);
+ ce->cpumask = cpumask_of(cpu);
- sirfsoc_timer1_irq.dev_id = ce;
- BUG_ON(setup_irq(ce->irq, &sirfsoc_timer1_irq));
- irq_set_affinity(sirfsoc_timer1_irq.irq, cpumask_of(1));
+ action->dev_id = ce;
+ BUG_ON(setup_irq(ce->irq, action));
+ irq_set_affinity(action->irq, cpumask_of(cpu));
clockevents_register_device(ce);
return 0;
}
-static void sirfsoc_local_timer_stop(struct clock_event_device *ce)
+static void __cpuinit sirfsoc_local_timer_stop(struct clock_event_device *ce)
{
+ int cpu = smp_processor_id();
+
sirfsoc_timer_count_disable(1);
- remove_irq(sirfsoc_timer1_irq.irq, &sirfsoc_timer1_irq);
+ if (cpu == 0)
+ remove_irq(sirfsoc_timer_irq.irq, &sirfsoc_timer_irq);
+ else
+ remove_irq(sirfsoc_timer1_irq.irq, &sirfsoc_timer1_irq);
+}
+
+static int __cpuinit sirfsoc_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ struct clock_event_device *evt = this_cpu_ptr(sirfsoc_clockevent);
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ sirfsoc_local_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ sirfsoc_local_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
}
-static struct local_timer_ops sirfsoc_local_timer_ops __cpuinitdata = {
- .setup = sirfsoc_local_timer_setup,
- .stop = sirfsoc_local_timer_stop,
+static struct notifier_block sirfsoc_cpu_nb __cpuinitdata = {
+ .notifier_call = sirfsoc_cpu_notify,
};
-#endif /* CONFIG_LOCAL_TIMERS */
static void __init sirfsoc_clockevent_init(void)
{
- clockevents_calc_mult_shift(&sirfsoc_clockevent, CLOCK_TI
[PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width
From: Steve Muckle The subarchitecture field in the fpsid register is 7 bits wide. The topmost bit is used to designate that the subarchitecture designer is not ARM. We use this field to determine which VFP version is supported by the CPU. Since the topmost bit is masked off we detect non-ARM subarchitectures as supporting only HWCAP_VFP and not HWCAP_VFPv3 as it should be for Qualcomm's processors. Use the proper width for the mask so that we report the correct elf_hwcap of non-ARM designed processors. Signed-off-by: Steve Muckle [sboyd: Expanded on commit text] Signed-off-by: Stephen Boyd --- arch/arm/include/asm/vfp.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/vfp.h b/arch/arm/include/asm/vfp.h index f4ab34f..76d3f69 100644 --- a/arch/arm/include/asm/vfp.h +++ b/arch/arm/include/asm/vfp.h @@ -21,7 +21,7 @@ #define FPSID_FORMAT_MASK (0x3 << FPSID_FORMAT_BIT) #define FPSID_NODOUBLE (1<<20) #define FPSID_ARCH_BIT (16) -#define FPSID_ARCH_MASK(0xF << FPSID_ARCH_BIT) +#define FPSID_ARCH_MASK(0x7F << FPSID_ARCH_BIT) #define FPSID_PART_BIT (8) #define FPSID_PART_MASK(0xFF << FPSID_PART_BIT) #define FPSID_VARIANT_BIT (4) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width
On 2/22/2013 10:27 AM, Will Deacon wrote:
> Hi guys,
>
> On Fri, Feb 22, 2013 at 08:08:05AM +, Stephen Boyd wrote:
>> From: Steve Muckle
>>
>> The subarchitecture field in the fpsid register is 7 bits wide.
>> The topmost bit is used to designate that the subarchitecture
>> designer is not ARM. We use this field to determine which VFP
>> version is supported by the CPU. Since the topmost bit is masked
>> off we detect non-ARM subarchitectures as supporting only
>> HWCAP_VFP and not HWCAP_VFPv3 as it should be for Qualcomm's
>> processors.
> I'm struggling to see why this has anything to do with the hwcaps being set
> incorrectly. What value do you have in fpsid? As far as I can tell, the
> subarchitecture bits 6:0 should start at 0x40 for you, right?
Yes it does.
>
> I can see cases for changing this code, I just don't see why it would go
> wrong in the case you're describing.
VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;
causes VFP_arch to be equal to 0 because 0x40 & 0xf == 0.
and then a little bit later we have
if (VFP_arch >= 2) {
elf_hwcap |= HWCAP_VFPv3;
The branch is not taken so we never set VFPv3.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/11] ssbi: Use regular init level
On 03/12/13 11:41, David Brown wrote:
> With device tree, and deferred probe, it is no longer necessary to
> make sure that the ssbi bus driver is initialized very early. Restore
> to a regular module_init().
>
> Signed-off-by: David Brown
> ---
> drivers/ssbi/ssbi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/ssbi/ssbi.c b/drivers/ssbi/ssbi.c
> index 7ae8925..6878e55 100644
> --- a/drivers/ssbi/ssbi.c
> +++ b/drivers/ssbi/ssbi.c
> @@ -379,7 +379,7 @@ static int __init msm_ssbi_init(void)
> {
> return platform_driver_register(&msm_ssbi_driver);
> }
> -postcore_initcall(msm_ssbi_init);
> +module_init(msm_ssbi_init);
>
> static void __exit msm_ssbi_exit(void)
> {
With this change we can use module_platform_driver() too.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/11] SSBI: Convert SSBI to device tree
On 03/12/13 11:41, David Brown wrote:
> @@ -261,56 +263,13 @@ int msm_ssbi_write(struct device *dev, u16 addr, u8
> *buf, int len)
> }
> EXPORT_SYMBOL_GPL(msm_ssbi_write);
>
> -static int msm_ssbi_add_slave(struct msm_ssbi *ssbi,
> - const struct msm_ssbi_slave_info *slave)
> -{
> - struct platform_device *slave_pdev;
> - int ret;
> -
> - if (ssbi->slave) {
> - pr_err("slave already attached??\n");
> - return -EBUSY;
> - }
> -
> - slave_pdev = platform_device_alloc(slave->name, -1);
> - if (!slave_pdev) {
> - pr_err("cannot allocate pdev for slave '%s'", slave->name);
> - ret = -ENOMEM;
> - goto err;
> - }
> -
> - slave_pdev->dev.parent = ssbi->dev;
> - slave_pdev->dev.platform_data = slave->platform_data;
> -
> - ret = platform_device_add(slave_pdev);
> - if (ret) {
> - pr_err("cannot add slave platform device for '%s'\n",
> - slave->name);
> - goto err;
> - }
> -
> - ssbi->slave = &slave_pdev->dev;
> - return 0;
> -
> -err:
> - if (slave_pdev)
> - platform_device_put(slave_pdev);
> - return ret;
> -}
> -
> static int msm_ssbi_probe(struct platform_device *pdev)
> {
> - const struct msm_ssbi_platform_data *pdata = pdev->dev.platform_data;
Now that all this code is gone do we have a user of the
msm_ssbi_platform_data struct? Why not remove it from the header file?
If you remove it from the header you can probably move the enum for
controller_type into this file too.
> @@ -334,7 +293,25 @@ static int msm_ssbi_probe(struct platform_device *pdev)
> ssbi->dev = &pdev->dev;
> platform_set_drvdata(pdev, ssbi);
>
> - ssbi->controller_type = pdata->controller_type;
> + type = of_get_property(np, "qcom,controller-type", NULL);
> + if (type == NULL) {
> + pr_err("Missing qcom,controller-type property\n");
This could be dev_err() considering you use dev_info() below.
> + ret = -EINVAL;
> + goto err_ssbi_controller;
> + }
> + dev_info(&pdev->dev, "SSBI controller type: '%s'\n", type);
> + if (strcmp(type, "ssbi") == 0)
> + ssbi->controller_type = MSM_SBI_CTRL_SSBI;
> + else if (strcmp(type, "ssbi2") == 0)
> + ssbi->controller_type = MSM_SBI_CTRL_SSBI2;
> + else if (strcmp(type, "pmic-arbiter") == 0)
> + ssbi->controller_type = MSM_SBI_CTRL_PMIC_ARBITER;
> + else {
> + pr_err("Unknown qcom,controller-type\n");
dev_err()?
> @@ -370,12 +347,18 @@ static int msm_ssbi_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static struct of_device_id ssbi_match_table[] = {
const?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: proc: Add Krait proc info
On 03/07/13 22:41, Will Deacon wrote: > On Wed, Mar 06, 2013 at 05:20:32AM +0000, Stephen Boyd wrote: >> On 03/05/13 14:03, Stephen Boyd wrote: >>> On 03/05/13 00:34, Will Deacon wrote: >>>> I was looking at this the other day and wondered whether we could set >>>> HWCAP_IDIV in __v7_setup, depending on ID_ISAR0[27:24]. I can't immediately >>>> think why that would be difficult, but similarly there may well be a reason >>>> why we assign it like this. >>>> >>>> Fancy taking a look? >>> Ok I'll take a look. >> Hmm. I wonder if we did it this way because between version B and C of >> DDI0406 the definition of those bits changed. >> >> In DDI0406B we have >> >> 0 - no support >> 1 - support >> >> and in DDI0406C we have >> >> 0 - no support >> 1 - support in Thumb >> 2 - support in Thumb and ARM > Well spotted, although I think this a documentation error. I've checked both > A7 and A15 and they both advertise '2' (although r0p0 TRM for A7 also gets > this wrong, the CPU does the right thing). What about the Cortex-R7? When I google "ARM ISAR0" the first hit is http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363e/Bgbfafej.html and in there it just says 1. > What about the Qualcomm CPUs? > It's set to 1 in some of our earlier Krait CPU designs, but we corrected it later on to say 2 because the hardware actually supports the instructions in both ARM and Thumb mode. Unfortunately, we mass produced some of these chips that say 1 so we still need to do the same kind of MIDR check. I'm going to send the patchset right now with all this in it. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: Work around faulty ISAR0 register in some Krait CPUs
Some early versions of the Krait CPU design incorrectly indicate
that they only support the UDIV and SDIV instructions in Thumb
mode when they actually support them in ARM and Thumb mode. It
seems that these CPUs follow the DDI0406B ARM ARM which has two
possible values for the divide instructions field, instead of the
DDI0406C document which has three possible values.
Work around this problem by checking the MIDR against Krait CPUs
with this faulty ISAR0 register and force the detection code
to indicate support in both modes.
Cc: Will Deacon
Cc: Stepan Moskovchenko
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/setup.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index bd27a70..34ec24e 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -362,6 +362,14 @@ static void __init idiv_setup(void)
divide_instrs = (read_cpuid_ext(CPUID_EXT_ISAR0) & 0x0f00) >> 24;
+ /*
+* Some Krait processors don't indicate support for SDIV and UDIV
+* instructions in the ARM instruction set, even though they actually
+* do support them.
+*/
+ if ((read_cpuid_id() & 0xff0ffc00) == 0x510f0400)
+ divide_instrs = 2;
+
switch (divide_instrs) {
case 2:
elf_hwcap |= HWCAP_IDIVA;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Detect UDIV/SDIV support from ISAR0
While attempting to upstream a patch to add the IDIV hwcap for Krait processors, Will suggested we move the code to read the ISAR0 register. This patchset does that and also works around the early Krait CPU designs that don't follow the latest ARM ARM for the ISAR0 register. Stephen Boyd (3): ARM: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n ARM: Detect support for SDIV/UDIV from ISAR0 register ARM: Work around faulty ISAR0 register in some Krait CPUs arch/arm/kernel/setup.c | 30 +- arch/arm/mm/proc-v7.S | 4 ++-- 2 files changed, 31 insertions(+), 3 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n
Don't advertise support for the SDIV/UDIV thumb instructions if the kernel is not compiled with support for thumb userspace. This is in line with how we remove the THUMB hwcap in these configurations. Cc: Will Deacon Cc: Stepan Moskovchenko Signed-off-by: Stephen Boyd --- arch/arm/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 3f6cbb2..e2c8bbf 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -484,7 +484,7 @@ static void __init setup_processor(void) list->elf_name, ENDIANNESS); elf_hwcap = list->elf_hwcap; #ifndef CONFIG_ARM_THUMB - elf_hwcap &= ~HWCAP_THUMB; + elf_hwcap &= ~(HWCAP_THUMB | HWCAP_IDIVT); #endif feat_v6_fixup(); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: Detect support for SDIV/UDIV from ISAR0 register
The ISAR0 register indicates support for the SDIV and UDIV
instructions in both the Thumb and ARM instruction set. Read the
register to detect the supported instructions and update the
elf_hwcap mask as appropriate. This is better than adding more
and more cpuid checks in proc-v7.S for each new cpu variant that
supports these instructions.
Cc: Will Deacon
Cc: Stepan Moskovchenko
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/setup.c | 20
arch/arm/mm/proc-v7.S | 4 ++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e2c8bbf..bd27a70 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -353,6 +353,23 @@ void __init early_print(const char *str, ...)
printk("%s", buf);
}
+static void __init idiv_setup(void)
+{
+ unsigned int divide_instrs;
+
+ if (cpu_architecture() < CPU_ARCH_ARMv7)
+ return;
+
+ divide_instrs = (read_cpuid_ext(CPUID_EXT_ISAR0) & 0x0f00) >> 24;
+
+ switch (divide_instrs) {
+ case 2:
+ elf_hwcap |= HWCAP_IDIVA;
+ case 1:
+ elf_hwcap |= HWCAP_IDIVT;
+ }
+}
+
static void __init feat_v6_fixup(void)
{
int id = read_cpuid_id();
@@ -483,6 +500,9 @@ static void __init setup_processor(void)
snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c",
list->elf_name, ENDIANNESS);
elf_hwcap = list->elf_hwcap;
+
+ idiv_setup();
+
#ifndef CONFIG_ARM_THUMB
elf_hwcap &= ~(HWCAP_THUMB | HWCAP_IDIVT);
#endif
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3a3c015..bcd3d48 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -420,7 +420,7 @@ __v7_pj4b_proc_info:
__v7_ca7mp_proc_info:
.long 0x410fc070
.long 0xff00
- __v7_proc __v7_ca7mp_setup, hwcaps = HWCAP_IDIV
+ __v7_proc __v7_ca7mp_setup
.size __v7_ca7mp_proc_info, . - __v7_ca7mp_proc_info
/*
@@ -430,7 +430,7 @@ __v7_ca7mp_proc_info:
__v7_ca15mp_proc_info:
.long 0x410fc0f0
.long 0xff00
- __v7_proc __v7_ca15mp_setup, hwcaps = HWCAP_IDIV
+ __v7_proc __v7_ca15mp_setup
.size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
/*
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 00/10] Remove ARM local timer API
In light of Mark Rutland's recent work on divorcing the ARM architected timers from the ARM local timer API and introducing a generic arch hook for broadcast it seems that we should remove the local timer API entirely. Doing so will reduce the architecture dependencies of our timer drivers, reduce code in ARM core, and simplify timer drivers because they no longer go through an architecture layer that is essentially a hotplug notifier. Previous attempts have been made[1] unsuccessfully. I'm hoping this can be accepted now so that we can clean up the timer drivers that are used in both UP and SMP situations. Right now these drivers have to ignore the timer setup callback on the boot CPU to avoid registering clockevents twice. This is not very symmetric and causes convuluted code that does the same thing in two places. Patches based on v3.9-rc2. I'm still looking for Acks/Tested-by on EXYNOS and PRIMA2. [1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705 Note: A hotplug notifier is used by both x86 for the apb_timer (see apbt_cpuhp_notify) and by metag (see arch_timer_cpu_notify in metag_generic.c) so this is not new. Changes since v2: * Bug fixes in smp_twd from Tony Lindgren's testing * Move smp_twd to use late_time_init hook * Collected Acks Changes since v1: * Picked up Mark's generic dummy timer driver * Split out omap changes into new patch Mark Rutland (1): clocksource: add generic dummy timer driver Stephen Boyd (9): ARM: smp: Remove duplicate dummy timer implementation ARM: smp_twd: Divorce smp_twd from local timer API ARM: OMAP2+: Divorce from local timer API ARM: EXYNOS4: Divorce mct from local timer API ARM: PRIMA2: Divorce timer-marco from local timer API ARM: msm: Divorce msm_timer from local timer API clocksource: time-armada-370-xp: Fix sparse warning clocksource: time-armada-370-xp: Divorce from local timer API ARM: smp: Remove local timer API arch/arm/Kconfig | 12 +-- arch/arm/include/asm/localtimer.h| 34 - arch/arm/kernel/smp.c| 87 - arch/arm/kernel/smp_twd.c| 64 ++-- arch/arm/mach-exynos/mct.c | 53 + arch/arm/mach-msm/timer.c| 125 +-- arch/arm/mach-omap2/Kconfig | 1 - arch/arm/mach-omap2/timer.c | 7 -- arch/arm/mach-prima2/timer-marco.c | 98 drivers/clocksource/Makefile | 1 + drivers/clocksource/dummy_timer.c| 67 + drivers/clocksource/time-armada-370-xp.c | 88 ++ include/linux/time-armada-370-xp.h | 4 +- 13 files changed, 309 insertions(+), 332 deletions(-) delete mode 100644 arch/arm/include/asm/localtimer.h create mode 100644 drivers/clocksource/dummy_timer.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 04/10] ARM: OMAP2+: Divorce from local timer API
Now that the TWD doesn't rely on the local timer API, OMAP can
stop selecting it in Kconfig and relying on the config option to
decide if it should call smp_twd functions.
Acked-by: Santosh Shilimkar
Acked-by: Tony Lindgren
Signed-off-by: Stephen Boyd
---
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mach-omap2/timer.c | 7 ---
2 files changed, 8 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 49ac3df..6e1f871 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -88,7 +88,6 @@ config ARCH_OMAP4
select CACHE_L2X0
select CPU_V7
select HAVE_SMP
- select LOCAL_TIMERS if SMP
select OMAP_INTERCONNECT
select PL310_ERRATA_588369
select PL310_ERRATA_727915
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2bdd4cf..c00a8f8 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -587,7 +587,6 @@ OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE,
"ti,timer-alwon",
#ifdef CONFIG_ARCH_OMAP4
OMAP_SYS_32K_TIMER_INIT(4, 1, OMAP4_32K_SOURCE, "ti,timer-alwon",
2, OMAP4_MPU_SOURCE);
-#ifdef CONFIG_LOCAL_TIMERS
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
void __init omap4_local_timer_init(void)
{
@@ -606,12 +605,6 @@ void __init omap4_local_timer_init(void)
pr_err("twd_local_timer_register failed %d\n", err);
}
}
-#else /* CONFIG_LOCAL_TIMERS */
-void __init omap4_local_timer_init(void)
-{
- omap4_sync32k_timer_init();
-}
-#endif /* CONFIG_LOCAL_TIMERS */
#endif /* CONFIG_ARCH_OMAP4 */
#ifdef CONFIG_SOC_OMAP5
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 09/10] clocksource: time-armada-370-xp: Divorce from local timer API
Separate the armada 370xp local timers from the local timer API.
This will allow us to remove ARM local timer support in the near
future and makes this driver multi-architecture friendly.
Cc: Gregory CLEMENT
Signed-off-by: Stephen Boyd
---
drivers/clocksource/time-armada-370-xp.c | 85 ++--
1 file changed, 38 insertions(+), 47 deletions(-)
diff --git a/drivers/clocksource/time-armada-370-xp.c
b/drivers/clocksource/time-armada-370-xp.c
index efe4aef..ee2e50c5 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,7 +32,6 @@
#include
#include
-#include
/*
* Timer block registers.
*/
@@ -70,7 +70,7 @@ static bool timer25Mhz = true;
*/
static u32 ticks_per_jiffy;
-static struct clock_event_device __percpu **percpu_armada_370_xp_evt;
+static struct clock_event_device __percpu *armada_370_xp_evt;
static u32 notrace armada_370_xp_read_sched_clock(void)
{
@@ -143,14 +143,7 @@ armada_370_xp_clkevt_mode(enum clock_event_mode mode,
}
}
-static struct clock_event_device armada_370_xp_clkevt = {
- .name = "armada_370_xp_per_cpu_tick",
- .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
- .shift = 32,
- .rating = 300,
- .set_next_event = armada_370_xp_clkevt_next_event,
- .set_mode = armada_370_xp_clkevt_mode,
-};
+static int armada_370_xp_clkevt_irq;
static irqreturn_t armada_370_xp_timer_interrupt(int irq, void *dev_id)
{
@@ -173,42 +166,53 @@ static int __cpuinit armada_370_xp_timer_setup(struct
clock_event_device *evt)
u32 u;
int cpu = smp_processor_id();
- /* Use existing clock_event for cpu 0 */
- if (!smp_processor_id())
- return 0;
-
u = readl(local_base + TIMER_CTRL_OFF);
if (timer25Mhz)
writel(u | TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
else
writel(u & ~TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
- evt->name = armada_370_xp_clkevt.name;
- evt->irq= armada_370_xp_clkevt.irq;
- evt->features = armada_370_xp_clkevt.features;
- evt->shift = armada_370_xp_clkevt.shift;
- evt->rating = armada_370_xp_clkevt.rating,
+ evt->name = "armada_370_xp_per_cpu_tick",
+ evt->features = CLOCK_EVT_FEAT_ONESHOT |
+ CLOCK_EVT_FEAT_PERIODIC;
+ evt->shift = 32,
+ evt->rating = 300,
evt->set_next_event = armada_370_xp_clkevt_next_event,
evt->set_mode = armada_370_xp_clkevt_mode,
+ evt->irq= armada_370_xp_clkevt_irq;
evt->cpumask= cpumask_of(cpu);
- *__this_cpu_ptr(percpu_armada_370_xp_evt) = evt;
-
clockevents_config_and_register(evt, timer_clk, 1, 0xfffe);
enable_percpu_irq(evt->irq, 0);
return 0;
}
-static void armada_370_xp_timer_stop(struct clock_event_device *evt)
+static void __cpuinit armada_370_xp_timer_stop(struct clock_event_device *evt)
{
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
disable_percpu_irq(evt->irq);
}
-static struct local_timer_ops armada_370_xp_local_timer_ops __cpuinitdata = {
- .setup = armada_370_xp_timer_setup,
- .stop = armada_370_xp_timer_stop,
+static int __cpuinit armada_370_xp_timer_cpu_notify(struct notifier_block
*self,
+ unsigned long action, void *hcpu)
+{
+ struct clock_event_device *evt = this_cpu_ptr(armada_370_xp_evt);
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ armada_370_xp_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ armada_370_xp_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block armada_370_xp_timer_cpu_nb __cpuinitdata = {
+ .notifier_call = armada_370_xp_timer_cpu_notify,
};
void __init armada_370_xp_timer_init(void)
@@ -224,9 +228,6 @@ void __init armada_370_xp_timer_init(void)
if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
/* The fixed 25MHz timer is available so let's use it */
- u = readl(local_base + TIMER_CTRL_OFF);
- writel(u | TIMER0_25MHZ,
- local_base + TIMER_CTRL_OFF);
u = readl(timer_base + TIMER_CTRL_OFF);
writel(u | TIMER0_25MHZ,
timer_base + TIMER_CTRL_OFF);
@@ -236,9 +237,6 @@ void __init armada_370_xp_timer_init(void)
struct clk *clk = of_clk_get(np, 0);
WARN_ON(IS
[PATCHv3 10/10] ARM: smp: Remove local timer API
There are no more users of this API, remove it.
Cc: Russell King
Acked-by: Tony Lindgren
Signed-off-by: Stephen Boyd
---
arch/arm/Kconfig | 10 --
arch/arm/include/asm/localtimer.h | 34 ---
arch/arm/kernel/smp.c | 69 ---
3 files changed, 113 deletions(-)
delete mode 100644 arch/arm/include/asm/localtimer.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ad2ccf..f1a4c57 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1647,16 +1647,6 @@ config ARM_PSCI
0022A ("Power State Coordination Interface System Software on
ARM processors").
-config LOCAL_TIMERS
- bool "Use local timer interrupts"
- depends on SMP
- default y
- help
- Enable support for local timers on SMP platforms, rather then the
- legacy IPI broadcast method. Local timers allows the system
- accounting to be spread across the timer interval, preventing a
- "thundering herd" at every timer tick.
-
config ARCH_NR_GPIO
int
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
diff --git a/arch/arm/include/asm/localtimer.h
b/arch/arm/include/asm/localtimer.h
deleted file mode 100644
index f77ffc1..000
--- a/arch/arm/include/asm/localtimer.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * arch/arm/include/asm/localtimer.h
- *
- * Copyright (C) 2004-2005 ARM Ltd.
- *
- * 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_ARM_LOCALTIMER_H
-#define __ASM_ARM_LOCALTIMER_H
-
-#include
-
-struct clock_event_device;
-
-struct local_timer_ops {
- int (*setup)(struct clock_event_device *);
- void (*stop)(struct clock_event_device *);
-};
-
-#ifdef CONFIG_LOCAL_TIMERS
-/*
- * Register a local timer driver
- */
-int local_timer_register(struct local_timer_ops *);
-#else
-static inline int local_timer_register(struct local_timer_ops *ops)
-{
- return -ENXIO;
-}
-#endif
-
-#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 4de4d14..4c49138 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -133,8 +132,6 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
}
#ifdef CONFIG_HOTPLUG_CPU
-static void percpu_timer_stop(void);
-
static int platform_cpu_kill(unsigned int cpu)
{
if (smp_ops.cpu_kill)
@@ -178,11 +175,6 @@ int __cpuinit __cpu_disable(void)
migrate_irqs();
/*
-* Stop the local timer for this CPU.
-*/
- percpu_timer_stop();
-
- /*
* Flush user cache and TLB mappings, and then remove this CPU
* from the vm mask set of all processes.
*
@@ -269,8 +261,6 @@ static void __cpuinit smp_store_cpu_info(unsigned int cpuid)
store_cpu_topology(cpuid);
}
-static void percpu_timer_setup(void);
-
/*
* This is the secondary CPU boot entry. We're using this CPUs
* idle thread stack, but a set of temporary page tables.
@@ -325,11 +315,6 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
set_cpu_online(cpu, true);
complete(&cpu_running);
- /*
-* Setup the percpu timer for this CPU.
-*/
- percpu_timer_setup();
-
local_irq_enable();
local_fiq_enable();
@@ -376,12 +361,6 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
max_cpus = ncores;
if (ncores > 1 && max_cpus) {
/*
-* Enable the local timer or broadcast device for the
-* boot CPU, but only if we have more than one CPU.
-*/
- percpu_timer_setup();
-
- /*
* Initialise the present map, which describes the set of CPUs
* actually populated at the present time. A platform should
* re-initialize the map in the platforms smp_prepare_cpus()
@@ -457,11 +436,6 @@ u64 smp_irq_stat_cpu(unsigned int cpu)
return sum;
}
-/*
- * Timer (local or broadcast) support
- */
-static DEFINE_PER_CPU(struct clock_event_device, percpu_clockevent);
-
#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
void tick_broadcast(const struct cpumask *mask)
{
@@ -469,49 +443,6 @@ void tick_broadcast(const struct cpumask *mask)
}
#endif
-static struct local_timer_ops *lt_ops;
-
-#ifdef CONFIG_LOCAL_TIMERS
-int local_timer_register(struct local_timer_ops *ops)
-{
- if (!is_smp() || !setup_max_cpus)
- return -ENXIO;
-
- if (lt_ops)
- return -EBUSY;
-
- lt_ops = ops;
- return 0;
-}
-#endif
-
-static void __cpuinit percpu_timer_setup(void)
-{
- unsigned int cpu = smp_processor_id();
[PATCHv3 08/10] clocksource: time-armada-370-xp: Fix sparse warning
drivers/clocksource/time-armada-370-xp.c:217:13: warning: symbol 'armada_370_xp_timer_init' was not declared. Should it be static? Also remove the __init marking in the prototype as it's unnecessary and drop the init.h file. Cc: Gregory CLEMENT Signed-off-by: Stephen Boyd --- drivers/clocksource/time-armada-370-xp.c | 3 ++- include/linux/time-armada-370-xp.h | 4 +--- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c index 47a6730..efe4aef 100644 --- a/drivers/clocksource/time-armada-370-xp.c +++ b/drivers/clocksource/time-armada-370-xp.c @@ -27,10 +27,11 @@ #include #include #include +#include +#include #include #include -#include /* * Timer block registers. */ diff --git a/include/linux/time-armada-370-xp.h b/include/linux/time-armada-370-xp.h index dfdfdc0..6fb0856 100644 --- a/include/linux/time-armada-370-xp.h +++ b/include/linux/time-armada-370-xp.h @@ -11,8 +11,6 @@ #ifndef __TIME_ARMADA_370_XPPRCMU_H #define __TIME_ARMADA_370_XPPRCMU_H -#include - -void __init armada_370_xp_timer_init(void); +void armada_370_xp_timer_init(void); #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 07/10] ARM: msm: Divorce msm_timer from local timer API
Separate the msm_timer from the local timer API. This will allow
us to remove ARM local timer support in the near future and gets
us closer to moving this driver to drivers/clocksource.
Acked-by: David Brown
Cc: Daniel Walker
Cc: Bryan Huntsman
Signed-off-by: Stephen Boyd
---
arch/arm/mach-msm/timer.c | 125 +-
1 file changed, 67 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 2969027..4675c5e 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -25,7 +26,6 @@
#include
#include
-#include
#include
#include "common.h"
@@ -46,7 +46,7 @@ static void __iomem *event_base;
static irqreturn_t msm_timer_interrupt(int irq, void *dev_id)
{
- struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+ struct clock_event_device *evt = dev_id;
/* Stop the timer tick */
if (evt->mode == CLOCK_EVT_MODE_ONESHOT) {
u32 ctrl = readl_relaxed(event_base + TIMER_ENABLE);
@@ -90,18 +90,7 @@ static void msm_timer_set_mode(enum clock_event_mode mode,
writel_relaxed(ctrl, event_base + TIMER_ENABLE);
}
-static struct clock_event_device msm_clockevent = {
- .name = "gp_timer",
- .features = CLOCK_EVT_FEAT_ONESHOT,
- .rating = 200,
- .set_next_event = msm_timer_set_next_event,
- .set_mode = msm_timer_set_mode,
-};
-
-static union {
- struct clock_event_device *evt;
- struct clock_event_device * __percpu *percpu_evt;
-} msm_evt;
+static struct clock_event_device __percpu *msm_evt;
static void __iomem *source_base;
@@ -127,40 +116,66 @@ static struct clocksource msm_clocksource = {
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
-#ifdef CONFIG_LOCAL_TIMERS
+static int msm_timer_irq;
+static int msm_timer_has_ppi;
+
static int __cpuinit msm_local_timer_setup(struct clock_event_device *evt)
{
- /* Use existing clock_event for cpu 0 */
- if (!smp_processor_id())
- return 0;
+ int cpu = smp_processor_id();
+ int err;
writel_relaxed(0, event_base + TIMER_ENABLE);
writel_relaxed(0, event_base + TIMER_CLEAR);
writel_relaxed(~0, event_base + TIMER_MATCH_VAL);
- evt->irq = msm_clockevent.irq;
+ evt->irq = msm_timer_irq;
evt->name = "local_timer";
- evt->features = msm_clockevent.features;
- evt->rating = msm_clockevent.rating;
+ evt->features = CLOCK_EVT_FEAT_ONESHOT;
+ evt->rating = 200;
evt->set_mode = msm_timer_set_mode;
evt->set_next_event = msm_timer_set_next_event;
+ evt->cpumask = cpumask_of(cpu);
+
+ clockevents_config_and_register(evt, GPT_HZ, 4, 0x);
+
+ if (msm_timer_has_ppi) {
+ enable_percpu_irq(evt->irq, IRQ_TYPE_EDGE_RISING);
+ } else {
+ err = request_irq(evt->irq, msm_timer_interrupt,
+ IRQF_TIMER | IRQF_NOBALANCING |
+ IRQF_TRIGGER_RISING, "gp_timer", evt);
+ if (err)
+ pr_err("request_irq failed\n");
+ }
- *__this_cpu_ptr(msm_evt.percpu_evt) = evt;
- clockevents_config_and_register(evt, GPT_HZ, 4, 0xf000);
- enable_percpu_irq(evt->irq, IRQ_TYPE_EDGE_RISING);
return 0;
}
-static void msm_local_timer_stop(struct clock_event_device *evt)
+static void __cpuinit msm_local_timer_stop(struct clock_event_device *evt)
{
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
disable_percpu_irq(evt->irq);
}
-static struct local_timer_ops msm_local_timer_ops __cpuinitdata = {
- .setup = msm_local_timer_setup,
- .stop = msm_local_timer_stop,
+static int __cpuinit msm_timer_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ struct clock_event_device *evt = this_cpu_ptr(msm_evt);
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ msm_local_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ msm_local_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block msm_timer_cpu_nb __cpuinitdata = {
+ .notifier_call = msm_timer_cpu_notify,
};
-#endif /* CONFIG_LOCAL_TIMERS */
static notrace u32 msm_sched_clock_read(void)
{
@@ -170,41 +185,35 @@ static notrace u32 msm_sched_clock_read(void)
static void __init msm_timer_init(u32 dgt_hz, int sched_bits, int irq,
bool percpu)
{
- struct clock_event_device *ce = &msm_clockevent;
struct clocksource *cs = &am
[PATCHv3 06/10] ARM: PRIMA2: Divorce timer-marco from local timer API
Separate the marco local timers from the local timer API. This
will allow us to remove ARM local timer support in the near future
and gets us closer to moving this driver to drivers/clocksource.
Cc: Barry Song
Signed-off-by: Stephen Boyd
---
arch/arm/mach-prima2/timer-marco.c | 98 --
1 file changed, 52 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-prima2/timer-marco.c
b/arch/arm/mach-prima2/timer-marco.c
index f4eea2e..d54aac2 100644
--- a/arch/arm/mach-prima2/timer-marco.c
+++ b/arch/arm/mach-prima2/timer-marco.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,7 +19,6 @@
#include
#include
#include
-#include
#include
#include "common.h"
@@ -154,13 +154,7 @@ static void sirfsoc_clocksource_resume(struct clocksource
*cs)
BIT(1) | BIT(0), sirfsoc_timer_base +
SIRFSOC_TIMER_64COUNTER_CTRL);
}
-static struct clock_event_device sirfsoc_clockevent = {
- .name = "sirfsoc_clockevent",
- .rating = 200,
- .features = CLOCK_EVT_FEAT_ONESHOT,
- .set_mode = sirfsoc_timer_set_mode,
- .set_next_event = sirfsoc_timer_set_next_event,
-};
+static struct clock_event_device __percpu *sirfsoc_clockevent;
static struct clocksource sirfsoc_clocksource = {
.name = "sirfsoc_clocksource",
@@ -176,11 +170,8 @@ static struct irqaction sirfsoc_timer_irq = {
.name = "sirfsoc_timer0",
.flags = IRQF_TIMER | IRQF_NOBALANCING,
.handler = sirfsoc_timer_interrupt,
- .dev_id = &sirfsoc_clockevent,
};
-#ifdef CONFIG_LOCAL_TIMERS
-
static struct irqaction sirfsoc_timer1_irq = {
.name = "sirfsoc_timer1",
.flags = IRQF_TIMER | IRQF_NOBALANCING,
@@ -189,56 +180,75 @@ static struct irqaction sirfsoc_timer1_irq = {
static int __cpuinit sirfsoc_local_timer_setup(struct clock_event_device *ce)
{
- /* Use existing clock_event for cpu 0 */
- if (!smp_processor_id())
- return 0;
+ int cpu = smp_processor_id();
+ struct irqaction *action;
+
+ if (cpu == 0)
+ action = &sirfsoc_timer_irq;
+ else
+ action = &sirfsoc_timer1_irq;
- ce->irq = sirfsoc_timer1_irq.irq;
+ ce->irq = action->irq;
ce->name = "local_timer";
- ce->features = sirfsoc_clockevent.features;
- ce->rating = sirfsoc_clockevent.rating;
+ ce->features = CLOCK_EVT_FEAT_ONESHOT;
+ ce->rating = 200;
ce->set_mode = sirfsoc_timer_set_mode;
ce->set_next_event = sirfsoc_timer_set_next_event;
- ce->shift = sirfsoc_clockevent.shift;
- ce->mult = sirfsoc_clockevent.mult;
- ce->max_delta_ns = sirfsoc_clockevent.max_delta_ns;
- ce->min_delta_ns = sirfsoc_clockevent.min_delta_ns;
+ clockevents_calc_mult_shift(ce, CLOCK_TICK_RATE, 60);
+ ce->max_delta_ns = clockevent_delta2ns(-2, ce);
+ ce->min_delta_ns = clockevent_delta2ns(2, ce);
+ ce->cpumask = cpumask_of(cpu);
- sirfsoc_timer1_irq.dev_id = ce;
- BUG_ON(setup_irq(ce->irq, &sirfsoc_timer1_irq));
- irq_set_affinity(sirfsoc_timer1_irq.irq, cpumask_of(1));
+ action->dev_id = ce;
+ BUG_ON(setup_irq(ce->irq, action));
+ irq_set_affinity(action->irq, cpumask_of(cpu));
clockevents_register_device(ce);
return 0;
}
-static void sirfsoc_local_timer_stop(struct clock_event_device *ce)
+static void __cpuinit sirfsoc_local_timer_stop(struct clock_event_device *ce)
{
+ int cpu = smp_processor_id();
+
sirfsoc_timer_count_disable(1);
- remove_irq(sirfsoc_timer1_irq.irq, &sirfsoc_timer1_irq);
+ if (cpu == 0)
+ remove_irq(sirfsoc_timer_irq.irq, &sirfsoc_timer_irq);
+ else
+ remove_irq(sirfsoc_timer1_irq.irq, &sirfsoc_timer1_irq);
+}
+
+static int __cpuinit sirfsoc_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ struct clock_event_device *evt = this_cpu_ptr(sirfsoc_clockevent);
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ sirfsoc_local_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ sirfsoc_local_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
}
-static struct local_timer_ops sirfsoc_local_timer_ops __cpuinitdata = {
- .setup = sirfsoc_local_timer_setup,
- .stop = sirfsoc_local_timer_stop,
+static struct notifier_block sirfsoc_cpu_nb __cpuinitdata = {
+ .notifier_call = sirfsoc_cpu_notify,
};
-#endif /* CONFIG_LOCAL_TIMERS */
static void __init sirfsoc_clockevent_init(void)
{
- clockevents_calc_mult_shift(&sirfsoc_clockevent, CLOCK_TI
[PATCHv3 05/10] ARM: EXYNOS4: Divorce mct from local timer API
Separate the mct local timers from the local timer API. This will
allow us to remove ARM local timer support in the near future and
gets us closer to moving this driver to drivers/clocksource.
Cc: Kukjin Kim
Signed-off-by: Stephen Boyd
---
arch/arm/mach-exynos/mct.c | 53 --
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index c9d6650..5a9a73f 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -16,13 +16,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
@@ -42,7 +42,7 @@ static unsigned long clk_rate;
static unsigned int mct_int_type;
struct mct_clock_event_device {
- struct clock_event_device *evt;
+ struct clock_event_device evt;
void __iomem *base;
char name[10];
};
@@ -264,8 +264,6 @@ static void exynos4_clockevent_init(void)
setup_irq(EXYNOS4_IRQ_MCT_G0, &mct_comp_event_irq);
}
-#ifdef CONFIG_LOCAL_TIMERS
-
static DEFINE_PER_CPU(struct mct_clock_event_device, percpu_mct_tick);
/* Clock event handling */
@@ -338,7 +336,7 @@ static inline void exynos4_tick_set_mode(enum
clock_event_mode mode,
static int exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
{
- struct clock_event_device *evt = mevt->evt;
+ struct clock_event_device *evt = &mevt->evt;
/*
* This is for supporting oneshot mode.
@@ -360,7 +358,7 @@ static int exynos4_mct_tick_clear(struct
mct_clock_event_device *mevt)
static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
{
struct mct_clock_event_device *mevt = dev_id;
- struct clock_event_device *evt = mevt->evt;
+ struct clock_event_device *evt = &mevt->evt;
exynos4_mct_tick_clear(mevt);
@@ -388,7 +386,6 @@ static int __cpuinit exynos4_local_timer_setup(struct
clock_event_device *evt)
int mct_lx_irq;
mevt = this_cpu_ptr(&percpu_mct_tick);
- mevt->evt = evt;
mevt->base = EXYNOS4_MCT_L_BASE(cpu);
sprintf(mevt->name, "mct_tick%d", cpu);
@@ -426,7 +423,7 @@ static int __cpuinit exynos4_local_timer_setup(struct
clock_event_device *evt)
return 0;
}
-static void exynos4_local_timer_stop(struct clock_event_device *evt)
+static void __cpuinit exynos4_local_timer_stop(struct clock_event_device *evt)
{
unsigned int cpu = smp_processor_id();
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
@@ -439,22 +436,38 @@ static void exynos4_local_timer_stop(struct
clock_event_device *evt)
disable_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER);
}
-static struct local_timer_ops exynos4_mct_tick_ops __cpuinitdata = {
- .setup = exynos4_local_timer_setup,
- .stop = exynos4_local_timer_stop,
+static int __cpuinit exynos4_mct_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
+ struct clock_event_device *evt = &mevt->evt;
+
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_STARTING:
+ exynos4_local_timer_setup(evt);
+ break;
+ case CPU_DYING:
+ exynos4_local_timer_stop(evt);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block exynos4_mct_cpu_nb __cpuinitdata = {
+ .notifier_call = exynos4_mct_cpu_notify,
};
-#endif /* CONFIG_LOCAL_TIMERS */
static void __init exynos4_timer_resources(void)
{
+ int err;
+ struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
struct clk *mct_clk;
mct_clk = clk_get(NULL, "xtal");
clk_rate = clk_get_rate(mct_clk);
-#ifdef CONFIG_LOCAL_TIMERS
if (mct_int_type == MCT_INT_PPI) {
- int err;
err = request_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER,
exynos4_mct_tick_isr, "MCT",
@@ -463,8 +476,16 @@ static void __init exynos4_timer_resources(void)
EXYNOS_IRQ_MCT_LOCALTIMER, err);
}
- local_timer_register(&exynos4_mct_tick_ops);
-#endif /* CONFIG_LOCAL_TIMERS */
+ err = register_cpu_notifier(&exynos4_mct_cpu_nb);
+ if (err)
+ goto out_irq;
+
+ /* Immediately configure the timer on the boot CPU */
+ exynos4_local_timer_setup(&mevt->evt);
+ return;
+
+out_irq:
+ free_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER, &percpu_mct_tick);
}
void __init exynos4_timer_init(void)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
[PATCHv3 02/10] ARM: smp: Remove duplicate dummy timer implementation
Drop ARM's version of the dummy timer now that we have a generic
implementation in drivers/clocksource.
Cc: Russell King
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/smp.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 31644f1..4de4d14 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -469,24 +469,6 @@ void tick_broadcast(const struct cpumask *mask)
}
#endif
-static void broadcast_timer_set_mode(enum clock_event_mode mode,
- struct clock_event_device *evt)
-{
-}
-
-static void __cpuinit broadcast_timer_setup(struct clock_event_device *evt)
-{
- evt->name = "dummy_timer";
- evt->features = CLOCK_EVT_FEAT_ONESHOT |
- CLOCK_EVT_FEAT_PERIODIC |
- CLOCK_EVT_FEAT_DUMMY;
- evt->rating = 400;
- evt->mult = 1;
- evt->set_mode = broadcast_timer_set_mode;
-
- clockevents_register_device(evt);
-}
-
static struct local_timer_ops *lt_ops;
#ifdef CONFIG_LOCAL_TIMERS
@@ -510,8 +492,8 @@ static void __cpuinit percpu_timer_setup(void)
evt->cpumask = cpumask_of(cpu);
- if (!lt_ops || lt_ops->setup(evt))
- broadcast_timer_setup(evt);
+ if (lt_ops)
+ lt_ops->setup(evt);
}
#ifdef CONFIG_HOTPLUG_CPU
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 03/10] ARM: smp_twd: Divorce smp_twd from local timer API
Separate the smp_twd timers from the local timer API. This will
allow us to remove ARM local timer support in the near future and
gets us closer to moving this driver to drivers/clocksource.
Cc: Russell King
Cc: Tony Lindgren
Signed-off-by: Stephen Boyd
---
Changes since v2:
* Fix booting on qemu and omap
arch/arm/Kconfig | 2 +-
arch/arm/kernel/smp_twd.c | 64 +++
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b71469..5ad2ccf 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1527,6 +1527,7 @@ config SMP
depends on HAVE_SMP
depends on MMU
select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
+ select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
select USE_GENERIC_SMP_HELPERS
help
This enables support for systems with more than one CPU. If you have
@@ -1650,7 +1651,6 @@ config LOCAL_TIMERS
bool "Use local timer interrupts"
depends on SMP
default y
- select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
help
Enable support for local timers on SMP platforms, rather then the
legacy IPI broadcast method. Local timers allows the system
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 3f25650..a79476d 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,7 +25,6 @@
#include
#include
-#include
/* set up by the platform code */
static void __iomem *twd_base;
@@ -33,7 +33,7 @@ static struct clk *twd_clk;
static unsigned long twd_timer_rate;
static DEFINE_PER_CPU(bool, percpu_setup_called);
-static struct clock_event_device __percpu **twd_evt;
+static struct clock_event_device __percpu *twd_evt;
static int twd_ppi;
static void twd_set_mode(enum clock_event_mode mode,
@@ -90,8 +90,10 @@ static int twd_timer_ack(void)
return 0;
}
-static void twd_timer_stop(struct clock_event_device *clk)
+static void twd_timer_stop(void)
{
+ struct clock_event_device *clk = __this_cpu_ptr(twd_evt);
+
twd_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
disable_percpu_irq(clk->irq);
}
@@ -106,7 +108,7 @@ static void twd_update_frequency(void *new_rate)
{
twd_timer_rate = *((unsigned long *) new_rate);
- clockevents_update_freq(*__this_cpu_ptr(twd_evt), twd_timer_rate);
+ clockevents_update_freq(__this_cpu_ptr(twd_evt), twd_timer_rate);
}
static int twd_rate_change(struct notifier_block *nb,
@@ -132,7 +134,7 @@ static struct notifier_block twd_clk_nb = {
static int twd_clk_init(void)
{
- if (twd_evt && *__this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
+ if (twd_evt && __this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
return clk_notifier_register(twd_clk, &twd_clk_nb);
return 0;
@@ -151,7 +153,7 @@ static void twd_update_frequency(void *data)
{
twd_timer_rate = clk_get_rate(twd_clk);
- clockevents_update_freq(*__this_cpu_ptr(twd_evt), twd_timer_rate);
+ clockevents_update_freq(__this_cpu_ptr(twd_evt), twd_timer_rate);
}
static int twd_cpufreq_transition(struct notifier_block *nb,
@@ -177,7 +179,7 @@ static struct notifier_block twd_cpufreq_nb = {
static int twd_cpufreq_init(void)
{
- if (twd_evt && *__this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
+ if (twd_evt && __this_cpu_ptr(twd_evt) && !IS_ERR(twd_clk))
return cpufreq_register_notifier(&twd_cpufreq_nb,
CPUFREQ_TRANSITION_NOTIFIER);
@@ -228,7 +230,7 @@ static void __cpuinit twd_calibrate_rate(void)
static irqreturn_t twd_handler(int irq, void *dev_id)
{
- struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
+ struct clock_event_device *evt = dev_id;
if (twd_timer_ack()) {
evt->event_handler(evt);
@@ -265,9 +267,9 @@ static void twd_get_clock(struct device_node *np)
/*
* Setup the local clock events for a CPU.
*/
-static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
+static void __cpuinit twd_timer_setup(void)
{
- struct clock_event_device **this_cpu_clk;
+ struct clock_event_device *clk = __this_cpu_ptr(twd_evt);
int cpu = smp_processor_id();
/*
@@ -276,9 +278,9 @@ static int __cpuinit twd_timer_setup(struct
clock_event_device *clk)
*/
if (per_cpu(percpu_setup_called, cpu)) {
__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
- clockevents_register_device(*__this_cpu_ptr(twd_evt));
+ clockevents_register_device(clk);
enable_percpu_irq(clk->irq, 0);
- return 0;
+ return;
}
pe
[PATCHv3 01/10] clocksource: add generic dummy timer driver
From: Mark Rutland
Several architectures have a dummy timer driver tightly coupled with
their broadcast code to support machines without cpu-local timers (or
where there is a lack of driver support).
Since 12ad100046: "clockevents: Add generic timer broadcast function"
it's been possible to write broadcast-capable timer drivers decoupled
from the broadcast mechanism. We can use this functionality to implement
a generic dummy timer driver that can be shared by all architectures
with generic tick broadcast (ARCH_HAS_TICK_BROADCAST).
This patch implements a generic dummy timer using this facility.
Signed-off-by: Mark Rutland
Cc: John Stultz
Cc: Thomas Gleixner
[sboyd: Make percpu data static and use __this_cpu_ptr()]
Signed-off-by: Stephen Boyd
---
drivers/clocksource/Makefile | 1 +
drivers/clocksource/dummy_timer.c | 67 +++
2 files changed, 68 insertions(+)
create mode 100644 drivers/clocksource/dummy_timer.c
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 4d8283a..655d718 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_VT8500_TIMER)+= vt8500_timer.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
+obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
diff --git a/drivers/clocksource/dummy_timer.c
b/drivers/clocksource/dummy_timer.c
new file mode 100644
index 000..7e1ce45
--- /dev/null
+++ b/drivers/clocksource/dummy_timer.c
@@ -0,0 +1,67 @@
+/*
+ * linux/drivers/clocksource/dummy_timer.c
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ * All Rights Reserved
+ *
+ * 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
+#include
+#include
+#include
+
+static DEFINE_PER_CPU(struct clock_event_device, dummy_timer_evt);
+
+static void dummy_timer_set_mode(enum clock_event_mode mode,
+ struct clock_event_device *evt)
+{
+ /*
+* Core clockevents code will call this when exchanging timer devices.
+* We don't need to do anything here.
+*/
+}
+
+static void __cpuinit dummy_timer_setup(void)
+{
+ int cpu = smp_processor_id();
+ struct clock_event_device *evt = __this_cpu_ptr(&dummy_timer_evt);
+
+ evt->name = "dummy_timer";
+ evt->features = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT |
+ CLOCK_EVT_FEAT_DUMMY;
+ evt->rating = 100;
+ evt->set_mode = dummy_timer_set_mode;
+ evt->cpumask= cpumask_of(cpu);
+
+ clockevents_register_device(evt);
+}
+
+static int __cpuinit dummy_timer_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ if ((action & ~CPU_TASKS_FROZEN) == CPU_STARTING)
+ dummy_timer_setup();
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block dummy_timer_cpu_nb __cpuinitdata = {
+ .notifier_call = dummy_timer_cpu_notify,
+};
+
+static int __init dummy_timer_register(void)
+{
+ int err = register_cpu_notifier(&dummy_timer_cpu_nb);
+ if (err)
+ return err;
+
+ /* We won't get a call on the boot CPU, so register immediately */
+ dummy_timer_setup();
+
+ return 0;
+}
+device_initcall(dummy_timer_register);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Complain about more executable files
We don't want executable permissions set on files such as
devicetree syntax files, text files, defconfig files, or binary
hex files.
Cc: Andy Whitcroft
Cc: Joe Perches
Signed-off-by: Stephen Boyd
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b28cc38..591867e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1576,7 +1576,7 @@ sub process {
# Check for incorrect file permissions
if ($line =~ /^new (file )?mode.*[7531]\d{0,2}$/) {
my $permhere = $here . "FILE: $realfile\n";
- if ($realfile =~
/(Makefile|Kconfig|\.c|\.h|\.S|\.tmpl)$/) {
+ if ($realfile =~
/(Makefile|Kconfig|\.c|\.h|\.S|\.tmpl|\.dts|\.dtsi|defconfig|\.txt|\.hex|\.HEX|\.ihex)$/)
{
ERROR("EXECUTE_PERMISSIONS",
"do not set execute permissions for
source files\n" . $permhere);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2013-03-01-15-50 uploaded (strict user copy)
On 03/01/13 19:42, Stephen Boyd wrote: > On 03/01/13 19:00, Randy Dunlap wrote: >> on i386: >> >> ERROR: "copy_from_user_overflow" [fs/binfmt_misc.ko] undefined! >> >> which I don't understand. >> lib/usercopy.o is built and building binfmt_misc.c says: >> >> CC [M] fs/binfmt_misc.o >> In file included from arch/x86/include/asm/uaccess.h:537:0, >> from include/linux/uaccess.h:5, >> from include/linux/highmem.h:8, >> from include/linux/pagemap.h:10, >> from fs/binfmt_misc.c:27: >> arch/x86/include/asm/uaccess_32.h: In function 'parse_command.part.1': >> arch/x86/include/asm/uaccess_32.h:211:26: warning: call to >> 'copy_from_user_overflow' declared with attribute warning: copy_from_user() >> buffer size is not provably correct [enabled by default] > Hm.. That's because it's part of lib and not obj, right? > > diff --git a/lib/Makefile b/lib/Makefile > index 59fabd0..4c55104 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -15,7 +15,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ > is_single_threaded.o plist.o decompress.o kobject_uevent.o \ > earlycpio.o percpu-refcount.o > > -lib-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o > +obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o > lib-$(CONFIG_MMU) += ioremap.o > lib-$(CONFIG_SMP) += cpumask.o > > Andrew, can you squash this into "Kconfig: consolidate CONFIG_DEBUG_STRICT_USER_COPY_CHECKS"? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: sched_clock: Add more notrace to prevent recursion
cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns()
is called by cyc_to_sched_clock(). I suspect that some compilers
inline both of these functions into sched_clock() and so we've
been getting away without having a notrace marking. It seems that
my compiler isn't inlining cyc_to_sched_clock() though, so I'm
hitting a recursion bug when I enable the function graph tracer,
causing my system to crash. Marking these functions notrace fixes
it. Technically cyc_to_ns() doesn't need the notrace because it's
already marked inline, but let's just add it so that if we ever
remove inline from that function it doesn't blow up.
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/sched_clock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index bd6f56b..59d2adb 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -45,12 +45,12 @@ static u32 notrace jiffy_sched_clock_read(void)
static u32 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
-static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
+static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
{
return (cyc * mult) >> shift;
}
-static unsigned long long cyc_to_sched_clock(u32 cyc, u32 mask)
+static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
{
u64 epoch_ns;
u32 epoch_cyc;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Scorpion is a v7 architecture, not v6
On 03/05/13 00:31, Arnd Bergmann wrote: > On Monday 04 March 2013, Stephen Boyd wrote: >> Scorpion processors have always been v7 CPUs. Fix the Kconfig >> text to reflect this. >> >> Reported-by: Stepan Moskovchenko >> Signed-off-by: Stephen Boyd >> --- >> arch/arm/Kconfig |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index dedf02b..dc3bbbc 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -1006,12 +1006,12 @@ config ARCH_MULTI_V4_V5 >> bool >> >> config ARCH_MULTI_V6 >> - bool "ARMv6 based platforms (ARM11, Scorpion, ...)" >> + bool "ARMv6 based platforms (ARM11)" >> select ARCH_MULTI_V6_V7 >> select CPU_V6 > Sorry about that, my fault. Can you pick this patch up from the mailing list? Otherwise I can try to route it through David's msm tree. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: msm: Wait for timer clear to complete
Without looping on the status bit, there is no way to guarantee
that a clear of the timer has actually completed. This can cause
us to enable the timer before the count has cleared and miss a
timer interrupt. To simplify this patch, remove the timer
register setup done during timer init, since it's duplicate work
that is eventually done in the set_next_event() callback.
Signed-off-by: Stephen Boyd
---
arch/arm/mach-msm/timer.c | 41 +++--
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 9f033c3..284313f 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -30,20 +30,22 @@
#include "common.h"
-#define TIMER_MATCH_VAL 0x
-#define TIMER_COUNT_VAL 0x0004
-#define TIMER_ENABLE0x0008
-#define TIMER_ENABLE_CLR_ON_MATCH_ENBIT(1)
-#define TIMER_ENABLE_EN BIT(0)
-#define TIMER_CLEAR 0x000C
-#define DGT_CLK_CTL0x10
-#define DGT_CLK_CTL_DIV_4 0x3
+#define TIMER_MATCH_VAL0x
+#define TIMER_COUNT_VAL0x0004
+#define TIMER_ENABLE 0x0008
+#define TIMER_ENABLE_CLR_ON_MATCH_EN BIT(1)
+#define TIMER_ENABLE_ENBIT(0)
+#define TIMER_CLEAR0x000C
+#define DGT_CLK_CTL0x10
+#define DGT_CLK_CTL_DIV_4 0x3
+#define TIMER_STS_GPT0_CLR_PENDBIT(10)
#define GPT_HZ 32768
#define MSM_DGT_SHIFT 5
static void __iomem *event_base;
+static void __iomem *sts_base;
static irqreturn_t msm_timer_interrupt(int irq, void *dev_id)
{
@@ -68,6 +70,11 @@ static int msm_timer_set_next_event(unsigned long cycles,
writel_relaxed(ctrl, event_base + TIMER_CLEAR);
writel_relaxed(cycles, event_base + TIMER_MATCH_VAL);
+
+ if (sts_base)
+ while (readl_relaxed(sts_base) & TIMER_STS_GPT0_CLR_PEND)
+ cpu_relax();
+
writel_relaxed(ctrl | TIMER_ENABLE_EN, event_base + TIMER_ENABLE);
return 0;
}
@@ -138,9 +145,6 @@ static int __cpuinit msm_local_timer_setup(struct
clock_event_device *evt)
if (!smp_processor_id())
return 0;
- writel_relaxed(0, event_base + TIMER_ENABLE);
- writel_relaxed(0, event_base + TIMER_CLEAR);
- writel_relaxed(~0, event_base + TIMER_MATCH_VAL);
evt->irq = msm_clockevent.irq;
evt->name = "local_timer";
evt->features = msm_clockevent.features;
@@ -178,9 +182,6 @@ static void __init msm_timer_init(u32 dgt_hz, int
sched_bits, int irq,
struct clocksource *cs = &msm_clocksource;
int res;
- writel_relaxed(0, event_base + TIMER_ENABLE);
- writel_relaxed(0, event_base + TIMER_CLEAR);
- writel_relaxed(~0, event_base + TIMER_MATCH_VAL);
ce->cpumask = cpumask_of(0);
ce->irq = irq;
@@ -275,6 +276,7 @@ void __init msm_dt_timer_init(void)
of_node_put(np);
event_base = base + 0x4;
+ sts_base = base + 0x88;
source_base = cpu0_base + 0x24;
freq /= 4;
writel_relaxed(DGT_CLK_CTL_DIV_4, source_base + DGT_CLK_CTL);
@@ -283,7 +285,8 @@ void __init msm_dt_timer_init(void)
}
#endif
-static int __init msm_timer_map(phys_addr_t addr, u32 event, u32 source)
+static int __init msm_timer_map(phys_addr_t addr, u32 event, u32 source,
+ u32 sts)
{
void __iomem *base;
@@ -294,6 +297,8 @@ static int __init msm_timer_map(phys_addr_t addr, u32
event, u32 source)
}
event_base = base + event;
source_base = base + source;
+ if (sts)
+ sts_base = base + sts;
return 0;
}
@@ -302,7 +307,7 @@ void __init msm7x01_timer_init(void)
{
struct clocksource *cs = &msm_clocksource;
- if (msm_timer_map(0xc010, 0x0, 0x10))
+ if (msm_timer_map(0xc010, 0x0, 0x10, 0x0))
return;
cs->read = msm_read_timer_count_shift;
cs->mask = CLOCKSOURCE_MASK((32 - MSM_DGT_SHIFT));
@@ -313,14 +318,14 @@ void __init msm7x01_timer_init(void)
void __init msm7x30_timer_init(void)
{
- if (msm_timer_map(0xc010, 0x4, 0x24))
+ if (msm_timer_map(0xc010, 0x4, 0x24, 0x80))
return;
msm_timer_init(24576000 / 4, 32, 1, false);
}
void __init qsd8x50_timer_init(void)
{
- if (msm_timer_map(0xAC10, 0x0, 0x10))
+ if (msm_timer_map(0xAC10, 0x0, 0x10, 0x34))
return;
msm_timer_init(1920 / 4, 32, 7, false);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at htt
[PATCH 0/3] Fix msm timer clearing bugs
This patchset cleans up some bugs in the msm timer code and overhauls the DT binding. I don't think we'll need to radically change it again, and we haven't shipped any devices with these bindings so we should be ok. The important thing is that the binding is consolidated and more clearly describes the hardware. We can use the compatible field to determine which timers are present and what the register layout is, so we may need to add more compatible fields in the future. Patches are based on v3.9-rc2. These patches will conflict with my other patch series to remove the local timer API, but the conflict isn't impossible to resolve and we can figure out how to deal with that after review. Patch 1 is a bug fix which could probably go into 3.9 if desired. Patch 2 overhauls the DT binding to be cleaner, and patch 3 fixes a bug where we don't wait for the timer to be clear before programming it leading to no more ticks. Stephen Boyd (3): ARM: msm: Stop counting before reprogramming clockevent ARM: msm: Rework timer binding to be more general ARM: msm: Wait for timer clear to complete .../devicetree/bindings/arm/msm/timer.txt | 41 arch/arm/boot/dts/msm8660-surf.dts | 20 ++-- arch/arm/boot/dts/msm8960-cdp.dts | 22 ++-- arch/arm/mach-msm/timer.c | 115 ++--- 4 files changed, 90 insertions(+), 108 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: msm: Stop counting before reprogramming clockevent
If the clockevent is forcibly reprogrammed to have a different
match value we mistakenly assume the timer is not ticking and
program a new match value while the timer is running. Although we
clear the timer before programming a new match, it's better to
stop the timer before clearing it so that we're sure the proper
amount of ticks are counted. Failure to do so can lead to missed
ticks and system hangs.
Signed-off-by: Stephen Boyd
---
arch/arm/mach-msm/timer.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 2969027..f9fd77e 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -62,7 +62,10 @@ static int msm_timer_set_next_event(unsigned long cycles,
{
u32 ctrl = readl_relaxed(event_base + TIMER_ENABLE);
- writel_relaxed(0, event_base + TIMER_CLEAR);
+ ctrl &= ~TIMER_ENABLE_EN;
+ writel_relaxed(ctrl, event_base + TIMER_ENABLE);
+
+ writel_relaxed(ctrl, event_base + TIMER_CLEAR);
writel_relaxed(cycles, event_base + TIMER_MATCH_VAL);
writel_relaxed(ctrl | TIMER_ENABLE_EN, event_base + TIMER_ENABLE);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: msm: Rework timer binding to be more general
The msm timer binding I wrote is bad. First off, the clock
frequency in the binding for the dgt is wrong. Software divides
down the input rate by 4 to achieve the rate listed in the
binding. We also treat each individual timer as a separate
hardware component, when in reality there is one timer block
(that may be duplicated per cpu) with multiple timers within it.
Depending on the version of the hardware there can be one or two
general purpose timers, status and divider control registers, and
an entirely different register layout.
In the next patch we'll need to know about the different register
layouts so that we can properly check the status register after
clearing the count. The current binding makes this complicated
because the general purpose timer's reg property doesn't indicate
where that status register is, and in fact it is beyond the size
of the reg property.
Clean all this up by just having one node for the timer hardware,
and describe all the interrupts and clock frequencies supported
while having one reg property that covers the entire timer
register region. We'll use the compatible field in the future to
determine different register layouts and if we should read the
status registers, etc.
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/arm/msm/timer.txt | 41 ++-
arch/arm/boot/dts/msm8660-surf.dts | 20 ++
arch/arm/boot/dts/msm8960-cdp.dts | 22 +++---
arch/arm/mach-msm/timer.c | 79 +-
4 files changed, 68 insertions(+), 94 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/msm/timer.txt
b/Documentation/devicetree/bindings/arm/msm/timer.txt
index 8c5907b..c6ef8f1 100644
--- a/Documentation/devicetree/bindings/arm/msm/timer.txt
+++ b/Documentation/devicetree/bindings/arm/msm/timer.txt
@@ -3,36 +3,35 @@
Properties:
- compatible : Should at least contain "qcom,msm-timer". More specific
- properties such as "qcom,msm-gpt" and "qcom,msm-dgt" specify a general
- purpose timer and a debug timer respectively.
+ properties specify which subsystem the timers are paired with.
-- interrupts : Interrupt indicating a match event.
+ "qcom,kpss-timer" - krait subsystem
+ "qcom,scss-timer" - scorpion subsystem
-- reg : Specifies the base address of the timer registers. The second region
- specifies an optional register used to configure the clock divider.
+- interrupts : Interrupts for the the debug timer, the first general purpose
+ timer, and optionally a second general purpose timer in that
+ order.
-- clock-frequency : The frequency of the timer in Hz.
+- reg : Specifies the base address of the timer registers.
+
+- clock-frequency : The frequency of the debug timer and the general purpose
+timer(s) in Hz in that order.
Optional:
- cpu-offset : per-cpu offset used when the timer is accessed without the
- CPU remapping facilities. The offset is cpu-offset * cpu-nr.
+ CPU remapping facilities. The offset is
+ cpu-offset + (0x1 * cpu-nr).
Example:
- timer@200a004 {
- compatible = "qcom,msm-gpt", "qcom,msm-timer";
- interrupts = <1 2 0x301>;
- reg = <0x0200a004 0x10>;
- clock-frequency = <32768>;
- cpu-offset = <0x4>;
- };
-
- timer@200a024 {
- compatible = "qcom,msm-dgt", "qcom,msm-timer";
- interrupts = <1 3 0x301>;
- reg = <0x0200a024 0x10>,
- <0x0200a034 0x4>;
- clock-frequency = <675>;
+ timer@200a000 {
+ compatible = "qcom,scss-timer", "qcom,msm-timer";
+ interrupts = <1 1 0x301>,
+<1 2 0x301>,
+<1 3 0x301>;
+ reg = <0x0200a000 0x100>;
+ clock-frequency = <1920>,
+ <32768>;
cpu-offset = <0x4>;
};
diff --git a/arch/arm/boot/dts/msm8660-surf.dts
b/arch/arm/boot/dts/msm8660-surf.dts
index 31f2157..743ef42 100644
--- a/arch/arm/boot/dts/msm8660-surf.dts
+++ b/arch/arm/boot/dts/msm8660-surf.dts
@@ -16,19 +16,13 @@
};
timer@204 {
- compatible = "qcom,msm-gpt", "qcom,msm-timer";
- interrupts = <1 1 0x301>;
- reg = <0x0204 0x10>;
- clock-frequency = <32768>;
- cpu-offset = <0x4>;
- };
-
- timer@224 {
- compatible = "qcom,msm-dgt", "qcom,msm-timer";
- interrupts = &l
Re: [PATCHv2] ARM: Push selects for TWD/SCU into machine entries
On 3/5/2013 2:34 PM, Arnd Bergmann wrote: > On Tuesday 05 March 2013, Stephen Boyd wrote: >> On 02/27/13 15:43, Stephen Warren wrote: >>> Seems simple enough it doesn't really need many, but for Tegra, >>> Acked-by: Stephen Warren >>> >>> Which kernel is this going into? It's possible Tegra will get converted >>> to multi-platform in 3.10, which might move that main ARCH_TEGRA block >>> from arch/arm/Kconfig into arch/arm/mach-tegra/Kconfig, although I >>> suppose it doesn't have to move it. I think some/all(?) other >>> multi-platform conversions have moved their main Kconfig option like >>> that though. >> Thanks. I'm hoping that Arnd/Olof can pick this up. I'm not sure which >> version it will go into. >> > Hmm, it certainly looks useful to me. I think it should go into the next > cleanup branch as a base, so others can build on top of it. We will > also need it for the Exynos multiplatform patches that I hope can land > in 3.10 as well. > > Sneaking it in through the fixes branch would make life easier for us, > but it doesn't feel right. Arnd, can you pick this up into the arm-soc tree now? It would be good to get this into next so that conflicts are avoided later on. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: MSM: Fix early debug uart mapping on some memory configs
The uart mapping runs into the space allocated for lowmem on some 8960 boards when we have more than 512Mb of memory. We were getting lucky before and our mapping wasn't part of DDR. Move the mapping up into the vmalloc area which will always be outside of the lowmem mapping regardless of how much lowmem actually exists. Signed-off-by: Stephen Boyd --- arch/arm/mach-msm/include/mach/msm_iomap-8960.h | 2 +- arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h index a1752c0..facf434 100644 --- a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h +++ b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h @@ -46,7 +46,7 @@ #define MSM8960_TMR0_SIZE SZ_4K #ifdef CONFIG_DEBUG_MSM8960_UART -#define MSM_DEBUG_UART_BASE0xE104 +#define MSM_DEBUG_UART_BASE0xF004 #define MSM_DEBUG_UART_PHYS0x1644 #endif diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h index 5aed57d..21a2a88 100644 --- a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h +++ b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h @@ -63,7 +63,7 @@ #define MSM8X60_TMR0_SIZE SZ_4K #ifdef CONFIG_DEBUG_MSM8660_UART -#define MSM_DEBUG_UART_BASE0xE104 +#define MSM_DEBUG_UART_BASE0xF004 #define MSM_DEBUG_UART_PHYS0x19C4 #endif -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] ARM: smp: Fix cpu_up() racing with sys_reboot
On 8/21/2012 9:03 PM, Stephen Boyd wrote: > Nothing stops a process from hotplugging in a CPU concurrently > with a sys_reboot() call. In such a situation we could have > ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the > fact that the CPU is not really offline and call the > CPU_UP_PREPARE notifier. When this happens stop_machine code will > complain that the cpu thread already exists and BUG_ON(). > > CPU0 CPU1 > > sys_reboot() > kernel_restart() > machine_restart() >machine_shutdown() > smp_send_stop() > ... ipi_cpu_stop() >set_cpu_online(1, false) > local_irq_disable() > while(1) > > cpu_up() > _cpu_up() >if (!cpu_online(1)) > __cpu_notify(CPU_UP_PREPARE...) > > cpu_stop_cpu_callback() > BUG_ON(stopper->thread) > > This is easily reproducible by hotplugging in and out in a tight > loop while also rebooting. > > Since the CPU is not really offline and hasn't gone through the > proper steps to be marked as such, let's mark the CPU as inactive. > This is just as easily testable as online and avoids any possibility > of _cpu_up() trying to bring the CPU back online when it never was > offline to begin with. > > Signed-off-by: Stephen Boyd > --- > > Perhaps we can take the hotplug lock in the sys_reboot() case but I > don't think that actually fixes everything. For example, in cases > where machine_shutdown() is called from emergency_restart() we would > have to take the hotplug lock which doesn't really seem feasible. Any comments on this patch? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] ARM: smp: Fix cpu_up() racing with sys_reboot
On 8/29/2012 4:53 PM, Russell King - ARM Linux wrote: > On Tue, Aug 21, 2012 at 09:03:49PM -0700, Stephen Boyd wrote: >> Nothing stops a process from hotplugging in a CPU concurrently >> with a sys_reboot() call. In such a situation we could have >> ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the >> fact that the CPU is not really offline and call the >> CPU_UP_PREPARE notifier. When this happens stop_machine code will >> complain that the cpu thread already exists and BUG_ON(). > This puts us at odds with x86, which is a bad thing without first > investigating whether a generic solution which fixes all arches would > be more appropriate. I went this way because it seems that we stop CPUs in architecture specific code instead of doing it generically (although we have smp_send_stop()?). It would be nice if we could generalize the cpu stopping code so that reboot at the architectual level doesn't have to do this. > > A better solution may be to mark those CPUs as being not-present, > which will prevent them being hot-plugged back. That sounds fine to me. I can s/active/present/ for v2 if we can get some kind of consensus. I was also thinking we could stop using these functions entirely and have some private stopped CPUs map that we check instead. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] hvc_dcc : add support to armv4 and armv5 core
On 8/31/2012 4:47 AM, Matthieu CASTET wrote:
> Signed-off-by: Matthieu Castet
Please consider adding some sort of commit text. Does this add some new
feature I may want on some downstream distro kernel?
> @@ -51,7 +51,7 @@ static inline char __dcc_getchar(void)
> return __c;
> }
>
> -static inline void __dcc_putchar(char c)
> +static inline void __dcc_putchar_v6(char c)
> {
> asm volatile("mcr p14, 0, %0, c0, c5, 0 @ write a char"
> : /* no output register */
> @@ -59,6 +59,69 @@ static inline void __dcc_putchar(char c)
> isb();
> }
>
> +static int hvc_dcc_put_chars_v6(uint32_t vt, const char *buf, int count)
> +{
> + int i;
> +
> + for (i = 0; i < count; i++) {
> + while (__dcc_getstatus_v6() & DCC_STATUS_TX_V6)
> + cpu_relax();
> +
> + __dcc_putchar_v6(buf[i]);
> + }
> +
> + return count;
> +}
It's unfortunate that the main logic is duplicated. I wonder if we could
push the runtime decision slightly lower into the accessor functions
instead and make some new functions dcc_tx_busy() and dcc_rx_busy() or
something. Then these loops stay the same.
> +
> +static int hvc_dcc_get_chars_v6(uint32_t vt, char *buf, int count)
> +{
> + int i;
> +
> + for (i = 0; i < count; ++i)
> + if (__dcc_getstatus_v6() & DCC_STATUS_RX_V6)
> + buf[i] = __dcc_getchar_v6();
> + else
> + break;
> +
> + return i;
> +}
> +
> +static const struct hv_ops hvc_dcc_get_put_ops_v6 = {
> + .get_chars = hvc_dcc_get_chars_v6,
> + .put_chars = hvc_dcc_put_chars_v6,
> +};
> +
> +#define DCC_STATUS_RX(1 << 0)
> +#define DCC_STATUS_TX(1 << 1)
> +
> +/* primitive JTAG1 protocol utilities */
This comment doesn't tell me much. Remove it?
> +static inline u32 __dcc_getstatus(void)
> +{
> + u32 ret;
> +
> + asm __volatile__ ("mrc p14, 0, %0, c0, c0 @ read comms ctrl reg"
> + : "=r" (ret));
Can you use volatile instead of __volatile__ so that the file is consistent?
> +
> + return ret;
> +}
> +
> +static inline char __dcc_getchar(void)
> +{
> + char c;
> +
> + asm __volatile__ ("mrc p14, 0, %0, c1, c0 @ read comms data reg"
> + : "=r" (c));
> +
Do you see any multiple character inputs? I think you may need an isb
here similar to the v6/7 code and in the putchar as well.
> + return c;
> +}
> +
> +static inline void __dcc_putchar(unsigned char c)
> +{
> + asm __volatile__ ("mcr p14, 0, %0, c1, c0 @ write a char"
> + : /* no output register */
> + : "r" (c));
> +}
> +
> static int hvc_dcc_put_chars(uint32_t vt, const char *buf, int count)
> {
> int i;
>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: msm: Fix sparse warnings due to incorrect type
arch/arm/mach-msm/timer.c:153:3: warning: incorrect type in initializer
(different address spaces)
arch/arm/mach-msm/timer.c:153:3:expected void const [noderef]
*__vpp_verify
arch/arm/mach-msm/timer.c:153:3:got struct clock_event_device [noderef]
**
arch/arm/mach-msm/timer.c:153:38: warning: incorrect type in assignment
(different address spaces)
arch/arm/mach-msm/timer.c:153:38:expected struct clock_event_device
[noderef] *
arch/arm/mach-msm/timer.c:153:38:got struct clock_event_device *evt
arch/arm/mach-msm/timer.c:191:22: warning: incorrect type in assignment
(different address spaces)
arch/arm/mach-msm/timer.c:191:22:expected struct clock_event_device
[noderef] **static [toplevel] percpu_evt
arch/arm/mach-msm/timer.c:191:22:got struct clock_event_device *[noderef]
*
arch/arm/mach-msm/timer.c:196:4: warning: incorrect type in initializer
(different address spaces)
arch/arm/mach-msm/timer.c:196:4:expected void const [noderef]
*__vpp_verify
arch/arm/mach-msm/timer.c:196:4:got struct clock_event_device [noderef]
**
arch/arm/mach-msm/timer.c:196:39: warning: incorrect type in assignment
(different address spaces)
arch/arm/mach-msm/timer.c:196:39:expected struct clock_event_device
[noderef] *
arch/arm/mach-msm/timer.c:196:39:got struct clock_event_device *ce
arch/arm/mach-msm/timer.c:198:24: warning: incorrect type in argument 4
(different address spaces)
arch/arm/mach-msm/timer.c:198:24:expected void [noderef]
*percpu_dev_id
arch/arm/mach-msm/timer.c:198:24:got struct clock_event_device [noderef]
**static [toplevel] percpu_evt
Signed-off-by: Stephen Boyd
---
arch/arm/mach-msm/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 81280825..004f935 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -101,7 +101,7 @@ static struct clock_event_device msm_clockevent = {
static union {
struct clock_event_device *evt;
- struct clock_event_device __percpu **percpu_evt;
+ struct clock_event_device * __percpu *percpu_evt;
} msm_evt;
static void __iomem *source_base;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/sys.c: call disable_nonboot_cpus in kernel_restart
On 09/04/12 15:36, Andrew Morton wrote: > On Mon, 3 Sep 2012 22:24:58 +0800 > Shawn Guo wrote: > >> Like kernel_power_off calls disable_nonboot_cpus, we may want to have >> kernel_restart call disable_nonboot_cpus as well. Doing so can help >> the machines that require boot cpu be the last alive cpu during reboot >> to survive with kernel restart. > That does sound logical. But the changelog is very vague and fluffy. > Does this patch actually fix any known problem on any known machine? > Not to hijack this thread but I have a similar problem that would be partially solved by patch. Basically reboot races with cpu_up and causes a BUG_ON to hit in stop machine. So this patch would fix my problem except for in the case where restart is called from panic (i.e. emergency restart). https://lkml.org/lkml/2012/8/22/3 Here's the commit text: Nothing stops a process from hotplugging in a CPU concurrently with a sys_reboot() call. In such a situation we could have ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the fact that the CPU is not really offline and call the CPU_UP_PREPARE notifier. When this happens stop_machine code will complain that the cpu thread already exists and BUG_ON(). CPU0 CPU1 sys_reboot() kernel_restart() machine_restart() machine_shutdown() smp_send_stop() ... ipi_cpu_stop() set_cpu_online(1, false) local_irq_disable() while(1) cpu_up() _cpu_up() if (!cpu_online(1)) __cpu_notify(CPU_UP_PREPARE...) cpu_stop_cpu_callback() BUG_ON(stopper->thread) This is easily reproducible by hotplugging in and out in a tight loop while also rebooting. Since the CPU is not really offline and hasn't gone through the proper steps to be marked as such, let's mark the CPU as inactive. This is just as easily testable as online and avoids any possibility of _cpu_up() trying to bring the CPU back online when it never was offline to begin with. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Fix deadlock scenario with smp_send_stop()
On 09/05/12 14:01, Stephen Boyd wrote:
> If one process calls sys_reboot and that process then stops other
> CPUs while those CPUs are within a spin_lock() region we can
> potentially encounter a deadlock scenario like below.
>
> CPU 0 CPU 1
> - -
> spin_lock(my_lock)
> smp_send_stop()
> send_IPI handle_IPI()
> disable_preemption/irqs
> while(1);
>
> spin_lock(my_lock) <--- Waits forever
>
> We shouldn't attempt to run any other tasks after we send a stop
> IPI to a CPU so disable preemption so that the reboot task runs to
> completion.
>
> Reported-by: Sundarajan Srinivasan
> Signed-off-by: Stephen Boyd
> ---
>
> Unfortunately this won't fix the other problem I mentioned two weeks
> ago where smp_send_stop races with other CPUs calling cpu_up().
Any comments?
>
> arch/arm/kernel/process.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 693b744..663a7a8 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -239,6 +239,7 @@ __setup("reboot=", reboot_setup);
>
> void machine_shutdown(void)
> {
> + preempt_disable();
> #ifdef CONFIG_SMP
> smp_send_stop();
> #endif
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 06/13] ARM: SoC: convert MSM SMP to SoC descriptor
On 09/12/12 09:26, David Brown wrote: > On Wed, Sep 12, 2012 at 04:58:19PM +0200, Arnd Bergmann wrote: >> From: Marc Zyngier >> >> Convert MSM SMP platforms to use the SoC descriptor to provide >> their SMP and CPU hotplug operations. >> >> Cc: David Brown >> Signed-off-by: Marc Zyngier >> Signed-off-by: Arnd Bergmann >> --- >> arch/arm/mach-msm/board-msm8960.c | 3 +++ >> arch/arm/mach-msm/board-msm8x60.c |7 +++ > Stephen Boyd recently sent out a patch series that remove the non-DT > support for these two targets, which naturally generates a bunch of > conflicts. > > I'm about to send out a pull request including these changes, and > after that, I'll rework this patch for the new board files, and give > it a try. It would also be nice if you used the common.h file instead of adding a core.h. common.h is a new file in the patch series you mention. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode
On 09/24/12 10:19, Will Deacon wrote: > Ok, I've pushed a bunch of patches to my hw-breakpoint branch (head commit > 55cb726797c7). I'll post them to the list after the merge window, but please > do take them for a spin if you get a chance. > Forgot to reply here. Took them for a spin last week with that commit. No more boot hangs but I can't say much else beyond that. When you post to the list I'll add my tested-by. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode
On 10/02/12 02:13, Will Deacon wrote: > > Thanks Stephen. I've also got some patches for OS save/restore of the debug > registers using the various hardware locking and readout mechanisms, so that > debug state can be persisted across low-power states. > > Do any of the Qualcomm chips (v7 as opposed to v7.1) implement the > save/restore > registers? Yes, we have save and restore registers. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] clk: Don't return negative numbers for unsigned values with !clk
Some of the helper functions return negative error codes if
passed a NULL clock. This can lead to confusing behavior when the
expected return value is unsigned. Fix up these accessors so that
they return unsigned values (or bool in the case of is_enabled).
This way we can't interpret NULL clocks as having valid and
interesting values.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c| 20 ++--
include/linux/clk-provider.h | 6 +++---
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 6852809..2847a66 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -262,7 +262,7 @@ inline struct clk_hw *__clk_get_hw(struct clk *clk)
inline u8 __clk_get_num_parents(struct clk *clk)
{
- return !clk ? -EINVAL : clk->num_parents;
+ return !clk ? 0 : clk->num_parents;
}
inline struct clk *__clk_get_parent(struct clk *clk)
@@ -270,14 +270,14 @@ inline struct clk *__clk_get_parent(struct clk *clk)
return !clk ? NULL : clk->parent;
}
-inline int __clk_get_enable_count(struct clk *clk)
+inline unsigned int __clk_get_enable_count(struct clk *clk)
{
- return !clk ? -EINVAL : clk->enable_count;
+ return !clk ? 0 : clk->enable_count;
}
-inline int __clk_get_prepare_count(struct clk *clk)
+inline unsigned int __clk_get_prepare_count(struct clk *clk)
{
- return !clk ? -EINVAL : clk->prepare_count;
+ return !clk ? 0 : clk->prepare_count;
}
unsigned long __clk_get_rate(struct clk *clk)
@@ -303,15 +303,15 @@ out:
inline unsigned long __clk_get_flags(struct clk *clk)
{
- return !clk ? -EINVAL : clk->flags;
+ return !clk ? 0 : clk->flags;
}
-int __clk_is_enabled(struct clk *clk)
+bool __clk_is_enabled(struct clk *clk)
{
int ret;
if (!clk)
- return -EINVAL;
+ return false;
/*
* .is_enabled is only mandatory for clocks that gate
@@ -324,7 +324,7 @@ int __clk_is_enabled(struct clk *clk)
ret = clk->ops->is_enabled(clk->hw);
out:
- return ret;
+ return !!ret;
}
static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
@@ -569,7 +569,7 @@ unsigned long __clk_round_rate(struct clk *clk, unsigned
long rate)
unsigned long parent_rate = 0;
if (!clk)
- return -EINVAL;
+ return 0;
if (!clk->ops->round_rate) {
if (clk->flags & CLK_SET_RATE_PARENT)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 0571261..3593a3c 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -341,11 +341,11 @@ const char *__clk_get_name(struct clk *clk);
struct clk_hw *__clk_get_hw(struct clk *clk);
u8 __clk_get_num_parents(struct clk *clk);
struct clk *__clk_get_parent(struct clk *clk);
-inline int __clk_get_enable_count(struct clk *clk);
-inline int __clk_get_prepare_count(struct clk *clk);
+inline unsigned int __clk_get_enable_count(struct clk *clk);
+inline unsigned int __clk_get_prepare_count(struct clk *clk);
unsigned long __clk_get_rate(struct clk *clk);
unsigned long __clk_get_flags(struct clk *clk);
-int __clk_is_enabled(struct clk *clk);
+bool __clk_is_enabled(struct clk *clk);
struct clk *__clk_lookup(const char *name);
/*
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] clk: Fix documentation typos
Fix some minor typos in the documentation for the ops structure. Signed-off-by: Stephen Boyd --- include/linux/clk-provider.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index 5a548e3..0571261 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -57,9 +57,9 @@ struct clk_hw; * This function must not sleep. Optional, if this op is not * set then the enable count will be used. * - * @recalc_rateRecalculate the rate of this clock, by quering hardware. The + * @recalc_rateRecalculate the rate of this clock, by querying hardware. The * parent rate is an input parameter. It is up to the caller to - * insure that the prepare_mutex is held across this call. + * ensure that the prepare_mutex is held across this call. * Returns the calculated rate. Optional, but recommended - if * this op is not set then clock rate will be initialized to 0. * @@ -93,7 +93,7 @@ struct clk_hw; * implementations to split any work between atomic (enable) and sleepable * (prepare) contexts. If enabling a clock requires code that might sleep, * this must be done in clk_prepare. Clock enable code that will never be - * called in a sleepable context may be implement in clk_enable. + * called in a sleepable context may be implemented in clk_enable. * * Typically, drivers will call clk_prepare when a clock may be needed later * (eg. when a device is opened), and clk_enable when the clock is actually -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] clk: Document .is_enabled op
Add the missing kernel-doc for this op. Signed-off-by: Stephen Boyd --- include/linux/clk-provider.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index 710c6cb..5a548e3 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -53,6 +53,10 @@ struct clk_hw; * @disable: Disable the clock atomically. Called with enable_lock held. * This function must not sleep. * + * @is_enabled:Queries the hardware to determine if the clock is enabled. + * This function must not sleep. Optional, if this op is not + * set then the enable count will be used. + * * @recalc_rateRecalculate the rate of this clock, by quering hardware. The * parent rate is an input parameter. It is up to the caller to * insure that the prepare_mutex is held across this call. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Minor fixes for generic clock framework
This is a small set of patches that fixes some documentation and fixes return values of functions that aren't used that much yet. Noticed while going through this code. Stephen Boyd (3): clk: Document .is_enabled op clk: Fix documentation typos clk: Don't return negative numbers for unsigned values with !clk drivers/clk/clk.c| 20 ++-- include/linux/clk-provider.h | 16 ++-- 2 files changed, 20 insertions(+), 16 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
arm-soc maintainer entry
Is the a...@kernel.org alias going to be added into the MAINTAINERS file? Should anybody be sending mails to this address? It seems I asked this over a year ago and the response was positive but nothing ever happened[1]. Maybe something like below? I only ask because get_maintainer.pl isn't picking up this email. diff --git a/MAINTAINERS b/MAINTAINERS index ecd8796..0e1ec23 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -606,6 +606,14 @@ W: http://www.arm.linux.org.uk/ S: Maintained F: arch/arm/ +ARM SUB-ARCHITECTURES +M: a...@kernel.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: MAINTAINED +F: arch/arm/mach-*/ +F: arch/arm/plat-*/ +T: git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git + ARM PRIMECELL AACI PL041 DRIVER M: Russell King S: Maintained [1] https://lkml.org/lkml/2011/7/26/307 -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: Push selects for TWD/SCU into machine entries
The TWD and SCU configs are selected by default as long as SCORPIONMP is false and/or MCT is false. Implementing the logic this way certainly saves lines in the Kconfig but it precludes those machines which select SCORPIONMP or MCT from participating in the single zImage effort because when those machines are combined with other SMP capable machines the TWD and SCU are no longer selected. Push the select out to the machine entries so that we can compile these machines together and still select the appropriate configs. Signed-off-by: Stephen Boyd Cc: David Brown Cc: Kukjin Kim Cc: Linus Walleij Cc: Pawel Moll Cc: Rob Herring Cc: Russell King Cc: Sascha Hauer Cc: Shiraz Hashim Cc: Simon Horman Cc: Srinidhi Kasagar Cc: Stephen Warren Cc: Tony Lindgren Cc: Viresh Kumar --- Does OMAP5 need to select TWD? I suspect not if it uses the architected timers. arch/arm/Kconfig | 8 ++-- arch/arm/mach-exynos/Kconfig | 2 ++ arch/arm/mach-highbank/Kconfig | 1 + arch/arm/mach-imx/Kconfig | 2 ++ arch/arm/mach-msm/Kconfig | 7 ++- arch/arm/mach-omap2/Kconfig| 4 arch/arm/mach-realview/Kconfig | 8 arch/arm/mach-vexpress/Kconfig | 2 ++ arch/arm/plat-spear/Kconfig| 2 ++ 9 files changed, 29 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e85f2b6..303ce90 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -639,6 +639,8 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SMP + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ select USE_OF @@ -686,6 +688,8 @@ config ARCH_SHMOBILE select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV select HAVE_SMP + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select GENERIC_CLOCKEVENTS select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT @@ -882,6 +886,8 @@ config ARCH_U8500 select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ select HAVE_SMP + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture @@ -1507,7 +1513,6 @@ config SMP depends on HAVE_SMP depends on MMU select USE_GENERIC_SMP_HELPERS - select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP help This enables support for systems with more than one CPU. If you have a system with only one CPU, like most personal computers, say N. If @@ -1620,7 +1625,6 @@ config LOCAL_TIMERS bool "Use local timer interrupts" depends on SMP default y - select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT) help Enable support for local timers on SMP platforms, rather then the legacy IPI broadcast method. Local timers allows the system diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 4372075..8f97e92 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -15,6 +15,7 @@ config ARCH_EXYNOS4 bool "SAMSUNG EXYNOS4" default y select HAVE_SMP + select HAVE_ARM_SCU if SMP select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems @@ -22,6 +23,7 @@ config ARCH_EXYNOS4 config ARCH_EXYNOS5 bool "SAMSUNG EXYNOS5" select HAVE_SMP + select HAVE_ARM_SCU if SMP help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig index 0e1d0a4..f1ad1f0 100644 --- a/arch/arm/mach-highbank/Kconfig +++ b/arch/arm/mach-highbank/Kconfig @@ -11,5 +11,6 @@ config ARCH_HIGHBANK select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU select HAVE_SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select SPARSE_IRQ select USE_OF diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 519ed57..13f765c 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -759,6 +759,8 @@ config SOC_IMX6Q select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select MFD_SYSCON select PINCTRL select PINCTRL_IMX6Q diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index 7902de15..5bff882 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -44,7 +44,7 @@ endchoice config ARCH_MSM8X60 bool "MSM8X60" - select ARCH_MSM_SCORPIONMP + select HAVE_SMP select ARM_GIC select CPU_V7 select MSM_V2_TLMM @@ -55,7 +55,7 @@ config ARCH_MSM8X60 config ARCH_MSM8960 bool "
Re: arm-soc maintainer entry
On 10/04/12 09:55, Olof Johansson wrote: > Hi, > > On Thu, Oct 4, 2012 at 1:41 AM, Stephen Boyd wrote: >> Is the a...@kernel.org alias going to be added into the MAINTAINERS file? >> Should anybody be sending mails to this address? >> >> It seems I asked this over a year ago and the response was positive but >> nothing ever happened[1]. Maybe something like below? I only ask because >> get_maintainer.pl isn't picking up this email. > I've been holding off re-proposing this, mostly because life is easier > for us if we don't get a...@kernel.org cc:d on every single patch by > people who run get_maintainers.pl -- it's the equivalent of getting > linux-arm-kernel cc:d to your inbox. It's better signal-to-noise ratio > if it's mostly platform maintainers that email us on that address with > pull requests or patches they want applied. > > But yeah, it also means that the maintainer structure is undocumented. > I'm open for suggestions. > Thanks for clarifying. Maybe we can put in the git tree and no email address? That at least documents some structure. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Push selects for TWD/SCU into machine entries
On 10/04/12 02:11, Santosh Shilimkar wrote: >> @@ -75,6 +77,8 @@ config SOC_OMAP5 >> select CPU_V7 >> select ARM_GIC >> select HAVE_SMP >> +select HAVE_ARM_SCU if SMP >> +select HAVE_ARM_TWD if LOCAL_TIMERS >> select ARM_CPU_SUSPEND if PM >> select SOC_HAS_REALTIME_COUNTER >> select ARM_ARCH_TIMER > Drop this change. > > With that fixed, for OMAP changes > > Acked-by: Santosh Shilimkar Thanks. Will drop both lines in this hunk. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Push selects for TWD/SCU into machine entries
On 10/04/12 06:05, Rob Herring wrote: > On 10/04/2012 03:50 AM, Stephen Boyd wrote: >> The TWD and SCU configs are selected by default as long as >> SCORPIONMP is false and/or MCT is false. Implementing the logic >> this way certainly saves lines in the Kconfig but it precludes >> those machines which select SCORPIONMP or MCT from participating >> in the single zImage effort because when those machines are >> combined with other SMP capable machines the TWD and SCU are no >> longer selected. >> >> Push the select out to the machine entries so that we can compile >> these machines together and still select the appropriate configs. > I think this is the wrong direction as I'd like to see the platform > selects shrink. I believe the local timers are run-time enabled now, so > can't we just drop the condition and always select TWD and SCU for > multi-platform? That sounds fine for multi-platform but it penalizes the "optimized" images made for a particular device that doesn't want any extra code than is necessary. Isn't this why we have the Kconfig language? > > Or perhaps we need a CortexA9 config symbol that selects V7, GIC, TWD, > SCU, SMP, PL310, errata, etc. rather than duplicating those for every > platform. > > This sounds like a good consolidation of lines that can be done in parallel to this patch. Care to send a patch on top? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] ARM: Push selects for TWD/SCU into machine entries
The TWD and SCU configs are selected by default as long as MSM_SCORPIONMP is false and/or MCT is false. Implementing the logic this way certainly saves lines in the Kconfig but it precludes those machines which select MSM_SCORPIONMP or MCT from participating in the single zImage effort because when those machines are combined with other SMP capable machines the TWD and SCU are no longer selected by default. Push the select out to the machine entries so that we can compile these machines together and still select the appropriate configs. Signed-off-by: Stephen Boyd Cc: David Brown Cc: Kukjin Kim Cc: Linus Walleij Acked-by: Pawel Moll Cc: Rob Herring Cc: Russell King Acked-by: Santosh Shilimkar Cc: Sascha Hauer Cc: Shiraz Hashim Acked-by: Simon Horman Cc: Srinidhi Kasagar Cc: Stephen Warren Cc: Tony Lindgren Acked-by: Viresh Kumar --- Changes since v1: * Dropped OMAP5 hunk * alphabetical order arch/arm/Kconfig | 8 ++-- arch/arm/mach-exynos/Kconfig | 2 ++ arch/arm/mach-highbank/Kconfig | 1 + arch/arm/mach-imx/Kconfig | 3 ++- arch/arm/mach-msm/Kconfig | 7 ++- arch/arm/mach-omap2/Kconfig| 2 ++ arch/arm/mach-realview/Kconfig | 8 arch/arm/mach-vexpress/Kconfig | 2 ++ arch/arm/plat-spear/Kconfig| 2 ++ 9 files changed, 27 insertions(+), 8 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index fe90e60..53112d0 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -633,6 +633,8 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SMP + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select MIGHT_HAVE_CACHE_L2X0 select SPARSE_IRQ select USE_OF @@ -677,6 +679,8 @@ config ARCH_SHMOBILE bool "Renesas SH-Mobile / R-Mobile" select CLKDEV_LOOKUP select GENERIC_CLOCKEVENTS + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select HAVE_CLK select HAVE_MACH_CLKDEV select HAVE_SMP @@ -875,6 +879,8 @@ config ARCH_U8500 select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_SMP + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture @@ -1490,7 +1496,6 @@ config SMP depends on GENERIC_CLOCKEVENTS depends on HAVE_SMP depends on MMU - select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP select USE_GENERIC_SMP_HELPERS help This enables support for systems with more than one CPU. If you have @@ -1604,7 +1609,6 @@ config LOCAL_TIMERS bool "Use local timer interrupts" depends on SMP default y - select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT) help Enable support for local timers on SMP platforms, rather then the legacy IPI broadcast method. Local timers allows the system diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index da55107..a8176d4 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -14,6 +14,7 @@ menu "SAMSUNG EXYNOS SoCs Support" config ARCH_EXYNOS4 bool "SAMSUNG EXYNOS4" default y + select HAVE_ARM_SCU if SMP select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help @@ -21,6 +22,7 @@ config ARCH_EXYNOS4 config ARCH_EXYNOS5 bool "SAMSUNG EXYNOS5" + select HAVE_ARM_SCU if SMP select HAVE_SMP help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig index 0e1d0a4..d87ac5b 100644 --- a/arch/arm/mach-highbank/Kconfig +++ b/arch/arm/mach-highbank/Kconfig @@ -10,6 +10,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select HAVE_ARM_TWD if LOCAL_TIMERS select HAVE_SMP select SPARSE_IRQ select USE_OF diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 892631f..3887fe2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -833,7 +833,8 @@ config SOC_IMX6Q select ARM_GIC select COMMON_CLK select CPU_V7 - select HAVE_ARM_SCU + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if LOCAL_TIMERS select HAVE_CAN_FLEXCAN if CAN select HAVE_IMX_GPC select HAVE_IMX_MMDC diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index b619085..fceb093 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -44,10 +44,10 @@ endchoice config ARCH_MSM8X60 bool "MSM8X60" - select ARCH_MSM_SCORPIONMP select ARM_GIC select CPU_V7 select GPIO_MSM_V2 + select HAVE_SMP se
[PATCH] MAINTAINERS: Add arm-soc tree entry
Document the arm-soc tree in the maintainers file so that developers know how arm SoC development is structured. Signed-off-by: Stephen Boyd --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 014272b..f70afea 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -637,6 +637,13 @@ W: http://www.arm.linux.org.uk/ S: Maintained F: arch/arm/ +ARM SUB-ARCHITECTURES +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: MAINTAINED +F: arch/arm/mach-*/ +F: arch/arm/plat-*/ +T: git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git + ARM PRIMECELL AACI PL041 DRIVER M: Russell King S: Maintained -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3] ARM: Sort exception table at compile time
Add the ARM machine identifier to sortextable and select the
config option so that we can sort the exception table at compile
time. sortextable relies on a section named __ex_table existing
in the vmlinux, but ARM's linker script places the exception
table in the data section. Give the exception table its own
section so that sortextable can find it.
This allows us to skip the sorting step during boot.
Cc: David Daney
Signed-off-by: Stephen Boyd
---
Changes since v2:
* Refreshed against linux-next
arch/arm/Kconfig | 1 +
arch/arm/kernel/vmlinux.lds.S | 19 +--
scripts/sortextable.c | 1 +
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 73067ef..208414c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -5,6 +5,7 @@ config ARM
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_WANT_IPC_PARSE_VERSION
+ select BUILDTIME_EXTABLE_SORT if MMU
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) &&
!CPU_BIG_ENDIAN
select GENERIC_ATOMIC64 if (CPU_V6 || !CPU_32v6K || !AEABI)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 36ff15b..b9f38e3 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -114,6 +114,15 @@ SECTIONS
RO_DATA(PAGE_SIZE)
+ . = ALIGN(4);
+ __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
+ __start___ex_table = .;
+#ifdef CONFIG_MMU
+ *(__ex_table)
+#endif
+ __stop___ex_table = .;
+ }
+
#ifdef CONFIG_ARM_UNWIND
/*
* Stack unwinding tables
@@ -220,16 +229,6 @@ SECTIONS
READ_MOSTLY_DATA(L1_CACHE_BYTES)
/*
-* The exception fixup table (might need resorting at runtime)
-*/
- . = ALIGN(4);
- __start___ex_table = .;
-#ifdef CONFIG_MMU
- *(__ex_table)
-#endif
- __stop___ex_table = .;
-
- /*
* and the usual data section
*/
DATA_DATA
diff --git a/scripts/sortextable.c b/scripts/sortextable.c
index f19ddc4..1f10e89 100644
--- a/scripts/sortextable.c
+++ b/scripts/sortextable.c
@@ -248,6 +248,7 @@ do_file(char const *const fname)
case EM_S390:
custom_sort = sort_relative_table;
break;
+ case EM_ARM:
case EM_MIPS:
break;
} /* end switch */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM: Push selects for TWD/SCU into machine entries
On 10/24/12 10:54, Stephen Warren wrote: > Where will this patch be merged? > > It probably won't happen for 3.8, but that config fragment will move to > arch/arm/mach-tegra/Kconfig when Tegra enables single zImage support, I > believe. So, it'd be good to make sure this patch gets merged somewhere > that could be used as a baseline for other arm-soc branches if needed, > to avoid merge conflicts. I was hoping this could go through the arm-soc tree for the 3.8 merge window. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: tps65910: Add RTC driver for TPS65910 PMIC RTC
On 7/25/2012 11:35 PM, Venu Byravarasu wrote:
> +
> +static struct rtc_class_ops tps65910_rtc_ops = {
const?
> + .read_time = tps65910_rtc_read_time,
> + .set_time = tps65910_rtc_set_time,
> + .read_alarm = tps65910_rtc_read_alarm,
> + .set_alarm = tps65910_rtc_set_alarm,
> + .alarm_irq_enable = tps65910_rtc_alarm_irq_enable,
> +};
> +
> +static int __devinit tps65910_rtc_probe(struct platform_device *pdev)
> +{
> + struct tps65910 *tps65910 = NULL;
> + struct tps65910_rtc *tps_rtc = NULL;
> + struct tps65910_board *pmic_plat_data;
> + int ret = -EINVAL;
> + int irq = 0;
> + u32 rtc_reg;
It seems like all the above assignments are useless as they're
overwritten later in this function. Can you remove the assignments?
> +
> + tps65910 = dev_get_drvdata(pdev->dev.parent);
> +
> + tps_rtc = devm_kzalloc(&pdev->dev, sizeof(struct tps65910_rtc),
> + GFP_KERNEL);
> + if (!tps_rtc)
> + return -ENOMEM;
> +
> + /* Clear pending interrupts */
> + ret = regmap_read(tps65910->regmap, TPS65910_RTC_STATUS, &rtc_reg);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_write(tps65910->regmap, TPS65910_RTC_STATUS, rtc_reg);
> + if (ret < 0)
> + return ret;
> +
> + dev_dbg(&pdev->dev, "Enabling tps65910-RTC.\n");
Hmph, looks more like stopping the RTC.
> + rtc_reg = TPS65910_RTC_CTRL_STOP_RTC;
> + ret = regmap_write(tps65910->regmap, TPS65910_RTC_CTRL, rtc_reg);
> + if (ret < 0)
> + return ret;
> +
> + pmic_plat_data = dev_get_platdata(tps65910->dev);
> + irq = pmic_plat_data->irq_base;
> + if (irq <= 0) {
> + dev_warn(&pdev->dev, "Wake up is not possible as irq = %d\n",
> + irq);
> + return ret;
> + }
> +
> + irq += TPS65910_IRQ_RTC_ALARM;
> + ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
> + tps65910_rtc_interrupt, IRQF_TRIGGER_LOW,
> + dev_name(&tps_rtc->rtc->dev), &pdev->dev);
How does this work? It doesn't look like tps_rtc->rtc is assigned until
down there at the rtc_device_register() call.
> + if (ret < 0) {
> + dev_err(&pdev->dev, "IRQ is not free.\n");
> + return ret;
> + }
> + device_init_wakeup(&pdev->dev, 1);
> +
> + tps_rtc->rtc = rtc_device_register(pdev->name, &pdev->dev,
> + &tps65910_rtc_ops, THIS_MODULE);
> + if (IS_ERR(tps_rtc->rtc)) {
> + ret = PTR_ERR(tps_rtc->rtc);
> + dev_err(&pdev->dev, "RTC device register: err %d\n", ret);
> + return ret;
> + }
> +
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: tps65910: Add RTC driver for TPS65910 PMIC RTC
On 07/30/12 03:07, Venu Byravarasu wrote:
>
> +
> +static int __devinit tps65910_rtc_probe(struct platform_device *pdev)
> +{
> + struct tps65910 *tps65910 = NULL;
> + struct tps65910_rtc *tps_rtc = NULL;
> + struct tps65910_board *pmic_plat_data;
> + int ret = -EINVAL;
> + int irq = 0;
> + u32 rtc_reg;
>> It seems like all the above assignments are useless as they're
>> overwritten later in this function. Can you remove the assignments?
>>
> Some of the non-intelligent compilers/tools complain as variables
> may get used uninitialized. Hence to avoid such complaints, initialized
> them to some default values.
> What harm do you see if I have local variables initialized during their
> declaration?
If you return early from a function and forget to give a variable a
value you actually want, you may use it pre-initialized with a bad
value. I would be surprised if a compiler complained about these ones
because they are simple assignments and they aren't under conditional
paths. If there is still a problem, you can use the uninitialized_var()
macro but I don't see why you would need to.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: Sort exception table at compile time
Add the ARM machine identifier to sortextable and select the
config option so that we can sort the exception table at compile
time. sortextable relies on a section named __ex_table existing
in the vmlinux, but ARM's linker script places the exception
table in the data section. Give the exception table its own
section so that sortextable can find it.
This allows us to skip the runtime sorting step during boot.
Signed-off-by: Stephen Boyd
Cc: David Daney
---
I can't find any information on why the exception table lives in the data
section. If there's a good reason for that, I'll look into changing
sortextable to look for the __start___ex_table symbol.
arch/arm/Kconfig | 1 +
arch/arm/kernel/vmlinux.lds.S | 19 +--
scripts/sortextable.c | 1 +
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b25c9d3..2af95e6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,6 +1,7 @@
config ARM
bool
default y
+ select BUILDTIME_EXTABLE_SORT if MMU
select ARCH_HAVE_CUSTOM_GPIO_H
select HAVE_AOUT
select HAVE_DMA_API_DEBUG
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 36ff15b..0e3e8b4 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -220,16 +220,6 @@ SECTIONS
READ_MOSTLY_DATA(L1_CACHE_BYTES)
/*
-* The exception fixup table (might need resorting at runtime)
-*/
- . = ALIGN(4);
- __start___ex_table = .;
-#ifdef CONFIG_MMU
- *(__ex_table)
-#endif
- __stop___ex_table = .;
-
- /*
* and the usual data section
*/
DATA_DATA
@@ -239,6 +229,15 @@ SECTIONS
}
_edata_loc = __data_loc + SIZEOF(.data);
+ . = ALIGN(4);
+ __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
+ __start___ex_table = .;
+#ifdef CONFIG_MMU
+ *(__ex_table)
+#endif
+ __stop___ex_table = .;
+ }
+
#ifdef CONFIG_HAVE_TCM
/*
* We align everything to a page boundary so we can
diff --git a/scripts/sortextable.c b/scripts/sortextable.c
index 1ca9ceb..591acb3 100644
--- a/scripts/sortextable.c
+++ b/scripts/sortextable.c
@@ -248,6 +248,7 @@ do_file(char const *const fname)
custom_sort = sort_x86_table;
break;
case EM_MIPS:
+ case EM_ARM:
break;
} /* end switch */
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Sort exception table at compile time
On 07/30/12 14:56, Russell King - ARM Linux wrote: > On Mon, Jul 30, 2012 at 02:30:03PM -0700, Stephen Boyd wrote: >> Add the ARM machine identifier to sortextable and select the >> config option so that we can sort the exception table at compile >> time. sortextable relies on a section named __ex_table existing >> in the vmlinux, but ARM's linker script places the exception >> table in the data section. Give the exception table its own >> section so that sortextable can find it. >> >> This allows us to skip the runtime sorting step during boot. >> >> Signed-off-by: Stephen Boyd >> Cc: David Daney >> --- >> >> I can't find any information on why the exception table lives in the data >> section. If there's a good reason for that, I'll look into changing >> sortextable to look for the __start___ex_table symbol. > Be careful about the placement of this, especially with XIP. > Thanks for the hint. I'm unfamiliar with how XIP works so I'll take a closer look there. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Sort exception table at compile time
On 07/30/12 15:19, Russell King - ARM Linux wrote: > On Mon, Jul 30, 2012 at 11:51:18PM +0200, Sam Ravnborg wrote: >> Here you should be able to use the macro EXCEPTION_TABLE from >> vmlinux.lds.h. >> I cannot see why the ifdef for not NON-MMU case is needed, >> but if it is needed the macro is not good... > Because you can not mention the same input section in two different > places and end up with predictable output from the linker. > > We discard the __ex_table for noMMU, but I think the start/stop > symbols are still referenced somewhere. Dunno, I don't have much to > do with noMMU ARM, and the only platform I'd be interested in never > got merged. I was thinking, perhaps we can ifdef out the exception fixup sections in the places where they're added? Then we can just use the EXCEPTION_TABLE macro from vmlinux.lds.h knowing that there are no __ex_table sections in the input object files? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Sort exception table at compile time
On 07/30/12 15:38, Stephen Boyd wrote: > On 07/30/12 14:56, Russell King - ARM Linux wrote: >> On Mon, Jul 30, 2012 at 02:30:03PM -0700, Stephen Boyd wrote: >>> Add the ARM machine identifier to sortextable and select the >>> config option so that we can sort the exception table at compile >>> time. sortextable relies on a section named __ex_table existing >>> in the vmlinux, but ARM's linker script places the exception >>> table in the data section. Give the exception table its own >>> section so that sortextable can find it. >>> >>> This allows us to skip the runtime sorting step during boot. >>> >>> Signed-off-by: Stephen Boyd >>> Cc: David Daney >>> --- >>> >>> I can't find any information on why the exception table lives in the data >>> section. If there's a good reason for that, I'll look into changing >>> sortextable to look for the __start___ex_table symbol. >> Be careful about the placement of this, especially with XIP. >> > Thanks for the hint. I'm unfamiliar with how XIP works so I'll take a > closer look there. > Ok. It looks like the exception table is placed in the data section so that XIP kernels can boot up and sort the exception table (otherwise the exception table would be in read-only flash). Now that the exception table is sorted at compile time, we should be able to place the exception table in the rodata area, essentially placing the table in the non-volatile storage on XIP kernels. I propose we move the exception table right after the rodata. Other arches (x86/mips) may actually want to put the exception table into the rodata, but that looks like a larger change. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] ARM: msm: Remove custom clk_set_{max,min}_rate() API
There are no users of this API anymore so let's just remove it.
If a need arises in the future we can extend the common clock API
to handle it.
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
arch/arm/mach-msm/clock-debug.c | 9 +
arch/arm/mach-msm/clock.c| 12
arch/arm/mach-msm/include/mach/clk.h | 6 --
3 files changed, 1 insertion(+), 26 deletions(-)
diff --git a/arch/arm/mach-msm/clock-debug.c b/arch/arm/mach-msm/clock-debug.c
index 4886404..c4b34d7 100644
--- a/arch/arm/mach-msm/clock-debug.c
+++ b/arch/arm/mach-msm/clock-debug.c
@@ -25,14 +25,7 @@ static int clock_debug_rate_set(void *data, u64 val)
struct clk *clock = data;
int ret;
- /* Only increases to max rate will succeed, but that's actually good
-* for debugging purposes so we don't check for error. */
- if (clock->flags & CLK_MAX)
- clk_set_max_rate(clock, val);
- if (clock->flags & CLK_MIN)
- ret = clk_set_min_rate(clock, val);
- else
- ret = clk_set_rate(clock, val);
+ ret = clk_set_rate(clock, val);
if (ret != 0)
printk(KERN_ERR "clk_set%s_rate failed (%d)\n",
(clock->flags & CLK_MIN) ? "_min" : "", ret);
diff --git a/arch/arm/mach-msm/clock.c b/arch/arm/mach-msm/clock.c
index 5fac2df..8d07b25 100644
--- a/arch/arm/mach-msm/clock.c
+++ b/arch/arm/mach-msm/clock.c
@@ -97,18 +97,6 @@ long clk_round_rate(struct clk *clk, unsigned long rate)
}
EXPORT_SYMBOL(clk_round_rate);
-int clk_set_min_rate(struct clk *clk, unsigned long rate)
-{
- return clk->ops->set_min_rate(clk->id, rate);
-}
-EXPORT_SYMBOL(clk_set_min_rate);
-
-int clk_set_max_rate(struct clk *clk, unsigned long rate)
-{
- return clk->ops->set_max_rate(clk->id, rate);
-}
-EXPORT_SYMBOL(clk_set_max_rate);
-
int clk_set_parent(struct clk *clk, struct clk *parent)
{
return -ENOSYS;
diff --git a/arch/arm/mach-msm/include/mach/clk.h
b/arch/arm/mach-msm/include/mach/clk.h
index 5f1c37d..fd4f4a7 100644
--- a/arch/arm/mach-msm/include/mach/clk.h
+++ b/arch/arm/mach-msm/include/mach/clk.h
@@ -25,12 +25,6 @@ enum clk_reset_action {
struct clk;
-/* Rate is minimum clock rate in Hz */
-int clk_set_min_rate(struct clk *clk, unsigned long rate);
-
-/* Rate is maximum clock rate in Hz */
-int clk_set_max_rate(struct clk *clk, unsigned long rate);
-
/* Assert/Deassert reset to a hardware block associated with a clock */
int clk_reset(struct clk *clk, enum clk_reset_action action);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
