* Re: [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
From: Sukadev Bhattiprolu @ 2013-01-18 17:46 UTC (permalink / raw)
To: Jiri Olsa
Cc: Andi Kleen, Peter Zijlstra, robert.richter, Greg KH,
Anton Blanchard, linux-kernel, Stephane Eranian, linuxppc-dev,
Ingo Molnar, Paul Mackerras, Arnaldo Carvalho de Melo
In-Reply-To: <20130117141145.GA3817@krava.brq.redhat.com>
Jiri Olsa [jolsa@redhat.com] wrote:
| Maybe it'd worth to mention, that it does not need to be just 'event',
| but anything from /sys/bus/event_source/devices/<dev>/format directory,
| like
|
| The can be multiple terms like 'event=0xNNNN' specified
| and separated with comma. All available terms are located
| in /sys/bus/event_source/devices/<dev>/format file.
|
| Please feel free to rephrase or use proper English ;-)
|
| otherwise it's ok,
| jirka
Agree. Thanks for the review. Here is the updated patch.
---
>From 1e3cc6b3ef87f533985b10574af472361e39eecd Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Tue, 8 Jan 2013 22:31:49 -0800
Subject: [PATCH] perf: Document the ABI of perf sysfs entries
This patchset addes two new sets of files to sysfs for POWER architecture.
- perf event config format in /sys/devices/cpu/format/event
- generic and POWER-specific perf events in /sys/devices/cpu/events/
The format of the first file is already documented in:
sysfs-bus-event_source-devices-format
Document the format of the second set of files '/sys/devices/cpu/events/*'
which would also become part of the ABI.
Changelog[v3.2]: (small changes to this one patch).
[Jiri Olsa]: Mention that multiple event= like terms can be specified
in the 'events' file.
Changelog[v3.1]:
(small changes to just this one patch).
[Jiri Olsa]: Remove the documentation for the 'config format' file
as it is already documented in 'Documentation/ABI/testing/'.
[Jiri Olsa]: Move the documentation of 'events' also to 'testing'
from 'stable'.
Changelog[v3]:
[Greg KH] Include ABI documentation.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
.../testing/sysfs-bus-event_source-devices-events | 62 ++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
delete mode 100644 Documentation/ABI/stable/sysfs-devices-cpu-events
create mode 100644 Documentation/ABI/testing/sysfs-bus-event_source-devices-events
diff --git a/Documentation/ABI/stable/sysfs-devices-cpu-events b/Documentation/ABI/stable/sysfs-devices-cpu-events
deleted file mode 100644
index e69de29..0000000
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
new file mode 100644
index 0000000..0adeb52
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -0,0 +1,62 @@
+What: /sys/devices/cpu/events/
+ /sys/devices/cpu/events/branch-misses
+ /sys/devices/cpu/events/cache-references
+ /sys/devices/cpu/events/cache-misses
+ /sys/devices/cpu/events/stalled-cycles-frontend
+ /sys/devices/cpu/events/branch-instructions
+ /sys/devices/cpu/events/stalled-cycles-backend
+ /sys/devices/cpu/events/instructions
+ /sys/devices/cpu/events/cpu-cycles
+
+Date: 2013/01/08
+
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+
+Description: Generic performance monitoring events
+
+ A collection of performance monitoring events that may be
+ supported by many/most CPUs. These events can be monitored
+ using the 'perf(1)' tool.
+
+ The contents of each file would look like:
+
+ event=0xNNNN
+
+ where 'N' is a hex digit and the number '0xNNNN' shows the
+ "raw code" for the perf event identified by the file's
+ "basename".
+
+
+What: /sys/devices/cpu/events/PM_LD_MISS_L1
+ /sys/devices/cpu/events/PM_LD_REF_L1
+ /sys/devices/cpu/events/PM_CYC
+ /sys/devices/cpu/events/PM_BRU_FIN
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
+ /sys/devices/cpu/events/PM_BRU_MPRED
+ /sys/devices/cpu/events/PM_INST_CMPL
+ /sys/devices/cpu/events/PM_CMPLU_STALL
+
+Date: 2013/01/08
+
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+ Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
+
+Description: POWER-systems specific performance monitoring events
+
+ A collection of performance monitoring events that may be
+ supported by the POWER CPU. These events can be monitored
+ using the 'perf(1)' tool.
+
+ These events may not be supported by other CPUs.
+
+ The contents of each file would look like:
+
+ event=0xNNNN
+
+ where 'N' is a hex digit and the number '0xNNNN' shows the
+ "raw code" for the perf event identified by the file's
+ "basename".
+
+ Further, multiple terms like 'event=0xNNNN' can be specified
+ and separated with comma. All available terms are defined in
+ the /sys/bus/event_source/devices/<dev>/format file.
--
1.7.1
^ permalink raw reply related
* [PATCH] pseries/iommu: Fix iteration in DDW TCE clearrange
From: Nishanth Aravamudan @ 2013-01-18 19:16 UTC (permalink / raw)
To: benh; +Cc: nfont, paulus, linuxppc-dev, miltonm, anton
tce_clearrange_multi_pSeriesLP is attempting to iterate over all TCEs in
a given range. However, is it not advancing the dma_offset value passed
to plpar_tce_stuff via the next value. This prevents DLPAR from
completing, because TCEs are still present at slot isolation time.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index e2685ba..a55b685 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -382,6 +382,7 @@ static int tce_clearrange_multi_pSeriesLP(unsigned long start_pfn,
rc = plpar_tce_stuff((u64)be32_to_cpu(maprange->liobn),
dma_offset,
0, limit);
+ next += limit * tce_size;
num_tce -= limit;
} while (num_tce > 0 && !rc);
^ permalink raw reply related
* [PATCH] pseries/iommu: ensure TCEs are cleared with non-huge DDW
From: Nishanth Aravamudan @ 2013-01-18 19:17 UTC (permalink / raw)
To: benh; +Cc: nfont, paulus, linuxppc-dev, miltonm, anton
There are now two kinds of DMA windows that might be presented by
PowerVM DDW support -- huge windows (that can map all of system memory
regardless of the LPAR configuration) and non-huge windows (which
can't). They are implemented slightly differently in PowerVM, and thus
have different characteristics. The most obvious is that slot isolate
doesn't clear the TCEs/window for us with non-huge windows. Thus, when a
DLPAR operation occurs on a slot using a non-huge window, TCEs are still
present (the notifier chain doesn't currently remove them explicitly)
and the DLPAR fails. Fix this by calling remove_ddw() first, which will
unmap the DDW TCEs.
Note: a corresponding change to drmgr is needed to actually successfully
DLPAR, such that the device-tree update (which causes the notifier chain
to fire) occurs before slot isolate.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index a55b685..b4bb9e1 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1296,6 +1296,7 @@ static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned long acti
switch (action) {
case OF_RECONFIG_DETACH_NODE:
+ remove_ddw(np);
if (pci && pci->iommu_table)
iommu_free_table(pci->iommu_table, np->full_name);
@@ -1308,16 +1309,6 @@ static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned long acti
}
}
spin_unlock(&direct_window_list_lock);
-
- /*
- * Because the notifier runs after isolation of the
- * slot, we are guaranteed any DMA window has already
- * been revoked and the TCEs have been marked invalid,
- * so we don't need a call to remove_ddw(np). However,
- * if an additional notifier action is added before the
- * isolate call, we should update this code for
- * completeness with such a call.
- */
break;
default:
err = NOTIFY_DONE;
^ permalink raw reply related
* Re: [PATCH 6/6][v3] perf: Document the ABI of perf sysfs entries
From: Arnaldo Carvalho de Melo @ 2013-01-18 19:20 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Andi Kleen, Peter Zijlstra, robert.richter, Greg KH,
Anton Blanchard, linux-kernel, Stephane Eranian, linuxppc-dev,
Ingo Molnar, Paul Mackerras, Jiri Olsa
In-Reply-To: <20130118174654.GA12575@us.ibm.com>
Em Fri, Jan 18, 2013 at 09:46:54AM -0800, Sukadev Bhattiprolu escreveu:
> Jiri Olsa [jolsa@redhat.com] wrote:
> | Maybe it'd worth to mention, that it does not need to be just 'event',
> | but anything from /sys/bus/event_source/devices/<dev>/format directory,
> | like
> |
> | The can be multiple terms like 'event=0xNNNN' specified
> | and separated with comma. All available terms are located
> | in /sys/bus/event_source/devices/<dev>/format file.
> |
> | Please feel free to rephrase or use proper English ;-)
> |
> | otherwise it's ok,
> | jirka
>
> Agree. Thanks for the review. Here is the updated patch.
Ok, I'll wait for Jiri's final acked-by, then you can resubmit the patch
series and I'll apply it to my perf/core branch.
- Arnaldo
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: dts - add ranges property for SEC
From: Kim Phillips @ 2013-01-18 20:40 UTC (permalink / raw)
To: Po Liu; +Cc: linuxppc-dev
In-Reply-To: <1358500573-19477-1-git-send-email-po.liu@freescale.com>
On Fri, 18 Jan 2013 17:16:13 +0800
Po Liu <po.liu@freescale.com> wrote:
> This facilitates getting the physical address of the SEC node.
>
> Signed-off-by: Liu po <po.liu@freescale.com>
> ---
Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
Kim
^ permalink raw reply
* [PATCH] perf: Fix compile warnings in tests/attr.c
From: Sukadev Bhattiprolu @ 2013-01-19 1:30 UTC (permalink / raw)
To: acme, Anton Blanchard, paulus; +Cc: linuxppc-dev, jolsa, linux-kernel
>From 4d266e5040c33103f5d226b0d16b89f8ef79e3ad Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Fri, 18 Jan 2013 11:14:28 -0800
Subject: [PATCH] perf: Fix compile warnings in tests/attr.c
Replace '%llu' in printf()s with 'PRIu64' in 'tools/perf/tests/attr.c'
to fix compile warnings (which become errors due to -Werror).
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
tools/perf/tests/attr.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c
index f61dd3f..5cbb2b3 100644
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -65,7 +65,7 @@ static int store_event(struct perf_event_attr *attr, pid_t pid, int cpu,
FILE *file;
char path[PATH_MAX];
- snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
+ snprintf(path, PATH_MAX, "%s/event-%d-%" PRIu64 "-%d", dir,
attr->type, attr->config, fd);
file = fopen(path, "w+");
@@ -74,7 +74,7 @@ static int store_event(struct perf_event_attr *attr, pid_t pid, int cpu,
return -1;
}
- if (fprintf(file, "[event-%d-%llu-%d]\n",
+ if (fprintf(file, "[event-%d-%" PRIu64 "-%d]\n",
attr->type, attr->config, fd) < 0) {
perror("test attr - failed to write event file");
fclose(file);
@@ -91,10 +91,10 @@ static int store_event(struct perf_event_attr *attr, pid_t pid, int cpu,
/* struct perf_event_attr */
WRITE_ASS(type, PRIu32);
WRITE_ASS(size, PRIu32);
- WRITE_ASS(config, "llu");
- WRITE_ASS(sample_period, "llu");
- WRITE_ASS(sample_type, "llu");
- WRITE_ASS(read_format, "llu");
+ WRITE_ASS(config, PRIu64);
+ WRITE_ASS(sample_period, PRIu64);
+ WRITE_ASS(sample_type, PRIu64);
+ WRITE_ASS(read_format, PRIu64);
WRITE_ASS(disabled, "d");
WRITE_ASS(inherit, "d");
WRITE_ASS(pinned, "d");
@@ -119,10 +119,10 @@ static int store_event(struct perf_event_attr *attr, pid_t pid, int cpu,
WRITE_ASS(exclude_callchain_user, "d");
WRITE_ASS(wakeup_events, PRIu32);
WRITE_ASS(bp_type, PRIu32);
- WRITE_ASS(config1, "llu");
- WRITE_ASS(config2, "llu");
- WRITE_ASS(branch_sample_type, "llu");
- WRITE_ASS(sample_regs_user, "llu");
+ WRITE_ASS(config1, PRIu64);
+ WRITE_ASS(config2, PRIu64);
+ WRITE_ASS(branch_sample_type, PRIu64);
+ WRITE_ASS(sample_regs_user, PRIu64);
WRITE_ASS(sample_stack_user, PRIu32);
fclose(file);
--
1.7.1
^ permalink raw reply related
* ml510 booting problem.
From: rakesh l @ 2013-01-19 10:41 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
Hello All,
I am trying to port 3.6 linux kernel on ml510 board and i
have already ported 3.6 kernel on ml403 board but i am unable to do the
same thing on ml510. I really don't know what i am missing here.
Tools used :
1) xilinx 13.1 edk
2) linux kernel from git.xilinx.com (downloaded 3.6 kernel)
3) eldk 5.3 (cross compilers tools)
Flow go's like this :
1) I have added necessary peripherals in the edk and generated bit stream
and exported it to sdk. In sdk i have creted a .dts file.
2) The obtained dts file i have placed in arch/powerpc/boot/dts folder
3) i also got ramdisk image from wiki.xilinx.com/powerpc-linux. (placed in
/arch/powerpc/boot)
compiled kernel using default configuration. i have also enabled soft fpu's
After compiling i got .elf file in arch/powerpc/boot . i took that elf and
download.bit in edk project and clubbed it in xmd console inorder to get
.ace file .
obtained .ace file is loaded in CF and trying to port through rs232, but i
am seeing nothing on the console. what to do.... what i am missing here. I
am breaking my head from past 1 month. Please do reply.
With Regards,
Rakesh.
[-- Attachment #2: Type: text/html, Size: 1507 bytes --]
^ permalink raw reply
* Re: Anyone have a PrPmc 280/2800 handy?
From: Paul Gortmaker @ 2013-01-20 1:59 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20130117223343.GC32446@animalcreek.com>
On Thu, Jan 17, 2013 at 5:33 PM, Mark A. Greer <mgreer@animalcreek.com> wrote:
> Hello.
>
> I want to make some fixups to the marvell hostbridge and
> mpsc code and would like to test them on a PrPmc280/2800.
> The problem is, I don't have one anymore.
Hi Mark,
Is there another platform that uses mpsc that can be used for
testing? I ask because I did spend a lot of time with PrPMC-280
and motload/powerboot; some standalone, some on ATCA-F101.
And with that hindsight, I can't help thinking that the right thing
to do some eight years later is to simply consider removing the
support for these old platforms. Would that make your validation
easier? If so, then I'd recommend it. This is of course, just my opinion.
Paul.
--
>
> If you have one handy and don't mind running a quick boot
> test for me, please let me know.
>
> Thanks,
>
> Mark
> --
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [v2][PATCH 0/6] powerpc/book3e: make kgdb to work well
From: Tiejun Chen @ 2013-01-21 7:44 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel, jason.wessel
This patchset is used to support kgdb/gdb on book3e.
v2:
* Make sure we cover CONFIG_PPC_BOOK3E_64 safely
* Use LOAD_REG_IMMEDIATE() to load properly
the value of the constant expression in load debug exception stack
* Copy thread infor form the kernel stack coming from usr
* Rebase latest powerpc git tree
v1:
* Copy thread info only when we are from !user mode since we'll get kernel stack
coming from usr directly.
* remove save/restore EX_R14/EX_R15 since DBG_EXCEPTION_PROLOG already covered
this.
* use CURRENT_THREAD_INFO() conveniently to get thread.
* fix some typos
* add a patch to make sure gdb can generate a single step properly to invoke a
kgdb state.
* add a patch to if we need to replay an interrupt, we shouldn't restore that
previous backup thread info to make sure we can replay an interrupt lately
with a proper thread info.
* rebase latest powerpc git tree
v0:
This patchset is used to support kgdb for book3e.
Tiejun Chen (6):
powerpc/book3e: load critical/machine/debug exception stack
powerpc/book3e: store critical/machine/debug exception thread info
book3e/kgdb: update thread's dbcr0
book3e/kgdb: Fix a single stgep case of lazy IRQ
powerpc/book3e: support kgdb for kernel space
kgdb/kgdbts: support ppc64
arch/powerpc/kernel/exceptions-64e.S | 60 +++++++++++++++++++++++++++++++---
arch/powerpc/kernel/irq.c | 10 ++++++
arch/powerpc/kernel/kgdb.c | 16 ++++++---
drivers/misc/kgdbts.c | 2 ++
4 files changed, 80 insertions(+), 8 deletions(-)
Tiejun
^ permalink raw reply
* [v2][PATCH 1/6] powerpc/book3e: load critical/machine/debug exception stack
From: Tiejun Chen @ 2013-01-21 7:44 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1358754255-31484-1-git-send-email-tiejun.chen@windriver.com>
We always alloc critical/machine/debug check exceptions. This is
different from the normal exception. So we should load these exception
stack properly like we did for booke.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/exceptions-64e.S | 40 +++++++++++++++++++++++++++++++---
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index ae54553..767f856 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -36,6 +36,28 @@
*/
#define SPECIAL_EXC_FRAME_SIZE INT_FRAME_SIZE
+/* only on book3e */
+#define DBG_STACK_BASE dbgirq_ctx
+#define MC_STACK_BASE mcheckirq_ctx
+#define CRIT_STACK_BASE critirq_ctx
+
+#ifdef CONFIG_SMP
+#define BOOK3E_LOAD_EXC_LEVEL_STACK(level) \
+ mfspr r14,SPRN_PIR; \
+ slwi r14,r14,3; \
+ LOAD_REG_IMMEDIATE(r10, level##_STACK_BASE); \
+ add r10,r10,r14; \
+ ld r10,0(r10); \
+ addi r10,r10,THREAD_SIZE; \
+ std r10,PACA_##level##_STACK(r13);
+#else
+#define BOOK3E_LOAD_EXC_LEVEL_STACK(level) \
+ LOAD_REG_IMMEDIATE(r10, level##_STACK_BASE); \
+ ld r10,0(r10); \
+ addi r10,r10,THREAD_SIZE; \
+ std r10,PACA_##level##_STACK(r13);
+#endif
+
/* Exception prolog code for all exceptions */
#define EXCEPTION_PROLOG(n, intnum, type, addition) \
mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ \
@@ -68,20 +90,32 @@
#define SPRN_GDBELL_SRR1 SPRN_GSRR1
#define CRIT_SET_KSTACK \
+ andi. r10,r11,MSR_PR; \
+ bne 1f; \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(CRIT); \
ld r1,PACA_CRIT_STACK(r13); \
- subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
+ subi r1,r1,SPECIAL_EXC_FRAME_SIZE; \
+1:
#define SPRN_CRIT_SRR0 SPRN_CSRR0
#define SPRN_CRIT_SRR1 SPRN_CSRR1
#define DBG_SET_KSTACK \
+ andi. r10,r11,MSR_PR; \
+ bne 1f; \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(DBG); \
ld r1,PACA_DBG_STACK(r13); \
- subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
+ subi r1,r1,SPECIAL_EXC_FRAME_SIZE; \
+1:
#define SPRN_DBG_SRR0 SPRN_DSRR0
#define SPRN_DBG_SRR1 SPRN_DSRR1
#define MC_SET_KSTACK \
+ andi. r10,r11,MSR_PR; \
+ bne 1f; \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(MC); \
ld r1,PACA_MC_STACK(r13); \
- subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
+ subi r1,r1,SPECIAL_EXC_FRAME_SIZE; \
+1:
#define SPRN_MC_SRR0 SPRN_MCSRR0
#define SPRN_MC_SRR1 SPRN_MCSRR1
--
1.7.9.5
^ permalink raw reply related
* [v2][PATCH 2/6] powerpc/book3e: store critical/machine/debug exception thread info
From: Tiejun Chen @ 2013-01-21 7:44 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1358754255-31484-1-git-send-email-tiejun.chen@windriver.com>
We need to store thread info to these exception thread info like something
we already did for PPC32.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/exceptions-64e.S | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 767f856..423a936 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -58,6 +58,18 @@
std r10,PACA_##level##_STACK(r13);
#endif
+/* Store something to exception thread info */
+#define BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(type) \
+ ld r1,PACAKSAVE(r13); \
+ CURRENT_THREAD_INFO(r14, r14); \
+ CURRENT_THREAD_INFO(r15, r1); \
+ ld r10,TI_FLAGS(r14); \
+ std r10,TI_FLAGS(r15); \
+ ld r10,TI_PREEMPT(r14); \
+ std r10,TI_PREEMPT(r15); \
+ ld r10,TI_TASK(r14); \
+ std r10,TI_TASK(r15);
+
/* Exception prolog code for all exceptions */
#define EXCEPTION_PROLOG(n, intnum, type, addition) \
mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ \
@@ -95,6 +107,7 @@
BOOK3E_LOAD_EXC_LEVEL_STACK(CRIT); \
ld r1,PACA_CRIT_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE; \
+ BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(CRIT); \
1:
#define SPRN_CRIT_SRR0 SPRN_CSRR0
#define SPRN_CRIT_SRR1 SPRN_CSRR1
@@ -105,6 +118,7 @@
BOOK3E_LOAD_EXC_LEVEL_STACK(DBG); \
ld r1,PACA_DBG_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE; \
+ BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(DBG); \
1:
#define SPRN_DBG_SRR0 SPRN_DSRR0
#define SPRN_DBG_SRR1 SPRN_DSRR1
@@ -115,6 +129,7 @@
BOOK3E_LOAD_EXC_LEVEL_STACK(MC); \
ld r1,PACA_MC_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE; \
+ BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(MC); \
1:
#define SPRN_MC_SRR0 SPRN_MCSRR0
#define SPRN_MC_SRR1 SPRN_MCSRR1
--
1.7.9.5
^ permalink raw reply related
* [v2][PATCH 3/6] book3e/kgdb: update thread's dbcr0
From: Tiejun Chen @ 2013-01-21 7:44 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1358754255-31484-1-git-send-email-tiejun.chen@windriver.com>
gdb always need to generate a single step properly to invoke
a kgdb state. But with lazy interrupt, book3e can't always
trigger a debug exception with a single step since the current
is blocked for handling those pending exception, then we miss
that expected dbcr configuration at last to generate a debug
exception.
So here we also update thread's dbcr0 to make sure the current
can go back with that missed dbcr0 configuration.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/kgdb.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 8747447..eb30a40 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -409,7 +409,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
struct pt_regs *linux_regs)
{
char *ptr = &remcom_in_buffer[1];
- unsigned long addr;
+ unsigned long addr, dbcr0;
switch (remcom_in_buffer[0]) {
/*
@@ -426,8 +426,15 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code,
/* set the trace bit if we're stepping */
if (remcom_in_buffer[0] == 's') {
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
- mtspr(SPRN_DBCR0,
- mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
+ dbcr0 = mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM;
+ mtspr(SPRN_DBCR0, dbcr0);
+#ifdef CONFIG_PPC_BOOK3E_64
+ /* With lazy interrut we have to update thread dbcr0 here
+ * to make sure we can set debug properly at last to invoke
+ * kgdb again to work well.
+ */
+ current->thread.dbcr0 = dbcr0;
+#endif
linux_regs->msr |= MSR_DE;
#else
linux_regs->msr |= MSR_SE;
--
1.7.9.5
^ permalink raw reply related
* [v2][PATCH 4/6] book3e/kgdb: Fix a single stgep case of lazy IRQ
From: Tiejun Chen @ 2013-01-21 7:44 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1358754255-31484-1-git-send-email-tiejun.chen@windriver.com>
When we're in kgdb_singlestep(), we have to work around to get
thread_info by copying from the kernel stack before calling
kgdb_handle_exception(), then copying it back afterwards.
But for PPC64, we have a lazy interrupt implementation. So after
copying thread info frome kernle stack, if we need to replay an
interrupt, we shouldn't restore that previous backup thread info
to make sure we can replay an interrupt lately with a proper
thread info.
This patch use __check_irq_replay() to guarantee this process.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/irq.c | 10 ++++++++++
arch/powerpc/kernel/kgdb.c | 3 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 4f97fe3..bb8d27a 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -339,7 +339,17 @@ bool prep_irq_for_idle(void)
return true;
}
+notrace unsigned int check_irq_replay(void)
+{
+ return __check_irq_replay();
+}
+#else
+notrace unsigned int check_irq_replay(void)
+{
+ return 0;
+}
#endif /* CONFIG_PPC64 */
+EXPORT_SYMBOL(check_irq_replay);
int arch_show_interrupts(struct seq_file *p, int prec)
{
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index eb30a40..2f22807 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -151,6 +151,7 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
return 1;
}
+extern notrace unsigned int check_irq_replay(void);
static int kgdb_singlestep(struct pt_regs *regs)
{
struct thread_info *thread_info, *exception_thread_info;
@@ -181,7 +182,7 @@ static int kgdb_singlestep(struct pt_regs *regs)
kgdb_handle_exception(0, SIGTRAP, 0, regs);
- if (thread_info != exception_thread_info)
+ if ((thread_info != exception_thread_info) && (!check_irq_replay()))
/* Restore current_thread_info lastly. */
memcpy(exception_thread_info, backup_current_thread_info, sizeof *thread_info);
--
1.7.9.5
^ permalink raw reply related
* [v2][PATCH 5/6] powerpc/book3e: support kgdb for kernel space
From: Tiejun Chen @ 2013-01-21 7:44 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1358754255-31484-1-git-send-email-tiejun.chen@windriver.com>
Currently we need to skip this for supporting KGDB.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/exceptions-64e.S | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 423a936..6204681 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -589,11 +589,14 @@ kernel_dbg_exc:
rfdi
/* Normal debug exception */
+1:
+#ifndef CONFIG_KGDB
/* XXX We only handle coming from userspace for now since we can't
* quite save properly an interrupted kernel state yet
*/
-1: andi. r14,r11,MSR_PR; /* check for userspace again */
+ andi. r14,r11,MSR_PR; /* check for userspace again */
beq kernel_dbg_exc; /* if from kernel mode */
+#endif
/* Now we mash up things to make it look like we are coming on a
* normal exception
--
1.7.9.5
^ permalink raw reply related
* [v2][PATCH 6/6] kgdb/kgdbts: support ppc64
From: Tiejun Chen @ 2013-01-21 7:44 UTC (permalink / raw)
To: benh, galak; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1358754255-31484-1-git-send-email-tiejun.chen@windriver.com>
We can't look up the address of the entry point of the function simply
via that function symbol for all architectures.
For PPC64 ABI, actually there is a function descriptors structure.
A function descriptor is a three doubleword data structure that contains
the following values:
* The first doubleword contains the address of the entry point of
the function.
* The second doubleword contains the TOC base address for
the function.
* The third doubleword contains the environment pointer for
languages such as Pascal and PL/1.
So we should call a wapperred dereference_function_descriptor() to get
the address of the entry point of the function.
Note this is also safe for other architecture after refer to
"include/asm-generic/sections.h" since:
dereference_function_descriptor(p) always is (p) if without arched definition.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
drivers/misc/kgdbts.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 3aa9a96..4799e1f 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -103,6 +103,7 @@
#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/module.h>
+#include <asm/sections.h>
#define v1printk(a...) do { \
if (verbose) \
@@ -222,6 +223,7 @@ static unsigned long lookup_addr(char *arg)
addr = (unsigned long)do_fork;
else if (!strcmp(arg, "hw_break_val"))
addr = (unsigned long)&hw_break_val;
+ addr = (unsigned long )dereference_function_descriptor((void *)addr);
return addr;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 8/15] arch/powerpc/platforms/85xx/p1022_ds.c: adjust duplicate test
From: Julia Lawall @ 2013-01-21 13:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: kernel-janitors, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1358773378-4700-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Delete successive tests to the same location. The code tested the result
of a previous call, that itself was already tested. It is changed to test
the result of the most recent call.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@s exists@
local idexpression y;
expression x,e;
@@
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
... when != \(y = e\|y += e\|y -= e\|y |= e\|y &= e\|y++\|y--\|&y\)
when != \(XT_GETPAGE(...,y)\|WMI_CMD_BUF(...)\)
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
arch/powerpc/platforms/85xx/p1022_ds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index e346edf..af5853c 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -302,7 +302,7 @@ static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
goto exit;
}
cs1_addr = lbc_br_to_phys(ecm, num_laws, br1);
- if (!cs0_addr) {
+ if (!cs1_addr) {
pr_err("p1022ds: could not determine physical address for CS1"
" (BR1=%08x)\n", br1);
goto exit;
^ permalink raw reply related
* Re: [RFC PATCH 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: Roger Quadros @ 2013-01-21 13:18 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: linux-doc, tony, linux, linux-sh, alexander.shishkin, stern,
devicetree-discuss, linuxppc-dev, rob.herring, horms,
haojian.zhuang, linux-omap, linux-arm-kernel, eric.y.miao,
b-cousson, gregkh, linux-usb, linux-kernel, balbi, cbou, rob,
dwmw2
In-Reply-To: <1358348462-27693-7-git-send-email-kishon@ti.com>
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
> The OMAP glue has been modified to get PHY by phandle for dt boot.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/musb/omap2430.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 3628a50..08709cf 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -346,7 +346,12 @@ static int omap2430_musb_init(struct musb *musb)
> * up through ULPI. TWL4030-family PMICs include one,
> * which needs a driver, drivers aren't always needed.
> */
> - musb->xceiv = devm_usb_get_phy(dev, 0);
> + if (dev->parent->of_node)
> + musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
> + "usb_phy", 0);
Why dev->parent and not just dev?
> + else
> + musb->xceiv = devm_usb_get_phy(dev, 0);
> +
> if (IS_ERR_OR_NULL(musb->xceiv)) {
> pr_err("HS USB OTG: no transceiver configured\n");
> return -ENODEV;
>
--
cheers,
-roger
^ permalink raw reply
* Re: [RFC PATCH 5/6] usb: otg: add device tree support to otg library
From: Roger Quadros @ 2013-01-21 13:21 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: linux-doc, tony, linux, linux-sh, alexander.shishkin, stern,
devicetree-discuss, linuxppc-dev, rob.herring, horms,
Marc Kleine-Budde, haojian.zhuang, linux-omap, linux-arm-kernel,
eric.y.miao, b-cousson, gregkh, linux-usb, linux-kernel, balbi,
cbou, rob, dwmw2
In-Reply-To: <1358348462-27693-6-git-send-email-kishon@ti.com>
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
> Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
> device node phandle value. This function will return a pointer to
> the phy on success, -EPROBE_DEFER if there is a device_node for the phandle,
> but the phy has not been added, or a ERR_PTR() otherwise.
>
> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/otg/otg.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/usb/phy.h | 8 +++++
> 2 files changed, 85 insertions(+)
>
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index dbf2043..e9799bb 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -13,7 +13,9 @@
> #include <linux/export.h>
> #include <linux/err.h>
> #include <linux/device.h>
> +#include <linux/module.h>
> #include <linux/slab.h>
> +#include <linux/of.h>
>
> #include <linux/usb/otg.h>
>
> @@ -34,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct device *dev, u8 index)
> return ERR_PTR(-ENODEV);
> }
>
> +static struct usb_phy *__of_usb_find_phy(struct device_node *node)
> +{
> + struct usb_phy *phy;
> +
> + list_for_each_entry(phy, &phy_list, head) {
> + if (node != phy->dev->of_node)
> + continue;
> +
> + return phy;
> + }
> +
> + return ERR_PTR(-ENODEV);
> +}
> +
> static void devm_usb_phy_release(struct device *dev, void *res)
> {
> struct usb_phy *phy = *(struct usb_phy **)res;
> @@ -109,6 +125,67 @@ err0:
> }
> EXPORT_SYMBOL(usb_get_phy);
>
> + /**
> + * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
> + * @dev - device that requests this phy
> + * @phandle - name of the property holding the phy phandle value
> + * @index - the index of the phy
> + *
> + * Returns the phy driver associated with the given phandle value,
> + * after getting a refcount to it, -ENODEV if there is no such phy or
> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
> + * not yet loaded. While at that, it also associates the device with
> + * the phy using devres. On driver detach, release function is invoked
> + * on the devres data, then, devres data is freed.
> + *
> + * For use by USB host and peripheral drivers.
> + */
> +struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
> + const char *phandle, u8 index)
> +{
> + struct usb_phy *phy = NULL, **ptr;
> + unsigned long flags;
> + struct device_node *node;
> +
> + if (!dev->of_node) {
> + dev_dbg(dev, "device does not have a device node entry\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + node = of_parse_phandle(dev->of_node, phandle, index);
> + if (!node) {
> + dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
> + dev->of_node->full_name);
> + return ERR_PTR(-ENODEV);
> + }
> +
> + ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr) {
> + dev_dbg(dev, "failed to allocate memory for devres\n");
> + return ERR_PTR(-ENOMEM);
> + }
I fail to understand why you need ptr at all and why do devres_alloc()
for it.
> +
> + spin_lock_irqsave(&phy_lock, flags);
> +
> + phy = __of_usb_find_phy(node);
> + if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
> + phy = ERR_PTR(-EPROBE_DEFER);
> + devres_free(ptr);
> + goto err0;
> + }
> +
> + *ptr = phy;
> + devres_add(dev, ptr);
> +
> + get_device(phy->dev);
> +
> +err0:
> + spin_unlock_irqrestore(&phy_lock, flags);
> +
> + return phy;
> +}
> +EXPORT_SYMBOL(devm_usb_get_phy_by_phandle);
> +
--
cheers,
-roger
^ permalink raw reply
* Re: [RFC PATCH 5/6] usb: otg: add device tree support to otg library
From: kishon @ 2013-01-21 13:34 UTC (permalink / raw)
To: Roger Quadros
Cc: linux-doc, tony, linux, linux-sh, alexander.shishkin, stern,
devicetree-discuss, linuxppc-dev, rob.herring, horms,
Marc Kleine-Budde, haojian.zhuang, linux-omap, linux-arm-kernel,
eric.y.miao, b-cousson, gregkh, linux-usb, linux-kernel, balbi,
cbou, rob, dwmw2
In-Reply-To: <50FD40D1.8020405@ti.com>
On Monday 21 January 2013 06:51 PM, Roger Quadros wrote:
> On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
>> Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
>> device node phandle value. This function will return a pointer to
>> the phy on success, -EPROBE_DEFER if there is a device_node for the phandle,
>> but the phy has not been added, or a ERR_PTR() otherwise.
>>
>> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> drivers/usb/otg/otg.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/usb/phy.h | 8 +++++
>> 2 files changed, 85 insertions(+)
>>
>> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
>> index dbf2043..e9799bb 100644
>> --- a/drivers/usb/otg/otg.c
>> +++ b/drivers/usb/otg/otg.c
>> @@ -13,7 +13,9 @@
>> #include <linux/export.h>
>> #include <linux/err.h>
>> #include <linux/device.h>
>> +#include <linux/module.h>
>> #include <linux/slab.h>
>> +#include <linux/of.h>
>>
>> #include <linux/usb/otg.h>
>>
>> @@ -34,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct device *dev, u8 index)
>> return ERR_PTR(-ENODEV);
>> }
>>
>> +static struct usb_phy *__of_usb_find_phy(struct device_node *node)
>> +{
>> + struct usb_phy *phy;
>> +
>> + list_for_each_entry(phy, &phy_list, head) {
>> + if (node != phy->dev->of_node)
>> + continue;
>> +
>> + return phy;
>> + }
>> +
>> + return ERR_PTR(-ENODEV);
>> +}
>> +
>> static void devm_usb_phy_release(struct device *dev, void *res)
>> {
>> struct usb_phy *phy = *(struct usb_phy **)res;
>> @@ -109,6 +125,67 @@ err0:
>> }
>> EXPORT_SYMBOL(usb_get_phy);
>>
>> + /**
>> + * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
>> + * @dev - device that requests this phy
>> + * @phandle - name of the property holding the phy phandle value
>> + * @index - the index of the phy
>> + *
>> + * Returns the phy driver associated with the given phandle value,
>> + * after getting a refcount to it, -ENODEV if there is no such phy or
>> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
>> + * not yet loaded. While at that, it also associates the device with
>> + * the phy using devres. On driver detach, release function is invoked
>> + * on the devres data, then, devres data is freed.
>> + *
>> + * For use by USB host and peripheral drivers.
>> + */
>> +struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
>> + const char *phandle, u8 index)
>> +{
>> + struct usb_phy *phy = NULL, **ptr;
>> + unsigned long flags;
>> + struct device_node *node;
>> +
>> + if (!dev->of_node) {
>> + dev_dbg(dev, "device does not have a device node entry\n");
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + node = of_parse_phandle(dev->of_node, phandle, index);
>> + if (!node) {
>> + dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
>> + dev->of_node->full_name);
>> + return ERR_PTR(-ENODEV);
>> + }
>> +
>> + ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
>> + if (!ptr) {
>> + dev_dbg(dev, "failed to allocate memory for devres\n");
>> + return ERR_PTR(-ENOMEM);
>> + }
>
> I fail to understand why you need ptr at all and why do devres_alloc()
> for it.
Thats how we create a "managed device resource". You can have a look at
Documentation/driver-model/devres.txt and drivers/base/devres.c.
I'm not sure if that is what you are looking for :-P
Thanks
Kishon
^ permalink raw reply
* Re: [RFC PATCH 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: kishon @ 2013-01-21 13:41 UTC (permalink / raw)
To: Roger Quadros
Cc: linux-doc, tony, linux, linux-sh, alexander.shishkin, stern,
devicetree-discuss, linuxppc-dev, rob.herring, horms,
haojian.zhuang, linux-omap, linux-arm-kernel, eric.y.miao,
b-cousson, gregkh, linux-usb, linux-kernel, balbi, cbou, rob,
dwmw2
In-Reply-To: <50FD4034.5040402@ti.com>
Hi,
On Monday 21 January 2013 06:48 PM, Roger Quadros wrote:
> On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
>> The OMAP glue has been modified to get PHY by phandle for dt boot.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> drivers/usb/musb/omap2430.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>> index 3628a50..08709cf 100644
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -346,7 +346,12 @@ static int omap2430_musb_init(struct musb *musb)
>> * up through ULPI. TWL4030-family PMICs include one,
>> * which needs a driver, drivers aren't always needed.
>> */
>> - musb->xceiv = devm_usb_get_phy(dev, 0);
>> + if (dev->parent->of_node)
>> + musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
>> + "usb_phy", 0);
>
> Why dev->parent and not just dev?
Right now MUSB core is not converted to dt and hence we don't have
separate dt node for MUSB core.
So the PHY information is added to the glue dt data.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH] perf: Fix compile warnings in tests/attr.c
From: Jiri Olsa @ 2013-01-21 13:59 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: linuxppc-dev, Anton Blanchard, paulus, linux-kernel, acme
In-Reply-To: <20130119013052.GA24693@us.ibm.com>
On Fri, Jan 18, 2013 at 05:30:52PM -0800, Sukadev Bhattiprolu wrote:
> From 4d266e5040c33103f5d226b0d16b89f8ef79e3ad Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Date: Fri, 18 Jan 2013 11:14:28 -0800
> Subject: [PATCH] perf: Fix compile warnings in tests/attr.c
>
> Replace '%llu' in printf()s with 'PRIu64' in 'tools/perf/tests/attr.c'
> to fix compile warnings (which become errors due to -Werror).
i386 and x86_64 compiles fine for me with gcc versions 4.6.3-2 and 4.7.2-2
with your patch for x86_64 I'm getting following warnings/errors:
CC tests/attr.o
tests/attr.c: In function ‘store_event’:
tests/attr.c:69:4: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘__u64’ [-Werror=format]
tests/attr.c:69:4: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘__u64’ [-Werror=format]
tests/attr.c:78:7: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:94:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:94:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:95:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:95:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:96:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:96:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:97:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:97:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:122:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:122:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:123:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:123:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:124:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:124:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:125:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
tests/attr.c:125:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘__u64’ [-Werror=format]
cc1: all warnings being treated as errors
make: *** [tests/attr.o] Error 1
i386 compiles fine
jirka
^ permalink raw reply
* Re: [RFC PATCH 5/6] usb: otg: add device tree support to otg library
From: Roger Quadros @ 2013-01-21 14:23 UTC (permalink / raw)
To: kishon
Cc: linux-doc, tony, linux, linux-sh, alexander.shishkin, stern,
devicetree-discuss, linuxppc-dev, rob.herring, horms,
Marc Kleine-Budde, haojian.zhuang, linux-omap, linux-arm-kernel,
eric.y.miao, b-cousson, gregkh, linux-usb, linux-kernel, balbi,
cbou, rob, dwmw2
In-Reply-To: <50FD43F5.1020208@ti.com>
On 01/21/2013 03:34 PM, kishon wrote:
> On Monday 21 January 2013 06:51 PM, Roger Quadros wrote:
>> On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
>>> Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
>>> device node phandle value. This function will return a pointer to
>>> the phy on success, -EPROBE_DEFER if there is a device_node for the
>>> phandle,
>>> but the phy has not been added, or a ERR_PTR() otherwise.
>>>
>>> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> drivers/usb/otg/otg.c | 77
>>> +++++++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/usb/phy.h | 8 +++++
>>> 2 files changed, 85 insertions(+)
>>>
>>> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
>>> index dbf2043..e9799bb 100644
>>> --- a/drivers/usb/otg/otg.c
>>> +++ b/drivers/usb/otg/otg.c
>>> @@ -13,7 +13,9 @@
>>> #include <linux/export.h>
>>> #include <linux/err.h>
>>> #include <linux/device.h>
>>> +#include <linux/module.h>
>>> #include <linux/slab.h>
>>> +#include <linux/of.h>
>>>
>>> #include <linux/usb/otg.h>
>>>
>>> @@ -34,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct
>>> device *dev, u8 index)
>>> return ERR_PTR(-ENODEV);
>>> }
>>>
>>> +static struct usb_phy *__of_usb_find_phy(struct device_node *node)
>>> +{
>>> + struct usb_phy *phy;
>>> +
>>> + list_for_each_entry(phy, &phy_list, head) {
>>> + if (node != phy->dev->of_node)
>>> + continue;
>>> +
>>> + return phy;
>>> + }
>>> +
>>> + return ERR_PTR(-ENODEV);
>>> +}
>>> +
>>> static void devm_usb_phy_release(struct device *dev, void *res)
>>> {
>>> struct usb_phy *phy = *(struct usb_phy **)res;
>>> @@ -109,6 +125,67 @@ err0:
>>> }
>>> EXPORT_SYMBOL(usb_get_phy);
>>>
>>> + /**
>>> + * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
>>> + * @dev - device that requests this phy
>>> + * @phandle - name of the property holding the phy phandle value
>>> + * @index - the index of the phy
>>> + *
>>> + * Returns the phy driver associated with the given phandle value,
>>> + * after getting a refcount to it, -ENODEV if there is no such phy or
>>> + * -EPROBE_DEFER if there is a phandle to the phy, but the device is
>>> + * not yet loaded. While at that, it also associates the device with
>>> + * the phy using devres. On driver detach, release function is invoked
>>> + * on the devres data, then, devres data is freed.
>>> + *
>>> + * For use by USB host and peripheral drivers.
>>> + */
>>> +struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
>>> + const char *phandle, u8 index)
>>> +{
>>> + struct usb_phy *phy = NULL, **ptr;
>>> + unsigned long flags;
>>> + struct device_node *node;
>>> +
>>> + if (!dev->of_node) {
>>> + dev_dbg(dev, "device does not have a device node entry\n");
>>> + return ERR_PTR(-EINVAL);
>>> + }
>>> +
>>> + node = of_parse_phandle(dev->of_node, phandle, index);
>>> + if (!node) {
>>> + dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
>>> + dev->of_node->full_name);
>>> + return ERR_PTR(-ENODEV);
>>> + }
>>> +
>>> + ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
>>> + if (!ptr) {
>>> + dev_dbg(dev, "failed to allocate memory for devres\n");
>>> + return ERR_PTR(-ENOMEM);
>>> + }
>>
>> I fail to understand why you need ptr at all and why do devres_alloc()
>> for it.
>
> Thats how we create a "managed device resource". You can have a look at
> Documentation/driver-model/devres.txt and drivers/base/devres.c.
OK, I get it now. You might want to update the text file too since you
are adding a automagically managed interface.
regards,
-roger
^ permalink raw reply
* Re: [RFC PATCH 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: Roger Quadros @ 2013-01-21 14:24 UTC (permalink / raw)
To: kishon
Cc: linux-doc, tony, linux, linux-sh, alexander.shishkin, stern,
devicetree-discuss, linuxppc-dev, rob.herring, horms,
haojian.zhuang, linux-omap, linux-arm-kernel, eric.y.miao,
b-cousson, gregkh, linux-usb, linux-kernel, balbi, cbou, rob,
dwmw2
In-Reply-To: <50FD4593.5020007@ti.com>
On 01/21/2013 03:41 PM, kishon wrote:
> Hi,
>
> On Monday 21 January 2013 06:48 PM, Roger Quadros wrote:
>> On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
>>> The OMAP glue has been modified to get PHY by phandle for dt boot.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> drivers/usb/musb/omap2430.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>> index 3628a50..08709cf 100644
>>> --- a/drivers/usb/musb/omap2430.c
>>> +++ b/drivers/usb/musb/omap2430.c
>>> @@ -346,7 +346,12 @@ static int omap2430_musb_init(struct musb *musb)
>>> * up through ULPI. TWL4030-family PMICs include one,
>>> * which needs a driver, drivers aren't always needed.
>>> */
>>> - musb->xceiv = devm_usb_get_phy(dev, 0);
>>> + if (dev->parent->of_node)
>>> + musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
>>> + "usb_phy", 0);
>>
>> Why dev->parent and not just dev?
>
> Right now MUSB core is not converted to dt and hence we don't have
> separate dt node for MUSB core.
> So the PHY information is added to the glue dt data.
>
OK. Got it :).
--
cheers,
-roger
^ permalink raw reply
* Re: Anyone have a PrPmc 280/2800 handy?
From: Mark A. Greer @ 2013-01-21 18:30 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <CAP=VYLpyJZ3BYW6xrJOivQoXv3y7msiB5g7_puFw04UdMFW3zA@mail.gmail.com>
On Sat, Jan 19, 2013 at 08:59:18PM -0500, Paul Gortmaker wrote:
> On Thu, Jan 17, 2013 at 5:33 PM, Mark A. Greer <mgreer@animalcreek.com> wrote:
> > Hello.
> >
> > I want to make some fixups to the marvell hostbridge and
> > mpsc code and would like to test them on a PrPmc280/2800.
> > The problem is, I don't have one anymore.
>
> Hi Mark,
Hi Paul.
> Is there another platform that uses mpsc that can be used for
> testing? I ask because I did spend a lot of time with PrPMC-280
> and motload/powerboot; some standalone, some on ATCA-F101.
> And with that hindsight, I can't help thinking that the right thing
> to do some eight years later is to simply consider removing the
> support for these old platforms. Would that make your validation
> easier? If so, then I'd recommend it. This is of course, just my opinion.
Hmm, yeah, the c2k platform uses that bridge too. I'll see if I can find
someone with one of those handy.
Since nobody seems to have a prmpc280/2800 anymore, it does seem prudent
to remove it. It would make validation easier for me in that its one less
platform to worry about breaking. If I don't hear anything in the next
few days, I'll make a patches to remove prpmc280/2800 support.
Thanks,
Mark
--
^ permalink raw reply
* Re: [PATCH] perf: Fix compile warnings in tests/attr.c
From: Sukadev Bhattiprolu @ 2013-01-21 21:38 UTC (permalink / raw)
To: Jiri Olsa; +Cc: linuxppc-dev, Anton Blanchard, paulus, linux-kernel, acme
In-Reply-To: <20130121135906.GD1995@krava.brq.redhat.com>
Jiri Olsa [jolsa@redhat.com] wrote:
| On Fri, Jan 18, 2013 at 05:30:52PM -0800, Sukadev Bhattiprolu wrote:
| > From 4d266e5040c33103f5d226b0d16b89f8ef79e3ad Mon Sep 17 00:00:00 2001
| > From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
| > Date: Fri, 18 Jan 2013 11:14:28 -0800
| > Subject: [PATCH] perf: Fix compile warnings in tests/attr.c
| >=20
| > Replace '%llu' in printf()s with 'PRIu64' in 'tools/perf/tests/attr.c'
| > to fix compile warnings (which become errors due to -Werror).
|=20
| i386 and x86_64 compiles fine for me with gcc versions 4.6.3-2 and 4.7.2-2
But is broken on Power for 64bit :-( I am trying to fix that and thought
that use of format specifiers like 'PRIu64' was the way to go.
|=20
| with your patch for x86_64 I'm getting following warnings/errors:
|=20
| CC tests/attr.o
| tests/attr.c: In function =E2=80=98store_event=E2=80=99:
| tests/attr.c:69:4: error: format =E2=80=98%lu=E2=80=99 expects argument o=
f type =E2=80=98long unsigned int=E2=80=99, but argument 6 has type =E2=80=
=98__u64=E2=80=99 [-Werror=3Dformat]
Here is what I see on an x86_64 box, RHEL6.2 box:
$ rpm -qf /usr/include/linux/types.h
kernel-headers-2.6.32-220.4.2.el6.x86_64
$ cat foo.c
#include <linux/types.h>
$ cc -Werror -Wall foo.c
In file included from /usr/include/asm-generic/types.h:7,
from /usr/include/asm/types.h:6,
from /usr/include/linux/types.h:4,
from foo5.c:1:
/usr/include/asm-generic/int-ll64.h:31:2: error: #error __u64 defined as u=
nsigned long long
where the #error is my debug message.
<snip>
| make: *** [tests/attr.o] Error 1
|=20
| i386 compiles fine
__u64 is 'unsigned long long' on x86 and PRIu64 is 'llu' which is fine.
__u64 is 'unsigned long' on Power and PRIu64 is 'lu' which is again fine.
But __u64 is 'unsigned long long' on x86_64, but PRIu64 is '%lu' bc __WORDS=
IZE
is 64.
On x86_64, shouldn't __u64, be defined as 'unsigned long' rather than
'unsigned long long' - ie include 'int-l64.h' rather than 'int-ll64.h' ?
BTW, does 'perf' with my patch compile, (with warnings) for you on x86_64
with 'WERROR=3D0 make' ?
Sukadev
^ 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