* [PATCH v2 09/11] powerpc/perf: add support for the hv 24x7 interface
From: Cody P Schafer @ 2014-02-14 22:02 UTC (permalink / raw)
To: Linux PPC, Cody P Schafer
Cc: Peter Zijlstra, LKML, Michael Ellerman, Ingo Molnar,
Paul Mackerras, Arnaldo Carvalho de Melo
In-Reply-To: <1392415338-16288-1-git-send-email-cody@linux.vnet.ibm.com>
This provides a basic interface between hv_24x7 and perf. Similar to
the one provided for gpci, it lacks transaction support and does not
list any events.
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
arch/powerpc/perf/hv-24x7.c | 491 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 491 insertions(+)
create mode 100644 arch/powerpc/perf/hv-24x7.c
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
new file mode 100644
index 0000000..13de140
--- /dev/null
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -0,0 +1,491 @@
+/*
+ * Hypervisor supplied "24x7" performance counter support
+ *
+ * Author: Cody P Schafer <cody@linux.vnet.ibm.com>
+ * Copyright 2014 IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt) "hv-24x7: " fmt
+
+#include <linux/perf_event.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <asm/firmware.h>
+#include <asm/hvcall.h>
+#include <asm/io.h>
+
+#include "hv-24x7.h"
+#include "hv-common.h"
+
+/*
+ * TODO: Merging events:
+ * - Think of the hcall as an interface to a 4d array of counters:
+ * - x = domains
+ * - y = indexes in the domain (core, chip, vcpu, node, etc)
+ * - z = offset into the counter space
+ * - w = lpars (guest vms, "logical partitions")
+ * - A single request is: x,y,y_last,z,z_last,w,w_last
+ * - this means we can retrieve a rectangle of counters in y,z for a single x.
+ *
+ * - Things to consider (ignoring w):
+ * - input cost_per_request = 16
+ * - output cost_per_result(ys,zs) = 8 + 8 * ys + ys * zs
+ * - limited number of requests per hcall (must fit into 4K bytes)
+ * - 4k = 16 [buffer header] - 16 [request size] * request_count
+ * - 255 requests per hcall
+ * - sometimes it will be more efficient to read extra data and discard
+ */
+
+PMU_RANGE_ATTR(domain, config, 0, 3); /* u3 0-6, one of HV_24X7_PERF_DOMAIN */
+PMU_RANGE_ATTR(starting_index, config, 16, 31); /* u16 */
+PMU_RANGE_ATTR(offset, config, 32, 63); /* u32, see "data_offset" */
+PMU_RANGE_ATTR(lpar, config1, 0, 15); /* u16 */
+
+PMU_RANGE_RESV(reserved1, config, 4, 15);
+PMU_RANGE_RESV(reserved2, config1, 16, 63);
+PMU_RANGE_RESV(reserved3, config2, 0, 63);
+
+static struct attribute *format_attrs[] = {
+ &format_attr_domain.attr,
+ &format_attr_offset.attr,
+ &format_attr_starting_index.attr,
+ &format_attr_lpar.attr,
+ NULL,
+};
+
+static struct attribute_group format_group = {
+ .name = "format",
+ .attrs = format_attrs,
+};
+
+/*
+ * read_offset_data - copy data from one buffer to another while treating the
+ * source buffer as a small view on the total avaliable
+ * source data.
+ *
+ * @dest: buffer to copy into
+ * @dest_len: length of @dest in bytes
+ * @requested_offset: the offset within the source data we want. Must be > 0
+ * @src: buffer to copy data from
+ * @src_len: length of @src in bytes
+ * @source_offset: the offset in the sorce data that (src,src_len) refers to.
+ * Must be > 0
+ *
+ * returns the number of bytes copied.
+ *
+ * '.' areas in d are written to.
+ *
+ * u
+ * x w v z
+ * d |.........|
+ * s |----------------------|
+ *
+ * u
+ * x w z v
+ * d |........------|
+ * s |------------------|
+ *
+ * x w u,z,v
+ * d |........|
+ * s |------------------|
+ *
+ * x,w u,v,z
+ * d |------------------|
+ * s |------------------|
+ *
+ * x u
+ * w v z
+ * d |........|
+ * s |------------------|
+ *
+ * x z w v
+ * d |------|
+ * s |------|
+ *
+ * x = source_offset
+ * w = requested_offset
+ * z = source_offset + src_len
+ * v = requested_offset + dest_len
+ *
+ * w_offset_in_s = w - x = requested_offset - source_offset
+ * z_offset_in_s = z - x = src_len
+ * v_offset_in_s = v - x = request_offset + dest_len - src_len
+ * u_offset_in_s = min(z_offset_in_s, v_offset_in_s)
+ *
+ * copy_len = u_offset_in_s - w_offset_in_s = min(z_offset_in_s, v_offset_in_s)
+ * - w_offset_in_s
+ */
+static ssize_t read_offset_data(void *dest, size_t dest_len,
+ loff_t requested_offset, void *src,
+ size_t src_len, loff_t source_offset)
+{
+ size_t w_offset_in_s = requested_offset - source_offset;
+ size_t z_offset_in_s = src_len;
+ size_t v_offset_in_s = requested_offset + dest_len - src_len;
+ size_t u_offset_in_s = min(z_offset_in_s, v_offset_in_s);
+ size_t copy_len = u_offset_in_s - w_offset_in_s;
+
+ if (requested_offset < 0 || source_offset < 0)
+ return -EINVAL;
+
+ if (z_offset_in_s <= w_offset_in_s)
+ return 0;
+
+ memcpy(dest, src + w_offset_in_s, copy_len);
+ return copy_len;
+}
+
+static unsigned long h_get_24x7_catalog_page(char page[static 4096],
+ u32 version, u32 index)
+{
+ WARN_ON(!IS_ALIGNED((unsigned long)page, 4096));
+ return plpar_hcall_norets(H_GET_24X7_CATALOG_PAGE,
+ virt_to_phys(page),
+ version,
+ index);
+}
+
+static ssize_t catalog_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr, char *buf,
+ loff_t offset, size_t count)
+{
+ unsigned long hret;
+ ssize_t ret = 0;
+ size_t catalog_len = 0, catalog_page_len = 0, page_count = 0;
+ loff_t page_offset = 0;
+ uint32_t catalog_version_num = 0;
+ void *page = kmalloc(4096, GFP_USER);
+ struct hv_24x7_catalog_page_0 *page_0 = page;
+ if (!page)
+ return -ENOMEM;
+
+
+ hret = h_get_24x7_catalog_page(page, 0, 0);
+ if (hret) {
+ ret = -EIO;
+ goto e_free;
+ }
+
+ catalog_version_num = be32_to_cpu(page_0->version);
+ catalog_page_len = be32_to_cpu(page_0->length);
+ catalog_len = catalog_page_len * 4096;
+
+ page_offset = offset / 4096;
+ page_count = count / 4096;
+
+ if (page_offset >= catalog_page_len)
+ goto e_free;
+
+ if (page_offset != 0) {
+ hret = h_get_24x7_catalog_page(page, catalog_version_num,
+ page_offset);
+ if (hret) {
+ ret = -EIO;
+ goto e_free;
+ }
+ }
+
+ ret = read_offset_data(buf, count, offset,
+ page, 4096, page_offset * 4096);
+e_free:
+ if (hret)
+ pr_err("h_get_24x7_catalog_page(ver=%d, page=%lld) failed: rc=%ld\n",
+ catalog_version_num, page_offset, hret);
+ kfree(page);
+
+ pr_devel("catalog_read: offset=%lld(%lld) count=%zu(%zu) catalog_len=%zu(%zu) => %zd\n",
+ offset, page_offset, count, page_count, catalog_len,
+ catalog_page_len, ret);
+
+ return ret;
+}
+
+#define PAGE_0_ATTR(_name, _fmt, _expr) \
+static ssize_t _name##_show(struct device *dev, \
+ struct device_attribute *dev_attr, \
+ char *buf) \
+{ \
+ unsigned long hret; \
+ ssize_t ret = 0; \
+ void *page = kmalloc(4096, GFP_USER); \
+ struct hv_24x7_catalog_page_0 *page_0 = page; \
+ if (!page) \
+ return -ENOMEM; \
+ hret = h_get_24x7_catalog_page(page, 0, 0); \
+ if (hret) { \
+ ret = -EIO; \
+ goto e_free; \
+ } \
+ ret = sprintf(buf, _fmt, _expr); \
+e_free: \
+ kfree(page); \
+ return ret; \
+} \
+static DEVICE_ATTR_RO(_name)
+
+PAGE_0_ATTR(catalog_version, "%lld\n",
+ (unsigned long long)be32_to_cpu(page_0->version));
+PAGE_0_ATTR(catalog_len, "%lld\n",
+ (unsigned long long)be32_to_cpu(page_0->length) * 4096);
+static BIN_ATTR_RO(catalog, 0/* real length varies */);
+
+static struct bin_attribute *if_bin_attrs[] = {
+ &bin_attr_catalog,
+ NULL,
+};
+
+static struct attribute *if_attrs[] = {
+ &dev_attr_catalog_len.attr,
+ &dev_attr_catalog_version.attr,
+ NULL,
+};
+
+static struct attribute_group if_group = {
+ .name = "interface",
+ .bin_attrs = if_bin_attrs,
+ .attrs = if_attrs,
+};
+
+static const struct attribute_group *attr_groups[] = {
+ &format_group,
+ &if_group,
+ NULL,
+};
+
+static bool is_physical_domain(int domain)
+{
+ return domain == HV_24X7_PERF_DOMAIN_PHYSICAL_CHIP ||
+ domain == HV_24X7_PERF_DOMAIN_PHYSICAL_CORE;
+}
+
+static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
+ u16 lpar, u64 *res,
+ bool success_expected)
+{
+ unsigned long ret;
+
+ /*
+ * request_buffer and result_buffer are not required to be 4k aligned,
+ * but are not allowed to cross any 4k boundary. Aligning them to 4k is
+ * the simplest way to ensure that.
+ */
+ struct reqb {
+ struct hv_24x7_request_buffer buf;
+ struct hv_24x7_request req;
+ } __packed __aligned(4096) request_buffer = {
+ .buf = {
+ .interface_version = HV_24X7_IF_VERSION_CURRENT,
+ .num_requests = 1,
+ },
+ .req = {
+ .performance_domain = domain,
+ .data_size = cpu_to_be16(8),
+ .data_offset = cpu_to_be32(offset),
+ .starting_lpar_ix = cpu_to_be16(lpar),
+ .max_num_lpars = cpu_to_be16(1),
+ .starting_ix = cpu_to_be16(ix),
+ .max_ix = cpu_to_be16(1),
+ }
+ };
+
+ struct resb {
+ struct hv_24x7_data_result_buffer buf;
+ struct hv_24x7_result res;
+ struct hv_24x7_result_element elem;
+ __be64 result;
+ } __packed __aligned(4096) result_buffer = {};
+
+ ret = plpar_hcall_norets(H_GET_24X7_DATA,
+ virt_to_phys(&request_buffer), sizeof(request_buffer),
+ virt_to_phys(&result_buffer), sizeof(result_buffer));
+
+ if (ret) {
+ if (success_expected)
+ pr_err_ratelimited("hcall failed: %d %#x %#x %d => 0x%lx (%ld) detail=0x%x failing ix=%x\n",
+ domain, offset, ix, lpar,
+ ret, ret,
+ result_buffer.buf.detailed_rc,
+ result_buffer.buf.failing_request_ix);
+ return ret;
+ }
+
+ *res = be64_to_cpu(result_buffer.result);
+ return ret;
+}
+
+static unsigned long event_24x7_request(struct perf_event *event, u64 *res,
+ bool success_expected)
+{
+ return single_24x7_request(event_get_domain(event),
+ event_get_offset(event),
+ event_get_starting_index(event),
+ event_get_lpar(event),
+ res,
+ success_expected);
+}
+
+static int h_24x7_event_init(struct perf_event *event)
+{
+ struct hv_perf_caps caps;
+ unsigned domain;
+ unsigned long hret;
+ u64 ct;
+
+ /* Not our event */
+ if (event->attr.type != event->pmu->type)
+ return -ENOENT;
+
+ /* Unused areas must be 0 */
+ if (event_get_reserved1(event) ||
+ event_get_reserved2(event) ||
+ event_get_reserved3(event)) {
+ pr_devel("reserved set when forbidden 0x%llx(0x%llx) 0x%llx(0x%llx) 0x%llx(0x%llx)\n",
+ event->attr.config,
+ event_get_reserved1(event),
+ event->attr.config1,
+ event_get_reserved2(event),
+ event->attr.config2,
+ event_get_reserved3(event));
+ return -EINVAL;
+ }
+
+ /* unsupported modes and filters */
+ if (event->attr.exclude_user ||
+ event->attr.exclude_kernel ||
+ event->attr.exclude_hv ||
+ event->attr.exclude_idle ||
+ event->attr.exclude_host ||
+ event->attr.exclude_guest ||
+ is_sampling_event(event)) /* no sampling */
+ return -EINVAL;
+
+ /* no branch sampling */
+ if (has_branch_stack(event))
+ return -EOPNOTSUPP;
+
+ /* offset must be 8 byte aligned */
+ if (event_get_offset(event) % 8) {
+ pr_devel("bad alignment\n");
+ return -EINVAL;
+ }
+
+ /* Domains above 6 are invalid */
+ domain = event_get_domain(event);
+ if (domain > 6) {
+ pr_devel("invalid domain %d\n", domain);
+ return -EINVAL;
+ }
+
+ hret = hv_perf_caps_get(&caps);
+ if (hret) {
+ pr_devel("could not get capabilities: rc=%ld\n", hret);
+ return -EIO;
+ }
+
+ /* PHYSICAL domains & other lpars require extra capabilities */
+ if (!caps.collect_privileged && (is_physical_domain(domain) ||
+ (event_get_lpar(event) != event_get_lpar_max()))) {
+ pr_devel("hv permisions disallow: is_physical_domain:%d, lpar=0x%llx\n",
+ is_physical_domain(domain),
+ event_get_lpar(event));
+ return -EACCES;
+ }
+
+ /* see if the event complains */
+ if (event_24x7_request(event, &ct, false)) {
+ pr_devel("test hcall failed\n");
+ return -EIO;
+ }
+
+ perf_swevent_init_hrtimer(event);
+ return 0;
+}
+
+static u64 h_24x7_get_value(struct perf_event *event)
+{
+ unsigned long ret;
+ u64 ct;
+ ret = event_24x7_request(event, &ct, true);
+ if (ret)
+ /* We checked this in event init, shouldn't fail here... */
+ return 0;
+
+ return ct;
+}
+
+static void h_24x7_event_update(struct perf_event *event)
+{
+ s64 prev;
+ u64 now;
+ now = h_24x7_get_value(event);
+ prev = local64_xchg(&event->hw.prev_count, now);
+ local64_add(now - prev, &event->count);
+}
+
+static void h_24x7_event_start(struct perf_event *event, int flags)
+{
+ if (flags & PERF_EF_RELOAD)
+ local64_set(&event->hw.prev_count, h_24x7_get_value(event));
+ perf_swevent_start_hrtimer(event);
+}
+
+static void h_24x7_event_stop(struct perf_event *event, int flags)
+{
+ perf_swevent_cancel_hrtimer(event);
+ h_24x7_event_update(event);
+}
+
+static int h_24x7_event_add(struct perf_event *event, int flags)
+{
+ if (flags & PERF_EF_START)
+ h_24x7_event_start(event, flags);
+
+ return 0;
+}
+
+static struct pmu h_24x7_pmu = {
+ .task_ctx_nr = perf_invalid_context,
+
+ .name = "hv_24x7",
+ .attr_groups = attr_groups,
+ .event_init = h_24x7_event_init,
+ .add = h_24x7_event_add,
+ .del = h_24x7_event_stop,
+ .start = h_24x7_event_start,
+ .stop = h_24x7_event_stop,
+ .read = h_24x7_event_update,
+
+ .event_idx = perf_swevent_event_idx,
+};
+
+static int hv_24x7_init(void)
+{
+ int r;
+ unsigned long hret;
+ struct hv_perf_caps caps;
+
+ if (!firmware_has_feature(FW_FEATURE_LPAR)) {
+ pr_info("not a virtualized system, not enabling\n");
+ return -ENODEV;
+ }
+
+ hret = hv_perf_caps_get(&caps);
+ if (hret) {
+ pr_info("could not obtain capabilities, error 0x%80lx, not enabling\n",
+ hret);
+ return -ENODEV;
+ }
+
+ r = perf_pmu_register(&h_24x7_pmu, h_24x7_pmu.name, -1);
+ if (r)
+ return r;
+
+ return 0;
+}
+
+device_initcall(hv_24x7_init);
--
1.8.5.4
^ permalink raw reply related
* [PATCH v2 10/11] powerpc/perf: add kconfig option for hypervisor provided counters
From: Cody P Schafer @ 2014-02-14 22:02 UTC (permalink / raw)
To: Linux PPC, Aneesh Kumar K.V, Anshuman Khandual, Anton Blanchard,
Benjamin Herrenschmidt, Cody P Schafer, Kumar Gala, Lijun Pan,
Li Yang, Michael Ellerman, Paul Bolle, Priyanka Jain, Scott Wood,
Tang Yuantian
Cc: Ingo Molnar, Paul Mackerras, LKML, Arnaldo Carvalho de Melo,
Peter Zijlstra
In-Reply-To: <1392415338-16288-1-git-send-email-cody@linux.vnet.ibm.com>
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
arch/powerpc/perf/Makefile | 2 ++
arch/powerpc/platforms/Kconfig.cputype | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index 60d71ee..f9c083a 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -11,5 +11,7 @@ obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
+obj-$(CONFIG_HV_PERF_CTRS) += hv-24x7.o hv-gpci.o hv-common.o
+
obj-$(CONFIG_PPC64) += $(obj64-y)
obj-$(CONFIG_PPC32) += $(obj32-y)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 434fda3..dcc67cd 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -364,6 +364,12 @@ config PPC_PERF_CTRS
help
This enables the powerpc-specific perf_event back-end.
+config HV_PERF_CTRS
+ def_bool y
+ depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT
+ help
+ Enable access to perf counters provided by the hypervisor
+
config SMP
depends on PPC_BOOK3S || PPC_BOOK3E || FSL_BOOKE || PPC_47x
bool "Symmetric multi-processing support"
--
1.8.5.4
^ permalink raw reply related
* [PATCH v2 11/11] powerpc/perf/hv_{gpci, 24x7}: add documentation of device attributes
From: Cody P Schafer @ 2014-02-14 22:02 UTC (permalink / raw)
To: Linux PPC, Cody P Schafer
Cc: Rob Landley, Peter Zijlstra, linux-doc, LKML, Michael Ellerman,
Ingo Molnar, Paul Mackerras, Arnaldo Carvalho de Melo
In-Reply-To: <1392415338-16288-1-git-send-email-cody@linux.vnet.ibm.com>
gpci and 24x7 expose some device specific attributes. Add some
documentation for them.
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
.../testing/sysfs-bus-event_source-devices-hv_24x7 | 22 +++++++++++
.../testing/sysfs-bus-event_source-devices-hv_gpci | 43 ++++++++++++++++++++++
2 files changed, 65 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
create mode 100644 Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
new file mode 100644
index 0000000..13474d3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
@@ -0,0 +1,22 @@
+What: /sys/bus/event_source/devices/hv_24x7/interface/catalog
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ Provides access to the binary "24x7 catalog" provided by the
+ hypervisor on POWER7 and 8 systems. This catalog lists events
+ avaliable from the powerpc "hv_24x7" pmu. Its format is
+ documented in arch/powerpc/perf/hv_24x7.h.
+
+What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_length
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ A number equal to the length in bytes of the catalog. This is
+ also extractable from the provided binary "catalog" sysfs entry.
+
+What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_version
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ Exposes the "version" field of the 24x7 catalog. This is also
+ extractable from the provided binary "catalog" sysfs entry.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
new file mode 100644
index 0000000..3fa58c2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
@@ -0,0 +1,43 @@
+What: /sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ '0' if the hypervisor is configured to forbid access to event
+ counters being accumulated by other guests and to physical
+ domain event counters.
+ '1' if that access is allowed.
+
+What: /sys/bus/event_source/devices/hv_gpci/interface/ga
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ 0 or 1. Indicates whether we have access to "GA" events (listed
+ in arch/powerpc/perf/hv-gpci.h).
+
+What: /sys/bus/event_source/devices/hv_gpci/interface/expanded
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ 0 or 1. Indicates whether we have access to "EXPANDED" events (listed
+ in arch/powerpc/perf/hv-gpci.h).
+
+What: /sys/bus/event_source/devices/hv_gpci/interface/lab
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ 0 or 1. Indicates whether we have access to "LAB" events (listed
+ in arch/powerpc/perf/hv-gpci.h).
+
+What: /sys/bus/event_source/devices/hv_gpci/interface/version
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ A number indicating the version of the gpci interface that the
+ hypervisor reports supporting.
+
+What: /sys/bus/event_source/devices/hv_gpci/interface/kernel_version
+Date: February 2014
+Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+ A number indicating the latest version of the gpci interface
+ that the kernel is aware of.
--
1.8.5.4
^ permalink raw reply related
* Re: [PATCH v2 10/11] powerpc/perf: add kconfig option for hypervisor provided counters
From: Scott Wood @ 2014-02-14 22:32 UTC (permalink / raw)
To: Cody P Schafer
Cc: Paul Bolle, Peter Zijlstra, LKML, Michael Ellerman, Tang Yuantian,
Ingo Molnar, Paul Mackerras, Aneesh Kumar K.V,
Arnaldo Carvalho de Melo, Priyanka Jain, Lijun Pan,
Anshuman Khandual, Linux PPC, Anton Blanchard
In-Reply-To: <1392415338-16288-11-git-send-email-cody@linux.vnet.ibm.com>
On Fri, 2014-02-14 at 14:02 -0800, Cody P Schafer wrote:
> Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/Makefile | 2 ++
> arch/powerpc/platforms/Kconfig.cputype | 6 ++++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
> index 60d71ee..f9c083a 100644
> --- a/arch/powerpc/perf/Makefile
> +++ b/arch/powerpc/perf/Makefile
> @@ -11,5 +11,7 @@ obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
> obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
> obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
>
> +obj-$(CONFIG_HV_PERF_CTRS) += hv-24x7.o hv-gpci.o hv-common.o
> +
> obj-$(CONFIG_PPC64) += $(obj64-y)
> obj-$(CONFIG_PPC32) += $(obj32-y)
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 434fda3..dcc67cd 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -364,6 +364,12 @@ config PPC_PERF_CTRS
> help
> This enables the powerpc-specific perf_event back-end.
>
> +config HV_PERF_CTRS
> + def_bool y
> + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT
> + help
> + Enable access to perf counters provided by the hypervisor
Please don't add default-y stuff that is platform-specific, and
definitely point out that platform dependency in the config description
-- I have to look elsewhere in the patchset to determine that this is
for "Power Hypervisor". PPC_HAVE_PMU_SUPPORT is enabled by all 6xx
builds, even for hardware like e300 that doesn't have PMU at all (it has
the FSL embedded perfmon instead), much less this hv interface.
And yes, PPC_PERF_CTRS has the same problem and should be fixed. :-)
-Scott
^ permalink raw reply
* Re: [PATCH v2 10/11] powerpc/perf: add kconfig option for hypervisor provided counters
From: Cody P Schafer @ 2014-02-15 0:25 UTC (permalink / raw)
To: Scott Wood
Cc: Paul Bolle, Peter Zijlstra, LKML, Michael Ellerman, Tang Yuantian,
Ingo Molnar, Paul Mackerras, Aneesh Kumar K.V,
Arnaldo Carvalho de Melo, Priyanka Jain, Lijun Pan,
Anshuman Khandual, Linux PPC, Anton Blanchard
In-Reply-To: <1392417133.6733.624.camel@snotra.buserror.net>
On Fri, Feb 14, 2014 at 04:32:13PM -0600, Scott Wood wrote:
> On Fri, 2014-02-14 at 14:02 -0800, Cody P Schafer wrote:
> > Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/perf/Makefile | 2 ++
> > arch/powerpc/platforms/Kconfig.cputype | 6 ++++++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
> > index 60d71ee..f9c083a 100644
> > --- a/arch/powerpc/perf/Makefile
> > +++ b/arch/powerpc/perf/Makefile
> > @@ -11,5 +11,7 @@ obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
> > obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
> > obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
> >
> > +obj-$(CONFIG_HV_PERF_CTRS) += hv-24x7.o hv-gpci.o hv-common.o
> > +
> > obj-$(CONFIG_PPC64) += $(obj64-y)
> > obj-$(CONFIG_PPC32) += $(obj32-y)
> > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> > index 434fda3..dcc67cd 100644
> > --- a/arch/powerpc/platforms/Kconfig.cputype
> > +++ b/arch/powerpc/platforms/Kconfig.cputype
> > @@ -364,6 +364,12 @@ config PPC_PERF_CTRS
> > help
> > This enables the powerpc-specific perf_event back-end.
> >
> > +config HV_PERF_CTRS
> > + def_bool y
> > + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT
> > + help
> > + Enable access to perf counters provided by the hypervisor
>
> Please don't add default-y stuff that is platform-specific, and
> definitely point out that platform dependency in the config description
> -- I have to look elsewhere in the patchset to determine that this is
> for "Power Hypervisor". PPC_HAVE_PMU_SUPPORT is enabled by all 6xx
> builds, even for hardware like e300 that doesn't have PMU at all (it has
> the FSL embedded perfmon instead), much less this hv interface.
>
> And yes, PPC_PERF_CTRS has the same problem and should be fixed. :-)
Yep, I just based this one on what PPC_PERF_CTRS was doing.
How about the following:
+config HV_PERF_CTRS
+ bool "Perf Hypervisor supplied counters"
+ default y
+ depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT && PPC_PSERIES
+ help
+ Enable access to hypervisor supplied counters in perf. Currently,
+ this enables code that uses the hcall GetPerfCounterInfo and 24x7
+ interfaces to retrieve counters. GPCI exists on Power 6 and later
+ systems. 24x7 is available on Power 8 systems.
+
+ If unsure, select Y.
And relocated to arch/powerpc/platforms/Kconfig (as this isn't really
strictly "cputype" related).
^ permalink raw reply
* Re: [PATCH 1/6] PCI, acpiphp: Use list_for_each_entry() for bus traversal
From: Yijing Wang @ 2014-02-15 0:49 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Russell King, David Airlie, linux-pcmcia, Hanjun Guo, dri-devel,
linux-pci, Bjorn Helgaas, linuxppc-dev
In-Reply-To: <2512180.zyEb2tzySd@vostro.rjw.lan>
>>> Does it conflict with anything currently in linux-next (the linux-next branch
>>> of linux-pm.git in particular)?
>>
>> Hi Rafael,
>> I applied this to your linux-next branch successfully . No conflicts found.
>
> Good. :-)
>
> Please feel free to add my ACK to it.
Thanks very much!
^ permalink raw reply
* Re: [PATCH 1/6] PCI, acpiphp: Use list_for_each_entry() for bus traversal
From: Yijing Wang @ 2014-02-15 0:52 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Russell King, David Airlie, linux-pcmcia, Hanjun Guo, dri-devel,
linux-pci, linuxppc-dev
In-Reply-To: <20140214182316.GB31093@google.com>
On 2014/2/15 2:23, Bjorn Helgaas wrote:
> On Thu, Feb 13, 2014 at 09:13:58PM +0800, Yijing Wang wrote:
>> Replace list_for_each() + pci_bus_b() with the simpler
>> list_for_each_entry().
>>
>> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>
> I applied all six of these (please include a 0/6 cover letter in the
> future; that's a nice place to note that I applied things) to
> pci/list-for-each-entry for v3.15, thanks!
Thanks, I will add cover letter in the next time, sorry.
>
>> ---
>> drivers/pci/hotplug/acpiphp_glue.c | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
>> index cd929ae..aee6a0a 100644
>> --- a/drivers/pci/hotplug/acpiphp_glue.c
>> +++ b/drivers/pci/hotplug/acpiphp_glue.c
>> @@ -450,7 +450,7 @@ static void cleanup_bridge(struct acpiphp_bridge *bridge)
>> */
>> static unsigned char acpiphp_max_busnr(struct pci_bus *bus)
>> {
>> - struct list_head *tmp;
>> + struct pci_bus *tmp;
>> unsigned char max, n;
>>
>> /*
>> @@ -463,8 +463,8 @@ static unsigned char acpiphp_max_busnr(struct pci_bus *bus)
>> */
>> max = bus->busn_res.start;
>>
>> - list_for_each(tmp, &bus->children) {
>> - n = pci_bus_max_busnr(pci_bus_b(tmp));
>> + list_for_each_entry(tmp, &bus->children, node) {
>> + n = pci_bus_max_busnr(tmp);
>> if (n > max)
>> max = n;
>> }
>> --
>> 1.7.1
>>
>>
>
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH 2/2] of: search the best compatible match first in __of_match_node()
From: Stephen N Chivers @ 2014-02-15 5:19 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Kevin Hao, Chris Proctor,
Stephen N Chivers, Kumar Gala, Grant Likely, linuxppc-dev,
Sebastian Hesselbarth
In-Reply-To: <CAL_JsqKq4_1K8EF+PZoP=0=H6tiRxbgdzs9UHHVdbHS014n74Q@mail.gmail.com>
Rob Herring <robherring2@gmail.com> wrote on 02/15/2014 02:53:40 AM:
> From: Rob Herring <robherring2@gmail.com>
> To: Kevin Hao <haokexin@gmail.com>
> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
> linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, Sebastian Hesselbarth
> <sebastian.hesselbarth@gmail.com>, Stephen N Chivers
> <schivers@csc.com.au>, Grant Likely <grant.likely@linaro.org>, Rob
> Herring <robh+dt@kernel.org>, Kumar Gala <galak@codeaurora.org>
> Date: 02/15/2014 02:53 AM
> Subject: Re: [PATCH 2/2] of: search the best compatible match first
> in __of_match_node()
>
> On Thu, Feb 13, 2014 at 11:22 PM, Kevin Hao <haokexin@gmail.com> wrote:
> > Currently, of_match_node compares each given match against all node's
> > compatible strings with of_device_is_compatible.
> >
> > To achieve multiple compatible strings per node with ordering from
> > specific to generic, this requires given matches to be ordered from
> > specific to generic. For most of the drivers this is not true and also
> > an alphabetical ordering is more sane there.
> >
> > Therefore, this patch introduces a function to match each of the
node's
> > compatible strings against all given compatible matches without type
and
> > name first, before checking the next compatible string. This implies
> > that node's compatibles are ordered from specific to generic while
> > given matches can be in any order. If we fail to find such a match
> > entry, then fall-back to the old method in order to keep
compatibility.
> >
> > Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> > Signed-off-by: Kevin Hao <haokexin@gmail.com>
>
> Looks good to me. I'll put this in next for a few days. I'd really
> like to see some acks and tested-by's before sending to Linus.
>
Tested-by: Stephen Chivers <schivers@csc.com>
I have tested the patch for the four PowerPC platforms
available to me.
They are:
MPC8349_MITXGP - Works.
MVME5100 - Works.
MVME4100 - Works.
SAM440EP - Works.
The MPC8349_MITXGP platform is present in Linux-3.13 and previous
releases.
The MVME5100 is a "revived" platform that is in Linux-3.14-rc2.
The MVME4100 is a work in progress and is the 85xx platform that the
original failure report was for.
The SAM440EP is present in Linux-3.13 and previous releases.
The MPC8349_MITXGP is one of the 49 DTS files with the serial compatible:
compatible = "fsl,ns16550", "ns16550";
For the SAM440EP, the patch improves things from Linux-3.13. In that
release the same sort of problem as reported in:
"Linux-3.14-rc2: Order of serial node compatibles in DTS files."
occurs with slightly different symptoms:
of_serial ef600300.serial: Port found
of_serial ef600300.serial: Port found
of_serial ef600300.serial: Unknown serial port found, ignored
of_serial ef600400.serial: Port found
of_serial ef600400.serial: Port found
of_serial ef600400.serial: Unknown serial port found, ignored
of_serial ef600500.serial: Port found
of_serial ef600500.serial: Port found
of_serial ef600500.serial: Unknown serial port found, ignored
of_serial ef600600.serial: Port found
of_serial ef600600.serial: Port found
of_serial ef600600.serial: Unknown serial port found, ignored
The SAM440EP has a IBM/AMCC 440EP PowerPC CPU and so simply has
"ns16550" as its serial compatible.
> We could be a bit more strict here and fallback to the old matching if
> the match table has any entries with name or type. I don't think that
> should be necessary though.
>
> Rob
Stephen Chivers,
CSC Australia Pty. Ltd.
>
> > ---
> > drivers/of/base.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index ba195fbce4c6..10b51106c854 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -730,13 +730,49 @@ out:
> > }
> > EXPORT_SYMBOL(of_find_node_with_property);
> >
> > +static const struct of_device_id *
> > +of_match_compatible(const struct of_device_id *matches,
> > + const struct device_node *node)
> > +{
> > + const char *cp;
> > + int cplen, l;
> > + const struct of_device_id *m;
> > +
> > + cp = __of_get_property(node, "compatible", &cplen);
> > + while (cp && (cplen > 0)) {
> > + m = matches;
> > + while (m->name[0] || m->type[0] || m->compatible[0]) {
> > + /* Only match for the entries without type
> and name */
> > + if (m->name[0] || m->type[0] ||
> > + of_compat_cmp(m->compatible, cp,
> > + strlen(m->compatible)))
> > + m++;
> > + else
> > + return m;
> > + }
> > +
> > + /* Get node's next compatible string */
> > + l = strlen(cp) + 1;
> > + cp += l;
> > + cplen -= l;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > static
> > const struct of_device_id *__of_match_node(const struct
> of_device_id *matches,
> > const struct device_node
*node)
> > {
> > + const struct of_device_id *m;
> > +
> > if (!matches)
> > return NULL;
> >
> > + m = of_match_compatible(matches, node);
> > + if (m)
> > + return m;
> > +
> > while (matches->name[0] || matches->type[0] ||
> matches->compatible[0]) {
> > int match = 1;
> > if (matches->name[0])
> > @@ -760,7 +796,12 @@ const struct of_device_id *__of_match_node
> (const struct of_device_id *matches,
> > * @matches: array of of device match structures to search
in
> > * @node: the of device structure to match against
> > *
> > - * Low level utility function used by device matching.
> > + * Low level utility function used by device matching. We have
two ways
> > + * of matching:
> > + * - Try to find the best compatible match by comparing each
compatible
> > + * string of device node with all the given matches
respectively.
> > + * - If the above method failed, then try to match the
> compatible by using
> > + * __of_device_is_compatible() besides the match in type and
name.
> > */
> > const struct of_device_id *of_match_node(const struct
> of_device_id *matches,
> > const struct device_node
*node)
> > --
> > 1.8.5.3
> >
^ permalink raw reply
* PCI-PCI bridge configuration in linux device tree
From: Anand Mistry @ 2014-02-15 12:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Hello,
We are working on a cPCI based application involving MPC8313 processor. The
cPCI back-plane has a PCI-PCI bridge on it.
While booting, the linux kernel(2.6.23) crashes while allocating resources for
devices
beyong the bridge. After examination we came to know that if we program the
PCI-PCI bridge's memory windows in u-boot (memory base and limit registers
manually using u-boot commands), the kernel won't crash and allocate resources.
Our understanding is that programming of PCI-PCI bridges's memory windows
should be done automatically either by u-boot or by linux during boot (not
considering hot-swap right now) and no special driver is required for PCI-PCI
bridges.
Is our understanding correct? Can somebody help us find out the way to achieve
automatic configuration of PCI-PCI bridge memory windows for resource allocation?
Attachments,
log_pci_bridge.txt : kernel crash log
pci_dts.txt : PCI config part of the DTS file
Thanks and Regards,
Anand Mistry,
Spectross Digital Systems, New Delhi
[-- Attachment #2: pci_dts.txt --]
[-- Type: text/plain, Size: 895 bytes --]
pci@8500 { // sds-am : controller card config only
bus-range = <0 0>;
ranges = <02000000 0 90000000 90000000 0 10000000
42000000 0 80000000 80000000 0 10000000
01000000 0 00000000 e2000000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
compatible = "fsl,mpc8349-pci";
device_type = "pci";
interrupt-parent = < &ipic >;
interrupts = <42 8>;
interrupt-map-mask = <0F800 0 0 7>;
interrupt-map = <
// ** For reference **
// INTA = IRQ1 = 0x11
// INTB = IRQ2 = 0x12
// INTC = IRQ0 = 0x30
// INTD = IRQ4 = 0x14
// BUS 0 IDSEL 0x18 (IDSEL = AD24)
0c000 0 0 1 &ipic 11 8 // PCI_INTA
0c000 0 0 2 &ipic 12 8 // PCI_INTB slot 13 i guess
0c000 0 0 3 &ipic 30 8 // PCI_INTC slot 14 i guess
0c000 0 0 4 &ipic 14 8 // PCI_INTD slot 15 i guess
>;
};
[-- Attachment #3: log_pci_bridge.txt --]
[-- Type: text/plain, Size: 10346 bytes --]
Booting using the fdt at 0x400000
[ 0.000000] -> early_init_devtree(c0400000)
[ 0.000000] search "chosen", depth: 0, uname:
[ 0.000000] search "chosen", depth: 1, uname: chosen
[ 0.000000] Looking for initrd properties... <3>initrd_start=0x0 initrd_end=0x0
[ 0.000000] Command line is: root=/dev/nfs rw nfsroot=192.168.1.11:/nfs/rootfs/fce_test ip=192.168.1.111:192.168.1.11:192.168.1.1:255.255.255.0:mpc8313erdb:eth0:off panic=1 loglevel=7
[ 0.000000] dt_root_size_cells = 1
[ 0.000000] dt_root_addr_cells = 1
[ 0.000000] memory scan node memory, reg size 8, data: 0 10000000 2 1,
[ 0.000000] - 0 , 10000000
[ 0.000000] Phys. mem: 10000000
[ 0.000000] -> move_device_tree
[ 0.000000] <- move_device_tree
[ 0.000000] Scanning CPUs ...
[ 0.000000] boot cpu: logical 0 physical 0
[ 0.000000] <- early_init_devtree()
[ 0.000000] Using MPC8313 RDB machine description
[ 0.000000] Linux version 2.6.23-gd2c719c0-dirty (anand@anand-desktop) (gcc version 4.2.2) #32 Wed Feb 5 18:50:03 IST 2014
[ 0.000000] -> unflatten_device_tree()
[ 0.000000] size is f44, allocating...
[ 0.000000] unflattening cffff0b8...
[ 0.000000] fixed up name for ->
[ 0.000000] fixed up name for chosen -> chosen
[ 0.000000] fixed up name for cpus -> cpus
[ 0.000000] fixed up name for PowerPC,8313@0 -> PowerPC,8313
[ 0.000000] fixed up name for memory -> memory
[ 0.000000] fixed up name for nand@e2800000 -> nand
[ 0.000000] fixed up name for soc8313@e0000000 -> soc8313
[ 0.000000] fixed up name for wdt@200 -> wdt
[ 0.000000] fixed up name for usb@23000 -> usb
[ 0.000000] fixed up name for mdio@24520 -> mdio
[ 0.000000] fixed up name for ethernet-phy@1 -> ethernet-phy
[ 0.000000] fixed up name for ptimer@24e00 -> ptimer
[ 0.000000] fixed up name for ethernet@24000 -> ethernet
[ 0.000000] fixed up name for serial@4500 -> serial
[ 0.000000] fixed up name for pci@8500 -> pci
[ 0.000000] fixed up name for pic@700 -> pic
[ 0.000000] fixed up name for elbc@5000 -> elbc
[ 0.000000] fixed up name for power@b00 -> power
[ 0.000000] fixed up name for timer@500 -> timer
[ 0.000000] <- unflatten_device_tree()
[ 0.000000] console [udbg0] enabled
setup_arch: bootmem
mpc8313_rdb_setup_arch()
[ 0.000000] Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->2
[ 0.000000] PCI: MEM[0] 0x90000000 -> 0x9fffffff
[ 0.000000] PCI: MEM[1] 0x80000000 -> 0x8fffffff
[ 0.000000] PCI: IO 0x0 -> 0xfffff
arch: exit
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 65536
[ 0.000000] Normal 65536 -> 65536
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 65536
[ 0.000000] Built 1 zonelists in Zone order. Total pages: 65024
[ 0.000000] Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.11:/nfs/rootfs/fce_test ip=192.168.1.111:192.168.1.11:192.168.1.1:255.255.255.0:mpc8313erdb:eth0:off panic=1 loglevel=7
[ 0.000000] IPIC (128 IRQ sources) at fdef9700
[ 0.000000] PID hash table entries: 1024 (order: 10, 4096 bytes)
[ 0.001092] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.009919] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.049138] Memory: 256256k/262144k available (3112k kernel code, 5644k reserved, 140k data, 93k bss, 152k init)
[ 0.144303] Mount-cache hash table entries: 512
[ 0.152429] NET: Registered protocol family 16
[ 0.159856] of_irq_map_raw: par=/soc8313@e0000000/pic@700,intspec=[0x00000026 0x00000008...],ointsize=2
[ 0.169145] of_irq_map_raw: ipar=/soc8313@e0000000/pic@700, size=2
[ 0.175221] -> addrsize=0
[ 0.177893] -> got it !, intspec=26
[ 0.181573] #### arch/powerpc/kernel/prom_parse.c:1049 irq=38
[ 0.187501] of_irq_map_raw: par=/soc8313@e0000000/pic@700,intspec=[0x00000020 0x00000008...],ointsize=2
[ 0.196764] of_irq_map_raw: ipar=/soc8313@e0000000/pic@700, size=2
[ 0.202859] -> addrsize=0
[ 0.205537] -> got it !, intspec=20
[ 0.209211] #### arch/powerpc/kernel/prom_parse.c:1049 irq=32
[ 0.214894] of_irq_map_raw: par=/soc8313@e0000000/pic@700,intspec=[0x00000021 0x00000008...],ointsize=2
[ 0.224221] of_irq_map_raw: ipar=/soc8313@e0000000/pic@700, size=2
[ 0.230334] -> addrsize=0
[ 0.233012] -> got it !, intspec=21
[ 0.236679] #### arch/powerpc/kernel/prom_parse.c:1049 irq=33
[ 0.242368] of_irq_map_raw: par=/soc8313@e0000000/pic@700,intspec=[0x00000022 0x00000008...],ointsize=2
[ 0.251689] of_irq_map_raw: ipar=/soc8313@e0000000/pic@700, size=2
[ 0.257817] -> addrsize=0
[ 0.260487] -> got it !, intspec=22
[ 0.264153] #### arch/powerpc/kernel/prom_parse.c:1049 irq=34
[ 0.270088] of_irq_map_raw: par=/soc8313@e0000000/pic@700,intspec=[0x00000014 0x00000008...],ointsize=2
[ 0.279342] of_irq_map_raw: ipar=/soc8313@e0000000/pic@700, size=2
[ 0.285452] -> addrsize=0
[ 0.288123] -> got it !, intspec=14
[ 0.291868] of_irq_map_raw: par=/soc8313@e0000000/pic@700,intspec=[0x0000004d 0x00000008...],ointsize=2
[ 0.301125] of_irq_map_raw: ipar=/soc8313@e0000000/pic@700, size=2
[ 0.307220] -> addrsize=0
[ 0.309899] -> got it !, intspec=4d
[ 0.313823] PCI: Probing PCI hardware
[ 0.317924] pci_busdev_to_OF_node(0,0xc0)
[ 0.321801] scan_OF_for_pci_bus
[ 0.324934] parent is /soc8313@e0000000/pci@8500
[ 0.329561] scan_OF_for_pci_dev, devfn = c0
[ 0.333700] not found
[ 0.335923] result is <NULL>
[ 0.339565] pci_busdev_to_OF_node(1,0x48)
[ 0.343441] scan_OF_for_pci_bus
[ 0.346543] scan_OF_for_pci_bus
[ 0.349646] scan_OF_for_pci_dev, devfn = c0
[ 0.353786] not found
[ 0.356032] no parent found
[ 0.358867] pci_busdev_to_OF_node(1,0x58)
[ 0.362860] scan_OF_for_pci_bus
[ 0.365967] scan_OF_for_pci_bus
[ 0.369080] scan_OF_for_pci_dev, devfn = c0
[ 0.373225] not found
[ 0.375447] no parent found
[ 0.378329] pci_busdev_to_OF_node(0,0xc0)
[ 0.382299] scan_OF_for_pci_bus
[ 0.385409] parent is /soc8313@e0000000/pci@8500
[ 0.390075] scan_OF_for_pci_dev, devfn = c0
[ 0.394220] not found
[ 0.396469] result is <NULL>
[ 0.399388] of_irq_map_raw: par=/soc8313@e0000000/pci@8500,intspec=[0x00000004 0x0000c000...],ointsize=1
[ 0.408846] of_irq_map_raw: ipar=/soc8313@e0000000/pci@8500, size=1
[ 0.415048] -> addrsize=3
[ 0.417735] -> match=0 (imaplen=24)
[ 0.421277] -> newintsize=2, newaddrsize=0
[ 0.425412] -> imaplen=21
[ 0.428092] -> match=0 (imaplen=17)
[ 0.431612] -> newintsize=2, newaddrsize=0
[ 0.435780] -> imaplen=14
[ 0.438460] -> match=0 (imaplen=10)
[ 0.442006] -> newintsize=2, newaddrsize=0
[ 0.446148] -> imaplen=7
[ 0.448742] -> match=1 (imaplen=3)
[ 0.452201] -> newintsize=2, newaddrsize=0
[ 0.456342] -> imaplen=0
[ 0.458912] -> new parent: /soc8313@e0000000/pic@700
[ 0.463949] -> got it !, intspec=14
[ 0.468294] pci_busdev_to_OF_node(2,0x60)
[ 0.472182] scan_OF_for_pci_bus
[ 0.475231] scan_OF_for_pci_bus
[ 0.478370] scan_OF_for_pci_bus
[ 0.481479] scan_OF_for_pci_dev, devfn = c0
[ 0.485625] not found
[ 0.487847] no parent found
[ 0.490730] pci_busdev_to_OF_node(1,0x48)
[ 0.494698] scan_OF_for_pci_bus
[ 0.497806] scan_OF_for_pci_bus
[ 0.500919] scan_OF_for_pci_dev, devfn = c0
[ 0.505064] not found
[ 0.507286] no parent found
[ 0.510165] pci_busdev_to_OF_node(0,0xc0)
[ 0.514136] scan_OF_for_pci_bus
[ 0.517248] parent is /soc8313@e0000000/pci@8500
[ 0.521914] scan_OF_for_pci_dev, devfn = c0
[ 0.526059] not found
[ 0.528307] result is <NULL>
[ 0.531226] of_irq_map_raw: par=/soc8313@e0000000/pci@8500,intspec=[0x00000002 0x0000c000...],ointsize=1
[ 0.540685] of_irq_map_raw: ipar=/soc8313@e0000000/pci@8500, size=1
[ 0.546887] -> addrsize=3
[ 0.549574] -> match=0 (imaplen=24)
[ 0.553115] -> newintsize=2, newaddrsize=0
[ 0.557251] -> imaplen=21
[ 0.559906] -> match=1 (imaplen=17)
[ 0.563476] -> newintsize=2, newaddrsize=0
[ 0.567619] -> imaplen=14
[ 0.570297] -> new parent: /soc8313@e0000000/pic@700
[ 0.575312] -> got it !, intspec=12
[ 0.581054] PCI->OF bus map:
[ 0.583763] 0 -> 0
[ 0.585819] PCI: bridge rsrc 0..fffff (100), parent c030f44c
[ 0.591403] PCI: bridge rsrc 90000000..9fffffff (200), parent c030f430
[ 0.597884] PCI: bridge rsrc 80000000..8fffffff (1200), parent c030f430
[ 0.604490] PCI:0000:01:0b.0: Resource 0: 0000000000000000-0000000000001fff (f=200)
[ 0.612059] PCI: Cannot allocate resource region 0 of device 0000:01:0b.0
[ 0.618795] PCI:0000:02:0c.0: Resource 0: 0000000000000000-0000000000001fff (f=200)
[ 0.626400] PCI: Cannot allocate resource region 0 of device 0000:02:0c.0
[ 0.656430] PCI: Failed to allocate mem resource #0:2000@0 for 0000:01:0b.0
[ 0.663368] ------------[ cut here ]------------
[ 0.667918] kernel BUG at arch/powerpc/kernel/pci_32.c:589!
[ 0.673451] Oops: Exception in kernel mode, sig: 5 [#1]
[ 0.678627] MPC8313 RDB
[ 0.681046] Modules linked in:
[ 0.684075] NIP: c02eeb48 LR: c02eeb48 CTR: c000ffe4
[ 0.689002] REGS: cffc1e80 TRAP: 0700 Not tainted (2.6.23-gd2c719c0-dirty)
[ 0.696080] MSR: 00029032 <EE,ME,IR,DR> CR: 22044022 XER: 00000000
[ 0.702392] TASK = cffe0ba0[1] 'swapper' THREAD: cffc0000
[ 0.707572] GPR00: c02eeb48 cffc1f30 cffe0ba0 fffffff4 00002931 ffffffff 00004000 00002931
[ 0.715866] GPR08: 00000033 c0330000 00002931 fdffe505 42044022 3b063644 c0298b90 c0298b80
[ 0.724161] GPR16: c0298bdc cffc1f98 c0298bc4 c0306e28 c0298bf0 c0298c04 c0300000 00000000
[ 0.732455] GPR24: c0330000 c0330000 c0330000 c032c24c c0334c4c cffea000 00000000 cffea000
[ 0.740922] Call Trace:
[ 0.743344] [cffc1f30] [c02eeb48] (unreliable)
[ 0.747836] [cffc1f60] [c02e41f4]
[ 0.751205] [cffc1ff0] [c000fec4]
[ 0.754573] Instruction dump:
[ 0.757512] 2f800000 419e0018 7c0903a6 4e800421 2f830000 409e0020 813f01a4 552000c2
[ 0.765200] 7fa3eb78 901f01a4 7fc4f378 4be62d6d <0f030000> 2f9e0005 3bff001c 3bde0001
[ 0.773069] Kernel panic - not syncing: Attempted to kill init!
[ 0.778940] Rebooting in 1 seconds..
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error
From: Guenter Roeck @ 2014-02-15 18:02 UTC (permalink / raw)
To: Stephen Rothwell, Benjamin Herrenschmidt
Cc: Mahesh J Salgaonkar, linux-next, Paul Mackerras, Linux Kernel,
linuxppc-dev
In-Reply-To: <20140212162251.57472ed024ace170b49ec2fa@canb.auug.org.au>
On 02/11/2014 09:22 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 10 Dec 2013 10:26:10 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>
>> On Tue, 2013-12-10 at 10:10 +1100, Stephen Rothwell wrote:
>>> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>
>>> Works for me. Thanks. I will add this to linux-next today if Ben
>>> doesn't add it to his tree.
>>
>> I will but probably not soon enough for your cut today
>
> As noted elsewhere, this did not completely fix the problem and I have
> been still getting this error from my allyesconfig builds for some time:
>
+allmodconfig in latest mainline.
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
>
> Could someone please fix this?
>
Guenter
^ permalink raw reply
* Re: [PATCH v2 03/11] sysfs: create bin_attributes under the requested group
From: Greg Kroah-Hartman @ 2014-02-15 20:15 UTC (permalink / raw)
To: Cody P Schafer
Cc: Peter Zijlstra, LKML, Michael Ellerman, Ingo Molnar,
Paul Mackerras, Arnaldo Carvalho de Melo, Linux PPC
In-Reply-To: <1392415338-16288-4-git-send-email-cody@linux.vnet.ibm.com>
On Fri, Feb 14, 2014 at 02:02:07PM -0800, Cody P Schafer wrote:
> bin_attributes created/updated in create_files() (such as those listed
> via (struct device).attribute_groups) were not placed under the
> specified group, and instead appeared in the base kobj directory.
>
> Fix this by making bin_attributes use creating code similar to normal
> attributes.
>
> A quick grep shows that no one is using bin_attrs in a named attribute
> group yet, so we can do this without breaking anything in usespace.
>
> Note that I do not add is_visible() support to
> bin_attributes, though that could be done as well.
is_visible() support would be nice to add if you get a chance.
thanks,
greg k-h
^ permalink raw reply
* Re: Anyone using SysRQ key sequences on console serial port ?
From: Paul Gortmaker @ 2014-02-16 15:56 UTC (permalink / raw)
To: John Donnelly; +Cc: linuxppc-dev
In-Reply-To: <CAGtOQbTRSk32p7U=v9V9GPb_ro+WYbKLLCCfrmdypePcHA++mw@mail.gmail.com>
On Fri, Feb 14, 2014 at 3:42 PM, John Donnelly <john.d@servergy.com> wrote:
> Hi,
>
> I tried using the SysRq hotkey sequence on a serial console -
> 3.11.0-5-powerpc-e500mc system, by issuing a " break " and the system
> immediately wedges after displaying "SysRQ : HELP : " using both "Putty" and
> "Teraterm" terminal emulators. I know the system is dead because my ssh
> sessions stopped too.
Yes it does work -- or at least it _did_ work. Make sure your dts has an entry
compatible = "fsl,ns16550", "ns16550";
since that enables a workaround I'd added for a hardware errata relating
to sending breaks over the serial console. What you describe above
makes me think you aren't getting the workaround enabled.
Paul.
--
>
> http://en.wikipedia.org/wiki/Magic_SysRq_key .
>
>
>
>
> --
>
> Regards,
> John.
>
> --
>
> o Energy-efficiency is #1 reason data centers look to expand. -- Digital
> Realty Trust
> o Green Data Centers spending to increase 300% worldwide by 2016. -- Pike
> Research
> o Data Centers have become as vital to the functioni
> ng of society as power stations. -- The Economist
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/pseries: Report in kernel device tree update to drmgr
From: Benjamin Herrenschmidt @ 2014-02-17 0:22 UTC (permalink / raw)
To: Tyrel Datwyler; +Cc: nfont, linuxppc-dev
In-Reply-To: <1391212692-16217-4-git-send-email-tyreld@linux.vnet.ibm.com>
On Fri, 2014-01-31 at 15:58 -0800, Tyrel Datwyler wrote:
> Traditionally it has been drmgr's responsibilty to update the device tree
> through the /proc/ppc64/ofdt interface after a suspend/resume operation.
> This patchset however has modified suspend/resume ops to preform that update
> entirely in the kernel during the resume. Therefore, a mechanism is required
> for drmgr to determine who is responsible for the update. This patch adds a
> show function to the "hibernate" attribute that returns 1 if the kernel
> updates the device tree after the resume and 0 if drmgr is responsible.
This is not right.
We cannot change the kernel behaviour in a way that is incompatible with
existing userspace, and unless you can explain me why that is not the
case, it feels like this patch set does just that ....
What happens if you have an older drmgr which still does the update
itself ?
You can't just change user visible behaviours and interface without at
least explaining why it's ok to do so at the very least (and ensuring
that of course) without breaking existing userspace.
Now it's possible that the double update caused by this series is
harmless, in which case please explain it in the changeset, I certainly
can't assume it and if it's not, you'll need some other way for drmgr to
signal the kernel to indicate it supports the new behaviour before you
enable it.
Ben.
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/suspend.c | 25 ++++++++++++++++++++++++-
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/suspend.c b/arch/powerpc/platforms/pseries/suspend.c
> index 1d9c580..b87b978 100644
> --- a/arch/powerpc/platforms/pseries/suspend.c
> +++ b/arch/powerpc/platforms/pseries/suspend.c
> @@ -192,7 +192,30 @@ out:
> return rc;
> }
>
> -static DEVICE_ATTR(hibernate, S_IWUSR, NULL, store_hibernate);
> +#define USER_DT_UPDATE 0
> +#define KERN_DT_UPDATE 1
> +
> +/**
> + * show_hibernate - Report device tree update responsibilty
> + * @dev: subsys root device
> + * @attr: device attribute struct
> + * @buf: buffer
> + *
> + * Report whether a device tree update is performed by the kernel after a
> + * resume, or if drmgr must coordinate the update from user space.
> + *
> + * Return value:
> + * 0 if drmgr is to initiate update, and 1 otherwise
> + **/
> +static ssize_t show_hibernate(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%d\n", KERN_DT_UPDATE);
> +}
> +
> +static DEVICE_ATTR(hibernate, S_IWUSR | S_IRUGO,
> + show_hibernate, store_hibernate);
>
> static struct bus_type suspend_subsys = {
> .name = "power",
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2014-02-17 1:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are some more powerpc fixes for 3.14
The main one is a nasty issue with the NUMA balancing support
which requires a small generic change and the addition of a new
accessor to set _PAGE_NUMA. Both have been reviewed and acked by
Mel and Rik.
The changelog should have plenty of details but basically,
without this fix, we get random user segfaults and/or
corruptions due to missing TLB/hash flushes. Aneesh series
of 3 patches fixes it.
We have some vDSO vs. perf fixes from Anton, some small EEH
fixes from Gavin, a ppc32 regression vs. the stack overflow
detector, and a fix for the way we handle PCIe host bridge
speed settings on pseries (which is needed for proper
operations of AMD graphics cards on Power8).
Cheers,
Ben.
The following changes since commit cd15b048445d0a54f7147c35a86c5a16ef231554:
powerpc/powernv: Add iommu DMA bypass support for IODA2 (2014-02-11 16:07:37 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to 66f9af83e56bfa12964d251df9d60fb571579913:
powerpc/eeh: Disable EEH on reboot (2014-02-17 11:19:39 +1100)
----------------------------------------------------------------
Aneesh Kumar K.V (3):
powerpc/mm: Add new "set" flag argument to pte/pmd update function
mm: Dirty accountable change only apply to non prot numa case
mm: Use ptep/pmdp_set_numa() for updating _PAGE_NUMA bit
Anton Blanchard (2):
powerpc: Link VDSOs at 0x0
powerpc: Use unstripped VDSO image for more accurate profiling data
Gavin Shan (3):
powerpc/powernv: Rework EEH reset
powerpc/eeh: Cleanup on eeh_subsystem_enabled
powerpc/eeh: Disable EEH on reboot
Kevin Hao (1):
powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack
Kleber Sacilotto de Souza (2):
powerpc/pseries: Fix regression on PCI link speed
powerpc/pseries: Add Gen3 definitions for PCIE link speed
arch/powerpc/include/asm/eeh.h | 21 +++++++++++++--
arch/powerpc/include/asm/hugetlb.h | 2 +-
arch/powerpc/include/asm/pgtable-ppc64.h | 26 +++++++++++--------
arch/powerpc/include/asm/pgtable.h | 22 ++++++++++++++++
arch/powerpc/include/asm/vdso.h | 6 ++---
arch/powerpc/kernel/eeh.c | 32 ++++++++++++++++++-----
arch/powerpc/kernel/misc_32.S | 5 +++-
arch/powerpc/kernel/vdso32/vdso32_wrapper.S | 2 +-
arch/powerpc/kernel/vdso64/vdso64_wrapper.S | 2 +-
arch/powerpc/mm/pgtable_64.c | 12 +++++----
arch/powerpc/mm/subpage-prot.c | 2 +-
arch/powerpc/platforms/powernv/eeh-ioda.c | 32 +++++------------------
arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
arch/powerpc/platforms/pseries/eeh_pseries.c | 2 +-
arch/powerpc/platforms/pseries/pci.c | 22 +++++++++++-----
include/asm-generic/pgtable.h | 39 ++++++++++++++++++++++++++++
mm/huge_memory.c | 9 ++-----
mm/mprotect.c | 25 ++++++------------
18 files changed, 172 insertions(+), 91 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
From: Joonsoo Kim @ 2014-02-17 6:52 UTC (permalink / raw)
To: Christoph Lameter
Cc: Han Pingtian, Nishanth Aravamudan, Matt Mackall, Pekka Enberg,
Linux Memory Management List, Paul Mackerras, Anton Blanchard,
David Rientjes, linuxppc-dev, Wanpeng Li
In-Reply-To: <alpine.DEB.2.10.1402121612270.8183@nuc>
On Wed, Feb 12, 2014 at 04:16:11PM -0600, Christoph Lameter wrote:
> Here is another patch with some fixes. The additional logic is only
> compiled in if CONFIG_HAVE_MEMORYLESS_NODES is set.
>
> Subject: slub: Memoryless node support
>
> Support memoryless nodes by tracking which allocations are failing.
I still don't understand why this tracking is needed.
All we need for allcation targeted to memoryless node is to fallback proper
node, that it, numa_mem_id() node of targeted node. My previous patch
implements it and use proper fallback node on every allocation code path.
Why this tracking is needed? Please elaborate more on this.
> Allocations targeted to the nodes without memory fall back to the
> current available per cpu objects and if that is not available will
> create a new slab using the page allocator to fallback from the
> memoryless node to some other node.
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
>
> @@ -1722,7 +1738,7 @@ static void *get_partial(struct kmem_cac
> struct kmem_cache_cpu *c)
> {
> void *object;
> - int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
> + int searchnode = (node == NUMA_NO_NODE) ? numa_mem_id() : node;
>
> object = get_partial_node(s, get_node(s, searchnode), c, flags);
> if (object || node != NUMA_NO_NODE)
This isn't enough.
Consider that allcation targeted to memoryless node.
get_partial_node() always fails even if there are some partial slab on
memoryless node's neareast node.
We should fallback to some proper node in this case, since there is no slab
on memoryless node.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node
From: Joonsoo Kim @ 2014-02-17 7:00 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Han Pingtian, Matt Mackall, Pekka Enberg,
Linux Memory Management List, Paul Mackerras, Anton Blanchard,
David Rientjes, Christoph Lameter, linuxppc-dev, Wanpeng Li
In-Reply-To: <20140213065137.GA10860@linux.vnet.ibm.com>
On Wed, Feb 12, 2014 at 10:51:37PM -0800, Nishanth Aravamudan wrote:
> Hi Joonsoo,
> Also, given that only ia64 and (hopefuly soon) ppc64 can set
> CONFIG_HAVE_MEMORYLESS_NODES, does that mean x86_64 can't have
> memoryless nodes present? Even with fakenuma? Just curious.
I don't know, because I'm not expert on NUMA system :)
At first glance, fakenuma can't be used for testing
CONFIG_HAVE_MEMORYLESS_NODES. Maybe some modification is needed.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 10/11] powerpc/perf: add kconfig option for hypervisor provided counters
From: Michael Ellerman @ 2014-02-17 7:11 UTC (permalink / raw)
To: Cody P Schafer
Cc: Paul Bolle, Peter Zijlstra, Priyanka Jain, LKML, Tang Yuantian,
Ingo Molnar, Paul Mackerras, Aneesh Kumar K.V,
Arnaldo Carvalho de Melo, Scott Wood, Lijun Pan, Linux PPC,
Anton Blanchard, Anshuman Khandual
In-Reply-To: <20140215002505.GA2991@negative>
On Fri, 2014-02-14 at 16:25 -0800, Cody P Schafer wrote:
> On Fri, Feb 14, 2014 at 04:32:13PM -0600, Scott Wood wrote:
> > On Fri, 2014-02-14 at 14:02 -0800, Cody P Schafer wrote:
> > > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> > > index 434fda3..dcc67cd 100644
> > > --- a/arch/powerpc/platforms/Kconfig.cputype
> > > +++ b/arch/powerpc/platforms/Kconfig.cputype
> > > @@ -364,6 +364,12 @@ config PPC_PERF_CTRS
> > > help
> > > This enables the powerpc-specific perf_event back-end.
> > >
> > > +config HV_PERF_CTRS
> > > + def_bool y
> > > + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT
> > > + help
> > > + Enable access to perf counters provided by the hypervisor
> >
> > Please don't add default-y stuff that is platform-specific, and
> > definitely point out that platform dependency in the config description
> > -- I have to look elsewhere in the patchset to determine that this is
> > for "Power Hypervisor". PPC_HAVE_PMU_SUPPORT is enabled by all 6xx
> > builds, even for hardware like e300 that doesn't have PMU at all (it has
> > the FSL embedded perfmon instead), much less this hv interface.
> >
> > And yes, PPC_PERF_CTRS has the same problem and should be fixed. :-)
>
> Yep, I just based this one on what PPC_PERF_CTRS was doing.
>
> How about the following:
>
> +config HV_PERF_CTRS
> + bool "Perf Hypervisor supplied counters"
"Support for Hypervisor supplied PMU events (24x7 & GPCI)" ?
> + default y
> + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT && PPC_PSERIES
I think you just want:
depends on PERF_EVENTS && PPC_PSERIES
Because you're adding two completely new PMUs, they're not a "struct power_pmu"
backend for the existing powerpc PMU implementation.
cheers
^ permalink raw reply
* Re: [PATCH 2/2] of: search the best compatible match first in __of_match_node()
From: Grant Likely @ 2014-02-17 17:58 UTC (permalink / raw)
To: Kevin Hao, devicetree, linuxppc-dev
Cc: Stephen N Chivers, Rob Herring, Kevin Hao, Sebastian Hesselbarth
In-Reply-To: <1392355366-1445-3-git-send-email-haokexin@gmail.com>
On Fri, 14 Feb 2014 13:22:46 +0800, Kevin Hao <haokexin@gmail.com> wrote:
> Currently, of_match_node compares each given match against all node's
> compatible strings with of_device_is_compatible.
>
> To achieve multiple compatible strings per node with ordering from
> specific to generic, this requires given matches to be ordered from
> specific to generic. For most of the drivers this is not true and also
> an alphabetical ordering is more sane there.
>
> Therefore, this patch introduces a function to match each of the node's
> compatible strings against all given compatible matches without type and
> name first, before checking the next compatible string. This implies
> that node's compatibles are ordered from specific to generic while
> given matches can be in any order. If we fail to find such a match
> entry, then fall-back to the old method in order to keep compatibility.
>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> ---
> drivers/of/base.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index ba195fbce4c6..10b51106c854 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -730,13 +730,49 @@ out:
> }
> EXPORT_SYMBOL(of_find_node_with_property);
>
> +static const struct of_device_id *
> +of_match_compatible(const struct of_device_id *matches,
> + const struct device_node *node)
> +{
> + const char *cp;
> + int cplen, l;
> + const struct of_device_id *m;
> +
> + cp = __of_get_property(node, "compatible", &cplen);
> + while (cp && (cplen > 0)) {
> + m = matches;
> + while (m->name[0] || m->type[0] || m->compatible[0]) {
> + /* Only match for the entries without type and name */
> + if (m->name[0] || m->type[0] ||
> + of_compat_cmp(m->compatible, cp,
> + strlen(m->compatible)))
> + m++;
This seems wrong also. The compatible order should be checked for even
when m->name or m->type are set. You actually need to score the entries
to do this properly. The pseudo-code should look like this:
uint best_score = ~0;
of_device_id *best_match = NULL;
for_each(matches) {
uint score = ~0;
for_each_compatible(index) {
if (match->compatible == compatible[index])
score = index * 10;
}
/* Matching name is a bit better than not */
if (match->name == node->name)
score--;
/* Matching type is better than matching name */
/* (but matching both is even better than that */
if (match->type == node->type)
score -= 2;
if (score < best_score)
best_match = match;
}
return best_match;
This is actually very similar to the original code. It is an easy
modification. This is very similar to how the of_fdt_is_compatible()
function works.
g.
^ permalink raw reply
* Re: [PATCH 2/2] of: search the best compatible match first in __of_match_node()
From: Grant Likely @ 2014-02-17 17:59 UTC (permalink / raw)
To: Rob Herring, Kevin Hao
Cc: devicetree@vger.kernel.org, Stephen N Chivers, Rob Herring,
Kumar Gala, linuxppc-dev, Sebastian Hesselbarth
In-Reply-To: <CAL_JsqKq4_1K8EF+PZoP=0=H6tiRxbgdzs9UHHVdbHS014n74Q@mail.gmail.com>
On Fri, 14 Feb 2014 09:53:40 -0600, Rob Herring <robherring2@gmail.com> wrote:
> On Thu, Feb 13, 2014 at 11:22 PM, Kevin Hao <haokexin@gmail.com> wrote:
> > Currently, of_match_node compares each given match against all node's
> > compatible strings with of_device_is_compatible.
> >
> > To achieve multiple compatible strings per node with ordering from
> > specific to generic, this requires given matches to be ordered from
> > specific to generic. For most of the drivers this is not true and also
> > an alphabetical ordering is more sane there.
> >
> > Therefore, this patch introduces a function to match each of the node's
> > compatible strings against all given compatible matches without type and
> > name first, before checking the next compatible string. This implies
> > that node's compatibles are ordered from specific to generic while
> > given matches can be in any order. If we fail to find such a match
> > entry, then fall-back to the old method in order to keep compatibility.
> >
> > Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> > Signed-off-by: Kevin Hao <haokexin@gmail.com>
>
> Looks good to me. I'll put this in next for a few days. I'd really
> like to see some acks and tested-by's before sending to Linus.
As I commented on the patch, I don't think the new solution is correct
either. I've made a suggestion on how to fix it, but in the mean time
the revert should be applied and sent to Linus.
g.
^ permalink raw reply
* Re: [PATCH] of: give priority to the compatible match in __of_match_node()
From: Grant Likely @ 2014-02-17 18:06 UTC (permalink / raw)
To: Rob Herring, Kevin Hao
Cc: devicetree@vger.kernel.org, Arnd Bergmann, Chris Proctor,
Stephen N Chivers, Rob Herring, Scott Wood, linuxppc-dev,
Sebastian Hesselbarth
In-Reply-To: <CAL_JsqKMi2H=vwoxrOt8QRA2xJeiLqBKKfLtt4QRCRoFk6JUHg@mail.gmail.com>
On Thu, 13 Feb 2014 13:01:42 -0600, Rob Herring <robherring2@gmail.com> wrote:
> On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao <haokexin@gmail.com> wrote:
> > When the device node do have a compatible property, we definitely
> > prefer the compatible match besides the type and name. Only if
> > there is no such a match, we then consider the candidate which
> > doesn't have compatible entry but do match the type or name with
> > the device node.
> >
> > This is based on a patch from Sebastian Hesselbarth.
> > http://patchwork.ozlabs.org/patch/319434/
> >
> > I did some code refactoring and also fixed a bug in the original patch.
>
> I'm inclined to just revert this once again and avoid possibly
> breaking yet another platform.
>
> However, I think I would like to see this structured differently. We
> basically have 2 ways of matching: the existing pre-3.14 way and the
> desired match on best compatible only. All new bindings should match
> with the new way and the old way needs to be kept for compatibility.
> So lets structure the code that way. Search the match table first for
> best compatible with name and type NULL, then search the table the old
> way. I realize it appears you are doing this, but it is not clear this
> is the intent of the code. I would like to see this written as a patch
> with commit 105353145eafb3ea919 reverted first and you add a new match
> function to call first and then fallback to the existing function.
I disagree here, partially because it complicates the code and partially
because it leaves an incorrect corner case. Compatible is always the
preferred matching, even on old drivers, but there are bindings that
take both compatible and type or name into account. Even those cases
should rank the compatible order.
g.
^ permalink raw reply
* Re: Anyone using SysRQ key sequences on console serial port ?
From: Scott Wood @ 2014-02-17 19:37 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: John Donnelly, linuxppc-dev
In-Reply-To: <CAP=VYLpgMYaSVjTwJ2Q15XB+nozz=OhAPU85Nb9xG_FdP5dcyA@mail.gmail.com>
On Sun, 2014-02-16 at 10:56 -0500, Paul Gortmaker wrote:
> On Fri, Feb 14, 2014 at 3:42 PM, John Donnelly <john.d@servergy.com> wrote:
> > Hi,
> >
> > I tried using the SysRq hotkey sequence on a serial console -
> > 3.11.0-5-powerpc-e500mc system, by issuing a " break " and the system
> > immediately wedges after displaying "SysRQ : HELP : " using both "Putty" and
> > "Teraterm" terminal emulators. I know the system is dead because my ssh
> > sessions stopped too.
>
> Yes it does work -- or at least it _did_ work. Make sure your dts has an entry
>
> compatible = "fsl,ns16550", "ns16550";
>
> since that enables a workaround I'd added for a hardware errata relating
> to sending breaks over the serial console. What you describe above
> makes me think you aren't getting the workaround enabled.
Also make sure CONFIG_SERIAL_8250_FSL is enabled.
-Scott
^ permalink raw reply
* Re: [PATCH v2 10/11] powerpc/perf: add kconfig option for hypervisor provided counters
From: Cody P Schafer @ 2014-02-17 19:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: Paul Bolle, Peter Zijlstra, Priyanka Jain, LKML, Tang Yuantian,
Ingo Molnar, Paul Mackerras, Aneesh Kumar K.V,
Arnaldo Carvalho de Melo, Scott Wood, Lijun Pan, Linux PPC,
Anton Blanchard, Anshuman Khandual
In-Reply-To: <1392621108.8740.5.camel@concordia>
On 02/16/2014 11:11 PM, Michael Ellerman wrote:
> On Fri, 2014-02-14 at 16:25 -0800, Cody P Schafer wrote:
>> On Fri, Feb 14, 2014 at 04:32:13PM -0600, Scott Wood wrote:
>>> On Fri, 2014-02-14 at 14:02 -0800, Cody P Schafer wrote:
>>>> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
>>>> index 434fda3..dcc67cd 100644
>>>> --- a/arch/powerpc/platforms/Kconfig.cputype
>>>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>>>> @@ -364,6 +364,12 @@ config PPC_PERF_CTRS
>>>> help
>>>> This enables the powerpc-specific perf_event back-end.
>>>>
>>>> +config HV_PERF_CTRS
>>>> + def_bool y
>>>> + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT
>>>> + help
>>>> + Enable access to perf counters provided by the hypervisor
>>>
>>> Please don't add default-y stuff that is platform-specific, and
>>> definitely point out that platform dependency in the config description
>>> -- I have to look elsewhere in the patchset to determine that this is
>>> for "Power Hypervisor". PPC_HAVE_PMU_SUPPORT is enabled by all 6xx
>>> builds, even for hardware like e300 that doesn't have PMU at all (it has
>>> the FSL embedded perfmon instead), much less this hv interface.
>>>
>>> And yes, PPC_PERF_CTRS has the same problem and should be fixed. :-)
>>
>> Yep, I just based this one on what PPC_PERF_CTRS was doing.
>>
>> How about the following:
>>
>> +config HV_PERF_CTRS
>> + bool "Perf Hypervisor supplied counters"
>
> "Support for Hypervisor supplied PMU events (24x7 & GPCI)" ?
Sounds good to me.
>
>> + default y
>> + depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT && PPC_PSERIES
>
> I think you just want:
>
> depends on PERF_EVENTS && PPC_PSERIES
>
>
> Because you're adding two completely new PMUs, they're not a "struct power_pmu"
> backend for the existing powerpc PMU implementation.
>
Ack. I'll fix this up in v3
^ permalink raw reply
* Re: PCI-PCI bridge configuration in linux device tree
From: Scott Wood @ 2014-02-18 0:50 UTC (permalink / raw)
To: Anand Mistry; +Cc: linuxppc-dev
In-Reply-To: <20140215115045.M44796@Spectross.com>
On Sat, 2014-02-15 at 18:03 +0530, Anand Mistry wrote:
> Hello,
>
> We are working on a cPCI based application involving MPC8313 processor. The
> cPCI back-plane has a PCI-PCI bridge on it.
>
> While booting, the linux kernel(2.6.23)
2.6.23 is over 6 years old. Why are you using it for new hardware
support? Note that this code looks very different now.
Plus, from the file number in the crash output, it looks like you're not
dealing with vanilla 2.6.23, as there is no BUG on line 589 of pci_32.c.
If this is Freescale BSP/SDK code, support requests should be addressed
to support@freescale.com or https://community.freescale.com/ -- though
again I suggest going with current upstream code given the age of the
BSP code.
There is a BUG_ON on line 588 -- if it's that one (BUG_ON(rc) after
pci_assign_resource) then look into why pci_assign_resource is failing.
Also please ensure that you have CONFIG_KALLSYMS enabled when submitting
crash dumps.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] of: search the best compatible match first in __of_match_node()
From: Kevin Hao @ 2014-02-18 5:41 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree, Rob Herring, linuxppc-dev, Stephen N Chivers,
Sebastian Hesselbarth
In-Reply-To: <20140217175834.62ED6C403C8@trevor.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
On Mon, Feb 17, 2014 at 05:58:34PM +0000, Grant Likely wrote:
> This seems wrong also. The compatible order should be checked for even
> when m->name or m->type are set. You actually need to score the entries
> to do this properly. The pseudo-code should look like this:
>
> uint best_score = ~0;
> of_device_id *best_match = NULL;
> for_each(matches) {
> uint score = ~0;
> for_each_compatible(index) {
> if (match->compatible == compatible[index])
> score = index * 10;
> }
>
> /* Matching name is a bit better than not */
> if (match->name == node->name)
> score--;
>
> /* Matching type is better than matching name */
> /* (but matching both is even better than that */
> if (match->type == node->type)
> score -= 2;
>
> if (score < best_score)
> best_match = match;
> }
> return best_match;
>
> This is actually very similar to the original code. It is an easy
> modification. This is very similar to how the of_fdt_is_compatible()
> function works.
I like this idea and will make a new patch based on this.
Thanks,
Kevin
>
> g.
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Build regressions/improvements in v3.14-rc3
From: Geert Uytterhoeven @ 2014-02-18 9:06 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: linux-xtensa@linux-xtensa.org, the arch/x86 maintainers,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1392714172-2712-1-git-send-email-geert@linux-m68k.org>
On Tue, Feb 18, 2014 at 10:02 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.14-rc3[1] to v3.14-rc2[3], the summaries are:
> - build errors: +17/-6
+ /scratch/kisskb/src/arch/powerpc/include/asm/floppy.h: error:
'isa_bridge_pcidev' undeclared (first use in this function): =>
142:20
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: #error
m8xx_pcmcia: Bad configuration!: => 127:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error:
'PCMCIA_IO_WIN_NO' undeclared here (not in a function): => 220:30
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error:
'PCMCIA_MEM_WIN_NO' undeclared here (not in a function): => 219:32
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error:
'PCMCIA_SOCKETS_NO' undeclared here (not in a function): => 225:34
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: 'irq_map'
undeclared (first use in this function): => 1027:10
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: 's'
undeclared (first use in this function): => 982:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: expected
')' before 'PCMCIA_BOARD_MSG': => 1036:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'hardware_disable'
[-Werror=implicit-function-declaration]: => 1137:3
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'hardware_enable'
[-Werror=implicit-function-declaration]: => 1080:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'mk_int_int_mask'
[-Werror=implicit-function-declaration]: => 748:6
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'socket_get'
[-Werror=implicit-function-declaration]: => 657:2
+ /scratch/kisskb/src/drivers/pcmcia/m8xx_pcmcia.c: error: implicit
declaration of function 'voltage_set'
[-Werror=implicit-function-declaration]: => 686:2
powerpc-randconfig
+ /scratch/kisskb/src/drivers/gpio/gpio-xtensa.c: Error: unknown
opcode or format name 'read_impwire': => 87
+ /scratch/kisskb/src/drivers/gpio/gpio-xtensa.c: Error: unknown
opcode or format name 'rur.expstate': => 110
+ /scratch/kisskb/src/drivers/gpio/gpio-xtensa.c: Error: unknown
opcode or format name 'wrmsk_expstate': => 124
xtensa-allmodconfig
+ error: kvm_main.c: undefined reference to `__stack_chk_guard': =>
.text+0x6895)
i386-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/7190/ (all 119 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7167/ (all 119 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
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