* [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Nicolas Pitre @ 2014-01-30 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA5720.8010000@linaro.org>
On Thu, 30 Jan 2014, Daniel Lezcano wrote:
> On 01/30/2014 06:28 AM, Nicolas Pitre wrote:
> > On Thu, 30 Jan 2014, Preeti U Murthy wrote:
> >
> > > Hi Nicolas,
> > >
> > > On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
> > > > On Wed, 29 Jan 2014, Nicolas Pitre wrote:
> > > >
> > > > > In order to integrate cpuidle with the scheduler, we must have a
> > > > > better
> > > > > proximity in the core code with what cpuidle is doing and not delegate
> > > > > such interaction to arch code.
> > > > >
> > > > > Architectures implementing arch_cpu_idle() should simply enter
> > > > > a cheap idle mode in the absence of a proper cpuidle driver.
> > > > >
> > > > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > > > Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > > >
> > > > As mentioned in my reply to Olof's comment on patch #5/6, here's a new
> > > > version of this patch adding the safety local_irq_enable() to the core
> > > > code.
> > > >
> > > > ----- >8
> > > >
> > > > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> > > > Subject: idle: move the cpuidle entry point to the generic idle loop
> > > >
> > > > In order to integrate cpuidle with the scheduler, we must have a better
> > > > proximity in the core code with what cpuidle is doing and not delegate
> > > > such interaction to arch code.
> > > >
> > > > Architectures implementing arch_cpu_idle() should simply enter
> > > > a cheap idle mode in the absence of a proper cpuidle driver.
> > > >
> > > > In both cases i.e. whether it is a cpuidle driver or the default
> > > > arch_cpu_idle(), the calling convention expects IRQs to be disabled
> > > > on entry and enabled on exit. There is a warning in place already but
> > > > let's add a forced IRQ enable here as well. This will allow for
> > > > removing the forced IRQ enable some implementations do locally and
> > >
> > > Why would this patch allow for removing the forced IRQ enable that are
> > > being done on some archs in arch_cpu_idle()? Isn't this patch expecting
> > > the default arch_cpu_idle() to have re-enabled the interrupts after
> > > exiting from the default idle state? Its supposed to only catch faulty
> > > cpuidle drivers that haven't enabled IRQs on exit from idle state but
> > > are expected to have done so, isn't it?
> >
> > Exact. However x86 currently does this:
> >
> > if (cpuidle_idle_call())
> > x86_idle();
> > else
> > local_irq_enable();
> >
> > So whenever cpuidle_idle_call() is successful then IRQs are
> > unconditionally enabled whether or not the underlying cpuidle driver has
> > properly done it or not. And the reason is that some of the x86 cpuidle
> > do fail to enable IRQs before returning.
> >
> > So the idea is to get rid of this unconditional IRQ enabling and let the
> > core issue a warning instead (as well as enabling IRQs to allow the
> > system to run).
>
> But what I don't get with your comment is the local_irq_enable is done from
> the cpuidle common framework in 'cpuidle_enter_state' it is not done from the
> arch specific backend cpuidle driver.
Oh well... This certainly means we'll have to clean this mess as some
drivers do it on their own while some others don't. Some drivers also
loop on !need_resched() while some others simply return on the first
interrupt.
> So the code above could be:
>
> if (cpuidle_idle_call())
> x86_idle();
>
> without the else section, this local_irq_enable is pointless. Or may be I
> missed something ?
A later patch removes it anyway. But if it is really necessary to
enable interrupts then the core will do it but with a warning now.
Nicolas
^ permalink raw reply
* Root NFS panicing on Linus' tip (Re: NFS client broken in Linus' tip)
From: Russell King - ARM Linux @ 2014-01-30 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130151703.GA20594@localhost>
On Thu, Jan 30, 2014 at 12:17:04PM -0300, Ezequiel Garcia wrote:
> Hi Russell, Trond:
>
> On Thu, Jan 30, 2014 at 02:08:34PM +0000, Russell King - ARM Linux wrote:
> > I just booted Linus' tip (plus a few other patches to imx-drm and imx
> > code), and stumbled into this interesting scenario:
> >
> [..]
>
> > CONFIG_NFS_FS=y
> > CONFIG_NFS_V2=y
> > CONFIG_NFS_V3=y
> > CONFIG_NFS_V3_ACL=y
>
> Just came across another issue, but a bit more problematic, as my
> kernel (Linus' tip as well) panics, after mounting the rootfs:
>
> IP-Config: Complete:
> device=eth0, hwaddr=00:50:43:50:1c:15, ipaddr=192.168.0.159, mask=255.255.255.0, gw=192.168.0.1
> host=develboard, domain=, nis-domain=(none)
> bootserver=192.168.0.45, rootserver=192.168.0.45, rootpath=
> VFS: Mounted root (nfs filesystem) on device 0:11.
> devtmpfs: mounted
> Freeing unused kernel memory: 136K (c0465000 - c0487000)
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c0004000
> [00000000] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.13.0-10094-g9b0cd30 #276
> task: ed839a40 ti: ed83a000 task.ti: ed83a000
> PC is at xattr_resolve_name+0x14/0x94
> LR is at generic_getxattr+0x2c/0x64
> pc : [<c00a7ab0>] lr : [<c00a7b5c>] psr: a0000113
> sp : ed83be5c ip : ed83be74 fp : ed10ebc0
> r10: ed83a000 r9 : ed43d980 r8 : ed81b800
> r7 : c034dad8 r6 : 00000000 r5 : c03f3dcc r4 : ed43d980
> r3 : 00000014 r2 : ed83be8c r1 : ed83be74 r0 : 00000000
> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c53c7d Table: 00004059 DAC: 00000015
> Process swapper (pid: 1, stack limit = 0xed83a238)
> Stack: (0xed83be5c to 0xed83c000)
> be40: ed43d980
> be60: 00000014 ed83be8c 00000000 00000000 c04bc22c c03f3dcc ed83bf14 ed43f340
> be80: ed43d980 c01115cc 00000000 00000041 c04bba6c 00000000 00000000 002040d0
> bea0: ed81bc00 ed10ebc0 ed81bc30 c01116f8 00000000 000004d0 ed8172d0 ed43d980
> bec0: 45878fd4 00000007 bfe01007 ef7f8fc0 c04bba6c ed43d6d8 c04bba6c 00000101
> bee0: 00000000 ed809fd0 ed809fc0 ed809f50 ed809f40 00000000 edb045d8 c0078bcc
> bf00: ed0e5dc0 edb045d8 00000000 bf000000 ed0e5dc0 00000000 00000000 00000000
> bf20: 00000000 00000000 bf000000 ed10ebc0 ed0e5dc0 00000001 edb045d8 c04926d0
> bf40: ed83a000 c0492758 ed10ebc0 c008fc54 00000001 ed0e5dc0 00000002 c0090cec
> bf60: c03ec85c ed0e5df4 00000000 ed839c00 c0487000 c04bcec0 c03e4f08 00000000
> bf80: 00000000 00000000 00000000 00000000 00000000 c00086a8 00000000 c04bcec0
> bfa0: c0344f5c c0345004 00000000 c000e398 00000000 00000000 00000000 00000000
> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c00a7ab0>] (xattr_resolve_name) from [<00000000>] ( (null))
> Code: e1a06000 e5915000 e3550000 0a00001d (e5900000)
> ---[ end trace 15c15b4afa9eff90 ]---
> swapper (1) used greatest stack depth: 5104 bytes left
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> Adding a little hack, and could produce a better strack trace.
> See the diff and the stack trace below:
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 3377dff..bd2b173 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -740,6 +740,10 @@ xattr_resolve_name(const struct xattr_handler **handlers, const char **name)
>
> if (!*name)
> return NULL;
> + if(!handlers) {
> + dump_stack();
> + panic("ouch");
> + }
>
> for_each_xattr_handler(handlers, handler) {
> const char *n = strcmp_prefix(*name, handler->prefix);
>
> CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.13.0-10094-g9b0cd30-dirty #279
> [<c0012f40>] (unwind_backtrace) from [<c00107b8>] (show_stack+0x10/0x14)
> [<c00107b8>] (show_stack) from [<c00a8160>] (xattr_resolve_name+0x9c/0xa8)
> [<c00a8160>] (xattr_resolve_name) from [<c00a8274>] (generic_getxattr+0x2c/0x64)
> [<c00a8274>] (generic_getxattr) from [<c01115e0>] (get_vfs_caps_from_disk+0x4c/0xf4)
> [<c01115e0>] (get_vfs_caps_from_disk) from [<c011170c>] (cap_bprm_set_creds+0x84/0x408)
> [<c011170c>] (cap_bprm_set_creds) from [<c008fc54>] (prepare_binprm+0x80/0x11c)
> [<c008fc54>] (prepare_binprm) from [<c0090cec>] (do_execve+0x33c/0x46c)
> [<c0090cec>] (do_execve) from [<c00086a8>] (try_to_run_init_process+0x1c/0x50)
> [<c00086a8>] (try_to_run_init_process) from [<c0345024>] (kernel_init+0xa8/0x110)
> [<c0345024>] (kernel_init) from [<c000e398>] (ret_from_fork+0x14/0x3c)
> Kernel panic - not syncing: ouch
>
> FWIW, here's my piece of NFS config:
>
> CONFIG_NFS_FS=y
> CONFIG_NFS_V2=y
> CONFIG_NFS_V3=y
> # CONFIG_NFS_V3_ACL is not set
> # CONFIG_NFS_V4 is not set
> # CONFIG_NFS_SWAP is not set
> CONFIG_ROOT_NFS=y
> # CONFIG_NFSD is not set
> CONFIG_LOCKD=y
> CONFIG_LOCKD_V4=y
> CONFIG_NFS_COMMON=y
> CONFIG_SUNRPC=y
>
> > I think it's down to this:
> >
> > commit 013cdf1088d7235da9477a2375654921d9b9ba9f
> > Author: Christoph Hellwig <hch@infradead.org>
> > Date: Fri Dec 20 05:16:53 2013 -0800
> >
> > nfs: use generic posix ACL infrastructure for v3 Posix ACLs
> >
> > This causes a small behaviour change in that we don't bother to set
> > ACLs on file creation if the mode bit can express the access permissions
> > fully, and thus behaving identical to local filesystems.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>
> And also here, reverting the above seem to fix the panic.
Reverting this commit with NFS3 ACLs enabled also fixes the problems I
reported.
--
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
* [GIT PULL] Xilinx Zynq dt fixes for v3.14
From: Michal Simek @ 2014-01-30 16:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi guys,
please consider to queue this patch to 3.14 because it enables Arasan
SDHCI driver which has been merged to the tree. It took for a while
to get it to the mainline that's why I didn't push this patch
in regular arm-soc merge window. I was talking about it
with Kevin some weeks ago.
There will be one more patch which I have discussed with Russell but
I will send it out for reviewed first.
https://lkml.org/lkml/2014/1/27/212
Thanks,
Michal
The following changes since commit 9b0cd304f26b9fca140de15deeac2bf357d1f388:
Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux (2014-01-29 20:49:12 -0800)
are available in the git repository at:
git://git.xilinx.com/linux-xlnx.git tags/zynq-dt-fixes-for-3.14
for you to fetch changes up to b1d30fb5b8618e69195fb074b89c204cb1bb2262:
arm: dt: zynq: Add SDHCI nodes (2014-01-30 12:28:03 +0100)
----------------------------------------------------------------
arm: Xilinx Zynq DT fixes for v3.14
- Enable Arasan SDHCI driver
----------------------------------------------------------------
Soren Brinkmann (1):
arm: dt: zynq: Add SDHCI nodes
arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/zynq-zc702.dts | 4 ++++
arch/arm/boot/dts/zynq-zc706.dts | 4 ++++
arch/arm/boot/dts/zynq-zed.dts | 4 ++++
4 files changed, 32 insertions(+)
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140130/e3b3b418/attachment.sig>
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-01-30 16:11 UTC (permalink / raw)
To: linux-arm-kernel
mach-virt has existed for a while but it is not written down what it actually
consists of. Although it seems a bit unusual to document a binding for an
entire platform since mach-virt is entirely virtual it is helpful to have
something to refer to in the absence of a single concrete implementation.
I've done my best to capture the requirements based on the git log and my
memory/understanding.
While here remove the xenvm dts example, the Xen tools will now build a
suitable mach-virt compatible dts when launching the guest.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
I'm not sure which tree this sort of thing should go though, sorry for the
huge Cc.
---
.../devicetree/bindings/arm/mach-virt.txt | 32 ++++++++
arch/arm/boot/dts/xenvm-4.2.dts | 81 --------------------
2 files changed, 32 insertions(+), 81 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt b/Documentation/devicetree/bindings/arm/mach-virt.txt
new file mode 100644
index 0000000..562bcda
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
@@ -0,0 +1,32 @@
+* Mach-virt "Dummy Virtual Machine" platform
+
+"mach-virt" is the smallest, dumbest platform possible, to be used as
+a guest for Xen, KVM and other hypervisors. It has no
+properties/functionality of its own and is driven entirely by device
+tree.
+
+This document defines the requirements for such a platform.
+
+* Required properties:
+
+- compatible: should be one of:
+ "linux,dummy-virt"
+ "xen,xenvm"
+
+In addition to the standard nodes (chosen, cpus, memory etc) the
+platform is required to provide certain other basic functionality
+which must be described in the device tree:
+
+ The platform must provide an ARM Generic Interrupt Controller
+ (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
+
+ The platform must provide ARM architected timer, defined in
+ Documentation/devicetree/bindings/arm/arch_timer.txt.
+
+ If the platform is SMP then it must provide the Power State
+ Coordination Interface (PSCI) described in
+ Documentation/devicetree/bindings/arm/psci.txt.
+
+The platform may also provide hypervisor specific functionality
+(e.g. PV I/O), if it does so then this functionality must be
+discoverable (directly or indirectly) via device tree.
diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
deleted file mode 100644
index 3369151..0000000
--- a/arch/arm/boot/dts/xenvm-4.2.dts
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- * Xen Virtual Machine for unprivileged guests
- *
- * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
- * Cortex-A15 MPCore (V2P-CA15)
- *
- */
-
-/dts-v1/;
-
-/ {
- model = "XENVM-4.2";
- compatible = "xen,xenvm-4.2", "xen,xenvm";
- interrupt-parent = <&gic>;
- #address-cells = <2>;
- #size-cells = <2>;
-
- chosen {
- /* this field is going to be adjusted by the hypervisor */
- bootargs = "console=hvc0 root=/dev/xvda";
- };
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu at 0 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0>;
- };
-
- cpu at 1 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <1>;
- };
- };
-
- psci {
- compatible = "arm,psci";
- method = "hvc";
- cpu_off = <1>;
- cpu_on = <2>;
- };
-
- memory at 80000000 {
- device_type = "memory";
- /* this field is going to be adjusted by the hypervisor */
- reg = <0 0x80000000 0 0x08000000>;
- };
-
- gic: interrupt-controller at 2c001000 {
- compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
- #interrupt-cells = <3>;
- #address-cells = <0>;
- interrupt-controller;
- reg = <0 0x2c001000 0 0x1000>,
- <0 0x2c002000 0 0x100>;
- };
-
- timer {
- compatible = "arm,armv7-timer";
- interrupts = <1 13 0xf08>,
- <1 14 0xf08>,
- <1 11 0xf08>,
- <1 10 0xf08>;
- };
-
- hypervisor {
- compatible = "xen,xen-4.2", "xen,xen";
- /* this field is going to be adjusted by the hypervisor */
- reg = <0 0xb0000000 0 0x20000>;
- /* this field is going to be adjusted by the hypervisor */
- interrupts = <1 15 0xf08>;
- };
-
- motherboard {
- arm,v2m-memory-map = "rs1";
- };
-};
--
1.7.10.4
^ permalink raw reply related
* [PATCH V3 0/5] ARM CoreSight: ETM: Fix a vmalloc/vfree failure and enhance tracing control
From: Adrien Vergé @ 2014-01-30 16:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
Different ARM users have shown their interest in this patch, so I made
a third version that is compatible with PID namespaces.
Mainly:
- It fixes a "vmalloc: allocation failure: 0 bytes" when reading an
ETB buffer that is empty.
- It extends current support of CoreSight ETM, that is currently
very limited.
ETM is a dedicated hardware that provides program tracing, a
cycle-precise and low-overhead solution that software tools such as
'perf record' cannot provide.
Usage of ETM tracing facility is presently limited to start and stop
tracing. This set of patches enables management of address combinations
and PIDs that trigger tracing, thus allowing to trace specific
functions and processes. ETM management was done via sysfs entries
(trace_info, trace_running...), this code adds trace_addrrange and
trace_pid to let the user read/write custom values.
Changes in V2:
- Fix a vmalloc/vfree failure when ETB is empty
- Use device attributes rather than raw kobjects
- Make PID_IN_CONTEXTIDR incompatible with PID_NS in Kconfig
- Use pid_t instead of long
Changes in V3:
- Support tracing processes by their PID in PID namespaces
- Reset PID_IN_CONTEXTIDR and PID_NS independent
This series of patches applies to v3.13.
Adrien Verg? (5):
ARM CoreSight: ETM: Fix a memory allocation failure
ARM CoreSight: ETM: Use device attributes
ARM CoreSight: ETM: Rename 'comparator' to 'address comparator'
ARM CoreSight: ETM: Add address control support
ARM CoreSight: ETM: Add PID control support
arch/arm/include/asm/hardware/coresight.h | 9 +-
arch/arm/kernel/etm.c | 257 ++++++++++++++++++++++++------
2 files changed, 216 insertions(+), 50 deletions(-)
--
1.8.5.3
^ permalink raw reply
* [PATCH V3 1/5] ARM CoreSight: ETM: Fix a memory allocation failure
From: Adrien Vergé @ 2014-01-30 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098270-8867-1-git-send-email-adrienverge@gmail.com>
When an application reads the ETB buffer too often, it can be empty.
In this case, it results in a "vmalloc: allocation failure: 0 bytes",
a backtrace in dmesg and a vfree on an incorrect address.
This patch allocates and frees the trace buffer only when necessary.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/kernel/etm.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 8ff0ecd..5192693 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -275,7 +275,7 @@ static ssize_t etb_read(struct file *file, char __user *data,
long length;
struct tracectx *t = file->private_data;
u32 first = 0;
- u32 *buf;
+ u32 *buf = NULL;
mutex_lock(&t->mutex);
@@ -293,12 +293,14 @@ static ssize_t etb_read(struct file *file, char __user *data,
etb_writel(t, first, ETBR_READADDR);
length = min(total * 4, (int)len);
- buf = vmalloc(length);
+ if (length != 0)
+ buf = vmalloc(length);
dev_dbg(t->dev, "ETB buffer length: %d\n", total);
dev_dbg(t->dev, "ETB status reg: %x\n", etb_readl(t, ETBR_STATUS));
- for (i = 0; i < length / 4; i++)
- buf[i] = etb_readl(t, ETBR_READMEM);
+ if (buf)
+ for (i = 0; i < length / 4; i++)
+ buf[i] = etb_readl(t, ETBR_READMEM);
/* the only way to deassert overflow bit in ETB status is this */
etb_writel(t, 1, ETBR_CTRL);
@@ -311,7 +313,8 @@ static ssize_t etb_read(struct file *file, char __user *data,
etb_lock(t);
length -= copy_to_user(data, buf, length);
- vfree(buf);
+ if (buf)
+ vfree(buf);
out:
mutex_unlock(&t->mutex);
--
1.8.5.3
^ permalink raw reply related
* [PATCH V3 2/5] ARM CoreSight: ETM: Use device attributes
From: Adrien Vergé @ 2014-01-30 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098270-8867-1-git-send-email-adrienverge@gmail.com>
Replace all kobjects attributes with device attributes.
User experience isn't changed since the same files are created in sysfs.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/kernel/etm.c | 48 +++++++++++++++++++++---------------------------
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 5192693..7a3ee66 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -433,15 +433,14 @@ static struct amba_driver etb_driver = {
};
/* use a sysfs file "trace_running" to start/stop tracing */
-static ssize_t trace_running_show(struct kobject *kobj,
- struct kobj_attribute *attr,
- char *buf)
+static ssize_t trace_running_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
return sprintf(buf, "%x\n", trace_isrunning(&tracer));
}
-static ssize_t trace_running_store(struct kobject *kobj,
- struct kobj_attribute *attr,
+static ssize_t trace_running_store(struct device *dev,
+ struct device_attribute *attr,
const char *buf, size_t n)
{
unsigned int value;
@@ -457,12 +456,11 @@ static ssize_t trace_running_store(struct kobject *kobj,
return ret ? : n;
}
-static struct kobj_attribute trace_running_attr =
- __ATTR(trace_running, 0644, trace_running_show, trace_running_store);
+DEVICE_ATTR(trace_running, S_IRUGO|S_IWUSR,
+ trace_running_show, trace_running_store);
-static ssize_t trace_info_show(struct kobject *kobj,
- struct kobj_attribute *attr,
- char *buf)
+static ssize_t trace_info_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
u32 etb_wa, etb_ra, etb_st, etb_fc, etm_ctrl, etm_st;
int datalen;
@@ -498,21 +496,19 @@ static ssize_t trace_info_show(struct kobject *kobj,
);
}
-static struct kobj_attribute trace_info_attr =
- __ATTR(trace_info, 0444, trace_info_show, NULL);
+DEVICE_ATTR(trace_info, S_IRUGO, trace_info_show, NULL);
-static ssize_t trace_mode_show(struct kobject *kobj,
- struct kobj_attribute *attr,
- char *buf)
+static ssize_t trace_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
return sprintf(buf, "%d %d\n",
!!(tracer.flags & TRACER_CYCLE_ACC),
tracer.etm_portsz);
}
-static ssize_t trace_mode_store(struct kobject *kobj,
- struct kobj_attribute *attr,
- const char *buf, size_t n)
+static ssize_t trace_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t n)
{
unsigned int cycacc, portsz;
@@ -531,8 +527,7 @@ static ssize_t trace_mode_store(struct kobject *kobj,
return n;
}
-static struct kobj_attribute trace_mode_attr =
- __ATTR(trace_mode, 0644, trace_mode_show, trace_mode_store);
+DEVICE_ATTR(trace_mode, S_IRUGO|S_IWUSR, trace_mode_show, trace_mode_store);
static int etm_probe(struct amba_device *dev, const struct amba_id *id)
{
@@ -571,17 +566,16 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
etm_writel(t, 0x440, ETMR_CTRL);
etm_lock(t);
- ret = sysfs_create_file(&dev->dev.kobj,
- &trace_running_attr.attr);
+ ret = device_create_file(&dev->dev, &dev_attr_trace_running);
if (ret)
goto out_unmap;
/* failing to create any of these two is not fatal */
- ret = sysfs_create_file(&dev->dev.kobj, &trace_info_attr.attr);
+ ret = device_create_file(&dev->dev, &dev_attr_trace_info);
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_info in sysfs\n");
- ret = sysfs_create_file(&dev->dev.kobj, &trace_mode_attr.attr);
+ ret = device_create_file(&dev->dev, &dev_attr_trace_mode);
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_mode in sysfs\n");
@@ -611,9 +605,9 @@ static int etm_remove(struct amba_device *dev)
amba_release_regions(dev);
- sysfs_remove_file(&dev->dev.kobj, &trace_running_attr.attr);
- sysfs_remove_file(&dev->dev.kobj, &trace_info_attr.attr);
- sysfs_remove_file(&dev->dev.kobj, &trace_mode_attr.attr);
+ device_remove_file(&dev->dev, &dev_attr_trace_running);
+ device_remove_file(&dev->dev, &dev_attr_trace_info);
+ device_remove_file(&dev->dev, &dev_attr_trace_mode);
return 0;
}
--
1.8.5.3
^ permalink raw reply related
* [PATCH V3 3/5] ARM CoreSight: ETM: Rename 'comparator' to 'address comparator'
From: Adrien Vergé @ 2014-01-30 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098270-8867-1-git-send-email-adrienverge@gmail.com>
Since there are different types of comparators, and other kinds will
be used (such as Context ID comparators), rename them properly.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/include/asm/hardware/coresight.h | 4 ++--
arch/arm/kernel/etm.c | 19 ++++++++++---------
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/hardware/coresight.h b/arch/arm/include/asm/hardware/coresight.h
index ad774f3..8c50cf6 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -95,8 +95,8 @@
#define ETMAAT_NSONLY (1 << 10)
#define ETMAAT_SONLY (2 << 10)
-#define ETMR_COMP_VAL(x) (0x40 + (x) * 4)
-#define ETMR_COMP_ACC_TYPE(x) (0x80 + (x) * 4)
+#define ETMR_ADDRCOMP_VAL(x) (0x40 + (x) * 4)
+#define ETMR_ADDRCOMP_ACC_TYPE(x) (0x80 + (x) * 4)
/* ETM status register, "ETM Architecture", 3.3.2 */
#define ETMR_STATUS (0x10)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 7a3ee66..b3e6713 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -39,7 +39,7 @@ struct tracectx {
void __iomem *etb_regs;
void __iomem *etm_regs;
unsigned long flags;
- int ncmppairs;
+ int naddrcmppairs;
int etm_portsz;
struct device *dev;
struct clk *emu_clk;
@@ -59,7 +59,7 @@ static int etm_setup_address_range(struct tracectx *t, int n,
u32 flags = ETMAAT_ARM | ETMAAT_IGNCONTEXTID | ETMAAT_NSONLY | \
ETMAAT_NOVALCMP;
- if (n < 1 || n > t->ncmppairs)
+ if (n < 1 || n > t->naddrcmppairs)
return -EINVAL;
/* comparators and ranges are numbered starting with 1 as opposed
@@ -72,12 +72,12 @@ static int etm_setup_address_range(struct tracectx *t, int n,
flags |= ETMAAT_IEXEC;
/* first comparator for the range */
- etm_writel(t, flags, ETMR_COMP_ACC_TYPE(n * 2));
- etm_writel(t, start, ETMR_COMP_VAL(n * 2));
+ etm_writel(t, flags, ETMR_ADDRCOMP_ACC_TYPE(n * 2));
+ etm_writel(t, start, ETMR_ADDRCOMP_VAL(n * 2));
/* second comparator is right next to it */
- etm_writel(t, flags, ETMR_COMP_ACC_TYPE(n * 2 + 1));
- etm_writel(t, end, ETMR_COMP_VAL(n * 2 + 1));
+ etm_writel(t, flags, ETMR_ADDRCOMP_ACC_TYPE(n * 2 + 1));
+ etm_writel(t, end, ETMR_ADDRCOMP_VAL(n * 2 + 1));
flags = exclude ? ETMTE_INCLEXCL : 0;
etm_writel(t, flags | (1 << n), ETMR_TRACEENCTRL);
@@ -478,7 +478,8 @@ static ssize_t trace_info_show(struct device *dev,
etm_st = etm_readl(&tracer, ETMR_STATUS);
etm_lock(&tracer);
- return sprintf(buf, "Trace buffer len: %d\nComparator pairs: %d\n"
+ return sprintf(buf, "Trace buffer len: %d\n"
+ "Addr comparator pairs: %d\n"
"ETBR_WRITEADDR:\t%08x\n"
"ETBR_READADDR:\t%08x\n"
"ETBR_STATUS:\t%08x\n"
@@ -486,7 +487,7 @@ static ssize_t trace_info_show(struct device *dev,
"ETMR_CTRL:\t%08x\n"
"ETMR_STATUS:\t%08x\n",
datalen,
- tracer.ncmppairs,
+ tracer.naddrcmppairs,
etb_wa,
etb_ra,
etb_st,
@@ -562,7 +563,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
/* dummy first read */
(void)etm_readl(&tracer, ETMMR_OSSRR);
- t->ncmppairs = etm_readl(t, ETMR_CONFCODE) & 0xf;
+ t->naddrcmppairs = etm_readl(t, ETMR_CONFCODE) & 0xf;
etm_writel(t, 0x440, ETMR_CTRL);
etm_lock(t);
--
1.8.5.3
^ permalink raw reply related
* [PATCH V3 4/5] ARM CoreSight: ETM: Add address control support
From: Adrien Vergé @ 2014-01-30 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098270-8867-1-git-send-email-adrienverge@gmail.com>
In the same manner as for enabling tracing, an entry is created
in sysfs to set the address range that triggers tracing.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/kernel/etm.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 49 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index b3e6713..fa42e32 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -44,6 +44,8 @@ struct tracectx {
struct device *dev;
struct clk *emu_clk;
struct mutex mutex;
+ unsigned long addrrange_start;
+ unsigned long addrrange_end;
};
static struct tracectx tracer;
@@ -53,6 +55,13 @@ static inline bool trace_isrunning(struct tracectx *t)
return !!(t->flags & TRACER_RUNNING);
}
+/*
+ * Setups ETM to trace only when:
+ * - address between start and end
+ * or address not between start and end (if exclude)
+ * - trace executed instructions
+ * or trace loads and stores (if data)
+ */
static int etm_setup_address_range(struct tracectx *t, int n,
unsigned long start, unsigned long end, int exclude, int data)
{
@@ -115,8 +124,8 @@ static int trace_start(struct tracectx *t)
return -EFAULT;
}
- etm_setup_address_range(t, 1, (unsigned long)_stext,
- (unsigned long)_etext, 0, 0);
+ etm_setup_address_range(t, 1, t->addrrange_start, t->addrrange_end,
+ 0, 0);
etm_writel(t, 0, ETMR_TRACEENCTRL2);
etm_writel(t, 0, ETMR_TRACESSCTRL);
etm_writel(t, 0x6f, ETMR_TRACEENEVT);
@@ -530,6 +539,36 @@ static ssize_t trace_mode_store(struct device *dev,
DEVICE_ATTR(trace_mode, S_IRUGO|S_IWUSR, trace_mode_show, trace_mode_store);
+static ssize_t trace_addrrange_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%08lx - %08lx\n", tracer.addrrange_start,
+ tracer.addrrange_end);
+}
+
+static ssize_t trace_addrrange_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ unsigned long start, end;
+
+ if (tracer.flags & TRACER_RUNNING)
+ return -EBUSY;
+
+ if (sscanf(buf, "%08lx - %08lx", &start, &end) != 2)
+ return -EINVAL;
+
+ mutex_lock(&tracer.mutex);
+ tracer.addrrange_start = start;
+ tracer.addrrange_end = end;
+ mutex_unlock(&tracer.mutex);
+
+ return n;
+}
+
+DEVICE_ATTR(trace_addrrange, S_IRUGO|S_IWUSR,
+ trace_addrrange_show, trace_addrrange_store);
+
static int etm_probe(struct amba_device *dev, const struct amba_id *id)
{
struct tracectx *t = &tracer;
@@ -557,6 +596,8 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
t->dev = &dev->dev;
t->flags = TRACER_CYCLE_ACC;
t->etm_portsz = 1;
+ t->addrrange_start = (unsigned long) _stext;
+ t->addrrange_end = (unsigned long) _etext;
etm_unlock(t);
(void)etm_readl(t, ETMMR_PDSR);
@@ -571,7 +612,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
goto out_unmap;
- /* failing to create any of these two is not fatal */
+ /* failing to create any of these three is not fatal */
ret = device_create_file(&dev->dev, &dev_attr_trace_info);
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_info in sysfs\n");
@@ -580,6 +621,10 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_mode in sysfs\n");
+ ret = device_create_file(&dev->dev, &dev_attr_trace_addrrange);
+ if (ret)
+ dev_dbg(&dev->dev, "Failed to create trace_addrrange in sysfs\n");
+
dev_dbg(t->dev, "ETM AMBA driver initialized.\n");
out:
@@ -609,6 +654,7 @@ static int etm_remove(struct amba_device *dev)
device_remove_file(&dev->dev, &dev_attr_trace_running);
device_remove_file(&dev->dev, &dev_attr_trace_info);
device_remove_file(&dev->dev, &dev_attr_trace_mode);
+ device_remove_file(&dev->dev, &dev_attr_trace_addrrange);
return 0;
}
--
1.8.5.3
^ permalink raw reply related
* [PATCH V3 5/5] ARM CoreSight: ETM: Add PID control support
From: Adrien Vergé @ 2014-01-30 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098270-8867-1-git-send-email-adrienverge@gmail.com>
In the same manner as for enabling tracing, an entry is created in
sysfs to set the PID that triggers tracing. This change is effective
only if CONFIG_PID_IN_CONTEXTIDR is set.
When using PID namespaces, the virtual PID given by the user is
converted to the globally unique ID (task_pid_nr) that is present
in the Context ID register.
Signed-off-by: Adrien Verg? <adrienverge@gmail.com>
---
arch/arm/include/asm/hardware/coresight.h | 5 ++
arch/arm/kernel/etm.c | 131 ++++++++++++++++++++++++++++--
2 files changed, 129 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/hardware/coresight.h b/arch/arm/include/asm/hardware/coresight.h
index 8c50cf6..2051af0 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -98,6 +98,11 @@
#define ETMR_ADDRCOMP_VAL(x) (0x40 + (x) * 4)
#define ETMR_ADDRCOMP_ACC_TYPE(x) (0x80 + (x) * 4)
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+#define ETMR_CTXIDCOMP_VAL(x) (0x1b0 + (x) * 4)
+#define ETMR_CTXIDCOMP_MASK (0x1bc)
+#endif
+
/* ETM status register, "ETM Architecture", 3.3.2 */
#define ETMR_STATUS (0x10)
#define ETMST_OVERFLOW BIT(0)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index fa42e32..e8db9e2 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -25,6 +25,7 @@
#include <linux/vmalloc.h>
#include <linux/mutex.h>
#include <linux/module.h>
+#include <linux/sched.h>
#include <asm/hardware/coresight.h>
#include <asm/sections.h>
@@ -40,12 +41,17 @@ struct tracectx {
void __iomem *etm_regs;
unsigned long flags;
int naddrcmppairs;
+ int nctxidcmp;
int etm_portsz;
struct device *dev;
struct clk *emu_clk;
struct mutex mutex;
unsigned long addrrange_start;
unsigned long addrrange_end;
+ pid_t pid; /* globally unique PID */
+#ifdef CONFIG_PID_NS
+ pid_t vpid; /* virtual PID as seen in namespace */
+#endif
};
static struct tracectx tracer;
@@ -55,18 +61,42 @@ static inline bool trace_isrunning(struct tracectx *t)
return !!(t->flags & TRACER_RUNNING);
}
+#if defined(CONFIG_PID_IN_CONTEXTIDR) && defined(CONFIG_PID_NS)
+/*
+ * Returns the globally unique ID of a task referenced
+ * with its virtual namespace PID
+ */
+static inline pid_t pid_vnr_to_pid_nr(pid_t vpid)
+{
+ struct task_struct *task = find_task_by_vpid(vpid);
+
+ if (!task) {
+ printk(KERN_WARNING "CoreSight ETM: cannot track PID %d: "
+ "no such PID in current namespace\n",
+ vpid);
+ return -EINVAL;
+ }
+
+ return task_pid_nr(task);
+}
+#endif
+
/*
* Setups ETM to trace only when:
* - address between start and end
* or address not between start and end (if exclude)
+ * - in user-space when process id equals pid,
+ * in kernel-space (if pid == 0),
+ * always (if pid == -1)
* - trace executed instructions
* or trace loads and stores (if data)
*/
-static int etm_setup_address_range(struct tracectx *t, int n,
- unsigned long start, unsigned long end, int exclude, int data)
+static int etm_setup(struct tracectx *t, int n,
+ unsigned long start, unsigned long end, int exclude,
+ pid_t pid,
+ int data)
{
- u32 flags = ETMAAT_ARM | ETMAAT_IGNCONTEXTID | ETMAAT_NSONLY | \
- ETMAAT_NOVALCMP;
+ u32 flags = ETMAAT_ARM | ETMAAT_NSONLY | ETMAAT_NOVALCMP;
if (n < 1 || n > t->naddrcmppairs)
return -EINVAL;
@@ -75,6 +105,23 @@ static int etm_setup_address_range(struct tracectx *t, int n,
* to bits in a word */
n--;
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+ if (pid < 0) {
+ /* ignore Context ID */
+ flags |= ETMAAT_IGNCONTEXTID;
+ } else {
+ flags |= ETMAAT_VALUE1;
+
+ /* Set up the first Context ID comparator.
+ Process ID is found in the 24 first bits of Context ID
+ (provided by CONFIG_PID_IN_CONTEXTIDR) */
+ etm_writel(t, pid << 8, ETMR_CTXIDCOMP_VAL(0));
+ etm_writel(t, 0xff, ETMR_CTXIDCOMP_MASK);
+ }
+#else
+ flags |= ETMAAT_IGNCONTEXTID;
+#endif
+
if (data)
flags |= ETMAAT_DLOADSTORE;
else
@@ -124,8 +171,10 @@ static int trace_start(struct tracectx *t)
return -EFAULT;
}
- etm_setup_address_range(t, 1, t->addrrange_start, t->addrrange_end,
- 0, 0);
+ etm_setup(t, 1,
+ t->addrrange_start, t->addrrange_end, 0,
+ t->pid,
+ 0);
etm_writel(t, 0, ETMR_TRACEENCTRL2);
etm_writel(t, 0, ETMR_TRACESSCTRL);
etm_writel(t, 0x6f, ETMR_TRACEENEVT);
@@ -489,6 +538,7 @@ static ssize_t trace_info_show(struct device *dev,
return sprintf(buf, "Trace buffer len: %d\n"
"Addr comparator pairs: %d\n"
+ "Ctx ID comparators: %d\n"
"ETBR_WRITEADDR:\t%08x\n"
"ETBR_READADDR:\t%08x\n"
"ETBR_STATUS:\t%08x\n"
@@ -497,6 +547,7 @@ static ssize_t trace_info_show(struct device *dev,
"ETMR_STATUS:\t%08x\n",
datalen,
tracer.naddrcmppairs,
+ tracer.nctxidcmp,
etb_wa,
etb_ra,
etb_st,
@@ -569,6 +620,61 @@ static ssize_t trace_addrrange_store(struct device *dev,
DEVICE_ATTR(trace_addrrange, S_IRUGO|S_IWUSR,
trace_addrrange_show, trace_addrrange_store);
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+static ssize_t trace_pid_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+#ifdef CONFIG_PID_NS
+ return sprintf(buf, "%d\n", tracer.vpid);
+#else
+ return sprintf(buf, "%d\n", tracer.pid);
+#endif
+}
+
+static ssize_t trace_pid_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ pid_t pid;
+#ifdef CONFIG_PID_NS
+ pid_t vpid;
+#endif
+
+ if (tracer.flags & TRACER_RUNNING)
+ return -EBUSY;
+
+ if (sscanf(buf, "%i", &pid) != 1)
+ return -EINVAL;
+
+#ifdef CONFIG_PID_NS
+ /* the value written to the Context ID register is the global PID */
+ vpid = pid;
+
+ /* -1 means trace everything,
+ 0 means kernel tracing,
+ > 0 process tracing */
+ if (pid > 0) {
+ pid = pid_vnr_to_pid_nr(vpid);
+
+ if (pid < 0)
+ return pid;
+ }
+#endif
+
+ mutex_lock(&tracer.mutex);
+ tracer.pid = pid;
+#ifdef CONFIG_PID_NS
+ tracer.vpid = vpid;
+#endif
+ mutex_unlock(&tracer.mutex);
+
+ return n;
+}
+
+DEVICE_ATTR(trace_pid, S_IRUGO|S_IWUSR, trace_pid_show, trace_pid_store);
+#endif
+
static int etm_probe(struct amba_device *dev, const struct amba_id *id)
{
struct tracectx *t = &tracer;
@@ -598,6 +704,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
t->etm_portsz = 1;
t->addrrange_start = (unsigned long) _stext;
t->addrrange_end = (unsigned long) _etext;
+ t->pid = -1; /* trace everything */
etm_unlock(t);
(void)etm_readl(t, ETMMR_PDSR);
@@ -605,6 +712,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
(void)etm_readl(&tracer, ETMMR_OSSRR);
t->naddrcmppairs = etm_readl(t, ETMR_CONFCODE) & 0xf;
+ t->nctxidcmp = (etm_readl(t, ETMR_CONFCODE) >> 24) & 0x3;
etm_writel(t, 0x440, ETMR_CTRL);
etm_lock(t);
@@ -612,7 +720,7 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
goto out_unmap;
- /* failing to create any of these three is not fatal */
+ /* failing to create any of these four is not fatal */
ret = device_create_file(&dev->dev, &dev_attr_trace_info);
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_info in sysfs\n");
@@ -625,6 +733,12 @@ static int etm_probe(struct amba_device *dev, const struct amba_id *id)
if (ret)
dev_dbg(&dev->dev, "Failed to create trace_addrrange in sysfs\n");
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+ ret = device_create_file(&dev->dev, &dev_attr_trace_pid);
+ if (ret)
+ dev_dbg(&dev->dev, "Failed to create trace_pid in sysfs\n");
+#endif
+
dev_dbg(t->dev, "ETM AMBA driver initialized.\n");
out:
@@ -655,6 +769,9 @@ static int etm_remove(struct amba_device *dev)
device_remove_file(&dev->dev, &dev_attr_trace_info);
device_remove_file(&dev->dev, &dev_attr_trace_mode);
device_remove_file(&dev->dev, &dev_attr_trace_addrrange);
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+ device_remove_file(&dev->dev, &dev_attr_trace_pid);
+#endif
return 0;
}
--
1.8.5.3
^ permalink raw reply related
* [PATCH] fix compilation of imx-hdmi
From: Russell King - ARM Linux @ 2014-01-30 16:13 UTC (permalink / raw)
To: linux-arm-kernel
imx-hdmi creates a hdmi_colorimetry enum. This is also defined by
include/linux/hdmi.h, which gets included now via DRM headers since
985e5dc207e133 (drm/edid: Populate picture aspect ratio for CEA modes).
This leads to the compiler complaining:
drivers/staging/imx-drm/imx-hdmi.c:58:6: error: nested redefinition of 'enum hdmi_colorimetry'
drivers/staging/imx-drm/imx-hdmi.c:58:6: error: redeclaration of 'enum hdmi_colorimetry'
include/linux/hdmi.h:48:6: note: originally defined here
Fix it by using the one in linux/hdmi.h
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/staging/imx-drm/imx-hdmi.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-hdmi.c b/drivers/staging/imx-drm/imx-hdmi.c
index d358d89e11c4..74d635fcb3d5 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -55,11 +55,6 @@ enum hdmi_datamap {
YCbCr422_12B = 0x12,
};
-enum hdmi_colorimetry {
- ITU601,
- ITU709,
-};
-
enum imx_hdmi_devtype {
IMX6Q_HDMI,
IMX6DL_HDMI,
@@ -475,12 +470,12 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi *hdmi)
if (is_color_space_conversion(hdmi)) {
if (hdmi->hdmi_data.enc_out_format == RGB) {
- if (hdmi->hdmi_data.colorimetry == ITU601)
+ if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
csc_coeff = &csc_coeff_rgb_out_eitu601;
else
csc_coeff = &csc_coeff_rgb_out_eitu709;
} else if (hdmi->hdmi_data.enc_in_format == RGB) {
- if (hdmi->hdmi_data.colorimetry == ITU601)
+ if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
csc_coeff = &csc_coeff_rgb_in_eitu601;
else
csc_coeff = &csc_coeff_rgb_in_eitu709;
@@ -1009,14 +1004,14 @@ static void hdmi_config_AVI(struct imx_hdmi *hdmi)
/* Set up colorimetry */
if (hdmi->hdmi_data.enc_out_format == XVYCC444) {
colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_EXTENDED_INFO;
- if (hdmi->hdmi_data.colorimetry == ITU601)
+ if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
ext_colorimetry =
HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC601;
else /* hdmi->hdmi_data.colorimetry == ITU709 */
ext_colorimetry =
HDMI_FC_AVICONF2_EXT_COLORIMETRY_XVYCC709;
} else if (hdmi->hdmi_data.enc_out_format != RGB) {
- if (hdmi->hdmi_data.colorimetry == ITU601)
+ if (hdmi->hdmi_data.colorimetry == HDMI_COLORIMETRY_ITU_601)
colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_SMPTE;
else /* hdmi->hdmi_data.colorimetry == ITU709 */
colorimetry = HDMI_FC_AVICONF1_COLORIMETRY_ITUR;
@@ -1247,9 +1242,9 @@ static int imx_hdmi_setup(struct imx_hdmi *hdmi, struct drm_display_mode *mode)
(hdmi->vic == 21) || (hdmi->vic == 22) ||
(hdmi->vic == 2) || (hdmi->vic == 3) ||
(hdmi->vic == 17) || (hdmi->vic == 18))
- hdmi->hdmi_data.colorimetry = ITU601;
+ hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
else
- hdmi->hdmi_data.colorimetry = ITU709;
+ hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
(hdmi->vic == 12) || (hdmi->vic == 13) ||
--
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 related
* [RFC] ARM Generic Timer + Interaction with WFI on Cortex-A15
From: Lorenzo Pieralisi @ 2014-01-30 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52947FFA.90504@gmail.com>
Hi Marc,
On Tue, Nov 26, 2013 at 11:03:22AM +0000, Marc C wrote:
> Hi Lorenzo,
>
> > So what's the problem then ? Just avoid adding CPUIDLE_FLAG_TIMER_STOP
> > to the C-state flags and you are all set, or I am missing something
> > here ?
>
> The C3STOP flag prevents the kernel from using the timer as a
> high-resolution clock source. There are some patches that remove the
> C3STOP flag [1] in order for the timer to function for use with hrtimer.
> I think something similar could be manageable as a DT property on the
> armv7-timer binding.
>
> > Yes I do object. Timer binding is global in the DT and do not want to
> > override the flag for all local timers when, as I mentioned, A15
> > behaviour is just an exception. If you really need that, please write
> > an idle driver that does not enter broadcast mode on C-state entry
> > (see above).
>
> So what you're saying is that you'll outright disapprove of any patch
> that would otherwise help ensure the kernel would run on any/all
> variations of armv7-timer? I would imagine that we'd want things to be
> more inclusive, and since there are quite a few SoCs with the timer that
> behave in this manner.
>
> I'm not trying to be a thorn in your side. I just want to make sure
> everyone that has an implementation similar to ours is covered, too.
I though about this and I think the only clean way to implement this
would be to add a power domain property to the arch timers. The problem
I am having is that this should not break existing platforms, so
basically we need to understand what the power-domain property would
mean on a system like yours with no power management. We might add
an always-on power domain and attach the arch timer to that, it seems
lots of churn for not much to me.
Adding a property like "state-retained" is not nice either because this
would solve the problem for arch timer but that does not represent a
generic solution.
Thoughts appreciated.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH] fix compilation of imx-hdmi
From: Fabio Estevam @ 2014-01-30 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130161347.GD15937@n2100.arm.linux.org.uk>
On 01/30/2014 02:13 PM, Russell King - ARM Linux wrote:
> imx-hdmi creates a hdmi_colorimetry enum. This is also defined by
> include/linux/hdmi.h, which gets included now via DRM headers since
> 985e5dc207e133 (drm/edid: Populate picture aspect ratio for CEA modes).
> This leads to the compiler complaining:
>
> drivers/staging/imx-drm/imx-hdmi.c:58:6: error: nested redefinition of 'enum hdmi_colorimetry'
> drivers/staging/imx-drm/imx-hdmi.c:58:6: error: redeclaration of 'enum hdmi_colorimetry'
> include/linux/hdmi.h:48:6: note: originally defined here
>
> Fix it by using the one in linux/hdmi.h
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Sachin has also sent the same fix:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2014-January/045167.html
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Peter Zijlstra @ 2014-01-30 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401301102210.1652@knanqh.ubzr>
On Thu, Jan 30, 2014 at 11:03:31AM -0500, Nicolas Pitre wrote:
> > This is not a valid patch for PATCH(1). Please try again.
>
> Don't you use git? ;-)
Nah, git and me don't get along well.
> Here's a plain patch:
Thanks!
^ permalink raw reply
* [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Joe Perches @ 2014-01-30 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130162753.GF5002@laptop.programming.kicks-ass.net>
On Thu, 2014-01-30 at 17:27 +0100, Peter Zijlstra wrote:
> On Thu, Jan 30, 2014 at 11:03:31AM -0500, Nicolas Pitre wrote:
> > > This is not a valid patch for PATCH(1). Please try again.
> >
> > Don't you use git? ;-)
>
> Nah, git and me don't get along well.
Perhaps you could use a newer version of patch
http://savannah.gnu.org/forum/forum.php?forum_id=7361
GNU patch version 2.7 released
Item posted by Andreas Gruenbacher <agruen> on Wed 12 Sep 2012 02:18:14
PM UTC.
I am pleased to announce that version 2.7 of GNU patch has been
released. The following significant changes have happened since the last
stable release in December 2009:
* Support for most features of the "diff --git" format, including
renames and copies, permission changes, and symlink diffs.
Binary diffs are not supported yet; patch will complain and skip
them.
^ permalink raw reply
* [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Peter Zijlstra @ 2014-01-30 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391100076.2422.56.camel@joe-AO722>
On Thu, Jan 30, 2014 at 08:41:16AM -0800, Joe Perches wrote:
> Perhaps you could use a newer version of patch
>
> GNU patch version 2.7 released
Yeah, I know about that, I'll wait until its common in all distros,
updating all machines I use by hand is just painful.
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Christopher Covington @ 2014-01-30 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell@citrix.com>
Hi Ian,
On 01/30/2014 11:11 AM, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
>
> While here remove the xenvm dts example, the Xen tools will now build a
> suitable mach-virt compatible dts when launching the guest.
[...]
> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> @@ -0,0 +1,32 @@
> +* Mach-virt "Dummy Virtual Machine" platform
> +
> +"mach-virt" is the smallest, dumbest platform possible, to be used as
> +a guest for Xen, KVM and other hypervisors.
The platform is also useful to, and used by, simulators like QEMU in TCG mode.
> It has no
> +properties/functionality of its own and is driven entirely by device
> +tree.
I find this wording confusing. I read it as saying the platform has no
properties or functionality. Perhaps you could phrase it slightly differently,
such as having no properties or functionality beyond what's described in the
device tree.
> +This document defines the requirements for such a platform.
> +
> +* Required properties:
> +
> +- compatible: should be one of:
> + "linux,dummy-virt"
> + "xen,xenvm"
> +
> +In addition to the standard nodes (chosen, cpus, memory etc) the
> +platform is required to provide certain other basic functionality
> +which must be described in the device tree:
> +
> + The platform must provide an ARM Generic Interrupt Controller
> + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> +
> + The platform must provide ARM architected timer, defined in
> + Documentation/devicetree/bindings/arm/arch_timer.txt.
> +
> + If the platform is SMP then it must provide the Power State
> + Coordination Interface (PSCI) described in
> + Documentation/devicetree/bindings/arm/psci.txt.
> +
> +The platform may also provide hypervisor specific functionality
> +(e.g. PV I/O), if it does so then this functionality must be
> +discoverable (directly or indirectly) via device tree.
I think it would be informative to provide pointers here to commonly used
paravirtualized devices, especially VirtIO PCI/MMIO.
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* [PATCH] clk: keystone: gate: fix clk_init_data initialization
From: Ivan Khoronzhuk @ 2014-01-30 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA627E.8060801@ti.com>
Ok
On 01/30/2014 04:32 PM, Santosh Shilimkar wrote:
> On Thursday 30 January 2014 08:49 AM, Ivan Khoronzhuk wrote:
>> Yes. As result the clk->flag field contains garbage. In my case it leads
>> that flag CLK_IGNORE_UNUSED is set for most of clocks. As result a bunch
>> of unused clocks cannot be disabled.
>>
> Can you please update the change log with above information.
>
>> On 01/30/2014 03:26 PM, Shilimkar, Santosh wrote:
>>> Can u capture the issue withiout this fix?
>>>
>>> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>>>
>>> -----Original Message-----
>>> *From:* Khoronzhuk, Ivan [ivan.khoronzhuk at ti.com]
>>> *Received:* Thursday, 30 Jan 2014, 6:37am
>>> *To:* Shilimkar, Santosh [santosh.shilimkar at ti.com]
>>> *CC:* mturquette at linaro.org [mturquette at linaro.org];
>>> linux-arm-kernel at lists.infradead.org [linux-arm-kernel at lists.infradead.org];
>>> linux-kernel at vger.kernel.org [linux-kernel at vger.kernel.org]; Khoronzhuk, Ivan
>>> [ivan.khoronzhuk at ti.com]
>>> *Subject:* [PATCH] clk: keystone: gate: fix clk_init_data initialization
>>>
>>> In clk_register_psc() function clk_init_data struct is allocated
>>> in the stack. All members of this struct should be initialized
>>> before using otherwise it will contain garbage. So initialize flags
>>> in this structure too.
>>>
>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
>>> ---
>>> drivers/clk/keystone/gate.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/keystone/gate.c b/drivers/clk/keystone/gate.c
>>> index 17a5983..86f1e36 100644
>>> --- a/drivers/clk/keystone/gate.c
>>> +++ b/drivers/clk/keystone/gate.c
>>> @@ -179,6 +179,7 @@ static struct clk *clk_register_psc(struct device *dev,
>>>
>>> init.name = name;
>>> init.ops = &clk_psc_ops;
>>> + init.flags = 0;
>>> init.parent_names = (parent_name ? &parent_name : NULL);
>>> init.num_parents = (parent_name ? 1 : 0);
>>>
>>> --
>>> 1.8.3.2
>>>
^ permalink raw reply
* [PATCH] ARM: keystone: dts: disable "msmcsram" clock
From: Ivan Khoronzhuk @ 2014-01-30 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA6228.8030008@ti.com>
Thanks, I will send v2
On 01/30/2014 04:31 PM, Santosh Shilimkar wrote:
> On Thursday 30 January 2014 08:58 AM, Ivan Khoronzhuk wrote:
>> Ok. I will delete node for this clock from DT and send v1
>>
> Sorry for the html reply first of all. That node should never have
> been actually added since the clock is not suppose to be touched even
> in low power states. Change log should say something like this ...
>
> "MSMC is the coherency interconnect and all the coherent masters are
> connected to it including devices which are not under Linux OS control.
> MSMC clock should not be toched even in low power states."
>
> So drop the clock node o.w without 'clk_ignore_unused' will disable
> the clock leading to system stall.
>
> I wil try get these in rc's since its a bug fix
>
> Regards,
> Santosh
>
>
>
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Stefano Stabellini @ 2014-01-30 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA83D6.9050506@codeaurora.org>
On Thu, 30 Jan 2014, Christopher Covington wrote:
> Hi Ian,
>
> On 01/30/2014 11:11 AM, Ian Campbell wrote:
> > mach-virt has existed for a while but it is not written down what it actually
> > consists of. Although it seems a bit unusual to document a binding for an
> > entire platform since mach-virt is entirely virtual it is helpful to have
> > something to refer to in the absence of a single concrete implementation.
> >
> > I've done my best to capture the requirements based on the git log and my
> > memory/understanding.
> >
> > While here remove the xenvm dts example, the Xen tools will now build a
> > suitable mach-virt compatible dts when launching the guest.
>
> [...]
>
> > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > @@ -0,0 +1,32 @@
> > +* Mach-virt "Dummy Virtual Machine" platform
> > +
> > +"mach-virt" is the smallest, dumbest platform possible, to be used as
> > +a guest for Xen, KVM and other hypervisors.
>
> The platform is also useful to, and used by, simulators like QEMU in TCG mode.
>
> > It has no
> > +properties/functionality of its own and is driven entirely by device
> > +tree.
>
> I find this wording confusing. I read it as saying the platform has no
> properties or functionality. Perhaps you could phrase it slightly differently,
> such as having no properties or functionality beyond what's described in the
> device tree.
Right, something like making no assumptions on the presence of devices
or hardware interfaces beyond what is described on device tree.
> > +This document defines the requirements for such a platform.
> > +
> > +* Required properties:
> > +
> > +- compatible: should be one of:
> > + "linux,dummy-virt"
> > + "xen,xenvm"
> > +
> > +In addition to the standard nodes (chosen, cpus, memory etc) the
> > +platform is required to provide certain other basic functionality
> > +which must be described in the device tree:
> > +
> > + The platform must provide an ARM Generic Interrupt Controller
> > + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> > +
> > + The platform must provide ARM architected timer, defined in
> > + Documentation/devicetree/bindings/arm/arch_timer.txt.
> > +
> > + If the platform is SMP then it must provide the Power State
> > + Coordination Interface (PSCI) described in
> > + Documentation/devicetree/bindings/arm/psci.txt.
> > +
> > +The platform may also provide hypervisor specific functionality
> > +(e.g. PV I/O), if it does so then this functionality must be
> > +discoverable (directly or indirectly) via device tree.
>
> I think it would be informative to provide pointers here to commonly used
> paravirtualized devices, especially VirtIO PCI/MMIO.
In that case I would appreciate a link to the Xen hypervisor node:
Documentation/devicetree/bindings/arm/xen.txt
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Marc Zyngier @ 2014-01-30 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell@citrix.com>
Hi Ian,
On 30/01/14 16:11, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
>
> While here remove the xenvm dts example, the Xen tools will now build a
> suitable mach-virt compatible dts when launching the guest.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
> I'm not sure which tree this sort of thing should go though, sorry for the
> huge Cc.
> ---
> .../devicetree/bindings/arm/mach-virt.txt | 32 ++++++++
> arch/arm/boot/dts/xenvm-4.2.dts | 81 --------------------
> 2 files changed, 32 insertions(+), 81 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
> delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt b/Documentation/devicetree/bindings/arm/mach-virt.txt
> new file mode 100644
> index 0000000..562bcda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> @@ -0,0 +1,32 @@
> +* Mach-virt "Dummy Virtual Machine" platform
> +
> +"mach-virt" is the smallest, dumbest platform possible, to be used as
> +a guest for Xen, KVM and other hypervisors. It has no
> +properties/functionality of its own and is driven entirely by device
> +tree.
> +
> +This document defines the requirements for such a platform.
> +
> +* Required properties:
> +
> +- compatible: should be one of:
> + "linux,dummy-virt"
> + "xen,xenvm"
> +
> +In addition to the standard nodes (chosen, cpus, memory etc) the
> +platform is required to provide certain other basic functionality
> +which must be described in the device tree:
> +
> + The platform must provide an ARM Generic Interrupt Controller
> + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> +
> + The platform must provide ARM architected timer, defined in
> + Documentation/devicetree/bindings/arm/arch_timer.txt.
> +
> + If the platform is SMP then it must provide the Power State
> + Coordination Interface (PSCI) described in
> + Documentation/devicetree/bindings/arm/psci.txt.
I'm afraid I disagree with most of the above. The whole point of
mach-virt is to provide a shell for DT platforms. None of this hardware
is mandated. Instead, all the necessary information should be described
in DT.
Actually, mach-virt doesn't really stand for Virtual Machine. It stands
for virtual mach-* directory! Eventually, mach-virt should become the
default platform, the one we use when we don't match anything else in
the kernel
What you've described here are requirements for a hypervisor like Xen or
KVM. mach-virt itself shouldn't have any of that.
Cheers,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 0/7] Audio support for Armada 370 DB
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series of patches enable audio support on the Marvell Armada 370
Development Board. Since both the I2S controller on the SoC side and
the I2C audio codec are already supported by the kernel, the amount of
work is fairly limited.
Also, since the DT bindings that allows to replace the ASoC board
driver are still being ironed out, I'm proposing to add an old-style
ASoC board driver for now.
This set of patches only provide support for the analog output and
input, I am waiting for the optical cable to arrive to get the digital
input and output to work.
Patches 1 to 3 are to be taken by the ASoC maintainer, while patches 4
to 7 are to be taken by the mvebu maintainers.
Note that the audio support for Armada 370 also needs a fix to the
CS42L51, which is being discussed with the author of the change that
apparently introduced the problem (see discussion at
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071916.html).
Thanks,
Thomas
Thomas Petazzoni (7):
sound: codec: add Device Tree binding to cs42l51
sound: soc: enable Kirkwood driver for mvebu platforms
sound: soc: add ASoC board driver for Armada 370 DB
ARM: mvebu: add audio I2S controller to Armada 370 Device Tree
ARM: mvebu: add I2C0 muxing option for Armada 370 SoC
ARM: mvebu: add audio support to Armada 370 DB
ARM: mvebu: enable audio options in mvebu_defconfig
.../devicetree/bindings/i2c/trivial-devices.txt | 1 +
.../devicetree/bindings/sound/mvebu-audio.txt | 1 +
arch/arm/boot/dts/armada-370-db.dts | 46 +++++++
arch/arm/boot/dts/armada-370.dtsi | 29 +++++
arch/arm/configs/mvebu_defconfig | 5 +
sound/soc/codecs/cs42l51.c | 7 +
sound/soc/kirkwood/Kconfig | 10 +-
sound/soc/kirkwood/Makefile | 2 +
sound/soc/kirkwood/armada-370-db.c | 144 +++++++++++++++++++++
sound/soc/kirkwood/kirkwood-i2s.c | 1 +
10 files changed, 245 insertions(+), 1 deletion(-)
create mode 100644 sound/soc/kirkwood/armada-370-db.c
--
1.8.3.2
^ permalink raw reply
* [PATCH 1/7] sound: codec: add Device Tree binding to cs42l51
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds a trivial Device Tree binding to the I2C-based
cs42l51 sound codec, so that it can be used from Device Tree based
platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
sound/soc/codecs/cs42l51.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index b1cb341..041e560 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -17,6 +17,7 @@ at,24c08 i2c serial eeprom (24cxx)
atmel,24c02 i2c serial eeprom (24cxx)
atmel,at97sc3204t i2c trusted platform module (TPM)
catalyst,24c32 i2c serial eeprom
+cirrus,cs42l51 Cirrus Logic CS42L51 audio codec
dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock
dallas,ds1338 I2C RTC with 56-Byte NV RAM
dallas,ds1339 I2C Serial Real-Time Clock
diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c
index 1e0fa3b..4a7a733 100644
--- a/sound/soc/codecs/cs42l51.c
+++ b/sound/soc/codecs/cs42l51.c
@@ -604,10 +604,17 @@ static const struct i2c_device_id cs42l51_id[] = {
};
MODULE_DEVICE_TABLE(i2c, cs42l51_id);
+static const struct of_device_id cs42l51_of_match[] = {
+ { .compatible = "cirrus,cs42l51", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, cs42l51_of_match);
+
static struct i2c_driver cs42l51_i2c_driver = {
.driver = {
.name = "cs42l51-codec",
.owner = THIS_MODULE,
+ .of_match_table = cs42l51_of_match,
},
.id_table = cs42l51_id,
.probe = cs42l51_i2c_probe,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/7] sound: soc: enable Kirkwood driver for mvebu platforms
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
The audio unit found in the Armada 370 SoC is similar to the one used
in the Marvell Kirkwood and Marvell Dove SoCs. Therefore, this commit
allows the Kirkwood audio driver to be built on mvebu platforms, and
adds an additional compatible string to identify the Armada 370
variant of the audio unit.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Documentation/devicetree/bindings/sound/mvebu-audio.txt | 1 +
sound/soc/kirkwood/Kconfig | 2 +-
sound/soc/kirkwood/kirkwood-i2s.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/mvebu-audio.txt b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
index f0062c5..cb8c07c 100644
--- a/Documentation/devicetree/bindings/sound/mvebu-audio.txt
+++ b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
@@ -5,6 +5,7 @@ Required properties:
- compatible:
"marvell,kirkwood-audio" for Kirkwood platforms
"marvell,dove-audio" for Dove platforms
+ "marvell,armada370-audio" for Armada 370 platforms
- reg: physical base address of the controller and length of memory mapped
region.
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 78ed4a4..764a0ef 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,6 +1,6 @@
config SND_KIRKWOOD_SOC
tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
- depends on ARCH_KIRKWOOD || ARCH_DOVE || COMPILE_TEST
+ depends on ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST
help
Say Y or M if you want to add support for codecs attached to
the Kirkwood I2S interface. You will also need to select the
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c
index 3920a5e..9f84222 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -633,6 +633,7 @@ static int kirkwood_i2s_dev_remove(struct platform_device *pdev)
static struct of_device_id mvebu_audio_of_match[] = {
{ .compatible = "marvell,kirkwood-audio" },
{ .compatible = "marvell,dove-audio" },
+ { .compatible = "marvell,armada370-audio" },
{ }
};
MODULE_DEVICE_TABLE(of, mvebu_audio_of_match);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/7] sound: soc: add ASoC board driver for Armada 370 DB
From: Thomas Petazzoni @ 2014-01-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds a simple ASoC board driver fo the Armada 370
Development Board, which connects the audio unit of the Armada 370 SoC
to the I2C-based CS42L51.
For now, only the analog audio input and output through the CS42L51
are supported, but in the near future, digital audio input and output
support will be added through SPDIF.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
sound/soc/kirkwood/Kconfig | 8 +++
sound/soc/kirkwood/Makefile | 2 +
sound/soc/kirkwood/armada-370-db.c | 144 +++++++++++++++++++++++++++++++++++++
3 files changed, 154 insertions(+)
create mode 100644 sound/soc/kirkwood/armada-370-db.c
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 764a0ef..2dc3ecf 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -6,6 +6,14 @@ config SND_KIRKWOOD_SOC
the Kirkwood I2S interface. You will also need to select the
audio interfaces to support below.
+config SND_KIRKWOOD_SOC_ARMADA370_DB
+ tristate "SoC Audio support for Armada 370 DB"
+ depends on SND_KIRKWOOD_SOC && (ARCH_MVEBU || COMPILE_TEST) && I2C
+ select SND_SOC_CS42L51
+ help
+ Say Y if you want to add support for SoC audio on
+ the Armada 370 Development Board.
+
config SND_KIRKWOOD_SOC_OPENRD
tristate "SoC Audio support for Kirkwood Openrd Client"
depends on SND_KIRKWOOD_SOC && (MACH_OPENRD_CLIENT || MACH_OPENRD_ULTIMATE || COMPILE_TEST)
diff --git a/sound/soc/kirkwood/Makefile b/sound/soc/kirkwood/Makefile
index 9e78138..7c1d8fe 100644
--- a/sound/soc/kirkwood/Makefile
+++ b/sound/soc/kirkwood/Makefile
@@ -4,6 +4,8 @@ obj-$(CONFIG_SND_KIRKWOOD_SOC) += snd-soc-kirkwood.o
snd-soc-openrd-objs := kirkwood-openrd.o
snd-soc-t5325-objs := kirkwood-t5325.o
+snd-soc-armada-370-db-objs := armada-370-db.o
+obj-$(CONFIG_SND_KIRKWOOD_SOC_ARMADA370_DB) += snd-soc-armada-370-db.o
obj-$(CONFIG_SND_KIRKWOOD_SOC_OPENRD) += snd-soc-openrd.o
obj-$(CONFIG_SND_KIRKWOOD_SOC_T5325) += snd-soc-t5325.o
diff --git a/sound/soc/kirkwood/armada-370-db.c b/sound/soc/kirkwood/armada-370-db.c
new file mode 100644
index 0000000..d5d8388
--- /dev/null
+++ b/sound/soc/kirkwood/armada-370-db.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2014 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <sound/soc.h>
+#include <linux/of.h>
+#include <linux/platform_data/asoc-kirkwood.h>
+#include "../codecs/cs42l51.h"
+
+static int a370db_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ int ret;
+ unsigned int freq, fmt;
+
+ fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS;
+ ret = snd_soc_dai_set_fmt(cpu_dai, fmt);
+ if (ret < 0)
+ return ret;
+
+ ret = snd_soc_dai_set_fmt(codec_dai, fmt);
+ if (ret < 0)
+ return ret;
+
+ switch (params_rate(params)) {
+ default:
+ case 44100:
+ freq = 11289600;
+ break;
+ case 48000:
+ freq = 12288000;
+ break;
+ case 96000:
+ freq = 24576000;
+ break;
+ }
+
+ return snd_soc_dai_set_sysclk(codec_dai, 0, freq, SND_SOC_CLOCK_IN);
+}
+
+static struct snd_soc_ops a370db_ops = {
+ .hw_params = a370db_hw_params,
+};
+
+static const struct snd_soc_dapm_widget a370db_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Out Jack", NULL),
+ SND_SOC_DAPM_LINE("In Jack", NULL),
+};
+
+static const struct snd_soc_dapm_route a370db_route[] = {
+ { "Out Jack", NULL, "HPL" },
+ { "Out Jack", NULL, "HPR" },
+ { "AIN1L", NULL, "In Jack" },
+ { "AIN1L", NULL, "In Jack" },
+};
+
+static int a370db_dai_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_codec *codec = rtd->codec;
+ struct snd_soc_dapm_context *dapm = &codec->dapm;
+
+ snd_soc_dapm_enable_pin(dapm, "Out Jack");
+ snd_soc_dapm_enable_pin(dapm, "In Jack");
+
+ return 0;
+}
+
+static struct snd_soc_dai_link a370db_dai[] = {
+{
+ .name = "CS42L51",
+ .stream_name = "CS42L51 HiFi",
+ .cpu_dai_name = "i2s",
+ .platform_name = "d0030000.audio-controller",
+ .codec_dai_name = "cs42l51-hifi",
+ .codec_name = "cs42l51-codec.0-004a",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
+ .ops = &a370db_ops,
+ .init = a370db_dai_init,
+},
+};
+
+static struct snd_soc_card a370db = {
+ .name = "a370db",
+ .owner = THIS_MODULE,
+ .dai_link = a370db_dai,
+ .num_links = ARRAY_SIZE(a370db_dai),
+ .dapm_widgets = a370db_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(a370db_dapm_widgets),
+ .dapm_routes = a370db_route,
+ .num_dapm_routes = ARRAY_SIZE(a370db_route),
+};
+
+static int a370db_probe(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = &a370db;
+ int ret;
+
+ card->dev = &pdev->dev;
+
+ return snd_soc_register_card(card);
+}
+
+static int a370db_remove(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+ return snd_soc_unregister_card(card);
+}
+
+static const struct of_device_id a370db_dt_ids[] = {
+ { .compatible = "marvell,a370db-audio" },
+ { },
+};
+
+static struct platform_driver a370db_driver = {
+ .driver = {
+ .name = "a370db-audio",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(a370db_dt_ids),
+ },
+ .probe = a370db_probe,
+ .remove = a370db_remove,
+};
+
+module_platform_driver(a370db_driver);
+
+MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni@free-electrons.com>");
+MODULE_DESCRIPTION("ALSA SoC a370db audio client");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:a370db-audio");
--
1.8.3.2
^ 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