* [PATCH v3 6/6] coresight: etm4x: Support panic kdump
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
ETMv4 hardware information and configuration needs to be saved as
metadata; these metadata should be compatible with tool 'perf' and
can be used for tracing data analysis. ETMv4 usually works as tracer
per CPU, we cannot wait to gather ETM info after the CPU has been panic
and cannot execute dump operations for itself; so should gather
metadata when the corresponding CPU is alive.
Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
won't change at the runtime. Those registers value are filled when
tracers are instantiated.
The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
dynamically configured, we record their value when enabling coresight
path. When operating from sysFS tracer these two registers are recorded
in etm4_enable_sysfs() and add kdump node into list, and remove the
kdump node in etm4_disable_sysfs(). When operating from perf,
etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
is used to record configuration registers and update dump buffer info,
this can avoid unnecessary list addition and deletion operations.
Removal of the tracers from the dump list is done in function
free_event_data().
Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++++++++++-
drivers/hwtracing/coresight/coresight-etm4x.c | 23 +++++++++++++++++++++++
drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++++++
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 8a0ad77..fec779b 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
}
for_each_cpu(cpu, mask) {
+ struct coresight_device *csdev;
+
+ csdev = per_cpu(csdev_src, cpu);
+ if (csdev)
+ coresight_kdump_del(csdev);
+
if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
coresight_release_path(event_data->path[cpu]);
}
@@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
static void *etm_setup_aux(int event_cpu, void **pages,
int nr_pages, bool overwrite)
{
- int cpu;
+ int cpu, ret;
cpumask_t *mask;
struct coresight_device *sink;
struct etm_event_data *event_data = NULL;
@@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages,
event_data->path[cpu] = coresight_build_path(csdev, sink);
if (IS_ERR(event_data->path[cpu]))
goto err;
+
+ ret = coresight_kdump_add(csdev, cpu);
+ if (ret)
+ goto err;
}
if (!sink_ops(sink)->alloc_buffer)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index cf364a5..cbde398 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device *csdev,
static int etm4_enable_sysfs(struct coresight_device *csdev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct etmv4_config *config = &drvdata->config;
+ struct etmv4_metadata *metadata = &drvdata->metadata;
int ret;
spin_lock(&drvdata->spinlock);
+ /* Update meta data and add into kdump list */
+ metadata->trcconfigr = config->cfg;
+ metadata->trctraceidr = drvdata->trcid;
+
+ coresight_kdump_add(csdev, drvdata->cpu);
+ coresight_kdump_update(csdev, (char *)metadata, sizeof(*metadata));
+
/*
* Executing etm4_enable_hw on the cpu whose ETM is being enabled
* ensures that register writes occur when cpu is powered.
@@ -384,6 +393,9 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
*/
smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1);
+ /* Delete from kdump list */
+ coresight_kdump_del(csdev);
+
spin_unlock(&drvdata->spinlock);
cpus_read_unlock();
@@ -438,6 +450,7 @@ static void etm4_init_arch_data(void *info)
u32 etmidr4;
u32 etmidr5;
struct etmv4_drvdata *drvdata = info;
+ struct etmv4_metadata *metadata = &drvdata->metadata;
/* Make sure all registers are accessible */
etm4_os_unlock(drvdata);
@@ -590,6 +603,16 @@ static void etm4_init_arch_data(void *info)
drvdata->nrseqstate = BMVAL(etmidr5, 25, 27);
/* NUMCNTR, bits[30:28] number of counters available for tracing */
drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
+
+ /* Update metadata */
+ metadata->magic = ETM4_METADATA_MAGIC;
+ metadata->cpu = drvdata->cpu;
+ metadata->trcidr0 = readl_relaxed(drvdata->base + TRCIDR0);
+ metadata->trcidr1 = readl_relaxed(drvdata->base + TRCIDR1);
+ metadata->trcidr2 = readl_relaxed(drvdata->base + TRCIDR2);
+ metadata->trcidr8 = readl_relaxed(drvdata->base + TRCIDR8);
+ metadata->trcauthstatus = readl_relaxed(drvdata->base + TRCAUTHSTATUS);
+
CS_LOCK(drvdata->base);
}
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index b3b5ea7..08dc8b7 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -198,6 +198,20 @@
#define ETM_EXLEVEL_NS_HYP BIT(14)
#define ETM_EXLEVEL_NS_NA BIT(15)
+#define ETM4_METADATA_MAGIC 0x4040404040404040ULL
+
+struct etmv4_metadata {
+ u64 magic;
+ u64 cpu;
+ u64 trcconfigr;
+ u64 trctraceidr;
+ u64 trcidr0;
+ u64 trcidr1;
+ u64 trcidr2;
+ u64 trcidr8;
+ u64 trcauthstatus;
+};
+
/**
* struct etmv4_config - configuration information related to an ETMv4
* @mode: Controls various modes supported by this ETM.
@@ -393,6 +407,7 @@ struct etmv4_drvdata {
bool atbtrig;
bool lpoverride;
struct etmv4_config config;
+ struct etmv4_metadata metadata;
};
/* Address comparator access types */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 5/6] coresight: Add and delete sink callback for panic kdump list
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
If the sink device has panic kdump callback, this means the sink device
wants to save tracing data for panic happening.
This commit adds node into panic kdump list when the sink device is
enabled, and delete node when the sink device is disabled.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/coresight.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 389c4ba..56798b1 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -146,6 +146,14 @@ static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)
if (ret)
return ret;
}
+
+ /* Add into panic kdump list */
+ if (sink_ops(csdev)->panic_cb) {
+ ret = coresight_kdump_add(csdev, 0);
+ if (ret)
+ return ret;
+ }
+
csdev->enable = true;
}
@@ -157,6 +165,10 @@ static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)
static void coresight_disable_sink(struct coresight_device *csdev)
{
if (atomic_dec_return(csdev->refcnt) == 0) {
+ /* Delete from panic kdump list */
+ if (sink_ops(csdev)->panic_cb)
+ coresight_kdump_del(csdev);
+
if (sink_ops(csdev)->disable) {
sink_ops(csdev)->disable(csdev);
csdev->enable = false;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/6] coresight: tmc: Hook callback for panic kdump
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
Since the panic kdump functionality has been ready, this patch is to
hook panic callback function for ETB/ETF. Since the driver data
structure has allocated buffer when the session started, so simply save
ETB/ETF trace data into the buffer when panic happens and update
related info into dump node.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/coresight-tmc-etf.c | 29 +++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index e2513b7..f823464 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -504,6 +504,34 @@ static void tmc_update_etf_buffer(struct coresight_device *csdev,
CS_LOCK(drvdata->base);
}
+static void tmc_panic_cb(void *data)
+{
+ struct coresight_device *csdev = (struct coresight_device *)data;
+ struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ unsigned long flags;
+
+ if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB &&
+ drvdata->config_type != TMC_CONFIG_TYPE_ETF))
+ return;
+
+ if (drvdata->mode == CS_MODE_DISABLED)
+ return;
+
+ spin_lock_irqsave(&drvdata->spinlock, flags);
+
+ CS_UNLOCK(drvdata->base);
+
+ tmc_flush_and_stop(drvdata);
+ tmc_etb_dump_hw(drvdata);
+
+ CS_LOCK(drvdata->base);
+
+ /* Update buffer info for panic dump */
+ coresight_kdump_update(csdev, drvdata->buf, drvdata->len);
+
+ spin_unlock_irqrestore(&drvdata->spinlock, flags);
+}
+
static const struct coresight_ops_sink tmc_etf_sink_ops = {
.enable = tmc_enable_etf_sink,
.disable = tmc_disable_etf_sink,
@@ -512,6 +540,7 @@ static const struct coresight_ops_sink tmc_etf_sink_ops = {
.set_buffer = tmc_set_etf_buffer,
.reset_buffer = tmc_reset_etf_buffer,
.update_buffer = tmc_update_etf_buffer,
+ .panic_cb = tmc_panic_cb,
};
static const struct coresight_ops_link tmc_etf_link_ops = {
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/6] coresight: Support panic kdump functionality
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
After kernel panic happens, coresight has many useful info can be used
for analysis. For example, the trace info from ETB RAM can be used to
check the CPU execution flows before crash. So we can save the tracing
data from sink devices, and rely on kdump to save DDR content and uses
"crash" tool to extract coresight dumping from vmcore file.
This patch is to add a simple framework to support panic dump
functionality; it registers panic notifier, and provide the general APIs
{coresight_kdump_add|coresight_kdump_del} as helper functions so any
coresight device can add itself into dump list or delete as needed.
This driver provides helper function coresight_kdump_update() to update
the dump buffer base address and buffer size. This function can be used
by coresight driver, e.g. it can be used to save ETM meta data info at
runtime and these info can be prepared pre panic happening.
When kernel panic happens, the notifier iterates dump list and calls
callback function to dump device specific info. The panic dump is
mainly used to dump trace data so we can get to know the execution flow
before the panic happens.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
drivers/hwtracing/coresight/Kconfig | 9 ++
drivers/hwtracing/coresight/Makefile | 1 +
.../hwtracing/coresight/coresight-panic-kdump.c | 154 +++++++++++++++++++++
drivers/hwtracing/coresight/coresight-priv.h | 13 ++
include/linux/coresight.h | 7 +
5 files changed, 184 insertions(+)
create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c..4812529 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
properly, please refer Documentation/trace/coresight-cpu-debug.txt
for detailed description and the example for usage.
+config CORESIGHT_PANIC_KDUMP
+ bool "CoreSight Panic Kdump driver"
+ depends on ARM || ARM64
+ help
+ This driver provides panic kdump functionality for CoreSight
+ devices. When a kernel panic happen a device supplied callback function
+ is used to save trace data to memory. From there we rely on kdump to extract
+ the trace data from kernel dump file.
+
endif
diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 61db9dd..946fe19 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
+obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c b/drivers/hwtracing/coresight/coresight-panic-kdump.c
new file mode 100644
index 0000000..c21d20b
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017 Linaro Limited.
+#include <linux/coresight.h>
+#include <linux/coresight-pmu.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/mm.h>
+#include <linux/perf_event.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+#include "coresight-priv.h"
+
+typedef void (*coresight_cb_t)(void *data);
+
+/**
+ * struct coresight_kdump_node - Node information for dump
+ * @cpu: The cpu this node is affined to.
+ * @csdev: Handler for coresight device.
+ * @buf: Pointer for dump buffer.
+ * @buf_size: Length of dump buffer.
+ * @list: Hook to the list.
+ */
+struct coresight_kdump_node {
+ int cpu;
+ struct coresight_device *csdev;
+ char *buf;
+ unsigned int buf_size;
+ struct list_head list;
+};
+
+static DEFINE_SPINLOCK(coresight_kdump_lock);
+static LIST_HEAD(coresight_kdump_list);
+static struct notifier_block coresight_kdump_nb;
+
+int coresight_kdump_update(struct coresight_device *csdev, char *buf,
+ unsigned int buf_size)
+{
+ struct coresight_kdump_node *node = csdev->dump_node;
+
+ if (!node) {
+ dev_err(&csdev->dev, "Failed to update dump node.\n");
+ return -EINVAL;
+ }
+
+ node->buf = buf;
+ node->buf_size = buf_size;
+ return 0;
+}
+
+int coresight_kdump_add(struct coresight_device *csdev, int cpu)
+{
+ struct coresight_kdump_node *node;
+ unsigned long flags;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+
+ csdev->dump_node = (void *)node;
+ node->cpu = cpu;
+ node->csdev = csdev;
+
+ spin_lock_irqsave(&coresight_kdump_lock, flags);
+ list_add_tail(&node->list, &coresight_kdump_list);
+ spin_unlock_irqrestore(&coresight_kdump_lock, flags);
+ return 0;
+}
+
+void coresight_kdump_del(struct coresight_device *csdev)
+{
+ struct coresight_kdump_node *node, *next;
+ unsigned long flags;
+
+ spin_lock_irqsave(&coresight_kdump_lock, flags);
+ list_for_each_entry_safe(node, next, &coresight_kdump_list, list) {
+ if (node->csdev == csdev) {
+ list_del(&node->list);
+ kfree(node);
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&coresight_kdump_lock, flags);
+}
+
+static coresight_cb_t
+coresight_kdump_get_cb(struct coresight_device *csdev)
+{
+ coresight_cb_t cb = NULL;
+
+ switch (csdev->type) {
+ case CORESIGHT_DEV_TYPE_SINK:
+ case CORESIGHT_DEV_TYPE_LINKSINK:
+ cb = sink_ops(csdev)->panic_cb;
+ break;
+ case CORESIGHT_DEV_TYPE_SOURCE:
+ cb = source_ops(csdev)->panic_cb;
+ break;
+ case CORESIGHT_DEV_TYPE_LINK:
+ cb = link_ops(csdev)->panic_cb;
+ break;
+ default:
+ dev_info(&csdev->dev, "Unsupport panic dump\n");
+ break;
+ }
+
+ return cb;
+}
+
+/**
+ * coresight_kdump_notify - Invoke panic dump callbacks, this is
+ * the main function to fulfill the panic dump. It distinguishs
+ * to two types: one is pre panic dump which the callback function
+ * handler is NULL and coresight drivers can use function
+ * coresight_kdump_update() to directly update dump buffer base
+ * address and buffer size, for this case this function does nothing
+ * and directly bail out; another case is for post panic dump so
+ * invoke callback on alive CPU.
+ *
+ * Returns: 0 on success.
+ */
+static int coresight_kdump_notify(struct notifier_block *nb,
+ unsigned long mode, void *_unused)
+{
+ struct coresight_kdump_node *node;
+ struct coresight_device *csdev;
+ coresight_cb_t cb;
+ unsigned long flags;
+
+ spin_lock_irqsave(&coresight_kdump_lock, flags);
+
+ list_for_each_entry(node, &coresight_kdump_list, list) {
+ csdev = node->csdev;
+ cb = coresight_kdump_get_cb(csdev);
+ if (cb)
+ cb(csdev);
+ }
+
+ spin_unlock_irqrestore(&coresight_kdump_lock, flags);
+ return 0;
+}
+
+static int __init coresight_kdump_init(void)
+{
+ int ret;
+
+ coresight_kdump_nb.notifier_call = coresight_kdump_notify;
+ ret = atomic_notifier_chain_register(&panic_notifier_list,
+ &coresight_kdump_nb);
+ return ret;
+}
+late_initcall(coresight_kdump_init);
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index f1d0e21d..937750e 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -151,4 +151,17 @@ static inline int etm_readl_cp14(u32 off, unsigned int *val) { return 0; }
static inline int etm_writel_cp14(u32 off, u32 val) { return 0; }
#endif
+#ifdef CONFIG_CORESIGHT_PANIC_KDUMP
+extern int coresight_kdump_add(struct coresight_device *csdev, int cpu);
+extern void coresight_kdump_del(struct coresight_device *csdev);
+extern int coresight_kdump_update(struct coresight_device *csdev,
+ char *buf, unsigned int buf_size);
+#else
+static inline int
+coresight_kdump_add(struct coresight_device *csdev, int cpu) { return 0; }
+static inline void coresight_kdump_del(struct coresight_device *csdev) {}
+static inline int coresight_kdump_update(struct coresight_device *csdev,
+ char *buf, unsigned int buf_size) { return 0; }
+#endif
+
#endif
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index d950dad..43e40fa 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -171,6 +171,7 @@ struct coresight_device {
bool orphan;
bool enable; /* true only if configured as part of a path */
bool activated; /* true only if a sink is part of a path */
+ void *dump_node;
};
#define to_coresight_device(d) container_of(d, struct coresight_device, dev)
@@ -189,6 +190,7 @@ struct coresight_device {
* @set_buffer: initialises buffer mechanic before a trace session.
* @reset_buffer: finalises buffer mechanic after a trace session.
* @update_buffer: update buffer pointers after a trace session.
+ * @panic_cb: hook function for panic notifier.
*/
struct coresight_ops_sink {
int (*enable)(struct coresight_device *csdev, u32 mode);
@@ -205,6 +207,7 @@ struct coresight_ops_sink {
void (*update_buffer)(struct coresight_device *csdev,
struct perf_output_handle *handle,
void *sink_config);
+ void (*panic_cb)(void *data);
};
/**
@@ -212,10 +215,12 @@ struct coresight_ops_sink {
* Operations available for links.
* @enable: enables flow between iport and oport.
* @disable: disables flow between iport and oport.
+ * @panic_cb: hook function for panic notifier.
*/
struct coresight_ops_link {
int (*enable)(struct coresight_device *csdev, int iport, int oport);
void (*disable)(struct coresight_device *csdev, int iport, int oport);
+ void (*panic_cb)(void *data);
};
/**
@@ -227,6 +232,7 @@ struct coresight_ops_link {
* to the HW.
* @enable: enables tracing for a source.
* @disable: disables tracing for a source.
+ * @panic_cb: hook function for panic notifier.
*/
struct coresight_ops_source {
int (*cpu_id)(struct coresight_device *csdev);
@@ -235,6 +241,7 @@ struct coresight_ops_source {
struct perf_event *event, u32 mode);
void (*disable)(struct coresight_device *csdev,
struct perf_event *event);
+ void (*panic_cb)(void *data);
};
struct coresight_ops {
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/6] doc: Add documentation for Coresight panic kdump
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
Add detailed documentation for Coresight panic kdump, which contains
the idea for why need this and introduce the framework implementation
and usage.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
.../trace/coresight/coresight-panic-kdump.txt | 91 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 92 insertions(+)
create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
diff --git a/Documentation/trace/coresight/coresight-panic-kdump.txt b/Documentation/trace/coresight/coresight-panic-kdump.txt
new file mode 100644
index 0000000..6bf9cac
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-panic-kdump.txt
@@ -0,0 +1,91 @@
+ Coresight Panic Kdump
+ =====================
+
+ Author: Leo Yan <leo.yan@linaro.org>
+ Date: Dec 21th, 2017
+
+Introduction
+------------
+
+Coresight has different sinks for trace data, the trace data is quite useful
+for postmortem debugging. Embedded Trace Buffer (ETB) is one type sink which
+provides on-chip storage of trace data, usually uses SRAM as buffer with
+several KBs size; if the SoC designs to support 'Local ETF' (ARM DDI 0461B,
+chapter 1.2.7), every CPU has one local ETB buffer so the per CPU trace data
+can avoid to be overwritted by other CPUs. Trace Memory Controller (TMC) is
+another kind sink designed as a successor to the CoreSight ETB to capture trace
+into DRAM.
+
+After Linux kernel trigger panic, the trace data keeps the last execution flow
+before issues happen. We could consider the trace data is quite useful for
+postmortem debugging, especially when we can record trace data into DRAM and rely
+on kdump to save them into vmcore file; at the end we can retrieve trace data
+from vmcore file and "offline" to analyze the execution flow.
+
+
+Implementation
+--------------
+
+Coresight panic kdump is a simple framework to support dump functionality,
+it maintains dump list with every node recording the dump buffer base address
+and buffer size. Coresight panic kdump provides the general APIs
+{coresight_kdump_add|coresight_kdump_del} as helper functions so any coresight
+device can add itself into dump list or delete as needed.
+
+Generally coresight device set its 'panic_cb' in the ops structure, the panic
+notifier iterates dump list and invokes callback function to dump device specific
+info.
+
+For easily used by offline analysis, we also record tracer metadata so can
+retrieve tracer IDs and configuration, in this case the node records CPU number so
+can create connection between the metadata and specific CPU. The tracer
+driver uses helper function coresight_kdump_update() to update the dump
+buffer base address and buffer size; so the tracer can save metadata at runtime
+and these info can be prepared well pre panic happening.
+
+
+Usage
+-----
+
+Build Linux kernel with enabling 'CONFIG_CORESIGHT_PANIC_KDUMP' configuration.
+
+After system booting up, we need firstly prepare dump-capture kernel, this can
+refer doc [1] chapter 'Load the Dump-capture Kernel' for detailed steps. Then
+we need enable the coresight tracer, this can use either perf framework method
+or sysFS interface, please refer doc [2] chapter 'How to use the tracer modules'
+for detailed steps.
+
+When kernel panic happens, the panic kdump records trace data and launches
+dump-capture kernel, we can utilize the dump-capture kernel to save kernel dump
+file, this can refer doc [1] chapter 'Write Out the Dump File'.
+
+After get kernel dump file, we can use 'crash' tool + csdump.so extension to
+extract trace data and generate 'perf.data' file:
+
+ ./crash vmcore vmlinux
+ crash> extend csdump.so
+ crash> csdump output_dir
+
+ We can see in the 'output_dir' there will generate out three files:
+ output_dir/
+ ??? cstrace.bin -> trace raw data
+ ??? metadata.bin -> meta data
+ ??? perf.data -> 'perf' format compatible file
+
+Finally use 'perf' tool for offline analysis:
+
+ ./perf script -v -F cpu,event,ip,sym,symoff -i perf.data -k vmlinux --kallsyms /proc/kallsyms
+ [001] instructions: ffff000008559ad0 pl011_console_write+0x90
+ [001] instructions: ffff000008559230 pl011_read+0x0
+ [001] instructions: ffff00000855924c pl011_read+0x1c
+ [001] instructions: ffff000008559ae0 pl011_console_write+0xa0
+ [001] instructions: ffff000008559ad0 pl011_console_write+0x90
+ [001] instructions: ffff000008559230 pl011_read+0x0
+ [001] instructions: ffff00000855924c pl011_read+0x1c
+ [001] instructions: ffff000008559ae0 pl011_console_write+0xa0
+ [001] instructions: ffff000008559ad0 pl011_console_write+0x90
+ [001] instructions: ffff000008559230 pl011_read+0x0
+ [001] instructions: ffff00000855924c pl011_read+0x1c
+
+[1] Documentation/kdump/kdump.txt
+[2] Documentation/trace/coresight/coresight.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index d7a6fc7..26276e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1309,6 +1309,7 @@ S: Maintained
F: drivers/hwtracing/coresight/*
F: Documentation/trace/coresight/coresight.txt
F: Documentation/trace/coresight/coresight-cpu-debug.txt
+F: Documentation/trace/coresight/coresight-panic-kdump.txt
F: Documentation/devicetree/bindings/arm/coresight.txt
F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/6] doc: Add Coresight documentation directory
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513844415-11427-1-git-send-email-leo.yan@linaro.org>
For easily management and friendly adding more Coresight related
documentations, this commit creates one dedicated directory:
Documentation/trace/coresight. It moves Coresight related docs into
this new directory and updates MAINTAINERS file to reflect docs
movement.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
Documentation/trace/coresight-cpu-debug.txt | 187 ------------
Documentation/trace/coresight.txt | 332 ---------------------
.../trace/coresight/coresight-cpu-debug.txt | 187 ++++++++++++
Documentation/trace/coresight/coresight.txt | 332 +++++++++++++++++++++
MAINTAINERS | 4 +-
5 files changed, 521 insertions(+), 521 deletions(-)
delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
delete mode 100644 Documentation/trace/coresight.txt
create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
create mode 100644 Documentation/trace/coresight/coresight.txt
diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.txt
deleted file mode 100644
index 2b9b51c..0000000
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ /dev/null
@@ -1,187 +0,0 @@
- Coresight CPU Debug Module
- ==========================
-
- Author: Leo Yan <leo.yan@linaro.org>
- Date: April 5th, 2017
-
-Introduction
-------------
-
-Coresight CPU debug module is defined in ARMv8-a architecture reference manual
-(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
-debug module and it is mainly used for two modes: self-hosted debug and
-external debug. Usually the external debug mode is well known as the external
-debugger connects with SoC from JTAG port; on the other hand the program can
-explore debugging method which rely on self-hosted debug mode, this document
-is to focus on this part.
-
-The debug module provides sample-based profiling extension, which can be used
-to sample CPU program counter, secure state and exception level, etc; usually
-every CPU has one dedicated debug module to be connected. Based on self-hosted
-debug mechanism, Linux kernel can access these related registers from mmio
-region when the kernel panic happens. The callback notifier for kernel panic
-will dump related registers for every CPU; finally this is good for assistant
-analysis for panic.
-
-
-Implementation
---------------
-
-- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
- registers to decide if sample-based profiling is implemented or not. On some
- platforms this hardware feature is fully or partially implemented; and if
- this feature is not supported then registration will fail.
-
-- At the time this documentation was written, the debug driver mainly relies on
- information gathered by the kernel panic callback notifier from three
- sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get
- program counter; EDVIDSR has information for secure state, exception level,
- bit width, etc; EDCIDSR is context ID value which contains the sampled value
- of CONTEXTIDR_EL1.
-
-- The driver supports a CPU running in either AArch64 or AArch32 mode. The
- registers naming convention is a bit different between them, AArch64 uses
- 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
- 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
- use AArch64 naming convention.
-
-- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
- register bits definition. So the driver consolidates two difference:
-
- If PCSROffset=0b0000, on ARMv8-a the feature of EDPCSR is not implemented;
- but ARMv7-a defines "PCSR samples are offset by a value that depends on the
- instruction set state". For ARMv7-a, the driver checks furthermore if CPU
- runs with ARM or thumb instruction set and calibrate PCSR value, the
- detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
- C11.11.34 "DBGPCSR, Program Counter Sampling Register".
-
- If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
- no offset applied and do not sample the instruction set state in AArch32
- state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
- in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
- state EDPCSR is sampled and no offset are applied.
-
-
-Clock and power domain
-----------------------
-
-Before accessing debug registers, we should ensure the clock and power domain
-have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
-Debug registers', the debug registers are spread into two domains: the debug
-domain and the CPU domain.
-
- +---------------+
- | |
- | |
- +----------+--+ |
- dbg_clock -->| |**| |<-- cpu_clock
- | Debug |**| CPU |
- dbg_power_domain -->| |**| |<-- cpu_power_domain
- +----------+--+ |
- | |
- | |
- +---------------+
-
-For debug domain, the user uses DT binding "clocks" and "power-domains" to
-specify the corresponding clock source and power supply for the debug logic.
-The driver calls the pm_runtime_{put|get} operations as needed to handle the
-debug power domain.
-
-For CPU domain, the different SoC designs have different power management
-schemes and finally this heavily impacts external debug module. So we can
-divide into below cases:
-
-- On systems with a sane power controller which can behave correctly with
- respect to CPU power domain, the CPU power domain can be controlled by
- register EDPRCR in driver. The driver firstly writes bit EDPRCR.COREPURQ
- to power up the CPU, and then writes bit EDPRCR.CORENPDRQ for emulation
- of CPU power down. As result, this can ensure the CPU power domain is
- powered on properly during the period when access debug related registers;
-
-- Some designs will power down an entire cluster if all CPUs on the cluster
- are powered down - including the parts of the debug registers that should
- remain powered in the debug power domain. The bits in EDPRCR are not
- respected in these cases, so these designs do not support debug over
- power down in the way that the CoreSight / Debug designers anticipated.
- This means that even checking EDPRSR has the potential to cause a bus hang
- if the target register is unpowered.
-
- In this case, accessing to the debug registers while they are not powered
- is a recipe for disaster; so we need preventing CPU low power states at boot
- time or when user enable module at the run time. Please see chapter
- "How to use the module" for detailed usage info for this.
-
-
-Device Tree Bindings
---------------------
-
-See Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt for details.
-
-
-How to use the module
----------------------
-
-If you want to enable debugging functionality@boot time, you can add
-"coresight_cpu_debug.enable=1" to the kernel command line parameter.
-
-The driver also can work as module, so can enable the debugging when insmod
-module:
-# insmod coresight_cpu_debug.ko debug=1
-
-When boot time or insmod module you have not enabled the debugging, the driver
-uses the debugfs file system to provide a knob to dynamically enable or disable
-debugging:
-
-To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
-# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
-
-To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
-# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
-
-As explained in chapter "Clock and power domain", if you are working on one
-platform which has idle states to power off debug logic and the power
-controller cannot work well for the request from EDPRCR, then you should
-firstly constraint CPU idle states before enable CPU debugging feature; so can
-ensure the accessing to debug logic.
-
-If you want to limit idle states at boot time, you can use "nohlt" or
-"cpuidle.off=1" in the kernel command line.
-
-At the runtime you can disable idle states with below methods:
-
-It is possible to disable CPU idle states by way of the PM QoS
-subsystem, more specifically by using the "/dev/cpu_dma_latency"
-interface (see Documentation/power/pm_qos_interface.txt for more
-details). As specified in the PM QoS documentation the requested
-parameter will stay in effect until the file descriptor is released.
-For example:
-
-# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
-...
-Do some work...
-...
-# exec 3<>-
-
-The same can also be done from an application program.
-
-Disable specific CPU's specific idle state from cpuidle sysfs (see
-Documentation/cpuidle/sysfs.txt):
-# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
-
-
-Output format
--------------
-
-Here is an example of the debugging output format:
-
-ARM external debug module:
-coresight-cpu-debug 850000.debug: CPU[0]:
-coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
-coresight-cpu-debug 850000.debug: EDPCSR: [<ffff00000808e9bc>] handle_IPI+0x174/0x1d8
-coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
-coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
-coresight-cpu-debug 852000.debug: CPU[1]:
-coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
-coresight-cpu-debug 852000.debug: EDPCSR: [<ffff0000087fab34>] debug_notifier_call+0x23c/0x358
-coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
-coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
deleted file mode 100644
index a33c88c..0000000
--- a/Documentation/trace/coresight.txt
+++ /dev/null
@@ -1,332 +0,0 @@
- Coresight - HW Assisted Tracing on ARM
- ======================================
-
- Author: Mathieu Poirier <mathieu.poirier@linaro.org>
- Date: September 11th, 2014
-
-Introduction
-------------
-
-Coresight is an umbrella of technologies allowing for the debugging of ARM
-based SoC. It includes solutions for JTAG and HW assisted tracing. This
-document is concerned with the latter.
-
-HW assisted tracing is becoming increasingly useful when dealing with systems
-that have many SoCs and other components like GPU and DMA engines. ARM has
-developed a HW assisted tracing solution by means of different components, each
-being added to a design at synthesis time to cater to specific tracing needs.
-Components are generally categorised as source, link and sinks and are
-(usually) discovered using the AMBA bus.
-
-"Sources" generate a compressed stream representing the processor instruction
-path based on tracing scenarios as configured by users. From there the stream
-flows through the coresight system (via ATB bus) using links that are connecting
-the emanating source to a sink(s). Sinks serve as endpoints to the coresight
-implementation, either storing the compressed stream in a memory buffer or
-creating an interface to the outside world where data can be transferred to a
-host without fear of filling up the onboard coresight memory buffer.
-
-At typical coresight system would look like this:
-
- *****************************************************************
- **************************** AMBA AXI ****************************===||
- ***************************************************************** ||
- ^ ^ | ||
- | | * **
- 0000000 ::::: 0000000 ::::: ::::: @@@@@@@ ||||||||||||
- 0 CPU 0<-->: C : 0 CPU 0<-->: C : : C : @ STM @ || System ||
- |->0000000 : T : |->0000000 : T : : T :<--->@@@@@ || Memory ||
- | #######<-->: I : | #######<-->: I : : I : @@@<-| ||||||||||||
- | # ETM # ::::: | # PTM # ::::: ::::: @ |
- | ##### ^ ^ | ##### ^ ! ^ ! . | |||||||||
- | |->### | ! | |->### | ! | ! . | || DAP ||
- | | # | ! | | # | ! | ! . | |||||||||
- | | . | ! | | . | ! | ! . | | |
- | | . | ! | | . | ! | ! . | | *
- | | . | ! | | . | ! | ! . | | SWD/
- | | . | ! | | . | ! | ! . | | JTAG
- *****************************************************************<-|
- *************************** AMBA Debug APB ************************
- *****************************************************************
- | . ! . ! ! . |
- | . * . * * . |
- *****************************************************************
- ******************** Cross Trigger Matrix (CTM) *******************
- *****************************************************************
- | . ^ . . |
- | * ! * * |
- *****************************************************************
- ****************** AMBA Advanced Trace Bus (ATB) ******************
- *****************************************************************
- | ! =============== |
- | * ===== F =====<---------|
- | ::::::::: ==== U ====
- |-->:: CTI ::<!! === N ===
- | ::::::::: ! == N ==
- | ^ * == E ==
- | ! &&&&&&&&& IIIIIII == L ==
- |------>&& ETB &&<......II I =======
- | ! &&&&&&&&& II I .
- | ! I I .
- | ! I REP I<..........
- | ! I I
- | !!>&&&&&&&&& II I *Source: ARM ltd.
- |------>& TPIU &<......II I DAP = Debug Access Port
- &&&&&&&&& IIIIIII ETM = Embedded Trace Macrocell
- ; PTM = Program Trace Macrocell
- ; CTI = Cross Trigger Interface
- * ETB = Embedded Trace Buffer
- To trace port TPIU= Trace Port Interface Unit
- SWD = Serial Wire Debug
-
-While on target configuration of the components is done via the APB bus,
-all trace data are carried out-of-band on the ATB bus. The CTM provides
-a way to aggregate and distribute signals between CoreSight components.
-
-The coresight framework provides a central point to represent, configure and
-manage coresight devices on a platform. This first implementation centers on
-the basic tracing functionality, enabling components such ETM/PTM, funnel,
-replicator, TMC, TPIU and ETB. Future work will enable more
-intricate IP blocks such as STM and CTI.
-
-
-Acronyms and Classification
----------------------------
-
-Acronyms:
-
-PTM: Program Trace Macrocell
-ETM: Embedded Trace Macrocell
-STM: System trace Macrocell
-ETB: Embedded Trace Buffer
-ITM: Instrumentation Trace Macrocell
-TPIU: Trace Port Interface Unit
-TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
-TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
-CTI: Cross Trigger Interface
-
-Classification:
-
-Source:
- ETMv3.x ETMv4, PTMv1.0, PTMv1.1, STM, STM500, ITM
-Link:
- Funnel, replicator (intelligent or not), TMC-ETR
-Sinks:
- ETBv1.0, ETB1.1, TPIU, TMC-ETF
-Misc:
- CTI
-
-
-Device Tree Bindings
-----------------------
-
-See Documentation/devicetree/bindings/arm/coresight.txt for details.
-
-As of this writing drivers for ITM, STMs and CTIs are not provided but are
-expected to be added as the solution matures.
-
-
-Framework and implementation
-----------------------------
-
-The coresight framework provides a central point to represent, configure and
-manage coresight devices on a platform. Any coresight compliant device can
-register with the framework for as long as they use the right APIs:
-
-struct coresight_device *coresight_register(struct coresight_desc *desc);
-void coresight_unregister(struct coresight_device *csdev);
-
-The registering function is taking a "struct coresight_device *csdev" and
-register the device with the core framework. The unregister function takes
-a reference to a "struct coresight_device", obtained@registration time.
-
-If everything goes well during the registration process the new devices will
-show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
-
-root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
-root:~#
-
-The functions take a "struct coresight_device", which looks like this:
-
-struct coresight_desc {
- enum coresight_dev_type type;
- struct coresight_dev_subtype subtype;
- const struct coresight_ops *ops;
- struct coresight_platform_data *pdata;
- struct device *dev;
- const struct attribute_group **groups;
-};
-
-
-The "coresight_dev_type" identifies what the device is, i.e, source link or
-sink while the "coresight_dev_subtype" will characterise that type further.
-
-The "struct coresight_ops" is mandatory and will tell the framework how to
-perform base operations related to the components, each component having
-a different set of requirement. For that "struct coresight_ops_sink",
-"struct coresight_ops_link" and "struct coresight_ops_source" have been
-provided.
-
-The next field, "struct coresight_platform_data *pdata" is acquired by calling
-"of_get_coresight_platform_data()", as part of the driver's _probe routine and
-"struct device *dev" gets the device reference embedded in the "amba_device":
-
-static int etm_probe(struct amba_device *adev, const struct amba_id *id)
-{
- ...
- ...
- drvdata->dev = &adev->dev;
- ...
-}
-
-Specific class of device (source, link, or sink) have generic operations
-that can be performed on them (see "struct coresight_ops"). The
-"**groups" is a list of sysfs entries pertaining to operations
-specific to that component only. "Implementation defined" customisations are
-expected to be accessed and controlled using those entries.
-
-Last but not least, "struct module *owner" is expected to be set to reflect
-the information carried in "THIS_MODULE".
-
-How to use the tracer modules
------------------------------
-
-Before trace collection can start, a coresight sink needs to be identify.
-There is no limit on the amount of sinks (nor sources) that can be enabled at
-any given moment. As a generic operation, all device pertaining to the sink
-class will have an "active" entry in sysfs:
-
-root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
-root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
-root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
-root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
-1
-root:/sys/bus/coresight/devices#
-
-At boot time the current etm3x driver will configure the first address
-comparator with "_stext" and "_etext", essentially tracing any instruction
-that falls within that range. As such "enabling" a source will immediately
-trigger a trace capture:
-
-root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
-root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
-1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
-
-Trace collection is stopped the same way:
-
-root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
-root:/sys/bus/coresight/devices#
-
-The content of the ETB buffer can be harvested directly from /dev:
-
-root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
-of=~/cstrace.bin
-
-64+0 records in
-64+0 records out
-32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
-root:/sys/bus/coresight/devices#
-
-The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
-
-Following is a DS-5 output of an experimental loop that increments a variable up
-to a certain value. The example is simple and yet provides a glimpse of the
-wealth of possibilities that coresight provides.
-
-Info Tracing enabled
-Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
-Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
-Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
-Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Timestamp Timestamp: 17106715833
-Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
-Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
-Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
-Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
-Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
-Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
-Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
-Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
-Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
-Info Tracing enabled
-Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
-Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
-Timestamp Timestamp: 17107041535
-
-How to use the STM module
--------------------------
-
-Using the System Trace Macrocell module is the same as the tracers - the only
-difference is that clients are driving the trace capture rather
-than the program flow through the code.
-
-As with any other CoreSight component, specifics about the STM tracer can be
-found in sysfs with more information on each entry being found in [1]:
-
-root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
-enable_source hwevent_select port_enable subsystem uevent
-hwevent_enable mgmt port_select traceid
-root at genericarmv8:~#
-
-Like any other source a sink needs to be identified and the STM enabled before
-being used:
-
-root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
-root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
-
-From there user space applications can request and use channels using the devfs
-interface provided for that purpose by the generic STM API:
-
-root at genericarmv8:~# ls -l /dev/20100000.stm
-crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
-root at genericarmv8:~#
-
-Details on how to use the generic STM API can be found here [2].
-
-[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-[2]. Documentation/trace/stm.txt
diff --git a/Documentation/trace/coresight/coresight-cpu-debug.txt b/Documentation/trace/coresight/coresight-cpu-debug.txt
new file mode 100644
index 0000000..2b9b51c
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-cpu-debug.txt
@@ -0,0 +1,187 @@
+ Coresight CPU Debug Module
+ ==========================
+
+ Author: Leo Yan <leo.yan@linaro.org>
+ Date: April 5th, 2017
+
+Introduction
+------------
+
+Coresight CPU debug module is defined in ARMv8-a architecture reference manual
+(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate
+debug module and it is mainly used for two modes: self-hosted debug and
+external debug. Usually the external debug mode is well known as the external
+debugger connects with SoC from JTAG port; on the other hand the program can
+explore debugging method which rely on self-hosted debug mode, this document
+is to focus on this part.
+
+The debug module provides sample-based profiling extension, which can be used
+to sample CPU program counter, secure state and exception level, etc; usually
+every CPU has one dedicated debug module to be connected. Based on self-hosted
+debug mechanism, Linux kernel can access these related registers from mmio
+region when the kernel panic happens. The callback notifier for kernel panic
+will dump related registers for every CPU; finally this is good for assistant
+analysis for panic.
+
+
+Implementation
+--------------
+
+- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID
+ registers to decide if sample-based profiling is implemented or not. On some
+ platforms this hardware feature is fully or partially implemented; and if
+ this feature is not supported then registration will fail.
+
+- At the time this documentation was written, the debug driver mainly relies on
+ information gathered by the kernel panic callback notifier from three
+ sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get
+ program counter; EDVIDSR has information for secure state, exception level,
+ bit width, etc; EDCIDSR is context ID value which contains the sampled value
+ of CONTEXTIDR_EL1.
+
+- The driver supports a CPU running in either AArch64 or AArch32 mode. The
+ registers naming convention is a bit different between them, AArch64 uses
+ 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses
+ 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to
+ use AArch64 naming convention.
+
+- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different
+ register bits definition. So the driver consolidates two difference:
+
+ If PCSROffset=0b0000, on ARMv8-a the feature of EDPCSR is not implemented;
+ but ARMv7-a defines "PCSR samples are offset by a value that depends on the
+ instruction set state". For ARMv7-a, the driver checks furthermore if CPU
+ runs with ARM or thumb instruction set and calibrate PCSR value, the
+ detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter
+ C11.11.34 "DBGPCSR, Program Counter Sampling Register".
+
+ If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have
+ no offset applied and do not sample the instruction set state in AArch32
+ state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates
+ in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64
+ state EDPCSR is sampled and no offset are applied.
+
+
+Clock and power domain
+----------------------
+
+Before accessing debug registers, we should ensure the clock and power domain
+have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
+Debug registers', the debug registers are spread into two domains: the debug
+domain and the CPU domain.
+
+ +---------------+
+ | |
+ | |
+ +----------+--+ |
+ dbg_clock -->| |**| |<-- cpu_clock
+ | Debug |**| CPU |
+ dbg_power_domain -->| |**| |<-- cpu_power_domain
+ +----------+--+ |
+ | |
+ | |
+ +---------------+
+
+For debug domain, the user uses DT binding "clocks" and "power-domains" to
+specify the corresponding clock source and power supply for the debug logic.
+The driver calls the pm_runtime_{put|get} operations as needed to handle the
+debug power domain.
+
+For CPU domain, the different SoC designs have different power management
+schemes and finally this heavily impacts external debug module. So we can
+divide into below cases:
+
+- On systems with a sane power controller which can behave correctly with
+ respect to CPU power domain, the CPU power domain can be controlled by
+ register EDPRCR in driver. The driver firstly writes bit EDPRCR.COREPURQ
+ to power up the CPU, and then writes bit EDPRCR.CORENPDRQ for emulation
+ of CPU power down. As result, this can ensure the CPU power domain is
+ powered on properly during the period when access debug related registers;
+
+- Some designs will power down an entire cluster if all CPUs on the cluster
+ are powered down - including the parts of the debug registers that should
+ remain powered in the debug power domain. The bits in EDPRCR are not
+ respected in these cases, so these designs do not support debug over
+ power down in the way that the CoreSight / Debug designers anticipated.
+ This means that even checking EDPRSR has the potential to cause a bus hang
+ if the target register is unpowered.
+
+ In this case, accessing to the debug registers while they are not powered
+ is a recipe for disaster; so we need preventing CPU low power states at boot
+ time or when user enable module at the run time. Please see chapter
+ "How to use the module" for detailed usage info for this.
+
+
+Device Tree Bindings
+--------------------
+
+See Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt for details.
+
+
+How to use the module
+---------------------
+
+If you want to enable debugging functionality@boot time, you can add
+"coresight_cpu_debug.enable=1" to the kernel command line parameter.
+
+The driver also can work as module, so can enable the debugging when insmod
+module:
+# insmod coresight_cpu_debug.ko debug=1
+
+When boot time or insmod module you have not enabled the debugging, the driver
+uses the debugfs file system to provide a knob to dynamically enable or disable
+debugging:
+
+To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
+# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
+
+To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
+# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
+
+As explained in chapter "Clock and power domain", if you are working on one
+platform which has idle states to power off debug logic and the power
+controller cannot work well for the request from EDPRCR, then you should
+firstly constraint CPU idle states before enable CPU debugging feature; so can
+ensure the accessing to debug logic.
+
+If you want to limit idle states at boot time, you can use "nohlt" or
+"cpuidle.off=1" in the kernel command line.
+
+At the runtime you can disable idle states with below methods:
+
+It is possible to disable CPU idle states by way of the PM QoS
+subsystem, more specifically by using the "/dev/cpu_dma_latency"
+interface (see Documentation/power/pm_qos_interface.txt for more
+details). As specified in the PM QoS documentation the requested
+parameter will stay in effect until the file descriptor is released.
+For example:
+
+# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
+...
+Do some work...
+...
+# exec 3<>-
+
+The same can also be done from an application program.
+
+Disable specific CPU's specific idle state from cpuidle sysfs (see
+Documentation/cpuidle/sysfs.txt):
+# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
+
+
+Output format
+-------------
+
+Here is an example of the debugging output format:
+
+ARM external debug module:
+coresight-cpu-debug 850000.debug: CPU[0]:
+coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
+coresight-cpu-debug 850000.debug: EDPCSR: [<ffff00000808e9bc>] handle_IPI+0x174/0x1d8
+coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
+coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
+coresight-cpu-debug 852000.debug: CPU[1]:
+coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
+coresight-cpu-debug 852000.debug: EDPCSR: [<ffff0000087fab34>] debug_notifier_call+0x23c/0x358
+coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
+coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
diff --git a/Documentation/trace/coresight/coresight.txt b/Documentation/trace/coresight/coresight.txt
new file mode 100644
index 0000000..a33c88c
--- /dev/null
+++ b/Documentation/trace/coresight/coresight.txt
@@ -0,0 +1,332 @@
+ Coresight - HW Assisted Tracing on ARM
+ ======================================
+
+ Author: Mathieu Poirier <mathieu.poirier@linaro.org>
+ Date: September 11th, 2014
+
+Introduction
+------------
+
+Coresight is an umbrella of technologies allowing for the debugging of ARM
+based SoC. It includes solutions for JTAG and HW assisted tracing. This
+document is concerned with the latter.
+
+HW assisted tracing is becoming increasingly useful when dealing with systems
+that have many SoCs and other components like GPU and DMA engines. ARM has
+developed a HW assisted tracing solution by means of different components, each
+being added to a design at synthesis time to cater to specific tracing needs.
+Components are generally categorised as source, link and sinks and are
+(usually) discovered using the AMBA bus.
+
+"Sources" generate a compressed stream representing the processor instruction
+path based on tracing scenarios as configured by users. From there the stream
+flows through the coresight system (via ATB bus) using links that are connecting
+the emanating source to a sink(s). Sinks serve as endpoints to the coresight
+implementation, either storing the compressed stream in a memory buffer or
+creating an interface to the outside world where data can be transferred to a
+host without fear of filling up the onboard coresight memory buffer.
+
+At typical coresight system would look like this:
+
+ *****************************************************************
+ **************************** AMBA AXI ****************************===||
+ ***************************************************************** ||
+ ^ ^ | ||
+ | | * **
+ 0000000 ::::: 0000000 ::::: ::::: @@@@@@@ ||||||||||||
+ 0 CPU 0<-->: C : 0 CPU 0<-->: C : : C : @ STM @ || System ||
+ |->0000000 : T : |->0000000 : T : : T :<--->@@@@@ || Memory ||
+ | #######<-->: I : | #######<-->: I : : I : @@@<-| ||||||||||||
+ | # ETM # ::::: | # PTM # ::::: ::::: @ |
+ | ##### ^ ^ | ##### ^ ! ^ ! . | |||||||||
+ | |->### | ! | |->### | ! | ! . | || DAP ||
+ | | # | ! | | # | ! | ! . | |||||||||
+ | | . | ! | | . | ! | ! . | | |
+ | | . | ! | | . | ! | ! . | | *
+ | | . | ! | | . | ! | ! . | | SWD/
+ | | . | ! | | . | ! | ! . | | JTAG
+ *****************************************************************<-|
+ *************************** AMBA Debug APB ************************
+ *****************************************************************
+ | . ! . ! ! . |
+ | . * . * * . |
+ *****************************************************************
+ ******************** Cross Trigger Matrix (CTM) *******************
+ *****************************************************************
+ | . ^ . . |
+ | * ! * * |
+ *****************************************************************
+ ****************** AMBA Advanced Trace Bus (ATB) ******************
+ *****************************************************************
+ | ! =============== |
+ | * ===== F =====<---------|
+ | ::::::::: ==== U ====
+ |-->:: CTI ::<!! === N ===
+ | ::::::::: ! == N ==
+ | ^ * == E ==
+ | ! &&&&&&&&& IIIIIII == L ==
+ |------>&& ETB &&<......II I =======
+ | ! &&&&&&&&& II I .
+ | ! I I .
+ | ! I REP I<..........
+ | ! I I
+ | !!>&&&&&&&&& II I *Source: ARM ltd.
+ |------>& TPIU &<......II I DAP = Debug Access Port
+ &&&&&&&&& IIIIIII ETM = Embedded Trace Macrocell
+ ; PTM = Program Trace Macrocell
+ ; CTI = Cross Trigger Interface
+ * ETB = Embedded Trace Buffer
+ To trace port TPIU= Trace Port Interface Unit
+ SWD = Serial Wire Debug
+
+While on target configuration of the components is done via the APB bus,
+all trace data are carried out-of-band on the ATB bus. The CTM provides
+a way to aggregate and distribute signals between CoreSight components.
+
+The coresight framework provides a central point to represent, configure and
+manage coresight devices on a platform. This first implementation centers on
+the basic tracing functionality, enabling components such ETM/PTM, funnel,
+replicator, TMC, TPIU and ETB. Future work will enable more
+intricate IP blocks such as STM and CTI.
+
+
+Acronyms and Classification
+---------------------------
+
+Acronyms:
+
+PTM: Program Trace Macrocell
+ETM: Embedded Trace Macrocell
+STM: System trace Macrocell
+ETB: Embedded Trace Buffer
+ITM: Instrumentation Trace Macrocell
+TPIU: Trace Port Interface Unit
+TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
+TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
+CTI: Cross Trigger Interface
+
+Classification:
+
+Source:
+ ETMv3.x ETMv4, PTMv1.0, PTMv1.1, STM, STM500, ITM
+Link:
+ Funnel, replicator (intelligent or not), TMC-ETR
+Sinks:
+ ETBv1.0, ETB1.1, TPIU, TMC-ETF
+Misc:
+ CTI
+
+
+Device Tree Bindings
+----------------------
+
+See Documentation/devicetree/bindings/arm/coresight.txt for details.
+
+As of this writing drivers for ITM, STMs and CTIs are not provided but are
+expected to be added as the solution matures.
+
+
+Framework and implementation
+----------------------------
+
+The coresight framework provides a central point to represent, configure and
+manage coresight devices on a platform. Any coresight compliant device can
+register with the framework for as long as they use the right APIs:
+
+struct coresight_device *coresight_register(struct coresight_desc *desc);
+void coresight_unregister(struct coresight_device *csdev);
+
+The registering function is taking a "struct coresight_device *csdev" and
+register the device with the core framework. The unregister function takes
+a reference to a "struct coresight_device", obtained@registration time.
+
+If everything goes well during the registration process the new devices will
+show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
+
+root:~# ls /sys/bus/coresight/devices/
+replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+root:~#
+
+The functions take a "struct coresight_device", which looks like this:
+
+struct coresight_desc {
+ enum coresight_dev_type type;
+ struct coresight_dev_subtype subtype;
+ const struct coresight_ops *ops;
+ struct coresight_platform_data *pdata;
+ struct device *dev;
+ const struct attribute_group **groups;
+};
+
+
+The "coresight_dev_type" identifies what the device is, i.e, source link or
+sink while the "coresight_dev_subtype" will characterise that type further.
+
+The "struct coresight_ops" is mandatory and will tell the framework how to
+perform base operations related to the components, each component having
+a different set of requirement. For that "struct coresight_ops_sink",
+"struct coresight_ops_link" and "struct coresight_ops_source" have been
+provided.
+
+The next field, "struct coresight_platform_data *pdata" is acquired by calling
+"of_get_coresight_platform_data()", as part of the driver's _probe routine and
+"struct device *dev" gets the device reference embedded in the "amba_device":
+
+static int etm_probe(struct amba_device *adev, const struct amba_id *id)
+{
+ ...
+ ...
+ drvdata->dev = &adev->dev;
+ ...
+}
+
+Specific class of device (source, link, or sink) have generic operations
+that can be performed on them (see "struct coresight_ops"). The
+"**groups" is a list of sysfs entries pertaining to operations
+specific to that component only. "Implementation defined" customisations are
+expected to be accessed and controlled using those entries.
+
+Last but not least, "struct module *owner" is expected to be set to reflect
+the information carried in "THIS_MODULE".
+
+How to use the tracer modules
+-----------------------------
+
+Before trace collection can start, a coresight sink needs to be identify.
+There is no limit on the amount of sinks (nor sources) that can be enabled at
+any given moment. As a generic operation, all device pertaining to the sink
+class will have an "active" entry in sysfs:
+
+root:/sys/bus/coresight/devices# ls
+replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+root:/sys/bus/coresight/devices# ls 20010000.etb
+enable_sink status trigger_cntr
+root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
+root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
+1
+root:/sys/bus/coresight/devices#
+
+At boot time the current etm3x driver will configure the first address
+comparator with "_stext" and "_etext", essentially tracing any instruction
+that falls within that range. As such "enabling" a source will immediately
+trigger a trace capture:
+
+root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
+root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
+1
+root:/sys/bus/coresight/devices# cat 20010000.etb/status
+Depth: 0x2000
+Status: 0x1
+RAM read ptr: 0x0
+RAM wrt ptr: 0x19d3 <----- The write pointer is moving
+Trigger cnt: 0x0
+Control: 0x1
+Flush status: 0x0
+Flush ctrl: 0x2001
+root:/sys/bus/coresight/devices#
+
+Trace collection is stopped the same way:
+
+root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
+root:/sys/bus/coresight/devices#
+
+The content of the ETB buffer can be harvested directly from /dev:
+
+root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
+of=~/cstrace.bin
+
+64+0 records in
+64+0 records out
+32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
+root:/sys/bus/coresight/devices#
+
+The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
+
+Following is a DS-5 output of an experimental loop that increments a variable up
+to a certain value. The example is simple and yet provides a glimpse of the
+wealth of possibilities that coresight provides.
+
+Info Tracing enabled
+Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
+Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
+Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
+Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Timestamp Timestamp: 17106715833
+Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
+Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
+Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
+Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
+Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
+Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
+Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
+Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
+Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
+Info Tracing enabled
+Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
+Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
+Timestamp Timestamp: 17107041535
+
+How to use the STM module
+-------------------------
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the code.
+
+As with any other CoreSight component, specifics about the STM tracer can be
+found in sysfs with more information on each entry being found in [1]:
+
+root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
+enable_source hwevent_select port_enable subsystem uevent
+hwevent_enable mgmt port_select traceid
+root at genericarmv8:~#
+
+Like any other source a sink needs to be identified and the STM enabled before
+being used:
+
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
+
+From there user space applications can request and use channels using the devfs
+interface provided for that purpose by the generic STM API:
+
+root at genericarmv8:~# ls -l /dev/20100000.stm
+crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
+root at genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [2].
+
+[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+[2]. Documentation/trace/stm.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 4641719..d7a6fc7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1307,8 +1307,8 @@ M: Mathieu Poirier <mathieu.poirier@linaro.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: drivers/hwtracing/coresight/*
-F: Documentation/trace/coresight.txt
-F: Documentation/trace/coresight-cpu-debug.txt
+F: Documentation/trace/coresight/coresight.txt
+F: Documentation/trace/coresight/coresight-cpu-debug.txt
F: Documentation/devicetree/bindings/arm/coresight.txt
F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/6] Coresight: support panic kdump
From: Leo Yan @ 2017-12-21 8:20 UTC (permalink / raw)
To: linux-arm-kernel
This patch set is to explore Coresight trace data for postmortem
debugging. When kernel panic happens, the Coresight panic kdump can
help save on-chip trace data and tracer metadata into DRAM, later
relies on kdump and crash/perf for "offline" analysis.
The documentation is important to understand the purpose of Coresight
panic kdump, the implementation and usage. Patches 0001/0002 are used
to relocate and add related documenation.
Patch 0003 introduces the simple panic kdump framework which can be
easily used by Coresight devices.
Patches 0004/0005 support panic kdump for ETB; Patch 0006 supports
the dump for ETMv4. As Mathieu suggested, patch 0006 distinguish two
different tracer enabling mode: sysFS interface and perf mode.
This patch set have been verified on 96boards Hikey with tracer
enabling by sysFS interface.
Changes from v2:
* Add the two patches for documentation.
* Following Mathieu suggestion, reworked the panic kdump framework,
removed the useless flag "PRE_PANIC".
* According to comment, changed to add and delete kdump node operations
in sink enable/disable functions;
* According to Mathieu suggestion, handle kdump node
addition/deletion/updating separately for sysFS interface and perf
method.
Changes from v1:
* Add support to dump ETMv4 meta data.
* Wrote 'crash' extension csdump.so so rely on it to generate 'perf'
format compatible file.
* Refactored panic dump driver to support pre & post panic dump.
Changes from RFC:
* Follow Mathieu's suggestion, use general framework to support dump
functionality.
* Changed to use perf to analyse trace data.
Leo Yan (6):
doc: Add Coresight documentation directory
doc: Add documentation for Coresight panic kdump
coresight: Support panic kdump functionality
coresight: tmc: Hook callback for panic kdump
coresight: Add and delete sink callback for panic kdump list
coresight: etm4x: Support panic kdump
Documentation/trace/coresight-cpu-debug.txt | 187 ------------
Documentation/trace/coresight.txt | 332 ---------------------
.../trace/coresight/coresight-cpu-debug.txt | 187 ++++++++++++
.../trace/coresight/coresight-panic-kdump.txt | 91 ++++++
Documentation/trace/coresight/coresight.txt | 332 +++++++++++++++++++++
MAINTAINERS | 5 +-
drivers/hwtracing/coresight/Kconfig | 9 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +-
drivers/hwtracing/coresight/coresight-etm4x.c | 23 ++
drivers/hwtracing/coresight/coresight-etm4x.h | 15 +
.../hwtracing/coresight/coresight-panic-kdump.c | 154 ++++++++++
drivers/hwtracing/coresight/coresight-priv.h | 13 +
drivers/hwtracing/coresight/coresight-tmc-etf.c | 29 ++
drivers/hwtracing/coresight/coresight.c | 12 +
include/linux/coresight.h | 7 +
16 files changed, 887 insertions(+), 522 deletions(-)
delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
delete mode 100644 Documentation/trace/coresight.txt
create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
create mode 100644 Documentation/trace/coresight/coresight.txt
create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
--
2.7.4
^ permalink raw reply
* [PATCH] ARM: dts: colibri/apalis: use correct compatible for RTC
From: Shawn Guo @ 2017-12-21 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206102929.4755-1-stefan@agner.ch>
On Wed, Dec 06, 2017 at 11:29:29AM +0100, Stefan Agner wrote:
> All Toradex Carrier Boards use a st,m41t0 compatible RTC. Compared
> to a st,m41t00 this RTC has also an oscillator fail bit which allows
> to detect when the RTC lost track of time.
>
> Cc: Sanchayan Maity <maitysanchayan@gmail.com>
> Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: colibri/apalis: use correct compatible for RTC
From: Shawn Guo @ 2017-12-21 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206102929.4755-1-stefan@agner.ch>
On Wed, Dec 06, 2017 at 11:29:29AM +0100, Stefan Agner wrote:
> All Toradex Carrier Boards use a st,m41t0 compatible RTC. Compared
> to a st,m41t00 this RTC has also an oscillator fail bit which allows
> to detect when the RTC lost track of time.
>
> Cc: Sanchayan Maity <maitysanchayan@gmail.com>
> Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH RESEND v6 0/6] provide power off support for iMX6 with external PMIC
From: Shawn Guo @ 2017-12-21 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206184844.uqbu6rmj4bponpuw@sirena.org.uk>
On Wed, Dec 06, 2017 at 06:48:44PM +0000, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 08:23:56AM +0100, Oleksij Rempel wrote:
> > 2017.12.06:
> > Adding Linus. Probably there is no maintainer for this patch set.
> > No changes are made, tested on v4.15-rc1.
>
> Have any of the i.MX maintainers said anything about this? I was about
> to reply to this asking if they were ever going to review it as it keeps
> on getting resent but I'm not seeing any interest from any of them but
> the main immediate audience is i.MX systems.
I will be happy to take the dts changes, after kernel/reboot and
regulator get accepted (ideally landed on mainline).
Shawn
^ permalink raw reply
* [GIT PULL 3/3] ARM: defconfig: exynos: config for v4.16
From: Krzysztof Kozlowski @ 2017-12-21 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-2-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.16
>
> for you to fetch changes up to 6b732dfb698991b5f518be1ddf329c1c2eb3d7cb:
>
> ARM: exynos_defconfig: Enable CONFIG_EXYNOS_IOMMU (2017-12-14 18:57:38 +0100)
>
> ----------------------------------------------------------------
> Samsung defconfig changes for v4.16
>
> 1. Enable missing drivers for supported Exynos boards (PMU, CEC, MHL
> bridge, ASoC for Odroid XU3/XU4).
> 2. Enable Exynos IOMMU driver on exynos_defconfig.
>
> ----------------------------------------------------------------
> Marek Szyprowski (2):
> ARM: exynos_defconfig: Enable missing drivers for supported Exynos boards
> ARM: multi_v7_defconfig: Enable missing drivers for supported Exynos boards
>
> Shuah Khan (1):
> ARM: exynos_defconfig: Enable CONFIG_EXYNOS_IOMMU
>
> arch/arm/configs/exynos_defconfig | 7 +++++++
> arch/arm/configs/multi_v7_defconfig | 5 +++++
> 2 files changed, 12 insertions(+)
I forgot to mention possible conflict for multi_v7_defconfig (with
changes coming from keystone tree). The resolution is to take
everything from both branches. Something like:
@@@ -558,7 -583,8 +559,9 @@@ CONFIG_VIDEO_STI_DELTA=
CONFIG_VIDEO_RENESAS_JPU=m
CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_V4L_TEST_DRIVERS=y
+CONFIG_VIDEO_VIVID=m
+ CONFIG_CEC_PLATFORM_DRIVERS=y
+ CONFIG_VIDEO_SAMSUNG_S5P_CEC=m
# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
CONFIG_VIDEO_ADV7180=m
CONFIG_VIDEO_ML86V7667=m
@@@ -582,16 -613,12 +585,17 @@@ CONFIG_DRM_RCAR_DU=
CONFIG_DRM_RCAR_LVDS=y
CONFIG_DRM_SUN4I=m
CONFIG_DRM_TEGRA=y
+CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_PANEL_SAMSUNG_LD9040=m
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
-CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_DUMB_VGA_DAC=m
+CONFIG_DRM_NXP_PTN3460=m
+CONFIG_DRM_PARADE_PS8622=m
+CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_I2C_ADV7511_AUDIO=y
+ CONFIG_DRM_SII9234=m
CONFIG_DRM_STI=m
-CONFIG_DRM_VC4=y
+CONFIG_DRM_VC4=m
CONFIG_FB_ARMCLCD=y
CONFIG_FB_EFI=y
CONFIG_FB_WM8505=y
@@@ -626,9 -655,10 +630,10 @@@ CONFIG_SND_SOC_SAMSUNG=
CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994=m
CONFIG_SND_SOC_SMDK_WM8994_PCM=m
CONFIG_SND_SOC_SNOW=m
+ CONFIG_SND_SOC_ODROID=m
CONFIG_SND_SOC_SH4_FSI=m
CONFIG_SND_SOC_RCAR=m
-CONFIG_SND_SIMPLE_SCU_CARD=m
+CONFIG_SND_SOC_STI=m
CONFIG_SND_SUN4I_CODEC=m
CONFIG_SND_SOC_TEGRA=m
CONFIG_SND_SOC_TEGRA20_I2S=m
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH][v3] dt-bindings: ifc: Update endianness usage
From: Prabhakar Kushwaha @ 2017-12-21 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB12413F48FF7E083FD8E0FD36973D0@HE1PR04MB1241.eurprd04.prod.outlook.com>
Hi Rob,
> -----Original Message-----
> From: devicetree-owner at vger.kernel.org [mailto:devicetree-
> owner at vger.kernel.org] On Behalf Of Prabhakar Kushwaha
> Sent: Tuesday, December 05, 2017 2:45 PM
> To: Rob Herring <robh@kernel.org>
> Cc: devicetree at vger.kernel.org; mark.rutland at arm.com;
> shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: RE: [PATCH][v3] dt-bindings: ifc: Update endianness usage
>
>
> > -----Original Message-----
> > From: Rob Herring [mailto:robh at kernel.org]
> > Sent: Tuesday, December 05, 2017 2:17 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> > Cc: devicetree at vger.kernel.org; mark.rutland at arm.com;
> > shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH][v3] dt-bindings: ifc: Update endianness usage
> >
> > On Thu, Nov 30, 2017 at 01:36:36PM +0530, Prabhakar Kushwaha wrote:
> > > IFC controller version < 2.0 support IFC register access as
> > > big endian. These controller version also require IFC NOR signals to
> > > be connected in reverse order with NOR flash.
> > >
> > > IFC >= 2.0 is other way around.
> > >
> > > So updating IFC binding to take care of both using endianness field.
> > >
> > > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> > > ---
> > > Changes for v2: updated subject
> > > Changes for v3: fixed typo for "big-endian"
> > >
> > > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6
> ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/memory-
> controllers/fsl/ifc.txt
> > b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > index 89427b0..824a2ca 100644
> > > --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > @@ -18,8 +18,10 @@ Properties:
> > > interrupt (NAND_EVTER_STAT). If there is only one,
> > > that interrupt reports both types of event.
> > >
> > > -- little-endian : If this property is absent, the big-endian mode will
> > > - be in use as default for registers.
> > > +- little-endian or big-endian : It represents how IFC registers to be accessed.
> > > + It also represents connection between controller and
> > > + NOR flash. If this property is absent, the big-endian
> > > + mode will be in use as default.
> >
> > My question on the prior version remains. I think if you need to handle
> > more than just register endianness, that should be done with the
> > compatible string.
> >
>
> I may not able to use compatible string as this information will also be used it
> drivers/mtd/maps/physmap_of_core.c other than drivers/memory/fsl_ifc.c.
> I am trying to avoid controller specific details in generic file.
>
> This is the reason endianness property is being used.
>
Please let me know if I am not able to address your review comment
--prabhakar
^ permalink raw reply
* [PATCH] ARM: dts: imx: Add memory node unit name
From: Lothar Waßmann @ 2017-12-21 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512575989-15627-1-git-send-email-marcofrk@gmail.com>
Hi,
On Wed, 6 Dec 2017 13:59:49 -0200 Marco Franchi wrote:
> Fix the following warnings from dtc by adding the unit name to memory
> nodes:
>
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>
> Converted using the following command:
>
> perl -p0777i -e 's/memory \{\n\t\treg = \<0x+([0-9a-f])/memory\@$1$\0000000 \{\n\t\treg = <0x$1/m' `find ./arch/arm/boot/dts -name "imx*"`
>
> The files below were manually fixed:
> -imx1-ads.dts
> -imx1-apf9328.dts
>
The imx*.dtsi files all have this:
| memory { device_type = "memory"; reg = <0 0>; };
Thus you will end up with a 'memory' node with a reg = <0 0> entry and
an additional 'memory at ...' node with the correct 'reg' values.
Lothar Wa?mann
^ permalink raw reply
* [PATCH resend] arm: dts: ls1021a: Specify interrupt-affinity for pmu node
From: Shawn Guo @ 2017-12-21 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512462145-12664-1-git-send-email-rasmus.villemoes@prevas.dk>
On Tue, Dec 05, 2017 at 09:22:25AM +0100, Rasmus Villemoes wrote:
> From: Esben Haabendal <eha@deif.com>
>
> From: Esben Haabendal <eha@deif.com>
Dropped the extra From line, fixed prefix and applied patch.
Shawn
>
> This avoids the warning
>
> hw perfevents: no interrupt-affinity property for /pmu, guessing.
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
> [RV: adapt commit log to the warning emitted in current mainline]
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> arch/arm/boot/dts/ls1021a.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 02a266faec9b..96dc1a29fc64 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -106,6 +106,7 @@
> compatible = "arm,cortex-a7-pmu";
> interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu0>, <&cpu1>;
> };
>
> reboot {
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH resend] arm: dts: ls1021a: Add label to USB controllers
From: Shawn Guo @ 2017-12-21 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512461794-12309-1-git-send-email-rasmus.villemoes@prevas.dk>
On Tue, Dec 05, 2017 at 09:16:33AM +0100, Rasmus Villemoes wrote:
> From: Esben Haabendal <eha@deif.com>
>
> Add usb2 and usb3 labels to USB2 and USB3 controller device tree nodes,
> for easier modification in board dts files.
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Fixed prefix and applied the patch.
Shawn
^ permalink raw reply
* [PATCH resend] arm: dts: ls1021a: add reboot node to .dtsi
From: Shawn Guo @ 2017-12-21 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512461568-12102-1-git-send-email-rasmus.villemoes@prevas.dk>
On Tue, Dec 05, 2017 at 09:12:47AM +0100, Rasmus Villemoes wrote:
> The LS1021A can be reset via the dcfg regmap in the same way as the
> arm64 layerscape SoCs, so add the corresponding DT node.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
We use "ARM: ..." instead of "arm: ..." as prefix for DTS patches going
through i.MX tree.
I fixed prefix up and applied the patch.
Shawn
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx51-babbage: Fix the 26MHz clock modelling
From: Shawn Guo @ 2017-12-21 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512246365-3657-2-git-send-email-festevam@gmail.com>
On Sat, Dec 02, 2017 at 06:26:05PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> On imx51-babbage there is a 26MHz oscillator that is gated by GPIO3_1.
>
> The output of this clock feeds audio codec clock and USB PHY clocks,
> which are gated by GPIO4_26 and GPIO2_1 respectively.
>
> Fix the clock representation by properly using gpio-gate-clock.
>
> The clock nodes can be moved out of the 'clocks' node.
>
> Based on a commit from Lucas Stach for imx51-zii-rdu1 board.
>
> This also fixes the following build warning with W=1:
>
> arch/arm/boot/dts/imx51-babbage.dtb: Warning (unit_address_vs_reg): Node /clocks/codec_clock has a reg or ranges property, but no unit name
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx51-babbage.dts | 67 +++++++++++++++++++++++++++----------
> 1 file changed, 50 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
> index c432de7..663a3cd 100644
> --- a/arch/arm/boot/dts/imx51-babbage.dts
> +++ b/arch/arm/boot/dts/imx51-babbage.dts
> @@ -25,18 +25,41 @@
> reg = <0x90000000 0x20000000>;
> };
>
> - clocks {
> - ckih1 {
> - clock-frequency = <22579200>;
> - };
> + ckih1 {
> + clock-frequency = <22579200>;
> + };
>
> - clk_26M: codec_clock {
> - compatible = "fixed-clock";
> - reg=<0>;
> - #clock-cells = <0>;
> - clock-frequency = <26000000>;
> - gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
> - };
> + clk_26M_osc: 26M_osc {
While at it, I suggest we use hyphen rather than underscore in node
name, and all lowercase for node name.
Shawn
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <26000000>;
> + };
> +
> + clk_26M_osc_gate: 26M_gate {
> + compatible = "gpio-gate-clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_clk26mhz_osc>;
> + clocks = <&clk_26M_osc>;
> + #clock-cells = <0>;
> + enable-gpios = <&gpio3 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + clk_26M_audio: audio_gate {
> + compatible = "gpio-gate-clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_clk26mhz_audio>;
> + clocks = <&clk_26M_osc_gate>;
> + #clock-cells = <0>;
> + enable-gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
> + };
> +
> + clk_26M_usb: usbhost_gate {
> + compatible = "gpio-gate-clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_clk26mhz_usb>;
> + clocks = <&clk_26M_osc_gate>;
> + #clock-cells = <0>;
> + enable-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
> };
>
> display1: disp1 {
> @@ -162,7 +185,7 @@
> usbh1phy: usbh1phy at 0 {
> compatible = "usb-nop-xceiv";
> reg = <0>;
> - clocks = <&clks IMX5_CLK_DUMMY>;
> + clocks = <&clk_26M_usb>;
> clock-names = "main_clk";
> reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> vcc-supply = <&vusb_reg>;
> @@ -345,10 +368,8 @@
>
> sgtl5000: codec at a {
> compatible = "fsl,sgtl5000";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_clkcodec>;
> reg = <0x0a>;
> - clocks = <&clk_26M>;
> + clocks = <&clk_26M_audio>;
> VDDA-supply = <&vdig_reg>;
> VDDIO-supply = <&vvideo_reg>;
> };
> @@ -441,9 +462,21 @@
> >;
> };
>
> - pinctrl_clkcodec: clkcodecgrp {
> + pinctrl_clk26mhz_audio: clk26mhzaudiocgrp {
> + fsl,pins = <
> + MX51_PAD_CSPI1_RDY__GPIO4_26 0x85
> + >;
> + };
> +
> + pinctrl_clk26mhz_osc: clk26mhzoscgrp {
> + fsl,pins = <
> + MX51_PAD_DI1_PIN12__GPIO3_1 0x85
> + >;
> + };
> +
> + pinctrl_clk26mhz_usb: clk26mhzusbgrp {
> fsl,pins = <
> - MX51_PAD_CSPI1_RDY__GPIO4_26 0x80000000
> + MX51_PAD_EIM_D17__GPIO2_1 0x85
> >;
> };
>
> --
> 2.7.4
>
^ permalink raw reply
* [kernel-hardening] [PATCH] arm: kernel: implement fast refcount checking
From: Jinbum Park @ 2017-12-21 7:50 UTC (permalink / raw)
To: linux-arm-kernel
This adds support to arm for fast refcount checking.
It's heavily based on x86, arm64 implementation.
(7a46ec0e2f48 ("locking/refcounts,
x86/asm: Implement fast refcount overflow protection)
This doesn't support under-ARMv6, thumb2-kernel yet.
Test result of this patch is as follows.
1. LKDTM test
- All REFCOUNT_* tests in LKDTM have passed.
2. Performance test
- Cortex-A7, Quad Core, 450 MHz
- Case with CONFIG_ARCH_HAS_REFCOUNT,
perf stat -B -- echo ATOMIC_TIMING \
>/sys/kernel/debug/provoke-crash/DIRECT
204.364247057 seconds time elapsed
perf stat -B -- echo REFCOUNT_TIMING \
>/sys/kernel/debug/provoke-crash/DIRECT
208.006062212 seconds time elapsed
- Case with CONFIG_REFCOUNT_FULL,
perf stat -B -- echo REFCOUNT_TIMING \
>/sys/kernel/debug/provoke-crash/DIRECT
369.256523453 seconds time elapsed
Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/atomic.h | 82 +++++++++++++++++++++++++++++++++++++++++
arch/arm/include/asm/refcount.h | 55 +++++++++++++++++++++++++++
arch/arm/kernel/traps.c | 44 ++++++++++++++++++++++
4 files changed, 182 insertions(+)
create mode 100644 arch/arm/include/asm/refcount.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3ea00d6..e07b986 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,7 @@ config ARM
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
+ select ARCH_HAS_REFCOUNT if __LINUX_ARM_ARCH__ >= 6 && (!THUMB2_KERNEL)
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
select ARCH_HAS_STRICT_MODULE_RWX if MMU
diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 66d0e21..b203396 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -17,6 +17,7 @@
#include <linux/irqflags.h>
#include <asm/barrier.h>
#include <asm/cmpxchg.h>
+#include <asm/opcodes.h>
#define ATOMIC_INIT(i) { (i) }
@@ -32,6 +33,87 @@
#if __LINUX_ARM_ARCH__ >= 6
+#ifdef CONFIG_ARCH_HAS_REFCOUNT
+
+#define REFCOUNT_ARM_BKPT_INSTR 0xfff001fc
+
+/*
+ * 1) encode call site that detect overflow in dummy b instruction.
+ * 2) overflow handler can decode dummy b, and get call site.
+ * 3) "(call site + 4) == strex" is always true.
+ * 4) the handler can get counter address via decoding strex.
+ */
+#define REFCOUNT_TRIGGER_BKPT \
+ __inst_arm(REFCOUNT_ARM_BKPT_INSTR) \
+" b 22b\n"
+
+/* If bkpt is triggered, skip strex routines after handling overflow */
+#define REFCOUNT_CHECK_TAIL \
+" strex %1, %0, [%3]\n" \
+" teq %1, #0\n" \
+" bne 1b\n" \
+" .subsection 1\n" \
+"33:\n" \
+ REFCOUNT_TRIGGER_BKPT \
+" .previous\n"
+
+#define REFCOUNT_POST_CHECK_NEG \
+"22: bmi 33f\n" \
+ REFCOUNT_CHECK_TAIL
+
+#define REFCOUNT_POST_CHECK_NEG_OR_ZERO \
+" beq 33f\n" \
+ REFCOUNT_POST_CHECK_NEG
+
+#define REFCOUNT_SMP_MB smp_mb()
+#define REFCOUNT_SMP_NONE_MB
+
+#define REFCOUNT_OP(op, c_op, asm_op, post, mb) \
+static inline int __refcount_##op(int i, atomic_t *v) \
+{ \
+ unsigned long tmp; \
+ int result; \
+\
+ REFCOUNT_SMP_ ## mb; \
+ prefetchw(&v->counter); \
+ __asm__ __volatile__("@ __refcount_" #op "\n" \
+"1: ldrex %0, [%3]\n" \
+" " #asm_op " %0, %0, %4\n" \
+ REFCOUNT_POST_CHECK_ ## post \
+ : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter) \
+ : "r" (&v->counter), "Ir" (i) \
+ : "cc"); \
+\
+ REFCOUNT_SMP_ ## mb; \
+ return result; \
+} \
+
+REFCOUNT_OP(add_lt, +=, adds, NEG_OR_ZERO, NONE_MB);
+REFCOUNT_OP(sub_lt, -=, subs, NEG, MB);
+REFCOUNT_OP(sub_le, -=, subs, NEG_OR_ZERO, NONE_MB);
+
+static inline int __refcount_add_not_zero(int i, atomic_t *v)
+{
+ unsigned long tmp;
+ int result;
+
+ prefetchw(&v->counter);
+ __asm__ __volatile__("@ __refcount_add_not_zero\n"
+"1: ldrex %0, [%3]\n"
+" teq %0, #0\n"
+" beq 2f\n"
+" adds %0, %0, %4\n"
+ REFCOUNT_POST_CHECK_NEG
+"2:"
+ : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
+ : "r" (&v->counter), "Ir" (i)
+ : "cc");
+
+ return result;
+}
+
+#endif /* CONFIG_ARCH_HAS_REFCOUNT */
+
/*
* ARMv6 UP and SMP safe atomic ops. We use load exclusive and
* store exclusive to ensure that these are atomic. We may loop
diff --git a/arch/arm/include/asm/refcount.h b/arch/arm/include/asm/refcount.h
new file mode 100644
index 0000000..300a2d5
--- /dev/null
+++ b/arch/arm/include/asm/refcount.h
@@ -0,0 +1,55 @@
+/*
+ * arm-specific implementation of refcount_t. Based on x86 version and
+ * PAX_REFCOUNT from PaX/grsecurity.
+ *
+ * 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.
+ */
+
+#ifndef __ASM_REFCOUNT_H
+#define __ASM_REFCOUNT_H
+
+#include <linux/refcount.h>
+
+#include <asm/atomic.h>
+#include <asm/uaccess.h>
+
+static __always_inline void refcount_add(int i, refcount_t *r)
+{
+ __refcount_add_lt(i, &r->refs);
+}
+
+static __always_inline void refcount_inc(refcount_t *r)
+{
+ __refcount_add_lt(1, &r->refs);
+}
+
+static __always_inline void refcount_dec(refcount_t *r)
+{
+ __refcount_sub_le(1, &r->refs);
+}
+
+static __always_inline __must_check bool refcount_sub_and_test(unsigned int i,
+ refcount_t *r)
+{
+ return __refcount_sub_lt(i, &r->refs) == 0;
+}
+
+static __always_inline __must_check bool refcount_dec_and_test(refcount_t *r)
+{
+ return __refcount_sub_lt(1, &r->refs) == 0;
+}
+
+static __always_inline __must_check bool refcount_add_not_zero(unsigned int i,
+ refcount_t *r)
+{
+ return __refcount_add_not_zero(i, &r->refs) != 0;
+}
+
+static __always_inline __must_check bool refcount_inc_not_zero(refcount_t *r)
+{
+ return __refcount_add_not_zero(1, &r->refs) != 0;
+}
+
+#endif
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 5cf0488..a309215 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -795,8 +795,52 @@ void abort(void)
}
EXPORT_SYMBOL(abort);
+#ifdef CONFIG_ARCH_HAS_REFCOUNT
+
+static int refcount_overflow_handler(struct pt_regs *regs, unsigned int instr)
+{
+ u32 dummy_b = le32_to_cpup((__le32 *)(regs->ARM_pc + 4));
+ u32 strex;
+ u32 rt;
+ bool zero = regs->ARM_cpsr & PSR_Z_BIT;
+
+ /* point pc to the branch instruction that detected the overflow */
+ regs->ARM_pc += 4 + (((s32)dummy_b << 8) >> 6) + 8;
+
+ /* decode strex to set refcount */
+ strex = le32_to_cpup((__le32 *)(regs->ARM_pc + 4));
+ rt = (strex << 12) >> 28;
+
+ /* unconditionally saturate the refcount */
+ *(int *)regs->uregs[rt] = INT_MIN / 2;
+
+ /* report error */
+ refcount_error_report(regs, zero ? "hit zero" : "overflow");
+
+ /* advance pc and proceed, skip "strex" routine */
+ regs->ARM_pc += 16;
+ return 0;
+}
+
+static struct undef_hook refcount_break_hook = {
+ .instr_mask = 0xffffffff,
+ .instr_val = REFCOUNT_ARM_BKPT_INSTR,
+ .cpsr_mask = 0,
+ .cpsr_val = 0,
+ .fn = refcount_overflow_handler,
+};
+
+#define register_refcount_break_hook() register_undef_hook(&refcount_break_hook)
+
+#else /* !CONFIG_ARCH_HAS_REFCOUNT */
+
+#define register_refcount_break_hook()
+
+#endif /* CONFIG_ARCH_HAS_REFCOUNT */
+
void __init trap_init(void)
{
+ register_refcount_break_hook();
return;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx51-babbage: Pass the USB PHY regulator
From: Shawn Guo @ 2017-12-21 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512246365-3657-1-git-send-email-festevam@gmail.com>
On Sat, Dec 02, 2017 at 06:26:04PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> The USB PHYs are supplied via MC13892 VUSB regulator rail,
> so properly describe this in the device tree.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied this one, thanks.
^ permalink raw reply
* [PATCH 0/6] Add CPU Frequency scaling support on Armada 37xx
From: Andre Heider @ 2017-12-21 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wp1kge99.fsf@free-electrons.com>
On 18/12/17 18:03, Gregory CLEMENT wrote:
> Hi Andre,
>
> On mer., d?c. 06 2017, Andre Heider <a.heider@gmail.com> wrote:
>
>> On 06/12/17 12:50, Gregory CLEMENT wrote:
>>> I did a last rebase before sending the series to remove the avs part not
>>> working yet. And during this rebase I introduced an bug.
>>>
>>> I will send a v2 soon if you are intersected by testing it right now,
>>> here it is the fix:
>>>
>>> iff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c
>>> index 40c9a744cc6e..96c2600009b5 100644
>>> --- a/drivers/cpufreq/armada-37xx-cpufreq.c
>>> +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
>>> @@ -219,7 +219,8 @@ static int __init armada37xx_cpufreq_driver_init(void)
>>> */
>>> for (load_level = ARMADA_37XX_DVFS_LOAD_0; load_level < LOAD_LEVEL_NR;
>>> load_level++) {
>>> - unsigned long freq = dvfs->divider[load_level];
>>> + unsigned long freq = cur_frequency /
>>> + dvfs->divider[load_level];
>>> ret = dev_pm_opp_add(cpu_dev, freq, 0);
>>> if (ret)
>>
>> Much better, that seems to work so far, thanks!
>>
>> My espressobin now gets these frequencies: 200 MHz, 250 MHz, 500 MHz
>> and 1000 MHz.
>>
>> With the schedutil governor and `watch -n 0.2 cpufreq-info -f -m` it
>> jumps over all of those depending on the load, nice:
>>
>> Tested-by: Andre Heider <a.heider@gmail.com>
>>
>> The measured power usage doesn't drop though, I guess that requires
>> the AVS part you mentioned? Looking forward to it ;)
>
> Well I did some measurement and i saw some drop, according to my notes:
>
> @ 250MHz: 222mA at 12V => 2.66W
> @ 1000MHz: 238mA at 12CV => 2.87W
>
> Not something huge, but only the CPUs which are concerned so it's not so
> bad.
Oh, okay, my cheap equipment isn't capable to measure a difference of
just 0.2w... Guess I was hoping for more ;)
>> On a related note: Do you know if power usage can be lowered by
>> disabling eth phys? Is that possible on mainline?
>
> For the test I have done just by removing an Ethernet cable we save a
> lot of power, so it helps. I'm sure it is doable on mainline, but maybe
> currently, there is something still missing.
Promising, was that with a downstream kernel?
Thanks,
Andre
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-zii-rdu2: Remove device_type from PCI subnode
From: Shawn Guo @ 2017-12-21 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512234488-8760-1-git-send-email-festevam@gmail.com>
On Sat, Dec 02, 2017 at 03:08:08PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> device_type = "pci" should be used for the SoC level PCI controller and
> it is already present at imx6qdl.dtsi.
>
> Remove it from the subnode in order to fix the following build
> warnings with W=1:
>
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (pci_bridge): Node /soc/pcie at 1ffc000/pci at 0 missing ranges for PCI bridge (or not a bridge)
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (pci_bridge): Node /soc/pcie at 1ffc000/pci at 0 missing bus-range for PCI bridge
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (unit_address_format): Failed prerequisite 'pci_bridge'
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (pci_device_reg): Failed prerequisite 'pci_bridge'
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge'
>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 01/12] ARM: dts: imx51-ts4800: Fix syscon and touschscreen nodes
From: Shawn Guo @ 2017-12-21 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512390016-703-1-git-send-email-festevam@gmail.com>
On Mon, Dec 04, 2017 at 10:20:05AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> The syscon node has an incorrect notation for its unit address and the
> wdt node has an unneeded unit address.
>
> Fix them so that the following build warnings with W=1 are gone:
>
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/syscon at b0010000/wdt at e has a unit name, but no reg property
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/touchscreen has a reg or ranges property, but no unit name
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (simple_bus_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/syscon at b0010000 simple-bus unit address format error, expected "10000"
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (simple_bus_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/touchscreen simple-bus unit address format error, expected "12000"
>
> Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> Reviewed-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
From: Shawn Guo @ 2017-12-21 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB1241243DE5FE86833DD0B509970D0@HE1PR04MB1241.eurprd04.prod.outlook.com>
On Thu, Dec 21, 2017 at 07:19:12AM +0000, Prabhakar Kushwaha wrote:
> Are you referring to this discussion https://patchwork.ozlabs.org/patch/842543/?
> Due to which binding are not ACK-ed.
Hmm, I'm talking about Rob's comment below.
https://www.spinics.net/lists/arm-kernel/msg620518.html
In any case, I cannot apply the dts change before the bindings part gets
ACK-ed by DT maintainer.
Shawn
^ permalink raw reply
* [RESEND PATCH v5 0/6] ARM: Add Variscite DART-MX6 SoM and Carrier-board support
From: Shawn Guo @ 2017-12-21 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
On Mon, Dec 04, 2017 at 10:21:04AM +0100, Neil Armstrong wrote:
> Neil Armstrong (6):
> ARM: dts: imx6qdl-pinfunc: Add missing
> MX6QDL_PAD_ENET_RXD0__OSC32K_32K_OUT
> dt-bindings: Add vendor prefix for Solomon Goldentek Display
> Corporation
> dt-bindings: display: Add bindings for SGD GKTW70SDAE4SE Panel
> ARM: dts: imx6qdl: Add Variscite DART-MX6 SoM support
> ARM: dts: imx6q: Add Variscite DART-MX6 Carrier-board support
> ARM: imx_v6_v7_defconfig: Add missing config for DART-MX6 SoM
Applied all, thanks.
^ permalink raw reply
* [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
From: Prabhakar Kushwaha @ 2017-12-21 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221071056.GF3766@dragon>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Thursday, December 21, 2017 12:41 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> Cc: devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com;
> Alison Wang <alison.wang@nxp.com>; Jagdish Gediya
> <jagdish.gediya@nxp.com>; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
>
> On Thu, Dec 21, 2017 at 05:14:36AM +0000, Prabhakar Kushwaha wrote:
> > Hi Shawn,
> >
> > > -----Original Message-----
> > > From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha at nxp.com]
> > > Sent: Thursday, November 30, 2017 9:12 AM
> > > To: devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com;
> > > shawnguo at kernel.org
> > > Cc: linux-arm-kernel at lists.infradead.org; Jagdish Gediya
> > > <jagdish.gediya@nxp.com>; Alison Wang <alison.wang@nxp.com>;
> Prabhakar
> > > Kushwaha <prabhakar.kushwaha@nxp.com>
> > > Subject: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
> > >
> > > From: Jagdish Gediya <jagdish.gediya@nxp.com>
> > >
> > > For the patch to update struct map_info's swap field based on device
> > > characteristics defined in device tree, big-endian parameter is added
> > > for LS1021A.
> > >
> > > Signed-off-by: Alison Wang <alison.wang@nxp.com>
> > > Signed-off-by: Jagdish Gediya <jagdish.gediya@nxp.com>
> > > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> > > ---
> > > Changes for v2: updated subject
> > >
> > > arch/arm/boot/dts/ls1021a.dtsi | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> > > index 9319e1f..babb086 100644
> > > --- a/arch/arm/boot/dts/ls1021a.dtsi
> > > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > > @@ -145,6 +145,7 @@
> > > ifc: ifc at 1530000 {
> > > compatible = "fsl,ifc", "simple-bus";
> > > reg = <0x0 0x1530000 0x0 0x10000>;
> > > + big-endian;
> > > interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> > > };
> > >
> > > --
> > > 1.9.1
> >
> > There are no review comments on this patch.
> >
> > Can you please accept this patch
>
> It seems that the bindings hasn't been ACK-ed by DT maintainer.
>
Are you referring to this discussion https://patchwork.ozlabs.org/patch/842543/?
Due to which binding are not ACK-ed.
--pk
^ 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