* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Marc Zyngier @ 2016-11-10 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478721480-24852-1-git-send-email-wei@redhat.com>
Hi Wei,
On 09/11/16 19:57, Wei Huang wrote:
> This patch moves ARMv8-related perf event definitions from perf_event.c
> to asm/perf_event.h; so KVM code can use them directly. This also help
> remove a duplicated definition of SW_INCR in perf_event.h.
>
> Signed-off-by: Wei Huang <wei@redhat.com>
> ---
> arch/arm64/include/asm/perf_event.h | 161 +++++++++++++++++++++++++++++++++++-
> arch/arm64/kernel/perf_event.c | 161 ------------------------------------
> 2 files changed, 160 insertions(+), 162 deletions(-)
>
> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
> index 2065f46..6c7b18b 100644
> --- a/arch/arm64/include/asm/perf_event.h
> +++ b/arch/arm64/include/asm/perf_event.h
> @@ -46,7 +46,166 @@
> #define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
> #define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
>
> -#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
> +/*
> + * ARMv8 PMUv3 Performance Events handling code.
> + * Common event types.
> + */
> +
> +/* Required events. */
> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
In my initial review, I asked for the "required" events to be moved to a
shared location. What's the rational for moving absolutely everything?
KVM only needs to know about ARMV8_PMUV3_PERFCTR_SW_INCR and
ARMV8_PMUV3_PERFCTR_CPU_CYCLES, so I thought that moving the above six
events (and maybe the following two) would be enough.
Also, you've now broken the build by dropping
ARMV8_PMU_EVTYPE_EVENT_SW_INCR without amending it use in the KVM PMU
code (see the kbuild report).
> +
> +/* At least one of the following is required. */
> +#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
> +#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
> +
> +/* Common architectural events. */
> +#define ARMV8_PMUV3_PERFCTR_LD_RETIRED 0x06
> +#define ARMV8_PMUV3_PERFCTR_ST_RETIRED 0x07
> +#define ARMV8_PMUV3_PERFCTR_EXC_TAKEN 0x09
> +#define ARMV8_PMUV3_PERFCTR_EXC_RETURN 0x0A
> +#define ARMV8_PMUV3_PERFCTR_CID_WRITE_RETIRED 0x0B
> +#define ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED 0x0C
> +#define ARMV8_PMUV3_PERFCTR_BR_IMMED_RETIRED 0x0D
> +#define ARMV8_PMUV3_PERFCTR_BR_RETURN_RETIRED 0x0E
> +#define ARMV8_PMUV3_PERFCTR_UNALIGNED_LDST_RETIRED 0x0F
> +#define ARMV8_PMUV3_PERFCTR_TTBR_WRITE_RETIRED 0x1C
> +#define ARMV8_PMUV3_PERFCTR_CHAIN 0x1E
> +#define ARMV8_PMUV3_PERFCTR_BR_RETIRED 0x21
> +
> +/* Common microarchitectural events. */
> +#define ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL 0x01
> +#define ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL 0x02
> +#define ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL 0x05
> +#define ARMV8_PMUV3_PERFCTR_MEM_ACCESS 0x13
> +#define ARMV8_PMUV3_PERFCTR_L1I_CACHE 0x14
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_WB 0x15
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE 0x16
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL 0x17
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_WB 0x18
> +#define ARMV8_PMUV3_PERFCTR_BUS_ACCESS 0x19
> +#define ARMV8_PMUV3_PERFCTR_MEMORY_ERROR 0x1A
> +#define ARMV8_PMUV3_PERFCTR_BUS_CYCLES 0x1D
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_ALLOCATE 0x1F
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_ALLOCATE 0x20
> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED_RETIRED 0x22
> +#define ARMV8_PMUV3_PERFCTR_STALL_FRONTEND 0x23
> +#define ARMV8_PMUV3_PERFCTR_STALL_BACKEND 0x24
> +#define ARMV8_PMUV3_PERFCTR_L1D_TLB 0x25
> +#define ARMV8_PMUV3_PERFCTR_L1I_TLB 0x26
> +#define ARMV8_PMUV3_PERFCTR_L2I_CACHE 0x27
> +#define ARMV8_PMUV3_PERFCTR_L2I_CACHE_REFILL 0x28
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_ALLOCATE 0x29
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_REFILL 0x2A
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE 0x2B
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_WB 0x2C
> +#define ARMV8_PMUV3_PERFCTR_L2D_TLB_REFILL 0x2D
> +#define ARMV8_PMUV3_PERFCTR_L2I_TLB_REFILL 0x2E
> +#define ARMV8_PMUV3_PERFCTR_L2D_TLB 0x2F
> +#define ARMV8_PMUV3_PERFCTR_L2I_TLB 0x30
> +
> +/* ARMv8 recommended implementation defined event types */
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_RD 0x40
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WR 0x41
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_RD 0x42
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x43
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_INNER 0x44
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_OUTER 0x45
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_VICTIM 0x46
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_CLEAN 0x47
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_INVAL 0x48
> +
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x4C
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x4D
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x4E
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x4F
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_RD 0x50
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WR 0x51
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_RD 0x52
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_WR 0x53
> +
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_VICTIM 0x56
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_CLEAN 0x57
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_INVAL 0x58
> +
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_RD 0x5C
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_WR 0x5D
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_RD 0x5E
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_WR 0x5F
> +
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x60
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x61
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_SHARED 0x62
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NOT_SHARED 0x63
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NORMAL 0x64
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_PERIPH 0x65
> +
> +#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_RD 0x66
> +#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_WR 0x67
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LD_SPEC 0x68
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_ST_SPEC 0x69
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LDST_SPEC 0x6A
> +
> +#define ARMV8_IMPDEF_PERFCTR_LDREX_SPEC 0x6C
> +#define ARMV8_IMPDEF_PERFCTR_STREX_PASS_SPEC 0x6D
> +#define ARMV8_IMPDEF_PERFCTR_STREX_FAIL_SPEC 0x6E
> +#define ARMV8_IMPDEF_PERFCTR_STREX_SPEC 0x6F
> +#define ARMV8_IMPDEF_PERFCTR_LD_SPEC 0x70
> +#define ARMV8_IMPDEF_PERFCTR_ST_SPEC 0x71
> +#define ARMV8_IMPDEF_PERFCTR_LDST_SPEC 0x72
> +#define ARMV8_IMPDEF_PERFCTR_DP_SPEC 0x73
> +#define ARMV8_IMPDEF_PERFCTR_ASE_SPEC 0x74
> +#define ARMV8_IMPDEF_PERFCTR_VFP_SPEC 0x75
> +#define ARMV8_IMPDEF_PERFCTR_PC_WRITE_SPEC 0x76
> +#define ARMV8_IMPDEF_PERFCTR_CRYPTO_SPEC 0x77
> +#define ARMV8_IMPDEF_PERFCTR_BR_IMMED_SPEC 0x78
> +#define ARMV8_IMPDEF_PERFCTR_BR_RETURN_SPEC 0x79
> +#define ARMV8_IMPDEF_PERFCTR_BR_INDIRECT_SPEC 0x7A
> +
> +#define ARMV8_IMPDEF_PERFCTR_ISB_SPEC 0x7C
> +#define ARMV8_IMPDEF_PERFCTR_DSB_SPEC 0x7D
> +#define ARMV8_IMPDEF_PERFCTR_DMB_SPEC 0x7E
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_UNDEF 0x81
> +#define ARMV8_IMPDEF_PERFCTR_EXC_SVC 0x82
> +#define ARMV8_IMPDEF_PERFCTR_EXC_PABORT 0x83
> +#define ARMV8_IMPDEF_PERFCTR_EXC_DABORT 0x84
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_IRQ 0x86
> +#define ARMV8_IMPDEF_PERFCTR_EXC_FIQ 0x87
> +#define ARMV8_IMPDEF_PERFCTR_EXC_SMC 0x88
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_HVC 0x8A
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_PABORT 0x8B
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_DABORT 0x8C
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_OTHER 0x8D
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_IRQ 0x8E
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_FIQ 0x8F
> +#define ARMV8_IMPDEF_PERFCTR_RC_LD_SPEC 0x90
> +#define ARMV8_IMPDEF_PERFCTR_RC_ST_SPEC 0x91
> +
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_RD 0xA0
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WR 0xA1
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_RD 0xA2
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_WR 0xA3
> +
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_VICTIM 0xA6
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_CLEAN 0xA7
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_INVAL 0xA8
> +
> +/* ARMv8 Cortex-A53 specific event types. */
> +#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> +
> +/* ARMv8 Cavium ThunderX specific event types. */
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_MISS_ST 0xE9
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_ACCESS 0xEA
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_MISS 0xEB
> +#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_ACCESS 0xEC
> +#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_MISS 0xED
>
> /*
> * Event filters for PMUv3
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index a9310a6..108ba40 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -29,167 +29,6 @@
> #include <linux/perf/arm_pmu.h>
> #include <linux/platform_device.h>
>
> -/*
> - * ARMv8 PMUv3 Performance Events handling code.
> - * Common event types.
> - */
> -
> -/* Required events. */
> -#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
> -#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
> -#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
> -#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
> -
> -/* At least one of the following is required. */
> -#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
> -#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
> -
> -/* Common architectural events. */
> -#define ARMV8_PMUV3_PERFCTR_LD_RETIRED 0x06
> -#define ARMV8_PMUV3_PERFCTR_ST_RETIRED 0x07
> -#define ARMV8_PMUV3_PERFCTR_EXC_TAKEN 0x09
> -#define ARMV8_PMUV3_PERFCTR_EXC_RETURN 0x0A
> -#define ARMV8_PMUV3_PERFCTR_CID_WRITE_RETIRED 0x0B
> -#define ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED 0x0C
> -#define ARMV8_PMUV3_PERFCTR_BR_IMMED_RETIRED 0x0D
> -#define ARMV8_PMUV3_PERFCTR_BR_RETURN_RETIRED 0x0E
> -#define ARMV8_PMUV3_PERFCTR_UNALIGNED_LDST_RETIRED 0x0F
> -#define ARMV8_PMUV3_PERFCTR_TTBR_WRITE_RETIRED 0x1C
> -#define ARMV8_PMUV3_PERFCTR_CHAIN 0x1E
> -#define ARMV8_PMUV3_PERFCTR_BR_RETIRED 0x21
> -
> -/* Common microarchitectural events. */
> -#define ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL 0x01
> -#define ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL 0x02
> -#define ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL 0x05
> -#define ARMV8_PMUV3_PERFCTR_MEM_ACCESS 0x13
> -#define ARMV8_PMUV3_PERFCTR_L1I_CACHE 0x14
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_WB 0x15
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE 0x16
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL 0x17
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_WB 0x18
> -#define ARMV8_PMUV3_PERFCTR_BUS_ACCESS 0x19
> -#define ARMV8_PMUV3_PERFCTR_MEMORY_ERROR 0x1A
> -#define ARMV8_PMUV3_PERFCTR_BUS_CYCLES 0x1D
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_ALLOCATE 0x1F
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_ALLOCATE 0x20
> -#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED_RETIRED 0x22
> -#define ARMV8_PMUV3_PERFCTR_STALL_FRONTEND 0x23
> -#define ARMV8_PMUV3_PERFCTR_STALL_BACKEND 0x24
> -#define ARMV8_PMUV3_PERFCTR_L1D_TLB 0x25
> -#define ARMV8_PMUV3_PERFCTR_L1I_TLB 0x26
> -#define ARMV8_PMUV3_PERFCTR_L2I_CACHE 0x27
> -#define ARMV8_PMUV3_PERFCTR_L2I_CACHE_REFILL 0x28
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_ALLOCATE 0x29
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_REFILL 0x2A
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE 0x2B
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_WB 0x2C
> -#define ARMV8_PMUV3_PERFCTR_L2D_TLB_REFILL 0x2D
> -#define ARMV8_PMUV3_PERFCTR_L2I_TLB_REFILL 0x2E
> -#define ARMV8_PMUV3_PERFCTR_L2D_TLB 0x2F
> -#define ARMV8_PMUV3_PERFCTR_L2I_TLB 0x30
> -
> -/* ARMv8 recommended implementation defined event types */
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_RD 0x40
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WR 0x41
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_RD 0x42
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x43
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_INNER 0x44
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_OUTER 0x45
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_VICTIM 0x46
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_CLEAN 0x47
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_INVAL 0x48
> -
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x4C
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x4D
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x4E
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x4F
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_RD 0x50
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WR 0x51
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_RD 0x52
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_WR 0x53
> -
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_VICTIM 0x56
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_CLEAN 0x57
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_INVAL 0x58
> -
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_RD 0x5C
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_WR 0x5D
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_RD 0x5E
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_WR 0x5F
> -
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x60
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x61
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_SHARED 0x62
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NOT_SHARED 0x63
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NORMAL 0x64
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_PERIPH 0x65
> -
> -#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_RD 0x66
> -#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_WR 0x67
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LD_SPEC 0x68
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_ST_SPEC 0x69
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LDST_SPEC 0x6A
> -
> -#define ARMV8_IMPDEF_PERFCTR_LDREX_SPEC 0x6C
> -#define ARMV8_IMPDEF_PERFCTR_STREX_PASS_SPEC 0x6D
> -#define ARMV8_IMPDEF_PERFCTR_STREX_FAIL_SPEC 0x6E
> -#define ARMV8_IMPDEF_PERFCTR_STREX_SPEC 0x6F
> -#define ARMV8_IMPDEF_PERFCTR_LD_SPEC 0x70
> -#define ARMV8_IMPDEF_PERFCTR_ST_SPEC 0x71
> -#define ARMV8_IMPDEF_PERFCTR_LDST_SPEC 0x72
> -#define ARMV8_IMPDEF_PERFCTR_DP_SPEC 0x73
> -#define ARMV8_IMPDEF_PERFCTR_ASE_SPEC 0x74
> -#define ARMV8_IMPDEF_PERFCTR_VFP_SPEC 0x75
> -#define ARMV8_IMPDEF_PERFCTR_PC_WRITE_SPEC 0x76
> -#define ARMV8_IMPDEF_PERFCTR_CRYPTO_SPEC 0x77
> -#define ARMV8_IMPDEF_PERFCTR_BR_IMMED_SPEC 0x78
> -#define ARMV8_IMPDEF_PERFCTR_BR_RETURN_SPEC 0x79
> -#define ARMV8_IMPDEF_PERFCTR_BR_INDIRECT_SPEC 0x7A
> -
> -#define ARMV8_IMPDEF_PERFCTR_ISB_SPEC 0x7C
> -#define ARMV8_IMPDEF_PERFCTR_DSB_SPEC 0x7D
> -#define ARMV8_IMPDEF_PERFCTR_DMB_SPEC 0x7E
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_UNDEF 0x81
> -#define ARMV8_IMPDEF_PERFCTR_EXC_SVC 0x82
> -#define ARMV8_IMPDEF_PERFCTR_EXC_PABORT 0x83
> -#define ARMV8_IMPDEF_PERFCTR_EXC_DABORT 0x84
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_IRQ 0x86
> -#define ARMV8_IMPDEF_PERFCTR_EXC_FIQ 0x87
> -#define ARMV8_IMPDEF_PERFCTR_EXC_SMC 0x88
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_HVC 0x8A
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_PABORT 0x8B
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_DABORT 0x8C
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_OTHER 0x8D
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_IRQ 0x8E
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_FIQ 0x8F
> -#define ARMV8_IMPDEF_PERFCTR_RC_LD_SPEC 0x90
> -#define ARMV8_IMPDEF_PERFCTR_RC_ST_SPEC 0x91
> -
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_RD 0xA0
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WR 0xA1
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_RD 0xA2
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_WR 0xA3
> -
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_VICTIM 0xA6
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_CLEAN 0xA7
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_INVAL 0xA8
> -
> -/* ARMv8 Cortex-A53 specific event types. */
> -#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> -
> -/* ARMv8 Cavium ThunderX specific event types. */
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_MISS_ST 0xE9
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_ACCESS 0xEA
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_MISS 0xEB
> -#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_ACCESS 0xEC
> -#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_MISS 0xED
> -
> /* PMUv3 HW events mapping. */
>
> /*
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] STi DT update for v4.10 round 2
From: Patrice Chotard @ 2016-11-10 9:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof
PLease consider this second round of STi dts update for v4.10 :
The following changes since commit 97a0b97f9e8197429eee5f87ce14373f73dbd9d3:
ARM: dts: stih410-clocks: Add PROC_STFE as a critical clock (2016-10-20 16:20:26 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-dt-for-4.10-round2
for you to fetch changes up to 64783ea7de0bff3de77cfdff1ed76428c288faac:
ARM: dts: STiHxxx-b2120: change sound card name (2016-11-10 09:52:49 +0100)
----------------------------------------------------------------
STi dts update:
Change sound card name for B2120
Enable sound card for B2260
Remove stih415-clks.h
Identify critical clocks for STiH407
Fix typo in stih407-pinctrl.dtsi
----------------------------------------------------------------
Arnaud Pouliquen (2):
ARM: dts: STiH410-B2260: enable sound card
ARM: dts: STiHxxx-b2120: change sound card name
Geert Uytterhoeven (1):
ARM: dts: STiH407: DT fix s/interrupts-names/interrupt-names/
Patrice Chotard (1):
ARM: dts: remove stih415-clks.h
Peter Griffin (1):
ARM: dts: stih407-clocks: Identify critical clocks
arch/arm/boot/dts/stih407-clock.dtsi | 10 ++++++++++
arch/arm/boot/dts/stih407-pinctrl.dtsi | 2 +-
arch/arm/boot/dts/stih410-b2260.dts | 22 ++++++++++++++++++++++
arch/arm/boot/dts/stihxxx-b2120.dtsi | 2 +-
include/dt-bindings/clock/stih415-clks.h | 16 ----------------
5 files changed, 34 insertions(+), 18 deletions(-)
delete mode 100644 include/dt-bindings/clock/stih415-clks.h
^ permalink raw reply
* [GIT PULL] STi defconfig updates for v4.10 round 2
From: Patrice Chotard @ 2016-11-10 9:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider the second round of multi_v7_defconfig updates for v4.10 :
The following changes since commit 620c52f4db4d47e1f33c64e641392fe575d5397f:
ARM: multi_v7_defconfig: Remove stih41x phy Kconfig symbol. (2016-10-20 17:05:08 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git sti-defconfig-for-4.10-round2
for you to fetch changes up to 57dae748959d0abae2b382ccee68621a82f827c8:
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol (2016-10-21 17:05:54 +0200)
----------------------------------------------------------------
Remove STiH415/416 specific IPs
As STiH415/416 have been removed from kernel, remove IPs only
found on these socs, remove ST_THERMAL_SYSCFG.
----------------------------------------------------------------
Patrice Chotard (1):
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-10 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28234714-3994-6747-9cf8-1ff0b3257f7a@gmail.com>
Hi,
On 09-11-16 21:45, Jacek Anaszewski wrote:
> Hi Tony,
>
> On 11/09/2016 08:23 PM, Tony Lindgren wrote:
>> Hi,
>>
>> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
>> the sysfs brightness attr for changes.") breaks runtime PM for me.
>>
>> On my omap dm3730 based test system, idle power consumption is over 70
>> times higher now with this patch! It goes from about 6mW for the core
>> system to over 440mW during idle meaning there's some busy timer now
>> active.
>>
>> Reverting this patch fixes the issue. Any ideas?
>
> Thanks for the report. This is probably caused by sysfs_notify_dirent().
> I'm afraid that we can't keep this feature in the current shape.
> Hans, I'm dropping the patch. We probably will have to delegate this
> call to a workqueue task. Think about use cases when the LED is blinked
> with high frequency e.g. from ledtrig-disk.c.
sysfs_notify_dirent() already uses a workqueue, here is the actual
implementation of it (from fs/kernfs/file.c) :
void kernfs_notify(struct kernfs_node *kn)
{
static DECLARE_WORK(kernfs_notify_work, kernfs_notify_workfn);
unsigned long flags;
if (WARN_ON(kernfs_type(kn) != KERNFS_FILE))
return;
spin_lock_irqsave(&kernfs_notify_lock, flags);
if (!kn->attr.notify_next) {
kernfs_get(kn);
kn->attr.notify_next = kernfs_notify_list;
kernfs_notify_list = kn;
schedule_work(&kernfs_notify_work);
}
spin_unlock_irqrestore(&kernfs_notify_lock, flags);
}
So using a workqueue is not going to help. Note that I already
feared this, which is why my initial implementation only called
sysfs_notify_dirent() for user initiated changes and not for
triggers / blinking.
I think we may need to reconsider what getting the brightness
sysfs atrribute actually returns. Currently when a LED is
blinking it will return 0 resp. the actual brightness depending
on when in the blink cycle the user reads the brightness
sysfs atrribute.
So a user can do "echo 128 > brightness && cat brightness" and
get out 0, or 128, depending purely on timing.
This seems to contradict what Documentation/ABI/testing/sysfs-class-led
has to say:
What: /sys/class/leds/<led>/brightness
Date: March 2006
KernelVersion: 2.6.17
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Set the brightness of the LED. Most LEDs don't
have hardware brightness support, so will just be turned on for
non-zero brightness settings. The value is between 0 and
/sys/class/leds/<led>/max_brightness.
Writing 0 to this file clears active trigger.
Writing non-zero to this file while trigger is active changes the
top brightness trigger is going to use.
Even though it only talks about writing, the logical thing would be for
reading to be the exact opposite of writing, so we would get:
Reading from this file while a trigger is active returns the
top brightness trigger is going to use.
The current docs say not about (sw) blinking, but that should be treated just
like a trigger IMHO.
If we can get consensus on what the read behavior for the brightness attribute
should be, then I think that a better poll() behavior will automatically follow
from that.
Regards,
Hans
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: add nand controller nodes
From: Steffen Trumtrar @ 2016-11-10 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7127bcd-ec0e-cb47-592d-06f404857d50@kernel.org>
On Wed, Nov 09, 2016 at 12:48:21PM -0600, Dinh Nguyen wrote:
>
>
> On 11/09/2016 01:35 AM, Steffen Trumtrar wrote:
> > Add the denali nand controller to the socfpga dtsi.
> >
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > ---
> > arch/arm/boot/dts/socfpga.dtsi | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> > index 9f48141270b8..6b0c23ca5e88 100644
> > --- a/arch/arm/boot/dts/socfpga.dtsi
> > +++ b/arch/arm/boot/dts/socfpga.dtsi
> > @@ -700,6 +700,19 @@
> > status = "disabled";
> > };
> >
> > + nand0: nand at ff900000 {
> > + #address-cells = <0x1>;
> > + #size-cells = <0x1>;
> > + compatible = "denali,denali-nand-dt";
> > + reg = <0xff900000 0x100000>,
> > + <0xffb80000 0x10000>;
> > + reg-names = "nand_data", "denali_reg";
> > + interrupts = <0x0 0x90 0x4>;
> > + dma-mask = <0xffffffff>;
> > + clocks = <&nand_clk>;
> > + status = "disabled";
> > + };
> > +
> > ocram: sram at ffff0000 {
> > compatible = "mmio-sram";
> > reg = <0xffff0000 0x10000>;
> >
>
> Since there's only 1 NAND node, do we need to call the node "nand0"? No
> need to resend a patch, I can change it locally if we agree that the
> node should be just:
>
> nand: nand at ff900000
>
Okay with me. Go ahead.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-10 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109192301.GS26979@atomide.com>
Hi,
On 09-11-16 20:23, Tony Lindgren wrote:
> Hi,
>
> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
> the sysfs brightness attr for changes.") breaks runtime PM for me.
>
> On my omap dm3730 based test system, idle power consumption is over 70
> times higher now with this patch! It goes from about 6mW for the core
> system to over 440mW during idle meaning there's some busy timer now
> active.
Do you have any blinking LEDs or LED triggers defined on the system ?
> Reverting this patch fixes the issue. Any ideas?
All I can think of is something calling led_set_brightness quite often,
the patch in question makes led_set_brightness somewhat more expensive,
but it should not cause such a big difference unless something is
really calling led_set_brightness quite often maybe something is calling
it with the same value all the time ?
Regards,
Hans
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: zhichang.yuan @ 2016-11-10 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478647002.7430.69.camel@kernel.crashing.org>
Hi, Ben,
On 2016/11/9 7:16, Benjamin Herrenschmidt wrote:
> On Tue, 2016-11-08 at 12:03 +0000, Mark Rutland wrote:
>> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
>>>
>>> For arm64, there is no I/O space as other architectural platforms, such as
>>> X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
>>> such as Hip06, when accessing some legacy ISA devices connected to LPC, those
>>> known port addresses are used to control the corresponding target devices, for
>>> example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
>>> normal MMIO mode in using.
>>
>> This has nothing to do with arm64. Hardware with this kind of indirect
>> bus access could be integrated with a variety of CPU architectures. It
>> simply hasn't been, yet.
>
> On some ppc's we also use similar indirect access methods for IOs. We
> have a generic infrastructure for re-routing some memory or IO regions
> to hooks.
>
I am interested on the generic infrastructure on PPC.
Could you point out where those drivers are?
want to take a look..
Thanks,
Zhichang
> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
> firmware calls ;-) We use that infrastructure to plumb in the LPC bus.
>
>>> To drive these devices, this patch introduces a method named indirect-IO.
>>> In this method the in/out pair in arch/arm64/include/asm/io.h will be
>>> redefined. When upper layer drivers call in/out with those known legacy port
>>> addresses to access the peripherals, the hooking functions corrresponding to
>>> those target peripherals will be called. Through this way, those upper layer
>>> drivers which depend on in/out can run on Hip06 without any changes.
>>
>> As above, this has nothing to do with arm64, and as such, should live in
>> generic code, exactly as we would do if we had higher-level ISA
>> accessor ops.
>>
>> Regardless, given the multi-instance case, I don't think this is
>> sufficient in general (and I think we need higher-level ISA accessors
>> to handle the indirection).
>
> Multi-instance with IO is tricky to do generically because archs already
> have all sort of hacks to deal with the fact that inb/outb don't require
> an explicit ioremap, so an IO resource can take all sort of shape depending
> on the arch.
>
> Overall it boils down to applying some kind of per-instance "offset" to
> the IO port number though.
>
^ permalink raw reply
* [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware
From: Thomas Petazzoni @ 2016-11-10 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174440.GA24717@obsidianresearch.com>
Hello,
On Wed, 26 Oct 2016 11:44:40 -0600, Jason Gunthorpe wrote:
> The firmware may setup the mbus to access PCI-E and indicate this
> has happened with a ranges mapping for the PCI-E ID. If this happens
> then the mbus setup and the pci dynamic setup conflict, creating
> problems.
>
> Have PCI-E assume control of the firmware specified default mapping by
> setting the value of the bridge window to match the firmware mapping.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Sorry for the late feedback. I am not sure to fully understand what you
are trying to do here.
However, one thing that confuses me specifically is how can the kernel
get any MBus mapping set up by the firmware? Indeed, when the
mvebu-mbus driver initializes, it destroys all existing MBus windows
that might have been left by the firmware/bootloader:
static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
phys_addr_t mbuswins_phys_base,
size_t mbuswins_size,
phys_addr_t sdramwins_phys_base,
size_t sdramwins_size,
phys_addr_t mbusbridge_phys_base,
size_t mbusbridge_size,
bool is_coherent)
[...]
for (win = 0; win < mbus->soc->num_wins; win++)
mvebu_mbus_disable_window(mbus, win);
Why does Linux needs to rely on what the firmware has setup in terms of
MBus windows? Why can't Linux just find out the right BAR base/size
like it is doing for all other devices?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Thomas Petazzoni @ 2016-11-10 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-5-gregory.clement@free-electrons.com>
Hello,
On Thu, 10 Nov 2016 01:09:50 +0100, Gregory CLEMENT wrote:
> - bootrom {
> + bootrom at 0 {
> compatible = "marvell,bootrom";
> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
I am still not sure whether this "0" unit address is correct compared
to the reg property being passed.
A good example of why I'm worried is the sa-sram case:
+ crypto_sram0: sa-sram0 at 0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
+ crypto_sram1: sa-sram1 at 0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
The node names should be just "sram" without a number. Indeed for UARTs
for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
uart1 at ABC. But then, if you do that, with your scheme, you end up with
both nodes named sa-sram at 0.
Which clearly shows that the way you set this unit-address is not
correct: those two devices are mapped at completely different
locations, but you end up with an identical unit address.
I have no idea what is the rule for setting the unit address in this
case, but I'm pretty sure the rule you've chosen is not good.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4] regulator: lp873x: Add support for populating input supply
From: Lee Jones @ 2016-11-10 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110052915.4898-1-lokeshvutla@ti.com>
On Thu, 10 Nov 2016, Lokesh Vutla wrote:
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Changes since v3:
> - Applied Rob's ack.
> - Sending this patch separately so that this can be merged via Regulator tree.
> - Link to v3: https://patchwork.kernel.org/patch/9408545/
>
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> index 52766c2..ae9cf39 100644
> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> @@ -7,6 +7,9 @@ Required properties:
> - #gpio-cells: Should be two. The first cell is the pin number and
> the second cell is used to specify flags.
> See ../gpio/gpio.txt for more information.
> + - xxx-in-supply: Phandle to parent supply node of each regulator
> + populated under regulators node. xxx can be
> + buck0, buck1, ldo0 or ldo1.
> - regulators: List of child nodes that specify the regulator
> initialization data.
> Example:
> @@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
> gpio-controller;
> #gpio-cells = <2>;
>
> + buck0-in-supply = <&vsys_3v3>;
> + buck1-in-supply = <&vsys_3v3>;
> + ldo0-in-supply = <&vsys_3v3>;
> + ldo1-in-supply = <&vsys_3v3>;
> +
> regulators {
> lp8733_buck0: buck0 {
> regulator-name = "lp8733-buck0";
> diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
> index e504b91..70e3df6 100644
> --- a/drivers/regulator/lp873x-regulator.c
> +++ b/drivers/regulator/lp873x-regulator.c
> @@ -24,6 +24,7 @@
> [_id] = { \
> .desc = { \
> .name = _name, \
> + .supply_name = _of "-in", \
> .id = _id, \
> .of_match = of_match_ptr(_of), \
> .regulators_node = of_match_ptr("regulators"),\
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
From: Peter Rosin @ 2016-11-10 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110000923.ltpouekbkx7onzm7@piout.net>
On 2016-11-10 01:09, Alexandre Belloni wrote:
> On 10/11/2016 at 00:41:37 +0100, Peter Rosin wrote :
>> On 2016-10-20 15:35, Alexandre Belloni wrote
>>> On 16/10/2016 at 18:21:45 +0200, Sylvain Rochet wrote :
>>>> Remove pullup on dbgu DTXD signal, it is a push-pull output thus the
>>>> pullup is pointless.
>>>>
>>>> Add pullup on dbgu DRXD signal, it prevents the DRXD signal to be left
>>>> floating and so consuming a useless extra amount of power in crowbarred
>>>> state if nothing is externally connected to dbgu.
>>> Applied, thanks.
>>
>> I can't seem to find this patch in any of the repos I'm looking at,
>> so I'm wondering where it was applied and when it might hit mainline?
>>
>
> It is applied there:
> http://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/log/?h=at91-dt
>
> It will land in 4.10. I'll do the PR to arm-soc soon.
Great, thanks! (expected it to be in -next by now and got worried, and
couldn't find it in https://github.com/linux4sam/linux-at91 either...)
Cheers,
Peter
^ permalink raw reply
* [PATCH] mfd: qcom-pm8xxx: Clean up PM8XXX namespace
From: Jacek Anaszewski @ 2016-11-10 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZe0VO=ABfbven8mU0FGb=sJNY_tjk2_GpAP30wsiDkvQ@mail.gmail.com>
On 11/09/2016 11:19 PM, Linus Walleij wrote:
> On Wed, Nov 9, 2016 at 4:47 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
>> How many more Acks do we need?
>
> Jacek and one of the ARM SoC people ideally...
>
> Jacek? Arnd/Olof?
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation
From: Peter Rosin @ 2016-11-10 7:46 UTC (permalink / raw)
To: linux-arm-kernel
The new size (0x100) also matches the size given in sama5d3.dtsi
Documentation reference: section 43.6 "Universal Asynchronous
Receiver Transmitter (UART) User Interface", table 43-4 "Register
Mapping" in [1].
[1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16
Signed-off-by: Peter Rosin <peda@axentia.se>
---
arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3_uart.dtsi b/arch/arm/boot/dts/sama5d3_uart.dtsi
index 2511d748867b..186377d41c91 100644
--- a/arch/arm/boot/dts/sama5d3_uart.dtsi
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -55,7 +55,7 @@
uart0: serial at f0024000 {
compatible = "atmel,at91sam9260-usart";
- reg = <0xf0024000 0x200>;
+ reg = <0xf0024000 0x100>;
interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart0>;
@@ -66,7 +66,7 @@
uart1: serial at f8028000 {
compatible = "atmel,at91sam9260-usart";
- reg = <0xf8028000 0x200>;
+ reg = <0xf8028000 0x100>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] mfd: pm8921: add support to pm8821
From: kbuild test robot @ 2016-11-10 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478622577-20699-1-git-send-email-srinivas.kandagatla@linaro.org>
Hi Srinivas,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/mfd-pm8921-add-support-to-pm8821/20161109-013248
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: arm-pxa_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
drivers/mfd/pm8921-core.c: In function 'pm8921_probe':
>> drivers/mfd/pm8921-core.c:630:58: warning: dereferencing 'void *' pointer
data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
^~
>> drivers/mfd/pm8921-core.c:630:58: error: request for member 'data' in something not a structure or union
vim +/data +630 drivers/mfd/pm8921-core.c
624 const struct pm8xxx_data *data;
625 int irq, rc;
626 unsigned int val;
627 u32 rev;
628 struct pm_irq_chip *chip;
629
> 630 data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
631 if (!data) {
632 dev_err(&pdev->dev, "No matching driver data found\n");
633 return -EINVAL;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 30088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/a54a422b/attachment-0001.gz>
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Benjamin Herrenschmidt @ 2016-11-10 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109111959.GB17020@leverpostej>
On Wed, 2016-11-09 at 11:20 +0000, Mark Rutland wrote:
> The big change would be to handle !MMIO translations, for which we'd
> need a runtime registry of ISA bus instance to find the relevant
> accessor ops and instance-specific data.
Yes. We do something a bit like that on ppc, we find the PCI bus
for which the IO ports match and I have a hook to register the
special indirect ISA.
It's a bit messy, we could do something nicer generically.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-10 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165549.1cf320c5@thinkpad>
On Wed, Nov 09, 2016 at 04:55:49PM +0100, Gerald Schaefer wrote:
> > index 9fdfc24..5dbfd62 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1095,6 +1095,9 @@ static struct page *alloc_gigantic_page(int nid, unsigned int order)
> > unsigned long ret, pfn, flags;
> > struct zone *z;
> >
> > + if (nid == NUMA_NO_NODE)
> > + nid = numa_mem_id();
> > +
>
> Now counter.sh works (on s390) w/o the lockdep warning. However, it looks
Good news to me :)
We have found the root cause of the s390 issue.
> like this change will now result in inconsistent behavior compared to the
> normal sized hugepages, regarding surplus page allocation. Setting nid to
> numa_mem_id() means that only the node of the current CPU will be considered
> for allocating a gigantic page, as opposed to just "preferring" the current
> node in the normal size case (__hugetlb_alloc_buddy_huge_page() ->
> alloc_pages_node()) with a fallback to using other nodes.
Yes.
>
> I am not really familiar with NUMA, and I might be wrong here, but if
> this is true then gigantic pages, which may be hard allocate at runtime
> in general, will be even harder to find (as surplus pages) because you
> only look on the current node.
Okay, I will try to fix this in the next version.
>
> I honestly do not understand why alloc_gigantic_page() needs a nid
> parameter at all, since it looks like it will only be called from
> alloc_fresh_gigantic_page_node(), which in turn is only called
> from alloc_fresh_gigantic_page() in a "for_each_node" loop (at least
> before your patch).
>
> Now it could be an option to also use alloc_fresh_gigantic_page()
> in your patch, instead of directly calling alloc_gigantic_page(),
Yes, a good suggestion. But I need to do some change to the
alloc_fresh_gigantic_page().
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-10 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2825537.ADCNsGqGxn@wuerfel>
Hi, Arnd,
On 2016/11/10 5:34, Arnd Bergmann wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
>>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
>>>> + /*
>>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
>>> indirectIO.
>>>> + * It will separate indirectIO range from pci host bridge to
>>>> + * avoid the possible PIO conflict.
>>>> + * Set the indirectIO range directly here.
>>>> + */
>>>> + lpcdev->io_ops.start = 0;
>>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
>>>> + lpcdev->io_ops.devpara = lpcdev;
>>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
>>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
>>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
>>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
>>>
>>> I have to look at patch 2 in more detail again, after missing a few
>>> review
>>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
>>> range here, and would hope that we can just go through the same
>>> assignment of logical port ranges that we have for PCI buses,
>>> decoupling
>>> the bus addresses from the linux-internal ones.
>>
>> The point here is that we want to avoid any conflict/overlap between
>> the LPC I/O space and the PCI I/O space. With the assignment above
>> we make sure that LPC never interfere with PCI I/O space.
>
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.
Do you means that we can pick up the maximal I/O address from all children's
device resources??
Thanks,
Zhichang
>
> Arnd
>
> .
>
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: zhichang.yuan @ 2016-11-10 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165044.GE10219@e106497-lin.cambridge.arm.com>
Hi,Liviu,
Thanks for your comments!
On 2016/11/10 0:50, liviu.dudau at arm.com wrote:
> On Wed, Nov 09, 2016 at 04:16:17PM +0000, Gabriele Paoloni wrote:
>> Hi Liviu
>>
>> Thanks for reviewing
>>
>
> [removed some irrelevant part of discussion, avoid crazy formatting]
>
>>>> +/**
>>>> + * addr_is_indirect_io - check whether the input taddr is for
>>> indirectIO.
>>>> + * @taddr: the io address to be checked.
>>>> + *
>>>> + * Returns 1 when taddr is in the range; otherwise return 0.
>>>> + */
>>>> +int addr_is_indirect_io(u64 taddr)
>>>> +{
>>>> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end <
>>> taddr)
>>>
>>> start >= taddr ?
>>
>> Nope... if (taddr < arm64_extio_ops->start || taddr > arm64_extio_ops->end)
>> then taddr is outside the range [start; end] and will return 0; otherwise
>> it will return 1...
>
> Oops, sorry, did not pay attention to the returned value. The check is
> correct as it is, no need to change then.
>
>>
>>>
>>>> + return 0;
>>>> +
>>>> + return 1;
>>>> +}
>>>>
>>>> BUILD_EXTIO(b, u8)
>>>>
>>>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>>>> index 02b2903..cc2a05d 100644
>>>> --- a/drivers/of/address.c
>>>> +++ b/drivers/of/address.c
>>>> @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct
>>> device_node *np)
>>>> return false;
>>>> }
>>>>
>>>> +
>>>> +/*
>>>> + * of_isa_indirect_io - get the IO address from some isa reg
>>> property value.
>>>> + * For some isa/lpc devices, no ranges property in ancestor node.
>>>> + * The device addresses are described directly in their regs
>>> property.
>>>> + * This fixup function will be called to get the IO address of
>>> isa/lpc
>>>> + * devices when the normal of_translation failed.
>>>> + *
>>>> + * @parent: points to the parent dts node;
>>>> + * @bus: points to the of_bus which can be used to parse
>>> address;
>>>> + * @addr: the address from reg property;
>>>> + * @na: the address cell counter of @addr;
>>>> + * @presult: store the address paresed from @addr;
>>>> + *
>>>> + * return 1 when successfully get the I/O address;
>>>> + * 0 will return for some failures.
>>>
>>> Bah, you are returning a signed int, why 0 for failure? Return a
>>> negative value with
>>> error codes. Otherwise change the return value into a bool.
>>
>> Yes we'll move to bool
>>
>>>
>>>> + */
>>>> +static int of_get_isa_indirect_io(struct device_node *parent,
>>>> + struct of_bus *bus, __be32 *addr,
>>>> + int na, u64 *presult)
>>>> +{
>>>> + unsigned int flags;
>>>> + unsigned int rlen;
>>>> +
>>>> + /* whether support indirectIO */
>>>> + if (!indirect_io_enabled())
>>>> + return 0;
>>>> +
>>>> + if (!of_bus_isa_match(parent))
>>>> + return 0;
>>>> +
>>>> + flags = bus->get_flags(addr);
>>>> + if (!(flags & IORESOURCE_IO))
>>>> + return 0;
>>>> +
>>>> + /* there is ranges property, apply the normal translation
>>> directly. */
>>>
>>> s/there is ranges/if we have a 'ranges'/
>>
>> Thanks for spotting this
>>
>>>
>>>> + if (of_get_property(parent, "ranges", &rlen))
>>>> + return 0;
>>>> +
>>>> + *presult = of_read_number(addr + 1, na - 1);
>>>> + /* this fixup is only valid for specific I/O range. */
>>>> + return addr_is_indirect_io(*presult);
>>>> +}
>>>> +
>>>> static int of_translate_one(struct device_node *parent, struct
>>> of_bus *bus,
>>>> struct of_bus *pbus, __be32 *addr,
>>>> int na, int ns, int pna, const char *rprop)
>>>> @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct
>>> device_node *dev,
>>>> result = of_read_number(addr, na);
>>>> break;
>>>> }
>>>> + /*
>>>> + * For indirectIO device which has no ranges property, get
>>>> + * the address from reg directly.
>>>> + */
>>>> + if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
>>>> + pr_debug("isa indirectIO matched(%s)..addr =
>>> 0x%llx\n",
>>>> + of_node_full_name(dev), result);
>>>> + break;
>>>> + }
>>>>
>>>> /* Get new parent bus and counts */
>>>> pbus = of_match_bus(parent);
>>>> @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct
>>> device_node *dev,
>>>> if (taddr == OF_BAD_ADDR)
>>>> return -EINVAL;
>>>> memset(r, 0, sizeof(struct resource));
>>>> - if (flags & IORESOURCE_IO) {
>>>> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
>>>> unsigned long port;
>>>> +
>>>> port = pci_address_to_pio(taddr);
>>>> if (port == (unsigned long)-1)
>>>> return -EINVAL;
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index ba34907..1a08511 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t
>>> addr, resource_size_t size)
>>>>
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *range;
>>>> - resource_size_t allocated_size = 0;
>>>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>>>
>>>> /* check if the range hasn't been previously recorded */
>>>> spin_lock(&io_range_lock);
>>>> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long
>>> pio)
>>>>
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *range;
>>>> - resource_size_t allocated_size = 0;
>>>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>>
>>> Have you checked that pci_pio_to_address still returns valid values
>>> after this? I know that
>>> you are trying to take into account PCIBIOS_MIN_IO limit when
>>> allocating reserving the IO ranges,
>>> but the values added in the io_range_list are still starting from zero,
>>> no from PCIBIOS_MIN_IO,
>>
>> I think you're wrong here as in pci_address_to_pio we have:
>> + resource_size_t offset = PCIBIOS_MIN_IO;
>>
>> This should be enough to guarantee that the PIOs start at
>> PCIBIOS_MIN_IO...right?
>
> I don't think you can guarantee that the pio value that gets passed into
> pci_pio_to_address() always comes from a previously returned value by
> pci_address_to_pio(). Maybe you can add a check in pci_pio_to_address()
>
> if (pio < PCIBIOS_MIN_IO)
> return address;
>
> to avoid adding more checks in the list_for_each_entry() loop.
>
I will register some ranges to the list and test it later.
But from my understanding, pci_pio_to_address() should can return the right
original physical address.
According to the algorithm, the output PIO ranges are consecutive? just like this:
input pio of pci_pio_to_address()
|
V
|----------------|--------------------------|------|-----------|
^
|
allocated_size is here
The change of this patch just make the start PIO from ZERO to PCIBIOS_MIN_IO.
in pci_pio_to_address(), for one input pio which fall into any PIO segment, the
return address will be:
address = range->start + pio - allocated_size;
Since allocated_size is the total range size of all IO ranges before the one
where pio belong, then (pio - allocated_size) is the offset to the range start,
So....
Thanks!
Zhichang
> Best regards,
> Liviu
>
>>
>>
>>> so the calculation of the address in this function could return
>>> negative values casted to pci_addr_t.
>>>
>>> Maybe you want to adjust the range->start value in
>>> pci_register_io_range() as well to have it
>>> offset by PCIBIOS_MIN_IO as well.
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>> if (pio > IO_SPACE_LIMIT)
>>>> return address;
>>>> @@ -3335,7 +3335,7 @@ unsigned long __weak
>>> pci_address_to_pio(phys_addr_t address)
>>>> {
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *res;
>>>> - resource_size_t offset = 0;
>>>> + resource_size_t offset = PCIBIOS_MIN_IO;
>>>> unsigned long addr = -1;
>>>>
>>>> spin_lock(&io_range_lock);
>>>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>>>> index 3786473..deec469 100644
>>>> --- a/include/linux/of_address.h
>>>> +++ b/include/linux/of_address.h
>>>> @@ -24,6 +24,23 @@ struct of_pci_range {
>>>> #define for_each_of_pci_range(parser, range) \
>>>> for (; of_pci_range_parser_one(parser, range);)
>>>>
>>>> +
>>>> +#ifndef indirect_io_enabled
>>>> +#define indirect_io_enabled indirect_io_enabled
>>>> +static inline bool indirect_io_enabled(void)
>>>> +{
>>>> + return false;
>>>> +}
>>>> +#endif
>>>> +
>>>> +#ifndef addr_is_indirect_io
>>>> +#define addr_is_indirect_io addr_is_indirect_io
>>>> +static inline int addr_is_indirect_io(u64 taddr)
>>>> +{
>>>> + return 0;
>>>> +}
>>>> +#endif
>>>> +
>>>> /* Translate a DMA address from device space to CPU space */
>>>> extern u64 of_translate_dma_address(struct device_node *dev,
>>>> const __be32 *in_addr);
>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>> index 0e49f70..7f6bbb6 100644
>>>> --- a/include/linux/pci.h
>>>> +++ b/include/linux/pci.h
>>>> @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct
>>> pci_bus *bus)
>>>> /* provide the legacy pci_dma_* API */
>>>> #include <linux/pci-dma-compat.h>
>>>>
>>>> +/*
>>>> + * define this macro here to refrain from compilation error for some
>>>> + * platforms. Please keep this macro at the end of this header file.
>>>> + */
>>>> +#ifndef PCIBIOS_MIN_IO
>>>> +#define PCIBIOS_MIN_IO 0
>>>> +#endif
>>>> +
>>>> #endif /* LINUX_PCI_H */
>>>> --
>>>> 1.9.1
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci"
>>> in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/10] clk: sunxi-ng: multiplier: Add fractionnal support
From: Chen-Yu Tsai @ 2016-11-10 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3d3436c03e0597de205f674061892dbc9498a7e.1478625788.git-series.maxime.ripard@free-electrons.com>
On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Nit: Typo in the subject ("fractional"). Maybe mention what clock on what SoC
needs this in the commit message?
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/clk/sunxi-ng/ccu_mult.c | 8 ++++++++
> drivers/clk/sunxi-ng/ccu_mult.h | 2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
> index 678b6cb49f01..826302464650 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.c
> +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> @@ -75,6 +75,9 @@ static unsigned long ccu_mult_recalc_rate(struct clk_hw *hw,
> unsigned long val;
> u32 reg;
>
> + if (ccu_frac_helper_is_enabled(&cm->common, &cm->frac))
> + return ccu_frac_helper_read_rate(&cm->common, &cm->frac);
> +
> reg = readl(cm->common.base + cm->common.reg);
> val = reg >> cm->mult.shift;
> val &= (1 << cm->mult.width) - 1;
> @@ -102,6 +105,11 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long flags;
> u32 reg;
>
> + if (ccu_frac_helper_has_rate(&cm->common, &cm->frac, rate))
> + return ccu_frac_helper_set_rate(&cm->common, &cm->frac, rate);
> + else
> + ccu_frac_helper_disable(&cm->common, &cm->frac);
> +
> ccu_mux_helper_adjust_parent_for_prediv(&cm->common, &cm->mux, -1,
> &parent_rate);
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.h b/drivers/clk/sunxi-ng/ccu_mult.h
> index c1a2134bdc71..bd2e38b5a32a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.h
> +++ b/drivers/clk/sunxi-ng/ccu_mult.h
> @@ -2,6 +2,7 @@
> #define _CCU_MULT_H_
>
> #include "ccu_common.h"
> +#include "ccu_frac.h"
> #include "ccu_mux.h"
>
> struct ccu_mult_internal {
> @@ -23,6 +24,7 @@ struct ccu_mult_internal {
> struct ccu_mult {
> u32 enable;
>
> + struct ccu_frac_internal frac;
> struct ccu_mult_internal mult;
> struct ccu_mux_internal mux;
> struct ccu_common common;
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH] ASoC: sun4i-codec: fix semicolon.cocci warnings
From: Chen-Yu Tsai @ 2016-11-10 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109163518.GA42508@lkp-nex06.lkp.intel.com>
On Thu, Nov 10, 2016 at 12:35 AM, kbuild test robot
<fengguang.wu@intel.com> wrote:
> sound/soc/sunxi/sun4i-codec.c:1339:2-3: Unneeded semicolon
>
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Sorry about the screw up.
> ---
>
> sun4i-codec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -1336,7 +1336,7 @@ static int sun4i_codec_probe(struct plat
> dev_err(&pdev->dev, "Failed to get reset control\n");
> return PTR_ERR(scodec->rst);
> }
> - };
> + }
>
> scodec->gpio_pa = devm_gpiod_get_optional(&pdev->dev, "allwinner,pa",
> GPIOD_OUT_LOW);
^ permalink raw reply
* [PATCH v4] regulator: lp873x: Add support for populating input supply
From: Lokesh Vutla @ 2016-11-10 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In order to have a proper topology of regulators for a platform, each
registering regulator needs to populate supply_name field for identifying
its supply's name. Add supply_name field for lp873x regulators.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Changes since v3:
- Applied Rob's ack.
- Sending this patch separately so that this can be merged via Regulator tree.
- Link to v3: https://patchwork.kernel.org/patch/9408545/
Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
drivers/regulator/lp873x-regulator.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
index 52766c2..ae9cf39 100644
--- a/Documentation/devicetree/bindings/mfd/lp873x.txt
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -7,6 +7,9 @@ Required properties:
- #gpio-cells: Should be two. The first cell is the pin number and
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx can be
+ buck0, buck1, ldo0 or ldo1.
- regulators: List of child nodes that specify the regulator
initialization data.
Example:
@@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
gpio-controller;
#gpio-cells = <2>;
+ buck0-in-supply = <&vsys_3v3>;
+ buck1-in-supply = <&vsys_3v3>;
+ ldo0-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+
regulators {
lp8733_buck0: buck0 {
regulator-name = "lp8733-buck0";
diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
index e504b91..70e3df6 100644
--- a/drivers/regulator/lp873x-regulator.c
+++ b/drivers/regulator/lp873x-regulator.c
@@ -24,6 +24,7 @@
[_id] = { \
.desc = { \
.name = _name, \
+ .supply_name = _of "-in", \
.id = _id, \
.of_match = of_match_ptr(_of), \
.regulators_node = of_match_ptr("regulators"),\
--
2.10.1
^ permalink raw reply related
* [PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf.
From: Wu-Cheng Li @ 2016-11-10 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478755445-23494-1-git-send-email-wuchengli@chromium.org>
From: Wu-Cheng Li <wuchengli@google.com>
vb2_qbuf will check the buffer index. If a driver overrides
vidioc_qbuf and use the buffer index, the driver needs to check
the index.
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0520919..0746592 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -533,6 +533,10 @@ static int vidioc_vdec_qbuf(struct file *file, void *priv,
}
vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
+ if (buf->index >= vq->num_buffers) {
+ mtk_v4l2_debug(1, "buffer index %d out of range", buf->index);
+ return -EINVAL;
+ }
vb = vq->bufs[buf->index];
vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf
From: Wu-Cheng Li @ 2016-11-10 5:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Wu-Cheng Li <wuchengli@google.com>
This patch adds a buffer index check in decoder vidioc_qbuf.
Wu-Cheng Li (1):
mtk-vcodec: add index check in decoder vidioc_qbuf.
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++++
1 file changed, 4 insertions(+)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Scott Wood @ 2016-11-10 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0401MB25369DEFDDDED2A96851259EF8B80@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Thu, 2016-11-10 at 04:11 +0000, Y.B. Lu wrote:
> >
> > -----Original Message-----
> > From: Y.B. Lu
> > Sent: Thursday, November 10, 2016 12:06 PM
> > To: 'Scott Wood'; Ulf Hansson
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> > kernel at vger.kernel.org; linux-clk; iommu at lists.linux-foundation.org;
> > netdev at vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> > Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> > Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
> >
> > >
> > > -----Original Message-----
> > > From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> > > owner at vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Thursday, November 10, 2016 11:55 AM
> > > To: Ulf Hansson; Y.B. Lu
> > > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> > > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > > linux- kernel at vger.kernel.org; linux-clk;
> > > iommu at lists.linux-foundation.org; netdev at vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> > >
> > > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > >
> > > > - i2c-list
> > > >
> > > > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > > > >
> > > > >
> > > > > This patchset is used to fix a host version register bug in the
> > > > > T4240-
> > > > > R1.0-R2.0
> > > > > eSDHC controller. To match the SoC version and revision, 15
> > > > > previous version patchsets had tried many methods but all of them
> > > > > were rejected by reviewers.
> > > > > Such as
> > > > > ????????- dts compatible method
> > > > > ????????- syscon method
> > > > > ????????- ifdef PPC method
> > > > > ????????- GUTS driver getting SVR method Anrd suggested a
> > > > > soc_device_match method in v10, and this is the only available
> > > > > method left now. This v11 patchset introduces the soc_device_match
> > > > > interface in soc driver.
> > > > >
> > > > > The first four patches of Yangbo are to add the GUTS driver. This
> > > > > is used to register a soc device which contain soc version and
> > > > > revision information.
> > > > > The other three patches introduce the soc_device_match method in
> > > > > soc driver and apply it on esdhc driver to fix this bug.
> > > > >
> > > > > ---
> > > > > Changes for v15:
> > > > > ????????- Dropped patch 'dt: bindings: update Freescale DCFG
> > > compatible'
> > > >
> > > > >
> > > > > ??????????since the work had been done by below patch on
> > > > > ShawnGuo's linux tree.
> > > > > ??????????'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A
> > > > > compatible for SCFG
> > > > > ???????????and DCFG'
> > > > > ????????- Fixed error code issue in guts driver Changes for v16:
> > > > > ????????- Dropped patch 'powerpc/fsl: move mpc85xx.h to
> > > include/linux/fsl'
> > > >
> > > > >
> > > > > ????????- Added a bug-fix patch from Geert
> > > > > ---
> > > > >
> > > > > Arnd Bergmann (1):
> > > > > ? base: soc: introduce soc_device_match() interface
> > > > >
> > > > > Geert Uytterhoeven (1):
> > > > > ? base: soc: Check for NULL SoC device attributes
> > > > >
> > > > > Yangbo Lu (5):
> > > > > ? ARM64: dts: ls2080a: add device configuration node
> > > > > ? dt: bindings: move guts devicetree doc out of powerpc directory
> > > > > ? soc: fsl: add GUTS driver for QorIQ platforms
> > > > > ? MAINTAINERS: add entry for Freescale SoC drivers
> > > > > ? mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > > > >
> > > > > ?.../bindings/{powerpc => soc}/fsl/guts.txt?????????|???3 +
> > > > > ?MAINTAINERS????????????????????????????????????????|??11 +-
> > > > > ?arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi?????|???6 +
> > > > > ?drivers/base/Kconfig???????????????????????????????|???1 +
> > > > > ?drivers/base/soc.c?????????????????????????????????|??70 ++++++
> > > > > ?drivers/mmc/host/Kconfig???????????????????????????|???1 +
> > > > > ?drivers/mmc/host/sdhci-of-esdhc.c??????????????????|??20 ++
> > > > > ?drivers/soc/Kconfig????????????????????????????????|???3 +-
> > > > > ?drivers/soc/fsl/Kconfig????????????????????????????|??18 ++
> > > > > ?drivers/soc/fsl/Makefile???????????????????????????|???1 +
> > > > > ?drivers/soc/fsl/guts.c?????????????????????????????| 236
> > > > > +++++++++++++++++++++
> > > > > ?include/linux/fsl/guts.h???????????????????????????| 125
> > > > > ++++++-----
> > > > > ?include/linux/sys_soc.h????????????????????????????|???3 +
> > > > > ?13 files changed, 447 insertions(+), 51 deletions(-)
> > > > > ?rename Documentation/devicetree/bindings/{powerpc =>
> > > > > soc}/fsl/guts.txt
> > > > > (91%)
> > > > > ?create mode 100644 drivers/soc/fsl/Kconfig
> > > > > ?create mode 100644 drivers/soc/fsl/guts.c
> > > > >
> > > > > --
> > > > > 2.1.0.27.g96db324
> > > > >
> > > > Thanks, applied on my mmc tree for next!
> > > >
> > > > I noticed that some DT compatibles weren't documented, according to
> > > > checkpatch. Please fix that asap!
> > > They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > > >
> > > > ?- compatible : Should define the compatible device type for
> > > > ???global-utilities.
> > > > ???Possible compatibles:
> > > > ????????"fsl,qoriq-device-config-1.0"
> > > > ????????"fsl,qoriq-device-config-2.0"
> > > > ????????"fsl,<chip>-device-config"
> > > > ????????"fsl,<chip>-guts"
> > > Checkpatch doesn't understand compatibles defined in such a way.
> > [Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings:
> > update Freescale DCFG compatible '
> > which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
> > https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h
> > =imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
> >
> > Thanks.
> [Lu Yangbo-B47093] Both 'fsl,<chip>-guts' and 'fsl,<chip>-dcfg' would have
> no un-doc issue after Shaohui's patch are pulled :)
I don't follow. ?The link above points to a patch that addresses -dcfg and
-scfg, not -device-config or -guts -- and it also doesn't do it in a manner
that checkpatch will understand.
In any case, I wouldn't call this an "un-doc issue" -- it is documented -- but
rather a checkpatch-friendliness issue.
-Scott
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Vignesh R @ 2016-11-10 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D0AA78D0-9562-4E4D-A949-A771289D7570@gmail.com>
Hi,
On Thursday 10 November 2016 05:23 AM, John Syne wrote:
> OK, then back to my original question. Given that these DT properties are supported in the driver
>
Below properties are supported by only by ti_am3335x_adc driver and not
ti_am335x_tsc driver. As author of this patch pointed out in another
reply, there is no need to change step-opendelay for tsc. AFAIK, I don't
see a use case where these values needs to be tweaked for tsc channels,
therefore it does not make sense to be DT properties.
> shouldn?t the following be added to am33xx.dtsi and am4372.dtsi?
Its totally upto board dts files to allocate channels for tsc and adc.
So, how could these be added to dtsi files?
> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>
> Regards,
> John
>>
>> --
>> Regards
>> Vignesh
>
--
Regards
Vignesh
^ 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