* [PATCH v3 3/3] selftests: Add test of PMU instruction counting on powerpc
From: Michael Ellerman @ 2013-08-06 7:42 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jeremy Kerr, Andrew Morton, Michael Neuling, linux-kernel,
Anton Blanchard
In-Reply-To: <1375774957-30052-1-git-send-email-michael@ellerman.id.au>
This commit adds a test of instruction counting using the PMU on powerpc.
Although the bulk of the code is architecture agnostic, the code needs to
run a precisely sized loop which is implemented in assembler.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
v2,3: No change
tools/testing/selftests/powerpc/Makefile | 2 +-
tools/testing/selftests/powerpc/pmu/Makefile | 23 ++++
.../selftests/powerpc/pmu/count_instructions.c | 135 +++++++++++++++++++++
tools/testing/selftests/powerpc/pmu/event.c | 105 ++++++++++++++++
tools/testing/selftests/powerpc/pmu/event.h | 39 ++++++
tools/testing/selftests/powerpc/pmu/loop.S | 46 +++++++
6 files changed, 349 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/powerpc/pmu/Makefile
create mode 100644 tools/testing/selftests/powerpc/pmu/count_instructions.c
create mode 100644 tools/testing/selftests/powerpc/pmu/event.c
create mode 100644 tools/testing/selftests/powerpc/pmu/event.h
create mode 100644 tools/testing/selftests/powerpc/pmu/loop.S
diff --git a/tools/testing/selftests/powerpc/Makefile b/tools/testing/selftests/powerpc/Makefile
index b315740..bd24ae5 100644
--- a/tools/testing/selftests/powerpc/Makefile
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -13,7 +13,7 @@ CFLAGS := -Wall -O2 -flto -Wall -Werror -DGIT_VERSION='"$(GIT_VERSION)"' -I$(CUR
export CC CFLAGS
-TARGETS =
+TARGETS = pmu
endif
diff --git a/tools/testing/selftests/powerpc/pmu/Makefile b/tools/testing/selftests/powerpc/pmu/Makefile
new file mode 100644
index 0000000..7216f00
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/Makefile
@@ -0,0 +1,23 @@
+noarg:
+ $(MAKE) -C ../
+
+PROGS := count_instructions
+EXTRA_SOURCES := ../harness.c event.c
+
+all: $(PROGS)
+
+$(PROGS): $(EXTRA_SOURCES)
+
+# loop.S can only be built 64-bit
+count_instructions: loop.S count_instructions.c $(EXTRA_SOURCES)
+ $(CC) $(CFLAGS) -m64 -o $@ $^
+
+run_tests: all
+ @-for PROG in $(PROGS); do \
+ ./$$PROG; \
+ done;
+
+clean:
+ rm -f $(PROGS) loop.o
+
+.PHONY: all run_tests clean
diff --git a/tools/testing/selftests/powerpc/pmu/count_instructions.c b/tools/testing/selftests/powerpc/pmu/count_instructions.c
new file mode 100644
index 0000000..312b4f0
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/count_instructions.c
@@ -0,0 +1,135 @@
+/*
+ * Copyright 2013, Michael Ellerman, IBM Corp.
+ * Licensed under GPLv2.
+ */
+
+#define _GNU_SOURCE
+
+#include <stdio.h>
+#include <stdbool.h>
+#include <string.h>
+#include <sys/prctl.h>
+
+#include "event.h"
+#include "utils.h"
+
+extern void thirty_two_instruction_loop(u64 loops);
+
+static void setup_event(struct event *e, u64 config, char *name)
+{
+ event_init_opts(e, config, PERF_TYPE_HARDWARE, name);
+
+ e->attr.disabled = 1;
+ e->attr.exclude_kernel = 1;
+ e->attr.exclude_hv = 1;
+ e->attr.exclude_idle = 1;
+}
+
+static int do_count_loop(struct event *events, u64 instructions,
+ u64 overhead, bool report)
+{
+ s64 difference, expected;
+ double percentage;
+
+ prctl(PR_TASK_PERF_EVENTS_ENABLE);
+
+ /* Run for 1M instructions */
+ thirty_two_instruction_loop(instructions >> 5);
+
+ prctl(PR_TASK_PERF_EVENTS_DISABLE);
+
+ event_read(&events[0]);
+ event_read(&events[1]);
+
+ expected = instructions + overhead;
+ difference = events[0].result.value - expected;
+ percentage = (double)difference / events[0].result.value * 100;
+
+ if (report) {
+ event_report(&events[0]);
+ event_report(&events[1]);
+
+ printf("Looped for %llu instructions, overhead %llu\n", instructions, overhead);
+ printf("Expected %llu\n", expected);
+ printf("Actual %llu\n", events[0].result.value);
+ printf("Delta %lld, %f%%\n", difference, percentage);
+ }
+
+ event_reset(&events[0]);
+ event_reset(&events[1]);
+
+ if (difference < 0)
+ difference = -difference;
+
+ /* Tolerate a difference below 0.0001 % */
+ difference *= 10000 * 100;
+ if (difference / events[0].result.value)
+ return -1;
+
+ return 0;
+}
+
+/* Count how many instructions it takes to do a null loop */
+static u64 determine_overhead(struct event *events)
+{
+ u64 current, overhead;
+ int i;
+
+ do_count_loop(events, 0, 0, false);
+ overhead = events[0].result.value;
+
+ for (i = 0; i < 100; i++) {
+ do_count_loop(events, 0, 0, false);
+ current = events[0].result.value;
+ if (current < overhead) {
+ printf("Replacing overhead %llu with %llu\n", overhead, current);
+ overhead = current;
+ }
+ }
+
+ return overhead;
+}
+
+static int count_instructions(void)
+{
+ struct event events[2];
+ u64 overhead;
+
+ setup_event(&events[0], PERF_COUNT_HW_INSTRUCTIONS, "instructions");
+ setup_event(&events[1], PERF_COUNT_HW_CPU_CYCLES, "cycles");
+
+ if (event_open(&events[0])) {
+ perror("perf_event_open");
+ return -1;
+ }
+
+ if (event_open_with_group(&events[1], events[0].fd)) {
+ perror("perf_event_open");
+ return -1;
+ }
+
+ overhead = determine_overhead(events);
+ printf("Overhead of null loop: %llu instructions\n", overhead);
+
+ /* Run for 1M instructions */
+ FAIL_IF(do_count_loop(events, 0x100000, overhead, true));
+
+ /* Run for 10M instructions */
+ FAIL_IF(do_count_loop(events, 0xa00000, overhead, true));
+
+ /* Run for 100M instructions */
+ FAIL_IF(do_count_loop(events, 0x6400000, overhead, true));
+
+ /* Run for 1G instructions */
+ FAIL_IF(do_count_loop(events, 0x40000000, overhead, true));
+
+ event_close(&events[0]);
+ event_close(&events[1]);
+
+ return 0;
+}
+
+int main(void)
+{
+ return test_harness(count_instructions, "count_instructions");
+}
diff --git a/tools/testing/selftests/powerpc/pmu/event.c b/tools/testing/selftests/powerpc/pmu/event.c
new file mode 100644
index 0000000..2b2d11d
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/event.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2013, Michael Ellerman, IBM Corp.
+ * Licensed under GPLv2.
+ */
+
+#define _GNU_SOURCE
+#include <unistd.h>
+#include <sys/syscall.h>
+#include <string.h>
+#include <stdio.h>
+#include <sys/ioctl.h>
+
+#include "event.h"
+
+
+int perf_event_open(struct perf_event_attr *attr, pid_t pid, int cpu,
+ int group_fd, unsigned long flags)
+{
+ return syscall(__NR_perf_event_open, attr, pid, cpu,
+ group_fd, flags);
+}
+
+void event_init_opts(struct event *e, u64 config, int type, char *name)
+{
+ memset(e, 0, sizeof(*e));
+
+ e->name = name;
+
+ e->attr.type = type;
+ e->attr.config = config;
+ e->attr.size = sizeof(e->attr);
+ /* This has to match the structure layout in the header */
+ e->attr.read_format = PERF_FORMAT_TOTAL_TIME_ENABLED | \
+ PERF_FORMAT_TOTAL_TIME_RUNNING;
+}
+
+void event_init_named(struct event *e, u64 config, char *name)
+{
+ event_init_opts(e, config, PERF_TYPE_RAW, name);
+}
+
+#define PERF_CURRENT_PID 0
+#define PERF_NO_CPU -1
+#define PERF_NO_GROUP -1
+
+int event_open_with_options(struct event *e, pid_t pid, int cpu, int group_fd)
+{
+ e->fd = perf_event_open(&e->attr, pid, cpu, group_fd, 0);
+ if (e->fd == -1) {
+ perror("perf_event_open");
+ return -1;
+ }
+
+ return 0;
+}
+
+int event_open_with_group(struct event *e, int group_fd)
+{
+ return event_open_with_options(e, PERF_CURRENT_PID, PERF_NO_CPU, group_fd);
+}
+
+int event_open(struct event *e)
+{
+ return event_open_with_options(e, PERF_CURRENT_PID, PERF_NO_CPU, PERF_NO_GROUP);
+}
+
+void event_close(struct event *e)
+{
+ close(e->fd);
+}
+
+int event_reset(struct event *e)
+{
+ return ioctl(e->fd, PERF_EVENT_IOC_RESET);
+}
+
+int event_read(struct event *e)
+{
+ int rc;
+
+ rc = read(e->fd, &e->result, sizeof(e->result));
+ if (rc != sizeof(e->result)) {
+ fprintf(stderr, "read error on event %p!\n", e);
+ return -1;
+ }
+
+ return 0;
+}
+
+void event_report_justified(struct event *e, int name_width, int result_width)
+{
+ printf("%*s: result %*llu ", name_width, e->name, result_width,
+ e->result.value);
+
+ if (e->result.running == e->result.enabled)
+ printf("running/enabled %llu\n", e->result.running);
+ else
+ printf("running %llu enabled %llu\n", e->result.running,
+ e->result.enabled);
+}
+
+void event_report(struct event *e)
+{
+ event_report_justified(e, 0, 0);
+}
diff --git a/tools/testing/selftests/powerpc/pmu/event.h b/tools/testing/selftests/powerpc/pmu/event.h
new file mode 100644
index 0000000..e699319
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/event.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright 2013, Michael Ellerman, IBM Corp.
+ * Licensed under GPLv2.
+ */
+
+#ifndef _SELFTESTS_POWERPC_PMU_EVENT_H
+#define _SELFTESTS_POWERPC_PMU_EVENT_H
+
+#include <unistd.h>
+#include <linux/perf_event.h>
+
+#include "utils.h"
+
+
+struct event {
+ struct perf_event_attr attr;
+ char *name;
+ int fd;
+ /* This must match the read_format we use */
+ struct {
+ u64 value;
+ u64 running;
+ u64 enabled;
+ } result;
+};
+
+void event_init(struct event *e, u64 config);
+void event_init_named(struct event *e, u64 config, char *name);
+void event_init_opts(struct event *e, u64 config, int type, char *name);
+int event_open_with_options(struct event *e, pid_t pid, int cpu, int group_fd);
+int event_open_with_group(struct event *e, int group_fd);
+int event_open(struct event *e);
+void event_close(struct event *e);
+int event_reset(struct event *e);
+int event_read(struct event *e);
+void event_report_justified(struct event *e, int name_width, int result_width);
+void event_report(struct event *e);
+
+#endif /* _SELFTESTS_POWERPC_PMU_EVENT_H */
diff --git a/tools/testing/selftests/powerpc/pmu/loop.S b/tools/testing/selftests/powerpc/pmu/loop.S
new file mode 100644
index 0000000..8820e3d
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/loop.S
@@ -0,0 +1,46 @@
+/*
+ * Copyright 2013, Michael Ellerman, IBM Corp.
+ * Licensed under GPLv2.
+ */
+
+ .text
+
+ .global thirty_two_instruction_loop
+ .type .thirty_two_instruction_loop,@function
+ .section ".opd","aw",@progbits
+thirty_two_instruction_loop:
+ .quad .thirty_two_instruction_loop, .TOC.@tocbase, 0
+ .previous
+.thirty_two_instruction_loop:
+ cmpwi %r3,0
+ beqlr
+ addi %r4,%r3,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1
+ addi %r4,%r4,1 # 28 addi's
+ subi %r3,%r3,1
+ b .thirty_two_instruction_loop
--
1.8.1.2
^ permalink raw reply related
* [PATCH v3 2/3] selftests: Add support files for powerpc tests
From: Michael Ellerman @ 2013-08-06 7:42 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jeremy Kerr, Andrew Morton, Michael Neuling, linux-kernel,
Anton Blanchard
In-Reply-To: <1375774957-30052-1-git-send-email-michael@ellerman.id.au>
This commit adds support code used by upcoming powerpc tests.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
v3: Print when the child dies due to a signal
v2: Put back the SIGALARM handler to make the hang logic work.
tools/testing/selftests/powerpc/harness.c | 105 ++++++++++++++++++++++++++++++
tools/testing/selftests/powerpc/subunit.h | 47 +++++++++++++
tools/testing/selftests/powerpc/utils.h | 34 ++++++++++
3 files changed, 186 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/harness.c
create mode 100644 tools/testing/selftests/powerpc/subunit.h
create mode 100644 tools/testing/selftests/powerpc/utils.h
diff --git a/tools/testing/selftests/powerpc/harness.c b/tools/testing/selftests/powerpc/harness.c
new file mode 100644
index 0000000..e80c42a
--- /dev/null
+++ b/tools/testing/selftests/powerpc/harness.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2013, Michael Ellerman, IBM Corp.
+ * Licensed under GPLv2.
+ */
+
+#include <errno.h>
+#include <signal.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <unistd.h>
+
+#include "subunit.h"
+#include "utils.h"
+
+#define TIMEOUT 120
+#define KILL_TIMEOUT 5
+
+
+int run_test(int (test_function)(void), char *name)
+{
+ bool terminated;
+ int rc, status;
+ pid_t pid;
+
+ /* Make sure output is flushed before forking */
+ fflush(stdout);
+
+ pid = fork();
+ if (pid == 0) {
+ exit(test_function());
+ } else if (pid == -1) {
+ perror("fork");
+ return 1;
+ }
+
+ /* Wake us up in timeout seconds */
+ alarm(TIMEOUT);
+ terminated = false;
+
+wait:
+ rc = waitpid(pid, &status, 0);
+ if (rc == -1) {
+ if (errno != EINTR) {
+ printf("unknown error from waitpid\n");
+ return 1;
+ }
+
+ if (terminated) {
+ printf("!! force killing %s\n", name);
+ kill(pid, SIGKILL);
+ return 1;
+ } else {
+ printf("!! killing %s\n", name);
+ kill(pid, SIGTERM);
+ terminated = true;
+ alarm(KILL_TIMEOUT);
+ goto wait;
+ }
+ }
+
+ if (WIFEXITED(status))
+ status = WEXITSTATUS(status);
+ else {
+ if (WIFSIGNALED(status))
+ printf("!! child died by signal %d\n", WTERMSIG(status));
+ else
+ printf("!! child died by unknown cause\n");
+
+ status = 1; /* Signal or other */
+ }
+
+ return status;
+}
+
+static void alarm_handler(int signum)
+{
+ /* Jut wake us up from waitpid */
+}
+
+static struct sigaction alarm_action = {
+ .sa_handler = alarm_handler,
+};
+
+int test_harness(int (test_function)(void), char *name)
+{
+ int rc;
+
+ test_start(name);
+ test_set_git_version(GIT_VERSION);
+
+ if (sigaction(SIGALRM, &alarm_action, NULL)) {
+ perror("sigaction");
+ test_error(name);
+ return 1;
+ }
+
+ rc = run_test(test_function, name);
+
+ test_finish(name, rc);
+
+ return rc;
+}
diff --git a/tools/testing/selftests/powerpc/subunit.h b/tools/testing/selftests/powerpc/subunit.h
new file mode 100644
index 0000000..98a2292
--- /dev/null
+++ b/tools/testing/selftests/powerpc/subunit.h
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2013, Michael Ellerman, IBM Corp.
+ * Licensed under GPLv2.
+ */
+
+#ifndef _SELFTESTS_POWERPC_SUBUNIT_H
+#define _SELFTESTS_POWERPC_SUBUNIT_H
+
+static inline void test_start(char *name)
+{
+ printf("test: %s\n", name);
+}
+
+static inline void test_failure_detail(char *name, char *detail)
+{
+ printf("failure: %s [%s]\n", name, detail);
+}
+
+static inline void test_failure(char *name)
+{
+ printf("failure: %s\n", name);
+}
+
+static inline void test_error(char *name)
+{
+ printf("error: %s\n", name);
+}
+
+static inline void test_success(char *name)
+{
+ printf("success: %s\n", name);
+}
+
+static inline void test_finish(char *name, int status)
+{
+ if (status)
+ test_failure(name);
+ else
+ test_success(name);
+}
+
+static inline void test_set_git_version(char *value)
+{
+ printf("tags: git_version:%s\n", value);
+}
+
+#endif /* _SELFTESTS_POWERPC_SUBUNIT_H */
diff --git a/tools/testing/selftests/powerpc/utils.h b/tools/testing/selftests/powerpc/utils.h
new file mode 100644
index 0000000..5851c4b
--- /dev/null
+++ b/tools/testing/selftests/powerpc/utils.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright 2013, Michael Ellerman, IBM Corp.
+ * Licensed under GPLv2.
+ */
+
+#ifndef _SELFTESTS_POWERPC_UTILS_H
+#define _SELFTESTS_POWERPC_UTILS_H
+
+#include <stdint.h>
+#include <stdbool.h>
+
+/* Avoid headaches with PRI?64 - just use %ll? always */
+typedef unsigned long long u64;
+typedef signed long long s64;
+
+/* Just for familiarity */
+typedef uint32_t u32;
+typedef uint8_t u8;
+
+
+int test_harness(int (test_function)(void), char *name);
+
+
+/* Yes, this is evil */
+#define FAIL_IF(x) \
+do { \
+ if ((x)) { \
+ fprintf(stderr, \
+ "[FAIL] Test FAILED on line %d\n", __LINE__); \
+ return 1; \
+ } \
+} while (0)
+
+#endif /* _SELFTESTS_POWERPC_UTILS_H */
--
1.8.1.2
^ permalink raw reply related
* [PATCH v3 1/3] selftests: Add infrastructure for powerpc selftests
From: Michael Ellerman @ 2013-08-06 7:42 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jeremy Kerr, Andrew Morton, Michael Neuling, linux-kernel,
Anton Blanchard
This commit adds a powerpc subdirectory to tools/testing/selftests,
for tests that are powerpc specific.
On other architectures nothing is built. The makefile supports cross
compilation if the user sets ARCH and CROSS_COMPILE.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
v3: Add tags
v2: No change
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/powerpc/Makefile | 39 ++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/Makefile
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 4cb14ca..9f3eae2 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -8,6 +8,7 @@ TARGETS += net
TARGETS += ptrace
TARGETS += timers
TARGETS += vm
+TARGETS += powerpc
all:
for TARGET in $(TARGETS); do \
diff --git a/tools/testing/selftests/powerpc/Makefile b/tools/testing/selftests/powerpc/Makefile
new file mode 100644
index 0000000..b315740
--- /dev/null
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -0,0 +1,39 @@
+# Makefile for powerpc selftests
+
+# ARCH can be overridden by the user for cross compiling
+ARCH ?= $(shell uname -m)
+ARCH := $(shell echo $(ARCH) | sed -e s/ppc.*/powerpc/)
+
+ifeq ($(ARCH),powerpc)
+
+GIT_VERSION = $(shell git describe --always --long --dirty || echo "unknown")
+
+CC := $(CROSS_COMPILE)$(CC)
+CFLAGS := -Wall -O2 -flto -Wall -Werror -DGIT_VERSION='"$(GIT_VERSION)"' -I$(CURDIR) $(CFLAGS)
+
+export CC CFLAGS
+
+TARGETS =
+
+endif
+
+all:
+ @for TARGET in $(TARGETS); do \
+ $(MAKE) -C $$TARGET all; \
+ done;
+
+run_tests: all
+ @for TARGET in $(TARGETS); do \
+ $(MAKE) -C $$TARGET run_tests; \
+ done;
+
+clean:
+ @for TARGET in $(TARGETS); do \
+ $(MAKE) -C $$TARGET clean; \
+ done;
+ rm -f tags
+
+tags:
+ find . -name '*.c' -o -name '*.h' | xargs ctags
+
+.PHONY: all run_tests clean tags
--
1.8.1.2
^ permalink raw reply related
* Re: PCIE device errors after linux kernel upgrade
From: Leon Ravich @ 2013-08-06 7:26 UTC (permalink / raw)
To: Johannes Thumshirn; +Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, linuxppc-dev
In-Reply-To: <20130806070703.GA20622@jtlinux>
Hi Johannes
no panic just reboot.
it is not the first read, it takes few minutes of work with pcie to reboot.
On 6 August 2013 10:07, Johannes Thumshirn <johannes.thumshirn@men.de> wrote:
> On Mon, Aug 05, 2013 at 09:38:45AM -0600, Bjorn Helgaas wrote:
>> [+cc linuxppc-dev]
>>
>> On Mon, Aug 5, 2013 at 5:17 AM, Leon Ravich <lravich@gmail.com> wrote:
>> > Hi all ,
>> > I am trying to upgrade ours embedded device (freescale powerPC P2020 cpu)
>> > linux kernel , till now we used 2.6.32 I am trying to upgrade to 3.8.13 .
>> > I took the source from freescale git:
>> > git://git.freescale.com/ppc/sdk/linux.git
>> >
>> > on our embedded device we have an FPGA connected through PCIE .
>> >
>> > on each boot we loading the rbf design to the FPGA and the rescan pci bus to let
>> > kernel detect it .
>> >
>> > during the rescan I getting error messages:
>> > genirq: Setting trigger mode 0 for irq 27 failed
>> > (mpc8xxx_irq_set_type+0x0/0xec)
>> > [ 22.060898] genirq: Setting trigger mode 0 for irq 28 failed
>> > (mpc8xxx_irq_set_type+0x0/0xec)
>> > [ 22.069461] genirq: Setting trigger mode 0 for irq 31 failed
>> > (mpc8xxx_irq_set_type+0x0/0xec)
>> > [ 22.078010] genirq: Setting trigger mode 0 for irq 32 failed
>> > (mpc8xxx_irq_set_type+0x0/0xec)
>> > [ 22.086576] genirq: Setting trigger mode 0 for irq 33 failed
>> > (mpc8xxx_irq_set_type+0x0/0xec)
>> > [ 22.095143] genirq: Setting trigger mode 0 for irq 37 failed
>> > (mpc8xxx_irq_set_type+0x0/0xec)
>> > [ 22.103715] genirq: Setting trigger mode 0 for irq 38 failed
>> > (mpc8xxx_irq_set_type+0x0/0xec)
>> > [ 22.112282] genirq: Setting trigger mode 0 for irq 39 failed
>> > (mpc8xxx_irq_set_type+0x0/0xec)
>>
>> Hmm, I don't know much about IRQ issues.
>>
>> > [ 37.945785] pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't
>> > match header type 01)
>>
>> There's a recent patch related to this:
>> http://lkml.kernel.org/r/1374823418-1550-1-git-send-email-Chunhe.Lan@freescale.com
>>
>> > [ 37.953640] PCIE error(s) detected
>> > [ 37.953858] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
>> > [ 37.953988] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0000000-0xdfffffff]
>> > [ 37.953994] pci 0000:00:00.0: BAR 7: can't assign io (size 0x10000)
>> > [ 37.954000] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff]
>> > [ 37.954013] pci 0000:01:00.0: BAR 1: assigned [mem 0xc0100000-0xc017ffff]
>> > [ 37.954025] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0180000-0xc01fffff]
>> > [ 37.954036] pci 0000:00:00.0: PCI bridge to [bus 01]
>> > [ 37.954041] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
>> > [ 38.007354] PCIE ERR_DR register: 0x80020000
>> > [ 38.011613] PCIE ERR_CAP_STAT register: 0x00000041
>> > [ 38.016392] PCIE ERR_CAP_R0 register: 0x00000800
>> > [ 38.020997] PCIE ERR_CAP_R1 register: 0x00000000
>> > [ 38.025602] PCIE ERR_CAP_R2 register: 0x00000000
>> > [ 38.030207] PCIE ERR_CAP_R3 register: 0x00000000
>> >
>> >
>> > and after a few minutes I linux reboot it self,
>> >
>> >
>> > where can I start debugging it??
>>
>> I'd start by applying the header quirk patch above, then comparing the
>> complete console log (boot with "ignore_loglevel") from 2.6.32 and
>> 3.8.13.
>>
>> Bjorn
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> Hi,
>
> I have a similar problem here on a P4080 based board with the same 3.8 Kernel
> from freescale git. Does your system panic (maybe due to a machine check
> exception)? If yes could it be the first read from the PCI device?
>
> Johannes
--
Leonid Ravich
^ permalink raw reply
* Re: mm/slab: ppc: ubi: kmalloc_slab WARNING / PPC + UBI driver
From: Wladislav Wiebe @ 2013-08-06 7:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: dedekind1, Mel Gorman, dwmw2, Pekka Enberg, linux-mm, linux-mtd,
linuxppc-dev
In-Reply-To: <0000014035b06a9d-e8b10680-e321-4d3b-95a8-0833fa3fb7c9-000000@email.amazonses.com>
Hi,
On 31/07/13 19:04, Christoph Lameter wrote:
> On Wed, 31 Jul 2013, Wladislav Wiebe wrote:
>
>> Thanks for the point, do you plan to make kmalloc_large available for extern access in a separate mainline patch?
>> Since kmalloc_large is statically defined in slub_def.h and when including it to seq_file.c
>> we have a lot of conflicting types:
>
> You cannot separatly include slub_def.h. slab.h includes slub_def.h for
> you. What problem did you try to fix by doing so?
>
> There is a patch pending that moves kmalloc_large to slab.h. So maybe we
> have to wait a merge period in order to be able to use it with other
> allocators than slub.
>
>
ok, just saw in slab/for-linus branch that those stuff is reverted again..
commit 4932163637fbb9aaa654ca0703c5a624b7809da2
Author: Pekka Enberg <penberg@kernel.org>
Date: Wed Jul 10 10:16:01 2013 +0300
Revert "mm/sl[aou]b: Move kmalloc_node functions to common code"
..
commit 35be03cafb8f5ddcc1236e90144b6ec76296b789
Author: Pekka Enberg <penberg@kernel.org>
Date: Wed Jul 10 09:56:49 2013 +0300
Revert "mm/sl[aou]b: Move kmalloc definitions to slab.h"
--
WBR, WLadislav Wiebe
^ permalink raw reply
* Re: PCIE device errors after linux kernel upgrade
From: Johannes Thumshirn @ 2013-08-06 7:07 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, linuxppc-dev, Leon Ravich
In-Reply-To: <CAErSpo5ZZgdpkK+QdQUEnNCEXcG_T+QBWTVoQnMTghxkX7n2HA@mail.gmail.com>
On Mon, Aug 05, 2013 at 09:38:45AM -0600, Bjorn Helgaas wrote:
> [+cc linuxppc-dev]
>
> On Mon, Aug 5, 2013 at 5:17 AM, Leon Ravich <lravich@gmail.com> wrote:
> > Hi all ,
> > I am trying to upgrade ours embedded device (freescale powerPC P2020 cpu)
> > linux kernel , till now we used 2.6.32 I am trying to upgrade to 3.8.13 .
> > I took the source from freescale git:
> > git://git.freescale.com/ppc/sdk/linux.git
> >
> > on our embedded device we have an FPGA connected through PCIE .
> >
> > on each boot we loading the rbf design to the FPGA and the rescan pci bus to let
> > kernel detect it .
> >
> > during the rescan I getting error messages:
> > genirq: Setting trigger mode 0 for irq 27 failed
> > (mpc8xxx_irq_set_type+0x0/0xec)
> > [ 22.060898] genirq: Setting trigger mode 0 for irq 28 failed
> > (mpc8xxx_irq_set_type+0x0/0xec)
> > [ 22.069461] genirq: Setting trigger mode 0 for irq 31 failed
> > (mpc8xxx_irq_set_type+0x0/0xec)
> > [ 22.078010] genirq: Setting trigger mode 0 for irq 32 failed
> > (mpc8xxx_irq_set_type+0x0/0xec)
> > [ 22.086576] genirq: Setting trigger mode 0 for irq 33 failed
> > (mpc8xxx_irq_set_type+0x0/0xec)
> > [ 22.095143] genirq: Setting trigger mode 0 for irq 37 failed
> > (mpc8xxx_irq_set_type+0x0/0xec)
> > [ 22.103715] genirq: Setting trigger mode 0 for irq 38 failed
> > (mpc8xxx_irq_set_type+0x0/0xec)
> > [ 22.112282] genirq: Setting trigger mode 0 for irq 39 failed
> > (mpc8xxx_irq_set_type+0x0/0xec)
>
> Hmm, I don't know much about IRQ issues.
>
> > [ 37.945785] pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't
> > match header type 01)
>
> There's a recent patch related to this:
> http://lkml.kernel.org/r/1374823418-1550-1-git-send-email-Chunhe.Lan@freescale.com
>
> > [ 37.953640] PCIE error(s) detected
> > [ 37.953858] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > [ 37.953988] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0000000-0xdfffffff]
> > [ 37.953994] pci 0000:00:00.0: BAR 7: can't assign io (size 0x10000)
> > [ 37.954000] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff]
> > [ 37.954013] pci 0000:01:00.0: BAR 1: assigned [mem 0xc0100000-0xc017ffff]
> > [ 37.954025] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0180000-0xc01fffff]
> > [ 37.954036] pci 0000:00:00.0: PCI bridge to [bus 01]
> > [ 37.954041] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
> > [ 38.007354] PCIE ERR_DR register: 0x80020000
> > [ 38.011613] PCIE ERR_CAP_STAT register: 0x00000041
> > [ 38.016392] PCIE ERR_CAP_R0 register: 0x00000800
> > [ 38.020997] PCIE ERR_CAP_R1 register: 0x00000000
> > [ 38.025602] PCIE ERR_CAP_R2 register: 0x00000000
> > [ 38.030207] PCIE ERR_CAP_R3 register: 0x00000000
> >
> >
> > and after a few minutes I linux reboot it self,
> >
> >
> > where can I start debugging it??
>
> I'd start by applying the header quirk patch above, then comparing the
> complete console log (boot with "ignore_loglevel") from 2.6.32 and
> 3.8.13.
>
> Bjorn
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Hi,
I have a similar problem here on a P4080 based board with the same 3.8 Kernel
from freescale git. Does your system panic (maybe due to a machine check
exception)? If yes could it be the first read from the PCI device?
Johannes
^ permalink raw reply
* RE: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s
From: Bhushan Bharat-R65777 @ 2013-08-06 7:02 UTC (permalink / raw)
To: Wood Scott-B07421, Paul Mackerras
Cc: kvm@vger.kernel.org, agraf@suse.de, kvm-ppc@vger.kernel.org,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1375730341.13074.38.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmh1c2hhbiBCaGFyYXQt
UjY1Nzc3DQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNiwgMjAxMyA2OjQyIEFNDQo+IFRvOiBX
b29kIFNjb3R0LUIwNzQyMQ0KPiBDYzogQmVuamFtaW4gSGVycmVuc2NobWlkdDsgYWdyYWZAc3Vz
ZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5vcmc7DQo+IGt2bUB2Z2VyLmtlcm5lbC5vcmc7IGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggNS82IHYy
XSBrdm06IHBvd2VycGM6IGJvb2tlOiBBZGQgbGludXggcHRlIGxvb2t1cCBsaWtlDQo+IGJvb2tl
M3MNCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206
IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gU2VudDogVHVlc2RheSwgQXVndXN0IDA2LCAyMDEzIDEy
OjQ5IEFNDQo+ID4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiA+IENjOiBCZW5qYW1pbiBI
ZXJyZW5zY2htaWR0OyBXb29kIFNjb3R0LUIwNzQyMTsgYWdyYWZAc3VzZS5kZTsga3ZtLQ0KPiA+
IHBwY0B2Z2VyLmtlcm5lbC5vcmc7IGt2bUB2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gbGludXhwcGMt
ZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDUvNiB2Ml0ga3Zt
OiBwb3dlcnBjOiBib29rZTogQWRkIGxpbnV4IHB0ZSBsb29rdXANCj4gPiBsaWtlIGJvb2tlM3MN
Cj4gPg0KPiA+IE9uIE1vbiwgMjAxMy0wOC0wNSBhdCAwOToyNyAtMDUwMCwgQmh1c2hhbiBCaGFy
YXQtUjY1Nzc3IHdyb3RlOg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gPiA+ID4gRnJvbTogQmVuamFtaW4gSGVycmVuc2NobWlkdCBbbWFpbHRvOmJlbmhAa2Vy
bmVsLmNyYXNoaW5nLm9yZ10NCj4gPiA+ID4gU2VudDogU2F0dXJkYXksIEF1Z3VzdCAwMywgMjAx
MyA5OjU0IEFNDQo+ID4gPiA+IFRvOiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4gPiA+ID4gQ2M6
IFdvb2QgU2NvdHQtQjA3NDIxOyBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIua2VybmVsLm9y
ZzsNCj4gPiA+ID4ga3ZtQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFi
cy5vcmcNCj4gPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCA1LzYgdjJdIGt2bTogcG93ZXJwYzog
Ym9va2U6IEFkZCBsaW51eCBwdGUNCj4gPiA+ID4gbG9va3VwIGxpa2UgYm9va2Uzcw0KPiA+ID4g
Pg0KPiA+ID4gPiBPbiBTYXQsIDIwMTMtMDgtMDMgYXQgMDI6NTggKzAwMDAsIEJodXNoYW4gQmhh
cmF0LVI2NTc3NyB3cm90ZToNCj4gPiA+ID4gPiBPbmUgb2YgdGhlIHByb2JsZW0gSSBzYXcgd2Fz
IHRoYXQgaWYgSSBwdXQgdGhpcyBjb2RlIGluDQo+ID4gPiA+ID4gYXNtL3BndGFibGUtMzIuaCBh
bmQgYXNtL3BndGFibGUtNjQuaCB0aGVuIHB0ZV9wZXJzZW50KCkgYW5kDQo+ID4gPiA+ID4gb3Ro
ZXIgZnJpZW5kIGZ1bmN0aW9uIChvbiB3aGljaCB0aGlzIGNvZGUgZGVwZW5kcykgYXJlIGRlZmlu
ZWQgaW4NCj4gcGd0YWJsZS5oLg0KPiA+ID4gPiA+IEFuZCBwZ3RhYmxlLmggaW5jbHVkZXMgYXNt
L3BndGFibGUtMzIuaCBhbmQgYXNtL3BndGFibGUtNjQuaA0KPiA+ID4gPiA+IGJlZm9yZSBpdCBk
ZWZpbmVzIHB0ZV9wcmVzZW50KCkgYW5kIGZyaWVuZHMgZnVuY3Rpb25zLg0KPiA+ID4gPiA+DQo+
ID4gPiA+ID4gT2sgSSBtb3ZlIHdvdmUgdGhpcyBpbiBhc20vcGd0YWJsZSouaCwgaW5pdGlhbGx5
IEkgZm91Z2h0IHdpdGgNCj4gPiA+ID4gPiBteXNlbGYgdG8gdGFrZSB0aGlzIGNvZGUgaW4gcGd0
YWJsZSogYnV0IGZpbmFsbHkgZW5kIHVwIGRvaW5nDQo+ID4gPiA+ID4gaGVyZSAoZ290IGJpYXNl
ZCBieSBib29rM3MgOikpLg0KPiA+ID4gPg0KPiA+ID4gPiBJcyB0aGVyZSBhIHJlYXNvbiB3aHkg
dGhlc2Ugcm91dGluZXMgY2FuIG5vdCBiZSBjb21wbGV0ZWx5IGdlbmVyaWMNCj4gPiA+ID4gaW4g
cGd0YWJsZS5oID8NCj4gPiA+DQo+ID4gPiBIb3cgYWJvdXQgdGhlIGdlbmVyaWMgZnVuY3Rpb246
DQo+ID4gPg0KPiA+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3Rh
YmxlLXBwYzY0LmgNCj4gPiA+IGIvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL3BndGFibGUtcHBj
NjQuaA0KPiA+ID4gaW5kZXggZDI1N2Q5OC4uMjFkYWYyOCAxMDA2NDQNCj4gPiA+IC0tLSBhL2Fy
Y2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxlLXBwYzY0LmgNCj4gPiA+ICsrKyBiL2FyY2gv
cG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxlLXBwYzY0LmgNCj4gPiA+IEBAIC0yMjEsNiArMjIx
LDI3IEBAIHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBwdGVfdXBkYXRlKHN0cnVjdA0KPiA+
ID4gbW1fc3RydWN0DQo+ID4gKm1tLA0KPiA+ID4gICAgICAgICByZXR1cm4gb2xkOw0KPiA+ID4g
IH0NCj4gPiA+DQo+ID4gPiArc3RhdGljIGlubGluZSB1bnNpZ25lZCBsb25nIHB0ZV9yZWFkKHB0
ZV90ICpwKSB7ICNpZmRlZg0KPiA+ID4gK1BURV9BVE9NSUNfVVBEQVRFUw0KPiA+ID4gKyAgICAg
ICBwdGVfdCBwdGU7DQo+ID4gPiArICAgICAgIHB0ZV90IHRtcDsNCj4gPiA+ICsgICAgICAgX19h
c21fXyBfX3ZvbGF0aWxlX18gKA0KPiA+ID4gKyAgICAgICAiMTogICAgIGxkYXJ4ICAgJTAsMCwl
M1xuIg0KPiA+ID4gKyAgICAgICAiICAgICAgIGFuZGkuICAgJTEsJTAsJTRcbiINCj4gPiA+ICsg
ICAgICAgIiAgICAgICBibmUtICAgIDFiXG4iDQo+ID4gPiArICAgICAgICIgICAgICAgb3JpICAg
ICAlMSwlMCwlNFxuIg0KPiA+ID4gKyAgICAgICAiICAgICAgIHN0ZGN4LiAgJTEsMCwlM1xuIg0K
PiA+ID4gKyAgICAgICAiICAgICAgIGJuZS0gICAgMWIiDQo+ID4gPiArICAgICAgIDogIj0mciIg
KHB0ZSksICI9JnIiICh0bXApLCAiPW0iICgqcCkNCj4gPiA+ICsgICAgICAgOiAiciIgKHApLCAi
aSIgKF9QQUdFX0JVU1kpDQo+ID4gPiArICAgICAgIDogImNjIik7DQo+ID4gPiArDQo+ID4gPiAr
ICAgICAgIHJldHVybiBwdGU7DQo+ID4gPiArI2Vsc2UNCj4gPiA+ICsgICAgICAgcmV0dXJuIHB0
ZV92YWwoKnApOw0KPiA+ID4gKyNlbmRpZg0KPiA+ID4gKyNlbmRpZg0KPiA+ID4gK30NCj4gPiA+
ICBzdGF0aWMgaW5saW5lIGludCBfX3B0ZXBfdGVzdF9hbmRfY2xlYXJfeW91bmcoc3RydWN0IG1t
X3N0cnVjdCAqbW0sDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdW5zaWduZWQgbG9uZyBhZGRyLA0KPiA+ID4gcHRlX3QgKnB0ZXApDQo+ID4NCj4g
PiBQbGVhc2UgbGVhdmUgYSBibGFuayBsaW5lIGJldHdlZW4gZnVuY3Rpb25zLg0KPiA+DQo+ID4g
PiAgew0KPiA+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxl
LmgNCj4gPiA+IGIvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL3BndGFibGUuaA0KPiA+ID4gaW5k
ZXggNjkwYzhjMi4uZGFkNzEyYyAxMDA2NDQNCj4gPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9pbmNs
dWRlL2FzbS9wZ3RhYmxlLmgNCj4gPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9w
Z3RhYmxlLmgNCj4gPiA+IEBAIC0yNTQsNiArMjU0LDQ1IEBAIHN0YXRpYyBpbmxpbmUgcHRlX3QN
Cj4gPiA+ICpmaW5kX2xpbnV4X3B0ZV9vcl9odWdlcHRlKHBnZF90ICpwZ2RpciwgdW5zaWduZWQg
bG9uZyBlYSwgIH0NCj4gPiA+ICNlbmRpZg0KPiA+ID4gLyogIUNPTkZJR19IVUdFVExCX1BBR0Ug
Ki8NCj4gPiA+DQo+ID4gPiArc3RhdGljIGlubGluZSBwdGVfdCBsb29rdXBfbGludXhfcHRlKHBn
ZF90ICpwZ2RpciwgdW5zaWduZWQgbG9uZyBodmEsDQo+ID4gPiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaW50IHdyaXRpbmcsIHVuc2lnbmVkIGxvbmcNCj4gPiA+ICsqcHRl
X3NpemVwKQ0KPiA+DQo+ID4gVGhlIG5hbWUgaW1wbGllcyB0aGF0IGl0IGp1c3QgcmVhZHMgdGhl
IFBURS4gIFNldHRpbmcgYWNjZXNzZWQvZGlydHkNCj4gPiBzaG91bGRuJ3QgYmUgYW4gdW5kb2N1
bWVudGVkIHNpZGUtZWZmZWN0Lg0KPiANCj4gT2ssIHdpbGwgcmVuYW1lIGFuZCBkb2N1bWVudC4N
Cj4gDQo+ID4gV2h5IGNhbid0IHRoZSBjYWxsZXIgZG8gdGhhdCAob3IgYSBkaWZmZXJlbnQgZnVu
Y3Rpb24gdGhhdCB0aGUgY2FsbGVyDQo+ID4gY2FsbHMgYWZ0ZXJ3YXJkIGlmIGRlc2lyZWQpPw0K
PiANCj4gVGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaW4gYm9vazNzIGlzOw0KPiAgMSkgZmlu
ZCBhIHB0ZS9odWdlcHRlDQo+ICAyKSByZXR1cm4gbnVsbCBpZiBwdGUgbm90IHByZXNlbnQNCj4g
IDMpIHRha2UgX1BBR0VfQlVTWSBsb2NrDQo+ICA0KSBzZXQgYWNjZXNzZWQvZGlydHkNCj4gIDUp
IGNsZWFyIF9QQUdFX0JVU1kuDQo+IA0KPiBXaGF0IEkgdHJpZWQgd2FzDQo+IDEpIGZpbmQgYSBw
dGUvaHVnZXB0ZQ0KPiAyKSByZXR1cm4gbnVsbCBpZiBwdGUgbm90IHByZXNlbnQNCj4gMykgcmV0
dXJuIHB0ZSAobm90IHRha2UgbG9jayBieSBub3Qgc2V0dGluZyBfUEFHRV9CVVNZKQ0KPiANCj4g
NCkgdGhlbiB1c2VyIGNhbGxzICBfX3B0ZXBfc2V0X2FjY2Vzc19mbGFncygpIHRvIGF0b21pYyB1
cGRhdGUgdGhlDQo+IGRpcnR5L2FjY2Vzc2VkIGZsYWdzIGluIHB0ZS4NCj4gDQo+IC0gYnV0IHRo
ZSBiZW5jaG1hcmsgcmVzdWx0cyB3ZXJlIG5vdCBnb29kDQo+IC0gQWxzbyBjYW4gdGhlcmUgYmUg
cmFjZSBhcyB3ZSBkbyBub3QgdGFrZSBsb2NrIGluIHN0ZXAgMyBhbmQgdXBkYXRlIGluIHN0ZXAg
NCA/DQo+IA0KPiA+DQo+ID4gVGhvdWdoIGV2ZW4gdGhlbiB5b3UgaGF2ZSB0aGUgdW5kb2N1bWVu
dGVkIHNpZGUgZWZmZWN0IG9mIGxvY2tpbmcgdGhlDQo+ID4gUFRFIG9uIGNlcnRhaW4gdGFyZ2V0
cy4NCj4gPg0KPiA+ID4gK3sNCj4gPiA+ICsgICAgICAgcHRlX3QgKnB0ZXA7DQo+ID4gPiArICAg
ICAgIHB0ZV90IHB0ZTsNCj4gPiA+ICsgICAgICAgdW5zaWduZWQgbG9uZyBwcyA9ICpwdGVfc2l6
ZXA7DQo+ID4gPiArICAgICAgIHVuc2lnbmVkIGludCBzaGlmdDsNCj4gPiA+ICsNCj4gPiA+ICsg
ICAgICAgcHRlcCA9IGZpbmRfbGludXhfcHRlX29yX2h1Z2VwdGUocGdkaXIsIGh2YSwgJnNoaWZ0
KTsNCj4gPiA+ICsgICAgICAgaWYgKCFwdGVwKQ0KPiA+ID4gKyAgICAgICAgICAgICAgIHJldHVy
biBfX3B0ZSgwKTsNCj4gPiA+ICsgICAgICAgaWYgKHNoaWZ0KQ0KPiA+ID4gKyAgICAgICAgICAg
ICAgICpwdGVfc2l6ZXAgPSAxdWwgPDwgc2hpZnQ7DQo+ID4gPiArICAgICAgIGVsc2UNCj4gPiA+
ICsgICAgICAgICAgICAgICAqcHRlX3NpemVwID0gUEFHRV9TSVpFOw0KPiA+ID4gKw0KPiA+ID4g
KyAgICAgICBpZiAocHMgPiAqcHRlX3NpemVwKQ0KPiA+ID4gKyAgICAgICAgICAgICAgIHJldHVy
biBfX3B0ZSgwKTsNCj4gPiA+ICsNCj4gPiA+ICsgICAgICAgaWYgKCFwdGVfcHJlc2VudCgqcHRl
cCkpDQo+ID4gPiArICAgICAgICAgICAgICAgcmV0dXJuIF9fcHRlKDApOw0KPiA+ID4gKw0KPiA+
ID4gKyNpZmRlZiBDT05GSUdfUFBDNjQNCj4gPiA+ICsgICAgICAgLyogTG9jayBQVEUgKHNldCBf
UEFHRV9CVVNZKSBhbmQgcmVhZCAqLw0KPiA+ID4gKyAgICAgICBwdGUgPSBwdGVfcmVhZChwdGVw
KTsNCj4gPiA+ICsjZWxzZQ0KPiA+ID4gKyAgICAgICBwdGUgPSBwdGVfdmFsKCpwdGVwKTsNCj4g
PiA+ICsjZW5kaWYNCj4gPg0KPiA+IFdoYXQgYWJvdXQgMzItYml0IHBsYXRmb3JtcyB0aGF0IG5l
ZWQgYXRvbWljIFBURXM/DQo+IA0KPiBJIGNhbGxlZCBfX3B0ZXBfc2V0X2FjY2Vzc19mbGFncygp
IGZvciBib3RoIDMyLzY0Yml0IChmb3IgNjRiaXQgSSB3YXMgbm90DQo+IGNhbGxpbmcgcHRlX3Jl
YWQoKSksIHdoaWNoIGhhbmRsZXMgYXRvbWljIHVwZGF0ZXMuIFNvbWVob3cgdGhlIGJlbmNobWFy
ayByZXN1bHQNCj4gd2VyZSBub3QgZ29vZCwgd2lsbCB0cnkgYWdhaW4uDQoNCkhpIFBhdWxzLA0K
DQpJIGFtIHRyeWluZyB0byBtZSB0aGUgTGludXggcHRlIHNlYXJjaCBhbmQgdXBkYXRlIGdlbmVy
aWMgc28gdGhhdCB0aGlzIGNhbiBiZSB1c2VkIGZvciBwb3dlcnBjIGFzIHdlbGwuDQoNCkkgYW0g
bm90IHN1cmUgd2hpY2ggb2YgdGhlIGJlbG93IHR3byBzaG91bGQgYmUgb2ssIHBsZWFzZSBoZWxw
DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAoMSkgVGhpcyAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KLyoNCiAqIExvY2sgYW5kIHJlYWQgYSBsaW51eCBQVEUuICBJZiBpdCdzIHBy
ZXNlbnQgYW5kIHdyaXRhYmxlLCBhdG9taWNhbGx5DQogKiBzZXQgZGlydHkgYW5kIHJlZmVyZW5j
ZWQgYml0cyBhbmQgcmV0dXJuIHRoZSBQVEUsIG90aGVyd2lzZSByZXR1cm4gMC4NCiAqLw0Kc3Rh
dGljIGlubGluZSBhdG9taWNfcmVhZF91cGRhdGVfcHRlX2ZsYWdzKHB0ZV90ICpwdGVwLCBpbnQg
d3JpdGluZykNCnsNCiAgICAgICAgcHRlX3QgcHRlOw0KI2lmZGVmIENPTkZJR19QUEM2NA0KICAg
ICAgICAvKiBMb2NrIFBURSAoc2V0IF9QQUdFX0JVU1kpIGFuZCByZWFkDQogICAgICAgICAqIFhY
WDogTk9URTogU29tZSBBcmNoaXRlY3R1cmVzIChib29rM2UpIGRvZXMgbm90IGhhdmUgcHRlIExv
Y2tpbmcsDQogICAgICAgICAqIHNvIG5vdCBnZW5lcmljIGluIHRoYXQgc2Vuc2UgZm9yIGFsbCBh
cmNoaXRlY3R1cmUNCiAgICAgICAgICovDQogICAgICAgIHB0ZSA9IHB0ZV9yZWFkKHB0ZXApOw0K
I2Vsc2UNCiAgICAgICAgLyogWFhYOiBkbyBub3Qgc2VlIGFueSByZWFkIGxvY2tpbmcgb24gMzIg
Yml0IGFyY2hpdGVjdHVyZSAqLw0KICAgICAgICBwdGUgPSBwdGVfdmFsKCpwdGVwKTsNCiNlbmRp
Zg0KICAgICAgICBpZiAocHRlX3ByZXNlbnQocHRlKSkgew0KICAgICAgICAgICAgICAgIHB0ZSA9
IHB0ZV9ta3lvdW5nKHB0ZSk7DQogICAgICAgICAgICAgICAgaWYgKHdyaXRpbmcgJiYgcHRlX3dy
aXRlKHB0ZSkpDQogICAgICAgICAgICAgICAgICAgICAgICBwdGUgPSBwdGVfbWtkaXJ0eShwdGUp
Ow0KICAgICAgICB9DQoNCiAgICAgICAgKnB0ZXAgPSBfX3B0ZShwdGUpOyAvKiA2NGJpdDogQWxz
byB1bmxvY2sgcHRlIChjbGVhciBfUEFHRV9CVVNZKSAqLw0KDQogICAgICAgIHJldHVybiBwdGU7
DQp9DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tICgyKSBPUiBUSElTIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KLyoNCiAqIFJlYWQgYSBsaW51eCBQVEUuICBJZiBpdCdz
IHByZXNlbnQgYW5kIHdyaXRhYmxlLCBhdG9taWNhbGx5DQogKiBzZXQgZGlydHkgYW5kIHJlZmVy
ZW5jZWQgYml0cyBhbmQgcmV0dXJuIHRoZSBQVEUsIG90aGVyd2lzZSByZXR1cm4gMC4NCiAqLw0K
c3RhdGljIGlubGluZSBhdG9taWNfcmVhZF91cGRhdGVfcHRlX2ZsYWdzKHB0ZV90ICpwdGVwLCBp
bnQgd3JpdGluZykNCnsNCiAgICAgICAgcHRlX3QgcHRlOw0KICAgICAgICBwdGUgPSBwdGVfdmFs
KCpwdGVwKTsNCiAgICAgICAgaWYgKHB0ZV9wcmVzZW50KHB0ZSkpIHsNCiAgICAgICAgICAgICAg
ICBwdGUgPSBwdGVfbWt5b3VuZyhwdGUpOw0KICAgICAgICAgICAgICAgIGlmICh3cml0aW5nICYm
IHB0ZV93cml0ZShwdGUpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgcHRlID0gcHRlX21rZGly
dHkocHRlKTsNCiAgICAgICAgfQ0KDQogICAgICAgIF9fcHRlcF9zZXRfYWNjZXNzX2ZsYWdzKHB0
ZXAsIHB0ZSk7DQoNCiAgICAgICAgcmV0dXJuIHB0ZV92YWwoKnB0ZXApOw0KfQ0KDQpUaGFua3MN
Ci1CaGFyYXQNCg0KPiANCj4gVGhhbmtzDQo+IC1CaGFyYXQNCj4gPg0KPiA+IC1TY290dA0KPiA+
DQoNCg==
^ permalink raw reply
* Re: PCIE device errors after linux kernel upgrade
From: Leon Ravich @ 2013-08-06 6:32 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, linuxppc-dev
In-Reply-To: <CAErSpo5ZZgdpkK+QdQUEnNCEXcG_T+QBWTVoQnMTghxkX7n2HA@mail.gmail.com>
Thanks Bjorn.
1) If I understand it right this patch only removes the "pci
0000:00:00.0: ignoring class 0x0b2000 (doesn't
match header type 01)" message , don't care about it , had it before .
2) regarding the comparing of printouts:
kernel 3.8.13:
[ 37.908846] pci_bus 0000:00: scanning bus
[ 37.912870] pci 0000:00:00.0: [1957:0070] type 01 class 0x0b2000
[ 37.918881] pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't
match header type 01)
[ 37.926640] pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x5c
[ 37.933596] pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0xf0
[ 37.940132] pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x78
[ 37.946505] pci 0000:00:00.0: supports D1 D2
[ 37.950779] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 37.957397] pci 0000:00:00.0: PME# disabled
[ 37.961580] PCIE error(s) detected
[ 37.964971] PCIE ERR_DR register: 0x00020000
[ 37.969229] PCIE ERR_CAP_STAT register: 0x00000041
[ 37.974008] PCIE ERR_CAP_R0 register: 0x00000800
[ 37.978614] PCIE ERR_CAP_R1 register: 0x00000000
[ 37.983218] PCIE ERR_CAP_R2 register: 0x00000000
[ 37.987823] PCIE ERR_CAP_R3 register: 0x00000000
[ 37.992448] PCIE error(s) detected
[ 37.995841] PCIE ERR_DR register: 0x00020000
[ 38.000098] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.004877] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.009482] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.014087] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.018692] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.023312] PCIE error(s) detected
[ 38.026704] PCIE ERR_DR register: 0x00020000
[ 38.030961] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.035740] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.040345] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.044950] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.049554] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.054180] PCIE error(s) detected
[ 38.057573] PCIE ERR_DR register: 0x00020000
[ 38.061831] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.066609] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.071214] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.075819] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.080424] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.085046] PCIE error(s) detected
[ 38.088438] PCIE ERR_DR register: 0x00020000
[ 38.092696] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.097474] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.102079] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.106684] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.111289] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.115909] PCIE error(s) detected
[ 38.119301] PCIE ERR_DR register: 0x00020000
[ 38.123559] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.128337] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.132942] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.137547] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.142152] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.146773] PCIE error(s) detected
[ 38.150164] PCIE ERR_DR register: 0x00020000
[ 38.154423] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.159201] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.163806] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.168410] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.173015] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.177635] PCIE error(s) detected
[ 38.181028] PCIE ERR_DR register: 0x00020000
[ 38.185286] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.190066] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.194670] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.199275] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.203880] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.208504] PCIE error(s) detected
[ 38.211897] PCIE ERR_DR register: 0x00020000
[ 38.216156] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.220935] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.225540] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.230144] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.234749] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.239395] PCIE error(s) detected
[ 38.242788] PCIE ERR_DR register: 0x00020000
[ 38.247046] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.251825] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.256430] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.261034] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.265639] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.270268] PCIE error(s) detected
[ 38.273660] PCIE ERR_DR register: 0x00020000
[ 38.277918] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.282697] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.287302] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.291906] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.296511] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.301134] PCIE error(s) detected
[ 38.304526] PCIE ERR_DR register: 0x00020000
[ 38.308784] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.313563] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.318168] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.322772] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.327377] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.331999] PCIE error(s) detected
[ 38.335390] PCIE ERR_DR register: 0x00020000
[ 38.339648] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.344427] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.349031] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.353636] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.358241] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.362862] PCIE error(s) detected
[ 38.366255] PCIE ERR_DR register: 0x00020000
[ 38.370512] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.375291] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.379896] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.384501] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.389106] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.393728] PCIE error(s) detected
[ 38.397121] PCIE ERR_DR register: 0x00020000
[ 38.401379] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.406158] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.410763] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.415367] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.419972] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.424613] PCIE error(s) detected
[ 38.428007] PCIE ERR_DR register: 0x00020000
[ 38.432264] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.437043] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.441648] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.446253] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.450857] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.455483] PCIE error(s) detected
[ 38.458875] PCIE ERR_DR register: 0x00020000
[ 38.463133] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.467911] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.472516] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.477121] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.481726] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.486351] PCIE error(s) detected
[ 38.489743] PCIE ERR_DR register: 0x00020000
[ 38.494001] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.498780] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.503385] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.507989] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.512594] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.517212] PCIE error(s) detected
[ 38.520603] PCIE ERR_DR register: 0x00020000
[ 38.524860] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.529639] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.534244] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.538849] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.543453] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.548069] PCIE error(s) detected
[ 38.551461] PCIE ERR_DR register: 0x00020000
[ 38.555719] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.560497] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.565102] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.569707] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.574312] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.578928] PCIE error(s) detected
[ 38.582318] PCIE ERR_DR register: 0x00020000
[ 38.586576] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.591354] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.595959] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.600564] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.605169] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.609784] PCIE error(s) detected
[ 38.613175] PCIE ERR_DR register: 0x00020000
[ 38.617433] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.622211] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.626816] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.631421] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.636026] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.640658] PCIE error(s) detected
[ 38.644050] PCIE ERR_DR register: 0x00020000
[ 38.648309] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.653088] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.657692] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.662297] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.666902] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.671522] PCIE error(s) detected
[ 38.674914] PCIE ERR_DR register: 0x00020000
[ 38.679172] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.683951] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.688556] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.693161] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.697766] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.702386] PCIE error(s) detected
[ 38.705777] PCIE ERR_DR register: 0x00020000
[ 38.710034] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.714813] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.719418] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.724023] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.728628] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.733244] PCIE error(s) detected
[ 38.736636] PCIE ERR_DR register: 0x00020000
[ 38.740895] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.745673] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.750278] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.754883] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.759488] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.764103] PCIE error(s) detected
[ 38.767494] PCIE ERR_DR register: 0x00020000
[ 38.771752] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.776530] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.781135] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.785740] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.790344] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.794984] PCIE error(s) detected
[ 38.798377] PCIE ERR_DR register: 0x00020000
[ 38.802635] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.807414] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.812019] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.816624] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.821229] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.825848] PCIE error(s) detected
[ 38.829239] PCIE ERR_DR register: 0x00020000
[ 38.833496] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.838275] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.842880] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.847485] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.852090] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.856712] PCIE error(s) detected
[ 38.860103] PCIE ERR_DR register: 0x00020000
[ 38.864361] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.869139] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.873744] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.878349] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.882954] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.887574] PCIE error(s) detected
[ 38.890966] PCIE ERR_DR register: 0x00020000
[ 38.895223] PCIE ERR_CAP_STAT register: 0x00000041
[ 38.900002] PCIE ERR_CAP_R0 register: 0x00000800
[ 38.904607] PCIE ERR_CAP_R1 register: 0x00000000
[ 38.909212] PCIE ERR_CAP_R2 register: 0x00000000
[ 38.913817] PCIE ERR_CAP_R3 register: 0x00000000
[ 38.918446] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
[ 38.925142] pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
[ 38.931873] pci_bus 0000:01: busn_res: can not insert [bus 01-ff]
under [bus 00-01] (conflicts with (null) [bus 00-01])
[ 38.942654] pci_bus 0000:01: scanning bus
[ 38.946687] pci 0000:01:00.0: [1234:0002] type 00 class 0xff0000
[ 38.952697] pci 0000:01:00.0: reg 10: [mem 0x00000000-0x000fffff]
[ 38.958801] pci 0000:01:00.0: reg 14: [mem 0x00000000-0x0007ffff]
[ 38.964891] pci 0000:01:00.0: reg 18: [mem 0x00000000-0x0007ffff]
[ 38.971017] pci 0000:01:00.0: calling pcibios_fixup_resources+0x0/0xf0
[ 38.977605] pci_bus 0000:01: fixups for bus
[ 38.981782] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[ 38.987012] pci 0000:00:00.0: bridge window [io 0x0000-0x0fff]
[ 38.993098] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
[ 38.999970] pci_bus 0000:01: bus scan returning with max=01
[ 39.005537] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 39.012158] pci_bus 0000:00: bus scan returning with max=01
[ 39.017749] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0000000-0xdfffffff]
[ 39.024530] pci 0000:00:00.0: BAR 7: can't assign io (size 0x10000)
[ 39.030801] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff]
[ 39.037596] pci 0000:01:00.0: BAR 0: set to [mem
0xc0000000-0xc00fffff] (PCI address [0xc0000000-0xc00fffff])
[ 39.047511] pci 0000:01:00.0: BAR 1: assigned [mem 0xc0100000-0xc017ffff]
[ 39.054293] pci 0000:01:00.0: BAR 1: set to [mem
0xc0100000-0xc017ffff] (PCI address [0xc0100000-0xc017ffff])
[ 39.064204] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0180000-0xc01fffff]
[ 39.070997] pci 0000:01:00.0: BAR 2: set to [mem
0xc0180000-0xc01fffff] (PCI address [0xc0180000-0xc01fffff])
[ 39.080910] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 39.085866] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
[ 39.092662] pci 0000:00:00.0: enabling bus mastering
kernel 2.6.32
[ 49.665070] PCI: Scanning bus 0000:00
[ 49.668744] pci 0000:00:00.0: found [1957:0070] class 000b20 header type 01
[ 49.675708] pci 0000:00:00.0: ignoring class b20 (doesn't match
header type 01)
[ 49.683028] pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x5c
[ 49.689991] pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0xd0
[ 49.696525] pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x64
[ 49.702885] pci 0000:00:00.0: calling quirk_resource_alignment+0x0/0x1d4
[ 49.709583] pci 0000:00:00.0: supports D1 D2
[ 49.713851] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 49.720457] pci 0000:00:00.0: PME# disabled
[ 49.724657] pci 0000:00:00.0: scanning behind bridge, config 010100, pass 0
[ 49.731611] pci 0000:00:00.0: scanning behind bridge, config 000000, pass 1
[ 49.738576] PCI: Scanning bus 0000:01
[ 49.742256] pci 0000:01:00.0: found [1234:0002] class 00ff00 header type 00
[ 49.749224] pci 0000:01:00.0: reg 10 32bit mmio: [0x000000-0x0fffff]
[ 49.755584] pci 0000:01:00.0: reg 14 32bit mmio: [0x000000-0x07ffff]
[ 49.761932] pci 0000:01:00.0: reg 18 32bit mmio: [0x000000-0x07ffff]
[ 49.768302] pci 0000:01:00.0: calling pcibios_fixup_resources+0x0/0xd0
[ 49.774830] pci 0000:01:00.0: calling quirk_resource_alignment+0x0/0x1d4
[ 49.781566] PCI: Fixups for bus 0000:01
[ 49.785402] pci 0000:00:00.0: bridge io port: [0x00-0xfff]
[ 49.790879] pci 0000:00:00.0: bridge 32bit mmio: [0xc0000000-0xdfffffff]
[ 49.797627] PCI: Bus scan for 0000:01 returning with max=01
[ 49.803200] PCI: Bus scan for 0000:00 returning with max=01
[ 49.808777] pci 0000:01:00.0: BAR 0: got res
[0xc0000000-0xc00fffff] bus [0xc0000000-0xc00fffff] flags 0x20020200
[ 49.819041] pci 0000:01:00.0: BAR 0: moved to bus
[0xc0000000-0xc00fffff] flags 0x20200
[ 49.827043] pci 0000:01:00.0: BAR 1: got res
[0xc0100000-0xc017ffff] bus [0xc0100000-0xc017ffff] flags 0x20020200
[ 49.837303] pci 0000:01:00.0: BAR 1: moved to bus
[0xc0100000-0xc017ffff] flags 0x20200
[ 49.845306] pci 0000:01:00.0: BAR 2: got res
[0xc0180000-0xc01fffff] bus [0xc0180000-0xc01fffff] flags 0x20020200
[ 49.855566] pci 0000:01:00.0: BAR 2: moved to bus
[0xc0180000-0xc01fffff] flags 0x20200
[ 49.863568] pci 0000:00:00.0: PCI bridge, secondary bus 0000:01
[ 49.869477] pci 0000:00:00.0: IO window: disabled
[ 49.874352] pci 0000:00:00.0: MEM window: 0xc0000000-0xc01fffff
[ 49.880436] pci 0000:00:00.0: PREFETCH window: disabled
On 5 August 2013 18:38, Bjorn Helgaas <bhelgaas@google.com> wrote:
> [+cc linuxppc-dev]
>
> On Mon, Aug 5, 2013 at 5:17 AM, Leon Ravich <lravich@gmail.com> wrote:
>> Hi all ,
>> I am trying to upgrade ours embedded device (freescale powerPC P2020 cpu)
>> linux kernel , till now we used 2.6.32 I am trying to upgrade to 3.8.13 .
>> I took the source from freescale git:
>> git://git.freescale.com/ppc/sdk/linux.git
>>
>> on our embedded device we have an FPGA connected through PCIE .
>>
>> on each boot we loading the rbf design to the FPGA and the rescan pci bus to let
>> kernel detect it .
>>
>> during the rescan I getting error messages:
>> genirq: Setting trigger mode 0 for irq 27 failed
>> (mpc8xxx_irq_set_type+0x0/0xec)
>> [ 22.060898] genirq: Setting trigger mode 0 for irq 28 failed
>> (mpc8xxx_irq_set_type+0x0/0xec)
>> [ 22.069461] genirq: Setting trigger mode 0 for irq 31 failed
>> (mpc8xxx_irq_set_type+0x0/0xec)
>> [ 22.078010] genirq: Setting trigger mode 0 for irq 32 failed
>> (mpc8xxx_irq_set_type+0x0/0xec)
>> [ 22.086576] genirq: Setting trigger mode 0 for irq 33 failed
>> (mpc8xxx_irq_set_type+0x0/0xec)
>> [ 22.095143] genirq: Setting trigger mode 0 for irq 37 failed
>> (mpc8xxx_irq_set_type+0x0/0xec)
>> [ 22.103715] genirq: Setting trigger mode 0 for irq 38 failed
>> (mpc8xxx_irq_set_type+0x0/0xec)
>> [ 22.112282] genirq: Setting trigger mode 0 for irq 39 failed
>> (mpc8xxx_irq_set_type+0x0/0xec)
>
> Hmm, I don't know much about IRQ issues.
>
>> [ 37.945785] pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't
>> match header type 01)
>
> There's a recent patch related to this:
> http://lkml.kernel.org/r/1374823418-1550-1-git-send-email-Chunhe.Lan@freescale.com
>
>> [ 37.953640] PCIE error(s) detected
>> [ 37.953858] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
>> [ 37.953988] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0000000-0xdfffffff]
>> [ 37.953994] pci 0000:00:00.0: BAR 7: can't assign io (size 0x10000)
>> [ 37.954000] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff]
>> [ 37.954013] pci 0000:01:00.0: BAR 1: assigned [mem 0xc0100000-0xc017ffff]
>> [ 37.954025] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0180000-0xc01fffff]
>> [ 37.954036] pci 0000:00:00.0: PCI bridge to [bus 01]
>> [ 37.954041] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
>> [ 38.007354] PCIE ERR_DR register: 0x80020000
>> [ 38.011613] PCIE ERR_CAP_STAT register: 0x00000041
>> [ 38.016392] PCIE ERR_CAP_R0 register: 0x00000800
>> [ 38.020997] PCIE ERR_CAP_R1 register: 0x00000000
>> [ 38.025602] PCIE ERR_CAP_R2 register: 0x00000000
>> [ 38.030207] PCIE ERR_CAP_R3 register: 0x00000000
>>
>>
>> and after a few minutes I linux reboot it self,
>>
>>
>> where can I start debugging it??
>
> I'd start by applying the header quirk patch above, then comparing the
> complete console log (boot with "ignore_loglevel") from 2.6.32 and
> 3.8.13.
>
> Bjorn
--
Leonid Ravich
^ permalink raw reply
* Re: Failure to detect PCI card
From: David Hawkins @ 2013-08-06 2:01 UTC (permalink / raw)
To: Peter LaDow; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <CAN8Q1EfWOedMFKtFQbTmmydnLoLe24=c3Fo1Ao3sTdDmuYBJqQ@mail.gmail.com>
Hi Pete,
> On Mon, Aug 5, 2013 at 4:07 PM, Peter LaDow <petela@gocougs.wsu.edu> wrote:
>> However, replacing the 82540 based card with either a 3com 3C905TXM or
>> the Netgear FA331, there is no response on the 0x10 IDSEL line. Thus
>> it appears these cards are NOT responding to configuration reads. I
>> think I have to break out the scope and probe around for the 5V/3V. I
>> wouldn't think that the supplies are the issue since these are
>> universal cards, and as I understand it either 3V3 _or_ 5V can be
>> present, so these should work fine. Yet they aren't responding to PCI
>> configuration cycles.
It depends on what you define "Universal PCI" as :)
My definition is that the board works with either 5V or 3.3V PCI
signals. However, that definition does not tell you where the device
draws power from.
I suspect the lack of either the 5V or 3.3V power rail to the card
might be the problem.
Did you probe the PCI edge connect to see what supplies were present?
> A few more notes. I tried a variety of other cards, such as a PCI
> modem (WinMode, ack), a WinTV card, and a PCI based 802.11 card. All
> of them enumerate perfectly.
These could all be 3.3V cards ...
> Perhaps it is a BIOS option ROM like you suggested earlier. The
> 3c90xC reference manual I found
> (http://people.freebsd.org/~wpaul/3Com/3c90xc.pdf) mentions an option
> ROM (and there is an Atmel part stuffed). I can't find any technical
> information on the FA331 (yet), so I don't know about it.
>
> But regardless, wouldn't enumeration have to occur before any option
> ROM could even be used?
I've never had a card with an option ROM, so can't comment. I'd have
to look at the PCI spec. If you want me to look, let me know.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
From: Kevin Hao @ 2013-08-06 1:45 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc
In-Reply-To: <1375748040.13074.111.camel@snotra.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
On Mon, Aug 05, 2013 at 07:14:00PM -0500, Scott Wood wrote:
> On Thu, 2013-07-04 at 20:54 +0800, Kevin Hao wrote:
> > @@ -1222,6 +1266,9 @@ _GLOBAL(switch_to_as1)
> > /*
> > * Restore to the address space 0 and also invalidate the tlb entry created
> > * by switch_to_as1.
> > + * r3 - the tlb entry which should be invalidated
> > + * r4 - __pa(PAGE_OFFSET in AS0) - pa(PAGE_OFFSET in AS1)
> > + * r5 - device tree virtual address
> > */
> > _GLOBAL(restore_to_as0)
> [snip]
> > diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
> > index 3a65644..8280dbb 100644
> > --- a/arch/powerpc/mm/mmu_decl.h
> > +++ b/arch/powerpc/mm/mmu_decl.h
> > @@ -149,7 +149,7 @@ extern void MMU_init_hw(void);
> > extern unsigned long mmu_mapin_ram(unsigned long top);
> > extern void adjust_total_lowmem(void);
> > extern int switch_to_as1(void);
> > -extern void restore_to_as0(int);
> > +extern void restore_to_as0(int, int, void *);
>
> "int" seems wrong for the second argument. Shouldn't it be phys_addr_t?
This is the offset between __pa(PAGE_OFFSET in AS0) and __pa(PAGE_OFFSET in AS1).
And the max offset should never exceed 768M. So a int type is safe here and
using this type also avoid the ugly #ifdef CONFIG_PHYS_64BIT.
>
> Also, please use parameter names.
Sure.
Thanks,
Kevin
>
> -Scott
>
>
>
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
From: Kevin Hao @ 2013-08-06 1:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc
In-Reply-To: <1375747806.13074.106.camel@snotra.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]
On Mon, Aug 05, 2013 at 07:10:06PM -0500, Scott Wood wrote:
> On Sun, 2013-08-04 at 08:50 +0800, Kevin Hao wrote:
> > On Fri, Jul 26, 2013 at 07:17:57PM -0500, Scott Wood wrote:
> > > >diff --git a/arch/powerpc/mm/fsl_booke_mmu.c
> > > >b/arch/powerpc/mm/fsl_booke_mmu.c
> > > >index 8f60ef8..dd283fd 100644
> > > >--- a/arch/powerpc/mm/fsl_booke_mmu.c
> > > >+++ b/arch/powerpc/mm/fsl_booke_mmu.c
> > > >@@ -224,7 +224,7 @@ void __init adjust_total_lowmem(void)
> > > >
> > > > i = switch_to_as1();
> > > > __max_low_memory = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM);
> > > >- restore_to_as0(i);
> > > >+ restore_to_as0(i, 0, 0);
> > >
> > > The device tree virtual address is zero?
> >
> > No. But if the __pa(PAGE_OFFSET in AS0) is equal to __pa(PAGE_OFFSET in AS1),
> > that mean we don't need to do another relocation and the device tree virtual
> > address is useless in this case.
>
> The documentation of restore_to_as0() should make it clear that r5 is
> ignored if r4 is zero.
OK, will add.
Thanks,
Kevin
>
> -Scott
>
>
>
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info
From: Kevin Hao @ 2013-08-06 1:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc
In-Reply-To: <1375747168.13074.100.camel@snotra.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On Mon, Aug 05, 2013 at 06:59:28PM -0500, Scott Wood wrote:
> On Sun, 2013-08-04 at 08:45 +0800, Kevin Hao wrote:
> > memblock_add(base, size);
<snip>
> > }
>
> I think it'd be clearer for it to be an external variable that gets set
> by the relocation code -- plus, the above wouldn't work if this gets
> called twice due to having multiple memory regions.
Got it.
Thanks,
Kevin
>
> -Scott
>
>
>
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s
From: Bhushan Bharat-R65777 @ 2013-08-06 1:12 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <1375730341.13074.38.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgQXVndXN0IDA2LCAyMDEzIDEyOjQ5IEFNDQo+IFRvOiBCaHVz
aGFuIEJoYXJhdC1SNjU3NzcNCj4gQ2M6IEJlbmphbWluIEhlcnJlbnNjaG1pZHQ7IFdvb2QgU2Nv
dHQtQjA3NDIxOyBhZ3JhZkBzdXNlLmRlOyBrdm0tDQo+IHBwY0B2Z2VyLmtlcm5lbC5vcmc7IGt2
bUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0ggNS82IHYyXSBrdm06IHBvd2VycGM6IGJvb2tlOiBBZGQgbGludXggcHRl
IGxvb2t1cCBsaWtlDQo+IGJvb2tlM3MNCj4gDQo+IE9uIE1vbiwgMjAxMy0wOC0wNSBhdCAwOToy
NyAtMDUwMCwgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3IHdyb3RlOg0KPiA+DQo+ID4gPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogQmVuamFtaW4gSGVycmVuc2NobWlkdCBb
bWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gPiA+IFNlbnQ6IFNhdHVyZGF5LCBB
dWd1c3QgMDMsIDIwMTMgOTo1NCBBTQ0KPiA+ID4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0K
PiA+ID4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIu
a2VybmVsLm9yZzsNCj4gPiA+IGt2bUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0
cy5vemxhYnMub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDUvNiB2Ml0ga3ZtOiBwb3dl
cnBjOiBib29rZTogQWRkIGxpbnV4IHB0ZQ0KPiA+ID4gbG9va3VwIGxpa2UgYm9va2Uzcw0KPiA+
ID4NCj4gPiA+IE9uIFNhdCwgMjAxMy0wOC0wMyBhdCAwMjo1OCArMDAwMCwgQmh1c2hhbiBCaGFy
YXQtUjY1Nzc3IHdyb3RlOg0KPiA+ID4gPiBPbmUgb2YgdGhlIHByb2JsZW0gSSBzYXcgd2FzIHRo
YXQgaWYgSSBwdXQgdGhpcyBjb2RlIGluDQo+ID4gPiA+IGFzbS9wZ3RhYmxlLTMyLmggYW5kIGFz
bS9wZ3RhYmxlLTY0LmggdGhlbiBwdGVfcGVyc2VudCgpIGFuZCBvdGhlcg0KPiA+ID4gPiBmcmll
bmQgZnVuY3Rpb24gKG9uIHdoaWNoIHRoaXMgY29kZSBkZXBlbmRzKSBhcmUgZGVmaW5lZCBpbiBw
Z3RhYmxlLmguDQo+ID4gPiA+IEFuZCBwZ3RhYmxlLmggaW5jbHVkZXMgYXNtL3BndGFibGUtMzIu
aCBhbmQgYXNtL3BndGFibGUtNjQuaA0KPiA+ID4gPiBiZWZvcmUgaXQgZGVmaW5lcyBwdGVfcHJl
c2VudCgpIGFuZCBmcmllbmRzIGZ1bmN0aW9ucy4NCj4gPiA+ID4NCj4gPiA+ID4gT2sgSSBtb3Zl
IHdvdmUgdGhpcyBpbiBhc20vcGd0YWJsZSouaCwgaW5pdGlhbGx5IEkgZm91Z2h0IHdpdGgNCj4g
PiA+ID4gbXlzZWxmIHRvIHRha2UgdGhpcyBjb2RlIGluIHBndGFibGUqIGJ1dCBmaW5hbGx5IGVu
ZCB1cCBkb2luZyBoZXJlDQo+ID4gPiA+IChnb3QgYmlhc2VkIGJ5IGJvb2szcyA6KSkuDQo+ID4g
Pg0KPiA+ID4gSXMgdGhlcmUgYSByZWFzb24gd2h5IHRoZXNlIHJvdXRpbmVzIGNhbiBub3QgYmUg
Y29tcGxldGVseSBnZW5lcmljDQo+ID4gPiBpbiBwZ3RhYmxlLmggPw0KPiA+DQo+ID4gSG93IGFi
b3V0IHRoZSBnZW5lcmljIGZ1bmN0aW9uOg0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93
ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxlLXBwYzY0LmgNCj4gPiBiL2FyY2gvcG93ZXJwYy9pbmNs
dWRlL2FzbS9wZ3RhYmxlLXBwYzY0LmgNCj4gPiBpbmRleCBkMjU3ZDk4Li4yMWRhZjI4IDEwMDY0
NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxlLXBwYzY0LmgNCj4g
PiArKysgYi9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vcGd0YWJsZS1wcGM2NC5oDQo+ID4gQEAg
LTIyMSw2ICsyMjEsMjcgQEAgc3RhdGljIGlubGluZSB1bnNpZ25lZCBsb25nIHB0ZV91cGRhdGUo
c3RydWN0IG1tX3N0cnVjdA0KPiAqbW0sDQo+ID4gICAgICAgICByZXR1cm4gb2xkOw0KPiA+ICB9
DQo+ID4NCj4gPiArc3RhdGljIGlubGluZSB1bnNpZ25lZCBsb25nIHB0ZV9yZWFkKHB0ZV90ICpw
KSB7ICNpZmRlZg0KPiA+ICtQVEVfQVRPTUlDX1VQREFURVMNCj4gPiArICAgICAgIHB0ZV90IHB0
ZTsNCj4gPiArICAgICAgIHB0ZV90IHRtcDsNCj4gPiArICAgICAgIF9fYXNtX18gX192b2xhdGls
ZV9fICgNCj4gPiArICAgICAgICIxOiAgICAgbGRhcnggICAlMCwwLCUzXG4iDQo+ID4gKyAgICAg
ICAiICAgICAgIGFuZGkuICAgJTEsJTAsJTRcbiINCj4gPiArICAgICAgICIgICAgICAgYm5lLSAg
ICAxYlxuIg0KPiA+ICsgICAgICAgIiAgICAgICBvcmkgICAgICUxLCUwLCU0XG4iDQo+ID4gKyAg
ICAgICAiICAgICAgIHN0ZGN4LiAgJTEsMCwlM1xuIg0KPiA+ICsgICAgICAgIiAgICAgICBibmUt
ICAgIDFiIg0KPiA+ICsgICAgICAgOiAiPSZyIiAocHRlKSwgIj0mciIgKHRtcCksICI9bSIgKCpw
KQ0KPiA+ICsgICAgICAgOiAiciIgKHApLCAiaSIgKF9QQUdFX0JVU1kpDQo+ID4gKyAgICAgICA6
ICJjYyIpOw0KPiA+ICsNCj4gPiArICAgICAgIHJldHVybiBwdGU7DQo+ID4gKyNlbHNlDQo+ID4g
KyAgICAgICByZXR1cm4gcHRlX3ZhbCgqcCk7DQo+ID4gKyNlbmRpZg0KPiA+ICsjZW5kaWYNCj4g
PiArfQ0KPiA+ICBzdGF0aWMgaW5saW5lIGludCBfX3B0ZXBfdGVzdF9hbmRfY2xlYXJfeW91bmco
c3RydWN0IG1tX3N0cnVjdCAqbW0sDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgYWRkciwNCj4gPiBwdGVfdCAqcHRlcCkNCj4g
DQo+IFBsZWFzZSBsZWF2ZSBhIGJsYW5rIGxpbmUgYmV0d2VlbiBmdW5jdGlvbnMuDQo+IA0KPiA+
ICB7DQo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxlLmgN
Cj4gPiBiL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wZ3RhYmxlLmgNCj4gPiBpbmRleCA2OTBj
OGMyLi5kYWQ3MTJjIDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9w
Z3RhYmxlLmgNCj4gPiArKysgYi9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vcGd0YWJsZS5oDQo+
ID4gQEAgLTI1NCw2ICsyNTQsNDUgQEAgc3RhdGljIGlubGluZSBwdGVfdA0KPiA+ICpmaW5kX2xp
bnV4X3B0ZV9vcl9odWdlcHRlKHBnZF90ICpwZ2RpciwgdW5zaWduZWQgbG9uZyBlYSwgIH0gICNl
bmRpZg0KPiA+IC8qICFDT05GSUdfSFVHRVRMQl9QQUdFICovDQo+ID4NCj4gPiArc3RhdGljIGlu
bGluZSBwdGVfdCBsb29rdXBfbGludXhfcHRlKHBnZF90ICpwZ2RpciwgdW5zaWduZWQgbG9uZyBo
dmEsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCB3cml0aW5n
LCB1bnNpZ25lZCBsb25nDQo+ID4gKypwdGVfc2l6ZXApDQo+IA0KPiBUaGUgbmFtZSBpbXBsaWVz
IHRoYXQgaXQganVzdCByZWFkcyB0aGUgUFRFLiAgU2V0dGluZyBhY2Nlc3NlZC9kaXJ0eSBzaG91
bGRuJ3QNCj4gYmUgYW4gdW5kb2N1bWVudGVkIHNpZGUtZWZmZWN0Lg0KDQpPaywgd2lsbCByZW5h
bWUgYW5kIGRvY3VtZW50Lg0KDQo+IFdoeSBjYW4ndCB0aGUgY2FsbGVyIGRvIHRoYXQgKG9yIGEg
ZGlmZmVyZW50DQo+IGZ1bmN0aW9uIHRoYXQgdGhlIGNhbGxlciBjYWxscyBhZnRlcndhcmQgaWYg
ZGVzaXJlZCk/DQoNClRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIGluIGJvb2szcyBpczsNCiAx
KSBmaW5kIGEgcHRlL2h1Z2VwdGUNCiAyKSByZXR1cm4gbnVsbCBpZiBwdGUgbm90IHByZXNlbnQN
CiAzKSB0YWtlIF9QQUdFX0JVU1kgbG9jaw0KIDQpIHNldCBhY2Nlc3NlZC9kaXJ0eQ0KIDUpIGNs
ZWFyIF9QQUdFX0JVU1kuDQoNCldoYXQgSSB0cmllZCB3YXMgDQoxKSBmaW5kIGEgcHRlL2h1Z2Vw
dGUNCjIpIHJldHVybiBudWxsIGlmIHB0ZSBub3QgcHJlc2VudA0KMykgcmV0dXJuIHB0ZSAobm90
IHRha2UgbG9jayBieSBub3Qgc2V0dGluZyBfUEFHRV9CVVNZKQ0KDQo0KSB0aGVuIHVzZXIgY2Fs
bHMgIF9fcHRlcF9zZXRfYWNjZXNzX2ZsYWdzKCkgdG8gYXRvbWljIHVwZGF0ZSB0aGUgZGlydHkv
YWNjZXNzZWQgZmxhZ3MgaW4gcHRlLg0KDQotIGJ1dCB0aGUgYmVuY2htYXJrIHJlc3VsdHMgd2Vy
ZSBub3QgZ29vZA0KLSBBbHNvIGNhbiB0aGVyZSBiZSByYWNlIGFzIHdlIGRvIG5vdCB0YWtlIGxv
Y2sgaW4gc3RlcCAzIGFuZCB1cGRhdGUgaW4gc3RlcCA0ID8NCiAgDQo+IA0KPiBUaG91Z2ggZXZl
biB0aGVuIHlvdSBoYXZlIHRoZSB1bmRvY3VtZW50ZWQgc2lkZSBlZmZlY3Qgb2YgbG9ja2luZyB0
aGUgUFRFIG9uDQo+IGNlcnRhaW4gdGFyZ2V0cy4NCj4gDQo+ID4gK3sNCj4gPiArICAgICAgIHB0
ZV90ICpwdGVwOw0KPiA+ICsgICAgICAgcHRlX3QgcHRlOw0KPiA+ICsgICAgICAgdW5zaWduZWQg
bG9uZyBwcyA9ICpwdGVfc2l6ZXA7DQo+ID4gKyAgICAgICB1bnNpZ25lZCBpbnQgc2hpZnQ7DQo+
ID4gKw0KPiA+ICsgICAgICAgcHRlcCA9IGZpbmRfbGludXhfcHRlX29yX2h1Z2VwdGUocGdkaXIs
IGh2YSwgJnNoaWZ0KTsNCj4gPiArICAgICAgIGlmICghcHRlcCkNCj4gPiArICAgICAgICAgICAg
ICAgcmV0dXJuIF9fcHRlKDApOw0KPiA+ICsgICAgICAgaWYgKHNoaWZ0KQ0KPiA+ICsgICAgICAg
ICAgICAgICAqcHRlX3NpemVwID0gMXVsIDw8IHNoaWZ0Ow0KPiA+ICsgICAgICAgZWxzZQ0KPiA+
ICsgICAgICAgICAgICAgICAqcHRlX3NpemVwID0gUEFHRV9TSVpFOw0KPiA+ICsNCj4gPiArICAg
ICAgIGlmIChwcyA+ICpwdGVfc2l6ZXApDQo+ID4gKyAgICAgICAgICAgICAgIHJldHVybiBfX3B0
ZSgwKTsNCj4gPiArDQo+ID4gKyAgICAgICBpZiAoIXB0ZV9wcmVzZW50KCpwdGVwKSkNCj4gPiAr
ICAgICAgICAgICAgICAgcmV0dXJuIF9fcHRlKDApOw0KPiA+ICsNCj4gPiArI2lmZGVmIENPTkZJ
R19QUEM2NA0KPiA+ICsgICAgICAgLyogTG9jayBQVEUgKHNldCBfUEFHRV9CVVNZKSBhbmQgcmVh
ZCAqLw0KPiA+ICsgICAgICAgcHRlID0gcHRlX3JlYWQocHRlcCk7DQo+ID4gKyNlbHNlDQo+ID4g
KyAgICAgICBwdGUgPSBwdGVfdmFsKCpwdGVwKTsNCj4gPiArI2VuZGlmDQo+IA0KPiBXaGF0IGFi
b3V0IDMyLWJpdCBwbGF0Zm9ybXMgdGhhdCBuZWVkIGF0b21pYyBQVEVzPw0KDQpJIGNhbGxlZCBf
X3B0ZXBfc2V0X2FjY2Vzc19mbGFncygpIGZvciBib3RoIDMyLzY0Yml0IChmb3IgNjRiaXQgSSB3
YXMgbm90IGNhbGxpbmcgcHRlX3JlYWQoKSksIHdoaWNoIGhhbmRsZXMgYXRvbWljIHVwZGF0ZXMu
IFNvbWVob3cgdGhlIGJlbmNobWFyayByZXN1bHQgd2VyZSBub3QgZ29vZCwgd2lsbCB0cnkgYWdh
aW4uDQoNClRoYW5rcw0KLUJoYXJhdA0KPiANCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
From: Scott Wood @ 2013-08-06 0:14 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <1372942454-25191-8-git-send-email-haokexin@gmail.com>
On Thu, 2013-07-04 at 20:54 +0800, Kevin Hao wrote:
> @@ -1222,6 +1266,9 @@ _GLOBAL(switch_to_as1)
> /*
> * Restore to the address space 0 and also invalidate the tlb entry created
> * by switch_to_as1.
> + * r3 - the tlb entry which should be invalidated
> + * r4 - __pa(PAGE_OFFSET in AS0) - pa(PAGE_OFFSET in AS1)
> + * r5 - device tree virtual address
> */
> _GLOBAL(restore_to_as0)
[snip]
> diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
> index 3a65644..8280dbb 100644
> --- a/arch/powerpc/mm/mmu_decl.h
> +++ b/arch/powerpc/mm/mmu_decl.h
> @@ -149,7 +149,7 @@ extern void MMU_init_hw(void);
> extern unsigned long mmu_mapin_ram(unsigned long top);
> extern void adjust_total_lowmem(void);
> extern int switch_to_as1(void);
> -extern void restore_to_as0(int);
> +extern void restore_to_as0(int, int, void *);
"int" seems wrong for the second argument. Shouldn't it be phys_addr_t?
Also, please use parameter names.
-Scott
^ permalink raw reply
* Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
From: Scott Wood @ 2013-08-06 0:10 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20130804005035.GE19141@pek-khao-d1.corp.ad.wrs.com>
On Sun, 2013-08-04 at 08:50 +0800, Kevin Hao wrote:
> On Fri, Jul 26, 2013 at 07:17:57PM -0500, Scott Wood wrote:
> > >diff --git a/arch/powerpc/mm/fsl_booke_mmu.c
> > >b/arch/powerpc/mm/fsl_booke_mmu.c
> > >index 8f60ef8..dd283fd 100644
> > >--- a/arch/powerpc/mm/fsl_booke_mmu.c
> > >+++ b/arch/powerpc/mm/fsl_booke_mmu.c
> > >@@ -224,7 +224,7 @@ void __init adjust_total_lowmem(void)
> > >
> > > i = switch_to_as1();
> > > __max_low_memory = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM);
> > >- restore_to_as0(i);
> > >+ restore_to_as0(i, 0, 0);
> >
> > The device tree virtual address is zero?
>
> No. But if the __pa(PAGE_OFFSET in AS0) is equal to __pa(PAGE_OFFSET in AS1),
> that mean we don't need to do another relocation and the device tree virtual
> address is useless in this case.
The documentation of restore_to_as0() should make it clear that r5 is
ignored if r4 is zero.
-Scott
^ permalink raw reply
* Re: [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info
From: Scott Wood @ 2013-08-05 23:59 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20130804004531.GD19141@pek-khao-d1.corp.ad.wrs.com>
On Sun, 2013-08-04 at 08:45 +0800, Kevin Hao wrote:
> On Fri, Jul 26, 2013 at 07:18:01PM -0500, Scott Wood wrote:
> > >+ * This function run before early_init_devtree, so we have to init
> > >+ * initial_boot_params. Since early_init_dt_scan_memory_ppc will be
> > >+ * executed again in early_init_devtree, we have to reinitialize the
> > >+ * memblock data before return.
> > >+ */
> > >+void __init early_get_first_memblock_info(void *params,
> > >phys_addr_t *size)
> > >+{
> > >+ /* Setup flat device-tree pointer */
> > >+ initial_boot_params = params;
> > >+
> > >+ /* Scan memory nodes and rebuild MEMBLOCKs */
> > >+ of_scan_flat_dt(early_init_dt_scan_root, NULL);
> > >+ of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
> > >+
> > >+ if (size)
> > >+ *size = first_memblock_size;
> > >+
> > >+ /* Undo what early_init_dt_scan_memory_ppc does to memblock */
> > >+ memblock_reinit();
> > >+}
> > >+#endif
> >
> > Wouldn't it be simpler to set a flag so that
> > early_init_dt_add_memory_arch() doesn't mess with memblocks on the
> > first pass?
>
> Do you mean something like this?
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 9a69d2d..e861394 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -523,6 +523,10 @@ static int __init early_init_dt_scan_memory_ppc(unsigned long node,
>
> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> +#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FSL_BOOKE)
> + static int first_time = 1;
> +#endif
> +
> #ifdef CONFIG_PPC64
> if (iommu_is_off) {
> if (base >= 0x80000000ul)
> @@ -541,6 +545,13 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> }
>
> /* Add the chunk to the MEMBLOCK list */
> +
> +#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FSL_BOOKE)
> + if (first_time) {
> + first_time = 0;
> + return;
> + }
> +#endif
> memblock_add(base, size);
> }
I think it'd be clearer for it to be an external variable that gets set
by the relocation code -- plus, the above wouldn't work if this gets
called twice due to having multiple memory regions.
-Scott
^ permalink raw reply
* Re: Failure to detect PCI card
From: Peter LaDow @ 2013-08-05 23:14 UTC (permalink / raw)
To: David Hawkins; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <CAN8Q1EecMBWb_wKVOGnBJ=CHZ9zQQDKjwN5ZD4DkP30+QRerPA@mail.gmail.com>
On Mon, Aug 5, 2013 at 4:07 PM, Peter LaDow <petela@gocougs.wsu.edu> wrote:
> However, replacing the 82540 based card with either a 3com 3C905TXM or
> the Netgear FA331, there is no response on the 0x10 IDSEL line. Thus
> it appears these cards are NOT responding to configuration reads. I
> think I have to break out the scope and probe around for the 5V/3V. I
> wouldn't think that the supplies are the issue since these are
> universal cards, and as I understand it either 3V3 _or_ 5V can be
> present, so these should work fine. Yet they aren't responding to PCI
> configuration cycles.
A few more notes. I tried a variety of other cards, such as a PCI
modem (WinMode, ack), a WinTV card, and a PCI based 802.11 card. All
of them enumerate perfectly.
Perhaps it is a BIOS option ROM like you suggested earlier. The
3c90xC reference manual I found
(http://people.freebsd.org/~wpaul/3Com/3c90xc.pdf) mentions an option
ROM (and there is an Atmel part stuffed). I can't find any technical
information on the FA331 (yet), so I don't know about it.
But regardless, wouldn't enumeration have to occur before any option
ROM could even be used?
Thanks,
Pete
^ permalink raw reply
* Re: Failure to detect PCI card
From: Peter LaDow @ 2013-08-05 23:07 UTC (permalink / raw)
To: David Hawkins; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <52000ACA.1010606@ovro.caltech.edu>
On Mon, Aug 5, 2013 at 1:27 PM, David Hawkins <dwh@ovro.caltech.edu> wrote:
> 2. Have you probed the PCI bus using a bus analyzer or scope?
Ok. I managed to find someone with a bus extender, and have connected
both our analyzer and card.
With a working card (the 82540EM based card), I see configuration
reads on 0x00040000, 0x00080000, and 0x00100000 succeed. The 4 and 8
correspond to the IDSEL's for our on-board ethernet (also 82540 based)
and our FPGA, respectively (these configuration addresses match the
IDSEL on our schematic, and these accesses are present when no card is
plugged into the expansion slot). The 0x10 corresponds with the 82540
based network card. All the vendor/device id's make sense.
However, replacing the 82540 based card with either a 3com 3C905TXM or
the Netgear FA331, there is no response on the 0x10 IDSEL line. Thus
it appears these cards are NOT responding to configuration reads. I
think I have to break out the scope and probe around for the 5V/3V. I
wouldn't think that the supplies are the issue since these are
universal cards, and as I understand it either 3V3 _or_ 5V can be
present, so these should work fine. Yet they aren't responding to PCI
configuration cycles.
I'll have to do more digging.
Thanks,
Pete
^ permalink raw reply
* Re: [PATCH] Add device file bindings for MAPLE
From: Kumar Gala @ 2013-08-05 22:26 UTC (permalink / raw)
To: Scott Wood; +Cc: Shaveta Leekha, devicetree-discuss, linuxppc-dev
In-Reply-To: <1375737065.13074.58.camel@snotra.buserror.net>
On Aug 5, 2013, at 4:11 PM, Scott Wood wrote:
> On Thu, 2013-08-01 at 11:05 -0500, Kumar Gala wrote:
>> On Aug 1, 2013, at 6:02 AM, Shaveta Leekha wrote:
>>=20
>>> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
>>> ---
>>> .../devicetree/bindings/powerpc/fsl/maple.txt | 30 =
++++++++++++++++++++
>>> 1 files changed, 30 insertions(+), 0 deletions(-)
>>> create mode 100644 =
Documentation/devicetree/bindings/powerpc/fsl/maple.txt
>>>=20
>>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt =
b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
>>> new file mode 100644
>>> index 0000000..da51c5f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
>>> @@ -0,0 +1,30 @@
>>> +* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
>>> + (MAPLE-B3)device nodes
>>> +
>>> +Supported chips:
>>> +Example: B4860
>>> +
>>> +Required properties:
>>> +
>>> +- compatible: Should contain "fsl,maple-b3-liodn" as the value
>>> + This identifies Multi Accelerator Platform Engine
>>> + Baseband 3 block.This representation is required
>>> + for doing the PAMU/LIODN programming on the Linux side.
>>=20
>> This compatible makes no sense, we shouldn't be marking a full HW =
block with some name that is just intended for LIODN convenance.
>=20
> The point is we're not describing the whole block here, because the =
rest
> of the block is owned by an external entity (the DSP cores).
So the binding should make that far more clear that the MAPLE would be =
controlled by DSP SW.
>=20
>> Is this version 3 of the block? If so a name like "fsl,maple-v3" or =
"fsl,maple-v3.0" would be more appropriate.
>>=20
>> - k
>>=20
>>> +
>>> +- reg: offset and length of the register set for the =
device
>>> +
So the reg should limit itself to the LIODN registers only.
>>> +Devices that have LIODNs need to specify links to the parent PAMU =
controller
>>> +(the actual PAMU controller that this device is connected to) and a =
pointer to
>>> +the LIODN register, if applicable.
>>=20
>>=20
>> Does Maple not have any IRQs associated with it?
>=20
> maple-liodn doesn't.
>=20
> -Scott
>=20
>=20
^ permalink raw reply
* Re: [PATCH] Add device file bindings for MAPLE
From: Scott Wood @ 2013-08-05 22:16 UTC (permalink / raw)
To: Shaveta Leekha; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <1375354963-11219-1-git-send-email-shaveta@freescale.com>
On Thu, 2013-08-01 at 16:32 +0530, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/maple.txt | 30 ++++++++++++++++++++
> 1 files changed, 30 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/maple.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> new file mode 100644
> index 0000000..da51c5f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> @@ -0,0 +1,30 @@
> +* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
> + (MAPLE-B3)device nodes
> +
> +Supported chips:
> +Example: B4860
> +
> +Required properties:
> +
> +- compatible: Should contain "fsl,maple-b3-liodn" as the value
> + This identifies Multi Accelerator Platform Engine
> + Baseband 3 block.This representation is required
> + for doing the PAMU/LIODN programming on the Linux side.
Device tree bindings should not talk about particular OSes or use cases
(except for use case information that is part of the AMP partitioning,
and thus not at the discretion of the OS). Just say that this
identifies the LIODN register of the block.
> +
> +- reg: offset and length of the register set for the device
> +
> +Devices that have LIODNs need to specify links to the parent PAMU controller
> +(the actual PAMU controller that this device is connected to) and a pointer to
> +the LIODN register, if applicable.
> +
> +- fsl,iommu-parent
> + : <phandle>
> + This property should be present
> +
> +Example:
> + /* B4860 */
> + maple@800000 {
> + compatible = "fsl,maple-b3-liodn";
> + reg = <0x8000000 0x10000>;
Unit address doesn't match reg (missing/extra zero).
-Scott
^ permalink raw reply
* Re: Failure to detect PCI card
From: Peter LaDow @ 2013-08-05 22:11 UTC (permalink / raw)
To: David Hawkins; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <5200143F.9010307@ovro.caltech.edu>
On Mon, Aug 5, 2013 at 2:08 PM, David Hawkins <dwh@ovro.caltech.edu> wrote:
> My analyzer has an extender card that you first plug in, and then
> plug the board into that ... any chance someone in your organization
> has one of those cards? Alternatively, confirm the board works in
> a machine that has more than one slot, and if it does not, use the
> analyzer to see what is happening.
Mine has an extender as well, but it is a 5V only extender (such as
the one you pointed out). I'll ask the HW guys if they have a 3V
somewhere.
Now, I'm not a PCI expoert, but, I can do PCI transactions via u-boot.
And probing the PCI space via u-boot reveals nothing on 00:14.0 (the
place where our 82540 typically shows up). Indeed, it returns all
FF's, so I presume that means nothing is there. And enabling PCI_ENUM
is u-boot causes an exception when I try 'pci enum' (with an older
version of u-boot) or hangs u-boot (in 2013.07).
> If you're looking for a PCI target that you can completely control,
> then if you have an "FPGA guy" in your company, perhaps he can
> dig up a low-cost PCI card that you can configure as a PCI master
> to emulate the functions of a network card.
Well, we do have an FPGA hanging off the bus. But getting an RTL guy
to do this....hmmm. I'll have to explore more.
> Actually, before going down that route, I would get a PCI extender
> that you can use to trace the traffic with your board. Does the
> network card use 33MHz or 66MHz?
It's at 33MHz. I just need to find a 3V extender somewhere...
Thanks,
Pete
^ permalink raw reply
* Re: [PATCH 00/11] Add compression support to pstore
From: Tony Luck @ 2013-08-05 21:20 UTC (permalink / raw)
To: Aruna Balakrishnaiah
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
linux-kernel@vger.kernel.org, keescook@chromium.org
In-Reply-To: <51FFFFEB.3030907@linux.vnet.ibm.com>
This patch seems to fix the garbage at the end problem. Booting an
old kernel and using openssl decodes them OK.
Still have problems booting if there are any compressed images in ERST
to be inflated.
-Tony
^ permalink raw reply
* Re: [PATCH] Add device file bindings for MAPLE
From: Scott Wood @ 2013-08-05 21:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: Shaveta Leekha, devicetree-discuss, linuxppc-dev
In-Reply-To: <5C32ABF4-ECC3-4F1C-82D0-EA3AD9053575@kernel.crashing.org>
On Thu, 2013-08-01 at 11:05 -0500, Kumar Gala wrote:
> On Aug 1, 2013, at 6:02 AM, Shaveta Leekha wrote:
>
> > Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> > ---
> > .../devicetree/bindings/powerpc/fsl/maple.txt | 30 ++++++++++++++++++++
> > 1 files changed, 30 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> > new file mode 100644
> > index 0000000..da51c5f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> > @@ -0,0 +1,30 @@
> > +* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
> > + (MAPLE-B3)device nodes
> > +
> > +Supported chips:
> > +Example: B4860
> > +
> > +Required properties:
> > +
> > +- compatible: Should contain "fsl,maple-b3-liodn" as the value
> > + This identifies Multi Accelerator Platform Engine
> > + Baseband 3 block.This representation is required
> > + for doing the PAMU/LIODN programming on the Linux side.
>
> This compatible makes no sense, we shouldn't be marking a full HW block with some name that is just intended for LIODN convenance.
The point is we're not describing the whole block here, because the rest
of the block is owned by an external entity (the DSP cores).
> Is this version 3 of the block? If so a name like "fsl,maple-v3" or "fsl,maple-v3.0" would be more appropriate.
>
> - k
>
> > +
> > +- reg: offset and length of the register set for the device
> > +
> > +Devices that have LIODNs need to specify links to the parent PAMU controller
> > +(the actual PAMU controller that this device is connected to) and a pointer to
> > +the LIODN register, if applicable.
>
>
> Does Maple not have any IRQs associated with it?
maple-liodn doesn't.
-Scott
^ permalink raw reply
* Re: Failure to detect PCI card
From: David Hawkins @ 2013-08-05 21:10 UTC (permalink / raw)
To: Peter LaDow; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <5200143F.9010307@ovro.caltech.edu>
Hi Pete,
> Actually, before going down that route, I would get a PCI extender
> that you can use to trace the traffic with your board. Does the
> network card use 33MHz or 66MHz?
I wonder if something like this board:
http://www.logicsupply.com/products/pci122_dflex
can be used to make a single PCI slot into two PCI slots. You
could then plug your analyzer into the second slot.
For $30 it might be worth a shot ...
Cheers,
Dave
^ permalink raw reply
* Re: Failure to detect PCI card
From: David Hawkins @ 2013-08-05 21:08 UTC (permalink / raw)
To: Peter LaDow; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <CAN8Q1EcnT3We1X22pw4AQ28xmd2d-XB9nTzZ2KdVb=qOx4j7-Q@mail.gmail.com>
Hi Pete,
>> 1. Have you checked the power supplies on the PCI board?
>>
>> PCI boards can be powered from 3.3V or 5V, or both. I've had
>> old PCs that only supply one or the other rail, and various
>> evaluation boards that only supply 3.3V.
>>
>> If you can put together a "working" x86 setup that detects the
>> board, then you could poke around and see what voltages exist
>> on some of the decoupling components, then plug it into your
>> real system, and see what voltages you measure there.
>
> These are universal boards. Our board does only support only 3V3 (and
> is slotted as such).
Ok.
>> 2. Have you probed the PCI bus using a bus analyzer or scope?
>>
>> If you have a PCI bus analyzer (or can find someone with one),
>> plug it in and see what happens at power-on (there should be
>> configuration cycles).
>>
>> At a minimum, if you have a 'scope, see if the PCI configuration
>> space access handshakes are active during power-on.
>
> Hmm...I do have one. But I can't get both the analyzer and the card
> in the system in at the same time.
My analyzer has an extender card that you first plug in, and then
plug the board into that ... any chance someone in your organization
has one of those cards? Alternatively, confirm the board works in
a machine that has more than one slot, and if it does not, use the
analyzer to see what is happening.
>> 3. Is debugging this PCI card worth your time?
>>
>> Sometimes the "solution" involves tossing old hardware in
>> the trash.
>
> Well, this is part of the ongoing work regarding the incoming PCI
> memory corruption.
Ok, I recall seeing that thread.
> We are going down the path of abandoning the 82540
> for our platform because we can't seem to track down the corruption.
> So we are looking at other chipsets which we can purchase, which
> include this National (now TI) chipset on the Netgear FA331. If we
> could find a PCI (_not_ PCIe) card to test with that seems to work...
>
> Interestingly, I have an older 3com 3C905TXM exhibiting the same
> behavior. Both of these are older cards (they even came with drivers
> on--gasp--floppies!). Maybe the lack of a 5V supply is an issue...
If you're looking for a PCI target that you can completely control,
then if you have an "FPGA guy" in your company, perhaps he can
dig up a low-cost PCI card that you can configure as a PCI master
to emulate the functions of a network card.
Actually, before going down that route, I would get a PCI extender
that you can use to trace the traffic with your board. Does the
network card use 33MHz or 66MHz?
Cheers,
Dave
^ 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