* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Hanjun Guo @ 2016-09-20 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920104348.GP25086@rric.localdomain>
+Cc Yisheng,
On 09/20/2016 06:43 PM, Robert Richter wrote:
> David,
>
> On 19.09.16 11:49:30, David Daney wrote:
>> Fix by supplying a cpu_to_node() implementation that returns correct
>> node mappings.
>
>> +int cpu_to_node(int cpu)
>> +{
>> + int nid;
>> +
>> + /*
>> + * Return 0 for unknown mapping so that we report something
>> + * sensible if firmware doesn't supply a proper mapping.
>> + */
>> + if (cpu < 0 || cpu >= NR_CPUS)
>> + return 0;
>> +
>> + nid = cpu_to_node_map[cpu];
>> + if (nid == NUMA_NO_NODE)
>> + nid = 0;
>> + return nid;
>> +}
>> +EXPORT_SYMBOL(cpu_to_node);
>
> this implementation fixes the per-cpu workqueue initialization, but I
> don't think a cpu_to_node() implementation private to arm64 is the
> proper solution.
>
> Apart from better using generic code, the cpu_to_node() function is
> called in the kernel's fast path. I think your implementation is too
> expensive and also does not consider per-cpu data access for the
> lookup as the generic code does. Secondly, numa_off is not considered
> at all.
>
> Instead we need to make sure the set_*numa_node() functions are called
> earlier before secondary cpus are booted. My suggested change for that
> is this:
>
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index d93d43352504..952365c2f100 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -204,7 +204,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> static void smp_store_cpu_info(unsigned int cpuid)
> {
> store_cpu_topology(cpuid);
> - numa_store_cpu_info(cpuid);
> }
>
> /*
> @@ -719,6 +718,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> continue;
>
> set_cpu_present(cpu, true);
> + numa_store_cpu_info(cpu);
> }
> }
We tried a similar approach which add numa_store_cpu_info() in
early_map_cpu_to_node(), and remove it from smp_store_cpu_info,
but didn't work for us, we will try your approach to see if works.
>
>
> I have tested the code and it properly sets up all per-cpu workqueues.
>
> Unfortunately either your nor my code does fix the BUG_ON() I see with
> the numa kernel:
>
> kernel BUG at mm/page_alloc.c:1848!
>
> See below for the core dump. It looks like this happens due to moving
> a mem block where first and last page are mapped to different numa
> nodes, thus, triggering the BUG_ON().
Didn't triggered it on our NUMA hardware, could you provide your
config then we can have a try?
Thanks
Hanjun
^ permalink raw reply
* [PATCH] irqchip, gicv3: Fix out-of-range cpumask access reported by cpumask_check()
From: Robert Richter @ 2016-09-20 11:34 UTC (permalink / raw)
To: linux-arm-kernel
Booting a kernel with DEBUG_PER_CPU_MAPS enabled triggers the follwing
warning:
WARNING: CPU: 1 PID: 0 at ./include/linux/cpumask.h:121 gic_raise_softirq+0x298/0x308
Reason for this is the code in for_each_cpu() that modifies cpu in
gic_compute_target_list() which may cause cpu set to nr_cpumask_bits
and cpumask_check() (cpumask_next() of for_each_cpu()) throwing the
warning.
Change the code to avoid out-of-range access that stops the warning.
Note: Though cpumask_check() fails, current for_each_cpu()
implementation is save to use cpu out of range. Also, code in
gic_raise_softirq() might be reworked at all in a way that a single
each-cpu loop is used by squashing it with gic_compute_target_list().
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/irqchip/irq-gic-v3.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index ede5672ab34d..ed46b906cf0a 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -615,6 +615,8 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
tlist = gic_compute_target_list(&cpu, mask, cluster_id);
gic_send_sgi(cluster_id, tlist, irq);
+ if (cpu >= nr_cpu_ids)
+ break;
}
/* Force the above writes to ICC_SGI1R_EL1 to be executed */
--
2.7.0.rc3
^ permalink raw reply related
* Tegra baseline test results for v4.8-rc7
From: Jon Hunter @ 2016-09-20 11:37 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.8-rc7.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.8-rc7/20160919073102/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.8-rc6 (9395452b4aab7bc2475ef8935b4a4fb99d778d70)):
text data bss total kernel
+564 0 0 +564 defconfig
+12679 +4288 0 +16967 multi_v7_defconfig
+208 0 0 +208 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.8-rc6 (9395452b4aab7bc2475ef8935b4a4fb99d778d70))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* [PATCH] irqchip, gicv3: Fix out-of-range cpumask access reported by cpumask_check()
From: Mark Rutland @ 2016-09-20 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474371259-18783-1-git-send-email-rrichter@cavium.com>
On Tue, Sep 20, 2016 at 01:34:19PM +0200, Robert Richter wrote:
> Booting a kernel with DEBUG_PER_CPU_MAPS enabled triggers the follwing
> warning:
>
> WARNING: CPU: 1 PID: 0 at ./include/linux/cpumask.h:121 gic_raise_softirq+0x298/0x308
James posted a patch for this [1], which we were hoping Thomas would
pick up [2].
Does that patch work for you?
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/458087.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/458094.html
> Reason for this is the code in for_each_cpu() that modifies cpu in
> gic_compute_target_list() which may cause cpu set to nr_cpumask_bits
> and cpumask_check() (cpumask_next() of for_each_cpu()) throwing the
> warning.
>
> Change the code to avoid out-of-range access that stops the warning.
>
> Note: Though cpumask_check() fails, current for_each_cpu()
> implementation is save to use cpu out of range. Also, code in
> gic_raise_softirq() might be reworked at all in a way that a single
> each-cpu loop is used by squashing it with gic_compute_target_list().
>
> Signed-off-by: Robert Richter <rrichter@cavium.com>
> ---
> drivers/irqchip/irq-gic-v3.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index ede5672ab34d..ed46b906cf0a 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -615,6 +615,8 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>
> tlist = gic_compute_target_list(&cpu, mask, cluster_id);
> gic_send_sgi(cluster_id, tlist, irq);
> + if (cpu >= nr_cpu_ids)
> + break;
> }
>
> /* Force the above writes to ICC_SGI1R_EL1 to be executed */
> --
> 2.7.0.rc3
>
^ permalink raw reply
* [PATCH -next v2] arm*/efi: efi_init error handling fix
From: Yisheng Xie @ 2016-09-20 11:39 UTC (permalink / raw)
To: linux-arm-kernel
There's an early memmap leak in efi_init error path, fix it.
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
---
drivers/firmware/efi/arm-init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9f8d996..7c2fe57 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -245,8 +245,10 @@ void __init efi_init(void)
"Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
efi.memmap.desc_version);
- if (uefi_init() < 0)
+ if (uefi_init() < 0) {
+ efi_memmap_unmap();
return;
+ }
reserve_regions();
efi_memattr_init();
--
1.7.12.4
^ permalink raw reply related
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-09-20 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918102852.6593-1-contact@paulk.fr>
On 18/09/16 11:28, Paul Kocialkowski wrote:
> Nyan boards only have host USB ports (2 external, 1 internal), there is
> no OTG-enabled connector.
>
> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> ---
> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi b/arch/arm/boot/dts/tegra124-nyan.dtsi
> index 18db797..254b2ee 100644
> --- a/arch/arm/boot/dts/tegra124-nyan.dtsi
> +++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
> @@ -435,7 +435,7 @@
> usb2-0 {
> vbus-supply = <&vdd_usb1_vbus>;
> status = "okay";
> - mode = "otg";
> + mode = "host";
> };
>
> usb2-1 {
Sounds correct to me, so ...
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] irqchip, gicv3: Fix out-of-range cpumask access reported by cpumask_check()
From: Marc Zyngier @ 2016-09-20 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920113858.GA5140@leverpostej>
On 20/09/16 12:39, Mark Rutland wrote:
> On Tue, Sep 20, 2016 at 01:34:19PM +0200, Robert Richter wrote:
>> Booting a kernel with DEBUG_PER_CPU_MAPS enabled triggers the follwing
>> warning:
>>
>> WARNING: CPU: 1 PID: 0 at ./include/linux/cpumask.h:121 gic_raise_softirq+0x298/0x308
>
> James posted a patch for this [1], which we were hoping Thomas would
> pick up [2].
It is already in tip/irq/urgent (727653d).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: dts: Add power button support for igepv5
From: Ladislav Michl @ 2016-09-20 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919230826.aubqvj2km4wg6gz7@atomide.com>
On Mon, Sep 19, 2016 at 04:08:26PM -0700, Tony Lindgren wrote:
> * Pau Pajuel <ppajuel@gmail.com> [160919 01:13]:
> > Hello Tony,
> >
> > 2016-09-14 3:26 GMT+02:00 Javier Martinez Canillas <javier@osg.samsung.com>:
> > > Hello Tony,
> > >
> > > On 09/09/2016 05:07 PM, Tony Lindgren wrote:
> > >> Add power button support for igepv5.
> > >>
> > >> Cc: Agust? Fontquerni i Gorchs <afontquerni@iseebcn.com>
> > >> Cc: Enric Balletbo Serra <eballetbo@gmail.com>
> > >> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > >> Cc: Pau Pajuel <ppajuel@gmail.com>
> > >> Signed-off-by: Tony Lindgren <tony@atomide.com>
> > >> ---
> > >
> > > I don't have a schematics for this board, but the patch looks good to me.
> > Patch has an errata. Power button is GPIO_ACTIVE_LOW instead GPIO_ACTIVE_HIGH.
>
> Oops sorry about that, here's an incremental fix.
And here's another nitpick ;-)
8< -----------------------
>From 209f676512b5265ab4e9b4efa5a44c281ec2fc71 Mon Sep 17 00:00:00 2001
From: Ladislav Michl <ladis@linux-mips.org>
Date: Tue, 20 Sep 2016 14:09:03 +0200
Subject: [PATCH 2/2] ARM: omap5-igep0050.dts: Use tabs for indentation
Cc: Agust? Fontquerni i Gorchs <afontquerni@iseebcn.com>
Cc: Enric Balletbo Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Pau Pajuel <ppajuel@gmail.com>
Fixes: b118c6a6ffa1 ("ARM: dts: Add power button support for igepv5")
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
arch/arm/boot/dts/omap5-igep0050.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-igep0050.dts b/arch/arm/boot/dts/omap5-igep0050.dts
index 139c8f7..44be08a 100644
--- a/arch/arm/boot/dts/omap5-igep0050.dts
+++ b/arch/arm/boot/dts/omap5-igep0050.dts
@@ -20,7 +20,7 @@
};
gpio_keys {
- compatible = "gpio-keys";
+ compatible = "gpio-keys";
pinctrl-0 = <&power_button_pin>;
pinctrl-names = "default";
--
2.1.4
^ permalink raw reply related
* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Alexander Graf @ 2016-09-20 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E10F37.3030002@arm.com>
On 09/20/2016 12:28 PM, Marc Zyngier wrote:
> On 20/09/16 11:05, Alexander Graf wrote:
>> On 09/20/2016 11:39 AM, Marc Zyngier wrote:
>>> On 20/09/16 10:26, Alexander Graf wrote:
>>>> On 20.09.16 11:21, Marc Zyngier wrote:
>>>>> On 19/09/16 18:39, Alexander Graf wrote:
>>>>>> On 19.09.16 16:48, Marc Zyngier wrote:
>>>>>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>>>>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>>>>>>> handle them all using hardware acceleration through the vgic or we can emulate
>>>>>>>> a gic in user space and only drive CPU IRQ pins from there.
>>>>>>>>
>>>>>>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>>>>>>> about timer events that may result in interrupt line state changes, so we
>>>>>>>> lose out on timer events if we run with user space gic emulation.
>>>>>>>>
>>>>>>>> This patch fixes that by routing vtimer expiration events to user space.
>>>>>>>> With this patch I can successfully run edk2 and Linux with user space gic
>>>>>>>> emulation.
>>>>>>>>
>>>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> v1 -> v2:
>>>>>>>>
>>>>>>>> - Add back curly brace that got lost
>>>>>>>>
>>>>>>>> v2 -> v3:
>>>>>>>>
>>>>>>>> - Split into patch set
>>>>>>>>
>>>>>>>> v3 -> v4:
>>>>>>>>
>>>>>>>> - Improve documentation
>>>>>>>> ---
>>>>>>>> Documentation/virtual/kvm/api.txt | 30 ++++++++-
>>>>>>>> arch/arm/include/asm/kvm_host.h | 3 +
>>>>>>>> arch/arm/kvm/arm.c | 22 ++++---
>>>>>>>> arch/arm64/include/asm/kvm_host.h | 3 +
>>>>>>>> include/uapi/linux/kvm.h | 14 +++++
>>>>>>>> virt/kvm/arm/arch_timer.c | 125 +++++++++++++++++++++++++++-----------
>>>>>>>> 6 files changed, 155 insertions(+), 42 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>>>>>>> index 23937e0..1c0bd86 100644
>>>>>>>> --- a/Documentation/virtual/kvm/api.txt
>>>>>>>> +++ b/Documentation/virtual/kvm/api.txt
>>>>>>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>>>>>> /* in */
>>>>>>>> __u8 request_interrupt_window;
>>>>>>>>
>>>>>>>> -Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>> interrupts into the guest. Useful in conjunction with KVM_INTERRUPT.
>>>>>>>>
>>>>>>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>>>>>>> +trigger forever. These lines are available:
>>>>>>>> +
>>>>>>>> + KVM_IRQWINDOW_VTIMER - Masks hw virtual timer irq while in guest
>>>>>>>> +
>>>>>>>> __u8 padding1[7];
>>>>>>>>
>>>>>>>> /* out */
>>>>>>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>>>>>> event/message pages and to enable/disable SynIC messages/events processing
>>>>>>>> in userspace.
>>>>>>>>
>>>>>>>> + /* KVM_EXIT_ARM_TIMER */
>>>>>>>> + struct {
>>>>>>>> + __u8 timesource;
>>>>>>>> + } arm_timer;
>>>>>>>> +
>>>>>>>> +Indicates that a timer triggered that user space needs to handle and
>>>>>>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>>>>>>> +guest to proceed. This only happens for timers that got enabled through
>>>>>>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>>>>>>> +
>>>>>>>> + KVM_ARM_TIMER_VTIMER - virtual cpu timer
>>>>>>>> +
>>>>>>>> /* Fix the size of the union. */
>>>>>>>> char padding[256];
>>>>>>>> };
>>>>>>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>>>>>> accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>>>>>> the guest.
>>>>>>>>
>>>>>>>> +6.11 KVM_CAP_ARM_TIMER
>>>>>>>> +
>>>>>>>> +Architectures: arm, arm64
>>>>>>>> +Target: vcpu
>>>>>>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>>>>>>> +
>>>>>>>> +This capability allows to route per-core timers into user space. When it's
>>>>>>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>>>>>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>>>>>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>>>>>>> +
>>>>>>>> 7. Capabilities that can be enabled on VMs
>>>>>>>> ------------------------------------------
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>>>>>>> index de338d9..77d1f73 100644
>>>>>>>> --- a/arch/arm/include/asm/kvm_host.h
>>>>>>>> +++ b/arch/arm/include/asm/kvm_host.h
>>>>>>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>>>>>>
>>>>>>>> /* Detect first run of a vcpu */
>>>>>>>> bool has_run_once;
>>>>>>>> +
>>>>>>>> + /* User space wants timer notifications */
>>>>>>>> + bool user_space_arm_timers;
>>>>>>> Please move this to the timer structure.
>>>>>> Sure.
>>>>>>
>>>>>>>> };
>>>>>>>>
>>>>>>>> struct kvm_vm_stat {
>>>>>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>>>>>> index c84b6ad..57bdb71 100644
>>>>>>>> --- a/arch/arm/kvm/arm.c
>>>>>>>> +++ b/arch/arm/kvm/arm.c
>>>>>>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>>>>> case KVM_CAP_ARM_PSCI_0_2:
>>>>>>>> case KVM_CAP_READONLY_MEM:
>>>>>>>> case KVM_CAP_MP_STATE:
>>>>>>>> + case KVM_CAP_ARM_TIMER:
>>>>>>>> r = 1;
>>>>>>>> break;
>>>>>>>> case KVM_CAP_COALESCED_MMIO:
>>>>>>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>>>>>> return ret;
>>>>>>>> }
>>>>>>>>
>>>>>>>> - /*
>>>>>>>> - * Enable the arch timers only if we have an in-kernel VGIC
>>>>>>>> - * and it has been properly initialized, since we cannot handle
>>>>>>>> - * interrupts from the virtual timer with a userspace gic.
>>>>>>>> - */
>>>>>>>> - if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>>>>>>> - ret = kvm_timer_enable(vcpu);
>>>>>>>> + ret = kvm_timer_enable(vcpu);
>>>>>>>>
>>>>>>>> return ret;
>>>>>>>> }
>>>>>>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>>>>> run->exit_reason = KVM_EXIT_INTR;
>>>>>>>> }
>>>>>>>>
>>>>>>>> + if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>>>>>> Since this is a very unlikely event (in the grand scheme of things), how
>>>>>>> about making this unlikely()?
>>>>>>>
>>>>>>>> + /* Tell user space about the pending vtimer */
>>>>>>>> + ret = 0;
>>>>>>>> + run->exit_reason = KVM_EXIT_ARM_TIMER;
>>>>>>>> + run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>>>>>>> + }
>>>>>>> More importantly: why does it have to be indirected by a
>>>>>>> make_request/check_request, and not be handled as part of the
>>>>>>> kvm_timer_sync() call? We do update the state there, and you could
>>>>>>> directly find out whether an exit is required.
>>>>>> I can try - it seemed like it could easily become quite racy because we
>>>>>> call kvm_timer_sync_hwstate() at multiple places.
>>>>> It shouldn't. We only do it at exactly two locations (depending whether
>>>>> we've entered the guest or not).
>>>>>
>>>>> Also, take the following scenario:
>>>>> (1) guest programs the timer to expire at time T
>>>>> (2) guest performs an MMIO access which traps
>>>>> (3) during the world switch, the timer expires and we mark the timer
>>>>> interrupt as pending
>>>>> (4) we exit to handle the MMIO, no sign of the timer being pending
>>>>>
>>>>> Is the timer event lost? Or simply delayed? I think this indicates that
>>>>> the timer state should always be signalled to userspace, no matter what
>>>>> the exit reason is.
>>>> That's basically what I'm trying to get running right now, yes. I pushed
>>>> the interrupt pending status field into the kvm_sync_regs struct and
>>>> check it on every exit in user space - to make sure we catch pending
>>>> state changes before mmio reads.
>>>>
>>>> On top of that we also need a force exit event when the state changes,
>>>> in case there's no other event pending. Furthermore we probably want to
>>>> indicate the user space status of the pending bit into the kernel to not
>>>> exit too often.
>>> All you need is to do is to stash the line state in the run structure.
>> That's what I do now, yes. The sync_regs struct is basically an arch
>> specific add-on to the run structure, so we don't modify padding /
>> alignment with the change.
>>
>>> You shouldn't need any other information. And you trigger the exit on
>>> "timer line high + timer line unmasked" in order to inject the
>>> interrupt. Which is basically what the vgic does. It would greatly help
>>> if you adopted a similar behaviour.
>> We also need to know "timer line low + timer line masked", as otherwise
>> we might get spurious interrupts in the guest, no?
> Yes. Though you can't really know about this one, and you'll have to
> wait until the next natural exit to find out. As long as the spurious is
We can provoke a special exit for it, no?
> "spurious in the GIC sense" (hence returning 0x3ff) and not a spurious
> timer interrupt being presented, you're fine.
Imagine
* guest configures timer to fire
* kvm exits to user space because lines mismatch now
* user space sets gic line up, setting vcpu irq line high
* guest runs, handles IRQ, calls EOI with IRQs disabled on the core
* user space handles EOI, but still leaves the vcpu line high
* guest runs, sets cval, enables IRQs on the core
* kvm injects a timer interrupt into the guest
At this point, the pending state from user space is bogus, as the line
really isn't pending anymore. However, when the guest asks the GIC at
that point what interrupt is pending, the line down state will have
populated into user space before the mmio request gets processed. So you
will see a 0x3ff return I guess.
Is that reasonable?
Alex
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Enable GPU node and related supply
From: Jon Hunter @ 2016-09-20 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918141311.17140-1-contact@paulk.fr>
On 18/09/16 15:13, Paul Kocialkowski wrote:
> This enables the GPU node for tegra124 nyan boards, which is required to
> get graphics acceleration with nouveau on these devices.
>
> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> ---
> arch/arm/boot/dts/tegra124-nyan.dtsi | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi b/arch/arm/boot/dts/tegra124-nyan.dtsi
> index dab9509..225ca77 100644
> --- a/arch/arm/boot/dts/tegra124-nyan.dtsi
> +++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
> @@ -42,6 +42,12 @@
> };
> };
>
> + gpu at 0,57000000 {
> + status = "okay";
> +
> + vdd-supply = <&vdd_gpu>;
> + };
> +
> serial at 70006000 {
> /* Debug connector on the bottom of the board near SD card. */
> status = "okay";
> @@ -214,7 +220,7 @@
> regulator-always-on;
> };
>
> - sd6 {
> + vdd_gpu: sd6 {
> regulator-name = "+VDD_GPU_AP";
> regulator-min-microvolt = <650000>;
> regulator-max-microvolt = <1200000>;
>
Looks good to me. I see the following error when booting but looking at the
code appears to be benign. Thierry, Alex, is this normal/okay?
[ 5.715181] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1)
[ 5.720625] nouveau 57000000.gpu: imem: using IOMMU
[ 5.803694] nouveau 57000000.gpu: DRM: VRAM: 0 MiB
[ 5.808501] nouveau 57000000.gpu: DRM: GART: 1048576 MiB
[ 5.816000] nouveau 57000000.gpu: DRM: failed to create ce channel, -22
[ 5.924140] nouveau 57000000.gpu: DRM: MM: using GRCE for buffer copies
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Marc Zyngier @ 2016-09-20 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E12A02.7020907@suse.de>
On 20/09/16 13:22, Alexander Graf wrote:
> On 09/20/2016 12:28 PM, Marc Zyngier wrote:
>> On 20/09/16 11:05, Alexander Graf wrote:
>>> On 09/20/2016 11:39 AM, Marc Zyngier wrote:
>>>> On 20/09/16 10:26, Alexander Graf wrote:
>>>>> On 20.09.16 11:21, Marc Zyngier wrote:
>>>>>> On 19/09/16 18:39, Alexander Graf wrote:
>>>>>>> On 19.09.16 16:48, Marc Zyngier wrote:
>>>>>>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>>>>>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>>>>>>>> handle them all using hardware acceleration through the vgic or we can emulate
>>>>>>>>> a gic in user space and only drive CPU IRQ pins from there.
>>>>>>>>>
>>>>>>>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>>>>>>>> about timer events that may result in interrupt line state changes, so we
>>>>>>>>> lose out on timer events if we run with user space gic emulation.
>>>>>>>>>
>>>>>>>>> This patch fixes that by routing vtimer expiration events to user space.
>>>>>>>>> With this patch I can successfully run edk2 and Linux with user space gic
>>>>>>>>> emulation.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> v1 -> v2:
>>>>>>>>>
>>>>>>>>> - Add back curly brace that got lost
>>>>>>>>>
>>>>>>>>> v2 -> v3:
>>>>>>>>>
>>>>>>>>> - Split into patch set
>>>>>>>>>
>>>>>>>>> v3 -> v4:
>>>>>>>>>
>>>>>>>>> - Improve documentation
>>>>>>>>> ---
>>>>>>>>> Documentation/virtual/kvm/api.txt | 30 ++++++++-
>>>>>>>>> arch/arm/include/asm/kvm_host.h | 3 +
>>>>>>>>> arch/arm/kvm/arm.c | 22 ++++---
>>>>>>>>> arch/arm64/include/asm/kvm_host.h | 3 +
>>>>>>>>> include/uapi/linux/kvm.h | 14 +++++
>>>>>>>>> virt/kvm/arm/arch_timer.c | 125 +++++++++++++++++++++++++++-----------
>>>>>>>>> 6 files changed, 155 insertions(+), 42 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>>>>>>>> index 23937e0..1c0bd86 100644
>>>>>>>>> --- a/Documentation/virtual/kvm/api.txt
>>>>>>>>> +++ b/Documentation/virtual/kvm/api.txt
>>>>>>>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>>>>>>> /* in */
>>>>>>>>> __u8 request_interrupt_window;
>>>>>>>>>
>>>>>>>>> -Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>>> interrupts into the guest. Useful in conjunction with KVM_INTERRUPT.
>>>>>>>>>
>>>>>>>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>>>>>>>> +trigger forever. These lines are available:
>>>>>>>>> +
>>>>>>>>> + KVM_IRQWINDOW_VTIMER - Masks hw virtual timer irq while in guest
>>>>>>>>> +
>>>>>>>>> __u8 padding1[7];
>>>>>>>>>
>>>>>>>>> /* out */
>>>>>>>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>>>>>>> event/message pages and to enable/disable SynIC messages/events processing
>>>>>>>>> in userspace.
>>>>>>>>>
>>>>>>>>> + /* KVM_EXIT_ARM_TIMER */
>>>>>>>>> + struct {
>>>>>>>>> + __u8 timesource;
>>>>>>>>> + } arm_timer;
>>>>>>>>> +
>>>>>>>>> +Indicates that a timer triggered that user space needs to handle and
>>>>>>>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>>>>>>>> +guest to proceed. This only happens for timers that got enabled through
>>>>>>>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>>>>>>>> +
>>>>>>>>> + KVM_ARM_TIMER_VTIMER - virtual cpu timer
>>>>>>>>> +
>>>>>>>>> /* Fix the size of the union. */
>>>>>>>>> char padding[256];
>>>>>>>>> };
>>>>>>>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>>>>>>> accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>>>>>>> the guest.
>>>>>>>>>
>>>>>>>>> +6.11 KVM_CAP_ARM_TIMER
>>>>>>>>> +
>>>>>>>>> +Architectures: arm, arm64
>>>>>>>>> +Target: vcpu
>>>>>>>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>>>>>>>> +
>>>>>>>>> +This capability allows to route per-core timers into user space. When it's
>>>>>>>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>>>>>>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>>>>>>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>>>>>>>> +
>>>>>>>>> 7. Capabilities that can be enabled on VMs
>>>>>>>>> ------------------------------------------
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>>>>>>>> index de338d9..77d1f73 100644
>>>>>>>>> --- a/arch/arm/include/asm/kvm_host.h
>>>>>>>>> +++ b/arch/arm/include/asm/kvm_host.h
>>>>>>>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>>>>>>>
>>>>>>>>> /* Detect first run of a vcpu */
>>>>>>>>> bool has_run_once;
>>>>>>>>> +
>>>>>>>>> + /* User space wants timer notifications */
>>>>>>>>> + bool user_space_arm_timers;
>>>>>>>> Please move this to the timer structure.
>>>>>>> Sure.
>>>>>>>
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> struct kvm_vm_stat {
>>>>>>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>>>>>>> index c84b6ad..57bdb71 100644
>>>>>>>>> --- a/arch/arm/kvm/arm.c
>>>>>>>>> +++ b/arch/arm/kvm/arm.c
>>>>>>>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>>>>>> case KVM_CAP_ARM_PSCI_0_2:
>>>>>>>>> case KVM_CAP_READONLY_MEM:
>>>>>>>>> case KVM_CAP_MP_STATE:
>>>>>>>>> + case KVM_CAP_ARM_TIMER:
>>>>>>>>> r = 1;
>>>>>>>>> break;
>>>>>>>>> case KVM_CAP_COALESCED_MMIO:
>>>>>>>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>>>>>>> return ret;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> - /*
>>>>>>>>> - * Enable the arch timers only if we have an in-kernel VGIC
>>>>>>>>> - * and it has been properly initialized, since we cannot handle
>>>>>>>>> - * interrupts from the virtual timer with a userspace gic.
>>>>>>>>> - */
>>>>>>>>> - if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>>>>>>>> - ret = kvm_timer_enable(vcpu);
>>>>>>>>> + ret = kvm_timer_enable(vcpu);
>>>>>>>>>
>>>>>>>>> return ret;
>>>>>>>>> }
>>>>>>>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>>>>>> run->exit_reason = KVM_EXIT_INTR;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> + if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>>>>>>> Since this is a very unlikely event (in the grand scheme of things), how
>>>>>>>> about making this unlikely()?
>>>>>>>>
>>>>>>>>> + /* Tell user space about the pending vtimer */
>>>>>>>>> + ret = 0;
>>>>>>>>> + run->exit_reason = KVM_EXIT_ARM_TIMER;
>>>>>>>>> + run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>>>>>>>> + }
>>>>>>>> More importantly: why does it have to be indirected by a
>>>>>>>> make_request/check_request, and not be handled as part of the
>>>>>>>> kvm_timer_sync() call? We do update the state there, and you could
>>>>>>>> directly find out whether an exit is required.
>>>>>>> I can try - it seemed like it could easily become quite racy because we
>>>>>>> call kvm_timer_sync_hwstate() at multiple places.
>>>>>> It shouldn't. We only do it at exactly two locations (depending whether
>>>>>> we've entered the guest or not).
>>>>>>
>>>>>> Also, take the following scenario:
>>>>>> (1) guest programs the timer to expire at time T
>>>>>> (2) guest performs an MMIO access which traps
>>>>>> (3) during the world switch, the timer expires and we mark the timer
>>>>>> interrupt as pending
>>>>>> (4) we exit to handle the MMIO, no sign of the timer being pending
>>>>>>
>>>>>> Is the timer event lost? Or simply delayed? I think this indicates that
>>>>>> the timer state should always be signalled to userspace, no matter what
>>>>>> the exit reason is.
>>>>> That's basically what I'm trying to get running right now, yes. I pushed
>>>>> the interrupt pending status field into the kvm_sync_regs struct and
>>>>> check it on every exit in user space - to make sure we catch pending
>>>>> state changes before mmio reads.
>>>>>
>>>>> On top of that we also need a force exit event when the state changes,
>>>>> in case there's no other event pending. Furthermore we probably want to
>>>>> indicate the user space status of the pending bit into the kernel to not
>>>>> exit too often.
>>>> All you need is to do is to stash the line state in the run structure.
>>> That's what I do now, yes. The sync_regs struct is basically an arch
>>> specific add-on to the run structure, so we don't modify padding /
>>> alignment with the change.
>>>
>>>> You shouldn't need any other information. And you trigger the exit on
>>>> "timer line high + timer line unmasked" in order to inject the
>>>> interrupt. Which is basically what the vgic does. It would greatly help
>>>> if you adopted a similar behaviour.
>>> We also need to know "timer line low + timer line masked", as otherwise
>>> we might get spurious interrupts in the guest, no?
>> Yes. Though you can't really know about this one, and you'll have to
>> wait until the next natural exit to find out. As long as the spurious is
>
> We can provoke a special exit for it, no?
How? The guest decides to disable its timer. That doesn't trigger any
exit whatsoever. You'll have to wait until the next exit from the guest
to notice it.
>
>> "spurious in the GIC sense" (hence returning 0x3ff) and not a spurious
>> timer interrupt being presented, you're fine.
>
> Imagine
>
> * guest configures timer to fire
> * kvm exits to user space because lines mismatch now
I suppose you mean timer fired + physical interrupt for the virtual enabled?
> * user space sets gic line up, setting vcpu irq line high
> * guest runs, handles IRQ, calls EOI with IRQs disabled on the core
Same thing: you mean physical interrupt for the virtual timer disabled?
or something else?
> * user space handles EOI, but still leaves the vcpu line high
If there is another pending interrupt, sure. Otherwise, that's a bug.
> * guest runs, sets cval, enables IRQs on the core
What is that interrupt? Please name things, because that's very confusing.
> * kvm injects a timer interrupt into the guest
Why? Has the timer fired?
> At this point, the pending state from user space is bogus, as the line
> really isn't pending anymore. However, when the guest asks the GIC at
> that point what interrupt is pending, the line down state will have
> populated into user space before the mmio request gets processed. So you
> will see a 0x3ff return I guess.
>
> Is that reasonable?
I'm sorry, but you need to put names on things and precisely describe
the various events. because from the above script, I can derive twenty
different scenarios...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode
From: Shawn Guo @ 2016-09-20 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR0401MB1709F91B0C1EB6C80D741E4492F50@VI1PR0401MB1709.eurprd04.prod.outlook.com>
On Sun, Sep 18, 2016 at 03:37:27AM +0000, Po Liu wrote:
> Hi Shawn,
>
>
> > -----Original Message-----
> > From: Shawn Guo [mailto:shawnguo at kernel.org]
> > Sent: Sunday, September 18, 2016 8:52 AM
> > To: Po Liu
> > Cc: linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > linux-kernel at vger.kernel.org; devicetree at vger.kernel.org; Roy Zang; Arnd
> > Bergmann; Marc Zyngier; Stuart Yoder; Leo Li; M.H. Lian; Murali
> > Karicheri; Bjorn Helgaas; Mingkai Hu
> > Subject: Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with none
> > MSI/MSI-X/INTx mode
> >
> > On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
> > > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
> > > When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
> > > maybe there is interrupt line for aer pme etc. Search the interrupt
> > > number in the fdt file. Then fixup the dev->irq with it.
> > >
> > > Signed-off-by: Po Liu <po.liu@nxp.com>
> >
> > Will the new kernel work with existing/old DTB? I'm trying to
> > understand the dependency between driver and DTS changes.
>
> Yes, We've never use name 'intr' before. So we remove it is ok.
> 'aer' is a dts name for researching it's true interrupt number by kernel. This patch is first time to use name 'aer'. So it must be compatible with existing/old DTB.
Does that mean driver and DTS changes can go through separate trees,
i.e. PCI and arm-soc, without introducing regressions on either tree?
Or does the patch series needs to go in as a whole?
Shawn
^ permalink raw reply
* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Alexandre Torgue @ 2016-09-20 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609201150160.6905@nanos>
Thomas,
On 09/20/2016 11:51 AM, Thomas Gleixner wrote:
> On Tue, 20 Sep 2016, Alexandre Torgue wrote:
>>> On 09/14/2016 03:34 PM, Thomas Gleixner wrote:
>>>> Well, you just used some function in some context which is not
>>>> relevant to
>>>> the normal operation. So adding that mask() is just paranoia for no
>>>> value.
>>>
>> A gentle reminder ping...
>> If ".free" callback is not relevant then I 'll remove it from exti domain.
Sorry for discussing about the same thing again (and again) but I just
want to be sure before sending a new version. As you know I have 2
domains: EXTI domain (parent) and stm32-pinctrl-bank domain (child one).
There does it make sens to have ".free" callbacks defined in both domain
(actually if I define one for the child domain I have to define also
".free" callback for parent domain (EXTI) as it is hierarchical) ?
If ".free" have no chance to be called then I will send a new version by
removing .free callbacks (in both domain).
Regards
Alex
>
> I was not talking about the .free callback in general. I was talking about
> the masking. But yes, if the thing is otherwise a NOOP, then you can spare
> it completely.
>
> Thanks,
>
> tglx
>
^ permalink raw reply
* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Thomas Gleixner @ 2016-09-20 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <053a37f4-aa10-46ea-f477-8ae55bb5773f@st.com>
On Tue, 20 Sep 2016, Alexandre Torgue wrote:
> Thomas,
>
> On 09/20/2016 11:51 AM, Thomas Gleixner wrote:
> > On Tue, 20 Sep 2016, Alexandre Torgue wrote:
> > > > On 09/14/2016 03:34 PM, Thomas Gleixner wrote:
> > > > > Well, you just used some function in some context which is not
> > > > > relevant to
> > > > > the normal operation. So adding that mask() is just paranoia for no
> > > > > value.
> > > >
> > > A gentle reminder ping...
> > > If ".free" callback is not relevant then I 'll remove it from exti domain.
>
> Sorry for discussing about the same thing again (and again) but I just want to
> be sure before sending a new version. As you know I have 2 domains: EXTI
> domain (parent) and stm32-pinctrl-bank domain (child one).
>
> There does it make sens to have ".free" callbacks defined in both domain
> (actually if I define one for the child domain I have to define also ".free"
> callback for parent domain (EXTI) as it is hierarchical) ?
> If ".free" have no chance to be called then I will send a new version by
> removing .free callbacks (in both domain).
Free will be called when a interrupt in the child domain is torn down,
i.e. when irq_domain_free_irqs() is called. And it will be called for both
domains like the alloc callback is invoked on both domains via
irq_domain_alloc_irqs().
Thanks,
tglx
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Shawn Guo @ 2016-09-20 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474259324.15220.5.camel@buserror.net>
On Sun, Sep 18, 2016 at 11:28:44PM -0500, Scott Wood wrote:
> On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > >
> > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > >
> > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > > >
> > > > Could you please rebase atop of that?
> > > Well, we should figure out what tree this is going through first. There
> > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > of it is carrying the appropriate acks for me to queue it.
> > Given that mix, I had assumed that this would all go through the arm64
> > tree -- I see that Rob has already acked the binding, and I'm happy to
> > give my ack for the driver once that's in shape.
> >
> > The dts change could go through arm-soc in parallel, I guess. It doesn't
> > look like arm-soc have been Cc'd for that, though.
>
> The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
> did. ?There doesn't appear to be a separate arm-soc mailing list, nor is there
> a request to CC Olof/Arnd. ?I did CC Shawn Guo who has been handling the
> device tree patches for these chips.
This is kind of new feature development, and there is no hard dependency
between driver and DTS changes. In this case, we normally pick up the
DTS patch only after driver part get accepted.
Shawn
^ permalink raw reply
* [PATCH v2 1/1] clk: imx53: Add clocks configuration
From: Shawn Guo @ 2016-09-20 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474281002-18868-1-git-send-email-fabien.lahoudere@collabora.co.uk>
On Mon, Sep 19, 2016 at 12:30:00PM +0200, Fabien Lahoudere wrote:
> From: Kalle Kankare <kalle.kankare@vincit.fi>
>
> Add clocks configuration for CSI, FIRI and IEEE1588.
>
> Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Acked-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* [PATCH 2/2] clk: imx6: initialize GPU clocks
From: Shawn Guo @ 2016-09-20 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474276031.31321.0.camel@pengutronix.de>
On Mon, Sep 19, 2016 at 11:07:11AM +0200, Lucas Stach wrote:
> > > diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
> > > index 64c243173395..751c3e7d5843 100644
> > > --- a/drivers/clk/imx/clk-imx6q.c
> > > +++ b/drivers/clk/imx/clk-imx6q.c
> > > @@ -633,6 +633,24 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > if (IS_ENABLED(CONFIG_PCI_IMX6))
> > > clk_set_parent(clk[IMX6QDL_CLK_LVDS1_SEL], clk[IMX6QDL_CLK_SATA_REF_100M]);
> > >
> > > + /*
> > > + * Initialize the GPU clock muxes, so that the maximum specified clock
> > > + * rates for the respective SoC are not exceeded.
> > > + */
> > > + if (clk_on_imx6dl()) {
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
> > > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
> > > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > > + } else if (clk_on_imx6q()) {
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
> > > + clk[IMX6QDL_CLK_MMDC_CH0_AXI]);
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_SHADER_SEL],
> > > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
> > > + clk[IMX6QDL_CLK_PLL3_USB_OTG]);
> > > + }
> > > +
> >
> > Can we handle these with assigned-clock-parents from device tree?
> >
> No, we want to get rid of the GPU overclocking even with old DTs. DT
> stability rules and all that...
Fair point. For both patches,
Acked-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* [RFC] arm64: Ensure proper addressing for ldnp/stnp
From: bdegraaf at codeaurora.org @ 2016-09-20 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1911e82-e65a-73e4-f878-8e25f609f58b@arm.com>
On 2016-09-20 07:00, Robin Murphy wrote:
> On 19/09/16 19:25, bdegraaf at codeaurora.org wrote:
>> On 2016-09-19 14:01, Robin Murphy wrote:
>>> On 19/09/16 18:36, Brent DeGraaf wrote:
>>>> According to section 6.3.8 of the ARM Programmer's Guide,
>>>> non-temporal
>>>> loads and stores do not verify that address dependency is met
>>>> between a
>>>> load of an address to a register and a subsequent non-temporal load
>>>> or
>>>> store using that address on the executing PE. Therefore, context
>>>> switch
>>>> code and subroutine calls that use non-temporally accessed addresses
>>>> as
>>>> parameters that might depend on a load of an address into an
>>>> argument
>>>> register must ensure that ordering requirements are met by
>>>> introducing
>>>> a barrier prior to the successive non-temporal access. Add
>>>> appropriate
>>>> barriers whereever this specific situation comes into play.
>>>>
>>>> Signed-off-by: Brent DeGraaf <bdegraaf@codeaurora.org>
>>>> ---
>>>> arch/arm64/kernel/entry.S | 1 +
>>>> arch/arm64/lib/copy_page.S | 2 ++
>>>> 2 files changed, 3 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>>> index 441420c..982c4d3 100644
>>>> --- a/arch/arm64/kernel/entry.S
>>>> +++ b/arch/arm64/kernel/entry.S
>>>> @@ -679,6 +679,7 @@ ENTRY(cpu_switch_to)
>>>> ldp x27, x28, [x8], #16
>>>> ldp x29, x9, [x8], #16
>>>> ldr lr, [x8]
>>>> + dmb nshld // Existence of instructions with loose
>>>> load-use
>>>> dependencies (e.g. ldnp/stnp) make this barrier necessary
>>>> mov sp, x9
>>>> and x9, x9, #~(THREAD_SIZE - 1)
>>>> msr sp_el0, x9
>>>> diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
>>>> index 4c1e700..21c6892 100644
>>>> --- a/arch/arm64/lib/copy_page.S
>>>> +++ b/arch/arm64/lib/copy_page.S
>>>> @@ -47,6 +47,8 @@ alternative_endif
>>>> ldp x14, x15, [x1, #96]
>>>> ldp x16, x17, [x1, #112]
>>>>
>>>> + dmb nshld // In case x0 (for stnp) is dependent on a load
>>>
>>> The ARMv8 ARM (B2.7.2 in issue j) says that when an address
>>> dependency
>>> exists between a load and a subsequent LDNP, *other* observers may
>>> observe those accesses in any order. How's that related to an STNP on
>>> the same CPU?
>>>
>>> Robin.
>>>
>>>> +
>>>> mov x18, #(PAGE_SIZE - 128)
>>>> add x1, x1, #128
>>>> 1:
>>>>
>>
>> Yes, I have seen the section in the ARM ARM about this. But the
>> Programmer's Guide goes further, even providing a concrete example:
>>
>> "Non-temporal loads and stores relax the memory ordering
>> requirements...the LDNP instruction might
>> be observed before the preceding LDR instruction, which can result in
>> reading from an unpredictable
>> address in X0.
>>
>> For example:
>> LDR X0, [X3]
>> LDNP X2, X1, [X0]
>> To correct the above, you need an explicit load barrier:
>> LDR X0, [X3]
>> DMB NSHLD
>> LDNP X2, X1, [X0]"
>>
>> Did the ARM ARM leave this out? Or is the Programmer's Guide section
>> incorrect?
>
> If the ARM ARM and the Programmer's Guide don't agree, then the
> Programmer's Guide is wrong (I'll raise a bug against it).
>
> All the ARM ARM says is that in this situation:
>
> P1 P2
> STP x0, x1, [x2] 1: LDR x0, <ptr>
> DMB ISH CBZ x0, 1b
> STR x2, <ptr> LDNP x1, x2, [x0]
>
> P2's address dependency still very much exists from the point of view
> of
> P2's execution, it just may not guarantee order13.2.4 against the DMB
> on P1,
> so P2's LDNP isn't guaranteed to see the data from P1's STP (as opposed
> to how a regular LDP *is*), and may still load older stale data
> instead.
>
> Robin.
>
>>
>> Thanks for your comments,
>> Brent
>>
Thank you Robin. This was concerning to me because the ARM ARM
description
does not explicitly disagree with the Programmer's Guide, it just
doesn't
touch on the PEe ordering. Meanwhile, as you can see from the quote
above,
the Programmer's Guide doesn't talk about PEy, and even includes sample
code
that would only affect PEe ordering (the "nsh" option), leaving PEy
ordering
impacts completely out of the picture, meaning some degree of thought
was
applied toward it.
I went back through older versions of both the ARM ARM last week and the
Guide and the ARM ARM has never mentioned an issue with PEe ordering of
non-temporal accesses, so I am unsure where the Guide could have gotten
its information.
Also, please be aware that this description is in the Programmer's Guide
*twice*, both in section 6.3.8 which I mentioned in the commit text and
is
duplicated in section 13.2.4.
Please keep me posted as to when the Guide will be corrected (or if it
is
discovered to be correct).
Thanks again,
Brent
^ permalink raw reply
* [PATCH] tty: amba-pl011: uart_amba_port is not available with earlycon function
From: Shawn Guo @ 2016-09-20 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474092878-30034-1-git-send-email-shawn.guo@linaro.org>
On Sat, Sep 17, 2016 at 02:14:38PM +0800, Shawn Guo wrote:
> Commit 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE
> device") changes earlycon function pl011_putc() to use a pointer to
> uart_amba_port. This causes a regression when earlycon is enabled,
> because uart_amba_port is not available yet at earlycon time. Let's
> revert the change on pl011_putc() to fix the regression.
>
> The earlycon support for ZTE device can probably be added later by
> declaring a new earlycon setup function with a vendor specific
> compatible.
>
> Reported-by: Sudeep Holla <sudeep.holla@arm.com>
> Fixes: 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE device")
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Hi Sudeep,
Can you please confirm if the patch fixes your problem, so that Greg
knows whether it should be applied? Thanks.
Shawn
^ permalink raw reply
* [PATCH V6 4/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Bjorn Helgaas @ 2016-09-20 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d06879a2-d6e9-5d62-77c5-47eff33d9584@semihalf.com>
On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
> On 19.09.2016 17:45, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
> >>ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
> >>compliant with ECAM standard. It uses non-standard configuration space
> >>accessors (see pci_thunder_pem_ops) and custom configuration space granulation
> >>(see bus_shift = 24). In order to access configuration space and
> >>probe PEM as ACPI based PCI host controller we need to add MCFG quirk
> >>infrastructure. This involves:
> >>1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
> >> code.
> >>2. New quirk entries for each PEM segment. Each contains platform IDs,
> >> mentioned pci_thunder_pem_ops and CFG resources.
> >>
> >>Quirk is considered for ThunderX silicon pass2.x only which is identified
> >>via MCFG revision 1.
> >
> >Is it really the case that silicon pass2.x has MCFG revision 1, and
> >silicon pass1.x has MCFG revision 2? That just seems backwards.
>
> It is weird but silicon pass2.x is more common and it had MCFG
> revision 1 from the beginning. Unless it is allowed to use MCFG
> revision 0 ? Then we could use MCFG revision 0 for pass1.x
There's no reason to avoid revision 0. The question is really what
firmware is already in the field. We need to accommodate that. We don't
want a situation where kernel version X only works with firmware version Y,
but kernel version X+1 only works with firmware version Y+1.
Bjorn
^ permalink raw reply
* ftrace function_graph causes system crash
From: Bean Huo (beanhuo) @ 2016-09-20 13:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi, all
I just use ftrace to do some latency study, found that function_graph can not
Work, as long as enable it, will cause kernel panic. I searched this online.
Found that there are also some cause the same as mine. I am a newer of ftrace.
I want to know who know what root cause? Here is some partial log:
echo function_graph > current_tracer
[ 9.583813] Unable to handle kernel paging request at virtual address b0200083
[ 9.590997] pgd = c0004000
[ 9.593683] [b0200083] *pgd=00000000
[ 9.597253] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 9.602542] Modules linked in:
[ 9.605586] CPU: 1 PID: 15 Comm: kworker/1:0 Not tainted 4.0.0-xilinx-00043-gc701690-dirty #515
[ 9.614256] Hardware name: Xilinx Zynq Platform
[ 9.618793] Workqueue: 0xe3a00001 (\x04 ??)
[ 9.622765] task: df517500 ti: df518000 task.ti: df518000
[ 9.628162] PC is at rb_update_write_stamp+0x18/0xa0
[ 9.633100] LR is at rb_commit+0x34/0xdc
[ 9.637005] pc : [<c00b6674>] lr : [<c00b716c>] psr: 60000093
[ 9.637005] sp : df51a0f0 ip : df40b00c fp : df51a104
[ 9.648456] r10: 00000000 r9 : 00000000 r8 : 00bbff80
[ 9.653666] r7 : c0edcf18 r6 : df51a190 r5 : df404100 r4 : df484680
[ 9.660175] r3 : b020006b r2 : df40b000 r1 : df40b2bc r0 : df484680
[ 9.666687] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 9.674065] Control: 18c5387d Table: 1ee7004a DAC: 00000015
[ 9.679792] Process kworker/1:0 (pid: 15, stack limit = 0xdf518210)
[ 9.686041] Stack: (0xdf51a0f0 to 0xdf51a000)
[ 9.690411] [<c00b6674>] (rb_update_write_stamp) from [<c00b716c>] (rb_commit+0x34/0xdc)
[ 9.698478] [<c00b716c>] (rb_commit) from [<c00b7968>] (ring_buffer_unlock_commit+0x30/0x18c)
[ 9.706987] [<c00b7968>] (ring_buffer_unlock_commit) from [<c00beca4>] (__buffer_unlock_commit+0x20/0x28)
[ 9.716534] [<c00beca4>] (__buffer_unlock_commit) from [<c00ca094>] (__trace_graph_entry+0x94/0xa8)
[ 9.725557] [<c00ca094>] (__trace_graph_entry) from [<c00ca260>] (trace_graph_entry+0x1b8/0x224)
[ 9.734323] [<c00ca260>] (trace_graph_entry) from [<c0020824>] (prepare_ftrace_return+0x70/0xac)
[ 9.743089] [<c0020824>] (prepare_ftrace_return) from [<c0020404>] (ftrace_graph_caller+0x18/0x20)
[ 9.752020] Code: e24cb004 e5903048 e3c1ceff e3cc200f (e5933018)
[ 9.758104] ---[ end trace 5781781938261a54 ]---
[ 9.762689] Kernel panic - not syncing: Fatal exception
[ 10.933397] SMP: failed to stop secondary CPUs
[ 10.937805] ---[ end Kernel panic - not syncing: Fatal exception
[ 10.943779] CPU1: stopping
[ 10.946471] CPU: 1 PID: 15 Comm: kworker/1:0 Tainted: G D 4.0.0-xilinx-00043-gc701690-dirty #515
[ 10.956358] Hardware name: Xilinx Zynq Platform
[ 10.960889] Workqueue: 0xe3a00001 (\x04 ??)
[ 10.964896] [<c0021d64>] (unwind_backtrace) from [<c001c1f4>] (show_stack+0x20/0x24)
[ 10.972620] [<c001c1f4>] (show_stack) from [<c0592250>] (dump_stack+0x80/0xd0)
[ 10.979822] [<c0592250>] (dump_stack) from [<c001efa4>] (ipi_cpu_stop+0x4c/0x80)
[ 10.987197] [<c001efa4>] (ipi_cpu_stop) from [<c001f728>] (handle_IPI+0x74/0xbc)
[ 10.994573] [<c001f728>] (handle_IPI) from [<c0008720>] (gic_handle_irq+0x68/0x70)
[ 11.002123] [<c0008720>] (gic_handle_irq) from [<c001cd84>] (__irq_svc+0x44/0x7c)
[ 11.009569] Exception stack(0xdf519e70 to 0xdf519eb8)
[ 11.014608] 9e60: 00000034 df518000 00000000 c08d9524
[ 11.022770] 9e80: 00000000 00000000 c00317c8 00000000 c00b6674 00000000 00000008 df519edc
[ 11.030929] 9ea0: df519eb8 df519eb8 c058f64c c058f650 60000113 ffffffff
[ 11.037541] [<c001cd84>] (__irq_svc) from [<c058f650>] (panic+0x188/0x20c)
[ 11.044399] [<c058f650>] (panic) from [<c001c578>] (die+0x380/0x3e0)
[ 11.050739] [<c001c578>] (die) from [<c0027c20>] (__do_kernel_fault+0x74/0x94)
[ 11.057941] [<c0027c20>] (__do_kernel_fault) from [<c0027f3c>] (do_page_fault+0x2fc/0x31c)
[ 11.066185] [<c0027f3c>] (do_page_fault) from [<c0028004>] (do_translation_fault+0x2c/0xc0)
^ permalink raw reply
* [PATCH] tty: amba-pl011: uart_amba_port is not available with earlycon function
From: Sudeep Holla @ 2016-09-20 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920130504.GF3744@tiger>
On 20/09/16 14:05, Shawn Guo wrote:
> On Sat, Sep 17, 2016 at 02:14:38PM +0800, Shawn Guo wrote:
>> Commit 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE
>> device") changes earlycon function pl011_putc() to use a pointer to
>> uart_amba_port. This causes a regression when earlycon is enabled,
>> because uart_amba_port is not available yet at earlycon time. Let's
>> revert the change on pl011_putc() to fix the regression.
>>
>> The earlycon support for ZTE device can probably be added later by
>> declaring a new earlycon setup function with a vendor specific
>> compatible.
>>
>> Reported-by: Sudeep Holla <sudeep.holla@arm.com>
>> Fixes: 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE device")
>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>
> Hi Sudeep,
>
> Can you please confirm if the patch fixes your problem, so that Greg
> knows whether it should be applied? Thanks.
>
Sorry, since it's basically what I tried first before posting some patch
using private_data, I assumed it will work.
Anyways I have now tested it, so you can add:
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Robert Richter @ 2016-09-20 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E11E52.8060303@linaro.org>
On 20.09.16 19:32:34, Hanjun Guo wrote:
> On 09/20/2016 06:43 PM, Robert Richter wrote:
> >Unfortunately either your nor my code does fix the BUG_ON() I see with
> >the numa kernel:
> >
> > kernel BUG at mm/page_alloc.c:1848!
> >
> >See below for the core dump. It looks like this happens due to moving
> >a mem block where first and last page are mapped to different numa
> >nodes, thus, triggering the BUG_ON().
>
> Didn't triggered it on our NUMA hardware, could you provide your
> config then we can have a try?
Config attached. Other configs with an initrd fail too.
-Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-4.8.0-rc5.vanilla5.xz
Type: application/x-xz
Size: 35316 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160920/8f9a3512/attachment-0001.xz>
^ permalink raw reply
* [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Michael Trimarchi @ 2016-09-20 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5B_ahBJr_Tgz_HShmG9heUwCj4K0N3FHhxja1yg0gCUGA@mail.gmail.com>
Hi Fabio
On Wed, Sep 14, 2016 at 8:00 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Sep 14, 2016 at 2:43 PM, Jagan Teki <jagan@amarulasolutions.com> wrote:
>
>> OK, but where it showed on the processor manual? I only find LDO_2P5
>
> It is not a SoC regulator. It is the regulator that powers the CAN transceiver.
Engicam use fixed regulator always on and on on boot. Their board does
not have any
external pmu. Is this answer to your comment?
Michael
^ permalink raw reply
* [PATCH] tty: amba-pl011: uart_amba_port is not available with earlycon function
From: Shawn Guo @ 2016-09-20 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f503859-0bf3-e031-450b-2597d93e05ce@arm.com>
On Tue, Sep 20, 2016 at 9:15 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Anyways I have now tested it, so you can add:
> Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Sorry for the regression, and thanks much for the effort of issue
reporting and testing.
Shawn
^ 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