* [PATCH] arm64: defconfig: Select schedutil as default cpufreq governor
From: Catalin Marinas @ 2017-12-15 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af12e002bc165844101830c0eb00e283b536a879.1510813288.git.viresh.kumar@linaro.org>
On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote:
> Currently performance governor is getting selected by default, which is
> surely not a very good choice as its pretty much power hungry.
>
> Select schedutil instead.
And why do we care about this in defconfig? People deploying their own
kernels in mobile may opt for this config, others may prefer the default
governor.
Also it seems it would be the only architecture make this governor the
default, so NAK.
--
Catalin
^ permalink raw reply
* [PATCH] spi: atmel: fixed spin_lock usage inside atmel_spi_remove
From: Radu Pirea @ 2017-12-15 15:40 UTC (permalink / raw)
To: linux-arm-kernel
The only part of atmel_spi_remove which needs to be atomic is hardware
reset.
atmel_spi_stop_dma calls dma_terminate_all and this needs interrupts
enabled.
atmel_spi_release_dma calls dma_release_channel and dma_release_channel
locks a mutex inside of spin_lock.
So the call of these functions can't be inside a spin_lock.
Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
---
drivers/spi/spi-atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index f95da36..6694709 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1661,12 +1661,12 @@ static int atmel_spi_remove(struct platform_device *pdev)
pm_runtime_get_sync(&pdev->dev);
/* reset the hardware and block queue progress */
- spin_lock_irq(&as->lock);
if (as->use_dma) {
atmel_spi_stop_dma(master);
atmel_spi_release_dma(master);
}
+ spin_lock_irq(&as->lock);
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
spi_readl(as, SR);
--
2.7.4
^ permalink raw reply related
* [PATCH 06/10] arm64: handle 52-bit physical addresses in page table entries
From: Marc Zyngier @ 2017-12-15 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513184845-8711-7-git-send-email-kristina.martsenko@arm.com>
On 13/12/17 17:07, Kristina Martsenko wrote:
> The top 4 bits of a 52-bit physical address are positioned at bits
> 12..15 of a page table entry. Introduce macros to convert between a
> physical address and its placement in a table entry, and change all
> macros/functions that access PTEs to use them.
>
> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 09/10] arm64: allow ID map to be extended to 52 bits
From: Marc Zyngier @ 2017-12-15 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513184845-8711-10-git-send-email-kristina.martsenko@arm.com>
On 13/12/17 17:07, Kristina Martsenko wrote:
> Currently, when using VA_BITS < 48, if the ID map text happens to be
> placed in physical memory above VA_BITS, we increase the VA size (up to
> 48) and create a new table level, in order to map in the ID map text.
> This is okay because the system always supports 48 bits of VA.
>
> This patch extends the code such that if the system supports 52 bits of
> VA, and the ID map text is placed that high up, then we increase the VA
> size accordingly, up to 52.
>
> One difference from the current implementation is that so far the
> condition of VA_BITS < 48 has meant that the top level table is always
> "full", with the maximum number of entries, and an extra table level is
> always needed. Now, when VA_BITS = 48 (and using 64k pages), the top
> level table is not full, and we simply need to increase the number of
> entries in it, instead of creating a new table level.
>
> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
> ---
> arch/arm/include/asm/kvm_mmu.h | 5 +++
> arch/arm64/include/asm/assembler.h | 2 -
> arch/arm64/include/asm/kvm_mmu.h | 7 +++-
> arch/arm64/include/asm/mmu_context.h | 14 ++++++-
> arch/arm64/kernel/head.S | 76 +++++++++++++++++++++---------------
> arch/arm64/kvm/hyp-init.S | 17 ++++----
> arch/arm64/mm/mmu.c | 1 +
> virt/kvm/arm/mmu.c | 12 +++---
> 8 files changed, 83 insertions(+), 51 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 8dbec683638b..8c5643e2eea4 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -211,6 +211,11 @@ static inline bool __kvm_cpu_uses_extended_idmap(void)
> return false;
> }
>
> +static inline unsigned long __kvm_idmap_ptrs_per_pgd(void)
> +{
> + return PTRS_PER_PGD;
> +}
> +
> static inline void __kvm_extend_hypmap(pgd_t *boot_hyp_pgd,
> pgd_t *hyp_pgd,
> pgd_t *merged_hyp_pgd,
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index 2058fd864bfb..11719b11f4a7 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -344,10 +344,8 @@ alternative_endif
> * tcr_set_idmap_t0sz - update TCR.T0SZ so that we can load the ID map
> */
> .macro tcr_set_idmap_t0sz, valreg, tmpreg
> -#ifndef CONFIG_ARM64_VA_BITS_48
> ldr_l \tmpreg, idmap_t0sz
> bfi \valreg, \tmpreg, #TCR_T0SZ_OFFSET, #TCR_TxSZ_WIDTH
> -#endif
> .endm
>
> /*
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index b3f7b68b042d..8d663ca0d50c 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -273,7 +273,12 @@ void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
>
> static inline bool __kvm_cpu_uses_extended_idmap(void)
> {
> - return __cpu_uses_extended_idmap();
> + return __cpu_uses_extended_idmap_table();
> +}
> +
> +static inline unsigned long __kvm_idmap_ptrs_per_pgd(void)
> +{
> + return idmap_ptrs_per_pgd;
> }
>
> /*
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index accc2ff32a0e..043eed856b55 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -63,11 +63,21 @@ static inline void cpu_set_reserved_ttbr0(void)
> * physical memory, in which case it will be smaller.
> */
> extern u64 idmap_t0sz;
> +extern u64 idmap_ptrs_per_pgd;
>
> static inline bool __cpu_uses_extended_idmap(void)
> {
> - return (!IS_ENABLED(CONFIG_ARM64_VA_BITS_48) &&
> - unlikely(idmap_t0sz != TCR_T0SZ(VA_BITS)));
> + return unlikely(idmap_t0sz != TCR_T0SZ(VA_BITS));
> +}
> +
> +/*
> + * True if the extended ID map requires an extra level of translation table
> + * to be configured.
> + */
> +static inline bool __cpu_uses_extended_idmap_table(void)
> +{
> + return __cpu_uses_extended_idmap() &&
> + (idmap_ptrs_per_pgd == PTRS_PER_PGD);
> }
>
> /*
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 64e09f207d1d..465f70328ba0 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -172,7 +172,7 @@ ENDPROC(preserve_boot_args)
> * ptrs: #imm pointers per table page
> *
> * Preserves: virt
> - * Corrupts: tmp1, tmp2
> + * Corrupts: ptrs, tmp1, tmp2
> * Returns: tbl -> next level table page address
> */
> .macro create_table_entry, tbl, virt, shift, ptrs, tmp1, tmp2
> @@ -180,7 +180,8 @@ ENDPROC(preserve_boot_args)
> phys_to_pte \tmp1, \tmp2
> orr \tmp2, \tmp2, #PMD_TYPE_TABLE // address of next table and entry type
> lsr \tmp1, \virt, #\shift
> - and \tmp1, \tmp1, #\ptrs - 1 // table index
> + sub \ptrs, \ptrs, #1
> + and \tmp1, \tmp1, \ptrs // table index
> str \tmp2, [\tbl, \tmp1, lsl #3]
> add \tbl, \tbl, #PAGE_SIZE // next level table page
> .endm
> @@ -190,15 +191,17 @@ ENDPROC(preserve_boot_args)
> * block entry in the next level (tbl) for the given virtual address.
> *
> * Preserves: tbl, next, virt
> - * Corrupts: tmp1, tmp2
> + * Corrupts: ptrs_per_pgd, tmp1, tmp2
> */
> - .macro create_pgd_entry, tbl, virt, tmp1, tmp2
> - create_table_entry \tbl, \virt, PGDIR_SHIFT, PTRS_PER_PGD, \tmp1, \tmp2
> + .macro create_pgd_entry, tbl, virt, ptrs_per_pgd, tmp1, tmp2
> + create_table_entry \tbl, \virt, PGDIR_SHIFT, \ptrs_per_pgd, \tmp1, \tmp2
> #if SWAPPER_PGTABLE_LEVELS > 3
> - create_table_entry \tbl, \virt, PUD_SHIFT, PTRS_PER_PUD, \tmp1, \tmp2
> + mov \ptrs_per_pgd, PTRS_PER_PUD
> + create_table_entry \tbl, \virt, PUD_SHIFT, \ptrs_per_pgd, \tmp1, \tmp2
> #endif
> #if SWAPPER_PGTABLE_LEVELS > 2
> - create_table_entry \tbl, \virt, SWAPPER_TABLE_SHIFT, PTRS_PER_PTE, \tmp1, \tmp2
> + mov \ptrs_per_pgd, PTRS_PER_PTE
> + create_table_entry \tbl, \virt, SWAPPER_TABLE_SHIFT, \ptrs_per_pgd, \tmp1, \tmp2
> #endif
> .endm
>
> @@ -262,26 +265,13 @@ __create_page_tables:
> adrp x0, idmap_pg_dir
> adrp x3, __idmap_text_start // __pa(__idmap_text_start)
>
> -#ifndef CONFIG_ARM64_VA_BITS_48
> -#define EXTRA_SHIFT (PGDIR_SHIFT + PAGE_SHIFT - 3)
> -#define EXTRA_PTRS (1 << (48 - EXTRA_SHIFT))
> -
> - /*
> - * If VA_BITS < 48, it may be too small to allow for an ID mapping to be
> - * created that covers system RAM if that is located sufficiently high
> - * in the physical address space. So for the ID map, use an extended
> - * virtual range in that case, by configuring an additional translation
> - * level.
> - * First, we have to verify our assumption that the current value of
> - * VA_BITS was chosen such that all translation levels are fully
> - * utilised, and that lowering T0SZ will always result in an additional
> - * translation level to be configured.
> - */
> -#if VA_BITS != EXTRA_SHIFT
> -#error "Mismatch between VA_BITS and page size/number of translation levels"
> -#endif
> -
> /*
> + * VA_BITS may be too small to allow for an ID mapping to be created
> + * that covers system RAM if that is located sufficiently high in the
> + * physical address space. So for the ID map, use an extended virtual
> + * range in that case, and configure an additional translation level
> + * if needed.
> + *
> * Calculate the maximum allowed value for TCR_EL1.T0SZ so that the
> * entire ID map region can be mapped. As T0SZ == (64 - #bits used),
> * this number conveniently equals the number of leading zeroes in
> @@ -290,18 +280,41 @@ __create_page_tables:
> adrp x5, __idmap_text_end
> clz x5, x5
> cmp x5, TCR_T0SZ(VA_BITS) // default T0SZ small enough?
> - b.ge 1f // .. then skip additional level
> + b.ge 1f // .. then skip VA range extension
>
> adr_l x6, idmap_t0sz
> str x5, [x6]
> dmb sy
> dc ivac, x6 // Invalidate potentially stale cache line
>
> - create_table_entry x0, x3, EXTRA_SHIFT, EXTRA_PTRS, x5, x6
> -1:
> +#if (VA_BITS < 48)
> +#define EXTRA_SHIFT (PGDIR_SHIFT + PAGE_SHIFT - 3)
> +#define EXTRA_PTRS (1 << (PHYS_MASK_SHIFT - EXTRA_SHIFT))
> +
> + /*
> + * If VA_BITS < 48, we have to configure an additional table level.
> + * First, we have to verify our assumption that the current value of
> + * VA_BITS was chosen such that all translation levels are fully
> + * utilised, and that lowering T0SZ will always result in an additional
> + * translation level to be configured.
> + */
> +#if VA_BITS != EXTRA_SHIFT
> +#error "Mismatch between VA_BITS and page size/number of translation levels"
> #endif
>
> - create_pgd_entry x0, x3, x5, x6
> + mov x4, EXTRA_PTRS
> + create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6
> +#else
> + /*
> + * If VA_BITS == 48, we don't have to configure an additional
> + * translation level, but the top-level table has more entries.
> + */
> + mov x4, #1 << (PHYS_MASK_SHIFT - PGDIR_SHIFT)
> + str_l x4, idmap_ptrs_per_pgd, x5
> +#endif
> +1:
> + ldr_l x4, idmap_ptrs_per_pgd
> + create_pgd_entry x0, x3, x4, x5, x6
> mov x5, x3 // __pa(__idmap_text_start)
> adr_l x6, __idmap_text_end // __pa(__idmap_text_end)
> create_block_map x0, x7, x3, x5, x6, x4
> @@ -312,7 +325,8 @@ __create_page_tables:
> adrp x0, swapper_pg_dir
> mov_q x5, KIMAGE_VADDR + TEXT_OFFSET // compile time __va(_text)
> add x5, x5, x23 // add KASLR displacement
> - create_pgd_entry x0, x5, x3, x6
> + mov x4, PTRS_PER_PGD
> + create_pgd_entry x0, x5, x4, x3, x6
> adrp x6, _end // runtime __pa(_end)
> adrp x3, _text // runtime __pa(_text)
> sub x6, x6, x3 // _end - _text
> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> index a99718f32af9..c2ebe4e992df 100644
> --- a/arch/arm64/kvm/hyp-init.S
> +++ b/arch/arm64/kvm/hyp-init.S
> @@ -72,24 +72,23 @@ __do_hyp_init:
> mov x5, #TCR_EL2_RES1
> orr x4, x4, x5
>
> -#ifndef CONFIG_ARM64_VA_BITS_48
> /*
> - * If we are running with VA_BITS < 48, we may be running with an extra
> - * level of translation in the ID map. This is only the case if system
> - * RAM is out of range for the currently configured page size and number
> - * of translation levels, in which case we will also need the extra
> - * level for the HYP ID map, or we won't be able to enable the EL2 MMU.
> + * The ID map may be configured to use an extended virtual address
> + * range. This is only the case if system RAM is out of range for the
> + * currently configured page size and VA_BITS, in which case we will
> + * also need the extended virtual range for the HYP ID map, or we won't
> + * be able to enable the EL2 MMU.
> *
> * However, at EL2, there is only one TTBR register, and we can't switch
> * between translation tables *and* update TCR_EL2.T0SZ at the same
> - * time. Bottom line: we need the extra level in *both* our translation
> - * tables.
> + * time. Bottom line: we need to use the extended range with *both* our
> + * translation tables.
> *
> * So use the same T0SZ value we use for the ID map.
> */
> ldr_l x5, idmap_t0sz
> bfi x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
> -#endif
> +
> /*
> * Set the PS bits in TCR_EL2.
> */
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 0c631a17ae1d..baa34418c3bf 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -50,6 +50,7 @@
> #define NO_CONT_MAPPINGS BIT(1)
>
> u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
> +u64 idmap_ptrs_per_pgd = PTRS_PER_PGD;
>
> u64 kimage_voffset __ro_after_init;
> EXPORT_SYMBOL(kimage_voffset);
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index b36945d49986..876caf531d32 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -623,7 +623,7 @@ static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
> return 0;
> }
>
> -static int __create_hyp_mappings(pgd_t *pgdp,
> +static int __create_hyp_mappings(pgd_t *pgdp, unsigned long ptrs_per_pgd,
> unsigned long start, unsigned long end,
> unsigned long pfn, pgprot_t prot)
> {
> @@ -636,7 +636,7 @@ static int __create_hyp_mappings(pgd_t *pgdp,
> addr = start & PAGE_MASK;
> end = PAGE_ALIGN(end);
> do {
> - pgd = pgdp + pgd_index(addr);
> + pgd = pgdp + ((addr >> PGDIR_SHIFT) & (ptrs_per_pgd - 1));
>
> if (pgd_none(*pgd)) {
> pud = pud_alloc_one(NULL, addr);
> @@ -699,8 +699,8 @@ int create_hyp_mappings(void *from, void *to, pgprot_t prot)
> int err;
>
> phys_addr = kvm_kaddr_to_phys(from + virt_addr - start);
> - err = __create_hyp_mappings(hyp_pgd, virt_addr,
> - virt_addr + PAGE_SIZE,
> + err = __create_hyp_mappings(hyp_pgd, PTRS_PER_PGD,
> + virt_addr, virt_addr + PAGE_SIZE,
> __phys_to_pfn(phys_addr),
> prot);
> if (err)
> @@ -731,7 +731,7 @@ int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
> if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
> return -EINVAL;
>
> - return __create_hyp_mappings(hyp_pgd, start, end,
> + return __create_hyp_mappings(hyp_pgd, PTRS_PER_PGD, start, end,
> __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
> }
>
> @@ -1737,7 +1737,7 @@ static int kvm_map_idmap_text(pgd_t *pgd)
> int err;
>
> /* Create the idmap in the boot page tables */
> - err = __create_hyp_mappings(pgd,
> + err = __create_hyp_mappings(pgd, __kvm_idmap_ptrs_per_pgd(),
> hyp_idmap_start, hyp_idmap_end,
> __phys_to_pfn(hyp_idmap_start),
> PAGE_HYP_EXEC);
>
I wonder if you could push these changes into __create_hyp_mappings()
instead of changing all the call sites:
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index b36945d49986..0d44fb2bd9c6 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -629,14 +629,17 @@ static int __create_hyp_mappings(pgd_t *pgdp,
{
pgd_t *pgd;
pud_t *pud;
- unsigned long addr, next;
+ unsigned long addr, next, ptrs_per_pgd = PTRS_PER_PGD;
int err = 0;
+ if (pgdp != hyp_pgd)
+ ptrs_per_pgd = __kvm_idmap_ptrs_per_pgd();
+
mutex_lock(&kvm_hyp_pgd_mutex);
addr = start & PAGE_MASK;
end = PAGE_ALIGN(end);
do {
- pgd = pgdp + pgd_index(addr);
+ pgd = pgdp + ((addr >> PGDIR_SHIFT) & (ptrs_per_pgd - 1));
if (pgd_none(*pgd)) {
pud = pud_alloc_one(NULL, addr);
with a suitable comment explaining why this is needed?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [PATCH] arm64: defconfig: enable ARM_ARMADA_37XX_CPUFREQ
From: Gregory CLEMENT @ 2017-12-15 15:35 UTC (permalink / raw)
To: linux-arm-kernel
Add the cpu frequency scaling support for Armada 37xx by default, this
should allow a better coverage in kernel continuous integration tests.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6356c6da34ea..a4222de46500 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -99,6 +99,7 @@ CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
CONFIG_ARM_CPUIDLE=y
CONFIG_CPU_FREQ=y
CONFIG_CPUFREQ_DT=y
+CONFIG_ARM_ARMADA_37XX_CPUFREQ=y
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_ARM_SCPI_CPUFREQ=y
CONFIG_ACPI_CPPC_CPUFREQ=m
--
2.15.1
^ permalink raw reply related
* [PATCH] arm64: rockchip: enable Rockchip IO domain support
From: Heiko Stübner @ 2017-12-15 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215122010.34160-1-klaus.goger@theobroma-systems.com>
Am Freitag, 15. Dezember 2017, 13:20:10 CET schrieb Klaus Goger:
> Make sure the IO domain support is active. This requires to enable
> Adaptive Voltage Scaling class support too.
>
> Without Rockchip IO domain support the internal level shifter on the RK3399
> will be misconfigured if used in the other voltage domain then the default.
>
> Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
>
> ---
>
> arch/arm64/Kconfig.platforms | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 2401373565ff..7c0b0ab12f18 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -150,6 +150,8 @@ config ARCH_ROCKCHIP
> select GPIOLIB
> select PINCTRL
> select PINCTRL_ROCKCHIP
> + select POWER_AVS
> + select ROCKCHIP_IODOMAIN
I'm not sure if we really want this in the default arch Kconfig or if there
are cases where the iodomain driver is not necessary.
On arm32 it just gets selected in the regular defconfig [0]
Heiko
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/configs/multi_v7_defconfig#n452
^ permalink raw reply
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stübner @ 2017-12-15 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uHuwmU1nCcU1MQ9qgGZ0A70ycuoo8XpWcDzgPQFzFRnRA@mail.gmail.com>
Am Freitag, 15. Dezember 2017, 15:42:48 CET schrieb Philippe Ombredanne:
> On Fri, Dec 15, 2017 at 3:28 PM, Heiko St?bner <heiko@sntech.de> wrote:
> > Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
> >> Klaus,
> >>
> >> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
> >>
> >> <klaus.goger@theobroma-systems.com> wrote:
> >> > This patch series replaces all the license text in rockchip devicetree
> >> > files text with a proper SPDX-License-Identifier.
> >> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
> >> > yet merged.
> >> >
> >> > These series also fixes the issue with contradicting statements in most
> >> > licenses. The introduction text claims to be GPL or X11[2] but the
> >> > following verbatim copy of the license is actually a MIT[3] license.
> >> > The X11 license includes a advertise clause and trademark information
> >> > related to the X Consortium. As these X Consortium specfic points are
> >> > irrelevant for us we stick with the actuall license text.
> >> >
> >> > [1] https://patchwork.kernel.org/patch/10091607/
> >> > [2] https://spdx.org/licenses/X11.html
> >> > [3] https://spdx.org/licenses/MIT.html
> >>
> >> FWIW, the X11 license name was not always something clearly defined.
> >> SPDX calls it clearly MIT which is the most widely accepted name for
> >> the corresponding text. And this is also what we have in Thomas doc
> >> patches that should be the kernel reference.
> >>
> >> Also, as a general note, you want to make sure that such as patch set
> >> is not merged by mistake until you have collected an explicit review
> >> or ack from all the copyright holders involved.
> >
> > Just for my understanding, is it really necessary to get Acks from _all_
> > previous contributors?
> >
> > I see that Thomas patches moving license texts into the kernel itself do
> > not seem to have landed yet, but when the actual license text does _not_
> > change and only its location to a common place inside the kernel sources,
> > it feels a bit overkill trying to get Acks from _everybody_ that
> > contributed to Rockchip devicetrees for the last 4 years.
> >
> > If we would actually want to change the license I would definitly feel
> > differently, but the license text does not change.
>
> Well you are technically right. But there is a social and politeness
> angle to this too. So may be getting the ack of all contributors is
> not always needed, but getting it is best and the right to do and at
> least getting for the named copyright holders should be there.
>
> That's only only my take: leaving aside any technical legal issue, say
> I would be on the receiving end as one of the holder or contributors:
> I would find it really great and nice to have my ack requested. And I
> would be a dork not to give it. So I like to do to others the same I
> would appreciate done to me (within reason, as I sometimes shoot
> myself in the foot ;) )
Hehe ... I didn't plan on merging this without ample time for people
to either ACK or NAK the change, so was planning on keeping to social
protocol ;-) . Just the "all" threw me for a loop.
And having that as PATCH without RFC also communicates that people
should take a look, as RFC patches are often overlooked.
As Klaus seems to have included most people that have contributed in the
past, I would guess we should receive any existing complaints about that
change :-) .
So I'll definitly let this simmer for quite a bit and do a best-effort Ack
collection.
Thanks
Heiko
^ permalink raw reply
* [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver
From: Olivier MOYSAN @ 2017-12-15 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214173624.GM9788@sirena.org.uk>
Hello Mark,
Thanks for your comment.
On 12/14/2017 06:36 PM, Mark Brown wrote:
> On Thu, Dec 14, 2017 at 05:53:58PM +0100, Olivier Moysan wrote:
>> When defined in device tree, MCLK1 and MCLK2 are used
>> as sysclk for aif1 and aif2 interfaces respectively.
>
> That's not a valid assumption as far as I remember? The AIFs can use
> either MCLK depending on the system configuration I think.
>
You are right. wm8994 allows to select either MCLK for each AIF.
From this point of view, the current patch is too limiting.
MCLK information in DT allows to enforce MCLK use, but an additionnal
information is required to determine AIF MCLK assignment.
Available properties in codec DAI node, such as clocks property, cannot
help here.
Maybe a DAPM linked to a control is a better way to select AIF source,
When source is not provided by clk_id in wm8994_set_dai_sysclk().
In this case, wm8994_set_dai_sysclk() would only have to check
if clock source is not already set.
Please let me know if this option sounds better to you.
>> If clock rate is let 0, the frequency provided by
>> wm8994_set_dai_sysclk() is used instead.
>
> I'd expect this the other way around, if we didn't specify a frequency
> then read it from the input otherwise try to use clk_set_rate() to
> propagate things up.
>
If I implement a control to select the AIF source, I will drop the code
related to mclk clock provider.
Regards
Olivier
^ permalink raw reply
* [PATCH 1/1] arm: sunxi: Add alternative pins for spi0
From: Maxime Ripard @ 2017-12-15 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f518e4b-e624-17c2-7e72-24ba930a1c15@gmail.com>
Hi,
On Thu, Dec 14, 2017 at 08:24:54AM +0200, Stefan Mavrodiev wrote:
> On 12/13/2017 05:40 PM, Maxime Ripard wrote:
> > Hi,
> >
> > On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote:
> > > Allwinner A10/A13/A20 SoCs have pinmux for spi0
> > > on port C. The patch adds these pins in the respective
> > > dts includes.
> > >
> > > Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
> > Do you have any boards that are using these?
> >
> > We won't merge that patch if there's no users for it.
>
> A20-OLinuXino-Lime/Lime2 and A10-OLinuXino-Lime with spi flash.
> For A13 we still doesn't have that option.
If this bus is exposed on the headers, you can add those to the DT but
leave them disabled if you want. Buf if there's no users of those
nodes, our policy is not to merge them.
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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/09e5ec43/attachment.sig>
^ permalink raw reply
* [v7, 3/3] ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl, imx6q-snvs-lpgpr" node
From: Stefan Wahren @ 2017-12-15 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cfd53377-437a-98d3-1a0e-1123495a35ee@maciej.szmigiero.name>
Hi Maciej,
Am 11.12.2017 um 23:31 schrieb Maciej S. Szmigiero:
> On 20.06.2017 09:09, Oleksij Rempel wrote:
>> This node is for Low Power General Purpose Register which can
>> be used as Non-Volatile Storage.
>>
>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>> ---
>> arch/arm/boot/dts/imx6qdl.dtsi | 4 ++++
>> arch/arm/boot/dts/imx6ul.dtsi | 4 ++++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
>> index e426faa9c243..94e992558238 100644
> (..)
>
> FYI: It looks to me that while the driver itself from this series was
> picked up and eventually reached Linus' tree this DT change was
> forgotten, since I can't find in any tree (or am I not looking at the
> right place?).
thanks for the reminder. It's possible that this patch won't apply
anymore and needs a resend.
>
> Maciej
>
^ permalink raw reply
* [PATCH v3] ARM64: dts: meson-axg: enable IR controller
From: Yixun Lan @ 2017-12-15 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513350088.2261.62.camel@baylibre.com>
Hi Jerome
On 12/15/2017 11:01 PM, Jerome Brunet wrote:
> On Fri, 2017-12-15 at 22:59 +0800, Yixun Lan wrote:
>> Enable IR remote controller which found in Amlogic's Meson-AXG SoCs.
>>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>>
>> ---
>>
>> Changes since v2 at [2]
>> - rebase to Kevin's v4.16/dt64 branch
>> - this patch depend on pinctrl DT driver
>>
>> Changes since v1 at [1]:
>> - drop the compatbile 'amlogic,meson-gx-ir'
>>
>> [2]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005574.html
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005527.html
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 14 ++++++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
>> index 70eca1f8736a..e85fb665f12e 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
>> @@ -20,3 +20,9 @@
>> &uart_AO {
>> status = "okay";
>> };
>> +
>> +&ir {
>> + status = "okay";
>> + pinctrl-0 = <&remote_input_ao_pins>;
>> + pinctrl-names = "default";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index a0d7b10da512..1cd34141a5c1 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -223,6 +223,13 @@
>> #gpio-cells = <2>;
>> gpio-ranges = <&pinctrl_aobus 0 0 15>;
>> };
>> +
>> + remote_input_ao_pins: remote_input_ao {
>> + mux {
>> + groups = "remote_input_ao";
>> + function = "remote_input_ao";
>> + };
>> + };
>> };
>>
>> uart_AO: serial at 3000 {
>> @@ -242,6 +249,13 @@
>> clock-names = "xtal", "pclk", "baud";
>> status = "disabled";
>> };
>> +
>> + ir: ir at 8000 {
>> + compatible = "amlogic,meson-gxbb-ir";
>
> compatible = "amlogic,meson-axg-ir", "amlogic,meson-gxbb-ir";
>
> please (and the binding doc patch)
what's the policy for adding new compatible string?
is this a must even we don't use it for now?
or what's the problem if adding it when we really need it
>
>> + reg = <0x0 0x8000 0x0 0x20>;
>> + interrupts = <GIC_SPI 196 IRQ_TYPE_EDGE_RISING>;
>> + status = "disabled";
>> + };
>> };
>> };
>> };
>
> .
>
^ permalink raw reply
* [PATCH v3] ARM64: dts: meson-axg: enable IR controller
From: Jerome Brunet @ 2017-12-15 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215145906.1494-1-yixun.lan@amlogic.com>
On Fri, 2017-12-15 at 22:59 +0800, Yixun Lan wrote:
> Enable IR remote controller which found in Amlogic's Meson-AXG SoCs.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> ---
>
> Changes since v2 at [2]
> - rebase to Kevin's v4.16/dt64 branch
> - this patch depend on pinctrl DT driver
>
> Changes since v1 at [1]:
> - drop the compatbile 'amlogic,meson-gx-ir'
>
> [2]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005574.html
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005527.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 14 ++++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 70eca1f8736a..e85fb665f12e 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -20,3 +20,9 @@
> &uart_AO {
> status = "okay";
> };
> +
> +&ir {
> + status = "okay";
> + pinctrl-0 = <&remote_input_ao_pins>;
> + pinctrl-names = "default";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index a0d7b10da512..1cd34141a5c1 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -223,6 +223,13 @@
> #gpio-cells = <2>;
> gpio-ranges = <&pinctrl_aobus 0 0 15>;
> };
> +
> + remote_input_ao_pins: remote_input_ao {
> + mux {
> + groups = "remote_input_ao";
> + function = "remote_input_ao";
> + };
> + };
> };
>
> uart_AO: serial at 3000 {
> @@ -242,6 +249,13 @@
> clock-names = "xtal", "pclk", "baud";
> status = "disabled";
> };
> +
> + ir: ir at 8000 {
> + compatible = "amlogic,meson-gxbb-ir";
compatible = "amlogic,meson-axg-ir", "amlogic,meson-gxbb-ir";
please (and the binding doc patch)
> + reg = <0x0 0x8000 0x0 0x20>;
> + interrupts = <GIC_SPI 196 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
> + };
> };
> };
> };
^ permalink raw reply
* [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)
From: Shameerali Kolothum Thodi @ 2017-12-15 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214160957.13716-1-shameerali.kolothum.thodi@huawei.com>
Hi Lorenzo/Robin/Will,
Since this has all the necessary reviewed-by from all concerned now(Thanks to all),
just wondering how this will be picked up? through iort or iommu?
Please let me know.
Thanks,
Shameer
> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Thursday, December 14, 2017 4:10 PM
> To: lorenzo.pieralisi at arm.com; robin.murphy at arm.com;
> marc.zyngier at arm.com; will.deacon at arm.com
> Cc: joro at 8bytes.org; John Garry <john.garry@huawei.com>; xuwei (O)
> <xuwei5@hisilicon.com>; Guohanjun (Hanjun Guo) <guohanjun@huawei.com>;
> iommu at lists.linux-foundation.org; linux-arm-kernel at lists.infradead.org; linux-
> acpi at vger.kernel.org; devicetree at vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>
> Subject: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
>
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
>
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
>
> This patch implements an ACPI based quirk to reserve the hw msi regions
> in the smmu-v3 driver which means these address regions will not be
> translated and will be excluded from iova allocations.
>
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve and reserve
> the associated ITS base address from a device IORT node. The function
> has a check for smmu model to determine whether the platform requires
> the HW MSI reservation or not.
> 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> dts files so that users are warned about the non-DT support for this
> erratum.
>
> Changelog:
>
> v11--> v12
> -Thanks to Lorenzo, Fixed !CONFIG_IOMMU_API compile error(patch #1).
>
> v10 --> v11
> -Addressed comments from Lorenzo(patch#1)
> -Added Robin's Reviewed-by to patch #2
>
> v9 --> v10
> Addressed comments:
> -Moved smmu model check to iort helper function to selectively apply
> the msi reservation which will make the fn call generic from iommu-dma.
> -Removed PCI blacklisting patch, instead added smmu nodes(disabled)
> with comments to hip06/hip07 dts file.
>
> v8 --> v9
> -Thanks to Marc, fixed IORT helper function to reserve the ITS
> translater region only.
> -Removed the DT support for MSI reservation and blacklisted
> HiSilicon PCIe controllers on DT based systems when SMMUv3 is
> enabled.
>
> v7 --> v8
> Addressed comments from Rob and Lorenzo:
> -Modified to use DT compatible string for errata.
> -Changed logic to retrieve the msi-parent for DT case.
>
> v6 --> v7
> Addressed request from Will to add DT support for the erratum:
> - added bt binding
> - add of_iommu_msi_get_resv_regions()
> New arm64 silicon errata entry
> Rename iort_iommu_{its->msi}_get_resv_regions
>
> v5 --> v6
> Addressed comments from Robin and Lorenzo:
> -No change to patch#1 .
> -Reverted v5 patch#2 as this might break the platforms where this quirk
> is not applicable. Provided a generic function in iommu code and added
> back the quirk implementation in SMMU v3 driver(patch#3)
>
> v4 --> v5
> Addressed comments from Robin and Lorenzo:
> -Added a comment to make it clear that, for now, only straightforward
> HW topologies are handled while reserving ITS regions(patch #1).
>
> v3 --> v4
> Rebased on 4.13-rc1.
> Addressed comments from Robin, Will and Lorenzo:
> -As suggested by Robin, moved the ITS msi reservation into
> iommu_dma_get_resv_regions().
> -Added its_count != resv region failure case(patch #1).
>
> v2 --> v3
> Addressed comments from Lorenzo and Robin:
> -Removed dev_is_pci() check in smmuV3 driver.
> -Don't treat device not having an ITS mapping as an error in
> iort helper function.
>
> v1 --> v2
> -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
>
> RFCv2 -->PATCH
> -Incorporated Lorenzo's review comments.
>
> RFC v1 --> RFC v2
> Based on Robin's review comments,
> -Removed the generic erratum framework.
> -Using IORT/MADT tables to retrieve the ITS base addr instead
> of vendor specific CSRT table.
>
> Shameer Kolothum (3):
> ACPI/IORT: Add msi address regions reservation helper
> iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
> arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
>
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 56 ++++++++++++++++
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 25 +++++++
> drivers/acpi/arm64/iort.c | 111 ++++++++++++++++++++++++++++++-
> drivers/iommu/dma-iommu.c | 8 ++-
> drivers/irqchip/irq-gic-v3-its.c | 3 +-
> include/linux/acpi_iort.h | 7 +-
> 6 files changed, 204 insertions(+), 6 deletions(-)
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: marvell: armada-37xx: add nodes allowing cpufreq support
From: Gregory CLEMENT @ 2017-12-15 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214150006.25438-5-gregory.clement@free-electrons.com>
Hi,
On jeu., d?c. 14 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> In order to be able to use cpu freq, we need to associate a clock to each
> CPU and to expose the power management registers.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied on mvebu/dt64
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-372x.dtsi | 1 +
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> index 59d7557d3b1b..2554e0baea6b 100644
> --- a/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> @@ -56,6 +56,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x1>;
> + clocks = <&nb_periph_clk 16>;
> enable-method = "psci";
> };
> };
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index 90c26d616a54..3056d7168e0b 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -65,6 +65,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a53", "arm,armv8";
> reg = <0>;
> + clocks = <&nb_periph_clk 16>;
> enable-method = "psci";
> };
> };
> @@ -234,6 +235,12 @@
> };
> };
>
> + nb_pm: syscon at 14000 {
> + compatible = "marvell,armada-3700-nb-pm",
> + "syscon";
> + reg = <0x14000 0x60>;
> + };
> +
> pinctrl_sb: pinctrl at 18800 {
> compatible = "marvell,armada3710-sb-pinctrl",
> "syscon", "simple-mfd";
> --
> 2.15.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3] ARM64: dts: meson-axg: enable IR controller
From: Yixun Lan @ 2017-12-15 14:59 UTC (permalink / raw)
To: linux-arm-kernel
Enable IR remote controller which found in Amlogic's Meson-AXG SoCs.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
Changes since v2 at [2]
- rebase to Kevin's v4.16/dt64 branch
- this patch depend on pinctrl DT driver
Changes since v1 at [1]:
- drop the compatbile 'amlogic,meson-gx-ir'
[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005574.html
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005527.html
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 14 ++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..e85fb665f12e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -20,3 +20,9 @@
&uart_AO {
status = "okay";
};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index a0d7b10da512..1cd34141a5c1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -223,6 +223,13 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_aobus 0 0 15>;
};
+
+ remote_input_ao_pins: remote_input_ao {
+ mux {
+ groups = "remote_input_ao";
+ function = "remote_input_ao";
+ };
+ };
};
uart_AO: serial at 3000 {
@@ -242,6 +249,13 @@
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
+
+ ir: ir at 8000 {
+ compatible = "amlogic,meson-gxbb-ir";
+ reg = <0x0 0x8000 0x0 0x20>;
+ interrupts = <GIC_SPI 196 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
};
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH] ARM: dts: armada-38x: Add NAND RB pinctrl information
From: Gregory CLEMENT @ 2017-12-15 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171128084902.12134-1-sean.nyekjaer@prevas.dk>
Hi Sean,
On mar., nov. 28 2017, Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:
> Add pin control information for the NAND flash interface.
>
> Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Applied on mvebu/dt
Thanks,
Gregory
> ---
> arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
> index 00ff549d4e39..a6cc568f74f7 100644
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -279,6 +279,11 @@
> marvell,function = "dev";
> };
>
> + nand_rb: nand-rb {
> + marvell,pins = "mpp41";
> + marvell,function = "nand";
> + };
> +
> uart0_pins: uart-pins-0 {
> marvell,pins = "mpp0", "mpp1";
> marvell,function = "ua0";
> --
> 2.15.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper
From: Marc Zyngier @ 2017-12-15 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214160957.13716-2-shameerali.kolothum.thodi@huawei.com>
On Thu, 14 Dec 2017 16:09:55 +0000,
Shameer Kolothum wrote:
>
> On some platforms msi parent address regions have to be excluded from
> normal IOVA allocation in that they are detected and decoded in a HW
> specific way by system components and so they cannot be considered normal
> IOVA address space.
>
> Add a helper function that retrieves ITS address regions - the msi
> parent - through IORT device <-> ITS mappings and reserves it so that
> these regions will not be translated by IOMMU and will be excluded from
> IOVA allocations. The function checks for the smmu model number and
> only applies the msi reservation if the platform requires it.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> drivers/acpi/arm64/iort.c | 111 +++++++++++++++++++++++++++++++++++++--
> drivers/irqchip/irq-gic-v3-its.c | 3 +-
> include/linux/acpi_iort.h | 7 ++-
> 3 files changed, 116 insertions(+), 5 deletions(-)
For the ITS part:
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller
From: Neil Armstrong @ 2017-12-15 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215144217.223593-1-yixun.lan@amlogic.com>
On 15/12/2017 15:42, Yixun Lan wrote:
> From: Sunny Luo <sunny.luo@amlogic.com>
>
> Add DT info for the SPICC controller which found in
> the Amlogic's Meson-AXG SoC.
>
> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> ---
> Changes int v2 since [1]
> - rebase to Kevin's tree, branch v4.16/dt64
> - this patch depend on clock & pinctrl DT patch
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005495.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 93 ++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index d356ce74ad89..d33721005748 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
>
> / {
> compatible = "amlogic,meson-axg";
> @@ -120,6 +121,28 @@
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
>
> + spicc0: spi at 13000 {
> + compatible = "amlogic,meson-axg-spicc";
> + reg = <0x0 0x13000 0x0 0x3c>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc CLKID_SPICC0>;
> + clock-names = "core";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
[...]
> +
> + spi1_ss0_x_pins: spi1_ss0_x {
> + mux {
> + groups = "spi1_ss0_x";
> + function = "spi1";
> + };
> + };
> };
> };
>
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH] ARM: dts: sun7i: Enable HDMI on pcDuino3 Nano
From: Maxime Ripard @ 2017-12-15 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085243.17881-1-tuomas@tuxera.com>
On Fri, Dec 15, 2017 at 10:52:43AM +0200, Tuomas Tynkkynen wrote:
> The board has a regular-sized HDMI connector, so enable the display
> the pipeline and HDMI output for it.
>
> Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/f389b12e/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/3] ARM: sun8i: a83t: Add support for I2S and I2C
From: Maxime Ripard @ 2017-12-15 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214042350.29469-1-wens@csie.org>
On Thu, Dec 14, 2017 at 12:23:47PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v2 of my A83T I2S and I2C support series.
>
> Changes since v1:
>
> - Dropped ASoC patch that was merged
> - Added SoC-specific compatible strings for I2C controllers
> - Added Maxime's Acked-by
>
> This series adds support for I2S and I2C on the Allwinner A83T SoC.
> The I2S controllers are similar to the ones found on the A31. However
> the TX FIFO and interrupt status registers were swapped around. This
> seems to be a recurring theme for the audio related hardware blocks.
>
> Patch 1 adds device nodes and default pinmux settings for the I2S
> controllers.
>
> Patch 2 adds device nodes and default pinmux settings for the I2C
> controllers.
Applied both, 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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/a8650e39/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Philippe Ombredanne @ 2017-12-15 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21020918.S4038j3A1a@diego>
On Fri, Dec 15, 2017 at 3:28 PM, Heiko St?bner <heiko@sntech.de> wrote:
> Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
>> Klaus,
>>
>> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
>>
>> <klaus.goger@theobroma-systems.com> wrote:
>> > This patch series replaces all the license text in rockchip devicetree
>> > files text with a proper SPDX-License-Identifier.
>> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
>> > yet merged.
>> >
>> > These series also fixes the issue with contradicting statements in most
>> > licenses. The introduction text claims to be GPL or X11[2] but the
>> > following verbatim copy of the license is actually a MIT[3] license.
>> > The X11 license includes a advertise clause and trademark information
>> > related to the X Consortium. As these X Consortium specfic points are
>> > irrelevant for us we stick with the actuall license text.
>> >
>> > [1] https://patchwork.kernel.org/patch/10091607/
>> > [2] https://spdx.org/licenses/X11.html
>> > [3] https://spdx.org/licenses/MIT.html
>>
>> FWIW, the X11 license name was not always something clearly defined.
>> SPDX calls it clearly MIT which is the most widely accepted name for
>> the corresponding text. And this is also what we have in Thomas doc
>> patches that should be the kernel reference.
>>
>> Also, as a general note, you want to make sure that such as patch set
>> is not merged by mistake until you have collected an explicit review
>> or ack from all the copyright holders involved.
>
> Just for my understanding, is it really necessary to get Acks from _all_
> previous contributors?
>
> I see that Thomas patches moving license texts into the kernel itself do not
> seem to have landed yet, but when the actual license text does _not_ change
> and only its location to a common place inside the kernel sources, it feels
> a bit overkill trying to get Acks from _everybody_ that contributed to
> Rockchip devicetrees for the last 4 years.
>
> If we would actually want to change the license I would definitly feel
> differently, but the license text does not change.
Well you are technically right. But there is a social and politeness
angle to this too. So may be getting the ack of all contributors is
not always needed, but getting it is best and the right to do and at
least getting for the named copyright holders should be there.
That's only only my take: leaving aside any technical legal issue, say
I would be on the receiving end as one of the holder or contributors:
I would find it really great and nice to have my ack requested. And I
would be a dork not to give it. So I like to do to others the same I
would appreciate done to me (within reason, as I sometimes shoot
myself in the foot ;) )
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller
From: Yixun Lan @ 2017-12-15 14:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Sunny Luo <sunny.luo@amlogic.com>
Add DT info for the SPICC controller which found in
the Amlogic's Meson-AXG SoC.
Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
Changes int v2 since [1]
- rebase to Kevin's tree, branch v4.16/dt64
- this patch depend on clock & pinctrl DT patch
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005495.html
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 93 ++++++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d356ce74ad89..d33721005748 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -120,6 +121,28 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
+ spicc0: spi at 13000 {
+ compatible = "amlogic,meson-axg-spicc";
+ reg = <0x0 0x13000 0x0 0x3c>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc CLKID_SPICC0>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spicc1: spi at 15000 {
+ compatible = "amlogic,meson-axg-spicc";
+ reg = <0x0 0x15000 0x0 0x3c>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc CLKID_SPICC1>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
uart_A: serial at 24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -194,6 +217,76 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+
+ spi0_pins: spi0 {
+ mux {
+ groups = "spi0_miso",
+ "spi0_mosi",
+ "spi0_clk";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss0_pins: spi0_ss0 {
+ mux {
+ groups = "spi0_ss0";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss1_pins: spi0_ss1 {
+ mux {
+ groups = "spi0_ss1";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss2_pins: spi0_ss2 {
+ mux {
+ groups = "spi0_ss2";
+ function = "spi0";
+ };
+ };
+
+
+ spi1_a_pins: spi1_a {
+ mux {
+ groups = "spi1_miso_a",
+ "spi1_mosi_a",
+ "spi1_clk_a";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss0_a_pins: spi1_ss0_a {
+ mux {
+ groups = "spi1_ss0_a";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss1_pins: spi1_ss1 {
+ mux {
+ groups = "spi1_ss1";
+ function = "spi1";
+ };
+ };
+
+ spi1_x_pins: spi1_x {
+ mux {
+ groups = "spi1_miso_x",
+ "spi1_mosi_x",
+ "spi1_clk_x";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss0_x_pins: spi1_ss0_x {
+ mux {
+ groups = "spi1_ss0_x";
+ function = "spi1";
+ };
+ };
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Heiko Stübner @ 2017-12-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213103219.1464-2-enric.balletbo@collabora.com>
Am Mittwoch, 13. Dezember 2017, 11:32:16 CET schrieb Enric Balletbo i Serra:
> Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Just for people reading along, with the extcon driver-patch applied,
Enric sent a slightly fixed devicetree series, so we're moving to the v3
patches and ignoring the v2 dts from this series.
Heiko
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Rafael J. Wysocki @ 2017-12-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215042528.28715-4-d-gerlach@ti.com>
On Fri, Dec 15, 2017 at 5:25 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Document the devicetree bindings that describe Texas Instruments
> opp-supply which allow a platform to describe multiple regulators and
> additional information, such as registers containing data needed to
> program aforementioned regulators.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
I need an ACK from Rob on this one.
> ---
> .../bindings/opp/ti-omap5-opp-supply.txt | 63 ++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
>
> diff --git a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
> new file mode 100644
> index 000000000000..832346e489a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
> @@ -0,0 +1,63 @@
> +Texas Instruments OMAP compatible OPP supply description
> +
> +OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which
> +contain data that can be used to adjust voltages programmed for some of their
> +supplies for more efficient operation. This binding provides the information
> +needed to read these values and use them to program the main regulator during
> +an OPP transitions.
> +
> +Also, some supplies may have an associated vbb-supply which is an Adaptive Body
> +Bias regulator which much be transitioned in a specific sequence with regards
> +to the vdd-supply and clk when making an OPP transition. By supplying two
> +regulators to the device that will undergo OPP transitions we can make use
> +of the multi regulator binding that is part of the OPP core described here [1]
> +to describe both regulators needed by the platform.
> +
> +[1] Documentation/devicetree/bindings/opp/opp.txt
> +
> +Required Properties for Device Node:
> +- vdd-supply: phandle to regulator controlling VDD supply
> +- vbb-supply: phandle to regulator controlling Body Bias supply
> + (Usually Adaptive Body Bias regulator)
> +
> +Required Properties for opp-supply node:
> +- compatible: Should be one of:
> + "ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB
> + "ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD
> + along with VBB
> + "ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD
> + but no VBB.
> +- reg: Address and length of the efuse register set for the device (mandatory
> + only for "ti,omap5-opp-supply")
> +- ti,efuse-settings: An array of u32 tuple items providing information about
> + optimized efuse configuration. Each item consists of the following:
> + volt: voltage in uV - reference voltage (OPP voltage)
> + efuse_offseet: efuse offset from reg where the optimized voltage is stored.
> +- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.
> +
> +Example:
> +
> +/* Device Node (CPU) */
> +cpus {
> + cpu0: cpu at 0 {
> + device_type = "cpu";
> +
> + ...
> +
> + vdd-supply = <&vcc>;
> + vbb-supply = <&abb_mpu>;
> + };
> +};
> +
> +/* OMAP OPP Supply with Class0 registers */
> +opp_supply_mpu: opp_supply at 4a003b20 {
> + compatible = "ti,omap5-opp-supply";
> + reg = <0x4a003b20 0x8>;
> + ti,efuse-settings = <
> + /* uV offset */
> + 1060000 0x0
> + 1160000 0x4
> + 1210000 0x8
> + >;
> + ti,absolute-max-voltage-uv = <1500000>;
> +};
> --
> 2.15.1
>
^ permalink raw reply
* [PATCH 2/2] KVM: arm/arm64: Fix timer enable flow
From: Marc Zyngier @ 2017-12-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-3-christoffer.dall@linaro.org>
On Fri, 15 Dec 2017 14:16:56 +0000,
Christoffer Dall wrote:
>
> When enabling the timer on the first run, we fail to ever restore the
> state and mark it as loaded. That means, that in the initial entry to
> the VCPU ioctl, unless we exit to userspace for some reason such as a
> pending signal, if the guest programs a timer and blocks, we will wait
> forever, because we never read back the hardware state (the loaded flag
> is not set), and so we think the timer is disabled, and we never
> schedule a background soft timer.
>
> The end result? The VCPU blocks forever, and the only solution is to
> kill the thread.
>
> Fixes: 4a2c4da1250d ("arm/arm64: KVM: Load the timer state when enabling the timer")
> Reported-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/arch_timer.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 14c018f990a7..cc29a8148328 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -846,10 +846,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> no_vgic:
> preempt_disable();
> timer->enabled = 1;
> - if (!irqchip_in_kernel(vcpu->kvm))
> - kvm_timer_vcpu_load_user(vcpu);
> - else
> - kvm_timer_vcpu_load_vgic(vcpu);
> + kvm_timer_vcpu_load(vcpu);
> preempt_enable();
>
> return 0;
> --
> 2.14.2
>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ 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