* [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
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-10 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5824165A.4040303@hisilicon.com>
On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote:
> 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??
The driver should not look at the resources of its children, just
register a range of addresses dynamically, as I suggested in an
earlier review.
Your current version has
if (arm64_extio_ops->pfout) \
arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
addr, value, sizeof(type)); \
Instead, just subtract the start of the range from the logical
port number to transform it back into a bus-local port number:
if (arm64_extio_ops->pfout) \
arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
addr - arm64_extio_ops->start, value, sizeof(type)); \
We know that the ISA/LPC bus can only have up to 65536 ports,
so you can register all of those, or possibly limit it further to
1024 or 4096 ports, whichever matches the bus implementation.
Arnd
^ permalink raw reply
* [PATCH] regulator: gpio: properly check return value of of_get_named_gpio
From: Jisheng Zhang @ 2016-11-10 9:21 UTC (permalink / raw)
To: linux-arm-kernel
The function of_get_named_gpio() could return -ENOENT, -EPROBE_DEFER
-EINVAL and so on. Currently, for the optional property "enable-gpio",
we only check -EPROBE_DEFER, this is not enough since there may be
misconfigured "enable-gpio" in the DTB, of_get_named_gpio() will return
-EINVAL in this case, we should return immediately here. And for the
optional property "gpios", we didn't check the return value, the driver
will continue to the point where gpio_request_array() is called, it
doesn't make sense to continue if we got -EPROBE_DEFER or -EINVAL here.
This patch tries to address these two issues by properly checking the
return value of of_get_named_gpio.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
drivers/regulator/gpio-regulator.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c
index 83e89e5..0fce06a 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -162,8 +162,8 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np,
of_property_read_u32(np, "startup-delay-us", &config->startup_delay);
config->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0);
- if (config->enable_gpio == -EPROBE_DEFER)
- return ERR_PTR(-EPROBE_DEFER);
+ if (config->enable_gpio < 0 && config->enable_gpio != -ENOENT)
+ return ERR_PTR(config->enable_gpio);
/* Fetch GPIOs. - optional property*/
ret = of_gpio_count(np);
@@ -190,8 +190,11 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np,
for (i = 0; i < config->nr_gpios; i++) {
gpio = of_get_named_gpio(np, "gpios", i);
- if (gpio < 0)
+ if (gpio < 0) {
+ if (gpio != -ENOENT)
+ return ERR_PTR(gpio);
break;
+ }
config->gpios[i].gpio = gpio;
if (proplen > 0) {
of_property_read_u32_index(np, "gpios-states",
--
2.10.2
^ permalink raw reply related
* [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: Heiko Stübner @ 2016-11-10 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9eeb3d84-f850-4b76-ce6a-67cc92d6de3b@rock-chips.com>
Am Donnerstag, 10. November 2016, 10:54:49 schrieb wlf:
> Hi Doug,
>
> ? 2016?11?10? 04:54, Doug Anderson ??:
> > Hi,
> >
> > On Mon, Nov 7, 2016 at 5:00 AM, William Wu <wulf@rock-chips.com> wrote:
> >> We found that the system crashed due to 480MHz output clock of
> >> USB2 PHY was unstable after clock had been enabled by gpu module.
> >>
> >> Theoretically, 1 millisecond is a critical value for 480MHz
> >> output clock stable time, so we try to change the delay time
> >> to 1.2 millisecond to avoid this issue.
> >>
> >> Signed-off-by: William Wu <wulf@rock-chips.com>
> >> ---
> >>
> >> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c
> >> b/drivers/phy/phy-rockchip-inno-usb2.c index ecfd7d1..8f2d2b6 100644
> >> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> >> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> >> @@ -267,7 +267,7 @@ static int rockchip_usb2phy_clk480m_enable(struct
> >> clk_hw *hw)>>
> >> return ret;
> >>
> >> /* waitting for the clk become stable */
> >>
> >> - mdelay(1);
> >> + udelay(1200);
> >
> > Several people who have seen this patch have expressed concern that a
> > 1.2 ms delay is pretty long for something that's supposed to be
> > "atomic" like a clk_enable(). Consider that someone might call
> > clk_enable() while interrupts are disabled and that a 1.2 ms interrupt
> > latency is not so great.
> >
> > It seems like this clock should be moved to be enabled in "prepare"
> > and the "enable" should be a no-op. This is a functionality change,
> > but I don't think there are any real users for this clock at the
> > moment so it should be fine.
> >
> > (of course, the 1 ms latency that existed before this patch was still
> > pretty bad, but ...)
>
> Thanks a lot for your suggestion.
> I agree with you. clk_enable() will call spin_lock_irqsave() to disable
> interrupt, and we add
> more than 1ms in clk_enable may cause big latency.
>
> And according to clk_prepare() description:
> In a simple case, clk_prepare can be used instead of clk_enable to
> ungate a clk if the
> operation may sleep. One example is a clk which is accessed over I2c.
>
> So maybe we can remove the clock to clk_prepare.
>
> Hi Heiko, Frank,
> What do you think of it?
moving to clk_prepare sounds sensible. That way you can switch from delay to
sleep functions as well.
Heiko
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6723536.97ljqcB8tS@wuerfel>
Hi Ulf,
On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> >> > And Samsung.
>> >> > Shall I create the immutable branch now?
>> >>
>> >> Arnd: are you happy with the new patches and changes?
>> >
>> > I still had some comments for patch 7, but that shouldn't stop
>> > you from creating a branch for the first three so everyone can
>> > build on top of that.
>>
>> Thanks!
>>
>> What about patch [4/7]?
>> Haven't you received it? Your address was in the To-line for all 7 patches.
>
> Ok, I see it now, looks good. That should be included as well then.
Thanks, I've created the branch/tag :
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
branch soc-device-match
signed tag soc-device-match-tag1
In the mean time, Ulf has applied the first two patches to mmc/next, on top
of lots of MMC work :-(
Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
but also for Samsung and Renesas, would it still be possible to replace these
two commits
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of soc-device-match-tag1?
You can find more info in the full thread at
https://www.spinics.net/lists/devicetree/msg148558.html
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Geert Uytterhoeven @ 2016-11-10 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrcAN_pqgtGaUanfB2zh97zGcL23m5VDtJ3g==NJeRrfA@mail.gmail.com>
Hi Ulf,
On Wed, Nov 9, 2016 at 7:27 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> 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
> Thanks, applied on my mmc tree for next!
Oops, the above two commits (plus two more enhancements) are also a dependency
for Samsung and Renesas. Hence the plan was to use an immutable branch for
that...
Ulf, would it still be possible to replace these two commits in mmc/next:
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of the immutable branch I've just created?
Cfr, the other thread "[PATCH v2 0/7] soc: renesas: Identify SoC and register
with the SoC bus".
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM
From: Nathan Rossi @ 2016-11-10 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d+8kBYQwcUUcL1Z71Geij4EU3pjcv29=r8ndqSLW8iZDw@mail.gmail.com>
On 10 November 2016 at 18:41, Michal Simek <monstr@monstr.eu> wrote:
> + Nathan
>
> 2016-10-31 17:26 GMT+01:00 Kyle Roeschley <kyle.roeschley@ni.com>:
>>
>> On Zynq, we haven't been reserving the correct amount of DMA-incapable
>> RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
>> the first 512k). In older kernels, this was masked by the
>> memblock_reserve call in arm_memblock_init(). Now, reserve the correct
>> amount excplicitly rather than relying on swapper_pg_dir, which is an
>> address and not a size anyway.
>>
>> Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
>> kernel")
>>
>> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
Tested-by: Nathan Rossi <nathan@nathanrossi.com>
For reference this causes problems with DEBUG_RODATA (which changed to
default yes for CPU_V7 in v4.6) due to padding memory between
.head.text and .text, allowing memory below 0x80000 to be available
for allocation as non-reserved memory.
Regards,
Nathan
>> ---
>> Found when migrating from 4.1 to 4.6.
>>
>> arch/arm/mach-zynq/common.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
>> index 6cefdb8..75885bc 100644
>> --- a/arch/arm/mach-zynq/common.c
>> +++ b/arch/arm/mach-zynq/common.c
>> @@ -59,7 +59,7 @@ void __iomem *zynq_scu_base;
>> static void __init zynq_memory_init(void)
>> {
>> if (!__pa(PAGE_OFFSET))
>> - memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
>> + memblock_reserve(__pa(PAGE_OFFSET), 0x80000);
>> }
>>
>> static struct platform_device zynq_cpuidle_device = {
>> --
>> 2.9.3
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-10 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110092221.0219490b@free-electrons.com>
Hi Thomas,
On jeu., nov. 10 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> 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.
I chose to use the adress register inside the window memory.
>
> 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.
I don't know if there is an existing rules for this case. But I see your
concern. What I propose then is to expose the memory windows ID by
adding the target and the attributes like this:
crypto_sram0: sa-sram at 09_09_0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
crypto_sram1: sa-sram at 09_05_0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM
From: Nathan Rossi @ 2016-11-10 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+aJhH11ty3xWQ5-CLCrPA5xH-dr_nVb8JCKZEvgJcm6Ha3xaA@mail.gmail.com>
On 10 November 2016 at 19:33, Nathan Rossi <nathan@nathanrossi.com> wrote:
> On 10 November 2016 at 18:41, Michal Simek <monstr@monstr.eu> wrote:
>> + Nathan
>>
>> 2016-10-31 17:26 GMT+01:00 Kyle Roeschley <kyle.roeschley@ni.com>:
>>>
>>> On Zynq, we haven't been reserving the correct amount of DMA-incapable
>>> RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
>>> the first 512k). In older kernels, this was masked by the
>>> memblock_reserve call in arm_memblock_init(). Now, reserve the correct
>>> amount excplicitly rather than relying on swapper_pg_dir, which is an
>>> address and not a size anyway.
>>>
>>> Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
>>> kernel")
>>>
>>> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
>
> Tested-by: Nathan Rossi <nathan@nathanrossi.com>
>
> For reference this causes problems with DEBUG_RODATA (which changed to
Sorry typo -> s/causes/caused/, as in "... this [incorrect reserving
of the lower 512K] caused ...".
Regards,
Nathan
> default yes for CPU_V7 in v4.6) due to padding memory between
> .head.text and .text, allowing memory below 0x80000 to be available
> for allocation as non-reserved memory.
>
> Regards,
> Nathan
>
>>> ---
>>> Found when migrating from 4.1 to 4.6.
>>>
>>> arch/arm/mach-zynq/common.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
>>> index 6cefdb8..75885bc 100644
>>> --- a/arch/arm/mach-zynq/common.c
>>> +++ b/arch/arm/mach-zynq/common.c
>>> @@ -59,7 +59,7 @@ void __iomem *zynq_scu_base;
>>> static void __init zynq_memory_init(void)
>>> {
>>> if (!__pa(PAGE_OFFSET))
>>> - memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
>>> + memblock_reserve(__pa(PAGE_OFFSET), 0x80000);
>>> }
>>>
>>> static struct platform_device zynq_cpuidle_device = {
>>> --
>>> 2.9.3
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>>
>> --
>> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
>> w: www.monstr.eu p: +42-0-721842854
>> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
>> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
>> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Thomas Petazzoni @ 2016-11-10 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wpgbekwg.fsf@free-electrons.com>
Hello,
On Thu, 10 Nov 2016 10:36:47 +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.
>
> I chose to use the adress register inside the window memory.
Which I think is bogus, as my example below highlighted.
> > 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.
>
> I don't know if there is an existing rules for this case. But I see your
> concern. What I propose then is to expose the memory windows ID by
> adding the target and the attributes like this:
>
> crypto_sram0: sa-sram at 09_09_0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>
>
> crypto_sram1: sa-sram at 09_05_0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
I have no idea if 09_05_0 is considered a valid unit address. Indeed
the _ character in an address looks a bit weird.
I guess we need guidance from the DT binding maintainers on this, since
it's really a matter of interpreting what "unit address" means in
relation to the value of the "reg" property.
Rob, Mark?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3693445.TSdZGaiT9S@wuerfel>
Hi Arnd,
Thanks for your comments!
On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> v2:
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>
> I think I'd rather have seen the family names left in there, but it's
> not important, so up to you.
They're not useful for matching, as family names may change anytime, and don't
always say much about the hardware capabilities.
E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
SuperH.
At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>
> I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> binding for these, among other things.
I understand you've received them in the mean time?
> It does seem wrong to have a device node for a specific register though.
> Shouldn't the node be for the block of registers that these are inside
> of?
On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
we further don't touch at all.
On R-Car Gen2, it's not documented, but does exist.
BTW, see why I'd prefer not to have it in DT at all, and go for KISS in code
we can change at any time? To avoid mistakes we have to keep on supporting
forever.
>> - Don't register the SoC bus if the chip ID register is missing,
>
> Why? My objection was to hardcoding the register, not to registering
> the device? I think I'd rather see the device registered with an
> empty revision string.
If there's no chip ID register, there's no reason to use soc_device_match(),
as we can always look at a compatible value. All SoCs listed in this driver
have a chip ID register.
if you want me to register the soc_bus for those SoCs regardless, I want to
re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
registers ;-)
>> +#define CCCR 0xe600101c /* Common Chip Code Register */
>> +#define PRR 0xff000044 /* Product Register */
>> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
>> +
>> +static const struct of_device_id renesas_socs[] __initconst = {
>> +#ifdef CONFIG_ARCH_R8A73A4
>> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
>> +#endif
>> +#ifdef CONFIG_ARCH_R8A7740
>> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
>> +#endif
>
> My preference here would be to list the register address only for
> SoCs that are known to need them, while also having .dtb files that
> don't have the nodes.
Even if drivers don't have to handle differences, there's been a long
outstanding request to print SoC revision information during bootup
(E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
>> +static int __init renesas_soc_init(void)
>> +{
>> + struct soc_device_attribute *soc_dev_attr;
>> + const struct of_device_id *match;
>> + void __iomem *chipid = NULL;
>> + struct soc_device *soc_dev;
>> + struct device_node *np;
>> + unsigned int product;
>> +
>> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + of_node_put(np);
>> +
>> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> + if (!np)
>> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> + if (np) {
>> + chipid = of_iomap(np, 0);
>> + of_node_put(np);
>> + } else if (match->data) {
>> + chipid = ioremap((uintptr_t)match->data, 4);
>> + }
>> + if (!chipid)
>>
>
> Here, I'd turn the order around and look for the DT nodes of the
> devices first. Only if they are not found, look at the compatible
> string of the root node. No need to search for a node though,
> you know which one it is when you look for a compatible =
> "renesas,r8a73a4".
"renesas,r8a73a4" is the root node, not the device, so it does not have the
"reg" property for reading the chip ID?
There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
Hence I always need to look at the root nodes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Ard Biesheuvel @ 2016-11-10 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109224955.GO14322@bhelgaas-glaptop.roam.corp.google.com>
On 10 November 2016 at 06:49, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Nov 09, 2016 at 08:29:23PM +0000, Ard Biesheuvel wrote:
>> Hi Bjorn,
>>
>> On 9 November 2016 at 20:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Wed, Nov 09, 2016 at 02:25:56PM -0500, Christopher Covington wrote:
>> >> Hi Bjorn,
>> >>
>> [...]
>> >>
>> >> We're working to add the PNP0C02 resource to future firmware, but it's
>> >> not in the current firmware. Are dmesg and /proc/iomem from the
>> >> current firmware interesting or should we wait for the update to file?
>> >
>> > Note that the ECAM space is not the only thing that should be
>> > described via these PNP0C02 devices. *All* non-enumerable resources
>> > should be described by the _CRS method of some ACPI device. Here's a
>> > sample from my laptop:
>> >
>> > PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
>> > system 00:01: [io 0x1800-0x189f] could not be reserved
>> > system 00:01: [io 0x0800-0x087f] has been reserved
>> > system 00:01: [io 0x0880-0x08ff] has been reserved
>> > system 00:01: [io 0x0900-0x097f] has been reserved
>> > system 00:01: [io 0x0980-0x09ff] has been reserved
>> > system 00:01: [io 0x0a00-0x0a7f] has been reserved
>> > system 00:01: [io 0x0a80-0x0aff] has been reserved
>> > system 00:01: [io 0x0b00-0x0b7f] has been reserved
>> > system 00:01: [io 0x0b80-0x0bff] has been reserved
>> > system 00:01: [io 0x15e0-0x15ef] has been reserved
>> > system 00:01: [io 0x1600-0x167f] has been reserved
>> > system 00:01: [io 0x1640-0x165f] has been reserved
>> > system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
>> > system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
>> > system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
>> > system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
>> > system 00:01: [mem 0xfeb00000-0xfebfffff] has been reserved
>> > system 00:01: [mem 0xfed20000-0xfed3ffff] has been reserved
>> > system 00:01: [mem 0xfed90000-0xfed93fff] has been reserved
>> > system 00:01: [mem 0xf7fe0000-0xf7ffffff] has been reserved
>> > system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
>> >
>> > Do you have firmware in the field that may not get updated? If so,
>> > I'd like to see the whole solution for that firmware, including the
>> > MCFG quirk (which tells the PCI core where the ECAM region is) and
>> > whatever PNP0C02 quirk you figure out to actually reserve the region.
>> >
>> > I proposed a PNP0C02 quirk to Duc along these lines of the below. I
>> > don't actually know if it's feasible, but it didn't look as bad as I
>> > expected, so I'd kind of like somebody to try it out. I think you
>> > would have to call this via a DMI hook (do you have DMI on arm64?),
>> > maybe from pnp_init() or similar.
>>
>> We do have SMBIOS/DMI on arm64, but we have been successful so far not
>> to rely on it for quirks, and we'd very much like to keep it that way.
>>
>> Since this ACPI _CRS method has nothing to do with SMBIOS/DMI, surely
>> there is a better way to wire up the reservation code to the
>> information exposed by ACPI?
>
> I'm open to other ways, feel free to propose one :)
>
> If you do a quirk, you need some way to identify the machine/firmware
> combination, because you don't want to apply the quirk on every
> machine. You're trying to work around a firmware issue, so you
> probably want something tied to the firmware version. On x86, that's
> typically done with DMI.
>
I think I misunderstood the purpose of the example: that should only
be necessary if the _CRS methods are missing from the firmware, right?
If we update the firmware to cover all non-enumerable resources by
such a method, we shouldn't need any such quirks at all IIUC
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-10 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110012249.ed56ik6kdffoikym@rob-hp-laptop>
On 10/11/16 01:22, Rob Herring wrote:
> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>> This patch adds specific compatible to support legacy SCPI protocol.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index d1882c4540d0..ebd03fc93135 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>>
>> Required properties:
>>
>> -- compatible : should be "arm,scpi"
>> +- compatible : should be
>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or above
>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>
> I'd prefer that we explicitly enumerate the old versions. Are there
> many?
>
I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.
I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-10 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110111506.02842cbd@free-electrons.com>
Hi Thomas,
On jeu., nov. 10 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
[...]
>> > 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.
>>
>> I don't know if there is an existing rules for this case. But I see your
>> concern. What I propose then is to expose the memory windows ID by
>> adding the target and the attributes like this:
>>
>> crypto_sram0: sa-sram at 09_09_0 {
>> compatible = "mmio-sram";
>> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>>
>>
>> crypto_sram1: sa-sram at 09_05_0 {
>> compatible = "mmio-sram";
>> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
>
> I have no idea if 09_05_0 is considered a valid unit address. Indeed
> the _ character in an address looks a bit weird.
>
> I guess we need guidance from the DT binding maintainers on this, since
> it's really a matter of interpreting what "unit address" means in
> relation to the value of the "reg" property.
So I looked for in the reference: Power_ePAPR_APPROVED_v1.0, and in
paragraph "2.2.1.1 Node Name Requirements" we have:
"The unit-address component of the name is specific to the bus type on
which the node sits. It consists of one or more ASCII characters from
the set of characters in Table 2-1. The fundamental requirement is that
at any level of the device tree the unit-address be unique in order to
differentiate nodes with the same name at the same level in the
tree. The binding for a particular bus may specify additional, more
specific requirements for the format of a unit-address."
In Table 2-1 we have the following characters:
0-9
a-z
A-z
,
.
_
+
-
So the underscore is valid. And by adding information about the memory
windows we match the fundamental requirement :"at any level of the
device tree the unit-address be unique".
Gregory
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 3/3] ARM: gr8: evb: Add i2s codec
From: Maxime Ripard @ 2016-11-10 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v6557B5dooERbKc709Hbrzb3vP8eoSj3nh6rKek7UwrgEQ@mail.gmail.com>
1;4600;0c
On Tue, Nov 08, 2016 at 03:57:48PM +0800, Chen-Yu Tsai wrote:
> On Tue, Nov 8, 2016 at 3:44 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Mon, Nov 07, 2016 at 10:11:45PM +0800, Chen-Yu Tsai wrote:
> >> On Mon, Nov 7, 2016 at 9:08 PM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > The GR8-EVB comes with a wm8978 codec connected to the i2s bus.
> >> >
> >> > Add a card in order to have it working
> >> >
> >> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >> > ---
> >> > arch/arm/boot/dts/ntc-gr8-evb.dts | 14 ++++++++++++++
> >> > 1 file changed, 14 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/arch/arm/boot/dts/ntc-gr8-evb.dts b/arch/arm/boot/dts/ntc-gr8-evb.dts
> >> > index 12b4317a4383..5291e425caf9 100644
> >> > --- a/arch/arm/boot/dts/ntc-gr8-evb.dts
> >> > +++ b/arch/arm/boot/dts/ntc-gr8-evb.dts
> >> > @@ -76,6 +76,20 @@
> >> > default-brightness-level = <8>;
> >> > };
> >> >
> >> > + i2s {
> >>
> >> "sound" might be a better node name? The I2S controllers are also
> >> named "i2s".
> >
> > I know, but we also had the codec and SPDIF on this board, so sound
> > was too generic to be meaningful I guess. I don't really care about
> > the name though, if you have any suggestion...
>
> Well people seem to use "sound" for the sound card nodes...
>
> What about "sound-analog" for this one, and "sound-spdif" for the
> SPDIF simple card? Or "analog-sound" and "spdif-sound" if that looks
> better.
I fixed it and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/e93f3889/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWox5ksj1xhJ6_n0wNA9j6veX0AzAE0V9Gs26Kvw5C_sw@mail.gmail.com>
On Thu, Nov 10, 2016 at 10:22 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
Tested by kbuild test robot:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
soc-device-match
da65a1589dacc7ec44ea0557a14d70a39d991f32 base: soc: Provide a
dummy implementation of soc_device_match()
elapsed time: 101m
configs tested: 85
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [PATCH v7 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-11-10 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0j09fsp4Y66v2UANOGnW4FNO7PWxpZY=Pgw=bUccEL_eA@mail.gmail.com>
Hi Rafael,
On Thu, Nov 10, 2016 at 12:36:12AM +0100, Rafael J. Wysocki wrote:
> Hi Lorenzo,
>
> On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > This patch series is v7 of a previous posting:
> >
> > https://lkml.org/lkml/2016/10/18/506
>
> I don't see anything objectionable in this series.
Thank you very much !
> Please let me know which patches in particular to look at in detail.
Apart from patch 1, patch 7 (and patch 16 that adds on top of it)
requires an ack from an ACPI core perspective. acpi_dma_configure()
should not affect x86/ia64 systems at all so those patches should
not really be controversial (patch 16 adds an IORT hook into
acpi_dma_configure() that is a nop by design on anything other than
ARM64), please let me know if they are ok.
Thank you again for your time,
Lorenzo
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Ulf Hansson @ 2016-11-10 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWox5ksj1xhJ6_n0wNA9j6veX0AzAE0V9Gs26Kvw5C_sw@mail.gmail.com>
On 10 November 2016 at 10:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Ulf,
>
> On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>>> >> > And Samsung.
>>> >> > Shall I create the immutable branch now?
>>> >>
>>> >> Arnd: are you happy with the new patches and changes?
>>> >
>>> > I still had some comments for patch 7, but that shouldn't stop
>>> > you from creating a branch for the first three so everyone can
>>> > build on top of that.
>>>
>>> Thanks!
>>>
>>> What about patch [4/7]?
>>> Haven't you received it? Your address was in the To-line for all 7 patches.
>>
>> Ok, I see it now, looks good. That should be included as well then.
>
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
>
> In the mean time, Ulf has applied the first two patches to mmc/next, on top
> of lots of MMC work :-(
No worries! :-)
>
> Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
> but also for Samsung and Renesas, would it still be possible to replace these
> two commits
>
> 8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
> 6fa350172b098f0f base: soc: Check for NULL SoC device attributes
>
> by a merge of soc-device-match-tag1?
Yes, I will take care of it during the day.
Kind regards
Uffe
^ permalink raw reply
* [PATCH 1/2] iommu/mediatek: Convert M4Uv2 to iommu_fwspec
From: Joerg Roedel @ 2016-11-10 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0205bf6404b16bdebe8039bfc65570a2a6f9f960.1476704508.git.robin.murphy@arm.com>
On Mon, Oct 17, 2016 at 12:49:20PM +0100, Robin Murphy wrote:
> Our per-device data consists of the M4U instance and firmware-provided
> list of LARB IDs, which is a perfect fit for the generic iommu_fwspec
> machinery. Use that directly as a simpler alternative to the custom
> archdata code.
>
> CC: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> These are fairly mechanical cleanups, so I'm pretty confident, but it
> still bears mentioning that they're only compile-tested as I don't have
> the relevant hardware.
>
> Robin.
>
> drivers/iommu/mtk_iommu.c | 75 ++++++++++++-----------------------------------
> 1 file changed, 18 insertions(+), 57 deletions(-)
Applied both, thanks Robin.
^ permalink raw reply
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Charles Keepax @ 2016-11-10 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f53d533d-163f-31f3-4efb-0e39d201589d@samsung.com>
On Tue, Nov 08, 2016 at 04:53:40PM +0100, Sylwester Nawrocki wrote:
> On 11/08/2016 03:55 PM, Charles Keepax wrote:
> >>> diff --git a/arch/arm/mach-s3c64xx/pl080.c b/arch/arm/mach-s3c64xx/pl080.c
> >>> > > index 89c5a62..8c88680 100644
> >>> > > --- a/arch/arm/mach-s3c64xx/pl080.c
> >>> > > +++ b/arch/arm/mach-s3c64xx/pl080.c
> >> > <snip>
> >>> > > @@ -134,6 +153,8 @@ struct pl08x_platform_data s3c64xx_dma0_plat_data = {
> >>> > > .put_xfer_signal = pl08x_put_xfer_signal,
> >>> > > .slave_channels = s3c64xx_dma0_info,
> >>> > > .num_slave_channels = ARRAY_SIZE(s3c64xx_dma0_info),
> >>> > > + .slave_map = s3c64xx_dma0_slave_map,
> >>> > > + .slavecnt = ARRAY_SIZE(s3c64xx_dma0_slave_map),
> >>> > > };
> >> >
> >> > Here we add a .slavecnt but the pl08x_platform_data structure doesn't
> >> > contain that field. I can't see it on the branch you linked in
> >> > the cover letter either, is it added by a patch on another branch
> >> > I am missing?
> >> >
> > Ah I think I see it should be .slave_map_len here.
>
> Yeah, sorry, I fixed it after getting report from the kbuild test
> but have forgotten to push changes to the git tree.
>
> I pushed now to branch for-v4.10/dma/pl080-s3c64xx-v2 with this
> issue fixed and added initialization of the filer function.
Apologies for the delay got somewhat swamped with internal stuff
yesterday. Yeah using that branch it looks good to me, the SPI and
I2S are both working fine. I can download code to the wm0010
which should be a good work out of the SPI and play audio
correctly so the I2S should be fine. So for the series:
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
I do still need to revert these two patches to get the I2S to
work properly:
commit d70e861a3154833467023123e218e9b1ba558809
ASoC: samsung: Remove SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag
commit acde50a7bf1fd6ae0baa4402f0a02c4b1bd4c990
ASoC: dmaengine_pcm: Make FLAG_NO_RESIDUE internal
But that is clearly an unrelated issue, which I haven't found
time to look into yet as we don't use this platform that often
these days.
Thanks,
Charles
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Lorenzo Pieralisi @ 2016-11-10 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3136fae-144c-5949-3933-671b783671c8@arm.com>
On Wed, Nov 09, 2016 at 02:40:08PM +0000, Robin Murphy wrote:
[...]
> > +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops)
> > +{
> > + struct iommu_fwentry *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> > +
> > + if (WARN_ON(!iommu))
> > + return;
> > +
> > + if (is_of_node(fwnode))
>
> Nit: this check is actually redundant, since to_of_node() already does
> the right thing and of_node_get() is NULL-safe - iommu_fwspec_init()
> already works that way. On the other hand, though, it is perhaps more
> intuitive to see it explicitly, and since to_of_node() is inline it
> ought to result in the same object code (I've not checked, though).
I can easily fold this change in the final code and I think we
should keep this consistent so I am happy to change my code and
make the is_of_node() check implicit.
> Either way:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Thank you !
Lorenzo
> > + of_node_get(to_of_node(fwnode));
> > +
> > + INIT_LIST_HEAD(&iommu->list);
> > + iommu->fwnode = fwnode;
> > + iommu->ops = ops;
> > + spin_lock(&iommu_fwentry_lock);
> > + list_add_tail(&iommu->list, &iommu_fwentry_list);
> > + spin_unlock(&iommu_fwentry_lock);
> > +}
> > +
> > +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> > +{
> > + struct iommu_fwentry *node;
> > + const struct iommu_ops *ops = NULL;
> > +
> > + spin_lock(&iommu_fwentry_lock);
> > + list_for_each_entry(node, &iommu_fwentry_list, list)
> > + if (node->fwnode == fwnode) {
> > + ops = node->ops;
> > + break;
> > + }
> > + spin_unlock(&iommu_fwentry_lock);
> > + return ops;
> > +}
> > +
> > int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> > const struct iommu_ops *ops)
> > {
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > index 5b82862..0f57ddc 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> > }
> > EXPORT_SYMBOL_GPL(of_get_dma_window);
> >
> > -struct of_iommu_node {
> > - struct list_head list;
> > - struct device_node *np;
> > - const struct iommu_ops *ops;
> > -};
> > -static LIST_HEAD(of_iommu_list);
> > -static DEFINE_SPINLOCK(of_iommu_lock);
> > -
> > -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
> > -{
> > - struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> > -
> > - if (WARN_ON(!iommu))
> > - return;
> > -
> > - of_node_get(np);
> > - INIT_LIST_HEAD(&iommu->list);
> > - iommu->np = np;
> > - iommu->ops = ops;
> > - spin_lock(&of_iommu_lock);
> > - list_add_tail(&iommu->list, &of_iommu_list);
> > - spin_unlock(&of_iommu_lock);
> > -}
> > -
> > -const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> > -{
> > - struct of_iommu_node *node;
> > - const struct iommu_ops *ops = NULL;
> > -
> > - spin_lock(&of_iommu_lock);
> > - list_for_each_entry(node, &of_iommu_list, list)
> > - if (node->np == np) {
> > - ops = node->ops;
> > - break;
> > - }
> > - spin_unlock(&of_iommu_lock);
> > - return ops;
> > -}
> > -
> > static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> > {
> > struct of_phandle_args *iommu_spec = data;
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index 436dc21..15d5478 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -351,6 +351,9 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> > const struct iommu_ops *ops);
> > void iommu_fwspec_free(struct device *dev);
> > int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> > +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops);
> > +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode);
> >
> > #else /* CONFIG_IOMMU_API */
> >
> > @@ -580,6 +583,17 @@ static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
> > return -ENODEV;
> > }
> >
> > +static inline void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops)
> > +{
> > +}
> > +
> > +static inline
> > +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> > +{
> > + return NULL;
> > +}
> > +
> > #endif /* CONFIG_IOMMU_API */
> >
> > #endif /* __LINUX_IOMMU_H */
> > diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> > index e80b9c7..7681007 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -31,8 +31,16 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
> >
> > #endif /* CONFIG_OF_IOMMU */
> >
> > -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
> > -const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
> > +static inline void of_iommu_set_ops(struct device_node *np,
> > + const struct iommu_ops *ops)
> > +{
> > + fwnode_iommu_set_ops(&np->fwnode, ops);
> > +}
> > +
> > +static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> > +{
> > + return fwnode_iommu_get_ops(&np->fwnode);
> > +}
> >
> > extern struct of_device_id __iommu_of_table;
> >
> >
>
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Auger Eric @ 2016-11-10 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110020130.GA19108@arm.com>
Hi Will, Alex,
On 10/11/2016 03:01, Will Deacon wrote:
> On Wed, Nov 09, 2016 at 05:55:17PM -0700, Alex Williamson wrote:
>> On Thu, 10 Nov 2016 01:14:42 +0100
>> Auger Eric <eric.auger@redhat.com> wrote:
>>> On 10/11/2016 00:59, Alex Williamson wrote:
>>>> On Wed, 9 Nov 2016 23:38:50 +0000
>>>> Will Deacon <will.deacon@arm.com> wrote:
>>>>> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
>>>>>> The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
>>>>>> of IOVAs to a range of virtual addresses for a given device. If VFIO
>>>>>> cannot reasonably fulfill that contract, it must fail. It's up to QEMU
>>>>>> how to manage the hotplug and what memory regions it asks VFIO to map
>>>>>> for a device, but VFIO must reject mappings that it (or the SMMU by
>>>>>> virtue of using the IOMMU API) know to overlap reserved ranges. So I
>>>>>> still disagree with the referenced statement. Thanks,
>>>>>
>>>>> I think that's a pity. Not only does it mean that both QEMU and the kernel
>>>>> have more work to do (the former has to carve up its mapping requests,
>>>>> whilst the latter has to check that it is indeed doing this), but it also
>>>>> precludes the use of hugepage mappings on the IOMMU because of reserved
>>>>> regions. For example, a 4k hole someplace may mean we can't put down 1GB
>>>>> table entries for the guest memory in the SMMU.
>>>>>
>>>>> All this seems to do is add complexity and decrease performance. For what?
>>>>> QEMU has to go read the reserved regions from someplace anyway. It's also
>>>>> the way that VFIO works *today* on arm64 wrt reserved regions, it just has
>>>>> no way to identify those holes at present.
>>>>
>>>> Sure, that sucks, but how is the alternative even an option? The user
>>>> asked to map something, we can't, if we allow that to happen now it's a
>>>> bug. Put the MSI doorbells somewhere that this won't be an issue. If
>>>> the platform has it fixed somewhere that this is an issue, don't use
>>>> that platform. The correctness of the interface is more important than
>>>> catering to a poorly designed system layout IMO. Thanks,
>>>
>>> Besides above problematic, I started to prototype the sysfs API. A first
>>> issue I face is the reserved regions become global to the iommu instead
>>> of characterizing the iommu_domain, ie. the "reserved_regions" attribute
>>> file sits below an iommu instance (~
>>> /sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
>>> /sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
>>>
>>> MSI reserved window can be considered global to the IOMMU. However PCIe
>>> host bridge P2P regions rather are per iommu-domain.
>
> I don't think we can treat them as per-domain, given that we want to
> enumerate this stuff before we've decided to do a hotplug (and therefore
> don't have a domain).
That's the issue indeed. We need to wait for the PCIe device to be
connected to the iommu. Only on the VFIO SET_IOMMU we get the
comprehensive list of P2P regions that can impact IOVA mapping for this
iommu. This removes any advantage of sysfs API over previous VFIO
capability chain API for P2P IOVA range enumeration at early stage.
>
>>>
>>> Do you confirm the attribute file should contain both global reserved
>>> regions and all per iommu_domain reserved regions?
>>>
>>> Thoughts?
>>
>> I don't think we have any business describing IOVA addresses consumed
>> by peer devices in an IOMMU sysfs file. If it's a separate device it
>> should be exposed by examining the rest of the topology. Regions
>> consumed by PCI endpoints and interconnects are already exposed in
>> sysfs. In fact, is this perhaps a more accurate model for these MSI
>> controllers too? Perhaps they should be exposed in the bus topology
>> somewhere as consuming the IOVA range.
Currently on x86 the P2P regions are not checked when allowing
passthrough. Aren't we more papist that the pope? As Don mentioned,
shouldn't we simply consider that a platform that does not support
proper ACS is not candidate for safe passthrough, like Juno?
At least we can state the feature also is missing on x86 and it would be
nice to report the risk to the userspace and urge him to opt-in.
To me taking into account those P2P still is controversial and induce
the bulk of the complexity. Considering the migration use case discussed
at LPC while only handling the MSI problem looks much easier.
host can choose an MSI base that is QEMU mach-virt friendly, ie. non RAM
region. Problem is to satisfy all potential uses though. When migrating,
mach-virt still is being used so there should not be any collision. Am I
missing some migration weird use cases here? Of course if we take into
consideration new host PCIe P2P regions this becomes completely different.
We still have the good old v14 where the user space chose where MSI
IOVA's are put without any risk of collision ;-)
>> If DMA to an IOVA is consumed
>> by an intermediate device before it hits the IOMMU vs not being
>> translated as specified by the user at the IOMMU, I'm less inclined to
>> call that something VFIO should reject.
>
> Oh, so perhaps we've been talking past each other. In all of these cases,
> the SMMU can translate the access if it makes it that far. The issue is
> that not all accesses do make it that far, because they may be "consumed"
> by another device, such as an MSI doorbell or another endpoint. In other
> words, I don't envisage a scenario where e.g. some address range just
> bypasses the SMMU straight to memory. I realise now that that's not clear
> from the slides I presented.
>
>> However, instantiating a VM
>> with holes to account for every potential peer device seems like it
>> borders on insanity. Thanks,
>
> Ok, so rather than having a list of reserved regions under the iommu node,
> you're proposing that each region is attributed to the device that "owns"
> (consumes) it? I think that can work, but we need to make sure that:
>
> (a) The topology is walkable from userspace (where do you start?)
>
> (b) It also works for platform (non-PCI) devices, that lack much in the
> way of bus hierarchy
>
> (c) It doesn't require Linux to have a driver bound to a device in order
> for the ranges consumed by that device to be advertised (again,
> more of an issue for non-PCI).
Looks a long way ...
Thanks
Eric
>
> How is this currently advertised for PCI? I'd really like to use the same
> scheme irrespective of the bus type.
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v16 0/5] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2016-11-10 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477999698-6288-1-git-send-email-hs.liao@mediatek.com>
On Tue, 2016-11-01 at 19:28 +0800, HS Liao wrote:
> Hi,
>
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
>
> These patches have a build dependency on top of v4.9-rc1.
>
> Changes since v15:
> - separate "suspend and resume" patch from "save energy" patch
> - don't stop running tasks in cmdq_suspend()
> (i.e. leave no running tasks guarantee to clients)
>
> Best regards,
> HS Liao
>
> HS Liao (5):
> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> CMDQ: Mediatek CMDQ driver
> arm64: dts: mt8173: Add GCE node
> CMDQ: suspend and resume
> CMDQ: save energy
>
> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 ++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mtk-cmdq-mailbox.c | 632 +++++++++++++++++++++
> drivers/soc/mediatek/Kconfig | 11 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-cmdq-helper.c | 310 ++++++++++
> include/linux/mailbox/mtk-cmdq-mailbox.h | 67 +++
> include/linux/soc/mediatek/mtk-cmdq.h | 182 ++++++
> 10 files changed, 1268 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
>
Hi Jassi, Matthias,
Sorry to disturb you.
Do you have any further comment on CMDQ v16?
Thanks.
HS
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Mark Rutland @ 2016-11-10 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478647002.7430.69.camel@kernel.crashing.org>
On Wed, Nov 09, 2016 at 10:16:42AM +1100, 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.
>
> 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.
Just to check, do you hook that in your inb/outb/etc?
Generally, it would seem nicer if we could have higher-level
isa_{inb,outb,whatever} accessors that we could hook separately from
other IO.
We don't necessarily have to move all ISA drivers over to that if we had
a separate symbol for that interface.
Thanks,
Mark.
^ permalink raw reply
* [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain
From: Auger Eric @ 2016-11-10 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71bfe2a5-455e-9335-ba81-097ef24399ee@arm.com>
Hi Robin,
On 04/11/2016 15:00, Robin Murphy wrote:
> Hi Eric,
>
> Thanks for posting this new series - the bottom-up approach is a lot
> easier to reason about :)
>
> On 04/11/16 11:24, Eric Auger wrote:
>> Introduce a new iommu_reserved_region struct. This embodies
>> an IOVA reserved region that cannot be used along with the IOMMU
>> API. The list is protected by a dedicated mutex.
>
> In the light of these patches, I think I'm settling into agreement that
> the iommu_domain is the sweet spot for accessing this information - the
> underlying magic address ranges might be properties of various bits of
> hardware many of which aren't the IOMMU itself, but they only start to
> matter at the point you start wanting to use an IOMMU domain at the
> higher level. Therefore, having a callback in the domain ops to pull
> everything together fits rather neatly.
Using get_dm_regions could have make sense but this approach now is
ruled out by sysfs API approach. If attribute file is bound to be used
before iommu domains are created, we cannot rely on any iommu_domain
based callback. Back to square 1?
Thanks
Eric
>
>>
>> An iommu domain now owns a list of those.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> ---
>> drivers/iommu/iommu.c | 2 ++
>> include/linux/iommu.h | 17 +++++++++++++++++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 9a2f196..0af07492 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -1061,6 +1061,8 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>>
>> domain->ops = bus->iommu_ops;
>> domain->type = type;
>> + INIT_LIST_HEAD(&domain->reserved_regions);
>> + mutex_init(&domain->resv_mutex);
>> /* Assume all sizes by default; the driver may override this later */
>> domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap;
>>
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index 436dc21..0f2eb64 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -84,6 +84,8 @@ struct iommu_domain {
>> void *handler_token;
>> struct iommu_domain_geometry geometry;
>> void *iova_cookie;
>> + struct list_head reserved_regions;
>> + struct mutex resv_mutex; /* protects the reserved region list */
>> };
>>
>> enum iommu_cap {
>> @@ -131,6 +133,21 @@ struct iommu_dm_region {
>> int prot;
>> };
>>
>> +/**
>> + * struct iommu_reserved_region - descriptor for a reserved iova region
>> + * @list: Linked list pointers
>> + * @start: IOVA base address of the region
>> + * @length: Length of the region in bytes
>> + */
>> +struct iommu_reserved_region {
>> + struct list_head list;
>> + dma_addr_t start;
>> + size_t length;
>> +};
>
> Looking at this in context with the dm_region above, though, I come to
> the surprising realisation that these *are* dm_regions, even at the
> fundamental level - on the one hand you've got physical addresses which
> can't be remapped (because something is already using them), while on
> the other you've got physical addresses which can't be remapped (because
> the IOMMU is incapable). In fact for reserved regions *other* than our
> faked-up MSI region there's no harm if the IOMMU were to actually
> identity-map them.
>
> Let's just add this to the existing infrastructure, either with some
> kind of IOMMU_NOMAP flag or simply prot = 0. That way it automatically
> gets shared between the VFIO and DMA cases for free!
>
> Robin.
>
>> +
>> +#define iommu_reserved_region_for_each(resv, d) \
>> + list_for_each_entry(resv, &(d)->reserved_regions, list)
>> +
>> #ifdef CONFIG_IOMMU_API
>>
>> /**
>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at 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