* [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 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 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 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 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] 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: 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: 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] 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: 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 -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] 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
* 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: 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
* [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 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: kernel at martin.sperl.org @ 2016-09-20 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8053bf5c-7ddc-b4f7-1961-93f161731b16@tronnes.org>
> On 20.09.2016, at 12:56, Noralf Tr?nnes <noralf@tronnes.org> wrote:
>
>
> Den 20.09.2016 12:15, skrev Martin Sperl:
>>
>>
>> On 20.09.2016 10:41, Noralf Tr?nnes wrote:
>>>
>>> Den 20.09.2016 09:19, skrev Martin Sperl:
>>>> Hi Noralf!
>>>>
>>>> On 19.09.2016 17:26, Noralf Tr?nnes wrote:
>>>>> Some SMBus protocols use Repeated Start Condition to switch from write
>>>>> mode to read mode. Devices like MMA8451 won't work without it.
>>>>>
>>>>> When downstream implemented support for this in i2c-bcm2708, it broke
>>>>> support for some devices, so a module parameter was added and combined
>>>>> transfer was disabled by default.
>>>>> See https://github.com/raspberrypi/linux/issues/599
>>>>> It doesn't seem to have been any investigation into what the problem
>>>>> really was. Later there was added a timeout on the polling loop.
>>>>>
>>>>> One of the devices mentioned to partially stop working was DS1307.
>>>>>
>>>>> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
>>>>> and AT24C32 (eeprom) in parallel without problems.
>>>>>
>>>>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>>>>> ---
>>>>> drivers/i2c/busses/i2c-bcm2835.c | 107
>>>>> +++++++++++++++++++++++++++++++++++----
>>>>> 1 file changed, 98 insertions(+), 9 deletions(-)
>>>> ...
>>>>> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter
>>>>> *adap, struct i2c_msg msgs[],
>>>>> int i;
>>>>> int ret = 0;
>>>>> + /* Combined write-read to the same address (smbus) */
>>>>> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>>>>> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>>>>> + (msgs[0].len <= 16)) {
>>>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>>>>> +
>>>>> + return ret ? ret : 2;
>>>>> + }
>>>>> +
>>>>> for (i = 0; i < num; i++) {
>>>>> - ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
>>>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
>>>>> if (ret)
>>>>> break;
>>>>> }
>>>> This does not seem to implement the i2c_msg api correctly.
>>>>
>>>> As per comments in include/uapi/linux/i2c.h on line 58 only the last
>>>> message
>>>> in a group should - by default - send a STOP.
>>>>
>>>
>>> Apparently it's a known problem that the i2c controller doesn't support
>>> Repeated Start. It will always issue a Stop when it has transferred DLEN
>>> bytes.
>>> Refs:
>>> http://www.circuitwizard.de/raspi-i2c-fix/raspi-i2c-fix.html
>>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>>>
>>>
>>> UNLESS: a Start Transfer (ST) is issued after Transfer Active (TA) is set
>>> and before DONE is set (or the last byte is shifted, I don't know excatly).
>>> Refs:
>>> https://github.com/raspberrypi/linux/issues/254#issuecomment-15254134
>>> https://www.raspberrypi.org/forums/viewtopic.php?p=807834&sid=2b612c7209f2175bf1a266359c72ae6c#p807834
>>>
>>>
>>> I found this answer/report by joan that the downstream combined support
>>> isn't reliable:
>>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>>>
>>>
>>> My implementation differs from downstream in that I use local_irq_save()
>>> to protect the polling loop. But that only protects from missing the TA
>>> (downstream can miss the TA and issue a Stop).
>>>
>>> So currently in mainline we have a driver that says it support the standard
>>> (I2C_FUNC_I2C), but it really only supports one message transfers since it
>>> can't do ReStart.
>>>
>>> What I have done in this patch is to support ReStart for transfers with
>>> 2 messages: first write, then read. But maybe a better solution is to just
>>> leave this alone if it is flaky and use bitbanging instead. I don't know.
>> I have not said that the approach you have taken is wrong or bad.
>>
>
> I didn't take it as such, I'm just not sure what's the best approach here,
> so I added and looked up some more information
>
>> I was only telling you that the portion inside the bcm2835_i2c_xfer:
>> + /* Combined write-read to the same address (smbus) */
>> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>> + (msgs[0].len <= 16)) {
>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>> +
>> + return ret ? ret : 2;
>> + }
>> is very specific and maybe could be done in a "generic" manner
>> supporting more cases.
>>
>
> It has to be specific when it comes to number of messages. We can only
> support ReStart after the first message unless we use polling for the
> whole transfer. And in that case we can't disable interrupts for such
> a long period and we will end up sometimes loosing Transfer Active,
> resulting in Stop Condition between the messages.
> So we can only do transfers with 2 messages if we want Restart.
>
> It is possible to support more than 16 bytes for the first message,
> filling the FIFO after polling TA, but I'm not sure that is common.
> Mostly it's 1 or 2 bytes to set a register.
> The write-read restriction isn't absolutely necessary either, but it's the
> most common case I think. So it was about reusing bcm2835_i2c_xfer_msg().
> A less restrictive approach would require a dedicated function I think.
>
>> At least add a dev_warn_once for all num > 1 cases not handled by the
>> code above.
>>
>> This gives people an opportunity to detect such a situation if they
>> find something is not working as expected.
>>
>
> I agree.
>
> After reading joan's report I wonder if it would be best to add a module
> parameter like downstream has, so it can be disabled. What do you think?
>
I guess let us start simple:
* get warning in place about always issuing a stop for num > 1
- instead we may just want to set max_num_msgs = 1 in quirks.
* apply your patch for the write (<=16) then read case.
- maybe by setting quirks I2C_AQ_COMB_WRITE_THEN_READ
plus max_comb_1st_msg_len = 16 and max_num_msgs = 2
If this becomes too restrictive for some specific HW, then someone
may want to add the missing features.
As for the module parameters: no idea if this is acceptable
or sensible.
But that?s just my 2c...
Martin
^ permalink raw reply
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Mark Rutland @ 2016-09-20 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920104348.GP25086@rric.localdomain>
On Tue, Sep 20, 2016 at 12:43:48PM +0200, 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().
FWIW, I'm seeing a potentially-related BUG in the same function on a
v4.8-rc7 kernel without CONFIG_NUMA enabled. I have a number of debug
options set, including CONFIG_PAGE_POISONING and CONFIG_DEBUG_PAGEALLOC.
I've included the full log for that below, including subsequent
failures.
I'm triggering this by running $(hackbench 100 process 1000).
Thanks,
Mark.
[ 742.923329] ------------[ cut here ]------------
[ 742.927951] kernel BUG at mm/page_alloc.c:1844!
[ 742.932475] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 742.937951] Modules linked in:
[ 742.941075] CPU: 4 PID: 3608 Comm: hackbench Not tainted 4.8.0-rc7 #1
[ 742.947506] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 742.955066] task: ffff800341c4af80 task.stack: ffff800341c84000
[ 742.960981] PC is at move_freepages+0x220/0x338
[ 742.965503] LR is at move_freepages_block+0x164/0x1e0
[ 742.970544] pc : [<ffff2000083dfeb8>] lr : [<ffff2000083e0134>] pstate: 200001c5
[ 742.977928] sp : ffff800341c86ce0
[ 742.981233] x29: ffff800341c86ce0 x28: ffff20000c8d9308
[ 742.986541] x27: ffff7e000ffbffc0 x26: 0000000000000100
[ 742.991850] x25: 0000000000000000 x24: 00000000083fefff
[ 742.997157] x23: ffff7e000ffb8000 x22: ffff20000c8d9000
[ 743.002465] x21: ffff20000c8d9000 x20: 0000000000000700
[ 743.007772] x19: ffff7e000ffb8000 x18: 0000000000000000
[ 743.013079] x17: 0000000000000001 x16: ffff200008553d78
[ 743.018387] x15: 0000000000000002 x14: 0000000000000000
[ 743.023694] x13: ffffffffffffffff x12: ffff20000b311000
[ 743.029000] x11: 0000000000000000 x10: ffff20000d540000
[ 743.034307] x9 : dfff200000000000 x8 : ffff20000c8d9318
[ 743.039614] x7 : 0000000000000001 x6 : 1fffe4000149ab66
[ 743.044921] x5 : dfff200000000000 x4 : ffff20000a4d5b30
[ 743.050228] x3 : 0000000000000000 x2 : ffff7e000ffbffc0
[ 743.055535] x1 : 0000000000000000 x0 : 0000000000000000
[ 743.060841]
[ 743.062324] Process hackbench (pid: 3608, stack limit = 0xffff800341c84020)
[ 743.069276] Stack: (0xffff800341c86ce0 to 0xffff800341c88000)
[ 743.075013] 6ce0: ffff800341c86d70 ffff2000083e0134 00000000083fee00 ffff7e000ffb8000
[ 743.082833] 6d00: ffff20000c8d9000 0000000008400000 ffff7e000ffb8000 00000000083fefff
[ 743.090653] 6d20: 0000000000000000 0000000000000100 ffff20000a9873a0 ffff20000c8d9308
[ 743.098472] 6d40: 0000000000000000 0000000000000003 0000000000000005 ffff20000c8d9000
[ 743.106292] 6d60: 0000000000000000 0000000000000100 ffff800341c86dc0 ffff2000083e11bc
[ 743.114111] 6d80: 0000000000000005 0000000000000001 0000000000000000 0000000000000003
[ 743.121930] 6da0: 0000000000000005 ffff20000c8d9000 ffff20000b311000 1ffff000683896e8
[ 743.129750] 6dc0: ffff800341c86f50 ffff2000083e41fc 0000000000000003 ffff800341c873a0
[ 743.137570] 6de0: 00000000002156c0 0000000000000008 dfff200000000000 ffff20000a4d5000
[ 743.145389] 6e00: 0000000000000000 00000000002156c0 dfff200000000000 ffff20000c8d9000
[ 743.153209] 6e20: ffff800341c86ee0 ffff2000081b3758 0000000000000001 ffff800341c84000
[ 743.161028] 6e40: 0000000000000000 ffff7e000ffbb000 1ffff00068390dce ffff800341c86f50
[ 743.168848] 6e60: ffff7e000ffbb020 ffff7e000ffbb000 0000000041b58ab3 ffff20000a2777d8
[ 743.176668] 6e80: ffff2000083e06f8 000000000000b394 ffff800341c86e01 ffff20000823cd10
[ 743.184487] 6ea0: ffff20000b311000 00000000000001c0 ffff20000c8d9598 00000000002156c0
[ 743.192307] 6ec0: dfff200000000000 0000000000000000 ffff800341c86f20 ffff200009c28074
[ 743.200126] 6ee0: ffff20000c8d9580 0000000000000140 ffff2000083e41c8 0000000000000001
[ 743.207946] 6f00: dfff200000000000 ffff20000a4d5000 0000000000000000 0000000000000000
[ 743.215765] 6f20: ffff800341c86f50 ffff2000083e41c8 ffff20000c8d96e8 ffff800341c873a0
[ 743.223585] 6f40: 00000000002156c0 ffff2000083e4884 ffff800341c87160 ffff2000083e74d4
[ 743.231404] 6f60: ffff800341c4af80 ffff800341c873a0 00000000002156c0 0000000000000001
[ 743.239224] 6f80: dfff200000000000 ffff20000a4d5000 0000000000000000 00000000002156c0
[ 743.247043] 6fa0: 1ffff00068390e50 0000000000000001 00000000002156c0 ffff20000a9827c0
[ 743.254863] 6fc0: ffff800341c873b0 0000000000000003 0000000000000268 00000008002156c0
[ 743.262682] 6fe0: 1ffff00068390e18 0000000000000001 ffff8003ffef9000 0000000000000008
[ 743.270501] 7000: ffff8003002156c0 0000000000000002 0000000000000000 ffff200008236b1c
[ 743.278321] 7020: ffff800341c870a0 1ffff00068390e76 0000000000000140 ffff800341c4b740
[ 743.286141] 7040: ffff800300000003 ffff200008236b1c ffff800341c870e0 ffff200008236b1c
[ 743.293960] 7060: ffff800341c870e0 ffff200008236dac 0000000000000040 ffff800341c4b740
[ 743.301780] 7080: ffff800341c87110 ffff20000c8d9e00 ffff20000c8d9580 ffff20000c8d9268
[ 743.309599] 70a0: 0000000000000000 ffff800341c873a0 0000000000000000 ffff20000c8d9000
[ 743.317419] 70c0: 0000000041b58ab3 ffff20000a266f80 ffff2000083e37c8 1ffff00068390e4a
[ 743.325239] 70e0: ffff800341c4af80 0000000000000000 ffff800341c4af80 00000000000001c0
[ 743.333058] 7100: ffff800341c87130 ffff20000823f928 ffff20000b311000 00000000002156c0
[ 743.340878] 7120: 0000000000000140 00000000000001c0 ffff800341c87160 ffff2000083e71dc
[ 743.348698] 7140: ffff8003ffdf4680 00000000025106c0 ffff20000c8d9e00 00000000ffffffff
[ 743.356517] 7160: ffff800341c87400 ffff2000084ef36c ffff8003ffdf4680 00000000025106c0
[ 743.364337] 7180: 00000000002156c0 00000000ffffffff 00000000024146c0 0000000000000003
[ 743.372156] 71a0: 0000000000030020 ffff20000c8d9000 0000000000400000 0000000000000004
[ 743.379976] 71c0: ffff800341c87290 ffff200008093624 ffff800341c87350 ffff800341c87310
[ 743.387796] 71e0: ffff200008092ce0 ffff800341c4af80 ffff80036c0e0f80 ffff200009892b70
[ 743.395615] 7200: ffff20000ab19b70 ffff80036c0e0f80 ffff800341c84000 0000000000000004
[ 743.403435] 7220: 0000000041c4b738 1ffff000683896e7 0000000041b58ab3 ffff200000000040
[ 743.411254] 7240: ffff200000000000 ffff20000c8d9e08 ffff04000191b3c1 0000000000000000
[ 743.419074] 7260: 0000000000000000 ffff800341c87310 0000000300000000 ffff2000084ef36c
[ 743.426894] 7280: 0000000041b58ab3 ffff20000a277828 ffff2000083e70b8 ffff2000080937ac
[ 743.434713] 72a0: ffff800341c873f8 1ffff00068390e5e ffff800341c4af80 ffff800341c84000
[ 743.442533] 72c0: ffff800341c87390 ffff20000809397c ffff800341c84000 ffff800341c873f8
[ 743.450352] 72e0: 00000000025004c0 ffff800357ff2ac0 0000000041b58ab3 ffff20000a2623e8
[ 743.458172] 7300: ffff200008093648 ffff800341c84000 ffff800341c873b0 ffff2000084fade8
[ 743.465991] 7320: ffff800357ff2ce0 ffff800357ff2ba0 00000000025004c0 ffff800357ff2ac0
[ 743.473811] 7340: ffff80036c0e0f80 ffff200009892b70 ffff800341c873b0 ffff200008b58184
[ 743.481631] 7360: ffff20000a499000 000000000000b393 0000000000000000 00000000ffffffff
[ 743.489450] 7380: 00000000024106c0 ffff200009892b94 0000000000030020 ffff20000ab18cf0
[ 743.497270] 73a0: ffff20000c8d9e00 0000000000000000 ffff20000c8d9e00 0000000100000000
[ 743.505089] 73c0: 0000000000000000 ffff200008235e10 ffff8003ffdf4680 00000000025106c0
[ 743.512909] 73e0: 0000000000000000 ffff8003ffefd9b0 ffff800341c87400 ffff2000084ef38c
[ 743.520729] 7400: ffff800341c87490 ffff2000084f3bc0 0000000000000000 ffff8003ffefc5d0
[ 743.528548] 7420: 0000000000000000 ffff8003ffdf4680 00000000025106c0 ffff200009892b94
[ 743.536368] 7440: 0000000000210d00 ffff20000ab18cf0 ffff20000ab19938 0000000000000004
[ 743.544188] 7460: ffff2000098678a0 ffff20000854d770 ffff20000854ff38 025106c008553e20
[ 743.552007] 7480: ffff200008084730 ffffffffffffffff ffff800341c87590 ffff2000084f4130
[ 743.559827] 74a0: ffff20000a4a35d0 ffff20000a4d5e80 0000000000000140 00000000025106c0
[ 743.567646] 74c0: ffff200009892b94 0000000000000004 ffff8003ffdf4680 ffff20000ab1cb30
[ 743.575466] 74e0: ffff800341c84000 0000000000000004 ffff20000a499000 000000000000b392
[ 743.583286] 7500: ffff20000ab19988 ffff8003ffefc5d0 ffff200009892b94 ffff20000a4d5000
[ 743.591105] 7520: ffff800341c87580 ffff200008b5815c ffff20000a4a35d0 ffff8003ffdf4680
[ 743.598925] 7540: 0000000000000140 00000000025106c0 ffff200009892b94 ffff20000a4d5000
[ 743.606744] 7560: ffff8003ffdf4680 ffff20000ab1cb30 ffff800341c84000 ffff20000a278cb8
[ 743.614564] 7580: ffff800341c87590 ffff2000084f40ec ffff800341c875e0 ffff2000084fa028
[ 743.622383] 75a0: 0000000000000000 ffff8003ffdf4680 ffff8003ffdf4680 ffff20000ab1bff0
[ 743.630203] 75c0: 00000000025106c0 ffff20000a4d5000 ffff200009892b94 ffff20000a4d5000
[ 743.638023] 75e0: ffff800341c87660 ffff20000988cf54 ffff800341c87710 1ffff00068390ede
[ 743.645842] 7600: 00000000025004c0 ffff200009892b94 0000000000000000 0000000000000200
[ 743.653662] 7620: ffff80034219e940 dfff200000000000 ffff80034219e940 0000000000000000
[ 743.661481] 7640: 0000000000000064 00000000025004c0 0000000000000000 ffff80036c0e0f80
[ 743.669301] 7660: ffff800341c876a0 ffff200009892b94 ffff800357ff2ac0 1ffff00068390ede
[ 743.677120] 7680: 0000000000000064 00000000025004c0 0000000000000000 ffff80036c0e0f80
[ 743.684939] 76a0: ffff800341c87790 ffff200009893074 0000000000000000 0000000000000064
[ 743.692759] 76c0: ffff80034219eb20 0000000000000000 0000000000000003 0000000000000000
[ 743.700579] 76e0: ffff80034219e940 dfff200000000000 0000000041b58ab3 ffff20000a2cd5a8
[ 743.708398] 7700: ffff200009892ad0 dfff200000000000 ffff80034219f200 ffff20000cb359b0
[ 743.716218] 7720: ffff800342143364 ffff20000a4d5e90 ffff20000a4d5e90 00006003f5a2d000
[ 743.724038] 7740: 1ffff0006842866c 0000000000000004 0000dffff5b2a188 ffff20000a4a0000
[ 743.731857] 7760: ffff800341c877c0 ffff20000823daac ffff800341c84000 0000000000000140
[ 743.739677] 7780: ffff20000a7ac240 000000000000010a ffff800341c87830 ffff20000986ec00
[ 743.747498] 77a0: ffff800341c87920 7fffffffffffffff ffff80034219eb20 0000000000000000
[ 743.755319] 77c0: 0000000000000002 1ffff00068433d65 ffff80034219e940 dfff200000000000
[ 743.763138] 77e0: ffff80034219e940 0000000000000064 ffff800341c87830 ffff2000081b3178
[ 743.770958] 7800: ffff800341c4af80 ffff20000a0f3aa0 000000000000010a 0000000000000000
[ 743.778778] 7820: ffff8003025000c0 ffff800347135840 ffff800341c87980 ffff200009b33a10
[ 743.786597] 7840: 0000000000000064 0000000000000000 0000000000000000 0000000000000000
[ 743.794416] 7860: ffff800342198900 0000000000000064 ffff80034219e940 dfff200000000000
[ 743.802236] 7880: 0000000000000000 0000000000000064 ffff20000a0f3140 1ffff00068390f4a
[ 743.810055] 78a0: 0000000341c87ba0 0000000000000000 0000000000000064 ffff80034219ec50
[ 743.817875] 78c0: 1ffff00068390f20 ffff800341c87a70 ffff200009b3c398 0000000000000064
[ 743.825695] 78e0: ffff80034219eb28 ffff80034219ece2 1ffff00068433d8a ffff100068433d9c
[ 743.833514] 7900: 0000000041b58ab3 ffff20000a2680e0 ffff20000986e710 ffff800341c4b740
[ 743.841334] 7920: 1ffff000683896e8 000000000c8db000 ffff20000987442c 0000000000000140
[ 743.849153] 7940: ffff800341c87980 ffff200009b33b70 ffff800341c87980 ffff200009b337d8
[ 743.856973] 7960: ffff800347135840 ffff800341c87ba0 ffff20000a0f3140 0000000000000000
[ 743.864793] 7980: ffff800341c87af0 ffff2000098675f8 ffff800347135840 ffff800341c87ba0
[ 743.872612] 79a0: ffff20000a0f3140 ffff800341c87d77 ffff800341c87ba0 ffff800342b2a340
[ 743.880432] 79c0: ffff800347135840 1ffff00068390faa 0000000000000002 1ffff0006856546c
[ 743.888251] 79e0: ffff8003372a4780 ffff8003372a4790 1ffff00068390f4a ffff800347135840
[ 743.896071] 7a00: ffff10006843312c ffff800342198960 ffff800341c87a70 ffff80034219eb28
[ 743.903890] 7a20: ffff800341c87ab0 ffff800341c87be8 ffff800341c87ba0 1ffff00068390f7d
[ 743.911710] 7a40: 0000000000000064 0000000000000064 0000000041b58ab3 ffff20000a2d20f8
[ 743.919530] 7a60: ffff200009b33720 ffff20000a743000 00000000ffffff97 1ffff00068390f7e
[ 743.927349] 7a80: ffff800341c4af80 0000000000000000 ffff800341c4af80 ffff8003ffef9000
[ 743.935169] 7aa0: ffff800341c87ab0 ffff2000082383dc 0000000000000000 0000000000000000
[ 743.942988] 7ac0: ffffffff00000000 00000000ffffffff ffff8003ffef9018 0000000000000000
[ 743.950808] 7ae0: 0000000000000000 ffff2000081b205c ffff800341c87b30 ffff2000098678a0
[ 743.958628] 7b00: ffff800341c87d50 ffff800341c87cf0 1ffff00068390f70 00000000000001c0
[ 743.966447] 7b20: ffff8003ffef9018 ffff8003ffef9000 ffff800341c87c20 ffff20000854d770
[ 743.974267] 7b40: 1ffff00068390f92 ffff20000a0c0980 ffff800341c87d50 ffff800341c87e80
[ 743.982086] 7b60: 1ffff0006856546d ffff800342b2a368 1ffff00068390fd0 ffff80036ba1a480
[ 743.989906] 7b80: 0000000041b58ab3 ffff20000a2ccf48 ffff2000098676e0 ffff20000caf9470
[ 743.997725] 7ba0: 0000000000000000 0000000000000000 0000000000000001 0000000000000000
[ 744.005545] 7bc0: 0000000000000064 ffff800341c87cb0 0000000000000001 0000000000000000
[ 744.013364] 7be0: 0000000000000000 0000000000000000 ffff800341c87cf0 0000000000000001
[ 744.021183] 7c00: ffff800341c4b76a ffff800341c4b748 ffff20000d540000 0000000000000001
[ 744.029003] 7c20: ffff800341c87db0 ffff20000854ff38 ffff800342b2a340 0000000000000064
[ 744.036822] 7c40: ffff800347135870 ffff800342b2a3b4 0000000000000004 1ffff00068565476
[ 744.044642] 7c60: 0000ffffe63a1420 ffff800342b2a360 ffff800341c87e80 ffff800347135df0
[ 744.052462] 7c80: 0000000000000064 ffff800342b29fd0 0000000041b58ab3 ffff20000a27c658
[ 744.060281] 7ca0: ffff20000854d520 ffff800342b29fe0 0000ffffe63a1420 0000000000000064
[ 744.068101] 7cc0: 0000dffff5b2a188 0000000000000001 1ffff0007ffdf327 0000000000000001
[ 744.075920] 7ce0: ffff800341c87cf0 1ffff00068390fa2 ffff800342b2a340 0000000000000000
[ 744.083739] 7d00: 0000000000000000 0000000000000000 0000000000000000 ffff20000a27dc50
[ 744.091559] 7d20: ffff800341c87d60 ffff20000854f80c ffff800342b2a340 ffff800347135870
[ 744.099378] 7d40: 0000000000000000 0000000000000001 0000000000000001 0000000000000000
[ 744.107197] 7d60: 0000000000000064 ffff800341c87cb0 0000000000000001 0000000000000064
[ 744.115016] 7d80: ffff800341c84000 ffff800342b2a3b4 0000000000000004 ffff800341c4b300
[ 744.122836] 7da0: 0000000000000000 ffff8003372a4700 ffff800341c87e10 ffff200008553e20
[ 744.130656] 7dc0: 1ffff00068390fcc ffff800342b2a340 ffff800342b2a340 dfff200000000000
[ 744.138475] 7de0: 1ffff00068565487 0000ffffe63a1420 0000000000000064 ffff800342b2a438
[ 744.146295] 7e00: ffff200009c47000 ffff800341c84000 0000000000000000 ffff200008084730
[ 744.154114] 7e20: 0000000000000000 000000003d5e7b00 ffffffffffffffff 0000000000405acc
[ 744.161934] 7e40: 0000000060000000 0000000000000015 0000000000000120 0000000000000040
[ 744.169753] 7e60: 0000000041b58ab3 ffff20000a27c6d0 ffff200008553d78 000000003d5e7b00
[ 744.177572] 7e80: 0000000000000000 0000000000405acc 0000000060000000 ffff200008084630
[ 744.185392] 7ea0: 0000000000000000 ffff200008084624 0000000000000000 000000003d5e7b00
[ 744.193212] 7ec0: 000000000000000c 0000ffffe63a1420 0000000000000064 0000ffffe63a1420
[ 744.201031] 7ee0: 0000000000000000 00000000004a2790 000000000049d020 0000000000000058
[ 744.208850] 7f00: 0000000000000040 1999999999999999 0000000000000000 0000000000000000
[ 744.216669] 7f20: 0000000000000002 ffffffffffffffff 0000000000000000 00000000004a26f8
[ 744.224488] 7f40: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
[ 744.232307] 7f60: 000000003d5e7b00 0000000000000010 0000000000000064 0000000000000004
[ 744.240126] 7f80: 00000000000000f6 000000000049b000 000000000049c010 0000000000401e40
[ 744.247946] 7fa0: 0000000000000022 0000ffffe63a13d0 0000000000401dd4 0000ffffe63a13d0
[ 744.255765] 7fc0: 0000000000405acc 0000000060000000 000000000000000c 0000000000000040
[ 744.263584] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 744.271402] Call trace:
[ 744.273840] Exception stack(0xffff800341c86a90 to 0xffff800341c86bc0)
[ 744.280270] 6a80: ffff7e000ffb8000 0001000000000000
[ 744.288090] 6aa0: ffff800341c86ce0 ffff2000083dfeb8 00000000200001c5 000000000000003d
[ 744.295909] 6ac0: 0000000000000000 0000000000000100 ffff7e000ffbffc0 ffff800341c84000
[ 744.303729] 6ae0: ffff800341c4b76a ffff800341c4b748 0000000041b58ab3 ffff20000a261068
[ 744.311549] 6b00: ffff200008081b10 ffff800341c4af80 ffff800341c4b720 dfff200000000000
[ 744.319368] 6b20: ffff20000b311000 0000000000000001 ffff20000b311a60 00000000000080e7
[ 744.327188] 6b40: ffff800341c86ca0 ffff200009c16a78 ffff800341c86c10 ffff200009c28720
[ 744.335007] 6b60: ffff800341c86bc0 ffff200008b58184 ffff20000a499000 000000000000b2f1
[ 744.342826] 6b80: 0000000000000000 ffff20000a4d5000 ffff800336325e80 0000000000000000
[ 744.350645] 6ba0: 0000dffff5b2a188 0000000000000001 0000000000000000 0000000000000000
[ 744.358467] [<ffff2000083dfeb8>] move_freepages+0x220/0x338
[ 744.364030] [<ffff2000083e0134>] move_freepages_block+0x164/0x1e0
[ 744.370113] [<ffff2000083e11bc>] __rmqueue+0xac4/0x16d0
[ 744.375329] [<ffff2000083e41fc>] get_page_from_freelist+0xa34/0x2228
[ 744.381674] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 744.388019] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 744.393061] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 744.399665] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 744.406790] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 744.413050] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 744.419307] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 744.424522] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 744.430519] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 744.436605] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 744.442603] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 744.447906] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 744.453556] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 744.458858] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 744.463986] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 744.469029] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 744.474333] Code: 913d0000 941ebb67 17ffffed d503201f (d4210000)
[ 744.480482] ---[ end trace a906e1a5ea5e05bb ]---
[ 744.485103] BUG: sleeping function called from invalid context at ./include/linux/sched.h:3049
[ 744.493712] in_atomic(): 1, irqs_disabled(): 0, pid: 3608, name: hackbench
[ 744.500583] INFO: lockdep is turned off.
[ 744.504503] Preemption disabled at:[<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 744.512856]
[ 744.514341] CPU: 4 PID: 3608 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 744.521986] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 744.529544] Call trace:
[ 744.531983] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 744.537373] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 744.542417] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 744.547550] [<ffff2000081b2e24>] ___might_sleep+0x5ec/0x868
[ 744.553114] [<ffff2000081b3178>] __might_sleep+0xd8/0x350
[ 744.558504] [<ffff20000816b740>] exit_signals+0x80/0x428
[ 744.563807] [<ffff200008143f18>] do_exit+0x220/0x1828
[ 744.568849] [<ffff2000080945a4>] die+0x2f4/0x3c8
[ 744.573458] [<ffff2000080946dc>] bug_handler.part.1+0x64/0xf0
[ 744.579194] [<ffff2000080947ac>] bug_handler+0x44/0x70
[ 744.584322] [<ffff200008086c28>] brk_handler+0x168/0x348
[ 744.589624] [<ffff200008081c00>] do_debug_exception+0xf0/0x368
[ 744.595446] Exception stack(0xffff800341c86a90 to 0xffff800341c86bc0)
[ 744.601877] 6a80: ffff7e000ffb8000 0001000000000000
[ 744.609697] 6aa0: ffff800341c86ce0 ffff2000083dfeb8 00000000200001c5 000000000000003d
[ 744.617516] 6ac0: 0000000000000000 0000000000000100 ffff7e000ffbffc0 ffff800341c84000
[ 744.625336] 6ae0: ffff800341c4b76a ffff800341c4b748 0000000041b58ab3 ffff20000a261068
[ 744.633155] 6b00: ffff200008081b10 ffff800341c4af80 ffff800341c4b720 dfff200000000000
[ 744.640975] 6b20: ffff20000b311000 0000000000000001 ffff20000b311a60 00000000000080e7
[ 744.648795] 6b40: ffff800341c86ca0 ffff200009c16a78 ffff800341c86c10 ffff200009c28720
[ 744.656614] 6b60: ffff800341c86bc0 ffff200008b58184 ffff20000a499000 000000000000b2f1
[ 744.664434] 6b80: 0000000000000000 ffff20000a4d5000 ffff800336325e80 0000000000000000
[ 744.672253] 6ba0: 0000dffff5b2a188 0000000000000001 0000000000000000 0000000000000000
[ 744.680072] [<ffff200008083e5c>] el1_dbg+0x18/0x74
[ 744.684854] [<ffff2000083e0134>] move_freepages_block+0x164/0x1e0
[ 744.690937] [<ffff2000083e11bc>] __rmqueue+0xac4/0x16d0
[ 744.696153] [<ffff2000083e41fc>] get_page_from_freelist+0xa34/0x2228
[ 744.702497] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 744.708841] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 744.713882] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 744.720487] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 744.727612] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 744.733870] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 744.740127] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 744.745343] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 744.751339] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 744.757423] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 744.763421] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 744.768723] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 744.774372] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 744.779674] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 744.784802] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 744.789843] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 744.795159] note: hackbench[3608] exited with preempt_count 1
[ 783.865366] BUG: spinlock lockup suspected on CPU#5, hackbench/3727
[ 783.871631] lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[ 783.881189] CPU: 5 PID: 3727 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 783.888835] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 783.896393] Call trace:
[ 783.898832] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 783.904222] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 783.909265] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 783.914395] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[ 783.919524] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[ 783.925262] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[ 783.931346] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 783.937691] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 783.944034] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 783.949076] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 783.955680] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 783.962805] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 783.969063] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 783.975320] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 783.980536] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 783.986532] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 783.992616] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 783.998614] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 784.003916] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 784.009565] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 784.014867] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 784.019995] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 784.025037] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 802.492828] BUG: spinlock lockup suspected on CPU#7, hackbench/3194
[ 802.499097] lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[ 802.508655] CPU: 7 PID: 3194 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 802.516301] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 802.523859] Call trace:
[ 802.526300] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 802.531690] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 802.536733] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 802.541862] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[ 802.546991] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[ 802.552729] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[ 802.558813] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 802.565158] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 802.571502] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 802.576544] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 802.583148] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 802.590273] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 802.596531] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 802.602789] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 802.608004] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 802.614001] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 802.620086] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 802.626083] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 802.631386] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 802.637035] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 802.642337] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 802.647465] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 802.652507] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 802.727119] BUG: spinlock lockup suspected on CPU#1, hackbench/5203
[ 802.733384] lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[ 802.742942] CPU: 1 PID: 5203 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 802.750587] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 802.758145] Call trace:
[ 802.760584] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 802.765975] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 802.771017] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 802.776146] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[ 802.781275] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[ 802.787013] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[ 802.793097] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 802.799441] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 802.805785] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 802.810827] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 802.817432] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 802.824557] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 802.830815] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 802.837073] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 802.842289] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 802.848285] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 802.854370] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 802.860367] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 802.865670] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 802.871319] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 802.876621] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 802.881750] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 802.886792] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 806.778113] BUG: spinlock lockup suspected on CPU#6, hackbench/3240
[ 806.784376] lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[ 806.793933] CPU: 6 PID: 3240 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 806.801578] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 806.809136] Call trace:
[ 806.811575] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 806.816966] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 806.822008] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 806.827137] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[ 806.832265] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[ 806.838002] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[ 806.844086] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 806.850430] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 806.856774] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 806.861815] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 806.868420] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 806.875545] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 806.881803] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 806.888060] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 806.893276] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 806.899272] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 806.905356] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 806.911354] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 806.916656] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 806.922306] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 806.927607] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 806.932736] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 806.937777] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 808.159084] BUG: spinlock lockup suspected on CPU#3, hackbench/4717
[ 808.165350] lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[ 808.174908] CPU: 3 PID: 4717 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 808.182554] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 808.190112] Call trace:
[ 808.192552] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 808.197942] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 808.202985] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 808.208114] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[ 808.213243] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[ 808.218980] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[ 808.225064] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 808.231408] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 808.237752] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 808.242794] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 808.249399] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 808.256524] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 808.262782] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 808.269039] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 808.274255] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 808.280251] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 808.286335] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 808.292333] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 808.297635] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 808.303285] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 808.308587] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 808.313715] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 808.318757] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 809.327451] BUG: spinlock lockup suspected on CPU#2, hackbench/3360
[ 809.333714] lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[ 809.343271] CPU: 2 PID: 3360 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 809.350916] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 809.358474] Call trace:
[ 809.360913] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 809.366303] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 809.371345] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 809.376475] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[ 809.381603] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[ 809.382291] BUG: spinlock lockup suspected on CPU#0, hackbench/5685
[ 809.382297] lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[ 809.403145] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[ 809.409229] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 809.415574] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 809.421917] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 809.426959] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 809.433564] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 809.440689] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 809.446946] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 809.453204] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 809.458420] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 809.464417] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 809.470501] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 809.476498] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 809.481801] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 809.487450] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 809.492752] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 809.497880] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 809.502922] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 809.508226] CPU: 0 PID: 5685 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 809.515873] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 809.523431] Call trace:
[ 809.525871] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 809.531261] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 809.536304] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 809.541433] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[ 809.546562] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[ 809.552299] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[ 809.558383] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 809.564728] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 809.571071] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 809.576113] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 809.582717] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 809.589842] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 809.596100] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 809.602357] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 809.607573] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 809.613570] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 809.619654] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 809.625651] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 809.630953] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 809.636602] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 809.641904] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 809.647032] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 809.652074] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[ 810.224351] BUG: spinlock lockup suspected on CPU#4, hackbench/5272
[ 810.230613] lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[ 810.240169] CPU: 4 PID: 5272 Comm: hackbench Tainted: G D 4.8.0-rc7 #1
[ 810.247814] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[ 810.255371] Call trace:
[ 810.257810] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[ 810.263200] [<ffff2000080942a4>] show_stack+0x14/0x20
[ 810.268242] [<ffff200008afa714>] dump_stack+0xfc/0x150
[ 810.273371] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[ 810.278499] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[ 810.284236] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[ 810.290320] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[ 810.296664] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[ 810.303008] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[ 810.308049] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[ 810.314654] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[ 810.321779] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[ 810.328037] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[ 810.334294] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[ 810.339509] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[ 810.345506] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[ 810.351590] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[ 810.357587] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[ 810.362889] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[ 810.368538] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[ 810.373840] [<ffff20000854ff38>] vfs_write+0x128/0x520
[ 810.378968] [<ffff200008553e20>] SyS_write+0xa8/0x140
[ 810.384010] [<ffff200008084730>] el0_svc_naked+0x24/0x28
^ permalink raw reply
* [RFC] arm64: Ensure proper addressing for ldnp/stnp
From: Robin Murphy @ 2016-09-20 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9a3f86d9037a478f0a1a87b2084c7496@codeaurora.org>
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 order 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
>
^ permalink raw reply
* [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: Noralf Trønnes @ 2016-09-20 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4990930f-6d69-89c6-4b23-deae3d6713ed@martin.sperl.org>
Den 20.09.2016 12:15, skrev Martin Sperl:
>
>
> On 20.09.2016 10:41, Noralf Tr?nnes wrote:
>>
>> Den 20.09.2016 09:19, skrev Martin Sperl:
>>> Hi Noralf!
>>>
>>> On 19.09.2016 17:26, Noralf Tr?nnes wrote:
>>>> Some SMBus protocols use Repeated Start Condition to switch from write
>>>> mode to read mode. Devices like MMA8451 won't work without it.
>>>>
>>>> When downstream implemented support for this in i2c-bcm2708, it broke
>>>> support for some devices, so a module parameter was added and combined
>>>> transfer was disabled by default.
>>>> See https://github.com/raspberrypi/linux/issues/599
>>>> It doesn't seem to have been any investigation into what the problem
>>>> really was. Later there was added a timeout on the polling loop.
>>>>
>>>> One of the devices mentioned to partially stop working was DS1307.
>>>>
>>>> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
>>>> and AT24C32 (eeprom) in parallel without problems.
>>>>
>>>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>>>> ---
>>>> drivers/i2c/busses/i2c-bcm2835.c | 107
>>>> +++++++++++++++++++++++++++++++++++----
>>>> 1 file changed, 98 insertions(+), 9 deletions(-)
>>> ...
>>>> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter
>>>> *adap, struct i2c_msg msgs[],
>>>> int i;
>>>> int ret = 0;
>>>> + /* Combined write-read to the same address (smbus) */
>>>> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>>>> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>>>> + (msgs[0].len <= 16)) {
>>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>>>> +
>>>> + return ret ? ret : 2;
>>>> + }
>>>> +
>>>> for (i = 0; i < num; i++) {
>>>> - ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
>>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
>>>> if (ret)
>>>> break;
>>>> }
>>> This does not seem to implement the i2c_msg api correctly.
>>>
>>> As per comments in include/uapi/linux/i2c.h on line 58 only the last
>>> message
>>> in a group should - by default - send a STOP.
>>>
>>
>> Apparently it's a known problem that the i2c controller doesn't support
>> Repeated Start. It will always issue a Stop when it has transferred DLEN
>> bytes.
>> Refs:
>> http://www.circuitwizard.de/raspi-i2c-fix/raspi-i2c-fix.html
>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>>
>>
>>
>> UNLESS: a Start Transfer (ST) is issued after Transfer Active (TA) is
>> set
>> and before DONE is set (or the last byte is shifted, I don't know
>> excatly).
>> Refs:
>> https://github.com/raspberrypi/linux/issues/254#issuecomment-15254134
>> https://www.raspberrypi.org/forums/viewtopic.php?p=807834&sid=2b612c7209f2175bf1a266359c72ae6c#p807834
>>
>>
>>
>> I found this answer/report by joan that the downstream combined support
>> isn't reliable:
>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>>
>>
>>
>> My implementation differs from downstream in that I use local_irq_save()
>> to protect the polling loop. But that only protects from missing the TA
>> (downstream can miss the TA and issue a Stop).
>>
>> So currently in mainline we have a driver that says it support the
>> standard
>> (I2C_FUNC_I2C), but it really only supports one message transfers
>> since it
>> can't do ReStart.
>>
>> What I have done in this patch is to support ReStart for transfers with
>> 2 messages: first write, then read. But maybe a better solution is to
>> just
>> leave this alone if it is flaky and use bitbanging instead. I don't
>> know.
> I have not said that the approach you have taken is wrong or bad.
>
I didn't take it as such, I'm just not sure what's the best approach here,
so I added and looked up some more information
> I was only telling you that the portion inside the bcm2835_i2c_xfer:
> + /* Combined write-read to the same address (smbus) */
> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
> + (msgs[0].len <= 16)) {
> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
> +
> + return ret ? ret : 2;
> + }
> is very specific and maybe could be done in a "generic" manner
> supporting more cases.
>
It has to be specific when it comes to number of messages. We can only
support ReStart after the first message unless we use polling for the
whole transfer. And in that case we can't disable interrupts for such
a long period and we will end up sometimes loosing Transfer Active,
resulting in Stop Condition between the messages.
So we can only do transfers with 2 messages if we want Restart.
It is possible to support more than 16 bytes for the first message,
filling the FIFO after polling TA, but I'm not sure that is common.
Mostly it's 1 or 2 bytes to set a register.
The write-read restriction isn't absolutely necessary either, but it's the
most common case I think. So it was about reusing bcm2835_i2c_xfer_msg().
A less restrictive approach would require a dedicated function I think.
> At least add a dev_warn_once for all num > 1 cases not handled by the
> code above.
>
> This gives people an opportunity to detect such a situation if they
> find something is not working as expected.
>
I agree.
After reading joan's report I wonder if it would be best to add a module
parameter like downstream has, so it can be disabled. What do you think?
Noralf.
^ permalink raw reply
* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Philipp Zabel @ 2016-09-20 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNASDYjUjUoUEstFygA1GOboVgDTNKak8Zkpcj_B3XbK-1w@mail.gmail.com>
Am Dienstag, den 20.09.2016, 17:47 +0900 schrieb Masahiro Yamada:
> Hi Philipp,
>
>
> 2016-09-20 16:30 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> > Hi Masahiro,
> >
> > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
> >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
> >> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
> >>
> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >> ---
> >>
> >> Philipp,
> >>
> >> IIRC, you mentioned that you were planning to consolidate the double
> >> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
> >>
> >> I have not seen it in the ML, so I am sending this.
> >>
> >> Please let me know if you have some updates.
> >
> > I had started to doodle a bit, see
> >
> > git fetch git://git.pengutronix.de/git/pza/linux.git refs/heads/reset/kconfig
> >
> > but I haven't found time for cleanup and testing.
>
>
> OK, I will merge this patch for now.
>
>
>
> BTW, I did not understand some of your commits under way.
>
>
> commit 7fe911f9c83737449565db03bebf953d3d94bbbf
> Author: Philipp Zabel <p.zabel@pengutronix.de>
> Date: Tue Aug 9 11:18:51 2016 +0200
>
> dmaengine: sunx6i: do not depend on reset controller framework
>
> The reset controller framework provides inline function stubs if
> disabled.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>
>
>
>
>
> As far as I see from drivers/dma/sun6i-dma.c,
> the reset control is mandatory for this driver.
>
> Why are you removing the dependency?
>
>
> Don't you care if it works on run-time
> as long as it can build?
I have not thought about this too hard, it's just there because the
reset framework is not a build dependency (anymore). Some patches were
necessary to remove dependency loops, but I think this one could just be
dropped.
regards
Philipp
^ permalink raw reply
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Robert Richter @ 2016-09-20 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474310970-21264-1-git-send-email-ddaney.cavm@gmail.com>
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);
}
}
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().
Continuing with my investigations...
-Robert
[ 9.674272] ------------[ cut here ]------------
[ 9.678881] kernel BUG at mm/page_alloc.c:1848!
[ 9.683406] Internal error: Oops - BUG: 0 [#1] SMP
[ 9.688190] Modules linked in:
[ 9.691247] CPU: 77 PID: 1 Comm: swapper/0 Tainted: G W 4.8.0-rc5.vanilla5-00030-ga2b86cb3ce72 #38
[ 9.701322] Hardware name: www.cavium.com ThunderX CRB-2S/ThunderX CRB-2S, BIOS 0.3 Aug 24 2016
[ 9.710008] task: ffff800fe4561400 task.stack: ffff800ffbe0c000
[ 9.715939] PC is at move_freepages+0x160/0x168
[ 9.720460] LR is at move_freepages+0x160/0x168
[ 9.724979] pc : [<ffff0000081ec7d0>] lr : [<ffff0000081ec7d0>] pstate: 600000c5
[ 9.732362] sp : ffff800ffbe0f510
[ 9.735666] x29: ffff800ffbe0f510 x28: ffff7fe043f80020
[ 9.740975] x27: ffff7fe043f80000 x26: 000000000000000c
[ 9.746283] x25: 000000000000000c x24: ffff810ffffaf0e0
[ 9.751591] x23: 0000000000000001 x22: 0000000000000000
[ 9.756898] x21: ffff7fe043ffffc0 x20: ffff810ffffaeb00
[ 9.762206] x19: ffff7fe043f80000 x18: 0000000000000010
[ 9.767513] x17: 0000000000000000 x16: 0000000100000000
[ 9.772821] x15: ffff000088f03f37 x14: 6e2c303d64696e2c
[ 9.778128] x13: 3038336566666666 x12: 6630303866666666
[ 9.783436] x11: 3d656e6f7a203a64 x10: 0000000000000536
[ 9.788744] x9 : 0000000000000060 x8 : 3030626561666666
[ 9.794051] x7 : 6630313866666666 x6 : ffff000008f03f97
[ 9.799359] x5 : 0000000000000006 x4 : 000000000000000c
[ 9.804667] x3 : 0000000000010000 x2 : 0000000000010000
[ 9.809975] x1 : ffff000008da7be0 x0 : 0000000000000050
[ 10.517213] Call trace:
[ 10.519651] Exception stack(0xffff800ffbe0f340 to 0xffff800ffbe0f470)
[ 10.526081] f340: ffff7fe043f80000 0001000000000000 ffff800ffbe0f510 ffff0000081ec7d0
[ 10.533900] f360: ffff000008f03988 0000000008da7bc8 ffff800ffbe0f410 ffff0000081275fc
[ 10.541718] f380: ffff800ffbe0f470 ffff000008ac5a00 ffff7fe043ffffc0 0000000000000000
[ 10.549536] f3a0: 0000000000000001 ffff810ffffaf0e0 000000000000000c 000000000000000c
[ 10.557355] f3c0: ffff7fe043f80000 ffff7fe043f80020 0000000000000030 0000000000000000
[ 10.565173] f3e0: 0000000000000050 ffff000008da7be0 0000000000010000 0000000000010000
[ 10.572991] f400: 000000000000000c 0000000000000006 ffff000008f03f97 6630313866666666
[ 10.580809] f420: 3030626561666666 0000000000000060 0000000000000536 3d656e6f7a203a64
[ 10.588628] f440: 6630303866666666 3038336566666666 6e2c303d64696e2c ffff000088f03f37
[ 10.596446] f460: 0000000100000000 0000000000000000
[ 10.601316] [<ffff0000081ec7d0>] move_freepages+0x160/0x168
[ 10.606879] [<ffff0000081ec880>] move_freepages_block+0xa8/0xb8
[ 10.612788] [<ffff0000081ecf80>] __rmqueue+0x610/0x670
[ 10.617918] [<ffff0000081ee2e4>] get_page_from_freelist+0x3cc/0xb40
[ 10.624174] [<ffff0000081ef05c>] __alloc_pages_nodemask+0x12c/0xd40
[ 10.630438] [<ffff000008244cd0>] alloc_page_interleave+0x60/0xb0
[ 10.636434] [<ffff000008245398>] alloc_pages_current+0x108/0x168
[ 10.642430] [<ffff0000081e49ac>] __page_cache_alloc+0x104/0x140
[ 10.648339] [<ffff0000081e4b00>] pagecache_get_page+0x118/0x2e8
[ 10.654248] [<ffff0000081e4d18>] grab_cache_page_write_begin+0x48/0x68
[ 10.660769] [<ffff000008298c08>] simple_write_begin+0x40/0x150
[ 10.666591] [<ffff0000081e47c0>] generic_perform_write+0xb8/0x1a0
[ 10.672674] [<ffff0000081e6228>] __generic_file_write_iter+0x178/0x1c8
[ 10.679191] [<ffff0000081e6344>] generic_file_write_iter+0xcc/0x1c8
[ 10.685448] [<ffff00000826d12c>] __vfs_write+0xcc/0x140
[ 10.690663] [<ffff00000826de08>] vfs_write+0xa8/0x1c0
[ 10.695704] [<ffff00000826ee34>] SyS_write+0x54/0xb0
[ 10.700666] [<ffff000008bf2008>] xwrite+0x34/0x7c
[ 10.705359] [<ffff000008bf20ec>] do_copy+0x9c/0xf4
[ 10.710140] [<ffff000008bf1dc4>] write_buffer+0x34/0x50
[ 10.715354] [<ffff000008bf1e28>] flush_buffer+0x48/0xb8
[ 10.720579] [<ffff000008c1faa0>] __gunzip+0x27c/0x324
[ 10.725620] [<ffff000008c1fb60>] gunzip+0x18/0x20
[ 10.730314] [<ffff000008bf26dc>] unpack_to_rootfs+0x168/0x280
[ 10.736049] [<ffff000008bf2864>] populate_rootfs+0x70/0x138
[ 10.741615] [<ffff000008082ff4>] do_one_initcall+0x44/0x138
[ 10.747179] [<ffff000008bf0d0c>] kernel_init_freeable+0x1ac/0x24c
[ 10.753267] [<ffff000008859f78>] kernel_init+0x20/0xf8
[ 10.758395] [<ffff000008082b80>] ret_from_fork+0x10/0x50
[ 10.763698] Code: 17fffff2 b00046c0 91280000 97ffd47d (d4210000)
[ 10.769834] ---[ end trace 972d622f64fd69c0 ]---
^ permalink raw reply related
* [PATCH] arm64: kgdb: handle read-only text / modules
From: Mark Rutland @ 2016-09-20 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920100321.17846-1-takahiro.akashi@linaro.org>
On Tue, Sep 20, 2016 at 07:03:21PM +0900, AKASHI Takahiro wrote:
> Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
> by using aarch64_insn_write() instead of probe_kernel_write().
> See how this works:
> commit 2f896d586610 ("arm64: use fixmap for text patching")
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Jason Wessel <jason.wessel@windriver.com>
> Cc: <stable@vger.kernel.org> # 4.0-
We had SET_MODULE_RONX in v3.17, and we had KGDB before that, so we need
something for v3.17+.
> ---
> arch/arm64/kernel/kgdb.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index 6732a27..133cfe3 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -382,3 +382,23 @@ struct kgdb_arch arch_kgdb_ops = {
> KGDB_DYN_BRK_INS_BYTE(3),
> }
> };
> +int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> +{
> + int err;
> +
> + BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
> +
> + err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
> + if (err)
> + return err;
> +
> + return aarch64_insn_write((void *)bpt->bpt_addr,
> + (u32)AARCH64_BREAK_KGDB_DYN_DBG);
> +}
This changes the endianness of saved_instr (on BE), but it looks like
that's handed as an opaque token by the core code anyway, so that should
be fine.
This also renders arch_kgdb_ops.gdb_bpt_instr unused. Can/should we get
rid of that?
> +int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> +{
> + return aarch64_insn_write((void *)bpt->bpt_addr,
> + *(u32 *)bpt->saved_instr);
> +}
We also need a few additional includes:
<asm/debug-monitors.h> # for BREAK_INSTR_SIZE, AARCH64_BREAK_KGDB_DYN_DBG
<asm/insn.h> # for AARCH64_INSN_SIZE, insn_{read,write}
<linux/bug.h> # for BUILD_BUG_ON()
I take it that we're protected against nesting within
aarch64_insn_write(), so that we can't deadlock on patch_lock?
Other than that, this looks good to me.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Marc Zyngier @ 2016-09-20 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E109CF.8030705@suse.de>
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
"spurious in the GIC sense" (hence returning 0x3ff) and not a spurious
timer interrupt being presented, you're fine.
> Either way, I agree that this approach in general is saner. I don't
> think it's easier to implement though, but we'll get to that when I send
> a new version :)
OK.
M
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] iommu/arm-smmu: Updates for 4.9
From: Will Deacon @ 2016-09-20 10:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Joerg,
Please pull these significant arm-smmu updates for 4.9. The vast majority
of the code here is Robin's series to move the drivers over to the
generic DT bindings, which finally hooks up the DMA API and MSI mapping
for host machines. This has been stewing for a while and is now at the
point where I feel it's much better in mainline than languishing outside.
A consequence of that is that there are some non-trivial changes outside
of the drivers, but these are all acked by the relevant subsystem
maintainers.
Other stuff here includes some non-critical fixes to the queue handling
on SMMUv3 and a small devm cleanup that missed the boat last time around.
Cheers,
Will
--->8
The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:
Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-joerg/arm-smmu/updates
for you to fetch changes up to 82db33dc5e49fb625262d81125625d07a0d6184e:
iommu/io-pgtable-arm: Check for v7s-incapable systems (2016-09-16 09:34:23 +0100)
----------------------------------------------------------------
Jean-Philippe Brucker (2):
iommu/arm-smmu: Fix event queues synchronization
iommu/arm-smmu: Fix polling of command queue
Mark Rutland (1):
Docs: dt: add PCI IOMMU map bindings
Peng Fan (1):
iommu/arm-smmu: Drop devm_free_irq when driver detach
Robin Murphy (23):
iommu/arm-smmu: Support v7s context format
of/irq: Break out msi-map lookup (again)
iommu/of: Handle iommu-map property for PCI
iommu: Introduce iommu_fwspec
Docs: dt: document ARM SMMUv3 generic binding usage
iommu/arm-smmu: Fall back to global bypass
iommu/arm-smmu: Implement of_xlate() for SMMUv3
iommu/arm-smmu: Support non-PCI devices with SMMUv3
iommu/arm-smmu: Set PRIVCFG in stage 1 STEs
iommu/arm-smmu: Handle stream IDs more dynamically
iommu/arm-smmu: Consolidate stream map entry state
iommu/arm-smmu: Keep track of S2CR state
iommu/arm-smmu: Refactor mmu-masters handling
iommu/arm-smmu: Streamline SMMU data lookups
iommu/arm-smmu: Add a stream map entry iterator
iommu/arm-smmu: Intelligent SMR allocation
iommu/arm-smmu: Convert to iommu_fwspec
Docs: dt: document ARM SMMU generic binding usage
iommu/arm-smmu: Wire up generic configuration support
iommu/arm-smmu: Set domain geometry
iommu/dma: Add support for mapping MSIs
iommu/dma: Avoid PCI host bridge windows
iommu/io-pgtable-arm: Check for v7s-incapable systems
Will Deacon (1):
iommu/arm-smmu: Disable interrupts whilst holding the cmdq lock
.../devicetree/bindings/iommu/arm,smmu-v3.txt | 8 +-
.../devicetree/bindings/iommu/arm,smmu.txt | 61 +-
.../devicetree/bindings/pci/pci-iommu.txt | 171 ++++
arch/arm64/mm/dma-mapping.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
drivers/iommu/Kconfig | 2 +-
drivers/iommu/arm-smmu-v3.c | 561 ++++++------
drivers/iommu/arm-smmu.c | 995 ++++++++++-----------
drivers/iommu/dma-iommu.c | 161 +++-
drivers/iommu/io-pgtable-arm-v7s.c | 4 +
drivers/iommu/iommu.c | 58 ++
drivers/iommu/of_iommu.c | 52 +-
drivers/irqchip/irq-gic-v2m.c | 3 +
drivers/irqchip/irq-gic-v3-its.c | 3 +
drivers/of/irq.c | 78 +-
drivers/of/of_pci.c | 102 +++
include/linux/device.h | 3 +
include/linux/dma-iommu.h | 12 +-
include/linux/iommu.h | 39 +
include/linux/of_pci.h | 10 +
20 files changed, 1430 insertions(+), 897 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
^ permalink raw reply
* [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: Martin Sperl @ 2016-09-20 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb5e8e93-c6af-0050-1e7d-a69b722feadb@tronnes.org>
On 20.09.2016 10:41, Noralf Tr?nnes wrote:
>
> Den 20.09.2016 09:19, skrev Martin Sperl:
>> Hi Noralf!
>>
>> On 19.09.2016 17:26, Noralf Tr?nnes wrote:
>>> Some SMBus protocols use Repeated Start Condition to switch from write
>>> mode to read mode. Devices like MMA8451 won't work without it.
>>>
>>> When downstream implemented support for this in i2c-bcm2708, it broke
>>> support for some devices, so a module parameter was added and combined
>>> transfer was disabled by default.
>>> See https://github.com/raspberrypi/linux/issues/599
>>> It doesn't seem to have been any investigation into what the problem
>>> really was. Later there was added a timeout on the polling loop.
>>>
>>> One of the devices mentioned to partially stop working was DS1307.
>>>
>>> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
>>> and AT24C32 (eeprom) in parallel without problems.
>>>
>>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>>> ---
>>> drivers/i2c/busses/i2c-bcm2835.c | 107
>>> +++++++++++++++++++++++++++++++++++----
>>> 1 file changed, 98 insertions(+), 9 deletions(-)
>> ...
>>> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter
>>> *adap, struct i2c_msg msgs[],
>>> int i;
>>> int ret = 0;
>>> + /* Combined write-read to the same address (smbus) */
>>> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>>> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>>> + (msgs[0].len <= 16)) {
>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>>> +
>>> + return ret ? ret : 2;
>>> + }
>>> +
>>> for (i = 0; i < num; i++) {
>>> - ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
>>> if (ret)
>>> break;
>>> }
>> This does not seem to implement the i2c_msg api correctly.
>>
>> As per comments in include/uapi/linux/i2c.h on line 58 only the last
>> message
>> in a group should - by default - send a STOP.
>>
>
> Apparently it's a known problem that the i2c controller doesn't support
> Repeated Start. It will always issue a Stop when it has transferred DLEN
> bytes.
> Refs:
> http://www.circuitwizard.de/raspi-i2c-fix/raspi-i2c-fix.html
> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>
>
> UNLESS: a Start Transfer (ST) is issued after Transfer Active (TA) is set
> and before DONE is set (or the last byte is shifted, I don't know excatly).
> Refs:
> https://github.com/raspberrypi/linux/issues/254#issuecomment-15254134
> https://www.raspberrypi.org/forums/viewtopic.php?p=807834&sid=2b612c7209f2175bf1a266359c72ae6c#p807834
>
>
> I found this answer/report by joan that the downstream combined support
> isn't reliable:
> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>
>
> My implementation differs from downstream in that I use local_irq_save()
> to protect the polling loop. But that only protects from missing the TA
> (downstream can miss the TA and issue a Stop).
>
> So currently in mainline we have a driver that says it support the standard
> (I2C_FUNC_I2C), but it really only supports one message transfers since it
> can't do ReStart.
>
> What I have done in this patch is to support ReStart for transfers with
> 2 messages: first write, then read. But maybe a better solution is to just
> leave this alone if it is flaky and use bitbanging instead. I don't know.
I have not said that the approach you have taken is wrong or bad.
I was only telling you that the portion inside the bcm2835_i2c_xfer:
+ /* Combined write-read to the same address (smbus) */
+ if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
+ !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
+ (msgs[0].len <= 16)) {
+ ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
+
+ return ret ? ret : 2;
+ }
is very specific and maybe could be done in a "generic" manner
supporting more cases.
At least add a dev_warn_once for all num > 1 cases not handled by the
code above.
This gives people an opportunity to detect such a situation if they
find something is not working as expected.
Martin
^ 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