* [PATCH 07/15] perf tools: Add PMU configuration to tools
From: Arnaldo Carvalho de Melo @ 2016-09-22 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474578779-14095-1-git-send-email-acme@kernel.org>
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Now that the required mechanic is there to deal with PMU specific
configuration, add the functionality to the tools where events can be
selected.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1474041004-13956-7-git-send-email-mathieu.poirier at linaro.org
[ Fix the build on XSI-compliant systems, using str_error_r() to make sure we return a string, not an integer ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/builtin-record.c | 10 ++++++++++
tools/perf/builtin-stat.c | 9 +++++++++
tools/perf/builtin-top.c | 13 +++++++++++++
3 files changed, 32 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 03251c7f14ec..2d0d69be3bf8 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -22,6 +22,7 @@
#include "util/evlist.h"
#include "util/evsel.h"
#include "util/debug.h"
+#include "util/drv_configs.h"
#include "util/session.h"
#include "util/tool.h"
#include "util/symbol.h"
@@ -383,6 +384,7 @@ static int record__open(struct record *rec)
struct perf_evlist *evlist = rec->evlist;
struct perf_session *session = rec->session;
struct record_opts *opts = &rec->opts;
+ struct perf_evsel_config_term *err_term;
int rc = 0;
perf_evlist__config(evlist, opts, &callchain_param);
@@ -412,6 +414,14 @@ try_again:
goto out;
}
+ if (perf_evlist__apply_drv_configs(evlist, &pos, &err_term)) {
+ error("failed to set config \"%s\" on event %s with %d (%s)\n",
+ err_term->val.drv_cfg, perf_evsel__name(pos), errno,
+ str_error_r(errno, msg, sizeof(msg)));
+ rc = -1;
+ goto out;
+ }
+
rc = record__mmap(rec);
if (rc)
goto out;
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 90882b1d6a91..688dea7cb08f 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -52,6 +52,7 @@
#include "util/evlist.h"
#include "util/evsel.h"
#include "util/debug.h"
+#include "util/drv_configs.h"
#include "util/color.h"
#include "util/stat.h"
#include "util/header.h"
@@ -540,6 +541,7 @@ static int __run_perf_stat(int argc, const char **argv)
int status = 0;
const bool forks = (argc > 0);
bool is_pipe = STAT_RECORD ? perf_stat.file.is_pipe : false;
+ struct perf_evsel_config_term *err_term;
if (interval) {
ts.tv_sec = interval / USEC_PER_MSEC;
@@ -611,6 +613,13 @@ try_again:
return -1;
}
+ if (perf_evlist__apply_drv_configs(evsel_list, &counter, &err_term)) {
+ error("failed to set config \"%s\" on event %s with %d (%s)\n",
+ err_term->val.drv_cfg, perf_evsel__name(counter), errno,
+ str_error_r(errno, msg, sizeof(msg)));
+ return -1;
+ }
+
if (STAT_RECORD) {
int err, fd = perf_data_file__fd(&perf_stat.file);
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 400785702566..fe3af9535e85 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -24,6 +24,7 @@
#include "util/annotate.h"
#include "util/config.h"
#include "util/color.h"
+#include "util/drv_configs.h"
#include "util/evlist.h"
#include "util/evsel.h"
#include "util/machine.h"
@@ -913,6 +914,10 @@ static int callchain_param__setup_sample_type(struct callchain_param *callchain)
static int __cmd_top(struct perf_top *top)
{
+ char msg[512];
+ struct perf_evsel *pos;
+ struct perf_evsel_config_term *err_term;
+ struct perf_evlist *evlist = top->evlist;
struct record_opts *opts = &top->record_opts;
pthread_t thread;
int ret;
@@ -947,6 +952,14 @@ static int __cmd_top(struct perf_top *top)
if (ret)
goto out_delete;
+ ret = perf_evlist__apply_drv_configs(evlist, &pos, &err_term);
+ if (ret) {
+ error("failed to set config \"%s\" on event %s with %d (%s)\n",
+ err_term->val.drv_cfg, perf_evsel__name(pos), errno,
+ str_error_r(errno, msg, sizeof(msg)));
+ goto out_delete;
+ }
+
top->session->evlist = top->evlist;
perf_session__set_id_hdr_size(top->session);
--
2.7.4
^ permalink raw reply related
* [PATCH 06/15] perf pmu: Push configuration down to PMU driver
From: Arnaldo Carvalho de Melo @ 2016-09-22 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474578779-14095-1-git-send-email-acme@kernel.org>
From: Mathieu Poirier <mathieu.poirier@linaro.org>
This patch adds a PMU callback and the required mechanic so that drivers
can process the command line configuration elements found in
evsel::config_terms.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1474041004-13956-6-git-send-email-mathieu.poirier at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/Build | 1 +
tools/perf/util/drv_configs.c | 77 +++++++++++++++++++++++++++++++++++++++++++
tools/perf/util/drv_configs.h | 26 +++++++++++++++
tools/perf/util/pmu.h | 2 ++
4 files changed, 106 insertions(+)
create mode 100644 tools/perf/util/drv_configs.c
create mode 100644 tools/perf/util/drv_configs.h
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 96f99d608d00..eb60e613d795 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -86,6 +86,7 @@ libperf-y += term.o
libperf-y += help-unknown-cmd.o
libperf-y += mem-events.o
libperf-y += vsprintf.o
+libperf-y += drv_configs.o
libperf-$(CONFIG_LIBBPF) += bpf-loader.o
libperf-$(CONFIG_BPF_PROLOGUE) += bpf-prologue.o
diff --git a/tools/perf/util/drv_configs.c b/tools/perf/util/drv_configs.c
new file mode 100644
index 000000000000..1647f285c629
--- /dev/null
+++ b/tools/perf/util/drv_configs.c
@@ -0,0 +1,77 @@
+/*
+ * drv_configs.h: Interface to apply PMU specific configuration
+ * Copyright (c) 2016-2018, Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include "drv_configs.h"
+#include "evlist.h"
+#include "evsel.h"
+#include "pmu.h"
+
+static int
+perf_evsel__apply_drv_configs(struct perf_evsel *evsel,
+ struct perf_evsel_config_term **err_term)
+{
+ bool found = false;
+ int err = 0;
+ struct perf_evsel_config_term *term;
+ struct perf_pmu *pmu = NULL;
+
+ while ((pmu = perf_pmu__scan(pmu)) != NULL)
+ if (pmu->type == evsel->attr.type) {
+ found = true;
+ break;
+ }
+
+ list_for_each_entry(term, &evsel->config_terms, list) {
+ if (term->type != PERF_EVSEL__CONFIG_TERM_DRV_CFG)
+ continue;
+
+ /*
+ * We have a configuration term, report an error if we
+ * can't find the PMU or if the PMU driver doesn't support
+ * cmd line driver configuration.
+ */
+ if (!found || !pmu->set_drv_config) {
+ err = -EINVAL;
+ *err_term = term;
+ break;
+ }
+
+ err = pmu->set_drv_config(term);
+ if (err) {
+ *err_term = term;
+ break;
+ }
+ }
+
+ return err;
+}
+
+int perf_evlist__apply_drv_configs(struct perf_evlist *evlist,
+ struct perf_evsel **err_evsel,
+ struct perf_evsel_config_term **err_term)
+{
+ struct perf_evsel *evsel;
+ int err = 0;
+
+ evlist__for_each_entry(evlist, evsel) {
+ err = perf_evsel__apply_drv_configs(evsel, err_term);
+ if (err) {
+ *err_evsel = evsel;
+ break;
+ }
+ }
+
+ return err;
+}
diff --git a/tools/perf/util/drv_configs.h b/tools/perf/util/drv_configs.h
new file mode 100644
index 000000000000..32bc9babc2e0
--- /dev/null
+++ b/tools/perf/util/drv_configs.h
@@ -0,0 +1,26 @@
+/*
+ * drv_configs.h: Interface to apply PMU specific configuration
+ * Copyright (c) 2016-2018, Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#ifndef __PERF_DRV_CONFIGS_H
+#define __PERF_DRV_CONFIGS_H
+
+#include "drv_configs.h"
+#include "evlist.h"
+#include "evsel.h"
+
+int perf_evlist__apply_drv_configs(struct perf_evlist *evlist,
+ struct perf_evsel **err_evsel,
+ struct perf_evsel_config_term **term);
+#endif
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 5d7e84466bee..743422ad900b 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -4,6 +4,7 @@
#include <linux/bitmap.h>
#include <linux/perf_event.h>
#include <stdbool.h>
+#include "evsel.h"
#include "parse-events.h"
enum {
@@ -25,6 +26,7 @@ struct perf_pmu {
struct list_head format; /* HEAD struct perf_pmu_format -> list */
struct list_head aliases; /* HEAD struct perf_pmu_alias -> list */
struct list_head list; /* ELEM */
+ int (*set_drv_config) (struct perf_evsel_config_term *term);
};
struct perf_pmu_info {
--
2.7.4
^ permalink raw reply related
* [PATCH 05/15] perf tools: Add coresight etm PMU record capabilities
From: Arnaldo Carvalho de Melo @ 2016-09-22 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474578779-14095-1-git-send-email-acme@kernel.org>
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Coresight ETMs are IP blocks used to perform HW assisted tracing on a
CPU core. This patch introduce the required auxiliary API functions
allowing the perf core to interact with a tracer.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1474041004-13956-4-git-send-email-mathieu.poirier at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
MAINTAINERS | 4 +
tools/perf/arch/arm/util/Build | 2 +-
tools/perf/arch/arm/util/auxtrace.c | 54 ++++
tools/perf/arch/arm/util/cs-etm.c | 559 ++++++++++++++++++++++++++++++++++++
tools/perf/arch/arm/util/cs-etm.h | 23 ++
tools/perf/arch/arm64/util/Build | 4 +-
tools/perf/util/auxtrace.c | 1 +
tools/perf/util/auxtrace.h | 1 +
tools/perf/util/cs-etm.h | 74 +++++
9 files changed, 720 insertions(+), 2 deletions(-)
create mode 100644 tools/perf/arch/arm/util/auxtrace.c
create mode 100644 tools/perf/arch/arm/util/cs-etm.c
create mode 100644 tools/perf/arch/arm/util/cs-etm.h
create mode 100644 tools/perf/util/cs-etm.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7407fe779053..ac29d5453750 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1124,6 +1124,10 @@ F: Documentation/trace/coresight.txt
F: Documentation/devicetree/bindings/arm/coresight.txt
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
F: tools/perf/arch/arm/util/pmu.c
+F: tools/perf/arch/arm/util/auxtrace.c
+F: tools/perf/arch/arm/util/cs-etm.c
+F: tools/perf/arch/arm/util/cs-etm.h
+F: tools/perf/util/cs-etm.h
ARM/CORGI MACHINE SUPPORT
M: Richard Purdie <rpurdie@rpsys.net>
diff --git a/tools/perf/arch/arm/util/Build b/tools/perf/arch/arm/util/Build
index 4093fd146f46..e64c5f216448 100644
--- a/tools/perf/arch/arm/util/Build
+++ b/tools/perf/arch/arm/util/Build
@@ -3,4 +3,4 @@ libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
-libperf-$(CONFIG_AUXTRACE) += pmu.o
+libperf-$(CONFIG_AUXTRACE) += pmu.o auxtrace.o cs-etm.o
diff --git a/tools/perf/arch/arm/util/auxtrace.c b/tools/perf/arch/arm/util/auxtrace.c
new file mode 100644
index 000000000000..8edf2cb71564
--- /dev/null
+++ b/tools/perf/arch/arm/util/auxtrace.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier@linaro.org>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <stdbool.h>
+#include <linux/coresight-pmu.h>
+
+#include "../../util/auxtrace.h"
+#include "../../util/evlist.h"
+#include "../../util/pmu.h"
+#include "cs-etm.h"
+
+struct auxtrace_record
+*auxtrace_record__init(struct perf_evlist *evlist, int *err)
+{
+ struct perf_pmu *cs_etm_pmu;
+ struct perf_evsel *evsel;
+ bool found_etm = false;
+
+ cs_etm_pmu = perf_pmu__find(CORESIGHT_ETM_PMU_NAME);
+
+ if (evlist) {
+ evlist__for_each_entry(evlist, evsel) {
+ if (cs_etm_pmu &&
+ evsel->attr.type == cs_etm_pmu->type)
+ found_etm = true;
+ }
+ }
+
+ if (found_etm)
+ return cs_etm_record_init(err);
+
+ /*
+ * Clear 'err' even if we haven't found a cs_etm event - that way perf
+ * record can still be used even if tracers aren't present. The NULL
+ * return value will take care of telling the infrastructure HW tracing
+ * isn't available.
+ */
+ *err = 0;
+ return NULL;
+}
diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
new file mode 100644
index 000000000000..829c479614f1
--- /dev/null
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -0,0 +1,559 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier@linaro.org>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <api/fs/fs.h>
+#include <linux/bitops.h>
+#include <linux/coresight-pmu.h>
+#include <linux/kernel.h>
+#include <linux/log2.h>
+#include <linux/types.h>
+
+#include "cs-etm.h"
+#include "../../perf.h"
+#include "../../util/auxtrace.h"
+#include "../../util/cpumap.h"
+#include "../../util/evlist.h"
+#include "../../util/pmu.h"
+#include "../../util/thread_map.h"
+#include "../../util/cs-etm.h"
+
+#include <stdlib.h>
+
+struct cs_etm_recording {
+ struct auxtrace_record itr;
+ struct perf_pmu *cs_etm_pmu;
+ struct perf_evlist *evlist;
+ bool snapshot_mode;
+ size_t snapshot_size;
+};
+
+static bool cs_etm_is_etmv4(struct auxtrace_record *itr, int cpu);
+
+static int cs_etm_parse_snapshot_options(struct auxtrace_record *itr,
+ struct record_opts *opts,
+ const char *str)
+{
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ unsigned long long snapshot_size = 0;
+ char *endptr;
+
+ if (str) {
+ snapshot_size = strtoull(str, &endptr, 0);
+ if (*endptr || snapshot_size > SIZE_MAX)
+ return -1;
+ }
+
+ opts->auxtrace_snapshot_mode = true;
+ opts->auxtrace_snapshot_size = snapshot_size;
+ ptr->snapshot_size = snapshot_size;
+
+ return 0;
+}
+
+static int cs_etm_recording_options(struct auxtrace_record *itr,
+ struct perf_evlist *evlist,
+ struct record_opts *opts)
+{
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
+ struct perf_evsel *evsel, *cs_etm_evsel = NULL;
+ const struct cpu_map *cpus = evlist->cpus;
+ bool privileged = (geteuid() == 0 || perf_event_paranoid() < 0);
+
+ ptr->evlist = evlist;
+ ptr->snapshot_mode = opts->auxtrace_snapshot_mode;
+
+ evlist__for_each_entry(evlist, evsel) {
+ if (evsel->attr.type == cs_etm_pmu->type) {
+ if (cs_etm_evsel) {
+ pr_err("There may be only one %s event\n",
+ CORESIGHT_ETM_PMU_NAME);
+ return -EINVAL;
+ }
+ evsel->attr.freq = 0;
+ evsel->attr.sample_period = 1;
+ cs_etm_evsel = evsel;
+ opts->full_auxtrace = true;
+ }
+ }
+
+ /* no need to continue if at least one event of interest was found */
+ if (!cs_etm_evsel)
+ return 0;
+
+ if (opts->use_clockid) {
+ pr_err("Cannot use clockid (-k option) with %s\n",
+ CORESIGHT_ETM_PMU_NAME);
+ return -EINVAL;
+ }
+
+ /* we are in snapshot mode */
+ if (opts->auxtrace_snapshot_mode) {
+ /*
+ * No size were given to '-S' or '-m,', so go with
+ * the default
+ */
+ if (!opts->auxtrace_snapshot_size &&
+ !opts->auxtrace_mmap_pages) {
+ if (privileged) {
+ opts->auxtrace_mmap_pages = MiB(4) / page_size;
+ } else {
+ opts->auxtrace_mmap_pages =
+ KiB(128) / page_size;
+ if (opts->mmap_pages == UINT_MAX)
+ opts->mmap_pages = KiB(256) / page_size;
+ }
+ } else if (!opts->auxtrace_mmap_pages && !privileged &&
+ opts->mmap_pages == UINT_MAX) {
+ opts->mmap_pages = KiB(256) / page_size;
+ }
+
+ /*
+ * '-m,xyz' was specified but no snapshot size, so make the
+ * snapshot size as big as the auxtrace mmap area.
+ */
+ if (!opts->auxtrace_snapshot_size) {
+ opts->auxtrace_snapshot_size =
+ opts->auxtrace_mmap_pages * (size_t)page_size;
+ }
+
+ /*
+ * -Sxyz was specified but no auxtrace mmap area, so make the
+ * auxtrace mmap area big enough to fit the requested snapshot
+ * size.
+ */
+ if (!opts->auxtrace_mmap_pages) {
+ size_t sz = opts->auxtrace_snapshot_size;
+
+ sz = round_up(sz, page_size) / page_size;
+ opts->auxtrace_mmap_pages = roundup_pow_of_two(sz);
+ }
+
+ /* Snapshost size can't be bigger than the auxtrace area */
+ if (opts->auxtrace_snapshot_size >
+ opts->auxtrace_mmap_pages * (size_t)page_size) {
+ pr_err("Snapshot size %zu must not be greater than AUX area tracing mmap size %zu\n",
+ opts->auxtrace_snapshot_size,
+ opts->auxtrace_mmap_pages * (size_t)page_size);
+ return -EINVAL;
+ }
+
+ /* Something went wrong somewhere - this shouldn't happen */
+ if (!opts->auxtrace_snapshot_size ||
+ !opts->auxtrace_mmap_pages) {
+ pr_err("Failed to calculate default snapshot size and/or AUX area tracing mmap pages\n");
+ return -EINVAL;
+ }
+ }
+
+ /* We are in full trace mode but '-m,xyz' wasn't specified */
+ if (opts->full_auxtrace && !opts->auxtrace_mmap_pages) {
+ if (privileged) {
+ opts->auxtrace_mmap_pages = MiB(4) / page_size;
+ } else {
+ opts->auxtrace_mmap_pages = KiB(128) / page_size;
+ if (opts->mmap_pages == UINT_MAX)
+ opts->mmap_pages = KiB(256) / page_size;
+ }
+
+ }
+
+ /* Validate auxtrace_mmap_pages provided by user */
+ if (opts->auxtrace_mmap_pages) {
+ unsigned int max_page = (KiB(128) / page_size);
+ size_t sz = opts->auxtrace_mmap_pages * (size_t)page_size;
+
+ if (!privileged &&
+ opts->auxtrace_mmap_pages > max_page) {
+ opts->auxtrace_mmap_pages = max_page;
+ pr_err("auxtrace too big, truncating to %d\n",
+ max_page);
+ }
+
+ if (!is_power_of_2(sz)) {
+ pr_err("Invalid mmap size for %s: must be a power of 2\n",
+ CORESIGHT_ETM_PMU_NAME);
+ return -EINVAL;
+ }
+ }
+
+ if (opts->auxtrace_snapshot_mode)
+ pr_debug2("%s snapshot size: %zu\n", CORESIGHT_ETM_PMU_NAME,
+ opts->auxtrace_snapshot_size);
+
+ if (cs_etm_evsel) {
+ /*
+ * To obtain the auxtrace buffer file descriptor, the auxtrace
+ * event must come first.
+ */
+ perf_evlist__to_front(evlist, cs_etm_evsel);
+ /*
+ * In the case of per-cpu mmaps, we need the CPU on the
+ * AUX event.
+ */
+ if (!cpu_map__empty(cpus))
+ perf_evsel__set_sample_bit(cs_etm_evsel, CPU);
+ }
+
+ /* Add dummy event to keep tracking */
+ if (opts->full_auxtrace) {
+ struct perf_evsel *tracking_evsel;
+ int err;
+
+ err = parse_events(evlist, "dummy:u", NULL);
+ if (err)
+ return err;
+
+ tracking_evsel = perf_evlist__last(evlist);
+ perf_evlist__set_tracking_event(evlist, tracking_evsel);
+
+ tracking_evsel->attr.freq = 0;
+ tracking_evsel->attr.sample_period = 1;
+
+ /* In per-cpu case, always need the time of mmap events etc */
+ if (!cpu_map__empty(cpus))
+ perf_evsel__set_sample_bit(tracking_evsel, TIME);
+ }
+
+ return 0;
+}
+
+static u64 cs_etm_get_config(struct auxtrace_record *itr)
+{
+ u64 config = 0;
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
+ struct perf_evlist *evlist = ptr->evlist;
+ struct perf_evsel *evsel;
+
+ evlist__for_each_entry(evlist, evsel) {
+ if (evsel->attr.type == cs_etm_pmu->type) {
+ /*
+ * Variable perf_event_attr::config is assigned to
+ * ETMv3/PTM. The bit fields have been made to match
+ * the ETMv3.5 ETRMCR register specification. See the
+ * PMU_FORMAT_ATTR() declarations in
+ * drivers/hwtracing/coresight/coresight-perf.c for
+ * details.
+ */
+ config = evsel->attr.config;
+ break;
+ }
+ }
+
+ return config;
+}
+
+static size_t
+cs_etm_info_priv_size(struct auxtrace_record *itr __maybe_unused,
+ struct perf_evlist *evlist __maybe_unused)
+{
+ int i;
+ int etmv3 = 0, etmv4 = 0;
+ const struct cpu_map *cpus = evlist->cpus;
+
+ /* cpu map is not empty, we have specific CPUs to work with */
+ if (!cpu_map__empty(cpus)) {
+ for (i = 0; i < cpu_map__nr(cpus); i++) {
+ if (cs_etm_is_etmv4(itr, cpus->map[i]))
+ etmv4++;
+ else
+ etmv3++;
+ }
+ } else {
+ /* get configuration for all CPUs in the system */
+ for (i = 0; i < cpu__max_cpu(); i++) {
+ if (cs_etm_is_etmv4(itr, i))
+ etmv4++;
+ else
+ etmv3++;
+ }
+ }
+
+ return (CS_ETM_HEADER_SIZE +
+ (etmv4 * CS_ETMV4_PRIV_SIZE) +
+ (etmv3 * CS_ETMV3_PRIV_SIZE));
+}
+
+static const char *metadata_etmv3_ro[CS_ETM_PRIV_MAX] = {
+ [CS_ETM_ETMCCER] = "mgmt/etmccer",
+ [CS_ETM_ETMIDR] = "mgmt/etmidr",
+};
+
+static const char *metadata_etmv4_ro[CS_ETMV4_PRIV_MAX] = {
+ [CS_ETMV4_TRCIDR0] = "trcidr/trcidr0",
+ [CS_ETMV4_TRCIDR1] = "trcidr/trcidr1",
+ [CS_ETMV4_TRCIDR2] = "trcidr/trcidr2",
+ [CS_ETMV4_TRCIDR8] = "trcidr/trcidr8",
+ [CS_ETMV4_TRCAUTHSTATUS] = "mgmt/trcauthstatus",
+};
+
+static bool cs_etm_is_etmv4(struct auxtrace_record *itr, int cpu)
+{
+ bool ret = false;
+ char path[PATH_MAX];
+ int scan;
+ unsigned int val;
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
+
+ /* Take any of the RO files for ETMv4 and see if it present */
+ snprintf(path, PATH_MAX, "cpu%d/%s",
+ cpu, metadata_etmv4_ro[CS_ETMV4_TRCIDR0]);
+ scan = perf_pmu__scan_file(cs_etm_pmu, path, "%x", &val);
+
+ /* The file was read successfully, we have a winner */
+ if (scan == 1)
+ ret = true;
+
+ return ret;
+}
+
+static int cs_etm_get_ro(struct perf_pmu *pmu, int cpu, const char *path)
+{
+ char pmu_path[PATH_MAX];
+ int scan;
+ unsigned int val = 0;
+
+ /* Get RO metadata from sysfs */
+ snprintf(pmu_path, PATH_MAX, "cpu%d/%s", cpu, path);
+
+ scan = perf_pmu__scan_file(pmu, pmu_path, "%x", &val);
+ if (scan != 1)
+ pr_err("%s: error reading: %s\n", __func__, pmu_path);
+
+ return val;
+}
+
+static void cs_etm_get_metadata(int cpu, u32 *offset,
+ struct auxtrace_record *itr,
+ struct auxtrace_info_event *info)
+{
+ u32 increment;
+ u64 magic;
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
+
+ /* first see what kind of tracer this cpu is affined to */
+ if (cs_etm_is_etmv4(itr, cpu)) {
+ magic = __perf_cs_etmv4_magic;
+ /* Get trace configuration register */
+ info->priv[*offset + CS_ETMV4_TRCCONFIGR] =
+ cs_etm_get_config(itr);
+ /* Get traceID from the framework */
+ info->priv[*offset + CS_ETMV4_TRCTRACEIDR] =
+ coresight_get_trace_id(cpu);
+ /* Get read-only information from sysFS */
+ info->priv[*offset + CS_ETMV4_TRCIDR0] =
+ cs_etm_get_ro(cs_etm_pmu, cpu,
+ metadata_etmv4_ro[CS_ETMV4_TRCIDR0]);
+ info->priv[*offset + CS_ETMV4_TRCIDR1] =
+ cs_etm_get_ro(cs_etm_pmu, cpu,
+ metadata_etmv4_ro[CS_ETMV4_TRCIDR1]);
+ info->priv[*offset + CS_ETMV4_TRCIDR2] =
+ cs_etm_get_ro(cs_etm_pmu, cpu,
+ metadata_etmv4_ro[CS_ETMV4_TRCIDR2]);
+ info->priv[*offset + CS_ETMV4_TRCIDR8] =
+ cs_etm_get_ro(cs_etm_pmu, cpu,
+ metadata_etmv4_ro[CS_ETMV4_TRCIDR8]);
+ info->priv[*offset + CS_ETMV4_TRCAUTHSTATUS] =
+ cs_etm_get_ro(cs_etm_pmu, cpu,
+ metadata_etmv4_ro
+ [CS_ETMV4_TRCAUTHSTATUS]);
+
+ /* How much space was used */
+ increment = CS_ETMV4_PRIV_MAX;
+ } else {
+ magic = __perf_cs_etmv3_magic;
+ /* Get configuration register */
+ info->priv[*offset + CS_ETM_ETMCR] = cs_etm_get_config(itr);
+ /* Get traceID from the framework */
+ info->priv[*offset + CS_ETM_ETMTRACEIDR] =
+ coresight_get_trace_id(cpu);
+ /* Get read-only information from sysFS */
+ info->priv[*offset + CS_ETM_ETMCCER] =
+ cs_etm_get_ro(cs_etm_pmu, cpu,
+ metadata_etmv3_ro[CS_ETM_ETMCCER]);
+ info->priv[*offset + CS_ETM_ETMIDR] =
+ cs_etm_get_ro(cs_etm_pmu, cpu,
+ metadata_etmv3_ro[CS_ETM_ETMIDR]);
+
+ /* How much space was used */
+ increment = CS_ETM_PRIV_MAX;
+ }
+
+ /* Build generic header portion */
+ info->priv[*offset + CS_ETM_MAGIC] = magic;
+ info->priv[*offset + CS_ETM_CPU] = cpu;
+ /* Where the next CPU entry should start from */
+ *offset += increment;
+}
+
+static int cs_etm_info_fill(struct auxtrace_record *itr,
+ struct perf_session *session,
+ struct auxtrace_info_event *info,
+ size_t priv_size)
+{
+ int i;
+ u32 offset;
+ u64 nr_cpu, type;
+ const struct cpu_map *cpus = session->evlist->cpus;
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
+
+ if (priv_size != cs_etm_info_priv_size(itr, session->evlist))
+ return -EINVAL;
+
+ if (!session->evlist->nr_mmaps)
+ return -EINVAL;
+
+ /* If the cpu_map is empty all CPUs are involved */
+ nr_cpu = cpu_map__empty(cpus) ? cpu__max_cpu() : cpu_map__nr(cpus);
+ /* Get PMU type as dynamically assigned by the core */
+ type = cs_etm_pmu->type;
+
+ /* First fill out the session header */
+ info->type = PERF_AUXTRACE_CS_ETM;
+ info->priv[CS_HEADER_VERSION_0] = 0;
+ info->priv[CS_PMU_TYPE_CPUS] = type << 32;
+ info->priv[CS_PMU_TYPE_CPUS] |= nr_cpu;
+ info->priv[CS_ETM_SNAPSHOT] = ptr->snapshot_mode;
+
+ offset = CS_ETM_SNAPSHOT + 1;
+
+ /* cpu map is not empty, we have specific CPUs to work with */
+ if (!cpu_map__empty(cpus)) {
+ for (i = 0; i < cpu_map__nr(cpus) && offset < priv_size; i++)
+ cs_etm_get_metadata(cpus->map[i], &offset, itr, info);
+ } else {
+ /* get configuration for all CPUs in the system */
+ for (i = 0; i < cpu__max_cpu(); i++)
+ cs_etm_get_metadata(i, &offset, itr, info);
+ }
+
+ return 0;
+}
+
+static int cs_etm_find_snapshot(struct auxtrace_record *itr __maybe_unused,
+ int idx, struct auxtrace_mmap *mm,
+ unsigned char *data __maybe_unused,
+ u64 *head, u64 *old)
+{
+ pr_debug3("%s: mmap index %d old head %zu new head %zu size %zu\n",
+ __func__, idx, (size_t)*old, (size_t)*head, mm->len);
+
+ *old = *head;
+ *head += mm->len;
+
+ return 0;
+}
+
+static int cs_etm_snapshot_start(struct auxtrace_record *itr)
+{
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ struct perf_evsel *evsel;
+
+ evlist__for_each_entry(ptr->evlist, evsel) {
+ if (evsel->attr.type == ptr->cs_etm_pmu->type)
+ return perf_evsel__disable(evsel);
+ }
+ return -EINVAL;
+}
+
+static int cs_etm_snapshot_finish(struct auxtrace_record *itr)
+{
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ struct perf_evsel *evsel;
+
+ evlist__for_each_entry(ptr->evlist, evsel) {
+ if (evsel->attr.type == ptr->cs_etm_pmu->type)
+ return perf_evsel__enable(evsel);
+ }
+ return -EINVAL;
+}
+
+static u64 cs_etm_reference(struct auxtrace_record *itr __maybe_unused)
+{
+ return (((u64) rand() << 0) & 0x00000000FFFFFFFFull) |
+ (((u64) rand() << 32) & 0xFFFFFFFF00000000ull);
+}
+
+static void cs_etm_recording_free(struct auxtrace_record *itr)
+{
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ free(ptr);
+}
+
+static int cs_etm_read_finish(struct auxtrace_record *itr, int idx)
+{
+ struct cs_etm_recording *ptr =
+ container_of(itr, struct cs_etm_recording, itr);
+ struct perf_evsel *evsel;
+
+ evlist__for_each_entry(ptr->evlist, evsel) {
+ if (evsel->attr.type == ptr->cs_etm_pmu->type)
+ return perf_evlist__enable_event_idx(ptr->evlist,
+ evsel, idx);
+ }
+
+ return -EINVAL;
+}
+
+struct auxtrace_record *cs_etm_record_init(int *err)
+{
+ struct perf_pmu *cs_etm_pmu;
+ struct cs_etm_recording *ptr;
+
+ cs_etm_pmu = perf_pmu__find(CORESIGHT_ETM_PMU_NAME);
+
+ if (!cs_etm_pmu) {
+ *err = -EINVAL;
+ goto out;
+ }
+
+ ptr = zalloc(sizeof(struct cs_etm_recording));
+ if (!ptr) {
+ *err = -ENOMEM;
+ goto out;
+ }
+
+ ptr->cs_etm_pmu = cs_etm_pmu;
+ ptr->itr.parse_snapshot_options = cs_etm_parse_snapshot_options;
+ ptr->itr.recording_options = cs_etm_recording_options;
+ ptr->itr.info_priv_size = cs_etm_info_priv_size;
+ ptr->itr.info_fill = cs_etm_info_fill;
+ ptr->itr.find_snapshot = cs_etm_find_snapshot;
+ ptr->itr.snapshot_start = cs_etm_snapshot_start;
+ ptr->itr.snapshot_finish = cs_etm_snapshot_finish;
+ ptr->itr.reference = cs_etm_reference;
+ ptr->itr.free = cs_etm_recording_free;
+ ptr->itr.read_finish = cs_etm_read_finish;
+
+ *err = 0;
+ return &ptr->itr;
+out:
+ return NULL;
+}
diff --git a/tools/perf/arch/arm/util/cs-etm.h b/tools/perf/arch/arm/util/cs-etm.h
new file mode 100644
index 000000000000..909f486d02d1
--- /dev/null
+++ b/tools/perf/arch/arm/util/cs-etm.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier@linaro.org>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef INCLUDE__PERF_CS_ETM_H__
+#define INCLUDE__PERF_CS_ETM_H__
+
+struct auxtrace_record *cs_etm_record_init(int *err);
+
+#endif
diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index 3876dd05bb8b..cef6fb38d17e 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -1,4 +1,6 @@
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
-libperf-$(CONFIG_AUXTRACE) += ../../arm/util/pmu.o
+libperf-$(CONFIG_AUXTRACE) += ../../arm/util/pmu.o \
+ ../../arm/util/auxtrace.o \
+ ../../arm/util/cs-etm.o
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index c9169011e55e..c0aba8e839aa 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -892,6 +892,7 @@ int perf_event__process_auxtrace_info(struct perf_tool *tool __maybe_unused,
return intel_pt_process_auxtrace_info(event, session);
case PERF_AUXTRACE_INTEL_BTS:
return intel_bts_process_auxtrace_info(event, session);
+ case PERF_AUXTRACE_CS_ETM:
case PERF_AUXTRACE_UNKNOWN:
default:
return -EINVAL;
diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
index ac5f0d7167e6..09286f193532 100644
--- a/tools/perf/util/auxtrace.h
+++ b/tools/perf/util/auxtrace.h
@@ -41,6 +41,7 @@ enum auxtrace_type {
PERF_AUXTRACE_UNKNOWN,
PERF_AUXTRACE_INTEL_PT,
PERF_AUXTRACE_INTEL_BTS,
+ PERF_AUXTRACE_CS_ETM,
};
enum itrace_period_type {
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
new file mode 100644
index 000000000000..3cc6bc3263fe
--- /dev/null
+++ b/tools/perf/util/cs-etm.h
@@ -0,0 +1,74 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier@linaro.org>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef INCLUDE__UTIL_PERF_CS_ETM_H__
+#define INCLUDE__UTIL_PERF_CS_ETM_H__
+
+/* Versionning header in case things need tro change in the future. That way
+ * decoding of old snapshot is still possible.
+ */
+enum {
+ /* Starting with 0x0 */
+ CS_HEADER_VERSION_0,
+ /* PMU->type (32 bit), total # of CPUs (32 bit) */
+ CS_PMU_TYPE_CPUS,
+ CS_ETM_SNAPSHOT,
+ CS_HEADER_VERSION_0_MAX,
+};
+
+/* Beginning of header common to both ETMv3 and V4 */
+enum {
+ CS_ETM_MAGIC,
+ CS_ETM_CPU,
+};
+
+/* ETMv3/PTM metadata */
+enum {
+ /* Dynamic, configurable parameters */
+ CS_ETM_ETMCR = CS_ETM_CPU + 1,
+ CS_ETM_ETMTRACEIDR,
+ /* RO, taken from sysFS */
+ CS_ETM_ETMCCER,
+ CS_ETM_ETMIDR,
+ CS_ETM_PRIV_MAX,
+};
+
+/* ETMv4 metadata */
+enum {
+ /* Dynamic, configurable parameters */
+ CS_ETMV4_TRCCONFIGR = CS_ETM_CPU + 1,
+ CS_ETMV4_TRCTRACEIDR,
+ /* RO, taken from sysFS */
+ CS_ETMV4_TRCIDR0,
+ CS_ETMV4_TRCIDR1,
+ CS_ETMV4_TRCIDR2,
+ CS_ETMV4_TRCIDR8,
+ CS_ETMV4_TRCAUTHSTATUS,
+ CS_ETMV4_PRIV_MAX,
+};
+
+#define KiB(x) ((x) * 1024)
+#define MiB(x) ((x) * 1024 * 1024)
+
+#define CS_ETM_HEADER_SIZE (CS_HEADER_VERSION_0_MAX * sizeof(u64))
+
+static const u64 __perf_cs_etmv3_magic = 0x3030303030303030ULL;
+static const u64 __perf_cs_etmv4_magic = 0x4040404040404040ULL;
+#define CS_ETMV3_PRIV_SIZE (CS_ETM_PRIV_MAX * sizeof(u64))
+#define CS_ETMV4_PRIV_SIZE (CS_ETMV4_PRIV_MAX * sizeof(u64))
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 04/15] perf tools: Make coresight PMU listable
From: Arnaldo Carvalho de Melo @ 2016-09-22 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474578779-14095-1-git-send-email-acme@kernel.org>
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Adding the required mechanic allowing 'perf list pmu' to discover
coresight ETM/PTM tracers.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1474041004-13956-3-git-send-email-mathieu.poirier at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
MAINTAINERS | 1 +
tools/perf/arch/arm/util/Build | 2 ++
tools/perf/arch/arm/util/pmu.c | 34 ++++++++++++++++++++++++++++++++++
tools/perf/arch/arm64/util/Build | 2 ++
4 files changed, 39 insertions(+)
create mode 100644 tools/perf/arch/arm/util/pmu.c
diff --git a/MAINTAINERS b/MAINTAINERS
index db814a89599c..7407fe779053 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1123,6 +1123,7 @@ F: drivers/hwtracing/coresight/*
F: Documentation/trace/coresight.txt
F: Documentation/devicetree/bindings/arm/coresight.txt
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
+F: tools/perf/arch/arm/util/pmu.c
ARM/CORGI MACHINE SUPPORT
M: Richard Purdie <rpurdie@rpsys.net>
diff --git a/tools/perf/arch/arm/util/Build b/tools/perf/arch/arm/util/Build
index f98da17357c0..4093fd146f46 100644
--- a/tools/perf/arch/arm/util/Build
+++ b/tools/perf/arch/arm/util/Build
@@ -2,3 +2,5 @@ libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
+
+libperf-$(CONFIG_AUXTRACE) += pmu.o
diff --git a/tools/perf/arch/arm/util/pmu.c b/tools/perf/arch/arm/util/pmu.c
new file mode 100644
index 000000000000..af9fb666b44f
--- /dev/null
+++ b/tools/perf/arch/arm/util/pmu.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier@linaro.org>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <string.h>
+#include <linux/coresight-pmu.h>
+#include <linux/perf_event.h>
+
+#include "../../util/pmu.h"
+
+struct perf_event_attr
+*perf_pmu__get_default_config(struct perf_pmu *pmu __maybe_unused)
+{
+#ifdef HAVE_AUXTRACE_SUPPORT
+ if (!strcmp(pmu->name, CORESIGHT_ETM_PMU_NAME)) {
+ /* add ETM default config here */
+ pmu->selectable = true;
+ }
+#endif
+ return NULL;
+}
diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index 02f41dba4f4f..3876dd05bb8b 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -1,2 +1,4 @@
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
+
+libperf-$(CONFIG_AUXTRACE) += ../../arm/util/pmu.o
--
2.7.4
^ permalink raw reply related
* [PATCH 03/15] perf tools: Confine __get_cpuid() to x86 architecture
From: Arnaldo Carvalho de Melo @ 2016-09-22 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474578779-14095-1-git-send-email-acme@kernel.org>
From: Mathieu Poirier <mathieu.poirier@linaro.org>
The __get_cpuid() test is only valid when compiling for x86. When
compiling for other architectures like ARM/ARM64 the test fails event if
the functionality is not required.
This patch isolate the build-in feature check to x86 platform, allowing
the compilation and usage of PMUs that use the AUXTRACE infrastructure
on other architectures (i.e ARM CoreSight).
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1474041004-13956-2-git-send-email-mathieu.poirier at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/Makefile.config | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 24803c58049a..72edf83d76b7 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -746,10 +746,13 @@ ifdef LIBBABELTRACE
endif
ifndef NO_AUXTRACE
- ifeq ($(feature-get_cpuid), 0)
- msg := $(warning Your gcc lacks the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please install a newer gcc);
- NO_AUXTRACE := 1
- else
+ ifeq ($(ARCH),x86)
+ ifeq ($(feature-get_cpuid), 0)
+ msg := $(warning Your gcc lacks the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please install a newer gcc);
+ NO_AUXTRACE := 1
+ endif
+ endif
+ ifndef NO_AUXTRACE
$(call detected,CONFIG_AUXTRACE)
CFLAGS += -DHAVE_AUXTRACE_SUPPORT
endif
--
2.7.4
^ permalink raw reply related
* [GIT PULL 00/15] perf/core improvements and fixes
From: Arnaldo Carvalho de Melo @ 2016-09-22 21:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit 89f1c2c59c4aef8e26edbc7db5175e6ffb0e9ec7:
Merge tag 'perf-core-for-mingo-20160920' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2016-09-20 23:32:02 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160922
for you to fetch changes up to 2d831454140f28fa643b78deede4511b9e2c9e5f:
perf hists: Make hists__fprintf_headers function global (2016-09-22 13:08:59 -0300)
----------------------------------------------------------------
perf/core improvements:
New features:
- Add support for interacting with Coresight PMU ETMs/PTMs, that are IP blocks
to perform hardware assisted tracing on a ARM CPU core (Mathieu Poirier)
Infrastructure:
- Histogram prep work for the upcoming c2c tool (Jiri Olsa)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
----------------------------------------------------------------
Jiri Olsa (9):
perf evsel: Remove superfluous initialization of weight
perf hists: Use bigger buffer for stdio headers
perf hists: Add __hist_entry__snprintf function
perf tools: Make reset_dimensions global
perf tools: Make output_field_add and sort_dimension__add global
perf tools: Make several sorting functions global
perf tools: Make several display functions global
perf hists: Make __hist_entry__snprintf function global
perf hists: Make hists__fprintf_headers function global
Mathieu Poirier (6):
perf tools: Confine __get_cpuid() to x86 architecture
perf tools: Make coresight PMU listable
perf tools: Add coresight etm PMU record capabilities
perf pmu: Push configuration down to PMU driver
perf tools: Add PMU configuration to tools
perf tools: Add sink configuration for cs_etm PMU
MAINTAINERS | 5 +
tools/perf/Makefile.config | 11 +-
tools/perf/arch/arm/util/Build | 2 +
tools/perf/arch/arm/util/auxtrace.c | 54 ++++
tools/perf/arch/arm/util/cs-etm.c | 617 ++++++++++++++++++++++++++++++++++++
tools/perf/arch/arm/util/cs-etm.h | 26 ++
tools/perf/arch/arm/util/pmu.c | 36 +++
tools/perf/arch/arm64/util/Build | 4 +
tools/perf/builtin-record.c | 10 +
tools/perf/builtin-stat.c | 9 +
tools/perf/builtin-top.c | 13 +
tools/perf/ui/browsers/hists.c | 2 +-
tools/perf/ui/hist.c | 2 +-
tools/perf/ui/stdio/hist.c | 14 +-
tools/perf/util/Build | 1 +
tools/perf/util/auxtrace.c | 1 +
tools/perf/util/auxtrace.h | 1 +
tools/perf/util/cs-etm.h | 74 +++++
tools/perf/util/drv_configs.c | 77 +++++
tools/perf/util/drv_configs.h | 26 ++
tools/perf/util/evsel.c | 2 -
tools/perf/util/hist.h | 5 +
tools/perf/util/pmu.h | 2 +
tools/perf/util/sort.c | 16 +-
tools/perf/util/sort.h | 11 +
25 files changed, 1001 insertions(+), 20 deletions(-)
create mode 100644 tools/perf/arch/arm/util/auxtrace.c
create mode 100644 tools/perf/arch/arm/util/cs-etm.c
create mode 100644 tools/perf/arch/arm/util/cs-etm.h
create mode 100644 tools/perf/arch/arm/util/pmu.c
create mode 100644 tools/perf/util/cs-etm.h
create mode 100644 tools/perf/util/drv_configs.c
create mode 100644 tools/perf/util/drv_configs.h
[root at zoo ~]# time dm
1 73.911 alpine:3.4: Ok
2 26.890 android-ndk:r12b-arm: Ok
3 77.833 archlinux:latest: Ok
4 40.814 centos:5: Ok
5 64.151 centos:6: Ok
6 75.720 centos:7: Ok
7 68.960 debian:7: Ok
8 75.606 debian:8: Ok
9 75.127 fedora:20: Ok
10 80.186 fedora:21: Ok
11 80.157 fedora:22: Ok
12 83.273 fedora:23: Ok
13 91.566 fedora:24: Ok
14 37.720 fedora:24-x-ARC-uClibc: Ok
15 98.492 fedora:rawhide: Ok
16 100.555 mageia:5: Ok
17 94.140 opensuse:13.2: Ok
18 95.476 opensuse:42.1: Ok
19 106.037 opensuse:tumbleweed: Ok
20 75.951 ubuntu:12.04.5: Ok
21 52.138 ubuntu:14.04: Ok
22 94.814 ubuntu:14.04.4: Ok
23 100.525 ubuntu:15.10: Ok
24 93.813 ubuntu:16.04: Ok
25 85.214 ubuntu:16.04-x-arm: Ok
26 83.487 ubuntu:16.04-x-arm64: Ok
27 82.918 ubuntu:16.04-x-powerpc64: Ok
28 84.189 ubuntu:16.04-x-powerpc64el: Ok
29 93.162 ubuntu:16.10: Ok
real 38m13.568s
user 0m2.379s
sys 0m2.402s
[root at zoo ~]#
[root at jouet ~]# perf test
1: vmlinux symtab matches kallsyms : Ok
2: detect openat syscall event : Ok
3: detect openat syscall event on all cpus : Ok
4: read samples using the mmap interface : Ok
5: parse events tests : Ok
6: Validate PERF_RECORD_* events & perf_sample fields : Ok
7: Test perf pmu format parsing : Ok
8: Test dso data read : Ok
9: Test dso data cache : Ok
10: Test dso data reopen : Ok
11: roundtrip evsel->name check : Ok
12: Check parsing of sched tracepoints fields : Ok
13: Generate and check syscalls:sys_enter_openat event fields: Ok
14: struct perf_event_attr setup : Ok
15: Test matching and linking multiple hists : Ok
16: Try 'import perf' in python, checking link problems : Ok
17: Test breakpoint overflow signal handler : Ok
18: Test breakpoint overflow sampling : Ok
19: Test number of exit event of a simple workload : Ok
20: Test software clock events have valid period values : Ok
21: Test object code reading : Ok
22: Test sample parsing : Ok
23: Test using a dummy software event to keep tracking : Ok
24: Test parsing with no sample_id_all bit set : Ok
25: Test filtering hist entries : Ok
26: Test mmap thread lookup : Ok
27: Test thread mg sharing : Ok
28: Test output sorting of hist entries : Ok
29: Test cumulation of child hist entries : Ok
30: Test tracking with sched_switch : Ok
31: Filter fds with revents mask in a fdarray : Ok
32: Add fd to a fdarray, making it autogrow : Ok
33: Test kmod_path__parse function : Ok
34: Test thread map : Ok
35: Test LLVM searching and compiling :
35.1: Basic BPF llvm compiling test : Ok
35.2: Test kbuild searching : Ok
35.3: Compile source for BPF prologue generation test : Ok
35.4: Compile source for BPF relocation test : Ok
36: Test topology in session : Ok
37: Test BPF filter :
37.1: Test basic BPF filtering : Ok
37.2: Test BPF prologue generation : Ok
37.3: Test BPF relocation checker : Ok
38: Test thread map synthesize : Ok
39: Test cpu map synthesize : Ok
40: Test stat config synthesize : Ok
41: Test stat synthesize : Ok
42: Test stat round synthesize : Ok
43: Test attr update synthesize : Ok
44: Test events times : Ok
45: Test backward reading from ring buffer : Ok
46: Test cpu map print : Ok
47: Test SDT event probing : Ok
48: Test is_printable_array function : Ok
49: Test bitmap print : Ok
50: x86 rdpmc test : Ok
51: Test converting perf time to TSC : Ok
52: Test dwarf unwind : Ok
53: Test x86 instruction decoder - new instructions : Ok
54: Test intel cqm nmi context read : Skip
[root at jouet ~]#
^ permalink raw reply
* [PATCH v2] ARM: dts: wheat: add DU support
From: Sergei Shtylyov @ 2016-09-22 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <34968644.DhifNderY8@wasted.cogentembedded.com>
Define the Wheat board dependent part of the DU device node.
Add the device nodes for the Analog Devices ADV7513 HDMI transmitters
connected to DU0/1. Add the necessary subnodes to interconnect DU with
HDMI transmitters/connectors.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against the 'renesas-devel-20160919-v4.8-rc7' of Simon Horman's
'renesas.git' repo...
The patch depends on the 2 DRM patches (already merged by the maintainers) in
order to work correctly.
Changes in version 2:
- refreshed the patch.
arch/arm/boot/dts/r8a7792-wheat.dts | 126 ++++++++++++++++++++++++++++++++++++
1 file changed, 126 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7792-wheat.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7792-wheat.dts
+++ renesas/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -86,6 +86,34 @@
gpio = <&gpio11 12 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ hdmi-out0 {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con0: endpoint {
+ remote-endpoint = <&adv7513_0_out>;
+ };
+ };
+ };
+
+ hdmi-out1 {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con1: endpoint {
+ remote-endpoint = <&adv7513_1_out>;
+ };
+ };
+ };
+
+ osc2_clk: osc2 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <74250000>;
+ };
};
&extal_clk {
@@ -128,6 +156,16 @@
groups = "qspi_ctrl", "qspi_data4";
function = "qspi";
};
+
+ du0_pins: du0 {
+ groups = "du0_rgb888", "du0_sync", "du0_disp";
+ function = "du0";
+ };
+
+ du1_pins: du1 {
+ groups = "du1_rgb666", "du1_sync", "du1_disp";
+ function = "du1";
+ };
};
&scif0 {
@@ -196,4 +234,92 @@
};
};
};
+};
+
+&i2c4 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ hdmi at 3d {
+ compatible = "adi,adv7513";
+ reg = <0x3d>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7513_0_in: endpoint {
+ remote-endpoint = <&du_out_rgb0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7513_0_out: endpoint {
+ remote-endpoint = <&hdmi_con0>;
+ };
+ };
+ };
+ };
+
+ hdmi at 39 {
+ compatible = "adi,adv7513";
+ reg = <0x39>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7513_1_in: endpoint {
+ remote-endpoint = <&du_out_rgb1>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7513_1_out: endpoint {
+ remote-endpoint = <&hdmi_con1>;
+ };
+ };
+ };
+ };
+};
+
+&du {
+ pinctrl-0 = <&du0_pins &du1_pins>;
+ pinctrl-names = "default";
+
+ clocks = <&mstp7_clks R8A7792_CLK_DU0>, <&mstp7_clks R8A7792_CLK_DU1>,
+ <&osc2_clk>;
+ clock-names = "du.0", "du.1", "dclkin.0";
+ status = "okay";
+
+ ports {
+ port at 0 {
+ endpoint {
+ remote-endpoint = <&adv7513_0_in>;
+ };
+ };
+ port at 1 {
+ endpoint {
+ remote-endpoint = <&adv7513_1_in>;
+ };
+ };
+ };
};
^ permalink raw reply
* Regression in next with "softirq: fix tasklet_kill() and its users"
From: Tony Lindgren @ 2016-09-22 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a305129a-e2b4-9ba1-9e94-7998277da035@oracle.com>
* Santosh Shilimkar <santosh.shilimkar@oracle.com> [160922 13:59]:
> On 9/22/2016 1:51 PM, Tony Lindgren wrote:
> > Hi Santosh,
> >
> > Looks like commit 1f5e9c3bc47f ("softirq: fix tasklet_kill() and
> > its users") causes pandaboard es to not get any IP address on the
> > smsc95xx USB Ethernet.
> >
> > Reverting the commits fixes the issue. Any ideas?
> >
> Yep. It was discussed today morning and Stephen was suppose to
> revert that commit from next for now.
>
> The tasklet core fix even though fixes the issue, there are many
> bad users of tasklet which are using tasklet APIs without
> doing any sort of tasklet initialization. So there is more
> work to do before the tasklet core can be fixed.
OK thanks for the info.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] arm: dts: zynq: Add MicroZed board support
From: Sören Brinkmann @ 2016-09-22 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474550489-7005-1-git-send-email-jagan@amarulasolutions.com>
On Thu, 2016-09-22 at 18:51:29 +0530, Jagan Teki wrote:
> From: Jagan Teki <jteki@openedev.com>
>
> Added basic dts support for MicroZed board.
>
> - UART
> - SDHCI
> - Ethernet
>
> Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Jagan Teki <jteki@openedev.com>
> ---
> Changes for v2:
> - Add SDHCI
> - Add Ethernet
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/zynq-microzed.dts | 95 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 96 insertions(+)
> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faacd52..4d7b858 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
> wm8750-apc8750.dtb \
> wm8850-w70v2.dtb
> dtb-$(CONFIG_ARCH_ZYNQ) += \
> + zynq-microzed.dtb \
> zynq-parallella.dtb \
> zynq-zc702.dtb \
> zynq-zc706.dtb \
> diff --git a/arch/arm/boot/dts/zynq-microzed.dts b/arch/arm/boot/dts/zynq-microzed.dts
> new file mode 100644
> index 0000000..9e64496
> --- /dev/null
> +++ b/arch/arm/boot/dts/zynq-microzed.dts
> @@ -0,0 +1,95 @@
> +/*
> + * Copyright (C) 2015 Jagan Teki <jteki@openedev.com>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +/dts-v1/;
> +/include/ "zynq-7000.dtsi"
> +
> +/ {
> + model = "Zynq MicroZED Development Board";
> + compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
> +
> + aliases {
> + ethernet0 = &gem0;
> + serial0 = &uart1;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x40000000>;
> + };
> +
> + chosen {
> + bootargs = "earlycon";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0 {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <33333333>;
> +};
> +
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy at 0 {
> + reg = <0>;
> + };
> +};
> +
> +&sdhci0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb0_default>;
> +};
> +
> +&pinctrl0 {
> + pinctrl_usb0_default: usb0-default {
> + mux {
> + groups = "usb0_0_grp";
> + function = "usb0";
> + };
> +
> + conf {
> + groups = "usb0_0_grp";
> + slew-rate = <0>;
> + io-standard = <1>;
> + };
> +
> + conf-rx {
> + pins = "MIO29", "MIO31", "MIO36";
> + bias-high-impedance;
> + };
> +
> + conf-tx {
> + pins = "MIO28", "MIO30", "MIO32", "MIO33", "MIO34",
> + "MIO35", "MIO37", "MIO38", "MIO39";
> + bias-disable;
> + };
> + };
> +};
I guess it's not strictly required, but shouldn't there be pinctrl
descriptions for all devices?
S?ren
^ permalink raw reply
* Regression in next with "softirq: fix tasklet_kill() and its users"
From: Santosh Shilimkar @ 2016-09-22 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922205122.ezsxjint2l6lytyi@atomide.com>
On 9/22/2016 1:51 PM, Tony Lindgren wrote:
> Hi Santosh,
>
> Looks like commit 1f5e9c3bc47f ("softirq: fix tasklet_kill() and
> its users") causes pandaboard es to not get any IP address on the
> smsc95xx USB Ethernet.
>
> Reverting the commits fixes the issue. Any ideas?
>
Yep. It was discussed today morning and Stephen was suppose to
revert that commit from next for now.
The tasklet core fix even though fixes the issue, there are many
bad users of tasklet which are using tasklet APIs without
doing any sort of tasklet initialization. So there is more
work to do before the tasklet core can be fixed.
Regards,
Santosh
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2
From: Krzysztof Kozlowski @ 2016-09-22 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87shsrlq1f.fsf@monsta.com>
On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote:
>
> Krzysztof Kozlowski writes:
>
> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote:
> >> This allows to reboot the device into recovery mode and into the download
> >> mode of the bootloader.
> >
> > Which bootloader? Probably UBoot... or Samsung stock one? Could you put
> > that information here?
>
> I'm only working with the stock one. I was under the impression that the
> stock bootloader cannot be replaced on a i9300 because there's a
> signature check. Is UBoot loaded after the stock one on Trats2 or how
> does this work? I didn't find information on that.
+CC Marek,
Trats2 is working with U-Boot. Just U-Boot. However I never converted S3
into Trats2 on my own. I always used targets prepared to be "Trats2"
type.
Of course kernel is independent to bootloader but in that case you want
to use a specific interface between kernel and specific bootloader
type/version. In that case - this should be U-Boot, I think.
>
> >>
> >> Signed-off-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
> >> ---
> >> arch/arm/boot/dts/exynos4412-trats2.dts | 14 ++++++++++++++
> >> arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
> >> 2 files changed, 15 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
> >> index 129e973..a38d1e3 100644
> >> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> >> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> >> @@ -1294,3 +1294,17 @@
> >> vtmu-supply = <&ldo10_reg>;
> >> status = "okay";
> >> };
> >> +
> >> +&pmu {
> >> + compatible = "syscon", "simple-mfd";
> >> +
> >> + reboot-mode {
> >> + compatible = "syscon-reboot-mode";
> >> + offset = <0x80c>;
> >> +
> >> + mode-normal = <0x12345670>;
> >> + mode-bootloader = <0x12345671>;
> >> + mode-download = <0x12345671>;
> >> + mode-recovery = <0x12345674>;
> >
> > Hmmm, how did you get these values? Are they already supported?
>
> I only have the vendor source drop as documentation. The magic mode
> values [1] and the offset [2] can be found there.
It would be useful to mention that in commit msg (just the source)...
however as I wrote above, these values should be for U-Boot, not the
stock one.
Best regards,
Krzysztof
>
> > It would be nice to document them:
> > 1. In Documentation/arm/Samsung/Bootloader-interface.txt
> > 2. In header. I hate such magic numbers... you could add new header next
> > to existing rockchip one:
> > include/dt-bindings/soc/samsung,boot-mode.h
> > (and update maintainers entry :) )
>
> Thanks for the review! I will do the documentation and update the commit
> message.
>
> Best regards,
> Wolfgang
>
> [1] https://code.fossencdi.org/kernel_samsung_smdk4412.git/tree/arch/arm/mach-exynos/sec-reboot.c#n65
>
> [2] https://code.fossencdi.org/kernel_samsung_smdk4412.git/tree/arch/arm/mach-exynos/include/mach/regs-pmu.h#n79
>
>
> --
> Website: https://fossencdi.org
> Jabber: wolfgang at wiedmeyer.de
> OpenPGP: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4
> Key download: https://wiedmeyer.de/keys/ww.asc
^ permalink raw reply
* Regression in next with "softirq: fix tasklet_kill() and its users"
From: Tony Lindgren @ 2016-09-22 20:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
Looks like commit 1f5e9c3bc47f ("softirq: fix tasklet_kill() and
its users") causes pandaboard es to not get any IP address on the
smsc95xx USB Ethernet.
Reverting the commits fixes the issue. Any ideas?
Regards,
Tony
^ permalink raw reply
* [PATCH 3/3] arm64: Add the Raspberry Pi firmware's interface to the FXL6408.
From: Gerd Hoffmann @ 2016-09-22 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919161314.25858-3-eric@anholt.net>
On Mo, 2016-09-19 at 17:13 +0100, Eric Anholt wrote:
> This gets us hotplug detection of HDMI, so that graphics now works at
> boot. Tested with watching the output of xrandr while plugging and
> unplugging the HDMI cable.
Very nice. Whole patch series:
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
/me hopes this lands in the 4.9 merge window.
cheers,
Gerd
^ permalink raw reply
* [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support
From: atull @ 2016-09-22 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160809160039.GX29630@windriver.com>
On Tue, 9 Aug 2016, Paul Gortmaker wrote:
> [Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support] On 08/08/2016 (Mon 13:44) Moritz Fischer wrote:
>
> > Hi Alan,
> >
> > On Mon, Aug 8, 2016 at 12:18 PM, atull <atull@opensource.altera.com> wrote:
> >
> > >> Please don't use module.h in drivers controlled by a bool
> > >> Kconfig setting.
> > >>
> > >> THanks,
> > >> Paul.
> > >>
> > >
> > > Thanks for the feedback. Can you provide an example of what you
> > > would consider to be proper usage in the kernel?
> >
> >
> > I think Paul is suggesting to use
> >
> > static int __init alt_fpga_bridge_init(void)
> > {
> > platform_driver_register(&alt_fpga_bridge_driver);
> > }
> >
> > device_initcall(alt_fpga_bridge_init);
> >
> > or better:
> >
> > builtin_platform_driver(&alt_fpga_bridge_driver);
> >
> > Like for example in: drivers/cpuidle/cpuidle-mvebu-v7.c
>
> Yes, pretty much that -- if you have a bool Kconfig, you should be using
> builtin registration functions, and have no need for module.h or
> anything MODULE_<xyz> or any module_init/module_exit calls.
>
> An empty file containing nothing but #include <linux/module.h> will
> cause cpp to emit about 750k of goop, so we really should only be using
> it for drivers that are genuinely modular; i.e. tristate Kconfig.
>
> Thanks,
> Paul.
> --
>
> >
> > Cheers,
> >
> > Moritz
>
Thanks for the feedback and explanations!
I've retested my stuff with it all built as modules (mgr, bridged,
and fpga-region) and it all works that way as well as built in.
So I'll fix up the Kconfig as tristates for everybody. Also
I'll add some dependencies as FPGA_REGION should be dependent
on FPGA_BRIDGE.
Alan
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Mark Brown @ 2016-09-22 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922201301.0157a292@bbrezillon>
On Thu, Sep 22, 2016 at 08:13:01PM +0200, Boris Brezillon wrote:
> So, there are 2 different problems here:
> 1/ the board no longer boots because of commit 87248991a1de and a
> missing entry in the voltage table
> 2/ claiming the PWM pins at probe time can cause glitches
> I'm currently trying to solve #1, but most of the discussion in this
> thread was about addressing #2.
Well, if you actually want the entry in the voltage table then adding it
does seem the most sensible fix.
> > That was a very
> > long e-mail so I might be missing something but the obvious thing seems
> > to be to force a state since we'll be doing that when we enable anyway.
> Hm, okay, but which state should we choose? The first entry in the
> voltage-table?
That's why we don't do this currently. Probably the closest one if we
can work out what it was trying to achieve.
> > Or just not have the voltage table and use it as a continuous regulator.
> Yes, but that means patching the DT, which means breaking the DT compat.
It sounds like you want to fix the DT anyway though?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160922/adb328ef/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2
From: Wolfgang Wiedmeyer @ 2016-09-22 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922174606.GA4988@kozik-lap>
Krzysztof Kozlowski writes:
> On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote:
>> This allows to reboot the device into recovery mode and into the download
>> mode of the bootloader.
>
> Which bootloader? Probably UBoot... or Samsung stock one? Could you put
> that information here?
I'm only working with the stock one. I was under the impression that the
stock bootloader cannot be replaced on a i9300 because there's a
signature check. Is UBoot loaded after the stock one on Trats2 or how
does this work? I didn't find information on that.
>>
>> Signed-off-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
>> ---
>> arch/arm/boot/dts/exynos4412-trats2.dts | 14 ++++++++++++++
>> arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
>> 2 files changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
>> index 129e973..a38d1e3 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -1294,3 +1294,17 @@
>> vtmu-supply = <&ldo10_reg>;
>> status = "okay";
>> };
>> +
>> +&pmu {
>> + compatible = "syscon", "simple-mfd";
>> +
>> + reboot-mode {
>> + compatible = "syscon-reboot-mode";
>> + offset = <0x80c>;
>> +
>> + mode-normal = <0x12345670>;
>> + mode-bootloader = <0x12345671>;
>> + mode-download = <0x12345671>;
>> + mode-recovery = <0x12345674>;
>
> Hmmm, how did you get these values? Are they already supported?
I only have the vendor source drop as documentation. The magic mode
values [1] and the offset [2] can be found there.
> It would be nice to document them:
> 1. In Documentation/arm/Samsung/Bootloader-interface.txt
> 2. In header. I hate such magic numbers... you could add new header next
> to existing rockchip one:
> include/dt-bindings/soc/samsung,boot-mode.h
> (and update maintainers entry :) )
Thanks for the review! I will do the documentation and update the commit
message.
Best regards,
Wolfgang
[1] https://code.fossencdi.org/kernel_samsung_smdk4412.git/tree/arch/arm/mach-exynos/sec-reboot.c#n65
[2] https://code.fossencdi.org/kernel_samsung_smdk4412.git/tree/arch/arm/mach-exynos/include/mach/regs-pmu.h#n79
--
Website: https://fossencdi.org
Jabber: wolfgang at wiedmeyer.de
OpenPGP: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4
Key download: https://wiedmeyer.de/keys/ww.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160922/257562f9/attachment.sig>
^ permalink raw reply
* [PATCH v3] dmaengine: s3c24xx: Add dma_slave_map for s3c2440 devices
From: Sam Van Den Berge @ 2016-09-22 18:51 UTC (permalink / raw)
To: linux-arm-kernel
This patch updates the s3c24xx dma driver to be able to pass a
dma_slave_map array via the platform data. This is needed to
be able to use the new, simpler dmaengine API [1].
I used the virtual DMA channels as a parameter for the dma_filter
function. By doing that, I could reuse the existing filter function in
drivers/dma/s3c24xx-dma.c.
I have tested this on my mini2440 board with the audio driver.
According to my observations, dma_request_slave_channel in the
function dmaengine_pcm_new in the file
sound/soc/soc-generic-dmaengine-pcm.c now returns a valid DMA channel
whereas before no DMA channel was returned at that point.
Entries for DMACH_XD0, DMACH_XD1 and DMACH_TIMER are missing because I
don't realy know which driver to use for these.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/393635.html
Signed-off-by: Sam Van Den Berge <sam.van.den.berge@telenet.be>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
This patch depends on the audio fixes from Sylwester Nawrocki
(http://www.spinics.net/lists/arm-kernel/msg521918.html)
Changes since v2:
- s/3c2440-sdi/s3c2440-sdi/
- Removed reference to the audio fixes of Sylwester from the commit message
because I don't think it belongs in the commit message itself.
Changes since v1:
- rename arm into dmaengine in title
- one channel for s3c2440-sdi named "rx-tx"
arch/arm/mach-s3c24xx/common.c | 35 +++++++++++++++++++++++++++++++
drivers/dma/s3c24xx-dma.c | 3 +++
include/linux/platform_data/dma-s3c24xx.h | 6 ++++++
3 files changed, 44 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index fe7485d..f6c3f15 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -33,6 +33,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/platform_data/dma-s3c24xx.h>
+#include <linux/dmaengine.h>
#include <mach/hardware.h>
#include <mach/regs-clock.h>
@@ -445,10 +446,44 @@ static struct s3c24xx_dma_channel s3c2440_dma_channels[DMACH_MAX] = {
[DMACH_USB_EP4] = { S3C24XX_DMA_APB, true, S3C24XX_DMA_CHANREQ(4, 3), },
};
+static const struct dma_slave_map s3c2440_dma_slave_map[] = {
+ /* TODO: DMACH_XD0 */
+ /* TODO: DMACH_XD1 */
+ { "s3c2440-sdi", "rx-tx", (void *)DMACH_SDI },
+ { "s3c2410-spi.0", "rx", (void *)DMACH_SPI0 },
+ { "s3c2410-spi.0", "tx", (void *)DMACH_SPI0 },
+ { "s3c2410-spi.1", "rx", (void *)DMACH_SPI1 },
+ { "s3c2410-spi.1", "tx", (void *)DMACH_SPI1 },
+ { "s3c2440-uart.0", "rx", (void *)DMACH_UART0 },
+ { "s3c2440-uart.0", "tx", (void *)DMACH_UART0 },
+ { "s3c2440-uart.1", "rx", (void *)DMACH_UART1 },
+ { "s3c2440-uart.1", "tx", (void *)DMACH_UART1 },
+ { "s3c2440-uart.2", "rx", (void *)DMACH_UART2 },
+ { "s3c2440-uart.2", "tx", (void *)DMACH_UART2 },
+ { "s3c2440-uart.3", "rx", (void *)DMACH_UART3 },
+ { "s3c2440-uart.3", "tx", (void *)DMACH_UART3 },
+ /* TODO: DMACH_TIMER */
+ { "s3c24xx-iis", "rx", (void *)DMACH_I2S_IN },
+ { "s3c24xx-iis", "tx", (void *)DMACH_I2S_OUT },
+ { "samsung-ac97", "rx", (void *)DMACH_PCM_IN },
+ { "samsung-ac97", "tx", (void *)DMACH_PCM_OUT },
+ { "samsung-ac97", "rx", (void *)DMACH_MIC_IN },
+ { "s3c-hsudc", "rx0", (void *)DMACH_USB_EP1 },
+ { "s3c-hsudc", "rx1", (void *)DMACH_USB_EP2 },
+ { "s3c-hsudc", "rx2", (void *)DMACH_USB_EP3 },
+ { "s3c-hsudc", "rx3", (void *)DMACH_USB_EP4 },
+ { "s3c-hsudc", "tx0", (void *)DMACH_USB_EP1 },
+ { "s3c-hsudc", "tx1", (void *)DMACH_USB_EP2 },
+ { "s3c-hsudc", "tx2", (void *)DMACH_USB_EP3 },
+ { "s3c-hsudc", "tx3", (void *)DMACH_USB_EP4 }
+};
+
static struct s3c24xx_dma_platdata s3c2440_dma_platdata = {
.num_phy_channels = 4,
.channels = s3c2440_dma_channels,
.num_channels = DMACH_MAX,
+ .slave_map = s3c2440_dma_slave_map,
+ .slavecnt = ARRAY_SIZE(s3c2440_dma_slave_map),
};
struct platform_device s3c2440_device_dma = {
diff --git a/drivers/dma/s3c24xx-dma.c b/drivers/dma/s3c24xx-dma.c
index ce67075..d5c85e7 100644
--- a/drivers/dma/s3c24xx-dma.c
+++ b/drivers/dma/s3c24xx-dma.c
@@ -1301,6 +1301,9 @@ static int s3c24xx_dma_probe(struct platform_device *pdev)
s3cdma->slave.device_prep_dma_cyclic = s3c24xx_dma_prep_dma_cyclic;
s3cdma->slave.device_config = s3c24xx_dma_set_runtime_config;
s3cdma->slave.device_terminate_all = s3c24xx_dma_terminate_all;
+ s3cdma->slave.filter.map = pdata->slave_map;
+ s3cdma->slave.filter.mapcnt = pdata->slavecnt;
+ s3cdma->slave.filter.fn = s3c24xx_dma_filter;
/* Register as many memcpy channels as there are physical channels */
ret = s3c24xx_dma_init_virtual_channels(s3cdma, &s3cdma->memcpy,
diff --git a/include/linux/platform_data/dma-s3c24xx.h b/include/linux/platform_data/dma-s3c24xx.h
index 89ba1b0..4f9aba4 100644
--- a/include/linux/platform_data/dma-s3c24xx.h
+++ b/include/linux/platform_data/dma-s3c24xx.h
@@ -30,16 +30,22 @@ struct s3c24xx_dma_channel {
u16 chansel;
};
+struct dma_slave_map;
+
/**
* struct s3c24xx_dma_platdata - platform specific settings
* @num_phy_channels: number of physical channels
* @channels: array of virtual channel descriptions
* @num_channels: number of virtual channels
+ * @slave_map: dma slave map matching table
+ * @slavecnt: number of elements in slave_map
*/
struct s3c24xx_dma_platdata {
int num_phy_channels;
struct s3c24xx_dma_channel *channels;
int num_channels;
+ const struct dma_slave_map *slave_map;
+ int slavecnt;
};
struct dma_chan;
--
1.9.1
^ permalink raw reply related
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Stephen Boyd @ 2016-09-22 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917011605.GB10392@b29397-desktop>
Quoting Peter Chen (2016-09-16 18:16:05)
> On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > board to mux the D+/D- lines from the SoC between a micro usb
> > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > we need to change this mux to forward the D+/D- lines to either
> > > the port or the hub. Therefore, introduce a driver for this
> > > device that intercepts extcon USB_HOST events and logically
> > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > attached. When the cable goes away, it will logically deassert
> > > the gpio and mux the "device" lines.
> > >
> > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > >
> > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > Cc: <devicetree@vger.kernel.org>
> > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > ---
> > >
> > > Should I make the extcon part optional? I could see a case where there are two
> > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > software may want to mux between them at runtime. If we mandate an extcon,
> > > that won't be possible to support. Perhaps it would be better to have
> > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > endpoints would be useful too) so that when the controller wants to mux over
> > > a port it can do so.
> >
> > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > haven't written any code around it, but the idea is to allow the binding
> > to specify how the mux is connected to upstream and downstream D+/D-
> > lines. This way, we can do some dt parsing of the endpoints and their
> > parent nodes to figure out if the mux needs to be set high or low to use
> > a device connector or a usb hub based on if the id cable is present.
> > Maybe I'm over thinking things though and we could just have a DT
> > property for that.
> >
> > soc {
> > usb at 78d9000 {
> > extcon = <&usb_id>, <&usb_id>;
>
> Why you have two same extcon phandler? From my mind, one should id,
> another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> vbus support, how you support vbus detection for
> connection/disconnection with PC for your chipidea msm patch set?
This was already in the dts files for db410c. In the chipidea binding
one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
that great on this board because we only have on gpio for this.
^ permalink raw reply
* [PATCH v2] dmaengine: s3c24xx: Add dma_slave_map for s3c2440 devices
From: Sam Van Den Berge @ 2016-09-22 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b32bfb03-e0d1-09b4-95fc-5a6301a9bde5@kernel.org>
On Fri, Sep 16, 2016 at 01:16:31PM +0200, Krzysztof Kozlowski wrote:
> On 09/15/2016 09:41 PM, Sam Van Den Berge wrote:
> > This patch updates the s3c24xx dma driver to be able to pass a
> > dma_slave_map array via the platform data. This is needed to
> > be able to use the new, simpler dmaengine API [1].
> > I used the virtual DMA channels as a parameter for the dma_filter
> > function. By doing that, I could reuse the existing filter function in
> > drivers/dma/s3c24xx-dma.c.
> >
> > I have tested this on my mini2440 board with the audio driver.
> > (I first applied the audio fixes from Sylwester Nawrocki [2])
> > According to my observations, dma_request_slave_channel in the
> > function dmaengine_pcm_new in the file
> > sound/soc/soc-generic-dmaengine-pcm.c now returns a valid DMA channel
> > whereas before no DMA channel was returned at that point.
> >
> > Entries for DMACH_XD0, DMACH_XD1 and DMACH_TIMER are missing because I
> > don't realy know which driver to use for these.
> >
> > [1]
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/393635.html
> > [2] http://www.spinics.net/lists/arm-kernel/msg521918.html
> >
> > Signed-off-by: Sam Van Den Berge <sam.van.den.berge@telenet.be>
> > Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > ---
> >
> > Changes since v1:
> > - rename arm into dmaengine in title
> > - one channel for s3c2440-sdi named "rx-tx"
> >
> > arch/arm/mach-s3c24xx/common.c | 35 +++++++++++++++++++++++++++++++
> > drivers/dma/s3c24xx-dma.c | 3 +++
> > include/linux/platform_data/dma-s3c24xx.h | 6 ++++++
> > 3 files changed, 44 insertions(+)
>
> Vinod, do you want to take it through your tree? Not much difference for
> me, so in such case:
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
I was kinda waiting for an answer on this question because I didn't know
if I should add the acked-by or not but I'm going to assume that it's ok
so I'll include it in the third version of this patch.
>
> Best regards,
> Krzysztof
>
>
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Add entries for sound support on Odroid-XU board
From: Krzysztof Kozlowski @ 2016-09-22 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5fef2bec-adcf-0230-cd00-7fc29cbbcd32@samsung.com>
On Mon, Sep 19, 2016 at 10:47:46AM +0200, Sylwester Nawrocki wrote:
> On 09/17/2016 10:00 PM, Krzysztof Kozlowski wrote:
> > On Fri, Sep 16, 2016 at 01:58:32PM +0200, Krzysztof Kozlowski wrote:
> >> > On 09/16/2016 01:25 PM, Sylwester Nawrocki wrote:
> >>> > > On 09/16/2016 01:22 PM, Sylwester Nawrocki wrote:
> >>>> > >> This patch adds device nodes for the AUDSS clock controller,
> >>>> > >> peripheral DMA 0/1 controllers and the Audio Subsystem I2S controller.
> >>>> > >> These entries are required for sound support on Odroid-XU board.
> >>>> > >>
> >>>> > >> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> >>>> > >> ---
> >>>> > >> This patch depends on a patch adding clock ID macro definitions.
> >>>> > >> I'm going to provide a topic branch containing required changes.
> >>>> > >>
> >>>> > >> Changes since v1:
> >>>> > >> - GIC_SPI, IRQ_TYPE_NONE used in the PDMA and max98080 interrupt
> >>>> > >> specifiers,
> >>>> > >> - assigned-clock-* properties moved to respective controller
> >>>> > >> nodes.
> >>> > >
> >>> > > And here is a pull request containing clk dependency patches:
> >>> > >
> >>> > > The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
> >>> > >
> >>> > > Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
> >>> > >
> >>> > > are available in the git repository at:
> >>> > >
> >>> > > git://linuxtv.org/snawrocki/samsung.git tags/clk-v4.9-exynos54x0-dt
> >>> > >
> >>> > > for you to fetch changes up to 58d6506f327e3d192998ba03632f546da221b8d8:
> >>> > >
> >>> > > clk: samsung: exynos5410: Add clock IDs for PDMA and EPLL clocks (2016-09-09
> >>> > > 10:13:02 +0200)
> >>> > >
> >> >
> >> > Pulled and applied, thanks!
> >
> > This does not boot...
> > http://www.krzk.eu/builders/boot-odroid-xu-exynos/builds/216
> > http://www.krzk.eu/builders/boot-odroid-xu-multi_v7/builds/195
> >
> > I am going to send pull request this weekend (or Monday) so probably this
> > won't be included. If by any chance you prepare a fix soon, then it
> > will save me from rebasing the branch.
>
> Oops, indeed, I didn't test with just that part of clk changes applied.
> The only resolution here I can see is to pull my whole clk branch,
> it has already been pulled to the upstream clk tree.
Hmmmm, why the clock implementation is needed? Usually it should work
without it. The driver will just handle ENODEV or DEFER... Maybe there
is similar issue to the serial: e51e4d8a185d ("serial: samsung: Fix ERR
pointer dereference on deferred probe")?
Anyway, the patch will wait till next window opens. I hope it will work
then. :)
Best regards,
Krzysztof
>
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>
> are available in the git repository at:
>
> git://linuxtv.org/snawrocki/samsung.git tags/clk-v4.9-samsung
>
> for you to fetch changes up to be95d2c7d918b2b7b973378a1e92bdc6559c21f9:
>
> clk: samsung: Add support for EPLL on exynos5410 (2016-09-09 17:35:13 +0200)
>
> ----------------------------------------------------------------
> In addition to a few clean up and code consolidation patches this
> includes:
> - addition of sound subsystem related clocks for Exynos5410 SoC
> (EPLL, PDMA) and support for "samsung,exynos5410-audss-clock"
> compatible in the clk-exynos-audss driver,
> - addition of DRAM controller related clocks for exynos5420,
> - MAINTAINERS update adding Chanwoo Choi as the Samsung SoC
> clock drivers co-maintainer.
>
> ----------------------------------------------------------------
> Chanwoo Choi (5):
> clk: samsung: Add clock IDs for the CMU_CDREX (DRAM Express Controller)
> MAINTAINERS: Add myself as Samsung SoC clock drivers co-maintainer
> clk: samsung: exynos5260: Move struct samsung_cmu_info to init section
> clk: samsung: exynos5410: Use samsung_cmu_register_one() to simplify code
> clk: samsung: exynos5420: Add clocks for CMU_CDREX domain
>
> Sylwester Nawrocki (7):
> clk: samsung: exynos5410: Add clock IDs for PDMA and EPLL clocks
> clk: samsung: exynos5410: Expose the peripheral DMA gate clocks
> clk: samsung: Use common registration function for pll2550x
> clk: samsung: clk-exynos-audss: controller variant handling rework
> clk: samsung: clk-exynos-audss: Add exynos5410 compatible
> clk: samsung: clk-exynos-audss: Whitespace and debug trace cleanup
> clk: samsung: Add support for EPLL on exynos5410
>
> .../devicetree/bindings/clock/clk-exynos-audss.txt | 4 +-
> .../devicetree/bindings/clock/exynos5410-clock.txt | 21 +-
> MAINTAINERS | 3 +
> drivers/clk/samsung/clk-exynos-audss.c | 84 +++--
> drivers/clk/samsung/clk-exynos5260.c | 350 ++++++++++-----------
> drivers/clk/samsung/clk-exynos5410.c | 61 ++--
> drivers/clk/samsung/clk-exynos5420.c | 37 +++
> drivers/clk/samsung/clk-exynos5440.c | 9 +-
> drivers/clk/samsung/clk-pll.c | 154 ++++++---
> drivers/clk/samsung/clk-pll.h | 2 +
> include/dt-bindings/clock/exynos5410.h | 3 +
> include/dt-bindings/clock/exynos5420.h | 11 +-
> include/dt-bindings/clock/exynos5440.h | 2 +
> 13 files changed, 453 insertions(+), 288 deletions(-)
>
> --
> Thanks,
> Sylwester
^ permalink raw reply
* [RFC 1/4] arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support
From: Stephen Boyd @ 2016-09-22 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6cf4c215-e8a3-a9db-fcf1-8b56b5c1fab9@redhat.com>
Quoting Jeremy McNicoll (2016-09-20 17:42:02)
> On 2016-07-08 10:41 AM, Andy Gross wrote:
> > On Thu, Jul 07, 2016 at 05:41:04PM -0700, Jeremy McNicoll wrote:
> >> +
> >> +#include "../qcom/msm8992.dtsi"
> >> +
> >> +/ {
> >> + model = "LGE MSM8992 BULLHEAD rev-1.01";
> >> + compatible = "qcom,msm8992";
> >> + qcom,board-id = <0xb64 0>;
> >
> > Please work with sboyd to add the board-id to the dtbTool. We don't put
> > board-ids in the dts file. We post-process the dtb file and add them then.
> >
>
> sboyd has all the info he needs for this, I believe its just with legal
> now. Will remove for V2.
I've pushed out an update for dtbtool to have these msm ids.
>
> >> +
> >> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> >> +#include <dt-bindings/clock/qcom,gcc-msm8994.h>
> >> +
> >> +/ {
> >> + model = "Qualcomm Technologies, Inc. MSM 8992";
> >> + compatible = "qcom,msm8992";
> >> + qcom,msm-id = <251 0>, <252 0>;
>
> This is needed or else the LK provides the following error
>
> [5380] qcom,msm-id entry not found
>
> and refuses to boot.
>
>
> >> + qcom,pmic-id = <0x10009 0x1000A 0x0 0x0>;
> >
> > See above comment on ids.
>
> removal of this (pmic-id) seems to be ok.
>
Having the msm ids (and the pmic ids) in dtbtool isn't going to help
here though. I believe the bootloader on these devices uses a design of
appended dtbs where each dtb has the qcom,{msm-id,board-id,pmic-id}
properties in them. The QCDT "header" that dtbtool generates is not
used.
To fix that problem we'll need to update dtbtool to inject these
properties into the dtbs based on the compatible strings. Or get
maintainers to accept that these ids are now necessary for proper
functionality.
Furthermore, the value of board-id (0xb64) is concerning. qcom only
supports a certain set of values there for their boards, but vendors are
free to do whatever they want with that value. This means they can reuse
existing values that would map to qcom's concept of the "mtp" or "cdp"
boards, or they can numbers that would alias with other vendors.
Thankfully, msm-id and pmic-id are values that are under qcom's control,
so those are always going to be unique and sane. Really all that could
alias is board-id.
What does this all mean? We can't support non-qcom boards in the same
boot.img because of the possibility for the board-id property to alias
between different dtbs. Or at least dtbtool will have to do some alias
analysis and eject one aliasing dtbs from the blob. It also means that
we have a lot of work to do in dtbtool to inject these properties based
on strings, and to have custom parsers for different vendor prefixes so
that we know what values to inject (the nightmare is growing).
I've asked the bootloader folks to fix this in future platforms so that
we match based on the compatible string, instead of having to do any
post processing. Basically, put dtbtool logic into the bootloader. The
discussion is still on-going, but I'm hopeful that we don't need to keep
doing things here with post-processing and the headache will be reduced.
That could totally backfire though if vendors decide to leave the
bootloader unchanged and boot the "qcom,msm8992-mtp" dtb that's been
slightly tweaked for their design. Let's hope that doesn't happen.
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-22 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922124446.GA21681@red-moon>
On Thu, Sep 22, 2016 at 01:44:46PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Sep 22, 2016 at 11:10:13AM +0000, Gabriele Paoloni wrote:
> > Hi Lorenzo, Bjorn
> >
> > > -----Original Message-----
> > > From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi at arm.com]
> > > Sent: 22 September 2016 10:50
> > > To: Bjorn Helgaas
> > > Cc: Ard Biesheuvel; Tomasz Nowicki; David Daney; Will Deacon; Catalin
> > > Marinas; Rafael Wysocki; Arnd Bergmann; Hanjun Guo; Sinan Kaya;
> > > Jayachandran C; Christopher Covington; Duc Dang; Robert Richter; Marcin
> > > Wojtas; Liviu Dudau; Wangyijing; Mark Salter; linux-
> > > pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Linaro ACPI
> > > Mailman List; Jon Masters; Andrea Gallo; Jeremy Linton; liudongdong
> > > (C); Gabriele Paoloni; Jeff Hugo; linux-acpi at vger.kernel.org; linux-
> > > kernel at vger.kernel.org; Rafael J. Wysocki
> > > Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-
> > > specific register range for ACPI case
> > >
> > > On Wed, Sep 21, 2016 at 01:04:57PM -0500, Bjorn Helgaas wrote:
> > > > On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
> > > > > On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote:
> > > > > > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > > None of these platforms can be fixed entirely in software, and
> > > given
> > > > > > > that we will not be adding quirks for new broken hardware, we
> > > should
> > > > > > > ask ourselves whether having two versions of a quirk, i.e., one
> > > for
> > > > > > > broken hardware + currently shipping firmware, and one for the
> > > same
> > > > > > > broken hardware with fixed firmware is really an improvement
> > > over what
> > > > > > > has been proposed here.
> > > > > >
> > > > > > We're talking about two completely different types of quirks:
> > > > > >
> > > > > > 1) MCFG quirks to use memory-mapped config space that doesn't
> > > quite
> > > > > > conform to the ECAM model in the PCIe spec, and
> > > > > >
> > > > > > 2) Some yet-to-be-determined method to describe address space
> > > > > > consumed by a bridge.
> > > > > >
> > > > > > The first two patches of this series are a nice implementation
> > > for 1).
> > > > > > The third patch (ThunderX-specific) is one possibility for 2),
> > > but I
> > > > > > don't like it because there's no way for generic software like
> > > the
> > > > > > ACPI core to discover these resources.
> > > > >
> > > > > Ok, so basically this means that to implement (2) we need to assign
> > > > > some sort of _HID to these quirky PCI bridges (so that we know what
> > > > > device they represent and we can retrieve their _CRS). I take from
> > > > > this discussion that the goal is to make sure that all non-config
> > > > > resources have to be declared through _CRS device objects, which is
> > > > > fine but that requires a FW update (unless we can fabricate ACPI
> > > > > devices and corresponding _CRS in the kernel whenever we match a
> > > > > given MCFG table signature).
> > > >
> > > > All resources consumed by ACPI devices should be declared through
> > > > _CRS. If you want to fabricate ACPI devices or _CRS via kernel
> > > > quirks, that's fine with me. This could be triggered via MCFG
> > > > signature, DMI info, host bridge _HID, etc.
> > >
> > > I think the PNP quirk approach + PNP0c02 resource put forward by Gab
> > > is enough.
> >
> > Great thanks as we take a final decision I will ask Dogndgong to submit
> > another RFC based on this approach
> >
> > >
> > > > > We discussed this already and I think we should make a decision:
> > > > >
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-
> > > March/414722.html
> > > > >
> > > > > > > > I'd like to step back and come up with some understanding of
> > > how
> > > > > > > > non-broken firmware *should* deal with this issue. Then, if
> > > we *do*
> > > > > > > > work around this particular broken firmware in the kernel, it
> > > would be
> > > > > > > > nice to do it in a way that fits in with that understanding.
> > > > > > > >
> > > > > > > > For example, if a companion ACPI device is the preferred
> > > solution, an
> > > > > > > > ACPI quirk could fabricate a device with the required
> > > resources. That
> > > > > > > > would address the problem closer to the source and make it
> > > more likely
> > > > > > > > that the rest of the system will work correctly: /proc/iomem
> > > could
> > > > > > > > make sense, things that look at _CRS generically would work
> > > (e.g,
> > > > > > > > /sys/, an admittedly hypothetical "lsacpi", etc.)
> > > > > > > >
> > > > > > > > Hard-coding stuff in drivers is a point solution that doesn't
> > > provide
> > > > > > > > any guidance for future platforms and makes it likely that
> > > the hack
> > > > > > > > will get copied into even more drivers.
> > > > > > > >
> > > > > > >
> > > > > > > OK, I see. But the guidance for future platforms should be 'do
> > > not
> > > > > > > rely on quirks', and what I am arguing here is that the more we
> > > polish
> > > > > > > up this code and make it clean and reusable, the more likely it
> > > is
> > > > > > > that will end up getting abused by new broken hardware that we
> > > set out
> > > > > > > to reject entirely in the first place.
> > > > > > >
> > > > > > > So of course, if the quirk involves claiming resources, let's
> > > make
> > > > > > > sure that this occurs in the cleanest and most compliant way
> > > possible.
> > > > > > > But any factoring/reuse concerns other than for the current
> > > crop of
> > > > > > > broken hardware should be avoided imo.
> > > > > >
> > > > > > If future hardware is completely ECAM-compliant and we don't need
> > > any
> > > > > > more MCFG quirks, that would be great.
> > > > >
> > > > > Yes.
> > > > >
> > > > > > But we'll still need to describe that memory-mapped config space
> > > > > > somewhere. If that's done with PNP0C02 or similar devices (as is
> > > done
> > > > > > on my x86 laptop), we'd be all set.
> > > > >
> > > > > I am not sure I understand what you mean here. Are you referring
> > > > > to MCFG regions reported as PNP0c02 resources through its _CRS ?
> > > >
> > > > Yes. PCI Firmware Spec r3.0, Table 4-2, note 2 says address ranges
> > > > reported via MCFG or _CBA should be reserved by _CRS of a PNP0C02
> > > > device.
> > >
> > > Ok, that's agreed. It goes without saying that since you are quoting
> > > the PCI spec, if FW fails to report MCFG regions in a PNP0c02 device
> > > _CRS I will consider that a FW bug.
> > >
> > > > > IIUC PNP0C02 is a reservation mechanism, but it does not help us
> > > > > associate its _CRS to a specific PCI host bridge instance, right ?
> > > >
> > > > Gab proposed a hierarchy that *would* associate a PNP0C02 device with
> > > > a PCI bridge:
> > > >
> > > > Device (PCI1) {
> > > > Name (_HID, "HISI0080") // PCI Express Root Bridge
> > > > Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
> > > > Method (_CRS, 0, Serialized) { // Root complex resources
> > > (windows) }
> > > > Device (RES0) {
> > > > Name (_HID, "HISI0081") // HiSi PCIe RC config base address
> > > > Name (_CID, "PNP0C02") // Motherboard reserved resource
> > > > Name (_CRS, ResourceTemplate () { ... }
> > > > }
> > > > }
> > > >
> > > > That's a possibility. The PCI Firmware Spec suggests putting RES0 at
> > > > the root (under \_SB), but I don't know why.
> > > >
> > > > Putting it at the root means we couldn't generically associate it
> > > with
> > > > a bridge, although I could imagine something like this:
> > > >
> > > > Device (RES1) {
> > > > Name (_HID, "HISI0081") // HiSi PCIe RC config base address
> > > > Name (_CID, "PNP0C02") // Motherboard reserved resource
> > > > Name (_CRS, ResourceTemplate () { ... }
> > > > Method (BRDG) { "PCI1" } // hand-wavy ASL
> > > > }
> > > > Device (PCI1) {
> > > > Name (_HID, "HISI0080") // PCI Express Root Bridge
> > > > Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
> > > > Method (_CRS, 0, Serialized) { // Root complex resources
> > > (windows) }
> > > > }
> > > >
> > > > Where you could search PNP0C02 devices for a cookie that matched the
> > > > host bridge.o
> > >
> > > Ok, I am fine with both and I think we are converging, but the way
> > > to solve this problem has to be uniform for all ARM partners (and
> > > not only ARM). Two points here:
> > >
> > > 1) Adding a device/subdevice allows people to add a _CRS reporting the
> > > non-window bridge resources. Fine. It also allows people to chuck in
> > > there all sorts of _DSD properties to describe their PCI host bridge
> > > as it is done with DT properties (those _DSD can contain eg clocks
> > > etc.), this may be tempting (so that they can reuse the same DT
> > > driver and do not have to update their firmware) but I want to be
> > > clear here: that must not happen. So, a subdevice with a _CRS to
> > > report resources, yes, but it will stop there.
> > > 2) It is unclear to me how to formalize the above. People should not
> > > write FW by reading the PCI mailing list, so these guidelines have
> > > to
> > > be written, somehow. I do not want to standardize quirks, I want
> > > to prevent random ACPI table content, which is different.
> > > Should I report this to the ACPI spec working group ? If we do
> > > not do that everyone will go solve this problem as they deem fit.
> > >
> >
> > Do we really need to formalize this?
> >
> > As we discussed in the Linaro call at the moment we have few vendors
> > that need quirks and we want to avoid promoting/accepting quirks for
> > the future.
> >
> > At the time of the call I think we decided to informally accept a set
> > of quirks for the current platforms and reject any other quirk coming
> > after a certain date/kernel version (this to be decided).
> >
> > I am not sure if there is a way to document/formalize a temporary
> > exception from the rule...
>
> - (1) will be enforced.
I'm not sure it's necessary or possible to enforce a "no future
quirks" rule. For one thing, there's already a pretty strong
incentive to avoid quirks: if your hardware doesn't require quirks,
it works with OSes already in the field.
MCFG quirks allow us to use the generic ACPI pci_root.c driver even if
the hardware doesn't support ECAM quite according to the spec.
PNP0C02 usage is a workaround for the failure of the Consumer/Producer
bit. PNP0C02 quirks compensate for firmware that doesn't describe
resource usage accurately. It's possible the ACPI spec folks could
come up with a better Consumer/Producer workaround, if that's needed.
Apparently x86 hasn't needed it yet.
If people add _DSD methods for clocks or whatnot, the hardware won't
work with the generic pci_root.c driver, so there's already an
incentive for avoiding them. x86 has managed without such methods;
arm64 should be able to do the same.
> - We do not know whether PNP0c02 can be used in non-root devices _CRS
> - Are we sure (given that we are implementing this to make sure we are
> able to validate resources) that it is valid to have a subdevice with
> a _CRS whose resources are not contained in its parent _CRS address
> space (because that's exactly the case for these quirks) ?
>
> That's what I mean by formalizing, I want to know how PNP0c02 should
> be used. We all want platforms with quirks to be enabled asap but only
> if we stick to the ACPI specifications. On top of that, with the
> bindings above, the kernel would end up creating a platform device for
> the "fake" device with a _CRS approach, which is questionable.
> > > [...]
> > >
> > > > > For FW that is immutable I really do not see what we can do apart
> > > > > from hardcoding the non-config resources (consumed by a bridge),
> > > > > somehow.
> > > >
> > > > Right. Well, I assume you mean we should hard-code "non-window
> > > > resources consumed directly by a bridge". If firmware in the field
> > > is
> > > > broken, we should work around it, and that may mean hard-coding some
> > > > resources.
> > > >
> > > > My point is that the hard-coding should not be buried in a driver
> > > > where it's invisible to the rest of the kernel. If we hard-code it
> > > in
> > > > a quirk that adds _CRS entries, then the kernel will work just like
> > > it
> > > > would if the firmware had been correct in the first place. The
> > > > resource will appear in /sys/devices/pnp*/*/resources and
> > > /proc/iomem,
> > > > and if we ever used _SRS to assign or move ACPI devices, we would
> > > know
> > > > to avoid the bridge resource.
> > >
> > > We are in complete agreement here.
> > >
> > > Thanks,
> > > Lorenzo
> >
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Boris Brezillon @ 2016-09-22 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922164752.GP7994@sirena.org.uk>
On Thu, 22 Sep 2016 17:47:52 +0100
Mark Brown <broonie@kernel.org> wrote:
> On Thu, Sep 22, 2016 at 05:12:17PM +0200, Boris Brezillon wrote:
> > +Mark
>
> > I realize Mark has been out of the discussion, and what started as a DT
> > problem actually turned into a PWM regulator discussion.
> > Maybe we should start a new thread.
>
> Probably, you're lucky I even looked at this - the number of irrelevant
> patches I get CCed on is such that I'll often delete things that look
> irrelevant unread. I'm unsure what the relevance is, it looks like it's
> mainly a discussion about pinctrl?
Not exactly, even if this involves pin muxing.
>
> > As I said, the problem you're describing (pins muxed to the PWM device
> > when it should actually stay in gpio+input mode) is not new, and the old
> > pwm-regulator and pwm-rockchip implementation (before my atomic PWM
> > changes) were behaving the same way.
>
> Why would this make any kind of sense?
>
> > What is new though, is the pwm_regulator_init_state() function [1], and
> > it seems it's now preventing the probe of a pwm-regulator device if the
> > initial PWM state is not described in the voltage-table.
>
> > The question is, what should we do?
>
> > 1/ Force users to put an entry matching this state (which means
> > breaking DT compat)
> > 2/ Put a valid value in drvdata->state even if it's not reflecting the
> > real state
> > 3/ Patch regulator core to support an "unknown-selector" return code.
>
> Could someone say what the actual problem was please?
Well, to sum-up, the discussion started because Andy notice that some
boards were no longer booting, and found out that commit 87248991a1de
("regulator: pwm: Properly initialize the ->state field") was causing
the regression, because ->get_voltage_sel() was returning -EINVAL,
which in turn was caused by a missing entry in the voltage table.
Doug also noted that Andy was expecting the pin connected to the PWM
regulator to stay in a GPIO+input state until the PWM is really
enabled, in order to avoid glitches. But this not the case currently,
since the PWM chip claims all the pins at probe time.
So, there are 2 different problems here:
1/ the board no longer boots because of commit 87248991a1de and a
missing entry in the voltage table
2/ claiming the PWM pins at probe time can cause glitches
I'm currently trying to solve #1, but most of the discussion in this
thread was about addressing #2.
> That was a very
> long e-mail so I might be missing something but the obvious thing seems
> to be to force a state since we'll be doing that when we enable anyway.
Hm, okay, but which state should we choose? The first entry in the
voltage-table?
> Or just not have the voltage table and use it as a continuous regulator.
Yes, but that means patching the DT, which means breaking the DT compat.
^ permalink raw reply
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Tony Lindgren @ 2016-09-22 18:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Looks like commit 7a17e47f6403 ("mfd: twl6040: The chip does not
support bulk access") breaks at least omap4-duovero. I now get
tons of errors:
Skipping twl internal clock init and using bootloader value (unknown osc rate)
twl 0-0048: PIH (irq 332) nested IRQs
of_get_named_gpiod_flags: parsed 'ti,audpwron-gpio' property of node '/ocp/i2c at 48070000/t
wl at 4b[0]' - status (0)
omap_i2c 48070000.i2c: bus 0 rev0.10 at 400 kHz
twl6040 0-004b: Failed to read IRQ status: -16
twl6040 0-004b: Failed to read IRQ status: -16
twl6040 0-004b: Failed to read IRQ status: -16
twl6040 0-004b: Failed to read IRQ status: -16
twl6040 0-004b: Failed to read IRQ status: -16
twl6040 0-004b: Failed to read IRQ status: -16
twl6040 0-004b: Failed to read IRQ status: -16
twl6040 0-004b: Failed to read IRQ status: -16
twl6040 0-004b: Failed to read IRQ status: -16
It seems the regmap irqs don't work with use_single_rw?
Also seems that twl6040 does support bulk access as things have been
working earlier?
Anyways, can you please revert?
Regards,
Tony
^ permalink raw reply
* [PATCH 0/2] Fix warnings for i2c-rk3x.c
From: Wolfram Sang @ 2016-09-22 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474543764-51135-1-git-send-email-david.wu@rock-chips.com>
On Thu, Sep 22, 2016 at 07:29:22PM +0800, David Wu wrote:
> David Wu (2):
> i2c: rk3x: Fix sparse warning
> i2c: rk3x: fix variable 'min_total_ns' unused warning
>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160922/95673b3a/attachment.sig>
^ 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