* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Mark Brown @ 2014-01-22 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMi9puZSzdDJ-sur5ks7VcDH+XV_MbuA0xeidLgp=uJacg@mail.gmail.com>
On Tue, Jan 21, 2014 at 10:14:49AM -0800, Olof Johansson wrote:
> On Tue, Jan 21, 2014 at 12:55 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > That could make sense, but still I wonder how those shall be handled
> > in a fine grained power management setup. In other words, when shall
> > those be gated/ungated? Is the mmc core able to take the correct
> > decision about these?
> The reference clock is in most cases I've seen 32kHz, and not
> something that's under fine-grained power management. So it's not used
> to regulate interface speed, etc.
I have seen devices connected using SDIO which did use fine grained
power management here with faster clocks. They're definitely not the
common case but they're there. :/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140122/de54e4eb/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Will Deacon @ 2014-01-22 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390325166-16840-1-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On Tue, Jan 21, 2014 at 05:26:06PM +0000, Laura Abbott wrote:
> arm64 currently lacks support for -fstack-protector. Add
> similar functionality to arm to detect stack corruption.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> arch/arm64/Kconfig | 12 +++++++++
> arch/arm64/Makefile | 4 +++
> arch/arm64/include/asm/stackprotector.h | 38 +++++++++++++++++++++++++++++++
> arch/arm64/kernel/process.c | 9 +++++++
> 4 files changed, 63 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm64/include/asm/stackprotector.h
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 6d4dd22..4f86874 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -168,6 +168,18 @@ config HOTPLUG_CPU
> Say Y here to experiment with turning CPUs off and on. CPUs
> can be controlled through /sys/devices/system/cpu.
>
> +config CC_STACKPROTECTOR
> + bool "Enable -fstack-protector buffer overflow detection"
> + help
> + This option turns on the -fstack-protector GCC feature. This
> + feature puts, at the beginning of functions, a canary value on
> + the stack just before the return address, and validates
> + the value just before actually returning. Stack based buffer
> + overflows (that need to overwrite this return address) now also
> + overwrite the canary, which gets detected and the attack is then
> + neutralized via a kernel panic.
> + This feature requires gcc version 4.2 or above.
You can remove that bit about GCC -- GCC 4.2 doesn't support AArch64.
> +
> source kernel/Kconfig.preempt
>
> config HZ
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 2fceb71..1ce221e 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -48,6 +48,10 @@ core-$(CONFIG_XEN) += arch/arm64/xen/
> libs-y := arch/arm64/lib/ $(libs-y)
> libs-y += $(LIBGCC)
>
> +ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
> +KBUILD_CFLAGS +=-fstack-protector
> +endif
> +
> # Default target when executing plain make
> KBUILD_IMAGE := Image.gz
> KBUILD_DTBS := dtbs
> diff --git a/arch/arm64/include/asm/stackprotector.h b/arch/arm64/include/asm/stackprotector.h
> new file mode 100644
> index 0000000..de00332
> --- /dev/null
> +++ b/arch/arm64/include/asm/stackprotector.h
> @@ -0,0 +1,38 @@
> +/*
> + * GCC stack protector support.
> + *
> + * Stack protector works by putting predefined pattern at the start of
> + * the stack frame and verifying that it hasn't been overwritten when
> + * returning from the function. The pattern is called stack canary
> + * and gcc expects it to be defined by a global variable called
> + * "__stack_chk_guard" on ARM. This unfortunately means that on SMP
> + * we cannot have a different canary value per task.
> + */
> +
> +#ifndef _ASM_STACKPROTECTOR_H
__ASM_ for consistency.
> +#define _ASM_STACKPROTECTOR_H 1
Why #define explicitly to 1?
> +
> +#include <linux/random.h>
> +#include <linux/version.h>
> +
> +extern unsigned long __stack_chk_guard;
> +
> +/*
> + * Initialize the stackprotector canary value.
> + *
> + * NOTE: this must only be called from functions that never return,
> + * and it must always be inlined.
> + */
> +static __always_inline void boot_init_stack_canary(void)
> +{
> + unsigned long canary;
> +
> + /* Try to get a semi random initial value. */
> + get_random_bytes(&canary, sizeof(canary));
> + canary ^= LINUX_VERSION_CODE;
> +
> + current->stack_canary = canary;
> + __stack_chk_guard = current->stack_canary;
> +}
> +
> +#endif /* _ASM_STACKPROTECTOR_H */
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index de17c89..592d630 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -50,6 +50,12 @@
> #include <asm/processor.h>
> #include <asm/stacktrace.h>
>
> +#ifdef CONFIG_CC_STACKPROTECTOR
> +#include <linux/stackprotector.h>
> +unsigned long __stack_chk_guard __read_mostly;
> +EXPORT_SYMBOL(__stack_chk_guard);
> +#endif
> +
> static void setup_restart(void)
> {
> /*
> @@ -288,6 +294,9 @@ struct task_struct *__switch_to(struct task_struct *prev,
> {
> struct task_struct *last;
>
> +#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
> + __stack_chk_guard = next->stack_canary;
> +#endif
I don't get the dependency on !SMP. Assumedly, the update of
__stack_chk_guard would be racy otherwise, but that sounds solvable with
atomics. Is the stack_canary updated periodically somewhere else?
Will
^ permalink raw reply
* [PATCH 1/4] ARM: dts: cm-fx6: rearrange the dts file
From: Igor Grinberg @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121204201.GX16215@pengutronix.de>
Hi Sascha,
On 01/21/14 22:42, Sascha Hauer wrote:
> Hi Igor,
>
> On Tue, Jan 21, 2014 at 06:13:29PM +0200, Igor Grinberg wrote:
>> Move the iomuxc definition before the devices definitions
>> (e.g. gpmi, fec).
>
> The nodes are sorted alphabetically. Please keep them sorted.
Hmmm.. I missed that point... Thanks!
Will fix this up and resend.
--
Regards,
Igor.
^ permalink raw reply
* [PATCH 3/3] ARM: allow kernel to be loaded in middle of phymem
From: Wang Nan @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-1-git-send-email-wangnan0@huawei.com>
This patch allows the kernel to be loaded at the middle of kernel awared
physical memory. Before this patch, users must use mem= or device tree to cheat
kernel about the start address of physical memory.
This feature is useful in some special cases, for example, building a crash
dump kernel. Without it, kernel command line, atag and devicetree must be
adjusted carefully, sometimes is impossible.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: <stable@vger.kernel.org> # 3.4+
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geng Hui <hui.geng@huawei.com>
---
arch/arm/mm/init.c | 21 ++++++++++++++++++++-
arch/arm/mm/mmu.c | 13 +++++++++++++
mm/page_alloc.c | 7 +++++--
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 3e8f106..4952726 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -334,9 +334,28 @@ void __init arm_memblock_init(struct meminfo *mi,
{
int i;
- for (i = 0; i < mi->nr_banks; i++)
+ for (i = 0; i < mi->nr_banks; i++) {
memblock_add(mi->bank[i].start, mi->bank[i].size);
+ /*
+ * In some special case, for example, building a crushdump
+ * kernel, we want the kernel to be loaded in the middle of
+ * physical memory. In such case, the physical memory before
+ * PHYS_OFFSET is awkward: it can't get directly mapped
+ * (because its address will be smaller than PAGE_OFFSET,
+ * disturbs user address space) also can't be mapped as
+ * HighMem. We reserve such pages here. The only way to access
+ * those pages is ioremap.
+ */
+ if (mi->bank[i].start < PHYS_OFFSET) {
+ unsigned long reserv_size = PHYS_OFFSET -
+ mi->bank[i].start;
+ if (reserv_size > mi->bank[i].size)
+ reserv_size = mi->bank[i].size;
+ memblock_reserve(mi->bank[i].start, reserv_size);
+ }
+ }
+
/* Register the kernel text, kernel data and initrd with memblock. */
#ifdef CONFIG_XIP_KERNEL
memblock_reserve(__pa(_sdata), _end - _sdata);
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 580ef2d..2a17c24 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1308,6 +1308,19 @@ static void __init map_lowmem(void)
if (start >= end)
break;
+ /*
+ * If this memblock contain memory before PAGE_OFFSET, memory
+ * before PAGE_OFFSET should't get directly mapped, see code
+ * in create_mapping(). However, memory after PAGE_OFFSET is
+ * occupyed by kernel and still need to be mapped.
+ */
+ if (__phys_to_virt(start) < PAGE_OFFSET) {
+ if (__phys_to_virt(end) > PAGE_OFFSET)
+ start = __virt_to_phys(PAGE_OFFSET);
+ else
+ break;
+ }
+
map.pfn = __phys_to_pfn(start);
map.virtual = __phys_to_virt(start);
map.length = end - start;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5248fe0..d2959e3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4840,10 +4840,13 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat)
*/
if (pgdat == NODE_DATA(0)) {
mem_map = NODE_DATA(0)->node_mem_map;
-#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
+ /*
+ * In case of CONFIG_HAVE_MEMBLOCK_NODE_MAP or when kernel
+ * loaded at the middle of physical memory, mem_map should
+ * be adjusted.
+ */
if (page_to_pfn(mem_map) != pgdat->node_start_pfn)
mem_map -= (pgdat->node_start_pfn - ARCH_PFN_OFFSET);
-#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
}
#endif
#endif /* CONFIG_FLAT_NODE_MEM_MAP */
--
1.8.4
^ permalink raw reply related
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Wang Nan @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-1-git-send-email-wangnan0@huawei.com>
ARM's kdump is actually corrupted (at least for omap4460), mainly because of
cache problem: flush_icache_range can't reliably ensure the copied data
correctly goes into RAM. After mmu turned off and jump to the trampoline, kexec
always failed due to random undef instructions.
This patch use ioremap to make sure the destnation of all memcpy() is
uncachable memory, including copying of target kernel and trampoline.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: <stable@vger.kernel.org> # 3.4+
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geng Hui <hui.geng@huawei.com>
---
arch/arm/kernel/machine_kexec.c | 18 ++++++++++++++++--
kernel/kexec.c | 40 +++++++++++++++++++++++++++++++++++-----
2 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index f0d180d..ba0a5a8 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -144,6 +144,7 @@ void machine_kexec(struct kimage *image)
unsigned long page_list;
unsigned long reboot_code_buffer_phys;
unsigned long reboot_entry = (unsigned long)relocate_new_kernel;
+ void __iomem *reboot_entry_remap;
unsigned long reboot_entry_phys;
void *reboot_code_buffer;
@@ -171,9 +172,22 @@ void machine_kexec(struct kimage *image)
/* copy our kernel relocation code to the control code page */
- reboot_entry = fncpy(reboot_code_buffer,
- reboot_entry,
+ reboot_entry_remap = ioremap_nocache(reboot_code_buffer_phys,
+ relocate_new_kernel_size);
+ if (reboot_entry_remap == NULL) {
+ pr_warn("startup code may not be reliably flushed\n");
+ reboot_entry_remap = (void __iomem *)reboot_code_buffer;
+ }
+
+ reboot_entry = fncpy(reboot_entry_remap, reboot_entry,
relocate_new_kernel_size);
+ reboot_entry = (unsigned long)reboot_code_buffer +
+ (reboot_entry -
+ (unsigned long)reboot_entry_remap);
+
+ if (reboot_entry_remap != reboot_code_buffer)
+ iounmap(reboot_entry_remap);
+
reboot_entry_phys = (unsigned long)reboot_entry +
(reboot_code_buffer_phys - (unsigned long)reboot_code_buffer);
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 9c97016..3e92999 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -806,6 +806,7 @@ static int kimage_load_normal_segment(struct kimage *image,
while (mbytes) {
struct page *page;
char *ptr;
+ void __iomem *ioptr;
size_t uchunk, mchunk;
page = kimage_alloc_page(image, GFP_HIGHUSER, maddr);
@@ -818,7 +819,17 @@ static int kimage_load_normal_segment(struct kimage *image,
if (result < 0)
goto out;
- ptr = kmap(page);
+ /*
+ * Try ioremap to make sure the copied data goes into RAM
+ * reliably. If failed (some archs don't allow ioremap RAM),
+ * use kmap instead.
+ */
+ ioptr = ioremap(page_to_pfn(page) << PAGE_SHIFT,
+ PAGE_SIZE);
+ if (ioptr != NULL)
+ ptr = ioptr;
+ else
+ ptr = kmap(page);
/* Start with a clear page */
clear_page(ptr);
ptr += maddr & ~PAGE_MASK;
@@ -827,7 +838,10 @@ static int kimage_load_normal_segment(struct kimage *image,
uchunk = min(ubytes, mchunk);
result = copy_from_user(ptr, buf, uchunk);
- kunmap(page);
+ if (ioptr != NULL)
+ iounmap(ioptr);
+ else
+ kunmap(page);
if (result) {
result = -EFAULT;
goto out;
@@ -846,7 +860,7 @@ static int kimage_load_crash_segment(struct kimage *image,
{
/* For crash dumps kernels we simply copy the data from
* user space to it's destination.
- * We do things a page at a time for the sake of kmap.
+ * We do things a page@a time for the sake of ioremap/kmap.
*/
unsigned long maddr;
size_t ubytes, mbytes;
@@ -861,6 +875,7 @@ static int kimage_load_crash_segment(struct kimage *image,
while (mbytes) {
struct page *page;
char *ptr;
+ void __iomem *ioptr;
size_t uchunk, mchunk;
page = pfn_to_page(maddr >> PAGE_SHIFT);
@@ -868,7 +883,18 @@ static int kimage_load_crash_segment(struct kimage *image,
result = -ENOMEM;
goto out;
}
- ptr = kmap(page);
+ /*
+ * Try ioremap to make sure the copied data goes into RAM
+ * reliably. If failed (some archs don't allow ioremap RAM),
+ * use kmap instead.
+ */
+ ioptr = ioremap_nocache(page_to_pfn(page) << PAGE_SHIFT,
+ PAGE_SIZE);
+ if (ioptr != NULL)
+ ptr = ioptr;
+ else
+ ptr = kmap(page);
+
ptr += maddr & ~PAGE_MASK;
mchunk = min_t(size_t, mbytes,
PAGE_SIZE - (maddr & ~PAGE_MASK));
@@ -879,7 +905,11 @@ static int kimage_load_crash_segment(struct kimage *image,
}
result = copy_from_user(ptr, buf, uchunk);
kexec_flush_icache_page(page);
- kunmap(page);
+ if (ioptr != NULL)
+ iounmap(ioptr);
+ else
+ kunmap(page);
+
if (result) {
result = -EFAULT;
goto out;
--
1.8.4
^ permalink raw reply related
* [PATCH 1/3] ARM: Premit ioremap() to map reserved pages
From: Wang Nan @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-1-git-send-email-wangnan0@huawei.com>
This patch relaxes the restriction set by commit 309caa9cc, which
prohibit ioremap() on all kernel managed pages.
Other architectures, such as x86 and (some specific platforms of) powerpc,
allow such mapping.
ioremap() pages is an efficient way to avoid arm's mysterious cache control.
This feature will be used for arm kexec support to ensure copied data goes into
RAM even without cache flushing, because we found that flush_cache_xxx can't
reliably flush code to memory.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: <stable@vger.kernel.org> # 3.4+
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geng Hui <hui.geng@huawei.com>
---
arch/arm/mm/ioremap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index f123d6e..98b1c10 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -298,7 +298,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
/*
* Don't allow RAM to be mapped - this causes problems with ARMv6+
*/
- if (WARN_ON(pfn_valid(pfn)))
+ if (WARN_ON(pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn))))
return NULL;
area = get_vm_area_caller(size, VM_IOREMAP, caller);
--
1.8.4
^ permalink raw reply related
* [PATCH 0/3] Bugfix for kdump on arm
From: Wang Nan @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
This patch series introduce 3 bugfix for kdump (and kexec) on arm platform.
kdump for arm in fact is corrupted (at least for omap4460). With one-month hard
work and with the help of a jtag debugger, we finally make kdump works
reliablly.
Following is the patches. The first 2 patches forms a group, it allow
ioremap_nocache to be taken on reserved pages on arm platform (which is
prohibited by 309caa9cc) and then use ioremap_nocache to copy kexec required
code. The last 1 is for crash dump kernel. It allow kernel to be loaded in the
middle of kernel awared physical memory. Without it, crashdump kernel must be
carefully configured to boot.
Wang Nan (3):
ARM: Premit ioremap() to map reserved pages
ARM: kexec: copying code to ioremapped area
ARM: allow kernel to be loaded in middle of phymem
arch/arm/kernel/machine_kexec.c | 18 ++++++++++++++++--
arch/arm/mm/init.c | 21 ++++++++++++++++++++-
arch/arm/mm/ioremap.c | 2 +-
arch/arm/mm/mmu.c | 13 +++++++++++++
kernel/kexec.c | 40 +++++++++++++++++++++++++++++++++++-----
mm/page_alloc.c | 7 +++++--
6 files changed, 90 insertions(+), 11 deletions(-)
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geng Hui <hui.geng@huawei.com>
--
1.8.4
^ permalink raw reply
* [PATCH v4 2/5] arm: add new asm macro update_sctlr
From: Will Deacon @ 2014-01-22 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389445524-30623-3-git-send-email-leif.lindholm@linaro.org>
On Sat, Jan 11, 2014 at 01:05:21PM +0000, Leif Lindholm wrote:
> A new macro for setting/clearing bits in the SCTLR.
>
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> Suggested-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/assembler.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 5c22851..aba6458 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -383,4 +383,17 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
> #endif
> .endm
>
> +#ifdef CONFIG_CPU_CP15
> +/* Macro for setting/clearing bits in sctlr */
> + .macro update_sctlr, set:req, clear:req, tmp:req, tmp2:req
> + mrc p15, 0, \tmp, c1, c0, 0
> + ldr \tmp2, =\set
> + orr \tmp, \tmp, \tmp2
> + ldr \tmp2, =\clear
> + mvn \tmp2, \tmp2
> + and \tmp, \tmp, \tmp2
> + mcr p15, 0, \tmp, c1, c0, 0
I think this would be cleaner if you force the caller to put set and clear
into registers beforehand, rather than have to do the literal load every
time. Also, I don't think set and clear should be required (and then you can
lose tmp2 as well).
Will
^ permalink raw reply
* [PATCH v4 1/5] arm: break part of __soft_restart out into separate function
From: Will Deacon @ 2014-01-22 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389445524-30623-2-git-send-email-leif.lindholm@linaro.org>
On Sat, Jan 11, 2014 at 01:05:20PM +0000, Leif Lindholm wrote:
> Certain operations can be considered mandatory for any piece of code
> preparing to switch off the MMU. Break this out into separate function
> dmap_prepare().
idmap_prepare. dmap_prepare sounds like something *completely* different!
With that:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
From: Jack Mitchell @ 2014-01-22 11:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Jack Mitchell <jack@embed.me.uk>
Devicetree include file for setting up the am335x mcasp bus, i2c-2
bus, and audio codec required for a functioning BeagleBone Audio Cape.
Signed-off-by: Jack Mitchell <jack@embed.me.uk>
Signed-off-by: Matt Porter <mporter@linaro.org>
---
arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124 +++++++++++++++++++++
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++
2 files changed, 138 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
new file mode 100644
index 0000000..b8ec3dc
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2014 Jack Mitchell <jack@embed.me.uk>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * In order to enable the BeagleBone Audio Cape this dtsi must be
+ * incuded in the top level dts. On BeagleBone Black hardware the
+ * status of the HDMI dts node must also be set to "disabled".
+ *
+ * --- a/arch/arm/boot/dts/am335x-bone.dts
+ * +++ b/arch/arm/boot/dts/am335x-bone.dts
+ * @@ -9,6 +9,7 @@
+ *
+ * #include "am33xx.dtsi"
+ * #include "am335x-bone-common.dtsi"
+ * +#include "am335x-bone-audio-cape-reva.dtsi"
+ *
+ * &ldo3_reg {
+ * regulator-min-microvolt = <1800000>;
+ *
+ * On BeagleBone Black hardware the status of the HDMI dts node must
+ * also be set to "disabled"
+ *
+ * --- a/arch/arm/boot/dts/am335x-boneblack.dts
+ * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
+ * @@ -73,6 +74,6 @@
+ * pinctrl-names = "default", "off";
+ * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+ * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+ * - status = "okay";
+ * + status = "disabled";
+ * };
+ * };
+ */
+
+/ {
+ sound {
+ compatible = "ti,da830-evm-audio";
+ ti,model = "AM335x BeagleBone Audio Cape Rev. A";
+ ti,audio-codec = <&tlv320aic3106>;
+ ti,mcasp-controller = <&mcasp0>;
+ ti,codec-clock-rate = <12000000>;
+ ti,audio-routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+ };
+
+ audio-cape-gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bone_audio_cape_led_pins>;
+
+ audio-led0 {
+ label = "audio:green:usr0";
+ gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ audio-led1 {
+ label = "audio:green:usr1";
+ gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ };
+};
+
+&am33xx_pinmux {
+ bone_audio_cape_led_pins: pinmux_bone_audio_cape_led_pins {
+ pinctrl-single,pins = <
+ 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a2.gpio1_18 */
+ 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a3.gpio1_19 */
+ >;
+ };
+
+ bone_audio_cape_pins: bone_audio_cape_pins {
+ pinctrl-single,pins = <
+ 0x190 (PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_aclkx.mcasp0_aclkx */
+ 0x194 (PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_fsx.mcasp0_fsx */
+ 0x19c (PIN_INPUT_PULLUP | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2 */
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE2) /* mcasp0_ahclkx.mcasp0_axr3 */
+ >;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
+ status = "okay";
+ clock-frequency = <100000>;
+
+ tlv320aic3106: tlv320aic3106 at 1b {
+ compatible = "ti,tlv320aic3106";
+ reg = <0x1b>;
+ status = "okay";
+
+ /* Regulators */
+ AVDD-supply = <&vmmcsd_fixed>;
+ IOVDD-supply = <&vmmcsd_fixed>;
+ DRVDD-supply = <&vmmcsd_fixed>;
+ DVDD-supply = <&vdd1v8_fixed>;
+ };
+};
+
+&mcasp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&bone_audio_cape_pins>;
+
+ status = "okay";
+
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 2 1
+ >;
+ tx-num-evt = <1>;
+ rx-num-evt = <1>;
+};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index e3f27ec..c1c0f74 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -62,12 +62,26 @@
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
+
+ vdd1v8_fixed: fixedregulator at 1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd1v8_fixed";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
};
&am33xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&clkout2_pin>;
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_ctsn.i2c2_sda */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_rtsn.i2c2_scl */
+ >;
+ };
+
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a5.gpio1_21 */
--
1.8.5.2
^ permalink raw reply related
* [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
From: Lorenzo Pieralisi @ 2014-01-22 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD5DC5.3000908@samsung.com>
On Mon, Jan 20, 2014 at 05:32:53PM +0000, Tomasz Figa wrote:
> Hi Lorenzo,
>
> On 16.01.2014 17:34, Lorenzo Pieralisi wrote:
> > Hi Tomasz,
> >
> > thank you for posting this series. I would like to use the DT bindings
> > for power domains in the bindings for C-states on ARM:
> >
> > http://comments.gmane.org/gmane.linux.power-management.general/41012
> >
> > and in particular link a given C-state to a given power domain so that the
> > kernel will have a way to actually check what devices are lost upon C-state
> > entry (and for devices I also mean CPU peripheral like PMUs, GIC CPU IF,
> > caches and possibly cpus, all of them already represented with DT nodes).
> >
> > I have a remark:
> >
> > - Can we group device nodes under a single power-domain-parent so that
> > all devices defined under that parent won't have to re-define a
> > power-domain property (a property like interrupt-parent, so to speak)
> >
> > What do you think ?
>
> Hmm, I can see potential benefits of such construct on platforms with
> clear hierarchy of devices, but to make sure I'm getting it correctly,
> is the following what you have in mind?
>
> soc-domain-x at 12340000 {
> compatible = "...";
> reg = <...>;
> power-domain-parent = <&power_domains DOMAIN_X>;
>
> device at 1000 {
> compatible = "...";
> // inherits power-domain = <&power_domains DOMAIN_X>
> };
>
> device at 2000 {
> compatible = "...";
> // inherits power-domain = <&power_domains DOMAIN_X>
> };
> };
Yes, exactly, it could avoid duplicated data. I still have an issue
with nodes that are per-cpu but define just one node (eg PMU), since
a CPU might belong in a power-domain on its own (ie one power domain
per-CPU) and basically this means that arch-timers, PMU & company should
link to multiple power domains, ie one per CPU or we find a way to define
a power domain as "banked".
I need to think about this a bit more, thanks for your feedback.
Lorenzo
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Mika Westerberg @ 2014-01-22 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZbb=eO8YRtMn6hW0vn97PkHUo88e_o61DEC8=wPY3_PQ@mail.gmail.com>
On Wed, Jan 22, 2014 at 10:58:38AM +0100, Linus Walleij wrote:
> On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
>
> > The good (or bad, rather) thing about DT is that we can do whatever we
> > please with the new bindings: decide which name or which index
> > (doesn't matter here) a GPIO should have. However we don't have this
> > control over ACPI, where nothing guarantees that the same index will
> > be used for the same GPIO function.
>
> It's not like ACPI will impose some tables on us and expect us to
> use them as-is no matter how crazy they are. Then indeed the whole
> idea of unifying ACPI and DT accessors would be moot and it would
> only work by mistake or as a good joke.
With the current ACPI version we really don't have much of a choice here.
Only way we can distinguish between a set of GPIOs is to use index and hope
that the vendor puts the GPIOs in the table in same order that the driver
expects :-(
This is going to get a bit better when ACPI gets properties (like Arnd
commented already) as then we can get the correct index based on a name in
a table. However, it still requires the vendor to use naming that is
suitable for Linux driver in question.
> The situation with ACPI is just like with DT, it is assumed that the
> author of these tables also look at the Linux kernel drivers to figure
> out what argument goes where and we can influence them.
I certainly hope, now that Android is becoming more and more important,
that the vendors will actually check what the Linux drivers expect and
populate the tables with such information that is suitable for both ACPI
and DT enabled driver.
^ permalink raw reply
* [PATCH v2 5/7] ARM: perf_event: Fully support Krait CPU PMU events
From: Will Deacon @ 2014-01-22 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DEEDDA.4060302@codeaurora.org>
On Tue, Jan 21, 2014 at 09:59:54PM +0000, Stephen Boyd wrote:
> On 01/21/14 10:37, Stephen Boyd wrote:
> > On 01/21/14 10:07, Will Deacon wrote:
> >> Finally, I'd really like to see this get some test coverage, but I don't
> >> want to try running mainline on my phone :) Could you give your patches a
> >> spin with Vince's perf fuzzer please?
> >>
> >> https://github.com/deater/perf_event_tests.git
> >>
> >> (then build the contents of the fuzzer directory and run it for as long as
> >> you can).
> >>
> > Ok. I'll see what I can do.
>
> Neat. This quickly discovered a problem.
Yeah, the fuzzer is good at that!
> BUG: using smp_processor_id() in preemptible [00000000] code: perf_fuzzer/70
> caller is krait_pmu_get_event_idx+0x58/0xd8
> CPU: 2 PID: 70 Comm: perf_fuzzer Not tainted 3.13.0-rc7-next-20140108-00041-gb038353c8516-dirty #58
> [<c02165dc>] (unwind_backtrace) from [<c0212ffc>] (show_stack+0x10/0x14)
> [<c0212ffc>] (show_stack) from [<c06ad5fc>] (dump_stack+0x6c/0xb8)
> [<c06ad5fc>] (dump_stack) from [<c04b0928>] (debug_smp_processor_id+0xc4/0xe8)
> [<c04b0928>] (debug_smp_processor_id) from [<c021a19c>] (krait_pmu_get_event_idx+0x58/0xd8)
> [<c021a19c>] (krait_pmu_get_event_idx) from [<c021833c>] (validate_event+0x2c/0x54)
> [<c021833c>] (validate_event) from [<c02186b4>] (armpmu_event_init+0x264/0x2dc)
> [<c02186b4>] (armpmu_event_init) from [<c02b28e4>] (perf_init_event+0x138/0x194)
> [<c02b28e4>] (perf_init_event) from [<c02b2c04>] (perf_event_alloc+0x2c4/0x348)
> [<c02b2c04>] (perf_event_alloc) from [<c02b37e4>] (SyS_perf_event_open+0x7b8/0x9cc)
> [<c02b37e4>] (SyS_perf_event_open) from [<c020ef80>] (ret_fast_syscall+0x0/0x48)
>
> This is happening because the pmresrn_used mask is per-cpu but
> validate_group() is called in preemptible context. It looks like we'll
> need to add another unsigned long * field to struct pmu_hw_events just
> for Krait purposes? Or we could use the upper 16 bits of the used_mask
> bitmap to hold the pmresr_used values? Sounds sort of hacky but it
> avoids adding another bitmap for every PMU user and there aren't any
> Krait CPUs with more than 5 counters anyway.
I'm fine with that approach, but a comment saying what we're doing with
those upper bits wouldn't go amiss.
> This is the diff for the latter version. I'll let the fuzzer run overnight.
Cheers,
Will
^ permalink raw reply
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jean-Francois Moine @ 2014-01-22 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122111953.238349a5@armhf>
On Wed, 22 Jan 2014 11:19:53 +0100
Jean-Francois Moine <moinejf@free.fr> wrote:
> As both I2S and S/PDIF may be used for HDMI output in the Cubox,
> I wrote a tda998x CODEC which gets the audio ports from the DT and
> dynamically sets these ports and the audio type (i2s / spdif) on audio
> streaming start. I have not submitted yet this codec and the associated
> changes in tda998x, because I am waiting for a first patch series on the
> tda998x to be applied
> (http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).
Sorry, the last patch request is
http://lists.freedesktop.org/archives/dri-devel/2014-January/052201.html
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* mutual exculsion between clk_prepare_enable /clk_disable_unprepare and clk_set_parent
From: Russell King - ARM Linux @ 2014-01-22 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFgnuDdOKxzFSDCBQTGw=p_t0CvKfjVEudttOCP_wrzyA2K1Og@mail.gmail.com>
On Wed, Jan 22, 2014 at 02:02:57PM +0800, Xiaoguang Chen wrote:
> Hi, Mike
>
> We met a issue between clk_prepare_enable /clk_disable_unprepare and
> clk_set_parent.
clk_prepare_enable/disable_unprepare are perfectly fine in themselves.
You're looking at the problem wrongly - because drivers can perfectly
well call clk_prepare() and clk_unprepare() themselves. There's no
requirement for the enable and prepare to be paired together under any
kind of lock.
> and if below condition occurs, there will be problem
>
> thread1 thread 2
> call clk_disable_unprepare
Okay, if we're calling clk_disable_unprepare(), then the clock
must already have been prepared and enabled - which means that
the current parent is already prepared and enabled.
> 1) clk_disable
> get enable lock
> ...............
> release enable lock
This may result in the parent being disabled too.
>
> call clk_set_parent
> get prepare lock
> set clock's
> parent to another parent
At this point, the existing parent clock should be disabled if this
clock was enabled, and unprepared if this clock was prepared. The
new parent should be prepared and enabled as appropriate too so that
everything is kept balanced.
> release prepare lock
>
> 2) clk_unprepare
> get prepare lock
> unprepare parent clock <<--------------
> release prepare lock
And with the above guarantee - which is required in any case to make
reparenting safe - there's no problem here.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* Question: about wm8904's regulator consumer nodes
From: Yang, Wenyou @ 2014-01-22 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121181032.GI17314@sirena.org.uk>
Hi Mark,
> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Mark Brown
> Sent: Wednesday, January 22, 2014 2:11 AM
> To: Yang, Wenyou
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: Re: Question: about wm8904's regulator consumer nodes
>
> On Tue, Jan 21, 2014 at 07:10:24AM +0000, Yang, Wenyou wrote:
>
> > DCVDD-supply = <&vcc_1v8_reg>;
> > DBVDD-supply = <&vddana_reg>;
> > AVDD-supply = <&vcc_1v8_reg>;
> > CPVDD-supply = <&vcc_1v8_reg>;
> > MICVDD-supply =
> > <&vddana_reg>;
>
> > But the power of DCVDD, DBVDD, AVDD, CPVDD and MICVDD is not
> supplied by any regulators, not the above regulator nodes.
>
> > How do I deal with this case? Could you give me some advice?
>
> You should set up the supplies to point to whatever regulator is
> supplying the power. If there are supplies on the board which are
> generated using fixed voltage regulators then you should register those
> using the fixed regulator driver. Recent kernels are more tolerant of
> missing supplies but it's still better to be explicit if you can be.
Thank a lot for your answer.
Best Regards,
Wenyou Yang
^ permalink raw reply
* [PATCH v6 0/3] AArch64: KGDB support
From: Will Deacon @ 2014-01-22 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6tn4SJ4BjDGBNwH_8dGt82yHeAVyLzP+97rb8FDJdZSYQ@mail.gmail.com>
On Wed, Jan 22, 2014 at 07:50:46AM +0000, Vijay Kilari wrote:
> On Wed, Jan 22, 2014 at 10:01 AM, Vijay Kilari <vijay.kilari@gmail.com> wrote:
> >>> On Mon, Jan 20, 2014 at 3:53 PM, Will Deacon <will.deacon@arm.com> wrote:
> >> That's a good point: I think we wait until our first exception before they
> >> are unmasked. Perhaps we should:
> >>
> >> (1) Move local_dbg_{save,restore} from debug-monitors.h into irqflags.h
>
> local_dbg_save is setting bit #8 it should be bit #9?
>
> #define local_dbg_save(flags)
> \
> do {
> \
> typecheck(unsigned long, flags);
> \
> asm volatile(
> \
> "mrs %0, daif //
> local_dbg_save\n" \
> "msr daifset, #8"
That uses daifset, so #8 is bit 3 which is D.
> >> (2) Add local_dbg_enable/local_dbg_disable macros
> >> (3) Add a call to local_dbg_enable in the clear_os_lock function after the
> >> isb().
> >>
> >> Does that work for you?
> >
> > Yes, only after first exception occurs the PSTATE.D is unmasked.
> >
> > I have patched (temp) as below and now KGDB boot tests pass
> >
> > diff --git a/arch/arm64/include/asm/debug-monitors.h
> > b/arch/arm64/include/asm/debug-monitors.h
> > index aff3a76..ea2bc46 100644
> > --- a/arch/arm64/include/asm/debug-monitors.h
> > +++ b/arch/arm64/include/asm/debug-monitors.h
> > @@ -64,6 +111,24 @@ struct task_struct;
> >
> > #define DBG_ARCH_ID_RESERVED 0 /* In case of ptrace ABI updates. */
> >
> > +#define local_dbg_enable()
> > \
> > + do {
> > \
> > + asm volatile(
> > \
> > + "msr daifclr, #9 //
I think this is going to unmask fiq as well...
Will
^ permalink raw reply
* [PATCH REPOST 1/5] ARM: kvm: replace push and pop with stdmb and ldmia instrs to enable assembler.h inclusion
From: Will Deacon @ 2014-01-22 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA3XUr3rpEBCWbE0HGu14qgGsmt6J21D_yDeK2nFvK6_-cjPag@mail.gmail.com>
[Adding Nico, as the author of the push/pull macros. Background is that kvm
is using push to store to the stack and would now like to include assembler.h]
On Wed, Jan 22, 2014 at 06:41:09AM +0000, Victor Kamensky wrote:
> On 21 January 2014 01:58, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > How about trying this alternative approach:
> >
> > It looks like all the users of the push/pop macros are located in
> > arch/arm/lib (mostly checksumming code). Can't we move these macros to a
> > separate include file and leave the code that uses push/pop (as defined
> > by the assembler) alone?
>
> Marc, personally I am OK with such proposal. I was considering something
> along these lines as one of the options. It works for me both ways. If
> others agree I am happy to recode it as your suggested. I choose
> proposed above patch because kvm arm code came after push and pop
> defines were introduced in asm/assembler.h and used in other places.
> I am OK either way. I agree that use of push and pop as define names
> seems a bit unfortunate, but I don't have any historic visibility here
>
> Russell, Dave, Will, do you have any opinion on Marc's proposal to
> fix this issue?
I'm perfectly fine with moving those macros into a lib/-local header file.
An alternative is renaming push/pull to something like lspush and lspull
and updating the files under lib.
Will
^ permalink raw reply
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jean-Francois Moine @ 2014-01-22 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DF8D60.9020505@ti.com>
On Wed, 22 Jan 2014 11:20:32 +0200
Jyri Sarha <jsarha@ti.com> wrote:
> On 01/15/2014 05:51 PM, Jean-Francois Moine wrote:
> > On Wed, 15 Jan 2014 13:27:21 +0200
> > Jyri Sarha <jsarha@ti.com> wrote:
> >
> >> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> >> register statically to a value that works only with 4 byte samples.
> >> According to my tests it is possible to support 3 and 2 byte samples too
> >> by changing the CTS_N register value, but I am not sure if the
> >> configuration can be changed on the fly. My data sheet of the nxp chip
> >> is very vague about the register definitions, but I suppose the register
> >> configures some clock divider on the chip. HDMI supports only upto 24bit
> >> audio and the data sheet states that any extraneous least significant
> >> bits are ignored.
> >
> > In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
> > not set).
> >
> > Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
> > formats are working well with I2S input at any rate.
> >
>
> Could you refer the kernel version (main line?) and the involved ASoC
> drivers so could take I a look if there is something I could do differently?
Both drivers are in the kernel main line.
The ASoC is in sound/soc/kirkwood/. kirkwood-i2s.c defines the DAIs I2S
and S/PDIF outputs.
As both I2S and S/PDIF may be used for HDMI output in the Cubox,
I wrote a tda998x CODEC which gets the audio ports from the DT and
dynamically sets these ports and the audio type (i2s / spdif) on audio
streaming start. I have not submitted yet this codec and the associated
changes in tda998x, because I am waiting for a first patch series on the
tda998x to be applied
(http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Linus Walleij @ 2014-01-22 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5OOx8LgGVN0GFsa5-f=h1kasJVz4r0CfBXdXhK0F8iQAQ@mail.gmail.com>
On Thu, Jan 16, 2014 at 1:02 PM, Jean-Jacques Hiblot
<jjhiblot@traphandler.com> wrote:
> Linus,
> the root of the issue is the fact that a GPIO can't be requested
> twice. But IMO it's safe for a single device to request it more than
> once and use it for different purposes (irq and electrical signal
> value). Maybe we can rework the GPIO request to include this ownership
> information. I can post a draft implementation for this if you think
> it's worthwhile.
You are right and actually Jean-Christophe's patch is a good
start.
You also need to use the gpio_lock_as_irq() API as shown in
other patches to the subsystem e.g. this.
commit eb7cce1ea96b6399672abce787598f6e7a4352c3
Also check my other mail in this thread.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 2/2] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
From: Kishon Vijay Abraham I @ 2014-01-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DF7A78.5030700@ti.com>
On Wednesday 22 January 2014 01:29 PM, Roger Quadros wrote:
> On 01/22/2014 08:04 AM, Vivek Gautam wrote:
>> Hi,
>>
>>
>> On Tue, Jan 21, 2014 at 7:30 PM, Roger Quadros <rogerq@ti.com> wrote:
>>> Hi Kishon,
>>>
>>> On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
>>>> Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
>>>> power_on and power_off the following APIs are used phy_init(), phy_exit(),
>>>> phy_power_on() and phy_power_off().
>>>>
>>>> However using the old USB phy library wont be removed till the PHYs of all
>>>> other SoC's using dwc3 core is adapted to the Generic PHY Framework.
>>>>
>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>> ---
>>>> Changes from v3:
>>>> * avoided using quirks
>>>>
>>>> Documentation/devicetree/bindings/usb/dwc3.txt | 6 ++-
>>>> drivers/usb/dwc3/core.c | 60 ++++++++++++++++++++++++
>>>> drivers/usb/dwc3/core.h | 7 +++
>>>> 3 files changed, 71 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> index e807635..471366d 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> @@ -6,11 +6,13 @@ Required properties:
>>>> - compatible: must be "snps,dwc3"
>>>> - reg : Address and length of the register set for the device
>>>> - interrupts: Interrupts used by the dwc3 controller.
>>>> +
>>>> +Optional properties:
>>>> - usb-phy : array of phandle for the PHY device. The first element
>>>> in the array is expected to be a handle to the USB2/HS PHY and
>>>> the second element is expected to be a handle to the USB3/SS PHY
>>>> -
>>>> -Optional properties:
>>>> + - phys: from the *Generic PHY* bindings
>>>> + - phy-names: from the *Generic PHY* bindings
>>>> - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
>>>>
>>>> This is usually a subnode to DWC3 glue to which it is connected.
>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>> index e009d4e..036d589 100644
>>>> --- a/drivers/usb/dwc3/core.c
>>>> +++ b/drivers/usb/dwc3/core.c
>>>> @@ -82,6 +82,11 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
>>>>
>>>> usb_phy_init(dwc->usb2_phy);
>>>> usb_phy_init(dwc->usb3_phy);
>>>> + if (dwc->usb2_generic_phy)
>>>> + phy_init(dwc->usb2_generic_phy);
>>>
>>> What if phy_init() fails? You need to report and fail. Same applies for all PHY apis in this patch.
>>>
>>>> + if (dwc->usb3_generic_phy)
>>>> + phy_init(dwc->usb3_generic_phy);
>>>> +
>>>> mdelay(100);
>>>>
>>>> /* Clear USB3 PHY reset */
>>>> @@ -343,6 +348,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
>>>> {
>>>> usb_phy_shutdown(dwc->usb2_phy);
>>>> usb_phy_shutdown(dwc->usb3_phy);
>>>> + if (dwc->usb2_generic_phy)
>>>> + phy_exit(dwc->usb2_generic_phy);
>>>> + if (dwc->usb3_generic_phy)
>>>> + phy_exit(dwc->usb3_generic_phy);
>>>> +
>>>> }
>>>>
>>>> #define DWC3_ALIGN_MASK (16 - 1)
>>>> @@ -433,6 +443,32 @@ static int dwc3_probe(struct platform_device *pdev)
>>>> }
>>>> }
>>>>
>>>> + dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy");
>>>> + if (IS_ERR(dwc->usb2_generic_phy)) {
>>>> + ret = PTR_ERR(dwc->usb2_generic_phy);
>>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>>> + dwc->usb2_generic_phy = NULL;
>>>> + } else if (ret == -EPROBE_DEFER) {
>>>> + return ret;
>>>> + } else {
>>>> + dev_err(dev, "no usb2 phy configured\n");
>>>> + return ret;
>>>> + }
>>>> + }
>>>> +
>>>> + dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy");
>>>> + if (IS_ERR(dwc->usb3_generic_phy)) {
>>>> + ret = PTR_ERR(dwc->usb3_generic_phy);
>>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>>> + dwc->usb3_generic_phy = NULL;
>>>> + } else if (ret == -EPROBE_DEFER) {
>>>> + return ret;
>>>> + } else {
>>>> + dev_err(dev, "no usb3 phy configured\n");
>>>> + return ret;
>>>> + }
>>>> + }
>>>> +
>>>> dwc->xhci_resources[0].start = res->start;
>>>> dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
>>>> DWC3_XHCI_REGS_END;
>>>> @@ -482,6 +518,11 @@ static int dwc3_probe(struct platform_device *pdev)
>>>> usb_phy_set_suspend(dwc->usb2_phy, 0);
>>>> usb_phy_set_suspend(dwc->usb3_phy, 0);
>>>>
>>>> + if (dwc->usb2_generic_phy)
>>>> + phy_power_on(dwc->usb2_generic_phy);
>>>> + if (dwc->usb3_generic_phy)
>>>> + phy_power_on(dwc->usb3_generic_phy);
>>>> +
>>>
>>> Is it OK to power on the phy before phy_init()?
>>
>> Isn't phy_init() being done before phy_power_on() in the
>> core_soft_reset() in this patch ?
>> Isn't that what you want here ?
>>
>>>
>>> I suggest to move phy_init() from core_soft_reset() to here, just before phy_power_on().
>>
>> core_soft_reset() is called before phy_power_on() itself from
>> dwc3_core_init(), right ?
>> will moving the phy_inti() here make nay difference ?
>
> You are right. This part is fine then.
Yeah.. it was fixed in one of the earlier patches which got merged.
commit 3088f1085d1c08f31f02db26796555a66cdf7ca1
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date: Mon Nov 25 15:31:21 2013 +0530
usb: dwc3: invoke phy_resume after phy_init
usb_phy_set_suspend(phy, 0) is called before usb_phy_init. Fix it.
Reported-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Cheers,
Kishon
>
> cheers,
> -roger
>
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Linus Walleij @ 2014-01-22 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6C545.6080402@atmel.com>
On Wed, Jan 15, 2014 at 6:28 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> On 13/01/2014 11:35, boris brezillon :
>> You should only request it as a GPIO and then use gpio_to_irq to get the
>> related IRQ.
>> Because what is done here, is to solve the case where only the irq
>> is request, and in this specific case we need to request the pin as a
>> GPIO.
>
> Yes, this is what we do.
>
> It seems simple and obvious to me, but some may say that "you shall not
> do that, it is horrible!". Well... I always tend to choose a solution
> that works. It is one of my weaknesses, I admit ;-)
>
> Linus W. any advice on this, before we hit again one of those infinite
> threads that leads no progress at all?
So we recently established that it is actually OK for any IRQ
consumer to request an IRQ from any irq_chip no matter if
that is a combined GPIO+IRQ driver. This was concluded after
a long discussion involving several parties.
gpio_to_irq() is just a convenience function and should not be
relied upon to have been called before the IRQ is used.
The basic premise is that gpio_chip and irq_chip are
orthogonal, and offering their services independent of each
other.
Especially in the device tree use case it is very hard to
dictate that a certain semantic need to be followed to use
a certain interrupt-controller to have dependencies to a
certain gpio-controller. So they need to be orthogonal.
First step is: always prepare the hardware and make it
ready for action in respective callbacks from the gpio_chip API
and irq_chip API. Do not rely on gpio_to_irq() having been
called first anymore.
This leads to ambiguities that we need to solve: if there is
competition inside the subsystem which side is using
the resource (a certain GPIO line and register for example)
it needs to deny certain operations and keep track of usage
inside of the gpiolib subsystem.
We have added a new API to help with this situation:
gpio_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
gpio_unlock_as_irq(struct gpio_chip *chip,
unsigned int offset)
These should be called from the irq_chip startup() and
.shutdown() callbacks to flag that the line is now in use by
an IRQ. For example the GPIOlib core will deny the line to
be set as output after this.
If we need more infrastructure to help with this, I'm game.
Clear as mud? ;-)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Linus Walleij @ 2014-01-22 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKFfAvSPYLmvWV5jjT-peZFJ8sJ2bbh4F=JAYoWLhjZpA@mail.gmail.com>
On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> The good (or bad, rather) thing about DT is that we can do whatever we
> please with the new bindings: decide which name or which index
> (doesn't matter here) a GPIO should have. However we don't have this
> control over ACPI, where nothing guarantees that the same index will
> be used for the same GPIO function.
It's not like ACPI will impose some tables on us and expect us to
use them as-is no matter how crazy they are. Then indeed the whole
idea of unifying ACPI and DT accessors would be moot and it would
only work by mistake or as a good joke.
The situation with ACPI is just like with DT, it is assumed that the
author of these tables also look at the Linux kernel drivers to figure
out what argument goes where and we can influence them.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Linus Walleij @ 2014-01-22 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKFfAvSPYLmvWV5jjT-peZFJ8sJ2bbh4F=JAYoWLhjZpA@mail.gmail.com>
On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Tue, Jan 21, 2014 at 9:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 21 January 2014, Linus Walleij wrote:
>>> As discussed earlier in this thread I'm not sure the con_id is
>>> suitable for labelling GPIOs. It'd be better to have a proper name
>>> specified in DT/ACPI instead.
>>
>> +1
>
> I wonder why you guys prefer to have the name defined in the GPIO
> mapping. Having the driver decide the label makes it easier to look up
> which GPIO does what in debugfs, whereas nothing prevents people to
> name GPIOs whatever inadequate name they want in the device DT node.
> What am I overlooking here?
The proper name of a GPIO does not come from the driver but from the
usecase, i.e. often the name of the rail on the board where it is used.
Remember GPIO are per definition general purpose, they cannot get
any clever names from the driver. They would just be named
"chip-foo-gpio0" thru "chip-foo-gpioN" if the driver was to name them.
Using the rail name on the board is way more useful. A GPIO line
named "HAL_SENSOR" or "MMC_CD" is actually telling us what
that line is used for.
But such names can only come from a DT or ACPI table that has
knowledge of how the GPIO is used on a certain system/board and
not just from the driver.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 05/15] watchdog: orion: Make RSTOUT register a separate resource
From: Arnd Bergmann @ 2014-01-22 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121233321.GR18269@obsidianresearch.com>
On Tuesday 21 January 2014 16:33:21 Jason Gunthorpe wrote:
> On Tue, Jan 21, 2014 at 06:12:31AM -0300, Ezequiel Garcia wrote:
> > In order to support other SoC, it's required to distinguish
> > the 'control' timer register, from the 'rstout' register
> > that enables system reset on watchdog expiration.
>
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + if (!res)
> > + return -ENODEV;
> ^^^^^^^^^^^^^^^^^^^^^^
>
> This change seems to break compatibility with existing DT files that
> have only a single entry in reg?
>
> Can the value be defaulted some how if missing?
I think this is a direct consequence of the attempt to remove the
header file dependency, since the RSTOUTn_MASK macro is defined
in mach/bridge-regs.h.
I don't see a good way out that would preserve backwards compatibility,
other than hardcoding the physical address in the driver, which seems
just as bad as breaking compatibility. That said, it is always the
same constant (0xf1000000 + 0x20000 + 0x0108) on Dove, Kirkwood and
Orion5x (not on mv78xx0, but that doesn't use the wdt), so hardcoding
a fallback would technically work, but we should print a fat warning at
boot time if we actually fall back to that.
Arnd
^ 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