* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-16 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115183508.GJ3096@e104818-lin.cambridge.arm.com>
On 11/15/2016 10:35 AM, Catalin Marinas wrote:
> On Mon, Nov 14, 2016 at 10:41:29AM -0800, Laura Abbott wrote:
>> On 11/14/2016 10:19 AM, Catalin Marinas wrote:
>>> On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
>>>> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
>>>>> On 11/02/2016 04:52 PM, Mark Rutland wrote:
>>>>>> On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
>>>>>>>
>>>>>>> __pa_symbol is technically the marco that should be used for kernel
>>>>>>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
>>>>>>
>>>>>> Nit: s/marco/macro/
>>>>>>
>>>>>> I see there are some other uses of __pa() that look like they could/should be
>>>>>> __pa_symbol(), e.g. in mark_rodata_ro().
>>>>>>
>>>>>> I guess strictly speaking those need to be updated to? Or is there a reason
>>>>>> that we should not?
>>>>>
>>>>> If the concept of __pa_symbol is okay then yes I think all uses of __pa
>>>>> should eventually be converted for consistency and debugging.
>>>>
>>>> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
>>>> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
>>>> for consistency with other architectures.
>>>
>>> At a quick grep, it seems to only be used by mips and x86 and a single
>>> place in mm/memblock.c.
>>>
>>> Since we haven't seen any issues on arm/arm64 without this macro, can we
>>> not just continue to use __pa()?
>>
>> Technically yes but if it's introduced it may be confusing why it's being
>> used some places but not others.
>
> As it currently stands, your patches introduce the first and only use of
> __pa_symbol to arch/arm64. But I don't see the point, unless we replace
> all of the other uses.
>
>> Maybe the bounds in the debug virtual check should just be adjusted so
>> we don't need __pa_symbol along with a nice fat comment explaining
>> why.
>
> I'm fine with __pa_symbol use entirely from under arch/arm64. But if you
> want to use __pa_symbol, I tried to change most (all?) places where
> necessary, together with making virt_to_phys() only deal with the kernel
> linear mapping. Not sure it looks cleaner, especially the
> __va(__pa_symbol()) cases (we could replace the latter with another
> macro and proper comment):
>
I agree everything should be converted over, I was considering doing
that in a separate patch but this covers everything nicely. Are you
okay with me folding this in? (Few comments below)
> -------------8<--------------------------------------
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index a79b969c26fc..fa6c44ebb51f 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -47,7 +47,7 @@
> * If the page is in the bottom half, we have to use the top half. If
> * the page is in the top half, we have to use the bottom half:
> *
> - * T = __virt_to_phys(__hyp_idmap_text_start)
> + * T = __pa_symbol(__hyp_idmap_text_start)
> * if (T & BIT(VA_BITS - 1))
> * HYP_VA_MIN = 0 //idmap in upper half
> * else
> @@ -271,7 +271,7 @@ static inline void __kvm_flush_dcache_pud(pud_t pud)
> kvm_flush_dcache_to_poc(page_address(page), PUD_SIZE);
> }
>
> -#define kvm_virt_to_phys(x) __virt_to_phys((unsigned long)(x))
> +#define kvm_virt_to_phys(x) __pa_symbol((unsigned long)(x))
>
> void kvm_set_way_flush(struct kvm_vcpu *vcpu);
> void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index eac3dbb7e313..e02f45e5ee1b 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -169,15 +169,22 @@ extern u64 kimage_voffset;
> */
> #define __virt_to_phys_nodebug(x) ({ \
> phys_addr_t __x = (phys_addr_t)(x); \
> - __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
> - (__x - kimage_voffset); })
> + VM_BUG_ON(!(__x & BIT(VA_BITS - 1))); \
> + ((__x & ~PAGE_OFFSET) + PHYS_OFFSET); \
> +})
I do think this is easier to understand vs the ternary operator.
I'll add a comment detailing the use of __pa vs __pa_symbol somewhere
as well.
> +
> +#define __pa_symbol_nodebug(x) ({ \
> + phys_addr_t __x = (phys_addr_t)(x); \
> + VM_BUG_ON(__x & BIT(VA_BITS - 1)); \
> + (__x - kimage_voffset); \
> +})
>
> #ifdef CONFIG_DEBUG_VIRTUAL
> extern unsigned long __virt_to_phys(unsigned long x);
> extern unsigned long __phys_addr_symbol(unsigned long x);
> #else
> #define __virt_to_phys(x) __virt_to_phys_nodebug(x)
> -#define __phys_addr_symbol __pa
> +#define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
> #endif
>
> #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
> @@ -210,7 +217,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> * Drivers should NOT use these either.
> */
> #define __pa(x) __virt_to_phys((unsigned long)(x))
> -#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
> +#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
> #define __pa_nodebug(x) __virt_to_phys_nodebug((unsigned long)(x))
> #define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
> #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index a50185375f09..6cf3763c6e11 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -44,7 +44,7 @@ static inline void contextidr_thread_switch(struct task_struct *next)
> */
> static inline void cpu_set_reserved_ttbr0(void)
> {
> - unsigned long ttbr = virt_to_phys(empty_zero_page);
> + unsigned long ttbr = __pa_symbol(empty_zero_page);
>
> write_sysreg(ttbr, ttbr0_el1);
> isb();
> @@ -113,7 +113,7 @@ static inline void cpu_install_idmap(void)
> local_flush_tlb_all();
> cpu_set_idmap_tcr_t0sz();
>
> - cpu_switch_mm(idmap_pg_dir, &init_mm);
> + cpu_switch_mm(__va(__pa_symbol(idmap_pg_dir)), &init_mm);
Yes, the __va(__pa_symbol(..)) idiom needs to be macroized and commented...
> }
>
> /*
> @@ -128,7 +128,7 @@ static inline void cpu_replace_ttbr1(pgd_t *pgd)
>
> phys_addr_t pgd_phys = virt_to_phys(pgd);
>
> - replace_phys = (void *)virt_to_phys(idmap_cpu_replace_ttbr1);
> + replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
>
> cpu_install_idmap();
> replace_phys(pgd_phys);
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index ffbb9a520563..c2041a39a3e3 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -52,7 +52,7 @@ extern void __pgd_error(const char *file, int line, unsigned long val);
> * for zero-mapped memory areas etc..
> */
> extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
> -#define ZERO_PAGE(vaddr) pfn_to_page(PHYS_PFN(__pa(empty_zero_page)))
> +#define ZERO_PAGE(vaddr) pfn_to_page(PHYS_PFN(__pa_symbol(empty_zero_page)))
>
> #define pte_ERROR(pte) __pte_error(__FILE__, __LINE__, pte_val(pte))
>
> diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
> index a32b4011d711..df58310660c6 100644
> --- a/arch/arm64/kernel/acpi_parking_protocol.c
> +++ b/arch/arm64/kernel/acpi_parking_protocol.c
> @@ -109,7 +109,7 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
> * that read this address need to convert this address to the
> * Boot-Loader's endianness before jumping.
> */
> - writeq_relaxed(__pa(secondary_entry), &mailbox->entry_point);
> + writeq_relaxed(__pa_symbol(secondary_entry), &mailbox->entry_point);
> writel_relaxed(cpu_entry->gic_cpu_id, &mailbox->cpu_id);
>
> arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c02504ea304b..6ccadf255fba 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -736,7 +736,7 @@ static bool runs_at_el2(const struct arm64_cpu_capabilities *entry, int __unused
> static bool hyp_offset_low(const struct arm64_cpu_capabilities *entry,
> int __unused)
> {
> - phys_addr_t idmap_addr = virt_to_phys(__hyp_idmap_text_start);
> + phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start);
>
> /*
> * Activate the lower HYP offset only if:
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index d55a7b09959b..81c03c74e5fe 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -51,7 +51,7 @@
> extern int in_suspend;
>
> /* Find a symbols alias in the linear map */
> -#define LMADDR(x) phys_to_virt(virt_to_phys(x))
> +#define LMADDR(x) __va(__pa_symbol(x))
...Perhaps just borrowing this macro?
>
> /* Do we need to reset el2? */
> #define el2_reset_needed() (is_hyp_mode_available() && !is_kernel_in_hyp_mode())
> @@ -125,12 +125,12 @@ int arch_hibernation_header_save(void *addr, unsigned int max_size)
> return -EOVERFLOW;
>
> arch_hdr_invariants(&hdr->invariants);
> - hdr->ttbr1_el1 = virt_to_phys(swapper_pg_dir);
> + hdr->ttbr1_el1 = __pa_symbol(swapper_pg_dir);
> hdr->reenter_kernel = _cpu_resume;
>
> /* We can't use __hyp_get_vectors() because kvm may still be loaded */
> if (el2_reset_needed())
> - hdr->__hyp_stub_vectors = virt_to_phys(__hyp_stub_vectors);
> + hdr->__hyp_stub_vectors = __pa_symbol(__hyp_stub_vectors);
> else
> hdr->__hyp_stub_vectors = 0;
>
> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
> index 6f2ac4fc66ca..af8967a0343b 100644
> --- a/arch/arm64/kernel/insn.c
> +++ b/arch/arm64/kernel/insn.c
> @@ -97,7 +97,7 @@ static void __kprobes *patch_map(void *addr, int fixmap)
> if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
> page = vmalloc_to_page(addr);
> else if (!module)
> - page = pfn_to_page(PHYS_PFN(__pa(addr)));
> + page = pfn_to_page(PHYS_PFN(__pa_symbol(addr)));
> else
> return addr;
>
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 42816bebb1e0..f0f2abb72cf9 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -45,7 +45,7 @@ static int __init cpu_psci_cpu_prepare(unsigned int cpu)
>
> static int cpu_psci_cpu_boot(unsigned int cpu)
> {
> - int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa(secondary_entry));
> + int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa_symbol(secondary_entry));
> if (err)
> pr_err("failed to boot CPU%d (%d)\n", cpu, err);
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index f534f492a268..e2dbc02f4792 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -199,10 +199,10 @@ static void __init request_standard_resources(void)
> struct memblock_region *region;
> struct resource *res;
>
> - kernel_code.start = virt_to_phys(_text);
> - kernel_code.end = virt_to_phys(__init_begin - 1);
> - kernel_data.start = virt_to_phys(_sdata);
> - kernel_data.end = virt_to_phys(_end - 1);
> + kernel_code.start = __pa_symbol(_text);
> + kernel_code.end = __pa_symbol(__init_begin - 1);
> + kernel_data.start = __pa_symbol(_sdata);
> + kernel_data.end = __pa_symbol(_end - 1);
>
> for_each_memblock(memory, region) {
> res = alloc_bootmem_low(sizeof(*res));
> diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
> index 9a00eee9acc8..25fcccaf79b8 100644
> --- a/arch/arm64/kernel/smp_spin_table.c
> +++ b/arch/arm64/kernel/smp_spin_table.c
> @@ -98,7 +98,7 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
> * boot-loader's endianess before jumping. This is mandated by
> * the boot protocol.
> */
> - writeq_relaxed(__pa(secondary_holding_pen), release_addr);
> + writeq_relaxed(__pa_symbol(secondary_holding_pen), release_addr);
> __flush_dcache_area((__force void *)release_addr,
> sizeof(*release_addr));
>
> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index a2c2478e7d78..791e87a99148 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -140,11 +140,11 @@ static int __init vdso_init(void)
> return -ENOMEM;
>
> /* Grab the vDSO data page. */
> - vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa(vdso_data)));
> + vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa_symbol(vdso_data)));
>
> /* Grab the vDSO code pages. */
> for (i = 0; i < vdso_pages; i++)
> - vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa(&vdso_start)) + i);
> + vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa_symbol(&vdso_start)) + i);
>
> vdso_spec[0].pages = &vdso_pagelist[0];
> vdso_spec[1].pages = &vdso_pagelist[1];
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3236eb062444..14f426fea61b 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -225,7 +225,7 @@ void __init arm64_memblock_init(void)
> */
> if (memory_limit != (phys_addr_t)ULLONG_MAX) {
> memblock_mem_limit_remove_map(memory_limit);
> - memblock_add(__pa(_text), (u64)(_end - _text));
> + memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> @@ -278,7 +278,7 @@ void __init arm64_memblock_init(void)
> * Register the kernel text, kernel data, initrd, and initial
> * pagetables with memblock.
> */
> - memblock_reserve(__pa(_text), _end - _text);
> + memblock_reserve(__pa_symbol(_text), _end - _text);
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> memblock_reserve(initrd_start, initrd_end - initrd_start);
> @@ -483,7 +483,8 @@ void __init mem_init(void)
>
> void free_initmem(void)
> {
> - free_reserved_area(__va(__pa(__init_begin)), __va(__pa(__init_end)),
> + free_reserved_area(__va(__pa_symbol(__init_begin)),
> + __va(__pa_symbol(__init_end)),
> 0, "unused kernel");
> /*
> * Unmap the __init region but leave the VM area in place. This
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 17243e43184e..f7c0a47a8ebd 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -359,8 +359,8 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
>
> static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
> {
> - unsigned long kernel_start = __pa(_text);
> - unsigned long kernel_end = __pa(__init_begin);
> + unsigned long kernel_start = __pa_symbol(_text);
> + unsigned long kernel_end = __pa_symbol(__init_begin);
>
> /*
> * Take care not to create a writable alias for the
> @@ -427,14 +427,14 @@ void mark_rodata_ro(void)
> unsigned long section_size;
>
> section_size = (unsigned long)_etext - (unsigned long)_text;
> - create_mapping_late(__pa(_text), (unsigned long)_text,
> + create_mapping_late(__pa_symbol(_text), (unsigned long)_text,
> section_size, PAGE_KERNEL_ROX);
> /*
> * mark .rodata as read only. Use __init_begin rather than __end_rodata
> * to cover NOTES and EXCEPTION_TABLE.
> */
> section_size = (unsigned long)__init_begin - (unsigned long)__start_rodata;
> - create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> + create_mapping_late(__pa_symbol(__start_rodata), (unsigned long)__start_rodata,
> section_size, PAGE_KERNEL_RO);
>
> /* flush the TLBs after updating live kernel mappings */
> @@ -446,7 +446,7 @@ void mark_rodata_ro(void)
> static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
> pgprot_t prot, struct vm_struct *vma)
> {
> - phys_addr_t pa_start = __pa(va_start);
> + phys_addr_t pa_start = __pa_symbol(va_start);
> unsigned long size = va_end - va_start;
>
> BUG_ON(!PAGE_ALIGNED(pa_start));
> @@ -494,7 +494,7 @@ static void __init map_kernel(pgd_t *pgd)
> */
> BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
> set_pud(pud_set_fixmap_offset(pgd, FIXADDR_START),
> - __pud(__pa(bm_pmd) | PUD_TYPE_TABLE));
> + __pud(__pa_symbol(bm_pmd) | PUD_TYPE_TABLE));
> pud_clear_fixmap();
> } else {
> BUG();
> @@ -525,7 +525,7 @@ void __init paging_init(void)
> */
> cpu_replace_ttbr1(__va(pgd_phys));
> memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
> - cpu_replace_ttbr1(swapper_pg_dir);
> + cpu_replace_ttbr1(__va(__pa_symbol(swapper_pg_dir)));
>
> pgd_clear_fixmap();
> memblock_free(pgd_phys, PAGE_SIZE);
> @@ -534,7 +534,7 @@ void __init paging_init(void)
> * We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
> * allocated with it.
> */
> - memblock_free(__pa(swapper_pg_dir) + PAGE_SIZE,
> + memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
> SWAPPER_DIR_SIZE - PAGE_SIZE);
> }
>
> @@ -654,7 +654,7 @@ void __init early_fixmap_init(void)
>
> pgd = pgd_offset_k(addr);
> if (CONFIG_PGTABLE_LEVELS > 3 &&
> - !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
> + !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
> /*
> * We only end up here if the kernel mapping and the fixmap
> * share the top level pgd entry, which should only happen on
> @@ -663,12 +663,12 @@ void __init early_fixmap_init(void)
> BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
> pud = pud_offset_kimg(pgd, addr);
> } else {
> - pgd_populate(&init_mm, pgd, bm_pud);
> + pgd_populate(&init_mm, pgd, __va(__pa_symbol(bm_pud)));
> pud = fixmap_pud(addr);
> }
> - pud_populate(&init_mm, pud, bm_pmd);
> + pud_populate(&init_mm, pud, __va(__pa_symbol(bm_pmd)));
> pmd = fixmap_pmd(addr);
> - pmd_populate_kernel(&init_mm, pmd, bm_pte);
> + pmd_populate_kernel(&init_mm, pmd, __va(__pa_symbol(bm_pte)));
>
> /*
> * The boot-ioremap range spans multiple pmds, for which
> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
> index 874c78201a2b..98dae943e496 100644
> --- a/arch/arm64/mm/physaddr.c
> +++ b/arch/arm64/mm/physaddr.c
> @@ -14,8 +14,8 @@ unsigned long __virt_to_phys(unsigned long x)
> */
> return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
> } else {
> - VIRTUAL_BUG_ON(x < kimage_vaddr || x >= (unsigned long)_end);
> - return (__x - kimage_voffset);
> + WARN_ON(1);
Was the deletion of the BUG_ON here intentional? VIRTUAL_BUG_ON
is the check enabled by CONFIG_DEBUG_VIRTUAL vs just CONFIG_DEBUG_VM.
I intentionally kept CONFIG_DEBUG_VIRTUAL separate since the checks
are expensive.
> + return __phys_addr_symbol(x);
> }
> }
> EXPORT_SYMBOL(__virt_to_phys);
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index 8263429e21b8..9defbe243c2f 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -383,7 +383,7 @@ static int psci_suspend_finisher(unsigned long index)
> u32 *state = __this_cpu_read(psci_power_state);
>
> return psci_ops.cpu_suspend(state[index - 1],
> - virt_to_phys(cpu_resume));
> + __pa_symbol(cpu_resume));
> }
>
> int psci_cpu_suspend_enter(unsigned long index)
>
Thanks,
Laura
^ permalink raw reply
* [PATCH] drm/bridge: analogix_dp: return error if transfer none byte
From: Jianqun Xu @ 2016-11-16 0:13 UTC (permalink / raw)
To: linux-arm-kernel
Reference from drm_dp_aux description (about transfer):
Upon success, the implementation should return the number of payload bytes
that were transferred, or a negative error-code on failure. Helpers
propagate errors from the .transfer() function, with the exception of
the -EBUSY error, which causes a transaction to be retried. On a short,
helpers will return -EPROTO to make it simpler to check for failure.
The analogix_dp_transfer will return num_transferred, but if there is none
byte been transferred, the return value will be 0, which means success, we
should return error-code if transfer none byte.
for (retry = 0; retry < 32; retry++) {
err = aux->transfer(aux, &msg);
if (err < 0) {
if (err == -EBUSY)
continue;
goto unlock;
}
}
Cc: zain wang <wzz@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index cd37ac0..303083a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
(msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ)
msg->reply = DP_AUX_NATIVE_REPLY_ACK;
- return num_transferred;
+ return num_transferred > 0 ? num_transferred : -EBUSY;
}
--
1.9.1
^ permalink raw reply related
* [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Rob Herring @ 2016-11-16 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
On Mon, Nov 14, 2016 at 10:44:11AM +0100, Neil Armstrong wrote:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.txt | 6 +
> arch/arm64/boot/dts/amlogic/Makefile | 2 +
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 76 +++++++++
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 57 +++++++
> .../boot/dts/amlogic/meson-gxm-s912-q20x.dtsi | 188 +++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 114 +++++++++++++
> 6 files changed, 443 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q20x.dtsi
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] clk: rockchip: rk3399: fix copy-paste error
From: Jianqun Xu @ 2016-11-16 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479254835-6858-1-git-send-email-jay.xu@rock-chips.com>
Fix RK3368_* to RK3399_* for rk3399 clk_test clock.
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index 2c7cba7..ccbf558b 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -1382,8 +1382,8 @@ static struct rockchip_clk_branch rk3399_clk_branches[] __initdata = {
/* clk_test */
/* clk_test_pre is controlled by CRU_MISC_CON[3] */
COMPOSITE_NOMUX(0, "clk_test", "clk_test_pre", CLK_IGNORE_UNUSED,
- RK3368_CLKSEL_CON(58), 0, 5, DFLAGS,
- RK3368_CLKGATE_CON(13), 11, GFLAGS),
+ RK3399_CLKSEL_CON(58), 0, 5, DFLAGS,
+ RK3399_CLKGATE_CON(13), 11, GFLAGS),
/* ddrc */
GATE(0, "clk_ddrc_lpll_src", "lpll", 0, RK3399_CLKGATE_CON(3),
--
1.9.1
^ permalink raw reply related
* specifying order of /dev/mmcblk devices via device-tree?
From: Fabio Estevam @ 2016-11-16 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115235503.GC1041@n2100.armlinux.org.uk>
[Adding Masahiro and Michael]
On Tue, Nov 15, 2016 at 9:55 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
>> > On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
>> > <linux@armlinux.org.uk> wrote:
>> > > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
>> > >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
>> > >> <linux@armlinux.org.uk> wrote:
>> > >> > So, someone merged a patch which makes mmcblk devices follow the
>> > >> > host controller numbering.
>> > >> >
>> > >> > Now my cubox-i fails to boot correctly because the SD card in the
>> > >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
>> > >> >
>> > >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
>> > >> > remotely near a SD card or eMMC present. So, this change is
>> > >> > confusing on these platforms.
>> > >> >
>> > >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
>> > >> > their kernels.
>> > >> >
>> > >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
>> > >> >
>> > >> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
>> > >> > please revert whatever change caused this, and next time limit it
>> > >> > to only eMMC.
>> > >> >
>> > >> > Thanks.
>> > >>
>> > >> I see the same thing on newer kernels, which is why I asked the
>> > >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
>> > >> device and was looking for a way to control that via dt. Now I'm
>> > >> understanding that to avoid this kind of bootloader/kernel dependence
>> > >> issue I should be using UUID's to identify the boot device.
>> > >>
>> > >> >From my testing it looks like the change your looking for occurred
>> > >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
>> > >> regression specifically.
>> > >
>> > > That depends how you look at it. Yes, there's a change in 4.5 to 4.6
>> > > which ties the block device number to the host device index, but that's
>> > > really only part of the story here.
>> > >
>> > > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
>> > > 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
>> > > of behaviour - there can be no argument about that.
>> > >
>> > > Now, digging further into this today, it appears that:
>> > >
>> > > v4.8: usdhc2 was probed first, and is given mmc0.
>> > > usdhc1 is probed second, and is given mmc1.
>> > >
>> > > v4.9-rc: usdhc1 is probed first, and is given mmc0.
>> > > usdhc2 is probed second, and is given mmc1.
>> > >
>> > > I haven't yet been able to figure out why there's been this change
>> > > of probe order. There's no change that I can see in the iMX6 DT
>> > > files that would account for this.
>> > >
>> >
>> > I bisected it and the commit your looking for is
>> > 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
>>
>> No it's not.
>>
>> Let me try and put it plainer:
>>
>> * Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
>> device number (mmcblkN) to the mmc host interface number (mmcN).
>> This change happened between 4.5 and 4.6.
>>
>> * The change I'm seeing happened between 4.8 and 4.9-rc. I'm not
>> seeing a change of behaviour between 4.5 and 4.6.
>>
>> * The change I'm seeing changes the order of the physical device
>> associated with the hosts named mmc0 and mmc1 in the kernel.
>>
>> * Because physical devices associated with the mmc0 and mmc1 hosts
>> swap over, the mmcblkN number changes due to the commit you point
>> out.
>>
>> * So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
>> by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
>> else changing the order in which the two usdhc physical hardware
>> blocks get probed.
>>
>> Does this make it clearer?
>
> It turns out to be this commit:
>
> commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
> Author: Masahiro Yamada <yamada.masahiro@socionext.com>
> Date: Mon Sep 19 01:16:44 2016 +0900
>
> clk: probe common clock drivers earlier
>
> Several SoCs implement platform drivers for clocks rather than
> CLK_OF_DECLARE(). Clocks should come earlier because they are
> prerequisites for many of other drivers. It will help to mitigate
> EPROBE_DEFER issues.
>
> Also, drop the comment since it does not carry much value.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Acked-by: Michael Turquette <mturquette@baylibre.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> which changes the init order. In 4.8, we get:
>
> calling mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
> bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
> platform usdhc1_pwrseq: Driver pwrseq_simple requests probe deferral
> platform usdhc1_pwrseq: Added to deferred list
> initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 737 usecs
>
> which then goes on to cause:
>
> calling sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
> platform 2190000.usdhc: Driver sdhci-esdhc-imx requests probe deferral
> platform 2190000.usdhc: Added to deferred list
>
> followed by:
>
> bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
> sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
> bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
> initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 58205 usecs
>
> and eventually:
>
> mmc0: host does not support reading read-only switch, assuming write-enable
> mmc0: new ultra high speed SDR104 SDHC card at address 0001
> mmcblk0: mmc0:0001 00000 14.9 GiB
> mmcblk0: p1 p2
>
> In 4.9-rc5, we instead get:
>
> calling gpio_clk_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device sdio-clock with driver gpio-clk
> bus: 'platform': really_probe: probing driver gpio-clk with device sdio-clock
> driver: 'gpio-clk': driver_bound: bound to device 'sdio-clock'
> bus: 'platform': really_probe: bound device sdio-clock to driver gpio-clk
> ...
> calling mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
> bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
> driver: 'pwrseq_simple': driver_bound: bound to device 'usdhc1_pwrseq'
> bus: 'platform': really_probe: bound device usdhc1_pwrseq to driver pwrseq_simple
> initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 876 usecs
> ...
> calling sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
> sdhci-esdhc-imx 2190000.usdhc: allocated mmc-pwrseq
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2190000.usdhc'
> bus: 'platform': really_probe: bound device 2190000.usdhc to driver sdhci-esdhc-imx
> bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
> bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
> initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 384864 usecs
> ...
> mmc1: host does not support reading read-only switch, assuming write-enable
> mmc1: new ultra high speed SDR104 SDHC card at address 0001
> mmcblk1: mmc1:0001 00000 14.9 GiB
> mmcblk1: p1 p2
>
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure
From: Rafael J. Wysocki @ 2016-11-16 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-8-lorenzo.pieralisi@arm.com>
On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On DT based systems, the of_dma_configure() API implements DMA
> configuration for a given device. On ACPI systems an API equivalent to
> of_dma_configure() is missing which implies that it is currently not
> possible to set-up DMA operations for devices through the ACPI generic
> kernel layer.
>
> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
> calls that for now are just wrappers around arch_setup_dma_ops() and
> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>
> Since acpi_dma_configure() is used to configure DMA operations, the
> function initializes the dma/coherent_dma masks to sane default values
> if the current masks are uninitialized (also to keep the default values
> consistent with DT systems) to make sure the device has a complete
> default DMA set-up.
>
> The DMA range size passed to arch_setup_dma_ops() is sized according
> to the device coherent_dma_mask (starting at address 0x0), mirroring the
> DT probing path behaviour when a dma-ranges property is not provided
> for the device being probed; this changes the current arch_setup_dma_ops()
> call parameters in the ACPI probing case, but since arch_setup_dma_ops()
> is a NOP on all architectures but ARM/ARM64 this patch does not change
> the current kernel behaviour on them.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci]
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
LGTM
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
^ permalink raw reply
* [PATCH v7 16/16] drivers: acpi: iort: introduce iort_iommu_configure
From: Rafael J. Wysocki @ 2016-11-16 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-17-lorenzo.pieralisi@arm.com>
On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> DT based systems have a generic kernel API to configure IOMMUs
> for devices (ie of_iommu_configure()).
>
> On ARM based ACPI systems, the of_iommu_configure() equivalent can
> be implemented atop ACPI IORT kernel API, with the corresponding
> functions to map device identifiers to IOMMUs and retrieve the
> corresponding IOMMU operations necessary for DMA operations set-up.
>
> By relying on the iommu_fwspec generic kernel infrastructure,
> implement the IORT based IOMMU configuration for ARM ACPI systems
> and hook it up in the ACPI kernel layer that implements DMA
> configuration for a device.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
For the ACPI core part:
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
^ permalink raw reply
* [PATCH v3 0/3] Remove clocks dependency from SCM driver
From: Sarangdhar Joshi @ 2016-11-16 1:19 UTC (permalink / raw)
To: linux-arm-kernel
On earlier chiptsets (APQ8064, MSM8660, MSM8690, MSM8916,
APQ8084, MSM8974) crypto operations of TZ were depends on crypto
clocks controlled by users/clients. However on MSM8996 crypto clocks
control is handled internally in TZ itself. The current series of
patches handle this clock dependency in SCM driver.
Changes since v2:
- Use typecast of 'unsigned long' for pointer (Stephen)
Changes since v1:
- Added Rob's Acked-by
- Removed of_device_is_compatible check from probe (Stephen)
- Modified typecast to take care of 32-bit pointer
Sarangdhar Joshi (3):
dt-bindings: firmware: scm: Add MSM8996 DT bindings
firmware: qcom: scm: Remove core, iface and bus clocks dependency
firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails
.../devicetree/bindings/firmware/qcom,scm.txt | 2 +
drivers/firmware/qcom_scm.c | 49 ++++++++++++++++------
2 files changed, 39 insertions(+), 12 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Sarangdhar Joshi @ 2016-11-16 1:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479259165-1601-1-git-send-email-spjoshi@codeaurora.org>
Add SCM DT bindings for Qualcomm's MSM8996 platform.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
Documentation/devicetree/bindings/firmware/qcom,scm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 3b4436e..20f26fb 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -10,8 +10,10 @@ Required properties:
* "qcom,scm-apq8064" for APQ8064 platforms
* "qcom,scm-msm8660" for MSM8660 platforms
* "qcom,scm-msm8690" for MSM8690 platforms
+ * "qcom,scm-msm8996" for MSM8996 platforms
* "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
- clocks: One to three clocks may be required based on compatible.
+ * No clock required for "qcom,scm-msm8996"
* Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
* Core, iface, and bus clocks required for "qcom,scm"
- clock-names: Must contain "core" for the core clock, "iface" for the interface
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v15 01/13] clocksource/drivers/arm_arch_timer: Move enums and defines to header file
From: Fu Wei @ 2016-11-16 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201611160359.fuY2etTU%fengguang.wu@intel.com>
Hi Marc,
On 16 November 2016 at 03:23, kbuild test robot <lkp@intel.com> wrote:
> Hi Fu,
>
> [auto build test ERROR on tip/timers/core]
> [also build test ERROR on v4.9-rc5 next-20161115]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/fu-wei-linaro-org/acpi-clocksource-add-GTDT-driver-and-GTDT-support-in-arm_arch_timer/20161116-004444
> config: arm-hisi_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> Note: the linux-review/fu-wei-linaro-org/acpi-clocksource-add-GTDT-driver-and-GTDT-support-in-arm_arch_timer/20161116-004444 HEAD 47004b0566d2fd65c05836078319b02c5af2a1fc builds fine.
> It only hurts bisectibility.
>
> All error/warnings (new ones prefixed by >>):
>
>>> drivers/clocksource/arm_arch_timer.c:70:13: error: variable 'arch_timer_uses_ppi' has initializer but incomplete type
> static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
I have figured out this, I should move a change from patch 4/15 to
here to avoid the problem.
it should be static enum arch_timer_ppi_nr arch_timer_uses_ppi = VIRT_PPI;
will improve this
Thanks
> ^~~~~~
> drivers/clocksource/arm_arch_timer.c: In function '__arch_timer_setup':
>>> drivers/clocksource/arm_arch_timer.c:358:3: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> clk->irq = arch_timer_ppi[arch_timer_uses_ppi];
> ^~~
> drivers/clocksource/arm_arch_timer.c:359:3: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> switch (arch_timer_uses_ppi) {
> ^~~~~~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_has_nonsecure_ppi':
> drivers/clocksource/arm_arch_timer.c:447:2: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> return (arch_timer_uses_ppi == PHYS_SECURE_PPI &&
> ^~~~~~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_starting_cpu':
> drivers/clocksource/arm_arch_timer.c:471:2: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> flags = check_ppi_trigger(arch_timer_ppi[arch_timer_uses_ppi]);
> ^~~~~
> drivers/clocksource/arm_arch_timer.c:472:2: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> enable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], flags);
> ^~~~~~~~~~~~~~~~~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_banner':
> drivers/clocksource/arm_arch_timer.c:512:2: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
> ^~~~~~~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_counter_register':
> drivers/clocksource/arm_arch_timer.c:589:3: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
> ^~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_stop':
> drivers/clocksource/arm_arch_timer.c:624:2: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> disable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi]);
> ^~~~~~~~~~~~~~~~~~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_register':
> drivers/clocksource/arm_arch_timer.c:687:2: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> ppi = arch_timer_ppi[arch_timer_uses_ppi];
> ^~~
> drivers/clocksource/arm_arch_timer.c:688:2: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> switch (arch_timer_uses_ppi) {
> ^~~~~~
> drivers/clocksource/arm_arch_timer.c:737:2: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> free_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], arch_timer_evt);
> ^~~~~~~~~~~~~~~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_init':
> drivers/clocksource/arm_arch_timer.c:838:4: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> arch_timer_uses_ppi = HYP_PPI;
> ^~~~~~~~~~~~~~~~~~~
> drivers/clocksource/arm_arch_timer.c:841:4: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> arch_timer_uses_ppi = PHYS_SECURE_PPI;
> ^~~~~~~~~~~~~~~~~~~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_of_init':
> drivers/clocksource/arm_arch_timer.c:897:3: error: 'arch_timer_uses_ppi' has an incomplete type 'enum ppi_nr'
> arch_timer_uses_ppi = PHYS_SECURE_PPI;
> ^~~~~~~~~~~~~~~~~~~
> drivers/clocksource/arm_arch_timer.c: At top level:
>>> drivers/clocksource/arm_arch_timer.c:70:20: error: storage size of 'arch_timer_uses_ppi' isn't known
> static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
> ^~~~~~~~~~~~~~~~~~~
> drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_has_nonsecure_ppi':
>>> drivers/clocksource/arm_arch_timer.c:449:1: warning: control reaches end of non-void function [-Wreturn-type]
> }
> ^
>
> vim +/arch_timer_uses_ppi +70 drivers/clocksource/arm_arch_timer.c
>
> 220069945 Stephen Boyd 2013-07-18 64
> 8a4da6e36 Mark Rutland 2012-11-12 65 static u32 arch_timer_rate;
> 8a4da6e36 Mark Rutland 2012-11-12 66 static int arch_timer_ppi[MAX_TIMER_PPI];
> 8a4da6e36 Mark Rutland 2012-11-12 67
> 8a4da6e36 Mark Rutland 2012-11-12 68 static struct clock_event_device __percpu *arch_timer_evt;
> 8a4da6e36 Mark Rutland 2012-11-12 69
> f81f03fa2 Marc Zyngier 2014-02-20 @70 static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
> 82a561941 Lorenzo Pieralisi 2014-04-08 71 static bool arch_timer_c3stop;
> 220069945 Stephen Boyd 2013-07-18 72 static bool arch_timer_mem_use_virtual;
> 8a4da6e36 Mark Rutland 2012-11-12 73
>
> :::::: The code at line 70 was first introduced by commit
> :::::: f81f03fa231a8c3aacd580759e73b9238b92ba29 arm64: Allow the arch timer to use the HYP timer
>
> :::::: TO: Marc Zyngier <marc.zyngier@arm.com>
> :::::: CC: Marc Zyngier <marc.zyngier@arm.com>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH 1/2] ahci: qoriq: added a condition to enable dma coherence
From: yuantian.tang at nxp.com @ 2016-11-16 3:11 UTC (permalink / raw)
To: linux-arm-kernel
From: Tang Yuantian <Yuantian.Tang@nxp.com>
Enable DMA coherence in SATA controller on condition that
dma-coherent property exists in sata node in DTS.
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
drivers/ata/ahci_qoriq.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 9884c8c..45c88de 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -59,6 +59,7 @@ struct ahci_qoriq_priv {
struct ccsr_ahci *reg_base;
enum ahci_qoriq_type type;
void __iomem *ecc_addr;
+ bool is_dmacoherent;
};
static const struct of_device_id ahci_qoriq_of_match[] = {
@@ -164,26 +165,31 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
writel(LS1021A_PORT_PHY4, reg_base + PORT_PHY4);
writel(LS1021A_PORT_PHY5, reg_base + PORT_PHY5);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
- writel(AHCI_PORT_AXICC_CFG, reg_base + LS1021A_AXICC_ADDR);
+ if (qpriv->is_dmacoherent)
+ writel(AHCI_PORT_AXICC_CFG,
+ reg_base + LS1021A_AXICC_ADDR);
break;
case AHCI_LS1043A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
- writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+ if (qpriv->is_dmacoherent)
+ writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
case AHCI_LS2080A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
- writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+ if (qpriv->is_dmacoherent)
+ writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
case AHCI_LS1046A:
writel(LS1046A_SATA_ECC_DIS, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
- writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+ if (qpriv->is_dmacoherent)
+ writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
}
@@ -221,6 +227,7 @@ static int ahci_qoriq_probe(struct platform_device *pdev)
if (IS_ERR(qoriq_priv->ecc_addr))
return PTR_ERR(qoriq_priv->ecc_addr);
}
+ qoriq_priv->is_dmacoherent = of_property_read_bool(np, "dma-coherent");
rc = ahci_platform_enable_resources(hpriv);
if (rc)
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 2/2] ahci: qoriq: report warning when ecc register is missing
From: yuantian.tang at nxp.com @ 2016-11-16 3:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479265879-48840-1-git-send-email-yuantian.tang@nxp.com>
From: Tang Yuantian <Yuantian.Tang@nxp.com>
For ls1021a and ls1046a socs, sata ecc must be disabled.
If ecc register is not found in sata node in dts, report
a warning.
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
drivers/ata/ahci_qoriq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 45c88de..66eb4b5 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -158,6 +158,7 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
switch (qpriv->type) {
case AHCI_LS1021A:
+ WARN_ON(!qpriv->ecc_addr);
writel(SATA_ECC_DISABLE, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(LS1021A_PORT_PHY2, reg_base + PORT_PHY2);
@@ -185,6 +186,7 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
break;
case AHCI_LS1046A:
+ WARN_ON(!qpriv->ecc_addr);
writel(LS1046A_SATA_ECC_DIS, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH] reset: hisilicon: add a polarity cell for reset line specifier
From: Jiancheng Xue @ 2016-11-16 3:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479206594.2456.24.camel@pengutronix.de>
Hi Philipp,
On 2016/11/15 18:43, Philipp Zabel wrote:
> Hi Jiancheng,
>
> Am Dienstag, den 15.11.2016, 15:09 +0800 schrieb Jiancheng Xue:
>> Add a polarity cell for reset line specifier. If the reset line
>> is asserted when the register bit is 1, the polarity is
>> normal. Otherwise, it is inverted.
>>
>> Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
>> ---
Thank you very much for replying so soon.
Please allow me to decribe the reason why this patch exists first.
All bits in the reset controller were designed to be active-high.
But in a recent chip only one bit was implemented to be active-low :(
>> .../devicetree/bindings/clock/hisi-crg.txt | 11 ++++---
>> arch/arm/boot/dts/hi3519.dtsi | 2 +-
>> drivers/clk/hisilicon/reset.c | 36 ++++++++++++++++------
>> 3 files changed, 33 insertions(+), 16 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>> index e3919b6..fcbb4f3 100644
>> --- a/Documentation/devicetree/bindings/clock/hisi-crg.txt
>> +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>> @@ -25,19 +25,20 @@ to specify the clock which they consume.
>>
>> All these identifier could be found in <dt-bindings/clock/hi3519-clock.h>.
>>
>> -- #reset-cells: should be 2.
>> +- #reset-cells: should be 3.
>>
>> A reset signal can be controlled by writing a bit register in the CRG module.
>> -The reset specifier consists of two cells. The first cell represents the
>> +The reset specifier consists of three cells. The first cell represents the
>> register offset relative to the base address. The second cell represents the
>> -bit index in the register.
>> +bit index in the register. The third cell represents the polarity of the reset
>> +line (0 for normal, 1 for inverted).
>
> What is normal and what is inverted? Please specify which is active-high
> and which is active-low.
>
OK. I'll use active-high and active-low instead.
>>
>> Example: CRG nodes
>> CRG: clock-reset-controller at 12010000 {
>> compatible = "hisilicon,hi3519-crg";
>> reg = <0x12010000 0x10000>;
>> #clock-cells = <1>;
>> - #reset-cells = <2>;
>> + #reset-cells = <3>;
>> };
>>
>> Example: consumer nodes
>> @@ -45,5 +46,5 @@ i2c0: i2c at 12110000 {
>> compatible = "hisilicon,hi3519-i2c";
>> reg = <0x12110000 0x1000>;
>> clocks = <&CRG HI3519_I2C0_RST>;
>> - resets = <&CRG 0xe4 0>;
>> + resets = <&CRG 0xe4 0 0>;
>> };
>> diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
>> index 5729ecf..b7cb182 100644
>> --- a/arch/arm/boot/dts/hi3519.dtsi
>> +++ b/arch/arm/boot/dts/hi3519.dtsi
>> @@ -50,7 +50,7 @@
>> crg: clock-reset-controller at 12010000 {
>> compatible = "hisilicon,hi3519-crg";
>> #clock-cells = <1>;
>> - #reset-cells = <2>;
>> + #reset-cells = <3>;
>
> That is a backwards incompatible change. Which I think in this case
> could be tolerated, because there are no users yet of the reset
> controller. Or are there any hi3519 based device trees that use the
> resets out in the wild? If there are, the driver must continue to
> support old device trees with two reset-cells. Which would not be
> trivial because currently the core checks in reset_control_get that
> rcdev->of_n_reset_cells is equal to the #reset-cells value from DT.
I understand the backwards compatiblity is very important. As it can be basically
confirmed that the possibility of using hi3519 based device trees is very low,
to keep the code simple, I chose to give up the backwards compatiblity.
Maybe it is not very convincing. If you think it's better to keep backwards
compatiblity here, I can only change reset-cells to 3 for chipsets except Hi3519.
> One possibility to get around changing the binding would be to stuff the
> polarity bit into low bits of the register address cell.
>
It's also a solution. But I feel it's not very clear for reset consumer to
composite these information together as a index number. Maybe I'm wrong.
> Either way, I'm not very happy with blowing up the complexity of the
> reset phandles at the reset consumer side.
By complexity, do you mean that the consumer side doesn't need to know the
detailed information of the implementation of the reset controller eventhough
only in the device tree?
> If you do change the binding, is there any way you could change from a
> register address + bit offset binding to an index based binding with the
> information about reset bit positions and polarities contained in the
> driver, or in the crg node, similarly to the ti-syscon-reset bindings?
> That would also improve consistency with clock bindings, which already
> use a number as identifier.
>
I agree with that this solution is more modular. But the device node of the
reset controller will get more complicated. Actually, the device tree of
SoC part is provided by SoC vendor. In my opinion, we need balance between reset
provider and consumer :). And I supposed rcdev->of_xlate was designed to treat this
case. Am I right?
> [...]
>> @@ -59,14 +65,19 @@ static int hisi_reset_assert(struct reset_controller_dev *rcdev,
>> unsigned long flags;
>> u32 offset, reg;
>> u8 bit;
>> + bool polarity;
>>
>> offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
>> - bit = id & HISI_RESET_BIT_MASK;
>> + bit = (id & HISI_RESET_BIT_MASK) >> HISI_RESET_BIT_SHIFT;
>> + polarity = id & HISI_RESET_POLARITY_MASK;
>>
>> spin_lock_irqsave(&rstc->lock, flags);
>>
>> reg = readl(rstc->membase + offset);
>> - writel(reg | BIT(bit), rstc->membase + offset);
>> + if (polarity)
>> + writel(reg & ~BIT(bit), rstc->membase + offset);
>> + else
>> + writel(reg | BIT(bit), rstc->membase + offset);
>
> So there is no hardware polarity setting, which means the
> ti-syscon-reset bindings could fit in this case.
>
It seems that ti-syscon-reset doesn't support polarity now. Certainly it can be extended
through flags.
Thank you again.
Best Regards,
Jiancheng
> .
>
^ permalink raw reply
* [PATCH v5] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-11-16 3:20 UTC (permalink / raw)
To: linux-arm-kernel
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
mode, those signals will cause h-time larger than normal and reduce FPS.
So need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
Ths_trail+Ths_exit)/(htotal*bpp/lane_number)
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
Change since v4:
- tune the calc comment more clear.
- define the phy timings as constants.
Chnage since v3:
- wrapp the commit msg.
- fix alignment of some lines.
Change since v2:
- move phy timing back to dsi_phy_timconfig.
Change since v1:
- phy_timing2 and phy_timing3 refer clock cycle time.
- define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT.
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 64 +++++++++++++++++++++++++++---------
1 file changed, 48 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..eaa5a22 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -86,7 +86,7 @@
#define DSI_PHY_TIMECON0 0x110
#define LPX (0xff << 0)
-#define HS_PRPR (0xff << 8)
+#define HS_PREP (0xff << 8)
#define HS_ZERO (0xff << 16)
#define HS_TRAIL (0xff << 24)
@@ -102,10 +102,16 @@
#define CLK_TRAIL (0xff << 24)
#define DSI_PHY_TIMECON3 0x11c
-#define CLK_HS_PRPR (0xff << 0)
+#define CLK_HS_PREP (0xff << 0)
#define CLK_HS_POST (0xff << 8)
#define CLK_HS_EXIT (0xff << 16)
+#define T_LPX 5
+#define T_HS_PREP 6
+#define T_HS_TRAIL 8
+#define T_HS_EXIT 7
+#define T_HS_ZERO 10
+
#define NS_TO_CYCLE(n, c) ((n) / (c) + (((n) % (c)) ? 1 : 0))
struct phy;
@@ -161,20 +167,18 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
static void dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
- unsigned int ui, cycle_time;
- unsigned int lpx;
+ u32 ui, cycle_time;
ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
- lpx = 5;
- timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
- timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
+ timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
+ timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
+ T_HS_EXIT << 24;
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
(NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
- NS_TO_CYCLE(0x40, cycle_time);
+ timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -202,19 +206,47 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->dev;
int ret;
+ u64 pixel_clock, total_bits;
+ u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
if (++dsi->refcount != 1)
return 0;
+ switch (dsi->format) {
+ case MIPI_DSI_FMT_RGB565:
+ bit_per_pixel = 16;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ bit_per_pixel = 18;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ case MIPI_DSI_FMT_RGB888:
+ default:
+ bit_per_pixel = 24;
+ break;
+ }
+
/**
- * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
- * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
- * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
- * we set mipi_ratio is 1.05.
+ * vm.pixelclock is in kHz, pixel_clock unit is Hz, so multiply by 1000
+ * htotal_time = htotal * byte_per_pixel / num_lanes
+ * overhead_time = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
+ * mipi_ratio = (htotal_time + overhead_time) / htotal_time
+ * data_rate = pixel_clock * bit_per_pixel * mipi_ratio / num_lanes;
*/
- dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+ pixel_clock = dsi->vm.pixelclock * 1000;
+ htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+ dsi->vm.hsync_len;
+ htotal_bits = htotal * bit_per_pixel;
+
+ overhead_cycles = T_LPX + T_HS_PREP + T_HS_ZERO + T_HS_TRAIL +
+ T_HS_EXIT;
+ overhead_bits = overhead_cycles * dsi->lanes * 8;
+ total_bits = htotal_bits + overhead_bits;
+
+ dsi->data_rate = DIV_ROUND_UP_ULL(pixel_clock * total_bits,
+ htotal * dsi->lanes);
- ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
+ ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
dev_err(dev, "Failed to set data rate: %d\n", ret);
goto err_refcount;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Vinod Koul @ 2016-11-16 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
On Thu, Nov 10, 2016 at 04:17:48PM +0100, Sylwester Nawrocki wrote:
> This patch series aims to convert the s3c64xx platform to use
> the new DMA channel request API, i.e. this is only meaningful
> for non-dt systems using s3c64xx SoCs.
>
> Presumably the first 2 or 4 patches in this series could be queued
> for v4.10-rc1 and the remaining patches could be left for subsequent
> release, to avoid non-trivial conflict with patches already applied
> in the ASoC tree.
I am fine with dma patch (expect the subsystem tag) and others except arm
ones have acks, so I think we can merge this for v4.10-rc1. I cna create a
immutable tag and people can merge into their tree in case they have
dependencies.
Btw need acks on ARM patches before I can apply
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Vinod Koul @ 2016-11-16 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114114216.GA8986@griffinp-ThinkPad-X1-Carbon-2nd>
On Mon, Nov 14, 2016 at 11:42:16AM +0000, Peter Griffin wrote:
> Hi Vinod,
>
> On Mon, 14 Nov 2016, Vinod Koul wrote:
>
> > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > >
> > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > without providing Linus with a messy merge conflict.
> > > >
> > > > So the remoteproc parts now has to go through my tree.
> > >
> > > OK, I think the best approach is for Vinod to create an immutable
> > > branch with the entire fdma series on, and then both of you merge that branch into
> > > your respective trees.
> >
> > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > tag, please do let me know
>
> OK.
>
> >
> > >
> > > That way there won't be any conflicts and you can both accept further changes
> > > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> > > because they have dependencies on each other.
> > >
> > > I will send a v11 series in a moment which includes the feedback in this email
> > > and also include the additional fixes which Vinod has applied since the driver
> > > has been in linux-next.
> >
> > WHY.. Stuff is already merged twice!
>
> When the feedback is "there is an unrelated change in this patch", the only way
> you can fix that is by having a new version of the patch.
It can be reverted and clean patch applied..
--
~Vinod
^ permalink raw reply
* [PATCH v5] drm/mediatek: fixed the calc method of data rate per lane
From: Daniel Kurtz @ 2016-11-16 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479266454-31892-1-git-send-email-jitao.shi@mediatek.com>
Hi Jitao,
On Wed, Nov 16, 2016 at 11:20 AM, Jitao Shi <jitao.shi@mediatek.com> wrote:
>
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
> Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
> mode, those signals will cause h-time larger than normal and reduce FPS.
> So need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
> Ths_trail+Ths_exit)/(htotal*bpp/lane_number)
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
For this patch,
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
But, one more clean up suggestion for another patch, below...
> ---
> Change since v4:
> - tune the calc comment more clear.
> - define the phy timings as constants.
>
> Chnage since v3:
> - wrapp the commit msg.
> - fix alignment of some lines.
>
> Change since v2:
> - move phy timing back to dsi_phy_timconfig.
>
> Change since v1:
> - phy_timing2 and phy_timing3 refer clock cycle time.
> - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT.
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 64 +++++++++++++++++++++++++++---------
> 1 file changed, 48 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 28b2044..eaa5a22 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -86,7 +86,7 @@
>
> #define DSI_PHY_TIMECON0 0x110
> #define LPX (0xff << 0)
> -#define HS_PRPR (0xff << 8)
> +#define HS_PREP (0xff << 8)
> #define HS_ZERO (0xff << 16)
> #define HS_TRAIL (0xff << 24)
>
> @@ -102,10 +102,16 @@
> #define CLK_TRAIL (0xff << 24)
>
> #define DSI_PHY_TIMECON3 0x11c
> -#define CLK_HS_PRPR (0xff << 0)
> +#define CLK_HS_PREP (0xff << 0)
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define T_LPX 5
> +#define T_HS_PREP 6
> +#define T_HS_TRAIL 8
> +#define T_HS_EXIT 7
> +#define T_HS_ZERO 10
> +
> #define NS_TO_CYCLE(n, c) ((n) / (c) + (((n) % (c)) ? 1 : 0))
>
> struct phy;
> @@ -161,20 +167,18 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
> static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> {
> u32 timcon0, timcon1, timcon2, timcon3;
> - unsigned int ui, cycle_time;
> - unsigned int lpx;
> + u32 ui, cycle_time;
>
> ui = 1000 / dsi->data_rate + 0x01;
> cycle_time = 8000 / dsi->data_rate + 0x01;
> - lpx = 5;
>
> - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> - (4 * lpx);
> + timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
> + timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> + T_HS_EXIT << 24;
> timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> - NS_TO_CYCLE(0x40, cycle_time);
> + timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
> + NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
>
> writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> @@ -202,19 +206,47 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> {
> struct device *dev = dsi->dev;
> int ret;
> + u64 pixel_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
>
> if (++dsi->refcount != 1)
> return 0;
>
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
> +
> /**
> - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> - * we set mipi_ratio is 1.05.
> + * vm.pixelclock is in kHz, pixel_clock unit is Hz, so multiply by 1000
> + * htotal_time = htotal * byte_per_pixel / num_lanes
> + * overhead_time = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> + * mipi_ratio = (htotal_time + overhead_time) / htotal_time
> + * data_rate = pixel_clock * bit_per_pixel * mipi_ratio / num_lanes;
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + pixel_clock = dsi->vm.pixelclock * 1000;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> + dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> + overhead_cycles = T_LPX + T_HS_PREP + T_HS_ZERO + T_HS_TRAIL +
> + T_HS_EXIT;
> + overhead_bits = overhead_cycles * dsi->lanes * 8;
> + total_bits = htotal_bits + overhead_bits;
> +
> + dsi->data_rate = DIV_ROUND_UP_ULL(pixel_clock * total_bits,
> + htotal * dsi->lanes);
dsi->data_rate is only used here and in dsi_phy_timconfig(), which is
called directly a few lines down in this same function.
Rather than permanently storing this as state in struct mtk_dsi, just
pass the newly computed data_rate as a paratmer to
dsi_phy_timconfig().
Thanks,
-Dan
>
> - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> if (ret < 0) {
> dev_err(dev, "Failed to set data rate: %d\n", ret);
> goto err_refcount;
> --
> 1.7.9.5
>
^ permalink raw reply
* [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-16 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878twndi54.wl%kuninori.morimoto.gx@renesas.com>
Hi Rob, Michael, Russell
What is the conclusion of this patch ?
We shouldn't add devm_of_clk_get() ? or can I continue ?
The problem of current [devm_]clk_get() handles *dev only,
but I need to get clocks from DT node, not dev
sound_soc {
...
cpu {
...
=> clocks = <&xxx>;
};
codec {
...
=> clocks = <&xxx>;
};
};
> > Thank you for your feedback
> >
> > > > struct clk *clk_get(struct device *dev, const char *con_id)
> > > > {
> > > > ...
> > > > if (dev) {
> > > > clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id);
> > > > ~~~~~~~~~~~~
> > > > ...
> > > > }
> > > > }
> > > >
> > > > I would like to select specific device_node.
> > >
> > > Do you have access to the struct device that you want to target? Can you
> > > pass that device into either clk_get or devm_clk_get?
> >
> > If my understanding was correct, I think I can't.
> > In below case, "sound_soc" has its *dev, but "cpu" and "codec" doesn't
> > have *dev, it has node only. Thus, we are using of_clk_get() for these now.
> >
> > clk = of_clk_get(cpu, xxx);
> > clk = of_clk_get(codec, xxx);
> >
> > sound_soc {
> > ...
> > cpu {
> > ...
> > => clocks = <&xxx>;
> > };
> > codec {
> > ...
> > => clocks = <&xxx>;
> > };
> > };
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH fpga 8/9] fpga socfpga: Use the scatterlist interface
From: Jason Gunthorpe @ 2016-11-16 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611150940270.3634@atull-VirtualBox2>
On Tue, Nov 15, 2016 at 09:47:05AM -0600, atull wrote:
> Not different.
>
> From 'fpga-mgr.txt':
> The programming sequence is:
> 1. .write_init
> 2. .write (may be called once or multiple times)
> 3. .write_complete
>
> The old write was be separate from write_init and write_complete
> because I figured that in the future someone may be streaming in
> the bitstream and not have the whole bitstream in memory.
What is the point of this if write_init gets a copy of the buffer -
what is that supposed to be?
If you see things this way why are you opposed to patch 9? I'll change
things around to call write multiple times and force the sg list into
write_init, which seems like what you intended anyhow..
Jason
^ permalink raw reply
* [PATCH 2/3] thermal: hisilicon: fix for dependency
From: Leo Yan @ 2016-11-16 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479212695.2224.12.camel@intel.com>
On Tue, Nov 15, 2016 at 08:24:55PM +0800, Zhang Rui wrote:
> On Sat, 2016-11-12 at 20:05 +0800, Leo Yan wrote:
> > Hi Rui, Eduardo,
> >
> > On Wed, Aug 31, 2016 at 04:50:16PM +0800, Leo Yan wrote:
> > >
> > > The thermal driver is standalone driver which is used to enable
> > > thermal sensors, so it can be used with any cooling device and
> > > should not bind with CPU cooling device driver.
> > >
> > > This original patch is suggested by Amit Kucheria; so it's to
> > > polish the dependency in Kconfig, and remove the dependency with
> > > CPU_THERMAL.
> > Could you help review this patch? Or need me resend this patch? Sorry
> > I have not tracked this patches well before, this is one missed
> > patch for 96board Hikey.
> >
> as it still applies cleanly, the patch is queued for 4.10.
Thanks a lot.
> thanks,
> rui
> > Thanks,
> > Leo Yan
> >
> > >
> > > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > > ---
> > > ?drivers/thermal/Kconfig | 4 +++-
> > > ?1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > > index 2d702ca..91ebab3 100644
> > > --- a/drivers/thermal/Kconfig
> > > +++ b/drivers/thermal/Kconfig
> > > @@ -177,8 +177,10 @@ config THERMAL_EMULATION
> > > ?
> > > ?config HISI_THERMAL
> > > ? tristate "Hisilicon thermal driver"
> > > - depends on (ARCH_HISI && CPU_THERMAL && OF) ||
> > > COMPILE_TEST
> > > + depends on ARCH_HISI || COMPILE_TEST
> > > ? depends on HAS_IOMEM
> > > + depends on OF
> > > + default y
> > > ? help
> > > ? ??Enable this to plug hisilicon's thermal sensor driver
> > > into the Linux
> > > ? ??thermal framework. cpufreq is used as the cooling device
> > > to throttle
^ permalink raw reply
* [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Sriram Dash @ 2016-11-16 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116000740.iq6ffcjanrrvrdnq@rob-hp-laptop>
>From: Rob Herring [mailto:robh at kernel.org]
>On Mon, Nov 14, 2016 at 10:56:54AM +0530, Sriram Dash wrote:
>> Adds qoriq usb 3.0 phy driver support for LS1043A platform.
>> Describes the qoriq usb 2.0 phy driver binding, currently used for
>> LS1043A platform.
>>
>> Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
>> ---
>> .../devicetree/bindings/phy/phy-qoriq-usb3.txt | 36 ++++
>> drivers/phy/Kconfig | 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-qoriq-usb3.c | 202 +++++++++++++++++++++
>> 4 files changed, 247 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> create mode 100644 drivers/phy/phy-qoriq-usb3.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> new file mode 100644
>> index 0000000..d934c80
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> @@ -0,0 +1,36 @@
>> +Driver for Freescale USB 3.0 PHY
>> +
>> +Required properties:
>> +
>> +- compatible : fsl,qoriq-usb3-phy
>> +- reg : register mappings for Parameter Configuration Register
>> + and Phy base offset.
>> +- reg-names : "param_ctrl" and "phy_base"
>> +- phy_type : For multi port host USB controllers, should be one of
>> + "ulpi", or "serial". For dual role USB controllers,
>> + should be one of "ulpi", "utmi", "utmi_wide", or "serial".
Hi Rob,
>
>Do any of these really apply to a USB3 PHY?
>
The concerned USB3 phy used is UTMI. I agree to your point somewhat that
all the types are not required now. Anyway, shall I make it an optional
property, with the mention of only UTMI and ULPI?
>Rob
>
>> +
>> +Example:
>> + usbphy0: usb3-phy at 084F0000 {
>
>usb-phy at ...
>
Ok. Will change in the next rev for Documentation and dts (patch 2/2)
>> + compatible = "fsl,qoriq-usb3-phy";
>> + reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F0000 0x0 0x5000>;
>> + reg-names = "param_ctrl", "phy_base";
>> + #phy-cells = <0>;
>> + phy_type = "utmi";
>> + };
>> +
>> + usbphy1: usb3-phy at 08500000 {
>> + compatible = "fsl,qoriq-usb3-phy";
>> + reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x08500000 0x0 0x5000>;
>> + reg-names = "param_ctrl", "phy_base";
>> + #phy-cells = <0>;
>> + phy_type = "utmi";
>> + };
>> +
>> + usbphy2: usb3-phy at 08510000 {
>> + compatible = "fsl,qoriq-usb3-phy";
>> + reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x08510000 0x0 0x5000>;
>> + reg-names = "param_ctrl", "phy_base";
>> + #phy-cells = <0>;
>> + phy_type = "utmi";
>> + };
^ permalink raw reply
* [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Anurup M @ 2016-11-16 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115095148.GA29104@leverpostej>
On Tuesday 15 November 2016 03:21 PM, Mark Rutland wrote:
> On Mon, Nov 14, 2016 at 05:36:44AM +0530, Anurup M wrote:
>> On Friday 11 November 2016 12:00 AM, Mark Rutland wrote:
>>> On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:
>>>> + - scl-id : The Super Cluster ID. This can be the ID of the CPU die
>>>> + or IO die in the chip.
>>> What's this needed for?
>> This is used as suffix to the PMU name. hisi_l3c<scl-id>. (hisi_l3c2
>> - for scl-id = 2).
>> This is to identify the pmu correspond to which CPU die in the socket.
>>>> + - num-events : No of events supported by this PMU device.
>>>> +
>>>> + - num-counters : No of hardware counters available for counting.
>>> This isn't probeable or well-known?
>> My idea is to have the common properties of SoC PMU added here.
>> The num-events, num-counters etc. So that handling can be made
>> common in the driver.
>> Is it not recommended? Please share your comments.
> This feels like something that should be well-known for the programming
> model of the device. If the number of events and/or counters shange, I'd
> expect other things to also change such that the device is no longer
> compatible with previous versions.
>
> [...]
>
Agreed, it is possible that the versions can be still incompatible.
Shall move it to
driver in v2.
>> The below two properties (module-id, cfgen-map) differs between
>> chips hip05/06 and hip07.
> The module-id property sounds like a HW description, but it's not
> entirely clear to me what cfgen-map is; more comments on that below.
>
>> Please suggest.
>>>> + - module-id : Module ID to input for djtag. This property is an array of
>>>> + module_id for each L3 cache banks.
>>>> +
>>>> + - num-banks : Number of banks or instances of the device.
>>> What's a bank? Surely they have separate instances of the PMU?
>> Yes each bank is a separate instance of PMU.
>> If it is recommended to have each L3 cache bank registered as
>> separate PMU with perf, then this property will be removed.
> Generally, I think that separate instances are preferable.
>
>>> What order are these in?
>> The bank number will start from "1" till "4" for L3 cache as there
>> are four banks in hip05/06/07 chips.
>>>> + - cfgen-map : Config enable array to select the bank.
>>> Huh?
> As above, it's not clear to me what this property represents. Could you
> please clarify?
This property is used to select the bank. The naming lead to confusion.
I shall change it to bank_select.
If it is recommended to register each L3 cache bank as separate PMU then
this property will be moved to driver.
Thanks
Anurup
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH] clk: qoriq: added ls1012a clock configuration
From: yuantian.tang at nxp.com @ 2016-11-16 5:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Tang Yuantian <Yuantian.Tang@nxp.com>
Added ls1012a clock configuation information.
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
drivers/clk/clk-qoriq.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 1bece0f..563d874 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -202,6 +202,14 @@ static const struct clockgen_muxinfo ls1021a_cmux = {
}
};
+static const struct clockgen_muxinfo ls1012a_cmux = {
+ {
+ [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
+ {},
+ [2] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
+ }
+};
+
static const struct clockgen_muxinfo t1040_cmux = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
@@ -482,6 +490,16 @@ static const struct clockgen_chipinfo chipinfo[] = {
.pll_mask = 0x03,
},
{
+ .compat = "fsl,ls1012a-clockgen",
+ .cmux_groups = {
+ &ls1012a_cmux
+ },
+ .cmux_to_group = {
+ 0, -1
+ },
+ .pll_mask = 0x03,
+ },
+ {
.compat = "fsl,ls1043a-clockgen",
.init_periph = t2080_init_periph,
.cmux_groups = {
@@ -1284,6 +1302,7 @@ CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-2.0", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1043a, "fsl,ls1043a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen", clockgen_init);
+CLK_OF_DECLARE(qoriq_clockgen_ls1012a, "fsl,ls1012a-clockgen", clockgen_init);
/* Legacy nodes */
CLK_OF_DECLARE(qoriq_sysclk_1, "fsl,qoriq-sysclk-1.0", sysclk_init);
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device nodeg
From: Sekhar Nori @ 2016-11-16 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115211951.GH11011@uda0271908>
On Wednesday 16 November 2016 02:49 AM, Bin Liu wrote:
> On Tue, Nov 15, 2016 at 04:16:02PM +0530, Sekhar Nori wrote:
>> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
>>> This adds the device tree node for the usb otg
>>> controller present in the da850 family of SoC's.
>>> This also enables the otg usb controller for the lcdk board.
>>>
>>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>>> ---
>>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>>> arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
>>> 2 files changed, 23 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
>>> index 7b8ab21..9f5040c 100644
>>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>>> @@ -158,6 +158,14 @@
>>> rx-num-evt = <32>;
>>> };
>>>
>>> +&usb_phy {
>>> + status = "okay";
>>> + };
>>
>> As mentioned by David already, this node needs to be removed. Please
>> rebase this on top of latest linux-davinci/master when ready for merging
>> (driver changes accepted).
>
> Dropped this patch due to this comment.
Bin, Please do not apply dts or arch/arm/mach-davinci patches. I have a
bunch queued through my tree and more in pipeline and it will cause
unnecessary merge conflicts in linux-next or at Linus.
For future, I have asked Alexandre to send driver and dts patches as
separate series so there is no confusion on who should apply.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH V2 fix 4/6] mm: mempolicy: intruduce a helper huge_nodemask()
From: Huang Shijie @ 2016-11-16 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-5-git-send-email-shijie.huang@arm.com>
This patch intruduces a new helper huge_nodemask(),
we can use it to get the node mask.
This idea of the function is from the init_nodemask_of_mempolicy():
Return true if we can succeed in extracting the node_mask
for 'bind' or 'interleave' policy or initializing the node_mask
to contain the single node for 'preferred' or 'local' policy.
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
The previous version does not treat the MPOL_PREFERRED/MPOL_INTERLEAVE cases.
This patch adds the code to set proper node mask for
MPOL_PREFERRED/MPOL_INTERLEAVE.
---
include/linux/mempolicy.h | 8 ++++++++
mm/mempolicy.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index 5e5b296..7796a40 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -145,6 +145,8 @@ extern void mpol_rebind_task(struct task_struct *tsk, const nodemask_t *new,
enum mpol_rebind_step step);
extern void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new);
+extern bool huge_nodemask(struct vm_area_struct *vma,
+ unsigned long addr, nodemask_t *mask);
extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags,
struct mempolicy **mpol, nodemask_t **nodemask);
@@ -261,6 +263,12 @@ static inline void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new)
{
}
+static inline bool huge_nodemask(struct vm_area_struct *vma,
+ unsigned long addr, nodemask_t *mask)
+{
+ return false;
+}
+
static inline struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags,
struct mempolicy **mpol, nodemask_t **nodemask)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 6d3639e..5063a69 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1800,6 +1800,53 @@ static inline unsigned interleave_nid(struct mempolicy *pol,
#ifdef CONFIG_HUGETLBFS
/*
+ * huge_nodemask(@vma, @addr, @mask)
+ * @vma: virtual memory area whose policy is sought
+ * @addr: address in @vma
+ * @mask: a nodemask pointer
+ *
+ * Return true if we can succeed in extracting the policy nodemask
+ * for 'bind' or 'interleave' policy into the argument @mask, or
+ * initializing the argument @mask to contain the single node for
+ * 'preferred' or 'local' policy.
+ */
+bool huge_nodemask(struct vm_area_struct *vma, unsigned long addr,
+ nodemask_t *mask)
+{
+ struct mempolicy *mpol;
+ bool ret = true;
+ int nid;
+
+ if (!mask)
+ return false;
+
+ mpol = get_vma_policy(vma, addr);
+
+ switch (mpol->mode) {
+ case MPOL_PREFERRED:
+ if (mpol->flags & MPOL_F_LOCAL)
+ nid = numa_node_id();
+ else
+ nid = mpol->v.preferred_node;
+ init_nodemask_of_node(mask, nid);
+ break;
+
+ case MPOL_BIND:
+ /* Fall through */
+ case MPOL_INTERLEAVE:
+ *mask = mpol->v.nodes;
+ break;
+
+ default:
+ ret = false;
+ break;
+ }
+ mpol_cond_put(mpol);
+
+ return ret;
+}
+
+/*
* huge_zonelist(@vma, @addr, @gfp_flags, @mpol)
* @vma: virtual memory area whose policy is sought
* @addr: address in @vma for shared policy lookup and interleave policy
--
2.5.5
^ permalink raw reply related
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