* Re: [RESEND, PATCH v13 08/12] soc: mediatek: cmdq: change the type of input parameter
From: Matthias Brugger @ 2019-08-23 12:09 UTC (permalink / raw)
To: Bibby Hsieh, Jassi Brar, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, linux-arm-kernel, ginny.chen
In-Reply-To: <20190820084932.22282-9-bibby.hsieh@mediatek.com>
On 20/08/2019 10:49, Bibby Hsieh wrote:
> According to the cmdq hardware design, the subsys is u8,
> the offset is u16 and the event id is u16.
> This patch changes the type of subsys, offset and event id
> to the correct type.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
Applied, thanks
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 10 +++++-----
> include/linux/soc/mediatek/mtk-cmdq.h | 10 +++++-----
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 082b8978651e..7aa0517ff2f3 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> return 0;
> }
>
> -int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
> +int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
> {
> u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> (subsys << CMDQ_SUBSYS_SHIFT);
> @@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
> }
> EXPORT_SYMBOL(cmdq_pkt_write);
>
> -int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> - u32 offset, u32 value, u32 mask)
> +int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> + u16 offset, u32 value, u32 mask)
> {
> u32 offset_mask = offset;
> int err = 0;
> @@ -161,7 +161,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_mask);
>
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> u32 arg_b;
>
> @@ -181,7 +181,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
> }
> EXPORT_SYMBOL(cmdq_pkt_wfe);
>
> -int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event)
> +int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> {
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> index 39d813dde4b4..9618debb9ceb 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -66,7 +66,7 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
> +int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value);
>
> /**
> * cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
> @@ -78,8 +78,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> - u32 offset, u32 value, u32 mask);
> +int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> + u16 offset, u32 value, u32 mask);
>
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> @@ -88,7 +88,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
>
> /**
> * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
> @@ -97,7 +97,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event);
> +int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>
> /**
> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>
_______________________________________________
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: Benoit Parrot @ 2019-08-23 12:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Kate Stewart, Richard Fontana, Lad, Prabhakar, Thierry Reding,
Bluecherry Maintainers, Laurent Pinchart, Sylwester Nawrocki,
devel, Krzysztof Kozlowski, Michal Simek, Andrey Utkin,
Jonathan Hunter, Kukjin Kim, linux-arm-kernel, Ismael Luceno,
Linux Media Mailing List, Mauro Carvalho Chehab,
linux-samsung-soc, 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
In-Reply-To: <d6c04bf604084af63fec603b4afbd72c648e0394.1566553525.git.mchehab+samsung@kernel.org>
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote on Fri [2019-Aug-23 06:47:30 -0300]:
> As warned by cppcheck:
>
> [drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
> [drivers/media/pci/bt8xx/bttv-input.c:87]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
> [drivers/media/pci/bt8xx/bttv-input.c:98]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
> ...
> [drivers/media/v4l2-core/v4l2-ioctl.c:1391]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
>
> 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/am437x/am437x-vpfe_regs.h
drivers/media/platform/ti-vpe/vpe_regs.h
Reviewed-by: Benoit Parrot <bparrot@ti.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 v3 05/10] KVM: arm64: Support stolen time reporting via shared structure
From: Zenghui Yu @ 2019-08-23 12:07 UTC (permalink / raw)
To: Steven Price, Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm
Cc: kvm, linux-doc, Catalin Marinas, Russell King, linux-kernel,
Paolo Bonzini
In-Reply-To: <20190821153656.33429-6-steven.price@arm.com>
Hi Steven,
Only one comment, at the bottom.
On 2019/8/21 23:36, Steven Price wrote:
> Implement the service call for configuring a shared structure between a
> VCPU and the hypervisor in which the hypervisor can write the time
> stolen from the VCPU's execution time by other tasks on the host.
>
> The hypervisor allocates memory which is placed at an IPA chosen by user
> space. The hypervisor then updates the shared structure using
> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
> reporting the stolen time in nanoseconds.
>
> Whenever stolen time is enabled by the guest, the stolen time counter is
> reset.
>
> The stolen time itself is retrieved from the sched_info structure
> maintained by the Linux scheduler code. We enable SCHEDSTATS when
> selecting KVM Kconfig to ensure this value is meaningful.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm/include/asm/kvm_host.h | 20 +++++++++
> arch/arm64/include/asm/kvm_host.h | 25 +++++++++++-
> arch/arm64/kvm/Kconfig | 1 +
> include/linux/kvm_types.h | 2 +
> virt/kvm/arm/arm.c | 10 +++++
> virt/kvm/arm/hypercalls.c | 3 ++
> virt/kvm/arm/pvtime.c | 67 +++++++++++++++++++++++++++++++
> 7 files changed, 127 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 369b5d2d54bf..47d2ced99421 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -39,6 +39,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -329,6 +330,25 @@ static inline int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> return SMCCC_RET_NOT_SUPPORTED;
> }
>
> +static inline int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + return SMCCC_RET_NOT_SUPPORTED;
> +}
> +
> +static inline int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline void kvm_pvtime_init_vm(struct kvm_arch *kvm_arch)
> +{
> +}
> +
> +static inline bool kvm_is_pvtime_enabled(struct kvm_arch *kvm_arch)
> +{
> + return false;
> +}
> +
> void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
>
> struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 583b3639062a..b6fa7beffd8a 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -44,6 +44,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -83,6 +84,11 @@ struct kvm_arch {
>
> /* Mandated version of PSCI */
> u32 psci_version;
> +
> + struct kvm_arch_pvtime {
> + gpa_t st_base;
> + u64 st_size;
> + } pvtime;
> };
>
> #define KVM_NR_MEM_OBJS 40
> @@ -338,8 +344,13 @@ struct kvm_vcpu_arch {
> /* True when deferrable sysregs are loaded on the physical CPU,
> * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> bool sysregs_loaded_on_cpu;
> -};
>
> + /* Guest PV state */
> + struct {
> + u64 steal;
> + u64 last_steal;
> + } steal;
> +};
> /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
> #define vcpu_sve_pffr(vcpu) ((void *)((char *)((vcpu)->arch.sve_state) + \
> sve_ffr_offset((vcpu)->arch.sve_max_vl)))
> @@ -479,6 +490,18 @@ int kvm_perf_init(void);
> int kvm_perf_teardown(void);
>
> int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu);
> +int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu);
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init);
> +
> +static inline void kvm_pvtime_init_vm(struct kvm_arch *kvm_arch)
> +{
> + kvm_arch->pvtime.st_base = GPA_INVALID;
> +}
> +
> +static inline bool kvm_is_pvtime_enabled(struct kvm_arch *kvm_arch)
> +{
> + return (kvm_arch->pvtime.st_base != GPA_INVALID);
> +}
>
> void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
>
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a67121d419a2..d8b88e40d223 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -39,6 +39,7 @@ config KVM
> select IRQ_BYPASS_MANAGER
> select HAVE_KVM_IRQ_BYPASS
> select HAVE_KVM_VCPU_RUN_PID_CHANGE
> + select SCHEDSTATS
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index bde5374ae021..1c88e69db3d9 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -35,6 +35,8 @@ typedef unsigned long gva_t;
> typedef u64 gpa_t;
> typedef u64 gfn_t;
>
> +#define GPA_INVALID (~(gpa_t)0)
> +
> typedef unsigned long hva_t;
> typedef u64 hpa_t;
> typedef u64 hfn_t;
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 35a069815baf..5e8343e2dd62 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -40,6 +40,10 @@
> #include <asm/kvm_coproc.h>
> #include <asm/sections.h>
>
> +#include <kvm/arm_hypercalls.h>
> +#include <kvm/arm_pmu.h>
> +#include <kvm/arm_psci.h>
> +
> #ifdef REQUIRES_VIRT
> __asm__(".arch_extension virt");
> #endif
> @@ -135,6 +139,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> kvm->arch.max_vcpus = vgic_present ?
> kvm_vgic_get_max_vcpus() : KVM_MAX_VCPUS;
>
> + kvm_pvtime_init_vm(&kvm->arch);
> return ret;
> out_free_stage2_pgd:
> kvm_free_stage2_pgd(kvm);
> @@ -379,6 +384,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> kvm_vcpu_load_sysregs(vcpu);
> kvm_arch_vcpu_load_fp(vcpu);
> kvm_vcpu_pmu_restore_guest(vcpu);
> + if (kvm_is_pvtime_enabled(&vcpu->kvm->arch))
> + kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
>
> if (single_task_running())
> vcpu_clear_wfe_traps(vcpu);
> @@ -644,6 +651,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu)
> * that a VCPU sees new virtual interrupts.
> */
> kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu);
> +
> + if (kvm_check_request(KVM_REQ_RECORD_STEAL, vcpu))
> + kvm_update_stolen_time(vcpu, false);
> }
> }
>
> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c
> index 63ae629c466a..ac678eabf15f 100644
> --- a/virt/kvm/arm/hypercalls.c
> +++ b/virt/kvm/arm/hypercalls.c
> @@ -56,6 +56,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> case ARM_SMCCC_HV_PV_FEATURES:
> val = kvm_hypercall_pv_features(vcpu);
> break;
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + val = kvm_hypercall_stolen_time(vcpu);
> + break;
> default:
> return kvm_psci_call(vcpu);
> }
> diff --git a/virt/kvm/arm/pvtime.c b/virt/kvm/arm/pvtime.c
> index 6201d71cb1f8..28603689f6e0 100644
> --- a/virt/kvm/arm/pvtime.c
> +++ b/virt/kvm/arm/pvtime.c
> @@ -3,8 +3,51 @@
>
> #include <linux/arm-smccc.h>
>
> +#include <asm/pvclock-abi.h>
> +
> #include <kvm/arm_hypercalls.h>
>
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + struct kvm_arch_pvtime *pvtime = &kvm->arch.pvtime;
> + u64 steal;
> + u64 steal_le;
> + u64 offset;
> + int idx;
> + const int stride = sizeof(struct pvclock_vcpu_stolen_time);
> +
> + if (pvtime->st_base == GPA_INVALID)
> + return -ENOTSUPP;
> +
> + /* Let's do the local bookkeeping */
> + steal = vcpu->arch.steal.steal;
> + steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> + vcpu->arch.steal.steal = steal;
> +
> + offset = stride * kvm_vcpu_get_idx(vcpu);
> +
> + if (unlikely(offset + stride > pvtime->st_size))
> + return -EINVAL;
> +
> + steal_le = cpu_to_le64(steal);
> + idx = srcu_read_lock(&kvm->srcu);
> + if (init) {
> + struct pvclock_vcpu_stolen_time init_values = {
> + .revision = 0,
> + .attributes = 0
> + };
> + kvm_write_guest(kvm, pvtime->st_base + offset, &init_values,
> + sizeof(init_values));
> + }
> + offset += offsetof(struct pvclock_vcpu_stolen_time, stolen_time);
> + kvm_put_guest(kvm, pvtime->st_base + offset, steal_le, u64);
> + srcu_read_unlock(&kvm->srcu, idx);
> +
> + return 0;
> +}
> +
> int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> {
> u32 feature = smccc_get_arg1(vcpu);
> @@ -12,6 +55,7 @@ int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
>
> switch (feature) {
> case ARM_SMCCC_HV_PV_FEATURES:
> + case ARM_SMCCC_HV_PV_TIME_ST:
> val = SMCCC_RET_SUCCESS;
> break;
> }
> @@ -19,3 +63,26 @@ int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> return val;
> }
>
> +int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + u64 ret;
> + int err;
> +
> + /*
> + * Start counting stolen time from the time the guest requests
> + * the feature enabled.
> + */
> + vcpu->arch.steal.steal = 0;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> +
> + err = kvm_update_stolen_time(vcpu, true);
> +
> + if (err)
> + ret = SMCCC_RET_NOT_SUPPORTED;
> + else
> + ret = vcpu->kvm->arch.pvtime.st_base +
> + (sizeof(struct pvclock_vcpu_stolen_time) *
> + kvm_vcpu_get_idx(vcpu));
> +
> + return ret;
The *type* of the 'ret' here looks a bit messy to me:
(1)u64 -> (2)int -> (3)u32 -> (4)unsigned long
(1)->(2): just inside kvm_hypercall_stolen_time()
(2)->(3): inside kvm_hvc_call_handler(), assign 'ret' to 'val'
(3)->(4): through smccc_set_retval()
I really have seen an issue caused by (2)->(3).
When the PV guest running without PV_TIME device supporting, the result
of the ARM_SMCCC_HV_PV_TIME_ST hypercall is expected to be -1 (which
means "not supported"), but the actual result I got is 4294967295.
Guest continues to run blindly, bad things would happen then...
I think this needs a fix?
Thanks,
zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Frank Wunderlich @ 2019-08-23 12:13 UTC (permalink / raw)
To: Hsin-Hsiung Wang
Cc: Mark Rutland, Kate Stewart, Alexandre Belloni, linux-kernel,
"René van Dorst", Lee Jones, Hsin-Hsiung Wang,
linux-rtc, devicetree, Sean Wang, Rob Herring, linux-mediatek,
Matthias Brugger, Thomas Gleixner, Eddie Huang, linux-arm-kernel,
Alessandro Zummo, srv_heupstream, Richard Fontana,
Greg Kroah-Hartman, Liam Girdwood, Mark Brown
In-Reply-To: <1566531931-9772-3-git-send-email-hsin-hsiung.wang@mediatek.com>
Hi,
this commit breaks mt6323 pmic on BananaPi-R2
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4872e80ce7d2a1844328176dbf279d0a2b89bdb
resulting in this message in dmesg:
mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0
and multiple
mtk-cpufreq mtk-cpufreq: failed to initialize dvfs info for cpu0
see discussion here:
http://lists.infradead.org/pipermail/linux-mediatek/2019-August/022505.html
after reverting this one the errors are gone, please provide a fix
regards Frank
> Gesendet: Freitag, 23. August 2019 um 05:45 Uhr
> Von: "Hsin-Hsiung Wang" <hsin-hsiung.wang@mediatek.com>
> Betreff: [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
>
> In order to support different types of irq design, we decide to add
> separate irq drivers for different design and keep mt6397 mfd core
> simple and reusable to all generations of PMICs so far.
>
> Acked-for-mfd-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
> ---
> drivers/mfd/Makefile | 3 +-
> drivers/mfd/mt6397-core.c | 146 --------------------------------
> drivers/mfd/mt6397-irq.c | 181 ++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/mt6397/core.h | 9 ++
> 4 files changed, 192 insertions(+), 147 deletions(-)
> create mode 100644 drivers/mfd/mt6397-irq.c
_______________________________________________
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: Thomas Gleixner @ 2019-08-23 12:25 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux, catalin.marinas, will.deacon, LKML, linux-kselftest,
vincenzo.frascino, shuah, linux-arch, Will Deacon, daniel.lezcano,
arnd, andre.przywara, Chris Clayton, 0x7f454c46, pcc,
linux-arm-kernel, huw, linux-mips, ralf, salyzyn, paul.burton,
sthotton
In-Reply-To: <20190823111712.GB13294@shell.armlinux.org.uk>
On Fri, 23 Aug 2019, Russell King - ARM Linux admin wrote:
> On Fri, Aug 23, 2019 at 11:40:50AM +0100, Will Deacon wrote:
> > 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.
>
> Right, so Chris reported the issue to everyone involved. Tglx's
> reply severely trimmed the Cc list so folk like me had no idea what
> was going on, removing even the mailing lists. On the face of it,
> it looks like an intentional attempt to cut people out of the loop
> who really should've been kept in the loop. Yea, that's just great.
Sorry that was no intentional attempt to cut anyone out of the
loop. Trimmed it too agressively without applying much brain.
Thanks,
tglx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: sun4i: Make sun4i_csi_formats static
From: Maxime Ripard @ 2019-08-23 12:26 UTC (permalink / raw)
To: Hans Verkuil, Sakari Ailus, Mauro Carvalho Chehab
Cc: Maxime Ripard, linux-kernel, Hans Verkuil, Chen-Yu Tsai,
linux-arm-kernel, linux-media
From: Maxime Ripard <maxime.ripard@bootlin.com>
The sun4i_csi_formats array is only used in sun4i_v4l2.c, so it doesn't
make any sense to have it !static.
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
index 772b0fc5920f..967bdb99221c 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
@@ -18,7 +18,7 @@
#define CSI_DEFAULT_WIDTH 640
#define CSI_DEFAULT_HEIGHT 480
-const struct sun4i_csi_format sun4i_csi_formats[] = {
+const static struct sun4i_csi_format sun4i_csi_formats[] = {
/* YUV422 inputs */
{
.mbus = MEDIA_BUS_FMT_YUYV8_2X8,
--
2.21.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
* Re: Regression in 5.3-rc1 and later
From: Thomas Gleixner @ 2019-08-23 12:27 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-arch, linux-kselftest, Vincenzo Frascino, linux-mips,
daniel.lezcano, arnd, huw, andre.przywara, Chris Clayton,
will.deacon, LKML, ralf, salyzyn, paul.burton, linux, 0x7f454c46,
catalin.marinas, pcc, sthotton, shuah, linux-arm-kernel
In-Reply-To: <20190823105121.GA13294@shell.armlinux.org.uk>
On Fri, 23 Aug 2019, Russell King - ARM Linux admin wrote:
> On Fri, Aug 23, 2019 at 11:43:32AM +0100, Vincenzo Frascino wrote:
> > 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.
>
> I don't have access to the tip tree.
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent
> I'll wait a kernel release cycle instead.
It's going to be part of -rc6. I'll send the pull request to Linus tomorrow.
Thanks,
tglx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] input: keyboard: snvs_pwrkey: Send press and release event for i.MX6 S, DL and Q
From: Robin van der Gracht @ 2019-08-23 12:30 UTC (permalink / raw)
To: Robin van der Gracht
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer,
Dmitry Torokhov, linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, linux-input, Adam Ford, Robin Gong,
Fabio Estevam, linux-arm-kernel
The older generation i.MX6 processors send a powerdown request interrupt if
the powerkey is released before a hard shutdown (5 second press). This should
allow software to bring down the SoC safely.
For this driver to work as a regular powerkey with the older SoCs, we need to
send a keypress AND release when we get the powerdown request interrupt.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
---
arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
arch/arm/boot/dts/imx6sll.dtsi | 2 +-
arch/arm/boot/dts/imx6sx.dtsi | 2 +-
arch/arm/boot/dts/imx6ul.dtsi | 2 +-
arch/arm/boot/dts/imx7s.dtsi | 2 +-
drivers/input/keyboard/Kconfig | 2 +-
drivers/input/keyboard/snvs_pwrkey.c | 59 +++++++++++++++++++++++-----
7 files changed, 56 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b3a77bcf00d51..c10d12658743c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -836,7 +836,7 @@
};
snvs_pwrkey: snvs-powerkey {
- compatible = "fsl,sec-v4.0-pwrkey";
+ compatible = "fsl,imx6qdl-sec-v4.0-pwrkey";
regmap = <&snvs>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
linux,keycode = <KEY_POWER>;
diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index 1b4899f0fcded..91c7d5bdcc359 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -571,7 +571,7 @@
};
snvs_pwrkey: snvs-powerkey {
- compatible = "fsl,sec-v4.0-pwrkey";
+ compatible = "fsl,imx6sx-sec-v4.0-pwrkey";
regmap = <&snvs>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
linux,keycode = <KEY_POWER>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index b16a123990a26..b6736db65350f 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -733,7 +733,7 @@
};
snvs_pwrkey: snvs-powerkey {
- compatible = "fsl,sec-v4.0-pwrkey";
+ compatible = "fsl,imx6sx-sec-v4.0-pwrkey";
regmap = <&snvs>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
linux,keycode = <KEY_POWER>;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index a7f6d1d58e20d..d4678c52b55db 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -644,7 +644,7 @@
};
snvs_pwrkey: snvs-powerkey {
- compatible = "fsl,sec-v4.0-pwrkey";
+ compatible = "fsl,imx6sx-sec-v4.0-pwrkey";
regmap = <&snvs>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
linux,keycode = <KEY_POWER>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 106711d2c01b0..bb68c23beb199 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -604,7 +604,7 @@
};
snvs_pwrkey: snvs-powerkey {
- compatible = "fsl,sec-v4.0-pwrkey";
+ compatible = "fsl,imx6sx-sec-v4.0-pwrkey";
regmap = <&snvs>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
linux,keycode = <KEY_POWER>;
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 7c4f19dab34fd..937e58da5ce17 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -436,7 +436,7 @@ config KEYBOARD_SNVS_PWRKEY
depends on OF
help
This is the snvs powerkey driver for the Freescale i.MX application
- processors that are newer than i.MX6 SX.
+ processors.
To compile this driver as a module, choose M here; the
module will be called snvs_pwrkey.
diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
index 5342d8d45f811..c321e5f2d1087 100644
--- a/drivers/input/keyboard/snvs_pwrkey.c
+++ b/drivers/input/keyboard/snvs_pwrkey.c
@@ -29,6 +29,11 @@
#define DEBOUNCE_TIME 30
#define REPEAT_INTERVAL 60
+enum imx_snvs_hwtype {
+ IMX6SX_SNVS, /* i.MX6 SoloX and newer */
+ IMX6QDL_SNVS, /* i.MX6 Solo, DualLite adn Quad */
+};
+
struct pwrkey_drv_data {
struct regmap *snvs;
int irq;
@@ -37,6 +42,19 @@ struct pwrkey_drv_data {
int wakeup;
struct timer_list check_timer;
struct input_dev *input;
+ enum imx_snvs_hwtype hwtype;
+};
+
+static const struct platform_device_id imx_snvs_devtype[] = {
+ {
+ .name = "imx6sx-snvs-pwrkey",
+ .driver_data = IMX6SX_SNVS,
+ }, {
+ .name = "imx6qdl-snvs-pwrkey",
+ .driver_data = IMX6QDL_SNVS,
+ }, {
+ /* sentinel */
+ }
};
static void imx_imx_snvs_check_for_events(struct timer_list *t)
@@ -67,13 +85,23 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
{
struct platform_device *pdev = dev_id;
struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
+ struct input_dev *input = pdata->input;
u32 lp_status;
- pm_wakeup_event(pdata->input->dev.parent, 0);
+ pm_wakeup_event(input->dev.parent, 0);
regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
- if (lp_status & SNVS_LPSR_SPO)
- mod_timer(&pdata->check_timer, jiffies + msecs_to_jiffies(DEBOUNCE_TIME));
+ if (lp_status & SNVS_LPSR_SPO) {
+ if (pdata->hwtype == IMX6QDL_SNVS) {
+ input_report_key(input, pdata->keycode, 1);
+ input_report_key(input, pdata->keycode, 0);
+ input_sync(input);
+ pm_relax(input->dev.parent);
+ } else {
+ mod_timer(&pdata->check_timer,
+ jiffies + msecs_to_jiffies(DEBOUNCE_TIME));
+ }
+ }
/* clear SPO status */
regmap_write(pdata->snvs, SNVS_LPSR_REG, SNVS_LPSR_SPO);
@@ -88,11 +116,24 @@ static void imx_snvs_pwrkey_act(void *pdata)
del_timer_sync(&pd->check_timer);
}
+static const struct of_device_id imx_snvs_pwrkey_ids[] = {
+ {
+ .compatible = "fsl,imx6sx-sec-v4.0-pwrkey",
+ .data = &imx_snvs_devtype[IMX6SX_SNVS],
+ }, {
+ .compatible = "fsl,imx6qdl-sec-v4.0-pwrkey",
+ .data = &imx_snvs_devtype[IMX6QDL_SNVS],
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
+
static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
{
struct pwrkey_drv_data *pdata = NULL;
struct input_dev *input = NULL;
struct device_node *np;
+ const struct of_device_id *of_id;
int error;
/* Get SNVS register Page */
@@ -100,6 +141,11 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
if (!np)
return -ENODEV;
+ of_id = of_match_node(imx_snvs_pwrkey_ids, np);
+ if (!of_id)
+ return -ENODEV;
+ pdev->id_entry = of_id->data;
+
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
@@ -116,6 +162,7 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
}
pdata->wakeup = of_property_read_bool(np, "wakeup-source");
+ pdata->hwtype = pdev->id_entry->driver_data;
pdata->irq = platform_get_irq(pdev, 0);
if (pdata->irq < 0) {
@@ -175,12 +222,6 @@ static int imx_snvs_pwrkey_probe(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id imx_snvs_pwrkey_ids[] = {
- { .compatible = "fsl,sec-v4.0-pwrkey" },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
-
static struct platform_driver imx_snvs_pwrkey_driver = {
.driver = {
.name = "snvs_pwrkey",
--
2.20.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
* [PULL 4/5] Renesas driver updates for v5.4 (take two)
From: Geert Uytterhoeven @ 2019-08-23 12:36 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190823123643.18799-1-geert+renesas@glider.be>
The following changes since commit 0ed0eb0171d7c19310d9f7b06a6dee82a4fb8ab6:
soc: renesas: rcar-sysc: Use [] to denote a flexible array member (2019-07-29 15:36:56 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-drivers-for-v5.4-tag2
for you to fetch changes up to 2eced4607a1e6f51f928ae3e521fe02be5cb7d23:
soc: renesas: Enable ARM_ERRATA_754322 for affected Cortex-A9 (2019-08-23 10:33:31 +0200)
----------------------------------------------------------------
Renesas driver updates for v5.4 (take two)
- Improve "always-on" PM Domain handling on SH/R-Mobile SoCs,
- Automatic errata selection for Cortex-A7/A9,
- Small fixes and improvements.
----------------------------------------------------------------
Geert Uytterhoeven (4):
soc: renesas: rcar-sysc: Eliminate local variable gov
soc: renesas: rmobile-sysc: Set GENPD_FLAG_ALWAYS_ON for always-on domain
soc: renesas: Enable ARM_ERRATA_814220 for affected Cortex-A7
soc: renesas: Enable ARM_ERRATA_754322 for affected Cortex-A9
Nishka Dasgupta (1):
soc: renesas: rcar-sysc: Add goto to of_node_put() before return
drivers/soc/renesas/Kconfig | 11 +++++++++++
drivers/soc/renesas/rcar-sysc.c | 5 ++---
drivers/soc/renesas/rmobile-sysc.c | 31 ++++++++++++++++---------------
3 files changed, 29 insertions(+), 18 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 5/5] Renesas DT binding updates for v5.4 (take two)
From: Geert Uytterhoeven @ 2019-08-23 12:36 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190823123643.18799-1-geert+renesas@glider.be>
The following changes since commit 8cb7ec14188649cf2151464050413e2814fd7cf1:
dt-bindings: can: rcar_can: Complete documentation for RZ/G2[EM] (2019-07-29 15:36:39 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dt-bindings-for-v5.4-tag2
for you to fetch changes up to 7ac2d56f783d6d546e89a4e44fb46532667aa7a5:
dt-bindings: can: rcar_can: document r8a77470 support (2019-08-23 14:25:05 +0200)
----------------------------------------------------------------
Renesas DT binding updates for v5.4 (take two)
- Renesas DT binding doc filename cleanups,
- R-Car Gen3 and RZ/G1 updates for the R-Car CAN and CANFD DT
bindings.
----------------------------------------------------------------
Cao Van Dong (1):
dt-bindings: can: rcar_can: document r8a77470 support
Marek Vasut (1):
dt-bindings: can: rcar_can: document r8a77990 support
Niklas Söderlund (1):
dt-bindings: rcar-{csi2,vin}: Rename bindings documentation files
Simon Horman (2):
dt-bindings: Rename file of DT bindings for Renesas memory controllers
dt-bindings: rcar-imr: Rename bindings documentation file
Ulrich Hecht (2):
dt-bindings: can: rcar_can: document r8a77995 support
dt-bindings: can: rcar_canfd: document r8a77995 support
.../media/{renesas,rcar-csi2.txt => renesas,csi2.txt} | 0
.../bindings/media/{rcar_imr.txt => renesas,imr.txt} | 0
.../bindings/media/{rcar_vin.txt => renesas,vin.txt} | 0
.../{renesas-memory-controllers.txt => renesas,dbsc.txt} | 0
Documentation/devicetree/bindings/net/can/rcar_can.txt | 6 +++++-
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 14 +++++++-------
MAINTAINERS | 4 ++--
7 files changed, 14 insertions(+), 10 deletions(-)
rename Documentation/devicetree/bindings/media/{renesas,rcar-csi2.txt => renesas,csi2.txt} (100%)
rename Documentation/devicetree/bindings/media/{rcar_imr.txt => renesas,imr.txt} (100%)
rename Documentation/devicetree/bindings/media/{rcar_vin.txt => renesas,vin.txt} (100%)
rename Documentation/devicetree/bindings/memory-controllers/{renesas-memory-controllers.txt => renesas,dbsc.txt} (100%)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 2/5] Renesas ARM SoC updates for v5.4
From: Geert Uytterhoeven @ 2019-08-23 12:36 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190823123643.18799-1-geert+renesas@glider.be>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-soc-for-v5.4-tag1
for you to fetch changes up to e9670ccb39dbcfc934ae9533163e81a769d2cb82:
ARM: debug-ll: Add support for r7s9210 (2019-08-21 11:15:26 +0200)
----------------------------------------------------------------
Renesas ARM SoC updates for v5.4
- Low-level debugging support for RZ/A2M.
----------------------------------------------------------------
Geert Uytterhoeven (1):
ARM: debug-ll: Add support for r7s9210
arch/arm/Kconfig.debug | 20 +++++++++++++++++++-
arch/arm/include/debug/renesas-scif.S | 6 +++++-
2 files changed, 24 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 1/5] Renesas ARM DT updates for v5.4
From: Geert Uytterhoeven @ 2019-08-23 12:36 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190823123643.18799-1-geert+renesas@glider.be>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-dt-for-v5.4-tag1
for you to fetch changes up to 57012813f1ba82412cdcc3665b04d4353b357378:
ARM: dts: r8a77470: Add PMU device node (2019-08-21 10:28:57 +0200)
----------------------------------------------------------------
Renesas ARM DT updates for v5.4
- Fix HSCIF PM Domain on R-Car H1,
- PMU support for RZ/G1C.
----------------------------------------------------------------
Geert Uytterhoeven (2):
ARM: dts: r8a7779: Use SYSC "always-on" PM Domain for HSCIF
ARM: dts: r8a77470: Add PMU device node
arch/arm/boot/dts/r8a77470.dtsi | 7 +++++++
arch/arm/boot/dts/r8a7779.dtsi | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 3/5] Renesas ARM64 DT updates for v5.4 (take two)
From: Geert Uytterhoeven @ 2019-08-23 12:36 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190823123643.18799-1-geert+renesas@glider.be>
The following changes since commit 0a05b3d7fee511de8a1c9dffc3d86f1df55e1737:
arm64: dts: renesas: ulcb: Sort nodes (2019-07-30 11:25:35 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm64-dt-for-v5.4-tag2
for you to fetch changes up to 38290431d56d7d3928ac89e9f8d3d6b3c8df4c6e:
arm64: dts: renesas: Update 'vsps' properties for readability (2019-08-21 14:18:56 +0200)
----------------------------------------------------------------
Renesas ARM64 DT updates for v5.4 (take two)
- Sort nodes in various SoC and board DTSes,
- HDMI sound for HiHope RZ/G2M and R-Car M3-N Salvator-X(S) boards,
- Limit EtherAVB to 100Mbps on the Ebisu and Draak boards,
- Small fixes and improvements.
----------------------------------------------------------------
Fabrizio Castro (3):
arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1
arm64: dts: renesas: r8a774c0: cat874: Add definition for 12V regulator
arm64: dts: renesas: hihope-common: Add HDMI audio support
Geert Uytterhoeven (2):
arm64: dts: renesas: r8a77980: Fix IPMMU-VC0 base address
arm64: dts: renesas: r8a774c0: Fix register range of display node
Jacopo Mondi (1):
arm64: dts: renesas: Update 'vsps' properties for readability
Kuninori Morimoto (1):
arm64: dts: renesas: r8a77965-salvator-x(s): Enable HDMI sound
Simon Horman (1):
arm64: dts: renesas: ebisu, draak: Limit EtherAVB to 100Mbps
Yoshihiro Kaneko (13):
arm64: dts: renesas: r8a77970: eagle: Sort nodes
arm64: dts: renesas: r8a77970: v3msk: Sort nodes
arm64: dts: renesas: r8a77980: condor: Sort nodes
arm64: dts: renesas: r8a77980: v3hsk: Sort nodes
arm64: dts: renesas: r8a77990: ebisu: Sort nodes
arm64: dts: renesas: r8a77990: Sort nodes
arm64: dts: renesas: r8a77995: draak: Sort nodes
arm64: dts: renesas: r8a77995: Sort nodes
arm64: dts: renesas: r8a774a1: Sort nodes
arm64: dts: renesas: r8a774c0: cat874: Sort nodes
arm64: dts: renesas: r8a774c0: Sort nodes
arm64: dts: renesas: r8a7796: Sort nodes
arm64: dts: renesas: r8a77970: Sort nodes
arch/arm64/boot/dts/renesas/hihope-common.dtsi | 47 +++++
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 174 ++++++++---------
arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 37 ++--
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 96 ++++-----
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 152 +++++++--------
.../arm64/boot/dts/renesas/r8a77965-salvator-x.dts | 28 +++
.../boot/dts/renesas/r8a77965-salvator-xs.dts | 28 +++
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 58 +++---
arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts | 116 +++++------
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 6 +-
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 42 ++--
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 12 +-
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 4 +-
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 216 +++++++++++----------
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 46 ++---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 18 +-
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 78 ++++----
19 files changed, 646 insertions(+), 516 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 0/5] Renesas SoC updates for v5.4 (take two)
From: Geert Uytterhoeven @ 2019-08-23 12:36 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
Hi arm-soc folks,
This is my second pull request for the inclusion of Renesas SoC updates
for v5.4.
It consists of 5 parts:
[PULL 1/5] Renesas ARM DT updates for v5.4
- Fix HSCIF PM Domain on R-Car H1,
- PMU support for RZ/G1C.
[PULL 2/5] Renesas ARM SoC updates for v5.4
- Low-level debugging support for RZ/A2M.
[PULL 3/5] Renesas ARM64 DT updates for v5.4 (take two)
- Sort nodes in various SoC and board DTSes,
- HDMI sound for HiHope RZ/G2M and R-Car M3-N Salvator-X(S) boards,
- Limit EtherAVB to 100Mbps on the Ebisu and Draak boards,
- Small fixes and improvements.
[PULL 4/5] Renesas driver updates for v5.4 (take two)
- Improve "always-on" PM Domain handling on SH/R-Mobile SoCs,
- Automatic errata selection for Cortex-A7/A9,
- Small fixes and improvements.
[PULL 5/5] Renesas DT binding updates for v5.4 (take two)
- Renesas DT binding doc filename cleanups,
- R-Car Gen3 and RZ/G1 updates for the R-Car CAN and CANFD DT
bindings.
For now I more or less followed Simon's way of structuring the branches,
but I'm open for change. Hence if you have any comments, or suggestions
for improving the workflow, please let me know.
Thanks for pulling, and for your comments!
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
* Re: [PATCH v2 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Masahiro Yamada @ 2019-08-23 12:49 UTC (permalink / raw)
To: Nicolin Chen, Christoph Hellwig
Cc: Chris Zankel, linux-xtensa, Kees Cook, Stephen Rothwell,
Tony Lindgren, Catalin Marinas, Joerg Roedel, Will Deacon,
Russell King, iommu, Linux Kernel Mailing List, Max Filippov,
Wolfram Sang, iamjoonsoo.kim, Andrew Morton, Thierry Reding,
Robin Murphy, David Woodhouse, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190506223334.1834-3-nicoleotsuka@gmail.com>
On Tue, May 7, 2019 at 7:36 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> The addresses within a single page are always contiguous, so it's
> not so necessary to always allocate one single page from CMA area.
> Since the CMA area has a limited predefined size of space, it may
> run out of space in heavy use cases, where there might be quite a
> lot CMA pages being allocated for single pages.
>
> However, there is also a concern that a device might care where a
> page comes from -- it might expect the page from CMA area and act
> differently if the page doesn't.
>
> This patch tries to use the fallback alloc_pages path, instead of
> one-page size allocations from the global CMA area in case that a
> device does not have its own CMA area. This'd save resources from
> the CMA global area for more CMA allocations, and also reduce CMA
> fragmentations resulted from trivial allocations.
>
> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
This commit (bd2e75633c8012fc8a7431c82fda66237133bf7e)
broke the DMA for my MMC driver in the following way:
[ 1.876755] mmc0: ADMA error
[ 1.883385] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 1.889834] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
[ 1.896284] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
[ 1.902733] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
[ 1.909182] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
[ 1.915631] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
[ 1.922081] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000fa07
[ 1.928530] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
[ 1.934981] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
[ 1.941429] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
[ 1.947880] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
[ 1.954329] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
[ 1.960778] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
[ 1.967229] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
[ 1.973678] mmc0: sdhci: Host ctl2: 0x00000000
[ 1.978125] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
[ 1.985271] mmc0: sdhci: ============================================
[ 1.991758] mmc0: error -5 whilst initialising MMC card
[ 1.991913] 43fb0000.uart: ttyS1 at MMIO 0x43fb0000 (irq = 0,
base_baud = 768000) is a 16550A
[ 2.011011] hctosys: unable to open rtc device (rtc0)
[ 2.017694] Freeing unused kernel memory: 2368K
[ 2.027131] Run /init as init process
Starting syslogd: OK
Starting klogd: OK
Initializing random number generator... [ 2.074399] random: dd:
uninitialized urandom read (512 bytes read)
done.
Starting network: OK
[ 2.109593] mmc0: ADMA error
[ 2.112488] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 2.118941] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
[ 2.125389] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
[ 2.131840] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
[ 2.138289] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
[ 2.144738] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
[ 2.151188] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00004e47
[ 2.157637] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
[ 2.164087] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
[ 2.170536] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
[ 2.176987] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
[ 2.183435] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
[ 2.189886] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
[ 2.196335] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
[ 2.202784] mmc0: sdhci: Host ctl2: 0x00000000
[ 2.207232] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
[ 2.214379] mmc0: sdhci: ============================================
[ 2.220881] mmc0: error -5 whilst initialising MMC card
Welcome to Buildroot
buildroot login: [ 2.332786] mmc0: ADMA error
[ 2.335668] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 2.342119] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
[ 2.348568] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
[ 2.355018] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
[ 2.361468] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
[ 2.367917] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
[ 2.374367] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
[ 2.380816] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
[ 2.387267] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
[ 2.393716] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
[ 2.400166] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
[ 2.406615] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
[ 2.413065] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
[ 2.419515] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
[ 2.425963] mmc0: sdhci: Host ctl2: 0x00000000
[ 2.430412] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
[ 2.437557] mmc0: sdhci: ============================================
[ 2.444031] mmc0: error -5 whilst initialising MMC card
[ 2.572203] mmc0: ADMA error
[ 2.575089] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 2.581540] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
[ 2.587989] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
[ 2.594439] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
[ 2.600889] mmc0: sdhci: Present: 0x01ef02f6 | Host ctl: 0x00000019
[ 2.607339] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
[ 2.613788] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000e8c7
[ 2.620237] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
[ 2.626686] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
[ 2.633137] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
[ 2.639586] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
[ 2.646036] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
[ 2.652485] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
[ 2.658936] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
[ 2.665384] mmc0: sdhci: Host ctl2: 0x00000000
[ 2.669832] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
[ 2.676979] mmc0: sdhci: ============================================
[ 2.683450] mmc0: error -5 whilst initialising MMC card
CTRL-A Z for help | 115200 8N1 | NOR | Minicom 2.7.1 | VT102 | Offline
| ttyUSB0
Reverting this commit fixed the problem.
--
Best Regards
Masahiro Yamada
_______________________________________________
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 2/8] ab8500_charger.c:undefined reference to `iio_read_channel_processed'
From: kbuild test robot @ 2019-08-23 12:51 UTC (permalink / raw)
To: Linus Walleij; +Cc: kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-stericsson.git ab8500-gpadc
head: b9fc9832627e121832ebbcb26426f700f4fde9db
commit: 8a2099cccf09e0fffb905cb861b0052d456519d7 [2/8] power: supply: ab8500_charger: 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 8a2099cccf09e0fffb905cb861b0052d456519d7
# 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_charger.o: In function `ab8500_charger_usb_get_property':
>> ab8500_charger.c:(.text+0x2fc4): undefined reference to `iio_read_channel_processed'
ab8500_charger.c:(.text+0x30c4): undefined reference to `iio_read_channel_processed'
drivers/power/supply/ab8500_charger.o: In function `ab8500_charger_ac_get_property':
ab8500_charger.c:(.text+0x331c): undefined reference to `iio_read_channel_processed'
ab8500_charger.c:(.text+0x341c): undefined reference to `iio_read_channel_processed'
drivers/power/supply/ab8500_charger.o: In function `ab8500_charger_probe':
>> ab8500_charger.c:(.text+0x46cc): undefined reference to `devm_iio_channel_get'
ab8500_charger.c:(.text+0x471c): undefined reference to `devm_iio_channel_get'
ab8500_charger.c:(.text+0x4764): undefined reference to `devm_iio_channel_get'
ab8500_charger.c:(.text+0x47ac): undefined reference to `devm_iio_channel_get'
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
* [PATCH 1/5] dmaengine: ti: edma: Do not reset reserved paRAM slots
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
To: vkoul, robh+dt
Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
linux-arm-kernel
In-Reply-To: <20190823125618.8133-1-peter.ujfalusi@ti.com>
Skip resetting paRAM slots marked as reserved as they might be used by
other cores.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti/edma.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index 54895112ba59..1aae95cc0d4b 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -2338,9 +2338,6 @@ static int edma_probe(struct platform_device *pdev)
ecc->default_queue = info->default_queue;
- for (i = 0; i < ecc->num_slots; i++)
- edma_write_slot(ecc, i, &dummy_paramset);
-
if (info->rsv) {
/* Set the reserved slots in inuse list */
rsv_slots = info->rsv->rsv_slots;
@@ -2353,6 +2350,12 @@ static int edma_probe(struct platform_device *pdev)
}
}
+ for (i = 0; i < ecc->num_slots; i++) {
+ /* Reset only unused - not reserved - paRAM slots */
+ if (!test_bit(i, ecc->slot_inuse))
+ edma_write_slot(ecc, i, &dummy_paramset);
+ }
+
/* Clear the xbar mapped channels in unused list */
xbar_chans = info->xbar_chans;
if (xbar_chans) {
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 0/5] dmaengine: ti: edma: Multicore usage related fixes
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
To: vkoul, robh+dt
Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
linux-arm-kernel
Hi,
When other cores want to use EDMA for their use cases Linux was not playing
nicely.
By design EDMA is supporting shared use with shadow regions. Linux is using
region0, others can be used by other cores.
In order to not break multicore shared usage of EDMA:
- do not reset paRAM slots which is not allocated for Linux (reserved paRAM
slots)
- Only reset region0 access registers, do not touch other regions
- Add option for reserved channels which should not be used by Linux in a similar
fashion as we already have for reserved paRAM slots.
Regards,
Peter
---
Peter Ujfalusi (5):
dmaengine: ti: edma: Do not reset reserved paRAM slots
dmaengine: ti: edma: Only reset region0 access registers
dmaengine: ti: edma: Use bitmap_set() instead of open coded
edma_set_bits()
dt-bindings: dma: ti-edma: Add option for reserved channel ranges
dmaengine: ti: edma: Add support for handling reserved channels
.../devicetree/bindings/dma/ti-edma.txt | 5 +
drivers/dma/ti/edma.c | 190 +++++++++++-------
2 files changed, 123 insertions(+), 72 deletions(-)
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/5] dmaengine: ti: edma: Only reset region0 access registers
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
To: vkoul, robh+dt
Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
linux-arm-kernel
In-Reply-To: <20190823125618.8133-1-peter.ujfalusi@ti.com>
Region0 is used by Linux, do not reset other registers controlling access
for other shadow regions.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti/edma.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index 1aae95cc0d4b..87450431f336 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -2434,11 +2434,10 @@ static int edma_probe(struct platform_device *pdev)
edma_assign_priority_to_queue(ecc, queue_priority_mapping[i][0],
queue_priority_mapping[i][1]);
- for (i = 0; i < ecc->num_region; i++) {
- edma_write_array2(ecc, EDMA_DRAE, i, 0, 0x0);
- edma_write_array2(ecc, EDMA_DRAE, i, 1, 0x0);
- edma_write_array(ecc, EDMA_QRAE, i, 0x0);
- }
+ edma_write_array2(ecc, EDMA_DRAE, 0, 0, 0x0);
+ edma_write_array2(ecc, EDMA_DRAE, 0, 1, 0x0);
+ edma_write_array(ecc, EDMA_QRAE, 0, 0x0);
+
ecc->info = info;
/* Init the dma device and channels */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 3/5] dmaengine: ti: edma: Use bitmap_set() instead of open coded edma_set_bits()
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
To: vkoul, robh+dt
Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
linux-arm-kernel
In-Reply-To: <20190823125618.8133-1-peter.ujfalusi@ti.com>
bitmap_set() is the standard way of setting an area in the bitfield.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti/edma.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index 87450431f336..ba7c4f07fcd6 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -15,6 +15,7 @@
#include <linux/dmaengine.h>
#include <linux/dma-mapping.h>
+#include <linux/bitmap.h>
#include <linux/err.h>
#include <linux/init.h>
#include <linux/interrupt.h>
@@ -423,12 +424,6 @@ static inline void edma_param_or(struct edma_cc *ecc, int offset, int param_no,
edma_or(ecc, EDMA_PARM + offset + (param_no << 5), or);
}
-static inline void edma_set_bits(int offset, int len, unsigned long *p)
-{
- for (; len > 0; len--)
- set_bit(offset + (len - 1), p);
-}
-
static void edma_assign_priority_to_queue(struct edma_cc *ecc, int queue_no,
int priority)
{
@@ -2254,7 +2249,7 @@ static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info *info = pdev->dev.platform_data;
s8 (*queue_priority_mapping)[2];
- int i, off, ln;
+ int i, off;
const s16 (*rsv_slots)[2];
const s16 (*xbar_chans)[2];
int irq;
@@ -2342,11 +2337,9 @@ static int edma_probe(struct platform_device *pdev)
/* Set the reserved slots in inuse list */
rsv_slots = info->rsv->rsv_slots;
if (rsv_slots) {
- for (i = 0; rsv_slots[i][0] != -1; i++) {
- off = rsv_slots[i][0];
- ln = rsv_slots[i][1];
- edma_set_bits(off, ln, ecc->slot_inuse);
- }
+ for (i = 0; rsv_slots[i][0] != -1; i++)
+ bitmap_set(ecc->slot_inuse, rsv_slots[i][0],
+ rsv_slots[i][1]);
}
}
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 5/5] dmaengine: ti: edma: Add support for handling reserved channels
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
To: vkoul, robh+dt
Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
linux-arm-kernel
In-Reply-To: <20190823125618.8133-1-peter.ujfalusi@ti.com>
Like paRAM slots, channels could be used by other cores and in this case
we need to make sure that the driver do not alter these channels.
Move the reserved slot/channel query from DT to a separate function for
cleaner implementation.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti/edma.c | 161 +++++++++++++++++++++++++++---------------
1 file changed, 106 insertions(+), 55 deletions(-)
diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index ba7c4f07fcd6..5201aeebf5c1 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -260,6 +260,9 @@ struct edma_cc {
*/
unsigned long *slot_inuse;
+ /* for tracking reserved channels used by DSP */
+ unsigned long *reserved_chans;
+
struct dma_device dma_slave;
struct dma_device *dma_memcpy;
struct edma_chan *slave_chans;
@@ -716,6 +719,12 @@ static int edma_alloc_channel(struct edma_chan *echan,
struct edma_cc *ecc = echan->ecc;
int channel = EDMA_CHAN_SLOT(echan->ch_num);
+ if (test_bit(echan->ch_num, ecc->reserved_chans)) {
+ dev_err(ecc->dev, "Channel%d is reserved, can not be used!\n",
+ echan->ch_num);
+ return -EINVAL;
+ }
+
/* ensure access through shadow region 0 */
edma_or_array2(ecc, EDMA_DRAE, 0, EDMA_REG_ARRAY_INDEX(channel),
EDMA_CHANNEL_BIT(channel));
@@ -2096,6 +2105,76 @@ static int edma_xbar_event_map(struct device *dev, struct edma_soc_info *pdata,
return 0;
}
+static struct edma_rsv_info *edma_get_reserved_ranges_dt(struct device *dev)
+{
+ static const char * const prop_names[] = {
+ "ti,edma-reserved-slot-ranges",
+ "ti,edma-reserved-chan-ranges"
+ };
+ struct edma_rsv_info *rsv_info = NULL;
+ struct property *props[2];
+ int sz[2], i, ret;
+
+ for (i = 0; i < 2; i++)
+ props[i] = of_find_property(dev->of_node, prop_names[i],
+ &sz[i]);
+
+ if (!props[0] && !props[1])
+ return NULL;
+
+ rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return ERR_PTR(-ENOMEM);
+
+ for (i = 0; i < 2; i++) {
+ u32 (*tmp)[2];
+ s16 (*reserved)[2];
+ size_t nelm;
+ int j;
+
+ if (!props[i])
+ continue;
+
+ nelm = sz[i] / sizeof(*tmp);
+ if (!nelm)
+ continue;
+
+ tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return ERR_PTR(-ENOMEM);
+
+ reserved = devm_kcalloc(dev, nelm + 1, sizeof(*reserved),
+ GFP_KERNEL);
+ if (!reserved) {
+ kfree(tmp);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ ret = of_property_read_u32_array(dev->of_node, prop_names[i],
+ (u32 *)tmp, nelm * 2);
+ if (ret) {
+ kfree(tmp);
+ return ERR_PTR(ret);
+ }
+
+ for (j = 0; j < nelm; j++) {
+ reserved[j][0] = tmp[j][0];
+ reserved[j][1] = tmp[j][1];
+ }
+ reserved[nelm][0] = -1;
+ reserved[nelm][1] = -1;
+
+ if (i == 0)
+ rsv_info->rsv_slots = (const s16 (*)[2])reserved;
+ else if (i == 1)
+ rsv_info->rsv_chans = (const s16 (*)[2])reserved;
+
+ kfree(tmp);
+ }
+
+ return rsv_info;
+}
+
static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
bool legacy_mode)
{
@@ -2139,55 +2218,9 @@ static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
info->memcpy_channels = memcpy_ch;
}
- prop = of_find_property(dev->of_node, "ti,edma-reserved-slot-ranges",
- &sz);
- if (prop) {
- const char pname[] = "ti,edma-reserved-slot-ranges";
- u32 (*tmp)[2];
- s16 (*rsv_slots)[2];
- size_t nelm = sz / sizeof(*tmp);
- struct edma_rsv_info *rsv_info;
- int i;
-
- if (!nelm)
- return info;
-
- tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
- if (!tmp)
- return ERR_PTR(-ENOMEM);
-
- rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
- if (!rsv_info) {
- kfree(tmp);
- return ERR_PTR(-ENOMEM);
- }
-
- rsv_slots = devm_kcalloc(dev, nelm + 1, sizeof(*rsv_slots),
- GFP_KERNEL);
- if (!rsv_slots) {
- kfree(tmp);
- return ERR_PTR(-ENOMEM);
- }
-
- ret = of_property_read_u32_array(dev->of_node, pname,
- (u32 *)tmp, nelm * 2);
- if (ret) {
- kfree(tmp);
- return ERR_PTR(ret);
- }
-
- for (i = 0; i < nelm; i++) {
- rsv_slots[i][0] = tmp[i][0];
- rsv_slots[i][1] = tmp[i][1];
- }
- rsv_slots[nelm][0] = -1;
- rsv_slots[nelm][1] = -1;
-
- info->rsv = rsv_info;
- info->rsv->rsv_slots = (const s16 (*)[2])rsv_slots;
-
- kfree(tmp);
- }
+ info->rsv = edma_get_reserved_ranges_dt(dev);
+ if (IS_ERR(info->rsv))
+ return ERR_CAST(info->rsv);
return info;
}
@@ -2250,7 +2283,7 @@ static int edma_probe(struct platform_device *pdev)
struct edma_soc_info *info = pdev->dev.platform_data;
s8 (*queue_priority_mapping)[2];
int i, off;
- const s16 (*rsv_slots)[2];
+ const s16 (*reserved)[2];
const s16 (*xbar_chans)[2];
int irq;
char *irq_name;
@@ -2331,15 +2364,29 @@ static int edma_probe(struct platform_device *pdev)
if (!ecc->slot_inuse)
return -ENOMEM;
+ ecc->reserved_chans = devm_kcalloc(dev,
+ BITS_TO_LONGS(ecc->num_channels),
+ sizeof(unsigned long), GFP_KERNEL);
+ if (!ecc->reserved_chans)
+ return -ENOMEM;
+
ecc->default_queue = info->default_queue;
if (info->rsv) {
/* Set the reserved slots in inuse list */
- rsv_slots = info->rsv->rsv_slots;
- if (rsv_slots) {
- for (i = 0; rsv_slots[i][0] != -1; i++)
- bitmap_set(ecc->slot_inuse, rsv_slots[i][0],
- rsv_slots[i][1]);
+ reserved = info->rsv->rsv_slots;
+ if (reserved) {
+ for (i = 0; reserved[i][0] != -1; i++)
+ bitmap_set(ecc->slot_inuse, reserved[i][0],
+ reserved[i][1]);
+ }
+
+ /* Mark reserved channels */
+ reserved = info->rsv->rsv_chans;
+ if (reserved) {
+ for (i = 0; reserved[i][0] != -1; i++)
+ bitmap_set(ecc->reserved_chans, reserved[i][0],
+ reserved[i][1]);
}
}
@@ -2437,6 +2484,10 @@ static int edma_probe(struct platform_device *pdev)
edma_dma_init(ecc, legacy_mode);
for (i = 0; i < ecc->num_channels; i++) {
+ /* Do not touch reserved channels */
+ if (test_bit(i, ecc->reserved_chans))
+ continue;
+
/* Assign all channels to the default queue */
edma_assign_channel_eventq(&ecc->slave_chans[i],
info->default_queue);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
To: vkoul, robh+dt
Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
linux-arm-kernel
In-Reply-To: <20190823125618.8133-1-peter.ujfalusi@ti.com>
Similarly to paRAM slots, channels can be used by other cores.
Add optional property to configure the reserved channel ranges.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 4bbc94d829c8..1198682ada99 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -42,6 +42,9 @@ Optional properties:
- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
the driver, they are allocated to be used by for example the
DSP. See example.
+- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
+ the driver, they are allocated to be used by for example the
+ DSP. See example.
------------------------------------------------------------------------------
eDMA3 Transfer Controller
@@ -91,6 +94,8 @@ edma: edma@49000000 {
ti,edma-memcpy-channels = <20 21>;
/* The following PaRAM slots are reserved: 35-44 and 100-109 */
ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
+ /* The following channels are reserved: 35-44 */
+ ti,edma-reserved-chan-ranges = <35 10>;
};
edma_tptc0: tptc@49800000 {
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Mark Rutland @ 2019-08-23 12:57 UTC (permalink / raw)
To: Joakim Zhang
Cc: will@kernel.org, robin.murphy@arm.com,
linux-arm-kernel@lists.infradead.org, Frank Li, dl-linux-imx
In-Reply-To: <20190808064216.6950-2-qiangqing.zhang@nxp.com>
On Thu, Aug 08, 2019 at 06:45:29AM +0000, Joakim Zhang wrote:
> AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> writes with an ARID or AXID matching filter setting. Granularity is at
> subsystem level. Implementation does not allow filtring between masters
> within a subsystem. Filter is defined with 2 configuration registers.
>
> --AXI_ID defines AxID matching value
> --AXI_MASKING defines which bits of AxID are meaningful for the matching
>
> When non-masked bits are matching corresponding AXI_ID bits then counter
> is incremented. This filter allows counting read or write access from a
> subsystem or multiple subsystems.
>
> Perf counter is incremented if AxID && AXI_MASKING == AXI_ID && AXI_MASKING
Just to check, the filter does not affect other events, right?
>
> AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
>
> Read and write AXI ID filter should write same value to DPCR1 if want to
> specify at the same time as this filter is shared between counters.
>
> e.g.
> perf stat -a -e imx8_ddr0/axi-id-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axi-id-write,axi_id=0xMMMMDDDD/ cmd
> MMMM: AXI_MASKING
> DDDD: AXI_ID
You might want to expose this to userspace as two fields:
axi_id=DDDD
axi_mask=MMMM
... where axi_mask is inverted (i.e. set bits are bits to ignore), so
that the user can just specify axi_id to monitor a specific id, rather
than having to specifiy axi_id=0xffff<id>.
>
> ChangeLog:
> V1 -> V2:
> * add error log if user specifies read/write AXI ID filter at
> the same time.
> * of_device_get_match_data() instead of of_match_device(), and
> remove the check of return value.
> V2 -> V3:
> * move the AXI ID check to event_add().
> * add support for same value of axi_id.
> V3 -> V4:
> * move the AXI ID check to event_init().
> V4 -> V5:
> * reject event group if AXI ID not consistent in event_init().
>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
> drivers/perf/fsl_imx8_ddr_perf.c | 63 +++++++++++++++++++++++++++++++-
> 1 file changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
> index 63fe21600072..f25cf5cbe156 100644
> --- a/drivers/perf/fsl_imx8_ddr_perf.c
> +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> @@ -42,9 +42,22 @@
>
> static DEFINE_IDA(ddr_ida);
>
> +/* DDR Perf hardware feature */
> +#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter */
> +
> +struct fsl_ddr_devtype_data {
> + unsigned int quirks; /* quirks needed for different DDR Perf core */
> +};
> +
> +static const struct fsl_ddr_devtype_data imx8_devtype_data;
> +
> +static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
> + .quirks = DDR_CAP_AXI_ID_FILTER,
> +};
> +
> static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> - { .compatible = "fsl,imx8-ddr-pmu",},
> - { .compatible = "fsl,imx8m-ddr-pmu",},
> + { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
> + { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
> { /* sentinel */ }
> };
Are new DDR PMUs going to lack this feature?
If all PMUs the driver supports have it, then we don't need this
quirk/feature list.
That would make the subsequent code a bit nicer, as all the filtering
code would lose a level of indentation.
>
> @@ -57,6 +70,7 @@ struct ddr_pmu {
> struct perf_event *events[NUM_COUNTERS];
> int active_events;
> enum cpuhp_state cpuhp_state;
> + const struct fsl_ddr_devtype_data *devtype_data;
> int irq;
> int id;
> };
> @@ -128,6 +142,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
> IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
> IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
> + IMX8_DDR_PMU_EVENT_ATTR(axi-id-read, 0x41),
> + IMX8_DDR_PMU_EVENT_ATTR(axi-id-write, 0x42),
> NULL,
> };
>
> @@ -137,9 +153,11 @@ static struct attribute_group ddr_perf_events_attr_group = {
> };
>
> PMU_FORMAT_ATTR(event, "config:0-7");
> +PMU_FORMAT_ATTR(axi_id, "config1:0-31");
>
> static struct attribute *ddr_perf_format_attrs[] = {
> &format_attr_event.attr,
> + &format_attr_axi_id.attr,
> NULL,
> };
>
> @@ -189,6 +207,16 @@ static u32 ddr_perf_read_counter(struct ddr_pmu *pmu, int counter)
> return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
> }
>
> +static bool ddr_perf_is_filtered(struct perf_event *event)
> +{
> + return event->attr.config == 0x41 || event->attr.config == 0x42;
> +}
> +
> +static u32 ddr_perf_filter_val(struct perf_event *event)
> +{
> + return event->attr.config1;
> +}
> +
Let's add another helper:
static bool ddr_perf_filters_compatible(struct perf_event *a,
struct perf_event *b)
{
if (!ddr_perf_is_filtered(a))
return true;
if (!ddr_perf_is_filtered(b))
return true;
return ddr_perf_filter_val(a) == ddr_perf_filter_val(b);
}
> static int ddr_perf_event_init(struct perf_event *event)
> {
> struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
> @@ -215,6 +243,18 @@ static int ddr_perf_event_init(struct perf_event *event)
> !is_software_event(event->group_leader))
> return -EINVAL;
>
> + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> + bool is_filtered = ddr_perf_is_filtered(event);
> + u32 filter_val = ddr_perf_filter_val(event);
> +
> + for_each_sibling_event(sibling, event->group_leader) {
> + if (is_filtered && ddr_perf_is_filtered(sibling) &&
> + ddr_perf_filter_val(sibling) != filter_val) {
> + return -EINVAL;
> + }
> + }
> + }
... so this can be:
if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
if (!ddr_perf_filters_compatible(event, event->group_leader))
return -EINVAL;
for_each_sibling_event(sibling, event->group_leader) {
if (!ddr_perf_filters_compatible(event, sibling))
return -EINVAL;
}
}
Note: that checks group_leader, which you mised above. When the event is
the group leader, it's trivially compatible with itself, so we don't
need a special case there.
> +
> for_each_sibling_event(sibling, event->group_leader) {
> if (sibling->pmu != event->pmu &&
> !is_software_event(sibling))
> @@ -288,6 +328,23 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
> int counter;
> int cfg = event->attr.config;
>
> + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> + int i;
> + bool is_filtered = ddr_perf_is_filtered(event);
> + u32 filter_val = ddr_perf_filter_val(event);
> +
> + for (i = 1; i < NUM_COUNTERS; i++) {
> + if (is_filtered && pmu->events[i] &&
> + ddr_perf_is_filtered(pmu->events[i]) &&
> + ddr_perf_filter_val(pmu->events[i]) != filter_val) {
> + dev_dbg(pmu->dev, "Contradictory axi id filter value\n");
> + return -EINVAL;
> + }
> + }
... and likewise:
if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
int i;
for (i = 1; i < NUM_COUNTERS; i++) {
if (!ddr_perf_filters_compatible(event, pmu->events[i]))
return -EINVAL;
}
}
Please drop the dev_dbg() here, since when perf rotates events this can
happen many times per second, and it's entirely legitimate.
Otherwise, this looks good to me.
Thanks,
Mark.
> +
> + writel(filter_val, pmu->base + COUNTER_DPCR1);
> + }
> +
> counter = ddr_perf_alloc_counter(pmu, cfg);
> if (counter < 0) {
> dev_dbg(pmu->dev, "There are not enough counters\n");
> @@ -472,6 +529,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
> if (!name)
> return -ENOMEM;
>
> + pmu->devtype_data = of_device_get_match_data(&pdev->dev);
> +
> pmu->cpu = raw_smp_processor_id();
> ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
> DDR_CPUHP_CB_NAME,
> --
> 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
* Re: [PATCH v2 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Masahiro Yamada @ 2019-08-23 12:56 UTC (permalink / raw)
To: Nicolin Chen, Christoph Hellwig, linux-mmc, Ulf Hansson,
Adrian Hunter
Cc: Chris Zankel, linux-xtensa, Kees Cook, Stephen Rothwell,
Tony Lindgren, Catalin Marinas, Joerg Roedel, Will Deacon,
Russell King, iommu, Linux Kernel Mailing List, Max Filippov,
Wolfram Sang, iamjoonsoo.kim, Andrew Morton, Thierry Reding,
Robin Murphy, David Woodhouse, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <CAK7LNARacEorb38mVBw_V-Zvz-znWgBma1AP1-z_5B_xZU4ogg@mail.gmail.com>
+ linux-mmc, Ulf Hansson, Adrian Hunter,
ADMA of SDHCI is not working
since bd2e75633c8012fc8a7431c82fda66237133bf7e
Did anybody see the same problem?
Masahiro
On Fri, Aug 23, 2019 at 9:49 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> On Tue, May 7, 2019 at 7:36 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> >
> > The addresses within a single page are always contiguous, so it's
> > not so necessary to always allocate one single page from CMA area.
> > Since the CMA area has a limited predefined size of space, it may
> > run out of space in heavy use cases, where there might be quite a
> > lot CMA pages being allocated for single pages.
> >
> > However, there is also a concern that a device might care where a
> > page comes from -- it might expect the page from CMA area and act
> > differently if the page doesn't.
> >
> > This patch tries to use the fallback alloc_pages path, instead of
> > one-page size allocations from the global CMA area in case that a
> > device does not have its own CMA area. This'd save resources from
> > the CMA global area for more CMA allocations, and also reduce CMA
> > fragmentations resulted from trivial allocations.
> >
> > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
>
>
> This commit (bd2e75633c8012fc8a7431c82fda66237133bf7e)
> broke the DMA for my MMC driver in the following way:
>
>
>
>
> [ 1.876755] mmc0: ADMA error
> [ 1.883385] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 1.889834] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
> [ 1.896284] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
> [ 1.902733] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> [ 1.909182] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
> [ 1.915631] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
> [ 1.922081] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000fa07
> [ 1.928530] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
> [ 1.934981] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
> [ 1.941429] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 1.947880] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
> [ 1.954329] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
> [ 1.960778] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
> [ 1.967229] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
> [ 1.973678] mmc0: sdhci: Host ctl2: 0x00000000
> [ 1.978125] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
> [ 1.985271] mmc0: sdhci: ============================================
> [ 1.991758] mmc0: error -5 whilst initialising MMC card
> [ 1.991913] 43fb0000.uart: ttyS1 at MMIO 0x43fb0000 (irq = 0,
> base_baud = 768000) is a 16550A
> [ 2.011011] hctosys: unable to open rtc device (rtc0)
> [ 2.017694] Freeing unused kernel memory: 2368K
> [ 2.027131] Run /init as init process
> Starting syslogd: OK
> Starting klogd: OK
> Initializing random number generator... [ 2.074399] random: dd:
> uninitialized urandom read (512 bytes read)
> done.
> Starting network: OK
> [ 2.109593] mmc0: ADMA error
> [ 2.112488] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 2.118941] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
> [ 2.125389] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
> [ 2.131840] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> [ 2.138289] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
> [ 2.144738] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
> [ 2.151188] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00004e47
> [ 2.157637] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
> [ 2.164087] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
> [ 2.170536] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 2.176987] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
> [ 2.183435] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
> [ 2.189886] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
> [ 2.196335] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
> [ 2.202784] mmc0: sdhci: Host ctl2: 0x00000000
> [ 2.207232] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
> [ 2.214379] mmc0: sdhci: ============================================
>
> [ 2.220881] mmc0: error -5 whilst initialising MMC card
> Welcome to Buildroot
> buildroot login: [ 2.332786] mmc0: ADMA error
> [ 2.335668] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 2.342119] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
> [ 2.348568] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
> [ 2.355018] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> [ 2.361468] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
> [ 2.367917] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
> [ 2.374367] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
> [ 2.380816] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
> [ 2.387267] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
> [ 2.393716] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 2.400166] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
> [ 2.406615] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
> [ 2.413065] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
> [ 2.419515] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
> [ 2.425963] mmc0: sdhci: Host ctl2: 0x00000000
> [ 2.430412] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
> [ 2.437557] mmc0: sdhci: ============================================
> [ 2.444031] mmc0: error -5 whilst initialising MMC card
> [ 2.572203] mmc0: ADMA error
> [ 2.575089] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 2.581540] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
> [ 2.587989] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
> [ 2.594439] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> [ 2.600889] mmc0: sdhci: Present: 0x01ef02f6 | Host ctl: 0x00000019
> [ 2.607339] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
> [ 2.613788] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000e8c7
> [ 2.620237] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
> [ 2.626686] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
> [ 2.633137] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 2.639586] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
> [ 2.646036] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
> [ 2.652485] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
> [ 2.658936] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
> [ 2.665384] mmc0: sdhci: Host ctl2: 0x00000000
> [ 2.669832] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
> [ 2.676979] mmc0: sdhci: ============================================
> [ 2.683450] mmc0: error -5 whilst initialising MMC card
>
> CTRL-A Z for help | 115200 8N1 | NOR | Minicom 2.7.1 | VT102 | Offline
> | ttyUSB0
>
> Reverting this commit fixed the problem.
>
>
>
> --
> Best Regards
> Masahiro Yamada
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] arm64: meson-g12b: Add support for the Ugoos AM6
From: Christian Hewitt @ 2019-08-23 13:08 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Oleg Ivanov, Chrisitian Hewitt
This patchset adds support for the Ugoos AM6, an Android STB based on
the Amlogic W400 reference design with the S922X chipset.
Christian Hewitt (1):
dt-bindings: arm: amlogic: Add support for the Ugoos AM6
chewitt (2):
dt-bindings: Add vendor prefix for Ugoos
arm64: dts: meson-g12b-ugoos-am6: add initial device-tree
Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 567 +++++++++++++++++++++
4 files changed, 571 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
--
2.7.4
_______________________________________________
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