* [PATCH v4 09/10] ARM/ARM64: KVM: Fix CPU_ON emulation for PSCI v0.2
From: Anup Patel @ 2014-02-06 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686302-19451-1-git-send-email-anup.patel@linaro.org>
As-per PSCI v0.2, the source CPU provides physical address of
"entry point" and "context id" for starting a target CPU.
Current emulation of CPU_ON function does not consider physical
address of "context id" hence this patch updates kvm_psci_vcpu_on()
such that it works for both PSCI v0.1 and PSCI v0.2.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm/kvm/psci.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index 75447a3..675866e 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -32,12 +32,14 @@ static void kvm_psci_vcpu_off(struct kvm_vcpu *vcpu)
vcpu->arch.pause = true;
}
-static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
+static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu,
+ int psci_version)
{
struct kvm *kvm = source_vcpu->kvm;
struct kvm_vcpu *vcpu = NULL, *tmp;
wait_queue_head_t *wq;
unsigned long cpu_id;
+ unsigned long context_id;
unsigned long mpidr;
phys_addr_t target_pc;
int i;
@@ -62,6 +64,7 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
return KVM_PSCI_RET_INVAL;
target_pc = *vcpu_reg(source_vcpu, 2);
+ context_id = *vcpu_reg(source_vcpu, 3);
kvm_reset_vcpu(vcpu);
@@ -76,6 +79,8 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
kvm_vcpu_set_be(vcpu);
*vcpu_pc(vcpu) = target_pc;
+ if (psci_version != KVM_ARM_PSCI_0_1)
+ *vcpu_reg(vcpu, 0) = context_id;
vcpu->arch.pause = false;
smp_mb(); /* Make sure the above is visible */
@@ -180,7 +185,7 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
break;
case KVM_PSCI_0_2_FN_CPU_ON:
case KVM_PSCI_0_2_FN64_CPU_ON:
- val = kvm_psci_vcpu_on(vcpu);
+ val = kvm_psci_vcpu_on(vcpu, KVM_ARM_PSCI_0_2);
break;
case KVM_PSCI_0_2_FN_AFFINITY_INFO:
case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
@@ -234,7 +239,7 @@ static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
val = KVM_PSCI_RET_SUCCESS;
break;
case KVM_PSCI_FN_CPU_ON:
- val = kvm_psci_vcpu_on(vcpu);
+ val = kvm_psci_vcpu_on(vcpu, KVM_ARM_PSCI_0_1);
break;
case KVM_PSCI_FN_CPU_SUSPEND:
case KVM_PSCI_FN_MIGRATE:
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 10/10] ARM/ARM64: KVM: Emulate PSCI v0.2 CPU_SUSPEND
From: Anup Patel @ 2014-02-06 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686302-19451-1-git-send-email-anup.patel@linaro.org>
This patch adds emulation of PSCI v0.2 CPU_SUSPEND function call for
KVM ARM/ARM64. This is a VCPU-level function call which can suspend
current VCPU or all VCPUs within current VCPU's affinity level.
The CPU_SUSPEND emulation is not tested much because currently there
is no CPUIDLE driver in Linux kernel that uses PSCI CPU_SUSPEND. The
PSCI CPU_SUSPEND implementation in ARM64 kernel was tested using a
Simple CPUIDLE driver which is not published due to unstable DT-bindings
for PSCI.
(For more info, http://lwn.net/Articles/574950/)
Even if we had stable DT-bindings for PSCI and CPUIDLE driver that
uses PSCI CPU_SUSPEND then still we need to define SUSPEND states
for KVM ARM/ARM64. Due to this, the CPU_SUSPEND emulation added
by this patch only pause a VCPU and to wakeup a VCPU we need to
explicity call PSCI CPU_ON from Guest.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm/include/asm/kvm_host.h | 5 +++
arch/arm/include/asm/kvm_psci.h | 1 +
arch/arm/kvm/psci.c | 88 +++++++++++++++++++++++++++++++++++--
arch/arm/kvm/reset.c | 4 ++
arch/arm64/include/asm/kvm_host.h | 5 +++
arch/arm64/include/asm/kvm_psci.h | 1 +
arch/arm64/kvm/reset.c | 4 ++
7 files changed, 104 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 193ceaf..2cc36a6 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -131,6 +131,11 @@ struct kvm_vcpu_arch {
/* Don't run the guest on this vcpu */
bool pause;
+ /* PSCI suspend state */
+ bool suspend;
+ u32 suspend_entry;
+ u32 suspend_context_id;
+
/* IO related fields */
struct kvm_decode mmio_decode;
diff --git a/arch/arm/include/asm/kvm_psci.h b/arch/arm/include/asm/kvm_psci.h
index 6bda945..6a05ada 100644
--- a/arch/arm/include/asm/kvm_psci.h
+++ b/arch/arm/include/asm/kvm_psci.h
@@ -22,6 +22,7 @@
#define KVM_ARM_PSCI_0_2 2
int kvm_psci_version(struct kvm_vcpu *vcpu);
+void kvm_psci_reset(struct kvm_vcpu *vcpu);
int kvm_psci_call(struct kvm_vcpu *vcpu);
#endif /* __ARM_KVM_PSCI_H__ */
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index 675866e..482b0f6 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -15,6 +15,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/smp.h>
#include <linux/kvm_host.h>
#include <linux/wait.h>
@@ -27,9 +28,81 @@
* as described in ARM document number ARM DEN 0022A.
*/
+struct psci_suspend_info {
+ struct kvm_vcpu *vcpu;
+ unsigned long saved_entry;
+ unsigned long saved_context_id;
+};
+
+static void psci_do_suspend(void *context)
+{
+ struct psci_suspend_info *sinfo = context;
+
+ sinfo->vcpu->arch.pause = true;
+ sinfo->vcpu->arch.suspend = true;
+ sinfo->vcpu->arch.suspend_entry = sinfo->saved_entry;
+ sinfo->vcpu->arch.suspend_context_id = sinfo->saved_context_id;
+}
+
+static unsigned long kvm_psci_vcpu_suspend(struct kvm_vcpu *vcpu)
+{
+ int i;
+ unsigned long mpidr;
+ unsigned long target_affinity;
+ unsigned long target_affinity_mask;
+ unsigned long lowest_affinity_level;
+ struct kvm *kvm = vcpu->kvm;
+ struct kvm_vcpu *tmp;
+ struct psci_suspend_info sinfo;
+
+ target_affinity = kvm_vcpu_get_mpidr(vcpu);
+ lowest_affinity_level = (*vcpu_reg(vcpu, 1) >> 24) & 0x3;
+
+ /* Determine target affinity mask */
+ target_affinity_mask = MPIDR_HWID_BITMASK;
+ switch (lowest_affinity_level) {
+ case 0: /* All affinity levels are valid */
+ target_affinity_mask &= ~0x0UL;
+ break;
+ case 1: /* Aff0 ignored */
+ target_affinity_mask &= ~0xFFUL;
+ break;
+ case 2: /* Aff0 and Aff1 ignored */
+ target_affinity_mask &= ~0xFFFFUL;
+ break;
+ case 3: /* Aff0, Aff1, and Aff2 ignored */
+ target_affinity_mask &= ~0xFFFFFFUL;
+ break;
+ default:
+ return KVM_PSCI_RET_INVAL;
+ };
+
+ /* Ignore other bits of target affinity */
+ target_affinity &= target_affinity_mask;
+
+ /* Prepare suspend info */
+ sinfo.vcpu = NULL;
+ sinfo.saved_entry = *vcpu_reg(vcpu, 2);
+ sinfo.saved_context_id = *vcpu_reg(vcpu, 3);
+
+ /* Suspend all VCPUs within target affinity */
+ kvm_for_each_vcpu(i, tmp, kvm) {
+ mpidr = kvm_vcpu_get_mpidr(tmp);
+ if (((mpidr & target_affinity_mask) == target_affinity) &&
+ !tmp->arch.suspend) {
+ sinfo.vcpu = tmp;
+ smp_call_function_single(tmp->cpu,
+ psci_do_suspend, &sinfo, 1);
+ }
+ }
+
+ return KVM_PSCI_RET_SUCCESS;
+}
+
static void kvm_psci_vcpu_off(struct kvm_vcpu *vcpu)
{
vcpu->arch.pause = true;
+ vcpu->arch.suspend = false;
}
static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu,
@@ -179,6 +252,10 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
*/
val = 2;
break;
+ case KVM_PSCI_0_2_FN_CPU_SUSPEND:
+ case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
+ val = kvm_psci_vcpu_suspend(vcpu);
+ break;
case KVM_PSCI_0_2_FN_CPU_OFF:
kvm_psci_vcpu_off(vcpu);
val = KVM_PSCI_RET_SUCCESS;
@@ -216,10 +293,6 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
val = KVM_PSCI_RET_SUCCESS;
ret = 0;
break;
- case KVM_PSCI_0_2_FN_CPU_SUSPEND:
- case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
- val = KVM_PSCI_RET_NI;
- break;
default:
return -EINVAL;
}
@@ -253,6 +326,13 @@ static int kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
return 1;
}
+void kvm_psci_reset(struct kvm_vcpu *vcpu)
+{
+ vcpu->arch.suspend = false;
+ vcpu->arch.suspend_entry = 0;
+ vcpu->arch.suspend_context_id = 0;
+}
+
/**
* kvm_psci_call - handle PSCI call if r0 value is in range
* @vcpu: Pointer to the VCPU struct
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
index f558c07..220c892 100644
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@ -26,6 +26,7 @@
#include <asm/cputype.h>
#include <asm/kvm_arm.h>
#include <asm/kvm_coproc.h>
+#include <asm/kvm_psci.h>
#include <kvm/arm_arch_timer.h>
@@ -79,5 +80,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
/* Reset arch_timer context */
kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
+ /* Reset PSCI state */
+ kvm_psci_reset(vcpu);
+
return 0;
}
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 92242ce..b2c97dc 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -119,6 +119,11 @@ struct kvm_vcpu_arch {
/* Don't run the guest */
bool pause;
+ /* PSCI suspend state */
+ bool suspend;
+ u64 suspend_entry;
+ u64 suspend_context_id;
+
/* IO related fields */
struct kvm_decode mmio_decode;
diff --git a/arch/arm64/include/asm/kvm_psci.h b/arch/arm64/include/asm/kvm_psci.h
index bc39e55..4da675d 100644
--- a/arch/arm64/include/asm/kvm_psci.h
+++ b/arch/arm64/include/asm/kvm_psci.h
@@ -22,6 +22,7 @@
#define KVM_ARM_PSCI_0_2 2
int kvm_psci_version(struct kvm_vcpu *vcpu);
+void kvm_psci_reset(struct kvm_vcpu *vcpu);
int kvm_psci_call(struct kvm_vcpu *vcpu);
#endif /* __ARM64_KVM_PSCI_H__ */
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 70a7816..aca9f65 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -29,6 +29,7 @@
#include <asm/ptrace.h>
#include <asm/kvm_arm.h>
#include <asm/kvm_coproc.h>
+#include <asm/kvm_psci.h>
/*
* ARMv8 Reset Values
@@ -108,5 +109,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
/* Reset timer */
kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
+ /* Reset PSCI state */
+ kvm_psci_reset(vcpu);
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 08/51] arm, hw-breakpoint: Fix CPU hotplug callback registration
From: Srivatsa S. Bhat @ 2014-02-06 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206113933.GJ26035@mudshark.cambridge.arm.com>
On 02/06/2014 05:09 PM, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 11:25:46AM +0000, Srivatsa S. Bhat wrote:
>> Hi Will,
>
> Hello,
>
>> On 02/06/2014 04:27 PM, Will Deacon wrote:
>>> On Wed, Feb 05, 2014 at 10:06:04PM +0000, Srivatsa S. Bhat wrote:
>>>> Subsystems that want to register CPU hotplug callbacks, as well as perform
>>>> initialization for the CPUs that are already online, often do it as shown
>>>> below:
>>>>
>>>> get_online_cpus();
>>>>
>>>> for_each_online_cpu(cpu)
>>>> init_cpu(cpu);
>>>>
>>>> register_cpu_notifier(&foobar_cpu_notifier);
>>>>
>>>> put_online_cpus();
>>>>
>>>> This is wrong, since it is prone to ABBA deadlocks involving the
>>>> cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
>>>> with CPU hotplug operations).
>>>
>>> Hmm, the code in question (for this patch) runs from an arch_initcall. How
>>> can you generate CPU hotplug operations at that stage?
>>>
>>
>> You are right - in today's design of the init sequence, CPU hotplug
>> operations can't be triggered at that time during boot.
>
> Phew, so we don't have a bug as the code stands today.
Yes, that's right.
>
>> However, there have been proposals to boot CPUs in parallel along with the
>> rest of the kernel initialization [1] (and that would need full synchronization
>> with CPU hotplug even at the initcall stage). Of course this needs a lot of
>> auditing and modifications to the CPU hotplug notifiers of various subsystems
>> to make them robust enough to handle the parallel boot; so its not going to
>> happen very soon. But I felt that it would be a good idea to ensure that we
>> get the locking/synchronization right, even if the registrations happen very
>> early during boot today.. you know, just to be on the safer side and also to
>> make the job easier for whoever that is, who tries to implement parallel
>> CPU booting again in the future ;-)
>>
>> [1]. http://thread.gmane.org/gmane.linux.kernel/1246209
>
> Makes sense, and this seems like a good start.
>
>>> so it's best if you take this all via your tree.
>>>
>>
>> Hmm.. I'm not a maintainer myself, so I'm hoping that either Oleg or Rusty
>> or any of the other CPU hotplug maintainers (Thomas/Peter/Ingo) would be
>> willing to take these patches through their tree.
>
> Well, you can have my ack for this patch:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
Great! Thanks a lot Will!
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Marc Zyngier @ 2014-02-06 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686253-13436-3-git-send-email-will.deacon@arm.com>
On 06/02/14 11:30, Will Deacon wrote:
> When sending an SGI to another CPU, we require a DSB to ensure that
> any pending stores to normal memory are made visible to the recipient
> before the interrupt arrives.
>
> Rather than use a dsb() (which will soon cause an assembly error on
> arm64) followed by a writel_relaxed, we can use a writel instead, which
> will emit a dsb st prior to the str.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Looks sensible to me.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 08/51] arm, hw-breakpoint: Fix CPU hotplug callback registration
From: Will Deacon @ 2014-02-06 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F3713A.3040407@linux.vnet.ibm.com>
On Thu, Feb 06, 2014 at 11:25:46AM +0000, Srivatsa S. Bhat wrote:
> Hi Will,
Hello,
> On 02/06/2014 04:27 PM, Will Deacon wrote:
> > On Wed, Feb 05, 2014 at 10:06:04PM +0000, Srivatsa S. Bhat wrote:
> >> Subsystems that want to register CPU hotplug callbacks, as well as perform
> >> initialization for the CPUs that are already online, often do it as shown
> >> below:
> >>
> >> get_online_cpus();
> >>
> >> for_each_online_cpu(cpu)
> >> init_cpu(cpu);
> >>
> >> register_cpu_notifier(&foobar_cpu_notifier);
> >>
> >> put_online_cpus();
> >>
> >> This is wrong, since it is prone to ABBA deadlocks involving the
> >> cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
> >> with CPU hotplug operations).
> >
> > Hmm, the code in question (for this patch) runs from an arch_initcall. How
> > can you generate CPU hotplug operations at that stage?
> >
>
> You are right - in today's design of the init sequence, CPU hotplug
> operations can't be triggered at that time during boot.
Phew, so we don't have a bug as the code stands today.
> However, there have been proposals to boot CPUs in parallel along with the
> rest of the kernel initialization [1] (and that would need full synchronization
> with CPU hotplug even at the initcall stage). Of course this needs a lot of
> auditing and modifications to the CPU hotplug notifiers of various subsystems
> to make them robust enough to handle the parallel boot; so its not going to
> happen very soon. But I felt that it would be a good idea to ensure that we
> get the locking/synchronization right, even if the registrations happen very
> early during boot today.. you know, just to be on the safer side and also to
> make the job easier for whoever that is, who tries to implement parallel
> CPU booting again in the future ;-)
>
> [1]. http://thread.gmane.org/gmane.linux.kernel/1246209
Makes sense, and this seems like a good start.
> > so it's best if you take this all via your tree.
> >
>
> Hmm.. I'm not a maintainer myself, so I'm hoping that either Oleg or Rusty
> or any of the other CPU hotplug maintainers (Thomas/Peter/Ingo) would be
> willing to take these patches through their tree.
Well, you can have my ack for this patch:
Acked-by: Will Deacon <will.deacon@arm.com>
Cheers,
Will
^ permalink raw reply
* [PATCH 1/6] arm64: barriers: allow dsb macro to take option parameter
From: Catalin Marinas @ 2014-02-06 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686253-13436-1-git-send-email-will.deacon@arm.com>
On Thu, Feb 06, 2014 at 11:30:48AM +0000, Will Deacon wrote:
> The dsb instruction takes an option specifying both the target access
> types and shareability domain.
>
> This patch allows such an option to be passed to the dsb macro,
> resulting in potentially more efficient code. Currently the option is
> ignored until all callers are updated (unlike ARM, the option is
> mandated by the assembler).
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>
> Catalin -- I'd like to get this simple change in for 3.14, since it's a
> blocker for actually implementing the barrier options (we
> need to move all of the callers over before making the switch).
OK, no problem. Applied.
--
Catalin
^ permalink raw reply
* [PATCH 28/51] arm64, hw_breakpoint.c: Fix CPU hotplug callback registration
From: Will Deacon @ 2014-02-06 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205220944.19080.26519.stgit@srivatsabhat.in.ibm.com>
On Wed, Feb 05, 2014 at 10:09:45PM +0000, Srivatsa S. Bhat wrote:
> Subsystems that want to register CPU hotplug callbacks, as well as perform
> initialization for the CPUs that are already online, often do it as shown
> below:
[...]
> Fix the hw-breakpoint code in arm64 by using this latter form of callback
> registration.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
> arch/arm64/kernel/hw_breakpoint.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> index f17f581..24e88d0 100644
> --- a/arch/arm64/kernel/hw_breakpoint.c
> +++ b/arch/arm64/kernel/hw_breakpoint.c
> @@ -913,6 +913,8 @@ static int __init arch_hw_breakpoint_init(void)
> pr_info("found %d breakpoint and %d watchpoint registers.\n",
> core_num_brps, core_num_wrps);
>
> + cpu_maps_update_begin();
> +
> /*
> * Reset the breakpoint resources. We assume that a halting
> * debugger will leave the world in a nice state for us.
> @@ -927,7 +929,10 @@ static int __init arch_hw_breakpoint_init(void)
> TRAP_HWBKPT, "hw-watchpoint handler");
>
> /* Register hotplug notifier. */
> - register_cpu_notifier(&hw_breakpoint_reset_nb);
> + __register_cpu_notifier(&hw_breakpoint_reset_nb);
> +
> + cpu_maps_update_done();
> +
> /* Register cpu_suspend hw breakpoint restore hook */
> cpu_suspend_set_dbg_restorer(hw_breakpoint_reset);
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 2/6] arm64: barriers: make use of barrier options with explicit barriers
From: Catalin Marinas @ 2014-02-06 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686253-13436-2-git-send-email-will.deacon@arm.com>
On Thu, Feb 06, 2014 at 11:30:49AM +0000, Will Deacon wrote:
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -20,14 +20,14 @@
>
> #ifndef __ASSEMBLY__
>
> -#define sev() asm volatile("sev" : : : "memory")
> +#define sev(l) asm volatile("sev" #l : : : "memory")
Would we actually ever use sev(l) form C? And it's a new instruction
rather than an argument to the existing sev.
--
Catalin
^ permalink raw reply
* [PATCH 29/51] arm64, debug-monitors: Fix CPU hotplug callback registration
From: Will Deacon @ 2014-02-06 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205220957.19080.79200.stgit@srivatsabhat.in.ibm.com>
On Wed, Feb 05, 2014 at 10:09:58PM +0000, Srivatsa S. Bhat wrote:
> Subsystems that want to register CPU hotplug callbacks, as well as perform
> initialization for the CPUs that are already online, often do it as shown
> below:
[...]
> Fix the debug-monitors code in arm64 by using this latter form of callback
> registration.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
> arch/arm64/kernel/debug-monitors.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
> index 636ba8b..959a16b 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -155,12 +155,16 @@ static struct notifier_block os_lock_nb = {
>
> static int debug_monitors_init(void)
> {
> + cpu_maps_update_begin();
> +
> /* Clear the OS lock. */
> smp_call_function(clear_os_lock, NULL, 1);
> clear_os_lock(NULL);
>
> /* Register hotplug handler. */
> - register_cpu_notifier(&os_lock_nb);
> + __register_cpu_notifier(&os_lock_nb);
> +
> + cpu_maps_update_done();
> return 0;
> }
> postcore_initcall(debug_monitors_init);
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 00/11] ARM: shmobile: RSPI RZ and QSPI SoC and board integration
From: Simon Horman @ 2014-02-06 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoSrLV3PiUdbUQv9gTsM-p8tiqRvSza-=D9hG5fVn-CR0A@mail.gmail.com>
On Thu, Feb 06, 2014 at 07:36:17PM +0900, Magnus Damm wrote:
> On Wed, Feb 5, 2014 at 9:56 AM, Simon Horman <horms@verge.net.au> wrote:
> > Magnus, could you Ack these or otherwise?
> >
> > On Tue, Feb 04, 2014 at 04:23:54PM +0100, Geert Uytterhoeven wrote:
> >> Hi Simon, Magnus,
> >>
> >> This patch series contains SoC and board integration for
> >> 1. RSPI in the r7s72100 aka RZ/A1H SoC on the Genmai reference board,
> >> 2. QSPI in the r8a7791 aka R-Car M2 SoC on the Koelsch reference board.
> >> It was rebased on top of renesas-devel-v3.14-rc1-20140204.
> >>
> >> It was tested on the r7s72100-based Genmai reference board using loopback
> >> mode, and on the r8a7791-based Koelsch reference board using the Spansion
> >> s25fl512s SPI FLASH.
> >>
> >> - [v5 01/11] ARM: shmobile: r7s72100 clock: Add RSPI clocks
> >> - [v5 02/11] ARM: shmobile: genmai legacy: Add RSPI support
> >> - [v3 03/11] ARM: shmobile: genmai defconfig: Enable RSPI
> >> - [v3 04/11] ARM: shmobile: r7s72100 clock: Add RSPI clocks for DT
> >> - [v5 05/11] ARM: shmobile: r7s72100 dtsi: Add RSPI nodes
> >> - [v4 06/11] ARM: shmobile: r8a7791 clock: add QSPI clocks
> >> - [v4 07/11] ARM: shmobile: koelsch legacy: Add QSPI support
> >> - [v4 08/11] ARM: shmobile: koelsch defconfig: Enable RSPI and
> >> - [v3 09/11] ARM: shmobile: r8a7791 dtsi: Add QSPI node
> >> - [v3 10/11] ARM: shmobile: koelsch dts: Add QSPI nodes
> >> - [v2 11/11] ARM: shmobile: lager legacy: Switch QSPI to named IRQs
> >
> > Above I see v2, v3, v4 and v5 patches.
> >
> > While I can make sense of this it makes it cumbersome to refer to the
> > series as a whole.
> >
> > Bob, can you take a look at '"[PATCH 00/11] ARM: shmobile: RSPI RZ and
> > QSPI SoC and board", posted on Tuesday the 2nd, which includes v2, v3,
> > v4 and v5 patches'?
> >
> > What would make my life easier would be if the entire series was v5 and
> > all the patches contained in it were v5. Then I could just ask Bob to look
> > at "[PATCH v5 00/11] ARM: shmobile: RSPI RZ and QSPI SoC and board"
> >
> > There is no Bob but I do ask people these kind of questions :)
>
> Simon, Geert, Bob,
>
> I've now gone through these patches and I think they look great. My
> apologies for slow handling.
>
> Acked-by: Magnus Damm <damm@opensource.se>
Thanks, I have queued these up.
^ permalink raw reply
* [PATCH 2/6] arm64: barriers: make use of barrier options with explicit barriers
From: Will Deacon @ 2014-02-06 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206114130.GJ29446@arm.com>
On Thu, Feb 06, 2014 at 11:41:30AM +0000, Catalin Marinas wrote:
> On Thu, Feb 06, 2014 at 11:30:49AM +0000, Will Deacon wrote:
> > --- a/arch/arm64/include/asm/barrier.h
> > +++ b/arch/arm64/include/asm/barrier.h
> > @@ -20,14 +20,14 @@
> >
> > #ifndef __ASSEMBLY__
> >
> > -#define sev() asm volatile("sev" : : : "memory")
> > +#define sev(l) asm volatile("sev" #l : : : "memory")
>
> Would we actually ever use sev(l) form C? And it's a new instruction
> rather than an argument to the existing sev.
I don't know, but if it's not there then I'm pretty sure people will always
use sev, even if sevl could be used. In fact, sev and sevl are both aliases
of hint, so they're the same instruction with different immediate operands.
Will
^ permalink raw reply
* [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Catalin Marinas @ 2014-02-06 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686253-13436-3-git-send-email-will.deacon@arm.com>
On Thu, Feb 06, 2014 at 11:30:50AM +0000, Will Deacon wrote:
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 341c6016812d..03fe5ef3f2fe 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -662,11 +662,10 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> /*
> * Ensure that stores to Normal memory are visible to the
> * other CPUs before issuing the IPI.
> + *
> + * This always happens on GIC0.
> */
> - dsb();
> -
> - /* this always happens on GIC0 */
> - writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> + writel(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
That's heavier than a dsb() since with outer caches on ARM we also get
an outer_sync() call.
--
Catalin
^ permalink raw reply
* [PATCH 0/2] Add Ether's PHY IRQ support for Lager/Koelsh boards
From: Sergei Shtylyov @ 2014-02-06 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206063423.GB13435@verge.net.au>
Hello.
On 06-02-2014 10:34, Simon Horman wrote:
>>>> Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
>>>> 'renesas-devel-v3.14-rc1-20130204' tag. Here we add support for the Ether's PHY
>>>> IRQ to the R8A7790/Lager and R8A7791/Koelsch boards.
>>>> [1/2] ARM: shmobile: Lager: pass Ether PHY IRQ
>>>> [1/2] ARM: shmobile: Koelsch: pass Ether PHY IRQ
>>> Thanks, looking good!
>> Not at all, you've already tested these patches, IIRC.
> Thanks, I have queued these up with Magnus's ack which
> he supplied the previous time that you posted them.
Oh, sorry, I forgot to pick it up myself. :-/
WBR, Sergei
^ permalink raw reply
* [PATCH 2/6] arm64: barriers: make use of barrier options with explicit barriers
From: Catalin Marinas @ 2014-02-06 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206114559.GM26035@mudshark.cambridge.arm.com>
On Thu, Feb 06, 2014 at 11:45:59AM +0000, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 11:41:30AM +0000, Catalin Marinas wrote:
> > On Thu, Feb 06, 2014 at 11:30:49AM +0000, Will Deacon wrote:
> > > --- a/arch/arm64/include/asm/barrier.h
> > > +++ b/arch/arm64/include/asm/barrier.h
> > > @@ -20,14 +20,14 @@
> > >
> > > #ifndef __ASSEMBLY__
> > >
> > > -#define sev() asm volatile("sev" : : : "memory")
> > > +#define sev(l) asm volatile("sev" #l : : : "memory")
> >
> > Would we actually ever use sev(l) form C? And it's a new instruction
> > rather than an argument to the existing sev.
>
> I don't know, but if it's not there then I'm pretty sure people will always
> use sev, even if sevl could be used. In fact, sev and sevl are both aliases
> of hint, so they're the same instruction with different immediate operands.
SEVL was pretty much introduced to avoid a branch in the spinlock
functions. I'm not aware of other uses (on arm64 we don't even use the
wfe() macro directly). I would skip this for now.
--
Catalin
^ permalink raw reply
* [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Will Deacon @ 2014-02-06 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206114559.GK29446@arm.com>
On Thu, Feb 06, 2014 at 11:45:59AM +0000, Catalin Marinas wrote:
> On Thu, Feb 06, 2014 at 11:30:50AM +0000, Will Deacon wrote:
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index 341c6016812d..03fe5ef3f2fe 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -662,11 +662,10 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> > /*
> > * Ensure that stores to Normal memory are visible to the
> > * other CPUs before issuing the IPI.
> > + *
> > + * This always happens on GIC0.
> > */
> > - dsb();
> > -
> > - /* this always happens on GIC0 */
> > - writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> > + writel(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
>
> That's heavier than a dsb() since with outer caches on ARM we also get
> an outer_sync() call.
Yes, which I think we actually need in this case, since we're trying to make
normal writes visible to a CPU before a device write hits the GIC.
I can update the commit message if you like?
Will
^ permalink raw reply
* [PATCH 4/6] iommu/arm-smmu: provide option to dsb macro when publishing tables
From: Catalin Marinas @ 2014-02-06 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686253-13436-4-git-send-email-will.deacon@arm.com>
On Thu, Feb 06, 2014 at 11:30:51AM +0000, Will Deacon wrote:
> On coherent systems, publishing new page tables to the SMMU walker is
> achieved with a dsb instruction. In fact, this can be a dsb(ishst) which
> also provides the mandatory barrier option for arm64.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] arm64: Change misleading function names in dma-mapping
From: Ritesh Harjani @ 2014-02-06 11:51 UTC (permalink / raw)
To: linux-arm-kernel
From: Ritesh Harjani <ritesh.harjani@gmail.com>
Included changes in the patch based on the suggestion.
Ritesh Harjani (1):
arm64: Change misleading function names in dma-mapping
arch/arm64/mm/dma-mapping.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
1.8.1.3
^ permalink raw reply
* [PATCH] arm64: Change misleading function names in dma-mapping
From: Ritesh Harjani @ 2014-02-06 11:51 UTC (permalink / raw)
To: linux-arm-kernel
From: Ritesh Harjani <ritesh.harjani@gmail.com>
arm64_swiotlb_alloc/free_coherent name can be misleading
somtimes with CMA support being enabled after this
patch (c2104debc235b745265b64d610237a6833fd53)
Change this name to be more generic:
__dma_alloc/free_coherent
Signed-off-by: Ritesh Harjani <ritesh.harjani@gmail.com>
---
arch/arm64/mm/dma-mapping.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 45b5ab5..aee7521 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -30,7 +30,7 @@
struct dma_map_ops *dma_ops;
EXPORT_SYMBOL(dma_ops);
-static void *arm64_swiotlb_alloc_coherent(struct device *dev, size_t size,
+static void *__dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,
struct dma_attrs *attrs)
{
@@ -57,7 +57,7 @@ static void *arm64_swiotlb_alloc_coherent(struct
device *dev, size_t size,
}
}
-static void arm64_swiotlb_free_coherent(struct device *dev, size_t size,
+static void __dma_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
struct dma_attrs *attrs)
{
@@ -78,8 +78,8 @@ static void arm64_swiotlb_free_coherent(struct
device *dev, size_t size,
}
static struct dma_map_ops arm64_swiotlb_dma_ops = {
- .alloc = arm64_swiotlb_alloc_coherent,
- .free = arm64_swiotlb_free_coherent,
+ .alloc = __dma_alloc_coherent,
+ .free = __dma_free_coherent,
.map_page = swiotlb_map_page,
.unmap_page = swiotlb_unmap_page,
.map_sg = swiotlb_map_sg_attrs,
--
1.8.1.3
^ permalink raw reply related
* [PATCH 2/6] arm64: barriers: make use of barrier options with explicit barriers
From: Will Deacon @ 2014-02-06 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206114952.GL29446@arm.com>
On Thu, Feb 06, 2014 at 11:49:52AM +0000, Catalin Marinas wrote:
> On Thu, Feb 06, 2014 at 11:45:59AM +0000, Will Deacon wrote:
> > On Thu, Feb 06, 2014 at 11:41:30AM +0000, Catalin Marinas wrote:
> > > On Thu, Feb 06, 2014 at 11:30:49AM +0000, Will Deacon wrote:
> > > > --- a/arch/arm64/include/asm/barrier.h
> > > > +++ b/arch/arm64/include/asm/barrier.h
> > > > @@ -20,14 +20,14 @@
> > > >
> > > > #ifndef __ASSEMBLY__
> > > >
> > > > -#define sev() asm volatile("sev" : : : "memory")
> > > > +#define sev(l) asm volatile("sev" #l : : : "memory")
> > >
> > > Would we actually ever use sev(l) form C? And it's a new instruction
> > > rather than an argument to the existing sev.
> >
> > I don't know, but if it's not there then I'm pretty sure people will always
> > use sev, even if sevl could be used. In fact, sev and sevl are both aliases
> > of hint, so they're the same instruction with different immediate operands.
>
> SEVL was pretty much introduced to avoid a branch in the spinlock
> functions. I'm not aware of other uses (on arm64 we don't even use the
> wfe() macro directly). I would skip this for now.
Okey doke, I'll drop this hunk for the time being.
Will
^ permalink raw reply
* [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Catalin Marinas @ 2014-02-06 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206115121.GN26035@mudshark.cambridge.arm.com>
On Thu, Feb 06, 2014 at 11:51:21AM +0000, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 11:45:59AM +0000, Catalin Marinas wrote:
> > On Thu, Feb 06, 2014 at 11:30:50AM +0000, Will Deacon wrote:
> > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > > index 341c6016812d..03fe5ef3f2fe 100644
> > > --- a/drivers/irqchip/irq-gic.c
> > > +++ b/drivers/irqchip/irq-gic.c
> > > @@ -662,11 +662,10 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> > > /*
> > > * Ensure that stores to Normal memory are visible to the
> > > * other CPUs before issuing the IPI.
> > > + *
> > > + * This always happens on GIC0.
> > > */
> > > - dsb();
> > > -
> > > - /* this always happens on GIC0 */
> > > - writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> > > + writel(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> >
> > That's heavier than a dsb() since with outer caches on ARM we also get
> > an outer_sync() call.
>
> Yes, which I think we actually need in this case, since we're trying to make
> normal writes visible to a CPU before a device write hits the GIC.
If they are all in the inner shareable domain and with the caches
enabled, we don't need to flush the outer cache (as in the PL310 case
which is common to all CPUs; other saner outer caches propagate the
barrier ;). The outer_sync is needed when the memory accesses are
non-cacheable and we need to drain both the CPU write-buffer and the
PL310 one.
For our case here, we only need to ensure the visibility of writes on a
CPU to another but assuming SMP and caches enabled, so DSB is enough.
--
Catalin
^ permalink raw reply
* [PATCH 5/6] arm64: barriers: wire up new barrier options
From: Catalin Marinas @ 2014-02-06 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686253-13436-5-git-send-email-will.deacon@arm.com>
On Thu, Feb 06, 2014 at 11:30:52AM +0000, Will Deacon wrote:
> Now that all callers of the barrier macros are updated to pass the
> mandatory options, update the macros so the option is actually used.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 6/6] arm64: barriers: use barrier() instead of smp_mb() when !SMP
From: Catalin Marinas @ 2014-02-06 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391686253-13436-6-git-send-email-will.deacon@arm.com>
On Thu, Feb 06, 2014 at 11:30:53AM +0000, Will Deacon wrote:
> The recently introduced acquire/release accessors refer to smp_mb()
> in the !CONFIG_SMP case. This is confusing when reading the code, so use
> barrier() directly when we know we're UP.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Will Deacon @ 2014-02-06 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206115430.GN29446@arm.com>
On Thu, Feb 06, 2014 at 11:54:30AM +0000, Catalin Marinas wrote:
> On Thu, Feb 06, 2014 at 11:51:21AM +0000, Will Deacon wrote:
> > On Thu, Feb 06, 2014 at 11:45:59AM +0000, Catalin Marinas wrote:
> > > On Thu, Feb 06, 2014 at 11:30:50AM +0000, Will Deacon wrote:
> > > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > > > index 341c6016812d..03fe5ef3f2fe 100644
> > > > --- a/drivers/irqchip/irq-gic.c
> > > > +++ b/drivers/irqchip/irq-gic.c
> > > > @@ -662,11 +662,10 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> > > > /*
> > > > * Ensure that stores to Normal memory are visible to the
> > > > * other CPUs before issuing the IPI.
> > > > + *
> > > > + * This always happens on GIC0.
> > > > */
> > > > - dsb();
> > > > -
> > > > - /* this always happens on GIC0 */
> > > > - writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> > > > + writel(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> > >
> > > That's heavier than a dsb() since with outer caches on ARM we also get
> > > an outer_sync() call.
> >
> > Yes, which I think we actually need in this case, since we're trying to make
> > normal writes visible to a CPU before a device write hits the GIC.
>
> If they are all in the inner shareable domain and with the caches
> enabled, we don't need to flush the outer cache (as in the PL310 case
> which is common to all CPUs; other saner outer caches propagate the
> barrier ;). The outer_sync is needed when the memory accesses are
> non-cacheable and we need to drain both the CPU write-buffer and the
> PL310 one.
>
> For our case here, we only need to ensure the visibility of writes on a
> CPU to another but assuming SMP and caches enabled, so DSB is enough.
Hmm, but we *do* use this for boot and need to ensure that any mailboxes are
visible. Maybe we have enough cacheflushing/barriers for that already, but
I'm really uncomfortable making this a simple dsb(ishst).
Will
^ permalink raw reply
* [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Catalin Marinas @ 2014-02-06 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206115739.GP26035@mudshark.cambridge.arm.com>
On Thu, Feb 06, 2014 at 11:57:39AM +0000, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 11:54:30AM +0000, Catalin Marinas wrote:
> > On Thu, Feb 06, 2014 at 11:51:21AM +0000, Will Deacon wrote:
> > > On Thu, Feb 06, 2014 at 11:45:59AM +0000, Catalin Marinas wrote:
> > > > On Thu, Feb 06, 2014 at 11:30:50AM +0000, Will Deacon wrote:
> > > > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > > > > index 341c6016812d..03fe5ef3f2fe 100644
> > > > > --- a/drivers/irqchip/irq-gic.c
> > > > > +++ b/drivers/irqchip/irq-gic.c
> > > > > @@ -662,11 +662,10 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> > > > > /*
> > > > > * Ensure that stores to Normal memory are visible to the
> > > > > * other CPUs before issuing the IPI.
> > > > > + *
> > > > > + * This always happens on GIC0.
> > > > > */
> > > > > - dsb();
> > > > > -
> > > > > - /* this always happens on GIC0 */
> > > > > - writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> > > > > + writel(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> > > >
> > > > That's heavier than a dsb() since with outer caches on ARM we also get
> > > > an outer_sync() call.
> > >
> > > Yes, which I think we actually need in this case, since we're trying to make
> > > normal writes visible to a CPU before a device write hits the GIC.
> >
> > If they are all in the inner shareable domain and with the caches
> > enabled, we don't need to flush the outer cache (as in the PL310 case
> > which is common to all CPUs; other saner outer caches propagate the
> > barrier ;). The outer_sync is needed when the memory accesses are
> > non-cacheable and we need to drain both the CPU write-buffer and the
> > PL310 one.
> >
> > For our case here, we only need to ensure the visibility of writes on a
> > CPU to another but assuming SMP and caches enabled, so DSB is enough.
>
> Hmm, but we *do* use this for boot and need to ensure that any mailboxes are
> visible. Maybe we have enough cacheflushing/barriers for that already, but
> I'm really uncomfortable making this a simple dsb(ishst).
For boot we explicitly flush the caches for the shared data, so we don't
need this. The dsb() here is for standard smp_call_* etc. We didn't have
outer_sync() before, so you are slightly changing the functionality here
(arguably, ishst is relaxing the requirements but I'm not worried about
this, I consider that's the standard use-case for this function).
--
Catalin
^ permalink raw reply
* [PATCH 1/3] mmc: tmio-mmc: add DMA SG synchronisation
From: Ben Dooks @ 2014-02-06 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1401311248320.3234@axis700.grange>
On 31/01/14 11:54, Guennadi Liakhovetski wrote:
> According to the DMA API data has to be synchronised before starting
> a DMA transfer to device and after completing a DMA transfer from device.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
I've got 1/3 and 2/3, but not 3/3 ?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ 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