* [kvmarm] [PATCH v6 14/15] KVM: ARM: Power State Coordination Interface implementation
From: Peter Maydell @ 2013-01-21 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dfd76d65ce8e16c6792a47262d27dda2@localhost>
On 21 January 2013 18:08, Marc Zyngier <marc.zyngier@arm.com> wrote:
> I still have hope for QEMU to move forward and eventually generate a DT
> based on the host capabilities.
We might improve our "modify the DT the user passed us" code, but
I don't currently anticipate "generate a DT from scratch". In
my experience using anything other that the DT which came from
the same tree as the kernel itself is just asking for the kernel
to crash with some really obscure and unhelpful error message,
so QEMU generating a DT is just going to result in a pile of
bugs on the QEMU list where users say "new kernel doesn't boot"...
-- PMM
^ permalink raw reply
* [PATCH 1/6] arm: mvebu: Add support for local interrupt
From: Thomas Petazzoni @ 2013-01-21 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-2-git-send-email-gregory.clement@free-electrons.com>
Dear Gregory CLEMENT,
Just some minor nitpicks below.
On Mon, 21 Jan 2013 18:53:57 +0100, Gregory CLEMENT wrote:
> + if (hw < ARMADA_370_XP_MAX_PER_CPU_IRQS) {
> +
Unneeded empty line.
> + irq_set_percpu_devid(virq);
> + irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
> + handle_percpu_devid_irq);
> +
> + } else {
> + irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
> + handle_level_irq);
> + }
Braces useless since there is only one statement in the else.
> + set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
Incorrect indentation for this line.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [kvmarm] [PATCH v6 14/15] KVM: ARM: Power State Coordination Interface implementation
From: Marc Zyngier @ 2013-01-21 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qKDQrfSZC8knciajyeZWcX0CGObuYPrFA_RTEpUzBhBow@mail.gmail.com>
On Mon, 21 Jan 2013 12:54:22 -0500, Christoffer Dall
<c.dall@virtualopensystems.com> wrote:
> On Mon, Jan 21, 2013 at 12:43 PM, Marc Zyngier <marc.zyngier@arm.com>
> wrote:
>> On Mon, 21 Jan 2013 09:50:18 -0500, Christoffer Dall
>> <c.dall@virtualopensystems.com> wrote:
>>> On Mon, Jan 21, 2013 at 5:04 AM, Marc Zyngier <marc.zyngier@arm.com>
>> wrote:
>>>> On Sun, 20 Jan 2013 18:35:51 -0500, Christoffer Dall
>>>> <c.dall@virtualopensystems.com> wrote:
>>>>> On Thu, Jan 17, 2013 at 10:55 AM, Marc Zyngier
<marc.zyngier@arm.com>
>>>>> wrote:
>>>>>> On 16/01/13 17:59, Christoffer Dall wrote:
>>>>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>>>>
>>>>>>> Implement the PSCI specification (ARM DEN 0022A) to control
>>>>>>> virtual CPUs being "powered" on or off.
>>>>>>>
>>>>>>> PSCI/KVM is detected using the KVM_CAP_ARM_PSCI capability.
>>>>>>>
>>>>>>> A virtual CPU can now be initialized in a "powered off" state,
>>>>>>> using the KVM_ARM_VCPU_POWER_OFF feature flag.
>>>>>>>
>>>>>>> The guest can use either SMC or HVC to execute a PSCI function.
>>>>>>>
>>>>>>> Reviewed-by: Will Deacon <will.deacon@arm.com>
>>>>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>>>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>>>>>>
>>>>>> A few bits went wrong when you reworked this patch. See below.
>>>>
>>>> [...]
>>>>
>>>>>>> @@ -443,13 +445,17 @@ static int handle_hvc(struct kvm_vcpu *vcpu,
>>>>>>> struct kvm_run *run)
>>>>>>> trace_kvm_hvc(*vcpu_pc(vcpu), *vcpu_reg(vcpu, 0),
>>>>>>> vcpu->arch.hsr & HSR_HVC_IMM_MASK);
>>>>>>>
>>>>>>> + if (kvm_psci_call(vcpu))
>>>>>>> + return 1;
>>>>>>> +
>>>>>>> return 1;
>>>>>>
>>>>>> No undef injection if there is no PSCI match?
>>>>
>>>> You haven't addressed this issue in you patch.
>>>>
>>> right, well, it's actually quite nice not having it give you an
>>> undefined exception when it logs the trace event. The psci protocol
>>> relies on a confirmation in form of a return value anyhow, so it was
>>> actually on purpose to remove it, so you can do things like easily
>>> measure exit times or probe places in the guest.
>>
>> If that's for tracing purpose, why don't you allocate another
hypercall?
>> Returning to the guest without signalling that nothing was executed
seems
>> very wrong to me.
>>
> hmm, yeah, maybe you're right.
>
> I was just debating with myself whether an undefined isn't too rough.
> It made sense when we didn't have any kind of handling of hvc, but now
> an hvc isn't really an undefined instruction, and if we assume that we
> have a series of hypercalls, multiplexed by a number in r0, but you
> don't really know what's available on your VM host, it also seems very
> wrong to have an ABI that says, try it, and if it's not implemented
> handle the undefined exception.... Know what I mean? perhaps we should
> return -1 in r0 instead or something.
Aside from the API discovery discussion, my thoughts on the HVC semantics:
The way I see it, HVC effectively becomes an undefined instruction if the
upper layer doesn't know about the requested service. This is very
different from "I know what you mean, but I can't do it now". We should
really tell the guest "I have no clue what you're talking about", because
something is utterly wrong. This is a case of not being able to give the VM
the semantics it expects, and trying to paper over it.
Now, returning something in r0 could have been a possibility if it was
specified in the ARM ARM, and it is not. So we can already forget about it.
> We can of course argue that we should have an HVC discovery API or
> that everything should be set in device tree, but the latter doesn't
> really fit well with the way we do things now with qemu at least.
I still have hope for QEMU to move forward and eventually generate a DT
based on the host capabilities.
M.
--
Fast, cheap, reliable. Pick two.
^ permalink raw reply
* [PATCH 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
From: Tony Lindgren @ 2013-01-21 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FCF8D7.1010609@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130121 00:16]:
> On Friday 18 January 2013 10:49 PM, Tony Lindgren wrote:
> >* Santosh Shilimkar <santosh.shilimkar@ti.com> [130118 07:30]:
> >>From: Rajendra Nayak <rnayak@ti.com>
> >>
> >>Add the clock tree related data for OMAP54xx platforms.
> >>
> >>Cc: Paul Walmsley <paul@pwsan.com>
> >>
> >>Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> >>Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> >>[santosh.shilimkar at ti.com: Generated es2.0 data]
> >>Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >>---
> >>As mentioned in the summary, this patch will be updated once the
> >>movement of clock data to drivers/clock is clear.
> >
> >Yes let's first fix up the issues prevent us from moving all the
> >cclock*_data.c files to live under drivers/clock/omap.
> >
> >It seems that fixing this issue boils down to rearranging some
> >clock related headers in arch/arm/mach-omap2, and then populating
> >some of the clock data dynamically. Or am I missing something?
> >
> Am not sure of all the dependencies. Since clock data is using the low
> level prm/cm APIs, all those needs to be exported some how to move
> the data. Paul can comment better on it.
It seems that we should be able to export some omap specific
functions from drivers/clk/omap for that.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/6] clocksource: time-armada-370-xp: add local timer support
From: Gregory CLEMENT @ 2013-01-21 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121175927.GV23505@n2100.arm.linux.org.uk>
On 01/21/2013 06:59 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 21, 2013 at 06:53:58PM +0100, Gregory CLEMENT wrote:
>> +struct clock_event_device __percpu **percpu_armada_370_xp_evt;
>> +
>
> Have you run this through checkpatch? Should the above be static?
>
Yes (and it didn't complain) and yes it should be static, I will fix
this in the V2.
Thanks
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
From: Tony Lindgren @ 2013-01-21 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD5993.5010008@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130121 07:09]:
> >
> So I looked at this one with help of Rajendra. We can get rid of the
> IRQ and DMA data(needs DMA biding updates) easily. The address
> space though is needed since hwmod code uses it to setup the
> sysconfig registers.
OK great. The address space tinkering in hwmod code should be
moved to be done in the drivers.
As discussed earlier, there should be a driver specific reset
function driver_xyz_reset() in the driver header file so the
hwmod code can call it too in a late_initcall if no driver is
loaded.
> Extracting that from DT code seems to be really expensive and
> ugly [1]. I am yet to try out DMA lines removal but that seems
> to be doable by pulling Vinod'd DMA engine branch and updating
> DT file.
The overhead here does not matter as it should only happen in a
late_initcall and only for some of the drivers. For that to
happen we just need to go through the list of modules not yet
probed. We also need to have some locking in the driver specific
reset function to avoid races with the loadable modules.
> Whats your suggestion on address space part ?
Let's add the code to hwmod to extract it from DT so hwmod code
can call the driver specific reset function defined in the driver
header. That way we can start moving the driver code out of hwmod
one driver at a time.
Note that the ioremapping should be done in the driver specific
reset function, not in hwmod code. We just need to pass the
iorange in a struct resource to the driver specific reset function.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/6] clocksource: time-armada-370-xp: add local timer support
From: Russell King - ARM Linux @ 2013-01-21 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-3-git-send-email-gregory.clement@free-electrons.com>
On Mon, Jan 21, 2013 at 06:53:58PM +0100, Gregory CLEMENT wrote:
> +struct clock_event_device __percpu **percpu_armada_370_xp_evt;
> +
Have you run this through checkpatch? Should the above be static?
^ permalink raw reply
* [kvmarm] [PATCH v6 14/15] KVM: ARM: Power State Coordination Interface implementation
From: Christoffer Dall @ 2013-01-21 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <832da358616729fd6a5d6522682b022f@localhost>
On Mon, Jan 21, 2013 at 12:43 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Mon, 21 Jan 2013 09:50:18 -0500, Christoffer Dall
> <c.dall@virtualopensystems.com> wrote:
>> On Mon, Jan 21, 2013 at 5:04 AM, Marc Zyngier <marc.zyngier@arm.com>
> wrote:
>>> On Sun, 20 Jan 2013 18:35:51 -0500, Christoffer Dall
>>> <c.dall@virtualopensystems.com> wrote:
>>>> On Thu, Jan 17, 2013 at 10:55 AM, Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>> On 16/01/13 17:59, Christoffer Dall wrote:
>>>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>>>
>>>>>> Implement the PSCI specification (ARM DEN 0022A) to control
>>>>>> virtual CPUs being "powered" on or off.
>>>>>>
>>>>>> PSCI/KVM is detected using the KVM_CAP_ARM_PSCI capability.
>>>>>>
>>>>>> A virtual CPU can now be initialized in a "powered off" state,
>>>>>> using the KVM_ARM_VCPU_POWER_OFF feature flag.
>>>>>>
>>>>>> The guest can use either SMC or HVC to execute a PSCI function.
>>>>>>
>>>>>> Reviewed-by: Will Deacon <will.deacon@arm.com>
>>>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>>>>>
>>>>> A few bits went wrong when you reworked this patch. See below.
>>>
>>> [...]
>>>
>>>>>> @@ -443,13 +445,17 @@ static int handle_hvc(struct kvm_vcpu *vcpu,
>>>>>> struct kvm_run *run)
>>>>>> trace_kvm_hvc(*vcpu_pc(vcpu), *vcpu_reg(vcpu, 0),
>>>>>> vcpu->arch.hsr & HSR_HVC_IMM_MASK);
>>>>>>
>>>>>> + if (kvm_psci_call(vcpu))
>>>>>> + return 1;
>>>>>> +
>>>>>> return 1;
>>>>>
>>>>> No undef injection if there is no PSCI match?
>>>
>>> You haven't addressed this issue in you patch.
>>>
>> right, well, it's actually quite nice not having it give you an
>> undefined exception when it logs the trace event. The psci protocol
>> relies on a confirmation in form of a return value anyhow, so it was
>> actually on purpose to remove it, so you can do things like easily
>> measure exit times or probe places in the guest.
>
> If that's for tracing purpose, why don't you allocate another hypercall?
> Returning to the guest without signalling that nothing was executed seems
> very wrong to me.
>
hmm, yeah, maybe you're right.
I was just debating with myself whether an undefined isn't too rough.
It made sense when we didn't have any kind of handling of hvc, but now
an hvc isn't really an undefined instruction, and if we assume that we
have a series of hypercalls, multiplexed by a number in r0, but you
don't really know what's available on your VM host, it also seems very
wrong to have an ABI that says, try it, and if it's not implemented
handle the undefined exception.... Know what I mean? perhaps we should
return -1 in r0 instead or something.
We can of course argue that we should have an HVC discovery API or
that everything should be set in device tree, but the latter doesn't
really fit well with the way we do things now with qemu at least.
^ permalink raw reply
* [PATCH 6/6] clocksource: update and move armada-370-xp-timer documentation to timer directory
From: Gregory CLEMENT @ 2013-01-21 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-1-git-send-email-gregory.clement@free-electrons.com>
Timer driver for Armada 370 and Armada XP have gained local timers
support. So it needs new resources information regarding the IRQs
and the registers.
Also move the documentation in the new and more accurate directory
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../bindings/arm/armada-370-xp-timer.txt | 12 ------------
.../bindings/timer/marvell,armada-370-xp-timer.txt | 15 +++++++++++++++
2 files changed, 15 insertions(+), 12 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
deleted file mode 100644
index 6483011..0000000
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Marvell Armada 370 and Armada XP Global Timers
-----------------------------------------------
-
-Required properties:
-- compatible: Should be "marvell,armada-370-xp-timer"
-- interrupts: Should contain the list of Global Timer interrupts
-- reg: Should contain the base address of the Global Timer registers
-- clocks: clock driving the timer hardware
-
-Optional properties:
-- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
- Mhz fixed mode (available on Armada XP and not on Armada 370)
diff --git a/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
new file mode 100644
index 0000000..3638112
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
@@ -0,0 +1,15 @@
+Marvell Armada 370 and Armada XP Timers
+---------------------------------------
+
+Required properties:
+- compatible: Should be "marvell,armada-370-xp-timer"
+- interrupts: Should contain the list of Global Timer interrupts and
+ then local timer interrupts
+- reg: Should contain location and length for timers register. First
+ pair for the Global Timer registers, second pair for the
+ local/private timers.
+- clocks: clock driving the timer hardware
+
+Optional properties:
+- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
+ Mhz fixed mode (available on Armada XP and not on Armada 370)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/6] arm: mvebu: update DT to support local timers
From: Gregory CLEMENT @ 2013-01-21 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-1-git-send-email-gregory.clement@free-electrons.com>
Now that the time-armada-370-xp support local timers, updated the
device tree to take it into account.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 4c0abe8..aa6a187 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -68,8 +68,9 @@
timer at d0020300 {
compatible = "marvell,armada-370-xp-timer";
- reg = <0xd0020300 0x30>;
- interrupts = <37>, <38>, <39>, <40>;
+ reg = <0xd0020300 0x30>,
+ <0xd0021040 0x30>;
+ interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
clocks = <&coreclk 2>;
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/6] arm: mvebu: update defconfig with local timer support
From: Gregory CLEMENT @ 2013-01-21 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-1-git-send-email-gregory.clement@free-electrons.com>
Now that we have support for local timers, enable it by default
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index b5bc96c..28c1e38 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -14,7 +14,6 @@ CONFIG_MACH_ARMADA_XP=y
# CONFIG_CACHE_L2X0 is not set
# CONFIG_SWP_EMULATE is not set
CONFIG_SMP=y
-# CONFIG_LOCAL_TIMERS is not set
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
# CONFIG_COMPACTION is not set
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/6] arm: kconfig: don't select TWD with local timer for Armada 370/XP
From: Gregory CLEMENT @ 2013-01-21 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-1-git-send-email-gregory.clement@free-electrons.com>
The Armada 370 and Armada XP SoCs don't use the TWD timers, so don't
select it by default if CONFIG_LOCAL_TIMERS is selected
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..4c4d010 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1624,7 +1624,7 @@ config LOCAL_TIMERS
bool "Use local timer interrupts"
depends on SMP
default y
- select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
+ select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT && !ARMADA_370_XP_TIMER)
help
Enable support for local timers on SMP platforms, rather then the
legacy IPI broadcast method. Local timers allows the system
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/6] clocksource: time-armada-370-xp: add local timer support
From: Gregory CLEMENT @ 2013-01-21 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-1-git-send-email-gregory.clement@free-electrons.com>
On the SOCs Armada 370 and Armada XP, each CPU comes with two private
timers. This patch use the timer 0 of each CPU as local timer for the
clockevent if CONFIG_LOCAL_TIMER is selected. In the other case, use
only the private Timer 0 of CPU 0.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/clocksource/time-armada-370-xp.c | 150 ++++++++++++++++++++++--------
1 file changed, 112 insertions(+), 38 deletions(-)
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index a4605fd..757f034 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -27,8 +27,10 @@
#include <linux/of_address.h>
#include <linux/irq.h>
#include <linux/module.h>
-#include <asm/sched_clock.h>
+#include <asm/sched_clock.h>
+#include <asm/localtimer.h>
+#include <linux/percpu.h>
/*
* Timer block registers.
*/
@@ -49,6 +51,7 @@
#define TIMER1_RELOAD_OFF 0x0018
#define TIMER1_VAL_OFF 0x001c
+#define LCL_TIMER_EVENTS_STATUS 0x0028
/* Global timers are connected to the coherency fabric clock, and the
below divider reduces their incrementing frequency. */
#define TIMER_DIVIDER_SHIFT 5
@@ -57,14 +60,17 @@
/*
* SoC-specific data.
*/
-static void __iomem *timer_base;
-static int timer_irq;
+static void __iomem *timer_base, *local_base;
+static unsigned int timer_clk;
+static bool timer25Mhz = true;
/*
* Number of timer ticks per jiffy.
*/
static u32 ticks_per_jiffy;
+struct clock_event_device __percpu **percpu_armada_370_xp_evt;
+
static u32 notrace armada_370_xp_read_sched_clock(void)
{
return ~readl(timer_base + TIMER0_VAL_OFF);
@@ -78,24 +84,23 @@ armada_370_xp_clkevt_next_event(unsigned long delta,
struct clock_event_device *dev)
{
u32 u;
-
/*
* Clear clockevent timer interrupt.
*/
- writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
+ writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
/*
* Setup new clockevent timer value.
*/
- writel(delta, timer_base + TIMER1_VAL_OFF);
+ writel(delta, local_base + TIMER0_VAL_OFF);
/*
* Enable the timer.
*/
- u = readl(timer_base + TIMER_CTRL_OFF);
- u = ((u & ~TIMER1_RELOAD_EN) | TIMER1_EN |
- TIMER1_DIV(TIMER_DIVIDER_SHIFT));
- writel(u, timer_base + TIMER_CTRL_OFF);
+ u = readl(local_base + TIMER_CTRL_OFF);
+ u = ((u & ~TIMER0_RELOAD_EN) | TIMER0_EN |
+ TIMER0_DIV(TIMER_DIVIDER_SHIFT));
+ writel(u, local_base + TIMER_CTRL_OFF);
return 0;
}
@@ -107,37 +112,38 @@ armada_370_xp_clkevt_mode(enum clock_event_mode mode,
u32 u;
if (mode == CLOCK_EVT_MODE_PERIODIC) {
+
/*
* Setup timer to fire at 1/HZ intervals.
*/
- writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD_OFF);
- writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL_OFF);
+ writel(ticks_per_jiffy - 1, local_base + TIMER0_RELOAD_OFF);
+ writel(ticks_per_jiffy - 1, local_base + TIMER0_VAL_OFF);
/*
* Enable timer.
*/
- u = readl(timer_base + TIMER_CTRL_OFF);
- writel((u | TIMER1_EN | TIMER1_RELOAD_EN |
- TIMER1_DIV(TIMER_DIVIDER_SHIFT)),
- timer_base + TIMER_CTRL_OFF);
+ u = readl(local_base + TIMER_CTRL_OFF);
+
+ writel((u | TIMER0_EN | TIMER0_RELOAD_EN |
+ TIMER0_DIV(TIMER_DIVIDER_SHIFT)),
+ local_base + TIMER_CTRL_OFF);
} else {
/*
* Disable timer.
*/
- u = readl(timer_base + TIMER_CTRL_OFF);
- writel(u & ~TIMER1_EN, timer_base + TIMER_CTRL_OFF);
+ u = readl(local_base + TIMER_CTRL_OFF);
+ writel(u & ~TIMER0_EN, local_base + TIMER_CTRL_OFF);
/*
* ACK pending timer interrupt.
*/
- writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
-
+ writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
}
}
static struct clock_event_device armada_370_xp_clkevt = {
- .name = "armada_370_xp_tick",
+ .name = "armada_370_xp_per_cpu_tick",
.features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
.shift = 32,
.rating = 300,
@@ -150,32 +156,78 @@ 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;
- writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
- armada_370_xp_clkevt.event_handler(&armada_370_xp_clkevt);
+ writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
+ evt->event_handler(evt);
return IRQ_HANDLED;
}
-static struct irqaction armada_370_xp_timer_irq = {
- .name = "armada_370_xp_tick",
- .flags = IRQF_DISABLED | IRQF_TIMER,
- .handler = armada_370_xp_timer_interrupt
+/*
+ * Setup the local clock events for a CPU.
+ */
+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->set_next_event = armada_370_xp_clkevt_next_event,
+ evt->set_mode = armada_370_xp_clkevt_mode,
+ evt->cpumask = cpumask_of(cpu);
+
+ *__this_cpu_ptr(percpu_armada_370_xp_evt) = evt;
+
+ clockevents_config_and_register(evt, timer_clk, 1, 0xfffffffe);
+ enable_percpu_irq(evt->irq, 0);
+
+ return 0;
+}
+
+static void 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,
};
void __init armada_370_xp_timer_init(void)
{
u32 u;
struct device_node *np;
- unsigned int timer_clk;
+ int res;
+
np = of_find_compatible_node(NULL, NULL, "marvell,armada-370-xp-timer");
timer_base = of_iomap(np, 0);
WARN_ON(!timer_base);
+ local_base = of_iomap(np, 1);
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 | TIMER1_25MHZ,
+ writel(u | TIMER0_25MHZ,
timer_base + TIMER_CTRL_OFF);
timer_clk = 25000000;
} else {
@@ -183,15 +235,23 @@ void __init armada_370_xp_timer_init(void)
struct clk *clk = of_clk_get(np, 0);
WARN_ON(IS_ERR(clk));
rate = clk_get_rate(clk);
+ 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 | TIMER1_25MHZ),
+ writel(u & ~(TIMER0_25MHZ),
timer_base + TIMER_CTRL_OFF);
+
timer_clk = rate / TIMER_DIVIDER;
+ timer25Mhz = false;
}
- /* We use timer 0 as clocksource, and timer 1 for
- clockevents */
- timer_irq = irq_of_parse_and_map(np, 1);
+ /*
+ * We use timer 0 as clocksource, and private(local) timer 0
+ * for clockevents
+ */
+ armada_370_xp_clkevt.irq = irq_of_parse_and_map(np, 4);
ticks_per_jiffy = (timer_clk + HZ / 2) / HZ;
@@ -216,12 +276,26 @@ void __init armada_370_xp_timer_init(void)
"armada_370_xp_clocksource",
timer_clk, 300, 32, clocksource_mmio_readl_down);
- /*
- * Setup clockevent timer (interrupt-driven).
- */
- setup_irq(timer_irq, &armada_370_xp_timer_irq);
+ /* Register the clockevent on the private timer of CPU 0 */
armada_370_xp_clkevt.cpumask = cpumask_of(0);
clockevents_config_and_register(&armada_370_xp_clkevt,
timer_clk, 1, 0xfffffffe);
-}
+ percpu_armada_370_xp_evt = alloc_percpu(struct clock_event_device *);
+
+
+ /*
+ * Setup clockevent timer (interrupt-driven).
+ */
+ *__this_cpu_ptr(percpu_armada_370_xp_evt) = &armada_370_xp_clkevt;
+ res = request_percpu_irq(armada_370_xp_clkevt.irq,
+ armada_370_xp_timer_interrupt,
+ armada_370_xp_clkevt.name,
+ percpu_armada_370_xp_evt);
+ if (!res) {
+ enable_percpu_irq(armada_370_xp_clkevt.irq, 0);
+#ifdef CONFIG_LOCAL_TIMERS
+ local_timer_register(&armada_370_xp_local_timer_ops);
+#endif
+ }
+}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/6] arm: mvebu: Add support for local interrupt
From: Gregory CLEMENT @ 2013-01-21 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-1-git-send-email-gregory.clement@free-electrons.com>
MPIC allows the use of private interrupt for each CPUs. The 28th first
interrupts are per-cpu. This patch adds support to use them.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/irq-armada-370-xp.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index f99a4a2..c007fdc 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -145,11 +145,19 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
{
armada_370_xp_irq_mask(irq_get_irq_data(virq));
writel(hw, main_int_base + ARMADA_370_XP_INT_SET_ENABLE_OFFS);
-
- irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
- handle_level_irq);
irq_set_status_flags(virq, IRQ_LEVEL);
- set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+
+ if (hw < ARMADA_370_XP_MAX_PER_CPU_IRQS) {
+
+ irq_set_percpu_devid(virq);
+ irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
+ handle_percpu_devid_irq);
+
+ } else {
+ irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
+ handle_level_irq);
+ }
+ set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
return 0;
}
@@ -245,7 +253,7 @@ asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
if (irqnr > 1022)
break;
- if (irqnr >= 8) {
+ if (irqnr > 0) {
irqnr = irq_find_mapping(armada_370_xp_mpic_domain,
irqnr);
handle_IRQ(irqnr, regs);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/6] arm: mvebu: add support for local timer for Armada 370/XP
From: Gregory CLEMENT @ 2013-01-21 17:53 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
The Armada XP SoCs comes with private timers. This allows us to use
local timers through CONFIG_LOCAL_TIMERS and as stated in the kconfig
help, it prevents a "thundering herd" at every timer tick.
Armada 370 also have these private timers, and even if it comes only
with a single CPU, the feature is also enabled for this SoC to keep
the code generic.
In order to be able to use the local timer, I also had to add the
support for the per-CPU interrupts.
As this patch set need to modify several sub-systems, I'd like that
Jason take the whole series with the acked-by of each maintainer.
Jason I also try to create the patch to fit the order you expect
drivers, then boards and finally dt.
The 1st patch which add support for local interrupt should go directly
to the driver branch of Jason.
The 2nd patch which adds local timer support for Armada 370/XP should
received a acked-by John Stultz or Thomas Gleixner before going to the
driver branch of Jason.
For the 3rd patch, which just allow to not select TWD by default when
local timers are selected for Armada 370/XP, it would be nice if
Russell could give his acked-by. I think this patch should go to the
board branch of Jason, but I am not sure.
The 4th patch is an update to the mvebu_defconfig and should go to the
board branch of Jason.
The 5th and 6th patches are about the DT bindings. An acked-by or at
least a reviewed-by from Rob Herring or Grant Likely would be nice
before going ending to the dt branch of Jason.
This patch set is based on 3.8-rc4 and is obviously 3.9 material. The
git branch called local_timer is available at:
https://github.com/MISL-EBU-System-SW/mainline-public.git.
Thanks,
Gregory CLEMENT (6):
arm: mvebu: Add support for local interrupt
clocksource: time-armada-370-xp: add local timer support
arm: kconfig: don't select TWD with local timer for Armada 370/XP
arm: mvebu: update defconfig with local timer support
arm: mvebu: update DT to support local timers
clocksource: update and move armada-370-xp-timer documentation to
timer directory
.../bindings/arm/armada-370-xp-timer.txt | 12 --
.../bindings/timer/marvell,armada-370-xp-timer.txt | 15 ++
arch/arm/Kconfig | 2 +-
arch/arm/boot/dts/armada-370-xp.dtsi | 5 +-
arch/arm/configs/mvebu_defconfig | 1 -
arch/arm/mach-mvebu/irq-armada-370-xp.c | 18 ++-
drivers/clocksource/time-armada-370-xp.c | 150 +++++++++++++++-----
7 files changed, 144 insertions(+), 59 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
--
1.7.9.5
^ permalink raw reply
* [PATCH] ARM: tegra: DTS: harmony: enable keyboard
From: Stephen Warren @ 2013-01-21 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790245-21724-1-git-send-email-ldewangan@nvidia.com>
On 01/21/2013 10:44 AM, Laxman Dewangan wrote:
> Enable Tegra based keyboard interfacing for keys and provide
> all key mapping through DTS file.
Applied to Tegra's for-3.9/dt branch.
^ permalink raw reply
* [PATCH 1/2] net: fec: refactor dt probing
From: Baruch Siach @ 2013-01-21 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358757475-21035-2-git-send-email-s.hauer@pengutronix.de>
Hi Sascha,
On Mon, Jan 21, 2013 at 09:37:54AM +0100, Sascha Hauer wrote:
> For devicetree parsing only the fec_get_phy_mode_dt() is
> available. Rename it to fec_probe_dt() to be able to add more devicetree
> parsing to it.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
[...]
> -static int fec_get_phy_mode_dt(struct platform_device *pdev)
> +static int fec_probe_dt(struct fec_enet_private *fep)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = fep->pdev->dev.of_node;
>
> - if (np)
> - return of_get_phy_mode(np);
> + if (!np)
> + return -ENODEV;
> +
> + fep->phy_interface = of_get_phy_mode(np);
>
> return -ENODEV;
Maybe return fep->phy_interface?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 3/7] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC)
From: Matt Sealey @ 2013-01-21 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358761930.2522.54.camel@pizza.hi.pengutronix.de>
On Mon, Jan 21, 2013 at 3:52 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi Matt,
>
> thank you for your comments.
>
> Am Freitag, den 18.01.2013, 13:57 -0600 schrieb Matt Sealey:
>> On Wed, Jan 16, 2013 at 10:13 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
>>
>> +
>> +static int imx_src_reset(unsigned long sw_reset_idx)
>> +{
>>
>> Having a name like imx_src_reset seems needlessly generic and
>> confusing. Surely we are performing a reset on an SoC unit and not
>> having the SRC itself reset, even if it is clearer when we look at the
>> argument?
>
> imx_src_reset_module, then? Also, I'll add the struct
> reset_controller_dev pointer as an argument next time:
>
> static int imx_src_reset_module(struct reset_controller_dev *rcdev,
> unsigned long sw_reset_idx)
Yes, sure.
> Yes, maybe the module reset part of the SRC should be implemented as a
> proper device driver in drivers/reset. Then we could use the interrupt
> functionality and WARN_ON(timeout), as you suggest.
That would be ideal. Maybe Shawn or Fabio can bug a hardware guy to
shed some light on what a reasonable timeout might actually be for a
module to cause such a warning. I think it should definitely cause
one.. as I said, I was using 5 seconds, you used 1 second, I don't
think a shorter delay would be unreasonable, but maybe it could take
up to 10 seconds, or maybe I am wrong - maybe it is in fact impossible
in hardware for a reset to "fail" at least visibly because the
interrupt will always fire making the warning a never-traveled path.
It is certainly not something that would be documented, so without a
view of the RTL logic here, we wouldn't know.
Shawn, Fabio?
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH] ARM: tegra: DTS: harmony: enable keyboard
From: Laxman Dewangan @ 2013-01-21 17:44 UTC (permalink / raw)
To: linux-arm-kernel
Enable Tegra based keyboard interfacing for keys and provide
all key mapping through DTS file.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Stephen,
Request you to give a try on this patch? The patch is generated based on seaboard
patch and downstream key mapping. I am expecting that it should work.
Sorry for troubling you again.
If this works then we are completely done with the KBC.
arch/arm/boot/dts/tegra20-harmony.dts | 117 +++++++++++++++++++++++++++++++++
1 files changed, 117 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index b506de9..54295e3 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -448,6 +448,123 @@
bus-width = <8>;
};
+ kbc {
+ status = "okay";
+ nvidia,debounce-delay-ms = <2>;
+ nvidia,repeat-delay-ms = <160>;
+ nvidia,kbc-row-pins = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>;
+ nvidia,kbc-col-pins = <16 17 18 19 20 21 22 23>;
+ linux,keymap = <0x00020011 /* KEY_W */
+ 0x0003001F /* KEY_S */
+ 0x0004001E /* KEY_A */
+ 0x0005002C /* KEY_Z */
+ 0x000701D0 /* KEY_FN */
+ 0x0107008B /* KEY_MENU */
+ 0x02060038 /* KEY_LEFTALT */
+ 0x02070064 /* KEY_RIGHTALT */
+ 0x03000006 /* KEY_5 */
+ 0x03010005 /* KEY_4 */
+ 0x03020013 /* KEY_R */
+ 0x03030012 /* KEY_E */
+ 0x03040021 /* KEY_F */
+ 0x03050020 /* KEY_D */
+ 0x0306002D /* KEY_X */
+ 0x04000008 /* KEY_7 */
+ 0x04010007 /* KEY_6 */
+ 0x04020014 /* KEY_T */
+ 0x04030023 /* KEY_H */
+ 0x04040022 /* KEY_G */
+ 0x0405002F /* KEY_V */
+ 0x0406002E /* KEY_C */
+ 0x04070039 /* KEY_SPACE */
+ 0x0500000A /* KEY_9 */
+ 0x05010009 /* KEY_8 */
+ 0x05020016 /* KEY_U */
+ 0x05030015 /* KEY_Y */
+ 0x05040024 /* KEY_J */
+ 0x05050031 /* KEY_N */
+ 0x05060030 /* KEY_B */
+ 0x0507002B /* KEY_BACKSLASH */
+ 0x0600000C /* KEY_MINUS */
+ 0x0601000B /* KEY_0 */
+ 0x06020018 /* KEY_O */
+ 0x06030017 /* KEY_I */
+ 0x06040026 /* KEY_L */
+ 0x06050025 /* KEY_K */
+ 0x06060033 /* KEY_COMMA */
+ 0x06070032 /* KEY_M */
+ 0x0701000D /* KEY_EQUAL */
+ 0x0702001B /* KEY_RIGHTBRACE */
+ 0x0703001C /* KEY_ENTER */
+ 0x0707008B /* KEY_MENU */
+ 0x0804002A /* KEY_LEFTSHIFT */
+ 0x08050036 /* KEY_RIGHTSHIFT */
+ 0x0905001D /* KEY_LEFTCTRL */
+ 0x09070061 /* KEY_RIGHTCTRL */
+ 0x0B00001A /* KEY_LEFTBRACE */
+ 0x0B010019 /* KEY_P */
+ 0x0B020028 /* KEY_APOSTROPHE */
+ 0x0B030027 /* KEY_SEMICOLON */
+ 0x0B040035 /* KEY_SLASH */
+ 0x0B050034 /* KEY_DOT */
+ 0x0C000044 /* KEY_F10 */
+ 0x0C010043 /* KEY_F9 */
+ 0x0C02000E /* KEY_BACKSPACE */
+ 0x0C030004 /* KEY_3 */
+ 0x0C040003 /* KEY_2 */
+ 0x0C050067 /* KEY_UP */
+ 0x0C0600D2 /* KEY_PRINT */
+ 0x0C070077 /* KEY_PAUSE */
+ 0x0D00006E /* KEY_INSERT */
+ 0x0D01006F /* KEY_DELETE */
+ 0x0D030068 /* KEY_PAGEUP */
+ 0x0D04006D /* KEY_PAGEDOWN */
+ 0x0D05006A /* KEY_RIGHT */
+ 0x0D06006C /* KEY_DOWN */
+ 0x0D070069 /* KEY_LEFT */
+ 0x0E000057 /* KEY_F11 */
+ 0x0E010058 /* KEY_F12 */
+ 0x0E020042 /* KEY_F8 */
+ 0x0E030010 /* KEY_Q */
+ 0x0E04003E /* KEY_F4 */
+ 0x0E05003D /* KEY_F3 */
+ 0x0E060002 /* KEY_1 */
+ 0x0E070041 /* KEY_F7 */
+ 0x0F000001 /* KEY_ESC */
+ 0x0F010029 /* KEY_GRAVE */
+ 0x0F02003F /* KEY_F5 */
+ 0x0F03000F /* KEY_TAB */
+ 0x0F04003B /* KEY_F1 */
+ 0x0F05003C /* KEY_F2 */
+ 0x0F06003A /* KEY_CAPSLOCK */
+ 0x0F070040 /* KEY_F6 */
+ 0x14000047 /* KEY_KP7 */
+ 0x15000049 /* KEY_KP9 */
+ 0x15010048 /* KEY_KP8 */
+ 0x1502004B /* KEY_KP4 */
+ 0x1504004F /* KEY_KP1 */
+ 0x1601004E /* KEY_KPSLASH */
+ 0x1602004D /* KEY_KP6 */
+ 0x1603004C /* KEY_KP5 */
+ 0x16040051 /* KEY_KP3 */
+ 0x16050050 /* KEY_KP2 */
+ 0x16070052 /* KEY_KP0 */
+ 0x1B010037 /* KEY_KPASTERISK */
+ 0x1B03004A /* KEY_KPMINUS */
+ 0x1B04004E /* KEY_KPPLUS */
+ 0x1B050053 /* KEY_KPDOT */
+ 0x1C050073 /* KEY_VOLUMEUP */
+ 0x1D030066 /* KEY_HOME */
+ 0x1D04006B /* KEY_END */
+ 0x1D0500E1 /* KEY_BRIGHTNESSUP */
+ 0x1D060072 /* KEY_VOLUMEDOWN */
+ 0x1D0700E0 /* KEY_BRIGHTNESSDOWN */
+ 0x1E000045 /* KEY_NUMLOCK */
+ 0x1E010046 /* KEY_SCROLLLOCK */
+ 0x1E020071 /* KEY_MUTE */
+ 0x1F0400D6>; /* KEY_QUESTION */
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
--
1.7.1.1
^ permalink raw reply related
* [kvmarm] [PATCH v6 14/15] KVM: ARM: Power State Coordination Interface implementation
From: Marc Zyngier @ 2013-01-21 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98q+6wd6YmK--Xb7=rKm7AyHE94pBnC_XsP+6UmuP31CziQ@mail.gmail.com>
On Mon, 21 Jan 2013 09:50:18 -0500, Christoffer Dall
<c.dall@virtualopensystems.com> wrote:
> On Mon, Jan 21, 2013 at 5:04 AM, Marc Zyngier <marc.zyngier@arm.com>
wrote:
>> On Sun, 20 Jan 2013 18:35:51 -0500, Christoffer Dall
>> <c.dall@virtualopensystems.com> wrote:
>>> On Thu, Jan 17, 2013 at 10:55 AM, Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>>> On 16/01/13 17:59, Christoffer Dall wrote:
>>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>>
>>>>> Implement the PSCI specification (ARM DEN 0022A) to control
>>>>> virtual CPUs being "powered" on or off.
>>>>>
>>>>> PSCI/KVM is detected using the KVM_CAP_ARM_PSCI capability.
>>>>>
>>>>> A virtual CPU can now be initialized in a "powered off" state,
>>>>> using the KVM_ARM_VCPU_POWER_OFF feature flag.
>>>>>
>>>>> The guest can use either SMC or HVC to execute a PSCI function.
>>>>>
>>>>> Reviewed-by: Will Deacon <will.deacon@arm.com>
>>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>>>>
>>>> A few bits went wrong when you reworked this patch. See below.
>>
>> [...]
>>
>>>>> @@ -443,13 +445,17 @@ static int handle_hvc(struct kvm_vcpu *vcpu,
>>>>> struct kvm_run *run)
>>>>> trace_kvm_hvc(*vcpu_pc(vcpu), *vcpu_reg(vcpu, 0),
>>>>> vcpu->arch.hsr & HSR_HVC_IMM_MASK);
>>>>>
>>>>> + if (kvm_psci_call(vcpu))
>>>>> + return 1;
>>>>> +
>>>>> return 1;
>>>>
>>>> No undef injection if there is no PSCI match?
>>
>> You haven't addressed this issue in you patch.
>>
> right, well, it's actually quite nice not having it give you an
> undefined exception when it logs the trace event. The psci protocol
> relies on a confirmation in form of a return value anyhow, so it was
> actually on purpose to remove it, so you can do things like easily
> measure exit times or probe places in the guest.
If that's for tracing purpose, why don't you allocate another hypercall?
Returning to the guest without signalling that nothing was executed seems
very wrong to me.
M.
--
Fast, cheap, reliable. Pick two.
^ permalink raw reply
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
From: Arnd Bergmann @ 2013-01-21 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD7A5F.9020702@ti.com>
On Monday 21 January 2013, Rob Clark wrote:
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> think the correct fix would be to remove the dependency in OMAP2_DSS. I
> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> correct solution.
At least it says so in drivers/video/omap2/Kconfig, which contains
if ARCH_OMAP2PLUS
source drivers/video/omap2/dss/Kconfig
endif
We can probably change this, but until we do, we should not select
OMAP2_DSS from something that doesn't also depend on ARCH_OMAP2PLUS.
> > drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> > drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> > drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
> > drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
> > drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
> > drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in
>
>
> This was an unrelated build break which should be fixed in latest master
> after 'staging: drm/omap: use omapdss low level API'
Ok, it seems the message is stale then, I created the patch some time ago, but
only today wrote rest of the explanation for the changeset text.
With all the other patches from my series applied, allyesconfig still gives me
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared
because that symbol is only defined when OMAP2_DSS is enabled rather than
selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
to work as well, but that seems a little intrusive for v3.8, because it would
let a lot of people build that code that have no use for it.
Arnd
^ permalink raw reply
* [PATCH] mc13892-regulator: correct/refine handling of the SWxHI bit
From: Matt Sealey @ 2013-01-21 17:38 UTC (permalink / raw)
To: linux-arm-kernel
MC13892 PMIC supports a "HI" bit for 3 of it's 4 buck switcher outputs,
which enables a higher set of voltage ranges.
Despite a comment in the code ('sw regulators need special care due to the
"hi" bit'), it actually does not take special care since it does not modify
it's use of the selector table index when this bit is set, giving us very
odd behavior when setting a high voltage on supported switchers or listing
current voltages. Net effect is in best case the kernel and sysfs report
lower voltages than are actually set in hardware (1300mV instead of 1800mV
for example) and in the worst case setting a voltage (e.g. 1800mV) will cause
an undervoltage condition (e.g. 1300mV).
Correct the behavior, taking into account SW1 doesn't support the HI bit,
and as such we need to ignore it.
While we are modifying these functions, fix and optimize the following;
* set_voltage_sel callback was using .reg instead of .vsel_reg - since
they were set to the same value it actually didn't break anything but
it would be semantically incorrect to use .reg in this case. We now use
.vsel_reg and be consistent.
* vsel_shift is always 0 for every SWx regulator, and constantly shifting
and masking off the bottom few bits is time consuming and makes the
code very hard to read - optimize this out.
* get_voltage_sel uses the variable "val" and set_voltage_sel uses the
variable "selector" (and reg_value). Introduce the variable "selector"
to get_voltage_sel such that it makes more sense and allow some leaner
code in light of the modifications in this patch. Add better exposure
to the debug print so the register value AND the selector are printed as
this will adequately show the HI bit in the register.
* correct a comment in probe which is doing a version check. Magic
values are awful but for once instance, a comment does just as
good a job as something symbolic.
Signed-off-by: Matt Sealey <matt@genesi-usa.com>
Tested-by: Steev Klimaszewski <steev@genesi-usa.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/regulator/mc13892-regulator.c | 72 +++++++++++++++++++++++++--------
1 file changed, 56 insertions(+), 16 deletions(-)
diff --git a/drivers/regulator/mc13892-regulator.c b/drivers/regulator/mc13892-regulator.c
index 0d84b1f..169457b 100644
--- a/drivers/regulator/mc13892-regulator.c
+++ b/drivers/regulator/mc13892-regulator.c
@@ -164,6 +164,14 @@ static const unsigned int mc13892_sw1[] = {
1350000, 1375000
};
+/*
+ * Note: this table is used to derive SWxVSEL by index into
+ * the array. Offset the values by the index of 1100000uV
+ * to get the actual register value for that voltage selector
+ * if the HI bit is to be set as well.
+ */
+#define MC13892_SWxHI_SEL_OFFSET 20
+
static const unsigned int mc13892_sw[] = {
600000, 625000, 650000, 675000, 700000, 725000,
750000, 775000, 800000, 825000, 850000, 875000,
@@ -239,7 +247,6 @@ static const unsigned int mc13892_pwgtdrv[] = {
};
static struct regulator_ops mc13892_gpo_regulator_ops;
-/* sw regulators need special care due to the "hi bit" */
static struct regulator_ops mc13892_sw_regulator_ops;
@@ -396,7 +403,7 @@ static int mc13892_sw_regulator_get_voltage_sel(struct regulator_dev *rdev)
{
struct mc13xxx_regulator_priv *priv = rdev_get_drvdata(rdev);
int ret, id = rdev_get_id(rdev);
- unsigned int val;
+ unsigned int val, selector;
dev_dbg(rdev_get_dev(rdev), "%s id: %d\n", __func__, id);
@@ -407,12 +414,28 @@ static int mc13892_sw_regulator_get_voltage_sel(struct regulator_dev *rdev)
if (ret)
return ret;
- val = (val & mc13892_regulators[id].vsel_mask)
- >> mc13892_regulators[id].vsel_shift;
+ /*
+ * Figure out if the HI bit is set inside the switcher mode register
+ * since this means the selector value we return is at a different
+ * offset into the selector table.
+ *
+ * According to the MC13892 documentation note 59 (Table 47) the SW1
+ * buck switcher does not support output range programming therefore
+ * the HI bit must always remain 0. So do not do anything strange if
+ * our register is MC13892_SWITCHERS0.
+ */
+
+ selector = val & mc13892_regulators[id].vsel_mask;
+
+ if ((mc13892_regulators[id].vsel_reg != MC13892_SWITCHERS0) &&
+ (val & MC13892_SWITCHERS0_SWxHI)) {
+ selector += MC13892_SWxHI_SEL_OFFSET;
+ }
- dev_dbg(rdev_get_dev(rdev), "%s id: %d val: %d\n", __func__, id, val);
+ dev_dbg(rdev_get_dev(rdev), "%s id: %d val: 0x%08x selector: %d\n",
+ __func__, id, val, selector);
- return val;
+ return selector;
}
static int mc13892_sw_regulator_set_voltage_sel(struct regulator_dev *rdev,
@@ -425,18 +448,35 @@ static int mc13892_sw_regulator_set_voltage_sel(struct regulator_dev *rdev,
volt = rdev->desc->volt_table[selector];
mask = mc13892_regulators[id].vsel_mask;
- reg_value = selector << mc13892_regulators[id].vsel_shift;
-
- if (volt > 1375000) {
- mask |= MC13892_SWITCHERS0_SWxHI;
- reg_value |= MC13892_SWITCHERS0_SWxHI;
- } else if (volt < 1100000) {
- mask |= MC13892_SWITCHERS0_SWxHI;
- reg_value &= ~MC13892_SWITCHERS0_SWxHI;
+ reg_value = selector;
+
+ /*
+ * Don't mess with the HI bit or support HI voltage offsets for SW1.
+ *
+ * Since the get_voltage_sel callback has given a fudged value for
+ * the selector offset, we need to back out that offset if HI is
+ * to be set so we write the correct value to the register.
+ *
+ * The HI bit addition and selector offset handling COULD be more
+ * complicated by shifting and masking off the voltage selector part
+ * of the register then logical OR it back in, but since the selector
+ * is@bits 4:0 there is very little point. This makes the whole
+ * thing more readable and we do far less work.
+ */
+
+ if (mc13892_regulators[id].vsel_reg != MC13892_SWITCHERS0) {
+ if (volt > 1375000) {
+ reg_value -= MC13892_SWxHI_SEL_OFFSET;
+ reg_value |= MC13892_SWITCHERS0_SWxHI;
+ mask |= MC13892_SWITCHERS0_SWxHI;
+ } else if (volt < 1100000) {
+ reg_value &= ~MC13892_SWITCHERS0_SWxHI;
+ mask |= MC13892_SWITCHERS0_SWxHI;
+ }
}
mc13xxx_lock(priv->mc13xxx);
- ret = mc13xxx_reg_rmw(priv->mc13xxx, mc13892_regulators[id].reg, mask,
+ ret = mc13xxx_reg_rmw(priv->mc13xxx, mc13892_regulators[id].vsel_reg, mask,
reg_value);
mc13xxx_unlock(priv->mc13xxx);
@@ -520,7 +560,7 @@ static int mc13892_regulator_probe(struct platform_device *pdev)
if (ret)
goto err_unlock;
- /* enable switch auto mode */
+ /* enable switch auto mode (on 2.0A silicon only) */
if ((val & 0x0000FFFF) == 0x45d0) {
ret = mc13xxx_reg_rmw(mc13892, MC13892_SWITCHERS4,
MC13892_SWITCHERS4_SW1MODE_M |
--
1.7.10.4
^ permalink raw reply related
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
From: Rob Clark @ 2013-01-21 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD7A5F.9020702@ti.com>
On 01/21/2013 11:26 AM, Rob Clark wrote:
> On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
>> The omapdrm driver is incorrectly flagged to allow building
>> on non-omap platforms, when ARCH_MULTIPLATFORM is set.
>>
>> This does not work, because it unconditionally selects
>> the OMAP2_DSS symbol that only works on OMAP.
>> The problem was introduced in 5e3b087499 "staging:
>> drm/omap: add support for ARCH_MULTIPLATFORM", which this
>> patch partly reverts.
>
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
> think the correct fix would be to remove the dependency in OMAP2_DSS.
> I don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> correct solution.
hmm, yes, it does appear that OMAP2_DSS depends on ARCH_OMAP2PLUS.. let
me have a quick look at this, fixing omapdss would be a better solution..
BR,
-R
>
>
>> Without this patch, building allyesconfig results in:
>>
>> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has
>> unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
>> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has
>> unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
>> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
>> drivers/video/omap2/dss/dss.c:572:20: error:
>> 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this
>> function)
>> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared
>> identifier is reported only once for each function it appears in
>> drivers/staging/omapdrm/omap_connector.c: In function
>> 'omap_connector_dpms':
>> drivers/staging/omapdrm/omap_connector.c:116:8: error:
>> 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
>> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared
>> identifier is reported only once for each function it appears in
>
>
> This was an unrelated build break which should be fixed in latest
> master after 'staging: drm/omap: use omapdss low level API'
>
> BR,
> -R
>
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Rob Clark <rob@ti.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>> drivers/staging/omapdrm/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/omapdrm/Kconfig
>> b/drivers/staging/omapdrm/Kconfig
>> index b724a41..81a7cba 100644
>> --- a/drivers/staging/omapdrm/Kconfig
>> +++ b/drivers/staging/omapdrm/Kconfig
>> @@ -2,7 +2,7 @@
>> config DRM_OMAP
>> tristate "OMAP DRM"
>> depends on DRM && !CONFIG_FB_OMAP2
>> - depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
>> + depends on ARCH_OMAP2PLUS
>> select DRM_KMS_HELPER
>> select OMAP2_DSS
>> select FB_SYS_FILLRECT
>
^ permalink raw reply
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
From: Rob Clark @ 2013-01-21 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-16-git-send-email-arnd@arndb.de>
On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
> The omapdrm driver is incorrectly flagged to allow building
> on non-omap platforms, when ARCH_MULTIPLATFORM is set.
>
> This does not work, because it unconditionally selects
> the OMAP2_DSS symbol that only works on OMAP.
> The problem was introduced in 5e3b087499 "staging:
> drm/omap: add support for ARCH_MULTIPLATFORM", which this
> patch partly reverts.
Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
think the correct fix would be to remove the dependency in OMAP2_DSS. I
don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
correct solution.
> Without this patch, building allyesconfig results in:
>
> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
> drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
> drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in
This was an unrelated build break which should be fixed in latest master
after 'staging: drm/omap: use omapdss low level API'
BR,
-R
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Clark <rob@ti.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/staging/omapdrm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/Kconfig b/drivers/staging/omapdrm/Kconfig
> index b724a41..81a7cba 100644
> --- a/drivers/staging/omapdrm/Kconfig
> +++ b/drivers/staging/omapdrm/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_OMAP
> tristate "OMAP DRM"
> depends on DRM && !CONFIG_FB_OMAP2
> - depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
> + depends on ARCH_OMAP2PLUS
> select DRM_KMS_HELPER
> select OMAP2_DSS
> select FB_SYS_FILLRECT
^ permalink raw reply
* [PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}
From: Pawel Moll @ 2013-01-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-11-git-send-email-arnd@arndb.de>
On Mon, 2013-01-21 at 17:16 +0000, Arnd Bergmann wrote:
> The newly introduced vexpress mfd driver in linux-3.8-rc
> provides access to configuration functions, but the
> interfaces are not exported to modules, which breaks
> when the vexpress regulator driver tries to use them.
>
> Without this patch, building allmodconfig results in:
>
> ERROR: "__vexpress_config_func_get" [drivers/regulator/vexpress.ko] undefined!
> ERROR: "vexpress_config_func_put" [drivers/regulator/vexpress.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
You are the third person noticing that. My bad :-(
In fact some other ones, like the *_bridge_register could do with
exporting as well... I'll get all the patches merged in my fixes branch
and send a pull request this week.
Thanks!
Pawe?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox