* [PATCH v6 7/7] powerpc/perf/hv-24x7: Document sysfs event description entries
From: Sukadev Bhattiprolu @ 2014-12-22 7:48 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa, Michael Ellerman,
Paul Mackerras
Cc: peterz, linuxppc-dev, dev, linux-kernel
In-Reply-To: <1419234532-22657-1-git-send-email-sukadev@linux.vnet.ibm.com>
From: Cody P Schafer <cody@linux.vnet.ibm.com>
Changelog[v6]
[Cody Schafer] Update Contact info to Linux on Power Developer list
CC: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
CC: Haren Myneni <hbabu@us.ibm.com>
CC: Cody P Schafer <dev@codyps.com>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
.../testing/sysfs-bus-event_source-devices-hv_24x7 | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
index 32f3f5f..f893337 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
@@ -21,3 +21,25 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Exposes the "version" field of the 24x7 catalog. This is also
extractable from the provided binary "catalog" sysfs entry.
+
+What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
+Date: February 2014
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description:
+ Provides the description of a particular event as provided by
+ the firmware. If firmware does not provide a description, no
+ file will be created.
+
+ Note that the event-name lacks the domain suffix appended for
+ events in the events/ dir.
+
+What: /sys/bus/event_source/devices/hv_24x7/event_long_descs/<event-name>
+Date: February 2014
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description:
+ Provides the "long" description of a particular event as
+ provided by the firmware. If firmware does not provide a
+ description, no file will be created.
+
+ Note that the event-name lacks the domain suffix appended for
+ events in the events/ dir.
--
1.8.3.1
^ permalink raw reply related
* [PATCH v6 6/7] powerpc/perf/hv-gpci: add the remaining gpci requests
From: Sukadev Bhattiprolu @ 2014-12-22 7:48 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa, Michael Ellerman,
Paul Mackerras
Cc: peterz, linuxppc-dev, dev, linux-kernel
In-Reply-To: <1419234532-22657-1-git-send-email-sukadev@linux.vnet.ibm.com>
From: Cody P Schafer <cody@linux.vnet.ibm.com>
Add the remaining gpci requests that contain counters suitable for use
by perf. Omit those that don't contain any counters (but note their
ommision).
Changelog[v6]
[Jiri Olsa, Sukadev Bhattiprolu] Replace 'starting_index' with what
it really means for the event. Eg if starting_index refers to a
partition_id for an event, allow user to specify a value for
partition_id rather than 'starting_index'. Also use a =? to indicate
required parameters: eg partition_id=?
CC: Haren Myneni <hbabu@us.ibm.com>
CC: Cody P Schafer <dev@codyps.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
arch/powerpc/perf/hv-gpci-requests.h | 187 ++++++++++++++++++++++++++++++++++-
1 file changed, 186 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/hv-gpci-requests.h b/arch/powerpc/perf/hv-gpci-requests.h
index f42d131..1345835 100644
--- a/arch/powerpc/perf/hv-gpci-requests.h
+++ b/arch/powerpc/perf/hv-gpci-requests.h
@@ -20,7 +20,9 @@
*
* - starting_index_kind is one of the following, depending on the event:
*
- * chip_id: hardware chip id or -1 for current hw chip
+ * hw_chip_id: hardware chip id or -1 for current hw chip
+ * partition_id
+ * sibling_part_id,
* phys_processor_idx:
* 0xffffffffffffffff: or -1, which means it is irrelavant for the event
*
@@ -63,6 +65,33 @@ REQUEST(__count(0, 8, processor_time_in_timebase_cycles)
)
#include I(REQUEST_END)
+#define REQUEST_NAME entitled_capped_uncapped_donated_idle_timebase_by_partition
+#define REQUEST_NUM 0x20
+#define REQUEST_IDX_KIND "sibling_part_id=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 8, partition_id)
+ __count(0x8, 8, entitled_cycles)
+ __count(0x10, 8, consumed_capped_cycles)
+ __count(0x18, 8, consumed_uncapped_cycles)
+ __count(0x20, 8, cycles_donated)
+ __count(0x28, 8, purr_idle_cycles)
+)
+#include I(REQUEST_END)
+
+/*
+ * Not available for counter_info_version >= 0x8, use
+ * run_instruction_cycles_by_partition(0x100) instead.
+ */
+#define REQUEST_NAME run_instructions_run_cycles_by_partition
+#define REQUEST_NUM 0x30
+#define REQUEST_IDX_KIND "sibling_part_id=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 8, partition_id)
+ __count(0x8, 8, instructions_completed)
+ __count(0x10, 8, cycles)
+)
+#include I(REQUEST_END)
+
#define REQUEST_NAME system_performance_capabilities
#define REQUEST_NUM 0x40
#define REQUEST_IDX_KIND "starting_index=0xffffffffffffffff"
@@ -73,4 +102,160 @@ REQUEST(__field(0, 1, perf_collect_privileged)
)
#include I(REQUEST_END)
+#define REQUEST_NAME processor_bus_utilization_abc_links
+#define REQUEST_NUM 0x50
+#define REQUEST_IDX_KIND "hw_chip_id=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 4, hw_chip_id)
+ __array(0x4, 0xC, reserved1)
+ __count(0x10, 8, total_link_cycles)
+ __count(0x18, 8, idle_cycles_for_a_link)
+ __count(0x20, 8, idle_cycles_for_b_link)
+ __count(0x28, 8, idle_cycles_for_c_link)
+ __array(0x30, 0x20, reserved2)
+)
+#include I(REQUEST_END)
+
+#define REQUEST_NAME processor_bus_utilization_wxyz_links
+#define REQUEST_NUM 0x60
+#define REQUEST_IDX_KIND "hw_chip_id=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 4, hw_chip_id)
+ __array(0x4, 0xC, reserved1)
+ __count(0x10, 8, total_link_cycles)
+ __count(0x18, 8, idle_cycles_for_w_link)
+ __count(0x20, 8, idle_cycles_for_x_link)
+ __count(0x28, 8, idle_cycles_for_y_link)
+ __count(0x30, 8, idle_cycles_for_z_link)
+ __array(0x38, 0x28, reserved2)
+)
+#include I(REQUEST_END)
+
+#define REQUEST_NAME processor_bus_utilization_gx_links
+#define REQUEST_NUM 0x70
+#define REQUEST_IDX_KIND "hw_chip_id=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 4, hw_chip_id)
+ __array(0x4, 0xC, reserved1)
+ __count(0x10, 8, gx0_in_address_cycles)
+ __count(0x18, 8, gx0_in_data_cycles)
+ __count(0x20, 8, gx0_in_retries)
+ __count(0x28, 8, gx0_in_bus_cycles)
+ __count(0x30, 8, gx0_in_cycles_total)
+ __count(0x38, 8, gx0_out_address_cycles)
+ __count(0x40, 8, gx0_out_data_cycles)
+ __count(0x48, 8, gx0_out_retries)
+ __count(0x50, 8, gx0_out_bus_cycles)
+ __count(0x58, 8, gx0_out_cycles_total)
+ __count(0x60, 8, gx1_in_address_cycles)
+ __count(0x68, 8, gx1_in_data_cycles)
+ __count(0x70, 8, gx1_in_retries)
+ __count(0x78, 8, gx1_in_bus_cycles)
+ __count(0x80, 8, gx1_in_cycles_total)
+ __count(0x88, 8, gx1_out_address_cycles)
+ __count(0x90, 8, gx1_out_data_cycles)
+ __count(0x98, 8, gx1_out_retries)
+ __count(0xA0, 8, gx1_out_bus_cycles)
+ __count(0xA8, 8, gx1_out_cycles_total)
+)
+#include I(REQUEST_END)
+
+#define REQUEST_NAME processor_bus_utilization_mc_links
+#define REQUEST_NUM 0x80
+#define REQUEST_IDX_KIND "hw_chip_id=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 4, hw_chip_id)
+ __array(0x4, 0xC, reserved1)
+ __count(0x10, 8, mc0_frames)
+ __count(0x18, 8, mc0_reads)
+ __count(0x20, 8, mc0_write)
+ __count(0x28, 8, mc0_total_cycles)
+ __count(0x30, 8, mc1_frames)
+ __count(0x38, 8, mc1_reads)
+ __count(0x40, 8, mc1_writes)
+ __count(0x48, 8, mc1_total_cycles)
+)
+#include I(REQUEST_END)
+
+/* Processor_config (0x90) skipped, no counters */
+/* Current_processor_frequency (0x91) skipped, no counters */
+
+#define REQUEST_NAME processor_core_utilization
+#define REQUEST_NUM 0x94
+#define REQUEST_IDX_KIND "phys_processor_idx=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 4, phys_processor_idx)
+ __field(0x4, 4, hw_processor_id)
+ __count(0x8, 8, cycles_across_any_thread)
+ __count(0x10, 8, timebase_at_collection)
+ __count(0x18, 8, purr_cycles)
+ __count(0x20, 8, sum_of_cycles_across_all_threads)
+ __count(0x28, 8, instructions_completed)
+)
+#include I(REQUEST_END)
+
+/* Processor_core_power_mode (0x95) skipped, no counters */
+/* Affinity_domain_information_by_virtual_processor (0xA0) skipped,
+ * no counters */
+/* Affinity_domain_information_by_domain (0xB0) skipped, no counters */
+/* Affinity_domain_information_by_partition (0xB1) skipped, no counters */
+/* Physical_memory_info (0xC0) skipped, no counters */
+/* Processor_bus_topology (0xD0) skipped, no counters */
+
+#define REQUEST_NAME partition_hypervisor_queuing_times
+#define REQUEST_NUM 0xE0
+#define REQUEST_IDX_KIND "partition_id=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 2, partition_id)
+ __array(0x2, 6, reserved1)
+ __count(0x8, 8, time_waiting_for_entitlement)
+ __count(0x10, 8, times_waited_for_entitlement)
+ __count(0x18, 8, time_waiting_for_phys_processor)
+ __count(0x20, 8, times_waited_for_phys_processor)
+ __count(0x28, 8, dispatches_on_home_core)
+ __count(0x30, 8, dispatches_on_home_primary_affinity_domain)
+ __count(0x38, 8, dispatches_on_home_secondary_affinity_domain)
+ __count(0x40, 8, dispatches_off_home_secondary_affinity_domain)
+ __count(0x48, 8, dispatches_on_dedicated_processor_donating_cycles)
+)
+#include I(REQUEST_END)
+
+#define REQUEST_NAME system_hypervisor_times
+#define REQUEST_NUM 0xF0
+#define REQUEST_IDX_KIND "starting_index=0xffffffffffffffff"
+#include I(REQUEST_BEGIN)
+REQUEST(__count(0, 8, time_spent_to_dispatch_virtual_processors)
+ __count(0x8, 8, time_spent_processing_virtual_processor_timers)
+ __count(0x10, 8, time_spent_managing_partitions_over_entitlement)
+ __count(0x18, 8, time_spent_on_system_management)
+)
+#include I(REQUEST_END)
+
+#define REQUEST_NAME system_tlbie_count_and_time
+#define REQUEST_NUM 0xF4
+#define REQUEST_IDX_KIND "starting_index=0xffffffffffffffff"
+#include I(REQUEST_BEGIN)
+REQUEST(__count(0, 8, tlbie_instructions_issued)
+ /*
+ * FIXME: The spec says the offset here is 0x10, which I suspect
+ * is wrong.
+ */
+ __count(0x8, 8, time_spent_issuing_tlbies)
+)
+#include I(REQUEST_END)
+
+#define REQUEST_NAME partition_instruction_count_and_time
+#define REQUEST_NUM 0x100
+#define REQUEST_IDX_KIND "partition_id=?"
+#include I(REQUEST_BEGIN)
+REQUEST(__field(0, 2, partition_id)
+ __array(0x2, 0x6, reserved1)
+ __count(0x8, 8, instructions_performed)
+ __count(0x10, 8, time_collected)
+)
+#include I(REQUEST_END)
+
+/* set_mmcrh (0x80001000) skipped, no counters */
+/* retrieve_hpmcx (0x80002000) skipped, no counters */
+
#include "req-gen/_end.h"
--
1.8.3.1
^ permalink raw reply related
* [PATCH v6 0/4] Add support for parametrized events
From: Sukadev Bhattiprolu @ 2014-12-22 7:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa, Michael Ellerman,
Paul Mackerras
Cc: peterz, linuxppc-dev, dev, linux-kernel
Description of "event parameters" from the documentation patch:
Event parameters are a basic way for partial events to be specified in
sysfs with per-event names given to the fields that need to be filled in
when using a particular event.
It is intended for supporting cases where the single 'cpu' parameter is
insufficient. For example, POWER 8 has events for physical
sockets/cores/cpus that are accessible from with virtual machines. To
keep using the single 'cpu' parameter we'd need to perform a mapping
between Linux's cpus and the physical machine's cpus (in this case
Linux is running under a hypervisor). This isn't possible because
bindings between our cpus and physical cpus may not be fixed, and we
probably won't have a "cpu" on each physical cpu.
Description of the sysfs contents when events are parameterized (copied from an
included patch):
Examples:
domain=0x1,offset=0x8,core=?
In the case of the last example, a value replacing "?" would need
to be provided by the user selecting the particular event. This is
refered to as "event parameterization". All non-numerical values
indicate an event parameter.
Notes on how perf-list displays parameterized events
PARAMETERIZED EVENTS
--------------------
Some pmu events listed by 'perf list' will be displayed with '$xyz' in
them. For example:
hv_24x7/HPM_THREAD_NAP_CCYC__PHYS_CORE,core=?/
This means that when provided as an event, a value for ? must also
be supplied. For example:
perf stat -e \
'hv_24x7/HPM_THREAD_NAP_CCYC__PHYS_CORE,core=2' ...
Changelog[v6]
[Jiri Olsa, Sukadev Bhattiprolu] Rather than display
'starting_index=$core' in perf.list and sysfs and expect user to
specify a value for 'starting_index', replace 'starting_index' with
what it really means for the event. i.e for an event, if starting_index
refers to 'core' then display 'core=?' in both perf list and sysfs (see
examples above).
Changelog[v5]
- [Jiri Olsa, Peter Zijlstra] Use '$arg' notation rather than ?
to indicate event parameters.
- [Michael Ellerman] Separate the kernel and tool patches in the
patchset into different patchsets.
Changelog[v4]
- [Jiri Olsa] Rebase to perf/core tree (fix small merge conflict)
Changelog[v3]
- [Jiri Olsa] Changed the event parameters are specified. If
event file specifes 'param=val' make the usage 'param=123'
rather than 'val=123'. (patch 1,2/10)
- Shortened event names using "PHYS" and "VCPU" (patch 4/10)
- Print help message if invalid parameter is specified or required
parameter is missing.
- Moved 3 patches that are unrelated to parametrized events into
a separate patchset.
- Reordered patches so code changes come first.
Changelog[v2]
- [Joe Perches, David Laight] Use beNN_to_cpu() instead of guessing
the size from type.
- Use kmem_cache_free() to free page allocated with kmem_cache_alloc().
- Rebase to recent kernel
Cody P Schafer (4):
tools/perf: support parsing parameterized events
tools/perf: extend format_alias() to include event parameters
perf Documentation: add event parameters
tools/perf: Document parameterized and symbolic events
.../testing/sysfs-bus-event_source-devices-events | 6 ++
tools/perf/Documentation/perf-list.txt | 13 +++
tools/perf/Documentation/perf-record.txt | 12 +++
tools/perf/Documentation/perf-stat.txt | 20 ++++-
tools/perf/util/parse-events.h | 1 +
tools/perf/util/pmu.c | 92 +++++++++++++++++++---
6 files changed, 128 insertions(+), 16 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH v6 1/4] tools/perf: support parsing parameterized events
From: Sukadev Bhattiprolu @ 2014-12-22 7:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa, Michael Ellerman,
Paul Mackerras
Cc: peterz, linuxppc-dev, dev, linux-kernel
In-Reply-To: <1419234567-22784-1-git-send-email-sukadev@linux.vnet.ibm.com>
From: Cody P Schafer <cody@linux.vnet.ibm.com>
Enable event specification like:
pmu/event_name,param1=0x1,param2=0x4/
Assuming that
/sys/bus/event_source/devices/pmu/events/event_name
Contains something like
param2=?,bar=1,param1=?
Changelog[v4]:
[Jiri Olsa] Merge to recent perf-core and fix a small conflict.
Changelog[v3]:
[Jiri Olsa] If the sysfs event file specifies 'param=val', make the
usage 'hv_24x7/event,param=123/' rather than 'hv_24x7/event,val=123/'.
CC: Haren Myneni <hbabu@us.ibm.com>
CC: Cody P Schafer <dev@codyps.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
tools/perf/util/parse-events.h | 1 +
tools/perf/util/pmu.c | 65 +++++++++++++++++++++++++++++++++++-------
2 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index db2cf78..ca226ce 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -71,6 +71,7 @@ struct parse_events_term {
int type_val;
int type_term;
struct list_head list;
+ bool used;
};
struct parse_events_evlist {
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 5c9c494..cb516dd 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -551,31 +551,68 @@ static void pmu_format_value(unsigned long *format, __u64 value, __u64 *v,
}
/*
+ * Term is a string term, and might be a param-term. Try to look up it's value
+ * in the remaining terms.
+ * - We have a term like "base-or-format-term=param-term",
+ * - We need to find the value supplied for "param-term" (with param-term named
+ * in a config string) later on in the term list.
+ */
+static int pmu_resolve_param_term(struct parse_events_term *term,
+ struct list_head *head_terms,
+ __u64 *value)
+{
+ struct parse_events_term *t;
+
+ list_for_each_entry(t, head_terms, list) {
+ if (t->type_val == PARSE_EVENTS__TERM_TYPE_NUM) {
+ if (!strcmp(t->config, term->config)) {
+ t->used = true;
+ *value = t->val.num;
+ return 0;
+ }
+ }
+ }
+
+ if (verbose)
+ printf("Required parameter '%s' not specified\n", term->config);
+
+ return -1;
+}
+
+/*
* Setup one of config[12] attr members based on the
* user input data - term parameter.
*/
static int pmu_config_term(struct list_head *formats,
struct perf_event_attr *attr,
struct parse_events_term *term,
+ struct list_head *head_terms,
bool zero)
{
struct perf_pmu_format *format;
__u64 *vp;
+ __u64 val;
+
+ /*
+ * If this is a parameter we've already used for parameterized-eval,
+ * skip it in normal eval.
+ */
+ if (term->used)
+ return 0;
/*
- * Support only for hardcoded and numnerial terms.
* Hardcoded terms should be already in, so nothing
* to be done for them.
*/
if (parse_events__is_hardcoded_term(term))
return 0;
- if (term->type_val != PARSE_EVENTS__TERM_TYPE_NUM)
- return -EINVAL;
-
format = pmu_find_format(formats, term->config);
- if (!format)
+ if (!format) {
+ if (verbose)
+ printf("Invalid event/parameter '%s'\n", term->config);
return -EINVAL;
+ }
switch (format->value) {
case PERF_PMU_FORMAT_VALUE_CONFIG:
@@ -592,11 +629,16 @@ static int pmu_config_term(struct list_head *formats,
}
/*
- * XXX If we ever decide to go with string values for
- * non-hardcoded terms, here's the place to translate
- * them into value.
+ * Either directly use a numeric term, or try to translate string terms
+ * using event parameters.
*/
- pmu_format_value(format->bits, term->val.num, vp, zero);
+ if (term->type_val == PARSE_EVENTS__TERM_TYPE_NUM)
+ val = term->val.num;
+ else
+ if (pmu_resolve_param_term(term, head_terms, &val))
+ return -EINVAL;
+
+ pmu_format_value(format->bits, val, vp, zero);
return 0;
}
@@ -607,9 +649,10 @@ int perf_pmu__config_terms(struct list_head *formats,
{
struct parse_events_term *term;
- list_for_each_entry(term, head_terms, list)
- if (pmu_config_term(formats, attr, term, zero))
+ list_for_each_entry(term, head_terms, list) {
+ if (pmu_config_term(formats, attr, term, head_terms, zero))
return -EINVAL;
+ }
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v6 2/4] tools/perf: extend format_alias() to include event parameters
From: Sukadev Bhattiprolu @ 2014-12-22 7:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa, Michael Ellerman,
Paul Mackerras
Cc: peterz, linuxppc-dev, dev, linux-kernel
In-Reply-To: <1419234567-22784-1-git-send-email-sukadev@linux.vnet.ibm.com>
From: Cody P Schafer <cody@linux.vnet.ibm.com>
This causes `perf list pmu` to show parameters for parameterized events
like:
pmu/event_name,param1=?,param2=?/ [Kernel PMU event]
An example:
hv_24x7/HPM_TLBIE__PHYS_CORE,core=?/ [Kernel PMU event]
Changelog[v6]
[Jir Olsa, Sukadev Bhattiprolu] Drop the '$' sign and go back to
just printing whatevever sysfs provides (which is '=?') to identify
required parameters. sysfs also now uses parameters like 'core'
and 'vcpu' rather than 'starting_index'.
Changelog[v5]
[Jiri Olsa, Peter Zijlstra] Use '$' to prefix parameterized events.
Changelog[v4]
[Jiri Olsa] If the parameter for an event in sysfs is 'param=val',
have perf-list show the event as 'param=?' rather than 'val=?'.
CC: Haren Myneni <hbabu@us.ibm.com>
CC: Cody P Schafer <dev@codyps.com>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
tools/perf/util/pmu.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index cb516dd..d208fef 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -810,10 +810,35 @@ void perf_pmu__set_format(unsigned long *bits, long from, long to)
set_bit(b, bits);
}
+static int sub_non_neg(int a, int b)
+{
+ if (b > a)
+ return 0;
+ return a - b;
+}
+
static char *format_alias(char *buf, int len, struct perf_pmu *pmu,
struct perf_pmu_alias *alias)
{
- snprintf(buf, len, "%s/%s/", pmu->name, alias->name);
+ struct parse_events_term *term;
+ int used = snprintf(buf, len, "%s/%s", pmu->name, alias->name);
+
+ list_for_each_entry(term, &alias->terms, list)
+ if (term->type_val == PARSE_EVENTS__TERM_TYPE_STR)
+ used += snprintf(buf + used, sub_non_neg(len, used),
+ ",%s=%s", term->config,
+ term->val.str);
+
+ if (sub_non_neg(len, used) > 0) {
+ buf[used] = '/';
+ used++;
+ }
+ if (sub_non_neg(len, used) > 0) {
+ buf[used] = '\0';
+ used++;
+ } else
+ buf[len - 1] = '\0';
+
return buf;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v6 3/4] perf Documentation: add event parameters
From: Sukadev Bhattiprolu @ 2014-12-22 7:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa, Michael Ellerman,
Paul Mackerras
Cc: peterz, linuxppc-dev, dev, linux-kernel
In-Reply-To: <1419234567-22784-1-git-send-email-sukadev@linux.vnet.ibm.com>
From: Cody P Schafer <cody@linux.vnet.ibm.com>
Event parameters are a basic way for partial events to be specified in
sysfs with per-event names given to the fields that need to be filled in
when using a particular event.
It is intended for supporting cases where the single 'cpu' parameter is
insufficient. For example, POWER 8 has events for physical
sockets/cores/cpus that are accessible from with virtual machines. To
keep using the single 'cpu' parameter we'd need to perform a mapping
between Linux's cpus and the physical machine's cpus (in this case
Linux is running under a hypervisor). This isn't possible because
bindings between our cpus and physical cpus may not be fixed, and we
probably won't have a "cpu" on each physical cpu.
Changelog[v6]
Update event description to explain how required parameters
are displayed.
CC: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
CC: Haren Myneni <hbabu@us.ibm.com>
CC: Cody P Schafer <dev@codyps.com>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-event_source-devices-events | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 20979f8..47ad2a1 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -52,12 +52,18 @@ Description: Per-pmu performance monitoring events specific to the running syste
event=0x2abc
event=0x423,inv,cmask=0x3
domain=0x1,offset=0x8,starting_index=0xffff
+ domain=0x1,offset=0x8,core=?
Each of the assignments indicates a value to be assigned to a
particular set of bits (as defined by the format file
corresponding to the <term>) in the perf_event structure passed
to the perf_open syscall.
+ In the case of the last example, a value replacing "?" would
+ need to be provided by the user selecting the particular event.
+ This is referred to as "event parameterization". All
+ non-numerical values indicate an event parameter.
+
What: /sys/bus/event_source/devices/<pmu>/events/<event>.unit
Date: 2014/02/24
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
--
1.8.3.1
^ permalink raw reply related
* [PATCH v6 4/4] tools/perf: Document parameterized and symbolic events
From: Sukadev Bhattiprolu @ 2014-12-22 7:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa, Michael Ellerman,
Paul Mackerras
Cc: peterz, linuxppc-dev, dev, linux-kernel
In-Reply-To: <1419234567-22784-1-git-send-email-sukadev@linux.vnet.ibm.com>
From: Cody P Schafer <cody@linux.vnet.ibm.com>
Changelog[v6]:
- [Sukadev Bhattiprolu]: Update documentation of perf-list and
perf-record; Added documentation for perf-stat.
CC: Haren Myneni <hbabu@us.ibm.com>
CC: Cody P Schafer <dev@codyps.com>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
tools/perf/Documentation/perf-list.txt | 13 +++++++++++++
tools/perf/Documentation/perf-record.txt | 12 ++++++++++++
tools/perf/Documentation/perf-stat.txt | 20 ++++++++++++++++----
3 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt
index cbb4f74..d8be6fa 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -89,6 +89,19 @@ raw encoding of 0x1A8 can be used:
You should refer to the processor specific documentation for getting these
details. Some of them are referenced in the SEE ALSO section below.
+PARAMETERIZED EVENTS
+--------------------
+
+Some pmu events listed by 'perf-list' will be displayed with '$x' in them. For
+example:
+
+ hv_gpci/dtbp_ptitc,phys_processor_idx=?/
+
+This means that when provided as an event, a value for '?' must
+also be supplied. For example:
+
+ perf stat -C 0 -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ...
+
OPTIONS
-------
diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt
index af9a54e..acdcf3b 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -33,6 +33,18 @@ OPTIONS
- a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
hexadecimal event descriptor.
+ - a symbolically formed PMU event like 'pmu/param1=0x3,param2/' where
+ 'param1', 'param2', etc are defined as formats for the PMU in
+ /sys/bus/event_sources/devices/<pmu>/format/*.
+
+ - a symbolically formed event like 'pmu/config=M,config1=N,config3=K/'
+
+ where M, N, K are numbers (in decimal, hex, octal format). Acceptable
+ values for each of 'config', 'config1' and 'config2' are defined by
+ corresponding entries in /sys/bus/event_sources/devices/<pmu>/format/*
+ param1 and param2 are defined as formats for the PMU in:
+ /sys/bus/event_sources/devices/<pmu>/format/*
+
- a hardware breakpoint event in the form of '\mem:addr[:access]'
where addr is the address in memory you want to break in.
Access is the memory access type (read, write, execute) it can
diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt
index 29ee857..04e150d 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -25,10 +25,22 @@ OPTIONS
-e::
--event=::
- Select the PMU event. Selection can be a symbolic event name
- (use 'perf list' to list all events) or a raw PMU
- event (eventsel+umask) in the form of rNNN where NNN is a
- hexadecimal event descriptor.
+ Select the PMU event. Selection can be:
+
+ - a symbolic event name (use 'perf list' to list all events)
+
+ - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
+ hexadecimal event descriptor.
+
+ - a symbolically formed event like 'pmu/param1=0x3,param2/' where
+ param1 and param2 are defined as formats for the PMU in
+ /sys/bus/event_sources/devices/<pmu>/format/*
+
+ - a symbolically formed event like 'pmu/config=M,config1=N,config2=K/'
+ where M, N, K are numbers (in decimal, hex, octal format).
+ Acceptable values for each of 'config', 'config1' and 'config2'
+ parameters are defined by corresponding entries in
+ /sys/bus/event_sources/devices/<pmu>/format/*
-i::
--no-inherit::
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Scott Wood @ 2014-12-22 8:32 UTC (permalink / raw)
To: Emil Medve
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989, Liberman Igal-B31950
In-Reply-To: <5497D466.9090804@Freescale.com>
On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
> Hello Shao-Hui,
>
>
> On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
> >> On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
> >>>> -----Original Message-----
> >>>> From: Wood Scott-B07421
> >>>> Sent: Friday, December 19, 2014 6:01 AM
> >>>> To: Xie Shaohui-B21989
> >>>> Cc: linuxppc-dev@lists.ozlabs.org; devicetree@vger.kernel.org; Medve
> >>>> Emilian- EMMEDVE1; Liberman Igal-B31950
> >>>> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> >>>>
> >>>> On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
> >>>>> Ping.
> >>>>>
> >>>>> Best Regards,
> >>>>> Shaohui Xie
> >>>>
> >>>> I can't put patches in my -next until the merge window closes.
> >>>>
> >>>>>>>> +EXAMPLE
> >>>>>>>> +
> >>>>>>>> +Example for FMan v2 external MDIO:
> >>>>>>>> +
> >>>>>>>> +mdio@f1000 {
> >>>>>>>> + compatible = "fsl,fman-xmdio";
> >>>>>>>> + reg = <0xf1000 0x1000>;
> >>>>>>>> + bus-frequency = <20000>;
> >>>>>>>> +};
> >>>>>>>
> >>>>>>> So the bus frequency is only 20 KHz? Or is the unit supposed
> >>>>>>> to be something other than Hz?
> >>>>>> [S.H] it's only an example, it could be different on real SoCs,
> >>>>>> but they always lower than the standard one, The standard one is
> >>>>>> 2.5MHz, I have
> >>>> to use Hz for it.
> >>>>
> >>>> Is there any SoC for which 20 kHz is the right frequency? I just
> >>>> want to make sure the example is realistic.
> >>> [S.H] the clock divider has a limitation that the MAX value it can get
> >>> on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
> >>>
> >>> So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On Fman
> >>> v3 is: Fman_clock / ((2 * 511) + 1).
> >>>
> >>> Take default Fman frequency setting from SDK1.7 as example, the lowest
> >>> clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is 600MHz.
> >>>
> >>> Then the lowest bus frequency can get is:
> >>> Fman v2: ~1140KHz
> >>> Fman v3: ~587KHz
> >>>
> >>> 20KHz is not practice, we don't have a suggested value in errata document.
> >>> For this example, should I post a new version with a value like 1200KHz?
> >>
> >> This is different from how you described the problem before. If the limitation
> >> is on the divider, rather than the absolute bus frequency, then specifiy the max
> >> divider. Or better, since according to the above this correlates with fman
> >> version, just have the driver know what the max divider is for each fman version.
> > [S.H] The problem is not the divider has limitation, the problem is a different bus frequency
> > Is needed which is lower than the standard, but due to the divider limitation, the lowest
> > bus frequency also has limitation. i.e. we need to use the divider to get a lower frequency,
> > but how much lower the value could be is restricted by the divider limitation.
This is difficult to follow -- are you saying the erratum requires a
speed that is not achievable?
> For the purpose of an example in the binding document, I suggest we just
> stick with the IEEE standard frequency.
The whole reason for this property existing in the device tree is
non-standard frequencies.
> We can continue this conversation about errata handling when we submit
> the code relevant to this binding (and the FMan v3 support)
It affects the binding, so let's discuss it now please.
-Scott
^ permalink raw reply
* Re: Build regressions/improvements in v3.19-rc1
From: Geert Uytterhoeven @ 2014-12-22 8:42 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Miao Steven, linuxppc-dev@lists.ozlabs.org,
adi-buildroot-devel@lists.sourceforge.net, Cris, Linux-sh list
In-Reply-To: <1419237118-9712-1-git-send-email-geert@linux-m68k.org>
On Mon, Dec 22, 2014 at 9:31 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Below is the list of build error/warning regressions/improvements in
> v3.19-rc1[1] compared to v3.18[2].
>
> Summarized:
> - build errors: +24/-16
+ /home/kisskb/slave/src/arch/powerpc/xmon/xmon.c: error: unused
variable 'badaddr' [-Werror=unused-variable]: => 1185:13
+ /home/kisskb/slave/src/arch/powerpc/xmon/xmon.c: error: unused
variable 'mode' [-Werror=unused-variable]: => 1183:6
powerpc-randconfig
+ /home/kisskb/slave/src/arch/sh/boards/mach-se/7343/irq.c: error:
too few arguments to function 'ioread16': => 44:2
+ /home/kisskb/slave/src/arch/sh/boards/mach-se/7343/irq.c: error:
too few arguments to function 'iowrite16': => 123:2
sh4/se7343_defconfig
+ /home/kisskb/slave/src/arch/sh/boards/mach-se/7722/irq.c: error:
too few arguments to function 'ioread16': => 43:2
+ /home/kisskb/slave/src/arch/sh/boards/mach-se/7722/irq.c: error:
too few arguments to function 'iowrite16': => 116:2
sh4/se7722_defconfig
+ /home/kisskb/slave/src/drivers/usb/musb/blackfin.c: error:
'bfin_writel' undeclared here (not in a function): => 476:13
bfin/BF527-EZKIT-V2_defconfig
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_BABBLE_CTL' undeclared here (not in a function): => 67:17
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_CONFIGDATA' undeclared here (not in a function): => 62:18
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_EPINFO' undeclared here (not in a function): => 74:14
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_RAMINFO' undeclared here (not in a function): => 75:15
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_RXFIFOADD' undeclared here (not in a function): => 71:17
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_RXFIFOSZ' undeclared here (not in a function): => 69:16
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_TXFIFOADD' undeclared here (not in a function): => 70:17
+ /home/kisskb/slave/src/drivers/usb/musb/musb_debugfs.c: error:
'MUSB_TXFIFOSZ' undeclared here (not in a function): => 68:16
bfin/BF527-EZKIT_defconfig
bfin/BF527-EZKIT-V2_defconfig
bfin/BF548-EZKIT_defconfig
bfin/CM-BF548_defconfig
bfin/CM-BF527_defconfig
+ /home/kisskb/slave/src/include/linux/irq.h: error: conflicting
types for 'ioread16': => 856:19
+ /home/kisskb/slave/src/include/linux/irq.h: error: conflicting
types for 'iowrite16': => 847:20
sh4/se7343_defconfig
sh4/se7722_defconfig
+ error: "csum_partial_copy_nocheck" [net/ipv6/ipv6.ko] undefined!: => N/A
cris/cris-allmodconfig
+ error: No rule to make target include/config/auto.conf: => N/A
arm/arm-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/8241/ (262 out of 262 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/head/8168/ (262 out of 262 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Shaohui Xie @ 2014-12-22 8:56 UTC (permalink / raw)
To: Scott Wood, Emilian Medve
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Igal.Liberman@freescale.com
In-Reply-To: <1419237176.5581.159.camel@freescale.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBNb25kYXksIERlY2VtYmVyIDIyLCAyMDE0IDQ6MzMgUE0NCj4gVG86IE1lZHZlIEVt
aWxpYW4tRU1NRURWRTENCj4gQ2M6IFhpZSBTaGFvaHVpLUIyMTk4OTsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmc7DQo+IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBMaWJlcm1hbiBJ
Z2FsLUIzMTk1MA0KPiBTdWJqZWN0OiBSZTogW1BBVENIXSBbdjJdIHBvd2VyL2ZzbDogYWRkIE1E
SU8gZHQgYmluZGluZyBmb3IgRk1hbg0KPiANCj4gT24gTW9uLCAyMDE0LTEyLTIyIGF0IDAyOjIw
IC0wNjAwLCBFbWlsIE1lZHZlIHdyb3RlOg0KPiA+IEhlbGxvIFNoYW8tSHVpLA0KPiA+DQo+ID4N
Cj4gPiBPbiAxMi8yMS8yMDE0IDA4OjMxIFBNLCBYaWUgU2hhb2h1aS1CMjE5ODkgd3JvdGU6DQo+
ID4gPj4gT24gRnJpLCAyMDE0LTEyLTE5IGF0IDAxOjIzIC0wNjAwLCBYaWUgU2hhb2h1aS1CMjE5
ODkgd3JvdGU6DQo+ID4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+Pj4g
RnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+Pj4+IFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIg
MTksIDIwMTQgNjowMSBBTQ0KPiA+ID4+Pj4gVG86IFhpZSBTaGFvaHVpLUIyMTk4OQ0KPiA+ID4+
Pj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBkZXZpY2V0cmVlQHZnZXIua2Vy
bmVsLm9yZzsNCj4gPiA+Pj4+IE1lZHZlDQo+ID4gPj4+PiBFbWlsaWFuLSBFTU1FRFZFMTsgTGli
ZXJtYW4gSWdhbC1CMzE5NTANCj4gPiA+Pj4+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIFt2Ml0gcG93
ZXIvZnNsOiBhZGQgTURJTyBkdCBiaW5kaW5nIGZvciBGTWFuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4g
T24gVGh1LCAyMDE0LTEyLTE4IGF0IDA2OjUzIC0wNjAwLCBYaWUgU2hhb2h1aS1CMjE5ODkgd3Jv
dGU6DQo+ID4gPj4+Pj4gUGluZy4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IEJlc3QgUmVnYXJkcywN
Cj4gPiA+Pj4+PiBTaGFvaHVpIFhpZQ0KPiA+ID4+Pj4NCj4gPiA+Pj4+IEkgY2FuJ3QgcHV0IHBh
dGNoZXMgaW4gbXkgLW5leHQgdW50aWwgdGhlIG1lcmdlIHdpbmRvdyBjbG9zZXMuDQo+ID4gPj4+
Pg0KPiA+ID4+Pj4+Pj4+ICtFWEFNUExFDQo+ID4gPj4+Pj4+Pj4gKw0KPiA+ID4+Pj4+Pj4+ICtF
eGFtcGxlIGZvciBGTWFuIHYyIGV4dGVybmFsIE1ESU86DQo+ID4gPj4+Pj4+Pj4gKw0KPiA+ID4+
Pj4+Pj4+ICttZGlvQGYxMDAwIHsNCj4gPiA+Pj4+Pj4+PiArCWNvbXBhdGlibGUgPSAiZnNsLGZt
YW4teG1kaW8iOw0KPiA+ID4+Pj4+Pj4+ICsJcmVnID0gPDB4ZjEwMDAgMHgxMDAwPjsNCj4gPiA+
Pj4+Pj4+PiArCWJ1cy1mcmVxdWVuY3kgPSA8MjAwMDA+Ow0KPiA+ID4+Pj4+Pj4+ICt9Ow0KPiA+
ID4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+IFNvIHRoZSBidXMgZnJlcXVlbmN5IGlzIG9ubHkgMjAgS0h6
PyAgT3IgaXMgdGhlIHVuaXQgc3VwcG9zZWQNCj4gPiA+Pj4+Pj4+IHRvIGJlIHNvbWV0aGluZyBv
dGhlciB0aGFuIEh6Pw0KPiA+ID4+Pj4+PiBbUy5IXSBpdCdzIG9ubHkgYW4gZXhhbXBsZSwgaXQg
Y291bGQgYmUgZGlmZmVyZW50IG9uIHJlYWwgU29DcywNCj4gPiA+Pj4+Pj4gYnV0IHRoZXkgYWx3
YXlzIGxvd2VyIHRoYW4gdGhlIHN0YW5kYXJkIG9uZSwgVGhlIHN0YW5kYXJkIG9uZQ0KPiA+ID4+
Pj4+PiBpcyAyLjVNSHosIEkgaGF2ZQ0KPiA+ID4+Pj4gdG8gdXNlIEh6IGZvciBpdC4NCj4gPiA+
Pj4+DQo+ID4gPj4+PiBJcyB0aGVyZSBhbnkgU29DIGZvciB3aGljaCAyMCBrSHogaXMgdGhlIHJp
Z2h0IGZyZXF1ZW5jeT8gIEkganVzdA0KPiA+ID4+Pj4gd2FudCB0byBtYWtlIHN1cmUgdGhlIGV4
YW1wbGUgaXMgcmVhbGlzdGljLg0KPiA+ID4+PiBbUy5IXSB0aGUgY2xvY2sgZGl2aWRlciBoYXMg
YSBsaW1pdGF0aW9uIHRoYXQgdGhlIE1BWCB2YWx1ZSBpdCBjYW4NCj4gPiA+Pj4gZ2V0IG9uIEZt
YW4gdjIgaXMgMjU1ICgweGZmLCA4IGJpdHMpLCBPbiBGbWFuIHYzIGlzIDUxMSgweDFmZiwgOSBi
aXRzKS4NCj4gPiA+Pj4NCj4gPiA+Pj4gU28gdGhlIGxvd2VzdCBmcmVxdWVuY3kgb24gRm1hbiB2
MiBpczogRm1hbl9jbG9jayAvICgyICogMjU1KSwgT24NCj4gPiA+Pj4gRm1hbg0KPiA+ID4+PiB2
MyBpczogRm1hbl9jbG9jayAvICgoMiAqIDUxMSkgKyAxKS4NCj4gPiA+Pj4NCj4gPiA+Pj4gVGFr
ZSBkZWZhdWx0IEZtYW4gZnJlcXVlbmN5IHNldHRpbmcgZnJvbSBTREsxLjcgYXMgZXhhbXBsZSwg
dGhlDQo+ID4gPj4+IGxvd2VzdCBjbG9jayB1c2VkIGZvciBGbWFuIHYyIGlzIDU4MU1IeiwgVGhl
IGxvd2VzdCBjbG9jayBmb3IgRm1hbiB2MyBpcw0KPiA2MDBNSHouDQo+ID4gPj4+DQo+ID4gPj4+
IFRoZW4gdGhlIGxvd2VzdCBidXMgZnJlcXVlbmN5IGNhbiBnZXQgaXM6DQo+ID4gPj4+IEZtYW4g
djI6IH4xMTQwS0h6DQo+ID4gPj4+IEZtYW4gdjM6IH41ODdLSHoNCj4gPiA+Pj4NCj4gPiA+Pj4g
MjBLSHogaXMgbm90IHByYWN0aWNlLCB3ZSBkb24ndCBoYXZlIGEgc3VnZ2VzdGVkIHZhbHVlIGlu
IGVycmF0YSBkb2N1bWVudC4NCj4gPiA+Pj4gRm9yIHRoaXMgZXhhbXBsZSwgc2hvdWxkIEkgcG9z
dCBhIG5ldyB2ZXJzaW9uIHdpdGggYSB2YWx1ZSBsaWtlIDEyMDBLSHo/DQo+ID4gPj4NCj4gPiA+
PiBUaGlzIGlzIGRpZmZlcmVudCBmcm9tIGhvdyB5b3UgZGVzY3JpYmVkIHRoZSBwcm9ibGVtIGJl
Zm9yZS4gIElmDQo+ID4gPj4gdGhlIGxpbWl0YXRpb24gaXMgb24gdGhlIGRpdmlkZXIsIHJhdGhl
ciB0aGFuIHRoZSBhYnNvbHV0ZSBidXMNCj4gPiA+PiBmcmVxdWVuY3ksIHRoZW4gc3BlY2lmaXkg
dGhlIG1heCBkaXZpZGVyLiAgT3IgYmV0dGVyLCBzaW5jZQ0KPiA+ID4+IGFjY29yZGluZyB0byB0
aGUgYWJvdmUgdGhpcyBjb3JyZWxhdGVzIHdpdGggZm1hbiB2ZXJzaW9uLCBqdXN0IGhhdmUgdGhl
DQo+IGRyaXZlciBrbm93IHdoYXQgdGhlIG1heCBkaXZpZGVyIGlzIGZvciBlYWNoIGZtYW4gdmVy
c2lvbi4NCj4gPiA+IFtTLkhdIFRoZSBwcm9ibGVtIGlzIG5vdCB0aGUgZGl2aWRlciBoYXMgbGlt
aXRhdGlvbiwgdGhlIHByb2JsZW0gaXMNCj4gPiA+IGEgZGlmZmVyZW50IGJ1cyBmcmVxdWVuY3kg
SXMgbmVlZGVkIHdoaWNoIGlzIGxvd2VyIHRoYW4gdGhlDQo+ID4gPiBzdGFuZGFyZCwgYnV0IGR1
ZSB0byB0aGUgZGl2aWRlciBsaW1pdGF0aW9uLCB0aGUgbG93ZXN0IGJ1cw0KPiA+ID4gZnJlcXVl
bmN5IGFsc28gaGFzIGxpbWl0YXRpb24uIGkuZS4gd2UgbmVlZCB0byB1c2UgdGhlIGRpdmlkZXIg
dG8gZ2V0IGENCj4gbG93ZXIgZnJlcXVlbmN5LCBidXQgaG93IG11Y2ggbG93ZXIgdGhlIHZhbHVl
IGNvdWxkIGJlIGlzIHJlc3RyaWN0ZWQgYnkgdGhlDQo+IGRpdmlkZXIgbGltaXRhdGlvbi4NCj4g
DQo+IFRoaXMgaXMgZGlmZmljdWx0IHRvIGZvbGxvdyAtLSBhcmUgeW91IHNheWluZyB0aGUgZXJy
YXR1bSByZXF1aXJlcyBhIHNwZWVkIHRoYXQNCj4gaXMgbm90IGFjaGlldmFibGU/DQpbUy5IXSBU
aGUgZXJyYXRhIG9ubHkgc3RhdGVkIHRoYXQgaXQgbmVlZCB0byB1c2UgYSBsYXJnZXIgZGl2aWRl
ciB0byByZWR1Y2UgdGhlIGNsb2NrDQpGcmVxdWVuY3ksIGJ1dCBpdCBkaWQgbm90IHByb3ZpZGUg
YSBzdWdnZXN0ZWQgdmFsdWUsIHdoYXQgd2Uga25vdyBpcyBzaW5jZSB0aGUgZGl2aWRlcg0KSGFz
IGEgbGltaXRhdGlvbiwgdGhlbiBob3cgbXVjaCBsb3dlciB0aGUgY2xvY2sgZnJlcXVlbmN5IGNv
dWxkIGJlIHJlZHVjZWQgaGFzIGEgbGltaXRhdGlvbi4NCg0KVGhhbmtzIQ0KU2hhb2h1aQ0KPiAN
Cj4gPiBGb3IgdGhlIHB1cnBvc2Ugb2YgYW4gZXhhbXBsZSBpbiB0aGUgYmluZGluZyBkb2N1bWVu
dCwgSSBzdWdnZXN0IHdlDQo+ID4ganVzdCBzdGljayB3aXRoIHRoZSBJRUVFIHN0YW5kYXJkIGZy
ZXF1ZW5jeS4NCj4gDQo+IFRoZSB3aG9sZSByZWFzb24gZm9yIHRoaXMgcHJvcGVydHkgZXhpc3Rp
bmcgaW4gdGhlIGRldmljZSB0cmVlIGlzIG5vbi1zdGFuZGFyZA0KPiBmcmVxdWVuY2llcy4NCj4g
DQo+ID4gV2UgY2FuIGNvbnRpbnVlIHRoaXMgY29udmVyc2F0aW9uIGFib3V0IGVycmF0YSBoYW5k
bGluZyB3aGVuIHdlIHN1Ym1pdA0KPiA+IHRoZSBjb2RlIHJlbGV2YW50IHRvIHRoaXMgYmluZGlu
ZyAoYW5kIHRoZSBGTWFuIHYzIHN1cHBvcnQpDQo+IA0KPiBJdCBhZmZlY3RzIHRoZSBiaW5kaW5n
LCBzbyBsZXQncyBkaXNjdXNzIGl0IG5vdyBwbGVhc2UuDQo+IA0KPiAtU2NvdHQNCj4gDQoNCg==
^ permalink raw reply
* [PATCH] powerpc/smp: Fix Non-boot cpus cannot be bring up.
From: Dongsheng Wang @ 2014-12-22 6:38 UTC (permalink / raw)
To: benh, scottwood, anton; +Cc: linuxppc-dev, Wang Dongsheng
From: Wang Dongsheng <dongsheng.wang@freescale.com>
Kernel cannot bring up Non-boot cpus always get "Processor xx is stuck".
this issue bring by http://patchwork.ozlabs.org/patch/418912/ (powerpc:
Secondary CPUs must set cpu_callin_map after setting active and online)
We need to take timebase after bootup cpu give the timebase firstly.
When start_secondary, non-boot cpus set cpu_callin_map for boot cpu
after that boot cpu will give the timebase for non-boot cpu. Otherwise
non-boot cpus will fall in dead loop to waiting bootup cpu to give
imebase.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 8ec017c..9e29836 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -703,10 +703,6 @@ void start_secondary(void *unused)
if (smp_ops->setup_cpu)
smp_ops->setup_cpu(cpu);
- if (smp_ops->take_timebase)
- smp_ops->take_timebase();
-
- secondary_cpu_time_init();
#ifdef CONFIG_PPC64
if (system_state == SYSTEM_RUNNING)
@@ -746,6 +742,16 @@ void start_secondary(void *unused)
smp_wmb();
cpu_callin_map[cpu] = 1;
+ /*
+ * We need to take timebase after bootup cpu give the timebase.
+ * Base on cpu_callin_map move to here, so we also need move
+ * take_timebase. Because bootup cpu waiting for cpu_callin_map
+ * be set after that give_timebase can be executed.
+ */
+ if (smp_ops->take_timebase)
+ smp_ops->take_timebase();
+ secondary_cpu_time_init();
+
local_irq_enable();
cpu_startup_entry(CPUHP_ONLINE);
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Scott Wood @ 2014-12-22 9:42 UTC (permalink / raw)
To: Emil Medve
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989, Liberman Igal-B31950
In-Reply-To: <5497E645.7010500@Freescale.com>
On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote:
> Hello Scott,
>
>
> On 12/22/2014 02:32 AM, Scott Wood wrote:
> > On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
> >> For the purpose of an example in the binding document, I suggest we just
> >> stick with the IEEE standard frequency.
> >
> > The whole reason for this property existing in the device tree is
> > non-standard frequencies.
>
> While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
> support frequencies well beyond the standard. Specifying a lower then
> the standard frequency for the benefit of some errata is just one side
> of this property
The erratum was (until now) the only claimed reason for it. If there
are other reasons why one would specify a different frequency (in
particular, that relate to hardware description), please elaborate.
> >> We can continue this conversation about errata handling when we submit
> >> the code relevant to this binding (and the FMan v3 support)
> >
> > It affects the binding, so let's discuss it now please.
>
> I think this specific (unpublished yet) errata has less bearing on the
> binding then you might believe. This is mostly about providing a
> common/default frequency supported by all the devices on some board
What reason other than an erratum would there be for the standard
frequency not being supported?
-Scott
^ permalink raw reply
* Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Emil Medve @ 2014-12-22 9:37 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989, Liberman Igal-B31950
In-Reply-To: <1419237176.5581.159.camel@freescale.com>
Hello Scott,
On 12/22/2014 02:32 AM, Scott Wood wrote:
> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
>> Hello Shao-Hui,
>>
>>
>> On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
>>>> On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
>>>>>> -----Original Message-----
>>>>>> From: Wood Scott-B07421
>>>>>> Sent: Friday, December 19, 2014 6:01 AM
>>>>>> To: Xie Shaohui-B21989
>>>>>> Cc: linuxppc-dev@lists.ozlabs.org; devicetree@vger.kernel.org; Medve
>>>>>> Emilian- EMMEDVE1; Liberman Igal-B31950
>>>>>> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
>>>>>>
>>>>>> On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
>>>>>>> Ping.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Shaohui Xie
>>>>>>
>>>>>> I can't put patches in my -next until the merge window closes.
>>>>>>
>>>>>>>>>> +EXAMPLE
>>>>>>>>>> +
>>>>>>>>>> +Example for FMan v2 external MDIO:
>>>>>>>>>> +
>>>>>>>>>> +mdio@f1000 {
>>>>>>>>>> + compatible = "fsl,fman-xmdio";
>>>>>>>>>> + reg = <0xf1000 0x1000>;
>>>>>>>>>> + bus-frequency = <20000>;
>>>>>>>>>> +};
>>>>>>>>>
>>>>>>>>> So the bus frequency is only 20 KHz? Or is the unit supposed
>>>>>>>>> to be something other than Hz?
>>>>>>>> [S.H] it's only an example, it could be different on real SoCs,
>>>>>>>> but they always lower than the standard one, The standard one is
>>>>>>>> 2.5MHz, I have
>>>>>> to use Hz for it.
>>>>>>
>>>>>> Is there any SoC for which 20 kHz is the right frequency? I just
>>>>>> want to make sure the example is realistic.
>>>>> [S.H] the clock divider has a limitation that the MAX value it can get
>>>>> on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
>>>>>
>>>>> So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On Fman
>>>>> v3 is: Fman_clock / ((2 * 511) + 1).
>>>>>
>>>>> Take default Fman frequency setting from SDK1.7 as example, the lowest
>>>>> clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is 600MHz.
>>>>>
>>>>> Then the lowest bus frequency can get is:
>>>>> Fman v2: ~1140KHz
>>>>> Fman v3: ~587KHz
>>>>>
>>>>> 20KHz is not practice, we don't have a suggested value in errata document.
>>>>> For this example, should I post a new version with a value like 1200KHz?
>>>>
>>>> This is different from how you described the problem before. If the limitation
>>>> is on the divider, rather than the absolute bus frequency, then specifiy the max
>>>> divider. Or better, since according to the above this correlates with fman
>>>> version, just have the driver know what the max divider is for each fman version.
>>> [S.H] The problem is not the divider has limitation, the problem is a different bus frequency
>>> Is needed which is lower than the standard, but due to the divider limitation, the lowest
>>> bus frequency also has limitation. i.e. we need to use the divider to get a lower frequency,
>>> but how much lower the value could be is restricted by the divider limitation.
>
> This is difficult to follow -- are you saying the erratum requires a
> speed that is not achievable?
>
>> For the purpose of an example in the binding document, I suggest we just
>> stick with the IEEE standard frequency.
>
> The whole reason for this property existing in the device tree is
> non-standard frequencies.
While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
support frequencies well beyond the standard. Specifying a lower then
the standard frequency for the benefit of some errata is just one side
of this property
>> We can continue this conversation about errata handling when we submit
>> the code relevant to this binding (and the FMan v3 support)
>
> It affects the binding, so let's discuss it now please.
I think this specific (unpublished yet) errata has less bearing on the
binding then you might believe. This is mostly about providing a
common/default frequency supported by all the devices on some board
Anyway, the above thread about bits and lowest frequency limitation(s)
is not really a problem/limitation. The range of frequencies (dividers)
supported by both controller versions in all the supported SoC(s) allows
responding to this (FMan v3 only) errata just fine
Cheers,
^ permalink raw reply
* Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Emil Medve @ 2014-12-22 8:20 UTC (permalink / raw)
To: Xie Shaohui-B21989, Wood Scott-B07421
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Liberman Igal-B31950
In-Reply-To: <DM2PR0301MB086427C10254A0A749CD1326E2560@DM2PR0301MB0864.namprd03.prod.outlook.com>
Hello Shao-Hui,
On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
>> On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Friday, December 19, 2014 6:01 AM
>>>> To: Xie Shaohui-B21989
>>>> Cc: linuxppc-dev@lists.ozlabs.org; devicetree@vger.kernel.org; Medve
>>>> Emilian- EMMEDVE1; Liberman Igal-B31950
>>>> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
>>>>
>>>> On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
>>>>> Ping.
>>>>>
>>>>> Best Regards,
>>>>> Shaohui Xie
>>>>
>>>> I can't put patches in my -next until the merge window closes.
>>>>
>>>>>>>> +EXAMPLE
>>>>>>>> +
>>>>>>>> +Example for FMan v2 external MDIO:
>>>>>>>> +
>>>>>>>> +mdio@f1000 {
>>>>>>>> + compatible = "fsl,fman-xmdio";
>>>>>>>> + reg = <0xf1000 0x1000>;
>>>>>>>> + bus-frequency = <20000>;
>>>>>>>> +};
>>>>>>>
>>>>>>> So the bus frequency is only 20 KHz? Or is the unit supposed
>>>>>>> to be something other than Hz?
>>>>>> [S.H] it's only an example, it could be different on real SoCs,
>>>>>> but they always lower than the standard one, The standard one is
>>>>>> 2.5MHz, I have
>>>> to use Hz for it.
>>>>
>>>> Is there any SoC for which 20 kHz is the right frequency? I just
>>>> want to make sure the example is realistic.
>>> [S.H] the clock divider has a limitation that the MAX value it can get
>>> on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
>>>
>>> So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On Fman
>>> v3 is: Fman_clock / ((2 * 511) + 1).
>>>
>>> Take default Fman frequency setting from SDK1.7 as example, the lowest
>>> clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is 600MHz.
>>>
>>> Then the lowest bus frequency can get is:
>>> Fman v2: ~1140KHz
>>> Fman v3: ~587KHz
>>>
>>> 20KHz is not practice, we don't have a suggested value in errata document.
>>> For this example, should I post a new version with a value like 1200KHz?
>>
>> This is different from how you described the problem before. If the limitation
>> is on the divider, rather than the absolute bus frequency, then specifiy the max
>> divider. Or better, since according to the above this correlates with fman
>> version, just have the driver know what the max divider is for each fman version.
> [S.H] The problem is not the divider has limitation, the problem is a different bus frequency
> Is needed which is lower than the standard, but due to the divider limitation, the lowest
> bus frequency also has limitation. i.e. we need to use the divider to get a lower frequency,
> but how much lower the value could be is restricted by the divider limitation.
For the purpose of an example in the binding document, I suggest we just
stick with the IEEE standard frequency. We can continue this
conversation about errata handling when we submit the code relevant to
this binding (and the FMan v3 support)
Cheers,
^ permalink raw reply
* [PATCH v3 0/2] powerpc32: handle inverted _PAGE_RW bit outside of TLB handlers
From: Christophe Leroy @ 2014-12-22 10:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
scottwood
Cc: linuxppc-dev, linux-kernel
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only) bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of _PAGE_RW
Patchset:
1) powerpc32: adds handling of _PAGE_RO
2) powerpc/8xx: use _PAGE_RO instead of _PAGE_RW
All changes have been successfully tested on MPC885
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2 is a complete rework compared to v1
v3 takes into account comments from Scott on v2
arch/powerpc/include/asm/pgtable-ppc32.h | 12 +++++++-----
arch/powerpc/include/asm/pgtable.h | 7 +++++--
arch/powerpc/include/asm/pte-8xx.h | 9 ++++-----
arch/powerpc/include/asm/pte-common.h | 25 +++++++++++++++++--------
arch/powerpc/kernel/head_8xx.S | 3 ---
arch/powerpc/mm/gup.c | 2 ++
arch/powerpc/mm/pgtable_32.c | 2 +-
7 files changed, 36 insertions(+), 24 deletions(-)
^ permalink raw reply
* [PATCH v3 1/2] powerpc32: adds handling of _PAGE_RO
From: Christophe Leroy @ 2014-12-22 10:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
scottwood
Cc: linuxppc-dev, linux-kernel
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only) bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of _PAGE_RW
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2 is a complete rework of v1
v3:
- cleared PTE can remain 0, no need of _PAGE_RO on PAGE_NONE
- fix __ptep_set_access_flags() to be independant of clear/set order in pte_update()
arch/powerpc/include/asm/pgtable-ppc32.h | 7 ++++---
arch/powerpc/include/asm/pgtable.h | 7 +++++--
arch/powerpc/include/asm/pte-common.h | 25 +++++++++++++++++--------
arch/powerpc/mm/gup.c | 2 ++
arch/powerpc/mm/pgtable_32.c | 2 +-
5 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h
index 543bb8e..caf094a 100644
--- a/arch/powerpc/include/asm/pgtable-ppc32.h
+++ b/arch/powerpc/include/asm/pgtable-ppc32.h
@@ -275,7 +275,7 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- pte_update(ptep, (_PAGE_RW | _PAGE_HWWRITE), 0);
+ pte_update(ptep, (_PAGE_RW | _PAGE_HWWRITE), _PAGE_RO);
}
static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
@@ -286,9 +286,10 @@ static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
static inline void __ptep_set_access_flags(pte_t *ptep, pte_t entry)
{
- unsigned long bits = pte_val(entry) &
+ unsigned long set = pte_val(entry) &
(_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_EXEC);
- pte_update(ptep, 0, bits);
+ unsigned long clr = ~pte_val(entry) & _PAGE_RO;
+ pte_update(ptep, clr, set);
}
#define __HAVE_ARCH_PTE_SAME
diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index 316f9a5..0f713fa 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -30,7 +30,8 @@ struct mm_struct;
#include <asm/tlbflush.h>
/* Generic accessors to PTE bits */
-static inline int pte_write(pte_t pte) { return pte_val(pte) & _PAGE_RW; }
+static inline int pte_write(pte_t pte)
+{ return (pte_val(pte) & (_PAGE_RW | _PAGE_RO)) != _PAGE_RO; }
static inline int pte_dirty(pte_t pte) { return pte_val(pte) & _PAGE_DIRTY; }
static inline int pte_young(pte_t pte) { return pte_val(pte) & _PAGE_ACCESSED; }
static inline int pte_file(pte_t pte) { return pte_val(pte) & _PAGE_FILE; }
@@ -115,12 +116,14 @@ static inline unsigned long pte_pfn(pte_t pte) {
/* Generic modifiers for PTE bits */
static inline pte_t pte_wrprotect(pte_t pte) {
- pte_val(pte) &= ~(_PAGE_RW | _PAGE_HWWRITE); return pte; }
+ pte_val(pte) &= ~(_PAGE_RW | _PAGE_HWWRITE);
+ pte_val(pte) |= _PAGE_RO; return pte; }
static inline pte_t pte_mkclean(pte_t pte) {
pte_val(pte) &= ~(_PAGE_DIRTY | _PAGE_HWWRITE); return pte; }
static inline pte_t pte_mkold(pte_t pte) {
pte_val(pte) &= ~_PAGE_ACCESSED; return pte; }
static inline pte_t pte_mkwrite(pte_t pte) {
+ pte_val(pte) &= ~_PAGE_RO;
pte_val(pte) |= _PAGE_RW; return pte; }
static inline pte_t pte_mkdirty(pte_t pte) {
pte_val(pte) |= _PAGE_DIRTY; return pte; }
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index e040c35..2aef9b7 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -34,6 +34,12 @@
#ifndef _PAGE_PSIZE
#define _PAGE_PSIZE 0
#endif
+/* _PAGE_RO and _PAGE_RW shall not be defined at the same time */
+#ifndef _PAGE_RO
+#define _PAGE_RO 0
+#else
+#define _PAGE_RW 0
+#endif
#ifndef _PMD_PRESENT_MASK
#define _PMD_PRESENT_MASK _PMD_PRESENT
#endif
@@ -42,10 +48,10 @@
#define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE()
#endif
#ifndef _PAGE_KERNEL_RO
-#define _PAGE_KERNEL_RO 0
+#define _PAGE_KERNEL_RO (_PAGE_RO)
#endif
#ifndef _PAGE_KERNEL_ROX
-#define _PAGE_KERNEL_ROX (_PAGE_EXEC)
+#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_RO)
#endif
#ifndef _PAGE_KERNEL_RW
#define _PAGE_KERNEL_RW (_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE)
@@ -95,7 +101,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
/* Mask of bits returned by pte_pgprot() */
#define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | \
_PAGE_WRITETHRU | _PAGE_ENDIAN | _PAGE_4K_PFN | \
- _PAGE_USER | _PAGE_ACCESSED | \
+ _PAGE_USER | _PAGE_ACCESSED | _PAGE_RO | \
_PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC)
#ifdef CONFIG_NUMA_BALANCING
@@ -128,11 +134,14 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
*/
#define PAGE_NONE __pgprot(_PAGE_BASE)
#define PAGE_SHARED __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW)
-#define PAGE_SHARED_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW | _PAGE_EXEC)
-#define PAGE_COPY __pgprot(_PAGE_BASE | _PAGE_USER)
-#define PAGE_COPY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_EXEC)
-#define PAGE_READONLY __pgprot(_PAGE_BASE | _PAGE_USER)
-#define PAGE_READONLY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_EXEC)
+#define PAGE_SHARED_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW | \
+ _PAGE_EXEC)
+#define PAGE_COPY __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RO)
+#define PAGE_COPY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RO | \
+ _PAGE_EXEC)
+#define PAGE_READONLY __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RO)
+#define PAGE_READONLY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RO | \
+ _PAGE_EXEC)
#define __P000 PAGE_NONE
#define __P001 PAGE_READONLY
diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
index d874668..fa287fc 100644
--- a/arch/powerpc/mm/gup.c
+++ b/arch/powerpc/mm/gup.c
@@ -30,6 +30,8 @@ static noinline int gup_pte_range(pmd_t pmd, unsigned long addr,
result = _PAGE_PRESENT|_PAGE_USER;
if (write)
result |= _PAGE_RW;
+ else
+ result |= _PAGE_RO;
mask = result | _PAGE_SPECIAL;
ptep = pte_offset_kernel(&pmd, addr);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index a349089..5519168 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -148,7 +148,7 @@ void __iomem *
ioremap_prot(phys_addr_t addr, unsigned long size, unsigned long flags)
{
/* writeable implies dirty for kernel addresses */
- if (flags & _PAGE_RW)
+ if ((flags & (_PAGE_RW | _PAGE_RO)) != _PAGE_RO)
flags |= _PAGE_DIRTY | _PAGE_HWWRITE;
/* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */
--
2.1.0
^ permalink raw reply related
* [PATCH v3 2/2] powerpc/8xx: use _PAGE_RO instead of _PAGE_RW
From: Christophe Leroy @ 2014-12-22 10:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
scottwood
Cc: linuxppc-dev, linux-kernel
On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages
and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2 is a complete rework compared to v1
v3: fixing pte_update() and comments
arch/powerpc/include/asm/pgtable-ppc32.h | 5 +++--
arch/powerpc/include/asm/pte-8xx.h | 9 ++++-----
arch/powerpc/kernel/head_8xx.S | 3 ---
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h
index caf094a..b4e0c3b 100644
--- a/arch/powerpc/include/asm/pgtable-ppc32.h
+++ b/arch/powerpc/include/asm/pgtable-ppc32.h
@@ -178,9 +178,10 @@ static inline unsigned long pte_update(pte_t *p,
andc %1,%0,%5\n\
or %1,%1,%6\n\
/* 0x200 == Extended encoding, bit 22 */ \
- /* Bit 22 has to be 1 if neither _PAGE_USER nor _PAGE_RW are set */ \
+ /* Bit 22 has to be 1 when _PAGE_USER is unset and _PAGE_RO is set */ \
rlwimi %1,%1,32-2,0x200\n /* get _PAGE_USER */ \
- rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RW */ \
+ rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RO */ \
+ xori %3,%3,0x200\n \
or %1,%3,%1\n\
xori %1,%1,0x200\n"
" stwcx. %1,0,%4\n\
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index daa4616..eb6edb4 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -46,9 +46,9 @@
* require a TLB exception handler change. It is assumed unused bits
* are always zero.
*/
-#define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */
+#define _PAGE_RO 0x0400 /* lsb PP bits */
#define _PAGE_USER 0x0800 /* msb PP bits */
-/* set when neither _PAGE_USER nor _PAGE_RW are set */
+/* set when _PAGE_USER is unset and _PAGE_RO is set */
#define _PAGE_KNLRO 0x0200
#define _PMD_PRESENT 0x0001
@@ -62,9 +62,8 @@
#define PTE_ATOMIC_UPDATES 1
/* We need to add _PAGE_SHARED to kernel pages */
-#define _PAGE_KERNEL_RO (_PAGE_SHARED | _PAGE_KNLRO)
-#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_KNLRO)
-#define _PAGE_KERNEL_RW (_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE)
+#define _PAGE_KERNEL_RO (_PAGE_SHARED | _PAGE_RO | _PAGE_KNLRO)
+#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_RO | _PAGE_KNLRO)
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_PTE_8xx_H */
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 3d4b8ee..807b0db 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -441,9 +441,6 @@ DataStoreTLBMiss:
and r11, r11, r10
rlwimi r10, r11, 0, _PAGE_PRESENT
#endif
- /* invert RW */
- xori r10, r10, _PAGE_RW
-
/* The Linux PTE won't go exactly into the MMU TLB.
* Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
--
2.1.0
^ permalink raw reply related
* Re: [v2 PATCH 1/2] powerpc32: adds handling of _PAGE_RO
From: leroy christophe @ 2014-12-22 10:25 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1418868868.5581.121.camel@freescale.com>
Le 18/12/2014 03:14, Scott Wood a écrit :
> On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
>> Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only) bit.
>> This patch implements the handling of a _PAGE_RO flag to be used in place of _PAGE_RW
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> ---
>> v2 is a complete rework compared to v1
>>
>> arch/powerpc/include/asm/pgtable-ppc32.h | 11 ++++++-----
>> arch/powerpc/include/asm/pgtable.h | 10 +++++++---
>> arch/powerpc/include/asm/pte-common.h | 27 ++++++++++++++++++---------
>> arch/powerpc/mm/gup.c | 2 ++
>> arch/powerpc/mm/mem.c | 2 +-
>> arch/powerpc/mm/pgtable_32.c | 24 ++++++++++++++++++++----
>> 6 files changed, 54 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h
>> index 543bb8e..64ed9e1 100644
>> --- a/arch/powerpc/include/asm/pgtable-ppc32.h
>> +++ b/arch/powerpc/include/asm/pgtable-ppc32.h
>> @@ -125,7 +125,7 @@ extern int icache_44x_need_flush;
>> #ifndef __ASSEMBLY__
>>
>> #define pte_clear(mm, addr, ptep) \
>> - do { pte_update(ptep, ~_PAGE_HASHPTE, 0); } while (0)
>> + do { pte_update(ptep, ~_PAGE_HASHPTE, _PAGE_RO); } while (0)
> Is this really necessary? It's already clearing the valid bit.
>
> Likewise in several other places that set or check for _PAGE_RO on pages
> for which no access is permitted.
>
>
You are right, this is not needed. I needed it because I had defined
pte_none() as requiring _PAGE_RO set. But we can keep value 0 as
pte_none. Taken into account in v3
Christophe
^ permalink raw reply
* [PATCH 2/2] powerpc/config: enable mdio buses muxing via Memory-mapped device
From: shh.xie @ 2014-12-22 9:21 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: Andy Fleming, Shaohui Xie
From: Andy Fleming <afleming@gmail.com>
Signed-off-by: Andy Fleming <afleming@gmail.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index 7525835..6577c41 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -105,6 +105,7 @@ CONFIG_AT803X_PHY=y
CONFIG_FIXED_PHY=y
CONFIG_MDIO_BUS_MUX=y
CONFIG_MDIO_BUS_MUX_GPIO=y
+CONFIG_MDIO_BUS_MUX_MMIOREG=y
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index f915fe4..4016cf6 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -82,6 +82,7 @@ CONFIG_DUMMY=y
CONFIG_E1000E=y
CONFIG_MDIO_BUS_MUX=y
CONFIG_MDIO_BUS_MUX_GPIO=y
+CONFIG_MDIO_BUS_MUX_MMIOREG=y
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
--
1.8.4.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/config: enable mdio buses muxing via gpio
From: shh.xie @ 2014-12-22 9:19 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: Andy Fleming, Shaohui Xie
From: Andy Fleming <afleming@gmail.com>
Signed-off-by: Andy Fleming <afleming@gmail.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 2 ++
arch/powerpc/configs/corenet64_smp_defconfig | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index 611efe9..7525835 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -103,6 +103,8 @@ CONFIG_E1000E=y
CONFIG_VITESSE_PHY=y
CONFIG_AT803X_PHY=y
CONFIG_FIXED_PHY=y
+CONFIG_MDIO_BUS_MUX=y
+CONFIG_MDIO_BUS_MUX_GPIO=y
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index be24a18..f915fe4 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -80,6 +80,8 @@ CONFIG_SATA_SIL24=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_E1000E=y
+CONFIG_MDIO_BUS_MUX=y
+CONFIG_MDIO_BUS_MUX_GPIO=y
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
From: Emil Medve @ 2014-12-22 11:08 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989, Liberman Igal-B31950
In-Reply-To: <1419241330.5581.162.camel@freescale.com>
Hello Scott,
On 12/22/2014 03:42 AM, Scott Wood wrote:
> On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 12/22/2014 02:32 AM, Scott Wood wrote:
>>> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
>>>> For the purpose of an example in the binding document, I suggest we just
>>>> stick with the IEEE standard frequency.
>>>
>>> The whole reason for this property existing in the device tree is
>>> non-standard frequencies.
>>
>> While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
>> support frequencies well beyond the standard. Specifying a lower then
>> the standard frequency for the benefit of some errata is just one side
>> of this property
>
> The erratum was (until now) the only claimed reason for it. If there
> are other reasons why one would specify a different frequency (in
> particular, that relate to hardware description), please elaborate.
>From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS boards
support 12.5 MHz. I can dig out more specs for specifics on other PHY(s)
2.5 MHz is slow and even more so for high speed interfaces. With both
polling and interrupts (both MDIO and/or PHY) we've noticed (or blamed)
in the past some Ethernet performance issues on this very slowness
As of right now I'm not aware of another way to specify/coordinate the
MDC speed so setting a default (common denominator) in the DT that is
different then the IEEE standard seems ok
>>>> We can continue this conversation about errata handling when we submit
>>>> the code relevant to this binding (and the FMan v3 support)
>>>
>>> It affects the binding, so let's discuss it now please.
>>
>> I think this specific (unpublished yet) errata has less bearing on the
>> binding then you might believe. This is mostly about providing a
>> common/default frequency supported by all the devices on some board
>
> What reason other than an erratum would there be for the standard
> frequency not being supported?
This is not about not supporting the standard frequency. This is about
the default frequency being different then the standard
Cheers,
^ permalink raw reply
* Re: [git pull] Please pull mpe/linux.git powerpc-3.19-2 tag
From: Andreas Schwab @ 2014-12-22 14:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, anton
In-Reply-To: <1418980604.30631.1.camel@ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Anton Blanchard (1):
> powerpc: Secondary CPUs must set cpu_callin_map after setting active and online
This breaks booting on the PowerMac7,3. It takes forever to boot to
user space (~5 minutes instead of ~4 seconds), and then I see these
processes in top:
37 root 20 0 0 0 0 D 0.000 0.000 0:00.00 kwindfarm
10 root rt 0 0 0 0 R 0.000 0.000 0:00.00 migration/1
11 root 20 0 0 0 0 R 0.000 0.000 0:00.00 ksoftirqd/1
(The latter two processes don't accumulate any cpu time, but they are
constantly in run state.)
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v6 1/4] tools/perf: support parsing parameterized events
From: Jiri Olsa @ 2014-12-22 14:37 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: peterz, linux-kernel, Arnaldo Carvalho de Melo, dev,
Paul Mackerras, linuxppc-dev
In-Reply-To: <1419234567-22784-2-git-send-email-sukadev@linux.vnet.ibm.com>
On Sun, Dec 21, 2014 at 11:49:24PM -0800, Sukadev Bhattiprolu wrote:
SNIP
> + }
>
> switch (format->value) {
> case PERF_PMU_FORMAT_VALUE_CONFIG:
> @@ -592,11 +629,16 @@ static int pmu_config_term(struct list_head *formats,
> }
>
> /*
> - * XXX If we ever decide to go with string values for
> - * non-hardcoded terms, here's the place to translate
> - * them into value.
> + * Either directly use a numeric term, or try to translate string terms
> + * using event parameters.
> */
> - pmu_format_value(format->bits, term->val.num, vp, zero);
> + if (term->type_val == PARSE_EVENTS__TERM_TYPE_NUM)
> + val = term->val.num;
> + else
> + if (pmu_resolve_param_term(term, head_terms, &val))
> + return -EINVAL;
> +
I'm ok with the change logic, but I'm missing here check for the 'term'
string value to be '?', so we force subst terms to have '?' as value..
I believe thats what we decided in the previous set discussion, right?
I guess the it'd be nice to parse it directly in the bison code like
below (could be done later), but I'd be ok with simple check on this
place for now.
thanks,
jirka
---
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 93c4c9fbc922..7e021c64d5cc 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -484,6 +484,14 @@ PE_TERM '=' PE_VALUE
$$ = term;
}
|
+PE_TERM '=' PE_SUBST
+{
+ struct parse_events_term *term;
+
+ ABORT_ON(parse_events_term__subst(&term, (int)$1, NULL, NULL));
+ $$ = term;
+}
+|
PE_TERM
{
struct parse_events_term *term;
^ permalink raw reply related
* Re: [PATCH v6 3/4] perf Documentation: add event parameters
From: Jiri Olsa @ 2014-12-22 14:39 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: peterz, linux-kernel, Arnaldo Carvalho de Melo, dev,
Paul Mackerras, linuxppc-dev
In-Reply-To: <1419234567-22784-4-git-send-email-sukadev@linux.vnet.ibm.com>
On Sun, Dec 21, 2014 at 11:49:26PM -0800, Sukadev Bhattiprolu wrote:
> From: Cody P Schafer <cody@linux.vnet.ibm.com>
>
> Event parameters are a basic way for partial events to be specified in
> sysfs with per-event names given to the fields that need to be filled in
> when using a particular event.
>
> It is intended for supporting cases where the single 'cpu' parameter is
> insufficient. For example, POWER 8 has events for physical
> sockets/cores/cpus that are accessible from with virtual machines. To
> keep using the single 'cpu' parameter we'd need to perform a mapping
> between Linux's cpus and the physical machine's cpus (in this case
> Linux is running under a hypervisor). This isn't possible because
> bindings between our cpus and physical cpus may not be fixed, and we
> probably won't have a "cpu" on each physical cpu.
>
> Changelog[v6]
> Update event description to explain how required parameters
> are displayed.
>
> CC: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> CC: Haren Myneni <hbabu@us.ibm.com>
> CC: Cody P Schafer <dev@codyps.com>
> Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
> ---
> Documentation/ABI/testing/sysfs-bus-event_source-devices-events | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
> index 20979f8..47ad2a1 100644
> --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
> @@ -52,12 +52,18 @@ Description: Per-pmu performance monitoring events specific to the running syste
> event=0x2abc
> event=0x423,inv,cmask=0x3
> domain=0x1,offset=0x8,starting_index=0xffff
> + domain=0x1,offset=0x8,core=?
>
> Each of the assignments indicates a value to be assigned to a
> particular set of bits (as defined by the format file
> corresponding to the <term>) in the perf_event structure passed
> to the perf_open syscall.
>
> + In the case of the last example, a value replacing "?" would
> + need to be provided by the user selecting the particular event.
> + This is referred to as "event parameterization". All
> + non-numerical values indicate an event parameter.
I see.. here's the glitch ;-) I thought we agreed on forcing '?'
as the value for param events, not 'All non-numerical values'
thanks,
jirka
^ permalink raw reply
* Re: [PATCH v6 4/4] tools/perf: Document parameterized and symbolic events
From: Jiri Olsa @ 2014-12-22 14:43 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: peterz, linux-kernel, Arnaldo Carvalho de Melo, dev,
Paul Mackerras, linuxppc-dev
In-Reply-To: <1419234567-22784-5-git-send-email-sukadev@linux.vnet.ibm.com>
On Sun, Dec 21, 2014 at 11:49:27PM -0800, Sukadev Bhattiprolu wrote:
> From: Cody P Schafer <cody@linux.vnet.ibm.com>
>
> Changelog[v6]:
> - [Sukadev Bhattiprolu]: Update documentation of perf-list and
> perf-record; Added documentation for perf-stat.
>
> CC: Haren Myneni <hbabu@us.ibm.com>
> CC: Cody P Schafer <dev@codyps.com>
> Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> ---
> tools/perf/Documentation/perf-list.txt | 13 +++++++++++++
> tools/perf/Documentation/perf-record.txt | 12 ++++++++++++
> tools/perf/Documentation/perf-stat.txt | 20 ++++++++++++++++----
> 3 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt
> index cbb4f74..d8be6fa 100644
> --- a/tools/perf/Documentation/perf-list.txt
> +++ b/tools/perf/Documentation/perf-list.txt
> @@ -89,6 +89,19 @@ raw encoding of 0x1A8 can be used:
> You should refer to the processor specific documentation for getting these
> details. Some of them are referenced in the SEE ALSO section below.
>
> +PARAMETERIZED EVENTS
> +--------------------
> +
> +Some pmu events listed by 'perf-list' will be displayed with '$x' in them. For
> +example:
s/$x/?/ ^^^^
> +
> + hv_gpci/dtbp_ptitc,phys_processor_idx=?/
> +
> +This means that when provided as an event, a value for '?' must
> +also be supplied. For example:
> +
> + perf stat -C 0 -e 'hv_gpci/dtbp_ptitc,phys_processor_idx=0x2/' ...
> +
> OPTIONS
> -------
>
> diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt
> index af9a54e..acdcf3b 100644
> --- a/tools/perf/Documentation/perf-record.txt
> +++ b/tools/perf/Documentation/perf-record.txt
> @@ -33,6 +33,18 @@ OPTIONS
> - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
> hexadecimal event descriptor.
SNIP
> +
> + - a symbolically formed event like 'pmu/config=M,config1=N,config3=K/'
> +
> + where M, N, K are numbers (in decimal, hex, octal format). Acceptable
> + values for each of 'config', 'config1' and 'config2' are defined by
> + corresponding entries in /sys/bus/event_sources/devices/<pmu>/format/*
> + param1 and param2 are defined as formats for the PMU in:
> + /sys/bus/event_sources/devices/<pmu>/format/*
^^^^ misaligned tab
> +
> - a hardware breakpoint event in the form of '\mem:addr[:access]'
> where addr is the address in memory you want to break in.
> Access is the memory access type (read, write, execute) it can
> diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt
> index 29ee857..04e150d 100644
> --- a/tools/perf/Documentation/perf-stat.txt
> +++ b/tools/perf/Documentation/perf-stat.txt
> @@ -25,10 +25,22 @@ OPTIONS
>
thanks,
jirka
^ 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