* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-23 10:46 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland, devicetree, jlu, linux-edac, linux-kernel, robh+dt,
james.morse, Gregory CLEMENT, bp, mchehab, linux-arm-kernel,
patches
In-Reply-To: <20190712034904.5747-2-chris.packham@alliedtelesis.co.nz>
On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> From: Jan Luebbe <jlu@pengutronix.de>
>
> The macro name is too generic, so add a AURORA_ prefix.
>
> Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
I can't apply this series - this file does not exist in my tree, and
from what git tells me, it never has existed. Maybe it's in someone
elses tree?
> arch/arm/mm/cache-l2x0.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> index c86124769831..dc5c479ec4c3 100644
> --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> @@ -41,7 +41,7 @@
> #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
> (2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
>
> -#define MAX_RANGE_SIZE 1024
> +#define AURORA_MAX_RANGE_SIZE 1024
>
> #define AURORA_WAY_SIZE_SHIFT 2
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 428d08718107..83b733a1f1e6 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1352,8 +1352,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
> * since cache range operations stall the CPU pipeline
> * until completion.
> */
> - if (end > start + MAX_RANGE_SIZE)
> - end = start + MAX_RANGE_SIZE;
> + if (end > start + AURORA_MAX_RANGE_SIZE)
> + end = start + AURORA_MAX_RANGE_SIZE;
>
> /*
> * Cache range operations can't straddle a page boundary.
> --
> 2.22.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in 5.3-rc1 and later
From: Vincenzo Frascino @ 2019-08-23 10:43 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Chris Clayton
Cc: linux-arch, linux-mips, linux-kselftest, arnd, huw,
andre.przywara, daniel.lezcano, will.deacon, LKML, ralf, salyzyn,
paul.burton, linux, 0x7f454c46, catalin.marinas, pcc, tglx,
sthotton, shuah, linux-arm-kernel
In-Reply-To: <20190823103654.GX13294@shell.armlinux.org.uk>
Hi Russell,
On 8/23/19 11:36 AM, Russell King - ARM Linux admin wrote:
> Hi,
>
> To everyone on the long Cc list...
>
> What's happening with this? I was about to merge the patches for 32-bit
> ARM, which I don't want to do if doing so will cause this regression on
> 32-bit ARM as well.
>
The regression is sorted as of yesterday, a new patch is going through tip:
timers/urgent and will be part of the next -rc.
If you want to merge them there should be nothing blocking.
> Thanks.
>
> On Thu, Aug 22, 2019 at 07:57:59AM +0100, Chris Clayton wrote:
>> Hi everyone,
>>
>> Firstly, apologies to anyone on the long cc list that turns out not to be particularly interested in the following, but
>> you were all marked as cc'd in the commit message below.
>>
>> I've found a problem that isn't present in 5.2 series or 4.19 series kernels, and seems to have arrived in 5.3-rc1. The
>> problem is that if I suspend (to ram) my laptop, on resume 14 minutes or more after suspending, I have no networking
>> functionality. If I resume the laptop after 13 minutes or less, networking works fine. I haven't tried to get finer
>> grained timings between 13 and 14 minutes, but can do if it would help.
>>
>> ifconfig shows that wlan0 is still up and still has its assigned ip address but, for instance, a ping of any other
>> device on my network, fails as does pinging, say, kernel.org. I've tried "downing" the network with (/sbin/ifdown) and
>> unloading the iwlmvm module and then reloading the module and "upping" (/sbin/ifup) the network, but my network is still
>> unusable. I should add that the problem also manifests if I hibernate the laptop, although my testing of this has been
>> minimal. I can do more if required.
>>
>> As I say, the problem first appears in 5.3-rc1, so I've bisected between 5.2.0 and 5.3-rc1 and that concluded with:
>>
>> [chris:~/kernel/linux]$ git bisect good
>> 7ac8707479886c75f353bfb6a8273f423cfccb23 is the first bad commit
>> commit 7ac8707479886c75f353bfb6a8273f423cfccb23
>> Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
>> Date: Fri Jun 21 10:52:49 2019 +0100
>>
>> x86/vdso: Switch to generic vDSO implementation
>>
>> The x86 vDSO library requires some adaptations to take advantage of the
>> newly introduced generic vDSO library.
>>
>> Introduce the following changes:
>> - Modification of vdso.c to be compliant with the common vdso datapage
>> - Use of lib/vdso for gettimeofday
>>
>> [ tglx: Massaged changelog and cleaned up the function signature formatting ]
>>
>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> Cc: linux-arch@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-mips@vger.kernel.org
>> Cc: linux-kselftest@vger.kernel.org
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Cc: Ralf Baechle <ralf@linux-mips.org>
>> Cc: Paul Burton <paul.burton@mips.com>
>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>> Cc: Mark Salyzyn <salyzyn@android.com>
>> Cc: Peter Collingbourne <pcc@google.com>
>> Cc: Shuah Khan <shuah@kernel.org>
>> Cc: Dmitry Safonov <0x7f454c46@gmail.com>
>> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>> Cc: Huw Davies <huw@codeweavers.com>
>> Cc: Shijith Thotton <sthotton@marvell.com>
>> Cc: Andre Przywara <andre.przywara@arm.com>
>> Link: https://lkml.kernel.org/r/20190621095252.32307-23-vincenzo.frascino@arm.com
>>
>> arch/x86/Kconfig | 3 +
>> arch/x86/entry/vdso/Makefile | 9 ++
>> arch/x86/entry/vdso/vclock_gettime.c | 245 ++++---------------------------
>> arch/x86/entry/vdso/vdsox32.lds.S | 1 +
>> arch/x86/entry/vsyscall/Makefile | 2 -
>> arch/x86/entry/vsyscall/vsyscall_gtod.c | 83 -----------
>> arch/x86/include/asm/pvclock.h | 2 +-
>> arch/x86/include/asm/vdso/gettimeofday.h | 191 ++++++++++++++++++++++++
>> arch/x86/include/asm/vdso/vsyscall.h | 44 ++++++
>> arch/x86/include/asm/vgtod.h | 75 +---------
>> arch/x86/include/asm/vvar.h | 7 +-
>> arch/x86/kernel/pvclock.c | 1 +
>> 12 files changed, 284 insertions(+), 379 deletions(-)
>> delete mode 100644 arch/x86/entry/vsyscall/vsyscall_gtod.c
>> create mode 100644 arch/x86/include/asm/vdso/gettimeofday.h
>> create mode 100644 arch/x86/include/asm/vdso/vsyscall.h
>>
>> To confirm my bisection was correct, I did a git checkout of 7ac8707479886c75f353bfb6a8273f423cfccb2. As expected, the
>> kernel exhibited the problem I've described. However, a kernel built at the immediately preceding (parent?) commit
>> (bfe801ebe84f42b4666d3f0adde90f504d56e35b) has a working network after a (>= 14minute) suspend/resume cycle.
>>
>> As the module name implies, I'm using wireless networking. The hardware is detected as "Intel(R) Wireless-AC 9260
>> 160MHz, REV=0x324" by iwlwifi.
>>
>> I'm more than happy to provide additional diagnostics (but may need a little hand-holding) and to apply diagnostic or
>> fix patches, but please cc me on any reply as I'm not subscribed to any of the kernel-related mailing lists.
>>
>> Chris
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
--
Regards,
Vincenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in 5.3-rc1 and later
From: Will Deacon @ 2019-08-23 10:40 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux, catalin.marinas, will.deacon, LKML, linux-kselftest,
vincenzo.frascino, shuah, linux-arch, daniel.lezcano, arnd,
andre.przywara, Chris Clayton, 0x7f454c46, tglx, pcc,
linux-arm-kernel, huw, linux-mips, ralf, salyzyn, paul.burton,
sthotton
In-Reply-To: <20190823103654.GX13294@shell.armlinux.org.uk>
On Fri, Aug 23, 2019 at 11:36:54AM +0100, Russell King - ARM Linux admin wrote:
> To everyone on the long Cc list...
>
> What's happening with this? I was about to merge the patches for 32-bit
> ARM, which I don't want to do if doing so will cause this regression on
> 32-bit ARM as well.
tglx fixed it:
https://lkml.kernel.org/r/alpine.DEB.2.21.1908221257580.1983@nanos.tec.linutronix.de
which I assume is getting routed as a fix via -tip.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in 5.3-rc1 and later
From: Russell King - ARM Linux admin @ 2019-08-23 10:36 UTC (permalink / raw)
To: Chris Clayton
Cc: linux-arch, vincenzo.frascino, linux-mips, linux-kselftest, arnd,
huw, andre.przywara, daniel.lezcano, will.deacon, LKML, ralf,
salyzyn, paul.burton, linux, 0x7f454c46, catalin.marinas, pcc,
tglx, sthotton, shuah, linux-arm-kernel
In-Reply-To: <faaa3843-09a6-1a21-3448-072eeed1ea00@googlemail.com>
Hi,
To everyone on the long Cc list...
What's happening with this? I was about to merge the patches for 32-bit
ARM, which I don't want to do if doing so will cause this regression on
32-bit ARM as well.
Thanks.
On Thu, Aug 22, 2019 at 07:57:59AM +0100, Chris Clayton wrote:
> Hi everyone,
>
> Firstly, apologies to anyone on the long cc list that turns out not to be particularly interested in the following, but
> you were all marked as cc'd in the commit message below.
>
> I've found a problem that isn't present in 5.2 series or 4.19 series kernels, and seems to have arrived in 5.3-rc1. The
> problem is that if I suspend (to ram) my laptop, on resume 14 minutes or more after suspending, I have no networking
> functionality. If I resume the laptop after 13 minutes or less, networking works fine. I haven't tried to get finer
> grained timings between 13 and 14 minutes, but can do if it would help.
>
> ifconfig shows that wlan0 is still up and still has its assigned ip address but, for instance, a ping of any other
> device on my network, fails as does pinging, say, kernel.org. I've tried "downing" the network with (/sbin/ifdown) and
> unloading the iwlmvm module and then reloading the module and "upping" (/sbin/ifup) the network, but my network is still
> unusable. I should add that the problem also manifests if I hibernate the laptop, although my testing of this has been
> minimal. I can do more if required.
>
> As I say, the problem first appears in 5.3-rc1, so I've bisected between 5.2.0 and 5.3-rc1 and that concluded with:
>
> [chris:~/kernel/linux]$ git bisect good
> 7ac8707479886c75f353bfb6a8273f423cfccb23 is the first bad commit
> commit 7ac8707479886c75f353bfb6a8273f423cfccb23
> Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Date: Fri Jun 21 10:52:49 2019 +0100
>
> x86/vdso: Switch to generic vDSO implementation
>
> The x86 vDSO library requires some adaptations to take advantage of the
> newly introduced generic vDSO library.
>
> Introduce the following changes:
> - Modification of vdso.c to be compliant with the common vdso datapage
> - Use of lib/vdso for gettimeofday
>
> [ tglx: Massaged changelog and cleaned up the function signature formatting ]
>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mips@vger.kernel.org
> Cc: linux-kselftest@vger.kernel.org
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Paul Burton <paul.burton@mips.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Mark Salyzyn <salyzyn@android.com>
> Cc: Peter Collingbourne <pcc@google.com>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Dmitry Safonov <0x7f454c46@gmail.com>
> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Cc: Huw Davies <huw@codeweavers.com>
> Cc: Shijith Thotton <sthotton@marvell.com>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Link: https://lkml.kernel.org/r/20190621095252.32307-23-vincenzo.frascino@arm.com
>
> arch/x86/Kconfig | 3 +
> arch/x86/entry/vdso/Makefile | 9 ++
> arch/x86/entry/vdso/vclock_gettime.c | 245 ++++---------------------------
> arch/x86/entry/vdso/vdsox32.lds.S | 1 +
> arch/x86/entry/vsyscall/Makefile | 2 -
> arch/x86/entry/vsyscall/vsyscall_gtod.c | 83 -----------
> arch/x86/include/asm/pvclock.h | 2 +-
> arch/x86/include/asm/vdso/gettimeofday.h | 191 ++++++++++++++++++++++++
> arch/x86/include/asm/vdso/vsyscall.h | 44 ++++++
> arch/x86/include/asm/vgtod.h | 75 +---------
> arch/x86/include/asm/vvar.h | 7 +-
> arch/x86/kernel/pvclock.c | 1 +
> 12 files changed, 284 insertions(+), 379 deletions(-)
> delete mode 100644 arch/x86/entry/vsyscall/vsyscall_gtod.c
> create mode 100644 arch/x86/include/asm/vdso/gettimeofday.h
> create mode 100644 arch/x86/include/asm/vdso/vsyscall.h
>
> To confirm my bisection was correct, I did a git checkout of 7ac8707479886c75f353bfb6a8273f423cfccb2. As expected, the
> kernel exhibited the problem I've described. However, a kernel built at the immediately preceding (parent?) commit
> (bfe801ebe84f42b4666d3f0adde90f504d56e35b) has a working network after a (>= 14minute) suspend/resume cycle.
>
> As the module name implies, I'm using wireless networking. The hardware is detected as "Intel(R) Wireless-AC 9260
> 160MHz, REV=0x324" by iwlwifi.
>
> I'm more than happy to provide additional diagnostics (but may need a little hand-holding) and to apply diagnostic or
> fix patches, but please cc me on any reply as I'm not subscribed to any of the kernel-related mailing lists.
>
> Chris
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] KVM: arm: VGIC: properly initialise private IRQ affinity
From: Andre Przywara @ 2019-08-23 10:34 UTC (permalink / raw)
To: Marc Zyngier, Christoffer Dall
Cc: Zenghui Yu, Julien Grall, Dave Martin, linux-arm-kernel, kvmarm
At the moment we initialise the target *mask* of a virtual IRQ to the
VCPU it belongs to, even though this mask is only defined for GICv2 and
quickly runs out of bits for many GICv3 guests.
This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
------
[ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
[ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
------
Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
dump is wrong, due to this very same problem.
Because there is no requirement to create the VGIC device before the
VCPUs (and QEMU actually does it the other way round), we can't safely
initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch
every private IRQ for each VCPU anyway later (in vgic_init()), we can
just move the initialisation of those fields into there, where we
definitely know the VGIC type.
On the way make sure we really have either a VGICv2 or a VGICv3 device,
since the existing code is just checking for "VGICv3 or not", silently
ignoring the uninitialised case.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Dave Martin <dave.martin@arm.com>
---
Changelog v2 .. v3:
- replace BUG_ON() with error return
Changelog v1 .. v2:
- drop private IRQ initialisation in kvm_vgic_vcpu_init()
- initialise private IRQs in vgic_init()
- explicitly checking for VGIC device being v2 or v3
virt/kvm/arm/vgic/vgic-init.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 80127ca9269f..d67047fb261b 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -8,6 +8,7 @@
#include <linux/cpu.h>
#include <linux/kvm_host.h>
#include <kvm/arm_vgic.h>
+#include <asm/kvm_emulate.h>
#include <asm/kvm_mmu.h>
#include "vgic.h"
@@ -165,12 +166,18 @@ static int kvm_vgic_dist_init(struct kvm *kvm, unsigned int nr_spis)
irq->vcpu = NULL;
irq->target_vcpu = vcpu0;
kref_init(&irq->refcount);
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V2) {
+ switch (dist->vgic_model) {
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
irq->targets = 0;
irq->group = 0;
- } else {
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
irq->mpidr = 0;
irq->group = 1;
+ break;
+ default:
+ kfree(dist->spis);
+ return -EINVAL;
}
}
return 0;
@@ -210,7 +217,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
irq->intid = i;
irq->vcpu = NULL;
irq->target_vcpu = vcpu;
- irq->targets = 1U << vcpu->vcpu_id;
kref_init(&irq->refcount);
if (vgic_irq_is_sgi(i)) {
/* SGIs */
@@ -220,11 +226,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
/* PPIs */
irq->config = VGIC_CONFIG_LEVEL;
}
-
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
- irq->group = 1;
- else
- irq->group = 0;
}
if (!irqchip_in_kernel(vcpu->kvm))
@@ -287,10 +288,19 @@ int vgic_init(struct kvm *kvm)
for (i = 0; i < VGIC_NR_PRIVATE_IRQS; i++) {
struct vgic_irq *irq = &vgic_cpu->private_irqs[i];
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
+ switch (dist->vgic_model) {
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
irq->group = 1;
- else
+ irq->mpidr = kvm_vcpu_get_mpidr_aff(vcpu);
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
irq->group = 0;
+ irq->targets = 1U << idx;
+ break;
+ default:
+ ret = -EINVAL;
+ goto out;
+ }
}
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3] ARM: ftrace: remove mcount(),ftrace_caller_old() and ftrace_call_old()
From: Jisheng Zhang @ 2019-08-23 10:33 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar, Russell King
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Commit d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support")
removed the old mcount support, but forget to remove these three
declarations. This patch removes them.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
Changes since v2:
- really remove mcount() declaration too. I made a mistake when sending out v2
Changes since v1:
- remove mcount() declaration too
arch/arm/include/asm/ftrace.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index 18b0197f2384..48ec1d0337da 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -11,7 +11,6 @@
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
#ifndef __ASSEMBLY__
-extern void mcount(void);
extern void __gnu_mcount_nc(void);
#ifdef CONFIG_DYNAMIC_FTRACE
@@ -23,9 +22,6 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
/* With Thumb-2, the recorded addresses have the lsb set */
return addr & ~1;
}
-
-extern void ftrace_caller_old(void);
-extern void ftrace_call_old(void);
#endif
#endif
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 04/10] KVM: Implement kvm_put_guest()
From: Steven Price @ 2019-08-23 10:33 UTC (permalink / raw)
To: Sean Christopherson
Cc: Mark Rutland, Radim Krčmář, kvm, Suzuki K Pouloze,
Marc Zyngier, linux-doc, Russell King, linux-kernel, James Morse,
linux-arm-kernel, Catalin Marinas, Paolo Bonzini, Will Deacon,
kvmarm, Julien Thierry
In-Reply-To: <20190822162449.GF25467@linux.intel.com>
On 22/08/2019 17:24, Sean Christopherson wrote:
> On Thu, Aug 22, 2019 at 04:46:10PM +0100, Steven Price wrote:
>> On 22/08/2019 16:28, Sean Christopherson wrote:
>>> On Wed, Aug 21, 2019 at 04:36:50PM +0100, Steven Price wrote:
>>>> kvm_put_guest() is analogous to put_user() - it writes a single value to
>>>> the guest physical address. The implementation is built upon put_user()
>>>> and so it has the same single copy atomic properties.
>>>
>>> What you mean by "single copy atomic"? I.e. what guarantees does
>>> put_user() provide that __copy_to_user() does not?
>>
>> Single-copy atomicity is defined by the Arm architecture[1] and I'm not
>> going to try to go into the full details here, so this is a summary.
>>
>> For the sake of this feature what we care about is that the value
>> written/read cannot be "torn". In other words if there is a read (in
>> this case from another VCPU) that is racing with the write then the read
>> will either get the old value or the new value. It cannot return a
>> mixture. (This is of course assuming that the read is using a
>> single-copy atomic safe method).
>
> Thanks for the explanation. I assumed that's what you were referring to,
> but wanted to double check.
>
>> __copy_to_user() is implemented as a memcpy() and as such cannot provide
>> single-copy atomicity in the general case (the buffer could easily be
>> bigger than the architecture can guarantee).
>>
>> put_user() on the other hand is implemented (on arm64) as an explicit
>> store instruction and therefore is guaranteed by the architecture to be
>> single-copy atomic (i.e. another CPU cannot see a half-written value).
>
> I don't think kvm_put_guest() belongs in generic code, at least not with
> the current changelog explanation about it providing single-copy atomic
> semantics. AFAICT, the single-copy thing is very much an arm64
> implementation detail, e.g. the vast majority of 32-bit architectures,
> including x86, do not provide any guarantees, and x86-64 generates more
> or less the same code for put_user() and __copy_to_user() for 8-byte and
> smaller accesses.
>
> As an alternative to kvm_put_guest() entirely, is it an option to change
> arm64's raw_copy_to_user() to redirect to __put_user() for sizes that are
> constant at compile time and can be handled by __put_user()? That would
> allow using kvm_write_guest() to update stolen time, albeit with
> arguably an even bigger dependency on the uaccess implementation details.
I think it's important to in some way ensure that the desire that this
is a single write is shown. copy_to_user() is effectively
"setup();memcpy();finish();" and while a good memcpy() implementation
would be identical to put_user() there's a lot more room for this being
broken in the future by changes to the memcpy() implementation. (And I
don't want to require that memcpy() has to detect this case).
One suggestion is to call it something like kvm_put_guest_atomic() to
reflect the atomicity requirement. Presumably that would be based on a
new put_user_atomic() which architectures could override as necessary if
put_user() doesn't provide the necessary guarantees.
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND PATCH 5/5] arm64: dts: allwinner: orange-pi-3: Enable UART1 / Bluetooth
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
The board contains AP6256 WiFi/BT module that has its bluetooth part
connected to SoC's UART1 port. Enable this port, and add node for the
bluetooth device.
Bluetooth part is named bcm4345c5.
You'll need a BCM4345C5.hcd firmware file that can be found in the
Xulongs's repository for H6:
https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
The driver expects the firmware at the following path relative to the
firmware directory:
brcm/BCM4345C5.hcd
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 49d954369087..a9e776446c35 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -15,6 +15,7 @@
aliases {
serial0 = &uart0;
+ serial1 = &uart1;
};
chosen {
@@ -271,6 +272,24 @@
status = "okay";
};
+/* There's the BT part of the AP6256 connected to that UART */
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&rtc 1>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&r_pio 1 2 GPIO_ACTIVE_HIGH>; /* PM2 */
+ host-wakeup-gpios = <&r_pio 1 1 GPIO_ACTIVE_HIGH>; /* PM1 */
+ shutdown-gpios = <&r_pio 1 4 GPIO_ACTIVE_HIGH>; /* PM4 */
+ max-speed = <1500000>;
+ };
+};
+
&usb2otg {
/*
* This board doesn't have a controllable VBUS even though it
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 2/5] bluetooth: bcm: Add support for loading firmware for BCM4345C5
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Detect BCM4345C5 and load a corresponding firmware file.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
Checkpatch reports a spurious error.
drivers/bluetooth/btbcm.c | 3 +++
drivers/bluetooth/hci_bcm.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index 124ef0a3e1dd..2d2e6d862068 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -23,6 +23,7 @@
#define BDADDR_BCM43430A0 (&(bdaddr_t) {{0xac, 0x1f, 0x12, 0xa0, 0x43, 0x43}})
#define BDADDR_BCM4324B3 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb3, 0x24, 0x43}})
#define BDADDR_BCM4330B1 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb1, 0x30, 0x43}})
+#define BDADDR_BCM4345C5 (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0xc5, 0x45, 0x43}})
#define BDADDR_BCM43341B (&(bdaddr_t) {{0xac, 0x1f, 0x00, 0x1b, 0x34, 0x43}})
int btbcm_check_bdaddr(struct hci_dev *hdev)
@@ -73,6 +74,7 @@ int btbcm_check_bdaddr(struct hci_dev *hdev)
!bacmp(&bda->bdaddr, BDADDR_BCM2076B1) ||
!bacmp(&bda->bdaddr, BDADDR_BCM4324B3) ||
!bacmp(&bda->bdaddr, BDADDR_BCM4330B1) ||
+ !bacmp(&bda->bdaddr, BDADDR_BCM4345C5) ||
!bacmp(&bda->bdaddr, BDADDR_BCM43430A0) ||
!bacmp(&bda->bdaddr, BDADDR_BCM43341B)) {
bt_dev_info(hdev, "BCM: Using default device address (%pMR)",
@@ -332,6 +334,7 @@ static const struct bcm_subver_table bcm_uart_subver_table[] = {
{ 0x2122, "BCM4343A0" }, /* 001.001.034 */
{ 0x2209, "BCM43430A1" }, /* 001.002.009 */
{ 0x6119, "BCM4345C0" }, /* 003.001.025 */
+ { 0x6606, "BCM4345C5" }, /* 003.006.006 */
{ 0x230f, "BCM4356A2" }, /* 001.003.015 */
{ 0x220e, "BCM20702A1" }, /* 001.002.014 */
{ 0x4217, "BCM4329B1" }, /* 002.002.023 */
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 4d9de20bab7b..95c312ae94cf 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -1419,6 +1419,7 @@ static void bcm_serdev_remove(struct serdev_device *serdev)
#ifdef CONFIG_OF
static const struct of_device_id bcm_bluetooth_of_match[] = {
{ .compatible = "brcm,bcm20702a1" },
+ { .compatible = "brcm,bcm4345c5" },
{ .compatible = "brcm,bcm4330-bt" },
{ .compatible = "brcm,bcm43438-bt" },
{ },
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 3/5] bluetooth: hci_bcm: Give more time to come out of reset
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Some supported devices need more time to come out of reset (eg.
BCM4345C5 in AP6256).
I don't have/found a datasheet, so the value was arrive at
experimentally with the Oprange Pi 3 board. Without increased delay,
I got intermittent failures during probe. This is a Bluetooth 5.0
device, so maybe that's why it takes longer to initialize than the
others.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
drivers/bluetooth/hci_bcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 95c312ae94cf..7646636f2d18 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -260,7 +260,7 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool powered)
}
/* wait for device to power on and come out of reset */
- usleep_range(10000, 20000);
+ usleep_range(100000, 120000);
dev->res_enabled = powered;
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 4/5] arm64: dts: allwinner: h6: Add pin configs for uart1
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 uses UART1 for bluetooth. Add pinconfigs so that we can use
them.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 67f920e0fc33..7657e816096b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -298,6 +298,16 @@
pins = "PH0", "PH1";
function = "uart0";
};
+
+ uart1_pins: uart1-pins {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_rts_cts_pins: uart1-rts-cts-pins {
+ pins = "PG8", "PG9";
+ function = "uart1";
+ };
};
gic: interrupt-controller@3021000 {
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 1/5] dt-bindings: net: Add compatible for BCM4345C5 bluetooth device
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
In-Reply-To: <20190823103139.17687-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
This is present in the AP6526 WiFi/Bluetooth 5.0 module.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
Documentation/devicetree/bindings/net/broadcom-bluetooth.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
index c26f4e11037c..4fa00e2eafcf 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
+++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
@@ -13,6 +13,7 @@ Required properties:
* "brcm,bcm20702a1"
* "brcm,bcm4330-bt"
* "brcm,bcm43438-bt"
+ * "brcm,bcm4345c5"
Optional properties:
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND PATCH 0/5] Add bluetooth support for Orange Pi 3
From: megous @ 2019-08-23 10:31 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Marcel Holtmann,
Johan Hedberg
Cc: Mark Rutland, devicetree, Ondrej Jirman, netdev, linux-kernel,
linux-bluetooth, David S. Miller, linux-arm-kernel
From: Ondrej Jirman <megous@megous.com>
(Resend to add missing lists, sorry for the noise.)
This series implements bluetooth support for Xunlong Orange Pi 3 board.
The board uses AP6256 WiFi/BT 5.0 chip.
Summary of changes:
- add more delay to let initialize the chip
- let the kernel detect firmware file path
- add new compatible and update dt-bindings
- update Orange Pi 3 / H6 DTS
Please take a look.
thank you and regards,
Ondrej Jirman
Ondrej Jirman (5):
dt-bindings: net: Add compatible for BCM4345C5 bluetooth device
bluetooth: bcm: Add support for loading firmware for BCM4345C5
bluetooth: hci_bcm: Give more time to come out of reset
arm64: dts: allwinner: h6: Add pin configs for uart1
arm64: dts: allwinner: orange-pi-3: Enable UART1 / Bluetooth
.../bindings/net/broadcom-bluetooth.txt | 1 +
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 19 +++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++++++++++
drivers/bluetooth/btbcm.c | 3 +++
drivers/bluetooth/hci_bcm.c | 3 ++-
5 files changed, 35 insertions(+), 1 deletion(-)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] ARM: ftrace: remove mcount(),ftrace_caller_old() and ftrace_call_old()
From: Jisheng Zhang @ 2019-08-23 10:30 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar, Russell King
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Commit d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support")
removed the old mcount support, but forget to remove these three
declarations. This patch removes them.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
Changes since v1:
- remove mcount() declaration too
arch/arm/include/asm/ftrace.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index 18b0197f2384..f67596427971 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -23,9 +23,6 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
/* With Thumb-2, the recorded addresses have the lsb set */
return addr & ~1;
}
-
-extern void ftrace_caller_old(void);
-extern void ftrace_call_old(void);
#endif
#endif
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [v1] arm64: dts: ls1028a: Remove some fixed-clock definiation
From: Wen He @ 2019-08-23 10:17 UTC (permalink / raw)
To: linux-devel, Rob Herring, Mark Rutland, Shawn Guo, devicetree,
linux-kernel, linux-arm-kernel
Cc: Wen He, leoyang.li
Replace pclk/aclk/mclk fixed-clock clock provider with platform clockgen
pre-divider provider, those clocks should be driven by the CGA_PLL2/2.
More details please refer Reference Manual.
Signed-off-by: Wen He <wen.he_1@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 024d6fbd07ea..0fa3e29cb603 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -90,20 +90,6 @@
clocks = <&osc_27m>;
};
- aclk: clock-axi {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <650000000>;
- clock-output-names= "aclk";
- };
-
- pclk: clock-apb {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <650000000>;
- clock-output-names= "pclk";
- };
-
reboot {
compatible ="syscon-reboot";
regmap = <&dcfg>;
@@ -885,7 +871,8 @@
interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
<0 223 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "DE", "SE";
- clocks = <&dpclk>, <&aclk>, <&aclk>, <&pclk>;
+ clocks = <&dpclk>, <&clockgen 2 2>, <&clockgen 2 2>,
+ <&clockgen 2 2>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
arm,malidp-arqos-value = <0xd000d000>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Ondřej Jirman @ 2019-08-23 10:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190823100807.22heh2gahi7owo4e@flea>
Hello Maxime,
On Fri, Aug 23, 2019 at 12:08:07PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Fri, Aug 23, 2019 at 11:42:28AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
> > bcm43356 and can be used with the brcmfmac driver. The module is powered by
> > the two always on regulators (not AXP805).
> >
> > WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> > configured so that it sets up an 1.8V input bias on this port. This is done
> > by the pio driver by reading the vcc-pg-supply voltage.
> >
> > You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> > configuration that can be found in the Xulongs's repository for H6:
> >
> > https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
> >
> > Mainline brcmfmac driver expects the firmware and nvram at the following
> > paths relative to the firmware directory:
> >
> > brcm/brcmfmac43456-sdio.bin
> > brcm/brcmfmac43456-sdio.txt
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> >
> > Since RTC patches for H6 were merged, this can now go in too, if it looks ok.
> >
> > Other patches for this WiFi chip support were merged in previous cycles,
> > so this just needs enabling in DTS now.
> >
> > Sorry for the links in the commit log, but this information is useful,
> > even if the link itself goes bad. Any pointer what to google for
> > (file names, tree name) is great for anyone searching in the future.
>
> I understand, but this should (also?) be in the wiki. Please add it
> there too.
Added. Thank you.
http://linux-sunxi.org/Xunlong_Orange_Pi_3#Firmware_files
regards,
Ondrej
> > Please take a look.
> >
> > Thank you,
> > Ondrej
> >
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index eda9d5f640b9..49d954369087 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -56,6 +56,34 @@
> > regulator-max-microvolt = <5000000>;
> > regulator-always-on;
> > };
> > +
> > + reg_vcc33_wifi: vcc33-wifi {
> > + /* Always on 3.3V regulator for WiFi and BT */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc33-wifi";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc5v>;
> > + };
> > +
> > + reg_vcc_wifi_io: vcc-wifi-io {
> > + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-wifi-io";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc33_wifi>;
> > + };
> > +
> > + wifi_pwrseq: wifi_pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + clocks = <&rtc 1>;
> > + clock-names = "ext_clock";
> > + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> > + post-power-on-delay-ms = <200>;
> > + };
> > };
> >
> > &cpu0 {
> > @@ -91,6 +119,25 @@
> > status = "okay";
> > };
> >
> > +&mmc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
>
> This is the default already. I've removed it and applied.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/7] media: use the BIT() macro
From: Sylwester Nawrocki @ 2019-08-23 10:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Media Mailing List
Cc: Kate Stewart, Richard Fontana, Lad, Prabhakar, Thierry Reding,
Bluecherry Maintainers, Krzysztof Kozlowski, devel,
linux-samsung-soc, Michal Simek, Andrey Utkin, Jonathan Hunter,
Kukjin Kim, linux-arm-kernel, Ismael Luceno,
Mauro Carvalho Chehab, Benoit Parrot, linux-tegra,
Thomas Gleixner, Anton Sviridenko, Allison Randal, Andy Walls,
Hyun Kwon, Greg Kroah-Hartman, linux-renesas-soc, Kyungmin Park,
Kieran Bingham, Sakari Ailus, Hans Verkuil, Laurent Pinchart
In-Reply-To: <d6c04bf604084af63fec603b4afbd72c648e0394.1566553525.git.mchehab+samsung@kernel.org>
On 8/23/19 11:47, Mauro Carvalho Chehab wrote:
> There are lots of places where we're doing 1 << 31. That's bad,
> as, depending on the architecture, this has an undefined behavior.
>
> The BIT() macro is already prepared to handle this, so, let's
> just switch all "1 << number" macros by BIT(number) at the header files
> with has 1 << 31.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> v2:
> As suggested by Laurent:
> - Don't touch multi-bit masks
> - remove explicit casts
For:
drivers/media/platform/exynos4-is/fimc-lite-reg.h
drivers/media/platform/exynos4-is/fimc-reg.h
drivers/media/platform/s3c-camif/camif-regs.h
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] fix usb2 on rock64
From: Dan Johansen @ 2019-08-23 9:56 UTC (permalink / raw)
To: Tomohiro Mayama; +Cc: linux-rockchip, linux-arm-kernel
In-Reply-To: <991ac738-1f5d-8bbd-9c0e-a7e6c05514d9@iris.mystia.org>
Tomohiro Mayama skrev den 2019-03-08 11:48:
> Hello Dan,
>
> On 2019/03/08 16:35, Dan Johansen wrote:
>> - gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
>> + gpio = <&gpio0 RK_PD3 GPIO_ACTIVE_HIGH>;
>
> According to Robin's advice by reading the schematic, correct GPIO pin
> assignment is RK_PA2, but GPIO_ACTIVE_LOW. This fixed the USB problem
> for me.
>
> Please see the following thread:
> https://lists.infradead.org/pipermail/linux-rockchip/2019-March/023298.html
>
> Also please see this patch:
> https://lists.infradead.org/pipermail/linux-rockchip/2019-March/023300.html
>
> Or won't your problem be fixed with this patch?
>
> Regards,
> Tomohiro
Ah, didn't see that one.
Yes it does.
Sorry. Please remove this patch submission.
--
Sincerely
Dan "Strit" Johansen
Project Lead on the Manjaro ARM project
https://www.manjaro.org
Catch me on:
Mastodon: @strit@mastodon.social
Matrix: @strit:matrix.org
Wire: @strit
Email: strit@manjaro.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Chen-Yu Tsai @ 2019-08-23 10:10 UTC (permalink / raw)
To: Maxime Ripard
Cc: Ondřej Jirman, Mark Rutland, devicetree, linux-kernel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190823100807.22heh2gahi7owo4e@flea>
On Fri, Aug 23, 2019 at 6:08 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> Hi,
>
> On Fri, Aug 23, 2019 at 11:42:28AM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
> > bcm43356 and can be used with the brcmfmac driver. The module is powered by
> > the two always on regulators (not AXP805).
> >
> > WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> > configured so that it sets up an 1.8V input bias on this port. This is done
> > by the pio driver by reading the vcc-pg-supply voltage.
> >
> > You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> > configuration that can be found in the Xulongs's repository for H6:
> >
> > https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
> >
> > Mainline brcmfmac driver expects the firmware and nvram at the following
> > paths relative to the firmware directory:
> >
> > brcm/brcmfmac43456-sdio.bin
> > brcm/brcmfmac43456-sdio.txt
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> >
> > Since RTC patches for H6 were merged, this can now go in too, if it looks ok.
> >
> > Other patches for this WiFi chip support were merged in previous cycles,
> > so this just needs enabling in DTS now.
> >
> > Sorry for the links in the commit log, but this information is useful,
> > even if the link itself goes bad. Any pointer what to google for
> > (file names, tree name) is great for anyone searching in the future.
>
> I understand, but this should (also?) be in the wiki. Please add it
> there too.
>
> > Please take a look.
> >
> > Thank you,
> > Ondrej
> >
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index eda9d5f640b9..49d954369087 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -56,6 +56,34 @@
> > regulator-max-microvolt = <5000000>;
> > regulator-always-on;
> > };
> > +
> > + reg_vcc33_wifi: vcc33-wifi {
> > + /* Always on 3.3V regulator for WiFi and BT */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc33-wifi";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc5v>;
> > + };
> > +
> > + reg_vcc_wifi_io: vcc-wifi-io {
> > + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-wifi-io";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + vin-supply = <®_vcc33_wifi>;
> > + };
> > +
> > + wifi_pwrseq: wifi_pwrseq {
IIRC we shouldn't use underscores in node names. Maxime can you fix that up?
ChenYu
> > + compatible = "mmc-pwrseq-simple";
> > + clocks = <&rtc 1>;
> > + clock-names = "ext_clock";
> > + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> > + post-power-on-delay-ms = <200>;
> > + };
> > };
> >
> > &cpu0 {
> > @@ -91,6 +119,25 @@
> > status = "okay";
> > };
> >
> > +&mmc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
>
> This is the default already. I've removed it and applied.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Maxime Ripard @ 2019-08-23 10:08 UTC (permalink / raw)
To: megous
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190823094228.6540-1-megous@megous.com>
[-- Attachment #1.1: Type: text/plain, Size: 3198 bytes --]
Hi,
On Fri, Aug 23, 2019 at 11:42:28AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
> bcm43356 and can be used with the brcmfmac driver. The module is powered by
> the two always on regulators (not AXP805).
>
> WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> configured so that it sets up an 1.8V input bias on this port. This is done
> by the pio driver by reading the vcc-pg-supply voltage.
>
> You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> configuration that can be found in the Xulongs's repository for H6:
>
> https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
>
> Mainline brcmfmac driver expects the firmware and nvram at the following
> paths relative to the firmware directory:
>
> brcm/brcmfmac43456-sdio.bin
> brcm/brcmfmac43456-sdio.txt
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
>
> Since RTC patches for H6 were merged, this can now go in too, if it looks ok.
>
> Other patches for this WiFi chip support were merged in previous cycles,
> so this just needs enabling in DTS now.
>
> Sorry for the links in the commit log, but this information is useful,
> even if the link itself goes bad. Any pointer what to google for
> (file names, tree name) is great for anyone searching in the future.
I understand, but this should (also?) be in the wiki. Please add it
there too.
> Please take a look.
>
> Thank you,
> Ondrej
>
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index eda9d5f640b9..49d954369087 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -56,6 +56,34 @@
> regulator-max-microvolt = <5000000>;
> regulator-always-on;
> };
> +
> + reg_vcc33_wifi: vcc33-wifi {
> + /* Always on 3.3V regulator for WiFi and BT */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc33-wifi";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + vin-supply = <®_vcc5v>;
> + };
> +
> + reg_vcc_wifi_io: vcc-wifi-io {
> + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-wifi-io";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + vin-supply = <®_vcc33_wifi>;
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&rtc 1>;
> + clock-names = "ext_clock";
> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
> + post-power-on-delay-ms = <200>;
> + };
> };
>
> &cpu0 {
> @@ -91,6 +119,25 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
This is the default already. I've removed it and applied.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH next v10 03/11] dt-bindings: usb: add binding for USB GPIO based connection detection driver
From: Linus Walleij @ 2019-08-23 10:07 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heikki Krogerus, Hans de Goede, Greg Kroah-Hartman, linux-usb,
linux-kernel@vger.kernel.org, Biju Das, Badhri Jagan Sridharan,
Andy Shevchenko, Rob Herring,
moderated list:ARM/Mediatek SoC support, Min Guo,
Matthias Brugger, Nagarjuna Kristam, Adam Thomson, Linux ARM,
Li Jun
In-Reply-To: <1566547041-20804-4-git-send-email-chunfeng.yun@mediatek.com>
On Fri, Aug 23, 2019 at 9:58 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
> It's used to support dual role switch via GPIO when use Type-B
> receptacle, typically the USB ID pin is connected to an input
> GPIO, and also used to enable/disable device when the USB Vbus
> pin is connected to an input GPIO.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v9~v10 no changes
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [stericsson:ab8500-gpadc 1/8] ab8500_btemp.c:undefined reference to `iio_read_channel_processed'
From: kbuild test robot @ 2019-08-23 10:01 UTC (permalink / raw)
To: Linus Walleij; +Cc: kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-stericsson.git ab8500-gpadc
head: b9fc9832627e121832ebbcb26426f700f4fde9db
commit: 9cdd57c9310050acecd45c876149da7fef570450 [1/8] power: supply: ab8500_btemp: convert to IIO ADC
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 9cdd57c9310050acecd45c876149da7fef570450
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/power/supply/ab8500_btemp.o: In function `ab8500_btemp_get_batctrl_res':
>> ab8500_btemp.c:(.text+0xbf4): undefined reference to `iio_read_channel_processed'
drivers/power/supply/ab8500_btemp.o: In function `ab8500_btemp_probe':
>> ab8500_btemp.c:(.text+0xf0c): undefined reference to `devm_iio_channel_get'
ab8500_btemp.c:(.text+0xf5c): undefined reference to `devm_iio_channel_get'
drivers/power/supply/ab8500_btemp.o: In function `ab8500_btemp_periodic_work':
ab8500_btemp.c:(.text+0x1684): undefined reference to `iio_read_channel_processed'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 71382 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 01/11] dt-bindings: mmc: arasan: Update documentation for SD Card Clock
From: Manish Narani @ 2019-08-23 10:01 UTC (permalink / raw)
To: Heiko Stuebner, Ulf Hansson, linux-mmc@vger.kernel.org
Cc: mark.rutland@arm.com, Rob Herring, kernel@esmil.dk,
scott.branden@broadcom.com, viresh.kumar@linaro.org,
ayaka@soulik.info, adrian.hunter@intel.com,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
Rajan Vaja, tony.xie@rock-chips.com, Michal Simek,
linux-arm-kernel@lists.infradead.org,
philipp.tomsich@theobroma-systems.com, devicetree@vger.kernel.org,
christoph.muellner@theobroma-systems.com
In-Reply-To: <4911073.ucheZMAtV3@phil>
Hi Heiko/Uffe,
> -----Original Message-----
> From: Heiko Stuebner <heiko@sntech.de>
> Sent: Thursday, August 22, 2019 11:53 PM
> To: Ulf Hansson <ulf.hansson@linaro.org>; linux-mmc@vger.kernel.org
> Cc: Manish Narani <MNARANI@xilinx.com>; Rob Herring <robh@kernel.org>;
> mark.rutland@arm.com; Michal Simek <michals@xilinx.com>;
> adrian.hunter@intel.com; christoph.muellner@theobroma-systems.com;
> philipp.tomsich@theobroma-systems.com; viresh.kumar@linaro.org;
> scott.branden@broadcom.com; ayaka@soulik.info; kernel@esmil.dk;
> tony.xie@rock-chips.com; Rajan Vaja <RAJANV@xilinx.com>;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-rockchip@lists.infradead.org
> Subject: Re: [PATCH v2 01/11] dt-bindings: mmc: arasan: Update
> documentation for SD Card Clock
>
> Am Donnerstag, 22. August 2019, 15:38:26 CEST schrieb Ulf Hansson:
> > [...]
> >
> > > > > > > ---
> > > > > > > Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15
> > > > ++++++++++-
> > > > > > ----
> > > > > > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > > > > > >
> > > > > > > diff --git
> a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > > > index 1edbb04..15c6397 100644
> > > > > > > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > > > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > > > @@ -23,6 +23,10 @@ Required Properties:
> > > > > > > - reg: From mmc bindings: Register location and length.
> > > > > > > - clocks: From clock bindings: Handles to clock inputs.
> > > > > > > - clock-names: From clock bindings: Tuple including "clk_xin" and
> > > > "clk_ahb"
> > > > > > > + Apart from these two there is one more optional clock
> which
> > > > > > > + is "clk_sdcard". This clock represents output clock from
> > > > > > > + controller and card. This must be specified when #clock-
> cells
> > > > > > > + is specified.
> > > > > > > - interrupts: Interrupt specifier
> > > > > > >
> > > > > > > Required Properties for "arasan,sdhci-5.1":
> > > > > > > @@ -36,9 +40,10 @@ Optional Properties:
> > > > > > > - clock-output-names: If specified, this will be the name of the card
> > > > clock
> > > > > > > which will be exposed by this device. Required if #clock-cells is
> > > > > > > specified.
> > > > > > > - - #clock-cells: If specified this should be the value <0>. With this
> > > > property
> > > > > > > - in place we will export a clock representing the Card Clock. This
> clock
> > > > > > > - is expected to be consumed by our PHY. You must also specify
> > > > > > > + - #clock-cells: If specified this should be the value <0>. With this
> > > > > > > + property in place we will export one clock representing the Card
> > > > > > > + Clock. This clock is expected to be consumed by our PHY. You
> must
> > > > also
> > > > > > > + specify
> > > > > >
> > > > > > specify what?
> > > > > I think this line was already there, I missed to correct it, Will update in
> v3.
> > > > >
> > > > > >
> > > > > > The 3rd clock input I assume? This statement means any existing users
> > > > > > with 2 clock inputs and #clock-cells are in error now. Is that correct?
> > > > > Yes, this is correct. So far there was only one vendor using '#clock-cells'
> > > > which is Rockchip. I have sent DT patch (02/11) for that also.
> > > > > Here this is needed as earlier implementation isn't correct as suggested
> by
> > > > Uffe. (https://lkml.org/lkml/2019/6/20/486) .
> > > >
> > > > I am not sure how big of a problem the backwards compatible thingy
> > > > with DT is, in general we must not break it. What do you say Manish?
> > >
> > > Though I agree with Uffe on this, there is no other way from my
> understanding. Please suggest.
> > >
> > > >
> > > > As a workaround, would it be possible to use
> > > > of_clk_get_from_provider() somehow to address the compatibility issue?
> > >
> > > For this to be used we have to parse 'clkspec' from the DT node and pass
> the same as an argument to this function. In this case also the DT node needs to
> be updated, which is same as we have done in this series.
> >
> > Alright. I guess breaking DTBs for Rockchip platforms isn't
> > acceptable, especially if those are already widely deployed, which I
> > have no idea of....
>
> The arasan sdhci is part of the rk3399, so every SBC using that SoC, but
> also the whole Gru series of ChromeOS devices (Samsung Chromebook Plus
> among them) would be affected.
Thanks for confirming. This will be taken care of. I will go back to v1 changes and will send v3.
Thanks,
Manish
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V1, 2/2] media: i2c: Add more sensor mode for ov8856 camera sensor
From: Tomasz Figa @ 2019-08-23 10:01 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
louis.kuo, sj.huang, robh+dt, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190808092215.5608-3-dongchun.zhu@mediatek.com>
Hi Dongchun,
On Thu, Aug 08, 2019 at 05:22:15PM +0800, dongchun.zhu@mediatek.com wrote:
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> This patch mainly adds two more sensor modes for OV8856 image sensor.
> The OV8856 driver currently supports output format: 10-bit Raw,
> the resolution of 1632*1224 and 3264*2448, and the bayer order of BGGR.
> The hardware version also differs in some OTP regiser,
> as well as PLL register setting.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> drivers/media/i2c/ov8856.c | 624 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 621 insertions(+), 3 deletions(-)
>
Thanks for the patch! Please see my comments inline.
> diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
> index cd347d6..e0610b6 100644
> --- a/drivers/media/i2c/ov8856.c
> +++ b/drivers/media/i2c/ov8856.c
> @@ -1,12 +1,15 @@
> // SPDX-License-Identifier: GPL-2.0
> // Copyright (c) 2019 Intel Corporation.
>
> +#include <linux/clk.h>
> #include <asm/unaligned.h>
> #include <linux/acpi.h>
> #include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/i2c.h>
> #include <linux/module.h>
> #include <linux/pm_runtime.h>
> +#include <linux/regulator/consumer.h>
> #include <media/v4l2-ctrls.h>
> #include <media/v4l2-device.h>
> #include <media/v4l2-fwnode.h>
> @@ -19,6 +22,7 @@
> #define OV8856_LINK_FREQ_180MHZ 180000000ULL
> #define OV8856_SCLK 144000000ULL
> #define OV8856_MCLK 19200000
> +#define OV8856_XVCLK_FREQ 24000000
> #define OV8856_DATA_LANES 4
> #define OV8856_RGB_DEPTH 10
>
> @@ -29,6 +33,18 @@
> #define OV8856_MODE_STANDBY 0x00
> #define OV8856_MODE_STREAMING 0x01
>
> +/* define 1B module */
> +#define OV8856_1B_MODULE 0x02
> +
> +/* otp sram register */
> +#define OV8856_OTP_REG 0x700f
This isn't a register. I believe the OTP read-out buffer is at 0x7000 and
0xf is the offset of the byte in the OTP that means the module revision.
> +#define OV8856_OTP_REG_ONE 0x3d84
> +#define OV8856_OTP_REG_TWO 0x3d81
These registers are definitely not "ONE" and "TWO". Please use proper
names as per the datasheet.
> +
> +/* clock register */
> +#define OV8856_CLK_REG 0x3614
> +#define OV8856_CLK_REG_1B_VAL 0x20
Same here. These don't look like the real names of the register and bit
field.
> +
> /* vertical-timings from sensor */
> #define OV8856_REG_VTS 0x380e
> #define OV8856_VTS_MAX 0x7fff
> @@ -64,6 +80,14 @@
>
> #define to_ov8856(_sd) container_of(_sd, struct ov8856, sd)
>
> +static const char * const ov8856_supply_names[] = {
> + "dovdd", /* Digital I/O power */
> + "avdd", /* Analog power */
> + "dvdd", /* Digital core power */
> +};
> +
> +#define OV8856_NUM_SUPPLIES ARRAY_SIZE(ov8856_supply_names)
> +
> enum {
> OV8856_LINK_FREQ_720MBPS,
> OV8856_LINK_FREQ_360MBPS,
> @@ -316,6 +340,208 @@ static const struct ov8856_reg mode_3280x2464_regs[] = {
> {0x5e00, 0x00}
> };
>
> +static const struct ov8856_reg mode_3264x2448_regs[] = {
> + {0x0103, 0x01},
> + {0x0302, 0x3c},
> + {0x0303, 0x01},
> + {0x031e, 0x0c},
> + {0x3000, 0x00},
> + {0x300e, 0x00},
> + {0x3010, 0x00},
> + {0x3015, 0x84},
> + {0x3018, 0x72},
> + {0x3021, 0x23},
> + {0x3033, 0x24},
> + {0x3500, 0x00},
> + {0x3501, 0x9a},
> + {0x3502, 0x20},
> + {0x3503, 0x08},
> + {0x3505, 0x83},
> + {0x3508, 0x01},
> + {0x3509, 0x80},
> + {0x350c, 0x00},
> + {0x350d, 0x80},
> + {0x350e, 0x04},
> + {0x350f, 0x00},
> + {0x3510, 0x00},
> + {0x3511, 0x02},
> + {0x3512, 0x00},
> + {0x3600, 0x72},
> + {0x3601, 0x40},
> + {0x3602, 0x30},
> + {0x3610, 0xc5},
> + {0x3611, 0x58},
> + {0x3612, 0x5c},
> + {0x3613, 0xca},
> + {0x3614, 0x60},
> + {0x3628, 0xff},
> + {0x3629, 0xff},
> + {0x362a, 0xff},
> + {0x3633, 0x10},
> + {0x3634, 0x10},
> + {0x3635, 0x10},
> + {0x3636, 0x10},
> + {0x3663, 0x08},
> + {0x3669, 0x34},
> + {0x366d, 0x00},
> + {0x366e, 0x10},
> + {0x3706, 0x86},
> + {0x370b, 0x7e},
> + {0x3714, 0x23},
> + {0x3730, 0x12},
> + {0x3733, 0x10},
> + {0x3764, 0x00},
> + {0x3765, 0x00},
> + {0x3769, 0x62},
> + {0x376a, 0x2a},
> + {0x376b, 0x30},
> + {0x3780, 0x00},
> + {0x3781, 0x24},
> + {0x3782, 0x00},
> + {0x3783, 0x23},
> + {0x3798, 0x2f},
> + {0x37a1, 0x60},
> + {0x37a8, 0x6a},
> + {0x37ab, 0x3f},
> + {0x37c2, 0x04},
> + {0x37c3, 0xf1},
> + {0x37c9, 0x80},
> + {0x37cb, 0x16},
> + {0x37cc, 0x16},
> + {0x37cd, 0x16},
> + {0x37ce, 0x16},
> + {0x3800, 0x00},
> + {0x3801, 0x00},
> + {0x3802, 0x00},
> + {0x3803, 0x0c},
> + {0x3804, 0x0c},
> + {0x3805, 0xdf},
> + {0x3806, 0x09},
> + {0x3807, 0xa3},
> + {0x3808, 0x0c},
> + {0x3809, 0xc0},
> + {0x380a, 0x09},
> + {0x380b, 0x90},
> + {0x380c, 0x07},
> + {0x380d, 0x8c},
> + {0x380e, 0x09},
> + {0x380f, 0xb2},
> + {0x3810, 0x00},
> + {0x3811, 0x04},
> + {0x3812, 0x00},
> + {0x3813, 0x02},
> + {0x3814, 0x01},
> + {0x3815, 0x01},
> + {0x3816, 0x00},
> + {0x3817, 0x00},
> + {0x3818, 0x00},
> + {0x3819, 0x00},
> + {0x3820, 0x80},
> + {0x3821, 0x46},
> + {0x382a, 0x01},
> + {0x382b, 0x01},
> + {0x3830, 0x06},
> + {0x3836, 0x02},
> + {0x3862, 0x04},
> + {0x3863, 0x08},
> + {0x3cc0, 0x33},
> + {0x3d85, 0x17},
> + {0x3d8c, 0x73},
> + {0x3d8d, 0xde},
> + {0x4001, 0xe0},
> + {0x4003, 0x40},
> + {0x4008, 0x00},
> + {0x4009, 0x0b},
> + {0x400a, 0x00},
> + {0x400b, 0x84},
> + {0x400f, 0x80},
> + {0x4010, 0xf0},
> + {0x4011, 0xff},
> + {0x4012, 0x02},
> + {0x4013, 0x01},
> + {0x4014, 0x01},
> + {0x4015, 0x01},
> + {0x4042, 0x00},
> + {0x4043, 0x80},
> + {0x4044, 0x00},
> + {0x4045, 0x80},
> + {0x4046, 0x00},
> + {0x4047, 0x80},
> + {0x4048, 0x00},
> + {0x4049, 0x80},
> + {0x4041, 0x03},
> + {0x404c, 0x20},
> + {0x404d, 0x00},
> + {0x404e, 0x20},
> + {0x4203, 0x80},
> + {0x4307, 0x30},
> + {0x4317, 0x00},
> + {0x4502, 0x50},
> + {0x4503, 0x08},
> + {0x4601, 0x80},
> + {0x4800, 0x44},
> + {0x4816, 0x53},
> + {0x481b, 0x50},
> + {0x481f, 0x27},
> + {0x4823, 0x3c},
> + {0x482b, 0x00},
> + {0x4831, 0x66},
> + {0x4837, 0x16},
> + {0x483c, 0x0f},
> + {0x484b, 0x05},
> + {0x5000, 0x77},
> + {0x5001, 0x0a},
> + {0x5003, 0xc8},
> + {0x5004, 0x04},
> + {0x5006, 0x00},
> + {0x5007, 0x00},
> + {0x502e, 0x03},
> + {0x5030, 0x41},
> + {0x5780, 0x14},
> + {0x5781, 0x0f},
> + {0x5782, 0x44},
> + {0x5783, 0x02},
> + {0x5784, 0x01},
> + {0x5785, 0x01},
> + {0x5786, 0x00},
> + {0x5787, 0x04},
> + {0x5788, 0x02},
> + {0x5789, 0x0f},
> + {0x578a, 0xfd},
> + {0x578b, 0xf5},
> + {0x578c, 0xf5},
> + {0x578d, 0x03},
> + {0x578e, 0x08},
> + {0x578f, 0x0c},
> + {0x5790, 0x08},
> + {0x5791, 0x04},
> + {0x5792, 0x00},
> + {0x5793, 0x52},
> + {0x5794, 0xa3},
> + {0x5795, 0x02},
> + {0x5796, 0x20},
> + {0x5797, 0x20},
> + {0x5798, 0xd5},
> + {0x5799, 0xd5},
> + {0x579a, 0x00},
> + {0x579b, 0x50},
> + {0x579c, 0x00},
> + {0x579d, 0x2c},
> + {0x579e, 0x0c},
> + {0x579f, 0x40},
> + {0x57a0, 0x09},
> + {0x57a1, 0x40},
> + {0x59f8, 0x3d},
> + {0x5a08, 0x02},
> + {0x5b00, 0x02},
> + {0x5b01, 0x10},
> + {0x5b02, 0x03},
> + {0x5b03, 0xcf},
> + {0x5b05, 0x6c},
> + {0x5e00, 0x00},
> + {0x5e10, 0xfc}
> +};
> +
It would be better if we could find the differences between the two arrays
and handle them incrementally.
[snip]
> +static int ov8856_update_otp_reg(struct ov8856 *ov8856)
> +{
> + int ret;
> +
> + ret = ov8856_write_reg(ov8856, OV8856_REG_MODE_SELECT,
> + OV8856_REG_VALUE_08BIT, OV8856_MODE_STREAMING);
> + if (ret)
> + return ret;
> +
> + ret = ov8856_write_reg(ov8856, OV8856_OTP_REG_ONE,
> + OV8856_REG_VALUE_08BIT, OV8856_MODE_STANDBY);
> + if (ret)
> + return ret;
> +
> + return ov8856_write_reg(ov8856, OV8856_OTP_REG_TWO,
> + OV8856_REG_VALUE_08BIT, OV8856_MODE_STREAMING);
Hmm, this doesn't sound right. The OTP register doesn't have anything to do
with streaming. Also we should stop streaming at the end.
> +}
> +
> static int ov8856_set_ctrl(struct v4l2_ctrl *ctrl)
> {
> struct ov8856 *ov8856 = container_of(ctrl->handler,
> @@ -825,7 +1302,13 @@ static void ov8856_update_pad_format(const struct ov8856_mode *mode,
> {
> fmt->width = mode->width;
> fmt->height = mode->height;
> - fmt->code = MEDIA_BUS_FMT_SGRBG10_1X10;
> +
> + /* Bayer Order is determined by image resolution */
> + if (fmt->width == 3264 || fmt->width == 1632)
Could we instead set the bayer order in the mode struct?
> + fmt->code = MEDIA_BUS_FMT_SBGGR10_1X10;
> + else
> + fmt->code = MEDIA_BUS_FMT_SGRBG10_1X10;
> +
> fmt->field = V4L2_FIELD_NONE;
> }
>
> @@ -850,6 +1333,17 @@ static int ov8856_start_streaming(struct ov8856 *ov8856)
> return ret;
> }
>
> + /* update R3614 for 1B module */
What's R3614?
> + if (ov8856->is_1B_module) {
> + ret = ov8856_write_reg(ov8856, OV8856_CLK_REG,
> + OV8856_REG_VALUE_08BIT,
> + OV8856_CLK_REG_1B_VAL);
> + if (ret) {
> + dev_err(&client->dev, "failed to set R3614");
> + return ret;
> + }
> + }
> +
> ret = __v4l2_ctrl_handler_setup(ov8856->sd.ctrl_handler);
> if (ret)
> return ret;
> @@ -882,6 +1376,8 @@ static int ov8856_set_stream(struct v4l2_subdev *sd, int enable)
> if (ov8856->streaming == enable)
> return 0;
>
> + dev_dbg(&client->dev, "hardware version: (%d)\n", ov8856->is_1B_module);
> +
> mutex_lock(&ov8856->mutex);
> if (enable) {
> ret = pm_runtime_get_sync(&client->dev);
> @@ -908,6 +1404,54 @@ static int ov8856_set_stream(struct v4l2_subdev *sd, int enable)
> return ret;
> }
>
> +/* Calculate the delay in us by clock rate and clock cycles */
> +static inline u32 ov8856_cal_delay(u32 cycles)
> +{
> + return DIV_ROUND_UP(cycles, OV8856_XVCLK_FREQ / 1000 / 1000);
> +}
> +
> +static int __ov8856_power_on(struct ov8856 *ov8856)
> +{
> + int ret;
> + u32 delay_us;
> + struct i2c_client *client = v4l2_get_subdevdata(&ov8856->sd);
> +
> + ret = clk_prepare_enable(ov8856->xvclk);
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to enable xvclk\n");
> + return ret;
> + }
> +
> + gpiod_set_value_cansleep(ov8856->reset_gpio, 1);
According to my datasheet, this sensor doesn't have a reset pin. The one I
can see there is XSHUTDN, which I would call "n_shutdn" here.
> +
> + ret = regulator_bulk_enable(OV8856_NUM_SUPPLIES, ov8856->supplies);
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to enable regulators\n");
> + goto disable_clk;
> + }
> +
> + gpiod_set_value_cansleep(ov8856->reset_gpio, 0);
According to the datasheet, XSHUTDN should be 0 for shutdown and 1 for
running. Why is it the other way around here?
> +
> + /* 8192 cycles prior to first SCCB transaction */
> + delay_us = ov8856_cal_delay(8192);
If we pass a constant to the function and the function itself only uses
constants inside, could we just define a constant delay instead?
> + usleep_range(delay_us * 2, delay_us * 4);
Normally one one just give some small delta here, like +/- 100 us.
> +
> + return 0;
> +
> +disable_clk:
> + clk_disable_unprepare(ov8856->xvclk);
> +
> + return ret;
> +}
> +
> +static void __ov8856_power_off(struct ov8856 *ov8856)
> +{
> + clk_disable_unprepare(ov8856->xvclk);
> + gpiod_set_value_cansleep(ov8856->reset_gpio, 1);
> +
> + regulator_bulk_disable(OV8856_NUM_SUPPLIES, ov8856->supplies);
> +}
> +
> static int __maybe_unused ov8856_suspend(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> @@ -915,8 +1459,8 @@ static int __maybe_unused ov8856_suspend(struct device *dev)
> struct ov8856 *ov8856 = to_ov8856(sd);
>
> mutex_lock(&ov8856->mutex);
> - if (ov8856->streaming)
> - ov8856_stop_streaming(ov8856);
> +
> + __ov8856_power_off(ov8856);
This change is incorrect because it will power off even if the device was
already powered off, causing reference count mismatch. The original code
was okay.
>
> mutex_unlock(&ov8856->mutex);
>
> @@ -1089,6 +1633,20 @@ static int ov8856_identify_module(struct ov8856 *ov8856)
> return -ENXIO;
> }
>
> + /* set R3614 to distinguish harward versions */
hardware
> + ret = ov8856_update_otp_reg(ov8856);
> + if (ret) {
> + dev_err(&client->dev, "failed to set otp register");
> + return ret;
> + }
> +
> + ret = ov8856_read_reg(ov8856, OV8856_OTP_REG,
> + OV8856_REG_VALUE_08BIT, &val);
> + if (ret)
> + return ret;
> +
> + ov8856->is_1B_module = (val == OV8856_1B_MODULE) ? 1 : 0;
I'd rename ov8856_update_otp_reg() to ov8856_check_revision() and move the
few lines above to that function too.
> +
> return 0;
> }
>
> @@ -1164,11 +1722,27 @@ static int ov8856_remove(struct i2c_client *client)
> media_entity_cleanup(&sd->entity);
> v4l2_ctrl_handler_free(sd->ctrl_handler);
> pm_runtime_disable(&client->dev);
> + if (!pm_runtime_status_suspended(&client->dev))
> + __ov8856_power_off(ov8856);
> + pm_runtime_set_suspended(&client->dev);
> mutex_destroy(&ov8856->mutex);
>
> return 0;
> }
>
> +static int ov8856_configure_regulators(struct ov8856 *ov8856)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov8856->sd);
> + int i;
> +
> + for (i = 0; i < OV8856_NUM_SUPPLIES; i++)
> + ov8856->supplies[i].supply = ov8856_supply_names[i];
> +
> + return devm_regulator_bulk_get(&client->dev,
> + OV8856_NUM_SUPPLIES,
> + ov8856->supplies);
> +}
There is not much value in having a dedicated function just to call one
more function. Could you move back to the caller?
> +
> static int ov8856_probe(struct i2c_client *client)
> {
> struct ov8856 *ov8856;
> @@ -1186,6 +1760,40 @@ static int ov8856_probe(struct i2c_client *client)
> return -ENOMEM;
>
> v4l2_i2c_subdev_init(&ov8856->sd, client, &ov8856_subdev_ops);
> +
> + ov8856->xvclk = devm_clk_get(&client->dev, "xvclk");
> + if (IS_ERR(ov8856->xvclk)) {
> + dev_err(&client->dev, "Failed to get xvclk\n");
> + return -EINVAL;
> + }
> +
> + ret = clk_set_rate(ov8856->xvclk, OV8856_XVCLK_FREQ);
We should get the frequency from the DT bindings.
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to set xvclk rate (24MHz)\n");
> + return ret;
> + }
> + if (clk_get_rate(ov8856->xvclk) != OV8856_XVCLK_FREQ)
> + dev_warn(&client->dev,
> + "xvclk mismatched, modes are based on 24MHz\n");
> +
> + ov8856->reset_gpio = devm_gpiod_get(&client->dev,
> + "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(ov8856->reset_gpio)) {
> + dev_err(&client->dev, "Failed to get reset-gpios\n");
> + return -EINVAL;
> + }
> +
> + ret = ov8856_configure_regulators(ov8856);
> + if (ret) {
> + dev_err(&client->dev, "Failed to get power regulators\n");
> + return ret;
> + }
> +
> + ret = __ov8856_power_on(ov8856);
> + if (ret)
> + goto probe_error_v4l2_ctrl_handler_free;
> +
> ret = ov8856_identify_module(ov8856);
> if (ret) {
> dev_err(&client->dev, "failed to find sensor: %d", ret);
> @@ -1251,11 +1859,21 @@ static const struct acpi_device_id ov8856_acpi_ids[] = {
> MODULE_DEVICE_TABLE(acpi, ov8856_acpi_ids);
> #endif
>
> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id ov8856_of_match[] = {
> + { .compatible = "ovti,ov8856" },
> + {},
> +};
> +
nit: Unnecessary blank line.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] [RFC] ARM: shmobile: defconfig: Disable PL310_ERRATA_588369
From: Geert Uytterhoeven @ 2019-08-23 9:49 UTC (permalink / raw)
To: Simon Horman; +Cc: Linux-Renesas, Magnus Damm, Linux ARM, Geert Uytterhoeven
In-Reply-To: <20190822085804.rgyjxisnznmnura5@verge.net.au>
Hi Simon,
On Thu, Aug 22, 2019 at 10:58 AM Simon Horman <horms@verge.net.au> wrote:
> On Wed, Aug 21, 2019 at 02:46:02PM +0200, Geert Uytterhoeven wrote:
> > PL310 Erratum 588369 affects PL310 cache controller revisions older than
> > r2p0.
> >
> > As Renesas ARM SoCs contain the following revisions:
> > - SH-Mobile AG5: r3p1,
> > - R-Mobile A1: r3p1-50rel0,
> > - R-Car H1: r3p2,
> > - RZ/A1: r3p2,
> > - RZ/A2: r3p3,
> > none of them are affected, and support for the errata can be disabled
> > safely.
> >
> > The EMMA Mobile EV2 documentation doesn't mention the revision of its
> > PL310 cache controller, so this SoC might be affected. However, the L2
> > cache controller is not enabled by Linux.
>
> If the controller is not enabled by Linux then I would think that the
> Errata is not needed. If that is true then I agree with this patch.
>
> Regarding making assumptions about the version of the PL310 cache
> controller, I suggest that we cannot assume that it is not affected
> without further information.
I agree, so this needs more investigation.
It seems this was included in shmobile_defconfig based on the old
armadillo800eav_defconfig, which enabled several errata options since
commit e0ef0984ae346c54 ("ARM: shmobile: armadillo800eva: enable all
errata for cache on defconfig").
Based on my current knowledge, PL310_ERRATA_769419 is the only one that
affects Renesas SoCs (ignoring EMEV2 for now) with a PL310, and thus
should be enabled, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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